docs: qualify BAA copy to decided position; broaden PHI to PHI/PII#51
Merged
Conversation
Bring the on-prem compliance copy in line with the counsel-decided posture and broaden the general sensitive-data term from PHI to PHI/PII (OpenAdapt serves healthcare and lending/regulated work, not healthcare alone). BAA copy (deploy-on-prem.md compliance section): replace the flat "We do not sign a BAA" with the qualified position. In the self-hosted deployment PHI stays inside the customer environment and does not enter OpenAdapt's infrastructure, so the software runs as an on-premise vendor rather than a business associate for that shape and a BAA is not the operative instrument for it; the deployment's privacy officer and counsel make the determination. Where procurement requires written terms, a US HIPAA BAA (or, for an Ontario clinic, a PHIPA service-provider agreement) can be signed following review. Hosted processing of PHI in our infrastructure (BAA + HIPAA risk analysis) is not offered today. PHI -> PHI/PII in general product/security/deployment copy. Kept PHI where it is the correct legal/health-specific term or a literal token: the HIPAA/BAA/PHIPA compliance clause, the EMR illustration, the "PHI audit REM-3" identifiers, the merged-PR title in whats-new, the PlaintextPHIWarning code identifier, already-compound PII/PHI phrasing, and the narrow non-PHI validation-environment/entry-URL qualification fields. validate_docs.py, mkdocs build --strict, and pytest tests/ all pass; the pinned substrate-evidence copy is untouched. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NyCHrzA1psrKMFfroYbzaM
abrichr
force-pushed
the
baa-phi-copy-update
branch
from
July 21, 2026 08:38
7941251 to
b7b0d66
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings the on-prem compliance docs in line with the counsel-decided BAA/PHIPA posture and broadens the general sensitive-data term from PHI to PHI/PII (OpenAdapt serves healthcare and lending/regulated work).
BAA copy (legal-attestation-sensitive; scoped, not overclaimed)
docs/guides/deploy-on-prem.md"Compliance posture" section: replaced the flat "We do not sign a BAA" with the qualified position. In the self-hosted deployment PHI stays inside your environment and does not enter OpenAdapt's infrastructure, so the software runs as an on-premise vendor rather than a business associate for that shape and a BAA is not the operative instrument for it; the deploying org's privacy officer and counsel make the determination. Where procurement requires written terms, a US HIPAA BAA (or, for an Ontario clinic, a PHIPA service-provider agreement) can be signed following review. Hosted processing of PHI in our infrastructure (BAA + HIPAA risk analysis) is not offered today.The other pre-existing BAA lines (
security-review.md,deployment-matrix.md"do not infer BAA/HIPAA/PHIPA status from architecture docs") were already accurate and were left as-is.PHI -> PHI/PII
General product/security/deployment copy across 15 docs broadened to PHI/PII (scrubbing, at-rest, boundary, lane-safety guidance, etc.).
Kept as PHI (correct legal/health-specific term or literal token): the HIPAA/BAA/PHIPA compliance clause, the "a real EMR can display PHI" illustration, the
PHI audit REM-3remediation identifiers, the merged-PR title inwhats-new.md, thePlaintextPHIWarningcode identifier, already-compoundPII/PHI, and the narrownon-PHIvalidation-environment / entry-URL qualification fields.Guards
scripts/validate_docs.py: Validation passedmkdocs build --strict: successpytest tests/: 64 passed (pinned substrate-evidence copy untouched)No em dashes introduced. Source of the decided position: internal counsel decision memo (
.private/baa_phipa_decision_2026_07_14.md).🤖 Generated with Claude Code
https://claude.ai/code/session_01NyCHrzA1psrKMFfroYbzaM