CIMI Modeling Taskforce - Meeting Minutes

Tuesday 3 Apr 2014 @ 20:00-22:00 UTC

Attendees

Stan Huff
Linda Bird
Ian McNicoll
Harold Solbrig
Steve Hufnagel
Jay Lyle
Patrick Langford
Thomas Beale
Sarah Ryan
Daniel Karlsson
Deepak Sharma
Eithne Keelaghan

Draft Agenda

New call time?
Next face-to-face meeting in Phoenix May 1-3
Review of Thomas' proposal (Slides)
Review of Rahil's proposal
Draft - Steve Hufnagel

Detailed Meeting Minutes

Stan: I sent out draft agenda - hopefully you can see it.

[Stan reads the Draft Agenda]

Consider Changes to Modeling TaskForce Meeting Time

Stan: New call time - No participation from Australia or Singapore or... So thought about a new time. But Linda is here and Steve Chu wants to join - so maybe... What time is it in Brisbane, Linda?

Linda: It is 6am in Brisbane.

Stan: Is this time tolerable?

Linda: Yes - barely.

Stan: So will you have a daylight savings time?

Linda: No - UTC all year round.

Stan: OK - So we're good then.

Linda: Only Melbourne and (?) will have Daylight savings time, but no one on the call from there.

Stan: OK - we'll keep the same time for the meeting, then.

Next Face-to-Face Meeting in Phoenix on May 1, 2014

