EHRbase not supporting "persistent" or "episodic" COMPOSITION.category?

Implementation Platform
1

Hello,

I want to ask whether EHRbase supports COMPOSITION.category other than 433::event?

This came up while I was testing the EHR Merge API endpoint, which mentions the keyword composition_merge: PERSISTENT, presumably treating “persistent” compositions differently during the merge procedure.
However, when I attempted to save a composition with categories 431::persistent or 451::episodic, I got the error 422 Unprocessable Entity: /category: CodePhrase codeString does not match any option, found: 431

The syntax I tried is (EHRbase version 2.31.0):

"category": {
  "_type": "DV_CODED_TEXT",
  "value": "persistent",
  "defining_code": {
    "_type": "CODE_PHRASE",
    "terminology_id": {
      "_type": "TERMINOLOGY_ID",
      "value": "openehr"
    },
    "code_string": "431"
  }
},

Did I make a mistake here, or are these categories really not supported?

Thanks for your help and input!

Hendrik

2

Hello @HHeiser,

Persistent and episodic compositions are supported. The 422 comes from the template: the COMPOSITION archetype it is built on only allows 433|event|. The server is right to refuse it.

FerroEHR behaves the same way as EHRbase here: the category must be in the set the template allows.

I hoop this answers your question?

3

ah I see, thank you. I will have a look at adjusting the template valueset then

4

@HHeiser some composition archetypes have not set the correct category events. I’m not sure if this happens due to modelling tooling changes historically and got unnoticed, but usually kinds of errors occur if you want to use a persistent type. Happened with me too before in 2 templates. If that’s the case, please open a change request on CKM for that specific archetype.

5

Right now , Archetype Designer is unhelpful in that it does not allow multiple possible categories to be applied to category e.g persistent OR episodic, nor does it allow the category to be further constrained in a template.

One issue ot be aware of with MERGE is that you almost certainly should not try to ‘auto-merge’ persistent compositions based on most recent date. The specifications originally allowed that but had to be changed with experience from a site in the UK. In that case the person had an allergies list but was admitted as a ‘John Doe’, and a new EHR created but with an empty but more recent allergies list.

As a result, with the original spec being followed, the correct allergies composition was hidden. The Spec was updated to advise that persistent compositions really need to be ‘eye-balled’.

6

thanks for this info, Ian.

It is indeed something that we are thinking about. That is why we are currently investigating how exactly the Merge API endpoints behave in the different CDRs, and we will see how we govern around it. For sure it is a tricky operation that requires a lot of careful screening.

7

Also good to realise that there are some vague assumptions around behaviour of persistent compositions. Ian’s described merging. Others are uniqueness. And default for editing new/existing. This behaviour isn’t fully specified by openEHR thus be careful to assume behaviour just because a category code is persisted.

8

Hi Vanessa,
thanks for the disclaimer. From what I can see, all of the COMPOSITION archetypes are constrained to event, none are persistent (openEHR-EHR-COMPOSITION.pregnancy_summary.v0 is null, whatever that means…). Probably archetypes such as

  • openEHR-EHR-COMPOSITION.adverse_reaction_list.v1
  • openEHR-EHR-COMPOSITION.medication_list.v1
  • openEHR-EHR-COMPOSITION.problem_list.v2

which are all given as examples for persistent compositions in the specs, should be constrained to persistent?
I can open CRs for them.

Luckily, I just tried editing the OPT of a template based on openEHR-EHR-COMPOSITION.adverse_reaction_list.v1, changing the 433 into a 431 worked so that now the CDR automatically sets the category of a composition of that template to 431::persistent.

At least for my tests now a workaround :smiley:

9

Yes setting them to event was deliberate decision because we could not be sure if they would become epiodic/persistent and for a while we could only make a binarty choice. Also older version of the RM removed ‘context’ for persistent compositions which as really problematic

I would say that the majority of list type persistent compositions have to be a choice of persistent/episodic, rather than just persistent.

That leaves us with the AD problem of not being able to select multiple categories and not being able to further constrain that in templates.

I have reported this issue to Better but it has not been accepted as yet.

Would there be consensus about preferred AD behaviour in this area?

  1. Allow multiple categories to be constrained in archetypes
  2. Contrain further if required in templates
10

yes, I agree that fixing the category to “persistent” just moves the problem.

Your two behaviors seem very reasonable to me.