Start a project
Menu
ServicesAll servicesCybersecurityCloud EngineeringApplication ServicesEnterprise PlatformsData & AnalyticsAI & Machine LearningInternet of ThingsMobilize Talent
PlatformsAll platformsIdentity and accessPrivileged access and secretsERP, HCM and financeCRM, ITSM and automationHealthcareInsurance and bankingData and integrationCloud and AIIndustrial, utilities and mainframeSkills matrix
Case studiesAll case studiesIdentity and accessPrivileged accessSecurity operationsCloud and infrastructureApplicationsERP and HCMCRM, ITSM and automationIndustry platformsData and analyticsAI and agents
IndustriesAll industriesEnergy, oil & gasHealthcare payersBanking & financial servicesInsurancePublic sectorManufacturingLocations
InsightsField notesLearning tracks
CompanyAbout CohashPortfolioSkills matrixCareersTrust and securityContact
Start a project
industries · healthcare payers

Payer APIs, member logins and claims data that meet the CMS deadline and survive a HIPAA audit.

Health plans are building FHIR APIs for members, providers and other payers while the core still runs on Facets and nightly batch jobs. We connect the two, put identity in front of the APIs and decide who inside the plan can see claims data.

Talk to an engineerThe rules that apply
industry / healthcare-payers 4 rules in scope
01 · CORE PAYER SYSTEMS 02 · IDENTITY AND APIS 03 · API CONSUMERS 04 · INTERNAL ANALYTICS TriZetto Facets: claims · enrollment · providers TriZetto Facets claims · enrollment ·providers Utilization management: prior auth decisions Utilizationmanagement prior auth decisions FHIR API layer: Patient · Provider · P2P · PA FHIR API layer Patient · Provider ·P2P · PA Member and app identity: SMART on FHIR · OIDC Member and appidentity SMART on FHIR · OIDC Member apps: plan app · third-party apps Member apps plan app · third-partyapps Provider systems: EHRs · Da Vinci PAS Provider systems EHRs · Da Vinci PAS Other payers: payer-to-payer exchange Other payers payer-to-payerexchange Claims data platform: masking · row access policies Claims data platform masking · row accesspolicies
01 · CORE PAYER SYSTEMS02 · IDENTITY AND APIS03 · API CONSUMERS04 · INTERNAL ANALYTICS TriZetto Facets: claims · enrollment · providers TriZetto Facets claims ·enrollment ·… Utilization management: prior auth decisions Utilizationmanagement prior authdecisions FHIR API layer: Patient · Provider · P2P · PA FHIR API layer Patient · Provider· P2P · PA Member and app identity: SMART on FHIR · OIDC Member and appidentity SMART on FHIR ·OIDC Member apps: plan app · third-party apps Member apps plan app ·third-partyapps Provider systems: EHRs · Da Vinci PAS Providersystems EHRs · Da VinciPAS Other payers: payer-to-payer exchange Other payers payer-to-payerexchange Claims data platform: masking · row access policies Claims data platform masking · row access policies © Cohash · cohash.com
TriZetto FacetsAuth0OktaSnowflake
in short·15-second read

Under CMS-0057-F, member, claims and prior authorization data has to go out through FHIR APIs.

HIPAA's Security Rule hasn't gone anywhere, so it still has to be protected. We upgrade and integrate TriZetto Facets. We build member and app identity for the APIs with SMART on FHIR and OpenID Connect. And claims data goes into Snowflake or Databricks, where analysts only see what their role allows.

you probably need this if
  • The CMS-0057-F API work has a 2027 date but nobody owns how members and apps will authenticate.
  • During the last upgrade someone copied the Facets user groups from a template. Nobody has looked at them since.
  • Analysts still query claims tables with full member identifiers. Turn masking on and their reports break, so nobody does.
terms on this page FHIRdefinitionFast Healthcare Interoperability Resources, HL7's standard for health data over web APIs. CMS requires Release 4.0.1 here, so that's the version your server has to speak.explained in a field note →attributiondefinitionThe record that says this provider treats this member. Plans can build it from claims, PCP assignment or provider attestation, and the Provider Access API checks it on every call.explained in a field note →environmentdefinitionThe thing that holds a set of apps, flows and agents plus their database. Admins see one per team in the list when it's Dataverse for Teams.explained in a field note →
Ask an engineer facts checked 2026-10-20
how it runs
  1. 01Map each rule to its systems
  2. 02Measure who can reach regulated data
  3. 03Fix and automate the controls
  4. 04Produce evidence auditors can sample