Stan (cont'd): Next, Face-to-Face in Phoenix on May 1^st. Draft agenda - from Virginia Riehl. It will probably be 4-5 days until we get the draft agenda out. Sorry - I know Daniel and Harold will be in Copenhagen and will try to hurry to the meeting, but will miss the first day. We will try and change the agenda so that we will talk about things they are more involved in when they arrive. Questions?

[No Response]

Stan: So - to summarize, we have been talking in more detailed fashion about panels and entries in entries. And changes to the Ref Model that would have to occur for that. Almost made a decision...

Action Item: Stan to Make Examples of Composing Complex Objects from Simple Elements, etc.

Stan: I am behind in making examples... in text form... how we would compose, from simple elements, more complex objects... panels... sharing of things at different levels... When do you attach thing to patient, attributes, shared space...

Rahil, Thomas, Ian - Presentations at CIMI/SHN Meeting - how done in UK, in openEHR

Stan (cont'd): We had a presentation by Rahil at CIMI/SemanticHealthNet joint meeting on how they do this in the UK. Also, Ian and Thomas - how they do this in openEHR.

Plan Discussion for Today and Next Session (2 Sessions) - then Make Decision

So we said we will have 2 more sessions. Then take a vote - and the majority wins. We can probably talk another year about this, but my preference is to start to make content, because we probably won't know... for another year... before we really understand the issues... So today and next week - then make a decision. So - your thoughts?

Linda: Thanks for the update. I wonder if the group has gone back to the original requirements?

Action Item: Stan to send out Original Set of Requirements

Stan: We have specific set of requirements... specific to this set of panels and other work... We have been checking against these. I will send out most recent set of Requirements so you'll have those, Linda.

Linda: Thanks.

Stan: So let's jump to Thomas' proposal. He has made revisions... to proposal 2 weeks ago. We should have someone else display the slides, Thomas.

Thomas: I have to tell you - the Dell (?)6400 - that model - has a (?) causing CPU to choke because it thinks its temperature is going up. I found information on that and put (?) in and the problem went away.

Stan: Good. I'll make you presenter.

Thomas: If this does not work, I will be mad at Dell.

[Thomas' Slides displayed on Screen]

Thomas: So - slide from 2 weeks ago.

Entry - the Reliable Clinical Data Container

[slide #4] Entry

Thomas: My view is... the entries are a reliable clinical data container. It is defined... The information of an entry... can only have data of 1 subject. The timing has to be a coherent... time...

Stan: So - information must be info from 1 person's record? But could be for History data, but for this subject... or baby's blood type, but store in this person's record?

Thomas: Yes - fetal heart rate and mother heart rate, but would have to be in 2 entries... In same mother's record.

Linda: [Can't hear] ... as opposed to...

Thomas: The subject of the information implicated all the way through...

Steve: Should be as assertion as to the metadata. The Blood Pressure was taken on certain part of the body with certain position, i.e. prone. That is done with SNOMED.

Thomas: Yes - this is not a formal presentation of that.

Steve: OK.

Thomas: It is useful to keep inside peripheral data content - data items for understanding... A different set of data items... is content-dependent. If you are talking about physicians or... If talking about treadmill test. That kind of content has to be marked in a different way. The IMH way of doing this is more flexible.

Stan: Can you say... the purpose of having entry as part of the Ref Model in openEHR? If the idea you were trying to capture... Define the essential nature... the level of entry in openEHR.

Thomas: I think... they are unavoidable... ontology... To make sure those ideas are solid. Entry or some unit of information has to know what epistemic information... In openEHR, we have... different epistemic... An evaluation... prognosis, or whatever... What the course of the disease might be... opinions... instruction... what should happen... We did this a certain way in openEHR. We don't propose that way for CIMI.

Ian: In a sense, is a RESTful situation. If you look at FHIR, things are pretty granular. You have to be sure you are dealing with correct subject. If going to have any kind of modeling architecture... unless have a million different ways. You need to pin some of this down.

Thomas: Yes - 3 things. One is subject of Entry. One is epistemic context. And the 3^rd... Entry should match up with event or... That is where (conjunction?) of timing and... So - if 2 different events, 2 consultations, should not be in the same entry. There are book chapters on that topic. The 3rd - have to be an entry level...

Stan: 2 more questions - if I understand this slide. So, example, if a person has a transfusion reaction to blood transfused to them, they do ABO-Rh Blood Testing. They look at Antibodies. The blood type of patient in 1 entry, and retyping of unit - blood transfused - has to be in different entry. Is that right?

Thomas: Yes. Otherwise would get mixed up.

Ian: I have ideas of how we could tackle that. For example, in openEHR, the ability to reference part of an archetype from another. So, goal... archetype from weight archetype... You are reordering the same type of information in your blood-type example... So - is a use case for reusing... Dipping in below level and using a fragment of that.

Able to model with CIMI modeling language even if not modeling in CIMI preferred way

Stan: I also want to introduce... An additional requirement formulating in my mind. Our Ref Model and our modeling language... I want to be able to model with our language even if not the CIMI preferred way. So able to use the same language where people who have modeled in a different way. So can put both into same... So can automate data transformation. So I am planting that as a seed.

Thomas: I think you're saying - we should make model lax enough to accommodate... outside models being converted into inside models.

HL7 Null Flavors supported

Steve: So approach you are suggesting support the HL7 NULL flavors?

Thomas: Yes. Null flavors are done the same way. In openEHR, we just... I think most people...even if you ask Graham, I think... element... value... Null flavor have to be set if...

Stan: The goal in CIMI is to represent the flavors of Null full outside of data type. So not a structure inside of the value... I think Thomas said this is a better way to do it.

Thomas: Even Graham says it is better. So probably will be some type of discussion of how to use... Graham agrees with a lot of the criticism.

Thomas (cont'd): So the next thing I have is to say what is the Cluster.

CLUSTER

[slide #5] CLUSTER

Thomas: Clusters are chunks of information that define structure and value ranges. Clusters can only occur within other Clusters. I am suggesting here that Clusters are not archetypes... I f we want to, say that only some Clusters are archetyped... So all kinds of data groups...

CLINICAL DATA GROUP

[slide #6] CLINICAL DATA GROUP

Thomas: Some Clusters - you do want to archetype them. Medication... Description of Pain... Things to do with diagnostic types of information... So, maybe makes sense to call a certain type of Cluster a Clinical Data Group. A specific type of Cluster that is intended to be specifically archetyped... The epistemic... finest grain.

Thomas (cont'd): Now we have not talked about... the well-known way of distinguishing Blood Pressure from target Blood Pressure or... goal...

Ian: I think Stan's example is exactly that in terms of Blood typing.

Thomas: Please explain again.

Stan: You are putting outside? To me that is one type of epistemic.

Ian: In IMH models, would you regard the (?) Blood type and (?)... can't remember... different subjects or...

2 Different Subjects of Care, but same Subject of Record

Stan: 2 different subjects of care. But the same subject of record. Both records I want to store in Stan Huff record. But one is my blood type and the other is blood to be transferred into me.

Jay: So - epistemic status - are you suggesting you can change this or at (?) level?

Thomas: We have to know what the epistemic status is of the information we've got. So Systolic and Diastolic, or the bits of a device... So all would agree... So putting on a Clinical Data Group (CDG) level... So could have 2 CDG's in 1 entry... I don't know if it is a good idea, but... We have to be clear on where it is... is the thing that destroys querying, or, if you get it right...

Linda: I am not clear on example or Use-case of where have 2 epistemic status in entry... And is it not... or is this the binding to SNOMED CT?

Thomas: SNOMED has a context model that tries to do this, but... Your first statement I agree with. I looked through... Ian might know of examples.

Stan: There is an example in Lab Data... actual measurement on patient and then the control measure.

Thomas: Yes - is a good idea. Lab data is not the only place where can hit this..

Stan: Actually - that is just another example of change of subject of information. So I retract that.

Thomas: Well...

Ian: I think is a subtle distinction. We need to be able to nest items that have different subjects or different epistemic status.

Thomas: You never want to mix that stuff.

Ian: Whether we decide epistemic status or... We still need to be able to nest different clinical groups with different epistemic status.

Thomas: I have never seen...

Ian: Stan just gave you an example.

Stan: That transfusion... has information about patient blood type and antibodies and... and antibodies in unit and... transfused. We would store in the same logical record in the database.

Thomas: The same patient record?

Stan: A collection of things stored as a panel. A single commit for that patient.

Thomas: In openEHR we do that same thing, but do not mean...

Ian: But in Stan's model, these can be nested.

Stan: The purpose of entry is the point at which you attach a logical... to a single patient. And that is what is in an Entry... and not controlled by whether... or whether epistemic status is... But have to be absolutely unambiguous as to whether this is an actual measurement or is a goal or family history or... and have to be taken into account in query. I think you can model where status is as... name or you can... and put inside group. I see both of these done in the real world... Want to be able to make transforms.

Thomas: Normally containment means... When you have markers... So... Boeing 747 does not turn into... So if we want to do a kind of modeling where that kink of nesting...

Stan: No. If put epistemic status at level higher than... then obviously has to be inherited. But you can put a ... together and... Both are valid ways to model this information.

[slide #12] Ante-natal-exam

Thomas: The thing I think will be dangerous is when things... When start nesting that, then you don't know what the meaning is. So if... says is target, but something up the tree says...

Stan: Does not change up the tree, but can change inside collection.

Thomas: Yes - I think you are saying... siblings... they could each have a different epistemic status. And could even have different subject. But I would rather... little trees... Cannot change... Maybe not all agree with that, but we need to work out... Need to agree on what nesting allows.

Need to Agree on What we Want Entry to do

Stan: Part of reason this is so hard is we are trying to make entry do more than 1 thing, and we need to come to agreement about what we want entry to do. And might be different from IMH and from openEHR, but need to agree.

Thomas: The smallest... in openEHR... Blood Pressure... about a topic... situation... event... That has a reasonable amount of backing or epistemiology... Good academic thinking that supports that idea... Maybe we have to have a bit more debating about what we want... to do. Models force you to do what... In openEHR... protocol... if different... Then 2 different entries... No big deal... Some are uncomfortable with that but...

Ian: I don't entirely agree. You can say - need more entries, but hard to explain to developers.

Thomas: (?)

Ian: No - some examples of where to... constrained...

Thomas: Hopefully... CIMI... fix those problems... Make entry do what it is supposed to do without forcing into a straightjacket.

Linda: When you talk about an entry, you use the work indivisible... We used to have requirements on identifying individual bits... comment from Mark Shafarman... How does this proposal address that issue?

Ian: Still a work in progress. But the CDG is a query... Lower level... A systolic or diastolic... and that is what you want to hit. I want to query for systolic.

Linda: Could also relate to body structure.

Ian: Exactly. In previous slide... idea that Cluster could not be archetyped... So.. and ... not being query'd on... and we do use them as Clusters. Are saying these are really what you want to query on. The device...

Linda: The individual chunks of data about the patient.

Ian: Yes - it is about the patient. Have to have really clear... Is about the data... not the goal. The name of the CDG... family history... has to be clear.

Thomas: An idea I have brewing in recent times... 2 levels of indivisibility. First level of indivisibility... Second level of indivisibility is... But you do need... patient state... protocol for that level... Chunks of stuff have to be together... Patient on a treadmill... When get down to CDG, the indivisibility is... semantic meaning of it...

Linda: A single measurement... May have same subject and... one that contains the context... and defines individual chunks. So I am trying to work out how it relates. Could model a body structure as CDG...

Thomas: Entry... Defining... entry subject and timing. Encounter... If we agree that entry corresponds to... then can't have Entries in Entries.

Linda: I thought equating entry to indivisible statement about patient?

Ian: I think - yes - compound entry is what Thomas has as Entry. So... Is CDG atomic?

Linda: So is a CDG atomic or indivisible or can you archetype something smaller than that... body structure?

Thomas: ...

Ian: I think that is different between Clusters and atomic entry... Clusters have no meaning.

Linda: So - which approach... as Thomas says... how we define an entry... patient that can be grouped as... or... information that shares a common content? It is all how we define entry.

Thomas: Yes... can have... but not multiple. Personally, I think we should put it back on. We get this problem of nested content.

Linda: So both approaches require the context to be inherited from bigger to smaller chunk.

[I missed a little here]

Real World assumption - Panels

[slide #7] Real World Assumption

Thomas: Data groups in data groups...

Stan: I would say what I meant by panels in panels. I would have said...

Thomas: I think we need to clarify...

Ian: I don't think it matters, Thomas. In reality, these panels are little chunks and sometimes nested.

Thomas: If look at IMH model, sometimes... Talking about 2 different chunks of information. A large number of data items have to do with... So if taking them off the table and saying not have to do with panels, then... time... If I hear panel, I hear orderable and...

Deepak: How is order id possible? Confusing... An order might refer to a... ordered.

Thomas: That is my point of view as well.

Ian: The difference between view of panel is what is in LOINC. Defines what the order panels look like. What we are doing in clinical models... We are mixing this up with orders...

Thomas: So - example of IMH panel...

[Thomas shows example on screen]

Thomas: All have to do with the lab...

Stan: Is useful for you to go on and finish. But this is not the panel... is an order for a panel. Is meant to be ordered, or is a panel used in a result.

Thomas: Is a result.

Stan: But confused about what qualifiers to use. What I meant by panel in panel is the second part, not the first part. Things that are like the example we used.

Thomas: I thought you said... is an orderable thing.

Stan: Yes - but not have to include the orderable workflow in panel.

Ian: I think all are in profound agreement.

Lab Result Panel

[slide #9] Lab Result Panel

Thomas: Under a Cluster... So, a lab result panel is an entry. Has 5 of these CDG's inside... Is one subject... for the whole entry. Primary time. Does that seem uncontroversial?

Stan: Yes - I understand. That is one way of modeling, but it is not the only way.

Thomas: Yes - I am trying to show a coherent way of modeling. There are other ways.

[Thomas shows ADL workbench on screen]

Thomas: Are inheriting from standard...

[I missed some here]

Thomas: So that is the archetype that corresponds to that slide.

Analyte Target

[slide #10] Analyte target

Thomas: Each analyte is a CDG.

[slide # 11] Ad hoc obs panel

Thomas: Blood pressure, Hematocrit, Heart rate - hospital bedside type of context. An entry containing multiple...

Ante-natal Exam

[slide # 12] Ante-natal exam

Thomas: An encounter...

[I missed a little here]

BMI - ENTRY that Needs to Refer to Existing ENTRYs

[slide #13 sand #14] Other Use Case - Reference

Thomas: To do BMI properly, we must understand there is a reference to previous entries. That makes BMI not the same as other. I did not build an archetype to reference BMI. I don't think we have the... in CIMI.

Need Improved Version of IMH's Qualifier Marker Approach in CIMI

[slide # 15] Other Requirements

Thomas: I made a... about markers... Needs to include 2 types... The good thing about doing this... tools can react to this... Can separate out the data...

Ian: The other big reason... it is easier to factor if someone has a change of mind. If you have embedded it, then breaking... People get worked up... Whatever you do, make it easy for things to be re-factored. Minimize the impact of need to re-allocate or re-categorize.

Thomas: Yes - I have been convinced by Ian. He has built lots and lots of archetypes.

Querying

[slide #16] Querying

Thomas: To make querying work properly... we need to hit the ENTRY... and we have to hit the root points of indivisible data groups... There are ways to do this... One approach... Ian is an AQL master - can write queries to do this.

Thomas (cont'd): So - that has taken a lot longer than I thought to go through the slides.

Stan: So - at the antenatal exam, my question is - was it necessary to model it this way with composition with entries and CDG? Or could it be modeled as Entry with antenatal exam? All in one entry called antenatal exam?

Ian: That was my point. Thing you want to look for is Blood Pressure... So blood pressure is a grouper.

Thomas: One thing - people doing different things. At least in openEHR... The entries that are the same encounter, end up in the same composition. Are we suggesting... that we put heart rate and blood pressure... into a single entry?

Stan: Yes - is there some understanding of modeling that says that cannot be done?

Thomas: I don't think it can't be done.

Ian: When I was talking to Thomas, that was in my mind. To query into... independent of...

Stan: Yes - I think that is right... The CDG is essentially corresponding to our indivisible entry. And Entry is what we called a compound entry before. Is that wrong?

Thomas: The most basic definition... When should I create a new archetype? Is it about blood pressure or heart rate? We defined entries in openEHR... This is what we are suggesting with CDG's.

[Thomas changes Ante-natal Composition on screen]

Thomas: What if this was CDG?

Ian: Is odd in a primary data situation. But when things are summarized and compressed, is not...

Thomas: The summary... have to think about...

Stan: Is a different use case. The summary... A different use case. What is the buffer for a query coming back? The buffer is very different and should be defined...

Thomas: Query-return.

Stan: Query return is its own use case. Must think about (specific to all ?) as different use case. I don't like having the Ref Model class used for 2 different things. Collection of things that are... The query-safe characteristic of the patient. In the Ref Model, item is playing that role. Can be a virtual class or collection of things I don't like to have the name of things that are grouping things, like a panel, as the name of things in the panel.

Ian: It depends on if you need to nest them. If needed to nest... Not name, but if need to nest...

Thomas: What is the agreement for saying - each of the things taken on their own? Why not an entry... Does that seem unreasonable? If we say we record things differently if are multiple things than if one thing?

Stan: No - that is reasonable. But - Linda said this and I want to confirm. But the way this is structured... Entry is establishing shared context that is inherited by Clinical Data Group inside it. In different use cases, would want different shared context at levels of entry... I could see a place where people would do different modeling... And CDG... atomic statements or query-safe or... About 1 characteristic or observation about the patient.

Deepak: So CDG - do they have to appear inside an entry? Or can at level of composition - CDG's and entries?

Thomas: Have to be in [entry?].

Deepak: So...

Thomas: Composition in 13606 and openEHR is used as container of entries... for overall encounter... Work done on patient... Not fine-grained.

Nesting of Lab Results

Linda: Slide #12 (9) - How would you do nesting of lab results?

[slide #9] Lab result Panel

Ian: Would be nested in the CDG. So a CDG for WBC and... and 2 CDG's. 2 are nested in another.

Linda: So same CDG's represent compound and some - individual thing?

Ian: Well - query for differential and query for white count and... Are standalone query entries.

[Thomas shows Workbench] - shows example of white cell differential

Linda: I am realizing that some CDG's can be compound. Also - does each entry have to have CDG? I think the answer is Yes.

Deepak: It might be optional.

Thomas: Yes - these 2 ordinates here are... So nothing to prevent that... Is OK as long as query is designed to... No reason you would not do it.

Linda: Would make a difference as to reusability of...

Ian: I do not understand.

Thomas: (?)

Linda: If you use this approach and define an entry with CDG... You could not re-use with...

Thomas: I would not have thought to...

[Thomas shows workbench]

Ian: One of the issues... It does increase the number of artifacts. Makes the dependency problem more complex. I did calculations... BMI and... takes artifacts from 4 to 14 for that simple...

Stan: We are at the end of our time. That is not obvious to me - I don't understand why this style of modeling is more complicated. But we need to end. Anything else before we convene next week?

Deepak: Can we share the slides?

Thomas: I will report.

Action Item: Ian to Work-up argument discussed

Ian: I will work up that argument, Stan, and will try to... the things Linda said in terms of reusability.

Stan: Thanks, and thanks Thomas for presenting. I think we keep learning. But we need to make a decision and move on. I'll do my homework.

Next MTF Meeting - Rahil? Steve Hufnagel?

Stan: And I'll see if Rahil can present next time. And also information from Steve Hufnagel next time.

[end-of-meeting]

CIMI MTF Minutes 20140403

Contents