Instruction archetypes and overlaping nodes with INSTRUCTION.narrative
Indeed, I would say we (technologists) need to work alongside with local clinical leaders, safety review processes and constant audits focused on data flows, processing and use, not only as discussions previous implementation, but we must work together continuously throughout the project, improving the process while implementing it. Technology and rules are good (and feasible) at a certain point, after that, we need human intelligence (from domain experts) to help us out, e.g. to extract information from data, to set the right codes, to structure free text, to link together fragmented pieces of information, etc. Of course this goes far away from my original question, but is always good to exchange opinions. My question was focused on knowing a very basic set of rules of how to interpret and handle possible semantic overlaping between nodes inside the same archetype. Those rules are something that can be implemented easily in an application, but the rules of how to derive structured/coded information from free text are in other league (for people smarter than me and/or multidiscipinary teams). -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: ann.wright...@wales.nhs.uk To: openehr-technical at lists.openehr.org Date: Thu, 31 Oct 2013 10:30:00 + Subject: RE: Instruction archetypes and overlaping nodes with INSTRUCTION.narrative 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:openehr-technical-bounces at lists.openehr.org] 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 From: Ann.Wrightson at wales.nhs.uk To: openehr-technical at lists.openehr.org Date: Tue, 29 Oct 2013 12:08:10 + 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
Instruction archetypes and overlaping nodes with INSTRUCTION.narrative
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*EHRhttp://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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131029/e4ac441e/attachment.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/e4ac441e/attachment.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/e4ac441e/attachment.png
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131029/6f406ce1/attachment.html
Instruction archetypes and overlaping nodes with INSTRUCTION.narrative
A good question. My opinion is that it will be around for a long time. As NLM becomes more in use, there seems to be a tendency to believe that narrative will be around for a long time. I think what you propose will be an interesting discussion. The problem with narrative is that its contents, organization, completeness, and use of non-standard abbreviations is totally uncontrolled. From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Thomas Beale Sent: Tuesday, October 29, 2013 1:29 PM To: openehr-technical at lists.openehr.org Subject: Re: Instruction archetypes and overlaping nodes with INSTRUCTION.narrative On 29/10/2013 16:28, Dr Ed Hammond, Ph.D. wrote: As a point of interest, the required narrative section in CCD was an interim step because we (US) still have a number of sites that cannot accommodate structured data. In my opinion it does not imply correctness. Ed, I suggested some rules in my blog post for deal with this very ubiquitous reality... I wonder if you have any feel for whether the text/structured 'equivalence' idea will remain in a future CDA - going by Grahame's bloghttp://www.healthintersections.com.au/?p=1699, it appears CDA will turn into FHIR, i.e. a completely different format? If it is retained, there is an opportunity to establish better rules for this. I can imagine upgrading openEHR to use such rules as well. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131029/db06b574/attachment.html
