CIMI Telecom Minutes 2017-02-02

• WIKI URL: http://wiki.hl7.org/index.php?title=Clinical_Information_Modeling_Initiative_Work_Group
• Wiki Objective: maintain and communicate current information with CIMI members, partners and stakeholders.
• CIMI Co-chairs: Stan Huff, Linda Bird, Galen Mulrooney, Richard Esmond
• WIKI Curator: Stephen.Hufnagel.HL7@gmail.com
• CIMI Telecoms: Thursdays at 3PM EST (4PM EDT), https://global.gotomeeting.com/join/754419973 US Dial-in 224-501-3316, Code: 754-419-973
• HL7 List server: CIMI@lists.HL7.org; where, you must be subscribed to the CIMI@lists.hl7.org list server to use it.
• REQUESTED ACTION: Edit this WIKI page or send your feedback to CIMI@lists.HL7.org with your comments, questions, suggested updates.
• Screen Sharing & Telecom Information
  • https://global.gotomeeting.com/join/754419973 Dialin: United States : +1 (224) 501-3316 Access Code: 754-419-973
  • More phone numbers
  • Australia : +61 2 8355 1034
  • Belgium : +32 (0) 28 93 7002
  • Canada : +1 (647) 497-9372
  • Denmark : +45 89 88 03 61
  • Netherlands : +31 (0) 208 084 055
  • New Zealand : +64 4 974 7243
  • Spain : +34 932 20 0506
  • Sweden : +46 (0) 853 527 818
  • United Kingdom : +44 (0) 330 221 0098

Attendees

Linda Bird, Joey Coyle, Richard Esmond, Bret Heale, Stan Huff, Steve Hufnagel, Patrick Langford, Jay Lyle, Susan Matney, Chris Melo, Galen Mulrooney, Claude Nanjo, Craig Parker, Serafina Versaggi

Minutes (Annotated Agenda)

• Scribe: Stan.Huff@imail.org
• REQUESTED ACTION: Update wiki directly or send suggested changes to scribe or cimi@lists.hl7.org
• Bolded Items were discussed/annotated to the agenda

• Record this call
• Agenda review
• Updates on active projects (standing item)
  • Skin and wound assessments – Jay and Susan
    • Naming of coded attributes in subtypes; for example fracture location as a specialization of body location
    • Will try to have all the content specified in the next two weeks.

***** STYLE DECISION VOTE *****

• "When the item is only different from the parent because of a different value set binding, the name would be the same in the parent and the child. In the constraint of attributes in the subtypes (in ADL) more specific names can be created as desired. In the situation where the subtype attributes might have been created by slicing, the attributes would just be made as independent elements in the subtype, there would not be a common attribute in the parent."
• Moved by Claude, 2nd Richard. Abstain: 3, Opposed 1, Affirm 11 (This is a straw man to move forward with and get some experience, we can revisit or soften this rule if we run into trouble.)

• FHIM – CIMI integration – Galen
  • Phase 1: FHIM Participations to CIMI Attributions Provenance refactoring is complete
  • Phase 2: Patient refactoring - Context and Domain split to be discussed at tomorrows FHIM meeting
    • Need to discuss FHIM Promise and Order types that exist in the FHIM vs CIMI
    • Also the question of shared meta data in panels/batteries vs individual attribution of observation.
    • How to handle Dependent Observations (e.g., segments of a questionnaire)
    • How to handle Dependent Observations (e.g., segments of a questionnaire)
  • Phase 3: Topic-context refactoring (separation of UML-structure/ clinical classes and terminology) planned for rest of February

• Changes to the model (presented under Annotated Figures Section) – Claude
  • New abstract finding
  • Added goal
  • Added risk
  • Added promise

***** WE STOPPED HERE --> REMAING TIME SPENT ON CLAUDE'S CHANGES DISCUSSED IN THE NEXT SECTION*****

