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.
Impact: would require post-coordination or likely extensive local, national, or international pre-coordination.
Impact: all these options would require software implementing run-time constraint checking between multiple information model elements
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) |.
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)|.
Don't know how to interpret this pattern. Is "<" vs "<<" the only difference?
This pattern does e.g. not allow concepts which are primitive children of concepts with non-IsA relationships and thus seems overly restrictive.
There are other options for guaranteeing consistency between multiple SNOMED CT-valued information model elements, and hence interoperability:
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 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.