FHIR Ontology Requirements

DRAFT

1. It must be possible to round-trip instance data from XML/JSON through RDF representation

• 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

• Needs to allow for extensions where-ever they can appear, including simple types (date, boolean, etc.)

2. 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.

3. 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.

4. Syntax must support vocabulary bindings to code, Coding and CodeableConcept - including dealing with extensible value sets and multi-code system value sets

5. Syntax should enforce constraints that are representable in RDF (e.g. schema constraints, regular expressions, etc.)

6. In the RDFS/OWL, should expose at least minimal annotation information for display

7. 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?

8. 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"

9. Enablement of OWL/RDFS inference – so we could identify use cases that cannot be easily done based on the XML/JSON representation

10. 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?

11. The FHIR ontology must capture all of the standard semantics of FHIR XML and JSON data that are independent of the choice of serialization. (This is closely related to #1.)

• Is there anything this statement adds that isn't implicit in #1?

12. RDF/OWL expressions should be (business, clinical) user friendly and understandable

13. 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 #1

14. Transformations into RDF must meet software quality checks including closure.

15. 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

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)