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.
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)
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.
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.
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”.
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...
The thing is that this reminds me to the CDA narrative part, which is
the only "required" part. If I remember correctly, the only part that
can be assumed right is the narrative. But as openEHR gives a lot of
weight to the structured part, then it could be other way around.
And by the way, I also agree that "none" is a correct answer
A slightly different angle from Thomas’ response, from my implementation experience in similar situations:
There are two clear “base cases”:
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.
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
However, unless we develop some new formal relationship between the text and the structured part for orders and prescriptions - something which to do properly I think is probably a PhD thesis level of work - then for now we have to accept this bit of 'duplication' and understand it for what it is. A lot of work has been done in the UK in this area, and it may be that there is an answer already available - if anyone has information on it, would be useful to share.
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.
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 , 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
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.
Looking in the openEHR CKM there are several instruction archetypes that don’t require an ACTIVITY occurrence (0..1 or 0..*) including Medication order and Non-drug therapy. Therefore you can have a Medication order with only a narrative and no structured data.
It seems I have to add support for rules on EHRGen to define mappings between structured data and narrative text for INSTRUCTIONS.
That way, if there’s no structured INSTRUCTION or there are no mapping rules, the narrative will appear on screen to let the user input free text, else if there’s some structure (like the referral case) and there are mapping rules, the narrative should not appear on screen, and when the user input data on the structure, the mapping rules will be executed to get the narrative text.
Thinking of implementation: when there are mapping rules, at least one data point from the structure should be mandatory, so narrative is not empty, but there’s no guarantee that the archetype defines that constraint, maybe we need to set that constraint in templates or just leave that to apps as an extra verification.
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.
