This page is part of the FHIR Specification (v0.00: Historical Archive Draft). 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

RFH: Resources For Healthcare             | Exchange Specifications | Data Dictionary | Workflow Management |             © Health Intersections P/L 2011

Summary

Administrative Resources

Clinical Components

Medications

Care management

Documents

Introduction

Resources for Healthcare (RFH) defines a set of "resources" that represent granular clinical concepts. The resources can be managed in isolation, or aggregated into complex documents. This flexibility offers coherent solutions for a range of interoperability problems.

The simple direct definitions of the resources are based on thorough requirements gathering, formal analysis and extensive cross-mapping to other relevant standards. A workflow management layer provides support for designing, procuring, and integrating solutions.

Technically, RFH is designed for the web; the resources are based on simple XML, with an http-based RESTful protocol where each resource has predictable URL. Where possible, open internet standards are used for data representation.

Note for readers: please read the commentary (letter to readers).

Roadmap

RFH is based on three major parts:

The exchange specification is defined here; below the general concepts of the exchange specification are described. On the right of this page, there is series of links, firstly to the framework on which the resources are based, and then a list of the actual resources.

Resources

Each resource carries a master id. The id is never changed or reused, and it identifies the resource permanently. Resources may refer to other resources by id knowing that this is stable reference. Each resource has a URL which is derived from the id, the type, and the local base URL. Given one resource address, the address of any other resource can be automatically determined.

Resources contain references to other resources. 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.

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

The exchange specifications are simple and straight forward and based around direct description of the XML representation of the resource. Each resource is described separately, though there are some common patterns used across all the resources (called "data types"). In addition to the simple XML definitions, a 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 the UML model to lead to interoperable implementations).

Further, each xml element (or matching UML class, attribute and composition association) is associated with a reference into a single integrated ontology that serves as a data dictionary. As well as more precisely defining the element, the data dictionary specifies the mappings from the element into other standards.

Because of legal requirements in various jurisdictions, the content model is extended with a transaction specific section for create|update|delete and other transactions, and applications may require the transaction section to be filled out.

For each resource, this specification defines

There is also an entry in the data dictinoary for each resource, and also every element in the resource. Additionally, each resource may have a design document that explains the rationale for the way the resource is defined.

Using Resources

There are many ways to use resources to build working systems, covering:

The workflow control layer allows healthcare providers and vendors to manage the procurement, deployment and management of the resources and the applications and systems that use them. For further information, see workflow control.

The resources each stand on their own, and provide fine grained access to an integrated system. Even a relatively simple system will be concerned with a set of resource types and may need to perform multiple reads to assemble a complete set of information pertaining to a simple task.

Such a fine grained interface may not suit all exchange requirements. In particular, exchanges where information is sent from one enterprise to another where there is no general trust relationship require a different approach. A classic example of this is health summary reports to public healthcare institutions.

In such cases, a single document that aggregates many resources into a single content package is required. This specification describes a general mechanism for aggregating the resources, and defines specific documents for common clinical use patterns.

Such aggregated documents may also be associated with additional work flow features such as explicit attestation and signing, and may be suitable for long term persistence, such as in national EHR systems.

The aggregated documents are also resources of their own. Note that updating an aggregated document does not necessarily update the individual component resources of the aggregated document.

To Do:

© 2011