XSD incompatibilites with XSLT code
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090530/4a3b5c92/attachment.html
XSD incompatibilites with XSLT code
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090521/7c1ed51c/attachment.html
XSD incompatibilites with XSLT code
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090520/889ff11c/attachment.html
XSD incompatibilites with XSLT code
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
XSD incompatibilites with XSLT code
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090519/49b2e220/attachment.html
XSD incompatibilites with XSLT code
Hello Hugh, thank you for the quick answer! I do not understand the TDS approach yet. I have the following questions related to your answer: - why should one produce data (i.e. out of a legacy sytem) that conforms to TDS and then convert it to standard openEHR content format when it can be produced as the latter immediately? Nevertheless i clearly see the value of machine-generated message definitions - that's why we wanted to use the TDS for conversion of our legacy data format to standard EHR format. In this sense the Template Designer is used in order to provide an target data schema conforming to openEHR into that legacy data can be converted. - if the TDS is not a schema for an openEHR instance, how can i validate a real data instance against a template definition then? - we currently use Altova's MapForce that gives good support for a manual definiton of the mapping and does an automatic generation of the conversion scripts - this means that one can use a graphical editor and does not have to do the plain coding of the conversion code (e.g. XSLT). Are there any other tools that can be helpful to get legacy data into an openEHR system? brgds Demski Hugh Leslie schrieb: Hi Demski This is not a bug. When you generate a schema for a template, you are generating something called a template data schema which is not the same as a schema for an openEHR instance. The template data schema combines the archetype constraints with the reference model to provide a very specific schema for that particular template. From the openEHR website - The concept of the Template Data Schema is new in /open/EHR, and provides a greatly improved capability for integration. The standard approach to /open/EHR templates is to express them in a generic formalism, which has an associated generic XML schema. However with a single transform, a TDS can be generated for each template. The resulting schema is hard-wired to the template's contents, and suited for XML data transformation and communication, for example as a message. This allows data sources such as pathology laboratories to generate their content according to schemas directly describing their result types, without having to understand /open/EHR. The same logic follows for any kind of content. The TDS approach holds great promise for integration because any data that conforms to TDS .xsd in the standard XML fashion is guaranteed to be convertible to standard /open/EHR content format. The capability of producing TDSs from templates is effectively a facility for machine-generation of message definitions, replacing previous manual message definition approaches. Ocean has now had quite a lot of real world experience with this approach for all sorts of integration problems including messaging and legacy data conversion. regards Hugh On 19/05/2009 12:04 AM, demski wrote: Hello, we have created a template with the Template Designer (Version 2.4). It contains the Report archetype (openEHR-EHR-COMPOSITION.report.v1) that is built as a composition that allows to put generic content in it. We put e.g. some Lab-Data in. When we export the Template Data Schema we get a schema file that seems not to be compatible with the openEHR information model. Please have a look at the code snippet i provide below the text! A compostition must have a content element. In the schema definition that we get from the Template Designer the content element definition is missing. Instead we get an definition for Laboratory_findings that in my eyes is wrong. It simply should be named content and the label Laboratory findings should show up only in the name element of the content element (as it does anyway). Moreover there are no items elements within the schema. Here it is the same as for the content element - the names of the nodes are placed instead. We have discovered this as a problem while trying to apply the openEHR base.xslt stylesheet that did not fit to data that we generated while using the schema obtained from the Template Designer. Am i misinterpreting the definitions or is this a bug in the Template Designer? hope to get help from the experts on the list ;-) brgds Demski code snippet begin -- xs:element name=Report xs:complexType xs:sequence xs:element name=name xs:complexType xs:sequence xs:element name=value type=xs:string default=Report/ xs:element name=mappings type=oe:TERM_MAPPING minOccurs=0 maxOccurs=unbounded/ xs:element name=defining_code type=oe:CODE_PHRASE minOccurs=0/ /xs:sequence /xs:complexType /xs:element . . . xs:element name=*Laboratory_findings*
XSD incompatibilites with XSLT code
Hello, we have created a template with the Template Designer (Version 2.4). It contains the Report archetype (openEHR-EHR-COMPOSITION.report.v1) that is built as a composition that allows to put generic content in it. We put e.g. some Lab-Data in. When we export the Template Data Schema we get a schema file that seems not to be compatible with the openEHR information model. Please have a look at the code snippet i provide below the text! A compostition must have a content element. In the schema definition that we get from the Template Designer the content element definition is missing. Instead we get an definition for Laboratory_findings that in my eyes is wrong. It simply should be named content and the label Laboratory findings should show up only in the name element of the content element (as it does anyway). Moreover there are no items elements within the schema. Here it is the same as for the content element - the names of the nodes are placed instead. We have discovered this as a problem while trying to apply the openEHR base.xslt stylesheet that did not fit to data that we generated while using the schema obtained from the Template Designer. Am i misinterpreting the definitions or is this a bug in the Template Designer? hope to get help from the experts on the list ;-) brgds Demski code snippet begin -- xs:element name=Report xs:complexType xs:sequence xs:element name=name xs:complexType xs:sequence xs:element name=value type=xs:string default=Report/ xs:element name=mappings type=oe:TERM_MAPPING minOccurs=0 maxOccurs=unbounded/ xs:element name=defining_code type=oe:CODE_PHRASE minOccurs=0/ /xs:sequence /xs:complexType /xs:element . . . xs:element name=*Laboratory_findings* minOccurs=0 maxOccurs=unbounded xs:complexType xs:sequence xs:element name=*name* xs:complexType xs:sequence xs:element name=value type=xs:string fixed=*Laboratory findings*/ xs:element name=mappings type=oe:TERM_MAPPING minOccurs=0 maxOccurs=unbounded/ xs:element name=defining_code type=oe:CODE_PHRASE minOccurs=0/ /xs:sequence /xs:complexType /xs:element code snippet end code snippet begin -- xs:element name=data xs:complexType xs:sequence xs:element name=HbA1c xs:complexType xs:sequence xs:element name=name xs:complexType xs:sequence xs:element name=value type=xs:string default=HbA1c/ xs:element name=mappings type=oe:TERM_MAPPING minOccurs=0 maxOccurs=unbounded/ xs:element name=defining_code type=oe:CODE_PHRASE minOccurs=0/ /xs:sequence /xs:complexType /xs:element . . . xs:attribute name=archetype_node_id type=oe:archetypeNodeId use=required fixed=at0003/ xs:attribute name=type use=required fixed=ITEM_TREE/ /xs:complexType /xs:element code snippet end
