HIPAA-compliant cloud and healthcare cloud migration
Digital Scientists hosts the healthcare software we build on AWS, Microsoft Azure or Google Cloud, in your own cloud account where possible, under your BAA with the cloud provider. We build each environment as code from HIPAA-eligible services: encryption, audit logging, threat detection and monitoring. We've run NeverAlone, a virtual care platform for 30,000 patients across six states, on AWS 24/7 since March 2021. When your data sits on-premises, we move it in stages and keep the old system running until the new one is proven. Tell us what you run today, and we'll talk it over.
Updated
NeverAlone live on AWS, 24/7
Patients across six states on NeverAlone
Signed before any PHI moves or access is granted
Security plan mapping, plus a security addendum per client
Does Digital Scientists run healthcare software in the cloud today?
Yes. We've run NeverAlone, CommuniCare's virtual care platform, on AWS 24/7 since March 2021. We host the software we build. We don't sell generic web hosting.
NeverAlone began as a 90-day MVP. It now supports 30,000 patients across six states, with 100,000+ calls a year. Video runs on AWS Chime, emergency calls route through Bandwidth E911, and resident data comes from PointClickCare and Netsmart (GEHRIMED). Every one of those flows carries PHI, so the hosting has to hold up every hour of every day.
Guardian is the second example. Vital signs stream from operating room monitors into an AWS environment we built with Terraform: EKS, encrypted Aurora PostgreSQL, CloudFront, WAF, GuardDuty and CloudTrail. The same pattern sits under every healthcare platform we host. For the controls behind it, see healthcare security and PHI protection. For who runs it day to day, see platform operations.
NeverAlone on AWS, run by the team that built it
Calls a year on the platform
Guardian transcription accuracy, on AWS
What does a HIPAA-ready AWS environment include?
A signed BAA, HIPAA-eligible services only, encryption everywhere, audit logs on every action and alerts a person answers. We build all of it as code, so every environment matches and every change is reviewed.
No cloud is HIPAA compliant out of the box. AWS signs a BAA and publishes a list of HIPAA-eligible services. The configuration is on you and us. That's the shared responsibility model: AWS secures the data centers and hardware, and we configure everything built on top.
Here's the baseline we start from. Your Blueprint adjusts it for your workload, your data and your security team's requirements.
The baseline for a HIPAA-ready AWS environment
| Control | What it does | AWS service or tool |
|---|---|---|
| BAA and eligible services | Puts the account under a BAA. Only HIPAA-eligible services touch PHI. | AWS Artifact, AWS Organizations |
| Network isolation | Databases and app servers sit in private subnets. Nothing holding PHI faces the internet. | Amazon VPC, security groups |
| Encryption at rest | Databases, volumes and file storage are encrypted with managed keys. | AWS KMS, Aurora and RDS encryption, EBS encryption, S3 encryption |
| Encryption in transit | TLS on every connection, inside and outside the network. | AWS Certificate Manager, CloudFront, load balancers |
| Edge protection | Filters malicious web traffic before it reaches the app. | AWS WAF, CloudFront |
| Audit logging | Records every API call and every change to the environment. | AWS CloudTrail, S3 access logging |
| Threat detection | Flags unusual access and known attack patterns. | Amazon GuardDuty |
| Access control | Least-privilege roles, MFA, no shared logins. | AWS IAM |
| Secrets | Keeps passwords and API keys out of code. | AWS Secrets Manager, Systems Manager Parameter Store |
| Backups | Automated, encrypted database backups you can restore from. | Aurora automated backups and snapshots |
| Infrastructure as code | Every environment built from reviewed code, so staging matches production. | Terraform, Terragrunt |
| Cost alerts | Warns before spend crosses a threshold. | AWS Budgets |
HIPAA eligibility is set service by service. We check AWS's current list before a new service touches PHI.
Can you build on Azure or Google Cloud instead of AWS?
Yes. If your organization has standardized on Microsoft Azure or Google Cloud, we build there. Each provider signs a BAA and lists its HIPAA-eligible services, and we build the same baseline from those services, as code, in your account.
The same controls on each cloud
| Control | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| Encryption keys | AWS KMS | Azure Key Vault | Cloud KMS |
| Network isolation | Amazon VPC, security groups | Virtual Network, network security groups | VPC, firewall rules |
| Audit logging | AWS CloudTrail | Azure Monitor activity logs | Cloud Audit Logs |
| Threat detection | Amazon GuardDuty | Microsoft Defender for Cloud | Security Command Center |
| Access control | AWS IAM | Microsoft Entra ID, Azure RBAC | Cloud IAM |
| Secrets | AWS Secrets Manager | Azure Key Vault | Secret Manager |
HIPAA eligibility is set service by service on every cloud. We check the provider's current list before a new service touches PHI.
Who owns the cloud account?
You do, where possible. We build in your AWS account, under your BAA with AWS, and work in it through roles you grant and can revoke.
Owning the account means you own the data, the logs and the bill from day one. If you change partners or bring the platform in-house, nothing has to move. It also keeps AI inside your walls: on new builds, models run through Amazon Bedrock in your own account, covered by the same BAA.
Your account, your BAA
You accept the AWS BAA for your account. We sign our own BAA with you before we touch PHI.
Access you control
Our engineers work through least-privilege roles with MFA. Every action lands in your CloudTrail log.
Code in your repositories
The application code and the Terraform that builds the environment live in your GitHub organization.
When we start in ours
Some clients ask us to hold the account at first. We run it under our BAA with AWS and move it to you when you're ready, as part of build-operate-transfer.
How do you move a healthcare system from on-prem to the cloud?
In stages. Nobody likes a big-bang cutover, so we connect, copy and validate first, run old and new side by side, and switch users over once the numbers match.
We did this for CommuniCare's risk adjustment work. The data sat in on-premises Microsoft SQL Server databases. We built a secure pipeline over a VPN tunnel into AWS, mapped and normalized 7 tables across 3 databases, and validated data quality before any model used it. That data foundation now supports $10M+ in RAF improvement at 90%+ accuracy across 20K+ patients. See the risk adjustment case study.
Healthcare cloud migration, step by step
| Step | What happens | What you get |
|---|---|---|
| 1. Map | Inventory systems, databases, interfaces and users. Mark where PHI lives and where it flows. | A migration plan and a PHI data-flow diagram |
| 2. Land | Sign the BAA. Build the AWS environment as code from the baseline above. | An empty, secured environment in your account |
| 3. Connect | Open a secure link between your network and AWS, usually a VPN tunnel. | Encrypted data movement with no public exposure |
| 4. Copy and validate | Copy the data, map and normalize it, then check counts and quality against the source. | Proof the data matches before anyone relies on it |
| 5. Run in parallel | Keep the on-prem system as the source of truth while the new one runs. Move users in groups. | A working fallback the whole time |
| 6. Switch and retire | Cut over once results match. Keep a rollback path, then retire the old system on an agreed date. | One system, with the old one archived |
Who runs the environment after launch?
We do, for the platforms we build. The engineers who built the environment monitor it, patch it and answer the alerts. Your IT team or MSP keeps L1 and the desktop.
Hosting is only half the job. Certificates expire, vendors change, dependencies pick up vulnerabilities and costs creep. We handle that as routine work, with a monthly health report so you see what changed.
We support only platforms we built, with L2 and L3 as the usual split. When you want to run it yourself, build-operate-transfer hands over the account, the code, the runbooks and the documentation. The full model is on healthcare platform operations.
Monitoring
CloudWatch alarms, error tracking, on-call paging
Releases
GitHub Actions, Argo CD on EKS, rollback
Security updates
OS, container and dependency patches
Audit and threats
CloudTrail logs, GuardDuty findings
Cost
AWS Budgets threshold alerts
Support
L2 and L3 from the engineers who built it
Where should we start with HIPAA cloud hosting?
Start from what you have today. These are the common starting points, not rules.
Whichever path fits, the BAA comes first, and your security team gets our security plan mapped to NIST CSF 2.0 and a security addendum for your project. We don't hold SOC 2 or HITRUST, and we'll say so in the first conversation.
You're building something new
Hosting is designed in the Blueprint and built from the first sprint. See healthcare product development.
Your system runs on-premises
Start with a Blueprint. It maps the system, the data and the PHI flows, and gives you a staged migration plan.
Someone else built it and it's already in the cloud
We don't take over hosting of another team's code as-is. A Blueprint tells you what to harden or rebuild, and we run what we build.
You want it in-house eventually
Plan the transfer up front: what moves, in what order, and who is on call during the handover.
Healthcare platforms we host and run
NeverAlone · CommuniCare
On AWS 24/7 since March 2021
A virtual care platform for 30,000 patients across six states, with 100,000+ calls a year on AWS Chime video. We built it and we still run it.
See the work
Guardian · Vigilant Medical
99.9% transcription accuracy
Vital signs streamed from operating room monitors into an AWS environment built in Terraform, on EKS and encrypted Aurora PostgreSQL, hardened with WAF, GuardDuty and CloudTrail.
See the work
Risk adjustment · CommuniCare
On-prem data moved to AWS
A secure VPN pipeline from on-premises SQL Server databases into AWS, validated before use. It supports $10M+ in RAF improvement at 90%+ accuracy.
See the workTrusted by healthcare leaders.
“I have worked with many technology teams during my career, and Digital Scientists is one of the best. They take the time to understand the customers' needs, deliver innovative solutions, are always professional, and work with your team as a true partner to achieve success.”
Amy Severino
Chief Innovation Officer, NeverAlone
“By applying a robust machine learning model to our app, DS helped us create a scalable and accurate solution to improve the operating room experience for the anesthesia team and the patient. They are true collaborators.”
Justin Scott, M.D., FASA
CEO, Vigilant Medical Solutions
Related healthcare services
Healthcare platform operations
We run the platforms we build, 24/7, with L2 and L3 support.
Healthcare platform operations →Healthcare security and PHI protection
BAA first, a NIST CSF 2.0 security plan and a diligence packet.
Healthcare security and PHI protection →Healthcare integrations
EHR, lab, payer and telephony connections that stay up.
Healthcare integrations →Healthcare data engineering
Pipelines, warehouses and patient matching across sources.
Healthcare data engineering →Monitoring and ops
DevOps and site reliability engineering for live systems.
Monitoring and ops →Blueprint
Four to six weeks to map what you run and plan what comes next.
Blueprint →Latest thinking on HIPAA and the cloud
Questions about HIPAA cloud hosting and migration
Do you host our platform, or do we own the cloud account?
Where possible, you own it. Digital Scientists builds in your AWS account, under your BAA with AWS, and our engineers work through least-privilege roles you control. The code and the Terraform that builds the environment live in your repositories. If you'd rather we hold the account at first, we run it under our BAA with AWS and transfer it to you when you're ready.
Is AWS HIPAA compliant?
Not on its own. No cloud is. AWS signs a BAA and publishes a list of HIPAA-eligible services. Under the shared responsibility model, AWS secures the infrastructure, and the customer configures what runs on it: encryption, access, logging and monitoring. We build only on HIPAA-eligible services for anything that touches PHI, and we configure the controls as code.
How do you migrate without downtime?
We run old and new side by side. We connect your network to AWS, copy and validate the data against the source, then move users in groups while the on-prem system stays the source of truth. We switch over once results match and keep a rollback path. If the final switch needs a short window, we agree it with you in advance and schedule it when clinical use is lowest.
Do you work on Azure or Google Cloud?
Yes. Most of our healthcare production work runs on AWS, and we build on Microsoft Azure and Google Cloud too. We built data pipelines on Google Cloud for Congruity Health. Microsoft and Google both sign a BAA and publish which services are HIPAA eligible, so we build the same baseline there: encryption, audit logging, threat detection, least-privilege access and monitoring, from services covered by that provider's BAA.
Do you hold SOC 2 or HITRUST?
No. We don't hold SOC 2 or HITRUST. We sign a BAA with every covered entity before any PHI moves, run a security plan mapped to NIST CSF 2.0, and write a security addendum for each client's project. Your security team can put questions to our engineers directly.
Will you host a platform someone else built?
Not as-is. We host and support only platforms we built, because we can't stand behind code we don't know. For a system someone else built, start with a Blueprint. If the work goes ahead, we harden or rebuild what needs it, then host and run what we've built.
Talk it over
Tell us what you are trying to do. A senior person from our Atlanta team replies within one business day, and you can book a 30-minute call right after you send this.
- We tell you if we're the right fit, and if we're not, who is.
- Most work starts small, so you see how we work before you commit to more.
- We sign a BAA before we touch patient data.