FHIR RDF enables operational healthcare data to be linked with RDF data from other communities. FHIR data can be serialized in either JSON, XML or RDF (Turtle), and tools are used to convert between formats. However, currently the tools for converting to/from FHIR RDF involve custom code. JSON-LD 1.1 @context files now have potential to reduce the cost of implementing and maintaining this FHIR RDF conversion. These @context files can be generated automatically during the FHIR specification build process. Used with a standard, off-the-shelf JSON-LD 1.1 processor, these @context files can do most of the work needed for this conversion, though a small amount of pre- or post-processing is still needed. Using the latest FHIR build and server implementations, we created a framework for the FHIR RDF specification implementation by developing two tools to demonstrate this process: a JSON-LD 1.1 @context generator that produces @context files from the FHIR specification; and a command-line tool for batch conversion between FHIR JSON and FHIR RDF. HL7 Fast Healthcare Interoperability Resources (FHIR)[1] is a next generation standards framework for exchanging electronic healthcare data. The Semantic Web Resource Description Framework (RDF) is one of three standard formats for FHIR data: JSON[2], XML[3] and RDF[4] (Turtle). The HL7 FHIR RDF Workgroup is actively working on creating a new version of the FHIR RDF specification, aiming to achieve better utility and ease of use. Early adopters of FHIR RDF uncovered a number of issues, including 1) literal values are nested under blank nodes (BNodes); 2) FHIR References are nested under BNodes; 3) Ordered lists use an extra BNode to include an explicit fhir:index; 4) FHIR RDF uses long predicate names to ensure uniqueness; and 5) FHIR extensions are awkward for RDF users. For this reason, the FHIR RDF Workgroup is now placing greater emphasis on ease of use. To address these problems, we explored the use of JSON for Linked Data, version 1.1. (JSONLD 1.1)[5] as a means to generate an executable definition of the FHIR RDF specification to enable semantics of the FHIR data. Note that JSON-LD is a W3C standard that allows JSON-LD data to be interpreted as a serialization of RDF triples. JSON-LD 1.1 enables the FHIR RDF specification to be defined in a more declarative style, through the use of “@context”. JSON LD @context files act like a schema for the JSON instance data and can be used to interpret and translate JSON data into RDF formats. The same instance data can be interpreted in multiple ways with different sets of JSON LD @context files. While the JSON LD 1.1 approach is an attractive approach, there are some issues uncovered by early adopters[6]. We focus on these issues here to ensure the implemented tools provide a simple and practical way to convert FHIR JSON to RDF. FHIR JSON can be validated with JSON Schema files that are published with FHIR. However, the JSON schema language has limited expressivity. For instance, it doesn't reject mutually
exclusive properties. You can better verify conformance with the FHIR specification by converting
the JSON data to RDF and validating the result with Shape Expression (ShEx)[
The initial draft version of the FHIR RDF R5 specification addresses the following issues: • BNodes: FHIR RDF R4 included extra BNodes to express nested values, and references. For example, in FHIR RDF R4 a status of "final" is represented as fhir:status [fhir:value “final”], instead of simply fhir:status “final”, which complicates how these values are queried by a SPARQL query. In R5 we intend to eliminate these extra BNodes. • Shortened predicate names: the predicate names in FHIR R4 were unnecessarily long and could be shortened to reduce redundancy and simplify usage, e.g., instead of having separate fhir:AdverseEvent.identifier and fhir:AllergyIntolerance.identifier properties, a single shorter fhir:identifier property could be used across multiple resources.
The FHIR model is built with resources descending from a common base class StructureDefinition while data types descend from base classes of Element or BackboneElement. We shortened the predicate names if they are not core Element or BackboneElement. An example of this would be predicate fhir:observation.status transformed to simply fhir:status. • Extensions: FHIR allows extensions on Resources and on properties in Resources.
Extensions are classed as "modifying" or "non-modifying"; where modifying extensions change the interpretation of the enclosing element and must not be interpreted without understanding the extension. The FHIR RDF group is balancing tensions between RDF's monotonicity vs. keeping the RDF representation like JSON and XML.
• JSON LD 1.1 @context Generator: We developed a Java-based JSON LD @context
Generator[
We implemented a JSON-LD 1.1 FHIR RDF Java-based command line tool[
The JSON-LD 1.1 @context generator produced 1355 @context files[
JSON-LD 1.1 @context file medicationrequest.context.jsonld contains references to Dosage type: "dosageInstruction": { "@id": "fhir:dosageInstruction", "@context": "dosage.context.jsonld" }, This Dosage type is defined in its own @context file dosage.context.jsonld, which defines Dosage. This example also demonstrates shortening of the name from fhir:MedicationRequest.dosageInstruction to fhir:dosageInstruction. _:b10 fhir:dosageInstruction [ fhir:doseAndRate [ fhir:doseQuantity [ fhir:Quantity.code "mg" ; fhir:Quantity.system <http://unitsofmeasure.org> ; fhir:Quantity.unit "mg" ; fhir:Quantity.value "500"^^xsd:decimal ] ; fhir:Quantity.type [ fhir:CodeableConcept.coding [ fhir:Coding.code "ordered" ; fhir:Coding.display "Ordered" ; fhir:Coding.system <http://terminology.hl7.org/CodeSystem/dose-rate-type> ] ] ; fhir:route [ fhir:CodeableConcept.coding [ fhir:Coding.code "255559005" ; fhir:Coding.display "Intramuscular (qualifier value)" ; fhir:Coding.system <http://snomed.info/sct> ] ] ; fhir:sequence fhir:text fhir:timing [ fhir:Timing.repeat [
fhir:Timing.count ] ] ] ] .
1 1 ; "Administer 500mg IM as a single dose";
generator and a command line tool for batch conversion to/from FHIR RDF, based on JSON-LD 1.1. We demonstrated the feasibility of the JSON-LD-based approach to handle shortened predicate names while we are still in the process of implementing the features for handling BNodes and extensions.
The approach of leveraging JSON-LD @context files to translate FHIR Resources and Instance data bi-directionally between FHIR JSON and FHIR RDF has potential to reduce the cost of RDF implementation and maintenance. This also serves to link the FHIR community to other RDF communities. The ability to bidirectionally serialize FHIR artifacts using JSON-LD 1.1 has its own challenges and issues that were addressed with a strategy of pre- or post-processing of instance data and resolving issues with a suite of JSON-LD -based tools. We developed two tools - a JSON-LD @context generator and a command-line tool for batch conversion - with the latest FHIR build and server implementations. The output was validated for a) alignment between the @context files and the ShEx schemas and b) demonstrate to the community the model resulting from issues in the FHIR RDF community. This paves the way for these tools to be integrated into the FHIR build process.
References