CIMI MTF Minutes 20140612

From CIMI
Jump to: navigation, search

CIMI Modeling Taskforce - Meeting Minutes

Thursday 12 June 2014 @ 20:00-22:00 UTC


Attendees

  • Stan Huff
  • Linda Bird
  • Harold Solbrig
  • Deepak Sharma
  • Daniel Karlsson
  • Joey Coyle
  • Dave Carlson
  • Patrick Langford
  • Sarah Ryan
  • Eithne Keelaghan

Draft Agenda

  • Do we want to have an MTF face-to-face meeting this year?
  • Open HSPC meeting on FHIR profile creation, July 7-8, Salt Lake City
  • Review of final RM
  • Review of proposed reference archetypes - Thomas Beale
    • Composition
    • Section
    • Entry
    • EVENT_CONTEXT
  • Progress on next steps
    • Create new BMM from EA, new UML model (Michael, Joey, Patrick, Thomas)
    • Finalize the reference archetypes needed for lab and lab panels (Joey, Patrick, Thomas)
      • §  Make a new version of "proof of concept" types (Thomas)
      • §  Are there additional intermediate types
        • Atomic item group?
      • §  Cover types needed for individual lab results and lab panels
        • Entry like
        • Cluster
        • Clinical Data Group (distinguish atomic from collections)
    • Create one or more secondary reference archetypes for lab data (Joey, Patrick, Thomas)
        • §  Numeric lab
        • §  Coded lab
        • §  Titer lab
        • §  Ordinal lab
        • §  Textual lab
    • Create some specific lab models (Joey, Patrick)
        • §  Panels - Complete Blood Count
        • §  Hematocrit, hemoglobin, glucose, etc.
    • Use the models to explore and resolve terminology binding strategy
    • Forward generation of CIMI content from existing content
  • Any other business

Attachements

Stan's Final Notes - Created from Draft Agenda

  • Do we want to have an MTF face-to-face meeting this year?
  • Open HSPC meeting on FHIR profile creation, July 7-8, Salt Lake City
  • Review of final RM - Final per the group on the call
  • Review of proposed reference archetypes - Thomas Beale
    • Composition - make later
    • Section - make later
    • Entry - make now, see below
    • EVENT_CONTEXT - make later
  • Progress on next steps
    • Create new BMM from EA, new UML model (Michael, Joey, Patrick, Thomas)
    • Create mindmap representations of the new reference archetypes - Linda
    • Create two new reference archetypes
      • "Entry style" subject and context association - make this first
      • "Subject in model style" - subject is in each indivisible model - make this second
      • Determine if we want an intermediate parent between these two models and item_group
    • Finalize the reference archetypes needed for lab and lab panels (Joey, Patrick, Thomas)
      • Make a new version of "proof of concept" types (Thomas)
      • Are there additional intermediate types
        • Incorporates the knowledge of information that should be in lab models
      • Cover types needed for individual lab results and lab panels
        • Entry like
        • Cluster
        • Clinical Data Group (distinguish atomic from collections)
    • Create one or more secondary/tertiary reference archetypes for lab data (Joey, Patrick, Thomas)
      • Numeric lab
      • Coded lab
      • Titer lab
      • Ordinal lab
      • Textual lab
    • Create some specific lab models (Joey, Patrick)
      • Panels - Complete Blood Count
      • Hematocrit, hemoglobin, glucose, etc.
    • Use the models to explore and resolve terminology binding strategy
    • Forward generation of CIMI content from existing content
  • Any other business

Detailed Meeting Minutes

Stan: Agenda review. I question whether we need a Modeling Task Force (MTF) face-to-face meeting this year. Also meeting planned for July. And review Reference Model that was posted by Michael. And talk about archetypes... And anything from you, Harold, and the group doing archetypes? And next steps. That is the proposed agenda. Any changes?

Harold: Looks good.

Stan: OK. So - would we like to have another MTF meeting sometime this year? Next CIMI is in Amsterdam... Nov 1-3... after SNOMED showcase, and overlaps with IHTSDO meetings. Would people like to have a face-to-face and have faster progress in a 2-3 day meeting as opposed to a 2-hour weekly meeting? I can see value, but also, there is expense and I am not sure if people are available.

