By Don Rucker M.D./ National Coordinator for Health Information Technology
Twitter: @ONC_HealthIT
I am pleased to announce the release of ONC’s proposed rule to implement provisions in Title IV of the 21st Century Cures Act (Cures Act). We also released a series of educational resources that focus on areas of the rule—including patient access, information blocking, the new conditions of certification, and the role application programming interfaces (API) will play in the new health information technology (health IT) landscape created by the Cures Act. Over the next few weeks, we will hold several public webinars that share more about the proposed rule.
Let’s talk a bit about that API world and what it means for the people of this nation. The American public is awash in software apps. During my subway commute, at least half of my fellow riders are engrossed in their smartphones. I’m guessing only a few of them have apps that allow them to engage in their healthcare. What will it take to get patient-focused apps that help us manage health and care on our smartphones?
We have apps that connect us to our bank balances, airline ticket information, favorite sport teams’ latest scores, local weather, and traffic data for our commutes. Apps can even tell me when my next subway train is coming. Each of these apps work by connecting to servers that maintain the underlying data and then displaying the data in easy to understand ways. Although the app universe now has over 2 million products, it is nevertheless very difficult to get your personal medical data on your phone.
But this is about to change. In December 2016, legislators addressed this gap with an entire section in the bipartisan Cures Act focused on interoperability and health information exchange—including deterring and penalizing the practice of information blocking.
Congress required health IT developers participating in the ONC Health IT Certification Program (Certification Program) to publish APIs and allow health information from such technology to be accessed, exchanged, and used without special effort. Our proposed rule seeks to support patients’ secure and seamless access to their health information through APIs and would facilitate patients using apps to get their electronic health information at home or at their doctor’s office.
APIs are now central to any data exchange between computers. APIs are software protocols that work with Internet hardware and software to allow computers to talk to one another. But to require an API alone is not enough. APIs built without standards force developers to learn new tools for each EHR product. APIs built without standards can force patients and developers to be bound to a particular healthcare provider or EHR software developer. Can you imagine if each railroad in the United States had a different track width? That is the way it was for most of the 1800s until Congress required during the Civil War that the transcontinental railroad be built to one standard gauge.
With the Cures Act, Congress mandated that APIs be usable “without special effort.” This begs the question, “what is our equivalent of a standard gauge for healthcare APIs?” While there are a variety of relevant healthcare standards for connecting labs, images, claims processing systems, and other pieces of the provider world, when we look at the app economy and the clear trends in modern computing, one API approach seems to clearly emerge – Health Level Seven’s (HL7®) Fast Healthcare Interoperability Resources (FHIR®) standards. The Certification Program was designed to test and certify health IT, such as APIs, against consensus-based standards and certification criteria for the purposes of establishing and promoting interoperability in the healthcare market. In our proposed rule, we propose to adopt FHIR as the standard to which developers must certify their APIs and propose language to support an ecosystem for the secure flow of information. We believe this approach could lead to industry standard interfaces—interfaces where app developers can develop effective apps that use API technology without special effort to access a patient’s data.
It is important to realize that “open APIs” in healthcare use the same state-of-the-art security that other industries use to assure that patients are able to tightly control which apps may access and use their data. For instance, the OAuth 2 standards require specific actions for a patient to authorize an app to get their data in a way that meets authorization processes, putting patients in control of their data with individualized specific consent. While the APIs will be secured, and follow patients’ individual preferences, how that data is secured after it is in an app is a different story. Because the misuse of medical data can have lifelong implications for the patient and can involve entities that are not required to implement the protections and patient rights of the Health Insurance Portability and Accountability Act (HIPAA), patients will need to be careful when it comes to the apps they choose to allow to access and store their data.
With the requirements we are proposing today—including the FHIR requirements— I am optimistic that we as patients and consumers will finally have deep insight into our health and new data to prevent sickness. How will healthcare change when patients can freely access their medical records stored in different provider databases and combine them in a single app? How will it change when patients find they can take their records with them as they manage the rising costs of a healthcare system that offers little true competition? How will healthcare change when medical devices increasingly connect with the Internet of Things through secure and open APIs? While we do not know exactly what a secure open API future will bring, we can expect change in healthcare to be transformative. We will have better control of our medications and their costs. We will be able to bring machine learning and artificial intelligence directly to our health records on our smartphones. Apps we choose can help us to live more healthy and productive lives by integrating medical data into our daily lifestyle choices, including choices we make around exercise and eating.
The promise of standards-based API technology can only be successful if business practices that enable information blocking to occur are dismantled. For that reason, I thank Congress for deterring and penalizing information blocking and giving HHS the ability to identify reasonable and necessary activities that do not constitute information blocking. Along with reading through the API sections of the rule, I encourage stakeholders to read the entire proposed rule—including the information blocking section. The information blocking proposals put in place common sense exceptions for things like not making health information accessible during scheduled health IT system maintenance or for legitimate privacy and security reasons, and to permit the charging of certain fees associated with health IT systems. These provisions, when coupled with the updates to the Certification Program, including the API provisions, create a landscape ripe for progress and the flow of information for patient care.
Much of today’s American healthcare delivery system is often complex and opaque. Congress’s 21st Century Cures Act and modern computing allow us to revisit many of the assumptions about what delivery of medical care should be. ONC’s proposed rule to require secure open APIs, identify reasonable and necessary activities that are exceptions to information blocking, and update the Certification Program can serve as one of the largest steps necessary to make healthcare more transparent and patient accessible.
This post was originally published on the Health IT Buzz and is syndicated here with permission.