Obsolete status for care plan composition archetype

Specifications RM
55

Hi Joost,

So many points here to tease out and discuss :exploding_head: although I expect that we may be more aligned than it seems at first glance.

Another point is that we need to prioritise the display of a care plan that is relevant to the clinical role of the viewer, and the patient. In fact, we need to be able to provide a variety of views, hence my idea of the sub-plans - so that the endocrine physician can see the Diabetes plan relevant to them, and the Diabetes nurse can see the relevant items for them. The GP can see both and the tasks related to their practice.d

In the community space in AU there is an increasing role for a care coordinator who actively manages the care plans and assigns tasks to members of the appropriate care team. So there are times when all care plan items need to be viewed as a whole, but others where only a specific subset should be viewed and actioned, based on their role in the community or hospital care team. So, for this model to be successful, there needs to be a coordinator - if not the patient, then someone appointed. It still won’t be perfect but aiming to avoid duplication and ensure tasks are ticked off using the patient time and provider resources as efficiently as possible.

So I’m prioritising some different things, assuming slightly different work processes etc, and I’m pushing back gently again, even if only to play devil’s advocate a little - you still need to decide what works within your environment . :sunglasses:

If a sub-plan for UTI is completed, then the ACTION should be recorded as complete and the completed items removed from the active care plan - both doc and nurse need to be informed of this, and there needs to be a protocol about who records it as complete and in what timeframe to ensure the plan is up-to-date.

In an ideal, fully integrated world I think it is desirable to be able to make a single care plan available for viewing, where every item is potentially viewable. In lieu of that nirvana, we should strive to achieve as much transparency for all the tasks required for this patient as we can in the environment we have control over. Whether the underlying structure is a single COMPOSITION or a view comprised of multiple data sources, is up to the implementer. However, that master (monster?) care plan also needs to be filtered, sliced & dices in many ways so that it can be a useful tool within clinical practice. The design should be as flexible as possible, that’s why I’d rather speak in terms of filtered views (subsets) presented to the end user rather than fixed folders etc - then it can grow and evolve via querys or filters as clinical practice changes, new roles are added, etc etc rather than changing/evolving the storage mechanism with new queries etc.

I don’t really think in terms of a sub-plan as obsolete. It is completed, suspended or aborted etc in ACTION pathway terms. I’m not sure that this should be a COMPOSITION attribute.

If you want to query care plans, then you definitely need to first define if it is active or not, and ensure that this is prominently displayed. Again, a master/monster list will need clever querying on currency/clinician role/ tasks due within the next x wks etc to display the relevant items for the clinician role/location etc.

It is the most complex of complex EHR tasks that we’re discussing here!

It is almost certainly impossible to come to conclusions about care plans on a thread like this - needs more like a week-long F2F workshop :rofl:

Cheers
Heather

1 Like
56

Arguably most application forms would be built to do what is expected from each such form, possibly with a button that reruns the query with obsolete=on (or off). As long as it is easy to run such a query (it should be), I suspect that the default is less important than we might have originally thought on yesterday’s call.

Whether there really is one care plan (with sub-parts) or just multiple plans would seem to be the existential question. Do we know what clinician and cultural (e.g. US v Germany v Spain v Korea v…) preferences look like here?

Yes this is a recognised question but is advanced functionality, and probably does argue for a single over-arching care plan with a common ‘actions’ section. The logical reason for this is that the patient him/herself is a ‘singleton’, i.e. there is only one physical entity to which actions can be applied, not many. Same with medications. So either a single list is created and curated over time, or else there are multiple carers / institutions doing their own thing, and probably nurses or GPs get to figure out how to merge the disparate list actions (or medications) onto the patient. The former is at best inefficient, and the latter is positively dangerous, which is why a single source of truth medication list is so important.

I think your argument here says: we should think about care plans the same way.

EDIT: I missed @joostholslag 's reply - he provides cogent reasons why there might not be a single care plan, at least not as a single Composition/document entity. I am less worried about single Composition as well - the view in Task Planning is that multiple Work Plans for a patient will be in multiple Compositions.

So perhaps the concept we need is a top-level whole of patient coordinating meta-plan. And the singleton problem doesn’t go away: multiple lists of actions or medications to be applied to the patient are likely to become incoherent / dangerous.

