Why Science? | HL7 FHIR and Structured Health Data Exchange

Science learning becomes powerful when students can tell a measured pattern from a model, a statistical decision from a mechanism, and a useful lead from a finished conclusion. FHIR—Fast Healthcare Interoperability Resources—is an HL7 standard for exchanging healthcare information electronically. The official publication directory identifies FHIR R5, version 5.0.0 published on 26 March 2023, as the current published major release while the R6 sequence remains work in progress in 2026. FHIR organises information into typed resources with stable identities, references, terminology, profiles and several exchange patterns, including a RESTful API. Conformance to a resource schema does not make data clinically correct, consented, complete or safe to disclose; version, implementation guide, terminology, provenance and security controls remain essential. This guide supports Primary Science, PSLE Science, Secondary Science, O-Level Science and STEM education as a longform evidence-reading route; it is not medical advice, a laboratory protocol, an admission promise or a career guarantee.

Related eduKate reading: GA4GH Phenopackets and computable case representation; PhenoTips and structured genomic health records; GA4GH Service Info and self-describing APIs; GA4GH Data Connect and federated dataset queries; Science Learning Hub; Education Hub; STEM Education; Careers by Subject Capability.

Primary and official sources checked on 12 October 2026: HL7 official FHIR R5 specification, current published version, checked 12 October 2026; HL7 official FHIR publication directory, including the R6 work sequence, checked 12 October 2026; HL7 official FHIR R5 RESTful API specification, checked 12 October 2026; HL7 official FHIR R5 security and privacy module, checked 12 October 2026; 2026 Singapore–Cambridge O-Level Biology syllabus; MOE G2/G3 Lower Secondary Science teaching and learning syllabus; 2026 MOE G2 Computing syllabus. Standards, terminologies, implementation guides, tools and recommendations can change, so preserve dated documentation, exact source data and software versions.

A deeper reading route

Health information moves among people, laboratories, imaging systems, pharmacies, clinics, public-health services and research environments. Each system can use different local tables and labels. FHIR provides a shared resource model so a patient, observation, medication, diagnostic report or encounter can be represented with defined fields and linked to related resources instead of being flattened into one ambiguous message.

The current published FHIR specification is R5, version 5.0.0. The official directory also lists an R6 development sequence and snapshots in 2026. A development snapshot is not interchangeable with a published release. Every implementation should pin its base FHIR version and the package versions for the implementation guides and extensions it actually uses.

A FHIR resource has a resource type, elements and an identity. References connect resources, while narrative text can help humans understand a record. JSON, XML and RDF representations are possible under the specification. A valid JSON object is not automatically a valid FHIR resource, and a valid resource is not automatically a faithful account of the patient or event.

The RESTful API describes interactions such as read, search, create, update and history over resource collections. Servers publish CapabilityStatement information about what they support. Clients should not assume that every server implements every resource, search parameter, operation or profile merely because all are present in the base specification.

Profiles constrain or extend base resources for a particular jurisdiction or use case. Cardinalities, fixed values, required bindings and slices can turn a flexible base into an implementable contract. Extensions are a governed mechanism, not an invitation to put every local field into an undocumented structure. Reuse a shared extension where one fits and publish canonical definitions.

Terminology gives coded elements their intended meaning. A code should travel with its system and, where relevant, version and display. Value-set membership can change. Mapping a local code to SNOMED CT, LOINC or another system is an interpretation that needs governance and tests; it should not erase the original value or uncertainty.

Provenance, audit and consent are related but distinct. Provenance describes origins and transformations; audit records security-relevant events; consent can represent permissions or directives. The official security module says FHIR supplies building blocks rather than one mandatory security architecture. Authentication, authorisation, encryption, policy and monitoring must be implemented around the data exchange.

Bundles group resources for transactions, documents, messages, search results or collections. Bundle type changes processing rules. A document bundle starts with a Composition and is treated as a coherent attested statement, while a transaction asks a server to perform entries atomically. Software must read type and rules rather than treat every Bundle as a generic folder.

A practical audit follows one observation from source measurement through coding, resource construction, profile validation, API exchange and receiving-system display. It checks subject, performer, time, value, unit, method, reference range, status, terminology, provenance and access decision. This reveals whether technical success preserved clinical meaning.

The optimistic value is controlled interoperability. FHIR gives clinicians, patients, researchers and software teams a shared way to describe and move information. Its openness makes testing and innovation easier; careful profiles, validation, governance and privacy keep that flexibility from becoming silent semantic drift.

Search semantics need particular care. A server may support only selected parameters, modifiers, chained searches or includes. Pagination and total counts can behave differently. Record the complete query, headers, server capability and continuation links, then verify that the returned cohort matches a small known fixture before relying on a large export.

Conditional create and update can reduce duplicates only when search criteria truly express identity. Two records that look alike may represent different observations, while two differently formatted identifiers may refer to one event. Implement deterministic matching rules, preserve merge history and route ambiguous cases to review.

Canonical URLs identify reusable definitions such as profiles, value sets and implementation guides. The URL can remain stable while version changes. Store both canonical and version when reproducibility matters, and prevent a package resolver from silently substituting a newer artifact during validation.

Reference integrity extends beyond syntax. A specimen reference should resolve to the specimen that produced the observation; an encounter reference should represent the correct care context. Referential checks, subject-consistency checks and temporal checks reveal coherent JSON that tells an impossible story.

Bulk exchange deserves separate controls. Large exports can amplify privacy risk, server load and version drift. Define authorisation scope, export time, file manifests, checksums, deletion rules and restart behaviour. A successful download should still be reconciled against the server snapshot and requested resource types.

Error handling is part of interoperability. OperationOutcome can describe issues, but clients must preserve severity, diagnostics and location without showing sensitive details to unauthorised users. Tests should include invalid codes, missing references, conflicts, expired credentials and partial downstream outages.

A migration between FHIR releases is a semantic project, not a text substitution. Compare changed resources, elements, datatypes and terminology bindings; transform into a new copy; validate both sides; and retain a mapping receipt. If an element has no safe equivalent, preserve the exception rather than inventing compatibility.

Patient-facing access benefits from plain-language presentation, but simplification should not alter status or certainty. Show when a result is preliminary, corrected or outside its reference context, and provide the source organisation and date. Accessibility and translation should sit beside the structured resource, not rewrite it silently.

A four-step claim ladder for this method

Stage	Question	Evidence	Responsible output
Represent	What kind of health fact or workflow item is this?	Resource type, elements, identifiers and status	A structured resource
Constrain	Which local or national contract applies?	FHIR version, profile, extension and terminology bindings	An implementable data contract
Exchange	How does information move?	REST interaction, Bundle type, server capability and authentication	A controlled transfer
Verify	What claim is justified?	Source record, validation, provenance, consent and clinical review	A bounded interoperable result