FHIR and API enablement built for what happens after launch: versioning, conformance to profiles your partners actually use, throughput that survives a population query, app governance, and a deprecation policy written before the first consumer integrates.
Consuming a vendor FHIR API is straightforward engineering. Exposing your own is a different undertaking, because the moment an external consumer integrates you have accepted a support obligation and a change constraint you cannot unilaterally break. CaliberFocus helps provider organizations do both properly: consume what their platforms expose, and where they need to publish, build an API estate with the governance to run it for years.
Meeting a regulatory API requirement makes you compliant. It does not make you capable, and the two are frequently confused in the same budget line.
FHIR is a framework, not an agreement. Both ends can pass a conformance test and still disagree about which elements are populated, which profile applies, how a code system is bound, what must-support actually obligates, and which extensions carry the data that matters.
The second problem is scale. Transactional FHIR was designed for retrieving a patient, and many projects attempt to retrieve a population through it. Rate limits, pagination and per-request overhead then turn a simple idea into the wrong architecture.
Conformance is not interoperability
Passing validation says the resource is well formed. It says nothing about whether the element your workflow depends on is populated.
The vendor implementation is not the specification
Resource coverage, search parameters, extensions and operations differ by platform and version.
Transactional APIs used for population work
Pulling a cohort one patient at a time is the most common performance failure in healthcare FHIR projects.
App access with no vetting process
Third-party applications need a review path covering security, data use and support.
Every application solving the same problem again
Without a reusable layer, each application rebuilds authentication, connectivity, patient matching, transformation and error handling.
Regulatory compliance mistaken for capability
Meeting an API obligation produces an endpoint. It does not produce an interoperability capability.
Ask which profile before you ask which resource.
The productive conversation is which implementation guide and profiles both sides conform to, which elements are must-support, which terminology bindings apply, and what happens when an element the workflow needs is absent.
Consuming means adapting to what a platform actually exposes and designing around its limits. Providing means accepting a support obligation, a versioning constraint and a governance responsibility that lasts as long as any consumer depends on it.
Step 1
Establish which side you are on
Consuming, publishing, or both, with the obligations of each made explicit.
Step 2
Define the use case to the element level
Not which resources, but which elements the workflow depends on and what happens when one is missing.
Step 3
Test what the endpoint actually exposes
Resource coverage, search parameters, operations, extensions and populated elements verified against the real system.
Step 4
Choose the pattern
Transactional read, search, bulk export, subscription or application launch, matched to volume and latency.
Step 5
Agree profiles and terminology
Implementation guide, profiles, bindings, must-support elements and extensions.
Step 6
Design identity and consent across the boundary
Define behavior where there is no shared master index and the consumer cannot see your matching logic.
Step 7
Design for the limits
Rate limiting, pagination, timeout, retry and backoff planned against realistic volume.
Step 8
Monitor, govern and deprecate
Usage by consumer, error rates, latency and a working retirement process.
The specification is written for interoperability. The endpoint is written by a vendor.
We test against the actual system before committing to a design, because the difference between what the standard permits and what the platform populates is where FHIR projects lose their schedule.
Standing up an endpoint is the visible work. Conformance, identity across a boundary, throughput design, consumer support, app governance and version lifecycle determine whether it is still working and still changeable in three years.
Consume
Vendor and EHR API Integration
Integration against FHIR and proprietary APIs exposed by EHR and practice management platforms.
Endpoint Capability Assessment
Verified testing of what a given endpoint actually supports and populates, produced before design.
Bulk Data Extraction
Population-scale extraction through bulk export where it exists, with batch orientation and scope constraints designed for.
Publish
Write-Back as a Higher Governance Tier
Stronger identity confidence, user attribution, validation, duplicate prevention, audit trail, failure handling and correction path.
FHIR Server and Facade Implementation
Standing up a FHIR interface over existing systems, with the mapping burden visible up front.
Profiling and Implementation Guides
Profiles, extensions, terminology bindings and a published implementation guide.
SMART on FHIR App Enablement
Application launch, context passing, scope design and the app review process.
Version and Lifecycle Management
Versioning strategy, sandbox, change communication and a deprecation policy with a stated notice period.
Govern and Operate
Identity and Consent Across the Boundary
Patient matching where no shared index exists, consent capture and enforcement, and a defined insufficient-confidence behavior.
API Security
Authorization design, scope granularity, token lifetime, credential management and periodic access review.
Throughput and Resilience
Rate limiting, quota design, caching, pagination strategy and graceful degradation.
Usage Monitoring and Consumer Management
Usage by consumer, error rate, latency and version adoption.
What CaliberFocus does, and does not do.
We will tell you when FHIR is the wrong answer. For bulk historical movement, transactions the X12 estate already handles, or workflows where an existing v2 feed already carries the data, an API is frequently the more expensive route to the same outcome. We will also tell you when you should consume rather than publish.
Most FHIR disappointments trace to one decision: using a transactional pattern for a population job, or an API for something a file already did well.
| Use case | Right pattern | What to design around |
|---|---|---|
| Patient access to their own record | Transactional, patient authorized | Identity proofing, consent, app vetting and a support path for patients whose app breaks. |
| Third-party app launched in the EHR | SMART application launch | Context passing, scope granularity and an app review process that exists before the first request. |
| Care coordination with an external organization | Transactional or document exchange | Identity matching with no shared index, and what happens when confidence is insufficient. |
| Population extraction for analytics | Bulk export | Batch orientation, scope limits and job duration. Never a per-patient loop through a transactional API. |
| Payer data exchange | Transactional and bulk, per obligation | Trading partner variation, and the fact that compliance shape and useful shape are not the same. |
| Feeding a data platform | Bulk export or an existing feed | Frequently the wrong tool. If a v2 or file feed already delivers this, an API is a more expensive route to the same data. |
Regulatory APIs Are a Floor.
Meeting a required API obligation produces an endpoint that satisfies a requirement. That is worth doing and it is not a strategy. Decide whether you are building for compliance or for a genuine partner or application ecosystem, because the design differs.
HL7 v2 fails permissively. A message is usually accepted and the problem appears downstream in a workflow that did not get what it needed. X12 fails strictly. A transaction is rejected outright at a specific point in an acknowledgement chain, and the difficulty is that nobody is reading the response that says so.
| Pattern | Use it for | Limits |
|---|---|---|
| Read and search | Retrieving a known patient or a small result set in an interactive workflow. | Per-request overhead makes it unusable at population scale. Search parameter support varies widely by vendor. |
| Bulk export | Population extraction for analytics, quality and research. | Asynchronous and batch oriented. Scope, job duration and file handling are the design problem, not the request. |
| Write operations | Creating or updating clinical or administrative data in a source system. | The highest-risk surface. Requires stronger identity confidence, validation and a defined behavior on uncertainty. |
| Subscription and events | Reacting to a change without polling. | Support varies considerably. Delivery guarantees, ordering and replay all need designing rather than assuming. |
| Application launch | Third-party or internal applications running in clinical context. | Context passing, scope design and app governance. The technical part is the easy part. |
Design Warning
Where a service combines several underlying systems into one clean response, do not let it hide unresolved disagreement between them. An orchestration layer that quietly picks a winner when two sources conflict has moved the reconciliation problem somewhere nobody can see it.
A must-support element is not a guarantee that data will be there. A workflow built on that assumption will work in testing and fail quietly for the patients where the element is absent.
Profile before mapping
Agree the implementation guide, profiles, extensions and terminology bindings first.
Terminology binding is a maintained asset
Code system versions, value-set bindings and local-to-standard translation change over time and need an owner.
Validate against profiles, not just structure
Structural validity says the JSON is well formed. Profile validation says it conforms to what both parties agreed.
Design for absent elements explicitly
Absent, null and unknown are different states and should not be conflated.
Never match on probability into a clinical write
Where identity confidence is insufficient, refuse and route to review rather than proceed on the most likely candidate.
Preserve provenance through transformation
Retain where data came from, when it was retrieved, what transformation ran and which mapping version applied.
Consent enforced at the API, not in the consumer.
Access decisions belong on your side of the boundary. A consumer application asserting it has consent is not a control.
Authorization, scopes and token handling have established patterns. The harder question is which third-party applications get access to patient data, on what basis, reviewed by whom, and how access is withdrawn.
Access and authorization
- Standards-based authorization with scopes granular enough that an application receives only what its function requires.
- Credential and certificate management with scheduled rotation and no shared credentials across consumers.
- Periodic access review.
Application governance
- Written app review covering security posture, data use, retention, support model and incident contact.
- Named approval authority with clinical, security and compliance input.
- Defined revocation path and a published register of approved applications.
Protection and consent
- Minimum necessary enforced by scope design.
- Patient consent captured and enforced at the API boundary.
- PHI minimization in logs, error payloads and monitoring.
Operations
- Rate limiting and quotas per consumer.
- Usage, error rate, latency, version adoption and downstream completion monitored by consumer.
- Change communication and a deprecation policy with a stated notice period.
You cannot deprecate what you cannot see.
Usage monitoring and a deprecation policy are cheap on day one and effectively impossible to introduce after a dozen partners have integrated against an unversioned endpoint.
The outcome is whether consumers can build against the API without help, whether it holds under load, and whether you can still change it.
| Category | What we measure | Why it matters |
|---|---|---|
| Consumer self-sufficiency | Time from access granted to first successful call, and support tickets per integration. | A specification and sandbox that work show up here immediately. |
| Conformance in practice | Profile validation pass rate and elements expected but not populated, by partner. | The gap between conformant and useful, made countable. |
| Reliability | Error rate, latency at percentile, and availability against a stated commitment. | What a consumer experiences rather than what the platform reports. |
| Scale behaviour | Throughput at peak, rate-limit incidents, and bulk-job completion time. | Where FHIR projects fail, and it is measurable before it becomes a problem. |
| Changeability | Version adoption across consumers and successful deprecations completed. | If you have never retired a version, you cannot change anything. |
| Reuse versus proliferation | Consumers per governed service, services extended versus one-off endpoints, duplicate integrations avoided. | Whether you are building a capability or accumulating another estate. |
| Manual work removed | Re-entry, exports, uploads and swivel-chair workflows eliminated, in staff hours. | Connects API investment to operational value. |
| Governance | Applications reviewed before access, access reviews completed, revocations executed. | The control that matters most and is exercised least. |
Publishing an API is the beginning of an operating cost, not the end of a project.
Budget for consumer support, specification maintenance, version management, app review and the run. If the organization cannot fund the run, consuming rather than publishing is the honest answer.
The first API is frequently not the one being asked for. The requirement is often already met by an existing vendor API, an HL7 event you already receive, a governed data platform feed, a workflow change inside the EHR, or a service you have already built for someone else. Establishing that is part of the work.
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
