Wellsheet Sees Efficiency Grow With Amazon ECS Powering EHR Application 

Cloud303 Helps Scale EHR Application While Staying HIPAA-compliant 

 Migration  Modernization  HIPAA



Summary

Wellsheet is an intra-electronic health record (EHR) platform that prioritizes clinical content within physician workflow with machine learning.

Its AI-powered workflow is intuitive and integrated with Epic and Cerner to reduce a clinician’s time in the EHR, lessening clinician burnout and improving the quality of patient care.

Wellsheet is being used by clinicians on the frontline battling COVID-19 to provide real-time diagnostic result alerts; visibility of all patients being tested or confirmed with COVID-19 by location, by attending physician, and by associated isolation status; and reduced exposure through shared workspaces.

The application was hosted in Heroku, which is a container-based cloud platform that offers Platform as a Service (Paas). However, as the application grew in usage and popularity, Wellsheet began to realize Heroku was not the right fit anymore due to certain significant limitations.

Among the biggest drawbacks Wellsheet faced with Heroku were the high costs and the inability to access the underlying code and infrastructure.


Industries:
Local Government
Regions: 
NALADEMEAAPAC
AWS Segment: 
EnterpriseSMB


Our Customer

Wellsheet is an intra-electronic health record (EHR), speciality-agnostic cloud platform that prioritizes clinical content within physician workflow with machine learning. Wellsheet provides a predictive clinical workflow platform that uses the Fast Healthcare Interoperability Resources (FHIR) API standards to work within an existing EHR to surface the most relevant content for clinicians in a view that is contextualized and prioritized for their needs.

The Challenge


Cost

Wellsheet is a demanding EHR application. It requires changes to its backend infrastructure to be made in tandem with the growth of the platform. While Heroku fit the bill in the beginning, costs began to rise as time went on. This was mainly due to the way Heroku customers are charged based on the number and size of “Dynos” used. Dynos is a Heroku-proprietary Linux container where application processes are run. These Dynos can add up and cost a fortune in the long run, especially for an app as big as Wellsheet's.

Rigidity

As the Wellsheet platform grew with added intricacies to its infrastructure, Heroku’s fully-managed nature was holding them back. While it was convenient in the beginning, Wellsheet engineers eventually found it cumbersome because they could not tailor their back-end infrastructure according to the application’s needs due to Heroku automatically provisioning resources such as storage and database for the application. This proved to be a stumbling block in Wellsheet’s freedom to scale the application.

Scalability

Wellsheet was also desperate to hasten their exit from the Heroku ecosystem because of how tightly coupled the entire architecture was set up in Heroku. This proved to be a major disadvantage of being hosted in Heroku – it is not primed to support the complexities that microservices entail. The technological possibilities in the healthcare industry are endless, and Wellsheet sought a system that could cater to these possibilities. This meant that they needed to break out of their existing monolith on Heroku and dive into microservices, which would allow them to scale to their needs .

Why Wellsheet Chose AWS?

AWS was a great solution for Wellsheet for a few reasons. First, as their data needs were initially relatively modest but set to scale quickly, moving to an RDS Aurora database would be an ideal solution due to its unparalleled ability to scale in a number of ways and the fact that it would allow them to only pay for the capacity they need. Aurora’s flexibility and robust feature set would allow Wellsheet to easily adapt as their business grows. This can also be a huge money saver, as clients only pay for the capacity they need. Also, since they required flexibility, ECS was an ideal service choice. Containers could be deployed on a single EC2 instance and both the containers and instances could be scaled when the need arose.

Why Wellsheet Chose Cloud303?

Cloud303's reputation as the number one AWS Well-Architected Review partner boded well for Wellsheet's aspiration to roll out the EHR application, which had to be HIPAA-compliant, on AWS.

Cloud303 also turned out to be a great fit for Wellsheet because of their extensive experience with Health and Life Science companies. Cloud303’s experience also means that their engineers are extremely knowledgeable on what it takes to ensure HIPAA compliance in the cloud, including how to effectively keep track of the data needed for HIPAA compliance on the AWS account level as well as data and logs from within the application itself - all of which were defined and discusses extensively during the Well-Architect Review during the Assess Phase of the migration.

 
 
      Phil Supinski     Sujaiy Shivakumar
CEO/Solutions Architect      CTO/Solutions Architect

AWS Services Employed:
 EC2 ECS VPC

Cloud303's Solution


After migrating the workload from Heroku, the application was decoupled into microservices using Docker. Wellsheet, which used to be hosted in a single container in Heroku, could now have its backend functions deployed into multiple containers in Amazon Elastic Container Services (ECS) on EC2, using the compute-optimized c5.2xlarge instance type. Using CloudFormation, 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 in a three-tier VPC. IaC drift detection, built in-house, was configured to ensure that all infrastructure deployments and changes are standardized and made exclusively via CloudFormation.

The pipeline was orchestrated using CircleCI as the build server integrated with GitHub as the version control system. Cloud303 built the Docker image on CircleCI, pushed the Docker image to an Amazon Elastic Container Registry (ECR), and then deployed it to ECS on EC2. 

Various forms of testing, such as unit, integration and UI layer tests, for all environments (dev, stage, prod) were implemented for the entire CI process, making software delivery smoother, faster and more predictable.

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. Development and testing are isolated into stages to detect problems earlier, and feedback loops are faster, allowing for more efficient debugging.

ECS cluster auto scaling (CAS) was enabled to provide more control over the scaling of the EC2 instances within the cluster. The ECS Service was configured to send metrics to CloudWatch, which triggers an alarm to add more tasks to the ECS Service, with the capacity provider set up to target the autoscaling group.

As part of HIPAA compliance, the entire infrastructure was encrypted at rest and in transit. Encryption was managed with KMS-CMK, including automatic annual key rotation - a HIPAA requirement. Wellsheet also needed to access data from their partner hospitals in a secure fashion, so Cloud303 deployed Transit Gateway into a separate VPC, along with a Network Load Balancer, to ensure data remained in a private network and remained HIPAA-compliant.


Results/Benefits

With AWS, Wellsheet have much more control over the resources they’re utilizing, which was not possible on a managed service like Heroku. They can easily manage their own infrastructure and security levels as needed. Their monthly cloud spend was slashed by half, reducing their monthly bill from about $30,000 to $15,000. The development phase saw c5.2xlarge instances spanning two AZs being leveraged to power the ECS containers as a proof of concept (PoC) in the Dev account, with autoscaling configured with a step scaling policy invoked by CloudWatch metrics - with the containers set up to scale horizontally if CPU utilization exceeds 80% and to scale down back down if CPU utilization drops below 60%. After three months of monitoring, it was decided the workload would be optimized in the production environment by scaling the workload according to demand, averaging about 15-17 instances. This was achieved by using AWS native right-sizing and cost-optimization tools. 


AWS Programs/Funding Used:
Partner Opportunity Acceleration Funding"MAP" Migration Acceleration Program