CIMI MTF Minutes 20131107
- 1 CIMI Modeling Taskforce - Meeting Minutes
- 1.1 Attendees
- 1.2 Draft Agenda
- 1.3 Detailed Meeting Minutes
- 1.3.1 CIMI meeting with IHTSDO in Amsterdam in Oct 2014
- 1.3.2 Sent out Binding Example
- 1.3.3 Entries in Entries - Discussion
- 1.3.4 [end-of-meeting]
CIMI Modeling Taskforce - Meeting Minutes
- Linda Bird
- Stan Huff
- Joey Coyle
- Gerard Freriks
- Rahil Qamar Siddiqui
- Harold Solbrig
- Jay Lyle
- Michael van der Zel
- Patrick Langford
- Eithne Keelaghan
1. Brief follow-up on binding examples
2. Entries in entries discussion
a. Review and confirm possible options
b. Create a list of agreed upon capabilities, pros, and cons of each proposed representation
Detailed Meeting Minutes
Stan: I made a special invitation to Ian and Heather, but...
CIMI meeting with IHTSDO in Amsterdam in Oct 2014
Stan (cont'd): We are planning to have CIMI meet with IHTSDO meeting in Amsterdam in October or November. We were going to ask you, Gerard, and William and... if you know of company where we might get free meeting space a year from now in Amsterdam...
Gerard: I can ask people in the University... I will email...
Stan: I think we need to get started [with meeting]. Gerard - You figured out the time zone thing... You are the only one from Europe today. Brief follow-up of binding examples. Rahil posted a lot of questions we had talked about in our discussions. Oh - Rahil has joined us.
Sent out Binding Example
Stan: Just saying - we sent out binding example and we had discussed at some length at meetings... I and you or you and Linda can send out time for a call... We need to take time to bring you up to speed on what we said.
Rahil: Sorry - Yes - I missed last couple of meetings.
Stan: I will send you a time.
Entries in Entries - Discussion
Stan: That is all I intended to say about binding. Wanted to go on to Entries in Entries or, more properly, "What does the tree hierarchy look like".
Linda: I had a chance to... what we discussed.
[Linda starts slides - Entry in Entry Discussion]
Stan: Yes - Wonderful. Let's get back to slide set. Have to review where we are and see what we've got. See if have examples correct. Want to give examples that show the best practice... the best examples for each style. And once we agree on best examples of style, then discuss pros and cons. People may value them differently, but we should be able to say these are differences... So once we have had time to talk about differences, then we vote.
Stan (cont'd): So - Yes - Linda, if we can look at slide set.
Linda: Yes - we've been calling this Entries in Entries... also is...
Linda [reads slide]: Requirements - To recognize the smallest piece of information that you can sensibly say about a patient; Ensure query paths to these pieces can be consistent; A test should be able to appear in more than one type of panel.
[Slide #3] Principle
Linda: The principles from last week.
Linda (cont'd): [Linda reads slide] The reference model should be able to support new use cases; The reference model should have no healthcare semantics; Healthcare semantics should be represented in reference archetypes above the reference model (patterns)
Linda: I have renamed... We had 1a, 1b, 1c... etc. I renamed them to #1-6.
Linda [Reads slide]: Option 1: Sections and Entries; Option 2: Entries and Clusters; Option 3: Templated 'Uber Model' - was the same as Option 2 but using a Template 'Uber Model'; Option 4: Entries with Links. Option 5: Entries with External Panels; Option 6: Compound and Atomic Statements - using Compund statement for panel and atomic statement for test.
Stan: Rahil - did you have questions about requirements?
Rahil: I think I am OK for now.
Stan: Yes - feel free to interrupt.
Stan: OK - sorry to interrupt.
Linda: No problem. OK - what I did - step through each option and find place to put Pros and Cons...
Linda:[Linda reads slide] Option 1 - Sections & Entries - Panels defined using Sections; Tests defined using Entries; Panel-level information defined in a separate Entry
Sections can't contain Elements
Linda: Here is an example... ordered... When we have a group of tests like a panel, we... in Section... Sections can't contain elements, so... I've called this CBC... We have entry...
Linda (cont'd): And... inside the... Potentially can include data elements... have a (?) role in the... Not sure how we denote fact that first entry is about panel itself and (?) is about what it contains...
Gerard: Do the Ref Model classifiers have definitions? Is there a definition about Sections that make it clear what to be used for?
Linda: Yes - we put openEHR definitions into...
Jay: I can look it up...
Linda: In general, Sections are not to contain information. Used for human navigation.
Gerard: Paraphrase - compositional to... a structural document... Don't have any semantic meaning. The entries do.
Linda: So in a way, that is a downside since is putting some of the semantics in a Section.
Jay: That is what I was getting at - put into Pros and Cons.
Linda: Should I note now?
Stan: Yes - too easy to forget
Linda: Yes. Not sure whether we should distinguish this panel... different from test results... terminology binding.
[Linda adds to Cons on Option 1]
Rahil: In regards to that - Entry in itself has semantic information... clinical(?)... In example - CBC information - what is that trying to convey - that the thing maybe the nature of the example... in itself has not any clinical meaning. Seems to be very loose in what is trying to achieve over there. If we could have this panel interpretation and the... and don't need an entry for... Is there any relevance?
Linda: Yes - Saying this information is relevant to the entire panel... Panel interpretation is a summary of that... Might have method, location or performer... Anything relevant to entire panel... All tests in panel. Information subject is traditionally... on all entries... openEHR... But if see at start(?) of panel... know that it applies to all in panel. Probably more appropriate to look at date and...
Jay: Or Maybe patient-state, like fasting...
Rahil: And I am assuming there is a relationship... defining... Hemoglobin result and...
Linda: You mean a terminal binding relationship, like semantic?
Stan: One approach to recognize that panel information is different from other entries is to adopt a pattern that we always recognize. So not call CBC information but panel information... So, now... CBC... Urinalysis... So know it is information that supplies context for all entries... Keep same through all panels.
Linda: Agree and since inheriting from observation group, might want to... specialize.
Jay: Would make it easy for people to (?). But would take away... So CBC panel might include fasting state but another panel might not.
Stan: Yes - Could we have... attribution information... archetype that information to make... CBC information and Chem 7 information... So know it is special because archetype... common information... Allows us to specialize. Know particular context for panel. Would that work?
Jay: As far as I know.
Linda: Could do in... specialization... archetype.
Stan: So - other question? Looks accurate as far a style.
Linda: One of the Pros - No need to change existing Ref Model.
Gerard: And Con is... we need rules.
[Linda adds to Cons in slide #5]
Stan: Say more?
Gerard: Need to copy data into entries of each individual test... so is complete on its own... So (?) **... we need rules to derive those values.
Gerard: So data is... panel information part.
Stan: So if search for Hematocrit and don't care if part of CBC or Hematocrit-Hemoglobin panel, then information of panel should be included regardless of how physically store it. Regardless of... contextual information.
Gerard: And now it is... rules... You define it as a Pro, Linda. I define as a Con.
Linda: There is a Pro and a Con. Pro - assuming... then we can keep consistent (?) regardless of... The Con is we need to either copy the context or ensure we can write or execute a derivation Rule to ensure that the query path can remain consistent.
[Linda adds to Cons of Option 1: Con - Need either copy the context into each test or...]
Jay: Another option. In Option 1 - Use Selection as panel container... and whether or not date, time subject is included... The interpretation must be at higher level, but the... can be at test nodes.
Linda: Is true - unless asking for panel itself. If don't have at panel level, can't ask those questions.
Jay: Yes - OK. But not need to be derived.
Linda: Yes. I'll add.
Linda: Any other Pros/Cons? All OK?
[Response: Yes - OK]
Linda: Option 2 is the original Option 1. Before we talked about Uber-model...
Linda [Reads Option 2]: Panels defined using Entries; Tests defined using Clusters
Linda: So, example is where we have CBC as Entry and Cluster for Hematocrit-Result and for Hemoglobin-result... and would have to model...
Jay: Is that necessarily so? Two things going on - Container structure and...
Linda: The thing with this is... need to separate models to... model a cluster... can add (?) and date and derive, but still need 2 models. Your paths are different... still... entry root... smallest item of information. The challenges we had with this approach. That is why Tom, last week, suggested the Uber-model.
Gerard: CBC is clear... but blood panels are sometimes defined locally and you end up with other problems. And each group... entry on Right-hand-side with different composition.
Jay: So they can publish those 2.
Gerard: Then we will have many different... with same...
Jay: Is governance.
Stan: ...Have hematocrit-result... rather than... a more generic... single result. Could have a slot where you could put any cluster... Define general model... is single result... then could template that... or maybe not need to... Could have the test name or other things in it... would not have two different paths... Hematocrit would end up being cluster in both cases. Going back to convention - is part of meaning and purpose... entry... meant specify what you can query about... The smallest things. In this case... search for Hematocrit and Hemoglobin. The fact that are clusters... there are going to be other clusters... descriptive information inside another Hematocrit... could have multi...
Linda: Yes - it is possible to have Cluster in Hematocrit-thing... Similar to Uber - model approach. Need to ensure model is... Flat (?) of tests. Never group together the ones done by machine and by hand... Could never have a subgroup irrespective of what group(?) they are in...
Stan: You are probably right. Just not recognize is isosemantic representation...
Jay: I am looking forward to seeing the Uber-model.
Linda: I did my best.
Rahil: What is the Uber-model?
Linda: OK - but will have to come back to Pros and Cons. OK Stan?
Linda: This is what I interpreted from Tom last week...
Linda: [reads from slide] Same as Option 2(Entries and Clusters) except: One Lab Result 'Uber Model' is defined, which contains every possible test; Each panel is defined as a template (or constraint) on the 'Uber Model')
Jay: Or maybe 2 or 3...?
Linda: Might be... Before use test, need to throw into Uber-model.
Linda: So...Hematocrit results... Maybe modeled off a pattern... and like you say, Jay... Then you define a Hematocrit lab result to do a single test and constrain all you don't want... constrain out... So all have same path because is... defined in Uber-model.
Jay: Confused. Looks like Uber-model is enumerating all the possible tests.
Linda: That was my understanding.
Jay: So not 3 clusters, but 3000?
Linda: Stan - was that what Tom said?
Stan: I think this is the idea, but may not be all of lab, but could be chemistry tests or blood-born... Could do what we've done here but... I guess would be a variation on what we said. Would archetype what you want to include. But... an entry for cell-count test and entry for enzyme test and would be... but cleaner since... each defined as an entry.
Rahil: Why not just be a pattern instead of having to list out repetition instead of Uber-model? Could be instantiated for any result.
Rahil: So - first entry with 3 elements... a pattern for lab results... and instantiation would be right-hand-side... and constrain out what you don't use. Seems unnecessary.
Jay: I don't know what Tom was saying, but...
Rahil: So not constricted... The pattern remains faithful to all kinds of lab tests...
Stan: Where are the things defined in that... Hematocrits... Have different interpretations for quantitative or textual... Can you just define clusters being in an entry? Where can you define?
Rahil: You could do that - depend on approach... Define as cluster model or... If use current approach, effectively you would create your entry Hematocrit based on that factor and add in constraints... But effectively... your pattern would allow... fill in the blanks... where you'd require... what I don't see is the advantage of having that huge model and then... Having to remove 2999 is absurd. So if just have a pattern and create model based on pattern then...
Gerard: If have... where is the panel definition? How find your panel? My department blood count panel?
Rahil: No - because... I don't agree.
Stan: Not think there is a need to create panels?
Rahil: No - but I think this Uber-approach is... I think the way is now... have top panel and qualitative results... Is a pattern that can be used... That is fine. But the previous... no value added. The way is done now... that looks like a pattern.
Jay: Where is panel definition - your question?
[Linda re-joins meeting]
Linda: Hello - I had 5 minutes or the meeting would have died. My modem had the red light on... We are working off... because the modem died...
Gerard: My connection died as well...
Linda: A coincidence...
Harold: Am I off an hour [Harold late to meeting]?
Stan: Yes - moved an hour earlier. But glad to have you now.
Linda: ...it would not allow you to have groupings in groupings...
Stan: My question is... We ended up with Uber-model approach because we thought would be one... And my understanding... Ref model... I did not think... Would not know what was query-safe... and reference range Cluster that would... outside what contains it.
Rahil: I don't think the clustering I was talking about... I don't think that would be a problem. But... the previous... that in itself... not see the benefit... Is a collection... All kinds of different lab results... Not really... anything you can compute... Constrain out on Right-Hand-Side what you don't want and... on Left-hand-side... Lots of exclusions... more (?) than beneficiary... Whereas if we tweaked... The pattern... not going to be... So you know you can define your Hematocrit at the entry level but if have the Hematocrit at the Cluster level - sorry Entry level... You can do that and don't have to constrain out 1000's of things... Is about that lab result...
Stan: So my question may be lack of knowledge of ADL. But pattern on (?) is that... can do in ADL... a slot... say this slot can be filled by any lab test... Cluster... Is that a legal construct in ADL of how you can...?
Linda: Yes - then those... a specialization of lab test... And Hematocrit as specialization of lab test.
Rahil: So... if we define as pattern, then can start using that pattern... Design choice... define pattern and use... or say defining... specialization of... so that is a design choice. Pattern. So... lab result as pattern, and use to do all kinds of...
Linda: So - Rahil - Is this representation consistent with your suggestion?
Rahil: Yes - closer to what... Not an expert in lab modeling, but closer to what I said. Question - do we require cluster for each, or just have the one...? And then on Right-hand-side, have a... because cluster below is not adding anything.
Gerard: Nice to have this option, but what does it have to do with panels?
Stan: We could add one more example so could make CBC... Would be like Hematocrit, but have multiple... parts. This is demonstrating nicely the query path to that item... Whether part of panel or single result.
Linda: I suspect this approach is similar to what we meant by Option 2a... observation... specialize to laboratory observation... So I think 1a(?) and 2a are linked... Cluster is result and... Need to break out into separate option.
Stan: I think they are the same thing.
Linda: This... find maximal data set... discharge summary... and constrain out things don't need.
Stan: My question - see the (?) model... Do we have a solution... if want to build collective in collection vital signs with heart rate, prenatal and fundal height and blood type and vital signs panel. Can we do that?
Linda: My thought is can't do grouping without collecting the query path... Unless you key all tests on same level of nesting... will change the... one path in one panel and another in another panel. All agree?
Rahil: I think I did not understand.
Linda: Panel within panel. ...originally modeled the laboratory results to have lab grouping and lab test... The Australian model and openEHR model had that.
Stan: Other thing - Another way for looking at it... if somehow you can identify the things that are... the smallest things that you query for... atomic statements... if you can identify, can say... the implementation must have a way of retrieving no matter how embedded. So... support a query path regardless of container.
Gerard: To me - was the function of the Entry.
Stan: Yes - the query-safe... not identified by being entries... are Cluster... the downside to this pattern.
Rahil: Could also add...
Stan: I don't understand.
Rahil: So in Option 2a...
Rahil: You have the same situation... A Cluster for... and for Hemoglobin results... So if have... If query on all results, then the results from there should appear... at... level. That is at cluster level. Or else you have slots which point to another entry - the Hematocrit result. So have CBC as entry and... slot that points to another entry. ...and for each cluster could have a definition... as a separate element... Can add semantics at both levels.
Stan: So one way could identify as query-able, at (?) result... could add "I am an atomic statement" and that is how would know that it is something I could query for... independent of container as opposed to other. Is that what you mean?
Rahil: Yes - Basically... effectively you can... part of the cluster... to be query-able.
Stan: And I think you said another solution...
Rahil: That was different example... within Entries... have...
Stan: That is another option... the Link option...
Linda: Should we skip to...?
Linda: So here is an example... Lab panel is an Entry. Have lab... # of Link point to results... refer to the order... sort of containment... Could be done at semantic binding of Links... and slight variation...
Gerard: And for the example of... ordered... I prefer this entry with Links where externally the panel is stored in resource (?) and you store the individual results.
Rahil: Where is...?
Gerard: Is external resource.
Rahil: Which you reference?
Stan: Could have a file as part of EHR which defines what thing could be in panels. And then have order file.
Gerard: Is an analog of a value set. But is a set of...
Stan: Could be a (?) that is defined as relations...
Gerard: Could be enumerated.
Stan: Example is LOINC panel definition. Is an external resource. Is defining panels. Has its own file structure. Is an external resource in Model 5.
Gerard: It does.
Stan: So for external model... The Con is you have your knowledge of things split between...
[We lost Connection with Stan]
Gerard: Semantics are on right side and knowledge - on left side. So even if don't have external resource... just when you want to group things
[Stan returns to call]
Stan: Some structural knowledge is represented in the model and some is... So don't have uniforms... is represented by some structural knowledge is in model and some in external resources. That is Con to me. I would like to have all...
Gerard: But semantics on right side...
Linda: Might be semantics about panel...
Gerard: Panel... on Left side... on Right side - semantic data.
Stan: Where is this?
Gerard: To me - separate entry about assessment.
Stan: So like Option #4 - like a lab panel. So you say... like a lab panel record... OK.
Stan: OK - more questions about Option 4?
Linda: One of obvious Pros - Cons... Not sure if we consider a Con - that need to navigate the Links.
Stan: I would say Con.
Stan: Could say implication if not want to say Pro or Con, but have to navigate the Links...
Linda: Anything else? Allows us to have different levels of nesting.
Rahil: I was wondering... Could be used to... [can't hear]
Gerard: Con side is... we duplicate things because when have panel... identical context... each duplicates context.
Linda: Yes - the opportunity to... derivation rule... they need to be stored context. Is that all?
[Linda reads slide]
Stan: And so the Con is that it is a big change to Ref Model if we do this.
Option 4 - Entries with Link [slide #18] - Option 6 - Compound and Atomic Statements
Linda: So - how is example where CBC is represented as compound statement, and Hematocrit and Hemoglobin are atomic statements... Allows you to record within group it was captured, but also...
Gerard: Can have nested compound statements.
Linda: Yes - compound statements can contain...
Rahil: But can achieve this through other ... at run-time... Can achieve the same thing. When we say an entry is Linked to another entry... Would be a compound statement.
Stan: If you read what an Entry is... is a single atomic statement or a collection of statements... and so this is... instead of things in Entry that can be 'a' or 'b' saying there are things in 'a' and things in 'b'
[Linda Shows Entry definition]
Gerard: I don't like this definition of Entry.
Stan: I think you are right, Rahil. Which of the previous models we talked about do the same thing as clearly and an unambiguously as last example - Option 6 - Compound and Atomic...
Rahil: I keep going back to... Could define the ... without needing to radically change the existing models.... Using what we have.
Stan: Which options/patterns would you do that with?
Rahil: The one with... Option 2a is example of pattern...
Rahil: So - Option 2a...
Stan: Would need to update... to add the element... which one of these statements would query... achieve...
Rahil: I have not seen entries used as pattern. If look at Option 3... At runtime, all these entries with... The model is Linking out to separate entries. Not require entries in entries... So Option 4 could be included in the pattern...
Gerard: It could.
Stan: That works, but the downside - have to have your navigation in the Links. Have to say if wait to retrieve the Links or traverse and bring Link contents. I find that not desirable.
Rahil: But if you look at... Used... other archetypes... The whole principle in openEHR... to achieve the... This is not new territory... existing methods.
Stan: Well - Yes and No. In our system, the retrieval of that panel is most common thing we do, and... Links between... finding and the order. I traverse the Link... not most common... Is do-able... Traversing Links for most common Use-case, but not.
Stan: Have to deal with in logical query. Have to say whether retrieve and Links... or retrieve data and return... Logically you have to deal with when query. So... this is to the point where some people might say they are... so willing to deal with complexity. And other might say... I don't have a backlog of things so want more simplicity...
Linda: So - from - here - should consolidate additional option with pattern and path using clusters... and (?) and once done that and agree is a case of all understanding the option... and maybe should vote out some and end up with 2.
Stan: I think it gets clearer and clearer... I'll talk with Thomas. If you could send out current version, Linda, I could use as talking point.
Linda: And Jay - you were asking for slides. So will send out...