1 Like
57

I guess that is what I’m proposing… but support smart ‘slicing & dicing’ as needs be for a given viewer/clinician role/clinical context/location etc - describing a common approach but end-user preferences/requirements determines what they see. A diabetes specialist may only want to see the tasks that are relevant for their speciality, but it would be useful to be able to see the other items required by other sub plans - in that way care can be better coordinated or tests scheduled to require one visit instead of two etc.
It will still only work within one integrated ecosystem, which is clearly a long way away from our current reality, but there is utility in describing a common approach to optimise flexibility or allowing simpler local solutions as required.
It would be of great value if we can provide guidance for the aspirational, best practice solution principles, and the models to support such an implementation. .

1 Like
58

I think we are closely aligned on the requirements. Your idea of different views on the But I’m quite convinced it shouldn’t be a single mega composition with actions per sub plan. But composition per sub plan. And that sub plan can be obsolete. Maybe thinking of episodic problem lists is easier to think about obsolete state, could I please also get feedback on that part of the question?

1 Like
59

Even though I was not asked explicitly, I would like to express support towards this ‘obsolete’ state term. It comes close to a need we also had few years ago.

On the other hand, from a technical mind/perspective, I think is not only useful for care plans, but also for other use-cases, some also mentioned by Joost above. Perhaps slightly better functionality (but more complex) can be achieved by grouping data in a context of episodes, and considering (de-facto) ‘obsolete’ everything that is recorded in other episodes (thus outside of the ‘current-episode’ context).

1 Like
60

I’m really struggling to understand the use of ‘obsolete’ in a health record - it implies something is no longer used, out of date, more like a mobile phone that has been replaced with a newer version because it can’t connect to the network.

Instead, to me the care plan is dynamic - any sub care plan (ie individual sub careplans per condition/protocol/vaccination schedule etc) can be planned, scheduled, suspended, aborted or completed - as can each of the individual component tasks/activities.

Obsolete seems more a category implying that this is a piece of information we don’t query it for current activities- we don’t know if it is incorrect or out of date etc so I don’t understand the value of labelling data in this way because I can’t interpret it meaningfully. And of course, in medico-legal terms nothing in a health record can be obsolete because of the need for provenance and a relevant & coherent clinical history.

I really don’t care how a care plan is implemented at the technical level, but IMO the ideal care plan has to be designed so that the master/monster can be viewed if necessary as well as providing filtered subsets appropriate for the viewer.

The per COMPOSITION approach seems clumsy to my non-tech thinking because so many sub-plan activities are not mutually exclusive from another sub-plan, so I can’t imaging how they can be clearly separated.

61

I’ll second that. I have three care plans under Medicare as a patient: one is active with two sub-plans and supersedes another, the third was several years ago.

None are likely to be flagged as obsolete; the date in the record is sufficient to indicate the status.

1 Like
62

The problem with this perspective is this is largely a technical problem with different solution, and we’re looking for input on the clinical safety issues of the proposed solution.
Let’s put aside the master composition/vs composition per sub plan for a moment please. Since it’s a separate issue.

The problem is: if I have different versions of a single care plan composition, how do I know (technically) which version is the ‘active’ one and which ones are old/outdated and which ones are future plans yet to be activated. Normally one assumes the latest ( complete) version is considered the current one. However with plans this isn’t always true, a draft plan version can be the newest version and (technically) complete, but not to be considered active clinically. So we want to be able to mark versions as not active (incomplete or obsolete). More info and alternative (technical) approaches are described in the linked specrm and specpr

This is exactly the implications I’m looking for.

It’s primarily something to be interpreted by the application. And the app can map it to something clinically interpretable in a given context. E.g. a technically obsolete version of a care plan, can be shown in the UI to be clinically/legally considered archived: “no longer in use, kept for archiving purposes, no longer to be guaranteed to be true/current information one can depend on”. (Like we use incomplete to indicate draft forms).

We previously considered calling the state ‘archived’ but that triggered expectation from software engineers that it could be stored on a backup tape outside the main system and should be immutable. Since this isn’t necessarily what we’re aiming for, we changed it to obsolete.
Other suggestions are welcome.

