Fast Healthcare Interoperability Resources

FHIR organizes exchange into resources

FHIR represents useful healthcare concepts as modular resources. Examples include a Patient, Practitioner, Organization, Appointment, Observation, Condition, CarePlan, Claim, or Coverage. Resources have defined elements and can reference one another.

An API can let an authorized system search, read, create, or update resources. The API is the route. The resource is the structured content. Neither term proves that two organizations interpret the data the same way.

The official HL7 FHIR specification contains the base resources, data types, API patterns, terminology links, conformance artifacts, and implementation guidance. ASTP/ONC describes FHIR as a widely used, API-focused standard built from modular resources.

Profiles narrow the base standard

FHIR is designed for many settings and leaves choices. A profile constrains a resource for a use case by setting required elements, allowed values, terminology bindings, and other rules. An implementation guide brings profiles, examples, operations, and workflow expectations together.

Two systems can both say they support FHIR while using different versions, profiles, code systems, extensions, search parameters, or business rules. Record the exact FHIR release, implementation-guide version, profile canonical URL, terminology version, and trading partner.

Version and maturity matter

HL7's FHIR version-management page explains that implementers must manage specification and software versions. R5 is the current permanently published release, while many deployed programs still use earlier releases or named implementation guides.

Do not convert data between versions by changing a version label. Elements, cardinality, codes, extensions, and behavior may differ. Define supported versions, conversion ownership, rejected-content handling, and tests for every exchange.

FHIR does not guarantee interoperability

Interoperability requires at least five kinds of fit:

• technical: connections, authentication, formats, limits, and error handling work
• syntactic: the resource follows the agreed structure and profile
• semantic: both parties preserve the same meaning and terminology
• workflow: the message arrives at the right time and prompts the right action
• governance: authority, privacy, security, retention, provenance, and accountability are clear

A valid resource can still identify the wrong client, use an obsolete authorization period, omit a clinically important qualifier, or enter a queue nobody monitors.

Treat identifiers and terminology as governed data

Patient, practitioner, organization, location, payer, plan, and authorization identifiers come from particular assigning systems. Store the namespace with the value and define matching, merge, correction, and conflict rules. A number that is unique inside one database may collide when data crosses organizations.

Terminology needs the same care. Record the code system, version, display, mapping owner, and handling for unknown or retired codes. Preserve the source value when transforming data. A local service label should not be silently converted into a clinical diagnosis, billing code, or authorization status. Test whether every required extension and qualifier survives a round trip, including nulls and explicit statements that information is unknown.

A fictional ABA exchange

Elliott's practice pilots 30 fictional Appointment resources from a referral partner. Twenty-seven pass identity matching, profile validation, code mapping, timezone, status, ownership, and workflow-acceptance checks: 27 of 30, or 90%.

One resource uses an unknown location code. One has a timezone mismatch. One passes syntax but creates no staff task. All three remain held with an error artifact and owner. The ratio measures this test cohort's acceptance, not interoperability across clients, partners, or future versions.

Build a source-to-action contract

For each interface, specify:

• sender, receiver, endpoint, environment, and accountable owners
• resource, profile, version, terminology, identifiers, and required fields
• authentication, authorization, consent or disclosure route, and minimum data
• event or schedule, idempotency rule, retry, timeout, and duplicate handling
• validation, error response, reconciliation, monitoring, and escalation
• clinical or operational action, qualified decision-maker, and safe failure path

Keep provenance. Staff should be able to see the source, received time, transformation, and current status. A correction in one system needs an explicit route to the other.

Test meaning and operations

Use fictional or properly authorized test data. Include missing, duplicate, late, corrected, revoked, mismatched, and out-of-order cases. Compare source and destination values, then observe the downstream workflow.

Measure resources accepted by the declared gate divided by resources due for review. Report holds by reason and age. Separate API availability, profile validity, semantic agreement, workflow completion, and eventual business outcome.

Security and privacy remain separate duties. Protect endpoints, tokens, logs, payloads, support access, and stored copies. Confirm what each party may send, receive, use, retain, and disclose. FHIR capability alone supplies none of those permissions.

Before release, require the trading partners to sign off on the exact specification, profile, terminology, identifier, error, reconciliation, and workflow contract. Retest after any version, mapping, endpoint, or downstream-action change.