This
page
is
part
of
the
FHIR
Specification
v6.0.0-ballot3:
Release
6
Ballot
(3rd
Draft)
(see
Ballot
Notes
).
The
current
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
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 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, 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 organized into a set of "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
Level 2 Supporting implementation and binding to external specifications
Level 3 Linking to 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 , Family History , RiskAssessment , etc.
Observation
,
DiagnosticReport
,
Specimen
,
ImagingStudy
,
MolecularSequence
MolecularDefinition
,
DocumentReference
,
ServiceRequest
,
etc.
Medication
,
Request
,
Dispense
,
Administration
,
Statement
,
Immunization
,
etc.
Introduction + Task , Appointment , Schedule , Referral , PlanDefinition , etc.
Claim
,
Account
,
Invoice
,
ChargeItem
,
Coverage
+
Eligibility
Request
&
Response
,
ExplanationOfBenefit
,
etc.
Level 5 Providing the ability to reason about the healthcare process
Library , PlanDefinition & GuidanceResponse , Measure / MeasureReport , 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.