This page is part of the FHIR Specification (v0.01: Historical Archive Draft). The current version which supercedes this version is 4.0.1. For a full list of available versions, see the Directory of published versions

Introduction

Fast Healthcare Interoperability Resources (FHIR) defines a set of "resources" for health. These resources represent granular clinical concepts that can be exchanged in order to quickly and effectively solve problems in healthcare and related process. The resources cover the basic elements of healthcare - patients, admissions, diagnostic reports, medications, and problem lists, with their typical participants, and also support a range of richer and more complex clinical models. The simple direct definitions of the resources are based on thorough requirements gathering, formal analysis and extensive cross-mapping to other relevant standards.

Technically, FHIR is designed for the web; where possible or appropriate, open internet standards are used for data representation. The resources are based on simple XML, with an http-based RESTful protocol where each resource has predictable URL. Note that while the resources are defined to support an HTTP based RESTful infrastructure, it is not necessary to use such an infrastructure when using the resources. This specification also defines a class messaging based framework and way to use the resources to build clinical documents. In addition, the resources can be used in a SOA-based solution. This flexibility offers coherent solutions for a range of interoperability problems.

Roadmap

This specification has the following parts:

• Background: foundation infrastructure for implementing resources (XML rules, data types, terminology basics, extensibility rules, and a conformance infrastructure).
• Exchange: actual schemes for exchanging resources (HTTP RESTful protocol, Messaging and Documents, along with a general implementation resources page)
• Administrative Resources: basic resources encountered throughout the healthcare process
• Basic Clinical Components: Core reusable clinical resources that are encountered in most clincal practice
• etc

The contents of this specification are navigated using the right-hand side bar.

Resources

All resources have the following parts:

• A master id that is never changed
• Structured Data - the formal representation of the resource in a computable fashion
• Extensibility section - additional data not defined by HL7
• Text Representation - a human readable fall back presentation

Because the master resource id is never changed or reused, resources may refer to other resources by the master id knowing that this is stable reference. While each resource can be read and/or changed without explicit reference to these other resources, the presence of these references influences the behaviour of the system: implementations are required to maintain system and data integrity at all times.

The exchange specifications are simple and straight forward and based around a direct description of the XML representation of the resource. Each resource is described separately, though there are some common data patterns used across all the resources (called "data types").

For each resource, this specification defines

• scope and meaning of the resource
• semantics and business implications of the resource
• the XML content model of the resource (as XML, UML, and schema)

In addition to the simple XML definitions, a W3C XML schema and UML class diagram are available for each resource. The UML class diagram represents the same logical model as the XML format (though because of UML issues, implementors should not expect software built from the UML models to be automatically interoperable or conformant with the XML defined in this specification).

Each xml element (or matching UML class, attribute and composition association) has a formal definition that includes a definition, statement of requirements, additional comments, a mapping to the v3 RIM, and an indicative v2 mapping.

In addition, for each resource, some RESTful specific features are described:

• the relative URL for RESTful implementations derived from the id, the type, and a local base URL
• transactions specfically associated with the resource
• additional search parameters specifically associated with the resource

Each resource supports the same list of transactions - read, update, delete, etc. One particularly important transaction supported by every resource type is the provision of a conformance statement which specifies what parts of the defined content model are supported by the system, and what other transactions or interactions are supported. If any of the other interactions are supported, the conformance interaction must be supported. (i.e. if the conformance interaction returns an error, no operations are supported).

---

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.01 generated on Mon, May 14, 2012 09:48+1000.