CIMI MTF Minutes 20130131

Revision as of 15:37, 7 February 2013 by Mvdzel (Talk | contribs) (Created page with "= CIMI Modelling Taskforce - Meeting Minutes = <center>'''Thursday 31<sup>st</sup> January 2013 @ 20:00-22:00 UTC'''</center> == Attending == Linda Bird Galen Mulrooney Pet...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

CIMI Modelling Taskforce - Meeting Minutes

Thursday 31st January 2013 @ 20:00-22:00 UTC


Linda Bird

Galen Mulrooney

Peter Hendler

Stan Huff

Patrick Langford

Mike Lincoln

Mark Shafarman

Rahil Qamar Siddiqui

Jay Lyle

Joey Coyle

Harold Solbrig

Thomas Beale

Stephen Chu

Eithne Keelaghan


  • Weekly News & Updates
  • CIMI Modelling Style Guide - Table of Contents
  • Comparative Analysis Spreadsheet template - feedback
  • Review of Demographics Comparative Analysis spreadsheet & models
    • Location
    • Address
    • Electronic Contact
  • Next week + In two weeks:
    • Review of CIMI Reference Model
    • Review of Demographics Comparative Analysis spreadsheet & models
      • Party, Actor, Person, Organisation, Role, Patient etc.
    • Demo from William
    • Transformations to/from RIM
    • Plan for Archetype Object Model review:
      • Archetype Object Model
        • Review
        • Spreadsheet template
        • Useful Subset
        • Serialisation format

Weekly News & Updates


CIMI Modelling Style Guide - Table of Contents

CIMI Modelling - Technical Guide

  1. Introduction
    1. Background
    2. Definitions
    3. Architectural Framework
    4. Architectural Objectives and Benefits
    5. Document Overview
  1. CIMI Reference Model
    1. Core Reference Model
    2. Demographics Reference Model
    3. Data Types
  2. Model Constraint Semantics (Archetype Object Model)
  3. Model Serialisation (Archetype Definition Language)
  4. Archetype Modelling Language (UML Profile)
  5. Model Instance Representation
  6. Model Transformations and Implementation

CIMI Modelling - User Guide

  1. Introduction
    1. Background
    2. Definitions
    3. Objectives and Benefits
    4. Document Overview
  2. Modelling Framework
    1. Overview
    2. CIMI Reference Model
    3. Archetype Object Model
    4. CIMI Modelling Patterns
  1. Modelling Methodology
  1. Analyse Source Clinical Models
  2. Identify Maximal Data Elements
  3. Remove Out of Scope Data Elements
  4. Identify Modelling Patterns
  5. Define CIMI Model
  6. Add Terminology Bindings
  7. Add Example Data Instances
  8. Technical Validation
  9. Clinical Validation
  10. Model Transformations
  1. Modelling Examples and Use Cases
  1. Examples
  2. Use Cases

CIMI Modelling - Editorial Guide

  1. Introduction
    1. Background
    2. Definitions
    3. Modelling Framework
    4. Modelling Objectives and Benefits
    5. Document Overview
  1. Modelling Principles

2.1 General Principles

2.2 Quality Criteria

2.3 Scope of Models

2.4 Granularity of Models

2.5Consistency and Reuse

2.6 Context and Model Layers

2.7 Isosemantic Models (Boundary of structure and terminology)

2.8 Representing the Subject of a Record

2.9 Terminology Bindings

2.10 Mappings and Transformations

  1. Modelling Patterns
    1. Composition Modelling Patterns
      1. Overview
      2. Clinical Report
    2. Section Patterns
      1. Overview
    3. Entry Patterns
      1. Clinical Report Header
      2. Activity
      3. Request
      4. Observation
      5. Clinical Finding
    4. Cluster Pattern
      1. Observable
      2. Finding
      3. Action
      4. Material Entity

CIMI Modelling - Terminology Binding Guide

  1. Introduction
    1. Background
    2. Definitions
    3. Objectives and Benefits
    4. Requirements
    5. Document Overview
  1. Types of Terminology Bindings
    1. Overview
    2. Value Set Bindings
    3. Relationship Bindings
    4. Object Bindings
    5. Modifier Bindings
    6. Terminology Design Patterns (SNOMED)
  2. Terminology Binding Rules
    1. General Binding Rules
    2. Modifier Binding Rules
    3. Terminology Design Pattern Rules
    4. Model Specialisation
    5. Filling Model Slots and References
    6. Terminology Focal Nodes
  1. Terminology Binding Patterns
    1. Composition Bindings Patterns
      1. Overview
      2. Clinical Report
    1. Section Bindings Patterns


    1. Entry Bindings Patterns

4.3.1Clinical Report Header




4.3.5Clinical Finding

    1. Cluster Bindings Pattern

4.4.1 Observable

4.4.2 Finding

4.4.3 Action

4.4.4 Material Entity

  1. Terminology Binding Examples and Use Cases

5.1 Examples

5.2 Use Cases

      • Query, Transform, Consistency checking, Index, etc

Detailed Minutes

Mike Lincoln: How close [does] binding of terminology have to be for our models? I would like to understand better what they mean [referring to recent email exchanges]

Peter: I wasn't talking about that.

Mike: If someone could explain - I don't understand.

Peter: I can summarize.

Mike: I just want this on the agenda sometime.

Peter: Different ways of how people think about information model. There are... people who think of archetypes - cluster, etc. And others - think in terms of act, and think of clusters as (container?) act. That is what we are. So others - archetypes. And William - a neutral way of doing it - his own UML. Can translate to archetype or RIM. Then Joey - spreadsheets - I thought he was talking about non-RIM, non-clusters - an easier way for us to go to. I am not sure if possible to make transform to get into CIMI. So one thing - is it possible to - the way we do it - to transform? But William, clear UML, he says he can go either way... how this works. But not have to do with vocabulary.

Mike: Example?

Peter: Well - William not here, I am...

Linda: Better to go over during a session dedicated to this. But there was a 3-month (?) period when we evaluated this and decided... and some people present today who were in those decisions.

Stan: I think it would be possible to translate from ADL to RIM. The conversation is fascinating. The RIM Act is a container. Could call it a cluster or... But it is not arbitrary if we decide on... and we could explain it and you would understand. So I second what Linda said. We decided on ADL and with this AOM generic... another way to move away from ADL 1.5 constructs. At IMH, we use CDL, but our constructs are similar to ADL's constructs. If you go to ASN 1 - predates the RIM... It starts with container-types... and primitive types... We are not going down a road that is uncharted. We want to... translation of models... Possible to go from ... to RIM. Purpose of ADL activity is to come up with UML... I think if we continue doing what we are doing we will get to where you want to be, Peter.

Mark: Maybe we should test that out. Maybe when validated and approved, should go second step to get to... RIM format or mutual format...

Linda: I agree, but mutual format means different things to different people.

Mark: Move from RIM to CIMI with minimum of work.

Linda: Yes - important to test. Goal was to create a mutual format. Means different things to different people. So plan for this...

Peter: And maybe look at William's...

Stan: They've built knowledge into the translation engine. You need to add additional info to define the mapping from the model to the RIM. Ideally this translation should be static. Going to the RIM, most nodes map to Acts and containment to Act relationships. But you need to define that special knowledge before you can do a RIM transform. Always like to see tangible things.

Peter: I would like to see that, but next week I can't be there.

Linda: Schedule for two weeks' time?

Peter: Yes.

Linda: And William's demo?

Peter: Yes.

Linda: Transform to and from RIM... We will need volunteers to help...

Stan: On fourteenth, I am hosting LOINC conference.

Linda: Are you available next week, Stan?

Stan: Should be off airplane and in hotel.

Linda: Maybe start this conversation next week.

Peter: Yes - as long as I see William's demo...

Linda: OK. Now - first on agenda - CIMI Style Guide Table of Contents. We talked about separating into a number of guides: Technical Guide, User Guide, and Terminology-binding Guide. I have a proposal for rough content. Improved version I will send out to MTF. Technical Guide... [reads slide]. User Guide [reads slide]. Terminology-binding Guide [reads slide]. 1. Intro 2. Types of Term Binding 3. Terminology Binding Rules 4. Terminology Binding Patterns - how binds to basic... 5. Terminology Binding Examples and Use cases.

Linda: Hopefully that gives an overview.

Linda (cont'd): Now - got into details. All happy with this division?

Stan: Yes.

Rahil: Did we mention... Data Types?

Linda: Yes, into... Modeling Technical Guide Reference Model. Anything should be there?

Linda (cont'd): Any feedback on contents of tech guide? I will re-send out to broader group. So, User Guides - I thought we needed guide that went through methodology. Any feedback?

Rahil: Do we want to talk about UML patterns and profiles in the Technical Guide?

Linda: Good idea. Needs to go to someone. Question is - should there be a separate guide or section? Let's put in tentatively. All OK? Probably need more detailed in...

Linda (cont'd): All OK?

Harold: Yes - seems good.

Linda: So no other comments? Will be focused on how-to do Editorial Guide - started... principles... [reads slide] Modeling Principles. Also, need to document modeling patterns. Don't have... pattern, but will when Medications... and Entry Binding and... Any comments on Editorial Guide?

Stan: There's a combination of core patterns that we use at Intermountain... The whole idea of representing the subject of care... and other patterns, such as assertion patterns and measurement patterns... These could perhaps be some further entries into what you've already listed in the Table of Contents.

Linda: With some of these patterns, will add... Now, patterns with lab results... but I am sure there will be additional patterns and principles. But not sure if we developed stuff outside Heart Rate and lab result. And it may be, once stuff is in, we may see what is missing. I agree.

Stan: Yes

Linda: I am wondering where that would go... representing the subject.

Tom: Is that entry pattern bindings... is that limited to...?

Linda: No - cut and paste error.

Tom: You may want to put something in for administration entries - for things like patient transfers. We archetype these a lot. I don't know if out of scope for CIMI...

Linda: I don't know...

Stan: These are certainly in scope.

Tom: Reasonable... between patient going to hospital and leaving, vs. actual clinical event... encounter... surgical event. You may want to call it workflow or managerial. But knowing when admitted and discharged.

Linda: Yes - in lab result... Now modeling using clinical patterns... Prefer to look at actual models themselves and example of pattern. Add to agenda... Now lab results... If need to correct how lab results are done, obviously these patterns would change. I suggest modeling review at some point. Any suggestions? Stan - add any...?

Stan: It seems like it should be called out. That is probably a good spot.

Linda: And the other - the boundary of structure terminology... You also talked about...

Stan: Down at...

Linda: ?

Stan: Observation... What is different observation under entry.

Linda: Under entry - what test is performed and what tests were... Same structure is used for Heart Rate. What observation performed and what was Heart Rate? OK. Is that all for the moment? I will send out. Thought we would stick to patterns we are currently using now... and can change as needed.

Linda: Terminology Binding Guide. [reads slide] Section on requirements? Need to summarize in here?

Rahil: Yes.

Linda: Type of Terminology Bindings [on lslide], Terminology Binding Rules [on lslide]... A number of general rules... Using a valid object and the Terminology Binding Patterns... establishing basic binding patterns... And looking at specific Terminology Binding Examples and Use Cases. Any suggestions?

Stan: What name are we using for value-set binding? When I want to define the valid values for a data element.

Linda: Excellent point - thank you Stan.

Tom: What does 2.6 mean again?

Linda: The rules of how to map to pre-coordinated terms.

Tom: Oh - right. Design Patterns... and...

Linda: I preceded with Terminology...

Tom: May should put (Kent?) in brackets?

Linda: Will explain, but not put Kent's name in...

Tom: We will probably, in the future, think "what is this?"...

Linda: ... Design Patterns... so I'll put SNOMED in brackets.

Tom: Good.

Linda: Other? OK next. I'll send these out for comments. Speed of developing guide depends on contributions. Rahil and Daniel have offered to contribute to the Terminology guide. If others are available, this will obviously speed up progress. Make sense?

Stan: Yes. At IMH, Style Guide that ... is working on. Would have to be changed, but I am not sure if finished, but at any point in time he could give you the version he has, and he can cut and paste. Would be useful.

Linda: Can you ask him logical point to contribute?

Stan: Yes.

Linda: Next... Comparative Analysis Template. Anneke helped to come up with this. The idea - people could be given new model and start to fill in... and add columns... in parallel. Would be good to eventually have a website that people could go to when ready and see what has been added. Separate what from who and how - to see what has been added... because if 20 elements... hard to see... so if separate logically, can bring closer together... a human aid. I have sent out. Things we could do to extend. We could add separate columns for cardinality. If want to machine-process, probably best to put in separate columns. Other things we might want to add for machine processing... Comments? Harold?

Harold: No comment.

Linda: All happy to give this a go? Next will be Immunization models... so we will allocate and pass around.

Jay: The first thing I found difficult was how to represent data items that refer to other models in the spreadsheet. A data cluster may either be defined in the rows of the spreadsheet, or it might be a slot that refers to another page.

Linda: Like the specimen case. Where we have the data type - I have referred to CIMI data type. I have probably been overloading the SLOT constraint with the data type - as per the Specimen example “CLUSTER<Specimen>”. On that point - it would be useful to have an example on first page filled out. And I know Dennis G was asking for a guide of how to fill out the Comparative Anslysis spreadsheet, and perhaps a video demonstrating this. So have action items on that. If people want to add to the descriptions of the columns.

Linda (cont'd): Demographic Comparative. We will have demo by Michael soon, but he is recovering from operation now. OK. Location. IMH - Patient location... perform... NHS/LRA - place-entity, HL7... NEHTA has...

Linda: So elements. Have an identifier in Singapore. There was a description from IMH and LRA and Singapore. The Location name - there was a name of type in Singapore model... IMH had a Location name-value in their model and location name-use and location name-date... time range.

Stan: Looks right.

Linda: So - Location type. NEHTA had location of participation... And Singapore had a type condition. IMH had... We have the address. Jay - here is an example of where we refer to another model (for address) as a cluster with a reference. If we want to use a more formal syntax we could.

Jay: That looks clear.

Linda: OK. And contact... IMH... There is a Date-time Range... start and end time. The status - IMH has... A mobile indicator - from v3 RIM... Directions indicator - from v3 RIM... Position indicator - from v3 RIM.

Mark: HL7 v3 also has a telecom...

Linda: Yes and I mapped to HL7 v3's 'AD and ADXP' datatypes...

Mark: A place may have a telecommunication address. I can check the RIM, but I am pretty sure...

Linda: My version of RIM could be out of date.

Mark: Oh yes - there it is. Place has additional attributes on the parent class 'Entity', and Entity has a telecom...

Linda: Great. So we should add a mapping for HL7 v3 to telecom and telecom is of type TEL?

Mark: Actually is collection of telecom, and could be more than one.

Linda: Consistent... whether we use collection or have always in cardinality.

Mark: Collection is not necessarily ordered. The numbers don't necessarily mean anything.

Linda: Anything else with mapping to RIM?

Mark: Something else with Entity... an existence... is this thing valid...

Linda: OK - so existence... is a date-time range.

Mark: Yes.

Linda: Any other entity properties we should add, or should we add all of them?

Mark: Good question. I need to review spreadsheet more thoroughly.

Linda: Thank you... There was...?

Mark: Probably not, but...

Linda: If you could... So, the others... based on Point-of-care, room, bed, floor, building, organization... Everyone OK? And thank you Mark for following up on v3.

Mark: The things you were looking at for v2 - some in role code (?) and role class code. You can specify the organization responsible for the role, tracing down the model from role to entity to role.

Linda: Is this in v3?

Mark: Yes. So class-code for a Role can be an organizational thing to deal with in-patient and out-patient and person's location all can be added.

Linda: Is that the type of location?

Mark: Since don't have entities and roles, I will have to think about that.

Linda: Can I send you the spreadsheet?

Mark: Yes.

Linda: Thank you. So ... now Mindmaps.

[Mindmap Image for Location (Cluster)]

Linda: Any comments on this model? We have references to Address and Electronic Contact

Linda (cont'd): OK. The next one. Address is interesting. Tom - comments on which model I should have used? There was one which looked Brazilian and...

Tom: Was ISO 230222 standard... so there is nothing specific to Brazil... straight-forward.

Linda: Was one... census tract...

Tom: Must be minimal... Better job of annotations... That is what they are based on.

Linda: I looked at both - different styles.

Tom: The... provides a name for address... building name or... depend on where... if no address on house... Probably is a vocabulary that says... The openEHR is agnostic like HL7. One archetype... ISO model... that style. If you assume most will be strings... coded from... 1 of the address pieces... If street number, then must be street name... Can go a bit mad... Most develop down to 2-line address. Most give up on...

Linda: Last week, Rahil... 3 styles: Single description, structured address, and fully structured.

Rahil: Yes. First - unstructured, and then with address lines 1-5. And completely structured... By the way - HTML view of address - posted to Google docs... Like Tom said, can get crazy... very structured... So available to look at

Linda: And for CIMI being able to define mappings and transform from each of these different approaches, to the CIMI model at different levels of abstraction, is very important.

Rahil: ...Graham... tell people that there is a website... where you can get descriptions... These are requirements that have come from this product... You will find structured bits from there. Point you to data dictionary... descriptions... So look there.

Linda: Thank you, Rahil. So, looked at... Then NEHTA fixed address... I know what you just sent out, Rahil. Don't know if you want to check spreadsheet...

Rahil: OK.

Linda: Thank you. This fixed address indicator... in NEHTA model. The value... The way address is used. Address-type in openEHR... in IMH...

Linda (cont'd): Preference Indicator - whether this address is preferred. IMH... The status of address - from IMH. The type of address... Galen - on line? [no answer]

Linda (cont'd): I know there were... Was that Mike?

Mike: I don't think [Galen] is on the call.

[Linda pulls up Data Type from FHIM]

Linda: So the address type - has examples on both. Interesting - combines the use and address type. Combines the telecommunications and the address into 1 type. Telecom has 1 type, and address has 1 type, but not sure if...

Mark: I'll have to look that up. Where is this from?

Linda: From the FHIM.

Mike: Galen would know.

Mark: This is not diagram on RIM.

Linda: I said FHIM.

Mark: There is a generic... and Telecom is type of address, I believe.

Jay: These are accurate. Many of these ... are overlapped. These are about to be reviewed.

Linda: I was thinking to map to Use since FHIM was the only ... to use this type...

Linda (cont'd): Next was Representation. IMH... [Linda shows IMH model] Having looked at CDL... The value set of this coded attribute... ABC for... SYC for... and IDE for Ideographic. Different than those for home use... Joey? Stan?

Stan: Yes?

Linda: Question is understanding IMH address type more. Based on... ABC, SYL, IDE... Did not want to map to... I called representation...

Stan: Joey - Can you look at...?

Joey: Go to Test/Test - the New one. [www.clinicalelement/Test ?]

Joey: Just 1 test.

Linda: [Reads] "Alphabetic, Ideographic, Syllabic, Phoenetic, Soundex"... Not seen this before. Interesting.

Linda (cont'd): OK - date time range. IMH had start time, end time. FHIR had period and FHIM had... Also - can improve on description.

Linda( cont'd): OK... specificity... need to... specialization. Compared to generalized... Address part came from FHIR. Address line - used in nearly all. In openEHR...FHIR... NEHTA... v3/ISO 21090... and FHIM...

Linda (cont'd): Address Line number - included because sequencing in some. Possible to address... or can have line#... either approach. Delivery address line - a special type of address line. One thing - challenging - to show different levels of specialization and how to relate. The difference of... composition... street address line... additional locater... site name used in... unit number... unit type... Post Box number used in IMH and...

Linda (cont'd): Floor/level number... Floor/level type. Lot number. Street name. Street type. Street directions. Street value. So we have a case where, for street, includes all of... and street suffix... Street number - used in street... Broken down into street number - numeric and suffix. Intersection description... visualization... census area. Delivery point identifier. Delivery number. Delivery installation type. Delivery installation area. Delivery mode, Delivery mode identifier. Postal code. District - in openEHR model. County code.... in FHIM... Suburb/town/locality...

[Linda looks up ISO/?FDIS 21090]

Linda (cont'd): City is in FHIR and... State/territory/province is in... Country is in all of them. Case of... the name of party and who will take... Delimiter. Address start date accuracy indicator... Address end date accuracy indicator...

[Linda] Tom - Do you know anything about these?

Tom: I can look up.

Linda: If part of ISO standard, may want to include since in not local. Are all OK with this? If part of ISO - include?

Stan: Yes - fine.

Linda: Mindmap. Important to map to and from CIMI. Model at different levels of detail. Both the very general models, which just have address parts, and address lines - But also allow the specific models to map as well. Started by defining the specific models, but let's first look at the generic address...

[Linda show Mindmap of Address (Cluster)]

Linda: We have status... use... In address part we have... And in Address line we have...

[Linda]: When we want to specialize these attributes, we can say address line 1 has street# followed by street name, as per the generic address line. This allows us to model both the generic and the specific. Does that seem reasonable?

Stan: I am trying to think through - comes back to ISO-semantics. Think of simple Line 1,2,3... name parts... [I am] talking aloud here. You should be able to make ISO-semantic representation of either way. I would be more inclined to include one way in one model and other way in other model... not figured out what way you went with that.

Linda: I only showed you 1 piece of puzzle. Each address line should be constrained... So if you think of... B3 mapped into... Could define a more... model. Address details... specialized address-part with Address-part-type - specialized... Similarly - could... address line with address line 1 or 2... continue to use the more generic version... The generic address line... allow... more specific... and could extend.

Tom: Our use of these archetypes - only doing 1 thing. Our thing... to standardize. Technically is a bunch of constraints. Reality - only 3 fields that matter... Postal code .. so I don't know that I would get terribly worried about most of those. I don't know if I've seen full deployment in any I've seen. My point is - the complexity of address, for 5 things that matter, Post code, Country, Street, Street Number... Now I don't know of anywhere that contains all of those. May not be the most important.

Linda: I am happy to limit address-type, but we have been taking the max approach. In Singapore, the demographic service has address in this form... followed by area, city, country, and they have very specific address-part types in their implementations. But when standardized, we wanted to use more generic... In order to map between these, we need to understand the relationship between the abstract and the specific... In Singapore, we found it more useful for mapping to specific implementations if we made the model more concrete...

Tom: Maybe the right thing to do... only have to do once.

Stan: I was interested in people's experiences. This goes with name and addresses. We found name... elegant... address part and value. But implementation - address 1 and 2... city, state, zip. Singapore - do they show these things? In U.S., an official address registry... computable. But all they see is large aggregate parts. Only the address line system that matter and some other parts, like country and zip code.

Linda: Singapore has address line 1, 2 etc But - systems also break down into specific parts. Seems to be more efficient for interoperability... we had to go to a more generic for standardization between implementations...

Rahil: In UK - address - used across different organizations. We have the GDSC [Government Data Standard Committee?] standardize the... address... A structured address... to be used by NHS, the Royal... Police. Because is national and funded by the government, they all share. Where structured address-type comes into play... is cross-sector requirement.

Mark: This is one of those areas with... realm. May want basic model to be... for Singapore use and... use and... use... because the requirements are different in different countries.

Rahil: Yes - so if CIMI has ability to have structured, then... We need at least the base in there. If you look at a lot of NHS systems out there...

Linda: This model demonstrates as generic as can be... specific country use... as Mark says.

Linda (cont'd): End of meeting time. I'll send out the spreadsheet - revised. And Mindmaps. Please give any comments you have.

Stan: I am in awe of your ability to take all of these inputs and rationalize them. I could not do this.

Linda: Thank you. Please provide feedback.