FHIR's Observation resource identifies what was measured via a LOINC code, classifies it broadly via category, and represents the actual result through a type-specific value[x] field (valueQuantity, valueString, valueCodeableConcept). Panel tests use the component array to hold multiple related results under one parent Observation, with referenceRange and interpretation flagging abnormal values. Mapping from HL7 v2 is the main practical challenge: OBX segments don't map one-to-one, LOINC usage is inconsistent across source systems, non-numeric results need careful value-type handling, and OBX-7 reference ranges need explicit parsing into FHIR's structured referenceRange element.
Quick answer
The FHIR Observation resource covers an unusually broad range of clinical data for a single resource type, spanning lab results, vital signs, and clinical assessments alike, which means understanding its flexible structure matters more than for most other FHIR resources you'll encounter. Getting Observation right means understanding how LOINC coding identifies what was measured, how different value types represent different kinds of results, and how the component element handles multi-part panel results correctly.
Below is how Observation's coding and value structure actually works, how panel results and reference ranges are handled, and the practical mapping challenges that come from HL7 v2 source data. If you're mapping lab or vitals data into FHIR, our free Mirth Health Check can review your specific mapping approach directly — part of the Mirth Connect support work we do for US healthcare teams.
How Observation's Coding and Value Structure Works
Every Observation needs to clearly identify what was measured and what the result actually was, and FHIR handles both through a consistent but flexible structural pattern.
LOINC Codes Identify Exactly What Was Measured
The code element typically carries a LOINC code identifying the specific test or measurement, the same coding system used in HL7 v2's OBX-3 field, giving receiving systems a standardized way to interpret what the observation represents.
Category Distinguishes Broad Observation Types
The category element classifies observations broadly, such as laboratory, vital-signs, or social-history, letting consuming applications filter and organize observations by general type before examining the specific LOINC code involved.
Value[x] Represents the Actual Result Differently by Type
Depending on the nature of the result, the value is captured through valueQuantity for numeric measurements, valueString for text results, or valueCodeableConcept for coded results like positive or negative findings.
Status Indicates Whether a Result Is Final or Preliminary
The status field indicates whether an observation is preliminary, final, amended, or in another state, which matters significantly for clinical decision-making that shouldn't act on a result that hasn't yet been finalized.
How Panel Results and Reference Ranges Are Handled
Many lab tests aren't single values but panels containing multiple related results, and FHIR's component structure handles this common pattern specifically.
Component Elements for Multi-Part Panel Results
A complete blood count or metabolic panel uses the component array to hold multiple individual result values under one parent Observation, each component carrying its own code and value rather than creating separate top-level resources.
ReferenceRange Provides Normal Value Context
The referenceRange element specifies the expected normal range for a given result, letting consuming applications flag abnormal values appropriately without needing separate business logic to determine what counts as normal for that specific test.
Interpretation Flags Abnormal Results Explicitly
Beyond the raw reference range, the interpretation element can explicitly flag a result as high, low, critical, or normal, giving downstream systems a direct signal rather than requiring them to calculate abnormality themselves.
Effective[x] Captures When the Observation Actually Occurred
The effectiveDateTime or effectivePeriod field captures when the observation was actually taken or performed, which is distinct from when the resource itself was created or last updated in the system.
Mapping Challenges From HL7 v2 Source Data
Since much of the underlying lab and vitals data still originates from HL7 v2 systems, mapping that data correctly into FHIR Observation resources involves specific, recurring challenges worth understanding upfront.
OBX Segments Don't Map One-to-One With Observations
A single HL7 v2 ORU message can contain multiple OBX segments that need careful grouping logic to correctly become either separate Observation resources or components within one panel-based Observation.
Inconsistent LOINC Usage in Source Systems
Not every source system consistently populates LOINC codes in their HL7 v2 messages, sometimes using proprietary codes instead, requiring a mapping or terminology service layer to translate into standardized LOINC for the FHIR side.
Handling Non-Numeric and Free-Text Results Correctly
Results that arrive as free text or non-standard values in HL7 v2 need careful handling to map into the appropriate FHIR value type, since forcing a text result into valueQuantity would produce an invalid resource.
Preserving Reference Ranges During the Translation
HL7 v2's OBX-7 reference range field needs to be correctly parsed and mapped into FHIR's structured referenceRange element, since a naive text copy loses the structured low and high boundary values FHIR expects.
When to call for help
If your OBX-to-Observation mapping is producing inconsistent results, the cause is usually one of the four mapping challenges above showing up in production data your test messages didn't cover. Our free Mirth Connect health check reviews your mapping approach as part of the standard diagnostic.
Troubleshooting something specific? Send us the log, or check pricing for our support plans.
Mapping lab or vitals data into FHIR? Free Mirth health check — a written 12-point audit report in 48 hours, no cost.