Part 2 TPO electronic-health-record accounting scope

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

Current rule checkpoint

Live 42 CFR 2.25(b) limits the future Part 2 accounting of treatment, payment, and health care operations disclosures to records disclosed through an electronic health record and to the three years before the request. HHS continues to defer the section's compliance date. Both the TPO purpose and the EHR disclosure route must be supported.

Both purpose and route matter

Current 42 CFR 2.25(b) identifies TPO purpose and an EHR disclosure route. Record the disclosed recipient, purpose, outbound event, system of record, source timestamp, payload, correction, and evidence. Internal access and an external disclosure are different events.

Do not overread the future rule

HHS states in its Part 2 fact sheet that the accounting compliance date is tied to a future HIPAA revision. This section can guide data architecture now, but it should not be described as an active universal requirement to produce TPO EHR accountings.

Create a route decision

For each event, identify whether it moved through the EHR, a connected interface, an independent exchange, a payer portal, email, paper, or another system. Privacy and technical owners should document how the chosen route definition maps to source evidence.

Classify purpose from the real transaction

Record who initiated the disclosure, recipient, intended and actual purpose, workflow, consent, data, and evidence. Distinguish treatment coordination, claims and payment, operations, research, public health, legal process, patient direction, and mixed purposes. Do not infer TPO solely from the department, recipient type, or interface name.

Create review rules for events with more than one purpose or a changed purpose. Preserve the factual basis and qualified decision rather than only the final label.

Define the EHR route

Map how the record moved from the EHR to the recipient. Include native exchange, connected interfaces, HIE or network services, APIs, portal delivery, payer connectivity, direct messaging, document export, fax integration, printing, and manual handoff. Technical owners should show which routes are “through an electronic health record” under the approved legal interpretation.

An EHR user-access log is not by itself an external disclosure. A connected tool may create a disclosure even if the EHR records only a generic export. Link sending, transport, and recipient evidence to one stable event.

Preserve event-level proof

Useful fields include patient, Part 2 record, consent, purpose, sender, recipient, route, source and destination systems, date and time zone, payload, successful status, retry, correction, acknowledgment, reviewer, and evidence links. Retain raw and normalized values.

Define handling for partial delivery, multiple recipients, batch exchange, failed attempts, replaced payloads, and downstream redistribution. Avoid turning one disclosure into many because several systems logged it, or many disclosures into one because a batch shared an identifier.

Build readiness without overstating duty

Test event capture and export for a representative three-year interval. Include each EHR and connected route, legacy systems, acquired practices, vendors, consent types, TPO purposes, and recipient structures. Reconcile generated events to known transmissions and resolve unexplained gaps.

Label the control as preparation while the HHS fact sheet keeps the compliance date tied to a future HIPAA revision. Existing HIPAA, state, contract, audit, and access obligations should continue under their own requirements.

Plan for the future trigger

Version definitions, mappings, source coverage, and test results. Assign owners for regulatory monitoring, legal interpretation, EHR configuration, vendor contracts, data retention, patient response, corrections, and audit. Reevaluate whether the final HIPAA revision changes route or content assumptions before activation.

Maintain a route inventory with effective dates and a change-review requirement. New interfaces, payer connections, portal features, and acquisitions should not enter production until owners determine how their disclosure events will be classified and retained.

Example

Eighteen sampled TPO events are reviewed. Fourteen have purpose, sender, recipient, EHR-route decision, timestamp, payload evidence, and reviewer; four contain only a user-access log. Readiness is 14 of 18 events.

TPO-EHR-scope checklist

• determine the disclosure's actual TPO purpose and preserve the reasoning;
• map native, connected, portal, exchange, API, fax, print, and manual routes;
• distinguish external disclosure from internal access, use, queue, and failed attempt;
• link patient, consent, recipient, date, payload, route, status, and evidence;
• test every EHR, legacy source, vendor, mixed purpose, retry, and batch pattern; and
• keep controls preparatory until HHS sets and reviewers validate the compliance trigger.

The future paragraph (b) population is an intersection: qualifying TPO purpose, EHR disclosure route, and three-year period. Broad audit-log exports cannot prove that intersection.