rules
CMS Interoperability and Prior Authorization Final RuleHIPAA Security RuleState insurance data security lawsNYDFS Cybersecurity Regulation
platforms
proof
6 case studies on this
background
Decisionclocks First metrics APIs live Proposed:drugs Jan 2026 Jan 2028
field note · 14 minCMS-0057-F on January 1, 2027: what health plans on Facets, QNXT and HealthRules need live
regulations

The rules your access program answers to

Summaries for orientation, not legal advice. Ask us how each one maps to your systems.

CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)

Medicare Advantage, Medicaid, CHIP and Exchange QHP issuers, this one's yours. Provider Access, Payer-to-Payer and Prior Authorization APIs are due, generally from 1 January 2027, and prior authorization data has to show up in the Patient Access API. Decision timeframes and specific denial reasons applied from 1 January 2026.

map it to your systems →

HIPAA Security Rule (45 CFR Part 164, Subpart C)

The rule wants a risk analysis, unique user IDs, and access and audit controls around electronic PHI. In January 2025 HHS proposed a major update that would add MFA, an asset inventory and encryption. It isn't final, HHS now projects July 2027, and the current rule is still the one in force.

map it to your systems →

State insurance data security laws (NAIC Model 668)

28 jurisdictions had adopted the NAIC Insurance Data Security Model Law as of 8 October 2026. It requires a written security program, third-party service provider oversight and notice to the commissioner within 72 hours. HIPAA-compliant licensees can certify against its program section.

map it to your systems →

NYDFS Cybersecurity Regulation (23 NYCRR Part 500)

Health insurers licensed by New York DFS are in scope. Since 1 November 2025 that has meant MFA for every individual who touches your information systems, plus a documented asset inventory.

map it to your systems →
from rule to evidence

How a regulation turns into proof.

For healthcare payers, each rule below lands as a control, the control runs on a platform, and the platform leaves a record an auditor can read.

  1. 01

    Rules you answer to

    CMS Interoperability and Prior Authorization Final RuleHIPAA Security RuleState insurance data security lawsNYDFS Cybersecurity Regulation
  2. 02

    Controls we build

    Facets upgrades and integrationIdentity in front of the CMS APIsGovernance for core payer systemsGoverned claims dataMember and broker CRM
  3. 03

    Platforms that enforce them

  4. 04

    Evidence your auditors read

    Access review records Joiner, mover and leaver logs Privileged session records Change and approval history Control-to-rule mapping
the story · healthcare payers access program

From the first call to a setup your own team can run.

Here's what usually prompts a call about your healthcare payers access program, what we do about it and in which order, and where you end up.

  1. chapter 01 · where it hurts

    Why teams reach out

    • The CMS-0057-F API work has a 2027 date but nobody owns how members and apps will authenticate.
    • During the last upgrade someone copied the Facets user groups from a template. Nobody has looked at them since.
    • Analysts still query claims tables with full member identifiers. Turn masking on and their reports break, so nobody does.
  2. chapter 02 · what we change

    How we solve it

    • Facets upgrades and integration
    • Identity in front of the CMS APIs
    • Governance for core payer systems
    • Governed claims data
    • Member and broker CRM
  3. chapter 03 · how it runs

    Our approach

    • Map each rule to the systems it touches
    • Measure who can reach regulated data today
    • Fix access and automate the controls
    • Produce evidence auditors can sample
  4. chapter 04 · where you end up

    What changes

    • Each API sits on feeds that were tested before launch.
    • Most analysts work on de-identified data now.
challenges and answers

Where it usually goes wrong, and what we do about it

where it goes wrong
  1. 01

    Facets access that grew without a design

    Facets user groups, application security and claims permissions build up over years of upgrades and reorgs. Nobody can say with confidence who can adjust a claim or change an enrollment.

  2. 02

    Third-party apps reaching member data

    Members can hook up apps to the Patient Access API that the plan has never vetted. Someone still has to authenticate the member, register the app and scope the tokens properly. And the member portal can't get weaker in the process.

  3. 03

    Provider attribution for the Provider Access API

    Sharing data with in-network providers depends on knowing which provider has a treatment relationship with which member. That data usually lives in claims history and is messier than the API design assumes.

  4. 04

    PHI copied into every analytics environment

    Claims extracts end up in warehouses, sandboxes and vendor feeds, full member identifiers included. Every copy widens the HIPAA risk analysis. Every copy also makes the access review longer.

  5. 05

    Offshore and vendor access to core systems

    Claims processing vendors, BPO teams and implementation partners need Facets access. Their accounts often live outside HR-driven lifecycle processes and outlast the contract.

