This page is part of the FHIR Specification (v0.06: DSTU 1 Ballot 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

Overview 1.1

Fast Healthcare Interoperability Resources (FHIR) defines a set of resources for use in exchanging information about the healthcare process. Resources are:

• Granular - they are the smallest unit of operation and a transaction scope of their own
• Independent - the content of a resource can be processed without reference to other resources and has its own lifecycle and transaction scope
• Connected - resources refer to other resources to allow for clean modular reuse of information
• Simple - each resource is easy to understand and implement without needing specialized tooling or infrastructure (though that can be used if desired)
• RESTful - resources are able to be used in a RESTful exchange context
• Flexible - resources can also be used in non-RESTful contexts, such as messaging or SOA architectures and can be moved in and out of RESTful paradigms as convenient
• Extensible - resources can be extended to allow for local requirements without impacting on interoperability
• Web Enabled - where possible and appropriate, open internet standards are used for data representation
• Free for use - the FHIR specification itself is open - anyone can implement FHIR or derive related specifications without any IP restrictions

In addition to the basic resources, FHIR defines a lightweight implementation framework that supports the use of these resources in RESTful environments, classic message exchanges, human-centric clinical documents and enterprise SOA architectures. Each of these approaches provides its own benefits - FHIR provides the underpinning enablement that makes the choosing one of these painless and enables enterprises to choose their own paradigm without forsaking interoperability with other paradigms.

Though the resources are simple and easy to understand, they are backed by a thorough, global requirements gathering and formal modeling process that ensures that the content of the resources is stable and reliable. The resource contents are mapped to solid underlying ontologies and models using computable languages (including RDF) so that the definitions and contents of the resources can be leveraged by computational analysis and conversion processes.

FHIR also provides an underlying conformance framework and tooling that allows different implementation contexts and enterprises to describe their context and use of resources in formal computable ways and to empower computed interoperability that leverages both the conformance and definitional frameworks.

The combination of the resources and the 3 supporting layers (implementation frameworks, definitional thoroughness, and conformance tooling) frees healthcare data so that it can easily flow to where it needs to be (hospital production systems, mobile clinical systems, cloud based data stores, national health repositories, research databases, etc.) without having to pass through format and semantic inter-conversion hurdles along the way.

Compared to the all the other approaches, FHIR... [-- Obligatory: insert your FHIR FIRE related joke here --].

Roadmap 1.1.1

This specification is structured into 3 parts: the introduction, the implementation section and the resource definitions.

Introduction 1.1.1.1

The introduction provides foundational material that is required to understand and use resources:

• Introduction: Overall introduction, useful links and the FHIR license
• This roadmap
• Resource Formats: An explanation of the general content and format of all resources and how they are described
• Data Types: Common re-usable patterns encountered throughout healthcare data and used in the resources
• Using Codes: Explains how the use of codes (code systems, terminologies, classifications, ontologies) is managed in FHIR
• Extensibility: Describes the extension section of the resource and specifies the rules that apply to its use
• Resource Profiles: Describes how resources are profiled to describe their use in a particular context

Implementation 1.1.1.2

The implementation section explains how resources are used in various contexts:

• Implementation: General requirements for using resources and various useful things including schema packs and reference implementations
• REST (HTTP): Defines a lightweight HTTP based paradigm for using resources
• Messaging: A simple request/response message based transactional framework (equivalent to HL7 v2)
• Documents: Clinical documents contain attested content that are both human readable and computer processable and can be exchanged and signed as single bundles (equivalent to CDA)
• Errors & Warnings: Describes how issues are communicated when RESTful, messaging or SOA operations are unsuccessful or encounter problems
• hData Integration: An explanation of how to use resources in the context of an hData RESTful service
• Atom Feeds: Atom feeds are used to gather a set of resources into a single XML document when they are transferred as a group - these are called "bundles"
• JSON format: Explains how resources are serialized using the JSON syntax
• Value Set: A resource that describes a set of codes - used in association with profiles to specify resource contents and potentially usable in other contexts
• Conformance: A resource that describes how an application does, can, or should use FHIR resources
• Security: A brief discussion of security considerations associated with using FHIR

Resources 1.1.1.3

The resources section enumerates the resources:

• Resources: An index of the defined resources
• The resources in alphabetical order

For each resource, the following pages are provided:

• Content: Provides context for the resource and defines its content with a simple XML format and some additional description. Formal definitions such as W3C schema and others are also provided. Also describes events and search criteria associated with the resource.
• Examples: Provides one or more examples that show how the resource is used.
• Formal Definitions: A table of the full formal definitions for each element in the resource along with mappings to other standards and ontologies.
• Design Notes: Explanations of some of the less obvious aspects of the resource and explanation of why the resource is structured in a particular way. Not all resources have design notes and implementers do not need to read them.
• Profiles: A list of profiles of the resource that are provided as part of the standard. Profiles may be provided to illustrate some aspect of the use of a resource or because certain particular uses of a resource are sufficiently common to warrant a standard profile.

Community 1.1.2

The FHIR community meets inside the wider HL7 community and draws on its extensive human resources, institutional memory, previous standards and corporate support. HL7 itself owns FHIR and makes it freely available and the community relies on HL7 provided infrastructure.

The primary resources used by the FHIR community are the HL7 wiki, and the FHIR email list. In addition, the community holds regular face to face meetings as part of the HL7 Working Group meetings. The formal governance arrangements that manage FHIR development are documented (where? - todo)

Note that each page contains a direct link to its matching wiki page where input from the wider community is managed. Community input is very welcome - please consider making comments.

EHR Functional Model 1.1.3

The EHR System Functional Model provides a reference list of functions that may be present in an Electronic Health Record System. While FHIR is an implementation focused on exchange of information in healthcare, this often happens in the context of an EHR. This table briefly describes one way that FHIR can be used to meet the requirements described in the EHR-FM and is provided to help readers of the FHIR specification understand how FHIR can be used. There are many other equally valid ways to implement the EHR-FM and to make use of FHIR.

EHR Function		FHIR Implementation Notes
IN.1	Security	FHIR defines parts of the security infrastructure, and delegates others to standard web based security frameworks
IN.1.1	Entity Authentication	FHIR assumes that the users are authenticated. OAuth is the preferred mechanism
IN.1.2	Entity Authorization	FHIR doesn't currently provide any resources to describe or manage access-control permissions. By default, underlying web frameworks such as SAML would be used. See the security section for a discussion of binding between FHIR and SAML
IN.1.3	Entity Access Control	See above about SAML / OAuth
IN.1.4	Patient Access Management	FHIR does not - yet? - include functionality related to this requirement
IN.1.5	Non-Repudiation	The provenance resource tracks the timestamps, actors, digital signatures associated with resources
IN.1.6	Secure Data Exchange	TLS (https:) should be used for all production exchange of data. All conformant FHIR RESTful implementations must be able to use https
IN.1.7	Secure Data Routing	FHIR allows for brokers and various forms of messaging that support assured destinations and delivery (also see IN.2.2 below)
IN.1.8	Information Attestation	See the provenance resource
IN.1.9	Patient Privacy and Confidentiality	FHIR does not - yet? - include functionality related to this requirement, though implementations would be expected to provide this
IN.2	Health Record Information and Management	This is the core focus of the FHIR specification
IN.2.1	Data Retention, Availability and Destruction	A FHIR RESTful server gives precise and fine-grained control of retention, availability and destruction of resources, all clearly described by the conformance statement
IN.2.2	Auditable Records	FHIR provides the SecurityEvent resource for auditable records.
IN.2.3	Synchronization	FHIR supports synchronization using standard web publication/subscription methods via Atom feeds. Atom-based pub/sub may be push or pull based, and can include all resources of a particular type, or selected subsets of the resources. In addition, groups of resources can be exchanged in bundles, keeping a set of related resources in synchronization
IN.2.4	Extraction of Health Record Information	FHIR does not provide report formats (yet?), but does provide extensive search and retrieval functions to assist with building such reports
IN.2.5	Store and Manage Health Record Information	A FHIR RESTful server can store and manage health information persistently - see below for further information.
IN.2.5.1/2	Manage Structured and Unstructured Health Record Information	The dual contents of FHIR resources - structured data and XHTML narrative - provide seamless support for dealing with a mix of structured and unstructured information
IN.3	Registry and Directory Services	The FHIR Administration resources provide a naturally registry based access to patients, providers, etc
IN.4	Standard Terminologies and Terminology Services	FHIR encourages the use of standard terminologies whereever possible, and provides full support for their use through a variety of terminology related data types. FHIR does not define a terminology infrasturcture or service, but does define the Profile and ValueSet resources to describe how terminology is used in a FHIR context
IN.5	Standards-based Interoperability	FHIR is a definition of a standard on which to base interoperability
IN.5.1	Interchange Standards	This is the core focus of FHIR. See below for discussion of interaction modes
IN.5.2	Interchange Standards Versioning and Maintenance	FHIR version maintenance is described here
IN.5.3	Standards-based Application Integration	FHIR enables simple integration through use of an easy to understand, use and debug web based infrastructure. The same framework used within an EHR for persistence can also offer a simple way to implement exchange
IN.5.4	Interchange Agreements	The FHIR Conformance Statement and Resource Profile resources provide a registry based infrastructure for individual trading partner agreements, as well as for community based ones
IN.6	Business Rules Management	FHIR does not address this requirement at this time
IN.7	Workflow Management	FHIR does not address this requirement at this time, though the resources and services exist to support this functionality

The EHR functional model describes several modes for interaction between systems. Each of these can be implemented in several different ways using FHIR

Interaction Modes	FHIR Options
Unsolicited Notifications e.g. a patient has arrived for a clinic appointment	create/update new resource via http push resources using atom Send FHIR Message (if appropriate event is defined)
Query/Response e.g., Is Adam Everyman known to the system? Yes, MRN is 12345678.	search with parameters A query message (though not defined yet)
Service Request and Response e.g., Laboratory Order for Fasting Blood Sugar and a response containing the results of the test.	Could be supported either through Messaging or SOA solutions. Request/Response support is not yet defined
Information Interchange between organizations (e.g. in a RHIO, or in a National Health System)	pub/sub using atom (push or pull) RESTful interface FHIR messaging
Structured / Unstructured clinical document, e.g., dictated surgical note	See the Documents

The combination of a properly secured and managed FHIR server, along with enforced use of the SecurityEvent and Provenance resources ensures that the core record management functions defined in the EHR-FM are met:

• Lifespan/Lifecycle tracking, including capturing source, origination and authorship information, along with tracking of views and exchanges
• Attestation for accuracy and completeness, along with digital signature
• A full version history with content retention
• Retention and persistence

Additional functionality not defined (yet?) in FHIR is required to ensure non-repudation, access control, and consent tracking.

---

This is an old version of FHIR retained for archive purposes. Do not use for anything else
Implementers are welcome to experiment with the content defined here, but should note that the contents are subject to change without prior notice.
© HL7.org 2011 - 2012. FHIR v0.06 generated on Tue, Dec 4, 2012 00:04+1100. License