Doing testing for the EHRServer with persistent compositions found problem list and medication list have category 433 (event) instead of 431 (persistent).
Maybe other compositions have the same issue.
This might affect many people.
Doing testing for the EHRServer with persistent compositions found problem list and medication list have category 433 (event) instead of 431 (persistent).
Maybe other compositions have the same issue.
This might affect many people.
Hi Pablo,
This is a longstanding issue and workaround.
See the last paragraph in ‘Use’ for each of the COMPOSITIONS that theoretically should be persistent but have been modelled as an event:
“This archetype is usually managed as a persistent list, however there are situations where the list may be used within episodic care and require additional attributes such as context etc to enable accurate recording. The openEHR reference model currently only allows context to be recorded within Event-based COMPOSITION archetypes. As a result, this archetype has been modelled as an Event, rather than Persistent, COMPOSITION, to allow for flexibility so that some clinical systems can safely manage Problem lists for episodes of care, while others will choose to implement this COMPOSITION to act in a persistent manner.”
Until there is a change in the RM to cater for this use case we are a bit stuck!
Regards
Heather
Shouldn’t that be two separate archetypes? one event and one persistent?
That is a solution independent from the RM constraints.
It’s another workaround, but causes its own problems and confusion, doesn’t it! J
H
IMO the current state is not valid since we can’t create persistent instances that comply with those archetypes, validators will fail.
To clarify the workaround we have the description, use, misuse, etc. of the archetype. Not sure which issues that can create.
The rest is just naming. Current problem list should be the persistent, the “event problem list” can be the event version. The only differences will be the category and context.
The RM has been changed (see https://openehr.atlassian.net/browse/SPECRM-52) and the change will be included in the next release 1.0.4, for which we will determine a date at the SEC meeting end of this month.
I would suggest that the archetypes be reverted to ‘persistent’ at some point soon after that.