Care plans in the real world

Implementation
1

Hi all,

I’m curious to understand more about the extent of care planning implementation experience in the wild. If anyone is willing to provide some insights into their approach to developing and managing care plans it would be appreciated.
Ping @heath.frankel/@Seref from Ocean, @joostholslag from NEDAP.
Others?.. there must be many other implementations - ranging from simple to very complex; stand-alone to integrated/shared.

In particular, I’d like to get some insight if the current archetypes are supporting this work appropriately. There have been no requests that I’m aware of, from vendors seeking archetypes to support care planning.

The earliest iteration of the COMPOSITION.care_plan contains a proposed structure which gives insight into how I envisaged that a care plan might be constructed - as a single persistent list containing goals/targets and a collection of INSTRUCTION/ACTION pairs. The latest iteration has had that content removed as result of an Editorial decision to remove any constraints in templates as design guidance, but the intended build of a SECTION representing this content has not quite eventuated as planned.

This recent thread with @joostholslag proposes a slightly different approach.

If you look at CKM, the INSTRUCTION/ACTION duo is one of the least mature areas of our modelling - only a handful of each.

The INSTRUCTION.service_request can be very flexible for many situations by using a value set within the ‘Service name’ data element.

There are very few ACTIONs developed to date, mainly because there has been no request for them. However, a single, matching generic ACTION is unlikely to adequately record the data elements or the pathway required for most of the values within that ‘Service name’ value set. We have a generic ACTION.service but in truth, I’m not sure it has ever been used in an implementation, presumably because it is too generic - the attempt for ‘one size fits all’ results in ‘one size fits none’!

I’ve always anticipated that we would eventually have to develop a rather large number of ACTIONs, potentially one for each possible Service that can be requested, ensuring that the data elements and pathway steps are accurate and appropriate for the service. Despite their apparent elegant simplicity and clever approach to recording the progress/activities related to each INSTRUCTION, they are by far the hardest to design & model. Frankly, we have little experience in building them and care planning is the perfect environment in which to sharpen our modelling skillset and support smart care planning implementations.

Personally, I’d also like to see more cross-pollination between the openEHR programs, and the different types of members. Consider things like:

  • Developing a library of case studies about how care plans have been implemented
  • Developing guidance for ‘best practice’, or even a range of options, for care plan implementation.
  • Developing issues and pitfalls to avoid
  • Developing a collaborative effort to develop and fund the archetypes required to support this work
  • Publishing a governed package or release set of archetypes, shareable templates, other supporting technical artefacts and implementation guidance for newbies
  • etc
2 Likes
2

My apologies @heather.leslie , I missed the ping and became aware of it when it was mentioned yesterday in a SEC meet. I’ll do my best to get back to you asap.

2 Likes
3

I’ve just been looking at the INSTRUCTION.service_request and ACTION.service pair. The concept is clearly right, I think it is to be expected that a) there should be a growing number of specific ACTION.xyz_service specialised archetypes defined, for whatever processes are somewhat standard and b) there will routinely be local specialisations of ACTION.service, since most service processes will be non-standard.

So I think the approach from here would be to try a few examples, e.g. ‘case review’ or some other typical ‘service’ and see what falls out.

Should have read this first :wink:

Agree. There are technical issues here like ‘citations’ and ‘views’ which would help the authoring of Care Plans, which need to reference other recorded items (previous Dx, labs, goals etc). Also, we might want to consider more support for the ACTION careflow / state machines.

2 Likes
4

Some technical thoughts…

First let’s assume a Care Plan roughly includes:

  • Dx: primary diagnosis or problem (what the CP is there to address)
  • Obs: supporting evidence: symptoms, labs, imaging, other investigations
  • G: goals given Dx and patient specifics
  • Pr: prognosis - outlook for the patient as things stand
  • P: the main plan
    • R: recommendations - general description of approach, e.g. recommend lumpectomy + chemo + monitoring
    • O: orders
    • A: actions resulting from the orders
  • M: Monitoring / follow-up plan
    • probably more orders, e.g. service requests.

Then we can think about what is directly included in the plan, and what is referenced (or ‘cited’) by the plan. Normally Observations and Dx are made before a plan - the plan is created as a result of the Dx. Goals and recommendations are usually authored as part of the plan. Orders (Instructions) could be part of the plan, or they might be created by someone else (junior docs, following the plan for example) and created separately. Actions resulting from the Orders almost certainly won’t be ‘in the plan’.

So a fair bit of the plan’s contents are references to pre-existing data (Dx, some Obs) and to-be-created data - possibly Orders, and certainly Actions.

So we need a proper citation mechanism to do this properly. We have discussed this at great length, and there are some mooted improvements to the RM to support it.

