See below Gerard Freriks +31 620347088 gfrer at luna.nl On 14 jun. 2013, at 11:09, Daniel Karlsson <daniel.karlsson at liu.se> wrote:
> On Fri, 2013-06-14 at 09:56 +0200, 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. > With ADL 1.5, yes I believe. We, EN13606 Association, use the ADL1.4 spec in our tool: LinkEHR. This is sufficient for our and CIMI purposes, we believe. > >> 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. > Ok > >> The peculiar thing about templates is that they are for prime time >> actual use/deployment. > What's peculiar about that? 'Normal' archetypes can be produced just to produce other archetypes at design time. Templates are for specific use in a specific context and moment in time when actors define a screen or the content of an exchange. Of course Templates can be designed as templates to be used in local contexts. Archetypes can not be used without the Composition because a lot of the audit info and other info needed for versioning is defined at the Composition level. The meta-data about the pay load is defined in the EHR-Extract. Templates are mostly EHR-EXtracts with Compositions inside. > >> >> -2- >> Transformations: >> The Template (archetype) has node names changed in places (and >> therefor their meaning). > No, these are (should be) just two alternative serializations of the > same meaning. However, what constitutes the meaning of an archetype is > not a trivial question. When specializing an archetype the name (and meaning) changes. When originally the Name node is ENTRY it can be changed in specialization to ENTRY:Observation Or into ENTRY:Observation:ClinicalFinding Or into ENTRY:Observation:ClinicalFinding:BodyTemperature The names are different and therefore their meanings. Although all names are related to each other. >> 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. > Here I must confess I don't understand your use of the word "complex". > E.g. if there in an openEHR model is two specific named events in an > observation which are expanded in the TDD (isn't it??) does this > increase or decrease complexity? In a parent one node can allow zero to many siblings In a specialisation we can constrain it to any within the limits as specified by the parent. When allowed we can remove branches with zero-to-zero constraints and not use them at all. We can insert (when allowed) in places additional nodes (new banches) that were not in the parent. >> >> >> To write generic transformations is not trivial, I expect. >> If possible at all. > I do not agree. I believe this is what every implementer necessarily has > to do, to provide a two-way transformation between a canonical form and > any serialization and/or persistence form with a different set of > requirements (query performance, OLTP vs. OLAP, space requirements, > legacy systems integration, etc. etc. etc.). Not trivial but done on a > regular basis. > Using the 13606 AOM based tools it must be possible to track the whole provenance of any archetype/template. (There is a problem known for Archetype Slots and keeping track of the original choices that were expressed.) Although the template might be a sub-set in places and a super set in other places, all must conform to the Reference Model and all parent archetypes that were used in the chain of specializations. Without the complete set of artifacts the transformation will be NOT possible, Tracking all these changes that were made to the parent archetype > > Cheers, > Daniel > >> 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 > > > > _______________________________________________ > 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/ccc304ad/attachment-0001.html>
