Healthcare application architecture: protect patient data from day one
A healthcare app holds some of the most sensitive data there is, so the design starts with protection, not features. Here is how the pieces fit, which service plays each part on AWS, Azure and Google Cloud, which rules shape the design in different regions, and what an auditor will ask to see.
Quick answer
A healthcare application architecture keeps patient records in a managed health data store that speaks standards such as FHIR and DICOM, behind an app with strong sign-in and edge protection. Encryption keys you control, a full audit log and sensitive-data discovery surround it. Each cloud has a managed service for every part, so check regions first.
| Best for | Patient portals, clinic and hospital software, telemedicine and health-record apps |
|---|---|
| Less suited when | A fitness or wellness app that holds no clinical or identifiable health records |
| Start with | One region that fits your patients' rules, a managed health data store, your own encryption keys and audit logging switched on from day one |
| Main services on AWS | Amazon Cognito, AWS CloudTrail, AWS Key Management Service, AWS WAF, AWS Elastic Beanstalk, AWS HealthLake |
| Main services on Azure | Microsoft Entra External ID, Azure Activity Log, Azure Key Vault, Azure Web Application Firewall, Azure App Service, Azure Health Data Services |
| Main services on Google Cloud | Identity Platform, Cloud Audit Logs, Cloud Key Management Service, Cloud Armor, Cloud Run, Cloud Healthcare API |
The idea in plain words
Patient records are not like other app data. They are deeply personal, a leak or a wrong change can hurt people, and rules say who may see them and for how long they must be kept. So a healthcare design adds layers: a strong front door, a data store built for clinical data, encryption you control, and a record of every access.
Health data also follows standards. FHIR describes records such as patients, visits and lab results, DICOM covers medical images, and HL7 messages link older hospital systems. Each cloud has a managed service that stores and serves these formats, which saves you building the plumbing and makes it easier to exchange data with other systems, such as national health networks (for example ABDM in India).
Build the safeguards first, then the features. Keep records in one region you choose, switch on audit logging before the first real patient record exists, and test who can see what. Adding these later is harder and riskier.
The architecture
Boxes show the job each part does. Pick a cloud to see the service for each job.
Step by step
- A person opens the appA patient or staff member reaches your app over HTTPS. Edge protection filters attacks and floods before they reach the app.
- Prove who they areA sign-in service checks identity, asks for a second factor and keeps sessions short. Patients and staff get different roles, so a patient sees only their own record.
- Check what they may seeFor every request your app decides whether this person may see this record. Doctors, nurses, billing staff and patients each get the least access they need.
- Read or write the recordThe app reads and writes through the health data store's standard interface. Clinical data stays in one governed place instead of being copied into many databases.
- Lock the data with your keysRecords are encrypted when stored and while moving. The keys sit in a key service that you control, can rotate and can switch off.
- Write down every accessAn audit log notes who opened, changed, exported or deleted which record, and when. Logs go to a separate store that ordinary users and administrators cannot edit.
- Find and limit personal dataA discovery service scans files and exports for names, ID numbers and other identifiers, so scans, notes and reports do not leak data outside the protected store.
- Share only what is neededWhen a lab or a health-record network needs data, share the minimum fields through an approved interface and record the patient's consent.
Services side by side
The main service for each job on each cloud, with a second option where one exists. Names checked on 23 October 2026.
| Job | AWS | Azure | Google Cloud |
|---|---|---|---|
| Customer sign-up and login |
|
|
|
| Audit logs: who did what |
|
|
|
| Encryption keys (KMS and HSM) |
|
|
|
| Web application firewall and DDoS protection |
|
|
|
| Web app or API hosting (managed platform) |
|
|
|
| Healthcare data (FHIR, DICOM, HL7) |
|
|
|
| Compliance reports and certificationsOptional |
|
|
|
| Relational (SQL) databaseOptional |
|
|
|
| Voice, video and chat inside your appOptional |
|
|
|
| Find and protect sensitive data (PII)Optional |
|
|
|
Common variations
- You also store medical images. Keep scans in an image store or object storage with the same keys and logs, and show them through short-lived links instead of copying them to devices.
- Patients book video consultations. Add a video service for the call, keep recordings off unless you need them, and record consent when you do. Check the telemedicine guidelines that apply to you.
- You exchange data with labs or other hospitals. Use an integration service or API gateway with its own access rules, send only the fields needed, and log every exchange.
- You want analytics or AI on the data. Work on a de-identified copy in a separate account or project, and keep the original behind the stricter controls.
Managed health data service or your own database?
A managed health data service stores clinical data in standard formats such as FHIR and DICOM. The alternative is to design your own tables in a general database.
Managed health data service
Good
- Standard interfaces for FHIR, DICOM and HL7
- Built-in links to access logs and encryption keys
- Easier to exchange data with other systems
Watch out
- Tied to one provider's interface
- Not offered in every region
- Charged per operation, which can add up
Your own database
Good
- Full control of the data model
- Runs in any region and on any provider
- Familiar tools for your team
Watch out
- You build standards support yourself
- You build access logging and de-identification
- More work to prove to an auditor
Rules that shape a healthcare design
Rules differ by country and change over time. These are common ones, global first and then India, with what each asks for and which part of the design answers it.
HIPAA (United States)
What it asksIf you serve US patients or partners, the Security Rule asks for access controls, audit controls, integrity protection, encryption (an "addressable" safeguard in the current text) and a business associate agreement with your providers.
How this design helpsThe same layers answer the Security Rule. The big three clouds offer business associate agreements, so check which of your services are covered.
GDPR and UK GDPR (health data)
What it asksHealth data is special-category data. You need a lawful basis, security that fits the risk, a contract with each processor, rules for moving data outside the EU or UK, and breach notice within 72 hours.
How this design helpsKeys you control, role-based access and the audit log are the safeguards. Choose a region that fits your patients, and keep a record of who processes the data.
ISO/IEC 27001
What it asksAn international standard for running information security. Hospitals, insurers and large buyers often ask for certification, or for proof that you follow its controls.
How this design helpsThe safeguards here map onto its controls, and each cloud's own certificate covers its part. You still certify your own app and processes.
Digital Personal Data Protection (DPDP) Act, 2023
What it asksHandle personal data lawfully and with consent, collect only what you need, protect it with reasonable safeguards, report breaches and let people correct or erase their data.
How this design helpsEncryption, role-based access and the audit log are the safeguards. One governed data store makes correction, erasure and breach reporting practical.
Ayushman Bharat Digital Mission (ABDM)
What it asksIf you join India's national health data network, you follow its standards: FHIR-based records, ABHA health IDs and the patient's consent before records are shared.
How this design helpsA FHIR-based data store and a consent step before sharing match what the network expects. Check the current ABDM guides before you build.
CERT-In incident directions, 2022
What it asksReport certain cyber incidents to CERT-In within 6 hours, and keep system logs for 180 days, held within Indian jurisdiction.
How this design helpsCentral audit logs in an Indian region, kept for at least 180 days, give you the evidence to report on time.
IT Act and SPDI Rules, 2011
What it asksWhile they remain in force, these rules treat medical records as sensitive personal data. They ask for consent, a privacy policy and reasonable security practices.
How this design helpsThe same safeguards apply. A recognised standard such as ISO/IEC 27001 is named in the rules as one way to show reasonable security.
Who looks after what
The cloud provider looks after
- The data centres, hardware and network
- The software and patching of managed services
- Audits and compliance reports for its own controls
- The tools to encrypt, log and isolate your data
You look after
- Who can sign in, and what each role may see
- Turning on encryption, logging and backups, and testing them
- Where the data lives and who it is shared with
- Patient consent, how long records are kept and breach reporting
- Your own application code and its updates
Evidence an auditor will ask to see
Tick what you could show today. The gaps are your to-do list.
Keep in mind
- Keep data in one chosen region. Pick a region that meets your patients' rules, for example the EU for EU patients or India for Indian patients, and keep records there. Check which regions offer each service, because a few health services are not available everywhere.
- Least access. Give each role only what it needs, ask for a reason before opening a sensitive record and review access every quarter. Staff who leave lose access the same day.
- Keep patient data out of logs and test data. Keep names and ID numbers out of application logs, error messages and test copies. Use made-up or de-identified data for development.
- Backups and recovery. Back up on a schedule, store copies in a second location and test a restore. Patients cannot wait through a day of downtime.
- Staff and vendors. Sign agreements with every vendor that touches the data, train staff, and give support people the minimum access, logged and time-limited.
- Cost. Managed health services often charge per record or operation, and logs grow quickly. Estimate with your real volumes, set budget alerts and decide how long to keep logs.
- Review before launch. Have a security review or penetration test, and rehearse a breach report, before real patients use the app.
Words used on this page
Services in this pattern that have changed
Cloud providers rename and retire services often. These affect the parts above. Checked on 23 October 2026.
- AWS Closed to new customers AWS App Runner stopped accepting new customers on 30 April 2026. AWS recommends Amazon ECS Express Mode for new container web apps. Details
- Azure Closed to new customers Azure AD B2C has not been sold to new customers since 1 May 2025. Microsoft Entra External ID is the replacement for new projects. Details
Sources and further reading
Check details such as features, limits, prices and regions in the providers' own documentation.
- AWS documentation (opens in a new tab)
- Microsoft Azure documentation (opens in a new tab)
- Google Cloud documentation (opens in a new tab)
Announcements about the changed services above
Frequently asked questions
What is a HIPAA-compliant cloud architecture?
HIPAA does not certify designs. A HIPAA-aligned architecture uses access controls, encryption, audit logs and backups, signs a business associate agreement with the cloud provider and uses only services the provider lists as eligible. You still have to run it correctly.
Which cloud is best for healthcare data?
All three have managed health data services (AWS HealthLake, Azure Health Data Services and Google Cloud Healthcare API), strong security tools and compliance reports. The best fit depends on your regions, your team's skills and the systems you connect to.
Where can patient data be stored in the cloud?
Most countries allow cloud storage of health data on conditions: HIPAA in the US, GDPR in the EU and UK (with limits on moving data abroad), and the DPDP Act and CERT-In rules in India. Some countries or contracts require local storage. Choose a region that fits your patients and confirm with your compliance adviser.
What is FHIR and why does it matter?
FHIR is a standard way to describe health records, such as patients, visits and lab results, and to share them over web APIs. Using it makes it easier to connect to other systems, and each cloud's health data service speaks it.
How do I keep an audit trail for patient records?
Turn on audit logging for the data store and the app, record who did what and when, send logs to a separate protected store and keep them as long as your rules require. Test that you can answer 'who opened this record?'
Want this reviewed for your case?
CloudBrum architects can adapt this pattern to your documents, users, rules and budget, and estimate the cost. Nothing is sent until you choose.
Building something else?
Describe it in plain words and get matching services on all three clouds.
Service suggester → Cloud consulting →