CIMI MTF Minutes 20130418
- 1 CIMI Modelling Taskforce - Meeting Minutes
- 1.1 Attending
- 1.2 Agenda
- 1.3 Review of Leeds/Rockville meeting
- 1.4 Detailed Minutes
- 1.4.1 Requirements: Review of Leeds/Rockville meeting and next steps
- 1.4.2 Terminology Binding Model
- 1.4.3 Validators - for ADL AOM, UML AOM
- 1.4.4 Style Guidance and Patterns
- 1.4.5 Serious Version Control
- 1.4.6 Validator for Terminology
- 1.4.7 Repository, Governance rules, Model set exploration
- 1.4.8 Model Viewers
- 1.4.9 Agreements approved at Leeds
- 1.4.10 Changes made by Michael
- 1.4.11 Stan Leaves Meeting
- 1.4.12 Modeling Questions - Gerard
- 1.4.13 [end-of-meeting]
CIMI Modelling Taskforce - Meeting Minutes
Rahil Qamar Siddiqui
- Review of Leeds/Rockville meeting and next steps
- CIMI Reference Model DSTU (including LINKS)
- Modelling questions (Gerard)
- ISO11179 Discussions
- Implementing Terminology Bindings (continued)
Review of Leeds/Rockville meeting
- Next Steps
Linda: Agenda - Review of Leeds/Rockville meeting and next steps. Implementing Terminology Bindings, continued. CIMI Reference Model DSTU (including LINKS). Modeling questions - Gerard.
Harold: ISO 11179 - binds tightly to terminology binding. Easier to catch Stan later...
Linda: Stan only available the first hour. Finish... and then move on.
Harold: Move ISO 11179 down on the agenda...
Stan: I'll catch up with you.
Linda: All OK? Stan sent me 3 files... Reference Model from Michael - he is not on the call today. Reference Model topics to talk about... also on Tuesday. Second document - new work to support implementation.
Requirements: Review of Leeds/Rockville meeting and next steps
Stan: I thought what is the most important is 'Requirements' which Harold edited. What we thought was the pathway... getting content into visible repository first... was tasks related to things to be done to reference model... to make the current version plus 2 changes. And this one was "what are the things on the pathway to get content into repository". And the other... governance... all things that don't fall into primary pathway and discussion. Should I step through these requirements?
Stan: May not have been clear to all, but our strategy till a few weeks ago was looking at requirements to term editors and model authoring, thinking to approve CIMI tools. But the more we looked at this, we thought... let people use whatever they want. ADL 1.5 model that is using CIMI reference model that is using CIMI binding... that is bound to concepts we create... So people would produce models and we would have repository... and model in ADL 1.5... Would show with validator that it confers to... initially in proposed status... have opportunity to review... manage in repository.
Stan (cont'd): So - we went from a single tool to letting all use the tool they prefer. I don't know if we said this explicitly in the meeting, but that is where we got to. Any comments?
Gerard: I can argue with this, but not solve the problem of tools capable of building CIMI artifact.
Stan: I don't understand - not solve problem of one tool, but... says CIMI needs gold standard validator. Because have two syntax... need validator in ADL 1.5 and in AML - the UML profile that folks are working on.
Gerard: How many tools... that can produce CIMI artifacts?
Stan: At IMH - from local to ADL 1.5 - a model conversion device. Output to put into repository for initial review. May not be perfect, but can get you close enough to model to hand-modify. Puts new burdens on people to get from what they like to what we need in repository.
Gerard: Need to be transparent. In 13606... are thinking of... we will do with validators...
Tom: I was probably half asleep when we built this list - a good list ... the identification of artifacts. There are rules that exist in ADL or ADL 1.4 but improved in 1.5. We had a draft to put out - on versioning archetypes... without rules, it is chaos.
Harold: That had been the intent - under "serious version control... unique identifier".
Tom: I thought that was not losing things... Does not say about identifiers... only gets you 209...
Stan: I think the item on the list is what you meant. I think we all agree that this is what we need.
Tom: We will publish a draft soon. ...was put together over last few years. Has amalgamated what didn't work... experience with people using tools with any archetypes... most of it applies to CIMI.
Stan: I agree. Going down the list... Assume have to have a solidified Reference Model. We approved a couple of changes. Current version of model with changes becomes draft standard - a starting point for people to tool with... add as needed. We need a good enough canonized version to work with. That is Michael with help from others.
Terminology Binding Model
Stan: Then - issues with Term Binding Model. We worked with this on Tuesday. To come up with the UML model that will be incorporated into AOM or the MDHT - the structure we use for bindings.
Validators - for ADL AOM, UML AOM
Stan: We then need a validator... a CIMI-approved validator. Thomas will help us there. And then we need... given our agreement for AML syntax, we need AML/UML... could be an MDHT-thing, or Ron Chen (?) mentioned that Cambio (?) has a (?)Java compiler that could be moved...
Tom: It is an openEHR Java compiler that Cambio has.
Style Guidance and Patterns
Stan: OK - and then the Style Guide. Have for Lab Models... but need to say what styling models are... for Body Temperature.
Linda: Still quite a lot of work needs to go into the Style Guide. Rahil and Daniel to help...
Rahil: Yes - next week...
Stan: And William put his name on this item... very fundamental things he could glean from the (?) standard...
Serious Version Control
Stan: Next - serious version control. How do we know one model is related to another... and how do we know versions are related? Looking forward to Thomas' paper...
Validator for Terminology
Stan (cont'd): And validator for terminology. At least two levels: (1) Value set concept exists in terminology server. (2) Validate that child value set is a subset of the parent value set. So two levels of validation...
Repository, Governance rules, Model set exploration
Stan (cont'd): Next - need a place to put models. Now headed down a path where Portavita will provide a repository for distribution.
Stan (cont'd): Next - need for Governance Rules for determining preference model. Need a rule that says, for interoperability, we will choose one model. Need to say what our rules are... to say what will our standard be. Some said... who is using the most models - let it be more laissez-faire to choose model.
Stan (cont'd): Next - need some way for people to find model and view it. Going to say, for visual representation, we would agree to style in HTML - consistent whether ADL or AML or OWL or other representation. We would settle that and do Mindmap so people could see two different models and see in Mindmap or other standard representation.
Linda: Any more update from Leeds?
Agreements approved at Leeds
Stan: We approved the agreement between CIMI and HITSDO... between use of SNOMED in CIMI models. We also said - recommendation - to accept offer from VA to set up IHTSDO to use that as official CIMI repository for terminology. Those are two important milestones in progress.
Linda: Some discussion over finding out if can host SnowOwl... or only one official CIMI repository?
Harold: As for the repository, models in... one official and a bunch of authoring... I would still like to consider a bunch of tools running off single repository. Don't want to only have access via workbench. I would like to figure out a way to pull information and exchange information...
Linda: OK with all.
Tom: I think it is good.
Linda: Next item is CIMI reference model. Gerard had questions and a presentation.
Changes made by Michael
Linda (cont'd): Also - changes - Michael... Making [some changes - can't hear the changes Michael is making]
Harold: He wrote the changes on the back of an envelope. That was one. And another was...
Tom: I can explain - that name(?) being optional. Is logically optional in openEHR... but not technically optional. Can be empty. The name field in locatable only gets set if want display name to be different from name to be derived from archetype... So - the normal expectation is that most of the time it provides the value you want. So logical way to see it is an override... There is a rule in openEHR - if have a node in an archetype, common that have one node but can give rise to (?). The openEHR rule is that each of those data uses - need to construct a path to it. The way to do this is set the name field. Simpler way is not to have that expectation. So have unique run-time path in (?). If expectation is that query can return multiple things, then don't need unique name rule. If design rule in CIMI... then need uniqueness rule...
Linda: So every locatable needs a name, but can be in archetype itself.
Tom: Yes... can construct... So logically, name field can be optional... We left it mandatory, but can be optional in openEHR.
Mark: If I have a blood pressure that appears in a number of different models, and I want to put together from different patients, I need a LOINC code to identify blood pressure wherever I find it rather than path in archetype - so do we need different paths...?
Tom: No - as long as... path always the same.
Mark: But what if the Use-case only records systolic? Do I have to use blood pressure archetype and leave off the diastolic?
Tom: Yes - done all the time... may not have diastolic...
Linda: Also have the meaning for the code.
Mark: I want to be clear. Sometimes comes from lab and contains a number of tests that are always these or not... Want to be sure I can find pieces without having to give (?) battery (?) name.
Tom: Can see by going to path... Each is addressable and most points are made optional.
Mark: As long as that is always find-able, I don't...
Stan: I think we all have the same use-case and works OK.
Gerard: ...modeling CIMI artifacts?
Linda: As long as find human readable name. In example instances... have name... more useful to always include node name for clarity. The rendering could take instance and add in.
Tom: I would call it a rendering issue... I probably see it as a syntax issue, although want to make instances human readable.
Tom: Previous 99 steps - have to read and debug.
Linda: Yes - wouldn't want only at-codes.
Tom: Don't want to have to set name-fields in archetypes unless have to. Have to think about...
Linda: Our intention is to make reference model a logical model.
Tom: That is stored, whereas usually pull the name by computation and... on screen. As long as design decisions is documented and everyone understands... Don't know how good is documentation.
Linda: Have to work on...
Tom: Documentation in EA.
Linda: ...would be optional in implementation.
Stan: Fine with me.
Linda: In logical model - required.
Tom: Mainly should almost never be set-able in archetype. Should be done at run-time... I'll check.
Harold: Would it be worth tacking on a derived (?)?
Tom: Only do that if derived 100% of the time. But we are saying - could be manually set sometimes. Done in openEHR... Maybe that is the thing to do... Primary raison d'etre is to support archetyping rather than what will happen in runtime system...
Linda: I do think purpose is to supply logical for supporting archetypes rather than runtime... may not be (?) at runtime. Logical to physical transformation...
Linda (cont'd): Also, Michael said value of ordinal... from... (?).
Tom: Yes - that is it.
Linda: The other two changes that Michael told me about... (?)
Tom: Also Link.
Gerard: I talked about Links - not the one here, but implied in the Links. Looking at an archetype - how deal with the outside world... The semantic Link. I know people in 13606 - want to change it and make it more rich... I also said... we must think where this functionality will reside.
Stan Leaves Meeting
Stan: I am leaving. Good luck.
Gerard: So in 13606 reference model, the linkage is there, but people want to extend. One thing - want to have qualifiers.
Linda: Semantic Links?
Gerard: Links two parts in electronic patient record... you point at and have semantic allocation (?).
Linda: Point from one part of record to another?
Linda: Good point to raise. Other... different models record about participation. For example, LRA participation attributes... participation feature.
Gerard: Requirements of some... Could add to Link... participation as well...
Linda: Suppose added any additional details that are required? OpenEHR uses type... other qualifiers... So allow them to be extended. Comments on that?
Tom: I thought we should stick to idea that need real use-case. Are you sure it is needed?
Linda: Example, Gerard?
Gerard: Not a real-life example, but anything in archetype can be qualified, and you hit that need. Now you don't have those qualifiers.
Tom: [can't hear]
Linda: Types seemed to be derivable from meaning?
Tom: I don't think it is... A term that tells you what type of thread... Intervention... can create chains of links through data. But models in openEHR - not good for that... Talking about chains of data... I don't know, maybe Gerard is right. Put a place-holder.
Linda: More to add, Gerard?
Linda: Great to discuss use-cases.
Tom: The thing I think is wrong - the target is locatable. In 13606...
Daniel: 13606... to and from record components - the target...
Linda: The same as locatable.
Tom: Oh - programming... Guaranteed not to work.
Linda: This is a logical representation.
Tom: We could say that, but target of link cannot be in same space as thing (?)obtaining(?) the link...
Gerard: Reference to?
Daniel: Diagram... At end of association line... try page...
Linda: Found diagram.
Tom: That URL - the way to make sure (?) is stored in (?) That is correct. That UML syntax not used often. See box with (?)? Has specific meaning in UML.
Linda: Anyone know EA well enough to know if it provides that? I've not seen this...
[missed some of discussion]
Tom: Personally, I don't like that notation, but it is official...
Rahil: In LRA, we use the 13606 logic of the target representation differently. Datatype... it is mandatory and has description of... and is target of the Link. So that rotation is probably the thing that was done... for LRA - so the data-type is the (?), not the class itself.
Linda: I think we all agreed with intent... putting target in Link. But - what is most appropriate?
Tom: I would do what Rahil said. URI.
Harold: We made it derived... the target is derived from URI... accomplished by de-referencing the URI.
Tom: Would be good. The thing you want to achieve... constraints on Link targets... easy to do. Different way to do, but you do want to do it.
Linda: Multiple ways of implementing. But at logical level... indicating class in another class... The same thing for party. Linda in source locatable and... But party - not expect it to be in party...
Rahil: If look at association... Locatable in locatable... association as target. Reference point?
Tom: The UML... not representing what you said, Linda.
Linda: So difference between composition and non-composition relationship?
Tom: Difference is in the (?) of lifetime semantics. But not in how the referencing is done.... done by magic... hidden by pointer... can't see unless using C++... Have to do what Harold said and add...
Tom (cont'd): Probably important. To achieve the idea that want the reference to be an explicit reference... you need to put a specific property in the source and class. For example... link.ref... (?). And could put something in participation. And what kind of id is in there... And with Harold's advice... a completed link computed by reference... stored in...
Linda: I would like to avoid making implementation choice in this model.
Tom: Not an implementation choice... but it can be. But here, talking about interoperable data and what is in data... does have consequences if expect to find UID... will go down tree of things, depending on how the model is.
Linda: So - if I can document your recommendation... I think, like what Rahil said...
Tom: Yes - Rahil and then Harold.
Rahil: I have copied into... can use as starting point.
Tom: Maybe take offline. Work out on email.
Gerard: I will ask (Dave?) as well.
Rahil: The one question - is general - all the changes to reference model now is post approval on 1.0.12 as DSDO. Is that what is happening? Another...
Rahil: Another version?
Tom: Get under version control. A case of designating which versions we think is good for software people to use.
Rahil: But not achieved that yet?
Linda: Also - need Michael involved. I agree, Rahil, need to clarify.
Rahil: The version that was accepted in ISDO (?) was pushed out to our organization. Is uncomfortable.
Linda: [can't hear]
Rahil: I think this target one is important.
Linda: Need to make the same change with Party. Need constraint - target of URI needs to be a...
Tom: Thought that party was inheriting from Locatable.
Linda: Yes - you are right. OK - I will forward to Michael. Want to mention that I won't be around for 3 Â½ weeks - traveling on holiday and limited access to emails. Hoping this continues in my absence. Harold will be chairing with Stan's support, and helping when I return.
Harold: Chairing from... that meeting happens and notes are taken.
Linda: Thank you. Apologize that I won't be at them.
Gerard: You will publish updated models to CIMI web site?
Linda: I will let Michael know prior to leaving. Perhaps Harold can help.
Harold: Yes - need to talk whether anything is backwards compatible.
Linda: Yes. I just made changes we made the 2nd day.
Gerard: I will send off to people and ask for participation in email discussions.
Linda: If you will take the ball, Harold, for this... I will send... EA stuff... and cut and paste. I will list those things discussed... locatable... Gerard - other questions?
Modeling Questions - Gerard
[slide-2 - Points for discussion]
[slide-3 - Links, Modeling styles, Modeling focus]
Gerard: In CEM, would like to expose you to discussions. This is a list of things... We discussed Links... modeling Style and Modeling focus. I think several of the problems we discussed last Tuesday have to do with Links.
Stan's List of Requirements [Slide-4] - Problems encountered
[slide-5 - SNOMED and Structure]
Gerard: SNOMED - do we follow the ontology of SNOMED or let SNOMED follow our ontology? There are many more degrees of... If we follow the path we were following, we will see the limits of SNOMED sooner than later. The second part of the slide - modeling style.
[slide-6 Archetype Template, Types of data/information]
Gerard: Links - has to do with... the world of archetypes and... When we model archetypes, have worlds we want to reach outside, and link is only one of the things... And coding systems... Libraries... server... catalogues... and want to reach in the archetype interface - ontologies - and a place to store rules and point to rules. Static behavior = point to a (?) and leave it. You see that in reference sets. More complex than sending a kind of query. People make choices. Want to specify how... and what we want as answers... one or two choices. In HISA we are thinking about standardizing this. When look at archetype... are also used at runtime... Difference between what you are allowed to do. Do you reference inside or outside jurisdiction? Just a way to make you aware? Something for CIMI to think about or wait for our process that will take 3 months or 6 months.
[slide-7 Archetype Template, Types of Sources]
Linda: So - the specific areas for CIMI to look at?
Gerard: Nothing now. We discussed the intersection between... taking a look at modeling archetype and how to refer to data outside the archetype. And how we deal with SNOMED... or slot behavior, because now... it is to limit it.
Gerard: Another... modeling style. Class modeling.
[slide-8 - Class modeling Style]
Gerard: Entry...cluster... start changing the names of nodes and attach all kinds of (?) to it. Modify on test side... modeling style - what we are using now. This is the pattern... will contain the name... in this case, Physical Exam... systolic and diastolic. How deal with specialization... How we specialize them. We leave the nodes apart. We indicate that this is a systolic BP. And when you compare the... way of modeling with our modeling, then this is the difference you see.
[slide-9 Attribute modeling Style]
[slide-10 Example 1]
[slide-11 Example 2]
Gerard (cont'd): Last Tuesday, Medicinal Product... also indication... Medicinal product and active ingredient live OK without indication.
[slide -12 - Ad-Hoc Document style versus Process style]
Gerard (cont'd): Part of prescribing and then link to stored data... If model like last Tuesday, you have an inclination for pre and post-coordination. If model this way, can have simple SNOMED code and avoid pre and post-coordination. And it is how you order.
Linda: The medicinal product presented was not a CIMI model. Also, indication has different meanings. The way you modeled here would be (?) if was (?) for patient.
Gerard: [can't hear]
Linda: Don't focus on that model too much.
Gerard: A simplistic way of presenting... whether start point is process or... How deal with patterns. One pattern for all archetypes and specialized in one way. Or... It is a choice - a modeling choice. I want to expose you to it. Whether we model...
Linda: Would be helpful if you took the existing Mindmaps and showed what you would do.
Gerard: I could, but in weekend I thought about what we discussed at meeting. But I could do that.
Linda: That would be useful because I find it hard from these...
Gerard: I will do that.
Linda: Good, except that I will be gone for 3 Â½ weeks. We know that the different modeling will be different styles, and we need the CIMI preferred model.
Gerard: I think both are map-able but there are differences.
Linda: We can compare. Any questions for Gerard?
Rahil: Slide about SNOMED and structure - do you want to discuss more?
Rahil: I think fundamentally, used differently in 2 Use-cases. The structure is more about what is required... for requirements than needs... Structure driven by requirements, SNOMED by content... All they have overlaps and should communicate, but can coexist and don't need to replicate, either.
Gerard: Discussion is going on in Semantic Healthnet.
Tom: Yes. What Rahil said... My view is if you want to state that, you need to be more clear. Not a replacement question.
Rahil: I would be interested in Semantic Health Discussion. Would be interested in hearing discussion.
Gerard: Will meet in early May... in 2nd, 3rd of May in London.
Rahil: Please let me know the details.
Daniel: To summarize the 3 questions on this slide... No, No and No. What Semantic Health is trying to do is apply description logic - more expressive. This is what was discussed... not sufficient to represent what is in the structure.
Gerard: Yes - but what are consequences when we model and apply SNOMED codes?
Daniel: Good question.
Linda: Need specific examples. Other questions for Gerard? [No response] Thanks Gerard.
Linda: Looking at agenda - 10 minutes left. Get started on ISO11179 discussion?
Harold: No - since it is 15 minutes discussion... Will have to continue another time.
Gerard: I am part of project where use ISO-standards and link into ontology world. Looking into relationships between archetype and data standards.
Linda: Thank you. And in Australia - using (?ISO11179?) to...
Harold: What I am focusing on ISO... 11179 is a meta-data repository. Need to say something about the data you are recording about. Useful... abstraction. Ties closely to SNOMED we are talking about... element definition.
Linda: Singapore using 11179 for data dictionary. Rahil?
Rahil: I know has been work with ?11179... Nicholas.
Linda: Good backdrop for meta-data, but not have capabilities to express all in archetype.
Gerard: I think is possible to express archetypes with this.
Linda: Next week - Harold will chair next Thursday's meeting. Will Stan chair Tuesday?
Harold: Not sure.
Linda: Harold will check about Tuesday's meeting.
Harold: We do need to get back with terminology binding and try to resolve.
Linda: Good - will come back and all will be sorted.
Harold: Is that a 't' or a 'd'?
Linda: A 't' - definitely!