CIMI MTF Minutes 20130228

Jump to: navigation, search

CIMI Modelling Taskforce - Meeting Minutes

Thursday 28th February 2013 @ 20:00-22:00 UTC


Linda Bird

Patrick Langford

Sarah Ryan

Harold Solbrig

Rahil Qamar Siddiqui

Joey Coyle

Mark Shafarman

Cecil Lynch

Michael van der Zel

Gerard Freriks

Stan Huff

Eithne Keelaghan


  • Weekly News & Updates
  • CIMI Reference Model Review:
    • Changes to the Core Model
    • Discuss the Participation Model
  • Next Meeting:
    • Reference Model:
      • Data Value Type Changes
      • Remaining Changes
    • Transformation demonstrations
    • ADL generation for Laboratory Results

Detailed Minutes

Linda: Get through as much as we can today.

Image 1

Michael: My plan is to discuss changes to Core Model... will be discussion. Remaining changes - Proposed changes... don't know yet what direction to move in. Need Use-cases. Then other topic... we should do... Before Reference Model, we agreed to a number of requirements. Another we must do - complete documentation in Model... Guidance... And then make sure the tooling we choose will use the Reference Model. One is XMI(Dave's Tools), BMM (Tom's Tools), XSD, AML... Any comments? Questions?

Linda: Looks good. If could condense into a couple of sessions - good.

Recap of CIMI Guiding Principles and Rules

Image 2

Michael: Recap of Guiding Principles/Rules.

All say we should minimize complexity - make sure no hidden stuff in model [such as] recursion, deep nesting and abstract anti-patterns. Another - keep in mind what model based on... what Reference Model looks like in XML. Another [principle] - if no Use-case [for element], then remove class or attribute. Did with OpenEHR Model. Other - Clinical Models defined using the CIMI RM are 1 Transformation away from implementation. This is the reason we removed most of the Runtime attributes because are not required in the clinical models. Structural support is in the RM, use Patterns and Templates for clinical content... that will not end up in Reference Model. The Guiding Principles will be in the StyleGuide... Consistency in naming, use singular forms, classes UPPER_CASED with underscores, Attributes lower_cased with underscores... Model looks consistent.

The Parts of the CIMI RM - does not include terminology/meaning binding

Image 3

The Parts of the CIMI RM. The full CIMI Reference Model consists of the Core Model, the Participation Model, The Data Value Types, Supporting Classes and Primitive Types. Another thing to keep in mind - the terminology/meaning binding is not in the RM. Each locatable element has an archetype_node_id (+ tagged values in UML) and (CODED_) TEXT datatype attributes. .. separate from Reference Model... Bound to a meaning - Archetype_node_id.

Mark: So where do we find the meaning terminology binding?

Linda: This is part of the archetype, so in the clinical model and part in the reference model.

Mark: So Reference Model gets transformed?

Linda: No - archetype Model is a constraint on Reference Model.

Mark: OK.

Michael: Important to understand - Not in Reference Model. We will have meetings [in which we will] talk about this.

Changes to CIMI Reference Model

Image 4

Michael: Types of Changes - Summary of things that have changed. Cleanup of run-time elements. Direct associations between classes, instead of via references - so these reference classes are no longer used in the model. Another - Attribute naming consistency. Extensibility of Locatable classes.

Image 5

Michael: So now I am going to the next slide. Changes to the RM (13-feb-2013)

[cannot hear Michael very well]

Michael: #1: Renamed "Core Reference Model" to "Core Model" because it is the core of the whole CIMI Ref Model

Linda: Michael - your sound is breaking up for me... hard to hear.

Harold: Also for me.

Renamed Demographics to Participation Model

[Changes to RM - #2: Renamed Demographics to Participation Model - Actual Demographics will be patterns/archetypes of the Participation Model]

Michael: OK - There was a separate... called Demographics Model. Not much Demographics in there - we changed to Participation Model. Can be used to create... Demographics.

Michael (cont'd): Did everyone have time to look at the pdf I sent? Linda - I know you probably did not...

Harold: No - I didn't.

Michael: So - I say what changes I made. Should I show for each bullet?

Linda: For #3 - please show this.

Michael: So - I'll show Reference Model - what it was.

Michael: #3: Insert CORE_LOCATABLE and put participation, we only want participation on COMPOSITION, SECTION, ENTRY, CLUSTER and ELEMENT]

Image 6 - Core Reference Model 1.0.6

Michael: My mouse is on Locatable class. Can have participation. Don't see problem... Look at Demographics. The Party can have Participation. Not supposed to happen. We only want Participation on a Content Item - not on Party or Role or Actor. This is an error in the Model at the moment, so we had to repair this.

Image 7 - Core Model 1.0.10-WIP

Image 8 - Demographics Model 1.0.6

Image 9 - Participation Model 1.0.10-WIP

Participation on Core-Locatable

Michael: Introduced Core-Locatable - Participation on Core-Locatable.

Linda: Anything that is a Locatable can be archetyped - the focal point. Can create an entry archetype since it is a Locatable. The suggestion was to make Participation a Locatable so that it can be archetyped. Needs to be a Locatable so has archetype properties.

Gerard: What I see now is diverging from ISO 13606 because in 13606 Participations are only related to the composition and entry classes only. Each class can have a separate participation.

Linda: Yes - clusters and sections needed to have participation as we have examples of these in our models.

Gerard: This part will be removed when we translate into ISO-13606 from the archetype patterns. When we define these transformations we will need to document this.

Stan: Make difference in Leaf models - whether we include Participations just on Entries or on their specializations ...

Gerard: The Participations in the SYMS approach are modeled in the Entry archetype

Stan: How do you get by with that? Seems you need participations related to a cluster.

Gerard: Part of entry hierarchy where you find a cluster that defines participation. Archetype to indicate who is participating.

Michael: So you will create an archetype documenting the participation?

Gerard: There is an archetype that describes the participation pattern. In the entry class, this is the start model for a procedure, the Entry uses cluster models as part of entry, and this is where the Participations are - at the archetype level.

Linda: How do you link the entries to the parties? You create the participation archetypes and...?

Gerard: The demographics is a pattern at the archetype level.

Linda: No roles and actors?

Gerard: No - we expect this to be modeled in the archetypes. But this is not part of the standard. Will be proposed for next version.

Stan: Presents an interesting issue. What we hope is that we could support those using Reference Models - they would be able to make the logical models that are one step away from implementation and can transfer to different Core Reference model. If we get into situation where all models have to be identical, then this defeats the purpose. Seems there must be a way that this Reference Model can vary, but you could make the same terminal model.

Gerard: No reason can't use transformations to do this. Just pointing out that we only have participations as archetypes.

Michael: As long as you can distinguish what is a participation. Same issue with transforming to HL7. Depends on where you cut the model.

Stan: If we model this way, is it going to make it impossible to make models you want to make... or to transform to 13606... are they compatible?

Gerard: What is meaning of participation of a Cluster? Is there a semantic difference? Difficult for me to say it is impossible. We need tests in order to do that.

Michael: In our Cimi Reference model - we should have all the information so we can transform. Some of the models are... [can't hear]

Gerard: Similar to context inheritance in v3. We say - the context in terms of participation are inherited from the containing Act. But also can say at some point - not inherited. Maybe we need something like that?

Michael: Should say in CIMI model... [can't hear]

Removed LOCATABLE.uid

[Refer to Image-5 ,#4: Removed LOCATABLE.uid]

Michael: The LOCATABLE.uid has been removed. A Locatable class has a name, an archetype_node_id and an optional uid. However, we already have an identifier on the node, so there is no need to also have a uid.

Mark: If you remove the uid, doesn't archetype_id have to have... so people don't use the same uid?

Michael: In the name of the archetype.

Gerard: The archetype... To have a uid in the name of file is not the best solution.

Michael: The Locatable will have an archetype id, from Archetype Details, which is a unique. An archetype_node_id is unique within an archetype.

Gerard: Is a... number in ADL?

Michael: Yes - No reason why... we could all... The next are... #5.

Changed datatype of to String

[Refer to Image 5, #5: Changed datatype of to String...]

Michael: Changed datatype of to String - because we don't need to code the name of each node that is being captured in the terminology binding since it is just a label.

Stan: So - in my way of thinking, is that even though meaning is captured by code, you might want to manage names people use... terminology-server. So could say - this is the name in English... or Dutch... so could manage the names of synonyms for that concept.

Michael: Yes - I could use case 4 like that.

Linda: OpenEHR - in ontology section of ADL, they map to different languages in archetype itself. Are you suggesting using external terminology for that?

Stan: Yes - what we said is that for value-set binding, the archetype method is to enumerate... type... and move to... and use (?) compile to generate a version of ADL that is compatible to current computers. What I think of as terminology capabilities... of stuff done with AT... Especially names that could be ... specific... Rather than done in ontology part of model.

Linda: Sounds reasonable. It would be useful to document that Use-case. When we transform the models, whether that be to XML or to something else, we need to have a String of Characters to use as the node_name for each node. If you didn't have this translation requirement, could throw away the coding.

Harold: If any consequence requirements with respect to name, we need to document. Can I give any archetype name a code. Are there constraints on this?

Linda: And each node would need a preferred name.

Harold: Yes... turn into code and rules.

Rahil: Using existing terminology concepts to label classes, we may know which description id is used. Run the risk of people treating as semantic labeling rather than semantic representation. Good to have CIMI vocabulary... Just introduce issues downstream.

Stan: So - Any of these node-identifiers would come from SNOMED or LOINC - that would establish semantics... So in our terminology server - we would manage the synonyms. But whether SNOMED picks up - all we could guarantee is in CIMI terminology-server. Is that it, Rahil?

Rahil: I was thinking you meant renaming that locatable. I think you were suggesting a standardized description could be a synonym... RF2 or several preferred terms... dialect. Using the name with SNOMED CT description id. So if not... calling it description id, not concept id... think of as semantics. If not the same, we could have people doing all sorts of... I think that is something we should try and avoid. And if you want consistency across languages this would be useful too... Good if we have other language-server, not SNOMED. What we use to define semantics. Is that clearer?

Stan: No - something I don't understand. I am using SNOMED - concepts and terms and relationships. None of the terms would refer to concepts in SNOMED - what something means. So - this label is a hint. Real meaning is determined by the semantic binding - not its name. So - illegal to use the text name as if the concept... So text is term contained in structure, like SNOMED structure. Synonyms in SNOMED - supposed to be equivalent. I am sure I am not understanding what you are saying.

Rahil: Not sure if I understand correctly. Need example. If we are treating CIMI extension space for these requirements... used to facilitate standard representation or standard labeling, would we bind that locatable to it or the meaning?

Linda: I thought - separate from the meaning.

Rahil: Yes - I thought so. And because, coming from SNOMED... The fact that we are using SNOMED for labeling... will downstream, create some sort of semantics. I don't know why we need SNOMED for that.

Stan: I am trying to use the same SNOMED structure in CIMI representation. Why make another terminology service with... structure if the... I have will work fine.

Rahil: I thought used only for labeling. Not a term-server, but just a language.

Mark: If using for labeling, you still want to use the meaning... still can use the structure. In SNOMED structure, create a refset. Can have both potentials.

Stan: We may need to make more examples... So we can explain.

Mark: OK.

Stan: That is just a general comment - not complaining about what you said, Mark.

Michael: Most of Use-cases... binding... other... runtime name of the (?) used to build runtime part... xyz... XML... no more, no less. Different Use-cases... runtime and four others to understand the model. We need to decide. How do we pursue this issue? Will someone work out an example?

Linda: Next week we can look at example and compare ontology section of ADL vs references as concept... synonyms. Eithne takes notes and all will be recorded. Is this OK to all? OK - Michael.

LOCATABLE classes can now be archetyped

Image 5 [Refer to Image-5, #6: LOCATABLE classes can be archetyped, PARTICIPATION is now a specialization of LOCATABLE]

Michael: I think PARTICIPATION was not originally a LOCATABLE, and could not be archetyped... Changed PARTICIPATION to be a specialization of LOCATABLE.

Removal of Archetype_ID

Image 10 [Image-10] - #1 - Removed ARCHETYPE_ID, ARCHETYPED.archetype_id datatype to String with pattern

Michael: Archetype_ID used to be its own datatype... The only thing this has is the pattern for what an archetype_id should look like ... and the only place it is used is on the archetype_id attribute. So, I'll show you... the archetype-type. Removed the extra class... And same thing we did for template-id.

Removal of TEMPLATE_ID Pending Discussion with Tom

Image 10 [Refer to Image-10, #2 - Removed TEMPLATE_ID, ARCHETYPED.template_id datatype to String]

Linda: I think that was the only place those were used.

Gerard: What is the Use-case of template_id for CIMI? I think it can be removed.

Michael: Yes - I sent that question to Tom

Linda: I would support removal of template_id. All can be done using archetype_id.

Michael: Yes - only used at top-level structures. I will remove it now and then see what Tom says. OK.

Image 10 [Refer to Image-10, #3: LINK.type is duplicate with meaning, remove type]

Linda: I think one was more specific than the other. So, if using SNOMED one can be a specialization of the other.

Michael: So we removed type. Now just meaning in Link. The only one you can put in is the meaning.

Time-Validity Attributes

Image 10 [Refer to Image-10, #4: PARTICIPATION, remove time, also from ROLE, ACTOR, etc. - runtime stuff]

Michael: Next - Time attributes. Demographics model has time-validity. Do we ever need to archetype time-validity of model? That is something you do at runtime. Proposed to remove all of the time-validity attributes.

Linda: I think of it as the opposite. All demographics have datetime range, such as the datetime range that an organization exists or the birth and death dates. So time-validity is being done in the clinical model. So I would be happy not seeing in Ref model.

Gerard: You raise the question of whether this should be in the reference model or the archetype model. Advantage is - can be flexible in archetype model. I don't know if stable enough to be part of Ref Model. Want Ref Model to be extremely stable. Just like with Participation... I don't know if this is stable. There is a place where you have to deal with time, but it’s not in Ref Model... You never constrain it. Correct?

Linda: I think you may want to constrain it. We can define constraints on the time-range.

Rahil: So by removing time-validity, if someone wants to include a date-range for something specific... If participating on that capacity and want to see if Power of attorney is only valid for a particular period of time, is this possible?

Linda: Yes - allows you to... has a specific meaning of the date range at which that participation is valid.

Rahil: Party-relationship pointing to abstract Party. Party is at the abstract level. Actor, and Party relationship between 2 roles. Is the same thing that...?

Michael: Can we get to that later? Finish this first?

Rahil: Yes.

Participation - Remove Mode

Image 10 [Refer to Image-10, #5: PARTICIPATION, remove mode. 2 options, put all lin the RM or use details to archetype and add the extra stuff]

Michael: The mode that the party participates... The other - the function - attribute of participation. We discussed whether this mode is regularly done or not. Not recorded if done face-to-face or email. We should remove... If you really need, can add... Participation model...

Linda: Participation mode is present in a few of the models ... so we need it in the CIMI models, but this can be included in the clinical models...

Michael: What is your Use-case? Where say that...?

Linda: I know IMH Model - whether consultation done over phone or internet.

Michael: Yes... then is relevant.

Stan: I am not sure whether we used in models. I agree with the strategy. Joey - Mode of participation - person-to-person or phone or...?

Joey: I wouldn't know.

Stan: I have to look.

Michael: OK.


Image 10 [Refer to Image-10, #6 Add PARTY_RELATIONSHIP.type "The detailed description of the relationship."

Michael: We added Party_Relationship Type.


Image 10 [Refer to Image-10, #7 is now association, EHR_URI is a runtime thing, just like the REFs.]

Michael: Part on Ref Model where the Link class had a target attribute and... A pointer to another model. But the way you implement to EHR is implementation-specific. So in Ref Model we changed to... LOCATABLE. Point to each other through a Link. [see Core Model 1.0.10-WIP]

Linda: Allows this to be defined at the Logical Level. Notice the black diamond - Link is composed into the source of Link, but not composed into the target...

Michael: ... Where is this?

Harold: What is cardinality on target?

Michael: One. So, LOCATABLE can have multiple Links, and Link can have 1 target. I think we should add that... doesn't say. I'll fix.

Added direct link to PARTY

Image 10 [Refer to Image-10, #8 Added direct link to PARTY, and removed PARTY_PROXY. If you go through a PROXY is an implementation thing, just like the REFs.]

Michael (cont'd): OK - the same as Party-Proxy [#8]. Look at old Model... Party_Proxy... Look at new... Participation...

Image 10 [Refer to Image-10, #9 Remove PARTY_RELATIONSHIP.time_validity, also from ROLE, time_validity also run-time]

Michael (cont'd): I already mentioned [this] - #9. And minor things... #10.

Image 10 [Refer to Image-10, #10 Renamed <class>_type to just type, for consistent naming ROLE, PARTY, PARTY_PARTICIPATION, PARTICIPATION]

Michael: So what I did - we renamed those attributes...

Null_flavor in ELEMENT class

Gerard: I see in element class - the attribute NULL. Is this necessary? Null-Flavor?

Linda: That is part of original Open_EHR model. ...Make sure not part of ...(?) data types. What Graham suggested for FHIR as well.

Michael: We had lots of discussion about this. I don't know if... Use-case for it.

Gerard: When trying to implement at data-type level, makes sense, but not for CIMI.

Stan: I thought does make sense. Why Gerard? Are you saying that would be added back in as make archetypes? You need at implementation?

Gerard: There are many things you need when implement, but null_flavor - have we archetyped?

Linda: Some circumstances when we need to include this in instance data.

Gerard: I don't think we need for clinical model. Ref Model - yes, I want to see.

Michael: ...(?)

Gerard: We will have questionnaires, but will use clusters and data-type...

Linda: Set of possible null-flavors does vary depending on circumstances.

Gerard: Yes - but at implementation level why something is not present is important. But when we model the meaning of things, this is not important - at the semantic level. At semantic level, not Ref level.

Stan: So, I need someone to clarify for me. I may be confused. Our reason to include in Ref Model sometimes has to do with whether we need it in instances. It is a general capability we want to do consistently in everything. You do need to model. Not just an implementation detail. Need modeler to know... that there is someplace for that to go - such a common behavior. I don't have to make an attribute. You have to have at runtime, we all agree. Either be here or could be an element you add, a cluster, but all would be a cluster... have a null-flavor... Nothing would be a true element because all would have a null-flavor in it.

Gerard: When you implement archetypes in implementation space, you need a null-flavor - yes. But when I am dealing with clinical... only semantic level, not bits and bytes. So we decided is a state thing and not a null-flavor thing. Model - using cluster and elements... only need a few places, not in every element. In the data, it is given... modeled in when produce the archetype... content... The distinction between at bit and byte level and semantic level. Same as ordinals - as bit/byte level and semantic level. But I don't have problem.

Stan: I think I am not smart enough to understand the implications. I suggest we leave it in now and then when use... we can take out.

Gerard: That's OK.

Stan: If I am the only one...

Gerard: Let's leave it for the moment.

Global mapping CIMI RM to HL7 RM

Image 11 - Global mapping CIMI RM to HL7 RM - diagram]

Michael: Mapping from CIMI RM model to HL7. Makes it clear. I want to do the same with 13606 so you can see how done.

Linda: Yes - but depends on how much we must finish off...

Participation Model, Participation/Role, Party, Actor

Image 12 - Participation Model

Michael: Brings us to discussion on "Party" - part of participation model... Part of Party... In HL7, a separation of 3 classes. Entity, Role, Participate in Act. In CIMI model, we can simulate this same structure. A Role - item in an element...structure... Sometimes you collapse the Role and Participation and... So the Actor and Role collapse. Same for Role and Participation. Almost the same - sometimes difficult to distinguish between the 2. Don't know what way to go, but you do need distinction. I don't know if we should allow collapsing of thing.

Mark: We should look at specific Use-cases and see how map and that will give us a feeling for it. ...if we include entities, participating in Roles, this covers most things. It’s a matter of going through Use-cases.

Rahil: Yes - Mark said what I want to say. I think... we discussed... the different ways in which Role and Participation are being used. Would be helpful... the definitions of what we mean, the class Participation... the class Role... and what goes into. There was one example... suggested as participation for CIMI. Would be useful. Would determine if we need... Understanding what we need and how we should use them.

Linda: Any example, Michael?

Michael: The one I have is... I don't have an example.

Linda: Off the top of my head... an example of surgery with organ donor participation, and the actor that participates is the person who donated the organ. I would have that Participation and Role would be organ donor.

Mark: I can give one. Physician working at hospital - a Role of physician - licensed category. Scope is State-licensed authority. Physician Role might be surgeon. But might have someone participating in role that has a different license. Or might have an intern... not licensed... both participating as surgeon. But intern in Role as surgeon... The Role of Surgeon is a classification at hospital and different from participation.

Linda: Quite clear when you have Healthcare Provider. But when participation of general public - when not a licensed role in Healthcare - a bit harder.

Mark: In v3, the role would be patient. But Participation would be subject. So it could be organ donor, or citizen could be organ donor. You want to provide for both... either a standard role or participation for those things... still is useful.

Linda: Yes - useful.

Rahil: Mark is mentioning licensed role - we call the job - role - (?)... Whatever the certification. But back to organ donor... within the LRA, we use the Participation function... the spreadsheet you sent out with CIMI value-set... Those were the sort of Participation types that were used. Donor would be a specific role, but participation function would be the act of... or something similar. So if participation was... and ... could be identified through role. That is what I wanted clarity on - how CIMI is using Role and Participation.

Linda: Role is not a type of participation - Participation is how they participate in the healthcare event about which the information is recorded, whereas the role is how they are involved in the healthcare set or more broadly.

Gerard: The fact that we are discussing this - are things not stable? Everything dealing with Participation is undefined.

Linda: No - I think we just need to document better.

Michael: Whole point of the Ref Model is to identify points in the archetypes, and I am sure that distinction between roles and actors has to be made. Want to be [can't hear]... what the Ref Model is like...

Linda: Hard to hear what you said, Michael.

Michael: We want to achieve a stable first version of CIMI Ref Model so after can start building clinical models. So - we can change the model a lot, but things that are already...

Linda: So big question - whether we force Participation to go through Roles to get to Actors, or whether we allow Participation to go directly to Actor. There are models with assumed Role, so allow Participation directly to Actor. In some environments, when want to restrict participation-role-actor... but then environments... prefer to keep. Other - example... Actors can be people, organization, device. So in case of device... Role of device in Healthcare environment may be... healthcare event. May be similar... Device examples, Mark?

Mark: If we go this way, what will be needed to transition from CIMI to HL7 would be dummy Participation in the transformation... Without the Role you lose some of the administration - you need to track. So if you don't have one of these classes when do transformation, you would have to add.

Linda: Yes - I think only leave Role out if can be assumed by the Participation, and recorded in the metadata.

Mark: So, maybe when leave out, we have... document to support the transformation.

Michael: So this would be the... [can't hear]

Linda: So, Michael, you still have the Locatable uid - intended?

Michael: No.

Rahil: Also - cardinality... [0 to ...] because you may not have a Role.

Linda: Michael - how much more do we need to go through for stable Ref Model? Do we need next week? Only have 3 minutes.

Michael: [can't hear] A couple of issues on the data... type... Part with the temporal data types. I think that is it.

Agenda for next week

Linda: OK - excellent. Are all available for next week.

Gerard: Not me - I am in Madrid.

Stan: I will be available.

Linda: All others?

[no response]

Linda: Just - [next week's] agenda. We were planning to start on Transformation. Gerard has arranged for people from Spain to demonstrate. I haven't heard from... and a problem with NEHTA demonstrating. Michael - if you can let me know if you or William can present yours next week.

Michael: I'll get back to you.

Linda: And - would like to get feedback from people about what to focus on... StyleGuide, immunization models... Any preferences?

Stan: I would like to see us use the Ref Model and create ADL or AOM or whatever our single formalism... move from Mindmaps to shareable models in our formal system.

Michael: I am ready for transformations... [can't hear] I have to make sure the CIMI Ref Model is... export into BMM... [can't hear]

Linda: Sorry - Michael - only heard some of what you said. You said you want to move on with tooling?

Michael: Yes - next week... I am ready for the... [can't hear]

Linda: Stan - I agree with what you are saying. Problem is dependent on tooling work to generate the ADL to AOM... or do by hand. But I haven't had success with that.

Stan: I don't think I do. I don't have a suggestion right now.

Gerard: There are ADL 1.4 tools we can use.

Michael: No - they don't support other Ref Models.

Gerard: Not sure - can use any Ref Model. Constraints on Ref Model...

Linda: And we had demo of Link OpenEHR tooling. Better wrap up now. Sorry to be running late.