CIMI MTF Minutes 20131024

From CIMI
Jump to: navigation, search

CIMI Modeling Taskforce - Meeting Minutes

Thursday 24 Oct 2013 @ 20:00-22:00 UTC


Attendees

  • Linda Bird
  • Stan Huff
  • Joey Coyle
  • Gerard Freriks
  • Sarah Ryan
  • Dave Carlson
  • Thomas Beale
  • Daniel Karlsson
  • Eithne Keelaghan

Draft Agenda

  1. Update on ISO-13606 meeting
  2. Binding discussion from last week
  3. Entries in Entries discussion

Detailed Meeting Minutes

ISO Meeting - Stan's Report

Stan: ...Attended ISO meeting... More bureaucracy than any other organization I've ever participated in. Key part of meeting was... I was invited to talk to the working group about CIMI because they are in the process of revising 13606. Dipak first described the process and went through parts of 13606.


Survey - Many wanted XML and simplified Ref Model without Healthcare Semantics

Part of process was a survey to parties. Asked if they liked it and if they wanted changes... A lot said that they wanted XML representation of 13606 - wanted to implement it and wanted to use XML. Lots said they wanted it simple, and lots said they wanted examples of how it would be implemented. Lots said that they preferred a simplified Reference Model... Said that there was a lot of healthcare content ... They did not think healthcare semantics should be in the Model.

Record Entry Hierarchy - similar to Entries in Entries