Linda: I agree. It would be valuable and we would have more progress, but I agree - could people meet? It also depends on the place.

Stan: Well - maybe I should send out something... Would it depend on where... U.S. or Europe or Hawaii... Trying to split the difference between locations...

Harold: Maybe, but [Hawaii] would be hard on Thomas and...

Linda: Who would not want to go to Hawaii?

Harold: I think soon we will have a huge pile of things to do and would be good to meet. Today - not have a huge amount to do.

Stan: Yes - I am with you. Want to get to a place where we are talking about content and not syntax...

Sarah: I think if we could do the [whole?...] and create some deliverables for people, then go into November and show progress... I will help... can do a doodle-poll or other... I would like to help.

Stan: Well - thank you. I appreciate it. If want more content available and more things to do, maybe we should wait a few weeks... So might want to do a poll.

Sarah: I suppose there is no opportunity around HL7 meeting in Chicago?

Stan: Well, that is an opportunity. And HL7 would arrange meeting room. And if folks outside of North America and... are going to HL7, then would help with their travel.

Harold: Additionally - tentative plans re: HL7 - a presentation for... AML(?)... OMG meeting... So we could overlap some AML work there as well.

Linda: HL7 in Chicago, Sept 14-19, clashes with HIMSS Asia, so I would not be able to attend.

Stan: Yes - So we need to do Doodle poll to see conflicts. So we will keep that as a potential, and will monitor. If we have enough work done and have a quorum, then maybe...

Open HSPC Meeting on FHIR profile creation, July 7-8, Salt Lake City

Stan: Next item. Scheduling on HSPC [Healthcare Services Platform Consortium] meeting - open to anyone who wants to come. How to create FHIR profiles from... Also - SMART capabilities. We will have Graham Grieve and Josh Mandel. We just determined dates and location... Open meeting. I wanted to let this group know so could block dates on calendar.

[HSPC meeting dates: July 7-8, 2014 in Salt Lake City]

Stan: Could also think about Wednesday the 9th... AML meeting... So could think about this. In 1-2 days, I should have a draft agenda. Will meet in Salt Lake City... in the InterMountain Health [IMH] facility. I will send information out as soon as available.

Harold: What is HSPC?

Stan: Healthcare Services Platform Consortium.

Harold: Oh - yes - that is the Platform...

Review of final RM - Final per the Group on the Call

[Stan shows a slide from Michael]

Stan: OK - information from Michael. Michael or Thomas on the call?

Harold: Michael sent an email... A minor tweak... we called it 0.2...

Patrick: I sent a note to Thomas and Michael about that. Not gotten back to me.

Harold: I sent...

Patrick: The version of the BMM has a few errors... Is missing URI and string value. If you put those in, it validates...

[I missed a little here]

Harold: I need opinions on whether this makes sense... RM/Model... Directory named RM... I have a... drive... the BMM... If we make changes for the ELP... Let's put in there... Thomas... official...

Stan: OK. So - my question is - does this look accurate according to what we have previously agreed to?

Harold: Yes.

Stan: OK. And I appreciated your email, Linda, about wanting to be able to distinguish whether something is indivisible or a cluster... building block... And whether meant to be included or whether specified in it... I think we can do that. May have already said what codes are required for that structural group. Linda?

Linda: The Reference Model is suddenly able to meet those requirements, but not till the Ref... So I will read.

[Linda reads]

The things I would like to see in the CIMI Reference archetypes are:

  1. A class, which (when clinical context is added) represents an indivisible statement about the patient.
  2. A class, which indicates that everything inside shares the same subject of care and other clinical context
  3. The ability for 1. and 2. to be the same class when required (i.e. the context to be placed on the indivisible statement), so that in simple cases (e.g. heart rate) it is not always necessary to add an extra level of nesting just to support the mechanics of the reference model.

