TDS (and TDD) implementations?
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? /Daniel > > > There are at least 3 or 4 companies using TDD as part of their CDR > offering. > > > It would be good to make this part of the managed standard and public > spec . > > > Ian > > > > On 30 May 2013 10:21, Erik Sundvall wrote: > Hi! > > > Which projects and products out there support TDS (Template > Data Schema)? And do they support conversion of TDDs (Template > Data Documents) to standard "canonical" openEHR RM instances > (in e.g. XML)? Is there any available XSLT, webservice or > other thing that can convert bidirectionally between TDD and > openEHR RM-based instances? > > > What about a TDS specification? Is there any published or > work-in-progress document? If not is there any entity, group > or person that could/should be sponsored or bribed to produce > such a thing? :-) It seems to be on the > roadmap http://www.openehr.org/programs/specification/roadmap and > described there anyway... > > > I think TDS is an essential component in the toolbox in > practical openEHR integration projects but without a public > spec, it will be harder to take seriously and hard to make > compatible implementations. > > > (ExampleTDS-info for people not familiar with the > approach: > http://www.mz.gov.si/fileadmin/mz.gov.si/pageuploads/eZdravje/Novice/gradiva_predstavitve_dogodkov/Open_EHR/7_integration.pdf) > > > Best regards, > Erik Sundvall > Tel: +46-72-524 54 55 > LiO: erik.sundvall at lio.se > http://www.lio.se/Verksamheter/IT-centrum/ > LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ > > ___ > 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 > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
TDS (and TDD) implementations?
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. 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. -2- Transformations: The Template (archetype) has node names changed in places (and therefor their 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. To write generic transformations is not trivial, I expect. If possible at all. Gerard Freriks +31 620347088 gfrer at luna.nl On 14 jun. 2013, at 09:41, Daniel Karlsson 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? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/ddeb7b6f/attachment.html>
TDS (and TDD) implementations?
Hi We designed the process to allow ant XML schema generated to be transformed to openEHR with a single transform. I expect it may well be possible to do the reverse. At least it would be possible to get to a consistent flattened form. The reason for the TDS is to validate data using XML tools. Cheers Sam Dr Sam Heard FRACGP, MRCGP, DRCOG, FACHI Chairman, Ocean Informatics Chairman, openEHR Foundation Chairman, NTGPE +61417838808 From: Daniel Karlsson<mailto:daniel.karls...@liu.se> Sent: ?14/?06/?2013 5:12 PM To: openehr-technical at lists.openehr.org<mailto:openehr-technical at lists.openehr.org> Subject: Re: TDS (and TDD) implementations? 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? /Daniel > > > There are at least 3 or 4 companies using TDD as part of their CDR > offering. > > > It would be good to make this part of the managed standard and public > spec . > > > Ian > > > > On 30 May 2013 10:21, Erik Sundvall wrote: > Hi! > > > Which projects and products out there support TDS (Template > Data Schema)? And do they support conversion of TDDs (Template > Data Documents) to standard "canonical" openEHR RM instances > (in e.g. XML)? Is there any available XSLT, webservice or > other thing that can convert bidirectionally between TDD and > openEHR RM-based instances? > > > What about a TDS specification? Is there any published or > work-in-progress document? If not is there any entity, group > or person that could/should be sponsored or bribed to produce > such a thing? :-) It seems to be on the > roadmap http://www.openehr.org/programs/specification/roadmap and > described there anyway... > > > I think TDS is an essential component in the toolbox in > practical openEHR integration projects but without a public > spec, it will be harder to take seriously and hard to make > compatible implementations. > > > (ExampleTDS-info for people not familiar with the > approach: > http://www.mz.gov.si/fileadmin/mz.gov.si/pageuploads/eZdravje/Novice/gradiva_predstavitve_dogodkov/Open_EHR/7_integration.pdf) > > > Best regards, > Erik Sundvall > Tel: +46-72-524 54 55 > LiO: erik.sundvall at lio.se > http://www.lio.se/Verksamheter/IT-centrum/ > LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ > > ___ > 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 > > ___ > 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/c0e3ea26/attachment-0001.html>
TDS (and TDD) implementations?
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. > 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? > > -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. > 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? > > > 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. Cheers, Daniel > Gerard Freriks > +31 620347088 > gfrer at luna.nl > > On 14 jun. 2013, at 09:41, Daniel Karlsson > 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
TDS (and TDD) implementations?
cs, 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 > > > > ___ > > 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 > > ___ > 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/c4c77563/attachment.html>
TDS (and TDD) implementations?
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>
TDS (and TDD) implementations?
BCS Primary Health Care www.phcsg.org >> >> ___ >> 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 > -- Ocean Informatics <http://www.oceaninformatics.com/>*Thomas Beale Chief Technology Officer* +44 7792 403 613Specification Program, /open/EHR <http://www.openehr.org/> Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/> Health IT blog <http://wolandscat.net/category/health-informatics/> View Thomas Beale's profile on LinkedIn <http://uk.linkedin.com/in/thomasbeale> -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/d36965e5/attachment.html> -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 4085 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/d36965e5/attachment.jpg> -- next part -- A non-text attachment was scrubbed... Name: btn_liprofile_blue_80x15.png Type: image/png Size: 511 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/d36965e5/attachment.png>
TDS (and TDD) implementations?
Hi Gerard, Comments in-line below On 14 June 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. > 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 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>
TDS (and TDD) implementations?
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. > > -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. > 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. > > 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. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/4658baa5/attachment.html>
TDS (and TDD) implementations?
On 14/06/2013 10:09, Daniel Karlsson wrote: >> >> 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. > > Just to clarify to everyone (who may not be completely following here)... there are 2 types of serialisations of data that can be done, according to the following chains: * canonical object RM form -> canonical XML form o -> XML will be an instance of the standard openHER (/ other) XSD o all such XML instances conform to the one schema, worldwide... * canonical object RM form -> TDS XML form, known as TDD o -> XML will be an instance of each TDS, where there is one TDS for each Template o all instances of a given TDS conform to that TDS, but of course not to another TDS o TDD -> canonical data transform is needed to put the data into patient-centric longitudinal form, so that different data streams from different places / applications (but often containing the same logical data, e.g. vital signs) can be aggregated and computed with Both transforms have been implemented and in use for some years now. The reverse transform (canonical data -> TDD) I don't think has ever been implemented because currently it's not that useful. It would become useful if we were to start to standardise on 'openEHR messages', i.e. TDSs that would act as message standards. The advantage of these over current message standards would be that a) the payload is generated from single source models and b) the payload is separated from the message envelope and control aspects of the infrastructure. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/713ce15a/attachment.html>
TDS (and TDD) implementations?
Hi Gerard, see below... On Fri, 2013-06-14 at 11:54 +0200, Gerard Freriks wrote: > > See below > Gerard Freriks > +31 620347088 > gfrer at luna.nl > > On 14 jun. 2013, at 11:09, Daniel Karlsson > 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. Ok > > > > > > > > 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 That's fine, but serializing is not specializing. Templates also allow specializing (that is in a way what templates do) as does archetypes so there's an overlap. But that's a separate (and important) issue. I was asking about the possibility of having more compact serialization formats. > > 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. Can you provide an example because I thought the latter was not allowed (depending on what a branch is). > > > > > > > > > > > > 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, as I said I don't think this is the case, but if there are issues these should be discussed and straightened out. Do you have specific examples or template functions where templates loosen constraints? > 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, that's fair, but trivially true. Templates (or any
TDS (and TDD) implementations?
type 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>
TDS (and TDD) implementations?
Well, in ADL specialization allows extension >From here >(http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL&AOM1.5-SpecialisationSemantics) "extensions, i.e. object constraints added to a container attribute with respect to the corresponding attribute in the parent archetype, but only as allowed by the underlying reference model." So new nodes that change completely the meaning can be added. 2013/6/14 Daniel Karlsson : > Hi Gerard, > > see below... > > On Fri, 2013-06-14 at 11:54 +0200, Gerard Freriks wrote: >> >> See below >> Gerard Freriks >> +31 620347088 >> gfrer at luna.nl >> >> On 14 jun. 2013, at 11:09, Daniel Karlsson >> 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. > Ok >> >> >> >> > >> > > 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 > That's fine, but serializing is not specializing. Templates also allow > specializing (that is in a way what templates do) as does archetypes so > there's an overlap. But that's a separate (and important) issue. I was > asking about the possibility of having more compact serialization > formats. >> >> 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. > Can you provide an example because I thought the latter was not allowed > (depending on what a branch is). >> >> >> >> > > >> > > >> > > 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
TDS (and TDD) implementations?
Gerard, Ian, Thomas, thanks for all answers. On Fri, 2013-06-14 at 11:17 +0100, Thomas Beale wrote: > > Let me clarify a few things here. > > There are many possible TDSs that can be generated from a given > template. Some users want a 'flat schema' with minimal meta-data, > which makes working with integration data easier, but a TDD (TDS XML > document) -> canonical transformer harder to write (it has to look up > more from the archetypes.) > > Some users are happy with a fully featured schema that enables a > nearly trivial TDD -> canonical converter to be written. > > Some users want specific things like certain code annotations, or > hidden node markers or whatever, which in some cases can only be > obtained if they are in the annotations of the template or archetype > (i.e. most archetypes / templates won't have these specific > annotations). > > So, if we want to do a canonical -> TDD transform from a primary > openEHR repository, it means choosing which particular kind of TDS is > being targetted. If there were a default TDS for openEHR (we should > standardise on that), then canonical -> TDD could be implemented and > deployed, probably quite easily. Such a standard TDS/TDD would have made the Swedish 2009-10 quality registry project significantly easier and a lot of the criticism towards openEHR could have been rejected. We more or less constantly had to reply to questions as to why use archtypes/templates using up several kilobytes when anyone can write an XSD for a specific use case using up a fraction of that space. The obvious conclusion is that we (as in Sweden) ourselves should have started that project. It's not always easy being an openEHR advocate ;). > It's just a question of what the community thinks is important. > > - thomas > > > On 14/06/2013 08:41, Daniel Karlsson 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? > > > > /Daniel > > > > > > There are at least 3 or 4 companies using TDD as part of their CDR > > > offering. > > > > > > > > > It would be good to make this part of the managed standard and public > > > spec . > > > > > > > > > Ian > > > > > > > > > > > > On 30 May 2013 10:21, Erik Sundvall wrote: > > > Hi! > > > > > > > > > Which projects and products out there support TDS (Template > > > Data Schema)? And do they support conversion of TDDs (Template > > > Data Documents) to standard "canonical" openEHR RM instances > > > (in e.g. XML)? Is there any available XSLT, webservice or > > > other thing that can convert bidirectionally between TDD and > > > openEHR RM-based instances? > > > > > > > > > What about a TDS specification? Is there any published or > > > work-in-progress document? If not is there any entity, group > > > or person that could/should be sponsored or bribed to produce > > > such a thing? :-) It seems to be on the > > > roadmap http://www.openehr.org/programs/specification/roadmap and > > > described there anyway... > > > > > > > > > I think TDS is an essential component in the toolbox in > > > practical openEHR integration projects but without a public > > > spec, it will be harder to take seriously and hard to make > > > compatible implementations. > > > > > > > > > (ExampleTDS-info for people not familiar with the > > > approach: > > > http://www.mz.gov.si/fileadmin/mz.gov.si/pageuploads/eZdravje/Novice/gradiva_predstavitve_dogodkov/Open_EHR/7_integration.pdf) > > > > > > > > > Best regards, > > > Erik Sundvall > > > Tel: +46-72-524 54 55 > > > LiO: erik.sundvall at lio.se > > > http://www.lio.se/Verksamheter/IT-centrum/ > > > LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ > > > > > > ___ > > > openEHR-technical mailing list > > > openEHR-technical at lists.openehr.org > > > > > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > > > > > > > > > > > > ___ > > > openEHR-technica
TDS (and TDD) implementations?
On 14/06/2013 10:54, Gerard Freriks wrote: > Templates are mostly EHR-EXtracts with Compositions inside. I imagine that is probabaly true in 13606-land. It's so far uncommon in openEHR, but should be used more, and I think will become common with the growing use of the openEHR EHR Extract <http://www.openehr.org/wiki/display/spec/openEHR+EHR+Extract>. There is an example of a templated openEHR Extract <https://github.com/openEHR/adl-archetypes/tree/master/Example/openEHR/ehr_extract_template> in the openEHR test archetypes. > >> > > 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. In openEHR, the name attribute is not what is being constrained; it is the archetype_node_id, i.e. the coding of each attribute. That guarantees that specialisation is computable, and not a function of language or string processing (I'm not sure if that is what you are implying with things like "ENTRY:Observation:ClinicalFinding:BodyTemperature" above). - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/02143ac8/attachment.html>
TDS (and TDD) implementations?
On 14/06/2013 12:12, Gerard Freriks wrote: > Dear Thomas, > > Why do we (CIMI) need a TDD? > Isn't a TDD a transformation that is used during the implementation of > a Template. I have to admit I was surprised to see all this talk of TDD-like things in CIMI. TDS/TDD is more than just a specification, but it doesn't need to be solved in one go with the core modelling requirements - I think CIMI should stick to just the core job for now, and look at TDS/TDD later on. It already has too much work to do and no funding to do it with! > > 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. for CIMI, I would agree with that. > > 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. that's a reasonable way of looking at it. On the other hand, the power of the archetype/template approach is that you can generate a message content specfication straight from the template, as an XSD (i.e. what we call TDS) or for that matter, something else, e.g. JSON schema or whatever, and call that a standard. This could be done for something widely shareable such as emergency summary, basic labs, and vital signs. The TDS form will be the most easily consumable form for most vendors, so it's more than just a purely local concern. But in the end, I would say, leave all this till later in CIMI, if there is to be any hope of timely delivery of models. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/cf40f626/attachment.html>
TDS (and TDD) implementations?
On 14/06/2013 12:31, Daniel Karlsson wrote: > Gerard, Ian, Thomas, thanks for all answers. > > On Fri, 2013-06-14 at 11:17 +0100, Thomas Beale wrote: >> > Such a standard TDS/TDD would have made the Swedish 2009-10 quality > registry project significantly easier and a lot of the criticism towards > openEHR could have been rejected. as I am sure you know, we offered exactly this path to them in 2010 (it had already been running for a couple of years by then)... I am not sure what happened, but it wasn't taken up. I am pretty sure we actually supplied example TDSs, and the Template Designer (which was in use then) could be used to generate this transform on demand (i.e. no special input needed from anyone). > We more or less constantly had to > reply to questions as to why use archtypes/templates using up several > kilobytes when anyone can write an XSD for a specific use case using up > a fraction of that space. The obvious conclusion is that we (as in > Sweden) ourselves should have started that project. It's not always easy > being an openEHR advocate ;). true ;-) 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. - thomas
TDS (and TDD) implementations?
On 14/06/2013 12:19, Diego Bosc? wrote: > Well, in ADL specialization allows extension > > >From here > >(http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633#openEHRADL&AOM1.5-SpecialisationSemantics) > "extensions, i.e. object constraints added to a container attribute > with respect to the corresponding attribute in the parent archetype, > but only as allowed by the underlying reference model." > > So new nodes that change completely the meaning can be added. > They can't change the meaning of any existing specialised node. 'New' nodes aren't really new; they're just more data that were not defined by constraint by any of the parent archetypes of the current archetype. Often this is some specific item of context data relevant only at a deep level, or it might be something specific to the clinical purpose, e.g. cancer staging as a specialisation of diagnosis. That said, as far as I know, the addition of 'new' nodes, as opposed to extra children of an existing node is pretty rare (would be interesting to report on this in the ADL WB I guess). So to be clear, there is nothing abnormal about such nodes: they are normal archetype nodes that happen to be introduced for the first time in a non-top-level archetype. Of course, wherever there is a freedom, it can be exploited in a bad way - that's just bad modelling. It's always possible to do something badly, but I don't think that's a reason for a wholesale ban. If there are users or communities that want to force all archetype specialisation to be strictly children of previously archetyped nodes, it would be easy to make the tool enforce this. This is what next generation template designer tools should do. - thomas
AUTO: Goncalo Castro is out of the office (returning 24.06.2013)
I am out of the office until 24.06.2013. Note: This is an automated response to your message "Re: TDS (and TDD) implementations?" sent on 14.06.2013 9:56:28. This is the only notification you will receive while this person is away. -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately by reply e-mail and delete this message from your system. -- -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/208608ee/attachment-0001.html>
TDS (and TDD) implementations?
Compact serialization? When nodes in the archetype while they are developed and can change in the 'template' level or even during run-time, there never will be a simple serialization to an XML/XDS format. To much is volatile. When you say ' more compact serialization formats' do you mean shorter XML payload that go ver the wire? Observe that when parties decide to be semantically interoperable this means that every data point and all its context needs to be sent over the wire. Full semantic interoperability demands more resources than just updating fields in a database. Gerard Freriks +31 620347088 gfrer at luna.nl On 14 jun. 2013, at 13:01, Daniel Karlsson wrote: >> >> 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 > That's fine, but serializing is not specializing. Templates also allow > specializing (that is in a way what templates do) as does archetypes so > there's an overlap. But that's a separate (and important) issue. I was > asking about the possibility of having more compact serialization > formats. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/a9baa6e5/attachment.html>
TDS (and TDD) implementations?
One simple example: I can have an archetype slot that is filled at run-time as allowed by a regular expression or a hand entered list of possible archetypes that can fill that slot. But there are more examples. Gerard Freriks +31 620347088 gfrer at luna.nl On 14 jun. 2013, at 13:01, Daniel Karlsson wrote: >> >> 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. > Can you provide an example because I thought the latter was not allowed > (depending on what a branch is). -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/8c9d4f5b/attachment.html>
TDS (and TDD) implementations?
The best example is: One ENTRY archetype node that can have one ore more Clusters added to it - when allowed -of course-via Archetype slots at run- or design time. Gerard Freriks +31 620347088 gfrer at luna.nl On 14 jun. 2013, at 13:01, Daniel Karlsson wrote: >> 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, > as I said I don't think this is the case, but if there are issues these > should be discussed and straightened out. Do you have specific examples > or template functions where templates loosen constraints? -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/e9787307/attachment.html>
TDS (and TDD) implementations?
On 14/06/2013 10:38, Ian McNicoll wrote: > Hi Daniel, > > I should have been more precise. I still don't see how it would be > possible to create a single generic Canonical XML -> TDD transform. actually it would not even be all that hard. It is just a case of doing a data-level transform that corresponds to the reverse of the current TDS generator. It would need access to the templates and archetypes, that's all. - thomas
