CIMI Meetings this week
Linda Bird (MOHH)
Dear all,
Just a reminder that the following CIMI meetings will be on this week:
- Terminology & Tooling meeting: Tuesday 20:00 – 22:00 UTC
o Please note that (as discussed in Scottsdale) for the next few weeks we will be primarily focussing on Tooling during these meetings, and discussions will be chaired by Harold (thanks Harold!)
o Draft agenda:
§ Terminology tooling – requirements, options and selection process
§ Terminology binding for Laboratory results model (* Note: Only if there is time, after the tooling discussions *)
- CIMI Modelling Taskforce: Thursday 20:00 – 22:00 UTC
o Draft agenda:
§ Weekly News & Updates
§ CIMI Modelling Style Guide – Table of Contents
§ Comparative Analysis Spreadsheet template – feedback
§ Review of Demographics Comparative Analysis spreadsheet & models
· Location, Address, Party, Actor, Person
Also - As discussed at last week’s meeting, please find attached the draft ‘Comparative Analysis Template’ (for your review and comment ... thanks Anneke for your help with this!), and the example Heart Rate spreadsheet that was sent around in August last year (Please note everyone that this heart rate model is out of date – I am just sending for the layout, as requested by Joey)
Regards,
Linda.
Dr Linda Bird
Information Architect Information Systems Division
mobile +61 411 274 870 skype linda.j.bird
|
|
MOH Holdings Pte Ltd 1 Maritime Square (Lobby C) #11-25 Harbourfront Centre Singapore 099253 www.mohh.com.sg |
Please consider the environment before printing this email.
This email may contain privileged/confidential information. If you are not the intended recipient, please notify the sender immediately, and delete this email and any record or copy from your system. You should not use, disclose, copy, distribute or retain the contents of this email or any part of it, including, but not limited to its attachments. The sender reserves all rights. Thank you.
Gerard Freriks
Peter....@kp.org
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
§ Weekly News & Updates
--
You received this message because you are subscribed to the Google Groups
"cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send an email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
[attachment "CIMITemplateClinicalModel 23-01-2013.xlsx" deleted
by Peter Hendler/CA/KAIPERM] [attachment "CIMI - Clinical Models (13
August 2012 - examples).xlsx" deleted by Peter Hendler/CA/KAIPERM]
Ian McNicoll
--
You received this message because you are subscribed to the Google Groups "cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send an email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mc...@oceaninformatics.com
Director openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org
Daniel Karlsson
link to the AOM serialization beauty contest:
http://www.imt.liu.se/~erisu/2011/AOM-beauty-contest.html
from Erik Sundvall, presenting his thesis Feb 15. http://www.imt.liu.se/~erisu/2013/phd/
/Daniel
Peter....@kp.org
In order to automatically convert spreadsheets into triplets (RDF or OWL for example) you need one spreadsheet without nesting.
The first Column becomes the Objects, the column headers become the Predicates (or roles) and the cells them selves become the Objects.
Here's how to represent nesting of subclasses in a single spreadsheet (without dividing it into little sub sections.
| a1 | hasFindingSite | hasMorphology | isA | CausativeAgent | |
| Pneumonia | LungStructure | Inflammation | Disease | ||
| MyocardialInfarction | HeartStructure | Necrosis | Disease | ||
| Stroke | BrainStructure | Necrosis | Disease | ||
| PneumococcalPneumonia | Pneumonia | Pneumococcus | |||
| ViralPneumonia | Pneumonia | Virus | |||
| LeftMotorCortexStroke | LeftMotorCortex | Stroke | |||
| LeftMotorCortex | BrainStructure | ||||
For example in this "baby snomed" spread sheet the way you can specify a nested concept under a parent is how "ViralPneumonia" has "Pneumonia" in it's "isA" column, and in turn, the "Pneumonia" also appears in the far left column, and in that row, its parent is "Disease".
In this way, any part of any model can be on one sheet without nested sub sheets. And can therefore be imported into RDF or OWL, and therefore be compared to another model.
The spreadsheet must only have the neutral relationships that model the clinical information. As soon as it has "at codes" or "archetype node IDs" it is no longer neutral but is an openEHR model.
Perhaps before we come up with our template, we'll need to model an HL7 RIM clinical statement and an openEHR archetype for the same thing into two separate spreadsheets and then import them into RDF or OWL. We could then do a SPARQL query or use a reasoner to see if they are "equal".
This technique could also be used to test Union and Intersection to see, in the case that the models weren't equal, what parts of them overlap and what parts are unique to either model.
The only well studied standard ubiquitous way to tell if two models are equal or how they differ is RDF or OWL. We should assume that we will not be able to do any automated comparison of our models unless they can be decomposed into RDF or OWL. The RDF or OWL that they decompose into should not have any nodes named "at0001" or "archetype_node_id".
We can assign each node a unique UUID and a Name, and some of them will also be mapped (via triplet relationships) to SNOMED codes.
Joey, maybe as an exercise you and I could try to put this "heart rate model" into a non nested and neutral spreadsheet?. I'm already looking into the tools that import spreadsheets into RDF or OWL.
Thanks
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
From: "Linda Bird (MOHH)" <linda...@mohh.com.sg>
To: "cimi-modelli...@googlegroups.com" <cimi-modelli...@googlegroups.com>
Date: 01/28/2013 09:55 PM
Subject: [cimi-modelling-taskforce] CIMI Meetings this week
Sent by: cimi-modelli...@googlegroups.com
§ Weekly News & Updates
--
You received this message because you are subscribed to the Google Groups
"cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send an email to cimi-modelli...@googlegroups.com.
Visit this group at
http://groups.google.com/group/cimi-modelling-taskforce?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
Solbrig, Harold R.
Thomas Beale
Looking at the sample spreadsheet template (not included here but in Linda's last email). �It has a lot of nested structures (like little sub spread sheets inside the big spreadsheet). �And it has "at codes" so it's not a neutral format but a very specific openEHR based model.
Peter,
at the risk of not knowing what you are (really) talking about, I'll just point out that at-codes just mean you are looking at ADL, not openEHR. ADL for 13606, CIMI, and HL7 has at-codes (currently... one day this might change. Don't get hung up on the physical representation of the code).
In order to automatically convert spreadsheets into triplets (RDF or OWL for example) you need one spreadsheet without nesting.
The first Column becomes the Objects, the column headers become the Predicates (or roles) and the cells them selves become the Objects.
Personally I think doing manual work that is better done by computers using spreadsheets is to be avoided, but I may not know what you are trying to achieve here, so I won't comment further!
- thomas
William Goossen
But it are exactly the physical representations in ADL such as at codes where I object to. Cimi models should only be conceptual and logical and definitely not physical if we want for generic use and isosemantic representations.
Please make the physical ask content go away by Feb 15, 2013.
Vriendelijke groet,
William Goossen
Verzonden met mijn Winphone Nokia Lumia 800
Van: Thomas Beale
Verzonden: 29-1-2013 23:48
Aan: cimi-modelli...@googlegroups.com
Onderwerp: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
Looking at the sample spreadsheet template (not included here but in Linda's last email). It has a lot of nested structures (like little sub spread sheets inside the big spreadsheet). And it has "at codes" so it's not a neutral format but a very specific openEHR based model.
Peter,
at the risk of not knowing what you are (really) talking about, I'll just point out that at-codes just mean you are looking at ADL, not openEHR. ADL for 13606, CIMI, and HL7 has at-codes (currently... one day this might change. Don't get hung up on the physical representation of the code).
In order to automatically convert spreadsheets into triplets (RDF or OWL for example) you need one spreadsheet without nesting.
The first Column becomes the Objects, the column headers become the Predicates (or roles) and the cells them selves become the Objects.
well I would say it's pretty normal to convert a hierarchical structure to triplets; what you are looking for is a view of the object structure using references rather than inclusion by value. That's achieved by a traversal that uses the paths of each node to refer to it, and progressively generates a triplet for each node entered, with the previous parent node acting as the source object. Your spreadsheet table below is just a manual version of doing this, but now it's not useful for humans to read, only computers. That's why hierarchical representation is used in most object formalisms, including ADL (and many others).
Personally I think doing manual work that is better done by computers using spreadsheets is to be avoided, but I may not know what you are trying to achieve here, so I won't comment further!
- thomas
Thomas Beale
Hi Thomas,
But it are exactly the physical representations in ADL such as at codes where I object to. Cimi models should only be conceptual and logical and definitely not physical if we want for generic use and isosemantic representations.
you are missing the point. Any conceptual model, if it is to have some actual existence in this world, has a physical representation. There will be codes, syntax, and other formalism elements being used to do that - if we are formalising at all. If you are talking natural language, then all of that just reduces to words (and that's a different exercise from what I last understood was happening; it's equivalent to early stage mind-mapping).
The important distinction is between design and implementation expressions, where the latter implies some particular reference model, message format, etc and the former captures the domain-level semantics on their own.
- thomas
Gerard Freriks
Peter....@kp.org
Joey Coyle suggested at our meetng in Scottsdale that we replace ADL with spreadsheets as the way to express our models. Many of us strongly agreed with the suggestion.
Linda's spreadsheet is a first try at what such a spread sheet template would look like. My comments were under that context/assumption.
Specifically, many of us will not use clusters, elements, entries, items or in the demographics, parties in any of our models internally. Those are (I suppose ADL and not openEHR) constructs?
But it's not the way we picture the world or clinical information and we are much more comfortable doing it our way that does not require those constructs.
Thanks.
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
Thomas Beale
I do confuse where openEHR and ADL differ. So in my previous comments just substitute ADL everywhere I said openEHR.
Joey Coyle suggested at our meetng in Scottsdale that we replace ADL with spreadsheets as the way to express our models. Many of us strongly agreed with the suggestion.
Linda's spreadsheet is a first try at what such a spread sheet template would look like. My comments were under that context/assumption.
Specifically, many of us will not use clusters, elements, entries, items or in the demographics, parties in any of our models internally. Those are (I suppose ADL and not openEHR) constructs?
But it's not the way we picture the world or clinical information and we are much more comfortable doing it our way that does not require those constructs.
The clinical tools we use with clinicians indeed hide most of that, which is why they see things like the below- 4 views of the same archetype, all tool mediated, all hiding the underlying reference model classes. These are the tools in use day in day out in our clinical modelling world at least, by clinical people, and we learned very early on that you need to hide most of the reference model. But... it does need to be there, because it establishes the semantics of the information. An ENTRY or OBSERVATION or ACTION is different from a low-level hierarchy node like CLUSTER or ELEMENT. The RM also defines a set of semantics that can be used to determine a shareable (i.e. interoperable) data representation, e.g. for converting between concrete proprietary (e.g. Epic) and/or open formats (e.g. CDA CSP at VA).
If you opt for spreadsheets for more than just initial discussions, then you are in totally uncomputable territory (and I am not against spreadsheets for some early modelling, but I would have thought we should be using tooling and visualisation here).
If you don't want a reference model at all, then the CIMI project is a different thing from how it was initially defined (original mission statement; original requirements), and many subsequent discussions about the RM (e.g. patterns). These were the reasons that ADL was chosen - because it enables you to define clinical semantics on the basis of a single standard reference information model (which can be as abstract as you like).
I may just be out of date with proceedings ;-)
- thomas
CKM Mindmap, generated from archetype:
CKM HTML view:
Archetype Editor (the main clinical modelling tool today for the openEHR community):
ADL Workbench beta 8 (clinical view)
Thomas Beale
William Goossen
Of course we are in CIMI not natural language processors. But the design stage in our work at CIMI should ONLY deal with the logical aspects of concepts, data elements, code binding, data type and relationships. And we do need a format to do this.
However, fixing the format to ADL is fine as long we do allow transforms to other formats, can move it to various technologies and are not forced into irrelevant technical artefacts as at codes or limited worldview reference models that support only one very specific implementation.
Vriendelijke groet,
William Goossen
Verzonden met mijn Winphone Nokia Lumia 800
Van: Peter....@kp.org
Verzonden: 30-1-2013 17:25
Aan: cimi-modelli...@googlegroups.com
Onderwerp: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
I do confuse where openEHR and ADL differ. So in my previous comments just substitute ADL everywhere I said openEHR.
Joey Coyle suggested at our meetng in Scottsdale that we replace ADL with spreadsheets as the way to express our models. Many of us strongly agreed with the suggestion.
Linda's spreadsheet is a first try at what such a spread sheet template would look like. My comments were under that context/assumption.
Specifically, many of us will not use clusters, elements, entries, items or in the demographics, parties in any of our models internally. Those are (I suppose ADL and not openEHR) constructs?
Peter....@kp.org
And Observations being kinds of Acts. It's much easier for us to think that way rather than thinking in terms of tree structures and document structures.
The headers and subsections are very much like document structures and we do not necessarily need to think of things as documents. The HL7 clinical statement is more how we think of things. I am not saying it is the HL7 RIM. But the general idea of Entities in Roles Participating in Acts and Acts related to Acts is a lot more attractive to us then thinking of Entries and Clusters and Elements and Items. It's easy to know the difference between an Entity and an Act. It's not so obvious the difference between Clusters, Entries, Items and Elements.
They are all kinds of tree branches, and we don't even think in terms of trees or documents. A clinical statement, on the other hand, to us, is much easier to know intuitively what is the Entity, what is the Role and What is the Act. We can do trees and documents too, but the molecule of the clinical statement is a very nice way to model. The Acts Participations, Roles and Entities do not have to be HL7 RIM ones, but that construct is how we think.
BTW, I would rather we called them Dog and Cat, I like those names.
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
From: Thomas Beale <thomas...@oceaninformatics.com>
To: cimi-modelli...@googlegroups.com
Date: 01/30/2013 09:14 AM
Subject: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
Sent by: cimi-modelli...@googlegroups.com
Thomas Beale
Tom,
Of course we are in CIMI not natural language processors. But the design stage in our work at CIMI should ONLY deal with the logical aspects of concepts, data elements, code binding, data type and relationships. And we do need a format to do this.
However, fixing the format to ADL is fine as long we do allow transforms to other formats, can move it to various technologies and are not forced into irrelevant technical artefacts as at codes or limited worldview reference models that support only one very specific implementation.
ADL is designed to allow that to happen and to support it. There is a small-ish change I still have to do to enable the code_phrase / ordinals etc binding thing to work properly, and I am sorry it has taken longer to get done than I had expected - I have been buried on other projects. It will be done soon. Anyway, we designed ADL from the outset to enable absolutely any RM, so I don't think we can do better than that.
I don't think we should get too worked about about the 'at-codes'. There have to be some kind of codes there. I actually foresee a day where we move on to some other kind of code, but we there is no obvious single candidate. Snomed codes might technically make sense, but I think much wider discussions are needed before we go there. OBO Foundry ontology codes / ids are another candidate. If we one day make such a move, I would expect it is with fairly wide input and agreement. That will take time. Then we would machine re-process the existing archetypes, and voila, no more at-codes. Until then, we use them. They have two big advantages right now: a) they are very short, and b) the subsumption relationships are built into the codes, which means we avoid any dependence on external terminology services and semantics.
Transformations are fine, I am all in favour of them. We have quite a few based on the Operational Template (OPT) - including programming facades (Java, C#) and XSDs. Many more are possible.
Finally, convergence with the MDHT work is progressing (a bit slowly but it will get there). So the result will be a growing set of tools all converging on the same underlying formalism (which itself will be improved a bit on the way, as we discover more).
I think this is a reasonable path for the future.
- thomas
Thomas Beale
We do use reference models (KP) but we don't need headers or anything like a document. We can use a model that has Entities in Roles Participating in Acts. And Acts related to other Acts.
And Observations being kinds of Acts. It's much easier for us to think that way rather than thinking in terms of tree structures and document structures.
The headers and subsections are very much like document structures and we do not necessarily need to think of things as documents. The HL7 clinical statement is more how we think of things. I am not saying it is the HL7 RIM. But the general idea of Entities in Roles Participating in Acts and Acts related to Acts is a lot more attractive to us then thinking of Entries and Clusters and Elements and Items. It's easy to know the difference between an Entity and an Act. It's not so obvious the difference between Clusters, Entries, Items and Elements.
- thomas
Peter....@kp.org
If we then forget for the moment the participants and roles and entities and then concentrate only on the Observations, then we still don't use clusters or entries or items or elements.
There is context in the observation (like date etc) and there is a root code (what are we observing, usually a SNOMED code) and sometimes we need a value (often a PQ or it could also be a SNOMED code). If we need to combine them into groups, we don't need to decide if they are clusters or items or entries, we can just use a container Act.
There are two ways of looking at the same thing. What comes natural to archetype people is not natural to Act/Observation people, and visa versa.
I think we might agree on this. For a machine to compare two models, RDF, OWL or some form of triples is best. The reason we don't represent it to modelers that way is for the reason you stated a few emails ago, it is not the easiest way for people to think about it.
If we could (because we're not regular people) come up with the the underlying triples, then we could use them and map up to what the different people want to see.
There would be one map to the ADL/archetype way of thinking, and another map to the Observation (Act class clone) way of thinking.
The people who "think in archetypes" and the people who "think in Acts and Observations" could model the way they like and there would be a common (triplet) based way of storing the common relationships and model nodes.
Rather then start with archetypes and Act/Observations, and then try to find a common way to represent them (top down), maybe we should first discover the triplets, and then map "up" to these two ways of thinking.
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
From: Thomas Beale <thomas...@oceaninformatics.com>
To: cimi-modelli...@googlegroups.com
Date: 01/30/2013 12:44 PM
Subject: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
Sent by: cimi-modelli...@googlegroups.com
Cecil O. Lynch, MD, MS
Peter,
I do believe this is exactly what I brought up at the Kaiser hosted meeting many months ago that got no traction. I completely agree with you and tried to also make this point on the Terminology call yesterday as we start to think about how we store all terminology models. You can combine the RDF graphs any way you want without losing the overall semantics. I think this is attractive but I also think you and I and (probably Josh) are in the minority.
As such, there is nothing that should make us push the majority off their platform preferences as we can do the mappings on our own and host an alternative expression and let the "CIMI market place" make the decision.
Cecil
Thomas Beale
At the last CIMI meeting we were talking about the "demographics model" which had "parties, roles and actors", so all of my comments about the entities in roles participating in acts are more related to that subject then what happens "inside the observation".
If we then forget for the moment the participants and roles and entities and then concentrate only on the Observations, then we still don't use clusters or entries or items or elements.
There is context in the observation (like date etc) and there is a root code (what are we observing, usually a SNOMED code) and sometimes we need a value (often a PQ or it could also be a SNOMED code). If we need to combine them into groups, we don't need to decide if they are clusters or items or entries, we can just use a container Act.
There are two ways of looking at the same thing. What comes natural to archetype people is not natural to Act/Observation people, and visa versa.
I think we might agree on this. For a machine to compare two models, RDF, OWL or some form of triples is best. The reason we don't represent it to modelers that way is for the reason you stated a few emails ago, it is not the easiest way for people to think about it.
If we could (because we're not regular people) come up with the the underlying triples, then we could use them and map up to what the different people want to see.
There would be one map to the ADL/archetype way of thinking, and another map to the Observation (Act class clone) way of thinking.
The people who "think in archetypes" and the people who "think in Acts and Observations" could model the way they like and there would be a common (triplet) based way of storing the common relationships and model nodes.
Rather then start with archetypes and Act/Observations, and then try to find a common way to represent them (top down), maybe we should first discover the triplets, and then map "up" to these two ways of thinking.
- for clinical people who build the models, we hide these classes (no matter what they are) anyway, so their names don't matter that much
- when the classes start to matter, i.e. in realistic data transformation situations, in fact Cluster/Element and Act are not equivalent - the details of the models become apparent and the mapping is no longer based on synonyms, but something far more complex.
Usually model-model mappings are performed by expressing models
in a common meta-model language, like the UML/MOF approach (we do
a similar thing in the archetype workbench to enable any RM to be
imported). Representing information models as triples is doing
this, using a semantic net approach, and the outcome is that you
can potentially do some mapping on an ontological basis.
These are methods. However, there is no escaping the need to
actually find and express mappings, if that is the job at hand.
And for models with vastly different design bases, this is never
easy. It does potentially become possible if for a given content
model, only a small portion of the reference model is being used.
This is what enabled us to find some initial mappings between
Intermountain's CEMs and archetypes based on openEHR.
I probably missed the relevant posts that explained the specific
mapping requirement to be solved here - can someone point them
out?
- thomas
Peter....@kp.org
It's worth exploring.
Not just the terminology, which I'd say is already done and is the SNOMED model. but the CIMI information model in triplets. Then we can map "up" to both the archetype and the Act/Observation way of looking at it.
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
Peter....@kp.org
>>>>>
it depends on what you are trying to achieve here. If the job is to regenerate an archetype based on CIMI (containing Cluster, Element etc) as a RIM-based data structure (containing Act, ActRelationship), a trivial form of this can be achieved by simply supporting class synonymy in the tools. I don't however see the value of this because:
It's not the way we think of it or use it at any time in the life cycle of our models. It's unnecessary internally to "go there" with our current modeling framework. We are able to do what we need, from beginning to end without ever touching a "CIMI archetype containing Clusters Elements etc".
Many of the CIMI participants have pre existing ways of making models, and many of them never use archetypes of any kind. It is a burden to have to figure out how to map our non CIMI non ADL, non archetype, models with no Elements or Clusters or (in case of demographics Parties). The CIMI proposal of an archetype based model with Clusters and elements is one particular way of modeling that CEN and openEHR have chosen, but it's not a way that many of us model. The "new" idea was to go to a more neutral form that would be easier for all to map to, and not force us to make archetypes with Clusters and Elements, items, Entries, etc.
If as you say above, they really are the same, then lets use the Acts and Act containers. If they are different, then rather then everyone having to change over to archetypes , then some of us would rather have a more neutral formalism that is not so different from what we currently do.
This could all go away if it were possible (it might not be possible) for someone to write a utility that can reliably translate these two different ways of modeling. Then we could continue what we do now, and have it automatically turned into "CIMI archetypes" for the users who like it that way. But we wouldn't need the models in the "CIMI archetype" form.
Probably Stan (this is dangerous but I'll assume, not sure he even has time to read this stuff) is going to continue using his own format for models internally. I'm guessing (correct me if I'm wrong anyone) they will not be using "CIMI archetype based models with Clusters and Elements" internally. So for his models to be turned into "CIMI archetypes based models with Clusters and Elements" (Let's see that would be CABMWCAE) there would have to be a transform. Who will write that transform, and can it be written in such a way to work in most cases?
Perhaps we should check how many members internally use "CABMWCAE" and how many use RIM like UML, and how many use neither. The CABMWCAE is definitely one specific approach, and not such an easy one to map our internal models to. It will be quite a lot of work to map our models to that formalism. And since we don't need that formalism internally, I'm not sure we'd be allocating resources to do that hard work.
Finally, even though we do not use the same kind of models Intermountain (Stan) uses. When I look at the samples of his models, I could more easily map our RIM models to that formalism then I could map them to CABMWCAE.
The UML tools that Dave is working on don't really address this more basic problem. If the UML itself has the same Cluster Element Item etc classes. It's the model itself.
I'm sure I'm the only one who thinks this way, but I seem to be the main squeaky wheel. I'm hoping to fix this before the cement dries. Maybe it's too late.
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
From: Thomas Beale <thomas...@oceaninformatics.com>
To: cimi-modelli...@googlegroups.com
Date: 01/30/2013 04:37 PM
Subject: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
Sent by: cimi-modelli...@googlegroups.com
- thomas
William Goossen
You should not forget that we prefer UML / RIM like structures, but without the technical specs in it, just the logics for (series of) data elements, code bindings and data type expressions, together with their relationships.
Vriendelijke groet,
William Goossen
Verzonden met mijn Winphone Nokia Lumia 800
Van: Cecil O. Lynch, MD, MS
Verzonden: 31-1-2013 1:24
Aan: cimi-modelli...@googlegroups.com
Onderwerp: RE: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
Peter,
I do believe this is exactly what I brought up at the Kaiser hosted meeting many months ago that got no traction. I completely agree with you and tried to also make this point on the Terminology call yesterday as we start to think about how we store all terminology models. You can combine the RDF graphs any way you want without losing the overall semantics. I think this is attractive but I also think you and I and (probably Josh) are in the minority.
As such, there is nothing that should make us push the majority off their platform preferences as we can do the mappings on our own and host an alternative expression and let the "CIMI market place" make the decision.
Cecil
From: cimi-modelli...@googlegroups.com [mailto:cimi-modelli...@googlegroups.com] On Behalf Of Peter....@kp.org
Sent: Wednesday, January 30, 2013 2:50 PM
To: cimi-modelli...@googlegroups.com
Subject: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
At the last CIMI meeting we were talking about the "demographics model" which had "parties, roles and actors", so all of my comments about the entities in roles participating in acts are more related to that subject then what happens "inside the observation".
If we then forget for the moment the participants and roles and entities and then concentrate only on the Observations, then we still don't use clusters or entries or items or elements.
There is context in the observation (like date etc) and there is a root code (what are we observing, usually a SNOMED code) and sometimes we need a value (often a PQ or it could also be a SNOMED code). If we need to combine them into groups, we don't need to decide if they are clusters or items or entries, we can just use a container Act.
There are two ways of looking at the same thing. What comes natural to archetype people is not natural to Act/Observation people, and visa versa.
I think we might agree on this. For a machine to compare two models, RDF, OWL or some form of triples is best. The reason we don't represent it to modelers that way is for the reason you stated a few emails ago, it is not the easiest way for people to think about it.
If we could (because we're not regular people) come up with the the underlying triples, then we could use them and map up to what the different people want to see.
There would be one map to the ADL/archetype way of thinking, and another map to the Observation (Act class clone) way of thinking.
The people who "think in archetypes" and the people who "think in Acts and Observations" could model the way they like and there would be a common (triplet) based way of storing the common relationships and model nodes.
Rather then start with archetypes and Act/Observations, and then try to find a common way to represent them (top down), maybe we should first discover the triplets, and then map "up" to these two ways of thinking.
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
From: Thomas Beale <thomas...@oceaninformatics.com>
To: cimi-modelli...@googlegroups.com
Date: 01/30/2013 12:44 PM
Subject: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
Sent by: cimi-modelli...@googlegroups.com
On 30/01/2013 19:50, Peter....@kp.org wrote:
We do use reference models (KP) but we don't need headers or anything like a document. We can use a model that has Entities in Roles Participating in Acts. And Acts related to other Acts.
I'm pretty sure everyone has that ;-)
And Observations being kinds of Acts. It's much easier for us to think that way rather than thinking in terms of tree structures and document structures.
well acts and participants aren't much use in modelling the main data of a microbiology result, or a GTT, or another 3000 common clinical recordings. And most often, they are not constrained at design time anyway, since they will be set to who/when/where as appropriate at runtime. So I am not clear on why roles and participations are of that great an importance in archetype modelling. We do routinely constrain them in some places, but in terms of numbers of model elements constrained, they are a minority.
The headers and subsections are very much like document structures and we do not necessarily need to think of things as documents. The HL7 clinical statement is more how we think of things. I am not saying it is the HL7 RIM. But the general idea of Entities in Roles Participating in Acts and Acts related to Acts is a lot more attractive to us then thinking of Entries and Clusters and Elements and Items. It's easy to know the difference between an Entity and an Act. It's not so obvious the difference between Clusters, Entries, Items and Elements.
see the Adverse Reaction example in the previous post. There are 21 data element nodes, 4 internal nodes (Clusters) and one clinical statement (the root Evaluation). How does role/participation/act help here?
- thomas
--
You received this message because you are subscribed to the Google Groups "cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send an email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send an email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
William Goossen
Vriendelijke groet,
William Goossen
Verzonden met mijn Winphone Nokia Lumia 800
Van: Peter....@kp.org
Verzonden: 31-1-2013 5:13
Aan: cimi-modelli...@googlegroups.com
Onderwerp: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
>>>actually it's the same thing. IN the structures you talk about, it happens that you re-use Act as a data node, and ActRelationship as a joining element (all RIM modelling works like this, because there are no dedicated data structure building classes). In other works these perform the same role as Clusters and Elements.
If they are the same thing, then some of us would rather use the RIM modeling in the first place. Using Acts as data nodes and ActRelationships as joining elements is much more attractive to me.
>>>>>
it depends on what you are trying to achieve here. If the job is to regenerate an archetype based on CIMI (containing Cluster, Element etc) as a RIM-based data structure (containing Act, ActRelationship), a trivial form of this can be achieved by simply supporting class synonymy in the tools. I don't however see the value of this because:
That's not what I would be trying to do. I'd be trying to model first in a RIM based way, and then it can be stored in another form. but I wouldn't have any use for the "CIMI" form with Clusters Elements etc". If someone needed it in that form they could make a transform, but some of us would never need it in that form. Many of us would not be trying to "regenerate an archetype based on CIMI (containing Cluster, Element etc)" because we'd have no use for it.
It's not the way we think of it or use it at any time in the life cycle of our models. It's unnecessary internally to "go there" with our current modeling framework. We are able to do what we need, from beginning to end without ever touching a "CIMI archetype containing Clusters Elements etc".
Many of the CIMI participants have pre existing ways of making models, and many of them never use archetypes of any kind. It is a burden to have to figure out how to map our non CIMI non ADL, non archetype, models with no Elements or Clusters or (in case of demographics Parties). The CIMI proposal of an archetype based model with Clusters and elements is one particular way of modeling that CEN and openEHR have chosen, but it's not a way that many of us model. The "new" idea was to go to a more neutral form that would be easier for all to map to, and not force us to make archetypes with Clusters and Elements, items, Entries, etc.
If as you say above, they really are the same, then lets use the Acts and Act containers. If they are different, then rather then everyone having to change over to archetypes , then some of us would rather have a more neutral formalism that is not so different from what we currently do.
This could all go away if it were possible (it might not be possible) for someone to write a utility that can reliably translate these two different ways of modeling. Then we could continue what we do now, and have it automatically turned into "CIMI archetypes" for the users who like it that way. But we wouldn't need the models in the "CIMI archetype" form.
Probably Stan (this is dangerous but I'll assume, not sure he even has time to read this stuff) is going to continue using his own format for models internally. I'm guessing (correct me if I'm wrong anyone) they will not be using "CIMI archetype based models with Clusters and Elements" internally. So for his models to be turned into "CIMI archetypes based models with Clusters and Elements" (Let's see that would be CABMWCAE) there would have to be a transform. Who will write that transform, and can it be written in such a way to work in most cases?
Perhaps we should check how many members internally use "CABMWCAE" and how many use RIM like UML, and how many use neither. The CABMWCAE is definitely one specific approach, and not such an easy one to map our internal models to. It will be quite a lot of work to map our models to that formalism. And since we don't need that formalism internally, I'm not sure we'd be allocating resources to do that hard work.
Finally, even though we do not use the same kind of models Intermountain (Stan) uses. When I look at the samples of his models, I could more easily map our RIM models to that formalism then I could map them to CABMWCAE.
The UML tools that Dave is working on don't really address this more basic problem. If the UML itself has the same Cluster Element Item etc classes. It's the model itself.
I'm sure I'm the only one who thinks this way, but I seem to be the main squeaky wheel. I'm hoping to fix this before the cement dries. Maybe it's too late.
From: Thomas Beale <thomas...@oceaninformatics.com>
To: cimi-modelli...@googlegroups.com
Date: 01/30/2013 04:37 PM
Subject: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
Sent by: cimi-modelli...@googlegroups.com
At the last CIMI meeting we were talking about the "demographics model" which had "parties, roles and actors", so all of my comments about the entities in roles participating in acts are more related to that subject then what happens "inside the observation".
If we then forget for the moment the participants and roles and entities and then concentrate only on the Observations, then we still don't use clusters or entries or items or elements.
There is context in the observation (like date etc) and there is a root code (what are we observing, usually a SNOMED code) and sometimes we need a value (often a PQ or it could also be a SNOMED code). If we need to combine them into groups, we don't need to decide if they are clusters or items or entries, we can just use a container Act.
There are two ways of looking at the same thing. What comes natural to archetype people is not natural to Act/Observation people, and visa versa.
actually it's the same thing. IN the structures you talk about, it happens that you re-use Act as a data node, and ActRelationship as a joining element (all RIM modelling works like this, because there are no dedicated data structure building classes). In other works these perform the same role as Clusters and Elements.
I think we might agree on this. For a machine to compare two models, RDF, OWL or some form of triples is best. The reason we don't represent it to modelers that way is for the reason you stated a few emails ago, it is not the easiest way for people to think about it.
If we could (because we're not regular people) come up with the the underlying triples, then we could use them and map up to what the different people want to see.
There would be one map to the ADL/archetype way of thinking, and another map to the Observation (Act class clone) way of thinking.
The people who "think in archetypes" and the people who "think in Acts and Observations" could model the way they like and there would be a common (triplet) based way of storing the common relationships and model nodes.
Rather then start with archetypes and Act/Observations, and then try to find a common way to represent them (top down), maybe we should first discover the triplets, and then map "up" to these two ways of thinking.
it depends on what you are trying to achieve here. If the job is to regenerate an archetype based on CIMI (containing Cluster, Element etc) as a RIM-based data structure (containing Act, ActRelationship), a trivial form of this can be achieved by simply supporting class synonymy in the tools. I don't however see the value of this because:
- for clinical people who build the models, we hide these classes (no matter what they are) anyway, so their names don't matter that much
- when the classes start to matter, i.e. in realistic data transformation situations, in fact Cluster/Element and Act are not equivalent - the details of the models become apparent and the mapping is no longer based on synonyms, but something far more complex.
These are methods. However, there is no escaping the need to actually find and express mappings, if that is the job at hand. And for models with vastly different design bases, this is never easy. It does potentially become possible if for a given content model, only a small portion of the reference model is being used. This is what enabled us to find some initial mappings between Intermountain's CEMs and archetypes based on openEHR.
I probably missed the relevant posts that explained the specific mapping requirement to be solved here - can someone point them out?
- thomas
Daniel Karlsson
I suspect there are some serious apples-and-oranges going on. If comparing the RIM-like approach to the current CIMI approach, one should compare the RIM classes to the CIMI patterns, e.g. OBSERVATION class to the Observation pattern (through the Observation ENTRY archetype), ACT to Action etc. Not everything will be exactly lined up, things are probably still missing on the CIMI side etc., but at least the comparison is on the same (or similar!) level.
/Daniel
Thomas Beale
>>>actually it's the same thing. IN the structures you talk about, it happens that you re-use Act as a data node, and ActRelationship as a joining element (all RIM modelling works like this, because there are no dedicated data structure building classes). In other works these perform the same role as Clusters and Elements.
If they are the same thing, then some of us would rather use the RIM modeling in the first place. Using Acts as data nodes and ActRelationships as joining elements is much more attractive to me.
>>>>>
it depends on what you are trying to achieve here. If the job is to regenerate an archetype based on CIMI (containing Cluster, Element etc) as a RIM-based data structure (containing Act, ActRelationship), a trivial form of this can be achieved by simply supporting class synonymy in the tools. I don't however see the value of this because:
That's not what I would be trying to do. I'd be trying to model first in a RIM based way, and then it can be stored in another form. but I wouldn't have any use for the "CIMI" form with Clusters Elements etc". If someone needed it in that form they could make a transform, but some of us would never need it in that form. Many of us would not be trying to "regenerate an archetype based on CIMI (containing Cluster, Element etc)" because we'd have no use for it.
Some people might want to work with the RIM, but in CIMI, that is a transform away from the main activity, which is itself far from complete.
It's not the way we think of it or use it at any time in the life cycle of our models. It's unnecessary internally to "go there" with our current modeling framework. We are able to do what we need, from beginning to end without ever touching a "CIMI archetype containing Clusters Elements etc".
Many of the CIMI participants have pre existing ways of making models, and many of them never use archetypes of any kind. It is a burden to have to figure out how to map our non CIMI non ADL, non archetype, models with no Elements or Clusters or (in case of demographics Parties). The CIMI proposal of an archetype based model with Clusters and elements is one particular way of modeling that CEN and openEHR have chosen, but it's not a way that many of us model. The "new" idea was to go to a more neutral form that would be easier for all to map to, and not force us to make archetypes with Clusters and Elements, items, Entries, etc.
Now, as far as RM concepts go, an Entry is just a clinical statement, and everyone using openEHR, 13606, and Clinical Statement Pattern agree on this concept. Cluster and Element are just data structure building classes, containing virtually no attributes of their own. As you have already noted, you work with Act / ActRel to perform this job (the job doesn't go away). One of the things you must be doing is to remove nearly all of Act's 23 properties and ActRelationships 18 properties that are irrelevant inside typical clinical information structures containing numerous related elements (in CSP, most are removed). Or it may be that you don't use any models of this level of detail.
If as you say above, they really are the same, then lets use the Acts and Act containers. If they are different, then rather then everyone having to change over to archetypes , then some of us would rather have a more neutral formalism that is not so different from what we currently do.
This could all go away if it were possible (it might not be possible) for someone to write a utility that can reliably translate these two different ways of modeling. Then we could continue what we do now, and have it automatically turned into "CIMI archetypes" for the users who like it that way. But we wouldn't need the models in the "CIMI archetype" form.
Probably Stan (this is dangerous but I'll assume, not sure he even has time to read this stuff) is going to continue using his own format for models internally. I'm guessing (correct me if I'm wrong anyone) they will not be using "CIMI archetype based models with Clusters and Elements" internally. So for his models to be turned into "CIMI archetypes based models with Clusters and Elements" (Let's see that would be CABMWCAE) there would have to be a transform. Who will write that transform, and can it be written in such a way to work in most cases?
Perhaps we should check how many members internally use "CABMWCAE" and how many use RIM like UML, and how many use neither.
The CABMWCAE is definitely one specific approach, and not such an easy one to map our internal models to. It will be quite a lot of work to map our models to that formalism. And since we don't need that formalism internally, I'm not sure we'd be allocating resources to do that hard work.
Finally, even though we do not use the same kind of models Intermountain (Stan) uses. When I look at the samples of his models, I could more easily map our RIM models to that formalism then I could map them to CABMWCAE.
The UML tools that Dave is working on don't really address this more basic problem. If the UML itself has the same Cluster Element Item etc classes. It's the model itself.
I'm sure I'm the only one who thinks this way, but I seem to be the main squeaky wheel. I'm hoping to fix this before the cement dries. Maybe it's too late.
- thomas
Jay Lyle
--
You received this message because you are subscribed to the Google Groups "cimi-modelling-taskforce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cimi-modelling-tas...@googlegroups.com.
To post to this group, send an email to cimi-modelli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cimi-modelling-taskforce?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
Thomas Beale
> The issue I see is how to determine formalism-specific
> questions--e.g., whether a container resource at the triple layer is
> resolved in HL7 into a container act or an organizer or a section, or
> in CIMI into a cluster or entry. Triples look atomic, but they still
> have to address secondary and tertiary structure, to strain the
> molecular metaphor.
Just like a human being comes from a massive list of base pairs and
methylation markers. Never be fooled by an atomised representation of a
complex structure.
- thomas
Peter....@kp.org
I think it would be very valuable to see this done. If that's that case, that it's really not so hard to model the way you want, and then "save as" something else it would satisfy my concerns
I hope we can have you walk us through a demo. Then we can model as you do in "clean UML".
NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
From: William Goossen <wgoo...@results4care.nl>
To: "cimi-modelli...@googlegroups.com" <cimi-modelli...@googlegroups.com>
Date: 01/30/2013 10:27 PM
Subject: RE: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
Sent by: cimi-modelli...@googlegroups.com
Vriendelijke groet,
William Goossen
Verzonden met mijn Winphone Nokia Lumia 800
Van: Peter....@kp.org
Verzonden: 31-1-2013 5:13
Aan: cimi-modelli...@googlegroups.com
Onderwerp: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
>>>actually it's the same thing. IN the structures you talk about, it happens that you re-use Act as a data node, and ActRelationship as a joining element (all RIM modelling works like this, because there are no dedicated data structure building classes). In other works these perform the same role as Clusters and Elements.
If they are the same thing, then some of us would rather use the RIM modeling in the first place. Using Acts as data nodes and ActRelationships as joining elements is much more attractive to me.
>>>>>
it depends on what you are trying to achieve here. If the job is to regenerate an archetype based on CIMI (containing Cluster, Element etc) as a RIM-based data structure (containing Act, ActRelationship), a trivial form of this can be achieved by simply supporting class synonymy in the tools. I don't however see the value of this because:
That's not what I would be trying to do. I'd be trying to model first in a RIM based way, and then it can be stored in another form. but I wouldn't have any use for the "CIMI" form with Clusters Elements etc". If someone needed it in that form they could make a transform, but some of us would never need it in that form. Many of us would not be trying to "regenerate an archetype based on CIMI (containing Cluster, Element etc)" because we'd have no use for it.
It's not the way we think of it or use it at any time in the life cycle of our models. It's unnecessary internally to "go there" with our current modeling framework. We are able to do what we need, from beginning to end without ever touching a "CIMI archetype containing Clusters Elements etc".
Many of the CIMI participants have pre existing ways of making models, and many of them never use archetypes of any kind. It is a burden to have to figure out how to map our non CIMI non ADL, non archetype, models with no Elements or Clusters or (in case of demographics Parties). The CIMI proposal of an archetype based model with Clusters and elements is one particular way of modeling that CEN and openEHR have chosen, but it's not a way that many of us model. The "new" idea was to go to a more neutral form that would be easier for all to map to, and not force us to make archetypes with Clusters and Elements, items, Entries, etc.
If as you say above, they really are the same, then lets use the Acts and Act containers. If they are different, then rather then everyone having to change over to archetypes , then some of us would rather have a more neutral formalism that is not so different from what we currently do.
This could all go away if it were possible (it might not be possible) for someone to write a utility that can reliably translate these two different ways of modeling. Then we could continue what we do now, and have it automatically turned into "CIMI archetypes" for the users who like it that way. But we wouldn't need the models in the "CIMI archetype" form.
Probably Stan (this is dangerous but I'll assume, not sure he even has time to read this stuff) is going to continue using his own format for models internally. I'm guessing (correct me if I'm wrong anyone) they will not be using "CIMI archetype based models with Clusters and Elements" internally. So for his models to be turned into "CIMI archetypes based models with Clusters and Elements" (Let's see that would be CABMWCAE) there would have to be a transform. Who will write that transform, and can it be written in such a way to work in most cases?
Perhaps we should check how many members internally use "CABMWCAE" and how many use RIM like UML, and how many use neither. The CABMWCAE is definitely one specific approach, and not such an easy one to map our internal models to. It will be quite a lot of work to map our models to that formalism. And since we don't need that formalism internally, I'm not sure we'd be allocating resources to do that hard work.
Finally, even though we do not use the same kind of models Intermountain (Stan) uses. When I look at the samples of his models, I could more easily map our RIM models to that formalism then I could map them to CABMWCAE.
The UML tools that Dave is working on don't really address this more basic problem. If the UML itself has the same Cluster Element Item etc classes. It's the model itself.
I'm sure I'm the only one who thinks this way, but I seem to be the main squeaky wheel. I'm hoping to fix this before the cement dries. Maybe it's too late.
Mark shafarman
This would truly be a valuable way forward... I'm in favor of having a 'neutral' formalism that can be shared by several approaches... if we can achieve that, then a) we can truly share models, and b) we have a (hopefully computable) way towards semantic interoperability across the approaches (i.e. each approach should be able to do one type of translation/transformation to/from the neutral formalism... ). If we continue to do a similar neutral approach with semantic node binding, we will also encourage the use of description logic capabilities in sharing the models being created.
kind regards,
Mark
Gerard Freriks
Linda Bird (MOHH)
Dear all,
The draft agenda for this week’s meetings are:
CIMI Terminology & Tooling Subgroup meeting (Tuesday 20:00 – 22:00 UTC)
· Terminology binding
o Laboratory Test Request Summary
o Laboratory Test Observable
CIMI Modelling Taskforce meeting (Thursday 20:00 – 22:00 UTC)
· Weekly News & Updates
· Feedback
· CIMI Reference Model Review (if Michael is ready)
· Review of Demographics Comparative Analysis spreadsheet & models
o Electronic Contact
o Party, Actor Role
o Person, Organiation
o Patient
Please note that next week, we are planning to continue with the Tooling discussions during the Terminology & Tooling Subgroup meeting, and to start looking at possible approaches to Transformation and Model Mapping during the Thursday MTF meeting.
Regards,
Linda.
Dr Linda Bird
Information Architect Information Systems Division
mobile +61 411 274 870 skype linda.j.bird
|
|
MOH Holdings Pte Ltd 1 Maritime Square (Lobby C) #11-25 Harbourfront Centre Singapore 099253 www.mohh.com.sg |
Please consider the environment before printing this email.
This email may contain privileged/confidential information. If you are not the intended recipient, please notify the sender immediately, and delete this email and any record or copy from your system. You should not use, disclose, copy, distribute or retain the contents of this email or any part of it, including, but not limited to its attachments. The sender reserves all rights. Thank you.
William Goossen
Dear all,
I am still concerned that what we loosely call reference model, and in particular the one we created for CIMI is leading us toooo much into the implementation space. In particular as we state, like Gerard does for example, that the RM is a mix or sibling of 13606 / OpenEHR / CDA. All these have in common the very snapshot oriented approach for data, with specific ICT implementations in mind. Nothing wrong with that per se, but we need to move up one level of abstraction. I do respect that we need one formalism to express ourselves, but think we are still forcing us too much into a direction of specific implementations, where the intent is to keep the models pure and implementable in various reference models and technology, without having to redo all the work.
I challenge that we need any reference model to create proper clinical models. I do realize that for specific implementations into national health systems, or EHR systems or communications, we do need a reference (information) model that facilitates consistent and safe application of clinical models. But again that is implementation specifics.
I’d rather review our current ICT centric reference model approach to a more generic, logical model approach from which implementation specifications can be derived easily by simply adding what is required for a specific reference (information) model.
vriendelijke groet,
dr. William T.F. Goossen
directeur Results 4 Care B.V.
De Stinse 15
3823 VM Amersfoort
the Netherlands
telefoon +31654614458
e-mail: wgoo...@results4care.nl
skype: williamgoossenmobiel
kamer van koophandel 31133713
http://results4care.wikispaces.com/
http://www.linkedin.com/company/711047
https://www.facebook.com/Results4Care
brochure Detailed Clinical Models:
From: cimi-modelli...@googlegroups.com [mailto:cimi-modelli...@googlegroups.com] On Behalf Of Gerard Freriks
Sent: vrijdag 1 februari 2013 9:17
To: cimi-modelli...@googlegroups.com
Subject: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
For some time we are working on (and promoting):
--
Gerard Freriks
Gerard Freriks
Thomas Beale
William,
what you are expressing is actually an alternative theory of doing health informatics. It says:
- we need to model EHR / clinical content as an activity in itself
- this activity should be self-standing and have nothing to do with any specific implementations
- these models would then be converted to target implementation technologies / products by various transformation engines
It sounds superficially nice. But if you have a need for: a)
data interoperability b) data stability, and c) query
portability then it's going to make life real hard. The approach
above implies every implementation technology / community can
just do what they like, and completely ignore each other. But we
already know that that won't work - even just to share atomic
data objects, we need standardisation on data types. We need
quite a bit more. The basic structures common to CDA, 13606 and
openEHR - i.e. Composition (= CDA:Document) / Section / Entry /
low-level structure building elements - aren't arbitrary. They
correspond to some real world basics:
- A document corresponding to an encounter or other patient / health system interaction; corresponds to the user 'commit' action, and audit level
- Headings (multi-level) - health carers like everyone else in humanity likes to organise their information
- Clinical statements - an indivisible lump of clinical information that says one clinical thing
- the fine-grained structure of the statement, e.g. the bits and pieces of a lab result.
So standardisation, even from different sides has agreed pretty
much on this. And the data type needs are well recognised,
although we still lack a good standard (but there are some
working things available).
So your approach is essentially saying - throw this away, we
need more freedom.
I think for the EHR space, this is a bad idea. I am not saying
this is the only reference model in the world and I recognise
some other reference models will need to exist (demographics,
workflow, research study data sets...).
But it seems inconceivable to me that any clinical model
wouldn't belong to a family of models, and be based on some
underlyng common semantics - which is what a 'reference model'
provides.
Once you throw away any reference model at all, then you throw
out any ability to reason about data in a standard way -
everything becomes a custom case. You also make all model =>
impleementation mappings a custom work.
I won't say no other approach is possible; indeed, the 'no RM'
approach is the approach of the web 2.0 community works like
that for the basic reason that in general it can't assume
anything about the data. I think it's an unlikely source of
high-volume high-transaction rate EHR solutions however.
- thomas
On 05/02/2013 12:14, William Goossen wrote:
William Goossen
Ha Tom,
Nice reply and totally out of the order that I would not like to standardize at all. I am working for more than 30 years in various standardization efforts and think I know its value and its limitations as well.
I do want that freedom yes, but I do realize we need all the stuff you list below. And that is basically what is in the ISO DTS for Detailed Clinical Modeling. NO MORE than that however. And the moment I see at0007 codes, or MoodCode EVN and such (which are two of the basic reference models floating around in EHR and and communication land), then I say stop.
So if all these basic things you list below are also to be called reference model, then I think the confusion about what a reference model is pops up even more, but your listing of criteria for proper clinical models are some of the basics I have been fighting for the last 15 years. Yes, information must be organize able. However, I learned in 30+ years of nursing theory that every time some expert in the field comes up with new organization of the information for professional reasons. And each have a proper underpinning and each ends up to have slightly different categories under which the information is organized. However, if you drill down to your list below (data elements, data type, value set expression, binding to unique semantic codes) e.g. the nodes / clinical statements, all such information remains the same over centuries. So I have a strong preference to limit ourselves to the 20 or so basic characteristics of the data elements, their relationship, their use in 1-n organizing principles, their use in 1-n professional processes (not only the problem oriented approach indicated by observation, evaluation and such),and more.
The moment we prescribe the record structure even in abstracto like 13606-1, we are potentially limiting the flexibility of reorganizing the 1-n detailed clinical models that in itself are 100% standardized into clinical relevant structures and pathways.
An anology. I like to standardize the currencies around the world (Euro, Dollars, Won, Frank, Kroner, Rand and more). Each will get the internationally agreed abbreviation (USD, EUR) and their symbols €, $, £, ¥ and more. And the conversions according to rules and daily/ hourly, minutely changing figures is still part of the standard.
A next step is that you want to standardize how a legal bill must look like (including company number, tax number, service or product delivered amount, price per unit, subtotal and so on).
This are basic rules that would follow the minimum required to understand a bill.
However, what Reference Models try to do is determine what services and products in what order and which code must be on the bills and prescribe the currency.
I would really love CIMI to continue setting the criteria for clinical models, but why do we not call the format they must be in, and which represents some of the standardize able bits you list below, something else than a reference model. We have alternatives like Model Format, Model Design Pattern, Model Requirements (MR is better than RM J), or similar. The we are sending out a precise message that we create models that adhere to standardized patterns, but are not confusing the world by introducing yet another Reference Model.
So if I say no RM, I absolutely do not mean we do not need to standardize. But we are standardizing a profile for CIMI models, nothing more, we are not recreating an LMR, a RIM or a RM.
And this is still confusing to the world and people I meet.
Thanks for your reply!
William
From: cimi-modelli...@googlegroups.com [mailto:cimi-modelli...@googlegroups.com] On Behalf Of Thomas Beale
Sent: dinsdag 5 februari 2013 14:40
To: cimi-modelli...@googlegroups.com
Subject: Re: [cimi-modelling-taskforce] Comments on the sample spreadsheet template.
--
Thomas Beale
Ha Tom,
Nice reply and totally out of the order that I would not like to standardize at all. I am working for more than 30 years in various standardization efforts and think I know its value and its limitations as well.
I do want that freedom yes, but I do realize we need all the stuff you list below. And that is basically what is in the ISO DTS for Detailed Clinical Modeling. NO MORE than that however. And the moment I see at0007 codes, or MoodCode EVN and such (which are two of the basic reference models floating around in EHR and and communication land), then I say stop.
That's obviously silly. If we want computability, we need formalisation. Formalising requires marking things unequivocally in ways that computers can understand. That means codes of some kind, where codes are mapped to some kind of meanings in the human world. There's no escape from this.
So if all these basic things you list below are also to be called reference model, then I think the confusion about what a reference model is pops up even more, but your listing of criteria for proper clinical models are some of the basics I have been fighting for the last 15 years. Yes, information must be organize able. However, I learned in 30+ years of nursing theory that every time some expert in the field comes up with new organization of the information for professional reasons. And each have a proper underpinning and each ends up to have slightly different categories under which the information is organized. However, if you drill down to your list below (data elements, data type, value set expression, binding to unique semantic codes) e.g. the nodes / clinical statements, all such information remains the same over centuries. So I have a strong preference to limit ourselves to the 20 or so basic characteristics of the data elements, their relationship, their use in 1-n organizing principles, their use in 1-n professional processes (not only the problem oriented approach indicated by observation, evaluation and such),and more.
You can throw away this, and say that there is nothing that can be trusted as invariant beyond some data types and free hierarchies. Fine. But the minute you do that, you unavoidably turn every EHR product, and every clinical information project into a custom situation, where nothing beyond those minimal basics can be assumed. That seriously lowers the ability to get interoperability, and it antithetical to most practical goals in current modern care systems.
The moment we prescribe the record structure even in abstracto like 13606-1, we are potentially limiting the flexibility of reorganizing the 1-n detailed clinical models that in itself are 100% standardized into clinical relevant structures and pathways.
An anology. I like to standardize the currencies around the world (Euro, Dollars, Won, Frank, Kroner, Rand and more). Each will get the internationally agreed abbreviation (USD, EUR) and their symbols €, $, £, ¥ and more. And the conversions according to rules and daily/ hourly, minutely changing figures is still part of the standard.
A next step is that you want to standardize how a legal bill must look like (including company number, tax number, service or product delivered amount, price per unit, subtotal and so on).
This are basic rules that would follow the minimum required to understand a bill.
However, what Reference Models try to do is determine what services and products in what order and which code must be on the bills and prescribe the currency.
Any given reference model addresses a wider or narrower community for whom the semantics hold. You can make it super-specific, then it addresses only one use case.
I would really love CIMI to continue setting the criteria for clinical models, but why do we not call the format they must be in, and which represents some of the standardize able bits you list below, something else than a reference model. We have alternatives like Model Format, Model Design Pattern, Model Requirements (MR is better than RM J), or similar. The we are sending out a precise message that we create models that adhere to standardized patterns, but are not confusing the world by introducing yet another Reference Model.
CIMI could do that, but to my understanding its premise is not that; its premise is the concept of trying to do something about content models so that information interoperability and machine computability will be improved.
As I said to Peter Hendler, maybe CIMI hasn't really agreed on what assumed paradigm is. Is it:
- a model formalism + reference model approach
- an HL7 + semantic net approach
- a model formalism -only approach
- something else
these are basics.
CIMI is like anything else - it can only work if it chooses a
paradigm, and then works within that paradigm. People who don't
agree with the paradigm should set up an alternative effort. The
only other thing it can possibly do is some kind of research into
different paradigms.
I'm not against you wanting to pursue your preferred paradigm
(who knows, I might be wrong, and maybe your way will solve
everything one day). But CIMI can't follow two different
paradigms; it has (as far as I know) chosen, and it working within
one paradigm. If isn't the case, then it probably needs to review
where it is on this basic question...
- thomas
Joey Coyle
Does anyone have Angelo Rossi Mori's current email address?
thanks,
joey
Stan Huff
Angelo Rossi Mori (ross...@itb.cnr.it)
Angelo Rossi Mori (aross...@gmail.com)