This page is part of the FHIR Specification (v1.0.2: DSTU 2). 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|
|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)|
|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||DiagnosticOrder|
|Proposal for an imaging procedure||CT Scan, MRI, X-Rays||DiagnosticOrder|
|Proposed Diet Order||An oral diet order||NutritionOrder|
|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)|
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:
|Past||A record of an event that has happened|
|Present||A record that serves an exchange in real time|
|Future||A record that describes a future intent|
|Ongoing||A record that is maintained over time that tracks the state of a patient|
|Unrelated||A record that doesn't relate to time (e.g. a fixed entity)|
Note that even future records end up in the past after the event they are concerned with passes.
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
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.
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.
|AllergyIntolerance||Ongoing||Act||This has a Current List|
|Condition||Ongoing||Act||This has a Current List|
These resources support planning of care provision - care and treatment plans.
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.
NutritionOrder is a request to supply a diet, formula feeding (enteral) or oral nutritional supplement to a patient
VisionPrescription contains the details of visual aids requested for a patient.
Supports the medication and immunization processes. Some points of note:
MedicationStatementif records are unclear
Medicationresource is not used. It is generally used to represent information in formularies and to describe custom formulations
|MedicationOrder||Future||Act||Request/Order. This has a current List|
|MedicationStatement||Ongoing / Past||Act||Entity Availability Workflow. This has a Current List|
Resources concerned with observing the patient, and the diagnostic service process built around this.
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.
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. DiagnosticOrders capture the request from an authorized clinician to initiate the diagnostic process.
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).
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
|DiagnosticReport||Past||Act||Entity Availability Workflow|
|Specimen||Unrelated||Role||Entity Availability Workflow|
These resources provide support for identifying the various entities involved in healthcare: people, organizations, substances, devices, etc.
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.
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.
|Patient||Unrelated||Role||Entity Availability Workflow|
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
represents the services offered by one or more organizations at a single location.
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.).
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.
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.
|Location||Unrelated||Role||Entity Availability Workflow|
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.
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.
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.
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.
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.
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.
|Encounter||Future / Ongoing / Past||Act|
|Flag||Ongoing||Act||Entity Availability Workflow|
These resources are concerned with planning times and locations for future delivery of care:
Scheduledescribes a set of times in the future that a service or individual may be available
Slotis an instance of a time in a schedule that may be reserved
Appointmentis proposed or confirmed future event, with a list of participants who may or may not have confirmed their attendance
AppointmentResponseis an individual's acceptance or rejection of an appointment
The 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.
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.
These resources provide generally useful functionality, and/or are referenced directly from the base FHIR framework (RESTful API, messaging, documents).
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.
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.
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.
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:
Compositionallows for the construction of a detailed document package using other resources for all content of the document
DocumentManifestare 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
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.
|DocumentManifest||Unrelated||Document||Entity Availability Workflow|
|DocumentReference||Document||Entity Availability Workflow|
Basic support structure Resources with general usefulness:
Mediastores 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 resources
Binaryis a container for content of any type, to include content that is in some format other than a FHIR resource
Bundleacts 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)
Basicis a general container that can be used to represent data for which a specific resource doesn't yet exist (general extension point)
These resources support the exchange process directly:
MessageHeaderis the header for a message - identifies it context, sender and receiver, and content
OperationOutcomeis returned to indicate the detailed outcome of a particular FHIR operation or interaction - success, or failure
Parametersis input or output to Operations
Subscriptionallows one system to subscribe to events on another system
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.
ValueSet defines a set of codes from a code system
that are used for validation, lookup etc. A
ConceptMap maps value sets between different
NamingSystem resource represents and 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.
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:
Conformance is a statement of a set of system capabilities
for use as system discovery, or conformance expectations.
OperationDefinition describes an operation that can be
executed on a server, and a
a search parameter that can be used on a server.
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.
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.
These resources are all in draft status and more details will be provided here in due course.