Difference between revisions of "FHIR Ontology Requirements"
Line 14: | Line 14: | ||
=== 4. Monotonic with Modifier Exensions === | === 4. Monotonic with Modifier Exensions === | ||
+ | '''REVISIT THIS''' | ||
'''(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: [[ | : Was: [[ | ||
Line 21: | Line 22: | ||
=== 5. Vocabulary Bindings === | === 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 === | === 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. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
=== 7. Annotation Information === | === 7. Annotation Information === | ||
− | '''(SHOULD | + | '''(SHOULD?)''' In the RDFS/OWL, should expose at least minimal annotation information for display in an ontology editor. |
: ''QUESTION: Please clarify: What kinds of annotation information do you have in mind?'' | : ''QUESTION: Please clarify: What kinds of annotation information do you have in mind?'' | ||
Revision as of 16:53, 13 January 2015
DRAFT
Contents
- 1 Requirements
- 1.1 1. FHIR Instance Mappings
- 1.2 2. FHIR Ontology Mappings
- 1.3 3. Complete FHIR Coverage
- 1.4 4. Monotonic with Modifier Exensions
- 1.5 5. Vocabulary Bindings
- 1.6 6. Enforce Constraints
- 1.7 7. Annotation Information
- 1.8 8. User Friendly
- 1.9 9. Datatype IRIs
- 1.10 10. Articulate Value
- 1.11 11. Enable Inference
- 1.12 12. Common Model
- 1.13 13. Valid Against Schemas and Profiles
- 1.14 14. RDF Quality
- 2 USE CASES
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 resource XML/JSON instances to FHIR RDF instance data and vice versa. 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
REVISIT THIS (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?
- Syntax needs to be "safe" when dealing with 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, should expose at least minimal annotation information for display in an ontology editor.
- QUESTION: Please clarify: What kinds of annotation information do you have in mind?
8. User Friendly
RDF/OWL expressions should be (business, clinical) user friendly and understandable.
- (DBooth) I don't think this is achievable. I don't think clinicians or business people should have to look at RDF or OWL.
- (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
To support inference it would help if datatypes (date, dateTime, value, etc.) were 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?
- (MT) Here we need to stick on primary data types as complexes data type are hard to handle. Also we have to keep in mind that OWL cannot handle all data types. The solution would be to de-compose the complexes datatypes into native ones and use them in pieces of patterns /models
10. Articulate Value
Clearly articulate the value of the new RDF/RDFS/OWL representation over the current XML/JSON representation
- 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"
- (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
Enablement of OWL/RDFS inference – so we could identify use cases that cannot be easily done based on the XML/JSON representation
- QUESTION: What kinds of inference do you have in mind?
- ANSWER: See some of the use cases below
12. Common Model
A common OWL/RDFS representation for information model elements and medical terminology concepts.
- (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
Transformations into FHIR must validate against Schemas and Profile
- (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
Transformations into RDF must meet software quality checks including closure.
- 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.
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)