A 21st Century Cures Act Security Primer

The healthcare world has been going digital for a while and new federal government regulations tied to the 21st Century Cures Act are accelerating that trend. As the Centers for Medicare and Medicaid Services (CMS) predicted, the industry has also seen explosive growth of healthcare apps addressing use cases built on top of public APIs. The CMS Patient Access final rule, as well as the Office of the National Coordinator for Health IT (ONC) Information Blocking rule, now impose deadlines for most healthcare organizations to allow patients to access and share their electronic health information (EHI) via APIs. These new regulations are being enforced starting in 2021.

Both the CMS and ONC rules require health organizations to make use of the Fast Healthcare Interoperability Resources (FHIR) API, developed by the non-profit Health Level Seven International (HL7), to implement “interoperability” of health information. In addition, implementers must use the FHIR complementary security and app registration protocols, specifically the SMART Application Launch Implementation Guide (“SMART IG”) 1.0.0, which is a profile of the OAuth 2.0 specification, and the OpenID Connect Core 1.0 standard.

An organization implementing a Patient Access API must also make documentation regarding the API functionality and operation publicly accessible by posting it directly on their website or via publicly accessible hyperlink(s). The documentation must include at a minimum the API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception-handling methods, software components and the configurations an app must use to successfully interact with the API, and more.

In summary, health information must be accessible via an API, the API implementation must be documented, and that documentation must be made publicly accessible. The API provides access to highly sensitive health information that must be kept confidential and secure under federal and state privacy and security rules, including HIPAA, meaning that health organizations will face steep penalties if that data is breached. Given the high value that stolen health data commands, one can only anticipate that cybercriminals will look to target these new APIs to breach health organizations and steal patient data. 

While public APIs provide accessibility and the platform for innovation, they also significantly increase the risk of data breaches, challenging all health organizations to layer an effective API security and governance protection over those new APIs. As a result, API security, patient consent management and data privacy are fast becoming major design considerations for public healthcare APIs.

These risks can be mitigated, however, through the implementation of a Zero Trust model that includes robust identity and next generation API security controls. This would mean authenticating and authorizing all requests, continuously monitoring all FHIR API activity, remediating issues tied to third parties misusing the API, blocking hacking and enforcing patient consent rules at the API itself by monitoring API payloads to redact or block certain data requests.

The table below provides relevant information on compliance dates that must be met, including two past dates (highlighted):

Four requirements are tied to identity, or to how the API is accessed and used:

• Identification and Authentication: Is the patient who they claim to be, or might a request be coming from someone who has compromised a patient’s account or stolen their credentials?
• Consent and Delegation: Has the patient granted consent for their EHI or a portion to be shared? Can someone access or share EHI on behalf of someone they care for?
• Patient Matching: Many health organizations have patients with the same name—and if the correct data is not associated with the right patient, it can lead to exposing protected medical records, medical errors, billing errors and other costly problems.
• API Level Security: Given that FHIR APIs and the documentation for how to use them will be publicly available, a dynamic approach to monitoring and securing their use after authorization is granted must be implemented.

Based on numerous conversations with security leaders, these recommendations rise to the top:

1. Strong Authentication. The best way to mitigate this risk is through a robust identity infrastructure that can authenticate and authorize users and incoming requests—and given the prevalence of account takeovers enabled by compromises of weak authentication, the new government rules point strongly to MFA. Adding passwordless capabilities would additionally strengthen security.
   
   

2. Single User Store. A repository for all user identities outside of EMR/EHR systems should be considered. That store or directory would provide a single view for each user across all systems and resolve duplicate identities.
   
   

3. Dynamic Patient Consent Authorization. Collect, manage and enforce consent-driven access. The most effective way to enforce consent for EHI is at the API level by monitoring payloads and applying in real-time rules set by patients. Data would be made available, redacted or blocked based on the consent granted by the patient. That approach has also the merit to enable data sharing on a granular basis, therefore future-proofing the API implementation.
   
   

4. Monitor All API Activity Post Authorization. All activity should be monitored after access is granted with a great level of scrutiny on a per user basis—and not just per token or IP address. Activity needs to be tracked and made available for governance and forensic reports.
   
   

5. Identify and Block Hacking Using Machine Learning (ML). This requires active AI/ML analysis of all activity on APIs to identify malicious actions (attempts to breach or ongoing breach) and take corrective action such as notification and immediate blocking. ML can be effective at identifying attacks with compromised credentials, detecting hacking attempts to “reverse engineer” an API to take over accounts, as well as countless number of assaults on the API to steal health information.
   
   

6. Catch API Bugs and Other Mishaps—in Production—with ML. ML technology can also be used to recognize API bugs, misconfigurations and deployment issues that could lead to data leaks and other costly mishaps, while in production—and automatically block hackers exploiting those vulnerabilities. The same technology would sort out abnormal or abusing API activity by partners and third-party application developers.

    

Here at Ping, we work with the largest global healthcare organizations to help them stay on top of evolving healthcare security challenges. See below how you can use our solutions to protect EHI infrastructures and address Cures Act security needs:

1. Strong Authentication and Single Sign-on. These capabilities are implemented with PingFederate, PingOne or PingOne Advanced Services. For increased security and passwordless options, organizations use PingID or PingOne MFA to insert multi-factor authentication (MFA) into the decision flow. PingOne Risk can also add a valuable AI layer to assess the risk of every authentication and reduce the number of times another authentication factor is required, leading to more security with a better, enhanced user experience.
   
   

2. Single User Store. PingDirectory is a high-performance repository for consolidating all identities, synchronized from any number of directories including databases, LDAP and Microsoft AD.
   
   

3. Dynamic Consent. PingAuthorize enforces user consent and organizations’ policies at a granular level consistently by applying rules and policies at the point of access: the API. This approach eliminates the need to manage and enforce consent at each data store, eliminating the risk of having any one of them improperly configured. The solution controls fine-grain access and sharing of EHI data by inspecting API payloads in real-time and allowing, blocking or redacting EHI based on what patients have consented. Consent attributes can be stored in PingDirectory and managed directly by the patient.
   
   

4. API Activity Monitoring. PingIntelligence for APIs tracks API activity across all API gateway clusters, clouds and datacenters to deliver a single pane of glass used to monitor the API infrastructure. Existing and new APIs are discovered automatically and API traffic is linked to the identity of each user or machine consuming it—and not just a token/cookie, API key or IP address. Deep activity insights are delivered for auditing, forensic and governance reports.
   
   

5. Machine Learning (ML) to Catch API Bugs in Production and Identify, and Block Hacking. PingIntelligence for APIs leverages ML to detect and block modern API hacking techniques, from attacks that bypass the UI to compromise the API and take over an EHR system to data theft using stolen credentials. In addition, PingIntelligence can identify abnormal behaviors tied to third parties abusing a FHIR API, and catch active APIs’ bugs, vulnerabilities or misconfigurations that can lead to data leaks. It can identify attacks, as well as protect against people’s mistakes—and allow teams to step in to control damages.

To learn more about the 21st Century Cures Act regulations, please download the white paper “Identity as the Key to Better Digital Health.”