Hi Tom, On Fri, 2010-12-03 at 21:48 +0000, Thomas Beale wrote: > the general idea has always been that data can always be interpreted > by a receiver using just the archetypes declared in the data. I > believe this will continue to be a reliable assumption into the > future.
So this begs the question. Do you think that there is a possibility that it will NOT continue to be a reliable assumption? > However, with the new style templates, which are essentially just > archetypes, it may be that templates will be shared quite often as > well, since the computing machinery that can deal with archetypes will > be able to deal with ADL 1.5 templates as well (with only very minor > upgrades from today, since we are talking about operational templates, > which are essentially big archetypes). So in a paragraph or less can you explain the difference between templates and simply constructing archetypes that use slots for extendability? > This is not going to add much information, since the information > structures themselves (i.e. the compositional hierarchy of > Composition, Sections, Entries etc) will reflect the structure of the > template that was used. But if the receiver wants to validate the > received data against the template, But if the data validates against the archetype(s) (and therefore the reference model) there is no need to validate against templates. > and if the receiver is interested in what the template says, then it > means they probably have some agreement with the sender institution > about using their templates. Correct. So this is not a technical issue at all. It is a socio-political issue. > This will almost certainly happen with nationally standardised > templates for referrals, discharge summaries and so on. Makes sense. > In summary: displaying and using the data with just the archetypes > used to build it will be fine, since the data will reflect accurately > the removed optional items, reduced terminology choices etc. Actually the data will reflect the 'chosen' option(s). It is a historical artifact. > Any site wanting to do processing against the template will > undoubtedly be in some kind of communication with the publisher of the > template. Right; and otherwise the data is still valid against the archetype and should be valid in any conforming application. Since my original question was asking for a use case where templates were required to fully interpret the data. Based on this assertion: On Wed, 2010-12-01 at 23:04 +0100, David Moner wrote: > This specific use further constrains archetypes and these kind of > structural templates should be also shared as the archetypes > themselves since they will be needed to fully interpret the data. David and I agree that GUI directives have no place in structural definitions. Therefore, templates should not filter out existing (valid) data. At least I think that is what he is saying. But the point I am making is that templates do not have to be shared in order to interpret the data. Again, the only information a template can add is what particular subsets were available at the time a specific entry was chosen. I simply do not see a purpose for this 'requirement'. The data has been entered. It is now part of a historical record. Since the archetype describes the data model of the concept as a set of constraints against the reference model. That is all the validation required. Again, if I am missing something I am very interested in what it is. Thanks, Tim -- *************************************************************** Timothy Cook, MSc Project Lead - Multi-Level Healthcare Information Modeling http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link http://timothywayne.cook.googlepages.com/home -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101203/870bf0b7/attachment.asc>
