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 On 20/11/2014 21:16, Heath Frankel wrote: > 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 > > On 21 Nov 2014, at 1:21 am, "Thomas Beale" > <thomas.beale at oceaninformatics.com > <mailto:thomas.beale at oceaninformatics.com>> wrote: > >> >> There is a test archetype here >> <https://github.com/openEHR/adl-archetypes/blob/master/ADL15-reference/features/meta_data/openehr-test_pkg-WHOLE.full_meta_data.v0.0.1.adls>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 >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical at lists.openehr.org >> <mailto:openEHR-clinical at lists.openehr.org> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- Ocean Informatics <http://www.oceaninformatics.com/> *Thomas Beale Chief Technology Officer* +44 7792 403 613 Specification 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-clinical_lists.openehr.org/attachments/20141120/947e2caf/attachment-0001.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-clinical_lists.openehr.org/attachments/20141120/947e2caf/attachment-0001.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-clinical_lists.openehr.org/attachments/20141120/947e2caf/attachment-0001.png>
