CIMI MTF Minutes 20131031
- 1 CIMI Modeling Taskforce - Meeting Minutes
- 1.1 Attendees
- 1.2 Draft Agenda
- 1.3 Documents used During Meeting
- 1.4 Detailed Meeting Minutes
- 1.4.1 Entries in Entries - Review Process for Getting to a Decision
- 220.127.116.11 Thomas Beale joins call
- 18.104.22.168 Question for Tom regarding the email he sent out
- 22.214.171.124 IMH - Anything labeled as statement is query-able; must be able to be returned if asked for
- 126.96.36.199 openEHR - chose to hard-wire more
- 188.8.131.52 Key thing of CIMI - to make the constraint formalism work for whatever style of modeling
- 184.108.40.206 In a way, is a question of style - how much is in Reference Model
- 220.127.116.11 Stan's bias: to put less semantics in Ref Model and more semantics in Archetypes
- 18.104.22.168 Principle - Ref Model would have no Healthcare Semantics; implemented in archetypes
- 22.214.171.124 Compositions cannot contain Compositions, but can contain Sections and Clusters
- 126.96.36.199 Sections can contain Sections
- 188.8.131.52 Sections cannot have Data Elements
- 184.108.40.206 Compositions contain Sections or Entries, but not Elements
- 220.127.116.11 How to Represent Information at Panel level; "Panel Interpretation"
- 18.104.22.168 Terminology: Compound Statements preferred over Entries in Entries
- 22.214.171.124 Definition: Asterisk on slide means "derived"
- 126.96.36.199 Qualifiers vs. Context block
- 188.8.131.52 Action Item: To get review by Tom, Heather, Ian by next week's meeting
- 184.108.40.206 Atomic Statement - the smallest meaningful bit about a patient
- 1.4.2 [end-of-meeting]
- 1.4.1 Entries in Entries - Review Process for Getting to a Decision
CIMI Modeling Taskforce - Meeting Minutes
- Linda Bird
- Stan Huff
- Joey Coyle
- Gerard Freriks
- Sarah Ryan
- Dave Carlson
- Thomas Beale
- Galen Mulrooney
- Harold Solbrig
- Jay Lyle
- Michael van der Zel
- Patrick Langford
- Thomas Beale
- Eithne Keelaghan
- Brief follow-up on binding discussions from last week
- Entries in entries discussion
- Review proposed process for getting to a decision
- As needed, clarify any goals or requirements around this topic
- Do we want to make any statement about the level of semantics that should be in the reference model versus semantics in "patterns" (reference archetypes) above the RM
- Determine the best representation for each proposed style
- Start with the examples of CBC from Linda, modify as needed to be accurate with proposed style
- Clarify any policies that are needed to support consistency of modeling
- Get agreement on the capabilities, pros, and cons of each proposed representation
(We may not get this done in one meeting!)
Documents used During Meeting
Detailed Meeting Minutes
Stan: I will make up a model where relationship in SNOMED are good because pre and post-coordination... and if we can work through that, we will be in good shape. Any questions or things to go over?
Linda: Not from me. If I send out bindings and people can digest it, then can talk about it.
Entries in Entries - Review Process for Getting to a Decision
Stan: Then move on to second agenda item - Entries in Entries. I proposed a strategy in agenda.
[See agenda above]
Stan (cont'd): The idea would be... can clarify... Might need to get more formal about stating requirements... formalize so we are all agreeing on purpose. And then... the meat of this... to work from proposed style. So show everything we need to show - and accurate for people proposing that type of model. So someone who is an expert in openEHR - I want them to say "Yes - this is the best representation... the style..." Then, given those clear and explicit examples - to be able to agree on pros and cons. Not right and wrong - just need to say implications of each style. Might not agree on priority, but should have common understanding of pluses and minuses, and then we vote and move forward with that style... Always possible to change minds... but need to move forward or is a barrier. Does that seem like a reasonable approach?
Linda: It does. With regards to the models, should we do... or Powerpoint representation?
Stan: I like Powerpoint. If need to show terminology binding... My focus is... on logicals... or Mindmap might be... But already a good start on Powerpoint. My preference. We will be dependent on Thomas having time to review on these. There you are.
[Thomas Beale joins call]
Linda: Based on what Tom said last time we went through slides, I think I predict what he will say... The context... we have it in the right spot but will not be in the archetype... but he can tell us. Hi Tom.
Thomas Beale joins call
Thomas: I just realized I could join the call.
Stan: We did a bit about binding and talked about strategy which is... if the real meat of this is to get accurate example that show the possibilities and I want... important that examples are accurate according to the expert in that... So, openEHR... want you or others to say "Yes - this is the best way I propose" so we have for each proposal an accurate and explicit representation... We might weigh those differently, but might be able to say that this builds context as build archetype...
Stan (cont'd): So - once we have pros and cons and common understanding of implications, then we vote. If we run into trouble, we might have to change. But we need to decide and move on or it becomes a barrier. Any comments?
Tom: Sounds fine.
Stan: OK - let's jump to models. As we look at examples we can classify...
Question for Tom regarding the email he sent out
Linda: Can I ask Tom a question about email he sent out?
[email (with big and small colored text) - sent out on Oct 24, 2013]
Linda: Tom - in the first email you sent out, you said an entry is a collection of one or more... Did you mean one entry is a collection... or are there more than one entry?
Tom: We call what is an entry or statement... Would be a panel or Blood Pressure... together...
Linda: Because I also saw... includes an observation or set of observations...
Tom: A new draft might do that, but... called observation-time on entry... an observation with a time... So that gray [color] statement should say... I am afraid you caught me a bit on the.... So magenta [color]... is... So not vital signs in entry, but... Example: Heart Rate - different types of information about the heart...
Linda: Yes - 2008 13606... Entry [reads]
Tom: So - saying in words what we do in openEHR, but we have more modeling... Whatever gets thrown at it...
Linda: Could be one observation or more than 1 observation, but if... then no way of separating observations...
Tom: The way I understood... the various analytes of the test would be in entry. So your question?
Linda: Querying entry... If have an observation set... sometimes when query an entry... observation may be... But if entry is observation set, then path is further down into entry... Depends on if single or set of observation.
Tom: You could put a bunch of elements under there... Never really a problem. Depends on what archetype looks like... Cholesterol - LDL, HDL... 5 data points. Could report back... total... or whole panel... So that approximate structure - is the real archetype. So - could generate that type of structure... parent and 3 children... Cholesterol (entry) - LDL (cluster/element), HDL (cluster/element), Total (Cluster/element).
Tom (cont'd): So the ability to query... will be exactly the same... run-time consideration... Could get just systolic or systolic and diastolic... That is how openEHR works... Not saying that is the only way...
Stan: Not sure I understand yet. So - the top thing - not only an empty panel with 3 parts to it... And my question... Linda showed a second thing - HDL entry.
[shows on screen]
Tom: You can imagine... We'll pick total... Still find at same place...
Stan: So the archetype - it is part of query path?
Tom: ... Yes - right.
Stan: So if something can appear in more than 1 battery, not really archetypes... So cardiac risk panel... C-reactive protein... Would you make another archetype for that panel?
Tom: I am fairly sure... will have one archetype for cholesterol and one for... and other... The cardiac panel will be a... So I'll go back. When you get cholesterol one - will be inside... with a bit of meta-data.
Tom: So - a composition archetype... called Lab Report... That cholesterol is technical... metadata attributes at IMH... To make the lab report will involve lab report composition with lab report and... That cardiac panel is a specific kind of lab report... and even if had HDL... one protein and... A bunch of entries with 1 child... So if Linda kept doing what she is doing [shows on screen], then when built template, will chose the HDL and protein and other item that make sense.
Stan: So a given terminal item will only be a member of 1... member archetype?
Tom: Depends... So - LDL & HDL... would be together. But if want to put together with protein which comes from another test... then could be a bunch of entries under composition and each entry would have a small number of items. Linda is almost building the... but I don't understand the cholesterol.
Tom (cont'd): So, as you know, we don't have entries under entries... So if you stop there... That chunk of stuff in the middle... it is structurally the right kind of construct.
Stan: Would it have been legal to have entry level archetypes... LDL...?
Tom: Yes - for those 5 things, could make 5 separate archetypes... but not be efficient... because can already use (?) on its own... Toolbox called (?) - out of total blood count.
Stan: If archetype that contains HDL and LDL and other things, then the name of that archetype becomes part of the path... If I did it with cholesterol, with multiple item entry... then I would not make another entry level archetype that also contained that?
Tom: Yes - not have to. As you know, I have calculated... The discussions we have had - whether it makes sense to do the governance of HDL and LDL and... In CEA-land...
Tom (cont'd): You are right. You will get the cholesterol... cholesterol... node... with us this is what we want... How screens get filled and... our design approach... We like this because if someone says "give me HDL", does not matter [about] the template... it will get it.
IMH - Anything labeled as statement is query-able; must be able to be returned if asked for
Stan: We have the same thing... clinical statement... Anything we label as a statement is query-able and must be able to return by asking for item. So can search for Hematocrit... despite... So things in panels... responsibility on implementation to say... So you can ask for Hematocrit despite where comes from... Battery is not part of path-name... Rather than forcing archetype collection as part of pathname...
Tom: If you are querying for HDL, not based on terminology? You could have Blood Pressure on (?). But could also have in some sort of Hypertension goal... Your system... I can't remember.
Stan: No - just search for a Systolic Pressure. Just say - is an observation - ask for Systolic Blood Pressure or terminology, LOINC code for Blood Pressure... or general model name... or name of Systolic Blood Pressure model. We can retrieve without regard to what...
Tom: Could you (?)
Stan: Yes - a Blood Pressure goal model is different from...
Tom: So - parent model is acting like a container or context... underlying data points. Your... model is... Is the same for us, but we have more intervening nodes because have modeled more... context structure...
Stan: No - it is not willy-nilly, arbitrary in terms of... We don't... reference model...
Tom: No - I meant to say - not in Reference Model, but based on... So the Reference Model would let you do anything.
Stan: Yes - start with Ref Model... Make generic Observation - the lab or atomic observation, then... lab observation... and those become the parents. And it is inheriting the context.
openEHR - chose to hard-wire more
Tom: In openEHR model, we chose to hard-wire more.
Stan: And trade-off is that... How much do you want to hard-wire in... The way that you've used what is in Ref Model as a cut-off of what software has to... So you get great value out of knowing identifier and certain other context info. So your tool dealing with entries knows more about context, but... In our way, the service or internal functions that operate on lab data... They would have to know the model... at the... A model that is a model or 2 or 3 about the Ref Model. So we don't take... have to know the Ref Model as...
Key thing of CIMI - to make the constraint formalism work for whatever style of modeling
Tom: That is because you...? You designed into... The key things of CIMI - to make the constraint formalism work for whatever style of modeling.
In a way, is a question of style - how much is in Reference Model
Tom (cont'd): In a way is a question of style of how much is in Ref Model. We have been more heavy-handed to prevent programming error. CIMI is different... already exist... The existence of... does help modeling because they don't have to model... What they see on screen, they can build the....
Stan: And I agree - we have had the same trouble. People will invent it if...
Tom: I think CIMI group has to take seriously or run into problems... Let's say - because clinical people will spend time modeling what not need to model... openEHR... Question is - Entry or Composition or bother with... Could keep composition and entry... The question...
Linda: Like Mark Shafarman used to say - "It's important to be able to identify the smallest indivisible unit of information about a patient that is meaningful", so then you know that the data elements within this unit of information are there to qualify or add more details about the same piece of information.
Linda: So in CIMI - the patterns would define that...?
Stan: Yes - one of the things that is a requirement or something we need to do... Recognize what is query-safe without resurrecting the thing about statements. I am not sure about what... Rector meant by the smallest bit of information because... modifier is still information. I would say smallest bit of information about patient. Query for and be safe knowing that is statement about individual statement.
Tom: Pattern archetype... Question is not what is in Ref Model. It is what is standard substrate... If create (?) and distribute modeling guidance... The result is a more locked-down Ref Model... But at end of the day, I don't think it makes... difference... I think real question is - what is normative layers of CIMI... and it is those normative parts that decisions have to be made...
Tom: So if we put out minimal Ref Model, then people would translate... and won't be transformable...
Stan: There is really a fundamental difference with world view between what I and 13606... So 13606 originally intended to have Ref Model. And then part 3(?)... would show a level of pattern above the Ref Model... observations or... That is exactly the choice. No one is saying "We don't need to know where context is or no need for stable pattern". It is - how much of that do you put into Ref Model and how much inference... as required patterns above the Ref Model... And I think we need to take a stance or...
Stan (cont'd): I realize that... world view. Dipak was assuming 13606 would have Ref Model and... But not get to... because... But assumption was you would put out into the world and a 1000 flowers would bloom and have great diversity. But my view... what CIMI wants to do... Yes - you can model it that way... pre and post-coordination... But we are saying - this is the style we are using for interoperability... So I am not putting so much into archetypes or... Because will say... this is the one we will use... The things the.... sorted out in an editorial process, and... Different world view. I am setting up a framework where people can create models and not talk to each other... vs. you allow... set-up models and adjudicated and...
Tom: That is approach of what openEHR... clinicians can do... single data-point and can reconcile... I still think for these models - that is the right approach. When you think of open source - you would think that made it better for standardability... but did not increase interoperability. I am all for open source, but... So if you... I don't think it will work. I think all need to get together and say... So you show Blood Pressure... is... agree. I would advocate for that way to work. So if that was the assumption, then tooling and modeling and... how do you run a modeling session...
Tom (cont'd): Sorry - need to go.
Linda: Thanks for joining.
Stan: Yes - Thanks.
Gerard: I just joined... the time switch (daylight savings time]. I was sipping coffee over the last hour.
Stan's bias: to put less semantics in Ref Model and more semantics in Archetypes
Stan: My own bias is to put less semantics in Ref Model and more semantics in archetypes... because the broader (?) then the less commonality in the context. In openEHR... required elements like subject identifier or person identifier then that might not always be true... identified by study identifier rather than a person... Coming up with situation where required fields and context were difficult to fix. If thinking that this was going into EHR, then could think of... workflow... patient... It is that level of workflow that allows you to fix the context... The goal we have to reuse the models... models for representation for Decision Support Logic and... clinical trials. Also - big difference between if collecting data through... or if natural language processing. So pushed... have less in Ref Model and more in...
Linda: I agree. By putting all clinical information in archetype, it allows us to... So if Use-case... then... over time... lots more of Use-cases will emerge... flexibility.
Michael: I agree with you... and the other reasons not to include all those in Ref Model because if update...
Galen: I tend to agree. A year ago, I would probably have disagreed, but now... In the (?) discussion with Dave Carlson and Michael van der Zel... strikes me that they are on same route.
Dave Carlson: Archetype Modeling Language - to be Ref Model independent... My bias is data-type Library as part of (?) and then given Ref Model... The first thing to do is... based on Ref Model... So Stan - CEM - be able to... So I agree on simple Ref Model with... and derived (?) types.
Stan: I don't know if that is a requirement but is a principle... To guide us...
Linda: Should I document, Stan?
Principle - Ref Model would have no Healthcare Semantics; implemented in archetypes
Stan: Yes - The principle is that... the sort of... most radical statement would be that the Ref Model would have no Healthcare Semantics... But should be implemented in archetypes above the level of the Ref Model...
[Linda writes this down on screen]
Stan: People should be able to argue.
Gerard: I hope Ref Model... generic so can fulfill all Use-cases because... extensibility...
Stan: Yes - want Ref Model to be expandable, but... So say have Ref Model that did not have folders, but then add folders... not have to do with Healthcare, but how to organize... So... expansion... adding... or even genetic...
Linda: So - wording... Should be able to support Use-cases.
Stan: I think the Right side of this example is... But the Left side... does not exist because the Hematocrit is only exist in the complete blood type. So you have an option of... So if follow openEHR style, would exist as CBC or as independent element, but would not exist as... Downside would be... The implication is that if you create models in style of right-hand-side, then Complete Blood Count (CBC) is in query path of Hematocrit.
Linda: Would be reasonable to add to requirements that we require a test to be able to appear in more than 1 panel?
Stan: Yes - but... By templating... composition... would contain... I would make the battery... arbitrary battery at the level of composition... complete blood count or... other archetypes I would include in that composition.
Linda: So one approach is to make CBC a composition, and then (?) because a... but not consistent with CKM. Other would be lab result - a super (?), and then limit it down. So all tests at first level of nesting... Can't group in (?) level of testing. I am not sure of what Tom was... CKM... I can see how an Uber panel would work, but...
Compositions cannot contain Compositions, but can contain Sections and Clusters
Stan: Yes - I think to... but... Can Compositions contain other Compositions... in our current CIMI Ref Model?
Sections can contain Sections
Linda: No - only Sections and Clusters... Section can contain Sections.
Stan: So I can do multiple levels... section in section and... template on that pattern?
Gerard: As many levels as you want.
Sections cannot have Data Elements
Linda: Sections can't have data elements, so if you want to have (?) you must... So becomes a special entry.
Compositions contain Sections or Entries, but not Elements
Stan: Does composition only contain other Entries?
Linda: Sections or Entries - but not elements, so to create document header you need to create a (?) entry (?)...
Stan: So what we ought to do is make examples that describe those different choices. Not surprisingly... 13606 and openEHR would allow more than one style to be legal. When Dipak sent out question of what to fix with 13606 that is what people not know... When recurse... whether entries in... or ... so even if both to be allowed. I think we would develop only one pattern for doing that and not developing 2 different styles...
Linda: I am wondering if have break... So first using Sections and... Second - Templating the Uba-Model, which I mean templating the...
Stan: Yes - would take us to next level of discussion with Thomas and Gerard and maybe Ian or Hugh and Heather... Because sometimes Thomas knows... and sometimes Ian or Hugh or Heather would be familiar with... Need to make sure we ask broadly and get input.
Linda: I'll leave the (?) approach as well. Seems to be the way people model... but also leave the other...
Gerard" That approach - legal according to 13606... But I disagree. I don't want to see panels at the entry level... and where openEHR and... 13606... Lot of simple situations where you want to have one system doing its thing. Archetypes for querying and storing... but where think about interoperability... then rule, requirements need to be in place...
Stan: OK. I think that advances the discussion to... If we can fill out those explicit representations... styles... with our understanding of openEHR style...
Gerard: The 2 styles possible, but would be OK with me.
Stan: Do you want to say?
Gerard: One is where you define the panel in a (?) and the other is (?) panel and use semantic links.
Stan: One of those is option 2 - we will come to next.
Gerard: ...have to think about... best patterns... generic use-case.
Stan: I think... option #2.
[Linda shows Option #2 on screen]
Stan: So this would be the link-association method. So - say the battery is in an external thing... Say... the lab test is outside of this model... Have some structure... not necessarily outside, but... would want to model...
Gerard: Outside of the... but in one of the services... external...
Linda: In that case, context on individual entries....
Gerard: Yes - individual entries.
Stan: Even if panel is outside of patient-record, CIMI would still want to model... Even if external... Does it look the same... even though... as we model on Left-hand-side... would look similar even though... Would not need to be a Link to patient... just a set of pointers to individual observations, and not know patient until de-reference the pointers?
Gerard: Yes - is one way. But... define panels that way and... I think... roughly the same... You define a panel in the section or... But the record only individual records of that panel... Make observations... but you know what was the order.
How to Represent Information at Panel level; "Panel Interpretation"
Stan: Last time we talked about our 2-way example, a question we had was... What if I had information at the panel level... had a flag that said this panel was normal rather than that each individual was normal. Did you think how you would solve that problem?
Gerard: Only if... was an entry. Only if normal or abnormal.
Stan: Linda - go to 2 (2a?). So Gerard - you are saying... in thing on left-hand-side, we could add in panel interpretation?
Gerard: No - not what you want. Just a lab test... not a panel.
Stan: If on left-hand-side, would not be...
Gerard: It would be duplicated on...
Stan: That is a rule?
Gerard: I think... don't have... If have Links, then will work.
Stan: So - below test Link we could put "panel interpretation" and that would work.
Gerard: And I could...
Linda: Do I need to make changes?
Stan: If add one more element that says panel interpretation... Test name is same... but is more explicit... Call it panel interpretation or something...
Terminology: Compound Statements preferred over Entries in Entries
Stan: OK. So let's go on to Option 3. Dipak said in Sydney - if we go to Entries in Entries, which is... this... So he said - don't call it Entries or it will be a problem forever for people to understand. So is really statements...
Linda: Compound Statement?
Gerard: A new class in Ref model.
Stan: Yes - would be a...
Gerard: Entry with special features... rules...
Stan: So where it has item, could be a statement or collection of statements, and reverse and composition and... would go away.
Gerard:...are there 4... And the function of the thing here... compounding entries... not the same.
Stan: Probably still need sections.
Linda: I think would help panel... so move down...
Gerard: Theoretically is an option...
Linda: I still have a question whether ADL can still support the derivation... parent... because I am fairly sure...
Definition: Asterisk on slide means "derived"
Harold: So does asterisk mean derived?
Harold: Put on slide. Should we be doing an element by element basis or should there be a block that has subject date... Derived or references not really matter...
Stan: I don't understand.
Harold: Here we are saying the Hematocrit info subject is derived from... CBC information subject. Let's assume the content-subject is more than subject, date... Would the (?) etc. be derived as...?
Linda: I would have thought... separate derivation...
Harold: So don't have a (?) ...contextual that are inherited?
Stan: Yes - any context applied to item, we (?) in item... and if item... any level above... it gets inherited.
Qualifiers vs. Context block
Harold: So don't have context block?
Stan: We have qualifiers... not same... Say I... put sodium and potassium in panel... those 2 things are (?). Could be the instrument that was used... Are context, but not saying... Are saying those qualify... our adjective or adverbs... There is a different relationship to saying... to do CBC and relationship between Hematocrit and Hemoglobin... If that makes sense. So no context block. Context... all be labeled as qualifiers because supply more information, but different from being other items in collection. So Linda - Hematocrit-entry and Hemoglobin-entry - I would say statement instead of entry?
Linda: Simple statement?
Stan: Simple or atomic statement. Those things might be the same as entry...
Linda: I agree. Entry as defined in 13606 can be an observation or set of observations so this does disambiguate...
Action Item: To get review by Tom, Heather, Ian by next week's meeting
Stan: We furthered the discussion... We are getting closer... I think we will make a real effort to get review by Tom... and Heather or Ian before next week so when we come back next week... what we see as advantages or disadvantages...
Gerard: The options are correct and I can't think of more.
Stan: Well - good - because you usually think of options. Anyone else think of options?
Dave Carlson: Current slides... Compound Statement... is it necessary to distinguish compound from single statement? Blood Pressure... If have vital sign that contains Blood Pressure panel then compound statement contains compound statement.
Linda: I think we need to allow...
Atomic Statement - the smallest meaningful bit about a patient
Stan: I agree... Compound statement can consist of atomic or compound statement... So atomic statement is query-safe. Is the smallest meaningful bit about a patient...