Action specifications

Technical (archive)
1

Dear All

In developing an ontology for health record recordings - an archetype
ontology - I have come to the idea that there is a great deal of utility in
the idea of an 'action specification'. This is the part of an instruction
that says what to do - not when (or under what conditions) to do it.

Let me give you an example:

  A medication order is an instruction:

    medication=Amoxycillin: dose=250mg: route=IV: frequency=three times daily

  The action specification is:

    medication=Amoxycillin: dose=250mg: route=IV

  The when part is:

    frequency=three times daily

OR A Pap test notification instruction might consist of:

    Action is Pap Test & send specimen to laboratory
    When is two years since last pap test OR 1/1/03

The important thing is that the 'action specification' can be reused in the
EHR as a record of what was done. So a medication administration reuses the
action specification of a medication order - and has a record of who
administered it - likewise for the Pap test.

There may be no need to do this at the information model level - perhaps
leave it to the application. But there are some advantages - a consistent
description of what is to be done and what was done using the same
structure - guaranteed transformation from an instruction to recording an
action.

Comments?

Cheers, Sam

2

Sam wrote:

In developing an ontology for health record recordings - an archetype
ontology - I have come to the idea that there is a great deal of utility in
the idea of an 'action specification'. This is the part of an instruction
that says what to do - not when (or under what conditions) to do it.

Let me give you an example:

A medication order is an instruction:

  medication=Amoxycillin: dose=250mg: route=IV:
frequency=three times daily

The action specification is:

  medication=Amoxycillin: dose=250mg: route=IV

The when part is:

  frequency=three times daily

Indeed. A very valuable specification. Might I add that one of the
strategic aims of a system is to reduce medical error risks. In the example
above, one could imagine practical applications towards that goal by
emphasising the specific action (for example, route=IV: route=not intra
thecal), or some suitable alert.

Better at the information model level than the application.

Ahmad Risk

3

In developing an ontology for health record recordings - an archetype
ontology - I have come to the idea that there is a great deal of utility in
the idea of an 'action specification'. This is the part of an instruction
that says what to do - not when (or under what conditions) to do it.

Indeed. A very valuable specification. Might I add that one of the
strategic aims of a system is to reduce medical error risks. In the example
above, one could imagine practical applications towards that goal by
emphasising the specific action (for example, route=IV: route=not intra
thecal), or some suitable alert.

This very much leans towards "programmed guidelines". One
should probably have a good look at what those projects have
to offer.

Karsten Hilbert

4

Karsten Hilbert:

This very much leans towards "programmed guidelines". One
should probably have a good look at what those projects have
to offer.

You're right, but these are dangerous waters. My comment was far less
ambitious :slight_smile:

It is to do, perhaps, with incorporating 'safe practice' when there are
known facts.

Ahmad Risk

5

>This very much leans towards "programmed guidelines". One
>should probably have a good look at what those projects have
>to offer.
You're right, but these are dangerous waters. My comment was far less
ambitious :slight_smile:

I know. It was rather meant as a cautionary comment :slight_smile:

It is to do, perhaps, with incorporating 'safe practice' when there are
known facts.

This sort of thing has been raised by one of the Old Wise Guys(tm)
at, I believe, openhealt-list. The suggestion was to "hardcode"
certain common medication errors (Penicillin vs. Penicillamin,
Metamizol vs. Methotrexate).

Karsten

6

This sort of thing has been raised by one of the Old Wise Guys(tm)

                                                   ^^^^^^^^^^^^^
               Wise Old Guys
of course, pardon me :slight_smile:

Karsten

7

Aniket

Thanks for that.
Thanks for your thoughts.

There are finite orders in the Medical Terminology
which can be classifed according to the department and
coded.
Effort such as CPT(Common procedural terminology) can
be extended and continued to encompass all such
'action specifications'.
Thus the medical record can be structured broadly into
a.Enquiry specifications(history)

We call these observations (as per Rector) - the subject is the source.

b.Examination specifications(clinical examination)

We also call these observations - the clinician is the source.

It is quite difficult to separate these more conclusively - a patient may
say they are constipated and have not used their bowels for 5 days - in a
nursing home a care attendant might notice that the patient has not used
their bowels for 5 days. These are no different except in source and we have
found it helpful to use the same information component.

c.Action specifications which can be further divided
into
1.Clinical actions(Temparature,Pulse,Blood Pressure
etc.)

As we are only concerned with the record - we can record these as
observations - but they can be the subject of an instruction. For these
types (having their own archetype) the specification is not so important -
but with medication and other complex instructions it becomes very helpful
to reuse the instruction data.

2.Laboratory actions(All lab orders)

These are instructions

3.Procedure actions(OT,Cath-lab)

These are often complex records - but for us at present are an observation
with the ability to accept an action specification.

4.Medication actions.

Administration is the same as procedure - but the medication order is an
instruction.

Cheers,

Sam

8

Sam et al,

Sometimes it is beneficial to stand back and review the purpose
of EHRs, when trying to categorise content. No doubt you have done
this far more often than me, but for yet another high level perspective
here is my current view.

9

Eric Browne wrote:

