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:
FHIR
Infrastructure
Work
Group
| Standards Status : Informative |
FHIR
is
a
platform
specification
that
defines
a
set
of
capabilities
for
use
across
the
healthcare
process,
in
all
jurisdictions,
and
in
lots
of
different
context.
contexts.
While
the
basics
of
the
FHIR
specification
are
relatively
straight-forward
(see
the
Overviews:
General
,
Developers
,
Clinical
,
and
Architects
),
it
can
still
be
difficult
to
know
where
to
start
when
implementing
a
solution
based
on
FHIR.
This page provides some guidance to help get new implementers started on their path to successful implementation. Beyond reading the overviews (previous paragraph), where should an implementer start? Generally, an implementer needs to resolve:
The
remaining
sections
provide
guidance
on
specific
areas
(Foundation,
Implementer
Support,
Security
and
Privacy,
Conformance,
Terminology,
Linked
Data,
Administration,
Clinical,
Diagnostics,
Medications,
Workflow,
Financial
and
Clinical
Reasoning).
All implementers should be aware of how versioning works in the FHIR specification. See both:
In
order
to
help
implementers
find
their
way
around
the
specification
and
answer
these
questions,
it
is
organised
organized
into
a
set
of
"modules".
"modules".
Each
module
represents
a
different
functional
area
of
the
specification,
and
contains:
Broadly, the modules are organized into 3 groups:
Level 1 Basic framework on which the specification is built
Base
Documentation
,
XML
,
JSON
,
REST
API
+
Search
RDF
(Turtle)
,
Data
Types
Datatypes
,
Extensions
Level
2
Supporting
Implementation,
implementation
and
binding
to
external
specifications
Downloads
,
Common
Use
Cases
Version
Mgmt
,
Testing
Use
Cases
Level
3
Linking
to
real
world
real-world
concepts
in
the
healthcare
system
Patient , Practitioner , CareTeam , Device , Organization , Location , Healthcare Service
Level 4 Record-keeping and Data Exchange for the healthcare process
Allergy
,
Problem
,
Procedure
,
CarePlan
/
Goal
,
DetectedIssue
Family
History
,
RiskAssessment
,
etc.
Observation
,
Report
DiagnosticReport
,
Specimen
,
ImagingStudy
,
Genomics
,etc
MolecularDefinition
,
DocumentReference
,
ServiceRequest
,
etc.
Medication
,
Order
Request
,
Dispense
,
Administration
,
Statement
,
Immunization
,
etc.
Introduction + Task , Appointment , Schedule , Referral , PlanDefinition , etc.
Claim
,
Account
,
Coverage
Invoice
,
Claim
ChargeItem
,
EligibilityRequest
Coverage
+
Eligibility
Request
&
Response
,
ExplanationOfBenefit
,
etc.
Level 5 Providing the ability to reason about the healthcare process
Library
,
ServiceDefinition
PlanDefinition
&
GuidanceResponse
,
Measure
/
MeasureReport
,
etc
etc.
Medicinal , Packaged & Administrable product definitions, Regulated Authorization , etc.
Dependencies between the modules are mainly downwards, with some horizontal dependencies. Implementers should choose the content modules to engage with based on their requirements, and should only engage with the reasoning module if they need to do clinical decision support, and/or Quality Measures.
In addition to the use case based assistance in the modules, these additional documentation pages may be useful:
Finally,
one
important
place
to
look
is
the
registry
of
implementation
guides
,
to
see
whether
similar
(or
identical)
requirements
have
been
met.