FHIR Release 3 (STU)

This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

Work Group Implementable Technology Specifications Ballot Status: Informative

3.0 FHIR Linked Data Module

3.0.2 Introduction

This module describes the RDF representation for FHIR resources (FHIR/RDF) and related assets, including an OWL ontology for FHIR/RDF and a ShEx grammar to validate FHIR/RDF. Linked Data is structured data that is represented in an RDF format to facilitate inference and data linkage across datasets.

Materials in this module are created and maintained by a collaboration between HL7 and W3C . Editor: David Booth

3.0.1.1 Motivation and Design of the FHIR Linked Data Module

Although RDF formats can be used to exchange FHIR data, the primary purpose of the FHIR Linked Data Module is to ground FHIR data semantics in RDF, as a universal information representation. This enables FHIR data to be used with RDF applications, to support inference, shared semantics across multiple standards and data formats, data integration, semantic data validation, compliance enforcement, SPARQL queries and other uses.

The FHIR/RDF is based on the same abstract FHIR information model as the XML and JSON formats, and carries the same FHIR information content. FHIR data is losslessly round-trippable between XML, JSON and RDF formats. For this reason, data expressed in FHIR/RDF corresponds closely to the XML and JSON formats in its look and feel. However, there are a few additional terms that may appear in the RDF format, which are explained on the RDF page: fhir:nodeRole, fhir:treeRoot, fhir:value, fhir:index and fhir:concept.

Ontologies that were designed independently almost always have some impedance mismatch when attempting to use them together. Many of the ontologies in the medical and life sciences domain are designed to capture facts about the world for research, such as the fact that the mitral valve is a kind of heart valve. But FHIR was designed to support the day-to-day operations of healthcare providers exchanging electronic health records (EHRs), and in this context the orientation has historically been different. When using FHIR/RDF with other ontologies, impedence differences are likely to show up in two main ways:

  • Records versus facts. FHIR is oriented toward recording who did what ("Dr. Jones diagnosed patient x with viral pneumonia") rather than stating absolute medical facts ("patient x has viral pneumonia").
  • Non-monotonicity. RDF was designed to be monotonic, whereas FHIR has a few design aspects that are would be non-monotonic if they were interpreted directly in RDF. (Monotonicity means that new data cannot invalidate previous conclusions; non-monotonicity means that previous conclusions can be invalidated by new data.) For example, a modifier extension indicates that the surrounding element's meaning will likely be misunderstood if the modifier extension is not understood.

For both of these reasons, to maintain monotonicity in RDF, FHIR/RDF should not be directly interpreted as stating facts, at least until any potentially non-monotonic elements have been removed or isolated through pre-processing.

Application developers should also be aware that some FHIR data attributes have a major impact on the interpretation of the enclosing data element: the meaning of the enclosing element cannot be determined in isolation. For example, a status of 'entered-in-error' means that the resource was created accidentally, and should be ignored.

3.0.1.2 FHIR/RDF Data Formats

FHIR/RDF examples are provided for all FHIR resources in both Turtle and JSON-LD formats. To access a JSON-LD example, first navigate to that example in Turtle format, and then click the "JSON-LD" link above the Turtle example.

The mime type for the Turtle format is text/turtle .
The mime type for the JSON-LD format is application/ld+json .

3.0.2 Using FHIR/RDF

Application developers wishing to use FHIR/RDF will often need to perform the following rough steps, though exact steps will depend on your application:

  1. Convert FHIR/XML or FHIR/JSON data to/from FHIR/RDF. Open source implementations that can perform this conversion include:
  2. Download the FHIR ontology.
  3. Download other ontologies that you wish to use with your application, such as the SNOMED-CT ontology. (Because of license restrictions, the process of obtaining the SNOMED-CT ontology is more complex than a simple download. Some guidance is provided here .)
  4. Create or obtain a bridge ontology that relates terms in the FHIR ontology to terms in your other ontologies.
  5. Load your FHIR/RDF instance data and your ontologies into a reasoner and/or a triplestore, and perform SPARQL queries and/or reasoning.
  6. If you are creating FHIR/RDF then you might also wish to validate it, using ShEx . If so, you can download the ShEx schema for FHIR/RDF.

Slides by Eric Prud'hommeaux illustrate how inference can be used on FHIR/RDF data to perform a query for FHIR Observations of rheumatoid arthritis, using the SNOMED-CT ontology . Caveat: those slides show some terms in the fhir: namespace that do not actually exist in the fhir: namespace, such as fhir:Observation-of-Rheumatoid_arthritis-disorder and fhir:Coding-of-Rheumatoid_arthritis-disorder. A different namespace should have been used in the example.

3.0.3 Index

Other content in this module:

3.0.4 Security and Privacy

The use of RDF does not raise any known security or privacy issues beyond those already existing for FHIR/XML or FHIR/JSON. For more general considerations, see the Security and Privacy module.

RDF can also be used to help enforce security and privacy policies. See also HL7 Security and Privacy Ontology.

3.0.5 Common use Cases

In this section: common problems in the space of the module, ways to go about solving them, or references to additional problem based links.

TODO

3.0.6 Developmental Roadmap

In this section: what the current overall state is, what work is in train, what the goals over the next 18 months or so are.

Most of the major pieces of FHIR/RDF are now available in a complete enough form for developers to start trying them and providing feedback. Work still needed: