A Proposal for Disruptive Regulation of EHRs

The latest salvo in the interoperability and information-blocking debate comes from two academic experts in the field of informatics, and was recently published in JAMIA. In the brief article, Sittig and Wright are endeavoring to describe the prerequisites for classifying an EHR as “open” or interoperable. I believe the term “open” is a much better fit here, and if the EHR software happens to come from a business dependent on revenues, as opposed to grant funding from the government, bankrupt may be a more accurate description. Since innovation in the EHR market seems to lack any disruptive effects, perhaps a bit of disruptive regulation would help push everything over the edge.

Although the article seems to be just another shot at Epic, the currently #1 EHR in the country, which is privately owned and run by a woman (a seemingly irritating anomaly in the EHR world), it does have some interesting points worth exploring. The authors propose five overlapping use cases to describe functionality that is important to five stakeholder groups: clinicians, researchers, administrators, software developers and lastly, patients. Let’s look at each one in more detail (pay attention, since we’ll have a quiz at the end), and keep in mind that these requirements are meant to be enforced on all EHRs, including the relatively cheap little one you have in your office.

Use case 1: Extract

The first use case states that a client facility should be able to extract patient records from an EHR, while maintaining granularity of structured data, with the goal of creating “a new secondary-use database”  for internal purposes, or most likely for research. To enable the client to extract data and migrate it to a different database structure, the EHR vendor is required to provide the client with its “data dictionary”. A data dictionary is a detailed description of the EHR database schema, all its tables, views, data types, what the data means, how it connects to other tables, constraints, references, packages, procedures, and a whole lot more.

For the less technically inclined among us, the database structure, or the model, of a serious transactional software application is its heart and soul. The user interface, which is what you as a user see every day, is secondary and easily changed. Chances are that if you used the same EHR for a few years, you have witnessed such changes multiple times. You can certainly build a horrific user interface on top of an excellent model, but you can never build a great user experience on top of a lousy data model. The database structure is not written in stone either, but changes to the model entail excruciating effort and huge expenditures. The data dictionary, if done well, is both description and recipe for recreating the entire application, and as such it is the main portion of a vendor’s intellectual property.

Data dictionaries are usually provided to large clients that host their EHR onsite, and are mostly used to build interfaces with other systems. As health insurers continue to dump risk on health systems, database extractions are increasingly being used for other purposes as well. In the ambulatory market, data dictionaries are not usually shared with customers, since small practices have little to no ability to do independent software development. If your EHR is hosted in some cloud, in truly multi-tenant software as a service (i.e. data from multiple customers is stored in one database structure), you will not get any dictionary and you will never be allowed to access the vendor database, and rightfully so. The best you can hope for in this case is a data dump from your vendor.   

Use case 2: Transmit

This use case is a slightly expanded version of the current Meaningful Use requirement to generate and transmit clinical information in standard format (e.g. C-CDA) to another clinical facility or to an external personal health record (PHR). The goal here is to facilitate referrals or other transitions of care, and to prop up third party PHRs that nobody is interested in using.

Use case 3: Exchange

Here EHRs are required to be available 24/7 to accept programmatic requests from other EHRs for patient records. I am not sure what the significance of 24/7 is in this context, but basically the EHR should be able to respond to ad-hoc queries from any other EHR, locate the requested records, if any, and return a standard based response to the requestor. This use case is supposed to facilitate EHR agnostic community-wide health-information exchange, presumably (and strangely) without using a health information exchange (HIE) entity as mediator. Another peculiarity is the completely superfluous demand that the responding EHR should make its data dictionary available to all querying EHRs, which boils down to publishing the whole thing online, or on demand, for all competing (and aspiring) EHR vendors to enjoy, and to further democratize the hacking industry.

Use case 4: Move

This use case is intended to reduce costs of switching EHR vendors, while ensuring that all data in the old EHR, including metadata and transactional histories are transferred to the new system. To better understand this noble requirement, let’s look at how easily a health system can switch banks. If an organization uses say, US Bank for ten years, and then wishes to transition their accounts, to say, Bank of America, US Bank will first provide its complete data dictionary to the switching organization to be shared with Bank of America developers. Then US Bank will provide an extract of all financial data, including historical transactions and all metadata (e.g., timestamps, source, and authors) so everything is migrated and preserved in the Bank of America system. Other than the logos, the organization would not see any difference really, and this will all be done for little to no cost to the switching health system. If this has not been your experience, then you should call the banks and complain.

Use case 5: Embed

