CIMI Telecom Minutes 2017-01-26

REQUESTED ACTION: Feel free to directly edit this WIKI page or sent your feedback to CIMI@lists.HL7.org with your comments, updates and corrections.

Attendes

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

Annotated Agenda (Minutes)

• Record this call
• Agenda review (Richard & Steve's suggested topics were added)
• Updates on active projects (standing item)
  • Skin and wound assessments – Jay and Susan
  • FHIM – CIMI integration - Galen
  • 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)
    • Steve: Is this OBE? There is a Final Report at: https://1drv.ms/w/s!AlkpZJej6nh_k9dQ2qQnRuQM8gbu8A
  • Conversion of CIMI archetypes to FHIR logical models to FHIR profiles – Claude
  • LOKI – Patrick is still working
  • BMM parsing and serialization code – Claude
  • Creating ADL models from CEMs
    • First recreate CEMs from BMM and ADL files
    • Second – CEMs to BMM and ADL files
• Updates on HL7 Vocabulary WG threads - Richard
  • Terminology & ValueSet Publishing
  • Terminology Binding
  • ValueSet Expansion
• Review plans and action items from San Antonio – All
  • http://wiki.hl7.org/index.php?title=CIMI_WGM_Agenda_January_2017#Thursday_Q4
• FHIR Management Group requested justification for CIMI PSS being Universal Realm; where, the bulk of our work appears US centric (SNOMED, LOINC, RxNorm (SOLOR) in particular).
• Review of assertion/evaluation example table format - Stan
• Motion: That we create an informative ballot for May. Moved by Jay, second by Claude. Affirm: all, Neg: 0, Abstain: 0.
• Review CIMI models for January comment only ballot – Claude, All
• Continued modeling of assertions if time allows – Stan
• Future topics
  • 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
  • Requirements and tactical plan (Who does what) for May Ballot content
  • Requirements and strategic Plan for how CIMI tooling can improve (make consistent) and integrate with current FHIR web-based tooling - Steve
  • Requirements and strategic Plan for Streamline process to produce FHIR Profiles and Extensions - Steve, Galen, Claude
    • E.g., Is there an expedited UML tool path to FHIR Structure Definitions, as recommended by Michael van der Zel; where, tooling can also produce ADL.
  • Requirements and strategic Plans for CIMI Clinical Knowledge Manager (CKM) before we create stovepipe solutions - Steve
  • Others?
• Any other business

HL7 CIMI Meeting Details

https://global.gotomeeting.com/join/754419973

You can also dial in using your phone. 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

Annotated Figures

Stan presented the following ASSERTION and EVALUATION_RESULT structure example, from an Excel Spreadsheet, for workgroup discussion. Claude suggested separate PROS and CONS columns to justify why we selected the "Preferred" representation structure. Stan accepted the action to add the PROS and CONS columns and to continue adding illustrative examples.

• Example ASSERTION & EVALUATION_RESULT representations

Claude presented the following EVALUATION_RESULT and ASSERTION Patterns; where, he asked how we might make them equivalent and round-trip transformable. Stan Huff pointed out that, in practice, these structural patterns are used in different contexts, have different attribute requirements and do not have to be round-trip transformable. We discussed why categories, such as subjective or objective criteria, do NOT universally work in "edge cases". Stan verbally gave his ASSERTION and EVALUATION_RESULT structure selection guidelines, which Steve volunteered to document for workgroup review.

Claude presented the following two figures; where, the first figure shows the current CIMI BMM layers and the second figure shows a US and Canada centric ADDRESS Pattern; and where, Claude asked should country specific addresses (e.g., Japan) be a layer between layer 4 and 5 or integrated into layer 4. Galen suggested we follow the FHIM approach to have an abstract address class with country specific sub-classes. Stan concurred with Galen and recommended that they be integrated into layer 4; because, if subclass attributes migrate to the abstract address class or visa-versa they will remain consistent. Claude took the action to add an abstract address class.

Action 01 (Steve): Justify "Universal Realm" Criteria for IIM&T Project Scope Statement

• Requested by FHIR Management Group (FMG)
• Based on today's Workgroup Telecom discussion

Action 02 (Stan): Flush out ASSERTION & EVALUATION_RESULT example spreadsheet

• add PROS and CONS columns to justify "Preferred" representation
• add additional illustrative example

Action 03 (Steve): Document ASSERTION & EVALUATION_Result Rules

• Stan: Reasoning, subjective or objective categories are NOT supportable guidelines / rules.
• Jay: See http://wiki.hl7.org/index.php?title=CIMI_WGM_Agenda_January_2017#Thursday_Q1 for a start

SNOMED CT Finding concept seems appropriate to the Assertion model. This is a finding in the patient. We do, however, make presence, timing, and subject explicit, as in the SNOMED CT Situation model.

• Key = Assertion; Value = Diabetes (finding)

This corresponds to Situation; subject = patient, context = present; associated finding = diabetes.

SNOMED CT Observable concept (or LOINC codes) seems appropriate to the Evaluation model. This is the evaluation of a property in the patient.

• Key = Blood Type (Observable); Value = B negative

Observable: do we need a specific range, or can an Observable have two (pulse rate, pulse strength)

• Wave form: frequency, amplitude, shape. Are these three observables? We think so.
• Wound: many observables. Type may be baked into the assertion. All the rest are Observables.

The question is not what the fact “is,” but how do we represent it?

How to decide which pattern is preferred (for a case):

• Characteristic vs whole patient.
• Category. (e.g., drug injector question)
• Can we use Queries to differentiate.
• Table of examples & edge cases.
• If answer is Boolean or Present/Absent

