Data Readiness Knowledge Base

Where it fits—and where it doesn’t

Use these four checks before committing implementation time.

Use it when: You need an operational exchange boundary between healthcare systems, an eSource feed, a registry interface, or a clinical-research integration built against a named implementation guide.
Do not use it as: Do not use base FHIR conformance as proof of conformance to a research implementation guide, and do not treat FHIR as an analysis-ready warehouse or submission dataset.
Best for: Interoperability architects, clinical informaticians, integration engineers, and research teams bringing EHR data into a governed workflow.
Maturity: EstablishedFHIR R5 is established as an exchange standard, but R5 is a Standards for Trial Use release and maturity varies by resource, package, and implementation guide.

See it in the workflow

A standard creates value by changing a handoff, not by existing in a catalog.

InputWhat starts
EHR facts such as Patient, Observation, Medication, and Specimen records plus their local codes and provenance
FHIR®What changes
A named FHIR release, implementation guide, profiles, terminology bindings, and API contract
OutputWhat becomes possible
Validated resources that another authorized system can request, interpret, and trace

Readiness gateValidate against the exact profile package and test authorization, terminology, provenance, and downstream information loss—not only base-resource syntax.

A concrete example

An eSource service requests Patient, Observation, Medication, and Specimen resources from an electronic health record, validates them against a pinned research profile, and preserves identifiers and provenance for study review.

Why it matters: Machine-readable resources accelerate ingestion, but analytical features still need cohort, temporal, and terminology normalization.

What it fits with

Profiles constrain resources; ConceptMap bridges terminologies; implementation guides connect FHIR to OMOP and CDISC use cases.

Implementation starter

Start with one bounded handoff. Pin, test, and review it before scaling.

Define one exchange use case and the receiving system's decision before selecting resources.
Choose a named implementation guide; pin the FHIR release plus package and terminology versions.
Select the required resources, profiles, search parameters, extensions, and terminology bindings.
Validate representative examples with the target profile package and test them against the real server contract.
Test authorization, consent, provenance, error handling, and reconciliation as separate operational requirements.
If the data feeds analytics, measure what is lost or transformed when it enters the analytical model.

Limitation to test first—and the tests that catch it

Risk

A payload passes base FHIR validation but fails the named implementation guide or the receiver's contract.

Test

Run profile-specific validation and a round-trip test against the target server using representative extensions, codes, references, and failure cases.

Risk

FHIR resources arrive successfully but cannot support the intended cohort, endpoint, or temporal analysis.

Test

Trace one real analytical question from source record through the FHIR exchange into the downstream model, measuring missing codes, time context, provenance, and cardinality changes.

Why we believe this

Checked against the canonical source plus independent operational evidence from an adopter, regulator, or implementation report.

Evidence notation: E1 + E2. The code is shorthand; the plain-language statement above is the claim.

Formal status: R5 5.0.0 · STU; artifact status varies
Confidence: High
Review state: Source-checked
Reviewed by: Clinical interoperability reviewer
Last verified: 13 July 2026
Review again when: FHIR release or named IG/package update

How the evidence method works

Source shelf

Official diagrams, examples, specifications, and explainers. Nothing external loads until you choose to open it.

Primary sourceR5 · 5.0.0
HL7® FHIR® R5 specification
The canonical R5 specification and entry point to resources, infrastructure, and implementation guidance.
Publisher
HL7
Rights
FHIR® specification content is published under CC0; HL7® and FHIR® trademark terms still apply.
Access
Text-first specification; opens in a new tab.
Verified
2026-07-13
Open at source
DiagramFHIR® R5 · 5.0.0
Patient resource visual
The official visual overview of the Patient resource and its most important relationships.
HL7® FHIR® R5 Patient resourceLocal accessibility preview · canonical asset opens at the publisher
Publisher
HL7
Rights
FHIR® specification content is published under CC0; HL7® and FHIR® trademark terms still apply.
Attribution
HL7® FHIR® R5 Patient resource
Access
A direct source visual; the companion specification card provides the full textual explanation.
Verified
2026-07-13
Open at source
SpecificationFHIR® R5 · 5.0.0
Patient resource specification
Definitions, scope, boundaries, fields, examples, and maturity details for Patient in R5.
Publisher
HL7
Rights
FHIR® specification content is published under CC0; HL7® and FHIR® trademark terms still apply.
Access
Text and tables accompany the official diagram and examples.
Verified
2026-07-13
Open at source
DownloadsFHIR® R5 · 5.0.0
R5 downloads and implementation artifacts
Official definitions, schemas, examples, packages, and publication downloads for implementers.
Publisher
HL7
Rights
Review the license and trademark notice included with each artifact.
Access
Text-first download index; no files download automatically.
Verified
2026-07-13
Open at source

Next action

Put this profile in context

Compare its role with adjacent standards or place it inside an end-to-end data pathway before choosing an implementation.

Compare FHIR®Explore pathways Browse all profiles