When the outcome of an Action can be categorized as an Observation

Clinical
1

Hi, I’m a software developer from Brazil working on an EHR system.

This question may be obvious for this community, I’m sorry if that’s the case. But I have read a big part of the openEHR specifications and searched across this forum, and I’m still intrigued by this:

Suppose I have a Instruction archetype which contains an Action that describes an investigation request, requesting a certain test to be performed. The Action describes each step of the test, including the resulting data that should be obtained.

Once the test is performed, the completing of the Instruction suggests an Action to be recorded. But the results of that test suggest an Observation to be recorded. Recording both and repeating the data seems redundant. And recording an Action without the test result data (merely to advance the state of the Instruction) then recording a separate Observation with the data seems perhaps a bit inelegant and also to leave the Observation (test results) without a link to the Instruction/Action that originated it.

In my mind, it makes more sense for every data of a certain type to be recorded in a uniform fashion. So, a test result would be recorded as an Observation regardless of whether it came from an Instruction or not, and regardless also if it was performed within the same medical entity (same EHR system) or some third party.

What is the recommended approach here?
(and please correct me if my thinking above is wrong)

Thank you for those who’ve read this. This is a very inspiring community.

1 Like
2

Juan,
bem vindo… and good question! The real clinical modellers will no doubt respond, so I will just say what the intention of the reference model (i.e. types like Instruction, Action, Observation etc) is.

If an Instruction (representing some order, or even a protocol) has a number of steps, then it is usually important to know the steps have been done, so that the current status of the order can be determined.

You would only model an Action step representing the ‘doing’ of the test if you want to have that step explicitly recorded in the system, which might theoretically be useful, e.g the hospital could see that text X for patient P has been done at time T, and for a short time, there might be no result (the Observation) visible on the system.

Now, if the result never turns up, that Action containing that step is useful, because it says the lab (thinks it) did the test, so now you want to know where is the result. The system might also have some smart process tracking functionality that looks for these kinds of events, and finds orders (Instructions) that are not being done, or are half done etc.

However, if the system is not trying to do such smart things, then it doesn’t make sense to have to record an Action representing the performing of the test - as you say, the result (Observation) will just turn up (docs or patients will complain if it is taking too long, …)

In the future, plan definition and action tracking will be done by the Task Planning approach, which you can read about here. This won’t help you right now but it gives an idea of a general approach for more intelligent process-based systems for the near future.

hope this helps.

1 Like
3

Hey Juan, welcome!

To be correct, the reference model doesn’t allow an INSTRUCTION to contain an ACTION. What you have is a reference from the INSTRUCTION.activities.ACTIVITY.action_archetype_id (which is a regex) to one or many ACTION archetype IDs.

Check: EHR Information Model

This is saying “these ACTION archetypes could be recorded to modify the state of this INSTRUCTION/ACTIVITY”.

In a real lab environment from order to execution and getting the results, you will have something like this in archetypes:

  1. COMPOSITION.lab_order
  • INSTRUCTION.lab_order
  • ACTION.lab_action << this will set the first state for the INSTRUCTION/ACTION as PLANNED (check EHR Information Model)

That ACTION is a dummy entry and doesn’t need to record any data, just needs to be there to move set the initial state of the INSTRUCTION/ACTIVITY

  1. COMPOSITION.lab_scheduled
  • ADMIN_ENTRY.schedule_service
  • ACTION.lab_action << this will set the state of the INSTRUCTION/ACTION to SCHEDULED (check EHR Information Model)
  1. COMPOSITION.lab_execution
  • OBSERVATION.sample << blood/urine/etc taken from the patient
  • ACTION.lab_action << this will set the state of the INSTRUCTION/ACTION to ACTIVE (check EHR Information Model)
  1. COMPOSITION.lab_results
  • OBSERVATION.results << confirmed results
  • ACTION.lab_action << this will set the state of the INSTRUCTION/ACTION to COMPLETED (check EHR Information Model)

This is just an example, not saying you should model it this way. But when you model you need to consider the full COMPOSITION, not just the entries, and the need of that initial dummy ACTION is something a little difficult to realize just by reading the openEHR specs.

Hope that helps.

2 Likes
4

Thanks Thomas, very clarifying.

So, based on your answer (and correct me if I’m wrong), my current understanding is that Action is mainly a cog of the Instruction state machine, it may or not be used, depending on how much one needs to control and track the state of an Instruction; and also that recording measurements is indeed a job for an Observation entry.

Excited about the future of openEHR with task planning. So happy to have come across openEHR, the most elegant technical bridge between technicians and domain experts that I know of.

2 Likes
5

Thanks a lot for giving a thorough and useful example.

So you’re using Compositions to couple Actions with the entry type that records the data that is generated from the Action being taken.

There’s still something I’m still a bit confused about, though. Suppose an Instruction/Activity specifies in its description attribute a certain clinical procedure consisting of multiple different drugs with specific dosages and following a specific schedule. Once the procedure is followed, it needs to record some variation in drugs/timing/dosage from what was instructed—so I suppose that’s why Actions also have a description attribute, which is part of my confusion of how to use Action objects vs Observation objects.

How would you model that? Would you transfer that data (which was described in ACTIVITY.instruction) to an Observation entry, and couple it with an Action entry within the same Composition, as you laid you in your example? Or would you leave the data in the Action?

I guess my overall question is: Should Action objects ever hold data when the data suggests itself as an Observation? Or should such data always be inside Observations, and Action objects merely move the Activity state machine?

(sorry for such long reply!)

1 Like
6

Hi Juan,

