Hi! On Nov 23, 2007 7:17 PM, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > I believe you are referring to what we call Template Data Schemas > (TDSs). These are an alternate schema-per-message approach, where one > template generates one schema - in such schemas, you find tagnames > coming from the archetypes, e.g. "systolic" rather than the generic > openEHR tag names.
This seems to be exactly what I was looking for. > I will find out about example messages. Wonderful, if it was possible to get it soon that would be helpful. The reason for asking is that in a context where openEHR/13606 has been compared to HL7 (mainly v3 I believe) some parties claimed it would be easier for vendors to support HL7 than openEHR. In practice, what they mean is probably that they are used to follow (map their internal/legacy structures to) specific HL7 xml schemas that come out after the long HL7 modeling process. I doubt that the vendors in this case internally are using any HL7 v3 models. This is sometimes forgotten when comparing HL7 and openEHR. So far we have had a look at some fairly equivalent examples of XML instances (e.g. blood pressure) from HL7 CDA (v2) and openEHR RM. Both were fairly easy to understand when knowing the underlying models (HL7 RIM +CDA and openEHR RM+AM) and both were a bit verbose if you were just interested in the blood pressure. To be honest if I was a vendor not interested in underlying models I'd probably prefer whichever I was already used to and had people trained to work with - since none of them tries to make life easier to me by being tailored to the specific use case. To validate clinically both were dependent on other artifacts (HL7 Templates or openEHR archetypes). An information provider not interested in the underlying validation mechanisms could easily produce data instances that are clinically invalid even though they are valid from the perspective of the respective XML schemas. Does the TDS-approach produce an XML schema that enforces more or all of the specific archetype+template semantics? If not, could it be enhanced to do that? If so I believe that some safety would be gained - if data providers do not care to learn the full semantics of openEHR then at least their schema-based XML-validators would enforce some of the semantics. If we could standardize the TDSs and have accompanying standard determinstic transformation mechanism then openEHR would have a competitive advantage in the "just give me a simple XML schema and instance examlpe" use-case. A use case more important than one might think at first... Sometimes the use case is to decide on an XML format (for data exchange) based on one of the following 1. HL7 CDA 2. 13606/openEHR 3. A custom tailored XML schema Imagine that we using something like TDS could give an easy-to-produce alternative to 3 that with some deterministic transformations at the receiver also conforms to 2. (An open or free tool to produce the schema would be of tremendous help of course.) Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579
