Resource Links and Concept IRIs

FHIR RDF defines extra properties which are useful for RDF, SPARQL [[sparql11-query]], ShEx [[ShExSpec]], and OWL [[owl2-overview]].

First, FHIR RDF data elements with associated URIs, including relative references to other FHIR resources, can include an additional resource link with fhir:l to an IRI, which can be natively dereferenced by RDF applications. Example 2 shows a reference to "Patient/pat1", where "Patient" indicates the resource type, rendered with fhir:l link to <Patient/pat1>.

Second, a coded FHIR RDF data element can include a concept IRI, which associates the code to an externally defined RDF resource, such as an OWL ontology class. Example 2 shows SNOMED® and LOINC® codes used for "Body Weight" with corresponding concept IRIs added for their RDF or OWL versions.

FHIR defines a CodeableConcept as an element with an optional text value and/or one or more Codings, where each Coding can have a code, its source system, and an optional display value. Multiple Codings are allowed for a single CodeableConcept only if their codes can apply to the same thing, or as the FHIR specification states: "Strictly, based on ISO 704, the intersection of their 'extensions' is not empty". In ISO 704, the extension of a "concept" is the set of things it applies to [[ISO-704]].

Concept IRIs in FHIR RDF make this feature of CodeableConcepts more explicit when a concept IRI is available and denotes a class resource. RDF defines a class extension of a class resource as the set of things interpreted to be instances of that class. Adding a concept IRI to a CodeableConcept with an rdf:type assertion for each Coding applies this idea: the CodeableConcept is asserted to be an instance of each class denoted by the concept IRI for each Coding, which implies that the class extensions intersect.

@base <http://example.org/> .

<Observation/obs1> a fhir:Observation ;
    fhir:subject [
        fhir:reference [ fhir:v "Patient/pat1" ] ;
        fhir:l <Patient/pat1> # OPTIONAL resource link
    ] ;
    # Class assertions below are commented and don't usually appear in FHIR RDF
    fhir:code [
        # a fhir:CodeableConcept ;
        a loinc:29463-7 ;   # OPTIONAL concept IRI
        a sct:27113001 ;    # OPTIONAL concept IRI
        fhir:coding ( [
            # a fhir:Coding ;
            fhir:system [ fhir:v "http://loinc.org"^^xsd:anyURI ] ; 
            fhir:code [ fhir:v "29463-7" ] ;
            fhir:display [ fhir:v "Body Weight" ]
        ] [
            # a fhir:Coding ;
            fhir:system [ fhir:v "http://snomed.info/sct"^^xsd:anyURI ] ;
            fhir:code [ fhir:v "27113001" ] ;
            fhir:display [ fhir:v "Body weight" ]
        ] ) ;
        fhir:text [ fhir:v "Weight" ]
    ] .

<Patient/pat1> a fhir:Patient ; # Abbreviated
    fhir:id [ fhir:v "pat1" ] .

Using rdf:type with a concept IRI directly on a CodeableConcept is sometimes a pragmatic modeling shortcut since the CodeableConcept might not be literally an instance of the class. Concept IRIs can denote a wide range of entities and therefore require careful interpretation in explicit mapping contexts in order to avoid conflating data elements, functioning as information models, with instances of other ontology classes. The Concept IRI Extension (in the sense of "extensibility", not "class extension") alternatively encodes concept IRIs as resource links so that these values may be exchanged in FHIR JSON or FHIR XML, shown in Example 3.

<Observation/obs2> a fhir:Observation ;
    fhir:code [
        # a fhir:CodeableConcept ;
        fhir:coding ( [
            # a fhir:Coding ;
            fhir:system [ fhir:v "http://loinc.org"^^xsd:anyURI ] ; 
            fhir:code [ fhir:v "29463-7" ] ;
            fhir:display [ fhir:v "Body Weight" ] ;
            # RDF Concept IRI extension
            fhir:extension ( [
                fhir:url [ fhir:v "http://hl7.org/fhir/StructureDefinition/rdf-concept-iri"^^xsd:anyURI ] ;
                fhir:value [
                    a fhir:Uri ;
                    fhir:v "http://loinc.org/rdf/29463-7"^^xsd:anyURI ;
                    fhir:l loinc:29463-7 ; # OPTIONAL resource link with CURIE
                ]
            ] )
        ] )
    ] .

