Example
OperationDefinition/Claim-submit
(Narrative)
Financial
Management
Work
Group
Biomedical
Research
and
Regulation
|
Maturity
Level
:
N/A
|
Standards
Status
:
Informative
|
15.0
Medication
Definition
Module
15.0.1
Introduction
This
module
is
concerned
with
resources
and
functionality
in
areas
such
as:
The
regulation
and
manufacturing
of
drugs,
medicinal
products
and
other
medically-related
substances
or
co-packaged
devices.
Detailed
description
of
these
same
items,
typically
for
regulators
but
also
for
any
context
where
this
level
of
detail
is
necessary,
such
as
pharmacopoeias,
or
prescribing
support.
Indications
and
contra-indications
for
medications.
The
details
of
the
chemical
substances
that
may
be
ingredients
for
medications.
These
resources
are
not
typically
used
in
direct
patient
care
or
day-to-day
prescribing
functionality
(for
which
see
the
Medications
Module
Compartments
:
Device
,
and
further
down
on
this
page:
Relationship
to
Prescribing
),
but
play
a
supporting
role.
They
can
specify
the
"full"
version
of
the
product
type,
with
all
its
information,
including
the
licensed
packages
available,
with
their
physical
details
and
containers,
through
to
individual
tablet
level
and
on
to
ingredients
and
component
substances.
Encounter
,
Patient
,
Practitioner
,
RelatedPerson
15.0.2
Index
|
-
MedicinalProductDefinition
Narrative
Ingredient
-
ClinicalUseDefinition
XML
PackagedProductDefinition
-
AdministrableProductDefinition
JSON
SubstanceDefinition
-
ManufacturedItemDefinition
TTL
RegulatedAuthorization
The
main
medication
definition
resources
and
their
relationships
are
shown
below
(any
can
be
used
when
required,
but
there
is
no
need
to
use
all
of
them).
The
core
This
is
a
three
level
model:
product,
package,
item:
You
can
vary
the
levels
used,
according
to
the
application
needs:
Even
just
using
one
resource,
narrative
for
a
basic
representation:
An
example
of
a
single
resource
version
is
here
15.0.2.1
Products
and
Packaging
The
core
resources
of
Medication
Definition
deal
with
products
and
their
packaging:
Name
Description
MedicinalProductDefinition
The
MedicinalProductDefinition
resource
covers
the
detailed
defining
data
of
medicinal
products,
to
a
level
beyond
what
is
typically
needed
for
day-to-day
prescribing,
but
that
is
commonly
required
by
manufacturers
and
regulators,
and
resource.
See
also
for
use
in
drug
catalogs
and
pharmacopoeias.
(For
direct
patient
care
when
prescribing,
dispensing
etc.
the
correct
resource
is
Medication
).
PackagedProductDefinition
XML
,
JSON
The
PackagedProductDefinition
resource
represents
one
pack
type
of
a
product,
and
can
also
capture
all
aspects
of
the
physical
packaging
of
a
product.
These
pack
types
can
be
associated
with
an
"owning"
MedicinalProductDefinition,
to
represent
the
range
of
different
pack
sizes
for
that
product.
These
may
have
different
legal
statuses
and
availability,
or
be
packaged
in
different
ways.
The
resource
allows
describing
which
drug
items
and
associated
co-packaged
devices
are
within
them.
The
actual
contained
items
are
handled
by
specific
resources
(e.g.
ManufacturedItemDefinition
and
DeviceDefinition
).
ManufacturedItemDefinition
Turtle
ManufacturedItemDefinition
is
used
when
you
need
to
describe
a
physical
medication
item
type
such
as
a
tablet
or
capsule,
or
some
continuous
substance
such
as
liquid
or
powder.
This
is
typically
for
regulatory
or
manufacturing
use
cases,
rather
than
day-to-day
prescribing
or
dispensing.
It
can
carry
the
definition
and
characteristics
of
a
medicinal
(or
medically-related)
manufactured
item,
usually
to
be
contained
in
a
packaged
medicinal
product
,
and
not
found
on
its
own.
The
package
definition
carries
the
quantity
of
each
contained
item,
allowing
re-use
for
different
amounts
format.
AdministrableProductDefinition
A
medicinal
product
may
consist
of
several
items,
which
need
to
be
combined
before
administration
to
the
patient.
The
administrable
(or
"pharmaceutical")
product
-
which
differs
in
Note
that
it
is
now
"mixed"
from
its
components
(if
necessary)
and
is
ready
for
use
-
this
is
covered
by
the
AdministrableProductDefinition
resource.
The
components
are
ManufacturedItemDefinitions.
The
product
and
packaging
resources
listed
above
can
be
combined
to
represent
a
product
with
different
packs:
National
level
drug
dictionaries
typically
have
a
split
between
products
and
the
packs
that
exist
formal
definition
for
them.
The
product
level
has
the
common
data
such
submit
operation
as
name,
strength,
form,
indications
etc.
Medications
are
usually
prescribed
at
product
level,
rather
than
specifying
a
particular
pack.
But
eventually
it
is
an
actual
pack
that
gets
dispensed,
with
a
specific
size
or
item
count
and
packaging
configuration
(carton,
bottle,
blister
pack
etc.).
Packaging
information
can
be
complex,
and
the
PackagedProductDefinition
resource
allows
any
combination
of
items
and
packaging
to
be
represented.
Here
is
a
representation
of
a
widely
available
combination
product
pack
of
a
tablet
and
cream:
An
example
of
a
combination
product
is
here
,
shown
as
a
bundle
and
here
,
shown
instead
using
contained
resources
(either
can
be
selected
according
to
preference)
Co-packaged
devices
can
be
represented,
as
well
as
items
that
need
to
be
combined
before
administration:
A
full
example
of
a
co-packaged
device
with
a
powder
and
solvent
is
here
.
A
simpler
example
of
a
co-packaged
device
and
liquid
is
here
.
The
PackagedProductDefinition
resource
can
be
used
for
different
aspects
of
package
information:
Complete
package
definitions
(a
package
type,
and
its
internals)
Just
the
internal
packaging
(perhaps
only
the
innermost
layer
of
packaging
that
touches
the
tablet)
A
package
type
definition
that
has
no
internals
specified
(a
common
case
for
a
drug
dictionary)
The
resource
elements
must
be
used
in
a
consistent
way
for
each
case.
This
diagram
shows
how
these
three
cases
are
handled.
OperationDefinition
on
Claim.
See
the
PackagedProductDefinition
Operation
documentation
resource
for
more
information.
The
ManufacturedItemDefinition
resource
can
be
used
to
describe
the
physical
items
that
products
consist
of,
to
varying
levels
of
detail.
URL:
[base]/Claim/$submit
A
typical
use
is
the
left
diagram
below
-
a
tablet
consists
of
two
ingredients,
one
active
and
one
an
excipient,
together
with
the
amounts
of
each
(strengths)
in
the
tablet
as
a
whole.
A
more
detailed
view
is
shown
below
right,
which
also
covers
the
components,
or
layers,
that
make
up
a
single
tablet
-
for
instance
a
coating
or
shell,
and
the
inner
powder.
It
can
be
useful
to
be
able
to
state
which
of
the
overall
ingredients
are
found
in
which
parts
of
the
tablet,
and
in
what
quantities.
See
the
ManufacturedItemDefinition
resource
for
more
information.
Parameters
15.0.2.2
Ingredients
and
Substances
Medication
Definition
also
has
resources
for
the
detailed
chemical
composition
of
medications:
Name
Use
|
Description
Name
|
Ingredient
Cardinality
|
The
Ingredient
resource
describes
a
material
used
in
the
preparation
of
a
medicinal/pharmaceutical
product,
within
the
context
of
a
particular
use.
An
ingredient
is
part
of
a
product,
either
alone
or
in
combination
with
other
ingredients.
It
is
essentially
a
substance
with
the
addition
of
the
specific
role
it
is
playing
in
the
product,
which
may
include
whether
it
is
an
active
or
inactive
substance
and
what
the
strength
is
(the
quantity
of
substance
compared
to
the
whole
product).
SubstanceDefinition
The
detailed
description
of
a
substance,
typically
at
a
level
beyond
what
is
used
for
prescribing.
15.0.2.3
Authorizations
and
Usage/Warnings
Type
Medication
Definition
covers
the
surrounding
context
of
medications,
their
use
and
legal
status:
|
Name
Binding
|
Description
Documentation
|
RegulatedAuthorization
RegulatedAuthorization
is
a
resource
covering
the
authorization
of
a
type
of
product,
item,
device,
process,
treatment,
facility
or
service,
from
a
regulatory
point
of
view.
IN
|
ClinicalUseDefinition
ClinicalUseDefinition
is
a
resource
to
capture
a
usage
issue
-
either
an
indication,
contraindication,
interaction
or
an
undesirable
effect
for
a
medicinal
product,
medication,
device
or
procedure.
The
resource
represents
one
single
issue,
in
one
of
several
types.
|
15.0.3
Common
Use
Cases
1..1
|
Submitting
a
drug
to
a
regulator
for
approval
Creating
a
national
level
drug
catalogue,
including
with
virtual
and
actual
medicinal
products
and
packs
Capturing
information
about
the
manufacturing
of
a
drug
15.0.4
Resource
Other
resources
|
|
There
are
other
resources
that
are
of
particular
interest
to
the
medication
definition
domain.
Medication
This
is
the
resource
to
use
for
prescribing
use
cases,
and
anywhere
that
an
actual
medication
instance
is
needed.
Substance
The
substance
A
Claim
resource
has
a
limited
subset
of
data,
and
is
aimed
at
prescribing
use
cases.
Unlike
SubstanceDefinition,
it
can
be
an
actual
instance
of
a
substance
(e.g.
an
amount
of
an
ingredient
or
raw
material).
DeviceDefinition
A
DeviceDefinition
can
be
used
to
represent
a
device
that
is
inside
the
package
Bundle
of
claims,
either
as
individual
Claim
resources
or
as
Bundles
each
containing
a
medicinal
product,
within
the
PackagedProductDefinition
resource.
Organization
Many
regulatory
processes
are
centred
around
organizations
(pharma
companies,
drug
manufacturers,
regulatory
agencies).
These
are
all
represented
by
Organizations,
and
are
single
Claim
plus
referenced
by
many
of
the
module's
resources.
|
15.0.5
Definitions
and
Instances
|
OUT
|
return
|
1..1
|
The
main
Medication
Definition
resources
for
products
and
substances
are
purely
about
kinds
of
things
-
definitions
-
and
not
physical
instances.
Instances
of
products,
such
as
things
that
are
actually
dispensed,
administered
or
tested,
are
Medications
.
"Kinds"
can
be
prescribed,
either
as
a
code
(which
represents
a
definition)
or
as
a
reference
to
a
FHIR
product.
A
concept
in
a
code
system,
such
as
SNOMED
CT,
NDC
or
UK
dm+d,
and
a
concept
as
a
FHIR
MedicinalProductDefinition,
are
equivalent.
Both
represent
a
type
of
drug.
In
use
these
must
always
go
via
a
Medication
resource.
Instances
of
substances
and
ingredients
(a
substance
in
a
role)
are
Substances
.
Data
such
as
batch
numbers,
and
actual
manufacturing
dates
belong
on
instances
of
products
or
substances
rather
than
definitions.
Resource
15.0.6
Relationship
to
Prescribing
|
|
This
diagram
shows
the
principles
of
how
these
sets
of
resources
relate:
The
Medication
resource,
and
others
in
the
Medications
Module
(shown
at
the
top
of
the
diagram),
mainly
cover
the
use
of
a
medication
"by
reference"
(using
a
code),
with
only
some
basic
extra
optional
information:
form,
strength,
perhaps
batch
number
and
even
less
commonly
used
-
simple
ingredients.
Many
of
those
are
rarely
populated
because
they
are
implicit
in
the
code.
So
the
Medication
resource
doesn�t
define
medicinal
products
to
any
extent,
it
is
more
of
a
selector.
The
MedicinalProductDefinition
resource,
and
the
others
in
this
module
(show
lower
in
the
diagram),
cover
the
detailed
defining
data
of
medicinal
products,
to
a
level
that
is
only
occasionally
needed
for
day-to-day
prescribing
(e.g.
for
look-ups
of
unfamiliar
products),
but
that
is
commonly
required
by
manufacturers
and
regulators.
These
Medication
Definition
resources
are
information
about
drugs
(and
related
products),
and
drug
product
information
is
useful
any
time
that
a
drug
is
part
of
a
scenario
or
is
in
the
attention
of
a
clinician
or
patient.
If
the
drug
is
in
scope
of
a
workflow
then
these
resources
and
their
content
data
may
be
in
scope
of
the
software.
But
these
resources
are
not
themselves
directly
"prescribed".
You
usually
prescribe
a
shorthand
drug
reference
-
a
code
(with
varying
specificity)
-
and
not
the
page
from
the
pharmacopeia
or
drug
catalogue
-
which
is
more
what
these
resources
represent.
But
it
is
clear
that
the
prescribed
drug
and
the
information
in
the
catalogue
or
database
about
that
drug
are
two
sides
of
the
same
thing,
and
not
two
different
worlds.
Those
detailed
properties
always
exist,
in
all
settings.
So
the
main
difference
between
the
Medication
A
ClaimResponse
resource
and
the
Medication
Definition
ones
is
level
of
detail,
or
more
accurately
the
"extent"
of
information.
To
prescribe
a
drug
all
you
need
to
do
is
identify
what
drug
it
is
(or
substance
etc.).
But
there
are
times
when
you
need
to
open
your
book
(national
formulary,
or
maybe
a
national
drug
regulator's
website)
and
want
to
know
the
color
of
the
tablet,
or
if
it
can
be
given
for
children,
or
if
it
has
a
syringe
in
the
package.
You
may
need
to
know
if
it
is
licensed
as
prescription
only
(in
France),
or
if
an
excipient
is
present
that
the
patient
is
allergic
to
-
and
who
manufactured
that.
Or
if
it
comes
in
a
smaller
or
bigger
pack.
All
Bundle
of
this
is
in
these
Medication
Definition
resources.
You
don't
prescribe
that
information
(or
the
book)
but
it
is
useful
to
support
prescribing,
and
other
patient
processes,
such
claim
responses,
either
as
adverse
event
investigation.
You
therefore
prescribe
a
"code",
but
these
resources
sit
behind
this
code,
providing
context
and
definition,
giving
more
detail
than
even
most
drug
code
systems/ontologies
tend
to
have.
Also,
this
information
forms
the
product
dossier
when
people
want
to
decide
if
this
drug
is
safe
and
effective,
and
this
is
separate
from
prescribing
use.
The
distinction
between
the
two
sets
of
individual
ClaimResponse
resources
is
not
"regulatory"
versus
"prescribing".
It
is
important
to
realise
that
there
is
only
one
set
of
defining
information
in
the
real-world
about
the
drug,
no
matter
what
context,
or
who
needs
it,
or
what
subset
is
relevant
to
them.
The
drug
info
is
the
drug
info
and
it
exists
whether
it's
a
clinical
trial,
a
drug
licence
approval,
or
a
dispense.
It
always
has
this
set
of
properties
-
though
some
parts
of
the
information
set
vary
depending
on
the
geography
and
over
time.
Hence
the
information
in
the
Medication
Definition
resources
is
not
correctly
scoped
as
"regulatory".
It
is
just
the
facts
about
the
drug,
same
as
always,
from
when
it
was
first
created
and
trialled,
to
when
it
is
manufactured,
distributed,
prescribed
and
then
tracked
after
administration.
However
at
dispense
and
especially
at
prescribe
time
only
a
smaller
subset
of
this
information
is
usually
of
direct
interest.
Regulators
on
the
other
hand,
by
the
nature
of
their
role,
study
the
drug
in
great
depth
(down
to
molecular
level
perhaps)
and
consider
more
of
the
same
set
of
information,
which
these
resources
cover.
15.0.7
Security
and
Privacy
The
medication
definition
resources
don't
cover
any
aspect
of
direct
patient
care,
and
in
some
cases
the
information
is
even
in
the
public
domain.
However
drug
development
often
involves
confidential
data
of
Bundles
each
containing
a
commercially
sensitive
nature,
and
as
such
the
resources
are
susceptible
to
data
breaching.
Necessary
privacy
and
security
provisions
must
be
in
place
when
transmitting,
searching
and
fetching
this
information.
For
more
general
considerations,
see
the
Security
and
Privacy
module
.
single
ClaimResponse
plus
referenced
resources.
15.0.8
Developmental
Roadmap
|
BR&R
workgroup
recognizes
that
there
are
different
ways
a
medicinal
product
could
have
been
modelled,
when
we
created
these
resources
in
collaboration
with
Pharmacy
and
other
workgroups.
We
now
seek
interested
parties
to
implement
the
resources
for
their
own
requirements,
and
to
provide
feedback
with
evidence
of
what
works
and
what
may
be
missing.
This
will
help
us
to
cover
the
appropriate
scope
of
medicinal
products.
Development
Rationale:
Some
different
modes
of
design
for
these
resources
were
considered.
One
large
model,
with
a
profile
for
Medication:
A
decision
was
Usage
note:
every
effort
has
been
made
by
the
joint
committees
to
retain
Medication
as
a
core
resource,
without
it
needing
to
be
a
profile.
The
profile
approach
was
rejected
because
it
would
mean
that
Medication,
a
very
key
resource
in
FHIR,
would
be
appear
much
more
complicated,
with
a
lot
of
concepts
that
are
unfamiliar
to
pharmacists.
No
other
core
resources
mandate
the
use
of
profiles.
One
generic
"product"
entity
resource,
profiled
for
use
as
product,
packages,
internal
structure,
tablets
and
ingredients:
Although
these
things
have
some
features
in
common,
this
was
seen
as
too
confusing
in
use.
All
these
items
would
look
the
same
in
the
data
instances
and
at
searchable
end
points.
There
would
be
a
jumble
of
products
containing
products
with
products
inside
those,
consisting
of
products
ensure
that
are
made
of
products.
It
was
felt
it
was
necessary
to
distinguish
as
clearly
as
possible
between
the
main
entities
that
are
common
concepts.
For
example,
a
distinction
between
products
and
packs
exists
in
many
drug
dictionaries.
This
compares
with
resource
concepts
of
Observation,
Condition
and
Procedure,
or
Patient
and
Practitioner.
While
those
closely
related
clinical
entities
have
many
data
items
in
common,
it
is
considered
helpful
to
distinguish
which
examples
are
which
as
clearly
and
simply
as
possible,
correct
and
not
rely
on
context
or
relationships
to
show
what
are
useful,
but
they
are
(or
the
use
of
optional
profiles).
Boundaries:
While
we
seek
to
be
clear
which
parts
of
the
model
to
use
for
which
item,
this
does
occasionally
lead
to
difficult
choices
in
boundaries,
given
the
wide
range
of
products
and
items
that
exist.
This
is
similar
to
issues
sometimes
faced
when
deciding
if
something
is,
for
instance,
actually
a
procedure
or
an
observation
-
or
both
-
or
is
an
observation
or
condition
(or
a
diagnosis).
Having
these
categories
as
resources,
while
not
fool
proof,
does
help
to
guide
the
initial
choices.
A
related
example
is
deciding
on
the
split
between
a
medicated
device
and
a
medication,
or
a
device.
The
workgroup
doesn't
attempt
to
define
clinical
opinion
and
recognizes
that
different
practice
may
occasionally
lead
to
different
implementations
even
with
the
same
resources.
Terminology:
It
is
also
acknowledged
that,
as
with
clinical
data
representation,
there
is
overlap
in
what
can
be
achieved
with
the
resources
and
what
can
be
modelled
with
rich
terminology.
Some
of
what
can
be
represented
by
these
resources
can
also
be
covered
with
structured
code
systems.
The
FHIR
representation
is
intended
to
also
cover
transactional
use
(updates
and
submissions),
rather
than
read-only,
and
recognizes
that
implementers
may
prefer
a
consistent
FHIR
representation
interface
for
both
modes.
BR&R
welcomes
feedback
with
evidence
to
show
if
these
design
decisions
have
made
a
solution
that
works,
and
is
implementable,
for
users
across
a
range
normative
part
of
domains.
the
specification.
Conformance
|
Propose
a
change