This week at HL7, one of the topics of discussion within Structured Documents is a proposal to develop a new specification supporting capture of administrative information required in claims transactions, otherwise known as Attachments. One of the challenges posed for the claims process is that the data required by payers for claims for different services is complicated. From the CMS perspective this is further complicated by the fact that each type of service may be governed by specific regulation with respect to requirements that must be met.
One approach to this is to gather the various requirements and consolidate them in one place, and then require providers to report on all the data elements they captured or didn’t for an encounter based on those requirements. I’ve been arguing against this approach because I very much want the same data being used to record the clinical encounter to be able to be used in this scenario.
The concern that is being raised in that the current claims attachment guide is simple a rather thin veneer over CCDA, and none of the CCDA documents require all the data necessary to be captured to be present. I pointed out, unsuccessfully I might add, that the requirements that meaningful use imposes to capture and report on 17 data elements in the Common MU Data set also aren’t required of CCDA, and yet CCDA is the standard. It’s a combination of those data elements being present in CCDA, the ability for them to be included in any CCDA document, the MU Regulations which require their presence, and the certification testing which ensures that those 17 data elements are present in any document that is sent from an EHR system.
I don’t want HL7 to create an implementation guide that is essentially an enabler of compliance to the hundreds of regulatory requirements. As soon as any of that changes, the guide would need to be updated. One of the challenges here is a demand that any data that could be required for some part of these regulations, but which hasn’t been captured, has to be recorded as not having been captured. This is a packaging problem. The data may not have been captured in the EHR, but might have been captured elsewhere in an ancillary system (e.g., the Medication Administration Record). The data being required may not even be relevant to a particular specialty. For example, providers in the imaging space shouldn’t have to capture encounter data elements that providers in the anesthesia space might, and vice versa. Even in a similar space, what the surgeon reports and the anathesiologist reports will also have specialty specific variations.
If HL7 were to take this approach, the complaints that we would be hearing would be very similar to those reported by Margalit Gur-Arie in her thought provoking post on Innovative Health IT. I can hear it now: “Why do I have to report that I didn't capture this? That’s not even my job. That appears in the surgeons report.”
The approach that I’d like to see is to treat CCDA as a buffet. From it, a provider select the things that they need to capture and report on. There need not be an attestation that “this was not captured”, because if it isn't there, either it wasn't captured, or they don’t have access to that information, or it could be in a separate information system. There’s no attestation today in the current process that a particular piece of data wasn't captured. Rather, there's a signature that says this is what I have. From the provider perspective, if the data needs to be there to get paid, you can be sure they’ll figure that out.
We need to stop trying to mandate everything in the document. We should expect other forces like reimbursement and quality improvement incentives to ensure that content used for payment will show up. After all, not getting paid should be a pretty good incentive for providers to get it right. If the specification simply enforces what is already there in regulation, what will we do when the regulation changes? We cannot keep updating the standard every time the regulations are changed.
One response to my thoughts on this is that the EHR system will generate the report and simply insert all the necessary statements about “I didn't capture this.” The challenge here is that systems used for administrative transactions and systems used for clinical data management aren't always the same. So now the billing system needs to look at the clinical data, and figure out what is missing. That clinical data could be coming from several different systems (e.g., sometimes the ambulatory provider needs the discharge summary, not even in any of his systems). The attachments transaction can package not just one, but several documents in response to a query. I see no reason why we need create one “Uber CDA” for attachments, when we can in fact submit several. And if need be, a separate attestation that this is all the data available for this claim. Thus, if it’s not there, it wasn't captured.
Please, don’t make us duplicate the need to generate a CDA document for a patient encounter that is already required for meaningful use, and require additional gunge than makes it less useful for clinical care. And don't make us repackage information from several separate sources in a single document, when the existing claims transactions already support multiple inputs in response to a query.
It may well be that I don't understand, but I've been involved with attachments for ten years and more (in fact, this is now my 10th year as an HL7 member). CDA and Attachments what brought me here to start with.
0 comments:
Post a Comment