Under this idea, the Care Plan contains some primary content plus a lot of references to other content relevant to the plan - i.e. it is partially an index of other content, particularly Orders and Actions. Creating a new Order based on a Care Plan should cause a citation / ref to that Order to be added to the plan; same for Actions resulting from the Order.

So then an interesting question is: what does archetyping of all this look like? If we were to go with the VIEW_ENTRY approach, it’s quite easy, because your archetype contains VIEW_ENTRYs and they would be marked to be of a certain RM type or archetype - e.g. INSTRUCTION.service_request etc.

1 Like
5

I would suggest that most, if not all of the pre-existing data stays where it is and we link to it/cite or reference it as necessary. From my POV the care plan contains the plan - the goals & targets plus the order/action pairs.

  • Goals & targets are updated over time as a result of test results, measurements, consultations etc.
  • The list of order/action pairs is updated as orders are completed…

We need to discuss what we mean by a care plan. Is there a single ‘master’ from a patient POV, which may include ‘sub plans’ eg immunisation plan (which could kickstart an infant’s record), diabetes management plan. There is a need to see all outstanding goals/orders/actions in order to do appropriate care coordination eg to ensure that a BP measurement required in 4 weeks time for the diabetes sub plan and another BP measurement due in 6 weeks for the hypertension sub plan is done at the same visit in 5 weeks by their GP to prevent duplication and two 3 hour round trips on public transport etc.

How to display all that is planned for those who need to see everything, yet filter it so that role-based activities are highlighted or read only in others. Plus all the shades of grey in between re views and permissions to add, update or modify.

It is super complex, but unless we have some kind of common approach, us modellers are guessing what is required for implementation.

1 Like
6

Yep - I think we are on the same page. I missed targets.

Right, this goes back to your discussion on the other thread. As I said there, the patient is a singleton - a term we use in IT to mean a single instance object that is shared by many others. This is why in principle we would want to see one Meds list, one Dx list, one Allergies list, etc, and the same logic applies to goals, active orders and so on.

The patient is a real-world singleton, and representing it in the IT requires a digital twin approach - for the data to be a faithful informational proxy of the one person in the real world.

openEHR (when used as a patient-centric EHR) does this with the managed lists.

But the traditional approach to care plans - if we leave nursing care plans to the side for a minute - is a per-department or per-problem basis (for major problems). And we have not yet evolved openEHR to properly using the digital twin approach to Care Plans, including their primary content, i.e. goals, targets and complete order sets (i.e. beyond medications).

This is exactly the question. We need to make these separate problem-based care plans views on something integrated, yet which functions on a per-problem basis from the POV of departments / specialisations.

Aside: this need reflects a major challenge with CPGs, which is merging / de-conflicting when used together on patients with co-morbidities (see here in TP specs).

To summarise, we need the following in openEHR:

  • proper citation Entries or similar, to point to data external to but relevant to a Care Plan
  • apply the digital twin (single source of truth) approach not just to today’s managed lists (medications, allergies, etc) but more generally to all orders (meds being just a subset) - plan-originated or not, and possibly to goals, recommendations and targets
  • a Care Plan design that allows for distinct specialist ‘plans’ whose underlying structure respects the digital twin approach.

So, what’s the Care Plan design that does this properly? I think we need to accept that distinct CPs will need to exist, since the point of each one is to look at a problem and establish a care pathway based on goals.

The first innovation we might have is to consider the need for a single ‘orders list’, which is like the Medications list, but for all the other orders. Just doing this would provide some ability to efficiently plan & co-ordinate major investigations (e.g. MRIs, biopsies etc)as well as more mundane Obs.

For goals and recommendations, it seems to me that they could live in their own Care Plans, but would a merged ‘goal’ list make sense? Same question for targets (i.e. concretely measurable proxies for goals).

At a data level, I would see each Care Plan being its own Composition containing some original content and mostly references - much to items that are also listed in the other managed lists (Rx and so on).

To achieve the integrated effect would most likely mean designing a digital-twin style API above the underlying basic data, such that change to any CP or its elements could only be done via that API, and would result only in coherent changes to the CPs as well as to any of the other singleton lists.

There are a lot more details to think about, but the main thing to understand initially is that we cannot solve everything just in the data layer i.e. via archetype design.

I have been working with a US group outside openEHR on some of the digital twin thinking (as it relates to live and historical patient data consumed by executing plans and CDS). I think it would be a good time to get an openEHR working group together on this area.

1 Like
7

Just for fun, I sometimes say Order + Actions are ‘snakes’ - the Instruction is the head, and the numerous Actions accumulating over time are the body.

Querying on all those snakes can get the current state of each order from the (current) tail of each snake.

Others may prefer centipedes…