Find every copy and boundary

Map Every Place PHI Touches Before Connecting an AI Tool

A field-level system-boundary map for finding PHI copies in prompts, APIs, logs, caches, storage, support, exports, backups, and downstream applications.

By WhichAI. Published 2026-07-12. Updated 2026-07-12.

Methodology: Editorial synthesis of workflow design patterns and implementation constraints. Public control references provide context, not proof of a deployment or legal advice. Where a versioned evidence pack appears, its evidence class, method, and limitations govern what the artifact can support. Read the full method. Report a correction.

Built for

Healthcare system, integration, security, privacy, and workflow owners

The decision

Identify every PHI field, transfer, persistence point, access role, vendor, and deletion path.

Answer first

The visible prompt is only one data touch. Map field-level movement through clients, APIs, automation, model services, logs, storage, support, exports, backups, and downstream systems before approving use.

WhichAI Solutions diagnostic

Bring this operating problem to the diagnostic

Use WhichAI Solutions when PHI crosses more than one vendor or core system, runtime paths differ from documentation, or the organization lacks a tested return and deletion path.

Open the diagnostic

The capacity leak

What the team is doing before anyone calls it a systems problem

Headcount pressure rarely starts with one giant task. It starts when ordinary work is split across inboxes, tabs, handoffs, and undocumented judgment calls. These are the signals to map first.

SIGNAL 01

Architecture diagrams show applications but not PHI fields.

SIGNAL 02

Logging, tracing, support, retries, and failed-message storage are undocumented.

SIGNAL 03

Temporary files and exports survive beyond the expected workflow period.

SIGNAL 04

The deletion path is assumed rather than tested across copies and backups.

The implementation

The system should prepare the decision, not pretend the decision disappeared

A complete implementation connects the intake, context, transformation, review, and record. The output of one stage becomes the controlled input to the next. A human owns the exceptions and the final consequence.

StageCurrent dragSystem responsibilityHuman responsibilityEvidence kept
1. PHI field inventoryThe data classification is simply patient data.List exact identifiers, clinical, financial, and administrative fields required and excluded.Privacy and workflow owners approve minimum fields.Field inventory, purpose, source, exclusion, and approver.
2. Node and edge mapApplications appear as boxes with generic arrows.Map every client, API, automation, model, queue, log, store, export, backup, support, and downstream edge.System owners validate runtime paths and failure routes.Node IDs, transfers, protocols, regions, fields, and owners.
3. Persistence and accessOnly primary databases have retention and roles.Record where data persists, for how long, under which role, and how support or subprocessors can access it.Security and contracting owners resolve unknowns.Store, retention, role, support path, subprocessor, and evidence.
4. Failure-path testThe map represents only successful processing.Trigger rejection, timeout, retry, duplicate, logging, support, export, and rollback scenarios and observe copies.Incident owners confirm containment and recovery.Test case, observed path, copy, access, recovery, and discrepancy.
5. Return and deletion testTermination language is not tested operationally.Verify export, return, deletion request, residual copies, backup handling, access removal, and evidence of completion.The organization decides whether the lifecycle path is acceptable.Export, deletion test, residuals, access removal, and decision.

What the human keeps

The goal is not zero humans. It is zero avoidable preparation around the judgment only a responsible owner should make.

  • Privacy and workflow owners approve minimum PHI fields and purpose.
  • System, security, and contracting owners validate runtime paths, access, and vendor evidence.
  • Incident and lifecycle owners test failures, return, deletion, and access removal.

Controls before volume

A workflow is not ready because the happy path worked once. It is ready when access, review, fallback, and evidence are explicit.

  • Map PHI at field level, not only by application.
  • Include logs, caches, queues, failures, support, subprocessors, exports, and backups.
  • Test failure and lifecycle paths before the bounded pilot.
  • Block use while a material PHI path, access role, persistence point, or deletion path is unknown.

The scorecard

Measure capacity, not activity

A system can produce more messages and still make the operation worse. Measure movement through the workflow, the quality of review, and the load that still reaches a person.

Field-path coverage

Required PHI fields mapped across every observed node and edge.

Unknown persistence

Stores, logs, queues, or backups with unresolved retention or access.

Failure-path accuracy

Injected failures whose observed PHI path matches the approved map.

Lifecycle completion

Return, deletion, and access-removal steps with current evidence.

What a fake implementation looks like here

These patterns create an AI demo while leaving the labor, risk, and accountability in the same place.

  • Mapping applications but not fields and copies.
  • Ignoring logs, failed messages, support, and backups.
  • Assuming deletion propagates without testing.
  • Approving the workflow while an unknown PHI path remains.

Two ways to act

Use the path that matches the decision

Questions

What operators ask before they build

What counts as a PHI touch?

Any collection, creation, receipt, maintenance, transmission, transformation, logging, storage, viewing, export, backup, return, or deletion involving PHI.

Should temporary storage be mapped?

Yes. Duration does not remove the need to understand the actual path, access, safeguards, and obligations.

Can a vendor diagram replace this map?

No. It can inform the review, but the organization must map its exact product, plan, configuration, fields, integrations, users, and downstream systems.

Primary references

Controls should come from the specific operating environment

These are broad public control references, not article-specific evidence, vendor endorsements, or legal advice. Validate the current rules, contracts, system configuration, and organization-specific risk before deployment.

Keep mapping

Related implementation guides