Care plans in our software undergo a lifecycle from, draft → active → archived.
where draft → active depend on stuff like, completeness and sometimes attestation (by other care giver and/or client). And active → archived usually is caused by changes in the clinical situation, that lead to a new version of the care plan, usually duplicated from the old one, where the old one is ‘archived’.
I know there is a lifecycle state for a versioned object. That has an incomplete status which would work for indicating draft status, and complete that works for active status. But the only other option is deleted, and imho that should be reserved for other usecases than archived. So any thoughts about adding a code for archived to the terminology for lifecycle state?
The alternative approach, would be to add a status element to the archetype, as suggested here: Lifecycle_state in EHRbase
But my current understanding is that this usecase is generic enough (relevant for many persistent compositions, and maybe all versioned objects) so it could be part of the reference model.
Just to clarify Joost: I was not suggesting adding a status element to the archetype. I was referring to the idea of having a dedicated CDR instance with more relaxed constraints on validation. I have no comments regarding what the lifecycle status of a composition in that CDR may be. I was referring to the case in which a composition is not in a state that’s valid openEHR data, but still must be worked on using an openEHR based/backed application.
Our approach, based on trying to manage similar situations (and there are still some mixed ideas about!!)
‘Incomplete’ as composition lifecycle state, for when an openEHR composition has been started but really is not ‘safe’ clinically to be queried normally. In our example of End of Life, some clinicians feel it important to be able to work on and perhaps share a composition ‘privately’ but where a ‘normal’ query would not find it. This is where lifecycle_state = incomplete is helpful, especially as the most recent spec says that mandatory validation checks can ignored.
Some folks, Seref included, think this is better handled by a separate CDR, but I’m happy to laeve that open to implementers to decide the best approach.
We also have had other clinicians , say , we do not need ‘incomplete’ as a composiotn ‘technical setting’ - anything is better than nothing, but we would also like to put some sort of maturity indicator on the document based on local rules. e.g. It is draft vs published. Technically it is queryable but perhaps has not had key fields filled on or is not signed off.
1 and 2 are not contradictory, indeed I understand the Scots are using both for their ReSPECT document.
These are both is related to, but different from the lifecycle of the Care plan itself, which will go from ‘planned’ to ‘active’, to finished or aborted etc.
We are using an ACTION archetype to handle this - it is a local variant of the international ACTION.care_plan - I need to review if we still need that variant but it handles these states in the UI, mapped to the appropriate careflow_steps. Seems to work pretty well.
Consent given
Consent declined
Consent withdrawn
Patient died
Patient moved away
That’s news to me. Can I be lazy and asks for a link? That’d remove the distinction between type 1 and 2 'incomplete’s we’ve been talking about in this thread.
which one of your hats you’re wearing when you say “Our” here ?
Re 1: I think there’s something to say for adding archived as a lifecycle state, because it can indeed mean the context of the information is changed in such a way that the data is no longer clinically relevant/safe to query normally.
Until I know how we can move this discussion forward we’ll model this with a status element on the composition like report. But it’s problematic because of 1 and because a plan does not have an event context, which is confusing at least and bad modelling at worst imho, and it gives specific problems like a setting and start time being mandatory while there’s no data that makes sense here. We’re probably using null flavours for now, but that’s annoying workaround on a workaround. Or am I missing something?
There’s also the lifecycle of the plan itself which could indeed be an instance of the state machine. But using an action for this breaks the openEHR concept model of recording, since data in an ENTRY should not contain information about the COMPOSITION it contains, right?
The problem with that is that in theory someone would have to go back through everything in every patient record and mark data items that are no longer relevant, which is obviously not realistic.
But we have a simpler heuristic: whatever is in a persistent Composition, generally managed lists, e.g. Problem list, Meds list, allergies, Family history etc, is assumed to always be valid, because they are curated to be so.
Whatever is in Event Compositions, generally Obs, Dx, Rx and actions might or might not have meaning much later. A long history of BP over 160 has meaning as does an old Dx of type I diabetes; but old Rx for amoxycillin or radiology for ankle sprain most likely means nothing. But it depends on what the query purpose is. Might be some research looking for overuse of amoxycillin, or why people playing certain sports have a high historical rate of ankle sprains.
You never know what clinical data is going to get used for later on…
Yes, I agree with those statements about persistent compositions assumed to be always relevant. (and very much agree with event compositions only being relevant in the context of that event).
But how about episodic compositions?
And also for persistent compositions there can be multiple stored compositions in the CDR right? How would you indicate which is the ‘active’ one, and what to do with the no longer active one?
For persistent compositions the most recent version is always the active one. Exactly the same for episodic compositions, I’d have thought.
That’s the whole point of a persistent composition - there in only ever one ‘active’ instance fo the document - everything else is a previous version. - accessible but not through normal querying.
Most recently created, or most recently edited? or with the most recent time in the EVENT_CONTEXT? or one of the other many dates in a template on persistent composition?
And I don’t think whatever datae we decide on, is going to hold: there can be multiple active care_plans in one CDR… The psychologist, the nurses, the elderly care physician can each have there own active care plan.
But even for a single user, there’s a requirement to mark a careplan as ‘archived’, because a new version is now the active version. And this is not automatic, because a new care plan first has to be finished, approved and marked active, it’s not just the last edit date or created at date that determines which one is active.
Either. openEHR is a true versioned health record: whatever changes you make to one or more Compositions, including creation of new ones, will form the new versions of the next state of the record. Each set of changes is a change set, which we call a Contribution in openEHR. So the ‘top’ versions of all versioned content in the record constitute the current information of the record. (more explanation).
I understand the need to ‘archive’ a previous Care plan but I don’t think that should be at RM level - for me this needs to be a viable, queryable, though historical record, flagged as ‘archived’ or inactive or whatever at composition level. UI issue as to whether you want to retrieve only the current active care plan for e.g a mental health care plan or whether you want to see historical documents as well.
We have been using an ACTION careplan archetype to manage the state of the care plan, where it has that kind of defined status.
Thank you for the explanation. But if I read the specs it’s all about versions of a single stored composition. Then it makes sense each change is a new version of that stored composition, and the latest version is easily identifiable. But if there are multiple stored compositions (of a template on persistent composition care plan) those are in separate versioned object containers right? How do you now know which is the most recent one? And how do you record which is the active one, (not always the most recent one, as mentioned before).
I now realise there’s two use cases here that may need to be handled differently:
A single user creates a plan, activates it, then makes a ‘new’ plan (new composition or new version of the stored composition?) and until that is marked active (could be months later) and the old one marked archived, the old one is the one considered active. If we say in this usecase the new unactivated plan should be a new version of the same stored composition we need a way to label a VERSION as active/archived. It already has a lifecycle state, so to me it makes most sense to expand on that. But I don’t really care if something else is better from an engineering pov.
And we need to solve the second usecase: if multiple users of the same CDR each have their own care plan for the same patient, how do you keep track of which care plan to show to which user?
Agreed in principle off course, but: the scope of that is not the patient: it is the (group) of user working together on one EHR. Different user(groups) can have different instances of a persistent composition (e.g, docs and nurses each have their own problem list).
AND
The most recent one is not automatically the active one for care plans, as it first has to be activated/approved/attested/finalised whatever. So that logic doesn’t hold for this usecase. And it’s easy to see it’s a valid usecase right?
If you flag the COMPOSITION how do you handle, the most recent VERSION not being the active one?
I do think it should be solved at RM level. But I could live with solving it at composition archetype level. But even that is hardly doable at the moment. Due to design choice of compositions only allow expansion of event context, and for persistent composition mandatory start time and locations don’t make sense and can’t even be nulled. (Persistent compositions don’t have a context of event in clinical practice imho)
And sorry Ian but I fundamentally disagree with this modelling pattern of using a ACTION entry to record the status of the containing composition due to:
But I feel we’re struggling to understand each other and start going in circles, we (Nedap) really needs a solution here and if we (openEHR) don’t solve it, Nedap probably end up with some hack giving technical debt and limiting interoperability later at best and clinical safety risks at worst. So how can we move this further? Maybe an SEC discussion, or a smaller scale video call?
Maybe I can give a demo of how this ui works in our legacy app?
I think there probably is some mutual misunderstanding, and some different use-cases. We are right in the middle of this world right now and maybe we should setup a call to thrash out some of these issues as best we can and report back.