[end of Linda's statement]

Linda: So it is the Reference patterns...

Daniel: Can you forward that to the whole group?

Linda: Yes. Stan - were you talking about... in reference to the Reference model on screen?

Stan: Yes.

Linda: OK.

Stan: So - we think this is good, but we need the next level of Reference archetypes you will be sending out to the group. So next step...

Linda: Yes. This is the basis for that.

Stan: Good. Question or thoughts? Need to state them because we are getting to the final...

Harold: OK. I am seeing if Thomas' email relates to this. No - it is about using it, not changing it.

Stan: Good. So we will assume that this is final until we find a deficiency on modeling... So that is good.

Harold: Question - how keep in Repository... CIMI Repository?

Harold: Can I steal [GoToMeeting presenter] control from you, Stan?

Stan: You have the power...

[Harold shows GitHub on the screen]

Harold: We had the 1.0.1.2... contained 1.0.1.1... We started updating to get it down to 1.0.10... A problem that... and the versioning labels have... way of doing... Not sure I am happy, but so if someone decided we were to do 1.0.1... then they would have to do here.

[Harold shows on the screen how to do this]

Harold: So I think we could update these models without doing any harm. OK?

Stan: OK - but ask Dave and Patrick.

Patrick: Goes outside of GitHub... Keep track of new document.

Harold: We could tag it... Kind of redundant. I am open to suggestions... I don't want this to happen... One half in history and ½ in... And I don't know how to get 1.0.9.

Patrick: And I have 1.0.11 - did not make it in.

Harold: Yes - and here we have documentation and... So take a look at it and if idea about how to clear up...

Patrick: I think having a latest directory would be good. I'll think about it.

Harold: Yes - Directory file. So if... want to find final version 0 and minor 0 and minor 1, clearly separated...

Daniel: When using subversion, you have a [?] and a tag holder and... I don't see that in GitHub...

Patrick: Yes - could do as a branch... but is complicated.

Harold: Yes. I don't mind redundancy, but... Want to have a good idea... Want to find exactly what I want.

[Stan becomes presenter]

Stan: OK. Look at and let Harold know if you want to change the strategy.

Postpone Discussion with Thomas Beale on Proposed Reference Archetypes

Stan: Next - Review proposed Reference archetypes. Has Thomas joined?

Harold: No.

Stan: So - don't have to review. So, Harold - what you and Patrick were discussing.

Reference Archetypes - Discussion

Harold: Relates to Thomas' work on Ref archetypes. I am digging through stuff I have in ADL. He took 13606 - their archetypes within the CIMI mini-model. Back out into 13606...

Harold (cont'd): We never got a fully machinable openEHR. So we were using CIMI version 1.0 model. But would like to use CIMI version 2.0. And we discovered Patrick and Joey were getting there... Question that came up. When take 1.0 - from MindMaps, they could do in V.2.0... or take approach like Thomas. Maxi-CIMI... 1.10... Basic archetypes... 2.0... Could do that... Folks opinions on that? Also - if re-do archetypes in terms of [?]CIMI model, it is possible that some of the... that Linda did might get lost... But if they start with working set of not-so-CIMI stuff, then we are dragging (?)... Back onto table...

Stan: My thought - we would want to make Ref archetypes, and then lab content onto those Ref archetypes... because we do want those additional constraints. We want them implemented on a fundamental level, so whole family... You are right. Brings back to entries in entries. But the style where have models without subject and.... included in [?] that does have it... And subject at entry-level... will be a valid way of modeling... Question is - which style of model do we want to be preferred CIMI way of model?

Stan (cont'd): So - one style... at level of entry and other would be... and both in repository. We have decisions to make. One style is CIMI-preferred. Or one preferred for labs, other preferred for patients... So - I am excited and glad that we have a Ref model that allows both to be represented. But we need to make a stylistic decision for CIMI. That is OK. Actually the governments and organization and other people who will make their own choices for style. So - U.S. CDC might say "we don't choose same model as CIMI... Ours is different". But the models they need would be in repository. And CIMI models would be for interoperability. I am coming to view that stronger preference is by organizational bodies and not what CIMI wants.

Linda: The goal is to have some CIMI Ref archetypes... What is most effective way to get there? Using new model with Cluster and... and build up the Ref archetypes and put in afterwards? Or build Ref archetypes on old model which would... and then modify that. I suspect putting Ref archetype on old models will be easier mechanically, but I wonder if then... more difficult for new Ref archetypes. And... in Ref archetypes... subject-of-care... sort of like a Ref Archetype... to represent subject-of-care. So I am undecided. As long as we agree on goal.

Harold: The one thing that concerns me - if we have some map to source and some to cluster... and map all down to item-group and element... And I assume, if we map to same place, we lose that intent.

Linda: The good news is - all of the ones that were intended to be an entry have the [?]... and would not lose that. So easy to distinguish...

Harold: So, in a sense, there is a foundation model beyond the...

Linda: Yes - all built on clinical-entry, which contains a subject-of-care.

Stan: We may have to do things before I understand completely. I am inclined to go with models built on set of new archetypes, rather than create Ref archetypes to start back where we were and then modify them. Even if have to hand-modify some of the models... Might have more labor in making new CIMI-models.

Linda: Can I grab screen?

Stan: Yes.

Linda: So - no old archetypes... Each of the Entry-ones inherited from... included... from Ref Model. So, this specialized entry with subject-of-care and if we consider all to have subject-of-care... But originally we thought would be some without subject-of-care. My point... specialized archetypes will inherit from this... so will be easy to distinguish.

Harold: Patrick and Joey - make sense?

Patrick: I think so.

Harold: Can take for quick test drive...

Patrick: Yes.

Stan: So you are saying - we would make new Ref archetype with clinical entry. So would be no need to have made entry... The real usable part is clinical entry. Have a choice... either... or jump to new clinical archetype with clinical entry.

Linda: That is a choice. But if go to new Ref archetype, then... and will have a choice.

Harold: That makes sense.

Joey: I am a little confused. So, Linda, are you saying we don't model entry, and we model this as item-group so you can use in entry?

Linda: Two steps. Model clinical entry based on [?]. Second - whether insert Ref archetype in between... or rename clinical entry to...

Joey: I think we need to draw something out. Anyone else confused?

Stan: I think you are right. I need to see examples.

Joey: I need to see...

Patrick: That would help me as well.

Linda: I will look for diagram.

Stan: So - I think we all agree. Would make new archetypes that are based on item-group... And if insert another level... Might want another level between a new clinical entry... item-group and Ref model. Not clear - the purpose of having another layer. In making new clinical entry or group, I would have incorporated whether is complete... statement...

Slide - Linda's Diagram

Entry modeling patterns

Linda: Then clinical entry level models... Perhaps the first step is to replace entry with item-group. Question is - do we need to add new entry class? And do we want to support... for population health... not subject-of-care... and want to call clinical statement?

Linda (cont'd): So that is your question, Stan? If want to add Ref archetype between item-group and clinical statement?

Stan: We clearly want to have a family of models that follow traditional... And want other family of models... And need Ref archetype for both. If to be accurate according to... Clinical statement - inheriting the style. And could have other clinical statements... So clearly want ... at least 2 Ref archetypes... One supporting the traditional style and another allowing mixed subject... As you said, item between item-group and entry that is the parent between those 2... I am wondering what is being specified in Entry here... Would these be other things derived from Entry that would not be clinical statements?

Linda: Reason to insert is... the requirements... a type that states whether indivisible or not... Shares the common context...

Stan: I am thinking about that. So if went directly to clinical statement, then we would have included in clinical statement what the context was, and whether indivisible. And... I guess it is whether... how many variations we have on that... If only 2, then I would incorporate into 2 different types... But the more I talk about it... it probably gets to same places... If are about what open style statement looks like versus entity... So I am agnostic...

Linda: Probably... there was talk about whether collapse into Ref model. Would want Ref archetype... But if keeping as Ref archetype, it probably does not matter. Just something to keep in mind.

Stan: So I could go either way. If advantage to 1 style then... So if easier... for 13606 or openEHR, then I would say - go ahead and include.

Linda: We could generalize down the track as well. Would probably be easier to work on clinical statement level... and if we thought later to generalize out, we could do that...

Harold: Yes - probably no... down the line. Would like to see... quickly.

Stan: OK. I propose we go ahead and make the model at the level of clinical statement. So would incorporate subject and content. The other would be... to make inside the model. If we make these and we think are correct, then... We would then have specific examples to base the intermediate type on.

Linda: Yes.

Stan: So - next steps. We would say...

[Stan adds to the agenda]

Create Two New Reference Archetypes

Stan: We would say "Create 2 new Reference archetypes.

  • "Entry style " subject and context association - Make this first
  • "Subject in model style" - subject is in each indivisible model - Make this second
  • Determine if we want an intermediate parent between these 2 models and item-group.

Stan: Does that capture what we said?

Linda: Stan - could you explain the difference between "entry style" and "subject in model style"?

Stan: The entry style is like openEHR is now where subject is specified... And Hematocrit and Hemoglobin - each would not have subject specified in them. Happens at entry level. The other style would be to put subject in Hematocrit... to say whose it is in Hematocrit.

Linda: So...

Stan: Yes - those are 2 styles of models I would like to have enabled by our framework.

Linda: [?]

Stan: Yes - we would say "The CIMI-preferred-style is the Entry-Style" or could have one style for... and another style for... We would choose which style is CIMI-preferred style.

Linda: Thanks.

Stan: OK. So I am wondering how this relates to what we said before. Do we need Ref archetypes for compositions and sections, or can that wait?

Harold: I was thinking that could wait.

Linda: Yes. I was thinking could wait also. Danger would be could take longer to do now...

Stan: I forget what Event-context is...

Linda: Event-context is an openEHR thing. I was thinking... on the content...

Stan: OK - yes.

Daniel: It is the... location and that type of thing of HealthCare complex.

Stan: OK. So next thing we want to do is... this is the next thing we would like to make. We might have some intermediated types we want to make between these 2 types and... These become Ref patterns for all numeric lab things and... Would include what we modeled in Mindmap. Specific to... Would incorporate the knowledge of lab models... And then go on to create 1 more... the secondary or tertiary lab reference... Is that a roadmap of where we want to go?

Harold: Yes - as soon as possible.

Stan: Are we dependent on Thomas for these? Or Joey or Patrick?

Joey: I am not sure what they look like.

Linda: Look like another archetype.

Joey: ...

Patrick: I have a rough idea.

Linda: I could have ideas on that. I am traveling over the next few days, but I would like to contribute in that area.

Action Item: Create MindMap Representations of the New Reference Archetypes - Linda

Stan: OK. Should we do that first? "Create mindmap representation of the new Reference archetypes".

Joey: I could...

Harold: I could help...

Stan: So - You OK with that Linda? In the next few days?

Linda: I leave in 4 hours on a trip to Denmark. I will do this in the next few hours or on the plane. I'll do my best.

Stan: If you have these Mindmaps...

Linda: I think the first step would be to create UML, but I do not have access to EA [Enterprise Architecture]. So I will have to sketch out...

Patrick: Outline form would be fine.

Linda: If I could sketch out before flight, then Mindmap before meeting...

Stan: If could sketch out... If we understand, we could create Mindmaps or archetypes... Getting Mindmaps out in a form we could understand.

Harold: I have to leave. Apologies. Thomas had a short question he emailed us. You may want to take a look at it. So we'll talk next week.

Stan: Thanks, Harold. So let me pull up Thomas' email.

Stan (cont'd): So I think we will have some different flavors of Ref archetype. So I think his second question about "target a CIMI entry type for a forward generation..."

Only Use "Composition" or "Section" when meaning is close to 13606 or openEHR

Stan: We probably want to do what Thomas has done here. For things that are different... I think want to do... item-group. I think we should only use "composition" or "section" when it is very close to 13606 or openEHR meaning since is where it came from. Otherwise, need to come up with different names. But if slightly different, then... What do people think?

Linda: I completely agree. Should call it something else if it is different. CIMI_composition - I can't think of an alternative. Too bad can't call composition in the CIMI namespace. Although he might mean the first thing in the... would be... So it is just his template... composition...

Stan: OK. I will respond to his email and say Yes - naming convention will be fine.

Stan (cont'd): What will be in new Ref archetypes? So can make new Ref archetypes. And as soon as that is done, then 1 or more... to express lab models. So Hemoglobin and... Want to get there so can have binding discussion. Other?

Stan: OK. Thank you all. I am glad for the progress we are making. Steady but substantial. I am glad how things are going. We stand adjourned.

[end of meeting]