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 > > -- Ocean Informatics <http://www.oceaninformatics.com/> *Thomas Beale Chief Technology Officer* +44 7792 403 613 Specification Program, /open/EHR <http://www.openehr.org/> Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/> Health IT blog <http://wolandscat.net/category/health-informatics/> View Thomas Beale's profile on LinkedIn <http://uk.linkedin.com/in/thomasbeale> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131029/b432e31f/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 4085 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131029/b432e31f/attachment-0001.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: btn_liprofile_blue_80x15.png Type: image/png Size: 511 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131029/b432e31f/attachment-0001.png>
