When patient data and clinical uptime are the constraints
Healthcare architecture carries two constraints that pull against each other: the data must be tightly bounded, and the people who need it are working to the clock.
The situation
The system holds or moves patient data, and its availability has consequences that are measured in care rather than in revenue. Both the protection obligation and the uptime obligation are external, and neither can be traded away quietly.
The recurring failures are boundary failures: data unencrypted somewhere in transit or at rest, an access path that was never modelled, an audit trail with a gap in it. These are architecture-level facts and they are visible in a model long before they are visible in an assessment.
The other recurring problem is integration surface. Clinical estates are federated by nature, and the interfaces between systems are where both the availability and the exposure risk concentrate.
You are here if
- You cannot enumerate every path by which patient data leaves a system.
- Encryption is assumed to be on everywhere and has not been checked per component.
- A clinical workflow depends on a system whose availability nobody has stated.
- Integration points have grown one project at a time and were never modelled together.
How the work gets done
State the clinical availability target explicitly
The healthcare pack sets an availability and recovery position appropriate to clinical workflows, shown below. Stating it in the model turns "the system needs to be up" into something a design can be evaluated against.
Note the latency target is deliberately looser than the financial packs and the availability is not. That trade is the honest one for clinical systems and it is worth making visible to everyone in the room.
Simulate ▸ Industry PackSimulate ▸ Guided Setup Wizard
Check the data boundaries per component
The pack highlights the policies on encryption, public database exposure and the availability floor. Those are evaluated against the model component by component, which is the only way the answer is trustworthy — an estate-wide assertion that everything is encrypted is exactly the assertion that turns out to have an exception in it.
Simulate ▸ Policy & StandardsSimulate ▸ Rule Evaluation
Model the integration surface as one picture
Draw the interfaces between the clinical systems as a single model rather than one diagram per project. The risk concentrates at the joins, and the joins are precisely what per-project documentation never shows together.
Where a data flow crosses a boundary, lineage makes the crossing explicit rather than implied by an arrow.
Data ▸ LineageArch ▸ Platform Lens
Agree what the clinical terms mean
Patient, encounter and episode mean subtly different things in each system in a typical estate, and the mismatch is a clinical safety issue rather than a documentation nicety. Define them once, attached to the columns that implement them.
Data ▸ Business GlossaryData ▸ Data Dictionary
What the Healthcare pack sets
Clinical and patient data systems. HIPAA compliance, data integrity, and high availability for critical workflows. Applying the pack switches the workload profile and sets these six targets on the model. It does not change the design and it does not enable any industry-specific check — the targets are what the design is then evaluated against.
| Workload profile | Steady SaaS — Consistent load typical of B2B SaaS — low burst, predictable concurrency. |
|---|---|
| Availability target | 99.9% |
| Latency target (p95) | 500 ms |
| Throughput target | 500 requests/sec |
| Cost target | $30,000 / month |
| Recovery time objective | 10 minutes |
| Recovery point objective | 60 seconds |
The policies this pack highlights
- No Public Database Exposure — Databases must not be directly accessible from the public internet without a proxy or API gateway.
- Encryption Required — All data-at-rest components must have encryption enabled.
- Availability SLA ≥ 99.9% — System composite availability must meet or exceed the organisation baseline of 99.9%.
The risks it names for this industry
These are prompts to work through against your own design, not findings. The pack lists them; nothing evaluates them for you.
- PHI exposure from unencrypted storage or transit
- Missing audit trail for clinical data access
- EHR availability below 99.9% during critical care workflows
- Auth boundary gaps enabling unauthorised patient record access
What is still yours to check
The simulation evaluates the architecture itself — single point of failure, deep synchronous dependency chain, shared database across services, connection pool saturation risk, no autoscaling configured and excessive retry configuration — against the targets above, and the policy checks run on every design. The concerns below are specific to healthcare and nothing in the product evaluates them. The pack names them so they stay on your list; the review is a human one.
- PHI encryption at rest and in transit
- Audit trail for every clinical data access
- Auth boundaries and role scoping on patient records
- Observability and alerting on clinical workflow availability
What you end up holding
- A stated availability and recovery position for clinical workflows.
- Per-component encryption and exposure findings rather than an estate-wide assertion.
- One model of the integration surface, with data flows across boundaries traced.
- Agreed definitions for the clinical terms that differ between systems.
Not this, if
- You need a HIPAA compliance assessment. This models and evidences the architecture; it does not assess or attest compliance.
- The concern is data quality in patient records. This documents structure and meaning, not the values.
- You expect the pack to check clinical security rules automatically. It sets targets and highlights policies; the security review is still a human one.