These binding patterns are extracted from Linda Bird's presentation from the 2017 Bratislava face-to-face meeting.
- Note that binding patterns can be applied to all or a selection of information model elements, e.g. in the examples below the patterns apply to the code and bodySite information model elements, but not e.g. to clinicalStatus or severity. This is a design decision for each resource.
- Note that cardinality of value of information model is not considered. E.g. if code has two finding sites and there are multiple bodySite values?
Meaning provided solely by SNOMED CT (where SNOMED CT is applicable)
Option 1
The meaning of the resource instance is provided by using SNOMED CT only in areas covered by SNOMED CT.
Disallow conflicting representations by disallowing use of information model elements, i.e. cardinality 0..0.
Example:
Impact: would require post-coordination or likely extensive local, national, or international pre-coordination.
Meaning is provided by a mutually constrained combination of multiple SNOMED CT encoded information model elements
Impact: all these options would require software implementing run-time constraint checking between multiple information model elements
Option 2
Allow use of information model element only if there is no "corresponding" (how?) SNOMED CT attribute in a concept definition of a concept used as a value in another information model element.
Example: bodySite = 28231008 |Gallbladder| is allowed only because the definition of 363346000 |Cancer| does not contain the SNOMED CT attribute 363698007 | Finding site (attribute) | AND the information model element bodySite is considered corresponding to the SNOMED CT attribute 363698007 | Finding site (attribute) |.
Option 3
Allow use of information model element only if the case above (Option 2) is fulfilled OR if the attribute formed by the "corresponding" SNOMED CT attribute and the information model element value refines (is subsumed by) a SNOMED CT attribute in a concept definition of a concept used as a value in another information model element.
Example: bodySite = 71341001 | Femur | is allowed because there is a element-attribute correspondance (bodySite - 363698007 | Finding site (attribute) |) and 363698007 | Finding site (attribute) | = 71341001 | Femur | is subsumed by 363698007 |Finding site| = 272673000 |Bone structure (body structure)|.
Option 4
Don't know how to interpret this pattern. Is "<" vs "<<" the only difference?
Option 5
This pattern does e.g. not allow concepts which are primitive children of concepts with non-IsA relationships and thus seems overly restrictive.
Option X+
There are other options for guaranteeing consistency between multiple SNOMED CT-valued information model elements, and hence interoperability:
- the value of one information model element, if it does not exist, is assigned by extracting a value from a SNOMED CT attribute from a concept which is a value of another information model element.
- the value of one information model element, if it does not exist, is assigned or asserted to be equal to or subsumed by an expression which is a templated combination of multiple other information model elemetn values, .
Meaning is provided by a mutually unconstrained combination of multiple SNOMED CT encoded information model elements
Option 6
An expansion of "Option 6" which we might call Use SNOMED atomically, fully populating the information model is proposed here (modified from an email from Jim Case)
The main stumbling block we hit in attempting to recommend approaches to binding is around attempting to accommodate historical anomalies. Starting with a blank slate and attempting to move forward would facilitate progress.
FHIR/HL7 has gone to great lengths to define what they think is the appropriate level of abstraction and granularity for each of the resources. In many instances, there is overlap with the semantics of the SNOMED CT concept model. SNOMED CT also provides a broad range of granularity. Can we propose:
- In resources where the elements overlap semantically with the SNOMED concept model, the appropriate SNOMED range for that element will be used as the value.
- In all elements where SNOMED is used, the most atomic concepts that fulfil the value range will be used.
- SNOMED concepts pre-coordinated with additional qualifiers may be used in elements where the FHIR resource does not provide sufficient granularity to represent the needed semantics.
- SNOMED concepts used as values for FHIR elements should NOT have defined characteristics that overlap with other elements within the resource.
- SNOMED concepts in one element of a resource SHALL NOT contradict a value in another element of a resource.
- SNOMED concepts used to value an element SHALL NOT repeat the context of the element definition
In essence, we should leverage the information model supplied to us. How to convert old data to that format is a separate issue that should not block this project.