Anatomy of a Procedure

Posted on by

ACTION archetypes are one of the harder concepts to grasp in the openEHR clinical modeling world.

ACTIONs appear to be promising the world – allowing for recording all activities from planning, scheduling, postponing, cancelling, suspending, through to carrying out and completing an activity. While they may appear cumbersome at first, they are surprisingly elegant and fit for purpose… once you can twist your brain around them.

Consider ACTION archetypes as a walrus – awkward on land, but graceful in the water – well maybe the analogy is being stretched a little, but you get my drift.

Whatever you do, don’t underestimate the power of these little clinical models. ACTIONs are designed to enable sophisticated tracking of activities being carried out in a distributed environment – perfect for managing care pathways between multiple providers in disparate locations – not an easy task.

Take a look at this slide show – my attempt to provide a concrete example of how a Procedure ACTION archetype will support documentation about how an INSTRUCTION or order for a Procedure (any procedure, potentially) is carried out in a shared electronic health record environment.

  • ‘Pathway steps’ are identified as the steps (not necessarily sequential) or clinical activities in which it makes sense to record some information in the health record.
  • The Data Elements that are identified in the ‘Description’ include any and all information that we may wish to record for any of the Pathway steps. For example, the data we need to record when we plan to perform a Procedure or the information required to record that the Procedure was performed or abandoned, including the reason for abandonment.

 

Updated: August 17, 2011

6 thoughts on “Anatomy of a Procedure”

  1. Hi Heather, I’m trying to understand how and when to create the ACTION.instruction_details.wf_details structure.

    Could I create the structure by copying the correspondent INSTRUCTION.wf_definition, and modifying the values recorded in the plan (INSTRUCTION)?

    E.g. if the planned start time of the procedure (INSTRUCTION) differs from the real start time of the performed procedure (ACTION), should I change the procedure time value on the ACTION.instruction_details.wf_details structure structure?.

    Is this right for you?

    Thanks a lot!

    Kind regards,
    Pablo.

    Reply ↓

    • Pablo,
      I’m sorry – I can talk to you in terms of how to do this in the openEHR AE tooling, but not from an ADL perspective. Suggest you go to Ian McNicoll or the list for talking technical.

      In the Procedure INSTRUCTION – http://dcm.nehta.org.au/ckm/OKM.html#showArchetype_1013.1.937. There are a number of possible data elements providing information about potential timings required by the clinician who may be scheduling the procedure themselves or very distant from the scheduling and relying on third parties or third party apps for this process. Info re timing includes an instruction re the exact date/time that the procedure needs to be done &/or a statement about Urgency &/or Latest date procedure required to be completed.

      That said, in http://dcm.nehta.org.au/ckm/OKM.html#showArchetype_1013.1.936, there is a Start Date/Time – used to represent the formal Planned Start Date/Time (when it is formally scheduled) in the ACTION at the “Procedure Scheduled” careflow_step and then the actual Procedure Start Date/Time using the same data element but at the “Procedure performed” careflow_step.

      Does that help?

      Reply ↓

  2. Hi Heather, thanks for the answer.

    My question arises from the use of the AE, because when editing an ACTION archetype the ACTION.ism_transition attribute can be archetyped but the ACTION.instruction_details not. Now I’ve the RM in front of me, and I see that the INSTRUCTION_DETAILS is not archetypable, so it’s ok that the AE doesn’t allow me to archetype the ACTION.instruction_details attribute, but the ISM_TRANSITION isn’t archetypable neither. So maybe this is a bug on the AE or in the specs (http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 53).

    The start date/time was just an example to understand what can I put on the ACTION.instruction_details attribute, that was a bad example because the time of the ACTION is recorded in the ACTION.time attribute, sorry for that.

    I’d like your opinion on one more thing. As I understand it, when you have an INSTRUCTION only ACTIONs could make de ISM to move from one state to another. But scheduling a procedure isn’t an ADMIN_ENTRY instead of an ACTION? In that case, the ADMIN_ENTRY could move the ISM from planned to scheduled. What do you think?

    I’ll try to aks on the lists about this topic. Thanks a lot!

    Reply ↓

    • Hi Pablo,

      I’ll leave someone else to comment on the specs.

      However regarding the use of ADMIN_ENTRY – keep in mind that we are working with archetypes within a clinical system. The ACTION records data that is relevant at named points in time (ie pathway steps/States specified in the ACTION) to record how an INSTRUCTION has been carried out. The reality is that scheduling of a procedure will likely happen inside an external system and it will be the notification of that scheduling (eg via a message) that will trigger the change of state to ‘Scheduled’ and include the date/time/location etc from the content of the message as required.

      Reply ↓

  3. The start date/time was just an example to understand what can I put on the ACTION.instruction_details attribute, that was a bad example because the time of the ACTION is recorded in the ACTION.time attribute, sorry for that.

    I’d like your opinion on one more thing. As I understand it, when you have an INSTRUCTION only ACTIONs could make de ISM to move from one state to another. But scheduling a procedure isn’t an ADMIN_ENTRY instead of an ACTION? In that case, the ADMIN_ENTRY could move the ISM from planned to scheduled. What do you think?

    I’ll try to aks on the lists about this topic. Thanks a lot!

    Reply ↓

    • It is true that the scheduling of a procedure is an administrative process. However don’t mistake that we are trying to create a scheduling system using this archetype – this is absolutely not the case and a scheduling system may comprise ADMIN_ENTRY archetypes.

      With this ACTION, we are merely trying to keep track of the process of the INSTRUCTION. After all, it is just as important for a clinician to know that their instruction is scheduled, as it is to know it has been aborted or completed.

      Reply ↓

Leave a comment