This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Ontology Requirements"

From HL7Wiki
Jump to navigation Jump to search
 
(59 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
<div style="background-color: white; border: 1px solid red; margin: 4px; padding: 2px; font-weight: bold; text-align: center; color:red">
 +
This page is OBSOLETE. RDF Work has moved [https://confluence.hl7.org/pages/viewpage.action?pageId=66922543 Here]</div>
 +
 +
 +
 
'''DRAFT'''
 
'''DRAFT'''
 +
 +
== Desiderata ==
 +
How FHIR profiles are approached, designed, constrained, or extended should be based on a formal logical model. That model should be explicit and be developed prior to the profiles that result from it. Without such a model to operate from, FHIR will lack the semantic and structural consistency required to make FHIR computable.
  
 
== Requirements ==
 
== Requirements ==
 
Priorities are indicated using [https://en.wikipedia.org/wiki/MoSCoW_method MoSCoW] terms (MUST, SHOULD, COULD, WON'T).
 
Priorities are indicated using [https://en.wikipedia.org/wiki/MoSCoW_method MoSCoW] terms (MUST, SHOULD, COULD, WON'T).
  
−
=== 1.  FHIR Instance Mappings and Ontology ===
+
=== 1.  FHIR Instance Mappings ===
−
'''(MUST?)''' We must define mappings from FHIR XML/JSON to FHIR RDF instance data and vice versa, and an OWL/RDFS ontology for the structure and semantics of that RDF instance data.
+
'''(MUST)''' We must define lossless bi-drectional transformations from FHIR XML/JSON resource instances to FHIR RDF resource instances and vice versa.  FHIR RDF resource instance data that is transformed into FHIR XML resource instance data must validate against schemas and declared profiles.  This round-tripping must not be dependent on any information other than the definition of FHIR resources and data types.  (I.e. round-tripping must not be dependent on FHIR profiles, vocabulary definitions or other external information.)
−
: LM: I'd go stronger than mappings.  I think we want bi-directional transforms.  And the structure and semantics must come from Profile resource instances.  We can't have any structure or semantics that isn't defined in a Profile (though we can define extensions for Profile if there's additional semantics or structure we want to represent).
 
−
: Was: [[
 
−
:: We want to be able to represent instances as RDF and Profiles and schemas as OWL/RDFS
 
−
::
 
−
:: * LM: My leaning is to drop "schemas" from this.  Schemas are derived from profiles and schemas only exist for the root resources, whereas profiles will exist for all sorts of things that profiles won't.
 
−
: ]]
 
  
−
=== 2. Complete FHIR Coverage ===
+
=== 2. FHIR Ontology Mappings ===
−
'''(MUST?)''' The RDF representation of FHIR instance data must be capable of expressing all legal FHIR instances that make use of any valid FHIR profiles.  An RDF instance data representation that is limited to only a subset of possible FHIR instances is not acceptable.
+
'''(MUST)''' We must define lossless bi-directional transformations from FHIR Profile instances (XML/JSON/RDF) to OWL/RDFS ontology representations and vice versa
−
: Was: [[
 
−
:: The RDF and RDFS/OWL expressions must be capable of expressing all legal FHIR instances and profiles.  I.e. A syntax which is limited to only a subset of possible instances is not acceptable
 
−
: ]]
 
  
−
=== 3. Round Tripping ===
+
=== 3. Complete FHIR Coverage ===
−
'''(MUST)''' It must be possible to round-trip instance data from XML/JSON through the RDF representation.  This means that FHIR instance data in RDF, in combination with the FHIR ontology and any referenced FHIR Profiles, must capture all of the standard semantics of the corresponding FHIR XML or JSON data that are independent of the choice of serialization.
+
'''(MUST)''' The RDF representation of FHIR resource instance data must be capable of expressing all legal FHIR instances that make use of any valid FHIR profiles, including extensions.  An RDF instance data representation that is limited to only a subset of possible FHIR instances is not acceptable.
−
* LM: The instance, by itself (without any FHIR ontology or supplemental files) must be able to round-trip.  I.e. It must not be necessary to have access to any profiles, vocabulary definitions or any other information (other than the base resource definitions) to round trip.
 
−
* This includes retaining information about order of repeating elements
 
−
: ''QUESTION: Is the order of repeating elements semantically significant in FHIR? I.e., would it affect or use of the interpretation of the information?''
 
−
:: ''ANSWER''(LM): Yes.  Or more specifically, it's allowed to be.  Order of medications in a list, order of names, etc. is required to be retained and, depending on the definition of the element, can have meaning.  As well, retaining order is essential to allow digital signature validation after round-tripping
 
−
* This needs to allow for extensions wherever they can appear, including simple types (date, boolean, etc.)
 
  
 
=== 4. Monotonic with Modifier Exensions ===
 
=== 4. Monotonic with Modifier Exensions ===
−
'''(MUST?)''' FHIR RDF data with modifier extensions must be "safe" for RDF reasoning, i.e., the semantics of the RDF must be monotonic even in the presence of modifier extensions.
+
'''(MUST)''' FHIR RDF data with modifier extensions must be "safe" for RDF reasoning, i.e., the semantics of the RDF must be monotonic even in the presence of modifier extensions.
−
: Was: [[
 
−
:: Syntax needs to be "safe" when dealing with modifier extensions
 
−
::: ''QUESTION: What is meant by "syntax"?  RDF has several serializations.  What syntax do you mean?''
 
−
: ]]
 
  
 
=== 5. Vocabulary Bindings ===
 
=== 5. Vocabulary Bindings ===
−
'''(SHOULD?)''' The FHIR ontology must support vocabulary bindings to code, Coding and CodeableConcept - including dealing with extensible value sets and multi-code system value sets.
+
'''(MUST)''' The FHIR ontology must support vocabulary bindings to code, Coding and CodeableConcept - including dealing with extensible value sets and multi-code system value sets.
−
: Was: [[
+
 
−
:: OWL representation must support vocabulary bindings to code, Coding and CodeableConcept - including dealing with extensible value sets and multi-code system value sets.
+
'''(SHOULD)''' The FHIR vocabulary representation should be able to leverage existing semantic web terminology representations (e.g. SNOMED-CT)
−
::: ''QUESTION: I've reworded this to say "RDF and/or OWL representations" instead of "Syntax".  Was this a correct interpretation?  If not, what was meant by "Syntax"?''
 
−
:: (LM) I'd say this is a SHALL.  And changed it to just OWL.  Instances won't declare vocabulary bindings
 
−
: ''QUESTION: I've reworded this to say "RDF and/or OWL representations" instead of "Syntax".  Was this a correct interpretation?  If not, what was meant by "Syntax"?''
 
−
:: (LM) I'd say this is a SHALL. And changed it to just OWL. Instances won't declare vocabulary bindings
 
−
: ]]
 
  
 
=== 6. Enforce Constraints ===
 
=== 6. Enforce Constraints ===
−
'''(SHOULD?)''' The FHIR ontology should enforce constraints that are representable in OWL/RDF whenever possible, e.g. schema constraints, regular expressions, etc.
+
'''(SHOULD)''' The FHIR ontology should enforce constraints that are representable in OWL/RDF whenever possible, e.g. schema constraints, regular expressions, etc.
−
: ''QUESTION: Does this mean that the RDF and/or OWL representations should take advantage of available native RDF or OWL ways of expressing constraints??''
 
−
:: ''ANSWER:'' Yes
 
−
: Was: [[
 
−
:: Syntax should enforce constraints that are representable in RDF (e.g. schema constraints, regular expressions, etc.)
 
−
: ]]
 
  
 
=== 7. Annotation Information ===
 
=== 7. Annotation Information ===
−
'''(SHOULD?  COULD?)''' In the RDFS/OWL, should expose at least minimal annotation information for display.
+
'''(SHOULD)''' In the RDFS/OWL Ontology representation, should expose at least minimal annotation information for display in an ontology editor for use by humans
−
: ''QUESTION: Please clarify: What kinds of annotation information do you have in mind?''
 
  
−
=== 8. User Friendly ===
+
=== <strike>8. User Friendly</strike> ===
−
RDF/OWL expressions should be (business, clinical) user friendly and understandable.
+
<strike>RDF/OWL expressions should be (business, clinical) user friendly and understandable.</strike>  <br>
−
: (DBooth) I don't think this is achievable.  I don't think clinicians or business people should have to look at RDF or OWL.
+
''(This was felt to be unachievable.)''
−
:: (LM) Agree.  OWL/RDF is for inference, not consumption.  The standard XML or JSON will almost certainly be more human readable than the RDF
 
  
 
=== 9. Datatype IRIs ===
 
=== 9. Datatype IRIs ===
−
To support inference it would help if datatypes (date, dateTime, value, etc.) were represented as IRIs (xsd) rather than as string literals.  
+
'''(SHOULD)''' To support inference, datatypes (date, dateTime, value, etc.) should be represented as IRIs (xsd) rather than as string literals.
−
: ''QUESTION: Some of the types (e.g. date) are the union of multiple xsd types (xs:date, xs:gYearMonth, xs:gYear).  Can OWL/RDFS handle that?''
 
  
−
=== 10. Articulate Value ===
+
=== <strike>10. Articulate Value</strike> ===
−
Clearly articulate the value of the new RDF/RDFS/OWL representation over the current XML/JSON representation
+
<strike>Clearly articulate the value of the new RDF/RDFS/OWL representation over the current XML/JSON representation</strike>
−
* Objective here isn't "you should do RDF/etc. instead of JSON/XML", but rather "these are the circumstances in which RDF/etc. would provide value-add"
+
<br>''(This will be a separate goal of the group, rather than a FHIR ontology requirement.)''
−
:: ''(DBooth) This seems like a helpful thing to do, but it does not sound like a requirement of the FHIR ontology itself.''
 
−
:: ''(LM) Agree''
 
  
 
=== 11. Enable Inference ===
 
=== 11. Enable Inference ===
−
Enablement of OWL/RDFS inference – so we could identify use cases that cannot be easily done based on the XML/JSON representation
+
'''(MUST)''' The FHIR ontology must support inference on FHIR instance data, both in use cases based on the open world assumption and in use cases based on the closed world assumption.
−
: ''QUESTION: What kinds of inference do you have in mind?''
 
−
:: ''ANSWER:'' See some of the use cases below
 
  
−
=== 12. Common Model ===
+
=== <strike>12. Common Model</strike> ===
−
A common OWL/RDFS representation for information model elements and medical terminology concepts.
+
<strike>Create a common OWL/RDFS representation for information model elements and medical terminology concepts.</strike>  <br>''(This may be pursued as a separate project of the group.)''
−
* (LM)I'm not sure what this means.  I think the scope of this project is limited solely to FHIR models and value sets?
 
  
−
=== 13. Valid Against Schemas and Profiles ===
+
=== <strike>13. Valid Against Schemas and Profiles</strike> ===
−
Transformations into FHIR must validate against Schemas and Profile
+
''(Merged into #1.)''
−
* (LM) Not sure what this means  The RDF syntax will *be* FHIR - it won't be a translation into FHIR.  It'll just be one of the permitted syntaxes.  If this means that data that is converted from RDF into the other syntaxes needs to be valid, I think that's covered by #3 (Round tripping).
 
−
* (DBooth) I think this is covered by #3 (round tripping).
 
  
 
=== 14. RDF Quality ===
 
=== 14. RDF Quality ===
−
Transformations into RDF must meet software quality checks including closure.  
+
'''(MUST)''' Transformations into RDF must meet software quality checks including ontological closure. The RDF instance which is transformed from FHIR XML or FHIR JSON must be capable of being opened without further modification by widely available tools including Protégé and the RDF must meet quality checks including successful closure of graphs - all the links are understood by the tool.
−
: ''QUESTION: What kinds of quality checks?  What is meant by "closure"?''
+
 
−
* (TM) The RDF instance which is transformed from FHIR must me capable of being opened without further modification by widely available tools including Protégé and the RDF must meet quality checks including successful closure of graphs - all the links are understood by the tool.
+
=== 15. Auto Generated ===
 +
'''(MUST)''' The FHIR ontology and FHIR RDF instance data mappings should be auto-generatable from the FHIR specification.
 +
 
 +
=== <strike>16. Profiles from OWL</strike> ===
 +
<strike>'''(MAY)''' We may find a way to transform OWL/RDF ontologies into FHIR profiles.</strike><br>''(Subsumed by #2)''
  
 
== USE CASES ==
 
== USE CASES ==

Latest revision as of 20:27, 15 July 2021

This page is OBSOLETE. RDF Work has moved Here


DRAFT

Desiderata

How FHIR profiles are approached, designed, constrained, or extended should be based on a formal logical model. That model should be explicit and be developed prior to the profiles that result from it. Without such a model to operate from, FHIR will lack the semantic and structural consistency required to make FHIR computable.

Requirements

Priorities are indicated using MoSCoW terms (MUST, SHOULD, COULD, WON'T).

1. FHIR Instance Mappings

(MUST) We must define lossless bi-drectional transformations from FHIR XML/JSON resource instances to FHIR RDF resource instances and vice versa. FHIR RDF resource instance data that is transformed into FHIR XML resource instance data must validate against schemas and declared profiles. This round-tripping must not be dependent on any information other than the definition of FHIR resources and data types. (I.e. round-tripping must not be dependent on FHIR profiles, vocabulary definitions or other external information.)

2. FHIR Ontology Mappings

(MUST) We must define lossless bi-directional transformations from FHIR Profile instances (XML/JSON/RDF) to OWL/RDFS ontology representations and vice versa

3. Complete FHIR Coverage

(MUST) The RDF representation of FHIR resource instance data must be capable of expressing all legal FHIR instances that make use of any valid FHIR profiles, including extensions. An RDF instance data representation that is limited to only a subset of possible FHIR instances is not acceptable.

4. Monotonic with Modifier Exensions

(MUST) FHIR RDF data with modifier extensions must be "safe" for RDF reasoning, i.e., the semantics of the RDF must be monotonic even in the presence of modifier extensions.

5. Vocabulary Bindings

(MUST) The FHIR ontology must support vocabulary bindings to code, Coding and CodeableConcept - including dealing with extensible value sets and multi-code system value sets.

(SHOULD) The FHIR vocabulary representation should be able to leverage existing semantic web terminology representations (e.g. SNOMED-CT)

6. Enforce Constraints

(SHOULD) The FHIR ontology should enforce constraints that are representable in OWL/RDF whenever possible, e.g. schema constraints, regular expressions, etc.

7. Annotation Information

(SHOULD) In the RDFS/OWL Ontology representation, should expose at least minimal annotation information for display in an ontology editor for use by humans

8. User Friendly

RDF/OWL expressions should be (business, clinical) user friendly and understandable.
(This was felt to be unachievable.)

9. Datatype IRIs

(SHOULD) To support inference, datatypes (date, dateTime, value, etc.) should be represented as IRIs (xsd) rather than as string literals.

10. Articulate Value

Clearly articulate the value of the new RDF/RDFS/OWL representation over the current XML/JSON representation
(This will be a separate goal of the group, rather than a FHIR ontology requirement.)

11. Enable Inference

(MUST) The FHIR ontology must support inference on FHIR instance data, both in use cases based on the open world assumption and in use cases based on the closed world assumption.

12. Common Model

Create a common OWL/RDFS representation for information model elements and medical terminology concepts.
(This may be pursued as a separate project of the group.)

13. Valid Against Schemas and Profiles

(Merged into #1.)

14. RDF Quality

(MUST) Transformations into RDF must meet software quality checks including ontological closure. The RDF instance which is transformed from FHIR XML or FHIR JSON must be capable of being opened without further modification by widely available tools including Protégé and the RDF must meet quality checks including successful closure of graphs - all the links are understood by the tool.

15. Auto Generated

(MUST) The FHIR ontology and FHIR RDF instance data mappings should be auto-generatable from the FHIR specification.

16. Profiles from OWL

(MAY) We may find a way to transform OWL/RDF ontologies into FHIR profiles.
(Subsumed by #2)

USE CASES

Real world use cases that require and demonstrate the value of an RDF/OWL representation - TBD

  • Identify (through extension profile properties) inheritance relationships to abstract concepts and properties that hold across resources. E.g. "All orders", "All interventions", "All medications"
  • Allow easy testing of subsumption relationships between profiles - "Profile A is a proper constraint on Profile B"
  • Allow validation of mappings between FHIR elements and RIM, v2 and other models to:
    • Ensure that mapped to elements and paths actually exist
    • Allow identification of overlapping or unclear semantics in FHIR (as well as poorly expressed/imprecise mappings)
  • Allow FHIR-based data to be linked to other RDF data and queried via technologies such as SPARQL
  • Provide a recommended syntax for persisting FHIR data as triple-stores, allowing reasoning capabilities to be exercised (e.g. subsumption testing of codes when querying)
Retrieved from "https://wiki.hl7.org/w/index.php?title=FHIR_Ontology_Requirements&oldid=167563"