git:20261019.20937b5 to git:20261027.94f7f3e

- Use this before a security risk analysis, when a new system, integration or vendor touches health data, or when nobody can say with confidence which systems hold it. You get three files in a new folder, `./phi-flow-mapping/`: a spreadsheet you can open in Excel listing every place health data enters, sits or leaves, with its safeguards (`phi-inventory.csv`), simple diagrams of how the data moves (`flows.md`), and a list of the protection gaps found, each with a proposed owner (`safeguard-gaps.md`). This skill drafts for a human to review and sign; this skill never marks a control effective. The privacy and security officers confirm the map and own the decisions on gaps.

- Read the system inventory, architecture and integration diagrams, the vendor list with business associate agreement status, field lists for patient-facing systems, logging and backup configuration, and the last risk analysis. Ask the reader, in one message: whether the company is a covered entity, a business associate or both, which products and teams touch health data, and whether paper or fax is still in use.

- Write down the health data categories in scope (clinical, billing, identifiers linked to care, sensitive categories such as mental health) and which identifiers make data identifiable. Note what the company treats as de-identified and how. HIPAA recognises two methods under 45 CFR 164.514(b): an expert determination, or the safe harbor method. Safe harbor has two parts, and both need evidence in the inventory: the listed identifiers of the individual and of their relatives, employers and household members are removed, and the company has no actual knowledge that what remains could identify the person, alone or combined with other data (HHS de-identification guidance). Data only "masked" or "anonymised" by internal convention stays in scope until one method is shown in full. Teams often miss dates and ages over 89, and a re-identification code may not be derived from the identifiers (164.514(c)). Flag any flow carrying records from a federally assisted substance use disorder program: 42 CFR Part 2 adds stricter consent and redisclosure rules, so counsel reviews those flows.

- 1. **Enters**: portals, intake forms, provider integrations, claims feeds, uploads, phone, email, fax.

- Record each system or flow in the inventory spreadsheet (`phi-inventory.csv`): id, stage, system or flow, data categories, volume (order of magnitude), owner role, location (hosting region, device, paper), whether it is a source of truth or a copy, and on whose behalf the data is held (the company's own patients, or a named covered entity client when the company is a business associate, whose agreement then limits what it may do with the data).

- - Access: who can reach it, how access is granted and reviewed, and whether it is the minimum necessary.

- - Encryption at rest and in transit. Mark data in a store or flow that is not encrypted or destroyed by a method HHS recognises as unsecured (45 CFR 164.402). Unsecured data is what the breach rule analyses; whether a given incident is notifiable still depends on the exceptions in 164.402 and a documented assessment of the probability that the data was compromised, which the privacy or security owner makes, not the agent.

- - Audit logging: whether access is logged and someone reads the logs.

- - Integrity and backup: changes tracked, restores tested.

- Mark any safeguard without evidence as "claimed, not evidenced". Where a specific safeguard question matters (required or addressable, for example), run a framework lookup instead of guessing.

- In the diagrams file (`flows.md`), draw one diagram per product or process, in text or a diagram syntax the reader's tools render, marking trust boundaries and external parties. In the gap list (`safeguard-gaps.md`), list each gap with the flow id, what is missing, the likely consequence, and a proposed owner. Typical first findings: logs holding health data with broad engineer access, test environments seeded with production records, and vendors without an agreement. The list feeds the security risk analysis; it does not replace it.

- - The best practitioner looks first at the copies nobody designed: logs, error tracking, analytics, support attachments, test databases and staff AI use, where unprotected health data most often sits.

- - The common mistake is a diagram of the intended architecture with one box for "the database". The tell: no logs, backups, exports or vendors on the map, and no row marked as a copy.

- - Good output lets the security officer answer "where is our ePHI, who can reach it, and who outside the company receives it" from one inventory, with every external flow tied to an agreement or a documented reason.