FHIR CI-Build
DiagnosticsThis is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions 
| Work Group Orders and Observations & Clinical Genomics |
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.
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 | |
| Observation | Vital Signs, Measurement, Results | Measurements and simple assertions made about a patient, device or other subject. | |
| DiagnosticReport | Report, Test, Result, Results, Labs | The 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. | |
| ServiceRequest | diagnostic request, referral, referral request | A record of a request for service such as diagnostic investigations, treatments, or operations to be performed. | |
| Media | (Not defined yet) | ||
| ImagingSelection | A selection of DICOM SOP instances and/or frames within a single Study and Series. This might include additional specifics such as an image region, a Referenced Content Item Identifier from a DICOM SR Content Item or a Segment Number from a DICOM Segmentation SOP Instance. | ||
| ImagingStudy | Representation of the content produced in a DICOM imaging study. A study comprises a set of series, each of which includes a set of instances (images or other data) acquired or produced in a common context. A series SHALL have only one modality (e.g. X-ray, CT, MR, ultrasound). A study MAY have multiple series which MAY have different modality values. | ||
| MolecularSequence | Representation of a molecular sequence. | ||
| Specimen | A sample to be used for analysis. | ||
| BodyStructure | anatomical location | Record 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:
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:
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:
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:
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.
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.
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.
FHIR ®© HL7.org 2011+. FHIR R6 hl7.fhir.core#6.0.0-ballot2 generated on Tue, Nov 12, 2024 03:30+0000.
Links: Search |
Version History |
Contents |
Glossary |
QA |
Compare to R5 |
|
Propose a change