Referral Data Governance

Reentry Systems & Service Coordination

Professional field guide · Data governance

A functional guide to deciding what referral information should be collected, who may receive it, which status updates can close the loop, and where legal or human authorization must control the exchange.

Published August 23, 2026 Written by OACRA LLC United States

Referral governance Consent HIPAA 42 CFR Part 2 Community supervision

In this guide

1. What data governance means
2. Status without unnecessary detail
3. Three data layers
4. Consent and other authority
5. HIPAA and Part 2
6. Access, audit and retention
7. System and human authority
8. Procurement questions
9. Staged implementation
10. Official sources

Research notice This guide is informational and does not determine whether a particular disclosure is permitted, required or prohibited. Privacy, consent, confidentiality, supervision, court-record, procurement and information-sharing requirements vary by organization, program, record type and jurisdiction. Agencies and providers should obtain qualified legal, privacy, security and records-management review for their actual workflow.

A referral system can make service coordination easier without making every participating organization part of one unrestricted record. That distinction becomes critical when corrections, probation, parole, healthcare, substance-use treatment, housing, workforce and community organizations exchange information for different purposes and under different legal authorities.

This guide extends OACRA's closed-loop reentry referral framework. The first question is whether a referral reached an appropriate service. The next question is what information must move through the loop to answer that question responsibly.

What referral data governance means

Referral data governance is the set of decisions that controls the life cycle of referral information: what is collected, why it is needed, who may access it, how authority is established, what may be returned to the referring organization, how long the record is retained, and how errors or unauthorized access are handled.

Governance is broader than cybersecurity. Encryption and access controls can protect a system from unauthorized entry, but they do not decide whether an authorized user should receive a particular field or whether the organization had authority to collect it in the first place. NIST describes privacy risk in terms of problems individuals may experience from data processing across the data life cycle, not only from a security breach.

What is the least amount of information each participant needs to perform an authorized referral task, and what should remain with the source organization?

A closed loop does not require unrestricted detail

Many coordination decisions can be made from a limited referral status rather than a clinical note, supervision narrative or complete case file. The status vocabulary should be defined before organizations connect their systems so that the same term does not mean different things to different participants.

SentThe referral left the originating workflow.

ReceivedThe destination acknowledged receipt.

AcceptedThe destination agreed to continue intake or review.

ScheduledAn appointment or next action was arranged.

InitiatedThe person began the service or intake process.

ClosedThe referral concluded, with the permitted reason coded separately.

Even these labels require governance. "Accepted" may mean accepted for screening, accepted onto a waitlist or accepted into a program. "Closed" may mean served, redirected, declined, unreachable or ineligible. A system should not convert a simple status into a statement about treatment compliance, legal compliance or successful outcome unless the receiving and referring authorities have defined that meaning and the disclosure is authorized.

Separate discovery, routing and protected detail

A useful architecture separates information by function. This reduces the tendency to treat every field as equally necessary merely because the platform can store it.

Referral data layers, purposes and governance questions

Layer	Typical purpose	Example fields	Governance question
Service discovery	Identify possible organizations or programs.	Service type, location, format, public intake channel, general availability.	Is the information public, current and presented without implying eligibility or approval?
Referral routing	Transmit an authorized request and support contact.	Identity and contact fields, requested service, accessibility or language need, routing source.	Which fields are necessary for this recipient and purpose?
Status return	Show whether the connection progressed.	Received, accepted, scheduled, initiated, redirected, closed; permitted timestamps or reason codes.	Can the operational question be answered without returning sensitive detail?
Protected or case detail	Support treatment, supervision, adjudication or another authorized function.	Clinical records, SUD patient records, supervision notes, assessments, legal documents.	What specific law, consent, order, policy or other authority permits the collection and disclosure?

Consent is a governed process, not a universal checkbox

Consent or authorization may provide a basis for some exchanges, but it is not the only possible authority and it is not interchangeable across all record types. Some disclosures may be permitted or required under other legal authorities; others may remain prohibited even when a general program form has been signed. The correct analysis depends on the organizations, data, purpose and governing law.

A consent-based workflow should make the following elements understandable and reviewable:

• which organization is requesting the information and which organization will receive it;
• the specific purpose and the categories of information involved;
• whether participation or disclosure is voluntary, required or connected to another authority;
• the effective period, expiration conditions and process for revocation where applicable;
• what status or detail may be returned, redisclosed or retained; and
• how the person can ask questions, receive an accessible explanation or correct inaccurate information.

Interfaces should not bundle broad secondary uses into a referral action or make refusal harder than agreement. Language access and disability access also affect whether a person can meaningfully understand the process. Automated translation may assist limited nonbinding administrative content, but it should not replace qualified human interpretation or translation for court, rights-affecting, legal or procedural communications.

HIPAA and 42 CFR Part 2 are important, but they are not interchangeable

HIPAA does not govern every reentry organization or every referral field

The HIPAA Privacy Rule applies to health plans, healthcare clearinghouses and healthcare providers that conduct certain transactions electronically, along with covered business-associate relationships. It does not automatically apply to every correctional agency, court, housing organization, workforce program or community nonprofit merely because health-related information appears in a referral.

