Description

Since context is now allowed for non-event compositions I propose to add an “other_context” to composition.context. This attribute should have ITEM_STRUCTURE.
https://specifications.openehr.org/releases/RM/latest/ehr.html#_event_context_class

E.g. for a persistent composition e.g. care plan there are some context information datapoints you want archetyped on the composition level (e.g. status). Currently the only place allowing to do that is event_context. But since persistent/episodic compositions are not about events, this is semantically wrong to me.

Impact should be low since event_context can still be valid. And I believe context is still sufficiently expressive for what kind of information should go here.
Separately we could deprecate event_context for non-event compositions. But this would be a breaking change in the RM I guess?

Alternatively we could add an optional “other_context” attribute to the composition class (1 level up).

Another option would be to rename EVENT_CONTEXT to CONTEXT. But this would mean also loosening the mandatory start time to optional since persistent compositions may not have start times. And other attributes e.g. “setting” may or may not make sense for persistent/episodic compositions.

Activity

Show:

Pablo Pazos February 20, 2023 at 5:23 PM

Late to the party, I see the problem is using the name EVENT_CONTEXT for non-event COMPOSITIONs? I think when we agreed on enabling the use of EVENT_CONTEXT in other categories of COMPOSITIONs we also, implicitly, agreed the name wouldn’t be important, and that it just means ‘CONTEXT’, so we don’t need to introduce a breaking change just in the sake of being correct in terms of the terms. What is important besides the name is the definition of the class, which IMO could be clearer about event vs. non event records: “Documents the context information of a healthcare event involving the subject of care and the health system. The context information recorded here are independent of the attributes recorded in the version audit, which document the system interaction context, i.e. the context of a user interacting with the health record system. Healthcare events include patient contacts, and any other business activity, such as pathology investigations which take place on behalf of the patient.”

Fixing the description might be the only change needed for this so we don’t need to update thousand of lines of code :)

Thomas Beale February 11, 2022 at 7:12 PM

I don’t think I would see ‘status’ or ‘date last reviewed’ as context (we sometimes call it ‘situational context’ i.e. an artefact of the encounter or other care event; it’s part of the Care Plan, but maybe not the central clinical data items (e.g. recommended interventions).

Think of it this way: if you send the Care Plan to a colleague, won’t s/he expect to see those data items as part of the Plan?

Joost Holslag February 11, 2022 at 7:28 AM
Edited

Status in this context (pun intended) means the clinical status (in contrast to technical status) of the care plan composition. E.g. “approved”, “active”, “rejected”.
Let me think on more context elements of persistent elements. I assumed there would be many, but I may be wrong because it’s harder to come up with data points than I thought.

Probably “date last reviewed” (not the technical updated, but more the time the information in the plan as a whole was reviewed). This is usually part of the entry if relevant (immunisations summary.eval), but especially for a plan there is also meaning in the collection of entries that should be reviewed.

And also maybe commencement time (ironically) of the plan, which is different from the start time of the event an event composition describes.

I’m also starting to doubt wether context is still the appropriate name for the data points I’m describing. Maybe something more generic, like ‘meta data’ or ‘other details’ is a better fit.

We should also think hard wether to put these datapoint in an item structure, or factor into the RM. One of the criteria for me will be, how easy will it be for people recording these datapoints to choose the same structure others choose. Versus how do we keep the RM stable and prevent bloat.

Thomas Beale February 10, 2022 at 4:52 PM

Can you give some more examples of non-event related context? You mention ‘status’ but I don’t know what that means specifically.

We should improve the way context is explained with respect to persistent Compositions. Since each committed Composition is really a version, and a version is a snapshot in time and relates to that moment in time. Thus, if a Contribution adds a new version to a persistent Composition (e.g. Meds list, Care plan etc), then ‘context’ relates to that version (because every commit is always a version). The way we explained this in the EHR IM spec does not make this obvious at all

Second point that may help: currently there is COMPOSITION.context: EVENT_CONTEXT. Here we understand this ‘context’ attribute as ‘event context’ as you say - if we had our time again, we could rename to ‘event_context’ but today this would break a lot of software. Nevertheless, if we wanted to add more / non-event context to a COMPOSITION we could add an attribute COMPOSITION.other_context: ITEM_STRUCTURE (or even OTHER_CONTEXT). This would be reserved for recording non-event context.

But I’d still like to see some more examples of the data points you are thinking of.

Joost Holslag February 10, 2022 at 7:26 AM

the issue is that in order to use that item structure I need to add an event context class to the composition. For persistent compostion the event part is semantically problematic. Persistent compositions are not recording data about events. (And the mandatory start time is the second probkem)

Pinned fields
Click on the next to a field label to start pinning.
Details

Reporter

Joost Holslag

Raised By

Joost Holslag
Joost Holslag

Components

Created February 9, 2022 at 7:45 AM
Updated February 20, 2023 at 5:23 PM