Stan: Next face-to-face meeting in Phoenix on May 1-3. Will receive draft agenda from the meeting tomorrow from Virginia.

Today's Agenda

Stan: I will present some examples, like I have done in text. Hopefully this will create a better understanding. Then we will review Rahil's proposal. Go over questions from last week's discussion. We want to talk about this being our last meeting to discuss and then move forward. Want to talk about the proposal from Steve Hufnagel. Other things?

Harold: I would like to get to Steve Hufnagel's proposal because it looked interesting.

Review of Stan's Examples

Stan: OK. I sent out a file I put together that showed examples. (Example-file)

Stan: Modifier has similar structure, but provides "change of meaning" or explicit context...information to a model. So, have to be considered in a query. Might say this is family history, so breast cancer is breast cancer in family member.

Stan: And key - we have not talked about this much. It is independent of history. Is useful in connection between model and terminologies... useful. Not necessary for discussion today.

Stan: And then a qualifier. That is, a caveat that my examples are not intended to be complete - just examples. What I am trying to illustrate... strategies I would like to enable. Examples for us to think about - what Rahil and Thomas have made. Indivisible and compound or composite statements.

Stan: Questions?

Observables

Steve: Are the qualifier and modifiers SNOMED observations? Or can it be anything?

Stan: They are observables.

Steve: What are observables?

Stan: So - first examples - have first name. So observable... So this would be LOINC or SNOMED and also string that carries actual value. But is not a SNOMED finding name. Is always an observable or...

Steve: Is that true for qualifiers and modifiers?

Stan: These became qualifiers and modifiers when...

Examples - Components

Stan: OK. First name... Consists of a key... and data item. I created a similar thing that is a PersonIdentifierModel. And then I can make a bigger collection - thing called PersonNameModel. Has a bigger key. But are references back to First name and Last Name.