• Projects:
  • Conclusions from the CIMI FHIM Task Force – Stan Huff
    • Stan will update the document based on previous discussion, and bring the document back for review and approval in a few weeks (still not done)
  • Conversion of CIMI archetypes to FHIR logical models to FHIR profiles – Claude
  • LOKI – Patrick is still working
  • BMM parsing and serialization code – Claude
    • Making good progress on serialization – deserialization
    • Some questions to Thomas Beale
  • Creating ADL models from CEMs – Joey
    • First recreate CEMs from BMM and ADL files
    • Second – CEMs to BMM and ADL files
  • Propose some subtypes of the assertion model – Stan and Susan (pending)
  • Graph/STAMP modeling paradigm
    • Richard has scheduled meetings
    • Richard has sent out a first draft proposal
• Review plans for May ballot
  • For the May 2017 Ballot Cycle, the next deadline is the Notification of Intent to Ballot Form deadline on Sunday, February 19th
    • Galen will do it with Jay’s help, Richard will watch
  • Work plan
    • 3/26 pub date
      • 3/1 full content draft
      • 3/10 content done
      • 3/14 docs done: to Patrick for editing
  • Ballot content (top priorities)
    • Modeling. #1 priority. [Claude, Galen]
      • BMM: Reference model including pilot content
      • ADL: top level archetypes including pilot content
      • FHIM generation: #4 priority [Galen]
      • Skin Wound Assessment: content is #1 [Jay, Susan]
        • Expression #1 [Jay]
        • Quality measure #2 [Claude, Ken]
        • US Core / QI Core / CIMI Archetype integration #1 [Claude]
      • Claude and Galen will meet and make a prioritized list and figure out how far they can reach down the list
      • Skin and wound – plans are in place
      • Quality measure – Jay and Claude to meet tomorrow, then reach out to Ken Kawamoto and Floyd Eisenberg
    • Documentation [Patrick, Editor]
      • Documents created and edited on Google Docs, and then published to the wiki
      • Overview/marketing pitch [Stan, Jay, Claude, Steve, Nona, Ask Laura]
      • Practitioners' Guide, for clinicians, Analysts and non-CIMI SMEs. [Steve, Nona] (May be combined with the style guide listed below.)
      • Updated and fleshed out style guide [Susan, Jay, Steve]
      • Architecture guide [Claude]
      • Refine CIMI Process Definition for CIC #3 [Steve, Claude, Jay, Galen]
      • (Help to create documentation) Tool that reads a model and generates wiki pages (a document generation tool) [Michael, Claude]
      • Tool that takes the BMM patterns and produces FHIR profiles [Richard, Michael]
      • Ken Lord MDMI tool – Steve and Richard to follow up
• Wiki and website issues
  • Review/Approval of Last Week’s minutes and Action Items
    • http://wiki.hl7.org/index.php?title=CIMI_Telecom_Minutes_2017-01-26
  • Mayo wiki  HL7 wiki migration
    • http://informatics.mayo.edu/CIMI/index.php/Main_Page#CIMI_Models
  • Status of www.opencimi.org website
    • Who manages the website? How can content be updated, Should we use or link to the HL7 website?
  • Look, feel and content of restructured HL7 Wiki
    • http://wiki.hl7.org/index.php?title=Clinical_Information_Modeling_Initiative_Work_Group
• Review of updated assertion/evaluation example table format - Stan
• Review CIMI models for January comment only ballot – Claude, All
• Continued modeling of assertions if time allows – Stan
• Future topics
  • Loading of concepts into SOLOR
  • Review CIMI Observation Result pattern
  • Harmonization of CIMI and FHIR datatypes - Richard
  • How will CIMI coordinate with DAF? - Claude
  • Granularity of models (schematic anchors) – from Richard
  • We need a way to identify the focal concept in indivisible and group statements
    • We would probably use the new metadata element
  • New principle: Don’t include static knowledge such as terminology classifications in the model: class of drug, invasiveness of procedure, etc.
  • Proposed policy that clusters are created in their own file – Joey, Stan
  • The role of openEHR-like templating in CIMI’s processes - Stan
  • Model approval process
    • What models do we want to ballot?
  • IHTSDO work for binding SNOMED CT to FHIR resources – Linda, Harold
  • Which openEHR archetypes should we consider converting to CIMI models?
  • Model transformations
  • Transform of ICD-10 CM to CIMI models – Richard
  • Others?
