Cloud Computing in Healthcare: Architecture, Compliance, Cost, and Migration Plan

Cloud computing in healthcare is useful when it gives a provider, payer, or digital health company secure, governed access to clinical, operational, and patient-facing data without overbuilding local infrastructure. The decision is less "move everything to cloud" and more "which workloads belong in SaaS, managed cloud, private cloud, or hybrid architecture."

A practical cloud plan starts with workload fit, compliance responsibility, integration depth, cost controls, and migration risk. That is the difference between a controlled modernization program and a lift-and-shift project that moves existing problems to a new hosting model.

Where Cloud Computing in Healthcare Actually Helps

Healthcare cloud work pays off when it removes bottlenecks around data access, patient communication, scaling, resilience, or reporting. Start by mapping the workflows that suffer from slow releases, limited storage, poor integration, manual exports, or weak recovery plans. Those workloads often benefit before core clinical systems move.

Common areas include:

• Patient portals and mobile apps. Cloud services can support registration, appointment requests, secure messages, payments, care plan access, notifications, and document delivery. The main design work is identity, consent, data exposure, and integration with source systems.
• Telehealth and virtual care. Video visits, intake forms, chat, scheduling, and post-visit follow-up often fit managed cloud architecture because demand can vary by day and service line. Patient experience depends on latency, uptime, and clean integration with clinical workflows.
• Imaging and lab data access. Cloud storage and exchange layers can help with archiving, metadata search, routing, and controlled sharing. Large files, network limits, data retention, and specialist workflows need careful design.
• Integration layers. APIs, event queues, and data pipelines can reduce brittle point-to-point connections between EHRs, billing tools, patient apps, labs, pharmacies, devices, and analytics systems.
• Analytics and AI-ready data. Cloud data stores can support reporting, cohort analysis, operational dashboards, and future AI features when the data model, permissions, lineage, and quality controls are planned early. If AI is part of the roadmap, AI integration services should be considered with governance from the start.
• Remote monitoring. Wearables and home devices can generate frequent event data that requires ingestion, filtering, alerts, dashboards, and long-term storage.
• Backups and disaster recovery. Cloud backup, immutable storage, off-region recovery, and restore testing can reduce downtime risk when designed around recovery time and recovery point targets.

Not every workload needs the same model. An EHR may remain vendor-hosted, while a patient app runs on managed cloud, an imaging archive uses hybrid storage, and device-facing components keep some processing local.

Cloud Models and Workloads to Match

The right cloud model depends on data sensitivity, latency, customization, vendor lock-in, and how much operational control your team can support. Most healthcare organizations end up with a mix: SaaS for commodity workflows, managed cloud for differentiated platforms, and local or edge systems where devices, latency, or regulations require it.

Healthcare Cloud Model Decision Matrix

A workload decision should include the care setting, user type, data class, uptime need, integration path, and operating model. The wrong model often creates hidden cost. For example, a fully custom app for a standard back-office process may waste budget, while a SaaS platform for a differentiated care workflow may force staff into workarounds.

Compliance, Security, and Shared Responsibility

Cloud compliance is not transferred to the vendor. It is shared between the healthcare organization, software team, and cloud service provider, with each party owning different controls. The practical job is to define where ePHI lives, who can access it, how activity is logged, and how incidents are handled.

The HHS HIPAA cloud computing guidance states that cloud service providers can be business associates when they create, receive, maintain, or transmit ePHI on behalf of a covered entity or another business associate. If ePHI is in scope, a Business Associate Agreement is part of the operating model, not a procurement formality.

Security planning should cover:

• ePHI boundaries. Identify where ePHI is stored, processed, transmitted, logged, cached, exported, backed up, and exposed through support tools. Logs, analytics events, file names, screenshots, notifications, and webhook payloads can all create accidental ePHI exposure.
• Access controls. Use role-based or attribute-based access, least privilege, SSO, MFA, privileged access review, and clear break-glass procedures for urgent operational needs.
• Encryption and secret storage. Use encryption in transit and at rest, managed secrets, controlled encryption keys, rotation rules, and secure handling for service accounts.
• Audit logs. Capture user access, admin actions, data exports, permission changes, failed login patterns, configuration changes, and integration activity. Logs should be retained long enough to support investigations and audits.
• BAA and vendor review. Review incident notice terms, subcontractors, data return or deletion, support access, audit rights, security documentation, and change notification.
• Data retention. Define how long clinical, operational, audit, backup, and analytics data is retained, and how deletion requests or legal holds are handled.
• Backups and recovery. Use backup isolation, restore testing, ransomware recovery procedures, and documented recovery time and recovery point goals.
• Breach response. Prepare a response runbook, contact list, evidence preservation process, decision tree, and communication plan before an incident occurs.

The HHS Healthcare and Public Health Sector Cybersecurity Performance Goals provide a practical control set for healthcare environments, including MFA, vulnerability management, email security, incident planning, backups and recovery, and asset inventory. These are not only infrastructure tasks. They affect product design, onboarding, support, vendor access, release management, and monitoring.

Migration Plan: From Inventory to Production

A safe migration starts with inventory and risk, then moves through controlled pilots before production cutover. The goal is to protect care continuity while proving identity, data flow, audit trails, rollback, and cost behavior in a limited scope. Avoid starting with a broad move of every database and service.

Use a phased plan:

