HL7 Fast Healthcare Interoperability Resources (FHIR) is rapidly becoming a major standard for the exchange of electronic healthcare information. FHIR defines a collection of “resources” to represent different information types and specifies how these resources are to be exchanged using XML, JSON and, as of the latest release, RDF. The FHIR specification also uses links to SNOMED CT and other ontologies as an integral component of the representation of clinical data. The combination of a standardized set of FHIR RDF tags with embedded ontology references offers a number of interesting new possibilities for classification and categorization of clinical data, including recognizing prescriptions that contain particular drug categories, procedures that use a specific technique or approach, diagnoses of general disease categoreis (e.g. cancer, diabetes), etc. In this paper we investigate how FHIR RDF can be combined with ontologies in a description logic reasoner to achieve these goals.
? The SNOMED CT Concept Reference format (“code |name|”) will be used in this document to identify SNOMED CT concept codes.
We describe how an OWL reasoner can be used in combination with FHIR RDF and SNOMED CT to realize this sort of possibility,? and touch on some of the technical issues and next steps that will need to be addressed before this approach can be incorporated into high performance, industrial-strength tools. The HL7 Fast Healthcare Interoperability Resources FHIR 1 combines the key features of the Health Level Seven (HL7) 8 V2 9, V3 10 and CDA 11 standards into a framework based on the Resource Oriented Architecture (ROA) 12. FHIR defines a collection of resources that can be “easily assembled into working systems that solve real world clinical and administrative problems” 13. The FHIR specification defines how instances of FHIR resources are represented and exchanged using XML, JSON and, as of the latest version, RDF.
The FHIR Standard for Trial Use Version 3 (STU3) 4 includes a proposed specification for the representation of FHIR resources in RDF 5. This specification, jointly developed by HL7 FHIR and the W3C Semantic Web Health Care and Life Sciences Interest Group 14 includes: – Documentation and tooling for the representation the “abstract” FHIR model (FHIR StructureDefinition) as RDF. – A set of Shape Expression (ShEx) 15 16 schemas that formally define the rules
FHIR RDF compliance. – The FHIR Metadata Vocabulary 17 an RDFS/OWL document that formally defines the set of RDF URIs used in FHIR RDF instances.
One the key requirements for the FHIR RDF specification was “round trippability” – that all of the information in a abstract FHIR instance can be represented in the RDF serialization and vice versa. The FHIR RDF specification was, however, able to incorporate four optional “extensions” that help FHIR RDF to be a full participant in a Linked Open Data 18 environment: 1. Resource link Allows an explicit fhir:link to the URI of a referenced reference, e.g. the subject of a FHIR DiagnosticReport 2. Concept URI The RDF specification allows an optional “type arc” (i.e. rdf:type) that can reference the URI (or OWL expression) of a FHIR coded concept. ? The authors recognize that the application of automated reasoning to this sort of task is hardly novel. The fact, however, that large quantities of healthcare data may soon be directly in RDF using standardized URIs and representational ‘structures’ is new. The purpose of this paper is to call attention to this fact and to demonstrate that the sort of capabilities described in this paper are no longer hypothetical. Instead of saying if healthcare data were available in this RDF structure we could do X, we are saying now that large quantities of healthcare data is (or soon will be) available in this format, X will become generally available in production level environments. 3. Link type Identifies the rdf:type of a resource link. 4. Ontology header Provides an OWL compatible name and version for the resource instance, and imports the FHIR Ontology which allows the resource to be correctly interpreted in an OWL context.
While all of the above elements are optional, their presence enables a number of interesting use cases, a few of which are discussed here. Figure 1 shows a fragment of a JSON rendering of an example FHIR DiagnosticReport?. Figure 2 shows the equivalent information??, in RDF, with the extension elements shown in bold text. {"resourceType": "DiagnosticReport", "id": "f201",
... "status": "final",
... "subject": { "reference": "Patient/f201", "display": "Roel" },
... "conclusion": "CT brains: large tumor sphenoid/clivus.", "codedDiagnosis": [ {"coding": [ {"system": "http://snomed.info/sct", "code": "188340000", "display": "Malignant tumor of craniopharyngeal duct" } } ]}
]} Much as the Dublin Core 20 serves as a vocabulary of metadata terms used to to describe documents and other resources, the FHIR Metadata Vocabulary (FMV) can be viewed a “vocabulary” of terms used in health care documents. The FMV represents FHIR resources and their subcomponents as instances of owl:Class, and the attributes within those resources as instances of owl:ObjectProperty. Each owl:Class definition includes a description of its properties along with their type and expected cardinality. Each owl:ObjectProperty instance includes its rdf:domain and rdf:range, as well as any name(s), descriptions, etc. Figure 3 shows an excerpt from the definition of FHIR DiagnosticReport. ? http://hl7.org/fhir/diagnosticreport-example-f201-brainct.json ?? http://hl7.org/fhir/diagnosticreport-example-f201-brainct.ttl fhir:DiagnosticReport/f201 a fhir:DiagnosticReport; fhir:nodeRole fhir:treeRoot; fhir:Resource.id [ fhir:value "f201"]
... fhir:DiagnosticReport.status [ fhir:value "final"]; fhir:DiagnosticReport.subject [ fhir:link <http://hl7.org/fhir/Patient/f201>; 1 fhir:Reference.reference [ fhir:value "Patient/f201" ]; fhir:Reference.display [ fhir:value "Roel" ] ];
... fhir:DiagnosticReport.conclusion [ fhir:value "CT brains: large tumor sphenoid/clivus."]; fhir:DiagnosticReport.codedDiagnosis [ fhir:index 0; fhir:CodeableConcept.coding [ fhir:index 0; a sct:188340000; 2 fhir:Coding.system [ fhir:value "http://snomed.info/sct" ]; fhir:Coding.code [ fhir:value "188340000" ]; fhir:Coding.display [ fhir:value "Malignant tumor of craniopharyngeal duct" ]
The RDF fragment shown in Figure 2 asserts that <http://hl7.org/fhir/DiagnosticReport/ 1. Is an instance of the class FHIR DiagnosticReport. 2. Has a FHIR DiagosticReport.codedDiagnosis that, in turn, references a FHIR CodeableConcept.coding element that is (or represents) an instance of the the SNOMED CT concept 188340000 |Malignant tumor of craniopharyngeal duct|.
Using this assertion as a staring point, it is now possible to use this report in combination with the FMV, SNOMED CT and other ontologies to draw conclusions about the nature of the report. We will begin with a relatively straight-forward question: Does this report contain a cancer diagnosis? Using the SNOMED CT browser 21, we can determine the concept code for a cancer finding is 363346000 |Malignant neoplastic disease|.? Figure 4 shows how we can use the OWL 2 Functional Syntax 22 to define the class ReportWithCancerDiagnosis to be the set of fhir:DiagnosticReport instances that have at least one codedDiagnosis of type sct:3633346000.
Declaration(ObjectProperty(fhir:DiagnosticReport.codedDiagnosis.coding)) SubObjectPropertyOf(ObjectPropertyChain( fhir:DiagnosticReport.codedDiagnosis fhir:CodeableConcept.coding) fhir:DiagnosticReport.codedDiagnosis.coding) Declaration(Class(:ReportWithCancerDiagnosis)) EquivalentClasses( :ReportWithCancerDiagnosis
ObjectSomeValuesFrom(:fhir:DiagnosticReport.codedDiagnosis.coding sct:363346000))
When we load the diagnostic report itself, SNOMED CT, the FMV and the above class definition into Protégé 6 and applied the FACT++ 7 reasoner to reach the expected conclusion as shown in Figure 5.
It turns out, however, that the FHIR subject of a FHIR DiagnosticReport can be a FHIR Patient, Group, Device or Location. Figure 6 shows a class definition that selects FHIR DiagnosticReports having a FHIR Patient subjects.
A FHIR DiagnosticReport may or may not be “final”. If we want to restrict our classifier to finalized reports, we need to add another classifier. The current FHIR RDF specification doesn’t allow concept URI’s for simple codes such as FHIR status, so we need to examine the text status values??. Assuming we decide that “amended”, “appended”, “corrected” and “final” are the statuses that identify a finalized report, the resulting classifier can be constructed as shown in Figure 7. This approach, however, is brittle. “Appended” and “corrected” are both ? Note the distinction between this and 367651003 |Malignant neoplasm|, a morphological abnormality. The finding represents a set of “things” that can appear in a document, while the morphological abnormality represents the set of things that can appear on the body of a living organism. ?? http://hl7.org/fhir/valueset-diagnostic-report-status.html
Fig. 5: Cancer Diagnosis Classification Result Declaration(ObjectProperty(fhir:DiagnosticReport.subject.link)) SubObjectPropertyOf(
ObjectPropertyChain
(fhir:DiagnosticReport.subject fhir:link) fhir:DiagnosticReport.subject.link) Declaration(Class(:PatientReport)) EquivalentClasses(:PatientReport
ObjectSomeValuesFrom(fhir:DiagnosticReport.subject.link fhir:Patient)) subclasses of “amended”. The FHIR community might decide, however, that a status of “appended” should be a type “partial” or “preliminary”, and, were this the case, there would be no way to recognize that a change had occurred. New statuses could also be added such as, “fixed”, which might be defined as “final” status with additional workflow implications. A better approach to the status classifier would be to: 1. Publish an OWL rendering of the FHIR coding systems, including for FHIR
DiagnosticReport.status. 2. Extend the FHIR RDF specification to include URI’s for the code data type.
Figure 8 shows an excerpt from a proposed OWL rendering of the FHIR DiagnosticReport.status ontology, Figure 9 how it would appear and Figure 10 the corresponding classifier.
The categories defined above could then be combined into single classifier that identifies finalized diagnostic reports for patients with a diagnosis for any type of cancer, as shown in Figure 11. with the classification result in Figure 12.
The FHIR RDF representation allows us to “join the planes” of the information and ontology space. We have demonstrated that it, in the presence of the FHIR diagnostic-report-status: a owl:Ontology ; rdfs:comment "The status of the diagnostic report as a whole." ; rdfs:label "DiagnosticReportStatus" ; owl:versionIRI "http://hl7.org/fhir/diagnostic-report-status/3.1.0" ; owl:versionInfo "DiagnosticReportStatus(3.1.0)" . diagnostic-report-status:root a owl:Class ; rdfs:label "DxStatus" ; skos:definition "Diagnostic Report Status Values" ; skos:preflabel "DxStatus" .
... diagnostic-report-status:final a owl:Class ; rdfs:subClassOf diagnostic-report-status:root ; rdfs:label "Final" ;
... diagnostic-report-status:appended a owl:Class ; rdfs:label "Appended" ; rdfs:subClassOf diagnostic-report-statustic-report-status:amended skos:definition "Subsequent to being final, the report has been modified
by adding new content. The existing content is unchanged." . Import(<http://example.org/swat4ls/patientreport>) Import(<http://example.org/swat4ls/cancerreport>) Import(<http://example.org/swat4ls/finalreport>) Declaration(Class(:FinalPatientReportWithCancerDiagnosis)) EquivalentClasses(:FinalPatientReportWithCancerDiagnosis
ObjectIntersectionOf (<http://example.org/swat4ls/patientreport/PatientReport> <http://example.org/swat4ls/cancerreport/ReportWithCancerDiagnosis> <http://example.org/swat4ls/finalreport/FinalReport>)) ) Metadata Vocabulary and one or more ontologies, one can use an OWL Description Logic reasoner to classify and categorize FHIR resource instances. We have demonstrated the usefulness of the “extensions” to the FHIR RDF representation: – Resource links Assigns URI’s to referenced resources, allowing them to be typed and retrieved.
Fig. 12: Final Classification Results – Link type Identifies the type of a link – something that non-RDF representations have to determine by a) constructing a URI and b) resolving it. – Concept URI Allows resource instances and ontologies to be joined in the context of a DL reasoner. – Ontology header Allows import and reference to resource instances
We have also noted that the ability to assign URI’s to all FHIR code instances and to make all code systems available in an RDF/OWL format would improve general usability. This demonstration is only a first step, however. There are a number of issues that still need to be resolved before FHIR, ontology and reasoners can participate seamlessly, including: Classification Algorithms – Snorocket 23 and ELK 24 are the only two generally available reasoners that can currently classify the entirety of SNOMED CT in a reasonable period of time. 25 The ELK reasoner, however, does not support several required axioms such as ObjectPropertyRange, ObjectAllValuesFrom, ObjectUnionOf, while the current Snorocket reasoner does not recognize the anonymous individuals that form an integral part the FHIR RDF rendering. We use the FACT++ 7 reasoner in this project, which takes over 20 minutes to classify all of SNOMED CT on the machine we were using. As a work-around, we used the RF2Filter? and SNOMEDToOWL?? tools to isolate the classification tree that directly pertained to our particular problem. We plan to work with the Snorocket developers to address the specific issues and hope to employ a pre-classified server instance to achieve the sort of performance necessary to use classifiers in a production environment. ? https://github.com/hsolbrig/SNOMEDToOWL/blob/master/scripts/RF2Filter.
md ?? https://github.com/hsolbrig/SNOMEDToOWL/blob/master/scripts/ SNOMEDToOWL.md FHIR data types – The FHIR Metadata Vocabulary (FMV) includes references to xsd:date, xsd:time, xsd:base64Binary and fhir:xhtml, which are not recognized in the current OWL specification. We had to change these to xsd: dateTime or xsd:string before classification.
Content Negotiation – The FHIR servers currently expect the text/turtle mime type in the Accept header. Protégé currently requests applicaton/rdf+xml. We need work with a combination of the Protégé , FHIR and, perhaps, the W3C communities to arrive at an acceptable way for a client to say "I want OWL and will accept any format".
Anonymous individuals in Protégé - Protégé doesn’t appear to have a useful way of displaying or editing the sort of nested blank nodes that appear in the FHIR resource rendering?.
None of these issues are insurmountable and we anticipate being able to address all of them in the relative short term, with the goal of being able to connect a DL classifier to a FHIR data flow and to use it to categorize and recognize events that call for extra processing, adverse advent monitoring, clinical trial enrollment, etc.
This study is supported in part by NIH grants U01 HG009450 and U01 CA18094. This work was conducted using the Protégé resource, which is supported by grant GM10331601 from the National Institute of General Medical Sciences of the United States National Institutes of Health.
The files used in this project are available at https://github.com/BD2KOnFHIR/ BlendingFHIRandRDF/swat4ls. ? While it would possible provide dummy names for blank nodes for demonstration purposes, doing so would be impractical in a large scale, production environment (All URL’s accessed October 1, 2017.)