Rong, XML documents populated against a Template Data Schema are turned into pure openEHR, so you do not lose any semantics. There is enough meta data in the TDS to maintain the semantics. What you may lose are some of the ADL assertions which cannot be expressed in XSD, but these will be picked up by an openEHR kernel before being committed. The schema provides enough constraints to get a non-openEHR developer started.
All this will become clear when we publish a draft of the TDS generation and transformation rules on the wiki. Heath From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen Sent: Monday, 26 November 2007 1:38 AM To: For openEHR technical discussions Subject: Re: Compact XML format...? On Nov 25, 2007 10:09 PM, Heath Frankel <heath.frankel at oceaninformatics.com> wrote: Hi Erik, I will forward a schema based on a Microbiology Result generated using the Ocean Template Designer separately. See comments below, you have stated exactly the problem that the TDS was designed to solve. We are using this approach to integrate existing vendor software to the Ocean EhrBank where the vendor has no openEHR expertise or desire to do so (yet), they just want to have an openEHR repository. Hi Heath, Tom and others, I clearly see there is a need for TDS based integration. But I am also concerned with the side-effects of it. By offering this 'easy' way of integrating openEHR systems, we make it possible for vendors to ignore the 'hard' way of integrating openEHR systems using archetypes and the generic RM. As you have indicated TDS doesn't contain all the semantics of the archetypes and RM, some semantics will be forever lost when data are received using TDS. Without the knowledge of archetypes and RM, some intelligent use of the data won't be possible, e.g. AQL queries of the data. Also one-template-one-schema seems to imply software changes whenever new templates are introduced. Such changes will not be necessary if the openEHR RM can be mapped directly into a generic internal model, which is constrained in runtime using semantics in the archetypes/templates. So even it seems to be harder than TDS based integration, it does offer full benefits of using archetypes and makes the system more adaptive. Regards, Rong Heath > 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. [Heath Frankel] As you know, a template is the knowledge artefact designed for a particular use case, the TDS is a technical artefact to support the implementation of that 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. [Heath Frankel] Most but not all the semantics of the archetypes and templates are represented in the TDS. The reason it is not all, is due to the limitations of XML schema to do assertions between XML elements. > 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... [Heath Frankel] The TDS is simply a set of XML elements with names from the archetypes. If you look at the schema in an graphical XML tool such as Oxygen you will see a tree that has the same structure as the template tree displayed in the Ocean Template Designer. > 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.) [Heath Frankel] This is exactly the plan for the TDS. _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071126/2c5b6858/attachment.html>
