# Action specifications

**URL:** <https://discourse.openehr.org/t/action-specifications/15690>\
**Category:** Technical (archive)\
**Created:** [1 December 2002 01:24 UTC](https://discourse.openehr.org/t/action-specifications/15690 "2002-12-01T01:24:16Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sam](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@Sam](https://discourse.openehr.org/u/Sam)\
**Post date:** [1 December 2002 01:24 UTC](https://discourse.openehr.org/t/action-specifications/15690/1 "2002-12-01T01:24:16Z")

</div>

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:

&nbsp;&nbsp;A medication order is an instruction:

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

&nbsp;&nbsp;The action specification is:

&nbsp;&nbsp;&nbsp;&nbsp;medication=Amoxycillin: dose=250mg: route=IV

&nbsp;&nbsp;The when part is:

&nbsp;&nbsp;&nbsp;&nbsp;frequency=three times daily

OR A Pap test notification instruction might consist of:

&nbsp;&nbsp;&nbsp;&nbsp;Action is Pap Test & send specimen to laboratory  
&nbsp;&nbsp;&nbsp;&nbsp;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

---

<div class="post-metadata">

**Author:** ![Ahmad\_Risk](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@Ahmad\_Risk](https://discourse.openehr.org/u/Ahmad_Risk)\
**Post date:** [1 December 2002 12:28 UTC](https://discourse.openehr.org/t/action-specifications/15690/2 "2002-12-01T12:28:40Z")

</div>

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:
> 
> &nbsp;&nbsp;medication=Amoxycillin: dose=250mg: route=IV:  
> frequency=three times daily
> 
> The action specification is:
> 
> &nbsp;&nbsp;medication=Amoxycillin: dose=250mg: route=IV
> 
> The when part is:
> 
> &nbsp;&nbsp;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

---

<div class="post-metadata">

**Author:** ![Karsten\_Hilbert](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/k/e56c9b/32.png) [@Karsten\_Hilbert](https://discourse.openehr.org/u/Karsten_Hilbert)\
**Post date:** [1 December 2002 12:50 UTC](https://discourse.openehr.org/t/action-specifications/15690/3 "2002-12-01T12:50:02Z")

</div>

> > 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

---

<div class="post-metadata">

**Author:** ![Ahmad\_Risk](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@Ahmad\_Risk](https://discourse.openehr.org/u/Ahmad_Risk)\
**Post date:** [1 December 2002 16:27 UTC](https://discourse.openehr.org/t/action-specifications/15690/4 "2002-12-01T16:27:18Z")

</div>

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 🙂

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

Ahmad Risk

---

<div class="post-metadata">

**Author:** ![Karsten\_Hilbert](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/k/e56c9b/32.png) [@Karsten\_Hilbert](https://discourse.openehr.org/u/Karsten_Hilbert)\
**Post date:** [1 December 2002 19:34 UTC](https://discourse.openehr.org/t/action-specifications/15690/5 "2002-12-01T19:34:24Z")

</div>

> \>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 🙂

I know. It was rather meant as a cautionary comment 🙂

> 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

---

<div class="post-metadata">

**Author:** ![Karsten\_Hilbert](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/k/e56c9b/32.png) [@Karsten\_Hilbert](https://discourse.openehr.org/u/Karsten_Hilbert)\
**Post date:** [1 December 2002 20:30 UTC](https://discourse.openehr.org/t/action-specifications/15690/6 "2002-12-01T20:30:29Z")

</div>

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

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;^^^^^^^^^^^^^  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Wise Old Guys  
of course, pardon me 🙂

Karsten

---

<div class="post-metadata">

**Author:** ![Sam](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@Sam](https://discourse.openehr.org/u/Sam)\
**Post date:** [4 December 2002 02:47 UTC](https://discourse.openehr.org/t/action-specifications/15690/7 "2002-12-04T02:47:26Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Eric\_Browne1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/e/8dc957/32.png) [@Eric\_Browne1](https://discourse.openehr.org/u/Eric_Browne1)\
**Post date:** [4 December 2002 05:38 UTC](https://discourse.openehr.org/t/action-specifications/15690/8 "2002-12-04T05:38:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [4 December 2002 09:40 UTC](https://discourse.openehr.org/t/action-specifications/15690/9 "2002-12-04T09:40:10Z")

</div>

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"  
> &nbsp;&nbsp;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  
> &nbsp;&nbsp;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