HL7 Europe Base/Core IG 2.0.0 evidence

What the new HL7 Europe Base and Core FHIR Implementation Guides look like when they become executable validation evidence.

For: EHDS program teams, FHIR implementers, national infrastructure teams

Why this matters

Published IGs are not the same thing as measurable conformance.

HL7 Europe published Base and Core FHIR Implementation Guides 2.0.0 for both FHIR R4 and R5 on 28 April 2026. The guides define European base and core profiles, extensions, constraints, terminology, and mapping material intended to support EHDS-aligned implementations.

The operational question for implementation teams is narrower: can a system validate actual resources against a pinned version of those profiles, preserve the run configuration, and show the resource, profile, and validation messages together?

That is the evidence surface Records is built to produce. No source clinical payloads are stored; the evidence consists of resource IDs, profile references, issue counts, run metadata, package pins, and reproducibility fingerprints.

The validation lane

A small synthetic EHDS smoke run pinned to the published HL7 Europe packages.

Install the published R4 package

records profile install hl7.fhir.eu.base \  --version 2.0.0 --activate

Validate a bundle against it

records validate-file \  ./ehds-2026-base-laboratory-bundle.json \  --engine --format json

FHIR package	hl7.fhir.eu.base#2.0.0
FHIR release	R4 / 4.0.1
Companion lane	hl7.fhir.eu.base-r5#2.0.0
Fixture source	Synthetic EHDS smoke bundle
Profiles	EU Core Patient, Medical Test Result Observation
Output	Run metadata, issue list, profile-aware resource view

Profiles become visible

The first screen should answer which profile package and profile set were used.

Resources and messages stay together

A useful EHDS evidence screen does not hide validation issues away from the resource that produced them.

Document → section → entry.

Three complete views of the same Patient Summary. The detailed evidence flows remain below.

Document
Check document readiness
Confirm the standard, version, Composition, subject, and resolvable references before reading profile results.
Section
Keep the clinical context
Follow the Composition section and its resolved resources without flattening the document into one entry list.
Entry
Find the failing resource
Scan embedded resources by validation status, then open the selected entry with its field-level findings.

A Patient Summary is a document, not a flat Bundle

The European Patient Summary carries its own ballot version and a clinical-document readiness preflight before any profile validation is read.

Records recognises IPS and European Patient Summary Bundles as clinical documents. Before the profile result is meaningful, the document itself has to hold together: a Composition, a subject, resolvable section references, and the declared document standard and version.

That preflight is shown as its own state. A blocked readiness result is not the same finding as a failed profile constraint, and the two are never merged into a single pass/fail badge.

European Patient Summary with EPS ballot version and a passing exchange-readiness preflight.

Deep dive: document sections

From the Bundle browser through the section index to one invalid SNOMED CT code inside an embedded resource.

The section branch follows the document as a clinician would read it. The Patient Summary opens its structured sections, the Problems section keeps its own narrative, and the referenced Condition is resolved from inside that section rather than from a flat entry list.

Each step opens as an additional pane instead of replacing the previous one, so the document, the section, the selected resource, and the field-level finding stay visible together.

Deep dive: bundle entries and resource selection

The second route through the same document: every embedded resource with its rolled-up validation status, then one selected resource in field context.

Conformance work does not always start from the clinical narrative. The Entries pane lists all embedded resources of the Bundle with their rolled-up validation status, which is the faster route when the question is which resource in the document is failing.

Selecting a resource opens it beside the Entries pane, not on top of it. The validation messages for the selected Condition remain scoped to that embedded resource, so a terminology finding is never read out of its document context.

The run records its reproducibility basis

The relevant evidence is not only pass/fail; it also states whether the measurement context was fully locked or remained provisional.

Records preserves validator identity and configuration, enabled aspects, terminology basis, package context, source, scope, thresholds, timestamp, and environment evidence. A comparison is clean only when the outcome-affecting inputs are compatible and the lock limitations are explicit.

For EHDS work, this is the useful stance today: validate against the published profiles now, keep the evidence, and re-run the same resource scope when HL7 Europe or the implementing acts move the target.