Hi Thomas, Thanks for this excellent overview, it's very helpfull.
One short question? How could I explain 'semantic querying' to a non- technical person Cheers, Stef Op 5-sep-2008, om 20:41 heeft Thomas Beale het volgende geschreven: > > 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? >> > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20080907/1bd82c68/attachment.html>