It seems to me that openEHR's view of EHR content is still biased
towards the healthcare provider's view of the world, as if a person's
lifelong health status can be represented soley by a linear ( in time)
sequence of "actions" by healthcare providers. It should be remembered
that many of the "events" that change a subject's state
are independent of "intentional acts of health professionals".
In twenty or thirty year's time, we may be mature enough to realize
that the event "person X was made redundant from their employment today"
may have significantly greater effect on X's future health ( or the
health of a close friend/relative ), than "person X was diagnosed with
mumps today". If this is the case, then surely such events should
legitimately be recorded in an EHR?

it may be that our documentation of openEHR does not make it clear enough how richly structured the EHR could be. Everything that is recorded is committed at some date/time by someone, and usually talks about some event, thought, or proposed action, with date/time information attached. However, this time information is not the primary logical structure of the reocrd. The data can be organised and presented according to how an application wishes
- e.g. problem / issue "threads" which link symptom observations, diff. diagnoses, test results, diagnosis, care plan modificaitons, etc etc for each problem;

- on a time base of problems & issues
- current situation - active problems, therapeutic precautions, etc
- current proposed actions taken from care plan - this might be a 'care pathway' view

In your example, there is nothing in openEHR to stop someone (including the patient) recording that they were fired from work.

I have problems with lumping too many things under observations, without
distinguishing between "state" and "changes to state". Consider the
following:-

A. The _observation_ "subject weighs Y kilograms" is a state recording.
B. The _observation_ "subject experienced severe pain in lower left abdomen"
  is an event recording. An event causes a change of state.

this is recorded using an ENTRY made up of a HISTORY of 1 EVENT with duration xxxx, and data of type STRUCTURE, i.e. a data structure characterising the pain

C. The _action_specification_ "appendectomy" is a process recording. It
  similarly causes a change of state.

it depends on whether the procedure has occurred, or whether it is to occur in the future. If in the future, it is an action specification. Note that time in the future is not linear, it is branching, and conditional.

In the above, openEHR places A and B in the observation category. But
from a healthcare perspectve, B is closer to C, than to A.

I'm not sure I udnerstand why this is - can you elaborate?

Someone looking back in time through an EHR might be looking for
seminal events of a certain class. Again, consider a person admitted
to an Itensive Care Unit (ICU) with first degree burns. The current
"Service-Action" view of the world emphasises the care provided at
the ICU, thus de-emphasing the important change_of_state event, namely
the burn event.

I'm not sure why you say this - I would expect that the following would be recorded in the EHR due to this:

1. OBSERVATION Entries characterising the patient initial presenting situation and everything else relevant (shock, breathing, consciousness, bp etc). Every measurement made and committed to th EHR would be an OBSERVATION of the patient.

[you might at this point say: why isn;t the burn itself (e.g. "child threw petrol on bonfire and split some on self, experienced 30 seconds of petrol burning on chest, abdoment") being described in the record - it is important? I agree - and there would be nothign to stop this, as long as the information is known. But it might not be, the patient might be unconscious, and be the only one who knows what happened, so I haven't included it here]

2. OBSERVATION Entries indicating the actions that were taken to stabilise the patient, e.g. adrenalin injections, topical treatments etc

3. EVALUATION entries indicating how the situation is characterised, now that it is understood better, and proposing a care plan for it

4. INSTRUCTION Entries indicating specific actions to be taken for the future care of the patient

5. OBSERVATION Entries indicating ongoing progress, execution of actions in 4. and so on

etc

The "Service-Action" view of the world portrays the
burn_event as an attribute (observation) of the emergency care act.

actually - this is the HL7 view of the world, not the openEHR one. In openEHR, the patient situation is recorded as an observation, since it is by observation (including interviewing the patient) that this data is obtained. Similarly, if someone can come in and describe the orginal accident (e.g. the child's brother), then this could go in as observations as well.

It should be noted that we use the word "observation" to mean "any information coming to the person recording in the record". So everything that happens in the world is a kind of observation, in that, in order to record it, one must receive data about it. Even doing an appendectomy is like this - you record what you observe.

Surely
a more appropriate approach should be to consider the emergency care act
as a consequence of the burn event. This would also allow for subsequent
trauma counselling to be related to the same event, rather than to the
ICU burns treatment _action_specification_. Consequently, I believe that
openEHR should include an _event_ archetype.

I don't see any problem with this at all - I would only say - don't take the Reference Model classes as being the only way to see things. I would encourage everyone to think in terms of the clinical & real world concepts they want, and think about how to build archetypes for them.

A similar argument can be mounted for representing risks in their own
right, rather than mere observations. Unfortunately, today's risks are often
tomorrow's virtues and vice versa. Yet, given today's medical knowledge,
the _observation_ "Person X smokes 50 cigarettes per day" carries
significant value beyond the care event for which the observation is
being recorded. Consequently, I believe there are good grounds for
establishing a _risk_ archetype.

Again i would agree with this. The risk-archetype would in fact assume EVALUATION Entries describing the risk associated with OBSERVATIONs such as the smoking one you mention.

Hope this helps.

- thomas beale