Administration
This
page
is
part
of
the
FHIR
Specification
(v5.0.0:
R5
-
STU
v6.0.0-ballot3:
Release
6
Ballot
(3rd
Draft)
(see
Ballot
Notes
).
This
is
the
The
current
published
version
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
|
Work
Group
Patient
Administration
|
Standards Status : Informative |
The Administrative module covers the base data that is then linked into the other modules for clinical content, finance/billing, workflow, etc. It is built on the FHIR technology platform modules.
Before any clinical data can be recorded, the basic information of the patient must be recorded, and then often the basis of the interaction (such as an encounter).
Resources that contain details of people and animals that are either receiving 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
| |
| PersonalRelationship | Details about the relationship between 2 individuals. |
Implementation Note: Patient linking should also be considered when evaluating searches with references to other resources. e.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.
However, 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, 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 healthcare provider(s), and/or patient(s) for the purpose of providing healthcare service(s) or assessing the health status of patient(s). |
| Account | Cost center | 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, Alert | 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 .
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 place where services are provided and resources and participants may be stored, found, contained, or accommodated. | |
| Practitioner | A person who is directly or indirectly involved in the provisioning of healthcare or related services. | |
| PractitionerRole | A specific set of Roles/Locations/specialties/services that a practitioner may perform, or has performed at an organization during a period of time. | |
| HealthcareService | The details of a healthcare service available at a location or in a catalog. In the case where there is a hierarchy of services (for example, Lab -> Pathology -> Wound Cultures), this can be represented using a set of linked HealthcareServices. | |
| Endpoint | The technical details of an endpoint that can be used for electronic services, such as for web services providing XDS.b, a REST endpoint for another FHIR server, or a s/Mime email address. This may include any security context information. | |
| 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
|
The 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.
| Name | Aliases | Description |
| Device |
This
resource
describes
the
properties
(regulated,
has
real
time
clock,
etc.),
|
|
| DeviceDefinition | This is a specialized resource that defines the characteristics and capabilities of a device. | |
| DeviceMetric | Describes a measurement, calculation or setting capability of a device. The DeviceMetric resource is derived from the ISO/IEEE 11073-10201 Domain Information Model standard, but is more widely applicable. | |
| 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 |
|
A
scientific
study
|
| 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. 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
R5
hl7.fhir.core#5.0.0
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Sun,
Mar
26,
2023
15:26+1100.
Tue,
Apr
1,
2025
12:26+1100.
Links:
Search
|
Version
History
|
Contents
|
Glossary
|
QA
|
Compare
to
R4
|
Compare
to
R4B
R5
|
|
Propose
a
change