FHIR
Release
3
(STU)
CI-Build
Administration
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:
Work
Group
Patient
Administration
|
|
The
Administrative
module
covers
the
base
data
that
is
then
linked
into
the
other
modules
for
clinical
content,
finance/billing,
workflow,
etc.
This
of
course
It
is
built
on
the
FHIR
technology
platform
modules.
Before
any
clinical
data
can
be
recorded,
the
basic
information
on
of
the
patient
must
be
recorded,
and
then
often
the
basis
of
the
interaction
(such
as
an
encounter)
encounter).
Track
Resources
that
contain
details
of
people
involved
in
and
animals
that
are
either
receiving
healthcare,
the
basics
nearly
everything
else
references
care,
or
are
associated
with
these
subjects.
Many
other
resources
refer
back
to
these
as
either
the
subject
of
care,
or
are
somehow
involved
in
that
patient's
record.
| Name | Aliases | Description |
| Patient | SubjectOfCare Client Resident |
Demographics
and
other
administrative
information
about
an
individual
or
animal
|
| RelatedPerson |
Information
about
a
person
that
is
involved
in
a
patient's
health
or
the
care
for
a
patient,
but
who
is
not
the
primary
target
of
|
|
| Person | Demographics and administrative information about a person independent of a specific health-related context. | |
| Group |
Represents
a
defined
collection
of
entities
that
may
be
discussed
or
acted
upon
collectively
but
which
are
not
typically
expected
to
act
|
Implementation Note: Patient linking should also be considered when evaluating searches with references to other resources.
e.g. Searchinge.g., searching for a patient's conditions for a patient.
At present the specification does not define if the links should be also followed to include conditions that reference the linked patients too. We are currently seeking feedback on this.
Implementation Note: The Person resource may be used as a centralized register of people that may eventually be involved in healthcare, and could be used as the central core demographics register.
HoweverHowever, the fields/values in Person are duplicated in the other resources, and in many cases the Person resource will be hosted on external systems.
There are many use cases that require providing and tracking care to households, families, tribes, villages, shared accommodations, etc.
Within these collections of people there can be quite complex networks of relationships between the members.
Group resources representing households are able to act collectively, however groups of this kind can only contain Patients and RelatedPersons (and potentially other Groups).
The
Group
resource
is
used
to
collect
all
the
members
of
the
household,
and
within
that
resource
the
member.involvement
property
is
used
to
describe
the
role
or
relationship
of
the
individual
(member)
has
with
the
group,
not
with
other
members
of
the
group.
The
relationship
between
the
members
of
the
group
can
be
quite
complex,
and
transient
over
time,
and
is
recorded
using
the
PersonalRelationship
resource,
which
connects
2
members
of
the
group
together
(only
members
of
type
Patient
,
RelatedPerson
).
The
PersonalRelationship
resource
can
also
be
used
outside
the
group,
in
these
cases
it
can
also
reference
non
group
members,
including
Person
resources.
Some
use
cases
might
require
a
PersonalRelationship
resource
which
can
overlap
with
the
relationship
defined
inside
the
RelatedPerson
resource.
PersonalRelationship
can
be
used
to
document
"possible/suspected"
relationships,
such
as
a
doctor
recording
that
2
people
may
be
related,
or
in
an
evacuation
centre
trying
to
locate
and
connect
people
may
record
possible
connections
(individuals
may
be
unconscious).
The Group resource should be used when representing an aggregate population, where the system is not tracking the individual members. Examples of aggregate populations include households, a tribe, workers at a job site, or attendees at a sporting event.
Most
clinical
activities
occur
grouped
in
some
way.
Long
term
care
is
typically
covered
by
an
EpisodeOfCare,
where
whereas
short
term
care
is
covered
by
encounters.
Account
associates
the
tracking
of
transactions
back
to
a
Patient
(or
other
resource).
Flag
is
just
used
to
highlight
a
warning
or
other
notification
about
a
patient
(or
other
resource)
| Name | Aliases | Description |
| EpisodeOfCare | Case Program Problem | An association between a patient and an organization / healthcare provider(s) during which time encounters may occur. The managing organization assumes a level of responsibility for the patient during this time. |
| Encounter | Visit |
An
interaction
between
|
| Account |
Cost
|
A financial tool for tracking value accrued for a particular purpose. In the healthcare field, used to track charges for a patient, cost centers, etc. |
| Flag |
Barriers
to
Care,
|
Prospective warnings of potential issues when providing care to the patient. |
Implementation Note: Resources shown with a dotted box are described in other sections of the specification:
CoverageandClaimare from the section on Finance .
Implementation Note: This diagram shows the relationships between resource types. Relationships between instances of resources may include references to multiple instances of the same type. For example, an Encounter and an Account for the same human being may reference separate Patient resource instances, as noted in
Account.subject. Those Patient resources should be linked usingPatient.linkwith a type ofseealso.
Service Provider Directory resources are usually stored in the administration section of applications, and may even be synchronized from external systems.
| Name | Aliases | Description |
| Organization |
A
formally
or
informally
recognized
grouping
of
people
or
organizations
formed
for
the
purpose
of
achieving
some
form
of
collective
action.
|
|
| Location |
Details
and
position
information
for
a
|
|
| Practitioner |
A
person
who
is
directly
or
indirectly
involved
in
the
provisioning
of
|
|
| PractitionerRole |
A
specific
set
of
Roles/Locations/specialties/services
that
a
practitioner
may
|
|
| HealthcareService |
The
details
of
a
healthcare
service
available
at
a
|
|
| Endpoint |
The
technical
details
of
an
endpoint
that
can
be
used
for
electronic
services,
such
as
for
web
services
providing
|
|
| OrganizationAffiliation | Defines an affiliation/assotiation/relationship between 2 distinct organizations, that is not a part-of relationship/sub-division relationship. | |
| InsurancePlan | Details of a Health Insurance plan provided by an organization under an InsuranceProduct. | |
| InsuranceProduct | Details of a Health Insurance product provided by an organization. |
The
Scheduling/Appointments
Scheduling/Appointment
resources
permit
the
planning
of
encounters
to
occur
and
follow
on
with
other
clinical
activities.
| Name | Aliases | Description |
| Schedule | Availability | A container for slots of time that may be available for booking appointments. |
| Slot | A slot of time on a schedule that may be available for booking appointments. | |
| Appointment | A booking of a healthcare event among patient(s), practitioner(s), related person(s) and/or device(s) for a specific date/time. This may result in one or more Encounter(s). | |
| AppointmentResponse | A reply to an appointment request for a patient and/or practitioner(s), such as a confirmation or rejection. |
When the scheduling resources need to identify the specific activity or service that is being scheduled, they may use either a HealthcareService or a coding to represent that activity.
Other
assets
are
often
registered
in
the
administration
system,
and
maintained
as
master
files.
Refer
to
the
device
module
for
additional
details.
| Name | Aliases | Description |
| Device |
This
resource
|
|
|
|
|
|
| DeviceMetric |
Describes
a
measurement,
calculation
or
setting
capability
of
a
|
|
| Substance | A homogeneous material with a definite composition. |
Resources that capture information about research studies, and who is participating in them.
| Name | Aliases | Description |
| ResearchStudy | Study | A scientific study intended to increase health-related knowledge. For example, clinical trials are research studies that involve people. These studies may be related to new ways to screen, prevent, diagnose, and treat disease. They may also study certain outcomes and certain groups of people by looking at data collected in the past or future. |
| ResearchSubject | Study Subject | A ResearchSubject is a participant or object which is the recipient of investigative activities in a research study. |
Implementation Note: The episode and study properties are through standard extensions, and servers might not implement suitable search parameters on these extensions (still to be defined).
If an encounter has a mix of research and non research content, recommend creating 2 encounters in the system, however could derive that information Based on the presence of the extension on the obs/diagnosticreport/immunization etc. which then feeds to episodeofcare and onto account
Patient privacy is handled with security labels and tags in the Resource Meta property. This is the standard way in which that the FHIR specification provides this supporting information to a sub-system that implements it (which is not defined by FHIR).
One of the more common use cases is for marking a patient as being a celebrity .
Note
that
privacy
considerations
apply
to
Person,
Practitioner
and
Practitioner,
RelatedPerson
and
PersonalRelationship
records
in
addition
to
Patient's.
While
Organization,
Location,
Device
and
other
non-person-identifying
records
are
generally
subject
to
less
stringent
security
precautions,
such
data
must
still
be
protected
to
avoid
safety
issues
(e.g.
(e.g.,
someone
maliciously
changing
the
ingredients
associated
with
a
drug
to
cause/fail
to
cause
alerts)
Devices can be linked to Patients. If this occurs, they must be protected as any other patient-linked element
For more general considerations, see the Security and Privacy module .
When considering how a User Identity could be represented in FHIR resources:
Example Identifier for a User Identity:
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "USER",
"display": "User Name"
}
]
},
"value": "username@example.org"
}]
Implementation Note:
Some systems may use e-mail as a unique user identifier. Other systems may use e-mail as one piece of potentially uniquely identifying information. And other systems may use it for communication (where communication may be to validate identity, or for other purposes).
If an e-mail is used as both a user identifier and as a method of communication, then you'd put the same e-mail in both spots (identifier and telecom).
Also, consider that not all individuals that need to be identified may have e-mails, for example, kids in a pediatric setting.
Implementation Note:
The FHIR SMART App Launch specification MAY refer to a FHIR Patient, RelatedPerson, Practitioner, PractitionerRole or Person resource instance in its
fhirUserclaim.
Administration Resources are cornerstone resources that are used by clinical and other domains of the FHIR Standard.
The Patient Administration is currently working through resources that support:
Many
of
the
administrative
resources
are
part
of
the
core
resources
that
most
systems
use
first
and
have
formed
the
basis
for
most
people's
first
experiences
with
FHIR.
However
this
limited
exposure
has
still
to
be
proven
in
all
contexts,
such
as
veterinary,
public
health
and
clinical
research.
FHIR
®©
HL7.org
2011+.
FHIR
Release
3
(STU;
v3.0.2-11200)
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Thurs,
Oct
24,
2019
11:53+1100.
QA
Page
Mon,
Nov
10,
2025
15:23+0000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
Glossary
|
QA
|
Compare
to
DSTU2
R4
|
Compare
to
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change