Payer APIs built to be used rather than merely to satisfy a requirement, with honest provenance on data that came from claims and was never a clinical record.
Most payer API work exists because it is required. The predictable result is an implementation built to the letter of the requirement, published, adopted by almost nobody, and operated at full cost indefinitely. The plan has met its obligation, acquired a permanent platform commitment and received nothing back, which is the worst available position and also the most common one.
An API nobody calls still needs monitoring, security review, version management and an on-call rota. Compliance is the floor, not the outcome.
A plan holds administrative facts. A claim records that a service was billed with a diagnosis attached for payment purposes. Rendered as a FHIR Condition resource, that becomes something a receiving application will display to a clinician or a member as though it were a diagnosis made by a physician. It was not. It was a billing assertion, and the distance between those two is where payer interoperability creates clinical risk that nobody has quantified.
The second problem is commercial rather than clinical. Building to the requirement is achievable and produces an asset with an operating cost and no return, because nothing in the requirement obliges anyone to use it.
Claims-derived resources look clinical and are not
A diagnosis on a claim supports payment. Published as a clinical resource without provenance, it is consumed as a clinical fact
Compliance-minimum builds have no users
Meeting the letter of a requirement can produce a technically conformant API that no application integrates with.
Directory APIs publish your data quality
Provider directory accuracy becomes machine-readable, comparable and externally visible.
Payer-to-payer exchange has no provider equivalent
You send member data to another plan and receive data of unknown completeness and quality that you are then expected to use.
Third-party applications are not vetted by you
Data is released to applications the plan did not choose and cannot assess, while member questions still arrive when something goes wrong.
A success response is not a successful exchange
An HTTP success does not prove identity, completeness, semantic accuracy or usability.
Publish provenance with every claims-derived resource.
Where a condition, procedure or medication originates in a claim rather than a clinical record, say so in the resource itself. Receiving applications can then display it appropriately and clinicians can weigh it correctly.
When compliance sets the scope, the design question becomes who would actually use this and what would they need beyond the minimum. That question costs very little to ask and it is the difference between an asset and an obligation.
Step 1
Establish the obligation precisely
Then establish the opportunity separately, so the minimum is known and the design is not limited to it.
Step 2
Identify the actual consumers
Which applications, providers, plans or partners would call this and what would make them choose to.
Step 3
Map source data honestly
Record what each element genuinely represents and what it does not.
Step 4
Design provenance first
Make a claims-derived assertion distinguishable from a clinical one in the payload.
Step 5
Resolve identity before publishing
Member, provider and organization identity mastered before exposing matching quality externally.
Step 6
Design consent and authorization
Member-directed release handled distinctly from partner exchange.
Step 7
Choose the pattern per exchange
Regulatory APIs and enterprise integration have different performance, availability, security and workflow requirements.
Step 8
Build on governed data products
Avoid querying the core platform directly so external API load does not become an adjudication risk.
Step 9
Establish the operating model
Versioning, deprecation, monitoring, support, security review cadence and ownership before launch.
Step 10
Measure adoption and usability
Treat near-zero usage as a design finding, not somebody else’s problem.
Conformance testing proves you are compliant, not that you are usable.
An API can pass every conformance test and still fail at realistic data volumes, identity resolution, completeness or pagination. Test with a real consumer against real volume before launch.
The API surface is the visible part and the least difficult. Resource mapping with honest provenance, identity resolution, consent handling and the permanent operating model are what determine whether the implementation is safe and whether it survives.
Model the Data
Resource Mapping and Provenance
Claims, membership, provider, clinical and pharmacy data mapped to resources with the origin of every element recorded.
Terminology, Translation and Sufficiency
Administrative code sets translated to expected vocabularies, with unmapped values held rather than approximated.
Identity Resolution
Member, provider and organization identity mastered before publication.
Build the Surface
API Design and Implementation
Endpoints, search behaviour, pagination and bulk access designed against realistic volumes.
Authorization and Consent
Member-directed release, partner exchange and internal access handled as distinct flows.
Payer-to-Payer Exchange
Outbound release and inbound receipt treated with explicit data quality controls.
Prior Authorization APIs
Requirement discovery, submission and status exchange aligned to the operating model underneath.
Operate It
Versioning and Deprecation
A published policy with notice periods and predictable change.
Performance and Scale
Serve from governed data products, not the core platform, and test at realistic history sizes.
Reusable Service Layer
Shared data, identity, mapping, authorization and API management capabilities reused across exchanges.
Application and Partner Management
Registration, credentials, entitlement, rate limiting and support.
Adoption and Usability Measurement
Who is calling, what they retrieve, where they fail and where they give up.
What CaliberFocus does, and does not do?
We are not your counsel and do not interpret your regulatory obligations. We build the implementation and work alongside the legal and compliance leadership who own the interpretation. We will also tell you when an API you are required to publish will have no users, because that changes how much you should spend on it and whether the effort belongs somewhere the data would actually get consumed.
These are mostly obligations, and each fails to deliver value for its own specific reason. The third column is that reason, and addressing it costs a fraction of the build.
| API | What It Exposes | Why It Usually Underdelivers |
|---|---|---|
| Member Access | Claims, coverage and clinical data to member-authorized applications | Data is sparse and claims-derived. Applications cannot do much with it, so few integrate. |
| Provider Directory | Participation, location, specialty and contact information | It publishes the accuracy problem. The API is fine and the underlying data is not. |
| Payer-to-Payer Exchange | Member data to and from another plan on request | Inbound arrives incomplete and unvalidated, and nobody owns making it useful once received. |
| Prior Authorization | Requirement discovery, submission and status | The operating model did not change, so the API accelerates a process that still waits on people. |
| Formulary and Benefits | Coverage, tier and cost share information | Genuinely useful and consistently underinvested, because it is not the most visible obligation. |
| Partner and Vendor Exchange | Data to delegates, vendors and analytics partners | Frequently still a file transfer, because nobody revisited it when the API estate was built. |
| Internal Consumption | The same resources serving the plan's own applications | The largest available return and the one nobody scoped, since the driver was external compliance. |
Prior Authorization Is Workflow Interoperability, Not Document Retrieval
An authorization exchange has states: request, supporting information, status, decision, communication and follow-up. The API has to support progression through them rather than serving a document on demand.
This is the clinical safety core of payer FHIR work. A resource type carries an implied meaning that a receiving application will act on, and payer source data frequently does not support that meaning. The mapping decision is where that gap is either handled or concealed.
| Resource | What the Plan Actually Holds | What Must Be Stated |
|---|---|---|
| Condition | A diagnosis code submitted on a claim to support payment | Claims-derived. Not a clinician assertion, not confirmed, and not necessarily current. |
| Procedure | A procedure code billed for a service | Billed rather than clinically documented, with no operative detail behind it. |
| MedicationDispense | A pharmacy claim showing a fill | A fill is not adherence. It shows a prescription was collected, not taken. |
| Observation | Occasionally a result from supplemental data, often nothing | Source and date, since plans rarely hold results and what they do hold is partial. |
| Coverage | Genuine plan data, authoritative | One of the few resources where the plan is the best available source. |
| ExplanationOfBenefit | The claim itself, in its native meaning | Authoritative, and the resource payers should invest in most. |
A consumer does not need to know that eligibility comes from one platform and claims from another. They do need to be able to establish where a given element came from and how it was transformed.
Never populate an element you cannot support
An empty required element is honest. A plausible guess is worse than nothing because it is indistinguishable from a fact.
Hold unmapped values rather than approximating
A code that does not translate cleanly is an exception with an owner, not an opportunity to select the nearest available concept
Separate the three access models
Member-directed release, partner exchange under agreement and internal consumption have different authorization, consent and audit requirements. One model for all three is the common failure.
Design consent revocation, not just consent
A member who authorized an application must be able to withdraw it, and the withdrawal has to take effect everywhere including anything already exchanged.
Test at real volume
A member with eleven years of claims is not the test member with four. Pagination, timeouts and payload size fail at the volumes that matter
Version the mapping with the API
Mapping, profiles, extensions, transformation rules and API contracts are version-controlled production assets. A mapping change is a release, not an edit.
Treat inbound as unvalidated
The analysis is not complete when the variance is explained. It is complete when the issue has a named owner and a decision about whether to act.
Decide what a receiving clinician will believe.
The design test is not whether the mapping is technically defensible. It is what a clinician or a member will conclude when an application displays the resource. If the honest answer is that they will take an administrative billing artifact for a confirmed clinical fact, the mapping needs provenance, a qualifier or a decision not to publish that element at all.
An external API has unpredictable volume, unknown consumers and no ability to be told to try later. Serving it directly from the core administration platform makes an outside party capable of affecting adjudication performance, and that risk is usually discovered during the first bulk export somebody attempts.
Governed data products
Serve from certified claims, membership, provider and coverage products rather than live core platform queries.
Core administration platform
Remain the system of record, accessed through the data layer, with real-time requirements designed deliberately and rate-limited.
Provider data mastered
Identity, participation and effective dating must be governed before directory data becomes externally comparable.
Clinical and supplemental sources
Where genuine clinical data exists, retain source and date so it can be distinguished from claims-derived content.
Identity and authorization infrastructure
Member authentication, application registration, token issuance and consent records form much of the security surface.
Consent and preference records
Maintain grant and revocation history at the person level.
Isolate external traffic with separate serving infrastructure, rate limiting and quotas.
Separate serving infrastructure, rate limiting and quotas, so no consumer can degrade internal operations regardless of behaviour.
State freshness per resource.
Consumers need to know how current the data is. A claims-derived resource is weeks behind the clinical event and should say so.
Reuse the governed resource layer internally.
One governed set of resources serving external obligations and internal applications, rather than a compliance estate alongside the existing one
Design bulk separately from query.
Bulk export and individual retrieval have different performance profiles, and a bulk request against a query-shaped design is how these platforms fail first.
Define behaviour when a source fails.
Fail, return partial with an indication, serve an approved cached representation, retry, or route for operational intervention. Chosen per exchange rather than defaulted to whatever the framework does.
Member-directed release means an application the plan has not assessed receives member data on the member’s instruction. That is the design and it is correct. It also means the plan will receive questions when something goes wrong downstream, and governance has to be clear about where the plan’s responsibility ends and demonstrable about what it did.
Access and authorization
- Member-directed release, partner exchange and internal consumption governed distinctly
- Application registration, credentials, entitlement scoping and rate limiting
- Consent with grant, scope and revocation history
Data protection
- Minimum necessary per scope
- Sensitive category handling at the resource level where applicable
- Encryption, token lifetime and credential rotation
- Bulk export controls
Auditability
- Every request attributable to an application, authorization, member and timestamp
- Mapping and provenance decisions documented and versioned
- Consent grant and revocation history reproducible
Operational control
- Published versioning and deprecation policy
- Monitoring beyond uptime
- Named owner per API
- Retirement path
Find out whether anyone is using it.
Pull call volume by consumer for each published API and look at how many distinct applications made meaningful requests. For an API with near-zero usage, either improve usability or operate it at genuine minimum rather than continuing to fund enhancements nobody asked for.
API programmes report conformance achieved and endpoints published. Both are necessary and neither indicates whether anything is being consumed or whether what is being consumed is safe to act on.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Adoption | Distinct consumers making meaningful use, and volume trend by API | The measure that decides whether the investment was an asset or an obligation. |
| Usability | Error rates by consumer, abandoned call patterns and support contacts from developers | Conformance can pass while usability fails. |
| Provenance Integrity | Resources published with accurate source attribution and no unsupported elements populated | The clinical safety measure. |
| Internal Reuse | Plan applications consuming the governed resource layer rather than separate interfaces | Turns compliance cost into shared infrastructure and shrinks the estate. |
| Operational Health | Performance at real volume, isolation from core platform and consumer-visible incidents | Whether the platform survives its own success. |
| Consent Integrity | Revocations honoured completely and promptly, and consent history reproducible | What gets examined after a complaint. |
Honest expectation setting
Expect low adoption on at least one mandated API, and expect the mapping review to identify elements currently published that the plan cannot properly support. Both are better established now than after an application developer publishes a complaint or a clinician acts on a billing code presented as a diagnosis.
We will review what you publish, test it at realistic volume as a consumer would, assess whether your claims-derived resources carry honest provenance, measure who is actually using each API, and identify where internal reuse would turn compliance spend into shared infrastructure. The provenance review is the part we would do first regardless of what else is in scope.
Bring us a specialty or clinical setting where clinicians are spending too much time creating notes. We will assess where ambient documentation fits, what must remain clinician controlled, how it should integrate with your EHR, and how to measure whether it is actually reducing burden.
One conversation with people who have run these deployments, and a written readiness view you can use with or without us.
- AI Agents and Workflow Automation
- Voice and Conversational AI
- Document AI and Intelligent Processing
- Generative AI and Enterprise Copilots
- AI Strategy and Governance
- HCC and Risk Adjustment Analytics
Security & Compliance
