--- type: "doc" source: "source/rdf.html" --- \[%settitle RDF Representation%\] \[%file newheader%\] \[%file newnavbar%\] <%fmtheader rdf%> ## Resource Description Framework (RDF) / Turtle Representation | Responsible Owner: [\[%wgt its%\]]([%wg its%]) Work Group | [Standards Status](versions#std-process):[Normative](versions#std-process) | | --- | --- | | [![W3C RDF](https://www.w3.org/Icons/SW/Buttons/sw-rdf-blue-v.svg)](http://www.w3.org/2001/sw/wiki/RDF) | This page and the RDF Turtle forms are jointly maintained by the HL7 FHIR project -- especially the [RDF subgroup](https://confluence.hl7.org/pages/viewpage.action?pageId=66922543) of the [ITS work group](http://www.hl7.org/Special/committees/xml/index.cfm) -- and the [W3C Semantic Web Health Care and Life Sciences Interest Group](https://www.w3.org/blog/hcls/). | | --- | --- | FHIR resources can be represented as an [RDF graph](http://www.w3.org/RDF/) serialized in the [Turtle format](https://www.w3.org/TR/turtle/). The Turtle format is defined to assist the process of bridging between operational data exchange and formal knowledge processing systems. While the Turtle form offers a fully functional representation of FHIR resources, it has different operational characteristics from the [JSON](json) and [XML](xml) representations, and would be used for different reasons. Systems focused on operational exchange of data would not usually choose to use Turtle. This page describes: - [Turtle Prefixes](#prefixes) - [Turtle Template for Resources](#turtle-template) - [FHIR Turtle Example](#example) - [FHIR Turtle Serialization Conventions](#serialization-conventions) - [Representing Resources](#resources) - [Nested Anonymous Nodes](#nestedNodes) - [Property Names and Polymorphism](#propertyNames) - [Case Sensitivity](#caseSensitivity) - [Repeating Elements -- RDF Lists](#rdflist) - [Primitive Elements](#primitive) - [Primitive Elements with Union Types](#union-types) - [Turtle Shorthand for Primitive Literals](#turtle-shorthand) - [Primitive URI Types](#primitive-uris) - [References](#reference) - [Inline Resources -- Bundled or contained](#contained) - [Identifying Concepts in a Terminology](#identifying-concepts) - [Concept IRIs and IRI Stems](#iri-stem) - [Non-modifier Extensions](#extension) - [Modifier Extensions](#modifierExtension) - [ShEx Schema and FHIR RDF, W5 and HL7 v3 RIM Ontologies](#owl-shex-rim) - [Usage Guidance for OWL and ShEx](#guidance) - [Relationship Between RDF, FHIR and Other Ontologies](#relationship) - [Tutorials](#tutorials) - [Appendix 1: Algorithm for creating a Concept IRI](#concept-iri-algorithm) - [Appendix 2: Registering an IRI Stem on the HL7 Terminology Website](#registering-iri-stems) ### Turtle Prefixes The following Turtle prefixes are used in FHIR Turtle examples, the [FHIR ontology, and the ShEx schema](#guidance). \# These are typically used in FHIR Turtle data: @prefix fhir: . @prefix xsd: . @prefix rdf: . @prefix rdfs: . @prefix owl: . @prefix loinc: . # For LOINC codes @prefix sct: . # For SNOMED-CT codes # These are normally only used in the OWL ontology or ShEx schema: @prefix fhirvs: . @prefix fhirsd: . @prefix fhirw5: . @prefix dc: . ### Turtle Template for Resources Each resource page has a set of language templates describing the FHIR expression in that language. The Turtle representation for a resource is described using this format: \[ a fhir:Observation; fhir:nodeRole fhir:treeRoot; # if this is the parser root # from Resource: fhir:id; fhir:meta; fhir:implicitRules; and fhir:language # from DomainResource: fhir:text; fhir:contained; fhir:extension; and fhir:modifierExtension fhir:identifier ( \[ [Identifier](datatypes#Identifier) \] ... ) ; # 0..\* Business Identifier for observation fhir:status \[ [code](datatypes#code) \]; # 1..1 registered | preliminary | final | amended ... fhir:code \[ [CodeableConcept](datatypes#CodeableConcept) \]; # 1..1 Type of observation (code / type) fhir:subject \[ [Reference](references#Reference)([BiologicallyDerivedProduct](biologicallyderivedproduct#BiologicallyDerivedProduct)|[Device](device#Device)|[Group](group#Group)...) \]; # 0..1 Who and/or what this is about fhir:encounter \[ [Reference](references#Reference)([Encounter](encounter#Encounter)) \]; # 0..1 Healthcare event during which this observation is made # effective\[x\]: 0..1 Clinically relevant time/time-period for observation. One of these 4: fhir:effective \[ a fhir:DateTime ; [dateTime](datatypes#dateTime) \]; fhir:effective \[ a fhir:Period ; [Period](datatypes#Period) \]; fhir:effective \[ a fhir:Timing ; [Timing](datatypes#Timing) \]; fhir:effective \[ a fhir:Instant ; [instant](datatypes#instant) \]; ... \] Using this format: - To build a valid Turtle instance of a resource, replace the contents of the property values with valid content as described by the type rules and content description found in the property value for each element. - Nodes are never empty. If an element is present in the resource, it SHALL have properties as defined for its type, or 1 or more [extensions](extensibility). - `**0..1**` indicates an OPTIONAL element, i.e., minimum cardinality 0 and maximum cardinality 1. Similarly `**1..1**` indicates a required element. - `**0..***` or `**1..***` indicates an OPTIONAL or REQUIRED element (respectively) with no maximum cardinality. - Any element that allows more than one value is represented as an RDF list (see [below](#rdflist)). If an RDF list is provided, it SHALL NOT be empty. - Content type shown as `[Reference](references#Reference)([BiologicallyDerivedProduct](biologicallyderivedproduct#BiologicallyDerivedProduct)|[Device](device#Device)|[Group](group#Group)...)` means that it must be a [Reference](references#Reference) to a [BiologicallyDerivedProduct](biologicallyderivedproduct#BiologicallyDerivedProduct), or a [Device](device#Device), or a [Group](group#Group), etc. - **`# effective[x]`** indicates a polymorphic property ([see below](#propertyNames)), whose value (in this example) may be a fhir:DateTime, fhir:Period, fhir:Timing or fhir:Instant. Note that examples in this specification show Turtle that is nicely formatted and well laid out, but that is not required or expected in conforming FHIR Turtle. ### FHIR Turtle Example An example FHIR Turtle Observation illustrates the Turtle language and the additional conventions used by FHIR Turtle: # bgpanel has type fhir:Observation a fhir:Observation ; fhir:nodeRole fhir:treeRoot ; # and is the root of this document. fhir:id \[ fhir:v "bgpanel"\] ; # Its id is bgpanel. fhir:status \[ fhir:v "final"\] ; # It has an (extensible) status of final. fhir:code \[ # It has code, fhir:coding ( \[ # given by a list of Codings, a loinc:34532-2 ; # each having an OPTIONAL concept IRI (see below) fhir:system \[ # plus a code system URI fhir:l ; # (as an OPTIONAL RDF node, fhir:v "http://loinc.org"^^xsd:anyURI \] ; # but always as a literal), # and a code: fhir:code \[ fhir:v "34532-2" \] \] ) \] ; fhir:subject \[ fhir:l ; fhir:reference \[ fhir:v "Patient/infant" \] \] ; # … In this example, - the subject [IRI](https://www.rfc-editor.org/rfc/rfc3987) is wrapped with '`< ... >`', - the type (`fhir:Observation`) and following properties (e.g., `fhir:status`) are prefixed names (like XML namespaced names), - assertions following a ';' re-use the same subject, - anonymous nodes are declared with '`[ ... ]`'s, - and literals with a quoted value and an optional datatype preceded by '^^' (e.g., `"http://loinc.org"^^xsd:anyURI`). ### FHIR Turtle Serialization Conventions FHIR Turtle imposes additional conventions to simplify recognition and manipulation of FHIR RDF graphs.  Although RDF graphs in general may be serialized in any RDF format, FHIR RDF mandates support specifically for [Turtle](https://www.w3.org/TR/turtle/). All FHIR RDF documentation is expressed in Turtle.   And while the standard media type for Turtle is `text/turtle`, the use of Turtle for FHIR RDF uses the specialized media type `application/fhir+turtle`. FHIR uses [Shape Expressions (ShEx)](https://shex.io/shex-semantics/) to help define and validate FHIR RDF. See [fhir.shex](fhir.shex) for the complete FHIR RDF schema. Each Resource page includes a link for the subset of fhir.shex needed to describe that Resource. The media type for ShEx is `text/shex.` #### Representing Resources Each resource is represented as a set of RDF triples. When a resource has a persistent identity (e.g., it can be found at a particular URL -- usually a FHIR RESTful server), then that URL is its identity. Resources with no persistent identity (e.g., bundles from search results) have the identity of the root document -- "<>" in Turtle syntax. In the above example, the resource is the subject: ``. Some resources can contain other resources. Given that the relationships can appear in any order in RDF, it cannot be assumed that the first encountered element represents the resource of interest that is being represented by the set of Turtle statements. The focal resource -- the Resource that is not contained in any other Resource -- is indicated by having a `fhir:nodeRole` property with a value of `fhir:treeRoot`. If there is more than one node labeled as a 'treeRoot' in a set of Turtle statements, it may be impossible to deterimine which is the outermost Resource. #### Nested Anonymous Nodes Content within a resource is normally represented with anonymous nodes (a/k/a "blank nodes"), unless something else needs to reference that content.  Normally only FHIR Resource nodes are [IRIs](https://www.rfc-editor.org/rfc/rfc3987). For example, this Turtle: fhir:status \[ fhir:v "final" \] asserts that: - `` has a `status` of some anonymous node. - That anonymous node has a value of `"final"` (a literal), indicated by the `fhir:v` property. (See [Primitive Elements](#primitive) below.) #### Property Names and Polymorphism Property names in FHIR RDF are shared across resources: the same property may be used in several different resources. For example, `fhir:status` is spelled the same way regardless of whether it appears in an Observation, Diagnosis, or any other FHIR Resource. Some properties are polymorphic within a resource: the property may offer a choice of more than one permissible object type. If the Structure tab in a resource's HTML page shows "\[x\]" next to a property, such as value\[x\], then that property is polymorphic in FHIR RDF. (Alternatively, if the `type` property in the resource's structure definition shows a list of two or more types for a given property's value, then the property is polymorphic in FHIR RDF. For example, see the `value` property in [Observation's JSON structure definition](observation.profile.json).) In other formats (XML, JSON), a FHIR property with a choice of value types has the type appended to the property name, e.g., valueQuantity if the value is a [Quantity](datatypes#Quantity) (i.e., Observation.valueQuantity). But in FHIR RDF, it is written as a polymorphic `fhir:value` property, and the object asserts its type explicitly, as shown in the following excerpt from an [Observation body weight example](observation-example.ttl). Confusingly, this excerpt happens to include a second (nested) `fhir:value` property, which is a property of the [Quantity](datatypes#Quantity) datatype (i.e., Quantity.value), and whose type is indicated directly by the xsd:decimal datatype attached to its `fhir:v` literal value. **fhir:value** \[ # From Observation.value\[x\] (Observation.valueQuantity) **a fhir:Quantity ;** fhir:value \[ fhir:v "185"^^xsd:decimal \] ; # From Quantity.value fhir:unit \[ fhir:v "lbs" \] ; fhir:system \[ fhir:l ; fhir:v "http://unitsofmeasure.org"^^xsd:anyURI \] ; fhir:code \[ fhir:v "\[lb\_av\]" \] \] ; #### Case Sensitivity While RDF property names are case-sensitive, FHIR avoids confusion by assuring that there are no properties that differ only in case. #### Repeating Elements -- RDF Lists Elements that can repeat are represented with [RDF lists](https://www.w3.org/TR/turtle/#collections) (officially called "RDF collections") in order to retain the order of their elements. For example this `fhir:coding` property holds a list of two members: fhir:coding **(** \[ a … \] \[ a … \] **)** Since RDF lists can cause problems for OWL users, a [script](https://github.com/w3c/hcls-fhir-rdf/tree/gh-pages/scripts/owl-safe-lists) can convert RDF lists to an alternate representation. See [Using FHIR RDF with OWL](#fhir-rdf-with-owl) for more info. #### Primitive Elements Primitive elements -- elements with a primitive type -- are represented as anonymous nodes, both so that extensions can be attached and so that they can be consistently treated as OWL object properties (versus sometimes being datatype properties). Inside the anonymous node: - The FHIR [datatype](datatypes) MUST be asserted using `rdf:type` (or **`a`** in Turtle shorthand) if it is not implied by the property whose value is being represented. See [Property Names and Polymorphism](#propertyNames) for more explanation. - The name of each FHIR primitive type, such as [code](datatypes#code), is capitalized when written as an RDF class name: `fhir:Code` . This is done to avoid having a name clash with the `fhir:code` property, since RDF is case sensitive. For consistency, the RDF class name for the FHIR [xhtml](narrative#xhtml) is also capitalized `fhir:Xhtml` even though it is technically a [special](datatypes) type. All other FHIR RDF names use the same capitalization conventions as in the FHIR content model, JSON and XML. - Each FHIR type is represented by a particular [XML Schema Datatype (XSD)](https://www.w3.org/TR/xmlschema11-2/), written with an `xsd:` or `xs:` prefix, or an RDF datatype. - The value of the primitive type is written as an RDF Literal using the `fhir:v` property, which is the only FHIR property that directly holds an RDF literal -- i.e., it is the only OWL datatype property in FHIR RDF -- and it always holds an RDF Literal. - A `fhir:v` literal has two parts: a quoted string that contains the value, and an XSD or RDF type: fhir:v "\[value\]"^^xsd:type The XSD type is one of the following [XML Schema Datatypes (XSD)](https://www.w3.org/TR/xmlschema11-2/), typically written with an `xsd:` or `xs:` prefix: [boolean](https://www.w3.org/TR/xmlschema11-2/#boolean), [integer](https://www.w3.org/TR/xmlschema11-2/#integer), [decimal](https://www.w3.org/TR/xmlschema11-2/#decimal), [base64Binary](https://www.w3.org/TR/xmlschema11-2/#base64Binary), [dateTime](https://www.w3.org/TR/xmlschema11-2/#dateTime), [date](https://www.w3.org/TR/xmlschema11-2/#date), [gYear](https://www.w3.org/TR/xmlschema11-2/#gYear), [gYearMonth](https://www.w3.org/TR/xmlschema11-2/#gYearMonth) or [time](https://www.w3.org/TR/xmlschema11-2/#time). RDF type `rdf:XMLLiteral` is used for values of FHIR type [xhtml](narrative#xhtml). For example, a value of FHIR type [positiveInt](datatypes#positiveInt) is an anonymous node with a `fhir:v` assertion and possibly a type assertion, like one of the following: \[ fhir:v "2"^^xsd:positiveInteger \] # With implied FHIR type \[ a fhir:PositiveInt ; fhir:v "2"^^xsd:positiveInteger \] # With explicit FHIR type The fhir:v property can never be empty. Either the relationship is absent, or it is present with at least one character of content. XHTML is represented as an escaped xsd:string.  #### Primitive Elements with Union Types Some FHIR primitive datatypes are defined as a union of multiple XML Schema datatypes: - FHIR [date](datatypes#date) (union of xsd:date, xsd:gYearMonth, xsd:gYear); - FHIR [dateTime](datatypes#dateTime) (union of xsd:dateTime, xsd:date, xsd:gYearMonth, xsd:gYear); and - FHIR [decimal](datatypes#decimal) (union of xsd:decimal, xsd:double). In such cases, the correct XSD type must be determined by inspecting the literal value for conformance with one of the union XSD types for that FHIR type. For example, since a FHIR [decimal](datatypes#decimal) is a union of [xsd:decimal](https://www.w3.org/TR/xmlschema-2/#decimal) and [xsd:double](https://www.w3.org/TR/xmlschema-2/#double), any value with an 'e' or 'E' in it is an xsd:double, otherwise it is an xsd:decimal. For example, for a property whose value is a FHIR [decimal](datatypes#decimal), an literal value of `"185"` must be given the XSD datatype `xsd:decimal` because it does not contain 'e' or 'E'. Values of other FHIR union types -- [date](datatypes#date) or [dateTime](datatypes#dateTime) must be handled similarly, to assign the most specific XSD type that matches the given literal value. #### Turtle Shorthand for Primitive Literals Literal values that can be represented using Turtle shorthand notation for xsd:string, xsd:integer, xsd:decimal, xsd:double or xsd:boolean MAY optionally use shorthand instead of the long form described above. However, authors of FHIR Turtle serializers are advised to be aware that there are some differences between what is permitted in FHIR, Turtle shorthand, and XSD literals, and these differences can affect Turtle serialization of FHIR. For example: - The FHIR [decimal](datatypes#decimal) datatype is represented by [xsd:decimal](https://www.w3.org/TR/xmlschema11-2/#decimal) in Turtle. Turtle shorthand for an xsd:decimal value requires a decimal point, whereas the xsd:decimal type does not. Therefore, a FHIR [decimal](datatypes#decimal) value of 185 must either have a decimal point explicitly added, like 185.0, or the type must be explicitly indicated, like `"185"^^xsd:decimal`. Otherwise 185 in Turtle would be parsed as an xsd:integer. - Neither the FHIR [boolean](datatypes#boolean) datatype nor the Turtle shorthand for an xsd:boolean allows a literal value of 0 or 1, though [xsd:boolean](https://www.w3.org/TR/xmlschema11-2/#boolean) does. #### Primitive URI Types To facilitate linkage in RDF graphs, if a primitive has FHIR type [uri](datatypes#uri) or one of its subtypes (url, canonical, uuid, oid), then a `fhir:l` property -- previously called `fhir:link`, in FHIR R5 -- is RECOMMENDED as a sibling of the `fhir:v` property. The value of the `fhir:l` property is an RDF node having the same URI as the URI given in the `fhir:v` property, with one exception. If the `fhir:v` URI contains a vertical bar ("|", aka pipe symbol) then it represents a version indicator, which is stripped off and converted into a "?version=" query string, like this: fhir:measure \[ a fhir:Canonical ; fhir:l ; fhir:v "http://example.org/fhir/Measure/CMS146|v123"^^xsd:anyURI ; \] ; #### References A [Reference](references#Reference) element is represented using the same rules as above: fhir:subject \[ # a fhir:Reference ; fhir:reference \[ fhir:v "Patient/example" \]; fhir:display \[ fhir:v "Example Patient" \]; \]; This allows faithful round tripping of the resource between the Turtle format and the JSON and XML formats. However, it's very useful for an RDF processor if the RDF graph links to the target of the reference directly. This can be represented using the OPTIONAL fhir:l property: fhir:subject \[ # a fhir:Reference ; **fhir:l ;** fhir:reference \[ fhir:v "Patient/example" \]; fhir:display \[ fhir:v "Example Patient" \]; \]; The correct value for the fhir:l relationship must be determined by resolving the [rules for resolving references](references), for the various reference types, to a literal URL that refers to the correct content in the local RDF context. Although the target type of the `fhir:reference` property is specified as xsd:string, it is [required to be an absolute or relative URI or fragment identifier,](references#literal) so it can always be used for a fhir:l link. The fhir:l relationship can be added automatically as part of generating the resource representation, or it can be injected by a post-processor that knows how to convert the raw references into RDF-suitable references. #### Inline Resources -- Bundled or contained Inline resources -- when a resource is contained directly in another element -- occur in the following places: - [Bundle.entry.resource](bundle-definitions#Bundle.entry.resource) - [DomainResource.contained](domainresource-definitions#DomainResource.contained) - [Parameters.parameter.resource](parameters-definitions#Parameters.parameter.resource) The following example (derived from [this example](bundle-references.ttl)) shows a [Bundle](bundle). The Bundle holds a list of `fhir:entry`s, each of which specifies a Resource that is a member of that Bundle. Although Turtle serializes each Resource separately, they are logically all part of the same Bundle. \# This is the parent Bundle resource: a fhir:Bundle ; fhir:nodeRole fhir:treeRoot ; fhir:id \[ fhir:v "bundle-references"\] ; fhir:type \[ fhir:v "collection"\] ; fhir:entry ( \[ fhir:fullUrl \[ fhir:l **** ; fhir:v "http://example.org/fhir/Patient/23"^^xsd:anyURI \] ; fhir:resource \] ) … # This is a member of the above Bundle: **** a fhir:Patient ; fhir:id \[ fhir:v "23"\] ; fhir:text \[ fhir:status \[ fhir:v "generated" \] ; fhir:div \[ fhir:v "…"^^rdf:XMLLiteral \] \] ; fhir:identifier ( \[ fhir:system \[ fhir:l ; fhir:v "http://example.org/ids"^^xsd:anyURI \] ; fhir:value \[ fhir:v "1234567" \] \] ) . Except for [transactions and batches](http#transaction), each entry in a Bundle [has a URI](bundle#bundle-unique) that is determined from its [fhir:fullUrl property](bundle-definitions#Bundle.entry.fullUrl) as described in [Resolving references in Bundles](bundle#references). Systems are responsible for [ensuring a unique mapping from fullUrl to Resource](bundle#bundle-unique), including in the case of multiple versions of a resource. When parsed into RDF, all URIs are absolute, e.g., `http://example.org/some/path.ext`. The Turtle syntax for RDF leverages the same [relative URL resolution](https://datatracker.ietf.org/doc/html/rfc3986#section-5.2) as HTML. The FHIR examples (available from the downloads page) and this document follow some conventions described below with the goal of - illustrating the process of relative URL resolution, - leveraging the uniqueness of the identifiers afforded by Web architecture, - presenting terse and readable examples. URLs are constructed from the fhir:id property if it is given in the example. These are presumed to be Resources in a server compliant with the FHIR REST API served from `http://example.org/`. Thusly, a `PlanDefinition` with id "KDN5" is assumed to have a URL of `http://example.org/PlanDefinition/KDN5`. If a [contained](domainresource-definitions#DomainResource.contained) resource has a fhir:id property, then its value MAY be used in generating a URI for that contained resource, following [rules for Contained Resources](references#contained). Local references (i.e., starting with "#") are relative to the parent (containing) resource. If the example does not include a containing Resource with an apparent URL, we will represent that resource's URI in Turtle as a relative URI. In the following example (derived from the [KDN5 example](plandefinition-example-kdn5-simplified.ttl)), the FHIR id is given ("KDN5") so we assume a base URL of `http://example.org/PlanDefinition/KDN5`. The contained resource (having fhir:id "1111") is given a URL relative to that base. As in HTML, a "#" character is prepended to the child's `fhir:id` when it is used as a local reference. Given the asssumed base, the contained `ActivityDefintion` and the `fhir:l` and `fhir:contained` properties which reference it could be written as `<#1111>` but they are resolved here to their absolute URI, `` for clarity: \# KDN5 is the parent resource in this example: a fhir:PlanDefinition ; # Known URI fhir:nodeRole fhir:treeRoot ; fhir:id \[ fhir:v "KDN5"\] ; # fhir:contained gives a list of resources that are logically contained # inside this (KDN5) resource, though Turtle serializes them separately: fhir:contained ( **** ) ; # assertion of containership fhir:action ( \[ fhir:textEquivalent \[ fhir:v "Gemcitabine 1250 mg/m² IV over 30 minutes on days 1 and 8" \] ; fhir:definition \[ a fhir:Canonical ; # Here the KDN5 parent references the contained resource: fhir:l **** ; # use of the contained Resource fhir:v "#1111"^^xsd:anyURI ; # Local reference starts with "#" \] \] ) ; … # The definition of the (logically) contained resource #1111 is here: **** a fhir:ActivityDefinition ; fhir:id \[ fhir:v "1111" \] ; # Local identifier fhir:status \[ fhir:v "draft" \] . … In contrast, in the following example, the parent does not have an id so we would need information to know how this Resource is uniquely addressed. In the absense of that information, we will simply express the contained Resource as a relative URL, `<#2222>`, with an unstated base. \# KDN5 is the parent resource in this example: <> a fhir:PlanDefinition ; # URI is relative to unspecified base URI fhir:nodeRole fhir:treeRoot ; # fhir:contained gives a list of resources that are logically contained # inside this (KDN5) resource, though Turtle serializes them separately: fhir:contained ( **<#2222>** ) ; # Relative URI fhir:action ( \[ fhir:textEquivalent \[ fhir:v "Gemcitabine 1250 mg/m² IV over 30 minutes on days 1 and 8" \] ; fhir:definition \[ a fhir:Canonical ; # Here the KDN5 parent references the contained resource: fhir:l **<#2222>** ; fhir:v "#2222"^^xsd:anyURI ; # Local reference starts with "#" \] \] ) ; … # The body of the (logically) contained resource 2222 is here, and receives # a URI derived from its parent's URI: **<#2222>** a fhir:ActivityDefinition ; fhir:id \[ fhir:v "2222" \] ; # Local identifier fhir:status \[ fhir:v "draft" \] . … #### Identifying Concepts in a Terminology The same logic applies to the [Coding](datatypes#Coding) data type. These are represented directly in Turtle by serializing their properties as above. However, for reasoners using the RDF graph, it's also useful to make the implicit concept references in these Codings explicit, by specifying an OPTIONAL _concept [IRI](https://www.rfc-editor.org/rfc/rfc3987)_ in an rdf:type assertion, written using shorthand **`a`** in Turtle: fhir:code \[ fhir:coding ( \[ **a loinc:29463-7**; # OPTIONAL, but RECOMMENDED fhir:system \[ fhir:v "http://loinc.org" \]; fhir:code \[ fhir:v "29463-7" \]; fhir:display \[ fhir:v "Body Weight" \] \] \[ **a sct:27113001**; # OPTIONAL, but RECOMMENDED fhir:system \[ fhir:v "http://snomed.info/sct" \]; fhir:code \[ fhir:v "27113001" \]; fhir:display \[ fhir:v "Body weight" \] \] ) \]; #### Concept IRIs and IRI Stems A concept [IRI](https://www.rfc-editor.org/rfc/rfc3987) uniquely identifies a concept that would otherwise be identified by a <`Coding.system, Coding.code`\> pair. A concept IRI normally has two parts -- an IRI stem and a code -- though concept IRIs that do not follow this pattern can be used. An _IRI stem_ is the initial substring of the concept IRIs that correspond to all codes in a particular Code System or terminology. The concept IRI is formed by concatenating the IRI stem with the code (after percent-encoding any reserved characters -- see [Appendix 1: Algorithm for Creating a Concept IRI](#concept-iri-algorithm) for details). The IRI stem is typically used to define an IRI prefix in Turtle and SPARQL, such as `loinc:` or `sct:` in the above example. This approach allows the Compact URI `loinc:29463-7` (in Turtle or SPARQL) to be easily translated into the concept IRI `http://loinc.org/rdf/29463-7` by concatenating the IRI stem `http://loinc.org/rdf/` with the code `29463-7`. This particular IRI stem is defined in the [LOINC User Guide S12.7.2](https://loinc.org/kb/users-guide/recommendations-for-best-practices-in-using-and-mapping-to-loinc/#using-a-uri-to-identify-loinc-concepts-as-resources-in-rdf). [Compact URIs ("CURIEs")](https://www.w3.org/TR/curie/) provide a mechanism for abbreviating IRIs using a prefix and a reference, separated by a colon, such as `loinc:29463-7`. Although some RDF systems have treated CURIEs directly as FHIR Codes -- i.e., including the "loinc:" prefix as part of the code -- non-prefixed FHIR codes like `29463-7` are strongly preferred because they align better with the use of IRI stems described herein. If the "loinc:" prefix were treated as part of the FHIR code, like `loinc:29463-7`, then when the IRI stem is prepended the resulting absolute IRI would become `http://loinc.org/rdf/loinc:29463-7`, which in this example would be incorrect for the intended LOINC concept. One might wonder why the `Coding.system` is not used directly as the IRI stem for a given terminology. One reason is that `Coding.system`s often lack a convenient separator character as their final character, such as "/" or "#", which could cause problems if they were directly concatenated with codes, leading to erroneous concept IRIs such as `http://loinc.org35217-9`. But the main reason is that the `Coding.system` and the IRI stem of some terminologies were chosen independently and differ in unpredictable ways. Hence, there is no simple formula for determining the correct IRI stem from a `Coding.system`. To address this problem, and to facilitate ease of use, HL7 maintains a mapping from `Coding.system`s to IRI stems: IRI stems can be registered and looked up in the [HL7 Terminology (THO) website](https://terminology.hl7.org/), based on the desired `Coding.system`. To look up the correct IRI stem for a given terminology, such as LOINC: 1. navigate to the [Table of Contents](https://terminology.hl7.org/toc.html); 2. search within the page for an appropriate link that includes "NamingSystem" in its URL, such as this one, for LOINC: [https://terminology.hl7.org/NamingSystem-v3-loinc.html](https://terminology.hl7.org/NamingSystem-v3-loinc.html) ; then 3. scroll down to the [Identifiers section](https://terminology.hl7.org/NamingSystem-v3-loinc.html#identifiers), and look for the "IRI stem" entry: `http://loinc.org/rdf/` . If an IRI stem for a `Coding.system` is published at [https://terminology.hl7.org/](https://terminology.hl7.org/) it SHOULD be used. An NPM package is also available to efficiently automate lookup of IRI stems from `Coding.system`s. To add an IRI stem to that site, see [Appendix 2: Registering an IRI Stem on the HL7 Terminology Website](#registering-iri-stems). #### Non-modifier Extensions A Resource might have any number of non-modifier extensions, represented as an RDF list like this: a fhir:Observation; fhir:nodeRole fhir:treeRoot; **fhir:extension (** \[ fhir:url \[ fhir:l ; fhir:v "http://example.org/fhir/StructureDefinition/observation-bodyPosition"^^xsd:anyURI \] ; fhir:value \[ fhir:coding ( a sct:33586001; fhir:system \[ fhir:l ; fhir:v "http://snomed.info/sct"^^xsd:anyURI \]; fhir:code \[ fhir:v "33586001" \]; fhir:display \[ fhir:v "Sitting position (finding)" \] ) \] \] \[ fhir:url \[ fhir:l ; fhir:v "http://example.org/fhir/StructureDefinition/observation-delta"^^xsd:anyURI \] ; fhir:value \[ fhir:coding ( a sct:1250004; fhir:system \[ fhir:l ; fhir:v "http://snomed.info/sct"^^xsd:anyURI \]; fhir:code \[ fhir:v "1250004" \]; fhir:display \[ fhir:v "Decreased (qualifier value)" \] ) \] \] **)** … A primitive element such as `fhir:birthDate` can have a list of extensions attached like this: … fhir:birthDate \[ fhir:v "2016-05-18"^^xsd:date ; **fhir:extension (** \[ fhir:url \[ fhir:l ; fhir:v "http://hl7.org/fhir/StructureDefinition/patient-birthTime"^^xsd:anyURI \] ; fhir:value \[ a fhir:DateTime ; fhir:v "2016-05-18T10:28:45Z"^^xsd:dateTime \] \] **)** \] See [Extensibility](extensibility) for additional guidance on FHIR extensibility. #### Modifier Extensions FHIR allows `modifierExtension`s on [DomainResources](domainresource#DomainResource), [BackboneElements](types#BackboneElement) and [BackboneTypes](types#BackboneType). The type of any DomainResource with any `modifierExtension` is prefixed with '\_' in RDF. The '\_' prefix helps prevent FHIR RDF processors that do not understand a particular modifier extension from blindly processing it as though it still had the original semantics.  The structure of the element is otherwise unchanged. Note the underscore at the beginning of "\_MedicationRequest" in the following example: a **fhir:\_MedicationRequest;** fhir:nodeRole fhir:treeRoot; fhir:extension ( ... ); \# above bodyPosition and delta extensions **fhir:modifierExtension** ( \[ fhir:url \[ fhir:l ; fhir:v "http://example.org/fhir/StructureDefinition/anti-prescription"^^xsd:anyURI \] ; fhir:value \[ a fhir:Boolean ; fhir:v true \] \] ) … The [FHIR ontology](#owl-shex-rim) includes a `fhir:modifierExtensionClass` property that relates each unmodified resource class to its corresponding modified resource class, so that SPARQL queries can easily find all modified classes without having to parse their URIs to look for the leading underscore: fhir:MedicationRequest **fhir:modifierExtensionClass** fhir:\_MedicationRequest . BackboneElements and BackboneTypes are object types. Any RDF property that references a modified BackboneElement or BackboneType is prefixed with a '\_'. Note the underscore at the beginning of "\_value" in the following example: a fhir:Observation; … fhir:**\_value** \[ a fhir:Quantity; fhir:value \[ fhir:v "185"^^xsd:decimal \]; fhir:unit \[ fhir:v "lbs" \]; fhir:system \[ fhir:l ; fhir:v "http://unitsofmeasure.org"^^xsd:anyURI \]; fhir:code \[ fhir:v "\[lb\_av\]" \]; **fhir:modifierExtension** ( \[ fhir:url \[ fhir:l ; fhir:v "http://example.org/fhir/StructureDefinition/anti-observation"^^xsd:anyURI \] ; fhir:value \[ a fhir:Boolean ; fhir:v true \] \] ) ; \] The [FHIR ontology](#owl-shex-rim) also includes a `fhir:modifierExtensionProperty` property that relates each unmodified property to its corresponding modified property: fhir:value **fhir:modifierExtensionProperty** fhir:\_value . See [Modifier Extensions](extensibility#modifierExtension) for additional requirements around modifier extensions. ### ShEx Schema and FHIR RDF, W5 and HL7 v3 RIM Ontologies To facilitate FHIR RDF creation and processing, the following additional artifacts are available from the [downloads page](downloads). While the [fhir.hl7.org site](https://fhir.hl7.org/fhir/downloads.html) holds the official released versions of these artifacts, unreleased INFORMATIVE versions may also be available from the [build.fhir.org site](https://build.fhir.org/downloads.html). - ShEx schema fhir.shex (NORMATIVE). This schema is intended to help users validate FHIR RDF data. It is normative in the sense that if some purported FHIR RDF data is inconsistent with the ShEx schema, then that data is known to be invalid. However, consistency with the ShEx schema does not guarantee that the data is fully valid, because there are additional semantic requirements of FHIR data that are not captured in the ShEx schema. Although the logical meaning of the ShEx schema is normative, the _expression_ of that meaning is **INFORMATIVE** (i.e., not normative): it MAY be changed or enhanced at any time. For example, the schema MAY be refactored, or shape names that only appear in the ShEx MAY change. - OWL Ontology [fhir.ttl](fhir.rdf.ttl.zip) (NORMATIVE). This describes the classes and properties that are used to represent FHIR RDF data. It is normative in the sense that if an OWL reasoner finds some purported FHIR RDF data to be logically inconsistent with the ontology, then that data is known to be invalid, i.e., not conforming to the FHIR specification. However, consistency with the ontology does not guarantee that the data is fully valid, because there are many requirements of FHIR data that are not captured in the ontology. Although the logical meaning of the OWL ontology is normative, its _expression_ in OWL/Turtle is **INFORMATIVE** (i.e., not normative): it MAY be changed or enhanced at any time. For example, it MAY be refactored, or class or property names that only appear in the ontology MAY change. - W5 Ontology [w5.ttl](fhir.rdf.ttl.zip) (INFORMATIVE). This ontology attempts to capture relationships expressed in the [Five Ws Mappings](fivews) (formerly called W5 Report) -- Who, What, When, Where, Why. It has not been well vetted, and MAY be changed at any time. - v3 RIM ontology [rim.ttl](fhir.rdf.ttl.zip) (INFORMATIVE). This ontology attempts to capture semantic relationships between [HL7 v3 RIM](https://dev3.hl7.org/implement/standards/product_brief.cfm?product_id=77) and FHIR. It has not been well vetted, and may be changed at any time. ### Usage Guidance for OWL and ShEx **Informative** 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: - [HAPI java reference library](https://hapifhir.io/) - [Delphi reference implementation](http://github.com/grahamegrieve/fhirserver) - The [FHIR RDF Playground](https://fhircat.github.io/fhir-rdf-playground/) is a handy browser-based tool for experimenting with conversion of FHIR JSON to FHIR RDF. It is not for production use. Check the [HL7 Open Source FHIR Implementations page](https://confluence.hl7.org/display/FHIR/Open+Source+Implementations), in case new implementations have become available. 2. [Download](downloads) the FHIR ontology, fhir.ttl . 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](http://owl.cs.manchester.ac.uk/research/snomed/).) 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](http://shex.io/). You can [download the ShEx schema](fhir.shex) for FHIR RDF. **OWL Caveat:** RDF lists use a ladder of rdf:first and rdf:rest properties. This can cause problems in OWL DL, which disallows axioms over the rdf: namespace. To work around this problem, OWL users can convert RDF lists in their FHIR data to a different list representation. A [script](https://github.com/w3c/hcls-fhir-rdf/tree/gh-pages/scripts/owl-safe-lists) is available for doing such a conversion. ### Relationship Between RDF, FHIR, and Other Ontologies **Informative** This page documents an RDF format that can be used to exchange FHIR data, on the basis that RDF is a universal information representation. Using RDF enables FHIR data to be used with other RDF data and RDF-aware applications to support inference, shared semantics across multiple standards and data formats, data integration, semantic data validation, compliance enforcement, SPARQL queries and other uses. Implementers using FHIR in this fashion are advised to be aware of the relationship between FHIR's RDF format and other uses of ontologies. FHIR's RDF format is based on the same abstract information model as the [XML](xml) and [JSON](json) formats and carries the same information content. Resources are losslessly round-trippable between XML, JSON and RDF formats and data expressed in the RDF format corresponds closely to the XML and JSON formats in its look and feel, though a few additional FHIR-specific terms appear in the RDF format, as explained above: `fhir:nodeRole`, `fhir:treeRoot` and `fhir:v`. In addition to defining the RDF format, this specification provides [an associated ontology](downloads) containing formal definitions of the classes and properties that appear in the RDF format. 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, impedance 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 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, users are advised to avoid directly interpreting FHIR RDF as stating facts. Transformations may be needed to remove or isolate non-monotonic elements and reconcile the records across time and perspective. Application developers are also advised to 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 is not clinically relevant. ### Tutorials **Informative** [Slides by Eric Prud'hommeaux](https://www.w3.org/2016/Talks/1205-swat4ls-egp/reasoning) 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](https://www.nlm.nih.gov/healthit/snomedct/international.html). _Caveat: These slides were based on an earlier version of FHIR, so some specifics may have changed._ A [webinar by Harold Solbrig](https://yosemiteproject.org/fhir-rdf-as-a-bridge-to-the-semantic-web-in-healthcare/) shows how FHIR RDF data can be used with the [SNOMED-CT ontology](https://www.nlm.nih.gov/healthit/snomedct/international.html) to recognize a cancer diagnosis.  An [associated tutorial](https://yosemiteproject.org/tutorial-fhir-rdf-as-a-bridge-to-the-semantic-web-in-healthcare/) details the steps used.  _Caveat: This webinar and tutorial were based on a previous version of FHIR RDF, so some specifics may have changed. _ ### Appendix 1: Algorithm for Creating a Concept IRI _For background on concept IRIs, IRI stems, and their relationship to Code Systems, see [Concept IRIs and IRI Stems](#iri-stem) above._ This section defines a standard algorithm for generating a Concept IRI from a <`Coding.system`, `Coding.code`\> pair.  In many cases it involves merely concatenating the associated IRI Stem with the `Coding.code`.  But because a `Coding.code` could contain reserved characters that are used to delineate different parts of the IRI, percent-encoding of reserved characters is required, as defined below. Given: - a FHIR `Coding.system`, _s_, that identifies a terminology _t_; and - a `Coding.code`, _c_, that is defined within _t_; a Concept IRI, _conceptIRI_, corresponding to _s_ and _c_ is computed as follows: 1. If no IRI Stem is defined for _s_ in the [HL7 Terminology website](https://terminology.hl7.org/), then _conceptIRI_ is undefined. Halt. 2. Let _iStem_ be an IRI Stem that is defined for _s_ in the HL7 Terminology website.  3. As a special case, if _iStem_ equals `urn:ietf:rfc:3987`, then _conceptIRI_ is _c_, and _c_ MUST be a syntactically valid absolute-IRI as defined by [RFC 3987](https://datatracker.ietf.org/doc/html/rfc3987).  Halt.  (Informative comments: The purpose of this special case is to permit `System.code`s that are already IRIs to be used directly as Concept IRIs, without any transformation. Note that an absolute-IRI may also be a URL or a URN.) 4. Let _cSafe_ be the IRI-safe version of _c_, as defined by the algorithm in [section 7.3 of R2RML: RDB to RDF Mapping Language (W3C Recommendation 27 September 2012)](https://www.w3.org/TR/2012/REC-r2rml-20120927/#from-template), quoted here for convenience (informative): > _The **IRI-safe version** of a string is obtained by applying the following transformation to any character that is not in the [iunreserved production](http://tools.ietf.org/html/rfc3987#section-2.2) in \[RFC3987\]:_ > > > _1\. Convert the character to a sequence of one or more octets using UTF-8 \[RFC3629\]__2\. [Percent-encode](http://tools.ietf.org/html/rfc3986#section-2.1) each octet \[RFC3986\]_ The iunreserved production defined in [RFC 3987, section 2.2](https://datatracker.ietf.org/doc/html/rfc3987#section-2.2) using [ABNF](https://datatracker.ietf.org/doc/html/rfc2234) is also quoted here for convenience (informative): > `iunreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar` The ucschar production defined in [RFC 3987, section 2.2](https://datatracker.ietf.org/doc/html/rfc3987#section-2.2) is also quoted here for convenience (informative).  (Informative comment: The ucschar production defines international character ranges that are valid Unicode characters within the intersection of path components (ipath), query strings (iquery) and fragment identifiers (ifragment).  They do not include any reserved characters involved in parsing apart the various components of an IRI.) > `ucschar        = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF`` `                  `/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD`` `                  `/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD`` `                  `/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD`` `                  `/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD`` `                  `/ %xD0000-DFFFD / %xE1000-EFFFD` 5. _conceptIRI_ is the result of concatenating _iStem_ and _cSafe._ Halt. Some real and hypothetical examples are shown in the following table. | `**Coding.system**` | **IRI Stem** | `**Coding.code**` | **Concept IRI** | | --- | --- | --- | --- | | ICD 10:` ``http://hl7.org/fhir/sid/icd-10` | `http://purl.bioontology.org/ontology/ICD10/` | `G44.1` | `http://purl.bioontology.org/ontology/ICD10/G44.1`  | | SNOMED CT:\*` ``http://snomed.info/sct` | `http://snomed.info/id/` | `128045006` | `http://snomed.info/id/128045006` | | MeSH: `https://www.nlm.nih.gov/mesh` | `https://id.nlm.nih.gov/mesh/` | `D000305` | `https://id.nlm.nih.gov/mesh/D000305` | | LOINC: `http://loinc.org` | `https://loinc.org/rdf/` | `35217-9` | `https://loinc.org/rdf/35217-9` | | Example coding system that uses a Unicode smiling face character (U+263A) as a code:` ``http://example.org/` | `http://example.org/` | `☺` | `http://example.org/☺` | | Example coding system that uses a Unicode waving hand character (U+1F44B) from the [Miscellaneous Symbols and Pictographs](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Miscellaneous_Symbols_and_Pictographs&sa=D&source=editors&ust=1661857750967890&usg=AOvVaw3NF72CBQp0L6mXw4Z2Uolw) [block](https://www.google.com/url?q=https://en.wikipedia.org/wiki/Miscellaneous_Symbols_and_Pictographs&sa=D&source=editors&ust=1661857750968211&usg=AOvVaw0jUA8uygpG7xOCF5gdRbUq), combined with the medium-dark skin tone (U+1F3FE):` ``http://example.org/` | `http://example.org/` | `👋🏾` | `http://example.org/👋🏾`  | \*As of this writing (5-Sep-2022) it is not clear what IRI stem is most appropriate when writing a SNOMED CT post-coordinated code expression. ### Appendix 2: Registering an IRI Stem on the HL7 Terminology Website This section is intended for those who are helping to add or maintain IRI stem registrations at the [HL7 Terminology website](https://terminology.hl7.org/). IRI stems have not been standardized for all FHIR `Coding.system`s. But any that have been standardized SHOULD be registered in the HL7 terminology website by adding appropriate CodeSystem and NamingSystem entries, using the system "urn:ietf:rfc:3987" and [identifier type](valueset-identifier-type) of "iri-stem". You can see an example of this in the HL7 description of the [LOINC CodeSystem](https://terminology.hl7.org/CodeSystem-v3-loinc.json.html) and the [LOINC NamingSystem](https://terminology.hl7.org/NamingSystem-v3-loinc.html). Assuming that the `Coding.system` for your desired IRI stem has already been registered, the process for registering an IRI stem for it includes: 1. Select the most authoritative, community-supported IRI stem available for this Coding.system. The IRI stem SHOULD be taken from an official publication of the organization that publishes the terminology (such as the LOINC User Guide mentioned above). If no such IRI stem is defined by the organization, and the organization fails to define or endorse one even after repeated requests, and the organization appears unlikely to define one in the foreseeable future, then a community-defined IRI stem MAY be registered. In this case, it SHOULD be an IRI stem most commonly used by the community as recorded by several RDF IRI stem repositories, such as [Bioregistry](https://bioregistry.io/), [prefix.cc](https://prefix.cc/), [OBO Foundry](https://obofoundry.org/) or Wikidata (by means of [wdt:P1921](https://www.wikidata.org/wiki/Property:P1921)). 2. The IRI stem MUST be in the form of an IRI as defined by the [IRI production in RFC 3987](http://tools.ietf.org/html/rfc3987#section-2.2). This means that the IRI stem MUST start with a "scheme:" string, such as "http:", "https:", "urn:" or any other valid scheme, followed by an authority, followed by any number of path parts and an OPTIONAL query and fragment. Examples of valid IRI stems include: - `doi:10.1111/` - `urn:loinc.org:`     _← Note the trailing colon (":")_ - `http://loinc.org/rdf/` - `http://purl.obolibrary.org/obo/HP_`     _← Note the trailing underscore ("\_")_ - `https://example.org/terminologies/?action=search&id=` - `ftp://user@example.org:2222/loinc/` 3. The IRI stem MUST be intended to be used by concatenating it with a FHIR code as described in the [Appendix 1: Algorithm for creating a Concept IRI"](#concept-iri-algorithm). Therefore, care must be taken to ensure that the code can be concatenated to the IRI stem without altering the IRI stem's meaning, including: 1. The IRI stem SHOULD end with a delimiter character (one of the `gen-delims` or `sub-delims` productions from [section 2.2 of RFC 3987](https://datatracker.ietf.org/doc/html/rfc3987#section-2.2) or one of the characters "-", ".", "\_" or "~") . An IRI stem that ends with an alphanumeric character is likely to have the meaning of the final term altered when the code is concatenated. For example, an IRI stem of "http://example.org" when concatenated with the code "39" will result in a concept IRI of "http://example.org39", which is probably not the concept IRI intended. 2. Since FHIR codes are percent-encoded before being concatenated with the IRI stem, it is unlikely that it will alter the meaning of the IRI stem. However, note that the characters \`-\`, \`.\`, \`\_\`, \`~\` will NOT be percent encoded. Thus, if the IRI stem is \`http://hospital.org\`, a code of \`.attacker.com\` could be used to generate a concept IRI of \`http://hospital.org.attacker.com\`, which if resolved as a URL could provide information to an unexpected server name. 4. On the HL7 Terminology website ([https://terminology.hl7.org](https://terminology.hl7.org)), add the IRI stem to the NamingSystem and CodeSystem records corresponding to the desired Coding.system, by following the [process for submitting a UTG change proposal](https://confluence.hl7.org/display/VMAH/How+To+Submit+a+UTG+Change+Proposal). The IRI stem SHOULD be added to both the NamingSystem and the CodeSystem. Additions, deletions and modifications of an IRI stem to an existing NamingSystem or CodeSystem will generally be considered a minor change under the [UTG Versioning policy](https://confluence.hl7.org/display/VOC/Documented+Execution+of+UTG+Versioning). As of this writing (17-Dec-2022), the change proposal process for doing this included the following steps. However, since the process may have later changed, readers are advised to [verify it](https://confluence.hl7.org/display/VMAH/How+To+Submit+a+UTG+Change+Proposal) prior to proceeding. You can also see an example of such a change proposal, including the associated changes in the XML files, in the [MeSH IRI stem change proposal](https://jira.hl7.org/browse/UP-377). 1. Record the IRI stem in a CodeSystem by adding an identifier with: - system: urn:ietf:rfc:3987 - type: Coding with system=http://terminology.hl7.org/CodeSystem/v2-0203 and code="IRISTEM" - value: _\[the IRI stem\]_ - period: _\[OPTIONAL: the period during which this IRI stem was in use\]_ - assigner: - display: _\[documentation of the provenance of the IRI stem\]_ 2. Record the IRI stem in a NamingSystem by adding a uniqueId with: - type: iri-stem - value: _\[the IRI stem\]_ - period: _\[OPTIONAL: the period during which this IRI stem was in use\]_ - comment: _\[documentation of the provenance of the IRI stem\]_ - preferred: _false \[since an IRI stem is unlikely to also be the primary identifier\]_ - authoritative: _\[true if this IRI stem is officially recognized by the NamingSystem authority, false if this IRI stem is generally used in the RDF community but is not officially designated as such\]_ 5. If the current process for registering an IRI stem differs from the above steps, please: 1. [Search the Jira issue tracker](https://jira.hl7.org/issues/?jql=text%20~%20%22Registering%20an%20IRI%20Stem%20(RDF%20Subgroup)%22) for an issue titled "Registering an IRI Stem (RDF Subgroup)". 2. If no such issue is found, [file an issue](https://jira.hl7.org/secure/CreateIssue!default.jspa) with that title, describing how to improve the above steps. \[%file newfooter%\]