CIMI MTF Minutes 20130523

From CIMI
Jump to: navigation, search

CIMI Modelling Taskforce - Meeting Minutes

Thursday 23th May 2013 @ 20:00-22:00 UTC


Attending

Linda Bird

Harold Solbrig

Stan Huff

Rahil Qamar Siddiqui

Mike Lincoln

Patrick Langford

Joey Coyle

Daniel Karlsson

Michael van der Zel

Sarah Ryan

Gerard Freriks

Dave Carlson

Eithne Keelaghan

Agenda

  • Finalise CIMI Reference Model DSTU
    1. Discuss representation of relationships such as Link.Target - options include:
      1. Logical Association (current approach)
      2. Instance identifier (e.g. record_component_id)
      3. XPath
      4. EHR_URI
    2. Current progress (EA, BMM, XMI, RDF)
    3. Agree on versioning rules proposed by Thomas Beale
    4. Agree on location in opencimi.org Github repository
  • Unit of Measure (modelling style and approach)
    1. Finalise discussion from last week:
      1. CIMI general models only bind models to the Property of each quantity (e.g. mass concentration, time, volume, length, pressure), without defining the specific unit of measure;
      2. Regional specialisations can specialise the CIMI general models to define specific units of measure used regionaly
      3. A 'CIMI Canonical model' specialises the 'CIMI general models' to a specific unit of measure to be used when interoperability is required between jurisdictions
        1. Canonical model may both restrict the UOM and define any appropriate min/max value constraints applicable to that unit of measure
          • Units of measure will be included in Property-based reference sets (e.g. Temporal_UOM_refset)
    2. Finish discussion on Daniel's last comment last week, regarding it being difficult to enumerate all local units in the CIMI models (to ensure that the property-based UOM reference sets being complete).
  • Peter Hendler/Kaiser exercise:
    1. Progress and plan for Diabetes UML modelling exercise
    2. Produce Kaiser UML version
    3. Produce AML UML version
    4. Compare overall tree structure
  • Updates on other implementation work:
    1. AML work
    2. Mindmap-to-ADL conversion
    3. Mindmap-to-instance conversion
    4. OMG: OWL RDF
  • Publishing to the Portavita website
  • LINKs
    1. Reusable parts (like #include construct) - a reference (if specializations are to be allowed as well)
    2. Named links between instances - openEHR links
    3. Slots - items choosen from a set defined by queries or exclusions
    4. Can be substituted in a later model constraint step?
    5. Can be substituted at runtime
    6. More ...

Detailed Meeting Minutes

Review Agenda - Linda

Linda: Start with Michael's topics... I'll go through draft agenda. Comments... First is - finalize Reference Model DSTU. Michael kindly offered to present. ISO13606 approach is to use an identifier...

Michael: At end of Agenda there is a part about "Link"...

Linda: Yes - not sure what that is. Stan wanted that...

[Stan not on call yet]

Harold: Yes - he wanted to get clear about... from various communities. Hopefully he will be here.

Michael: Yes. I included this.

Linda: Good. Other topics - Units of measure. Did not finish last week. Looking at progress of Kaiser experiment. Other topics...


CIMI Reference Model DSTU - relationships such as Link.Target

Slide 1 - The Topic

Michael: I wanted more time... We are talking about the LINK.target, Participation.party and Party_relationship.target. I think we said in new rules it will be...

Slide 2 - What? Where? How?

Michael: So - "What" are we talking about? "Where" would one solve it? And "How" do we solve it? Those are the 3 questions. Find out what we need to do...


What are Links?

Slide 3 - What are Links?

Michael: Just a list that Stan included... What are links?

Linda: Previously we assumed they were Links between instances.

Michael: Yes.


What is in scope and out of scope - Instance and Logical?

Slide 4 - Scope

Michael: What is in scope and out of scope? So, out of scope - instance. In-scope - Logical - A Link to a type of instance, e.g. Logical ID, pattern, code, subset... or include-based. We are not referencing instances. Determine at Run-time what instances go in there.

Stan: Yes - not putting instances... But putting the framework in place so can specify type of Links... Governing the kind of Links you are expecting... in implementation.

Michael: Other - including models.

Stan: I don't know if we are doing that using Links or if some other way. Two different behaviors, and I don't know... OpenEHR - governing the Links in instances... and if we go beyond that, I need to understand.

Linda: And Links between models is done in AOM(?)... Not using slots and references... because it is at the modeling level, so don't need to see...

Gerard: The original Link... is Link to instances... but that is too simple. Need a generic interface... to several things... design at design-time and other at run-time. So Link-class is a complex interface - how I like to view it.

Linda: Instances of Reference Model is the patient-data. Whereas Links between models in patient-data could be... or all 1 model...

Gerard: Present slot mechanism is not mature enough...

Linda: Have to look at in regards to AOM...

Michael: So... first is in scope, and second part is how to do inclusion... AOM - out of scope.

Linda: Important to discuss, but in context of AOM.

Michael: I am glad we are clear on that. Next...

Slide 5 - Where to Solve?

Michael: Where to solve? RM level and Archetype-level... not in scope.

Gerard: It reaches archetype level AOM or UML... Must learn to think of as archetype... Slot mechanism - is AOM.

Michael: Later - right.

Linda: Yes.

Gerard: There are types of Links and we can discuss...

Michael: I now have a problem... The thing I wanted to propose is something else...

Linda: Have you slides on Link.target option?

[Michael skips slide-6 titled "How?"]

Slide 7 - Option 1 (on page 7)

Michael: Now most of them are obsolete because we decided that... (?). This talks about between models.

Linda: Still have 4 options for link.target. Where target of Link is ... reference... instance-identifier approach... where an attribute is defined... Link.target is a ... URI refers to... that Link is...

Michael: I think we just decided that the Link defines the type of instance we can put in these.

Gerard: Scope for this discussion......

Linda: Models themselves can constrain the... But it still needs to know what to point to... Data... How the instances are... So we need to decide on data-type of instances of... Logical identifier.

Gerard: Or both.

Michael: I would transform the Link to a ... It depends on the implementation what you choose.

Linda: Yes, but will need to make a choice for our... in order to better explain the models. So need to make a choice for those example instances.


Concern over Link-Target Relationship

Linda (cont'd): Can we go back to reference-diagram?

[1]

Too bad Tom is not on the line. He initially raised concern over Link-target relationship. I think intention was to keep it as Logical... So keep that as Logical as possible. But when define... that has a Link, for example, between Lab result and the order that caused Lab test to be performed, may need a pointer to a target that defines the lab order that initiated that... certainly we can... and refer to that in... If going to be in XML, can refer to it as XPath. Can show representation of how implemented...

Rahil: Yes. Tom said... the ability to have a unique identifier... to what Link is targeting... specify through... exact identifier... Link... is important... One of the issues Tom raised weeks ago. The issue is... unique identification...

Linda: Exactly right.

Rahil: So I think we do need some sort of unique identifier... target... so we know exactly which...

Harold: Architect ... id - is that the... of Locatable of identifier of archetype...?

Linda: That is...

Harold: So...?

Linda: Yes. In ISO13606, they have RC-id which is the instance identifier... Locatable. Important when doing Links and... version... But there are issues with having RC-id's... The rules can get complicated.

Harold: I don't think the standard has to say what the form of the identifier... would allow me to... But I do think we need something that says Locatable ID...

Linda: So - question is whether we make it optional and only required if being Linked to?

Harold: I assumed the class-name locatable indicated the identity. How can I locate if not identity?

Stan: My assumption... Instances have id's... can Link, but also other implications. I am in favor of... a string... recognizing that is a path or something... could be a path or...

Harold: Someone said through the path. We could go so far to say - it can be computed. Should be a way to ask a Locatable - what is your unique identifier? So I can talk about it.

Michael: The instance - identifiers depend on technology you choose.

Harold: I don't think the presence of an instance identifier depends on technology.

Michael: We don't want to restrict the... But want to restrict the title.

Stan: In our implementation, we mixed assumption about implementation with models. We put together the logical idea of floating point number and the... representation... mantissa... That was an error. Want to say - this is a unique identifier. If... implemented in XML, would be... Assumption that there is a unique id. So we create... that everything has a unique identifier... I think that is what Harold is saying, and I am in favor.

Harold: String is probably good enough. But maybe not all Locatables have identifiers. If nothing else, it appears that this is the only way to talk about Links... Or am I getting models and meta-models confused?

Rahil: By specifying... in string... what Stan was talking about... Would string be a sort of representation of data-type... or something generic?

Stan: I would be fine with that. I just am saying... uniqueness... If we wanted to make an identifier... I would be happy with that.

Linda: If we left as a string at the moment we would have to decide what... If passed in an API. So may be better to decide here... Every single element of every model requires an identifier... makes you... larger... And whether is stored and appears in data or is logically... I have had... ICID - topic of discussion in Singapore. I think Tom's approach is to refer to archetype path (?)... For instance, the diagnosis/code or diagnosis/description... So he uses the archetype path... not stored in...

Harold: Not trying to assert storage structure. But asserting that you should be able to get an identifier... to Link to... One way in UML... put a "derived-flag"... or make a method rather than an attribute. If derived, we are saying that... all locatables... should be able to come up with a unique identifier.

Linda: I like that. We could represent in UML as an operation.

Harold: If derived from UML, you put a... I would be interested in hearing Thomas's input on that. So that says that... it is up to the implementer how that happens. It is stronger. Also need Dave on this call - he can tell us what to say.

Linda: Michael - on the Link, we need the third attribute and the other...

Harold: So a Link is always constrained... particular id? I am looking at the model.

Michael: I am trying to... the different options... The other is some kind of...

Linda: All of that can go in AOM. The instance just have what is pointing to... patient-data... You'll see... whereas archetype model itself... an instance from a particular model... You won't see the name of the archetype it points to...

Rahil: In openEHR... defined as VHR(?)... UMR... whether you want to reference the target using... How you actually get to the target. Whereas in our case... the identifier we have used in the locatable class... How we are getting to the target.

Linda: A really good point. Discussion encourages us to go back to openEHR URI and if we... We can fix that is... and... we can... and see if openEHR... is sufficient or if we can have a different approach.

Rahil: Yes - I think how openEHR did it... If we have an alternative approach... to the design of EHR URI would allow that as well...

Harold: I could interpret option 4 in 2 ways.

[slide- 10] Option 4

Harold: Are we talking about the instance of the locatable? When we define a Link... No - never mind. It has to be the instance. I have to ask - is that necessary? Model elements have to refer to model elements and instances. But whether a URI, a hash, or some other scheme... Do we need that standardized on instance level? Share instance data or share models?

Stan: Both.

Linda: If want standardized, would need to... instance data.

Stan: Make sure I understand. We are trying to create interoperability. If I was thinking about now... Want to create around the SMART API's... But that implementation would have to make assumption about interoperability. Would have to... framework for interoperability... But then my eyes opened. Some might want to do around how SMART guys have done it, but then I thought some may want to do it with... JSON... So, have to say if implement...

Stan (cont'd): So - to get the interoperability, have to go from this level that we are specifying and go to... say "This is the JAVA implementation of Date and Time, and..." So, logical level to binding of physical level, and... stack(?). So you either understand me or... So unrealistic to say we will do with semantic web... over time we will have semantic web implementation and JSON and RUBY and...

Rahil: I agree with Stan. We require flexibility at implementation level. Also, need flexibility at (?) level. CIMI is being looked at as... canonical... Again, the target has to be String. There are no archetypes in the messaging world. So, how do we...? We need some of these model transformations thought out as well.

Stan: I think you are right. The other thing... we will have models in ADL... will want transform to AML and if going to do that, have to say how a construct in ADL... into AML. The AML group - figuring out how to do that. And want to make representation in OWL or ASN1 or other modeling Paradigms. Is that correct?

Rahil: Yes. We will be encountering model transformations... So... question... bearing in mind our discussion.

Harold: I am reading your note, Michael. Target can be... or constraints.

Linda: Yes.

Michael: Sorry?

Harold: 2 different things. One is constraints - Business Rules on what a Link can and cannot point to. The other is... Business Rules(?).

Linda: Yes. So the target will be the identifier of the instance it points to.

Gerard: The type.

Linda: Also - if... as string rather than EHR URI. Is that to make it more flexible?

Harold: We define specifically as EHR URI... then will be some expectations we will probably be unable to meet. But I don't know. Are these implementations we will make not possible by saying that?

Rahil: We could make it an (EHR?) URI... keep target-type as EHR URI...

Harold: Thinking about HL7 (RI?)-type. They wanted to say this II(?) is an instance identifier. They said... a whole set of choices of all the different ways they could think of to make one of those.

Rahil: We did the same... Usefulness in that... stick to another, broader identification scheme... We have done that ourselves and it... flexible at logical level. Take your pick... but string...

Harold: Says anything that can be converted to a string one way or another... I don't want to list all possible choices.

Rahil: Eventually these complex types... too primitive... Why can't have more logical data type?

Harold: One argument... Keith(?) in VA... are enamored by GUID(?). GUID is fine. Our requirement - has to be globally unique. Beyond that, string is a stake in the ground... can't be a floating point, but... Is locatable name an identifier within one scope, and what scope is that?

Michael: [can't hear] Scope is kind of limited. Not globally unique.

Harold: I suspect for UML we will have to resolve that.

Linda: I think with openEHR... must be unique within the structure... but not globally.

Daniel: Probably not unique because... could be several notes with same name following each other.

Linda: Certainly true at instance level.

Harold: They have called namespace... each child of namespace has to have a name that is unique within (?) of namespace... and need to have a way of... by traveling the path of... And I suspect we will have to resolve what the scope of name is and what is its purpose...

Linda: Also, depends on if unique within model or instance. Certainly not instance... but model... Need unique at model level because that is what AML is dealing with. If see... diagnosis... will have multiple in instance.


Instance vs Model

Dave: I am here now. Instance vs. model. Unique id's and (?) at model... Never occur at model level - instance level...

Harold: We have been talking about Link as instance-level... Question is - the Link had a target. How id the unique instance... is derived? Folks say - don't want instance id on every node. But I say it has to be computable... What should we say about instance id... ?

Dave Carlson: UML... not really say anything about ids of instances... On other hand, sometimes using XPaths... dependent on order of nodes... XPath can break if reorder...

Harold: Are we going too far?

Dave: UML not assume that at all. Need to put an attribute in model that contains that id.

Harold: (?)

Dave: If derived, then XPath like...(?)

Harold: Need to (?)...

Dave: Needs to be an attribute... Locatable.

Harold: You see it? So you agree... if have to reference, then need to call out some sort of identifier.

Dave: Leave in XML. Only requirement in ID rough(?) and... That is where you use the number-sign...

Harold: One way or the other, we have to declare a scope.

Dave: This is the scope of the document containing the instance. CIMI is agnostic about an instance... could be database or JSON or...

Harold: One document can carry.... and the other carry the order...

Dave: At least... with number (?) and number (?) in XML...

Harold: Theoretically aggregating these instances...

Dave: A GUID...

Harold: Can we get away with... whatever you do, the instance id has to be... context... up to you to decide... Give it a name...

Dave: Requirement that is a grey-area...

Harold: If this were a specification, we could put a solid stake in the ground. But as Stan mentioned, there are database implementations, RDF implementations, HL7 OIDs - difficult to implement in RDF. Correct Stan?

Stan: Yes. We are trying to say - an assumption of this architecture - create Links between instances... identifiers for... with the assumption that, what would happen from this level... If you are going to implement in XML, this is how you make your instance ids... from CIMI coded data-type... If XML, this is it. In JSON, this is it... terminology binding. The interoperability - will need to assume something about... states... At this level, we are trying to say - you will create Links between instances, but...

Dave: I agree.

Harold: As Thomas mentioned, there are... One of them is an id-tag. Can put an attribute in a class. And other thing - arrow from ... to Locatable. A little box... names the identifier in Locatable... How useful it is, I don't know.

Michael: I tried to create an instance of a CIMI model and I ran through... the whole target thing... in an instance...

Linda: Target would be the instance id, so only had one of those.

Harold: I had constraint on id... I am confused... if instance of Link is a model or is an instance?

Linda: An instance of a Link is an instance. Michael - I think you need to...

Michael: I thought the target of id was to specify the... to go in instance. This example I am showing is in AOM, not in CIMI Reference Model.

Linda: Yes - should be defined in archetype... and instance AOM.

Dave: But what are you constraining if you only have an id?

Linda: Yes - is a challenge. We struggle with this in Singapore because you have to say the... and you need a query language to say that, and we discussed with Tom. ...especially the Participation.Party. And we wanted to say this Participation.Party needs to point to healthcare provider. But you don't see in patient data.

Dave: ... At link, is just a pointer to a Locatable. Why not say it is just a Locatable?

Harold: That is where we started!

Dave: You have to say... you are adding additional...

Rahil: Still doesn't tell us the primary... being a Locatable... not tell us what column name of Locatable is this target... Still does not tell us that.

Dave: The ID does not give you full picture either.

Rahil: We need some sort of unique identifier... Require unique identifier to be... in target. Not good enough to say Locatable... saying... this form of identifier... The way we did in LRA - specify the... Not ever generate unique identifier... when we created instances. Did not look at identifier, but all linked together... Not need to worry about... Maybe that is what we have to address.

Linda: Michael - can you bring back association from Link to Locatable?

Dave: I understand.

Linda: So - do we need to...?

Dave: At UML Meta-Model... for composition... On other hand... not a reference... is a composition... In XMI... Other attributes... XMI-type... instances would carry what XMI-type for what type of Locatable. Can find examples of other XMI-schemas over the year. XML... XMI-type... schema... At the model level - more descriptive of what we are trying to do. Really - to attributes the instance has to contain... the type and the id.

Linda: And the type is what we constrain in the archetype... May be more than... Because lab-order is...

Dave: If all you have is... then nothing to...

Michael: That is why XMI-type is lab-order...

Dave: ?

Michael: Because attribute-type is lab order...

Dave: And is the id itself... the (?) and id.

Rahil: So the combination...

Dave: Both the XMI-type... type of subclass and has to be ID of instance pointing to...

Rahil: But this is implementation-specific, not logical.

Dave: Need a relationship... Without the relationship there is nothing constraining ADL.

Michael: What is the relationship?

Dave: The association...

Rahil: Yes.

Linda: We need to be more... But at logical level we don't want to preclude...

Rahil: I don't support... I think we should make sure Thomas is on the next call. It is important to see how openEHR models are implemented.

Linda: I thought Dave suggested...

Dave: Say the target is... constrained to (?) of Locatable... becomes part of the implementation...

Linda: That is how it was previously designed. But Rahil and Tom Beale have requested...

Rahil: The target is an association to Locatable that can be identified. However implemented... We require the locatable to be a target... uniquely identified locatable... But how... is immaterial...

Linda: I propose we go back to target association, but keep... If we can define Locatable instance id representation...

Gerard: I sent email with picture... contains idea of (?) with Link-class.

Michael: Do you think it helps to have XML examples?

Linda: Absolutely. Raises question to resolve with instances... Because raw instances of (?) models... I noticed that you have used model-names, which is clear... easier to read where XML tags are clinical elements...

Michael: Yes.

Linda: The only thing that is missing in instance is the Ref-model type of each node. So if you added... said it was an entry...

Michael: We could do that.

Linda: Makes it easier to...

Michael: You can generate... based on the model, so it can understand... schema... or CIMI...

Linda: I propose that next week, we have as a topic an instance, and have... uses reference-model approach and clinical-model approach.

Stan: I like that - so I understand.

Linda: 15 minutes left.

Gerard: Did you receive the picture?

Linda: ... Target is defined as an II(?). I think we discussed that this will exclude some implementations...

Harold: I don't' know if excluding. At least says how to do them.

Linda: So are all happy with going back to logical target association, and... some instances... Stabilize ref-model DSTU - was main goal today. But we need to put a stake in the ground. What is everyone's thoughts?

Stan: I am happy with where we are at with the recognition that 1 or 3 weeks from now we may think "Oh - I did not think of that". But that is why DSTU version. But will let people make tools...

Harold: Yes - if we put a stake in the ground and start making examples, I think we need to say this is good enough.

Dave: For example, with last DSTU... Eclipse-friendly version... and start... so this Link is specific enough for an Ecore model... has the internal... The way it specifies... is sufficient for ecore...

Rahil: Yes - I don't intend to be obstructive...

Dave: No - I know...

Rahil: If there are implementations that can cope with it, fair enough. And if requires changes later on - OK.

Linda: ... Locatable... instance id is derived? Are all comfortable?

Stan: I am fine either way. Not enough of an expert... Not trying to pin a...

Dave: Derived implies not a property that is...

Rahil: When generating the Ecore models from this, wondering if require the derived...?

Dave: The latter. Ecore uses XMI... So built into XMI spec... Will create an id that... proxy... I can create a small example... and can create to your point, Stan.

Michael: We can also mean, Xform into ecore and then into JAVA. JAVA automatically has id.

Rahil: If this is generated automatically in environment, it is... and then transformed to other environment, then re-generated...

Stan: If that is assumption in each language, then don't need it. But... I am comfortable with having it here. Theoretically, there are implementations that don't have automatic... So in... do have an account for instance-ids.

Dave: I agree.

Michael: Could be 2 ids... internal and externalize-able... something you can exchange.

Linda: My tendency would be to leave it out... identifiable... should also include for party, if we include... I take that back - party is a locatable.

Stan: Is that assumption stated somewhere?

Linda: I went back to UML 1.1 and... and I quoted that. "The UML Ref Manual - Rumbaugh, Jacobson and Booch"... At the Logical level, we decide that we don't need to make a decision...

Dave: Or left up to the implementation.

Linda: Perhaps.


Finalize CIMI Reference Model DSTU

Linda: So... all comfortable with "instance-id"?

Harold: Yes.

Stan: Yes.

Linda: Michael - you are comfortable with moving forward with DSTU?

[no response]

Linda: Stan - are you going to vote with members?

Stan: Did we make changes from what we agreed to in Leeds? Or intent changes?

Linda: I don't think so. Only change was derivable instance-id... Not a significant change?

Michael: Yes. And link-details.

Stan: Let's call it a DSTU and if objections then... I don't have a problem with another vote. But let's canonize this and then... I think it will pass anyhow.

Linda: Michael - can you put where we can access?

Michael: Yes.

Rahil: The target is the... class. And the cardinality is one (?).

Linda: Yes - cardinality is missing, Michael.

Michael: OK - I will fix it.

Dave: And target is...

Michael: Yes.

Linda: Maybe you can send a draft out, Michael?

[end-of-meeting]