For covered entities, the HIPAA minimum necessary standard generally requires reasonable efforts to limit certain uses, disclosures and requests for protected health information to the minimum needed for the intended purpose. HHS also identifies circumstances in which that standard does not apply, including disclosures to or requests by a healthcare provider for treatment and uses or disclosures made under an authorization. A platform should therefore avoid turning "minimum necessary" into one universal rule without examining the actual HIPAA relationship and purpose.

Part 2 adds specific protections for covered SUD patient records

Federal rules at 42 CFR Part 2 protect the confidentiality of certain substance-use-disorder patient records held by federally assisted programs subject to the regulation. HHS's 2024 final rule became effective April 16, 2024, and compliance with the applicable requirements was required by February 16, 2026. HHS also began a civil enforcement program tied to the updated requirements.

Part 2 analysis depends on the record, program and disclosure pathway. A generic release, referral note or assumption that HIPAA alone controls should not substitute for an organization-specific review. Systems that route treatment referrals should be able to segment fields, record the authority used, restrict redisclosure where required, and avoid exposing SUD detail through ordinary status screens or notifications.

Access controls should follow roles, purposes and time

Role-based access is more useful when roles correspond to defined tasks rather than broad organizational membership. A directory administrator may need to update provider information without viewing individual referrals. An intake worker may need routing fields without supervision notes. A supervisor may need an audit summary without unrestricted access to clinical documents.

Operational controls commonly include:

• field-level access based on job function and referral stage;
• time-limited access that changes when a referral closes or a worker changes roles;
• audit records showing who viewed, added, changed, exported or disclosed information;
• notification rules that avoid placing sensitive detail in email, text-message or lock-screen previews;
• retention and deletion schedules tied to legal, contractual and operational requirements;
• procedures for correction, dispute, incident response and inappropriate-access review; and
• vendor and subcontractor controls that follow the information beyond the first platform.

Keep system functions separate from human authority

System functions compared with decisions reserved for qualified human authorities

A system may support	A qualified human authority must determine
Collecting defined referral fields and recording the stated purpose.	Whether the organization has lawful authority to collect or disclose the information.
Applying configured access rules, expiration dates and status vocabularies.	Whether the configured rule correctly reflects law, policy, court authority, consent and professional duties.
Flagging missing consent records, unusual access or inconsistent status data.	Whether an exception applies, an incident occurred or corrective action is required.
Producing reports about routing time, contact attempts and referral progression.	Whether those measures demonstrate service quality, legal compliance, clinical progress or supervision compliance.

Questions agencies and providers should ask before procurement

1. Can the platform separate public directory data, routing data, referral status and protected case detail?
2. Can each organization configure its own roles, purposes, consent records, expiration rules and disclosure limits?
3. Does the audit trail record access, changes, exports, disclosures and administrative actions?
4. Can status be returned without exposing diagnoses, clinical notes, supervision narratives or documents?
5. How are Part 2 records identified, segmented, disclosed and protected from inappropriate redisclosure?
6. What data is used for product analytics, model training, automated decision-making or secondary commercial purposes?
7. Where is information stored, which subcontractors receive it, and what happens at contract termination?
8. How does the system support correction, revocation, record holds, retention schedules and incident investigation?
9. Are interfaces, notices and consent flows accessible and available through qualified language-access processes?
10. Which legal, privacy, security, records, procurement, clinical and supervision officials approved the final workflow?

A staged implementation is easier to govern

A program can begin with the smallest useful closed loop rather than connecting every record system at once. The initial workflow may involve service discovery, a limited routing record and a small set of status codes. More sensitive fields should be added only after the participating organizations define the purpose, authority, access rule, retention period and oversight process.

1. Map the workflow. Identify each sender, recipient, decision and status transition.
2. Classify the data. Separate public, administrative, health, SUD, supervision, court and other protected information.
3. Define authority and purpose. Document the legal, consent, order, policy or contractual basis for each exchange.
4. Minimize the fields. Test whether the operational question can be answered with less information.
5. Configure and test controls. Include role, expiration, audit, notification, correction and incident scenarios.
6. Evaluate the loop. Measure connection and timeliness without treating referral activity alone as a service outcome.

Official sources

• U.S. Department of Health and Human Services — Minimum Necessary Requirement
• U.S. Department of Health and Human Services — 42 CFR Part 2 Final Rule Fact Sheet
• U.S. Department of Health and Human Services — Understanding Confidentiality of SUD Patient Records
• U.S. Department of Health and Human Services — Part 2 Civil Enforcement Program
• National Institute of Justice — Role of Human Services During Community Supervision
• National Institute of Standards and Technology — Privacy Framework
• National Institute of Standards and Technology — Using the Privacy Framework

Update history. August 23, 2026: Initial publication. Reviewed HHS minimum-necessary guidance, the current Part 2 compliance and enforcement materials, NIJ service-coordination research and the NIST Privacy Framework.

Use and attribution. Direct links and brief attributed quotations are welcome. OACRA is an independent information and service-discovery platform and is not a court, correctional agency, healthcare provider, law firm or government entity. This guide is not legal, clinical, privacy, security or procurement advice.