This page is part of the FHIR Specification (v0.05: DSTU 1 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 bundles 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 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 bundled together or that all relevant resources are passed as parameters in a service call, through to a resource repository that provides access to all referenced 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 distributed use and re-use of resources and implementations should describe how this data item is handled.
• The conformance statement allows authoring and reading applications to describe their rules concerning the use and contents of a resource. The implementation will need to describe how this conformance statement or some other equivalent 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 with the service specification.

There are many ways to implement any particular workflow and 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 form the contents/parameters that are exchanged
• The resources can be "bundled" 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

Implementation Support

This section contains links to content that assist implementers make FHIR work in production:

• All schemas as a .zip (includes base schemas, resource schemas, Schematrons and FHIR-specific atom schemas and Schematrons)
• Single combined definitions of resources and data types as processable XML
• Single combined resource profiles. The resource profiles may be useful as a starting point for authoring profiles on the resources or with conformance statements
• All resource examples as a zip file

TODO: add RDF & OWL renditions, eCore definitions, ADL versions, anything anyone else asks for

Reference Implementations

These reference implementations are provided for implementer interest and assistance. They may be used in production instances, though HL7 and its contributors accept no liability for this use. All these implementations are provided under a standard OSI approved BSD license (BSD-3-Clause).

These reference implementations are limited to code for representing the resource contents in their native form and parsing & serializing them as XML and JSON. In addition, some of the implementations provide support for building, using and reasoning with resource definitions. Full blown open source implementations for FHIR, some of which use these reference implementations, are listed on the HL7 wiki.

It is not necessary to use these particular implementations in order to be conformant. Any other approach may 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

Icons

Any (conformant?) FHIR Implementation is allowed to use the FHIR icon in association with the FHIR implementation. The FHIR icon is available in various sizes:

---

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.05 generated on Sun, Sep 9, 2012 03:28+1000. License