SPECRM-89 - support for 'episodic' category

See the CR here.
The main changes are in this section of the EHR IM.

Please have a read and consider whether we need more precision about when to use the ‘episodic’ category, and what it is used for, e.g. querying, grouping things in Folders etc.

Episodic categories for health data has to be based on a “reference model” for the process related concepts of clinical care. OpenEHR has the clinical investigation model which is pretty good and cover most needs. With the addition from Taskplanning recently it even got better.

When moving into episodic content we need to look into the work done in CONTSYS (or similar). Some key concepts related to this are: period of care, episodes, contacts, health care resources, etc.

@ian.mcnicoll started some work on this (5 years ago) in this repo. https://github.com/openehr-clinical/shn-contsys .

For our EHR/HIS , DIPS Arena, we have the clinical processes manged outside of openEHR. The EHR already had a way to handle the above mentioned concepts. To integrate this with openEHR we invented TAG. Tag is a key/value structure to connect openEHR compositions with entities in the integrated system. This works reasonably well. The only concern is that we don’t have a openEHR way of handling this structures.

As mentioned above I think looking into the models from CONTSYS is a way to go.

I think this was discussed some time ago, since most implementations have a different understanding of what “persistent” category is. Also I think the current spec is not clear about that, and there are not many examples. For instance, in the EHRServer, persistent means just one composition compliant with a persistent compo archetype is allowed per EHR. So using CREATE twice for a persistent compo will fail the second time.

One thing we need to do is actually define the “persistent” category, and what is valid and invalid inside that category. Based on that, we need to modify implementations accordingly.

Then I’m open to any categories in between event and persistent, or even defining subcategories for those, like persistent.single (my current interpretation of “persistent”) and persistent.episodic. This second approach for subcategories might need an extra attribute in the RM but doesn’t require to modify system’s logic.

This is an urgent matter that we were delaying for a while, and will help to implement more consistent rules between systems, a step forward interoperability :slight_smile:

I think there are 2 separate though related issues here.


This is essentially a guide to the persistence strategy for a particular composition/template type and reflects the clinical governance arrangements i.e to what extent should this be regarded as a single, persistent,continually updated document.

Persistent - continually update a single composition instance for the whole of the patient’s life
Event - a new composition instance, other than to correct errors.
Episodic - continually update a single composition instance but only within a particular episode of care (whatever that means!!) e.g an admission , an outpatient spell or care plan). A new composition instance is created for each new episode of care.

I don’t think it is going to be possible to be more specific than that.

@bna raises the related issue of how to handle Episodes of care/spells of care more gnerally , and I agree that Contsys has some useful concepts, but that is different from the much narrower focus of COMPOSITION.category. Within an episode of care , I would expect all 3 COMPOSITION.category types to be used.

1 Like

IMO this is not well defined in the spec, since it doesn’t state there is going to be just one instance of the persistent COMPOSITION for the whole patient’s EHR, I think this is currently open for interpretation, generating incoherent implementations. We need to state if it’s possible or not to have many instances of a persistent COMPO inside the same EHR.

About the “episode” discussion, what I understand is an episode of care is something that has a beginning and end (occurs during a period of time), and is associated to one health problem or chief complaint. Then any kind of record could be created during the episode, event or persistent, but the episodic nature of the records is not really a category of individual record, but that the record (COMPOSITION) belongs to an episode, so the episode concept needs to be represented and could contain many COMPOSITIONs, in that sense, FOLDERs are a good representation for episodes, and anything there will be considered “episodic”, I guess by using an archetype “episode” for the FOLDER (which is something many implementers are already doing).

I guess, we need to reach consensus on what we understand an “episode” is, and put that also in the specs to avoid incorrect interpretation by implementers.

Well, a more precise definition would be that a persistent Composition is used for content that remains valid over the patient’s life, e.g. Family history, Problem list (with a few assumptions about what is in a problem list), Allergies etc. It doesn’t mean that there couldn’t be more than one Composition containing the same kind of information, as @ian.mcnicoll has shown with a very nice recent analysis of ‘problem list’ - where there are usually multiples, because they represent different views of what problems matter to different types of care.

