The Path Forward for Meaningful Use

Below is my assessment of the current Meaningful Use program and a proposal to better serve the needs of stakeholders.  I’m likely going to violate many rules with this post.   First, it’s over 1500 words, which is not ideal for social media.     Second, there are many who will find my conclusions politically unpopular.   I’m not criticizing people, I’m just commenting on ideas.   Finally, many of these topics do not have black and white answers. I hope my suggestions improve upon our current trajectory.

Where We Are

1.   I believe that the Meaningful Use programs have served their purpose.

Stage 1 created a foundation of functionality for everyone.   That was good.   Stage 2 tried to change too much too fast and required an ecosystem of applications and infrastructure that did not exist.   Clinicians struggled to engage patients and exchange data because they could send payloads but there were few who could receive them.    Stage 3 makes many of the same mistakes as Stage 2, trying to do too much too soon. It requires patient accessible Application Programming Interfaces (APIs) without specifying any standards.   It requires sending discharge e-prescriptions although pharmacies cannot widely support the cancel transaction that is essential to discharge medication management workflow.   It requires public health transactions but CMS has no authority to require public health authorities to standardize the way they receive data.  

Clinicians cannot get through a 12 minute visit, enter the necessary Stage 3 data elements, reconcile problems/allergies/medications from multiple institutions, meet the demands of the  Stage 3 clinical quality measures, make eye contact with patients, and deliver safe medical care.  There needs to be a new approach.     The same thing is true about certification.    I believe that early stage certification set a floor on EHR capability that was appropriate.   Certification is NOT good for the next stage of maturity, which will be driven by heterogeneous use cases and dynamic technology evolution.  Certification is now at the point where it threatens usability, interoperability, and EHR quality, while at the same time diverting research and development resources of health IT developers and providers.

2. I believe that volitional Information Blocking does not really exist.

There may be incompetence that feels like blocking but I’ve never encountered a competent organization with a business need blocking the secure exchange of information. I realize that there are folks in Congress who believe that a new crime called Information Blocking necessitates civil/monetary penalties and enforcement.    I have never encountered a Chief Information Blocking Officer at a health IT developer or provider organization.   The barriers are lack of enabling infrastructure, data governance, uniform policies, appropriately constrained standards, and economic incentives.  Focusing on information blocking is a distraction.

3.  I believe we cannot solve every societal problem through regulation.

The layers of requirements in Meaningful Use, the HIPAA Omnibus Rule, the Affordable Care Act, ICD-10 and the Medicare Access & CHIP Reauthorization Act of 2015 (MACRA)  are so complex and confusing that even government experts struggle to understand the implementation details.    Each of the regulations leads to various audits.  My experience is that even the auditors do not understand the regulatory intent and ask for documentation that far exceeds the capabilities of existing technology.   I was recently asked to support a Meaningful Use audit because the auditor wanted proof that a clinician performed a certain task during the reporting period (a report with a time and date stamp was not enough).   Maybe a video of a clinician at a keyboard with a calendar/clock on the wall in the background?

4.  I do not believe that adding numerous structured data elements and new quality measures to existing software creates disruptive innovation.  We need a business imperative for change and innovation based on the needs of customers.

I’ve already seen the rise of the Care Management Medical Record at our ACO, enabling care managers to examine data from all the EHRs in the community and identify gaps in care/variance from expected protocols.   Patient Relationship Management applications are in development, making healthcare more like other service industries.   None of this is driven by prescriptive regulation.

5.   I believe that health IT developers have already committed to piloting and developing Application Program Interfaces (APIs).

Creating regulation before there is any industry experience as to what works makes little sense.   Government can help with issues such as data governance principles, rationalizing  privacy policy,  and coordinating federal agencies but should not specify workflow or business process.  

What We Should Do

1.  Replace the Meaningful Use program with Alternative Payment Models and Merit-based Incentive Payments as part of MACRA.

Stage 2 and Stage 3 will not improve outcomes.   If alternative payment models offer compelling reimbursement for health and wellness, then clinicians and hospitals will adopt products and change behavior to achieve that goal.

2.  Replace certification with enabling infrastructure.

To accelerate interoperability we need a national provider directory, a master patient index/relationship locator service, a consent service, a certificate management service, and test beds for developers to exercise these services.   Today in Massachusetts we exchange over 3,000,000 patient records per month among 500 organizations because we created such enabling infrastructure backed by data governance (common policies and agreements).   Certification will not accelerate interoperability.

3.  Consider evolving the role of ONC to become a focused policy shop (supported by advisory committees) with a narrowed scope such as identifying ways to reduce errors, improve safety, enhance quality, accelerate interoperability, and meet the needs of diverse populations.

It could also provide transparency and true coordination for actions of government, communicating the IT efforts of agencies including DOD/VA.   ONC has become distracted by grant making, political agendas (see “information blocking” above), and expansive certification ambition.  It's time to narrow the scope and enhance the effectiveness of this important agency.

4.  Stop considering health IT developers and providers as the enemy.

Some believe health IT developers are responsible for creating information silos or resisting interoperability.   Some believe clinicians are lazy or greedy, requiring  government mandates to become patient-centric.   I’m sure there are exceptions, but in general, both are myths.   I’ve said that there are a few effective ways to influence clinician behavior - align incentives, give them a better work/life balance and help them avoid public humiliation (malpractice assertions, poor quality scores, negative Yelp reviews).   A partnership of government, payers, providers, patients, and health IT developers working together to achieve common goals is possible if there are mutually aligned incentives, such as the ideas embodied in value-based purchasing/MACRA.

5.  Focus our efforts on a few things that really matter.

The Federal Interoperability Roadmap has 117 goals.    The certification program has so many objectives that it takes a few hours just to read them all (summary slide below).

How about a laser-like focus on interoperability that includes just 3 objectives?

-ability to use FHIR to read a provider directory (could be hosted by government such as CMS as part of the national provider identifier or the private sector such as Surescripts, DirectTrust, or an HIE) and send a Direct message to that provider.

-ability to use FHIR/OAuth to read a relationship locator service (could be hosted by government or the private sector such as Surescripts, Commonwell, Sequoia, or HIE) and perform a query/response of the MU Common Data Set using a FHIR API.

-ability for a patient to download the MU Common Data Set using an app (that is curated/reviewed to ensure security and data integrity) using FHIR/OAuth or appropriate variants of OAuth such as HEART.   Several folks have contacted me to discuss the real purpose behind the consumer API requirement in the ONC and CMS rules.  Some suggest it was motivated by special interests who want to monetize patient submitted data.   Some suggest that it is an enabler for future provider to provider transactions.   Some say it is the best government lever to motivate the industry to move from messaging to APIs.    I’m not sure which interpretation is correct, but it is certainly true that providing data to the patient should be one of the focuses of interoperability.

Since MACRA will base payment on wellness which requires care coordination, providers will demand appropriate interoperability features when buying an EHR product.     Additionally, an independent third party such as KLAS could publish unbiased statistics about the actual experience of interoperability by speaking with hundreds of clinicians and staff.    Recently all the major health IT developers agreed to have their interoperability measured by KLAS via customer interviews using this questionnaire. 

I’m really trying to be helpful here and incorporate the overwhelming feedback I’ve heard from stakeholders.    More Meaningful Use and Certification criteria are not the answer.    Paying for outcomes that encourage government, payers, providers, patients and health IT developers to work together, instead of being adversaries, is the path forward.