Stan (cont'd): Also, there were mixed reviews on the record entry hierarchy. Same as what we are focusing on in Entries in Entries. A lot of people said it was confusing because they didn't know if they should use clusters or compositions... Not sure what construct to use.

Entries not recurse - purpose is to have fixed pattern to end recursion

Stan (cont'd): I spent about one hour talking with Dipak about the Entries in Entries discussion... He said the purpose of having entries NOT recurse was to have a fixed pattern to end recursion to tell people "this is an atomic item to store"... and tell people this is an item to store...

Key Difference between 13606 and CIMI

Stan (cont'd): So I had a chance to describe CIMI. There is a tremendous overlap in terms of 13606 and our Reference Model (RM). Big difference is CIMI is trying to produce content whereas ISO-13606 is interested in structure(?)... I think it was well received. So we talked about what they want to do with 13606 and what could CIMI help with and what would be useful. They talked about... 13606-3... Originally was to be a collection of core archetypes, but inability to agree and... finish it...

13606 would like to have some Core Reference Archetype - like our Patterns

They would like to have some core reference archetype... What we call patterns... Things that set a style of patterns... A Reference Level above the archetypes... will become a parent... will cause consistency in the children of the pattern.

Consys

Stan (cont'd): They also talked about the Consys... of patterns... A shopping list of patterns... Consys is a concept model for medicine - shows relationships... and processes... Not go into attributes or orders... but shows association between patients and order and association with billing system and cost accounting system... That was an interesting thing. I have a current draft of the concept model. Other comments?

Gerard: Yes - I am familiar. I am part of the group to see how... Consys and 13606... Standard... for our purposes we would like to use Consys as a source of patterns for archetype... And the standard models in the detailed generic way... abstract processes... How is documented... organizational processes... and 13606 is the thing that documents what is happening in processes.

Daniel: Originally based on work of a Swedish process. The model has been successfully applied on process analysis... in analyzing the specific needs in... areas. However, to derive more concrete models for this specification - was not as successful. So is probably a lot more to learn from that... style of generic and specific model for developing models on the level that CIMI would like to develop.

Gerard: The archetypes that were produced were in Sweden... I see us doing quite differently...

Daniel: To give you a clue... the Consys model used in the same way as HL7 RIM model used in development. The application of this Consys method... the framework and methodology more like the (?) type of modeling.

Gerard: (?)

Action Item - CIMI to look for General Patterns (to report by Christmas)

Stan: So - Dipak asked me to take an Action item to look for general patterns that might go into a new part 3 and he was hoping that I or another person in CIMI could give an idea of what it looks like by Christmas. I would hope others might help develop patterns... part of 13606. They talked about (?) auto-log stuff... No overlap with CIMI.

Action Item - CIMI and a subset of 21090 data types

Stan (cont'd): Then they talked about Part 1 and the need to change the data types to do a different approach... 13606 - they described the data type... But data value data types - they assumed from 21090 - but then said it is too complicated... to describe medical models and wanted to replace with a subset of 21090 data types... Wanted to do in a way consistent with HL7 and...ISO... work and I said I would like it also consistent with CIMI's work. So I volunteered IMH and John Quinn said HL7... I think want to... and also take into consideration the FHIR data types... So only try to be consistent with things people are using... 21090 data types. So another thing I volunteered us for.

Stan (cont'd): The next thing was a revision of 13606 reference model. They were thinking of taking out demographic model. Thomas - are you on the call?

Thomas: I am.

Demographic Model - CIMI approach

Stan: Welcome. They put in the demographic model and it has variations country to country... wanted to follow the pattern... archetype-able rather than part of model itself... Was one of the proposals... Also interested in CIMI approach to demographics and I said my idea of demographic not part of Reference Model but as above level of Ref model because want to (?) according to realm or Use-case...

Revision of entries, items, clusters - disruption of existing tooling?

Also - discussion of... wanting to revise entry... items... clusters as elements and other things... The discussion was people could see... where there might be a way to simplify... The other side of argument, though - there is tooling and things dependent on that and is part of 13606 and openEHR and... HL7... Even though there is the general idea that might be better to do it another way, it might not be good to disrupt tooling, but... use of hierarchy... confusion.

Stan (cont'd): Dipak did not want to make decisions about this in meeting, but wanted to write up and send to (Tc215?) work group-1... and get further clarification and ask if wanted to revise.

Gerard: At the moment, it is an issue of 3 patterns - then the issue is resolved.

Stan: I think it would make clear the use. But still a question... the current hierarchy... You could get it all done... still not clean... but I think you're right, Gerard - examples would clear it up.

Gerard: Was (?) discussed?

Stan: Yes - they said they were leaning towards having 13606 point to an external standard rather than incorporate into 13606. They put in ADL 1.4 and AOM as existed at the time, but did not like how it froze things in place. But people needed enhancements and it takes so long to get things approved by ISO and... so they said - a better way would be to say... "We approve ADL and current version of AOM, so that improvements could be made in that part of the standards... without going through process..." They like the standard but wanted the freedom to not have to go through the whole process to change. Other questions?


Binding Examples from MTF Meeting 2 weeks ago (10-10-2013)

Stan: So - Linda - could you bring us up-to-date on the binding examples we looked at 2 weeks ago?

[slide #1] - Terminology Binding Examples

Linda: ...had created the leukocytes in blood by... We wanted specialized archetypes conform to patterns. So I went back to observation level... needed before specialized cases. So - general pattern... if have observation... then... could be... a number of ways... Or thinking of the observable entity... pair. Think of the name of the observation... So have observable entity... could be a LOINC code - go into name... the leukocyte example has the quantity with units.

Linda (cont'd): Observation on its own has no relationship because... There is no current Use-case to put modifier on it. The name would be... same object... and values... observable entity. These - the result value- are probably what we need to discuss. And the constraint is from quantity-based results... Any comments on this binding?

Stan: I am trying to think.

Linda: Last week - in bindings you had, Stan - observable entity on all 3... I found to be uncomfortable because name and result-value are siblings.

Stan: Yes - my understanding of clinical finding - it is the combination of the thing and its value. So "hair color is brown" would be a clinical finding. Or "Hematocrit is 36 or 42". The combination of the thing and its value... So - it does not seem right to call this the clinical finding.

Linda: This does separate the observable from clinical finding...

Daniel: Typically - if there are results, then the current concept model specifies the attribute... and the result... qualifier... So - defining would be observable of hair color and clinical finding... is defined with the attribute. Interprets and observable... would be a qualifier... of brown.

Linda: Does interpret go from clinical finding as source concept and...

Daniel: I am viewing this on the... Let's see if I can give an example... Let's see if I can find an example and maybe... can you bring up a browser or SNOMED browser?

Linda: I have CliniClue (sp?).

Daniel: That will work. Do you want the clinical finding?

Linda: Yes.

Daniel: .. to breathe is a clinical finding and its...

[Linda shows on the screen]

Daniel: So - ability to breathe is an observable entity. And has interpretation... is the result. Whether it is good for CIMI to follow... So observation-result would be... This has only been discussed very briefly. But is how content model is now.

Stan: Any other examples? Skin appearance or skin color?

Linda: This interprets attribute from clinical finding to... What we want is... the opposite of ... I could not find.

Daniel: There is none.

Linda: Could be the reason I could not find.

Daniel: The use of... and interpretations are not clearly defined.

Linda: ...One that should be defined and is not.

Daniel: Yes.

Gerard: What are consequences of our efforts to use SNOMED when we talk about this?

Stan: Can still use proper relationship and bindings... But if trying to decompose SNOMED into interpretable and... then could not do things. Not prevent us from binding models correctly but would prevent from pre-coordination to post-coordination. So coming back to here... We want the reverse of interprets... but there is none...

Daniel: Linda says... this is the observation entry... so one could say that the top binding for the entry is the clinical finding and the... is the observable... Would be more consistent with the current version of the... model.

Linda: Are you suggesting that... to make the semantic binding the top node?

Daniel: Yes - is the result of an observation. And what is called name would be... of cluster...

Linda: But would not be able to use the LOINC codes in the ... specialization of the...

Daniel: But... LOINC terms are... the same kind of things as observable.

Stan: Yes - it would be proper to use in the value of name... when specialize.

Linda: Yes - but if specialize... leukocyte counts would need to have...

Daniel: Yes - but do we necessarily need that?

Linda: I think leukocytes by... in blood... Want to be a specialization. Not something we could do if... maps to... not clinical finding.

Daniel: If the meaning of the structure is observation result... and we are developers so could decide... and the whole... so is not really correct.

Stan: I agree. I would have been fine to leave the object general and... the value of the name to the LOINC code because... the object binding at the level and the... is not a LOINC code... really, the name of the observable. Won't find anything on SNOMED...

Linda: I guess the Use-case I am thinking of... we talked in Heart Rate example - could do queries over... archetype... brings back Heart-rate... So using SNOMED hierarchy to search over... Heart rate.

Stan: Why can't use...?

Linda: Not all archetypes will have... Takes more knowledge of the structure... If procedure... then need to look at differently...

Daniel: I think you have a... This introduces a complexity... For each model you need to know how to query, and could be different for different models. But I think it is the other way around... So some of these observation models would have a clinical finding in their top node...

Linda: If you are querying over archetypes, then... But when querying over data, then... Two different Use-cases. I would be hesitant to make querying over archetypes dependent on structure. I also think... about observable... But it is focused on his information of leukocyte... I still think of meaning of...

Stan: We could do it that way, but I don't think it is correct... Contains name and result... Don't think you can bind the name too. It would serve the function we have to do the query, but I don't think according to SNOMED rules.

Linda: I disagree.

Daniel: ...we might be being 100% consistent with the concept-model should aim to achieve... Will have to document... In the case of... and archetypes we will... In other - will be other decisions model. So SNOMED model will always be less expressive than archetype... So I feel it is not still correct, but not have to be.

Stan: Yes - not consistent with SNOMED...

Linda: Topic... is the observable entity. So Blood Pressure... Topic is Blood Pressure and concepts... all Relationships.

Stan: Not about topics... not an Index. We are using as an index. In SNOMED - model it as a...

Linda: OK. I think of it as a graph... As the strategy node of the graph... But I see your point...

Stan: But I am fine with this style. It suits the purpose in Use-case and I can follow as we produce...

Linda: I think it makes the Use-case we have defined. OK Daniel?

Daniel: I am in agreement.

Linda: Other comments?

[no response]


An Entry or a Cluster...?

Linda: I think it is important to establish the pattern... before looking at other examples. Because now can use it... If we decide...

Daniel: Is the observation... the top level in this structure... is that an Entry or a Cluster?

Linda: Good question. Depends on our discussion. I assume it is an Entry.

Daniel: Would that be two observations?

Depends on result of Entries in Entries discussion

Linda: Depends on where we go with Entries in Entries discussion.

Linda (cont'd): So looking at bindings... could map to LOINC code... Represents... and Entries... SNOMED not have anything specific enough to represent leukocytes - and may not be worth our while to develop... So notice relationship between parent and node and this node... and parent node is observable entity... or perhaps should be results.

Stan: So we gain no new information in that part of the binding... except constraints.

Linda: Except this... result... in parent... you know to look here...

Daniel: So probably the wrong question and the wrong time, but there are 3 LOINC codes. What are the differences between them?

Stan: What are you saying?

Daniel: The first is the binding of the top node... this structure or whatever it is... and the name... I seem to remember... if this was a cluster then there is no value to assign to cluster, so we need... the name. So is this same information repeated or something else...?

Linda: It is the combination of the... structure and the entry... and this is the element... So the entry will have more information... Could argue that we leave... as observable entry... But we need in the value... the only place we see test name... Do you have an alternate suggestion?

Daniel: No - just want to understand.

Linda: Comments?

Stan: I could follow the pattern and could consistently bind... I worry when we take this to implementers - they are not going to understand the nuances of why we did it this way. Same LOINC code in 2 or 3 different places in the same structure... I think this works and meets our Use-cases... it meets them... But I think it will be lost on the developer/User community...

Linda: I think... knowing which one is the focal concept... knowing which is important. So there are 2 levels of clinical findings with all the information... and the atomic bits where one is the focal concept... that pattern... I think is motivation to accept this as a pattern...

Stan: I agree with the reasoning... And exposing these issues is one reason I want... This is a simple case because is a quantitative (?) and has a different pattern than categorical findings when will get more value out of SNOMED... And gets back to your comment, Linda. If we did a different style, I would have to understand... This style produces consistency... but is not exercising the sophistication of our binding... to the (?) eye... redundant and repetitive... The other examples will bring that out... Two choices... We could say... applies to this class... Won't be consistent with diagnosis statements and procedure statements... But has the virtue of being simple, whereas other case... allows us to use the pre and post... of SNOMED...This is the tradeoff. Simple and specific, but not generalize or do something general...recognizing not get value out of relationships and models...

Linda: The more models we have looked at, the more this pattern is important. Like identifying the key in IMH model...

Stan: Yes, but... You won't always have a name... We could adopt a style where you could always have a name... could be part of our style...

Linda: Yes - would need to look at more Use-cases for that... I tried and got called out for... But should explore...

Gerard: When I transpose to how I model things, then the top level... very generic terminology... How I perceived... lab test... the name would be the name of test perceived, and the result will be the result... And name as name... So I think as I see bindings in my archetypes... I only will use LOINC in the name part.

Linda: It sounds like your model is one more level than observations.

Gerard: Similar but no use of LOINC code at all three levels.

Linda: So you would...(?)

Gerard: Yes.

Linda: Similar to pattern approach.


Must meet both requirements - to query data and to query archetypes

Daniel: This pattern - two needs... to query data and to query archetypes. Must meet both requirements...

Stan: Provisionally, this is a good style... where we have a specific way of...

Linda: To do that will have to go back and look at examples.

Stan: I think it works due to the 5,000 models at IMH. Where does it break down?

Linda: I just remember I called it name and... at IMH you call it key...

Stan(?): If redone, would not call it key... The idea that this bridges you from structural to conceptual...

Linda: Yes.

Stan: Someone will complain... not intuitive...


What will be the Process for deciding about Entries in Entries?

Stan: It is time for me to go. I was hoping we would get a chance to say something about entries in entries. I apologize Thomas - would like your perspective. I think we are getting close to where we understand the pros and cons... Once we all think we know enough, what will be our approach? A vote? Or back to CIMI membership? Could be controversial... If you could think about - what is the process? Vote and that wins? I worry about that. We have to make a decision and... But I hate to have anyone uncomfortable or dissatisfied...

Daniel: So is important... What kind of evidence would be important to make decision...?

Gerard: And Pros and Cons...

Linda: Yes - I agree... Need to have all understand pros and cons.

Stan: Yes - want to... Have same understanding that something is pro or con... Would like us all to understand...

slide #2 - Hematocrit Example