CIMI MTF Minutes 20130801
- 1 CIMI Modeling Taskforce - Meeting Minutes
- 1.1 Attending
- 1.1.1 Draft Agenda
- 1.1.2 Detailed Meeting Minutes
- 1.1.3 Professionalism in Emails and Public Correspondence
- 1.1.4 Entries in Entries
- 1.1.5 Review of Decisions from Last Time
- 1.1.6 CWE and CNE
- 1.1.7 URI's in Models for Terminology Binding
- 1.1.8 Six Points Stan Wished Captured in Meeting Minutes
- 1.1.9 Cluster Level Relationship Binding
- 1.1.10 Plan for MTF Meetings in August
- 1.1.11 Next Meeting
- 1.1.12 [end of meeting]
- 1.1 Attending
CIMI Modeling Taskforce - Meeting Minutes
1. Be nice in emails and on the listserver - Stan
2. Entries in entries (update only, we need more preparation before final resolution) - Stan
3. Review of decisions from last time:
a. Do we model common things as they are typically found in existing systems, or do we make them logically consistent, in terms of choosing the "preferred" CIMI model out of the iso-semantic family? - We prefer the most granular representation (tempered with some principles around common levels of granularity
b. Do we need to represent static versus dynamic binding? Yes
4. Do we need to represent CWE and CNE bindings? (Yes) Text vs CodedText + Best practice rules.
5. Reference model implications if we use URIs in models for terminology binding - Harold
6. Do we give the same binding to the cluster as for the focal element in the cluster? (effects the complete binding - including both the relationship and object bindings)
7. How to represent an "X or Y" Object binding (e.g. "|Clinical Finding| or |Event| or |Observation|"). Do we create a CIMI extension concept (I'm not so keen on this as it changes the inheritance of all the descendant concepts) ... or allow the Object binding to be repeated in the ADL to indicate the alternatives (my preference ... but we need a syntax).
8. Meeting schedule
a. With holiday/vacation time upon us, will we have quorum for meetings in August?
Next meeting: 29th August or 5th September
Detailed Meeting Minutes
Professionalism in Emails and Public Correspondence
Stan: Virginia Riehl and others noted to me that emails were getting "unprofessional". We need to be kind and... careful and polite in email communication. If want to yell at each other on phone - OK - but in public - be professional.
Entries in Entries
Stan: Entries in entries. Lots of email on Listserv - haven't had a chance to read all of it. Some messages were useful and clarifying. Also, Thomas Beale and I spent about Â½ hour to try and share experiences with this... me at IMH and he with openEHR. In the end - the way to get to bottom of this - people have proposed - we need a CIMI definition of clinical statement or nodes... Glossary should help... Need to add to if needed.
Stan (cont'd): Second - I will only understand this if we start with the kinds of data we want to represent and say "These will be clusters or sections or entries..." and then say "if we allow entries in entries, then will look this way". I need to do more homework and... We need to see... and then have solution.
Stan (cont'd): Might seem philosophical... But underneath it is very important... and we need to understand options... and we need to make a decision, so all will understand impact and implications.
Stan (cont'd): So - summary - looks esoteric but is very fundamental, and we need to agree on strategy or will end up with ambiguity and complications that are hard to deal with. I hope in a few weeks - I will have done my homework and communicated with others and we can bring his back and make a decision with the group.
Gerard: I agree - fundamental issues. I discussed with Dipak. We are against entry in entry. There are other solutions - others agree. But have to deal with context in context... The world is fractal... I agree. I thought about "fractalness" and sent around thoughts and ideas to think about.
Stan: If you have good examples, this is helpful. Maybe one or first things to do is to state what are our assumptions and requirements that we need to solve. ...else will not be able to agree on solution. Other comments?
Linda: Stan - I agree with you. Part of documenting assumptions and requirements is to look at Use-cases.
Stan: Yes - use cases come before requirements. Other thoughts?
Stan: OK - next item.
Review of Decisions from Last Time
Pre and post-coordinated
Stan: So last time we talked about doing things pre or post-coordinated. We said - this is another example of method where preferred method is the most post-coordinated model. That was tempered with the fact that...
[Lost connection to Stan]
[Stan returns]: ...There are certain boundaries on post-coordinated that people don't go over. If look at SNOMED observables or LOINC codes - people don't just say "glucose", but say "glucose mass concentration". We would make a decision and say "this is the level of (?)... But will choose all the LOINC codes where we choose post-coordination". Saying there are some boundaries... some things don't make sense... to go into fractal(?)...
Linda: Also, decisions about things that are commonly pre-coordinated, like CBC... It does not make sense to do CBC, and then repeat blood.
Stan: Yes - how to populate a data instance according to our... - Gerard?
Gerard: [can't hear]
Daniel K: Need to make a case for every example. For post-coordinated - patient-safety issue. For..., might be another case that has to be described.
Stan: We stated the general rule. May come to hard cases where we need to make a decision. Now we are saying - a general rule is for the post-coordinated... We will see where that leads... In the end, we want it to be right even if not conform to the general rule.
Stan (cont'd): This was meant to be a review of last time.
Static vs. Dynamic Binding
Stan: Next - Static vs. Dynamic binding. This may not always be used. May only be in localized models. But we decided we needed a key word to say [it] was static - a Ref set - or was dynamic - at any point in time... what in set is allowed... So we decided we had to say...
Linda: We haven't yet agreed on version. May be as easy as saying it is...
Stan: Might border on... things that Harold is going to talk about... whether have version numbers or not...
Harold: If include a version number of terminology, that is in effect a static binding. At any point in time, you can change and fix the version number. Have to include in the model.
Stan: So - any other questions?
CWE and CNE
Stan: Did we get to CWE and CNE? So "Coded with Exceptions" and "Coded no Exceptions" - from HL7. There are some fields that determine behavior of software. Coded fields need value from value-set or are not useful. Says coded set needs one of these values or whole record is invalid. Other cases where this is not true - use code that applies... Choose code from entire terminology rather than... CWE... Is a coded field except... allowed to... in place of one of the standard codes. This seems like something we need.
Linda: Related topic - if allow specialization. If we allow that - code with exceptions - then add parent... and specialization can be included... Cases where want code and...
[Lost Connection with Stan]
Gerard: I am neutral.
[Linda cutting in and out]
Linda: I was saying... "Related topic"... If we do allow specialization of reference set allowed, one way is to include parent set... But if wanted to say no specialization, then...
Stan: My translation. We allow definitions of value set and we could specify in binding node... This set... Where the body parts are extremities... Not make new value set, but make constraint statement that... allow in that field. Is that another way of saying that?
Linda: I missed part of that...
Daniel K: ...Given we have a way of binding what is the Use-case presented?
Stan: Could we take one at a time and talk about CWE & CNE and put the question that you raised, Linda - a new question. It might help to make examples to make sure we are saying the same thing. And it might help for Daniel to educate us with SNOMED.
Gerard: What is functionality of terminology set? I don't know where to place functionality... in terms of value set. At moment, I have not used it. Other - use coded text so use text or code... So it is something to think about.
Stan: Most is from HL7 discussions. If you assume value sets used with same sort of purpose... assume this field is... the CWE or CNE... characteristic of binding set... in HL7 - value sets could be reused and in one context were... and in other were... So be part of... [can't hear]
Linda: So most agree that we need it. But what is the solution... that is the question.
Stan: So - put in parenthesis. And you could come back next week, Gerard, and argue against this.
Daniel: I don't know implications of CWE, CNE, but hard to think of case for CIMI model to allow exception... a general rule that we don't have exception, but...
Stan: For interoperability - tend to more strict bindings. Can't have interoperability if you can throw in... field. Especially in life-cycle of mode... 20 different things, but after design you think of others... Probably want to have best-practice rules... May want to be judicious how we use.
Harold: Yes - if for input validation - one thing. But if transferring things back and forth... As consumer - do I need to expect both text and codes?
Harold: Different from text not coded yet. If send out, then probably not ever going to be coded.
Daniel: Coded text data type - don't they allow similar function? So, text field - either text or code. I don't remember the name.
Harold: We have type text-abstract and other. Plain data-type - concrete. And... if say data type is text, you have to supply code.
Linda: As you say, if text - could be coded or not coded.
Harold: Text - abstract-type... Have to do something with model if allow both.
Gerard: I interpreted - allow text or code.
Linda: I discussed with Tom about abstract. He said... could be... but... No one instance could be both. Text in model could be codeable, but each instance chooses what it is.
Daniel: So - coded with exception?
Daniel: So - through (?) binding we decide what code is allowed?
Linda: Yes, and whether static or dynamic.
Stan: So, in the model - you could make something text that... What I am wondering - if this covers the Use-case. As we have implemented in our model - it is a run-time decision.. So - at run-time, user decides. Is that this?
Linda: Yes - In model, if want either, then text data-type, and (User?) decides.
Gerard: But if want at design-time, can do as well.
Daniel: If give... data-type, then want to constrain code if they are used.
Harold: Good point. I want CWE... anatomical codes. But can't do since there are no codes.
Daniel: Do we still have the choice data-type or... can choose one or the other?
Linda: I think choice is a function of AOM.
Daniel: Then you can do that... [can't hear]
Stan: Handled in...
Linda: I want to confirm that it is not handled in another way. We should investigate...
Stan: We also need idea of CWE and CNE. But need best practice rules and further investigation to make sure not need... to contemplate the... Reserving Gerard's right to come back with a better decision. So tentatively say 'Yes'.
Stan: OK Harold - URI's...
URI's in Models for Terminology Binding
Harold: I was focusing on Text.... coded-type. Discussion today...
Harold: ...I start out with definition of code...
[Harold reads slide]
Harold: When I start to put in URI's, the relationship to codes is... First change I want to make is to differentiate... parsable expressions from simple code... I would argue - we need another type, so say "Here we get weird stuff"... The processing is very different... Other proposal - to use URI instead of code. We have not been able to arrive at... for years... If switch to URI's... in our world we could potentially come up with...
Stan: Do you want to discuss this as you present?
Stan: I am in favor of your code expression from single code. We would have a choice whether coded expression type vs. coded text or coded expression into text or single code... The parsing is done for you.
Gerard: I consider partial expression as equivalent of a query.
Gerard: A parsable expression I equate with query - has to be processed... I agree... Need to distinguish between parsable expression and... code.
Harold: Also have to settle on grammar or parsable expression has to include mind-type(?)... So... make distinction usually... You can have whatever... making... as consumer... I have to be able to deal with expression in unknown language - not comfortable with this.
Tan: Others - opposite opinion?
Linda: No - I agree.
Stan: OK. So - Harold - may need to come back with...
Harold: Question is - do we need it today? OK. Second - this is core... To use a URI to identify... Some of our discussion today... So what I am going to do is move to Code-Proposal...
Harold: So I propose coded-text have a URI... Prefix name - out of ... specification... So example would be... "sctfsn.appendicitis(finding)" Scope name is derivable from URI. But URI - primary source. Terminology ID has 2 uses. But code in first... Not really a terminology id... really... Important. In CIMI - have been assigned a code... Some will only be defined in CIMI extension. So if we say "go to", they won't...
Stan: Not create a problem for me... well, maybe it does... Not sure. I am thinking if these are local to CIMI... I could be referencing... I could be referencing the ones that are CIMI only from... universally in cloud.
Harold: SNOMED serves 2 useful but different uses. SNOMED namespace allows us to define... concept codes... whether... The second thing is different. Have to know - do we have to go to CIMI... Where go to find out more about concept? I am proposing we not embed this in the data. The reason... URI would be identifier... The reason I mark as derived... It is computable, but is happy to... So let me go on.
Harold: The second part is terminology and version. Two possible code strings here. Text value and the term. It is a bit of a challenge. What I am proposing - separate namespace. The terminology and version - is it qualifying the code, the text value or the term?
Harold: When I have terminology and... version... I would be saying... when I picked up this value in this language... could be saying it came from here or here...
Linda: Assume... the code...
Harold Documentation says code-string.
Linda: I think a historical artifact from openEHR.
Stan: I agree with Linda - is qualifying the code. Also is qualifying the term... I don't know that. The term... would be...
Linda: Yes. The text value is the coded text, whereas the...
Harold: My question...
[Harold reads "The string of characters associated with the code_string from the given terminology"]
Harold: So implies text... Value may already be the term... It is ambiguous what is going on.
Linda: I think it was suggested to avoid... So always put value... Otherwise - explicitly state... When it says value... term... openEHR...
Harold: So code-string refers to code?
Harold: OK - This explicitly references the terminology. So the namespace equivalent of terminology and code... So I think need another go-around...
Harold (cont'd): I came up with the notion of designation. But I had not... that text could be CWE... Might not be in terminology. So - term does not have a language. Could have a language out here...
Harold: But we need...
Stan: Somehow I thought coded-text would inherit language from text.
Harold: It does... Have to have value...
Linda: But don't know language of the term...
Harold: Hard to do in LOINC. So - you have a designation.
Harold: I am saying... I want to make this... a coded-text has zero or more designations. Might want to carry English and French designation.. And there was a... that must be specified. Not the SNOMED CT model. Could get US-English or British-English... and 2 flavors of Spanish... So I disagree... Language is a function of the designation. So I break the CWE idea.
Linda: Why designation have specification as text...?
Harold: Wanted to... add to possible... The source... and the actual-term id.
Harold: If revert to that aspect in model, we need to... That was the string of characters... Term does not have a language, but text does... We are overloading text... If term is missing... The unique identifier... If both text and term are present...
Harold: Let's go ahead and set-up... Instead of having 2 possible coded texts... Can cut down to zero... Would be useful to have many designations if... available.
Harold: Because I added helper classes - was messy. So I added... I am like a bull in a china shop....
Harold: #1: Do we need code expressions now or can we postpone?
Stan: I don't need them today.
Harold: I am assuming a code expression is a data type for... vs. data-type that is... [can't hear]
Linda: Yes - Reference model is about representing patient-data.
Harold: OK - I am not aware of anyone who is... expressions...?
Linda: Except England - doing natural language processing, but...
Stan: The reason... for asking... You think will take a long time if add or... Not change number of Reference model?
Harold: I am trying to steer clear of "what if" model... Keep lid on that closed.
Stan: I like the...
Linda: Are you saying if we introduce... we will also have to introduce code-expression?
Harold: We would not have... Take multiple code expressions and see if... Yes... to do... would need string or... data-type... vs. syntax and semantics. Syntax might be XML or... We can put that bit in...
Stan: I would second that proposal for now... re-interpreting the existing structure... for now... If have consumer who would...
Harold: Yes - that would be my take on it. The risk... re-factor the model... That is the risk. I think the CWE issue impacts...
Linda: When you re-factor... It sounds like:
- Adding URI
- Allowing multiple designations
- Add... to multiple designations
Harold: Yes - 5 proposals.
[shows on screen]
- Add URI
[shows on screen]
Harold: I start here and circle changes. Needs another go-around.
Harold: Second Issue. PIM vs PSM-Prefixed_name...
Harold: There are abstractions that help clarify the intent, but don't map... If I had namespace... name... then... Would have to... either both or one. This is a handy way to say that... whether... aAdds clarity to model...
Harold (cont'd): OK - terminology reference for URI. We answered question - is probably Yes. Whether this applies to code or string... So I think the answer is... need the ability...
Harold: Issue #3: Do we need a separate Terminology-Reference for URI? We said SNOMED CT without considering what we meant when we said it. Do people care... when I say... 0448... Do I care if I am looking at it in version 00013? The argument is usually that terminologies are will-behaved and has same meaning in 2010 as 2011... nuance of SNOMED... But... The one counter-argument is... in past... some terminologies are well-behaved...
Linda: We have a use-case in Singapore for defining use-case of version due to inconsistencies of version... In Singapore... But if not requirement of others...
Harold: Well - I could propose factoring that up and going back to original model since I don't expect... So I propose this terminology... reference back up into coded-text...
Linda: Yes - I would move anything up into coded-text...
Harold: [can't hear]
Linda: The rest of model using relationships... classes... designated... relationship to term-mapping... Need to get a consistent style.
Harold: OK - I can shift that. OK.
Harold: Issues #4 - the last one. Language, purpose, etc....
Harold: So - this could be diagnosis... a designation with a term-id... I said... That is what it would look like. Probably not have the... term-id... Here is the code... the URI... the designation... So here is the minimal example...
Harold: So all that needs to be... What I was trying to say... Instead of first class term... Would be handy... abbreviated from... To say language would be... Did not get that for...
Harold (cont'd): So - have a couple of... of guidance. Would like another go-around.. and could...
Stan: 6 points to capture in meeting minutes:
- We want to distinguish single codes from code-expression.
- Will wait until we have a use-case for code-expressions before we add them to the reference model
Harold: I thought I would show how it would fit... So not actually put it in.
Stan: OK. Not implement, but at least show a plan.
3) Add language to each designation (or term) in a Coded Text
4) Allow more than 1 terminology version
Harold: I am not sure we all agree with that.
Stan: That is why I am saying this...
Harold: One implication - original model always had... text. Current cardinality had 1...* which means...(?). If objection - we always want text...
Stan: I think true - but should be able to do by cardinality-constraint... Not want to say at this level...
5) We will use 'Text' for CWE and 'Coded Text' for CNE
Harold: And propose... where terminology... moves back to coded-text.
- Harold to propose revised Text and Coded Text design, based on today's discussions
Stan: Anything else? Thank you Harold.
Harold: I want to mention to those modeling... If adding a new attribute... "foo"...
[shows on screen]
Harold: If I do that there and save it, it will look like... But even though... called string, will create new type... So - need to go up and select "string", so is a... and not a new...
Linda: Important point and easy to forget when do quickly.
Six Points Stan Wished Captured in Meeting Minutes
- We want to distinguish single codes from code-expression
- Will wait until we have a use-case for code-expressions before we add them to the reference model
- Add language to each designation (or term) in a Coded Text
- Allow more than 1 terminology version (this refers to different versions of the same terminology)
- We will use 'Text' for CWE and 'Coded Text' for CNE
- Harold to propose revised Text and Coded Text design, based on today's discussions
Cluster Level Relationship Binding
Do we give the sameÂ binding to the cluster as for the focal element in the cluster?
Stan: So next item. The question about...
Agenda #6: Do we give the same relationship binding to the cluster as for the focal element in the cluster?
[Some problems showing slide]
Stan: So - next item: #6. I think you have a slide with a good example of that... Hematocrit or White blood count.
[Linda shows Mindmap on screen]
Linda: Observation item... Linked to observable entity...
Stan: Yes - if want to specialize model... Where we said hematocrit or WBC...
Linda: So here... specialized... model-level... Laboratory Text Observation
[Linda shows slide]
Linda: And similar with Hematocrit... meaning of... entry would refer to...
Stan: So Linda and I and Harold talked about this. At some level... not seem right, but not hurt... So explain. The one thing is a collection of things... and the other - structure with set of things... The real binding is... not have a semantic binding, but... The binding of it... observable code in SNOMED or LOINC... But serves a purpose to put at level of cluster and not hurt anything I am going to do. So I am OK with that. Discussion?
Linda: The purposes of [partition?] meaning on cluster.
Comment: To make sure model only used... decomposed in valid slots... So if observation, can only fill with observation... The other is searchable models. And other - the meaning is... qualified... Has more than text name... Has meaning and... So in terms of model meaning... lab-test... When substantiate... Need to refer to value of other fields to do that rather than other models.
Gerard: The way we think about patterns... for a process... order it or... Summarize it or... Always the same pattern... Changing one value in an element somewhere. The pattern is always the same... a process... A limited set of... variation...
Stan: So - you need to say more.
Gerard: The style of thinking about classes and nodes... element-style. You change that... specialize for... summarize... test?
Linda: We need to discuss that, but in terms of binding to clusters... Are you OK with using the bindings on observation clusters?
Gerard: Yes - but...
Linda: But you wouldn't specialize that?
Stan: I think... One type of modeling - you would make a derivative of... and hematocrit... The other style - if I make the hematocrit, I don't change the observation-item. Just says... this is not a hematocrit. Don't change node-name, only value of content.
Linda: Gerard - when you move from observation model to hematocrit-code and constrain... do you allow for extensions?
Linda: OK - new elements can be introduced, but...
Gerard: Yes - sometimes complex and need extensions.
Linda: We have had in CIMI where one... gets specialized to two. How handle that?
Gerard: [can't hear]
Stan: So - what is our style? Make specialization by change and hematocrit or by giving an observation to name and...?
Linda: Yes. My take on it - I see no problem with changing name when needed... into two. The... ADL contains the... in the base archetype. So when query over name, is connection between you and generic... includes all specialization in subsequent model. So... in matching mean... Though I can see advantage of keeping name consistent.
Stan: We will not resolve that today. By the time got to the same specificity, they would be isomorphic... Can change... My feeling is... might be a style issue.
Gerard: Yes - I do not mind... isomorphic. Can transform from one to the other.
Stan: Thanks for being flexible. We appreciate this.
Stan (cont'd): So back to the question. #6 Relationship-binding... Same relationship-binding at node as you do... And Linda told us why that has value.
Linda: Well - I did not...
Stan: Well - maybe I stated wrong...
Linda: Is whole binding.
[Linda fixes slide]
#6: Do we give the same binding to the cluster as for the focal element in the cluster? (effects the complete binding - including both the relationship and object bindings).
Plan for MTF Meetings in August
Linda: I'll be in Singapore for 3 weeks and the call would be at 4am, and I have a busy schedule. So next time I am back to normal would be Friday August 30th.
Gerard: Not next week - I have a meeting.
Harold: And I am out at... MedInfo.
Stan: Yes - me too. So I propose - next meeting...
Linda: Sorry - not till Sept 5th.
Stan: The 29th I am hosting a LOINC meeting.
Linda: Maybe you can let us know.
Stan: OK - next meeting on the 29th of August or 5th of September.
Gerard: I will be in France on the 5th.
Stan: Looks like in August a bunch of us will be gone.
Linda: Can be possible to continue over email.
Stan: Yes - and do further work on entries in entries and get that to a coherent presentation of issues. So work won't stop, but...
Stan (cont'd): OK - Thank you all. Good progress. I appreciate all your thoughts and contributions.