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

3.1 Guide to resources

FHIR Infrastructure Work GroupMaturity Level: N/ABallot 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:

  1. Clinical: The content of a clinical record
  2. Identification: Supporting entities involved in the care process
  3. Workflow: Manage the healthcare process
  4. Financial: Resources that support the billing and payment parts of FHIR
  5. Conformance: Resources use to manage specification, development and testing of FHIR solutions
  6. Infrastructure: General functionality, and resources for internal FHIR requirements

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 ResultsBlood panels such as CBC with Differential, Liver Panel, etc.DiagnosticReport with Observations
Imaging Study FindingsCT Scans, MRI, Plain Radiographs, Ultrasounds)DiagnosticReport (some with Observations)
Diagnostic Test ResultsEKG, pulmonary function test, EEGObservations (and maybe a DiagnosticReport)
Vital SignsTemperature, Blood Pressure, Heart Rate, Respiratory RateObservation
Other Physical Exam FindingsAuscultation findingsObservation
Pulmonary Artery Catheter readingsPulmonary artery pressureObservation
Patient Problems, Allergies and Adverse Events
AllergyFood or drug allergiesAllergyIntolerance
Clinical DiagnosisDiabetes, Congestive Heart FailureCondition
Adverse Event / ReactionAdverse reaction to an agent, falls, adverse surgical events, hospital infections(not done yet)
Patient History
Chief ComplaintCough, Pain, Fever, FatigueCondition
Past Surgical HistoryAppendectomy, Hernia repairProcedure
Past Medical HistoryDiabetes, Congestive heart failureCondition
MAR (Medication Administration Record)Warfarin 5mg PO administered on 12/10/2013 at 3pmMedicationAdministration
Home MedsWarfarin 5mg, 30 day supply, dispensed on 12/01/2013MedicationStatement
Social HistorySexual behavior, Smoking status, Alcohol intake, Illicit drug useObservation
Family HistoryMother has diabetesFamilyMemberHistory
Signs & Symptomsfrom a review of systems- Pain, FeverCondition
Suggested Physician Orders
Proposal for a laboratory testA blood panel, a stool analysisDiagnosticOrder
Proposal for an imaging procedureCT Scan, MRI, X-RaysDiagnosticOrder
Proposed Diet OrderAn oral diet orderNutritionOrder
Proposed respiratory orderOxygen deliveryNot done yet
Proposed MedicationsAspirin, LisinoprilMedicationOrder
Proposed SupplyWheel Chair, Food TraySupplyRequest
Interdisciplinary Care Planning
Patient GoalReduce risk of falls, lose weightGoal (as part of a CarePlan)
InterventionPatient assessmentsProcedureRequest

In addition, to the information on this page, see also Common Use Cases.

3.1.1 Resource Classification

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:

Type Description
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.

3.1.2 Clinical General

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.

AllergyIntoleranceOngoingActThis has a Current List
ConditionOngoingActThis has a Current List
ProcedurePastActClinical Workflow
RiskAssessmentPresentActClinical Workflow
DetectedIssuePresentAct Care Provision

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.

NutritionOrder 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.

GoalFutureActClinical Workflow
ReferralRequestFutureActClinical Workflow
ProcedureRequestFutureActClinical Workflow
VisionPrescriptionFutureAct Medication Management

Supports the medication and immunization processes. Some points of note:

  • Prescription = a MedicationOrder
  • In some records, medication orders, administration, and statements may not be well differentiated. Generally, use MedicationStatement if records are unclear
  • A medication chart (or variants) will use multiple different types of medication resources
  • When prescribing is done by an external system (e.g. most ambulatory e-prescribing), the Medication resource is not used. It is generally used to represent information in formularies and to describe custom formulations
MedicationMedicationActClinical Workflow
MedicationDispensePastActClinical Workflow
MedicationOrderFutureActRequest/Order. This has a current List
MedicationStatementOngoing / PastActEntity Availability Workflow. This has a Current List
ImmunizationRecommendationFutureAct Diagnostics

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:

  • Laboratory Results
  • Vital Signs (including Blood Pressure)
  • Physical Examinations
  • Social history (e.g. Smoking History)

and many more things beside. Note that 'everything is an observation', but implementations should not use Observation where Condition is more appropriate.

DiagnosticOrder 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. DiagnosticOrders 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 ImagingObjectSelection 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).

DiagnosticReportPastActEntity Availability Workflow
SpecimenUnrelatedRoleEntity Availability Workflow

3.1.3 Administrative Resources

These resources provide support for identifying the various entities involved in healthcare: people, organizations, substances, devices, etc. Individuals

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.

PatientUnrelatedRoleEntity Availability Workflow
RelatedPersonUnrelatedRole Groups

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.).

GroupUnrelatedEntity Entities

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.

LocationUnrelatedRoleEntity Availability Workflow
PersonUnrelatedEntity Device

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.


3.1.4 Work Flow Encounters

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.

EncounterFuture / Ongoing / PastAct
CommunicationPastActClinical Workflow
FlagOngoingActEntity Availability Workflow Scheduling

These resources are concerned with planning times and locations for future delivery of care:

  • A Schedule describes a set of times in the future that a service or individual may be available
  • A Slot is an instance of a time in a schedule that may be reserved
  • An Appointment is proposed or confirmed future event, with a list of participants who may or may not have confirmed their attendance
  • An AppointmentResponse is 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.

SlotFutureAct Order Management

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.


3.1.5 Infrastructure

These resources provide generally useful functionality, and/or are referenced directly from the base FHIR framework (RESTful API, messaging, documents). Information Management

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.

AuditEventPastAct Documents

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 document
  • DocumentReference 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.

DocumentManifestUnrelatedDocumentEntity Availability Workflow
DocumentReferenceDocumentEntity Availability Workflow
ListUnrelatedAct Structures

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 resources
  • Binary 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)
BasicUnrelatedInfrastructureRoot Exchange

These resources support the exchange process directly:

  • MessageHeader is the header for a message - identifies it context, sender and receiver, and content
  • OperationOutcome is returned to indicate the detailed outcome of a particular FHIR operation or interaction - success, or failure
  • Parameters is input or output to Operations
  • Subscription allows one system to subscribe to events on another system

3.1.6 Conformance

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. Terminology

A ValueSet defines a set of codes from a code system that are used for validation, lookup etc. A ConceptMap maps value sets between different code systems.

A 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.

NamingSystemUnrelated Content

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:

  • StructureDefinition is used specifically to describe the structures used by or with this specification
  • DataElement describes more general data items that are represented and exchanged in many formats and/or contexts
DataElementUnrelatedEntity Behavior

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.

SearchParameterUnrelated Miscellaneous

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.


3.1.7 Financial

These resources are all in draft status and more details will be provided here in due course.