Buyer-account PHI detection and de-identification on AWS
Octoryn Privacy Platform (Octopus Core internal platform)
The problem
Organisations that feed health-related text into AI and data workflows must find and remove Protected Health Information (PHI) before it moves downstream, and they need durable proof of what was inspected and what was released. Doing this by hand, or with a single detector, leaves gaps and produces little defensible evidence. It is also risky to send such data outside the organisation’s own cloud boundary.
The previous process
Without a dedicated platform, teams typically stitch together scripts, a single detection service and manual spot checks, with inconsistent handling of conflicts and low-confidence cases. Evidence is scattered or absent, so it is hard to reconstruct why a given record was admitted or released. Data often leaves the buyer’s own account for processing.
Scope
The platform provides secure ingress, PHI detection, de-identification, evidence capture and human review as a product boundary rather than a healthcare application. Healthcare is one optional consumer of its versioned ingress and release contracts. It deploys into the buyer’s own AWS account so that data stays within the customer’s cloud.
Architecture
Secure Ingress validates schema, source, MIME, malware and fingerprint, and records immutable admission-or-rejection evidence. A three-layer detection stage combines deterministic rules, Amazon Comprehend Medical and self-hosted specialist detectors, after which a Privacy Gateway performs normalisation, overlap resolution, precedence, replacement, a second-pass verification and residual-risk scoring, releasing fail-closed. An Evidence and Audit Store retains hashes, offsets, versions, policy, detector identity, reviewer evidence and timestamps with immutable export, while a Human Review Queue handles the cases that need a person. The initial target is a Linux container product on ECS/Fargate with buyer-account deployment templates, deployed in the buyer’s AWS account, with an EKS option planned later.
Governance
Release is fail-closed: if residual risk cannot be resolved, the record is not released. Every step writes immutable evidence — hashes, offsets, versions, policy, detector and reviewer identity and timestamps — that can be exported for audit. All processing happens inside the buyer’s own AWS account, keeping the data boundary with the customer.
The human role
Cases with low confidence, conflicts, residual findings, detector failures, unsupported language or policy exceptions are routed to a Human Review Queue. Reviewers make the decision, and their decisions are captured as private reviewer-signed evidence. The platform surfaces the finding; a person decides the outcome.
Outcome
At an independent staging validation (dated 2026-07-17/18), ECS ran 1/1 with two SageMaker endpoints at 1/1, exercised by real five-part traffic with runtime-owned metrics and eight fail-visible alarms. The Human Review Queue independently passed for all six trigger lanes using real ingress and private reviewer-signed decisions. In an adverse queue reconciliation, all 85 retained release-candidate-DLQ messages were redriven through the worker without purge, after which all eight product DLQs measured 0/0/0 and all seven orchestration containers were HEALTHY.
What was validated
- Independent staging (2026-07-17/18): ECS 1/1, two SageMaker endpoints 1/1, real five-part traffic, eight fail-visible alarms
- All 85 retained release-candidate-DLQ messages redriven through the worker without purge; afterwards eight product DLQs 0/0/0 and seven orchestration containers HEALTHY
- Human Review Queue independently passed all six trigger lanes with real ingress and private reviewer-signed decisions
- Runtime images: pinned digests, SBOM/SLSA attestations, non-root users, clean staging ECR scans
Limitations
← Back to case studies