The fifth and last use case is about application programming interfaces (APIs) on steroids, and it enables health systems to develop new EHR features or functionality and seamlessly incorporate those into the EHR. This implies full access to read, edit and delete database content, as well as ability to augment database structures, while the original EHR is expected to incorporate these changes automatically into its basic services such as security and privacy. Essentially, an EHR should become a development platform with functionality exceeding that of the best operating systems out there. For example, if an EHR lacks the ability to collect and process PHQ-9 data, an institution could develop such functionality independently, while the EHR will be expected to incorporate the functionality in its own workflows, screens, decision support, and HIPAA protections, practically out of the box.

Putting all five use cases together and using a tortured way to come up with an acronym, the authors dubbed their framework for defining an open and interoperable EHR, EXTREME, and extreme it is. The framework is written from the point of view of a large health system dealing with a large EHR vendor, and understandably so, since this seems to be the authors’ natural habitat. Applying this framework to the hundreds of EHRs and EHR modules that have been certified by the government to date will ensure that this big business habitat is the only model left standing. There is a cost to transitioning a software package from being a product or a service, to being a development platform. That cost is beyond the reach of most existing EHR companies. For the remaining few, the cost will eventually be passed down to current customers, as was the case with all government mandates imposed on EHRs. Small practices and small hospitals, already struggling to stay afloat, will be dealt the final coup de grâce.

The authors state that this upheaval is necessary “if we are to realize the enormous potential of an EHR- enabled health care system”. Six years and billions of dollars since we embarked on this journey and all we can come up with is some elusive “potential” that will certainly materialize if only we could spend a little more money, and if only we could drive a few more people out of this business, and only if we take the necessary next step, which we are told is to dismantle “the myriad socio-legal barriers to widespread health information exchange”, which is newspeak for removing any and all remaining privacy and informed consent protections for individuals, whether they like it or not. The truth is that we have no research, no proof and no reason to believe that the mythical “potential” even exists, let alone that the bigger-is-better, top-down model of health surveillance is best suited to unlock this “potential”.

I have to confess here that I have no idea what an open and interoperable EHR is. I also don’t know what a high usability EHR looks like. I do however know what a good EHR is, not a perfect one, but a good enough EHR. Just like any other piece of software, from Microsoft Office to Oracle Financials, a good EHR is one that people choose to purchase. If other people think there are better ways, then by all means, they should build amazing new software and fairly compete in the EHR market, instead of engaging in armchair quarterbacking of rules and regulations to advance theoretical concepts that captured neither market interest nor customer dollars on their own merit.

Quiz Question: Of the 5 stakeholders listed at the top, which one is absent, from all EXTREME use cases? Answer: The patient. Even in the tangential use case where data may be transmitted to a PHR, the patient is a passive entity, while the “organization” decides when, if and what to transmit. At some point, the few patient advocates who have not yet been thoroughly corrupted by the deluge of cash and fame, will have to come to terms with the grim realization that everything done and said nowadays is not intended to benefit the people, and health care is no longer an exception.

How to Use CPT 99490 for Healing the Sick

The Medscape Physician Compensation Report puts primary care physicians at the bottom of the heap, with a median earning of less than $200,000 per year in 2014. What if the largest insurer of older Americans took those numbers to heart and decided to give primary care a pay raise of 25%, in recognition of and better support for the hard work involved in caring for the very old and the very sick? This is the general idea behind the brand new Chronic Care Management (CCM) fee introduced by Medicare on January 1st 2015. Three cheers for Medicare!

Unfortunately, Medicare structured its fees based on the now prevailing assumption that all doctors are charlatans, and hence every penny paid to them must be justified by at least one thousand pages of legal size, single spaced, dated and notarized documentation, or the electronic equivalent thereof. Furthermore, as is customary in our nation’s capital, every law or regulation that may be beneficial to the public, comes adorned with a wealth of gifts for special interests, which often render the original intent null and void for all practical purposes. The CCM is no different.

Medicare could have settled on a simple capitation fee for chronic care to provide payment for currently uncompensated care management and to expand such services to patients who can benefit from additional attention. By piling on reams of preconditions and micro-specifications, Medicare all but ensured that none of the money it plans to spend on CCM will actually benefit chronically ill patients. Complex regulatory frameworks benefit those who provide services to alleviate administrative complexity, in this case computer and software vendors, and garden variety consultants turned experts at chronic care management practically overnight. However, with a little bit of ingenuity, you can get and keep some of the CCM money, and with a bit more effort, actually use it to help the sick, if you are so inclined.

What you need to know

The first and most important thing you need to know is that if something sounds too good to be true, it usually is. The bogus CCM calculators you see on vendor websites, advertising that you can make a quarter million dollars per year in CCM fees are completely false, unless of course you are willing to fraudulently bill Medicare for CCM services, and even then, the projected revenues are overstated. Medicare will pay you approximately $40 per month for at least 20 minutes of non-face-to-face care management activities performed by clinical staff (including MAs) for patients with at least two severe chronic conditions. The fee is subject to standard copays and deductibles, and the service requires informed consent from the patient, above and beyond the general consent for treatment that you already have on file. CCM fees are for traditional Medicare patients only, and only if you bill under the Medicare Physician Fee Schedule (community health centers and rural health clinics are currently excluded).

