CIMI MTF Minutes 20130718

Jump to: navigation, search

CIMI Modeling Taskforce - Meeting Minutes

Thursday 18th July 2013 @ 20:00-22:00 UTC


Linda Bird

Stan Huff

Thomas Beale

Gerard Freriks

Joey Coyle

Patrick Langford

Mark Shafarman

Eithne Keelaghan

Agenda & Brief Notes (italicized)

  • Reference model: Any final questions on DURATION or URI?
  • Entries in entries (continued from last week)
  • 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?  For example, do we have a single consistent style of including the specimen as a pre coordinated part of the observable name, or do we vary the style based on common practice in the laboratory?
    • Discussion: Post-coordinate to the smallest level that is clinically recognisable.
  • Do we need to represent static versus dynamic binding?
    • Dynamic binding: Allow any values that exist in the ref set at the current point in time. Allow values to be added to the reference set, and these become available to the binding - e.g. drug codes
    • Static binding: Only allow values that existed in the ref set at a given point in time. If new codes are required, then a new version of the ref set and binding are required - e.g. order status. Where it is required to synchronise software versions with known content that determines behaviour.
  • Meeting schedule:
    • Stan will miss the meeting on July 25 because of the HL7 Board Retreat.  Shall we cancel?
    • With holiday/vacation time upon us, will we have quorum for meetings in August?


Detailed Meeting Minutes

[I missed a few minutes due to technical problems]

Entries in Entries (continued from last week)

Stan: What I understood... The way to model these things is... In our... model hematocrit as a cluster and then make bigger cluster into... So Thomas's example: Make cluster for sodium, potassium, chloride, glucose. They have the value, reference range, and other things. Then make a bigger cluster that included these - example: a Chem-7 with sodium, potassium, chloride, glucose... And then make a bigger... that included a Chem-7. The only downside I see to that is the implication is... if store only hematocrit, I will make entry level that is hematocrit and cluster is a hematocrit... So saying a hematocrit is a cluster of one thing. I think that is the implication if we want to include hematocrit and all those things in one cluster. Proposed as the standard... openEHR style... SIAMS... 13606. I'll stop there.

Linda: I think that is a good summary.

Thomas: I made those analytes clusters... Had to have 2 elements in them... Reference range... We would not do this in openEHR because have to.. 2 data points. Any logical analyte is really 2... Logically you could have a single hematocrit... going to be a cluster... Its value and its Reference Range.

Stan: Did I describe right? Hemoglobin or Hematocrit to... or Chem-7. Put into a bigger entry?

Thomas: Doing it by template-ing. Look at all the CEN's... They are a kind of composed - compression of... and a concept of an Entry. So in IMH environment, not a black and white thing. Analytes separated from a thing... But CIMI models - definitions - and plug in... Your explanation is right.

Linda: Good summary, Stan. Because one issue I faced - had to separate individual test results into clusters so could be reusable so could use single hematocrit... Levels of nesting... Some have questioned why we did this. Other thing to consider... because using observation pattern... which is to be used if heart rate and also lab panel - want to be simple when look at heart rate, but also have to represent everything for more complex cases. So - I put together.

Option 1

Linda: Hematocrit result as Entry... Elements - Information Subject, Date, Test Name, Result Value, Interpretation...

