The Template Data Schema is (TDS) an XML schema generated from an openEHR operational template (.OPT) that has a tag set derived from a combination of the openEHR RM and archetypes.
The business value of a TDS to a developer/integrator is that:
- it is relatively easy to understand TDS and TDD, since most 'interesting' tags are created from the names given in template and archetypes, and are thus have directly meaningful/recognized tag names like "Family_History_Summary" (instead of generic RM-type names like "DV_TEXT" combined with at-codes like "at0001").
- XML data conforming to a TDS, which we call a Template Data Document (TDD) can be validated using industry-standard XSD tools
- it functions as a schema definition for a single 'message', i.e. the data set of one template
There are three things of interest to specify: the OPT to TDS transform; TDD to canonical RM transform; RM to TDD transform.
The information on this page will be used to create a new openEHR specification on TDS and TDD.
Previous TDS/TDD work
The original TDS/TDD mechanism was developed by Ocean Health Systems. Current versions of the Ocean Template designer (e.g. version 2.8) can generate a TDS (version 2?) file from the currently open template (by menu selection: File > Export > as Template Data Schema...)
TDS3 (a new 2016 version of TDS) discussed during the SEC Feb 2016 Meeting:
Heath Frankel at Ocean Informatics has developed a new TDS format and associated transform creating more compact and readable data instances (TDD). The plan is now to release the XSLT transform and some overview documentation of transform algorithms. (ADD JIRA PR/CR HERE WHEN AVAILABLE). Some notes from SEC meeting:
- A TDS-revision attribute (or element) needs to be added since a TDS might need new versions etc even if the template ID has not changed
- Marand has been using template annotations making it possible to override auto-generated id's
- Making it possible to use annotations to override value codes in value sets can be useful (e.g. to replace at0023 with something meaningful for developers)
OPT to TDS Transform (TDS-XSD generation rules)
Informal specification:
- tagging:
- default tag for each node is from reference model (RM), and uses oe: namespace
- for any object node (AOM C_OBJECT) that is a child of a multiply-valued attribute (AOM C_ATTRIBUTE), use a tag generated from text the id-code (ADL1.4: at-code) of the node (default namespace)
- possible option: case where only a single object node is present under a container attribute - can use oe: tag.
- XML attributes:
- where an OPT C_OBJECT node has an rm_type_name value that is an abstract RM type, or the child of an abstract RM type, an XML tag is required of the form oe:type='XXXX' where XXXX is the rm_type_name of the node, e.g. 'DV_CODED_TEXT'.
- LOCATABLE.name override from template - or use a proper XML element?
- Root node
TDS Tag Generation Algorithm
To convert from a text string in any language to a valid XML tag, use the the following algorithm.
TBD
TDD to Canonical RM Transform (TDD-XML consumption rules)
TBD
Canonical RM to TDD Transform (TDD-XML generation rules)
TBD
See also...