Clinical
Reasoning
This
page
is
part
of
the
Continuous
Integration
Build
of
FHIR
Specification
(v5.0.0:
R5
-
STU
).
This
is
the
current
published
version
in
it's
permanent
home
(it
will
always
(will
be
available
incorrect/inconsistent
at
this
URL).
For
a
full
list
of
available
versions,
see
times).
See
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
|
Responsible
Owner:
Work
Group
Clinical
Decision
Support
|
Standards
Status
:
|
One
of
the
primary
use
cases
of
the
Clinical
Reasoning
Module
is
to
enable
the
sharing
and
distribution
of
computable
clinical
knowledge
artifacts.
Some
general
considerations
for
this
use
case
are
documented
here,
in
this
discussion,
with
a
more
complete
and
ongoing
treatment
in
the
Canonical
Resource
Management
Infrastructure
implementation
guide.
The distribution use case involves enabling knowledge artifacts to be distributed as FHIR resources, either by making use of the FHIR implementation guide publication infrastructure, or via a FHIR server.
For distribution as part of FHIR Implementation Guides, the existing FHIR publication infrastructure can be used to produce implementation guides whose primary focus is conformance and knowledge artifacts such as ValueSets, Libraries, ActivityDefinitions, PlanDefinitions, and Measures. To help illustrate this approach, the following diagram depicts several types of FHIR implementation guides:
This diagram depicts 4 categories of specifications, with representative examples of each category, illustrating how the various pieces can be used together to deliver shareable clinical reasoning artifacts such as quality measures and decision support rules.
Along the bottom of the diagram are the foundational standards, including FHIR, with the 5 layers of Foundation, Conformance, Administration, Clinical, and Reasoning, as well as expression language and integration standards including FHIRPath, Clinical Quality Language, CDS Hooks, and SMART-on-FHIR.
In the middle left are the Model Implementation Guides, typically derived from Administration and Clinical resources such as Patient, Encounter, and MedicationRequest. Model IGs are typically built to address a broad range of use cases, focused on a particular target realm or domain.
In the middle right are the Specification Implementation Guides, which derive from the FHIR Clinical Reasoning resources to provide implementation guidance and conformance requirements for the creation, distribution, evaluation, and maintenance of shareable clinical knowledge. For example, the Quality Measure IG provides guidance on and conformance requirements for the use of the FHIR Measure and Library resources to create and share clinical quality measures, Data Exchange for Quality Measures (DEQM) provides guidance for reporting quality measures, and the Clinical Practice Guidelines IG (CPG-on-FHIR) demonstrates how to build shareable computable guideline content.
And finally, at the top of the diagram, the Content Implementation Guides are FHIR Implementation Guides, but not necessarily balloted as HL7 standards, rather these use the FHIR publication toolchain to support authoring and distribution, but the content is stewarded by separate authorities such as quality agencies and guideline developers; groups that have their own governance and maintenance policies. For example, the HEDIS IG contains HEDIS quality measures expressed using FHIR Measure and Library resources, and conforming to the Quality Measure IG profiles, while the CDC Opioid Prescribing IG and WHO Antenatal Care IGs contain decision support content to streamline guideline implementation. The content IGs conform to the specification IGs, and typically make use of the model IGs to define content focused on a particular realm.
The Foundation layer of FHIR defines the core data exchange protocol. The Conformance layer defines how resources, profiles, and terminologies are represented and used. The Administration layer defines individuals, locations, organizations, and encounters. The Clinical layer defines clinical information such as observations, medications, procedures, and orders. And the Reasoning layer provides definitional artifacts like plan and activity definitions, libraries, and measures.
FHIRPath
is
a
simple,
yet
powerful,
model-independent
expression
language
that
is
used
extensively
throughout
FHIR
to
describe
paths
to
elements
on
resources,
and
define
invariants
on
profiles.
CQL
Clinical
Quality
Language
(CQL)
is
a
superset
of
FHIRPath
that
provides
an
author-friendly
format
for
the
description
of
clinical
logic,
as
well
as
a
machine-friendly
machine-friendly,
platform
independent
format
for
sharing
and
processing
the
logic.
CDS
Hooks
is
an
HL7
standard
specification
for
integrating
decision
support
services
with
clinical
systems.
It
is
primarily
focused
on
provide-facing
remote
decision
support
within
an
EMR.
SMART-on-FHIR
is
an
HL7
standard
specification
for
integrating
clinical
applications
into
EMRs
using
FHIR.
International
Patient
Summary
(IPS)
is
a
set
of
internationally
applicable
FHIR
profiles
used
to
share
patient
information
across
international
boundaries.
As
a
result,
it
forms
an
excellent
foundation
for
expressing
universally
applicable
content
guidelines
such
as
the
WHO
Antenatal
Care
(WHO
ANC).
US
Core
is
a
set
of
profiles
focused
on
enabling
exchange
of
the
US
Clinical
Data
for
Interoperability
(US
CDI),
and
is
supported
by
a
broad
range
of
EMR
vendors
within
the
US.
QI
Core
is
a
set
of
profiles
that
derives
from
US
Core
to
enable
quality
improvement
use
cases
such
as
quality
measurement
and
decision
support
within
the
US.
To
get
started
building
a
content
implementation
guide,
refer
to
the
Sample
Content
IG
,
and
the
Content
IG
and
Colorectal
Cancer
walkthroughs.
For
distribution
via
a
FHIR
server,
the
search
and
read
interactions
defined
by
the
FHIR
infrastructure
can
be
used
for
this
purpose.
used.
The
Library
,
ActivityDefinition
,
PlanDefinition
,
Questionnaire
,
and
Measure
resources
can
all
be
used
to
represent
knowledge
artifacts,
and
so
define
several
search
parameters
specifically
to
enable
searching
based
on
the
various
attributes
of
a
knowledge
artifact.
A
FHIR
service
that
supports
at
least
searching
and
retrieval
of
these
resources
is
then
a
basic
Knowledge
Artifact
Repository.
More
advanced
knowledge
management
capabilities
such
as
change
management,
semantic
indexing,
and
dependency
tracking
can
all
be
provided
on
top
of
this
basic
infrastructure.
Some
general
considerations
for
use
are
documented
in
what
follows,
with
a
more
complete
and
ongoing
treatment
provided
as
part
of
the
Canonical
Resource
Management
Infrastructure
implementation
guide.
guide,
including:
In
particular,
the
useContext
and
topic
elements
are
is
intended
to
provide
both
semantic
and
topical
indexing
functionality
for
use
in
knowledge
repositories.
For
example,
the
following
fragment
illustrates
the
use
of
the
useContext
element
to
indicate
semantic
usage
context
for
an
example
suicide
risk
order
set:
<coverage>
<patientAgeGroup>
<coding>
<system value="http://snomed.info/sct"/>
<code value="133936004"/>
<display value="Adult"/>
</coding>
</patientAgeGroup>
<clinicalFocus>
<coding>
<system value="http://snomed.info/sct"/>
<code value="87512008"/>
<display value="Mild major depression"/>
</coding>
</clinicalFocus>
<clinicalFocus>
<coding>
<system value="http://snomed.info/sct"/>
<code value="394687007"/>
<display value="Low suicide risk"/>
</coding>
</clinicalFocus>
<targetUser>
<coding>
<system value="http://snomed.info/sct"/>
<code value="309343006"/>
<display value="Physician"/>
</coding>
</targetUser>
<clinicalVenue>
<coding>
<system value="http://snomed.info/sct"/>
<code value="440655000"/>
<display value="Outpatient environment"/>
</coding>
</clinicalVenue>
</coverage>
The
useContext
element
can
contain
any
number
of
characteristics
that
define
the
particular
context
of
use
for
the
artifact.
Note
that
the
base
resource
does
not
communicate
the
intended
semantics
when
multiple
useContext
elements
are
present.
To
accomplish
this,
a
core
extension
is
defined,
usagecontext-group
.
All
use
contexts
within
a
group
apply,
while
groups
of
use
contexts
indicate
that
any
group
applies.
In
addition,
the
useContext
element
is
intended
to
convey
prescriptive
semantics
about
the
appropriate
context
of
use
for
an
artifact,
while
the
topic
element
is
intended
to
convey
as
well
as
descriptive
semantics
suitable
for
indexing
and
searching
using
the
topic
search
parameter.
context
type.
The FHIR search interaction specifies that search results are returned in a Bundle, and the entries in that bundle allow a score to be specified, consistent with the Decision Support Service (DSS) relevance result. Note that the DSS score range is 1 to 100, while the FHIR score range is 0..1.
The algorithm for determining relevance is not prescribed by this guidance. When calculating relevance, implementations are encouraged to take advantage of the metadata represented within the artifact to help users understand the relevance of the returned artifacts to their search criteria.
To
reduce
the
size
of
returned
results
and
ensure
efficient
searching
and
retrieval,
the
Bundle
returned
SHOULD
is
recommended
to
consist
only
of
resources
of
the
requested
type.
Dependencies
of
the
resources
returned
SHOULD
NOT
are
not
recommended
to
be
included
unless
specifically
referenced
by
including
the
resources
using
the
_include
and
_revinclude
parameters.
Support for two different distribution use cases can be provided using the basic GET interaction:
_summary
parameter,
the
resources
returned
represent
only
the
basic
information
and
metadata
about
each
matching
artifact.
_include
and
_revinclude
search
parameters
to
include
related
resources
in
the
result.
The following table lists the search criteria elements defined by the Decision Support Service (DSS) standard along with their appropriate representation in FHIR:
| DSS Search Criteria | FHIR Equivalent |
|---|---|
| Maximum Results | _count global search parameter |
| Minimum Score | KnowledgeArtifact.minScore search parameter |
| Knowledge Artifact Trait | Knowledge search parameters (identifier, topic, title, description, version) |
| Knowledge Artifact Status | KnowledgeArtifact.status search parameter |
| Evaluation Result Semantics | Not Implemented |
| Data Requirements | Not Implemented |
| Relationships to specific Knowledge Artifacts | Not Implemented |
Support for exclusion criteria as described in the DSS is provided by the :not search parameter modifier of FHIR.
Implementing at least the FHIR search and get interactions for the clinical reasoning resources (Library, ActivityDefinition, PlanDefinition, and Measure) is then a basic implementation of a Knowledge Artifact Repository. For example, the following GET retrieves all measures that reference a specific value set:
GET
[base]/ValueSet/zika-affected-areas?_revinclude=Library:depends-on&_revinclude:recurse=Measure:depends-on
More sophisticated management functionality including semantic indexing, change management, and dependency tracking can be provided on top of this basic functionality using the same resource structures.
FHIR
®©
HL7.org
2011+.
FHIR
R5
hl7.fhir.core#5.0.0
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Sun,
Mar
26,
2023
15:26+1100.
Thu,
Nov
27,
2025
16:55+0000.
Links:
Search
|
Version
History
|
Contents
|
Glossary
|
QA
|
Compare
to
R4
|
Compare
to
R4B
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change