Hi Ann, I agree with your assessment in general, particularly that this really needs some kind of clinical judgement and discussion.
In the vast majority of cases (? all) I would expect any 'original' narrative to be carried inside the archetyped content and not at RM level, even in your case (1), so the narrative attribute would always be acting as a secondary 'derived' statement i.e we would always make sure that the archetype could natively handle a wholly-narrative instruction. Ian On 29 October 2013 12:08, Ann Wrightson (NWIS - Enterprise Architecture) <Ann.Wrightson at wales.nhs.uk> wrote: > A slightly different angle from Thomas? response, from my implementation > experience in similar situations: > > > > There are two clear ?base cases?: > > > > 1. If there is a comprehensive narrative entered by a human then that > is the narrative, i.e. any structured or coded data is regarded as > supplementary machine-readable content. > > 2. If there is structured data without a narrative, then as Ian > describes a human readable narrative is constructed from the data. > > > > In practice, I would expect a fair bit of discussion around these options > with the lead clinical users who assure and accept a particular solution (& > often a formal patient safety review too). As a result of such > discussion-in-context, a hybrid solution may be preferred where for example > the narrative as entered is shown first, followed by an algorithmic textual > rendering of key data items for patient safety such as medications. > > Regards, > > Ann W. > > Ann M Wrightson > Pensaer TG | Lead Technical Design Architect > Gwasanaeth Gwybodeg GIG Cymru | NHS Wales Informatics Service > Caernarfon: Ff?n/Tel: 01286 674226 Pencoed: WHTN: 01808 8940 > Ff?n/Tel: 01656 778940 > Symudol/Mobile: 07535 481797 > > > > From: openEHR-technical [mailto:openehr-technical-bounces at > lists.openehr.org] > On Behalf Of Thomas Beale > Sent: 29 October 2013 11:34 > To: openehr-technical at lists.openehr.org > Subject: Re: Instruction archetypes and overlaping nodes with > INSTRUCTION.narrative > > > > > I knew that question was coming ;-) > > Firstly, how would you detect an inconsistency? It can only be done by a > human being, or else a quite sophisticated piece of software. Now, what does > it mean if there is a difference? > > Firstly they are not quite 'duplicates'. The narrative is a directive to a > human agent to do something, in a slightly coded language that is supposed > to be understood unambiguously by the author and the reader. > > The structured representation is just that - a structure representing the > medication order activities, timing etc. > > If they don't say the same thing it could mean: > > the software that created the structural representation has an error, and > creates structures different from the clinical intention > the software that created the narrative has an error, and created a > different text from that required by the clinician > > As for any other data in the record, there is no 100% guarantee that any of > it is right. The correct comparison is not just between the two, but between > both of them and the original clinical intention, which is the reference. > This comparison will only be made during testing, where the purpose is to > ensure the software is bug-free. > > In routine use, inconsistencies probably won't be detected - the doctor will > just assume the software works properly. So it's just a question of making > sure the software works properly... > > - thomas > > > On 29/10/2013 10:07, Diego Bosc? 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 > > > > > > ________________________________ > > Mae?r wybodaeth a gynhwysir yn y neges e-bost hon ac yn unrhyw atodiadau?n > gyfrinachol. Os ydych yn ei derbyn ar gam, rhowch wybod i?r anfonwr a?i > dileu?n ddi-oed. Ni fwriedir i ddatgelu i unrhyw un heblaw am y derbynnydd, > boed yn anfwriadol neu fel arall, hepgor cyfrinachedd. Efallai bydd > Gwasanaeth Gwybodeg GIG Cymru (NWIS) yn monitro ac yn cofnodi pob neges > e-bost rhag firysau a defnydd amhriodol. Mae?n bosibl y bydd y neges e-bost > hon ac unrhyw atebion neu atodiadau dilynol yn ddarostyngedig i?r Ddeddf > Rhyddid Gwybodaeth. Mae?r farn a fynegir yn y neges e-bost hon yn perthyn > i?r anfonwr ac nid ydynt o reidrwydd yn perthyn i NWIS. > > > > The information included in this email and any attachments is confidential. > If received in error, please notify the sender and delete it immediately. > Disclosure to any party other than the addressee, whether unintentional or > otherwise, is not intended to waive confidentiality. The NHS Wales > Informatics Service (NWIS) may monitor and record all emails for viruses and > inappropriate use. This e-mail and any subsequent replies or attachments may > be subject to the Freedom of Information Act. The views expressed in this > email are those of the sender and not necessarily of NWIS. > > ________________________________ > > > _______________________________________________ > 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
