Symptom/sign - ready for republication as a new major version

After discussion in Discourse and among editors, the Symptom/sign archetype will be republished as a new major version.

The major changes from the last published revision (25.04.2018) are as follows:

  • ‘Nil significant’ element deleted. This was always an uncomfortable modelling choice, and is now covered in a much better way by the Symptom/sign screening questionnnaire archetype
  • The internal cluster ‘Precipitating/resolving factor’ has been split into two clusters named ‘Precipitating factor’ and ‘Resolving factor’
  • The ‘Duration’ elements has had constraints added that were missing from the last published revision, and has been expanded with the data types ‘Interval of duration’ and ‘Text’.
  • Some SLOTs have been updated to include published/republished versions of the included archetypes.

Additionally, a series of change requests have been folded in and closed, some minor textual changes performed, and a translation into Dutch added. All translations will need to be updated due to the mentioned text changes.

At the same time, the following archetypes will be republished as a new minor version, to include the new major version of the Symptom/sign archetype as SLOT includes. Please add to this list if you know of more published archetypes which uses CLUSTER.symptom_sign.v1 as a SLOT include.

If you have any comments or objections, please note them here, at the latest before the planned publication date, December 1st 2022.

4 Likes

Republication put on hold for a little while to continue exploring the NRS/VAS/etc complex.

1 Like

The problem of NRS/VAS/etc has been solved by replacing the previous “Severity rating” element with a SLOT for the new CLUSTER.severity_rating_scale archetype.

Unless there are objections, the archetype will be published as v2 on March 24th 2023.

1 Like

Looks good.

Regarding links/LINK usage mentioned/recommended in the comments of the SLOTs…

  • Previous episodes and
  • Associated symptom/sign

…it sounds good but I started thinking about how such linking should it be done in a consistent way in practice. Maybe it would be good to figure out and document what LOCATABLE nodes that are recommended to be used as a basis for where the outgoing links attribute can be attached (see FIgure 1 in Common Information Model).

I suspect an empty SLOT will not be available in actual EHR data instances and thus not possible to link from. I might be misunderstanding linking, but if not maybe we need to do one of the following:

  1. Add yet another archetype “Includes”-recommendation like Citation to the slot (but Citation it is unnecesarily complex since we don’t need its content if we just wanted to use LINK).

  2. Add yet another archetype “Includes”-recommendation to use a new single element micro-archetype like the attached “Crosslink” openEHR-EHR-ELEMENT.crosslink.v0.adl (1.4 KB) archetype and then change the CLUSTER_SLOTs to more general ITEM_SLOTs. A simple ADL-hack is needed since there is no button for it in AD, but it then works fine in AD, see screenshot below and attached link_test
    openEHR-EHR-CLUSTER.link_test.v0.adl (2.4 KB)
    archetype

  3. Describe what other already exising node(s)/field(s) in the archetype that should be used to link out from, for example link from “Description of previous episodes” instead of copying data into the “Previous episodes” SLOT. It is not as obvious what existing (non-SLOT) to link out from instead of using the “Associated symptom/sign” SLOT, perhaps we could reccoment to link from the the general “Descritpion” or “Comment” field?

This issue is not unique for the Symptom/sign archetype, but rather any time we in a description would say that instead of filling a SLOT we could use the nice links/LINK system of the RM.

1 Like

Thanks!

Regarding the rest of your comment, I’m struggling to get a concrete change request from it. Do you think it’s something that can be done at a later point?

Republished as v2: Clinical Knowledge Manager (openehr.org)

How about replacing the include with a new ‘previous episode cluster archetype. That has a DV_EHR_URI element to point to an instance of the data and a slot for sign/symptom.

I’m not sure I agree the Citation archetype is ‘too complex’. It’s got four elements, all of which are optional.

1 Like