We had an extensive discussion about guidelines for producing content for ABBI on the content call today. It was challenging in several ways.
There is a desire to present to "Data Holders" (Providers and Payers) a description of what data they need to produce so that it can be sent through ABBI. I argue that the Certified EHR in the providers possession should already be producing the C-CDA content, and so why do we have to describe it further. If we do, we run into the danger that people will expect that they must produce this thing separately. Yes, I know that C-CDA needs a quick-start guide, and that the industry as a whole needs C-CDA examples, and all of the other weaknesses. But the ABBI Content workgroup is NOT the place to backfill for this. The industry is currently working towards these pieces.
The next notion was on using stylesheets. It seems that few on the call understand that C-CDA already has two separate components:
-
Human readable components found in section/text
-
Machine readable components found in section/entry
The former can be, but isn't necessarily generated from the latter. Nor does a CDA rendering stylesheet provide the user of the CDA with any control over how 1 comes from 2 (if it does at all).
What we were actually talking about are two different things:
-
A rendering style sheet that turns CDA content into HTML (or XHTML) content that can be viewed in a browser.
-
A style guide that explains how to best present this kind of information to people in usable ways (and could be used to provide implementations with a way to generate the former from the latter).
The first is a technical artifact that involves straight-forward mapping from CDA elements to XHTML. Even
I can do that. The second involves a great deal of design experience, which precious few on the ABBI project have. Not a dis, just reality.
The closest that the industry has come to any sort of style guide at this stage is
ASTM 2184-02. That standard has been withdrawn without replacement (That basically meant that nobody was available or interested in maintaining it any more). The standard itself was relatively weak. It contained names of standard sections (most of which were adopted in LOINC, which was used by C-CDA), and had VERY limited guidance on how to document contents of each section.
There are three points I'd like to raise here:
Best Practices evolve from Practices
There is little enough available on practices for presenting C-CDA content to patients, let alone best-practices. Practices will evolving as solutions to MU Stage 2 do, and we haven't even seen the final test cases! It's hard to call anything a best practice without experience. So far, the only project I'm aware of that has done anything extensive in sharing data with patients in the fashion that ABBI has is
OpenNotes. So let that evolve. When we have a better notion of what people are producing, we can then work on how to make it better. Trying to do so before the industry has any experience is just asking for trouble.
Usability is about how you can use it, and Viewing is just one Use
The EHR or Portal isn't the only (or even the first) place where ABBI should be attempting to address usability of the data. The intent of ABBI is to put the data not just into the hands of patients, but also to do so in ways that applications can interact with it as well. Usability isn't just about presentation (e.g., human readability), but also about what you can do with it. ABBI enables a whole new eco-system of health IT applications. The last thing I want to do is to get in the way of anyone who wants to make a C-CDA available to patients, regardless of how good or poor I think their implementation of the human readable side of it is. In fact, what I want is exactly what the provider sees, nothing less. (FWIW, the "error" my
9-year-old spotted [and reported] in her records was in fact, a usability issue).
We want to attract provider to ABBI
The human readable side of C-CDA is very intertwined with the way that doctors want to produce clinical notes. They have what they like and have invested quite a bit in making it work that way. I don't want to introduce requirements in ABBI that will make providers want to avoid it because they have to change the way they are writing their visit documentation. If providers don't recognize how they write as potentially being a usability problem for their patients, market forces will eventually correct that issue for them, ABBI doesn't need to.
