PHI Data Handling Procedures

To meet the PHI data handling procedures requirement, you must document and implement procedures that govern how PHI is handled, stored, transmitted, and destroyed across every operational context, including clinical, administrative, research, and third-party exchanges (HICP 2023 - 405(d) Health Industry Cybersecurity Practices). Operationalize it by mapping PHI flows, setting clear handling rules by channel and system, and retaining evidence that staff and third parties follow those rules.

Key takeaways:

• Your procedures must cover PHI end-to-end: intake, use, storage, sharing, retention, and destruction across all contexts (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).
• “Documented” is not a binder exercise; auditors expect workflow-level steps, roles, and proof the procedure runs in production.
• Third-party exchanges belong in scope; your procedures must extend to how PHI is shared and controlled outside your boundary (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).

“PHI data handling procedures” is a deceptively simple requirement that often fails in execution. Many organizations have a general security policy, a HIPAA training deck, and a disposal policy, yet cannot show consistent, workflow-specific procedures for how PHI is handled across real operational contexts: front desk scanning, call centers, revenue cycle, remote clinical staff, research exports, integrations, and support access by third parties.

HICP Practice 7.1 focuses on documented procedures covering four verbs: handling, storage, transmission, and destruction of PHI across all operational contexts (HICP 2023 - 405(d) Health Industry Cybersecurity Practices). For a CCO or GRC lead, the fastest path is to treat this as a “PHI lifecycle standard operating procedure (SOP) set,” backed by a lightweight data-flow inventory and evidence that the SOPs are used.

This page gives requirement-level implementation guidance you can put into production quickly: who must follow the procedures, what to document, how to roll it out, and what artifacts to retain for audits and customer due diligence. You’ll also see common auditor questions, the usual failure modes, and a phased execution plan you can run without waiting for a multi-quarter security program.

Regulatory text

Requirement (excerpt): “Establish documented procedures for the handling, storage, transmission, and destruction of PHI across all operational contexts.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Operator interpretation: You need written, approved, and implemented procedures that tell teams exactly how PHI is:

1. Handled (collected, accessed, used, modified, displayed, printed, copied),
2. Stored (where it may live, how it’s protected, and who may access it),
3. Transmitted (how it moves between people, systems, and third parties), and
4. Destroyed (how it is disposed of at end of life, including backups and media),
   across all contexts: clinical workflows, administrative processes, research activities, and third-party exchanges (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).

The practical compliance test is simple: pick any workflow where PHI appears and ask, “Show me the procedure for this exact workflow, who owns it, and evidence it is followed.”

Plain-English requirement meaning (what “good” looks like)

A passing implementation has these characteristics:

• Workflow-specific: Not just “PHI must be encrypted.” Instead: “PHI sent to payers goes through system X using method Y; manual email is prohibited except under exception Z.”
• Channel-aware: Different rules for EHR, file shares, email, APIs, printing, call recordings, tickets, mobile devices, and removable media.
• Role-based: A nurse, billing specialist, researcher, and third-party support engineer do not need the same instructions. Your procedures must reflect real roles and approvals.
• Auditable: You can produce evidence: training acknowledgments, system configurations, access logs, destruction certificates, and third-party requirements.

Who it applies to (entity and operational context)

Applies to:

• Healthcare organizations that create, receive, maintain, or transmit PHI in any operational area (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).
• Health IT vendors and other third parties that handle PHI on behalf of healthcare organizations or exchange PHI via integrations and support activities (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).

Operational contexts to include (minimum set):

• Clinical: EHR access, clinical messaging, imaging, care coordination, remote clinicians.
• Administrative: scheduling, billing/revenue cycle, call centers, paper intake, scanning/printing.
• Research: datasets, de-identification workflows, exports, data use approvals.
• Third-party exchange: claims clearinghouses, labs, consultants, managed IT, cloud hosting, customer support access, and any data feeds or APIs (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).

What you actually need to do (step-by-step)

Use this implementation sequence to move from requirement to operating control.

Step 1: Define scope and ownership

• Name an executive owner (often Security/Privacy) and workflow owners (Revenue Cycle, HIM, Clinical Ops, Research, IT).
• Define “PHI handling procedures” as a controlled document set with versioning and approvals.
• Establish an exception process (temporary, time-bound, with compensating controls).

