Headgate - FHIR Interoperability API Platform for Claims, Clinical Data and Prior Authorization
Payer Interoperability Platform for a US Health Plan
Designed and built a clickable console for the FHIR APIs a US regional health plan must run under federal interoperability rules: API health across Patient Access, Provider Directory, Formulary, Provider Access, Payer-to-Payer and Prior Authorization, a security review queue for third-party apps, and one clock for every prior authorization request, however it arrived.
Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.
Impact
Dashboard, app registrations, app security review, prior authorization queue and request detail. Every demo app and every prior auth request opens its own page, and the profile menu signs in as any of 6 demo roles.
Patient Access, Provider Directory, Formulary, Provider Access, Payer-to-Payer and Prior Authorization CRD, DTR and PAS, each with its version, the CMS rule behind it, error rate, p95 latency, 7-day calls and last incident.
Expedited requests are due in 72 hours and standard ones in 7 calendar days, next to the plan's own 48-hour and 5-day targets. Time left turns amber under 24 hours and red under 12, and expedited requests are amber from receipt.
18 app registrations across 8 review statuses and 18 prior auth requests from 4 channels (PAS API, X12 278, portal and fax), with 12 members, 13 providers, 8 staff users and 6 fixed denial reasons.
The Problem
Juniper Basin, a fictional plan with about 410,000 Medicare Advantage and Medicaid managed care members in two states, met the 2021 Patient Access requirements with a vendor sandbox and a spreadsheet of registered apps. App approvals sat in an email inbox for weeks, nobody could say which apps a member had connected, the claims-to-FHIR conversion silently dropped lines when a code set changed, and prior auth requests arrived by fax, portal and X12 278 with no single clock.
Our Solution
Headgate runs the plan's interoperability APIs from one console. Staff see every API's health and every open deadline on the dashboard, review third-party apps against a security checklist that only allows a denial for security risk, and work every prior authorization request on one queue with a countdown to its federal deadline and a specific reason for every denial.
The Challenge: Federal APIs With Federal Deadlines
US payer interoperability is set by two CMS rules, a stack of HL7 implementation guides and HIPAA. Each API has its own audience, its own auth model and its own deadline, and the plan has to show a regulator who received which member's data and why.
More Required APIs Coming Due
CMS-9115-F already requires Patient Access and Provider Directory APIs. CMS-0057-F adds Provider Access, Payer-to-Payer and Prior Authorization APIs, generally from January 1, 2027, on HL7 FHIR R4, US Core, SMART App Launch and FHIR Bulk Data.
Prior Auth on One Clock
From January 1, 2026, Medicare Advantage and Medicaid managed care plans must generally decide expedited requests within 72 hours and standard ones within 7 calendar days, with a specific reason for every denial, whether the request came through the PAS API, an X12 278, the portal or a fax.
Apps the Plan Cannot Refuse
A plan may deny or end a member-chosen app's access only for an unacceptable security risk to its systems, not for its privacy practices. It may ask apps to attest to a privacy policy, and must tell members when an app has not.
Every Disclosure Accounted For
Provider Access data may go only to providers for their attributed members, with a member opt-out, and Payer-to-Payer exchange needs member opt-in. Every disclosure has to be logged with its purpose and recipient, and the plan must publish prior auth metrics every year.
Our Approach: From Interoperability Rules to a Clickable Console
Spec and Rules Research
Mapped 13 user roles from the interoperability lead and security reviewer to the UM medical director, app developer, provider organisation admin and member. Specified 43 screens across the staff console, developer portal, provider portal, mobile-first member pages and a public metrics page, and the data model for apps, reviews, member app connections, sharing choices, attribution lists, Bulk Data exports, prior auth requests and decisions, payer exchanges, disclosures and mapping issues. Wrote down the rules the design follows: CMS-9115-F, CMS-0057-F, the 2026 decision timeframes, HIPAA and the recommended HL7 implementation guides.
Clickable Demo on a Production UI Kit
Built 5 key screens on a production dashboard kit: the dashboard with KPIs, API health strip, prior auth clocks, role-based My work and needs-attention list, app registrations with status counts and days waiting, the app review with evidence tabs and security checklist, the prior auth queue with tabs and filters, and the request detail with documentation, criteria, clock, messages and activity. Assign, request information and decide run on local state, with a production and sandbox switch in the top bar.
What a Production Build Adds
An API gateway (such as Apigee, Azure API Management or Kong), a FHIR server with Bulk Data, the core claims and enrollment system, a clearinghouse for 837, 835 and 278 transactions, InterQual or MCG criteria, Okta member login with ID.me identity proofing, NPPES and CAQH provider data and member matching for payer-to-payer. Staff auth by role, an append-only audit and disclosure log, the developer, provider and member portals, and the remaining staff screens for traffic, attribution, exchanges, data quality and compliance.
Why It Works: Every Audience, Every Deadline in View
The Dashboard Starts With What Is Late
Open prior auths are stacked by time left, from under 12 hours to over 3 days, and split expedited and standard. Needs attention lists requests near their deadline, apps past the 10-business-day review target, unsent payer-to-payer responses, failed feeds and stuck Bulk Data exports.
Security Review, Not Privacy Gatekeeping
Each app is checked against 7 security criteria with pass, fail or N/A, next to a fixed banner that a missing privacy attestation is shown to members, not a reason to deny. Deny for security risk needs a failed criterion and a written explanation to the developer.
One Queue for Every Channel
PAS API, X12 278, portal and fax requests sit in one table with their channel, urgency, deadline and assignee. Request information pends the request with a PAS pended response and a DTR questionnaire, while the Clock tab shows the federal clock still running against its rule timeframe.
Denials Need a Reason and the Right Reviewer
The decide sheet sets an outcome per service line and takes a denial reason from a fixed list plus text specific to the member. Denials for medical necessity or level of care can be saved only by a medical director, and the ClaimResponse and notice are previewed before sending.
Related case studies
View all: Health data & interoperability
Sutura - HIPAA-Compliant Patient Data Hub over HL7 and FHIR
Designed and built a clickable patient data hub for a US health system running Epic, Oracle Health, athenahealth and eClinicalWorks: a live monitor for every HL7 v2, FHIR and HIE feed, one matched enterprise patient with a provenance-tagged record, and a duplicates queue where a person decides every uncertain match.
Kaivo - Pseudonymised Health Data Warehouse for Leadership Analytics and Permitted Research
Designed and built a clickable data platform console for a bilingual Finnish wellbeing services county: nightly pipelines that pseudonymise patient, lab, imaging, social care and finance data, leadership dashboards built only from aggregates, and a research request desk that ties every project to its data permit.
Enterprise Software Engineering - Human + AI
Contact Us
© 2026 - Copyright. All Rights reserved Oceanlab
Location
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
Enterprise Software Engineering - Human + AI
Contact Us
Locations
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
© 2026 - Copyright. All Rights reserved Oceanlab