Finalising archetype meta-data

Technical (archive)
1

There is a test archetype here that shows an example of proposed new meta-data items.

Things to notice:

  • ‘rm_release=1.0.2’ in the top line. Rm_release is now a mandatory item in ADL 2 (but easy to synthesise in converters)
  • ‘copyright’ is now at the outer level, before it was in the translatable part, i.e. with ‘keywords’ etc - now there is only one copyright statement for an archetype
  • ‘licence’ is a new item
  • there are items for ‘original_xxx’ and ‘custodian_xxx’ intended to document the original organisation that created something, and the current custodian of that thing.
  • proposed new blocks for ‘ip_acknowledgements’ and ‘conversion_details’

A question I have is: are the items for original publisher / namespace and custodian organisation enough?

Currently they are as follows:

original_namespace = <“org.archetypes-r-us”>
original_publisher = <“Archetypes R Us”>
custodian_namespace = <“org.openehr”>
custodian_organisation = <“openEHR Foundation”>

However, if we thing we need any more items for these two, we are stuck with this model - the only place we could put new items would be in the main ‘other_details’ block. Should we instead do the following:

original_publisher = <
organisation = <“Archetypes R Us”>
namespace = <“org.archetypes-r-us”>
other_details = <
[“key”] = <“value”>
[“key”] = <“value”>
…

custodian = <
organisation = <“openEHR Foundation”>
namespace = <“org.openehr”>
other_details = <
[“key”] = <“value”>
[“key”] = <“value”>
…

This is only slightly more complex, but much more flexible. As we are finalising the ADL/AOM 2 specifications, this is one of the last issues, so now is a good time to decide if we need to change this.

It is worth noting that we have done the ip_acknowledgements and conversion_details (both imminently needed by CIMI) differently:

ip_acknowledgements = <
[“loinc”] = <“This content from LOINC® is copyright © 1995 Regenstrief Institute, Inc. and the LOINC Committee, and available at no cost under the license at http://loinc.org/terms-of-use”>
[“snomedct”] = <“xyz”>

conversion_details = <
[“source_model”] = <“CEM xyz http://location.in.clinicalelementmodels.com”>
[“tool”] = <“cem2adl v6.3.0”>
[“time”] = <“2014-11-03T09:05:00”>

This is because in the first case, the structure is logically a keyed list of values, where we never know the keys, and in the ‘conversion_details’ case, because we are not currently sure of the keys (and maybe we’ll never have standard keys for that).

  • thomas
2

Hi Thomas,
I am not sure why we can’t use other-details for all of these. It doesn’t seem critical for processing archetypes, it is only for reference.

Regards

Heath

3

We could use other_details. However, the downside is that none of the tags are standardised when you do that, so you always run the risk of different tools / users creating variant structures they think will match but don't (even just not agreeing on international v US English for example). We'll always have to use other_details for things we don't know yet anyway, but where we think we know the logical 'tags', it may make sense to add them to the model as such.

- thomas

(attachments)

oceanfullsmall.jpg
btnliprofileblue80x15.png