CIMI MTF Minutes 20131212
- 1 CIMI Modeling Taskforce - Meeting Minutes
- 1.1 Attendees
- 1.2 Draft Agenda
- 1.3 Detailed Meeting Minutes
- 1.3.1 Principle #1: Reference Model should be able to support new Use Cases
- 1.3.2 Principle #2: Ref Model should have no Healthcare Semantics (e.g. Observation)
- 1.3.3 Princple #3: Healthcare Semantics should be represented in Reference Archetypes above the Reference Model (Patterns)
- 1.3.4 Option 1 - Sections & Entries
- 1.3.5 Option 2 - Entries & Clusters
- 1.3.6 Option 4: Entries With Links
- 1.3.7 Option 5: Entries with External Panels
- 1.3.8 Option 6 - Compund & Atomic Statements
- 1.3.9 Voting
- 1.3.10 Future meetings - Next 3 weeks
- 1.3.11 [end of meeting]
CIMI Modeling Taskforce - Meeting Minutes
- Stan Huff
- Gerard Freriks
- Harold Solbrig
- Joey Coyle
- Sarah Ryan
- Galen Mulrooney
- Jay Lyle
- Patrick Langford
- Daniel Karlsson
- Eithne Keelaghan
1. Entries in entries discussion
a. Finalize options and pros and cons (see attached slide deck)
b. Agree to voting procedure
c. Initiate vote on selected option
2. Discussion of "translations" as part of reference model for coded items
a. Clarification of use cases and solutions
b. Determine next steps
a. MTF on Thursday Dec 19 (if people are available)
b. MTF cancelled on Dec 26 for holiday
c. MTF on Thursday January 2 (if people are available)
d. Joint meeting with SemanticHealthNet March 13-15 in Europe
Detailed Meeting Minutes
[I joined meeting 5 minutes late]
Stan: Not meant to be Java class definition or JSON object or schemas. There is a pattern you can generate.
Gerard: But on a semantic level.
Stan: Say we decided to implement three models in XML and we had a database. We would want the models semantically to say - 2 people want to model... The purpose - to describe the logical structure of the data and the bindings to terminology. So one could query... Might be XML database or another... But the model - would use as the basis for interoperability. Would imply the containment of objects in each other... The purpose of models - to establish meanings you are trying to pass... enterprise boundary or...
Gerard: I agree. In User community - want to express a measurement as normal. That is fine, but I will never not model modification as normal - just as it is. My model - I have a series of other notes next to the model... that I call... normal... When we look at what is on the screen - is normal, but ... model has much more richness than models at deployment time. So this is... not what we should do... Should do more generic...
Stan: I agree. I am wondering why you bring it up now.
Gerard: We establish this - it is OK.
Stan: If you think we are violating that principle as we go along - bring it up. I apologize for not reading emails you all sent me. I have not had a chance to read all day. So back to the question.
Stan: 1) Recognize atomic information... [reads from slide]
Stan: 1) The reference model should be able to support new use cases... [reads from slide]
Stan: Any questions on the principles?
Jay: Good shorthand for those on the calls, but... would be useful for others who have not been on calls.
Principle #1: Reference Model should be able to support new Use Cases
Stan: The first one is a general statement. We want the Reference model to be able to support new use cases. In an ideal world... go to... data... Go to new domain without changing Ref Model. We want Ref Model to be as flexible as possible.
Principle #2: Ref Model should have no Healthcare Semantics (e.g. Observation)
Stan: The second is... This could be decided anyway. Want Ref Model not to have semantics in it, but be generally meaningful... General meaning as data structures... Not say patient or... Hemoglobin or White Blood Cell Count... Should be in item #3.
Princple #3: Healthcare Semantics should be represented in Reference Archetypes above the Reference Model (Patterns)
Archetype is above the Ref Model... into Healthcare semantics... move participants to be patients... That is what this whole screen of things is intended to encapsulate.
Stan: So far we have 6 options of how we might model the items. Definitions of collections... Batteries or Panels of things... We have these 6 and will go through them.
Jay: We went through the last time... Seemed like 4 of the 6 did not seem like good options. Will we narrow here or not?
Stan: Goal is to narrow down. Want to ask people if they have had a chance to do their homework... Something to note about Option 2 and Option 5... For several months now. Not want to do a comprehensive review, but if people have pros and cons then state them... and then want to move on to process where we initiate formal voting process. Does this make sense? We could stay with this or... we could step through then... or... Preference?
Jay: Yes - 1 to 2 sentences about each one would help. Last time - determined several were not a good fit...
Stan: Yes - I can do that. We can look at the list and I'll say something...
Option 1 - Sections & Entries
Stan: Sections are used to create CBC... and then entry-header info or shared info, and then Hematocrit, Hemoglobin... etc. Sections not intended to represent semantics. Containers... but should stay as sections, not CBC...
[Stan reads from slide-5]
Gerard: I agree. Sections do not have computable semantics. Container... already a partial semantic level... not full... But could be a solution... But as generic solution, option 1 is not good.
Daniel: Semantics not in the section but in the semantics beside the section. The panel header has... But whether you say the section is overloaded with semantics, I don't know. The panel entry...
Jay: The section there is the CBC. The bits are in entries. If looking for the panel...
Daniel: Look in the panel... information would be everything you would need. Dependency in... in section. The section name could be seen as just a name.
Stan: This style is not one I am proposing and when I talk to openEHR models, they say this is not acceptable since your attribution... to sections is a CBC-section... implies they have this content, which was not the original intent. I appreciate your clarification, Daniel... I don't know of anyone who is thinking of entries as a general...
Gerard: ...not the function of the section.
Option 2 - Entries & Clusters
Stan: So... we are seriously considering this. Panel is defined using entries. Tests defined using Clusters. Allows arbitrary levels of grouping... Con is you don't recognize atomic pieces of information... which are atomic statements. And depending on whether a single thing is... or is part of a cluster... you have potential for different query path...
Stan: Looking at right-hand-side... and you have clusters that represent Hematocrit and Hemoglobin and clusters... can assure query path is the same... anyone is defined in archetype, Hematocrit defined anywhere, but only definition is part of CBC. So query path - entry to cluster item. If want to make... would do through templating mechanism. One Con is - you have things that are entries and things that are clusters... No structural way to know that cluster here is... That is downside. The other - if define Hematocrit like on left-hand-side, where I have entry, for Hematocrit, has different query path then inside... So to keep query path - can't do style of modeling on left-hand-side. Have to be part of collection when defined. Then, put... BP's and HR's... do this by templating.
Gerard: Can only occur in one collection and not 2.
Jay: Could not create Hematocrit result as cluster and then create other archetype as slots...?
Stan: In this style, CBC is an entry. You could have something that is Hematocrit and Hemoglobin, so CBC with Hematocrit and Hemoglobin, or Hemoglobin & Hematocrit with those and CBC with those... But in this style, you should really do... Hematocrit in only one entry and then Hematocrit and Hemoglobin - by specializing the CBC or... template by creating a template with those things. But could not create... to define Hematocrit and Hemoglobin entry.
Stan: Another way to say this... You can define this type of lab result pattern and you have the elements with shared context and slot for... And you define all the clusters where I build up pattern... I select for slot fillers, Hematocrit and Hemoglobin's and other atomic...
Jay: So that gets around the first objection. Or does it get past both?
Stan: No - by making further policy statements, you get past second Con but not first. In this model, one can define clusters in clusters, but... not stand alone. Would have to indicate in some other way...
Jay: Is this an element that needs to be queary-able?
Stan: Without getting into details, it is something people meant to model in HL7 by clinical statement pattern... stands alone... is complete in its representation. Not make sense to start a query that starts an interpretation... and in other, you have a body location... and not go and query for body location unless for injection or other... Makes sense to query for hematocrit, but not...
Jay: Would not be... Hematocrit entry or CBC entry?
Stan: No - is a cluster.
Jay: Yes, but not query for the thing at a cluster level... There is context I would need...?
Stan: You would.
Jay: But not expect to get back?
Stan: Yes, you would.
Jay: So you would query for entry level here?
Stan: No. That is why we have 2a and 2b and 2c... Could copy information inside here. Logically this information is inside the cluster. When I query, all the information that is context... should be returned.
Gerard: What you see here is CBC is defined at entry level... 2a or 2b... While I think what is a CBC or panel is... at run-time... and not the same in all organizations. And focus on Hematocrit or... What you focus on most... And don't vary... We can use at design time... But not panels...
Stan: I know what you are saying. If you look at something like CBC, will see... I agree with you there. Is true of lots of things... And vital signs vary greatly. Some have BP and HR. But some have pulse ox... From a modeling perspective, those are different objects. If the contents vary, then... There is a CBC-1 and CBC-2 and there are those things... a, b, c, d... those are different things... different collections... Secondly, we do use them at the logical level as well. You can't depend on them to make interoperable software. You don't want to have to list panels that contain hematocrit to get hematocrit...
Gerard: And each panel... That is why I am not in favor of this solution.
Stan: The point is - if you do have parties that are communicating and they agree on panels contents... a minority of cases... Bu it means you can create... if agree with contents of panel... People will agree with Hematocrit, but more diversity with CBC.
Stan: You can obviate... by modeling style. Making one cluster as... The second part is not true. Can have clusters in clusters... and then what we say in Con - don't know if... cluster is complete statement and specimen description... Actually a bad example. If I had Reference Range in here... upper and lower range of normal... that type of cluster... So - I don't see any way to overcome that you can't recognize structurally.
Jay: Per Ref Model, one type of class is atomic... Ref Range example bad because would be a cluster, and you want to use atomic... and clusters are not.
Stan: Cluster... individual information and also atomic. So the fact that is a cluster...
Jay: Different in other paradigms?
Stan: Yes - especially in Option 6 - is explicit.
Gerard: Option 5 as well?
Stan: Option 3 is like 2 but solves the problem of query paths by putting into one huge archetype... by templating out the parts you don't want... Is good theoretically, but would have... to manage 90% of content for most use-cases. Not elegant.
Jay: So Hematocrit...?
Stan: Would have the same problem as model 2. Does not identify the smallest piece of information. But since put all in single archetype, it has a stable query path.
Stan: Yes. OK.
Option 4: Entries With Links
Stan: Panels defined using entries... Tests defined using Entries.
Stan: Lab Panel is an entry. So... if filled out more... specialization... point to Hematocrit and Hemoglobin. Gets around entries in entries. Has links to entries in Database. This is preferred when you are creating derived data. If this entry were a body mass index... The weight and height would be independent... Is showing relationship of calculated result to... in calculation. So would be preferred if showing primary data and derived data. The question is - would it be good for... Query paths are consistent. Tests can stand independent with own... The smallest... is... Anything is queryable - is a pro for this Option 4. Overcomes the problem of clusters used in two different ways. Might have to repeat... in tests. If... would have to traverse the link. Is acceptable when there are things done independently, but... is overhead with no payback in other...
Gerard: I am in favor of this solution as one of the options. You can have as many left panels as you like. Does not change the meaning of things.
Stan: I disagree. Working system - we retrieve the panel 10-100 times more than the result. Because... so we retrieve last 10 CBC's and show in chart... Probably 10-100 times more often than Hematocrit in decision-making or quality assurance.
Gerard: Archetypes are there to create Artifacts...
Stan: No. It is the fact that this... regardless of implementation... I have to traverse the link... This logical model requires more complexity in the query than...
Gerard: But in 13606...
Stan: The ease of use of the model seems to me to be the issue... Is about the logical model... Any implementation, is harder to implement.
Gerard: Would be a good way to express what you want...
Stan: If only thinking about data exchange - OK. But we are thinking about decision process in rule... more complex due to structure... If I want to write an application for reviewing CBC's, this data is more complicated than if inside the panel. The logical structure is more complex since have 2 traverse...
Gerard: I agree.
Stan: That is why we are discussing.
Gerard: An idea - if extend on the left - if duplicate result...
Stan: I don't understand.
Gerard: Have result... But also duplicates.
Stan: Violates Entries in Entries...
Gerard: But left panel - you know what results are...
Stan: You need to say more.
Gerard: First... Blood test #1... Result value... Next to link #1...
Stan: Oh - I know at this level is link to Hematocrit. OK. Not solve... If copy all of this data inside of here... extend the definition of link... pointer to all data points to... tricky way of Entries in Entries... Option 6 is saying it is OK to put Entries in Entries...
Stan: I think it works, but not know why not just do Entries in Entries. I have additional problem. The copied data is not an entry but is a proxy for this entry.
Gerard: Yes - will not be queries. But if need it in panel, that is where you have it.
Stan: I guess you could make that work, but cleaner to have Entries in Entries. But would work.
Stan: But have to understand relationship between Link and Cluster and...
Stan: Glad you are being creative...
Harold: One of the Cons is Replication of the information. Would it be possible to have the context be the link itself...? Entry that carries the contextual information...?
Stan: Yes. Would have Lab Panel header... Lab Panel... Would point the Lab Panel and each of the tests to lab info. Would overcome the problem of data duplication... but at the expense of... Logically, you would need to traverse a logical link.
Harold: Why does the former of the query language have to... Why can't the query language...?
Stan: The entry we are pointing to might have a link which would have a Link... Complexity of retrieving a record with pointer rather than with data.
Option 5: Entries with External Panels
Stan: You don't have a panel. You have an order record. Create links from this to individual results... You aggregate things according to... all part of order record. Have capability in Database to remember which things done together. Like model #4, but the group is an anonymous entry because it is outside the panel itself.
Gerard: In a resource.
Stan: Yes - panels defined in an external Database. But no place in model to put information that applies to the panel. So if information for CBC... flag that says this result is complete - will have to put into each - replicate in each - or not available.
Jay: So CIMI will not mess around with panels?
Stan: Yes - we don't deal with panels. It's for the implementer... You could never create a query that uses a panel name. Could ask for lab test that share a common... So - some foreign key or... that would allow you to do the aggregation based on... themselves. That is a defensible position that we don't have panels.
Gerard: Solve a lot of problems. When decide not to have panels in CIMI.
Stan: It would make the logical world easier, but practical world harder. Because so common in my world. In a working system, panels seen like a real thing. In ours, panels...
Gerard: We have... where in essence you model processes. You... in our way of thinking, in concurrent use, you order a panel and can query for it... order a... can find... So in our thinking, you can query a panel... what was ordered... So we can query it. But we model processes.
Stan: I am in favor of modeling processes. But the question is - do you want to query for panels. The only way you can... and the fact that this... is not modeled... If I am modeling the panel, then the model is what I am doing.
Stan: In Option 5, some combinations of foreign key information that allows me... Not an element of model that... What would be modeled would be an order. Would not be a model for a CBC.
Gerard: There is a model for CBC, but have to look at outside resource.
Comment: Have to look at outside resource...
Daniel: Don't always get what you ordered. Up to the laboratory to deliver what they think.
Gerard: You know what you ordered, but... you get what you get.
Stan: More discussion about Option 5?
Stan: OK. Option 6.
Option 6 - Compund & Atomic Statements
Stan: So - compound statements ... defined as a collection... I can query either a compound statement or atomic statement. From Gerard's point-of-view, have to query paths... Can (?) or go directly to Hemoglobin. So Gerard, if want Hematocrit, I query for atomic statement. If want panel, then I query for compound statement... When I get it back I have to look.
Stan (cont'd): If I want to use Hematocrit in any type of logic, then I query for it this way... Never use path... Don't search for Hematocrit inside of CBC or inside of some other panel. There are conceptually 2 query paths, but I don't use both. Query for Hematocrits when I want Hematocrit. Don't go through collection.
Jay: So, logically... is another node in the path...? ...Xpath?
Stan: No - is an explicit assumption. Not explicitly using XPath. The implementation... creating a path that... this piece of data... I am not talking about implementation, but... So, anything into my Database that is an atomic statement, I am going to create an index... Responsibility of implementer... So can always...
Gerard: The atomic statement is the entry? But you create a class at the level of entry that is the compound statement.
Stan: Yes - you can say I have an entry class - is a compound or atomic entry.
Joey: Classification. I have issue with naming of compound statement... Over 10 years - that term is overloaded. Definition of Compound Statement - made up of a collection of elements... Anyone would not make up... on its own.
Stan: Probably we should rename.
Gerard: Name is important now.
Stan: Thanks, Joey... is a bad name... given how much we have written about it. So - this [Option 6] is the one I like.
[Stan reads Pros and Cons on Option 6]
Stan: ...requires a change to the Ref Model... Can query for atomic statements independent of what they are contained in... Using atomic label to...
Jay: What would a specimen look like in that example?
Stan: Could be a cluster that you could include either at the level of panel... of question inside atomic statement.
Jay: Would it be queryable?
Stan: No. Compound statement and atomic statement - would have to assure are queryable. Things that are collections... qualify other statements in the model.
Jay: I thought in... [Option 2]. I seem to recall specimen being... in Option #2?
Stan: that was my example. But have things that are queryable, that are clusters and not queryable, that are clusters... Specimen - might want it to be queryable... Maybe queryable in its own right. The better example of problem is complex ref range. A set of things with specific high's and low's... encapsulated in a cluster... Better than specimen...
Jay: Yes - Ref Range - would not want to be queryable... I am wondering how often have things like specimen... sometimes query...
Stan: Yes. Sometimes we've had... for example, doing ventilator settings... tidal volume and other stuff... and you think of qualifier... Qualifying things is size of endotracheal tube... Could make dependent rather than independent in model... That is a problem... But... the problem we solve is Ref Model problem... I don't know what... to say... when is something query-able... It is sometimes a hard thing to determine...
Jay: Not sure why necessary to determine that in the model... Building the model...
Stan: Could query on Ref Model if wanted to, but not logically. You go looking for Ref Models without regard to what it is attached to... If want to know how often Ref Model stored in Database, for example. But not have any clinical meaning... unless you know what it is attached to. You want to key developers to this. They see all these in library and if no content knowledge, they get lost in the body... parts of things and... We found that to be useful. And the other part - is the semantic basis for entry in 13606 as in... The semantic implied by something being an entry in 13606 and openEHR.
Gerard: ...is... But is outside of the scope of 13606... out of the care of one patient... The query... the clinical statement... one patient.
Stan: Other questions in Option-6?
Gerard: Problem I have with Option-6... You need to change the Ref Model. Is not easily accomplished for me... Not sure what ISO 13606 would do...
Stan: I talked with Dipak about some of this... Could discuss in joint CIMI-Semantic Healthnet... They recognize it as a problem. As they surveyed... when talk about revision of 13606... They did not know how to use the Ref Model in terms of clusters and entries and sections and entries... Might come down one way or other... But they wanted a solution. One and only one way to model... collection... In ideal world, we could have this discussion, but then another year would pass and I would be sorry not modeling yet... So I sympathize, but want to decide and then start making models... rather than be perfect.
Stan: So if OK with understanding the content... then... Official members of committee and... member on this call... But official members would vote. Consultants could lobby the official members... I will send out... to official members. And I think we said to rounds of voting. So if person... would still like to vote between to options for top option... So would want to be transparent... Have first round and then highest 2 would be voted on in second round. A reasonable way to do this?
Gerard: It is a way.
Stan: If you think it is aristocratic and want to open vote to all who have participated, then... OK... But if not participated...
Gerard: The vote is the feeling of the group. But formally... one has to change the Ref Model... vote in formal group.
Stan: Yes. This vote is from Modeling Task Force (MTF)... not binding on the whole group. That makes me feel better... And OK with 2 rounds of voting? And the second between 2 leading candidates? Any further discussion?
Future meetings - Next 3 weeks
Stan: So agenda - do not have time to get into discussion of translation. And we need Thomas - not on call. We plan call next week if OK with folds. Are you still working or off?
Gerard: Dec 26th not good for me.
Stan: Yes - I was planning to cancel. But the 19th - I was palnning to meet. Then skip 1 week. Then Jan 2nd...
Gerard: I am available, but many people are not.
Harold: Available on 19th, but no guarantee on the 2nd.
Daniel: Yes - 19th OK but 2nd not.
Stan: OK - Let's do the 19th, but cancel the 2nd.
Stan (cont'd): OK - March... to 13th... meet with Semantic Healthnet in Brussels... The dates have been confirmed. You should block out the dates for the 13th.
Stan: Thanks to all for a good discussion.