Where PHI enters.
Identify the permitted source, purpose, and minimum necessary data.
Founder journey · Entry 004
The contract came before the data.
How I mapped Business Associate Agreements onto CareFlow’s data paths—and learned that a signature is a boundary, not a compliance badge.
Before CareFlow could handle protected health information, I needed to know which organizations could touch it, for what purpose, and under which written responsibilities.
The BAA made that question concrete. It did not make the architecture compliant by itself. It turned every proposed PHI route into a contract, product-scope, configuration, and evidence decision.
Chapter 01
Map the data, not the vendor logos.
The useful question is whether a service creates, receives, maintains, or transmits PHI on behalf of a regulated organization—not whether the vendor appears somewhere in the stack.
Where PHI is processed.
Verify agreement, exact service scope, configuration, and controls.
Where PHI could leak.
Inspect logs, identity attributes, support tools, and observability paths.
Where PHI stays blocked.
No billing or AI path is assumed approved before its own review.
A BAA is a data-routing constraint.
It is not a compliance badge.
It is not a compliance badge.
Chapter 02
Ambiguity is not an approved state.
Every service path receives one visible state so uncertainty cannot quietly become production use.
Intended PHI path verified.
The relationship, agreement, exact product scope, configuration, and owner are documented.
The gate stays closed.
A planned service cannot receive PHI until its legal and technical review is complete.
PHI is designed out.
The service remains useful without receiving protected information.
Chapter 03
The AWS agreement was only the first gate.
CareFlow chose an organization agreement through AWS Artifact. AWS currently documents that this can cover existing and subsequent organization member accounts, subject to its stated setup and permission requirements.
The next gate is the current HIPAA Eligible Services Reference. AWS states that PHI should be processed, stored, and transmitted only through listed eligible services under the BAA, while customers remain responsible for configuration and safeguards. That made a dated service-coverage map necessary.
APPLICABLE AGREEMENT
ELIGIBLE SERVICE
CORRECT CONFIGURATION
OPERATING CONTROLS
Primary references: HHS cloud guidance · AWS Artifact agreements · AWS HIPAA Eligible Services Reference
Chapter 04
The coverage map keeps “approved” specific.
The public version is conceptual. Real agreements, identifiers, acceptance evidence, and detailed architecture remain private.
| Field | Question | Why it matters |
|---|---|---|
| M-01 | Service role and purpose | Scope follows the work actually performed. |
| M-02 | Data created, received, maintained, or transmitted | The data path determines the vendor question. |
| M-03 | Agreement and exact product scope | A vendor-level signature does not approve every offering. |
| M-04 | Configuration, evidence owner, and review date | Coverage must survive change and audit. |
Chapter 05
The signature did not configure the system.
A BAA does not create encryption, least privilege, logging, retention, risk analysis, incident procedures, or workforce training.
Legal architecture is architecture.
Contracts shape permissible data routes and must be reflected in technical design.
Eligibility is not configuration.
An eligible service still needs controls appropriate to the intended use.
Data flow decides scope.
Not every vendor needs PHI, and not every relationship has the same obligations.
Evidence expires.
Services, features, contracts, and paths must be reviewed as the system changes.
Field check
Before a vendor touches PHI.
These prompts support review; they do not replace legal or compliance advice.
0 of 6 checked · saved nowhere
Visual edition
The contract came before the data.
A narrated visual edition mapping agreement, service scope, configuration, and continuing evidence onto CareFlow’s conceptual PHI boundary.