This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0 . For a full list Continuous Integration Build of available versions, see FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions . Page versions: R5 R4B R4 R3

Responsible Owner: Work Group Orders and Observations & Clinical Genomics

Ballot Standards Status : Informative

10.0 Diagnostic Medicine Diagnostics Module

10.0.1 Introduction

The Diagnostics Module provides an overview and guide to the FHIR content that addresses ordering and reporting of clinical diagnostics including laboratory testing, imaging and genomics.

10.0.2 Index

The Diagnostics module covers the following resources:

Observation DiagnosticReport ProcedureRequest DocumentReference

ImagingSelection ImagingStudy ImagingManifest MolecularDefinition Sequence GenomicStudy

ImagingSelection ImagingStudy Specimen BodySite BodyStructure

10.0.3 Related Resources and Modules

The diagnostic resources that represent the basic information about a patient and their relationships a clinical encounter can be found in the Administration Module . Other resources that represent core clinical information generated by healthcare providers during the course of a patient encounter are shown below. detailed in the Clinical Summary Module and the Medications Module .

This conceptual diagram is used to illustrate the common relationships between resources in the diagnostic domain. The arrows represent the direction of the references between resources (for example, DiagnosticReport references ProcedureRequest). Specimen or an Observation). See the Workflow Module for information about the coordination of activities such as ordering and fulfilling of diagnostics. diagnostics using ServiceRequest (exemplified here with a reference) and other request, task, and workflow management resources.

Implementation Note: See the Genomics Implementation Guidance for additional information about how to use the Diagnostic resources for Clinical Genomic Reporting and Analysis.

10.0.3 10.0.4 Security Organizing Related DiagnosticReport and Privacy Observation Resources

Many observations need to be grouped together in some fashion to document the relationships necessary for interpretation of the observations. The methods to do so primarily are through DiagnosticReport using DiagnosticReport.result and Observation using Observation.component, Observation.hasMember, and Observation.derivedFrom. Note that Composition may also be used to organize the content of a diagnostic resources often represent patient-specific data, report (in DiagnosticReport.composition), but that is only for purpose of readability, not to record the relationships necessary for interpretation.

Note: When an observation is not performed and if this needs to be communicated as part of a reporting, the Observation would be used to document that it was not performed and why. The DiagnosticReport would include such observation when that documentation was necessary. For more information see Observation .

10.0.4.1 Laboratory Results

Relationships between observations are susceptible important to data breaching. Necessary privacy understand for the following use cases in particular:

• Microbiology results relating observations on the identification of the organism(s) with observations of the sensitivity results
• Results associated with reflex, repeat, or re-run of tests based on prior result
• Results associated with a follow-up order to a prior order and/or result
• Results associated with an add-on order to the original order

The following describes the recommended approaches on how to use ServiceRequest, Observation, and security provisions must DiagnosticReport to consistently relate the necessary relationships.

10.0.4.1.1 Microbiology

Microbiology reports include the reporting of the overall culture, individually identified organisms and susceptibility results for each identified organism, while reporting additional observations as well such as growth and quantity/rate. The following summarizes the general relationships of the different components using DiagnosticReport and Observation:

This can be more specifically described in place when searching the following diagram identifying the specific resources and fetching this information. attributes used to create the relationships using a sample anaerobic culture as the basis for these relationships:

A DiagnosticReport is created using DiagnosticReport.basedOn to reference the ServiceRequest that authorized its performance.

The initial observation of a the sample anaerobic culture would be recorded as an Observation and linked to using DiagnosticReport.result. The Observation would describe presence of none, one or more growths or patterns. Other results for, e.g., a stain may be reported as well and linked to DiagnosticReport.result.

As the growth is identified, an Observation to report the actual organism is created. The actual identification may take time and could change. The change history on the Observation will track any changes in organism names. Thus the Observation.value may start as unknown and then be updated to reflect the actual identified name. The Observation of the initial anaerobic culture references each identified organism using Observation.hasMember, while the Observation of each organism references the initial ServiceRequest that authorized the tests using Observation.basedOn.

Specific observations on each individual organism, e.g., growth and quantity/rate, are recorded as separate Observation instances where the Observation of the organism identification links to these observations using Observation.hasMember.

When susceptibility tests are starting to be performed, an Observation instance is created for the Susceptibility Panel, enabling all susceptibility tests to be organized under that Susceptibility Panel. The Susceptibility Panel Observation is also linked to through the Obervation.hasMember of the identified organism Observation.

If a new authorization is required:

• A new ServiceRequest is created which is basedOn the original ServiceRequest; and
• Observation.basedOn points to the new ServiceRequest

The individual susceptibility observations are linked to the Susceptibility Panel by the Observation.hasMember on the Susceptibility Panel Observation.

All Observations either reference the overall Specimen or a Specimen Isolate as appropriate. The Specimen Isolate references the Specimen it was isolated from using Specimen.parent.

