Hello Hugh and all other readers, i still have some doubts about the right application of openEHR schema definitions. Please see my comments inline!
Hugh Leslie schrieb: > The TDS schema is not generic like the openEHR schema - it relates > exactly to a particular use case (template) including the correct > names for elements, etc. It does contain most of the constraints as > well (though not all). The real value for developers is that once > they have a TDS that matches some application schema, they can work in > an XML environment and don't have to understand anything about openEHR > to create instances of data that conform to a schema that contains > things that have direct meaning from their system schema (or > message). We are talking here about systems that are not natively > openEHR compliant. O.K. if one is using a certain TDS in order to export data from a legacy system this would result in some kind of "intermediary" format. This would lower the effort needed to include legacy data and break up the transformation to "real" openEHR data in two steps. LEGACY -> TDS-conform -> openEHR-conform. The second step could be performed by a generic service that consumes the TDS-conform data and the TDS and then does the transformation into "real" openEHR format. It is fully sensible to me to use a template to capture the structure and semantics of legacy data with the aim to transform it to the openEHR world. > Of course it is possible to create openEHR instances directly, just as > it is possible to create HL7v3 or CDA instances directly and software > systems will do this as well. The issue with all these things is the > high degree of knowledge and expertise required to get it right. The > TDS approach makes it much easier to produce instances because a lot > of the abstraction is made more concrete for a particular instance and > its automatically generated from the models. There is a huge amount > of XML expertise and tooling out there compared with openEHR or HL7 v3. Again, do you know of tools (we use Altova at the moment, ECLIPSE tools seemed to be less advanced), that ease the handling of XML generation, mapping, transformation, validation, formatting, ...? > We have been hearing that some people are saying that openEHR > archetypes are just for clinicians and not for secondary use. Well > this approach allows clinician approachable models to be used for any > secondary use that you would like - we are generating these schemas > and hence messages, documentation, data instances, queries and also > software classes, directly from the models. > > As far as validation goes, this can occur partly at the TDS level as I > mentioned as most of the constraints are there, but most importantly, > as data is committed to a repository it should be validated against > the original archetypes that make up the template as these are the > final source of truth about the contraints on the data instance. How can this data validation against the original archetypes be done? A simple XSD-schema validation does not suffice anyway - am i right? It seems to me that without specific knowledge and deep familiarity with openEHR this can not be done. This takes me back to investigations i made concerning the generation of a user interface. A common and desirably open source set of widgets (GUI elements for data entry) would be very helpful here. Maybe these could do "on the fly" validation at the point of data entry - which sure would be the most user-friendly way of checking for archetype definition conformance. Hope to get comments from more people out there! brgds Demski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090520/2d3865d1/attachment.html>
