Patients log in and enter data into Taproot's Electronic Data Capture (EDC) and Electronic Health Records (EHR) application, which is hosted in containers powered by Amazon Elastic Compute Cloud (EC2) instances on Amazon Elastic Container Service (ECS). All the cancer/clinical research data is stored in a three-pronged MongoDB cluster hosted on EC2 instances, with replica sets spanning multi-AZs. Route 53 is used to manage Taproot's DNS. Taproot's CICD pipeline is orchestrated by AWS CodePipeline and AWS CodeBuild, with the codebase being version controlled using GitHub. AWS Config rules are configured according to AWS' Operational Best Practices for HIPAA Security. Amazon CloudWatch alarms and AWS CloudTrail logs storage are also configured to be HIPAA-compliant.
Cloud303 scoped out the project and optimized the EHR platform by configuring compute-optimized c5.2xlarge EC2 instances to power the Docker containers running in Amazon ECS. The workload was spread in private subnets over multiple availability zones in an Auto Scaling Group behind an Application Load Balancer in the North Virginia region for high availability.
The development pipeline was orchestrated using AWS CodePipeline, with AWS CodeBuild and AWS CodeCommit which integrated perfectly with GitHub as the version control system. Cloud303 built the Docker image and pushed this image to an Amazon Elastic Container Registry (ECR), and then deployed it to ECS on EC2.
All testing of the application's backend was conducted in a development environment. Topic branches based off the main branch were used for feature and bug fixes. These feature branches isolate work in progress from the completed work in the main branch.
With autoscaling configured with a step scaling policy triggered by Amazon CloudWatch metrics, the ECS containers were powered by c5.2xlarge instances spread across two AZs during the development phase as a proof of concept (PoC) in the Dev account. The containers were set up to scale horizontally if CPU utilization exceeds 80%, and to scale in if CPU utilization falls below 60%. Following three months of monitoring, it was decided to scale the workload in the production environment to match demand, with the minimum and desired number of instances set at five and the maximum number set to twelve. Utilizing native right-sizing and cost-optimization capabilities from AWS, this was accomplished.
To achieve the best possible outcome in this regard, ECS cluster auto scaling (CAS) was enabled to provide more control over the scaling of the EC2 instances within the cluster, with the ECS Service configured to send metrics to CloudWatch, which triggers an alarm to add more tasks in the ECS Service, with the capacity provider set up to target the autoscaling group, using the CapacityProviderReservation metric.
The entire infrastructure was encrypted at-rest and in-transit using AWS Key Mangement service (KMS) with automated annual key rotation in order to comply with HIPAA regulations.