We will off course discuss the plan design: master vs seperate indexed compositions further, but maybe a live conversation would be helpful:)

63

Are they plans from multiple doctors from different specialties and from different institutions? How is coordination handled? May the cardiologist overwrite the plan from the endocrinologist (random examples)? If not (probably), they should be separate compositions, since the “compositions is the smallest unit that should be authorised, since the entire composition is needed to reliable interpret the clinical statements it contains. EHR Information Model

Also the date isn’t always sufficient, a neurosurgical care plan from when 30 years ago a ventricular peritoneal drain was placed, stating “visit doctor immediately in case of hydrocephalus signs” will be active life long. While a (version of) a plan from a surgeon that says take opioids in case of pain after surgery can be obsolete a few days later.

2 Likes
64

Hmmm - I wouldn’t expect to see this in a care plan… This is more like patient education to me.

I’d expect this to be an INSTRUCTION/ACTION pair that sets the time frame, and it expires after then few days

1 Like
65

My point is that ‘can be obsolete a few days later’ is a passive status, noone is going to bother to update the record. The GP who started the plan may be too busy to coordinate the plan; they might update it the next time the patient visits, but more likely will be looking at a new event.

66

I sense a difference in perspectives. My requirements are from a nursing home setting, where an elderly care physician intensively manages a small group of patients with complex multimorbidities using a care plan. Where the care plan is a list of sub plans which in turn consist of a problem one or more goals for that problem and one or more actions for those goals.

1 Like
67

That makes sense. But it would also make sense to record that action in a care composition, right? So what happens to the composition after it’s lost relevance?

68

Don’t forget most of the data in a long term health record is irrelevant (for current care - research obviously a different thing) after some days/weeks/months - most obs & labs, physical exams, and even minor diagnoses (infections, small injuries etc). It’s the persistent Compositions and (more recently) episodic Compositions of recent dates that matter.

Time (currency) is the basic criterion for determining relevancy. So I don’t think we should assume that unless old content is specifically marked obsolete it is going to get in the way. I think Care plans and some kinds of problem lists are likely to be the main candidates for this idea (as per your original analysis).

1 Like
69

Agreed. I think the default should be information in event category compositions are always to be (clinically) judged for currency, where time lapsed is indeed (usually) the most important criterion. This is routine clinical practice, often unconsciously.
For persistent compositions I’d like towards the status that they can by default be assumed to be current. (Off course for patient safety reasons the responsibility for checking this assumption remains with the healthcare professional). And should be marked obsolete if the information no longer is safe to be assumed current. (Known outdated, unmaintained archived etc).
Episodic compositions are a bit trickier and currency probably depends on the status of the episode. Which is not specified in openEHR afaik.

If we agree on this it may make sense to add this to the spec as descriptions/comments with the lifecycle states as part of the specrm-107.

70

This is the nub of the issue - whether the COMPOSITION could/should lose its relevance.

In my current thinking, there is only one COMPOSITION that carries all the tasks (per EHR, per aged care home, whatever context), forever. It doesn’t become obsolete at all because there is always something to do, even if it is only the next tetanus vaccination in 10 years time. If it is empty then there are no designated tasks until someone adds one but in this situation it is precisely because it is empty that we know there is nothing outstanding! If we have multiple COMPOSITIONs with varying states of currency that will be a challenge to query consistently, track activity states, and coordinate in a single setting with more than one practitioner - even worse in an integrated care setting with a multidisciplinary care team.

So the COMPOSITION carries the INSTRUCTION/ACTION pair for each sub plan, perhaps held within a SECTION for the purpose, plus the INSTRUCTION/ACTION pairs and goals for each clinical activity/task etc. This may need something like an INSTRUCTION index to support slick querying (@thomas.beale @heath.frankel ??) and filtering.

Maybe care plan is not the best use case. What are the use cases for other persistent COMPOSITIONs to become obsolete?

71

