Mapping pulmonary function test (PFT) results to FHIR R4 resources is one of the more technically nuanced challenges in respiratory informatics. Spirometry produces rich, multi-parameter datasets including FEV1, FVC, FEV1/FVC ratio, and flow-volume loop data that do not map cleanly to generic clinical data models. The FHIR Observation resource, specifically the Observation and DiagnosticReport resources in FHIR R4, provides the structural backbone for representing this data in a way that modern EMR integration solutions can consume, query, and act upon. Done well, this mapping enables true clinical data interoperability across respiratory labs, hospital systems, and downstream care providers.

TL;DR

• Spirometry data requires careful mapping to the FHIR R4 Observation resource, with multi-component panels for each measured parameter.

• The DiagnosticReport resource groups individual observations into a coherent, reportable unit for EMR consumption.

• Clinical data standardization using LOINC codes is essential for cross-system interoperability.

• A dedicated implementation guide for PFT FHIR reporting already exists and provides conformance guidance.

• Respiratory lab software that supports FHIR-native output removes the burden of manual mapping from clinical teams.

Why Is Spirometry Data Difficult to Map to FHIR?

Spirometry is not a single measurement. A standard PFT session produces dozens of discrete values across multiple maneuvers, each with a pre-test and post-bronchodilator result, a percent-predicted value, and a z-score. This complexity is what makes clinical data standardization for PFTs harder than, say, a blood pressure reading.

The core challenges include:

• Multiple related parameters per test: FEV1, FVC, FEV1/FVC, PEF, FEF25-75, and more must each be represented as discrete, queryable data points.

• Pre and post-bronchodilator pairs: Each parameter may have two values that must be linked relationally.

• Reference equation dependency: Percent-predicted values change depending on which normal value set was applied (GLI, NHANES, etc.).

• Flow-volume loop data: Waveform data is not easily represented in standard tabular FHIR structures.

What FHIR R4 Resources Are Used for PFT Data?

The FHIR R4 specification provides a layered approach to representing PFT results. According to the HL7 FHIR R4 index, the core resources relevant to spirometry reporting are:

The FHIR Observation resource is the workhorse. Each spirometry parameter is modeled as a separate Observation, with:

• A code element using a LOINC code to identify the measurement type

• A valueQuantity for the numeric result and unit

• A component array for related sub-values (e.g., percent predicted, z-score)

• A derivedFrom or hasMember reference to link pre/post pairs

How Should LOINC Codes Be Applied to Spirometry Parameters?

LOINC codes are the standard vocabulary for clinical data standardization in FHIR. Each spirometry parameter has a corresponding LOINC code that must be applied to the Observation.code element. Common mappings include:

• FEV1: LOINC 20150-9

• FVC: LOINC 19868-9

• FEV1/FVC ratio: LOINC 19926-5

• PEF: LOINC 19935-6

• FEF 25-75%: LOINC 19860-6

Applying the correct LOINC code is what allows EMR integration solutions to identify, filter, and display results without custom parsing logic on the receiving end. Without standardized codes, each system integration becomes a bespoke translation exercise.

What Does a Compliant FHIR PFT Implementation Look Like?

A dedicated FHIR implementation guide for pulmonary function testing already exists. The PFT FHIR Implementation Guide is intentionally designed to provide conformance guidance aligned with reporting standardization efforts, including ATS/ERS recommendations. It covers how to structure the DiagnosticReport, which Observation profiles to use, and how to handle the relationship between pre and post-bronchodilator measurements.

Key structural principles from the guide:

• Use DiagnosticReport.result to reference all component Observation resources

• Use Observation.hasMember to group related parameters (e.g., all pre-BD measurements)

• Include Observation.interpretation to carry ATS-grade severity classifications

• Use Observation.referenceRange to communicate the normal range applied

This level of structure is what enables genuine clinical data interoperability, where a receiving EMR can not only display a value but understand its clinical context automatically.

How Does QDM-to-QI-Core Mapping Affect PFT Reporting?

For organizations operating within quality measurement frameworks, the QDM to QI-Core mapping is relevant. QI-Core profiles constrain FHIR resources for use in electronic clinical quality measures (eCQMs). PFT results represented as QI-Core-compliant Observations can be used directly in population health queries and quality reporting without additional transformation.

This matters for respiratory labs that contribute data to national registries or hospital quality programs. Structuring PFT data correctly from the point of capture means it can serve multiple downstream purposes without rework.

What Role Does the Sending System Play in FHIR Mapping Quality?

The quality of FHIR output is only as good as the system generating it. A respiratory reporting platform that captures discrete, structured data at the point of result entry, rather than storing results as PDF attachments or unstructured text, is the prerequisite for clean FHIR mapping.

This is where platforms like Rezibase become relevant. Rezibase's Magic Import function automatically extracts discrete data from device reports, including flow-volume loops, creating the structured foundation that FHIR mapping requires. Because Rezibase is manufacturer-agnostic, it can receive data from any spirometry device and normalize it into a consistent internal model before outputting to connected EMR systems.

Its integration layer supports connections to EMR systems, Patient Administration Systems, and electronic ordering platforms, making it a practical example of how a purpose-built respiratory solution supports clinical data interoperability without requiring labs to manage the mapping complexity themselves.

Frequently Asked Questions

What is the FHIR Observation resource used for in PFT reporting?
It represents each individual measured parameter, such as FEV1 or FVC, as a discrete, coded, queryable data point with value, unit, and reference range.

Do I need a separate Observation for pre and post-bronchodilator results?
Yes. Pre and post-BD values should be separate Observation instances, linked using Observation.hasMember or derivedFrom references to preserve their relationship.

What LOINC code should I use for FEV1?
LOINC 20150-9 is the standard code for FEV1 measured in litres.

Is there an existing FHIR implementation guide for PFTs?
Yes. The PFT FHIR Implementation Guide at automate-medical.github.io/pft-ig/ provides conformance profiles aligned with ATS/ERS reporting standards.

How does FHIR PFT mapping support quality reporting?
QI-Core-compliant Observation profiles allow PFT data to be consumed directly by eCQM engines for population health and quality measurement without additional transformation.

What happens if my lab software stores results as PDFs?
PDF-based storage cannot be directly mapped to FHIR Observation resources. Discrete data capture at the point of entry is required for compliant FHIR output.

Does Rezibase support FHIR-based EMR integration?
Rezibase supports integration with EMR systems and other hospital platforms, with discrete data capture that supports structured, standardized data exchange.

About Rezibase

Rezibase is Australia's most advanced cloud-based respiratory and sleep reporting platform, built by respiratory scientists for respiratory labs. Trusted by over 35 sites including NHS and NSW Health, it offers manufacturer-agnostic data import, EMR integration, and ATS-aligned reporting in a fully cloud-hosted, no-lock-in model. Learn more at rezibase.com.

Ready to see how structured respiratory data flows seamlessly into your EMR? Visit rezibase.com to explore the platform or start a 30-day free trial.

References

• Automate Medical. PFT FHIR Implementation Guide. https://automate-medical.github.io/pft-ig/

• HL7 International. QDM to QI-Core Mapping. https://build.fhir.org/ig/HL7/fhir-qi-core/qdm-to-qicore.html

• HL7 International. FHIR R4 Index. https://hl7.org/fhir/r4

• eCQI Resource Center. FHIR - Fast Healthcare Interoperability Resources - About. https://ecqi.healthit.gov/fhir/about