CIMI MTF Minutes 20130207

Jump to: navigation, search

CIMI Modelling Taskforce -Meeting Minutes

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


Linda Bird

Stan Huff

Patrick Langford

Mike Lincoln

Michael Van der Zel

Rahil Qamar Siddiqui

Jay Lyle

Joey Coyle

Sarah Ryan

Gerard Freriks

Cecil Lynch

Eithne Keelaghan

Agenda & Brief Minutes

  • Weekly News & Updates
  • Feedback:
    • CIMI Modeling Style Guide Table of Contents
    • Comparative Analysis Spreadsheet template (with introduction and example)
    • Demographics Comparative Analysis spreadsheet - Location, Address
    • Mindmaps - Location, Address
  • CIMI Reference Model Review (if Michael is ready)
  • Review of Demographics Comparative Analysis spreadsheet & models
    • Address
    • Electronic Contact

Summary of Detailed Minutes

  • Planning for future meetings
    • Agree on February 28th for discussion about: demographic model, simplification, data type questions
    • Next 2 weeks - Feb 14th and 21st - plan to discuss models, including immunization, if time permits
    • Linda and Michael to discuss ROLE-ENTITY examples with Dipak and Graham
    • Need to plan for date to have Transformation Demos with William and possibly others demonstrating their transformation and tools
    • Gerard will contact people he knows who can demonstrate their transformations
    • Need to plan for review of AOM with a broader group of CIMI members. Will ask Dave for input on this, and he can discuss with Tom and Michael
  • Discussion about Guide Documents: Style Guide, Terminology Binding Guide, Editorial Guide
    • CIMI Modeling Style Guide Table of Contents - put on Google docs
    • Linda asked for volunteers to help write up Guides
    • Stan will talk to Tom Oniki about doing comparison
  • Comparison Analysis spreadsheet sent out last week
    • Contains explanation about how to populate the spreadsheet
    • Need suggestions about Immunization Models
    • Mark to provide review of demographics model mappings to HL7
  • Discussion on Binding
  • Discussion on Demographics modeling
    • Discussion about Generic level and Specialization - use of Tool
    • Address - Review abstract model
    • Gerard to follow-up on Addr-start-date-accuracy and Addr-end-date-accuracy indicators
  • Electronic Contact
    • Question for Michael: Should URI be a child of text? Tentatively changed, but Pending.
    • Question for Galen - address-type used for both address-type and telecommunications
  • Tuesday terminology meeting with Harold - Tooling
  • Next Thursday's meeting - continue with Demographic model
  • April meeting will be in UK - either Oxford or Leeds
    • Also gathering during meeting in US - probably Bethesda

Detailed Minutes

Planning for future meetings

Stan: I will host LOINC meeting next Thursday - not available.

Linda: Following week?

Stan: For 1 hour. Meeting in Washington.

Linda: Should we start next week and summarize in one hour on the following week?

Stan: So, I want to make sure I understand. What is the agenda?

Linda: Recommended changes to demographic model and conversations about simplifying even further.

Michael: And data type questions.

Stan: You had some things we didn't present. Concrete proposals. I hate to delay, but hate to miss discussion.

Linda: We could start... the first hour in week after next?

Stan: Let me check - Yes I have a conflict. And then Feb 21st - a meeting in DC.

Linda: Well - we do have enough work for the next week. But I think one hour won't be enough. Can we start, or Feb 21st, you will join for first hour, and then finish off on 28th?

Stan: Yes - I am good on 28th. Probably not able to make the first hour [of the 21st], since I will be getting into DC.

Michael: I am not available on 21st - a holiday.

Linda: [How about on] the 28th?

Michael: Yes.

Linda: Let's push back to the 28th. And Michael - we can do some preparation.

Stan: That will work for me.

Linda: Is it OK with everyone else? Anyone it is inconvenient for?

[no response].

Linda: Great. In next 2 weeks, we'll go through models and maybe Immunization. And Michael - we have to follow-up with Dipak and Graham on the ROLE-ENTITY examples.

Michael: Yes.

Linda: Yes -This gives us 3 weeks to tie up the reference model examples and recommendations

Michael: Minus 1 week for [my] holidays...

[Linda continues to read through Agenda]

