Over the years I've seen a number of different patterns for collecting information in health information systems and communicating it in CDA documents. Today's posting discusses some of the common patterns I've encountered. Note that in this posting, I'm providing very abbreviated examples of what would appear in the CDA document that are not valid without other details unnecessary for this discussion:
Checkbox Design Pattern
One of the common patterns that often needs to be represented is the checkbox pattern used in some products for review of systems, physical examination findings, or past medical history. Often in these history taking, reviews or examinations there are specific lists of symptoms or conditions that are being checked for.
When a box is checked these typically result in an observation of the following form:
‹observation classcode="OBS" moodcode="EVN" negationind="false"›
‹code code="finding" .../›
‹effectivetime value="201002031714"›
‹value xsi:type="CD" code="Crackles" ...›
‹/observation›
When the box is not checked, these typically result in an observation of the following form:
‹observation classcode="OBS" moodcode="EVN" negationind="true"›
‹code code="finding" .../›
‹effectivetime value="201002031714"›
‹value xsi:type="CD" code="Crackles" ...›
‹/observation›
Radiobutton Design Pattern
The Radio button design pattern asks a question about each symptom or finding, and offers one or more choices about its value.
‹observation classcode="OBS" moodcode="EVN" negationind="true"›
‹code code="QuestionCode" ... /›
‹effectivetime value="201002031714"›
‹value xsi:type="??" value="..." ›
‹/observation›
One of the struggles with this design pattern is that codes for questions aren't the same as codes for findings or diagnoses. The question is "Diabetes Status", the answers are yes/no/unknown or some variation thereof, but the diagnosis is "Diabetes" which is a different code.
For a yes/no/unknown value set for the answer, you can use the BL data type, with values of true or false to indicate yes or no, or a nullFlavor to indicate unknown. This leads us the the next design pattern.
Yes/No/Unknown Radiobutton Design Pattern
When the radio button design pattern is used with the answers yes/no/unknown, there's a tendency to model this using the checkbox design pattern. The yes/no part can follow the exact same pattern as checkbox design pattern. However, to say "unknown" is a little more challenging because most vocabularies don't routinely support "unknown X status" for all symptoms and findings. When they do, the other challenge is that you have to have knowledge of the relationships between these two different codes.
So then people try to model it using the Radiobox Design Pattern, but find that the codes for the diagnosis and the question about the diagnosis status are different. This makes it difficult to compute against the diagnosis codes without understanding the relationships between them and the diagnosis status codes. Also, there's a dearth of "diagnosis status" codes in most vocabularies.
There is a way to model this pattern in the value element using SNOMED CT and post-coordination:
‹value xsi:type="CD" code="413350009" displayname="finding with explicit context" ...›
‹qualifier›
‹name code="408729009" displayname="finding context" ...›
‹value code="261665006" displayname="unknown" ...›
‹/qualifier›
‹qualifier›
‹name code="246090004" displayname="associated finding" ...›
‹value code="286661006" displayname="Fever" ...›
‹/qualifier›
‹/value›
This basically says there is a finding: "Fever" that has the context "unknown". Other possible context values are "possibly present", "known present", "known absent", "confirmed", et cetera.
This means that the SNOMED post coordinated pattern can be used in a regular fashion to represent the Yes/No/Unknown Radio Button Design pattern. It's yet another model layered on top of the RIM, with the associated complexity, but also has the benefit that this particular CDA design pattern can easily be used to represent all the variations on a theme for yes/no/unknown.
Thanks to Sondra Renly who asked the question that got me looking down this path.
I'll be collecting more design patterns for CDA as the year goes on. Send your favorites to me here.
I'm not sure that the last snomed example is legal. The definition for qualifier says: "qualifiers cannot negate the meaning of the primary code". I don't know whether snomed is sufficiently well defined to be confident that a finding with explicit context, where the context is unknown, means that the finding is unknown, whether this is not a negation of the finding. So I query that this is safe?
ReplyDeleteBut thank you for raising this issue. It's an important one, and we should have clear guidelines to get consistency here.
The primary code in this context is: 413350009 finding with explicit context. The finding context for that code is "unknown" and the associated finding that has that context is "Fever"
ReplyDeleteSee for example: 407559004 family history unknown and 160266009 no family history of in SNOMED which follow this same pattern (and is how I determined the pattern in the first place).
Lloyd McKenzie reports:
ReplyDeleteIn newer RIMs, there's a non-structural attribute called valueNegationInd that can be true, false or a flavor of null. That will help for CDA R3, but isn't available in CDA R2.
If you don't use SNOMED, there are a couple of options:
- You can specify an uncertaintyCode about the overall observation which gets close to the semantic, but not quite. "I'm not sure whether there was an observation of fever last Tuesday".
- You can make an observation about your observation indicating that you're unsure
To which I say: YEAH for the new RIM attribute!