Instruction archetypes and overlaping nodes with INSTRUCTION.narrative

pablo pazos pazospablo at hotmail.com
Wed Oct 30 01:07:42 EDT 2013


Hi Colin, that's what I meant with my second paragraph (That way, if there's no structured INSTRUCTION or there are no mapping rules...), i.e. define conditions under the software knows to show or hide the narrative part for data input.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: Colin.Sutton at ctc.usyd.edu.au
To: openehr-clinical at lists.openehr.org
Subject: RE: Instruction archetypes and overlaping nodes with	INSTRUCTION.narrative
Date: Wed, 30 Oct 2013 04:58:02 +0000









You might want the narrative to appear for data entry if there is no suitable structure for the user’s case, or for others to code from it.
It should not appear there by default or the user might not bother trying to enter the structured data.
 
Regards,
Colin
 


From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org]
On Behalf Of pablo pazos

Sent: Wednesday, 30 October 2013 3:04 PM

To: openeh technical; openEHR Clinical

Subject: RE: Instruction archetypes and overlaping nodes with INSTRUCTION.narrative


 

Thanks Ian & Thomas,

 


It seems I have to add support for rules on EHRGen to define mappings between structured data and narrative text for INSTRUCTIONS.


 


That way, if there's no structured INSTRUCTION or there are no mapping rules, the narrative will appear on screen to let the user input free text, else if there's some structure (like the
 referral case) and there are mapping rules, the narrative should not appear on screen, and when the user input data on the structure, the mapping rules will be executed to get the narrative text.


 


Thinking of implementation: when there are mapping rules, at least one data point from the structure should be mandatory, so narrative is not empty, but there's no guarantee that the archetype
 defines that constraint, maybe we need to set that constraint in templates or just leave that to apps as an extra verification.


 


What do you think? Does this make sense?



-- 

Kind regards,

Eng. Pablo Pazos Gutiérrez

http://cabolabs.com




Date: Tue, 29 Oct 2013 10:01:59 +0000

From: thomas.beale at oceaninformatics.com

To: openehr-technical at lists.openehr.org

Subject: Re: Instruction archetypes and overlaping nodes with INSTRUCTION.narrative



Just to re-iterate, the 'narrative' property is meant to carry the piece of text that would appear on a medication or with a medication as supplied by a pharmacy (including in a hospital). When the administering agent is a human - the patient, family member
 or a nurse - this is normally the concrete direction that is followed. 



The computable form of the order / instruction says the same thing, but in a computable form, allowing structured querying, analysis, all the usual stuff.



This is probably the only place where there is content duplication in openEHR, and as far as I can see, it needs to be like that, since there is no standard way to generate the narrative text in its correct form from the computable form (i.e. the Activities
 etc) - particularly since the text form can contain quite particular words, 'codes' (like '3td po') and so on.




If a 'standard' algorithm could be developed for this purpose it would obviate the need for the narrative property, but I suspect this is a long way off due to the medically & culturally specific content typical in the narrative today.



- thomas





On 29/10/2013 08:36, Ian McNicoll wrote:


Hi Pablo,
 
My understanding is that the purpose of the INSTRUCTION.narrative
attribute is to carry a single 'human-friendly' version of what might
be a very complex structured set of activities. The best example would
be a complex medication order compromising multiple activities, each
with a number of structured content. The idea of the 'narrative'
attribute is that the key clinical content IS replicated for human
consumption. In the work we are currently doing in the UK on
medication orders we are concatenating the structured Medication name,
dose and frequency to populate the narrative attribute. This makes
good clinical sense for safety reasons, particularly when complex
timings are involved but
for a simple referral this is probably a bit over the top.
 
I would just replicate the content of  the 'Reason for request' in the
narrative attribute, unless you know that critical information will be
carried in the Reason description, in which case I would concatenate
the Reason + Description.
 
Ian
 
On 29 October 2013 02:50, pablo pazos <pazospablo at hotmail.com> wrote:

Hi, I'm reviewing archetypes for a project. Looking at referral request
archetype on the CKM, there are some nodes (Reason for request & Reason
description) that seems to match the semantics of INSTRUCTION.narrative
property.
 
Using that archetype to generate the UI in EHRGen, the overlaping was clear
(I though if a doctor records the reason, he/she will have no information to
record on narrative). The problem is that narrative is mandatory on the IM,
and I doubt what to do in cases like this one.
 
See the generated UI here: http://tinypic.com/r/ml5og5/5
 
 
Is there a real overlaping from the clinical point of view?
 
If an archetype has nodes that represents the same semantics as narrative
instruction, is there a need to record narrative anyway? (Even though the
narrative is mandatory by the IM)
 
Thanks!
 
--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com
 
_______________________________________________
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

 

 

-- 







Thomas Beale

Chief Technology Officer


+44 7792 403 613 


Specification Program,
openEHR 

Honorary Research Fellow, UCL


Chartered IT Professional Fellow, 
BCS 

Health IT blog








 



_______________________________________________ openEHR-technical mailing list 
openEHR-technical at lists.openehr.org 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org








Scanned by MailMarshal - 
M86 Security's comprehensive email content security solution. Download a free 
evaluation of MailMarshal at www.m86security.com







_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20131030/6a62a10f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4085 bytes
Desc: not available
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20131030/6a62a10f/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 511 bytes
Desc: not available
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20131030/6a62a10f/attachment.png>


More information about the openEHR-clinical mailing list