Strange Dreams and Context Controls in HL7 CDA

One of the challenges of a job that requires a lot of thinking is that it's really hard to escape it sometimes.  Last night, just before I head off for a short trip to the cape, I was dreaming about context controls in CDA documents.


Did I just lose you?  Yeah, I was wondering about that myself.

The CDA Document enumerates a number of participations, and for many of these participations, fixes the contextControlCode value to "OP", a code that means Overriding and Propagating, as in the example below from the CDA R-MIM.

What the heck does this mean?

In RIM Speak, context controls describe how the participation applies to not just the act the author participation is attached to (the CDA Document), but also the acts descending downwards (in the direction of the arrows) from the act in which the participation is attached.

So, if you have a CDA Document, it can have sections (a descendant act), which can have entries (a descendant act), and those entries can reference other things (like reference ranges) and so on.  And if, at the top of the document (/ClinicalDocument/author), you say that the author is Alex, then that propagates through the act and all related acts (in the direction of the act relationship arrows) until that same type of participation is again encountered.  At that time, the new participant (Bobbie) overrides the existing one, and propagates downward as the author of all attached and decedent acts.

This behavior is crucial to the way that participations work in CDA, and fortunately, all essential participations work that way.  The way it is crucial is because you can, using XSLT  (yeah, I know, who the hell else do you that dreams in XSLT...) create an XPath expression that identifies the author (or recorder, or performer) of a particular event.

Say you are looking at an allergy in a CCDA Document.  Who's the author of this thing?  Basically, you look at the act (in this case the observation using the allergy template).  If that has an author, you stop there.  Otherwise you look to the act above it to see if it has an author, and so on, all the way to the top of the document (which is /ClinicalDocument), and which, is guaranteed (according to the CDA R-MIM and Schema) to contain at least one author.  Once you find an act that has at least ONE author, you then accumulate all authors as the author of the act.  Assuming your current context is an act that you want to find the author of, here's the XPath expression that identifies all authors of the current act.

ancestor-or-self::cda:*[cda:author][1]/cda:author

What does this say?

Component	Meaning
ancestor‑or‑self::	Starting with the current node and ascending to all of its ancestors in order through the root of the document.
cda:*	Find any element ... note, that while this expression will allow traversal through both act and act-relationship links, the next element will only ever be true on acts (because only acts can have author children).
[cda:author]	That contains an cda:author element
[1]	Stop after you find the first one
/cda:author	Collect ALL of the authors.

So, this will find the first act that specified an author, and collect all of the authors.  If you are trying to translate from CDA to FHIR, this is an essential tool you can use to find author, informant, subject, or other participant.

You cannot assume that just because Alex authored the document that he / she authored all acts within it.  You have to look.

One important adjustment to this.  The subject of every act is assumed to be the patient, unless subject is otherwise specified, but the patient participation is actually identified through the record target participation in CDA.  This is inference from semantics, rather than true semantics, but that's OK.  The way to adjust for that is to use the following to get to the "subject" of the act:

ancestor-or-self::cda:*[cda:subject|cda:recordTarget][1]/(cda:subject|cda:recordTarget)

You may have to fiddle a bit around the use of parentheses depending on whether you are working in XSLT 1.0 or 2.0 (or even 3.0), but you should be able to make it work.

     Keith

One more time ...

It's a Wednesday morning in mid-September, and those of us at the HL7 Working Group meeting will shortly be hearing from Ed Hammond and some will be awarded vases in Duke Blue, and so that means it's also time for me to award the next Ad Hoc Harley.

This next awardee is someone I'd best describe as a passionate lifetime student.  I first met this person while I was chair of the IHE Patient Care Coordination workgroup in IHE and they were just learning CDA.  I love to teach, and they absorbed just about everything I could teach and then sought out more. 

It didn't take long before the two of us could spend an hour of committee time discussing the exact way in which some small piece of CDA could be modeled so that it was just right, and the semantics meant exactly what they should.  A very strong leader, we were sure to clash on some topics, but always with mutual respect and retaining friendship even when we disagreed.  Health IT is better for those sorts of interactions, something not everyone appreciates (but I do, and so do they).

