FHIR and API enablement for MedTech, built around the direction that matters to a device company and is the harder half of the standard.
Pulling patient demographics, problems, medications and results out of a modern EHR through FHIR is increasingly routine. Writing a device observation back into the chart is a different proposition: fewer resources are supported for write, vendor implementations vary more, approval is slower, and some systems will not accept external writes at all through that path. A device company whose value depends on getting data into the clinical record is working against the weaker side of the standard, and plans built on read-path experience understate the effort substantially.
Before FHIR, integration required a custom interface specification, an engine, a message format and a project. Now the request is standard and everything around it is not: you still need a contract, a security review, credentials, a tenant registration, a marketplace listing in some cases, an approval from the health system and a scheduled activation by a team with a queue. The engineering became easier, which moved the constraint rather than removing it, and most of the remaining effort is commercial and organizational rather than technical.
The second problem is that publishing your own API turns you into a platform vendor with obligations you may not have priced.
Write support lags read support
Fewer resources, more vendor variation, slower approval, and in some systems no external write path at all.
The friction moved rather than disappeared
Contracts, security reviews, credentials, tenant registration and approvals now dominate the timeline.
Versions coexist indefinitely
R4 and R5 will both be in production across your customers for years, and so will older deployments.
A published API is a product with obligations
Versioning, deprecation, documentation and support, for every customer who built against it.
A valid resource can still be clinically incomplete
An Observation may carry a measurement and lack the patient, encounter, device or order context needed to interpret it.
SMART apps live inside their upgrade cycle
An application embedded in an EHR is affected by their release schedule rather than yours.
Two systems can support FHIR and still fail to exchange useful data. Interoperability requires three things together: technical conformance, semantic accuracy and compatibility with the specific implementation at the other end. Passing schema validation establishes only the first.
A device company serving a real installed base will be writing through FHIR at one customer, HL7 v2 at another and a vendor-specific interface at a third, simultaneously and for years. The architecture that survives treats the standard as an output format behind an internal model rather than as the model itself, so adding a transport is a new adapter rather than a new codebase.
Step 1
Establish what each customer permits you to write before designing anything, since that varies more than the standard does.
Step 2
Keep your internal model separate from the exchange format, so a version change is an adapter change.
Step 3
Design for several transports concurrently, because FHIR, HL7 v2 and vendor interfaces will coexist across your base.
Step 4
Treat a published API as a product, with versioning, deprecation policy, documentation and a support commitment.
Step 5
Plan for R4 and R5 together, since both will be live across customers for years.
Step 6
Handle the authorization model properly, because tokens, scopes and launch contexts differ per vendor and per deployment.
Step 7
Start with the data contract rather than the endpoint, covering resources, profiles, terminology, units, status values and references before any API design.
Step 8
Validate against the customer profile rather than the base specification, since the profile is what will reject you.
Step 9
Design the write failure path, as a rejected resource needs to reach somebody rather than a log.
Step 10
Build conformance testing into the pipeline, so a vendor change is caught by a test rather than by a customer.
Step 11
Agree the regulatory position early, since where the boundary falls shapes the architecture.
Do not let the exchange format become your internal data model. FHIR is a good way to move clinical data between organizations and a poor foundation for a device product. Its resources are shaped by what clinical systems need to share rather than by what your device produces, its versioning is driven by a community you do not control, and adopting it internally propagates every change in the standard into your core. Keeping it at the boundary costs a mapping layer and means a new version, a new profile or a new customer requirement touches one place instead of everything.
HL7 v2 and DICOM are covered on our HL7 and DICOM Integration page, and the per-customer integration economics on our EHR and Clinical System Integration page. These are the FHIR and API specific capabilities.
Map and Write
Resource Mapping
Device output to Observation, DiagnosticReport, Device, ServiceRequest and related resources, mapped against the customer profile rather than the base specification.
Write Path Engineering
Getting device data into the chart, which is the harder direction and the one that determines whether the product delivers value.
Terminology and Coding
LOINC, SNOMED CT and local code sets, with exactness of each mapping stated rather than assumed.
Bulk and Subscription Patterns
Where volume or event-driven delivery suits better than individual resource writes, chosen against what the customer supports.
Build and Secure
API Design and Publication
Your own APIs treated as a product with versioning, deprecation policy, documentation and a stated support commitment.
SMART on FHIR Applications
Applications launched inside the EHR, with the launch context, scopes and upgrade exposure that implies.
Authorization Engineering
OAuth 2.0, SMART scopes, backend services and token lifecycle, which differ by vendor and by deployment.
API Gateway and Access Control
Rate limiting, tenant isolation, credential management and the audit trail each customer will ask for.
Sustain
Conformance and Validation
Testing against customer profiles and capability statements, automated, so a vendor change is caught before a customer reports it.
Version Coexistence
R4 and R5 supported concurrently, since your installed base will not move together and some will not move at all.
Write Failure Handling
Rejected and partially accepted resources routed to somebody who can act rather than accumulating in a log.
Lifecycle and Upgrade Management
Their upgrade schedule tracked, since a SMART application lives inside it and a write path can break without notice.
The third column is the realistic difficulty, which follows from direction and from how willing health systems are to accept external content. Reading is mostly solved. Writing varies from feasible to effectively blocked depending on the customer.
| Exchange | Direction | Realistic difficulty |
|---|---|---|
| Patient demographics and context | Read from the EHR | Low. Well supported, widely enabled and the usual starting point |
| Orders and worklists | Read from the EHR | Low to moderate, and the cleanest basis for patient association |
| Device observations into the chart | Write to the EHR | The hard one. Support, approval and destination all vary by customer |
| Remote monitoring data | Write, usually high volume | Hard. Volume and clinical review workflow both need resolving first |
| Embedded clinical application | Bidirectional, inside the EHR | Moderate technically, with an ongoing dependency on their release cycle |
Use FHIR to standardize the exchange, not to hide differences in clinical meaning. A device-specific measurement forced into an inappropriate resource or terminology mapping purely to appear compliant produces a conformant resource that misrepresents what the device measured, which is worse than an honest extension.
The standard defines a shape and each implementation narrows it. The third column is where to absorb the variation, and anything requiring code rather than configuration is a reason your next customer costs as much as your last.
| What varies | How it varies | Absorb it in |
|---|---|---|
| Version in production | R4 at most sites, R5 emerging, older deployments persisting | Concurrent version support behind one internal model |
| Profiles and constraints | Required elements, cardinality and extensions differ per implementation | A per-customer profile the validator loads rather than hard-coded rules |
| Supported resources and operations | Read widely available, write selective, search parameters inconsistent | Capability statement discovery rather than assumption |
| Authorization model | SMART launch, backend services, scopes and token lifetimes all differ | A pluggable auth layer, since this is where most onboarding time goes |
| Terminology bindings | Local code sets alongside LOINC and SNOMED CT | A mapping table per customer, with exactness recorded |
| Rate limits and quotas | Undocumented, enforced, and discovered in production | Backpressure and retry on your side rather than hope |
A resource accepted with elements silently dropped is the failure mode to design against. An unsupported extension, an unrecognized code, a field outside the profile: in several implementations these do not produce a rejection. The resource is accepted, the response is successful, and the content you considered essential is not in the record. That is worse than a rejection, because a rejection gets investigated and a success does not. Reading back what was written, at least during validation and periodically in production, is the only reliable way to know what actually landed.
Consuming a health system API places you inside their security model, which they define and enforce. Publishing your own places the obligation on you: authentication, authorization, tenant isolation, rate limiting, audit, credential lifecycle and incident response all become yours, for every customer who builds against it. Device companies frequently take on the second without pricing it, because the engineering to expose an endpoint is small and the obligation attached to it is not.
Authorization
- OAuth 2.0 and SMART scopes implemented to the vendor pattern rather than to a generic interpretation
- Token lifetime, refresh and revocation handled, since a stale credential is a silent integration failure
- Backend service authorization separated from user-context launch, as they carry different risk
- Least privilege applied to scopes requested, since broad scopes slow approval and expand exposure
Your published API
- Tenant isolation enforced structurally, because a multi-customer API holds several health systems data
- Versioning and deprecation policy published, since customers will build against it and you cannot break them silently
- Rate limiting and quota design, as an unbounded API is an availability risk to every other customer
- Credential issuance, rotation and revocation operated as a process rather than handled manually
Privacy
- Patient data handled to the obligations your counsel defines, including HIPAA where applicable
- Minimum necessary applied to what you request and what you expose
- Audit trail of access and writes, retained to the obligation rather than to convenience
- Data sharing agreements reflected in what the integration technically permits
Regulatory
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, IEC 62304 and ISO 13485
- Applicability, classification and validation strategy determined by your quality and regulatory functions rather than by us
- Where API output informs a clinical decision, the boundary assessed rather than assumed
- Interface change assessed against device software scope where the integration participates in device function
The only reliable confirmation that a write succeeded as intended is retrieving the resource afterwards and comparing it to what was sent. Acceptance responses report that the server took the request, not that it stored every element, applied the codes you supplied or placed the content where a clinician will find it. Reading back during validation, and on a sample in production, catches the whole category of silent loss that acknowledgments do not.
Write-then-read comparison
Element by element, since partial acceptance is the characteristic FHIR failure.
Conformance against each customer profile
Automated, because the profile is what rejects you and it changes with their upgrades.
Capability statement drift
Since a vendor upgrade can change supported operations without any notice to you.
Authorization failures by type
Expired tokens, scope changes and revoked credentials fail differently and need different responses.
Latency against the clinical window
A write that lands after the decision was made is technically delivered and operationally absent.
Rate limit encounters
Which indicate a ceiling you were not told about and will hit harder as volume grows.
API programmes are usually reported as endpoints delivered and resources supported. The outcomes that matter are whether writes land intact, whether they land somewhere clinical, and whether the next customer is faster to onboard than the last.
| Category | What we measure | Why it matters |
|---|---|---|
| Follow one measurement end to end | What it represents, which resource and profile apply, whether the code and units are right, whether the timestamp is accurate, whether device and patient are identified, whether references resolve, whether the receiver supports the version, profile and operation, whether the application is authorized, and whether it was tested against the actual target | If these cannot be answered the integration is conformant rather than interoperable |
| Write integrity | Elements present on read-back against elements sent | Partial acceptance succeeds and loses content silently |
| Clinical destination | Whether written data lands where a clinician actually works | A write into an unvisited location is a completed integration with no effect |
| Customer onboarding time | Contract to live, including security review and approval | Where the time actually goes, and it is mostly not engineering |
| Scope approval friction | Review duration and questions raised, by scope requested | Narrower requests compound in your favour across the installed base |
| Conformance break detection | Breaks caught by automated testing against breaks reported by a customer | Their upgrade will change something, and who notices first matters |
We will establish what each customer permits you to write and where it lands, test write integrity by reading back, review how much variation is absorbed in configuration rather than code, assess your scope requests against approval friction, and examine whether conformance breaks are caught before customers report them.
CaliberFocus is a MedTech engineering partner delivering FHIR and API enablement for device companies that need their data to reach the clinical record. From write path engineering and per-customer profile validation to SMART on FHIR applications, authorization and published API lifecycle, we build integrations that land intact, land where clinicians work, and make each new customer faster to onboard than the last.
- Write permission and destination confirmed with each customer first
- Exchange format kept at the boundary, with R4 and R5 supported together
- Write-then-read checks that catch silent partial acceptance
- Conformance testing automated against each customer profile
Security & Compliance