Unless you are a geriatrician chances are that you will not have 491 traditional Medicare patients with two or more chronic conditions that “place the patient at significant risk of death, acute exacerbation, decompensation or functional decline”, and even if you do, many will be under the management of one or more specialists. Specialists can also bill for CCM, and only one physician can bill in any given month. From whatever number of patients you come up with, you should subtract those who will not consent to such nebulous service. Then you have to account for the copays you will not be able to collect, and the months when those presumably very sick individuals are discharged from a hospital, and you bill the much higher transitional care management (TCM) codes instead.

Bottom line is that if you get an extra $60,000 per year in Medicare CCM fees, you should consider yourself very lucky. To obtain this revenue, you will have to incur additional expenses. A good chunk of those expenses will be sunk costs if you are routinely managing your sickest patients pretty well. The added expenses involve mostly tracking time and billing, both of which can be optimized with a bit of Yankee ingenuity. You should be able to keep approximately $45,000 per year, if you have 150 consenting patients who fit the CCM requirements (or $300 per patient per year).

What you need to have

You need not attest to meaningful use, but you must have (and use) a meaningful use certified EHR. This is just a small gift to the tech industry. You must have a care plan for each patient that your staff (and your staff only) can access online at all times. You must provide these very sick patients with a way to access you or on-call staff (a person, not a machine) 24/7. You should have a reasonably accessible schedule for in person appointments, such as same-day availability. Although, Medicare does not specifically mention this, it would be very helpful if you were able to establish good channels of communications with hospitals, specialists, home-care agencies and long term care facilities. You will also need a good amount of patience and a sense of humor, but you will not need more expensive technology (e.g. population management, analytics, etc.).

What you need to do

I am certain that as you read this, you can come up with ten or twenty patients who fit the Medicare criteria, off the top of your head. That’s as good a place to start as any.

1. Make a list of CCM candidates. Keep it small, particularly if you have minimal staff and if the patients are very sick. You could select by disease type, or better yet pick patients for whom you already provide significant amounts of uncompensated care between visits. Use this group as your pilot experiment.
2. Schedule appointments with each one and obtain consent for CCM from as many as possible. Update, or formally create a care plan for each one. Hand them a copy (paper is fine), and place a copy in your Internet accessible EHR. Make sure that whoever takes call after hours has access to the EHR from home.
3. Now comes the hard part. You need to track the time you or your staff spends interacting with each patient, or on behalf of each patient, each month (office visits excluded). You could simply use a paper timesheet, or you could find a way to use your EHR. Here is an idea that even the dumbest EHR can accommodate. Start a visit note for each patient on the 1st of each month. Leave it open and keep adding a brief note to it (including amount of time spent), each time you or your staff do something for the patient. Add the pertinent ICD codes and the CCM CPT and sign all the notes at the end of the month. Your biller can take it from there. Revise and tweak your process to make it as efficient as possible. This is why you should start small and grow the program over time.
4. Twenty minutes is not a lot of time. One call with the patient (or caregiver) may just fill the entire allotted time. Other activities that are beneficial and can be counted are, talking to specialists, obtaining and reviewing consult notes and test results, arranging referrals, coordinating with home-care, reconciling medications and pretty much everything you usually do for these patients.
5. Run your little pilot for a few months and see where it takes you. You have nothing to lose, and may end up pleasantly surprised.

What you should not do

Billing Medicare for CPT 99490 is cumbersome, but it is not as difficult as you are deliberately being led to believe. The Medicare CCM regulations were written in a way that allows, and encourages, outsourcing of services to third party vendors. The “market” responded with a wealth of fancy semiautomatic software products purporting to manage chronically ill patients remotely through interactive apps and “clinical” reviews of collected data. The going prices for these “services” are approximately what Medicare pays you, minus the copay, and you still have to do the actual billing. It’s a horrendously bad deal from a financial perspective, but it’s an even worse deal from an ethical perspective.

You should not outsource the management of your most complex and most vulnerable patients. You should not allow yourself to be used as a conduit for diverting Medicare funds to technology companies. Signing up a frail 85 year old gentleman with heart disease and Alzheimer’s for a monitored iPhone app, may meet the Medicare CCM regulations, but most certainly does not meet the clinical definition of care management. Chronic care management is not a $17 billion market. It is the ethical practice of continuous, comprehensive and compassionate medicine. If you outsource that, you might as well outsource your professional license and your very own soul.