PHI detection and redaction runs inside your own cloud account — AWS Comprehend Medical or Azure AI Language — before anything reaches the AI model layer. Raw patient data never leaves your boundary. It's the maximum-assurance path: for teams that require data sovereignty or must prove the boundary to their own auditors.
Every redaction or tokenization step must read the raw message first in order to classify which spans are PHI. That classifier is itself a model that sees the raw data. So the real question isn't whether something reads the PHI — something always does. It's whether that processor runs somewhere you can inspect, or somewhere you have to take on trust.
In-boundary processing moves that first processor into your cloud account. Same data classification step. No new vendor. Verifiable by your own security team without relying on anyone's word.
Two architectures for the same workflow. They differ in whose infrastructure touches PHI — and how much your own team can verify rather than take on trust.
For most covered-entity clients, the compliant baseline is straightforward — it's the baseline shown above: PHI is processed on HIPAA-eligible AWS services (Amazon Bedrock) inside a signed BAA. Under that BAA the model is permitted to handle PHI directly; no tokenization required. That path is fully compliant, and it's what most clients run.
In-boundary processing is the step beyond the baseline — for teams that require data sovereignty ("raw PHI never leaves our cloud"), run their own security review, or must prove the data boundary to their own auditors. You're not buying compliance you'd otherwise lack; you're buying verifiable control and the elimination of cross-boundary disclosure. And because the AI model only ever receives de-identified data, the model provider needs no BAA of its own — you can use any endpoint, including one that won't sign one. That's why it's the premium, maximum-assurance option — and the rest of this page.
Choose the level of control your security team needs. All three tiers keep patient identity out of the AI model layer — while preserving the clinical detail the assistant needs to be useful.
Known sensitive fields — name, date of birth, policy number, SSN — are hashed before transmission. The hash is deterministic: the same input always produces the same output, so the model can reason about identity without ever seeing the raw value.
Pseudonymization as defined in HIPAA § 164.514 (Expert Determination method): a stable pseudonymous profile is created for each patient; re-identification is possible only by the key holder using a mapping kept separately. The AI model receives only the pseudonymous profile. The mapping never leaves your controlled store.
Side Nerd deploys the complete PHI detection and redaction pipeline inside your own cloud account. AWS Comprehend Medical or Azure AI Language runs the detection step in your environment. Your security team has visibility into every component.
The AI model works exclusively with a pseudonymous profile throughout every interaction. Real identity never leaves your controlled key store.
User sends a text or structured input. Raw message — potentially containing PHI — lands in your cloud boundary (API Gateway / Event Bridge in your AWS account).
AWS Comprehend Medical or Azure AI Language classifies spans of text as PHI. The detection model runs inside your account under your existing cloud BAA. No data leaves your boundary in this step.
Detected PHI spans are replaced with stable pseudonymous tokens. Mapping is stored in your DynamoDB table or Azure Key Vault — not accessible to Side Nerd or the AI model.
Only the redacted, de-identified message reaches the AI model (MediMatch or your own endpoint). Responses are re-hydrated on return if a downstream handoff requires real identity.
| Property | BAA baseline | In-boundary ✦ |
|---|---|---|
| Raw PHI stays in client's cloud | No — processed in Side Nerd's AWS under a BAA | Yes — always |
| Where PHI is processed | Side Nerd's AWS (HIPAA-eligible, under BAA) | Client's own cloud account |
| Detection technology runs where | Side Nerd's AWS | Client's AWS (Comprehend Medical) or Azure (AI Language) |
| HIPAA-eligible BAA chain | Via Side Nerd + subprocessor BAAs | Via client's existing AWS or Azure BAA — no new vendor |
| Does the AI model need its own BAA | Yes — it processes PHI directly | No — it only ever sees de-identified data |
| Client can verify independently | No — vendor attestation | Yes — runs in their account; fully auditable |
| Identity mapping controlled by | Side Nerd (under BAA) | Client — stored in client's own key vault |
| Relative effort / timeline | Fastest — minimal setup | ~6–10 weeks build; no 3rd-party procurement |
Any external processor can write in a contract that your data stays protected. They can't let you verify it. In-boundary processing doesn't require anyone's word — you can see every step in your own account.
Every Lambda function, IAM role, Comprehend Medical call, and token mapping lives in your AWS or Azure account. Your security team can audit the entire data flow without relying on our documentation or attestation.
The detection layer uses AWS Comprehend Medical or Azure AI Language — services your team has likely already assessed. No new security review for Side Nerd's role in PHI processing, because we're not in that path.
AWS and Azure both offer HIPAA Business Associate Agreements as part of their enterprise programs. The Comprehend Medical and Azure AI Language services are BAA-eligible [AWS HIPAA-eligible services · Azure HIPAA]. No new vendor BAA is required.
With pseudonymization, the mapping between pseudonymous tokens and real identities lives only in your DynamoDB table or Azure Key Vault. Re-identification requires your authorization — not a call to our API.
Routing PHI through any extra processor means another party that must read raw data, another contract to trust, and another system to defend. In-boundary processing keeps detection inside infrastructure you already operate — no additional party touches raw PHI.
Your cloud security posture management (CSPM), DLP rules, and logging pipelines already cover your AWS/Azure accounts. In-boundary PHI processing is automatically in scope — no new tools required.
No. The in-boundary architecture is a security pattern that benefits any organization that handles identifiable health data, regardless of HIPAA coverage status. State consumer-health privacy laws — including the Washington My Health My Data Act [RCW 19.373] and Nevada SB 370 — impose consent and data-minimization obligations on organizations that may not be HIPAA covered entities. In-boundary processing addresses those obligations as well.
That said, for organizations that are HIPAA-covered entities or business associates, Tier 3 (Full In-Boundary Deployment) provides the strongest compliance posture because it brings PHI processing under your existing cloud BAA with no new vendor in the chain.
Yes. In-boundary processing governs where PHI is detected and de-identified, but the inbound channel that carries the message — SMS, web form, or email — is part of the PHI path too. If real PHI can flow through it, that channel must run on a HIPAA-eligible service under a signed BAA. For SMS that means a provider whose messaging product is explicitly BAA-covered — carrier "conduit" status is not a substitute. Our secure web intake runs inside the AWS BAA boundary, and for SMS we use a BAA-signing provider's HIPAA tier.
The two controls are complementary: the channel BAA protects the message in transit and at rest before detection runs; the de-identification step protects the AI model and downstream systems after.
AWS Comprehend Medical is a HIPAA-eligible managed NLP service that detects PHI entities including: patient name, date, phone number, address, age, email, SSN, medical record number, health plan beneficiary number, account number, certificate/license number, vehicle identifiers, device identifiers, web URLs, IP addresses, and biometric identifiers.
For most Medicare intake workflows — where common PHI includes name, DOB, Medicare ID, address, and clinical data — Comprehend Medical's coverage is comprehensive. Azure AI Language's PII detection covers a similar entity set.
Side Nerd delivers infrastructure-as-code — AWS CDK or Terraform — that provisions the detection pipeline in your account. This includes the Lambda functions that call Comprehend Medical, the DynamoDB table for pseudonym-to-PHI mapping, IAM roles scoped to least-privilege, and CloudWatch logging configuration. Your team deploys and operates the infrastructure using your own CI/CD pipeline and account credentials.
Side Nerd can provide deployment support during onboarding, but the running infrastructure is under your control and does not require ongoing access from our team.
With pseudonymization, the AI model works with pseudonymous tokens (e.g., "PATIENT_A1B2") throughout the conversation. When a downstream action requires real identity — for example, pre-filling a CRM record or scheduling a callback — your application layer calls your own key vault to look up the real value. Side Nerd's application code makes that call on your behalf using credentials your team provisions. The re-identification step never touches Side Nerd's infrastructure.
Typical Tier 3 engagements run 6–10 weeks from kickoff to production, including: architecture review with your security team, CDK/Terraform delivery, integration testing in a staging account, and handoff documentation. The infrastructure itself bills to your AWS or Azure account at Comprehend Medical / Azure AI Language consumption rates — typically a small fraction of message volume costs.
Side Nerd engagement cost is project-scoped. Book a 15-minute call to get a scoping estimate based on your message volume and existing cloud footprint.
In-boundary processing is a deployment architecture for MediMatch, not a separate product. MediMatch's intake, routing, and AI conversation layer remains unchanged — what changes is where the PHI detection and redaction step happens before messages reach the model. If you are already running MediMatch, moving to Tier 2 or Tier 3 requires an integration engagement; it is not a configuration switch.
Every claim on this page is grounded in primary regulatory authority, NIST standards, or agency guidance. Sources are organized by the aspect of in-boundary processing they govern.
The authoritative legal definition of de-identification for PHI. Establishes two accepted methods: (1) Safe Harbor — removal of 18 specified identifier categories; (2) Expert Determination — statistical demonstration that re-identification risk is very small. The pseudonymous profile tier is an Expert Determination implementation: a stable pseudonymous profile with re-identification possible only via a separately held mapping. The holder of the key is not the AI vendor; the data in transit to the model is de-identified data, not PHI.
ecfr.gov → 45 CFR § 164.514The HHS Office for Civil Rights' detailed guidance on both de-identification methods under § 164.514. Explains that pseudonymized data (where a code or mapping allows re-identification) is not de-identified for HIPAA purposes unless the covered entity or business associate retains that mapping — but critically, once the mapping is separated and the pseudonymous record transmitted, the recipient (the AI model endpoint) receives de-identified data, not PHI. This is the legal foundation for the pseudonymous profile architecture.
hhs.gov → OCR De-identification GuidanceEnumerates the 18 identifier categories that must be removed for Safe Harbor de-identification: names, geographic subdivisions smaller than state, dates (except year) for individuals over 89, phone/fax numbers, email addresses, SSNs, medical record numbers, health plan beneficiary numbers, account numbers, certificate/license numbers, vehicle identifiers, device identifiers, web URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number or code. The field-level hashing tier addresses this list deterministically.
ecfr.gov → 45 CFR § 164.514(b)(2)National Institute of Standards and Technology voluntary framework (January 2020) providing organizations a structure to identify and manage privacy risk. The "Protect-P" function directly governs data processing ecosystems and data minimization — the architectural principles behind both the field-hashing and pseudonymous profile tiers. The Framework's GOVERN, IDENTIFY, CONTROL, COMMUNICATE, and PROTECT functions map to the governance and technical safeguards required by HIPAA.
nist.gov/privacy-frameworkThe definitive federal security control catalog. Controls directly relevant to this architecture include: SI-19 (De-identification — process for de-identification of personally identifiable information); PM-22 (PII Quality Management); SC-28 (Protection of Information at Rest — encryption of the mapping table); AC-3 (Access Enforcement — key vault authorization). The in-boundary architecture enables organizations to implement SI-19 in a client-controlled environment rather than relying on vendor attestation.
csrc.nist.gov → NIST SP 800-53 Rev 5Authored by Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly (August 2020). Establishes the Zero Trust principle that no implicit trust is granted to systems based on network location or asset ownership — every access request must be authenticated, authorized, and continuously validated. The "trust boundary" concept central to our in-boundary architecture — that processing should occur in infrastructure where access controls are under the client's direct authority — is directly grounded in ZTA principles. In-boundary processing eliminates the implicit trust problem by removing the external processor entirely.
csrc.nist.gov → NIST SP 800-207The foundational definition of cloud deployment models: public cloud, private cloud, community cloud, and hybrid cloud. Defines "private cloud" as infrastructure provisioned for exclusive use by a single organization. In-boundary deployment (Tier 3) is a hybrid cloud pattern: Side Nerd operates the application layer in a shared environment; PHI processing runs in the client's private cloud. This publication provides the canonical framework for describing where in the cloud stack the trust boundary sits.
csrc.nist.gov → NIST SP 800-145Released February 2024. The GOVERN function — new in CSF 2.0 — establishes that cybersecurity risk management must address supply chain risk, third-party dependencies, and organizational roles. The in-boundary architecture directly addresses CSF 2.0's supply chain concerns by removing PHI from the third-party processing path. The IDENTIFY function's "asset management" and "risk assessment" categories apply to the question of where the trusted PHI processor resides.
nist.gov/cyberframeworkAmazon Web Services lists Amazon Comprehend Medical as a HIPAA-eligible service. Customers must execute an AWS Business Associate Addendum (BAA) before using Comprehend Medical to process PHI. When deployed in a client's own AWS account with a BAA in place, Comprehend Medical constitutes HIPAA-compliant PHI detection running inside the client's boundary — the core technology of Tier 3. Also listed: Amazon Bedrock, Amazon Comprehend, Amazon Textract, Amazon Transcribe, Amazon SageMaker AI, and Amazon Lex.
aws.amazon.com → HIPAA Eligible Services ReferenceMicrosoft Azure enters into HIPAA Business Associate Agreements with covered entities and business associates via the Microsoft Products and Services Data Protection Addendum (DPA), incorporated by reference into all Azure licensing agreements — no separate BAA signature is required. In-scope services include Azure AI Language (the Azure implementation of the PHI detection layer in Tier 3). Azure's HIPAA posture is mapped to NIST SP 800-53 and the NIST Cybersecurity Framework, and independently assessed under FedRAMP High and ISO/IEC 27001.
learn.microsoft.com → Azure HIPAA ComplianceWorld Health Organization guidance (June 2021), developed by leading experts in ethics, digital technology, law, and human rights across 18 months of deliberation. Establishes six core principles for health AI: protecting human autonomy; promoting human well-being and safety; ensuring transparency; fostering accountability; ensuring equity; and promoting AI that is responsive and sustainable. The in-boundary architecture directly supports the autonomy principle: patients and organizations retain control over how their health data is processed, by whom, and with what oversight — without relying on external vendor attestation.
who.int → Ethics and Governance of AI for Health (ISBN 9789240029200)The FDA's center for digital health technology policy and guidance, including AI/ML-Based Software as a Medical Device (SaMD). FDA's framework emphasizes that AI systems in healthcare must be transparent about their data handling and that "real-world performance monitoring" requires knowing what data the AI is actually processing. The in-boundary architecture satisfies this transparency requirement by making the data flow independently auditable — the organization can verify exactly what reaches the model layer without relying on vendor logs or documentation.
fda.gov → Digital Health Center of ExcellenceCybersecurity and Infrastructure Security Agency guidance (2023) on implementing Zero Trust across five pillars: Identity, Devices, Networks, Applications & Workloads, and Data. The Data pillar — which governs data categorization, access, and encryption — maps directly to the in-boundary PHI processing architecture. CISA's maturity model's "Advanced" and "Optimal" stages require data protection enforcement that is not dependent on implicit trust in shared infrastructure or external vendors, which is exactly what Tier 3 provides.
cisa.gov → Zero Trust Maturity ModelThe HITECH Act (2009) extended HIPAA obligations directly to business associates and their subcontractors — making the subprocessor chain a first-class compliance concern. Under HITECH, a covered entity's business associate (Side Nerd) that contracts with a subprocessor (an AI vendor) makes that subprocessor a business associate as well, with full HIPAA liability. The in-boundary architecture eliminates this subprocessor chain for PHI by moving detection out of the vendor's infrastructure entirely: the client's own cloud account becomes the processing environment, and no new BA subprocessor is added.
hhs.gov → HITECH Act EnforcementInternational standard providing a framework for de-identification of data to support privacy protection. Defines the principles, processes, and techniques for de-identification including pseudonymization, data masking, generalization, suppression, and noise addition. Directly relevant to both the field-hashing tier (pseudonymization with stable tokens) and the pseudonymous profile tier (structured pseudonymous profile with controlled re-identification). ISO/IEC 27559 is aligned with the NIST Privacy Framework.
iso.org → ISO/IEC 27559:2022Defines a conceptual framework for privacy in information and communication technology systems. Establishes the concept of a "privacy-by-design" architecture in which privacy controls are built into system design rather than bolted on. The in-boundary processing architecture is a privacy-by-design implementation: PHI never enters the external vendor's processing path; the design of the data flow, not a policy control, enforces the privacy guarantee. ISO/IEC 29101 is referenced in NIST privacy guidance.
iso.org → ISO/IEC 29101:2018The international standard defining "digital twin" for technical purposes. ISO 30173 defines a digital twin as a "digital representation of a target entity with data connections that enable convergence between the physical and digital states at an appropriate rate of synchronization" — a dynamic virtual replica of a real-world entity used for simulation and analysis, originating in IoT and manufacturing. This is distinct from pseudonymization as defined in HIPAA § 164.514, which is the correct technical framework for the Pseudonymous Profile tier described on this page. Cited here as a reference to distinguish the terms precisely.
iso.org → ISO/IEC 30173:2023CMS Medicare Marketing Guidelines require TPMOs to record all sales calls and retain recordings for 10 years. This retention requirement means that de-identification must be architected to preserve forensic utility — a compliant implementation can re-identify a record for audit purposes using the mapping table while keeping the AI model's operational data de-identified. The pseudonymous profile architecture's controlled re-identification pathway directly satisfies this: the pseudonymous profile handles ongoing AI interaction; the mapping table provides the audit trail when CMS requires it.
cms.gov → Medicare Marketing GuidelinesRequires covered entities to enter into BAA contracts before PHI is shared with a business associate, and requires BAs to do the same with their subcontractors. The in-boundary architecture reduces BAA chain complexity: PHI detection occurs in the client's account (no new BA); only de-identified data flows to Side Nerd's application layer (a BA relationship that handles no PHI); the AI model endpoint receives no PHI (no BA relationship needed). Each hop in the data flow that handles PHI requires a BAA — eliminating PHI from external hops eliminates those BAA requirements.
ecfr.gov → 45 CFR § 164.308(b)HHS OCR guidance specifically addressing cloud service providers and HIPAA. Confirms that a CSP that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or BA is itself a BA that must execute a BAA, regardless of whether the CSP accesses the PHI. This is the legal principle that makes the trust-processor question determinative: the AI model endpoint becomes a BA requiring a BAA if it receives PHI — but if it receives only de-identified data, the BAA requirement does not attach. In-boundary detection prevents BAA requirements from propagating to the AI model layer.
hhs.gov → HIPAA Cloud Computing GuidanceVerification note: ISO standards (sources 17–19) are paywalled; citations are to the ISO catalog pages. All other sources are publicly accessible. Nothing on this page constitutes legal advice. Consult qualified counsel for program-specific compliance determinations.
A 15-minute call is enough to scope which tier fits your security posture and message volume. We'll tell you what the infrastructure-as-code looks like before you commit to anything.
Also available: the full compliance white paper covering HIPAA scope, TCPA, CMS TPMO rules, and state health privacy laws.
Read: Compliance & Regulatory Framework for AI-Assisted Medicare Communication →