CIMI MTF Minutes 20130711
- 1 CIMI Modelling Taskforce - Meeting Minutes
- 1.1 Attending
- 1.2 Agenda
- 1.2.1 Detailed Meeting Minutes
- 1.2.2 Review of Arlington Meeting - Stan's list
- 1.2.3 Duration Discussion
- 1.2.4 Decision regarding DURATION class (as a child of QUANTITY):
- 1.2.5 URI's Inheriting from String Values
- 1.2.6 URI Added as Primitive Type
- 1.2.7 Decision regarding URI (as a child of STRING_VALUE):
- 1.2.8 Entries in Entries
- 1.2.9 Explicit Terminal Models vs. Different levels of Pre- and Post- in same Model
- 1.2.10 Choice of Interoperable model
- 1.2.11 [end-of-meeting]
CIMI Modelling Taskforce - Meeting Minutes
- Brief review of Arlington meeting
- Review list of work items - see issues list
- Continue discussion of model and terminology binding issues
- Reference model questions
- The DURATION data type has been made a subtype of QUANTITY
- URI inherits from STRING_VALUE
- The issue of entries containing other entries
- Do we make only fully explicit "terminal" models or do we permit terminal models that allow different levels of pre and post in the same model?
- 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?
- Reference model questions
Detailed Meeting Minutes
Review of Arlington Meeting - Stan's list
Stan: I sent out an agenda - had additions... Nice if Michael van der Zel could join but... Anyway... The review of Arlington meeting. Thanks again to Accenture for hosting in Arlington, and for all who participated. My review - List of items... The list is clean... Have lots of discussion on these... Continue growing list of things to talk about.
[Stan shows his list]
Stan: First 3 items are on today's agenda. 5th item - based on HL7 discussions around terminology binding and around FHIR... Do we need to distinguish static vs. dynamic binding, and do we need to make it a part of language? Exceptions and coded exceptions... I hope some will be decided quickly. Need... a default... Decide if done in models or... Objects and... Another - how represent "X" or "Y" binding... Clinical finding or Event or Observation. Thomas raised question of grouping and granularity...
Stan (cont'd): #12 - Agree to organizational paradigm (SNOMED...). #13 - Review the style of units of measure... #14 - Do we need to distinguish binding to a single concept vs...? #15 - Create a formal proposal... I have not tried to prioritize this. Some - want to decide quickly and some... approved CIMI model. Probably need to prioritize. That is my list. Other? Maybe around terminology binding and modeling style...
Gerard: I like to talk about style... I am happy with the list.
Stan: OK - Back to today's agenda. New Reference Model questions. Thomas had a chance to look at changes... whether we made the right changes... Thomas - what was duration intended to do as used in openEHR?
Thomas: In openEHR, a bunch of types... Used to call customary types... typically non-metric units. Pounds, stones... So, that is what... we use iso-8601 - a literal string representation... a layer dealing with time... So date, time, date-time... The duration type: weeks of pregnancy or weeks having this headache, or how old is son. Could express as quantities - a number of seconds, minutes... Could not be a month... is not a proper unit. But in iso, could have (?months and weeks?)... But could have 3 months... 5 days... can't do that with quantity. But someone might say - user-interface... and come out with quantity... But probably not get the same quantity if had months and weeks and days... Now, there is a (?) quantity... convert into... But with inheritance as is, I don't think will work as people think. The compiler... probably won't make it easy... the way it is constrained...
Stan: So, given this discussion, it overlaps our... unit of measure... So - you said... months not allowed. But where used, people are not trying to convert from months to seconds... Can't properly, unless said "28-day month" or "30-day month"... But I don't see problem with quantitatively using... In our system, we convert to smallest unit... So, months, weeks, days - into days. So - if people want to have weeks and months on entry screen - OK.
Linda: We also discussed this in the Netherlands MTF meeting. If wanted year, month, days, could separate into elements. Also - iso text string as part of...
Thomas: So that is 2 types of... to cope with years, months, days...
Stan: To me, not make it harder... just converts...
Thomas: Months and days aren't...
Stan: But no one converts months to days clinically.
Thomas: What if 1 month, 5 days?
Stan: Well - capture that in string.
Thomas: So 2 representations of same thing -string and quantity?
Gerard: When I think of time - 2 different things. Absolute - covered by ISO-standard. Relative - covered by iso-standard. And Duration is in the second class of things... Unit... but also like cycle... 1 cycle... Up front - to define unit... is difficult. Need to be flexible. Perhaps text is best to use when don't know what units should be.
Stan: I missed what you said.
Gerard: Duration can be time... months, years... Can be cycles... for the moment, use text.
Thomas: ISO-601 - date-time. Cycle of things - the way we modeled was by... the iso-... I think my usual push-back is don't try to have a model do two things. I think trying to make it do normal weeks and months as well as... in health, probably makes it complicated. Start making it look like (?)GTS(?)... which is based on iso...
Stan: I have poor technical connection... Don't know how to fix... Repeat?
Thomas: I agree with Gerard - instance - want to express 3 cycles - menstrual cycles or days. I don't think there is a model for that in duration... Days, weeks, months... Make it do too many things - a problem.
Stan: Where to go from here? What we have in Reference Model - your argument Thomas is - it is harder to ... in model if went back to... I am happy about how it is now...
Thomas: There are various things we wish we had done differently, but I don't think that is one of them. That we had Duration.quantity. I need to check how functionality reacts to it.
Stan: Thoughts? My bias is to leave as we have it now. If we get into using it and find it hard to implement, then we can change. My experience is opposite to yours. We use Duration... and never had problems with it. Maybe this means we can use both ways and it is fine.
Stan: I wanted to make sure Duration was not used for "What happened in my childhood" or ... Other thoughts before URI's?
Decision regarding DURATION class (as a child of QUANTITY):
We will keep the DURATION class as is, for further testing.
URI's Inheriting from String Values
Stan: OK. Thomas - can you explain the problem you have with URI's inheriting from String values?
Thomas: I think if had... I think... URI - one of values... like saying any... seems odd. Certainly if URI... to URI. But if put text type, we would not expect URI to turn up there.
Harold: Do you have the UML for that handy?
[UML Diagram on screen]
Linda: Looking at models for different members and I forget what it was... but some members doing as URI and some as text... and we wanted to say... had to be string-based.
Thomas:... I think very unusual...
Linda: So text... and URI just adds formatting constraint.
Stan: For this - data-type vs. constraints? Coded-exceptions... So for Duration discussion... could have said this is a physical quantity... We were saying the... unique identity and... URI. So I expect URI...
Thomas: Why not just be a data-value?
Stan: Not understand.
Linda: Why the URI not go directly to data-value?
Stan: I don't know.
Thomas: The fact that is... string... does not have to be... Not inheritance... just logical... Most things are strings. But is not what they are semantically... And if you put back on data-value, you can get rid of string value.
Linda: Put value into text...
Thomas: Yes... collapse...
Stan: Yes - good point.
Harold: It is correct... inherit from... Other possibility is Primitive type... but data-value. We declared as primitive types.
Thomas: Was operation on URI.
Harold: Probably is... if type as data value then have to do... value field...
Thomas: Just a normal field.
URI Added as Primitive Type
Harold: But... type called string. What do we gain from complex type of string-value? I would like to at least entertain that URI is a Primitive-type. Unless is a URI as understood by web community.
Stan: So... I am not understanding. What would you propose?
Harold: I would propose we add URI as 7th CIMI Primitive-type and be done with it.
Linda: To be a data-type of an element must be a specialization of a data-value, so would need...
Harold: So would have to create a URI value node...
Linda: Yes - Need to create a URI-value class(?).
Thomas: Yes - right. I would suggest... Harold is probably right that Primitive URI could be used anywhere...
Stan: So if we send... if wanted to use... attribute of class... could use these?
Thomas: Yes, such as... URI-type... URI...
Harold: Yes - terminology-type to be... So, Linda, you are saying we need both cases(?) - something derived from data-type, so can use... URL-proper... and then data-type. If put into string-type, are we going to reference as name-value?
Harold: If I have string-value used in archetype... In order to use a string in an argument we need to use a data-type?
Thomas: Value of element-type.
Linda: Data goes into element-value... If create as URI then... But not into patient records unless value of data-type.
Harold: So... reference patient.name.value, not just patient.name to get...
Harold: So I see why URI is there. If patient to... data-value, still need attributes... Looks like string-value... But if 2 steps - created a... and then URI-value with value-type URI, then have advantage of using... primitive-type.
Stan: Isn't that what you drew, Linda? Couldn't we have... string-value?
Harold: Pretend that is you...
[Harold or Stan]: Not now - need string-value. Put under text and do away with it?
Harold: But then don't have...
Harold: So - when else was text... data value used?
Stan: I don't think anywhere.
Harold: If wanted a string to use, then needed a type... data-value. Are there string-values elsewhere in model? Although, those are italics - right?
Harold: OK - not using directly, so is abstract.
Linda: Yes - yellow is abstract. Blue is concrete.
Linda: So - ignoring string-value type that we will get rid of - is this what we are proposing?
Stan: Yes - Thomas?
Linda: So need to rename.
Harold: How urgent is this set of changes if we have a DSTU? Need soon? Or incorporate?
Stan: So - what is our process? Tell me what the right thing to do is? Leave the one we have as DSTU and people can use, or...
Thomas: I would ask if anyone has built archetypes based on... I would stick to incorporating this when all ready and change to 1.1.1 (?).
Harold: Yes - should not have significant ramifications...
Linda: The only CIMI... where...
Harold: Would want to...string value to...
Stan: So - aren't any real CIMI models yet. Tool - makers - Patrick... or Dave. Are we going to break anything, Dave?
[no response from Dave]
Patrick: Not going to break anything with me, so OK.
Stan: So let's assume will not break anything and go ahead and make version. Let's hold off and see if additional changes... At least that part... would make a new version with that change... Anything else with that?
Decision regarding URI (as a child of STRING_VALUE):
We will remove STRING_VALUE, add 'URI' as a primitive type, add 'URI_VALUE' as a child of DATA_VALUE (with new attribute "value: URI"), and add the attribute "value: String" into the TEXT class (i.e. moved from STRING_VALUE.value).
Entries in Entries
Stan: Next - question of entries in entries. So - as you know from visit here [at IMH], we create a model for hematocrit, for hemoglobin, for diastolic blood pressure, and we build up... from those types. And that is distinct from an order... dose and... Typically call them panels or batteries which you are making a collection for convenience or some physiological... So we make hemoglobin... With blood pressure we would have diastolic and systolic and make blood pressure panel and put into lots of things like pre-natal exam and cardio exam. So that is my use-case.
Stan (cont'd): The way entries are made up, it seems I need to decide if... But I might not understand. But that is my Use-case. Other use-cases? Linda?
Linda: Yes. This applies for any compound observation. I know Gerard commented on this... systolic blood pressure and diastolic blood pressure are observations in their own right, but make up a panel...
Gerard: Clinical statement must be atomic. I am against entries in entries. How compound is compound? The way I solve - one entry is one clinical statement. Collection of result of process... observation... result... Never do systolic and diastolic at same time. Think about executing protocols where store... one perceived thing is one entry.
Linda: So you have been modeling systolic as one entry and diastolic as one... Previously I thought you...?
Gerard: Since... it is difficult. You cannot observe two things at same time.
Stan: If someone else asks for... I agree with you in terms of - we use screen definition to say what we will collect in data entry screen. On the other hand, there are collections that are orderable... When someone orders, we would allow someone to order blood pressure every 4 hours, and we would know they would get systolic and diastolic every 4 hours. We think we need a collection for interoperability. You order a procedure - you define as whatever you want. You put in some sort of knowledge representation.
Gerard: You could use archetypes, but if order a procedure, you get... back. So archetypes stay simple... And I don't have to break...
Stan: So if I make all as an entry, Hematocrit, Hemoglobin, Blood Pressure, Heart Rate as entry, and I put onto data entry screen... I was thinking of... is a way of grouping... Logic... because have shared attributes - who did it... where... So if I made each in entry and not onto screen, then each would be entry and I would have to copy into each - the same person and... I would have to put...
Gerard: Each entry is capable of full... This is the way I define it.
Stan: Thomas - consistent with openEHR - how is it done?
Thomas: I think separating systolic and diastolic is too... Can't be simultaneous, but... I don't think writing down separate times for each... If doing BP and Apgar and... The main thing - I think Stan's question needs to be addressed. 13606 - if have serum sodium or HDL or systolic pressure - I would map into element archetype... and then create an entry... or... panel... and use a slot to say which things go into these. How could create a slot... we do with lipids... total LDL, HDL... Triglycerides... all would be optional. Could be one... could be full panel... Would require... archetype... and would get the flexibility of the panel.
Stan: Yes - Makes sense. Linda?
Linda: Other Use-cases of systolic and diastolic separately, I have seen in Singapore. Average systolic over... and average diastolic...
Thomas: That is why we have event-type.
Linda: Yes - But you put a whole time series into...
Thomas: It's amazing to have...event... We use interval event. The math(?) function gets used a lot. I guess you replicate...
Linda: Probably is when derived functions over time intervals...
Thomas: Then trying to get too much from Reference model... Body temperature from last hour... from last twenty-four hours...
Linda: Hard to predict before time what derived functions are going to be needed.
Thomas: Is that not a query question?
Linda: Yes - that is why I would want atomic and leave time series.
Thomas: ...time series. There are instruments that generate a sample like a width and a delta or max or min.
Stan: We think of max and min - becomes its own data element. Separating models from... Would create a new data element called "max-temp-during-8-hour-shift" and would calculate the mean and store as new element. Interesting question... It is natural in Object-oriented programming to define functions on models.
Thomas: The field is called that function... but is only a term that says the meaning... Not actually a coding function.
Stan: So is an iso-semantic question. In ours... follows LOINC codes. Says min and max... The min and max are always pre-coordinated.
Gerard: There are examples of derived... where you do calculations.
Thomas: You have an instrument that is generating...
Stan: Yes - inside the black box - you get it... So, Gerard - you printed out, there is nothing simultaneous, but... numbers come out of box at same time. I have gas analyzer and... comes out... So multi-channel analyzer - you get time difference of systolic and diastolic... Have not seen them. The... out of the same instrument. I would need to make correlations... if systolic and diastolic together... If specifying systolic that corresponded to that time spent and diastolic... Because a lot of times you want to know if white count - done with differential... The difficulty has to do with... have to do the correlation. Sodium done exactly at same time as potassium... have to correlate - not as part of same thing, but...
Gerard: [can't hear]
Stan: But how do you tell it - this is one batch of things?
Gerard: You know when batch was ordered. When I think about archetypes I don't think about implementation.
Stan: I am not thinking about implementation. I am thinking about query. Are you storing "This is a batch-identifier, and here are things stored in batch"?
Gerard: So... knows...
Thomas: IF GP order...
Gerard: I agree, Stan - difficulty defining... when you want to process, all the time stamps are creating a problem. But it is context, must be able to... Not all the same. The only way to deal with... batches is... and execution of order in on a batch. But I want to have a simple pattern everywhere and statement and... creates problem.
Linda: Can record individual atomic... and knowing... but each... be derivable from grouping as recorded? Grouping... Can derive context from... not necessarily, but is done for query.
Thomas: I can... done naturally.
Linda: Depends on whether LDL or hematocrit is...
Thomas: Entry has only one... conceptually a panel in Stan's - that only has one. The thing of saying is an entry or panel... just because one... couldn't have passed with only one. These things are a specific kind of entry... a panel... can have one or more. Make sense?
Gerard: Medical implications at each level. We did not allow an entry in an entry because was not an atomic clinical statement. We did... have a cluster... diastolic result. But then you find the meaning of things... entry level... cluster level...makes things complex.
Thomas: I can dig things out of clinical element... and show how make an entry.
Stan: Yes - I think logically you want full context of object available to query. What I am worried about... Blood pressure is funny - not many things like BP. Maybe BP in the only instance...
[lost Stan's connection for a while]
Stan: The thing that I worry about - something as simple as systolic and diastolic... comparing time stamps.
Thomas: Basic question - whether we have to do something with Reference Model. I think the BP model... Better to keep until debate in...
Stan: I think it would be helpful to do what you said.
Thomas: The current generator... Modifications to put into there... Maybe take off-line and give it a go.
Stan: I think we have explored...
Linda: Like to consider making the entry a single... entry - the LDL, Hematocrit, Hemoglobin... But perhaps the Reference model is missing a class that has a logical...
Thomas: I don't think we have to do... We can get from collecting elements... and end up...
Linda: The "context conduction" and knowing when it is... down... and... I think you are missing when...
Thomas: I think "context conduction" is a failure of model...
Stan: I think it would be fun to go there when we are face-to-face and having a drink. But hematocrit... at normal ranges... So I use the cluster... a cluster in clusters.
Thomas: [Can't hear]
Linda: Not in CIMI model. The clinical information is away from data types.
Stan: Best to do some examples. Want us to understand the implications of style. What we wanted... examples against reference model... reason to change.
Explicit Terminal Models vs. Different levels of Pre- and Post- in same Model
Stan: Terminal models and not terminal models.
Gerard: What is it?
Stan: A leaf node model is better. A type that is used for interoperability... A model of instance data...
Gerard: A model of instance data?
Stan: Linda - slide?
slide-1(on page 2) IsoSemantic Models - Example of Problem
Linda: The term... makes it sound like no more changes can be made.
Stan: Not what I intended.
slide-2(on page 3) IsoSemantic Models - Example Instances
Stan: Different iso-semantic - great diagram - from Linda.
- Suspected Lung Cancer - Hospital
- Suspected Cancer and Lung - Polyclinic
- Cancer, Lung, Suspected - General Practice
Stan: So if look at model on left-hand-side - problem diagnosis, problem diagnosis name, details, body site...
Stan (cont'd): The thing under General Practice is most post-coordinated. And there have (?)partially pre-coordinated and... The thing I thought - 3 models. And in General Practitioner model... In General Practice - would be illegal to have... because is post-coordinated. And in polyclinic - suspected cancer... And... 3 distinct models.
Stan (cont'd): Actually 4 distinct models. Models on LHS and General Practice, Polyclinic and hospital - different degree of pre and post-coordination. The other way to think - not really 3 models. I have problem diagnosis and I can constrain to what I want. But for interoperability, I could constrain to what... All 3 are OK. But for interoperability - I don't want general model, I want sender to say if sending from General Practice model or Polyclinic model or Hospital model. Rather than look inside model to know...
Gerard: Situation with possibility of pre-coordinated cancer... or lung.
Stan: Yes - not meant to be comprehensive, but you are right, and if temporal context, then would have 12 models.
Gerard: I make distinction between quantitative and semi-quantitative. Suspected Cancer and Suspected Lung Cancer are semi-quantitative. The way I produce archetypes, I refuse to use pre-coordinated qualifier like suspected... Lung Cancer OK. Because Lung Cancer is a (?) thing. A way of expressing clinical statements...
Stan: One of the things we said in Arlington - consensus that our style would be the most post-coordinated model. So General Practice model would be the model we would use for interoperability. These other are useful for data entry - probably would use one of these others. But the consensus in Arlington... the General Practice model would be the most preferred.
Gerard: I agree. And the others... ad-hoc presentation... how want to present. But how to specify - the Left [General Practice] is the most flexible, and I could add a fourth. Seems clinicians - was to add (?), but also "it is not applicable". Fine with me...
Linda: I'd like to think about what to do with original - that clinician says... for medical safety. Second panels like CBC - means break up to... Is this natural or desirable? Third - Post-coordinated... Data structure has to be more complex to support.
Tom: If you were to throw this to Ian or (?), we would build an archetype/structure on Left, and probably would template it 3 times. First thing templating does - gives a different id... Define in each of those templates... Ref set... cancer... on right side more user... So, practically-speaking, if did it that way, come out in the wash... diagnosis... capture... not same as diagnosis... That would be my gut feeling...
Linda: A few things to template into structure... into value sets. But if you can't enumerate all values... body site... SNOMED not allow you to pre-define...
Thomas: Doesn't the current... Ref Set... Isn't there a...?
Linda: With... - you should be able to do that... to say...
Harold: Could say - All clinical findings - clinical findings that have value site.
Stan: ...in Ref Set... sometimes intentionally defined Ref Set... So - I think we went over the statement that we would do this more post-coordinated model is probably over-kill. Have to temper that. In LOINC - have like specimen-type, aren't incorporated. And would not want to say. There are things that people always pre-coordinate, including specimen or not... Would hurt ourselves when whole world does it. And Thomas - OK with me - archetype or template on archetype, as long as they... Not change fundamentally the question. I am asking - would we choose one of those template models as the model of interoperability, or would we choose left-handed side? If choose left-handed... receiver could get back in any of these forms and would have to change into other form. And we said before... people would get their model to preferred model... always predictable... Not have to parse.
Gerard: On left-hand-side, observed in complete context. The pattern we have to choose. Also... template... receive or send data to string... And store or define things in interoperable way. Also helps me in choice - I consider SNOMED a dictionary. Will I ever find an entry there that is suspected Lung Cancer? No - I will only find entry for Lung and Cancer...
Linda: There is... in SNOMED that has pre-coordinated forms.
Gerard: Are there but should not be there.
Choice of Interoperable model
Stan: We are running out of time. Can we agree that we would like to have one of the fully specified... We would always choose one of the right-hand models as basis for interoperability rather than the left-hand side? We can continue discussing which (on RHS), but not have various degrees of pre and post-coordination.
Thomas: My... and then transformation... Becomes a 1-to-1... Is unpredictable... At least can say we have a predictable... into target.
Stan: I agree. Linda?
Linda: I agree with Tom about... into preferred model. And... parts into... I still think we need to discuss how we handle lab tests. ...diff CBC - always would pre-coordinate.
Stan: I think we agree on principles. Capture in minutes.
Gerard: Left-hand-side - preferred or not - Canonical or not?
Stan: For our purposes - we would choose one of 3 models on right-hand-side as preferred CIMI. In this example, would choose General Practice. But with lab data, as Linda stated, have to discuss. But would not choose on left-hand-side - blue. Different pre and post-coordinated.