Before too long they had become CDA Certified, led a workgroup developing multiple CDA specifications and an author/editor of as many CDA implementation guides as I had.  They've been deeply involved in specifications for long term care, quality measurement, first in CDA and later in FHIR.  Most recently they've been leading terminology efforts with a team developing specifications that will aid the under served by enabling the capture of Social Determinants of Health in the HL7 Gravity Project.

I look forward to continuing to work with her, and learning what she has to teach me in this space myself as I award the next Ad Hoc Harley to ...

Lisa Nelson, BA, MBA, MMI of MaxMD

for being a lifetime student and a teacher of leaders...

Life will find a way

The defining behavior of an organization or organism is that it will resist change that is perceived to threaten its existence.  Few organizations (or organisms for that matter) fail to do so, or ever consider cases beyond which the need for their existence ceases to be present.  This is also true of work groups, committees, and organizations, even those built to address temporary situations, unless there's some very specific hayflick limit assigned to them during their creation (and even that isn't always sufficient).

So very often as change agents, we fail to take this into account when we envision change.  For example, this recent post from Z-Dogg MD on Medicare for All talks about the hidden consequences of Medicare for All.  I can't fault Z-Dogg's logic here, but what I do fault is the fundamental assumption that "other things remain the same".  Yes, if Medicare for All were to become a thing, the existence of hospitals, and medicine as a profession would certainly be threatened.

But here's the catch.  Hospitals are organizations, and medical professionals are organisms.  There's an appropriate meme for this:
 

And the challenge for many is that we won't actually understand how, or in what way the organisations and organisms threatened by these changes will adapt to the change.  But adapt they will.

One thing routinely taught in both User Experience and Informatics classes is an awareness of unintended consequences.  With any big change, there will be consequences.  In a complex system, some of those consequences are certainly going to be undesirable to those organisms or organizations whose existence is perceived to be threatened by that change.  But simple logic that assumes that the system isn't going to adapt to the change is isn't going to cut it.  Yet few will think beyond it.

In the case of Medicare for All, I can honestly say that I haven't a clue what will happen, but if hospitals are threatened, they will actively seek out ways to remain profitable.  And physicians who are accustomed to a certain level of income may in fact leave medicine, but they will eventually be replaced by others who never know that the same level of compensation (see this summary).  Other impacts might be to pressure institutions that train physicians to do so in a way that doesn't leave them with crippling debt. We know this will happen because a hole in the ecosystem ... or the economy won't be left vacant for long.

How Things Fall Apart

It doesn't take an evil overlord to destroy something.  Things will fall apart on their own if you simply wait long enough.

Beyond a certain size, a software project, a publication, a technical specification, or a standard becomes unmanageable.  This can be mitigated with processes, but processes executed by humans aren't nearly as a repeatable as processes managed using automation.

Let's take a look at an example of how something like this happens in standards...

In HL7 Version 2, the PV1 segment reports information about a patient visit.  An important thing happens during an inpatient or emergency department visit, which is that the patient is discharged.  You will want to know about this, in terms of both where to, and when.  In HL7 Version 2.1, where is captured in PV1-37 Discharged To Location, and when in PV1-45 Discharge Date/Time.

Let's look at the evolution of PV1-37 over time.

Version	Datatype	Description
2.2	CM	Components: <code> ^ <description> Definition: indicates a facility to which the patient was discharged. Refer to user-defined table 0113 - discharged to location.
2.3.1	CM	Components: <discharge location (IS)> ^ <effective date (TS)> Definition: This field indicates a facility to which the patient was discharged. User-defined table 0113 - Discharged to location is used as the Hl7 identifier for the user-defined table of values for this field.
2.5.1	DLD	Components: <Discharge Location (IS)> ^ <Effective Date (TS)> Definition: This field indicates the healthcare facility to which the patient was discharged and the date. Refer to User-defined Table 0113 - Discharged to Location for suggested values.
2.8.2	DLD	Components: <Discharge to Location (CWE)> ^ <Effective Date (DTM)> Definition: This field indicates the healthcare facility to which the patient was discharged and the date. Refer to User-defined Table 0113 - Discharged to Location in Chapter 2C, Code Tables, for suggested values.