Note that the concept IRI in Example 3 denotes an individual, not a class, because fhir:l is an object property. Data exchanged this way can be transformed for internal analysis in different ways, depending on what each code means. See for more examples.

FHIR ShEx Schema

FHIR ShEx [[FHIR-ShEx]] [[Developing-FHIR-ShEx]] is a set of ShEx (Shape Expressions) [[ShExSpec]] schemas designed for validating FHIR RDF data conformance with FHIR StructureDefinition and ElementDefinition conformance rules represented as ShEx shapes. ShEx schemas use closed-world semantics, where missing data is assumed to be false ("Closed World Assumption") and different IRIs are assumed to name different things ("Unique Name Assumption").

Every publication of the FHIR specification re-builds the FHIR ShEx schemas from all core StructureDefinition resources and includes them for download. The most recent build corresponding to the next pre-release version is also available at https://build.fhir.org/fhir.shex [[FHIR-ShEx-Current]].

OWL 2 Conformance

The FHIR ontology uses OWL 2 DL (Description Logic) [[owl2-syntax]] vocabulary, which includes subclass axioms defined with owl:allValuesFrom, owl:unionOf, and owl:cardinality. The ontology is not entirely conformant with OWL 2 due to its inclusion of a few data types, described below, in order to accurately reflect the vocabulary of FHIR RDF.

FHIR primitive type elements include literal data types from XML Schema [[xmlschema11-2]] such as xsd:string and xsd:dateTime. OWL 2 reasoners do not support xsd:date, xsd:time, xsd:gYear, or xsd:gYearMonth used in FHIR data, so values of these types need to be converted to a supported data type such as xsd:dateTime, or to a qualified time:DateTimeDescription, for use with an OWL 2 reasoner. Note that xsd:dateTime adds more information which is not implied by data types like xsd:date or xsd:time.

FHIR R5+ RDF uses RDF collections to track element order, but OWL 2 does not generally support RDF collections because that vocabulary is reserved for the RDF serialization of OWL axioms [[owl2-mapping-to-rdf]]. Applications could translate RDF collections into indexed triples with the fhir:index property used by earlier FHIR RDF versions, either for use with OWL or to enable more concise SPARQL queries. However, conformant FHIR R5+ RDF data is expected to be exchanged and validated using RDF collections.

Because it is intended for use with FHIR Turtle data, the FHIR ontology is currently distributed only in Turtle, while conformant OWL 2 [[owl2-conformance]] tools are only required to support ontologies serialized in RDF/XML. The FHIR ontology could be converted to RDF/XML if needed, but that serialization is not intended to be used with the FHIR XML representation, which does not use RDF.

        :pat1 a fhir:Patient ;
            # RDF collections
            fhir:name ( [
                fhir:given ( [ fhir:v "Peter" ] [ fhir:v "James" ] )
            ] [
                fhir:given ( [ fhir:v "Jim" ] )
            ] ) .

        :pat2 a fhir:Patient ;
            # Indexed triples
            fhir:name [
                fhir:given [ fhir:v "Peter" ; fhir:index 0 ], 
                           [ fhir:v "James" ; fhir:index 1 ] ;
                fhir:index 0 ;
            ] , [
                fhir:given [ fhir:v "Jim" ; fhir:index 0 ] ;
                fhir:index 1 ;
            ] .
        

Mappings

Every FHIR StructureDefinition and ElementDefinition defined for a FHIR resource has a mapping to an informal, non-normative taxonomy called W5 ("Five Ws"), which stands for "Who, What, Where, When, Why". The FHIR ontology is distributed with these mappings represented as rdfs:subClassOf and rdfs:subPropertyOf relations and with the W5 OWL taxonomy imported, which offers a more intuitive view of how each FHIR resource type is categorized across contexts of use such as clinical, administrative, or financial. These mappings are neither normative nor required, so removing the owl:imports statement and corresponding mappings will not affect the FHIR ontology.

FHIR resources may also be mapped to the HL7 RIM (Reference Information Model) [[HL7v3-comparison]], but those mappings are neither required nor represented in the FHIR ontology.

