- An audit packet isn't a folder of documents. It's one patient's episode of care, reconstructed so an outside reviewer can follow it without guessing.
- Start from the request's scope and the episode timeline, not from “download all.” More pages aren't more defensible.
- Reconcile before you send: schedule against notes, attendance against claims, services against authorizations, and every record against the version that existed on the date of service.
- Never hide or alter an exception. Investigate it with real records, have someone else review the packet, and keep an exact record of what was sent.
Friday, 3:47 PM. A payer request arrives. Due Monday.
Eight patients, a 90-day date range. What the request is asking for, and what's at stake if you can't produce it, is covered in What a UPIC request actually asks for — and what happens if you can't produce it. This article is about the part that happens next: actually assembling it.
The compliance officer starts with Patient 1.
Illustrative example
| Record | Where it is |
|---|---|
| Treatment plan | Found, in the EHR |
| Progress notes | Found, in the EHR |
| Authorization | In a spreadsheet |
| Attendance | In the scheduling system |
| Claim history | In the billing platform |
| ERA | A separate system |
| Credential file | A different folder |
| Signed consent | A PDF attachment |
One hour later, the organization has documents. It still doesn't have an audit packet. Seven patients to go.
The hardest part of a records request is rarely finding a document. It is proving that all of the documents belong to one consistent episode of care.
An audit packet should answer one question
Can an outside reviewer understand what happened without reconstructing the chart themselves?
Depending on the request, answering that may mean showing:
- who the patient was
- what program or level of care they were in
- when care occurred
- what services were delivered
- who delivered them
- what was authorized, where applicable
- why care was being provided
- what documentation supports it
- how the service was billed
- what the payer did with the claim
That isn't a universal list of required contents. What belongs in a packet depends on the specific request, payer, program, jurisdiction, and issue under review, and several different sets of rules can apply at once:
| Kind of requirement | Where it comes from |
|---|---|
| Operational readiness | Your own ability to find, reconcile, and assemble records; the subject of this article |
| The specific request | What this requester asked for, by when, and how to submit it |
| Payer requirements | The payer's contract and program rules |
| Privacy requirements | HIPAA, 42 CFR Part 2 where it applies, contracts, and your own policies |
| Regulatory requirements | The statutes and regulations that govern the program under review |
Only the first row is something this article can help with. The others come from the request itself and from your compliance and legal advisers.
Do not start by exporting the entire chart
The instinctive response to a request is “download all.” That produces 900 pages of duplicate forms, old documents, unrelated encounters, superseded versions, and internal administrative noise, and it makes the reviewer do the reconstruction you were supposed to do.
More pages aren't automatically more defensible. They can bury the records that matter, and they increase the chance of sending something you shouldn't. The packet should respond accurately to what was asked for.
An audit packet should be complete for the request, not indiscriminately complete.
Start with the scope of the request
Illustrative example
Before anyone exports anything, capture:
- the date the request was received
- the requester
- the patient or patients
- the date range
- the records requested
- specific services or claims, if identified
- the submission method
- the due date
- the assigned owner
- notes and clarifications
Follow the actual request and the requirements that apply to it. If something in the request is unclear, the answer is to ask the requester or your advisers, not to guess.
Build the episode-of-care timeline first
The shape of an episode
- Admission
- Assessment
- Treatment plan
- Authorization
- Services / attendance
- Progress notes
- Plan reviews
- Claims
- Remittance
- Discharge / transition
For A. Carter, that looks like:
Illustrative example
| Date | Event |
|---|---|
| Jun 3 | Admission |
| Jun 4 | Treatment plan |
| Jun 5 | Authorization effective |
| Jun 5 – Jul 2 | IOP services |
| Jun 19 | Plan review |
| Jul 2 | Transition to outpatient |
| Jul 5 | First outpatient visit |
The timeline gives a reviewer context, and it gives you something more useful: a frame that shows missing relationships before anyone starts exporting. It also turns up the question that the next few sections are about: do all the records agree with it?
The schedule and the notes should agree
Illustrative example
A discrepancy doesn't prove improper billing. The attendance may have been recorded wrong; the patient may have joined late through a different route; there may be another explanation in the records. But the organization should understand why the schedule, the roster, the note, and the claim disagree before the packet goes out, not after a reviewer points it out.
Authorization belongs in the timeline, not in a separate spreadsheet
Illustrative example
A. Carter's IOP ran through Jul 2. The authorization on file ends Jun 30. That's exactly the kind of relationship a packet should make easy to see, and when the authorization lives in a separate spreadsheet, nobody sees it until the reviewer does. Laying the authorization record over the service timeline turns a buried problem into a visible question. An authorization doesn't guarantee reimbursement either; it's one relationship among several.
The treatment plan should explain why the care existed
The clinical thread
- Assessment / needs
- Treatment plan
- Services
- Progress
- Review / change
A reviewer reading the episode should be able to follow the clinical direction of care from the treatment plan and the documentation around it. That doesn't mean every note must cite a goal number, and it isn't a claim about what any payer requires. It means the record should tell a coherent clinical story: what the patient needed, what the team set out to do, what happened, and why the plan continued or changed.
A stack of signed notes can still tell a disconnected story
Illustrative example
Every document exists. Every note is signed. And the clinical narrative is nearly impossible to follow, because twenty notes in a row say nothing about the goal they were supposed to serve. Why repeated language reads badly to a reviewer is covered in Cloned notes and medical necessity; the point here is that you want to find this during your own review, not theirs.
Audit readiness is not the same thing as document presence.
Group programs create a reconciliation problem
Illustrative example
In group-heavy programs, one session touches six records: the roster, attendance, individualized documentation, the service date, the program, and the claim. When nine were present and ten were documented and claimed, that's the first thing a reviewer will count, so it should be the first thing you count. The group note and roster should agree, or disagree for a reason that's in the record.
Provider information may belong in the packet too
Depending on the request, a reviewer may need context about who delivered the service:
- provider identity
- role
- credentials
- licensure
- enrollment information
- supervision documentation, where applicable
- the provider's relationship to the service
Illustrative example
Not every request asks for these. When one does, credential records are much more useful when they show the status on the date of service, not only today's status (the subject of The clinician delivered the service. Can you prove they were eligible to deliver it that day?). Which brings up a broader problem.
Historical accuracy matters
A provider's license is active today. The service under review was eight months ago. What was the status on that date? The treatment plan was updated last week. Which version was in force during the audited period?
An audit packet can depend on historical versions of:
- treatment plans
- authorizations
- credentials
- policies
- forms
- signatures
- other records
Today's record is not always the record that existed when care was delivered.
Version history can matter as much as the final document
Illustrative example
- Version 1 · Jun 4Signed
- Version 2 · Jun 19Updated at plan review
- Version 3 · Jul 8Current, after the outpatient transition
The audited service is Jun 14, so the relevant plan is version 1. A system that simply overwrote the plan each time would leave only version 3, which describes an outpatient patient who didn't exist on Jun 14. Replacing an old record with the newest one erases exactly the context a reviewer needs. That's why an append-only activity log, where amendments are added rather than silently overwritten, matters here. How long any record must be retained is a legal question this article doesn't answer.
The claim should trace back to the service
Illustrative example
- ClaimJun 14 · IOP · Example Clinician
- AttendanceConfirmed
- DocumentationComplete
- AuthorizationContext available
- Treatment planVersion 1 active
That's the traceability a packet should support: from any billed service back through the attendance, documentation, authorization, and plan behind it, without anyone opening four systems to prove it.
And the remittance should trace back to the claim
Illustrative example
- ClaimSubmitted
- ERAReceived
- Payer outcomePaid, adjusted, denied, or patient responsibility
- Follow-upResolved or pending
A records request may focus only on clinical documentation. For your own readiness review, though, the financial outcome is worth knowing: a claim that was paid, a denial that was never worked, or an adjustment that doesn't match the service can all point to inconsistencies in the clinical record. The remittance is where the payer recorded what it thought happened.
Do not hide the exception. Understand it.
Illustrative example
The wrong response is to leave the authorization record out of the packet. The right response is to find out what actually happened, from actual records. Possible explanations include:
- an updated authorization that was never attached
- a retroactive approval
- an incorrect authorization entry
- a wrong date range in the system
- a different service requirement
- other payer-specific context
Records must not be altered after the fact, backdated, deleted because they're unfavorable, or created to fill a gap. Where the explanation exists in the records, include it. Where it doesn't, say so accurately and involve your compliance and legal advisers.
An unexplained exception is a risk. A documented explanation is information.
Every packet needs a quality-control pass
| Area | Check before submission |
|---|---|
| Request scope | Correct patient; correct date range; requested record types included |
| Identity | Patient identifiers consistent throughout |
| Clinical | Appropriate treatment-plan version; requested notes included; signatures visible where applicable |
| Operations | Attendance and service dates reconciled |
| Authorization | Relevant records included where requested |
| Provider | Relevant provider information available |
| Billing | Claim records reconciled where applicable |
| File review | Pages readable; duplicates reviewed; unrelated patient information excluded; order reviewed |
This is an operational pass, not a legal checklist. Its job is to make sure the packet matches the request and itself before anyone else reads it.
Protect against sending the wrong patient's information
The most damaging packet error isn't a missing page. It's a page that belongs to someone else. Useful operational controls:
- confirm patient identifiers on every document
- confirm the date range
- confirm every attachment
- review combined PDFs page by page
- check for unrelated records
- use an appropriate secure submission method
- limit access to the staff who need it
Organizations should follow HIPAA, 42 CFR Part 2 where it applies, their contractual requirements, and their own privacy and security policies. Part 2 governs certain substance use disorder treatment records and sits on top of HIPAA, which is why a packet from an SUD program deserves an extra look before it leaves. What Part 2 requires for a given disclosure is a question for your compliance team; the operator-level overview is in 42 CFR Part 2, explained for operators, and the product side is on the 42 CFR Part 2 page.
The person assembling the packet should not be the only person reviewing it
An operational workflow
- Request received
- Owner assigned
- Packet assembled
- Second review
- Approval
- Submitted
- Submission receipt stored
A second reviewer catches what the assembler has stopped seeing: the wrong patient, missing pages, the wrong date range, unreadable files, unrelated documents, missing requested records, and obvious inconsistencies. Who does the second review is your call. It just shouldn't be the same person who built the packet at 11 PM on Sunday.
Track exactly what was sent
Illustrative example
Keep a record of what was sent, when, by whom, how, any receipt or confirmation, and any correspondence that follows. Months later, when the reviewer's findings arrive, the only useful answer to “did we send that?” is the exact file, not a recollection. How long to keep that record is, again, a question for your advisers.
The audit packet should be reproducible
If the compliance officer left tomorrow, could another authorized person rebuild the same packet? Not if it depends on a personal email folder, a private spreadsheet, a local desktop folder, memory, or one employee who knows where everything lives. Every one of those makes the process fragile, and fragile processes fail on Friday afternoons.
Audit readiness should belong to the organization, not to one employee's memory.
A packet builder should show what is missing before export
Conceptual example
The objective isn't a magical “audit-proof” badge. There's no such thing. The objective is visibility: knowing, before you export, which piece still needs a person.
The most useful audit dashboard is the one before the audit
Illustrative numbers
A strong compliance workflow finds incomplete records during normal operations, not after a request arrives. Every unsigned note caught by a documentation clock this week is one that won't be flagged in an audit packet next quarter.
Run your own records request before someone else does
Pick one patient, one program, and 30 to 60 days. Then try to produce, from scratch: admission context, the treatment plan, the authorization, the schedule and attendance, the notes, provider context, claim activity, the remittance, and the discharge or transition.
Measure what it takes:
- time to assemble
- missing items
- systems accessed
- manual steps
- exceptions discovered
This is an operational readiness exercise, not a formal legal audit, and it shouldn't be labeled as one. But the number of systems you had to open, and the exceptions you found along the way, are a very good preview of the Friday that hasn't happened yet.
A practical behavioral health audit-packet checklist
Request intake
- Request logged
- Patient(s) identified
- Date range confirmed
- Requested records identified
- Due date recorded
- Owner assigned
Patient / episode
- Correct patient confirmed
- Program / level of care identified
- Episode timeline reviewed
Clinical
- Relevant assessment records included where requested
- Appropriate treatment-plan version included
- Requested progress / group notes included
- Required signatures reviewed where applicable
- Treatment-plan reviews included where relevant
Operations
- Schedule reviewed
- Attendance reconciled
- Program transitions identified
Authorization
- Relevant authorization records collected where applicable
- Dates / utilization reconciled
Provider
- Relevant provider information reviewed
- Historical status available where needed
Billing
- Relevant claims identified
- Service dates reconciled
- Remittance available where applicable
- Denial / adjustment follow-up included where requested
Privacy / quality control
- Correct patient verified
- Date range verified
- Unrelated records removed
- Files readable
- Duplicate pages reviewed
- Second review completed
- Secure delivery method confirmed
Submission
- Exact files sent recorded
- Date / time recorded
- Sender recorded
- Receipt stored
- Follow-up correspondence tracked
This checklist is an operational framework, not legal advice and not a substitute for the specific records request or applicable payer, regulatory, contractual, or privacy requirements.
How ProbityCare approaches audit packets
ProbityCare is designed so the clinical and operational pieces of a patient record can be reviewed together, rather than reconstructed from disconnected systems on a Friday afternoon.
Illustrative example
- Packets built from the chart: pick the patient, the requesting payer, the date range, and the record types, and the audit packet compiles into one paginated PDF.
- A cover sheet and an index: the requesting payer, billing entity, patient, MRN, date range, and record counts up front, then every record listed with its date and page count.
- The record inline: signed notes, forms, assessments, authorizations, and documents in order. Unsigned records are flagged, not quietly included.
- History that isn't overwritten: the activity log is append-only, with creation, edit, and signature timestamps side by side, and amendments added rather than silently replaced.
- The same record underneath: treatment plans, group notes and attendance, authorizations, and credential tracking all live on the patient record the packet is built from.
It makes the record easier to assemble, read, and check. It isn't “audit-proof,” and it doesn't guarantee any reviewer's conclusion; the record still has to be right.
The takeaway
A records request shouldn't trigger an archaeological dig. The information already exists. The question is whether the organization can connect it. Can you show:
- what was planned?
- what care occurred?
- who delivered it?
- whether the patient attended?
- what was documented?
- what was authorized?
- what was billed, and what happened to the claim?
And can another authorized reviewer follow that story without guessing?
The best time to build an audit packet is before anyone asks for one.
Behavioral health audit packet questions
What is a behavioral health audit packet?
An audit packet is an organized collection of records assembled in response to a specific review, audit, or records request. A useful one lets an outside reviewer follow the patient’s episode of care without reconstructing the chart themselves.
What should be included in a behavioral health audit packet?
There is no single universal list. Contents depend on the specific request, the patient, the dates and services in question, the payer, and applicable requirements. Common elements can include treatment plans, notes, attendance, authorizations, provider information, and claim records, but the request itself sets the scope.
Should I send the patient’s entire chart?
Not automatically. Organizations should respond accurately to the scope of the request and applicable requirements. Exporting everything can bury the relevant records, include superseded or unrelated documents, and increase the risk of sending information that should not be disclosed.
How do you prepare for a behavioral health payer audit?
Readiness comes from routine operations: documentation completed and signed on time, current treatment plans, reconciled attendance, visible authorizations, provider records tied to service dates, claims that trace back to services, and periodic internal exercises that assemble one patient’s record from scratch.
What happens if records do not match?
Discrepancies should be investigated and understood using actual records, not ignored, removed, or altered. Where the records contain an explanation, include it; where they do not, say so accurately and involve compliance and legal advisers.
Can audit software guarantee that an audit will be passed?
No. Software can improve organization, traceability, visibility into what is missing, and retrieval. It cannot guarantee a payer’s or regulator’s conclusion, which depends on the records themselves and the rules under review.
How should audit packet submissions be tracked?
Keep a record of exactly what was sent, when, by whom, and how, along with any receipt or confirmation and subsequent correspondence, while following applicable privacy and security requirements. The goal is to answer “what did we send?” with the actual files, not a recollection.