Enterprise leaders are focused on the payment mechanisms of the Medicare Incentive Payment System (MIPS) program. Penalties of up to nine percent for not meeting the MACRA clinical quality measures (CQMs) are particularly worrisome.
Put simply: not meeting these measures means reduction in reimbursement. All major EHR systems will have to support the measures if they want to stay in business. How well – or poorly – these systems fit the CQMs into a physician’s workflow determines what additional costs might arise.
These additional costs fall into two major categories:
- Physician productivity
- Physician satisfaction
The first of these, physician productivity, is starting to receive attention. Depending on whose study you read, ambulatory physicians spend somewhere between 50-75% of their time doing things other than being with their patients. The burdens of documentation, data entry, coding, and just trying to find something in an electronic health record, are increasing.
We believe that a physician’s time is a precious, non-renewable resource, the use of which must be optimized to improve patient care. Current systems provide clinical functionality only as an afterthought. This slows doctors down.
Now, with additional compliance requirements, productivity is going to continue to take even more of a hit. Unfortunately, the issue of physician productivity has received little attention from the HIS vendors who account for the bulk of enterprise users in the U.S. Most systems were not designed with the clinical user in mind. They were designed to process, and bill for, transactions, and are accordingly focused on financial accounting and reimbursement.
Complying with MACRA without sacrificing physician productivity will require a completely new approach: data architectures and designs based on computable clinical data. Current models being deployed rely on SNOMED-CT, Rx-Norm, LOINC, ICD-10, etc. None of these were designed for use at the point of care. They were designed to code, or classify, single items in separate domains and were not designed to work together.
A partial solution is to use a terminology layer on top of these code sets, which at least provides a single interface to look up a code or term. But, physicians do not deal with single codes or terms. They treat patients, and each encounter may involve the mental analysis, and documentation, of all information clinically relevant for the patient. Fortunately, they are trained to do this in medical school. Unfortunately, current systems do not support this clinical thought process.
For any diagnosis, most current systems provide a way to code the diagnosis for billing and data collection. But, for each clinical problem, the physician needs to document relevant symptoms, history, physical exam findings, tests and therapies to order, co-morbidities, and other related information. And now, some of these items are included in quality measures. More will be included in the future. How will a provider know which ones are included? And, for the items critical to making the diagnosis and determining treatment, how do those get presented to the physician, keeping in mind they still need to document the visit?
All these things need to work together, seamlessly, at the point of care. Adding yet another disconnected process, or set of checkboxes, is only going to reduce physician productivity even more.
To see an example of how the growing number of requirements can be met, without slowing physicians down or getting in their way, go to makemacrawork.com.
