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

Implementation Details

While the FHIR Resources are designed with a simple RESTful HTTP-based implementation in mind, it is not necessary to use this implementation framework. This specification also defines a straight messaging based implementation framework for FHIR resources, and a document-based framework, as well as documenting how FHIR resources are used with hData.

SOA

Alternatively, it is not necessary to use any of these approaches; resources can be exchanged or persisted using any technical means that is appropriate to the context at hand. A common use of FHIR resources or aggregations is as parameters of service interfaces. FHIR itself does not define any particular service interface; instead, other standards and implementations define their own service interfaces and architecture that use FHIR resources. As long as the resources that are used are conformant with regard to this specification, and the rules for authoring and reading applications are followed, then the implementation can claim conformance to "FHIR Resources". Such implementations will need to resolve several issues:

• Resource references need to be able to be resolved. There are a variety of solutions to this, from ensuring that the all the relevant resources are aggregated together, or that all relevent resources are passed as parameters in a service call, through to a resource repository that provides access to all reference resources.
• The Resource metadata items "Version Id" and "Last Modified Date" are provided for use in resolving resource versioning and concurrency issues, both from a technical and human perspective. Most contexts of use will require at least one if not both of these attributes for some uses, and the implementation framework will need to resolve how and when they are exchanged
• The resource metadata item "Master Location" may be useful as part of a solution towards resolving resource references, and/or handling issues pertaining to distrubed use and re-use of resources, and implementations should describe how this data item is handlded
• The basic conformance statement allows authoring and reading applications to describe their rules concerning the contents of a resource. The implementation will need to describe how this constraint statement fits into the exchange/persistence context.
• How transactional information such as data enterer, author(s), responsible party, consent, and approvals is treated

The resolution to these issues should be documented and published somewhere.

Using Resources

Given these options, there are many ways to implement any particular workflow. There are many ways to use resources to build working systems:

• A RESTful paradigm where resources are exchanged separately using http transactions directly as defined in this specification. Implementations can use both push and pull, or a mix of the two
• The resources can be exchanged in messages or some other SOA implementation, where the resources are directly the contents/parameters that are exchanged
• The resources can be "aggregated" into documents that are self-contained and complete collections of linked resources, and then these documents can be exchanged and/or persisted
• The resources can be embedded in HTML pages or other web content such as content feeds

Useful Resources

General Resources:

• All schemas as a .zip (includes base schemas, resource schemas, and metadata schemas)
• Single combined definitions, including data types
• The UML definitions as an XMI file (or the Enterprise Architect source)

Resource specific resources:

Note: the JSON examples are simply the XML examples auto-converted to JSON by the json.org code. TODO: Add note about why JSON is included.

All of these resources except the JSON format are normative (i.e. Ballot comments may be made against these resources with regard to their correctness, other comments may be ruled out of scope). The reference implementations below are informative, and not subject to ballot.

Reference Implementations

Reference implementations are provided for implementer interest and assistance. Other implementations can be used, including code generated from the schemas.

• Delphi: Resource Definitions, and XML & JSON parsers. D5+. TODO: remove dependencies on unpublished code.
• Java: Resource Definitions + parser (+ more todo). The java reference implementation depends on XmlPull (http://www.xmlpull.org/) and the Apache Commons Codec library (http://commons.apache.org/codec/).
• C#: Resource definitions (+ more todo)
• ECore: Formal Object Definitions in OCLinECore text format - under development

Default Values

This is a list of the all the default values defined in the FHIR specification:

• In the RESTful conformance declaration, support for a transaction is declared on an element of type boolean. If no element is present, the transaction is not 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.