On 22/10/2014 14:07, Bert Verhees wrote:
> On 22-10-14 13:10, Ian McNicoll wrote:
>> In practice this means that if I create a .opt , I can upload this to
>> one of these systems and it will be ready to use, with no need to
>> upload or manage the individual archetypes.
>
> This is in fact an interesting thought. It could mean the end of
> archetypes. They only need to exist virtual, as inner-parts of templates.
> The system does not need to know them, as long as the template
> designer says they exist, somewhere, and on other existence, they are
> the same.
except for one tiny detail - queries are built using archetype ids and
paths, not templates. The data need to know the archetype ids, so that
querying works. This is fundamental - it is what allows (say) BP data
created using the BP archetype in 100 different templates to still be
queried /without knowing //anything about these templates/. In other
words, no matter what template you build tomorrow containing a given
archetype, all queries for the data in that archetype will automatically
work with the newly created data of that template.
OPTs are a compiled form of a template, including all of its archetype
information, in an efficient form. In the near future, we will define
different ways of generating OPTs that do things like:
* optionally replace DV_CODED_TEXT constraints with their bindings
(which could be say SNOMED codes or refset refrences)
* optionally remove unneeded languages, e.g. Arabic and Korean won't
be needed in the Netherlands
* optionally remove some or all unused / unneeded terminology bindings
* potentially convert to different output forms, e.g. different kinds
of XML non-XML forms.
Regardless of all this, the OPT will still carry all the archetype ids.
This is what provides the data with its semantic markers.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141022/3be3d99d/attachment.html>
