CIMI MTF Minutes 20140116

From CIMI
Jump to: navigation, search

CIMI Modeling Taskforce – Meeting Minutes

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


Attendees

  • Linda Bird
  • Stan Huff
  • Gerard Freriks
  • Thomas Beale
  • Galen Mulrooney
  • Jay Lyle
  • Patrick Langford
  • Daniel Karlsson
  • Sarah Ryan
  • Eithne Keelaghan

Draft Agenda

  1. No call on January 23 (HL7 meeting and other conflicts)
  2. Joint meeting with SemanticHealthNet March 13-15 in Europe
  3. Entries in entries (or the pattern for modeling panels)
    1. Review and correct requirements (see attached draft requirements document)
    2. Review, clarify, and finalize the options
    3. Plans for final voting
  4. Any other business

Proposed Requirements

1. The overall goal is to be able to model panels, which are collections of independent discreet observations where each observation in the collection has "specific context" (qualifiers, modifiers,

protocol, etc.), and where there is also shared or "general context" that is shared by the whole

collection (subject of the observation (patient), information source, observation time, instrument,

etc.). Also, for something to be a panel it has to be orderable, otherwise it is just an ad hoc

collection of results.


Panels are different than sections. Panels have specified and fixed content, which is what

provides their value when used in ordering. Sections can contain anything that is appropriate to

the section heading, and the contents change from instance to instance.


The idea of "independence" of the observations is important. It means that the meaning of

the observation is not changed by what panel contains it. As an example of things that are

not panels: a "drug name" element could be contained in a drug order model, or in a drug

administration model. The meaning of "drug name" in each of these compositions has a different

meaning. In one model it means the drug is being ordered, and in the other model it means the

drug is being administered to the patient. The clinical meaning of the element changes based

on the model that contains it. In these examples, the clinical meaning of the "drug element"

changes based on the container. In these cases "drug name" is not independent, and the

compositions "drug order" and "drug administration" are not panels.


2. We want to be able to model panels that contain other panels, for example: CBC with Diff panel,

which contains a CBC panel and a Differential panel.


3. We need to allow for data elements that are data about the panel, and not just shared context

for the contained items. That is, some panels have indicators of whether the whole panel is

complete or final. This is data that describes the panel as a whole and is not specific or derivable

from a single element in the panel.


4. A given observation can be modeled as part of many different panels. For example, a creatinine

level could be part of a renal panel, an electrolytes panel, a creatinine clearance panel, etc. Or a

serum sodium could be part of an electrolytes panel, a Chem-7 panel, a metabolic panel, a renal

panel, etc.


5. Recognize atomic elements: Especially for non-clinical users of the models, it is helpful to

recognize the indivisible pieces of information that you can sensibly query for and use in clinical

applications. That is, recognize elements that can sensibly be the subject of a query that returns

a useful statement about the patient.


  1. Proposal: Indivisible elements should be recognizable by always being assigned the same type, i.e. always identified as an "entry". This is the "thing" that can be queried along with its associated context. Or, the indivisible things could contain a tag or annotation that identifies it as an "entry".
  1. Panels are collections of atomic clinical statements.

6. Consistent query paths: Ensure query paths to these can be consistent. This is really the

same idea - that query paths always start with "Entry". The goal is that I can use the same query

statement to find serum sodium's regardless of the fact that sodium's can be part of many different

panels. Also, I should not need to change my query if sodium is added to a new panel.


7. Simple navigation: It should be as simple as possible for a query to navigate from a panel to the test results.

  1. Panels could be modeled as collections of contained observations, or as collections of references (pointers) to the contained observations. If items are modeled as collections of pointers then the query language must have a mechanism for asking for pointers to de-reference the pointer(s) so that the actual observation is returned to the user.

8. It would be best if the strategy (pattern) for representing lab panels was the same as the strategy (pattern) for representing patient observations. All panels should be represented using a common pattern.