Linda (cont'd): Define hematocrit in CBC - needs to be done in cluster because need other tests as well. On Left-side, ideally simplifying if only hematocrit result. But need hematocrit result as entry and as cluster.

Thomas: What is the problem we are trying to solve?

Stan: Single definition of hematocrit which allows it to be in different constructs.

Thomas: But what would be the problem?

Stan: One level of containment - not adding value except... If we made it a cluster, still need an entry. On right-hand-side, would have hematocrit... and have one level of containment without much value. It works... Consequences to allowing entries in entries?

Thomas: If talking about flattening, but serious consequences if... Software - harder to write. Querying - difficult.

Linda: Yes - that way... If hematocrit result as entry, temptation is to do it as flat, single entry. Path to get it... Results of Hematocrit - have to query differently on left and right.

Thomas: ? [can't hear]

Linda: Makes sense if multiple, but if only 1... Heart rate... or... forced to introduce extra cluster level of nesting.

Thomas: [can't hear]

Stan: Not so much path to hematocrit, but data on left-hand-side is inside result, whereas on right-hand-side - is in entry. So path of qualifying data changes depending on if standalone or...

Thomas: But... [can't hear]

Linda: Information subject is at top level and inherited down.

Stan: Let's let Linda finish explanation, and then discuss.

Linda: OK. Use consistent observation standard. So heart rate - have heart rate entry and the cluster. People had been questioning our use of cluster. The following... in reference to what Gerard said, but apologize if not...

Gerard: ...?

Option 2

Linda: CBC... Compound entry points to atomic entries it contains inside...

Gerard: This is correct.

Linda: OK... So hematocrit result Link has hematocrit result...

Gerard: At entry level, I have something called CBC. Abstract name - I forget. A perceived thing, and then an element that tells me it is a CBC.

Linda: OK - have to add.

[Linda makes changes to slide]

Gerard: Having these references is one way to do this. Another - compound thing outside of record.

Stan: Is what on screen accurate as to how you think about it, Gerard?

Gerard: Yes - sort of. And... That's OK.

[Linda changes slide: Link changed to "Result", and Entry changed to "Lab Test"]

Gerard: When we think about semantic interoperability, we can't ignore philosophical... Also, 13606 - clinical statement - allows you to create... So style that openEHR is using is according to openEHR and 13606. But the credit is... no semantic aspects... the archetype... Reference model allows exchange between EHR systems... But when think of semantic interoperability... Think of limited amount of... and the entry is only one clinical statement. Clinical statements are ad-hoc statements from people. Can be different in 5 years. So we made statement, that is one simple clinical statement... The Body Mass Index [BMI] is one statement because can be stored... Entry by hand... BMI is complex statement... point to... Famous example is ECG - order one thing, but many things come back. Order... and get many things back. That is why these types of complex results are modeled in one cluster. Why? Because is one sample and end up in... and one sample... one test... we model in many clusters... one test. It is compound.

Stan: OK - A little bit of response, but then Linda. I did not say that the conceptual does not matter. But need to make decisions about structure. Do we need to change the Reference Model? We can agree on structure... and I would want to move forward without agreement on philosophical. Second - CIMI never said models are only if... They are the basis for interoperability. Really trying to enable a standard archetype query language to allow... what they want from a Database... To say what is to be retrieved and what form it comes back as. I can imagine - like here - but the logical... be posed as what we had first. So let Linda continue.

Linda: One advantage of this approach - shows piece of information indivisible... and test results are the same if individual or part of a panel. Same... hematocrit results... Not depend on how organized - flat or nested. This is the approach we talked about previously. Talked about time series - where the dates or time, or BMI... different people or dates, and if different context, use link to point to them... point to entries.

Option 3

Linda: The third option uses this approach - atomic entry recorded in nested structure it was recorded at the time... If entries have same... Not repeat date-time on each observation if were the same. But if query - want a consistent path no matter what... So - if hematocrit is atomic entry with its own... you can have an assumed value of parent's information subject... But when get to query - can be filled. So with... hematocrit results... an atomic entry with its own context that can be derived.

Stan: So in current Ref model, you have... sections... If we change the name of that... how would be compound entry?

Linda: Section cannot have their own elements - would need to have entry.

Stan: So - this is essentially what we do in CEM [Clinical Element Model]. We... qualifiers... and we assume in storage - at panel level... If given anything at panel level, would show up with child. This is what we do now with CEM.

Gerard: If functional... but it violates 13606 as it is today.

Linda: I don't think we should be limited by that.

Gerard: Can't have an entry in an entry in 13606.

Stan: We would need to have a good reason for this, but never said could not.

Gerard: Have a specific function... Why things are the way they are. I could not find a good reason to not allow Entry in Entry...

Stan: What is your preference?

Linda: Option 3 is my preference even though it changes existing practice because it allows you to nest inside... Provides a consistent path to information you want to query... Individual units of information are more standalone. In option 1 - don't know if Hematocrit results are 1 or 5 levels of nesting. Depends on panel... To do consistent queries - advantage of Option 3.

Gerard: Option 2 & 3 look alike. Element contains another element.

Linda: Yes - I think could use Option 2 in certain situations - different observer or... situations when need to link between... Option 2 required in those cases.

Gerard: I am against Option 1. Could live with Option 2 & 3.

Stan: Do you have another option, Gerard?

Gerard: No.

Stan: We covered all your options?

Gerard: The other option... You never query for a CBC. You query for the topics in a Blood Count?

Stan: No - not our experience.

Gerard: When I order CBC, these... will be... That is what you want to store. But you refer to catalogue (?). Another - Have these compound statements... My CBC is not necessarily the same as other.

Stan: But by our... would be a different model. The most common, retrievable... when we want to retrieve the whole panel. We retrieve at CBC level more than hematocrit level. If we want to graph hematocrit or use in decision... But most common is to retrieve CBC and display multiple on screen... You want to be efficient. I want it to be easy to say logically "retrieve last 3 CBC's". Also, say "last 3 Hematocrits"... however gotten. Those are our requirements.

Gerard: When it comes to CBC - in catalogue, I can query the last 3 protocols of the name Blood Count, and I can look for results.

Stan: Yes - I am with you. Option 2 & 3... Option 2 is different - whether retrieve as... and then traverse each Link. In one case, retrieve one and the retrieve those that are linked to it. In other case - retrieve whole thing.

Gerard: Want to discuss with Dipak and also some in 13606. I am not against option 3 at all. Perhaps ask to change the Ref Model.

Stan: Thomas - A better option? Or reason one of these is bad or...?

Thomas: Way off my roadmap. CIMI doesn't have definitive attributes. The whole thing should be called something else.

Linda: What do you mean?

Thomas: When you create Ref Models, the point is not to get rid of domain semantics. The point about a good Ref Model is a lot of design and feedback... Some of those attributes in Entry class 13606 model... So, I say this is a different kind of approach in my point of view.

Stan: We want to do what you want to do. So - create a pattern on entry... always have a date and time... It is that consistency...

Thomas: That complexifies things...

Stan: No - as easy to reuse a pattern as it is to reuse an entry because... So when get into National Language processing... Clinical trials... There is a clinical trial data and time... The hematocrits are all the same but...

Thomas: One of the things... different kind of entry. Still surprised to see the EMR or EHR entry not contain its original semantics. Forces things to be redone.

Stan: You restated it. We are adding new classes of things to account for clinical trials... You have chosen not to made new entries, but make new class...

Thomas: A lot of value lost from things that are invariant...

Stan: No - not lost - just put into the pattern.

Thomas: From point of view of coding...

Stan: I would continue to make my software correspond to the pattern level and not the entry level.

Thomas: The point?

Linda: Some people might want to base their software on... or on observation patterns or...

Thomas: In that case, not talking about... I would throw the Ref Model out. We are saying... This is a different way of doing...

Linda: No - Ref Model still provides lowest level of consistency.

Thomas: [can't hear]

Stan: On less... not more.

Thomas: But still... No real meaning to...

Stan: It is arguable. I admit that. If we assume all implemented in XML or Java... if assume one implementation... You are sharing software components at a different level.

Thomas: But you want to share the data... If someone gives you a copy of reference model, then... But not hold anymore.

Stan: Have a Ref Model so can make information convertible. So what we are doing with AML... AOM... I don't think you can do if not agree with Ref Model.

Thomas: My point. I look at... ecore and... No longer can make basic assumptions of what the model means.

Mark: If you assume Ref Model always has to be 1-to-1 with implementation...

Thomas: [can't hear]

Mark: Different systems will have to use this information in different ways. The (?) of going from (?) to a... If we say the model we use has to support a particular type of implementation, then we have to resolve philosophical...

Gerard: 13606... Over the years I concluded... We have to change. So - a specification of an interface. We define the interface. Can generate screen, query, store, data abstract...

Thomas: Not true. Interface - have functions... There is a level of implementation model that is unavoidable. So, if have get-entry... going to get back... We can't run away from a logical (?) of information model.

Linda: Can we come back to options?

Gerard: I will email people and I will let you know. Open to Option 2 & 3.

Linda: Tom?

Thomas: The word entry - not mean...

Stan: I think may not... open... If store collection of things with shared context... An entry is a cluster... outside other cluster... The things that are stated outside are still context... You are thinking the things are fixed. We are saying those things are different if doing clinical trial or...

Thomas: The only thing in Entry that is different from anything else is...

Stan: Well - we may need to correct the way that we have done... My understanding of core entry...

Linda: Still - entry... The words were "observation" or "observation set"... We are distinguishing between observation and observation-set.

Thomas: The... [can't hear]

Stan: Assume we can fix that... is important. The semantics of entry... context... is an important construct we are trying to preserve. Looser than openEHR where you have fixed... Important to preserve entry as... shared context.

Thomas: You are saying Entries should contain Entries... Different...

Stan: No - just says can recursively contain... So BP - systolic and diastolic - then into vital signs - at next level I want to share who user was and...

Thomas: But you said shared context, and in Option 3... at lower levels... or just duplicating all over the place.

Stan: No - the way we got to structure. Some things usually shared and some... context-specific to measurement or to whole...

Thomas: Definition of entry... You are sharing something in Entry could have different... I understand IMH... what is going on here...

Stan: I think it is consistent. Why not?

Thomas: You want to keep... model entry as class... standard data items inside. You are saying - these could override.

Stan: I don't think it invalidates it. There is computing complexity... In example, Linda copied data down... Instance data at platform level. Info - it is not that it is not shared, but is shared at (?) level, If child - different... then... I don't think in conflict.

Thomas: I suggest... the main entry is misleading... Might think openEHR or 13606, but is only a container.

Linda: But is different from... Might have a cluster, but...

Thomas: Entry only has language that... [can't hear]

Linda: A cluster inside here would still have... Could not... and query over like it was data. They might be clusters inside, but only have meaning in hemoglobin results. I used to have idea that openEHR was the smallest... you can make, and you can query over, but that was wrong since can have time series and observation sets. And I know people argue about... but entry here is different from...

Gerard: Option 3 is style of modeling that I don't entertain, but I understand. It is not my preferred style... is Option 2.

Stan: Mark?

Mark: Two ways of thinking of problem. In v3 - independent(?) or standalone. Hematocrit can standalone or be part of CBC. You want to be able to say - is start(?)... So, urinalysis with color. Color not mean anything unless part of battery. Independent ... result is the smallest thing you want to point to that has meaning in itself. And want to group. And have context. Ways to override the context? As long as can get context of tree as whole and override - will support this... Whether go with Option 2 or 3. Not critically important - as long as can go from 1 to another. I prefer Option 3. The information in Option 3 can be ... with the common context at the top level. I can do a query and get all hematocrits of this patient in this time interval. I need CBC, but also need all of independent things that could be grouped for other... If wanted to have more... The v3 context for mood gives you context. You could have the time further defined... e.g. time specimen taken, not time found... microbiology - want specimen time and time of analysis and antibacterial and... As long as can say... That is the basic minimum set of requirements and Option 2 or 3 will support.

Stan: Thanks. Joey, Patrick - have you been online? Any additional thoughts? Also - want to give all a chance to go back and think about any implications. And go back and discuss and we can discuss next week.

Joey: Nothing to add.

Patrick: I agree - well covered. Discussion has been really good.

Stan: Let's leave it there for now. Anything else from anyone?

[no response]

Pre and Post-Coordination

Stan: Agenda - #3. Do we model common things as...?

[#3 from Agenda above]

  • 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?  For example, do we have a single consistent style of including the specimen as a pre coordinated part of the observable name, or do we vary the style based on common practice in the laboratory?

Mark: I have to go. I'll join next week.

Stan: Lots of examples of this pre and post-coordination. Examples came up in LOINC.

[slide] - Stan shows LOINC code example: Option 1 -pre-coordinated and Option 2 - post-coordinated

Stan: I can represent as Cadmium ... or ... If look at LOINC codes - the ones in yellow are interesting....

Stan (cont'd): If you look at different systems - some use highly post-coordinated... Use top code and post-coordinate... Others pre-coordinate and would have a ... set where specify name. And some... are a mix. Pre-coordinate things that are common. But post-coordinate some... Don't want Cadmium-Liver and Cadmium-heart... So they pre-coordinate and post-coordinate.

Stan (cont'd): So we... had to be consistent. And I am talking about preferred model for interchange. We could say... or we could say... going to pre-coordinate everyone... and say muscle tissue and brain tissue and... Or middle ground... So with Cadmium, when done all the time... we will... So erythrocytes concentration - erythrocytes per volume of some fluid... pericardial fluid, peritoneal fluid... But don't see wound drainage. That is the general question and I'll stop here.

Gerard: I feel safest when I it control myself... CSF and tissue sample - is my preferred. Because the... whether brain tissue or... is same procedure. Just the substrate is different. The measurement elsewhere... context - where derived from... BP from left or right arm... I don't want Left-arm-BP or Right-arm-BP.

Stan: That is consistent with what we said - that we prefer the most post-coordinated approach. But as Linda said - may not want to go as far as that implies. Could go too far - Cadmium... whether a patient...

Linda: Also other - CBC - not want to break down to complete count. Maybe break down to smallest unit that makes sense clinically.

Gerard: ...what makes sense - that decides what level you go. Have to still decide.

Stan: I think I agree with you, Gerard. I tend towards post. In our own systems, we will use pre-coordinated since pre-coordinated are how people think, so I will use internally and for data entry. But I agree. We would pick a style of post-coordination... We would pick a style... Use general code... and would pick...

Stan (cont'd): Argument for pre-coordinated is that you see it all the time... in our lab system. But... for consistency... Presenting to users and to other situations.

Gerard: Representation on screen issue and... Not the same.

Stan: Exactly. Other thoughts?

[no response]

Proposal for Preferred Strategy to be Post-Coordination

Stan: So, proposal is - would choose our appropriate level of post-coordination... at a level of things that are clinically useful. Would be our style reference... Our preferred strategy would be to move to a standard level of post-coordination.

Linda: I am not opposed to that approach but we need to consider what happens to original text when we share information.

Stan: Yes. Probably best in discussion of Problem-list entry. Like to discuss and make good examples - say what we will do.

Linda: A future agenda.

Stan: Yes. Aggregate. Pre-coordinated even though operating on post-coordinated. We will put that in future discussion.

Static vs. Dynamic Binding - Do we need to represent?

Stan: The idea that value sets might be maintained separately from people with model. So have a model - capturing health issues or problems for the patient, and they are coming from SNOMED CT... the concepts that go here come from SNOMED CT, and must be a finding or... So is an intentional statement. So... whether we do that kind of "and"-ing in value set or...

Stan (cont'd): But static vs. dynamic... Then people might be adding new diagnosis-sets, and your intention is... could be any values that exist in SNOMED, or I want to restrict this and only those at a certain point in time. So dynamic - as people add, they are added to field. Or static - no - only what exists. And if want, will add...

Linda: Dynamic Binding would require all to have access to terminology server?

Stan: ...They would need to anticipate errors that occur because people sending them new codes... Not coordinate... but able to manage the errors...

Thomas: If terminology is managed where new siblings are allowed, then have to use static... I think it comes down to what terminologies are out there and what implement.

Stan: We care about... Drug codes from First DataBank... comes from RxNorm too. But... as distributed from First DataBank... So any point in time - if ask "Was this thing available at... point in time" then we could go to ... and answer that.

Thomas: Depends on... concepts...

Stan: That has been our experience. But general question - do we allow both static and dynamic... Meta-data associated with this.

Thomas: Maybe more... at a higher level in environment.

Stan: Not set per model? But set as global strategy.

Thomas: [can't hear] ...but everywhere else... Use normal binding. Would be simpler... Better to avoid if could.

Stan: Yes.

Gerard: I see the reason why you can have both... I think we need facilities for both.

Stan: We do dynamic binding for drugs. But [the thing] which we should have done static is in order... order priority... If stat order... or routine... But if people add things... we want to do static bindings for those and then upgrade... orderable - want to have happen as people order... Not set globally, but small set as people...

Linda: Terminology server version of enumeration rather than as hard-coded.

Stan: Not a (?) question.

Linda: Have a fixed set of values... Can be extended... I agree with those use-cases.

Stan: Thomas - as more questions.

Thomas: The default if term and ... were well-managed, then types of Hepatitis are non-A, non-B... That is OK... represents reality. So bind to Ref-set and not care about if context changes. So - non-A, non-B - people will use children of that. Won't break. But if... then need to say "I was only pointing to... for this date and time".

Stan: A pre-requisite for dynamic binding is assumption that... is maintained. But my assumption... I create ordering software that depends on order status, if someone adds another status then my code will break. So if someone puts up status of cancel and not used before, then my software will break because not known. And if we add cancel as new status, then I will add to software. Keep behavior of software in sync ... So consistent management of terminology with... software versions of known context of status fields...

Thomas: Not mean the decision to... is not dependent of software. Could be different across implementations.

Stan: No - If one group has status of cancelled and the other doesn't then not... Need to share semantics.

Thomas: Any new addition... breaking the rules... older software gets new data... Those codes are...

Stan: It knows they are children, but would still not know what to do with it. Would create new child because know what to do with it.

Thomas: What decides...?

Stan: Things that determine... in software. New drug... not change anything... New status...

Thomas: Some... are hard-wired to Ref model... But already in Ref model... Are you thinking of things not in Ref model?

Stan: Yes.

Thomas: So how to know which things will influence the software...?

Stan: Yes - if it is tied to behavior.

Linda: If need this, what are syntax implications. URI with a version or not a version...

Stan: Yes.

Thomas: Probably the answer. One half the room... [can't hear]

Stan: Has been done in HL7 a lot and has not been contentious. Need Harold to...

Thomas: ... [can't hear]

Stan: In the end... In our binding syntax... do we allow a version to be specified...?

Future Meeting Schedule

Stan: We are over time. I won't be here next week. You can go on without me, but...

Linda: I suggest we cancel.

Stan: OK. Pick up in August. I think Sarah will send out availability in August - a common vacation month, so will decide.

[end of meeting]