• Any other business

2017-01-26 Action 01 (Steve): Justify CIMI IIM&T PSS "Universal Realm"

• Jan 25, 2017: Requested by FHIR Management Group (FMG)
• Jan 26, 2017: Response based-on CIMI Workgroup discussion
  • CIMI considers its work in the "Universal Realm”; where, current work might be considered "US Realm".
    • CIMI's is using a SNOMED extension including LOINC and RxNorm (SOLOR).
    • More countries than the US use SNOMED and LOINC, e.g., Canada, UK.
    • RxNorm is the most international medication terminology that is real
      • RxNorm includes chemical ingredients, which are international;
      • Foreign pharmaceutical units and packaging can replace US pharmaceuticals units and packaging
    • when available, CIMI will use an Standard International Medication Terminology.
    • Technically, CIMI's SOLOR semantic bindings are completely defined; where,
      • SOLOR follows the SNOMED observation model with explicit context expressions (e.g., body site)
      • CIMI's SOLOR terminology bindings can be considered as exemplars

Annotated Figures

• Scribe: SHufnagel@Apprio.com
• REQUESTED ACTION: Update wiki directly or send suggested changes to scribe or cimi@lists.hl7.org

Background (CIMI BMM)

• Reference: Jan 2017 CIMI Architecture, Methodology and Style Guide from Ballot
• The CIMI technical architecture consists of the three Basic Meta Model (BMM) reference model layers and two archetype layers shown here.

The CIMI Reference Model is expressed using the OpenEHR Basic Metamodel (BMM) Language. The archetype layers are expressed using the OpenEHR Archetype Definition Language (ADL). While reference model modules define classes, attributes, and class hierarchies, the archetype layers only specify progressive constraints on the reference model but do not introduce new classes, attributes, and class-class relationships.