how we help
  1. 01

    Facets upgrades and integration

    Facets version upgrades, extension and integration work, and the data feeds that move claims, enrollment and utilization data to the API layer and analytics.

  2. 02

    Identity in front of the CMS APIs

    Member authentication and app authorization with SMART on FHIR and OpenID Connect on Auth0 or Okta, backend-services tokens for provider and payer-to-payer exchange, and consent records the API layer can check.

  3. 03

    Governance for core payer systems

    Role design and certification campaigns across Facets, claims and care management. We pull in the vendor and offshore accounts too, the ones that sit outside HR records.

  4. 04

    Governed claims data

    Claims and member data sit in Snowflake or Databricks, masked, with row access policies on top. Analysts see what their role needs. Sandboxes don't get PHI unless someone asks for it.

  5. 05

    Member and broker CRM

    Salesforce or Dynamics 365 for member services, broker management and prior authorization cases. We hook it up to Facets so your agents quit typing the same data twice.

typical situations

Situations we walk into

We pieced these together from healthcare payers situations that come up a lot. They're patterns. You won't find a specific client in them.

case file 01

Patient Access API live, Provider Access API still on a whiteboard

composite · not a client story
  1. Beforethe situation

    A Medicare Advantage plan has run its Patient Access API on a vendor FHIR server for years. Now the Provider Access, Payer-to-Payer and Prior Authorization APIs are due by 1 January 2027. Provider attribution still lives in one spreadsheet.

  2. What we dothe work

    Step one is mapping the Facets and utilization management feeds each API needs. Attribution gets rebuilt from claims history together with network management. Provider and payer clients are set up with backend-services authorization. Nothing goes live until test data has run through every API and the consent checks have been tried.

  3. Afterwhere you end up

    Each API sits on feeds that were tested before launch. Attribution comes from a maintained data set instead of one person's spreadsheet. Provider and payer clients hold tokens the plan can revoke.

case file 02

Full member identifiers in every analytics sandbox

composite · not a client story
  1. Beforethe situation

    Actuarial and analytics teams query claims tables where names, member IDs and diagnosis codes sit in clear text. There are three environments like that. The HIPAA risk analysis lists every copy, and an access review takes a month.

  2. What we dothe work

    We tag the PHI columns, then apply masking and row access policies by role in Snowflake or Databricks. Analysts land on de-identified views. If they need identified data, there's a request path. We rebuild the sandboxes from the masked views.

  3. Afterwhere you end up

    Most analysts work on de-identified data now. Anyone who needs identified access asks, gets approved, and is reviewed later. The risk analysis has fewer PHI copies to chase.

architecture

How member data moves from Facets to the CMS-required APIs

Claims, enrollment and prior authorization data come out of the core admin platform and into a FHIR API layer. Identity services sit at the front and decide, call by call, whether a member, app, provider or payer gets in. Internal analytics runs separately, on its own governed data platform.

How member data moves from Facets to the CMS-required APIs Claims, enrollment and prior authorization data come out of the core admin platform and into a FHIR API layer. Identity services sit at the front and decide, call by call, whether a member, app, provider or payer gets in. Internal analytics runs separately, on its own governed data platform. 01 · CORE PAYER SYSTEMS 02 · IDENTITY AND APIS 03 · API CONSUMERS 04 · INTERNAL ANALYTICS claims and coverage prior auth status access tokens Patient Access Provider Access member history CDC Fa TriZetto Facets claims · enrollment· providers Utilization management prior auth decisions FHIR API layer Patient · Provider · P2P ·PA Member and appidentity SMART on FHIR · OIDC Member apps plan app · third-partyapps Provider systems EHRs · Da Vinci PAS Other payers payer-to-payer exchange Claims dataplatform masking · row accesspolicies © Cohash · cohash.com
01 · CORE PAYER SYSTEMS02 · IDENTITY AND APIS03 · API CONSUMERS04 · INTERNAL ANALYTICS TriZetto Facets: claims · enrollment · providers TriZetto Facets claims ·enrollment ·… Utilization management: prior auth decisions Utilizationmanagement prior authdecisions FHIR API layer: Patient · Provider · P2P · PA FHIR API layer Patient · Provider· P2P · PA Member and app identity: SMART on FHIR · OIDC Member and appidentity SMART on FHIR ·OIDC Member apps: plan app · third-party apps Member apps plan app ·third-partyapps Provider systems: EHRs · Da Vinci PAS Providersystems EHRs · Da VinciPAS Other payers: payer-to-payer exchange Other payers payer-to-payerexchange Claims data platform: masking · row access policies Claims data platform masking · row access policies claims and coverage prior auth status Patient Access Provider Access member history CDC © Cohash · cohash.com
case studies

Work on the platforms healthcare payers runs on

All case studies
implementation Industry platforms

TriZetto Facets upgrades and CMS-0057-F interoperability APIs

