Hello again! Here comes a more complete version of the mail I happened to send unfinished this morning.
I hope you don't mind me breaking out a side thread with concrete harmonisation suggestions. First an openEHR change request (CR), then an ISO 13606 change request. 1. item_structure (openEHR CR) ================ Regarding ITEM_TABLE (and the other classes in the openEHR item_structure package) there was a change request from Sam that went pretty unnoticed by a while ago, see: http://www.openehr.org/mailarchives/openehr-technical/msg04994.html I'm not saying we should go exactly by the letter in Sam's CR, but somehow skipping the things currently in item_structure package in openEHR could simplify understanding and slightly reduce implementation complexity. (It might also shorten paths in object traversal (and thus storage depth) one step - a possible performance gain in some implementations.) Probably letting the "data" attribute of openEHR ENTRY subtypes point straight to ITEM (or possibly CLUSTER) would be best. If something should be suggested to be shown in a GUI as a table, list (or other non-tree formalism) it might be possible to define using any of the following... a) ...a GUI directive/hint in archetype annotations similar to the directives shown by Koray Altag at Medinfo 2010, see slide 30 and onwards in http://www.openehr.org/wiki/download/attachments/5996988/3_GastrOS_Atalag.pdf b) ...a new attribute in the CLUSTER or ITEM class (with accompanying controlled vocabulary). c) ...some other way I have not thought of Suggestion a) means the directive/hint might not be available in instance data, only in the archetype, that might be bad for safety reasons. If b) is chosen, then that new attribute could of course be archetyped if you want the information in the archetype as Andrew suggests. Shortcuts to UML diagrams for comparison: CEN/ISO: http://www.chime.ucl.ac.uk/resources/CEN/EN13606-1/13606-1Diagramsv3e.pdf openEHR: http://www.imt.liu.se/~erisu/2008/openEHR-tour/print/openEHR-RM-1.0.1-may23-17.54.gif <http://www.imt.liu.se/~erisu/2008/openEHR-tour/print/openEHR-RM-1.0.1-may23-17.54.gif>I'd suggest that this change, after refinement and discussion with openEHR implementers followed by successful prototype implementation, be introduced as soon as possible before there is too much real patient data stored using the present item_structure package. Perhaps it can be introduced at the same time as ADL 1.5 and enhancements of the LINK class which anyway will require code changes. 2. OBSERVATION et. al. (ISO 13606 CR) ====================== I can understand the CEN/ISO-urge for simplification of the openEHR ENTRY package *if* the main intention of the standard is to extract and exchange data from legacy systems where there is no intention to harmonize the semantics of data capture in the originating systems. A typical scenario would be "Let's agree on an exchange message format for this particular use case and then everybody can do their best to map their internals to the agreed format" (a fully reasonable scenario in many situations by the way). But, if that was the intention, then the whole openEHR-ish archetype approach seems to be overkill. Why not just go for a simple usecase-specific XML-schema or HL7 v2? *If* on the other hand the CEN/ISO intention was (or becomes) wider to also encompass the intention to *harmonize the semantics at the point of data capture*, then the openEHR ENTRY subtypes really do make sense. The point of them is to have consistency and efficient technical implementation for some common usecases. The technical class names (especially OBSERVATION vs. EVALUATION) have often been confusing people (e.g. from a philosophical, ontological or phenomenology perspective). This has been discussed earlier, see: http://www.openehr.org/mailarchives/openehr-clinical/msg01353.html and followups, e.g. Heathers reply at http://www.openehr.org/mailarchives/openehr-clinical/msg01364.html So, to get you to focus on the *technical structure* and it's consequences rather than thoughts like "what is really an observation and why sholuld that be in the RM instead of the archetype". Let's temporarily in this post rename OBSERVATION to CARE_ENTRY_SUPPORTING_STRUCTURED_TIMING (as s described in the msg01353<http://www.openehr.org/mailarchives/openehr-clinical/msg01353.html>-link above). Sending patients between health care organisations with different EHR structure is just one usecase where an "archetyped" approach is useful, and I guess that is what CEN was somehow targeting. Other (according to me at least as interesting) usecases for path-enabled archetyped health records is the possibility to with a small effort reuse e.g.: - decision support rules - clever GUIs - overviews - epidemiology queries I research patient overviews where time is one very important visualization facet, and it really helps if there is a common way of expressing the semantics of time series using the class CARE_ENTRY_SUPPORTING_STRUCTURED_TIMING. That way we have predictable search paths to the time points and can make general (archetype agnostic) time-series viewers or drastically speed up development of archetype-specific time-series viewers. (Other fixed time point semantics like in COMPOSITION/EVENT_CONTEXT are also helpful, but there the differences between openEHR and 13606 are a bit less of a problem). So to Tom's claim that it is easier for clinicians to model time series, without risking reinventing the wheel in different ways every time, if the clinicians can use CARE_ENTRY_SUPPORTING_STRUCTURED_TIMING in addition to just ENTRY, I would as a software developer like to add that it also makes it a lot easier for those of us that want to retrieve and use the data. Many of the same issues also arise when you want to connect decision support systems doing temporal reasoning. You could do similar reasoning around INSTRUCTION+ACTION archetyping when it comes to having a generalized way of figuring current process state and a way of documenting transitions. Of course a 13606 ENTRY can be enough to model state in any way you personally want, but if we are going to build real systems using the state information, then we don't want to make a different kind of program snippet for every archetyping style used in the system. One of the major points of archetyping is to be able to compute health data in reusable ways, we don't want yet another generation of the "Desperately seeking data"-problem, see: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2850654/ There are simply better things to spend resources and the time of brilliant informatics people on. Note two things: 1. Algorithmically sound machine translations/transformations are ok, computing power is cheap. 2. I don't say that the entire world needs to unite here, it would be quite ok if there were just two or three different ways (e.g. HL7 and openEHR) of modelling the same thing, we can afford some manual translations of DSS rule integrations, overview systems, queries etc that are found valuable worldwide, but not dozens of different ways within a single region. *So my concrete harmonisation suggestion to CEN/ISO for the next update of 13606 is to m**ake an optional 13606 addition including the openEHR ENTRY subtypes, feel free to name them differently if it is names like "OBSERVATION" that are annoying.* This addition could be used by actors with a wider intention to harmonize the semantics of data capture, not only agree on messaging after manual mapping. In the mean time someone could try to document tested and logically sound & complete algorithms that can convert... - openEHR ENTRY subtype instance data - openEHR ENTRY subtype archetypes - corresponding paths and AQL-queries ...to 13606 in a consistent way. I guess such a conversion could also be performed by someone else than CEN/ISO if the 13606 semantics is powerful enough. I do believe that archetypes autoconverted to 13606 format will be less readable, but I could be wrong. Anyway, if the archetype modelling and query building would take place in the openEHR-space before autoconversion, then such a readability issue would not matter. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/<http://www.imt.liu.se/%7Eerisu/> Tel: +46-13-286733 P.s. Building up parallel efforts for developing and maintaining 13606 archetypes separate from openEHR archetypes as I have heard suggestions of seems like a huge waste of effort, modelling in one space and then machine-translate would be more reasonable. That HL7 and openEHR clinical models will currently be developed in parallel is something we'll just have to accept for now and let them inspire each other over time. P.p.s. I agree that openEHR governance could be more responsive and transparent. But learning learn more from management of successful volunteer projects e.g. in the open source world might gain more than copying SDOs. But discussing that probably fits better in another thread. On Tue, Nov 9, 2010 at 03:25, Andrew McIntyre <andrew at medical-objects.com.au > wrote: > > In reality the "Observation" status of an entry should have a > terminological definition rather than an explicit attribute of the model and > by declaring the eg "TABLE" cluster you are actually removing the knowledge > from the terminology and moving it to the model. This means the archetype > does not have the information. To function as a DCM the archetype should > have that knowledge embedded in it so that it can be represented in a > specific way in another model. You could declare a cluster that is marked, > by terminology binding as a table structure and that would allow any model > to represent it using its own table convention. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101110/95f63a86/attachment.html>
