CIMI MTF Minutes 20140109

Jump to: navigation, search

CIMI Modeling Taskforce - Meeting Minutes

Thursday 9 Jan 2014 @ 20:00-22:00 UTC


  • Linda Bird
  • Stan Huff
  • Daniel Karlsson
  • Deepak Sharma
  • Gerard Freriks
  • Harold Solbrig
  • Rahil Siddiqui
  • Thomas Beale
  • Sarah Ryan
  • Jay Lyle
  • Eithne Keelaghan

Results of Initial vote on modeling style for observation groups

  • Linda Bird - Option 6
  • Tom Beale - Abstain
  • Dave Carlson - No vote
  • Stephen Chu - Abstain
  • Mike Lincoln - No vote
  • Josh Mandel - Abstain
  • Mark Shafarman - No vote
  • Michael van der Zel - Option 6
  • Rahil Qamar Siddiqui - No vote
  • Gerard Freriks - Options 4 and 5
  • Stan Huff - Option 6
  • Harold Solbrig - No vote

Summary: 3 votes for option 6, one vote for options 4 and 5, 3 abstains, and 5 no votes


The three leading options are 6, 4, and 5


Draft agenda

  1. Next MTF conference call on January 16, 2014.  No call on January 23 (HL7 meeting and other conflicts).
  2. Joint meeting with SemanticHealthNet March 13-15 in Europe
  3. Entries in entries - discussion of the outcome of the vote
    1. Note from Thomas Beale on preferred openEHR approach
    2. Any further discussion of options
    3. Plans for final voting
  4. Any other business

Detailed Meeting Minutes

Stan: I may suggest a change in the agenda. After I sent out the agenda, I reviewed briefly the information from Thomas on a new approach to identifier in openEHR and... And he had been discussing in AML group. I asked Thomas if he would go over thoughts and plans for new identifier... and I thought we might want to adopt... So, is it OK if Thomas goes over this first?

Response: Yes.

Stan: OK - Thomas?

openEHR - Approach to new identifier

Tom: I'll put the URL on the Wiki page - that is the summary...

[URL =]

Tom: We've been struggling with these in openEHR. Guys who did 13606 did a slightly better way. Most of you who looked at identifier... 'at' identifiers. They are not on all nodes. We have tried to stay away from this - on all nodes - because have to define in ontology.