Deliverable: PHI Data Handling Procedures standard + RACI for ownership.

Step 2: Map PHI touchpoints (keep it lightweight)

Build a “PHI lifecycle map” that answers:

• Where PHI enters (forms, portals, phone, fax, EHR feeds).
• Where it is stored (EHR, data warehouse, file shares, endpoints, SaaS).
• How it moves (email, SFTP, API, HL7/FHIR, removable media, printing).
• Where it exits (payers, labs, registries, researchers, legal requests, third parties).
• Where it is destroyed (endpoints, paper, backups/media).

Deliverable: PHI flow inventory (systems + channels + owners).

Step 3: Write procedures by lifecycle stage and channel

Create procedures people can follow without interpretation. For each procedure, include: purpose, scope, roles, prerequisites, step-by-step instructions, and required records.

Minimum procedure set:

• Handling PHI (workstation and application use): access rules, minimum necessary approach, screen privacy, copy/paste restrictions, printing rules, handling misdirected PHI, incident escalation path.
• Storage of PHI: approved repositories, prohibited storage locations, endpoint storage rules, shared drive permissions model, labeling, retention alignment, and backup expectations.
• Transmission of PHI: approved methods (secure messaging, portals, APIs), identity verification for recipients, encryption expectations where relevant, restrictions on personal email/text, and file transfer requirements.
• Destruction of PHI: paper shredding and bins, secure wipe of devices/media, disposal of printers/copiers, destruction of exports, and process for decommissioning systems.

Deliverable: Controlled SOPs ¹.

Step 4: Extend procedures to third-party exchanges

Your procedures must cover PHI leaving your environment (HICP 2023 - 405(d) Health Industry Cybersecurity Practices). Operationally:

• Define approved PHI sharing patterns (API, SFTP, portal, secure email).
• Require third parties to follow equivalent handling and destruction expectations in contracts and security addenda.
• Document how third parties access PHI for support (approval, time-bound access, logging, and revocation).
• Maintain an inventory of integrations and data feeds that carry PHI.

Deliverable: Third-party PHI exchange standard + onboarding/offboarding checklist.

Step 5: Implement controls that make the procedure true

Procedures that contradict system reality fail audits. Align “paper rules” with configs:

• Access provisioning/deprovisioning workflows for PHI systems.
• Secure configurations for file transfer and storage locations.
• Logging and monitoring for PHI repositories and transfers, where available.
• Standard request paths for data extracts and research datasets.

Deliverable: Control-to-procedure mapping (what setting/process enforces each step).

Step 6: Train to the procedure, not the policy

Role-based training should teach:

• Which tools are approved for PHI transmission.
• What to do when PHI is received unexpectedly.
• How to request exceptions and how to report mistakes fast.

Deliverable: Training content + completion evidence tied to roles.

Step 7: Prove it runs (operational evidence)

Run recurring checks:

• Spot-check shared drives and collaboration tools for PHI sprawl.
• Validate a sample of data transfers use approved methods.
• Verify destruction tickets/certificates exist for decommission events.

Deliverable: Audit log of checks + remediation tracking.

Required evidence and artifacts to retain

Auditors and customers typically ask for both documents and proof of execution. Retain:

• PHI Data Handling Procedures (approved, versioned, with last review date).
• PHI flow inventory (systems, channels, third-party exchanges, owners).
• Access control evidence: provisioning tickets, role mappings, termination offboarding evidence.
• Transmission evidence: configuration screenshots for secure transfer tools, integration inventories, sample transfer logs where available.
• Destruction evidence: destruction certificates (paper, media, device disposal), decommission runbooks, tickets for data purge requests.
• Training evidence: role-based training materials and completion/attestation records.
• Exception records: approvals, duration, compensating controls, closure evidence.
• Third-party artifacts: contract language or addenda reflecting PHI handling expectations, third-party access approval records, and offboarding confirmations.

Common exam/audit questions and hangups

Expect these questions and prepare “show-me” responses:

