Many healthcare organizations are starting to adopt artificial intelligence (AI) systems to gain deeper insight into operations, patient care, diagnostic imaging, cost savings and so on. However, it can sometimes be daunting to even know where to get started. Many times, you need a clear lighted path to start your journey and embrace AI and machine learning (ML) capabilities rapidly.
One method is using an Azure Healthcare AI blueprint. It’s a shortcut to using Microsoft Azure at low cost and without deep knowledge of cloud computing. Blueprints include resources such as example code, test data, security, and compliance support. The largest advantage of using a blueprint is explicit advice and clear instructions on keeping your solution in compliance. We’re trying to eliminate the mystery, so you don’t have to research it yourself.
Three core areas where the blueprint can help with compliance are cloud provider and client responsibilities, security threats, and regulatory compliance. These three areas can get overlooked at the beginning of any technology project, yet they are important parts of creating healthcare systems. Applying formal discipline to these areas is made easier by using the blueprint to create an AI/ML experiment installation.
Helpful artifacts
The blueprint includes a script to create an AI/ML system, complete with a sample experiment. It also includes several documents to help system implementers keep their installations secure and compliant. These include worksheets, whitepapers, and spreadsheets that will help you ensure system compliance with healthcare regulations and certifications. The artifacts are easily re-purposed for other healthcare-based systems implemented on Azure.
Clarifying responsibilities
When creating any system on a cloud platform, there are two possible owners for any part of the solution, the cloud provider and the customer. It is important to know who is responsible for specific actions, services, and other operational details. Without a clear understanding of this delineation, customers or vendors may find themselves in a difficult situation if an issue arises, like service outages or security breaches. Therefore, it is in everyone’s interest to be clear about the responsibilities of design and operations.
Preventing misunderstandings and setting clear expectations of responsibilities is the goal of the Shared Responsibilities for Cloud Computing document. If you are trying to meet HITRUST certification standards, the HITRUST Customer Responsibilities Matrix spreadsheet identifies exactly what Microsoft and the customer are respectively responsible for managing.
Planning for security threats
Before creating complex systems, it is always advisable to perform a threat assessment. It is a best practice to create a threat assessment model. It helps you to visualize the system and find the points of vulnerability in the proposed architecture. This leads to conversations about where the system may be improved and hardened against attacks.
Microsoft provides a Threat Model Tool enabling architects to identify and mitigate potential security issues early, when they are relatively easy and cost-effective to resolve. The blueprint includes a model to be used with the tool. This comprehensive threat model provides insights into the potential risks of the architecture and how they may be mitigated.
A standard approach to security threat analysis involves identifying the surface area of your system, creating a model of that surface area, identifying potential threats, mitigating them and validating each mitigation, updating the threat model as you proceed. The following diagram highlights the major phases this process.
The figure below shows four stages: diagram, identify, mitigate, and validate.
Figure 1: Security cycle
This process flow provides an iterative and collaborative approach to threat analysis that ultimately helps create a more robust and secure system architecture.
Regulatory compliance
Healthcare systems need to meet regulatory compliance standards. At installation, the blueprint complies with HIPAA and HITRUST requirements. Whitepapers are included to help you understand how to continue to meet these requirements. Let’s examine the whitepapers and other provided artifacts to see how they might help.
HITRUST certification
The Common Security Framework (CSF) from HITRUST is a security standard for healthcare systems. The HITRUST compliance review whitepaper was published to aid in ensuring the healthcare blueprint meets CSF regulations. The whitepaper states:
“This whitepaper constitutes a review of the Blueprint architecture and functionality with respect to HITRUST-certified customer environments, examining how specifically it can satisfy HITRUST CSF security requirements.”
The whitepaper helps organizations plan their cloud implementation and understand how to meet HITRUST CSF compliance.
HIPAA compliance built into the blueprint
Compliance with HIPAA standards is fundamental to any healthcare organization. The blueprint was created with HIPAA in mind, and includes a whitepaper covering the topic in detail.
The HIPAA compliance review whitepaper is similar to the HITRUST whitepaper in its intent, to help organizations reach regulatory compliance. This document guides readers through the architecture, a shared responsibility model and deployment considerations for your solution. Protected healthcare information (PHI), a fundamental practice in well-designed system architectures, is also included in the whitepaper.
Recommended next steps
Use the supporting collateral below to prepare for your installation of the blueprint. The artifacts demonstrate how responsibilities, compliance, and security are established and how you can maintain them going forward.
Prepare for installation and ongoing maintenance with the following documents.
- The Azure blueprint for AI Solution Guide.
- Shared Responsibilities for Cloud Computing.
- HITRUST customer responsibility matrix.
- Threat model.
- HITRUST health data and AI review whitepaper.
- HIPAA health data and AI review.
Collaboration
What other artifacts or considerations do you think would be helpful when putting healthcare systems into production? Your comments and recommendations are welcome below. I regularly post on technology in healthcare topics. Reach out and connect with me on LinkedIn or Twitter.