Tom (con't): So - would not want to have to add a code in the quantity. Would end up with garbage. But without ids on all nodes, there are a small number of cases where paths are not reliable. You can use... to create path... XPath. 13606 - did brief forcing... not mandatory... and I think that is a better way to go - more reliable. The next thing - they are all at-codes.

Stan: Question. You are familiar with... element models at IMH. I would interpret that... required because required key code. So if you make it mandatory, then is like key code.

Tom: It is like key code. I have been always opposed to... But now... You have element... on the quantity object... So if we are going to be regular we would have node id in... but not in terminology. So could work out what has to have definitions... And if node under containment... They either are or could be sibling nodes... which is systolic and diastolic... So these codes you see - we should think of as node identifiers. So we changed to id... not 'at'... So you see... as 'at' codes... And third code is AC code - external... So changes are... to make 'at'-codes - identifiers... have become id-codes... Value set codes are still 'at' codes. External value codes are 'ac'-codes.

Tom (cont'd): So - paths always have Can do quality checking. Have reduced the code-capacity... Not just single... multi... code-system. So some won't care... But if start from ADL 1.4 - is nice future. So we are still discussing in openEHR community. I am working with vendors who have done the... and we will see if this is the final recipe...

Tom: Might remember... term-bindings and... Have collapsed into... like SNOMED description table... We got rid of constraint... AOM-type... If you get the last... and pdf specs... You will see that... becomes simpler. At some future time we could add another table called relationships. So if want to insert relationships, we could. We are not trying to remake SNOMED. It is for the purpose of... We don't have a ... for in-line value set. Might want to create a new code or add... to make sure are children of a value set. You can see an internal value set looks like... So - all on ids is on that page. Makes life easier for software implementation. Another link... You'll see AOM 1.5 and ADL 1.5...

Tom: Go to constraint model...

On Screen - [5 <Constraint Model Package>]

- archetype constraint -

Tom: So - any questions?

Bindings to everything are now URI's

Stan: So, have you included the changes that would change codes to URI's?

Tom: Yes - I've done it. Next UML diagram. See C-terminology-code... Code list could be a bunch of at-codes or an ac-code. I'll have to discuss more with Harold. Now - go to terminology section... section 7... Terminology Package. At top one-half you will see bindings - All bindings to everything are URI's. Second is code or path... everything is URI now... Next - have to work out with Harold what are correct templates... So - now are URI's. Joey and Patrick will have to eventually change their code. Will turn term-binding terms into URI's. Some of you might think "Why is this changing?" I think it is clear in last couple of years, IHTSDO has become serious about this and CIMI has thought about... So I think we should get this formalism up to... and I think it is the way to go. And I think it will bring archetypes closer to IMHs CN's.

Stan: That seems like a very good direction.

Harold: We have been working through the model... AML perspective... And this area, the hashes of the hashes... We will go over... Once we have unwrapped it... it has been proving to be very useful.

Tom: I wanted to point out... data structure on screen will be simplified. Will make Dave happier... The Java implementation - we should have a Java library that does this stuff some... We've done 1.5 stuff... We'll have code soon which Dave Karlsson can use... Java...

Gerard: I am in favor of the direction. I want to see if I bring others from Spain and Netherlands into the loop.

Tom: Have them look at specification. They should think about whether distinguishing at-codes from... And the ... binding...

Gerard: I need to be certain.

Tom: Go for it. I want all the tools to do exactly the same thing. And what I described is not fixed yet... Probably 4 groups... ADL workbench - it works. I think it is pretty good.

Gerard: If successful - these 2 topics... must find ways to bring it into this renewal process.

Process for CIMI arriving at a Final Vote

Stan: Back to representation of panels and style for groups. In terms of process - what we set up... Pick highest 2 vote getters... and then final vote. We had the initial vote. 3 for Option 6. 1, Gerard, Option 4 and 5. He couldn't decide. 3 people abstained. 5 did not vote. The question is - how do we want to move forward? You may have seen the further emails from Thomas...

Stan (cont'd): I saw a flood of emails - happened before I woke in U.S. So I have now caught up yet. So - what I would like to do is figure out what we want to do from here. OpenEHR - what best practice approach is... If we go by our previous understanding, we would investigate Option 6 and 4 or 5. Would have to force Gerard to pick (between 4 and 5].

Gerard: No need to discuss now. Let's listen to openEHR approach. I have to read email from Dipak still.

Stan: OK. Another idea - one way to make very clear, aside from examples, we could say... if chose Option 6, what would Reference Model look like... or 4 or 5... And I assume openEHR... would be unchanged. So I am thinking next vote... ref model Option 6 or... or 4 or 5... What do you think about that in terms of a process?

Rahil: Sorry - I missed the voting. I would have voted for Option 2. Also, there was an email from Ian - I thought it was close to... So I would have voted for that. I don't know what... Does not require change to the Ref Model.

Stan: I don't want to have formality keep us from the right decision, but it is important to have a decision. I want to agree as a group. If want more discussion with Thomas... As you know, time is important. I had hoped we would have done this 2 years ago... I think it has been important... But I would rather make decision and then find out we have to change something... But how easy or hard to build content... Want to get to a point where we are making content... rather than theoretically talking...

Rahil: At NHS, creating logical models. We require patterns for consistency in modeling process. We have chosen 13606. If we do... to CIMI in the future, we want to be able to transform easily from 13606 to CIMI ones. So have to see what changes in CIMI and whether we can work with it in the future.

openEHR - Best Practice

Stan: Thomas - can you stay on the call? Explain openEHR best practice...?

Linda: Can Tom explain how to align Option (2 or 3?)... So it is aligned with openEHR best practice? We have on powerpoint.

Tom: We need to consider... Lab panel problem... on Problem 2. Solve. There are actually lots of other clinical data to look at... Might cause changes... may not be compatible... One reason I did not want to vote now... though needs to happen.

Tom (cont'd): I agree, I think, with Deepak... I wonder if makes sense to go back to requirements and... formal requirements. So - something about querying... to get query Hematocrit... if inside panel... I think a visit of requirements and clarification of... formality... to say what should be true...


Stan: I haven't had a chance to read Deepak's requirements. What did he say?

Tom: He said 'Lads - get your requirements together'... Haven't quite gotten the... sorted out yet...

Stan: I think it usually is an iterative process. Happy to go look at requirements. We set up requirements and this helped... and if need to look at requirements now, then OK...

Deepak: Did I say something?

Stan: Deepak Cholera - not Deepak Sharma.

Tom: Don't want to go back to theoretical review. There are 2 things. The context info... and the other is... paths and congruence. Those are the 2 topics.

Action Item: Next meeting - to go over requirements

Stan: Jay Lyle outlined some things and I responded. We did not discuss as a group. We could do this... probably good... We talk and think we understand... But then find out... Maybe next meeting we can go over those.

Stan: You can have single definition of Hematocrit or Hemoglobin or Blood Pressure (BP)or Heart Rate or... In defining those, you can define other contextual elements. So, BP - can define what is called protocol in openEHR, i.e. type of device used. Once have fundamental pattern, can include in panel. So BP in defined set of prenatal measurements or... Then can include in specified groups... is useful... These are programmatic... They are useful to define and exist in working systems... and to ignore them would make it difficult.

Query Path is stable and can support groups within groups

Stan (cont'd): So - atomic statements... can re-use them... So, when query and you want hematocrits and... Atomic statements - have then qualifiers... When you query and access data - I can query whether stored as CBC or prenatal or... So, query Path is stable and can support groups within groups. That is the heart of it. But I welcome comments from others and clarifications.

Jay: This morning I started... Idea of query path is a sticking point... not clear... If Hematocrit is reachable... The existence of panel...

Tom: We have been computing with these models for 10 years, and with AQL since 2010. It is easy to pull the Hematocrit out... whether in panel or whether its own thing... I won't explain now... but not a problem.

Stan: I agree with what Thomas said. Puts responsibility on... But if something is defined as part of panel, but you are saying this is... whatever panel... can retrieve directly and not as part of CBC... So is trivial.

Jay: That makes sense, but the word "path" confuses me.

Stan: I think we are talking about Path because of XPath and...

Tom: Some have archetype workbench and notice can extract from any path... use tools... Other tools writing environment... When you hit a dot in... Visual Studio tools... From our point of view... Stan has own idea... If people don't feel... what path means... in terms of archetype... is required... is key to making query work... is running behind screen in hospital...

Jay: Any proposals that do not provide consistent query paths in models...

Stan: Yes...

Tom: See where you have element in Blue and cluster [Option 2B on screen]. That is where codes are... that give paths. Also... the attributes... the bits in square brackets... Hard to see paths from these pictures, but could...

Where the Context is stored

Linda: I think the issue we are discussing is where the context is stored. Traditionally - stored in panel. Whereas Hematocrit - a single test - context is stored in single... Can pull out, but need to handle differently and model in two different ways.

Identifying What Things are Query-able

Stan: Yes. Another important aspect... which I think is part of motivation of existing models... is identifying what things are query-able. What things are independent statements about patient and those that are... Might want to query and find out how many times I used body part, but not important unless... Important for people who use... easily recognize that Hematocrit has clinical meaning, rather than query "body location" independent of whether is body location for injury or... We would like to represent that in association to structural element. In chain... That is what I understand entries to provide... What I can query for... independent operations... Could be done a different way... Could have permanent part of model or annotation.

Linda: And... indivisible statements.

Stan: So - back to screen. How would we change to make it represent what openEHR would say? What is current best practice for representing? Do we need to explain this first? Or is [Option 2B] on screen understandable?

Tom: Nothing in this looks like openEHR. These are 3 elements - 1 has 9 and one has interpretation and one... In openEHR, we would just have one element and all would go underneath.

Stan: The value and interpretation would go there, but quantity does not have name in itself. So Hematocrit... and quantity is... included.

Linda: Slide 9 might be more concrete. This [Option 2B] is based on slide 9...

[slide #9] Option 2B - Entries and Clusters.

Tom: So - 2 things here have names. Name-result value and interpretation. We would not bother with name because that is what it is. And interpretation is so common in openEHR.

Stan: Does not solve the question. That works for Hematocrit, but if Blood Pressure, then extending the list would be patient position and...

Tom: Yes - would be separate elements. But...

Stan: We would do other example. But really question is... what is the pattern when you want to say more...?

Linda: So... comment about Hematocrit.

Tom: If want comment on per-item element level, then data point would be like a cluster and have things under... What we discussed... comment... occurs... But let's assume... has a bunch of children. If that is the rule in CIMI, then... But I would probably not use cluster and element since look like 13606, but not the same.

Stan: We thought we were using them the way they were intended.

Tom: Nothing wrong, except I was thinking... What would it look like? Let's not worry about what they are called.

Gerard: Is a matter of modeling style.

Tom: And CIMI could adopt that... Systolic would have to be in cluster... and diastolic...

Example of correct openEHR style for modeling Heart Rate with patient position

Stan: An observation with... If we assumed, where we have Hematocrit, if had a Heart Rate and wanted to know patient position... What would be correct openEHR style for modeling that?

Tom: Standard way would be a Cluster. Data protocol state... Cluster with... Another under that with... protocol... And patient-state... And protocol would be instrument and... We don't have state-protocol...

Daniel: That would mean single Heart Rate would not be query-able as Heart Rate in panel.

Tom: It depends. If have Heart Rate, depends on how you build the panel. We would keep the... The paths to those items are always the same. But you have more than 1 entry... Heart Rate context is different from Blood Pressure, which was checked at same time.

The Path is defined when you create the Archetype

Stan: Solved by style and process rather than... A modeler could, rather than create ... archetype, they could create Vital Signs archetype which could have Heart Rate and Blood Pressure and... So you can do what you want at template level, but the path is defined when you create the archetype. Whether at entry level or... The path gets fixed depending on which one you use. You could end up with some things that are created as one archetype and some other as other archetype.

Tom: Yes. Your one statement... Does not matter what data or... template it is recorded in, but you want... But other one does that they create... A Vital Sign panel collection is always going to be multiples of entries put together in a composition.

Clarification from Thomas Beale by email

[The basic point is: Paths to data items are defined by their archetypes, not by their templates. That means that the path to e.g. systolic BP is always the same, no matter which template it is captured in (each template typically corresponds to a different data set, e.g. a screen form). So this means that queries for systolic BP can be written without knowing or caring about the templates that have been used to capture it - you just need to know one thing - its path in its archetype. (This doesn't mean you can't also include in the query things that might be particular to some templates, since all templates are just made up of archetyped data points anyway). Short version: if you have the archetype, you can reliably query the data.]

Stan: Composition or template?

Tom: A Template is just an archetype... so 3 Entries, and paths to them... are based on those archetypes... The path from root point of entry... So, if people want to have a free-for-all modeling style so panel like... You're using an archetype like a template... and using... Blood pressure and... That is modeling style of openEHR, but...

The Style used for Lab Data, Panels

Stan: I have not looked at Heart Rate and Blood Pressure. But that is not the style used for Lab data.

Tom: Yes. Lipids or Liver Function or Thyroid... Gathered together... Those are... So can ask for total cholesterol... But as soon as talk about Chem 20... or Thyroid TSH in our system, will be 3 sibling entries with one thing from each in it. Is a different type of level.

Stan: But to be clear... some of the lab things people might construct as Lipid panel... single entry... But Creatinine level may have been defined on its own. Then when I create collection and template it, then single archetype and collection. Path to single will just say creatinine... and the... will say Lipid Panel - HDL. I don't see any consistent rule to say which should be done as panel or single... Not inconsistency in... But one would say "path - I am creatinine clearance" and the other "I am a Lipid Panel path". We may want to say if clinical measurement... we create panels templating on composition... May want to say this is right style...

Tom: If want to mix and match element archetypes... What CIMI will need is 1 cluster per analyte... And each one of the guys would generate a Cluster with elements hanging underneath... pretty solid. And use template to put together... which we would not have to do... And would have to create template for Chem-7 or Chem-20. But Big Deal. Just a different way. If that is the theory, then... would just have to make sure... But the mentality of what we have... if you were to get book with lab tests... probably a few hundred tests... quite well known... and the mentality was to create those and then put together.

Stan: That is my training... in lab medicine. But the other part of why I worry comes back to what is query-able. Can't have entries in entries... The others have to be Elements and Clusters.

Tom: Why not make CIMI rule a cluster archetype... and if want to create a panel... a Chem-7... Then make entry and create template... at entry...

Stan: That would work, but I was looking for consistency across lab data and patient... measurement... Single entry-level archetypes... I was looking for consistency.

Tom: We would treat those as... "munges" things together in flat list. But data... recording structures don't look like that... If look at... And data structures for colonoscopy... have 3 levels of hierarchy... complexity...

Stan: In the end, those things are style. No internal truth. Is in the eye of the beholder. I want to understand what you think are best... and then decide as a group... So... Option 6... simple... collection-entry... and atomic-entry... Atomic-entry should never have others in it. In the end - is in the eye of the beholder. Both unambiguous. But when explain to modelers - which would be the best?

Tom: Does Option 6... free-form hierarchies?

Linda: Yes - need to have multiple levels of groupings in panel.

Tom: So what would be the multiple levels? If look at microbiology with lots of depth. Those are defined by micro-people... What does it mean to create an arbitrary pattern?

Stan: Use-case could be the pre-natal exam. Part of entry we agree with... Shared set of attributes we can agree on... Same patient... The Use-case is... I could have situation where... have a nurse do a finger-stick... End up with Hematocrit, fundal height, Heart Rate... Is shared context... coming from lab and other person... Have situation where... finger-stick Hematocrit, fundal height, history and physical exam - all attributed to her. And that could be part of something else done on same patient. Don't want to be prohibitive on sharing.

Tom: Almost a text-book description of openEHR. If do the ante-natal exam and get 5 or 6 things... are sections... and context in entries and compositions... I wonder why these don't say composition and entry in... results and entry in...

Linda: But then need separate entry for panel...

Comment: ?

Linda: But composition can't contain a cluster.

Tom: But under the... you can.

Stan: Don't understand.

Linda: Tom indicates can add clusters under... in protocol model.

Tom: Easy to make CIMI model... If don't want entry like Hematocrit. But tracking id's or location.

Linda: Would require change to Ref Model...

Daniel: Or add...

Tom: Or add... other entry.

Stan: Those sound like Option 6.

Tom: Put up Option 6.

Stan: Yes.

Tom: What you said before - exactly how we would do it... Take Hematocrit or Hemoglobin...

Example of Discharge Summary

Linda: Tom - also depends on what you are modeling. If... and vital sign composition, then discharge summary is...

Tom: A discharge summary is a document that refers to existing data that could be inside compositions... or might put reference to...

Linda: Pulling the data in...

Tom: Key diagnosis, key results, Treatment-plan, history, all inside compositions somewhere... So discharge summary will take the bits and pieces. Even if Blood Pressure was in same composition back in record, now in discharge summary... will have a marker to say is an existing piece of data.

Linda: But if discharge summary was a copy and want to summarize into discharge summary, then would require...

Tom: Info of each of those panels... Let's say a urinalysis done 3 days ago. If want that info, is a cluster of info... Now you create a discharge summary... You will have to create a place to put all of those. A case of designing a template for the discharge summaries. But I think would have clinical references... Could be as large or as small as designer wants...

Stan: First Rahil, then plan how to conclude.

Questions about Compositions containing Compositions and Panels as Compositions

Rahil: How to approach the problem... high-level... built in as a composition. The way we have done composition is for reports or... That can be attested. If we start using hi-level... that have similar context... Then that is confusing... the other... in Option 6... Use compositions... That level of grouping... What section... Section not having semantics... If sections could be the other... Could be grouped. But I am not able to under the composition. So if CBC - a composition... And the laboratory - have more than one panel - becomes a composition within a composition.

Tom: I don't see a problem. Should be easy.

Rahil: But compositions can't contain compositions.

Tom: You just create a composition with lab report. And you have a whole bunch of entries.

Rahil: That I understand. But if was the... If start having panels as compositions, then those panels will be in higher level...

Tom: What do people understand as panel? To me - Labs that were recorded together... Lab report is a Composition...

Rahil: I understand Lab Report being a Composition with lab reports... But it was the other. And Linda queried on that before me.

Linda: Yes - panels as compositions would be problematic.

Rahil: Yes.

Stan: OK. I have learned a lot from this discussion. I suspect we will not know all implications until we start and then realize... So we can review and then... Could take Jay's suggestion... The second would be... We need 1 or 2 or however many... We would say... Yes - this is what we would say is the openEHR best-practice. We need to draw diagrams that would show that. The people... This is over-simplification... have not shown the id's or.... But we need that representation... The openEHR... So go ahead and clarify the requirements. And #2 - further clarification. Not an exercise... We want... to say... this is the way I would want it to be done. Which is what I say for Option #6. So, Rahil, explain what advantages are to Option 2B. And same from openEHR best-practice, Thomas. Don't know if we will ever have perfect understanding, but need to get to informed vote and count votes and move on.

Linda: Also, Option 6 - if we could review what changes to Ref model would be.

Stan: Yes - so 2 steps... The Ref Model changes... We have good starting point for requirements. I don't know how to get... best practice for openEHR. I don't know if Linda, you have good... and could draw it up.

Linda: In discussion... Tom's comment was like Option 2B. Would like Tom to make changes.

Daniel: I thought I heard that openEHR is producing 2 types of patterns like 2B, and the other like Item 1.

Gerard: I agree, Daniel.

Tom: Option 1 Daniel? Yes. I think if you replace section with composition then that would be the way to go... mix and match. Other Blood Pressure and physical... Would also be entries... Hematocrit on some... as Blood Pressure... and I think that is right. If want to make it so Systolic Blood Pressure and... Then that is query results... Query output model - based on queries. Is different.

Stan: Yes - is different from what you are doing... I put composition instead of...

Tom: I would have... and where have panel, create as cluster. Or could create an entry with that change... Would probably be my vote. Does what I think everyone wants to do?

Action Item: Linda makes change to Option 1 or 7 and Tom reviews

Linda: I can make change to Option 1 or... 7 or... and get Tom to look at it.

Tom: Create models... ante-natal is a good one.

Daniel: For example, in openEHR CKM... on template-side of things... There are Risk factors... Tobacco use and Alcohol use.

Stan: Daniel - if you could send out a note.

Daniel: [Already did?]

Action Item: Next Meeting - To Go over Requirements and Vote on Options

Stan: So - make it as an Option 7. So next meeting - go over requirements. Would say... have 3 or 4 things to vote on in terms of options. Clarify requirements. Have new composition. If reasonable - say would have to do anything to Ref model, what would change look like? Do we want to change Ref Model? Option 5,6,7 or Option (Gerard)... So - then decide if 2 or 1 or more vote.

Stan: I appreciate all the knowledgeable people being on the call. Thank you!