Principles

  1. The reference model should be able to support new use cases.
    1. If there is no operational criterion for this, we might remove it from the list.
  2. The reference model should have no semantics that are specific just to healthcare. (e.g. Observation). The motivation for this principle is that for the broad range of use cases that we are trying to serve, there are NO healthcare related attributes that are common to every model. Models that are meant for a restricted set of use cases, such as storage of data in an HER, DO contain elements that must be same in each observation model.
    1. Proposal: "Reference model elements represent generic knowledge structures, and should not be specific to any domain. Container types ('cluster,' 'section') and concepts corresponding to parts of speech ('thing,' 'action,' 'modifier') are permissible; domain-specific kinds of those terms are not ('patient,' 'procedure')." Healthcare semantics should be represented in "reference archetypes" that specializes the classes in the reference model. The reference archetypes contain health care semantics.

Detailed Meeting Minutes

Future Meetings

Stan: Quick item - no call on Jan 23rd. HL7 meeting. Continue with plan for meeting with SemanticHealthNet March 13-15 in Europe. We have conference calls to create agenda...

Stan (cont'd): So today, want to review requirements and review, clarify and finalize options to best... our ability and decide how to vote... and then move on... Any other on the agenda?

Response: No.

Requirements

Stan: OK. Linda, let's project the requirement documents. Jay created the first version and I remodeled it, so I don't know if you should blame me or Jay. But wanted to acknowledge Jay. So should we step through this?

Response: Yes.

Proposed Requirements #1 - What we are trying to do

[See Proposed Requirements at Beginning of Meeting Minutes]

Stan: OK. So the first... #1 [see Proposed Requirements above]... Say what we are trying to do. And, based on emails I have read, say what is panel and... Collection of independent discrete observations where each observation can have discrete context. Thomas also said... qualifiers and modifiers... discrete... And then shared, in common, the instrument... And the last sentence - the panels are orderable... A predetermined fixed meaning that you can use in healthcare process.

Things you can use in the clinical process - those are what we are trying to model

Stan (cont'd): Panels... have to do with "I want a complete blood count", and can receive back and use in patient's EHR. Different... from data stored from data-collection screen. There is complete arbitrariness about what might be put on screen... As Thomas described, no reason to describe those as things... But things you can use in the clinical process... Those are what we are trying to model.

Panels are different from Sections

Stan (cont'd): And Sections - Gerard said... have semantic meaning... But are different... variability... whereas Panels have a fixed content. Have rules about what is required and not required... Now - Sections are arbitrary headings and the things under there are... I don't think you can use a section as a panel.

Gerard: The name of the section has no meaning... except... to name... But what is collected is the definition of where everything should be. So the entries in Section define the panel(?)...

Stan: But I have never seen that... To... the content of a section...

Daniel: I sent email... on sections of... repository. I don't know if it is a good alternative, but is a possibility. The section... root factors... this was a heart failure template. Probably more a matter of taste.

Stan: Maybe I misunderstand. My understanding of section comes from CDA. You put things in there that correspond to name, but not defining... So you are saying... defining sections... Have to have mandatory....

Daniel: In those sections... the content of sections is...

Gerard: You can constrain sections in... As in any model. You can specify how many times allowed.

Thomas: What Gerard and Daniel said is correct. Probably... certain headings... But I think your understanding is correct. The thing here... panels... And sections can be put aside for now...

Daniel: Another question not on Sections... The panel side is specified... a fixed content, but how specified and how fixed? So... for example... How fixed is fixed?

Stan: In LOINC, they are completely specified. You have a list. There is conditional optionality. The way LOINC says is... you define a Chem-7 - only those 7 things... Not be a Chem-7 if include others. But can have... for example... anion gap, which is a derived value that can be derived from elements in the panel. Can calculate the parts that are conditional. But they are completely fixed. So, ordering... if have Chem-7 and electrolyte panel... Want to be able to say, these have overlapped. Want to be able to say... they have... they are fixed.

Stan (cont'd): In the example we are given with risk factors... the semantics. The code that says risk factors - not 5 things that are risk factors. But if said 5 things from American Cardiology Association in 1975, then can say... But the usual for risk factors... you are putting in place... But the Chem-7 says exactly that. That is the difference I see between sections and panels.

Daniel: So antibiogram... would not be a...?

Stan: Antibiogram... Section header... So the standard E. coli antibiogram... So takes into account what you test. Takes into account whether organism is resistant over time... So would have to say the E. coli antibiogram for 2014.

Gerard: ...(?)

Stan: So you order antibiogram and lab decides... So antibiograms are not panels.

Daniel: That is helpful. Wasn't clear to me. Important to clarify. As usual, you use the words and... We have different ideas about that. The whole purpose of requirements #1. The last part of requirement #1 to define what... are... Important characteristic of panels... the items have meaning independent of panel. So serum sodium... If in electrolytes panel or liver panel... has same meaning. Is in panel for convenience... But serum sodium... or potassium level... Could be used to adjust the patient's potassium intake or for supplement. Whether in electrolyte panel or other... But if had drug name... Used as part of antibiogram. The meaning of drug name is qualified by what contains it. So if name of drug in drug administrated, then is... If in antibiogram, then is name of drug used to test if sensitive...

Stan: Those things are not panels. Those are statements or entries... Their meaning is not only what contains them but also the other elements that are part of that structure. Questions?

[No Response]

Proposed Requirements #2 - Panels in Panels

[See Proposed Requirements at Beginning of Meeting Minutes]

Stan: So scroll down. The second... Want to have panels in panels... to other panels. A CBC and white cell differential... red cell indices... the differential... white cell count... Pretty straight forward... Want to have panels in panels.

Proposed Requirements #3 - Data about the Whole Panel

[See Proposed Requirements at Beginning of Meeting Minutes]


Stan: The third thing - want to have information that applies to the whole panel along with things that are contained in it. The status of the whole panel - whether complete or not. The attribute of the whole panel. They provide context, but could just as easily have been included in other... And this - requirements - is the reason... The reason that you can't do away with panels... What Gerard has argued... Don't need a panel. But this requirement says these are things that pertain to panel... Description of panel in aggregate... #3 is argument for why you need panels at all.

Proposed Requirements #4 - Can be part of Many Different Panels

[See Proposed Requirements at Beginning of Meeting Minutes]

Stan: And #4 is simple. Want to create arbitrary collections of measurements. Could be in two or more panels... What we are trying to cover in requirements.

Proposed Requirements #5 - Recognize Indivisible Pieces of Information

[See Proposed Requirements at Beginning of Meeting Minutes]

Stan: The 5th thing is subtle in some ways. We have talked about it. It is connected to #6 as well. What openEHR meant as well as 13606... Let me talk about #5 first.

Stan(cont'd): #5 is arguing - a good thing if you can recognize which things you're modeling are indivisible... Coherent statement about... patient or Lab. Being able to recognize difference between Hemoglobin and Hematocrit or Blood Pressure and Heart Rate rather than location. Says something unique about patient... So, independent classes... rather than body location... Has no meaning unless you say why is being collected from there... So modifiers... only have meaning in context... So - nouns vs. adjectives... Being able to distinguish those is important - especially if people modeling don't have deep clinical knowledge. So can say whether you value or not...

Gerard: Panels can exist in Panels.

Stan: Yes. And if you want to be clear... I don't like to use same name for different structure. So can say have Panels with same structure vs. Panels in Panels. So could say... super-panels vs. basic panels.

Gerard: Good.

Thomas: So have Systolic and Diastolic and Body position. We would regard as a group with its own logic. My question - Do you regard those groups of things as... models... with innate structure? So - body position can't be on its own, so group of things... Cuff-size and... Would that be an atomic element?

Stan: A Systolic BP would be an atomic statement. And Diastolic would be another.

Thomas: And Heart Rate and... the bits that go and make up?

Stan: Depending on how you model. If name of element is 2 minutes breathing Apgar... If fully descriptive, is Apgar... But if have only 2 elements - cry and color - not a panel.

Thomas: Would someone use a single part of Apgar on its own - cry, for example?

Stan: No. There is a subtlety there. It is not clinically useful if all I know is the cry-response of Apgar.

Galen: Apgar is an assessment instrument. The observation assigned are to come up with a score... I wonder if should consider assessment measurement and panels as different things.

Thomas: Well...

Galen: Creatinine clearance test. Take the... of patient and then take again... But the thing that counts is the difference between 2 counts.

Thomas: What about severity of reaction and...

Stan: Those are not panels.

Thomas: Are each of those atomic?

Stan: No, but...

Thomas: By atomic, do you mean data item or semantically individuals?

Linda: I think he means individuals, semantically individuals.

Stan: So if have order... drug name and dose and route... and if I reuse over and over... 2 things going on... Unless is part of order I don't know what it means. If I query for drug name and not what is...

Thomas: Wouldn't it be a drug name... molecule.

Stan: Meaningful to query for drug order. Not meaningful to query drug name and not order.

Thomas: Is that why you want drug name to be separate atomic... Because still seems to me that your atomic element...?

Stan: Yes - I mean in second sense. Drug name - not what I am calling atomic or indivisible then... The drug order is the indivisible thing. Different from Chem-7 and potassium and sodium.

Thomas: OK - good.

Stan: Further questions on #5?

[No Response]

Proposed Requirements #6 - Consistent Query Paths

[See Proposed Requirements at Beginning of Meeting Minutes]

Stan: OK - #6. Given that can have the same element... serum sodium, serum potassium in different panels, I have to support a query that will get all sodium regardless of how many panels it is a part of. So whether you put in panel or stored alone or in panel inside panel, I want to say, give me all serum sodium in past hour. So then must bring back all sodium whether in Chem-7 or Chem-20.

Jay: If that is really the requirements, then sodium... same structure... The only one that gives this is...

Stan: # 6 does that as well. Looking at options and saying pros and cons. Let's scroll to #7.

Proposed Requirements #7 - Simple Navigation, whether Instance or Pointers to Instance

[See Proposed Requirements at Beginning of Meeting Minutes]

Stan: #7 - Getting at whether we are retrieving data... or retrieving references to data... Instance or pointer to instance. That would be the recommended or best practice if... So, I calculate BMI based on weight and height... And I want to say... the weight and height are taken at different times by different people, so... can have BMI which has pointers. Would argue, if use in panels, is more... So if Chem-7 contains pointers rather than data, then have 2 steps... So, logically, retrieving.... pointers and then de-reference the pointers to get data. So if use pointers, is a more complex path logically because have to deal in the query language with...

Tom: Or have a query language that can follow links.

Stan: Yes - assuming that. But even if have that, have to tell it when you want to have it de-reference those... Makes sense?

Response: Yes.

Gerard: Unless... reference to Link or detailed item... or have the capability to de-reference...

Stan: Not sure if that helps - if going to put data there anyway.

Gerard: (?)

Stan: Then my update... is harder because have to update Link as well...

Gerard: I agree. But is a generic pattern. Details generated... But only occasionally have to have more details. Is a generic pattern you see everywhere.

Stan: I agree. The pattern of using pointers is elegant and essential, but not a general solution for panels is my argument. Not the one I prefer because it makes me do everything as if it were an exception to the general rule. So... whenever I do Chem-7, all 7 come back to me. I do this because I want to see sodium, potassium, glucose... So, if just one case... it is more complicated.

Gerard: But not generic panel solution...

Stan: I have the same with Vital Signs. So many times in the ICU I get vitals... Blood Pressure, Heart Rate, Respiratory Rate - all coming from some cluster and collected at the same time. Now sometimes the nurse will take the Blood Pressure - not a part of a panel. An individual item... But so often I have a panel... information source is same and happening at same time and I have 1000's done a day.

Gerard: So... is from labs to finding.

Galen: In dialysis, often will take blood pressure over the course of dialysis. So - same information taken over time. Single measurement many times... at different times... as opposed to...

Stan: No - not consider that a panel.

Thomas: Would you make the general statement that the values not be the same but different values... same critical time?

Stan: Yes.

Thomas: So that is why the ICU... single patient...?

Stan: Yes.

Proposed Requirements #8 - Lab Panel Strategy same as Patient Observation Strategy

[See Proposed Requirements at Beginning of Meeting Minutes]

Stan: So final thing - #8. Would be nice if, when applied, the panels for clinical observations follow the same pattern. So, as illustrated by Thomas's examples, there are time requirements for panels not met... Taken by different people and different times and... So, rather by query than by manipulating a panel.

Stan (cont'd): So, to me, some of these are more important than others, but...

Gerard: The way I see it, you need structure to deal with a panel as a whole and structure to deal with all elements of the panel. Loose coupling - use pointers...

Stan: That is one of the main dividing points. But, also, will... support panels in panels. Other requirements, distinguishing... You are right... whether we use reference to data or... Major decision is one of those 2 strategies.

Thomas: I think it is a good list of requirements. But I would like to replace "atomic" with innate structure. If you use the word atomic, it means one element to me. The question to solve is this thing of panels... People doing clinical modeling have had these questions...

Thomas (cont'd): I think, it means that... it can be solvable in a Ref model. Second - have something to do with separating... Has to do with context - subject, baseline time, risk... Has to be separated from group thing... compound structure... Historically, in openEHR, have been one thing. It has been getting annoying for clinical people. It seems to me that entry has to be separated from compound structure. If had the ability to put compound structures under entry, when entry is... Divergent from model. What we have done in openEHR... teased out... clinical... Hospital view forces this to be sorted... separate... Has to be a separate class...

Stan: I want to make sure I understand. You are saying... entry-thing and innate molecular things... Right? Or am I confused?

Thomas: I think that panels are an archetype of an entry... My current belief... Panels and Entries.

Stan: From your characterization of panels as a template on an entry archetype where this...?

Action Item - Thomas to Build Panels

Tom: Yes. I was thinking... BMI panel. I created a class... BMI... Has a few things hanging off it... height and weight... I may experiment with this and will provide in some visual form... I feel that I could build those panels... I'll try and do that.

Stan: That is useful. I need to think about this some more. Is a little difficult... I think - there are 2 kinds of entries. Panels and the indivisible molecule. Contain a single coherent fact about patient... And then there are collections of those things... Is a different way of thinking about that. And the molecular innate things are the root of the query path... And paths... collection of those... single coherent statements... And that is the basis of how we have thought about them. So... of the options we have, if 2 or 3 we think are viable, we need to say "What would the Ref Model need to look like?" Also, policies and procedures that establish the style... And Rules and policy constraints on how Ref Model is used. We probably need to get to that level of understanding to get to informed decision. Level of Ref Model... We need to get to... so is implementable. Reference model and overall modeling style.

Linda: So - one of the options for Modeling in the Reference Model... based on discussions. Two - one is the context and... other... the indivisible entry which could be the start of the query path. Each... in a panel shares the... context details... So how context shared between panel and test... and how we identify the individual...

Thomas: So - more of the context item into individual... So, subject... inside an entry or mega-panel, could not have patient's blood on fetal or donor kidney inside the same entry. So, in the type we agree... I wonder if we should... So, say what entry level we mean.

Linda: Those attributes are introduced at first level modeling.... attributes. So did not... subject, because we wanted to model... Public Health and other...

Thomas: I wonder if those are entries or... aggregate.

Linda: Yes - So depends on whether we keep CDISC or...

Thomas: Could be a candidate... If build archetypes and inheritance... Could crunch all the... easy to... Could be a promising...

Gerard: I think this will work but need to change the Ref Model. No other option for me except Option 4. Is equivalent to what I see on the screen.

Linda: Yes. Easy transformation.

[On screen - Linda's slide of Ref Model]

Stan: Yes . If can do everything you can... 13606... We can transform from what CIMI... to 13606. The whole value comes from the value we create from creating detailed model. If... trying to preserve the value of the model.

Gerard: Agree.

Where Do We Go From Here?

Stan: So where from here? Go back to options? Work with slide set... Say these are the 2 or 3 ways... contenders... Say - look at the Ref Model... Get to the details... Not only the kind of change we said... Collections from the innate indivisible molecules. Say what are the other required attributes? Considering the whole solution in reference to Ref Model.

Thomas: Get down to the 3 good ones and toss the others and show what the Ref Model implications will be... and show examples. I am going to try and get workbench done and get Harold's stuff, but not sure if will be on time. But I think I need to get... drawn out... Make sure not breaking stuff that already worked on. Do you think - a vote at SemanticHealthNet meeting?

Stan: I am always of 2 minds. Want to move fast, but want to be perfect. But... if at SemanticHealthNet... if we found out not perfect, we could change.

Thomas: If someone makes... diagrams, I can build... into workbench... and show result... I can offer to do to help resolve this.

Linda: Should I send you the XMI?

Action Item: Linda to send screen shots and XMI to Thomas

Tom: Yes - send me some screenshots and XMI. I am going to stick context attributes... the model inheritance... Will crunch all the... Can click the buttons on the side to show... If have context element, it will show up there... It is pretty quick for me to make these experimental things and throw at workbench.

Stan: So what do people think? The three things that Linda highlighted? We don't have Rahil on the call... or Michael van der Zel... But do people want a quick vote to see... or could vote and tell Rahil and Michael and see if they are OK with it.

[Brief discussion about how to proceed]

Stan: If get down to 1...

Thomas: I think 2 and 6 matter. Option 4 is... a kind of Link version...

Gerard: That is OK with me.

Stan: So we can go down to 2 - option 2 & 6 - and say Option 4 - corresponds to 2 and 6?

Gerard: Yes - one tight and one with loose coupling. But the Reference Model... the same.

Stan: So Thomas - do you think you have enough context? Does the current Ref Model take care of option 2?

Thomas: I can quickly make alternative Reference Model version... I can do the model I was going to do... I can build a model of...If someone can hack a BMI model for me... I have solid version of workbench now...

[slide #1] - Options

Thomas: Vital sign - seems like a good one... Panels. BMI...

Stan: And complete blood panel with differential. Are you writing down a list, Thomas?

Thomas: OK. CBC and diff. Chem-something. ICU, Vital signs panel... Also, ante-natal visit... under...

Stan: Yes - I think we are in agreement. Not need to do panel.

Thomas: So, Blood Pressure - if the world changes like they say, then do we really know...

Stan: Yes. Systolic and Diastolic... unique...

Thomas: Should try a version of one of the most nebulous... smoking or... Lots of data points. Doing these with 2 different approaches. I would want to get into quickly. Would be substantial progress in health informatics...

Stan: Yes. I think it has been painful in IMH and openEHR and 13606... I think you are right. I appreciate the work people have done. Will have advanced the...

Thomas: I didn't see it coming until a few months ago.

Stan: OK. I will send out a message. By consensus, will focus on 2 and 6. And Option 4 - a variant on 2 or 6 if people want... strategy as opposed to constrained. You have the list, Thomas.

Thomas: Should I send to you now?

Stan: Yes. We need at least 2 models - 2 and 6. And some example models from the list. Can you do that? Don't want to over-enlist you.

Thomas: I am happy to do it.

Jay: Thomas - you need help with UML version?

Thomas: Well, we have... that Michael van der Zel did... He generates... It was 30 minutes for me to make a new one. If can get Michael van der Zel and give (BMI's?), then he can generate for me.

Stan: So should we end early?

Gerard: Nice. I want to give an update from colleagues in Valencia(?)... about at-codes. I hear no negative sounds other than look at consequences. But they like the idea.

Stan: So - Is a good direction. Will need to look at.

Thomas: So I will get workbench out as fast as I can. The only final thing - whether move value sets into terminology, and the more I think about it the more I like it.

Stan: I like that...

Thomas: How the hell did I not think of this 10 years ago?

Stan: Linda - anything to add?

Linda: No - I will send...

Stan: Did you incorporate Thomas' version of...?

Linda: ...No, has Thomas' version.

Tom: We are doing research on the fly... The one on the screen is the best version...

Stan: So Linda will send out updated version.

Slidedeck as described below

[Slide #1] - Options

[Slide #2] - Option 2 - Entries & Clusters: Pros and Cons

[Slide #3] - Option 2a - Entries & Clusters

[Slide #4] - Option 2b - Entries & Clusters

[Slide #5] - Option 2b - Using Lab Results Pattern

[Slide #6] - Option 6 - Compound & Indivisible Statements

[Slide #7] - Option 6 - Compound & Indivisible Statements

[Slide #8] - Option 4 - Entries With Links

[Slide #9] - Option 4 - Entries With Links

[end of meeting]