[case: absent risk. Multiple context values or precoordinated; or other approach]

Note: use “evaluation result” to distinguish from the act of evaluation.

We want a single representation that can be reliably used for both cases.

EvaluationResultto Finding is easy:

• Finding of blood type of B negative.
• Systolic Blood Pressure is 131 (unlikely but unambiguous)

Assertion to EvaluationResultcan be harder

In order to logically transmute Finding of Diabetes into an evaluation, not only do we need a corresponding Observable concept, but the Finding concept or Observable concept needs to be defined in terms of the other. Another question: can we negate loss of consciousness within a present head injury? The situation model only has one site for Finding Context. These have to be separate Situation using the current model; their relationship lives in CIMI, not the ontology.

PenRad using CliniThink, which uses attribute chaining rather than role groups, apparently successfully.

EvaluationResult has Method; how do you do that in Assertion? Assertion has [property]; how do you represent that in an EvaluationResult?

Action 04 (Claude): Add ADDRESS abstract class in Foundational Architypes BMM layer

• Stan: Keep country specific address classes in Foundational Architypes BMM layer

Post Telecom Discussion: ASSERTION vs. EVALUATION_RESULTS

From: Joey Coyle Sent: Friday, January 27, 2017 10:43 AM Subject: Re: CIMI meeting 26-1-2017: Assertion

• Stan has talked about Assertion and Evaluation as 2 'modeling styles'.
• You have defined ‘assertion’ : a confident and forceful statement about a fact or belief.
• I think the Assertion / Evaluation distinction does conform to your definition, when one focuses on 'modeling style', and not the resulting data instances.
  • The Evaluation modeling style is NOT a "confident and forceful statement about a fact or belief." Since the valueset has many options, the eye color could still be blue, brown, green.
  • The Assertion modeling style is confidently and forcefully saying this model has to represent blue eye color.
  • I will agree though that once a data instance is created for either of these and stating "blue eye color", they are a equally confident and forceful statement about a fact or belief.
  • Thus I feel the terms Stan is using for the 2 modeling styles follows your definition for the 'modeling style', but yes I agree this distinction disappears once you create the instances from these models.
  • That being said, I'm sure if we can find better terminology for these modeling styles, Stan would welcome that.

Assertion Style

---

BlueEyeColor

   key   isA_Assertion_code
   value   blue_eye_color_code

Evaluation Style

---

EyeColor

   key   isA_Eye_color_code
   value   any eye color code   ( from valueset of all eye colors )

From: Gerard Freriks Sent: Friday, January 27, 2017 9:41 AM Subject: CIMI meeting 26-1-2017: Assertion

I have serious problems with the current line of thinking about the use of the term ‘Assertion’ and ‘Finding’. It is impossible for me to grasp the difference between Assessment and Finding.

1- When I look up the meaning of ‘assertion’ I read: a confident and forceful statement about a fact or belief. To me any statement is therefor an assertion. At least the ‘Finding’ is an assertion as wel.

2- To me we need only 5/6 kinds of statements as main patterns. The 5/6 statements correspond to a common, accepted, clinical model: Clinical model documentation process phases: - Observation of phenomena that result from a process. Human senses are used. - Assessment of a process. When the process is one in the Patient System it is called Diagnosis. Implicit and explicit resources are used. Mental processes/CDS play a role. - Planning of the execution of a process. Mental processes/CDS play a role. - Ordering the execution of a process. When the target is a process in the Patient System we call it treatment, or it can be the ordering of Observations. Mental processes/CDS play a role. - Execution of the process. e.g. lab tests can generate a lot of detailed additional information.

3- Each statement is about processes, that can be located in the Patient System or in other more administrative processes

4- The documentation in the phases above is a process as well.

5- Any statement can be used in: - any of the Clinical model phases - relation to processes in the Patient System or any administrative process and, - any interface

6- All Statements have the pattern: - Key, Result - Context (why, who, when/where, how) - additional metadata that indicate: the clinical process phase it is used in the kind of process the kind of interface The additional metadata indicate how the statement is used in the documentation process. The context defines the context of that what is documented.

7- The examples as provided by Stan 1a: Key=SystolicBPMeasuremet (when it is a new observation) Result= 120 mmHG ClinicalProcessPhase: Observation Target: Patient System Context: …

When this Observation is re-used the target = the process that is observed.

4a: Key=Diagnosis (when it is a new assessment of a Patient System) Result= DiabetesMellitus ClinicalProcessPhase: Diagnosis Target: PatientSystemProcess Context: … When this Assessment is not a de novo fact but re-used the target = the administrative process that is observed

4b: Key=Diagnosis (when it is a new assessment of a Patient System) Result= DiabetesMellitus ClinicalProcessPhase: Execution Target: AdministrativeDischargeProcess The search for the Key/Result pair gives all. Some additional attributes are needed to end in all FinalDiagnosis in a Discharge letter or all de novo registrations of the diagnosis.

When this Assessment is not a de novo fact but re-used the target = the administrative process that is observed

8- Any statement as Modifiers: - present or absent - certainty (uncertain, …, certain) - Status (no result, intermediate result, final result) Observe I split presence and certainty because they are not the same concepts. Observe that I use a very specific Status at the semantic level of Statements. The examples in the spreadsheet are about wether the datum is present or not in the technical interface. This handled outside of the statement. In 13606 it is coded via structural attributes in the RM.

9- Questions about the spreadsheet: - How can you create a CIMI pattern that expresses that: blood pressures above 130 mmHg are Not Present?