CIMI Telecom Minutes 2017-01-26

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 Figures

Stan presented the following ASSERTION and EVALUATION_RESULT structures example, in 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.

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 in IIM&T Project Scope Statement

• Requested by FHIR Management Group
• Based on 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?