Technologies for Cures

While the 21st Century Cures Act’s prohibition against information blocking has been effective for well over a year for health IT developers and information exchanges, healthcare providers have not been held to civil monetary penalties, yet. That will change this Spring. The 21st Century Cures Act (“Cures”) requires healthcare providers to share electronic protected health information (“ePHI”) through a general prohibition against “information blocking.” Information blocking means any practice that materially interferes with the access, exchange, or use of ePHI. There are a host of exceptions, but once the rule becomes enforceable, a healthcare organization needs certain technical capabilities to meet its requirements.

First, it aligns with HIPAA. Therefore, a provider’s systems must be able to produce human readable medical records. See this blog post for an a real word example of how such a complaint could play out. Next, your systems must be able to produce machine readable data and exports.  “Machine readable” means a computer can make sense of it. For example, computers cannot make sense of raw pictures, but if there are red-blue-green (“RBG”) color codes behind that picture, it can. In contrast, a person cannot make sense of a bunch of dots with numbers in them (RBG code values). The government wants data to be human readable so people can . . . read their medical history. It wants data to be machine-readable so payers, providers, and patients can automate processes, port data from one solution to another, and for different levels of clinical analytics. Standing in the way of those activities is information blocking.

However, the second prong is a little more complex. When you think through why a payer, provider, or patient would pull discrete machine readable data, you find you have to support a lot of different types of pulls, or have the technology that can support that. A general rule of thumb is that you should be able to produce data that somebody could reasonably use in their own systems – even if they have to work a little (or even a good amount). There are a lot of reasons why somebody might want their data, and that will inform how you format it and provide it. This is a blog post and cannot cover every use case, so I will try to cover the most important.

1. Payers, including CMS, want data for population level clinical analytics (i.e. how many patients receiving certain treatments measured against those treatment’s targeted clinical outcomes) and to make payment decisions on individual insurance claims. Certain plans may use it to identify potential areas of clinical intervention.
2. Providers want your data so they can coordinate the treatment of their patients, and sometimes so for payment purposes.
3. Patients want their data so they can look at their medical records and go to other providers. In the future some might start using it to upload their data to third party applications, like phone apps, although this does not appear common today.

On a technical level that actually means your technology stack has to support quite a lot. Let’s talk through it.

1. Payers need the ability to pull patient-specific  data to manage insurance claims. They need to pull population level data for analytics. That’s two different kinds of pulls, and not all systems can do them.
2. All parties, also sometimes need to pull only segmented data to meet the requirements of privacy laws, or HIPAA’s minimum use standard. One example of where you may have to segment data is when working with organizations that treat substance abuse disorders because it is governed by heightened privacy restrictions. Clinicians specifically need data related to specific encounters, but also sometimes need a patient’s entire medical history, depending on the nature of the encounter. For example, a physician may only need to pull in a lab result from your organization. That kind of data exchange would implicate the United States Core Data for Interoperability (“USCDI”).
3. Patients only need to pull their own data, and generally can be satisfied with full productions whether in PDF format or machine readable format.

All of this means a provider’s systems must be 1) partially open, 2) capable of setting specific data pulls depending on the use cases iterated above, and 3) able to convert that data in discrete machine readable information so that it can be used by third party products (within reason). Below are some common tools that you can leverage:

1. An electronic health record that is standardized;
2. Clinical databases that enable the storage, segmentation, query, and writing to electronic health records, and an accompanying data dictionary;
3. Solutions certified through the Office of the National Coordinator’s Health IT Certification Program;
4. Application programming interfaces (“APIs”) that will allow for segmented patient and population data pulls with your business partners, including your payers; or,
5. Health level seven (“HL7”) or other standard interfaces

Finally, let’s talk about what’s in scope of “data.” Right now, it’s only the USCDI, which is a set of discrete data elements including demographics, problems, medications, labs, etc. You can find it at the following link: https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi. Starting next year though, it will become the entire designated record set. That includes:

1. Medical records
2. Billing records
3. Payment and claims records
4. Health plan enrollment records
5. Case management records

That’s a lot. I recommend starting the procurement process now for any solutions you might need before the OIG finalizes its civil monetary penalties.