FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

Work Group Orders and Observations icon & Clinical Genomics icon Standards Status: Informative

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.

The Diagnostics module covers the following resources:

The diagnostic resources and their relationships are shown below. The arrows represent the direction of the references between resources (for example, DiagnosticReport references ServiceRequest). See the Workflow Module for information about the coordination of activities such as ordering and fulfilling of diagnostics.

Image showing the diagnostic resources

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

Name Aliases Description
ObservationVital Signs, Measurement, ResultsMeasurements and simple assertions made about a patient, device or other subject.
DiagnosticReportReport, Test, Result, Results, LabsThe findings and interpretation of diagnostic tests performed on patients, groups of patients, products, substances, devices, and locations, and/or specimens derived from these. The report includes clinical context such as requesting provider information, and some mix of atomic results, images, textual and coded interpretations, and formatted representation of diagnostic reports. The report also includes non-clinical context such as batch analysis and stability reporting of products and substances.
ServiceRequestdiagnostic request, referral, referral requestA record of a request for service such as diagnostic investigations, treatments, or operations to be performed.
Media(Not defined yet)
ImagingSelectionA selection of DICOM SOP instances and/or frames within a single Study and Series. This might include additional specifics such as an image region, an Observation UID or a Segmentation Number, allowing linkage to an Observation Resource or transferring this information along with the ImagingStudy Resource.
ImagingStudyRepresentation of the content produced in a DICOM imaging study. A study comprises a set of series, each of which includes a set of Service-Object Pair Instances (SOP Instances - images or other data) acquired or produced in a common context. A series is of only one modality (e.g. X-ray, CT, MR, ultrasound), but a study may have multiple series of different modalities.
MolecularSequenceRepresentation of a molecular sequence.
SpecimenA sample to be used for analysis.
BodyStructureanatomical locationRecord details about an anatomical structure. This resource may be used when a coded concept does not provide the necessary detail needed for the use case.

Many observations need to be grouped together in some fashion to document critical relationships 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 observations and diagnostic reports, but that is only for purpose of readability, not to record critical relationships for interpretations. See DiagnosticReport.composition and Composition for further considerations for that separate purpose.

Relationships between observations are important to 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 orders 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 DiagnosticReport to consistently relate the necessary relationships.

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:

Micro Isolate and Susceptibility structure 1

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

Micro Isolate and Susceptibility structure 2

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 well.

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 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 was needed to perform the susceptibility panel as sometimes the overall ServiceRequest covers it, and other times a new authorization is required, the Susceptibility Panel Observation.basedOn will reference the appropriate ServiceRequest, while, if present, the Susceptibility Panel ServiceRequest.basedOn will reference the initial 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 reference 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.

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 other tests depending on the 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
Micro Isolate and Susceptibility structure 3

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

The Observation.triggeredBy on the additional observation(s) will be valued to the appropriate type (reflect, 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.

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 DiagnosticReport instances.

When ordering a test involves a specimen, the common understanding is that either a new specimen is drawn or by policy specimen collection is optimized to minimize draws where permitted/appropriate. 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 (ServiceRequest.extension-specimenSuggestion references the specific Specimen to be used), or contextually based on the ServiceRequest for which the specimen of interest has been or is about to be collected (serviceRequest.extension-specimenSuggestion references the specific ServiceRequest for which a specimen has been or is about to be collected). One must then also have indicated 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 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.

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.

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

There are many ways to use these resources independently as well. The Observation resource, in 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
  • 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

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.

  • The Observation resource has been tested and used in production tooling and 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.
  • The DocumentReference and ImagingStudy resources have been tested and used in production tooling and have reached maturity level FMM=4.
  • The DiagnosticReport resource has been tested and used in production tooling and has reached maturity level FMM=3. Future work will focus on further refinements to the resource, as well as developing core profiles and clarifying use cases and boundaries and providing more domain specific examples.
  • The ServiceRequest resource had relatively significant changes leading up to the R4 release, and is still relatively immature at FMM=2. We anticipate that future work could lead to further refinements in the scope and boundaries. We anticipate its broad use by implementers which will help to increase its maturity level.
  • The Specimen resource is expected to undergo further development as a focus of ongoing work group efforts. We expect to see more widespread use of this resource which will help to increase its maturity.
  • The ImagingSelection resource is relatively immature at FMM=1 and has been added for R5. We are looking for implementer feedback to advance its maturity.
  • The MolecularSequence resource has had some limited testing and use. Changes have been made to improve the ability to represent sequences in various ways. It remains at FMM=1.
  • The GenomicStudy resource was introduced in R5. It represents a set of analyses performed to analyze and generate genomic data and is at FMM=1. Further use of this resource in production tooling is needed for it to reach a more stable FMM level.
  • The BodyStructure resource is relatively immature at FMM=1. Changes have been made to support greater precision of body location identification based on feedback that has been received, and we expect to receive additional implementation feedback which will help increase the resource maturity level.