Stan (cont'd): And ClinicianReferenceModel... Has PersonNameModel and PersonIdentModel. All of these would be Clusters and Clusters in Clusters. Those are the common things.

Stan (cont'd): And to get into Entries in Entries - Systolic Blood Pressure. Key is SystolicBPConcept... for Systolic Blood Pressure. We specify that this is a number. Could be other around this.

Stan (cont'd): Steve - This is where qualifiers come in. They are qualifiers because they tell me more about the Key in the model.

Stan (cont'd): Questions? We are making simple building blocks that are statements. Represent a statement... qualifier... You could query on these because have ... for patient. If you query on SystolicBPConcept, not have meaning. The qualifiers only have meaning when in association with primary (?) they are modifying.

Steve: If you have Null data, can you put a flavor to indicate why?

Stan: Yes - I did not put that in. Would go here. You would have data or a flavor of Null. Would tell you why data was missing.

Stan: Other questions?

[No Response]

Creating a panel, and a panel in a panel - Prenatal Exam example

Stan: So I made Systolic and Diastolic Blood Pressure, and I made a panel. You have a model for the panel. Is a concept for the panel - an observable or LOINC code. I included the observable systolic and diastolic BP as members in panel, and I included qualifiers: measurement device and patient position. Because this is a panel, these 2 things add meaning. Both systolic and diastolic measured in certain patient position using certain device.

Stan (cont'd): And then I made a prenatal example panel. Has its own link. Has a BP Model and Heart Rate Model and Fundal Height Model. Is one example of a panel in a panel. Occurs in... but also patient data. If more thorough, you would have created systolic and diastolic in panel, then vital signs panel... Then vitals panel would be included in pre-natal exam.

Stan (cont'd): So would have panel in panel in panel. So that is the style we are shooting for. Would have been qualifiers at the panel exam - the clinician who collected...

Deepak: The Heart Rate Model. Whose Heart Rate?

Stan: Was the patient. But you could have included the fetal Heart Rate. Actually - I will add it here.

[Stan puts fetal HR in PrenatalExamPanelModel].

Stan: Depends on your style of doing things. One style would have it stored as Entry; other would not since is not about patient - is about fetus.

Defining the Common Context

Thomas: You would not seriously put the context items in there, would you? They would be context items in any exam, or... So you would not wait until this, would you?

Stan: Like the patient location?

Thomas: Yes. The prenatal exam would inherit from other panel exam or... There has to be a way. We would not want to redefine the common context on each.

Stan: That is true. Would want to make sure the same...

Thomas: You use the... at least in lab.

Stan: Yes - common part of lab. Reference range... If we go back up... Have interpretation... So systolic BP Model... Would probably have been... Ref Range Model.

Thomas: Yes. Just one comment. The approach at IMH is 100% constructive, meaning you are always building from pattern up. And there are 2 issues. There are natural data groups, like tree structures - you would not normally cut them up into pieces. I would have that you would start with a multi-level tree... And the second thing - for each single model, if we assume there is metadata... We have to be conscious of that kind of work we do. Your first example - first name, last name. Really would make as separate models?

Stan: Yes - whether make as separate or include in (?), does not change. The things that are qualifiers - very rarely change. Is the same amount of information whether you put into 3 smaller models or put into a bigger model.

Thomas: Yes... The metadata - why define first name and last name as models? Presuming would have title and other with it.

Stan: Is a style issue. If you wanted to define at this level and wanted to define first and last name, then would need more verbs. Here you are saying - here is... And everything follows this model... I have to distinguish the key for the person and key for this other.

Thomas: It is a triple. I have not thought about...

Stan: Yes.

Thomas: So you could mix first name with serum sodium, which does not make sense?

Stan: Yes - you can make non-sensible things out of this. These things are only included in... But I think it is true of this. You can say - I define person-name and first name and last name... Then I can still put person name where it does not belong.

Thomas: Would that allow tooling to use... But not first name and last name. But person with special tooling could...

Stan: Theoretically you could do that. We are doing reasonable things for type checking. Even if put into OWL, that would be true. It would tell you that this is consistent, but...

Thomas: Yes - then you are into an ontology thing with person name. OK.

Stan: Very good perception.

Deepak: I think the influence and the validity is... just an example. But I think once you put Heart Rate into... It tells you - is a female and... it tells you the status of the patient. Puts some restrictions... It makes sense once you put there.

Stan: Yes. Have not tried to put constraints. Are not trying to make an ontology that is so precise that can only make (?) models. We are depending on people to verify.

Stan (cont'd): OK. We have Laboratory Data Examples.

Laboratory Data Examples

[See Laboratory Data Example from Stan's file]

Stan: This would be the Hematocrit Model. The HematocritConcept. Also Hemoglobin. This would be a Complete Blood Count... Would have Hemoglobin and Hematocrit and White Blood Count and Differential. Also add qualifiers. Could have included another qualifier with instrument.

Stan (cont'd): The qualifiers at this level are telling you common content. That is why it is important. The relationship between qualifier and Hemoglobin is different from (?) and Hemoglobin. Shared context... In openEHR, could have been... they are represented as part of clusters that are included in other items. So go on and create PMNCountModel. And if we were doing the whole thing, would be White Blood Cell differential... Including PMN count [PMN=Polymorphonuclear leukocytes] and lymphocyte count. Have the same qualifiers. Part of Red Cell...

Stan (cont'd): So go on and create PMNCountModel. And if we were doing the whole thing, would be White Blood Cell Differential... including PMN Count and lymphocyte count. Have the same qualifiers... part of Red Cell...

Stan (cont'd): The same place where panel in panel. CBC with Differential would be a panel which consists of these 2 other panels. So panel in panels. So then Hematocrit and Hemoglobin are orderable. Could order... In either case, would want to know what I get.

Thomas: When you say these are "orderable", do you mean these are data elements that have to do with ordering? Not sharing these?

Stan: These models are different from order model.

Thomas: I understand - these are results.

Stan: The order model with order item would have their order. Is actually just a reference. It is the concept id in this panel that is the coded item... the coded data in the order.

Thomas: So... If you want to know... So when put white cell differential into something else, not have to do with order-ability?

Stan: Yes - the models from our web site are orders of results.

Thomas: So are you proposing something different here, or is this just for brevity... leaving things out?

Stan: The CEM models you see are modeling the content in the panel, and are modeling the attributes. The model and the terminology associated with the result is the same concept-code that is used in an order.

Stan (cont'd): So here is...

[Stan show the CEM Browser on the screen]

Stan: Well - we don't have the lab panels here. But can look at regular results and talk about... So it works the same for panels... Is modeling the content of Hematocrit result that would come back and be stored as an instance of data in Record... And the Key... LOINC... is the concept that would be used to be ordered. So this model... Hematocrit model - is used to order it. Is used to describe content and... Actually we could say also for the Blood Pressure guy.

[Stan shows the Vital Signs Panel - CEM]

Stan: This model is specifying the content of Vital Sign result. And you could order... So used to define what results would look like. Also defining what is shown in example. Also... the statements in panel. We have mixed the model info about panel with information that is part of the entry. Does this make sense?

Thomas: So in Blood Pressure panel, and Vital Signs, no order of info as such? No order id as such? But if you went to a panel - like a client - then each of the things inside would have order-ids? So would get a whole bunch of order-ids?

Stan: So if we go to Hematocrit, it has all this Reference Range and filler order# and...

Thomas: So if we make a panel, then all of that order stuff will appear?

Stan: But not in the instance. Does not physically get stored.

Thomas: So is a different...?

Stan: The physical model... Not mean if at 2 levels in virtual model, not mean is in physical model.

Thomas: I think in CIMI we need to be clean if trying to... or trying to assume that... are system-specific. Do we agree that what we are doing in CIMI is different from what you have here?

Stan: Well...

Thomas: If trying to optimize, then...

In CIMI, we are not trying to optimize

Stan: Yes. In CIMI, we are not trying to optimize. Has crept into models, and we try to correct. If CEML... This is a logical model. The issues you are raising are very important. The root of what you are saying is true. There is a reason we got here... is not an accident. You have Hematocrit. That can be done alone. Can be done as part of panel. And filler order# and... order# are still part of... So if define a panel and only put at level of panel, and then allow someone to retrieve Hematocrit... then need to... copy into...

Thomas: Aren't we... into what is query data and what is capture data?

Ian: I understand, I think, having to carry more granular information to level of analyte. But could argue that for physician, or... as well. But to do that is basically madness... is a tension...

Stan: Is all a question of how you want to model it. Causes complexity however you do it. If body part is modeled at panel vs. individual... Then complexity is... how can I retrieve body part... That query, whether at Blood Pressure panel or individual, is an important issue. There are trade-offs. If at panel level, you can make panels where some context is shared. But you can ask, how can I know? Then - problem with copying into 4 or 5 panels, but not all of them.

Thomas: But don't we have to...?

Stan: This is not a model of query results. Is how you state the... not how you return it.

Thomas: But - optimized...

Stan: Not have to be optimized.

Thomas: But... will have same context wrapped around both things...

Stan: But...

Thomas: But in CIMI, I thought...

Stan: These are both logical models. Whether qualifiers are a panel or... And both ways are valid. One of the things that has been forming in my mind. I don't want a modeling language that forces me to model one way. Want to... then recognize them as...

Ian: I can support that, Stan. Is hard, even in openEHR, you get different modeling styles. So to get something that allows those differences.

Thomas: So to be clear... that approach will require the Ref Model in CIMI to be (simpler?) than what it is today... And is all archetype... 3 or 2 or 5 different types of archetypes.

Stan: Yes - but the other principle... Even though we are allowing those different archetype families... for interoperability. So to echo Ian, I would agree.

Stan (cont'd): Is not up to me to say what is... It is the people using the models who should have the final vote. And is my job to convert from one to the other. And people should decide. So, yes, we would allow different models. Other groups would express - this is the style... we would use.

Thomas: Was different from what I thought we were doing...

Stan: Yes - that is right. Is inherent in isosemantic model - from the start. Lot of info in the entry level of the model would become information in the... Makes it possible for Ref Model to be the independent...

Have given up controlling the Universe and making everyone model as I want them to model

Stan (cont'd): I have given up on controlling the universe and making everyone model as I want them to model.

Two Styles for Epistemic Information

["It is a goal that the RM would allow description of any style of modeling, though only one style would be preferred for interoperability services." - from "Two Styles for Epistemic Information" in Stan's Examples-file]

Stan (cont'd): As we get to the bottom of these... we can look at 2 different styles for epistemic info. Could have procedure, and could... This code would be... This would be actual procedure code for appendectomy [ProcedureValueSet]...

Stan (cont'd): And could have the other code for... procedure scheduled... You could model one way... planned procedure... I have a concept...

[See "Style A" in Stan's Examples-file]

Stan: This should be a qualifier.

[Stan changes something on the screen]

Stan: The other way... The epistemic says... I know this is a planned thing because is planned procedure. And inside model I say whether done or...

Stan (cont'd): Two different ways. One I say... epistemic. The other - pre-coordination. Other - I could have diagnosis model and family relation model. Is the mother of the patient, or ancestor or... And... code says... I have a family history model... And I know it is family history because of thing it is contained in. Or could have a health issue model... and modifier that says this is a family history.

2 Different Models - details not in Ref model; should be in Ref Archetype

Stan (cont'd): 2 different models. Over time at IMH we have used both. So - the conclusion is exactly the same you came to, Thomas. The details should not be in the Ref Model. Should be in the Ref Archetype that is one step... Are specialized models. Are not going to get direction from modeling in Ref Model... Not entries, per say, that... the subject has to be specialized. If put that in the Ref Model, then can't say...

Ian: I am not sure. Not a problem using Ref-Archetype approach. But... have to know... Would be dangerous. Have to have modifier flag and subject of info in (?) of model... or system will have to get it. Don't think that removes the problem.

Thomas: Is there some assumption that in some system would only be one style... Otherwise a problem.

Stan: The identity of patient... When I create an entry... Then I create a modifier that includes subject. I only know at this level. And at each model, include subject. And can make pre-natal exam. Understood that...

[See Example-file: "PrenatalExamEntry2Model" - "It is required and understood that each item in the entry contains Subject information"]

Stan: So each... has to do style... where included constituent parts.

Thomas: Doing otherwise would be confusing. Series... dependent on content. Not work. Propensity for error in that situation - not viable.

Ian: If you name something that is query-able - we call it CDG [Clinical_Data_Group]. So fundal height model and... Somehow system will have to supply to query engine the... And how the system does that is...

Ian: I don't think that is true, Thomas. We could use IMH models, but...

Thomas: But could not do what Stan has here... If do IMH models with 13606 and VA and... not work... is different... not know if right or wrong.

Ian: But would be made to work.

Stan: Not sure there, but my thought is closer to Thomas. The logical (...?) to query is fixed... rather than to Ref Model. We are talking about subject, but... The shared context... has to do with all epistemic data, whether outside or inside models. Could get from... epistemic data outside the parts to model with epistemic inside the parts. The query you state would have to be done against archetype... And can't be done against different type of archetype...

Stan (cont'd): So the real question is - if we want to create representation of any style of model... Can have common style of model with...? Or can do at the Ref Model level? But would have to have a different Ref Model if want to do different style. Because if you fix subject or other epistemic data, then other styles that don't use that data can't be... I think that is true. And as you say, Thomas, the Ref (...?) becomes simpler. The Ref archetypes... Different way to think of... I can't make interoperable by selecting one style.

Stan (cont'd): But... pinned to a core Ref Archetype instead of pinned to a Ref Model.

Thomas: More than a Ref archetype... Seems to me this changes what the CIMI project is. Now is more of using an archetype to get from one... silo or... into the base... and into some sort of data transformation approach.

Stan: Yes and No. I don't think I have changed. I still say - of those Ref archetypes... the one we want for interoperability. I don't want to encourage people to do what they want. I want consensus around a preferred set of models. If someone chooses a different isosemantic representation for that, I want to know how it relates to CIMI. So I can use the same modeling language and set of tools... to describe local "BAD" models which are accurate according to set of tools using them. So can...

Stan (cont'd): I want to strive to the modeling style. The argument is happening at the core reference archetype. Special one-dimension of the modeling universe. All have taken a stance. And another universe would be where that information would be...

Linda: Are we still following - requiring style for Ref Model to include... chunks of information?

Stan: We still want to... but what are trade-offs if at... level vs. archetype level?

Linda: I think would be a benefit... for identifying at Ref Model level.

Review of Rahil's Proposal

Stan: So - coming back to agenda. Rahil - did you join?

Rahil: Yes. I have system failures. I emailed [my slides], though. (Slides)

Stan: I can display it. Is this it?

[slide 1] HSCIC Data Dictionary for Care Modeling Approach

Rahil: Yes. Go to second slide. I was struggling a little following the conversation. I think... recognizing the indivisible units. Our approach. 2-level process. Level 1 can be ignored. Is the hi-level... More for health informaticians and clinicians.

[slide 2] Logical Models for Care

Rahil (cont'd): Level 2 is the interesting bit. We call them logical models. Can call them archetypes. Are the technical discussion with health informaticians and technical modelers. How much of modeling style is supported by... and how much is style issue.

Rahil: I wanted to present discussion Thomas and I have been having, why we don't need a class called (?). If you look at purple and yellow - clusters that... Clinical_Data_Groups (CDG). There are clusters with elements inside them. Within 13606, you can present... the scope ... using an attribute called... So, I could state that this is about the core data - systolic and diastolic. Or could specify that another cluster is... of patient state. So that is what the clinical statement is about. Could call it... or CDG [Clinical_Data_Group].

Rahil (cont'd): So these CDG contain... The type... I included at entry level... whether subject of care or... family history. You also have the... state... similar to mood... flavor. So could say whether already observed or is planned.

Rahil (cont'd): And then you have... Everything above that is for human consumption. The way we use is synonymous with heading. Level 1 - sections. Exam - finding section - synonymous to heading. That changes with community. Different depending on setting. All for human navigation and setting.

Rahil (cont'd): Then have... organizers or reports. Discharge summary and... Not about how faithful is... but for human consumption. Have a little looseness. But are faithful to the entry downward. Want to be faithful - how we represent entry... and the clusters - individual (...?) within an entry. Then you come to whether you want vital signs as Section or as Entry.

[slide 5] Level two: Logical models. Bottom-up modeling approach (2)

[slide 6] CLUSTER: Blood Pressure Measurement

Rahil: [can't hear]

[slide 7] CLUSTER: Blood Pressure Measurement State

Rahil: Can create another cluster of this kind.

[slide 8] Level two: Logical models. Bottom-up modeling approach (3)

[slide 9] ENTRY: Blood Pressure

Rahil: We have included 2 Clusters. The Blood Pressure measurement and the BP Measurement State. That is a completed... not planned. Or you can bind the concept to a shared concept. And can do for... And can define each of these with a SNOMED CT concept.

[slide 10] Level two: Logical models. Bottom-up modeling approach (4)

[slide 11] SECTION: Vital Signs

Rahil: From the feedback we received, Vital Signs differ in different institutes, so are not consistent. And we noticed... changes... Therefore, since inconsistent, the decision was to model as a Section. This is where the... comes in. Might want to model as Entry. Can re-use those clusters... Vital Signs history... Vital Signs Cluster... included in Vital Signs.

[slide 12] SECTION: Examination Findings

Rahil: To show how they all fit in together. Can have Sections in Sections. How this has been modeled.

[slide 13] Level two: Logical models. Bottom-up modeling approach (5)

Rahil: Where you have...

[slide 14] COMPOSITION: Outpatients

Rahil: Working example up to the top. Part of Outpatient Report. Modeled as composition. This is the last slide.

Rahil (cont'd): This is how we have approached the issue of reusing the information by having lots of clusters and... modeling. GP to GP... Re-using the same sort of style. We have been able to re-use. Useful to share. I would like to stress - some level of consistency needs to be available at Ref Model level. But we can...(?) at Ref Archetype level. Need...(?) or different approaches... representation... inter-operability. Thank you.

Stan: Thank you. You are using the Ref Model in this part in terms of Entries and Clusters. You are using openEHR-style. And... whether Cluster = re-usable context... to use in class. And creating Clusters using those Clusters... saying this is a Cluster, but... what we call an atomic statement. Is that right?

Rahil: I don't understand the name "labels".

Stan: Right here - your item category. I am calling this a label . That is how you distinguish...

Rahil: Right. These are actually the item category... is an attribute in the item class in 13606. Not sure if in openEHR - that attribute. I am not sure. That is true... is categorizing your Cluster and sticking a label on it.

Ian: Similar to what you do with modifiers, Stan. We do differently. I think what is different and the same is the commitment to the epistemic. Making sure we have identified the subject. Different in 13606... openEHR... IMH... I think that is what you're doing.

Rahil: I could have shown you the Archetype Tree Tab. Would allow you to... and I think 13606 and openEHR are similar.

Ian: Yes, but Stan could... at a more granular level.

Rahil: Yes. Assumption is you are re-using completeness of information when you say... This system... At this point, you are defining... Not just the data, but also the information that helps you to understand. You are throwing in all the data and content. But the entry will allow you to say "this is information about a family member, not the subject of care". It allows you to... That is how we are using it.

Rahil (cont'd): I have spoken to people about the lab panel stuff. These are...(?) that will keep changing. I did not have a chance to model, but I could summarize. I think we are close...

Stan: There are things people commonly call panels that are like that. The panels we are talking about have a pre-determined content. If changes, then there is a different panel.

Rahil: ...What is the information that is required for that particular representation? If the data within it can keep changing... How you are defining what goes inside defines whether it is an Entry or a Section. Could be modeled using Clusters and Elements. Thank you.

Discussion and decision process for "final" reference model

Stan: We are in a bit of a pickle. First - need to make a plan. Second - did not get to Steve Hufnagel's agenda item. So - the 3 options, and correct me if I am wrong...

Stan (cont'd): First option - Rahil's approach. Second option - CDG proposal by Thomas and Ian. Third option - The model we previously proposed as indivisible and compound. Beyond those 3, there are additional things we need to say. What are the actual attributes inside the model? So - are those the 3 different options?

Rahil: Yes - I think so.

Stan: So I will summarize the options and include the slide set and send out as email. How much time is reasonable to vote?

Steve: Vote by next week.

Rahil: I am mostly on leave next week.

Linda: I am on leave next week as well. Another - would be good if we could objectively compare. Compare each approach against the requirements.

Stan: Is that a suggestion - we should do individually or as a group?

Linda: I would hate us to vote unless we see how it meets requirements.

Stan: I worry - I would encourage that also. But I can see us going on for another few months.

Linda: Yes. Perhaps when you summarize approaches, you can discuss.

Stan: What we discussed today - more robust modeling style or... Core vs. qualifier element. Whether at Ref Model level we want to fix... All entitled to set the course. If a majority want to go through formal process, we can do that. I would rather leave that for those who want to, and go to vote. Once we use, we will want to change... Goes... Need to be pragmatic and make decision.

Linda: Yes - I don't want to slow down progress.

Stan: No - I appreciate comment. So I will do that, and people are welcome to email or call me. But email will allow all to see discussion. And approach of Rahil... Thomas...

Stan (cont'd): So, we need to vote by the end of next week... by Friday?

Linda: If we could have a couple of extra days, that would be appreciated, even if just up to Monday.

Stan: By the 21st?

Linda: Yes.

Stan: So, we will tally vote by the 21st. So people can... discuss on call next week. But first item will be Steve's... I apologize, Steve, that we did not get to your proposal today.