1. Workflow and data inventory. List systems, owners, users, workflows, data classes, integrations, reports, storage locations, backup methods, and downtime tolerance. Include shadow exports and manual spreadsheets because they often contain ePHI.
2. Workload classification. Group workloads by SaaS fit, managed cloud fit, private cloud need, hybrid dependency, or local requirement. Tag each workload by sensitivity, latency, integration depth, compliance burden, and business priority.
3. Compliance model. Define ePHI boundaries, BAA requirements, identity model, retention rules, encryption approach, audit logging, support access, and incident response ownership.
4. Migration pilot. Choose a limited workload with real integrations but controlled blast radius. Prove provisioning, CI/CD, monitoring, access review, backup, restore, rollback, and cost reporting.
5. Integration build. Implement APIs, queues, event processing, file exchange, terminology mapping, authentication, and monitoring around EHR, lab, imaging, billing, device, or third-party systems.
6. Testing and validation. Test security, performance, failover, restore, audit logs, data reconciliation, user roles, error handling, and clinical workflow impact. If the platform connects with certified health IT, review the ONC HTI-1 final rule overview with compliance stakeholders.
7. Cutover. Plan migration windows, freeze periods, data sync, user communication, support coverage, rollback triggers, and post-release checks.
8. Monitoring and FinOps. Track uptime, latency, errors, failed jobs, backup status, audit events, spend anomalies, idle resources, reserved capacity, and storage growth.

A structured cloud migration plan is especially important when the product spans mobile, clinical web portals, devices, and data pipelines.

Attract Group's RAE Health work is a useful example of this architecture pattern. The engagement ran 24+ months in a $200,000+ budget band and covered a mobile app, a web clinical portal, wearable event data, calendar and statistics features, and caregiver/provider visibility through RAE Connect.

The backend and architecture stack used AWS S3, Lambda, DynamoDB, ECS, RDS, Cognito, SQS, Jenkins, and Terraform. This is the type of planning healthcare cloud projects need: identity, ingestion, storage, queues, infrastructure provisioning, clinical portal access, and operational visibility designed together. It should not be treated as a simple hosting task.

Cost and Timeline Planning

Cloud migration cost depends less on server count than on data quality, integrations, validation, security review, and uptime constraints. Budget planning should separate hardening, single-product migration, and enterprise programs. Treat the ranges below as planning bands for discovery, architecture, engineering, testing, and release support.

Planning ranges:

• Small compliance-ready migration or cloud hardening: about $25k-$80k and 6-12 weeks.
• Patient-facing platform or telemedicine module on managed cloud: about $80k-$250k and 3-6 months.
• Enterprise multi-system migration, analytics platform, or EHR-adjacent integration layer: often $250k+ and 6-12+ months.

What moves the range:

• Number and quality of integrations
• Data cleanup, mapping, and reconciliation
• Identity and access model complexity
• Uptime, failover, and rollback requirements
• Security architecture and vendor review depth
• Audit trail requirements
• Data migration volume and migration windows
• Validation, clinical workflow testing, and release support
• Need for infrastructure automation, monitoring, and FinOps reporting

Cost control should be designed into the architecture. Managed services can reduce operations effort, but they still need limits, tagging, budgets, log retention policies, autoscaling rules, storage lifecycle rules, and regular review. Without FinOps discipline, a technically sound cloud environment can still become difficult to forecast.

Build, Buy, or Modernize Around Existing Systems

Build, buy, or modernize should be decided workload by workload. SaaS is usually best when the process is common and the vendor has mature compliance controls. Custom software makes sense when the workflow, integration pattern, data model, or analytics layer is part of your operating advantage.

Use SaaS when:

• The workflow is standard across healthcare organizations
• Configuration covers most needs
• The vendor provides strong compliance documentation
• Data export and integration are acceptable
• Switching cost is manageable

Use custom software development when:

• Patient, clinician, caregiver, or operations workflows are specific to your model
• The product depends on custom integrations
• Analytics or AI-ready data is a product requirement
• User experience affects adoption or operational efficiency
• You need control over the data model, release cycle, and roadmap

Modernize around an existing system when:

• The old system contains domain logic that is hard to replace
• Users depend on stable workflows
• A full rebuild would interrupt operations
• The better path is to add APIs, reporting, identity, automation, or a new user layer first

Questions to ask a vendor or implementation partner:

• Which workloads should not move yet?
• Where will ePHI live, and how will it be logged?
• What is the shared responsibility split?
• Which services require a BAA?
• How will identity, MFA, and role management work?
• What is the rollback plan?
• How will backups be restored and tested?
• How will costs be tagged, forecast, and reviewed?
• Which integrations carry the highest delivery risk?
• What should be SaaS, custom, hybrid, or local?

For healthcare teams planning a platform rebuild or new patient-facing product, the decision is often a mix: buy commodity modules, modernize hard-to-replace systems, and build the parts that define the care model or data strategy. Attract Group's healthcare software development experience is most relevant when those product and integration decisions need to be made together.

A Practical Next Step

The next step is a workload and risk assessment, not a tool shortlist. Identify which systems contain ePHI, which workflows need better access or resilience, which integrations block product work, and which controls auditors will expect. That creates a migration path with fewer surprises.

A practical assessment should produce:

• Workload inventory
• Cloud model recommendation by workload
• ePHI boundary map
• Shared responsibility model
• Migration sequence
• Security and compliance gap list
• Integration risk review
• Budget and timeline range
• First pilot scope

If your team is planning a healthcare cloud migration, telemedicine rollout, analytics environment, or AI-ready data layer, Attract Group can help scope the architecture through its DevOps and Cloud services and healthcare delivery experience. The right first move is to decide what belongs in cloud, what should stay where it is, and what needs to be rebuilt around the workflow.

Vladimir Terekhov

Co-founder and CEO at Attract Group