Persistent Compositions can also be understood as ‘proxies’ or ‘virtual surrogates’ for things in the real world, usually relating to the patient phenotype, life situation, care history etc. These things tend to be singletons in the real world, hence the idea that (often) persistent Compositions are unique.

A bit more precisely, persistent Compositions tend to record state information rather than events. Being allergic to penicillin is a state; so is having had a CABG (your body is in the state of having grafted coronary arteries supplying your heart). And so on. Whereas the blood sugar I had last year, or even last week, or 3 hours ago, doesn’t reflect much about my current blood sugar (but an inability to reduce blood glucose below 6.5 mmol/L 2 hour after a standard glucose challenge would tell you something).

A simple test is: is this information useful to retrieve onto the screen at any time in the patient’s life? If it is, it’s probably ‘persistent’ information.

Please let’s not get into an existential discussion about what is an episode and what is not.

This is directly about commit behaviour.

  1. Do you normally want to do a PUT after every initial POST => persistent. Thisis well documented in the specs but was assumed to always be ‘life-long’ which turned out to be incorrect.

  2. After an initial POST, do you only ever want to do a PUT to correct an error or incorrect information => event

  3. Something else - After an inital POST do a PUT for a period/episode or some other business rule that defines when a new document i.e a POST is required. Many implementers have recognised that we need to flag this as different style of persistent.

I am pretty sure we talked this over and decided that ‘episode’ was the best term but we should not try and equate that with any real-world definitions of episode. In any real world epsiode of care I would expect to see event, persistent and epiosde style of commits.

Perhaps it does require better documentation but that should not be about any sort of definition of episode, for which any other layer of modelling hell is about to start.

I am staying away from that :wink:

But I would say that what people think PUT, POST and other REST verbs (at best only weakly matched to real-world API semantics, and rarely agreed upon, even by experts) isn't a strong basis for deciding the semantics of anything ... One day, PUT, POST, and friends will be replaced by the next standard protocol, but episodes will still be what they were.

Having said that, that is quite an original analysis, and with a second beer, I might even start to like it.

1 Like

so Create and Update for you old-timers then :wink:


I agree, I was actually going to propose to talk about “scope” instead of “episode”. I think of scope as: a versioned composition complying with one OPT can occur:

  1. many times in the EHR => event
  2. one time in the EHR => persistent
  3. many times in the EHR, but always associated with a FOLDER and can occur one time per FOLDER (e.g. using FOLDER as an episode container) => episodic

I can think of a 4th scope that is a little tricky:

  1. many times in the EHR, but always associated with an ENTRY, and can occur just one time associated with that ENTRY (e.g. using the ENTRY as a Health Problem in a problem-oriented record) => persistent-problem

Let me explain the last one: sometimes you want to associate a medication list, a procedure list or even a problem list for comorbilities, to an ENTRY (EVALUATION) that represents a health problem in a problem list (this one is persistent). And the associations between COMPOSITION and ENTRY use LINK. This way, doctors can manage, for instance, medications associated with each problem independently from other problems.

I guess if we get the scopes right, we then can name the categories whatever we want, and also map that to operations like @ian.mcnicoll did above.

What do you think?

Pretty well agree other than that I don’t think there needs to be any formal connection with FOLDERS - that is a good a propach but I don’t think there should be any formal dependencies in the spec.

I’m not sure I understand the (4) problem case as being different to (3) other than you have tied (3) to FOLDERS.

Yes, I was thinking that dependency might cause issues for some implementations, so maybe the category shouldn’t be so strict in the spec, and we could suggest stuff like this in an ITS guide, like a pattern or good practice.

The difference is on what is the object used to define the scope of the COMPOSITION. In an episode modeled by a FOLDER, FOLDER is clearly what defines the scope of the items it contains. For problem-oriented records, the key object is the problem, but there is no formal containment, on that case we can just use LINK, the concept is similar but not 100% the same. In pure event/persistent, the scope is clearly the EHR object.

Also consider this was just input for thinking about the issue, not proposing that as a final solution.

Another option is to relax the category definition so it’s not associated to a specific behavior, and also allow client-defined categories. I don’t see an issue with this approach if implementers document their categories.

I’m not against per se. But I see an issue with frontend clients working with multiple (federated?) CDRs. How will a client handle working with different persistence categories if they (as currently) differ in behaviour.