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
R3
Responsible
Owner:
Work
Group
Pharmacy
&
Public
Health
|
Standards Status : Informative |
This module is concerned with resources and functionality in 3 main domains:
|
| Name | Description |
| MedicationRequest |
Represents an instruction for the administration of medication to a patient - both in the inpatient (hospital) and community setting. It can also include instructions for the dispensing, the reasons why the administration should occur and other data. It is called an 'Request' to be consistent with other FHIR resources and the workflow pattern, but a common alias for this resource is a 'Prescription' or an 'Order'. The Order itself represents the content of the instruction and is not, by itself, actionable. The workflow process around 'fulfilling' the order is part of the generic FHIR workflow (see below), with the MedicationRequest representing the contents. |
| MedicationDispense | The provision of a supply of a medication with the intention that it is subsequently consumed by a patient (usually in response to a prescription). |
| MedicationAdministration | A record of a patient actually consuming a medicine, or if it has otherwise been administered to them |
| MedicationStatement | This is a record indicating that a patient may be taking a medication now, has taken the medication in the past, or will be taking the medication in the future. The source for this information can be the patient, significant other (such as a family member or spouse), or a clinician. A common scenario where this information is captured is during the history taking process during a patient visit or stay. A medication statement is not a part of the prescribe->dispense->administer sequence, but is a report that such a sequence (or at least a part of it) did take place, resulting in a belief that the patient has received a particular medication. It may be used to construct a patients 'Current Medications' list. |
| Medication | The medication resource represents an actual medication that can be given to a patient, and referenced by the other medication resources. In many cases, this resource is not needed and the drug is indicated by a reference to the appropriate terminology and so can be represented using a codeable concept. In other cases, however, it may be desired to indicate more details than the simple drug (such as the packaging, whether it is a generic medication or the active and inactive ingredients) and so the Medication resource can be used for this. |
| Name | Description |
| Immunization | The Immunization resource is intended to cover the recording of current and historical administration of vaccines to patients across all healthcare disciplines in all care settings and all regions. This includes immunization of both humans and animals, but does not include the administration of non-vaccine agents, even those that may have or claim to have immunological effects. |
ImmunizationRecommendation
|
A patient's point-in-time immunization and recommendation (i.e. forecasting a patient's immunization eligibility according to a published schedule) with optional supporting justification |
ImmunizationEvaluation
|
The ImmunizationEvaluation resource is intended to cover communicating the results of an evaluation of a vaccine administration event (documented using the Immunization resource) against a set of published recommendations (protocols). |
Overview
Medication reconciliation is a process that collects all available medication information about a patient e.g., existing medication orders, patient reported medication orders, over-the-counter medication information (e.g., supplements, vitamins and other medications), medication dispenses, medication administrations, medication history and medication related claims or bills. After aggregating the medication information, the provider determines if any action needs to be taken related to the known medications. These actions include updating an existing prescription, writing a new prescription, writing a new order indicating that a patient should not take a medication, including one or more of the over-the-counter medications, etc. The end point of the medication reconciliation process is to end up with a reconciled medication list that can be shared with a provider or patient or patient representative.
This reconciliation process is often done when a patient is:
At transitions of care, it is best practice to perform a medication reconciliation process in order to determine the status of:
Sources for Medication Information
The source of uncurated medication information is often taken from one or more of the following:
The source data may be captured from systems, often EHRs, MARs, ePrescribing systems, pharmacy or billing systems. Depending on the architecture of the healthcare organization and the larger cross enterprise system the data may involve data housed in centralized healthcare data repositories that include medication related data, e.g., dispenses, orders, claims, Personal Health Records (PHR), or patient portals
How to represent the data that is pulled together and in turn make it available via a FHIR API?
Depending on the business requirements the overall list of medications may include data from diverse systems and if it is important to maintain the relationship of the data to the primary FHIR resources this could end up with a collection of data that is represented with the following resources:
Often,
however
the
internal
systems
may
make
a
business
determination
that
they
will
expose
the
data
via
one
of
the
resources
e.g.
e.g.,
If
the
list
of
medication
data
is
to
reflect
what
the
patient
"should"
be
taking,
it
would
be
accurate
to
represent
this
using
the
MedicationRequest
resource.
See
US
Core
for
one
example
for
how
to
represent
this
type
of
approach.
As additional requirements evolve additional resources may be required to support creating a medication list. For example, if you want to include whether the patient is taking or not taking a medication, or whether the patient is taking or not taking the medication as prescribed, you may want to include MedicationStatement to reflect the taking or not taking.
Another example of an additional requirement may be if you want to create a reference to what type of data was used to create the entry on the medication list – this may result in exposing the referenced data as a MedicationRequest (common), MedicationDispense (often), MedicationAdministration(rare), or MedicationStatement (situational).
A
strong
suggestion
is
to
consider
carefully
how
you
want
to
expose
this
information.
This
will
influence
what
resources
may
be
used
in
a
FHIR
API
interface.
A
simple
medication
list
may
only
include
one
or
two
of
the
primary
Pharmacy
resources
e.g.
e.g.,
MedicationRequest
or
MedicationStatement,
but
a
more
complex
or
full
featured
medication
list
may
include
many
if
not
all
of
the
Pharmacy
resources.
Context Impacts Medication Reconciliation
In any example it is possible that some medication information may be constrained or even excluded from the medication reconciliation e.g., exclude history of long-past substance abuse, constrain to only prescribed medications. These limited Medication Reconciliation outputs will have some value to some end-uses, but not to all end-uses.
How is Medication Reconciliation information made available to patients or clinicians?
Patients often access the list of medications via a patient facing portal, or they may be provided a paper copy of their medications.
Providers may access the output of Medication Reconciliation directly in their ePrescribing system or EHR which reflects all known medications the patient should be taking at a point in time.
and
SupplyDelivery
which,
like
MedicationRequest,
are
'detail'
resources
used
as
part
of
a
workflow
.
They
are
concerned
with
the
request
of
supplies
used
in
the
healthcare
process.
This
includes
supplies
specifically
used
in
the
treatment
of
patients
as
well
as
supply
movement
within
an
institution
(transport
a
set
of
supplies
from
materials
management
to
a
service
unit
(nurse
station).
As with all clinical data, Medications (in particular) can be sensitive information as specific medications can indicate the presence of private information such as mental health disorders or HIV. However, withholding information about what medications a person is taking can lead to catastrophic results, and so needs to be considered very carefully. At the least, a clinician should be made aware that there is information available that they have not been given when making clinical decisions.
For more general considerations, see the Security and Privacy module .
The
Pharmacy
workgroup
has
plans
to
improve
all
existing
resources
e.g.
e.g.,
adding
in
features
that
support
detailing
our
conditional
orders
in
a
structured
way;
evaluating
requirements
for
supporting
drug
formularies
and
medication
knowledge.
This
work
is
expected
to
include
the
development
and
approval
of
a
new
resource
and
may
involve
updates
to
the
Medication
Resource.