2016-06-03 PC CIMI POC Call Minutes

Back to PC CIMI POC Minutes

Minutes Template

Meeting Information

HL7 PC-CIMI-POC Meeting Minutes Location: HL7 WGM, Montreal		Date: 2016-06-03 Time: 9:00-10:30 ET
Facilitator	Jay Lyle	Note taker(s)	Jay Lyle
Attendee	Name	Affiliation
y	Richard Esmond	PenRad
y	Galen Mulrooney	JP Systems
y	Jay Lyle	JP Systems / VA
y	Harold Solbrig	Mayo
	Susan Matney	Intermountain
	Joey Coyle	Intermountain
y	Laura Heerman Langford	Intermountain

Agenda

Agenda Topics

1. elements & semantics
2. editing ADL
   1. . Oxygen syntax file?
   2. . Method: technique bound to qv, not procedure. No "evaluation" value available.
   3. . Numbering scheme.
      1. is it computable or merely convenient? assumption: dots tell compiler the level, and magnitudes tell it the latest, but they don't have to be serial.
      2. kinds
         1. id: model binding for node.
         2. at: value binding to a single code.
         3. ac: value binding to a value set
   4. . syntax
      1. extend by adding a node (e.g., 5.0.1 -> 5.0.1.1)
      2. or constrain (e.g., 5.0.1/value[xyz] matches . . .)

Minutes

Minutes/Conclusions Reached:

1. Oxygen syntax file? Pat may have one for Sublime
2. Semantics discussion based on Harold's draft:
   1. The CIMI identifier is the "code" that would be used in guidelines, alerts and general clinical documentation. Its purpose is to bridge the clinical and technical and to be sufficiently precise that the clinician can determine precisely what is and isn't referenced by the identifier and the tooling developer / architect can understand exactly what it references.
      1. e.g., CIMI-CORE-ITEM_GROUP.skin_condition.v1.0.0. CIMI's raison d'etre: identify these.
   2. The about reference ties some (not necessarily all) model elements to a formal description what the element is actually describing, be it patient age, specimen draw date or the TcB measurement procedure. Note in particular that the about identifiers are a part of the CIMI model and do not usually, if ever, accompany actual data.
      1. = "model binding"
      2. to support observable, this is not the root (which would be bigger--the CIMI identifier).
      3. segregate into contextual & ontological stuff? proposed. into a substructure. This would be the point to bind an observable about.
      4. if divided into epistemic and observable, then there is redundancy between CIMI & SCT models. Do they both need to exist. (Legacy momentum.)
      5. Not all elements need an about.
   3. The code attribute is data. Not all CIMI models have codes. At the moment, it appears that code is mandatory for the class of models called "Observation", but it isn't obvious (at least to me<HS>) how this can be possible, given that (a) some observations do not currently have an associated code, and requiring that one be minted (beyond the CIMI identifier) for every code seems to be just make-work. Furthermore, it may be quite possible (see TcB / TSB total/direct or conjugated and unconjugated) where one may want to include a set of possible codes — any of which would be valid.
      1. Is a code unique for a model? Only if semantically unique. We may want to allow a set, if codes have different (contextual) properties.
         1. example of serum biliruben - should be 0..*; may be constrained. Is this a method?
3. Open question: does a CIMI model have exactly one LOINC code (where LOINC is the appropriate system)? It doesn't seem too align with clinical use.
   1. Perhaps a CIMI model may allow any of a set of LOINCs. Instances would still specify one.
      1. Would the semantics of "about" then be inferred from the LOINC-SCT mapping table?

Meeting Outcomes

Actions begin construction of test classes

Next Meeting/Preliminary Agenda Items Review test class progress & tooling

© 2012 Health Level Seven® International. All rights reserved.