One of the challenges I keep running into in the use of CDA are some misunderstandings of its purpose and resulting from that, misinterpretations of what should be done with content within it. In this case, an assertion was made that a CDA document is created as an extract from an EHR. The subsequent claim is that each piece of data in the EHR carries some legal authentication provenance and that should be attested to within the document.
While extraction from an EHR is one way in which a document can be created, it is certainly not the only way, and even in that case, the legal authentication of data in the EHR is still happening at the encounter level, not at the level of the datum.
The focus of the CDA standard is to provide documentation of services performed in the context of a clinical encounter. For the most part, these are commonly understood to be the reports that providers produce in a consultation, physical examination, intake or discharge from a hospital, or when reporting on a procedure or surgical operation.
In all of these cases, the document serves as the legal and medical record of the encounter. As such, there really can be one and only one final legal authenticator to meet with both medico-legal and accreditation requirements. That attestation indicates that the provider is taking legal responsibility for the combination of content in the document. That doesn't mean that they necessarily agree with everything that appears in that record, but it does mean that the document is a true and correct representation of what occurred and the information available to the provider during the encounter. If there are questions about information contained in the document, the legal authenticator certainly should, and can in CDA, provide any comments about their concerns about any data represented in the document.
I don't want to see an evolution where every datum that ever appears within a document has to carry provenance indicating who originated it and when in order to assign final legal responsibility to that datum. At some point, the provider taking care of the patient has to agree to that datum in documenting the encounter, and that agreement is a case where there needs to be an assignment of legal responsibility. If they were misinformed and acted upon it, there is still a case for them being responsible for checking on uncertain data. After all, who but they are able to evaluate it clinically? Furthermore, while final responsibility rests with the legal authenticator, anyone who is able to act as an author also has responsibilities.
The idea being promoted here seems to be coming from the need to avoid fraud. But avoidance of fraud isn't isn't the principal reason for documenting a clinical encounter. Estimates of improper payments to Medicare range from 3 to 10% overall. Yet the cost of developing an IT infrastructure which could track data to this level, enforce non-repudiatable attestation to it, and the necessary changes and interruptions in provider workflows required to develop such a change would wind up costing healthcare a great deal more than we could save by doing it. Is that really where we want to go?
I don't think so. The point of the EHR is not to avoid fraud, but rather to provide for better care at reduced costs. Let's not forget that goal and subsequently introduce more effort and cost into the healthcare process just because there is a technical capability that could be executed on. A car running on hydrogen as a fuel is also technically feasible; why don't we see more of them? It isn't about technical feasibility.
As co-facilitator for the HL7 Workgroup for Records Management and Evidentiary Support (RMES, perhaps aka distracting gnats), thank you for broaching this subject matter Keith. There are many elements of your post that merit address and I very much hope that it proves a new starting point for a sustained discussion that has started, stopped, and restarted for sometime. To this point, and to Glen's, the RMES Profile Standard passed HL7 ballot and was published 2010.
ReplyDeleteFirst, I will reassure you that health care fraud is very distant from the key driver for asserting the functional requirements to which you allude. It happens to be where the money is (and policy attention due to the Center for Public Integrity series last Fall) but money is not the overarching purpose here.
The key driver, especially in the U.S. domain, is the extensive body of knowledge, embedded in Standards, regulations, and in case law, about how one determines truth in records in the widely varying contexts where the attributes for applicable "truth" varies. Healthcare is unique in the many and varied end-users whose "truth" attributes must be accommodated. Most worrisome is that what we've got today seems mainly useful for purposes other than those of the bedside clinician, as noted in Dr. Robert Foote's widely re-distributed Opinion in JAMA, July 8, 2013, "The Challenge to the Medical Record".
The additional challenge is that all industries and all legal domains are evolving in the area of what is generally referred to as eDiscovery, so that anyone who states that there is a fixed endpoint for "legal" in digital records systems is forecasting the future. There are areas where the issues seem fairly straightforward, such as problematic authorship attribution or non-evident record modification, where one might start.
Having invested in learning about CDA by, for example, attending CDA Academy, as well as various discussions with experts including you, I remain concerned that, as Glen notes, the absence of a Use Case exercise leaves many asking questions about what sometimes appears to outsiders like me to be a quasi-magical belief in CDA's necessary all-comprehensive sufficiency (So, we have "magicians" vs. "gnats" I guess?) My recent conferences with legal scholars and Federal Magistrate Judges gives me a little confidence that I am not being entirely "gnattish" by remaining in a "show me" state.
I know the CDA leadership to be conscientious and invested in the best interests of the health care enterprise and hope that folks like myself, are similarly received. We are looking for demonstration of the means by which EHR-Systems will utilize CDA in capturing, managing, and rendering a body of clinical information in a manner that meets rigorous evidentiary examination that indeed requires, by local policy, multiple "legal" authenticators. In some of these instances, for example CMS Documentation Guidelines for Evaluation and Management Services, it may be found that such are best addressed by "translation" into eDiscovery, EHR terms.
In any case, again I look forward to learning whether these matters have achieved sufficient interest and "critical mass" to work forward to align, for example, CDA with EHR-FM Release 2 which is now completing international balloting, also substantially incorporating the 2010 RMES Profile Standard. Where might this "convergence" project best be accommodated?
Reed D. Gelzer, MD, MPH, CHCC
Provider Resources, Inc.
Co-Facilitator, Records Management and Evidentiary Support WG (under EHR-S Workgroup)
Dr. Gelzer,
DeleteWhere the "money is" is where some of the assertions that "it must be this way" are coming from, whether or not meeting those requirements addresses the fundamental need for which the CDA standard was developed. Part of the challenge is addressing the fundamental issue of trust between those who pay for care, and those who provide and document those services. That means enabling evidentiary support, but it doesn't mean that CDA is the right place for it. Unfortunately, CMS has a small tool chest, and in that body of tools is the CDA Hammer. It seems to be attractive for a lot of uses which it wasn't intended to support, some which aren't a far stretch, and others which are far larger. I think the esMD focus on fraud has had far too much influence on the discussion. I realize that CMS's toolbox is small, and the CDA meaningful use hammer is rather versatile, but I don't think it's necessarily the right tool to address all of the needs that folks have suggested could "just easily be met by this one small change". Technically in the standard, perhaps, but the workflow ramifications are much larger.
What would it take to digitally sign every data element entered by a provider? How and where would you track that signature? At what cost and for what value? And is now the time to do this? These are the questions I ask.
Good questions. There is actually an initiative getting worked up to address this for a CMS Use Case. Unfortunately I won't get to the Cambridge WG meeting but that's no dependency for this work going forward. FWIW, IMO part of this line of inquiry has been generated from data-element level "tagging" in the DS4P project, opening the door to discussions of what else might be added at the element level for some subtypes of data. (People who know a heck of a lot more than I ever will about database design have been very kind in helping me understand at least some of this.)
ReplyDeleteThe CDA "corner" that various discussions have been painted into has, as you know, a convoluted history. From my RMES POV, the current "evidentiary pressure" on CDA has arisen in no small part from the fact that there are sufficient EHRs out there now that the risks arising from their extraordinary variability (and amazing variances from Records Management fundamentals)are becoming material.
How does an end-user (such as CMS) that has statutory requirements (written in "paper" days) for auditable Payment Integrity assurance, manage in an EHR environment with nearly infinite variability? In essence, CDA is being asked to have infinite capability to both validate, or at least differentiate good from bad, as well as transport. There do seem to be some folks who think CDA is up to the task or can be adapted to do so. (To me it would make infinitely more sense to make sure that the source systems are trustworthy, and relieve "exchange" from an over-sized validation burden, but MU has pushed that back for a few years.) IMO the pressure to engage means to validate source systems will grow, especially as overtly criminal organizations seem to have come to appreciate the efficiency of EHRs to create completely fake, perfectly configured records.
Economic pressure on "normalizing" EHRs as Records Management systems is already growing. Just recently I was advised by a consulting liability carrier that they would not write any policy at any price for anyone consulting on EHR/EMR systems due to the extraordinary risk, even if the work has nothing to do with patient care contact.
In any case, RMES and EHR welcome development a "convergence" path on these topics.
RDGelzer, MD, MPH
RMES co-facilitator