Hi Diego, I would expect the narrative to be constructed from the 'clinically significant' elements of the archetype to generate a clinically safe narrative expression of the structured content. In that sense the narrative' is the fall-back expression of the Instruction for humans and therefore should be seen as the one that is supposed to be 'right'. Since I would expect it to be constructed from elements in the archetype it should never be at variance with the structured content but will usually be a subset of that content. Ultimately it must be a clinical decision as to which of the structured element values to include in the narrative to make this clinically safe. The bottom line should be "if all I have to work with is the narrative, is that going to be safe".
On 29 October 2013 10:07, Diego Bosc? <yampeku at gmail.com> wrote: > And if an inconsistency is detected, which one is supposed to be right? > > > 2013/10/29 Thomas Beale <thomas.beale at oceaninformatics.com> > >> >> 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> >> <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?rrezhttp://cabolabs.com >> >> _______________________________________________ >> openEHR-technical mailing listopenEHR-technical at >> lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> -- >> [image: 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/> [image: >> View Thomas Beale's profile on LinkedIn] >> <http://uk.linkedin.com/in/thomasbeale> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131029/fe24e0c8/attachment-0001.html> -------------- 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/fe24e0c8/attachment-0001.png> -------------- 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/fe24e0c8/attachment-0001.jpg>
