Assessing Interoperability for MACRA

From John Halamka’s Blog, Life as a Healthcare CIO:

Dr. Larry Garber, Medical Director for Informatics at Reliant Medical Group penned this response to the HHS request for an assessment of interoperability needed to support MACRA.

It’s so good that I wanted to share it with you as a guest post:

“To: Department of Health and Human Services
Office of the National Coordinator for Health Information Technology
330 C Street SW., Room 7025A
Washington, DC 20201

Re: ONC RFI Regarding Assessing Interoperability for MACRA

I am writing as a practicing physician, an implementer of electronic health records (EHRs), a designer/developer/director of EHRs and health information exchanges (HIEs), and a participant in standards development processes. It is my firm belief that our goal is “Hassle-Free HIE.” In order to achieve that goal, it is not only important to measure progress towards that goal, but also to ensure that all of the tools necessary to achieve that goal are readily available.

Interoperability is a continuum measured on 3 major axes with 9 sub-axes scored regarding their level of automation:

1. What the holder/releaser of data had to do (including the patient in the case of Personal Health Records (PHRs) and personal devices):
   1. Authorization
      1. Can’t be done
      2. Manual determination of patient authorization
      3. Automated (either authorization was covered by federal and state laws/regulations and that patient had provided any other required authorization/acknowledgement prior to transaction; or EHR was able to automatically convey consent requirements and interpret the nature of the release (e.g. requestor, purpose and data types) and assertions of collected authorization in order to automatically release the data)
   2. Addressing/authentication
      1. Can’t be done
      2. Manual identification of where/how to send the data and authenticating the requestor
      3. Automated identification/authentication of where/how to send the data
   3. Gathering data
      1. Can’t be done
      2. Collection of the data for sending required some manual intervention or entry
      3. Automated collection of the data to send (including device data)
   4. Sending data
      1. Can’t be done
      2. Manually triggering the data to be sent
      3. Automated sending of the data
2. What the receiver of data had to do:
   1. Identifying data source(s)
      1. Can’t be done
      2. Manual identification of holder(s) of data
      3. Automated identification of data source(s)
   2. Requesting data
      1. Can’t be done
      2. Manual request for data
      3. Automated request for data (including subscription or data pushed to receiver)
   3. Authorization
      1. Can’t be done
      2. Manual determination of requirements and assertion of patient authorization
      3. Automated (either authorization was covered by federal and state laws/regulations and that patient had provided any other required authorization/acknowledgement prior to transaction; or EHR was able to automatically determine consent requirements and assert the nature of the release (e.g. requestor, purpose and data types) and assert the collection of the authorization)
   4. Importing data
      1. Can’t be done
      2. Display/view of data only
      3. Manual reconciliation
      4. Automated reconciliation/incorporation
3. What the patient also had to do:
   1. Authorization
   i. Can’t be done
   ii. Manually provide authorization for the transaction
   iii. Nothing (i.e. authorization was covered by federal and state laws/regulations and that patient had provided any other required authorization/acknowledgement prior to transaction so transaction can be automated)

These measures can be applied to specific types of data (e.g. Medications, Problems, Allergies, Immunizations, Test Results, etc…) or document-level data (e.g. Patient Summaries, Care Plans, etc…)

I’m not sure how to automatically measure these, so they probably require attestations based on certain types of data as noted above (e.g. Test Results and Discharge Summaries).

HOWEVER, it is important to note that the scores on these measures do not reflect on the capabilities of an individual provider, their EHR vendor, their EHR’s implementation/training, the community/state/national infrastructure, the available standards, or the local/state/federal laws/regulations. Instead, it is a collective measure of all these combined. So while I think it’s important to measure these as a nation (because you can’t improve what you can’t measure), I do not believe that you can force Hassle-Free HIE by measuring and penalizing providers for things that are out of the control of the providers. You first need to create the national infrastructure to give the providers the opportunity to be successful (see below). Only then can you use positive incentives to encourage interoperability; but it’s still not fair to impose punitive payment withholds. While I recognize those are essentially the same, the difference is the message that you send when you market this…

In order to accomplish Hassle-Free HIE, we need these catalysts that are missing today:

1. National federated Master Patient Index (MPI) network
   1. Standards for patient demographic recording
   2. Standards for patient matching algorithms
   3. Shows how to communicate with patients, including Personal Health Records
   4. Shows proxy relationships and how to communicate with them
   5. Show authenticated devices and how to communicate with them
2. Relationship Listing Services (RLS) affiliated with the MPIs
   1. Show providers affiliated with patients and their roles (e.g. PCP)
   2. Show patient authorizations for communication with specific providers
   3. Show provider subscriptions for specific types of information, including events
3. National federated Provider Directory network
   1. Show provider services offered
   2. Show provider capabilities to communicate electronically, including necessary certificates/addresses
   3. Provider Directory is automatically updated/maintained by EHR that each provider uses
4. Standard consents/authorizations
   1. Types of data, uses of data, restrictions on redisclosure, timeframes, etc…
   2. How to convey requirements and assert that they have been received from patient
   3. How to convey authorization for proxy access (e.g. to parents of minors, or children of elderly parents) on behalf of patient
5. Standard vocabulary for orderable tests and procedures
6. Standard APIs
   1. Querying data from EHRs
   2. Submitting device data to EHRs
7. Support and encourage free text summaries of problems and encounters
   1. C-CDA updated to allow free-text descriptions/explanations of Problems in the coded data part of the Problem Concern Act and Problem Observation templates
   2. EHRs capable of generating C-CDA R2.1 documents that include free-text descriptions/explanations of Problems and Medical Decision Making in the Assessment or Assessment and Plan Sections
   3. Other document and API support for free-text problems and encounter summaries

Thank you for this opportunity to provide input into the future of our healthcare system.”

John D. Halamka, MD, MS, is Chief Information Officer of Beth Israel Deaconess Medical Center, Chairman of the New England Healthcare Exchange Network (NEHEN), Co-Chair of the HIT Standards Committee, a full Professor at Harvard Medical School, and a practicing Emergency Physician. This article was originally published in his blog Life as a Healthcare CIO and is reprinted here with permission.