Update on meta-data for openEHR and 13606

Thomas Beale thomas.beale at oceaninformatics.com
Mon Jan 27 09:27:02 EST 2014


On 27/01/2014 13:37, Diego Boscá wrote:
> Just a couple of comments:
>
> Do really is_template & is_overlay need to be mandatory?

well they are only mandatory due to being Booleans, and in standard 
programming languages, Boolean (or bool or whatever) is a builtin type 
that is always there. In XML and other serialisations, it's true that 
anything can be optional (normally absence = False for Boolean). I 
should probably change this to reflect that.

> I would say that they can be optional if you are dealing with 
> archetypes (assuming that all archetypes are just archetypes by default).
> What does exactly 'is_overlay' refers to?

an overlay is a cut-down archetype that is used as a template-specific 
slot-filler to provide the overrides on a standard slot filler. E.g. say 
you want to put 'symptom' CLUSTER archetype in a CLUSTER slot for 
template T, but just for that template you also want to remove 3 of the 
5 data points of the symptom structure. So you create a specialised 
(1.5) archetype that does that just for that template. It's the same as 
any other specialised archetype, except it has almost nothing in the 
description section, because it gets all that from the template. So an 
overlay can't be used standalone, but obviously, tools could convert one 
to a real archetype.

In 1.5, a template is essentially a specialised archetype with a bunch 
of other filler archetypes, templates and / or overlays (maybe all 
overlays).

>
> Also, I think that you could argue that version_status is more 
> suitable to be placed into the resource_description instead of where 
> it is now.

version_status, or something equivalent is needed with the version_id 
attributes, so that the full version id can be constructed, e.g. 
1.0.4-rc28 - the version_status is what tells you that it's an 'rc' 
(release candidate), full release (1.0.4), uncontrolled additions 
(1.0.4+u88) and so on. It's related to the lifecycle_state, which has 
more values like 'initial', 'obsolete', and so on, according to this 
state diagram 
<http://www.openehr.org/wiki/download/attachments/5996562/artefact_lifecycle_versioning.png?version=1&modificationDate=1366562248000&api=v2>. 
There is overlap but it seems unavoidable to me.

- thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140127/0892d35a/attachment.html>


More information about the openEHR-technical mailing list