Dear Thomas, Why do we (CIMI) need a TDD? Isn't a TDD a transformation that is used during the implementation of a Template.
We in CIMI -I think, we agreed- is about Clinical Information Models. CIMS. CIMS that can be transformed to openEHR expressions, 13606 expressions, CDA, all expressed as constraints on there respective Reference Models. These CIM's, once transformed, are used in Templates that will be used locally. And only then at implementation time implementers want something in XML. And that is the TDD. I think it is completely out of scope for CIMI to talk about Archetypes expressed as constraints on their Reference Model and it is even more out of scope to deal with Templates and it is absolutely out of scope to deal with implementation issues such as XML representations of an implementable Template designed for local use. Gerard Freriks +31 620347088 gfrer at luna.nl On 14 jun. 2013, at 12:31, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > On 14/06/2013 08:56, Gerard Freriks wrote: >> Hi, >> >> While we are at it. >> >> -1- >> Why do we need a TDD? >> Isn't a Template just a Composition archetype with Sections archetypes and >> ENTRY archetypes and Cluster archetypes and Element archetypes plus data >> types. > > that's what a template is; but a TDD (Template Data Document) is something > different. It's not an XML instance of the canonical (i.e. RM) information > model XSD, it's an instance of a transform of that, called a TDS (Template > Data Schema). > > A TDS is something like a 'green CDA' schema but generated from the AOM > template structure. The tag set is a mixture of standard RM attribute names > (like 'start_time', 'events', etc), and for the data attributes, names > derived from the archetype node ids, i.e. things like 'serum_sodium', or > 'total_cholesterol'. The result is an XSD whose tagset consists of basic > openEHR context attributes (always the same) and template specific data > attribute names. > > There is therefore one TDS per template - each TDS is its own schema. > > A TDD is an XML document instance of a TDS. > >> In addition as many possible degrees of freedom need to be constrained so as >> to reflect the agreement between the two exchanging actors. >> In all aspects they rare nothing but an archetype in my part of the world. >> The peculiar thing about templates is that they are for prime time actual >> use/deployment. > > that's true, but not only that - you need templates to define a data set of > any kind. Except in some coincidental cases (like some labs), archetypes > don't on their own define useful or complete data-sets. So if a government > wants to mandate a discharge summary or e-referral document, they need to > define a template to do that, made up of specifically chosen attributes from > a set of chosen archetypes. Data sets are ad-hoc collections of individual data points. They are out of scope for CIMI, I think. We need to bother ourselves with 'How do we model the individual data points and all their context? > >> >> -2- >> Transformations: >> The Template (archetype) has node names changed in places (and therefor >> their meaning). > > At a technical level, the 'meaning' of each node can't be changed from the > archetype - and that is the meaning that is computed with. I agree that in > some cases, the clinical meaning may be different, but it should always be > refined, not arbitrarily different. ADL/AOM 1.5 addresses this properly and > makes all template refinements regular and computable. One can compute as much as we like. When we specialize we change meaning (Names of the rate fact and the nodes, Constraints, Codes attached) The at-code can be the same, and that is what is used to compute with. Even a 'refined' node name means changing the meaning into a 'refined meaning'. > >> They are more complex in places (because new branches) have been added, less >> complex in places (because branches are not used), more constrained in >> places than the pure parent archetype. > > Currently, no new data at all can be added in an opernEHR template, and no > new branches. The only 'new' thing that can be added is clones of existing > archetype nodes to account for specific multiplicities required by that data > set. I equate archetypes with templates. Only Templates are defined to be implemented in a local temporal context and will contain: EHR-Extract, one or more Composition, Entry and Elements as minimum component. Archetypes (and CIMI is talking archetypes) can be changed in any that I indicated. Even at run-time archetype slots can be inserted when needed when used inside a template. > >> >> To write generic transformations is not trivial, I expect. >> If possible at all. > > For TDD -> canonical openEHR (and this would be the same for 13606, CIMI etc) > it's not completely trivial, but it's not hard - transformers doing this have > been in production for some years how. > > I don't know if anyone has written a canonical -> TDD transformer, and I am > not even that clear on what the need would be, but (see my other post), it > would be nearly trivial, assuming that a reasonable TDS was designated as the > default target. The question is: How much information is lost as a result of the transformation of a Template to an XML derivative? But again: I think all this implementation stuff is outside the scope of CIMI. > > - thomas > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/4b193f3d/attachment.html>
