Instructions and Actions - work flow in openEHR

Owned by (Sam Heard) inactive (Unlicensed)
Last updated: 20-Jul-2008Version comment

The reference model provides a mechanism for dealing with distributed recording of actions against instructions (and contained activities). This is described in the specification documentation but left to individual implementers to deal with the workflow process. As there is no accepted workflow standard, the DV_PARSABLE data type is used for the time being to allow the representation of workflow expressed in any syntax, e.g. YAWL, BPEL, XPDL and so on.

Two things have become clear:

  1. The state of an Instruction as a whole is distinct from the state of each of the Activities
  2. The process of keeping track of Actions and changing states with respect to Instructions is probably worth formalising. To make this easier I have added some regions to the above diagram.

 Instruction State

The state of an Instruction, from a machine point of view, can be known at least to four different states based on the action state model in the reference model.

  • Terminated
    • All Activities in an Instruction are in a terminal state
    • A special case of this is
      • Completed in full
        • All Activities in an Instruction are completed 
  • Inactive
    •  No Activities are in an active state and at least one of the activities is in the suspended state
  • Active
    • At least one of the Activities is in an active state
  • Pre-active
    • No Activities have entered an active state (Initial, planned, postponed, cancelled only)

I believe a state machine that derives such states from the states of the activities will be helpful from a machine and human point of view.

Instruction Index

The Ocean team have been working with the idea of an Instruction index that maintains a list of all Instructions in the EHR and the state of each Activity.

When any Action is committed to the EHR the Action and associated state can be recorded against the Instruction Index and the state of the activity updated. The advantage of this is that actions recorded elsewhere can update the index. This does require a strong link to the Instruction which at present is an EHR_URI. This works well in an environment where there is one source of authority for the Instruction, but is potentially problematic when doses get adjusted in a distributed environment.We need to consider an appropriate model for allowing updates of Instructions that replace previous instructions and understand how this might be managed in a distributed environment.

The structure of the Instruction Index is something worth considering. It provides a link back to all Actions. It can of course be reconstructed from the data and is the first component of the EHR which I do not think should be versioned but should run as a component of any implementation. The medico-legal aspects, should they arise, should be determined from the EHR. Different implementers will do it differently. It will not be shareable as the Instructions at one site are very likely to be different from the Instructions at another site. Sharing the care plan will mean that Instructions are shared that are not acted upon at all sites.