Originally, PV1-37 was just a composite made up of a code and a description.  Between 2.2 and 2.3, the data types and description of the second part of the composite changed from <description> to <effective date (TS)>.  Why?  I don't know.  It could quite simply have been someone asking "What do they put in the description field?", and someone else responding "Usually the discharge date" and from there maybe they decided to set the data type to TS, not realizing this data was already in PV1-45. NOTE: It's really hard to say what happened because this was back in 1994.  The HL7 List Serve only tracks back to 2012 for pafm and V2 lists, and the historical tracker database only goes back to Version 2.5, which came out in 2006/7 time frame, and the ballot desktop only goes back to 2004.

In the 2.4-2.5 time frame the CM data type was replaced with a real data type (DLD), which was defined as being an IS followed by a TS.  That we can determine from change request 135 in the HL7 change tracking database for Version 2.

Over time, IS data types were switched to CWE data types, and TS to DTM as you can see in Version 2.8.2 above.

So, somewhere along the way, we lost track of why <description> became <effective date>, and duplicated what was already in PV1-45 Discharge Date/Time.

People move on, knowledge gets lost, cruft and minor issues accumulate, technical debt accrues.  Eventually, technology needs to be rebuilt, just like anything else, in order to be relevant, useful and most of all, well understood by all currently using it, or it collapses under its own weight.

On The Proliferation of Implementation Guides

For all of the problems that standards solve, they also create more.

There's even a standard comic for this one XKCD/927 below.

Standards are like potato chips, you can't have just one.  I've said this many times.  The challenge that we face though, is that everyone has a somewhat different use case.  So it's more a matter of 14 different flavors of potato chip, rather than 14 different potato chips.  And somehow we have to put all of them into the same bag (maybe) to make everyone happy.

• Company A wants to record blood pressure using a consumer device simply and easily.
• Provider B wants to get that information as easy as possible, and their organization wants it to cost as little as is reasonably possible.
• Professional Society C wants it to be conforming to the highest quality of standards that can be met practically using consumer grade equipment.
• Medical device manufacturer D wants the data to contain everything they feel is essential to cover their FDA requirements for capture of the information.
• Medical Researcher E wants to have ALL of the data the same way every time for the most reliable measurements.

Every single one of these constituents has reasonable requirements for why they want what they want. Many of the requirements conflict with each other in many ways.  How do we get from here to there in a way that we can make use of the data?

The way this is done today in standards is essential by eminence, rather than by evidence.  We compensate our under-engineering with real data by over-engineering a solution. To be honest, it's pretty damn difficult to gather the necessary evidence needed.  How would you put a number on any of the following?

1. What's the actual value to research for having ALL of the data (not just the BP measures, but the signal that was interpreted to produce the measure)? 
2. How much of the FDA medical device requirements are essential for patient care?
3. How much variance is reduced by recording cuff size?  
4. What is the impact of not recording it on patient care?  
5. How accurate is the data that is recorded? 
6. What is actually going to cost to get that data to a healthcare provider?  
7. Whats the cost to develop an app that allows this data to be transmitted using various standards?

Can you even get data that would be aligned with measures associated with any of these questions?  Would you be willing to sit in a room with a number of noted physician and even ask some of these questions?  Because if you do, you will be challenging the status quo somewhere.

But status quo right now is that this isn't happening in a practical, cost effective fashion, and someone has to engineer a solution to make it work.  How much engineering is actually going to happen though, really, without looking at all of these factors.  Because if you don't address those factors, you aren't really doing engineering (you may be over-engineering a perfect solution, a sure sign of under-engineering).

Until we can solve this problem, we're simply going to be stuck with a whole bag of things that is probably more than we need.

P.S. When this ad came out, I did eat just one, just to prove that I could.