That’s a good way of looking at it. Some clinical activities like procedures and medication prescribing/dispensing etc generally have very close relationship to state machine tracking but this is often not so clear for Observations, where either formal tracking of of the activity is not needed or the request being tracked is for a group of Observations. e.g ‘Please do Vital signs obs every 4 hours’ - pulse, Bp, resps etc’.

Good to hear you are liking openEHR!!

2 Likes
7

I would put each specification on a different ACTIVITY.

Any change in the state of the order is represented by an ACTION.

The difference is just that: is the recorded information changing the state of the INSTRUCTION/ACTIVITY or is about recording some result of the procedure. The result doesn’t change the state, is an outcome.

With my students I use this analogy:

  • INSTRUCTION: is the definition of a function
  • ACTION: is the execution/evaluation of the function
  • OBSERVATION: is the result of the function

That of course is not 100% correct in all contexts, is just to give an idea of how to model the information that should be recorded for some complex processes.

Another useful idea is:

  • INSTRUCTION: record something that should be done in the future
  • ACTION: record something that happened in the past, already happened
  • OBSERVATION: record something that is asked, observed, measured in this moment (present)

Also not 100% accurate but gives an idea on when to use each type of entry.

Yes, a state change for the INSTRUCTION/ACTIVITY sometimes has useful information to be recorded about that change, like when starting the execution of a process, a nurse could record the verifications done before administering a medication to the patient, or why the medication was suspended, or why the schedule of the medication was changed, etc.

OBSERVATIONS do not change the state of an INSTRUCTION/ACTIVITY.

Hope that helps!

2 Likes
8

Largely agree Pablo, other than that I would probably model a set of prescriptions as individual INSTRUCTIONS. In theory one could use multliple ACTIVITY objects within the same INSTRUCTION, particularly if they were clinically tightly bound e.g an antibiotic regimen for H. Pylori but, in practice this requires the UI to have some idea of Grouped orders which complicates things. AFAIK the main production systems use single activity per instruction, though there was a recent discussion about using Activities to handle multiple alternate routes for the same drug e.g IV/Oral.

The main thing is that there is no imperative to always record INSTRUCTION and ACTION and OBSERVATION.Many Observations have no need of explicit Instructions/Actions (though they probably exist implicitly), and surgical procedures and medication (Instructions/actions) do not usually have associated Observations.

2 Likes
9

Normally multiple drugs would each be an Instruction, even in an order set (e.g. RCHOPS chemo drugs, given together) because it is nearly always the case that each drug can have actions taken independently as you mention. E.g. one drug might be suspended for a time, until cortisone can be administered to reduce reaction; doses can be adjust slightly; timings can be adjusted and so on.

If it is not a single order, then multiple drugs has to be separate INSTRUCTIONs anyway, since they will correspond to separate prescription ids, drug payment rules and other administrative/payor related details.

I would reserve different ACTIVITYs in the same INSTRUCTION for variant uses of the same drug e.g. stepwise reduction of dosage over time.

2 Likes
10

I agree, though that is a modelling choice.

I think, correct me if I’m wrong, an ACTION could change the status of each ACTIVITY independently, that is why I mentioned that option. For instance, suspend one ACTIVITY, and complete another, both in the same INSTRUCTION.

2 Likes
11

Thanks for the feedback, it has been helpful.

Take this example: A physician asks a patient to perform a blood test, or urine analysis, in some lab somewhere else, and return with the results on another day.

In this example we’d need a record of the order in the day of the appointment/test request, and then a record of the results on the day the patient returns.

How would you model it?

  • INSTRUCTION then ACTION?
  • INSTRUCTION then OBSERVATION?
  • INSTRUCTION then ACTION+OBSERVATION?
12

Hi Juan,

Yes, the clinician’s order (INSTRUCTION) is used to generate a test request, which is taken by the patient/sent electronically to a lab somewhere. Concurrently, in the clinician’s system, the test-related ACTION might only record the minimum of test name and state of ‘planned’, or maybe even ‘scheduled’.

When the test result is received (OBSERVATION), the clinician’s system’s ACTION is set to ‘completed’.
If there was an outstanding order index, the original INSTRUCTION would no longer be active and the INSTRUCTION/ACTION loop closed, with the result OBSERVATION documenting the outcome of the process.

Note that sometimes the test actually done by the lab may not align with the test ordered by the clinician. This will be demonstrated by comparing the ‘Test name’ in the completed ACTION (and related result OBSERVATION) against the ‘Test name’ in the original INSTRUCTION and planned ACTION step.

The pathway steps can be much more convoluted, especially if a lab test is sent on to specialised labs for the actual testing process, but don’t get caught up in the pathway steps that belong within the Lab system and internal processes - we are just capturing the relevant data for the EHR component.

It is complex, especially getting your head around how the ACTIONs work in relation to the other classes.

Designing ACTIONS is not easy - you will note there are not so many yet. The art of designing an ACTION is trying not to duplicate the data unnecessarily - ideally, we only want the ACTION to carry info that is relevant to support recording requirements for one or more of the pathway steps. Duplication of INSTRUCTION or OBS data points in the ACTION should be discouraged in principle.

It gets even more complicated in a fragmented ecosystem if an ACTION might be recorded without the original INSTRUCTION. For clinical safety reasons this might require including some data elements that might provide context of the original clinician’s intent eg clinical background and clinical indication, but potentially replicate what should have been in the original INSTRUCTION.

The critical part in modelling of ACTIONs is differentiating from the INSTRUCTION which is recording the clinician’s intent and need. The OBSERVATION records the result/outcome. The ACTION only records relevant key bits of data to track the progress and activities between generation of INSTRUCTION and the closing off of the process on receipt and ‘virtual filing’ of the OBSERVATION.
Cheers

Heather

3 Likes