CIMI MTF Minutes 20140320

From CIMI
Jump to: navigation, search

CIMI Modeling Taskforce - Meeting Minutes

Tuesday 20 Mar 2014 @ 20:00-22:00 UTC


Attendees

  • Stan Huff
  • Harold Solbrig
  • Gerard Freriks
  • Steve Hufnagel
  • Jay Lyle
  • Patrick Langford
  • Joey Coyle
  • Thomas Beale
  • Sarah Ryan
  • Rahil Siddiqui
  • Daniel Karlsson
  • Dave Carlson
  • Thomas Beale
  • Deepak Sharma
  • Eithne Keelaghan

Draft Agenda

  1. Brief report on joint meeting with SemanticHealthNet March 13-15 in Brussels
  2. Panel modelling examples (aka entries in entries discussion) - Thomas Beale, All (Slides)
  3. Cancel call on Thursday March 27 (Stan will be on an airplane)

Detailed Meeting Minutes

[There was no brief report on joint meeting with SemanticHealthNet in Brussles]


Panel Modeling Examples (aka entries in entries discussion) - Thomas Beale

[Thomas referred to the following Link throughout presentation:

http://www.openehr.org/wiki/display/CIMI/CIMI+CLINICAL_DATA_GROUP+Model


[slide-1] CIMI RM proposal: 18 Mar 2014 - Thomas Beale, Ian McNicoll

Thomas: Point is to show what my personal opinion of the right solution for CIMI entries...

[slide-2] Basis of this proposal

Thomas: The first thing - what is the meaning of an Entry for CIMI and 13606 and openEHR?

Entry

[slide-4] Entry

Thomas: An entry is something that can only have one subject. Normally, have the same provider or providers... The Time of entry... corresponds to a specific point or interval in time within an encounter or other healthcare service... Healthcare event involving the patient or the tissue of the patient... OK - that is an entry. Is a fuzzy picture of things to remind ourselves.

Cluster

[slide-5] Cluster

Thomas: OK - we have a cluster. Clusters are chunks of information that define structure and value ranges. Clusters can occur within other Clusters... I am proposing Clusters and not archetypes... Clusters are not archetyped themselves... They can occur within other archetypes.

Clinical Data Group (CDG)

[slide-6] Clinical Data Group

Thomas: A Clinical Data Group (CDG) is a kind of Cluster that can be separately archetyped... Arguably the epistemic status - the data of an ENTRY is all of the same 'knowledge type'... So if we take that approach - see on screen...

http://www.openehr.org/wiki/display/CIMI/CIMI+CLINICAL_DATA_GROUP+Model

Thomas: That contains Clinical_Data_Group (CDG)... The simpler version of this model is that the CDG is just a subtype of Cluster...

[Read from Slide: The 'epistemic status' - the data of an ENTRY is all of the same 'knowledge type', i.e. actual, goal, assessment, risk, family history, etc. So if we take that approach... Could model as Clinical_Data_Group (CDG) epistemic_status. Can be constrained in archetypes or left open to run-time.]

[slide-7] Real World Assumption - see slide

Lab Result Panel

[slide-9] Lab Result Panel

Thomas: Each analyte is a Clinical_Data_Group... We see it as being a self-standing piece of information. So I think the Lab Result Panel is an Entry, e.g. Lab result panel. That panel is separately archetyped.

Thomas (cont'd): You can have a generic panel archetype. Let's say Clinical_Data_Group archetype... Or you can make a panel...

[slide-10] Analyte target

Thomas: You do have to care about epistemic status. We have to care that we have an observation and not a target... We do have one subject... Primary time...

[See Link]

Thomas: If you go to that page, you see all the bits and pieces to make the panel... Hemoglobin, hematocrit, Red Cell Count... We have Clinical_Data_Group...

[Thomas shows "std_lab_obs" on screen... hemoglobin... lymphocytes... red_cell_count]

Thomas: Should be something here that says its value is any count of quantitative... So Hemoglobin, Hematocrit, Red Cell Count... have their own... Hematocrit... element... proportion... So each analyte has 1 of these... groups. So if continue down, you have... like IMH... The panel is an entry... Participation is subject...

Thomas (cont'd): The next bit is slots. The slot to say Level 1 Panel Item... Level 2 Panel Item... generic... to show this panel. The next step is to make a template...

Thomas: Lymphocytes is in the Level 2... Could be a whole separate panel on its own... If you flattened with the tool, you get the flattened template... So... white cell differential... a cluster...

Ad hoc Observation Panel

[slide-11] Ad hoc obs panel

Thomas (reads slide 11): I assume each data group is a Clinical_Data_Group (CDG)... e.g. CDG: systolic + diastolic + comment; CDG: Hematocrit; CDG: Heart rate & character. The panel is an observation Entry.

[Lost connection with Thomas for a while]

Thomas: If you look at the second panel you will see that Hematocrit gets used. So - on the slides, there is a little bit of... to make querying work... There are cases where you can query something more fine-ground than Entry, but you... need to know what the epistemic... of what you are looking for... Have to be able to distinguish between target and... epistemic status... and actual... value of Hematocrit or White Blood Cell value.

Thomas (cont'd): There is a type of querying in... that is the same as we use in openEHR. The essential thing is that you can refer to multiple archetypes... So that one is saying... Asking for... right down to the Blood Pressure. It does not show how the epistemic... We do that in openEHR... It is bullet-proof, but we don't have the flexibility as we would in CIMI. So I would stop there.

Thomas: So - four different ways to do this panel in panel. One: Entries in... where the composition is the panel. The problem is... if we agree with what the meaning of... Then if you do composition...

Thomas: #2 was compound entry and (?) entry. There is a different wiki page for this. That is not very good because forces you to have data in "parts" and "data". I think the cluster-type is... Want to have a panel... Is an ad-hoc panel... Archetype groups of things that can occur together. The bits and pieces that make up a Blood-Pressure - could be a Clinical_Data_Group.

Thomas: Questions?

Stan: This seems to me to meet the Use-case. Some of the things we created... Whether you put Systolic and Diastolic in the same data groups... If you did another depth beyond complete blood count, would that be... recursion?

Thomas: Be more precise?

Stan: Not made clinical sense, but is only for discussion. I have CBC and differential and each of those are entries and I put in a composition... and if I wanted to include in prenatal exam, then...

Thomas: Then I think we are talking about a number of separate things done over pregnant woman visit... An entry for vital signs... An entry for... fundal exam... physical exam of some kind... A bunch of entries in a composition... In openEHR... each form a separate entry in composition. In openEHR, the composition is the... of the entry... So... would be a couple of Blood Pressure samples in there... taken at 12:05 and 12:10... Would be different for auscultation of the chest... and different person... Not what you are doing at IMH...

Thomas (cont'd): In hospital setting... every (?) thing written down seems like another entry. I would say... chunks in which you can make... and it might be information visible on the screen until a button puts the whole into... Could be composition with one or more entries inside it.

Stan: Yes.

Thomas: Simple answer is composition with entries.

Stan: It may be OK, but my interpretation of that is we don't think you need a higher level of recursion.

Thomas: You can put (?) if that is what is wanted inside the entries. I don't think we need more abilities to do recursions.

Stan: I was not thinking of sections and clusters, so that is more flexible.

Thomas: One question is... what chunks of information need to be archetyped as meaningful data groups? If you put a meaningful data group into a (?), it makes it easier to model. So analytes... into Clinical_Data_Group. If you look at pain - has bits and pieces. I would expect to see it as within a Clinical_Data_Group.

Stan: I think it does not have to do with Ref Model or Clinical_Data_Group... although it does a little bit...

Thomas: I can potentially show more examples so people can see...

Stan: Let me look at your examples a little.

Jay: Was there a requirement that elicited this as opposed to (?)?

Thomas: The indivisible compound entry... does not do in a nice way... I will show you...

Entries in Entries - mixes up 2 Needs

Thomas (cont'd): The CIMI model needs to say... this is what a (?) means. As soon as you put entries in entries, it mixes up 2 needs. 1 is... other pre-defined groups of things. But also - the context... You have context repeated all over the place with entries in entries...

Thomas (cont'd) I realize that these models take some staring at before you realize... They are all online... and the workbench... I think Harold has all those archetypes running under the new workbench.

Harold: Almost all - there are a few errors.

Action Item: Thomas to build more archetypes, including antenatal

Thomas: I think best way to solve is for me to build more archetypes. I did not build the antenatal exam, but I will. I don't think it is controversial.

Stan: I think the heart of the question that Jay asked is... Why do you prefer this to the Entry in Entry? You had a collection of entries or an item in Entry... and if you made the rule that either one of those had to have a patient... seems simpler.

Thomas: Each of those sub-entries could be a different patient.

Stan: No - you make that rule. Has to be the same.

Thomas: So - rules outside the... that the tools have to know about?

Stan: Not sure why. If you make patient an element in entry.

Thomas: If you archetype an entry... A subject... Maybe you can force it to be a patient, but not the same patient. Although you could, but... not simple... Would be a downside since is a complexity.

Thomas (cont'd): Another... on page... My original goal was to do these models and see what the consequences are.

Stan: As I look at examples... is a question of... The way you made Blood Pressure seems asymmetric to the way you made analytes.

Thomas: Yes - I agree... and is reality... I think lab analytes are a special class of things. They are all the same thing, but measure a different property... They all are the same "shape"... There are focal and then peripheral things... But as soon as you are out of that... the same.

Thomas (cont'd): But auscultation and... It is easy to find data points that don't make sense if separate archetype...

Stan: Heart Rate... Systolic... Diastolic... Would see... as counter intuitive.

Thomas: Never use Blood Pressure... to... But if look at auscultation cluster archetype, or pair or... lots of things... You might reject how it is being done. But for CIMI - what objective criteria... I think analytes... Not make sense to me to separate things that don't have clinical meaning on their own.

Stan: I think we have the same view. I agree. Allergies, reactions... But I don't see making systolic Blood Pressure different from Heart Rate. It is in the eye of the beholder.

Thomas: I would not argue clinically, being an electrical engineer... Someone told me or I read that Systolic and Diastolic as used now may die out. But 2 measurements of different phases... Clinically - systolic and diastolic separately... arterial pressure as an archetype and pulse pressure as an archetype... I would not argue against.

Stan: I would say... the other question comes back to... and maybe... I mean... this model, I don't think, doesn't have an indication of what things are query-safe... are the measurements and the qualifiers.

Thomas: Should put the qualifiers... The way you see on my screen, all the same. If we had a code for qualifier... If was in the Ref Model, we could... end up as you have in IMH. So as soon as all agree, I could stick in... I could show how would look close to the IMH one.

Stan: So - down here at bottom you have... Why this change to the Ref Model to include CDG and Clusters? That is less disruptive than how people normally think about openEHR... rather than Entries in Entries?

Thomas: Seems to me... if Entry is an Entry, is easy to understand. Seems to me to be clearer than context all over the place... And if we agree... that is where you go for structure... Seems to me to be clear.

Stan: Back to the alternative. If entry had patient in it... not saying a single item or 1 or more... So no ambiguity about patient...

Thomas: OK - maybe I have done the modeling of that in a way that you did not expect. So, BMI... I did it where panel was a compound entry and Hemoglobin, etc., was an indivisible entry.

Stan: So indivisible entry could have a patient. So collection level could conflict?

Thomas: Yes - So if you go on...

Harold: Stan - can you share your screen?

Stan: Yes.

[See screen with CIMI Clinical_Data_Group]

Thomas: So - scroll down. You can see compound entry.

Thomas (cont'd): We have to remember that CIMI models will be converted into... and out of other models. So if I have 13606, I would... with a large library of CIMI archetypes... Could be hard to write. That is why I think... Because doing model transformers... If had a bunch of people making... makes the conversion process hard.

Thomas (cont'd): What I can do is upgrade that model so is a more copy of CBC. And I can add the... which in my mind is composition containing entries.

Key thing is to be clear about Purpose of each Modeling Element

Stan: I think your statement is right. The key thing is being clear about what purpose each of modeling elements is for... Cluster, Element, Entry and Cluster - what each does for us. Goes back to your slide set. And at its most fundamental level... Entry establishes the connection between a particular (?) and models and a particular subject. Once you go past patient... becomes less clear... why forces it to have a common time.

Thomas: Assumption would be... Don't have disparate... entry...

Stan: And I'm truly talking because I think there is a part of this that I get glimpses of, but... bigger pattern than we are seeing. You have things about Blood Pressure that have relevance - the kinds of things measuring, absolute range, normal flags... The assumption is that that model can be applied to many patients and used in clinical care and in clinical trial. Can be used in any quality measure. And... you want to include in (?) that has that... This is a measure on patient.

Stan (cont'd): So a Trial structure... You know is trial subject A, but do not know it is Stan Huff... If I have a worry, it is that we are assuming single use case that requires a patient.

Thomas: We have a subject, but the identity is flexible. Could be a (?) or a person. Does not have to be an identified subject.

Stan: that means you will make distinction in archetype, but end up with identified subject vs. non-identified. If want consistent, the patient data type would be different from clinical trial ident...

Thomas: Other?

Stan: Yes - would be a clinical trial id-type and...

Thomas: But I think would work because... Is the concept of Entry in and of itself problematic for trial-data?

Stan: I don't know, Thomas. Some of the things we talked about... structural and data-type... vs. clinically relevant to the context. That is where the value comes in. Should patient show up as entry or as the next... higher or lower or... the type... I derive from a cluster. Because I can assume since I am working on EHR data. So I can include rather than have it part of model.


Requirements: What will meet your requirement the best?

Rahil: I just wanted to say - if possible to put modeling approach to one side and think of what we are trying to do. So - what want to record at each level, and what want to put at each level? And then think what will be the best class for each bit. The same requirements... So one approach would be entry in entry, and other... So - some 3 or 4 options. But if we know the requirements first... then not get caught up with modeling style. It is difficult to understand if what you wanted was met in some manner looking at modeling style.

Thomas: Yes - as you say... not drawn out in a non-committed way... Someone write down some models... Third thing is epistemic... There are three things that need to be understood. If anyone has the energy... I didn't offer because I don't know if I have the source models. I just have what is in my head.

Stan: A good suggestion. If you make a representation that is not in formalism... You are showing physical relationship and... So you could say... If we did the Ref Model this way, then... I am getting confused. I was thinking... If we did indivisible and... composite... and if we did Clinical_Data_Group... Is that what you are proposing, Rahil?

Rahil: Yes - would be nice to capture on sheet of paper - what you want... Forget about the model. So - Stan has the requirement... How do we... meet it? Which will meet your requirement the best? All those things... How to represent? How to represent your data the best way?

Stan: I have something close to that already, so would be easy to do.

Rahil: If you send that format, I can have a go at it as well. Thomas has already done... but some of the other, I could have a go at. Would be interesting... Requirements... Would be modeled differently by 2 different modelers... Would be interesting to see how different. If same - that would be brilliant... If works with 2 or more approaches, then...

Stan: A part of me wants to do that and another part of me wants to say - we have discussed long enough. And if obvious differences, we would have seen... So we should go ahead... Until we get into the use of it, won't know... Part of me wants to go back to fundamentals and restate requirements and model... And another says... make content and adjust when run into trouble. Thoughts?

Rahil: The length of time we spent on this discussion is reason enough to think we have not... Not something we can test out... We can continue, but the discussions have... for far too long, so is it worth spending another meeting or 2?

Stan: There was an old New England Journal... Physicians on rounds arguing about therapeutic options. They found that the length of the arguments lengthened as 2 options were more similar. If clearly a superior option, then a short argument. So, there is not a lot of difference here... Similar... What do others think? I don't mind a couple of more sessions to try and clarify... I am still learning. But I am aware of criticisms... The value will probably be content we create.

Gerard: I agree with Rahil. I know there are various reasons to combine things. Might be worth thinking about why clinicians want to combine things... I think is a worthwhile investment in time. A common way of thinking how to tackle a problem... And have too many options to model it. There are too many kinds of things to model.

Stan: Other ideas?

Harold: I think - unless we have a clear path... we had better do something. Would like to pick something and get on with it.

Thomas: My preference as well. One thing I would do is to add in this qualifier-thing because it would make the models... And I could make up a code and stick it on... I could make a version and... The main data points separated out... Is that worthwhile?

Stan: I don't want to put you to a lot of work, but I think we do want to figure out what to do with the qualifiers. But I think that is clear how to do that... not controversial. So should probably figure this other out... Daniel?

Gerard: Daniel left.

Stan: Dave Carlson? Opinion?

Dave: I agree with general opinion of building complete models and learn from experience... Good design... and see how holds up.

Stan: Steve Hufnagel?

Steve: I'm an engineer, so I am with Dave Carlson.

Stan: Sarah?

Sarah: I am in the Thomas/Harold camp... Want to get going.

Stan: Deepak?

Deepak: I think we should pick one and go ahead. But not sure how much time we have... I would choose one and then...

Stan: There seems to be a slight preference for making a decision and moving forward. So, I guess I would propose that we go ahead with what Thomas has proposed and start making models and adding qualifiers.

Proposal to Have 2 Votes

Stan: We could go back and hold a vote. First decision - whether to make a decision. Second - composite and Clinical_Data_Group approach. So I think... I would propose we... need to have a vote. I would propose 2 votes.

1st Vote and 2nd Vote

Stan: 1st Vote: Do we want to pick a model now or do more analysis? If more analysis, then do analysis. If we pick one and go - then second vote would be "which one"? We could have the first vote open for a week. And if have a second vote - then open for a week. So - analysis or making content? Is that reasonable?

Deepak: Can we get indication of everyone's vote now?

Stan: Yes. I have a slight preference for composite and indivisible entries. Thomas - Yours?

Thomas: Mine would be for the other, but my view is... if one's better... objectively... So we throw stuff at them and see it break. So - I would say go with...

Harold: Same as Thomas. At this point and time, I am not tracking all the subtleties. So I am fine with going where you want, Stan. I'll vote in your line.

Stan: Dave?

Dave: I have to abstain. Will defer to your thoughts.

Stan: Gerard?

Gerard: It is fine to look at results and see if breaks.

Stan: Joey?

Joey: Is the preference - modeling now or...?

Stan: No - if you choose a model, which one would you choose?

Joey: Entry within entry.

Stan: Patrick?

Patrick: Abstain - not sure which...

Stan: Rahil?

Rahil: I choose the one where Ref Model is not changed and agnostic. Would be nice to see more detail of why one would be better than the other... But... Ref Model - no changes - is my preference.

Stan: So you are choosing a third option?

Rahil: Oh?

Stan: Yes. Structured Data Groups - changes the Ref Model and composites and indivisible entries - that changes the Ref Model as well.

Rahil: If could sort out where not change Ref Model, that would be my preference.

Gerard: Mine as well.

Thomas: I think that does not matter since... Qualifiers and modifiers and...

Rahil: The reason I say this is... CIMI is not for consumption by various users of model... The more complexity... a huge value the... Because CIMI is meant for others to consume. We are not sure if the way...

Thomas: We know that 13606 and others don't do the things Stan is after... The Use case that Stan is after is a broad Use case. We know 13606 and openEHR don't do this. So... would probably have to be a model change.

Stan: Yes. Sarah - an opinion?

Sarah: I am not technical enough to have an opinion.

Joey: Thomas - with what you were showing today, would everything be modeled in the modeling group... and nothing modeled in Entry? So if want to make a group, would...

Thomas: Panels would be modeled like Entries. And other things... So - archetypes at that level of... But... they'd be mostly Clinical_Data_Groups.

Joey: So if model a Chem-20 vs. Serum sodium... So serum sodium - not in the entry, but individual. And Chem-20...

Thomas: Chem-20 -- a panel. And each would be a Clnical_Data_Group.

Joey: But then not put that in another thing.

Thomas: But...

Joey: Stan - is it a requirement to take away panel and put in another panel?

Stan: My preference, but probably not go any deeper than 2 levels.

Joey: Micro?

Stan: But I don't think of that as a panel.

Joey: But don't you think of... and put in nested structure?

Stan: Could think of Antibiotic Sensitivities...

Thomas: But not a panel until you order it. Even if said... differential... Not 2 panels... one order... Seems uncontroversial...

Joey: But data groups in data-groups can go on forever?

Stan: No - just define clusters and elements.

Thomas: We can do it so CDGs can contain CDGs.

Stan: We are running out of time. Steve Hufnagel?

Steve: I would abstain.

Plan to have 2 more Sessions and then make decision

Stan: So - I am inclined to put a stake in the sand. I will do better examples. Will have 2 more sessions on this and then make a decision. We can probably classify with good Use-cases. But... is that OK? 2 more sessions? I will make more examples as Rahil described. But then... look at and... call for a vote.

[Agreement all around]

Action Item: Stan will get examples out to MTF members

Stan: No call next week. But the following week we'll have a call. So I'll try to get examples out to people within the week. I do want to get back to Gerard's question. The LOINC committee would like to make the semantic tags you...

Gerard: OK.

Stan: We'll carry discussion to next session. Any other?

[No response]

Stan: OK. Thank you. I appreciate your work, Thomas, in doing this. Thank you for your work and thanks to all.

[end-of-meeting]