1. The CIMI Core Reference Model provides the core granularity of the CIMI model and introduces its top-level classes such as the DATA_VALUE class and the LOCATABLE class. This reference layer module defines the CIMI primitive types and core data types.
2. The CIMI Foundational Reference Model is closely aligned to ISO13606 and the OpenEHR Core Reference Model. It defines foundational CIMI clinical documents and clinical record patterns. It also introduces the PARTY, ROLE, and PARTY_RELATIONSHIP patterns and defines the top-level CLUSTER class for complex CIMI type hierarchies. CQI Knowledge Artifacts may also leverage this layer.
3. The CIMI Clinical Reference Model consists of the classes derived from existing CIMI archetypes, the FHIM, QUICK, vMR, and QDM. This layer defines the set of 'schematic anchors' (to borrow Richard Esmond's term) or core reference model patterns from which all CIMI archetype hierarchies and ultimately Detailed Clinical Models (DCMs) derive. Requirements for this layer come from FHIM, vMR, QDM, QUICK, FHIR US Core, SDC, etc...
   1. The 'goal' is to define the reference models with low FHIR transformation costs where feasible noting that we will inherently have some divergence due to the different requirements underlying both models.
   2. Galen points out that, FHIM’s expressivity will not carry over to CIMI DCMs given the models' different requirements (e.g., FHIM includes finance and accounting).
4. The CIMI Foundational Archetypes define the top-level constraints on the CIMI Reference Model. These typically consist of attribute formal documentation and high level attribute semantic and value set bindings. Archetypes at this layer will provide the foundational requirements for future US Core and QI Core profiles. Future pilots will explore the generation of US Core and QI Core archetypes from these CIMI archetypes.
5. The CIMI Detailed Clinical Model Layer represents the set of leaf-level constraining profiles on the foundational archetypes to create families of archetypes that only vary in their finest terminology bindings and cardinality constraints. This layer is intended to support clinical interoperability through an unambiguous specification of model constraints for information exchange, information retrieval, and data processing.

From layers 1-5, we define the set of transformations (e.g., SIGG (MDHT, MDMI)) to generate the corresponding FHIR profiles including the US Core and QI Core profile sets. Note that FHIR profiles can be generated from the various levels of the archetype hierarchy depending on requirements. The lower down in the hierarchy, the more prescriptive the profile is in terms of constraints. Much like ADL Archetypes, FHIR profiles can be layered.

It is important to note that some FHIR profiles may be derived from the Foundational Archetype Layer (e.g., US Core, some QI Core profiles, some CQIF profiles on PlanDefinition, Questionnaire and ActivityDefinition, etc...) and others from the DCM Layer (e.g., bilirubin, HgA1c, etc...). In other words, the arrow for FHIR Profiles stems out of the outer box rather than the last of the inner boxes (the DCM box).

• The CIMI Core Reference Model provides the core granularity of the CIMI model and introduces its top-level classes such as the DATA_VALUE class and the LOCATABLE class. This reference layer module defines the CIMI primitive types and core data types.

• The CIMI Foundational Reference Model is closely aligned to ISO13606 and the OpenEHR Core Reference Model. It defines foundational CIMI clinical documents and clinical record patterns. It also introduces the PARTY, ROLE, and PARTY_RELATIONSHIP patterns and defines the top-level CLUSTER class for complex CIMI type hierarchies. CQI Knowledge Artifacts may also leverage this layer.
• The CIMI Clinical Reference Model consists of the classes derived from existing CIMI archetypes, the FHIM, QUICK, vMR, and QDM. This layer defines the set of 'schematic anchors' (to borrow Richard Esmond's term) or core reference model patterns from which all CIMI archetype hierarchies and ultimately Detailed Clinical Models (DCMs) derive. Requirements for this layer come from FHIM, vMR, QDM, QUICK, FHIR US Core, SDC, etc...

• This CIMI-FHIM Clinical Reference Model - starts with the Foundation Reference Archetypes and derives Patterns resulting in Semantic Anchors for CIMI DCMs.

Proposed Abstract Finding, Risk, Goal Classes

• Claude: I created a BaseEvaluationResultclass, which carries the essence, for assertion and evaluation that support specializations.
  • The specializations use the “CIMI Foundational Reference Model” dependent Cluster or a structure to add needed attributes at that level (see background above)
    • As an example, a specialization of the BaseEvaluationResult can add
      • key = Systolic Blood Pressure
      • value = 120mg HG or an exception value when results are not captured.
    • another example are the specific attributes needed for SkinWoundAssessment

• Assertion class contains all the needed Qualifiers
• Assertions can link to ClinicalStatements with a “dueTo” relationship.

• Claude: Initially, Risk and Goal were a Context and not a Topic; where,
  • We could not say “there is some % of Risk or no Rusk”; but,
  • as Topic-Assertion-Risk/Topic-Assertion-Goal, they contain non-relevant attributes of Assertion; here,
  • Here, the Context side still remains; but, Risk/Goal are types of BaseAssertion
    • Now, we can add only the relevant attributes for types of Risk or types of Goal.
• Susan: Risks are often pre-coordinated; we need a post-coordinated version
  • Nursing has common pre-coordinated Risk-Assertions, e.g., for types of cancer
  • We need a Risk-for Attribute, enabling post-coordination models
• Richard: can you use “presence” or absence” or “risk of a condition”, such as diabetes?
  • Claude: That was the old representation of Finding-Assertion (e.g., diabetes) with a Context of present, absent or goal;
    • In this representation you cannot say the patient has a risk for or does-not have a risk for (e.g., diabetes)
    • now as a Topic, you have a Topic-BaseAssertion-Risk; where there are relevant Risk attributes (% of risk) and Context (present or absent in this subject)
• Stan: Post-coordination is the preferred CIMI modelling style; queries require meaningful risk-contexts to differentiate people with risk of diabetes vs. people who have diabetes vs, people who don’t have diabetes.
• Claude: specialization may have attributes for particular types of risk
• Stan: Need to separate people with diabetes from people with a risk, no-risk or aspects-of-Risk for diabetes to enable meaningful searches.
  • We need to do this in a similar way that we handled negation; where, Topic-Assertion-Risk allows us to express risk, no-risk, absent-finding or aspects-of-Risk, as one preferred model with 2 dimensions. Pre-coordinated risk would be a non-preferred model.
  • Susan<2:22:15>: a genetic use case is “not a risk of colon cancer, because children don’t have common-cancer gene.
    • Stan: They might say “no increased risk”.
    • Claude: How do we say risk is present/absent or that increased risk is absent?

• Claude<2:25:04>: Goal will have specific attributes plus Context
  • Goal is a sibling of EvaluationResult and Assertion; where, Risk was a subtype of Assertion
  • Although it may not be relevant, you can say a Goal is present/absent.
  • Susan: A Goal, with a metric, is analogous to an instantiated EvaluationResult (e.g., I want my blood pressure to be less than 140 systolic)
  • Stan: Some Goals are more Assertion-like, general and coded (e.g., psycho-social goals to be-happy, exercise-more, lose-weight)
  • Measurable Goal/Objectives follow the statement of an EvaluationResult
  • Richard<02:27:00>: How do you express that a “Patient doesn’t have a goal to quit smoking” (goal absent or refused)?
  • Action (Stan): make Goal examples to help understanding “and to be put in the Style Guide to explain them” [Susan]
    • Claude’s OPEN QUESTIONS
      • When we do this in the table what is the Risk key and
        • Goal, as a child of Finding has a key
      • What is an example of the name?
      • What else do you need to formally specify Goal?

Proposed StatementContext-Promise Class

• Clause <2:30:00>: Promise was added as an Action context tied to Orders
  • Promise is receipt of order with specialized metadata (e.g., lab vs. Rx)
  • Claude: does fulfillment system manage the Promise object (e.g., changes from Order/how it was fulfilled.)
• Stan: Fulfilling system can manage its own instance of Order
  • Systems track state change.
  • Does FHIM consider Promise as a change in responsibility?

• Here is the FHIM Promise class, which will be discussed at tomorrow's FHIM call.

Proposed Abstract BaseAddress Class

• Claude<02:38:00>: I added an abstract BaseAddress class, to allow country specific specializations.
  • USPostalAddress line contains all the information you need in a single class
  • Part lets you to build the whole address as name-value pairs and seems a duplicate mechanism
  • Both representations seem duplicative
    • Stan: Part allows for the addition of other information, such as geo-spatial latitude and longitude
    • Claude: Does Part provide context, such as address is valid or status (e.g., hold mail while on vacation)?
• Linda: Part allows importing addresses
  • General address line 1, 2, …
  • Specific countries constrain out what is not needed
  • consider CIMI’s previous comparative analysis demographics models of Intermountain, Australia’s NEDA, spreadsheet OpenEHR, HL7 V3, ISO 21019, ISO 22209 demographics

2017-02-02 Action-03 (Linda & Claude): make international Address version

• ACTION (Linda & Claude): make international Address version
  • Use AddressLine01, AddressLine02, …
  • have address as BaseAddress-Parts
  • need to use maximal approach, consider US if applicabe
• Stan like abstractAddress to allow delay of adding detail depending on use-case and work with address experts
  • support Japanese Patient being treated in US
  • CIMI does not spend much time working on address detracting from clinical work.