How about a problem list, let’s say the GP keeps a persistent problem list, now the patient is transferred to the hospital, (single EHR/federation/different EHR with post hoc data exchange) and the surgeon starts their own problem list, the GP’s one should be marked obsolete imho (and reactivated after discharge probably). Now we will end up at the same discussion probably, since I expect your view to be the surgeon should update the gp’s problem list, right?
I would again argue it’s unfeasible (technically impossible in the case of seperate EHRs afaik) and probably undesirable, since so much context (author, setting) and metadata (authorisations) has changed recorded in the composition. And most importantly the perspective has changed too much, GPs look at problems totally differently than surgeons do: DM to a gp is a condition that requires chronic management, to a surgeon it’s a higher risk of wound infection and someone you need to consult the diabetologist on to ‘fix those sugars’. If you take a nurses problem list and a doctors problem list, this difference in perspective grows even more problematic.
Now you may suggest in turn to have different views for surgeons, GPs and nursed on a single master problem list composition? And I than again would say you’ll run into issues like described above. Moreover would you be ok with recording DM2 three times(surgeon, gp, nurse) in that master composition? More info on the different perspectives on problem here: Audience specific problem name - #6 by ian.mcnicoll
(where from my previous thoughts, I still argues for the opposite I’m arguing now, I got convinced by Ian)

I do agree why you want to keep it closely together, it’s a single patient and single biochemical alteration off course. And integrating facilitates collaboration, and the current systems disjoint is one of the main reasons for working on openEHR. However I’ve come around to the idea that it’s better to record separate compositions and link problems together to keep them aligned.
This can even be using a single (medical) problem list, managed by a single doctor (if the healthcare system has such a coordinating person as the Netherlands does) that indexes other problem(lists). This can be done using a persistent composition with repeating DV_(EHR_)URI or FOLDERs, depending on whether it’s mostly a document or mostly an index.

72

Hi Joost,

No
It is hard to respond in a thread like this, maybe one day we’ll be able to get back to F2F meetings and this would be a great topic for inclusion in a modelling conference.

In an ideal openEHR world with shared health records, perfect data merging and an assigned Problem List coordinator, there would be a single problem list that can be filtered and ordered according to the viewer - in this case the GP view will be different to the renal physician and the community nurse not because any one of them shouldn’t have access to view the full list of problems, but what is considered a priority for GP chronic disease management is not the same for the renal physician who is managing only the chronic renal failure and all other diagnoses are effectively background considerations.

But it is tricky to try to mirror this across the reality of disparate systems - in fact, we can’t and probably shouldn’t. We can share a problem list between providers, but it should be up to them to include them in a local Problem list as EVAL.problem_diagnosis (or not) and also to potentially assign them relevant qualifier status (CLUSTER.problem_qualifier) that is relevant to the receiving care context. So the Problem/Diagnosis list can be kept applicable to all, but the context of primary or secondary diagnosis etc can be configurable per healthcare provider. Divergence may occur, but the intentional design of EVAL.problem_diagnosis level of information is key to supporting alignment when sharing, and the qualifier is usually only relevant at the local context level.
Again, I don’t think any Problem list would ever become obsolete, we just need to track its currency and update accordingly.
Just to add to the complexity, I suspect Nursing diagnoses should also be recorded using a separate archetype again because of the different semantics. DM2 would be recorded using the EVAL.problem_diagnosis but care-related risks and diagnoses should perhaps be recorded with slightly different semantics, although these could all be added to the local comprehensive problem list - again, filtering is key here.

Look forward to talking soon

Heather

1 Like
73

This is a long thread containing many parallell and overlapping topics.

For the there are (at least) three topics here:

Topic 1: Do any vendor, system or application need a way to mark a composition as archived or obsolete?
Yes they do.

Topic 2: Should obsolete/archived compositions be included in the result from an AQL query?
I have no strong opinion on the default except it need to be the same across all openEHR platforms/CDR. The applications and developers of those applications will need to look into the requirements for the specific case. And implement the use-case at hand regarding what to show and when to show the data.

Topic 3: How do we implement Care plan in openEHR?
Look into the Task Planning specification if you need to implement clinical process- and decision support.

2 Likes
74

I think Contsys have solved the definitions for episode, episode of care, etc. quite good. It’s always my reference when discussing such terms. It’s needed to have a useful conversation on how data are connected through a clinical process.

Most of the process related concepts fits reasonably well with #openehr folder. I would have modelled them years ago if we didn’t have the concept of episodes, periods, contacts, etc in our system before we went into #openehr.

3 Likes