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@luna.nl
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 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. 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.
It seems to be on the roadmap http://www.openehr.org/programs/specification/roadmap and described there anyway…
I think the lesson we needed to learn (are still learning) is not to improve the technology, but to improve the educational materials. I look forward to seeing more community input on that in the future.