Structure Definitions

A FHIR structure definition or StructureDefinition defines rules about the structure and content of FHIR resources, elements, and data types. Every FHIR StructureDefinition resource is itself an instance of the StructureDefinition type.

The FHIR ontology maps each StructureDefinition in the core FHIR specification [[FHIR]], except for example FHIR profiles, to an OWL class representing the set of valid instances of that FHIR resource or data type. For example, the class fhir:Patient represents the set of valid FHIR Patient resources, while fhir:Address represents the set of valid FHIR Address typed data elements.

Each class is assigned an IRI mapped from the StructureDefinition's name, prefixed with the FHIR namespace http://hl7.org/fhir/. The fhir:Patient class has the IRI http://hl7.org/fhir/Patient, while the StructureDefinition instance itself is assigned an IRI mapped from its canonical URL, http://hl7.org/fhir/StructureDefinition/Patient.

An OWL class interpreted as an RDF class is just another RDF resource. An RDF class is distinct from its class extension, which is the set of resources that are instances of that class, under a given interpretation. An rdf:type triple asserts class membership, but membership may also be inferred from axioms and is not limited to explicitly asserted rdf:type triples.

The FHIR ontology represents the relationship between a StructureDefinition resource instance and its corresponding OWL class with an rdfs:isDefinedBy annotation on the class, so RDF applications can navigate from a FHIR resource to the OWL class it is an instance of, and then to the defining StructureDefinition resource. FHIR ontology classes therefore act as links between FHIR RDF resource or data type instances and their StructureDefinitions.

To summarize: A StructureDefinition resource defines rules about a FHIR resource or data type. Its corresponding FHIR ontology class represents a set of valid instances of that type. Both are encoded as data in Turtle.

        # Abbreviated example corresponding to the FHIR StructureDefinition for 'Patient'
        fhir:Patient a owl:Class ;
            rdfs:label        "Patient" ;
            # Provenance annotation and link to StructureDefinition resource instance
            rdfs:isDefinedBy  fhirsd:Patient ;
            # StructureDefinition.description
            rdfs:comment      "Demographics and other administrative information about an individual or animal that is the subject of potential, past, current, or future health-related care, services, or processes." ;
            # StructureDefinition.baseDefinition and mappings
            rdfs:subClassOf   fhir:DomainResource, fhirw5:administrative.individual ;
            # ...
            # Example type and cardinality axioms:
            rdfs:subClassOf   [ rdf:type           owl:Restriction ;
                                owl:onProperty     fhir:name ;
                                owl:allValuesFrom  fhir:HumanName
                              ] ;
            rdfs:subClassOf   [ rdf:type           owl:Restriction ;
                                owl:onProperty     fhir:birthDate ;
                                owl:allValuesFrom  fhir:Date
                              ] ;
            rdfs:subClassOf   [ rdf:type            owl:Restriction ;
                                owl:onProperty      fhir:birthDate ;
                                owl:maxCardinality  1
                              ] ;
            rdfs:subClassOf   [ rdf:type           owl:Restriction ;
                                owl:onProperty     fhir:contact ;
                                owl:allValuesFrom  fhir:Patient.contact
                              ] ;
            # ...
        

FHIR ontology classes can also be equivalently encoded with OWL Manchester syntax [[owl2-manchester-syntax]] as shown in Example 6:

# Abbreviated example of fhir:Patient shown in OWL Manchester Syntax
Class: fhir:Patient
    Annotations: 
        rdfs:label "Patient",
        rdfs:isDefinedBy fhirsd:Patient,
        rdfs:comment "Demographics and other administrative information about an individual or animal that is the subject of potential, past, current, or future health-related care, services, or processes."

    SubClassOf: 
        fhir:DomainResource,
        fhirw5:administrative.individual,
        # ...
        fhir:name only fhir:HumanName,
        fhir:birthDate only fhir:Date,
        fhir:birthDate max 1 owl:Thing,
        fhir:contact only fhir:Patient.contact,
        # ...

Element Definitions

A FHIR element definition or ElementDefinition defines rules about the content of a data element used in a FHIR resource defined in a StructureDefinition.

