Plan CCBHC DCO data handoffs with explicit event definitions, source ownership, authorized sharing, reconciliation, and reporting dependencies.
A DCO data handoff is testable when the organizations agree on the event, source, responsible contact, authorized route, expected acknowledgment, and reconciliation process. Choosing a file format or interface before those decisions can automate confusion rather than resolve it.
This guide describes operational planning for a CCBHC and a designated collaborating organization. It does not establish whether an arrangement meets certification criteria, which services can be delegated, or what information can be shared in a particular case. Use the applicable criteria, state instructions, and approved agreements for those decisions.
CCBHC DCO data handoff checklist: define the event
The Kentucky Medicaid overview of the SAMHSA CCBHC criteria includes care coordination and service scope among the program areas. Translate the organization's applicable arrangement into concrete events before writing a software requirement.
A referral request, acknowledgment, scheduled appointment, delivered service, and corrected record are different events. Identify which organization can establish each one and what evidence it maintains. Avoid using a generic complete status that changes meaning across teams.
For a fictional example, the clinic sends a request to a partner, the partner acknowledges it, and a later record describes a service. The clinic should be able to distinguish those three events rather than infer service delivery from the first message.
Assign the authoritative source for each field
Create a field dictionary with identifiers, event dates, program or service information, status, and correction references. Name the organization responsible for each value and the person who can resolve a disputed or missing item.
Distinguish patient identity from event identity. A patient identifier helps match the person; a stable event identifier helps identify duplicates, corrections, and retransmissions. Without both concepts, staff may confuse a corrected event with a second delivered service.
Define dates precisely. Service date, record creation, transmission, receipt, and correction date answer different questions. A reporting process that treats receipt date as service date can produce an inaccurate period even when the information arrived successfully.
Review the approved information route
Have authorized privacy, legal, and security staff review the information, purpose, parties, access, and exchange method. An operational need for coordination does not establish that every data element should be shared with every participant.
The New Jersey CCBHC provider resources illustrate the role of state-specific program materials. Use the instructions relevant to the actual program rather than assuming a vendor's generic DCO configuration covers the arrangement.
Map where information appears after exchange: chart, external portal, reporting dataset, worklist, export, and error log. Apply appropriate access decisions to each destination. A secure transfer does not by itself answer who can read the received information afterward.
Define receipt and acceptance separately
Technical delivery can succeed while the receiving workflow cannot use the record. A file may arrive with an unknown identifier, an unsupported status, or missing information. Define what establishes receipt and what establishes acceptance for operational use.
Give failures a named owner and a support route. The sending organization should know whether the item is waiting for retransmission, identity review, field clarification, or a receiving-system correction. A shared mailbox with no accountable reviewer can become another untracked queue.
Keep the original event and transmission history identifiable. If staff resend an item, the system or manual process should recognize that it concerns the same event. Do not count each delivery attempt as another service or another referral.
Test corrections and late information deliberately
Use a fictional event that is corrected after initial acceptance. Ask how the receiving organization identifies the changed value, relates it to the original, and reviews any downstream report. A correction should not silently create a second event or erase the history needed to explain a prior result.
Include a late-arriving event from an earlier reporting period. The reporting owner should determine its treatment using applicable instructions and the organization's submission process. Do not assume a live dashboard update automatically revises an earlier submission appropriately.
| Test case | Evidence to inspect |
|---|---|
| Ordinary event | Correct person, event, dates, and destination |
| Duplicate transmission | One event with recognizable delivery history |
| Missing identifier | Visible exception and responsible reviewer |
| Corrected event | Link to original and understandable change history |
| Late information | Defined reporting review and cutoff treatment |
| Failed transfer | Detection, notification, and recovery ownership |
Save expected results before the demonstration. That makes it harder to accept an unexplained output merely because the interface looks successful.
Reconcile the exchange to source records
For a small test period, compare the sending organization's events with the receiving organization's accepted records. Explain missing, duplicate, rejected, corrected, and pending items. Equal totals alone are not enough because one missing event can be offset by one duplicate.
Use stable identifiers to reconcile individual cases. Record the reason for differences and who owns the next action. Avoid copying unnecessary patient detail into a broadly shared implementation report; keep detailed evidence in an authorized location.
Agree on a sustainable operational cadence. A daily exception review and a periodic broader reconciliation can serve different purposes. Choose a process the organizations can staff and document what happens when the usual contact is unavailable.
Put dependencies into the written proposal
Ask vendors to identify what is available, what needs configuration, what depends on another service, and what remains manual. Include agreements, partner cooperation, account setup, data mapping, testing, support, and ongoing change ownership.
Tie acceptance to the fictional cases and reconciliation results. An interface that transfers ordinary records but cannot handle corrections may not be ready for the proposed use. Record any approved limitation and its operational control before launch.
Ease Health publishes this guide and offers a unified CRM, EHR, and RCM platform for behavioral health. Ask the team to demonstrate the proposed data path and identify external dependencies rather than assuming a named integration exists. Related material includes the EHR overview, CCBHC evidence matrix, and quality measure lineage guide.
The useful result is an exchange both organizations can explain and reconcile. That is a stronger basis for coordination and reporting than a technical success message without accountable event history.
Related reading
Frequently Asked Questions
Is a DCO agreement the same as a working data exchange?
No. The agreement and the operational exchange are related but distinct. Test the actual information flow, ownership, timing, exceptions, and evidence needed for the clinic's applicable program and reporting scope.
What should be defined before an integration is built?
Define the event being exchanged, identifiers, field meanings, responsible source, permitted information flow, timing, acknowledgment, correction process, and validation owner. Technology selection follows those decisions.
Can a sent referral prove that a DCO delivered a service?
No. Referral, receipt, acceptance, service delivery, and outcome reporting are different events. Use evidence from the organization that can establish the event being reported.
What belongs in a DCO handoff test?
Include an ordinary event, a duplicate, missing identifiers, a late record, a corrected event, and a failed transfer. Verify how staff detect each exception and who resolves it.
