CDA: What information from the Entries has to go in the narrative?
Mar 27, 2014Most CDA implementation guides, and many tutorials - including some of both I wrote myself - say something like this:
it is an absolute requirement of all CDA documents that the section narrative text completely captureallthe information represented in the structured elements within the section
(emphasis added) This example is from Brian’s article I linked to in my previous post, but the same language exists all over the place.
Only, it’s not true. What it should say is, “the section narrative must capture all the clinically relevant information represented in the structured elements within the section”. Which raises the obvious question, ‘well, what’s clinically relevant’?
For comparison, this is the definition of the underlying field that includes the words:
Act.text SHOULD NOT be used for the sharing of computable information
That shouldn’t be understood to mean that you can’t put information that is computable in Act.text, but that it’s meant for human consumption, and you put in there what’s relevant for a human.
What is “Clinically Relevant”?
The rest of this post gives a set of suggestions about what is clinically relevant in the entries. But it’s really important to understand that this is all just suggestions. The decision has to be made by some clinically aware person who knows what the data means - don’t let programmers do it (and I see a lot of documents where the programmers have done it, and what they did doesn’t make sense to a clinician).
First, I’ll look at the entries, and then I’ll make comments about data type rendering below that.
Entry - nothing to display in the narrative
Entry Acts (Observation , etc) - each act should be shown in the narrative, except for RegionOfInterest which is purely technical, and ObservationMedia which is shown via a
classCode , moodCode, statusCode - these are critical to be in the narrative - but very often, they are implicit. For example, if the Section title is “Past Procedures”, and all the entries are procedures with moodCode = EVN, then there’s nothing to say in the narrative (and don’t, if you don’t have to, otherwise it’s just noise for already overwhelmed users). But if the section title is “procedures, past and planned”, then you’ll need to show the mood code for each procedure - and don’t just show the code for the moodCode - give it a meaningful human readable word (e.g. done or planned in this case)
effectiveTime - This is generally necessary to display. It’s rare that the timing of some event simply doesn’t matter - except for future activities that are known not to have happened (the effective time then is the time of booking, and whether to show this is a clinical decision based on the context of use)
id - generally I would recommend not showing these. But it’s a matter of clinical judgement when identifiers are likely to matter to someone reading the document (when they have to get on the phone and say, look, about diagnostic report XXXX, can you…)
code - generally, this needs to be shown
negationInd - this always needs to be shown if it’s negative. The only exception I could think of is if every entry in the section is negated, and the section title says “failed Medication Administrations” or something like that
text - any time an entry has text, I’d very much expect that the text would be in the narrative - but it might not be quite the same. For instance, the text might be generated using a variation of the method by which the whole narrative was generated, so the information would be similar, but laid out differently. Alternatively, the text could be additional independent information from everything else, and then would be found verbatim in the narrative.
Other entry attributes - well, there’s just too many to list here, and beyond the common elements above, there’s not much simple common guidance I can write. Some things like Observation.value, and SubstanceAdministration.dosage are obvious things to put in the narrative, and other things like Act.priority code are unlikely to be in the narrative unless the act is yet future. Most other things lie somewhere between this. Clinical judgement is always required.
Participations
- Author: probably not worth showing
- Informant: probably not worth showing? (Wouldn’t it be nice to know that there would always be a way to “unpeel the onion” when it is appropriate)
- Subject: Always must be shown if it’s different to the section subject, but this is extremely rare. (which reminds me - if the section subject differs to the document subject, that absolutely must be shown in the section narrative)
- Performer: usually worth showing (as a single piece of text, the name of the person, or the org if there’s no person)
- Consumable/Product: Show the name and/or code of the DrugOrOtherMaterial
- Specimen: really, I’m not sure. If it’s a diagnostic report, it’s not usually shown in the narrative (or if it is, it’s in the title or implied in the test code). I haven’t seen specimen in other contexts
- Participant: it depends on what type of participant and why. Sometimes, this is audit trail type stuff, and you shouldn’t show it. Other times, it’s critical information
ActRelationships
- Reference - should be shown as a linkHtml if possible.
- Precondition - don’t know.
- ReferenceRange - usually shown, but the labs know what they want or have to do
- Component (on organizer) - should always be shown
EntryRelationships
What to do with Entry Relationships all depends on what they say. These could be:
- Entries in the narrative table in their own right (sometimes in place of the thing that contains them)
- nested tables in the main table
- a single line of text in the main table
- ignored and not shown in the narrative
It’s a clinical judgement call. If you do show an entry relationship, pay attention to these elements:
- typeCode / inversionInd - The meaning of the typeCode and inversionInd needs to be conveyed somehow. Very often, this is obvious in the context, and showing it is just noise. But sometimes it matters
- sequenceNumber - any time this is present, it probably needs to be in the narrative
- negationInd - see above
Data Type Guidance
- nullFlavor: if the data type has a nullFlavor, then show some abbreviation for the nullFlavor. I use “–” for NI, n/a for NA, unk for UNK, or the code (the first three are the common ones). If the data type has additional properties as well as a nullFlavor, then generally these would be type /scope information, and something smart is required - e.g. <tel nullFalvor=”UNK” use=”H” value=”tel:’/> should be shown as “Home phone number: unk”.
- BL / INT / REAL / ST: just show the value directly
- ED: These shouldn’t be rendered directly. You should use a linkHtml or renderMultimedia to refer to this indirectly
- CD/CE/CV: if you have original text, then show that. If not, it’ll have to be a display. In a few circumstances, where humans use the codes directly (billing codes!) it’s worth showing the codes directly
- CS: if you have to show a CS, you should know why, and you should have a representation table that translates the code to something good for a human
- II: if you have to show one of these (try and avoid it), and it has an extension, show the extension. if it’s just a UUID - don’t show it. Humans hate UUIDS. Just like OIDs
- TEL: I use at template like this [use] [type] details, where use is a lookup from the use code, if there is one, type is phone or fax depending on the scheme in the value, and details is the rest of the value. if it’s a web url, I’ll drop the [type] and show the value is a linkHtml. But that doesn’t always suit (host systems might not know what to do with a mailto: url in a linkHtml)
- EN: If you have to render this, use [use] [literal] where use is from the use code(s) and literal is the literal form defined in the abstract data types (the definition is obtuse, but the format is usually pretty good)
- AD: same as EN
- PQ: render as [value] [unit]. If you have a different human display unit to the UCUM unit, you can use that (or translate it to a human display. for instance, the UCUM unit uL, some people prefer µL and some mandate mcg)
- RTO: Use the literal form (though use human units if they available)
- TS: Depends on the culture. In Australia, we mandated dd-mmm-yyyy hh:nn:[ss][T] (no milliseconds). Other cultures will have their own rules
- IVL<>: I use the literal form
- GTS: good luck with this one… hopefully you have some system source text description as well as a GTS. I guess there’s always the literal form.