This page is part of the FHIR Specification (v1.6.0: STU 3 Ballot 4). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2
FHIR Infrastructure Work Group | Maturity Level: N/A | Ballot Status: Draft |
The FHIR specification defines a set of resources, and an infrastructure for handling resources. In order to use FHIR to create solutions for integration requirements, implementers must map their problems to resources and their content.
The resources are classified into 6 sections:
This page describes the resources and their functional intent in more detail to assist implementers to understand their purpose and scope, and their supporting classifications.
Where to find common concepts in this specification:
Concept | Example | Where to find |
Clinical Findings | ||
Laboratory Results | Blood panels such as CBC with Differential, Liver Panel, etc. | DiagnosticReport with Observations |
Imaging Study Findings | CT Scans, MRI, Plain Radiographs, Ultrasounds) | DiagnosticReport (some with Observations) |
Diagnostic Test Results | EKG, pulmonary function test, EEG | Observations (and maybe a DiagnosticReport) |
Vital Signs | Temperature, Blood Pressure, Heart Rate, Respiratory Rate | Observation |
Other Physical Exam Findings | Auscultation findings | Observation |
Pulmonary Artery Catheter readings | Pulmonary artery pressure | Observation |
Patient Problems, Allergies and Adverse Events | ||
Allergy | Food or drug allergies | AllergyIntolerance |
Clinical Diagnosis | Diabetes, Congestive Heart Failure | Condition |
Adverse Event / Reaction | Adverse reaction to an agent, falls, adverse surgical events, hospital infections | (not done yet) |
Patient History | ||
Chief Complaint | Cough, Pain, Fever, Fatigue | Condition |
Past Surgical History | Appendectomy, Hernia repair | Procedure |
Past Medical History | Diabetes, Congestive heart failure | Condition |
MAR (Medication Administration Record) | Warfarin 5mg PO administered on 12/10/2013 at 3pm | MedicationAdministration |
Home Meds | Warfarin 5mg, 30 day supply, dispensed on 12/01/2013 | MedicationStatement |
Social History | Sexual behavior, Smoking status, Alcohol intake, Illicit drug use | Observation |
Family History | Mother has diabetes | FamilyMemberHistory |
Signs & Symptoms | from a review of systems- Pain, Fever | Condition |
Suggested Physician Orders | ||
Proposal for a laboratory test | A blood panel, a stool analysis | DiagnosticRequest |
Proposal for an imaging procedure | CT Scan, MRI, X-Rays | DiagnosticRequest |
Proposed Diet Order | An oral diet order | NutritionRequest |
Proposed respiratory order | Oxygen delivery | Not done yet |
Proposed Medications | Aspirin, Lisinopril | MedicationOrder |
Proposed Supply | Wheel Chair, Food Tray | SupplyRequest |
Interdisciplinary Care Planning | ||
Patient Goal | Reduce risk of falls, lose weight | Goal (as part of a CarePlan) |
Intervention | Patient assessments | ProcedureRequest |
In addition, to the information on this page, see also Common Use Cases.
In addition to the overall classification above, Resources and the data elements in them are tapped into an overall ontology that provides consistent meaning across the resources.
One of the most fundamental aspects of a resource is tense - where it fits into the time line. Some resources are records of past events, some are plans for the future, etc. This table summarizes the categories:
Note that even future records end up in the past after the event they are concerned with passes.
AllergyIntolerance
, Condition
, and Procedure
are common resources that appear throughout
the patient record - summaries of the patient status or history.
FamilyMemberHistory
tracks significant health issues for relatives of the patient, since these are significant risk factors for the patient.
These resources may be found in patient, episode, discharge summaries, and consultation records.
ClinicalImpression
(aka ClinicalAssessment) records the core of a clinical consultation/assessment/impression.
When a single text note is inserted directly in the patient record, this is typically a
ClinicalImpression.summary. A RiskAssessment
is an assessment - usually, but not necessarily, by
a decision support engine of the likely outcomes of some course of action for a patient.
A DetectedIssue
is an active alert that there is a clinical issue with/between one or more active or
proposed clinical actions for a patient. One way it may be used is as part of an error message in response
to an attempted operation.
Resource | Category | RIM | Lifecycle |
AllergyIntolerance | Ongoing | Act | This has a Current List |
Condition | Ongoing | Act | This has a Current List |
Procedure | Past | Act | Clinical Workflow |
FamilyMemberHistory | Past | Act | |
ClinicalImpression | Past | Act | |
RiskAssessment | Present | Act | Clinical Workflow |
DetectedIssue | Present | Act |
These resources support planning of care provision - care and treatment plans.
CarePlan
and Goal
are the primary structures around which future planning for the patient
is based. These are used to define care and treatement planned for a patient in the future, and may be
updated and adjusted as ongoing care is provided.
ReferralRequest
is the basis for a proposed/requested transfer of care from
one clinician to another. Typically, these are associated with a transfer
of records, and a physical relocation of the patient, but neither of these
are required. A ProcedureRequest
records a request for a procedure to be carried out.
NutritionRequest
is a request to supply a diet, formula feeding (enteral) or oral nutritional supplement to a patient
and VisionPrescription
contains the details of visual aids requested for a patient.
Resource | Category | RIM | Lifecycle |
CarePlan | Ongoing | Act | |
Goal | Future | Act | Clinical Workflow |
ReferralRequest | Future | Act | Clinical Workflow |
ProcedureRequest | Future | Act | Clinical Workflow |
NutritionRequest | Future/Ongoing | Act | |
VisionPrescription | Future | Act |
Supports the medication and immunization processes. Some points of note:
MedicationOrder
MedicationStatement
if records are unclearMedication
resource is not used. It is generally used to represent information in formularies and to describe custom formulationsResource | Category | RIM | Lifecycle |
Medication | Unrelated | Role | |
Medication | Medication | Act | Clinical Workflow |
MedicationDispense | Past | Act | Clinical Workflow |
MedicationOrder | Future | Act | Request/Order. This has a current List |
MedicationStatement | Ongoing / Past | Act | Entity Availability Workflow. This has a Current List |
Immunization | Past | Act | |
ImmunizationRecommendation | Future | Act |
Resources concerned with observing the patient, and the diagnostic service process built around this.
The Observation
resource is a widely used general purpose tool. Typical uses include
recording the following kinds of data:
and many more things beside. Note that 'everything is an observation', but implementations should not use Observation where Condition is more appropriate.
DiagnosticRequest
and DiagnosticReport
support the overall diagnostic process.
A DiagnosticReport connects the process of 'reporting', linking process identifiers, visual
presentations of a report, and conclusions/interpretations with the Observations. DiagnosticRequests capture the request from an authorized clinician to initiate the diagnostic process.
Specimen
and BodySite
are used to record the details of specimen collection
although BodySite can also be used with other resources (e.g. Operation location details on a Procedure).
The resources ImagingManifest
and ImagingStudy
are provided to make links to diagnostic
images available within the clinical record, where the actual images will be provided by
dedicated systems (the Media resource is intended for sharing
actual images directly, which is not generally suitable for high resolution, high volume
diagnostic images).
Resource | Category | RIM | Lifecycle |
Observation | Past | Act | |
DiagnosticReport | Past | Act | Entity Availability Workflow |
DiagnosticRequest | Future | Act | Request/Order |
Specimen | Unrelated | Role | Entity Availability Workflow |
BodySite | Unrelated | Role | |
ImagingManifest | Past | Act | |
ImagingStudy | Past | Act |
These resources provide support for identifying the various entities involved in healthcare: people, organizations, substances, devices, etc.
The Patient
resource represents the recipient of healthcare. This concept
is not always referred to as a 'patient' - other words such as client, customer, resident,
etc. are commonly used, but in this specification, the recipient of healthcare is
simply known as the patient. The patient resource includes basic demographics and
next of kin information.
The Practitioner
resource is used to identify and describe any person
(or even animal) involved in the provision of care, including doctors, nurses,
clerical staff, specialist support staff, etc.
RelatedPerson
is used to describe individuals who are related
to the patient who are involved in the healthcare process, beyond merely
being next of kin - they may sign documents, administer medications, be the
source of information, or simply provide care by chance at an accident.
Resource | Category | RIM | Lifecycle |
Patient | Unrelated | Role | Entity Availability Workflow |
Practitioner | Unrelated | Role | |
RelatedPerson | Unrelated | Role |
In most provision of healthcare, some Organization
is responsible and accountable
for the care, and references appear throughout the clinical record. The organization is
a legal entity that may operate at multiple locations. A HealthcareService
represents the services offered by one or more organizations at a single location.
A Group
is used to describe one or more individuals - usually people, though
other kinds of entities are allowed. Typically, these are used with aggregate reporting,
though sometimes care is provided to a set of individuals at once (some counseling
procedures, public health procedures, herds of cattle, etc.).
Resource | Category | RIM | Lifecycle |
Organization | Unrelated | Role | |
HealthcareService | Unrelated | Role | |
Group | Unrelated | Entity |
Location
- for where things happen. Locations are either by instance (e.g.
this particular room at a given address or GPS coordinates) or by kind (e.g. the back
of some ambulance). The same applies to Substance
, for some kind of
material (e.g. chemical) used in healthcare - it may refer to an identified instance
(e.g. bottle) or a kind of chemical.
The Person
resource is used to track associations between different
patient records across the provision of healthcare (e.g. "master patient indexes").
Person resources are not referred directly from other resources; their use is for
dedicated person registries.
Resource | Category | RIM | Lifecycle |
Location | Unrelated | Role | Entity Availability Workflow |
Substance | Unrelated | Entity | |
Person | Unrelated | Entity |
Device
is used to track non-consumable manufactured materials through the
healthcare process. It includes implants, large instruments, non-medical things (including
software), and containers. Devices - and therefore the device resource - have many purposes,
including stock control, locating devices, and tracking implants.
DeviceComponent
and DeviceMetric
are used to report the status
and characteristics of the kinds of medical devices that produce a stream of one or
more data points (Observations), usually about a patient.
Resource | Category | RIM | Lifecycle |
Device | Unrelated | Role | |
DeviceComponent | Unrelated | Role | |
DeviceMetric | Unrelated | Role |
Encounter
tracks an interaction between a patient and healthcare provider(s).
Specifically, this resource tracks the administrative details of the interaction, not the
clinical details (though these usual link to it). Aliases for this include
'admission', 'consultation', and sometimes 'appointment'. Encounters may be nested - e.g.
when the patient goes to physiotherapy as part of a hospital admission.
An EpisodeofCare
is an association between a patient and a care provider
that may last over several encounters. The purpose of EpisodeOfCare is track a provider
(person or organization) that has an interest in the ongoing care of the patient.
A Communication
is a record of a formal communication with a
patient or another party with an interest in their care - a letter, email, phone call etc.
A Flag
is warning maintained in the system that alerts care providers to potential
issues they should be aware of when providing care to a patient, or at a location.
Resource | Category | RIM | Lifecycle |
Encounter | Future / Ongoing / Past | Act | |
EpisodeOfCare | Act | ||
Communication | Past | Act | Clinical Workflow |
Flag | Ongoing | Act | Entity Availability Workflow |
These resources are concerned with planning times and locations for future delivery of care:
Schedule
describes a set of times in the future that a service or individual may be availableSlot
is an instance of a time in a schedule that may be reservedAppointment
is proposed or confirmed future event, with a list of participants who may or may not have confirmed their attendanceAppointmentResponse
is an individual's acceptance or rejection of an appointmentThe scheduling systems is closely aligned with the iCal system so that systems may leverage web bookings while maintaining integrity with the rest of the clinical record.
Resource | Category | RIM | Lifecycle |
Appointment | Future | Act | |
AppointmentResponse | Future | Act | |
Schedule | Future | ||
Slot | Future | Act |
Todo: these resources are all draft. Bringing them to maturity and testing their support for real-world scenarios is a major ongoing focus of the FHIR project.
Resource | Category | RIM | Lifecycle |
Task | Present | Act | |
CommunicationRequest | Future | Act | Request/Order |
DeviceUseRequest | Present | Act | Request/Order |
DeviceUseStatement | Past | Act | |
ProcessRequest | Present | Act | Request/Order |
ProcessResponse | Present | Act | |
SupplyDelivery | Present | Act | |
SupplyRequest | Future | Act |
These resources provide generally useful functionality, and/or are referenced directly from the base FHIR framework (RESTful API, messaging, documents).
Questionnaire
and QuestionnaireResponse
are for general purpose data collection
from a patient or other information source. They represent the set of questions to be answered, and an individual's responses to those questions. A questionnaire can contain any kind of data, including the data represented in all other
resources. It is anticipated that the data will be processed into other kinds of resources for further
usage and exchange.
The Provenance
resource is used to make statements about where
a resource came from - that is, who, what, why, when and where for its creation.
This may be used in assessing the integrity, reliability and usefulness of a resource
or the data in it. Note that many resources contain some limited amount of this
information directly, because it is deemed essential to using/finding/filtering/understanding
the resource directly. Whenever information is found in both a resource, and in the
provenance statements for the resource, it is expected to be the same.
An AuditEvent
is an observation by a system that a record was altered (created,
updated, deleted) or otherwise accessed (queried, transferred, copied), with audit information about the event. Typically, the provenance record
is created before the resource is altered, by the (sub)system causing the change to the
resource, while the audit record is created after the change by the (sub)system responsible
for storing it.
Resource | Category | RIM | Lifecycle |
Questionnaire | Past | Act | |
QuestionnaireResponse | Past | Act | |
Provenance | Past | Act | |
AuditEvent | Past | Act |
In clinical practice, there are use cases for both exchanging information in a highly granular form, and for exchanging it in packages known as 'documents'. This specification provides two different kinds of support for creating and exchanging documents:
Composition
allows for the construction of a detailed document package using other resources for all content of the documentDocumentReference
and DocumentManifest
are used for referring to and/or exchanging external documents (CDA , PDF, other kinds of records, etc.) either as single documents or groups of documents respectively
The List
resource is used to link a set of other kinds of resources into a single list. This might
be done for many reasons - maintaining a list of work to do, of patients of interest, or of a set of current problems for a patient.
Resource | Category | RIM | Lifecycle |
Composition | Unrelated | Unrelated | |
DocumentManifest | Unrelated | Document | Entity Availability Workflow |
DocumentReference | Document | Entity Availability Workflow | |
List | Unrelated | Act |
Basic support structure Resources with general usefulness:
Media
stores an image, video, or sound recording, with metadata that can be used to link it into the rest of the healthcare record as represented in resourcesBinary
is a container for content of any type, to include content that is in some format other than a FHIR resource Bundle
acts as an envelope for a set of other resources as they are gathered together for exchange. Bundles may be long lived (documents) or very short lived (search results)Basic
is a general container that can be used to represent data for which a specific resource doesn't yet exist (general extension point)Resource | Category | RIM | Lifecycle |
Media | Past | Act | |
Binary | Unrelated | Entity | |
Bundle | Unrelated | Entity | |
Basic | Unrelated | InfrastructureRoot |
These resources support the exchange process directly:
MessageHeader
is the header for a message - identifies its context, sender and receiver, and contentOperationOutcome
is returned to indicate the detailed outcome of a particular FHIR operation or interaction - success, or failureParameters
is input or output to OperationsSubscription
allows one system to subscribe to events on another systemResource | Category | RIM | Lifecycle |
MessageHeader | Present | Act | |
OperationOutcome | Present | Act | |
Parameters | Present | InfrastructureRoot | |
Subscription | Present | Act |
This specification is a base platform specification that defines a set of general capabilities. Specific systems build on top of that to create interoperable solutions by making a set of conformance rules. These conformance rules are supported by a this set of "conformance" resources.
A ValueSet
defines a set of codes from one or more code systems
that are used for validation, lookup etc. A ConceptMap
maps value sets between different
code systems.
A NamingSystem
resource represents an external provider of codes
or identifiers (e.g. an external code system such as SNOMED CT, or an identification system such
as an institution MRN). The naming system resource exists to share the identification and registration
of these systems, to foster consistency in their identification.
Resource | Category | RIM | Lifecycle |
ValueSet | Unrelated | ||
ConceptMap | Unrelated | ||
NamingSystem | Unrelated |
StructureDefinition
and DataElement
both describe a
set of data elements that can represent data for the purposes of collection,
analysis and exchange. They have slightly different purposes:
StructureMap
supports a general purpose mapping language that can be used to transfer data
from one structure to another.
Resource | Category | RIM | Lifecycle |
StructureDefinition | Unrelated | ||
StructureMap | Unrelated | Unrelated | |
DataElement | Unrelated | Entity |
A Conformance
is a statement of a set of system capabilities
for use as system discovery, or conformance expectations.
An OperationDefinition
describes an operation that can be
executed on a server, and a SearchParameter
defines
a search parameter that can be used on a server. CompartmentDefinition
provides information about how resources are associated on a server.
Resource | Category | RIM | Lifecycle |
Conformance | Unrelated | ||
OperationDefinition | Unrelated | ||
SearchParameter | Unrelated | ||
CompartmentDefinition | Unrelated |
ImplementationGuide
is used to gather all the other resources
into a single package for publication, and also to define the bounds of
an interoperability solution.
A TestScript
specifies a series of operations and outcomes
that a system is expected to meet. Test Scripts are for development and
acceptance testing, but may also be considered for use with production
systems, if the tests are carefully constructed and vetted.
Resource | Category | RIM | Lifecycle |
ImplementationGuide | Unrelated | ||
TestScript | Unrelated |
These resources are all in draft status and more details will be provided here in due course.
Resource | Category | RIM | Lifecycle |
Coverage | Ongoing | Act | |
EligibilityRequest | Present | Act | |
EligibilityResponse | Present | Act | |
EnrollmentRequest | Present | Act | |
EnrollmentResponse | Present | Act | |
Claim | Present | Act | |
ClaimResponse | Present | Act | |
PaymentNotice | Past | Act | |
PaymentReconciliation | Past | Act | |
ExplanationOfBenefit | Past | Act |