R6
Ballot
(3rd
Draft)
(1st
Full
Ballot)
Diagnostics
This
page
is
part
of
the
FHIR
Specification
v6.0.0-ballot3:
v6.0.0-ballot4:
Release
6
Ballot
(3rd
Draft)
(1st
Full
Ballot)
(see
Ballot
Notes
).
The
current
version
is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
for
published
versions
|
Responsible
Owner:
Work
Group
Orders
and
Observations
|
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
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
ServiceRequest).
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.
| Name | Aliases | Description |
| Observation |
Vital
|
Measurements and simple assertions made about a patient, device or other subject. |
| DiagnosticReport |
Report,
Test,
Result,
Results,
|
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
|
A record of a request for service such as diagnostic investigations, treatments, or operations to be performed. |
|
|
A reference to a document of any kind for any purpose. While the term “document” implies a more narrow focus, for this resource this “document” encompasses *any* serialized object with a mime-type, it includes formal patient-centric documents (CDA), clinical notes, scanned paper, non-patient specific documents like policy text, as well as a photo, video, or audio recording acquired or used in healthcare. The DocumentReference resource provides metadata about the document so that the document can be discovered and managed. The actual content may be inline base64 encoded data or provided by direct reference. | |
| ImagingSelection |
A
selection
of
DICOM
SOP
instances
|
|
| 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
images
or
other
data
objects
(called
Service-Object
Pair
Instances
|
|
|
|
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. |
Implementation Note: MolecularSequence resource has been replaced by the Molecular Definition
Many
observations
need
to
be
grouped
together
in
some
fashion
to
document
critical
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
observations
and
the
content
of
a
diagnostic
reports,
report
(in
DiagnosticReport.composition),
but
that
is
only
for
purpose
of
readability,
not
to
record
critical
the
relationships
necessary
for
interpretations.
See
DiagnosticReport.composition
interpretation.
Note:
When
an
observation
is
not
performed
and
Composition
for
further
considerations
for
if
this
needs
to
be
communicated
as
part
of
a
reporting,
the
Observation
would
be
used
to
document
that
separate
purpose.
it
was
not
performed
and
why.
The
DiagnosticReport
would
include
such
observation
when
that
documentation
was
necessary.
For
more
information
see
Observation
.
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.
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
was
needed
to
perform
the
susceptibility
panel
as
sometimes
the
overall
ServiceRequest
covers
it,
and
other
times
a
is
required:
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
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.
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,
(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.
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 more 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.
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
(ServiceRequest.extension-specimenSuggestion
references
the
specific
Specimen
to
be
used),
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
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.
The
DICOM®
Structured
Report
(DICOM®
SR)
is
a
standard
for
recording
clinical
imaging
observations
made
regarding
a
diagnostic
resources
often
represent
patient-specific
data,
and
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
susceptible
bridged
by
the
DICOM
SR
IG
by
the
transformation
of
the
DICOM
SR
attributes
to
data
breaching.
Necessary
privacy
the
HL7
FHIR
Observation
Resource.
DICOM
SR
mapping
to
FHIR
is
limited
to
the
Observation
resource
and
security
provisions
must
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
place
when
searching
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
Security
core
DICOM
SR
measurement
groups,
measurements
and
Privacy
module
.
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.
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 .
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 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 .
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-ballot3
hl7.fhir.core#6.0.0-ballot4
generated
on
Tue,
Apr
1,
Thu,
Dec
18,
2025
12:26+1100.
07:15+1100.
Links:
Search
|
Version
History
|
Contents
|
Glossary
|
QA
|
Compare
to
R4
|
Compare
to
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change