Not much to say today...

If a picture paints a thousand words, then this picture has about an 86:1 compression ratio.

It may not be done, but it sure is close.  Feature freeze has been declared.  There shall be no new content without an appropriate ECO.  Now I throw it over the wall to QA ;-)

   Keith

An analogy for Viewpoints

I was trying to explain something in the CDA Book, and in so doing came up with an analogy that may help explain the use of viewpoints in SAIF and RM-ODP.

There have been many times in my engineering career where someone would give me requirements for an object in a system.  After listening to the requirements, I would start breaking them down into the classes that the system would use.  Time and time again I would run into situations where the class I had created could be simply extended to support some new behavior in order to meet other requirements.  This is pretty normal in engineering.

Then I would go explain what I did, and the person who gave me the requirements would say "No, that has to be wrong, because Y is not the same as X".
"But,"  I would argue, "except for these extension points, they work exactly the same way."

And then we would sit down and look at it.  And lo and behold, we would see that we were looking at the same thing from two different viewpoints.  I was looking at it from an engineering viewpoint, trying to understand how it worked, and the other person was thinking about it from a business viewpoint, how it was used and managed. it would turn out that we were both right.

Let's take another example.  To an auto-mechanic, a cam-shaft, a transmission, an a differential are all different things.  But they are all made up of gears, and to a mechanical engineer, these could just be viewed as different kinds of gear-cases (I do realize I'm drastically simplifying this, but you should get the idea).

I used a shift in viewpoint to explain the acts in the HL7 CDA clinical statement model in the book, so that I could build from students knowledge of simpler things.  A substanceAdministration is like a procedure, for example, save that it has these extra things.  Given that they already understand the procedure class, I no longer have to explain all of the details of the substanceAdministration class again.  I can expect the student to make the viewpoint shift to the clinical aspects of medication administration independently from the data transmission aspects.

I wound up not using this analogy in the book, but only because I couldn't make it fit with what I had already written.  It's still an interesting analogy.

A proposal for HL7 XML Extensibility

I'm in the process of finishing the CDA Book, and was writing the chapter on extensions.  As I was writing it, the following idea came up.

The HL7 XML Implementation Technology Specification, or ITS, defines how HL7 message elements are to be sent using XML.  Section 2.5 of the XML ITS: XML Structures (Release 1) specification allows for the include of extension elements.  The only real requirement is that they come from a namespace other than urn:hl7-org:v3.

As part of the best practices for CDA templates created by the Structured Documents Workgroup, we determined that:

1. All CDA extensions should be RIM derived, and
2. They should be placed where they would have been placed had the CDA standard included that RIM attribute.

This is a nice idea, but has some  unfortunate consequences when validating CDA content that contains extensions.  Each possible extension can appear in a different place in the CDA schema, and it becomes nearly impossible to modify the CDA schema to support validation of  CDA containing extensions. 

I propose a new rule:  All extension elements must appear after all content defined by the standard. This rule has a great benefit.  Take a look at the following revised definition for POCD_MT000040.ObservationRange for CDA Release 2:

‹xs:complexType name="POCD_MT000040.ObservationRange"›

  ‹xs:sequence›

    ‹xs:element name="realmCode" type="CS" minOccurs="0" maxOccurs="unbounded"/›

    ‹xs:element name="typeId" type="POCD_MT000040.InfrastructureRoot.typeId"

                minOccurs="0"/›

    ‹xs:element name="templateId" type="II" minOccurs="0" maxOccurs="unbounded"/›

    ‹xs:element name="code" type="CD" minOccurs="0"/›

    ‹xs:element name="text" type="ED" minOccurs="0"/›

    ‹xs:element name="value" type="ANY" minOccurs="0"/›

    ‹xs:element name="interpretationCode" type="CE" minOccurs="0"/›

    ‹xs:any namespace="##other" processContents="skip"

  minOccurs="0" maxOccurs="unbounded"›

  ‹/xs:sequence›

  ‹xs:attribute name="nullFlavor" type="NullFlavor" use="optional"/›

  ‹xs:attribute name="classCode" type="ActClassObservation" 

    use="optional" default="OBS"/›

  ‹xs:attribute name="moodCode" type="ActMood" use="optional" fixed="EVN.CRT"/›

  ‹xs:anyAttribute namespace="##other"/›

‹/xs:complexType›

This schema supports extension following that rule, and furthermore, the HL7 tooling can be modified to easily add these statements to any existing schema.  Thus, we can, with the addition of this rule, have our XML extensions, and validate the message too.

A Change of Mood

I get a little tired of my complaining on Monday and Tuesday and so today's post is about the topic of mood in HL7 Version 3.  The HL7 moodCode attribute is one of those topics that always seems to confuse people because the name doesn't seem to make any sense.  And it's true, it doesn't until you understand which definition of mood you need to work with.  This is the definition you want to work with.

mood (plural moods)

1. (grammar) A verb form that depends on how its containing clause relates to the speaker’s or writer’s wish, intent, or assertion about reality.

Now, in a former life I used to write linguistic software.  I helped develop applications for spelling correction, grammar and thesaurus applications that are still in use today in Microsoft Word, among others.  So I should know a little something about mood.  But while that life led to this one, I found that I needed a refresher on the topic. A more detailed explanation of mood as used in linguistics can be found on wikipedia.

Since just about every clinical statement (sentence) you can make in HL7 version 3 starts with a verb (an Act), you have to have different ways to inflect these verbs.  Inflection changes mood and tense, and that's what moodCode is all about.  And just as in linguistics, where mood and tense are conflated, they are also conflated in HL7 Version 3.

Their are something like 18 moods defined in the HL7 moodCode vocabulary (there were only 14 when CDA Release 2 was created).  Moods fall into two main categories:  The Act completion track represents transitions from definition (e.g., a clinical guideline for care), to intent (a plan of care), to event (a sequence of care events that have taken place).  The predicate track deals with more nebulous moods.

So, looking at a few mood codes, what would be the appropriate linguistic mood to associate with each one? Here are my best guesses.

Event (EVN) - The actual occurence of an event. Indicative.
Request or Order (RQO) - A request or order to perform an act [in the future]. Precative or Imperative.

Definition (DEF) - a definition of an act that can occur. Deontic
Intent (INT) - The intent for an act to occur [in the future]. [Future tense]
Proposal (PRP) - A proposal to perform an act [in the future].
Promise (PRMS) - The promise to perform an act [in the future]. Commissive


Event Criteria (EVN.CRT) - An event that must occur or criteria that must be applicable before another event can happen. Conditional  [but  note that HL7 the inflection occurs on the verb in the protasis, so perhaps it is Subjective]
Expectation (EXPEC) - The expectation that something may occur in the future. Potential seems to be the best choice.
Goal (GOL) - The hope, expectation or desire that something does occur in the future. Optative
Risk (RSK) - The hope, expectation or desire that something DOES NOT occur in the future.  Optative 

I'm glad HL7 chose to use something humans can understand in the vocabulary for moodCode, because this little experiment just proved that I've forgotten a ton about mood, and never learned quite a bit more.

Of course, just when you thought you understood it all, things change.  It turns out the criteria moods are defective, and so the CRT and EVN.CRT mood code was recently deprecated.  I'll save the discussion of that for another post.

I had thought this would be book fodder if I had been able to understand it better. [Pluperfect subjunctive?].

CDA Design Patterns

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.