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

**URL:** <https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360>\
**Category:** Platform\
**Tags:** ehrbase\
**Created:** [6 October 2026 10:41 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360 "2026-10-06T10:41:33Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![HHeiser](https://discourse.openehr.org/user_avatar/discourse.openehr.org/hheiser/32/4249_2.png) [@HHeiser](https://discourse.openehr.org/u/HHeiser)\
**Post date:** [6 October 2026 10:41 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360/1 "2026-10-06T10:41:34Z")

</div>

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](https://docs.ehrbase.org/api/hip-ehrbase/admin#tag/Admin-EHR-Merge), 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):

```auto
"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

---

<div class="post-metadata">

**Author:** ![rubentalstra](https://discourse.openehr.org/user_avatar/discourse.openehr.org/rubentalstra/32/6546_2.png) [@rubentalstra](https://discourse.openehr.org/u/rubentalstra)\
**Post date:** [6 October 2026 14:27 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360/2 "2026-10-06T14:27:45Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![HHeiser](https://discourse.openehr.org/user_avatar/discourse.openehr.org/hheiser/32/4249_2.png) [@HHeiser](https://discourse.openehr.org/u/HHeiser)\
**Post date:** [6 October 2026 14:30 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360/3 "2026-10-06T14:30:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![vanessap](https://discourse.openehr.org/user_avatar/discourse.openehr.org/vanessap/32/2088_2.png) [@vanessap](https://discourse.openehr.org/u/vanessap)\
**Post date:** [6 October 2026 15:06 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360/4 "2026-10-06T15:06:21Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [7 October 2026 14:34 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360/5 "2026-10-07T14:34:15Z")

</div>

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’.

---

<div class="post-metadata">

**Author:** ![HHeiser](https://discourse.openehr.org/user_avatar/discourse.openehr.org/hheiser/32/4249_2.png) [@HHeiser](https://discourse.openehr.org/u/HHeiser)\
**Post date:** [7 October 2026 14:46 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360/6 "2026-10-07T14:46:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![joostholslag](https://discourse.openehr.org/user_avatar/discourse.openehr.org/joostholslag/32/1981_2.png) [@joostholslag](https://discourse.openehr.org/u/joostholslag)\
**Post date:** [8 October 2026 09:38 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360/7 "2026-10-08T09:38:49Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![HHeiser](https://discourse.openehr.org/user_avatar/discourse.openehr.org/hheiser/32/4249_2.png) [@HHeiser](https://discourse.openehr.org/u/HHeiser)\
**Post date:** [8 October 2026 10:43 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360/8 "2026-10-08T10:43:33Z")

</div>

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](https://specifications.openehr.org/releases/RM/development/ehr.html#_compositions), 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 😃

---

<div class="post-metadata">

**Author:** ![ian.mcnicoll](https://discourse.openehr.org/user_avatar/discourse.openehr.org/ian.mcnicoll/32/4430_2.png) [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)\
**Post date:** [8 October 2026 11:16 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360/9 "2026-10-08T11:16:13Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![HHeiser](https://discourse.openehr.org/user_avatar/discourse.openehr.org/hheiser/32/4249_2.png) [@HHeiser](https://discourse.openehr.org/u/HHeiser)\
**Post date:** [8 October 2026 12:55 UTC](https://discourse.openehr.org/t/ehrbase-not-supporting-persistent-or-episodic-composition-category/17360/10 "2026-10-08T12:55:34Z")

</div>

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

Your two behaviors seem very reasonable to me.