FHIR R4 Symptoms Implementation Guide, published by HL7 International / Clinical Interoperability Council. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-symptoms-ig/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
The FHIR Symptoms Logical Model defines the conceptual representation of symptom data, independent of any particular FHIR resource. It specifies the key elements needed to describe symptoms, including onset, severity, course, body site, and qualitative descriptors. This logical model captures the semantics of symptoms and provides a consistent structure for implementers and modelers.
The Symptoms FHIR Profile is the concrete implementation of the logical model in FHIR. It constrains the base Observation resource to represent symptoms in a standardized, interoperable way. This includes specifying required elements, allowed value sets, and recommended patterns for capturing symptom information.
Observation resource, including:
In essence, the FHIR profile operationalizes the logical model, making it actionable and exchangeable in a clinical system.
| Aspect | Logical Model | FHIR Profile |
|---|---|---|
| Purpose | Conceptual representation of symptom data | Standardized implementation in FHIR Observation |
| Scope | Defines elements, relationships, and semantics | Constrains resource elements, cardinality, and terminology bindings |
| Role | Guides what data should be captured | Ensures interoperable exchange and validation |
| Examples | Onset, severity, body site, course | Observation.code, Observation.valueCodeableConcept, Observation.effective[x] |
Use the logical model as the authoritative reference for what symptom data should be captured. Use the FHIR profile to implement these concepts in health IT systems, ensuring interoperability and adherence to terminology standards.
OpenEHR Archetypes are a computable definition, or specification, for a single, discrete clinical concept. It is inclusive of all data elements that make clinical sense about that concept and designed for all imaginable clinical situations. The definition is kept broad and constraints minimal in order to maximise interoperability by being able to share and re-use the archetype across many types of healthcare and the broadest range of clinical scenarios. The specification is expressed in Archetype Definition Language (ADL), which is an ISO standard, but able to be viewed and reviewed in 'clinician-friendly' formats, as structured definitions and mind maps.
Two of the archetypes are included in this guide for further clinical guidance: the Symptom-Sign archetype which correlates to the details of a single episode of a symptom or reported sign in an individual, and the Exclusion Symptom-Sign archetype which records a positive statement that a symptom or sign was not present.
The OpenEHR Archetype is included in this guide as an informative document and an additional source of clinical guidance.