STU3 Candidate

This page is part of the FHIR Specification (v1.8.0: STU 3 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

Work Group Implementable Technology Specifications Public Health and Emergency Response Ballot Status: n/a

3.0 FHIR Linked Data Module

3.0.1 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 for FHIR/RDF

The purpose of defining an RDF representation of FHIR is not only to enable FHIR to be exchanged in an RDF format such as Turtle, it is also to ground the semantics of FHIR data in RDF, for use with ontologies and other RDF data. Since FHIR data is losslessly round-trippable between XML, JSON and RDF formats, any FHIR data can be used in conjunction with RDF. The semantics are the same regardless of source format.

Reasons for using RDF and ontologies with FHIR data include:

  • Shared semantics. RDF's use of URIs as universal identifiers facilitates shared semantics across independently authored data.
  • Inference. An ontology specifies relationships between concepts, which can be used to perform computer-based inference and formal reasoning over FHIR data. For example, using inference a query for heart valve surgeries could automatically include results that were documented as mitral valve surgeries, because a mitral valve is a kind of heart valve.
  • Data integration. FHIR/RDF data can be integrated with other data, using RDF as a common semantic and representation layer -- including data that does not originate in an RDF format. For example, clinical trials data in XML (see https://clinicaltrials.gov/ ) can be translated to RDF and then combined with FHIR/RDF data.
  • Data validation. An ontology provides a vocabulary of uniquely identified concepts, which facilitates data validation.
  • Error detection. Computer-based reasoning can be used to help detect errors and inconsistencies in data and ontologies, and potential help repair them.
  • Compliance. RDF and ontologies can be used to express compliance constraints, for example to control data projected between two privacy contexts or to encode access restrictions for queries.
  • Modularity. RDF was designed to support modularity, such that a specialized ontology can be freely composed of a subset of concepts from a larger ontology.
  • Combining ontologies. The FHIR ontology can be linked to other ontologies, through bridge ontologies, and used together to support ontology-enabled applications in overlapping domains.
  • Query. SPARQL queries can be performed on FHIR/RDF data, without need for a FHIR-specific query language. SPARQL is a W3C standard query language for RDF data. It can be used uniformly to query over both FHIR data and other data -- even in the same query.

3.0.1.2 Design of FHIR/RDF

FHIR/RDF was designed to correspond very closely to FHIR/XML and FHIR/JSON in its look and feel, though there are some apparent differences that are necessary to ensure full-fidelity round tripping between all FHIR formats, or to accommodate FHIR's extensibility. For example, fhir:index is used to retain information about ordering within a FHIR list, and fhir:value is used to indicate the value of an element, while still allowing FHIR extensions to be attached.

3.0.1.3 Using FHIR/RDF with Other Ontologies

Ontologies that were designed independently almost always have some impedance mismatch when attempting to use them together, and the FHIR ontology is no exception. 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 this difference is 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 may be misunderstood if the modifier extension is not understood. Another example: an entered-in-error status on a FHIR resource means that the resource was created accidentally, and should be ignored.

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. This could be done with a pre-processing step.

3.0.1.4 FHIR/RDF Data Formats

FHIR/RDF examples are provided for all FHIR resources in Turtle and JSON-LD formats.

The mime type for the Turtle format is text/turtle.

TODO: What is the status of the JSON-LD examples?

3.0.2 Index

Link to key content pages in this module:

3.0.3 Security and Privacy

TODO: In this section: description of key security and privacy issues, or references to pages that deal with this. For the security / privcay module itself, this section does not exist. For other modules, the paragraph/section can end with this boilerplate: For more general considerations, see the Security and Privacy module.

See also HL7 Security and Privacy Ontology

3.0.4 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 linkes

3.0.5 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