Keeping TriZetto Facets current while we build the Provider Access, Payer-to-Payer and Prior Authorization APIs that CMS-0057-F requires by January 2027.

read the case study
upgrade Identity and access

Moving Auth0 Rules and Hooks to Actions before Auth0 switches them off

Moving Auth0 Rules and Hooks to Actions before Hooks stop on 30 April 2027 and Rules on 31 January 2028, with token claims checked before and after each change.

read the case study
implementation Industry platforms

Epic integrations, FHIR APIs and TEFCA connectivity

Building and governing the HL7 and FHIR integrations, SMART on FHIR apps and TEFCA exchange around Epic, with an interface catalog and scope reviews.

read the case study
migration Identity and access

ForgeRock AM/IDM to PingOne Advanced Identity Cloud

Moving self-managed ForgeRock AM and IDM, now called PingAM and PingIDM, to PingOne Advanced Identity Cloud without breaking sign-in or provisioning.

read the case study
migration Industry platforms

Guidewire InsuranceSuite self-managed to Guidewire Cloud

Moving self-managed PolicyCenter, BillingCenter and ClaimCenter to Guidewire Cloud without carrying every Gosu customization and integration along.

read the case study
implementation Identity and access

Homegrown customer login to Auth0 or Okta Customer Identity

We swap homegrown customer login and its user table for Auth0, move users without forcing password resets, and keep the CRM records in sync.

read the case study
talent and delivery · healthcare payers

Certified engineers, wherever you need them.

Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
due diligence · healthcare payers

Questions to ask any partner, including us.

Put these to anyone bidding on your healthcare payers work. The ones who've done it answer differently from the ones who've read about it.

  1. Q1

    Which CMS-0057-F APIs apply to each of our lines of business, and by when?

    Medicare Advantage, Medicaid, CHIP and FFE QHP issuers are in, generally from 1 January 2027, and the dates differ by payer type. Commercial group business is out, and that changes the API design.

  2. Q2

    How will member and app authentication on the APIs satisfy the HIPAA Security Rule?

    The Security Rule asks for unique user IDs, access controls and audit controls on ePHI. On an API layer, those live in SMART on FHIR scopes, consent records and token logs.

  3. Q3

    Are you designing to the current HIPAA Security Rule or the proposed update?

    The January 2025 proposal isn't final, and HHS projects final action for July 2027. Plans under NYDFS Part 500 already need MFA and an asset inventory. So each control should name the rule it actually rests on.

  4. Q4

    Our claims vendors have Facets logins. How will you handle Model 668 oversight for those accounts?

    Adopting states require oversight of third-party service providers. For claims vendors and BPO teams, the test is simple. Does their access end when the contract ends, and did anyone review it in the meantime?

  5. Q5

    If OCR opens an investigation or a state examiner calls, what access evidence will you have left us?

    Both will ask who can reach PHI and how that access is reviewed. Evidence pulled on a schedule from IGA and the data platform beats a scramble after the letter arrives.

01Does CMS-0057-F apply to our commercial group business?

It covers Medicare Advantage organizations, state Medicaid and CHIP programs and their managed care plans, and QHP issuers on the federally facilitated Exchanges. Commercial employer group plans outside those programs aren't directly in scope. Even so, many plans build one API layer for every line of business, because running two is harder.

02Is the updated HIPAA Security Rule final?

No. HHS put out the proposed rule in January 2025, and the October 2026 Unified Agenda lists final action as a long-term item projected for July 2027. So the current Security Rule is what you're held to. If NYDFS Part 500 covers you, MFA and an asset inventory are already required anyway.

03Should members use the existing portal login for third-party apps?

Usually, yes, so members don't end up managing a second password. Two things decide it. Can your portal identity provider act as a SMART on FHIR authorization server, or sit behind one? And how do you handle proxies like parents and caregivers? We check both before we pick.

04Do you also upgrade Facets, or only work on identity and data?

We do both. Facets upgrades and integrations live in our enterprise platforms practice. Usually they run alongside the API and identity work anyway, since it's the same data feeds.

05Can you work alongside our FHIR API vendor?

Yes. Lots of plans buy a FHIR server or API platform. We work on the identity in front of it, the Facets feeds behind it and the testing in between, inside your contract with the vendor.

services

Services for healthcare payers

The services healthcare payers clients ask us for most, alongside the work on this page.

you are hereHealthcare payers
fact-checked Checked against vendor and official documentation last checked 2026-10-20 content fingerprint 1610d3f8
  1. 01Book a 30-minute working sessionsenior engineer
  2. 02Talk to an engineer about your setupreply within 24 hours
  3. 03See how similar projects wentcase studies
Reviewed by the Cohash team Product names are trademarks of their owners. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

Book a working session See the case studies
useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it