Current Build
FHIR Infrastructure Work GroupMaturity Level: N/ABallot Status: Informative

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 Resource List provides views of the resources organized in several different ways, and is the primary entry point to the resources.

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 EventAdverse reaction to an agent, falls, adverse surgical events, hospital infectionsAdverseEvent
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 analysisServiceRequest
Proposal for an imaging procedureCT Scan, MRI, X-RaysServiceRequest
Proposed Diet OrderAn oral diet orderNutritionOrder
Proposed respiratory orderOxygen deliveryNot done yet
Proposed MedicationsAspirin, LisinoprilMedicationRequest
Proposed SupplyWheel Chair, Food TraySupplyRequest
Interdisciplinary Care Planning
Patient GoalReduce risk of falls, lose weightGoal (as part of a CarePlan)
InterventionPatient assessmentsServiceRequest

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:

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.

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.

OccupationalData (aka Occupational Data for Health - ODH) is designed for the social history section of a medical record, to facilitate clinical care in most/all disciplines and delivery environments. ODH also can be used to support public health reporting, population health activities, clinical decision support, and similar value-based care.

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

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 treatment planned for a patient in the future, and may be updated and adjusted as ongoing care is provided.

A ServiceRequest 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
ServiceRequestFutureActClinical Workflow

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

  • Prescription = a MedicationRequest
  • In some records, medication orders, administration, and statements might 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
MedicationRequestFutureActRequest/Order. This has a current List
MedicationStatementOngoing / PastActEntity Availability Workflow. This has a Current List

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.

TheMediaresource represents multimedia observations stored as images, videos, or sound recordings, with metadata that can be used to link it into the rest of the healthcare record as represented in resources

ServiceRequest 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. ServiceRequests capture the request from an authorized clinician to initiate the diagnostic process. Specimen and BodyStructure are used to record the details of specimen collection although BodyStructure can also be used with other resources (e.g. Operation location details on a Procedure).

The resource ImagingStudy is 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
SpecimenDefinitionUnrelatedRoleEntity Availability Workflow

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.

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


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.

The BiologicallyDerivedProduct resource is used to describe a material substance originating from a biological entity intended to be transplanted or infused into another (possibly the same) biological entity.

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

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.


ResearchStudy is used to capture information related to the planning and execution of clinical and pre-clinical studies. It covers both human and veterinary studies and safety, efficacy, comparative effectiveness and retrospective trials.

ResearchSubject capture the information around the participation of a specific individual (Patient) in a specific ResearchStudy. This information includes their time of participation, associated study arm, status within the study, etc.


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 usually 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 to 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

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 a proposed or confirmed future event, with a list of participants who might or might 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.


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

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.


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

Basic support structure Resources with general usefulness:

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

These resources support the exchange process directly:

  • MessageHeader is the header for a message - identifies its 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

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


StructureDefinition describes a set of data elements that can represent data for the purposes of collection, analysis and exchange. StructureDefinition is used specifically to describe the structures used by or with this specification.

StructureMap supports a general purpose mapping language that can be used to transfer data from one structure to another.


A CapabilityStatement 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. MessageDefintion describes the behavior associated with receiving a particular message.


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. TestScripts are for development and acceptance testing, but may also be considered for use with production systems, if the tests are carefully constructed and vetted.

A TestReport contains the test execution results of a TestScript against a series of operations and outcomes that a system is expected to meet. TestReports provide a static recording of TestScript results for subsequent retrieval and review.


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