CIMI MTF Minutes 20140213
CIMI Modeling Taskforce - Meeting Minutes
- Stan Huff
- Gerard Freriks
- Harold Solbrig
- Deepak Sharma
- Jay Lyle
- Patrick Langford
- Rahil Siddiqui
- Sarah Ryan
- Thomas Beale
- Joey Coyle
- Eithne Keelaghan
- Joint meeting with SemanticHealthNet March 13-15 in Brussels
- Panel modelling examples - Thomas Beale, All
- Any other business
Detailed Meeting Minutes
Stan: Quick mention of SemanticHealthNet meeting. Then examples Thomas sent out. Joint meeting March 13-15 in Brussels. You should have received information on this. We did a lot of work on the agenda. Hopefully we can distribute soon. Questions?
Goal for Joint CIMI and SemanticHealthNet Meeting
Harold: One quick question of SemanticHealthNet meeting. What is the Goal?
Stan: To find if there are areas where SemanticHealthNet and CIMI could work together or reuse existing work in projects. Also, to have a discussion, with Deepak Karla, on revision of 13606, and how CIMI or SemanticHealthNet might impact that.
Stan: Should be interesting. The third day - Saturday - is when you present on AML, Harold. But the rest of the day is on how these models get used... How integrated into commercial software systems... all of that. We are inviting companies and other organizations to discuss how to move from these models to implementation and "how do we help healthcare". Other questions?
Stan: OK. I'd like to now go to Thomas. And thank you, Thomas, for doing this work.
Panel Modeling Examples -Thomas Beale
[Shows models on screen]
Thomas: You are not seeing the exact models I said I would do because I got into... So, some of Michael's... BMI-related example is the one I did first. So you don't see Hematocrit... But this is a direct analog of that.
Stan: Yes - you are right. Good examples.
Thomas: If I had more time... doing the ante-natal exam is a good one. Gateway-type of encounter that gathers all the pieces... But Hematocrit is good, too.
Stan: Yes. So I am good with the examples you are doing. So we can start here. This is an intro-page that Thomas created.
[Screen Display - CIMI Entry-in-Entry Modeling Pattern]
[On Screen - CIMI panel in panel example - BMI]
Thomas: So the point is, you have that compound entry... It can have parts... This concept - I don't know if I agree with this... But you can have a free hierarchy of entries... considered to be a panel... including bedside and nurses readings. A compound entry can have more readings and a compound entry can have fine-grained data and a tree...
Stan: So, to comment on Ref Model. Part of the discussion - if we want to put some more content on entry, even though abstract-type. We might say... either for a compound or indivisible entry... The contents have to pertain to one person's record... Rather than entirely from... what the other attributes can be.
Thomas: I think that is one of the main entries. Should put... constraints... I use the example of the patient... Think about this model.
Thomas (cont'd): So, taking BMI - general use-case - expect to have a height and weight would be entries. Each is atomic... Index cases... Scroll down and see... Michael put this up a year ago for Results-4-Care. So, contextual-data. Not make sense on its own. Needs to be with something... So body and clothing would be a qualifier/modifier(?), and... So have a height and weight archetype. Record the height and weight of patient. So we want BMI. So BMI - a third item... it is weight (kg) divided by height (m) squared.
Thomas (cont'd): So to do from the archetypes we have, we need to create a template... Tells the tooling in the downstream... It is a data-set. You can see the source - structure of the weight template. Click on the first thumbnail...
Thomas (cont'd): A template on an archetype inherits from the archetype. The template keyword is the first keyword. Inherits from body-weight archetype. You are forced to say what class... you can use....
Thomas (cont'd): A body weight template inherits from body-weight archetype. Is recognized as a template... Can flatten it... You then get the archetype - not interesting.
Thomas (cont'd): I highlighted a couple of paths - down to numeric value of weight... and units. If you wrote a query with one of these paths, you could ask for the data down to ... level. But we have to be clear... Query processor has to be looking at...
Thomas (cont'd): Even though you could be retrieving the containing entry... So you know - these are paths. The next bit down is the BMI. I build on archetype. BMI is a fixed concept. Clinical people would agree on it. They would get together and create an archetype. So, see two entries with extra data... Parts and entry... That is the model. So, data-piece has the BMI. So, BMI in the 25's if healthy... But it could be 40...
Thomas (cont'd): So, that is an archetype with reference to 2 other archetypes. No question about what I need. So, that is the archetype.
Thomas (cont'd): You have to still create a template. The template version of that... One the left-hand-side-version... The template is trivial. It is templating the BMI-archetype... Not need to do anything. The total... The two of those - template... when ask to flatten...
Thomas (cont'd): So, Stan, go to the middle column. That structure - follow through... You have two individual entries... You can see the data-stuff on the buffer. I could have made the BMI as a third archetype... Maybe should have done that... That is flattening.
Stan: I agree with you. I would have made BMI its own archetype because I could use here when height and weight measured together... Usually other time where they are measured separately and this case they are pointers.
Thomas: Yes... should have done that. I can do tomorrow. This is showing paths. Can make the weight and height and actual BMI. Can see on the... path... Have the weight and height archetype buried under the... These paths aren't interesting.
Thomas (cont'd): So that is an illustration of building a fixed model... Clinicians after discussing would do...
Thomas (cont'd): So building panels. If we want multi-entry tree structure... Or the lab-panels. So if Lab-panel... You build a top-level panel... I made a GP-panel... Think of it... That panel is an archetype. Top-right things... These are panel-wide data points. Below that - slots... The idea of this is to be a generic panel. You will probably build a template and fill in.
Thomas (cont'd): So that is the archetype... with slots... So, go to the next level down. GP - physical exam. If I wanted a Heart Rate.. So there are 2 paths under that compound entry. So - in that slot, I want to be filled by body weight... Don't want anything in that slot... That is all that the template has to do.
Thomas (cont'd): If you look at the right-hand-side, you see the flattened version of that. The panel-wide stuff. Panel patterns... You see the Heart Rate... So that is the result of filling 2 slots... indivisible-entry... Sort of second generic cases. Doing multi-level entries and panels. Nothing to decide at run-time... But this one - have a lab-panel archetype and plug-in. Have LFT's and those things. If can replace body weight with analytes... The result is the same... I just did not have that at the time. Body weight - I would have put a whole stack there... analytes.
Jay: So your slot will have a constraint... and put in... At flattening or run-time?
Thomas: Flattening-time. So - whatever choices you have made at that time. So XML - have body weight at that time and Heart Rate and... But you can leave open at that time for run-time to do. So if person building discharge summary, probably not know the contents until run-time.
Thomas (cont'd): So, I can knock out a Chem-7. Would look just like that... Can show as separated. That last thing - to show the RM attributes that don't happen to be... So the red lines... To highlight the fact that we have a bunch of context attached to an entry. At the bottom... all of those red lines... have some context... Actually forcing you to... those locations. The point of this is to highlight the... Probably not want to have a different patient weight and height inside another patient's panel. We need to be conscious of this. Indeed, to establish rules so tooling makes sure that no subjects in context can override...
Harold: Also - rules... Assertion to the effect that body-weight... must... examine...
Stan: That is a very interesting thought. The other is... there is an interesting interplay that is distinguished from how IMH does this. So, you have parts... Heart Rate, body weight... and have these other things - subject and... In IMH-style, there are 2 things would have been items... and these 2 qualifiers and modifiers... and the importance is... But relationship of body weight to Heart Rate is different from relationship to...
Thomas: I think you are saying... because IMH not rely on Ref Model to do that. You are going to... So that means you do it at the top level. But not do at the inner levels. I can build that as well. Just not today because I thought we should thrash out CIMI's way to do... And maybe what you say is the way to do it... So, tree structure... then qualifiers and modifiers... So... need to be clear on how to do this.
Stan: And again... the idea would be that you are making Reference archetypes that are derived from the Ref Model. And reason is because they are established... So get reusability from that. You establish pattern. So, for labs... qualifiers and contextual will be the same. So do not do in Ref Model, but you are fixing in the Reference Archetype. And that pattern is used to create all the children the same way...
Thomas: We could certainly build some sort of structure. But not sure if we have discussed this, so we know that is what we are doing.
Stan: Yes - I am jumping ahead. Questions people have?
Thomas: I forgot to say - if you match those paths up... The query process would have to work differently from how ADL... But no problem with AQL...
Stan: So - this part is identical.
[shows on screen]
Thomas: Yes - single template, so path does not bother putting in id's. But now on screen... Root-type. Now paths - you always have the archetype-id. When writing AQL-query you start with archetype-id. So, not care about stuff on left-hand-side?
Stan: So, the rest of the path exists, but no reason to say...
[Continued discussion while showing openEHR on screen]
Thomas: So that path with square-bracket... archetype-id... would find that in either id... standalone structure... finger-stick... blood panel...
Thomas: So one question is if people think it makes sense to have parts. One is true and other... So in this... does not make sense.
Stan: Yes - my next questions... What is the role and purpose of data vs. role and purpose of parts? Probably a stupid question, but why can't this order-status be inside parts?
Thomas: Would have to be themselves - entries - is probably not what you want. So that is the question... According to how the model is now.
Stan: Say again? Because they are not entries? Or have to be here because are entries?
Thomas: So, that icon is an entry. Under those parts... if look at... You can only have different kind of entries... That is why I did not go further... Must think of the consequences of this... If take that compound entry... Hanging off that - the parts... That is what your compound-entry looks like.
Thomas: I think there are other ways to do this...
Stan: I see.
Thomas: Was that model the original one that Linda proposed?
Stan: Yes. The first version. So this is saying - you could call it what you wanted, but this saying that any entry in an entry would be inside parts. And any cluster or element would be under data.
Thomas: Yes. So leaf entry... under parts... data... Stop having more entries.
Stan: I need to think about this. Had not looked at close enough. I think it is fine.
Thomas: Probably not as flexible as at InterMountainHealth framework.
Stan: Yes. So this is a nice example because having the data section lets you know that these are unique to Heart Rate and not shared context. And the assumption - if can open these guys... Can see what is pertinent under body weight.
Thomas: Yes - units and...
Jay: Only the Units, or devices as well?
Stan: Yes - the clothing, the devices... Here it is. Data has both body weight and... clothing and device... So in both examples... if open it you will see the body weight, Units, clothing, device...
Jay: But they are siblings.
Thomas: Stan says the fine-grained definition of body weight. The reason is that I have a tool... Those green dots are elements.
Stan: So I misstated... These are above and these are the parts of things that are above... Sorry - I misspoke, Jay.
Stan (cont'd): So, my question is... Going back to the way we've done things at Intermountain Health... I am trying to understand... We would have at this level. We would have put things like subject and date and time and provider. We would have put subject at this level rather than propagating into each level. That is what data means. I am thrown off by the meaning of data and parts.
Stan (cont'd): So, overall I think I like it. Are you seeing a fatal flaw in this?
Thomas: I think you need to take it and its endpoint, which is the InterMountainHealth-point. When we did openEHR, we said we know these will be modelers and... We said to standardize the Ref Model or otherwise... So if go on that theory, that is why this approach does not work as well. So if you make entry-point... an archetype... at that level... and cover... and that will work. But only work if... This model not work if different bunches of people started doing it... But in the CIMI context, it does make sense.
Thomas: So the next thing to do... replace archetype with InterMountainHealth type context-item. We would easily do that. We can build a panel... Ref Archetype... and work there.
Thomas (cont'd): I am happy to do that. I have a copy that Patrick and Joey have been using.
Joey: Patrick has them all compiling now.
Thomas: In the old workbench. You could probably have compiling in the new workbench if you take the... out. We could build an InterMountainHealth-type panel and show... So is up to the group... Reference Model... Have to decide about data... rather than context.
Thomas (cont'd): I can work with Patrick and Joey... representative... Actual panel. I think we need an entry of some kind. Need downstream processing. If don't have enough (?) the downstream tools can't see it and can't add inferences.
Stan: I don't understand.
Thomas: We've gone from entry to entry as an abstract-class to (?)... Some might say... let's make it the one thing. But then downstream tools can't see the modeling. And... 1.4 ... And you have downstream processing that is the future... turning into directly-usable stuff... Tend to do some sort of mapping. So if there was a subject, then in openEHR, we would... throw out because...
Stan: I was thinking that the indivisible entry was the starting point... The statement, if you will.
Thomas: So... Hemoglobin, leukocytes... Have mapped to cluster... Would these become indivisible-entry?
Stan: Yes. The Hematocrit, Hemoglobin... They would be indivisible entries in this new model.
Thomas: If we could agree on the rules... the forward generation... I would imagine that this whole path could be rebuilt quickly.
Thomas: So could have CIMI models mapping up with IMH. So, just a question. I see leukocytes, morphology panel... Compound-entry?
Stan: Yes - compound-entry?
Thomas: Patrick & Joey?
Patrick & Joey: Yes.
Thomas: You three know the models inside out. Some of the clusters are logically panels... So they would be compound-entries... And some would be indivisible-entries.
Joey: Would have to go through and mark individually.
Stan: We know what they are in CEML. It is when move from CEML to ADL... Did not see how to map from panel and indivisible-entry to corresponding... and clusters in openEHR... We lost information.
Thomas: I think that process you are working on should look at CEML and sometimes generate indivisible-entry and sometimes compound-entry. Something in source-modules.
Stan: Yes. In our model, the indivisible-entry is called data and other called item. So path... and compound-entry. I probably said it wrong, but... you can tell in model which is which.
Thomas: So - next steps...
Stan: I need to think about and talk to Joey and Patrick.
Joey: Patrick and I are using the models that Linda created so not coming from our...
Thomas: Linda had models?
Joey: Modeled in Mindmaps. Patrick able to generate... She was very meticulous about Mindmap, but we still had to fix a lot of stuff. So to go to... Hopefully, we can use... and then use your editor... and go from there.
Thomas: I don't have... But I have converter with the new id's... the beginning point. You could do an archetype at a time. Batch-converter... Can then press the same button.
Patrick: That would be handy.
Stan: So I would like to visit with Patrick and Joey and think about this. How to put in bigger roadmap... We are going from these models to FHIR profiles. Have to think about the Mindmaps... to what we want to generate in terms of FHIR profiles.
Thomas: One of the things you can't see here is... JSON and XML... We are thinking of... Flattened... JSON and XML... Have to do a couple more steps first.
Stan: My intuition is that this Ref Model would work coupled with some rules and... Reference... Rules on an individual model.
Stan (cont'd): Another questions. Is it appropriate in part of your process to make archetypes from archetypes, or only templates from archetypes?
Thomas: You can specify...?
Thomas (cont'd): Look at what Joey and Patrick have generated. Will get quite deep in CIMI... More than one level... That is ... blood, sweat and tears of making this work.
Stan: Yes. So let's talk internally and exchange email and talk further. The first decision would be whether we like it. This is good model, but needs... more constraints... or... Ref-types. That is my impression. Gerard - questions? Concerns?
Gerard: I have concerns. I am taking notes. We will discuss with people in Valencia. On one hand is a solution. On the other hand - problem.
Thomas: In openEHR... If get to stage that all agree... Build panels, and... then... If can't do that, we are in trouble. Probably come down to making sure enough markers and categories... If use IMH... Then a mapper... generate an openEHR... So is enough information on this. If don't do that, then CIMI-side is... If can't take CIMI model and generate CEMS and 13606 and openEHR, then we need to fix something in CIMI-land... Will have missed something... But if we get it right, generate openEHR archetype... then... If we can prove those two - If we can show what it takes to write the converter... Then have this proof of usability.
Stan: Yes - that is the goal. That we can generate those 3 classes of models, as well as others.
Stan (cont'd): OK. It will be important for Linda and Rahil and others to understand. So they should be able to look at what you sent out and link and they should be able to ask questions. Thank you, Thomas, for all the work you put into this.
Stan (cont'd): Harold - have any questions regarding AML?
Harold: Yes - I want to talk with Thomas off the call about this. So, talk to Thomas after call.
Joey: Thomas - the new workbench - can you send us a link to that?
Thomas: Need a couple of days.
Joey: He is using Linux, so can send that.
Patrick: Yes - Linux.
Thomas: Probably in a couple of days.
Patrick: I use a Linux-build now.us...
Thomas: You can be the alpha-version.
Joey: The email you got today - all the ADL should compile in the old workbench. Do you want to convert those, or send us...?
Joey: I thought you had a command-line...?
Thomas: Yes - I could. Yes. Good point.
Joey: Or you can convert for us and we will use in new workbench.
Thomas: Yes - or put in new workbench so you can do... OK. I will convert... and give you copies.
Joey: OK. So generating graphical views... You generate Mindmaps. How do you do this?
Thomas: Yes - I did not answer that because I need to get a hold of the guy who did that.
Patrick: It is Freemind.
Stan: Anything else? Thanks to all.