What made this backend different from a normal CRUD API?

The important work was not only creating endpoints. It was deciding where patient data could flow, which actions needed explicit access checks, and how to keep the backend small enough to audit.

Could this kind of backend support future compliance review?

Yes. The structure was designed around traceable data paths, backend-owned validation, and clearer ownership boundaries, which makes later security or compliance review much less painful.

aa.health HIPAA-Ready Backend

The problem

The product needed backend foundations that could handle sensitive patient data without creating fragile, one-off compliance workarounds.

Approach

I separated patient data flows from operational workflows, designed explicit access boundaries, and kept the core API small enough to audit and extend.

The backend work started with the parts of the product that would become hardest to repair later: patient data ownership, protected write paths, and the difference between operational workflows and sensitive healthcare records. That meant naming the backend boundaries before the API surface grew too large.

I kept validation and authorization close to the write paths so the frontend could change without weakening privacy controls. For healthcare products, the backend has to remain the enforcement layer even when a UI feels simple.

The result was intentionally not flashy. It was a foundation that could be understood by future engineers, reviewed by stakeholders, and extended without turning every new patient workflow into a new security question.

Result: The team got a maintainable healthcare backend with clearer privacy controls and production deployment paths.

Architecture decisions

Kept patient-facing workflows separate from operational backend paths so sensitive healthcare data did not leak into convenience APIs.
Designed backend boundaries around explicit access checks instead of relying on the frontend to hide protected actions.
Used a small, auditable API surface so future HIPAA-adjacent review work would be easier to reason about.
Prioritized clear database ownership and traceable write paths over clever abstractions that would make compliance harder later.

Before and after

BeforeThe product needed a backend foundation for regulated patient workflows, but the risk was building quick endpoints without clear privacy boundaries.

AfterThe backend had explicit patient data paths, secure access patterns, and a structure that could support audit-friendly product growth.

BeforeHealthcare workflows can become difficult to change when validation, permissions, and persistence rules are spread across the frontend and backend.

AfterValidation and access decisions lived at the backend boundary, giving the frontend predictable contracts without weakening data protection.

Risks avoided

Sensitive patient data spreading into convenience endpoints without clear ownership.
Frontend-only permission assumptions that could fail when new screens or clients were added.
A backend surface too large or inconsistent to audit confidently.
Early product speed creating compliance debt that would be expensive to unwind.

Cloudflare and AWS

Used Cloudflare-facing architecture for secure request handling and deployment simplicity where the edge could reduce exposure.
Kept sensitive stateful logic behind controlled backend paths instead of pushing every concern to the edge.
Designed the system so future AWS or Cloudflare decisions could be made by workload fit rather than by a rushed launch constraint.