Linda: In the future - transformation demos. William to show transform into... CDA... Hopefully, in future, can get people to demo... OK with everyone? Other suggestions with tools or methods? Michael's Tools.

Michael: Yes...

Linda: NEHTA method. Transform to CDA. Anyone else done transforms to other models?

Gerard: I have not personally, but in community, there are people to do transformations to CDA on an instance level and from 1 archetype to another based on Reference Model.

Linda: Anyone we could invite?

Gerard: Yes - a guy from University of Murcia in Spain. I will Skype him. And people from Valencia and Vienna.

Linda: Will you be able to follow-up on that?

Gerard: I will ask them.

Linda: Thank you. Anyone else? [no answer]

Linda: Another - a Review of Archetype Object Model (AOM). And we were talking about choosing a subset of the AOM to provide an easier benchmark for tool and support to get to. Also - spreadsheet template of that so all understand constraints. Any suggestions on how to do this, or should we ask Dave?

Michael: Dave will have opinion, because we wrote down requirements in AOM paper.

Linda: OK - need Dave in discussion. Hopefully, it would be good to have discussion with broader group after Dave, Michael and Tom discuss. OK? So those are what we will plan over next few months.

[Linda continues with Agenda]

Discussion about Guide Documents: Style Guide, Terminology Binding Guide, Editorial Guide

Linda: CIMI Modeling Style Guide Table of Contents. I put this on Google docs. If people have trouble getting on, please let me know. We have document templates for Terminology Binding Guide. The CIMI Technical Guide, the CIMI User Guide, the CIMI Editorial Guide and the CIMI Terminology Binding Guide agenda?} Guide. Any comments?

Stan: I though they looked good. When add content, we may find we need to add other information, but now it looks complete.

Linda: Gives us 1 or 2 months to start looking through these. It would be great to have volunteers to do write up. Any comment on what we should start with? AOM - first want review. Technical Guide, User Guide should include the methodology, the Editorial Guide will include the patterns and modeling principles - Terminology Binding Guide and Editorial Guide - are these good places to start?

Stan: I think yes. My greatest interest is in the Style Guide.

Linda: Have you had the chance to talk to Tom Oniki about when would be an appropriate time for us to get a copy of the Intermountain Style Guide?

Stan: I forgot, but I know he is still interested.

Linda: Could you ask so we can schedule to do comparison?

Stan: Yes.

Linda: OK - that is the Style Guide.

Comparison Analysis spreadsheet sent out last week

