CIMI WGM Agenda September 2016
Return to Clinical_Information_Modeling_Initiative_Work_Group main page
- 1 Agenda
- 2 Minutes
- 2.1 Friday
- 2.2 Sunday Q3
- 2.3 Sunday Q4
- 2.4 Monday Lunch
- 2.5 Monday Q3
- 2.6 Monday Q4: Semantic alignment with terminology model binding
- 2.7 Tuesday Q1 Skin model proof of concept
- 2.8 Tuesday Q2
- 2.9 Tuesday Lunch
- 2.10 Tuesday Q3
- 2.11 Tuesday Q4 Negation with Patient Care
- 2.12 Wednesday Q1
- 2.13 Wednesday Q2
- 2.14 Wednesday Q3
- 2.15 Wednesday Q4
- 2.16 Thursday Q1
- 2.17 Thursday Q3
Prework session > how to map adl to FHIR profiles > solor implications > composition > boundary between adl and cql > condition & observation > common foundation for CDS knowledge artifacts
|Q3||Composition of archetypes: review the proposed compositional approach for Clinical Statement design with two use cases, Procedure and Condition. We will discuss how to model context (mode) and topic and review some examples which include the context 'Not done'.||Claude|
|Q4||Administration & planning|
|lunch||Baltimore||Report out from Friday. Alignment with FHIR - how to generate a profile from an archetype. How to communicate semantic bindings for instances. Discuss possible approaches to go from CIMI Archetypes to FHIR profiles including via the use of logical profiles.||Galen||Jay|
Prepare for CIMI FHIR profile governance - leverage across groups.Start drafting a list of asks for FHIR.
|Q4||Baltimore||"Semantic alignment with terminology model binding, sources, impedance, impact on composition"||Jay||Galen|
|AM||Q1||Constellation D||@ Patient Care, skin breakdown proof-of-concept: composition patterns for archetypes that conform to SCT concept model||Patient Care||(PC) Jay (Susan, Harold)|
|Q2||Baltimore||CIMI & FHIM; Steve & Nona on PSS for CIMI/FHIR/FHIM/SOLOR/CQI||Galen||Jay|
|PM||lunch||Constellation Ballroom D
||CIMI meeting with FHIR Core Team;
Strategy of using FHIR structure definitions to represent CIMI modelsCorrespondence between SNOMED templates and FHIR profiles / FHIR terminology bindings
|Q3||Baltimore||Continue working session from MQ3||Claude||Richard|
|Q4||Constellation D||@ Patient Care: Negation. Information requirements, design desiderata, design patterns. Review of draft report.||Jay|
|AM||Q1||Constellation F||@ CQI (including DAF): Discuss how a number of current initatives such as CQF and DAF can align at the logical model level and how corresponding DAF and QICore profiles are to be generated from the CIMI logical model.||CQI|
|Q2||Columbia or CIC Guest 403||@ CIC. How to engage specialty societies. (& possibly registries)||CIC||Stan|
|PM||Q3||Columbia||Reference Model: review the proposed reference model changes, foundational archetypes defined off the reference model, and discuss pros and cons of the proposed approach.||Claude||Jay|
|Q4||Constellation F||@ CDS (including DAF)||CDS|
|AM||Q1||Guest room 320||Conditions & Observations: review a proposed approach for modeling Condition and Observation that takes into account how these resources are structured, partitioned, bound to the corresponding SNOMED CT model, and how negation can be expressed through a statement's context.||Stan||Galen|
|PM||Q3||Guest room 320||@ Vocabulary. How to coordinate CIMI bindings with SNOMED releases (realm, year)||Vocabulary|
Attending: Claude Nanjo, Galen Mulrooney, Ioana Singureanu, Oyvind Aassve, Jay Lyle, Susan Matney, Linda Bird, Steve Hufnagel, Nona Hall, Kurt Allen, Richard Esmond, Bruce Bray, Chris Herzog
- Multiple inheritance is a problem. The compositional approach supports reuse without multiple inheritance.
- Compositional patterns may be exposed by programmers as interfaces.
- The interface approach also supports capturing serial modes (one procedure planned, ordered, executed)
- Cardinality: Is a procedure proposal and a proposal completed one statement or two?
- How complex should a clinical statement be?
- “Procedure Proposal Entry” as a smaller object than a “procedure proposal document”
- This pattern is for indivisible entries.
- “Topic” may have not just code but strength and site etc.
- Topic is closer to model of meaning; statement to information model
- Flattening of patterns (e.g., transforming ProcedurePlanned.planned.plannedDate into ProcedurePlanned. plannedDate) allows access to compositional properties without complex paths
- Context and association semantics are defined on relationships between Statement class and compositional parts, but they are repeated within components so that they will be visible when flattened.
- Might we need both procedure context and finding context in a single model? E.g. lab result with status of complete?
- Perhaps a specific lab result modality with additional procedure metadata.
- Absence is hard. How to distinguish between absent and probably absent. Need use cases for queries; or perhaps use SCT boundaries.
- Updates to schedule
- Brief overview of SOLOR design direction
- Brief overview of IHTSDO recommendations for CIMI extension dependencies
Monday Q4: Semantic alignment with terminology model binding
- where appropriate to the SCT concept model (e.g., finding site, finding interprets observable), CIMI elements to be bound to SCT attributes
- Example slide for observable, finding, situation structure.
- Situation model supports consistent representation of modifiers
- Similar for procedure
- Not to include unbound "unapproved" attributes
- example compositional patterns for harmonization here
- CIMI elements bound to sct observables &/or LOINC codes where not appropriate to the SCT concept model
- Do we need some other kind of semantic framework for these elements?
- Relationships among code systems (SNOMED CT, LOINC, RxNorm or other drug system)
- SOLOR concept & design
- Operational implications for semantic binding
- syntax for models, for specifications, for instances
- maintenance: resources, governance
- services (population, validation, inference)
- SCT attributes agreed previously
- SCT observables for attributes not in concept model agreed
- LOINC values also agreed; semantic binding need not be unique
- However, we cannot use the "is-a" relationship to assert that the root node of an archetype is a finding, e.g. "Is-a" is for concepts (classes), not individuals.
- The association of the root node with a semantic code will not have a SNOMED CT model binding, but will be a convention agreed to as part of the CIMI design.
- Examples have duplicated LOINC codes; one for the root node and one for the "code" attribute.
- It is anticipated that the "code" attribute is an element that will appear in instances.
- It may be more specific than the root element, and it may have a value set of options.
- The root element may be SNOMED rather than LOINC.
- Whether it should be carried in instances is up to the implementation specification. CIMI will specify it.
- This is also true for contained classes, recursively.
Tuesday Q1 Skin model proof of concept
See agenda and minutes under Patient Care
- Nona Hall & Steve Hufnagel presented slides summarizing the results of the investigative project and proposing a PSS for a pilot project
- It's clear that this project will not guide FHIR, a specification already under development. However, it may align with FHIR specifications, provide semantic underpinnings for existing resources & profiles, and provide a semantically coordinated path forward.
- Various approaches discussed for coping with medications. RxNorm is convenient; substance content could be provided as extension or donated to international edition; brands may need to be published in national extensions.
- Pilot projects considered (see slides)
Linda Bird presented slides outlining a proposed approach to binding FHIR properties to SNOMED CT
Tuesday Q4 Negation with Patient Care
See Agenda & Minutes at Care_Tuesday_Q4 Patient Care
Attending: Richard Esmond, Patrick Langford, Steve Hufnagel, Galen Mulrooney, John Kilbourne, Jay Lyle, Abdul-Malik Shakir, Claude Nanjo, Harold Solbrig, Stan Huff
- CIMI Reference model
- How to modify FHIM (UML) to support coordination with CIMI. Convert to ADL?
- Note: AML is a profile on UML; i.e., a subset. If FHIM is UML, AML won’t add anything. It does hide some complexity. (Analogous situation with BMM & ADL).
- Current model provides a meta-model for construction of classes, which makes it abstract and stable, but which makes implemented models extremely heavy in terms of modeling overhead. Address, e.g., becomes dozens of classes.
- Proposal: remove metamodel classes (item, item group) from RM and add domain classes (observation, etc.).
- The result: all classes and properties would be in the RM; ADL can only constrain things present in the RM.
- An argument for not doing this is support of iso-semantic operations. (terminology conversions are different: we need an example of a structural iso-semantic operation that would be easier in the abstract scenario, and how to handle it in the more concrete scenario.)
- Tangent: FHIM may be equivalent to BMM but not identical. Concrete relationships among artifacts are not clear right now, but we do agree that DRY (don’t repeat yourself) is a pretty good architectural principle.
- (Tagging is discussed.)
- Note: openEHR is making a similar change.
- Three open questions
- Section & entry patterns are very similar, structurally. Distinction: sections have no proper data; entries may. Can we confirm or clarify the distinction and rational and add to the requirements page? (http://wiki.hl7.org/index.php?title=CIMI_RM_Requirements)
- Iso-semantic conversions are relatively clear for terminology operations. We need examples of structural iso-semantic patterns, and how equivalence could be asserted.
- It seems that the “archetypes only constrain” is further encouragement to disaggregate properties. E.g., it’s clear that Height is not a RM element; the element is *Observation, and the “Height” semantics are asserted as a constraint. But other properties may also follow this pattern; e.g., the instrument with which height was measured might be an observation property, or it might be another observation. The new pattern encourages the latter.
- We find this to be a promising approach and authorize dev of examples to ensure it works at which point we will vote on whether it becomes our direction.
- Motion: Stan; Second: Richard
- Motion carries 8-0-0