Difference between revisions of "FHIR Ontology Requirements"
Vipulkashyap (talk | contribs) |
|||
| Line 7: | Line 7: | ||
* Needs to allow for extensions where-ever they can appear, including simple types (date, boolean, etc.) | * 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 as OWL/RDFS | + | 2. We want to be able to represent instances as RDF and Profiles and schemas as OWL/RDFS |
3. Syntax needs to be "safe" when dealing with modifier extensions | 3. Syntax needs to be "safe" when dealing with modifier extensions | ||
Revision as of 16:51, 16 December 2014
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
3. 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?
4. Syntax should 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.
8. Clearly articulate the value of the new RDF/RDFS/OWL representation over the current XML/JSON representation
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.
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.)
12. RDF/OWL expressions should be (business, clinical) user friendly and understandable
USE CASES
Real world use cases that require and demonstrate the value of an RDF/OWL representation - TBD
