Procedure or not procedure?

Clinical Ask an editor
1

ACTION.procedure is a great archetype and it is published a long time ago. I guess all reading this post know the archetype and has some opinions on how to use it.

Surprisingly we discovered that we had really different views on the scope for the archetype. This appeared to my during this thread with Heather on the openEHR CKM.

This post is an invitation to share thoughts about the ACTION.procedure and it’s use in current systems, it’s intended purpose/scope and the future direction for the archetype.

Some background:
We, DIPS AS, is currently implementing an application to support the national patient safety program. Some information, in Norwegian, about the program is found here: https://pasientsikkerhetsprogrammet.no/ The purpose of the program is to reduce the frequency of unwanted events when providing health care. The program is divided into several focus areas like: risk of falling, pressure soar/ulcers, sepsis, changed somatic state, suicide, malnutrition and so on. The application we are building will use a lot of screening archetypes (Stratify, NEWS , NRS2002, etc.)

In addition to this straight forward archetype usage we want to record the action taken to follow up the admitted patient. Examples of such activities is:

  • Screening for risk of falling
  • Create plan to reduce risk of falling
  • Do actions do reduce risk of falling
  • Evaluate the plan and/or re-evaluate the risk for falling
  • Complete the activity

To record these steps we will use openEHR Taskplanning in a future release. Currently we need to support the use-case with “old-school” archetypes, and we ended up with the following postulate/conclusion:

The ACTION.procedure is perfect match to record the activities as illustrated above. But we need a minor adjustment: we need to add a new careflow step for the action of evaluating/reviewing the ongoing activity.

This was when we realised, together with @siljelb and @heather.leslie that the original intention for ACTION.procedure was not to be used in such a use-case.

As far as I understand the intention for ACTION.procedure is to cover more “one-shot” actions, and not to manage long-running activities.

So my intention with this topic is to open a discussion about ACTION.procedure and the modelling for such a use-case as described.

What do you think?

  • Is ACTION.procedure well-fitted for the use-case described?
  • Should we create some new archetype for my use-case?
    • Should it be one or several archetypes?
    • Perhaps the suggested design is wrong in the first time?

Look forward to some opinions on this!

2 Likes
2

Slightly off-topic perhaps, but what will happen to all ACTION.procedure implementations when/if Task Planning becomes a thing?

3

That’s not off topic. It’s a very good question.

What will happen is that ACTION.procedure will be used within a Taskplan. This could be expressed in a DATASET_SPEC. This makes it, finally, possible to define the careflow steps as part of a formal definition.

So IMHO Taskplanning will build upon the existing published arcetype to increase the value of the ecosystem.

4

To add a little bit to that, you can see the ENTRY class referred to in this part of the TP spec, as a ‘prototype’ of a DEFINED_ACTION. Most commonly, this ENTRY will be an ACTION. So this connects ‘planned actions’ with prototypes of ‘actual actions’ (possibly partly built, or maybe just specified by archetype id).

The use of Task Planning will not break any current implementation of INSTRUCTION, ACTION etc, but it should provide more effective ways to build pre-planned pathways of Actions, not just have them record something that was done as it was done, which is the case today.

1 Like
5

Being able to use it as part of the TASK structure (the ENTRY prototype) seems to enable more intelligent application of existing ACTION archetypes (by not having to create various intelligent transforms to apply on DATASET_SPEC items depending on inferred type)?
Still @bna sorry to somewhat derail the thread - you haven’t got an answer yet to your real question - but thanks both for the replies!

1 Like
6

In for a penny!! For this use-case, I would have opted for ACTION.service (possibly multiple).

The other example that was discussed separately was the cycle of venous Cannula insertion and subsequent monitoring by nursing staff e.g. insertion, regular Observations for patency, infection and eventually removal. In this case I would be more likely to use ACTION.procedure, certainly for insertion and removal, but possibly and encompassing Service to include the observational reviews.

A lot will depend on the degree to which you want to (and are able) record the granularity of these activities e.g. some folks might want to document specifically every single review as an Action, whilst others will be happy just to let the Observations act as proxies for the Actions.

I don’t think we need any new archetypes, at least at ENTRY level. I’d tend to agree with the view that if you need ‘review steps’, then Service might be a better fit than Procedure.

Can we come up with an expanded set of examples?

2 Likes