Who is healthcare software architecture for?
Teams about to build version one, teams whose version one cannot pass a security or regulatory review, and pharma or health-system groups standardizing a platform across studies. The output is a written architecture your engineers, or ours, can execute without re-deciding the fundamentals.
What does healthcare software architecture include?
- System and cloud architecture — services, hosting, environments, and the boundaries that keep PHI contained.
- Data model and provenance — a model that supports clinical analysis, with lineage from source to result.
- Audit trail and versioning — the record regulators and quality teams expect, designed in rather than bolted on.
- Security architecture — identity, access control, encryption, logging, and secrets, aligned to HIPAA and SOC 2.
- Interoperability design — FHIR, HL7 v2, and wearable ingestion planned as first-class interfaces.
- Scalability and cost — what the architecture costs at ten users and at ten thousand.
- Architecture decision records — each major decision, its alternatives, and why, so the reasoning survives staff changes.
- Build plan — phased delivery with milestones your board can read.
How does a healthcare software architecture engagement run?
- DiscoveryProduct intent, regulatory position, data sources, team, and constraints.
- Options and trade-offsTwo or three candidate architectures with costs, risks, and recommendations.
- Written architectureThe document, decision records, and diagrams, reviewed with your engineers.
- Build plan and handoffPhased plan, hiring or vendor implications, and an optional path into a build engagement.
HIPAA-eligible cloud services: AWS vs. Google Cloud vs. Azure
All three major clouds will sign a Business Associate Agreement (BAA) and support HIPAA workloads, but only for services on their published HIPAA-eligible lists, and the BAA does not make your configuration compliant. The table shows the BAA process and the services we most often use for each layer of a health data platform.
| Layer | AWS | Google Cloud | Microsoft Azure |
|---|---|---|---|
| BAA process | Review and accept the AWS BAA in AWS Artifact in the console | Accept the Google Cloud BAA for your account; it covers Google Cloud infrastructure plus listed products | No separate contract: the BAA is included by default in the Microsoft Product Terms |
| Compute | Amazon EC2, AWS Lambda, Amazon EKS | Compute Engine, Cloud Run, Google Kubernetes Engine | Virtual Machines, Azure Functions, Azure Kubernetes Service |
| Ingest and APIs | Amazon API Gateway, Amazon Kinesis | Apigee, Pub/Sub | API Management, Event Hubs |
| Database | Amazon RDS / Aurora | Cloud SQL | Azure SQL Database |
| Object storage | Amazon S3 | Cloud Storage | Azure Blob Storage |
| Health data (FHIR) | AWS HealthLake | Cloud Healthcare API | Azure Health Data Services |
| Analytics and ML | Amazon Athena, Amazon SageMaker | BigQuery, Vertex AI | Azure Synapse Analytics, Azure Machine Learning |
| Keys and audit logging | AWS KMS, AWS CloudTrail | Cloud Key Management Service, Cloud Logging | Key Vault, Azure Monitor |
| Official list | AWS HIPAA Eligible Services | Google Cloud HIPAA compliance | Azure HIPAA offering |
Vendors update these lists often. Confirm each service against the vendor's current list, and against the specific region and feature you plan to use, before any PHI touches it.
Reference architecture: wearable data to analytics
Most of our digital health platforms follow the same six-stage path from a sensor to an analysis-ready dataset. Each stage is a boundary where PHI is either contained, transformed, or removed.
- Device and SDKWearable or phone sensors (for example Apple HealthKit, Google Health Connect, or a vendor SDK) collect data on the device, with consent captured and versioned in the app.
- Ingest APIAn authenticated, rate-limited API receives uploads over TLS, validates payloads, and stamps each record with device, firmware, and app version for provenance.
- Encrypted raw storeRaw data lands unchanged in encrypted object storage with customer-managed keys, so any downstream result can be recomputed from source.
- Normalization to FHIR or OMOPPipelines map raw signals and app data to FHIR resources for clinical exchange or to the OMOP common data model for research, with lineage recorded at every step.
- De-identified analyticsA separate analytics environment holds de-identified or limited data sets for dashboards, statistics, and model training, so most analysts never touch identified PHI.
- Audit logging across every stageEvery access, transformation, and export is logged to tamper-evident storage, giving security reviewers and regulators the trail they ask for.
Frequently asked questions about healthcare software architecture
Do you build what you design?
Yes, when you want that. Many clients take the document to their own team or a vendor; others continue into a build engagement with us. The design is written to work either way.
We already have an architecture. Is this still useful?
Often more so. A review of an existing architecture against regulatory, security, and scalability requirements usually finds a short list of changes that are cheap now and expensive later.
Which cloud and stack do you recommend?
Whatever the requirements and your team dictate. We have shipped on AWS, Google Cloud, and Azure with HIPAA-eligible services on each, and we are not reselling any of them.
Do AWS, Google Cloud, and Azure all sign a HIPAA BAA?
Yes. AWS offers its BAA through AWS Artifact, Google Cloud through BAA acceptance for your account, and Microsoft includes its BAA by default in the Product Terms. Each covers only the services on its HIPAA-eligible list, and you remain responsible for configuring them securely.
What does a HIPAA-ready wearable data pipeline look like?
Data moves from the device or SDK to an authenticated ingest API, then into encrypted raw storage, then through normalization to FHIR or OMOP, into a separate de-identified analytics environment, with audit logging at every stage.
Should we normalize health data to FHIR or OMOP?
Use FHIR when data must flow to and from EHRs and clinical apps, and OMOP when the main goal is observational research and analytics across sources. Many platforms keep both: FHIR at the clinical edge and OMOP in the research warehouse.
Related services
Scope it in 30 minutes
Book a scoping call and we'll name the smallest engagement that moves you forward. Most teams start with the fixed-scope Initial Audit.
Book a 30-min scoping callPrefer to write? Send a short note.