Note that as an Observation is updated, the Observation.id remains the same, but if for some reason a replacement needs to be recorded, the Observation.id changes while the Observation.identifier can remain the same. For observations documenting the progression of identifying the organism, use of a change history is recommended, thus keeping the Observation.id the same.

10.0.4.1.2 Policy Driven Additional Testing

Additional testing may be performed based on actual test results, e.g., abnormal results, based on established policies, thus not requiring a new order to be placed. The original order must have associated policies to permit the immediate order of subsequent tests based on specific results. That means that from an ordering provider perspective there is no need to submit a new order (ServiceRequest) for such subsequent testing. However, the laboratory may utilize ServiceRequests for any of these tests where it needs to interact with a reference laboratory for such subsequent testing.

The different types of policy driven additional testing can be:

• Reflex – performance of one or more general considerations, see other tests depending on the Security results of the initial test. This may include collection of additional specimen(s)
• Repeat (per policy) – performance of the same test again with the same parameters/settings/solution
• Re-run (per policy) – performance of the same test but with different parameters/settings/solution

The DiagnosticReport includes both the initial and Privacy module . additional tests, using the DiagnosticReport.result attribute.

The Observation.triggeredBy on the additional observation(s) will be valued to the appropriate type (reflex, repeat, or re-run) and reference the Observation that it is additional to. The Observation.basedOn contains the link to the original ServiceRequest that authorized the performance of the additional tests, and may also point to another ServiceRequest that was necessary to communicate authorization to a reference lab.

Some may opt to report the additional observations in either a separate DiagnosticReport or the original/initial DiagnosticReport. The additional DiagnosticReport must then also be linked to the original ServiceRequest using DiagnosticReport.basedOn. Note though that the additional observations are then only referenced in the additional DiagnosticReport, not the original DiagnosticReport. The additional DiagnosticReport still may include the original observations that triggered the additional tests.

10.0.4.1.3 Follow-Up Orders/Results

Follow-up orders are individual requests outside established policy, not authorized through the original order, based on the results of a prior test to perform further test(s). There may be reasons that this only requires a change/correction to the original ServiceRequest (until any change/correction is not permitted as the processing has progressed too far), or require a new ServiceRequest. This may depend on whether the additional test can be charged or not. It furthermore depends on whether the original ordering system permits that ServiceRequest to be changed. The intent may also be that the original result is amended/appended rather than that a separate, new result is reported. This yields the need for either an update to the original ServiceRequest or a new ServiceRequest.

• Demographic or AOE response change/correction - no re-performance of the test, only new interpretation.
• Repeat Determination/Re-evaluation - that may be questioning the original result and needing a re-evaluation that may result in re-run. Include prior specimen number.
• Confirmation/Validation – May be re-run or validation. A re-run out of policy.

This can be mostly handled using the existing ServiceRequest capabilities. We leave it up to future initiatives to establish appropriate reasons to enable managing any fulfillment of these requests.

Diagnostic reports do not specifically reflect these orders and might or might not include them in one or more DiagnosticReport instances.

10.0.4.1.4 Add-On Orders/Results

When ordering a test involves a specimen, the common understanding is that either a new specimen is drawn or specimen collection is optimized to minimize draws where permitted/appropriate by policy. However, if the ordering provider wants to explicitly use an already existing specimen or a still to be drawn specimen, then an add-on order is placed. The intended specimen to use is either indicated explicitly by directly referencing the specimen to be used, or contextually based on the ServiceRequest for which the specimen of interest has been or is about to be collected. The servicerequest-specimenSuggestion extension can indicate either of these scenarios, including a fallBackAction in that extension.

Conversely, an ordering provider may indicate explicitly to use a new, separate specimen rather than using any available or about to be drawn specimen where policy otherwise may push for the optimization of specimen draws reducing sticking the patient twice. That is not considered an add-on order. But still can be indicated.

Either way, the DiagnosticReport would include test results as per normal without any specific relationships between the observations.

10.0.4.2 Imaging

10.0.4.2.1 Representation of DICOM SR measurements using FHIR resources

DICOM® Structured Report (DICOM® SR) is a standard for recording clinical imaging observations made regarding a diagnostic or interventional imaging procedure. Imaging Observations are made by humans, such as a sonographer making measurements on recently acquired ultrasound image, a Radiologist recording observations on suspected lesions, or by a machine, such as an automated AI Algorithm providing qualitative and quantitative observations.

The standards for recording clinical observations, DICOM® SR and HL7 FHIR Observation resource are bridged by the DICOM SR IG by the transformation of the DICOM SR attributes to the HL7 FHIR Observation Resource.

Example use cases:

• Extracting imaging results for use in reporting.
• Extracting imaging results for FHIRcast content sharing.

DICOM SR mapping to FHIR is limited to the Observation resource and a small set of related resources. The resultant mapping is provided, as a minimum, a composition or bundle of Observations. Depending on the use case, the observations may be part of or contained in a Diagnostic Report. Use case-specific requirements to construct a diagnostic report(e.g., Mammography) may require the transformation described in the DICOM SR IG. However, the detailed elaboration of those use cases are not in scope in that IG or here in the Diagnostics module.

