HL 7 FHIR Concept Map Resource Evaluation June

HL 7 FHIR Concept Map Resource Evaluation June – August 2018

Concept Map Resource Evaluation • June – August 2018 • Small team met to discuss specific Concept Map Tracker items • • Rob Hausam Jay Lyle Carmela Couderc Michael Lawley • Trackers • • • 14209 16364 16367 16372 16782

• June 13, 2018 – Concept Map Project Kick Off • Define Concept. Map intended • Original: equivalence mappings only, across code systems • across code systems or within a single code system was not clearly stated • Define Concept. Map semantic scope • Current: equivalence relations only • Equivalence and nulls (not mapped) and negatives (disjoint) • Others that some have assumed: • Relationships of any kind (especially with the addition of related to – Cologne May 2018) • Aggregation • Clarify Code System Supplement governance • Concept Ma p does not have the same governance rules as those documented for Code System Supplement

Conclusion - Recommendation • Concept. Map resource supports all relationships with a single property • Equivalence occupy a separate branch of the semantic hierarchy; e. g. , one “broader” node cannot subsume both semantic and compositional breadth. • Clearly distinguish the relationship code system concepts between semantic and compositional relationships. • Example: County – State relationship = compositional relationship • DM – DM II relationship = semantic relationship

Conclusion - Recommendation • Use a single resource for both equivalence and other maps; clarify • Rewrite equivalence property name, definition • Relationship type, relationship, relation • Check resource definition, boundaries • Maintain datatype = code/required binding • Support other use cases w/extensions • Document use-cases to evaluate Value Set, definitions

Conclusion - Recommendation • Use a single resource for both equivalence and other maps • Change Equivalence Value Set name to: concept-map-relation(ship) • Clean up value set concepts • • • remove duplicates clearly define each concept redefine value set if no clear use case for a relationship type, don’t add it Keep the value set relatively clean and concise

Conclusion - Recommendation • Use a single resource for both equivalence and other maps • Remove values of equal, specializes and subsumes • The direction metaphor in the text is confusing. Wider means target wider than source. • Existing text: “Mappings are one way – from the source to the target system. ” • Propose new text “Mappings are one way, identifying targets for sources” • Fix the unmatched hierarchy and rename to nomatch. • Clear guidance and examples required • Complicated nuances • Merits clear guidance in the resource documentation • Include guidance regarding whether a relationship can be used transitively.

Relation Type Code System • Code Systems considered • • ISO SKOS SNOMED CT Existing FHIR Value Set

Relationship Type Notes • Relationship semantics may be specific to the use case. • Maps are use-case-specific, • Don't need to automate distinctions among closely related relationship kinds. • Disambiguation in set notation (e. g. , "A ⋂ B ≠ ∅ ") is probably not feasible at this level. • Automated distinction desirable within the set of concepts used in a given map • Requires a standard list of values, even if their meanings may vary, slightly, across cases. • Value Set should be lean and mean to avoid adding confusion.

Relationship Type Notes • Gnarly example • Meaning of "broader“ • semantic, category, composition, or some other flavor of breadth can be left to the use case; • Must be distinct from other values (e. g. , 'equal', 'disjoint’). • Suggest a category relationship type concept • Alternatively: semantic and compositional can be collapsed • Clear guidance and examples required • Complicated nuances • Merits clear guidance in the resource documentation • Guidance to include whether a relationship can be used transitively.

Concept Map Relationship Type Use Cases • Translate clinical data in one specification (e. g. , FHIR criticality 'low') to another, • need to find semantically equivalent code (e. g. , V 3/C-CDA 'CRITL'). • equivalent • Or semantically valid code, even if not equivalent • equivalent, broader • Identify incorrect maps (http: //build. fhir. org/conceptmap-example. html) • equivalent, disjoint • Identify unmatched values (for performance, for clarity) (http: //build. fhir. org/conceptmap-example-specimen-type. html) • equivalent, unmatched

Concept Map Relationship Type Use Cases • Map a clinical code to a classification • For analysis • SCT to ICD for analysis, abstract values permitted (http: //build. fhir. org/conceptmap. html 4. 9. 1) • Classify surgical codes locally for a report (open/closed, simple/complex, anatomical structure) • category/broader • category/ broader, no match? • For billing • SCT to ICD for billing, leaf levels only (http: //build. fhir. org/conceptmap. html 4. 9. 1) • category/ broader

Concept Map Relationship Type Use Cases • Identify counties in a state or kinds of places in a place kind (is this a real use case? http: //build. fhir. org/v 3/Address. Part. Type/cs. html) • aggregate? • Identify possible matches for human review • [inexact used by ML: https: //chat. fhir. org/#narrow/stream/48 terminology/subject/Concept. Map/near/155445] • inexact/close/some. Overlap

Concept Map Relationship Type Use Cases • Clarify purpose of use case for narrower: http: //build. fhir. org/conceptmap-103. html] • narrower; others? • A map that depends on some other property: http: //build. fhir. org/conceptmap-example-2. html • need concrete example; possibly SCT/ICD. Possible curly braces problem. • Map between elements in two structure definitions (http: //build. fhir. org/conceptmap. html 4. 9. 7) • would seem to be of equivalence; no examples provided

Concept Map Relationship Type Use Cases • Map between a code system and a medication resource (http: //build. fhir. org/conceptmap. html 4. 9. 7) • would seem to support a system of reference information; no examples provided • Narrower: laterality and severity for human factor • Device codes mapped to LOINC – generate value set of LOINC codes • Some maps can be reversed (if so need to specify translations) • Used in reverse, not generated

Code System Supplement and Concept Map • Problem/Issue: • Is it clear to implementers how to address Code System Supplements? • Some have assumed that Concept Map is an appropriate resource to use. • Options for Guidance: • Option 1: • Code System Supplements are for relationships within a system; • Maps are for relationships across systems. • Option 2: • Code System Supplements are for relationships asserted by the code system steward, with system definition authority; • Concept Maps are for relationships asserted by others.

Code System Supplement vs: Concept Map • Options for Guidance - Discussion: • Option 2: • Code System Supplements are for relationships asserted by the code system steward, with system definition authority; • Not necessarily • Some have assumed that Code System supplements may be created by someone other than the steward/owner • Some have assumed that Code System supplements may be cross-Code System

Code System Supplement vs: Concept Map • Options for Guidance - Discussion: • what, if any, is the functional result of the distinction? Does either case require some feature that the other doesn’t? • The Concept Map Boundary documentation must be updated to provide guidance