How should deal with Metadata

Hi,
I am wondering how can we deal with the Description part (including Details and Authorship) when we are modifying one archetype and also when we are creating a new template?

Is that OK if the original authors and description be replaced with the new one?

Hi maryam,

Could you please give an example of what kind of modifications you are making to archetypes and templates. In general I would suggest not to edit any existing archetypes because it will break interoperability. If you need something changed, please make a change request in the CKM. An alternative would be to adjust for local requirements, to specialise an archetype. In that case it’s recommended to add a namespace to the archetype id.
Since most templates are implementation specific you’ll probably make your own. So in templates you can write your own descriptions. There are some shared international templates (e.g. for covid) where it has value to keep them standardised for interoperability purposes. Here the same recommendations regarding archetypes apply.

Hope this helps:)

1 Like

Thank you @joostholslag
Actually, this question is raised since some countries are building their own clinical information models at the national level. These national clinical models are not dependent on any standard specification and I am wondering how is it possible to map national clinical models with OpenEHR? In some cases, it is possible to have templates but in other cases we need archetypes. For example this CIM from NICTIZ. HeartRate-v3.4(2020EN) - Zorginformatiebouwstenen.
How this can be mapped in openEHR?

You have mentioned adding a namespace to the archetype id. Does this apply to the example above? if yes can you give me an example?

Hi Maryam,

The zibs are actually from my country. And openEHR NL (affiliate) is working on mapping these to CKM archetypes (I’m involved). Please have a look at:

It’s actually not an easy question:
We supply mappings from CKM archetypes (as csv) to help implementers do a mapping to zibs (usually FHIR technically).
And we supply an openEHR template to facilitate storing of data, received as zib, in openEHR.

The openEHR nl work is progressing quite slowly.
@nedap in case no CKM archetype was available, we made some custom archetypes that are mostly copies from the zibs data fields. Let me know if your interested in those, we could discuss sharing:) we namespaces those (to com.nedap.zibs iirc)
But ideally these will become redundant when either the CKM has 100% coverage of clinical concepts. Or Nictiz realises some ZIBs are bad models and should be deprecated.

You made me really curious btw, are you using the zibs in Sweden, or are you active in the Dutch market?

1 Like

@MaryamRazavi often openEHR already has a place to put most things from national models requirements, but maybe using a slightly different pattern.

Often complementing existing archetypes with some (possibly national) CLUSTER extensions will do the trick to incorporate extra needs without breaking the international compatibility of the main content in the archetype. If there is no suitable extension point, then to specialise the archetype is also an option as @joostholslag wrote.

Sometimes design patterns using the LINK feature from the reference model can also be needed for things that a national model may have linked/aggreagated in some other form than the current set of international archetypes does.

What models are you thinking of? (It’s OK to post links to Swedish models too, translation tools or Swedish community members wil llikely get us pretty far.)

1 Like

@joostholslag @erik.sundvall Thank you both for the explanation.
@joostholslag Thank you for the link to ZIBs. for answers to your question, I would say that in Sweden there is Nationella informationsmängderhttps://informationsstruktur.socialstyrelsen.se/NIM-Hj%C3%A4rtfrekvens.
I am working on a project to map the national models in OpenEHR. That is the reason I asked the question.

1 Like

Hi maryam, interesting: the models from “Nationella informationsmängder“ feel similar conceptually to openEHR archetypes and zibs. So maybe our approach to mapping zibs is helpful.
What kind of details are you looking for? Some detail is here Werkwijze - Remote theme example
Functionally we record zib ‘elements’ and the corresponding path in CKM archetypes. (The table yours see). And create a openEHR template to record entire zibs.
Practically we edit a csv and create a PR to merge that with the tabel that is rendered on the website I linked. Templates are designed in archetype designer using a shared repo and also merged to be rendered on the website.
Technically the mapping has to be implemented in a CDR or related microservice.
Organisationally the tiny openEHR nl has a work group of 4 (@wouterzanen @sebastian.iancu @Jelte and me) plus two (scarcely:p) paid consultants (@ian.mcnicoll and @heidi.koikkalainen) funded by openEHR nl with contributions from code24 and Nedap.

Hi Maryam! In general, according to the Creative Commons licence (CC-BY-SA) the archetypes are published under, the original author is retained when making new revisions of the same archetype, ie when the concept is unchanged. Contributors are added to the list of contributors.

However, when creating a new archetype, for a concept separate from that of the original archetype, by using the pattern of an existing one, or even a specialisation, the author is set as the creator of that new archetype. The author of the original archetype is added to the list of contributors, and the original is referenced as “Derived from”, like this from the Tanner stages archetype:

Derived from: Tanner stadier, Draft archetype [Internet]. Nasjonal IKT, Nasjonal IKT Clinical Knowledge Manager [cited: 2017-05-05]. Available from: http://arketyper.no/ckm/#showArchetype_1078.36.1823

A template is authored by its creator, regardless of the authors of the included archetypes.

Edit: Also, new archetypes which are derivatives of archetypes from the CKM also have to be published using the CC-BY-SA license, as this is a copyleft license. This is however not intended to apply to software created using the archetypes.

2 Likes