This Guidance helps life sciences customers to gain a comprehensive understanding of the patient care journey through a Patient Outcome Predictor (POP) application that applies artificial intelligence and machine learning (AI/ML) to de-identified, longitudinal patient data. POP helps to uncover unique patterns in target patients’ medical history and unleashes insights about patient outcome patterns such as disease progression to support early identification of eligible patients for treatments, data-driven care management decisions and timely interventions. Patient journey predictions that are made by the algorithm can be linked back to providers so that life sciences organization can use POP for improving their customer segmentation & targeting with deciphered real world patient journey insights to enable successful product commercialization.
Architecture Diagram
Step 1
Access POP and input patient health data such as medical records, insurance claims, lab reports, and doctor’s notes through AWS Transit Gateway.
Step 2
Amazon HealthLake, a Health Insurance Portability and Accountability Act (HIPAA)-eligible service, ingests customer health data. HealthLake transforms customer health data to make it ready for querying and ML processing.
Step 3
A series of AWS Step Functions sends customer datasets through Amazon Macie, a service that discovers and protects sensitive data.
Step 4
Amazon Simple Storage Service (Amazon S3) stores customer data from HealthLake and Macie. AWS Glue then processes the data by transforming and preparing it for ingestion as training data. The data is then ready for a custom-trained Amazon SageMaker model.
Step 5
Custom SageMaker models are trained to predict patient outcomes, such as disease progression for potentially undiagnosed patients and hospital readmission probability. SageMaker model endpoints are then created for model inference.
Step 6
Access the web client frontend through Amazon CloudFront and AWS WAF to perform model inference.
Step 7
When you want to perform model inference from a previously trained model, an AWS Lambda trigger lets you pick a SageMaker model endpoint to perform predictions.
Step 8
When you want to explore model explainability, a Lambda trigger lets you look at potential bias in your training data and trained models through Amazon SageMaker Clarify.
Step 9
To support operational and cost monitoring, Amazon CloudWatch, AWS Config, and AWS CloudTrail record all Amazon Virtual Private Cloud (VPC) flow logs, API metrics, and other AWS resource usage.
Step 1
Access POP and input patient health data such as medical records, insurance claims, lab reports, and doctor’s notes through AWS Transit Gateway.
Step 2
Amazon HealthLake, a Health Insurance Portability and Accountability Act (HIPAA)-eligible service, ingests customer health data. HealthLake transforms customer health data to make it ready for querying and ML processing.
Step 3
A series of AWS Step Functions sends customer datasets through Amazon Macie, a service that discovers and protects sensitive data.
Step 4
Amazon Simple Storage Service (Amazon S3) stores customer data from HealthLake and Macie. AWS Glue then processes the data by transforming and preparing it for ingestion as training data. The data is then ready for a custom-trained Amazon SageMaker model.
Step 5
Custom SageMaker models are trained to predict patient outcomes, such as disease progression for potentially undiagnosed patients and hospital readmission probability. SageMaker model endpoints are then created for model inference.
Step 6
Access the web client frontend through Amazon CloudFront and AWS WAF to perform model inference.
Step 7
When you want to perform model inference from a previously trained model, an AWS Lambda trigger lets you pick a SageMaker model endpoint to perform predictions.
Step 8
When you want to explore model explainability, a Lambda trigger lets you look at potential bias in your training data and trained models through Amazon SageMaker Clarify.
Step 9
To support operational and cost monitoring, Amazon CloudWatch, AWS Config, and AWS CloudTrail record all Amazon Virtual Private Cloud (VPC) flow logs, API metrics, and other AWS resource usage.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
HealthLake extracts meaning from unstructured data with NLP and supports interoperable standards such as the Fast Healthcare Interoperability Resources (FHIR) format. This provides broad extensibility across data sources that are relevant for healthcare and life science users.
-
SecurityRead the Security whitepaper
CloudFront and AWS WAF help ensure secure access to the web app using only allow-listed IP sets. Macie automates the discovery of potentially sensitive data to ensure data privacy and security. All roles are defined with least privilege access, and all communications between services stay within the customer account. The infrastructure is based in a VPC where API and ML workloads are executed in private subnets to prevent the risk of intrusion. All S3 buckets encrypt data, are private, and block public access. The data catalog in AWS Glue has encryption enabled, and all data written to Amazon S3 from SageMaker is encrypted.
-
ReliabilityRead the Reliability whitepaper
Multiple services help to enable a reliable architecture for this Guidance. For example, CloudWatch alarms track API events in CloudTrail, and backend Lambda functions log errors to log streams. These services help you stay aware of potential issues so you can fix them as they arise. Additionally, SageMaker endpoints can be configured to scale for increased workload demand.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
By using serverless technologies, you provision the exact amount of resources you use. Each AWS Glue job will provision a Spark cluster on demand to transform data and de-provision the resources when you’re done.
-
Cost OptimizationRead the Cost Optimization whitepaper
Lambda will automatically de-provision resources when you no longer need them, so that you don’t pay for idle infrastructure. From a model experimentation perspective, you can start and stop SageMaker notebook environments on an as-needed basis.
-
SustainabilityRead the Sustainability whitepaper
You can minimize the environmental impact of backend services by using fully managed services, dynamic scaling within all serverless services, and Lambda for custom functionality. The only component in this architecture that you need to maintain and monitor manually are SageMaker notebooks, which you must start and stop during model experimentation. Aside from that service, all other components in the architecture can be automated, reducing the number of resources you need.
Implementation Resources
A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Related Content
A Shifting Paradigm: Deciphering Patient Journeys with the Power of AI/ML
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.