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>
