Erik Sundvall wrote: > > 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. > thi is a reasonable statement, practically speaking. The question is\; if you are vendor that needs to increase the diversity of content being handled - in other words, you are need semantic scalability - and, if you need to be able too use other derived products from the same content models, then the difference starts to manifest itself. There isn't any easy way I know of to convert a v3 RMIM to an Xform, a PDF, various kinds of XML and HTML and so on. And before people simply say: 'its just an XML transform', you must remember that in the RIM/RMIM world, there are dozens of attributes specifically to do with message transfer that don't make sense in other representations of the same content. Any transformation software has to sift through all these, as well as work out all the context conduction etc. It is not trivial. > 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. > see other responses on this (yes is the answer). > 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... > that's why we made them in the first place ;-) For vendors who just want to send a bunch of messages (they usually see them as messages), that can be converted by smart software doing a standard transform, generating guaranteed correct openEHR content.
- thomas beale