1. “Show me the procedure for PHI sent to external parties.” Auditors want specific approved channels and who can authorize them.
2. “Where is PHI allowed to be stored?” If the answer is “in our systems,” you will get follow-ups about endpoints, shared drives, and SaaS sprawl.
3. “How do you know PHI was destroyed?” “We shred” is not evidence; they want tickets, certificates, or logs tied to assets and dates.
4. “How do third parties access PHI for support?” Be ready with a documented workflow: request, approval, time-bound access, logging, and revocation.
5. “How do research exports get governed?” The hangup is usually uncontrolled extracts and unclear retention/destruction.

Frequent implementation mistakes (and how to avoid them)

• Mistake: One policy document labeled as “procedure.” Fix: convert high-level statements into step-by-step SOPs tied to real tools and teams.
• Mistake: Excluding non-clinical departments. Fix: include Revenue Cycle, call centers, and HIM; they often handle the messiest PHI flows.
• Mistake: Ignoring exception handling. Fix: create a defined, documented exception route so staff don’t invent workarounds.
• Mistake: No linkage to third-party exchanges. Fix: treat every integration and support arrangement as in-scope; document approved transfer methods and contractual expectations (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).
• Mistake: Destruction without proof. Fix: require destruction events to produce a record (ticket, certificate, asset log update) as part of the process definition.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, weak PHI handling procedures raise breach likelihood and complicate incident response because teams cannot quickly prove what happened, where PHI traveled, and whether exposure was contained. The operational risk shows up during customer security reviews and third-party due diligence as well: buyers often request documented procedures plus evidence of execution, not only policy statements.

Practical 30/60/90-day execution plan

Use phased execution without committing to fixed durations beyond these milestones.

First 30 days: Baseline and triage

• Assign owners and approve the document set structure for procedures.
• Draft the PHI flow inventory with your highest-PHI systems and top third-party exchanges.
• Identify “unsafe by default” channels (personal email, unmanaged file shares, ad-hoc exports) and publish interim restrictions.

By 60 days: Procedures in production for core workflows

• Finalize SOPs for the most common PHI workflows: intake, EHR access, billing, secure transfer, printing/scanning, and disposal.
• Implement or tighten the systems and access workflows that make the SOPs enforceable.
• Roll out role-based training tied to the new procedures and record completion.

By 90 days: Expand coverage and prove repeatability

• Extend procedure coverage to research exports, less common departments, and edge cases (legal requests, audits, patient requests).
• Formalize third-party exchange procedures, including support access and offboarding.
• Run a first internal evidence review: pick sample workflows and assemble a mini “audit packet” of procedure + proof.

Where Daydream fits naturally: If you manage many third parties and integrations, Daydream can centralize the PHI exchange inventory, store third-party artifacts (contracts, attestations), and track exception approvals and evidence requests so “show me” audits don’t become a multi-inbox scavenger hunt.

Frequently Asked Questions

Do I need separate procedures for every department?

You need procedures that cover all operational contexts where PHI is handled, including clinical, administrative, research, and third-party exchanges (HICP 2023 - 405(d) Health Industry Cybersecurity Practices). In practice, write procedures by channel/workflow and then map departments to the relevant SOPs.

What’s the difference between a PHI handling policy and a PHI handling procedure?

A policy states expectations at a high level (what must be true). A procedure gives step-by-step instructions tied to specific tools, roles, approvals, and records so you can prove execution during an audit.

How do we handle PHI in support tickets and screenshots?

Document an approved method (redaction guidance, secure ticketing configuration, access restrictions) and require staff to avoid including PHI unless necessary. Add a workflow for purging attachments and documenting the purge as part of destruction.

Does this requirement apply to third parties that only have “incidental” access?

If the third party participates in PHI exchange or may access PHI during operations (such as support), you need documented procedures that govern that access and how PHI is handled and destroyed in that context (HICP 2023 - 405(d) Health Industry Cybersecurity Practices).

What evidence is most persuasive to auditors?

Auditors respond well to a tight package: the procedure, the system configuration that supports it, training records for the people performing it, and a sample of tickets/logs showing it happened. Avoid relying on narrative explanations without artifacts.

We have multiple PHI repositories. How do we keep procedures current?

Tie procedure maintenance to your change management and third-party onboarding processes so new systems, integrations, and workflows trigger an update to the PHI flow inventory and the relevant SOPs. Assign an owner to each SOP and require periodic review as part of your document control process.

Footnotes

1. channel and workflow