Hi everybody, very interesting thread. And yes TDS seem to be a very helpful and pragmatic way to start with openEHR. This pragmatism and step-wise approach is what helped HL7 CDA R2 to be relatively successful! Now, we have an answer for this strong (IMHO the strongest) CDA argument.
As mentioned previously it will depend on the use case (and its economics) whether an implementor uses it to stepwise change their systems to a "full", adaptive openEHR solution or whether every time clinical requirements (expressed as archetypes and templates) change the software is re-implemented. Regarding interoperability it won't make a difference as in both cases the resulting data is fully openEHR compliant. One theoretical question (probably you Ocean guys have already looked into it), would it be possible to generate a second schemtron schema to express the asseration type constraints that can't be expressed with XML schema. If possible, by validating against both schemas there wouldn't be a need to use an openEHR kernel component in this integration by TDS scenario. But maybe this is (1) to complicated or (2) superflous as the data is checked anyways with a kernel before being committed. The only advantage would perhaps be that a more or less complete validation could take place in an XML based environment at the client side. Cheers, Thilo On 11/26/07, Heath Frankel <heath.frankel at oceaninformatics.com> wrote: > > > > 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: openehr-technical-bounces at openehr.org > [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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
