FHIR Interoperability: A Buyer Guide
FHIR interoperability is valuable when it makes a defined healthcare workflow easier, safer, or more consistent. Buyers should begin with the information exchange and user decision, then assess profiles, identity, security, testing, and ownership.
What is FHIR interoperability?
FHIR is a standard for representing and exchanging healthcare information through reusable resources and APIs. Interoperability is the larger operating result: the right information reaches the right system and user in a form that can be understood and acted on.
A conformance statement does not prove that two products will work together in a live workflow. Implementations may use different profiles, extensions, terminology, identity models, and security arrangements. The buyer needs to define the exchange that matters before comparing products.
Start with a story. For example, a referral, a medication list, a discharge summary, or a result notification. Document the source, destination, user, timing, minimum data, exception path, and outcome. That story becomes the test case for architecture and procurement.
Start with the workflow: a standard is a means of exchange, not the outcome the buyer is purchasing.
Which interoperability questions should be answered first?
The first questions are about purpose and scope. They stop a project from becoming an open-ended integration programme with no measurable finish line.
Ask each supplier to answer using the same workflow and data examples. A generic product demonstration makes comparison difficult because every vendor chooses its best path.
- What is exchanged? Identify the resources, elements, terminology, attachments, and minimum data set.
- Who uses it? Name the clinician, administrator, patient, analyst, or system that acts on the information.
- When does it arrive? Separate real-time, event-driven, scheduled, and on-demand exchange.
- What happens when data is missing? Define validation, correction, retry, and manual fallback.
- Who owns the interface? Assign the team that supports the connection after launch.
How do profiles and extensions change the buying decision?
Profiles make an implementation more specific by constraining how resources are used. Extensions can carry information that the base resource does not include. These mechanisms are useful, but they also create local implementation choices that must be documented and tested.
Ask for the implementation guide, profile versions, extensions, terminology bindings, and examples that will be used in the project. Confirm how changes are governed. An integration that works only because two teams remember an undocumented local rule is difficult to maintain.
The ONC interoperability resources provide useful context for the wider policy and exchange environment in the United States. Buyers in other jurisdictions should map the same questions to their local rules and infrastructure.
| Scope item | Why it matters | Acceptance evidence |
|---|---|---|
| Resource and profile | Defines the shape and meaning of data. | Validated examples and profile references. |
| Terminology | Controls how codes and values are interpreted. | Value sets, mappings, and error handling. |
| Extension | Carries local or specialised information. | Documented definition and consumer behaviour. |
| Versioning | Prevents silent changes from breaking the exchange. | Change policy, test plan, and release record. |
Identity, consent, and security
Interoperability connects information, so identity and access cannot be treated as afterthoughts. The buyer should know how a person, organisation, patient, device, and application are identified, and how those identities are linked or kept separate.
Consent and purpose matter when data moves across organisations or uses. Document the lawful or authorised purpose, the minimum necessary data, the access decision, and the audit record. The project should make it possible to investigate who accessed what and why.
Security also includes availability and recovery. A workflow should state what happens when the authorisation service is unavailable, a token expires, a message fails validation, or a receiving system is down.
- Identity: define patient, practitioner, organisation, device, and application identifiers.
- Authorisation: map roles and purposes to access decisions.
- Audit: retain useful events and make them available to the responsible team.
- Minimum data: send what the workflow needs, not every field available.
- Recovery: document replay, reconciliation, correction, and manual fallback.
How should an interoperability project be tested?
Testing should use representative examples, not only valid happy paths. Include missing data, duplicate messages, changed identifiers, stale information, invalid codes, delayed responses, and a user who must correct an error. Test the action that follows the exchange, not just the HTTP response.
Use a test catalogue with an owner and an expected result. Keep the source and receiving record so the team can trace what happened. If the workflow is safety-sensitive, include domain reviewers who can judge whether the data is clinically or operationally usable.
After launch, compare interface health with workflow results. A connection can be technically available while users ignore it, data arrives too late, or the wrong information is displayed.
- Define the workflow and minimum data set.
- Agree profiles, terminology, identity, access, and version rules.
- Build normal, exception, correction, and downtime test cases.
- Run end-to-end tests with representative users and systems.
- Monitor both interface events and the outcome of the workflow.
FHIR implementation models compared
There is no single best deployment pattern. The right choice depends on the number of systems, data sensitivity, latency, local skills, and who must support the exchange.
Compare models on the work they create after launch. A central platform may simplify policy and monitoring but add a dependency. Point-to-point interfaces may be fast for one use case but become difficult to govern as connections grow.
| Model | Best fit | Strength | Risk to manage |
|---|---|---|---|
| Direct API exchange | Small number of clear partners | Short path between systems | Connection sprawl and uneven controls |
| Integration platform | Many systems and shared policy | Central monitoring and transformation | Platform dependency and configuration burden |
| Shared data service | Common data access across workflows | Reusable access pattern | Governance and ownership must be explicit |
| Event-based exchange | Timely updates across processes | Decouples producers and consumers | Ordering, replay, and duplicate handling |
What does not matter as much as buyers think?
The word FHIR on a product sheet is not the same as a tested exchange. A long list of supported resources does not prove that the one workflow the organisation needs is usable. A successful connection test does not show whether data is understood by the people who receive it.
The practical signal is a clear implementation contract. It states the data, meaning, timing, identity, security, error path, owner, and change process. That is what keeps interoperability from becoming an attractive integration diagram with no operational home.
One-page buyer worksheet
Use this worksheet for one real exchange, not the whole estate. Write the source, destination, user, resources, profiles, terminology, identity, consent, timing, error path, test cases, owner, and change rule.
Keep the worksheet with the research brief, procurement record, or operating review. It turns a broad market question into a set of checks that can be answered, assigned, and revisited when new evidence arrives.
- Minimum data set and meaning of each field
- Profiles, extensions, and terminology bindings
- Identity, access, consent, and audit requirements
- Normal, missing, duplicate, and delayed-data tests
- Support, reconciliation, and version ownership
FAQ
Is FHIR the same as interoperability?
No. FHIR provides a standard way to represent and exchange information. Interoperability also requires shared meaning, identity, security, workflow fit, and operational ownership.
Should a buyer require every FHIR resource?
No. Start with the resources and elements needed for the defined workflow. Extra scope increases testing and maintenance without automatically improving the result.
What is the most important FHIR procurement document?
The implementation guide or equivalent contract should describe profiles, extensions, terminology, identity, security, examples, error handling, and change rules.
How can FHIR projects fail after technical testing?
Data may arrive too late, lack context, display poorly, use different terminology, or give users no useful action. End-to-end workflow testing catches these gaps.
Who owns an interface after launch?
A named team should own monitoring, support, changes, security review, reconciliation, and communication with the connected organisation.
Bottom line
Need context for a healthcare interoperability project? Read the interoperability buyer guide and digital health market research.