Hi Pablo - Yes, all this can be relevant, however...
My main point was to include the key role of local clinical leads and safety review processes within a particular implementation programme. In the present state of the art (aka until we have a mature evidence-based methodology available to support locally specific implementation decisions rather than relying on theory or opinion) there's a need for technologists (who tend to like rules, the more "sophisticated" the better...) to exercise self-discipline & regard abstract rules as only a starting point for pragmatic discussion in a particular context. Trade-offs between various ways to use narrative (as discussed earlier in this thread) with other functions such as search & analysis would form part of such a pragmatic discussion. 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:[email protected]] On Behalf Of pablo pazos Sent: 30 October 2013 04:28 To: openeh technical Subject: RE: Instruction archetypes and overlaping nodes with INSTRUCTION.narrative Warning this message contains links that it has not been possible to verify as safe. You should only click on the links if you are sure they are from a trusted source. Hi Ann, the case 2 is easy to implement on software with some rules. For case 1 I've seen implementations that use smart terminology services to help doctors to codify their free text when recording information or NLP techniques that process the free text and try to set codes to it's parts (mostly academical work), or more practical second level coding: having a bunch of clinical coders (mainly students of medicine) that read each free text and associate SNOMED-CT or other kinds of fine-grained codes that are classified and grouped by other coarse grained terminologies like ICD-10 or CIAP-2, and then DRG. Assigning codes can be seen as giving structure to free text data, but is not the same: free text data could have an implicit structured model that is not reflected by codes/terminologies/dictionaries... But at the end, the effect is similar: have processable data. The problem with codes is that they don't show the hierarchy that exists in the data, but codes help to show the implicit hierarchy as a plain structure that is easy to map/store in relational databases and be queried using common SQL. The problem comes when you need to query the structure itself, i.e. get some data if a structure defined by archetype A contains other structure defined by archetype B with some data > x. On this case, you need to have the hierarchy, some storage that can store that hierarchy and a query language that support those kinds of queries, like AQL. -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com<http://cabolabs.com/es/home> ________________________________ From: [email protected] To: openehr-technical at lists.openehr.org Date: Tue, 29 Oct 2013 12:08:10 +0000 Subject: RE: Instruction archetypes and overlaping nodes with INSTRUCTION.narrative 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:[email protected]] 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<mailto: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 --- 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. --- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131031/df96cf35/attachment-0001.html>