A complex element like Patient.contact has child elements, each defined by its own ElementDefinition. The canonical FHIR ontology maps each complex ElementDefinition to a separate OWL class to avoid complex nesting of axioms in the corresponding StructureDefinition class. Most of these are subclasses of fhir:BackboneElement but some are subclasses of fhir:Element. Complex elements in FHIR RDF do not include type assertions for these classes. They are simply used to organize the ontology and have no effect on FHIR data generally.

A FHIR "elements ontology" consisting of classes derived from all ElementDefinitions could be generated, but is not included in the canonical FHIR ontology file.

Classes derived from ElementDefinitions are indicated by an rdfs:isDefinedBy annotation to a fragment of a StructureDefinition, e.g. http://hl7.org/fhir/StructureDefinition/Patient#Patient.contact shown in Example 7.

# Abbreviated example corresponding to the FHIR ElementDefinition for 'Patient.contact'
fhir:Patient.contact  a  owl:Class ;
    rdfs:label        "Patient.contact" ;
    # Provenance annotation and link to ElementDefinition element instance
    rdfs:isDefinedBy  <http://hl7.org/fhir/StructureDefinition/Patient#Patient.contact> ;
    # ElementDefinition.definition
    rdfs:comment      "A contact party (e.g. guardian, partner, friend) for the patient." ;
    # ElementDefinition.type.code
    rdfs:subClassOf   fhir:BackboneElement ;

    # ...

    # Example type and cardinality axioms:
    rdfs:subClassOf   [ rdf:type           owl:Restriction ;
                        owl:onProperty     fhir:name ;
                        owl:allValuesFrom  fhir:HumanName
                       ] ;
    rdfs:subClassOf   [ rdf:type            owl:Restriction ;
                        owl:onProperty      fhir:name ;
                        owl:maxCardinality  1
                      ] ;
    rdfs:subClassOf   [ rdf:type           owl:Restriction ;
                        owl:onProperty     fhir:telecom ;
                        owl:allValuesFrom  fhir:ContactPoint 
                      ] ;
    rdfs:subClassOf   [ rdf:type           owl:Restriction ;
                        owl:onProperty     fhir:address ;
                        owl:allValuesFrom  fhir:Address 
                      ] ;
    # ...
        

Class IRIs

