Correction to COMPOSITION.category description


I'm reviewing the specs & the openEHR terminology.
I understand the "event" and "persistent" values for the Composition.category property.
There is also a "process" value, but I don't understand the difference between "event" and "process". The specs are not clear here:

"Indicates what broad category this Composition is belogs to, e.g. "persistent" - of longitudinal validity, "event", "process" etc."

Hi Pablo

The only current allowed values are event and persistent. I am not quite sure what process might mean in this context. This was clearly some philosophical musing when the spec was written but I have not come across a need for this when modelling so far. I have requested a change to allow a persistent composition to have a context attribute , currently disallowed. Episodic care such as hospital admission does throw up the need for persistent compositions to carry the context of the episode but persist throughout that episode. eg a problem list for the current admission.

I think having "process" & "etc" in the specs makes a little difficult to understand what values are allowed in the category field.

BTW, in the Terminology.xml file, "process" is also present:

<Concept Language="en" ConceptID="431" Rubric="persistent"/>
<Concept Language="en" ConceptID="432" Rubric="Composition category"/>
<Concept Language="en" ConceptID="433" Rubric="event"/>
<Concept Language="en" ConceptID="434" Rubric="process"/> <<<<<<===========




Heath Frankel
March 17, 2016, 6:43 PM

Perhaps process was assigned a code but never grouped with composition category in the Archetype Editor because Sam didn't feel there was a clinical use case for it, which appeared to be backed by the commenter (Ian?) in Pablo's description above.

Ian McNicoll
March 17, 2016, 6:51 PM

I certainly don't feel it fits the current use of category, which is, and I think should remain, specific to indicating the commit strategy.

Bjorn has been making good arguments for being able to define other categories of composition i.e primary or derived data but I think these are, I think orthogonal to the current 'category' usage and possibly deserve a new attribute.

Bjørn Næss
March 17, 2016, 11:04 PM

Some thinking on the topic of persistence scope:

Some Compositions are truly event based and contains information which are collected and registered in a well defined clinical event.
Some Compositions are truly persistent and contains information which is unique (one instance) for a given EHR (patient/subject of care). This information is always true given a specific subject of care and there should only be one instance of the content.

Then there are a lot of information which is persistent for a given scope or context. From my current point of view this scope or context is always some kind of health care process. Examples of these are episode of care, periode of care, patient pathway, surgery (including planning, performing and reporing).

Maybe we only need three levels like this? And then of course some qualifiers to tell the scope of persistence for process compositions?

And the the other dimension (orthogonal as Ian says) is a classification about the content. Is it a primary source or only copies of existing information? This is realted to my proposal of using Composition.Category for report compositions. As Ian writes I also think this orthogonal to the persistent nature for content.

Ian McNicoll
September 27, 2019, 6:11 AM

Agree with Bjorn (or rather I think he agrees with me!!).

Adding ‘Episode persistent’ allows for more contextual periods of persistence and would add immediate benefit.

Agree that there is a need for other kinds of content classification possibly multiple occurence for the kind of usage that Bjorn describes.

Ian McNicoll
September 30, 2019, 6:01 PM

I suggest we remove ‘process’ from the spec documentation - it really makes no sense in the COMPOSITION.category and is not currently being used that way in any of the tools or CDRs. We should probably leave it in the terminology in case it is being used for some different purpose.
Then deal with ‘episode persistent’ in the separate PR/CR that specifically handles this.



Pablo Pazos



Affects versions