Dear Erik, The European Institute for Health Records is executing a European project: Q-Rec. Next to quality labelling and certification we have to set up registries of approved artefacts like: - archetypes and templates - coding systems - EHR related standards and - XML implementable Information definitions.
I hope and expect that these Template Data Schemas can find a place there to be disseminated. Gerard conexis --------------------------- Gerard Freriks, MD Huigsloterdijk 378 2158LR Buitenkaag the Netherlands M:+31 620347088 T: +31 620347088 E: gf at conexis.nl KvK 34264021 On Nov 25, 2007, at 9:38 AM, Erik Sundvall wrote: > 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 > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- <private> -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071125/4a02e02d/attachment.html>