Linda (cont'd): The comparative analysis spreadsheet was distributed with long email from last week. The version distributed previously only had the comparison pages, which Anneke helped with. Now I've added the cover sheet and an example sheet - to try and explain how to populate the spreadsheet. I know Dennis wanted a video, but that will be next. If everyone gets a chance this week, please take a look at this on Google Docs to see if enough information. We will use in a couple of weeks with immunization. I have populated the example with the laboratory results model. Please click on the plus sign on left-hand-side to open-up each group. We will need to decide how to structure the immunization models. There were a number of separate models as part of the immunization record, including medication administration and adverse reactions. Any suggestions for this? Please provide over next weeks. Also Demographics - Mark and someone else - I need to ask Eithne who it was who volunteered.

[I missed a little here]

Discussion on Binding

Cecil: I am trying to understand where in V3 model - need to decide which are binding to, because binding is different depending on message type.

Linda: The binding shows the value sets and semantic meaning of each node of the model.

Cecil: Still not clear. Is it the binding to SNOMED?

Stan: Let me take a second. We started off with a Value Set binding and this is my take. Three things want to bind. One is - if take given element... So if have Hematocrit, we are binding to concept of meaning - SNOMED or... Second: So like binding to a device that is a qualifier of where Heart Rate made, would bind an attribute to a LOINC code... or would bind to SNOMED relationship between the nodes - So know how to compose and decompose. Third is value of the attribute. The primary source is SNOMED. So - first is attribute. Second is concept itself - SNOMED or LOINC. And third is the binding to Value Set - collection of exact codes. Probably one more thing - like a domain name. To say substance or bodily location... I want to talk about. People think important... This is different from IMH.

Cecil: Yes - if talking about terminology, and not model. I was confused - HL7 demographics - want to talk about how concepts map to SNOMED. So we don't care whether HL7 model binding or CIMI model binding or...

Stan: I was with you till the end there. We have more than one thing going on. If working with CIMI models - that's one thing. But how to move from CIMI model to IMH in CDL, etc.

Cecil: OK - I understand.

Linda: So we look at HL7 twice. First to make sure we are covering all the data elements. We then bind the CIMI models to SNOMED and then need to define transformation from CIMI model back to HL7.

Discussion on Demographics modeling

Gerard: Demographics to me, not the same as... Also, to identify patients, humans or things. I think I sent you Mindmap of how we think about demographics - based on ISO standard. And why not use the ISO standard to deal with this. The number 22220 - why not use that structure standard?

Linda: We have used as one of inputs... Is in person or healthcare consumer.

Gerard: The Mindmap you sent around - you are diverging from that standard.

Stan: That is why [we are] doing [this] analysis. The reason is - if we find other data elements that are missing, we will add it.

Gerard: That's fine... Consensus in group I was not attending. Maybe I misinterpreted Mindmap.

Linda: I surely got feedback from all... we went through source model... Rahil?

Rahil: Yes.

Linda: Rahil gave us a mapping from ISO22220, which we incorporated into comparison. I am sorry Gerard - I have not been able to incorporate what you sent me into Mindmap. So this will be one of source models.

Gerard: Yes - you must stay pragmatic, but why not make use of what is properly defined already?

Linda: Thanks, Gerard. That is a piece of work that will cause revision to location and address... Address we looked at last week - first layer - Line 1,2,3 etc... and generic... and constraints on top of that with detailed address... and extend, and address lines 3 & 4, and probably extend to 5. So with each - the line# has a constraint. With address, Line 1 must be 1... justify a line with a line#.

Stan: So, I need an example. Don't know what means in terms of instance data. Would information be in there twice or just constrained part?

Linda: The instance - look like the reference model in both cases. But when you query over this data, this address line 1 can be refined to address line with line# = 1, or address line 1. And those become synonymous when you query. If you do as a Use Case specific, then you can use the more abstract model to define instances, and both will say address line. Bu the more detailed model will have additional constraints, but will look the same.

Cecil: So - why not address line and 0-1 or 0-2 instead of address line 1 or address line 2?

Linda: Provides for generic - address line and you say line#. But last week we talked about having both the more abstract address model and the more specific. So can map to more generic or specific. So rather than choosing one or the other, allows source models to be mapped to whichever is more appropriate.

Stan: I agree, but the way I think of isosemantic is not to put both in the model, and map between both.

Linda: I see this as the same as using the generic laboratory results model and then adding constraints to specialize this into the more specific types of lab results. Because there are just constraints between more general model.

Stan: So this is abstract?

Linda: Yes - but some may implement at abstract level. IMH may not, but...

Stan: I may not be understanding. Recognize that have multiple representations. But idea was to choose one rather than leave open... because someone receiving information knows the logical structure... then map.

Linda: This is just what the AOM does... and allows you to query over all of the levels. I thought we weren't making a choice... I thought we were allowing for abstract vs specific constraints. Because there are many levels and we want to be able to query over all of them. So the more specific address line... you can query on address line, it knows that it is address line with a line number of 2, for example.

Stan: I have to think through it. Everything you say is true. It is transformable between the models. If implement at generic level and not specific, would you know how to query? If generic model, you don't know model to use. Only have concept code. Different from 'get me Hematocrit models'. And that implies the other parts... [I am] trying to think through. I may be muddling up what we want to say in interoperability. May be logical model and the implementation model... If going to say - send data to an app in a standardized way, you will want to specify in that context, and exact format to use a standard API.

Linda: Yes - I thought that was what you were thinking. I was assuming the instance would look the same. Depends on how present to API.

Gerard: It is complex. I tried to translate. On one hand you have a very abstract model - generic - subject-of-care. On the other hand, specializations. I think at the generic level, the specializations are a function of the archetype model. I think it not wise to copy the functionality of archetype model.

Stan: Our scope of work is to do both things... if we want interoperability... To the extent make functionality for interoperability, have to agree on specializations as well.

Gerard: A separate step. Defining specializations - we can do as a community.

Stan: We made specializations - CBC and... We did both... We made generic model and then specialization.

Gerard: We have to do, but specializations can be for local requirements.

Stan: Yes - but those mechanisms - can use and represent in Mindmap and model as we are doing.

Linda: The CIMI Reference Model is there to make sure the instance looks the same.

Gerard: But is the specialization in the archetype model. Don't have to think about now. Can create any specialization... identifiable way.

Linda: So - you are suggesting, Gerard, that we stop at abstract?

Gerard: Yes.

Linda: Stan - your thoughts?

Stan: That is where first level ends... We can call Step 1 and Step 2. But job not done till make specialization for interoperability. We have been mixing the two, Gerard... often in same meeting. I guess is a question of... may be useful to agree. First generic level, and then approve specialization.

Gerard: To create specialization, use Archetype model and Tool.

Stan: We agree - want to use tool. Which tool is what we have been talking about at Tuesday meeting.

Gerard: I am using an ADL 1.4 tool... I can create any specialization. That is the difference between CIMI at this moment and me.

Linda: You are referring to LinkEHR

Gerard: Yes.

Linda: So - Stan -do you want to go through address abstract model, or move on to the other models?

Stan: Can we step through again?

Linda: So all this came through analysis of some models. So address space... preferred levels... We had a Y/N Boolean for "No fixed address individual". We had a plain-text description. The status of the address. The use of the address. The Preferred-indicator - is a coded-text but I notice that the 'No fixed address indicator' is Boolean. We want to avoid Boolean, so we should change the 'No fixed address indicator' to a CodedText. OK?

Gerard: Yes.

Stan: Yes - we should be using coded values.

Linda: The type of address - need to go back to comparative analysis to see. Type was from FHIM - was the same as Use. We deleted from spreadsheet, but not model yet. OK - Representation - from IMH model - alphabetic or syllabic or geographic.

Stan: I think we should eliminate. I don't think we have used [these], so should not include.

Linda: OK - IMH only, so reason for exclusion is Not in Use.

Stan: OK - may come back sometime, but will know then how and why used.

Linda: OK. So, Date-time-range - has it as 0...1. I was going to suggest 0 to *. Is that a Use case we want to consider?

Stan: I think not. I think of this as current, pertinent range, not list of future... that is why have 1.

Linda: Yes.

Gerard: Also - indicator for... of time.

Linda: We had that... just finish off these first. OK - address part...

Gerard: ...and there you can have various address-type, and one is no-fixed address or unknown. Derived from HL7 v 2.?

Stan: Sounds like a different Use-case. Here this is not in same axis as home or address types. It is saying - this is a free-text object as opposed to coded object.

Gerard: OK.

Linda: ...including the use... which is what other source models are doing. So - address part... part number... Should we rename this? Thoughts? I named that after doing line#.

Gerard: Rank?

Linda: Part-rank? Maybe not matter that is consistent with line#.

Stan: I would rather not make names as a committee. One name intuitive to one person and not another. I would name as in one of the models... We could do by email.

Rahil: Tuesday meeting - get rid of problem about label to use.

Linda: Yes - we had the same discussion. It became apparent that we needed descriptions for each... So address part has 0 to 1 Part#, 0 to 1 Value, 0 to 1 Type and details. OK?

Linda (cont'd): Address Line - Don't want to restrict to 5 because not know what is out there. Value of Add - part is text. Value of address - line is the unstructured address line. Is that reasonable?

Rahil: I think I would like to check. I think there was a bit of structure to Line 1 and 2.

Linda: The value just gives you the unstructured, but the address can be structured using the address parts within the line.

Rahil: Address line is the unstructured address...

Linda: You have completely unstructured all in a single string. You have address-line value... and you have unstructured address lines, which can be ordered appropriately. And you have the fully structured address lines, where each part within the address line is recorded. When you were talking about a structured address, I thought you were saying that each address line can have parts.

Rahil: I am not sure. Address where not use lines at all. Ordered as building identifiers... So that is address part?

Linda: Yes. Address parts can be defined, which are not part of an address line, or Address part can be defined within a given address line. Source models covered these variations.

Rahil: You - so far have Address part and then Address lines with structure?

Linda: Can have free text - outside line or inside line and order. Can all see?

Linda (cont'd): OK - There is the Line# value. However, sometimes they call it a 'Street Line', rather than using a Line#. So, they gave it a Line Type. And we need extensibility to add other address lines. I know there are other attributes that Gerard talked about - other?

Linda (cont'd): OK - Last week we decided to exclude these attributes until we had a Use case. Gerard? Address-start-date-accuracy indicator. Address-end-date-accuracy indicator. These?

Gerard: Yes. I don't know what case is in latest version.

Linda: If you could follow up and check. Happy to add. Thank you Gerard.

Linda (cont'd): All OK with this approach - if in ISO standard, we will add?

Stan: Yes. The case for adding is strengthened if people have found it useful when implemented. More convincing if people have found useful.

Gerard: I agree.

Stan: One of our principles is - we will include anything that is useful. Want to cover what people do. Modelers as we are, we go off and add what we think might be useful. But [need] to temper this and leave out...

Gerard: I agree, but in specialization process, can put constraints on what you don't use.

Stan: I think if we include, will include as was originally. Not harder to add a new attribute. Anyway - you will do Homework?

Gerard: Yes.

Linda: Thank you.

Linda: We have a number of address-line types. There are all of the address-parts - grouped together. Separate address parts... unit number, unit type... Specialized - one was to define the address into address part - this model constrains down to what part is. And other constraints are added to addr-line. Probably most efficient to...

Stan: So, assumption by not putting delivery address... So in model, could say 'home delivery address'?

Linda: And perhaps should have street address line and delivery address line

Stan: No - I would not have done at line level. Instead of use line order and whether it's a delivery place or not.

Linda: That is address-line-type. Would be whether it is a street or delivery address line.

Stan: OK.

Linda: So - whether we constrain in specific model. Constraint on Address-base mode. We can rename this to 'Address'. An then include a whole bunch of specializations on address-part. The type of address-part has a bunch of... The value of address-part is street... Whole bunch of address part and lines... Addr-line 1 is constrained to have a value of 1. Are all happy to go through on your own?

Gerard: Yes.

Stan: Yes.

Linda: Any other comments on address before move on to electronic contact?

[no answer]

Electronic Contact

Linda: OK. Next is electronic contact. Simpler model. I looked at openEHR, IMH, ..., IS013606 has a telecom, ISO...2220? NEHTA for... and FHIM for telecommunications. Gerard - would yours...?

Gerard: Yes - 2222 will follow that. What you see in 13606 in data type... I will not be surprised if we find.... application of this ISO standard.

Linda: OK. Any other models we should have considered?

Rahil: Wondering if you had a chance to look at LRA in this list? I can't see it.

Linda: I think LRA using TEL, which is an ISO 21090 datatype.

Rahil: OK - so not explicitly here...

Linda: So the value... in openEHR - they refer to as... IMH - the telecom data. In FHIM is value. In EN13606 is telecom address. In 23230? Is... in 22220... in NEHTA... in FHIM... So first - are all OK? Second - some used URI's, some used... want to standardize?

Gerard: How think about new standard...? Not using specific data types at all.

Linda: So, few that refer to specific data type is... 13606 and openEHR. Should we standardize to text or... structured level?

Gerard: I think at CIMI level, text is enough.

Linda: OK - all OK? Text allows coding and most others, only plain values...

Stan: So - could specialize to URI?

Linda: Interesting. At the moment, URI is not a child of text. Could not turn into URI data type. Perhaps an issue... Is Michael still on line?

[no answer]

Linda: So - answer at the moment is No. Question is - should URI be a child of text?

Stan: Yes.

Gerard: Yes.

Linda: So I will raise this to Michael. That would make sense to me. So I will tentatively change, but is Pending. All OK?

[no answer]

Linda: Next is scheme. IMH has telecom scheme - the only one. Should we look at sample values?

Stan: Yes - could look at Mindmap values.

Linda: You remember?

Stan: Clinical

[Linda brings up on screen]

Linda: Doesn't seem to be a value set on scheme. I clicked on Telecom scheme. The CD does not have a Value set.

Joey: Try mousing over documentation-thing.

Linda: Good. Thanks Joey. [Linda reads Telecom Scheme] So it is the protocol. So if we rename to protocol, maybe people will understand. Are all happy for me to rename to protocol?

Gerard: Yes.

Stan: Yes.

Linda: Can I cut and paste, Joey?

Joey: Go into telecom Scheme... on LHS - see it?

Linda: Good. Are all OK with rename to protocol?

Gerard: I need to leave [meeting]. I will follow-up.

Linda: Status - IMH has telecom status... is nullified. We will have to go through.

Linda: Medium is... IMH uses Telecom-type... HL7 ISO 2...09 uses capability. This is interesting, and probably why IMH calls it telecom type and not medium. I would put emergency contact into Telecom Use.

Stan: That is what you sometimes get into. Is it a type or a Use or... So important - that it is not ambiguous... And you get into some question about... If follow more than 1 - have emergency... and emergency-home...

Linda: Would need it to be repeatable and you only have 0 to 1.

Stan: Can solve by making emergency-home... But I agree with you. Should probably. Preference, Joey?

Joey: No. Wanted to say - always see 5 values in value set. Not the complete set.

Linda: Can you see the complete set?

Joey: Yes. (Clint?) generates it. I hope it is true.

Linda: Sharp or not Sharp?

Joey: Sharp... but will download. In a few weeks... webmaster. Took a month-long vacation. Will be back.

Linda: Will test move to URL?

Joey: Test will move to URL.

Linda: So now - Medium and Use. And Based on values from FHIM, the address-type seemed to be shared between both Address and Electronic Contact. Looking at the values... Galen not on line. Mike - are you familiar with FHIM?

Mike Lincoln: Not as familiar as Galen, and not sure of answer to this question.

Linda: I remember a few strange things with address-type...

Mike: We can go to... [FHIM online]

Linda: I remember address-type sharing values with contact-type.

[Linda looks up FHIM]

Linda: Telecommunications - had address-type... sharing with Address. Some of the values may not be applicable to both Address and Electronic contact.

Mike: - can see same diagram Linda is looking at. I think is same, but need to ask Galen to be sure.

Linda: Yes - with address-type used for both address-type and telecommunications.

Mike: I need to go.

Linda: OK - thanks for joining. A couple more to go. Preferred timing - only openEHR. Might be multiple preferred times, but... Cardinality... all OK? Date-time-range - The start and/or end-time...

Linda: IMH has... FHIM has... all OK? With naming of this, the date-time-range is used across the models. So if I change, then want to change everywhere. Preference indicator. Is everyone happy with analysis? Need to change... and get conference from Galen on FHIM-mapping.

Linda (cont'd): So Mindmap... Scheme - rename to protocol. Status... Preferred-timing... Date-Time Range... Medium is 0 to * - maybe an error... Any comments, suggestions ont his Mindmap? Good...

Linda (cont'd): Given that we're postponing the CIMI Reference Model discussion for 3 weeks, and need to schedule... and review of AOM, are all OK with going on with reviewing these comparative analysis models in the next few weeks. OK with these as topics for next few weeks? Stan?

Stan: Yes.

Linda: Will Joey be available when you're not?

Stan: Yes - this is detailed work, but don't know of other ways to do it. In some ways, we think these are simple, but they have become more sophisticated as people use them.

Linda: I am hoping is a 1-time thing. Not like clinical models - having to build up content.

Tuesday terminology meeting with Harold - Tooling

Linda (cont'd): Any other comments? Just a plug for the Tuesday meeting. I believe Harold will be continuing the discussions on the Terminology tooling. So next Tuesday - a Tooling meeting,

Next Thursday's meeting - continue with Demographic model

Linda: Thursday - continue with Demographic model.

Sarah: I'll be there. And have you heard where the April meeting will be?

April meeting will be in UK - either Oxford or Leeds

Stan: In UK. Maybe Oxford, but most likely in Leeds. Also on East Coast location - probably at Kaiser in North Bethesda. The meeting at Baltimore HL7...

Linda: The first one?

Stan: So - that was Tyson's Corner. This was... That should be firmed up in a week. Oxford if less than 30 people. But if more, too many for Oxford.

Linda: For me, 9pm - 3-5pm - time zone.

Stan: I think start noon London time. And Linda - try to accommodate your schedule. Other discussion. When get to scheduling... will schedule you when you can be there.

[end of meeting]