Dear Erik, My personal thoughts and reactions.
It is based on off-line discussions in the EN13606 Association. We will collect our thoughts and ideas, present them next year to the community and discuss them in February during our annual meeting in Seville. Until then my personal ideas only. Gerard Freriks +31 620347088 gfrer at luna.nl On 16 dec. 2011, at 12:06, Erik Sundvall wrote: > 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. I agree. This is what I wanted in the first place. In the standardisation process it was felt to be more safe to obtain experiences first this the present scope. Some wording in the present scope hints at this more extended use outside of the EH-Extract. Although I agree, I think, that the 13606 Reference Model should not be a model on how to implement it in a very detailed way in a system. It must stay a generic and logical model that provides features that help vendors to produce such internal proprietary implemented models. > >> 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/ It is/was a matter of scope. I see no reason why we can NOT have one logical model that can serve the purpose of use inside IT-systems and outside an IT-system. A different matter is whether the present openEHR RM is acceptable or not. And who owns the spec. > > 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? When it is possible to design and implement using 13606 and archetypes in less than a week a common patient summary between two different hospitals, or a system that transforms a proprietary EHR to the CDISC-ODM format, is that enough of an answer? My answer is that the present 13606 fulfills its scope and is very functional. > >> 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 and I agree. > > 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? In the EN13606 Association community there are openings to do that. But whether the CEN/ISO representatives want it, is to be found out. > > 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)? 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>
