Healthcare Interoperability and Information Security : It Is Not About Compliance

Rarely do we encounter regulations that also have the potential of spurring innovation and generating significant positive outcomes in health, wellness and indeed the larger economy. That is exactly the nature of change that the  CMS Interoperability and Patient Access Rule (“CMS Rule”) and the ONC Cures Act Final Rule (“ONC Rule”) are aimed for. We discussed an overview of the two regulations in our post published by the International Association of Privacy Professionals (IAPP) recently.

The objective of this post is to discuss specific ideas that healthcare information security (infosec) programs can or should adopt to support their organizations in the transformation initiatives.

The two regulations require both healthcare payers and providers (or the service providers they work with) to implement significant technology and capabilities for sharing sensitive patient data. The regulations also aim to usher in a new paradigm in healthcare data sharing and collaboration between healthcare payors, providers and the larger ecosystem of “apps” that may not even be regulated by the HIPAA Security or Privacy rules.

Infosec programs at these organizations have an important role to play in assuring that such technology implementations are secure and the data exchanges are performed only with authorized parties.

How can the infosec programs work with their organizations’ interoperability programs or initiatives and what should be the focus areas? I discuss a few topical ideas in the following sections.

  • Security Policies and Standards

    There may be a need to update certain security policies and standards. In addition, I recommend creating a new standard to support the security exception allowed in the ONC Rule for Information Blocking, as the Rule leaves it to covered organizations to define the specific details of the exception criteria.

    A sample of topical areas that may need updates to policies and/or standards includes:

    • Data Classification – The policy may need to be updated to include Electronic Health Information (EHI). its expected handling and the ownership/custodian aspects.
    • Information Exchange – The policy may need to be updated to include data exchanges mandated by the two regulations. Appropriate details of prerequisites and specifications may also be included in the update.
    •  Consumer Identity and Access Management – This may be a new policy for most healthcare organizations. The policy will need to cover areas such as identity verification or assurance, privacy and consent management.
    •  Authentication and Delegation – The policy may need to be supplemented with content related to non-FHIR protocols that may be used internally as well OAuth 2.0 and Open ID Connect that would be mandated for FHIR APIs.
    •  Third Party Risk Management – The policy may need to be updated to include details related to assessment for “Security Exception” criteria mentioned above.
    •  Access Lifecycle Management – Additional content related to request, provisioning/deprovisioning fulfillment of new interfaces (internal – FHIR and non-FHIR) and external (FHIR APIs).
  • EHI Data Flows and Inventory

An accurate and complete inventory of sensitive data flows and their repositories – both structured and unstructured data – is a foundational prerequisite for an effective security or data protection program.  The lack of such inventory or flows is often the reason why many security risk management or compliance efforts are not as efficient or effective as they could otherwise be. Refreshing/building the inventory and data flows must be among the program charters or objectives of interoperability readiness initiatives.

Once built, the inventory and flows should be shared on a need-to-know basis with various functions of the infosec program – Identity and Access Management, Detection and Response, Data Protection, Disaster Recovery etc. – to help ensure that those functions can plan and assist in  designing, developing and implementation of appropriate security safeguards or solutions.

  • Assessments for “Secure By Design”

Infosec programs should work collaboratively with their organizations’ interoperability readiness programs to perform an (pre)assessment of planning and design aspects of solutions and processes before they are implemented. The assessment reports must include specific and actionable security safeguards that can be implemented in the form of technologies as well as operational processes.

A post-assessment should then be performed after the program implementation to confirm whether the safeguards recommended in previously in pre-assessment have not only been implemented but also operationalized effectively. The assessment report should also clearly state expectations or requirements relative to security and ongoing ownership of technology owners or data custodians and clinical or business process owners.

Both these assessments should provide assurance that interoperability programs are “secure by design” in terms of their technology and process architecture as well as ongoing operations.

In our view and experience, such assessments often require specialist security skillsets in certain areas.  Infosec leadership may need to staff the project/program with required expertise in various areas including  Identity and Access Management, Security Architecture, Security Operations etc.

  • Sensitive Data – Streamlining flows and minimization

The pre and post assessments (covered in the previous section) should provide infosec teams with a good idea of sensitive data flows and repositories. The team should identify opportunities to streamline the flows wherever possible as well as identify unnecessary data repositories that could be retired and decommissioned in the interest of data minimization. The teams may need to work with relevant business and technology owners to establish specific objectives and timelines for streamlining of flows and minimization of data repositories.

Special attention may need to be paid to flows and potential proliferation of unstructured data. Personnel or teams with specialist security skillsets in data protection or loss prevention may need to be involved in design and implementation of appropriate security solutions.

  • Application Security

Interoperability programs at most organizations will involve implementation of new solutions as well as updates to existing ones. New application or data interfaces will need to be implemented in the form of FHIR APIs for external interfaces and a combination of FHIR based or other traditional methods for internal interfaces.

Application security teams will need to be involved in design and testing of these interfaces before they are released for production use. While security of both (internal and external) interfaces is important, the external interfaces will likely need special focus in terms of frequent security testing and vulnerability management.

  • Third Party Risk Management(TPRM)

Third party or vendor risk assessments can be notorious for their compliance style approaches as opposed to performing an effective exercise in assessment and management of security or privacy risks posed by vendors. Healthcare organizations (both customers and vendors) will need to make meaningful changes in this regard to their TPRM programs.

Interoperability initiatives at most organizations will likely involve vendors or third parties that may provide solutions or business process support.

Appropriate security validation of these third parties and their services must be performed upon onboarding of each vendor. Beyond onboarding, TPRM programs will need to perform risk -based due diligence assessments of the third parties.

Special attention must be paid to non-standard implementations of OAuth2 or OpenIDConnect in vendor solutions as these are usually susceptible to security vulnerabilities in due course of time.

Just as in the case of “Secure By Design” assessments discussed in section 3 above, TPRM teams should involve specialist personnel wherever necessary.

  • Incident Detection and Response 

Healthcare infosec programs should view their organizations’ interoperability initiative as an opportunity to enhance capabilities for detection of potential security incidents in their systems that store and process EHI, including the interfaces and APIs.

Such capabilities must cover infrastructure, data repositories as well as applications in equal measure.  The EHI data flows and inventory (see section 2) should be useful in identifying these components conclusively.

Further, detection use cases should cover insider threats in addition to external threat actors.

To conclude, Healthcare interoperability could be a challenge to information security given the new paradigm. However, leading infosec programs are likely to view the initiative as an opportunity to make meaningful enhancements in mitigating security gaps that might currently exist. Such programs would also likely want to be seen as business enablers and assisting with the design and implementation of security requirements in support of their transformation initiatives.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Kamal Govindaswamy

Posted on

October 15, 2020