Demographics
and
other
administrative
information
about
an
individual
or
animal
receiving
care
or
other
health-related
services.
Demographics and other administrative information about an individual or animal receiving care or other health-related services.
5.1.1
Scope
and
Usage
Scope and Usage This
Resource
covers
data
about
patients
and
animals
involved
in
a
wide
range
of
health-related
activities,
including:
Curative
activities
Psychiatric
care
Social
services
Pregnancy
care
Nursing
and
assisted
living
Dietary
services
Tracking
of
personal
health
and
exercise
data
The
data
in
the
Resource
covers
the
"who"
information
about
the
patient:
its
attributes
are
focused
on
the
demographic
information
necessary
to
support
the
administrative,
financial
and
logistic
procedures.
A
Patient
record
is
generally
created
and
maintained
by
each
organization
providing
care
for
a
patient.
A
patient
or
animal
receiving
care
at
multiple
organizations
may
therefore
have
its
information
present
in
multiple
Patient
Resources.
Not
all
concepts
are
included
within
the
base
resource
(such
as
race,
ethnicity,
organ
donor
status,
nationalilty,
etc.),
but
may
be
found
in
This Resource covers data about patients and animals involved in a wide range of health-related activities, including:
Curative activities
Psychiatric care
Social services
Pregnancy care
Nursing and assisted living
Dietary services
Tracking of personal health and exercise data
The data in the Resource covers the "who" information about the patient: its attributes are focused on the demographic information necessary to support the administrative, financial and logistic procedures. A Patient record is generally created and maintained by each organization providing care for a patient. A patient or animal receiving care at multiple organizations may therefore have its information present in multiple Patient Resources.
Not all concepts are included within the base resource (such as race, ethnicity, organ donor status, nationalilty, etc.), but may be found in
profiles
defined
for
specific
jurisdictions
(e.g.,
US
Meaningful
Use
Program)
or
standard
extensions
defined for specific jurisdictions (e.g., US Meaningful Use Program) or
standard extensions
.
Such
fields
vary
widely
between
jurisdictions
and
often
have
different
names
and
valuesets
for
the
similar
concepts,
but
they
are
not
similar
enough
to
be
able
to
map
and
exchange
This
resource
is
referenced
by
Such fields vary widely between jurisdictions and often have different names and valuesets for the similar concepts, but they are not similar enough to be able to map and exchange
A
contact
party
(e.g.
guardian,
partner,
friend)
for
the
patient
A contact party (e.g. guardian, partner, friend) for the patient
SHALL
at
least
contain
a
contact's
details
or
a
reference
to
an
organization
SHALL at least contain a contact's details or a reference to an organization
The
period
during
which
this
contact
person
or
organization
is
valid
to
be
contacted
relating
to
this
patient
The period during which this contact person or organization is valid to be contacted relating to this patient
A
list
of
Languages
which
may
be
used
to
communicate
with
the
patient
about
his
or
her
health
A list of Languages which may be used to communicate with the patient about his or her health
The
language
which
can
be
used
to
communicate
with
the
patient
about
his
or
her
health
The language which can be used to communicate with the patient about his or her health
Language
Language (
(
Required
)
A
contact
party
(e.g.
guardian,
partner,
friend)
for
the
patient
A contact party (e.g. guardian, partner, friend) for the patient
SHALL
at
least
contain
a
contact's
details
or
a
reference
to
an
organization
SHALL at least contain a contact's details or a reference to an organization
The
period
during
which
this
contact
person
or
organization
is
valid
to
be
contacted
relating
to
this
patient
The period during which this contact person or organization is valid to be contacted relating to this patient
A
list
of
Languages
which
may
be
used
to
communicate
with
the
patient
about
his
or
her
health
A list of Languages which may be used to communicate with the patient about his or her health
The
language
which
can
be
used
to
communicate
with
the
patient
about
his
or
her
health
The language which can be used to communicate with the patient about his or her health
Language
Language (
(
Required
)
The
nature
of
the
relationship
between
a
patient
and
a
contact
person
for
that
patient.
The nature of the relationship between a patient and a contact person for that patient.
The
type
of
link
between
this
patient
resource
and
another
patient
resource.
The type of link between this patient resource and another patient resource.
pat-1
:
On
Patient.contact:
SHALL
at
least
contain
a
contact's
details
or
a
reference
to
an
organization
(xpath
on
f:Patient/f:contact:
f:name
or
f:telecom
or
f:address
or
f:organization
: On Patient.contact: SHALL at least contain a contact's details or a reference to an organization (
expression
on Patient.contact:
name or telecom or address or organization
)
Notes:
multipleBirth
can
be
either
expressed
as
a
Boolean
(just
indicating
whether
the
patient
is
part
of
a
multiple
birth)
or
as
an
integer,
indicating
the
actual
birth
order.
Patient
records
may
only
be
in
one
of
two
statuses:
in
use
(active=true)
and
not
in
use
(active=false).
A
normal
record
is
active,
i.e.
it
is
in
use.
Active
is
set
to
'false'
when
a
record
is
created
as
a
duplicate
or
in
error.
A
record
does
not
need
to
be
linked
to
be
inactivated.
The
Notes:
multipleBirth can be either expressed as a Boolean (just indicating whether the patient is part of a multiple birth) or as an integer, indicating the actual birth order.
Patient records may only be in one of two statuses: in use (active=true) and not in use (active=false). A normal record is active, i.e. it is in use. Active is set to 'false' when a record is created as a duplicate or in error. A record does not need to be linked to be inactivated.
The
link
element
is
used
to
assert
that
two
or
more
Patient
resources
are
both
about
the
same
actual
patient.
See
below
for
further
discussion
There
should
be
only
one
preferred
language
(Language.preference
=
true)
per
mode
of
expression.
The
Contact
for
a
Patient
has
an
element
organization
,
this
is
for
use
with
guardians
or
business
related
contacts
where
just
the
element is used to assert that two or more Patient resources are both about the same actual patient. See below for further discussion
There should be only one preferred language (Language.preference = true) per mode of expression.
The Contact for a Patient has an element
organization
is
relevant.
, this is for use with guardians or business related contacts where just the organization is relevant.
5.1.3
Patient
id's
and
Patient
resource
id's
Patient id's and Patient resource id's A
Patient
record's
Resource
Id
can
never
change.
For
this
reason
the
identifiers
with
which
humans
are
concerned
(often
called
MRN
-
Medical
Record
Number,
or
UR
-
Unit
Record)
should
not
be
used
for
the
resource's
id,
since
MRN's
may
change,
i.e.
as
a
result
of
having
duplicate
records
of
the
same
patient.
Instead
they
should
be
represented
in
the
A Patient record's Resource Id can never change. For this reason the identifiers with which humans are concerned (often called MRN - Medical Record Number, or UR - Unit Record) should not be used for the resource's id, since MRN's may change, i.e. as a result of having duplicate records of the same patient. Instead they should be represented in the
Patient.identifier
list
where
they
can
be
managed.
This
is
also
useful
for
the
case
of
institutions
that
have
acquired
multiple
numbers
because
of
mergers
of
patient
record
systems
over
time.
list where they can be managed. This is also useful for the case of institutions that have acquired multiple numbers because of mergers of patient record systems over time.
5.1.4
Linking
Patients
Linking Patients The
The
link
element
is
used
to
assert
that
patient
resources
refer
to
the
same
patient.
This
element
is
used
to
support
the
following
scenarios
where
multiple
patient
records
exist:
element is used to assert that patient resources refer to the same patient. This element is used to support the following scenarios where multiple patient records exist:
5.1.4.1
Duplicate
Patient
records
Duplicate Patient records Managing
Patient
registration
is
a
well
known
difficult
problem.
Around
2%
of
registrations
are
in
error,
mostly
duplicate
records.
Sometimes
the
duplicate
record
is
caught
fairly
quickly
and
retired
before
much
data
is
accumulated.
In
other
cases,
substantial
amounts
of
data
may
accumulate.
By
using
a
link
of
type
'replace',
the
record
containing
such
a
link
is
marked
as
a
duplicate
and
the
link
points
forward
to
a
record
that
should
be
used
instead.
Note
that
the
record
pointed
to
may
in
its
turn
have
been
identified
as
created
in
error
and
forward
to
yet
another
Patient
resource.
Records
that
replace
another
record,
do
not
point
back
to
the
replaced
record.
Managing Patient registration is a well known difficult problem. Around 2% of registrations are in error, mostly duplicate records. Sometimes the duplicate record is caught fairly quickly and retired before much data is accumulated. In other cases, substantial amounts of data may accumulate. By using a link of type 'replace', the record containing such a link is marked as a duplicate and the link points forward to a record that should be used instead. Note that the record pointed to may in its turn have been identified as created in error and forward to yet another Patient resource. Records that replace another record, do not point back to the replaced record.
5.1.4.2
Patient
record
in
a
Patient
index
Patient record in a Patient index A
Patient
record
may
be
present
in
a
system
that
acts
as
a
Patient
Index:
it
maintains
a
(summary
of)
patient
data
and
a
list
of
one
or
more
servers
that
it
are
known
to
hold
a
more
comprehensive
and/or
authorative
record
of
the
same
patient.
The
link
type
'refer'
is
used
denote
such
a
link.
Note
that
linked
records
may
contain
contradictory
information.
The
record
referred
to
does
not
point
back
to
the
referring
record.
A Patient record may be present in a system that acts as a Patient Index: it maintains a (summary of) patient data and a list of one or more servers that it are known to hold a more comprehensive and/or authorative record of the same patient. The link type 'refer' is used denote such a link. Note that linked records may contain contradictory information. The record referred to does not point back to the referring record.
5.1.4.3
Distributed
Patient
record
Distributed Patient record In
a
distributed
architecture,
multiple
systems
keep
separate
patient
records
concerning
the
same
patient.
These
records
are
not
considered
duplicates,
but
contain
a
distributed,
potentially
overlapping
view
of
the
patient's
data.
Each
such
record
may
have
its
own
focus
or
maintaining
organization
and
there
need
not
be
a
sense
of
one
record
being
more
complete
or
more
authorative
than
another.
In
such
cases,
links
of
type
'see
also'
can
be
used
to
point
to
other
patient
records.
It
is
not
a
requirement
that
such
links
are
bilateral.
In a distributed architecture, multiple systems keep separate patient records concerning the same patient. These records are not considered duplicates, but contain a distributed, potentially overlapping view of the patient's data. Each such record may have its own focus or maintaining organization and there need not be a sense of one record being more complete or more authorative than another. In such cases, links of type 'see also' can be used to point to other patient records. It is not a requirement that such links are bilateral.
5.1.5
Patient
vs.
Person
vs.
Patient.Link
Patient vs. Person vs. Patient.Link The
Person
resource
on
the
surface
appears
to
be
very
similar
to
the
Patient
resource,
and
the
usage
for
it
is
very
similar
to
using
the
Patient.Link
capability.
The
intention
of
the
Person
resource
is
to
be
able
to
link
instances
of
resources
together
that
are
believed
to
be
the
same
individual.
This
includes
across
resource
types,
such
as
RelatedPerson,
Practitioner,
Patient
and
even
other
Person
resources.
The
Patient
Link
however
is
only
intended
to
be
used
for
Patient
resources.
The
primary
use
case
for
the
Person
resource
is
to
be
able
to
support
person
registries
that
do
not
necessarily
have
a
healthcare
context,
and
are
able
to
identify
and
quantify
confidence
levels
that
this
is
the
same
person.
This
could
include
consumer
portals
where
the
maintainer
of
the
person
information
is
the
actual
person
themselves.
A
system
could
use
the
Person
entry
to
cross
check
changes
to
information
applied
to
one
part
of
a
record
to
values
in
another
system;
e.g.,
when
moving,
a
consumer
updates
his
contact
numbers
and
address
in
his
person
record,
and
then
a
Patient
Administration
system
is
able
to
see
that
this
data
is
changed
and
prompt
the
organization
to
follow
up
with
the
patient
that
was
linked
to
the
person
record
if
they
want
their
details
updated,
or
if
they
no
longer
need
services
and
they
should
be
cancelled,
as
they've
moved
from
the
area.
The Person resource on the surface appears to be very similar to the Patient resource, and the usage for it is very similar to using the Patient.Link capability.
The intention of the Person resource is to be able to link instances of resources together that are believed to be the same individual. This includes across resource types, such as RelatedPerson, Practitioner, Patient and even other Person resources.
The Patient Link however is only intended to be used for Patient resources.
The primary use case for the Person resource is to be able to support person registries that do not necessarily have a healthcare context, and are able to identify and quantify confidence levels that this is the same person.
This could include consumer portals where the maintainer of the person information is the actual person themselves.
A system could use the Person entry to cross check changes to information applied to one part of a record to values in another system; e.g., when moving, a consumer updates his contact numbers and address in his person record, and then a Patient Administration system is able to see that this data is changed and prompt the organization to follow up with the patient that was linked to the person record if they want their details updated, or if they no longer need services and they should be cancelled, as they've moved from the area.
5.1.6
Patient.contact
vs.
RelatedPerson
Patient.contact vs. RelatedPerson The
contact
element
on
the
Patient
Resource
should
be
used
for
storing
people
to
contact
information.
Where
a
system
has
a
separate
record
for
other
people
for
purposes
other
than
just
the
contact
details,
the
RelatedPerson
resource
should
be
used.
This
includes
cases
where
these
related
people
are
actually
contributing
to
the
record,
and
need
to
be
referenced
individually
(e.g.
CarePlan.Participant,
Encounter,
DocumentReference,
Appointment)
where
the
Patient.Contact
component
cannot
be
used.
It
is
not
expected
that
these
records
will
be
used
for
recording
the
primary
care
provider;
this
information
should
be
stored
in
the
Patient.careProvider
field.
The contact element on the Patient Resource should be used for storing people to contact information. Where a system has a separate record for other people for purposes other than just the contact details, the RelatedPerson resource should be used.
This includes cases where these related people are actually contributing to the record, and need to be referenced individually (e.g. CarePlan.Participant, Encounter, DocumentReference, Appointment) where the Patient.Contact component cannot be used.
It is not expected that these records will be used for recording the primary care provider; this information should be stored in the Patient.careProvider field.
5.1.7
Merging
records
Merging records This
specification
does
not
specify
merge
functionality:
if
multiple
patient
records
are
found
to
be
duplicates,
they
can
be
linked
together,
as
described
above.
These
links
merely
express
the
relationship
between
records,
and
in
the
case
of
a
replacement
link,
indicate
a
"master"
record.
This
specification
does
not
mandate
that
FHIR
servers
migrate
information
between
such
records
on
finding
such
a
link.
Note:
Health
information
administrators
may
call
the
process
"merging",
but
it
is
often
implemented
as
"linking"
at
the
record
level
Servers
are
allowed
to
implement
merging/record
migration
even
though
it
is
not
mandated.
DSTU
Note:
We
are
seeking
input
from
the
implementer
community
on
what
effect
linking/merging/unlinking
should
have
on
other
functionality
such
as
the
GET
operation
(where
the
result
is
the
old
version
of
the
Patient),
searching,
reverse
includes,
etc.;
e.g.,
should
observation
resources
from
all
linked/merged
patients
be
returned
when
querying
for
one
of
them?
How
should
an
unlink
behavior
be
done?
(Assuming
that
no
data
was
"re-allocated"
as
part
of
merge)
These
suggested
updated
behaviors
could
be
the
subject
of
a
future
connectathon.
Feedback
here
This specification does not specify merge functionality: if multiple patient records are found to be duplicates, they can be linked together, as described above. These links merely express the relationship between records, and in the case of a replacement link, indicate a "master" record. This specification does not mandate that FHIR servers migrate information between such records on finding such a link. Note:
Health information administrators may call the process "merging", but it is often implemented as "linking" at the record level
Servers are allowed to implement merging/record migration even though it is not mandated.
DSTU Note:
We are seeking input from the implementer community on what effect linking/merging/unlinking should have on other functionality such as the GET operation (where the result is the old version of the Patient), searching, reverse includes, etc.; e.g., should observation resources from all linked/merged patients be returned when querying for one of them? How should an unlink behavior be done? (Assuming that no data was "re-allocated" as part of merge) These suggested updated behaviors could be the subject of a future connectathon.
5.1.8
Patient
Matching
using
an
MPI
Patient Matching using an MPI A
Master
Patient
Index
(
A Master Patient Index (
MPI
MPI )
is
a
service
used
to
manage
patient
identification
in
a
context
where
multiple
patient
databases
exist.
Healthcare
applications
and
middleware
use
the
MPI
to
match
patients
between
the
databases,
and
as
new
patient
details
are
encountered.
MPIs
are
highly
specialized
applications,
often
tailored
extensively
to
the
institution's
particular
mix
of
patients.
MPIs
can
also
be
run
on
a
regional
and
national
basis.
To
ask
an
MPI
to
match
a
patient,
clients
use
the
"mpi"
) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and as new patient details are encountered. MPIs are highly specialized applications, often tailored extensively to the institution's particular mix of patients. MPIs can also be run on a regional and national basis.
GET [base]/Patient?_query=mpi¶meters...
The
response
from
an
"mpi"
query
is
a
set
of
patient
records,
ordered
from
most
likely
to
least
likely.
If
there
are
not
patient
matches,
the
MPI
SHALL
return
an
empty
search
set
with
no
error,
but
may
include
an
operation
outcome
with
further
advice.
All
patient
records
SHALL
have
a
score
from
0
to
1,
where
1
is
the
most
certain
match,
along
with
an
The response from an "mpi" query is a set of patient records, ordered from most likely to least likely. If there are not patient matches, the MPI SHALL return an empty search set with no error, but may include an
operation outcome
with further advice. All patient records SHALL have a score from 0 to 1, where 1 is the most certain match, along with an
extension
"patient-mpi-match"
that
indicates
the
MPI's
position
on
the
match
quality:
that indicates the MPI's position on the match quality:
<entry>
<resource>
<Patient>
<!-- patient details -->
</Patient>
</resource>
<search>
<extension url="http://hl7.org/fhir/StructureDefinition/patient-mpi-match">
<valueCode value="probable"/>
</extension>
<score value="0.80"/>
</search>
</entry>
The
patient-mpi-match
extension
has
one
of
the
following
codes
:
This
record
meets
the
MPI
criteria
to
be
automatically
considered
as
a
full
match.
This record meets the MPI criteria to be automatically considered as a full match.
probable
This
record
is
a
close
match,
but
not
a
certain
match.
Additional
review
(e.g.
by
a
human)
may
be
required
before
using
this
as
a
match.
This record is a close match, but not a certain match. Additional review (e.g. by a human) may be required before using this as a match.
possible
This
record
may
be
a
matching
one.
Additional
review
(e.g.
by
a
human)
SHOULD
be
performed
before
using
this
as
a
match.
This record may be a matching one. Additional review (e.g. by a human) SHOULD be performed before using this as a match.
certainly-not
This
record
is
known
not
to
be
a
match.
Note
that
usually
non-matching
records
are
not
returned,
but
in
some
cases
records
previously
or
likely
considered
as
a
match
may
specifically
be
negated
by
the
MPI.
This record is known not to be a match. Note that usually non-matching records are not returned, but in some cases records previously or likely considered as a match may specifically be negated by the MPI.
One
optional
parameter
to
the
MPI
match
operation
is
"userid",
which
is
used
to
pass
the
user
details
from
a
trusted
client
to
the
MPI.
This
may
be
used
by
the
MPI
to
restrict
the
possible
matches
that
are
returned,
based
on
the
user's
rights.
For
example,
a
staff
member
covered
by
policies,
etc.,
may
well
get
a
different
result
than
a
patient
trying
to
find
their
own
record.
Note
that
this
parameter
is
used
where
the
user
would
not
be
expected
to
log
in
to
the
MPI
directly;
whether
this
is
appropriate
or
not
is
a
deployment
choice.
A
formal
definition
for
the
MPI
query
is
published.
DSTU
Note:
This
is
the
first
draft
of
this
approach,
as
a
result
of
connectathon
testing.
Feedback
is
sought
here
One optional parameter to the MPI match operation is "userid", which is used to pass the user details from a trusted client to the MPI. This may be used by the MPI to restrict the possible matches that are returned, based on the user's rights. For example, a staff member covered by policies, etc., may well get a different result than a patient trying to find their own record. Note that this parameter is used where the user would not be expected to log in to the MPI directly; whether this is appropriate or not is a deployment choice.
Patient's
nominated
care
provider,
could
be
a
care
manager,
not
the
organization
that
manages
the
record
Patient's nominated care provider, could be a care manager, not the organization that manages the record
A
portion
of
either
family
or
given
name
using
some
kind
of
phonetic
matching
algorithm
A portion of either family or given name using some kind of phonetic matching algorithm
Patient
identifier
active
deceased[x]
contact
organization
<!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension --> <identifier><!-- 0..* Identifier An identifier for this patient --></identifier> <active value="[boolean]"/><!-- 0..1 Whether this patient's record is in active use --> <name><!-- 0..* HumanName A name associated with the patient --></name> <telecom><!-- 0..* ContactPoint A contact detail for the individual --></telecom> <gender value="[code]"/><!-- 0..1 male | female | other | unknown --> <birthDate value="[date]"/><!-- 0..1 The date of birth for the individual --> <deceased[x]><!-- 0..1 boolean|dateTime Indicates if the individual is deceased or not --></deceased[x]> <address><!-- 0..* Address Addresses for the individual --></address> <maritalStatus><!-- 0..1 CodeableConcept Marital (civil) status of a patient --></maritalStatus>
0..1 Reference(Organization) Organization that is associated with the contact --></organization> <period><!-- 0..1 Period The period during which this contact person or organization is valid to be contacted relating to this patient --></period> </contact> <animal> <!-- 0..1 This patient is known to be an animal (non-human) --> <species><!-- 1..1 CodeableConcept E.g. Dog, Cow --></species> <breed><!-- 0..1 CodeableConcept E.g. Poodle, Angus --></breed> <genderStatus><!-- 0..1 CodeableConcept E.g. Neutered, Intact --></genderStatus> </animal> <communication> <!-- 0..* A list of Languages which may be used to communicate with the patient about his or her health --> <language><!-- 1..1 CodeableConcept The language which can be used to communicate with the patient about his or her health
