13606 revisited - list proposal
2011/12/16 Erik Sundvall erik.sundvall at liu.se If so, why do you want to turn the 13606/openEHR into something healthcare a-specific? Wouldn't that be an enormous deviation from the current 13606 thinking and purpose? Was not 13606 intended exactly for healthcare? Well, in fact current EN13606 RM is nearly healthcare independent, except the EHR_EXTRACT class name, the attributes ehr_system, ehr_id, subject_of_care and healthcare_facility and the demographic model. The class and attribute names can be easily changed to drop the EHR part and for the demographic package I think that the one of openEHR is much better and, in fact, it is already healthcare independent. In any case, this generic design is a result of the current scope of 13606: EHR exchange and not a complete EHR implementation specification. From our experience, interoperability between legacy systems (standard-based or not) is much easier using a generic model for exchange. The harsh truth is that the quality of the data and the design of information structures in existing EHR systems is quite bad or unclear, thus making really complicated the process of automatically transforming it to a very specific reference model. This is not the case when we use 13606. A different thing is if 13606 scope changes during the revision. In that case, I agree that reducing layers of modelling by introducing specific classes will make the systems more efficient. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/43915127/attachment.html
13606 revisited - list proposal
Hi! On Fri, Dec 16, 2011 at 09:32, David Moner damoca at gmail.com wrote: In any case, this generic design is a result of the current scope of 13606: EHR exchange and not a complete EHR implementation specification. Thanks for reminding me. I tend to forget that the 13606 purpose never was to make internal system semantics interoperable. It's easy to forget the intentional 13606 focus when usually thinking of mappings and interoperability issues based on examples like the ones on slides 12 and 13 of... http://www.imt.liu.se/~erisu/2011/openEHR-TBMI19-lecture.pdf As you know, if you want to truly bi-directionally share things for which it is impossible to define deterministic conversion algorithms/programs (thus maintaining patient safety in automated conversions), then just defining a standard message- or extract format will be a lost cause (no matter how determined politicians are and no matter how much you pay IT-consultants to try to do the job). Instead the semantics of the end point systems will need to be aligned sooner or later. Anyway it wouldn't hurt if a new or refreshed internationally recognized standard could be used by those vendors and system owners that actually _want_ to agree on the internal clinical semantics of efficiently implementable systems all the way down to some of the technical (e.g. openEHR inspired) details. I think there is now a market for such a standard (or new standard part) helping those that have given up beliefs in mapping of incompatible semantics. From our experience, interoperability between legacy systems (standard-based or not) is much easier using a generic model for exchange. The harsh truth is that the quality of the data and the design of information structures in existing EHR systems is quite bad or unclear, thus making really complicated the process of automatically transforming it to a very specific reference model. This is not the case when we use 13606. I suspect this is an intentional difference between current 13606 and openEHR; to faithfully capture the current (incompatible) situation versus aiming to change the current situation. Can those different goals really meet in one RM or do we need two standardized RMs? http://dilbert.com/strips/comic/2011-08-02/ A side-track question: Do you feel that the archetyped approach with 13606 really helps in the current mappings/transformations that you work with more than what just using e.g. RDF+OWL would help? Or does the archetype stuff and RM mostly complicate things? A different thing is if 13606 scope changes during the revision. In that case, I agree that reducing layers of modelling by introducing specific classes will make the systems more efficient. Is there an opening for scope-change or not within the formal 13606-revision or would one need to start a completely new standard in order to define a standard for aligning internal EHR system semantics? Could one add a new part (13606 part-6 or 1b?) to the specification containing detailed RM semantics (inspired by openEHR) and at the same time align that new part and a more general healthcare a-specific model (a revised 13606 part-1(a)?) in a way that clearly defines a deterministic (and tested) conversion algorithm from the detailed clinically focused RM (6 or 1b) to the healthcare a-specific RM (1a)? It would be nice to have the different parts under the same roof, a revised 13606, since they could share an AM based on AOM 1.5. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
13606 revisited - list proposal
+1 BTW in an ideal world the 13606-openEHR divergence shouldn't have happened in first place. I seriously think we can't afford to fall apart and go our own ways. But never mind... -koray -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Adolfo Mu?oz Carrero Sent: Thursday, 15 December 2011 11:14 p.m. To: openehr-technical at openehr.org Subject: Re: 13606 revisited - list proposal Dear Thomas, I also think it's a good idea. Regards, Adolfo Mu?oz El 15/12/2011 11:04, Rong Chen escribi?: Great idea, Thomas! /Rong On 15 December 2011 10:29, Isabel Rom?n Mart?nezisabel at trajano.us.es wrote: Dear Thomas, I think it is a good idea. Best Regards, Isabel El 15/12/2011 10:01, Marcelo Rodrigues dos Santos escribi?: Dear Thomas, The creation of this list will be an excellent contribution to promote the harmonization process. In my opinion the alignment of these two initiatives is a concrete step to achieve interoperability among EHR systems. Best regards, Marcelo 2011/12/15 Seref Arikanserefarikan at kurumsalteknoloji.com Hi Tom, Yes, such a list would be good. Regards Seref On Thu, Dec 15, 2011 at 12:49 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: At the CIMI meeting last week and elsewhere, I have noticed a lot of interest in the ISO 13606 2012 revision, specifically in a) whether the openEHR and 13606 reference models can be brought together for part 1 of the revision and b) in finalising ADL/AOM 1.5 for providing a new snapshot to ISO for part 2. It seems to me that it would be useful to have a dedicated place to discuss this, so I would like to propose a new mailing list, 13606-alignment at openehr.org Does this seem like a useful idea? - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Adolfo Mu?oz Carrero Instituto de Salud Carlos III Unidad de Investigaci?n en Telemedicina y eSalud Avda. Monforte de Lemos 5 - Pabell?n 14 28029 Madrid Tfno: +34 918222182 FAX: +34 913877567 * AVISO LEGAL * Este mensaje electr?nico est? dirigido exclusivamente a sus destinatarios, pudiendo contener documentos anexos de car?cter privado y confidencial. Si por error, ha recibido este mensaje y no se encuentra entre los destinatarios, por favor, no use, informe, distribuya, imprima o copie su contenido por ning?n medio. Le rogamos lo comunique al remitente y borre completamente el mensaje y sus anexos. El Instituto de Salud Carlos III no asume ning?n tipo de responsabilidad legal por el contenido de este mensaje cuando no responda a las funciones atribuidas al remitente del mismo por la normativa vigente. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical __ Information from ESET NOD32 Antivirus, version of virus signature database 6712 (20111214) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6716 (20111216) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6716 (20111216) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
13606 revisited - list proposal
?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/244bb585/attachment.html
13606 revisited - list proposal
On 16/12/2011 11:06, Erik Sundvall wrote: if you want to truly bi-directionally share things ... the semantics of the end point systems will need to be aligned sooner or later. Anyway it wouldn't hurt if a new or refreshed internationally recognized standard could be used by those vendors and system owners that actually _want_ to agree on the internal clinical semantics of efficiently implementable systems all the way down to some of the technical (e.g. openEHR inspired) details. I think there is now a market for such a standard (or new standard part) helping those that have given up beliefs in mapping of incompatible semantics. Although openEHR is designed for aligning semantics of the data inside and between systems, real sytems/products are not so much deficient in this area (well, actually they usually are) as focussing on higher levels of computing, such as medication list management, prescription tracking, care plan management and so on. They generally have to implement such things with hard-wired logic and dedicated DB tables etc because there is no generalised data architecture that provides the platform for such functionality. In the standards arena, we have to deal with these upper levels of functionality at some point, but doing so will be easier having defined a 'proper' data architecture (I don't mean to say today's version is perfect, just that it is probably in the right ballpark of structure/semantics to support upper layers of logic). One of the forthcoming proposals we have been working on for some time is a generalised rule-based 'Entry Index' system which enables higher level structures like medication lists and care plans to be completely specified in terms of the low level openEHR Entry types we know today (or whatever they become). This facility is based on AQL rule patterns and output notifications / events, so it is a higher level of sophistication than what currently exists in openEHR. I foresee such tings (the above is just one example) being slowly standardised, in a flexible way, so that one day medication lists, doctor's appointment schedules and patient care plans can be widely shared across products and jurisdictions. Secondly, decision support and business intelligence will finally have something solid to work on. In my view, that is the real promise of openEHR. The current models are just a foundation. I suspect this is an intentional difference between current 13606 and openEHR; to faithfully capture the current (incompatible) situation versus aiming to change the current situation. Can those different goals really meet in one RM or do we need two standardized RMs? http://dilbert.com/strips/comic/2011-08-02/ I should perhaps point out that openEHR has a perfectly usable generic Entry type http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html that does the same as 13606 Entry. This Entry type is designed for weakly structured data. I would suggest that it is not an argument between inside-system logic V between system logic, but that there is a continuum of structure+semantics, and our models have to cater for that. Some otherwise primitive systems happen to be very good at time-series data (e.g. most vital signs monitors) and creating openEHR Observations in messages for these data sources is in fact easy. So Observation is not specifically an 'inside-system' concept, just a standardised way of representing time-series data that is useful for sharing information. Could one add a new part (13606 part-6 or 1b?) to the specification containing detailed RM semantics (inspired by openEHR) and at the same time align that new part and a more general healthcare a-specific model (a revised 13606 part-1(a)?) that could be a useful idea. There are other probably more important challenges in the current 13606 though. I have put a few notes here http://www.openehr.org/wiki/display/spec/openEHR+%7E+13606+2012+revision+-+alignment+proposals. - thomas ** -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/a022ed5f/attachment.html
13606 revisited - list proposal
from the detailed clinically focused RM (6 or 1b) to the healthcare a-specific RM (1a)? Present thinking in EN13606 is that possibly there can and will be one logical RM as part 1, serving an extended scope. One of the driving forces behind an updated Part 1 and a new additional standard (SIAM) is the need to reduce the numbers of freedom. One possible new RM for 13606-1 is being discussed internally. One RM that allows the expression of constraints on any UML model, as Part 2. Personally I think that Part 3 will be replaced. Much of its present content will end up in an other standard that deals with how semantic artefacts (archetypes/templates/ common modeling patterns, etc.) are constructed. The standardised (sub-)patterns will reduce the degrees of freedom. Whether this standard for Semantic Interoperability Artefact Modeling (SIAM) will become part of 13606 or a separate standard we will have to see. Whether the name I used will be its real name, we will have to see. Part 4: what will we have to do there is an engima for me. I think that there is not enough experience with it. Part 5: is too young to change. other than correct mistakes and explain more, when needed. It would be nice to have the different parts under the same roof, a revised 13606, since they could share an AM based on AOM 1.5. I fear that in my thinking, part of the functionality in the present AOM1.5 will end up in the SIAM standard. As will be the Observation, Evaluation, Instruction and Action sub-parterns that specialise the generic Entry Class in the RM. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/9d0f4d2f/attachment.html
13606 revisited - list proposal
I suspect this is an intentional difference between current 13606 and openEHR; to faithfully capture the current (incompatible) situation versus aiming to change the current situation. Can those different goals really meet in one RM or do we need two standardized RMs?http://dilbert.com/strips/comic/2011-08-02/ I should perhaps point out that openEHR has a perfectly usable generic Entry typehttp://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.htmlthat does the same as 13606 Entry. This Entry type is designed for weakly structured data. It is not exactly the same as what I was proposing. The GENERIC_ENTRY as is now only complicates de model by creating a standalone branch. Instead of that, I would prefer to look for a solution where the ENTRY class is directly instantiable. Thus, an implementer can choose to use it if the lower OBSERVATION, INSTRUCTION, etc. classes do not accommodate his needs. Moreover, it would be easy to cast an ENTRY instance into any of its descendants when needed. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/120f3d44/attachment.html
13606 revisited - list proposal
Hi David, On 16/12/2011 18:48, David Moner wrote: I suspect this is an intentional difference between current 13606 and openEHR; to faithfully capture the current (incompatible) situation versus aiming to change the current situation. Can those different goals really meet in one RM or do we need two standardized RMs? http://dilbert.com/strips/comic/2011-08-02/ I should perhaps point out that openEHR has a perfectly usable generic Entry type http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html that does the same as 13606 Entry. This Entry type is designed for weakly structured data. It is not exactly the same as what I was proposing. The GENERIC_ENTRY as is now only complicates de model by creating a standalone branch. do you mean in the inheritance tree? Well, that's true, but that's normal object modelling... Instead of that, I would prefer to look for a solution where the ENTRY class is directly instantiable. Thus, an implementer can choose to use it if the lower OBSERVATION, INSTRUCTION, etc. classes do not accommodate his needs. Moreover, it would be easy to cast an ENTRY instance into any of its descendants when needed. I think this is looking at it from too low a level. The structures of ENTRY, OBSERVATION, INSTRUCTION etc are quite different. The ENTRY concept in openEHR does not on its own define a meaningful object; the structure of the data have to be defined in specific subclasses. The descendants (today) are: ADMIN_ENTRY, OBSERVATION, EVALUATION, INSTRUCTION, ACTION and GENERIC_ENTRY. So GENERIC_ENTRY is just one of the sibling possibilities for representing data. (I realise that it's a bit annoying that we use 'ENTRY' as the abstract parent type, whereas 13606 uses it as the name of the concrete type, but I can't see any easy way around that). I think this is a normal modelling outcome. I can't see how in openEHR, the ENTRY class could do its main job, which is to define the common attributes (we can think of them as meta-data attributes) of all ENTRY types, and also have some kind of commitment to data, which would then be somehow redefined to other specific data structures somehow - casting only works when the physical data don't change, but are interpreted differently (and anyway, casting should always be avoided - it means the software is potentially violating the type system). The normal OO approach is that a parent class such as ENTRY stays abstract, and its children exhaustively define the possibility space. However, what I can imagine is a function on ENTRY, something like 'as_standard_representation: CLUSTER', which /generates /a standardised CLUSTER/ELEMENT hierarchy of the 13606 variety (complete with logical data structure markers to indicate the intention of lists, tables etc). This would allow the openEHR model to stick to normal OO modelling conventions, but also have a fully formally defined transform to the simple CLUSTER/ELEMENT structure from each of its ENTRY subtypes. Calling this function during a traversal of a COMPOSITION would enable something very close to a 13606 COMPOSITION to be generated. As I mentioned in another post, I think a greater challenge is dealing with the differences in the base classes - my notes on this so far are here http://www.openehr.org/wiki/display/spec/openEHR+%7E+13606+2012+revision+-+alignment+proposals. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/02eabe28/attachment.html
13606 revisited - list proposal
I am reading 1.0.2 IM and it says CARE_ENTRY, not GENERIC_ENTRY. which one is the good one? By the way, both ENTRY and CARE_ENTRY are abstract in openEHR. I don't think you could only make ENTRY non-abstract without making CARE_ENTRY non-abstract too (I think it has no sense to inherit an abstract class from non abstract). Looking at CARE_ENTRY, I don't really get why ADMIN_ENTRY is not able to inherit from it. 'protocol' attribute meaning changes according to the instantiated class (as the pdf says, describes 'how' was arrived the information) and it is optional, as 'guideline_id'. Why don't make ADMIN_ENTRY as a child of CARE_ENTRY as protocol could be also used (why not using it for stating how was the ADMIN_ENTRY information arrived? or what where the social/legal requirements to led to this entry). 'guideline_id' could be used to state if this ADMIN_ENTRY was a result from a clinical guide step (I can be wrong at this one, but that's what I understand from the specifications). And the specifications say that this one is only used 'if relevant', so it isn't always used anyway. If you do this you can remove CARE_ENTRY and focus on the ENTRY itself :) 2011/12/16 Thomas Beale thomas.beale at oceaninformatics.com: Hi David, On 16/12/2011 18:48, David Moner wrote: I suspect this is an intentional difference between current 13606 and openEHR; to faithfully capture the current (incompatible) situation versus aiming to change the current situation. Can those different goals really meet in one RM or do we need two standardized RMs? http://dilbert.com/strips/comic/2011-08-02/ I should perhaps point out that openEHR has a perfectly usable generic Entry type that does the same as 13606 Entry. This Entry type is designed for weakly structured data. It is not exactly the same as what I was proposing. The GENERIC_ENTRY as is now only complicates de model by creating a standalone branch. do you mean in the inheritance tree? Well, that's true, but that's normal object modelling... Instead of that, I would prefer to look for a solution where the ENTRY class is directly instantiable. Thus, an implementer can choose to use it if the lower OBSERVATION, INSTRUCTION, etc. classes do not accommodate his needs. Moreover, it would be easy to cast an ENTRY instance into any of its descendants when needed. I think this is looking at it from too low a level. The structures of ENTRY, OBSERVATION, INSTRUCTION etc are quite different. The ENTRY concept in openEHR does not on its own define a meaningful object; the structure of the data have to be defined in specific subclasses. The descendants (today) are: ADMIN_ENTRY, OBSERVATION, EVALUATION, INSTRUCTION, ACTION and GENERIC_ENTRY. So GENERIC_ENTRY is just one of the sibling possibilities for representing data. (I realise that it's a bit annoying that we use 'ENTRY' as the abstract parent type, whereas 13606 uses it as the name of the concrete type, but I can't see any easy way around that). I think this is a normal modelling outcome. I can't see how in openEHR, the ENTRY class could do its main job, which is to define the common attributes (we can think of them as meta-data attributes) of all ENTRY types, and also have some kind of commitment to data, which would then be somehow redefined to other specific data structures somehow - casting only works when the physical data don't change, but are interpreted differently (and anyway, casting should always be avoided - it means the software is potentially violating the type system). The normal OO approach is that a parent class such as ENTRY stays abstract, and its children exhaustively define the possibility space. However, what I can imagine is a function on ENTRY, something like 'as_standard_representation: CLUSTER', which generates a standardised CLUSTER/ELEMENT hierarchy of the 13606 variety (complete with logical data structure markers to indicate the intention of lists, tables etc). This would allow the openEHR model to stick to normal OO modelling conventions, but also have a fully formally defined transform to the simple CLUSTER/ELEMENT structure from each of its ENTRY subtypes. Calling this function during a traversal of a COMPOSITION would enable something very close to a 13606 COMPOSITION to be generated. As I mentioned in another post, I think a greater challenge is dealing with the differences in the base classes - my notes on this so far are here. - thomas ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
