Compliance and HIPAA: Isolate PHI

Orca handles real patient tissue images, so compliance is not a feature bolted on the side — it is a property of the architecture. First, the honest framing: this is a program in mid-flight toward HIPAA and ISO 15189, not a certification being claimed. (Glossary: PHI is Protected Health Information — any patient-identifying data such as a name, medical-record number or date attached to a scan; HIPAA is the US health-data privacy law; ISO 15189 is the quality standard for medical laboratories.)

What the design does is make the widest exposures structurally hard, sequenced so the biggest risks were closed first. The two things closed first: automatic multi-tenant isolation, and keeping PHI out of the AI inference tier entirely. Everything else — MFA, encryption at rest, an immutable audit log — is sequenced next, and named plainly rather than glossed over.

The clearest way to see the design is as three trust zones. A trust boundary is the line where untrusted input becomes trusted: nothing is believed until it has crossed it. (Glossary: the Edge is the outermost layer where requests first arrive; obfuscation means stripping or masking patient identifiers so what remains cannot be tied to a person.)

Outside is untrusted: the pathologist's browser, external reference labs uploading PHI-sensitive images under per-tenant IAM roles, and R&D model artifacts. Edge is where trust is established and, critically, where PHI is removed: CloudFront and API Gateway terminate TLS, the Cognito authorizer turns a login token into an org_id claim, and the Obfuscation Service strips or masks PHI before anything is ingested. Pre-signed SigV4 URLs — short-lived, signed download links — live here too. Inside is the trusted platform: the core and its microservices, the workflow engine, the WSI processor on Fargate, org-namespaced S3, RDS MySQL, and the SQS/EventBridge/SNS messaging. Only the ISO stage runs inside a VPC (a private network).

Because obfuscation happens at the edge, PHI never crosses into the platform at all — which sets up the point of the next section.

The single point this design lands: the AI inference tier is structurally a PHI-free zone. It is not that the inference code is trusted with PHI — it never receives it. Obfuscation at the edge strips patient identifiers before ingest, so by the time an image reaches a model, there is no PHI left to leak.

This is the difference between a policy and a property. A policy says "the model should not log PHI"; a property says "the model cannot see PHI, because none arrives." The second is the one worth defending, because it does not depend on anyone remembering to follow a rule.

Many labs share one platform, so the hardest safety property is tenant isolation: one lab (one tenant) can never see another's data. Orca enforces this on a single value, the org_id (the organization/tenant id), at three layers. (Glossary: a claim is a fact carried inside a signed login token; a WHERE clause is the part of a database query that filters which rows come back.)

Layer one — identity: the Cognito login token carries an org_id claim, so tenant identity travels with every request instead of being inferred later. Layer two — data: that claim is merged into the query filters in the resource-base layer, so every read is org-scoped automatically — a developer never writes the WHERE clause and therefore can never forget it. Layer three — storage: S3 keys are namespaced by org, isolating each tenant's files by path.

The property worth trusting is that isolation is applied once, by construction, in the single path all reads and writes flow through — not a check that fifty endpoints each had to remember.

The authentication layer binds every request to exactly one tenant before any data is touched. (Glossary: a JWT is a signed token proving who is calling; an IAM role is a scoped set of AWS permissions; deny-by-default means a missing or invalid claim fails closed, granting nothing.)

Every request carries a Cognito JWT whose org_id claim binds the caller to one tenant. Per-tenant IAM roles scope credentials so compute only ever touches that org's resources. Tokens are short-lived, so expired credentials cannot be replayed — that limits the blast radius of any leak. The authorizer enforces deny-by-default: no valid org_id claim means no access.

The data layer is the defense-in-depth backstop: even if the application layer were bypassed, the database itself still enforces the org boundary. (Glossary: Row-Level Security, or RLS, is a database feature that filters rows per tenant inside the engine; a parameterized query keeps user input separate from SQL so input cannot rewrite the query.)

Every backend query gets an auto-injected org_id filter before it reaches the database. Row-Level Security enforces the same org boundary independently, inside the engine, as a second line of defense. Objects live in org-namespaced S3 prefixes, isolating tenant blobs by path. Parameterized queries stop injection from bypassing the org scope. Isolation lives in the plumbing, not in a developer's memory.

The last piece maps the real, implemented controls to the clauses they satisfy — so the design can be discussed in the auditor's language, not just the engineer's. The program is sequenced isolation-first: the controls that close the widest exposure shipped before the rest.

The honest part is the last row: MFA, encryption at rest, and an immutable append-only audit log are the sequenced next steps, not yet done. The ordering was deliberate — close the widest exposure first (automatic multi-tenant isolation and keeping PHI out of inference), then work down the list, so the priority order can be defended clause by clause.

• Compliance on Orca is by architecture, and stated honestly: a program in mid-flight toward HIPAA and ISO 15189, not a certification being claimed.
• The design is three trust zones — Outside (untrusted browser, labs, R&D artifacts), Edge (TLS, Cognito authorizer, Obfuscation Service, SigV4 URLs), Inside (core, workflow engine, Fargate WSI processor, org-namespaced S3, RDS, messaging; ISO stage in a VPC).
• Obfuscation strips PHI at the edge before ingest, which makes the AI inference tier a structurally PHI-free zone — a property, not a policy: the model cannot see PHI because none arrives.
• Tenant isolation runs on org_id at three layers: identity (Cognito claim), data (automatic query-filter injection so no one writes a WHERE clause), and storage (org-namespaced S3 keys).
• The auth layer binds each request to one tenant with a Cognito JWT, per-tenant IAM roles, short-lived tokens, and deny-by-default authorization.
• The data layer adds defense in depth: auto-injected org_id filters, Row-Level Security inside the engine, org-namespaced S3 prefixes, and parameterized queries.
• Implemented controls map to specific clauses (164.514d, 164.312a/e/c, ISO 27001/27799), sequenced isolation-first; MFA, at-rest encryption, and an immutable audit log are the named next steps.

• [ ] I can state the compliance posture honestly: mid-flight toward HIPAA and ISO 15189, not certified.
• [ ] I can describe the Outside / Edge / Inside trust boundary and name what lives in each zone.
• [ ] I can explain why the AI inference tier is a PHI-free zone, and why that is a property rather than a policy.
• [ ] I can list the three org_id isolation layers (identity, data, storage) and why the data layer means no one writes a WHERE clause.
• [ ] I can walk the auth layer: Cognito JWT claim, per-tenant IAM, short-lived tokens, deny-by-default.
• [ ] I can explain the data layer's defense in depth: auto-injected filter, Row-Level Security, org-namespaced S3, parameterized queries.
• [ ] I can map at least four implemented controls to their HIPAA clauses and name the sequenced next steps.