On July 1, the Centers for Medicare and Medicaid Services began the enforcement of its Interoperability and Patient Access final rule, designed to fuel data sharing between providers and to support patients’ rights to access their protected health information, relying heavily on the use of application programming interfaces (API).
The 21st Century Cures Act outlined the requirements of the interoperability rule, which are vastly supported by APIs. At the time of its draft proposal, industry stakeholders raised a number of privacy and security risks for patients.
The interoperability rule builds on previous CMS data-sharing rules and emphasizes the sector’s need to improve health information exchange crucial for enabling PHI access for patients, health care providers, and payers.
The rule centers around the idea that patients should be at the center of their own care with enabled access to their health data, which includes efforts to improve prior authorization processes through technology and processes, while enhancing CMS policies and increasing data sharing within the sector.
To accomplish this, the draft proposal showed CMS intended to use third-party applications to transfer PHI. However, as noted by the American Academy of Neurology at the time, the use would create security risks as the rule lacked a third-party app security framework.
“Challenges associated with interoperability and data blocking are two of the most critical elements forcing clinicians to spend more time on low-value clerical work and less time on direct patient care,” AAN President Ralph Sacco, M.D., wrote at the time.
“Consistent policies are needed across the board to incentivize and facilitate the exchange of data across systems,” he added. “Many EHRs do not support the robust use of APIs for data exchange or are hindered by APIs that are implemented in proprietary ways that inhibit data exchange.”
Further, the rule did not expressly clarify the role of the third-party app developer in maintaining the security of patient data.
The American Medical Association, College of Healthcare Information Management Executives, Medical Group Management Association, and other industry groups echoed those concerns in a September 2019 congressional request that also asked Congress to oversee the implementation of the information blocking provision of the Cures Act.
The groups also argued that the Office of the National Coordinator (ONC) should be required to address the app and API security risks prior to the rule’s enactment, as well as other security concerns that can arise when on-boarding third-party apps onto the systems of providers and clinicians.
For Terry Ray, senior vice president and fellow at Imperva, these privacy and security concerns are valid as any innovation comes with its own risks -- particularly as the health care sector has remained a prime target for nefarious attacks.
The rule relies on APIs, which “serve as the connective tissue between applications and the underlying database,” said Ray. CMS’ voice to open APIs to third-party vendors could blur lines of data ownership and accountability, which could increase the risk of errors.
Even before the Department of Health and Human Services’ interoperability push, cybersecurity concerns and infrastructure attacks were commonplace, including those against health care websites.
For example, Imperva Research Labs monitored roughly 187 million web app attacks against global health care targets each month, on average in 2020. The total amounts to roughly 498 attacks per entity each month, a 10% increase from 2019.
As many health care entities are already strapped for resources, the introduction of new apps or APIs may add to the security burden of providers, he explained.
“The health care industry should prepare for more advanced and sophisticated attacks targeting the expanding ecosystem of APIs and third-party applications in the months and years ahead,” said Ray.
“API security will present a significant business risk for the health care industry in the years ahead,” he continued. “While the intent of the new HHS rules is to help improve patient care, this model could potentially lead to sensitive data exposure – especially if health care organizations aren’t proactive about protecting all paths to their data.”
CMS’ role in API security
The Health Insurance Portability and Accountability Act was enacted long before the age of digital health, and certainly before the reliance on APIs. The question then becomes how HHS, CMS, and its relevant agencies can reduce the threat landscape posed by the enactment of the interoperability rule.
As Ray sees it, regulators and security experts will likely focus on just what data the APIs are supposed to access, in addition to the data it actually accesses and how much, and whether the APIs can access data it was previously not able to view.
“Securing the data itself must be the business imperative.”
Terry Ray, Imperva Senior VP, Fellow
As a result, API data access behavior will remain a key focus area, which Ray noted is similar to the access requirements in HIPAA in terms of individual parties.
“By applying the right controls to govern, monitor access and protect data, it decreases the opportunity for a bad actor to compromise a third-party API connection or vulnerability to exploit the flaw for greater damage,” he added.
Health care providers should not expect to receive overt assistance on API security from HHS and will instead need to proactively move to secure APIs now -- with the same level of security leveraged with normal business-critical web applications.
Ray provided a number of key security recommendations for providers to support API security and the overall implementation of the requirements of the interoperability rule. For one, REST APIs employ basic authentication via the TLS protocol, but providers should consider the use of OAuth 2 and OpenID Connect -- considered more secure options.
The next step is to establish what data identified users are allowed to access. Other recommendations include the validation of API calls against API schemas, with complete descriptions of expected structures.
The tool should also scan for payloads, while Ray noted that “performing schema validation can prevent code injections, malicious entity declarations, and parser attacks.” Administrators can also assign an API token for each API call, which will validate incoming queries and prevent endpoint attacks.
Lastly, all web pages must be secured with TSL/SSL, which will encrypt and authenticate all transmitted data, especially data sent via web APIs. Ray stressed that the use will mitigate man-in-the-middle attack threats, as it prevents site traffic from being intercepted.
“An API should be built and tested to prevent users from accessing API functions or operations outside their predefined role. For example, a read-only API client shouldn’t be allowed to access an endpoint providing admin functionality,” said Ray.
“Above all, the fundamental focus must be on securing data. Web applications and by extension, APIs, have for decades been considered separate and apart from the data sitting right behind them,” he added. “Successful security programs recognize the need to both monitor how data is used behind the applications, but also, and now as importantly, how that data is being used by the applications and APIs themselves.”
The path forward
The enactment of the interoperability rule, combined with the continued threat landscape, should serve as an inflection point for health care providers to consider threats beyond their immediate set of vendors.
“They must now account for all the APIs and third-party applications that could be accessing their data systems – exposing them to risk in a new, more complex way,” Ray added.
What’s not changed is the cybersecurity burden on providers, as HIPAA requires all covered entities and business associates to ensure PHI in their possession is secured from unauthorized access or disclosure. Ray noted that the same can be said for other sectors.
However, these required security measures are often overly burdensome to providers, as it’s combined with the high operating costs of normal business operations. In short: it typically means there’s less money in providers' budgets for cybersecurity.
In recent years, health IT vendors have offered managed services to the health care sector, including outsourced electronic medical record systems and other products that shift some of the cybersecurity risk off of the provider and onto the vendor, which he explained can reduce some of the overall costs.
Regardless of the security burdens, providers remained tasked with protecting data and all paths to it. Ray stressed that providers need to invest in application and data security with multiple layers of protection, which will support legitimate traffic and keep out bad actors.
“The government may choose to have a role in that challenge, but regardless of that choice, health care providers have moved to try and mitigate some of their risk by using third-party services,” Ray explained. “Securing the data itself must be the business imperative.”
“Move away from point solutions as managing a growing stack of technology to address each unique risk is unrealistic,” he added. “Instead, find a partner that can offer an integrated platform that provides protection against the leading attacks and optimizes web performance, helping the organization to operate more efficiently and securely.”
Above all, providers need to ensure regulatory compliance, which includes the ability to demonstrate access controls and monitoring for all PHI access. Although data security remains a complex issue, employing the right policies, processes, and technologies can effectively reduce these risks and protect patient safety, Ray concluded.