All class IRI local names are named with an uppercase first letter (e.g. http://hl7.org/fhir/Patient or fhir:Patient), while all object properties are named with a lowercase first letter. This case-sensitivity avoids punning, where an object property could have the same IRI as a class corresponding to the wrong StructureDefinition. Classes for FHIR primitive types are also named with an uppercase first letter, such as fhir:Code, but are given an rdfs:label annotation with their conventional lowercasing, e.g. "code".

Object Properties

Each ElementDefinition within a StructureDefinition is mapped to an OWL object property and assigned an IRI corresponding to the last segment of the ElementDefinition.path. The object property fhir:l is used only in FHIR RDF for resource links. The object property fhir:nodeRole is used only in FHIR RDF when serializing FHIR resources that contain other FHIR resources as separate RDF resources in a single document. For example, fhir:nodeRole fhir:treeRoot identifies the top-level, containing FHIR resource.

Since version R5, FHIR RDF uses short, unqualified object property IRIs corresponding to each ElementDefinition.path, which makes the Turtle serialization easier to read and makes SPARQL queries easier to write. FHIR object properties have lowercased first letters, which avoids punning them with a class of the same name. For example, fhir:Code is a class for a primitive type, while fhir:code is an object property derived from different ElementDefinitions (Observation.code, Condition.code, etc.).

Unqualified object property names result in different ElementDefinitions being mapped to the same object property. FHIR R5+ object property names are therefore ambiguous except in the context of their use in FHIR data and OWL class axioms. Each object property instance in a FHIR RDF resource can be disambiguated either from the corresponding ElementDefinition in the StructureDefinition for the resource, or from the corresponding property restriction axioms in the OWL class for the resource.

Object properties can also be disambiguated with SPARQL queries (Example 8) or SWRL (Semantic Web Rule Language) [[SWRL]] rules (Example 9). This could result in punning, but only for a class corresponding to the correct ElementDefinition (fhir:Patient.name as an object property and a class):

            CONSTRUCT {
                ?p fhir:Patient.name ?n .
            } WHERE {
                ?p a fhir:Patient . 
                ?p fhir:name ?n .
            }
            

            fhir:Patient(?p) ^ fhir:name(?p, ?n) -> fhir:Patient.name(?p, ?n)
            fhir:Account(?a) ^ fhir:name(?a, ?n) -> fhir:Account.name(?a, ?n)
            # Reverse for converting R4 to R5+ syntax for internal analysis
            fhir:Patient.name(?p, ?n) -> fhir:name(?p, ?n)
            fhir:Account.name(?a, ?n) -> fhir:name(?a, ?n)
            

FHIR object properties do not have specified domain or range axioms because their domains and ranges vary across different contexts, as explained above. The meaning of a property is best understood by its corresponding source ElementDefinition (e.g. <http://hl7.org/fhir/StructureDefinition/Patient#Patient.contact>), class axioms that use the property (e.g. fhir:Patient SubClassOf: fhir:contact only fhir:Patient.contact), or by a derived ElementDefinition class (e.g. class fhir:Patient.contact is the range of fhir:contact for class fhir:Patient).

Data Properties

FHIR RDF represents primitive types — elements with a single literal value such as an xsd:string — using the data property fhir:v. Primitive types, like all FHIR data types, are extensible, and so the fhir:v assertion allows a primitive type element to add a FHIR Extension. The extra fhir:v also prevents punning some choice type elements that can either be a primitive type or non-primitive type (e.g. Observation.value) as both a data property and an object property, which would be non-conformant with OWL 2.

The data property fhir:index was used prior to version R5 and is no longer conformant for exchange, but can be used to convert RDF collections to indexed triples.

Annotation Properties

No FHIR-specific annotation properties are currently defined. StructureDefinition.description and ElementDefinition.definition map to rdfs:comment, and rdfs:isDefinedBy links each derived OWL class or object property to its corresponding StructureDefinition or ElementDefinition(s).

Consistency vs Validity

FHIR data is often described as "valid" or "invalid" with respect to whether it follows conformance rules, beyond just syntax rules. FHIR RDF data could be invalid, in this sense, while logically consistent with the FHIR ontology for two different reasons. First, data might violate a conformance rule that is not represented as an axiom, such as a FHIRPath constraint or an informally described rule. Second, data might violate a conformance rule that is represented as an axiom, such as minimum cardinality, while still being consistent with an open-world interpretation of that axiom.

FHIR ontology axioms are always true of valid FHIR data, but are not always inconsistent with invalid FHIR data. Inconsistency with the FHIR ontology guarantees invalidity, but invalidity does not guarantee inconsistency. A closed-world system like FHIR ShEx or a FHIR validator tool should be used for data validation, while the FHIR ontology axioms are intended for open-world, logical inference.

In practice, invalid FHIR data is exchanged, stored, and analyzed in some FHIR workflows. A SPARQL query for anything that is rdf:type fhir:Patient will return data that includes this assertion, regardless of whether it is invalid or inconsistent with the FHIR ontology.

Base Definitions

The base definition of a StructureDefinition is another StructureDefinition, which the FHIR ontology maps to an rdfs:subClassOf relation between the corresponding OWL classes. For example, fhir:Patient is a subclass of fhir:DomainResource, which is equivalent to the universal statement: Anything that is a FHIR Patient is also a FHIR DomainResource. If a resource is rdf:type fhir:Patient, then an OWL reasoner will infer that it is also rdf:type fhir:DomainResource.

StructureDefinition.abstract means that resources defined by this type shall not be instantiated without instantiating a more specific, non-abstract type. For example, a FHIR resource is invalid if it is asserted to be an instance of fhir:Resource and not a more specific class corresponding to a non-abstract StructureDefinition. The FHIR ontology does not represent StructureDefinition.abstract with an axiom because, in this example, every resource is already implicitly rdf:type fhir:Resource. But OWL does not require this inference to be asserted because of its open-world semantics.

Element Types

An ElementDefinition may define a target element type, the value of which is defined by a StructureDefinition, and therefore represented as an OWL class. For example, if a valid Patient.active element has a value, then its type is boolean, represented as the class fhir:Boolean. The FHIR ontology represents target type relations with owl:allValuesFrom axioms.

A FHIR dateTime is defined as a union of the XML Schema types xsd:dateTime, xsd:date, xsd:gYearMonth, and xsd:gYear. Because the literal value of a primitive type element is represented with fhir:v, fhir:DateTime has an owl:unionOf axiom stating that all of its fhir:v values are one of those XML Schema types.

FHIR choice types, or polymorphic types, are also represented with owl:unionOf. For example, Observation.effective can be a dateTime, instant, Period, or Timing, so fhir:Observation is a subclass of the things whose fhir:effective values are only instances of fhir:DateTime, fhir:Instant, fhir:Period, or fhir:Timing. In FHIR RDF, an instance of a choice type includes an rdf:type assertion stating which of these types it is. This is analogous to the type being suffixed to the element name in JSON, as in the "effectiveDateTime" property of a FHIR JSON Observation.

Reference Types

The reference type of an ElementDefinition defines the type of FHIR resource the element refers to, if at all. For example, every valid Condition.subject refers only to a resource of type Patient or Group. Each FHIR RDF fhir:Reference element optionally asserts an additional fhir:l (resource link) to an IRI for the referenced resource. The FHIR ontology represents reference type relations with owl:allValuesFrom axioms on fhir:l.

Element Cardinality

The cardinality of an ElementDefinition defines how many values the element could have. The FHIR ontology represents element cardinality with owl:cardinality, owl:minCardinality, and owl:maxCardinality axioms on the class corresponding to its StructureDefinition or parent, complex ElementDefinition. For example, Condition.subject has a minimum and maximum cardinality of 1, so every valid fhir:Condition instance is related via fhir:subject to exactly one thing. Cardinality axioms are separate from reference type axioms.

Minimum cardinality axioms in OWL are usually not inconsistent with RDF data due to its open-world semantics. An instance of fhir:Condition may be missing a fhir:subject, but an OWL reasoner will not assume that represented condition is not associated with anyone, nor will it assume that the missing data does not exist anywhere else — like in another part of a distributed system. A closure axiom stating that the fhir:Condition resource only has the fhir:subject values explicitly stated would be needed for an inconsistency. For data validation, the FHIR ShEx schema can instead be used to check whether the required data is present. Minimum cardinality axioms are more useful as sufficient conditions in owl:equivalentClass axioms for analytics.

Maximum cardinality axioms can detect some inconsistencies for invalid data, but they can also lead to unintuitive inferences. If a fhir:Condition has more than one fhir:subject (which would be invalid FHIR in a closed-world interpretation), an OWL reasoner would infer that the subjects are the same, unless given a reason why they are distinct. This reflects how "at most one" is represented in first-order logic, which is the basis of the description logic underlying OWL: ∀x∀y∀z((Condition(x) ∧ subject(x,y) ∧ subject(x,z)) → y=z) means "If x is a Condition and has a subject y, then any subject z is y" — where y and z are not unique names.

Fortunately, FHIR resources and elements can be distinguished by their primitive type elements. Two instances of fhir:Patient with different fhir:id values will be inferred to be distinct, because fhir:Id has at most one fhir:v literal value. Similarly, any other primitive type elements like fhir:String or fhir:Uri are uniquely identifiable by their fhir:v values, and therefore necessarily distinct.

Element Slicing

A FHIR sliced element type could have multiple values of different element types and with different cardinalities. Slicing types are only used in FHIR profiles, not in the core FHIR StructureDefinitions, and therefore are not represented in the FHIR ontology. Profiles may be similarly mapped to OWL classes and slicing types represented with owl:qualifiedCardinality axioms.

FHIRPath Constraints

FHIRPath expressions are not mapped to OWL axioms but could be in the future.

ValueSet Bindings

The ValueSet bindings of an ElementDefinition specify which sets of codes are intended to be used as values for this element. The FHIR ontology does not represent ValueSet bindings but could in the future.

Analytics

Custom, defined classes can encode reusable logic that composes with SPARQL queries [[Blending-FHIR-OWL]]. This works especially well with concept IRIs for external OWL classes corresponding to terminology codes. Example 10 is a FHIR SPARQL query for all Patients with some DiagnosticReport with the SNOMED code for "Malignant neoplastic disease", 363346000. This simplified query assumes the data includes no RDF collections.

SELECT ?patient WHERE {
    ?diagnosticReport a fhir:DiagnosticReport ;
        fhir:conclusionCode [
            fhir:concept [
                fhir:coding [
                    fhir:code [ fhir:v "363346000" ] ;
                    fhir:system [ fhir:v "http://snomed.info/sct"^^xsd:anyURI ]
                ]
            ]
        ] ;
        fhir:subject/fhir:l ?patient .

    ?patient a fhir:Patient .
}
            

This logic can be re-defined and extended in an OWL class in Example 11 that takes advantage of FHIR RDF concept IRIs instead of relying on literal code values.

# "fhir:DiagnosticReport 
#  and fhir:conclusionCode some 
#     (fhir:concept some 'Malignant neoplastic disease (disorder)')"
:CancerReport a owl:Class ;
    owl:equivalentClass [ 
        owl:intersectionOf ( 
            fhir:DiagnosticReport
            [ rdf:type owl:Restriction ;
              owl:onProperty fhir:conclusionCode ;
              owl:someValuesFrom [ 
                    rdf:type owl:Restriction ;
                    owl:onProperty fhir:concept ;
                    owl:someValuesFrom sct:363346000
              ]
            ]
        )
    ] .

Given a relevant fragment of SNOMED OWL (at least the term sct:363346000 and its subclasses) [[SNOMED-OWL-Toolkit]], an OWL 2 EL [[owl2-profiles]] reasoner like ELK [[ELK]] will infer the statement a :CancerReport on any matching data. These inferred statements can be saved to a materialized graph, similar to a materialized view.

The defined OWL class :CancerReport provides two benefits: First, it can classify not only DiagnosticReports coded with 363346000, but also DiagnosticReports with any code subsumed by 363346000. Second, it can be reused to compose multiple different queries like in Example 12 or other classes in a consistent way.

SELECT ?patient WHERE {
    ?diagnosticReport a :CancerReport ;
        fhir:subject/fhir:l ?patient .

    ?patient a fhir:Patient .
}
            

Example 13 shows further composition using terms like owl:inverseOf, which goes beyond OWL 2 EL.

# "fhir:Patient 
#  and ( inverse (fhir:l) some 
#      ( inverse (fhir:subject) some :CancerReport))"
:PatientWithCancerReport a owl:Class ;
    owl:equivalentClass [ 
        owl:intersectionOf ( 
            fhir:Patient
            [ rdf:type owl:Restriction ;
              owl:onProperty [ owl:inverseOf fhir:l ] ;
              owl:someValuesFrom [ rdf:type owl:Restriction ;
                                   owl:onProperty [ owl:inverseOf fhir:subject ] ;
                                   owl:someValuesFrom :CancerReport
                                 ]
            ]
        )
    ] .

Materializing the inferred instances of this class enables SPARQL queries to be further reduced to Example 14:

SELECT ?patient WHERE {
    ?patient a :PatientWithCancerReport .
}
            

Graph Projections

Simplified "knowledge graphs" can be derived from the FHIR ontology using SPARQL to more compactly encode or visualize queryable FHIR resource type and element type relationships. For example, one might derive a triple like fhir:Patient fhir:contact fhir:Patient.contact. Note that fhir:Patient and fhir:Patient.contact in that triple would be interpreted by OWL as individuals, unrelated to the classes named by the same IRIs. These kinds of graphs are best used in contexts separate from FHIR RDF data and the FHIR ontology for that reason.

Simplified graph projections of the FHIR ontology can also serve as "context layers" for large language models and queried progressively for quick reference.

Mapping

The FHIR ontology can be used to map between FHIR and non-FHIR concepts or data using techniques that do not depend on FHIR-specific tooling.

Ontology-based data access systems such as Ontop (open-source) can rewrite OWL 2 QL [[owl2-profiles]] axioms and SPARQL queries to SQL. This has been used with the FHIR ontology to dynamically rewrite FHIR SPARQL [[FHIR-Ontop-OMOP]] to SQL queries over OMOP relational data [[OMOP]].

Terminology mappings using rdfs:subClassOf, owl:equivalentClass, or SKOS [[skos-reference]] can sometimes be used instead of FHIR ConceptMap resources, or be derived from them. When a mapping is encoded with a property like rdfs:subClassOf, OWL reasoners can classify the mapped codes to enrich data analytics as described in the previous section. These kinds of simple mappings can also be queried as data, even with properties that have no significant, defined logical consequences, such as skos:relatedMatch shown in Example 15.

FHIR resources can be interpreted more literally as information models to better integrate with some ontologies, like those from the Open Biological and Biomedical Ontology Foundry [[OBO]]. The relationship between a coded data element and a concept IRI could be interpreted with a mapping from the Information Artifact Ontology. Example 15 shows an Observation.code element that is about (obo:IAO_0000136) a clinical finding of tinnitus. The clinical finding is interpreted to be something that someone participates in, to say the least [[SNOMED-BFO-Schulz]], using the term obo:RO_0000056 from the Relations Ontology. The tinnitus itself is represented as a phenotypic abnormality in the context of the Human Phenotype Ontology, but its direct relationship to the clinical finding is left unspecified in this example.

@prefix obo:  <http://purl.obolibrary.org/obo/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@base <http://example.org/> .

<Observation/observationRecord> a fhir:Observation ;
    fhir:subject [
        fhir:reference [ fhir:v "Patient/patientRecord" ] ;
        fhir:l <Patient/patientRecord> # OPTIONAL resource link
    ] ;
    # Re-interpretation of concept IRI. Coding omitted for brevity.
    fhir:code [
        # 'is about' from Information Artifact Ontology
        obo:IAO_0000136 :exampleTinnitusFinding ;
    ] .

# 'Tinnitus (finding)' from SNOMED
:exampleTinnitusFinding a sct:60862001 . 

# 'tinnitus' from Human Phenotype Ontology
:exampleTinnitus a obo:HP_0000360 .

# Alternative, non-specific terminology mapping
sct:60862001 skos:relatedMatch obo:HP_0000360 . 

:examplePerson a obo:MF_0000016 ; # 'human being' from Mental Functioning Ontology
    # 'participates in' from Relations Ontology
    obo:RO_0000056 :exampleTinnitusFinding ;
    # 'has phenotype' from Relations Ontology
    obo:RO_0002200 :exampleTinnitus .

Example 16 shows separate fhir:Patient and fhir:Person resources that are about (obo:IAO_0000136) the same person, who has role (obo:RO_0000087) some patient role (obo:OBI_0000093), where the latter term comes from the Ontology for Biomedical Investigations. The :invalidRecord shows a wrong way to express this: Patient and Person resources cannot be validly combined in FHIR.

# Invalid example — these resource types are distinct
# :invalidRecord a fhir:Patient, fhir:Person .

# Valid, associated FHIR Patient and FHIR Person records
<Patient/patientRecord> a fhir:Patient .

<Person/personRecord> a fhir:Person ;
    fhir:link ( [
        fhir:target [
            fhir:l <Patient/patientRecord> ;
            fhir:reference [ fhir:v "Patient/patientRecord" ] ;
        ] ;
    ] ) .

# Monotonic mapping to ontologies
<Patient/patientRecord> a obo:OBI_0000078 ; # 'eMedical record' from Ontology for Biomedical Investigations
   # 'is about' 
   obo:IAO_0000136 :examplePerson .

<Person/personRecord> a obo:OBI_0000078 ; # 'eMedical record' from Ontology for Biomedical Investigations
    # 'is about'
    obo:IAO_0000136 :examplePerson .

# 'has role' from Relations Ontology
:examplePerson obo:RO_0000087 [ 
        a obo:OBI_0000093 ; # 'patient role' from Ontology for Biomedical Investigations
    ] .

Alternative interpretations of FHIR resources are possible. Tinnitus can be modeled as associated with a kind of symptom, disease, disorder, process, disposition, etc. depending on the context. A mapping is valuable not only when it is correct, but also when it helps us understand exactly why it might be incorrect. Note that the FHIR RDF data in Examples 15 and 16 are not conformant for exchange and the core FHIR specification does not endorse any mappings like these, which will vary depending on the data, codes, ontologies, and perspectives involved.