This wiki has undergone a migration to Confluence found Here

CIMI WGM Agenda September 2016

From HL7Wiki
Jump to navigation Jump to search

Return to Clinical_Information_Modeling_Initiative_Work_Group main page


Day Time   Room Event Host Joining Chair Scribe

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

September 18
AM Q1    
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  
Day Time   Room Event Host Joining Chair Scribe
September 19
AM Q1 Plenary
Q2 Plenary      
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
PM Q3 TBD Working session

Prepare for CIMI FHIR profile governance - leverage across groups.

Start drafting a list of asks for FHIR.
Galen Harold
Q4 Baltimore "Semantic alignment with terminology model binding, sources, impedance, impact on composition" Jay Galen
Day Time   Room Event Host Joining Chair Scribe
September 20
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 models

Correspondence between SNOMED templates and FHIR profiles / FHIR terminology bindings
Linda Jay
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  
Day Time   Room Event Host Joining Chair Scribe
September 21
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
Day Time   Room Event Host Joining Chair Scribe
September 22
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  
Q4   NOT MEETING        
Day Time   Room Event Host Joining Chair Scribe
May 13
Q2   NOT MEETING        
PM Q3   NOT MEETING        
Q4   NOT MEETING        



Sunday Q3

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.

Sunday Q4

  • Updates to schedule
  • Brief overview of SOLOR design direction
  • Brief overview of IHTSDO recommendations for CIMI extension dependencies

Monday Lunch

Monday Q3

Monday Q4: Semantic alignment with terminology model binding


  1. where appropriate to the SCT concept model (e.g., finding site, finding interprets observable), CIMI elements to be bound to SCT attributes
    1. Example slide for observable, finding, situation structure.
    2. Situation model supports consistent representation of modifiers
    3. Similar for procedure
    4. Not to include unbound "unapproved" attributes
    5. example compositional patterns for harmonization here
  2. CIMI elements bound to sct observables &/or LOINC codes where not appropriate to the SCT concept model
    1. Do we need some other kind of semantic framework for these elements?
  3. Relationships among code systems (SNOMED CT, LOINC, RxNorm or other drug system)
    1. SOLOR concept & design
  4. Operational implications for semantic binding
    1. syntax for models, for specifications, for instances
    2. strength
    3. maintenance: resources, governance
    4. services (population, validation, inference)


  1. SCT attributes agreed previously
  2. SCT observables for attributes not in concept model agreed
  3. LOINC values also agreed; semantic binding need not be unique
  4. 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.
    1. 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.
  5. Examples have duplicated LOINC codes; one for the root node and one for the "code" attribute.
    1. It is anticipated that the "code" attribute is an element that will appear in instances.
    2. It may be more specific than the root element, and it may have a value set of options.
    3. The root element may be SNOMED rather than LOINC.
    4. Whether it should be carried in instances is up to the implementation specification. CIMI will specify it.
    5. This is also true for contained classes, recursively.

Tuesday Q1 Skin model proof of concept

See agenda and minutes under Patient Care

Tuesday Q2


  • 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)

Tuesday Lunch

Linda Bird presented slides outlining a proposed approach to binding FHIR properties to SNOMED CT

Tuesday Q3

Tuesday Q4 Negation with Patient Care

See Agenda & Minutes at Care_Tuesday_Q4 Patient Care

Wednesday Q1

Wednesday Q2

Wednesday Q3

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? (
    • 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.
  • Motion
    • 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

Wednesday Q4

Thursday Q1

Thursday Q3