CIMI MTF Minutes 20140213
- 1 CIMI Modeling Taskforce - Meeting Minutes
- 1.1 Attendees
- 1.2 Draft Agenda
- 1.3 Detailed Meeting Minutes
CIMI Modeling Taskforce - Meeting Minutes
- Stan Huff
- Gerard Freriks
- Harold Solbrig
- Joey Coyle
- Thomas Beale
- Sarah Ryan
- Jay Lyle
- Patrick Langford
- Deepak Sharma
- Eithne Keelaghan
1. Joint meeting with SemanticHealthNet March 13-15 in Brussels
2. Proposed solution from Gerard
3. Panel modeling examples - Thomas Beale, All
Detailed Meeting Minutes
Joint Meeting: CIMI-SemanticHealthNet - March 13-15 in Brussels
Stan: Simple agenda. Hopefully a lot to discuss. March 13-15 is the joint CIMI-SemanticHealthNet meeting in Brussels. Questions about this?
Stan: First on the agenda today - Gerard proposed a solution using current Ref Model. And Thomas has more...
Gerard's email re: a paper on the mapping of IMH CEMs to openEHR Ref Model
Stan: So - Gerard - describe to us what you are proposing.
Gerard: I sent an email, but it was from Geraldo Bryce in (?). One of his students spent a year at Mayo mapping from IMH to openEHR, and Geraldo sent the draft of paper to be published and he sent me the diagram. It is relevant to our discussion... So, on the left-hand-side (LHS) you see the CEMs... And with his tool, this is how his panel is mapped. He thought this the best solution. Mapping CEMs to openEHR Ref Model. And you can see the composition... And within the Section he is using Entries, and there... simple statement from CEMs... and on up. That is what he proposes.
Stan: Is this consistent with your summary of discussion... with 13606 discussion?
Gerard: Yes. This is one of the options that was considered. So - nothing more to say. Composition-section... he considered a good solution. When followed Option 6... Entries... Shared attributes from indivisible... in Compound Entries. When re-allocating attributes... Was in my email of last week.
Stan: So - can talk about this and then look at Thomas' example and then have a general discussion. So, composition contains one section in a given panel... And one diminished statement in a panel?
Stan: So - at least 2 kinds of sections. Because to turn into panel... Section is a general label to organize... Whereas a panel really is... A CBC contains Hemoglobin, Hematocrit... So physical exam section can contain anything from physical exam.... is open-ended, So, if do this, then need to distinguish between open-ended section and those with this ... content. Is that what is... 13606 and openEHR?
Gerard: The section is... no (?) meaning. And can only create meaning in Section... have entry that contains it. I am not telling you that what I see is what I want. I am just sharing.
Stan: So - what do you think best solution is?
Gerard: For me - one that does not require change of 13606 Ref Model. Where totality of panel - create separate entry... can create... what you want to summarize... This solution involves duplication... Some component into additional...
Stan: Is your solution different from Options 3 or 4?
Gerard: I think it is there.
Stan: So... let me get [options on screen]
[Shows Option 4]
Stan: Is this close to what best solution is?
Gerard: Yes... and can duplicate.
Stan: You can duplicate part of this, but cannot put this entry in this entry.
Jay: It duplicates the subject and data.
Gerard: Yes - those which you think should be in...
Stan: Oh - You mean...
Gerard: Yes - Duplicate is an option...
Stan: To be clear... your best selection... Is this the same as 13606 preference?
Gerard: No. It is my preference. In discussion with 13606, ...want to avoid change in Ref Model.
Stan: OK. Just should not change Ref Model.
Stan: OK. Guess the trick is... until you get to details, I don't know how we satisfy requirements and do all of those things. But OK. I have a better understanding. Other questions for Gerard?
Stan: So - Thomas? Make you presenter?
[Delay - Thomas' "GoToMeeting" died]
There is another meeting before SemanticHealthNet-CIMI meeting
Stan: So I received notice that there is going to be a meeting before joint CIMI-SemanticHealthNet. Is it in the afternoon the day before the meeting?
Gerard: Yes - after and early part of meeting and includes dinner.
Stan: I get to Brussels in the morning on Wednesday.
Gerard: It is in the same hotel.
Stan: Great. Need to register?
Gerard: Yes because they need to know how many will come to dinner.
Stan: If I do not want dinner, do I need to register?
Gerard: It is part of the meeting. It is a buffet. So we eat and talk.
Stan: OK. I will register.
Gerard: And the meeting ends at 8pm, I think. It would be nice if you were there.
Panel Modeling Examples - Thomas Beale
Thomas: Did not get as much done as I hoped, but here is what I've done... I will show you the composition approach... No, I'll do Entry in Entry...
Thomas (cont'd): So, we have RBC count... archetypes... indivisible entry... See on screen?
Thomas: So, have 3 of these. Then I made a panel which is a Compound Entry... Is lab-result panel. So the idea is... same as last week. A panel = a Compound Entry. Probably needs to have some sort of Subject - I put one in... Remember, have data and parts - current model. In data - other types of... So I put a few things in... Abnormal interpretation, Request order, Panel status. Then, imagine we have 2 levels. Indivisible Entries... So, these... highlighted ones on screen... Have slots... So, indivisible entry can go here.
Thomas (cont'd): I will quickly show the ADL. So, the data is where the panel-level context is. And slot for indivisible entries... If want some tree structure... So, under parts - indivisible entry. Hemoglobin and Red Cell Count. So might put some meaning to second level. White cell differential. So that's the form.
Thomas (cont'd): So I'll show ADL. So if I flatten the structure, you'll get the result of everything. Ignore the slots - it is inherited. So - the entries of blood panel... There are 3 things. White cell differential with Lymphocytes... and at the top - have Red Cell Count. So each type is one single Hemoglobin... Have an entry for each logical analyte.
Thomas (cont'd): I could have produced another panel template that... So the question is, about this context stuff... If you built it properly... If you put differential down... The question is, can you re-use the context... How can I get the context here? I could build a template. Could say it has a cluster context... So it would be possible. Participation... does exist on the single level. Could template that. Need to... to do in clear fashion. Maybe I should stop here.
Stan: You are breaking up again, Thomas. You asked for our questions?
Stan: I think, looking at it, the overall pattern looks right. Would answer all of the requirements... So would have to make statement about what goes on with context... a panel above other panel. And idea about entries... In any entry there should only be one subject, for instance. And what that would mean is - if subject is specified at this panel level, then not down in contained panels. But... how Query...
Stan (cont'd): Trying to support [the following request]: "Give me the lymphocyte count for [patient] Stan Huff. " And should return... whether [it is] stored in a panel or in panel which was in a panel. And there might be other participation. Don't know if that makes sense. Might require that all information from single source... Not some filled by nurse and some by other... Could also say... All that is contextual, only stated at indivisible level... So subject repeated at indivisible... Even though common in panel... That is what I see as questions.
Thomas: [can't hear - Bad Reception]
Stan: I can't understand, Thomas.
[Discussion while Thomas tries to fix problem]
Gerard: While we are waiting... I see what Thomas presented will work in a way... Contained its complete context... Moving out of... then it lost its context... How find context of indivisible entry?
Stan: What we did in defining the indivisible entries, we placed all with appropriate context in indivisible entry. And then context put at panel level. And then the way it works... when you query, if the context specified at panel level, if exists at individual level, then it gets...
Gerard: So is duplicated?
Stan: But not physically duplicated. Only logically duplicated.
Gerard: That will work. But is possible to duplicate if have... pointers. Which is one of the things that will work... Will not need change in Ref Model.
Stan: Yes. And the only comment I have against...
[Stan shows Option 4 on the screen]
Stan: Comes back to this. The only thing I see is it complicates the Query path.
Gerard: Yes. Or at a point in process of receiving information and submitting, you really duplicate it.
Stan: Say more.
Gerard: For instance, a set of... is... and is part of the panel. You store each content of... test, and you store whatever you want...
Stan: And duplication would be a Cluster?
Gerard: Or a set of clusters?
Stan: I think that works. To me, changing the Ref Model is less of a problem than figuring out how I query and distinguish things in instance from things not.
Stan: It would seem intuitive that if we modeled the one we are talking about now, Model 6 is map-able. CIMI has different model... But if map-able to 13606... is that OK?
Gerard: Yes, of that opinion. But not my preference.
Stan: If CIMI and 13606 and openEHR could all do the same way, would be best. Short of that - we agree to do differently, but have lots of transforms between... Could look at as well...
Thomas: I'm back.
Thomas: I don't think we have to worry if CIMI's Ref Model has to change. I think, the best we can do with mapping to 13606 is a clean mapping. If we have to put... Going back to question of compound-entry and indivisible-entry. The problem I have with entry, I don't think is... Would be easy to... using cluster. That is the approach I would probably do. The other I build was the composition-one.
Stan: Try to make you presenter.
Thomas: If it dies, I will put it on the wiki.
Thomas: OK - Straight to Composition-based one.
Stan: First - The idea would be... if going to do Compound and Indivisible Entries, want something individual to entries... So, entries are always about same subject. Can put in at entry level - parts meaning to being an entry. If compound-entry, is a bunch of entries about a single patient. If single entry, then one thing about patient. Subject at entry level... Shared assumptions about what an entry is. The other - idea about entry is that it is the thing that is start of query-path. The indivisible entry is start of entry-path. So I would want that to be part of Entry rather than...
Thomas: I think you said entries - start of query path. At the moment is ADL... Any archetype can be start of query-path. Not know anything special about entry. So you don't have to have an entry to have start-point of Query. Might want, but don't have now.
Stan: Not that you can't query from anything, but is query through entry, then is guaranteed that you query for something that is complete statement about patient.
Thomas: That is it. So I will do work on it. So is like what you have at IMH. So, to do a standalone for panel. If you just had a standalone with Hematocrit... just an indivisible...
Thomas: So if remodeled the... then how make sure...? [can't hear]
Thomas (cont'd): In the section-composition way of doing it, like Gerard's diagram, you end up with section context. And then end up with bottom... Depending on how arrange panel... If get your Hemoglobin... Your context... Sitting in composition... Your Hemoglobin sitting down inside.
[Thomas show screen]
Thomas: Participation... I put a section for panel context, but don't have to do.
Thomas (cont'd): So, querying is the question. Composition... the thing you query for. Might be some upsides... Like not mess with Ref Model. But I don't think querying approach is better. But might be the way people in 13606 want to model. Might want to think now generating this and a mapping-target... So have to keep in mind... Mapping target. Querying in context.
Thomas (cont'd): The last thing... the one I favor... is a Cluster... an analyte... We make an entry... as cluster... analytes... and make Cluster as analyte in it. So I will do this and show it - put it up on wiki. Will try and model. The workbench is probably stable. Have to test on Mac...
Stan: OK. I will be interested in the cluster-based approach. I will repeat this: The ideal situation is if we can have Ref Model that is consistent across 13606, openEHR and CIMI and CEMS... If we can't get to there, then acceptable if have Ref Models where... mapping... So data in one model could be represented without loss in other model. Consistent Query semantics, even if models different. Want the ability for someone developing application to be able to query and bring back data across different architectures.
Thomas: That's the question. So imagine I send my Query tool and it rewrites Query using model. And if run at IMH... want to rewrite as CIMI... I suspect that will be the best we can do.
Thomas (cont'd): Treat Queries as first-class objects... Reliable query paths. One of the things in the workbench is to generate API. Might be an API-way to make Queries work... I need to do more work on this. Get theories of patterns up online so we can have an effective session.
Stan: We continue to understand our options, which is good. But at some point... have to... Value is when we create content. I want to get past this Reference... It seems that there are 2 or more unambiguous ways to do this. If we spend too much more time on this, will not get to share content.
Stan (cont'd): So I think - take the first part of... Look at... and then talk about what we want CIMI model to be. Like 13606 or indivisible-entry or... 3 Options: 1 is what Gerard prefers. 2nd is compound and indivisible entry approach. And 3rd is Thomas... yours... using clusters.
Thomas: I think the compound and indivisible entry can be done in a cleaner way. Has a ripe idea we want to use.
Stan: So - lay those things out and discuss pros and cons and call for a vote. At a minimum is that we have a clean mapping between Ref Models. I mean - by clean - no data loss. That would be the basis to unambiguously translate Query from ...model to Query from ... model...
Thomas: I would love to show ... on workbench. API-tags. Crunch all of the paths into tags. End up with tag for white cell count value. Then tags could be the way to mediate between models. You can imagine... tags same between CIMI and 13606... Then could generate... or might have 13606 and... The tag stuff works - we use to generate Template... I am thinking about using that.
Stan: I like that idea a lot. I thought of in the context of reconciling the data in protocol in openEHR to date. IMH in qualifiers and modifiers...
Thomas: That will be... I thought of... in qualifiers and modifiers... In openEHR we can't... You do in more fluid way. If we did have qualifiers and modifiers then...
Stan: The idea came about... It would be interesting... the cuff-size used in measuring... Would be useful to know if protocol or state or... Is specifying device or patient-position. So if IMH, it is qualifier, device, and if in (?), is... So maintain the mapping. Information not lost. Lost-less exchange is possible... Is part of tagging you can do in model itself.
Stan: So- we'll have next discussion and then call a vote. We'll adopt those principles... Will... have a lost-less transformation to ... 13606... openEHR... That will be the strategy.
Stan (cont'd): I am hosting LOINC meeting next Thursday, and some will be traveling to HIMMS. So cancel next week's meeting (Feb 27). The next MTF meeting will be March 6th. After that - call for vote. Then finish up binding details. And then we'll get on with making content.
Thomas: I think we are closer than you think.
Stan: Wonderful. What else should we talk about today?
Stan: Gerard - are you OK for now?
Stan: And we lost Harold...
Patrick: There is a blizzard at Mayo...