Hi Gerard, Comments in-line below
On 14 June 2013 08:56, Gerard Freriks <gfrer at luna.nl> 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. > IAN: Yes. That is true in both ADL1.4 and ADL 1.5 operational templates. We do not need TDDs but we have found them very helpful when working with non-openEHR specialists as they considerably simplify the target for them to work with, particularly for integration projects. The TDS/TDD removes some of the less commonly used complexity in the raw openEHR schema and creates xml tags with business names. This is a very similar philosophy to that driving the Green CDA work and indeed FHIR, by placing a simpler, flatter layer over the more complex raw formalism. Having a single generic TDD-Canonical transform makes this very powerful since any TDD can be converted to canonical XML without further effort. Most of the commercial openEHR CDRs actually package this behind a ComittTDD service call. > 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. > IAN: I agree. That is why in ADL1.5 the archetype and template formalism is identical. In essence a template then becomes just a conformance statement / stakeholder agreement > The peculiar thing about templates is that they are for prime time actual > use/deployment. > > IAN: Exactly, since they tighten up some of the mandation constraints, apply local term-bindings and remove elements which are out of scope for this business case, making the final artefact easier for developers to work with. -2- > Transformations: > The Template (archetype) has node names changed in places (and therefor > their meaning). > IAN: That is correct but the original archetype node name is always preserved and carried in the template. We try very hard to avoid carrying semantics in the overriden node names, and tend to use this simply to rename the nodes to reflect the local usage and align with requirements documentation, without changing the semantics. In the future I would expect that this will become more tightly controlled e.g by using SNOMED-CT synonyms. 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. > > IAN: Correct although there is never any new content that is not defined in the underlying archetype. There are never any new branches, other than those which are allowed to be multiply occurenced in the underling archetype. Essentially this is the only difference (in ADL 1.5) between a specialised archetype and a template. The former can add new branches in the specialisation, a template cannot. > To write generic transformations is not trivial, I expect. > If possible at all. > > IAN: Well not trivial but the TDD->Canonical transform works very well. As I said in my reply to Daniel, I do not think a single reverse transform is possible but a single reverse transform generator might be possible, based on the operational template. Regards Ian Gerard Freriks > +31 620347088 > gfrer at luna.nl > > On 14 jun. 2013, at 09:41, Daniel Karlsson <Daniel.Karlsson at liu.se> wrote: > > Hi Ian, > > On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote: > > Hi Erik, > > > The Ocean TDD->canonical transform is available at > > > http://openehr.codeplex.com/SourceControl/latest#176376 > > > > look for TDD_to_openEHR.xsl > > > As far as I know a generic reverse transform is not possible. > > > How could that be? Is there something in the TDD format that is not in > the RM format? The intuition tells me that it should be easier going > from the rich RM format to the TDD format than in the opposite > direction. What are the specific issues that make a reverse > transformation problematic? Could anything be changed to make the > transformation possible? > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/e513d0c7/attachment-0001.html>