The mapping of the core DICOM SR measurement groups, measurements and qualitative analysis content items are covered by the Observation resource profiles, representing various measurements related DICOM SR templates. The Observation resource profiles depend on number of ImagingSelection resource profiles, as shown in Figure 3. FindingSite profiles the BodyStructure resource representing a finding site content item from the DICOM SR templates.

10.0.4 10.0.5 Common Use Cases

Diagnostic resources are commonly used to plan, recommend, order and report clinical diagnostics:

NOTE: Other diagnostic resources can be used for associating related specimen or body site .

• Planning a diagnostic test such as in this Careplan-example
• Recommending diagnostics such as is done by Clinical Decision Support tools. See the Clinical Reasoning module for more information.
• Ordering a Laboratory Test such as a lipid panel
• Reporting a Laboratory Test such as a lipid panel
• Ordering an imaging study such as a CT study
• Reporting an imaging study such as a CT study
Ordering a genetic test such as a gene mutation analysis Reporting a genetic test such as HLA genotyping

There are many ways to use these resources independently as well. The Observation resource resource, in particular particular, is central to capturing many measurements and events in healthcare and is often used outside the context of diagnostic orders and reports.

• recording vital signs such as temperature , blood pressure , respiratory rate , heart rate
• recording other observations of a patient's social history such as tobacco use
• recording other characteristics of a patient such as pregnancy status (note: The Condition resource may be used to represent these as well)
• recording clinical assessment tool scores such as an Apgar score .
identifying and describing a specimen

or body site

10.0.6 Security and Privacy

The diagnostic resources often represent patient-specific data, and as such are susceptible to data breaching. Necessary privacy and security provisions must be in place when searching and fetching this information. For more general considerations, see the Security and Privacy module .

10.0.5 10.0.7 Related Resources and Modules

The resources that represent the basic information about a patient and a clinical encounter can be found in the Administration Module . Other resources that represent core clinical information generated by healthcare providers during the course of a patient encounter are detailed in the Clinical Summary Module and the Medications Module .

10.0.6 10.0.8 Developmental Roadmap

• The Observation and Diagnostic Report resources have resource has been tested and used in production tooling and as such have reached a maturity level FMM=4 where changes become less likely and require implementer community approval. is Normative. Any further development will follow the rules for Normative resources. Future work will focus on developing core profiles and clarifying use cases and boundaries and providing more domain specific examples. We anticipate Observation and Diagnostic Report reaching normative status by the end of this cycle.
• The ImagingStudy DocumentReference resource has had some limited testing been tested and use. Further use of this resource used in production tooling in order for it to reach a more stable FMM level. ImagingManifest : We expect to see more widespread use of this resource and future updates to its FMM has reached maturity level FMM=4.
• The ProcedureRequest DiagnosticReport resources resource has undergone substantial changes since DSTU2. Foremost of which is the merging of DSTU2 DiagnosticOrder been tested and ProcedureRequest into a single resources. In addition, as a result of the addition of FHIR workflow for STU3, its structure used in production tooling and content have been updated has reached maturity level FMM=3. Future work will focus on further refinements to align with the general FHIR workflow "request" pattern. Because of these, it remains a relatively immature resource. No more sweeping changes to its structure are expected. However, its scope resource, as well as developing core profiles and boundaries vis a vis other resources will be the topic of future workgroup efforts. We anticipate its broad clarifying use by implementers cases and that it will mature as a resource throught the upcoming cycle. boundaries and providing more domain specific examples.
• The Specimen resource will be the is expected to undergo further development as a focus of ongoing work group efforts for the upcoming cycle. A new SpecimenDefinition resource is planned for describing specimen types vs specimen instances and will take over some of the Specimen resourc'e's current scope. efforts. We expect to see more widespread use of this resource and future updates which will help to increase its FMM level maturity(currently at FMM=2).
• The Sequence ImagingStudy resource remains draft has been tested and we expect to see more widespread use of this resource used in production tooling and future updates to its FMM has reached maturity level FMM=4.
• The BodySite ImagingSelection resource is an relatively immature at FMM=1 (added in R5). We are looking for implementer feedback to advance its maturity.
• The MolecularDefinition resource with is replacing MolecularSequence. It includes definitional content for a FMM level of 1. To date there has been little implementation feedback. molecular entity, such as a nucleotide or protein sequence. This resource is an Additional Resource .
• The Media GenomicStudy resource is the newest member was introduced in R5. It represents a set of analyses performed to the Diagnostics module having undergone substantial scope analyze and structural changes generate genomic data and is at FMM=1. Further use of this resource in production tooling is needed for it to create an specialized observation reach a more stable FMM level.
• The BodyStructure resource focused is relatively immature at FMM=1. Changes have been made to support greater precision of body location identification based on digital media such as images feedback that has been received, and audio files. Future work we expect to receive additional implementation feedback which will focus on developing core profiles and providing more domain specific examples. help increase the resource maturity level.