I am not asking to merge standards. I am asking for cooperation to show on a large scale and in real world examples where each standard shall be put to use for which purpose. Cooperation with the IHE lab report group may be a useful starting point. There may be better ones. Greetings from Austria. Stefan Sauermann
_____ Von: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical-bounces at openehr.org] Im Auftrag von Thomas Beale Gesendet: Freitag, 05. September 2008 20:42 An: For openEHR clinical discussions Betreff: Re: AW: Chair of openEHR Clinical Review Board (CRB) .. your viewsplease Hi Stefan, I would suggest that in this eternal quest to 'merge standards' (I have been hearing about it for 10 years now), we need understand that standards are not all the same. To understand the differences we need a small standards typology. The following is a rough classification. * A - standards for concrete purpose-specific schemas, messages etc, such as for particular kinds of re-imbursement, order, lab result etc; These schemas only have one use (although it might be quite wide) and are almost always hand-crafted * Characteristics: * Modelling * every message schema has to be hand built; * generally limited re-use of elements between messages; * no reuse at all across implementation technologies, there is no way to use a message definition to generate GUI elements, service interface or other expressions; * Interoperability * functional interoperability is achieved (within the limits of local variations of message implementations) * semantic interoperability is possible depending on how tightly controlled the definitions and use of coding are * systems suffer from semantic incoherence from GUI to persistence layers, because their messages are developed and implemented separately from their GUI capture and display, persistence, and service interfaces * very limited support for querying * Clinician engagement: * usually difficult for clinicians to engage with in order to define content for each new message => messages only approximate requirements * Economics * inflexible; changed requirements => new message definitions * relatively low cost of use for a given message, since message structure fully mapped out - implemeters only have to generate prescribed content; no theoretical understanding required * scalable to some point but with a linear increasing cost and often NxN complexity characteristics * costs of system building borne separately * Examples * EDIFACT * HL7v2 messages * HL7v3 messages (slightly more generic message production approach, but vastly higher development cost per message compared to HL7v2) * ASTM CCR message (one size fits all approach) * B - standards for concrete generic schemas, which can carry a wide variety of content: * Characteristics: * Modelling: * only a single schema required; much cheaper to implement at a basic level * however no controls on what how content is expressed in the structures defined by the schemas; two implementers are most likely to develop two different configurations to express 'vital signs observations' * Interoperability: * functional interoperability guaranteed (single shared data schema) * semantic interoperability likely to be poor / chaotic / unmanaged * basic querying supported but only useful if content structures standardised * Clinician engagement * no direct way for clinicians to engage; clinical modelling usually done (badly) by software developers * Economics: * relatively cheap in limited local contexts * not scalable * some software re-use within systems * Examples * EN13606-1 XSD on its own * HL7 CDAr2 XSD on its own (more or less, although it is only partly generic at the Entry level) * openEHR Reference Model expressed as an XSD or other similar format on its own * C - standards that define concrete generic schemas, plus a formal way of defining content that can be used with these schemas that has the effect of controlling instances of these schemas (i.e. actual documents, XML): * Characteristics - as above: * Interoperability * + semantic querying supported * Clinician engagement: * + clinicians can directly engage and build content models for use with schemas * + modelling governance framework required * + separate modelling still required for many aspects of systems, particularly GUI and service interfaces * Economics * higher costs of centralised / regional planning & governance * lower incremental costs (i.e. cost of deal with each new requirement) * higher implementation cost per site; some level of theoretical understanding required * reduced cost of systems due to some software re-use * highly scalable with a cost characteristic probably of a NlogN shape * possibility of concrete gains in preventative and personalised health due to ability to do true semantic querying through and across EHRs * Examples: * EN13606-1 + EN13606-2; caveat: EN13606-1 doesn't provide a direct basis for many useful clinical archetypes; no templates * HL7 CDAr2 + HL7 templates (schema specialisations of CDA main schema; limited reuse) * openEHR RM XSD + archetypes + templates * D - standards that define a framework for defining reusable formal clinical content models, that can be used with abstract generic schemas to be able to generate various concrete generic schemas (message defs, XSDs, Xforms, java code, DB schemas), and to generate concrete purpose-specific concrete schemas. * Characteristics as above: * Clinician engagement: * + getting towards single-source modelling - clinicians can model once and have their semantics appear everywhere. * Economics * + lower implementation cost per site - same as for using hand-built messages * + significantly reduced costs of system due to pervasive re-use of generated artefacts * Examples: * openEHR abstract RM + archetypes + templates; openEHR abstract RM ==> generate ==> multiple concrete expressions, including various XSD, database schema, Java code, C# code, and many more; openEHR operational template (incorporating archetypes & reference model elements) ==> generate ==> Template Data Schema (TDS) e.g. for messaging, display. The last kind is what we have been working on in openEHR - it is getting toward the goal of fully semantically informed systems and interoperability engineered within the one framework. Clearly in the above you cannot just compare openEHR with CDA with HL7v2, with whatever else. The overall framework in each case brings significantly different advantages and cost characteristics. Until recently, openEHR was not the cheapest to engage with if you are a single implementer site or company; this has changed due to the TDS; previously message-oriented standards were cheaper to engage with from a single site point of view. However if you are a region or a country, then the cost advantages of a better framework may make a qualitative difference on national health budgets. I think that if health authorities and governments don't realise the qualitative differences, they will not succeed in creating a sustainable e-health framework (i..e they will simply succeed in creating the only kind that we know of to date, which is one that has to be recreated every few years). I did not include IHE above, because it is really a 'standard' for a transport system for other content developed by whatever means. But: consider how useful it would have been to have the IHE lab report definition generated from trly reusable content models of lab reports, that could also be used for other purposes. I am not saying that the various kinds of standards can't be made to work together - they possibly can (some are easy - e.g. openEHR / 13606); the above typology helps show how they could be integrate and what the costs are likely to be (and therefore what integrations make sense). - thomas beale Stefan Sauermann wrote: In order to get something on the way here, I think we need to combine some major forces, and finally show that we can successfully tackle some real world problems on a multi-national scale. - The IHE lab report group does collect clinical input from different countries, and it has carried the document through many iterations, and produced a final release in August 2008. After that much effort, it can well be expected to be of clinical use, and is definitely worth consideration. We do see a lot of vendor interest here, and things are being implemented, tested, and put to practical use. - openEHR is the home of archetypes, a very relevant technology, and also has a lot of international clinical input and expertise, and the tailwind of 13606 being a formal international standard. (- HL7 is the home of CDA, and therefore connected deeply) Would it be possible to connect these two (or all three?) groups, generate archetypes from the IHE lab report, and show how this agreed clinical content can usefully be documented and reused with the archetype technology? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20080908/8141205d/attachment.html>
