​​​​​​CLOSED LOOP REFERRAL (CLR) FREQUENTLY ASKED QUESTIONS​​

General Implementation

Can Department of Health Care Services (DHCS) please clarify what it means that DHCS will begin conducting compliance reviews of Medi-Cal managed care plans' (MCPs') implementation of CLR one year after the go-live date of July 1, 2025? Does DHCS expect MCPs to be fully compliant with CLR by July 1, 2025?

DHCS is providing MCPs a grace period for getting CLR systems and processes in place after the CLR policy is effective on July 1, 2025. While DHCS expects MCPs to implement CLR by July 1, 2025, DHCS acknowledges that additional time may be needed to refine CLR operational and implementation requirements such as noticing and tracking methodologies, system updates, and workflows after the go-live date. Therefore, DHCS will begin actively monitoring for compliance beginning July 1, 2026.

Tracking Member Referrals

MCPs sometimes get frequent and valuable information on referrals and engagement status directly from their Enhanced Care Management (ECM) providers. Is it possible to include alternative data sources for completing CLR tracking requirements to the mention of supplemental claims and encounter data?

MCPs may use alternative data sources to supplement CLR tracking sources outlined in the guidance; however, MCPs cannot require ECM/Community Supports Providers to submit data for tracking via means other than the Return Transmission File (RTF).

Will the DHCS confirm the MCP can close the loop as “Services Received" if the ECM or Community Supports provider confirms services are rendered or begun via data included on the RTF? The term billable service implies the MCP has received a claim which could take six months.

MCPs can close the loop of a CLR as “Ser​​vices Received" once the Provider confirms services are rendered via the Reason for Referral Loop Closure data element in the RTF.

How do CLR tracking and notification requirements apply to sobering centers?  Is Member notification required for a 24-hour service?

CLR requirements will not apply to Sobering Centers because services are often delivered in real-time, the length of stay is under 24 hours, and services are typically authorized on a retroactive basis to facilitate timely access to this Community Support.

Can DHCS clarify the intended use of the “Declined" Referral Status value by ECM and Community Supports Provider​s?

The standard CLR Referral Status values may apply across a range of services over time. Currently, DHCS anticipates that ECM and Community Supports service providers may enter a “Declined" Referral Status for any of the following reasons: the provider lacks capacity, the Member doesn't live in their service area, or for other reasons. MCPs should work with their Network Providers and provide clear documented procedures to determine which reasons are permissible for denying a referral in accordance with ECM and Community Supports policies and how it should be notated in the Referral Status value. DHCS is not implying that MCPs should adopt new policies to allow Network Providers to deny referrals.

In the DHCS Addendum to the PHM Policy Guide: Closed-Loop Referral Implementation Guidance, Table 4: Referral Processing has “Servicing Provider Name" and “Servicing Provider Phone Number" listed. Can DHCS please clarify if this is the Member's assigned lead care manager and their phone number?

The “Servicing Provider Name" and “Servicing Provider Phone Number" is the name and phone number of the entity (i.e., Servicing Provider) that receives the ECM or Community Support referral request from the MCP or the Referring Entity. For example, on pages 23-24 of CalAIM Data Guidance: Member-Level Information Sharing Between MCPs and ECM Providers Guidance, the information would be consistent with the “ECM Provider Name" and “ECM Provider Phone Number. The intent of the fields is to confirm the MCP has recorded contact information they can leverage to support the referral and service delivery for the Member for different Providers/Services to which CLR requirements apply.

Can DHCS explain the difference between “Servicing Provider Organization Name" & “Servicing Provider Name"?

​The “Servicing Provider Organization Name" is the ECM Provider (i.e., organization name). “The Servicing Provider Name" is the ECM Lead Care Manager that is assigned to provide the ECM service (the person at the organization assigned to the member).

The requirement to share Referral Loop Closure reason with Referring Entities require sharing protected health information (PHI) with non-covered entities without Member authorization. MCPs believe this requirement is non-compliant with HIPAA and requests DHCS to remove this requirement.

​The Health Insurance Portability and Accountability Act of 1996 (HIPAA) permits covered entities, including MCPs, to use or disclose “protected health information" (PHI) for certain purposes, including treatment, payment, or health care operations (certain administrative, legal, financial, and quality improvement activities, including care coordination and case management), without patient authorization. Such disclosures may be made both to other covered entities (e.g., health care providers) and to non-covered entities (e.g., housing providers, community-based organizations (CBOs)), as long as the disclosures are for purposes of treatment, payment and health care operations. 

​Referral Loop Closure Reason and Referral Loop Closure Date would both constitute PHI under HIPAA; as covered entities, MCPs are able to share that information with non-covered entities without individual authorization for purposes of treatment and care coordination. 45 CFR 164.506(c)(1) provides that covered entities may use and disclose PHI for their own treatment, payment and health care operations purposes.​​

Can DHCS provide a crosswalk for interactions between the new CLR status fields and existing status fields in RTF, and remove the new CLR status requirements from the ECM RTF and instead use existing ECM statuses for CLR tracking? The ECM RTF already tracks CLR through established statuses, but the new CLR statuses do not align, creating unnecessary complexity. Removing them would reduce confusion and administrative burden while maintaining process alignment.

DHCS is unable to accommodate the request to remove the Referral Status variable, as this is a key value for standardizing CLR tracking. However, DHCS is working on possible solutions, while considering MCP feedback on the implications of removing existing fields.  

​Can DHCS provide clarification on the difference between referral status 1 – Accepted and 3-Pending, as it is unclear in the current ECM workflow how to differentiate between them.

“Pending" is the default Referral Status for a referral made to an ECM or Community Supports Provider on the MIF when the Provider has not yet viewed the referral and confirmed they have capacity to serve the Member and intend to initiate outreach. “Accepted" is indicated once the Provider reviews the referral and intends to outreach the Member but has not yet done so. Please see Table 11 of the CLR Implementation Guidance for additional description of the values for the Referral Status variable.

MCPs are concerned that DHCS is allowing providers to decline referrals that could lead to selective Member acceptance and potential discrimination. For example, refusing to serve transgender individuals or speakers of certain languages. Can DHCS please reconsider this CLR option or implement safeguards against Member discrimination?

​The standard CLR Referral Status values may apply across a range of services over time. Currently, DHCS anticipates that ECM and Community Supports service providers may enter a “Declined" Referral Status for any of the following reasons: the provider lacks capacity, the Member doesn't live in their service area, or for other reasons. MCPs should work with their Network Providers and provide clear documented procedures to determine which reasons are permissible for denying a referral in accordance with ECM and Community Supports policies and how it should be notated in the Referral Status value. DHCS is not implying that MCPs should adopt new policies to allow Network Providers to deny referrals.

​Can DHCS confirm it is at the discretion of the MCP to define “CLRs that have been open for an extended period of time"?

Confirmed. DHCS anticipates this may vary by the known needs of the Member and the type of service. Per CLR Implementation Guidance all Referral Statuses must be updated at least monthly.

Can DHCS please clarify what does “respond to the inquiry" mean in the requirement “MCPs are expected to respond to the inquiry within one business day"?

​MCPs are required to, at a minimum, acknowledge receipt of the inquiry and provide a status of the CLR within one business day. For example, the MCP may notify the Referring Entity or Member that a referral has been authorized and passed to the service provider for outreach on [Date] if that is the latest update the MCP has on the referral's status. The intent of this requirement is to improve Referral partner understanding of a referral's status more promptly, so they can also best support the Member. DHCS is not intending to issue exceptions to this requirement at this time.

How will DHCS monitor compliance with the requirement to respond to Member inquiries within one business day?

​DHCS will begin conducting compliance reviews of MCPs' CLRs one year after the implementation date of July 1, 2025. DHCS may consider requesting ad-hoc documentation, completing audits, or introducing other measures to ensure this requirement is met and will notify MCPs in advance.

​Clarification requested from DHCS regarding expectations for follow-up related to Members denied for services due to eligibility. Can DHCS provide a clear example of a procedure that fulfills this requirement?

The intent of this requirement is to improve the likelihood that the need that led to the initial referral to ECM or Community Supports is still addressed for the Member. In the case of denied authorization for ECM due to eligibility, a next step for the MCP may be considering the application of CCM for the Member's needs and offering CCM as an alternative or notifying the Member's D-SNP of their need for care management and confirming the Member has received outreach from the D-SNP for care management support.

Most ECM referrals bypass the plan and go directly to ECM providers, who presumptively enroll Members. How can plans track the minimum data set for CLR without visibility into the referral's origin? If tracking is required, it would add significant reporting and administrative burden to our ECM provider network.

​Please refer to Appendix B Section 1.A.3. of the CLR Implementation Guidance for guidance on coding of referrals/authorization requests coming from ECM Providers to MCPs under presumptive authorization arrangements.

What level of status does DHCS expect MCPs to report out on?

​Please see the CLR Implementation Guidance section on Tracking for the full specifications and data elements that MCPs are required to track for services under CLR requirements (ECM and Community Supports). Appendix B provides additional details on values for key tracking variables such as “Referral Status" and how the data should be collected from ECM and Community Supports Providers via the monthly RTF. JSON Phase 4 templates released in February contain the detailed data elements for CLR monitoring submissions.

What level of intervention does DHCS expect when referrals remain pending for an extended period? Does that need to be memorialized in the Memorandum of Understanding (MOU) with each agency?

​Please see Section II.B.2 “Supporting Pending and Re-Referrals" of the CLR Implementation Guidance for a list of example actions MCPs can take to support ECM and Community Supports Providers in their outreach of pending referrals and recommendations for follow up with the Member and Referring Entity in these cases.

What if each agency requests different interventions from the MCP (e.g., WIC says to notify within five business days for pending referrals, Regional Center says to notify within 30 business days, etc.)

​At this time, CLR requirements apply only to referrals made to MCPs for ECM and Community Supports. CLR Noticing requirements outline expectations for Noticing Referring Entities (e.g. CBOs, Providers, Primary Care Physicians (PCPs)) on the Referral's Authorization Decision in accordance with timelines required in APL 21-011 and the Referral's Closure Reason within outlined timeframes. Please see Section II.B.I of CLR Implementation Guidance for detailed MCP CLR Noticing Requirements.

Since MCPs are required to use the DHCS referral form for ECM/Community Supports, can MCPs modify this form to include 'email address' for electronic notification purposes?

​ECM Referral Standards already include “Referring Individual Email Address" as a required element in Table 2 of the ECM Referral Standards. No updates are needed to collect this information.

How would MCPs approach duplicate referrals from the same Member and for the same service? Please provide further guidance on this.

​Please see example scenarios below:

• Scenario 1: Referral for service for which Member is already authorized. In the case that an MCP receives a referral for (e.g., ECM) and the Member already has an open authorization for ECM, the MCP should record the key referral information on referral receipt (date, Referring Entity, service) and the appropriate authorization determination (e.g., denied) and provide the necessary context to the Referring Entity in the Notice of Action (NOA) of denial (e.g., the Member is denied because they already have an active, open ECM authorization). MCPs should also provide contact information for the Referring Entity/Member to contact the MCP if they would like to request a change in Provider for their current, open authorization, as applicable.
• Scenario 2: Referral for service for which Member has another open referral in process. The MCP should also record key CLR tracking elements on the second referral in the case that two referrals for the same service are open for the Member at the same time (e.g. date of referral, Referring Entity, service, authorization status). The MCP is still expected to fulfill CLR noticing requirements for the second Referring Entity. DHCS is requiring MCPs to record information on both referrals because MCPs still have expectations for supporting the referral through communication with the Referring Entity and for supporting any necessary coordination with the Member if the duplicate referrals generate uncertainty on the assignment of an appropriate Provider of the service. For example, if two different ECM Providers submit referrals for the Member, it will be necessary for the MCP to coordinate across the Member and Referring ECM Providers to make the Member's preferred assignment of an ECM Provider.
  
  The MCP should follow existing policy and procedures and review the share/volume of Members that are referred by a Referring Entity and are denied authorization. If there is a high number of duplicate referrals for the same Member and same service, the MCP should facilitate a discussion and provide technical assistance with the Referring Entity to increase referrals that meet eligibility and are authorized.

CLR Noticing

​If an MCP identifies an individual as eligible for ECM or Community Supports using their internal data (i.e., 'Referral Type' is “2. Identified by the MCP"), do noticing requirements apply?

In this scenario, the MCP is the Referring Entity and noticing requirements do not apply. However, as a best practice, DHCS encourages MCPs to inform Members they are eligible and have been referred for a service to increase the likelihood of Member engagement.

It often takes MCPs time to ingest and clean RTF data from Providers. When does the "noticing clock" of two business days for referral loop closure begin?

​DHCS understands that MCPs may need additional time to ingest and process data upon receipt of the RTF from providers. MCPs are permitted up to five business days to process the RTF and notice the Referring Entity within two business days of completing data processing (seven days total from receipt of RTF, if needed).

Will DHCS please confirm how the MCP is expected to proceed with noticing if the Referring Entity is the Member? The Member's guardian or caretaker? The Member's family, friend, or neighbor?

In the case that a Member, their guardian/caretaker, or a family member, friend, or neighbor places a referral and request for ECM/Community Supports authorization, MCPs will still provide notice of the authorization decision to the Member. No other noticing requirements apply.

​What are the expectations for Member noticing if a Member has opted out of receiving written notices from the MCP?

MCPs should follow their internal policies on alternative methods of contacting Members with key information or NOAs in the event they have opted out of receiving written communication. For example, the MCP may instead contact the Member by phone or permissible, secure electronic method if they have opted out of written communications.

Do Member noticing requirements apply when the authorization for ECM is denied due to the Member already enrolled in ECM?

​Yes, all referrals to ECM and Community Supports are an authorization request and trigger APL 21-011 noticing requirements. Under APL 21-011, MCPs must use the appropriate NOA template which must include a concise explanation of the reasons for the decision. In the case the ECM is denied due to an existing authorization, MCPs should clearly convey the reason for the decline and offer a method of contacting the MCP to request a change in their ECM Provider, if desired.

Can DHCS please clarify who constitutes as a self-referral? For example, would a neighbor or teacher be considered a self-referral for purposes of CLR noticing requirements? What is DHCS' expectation for documenting that type of referral?

​Referrals made by a Member, their neighbor, family member, friend, or guardian/caretaker are considered self-referrals. In the case of a self-referral for ECM/Community Supports authorization, MCPs must still provide notice of the authorization decision to the Member. No other noticing requirements to Referring Entities apply. MCPs must track, support and monitor all referrals made to ECM and Community Supports, including self-referrals. Teachers, in their professional capacity, serve a Member, and are not classified as a “self or caretaker referral," therefore, are subject to noticing requirements for Referring Entities.

DHCS requires MCPs to use electronic method (not including fax) to share notices with Referring Entities, unless other non-electronic methods are mutually agreed upon. This requirement raises legal concerns about being able to share information via email.

​Guidance on what qualifies as a secure electronic method is provided in Exhibit G of the MCP contract, the Business Associate Addendum, § 9.2. This section includes obligations related to PHI Safeguards and Security, including compliance with subpart C of 45 CFR Part 164.  DHCS recommends MCPs review the Health and Human Services (HHS) FAQ: Does the Security Rule allow for sending electronic PHI (e-PHI) in an email or over the Internet? If so, what protections must be applied?

In its answer, HHS states that “The Security Rule does not expressly prohibit the use of email for sending e-PHI. However, the standards for access control (45 CFR § 164.312(a)), integrity (45 CFR § 164.312(c)(1)), and transmission security (45 CFR § 164.312(e)(1)) require covered entities to implement policies and procedures to restrict access to, protect the integrity of, and guard against unauthorized access to e-PHI. The standard for transmission security (§ 164.312(e)) also includes addressable specifications for integrity controls and encryption. This means that the covered entity must assess its use of open networks, identify the available and appropriate means to protect e-PHI as it is transmitted, select a solution, and document the decision. The Security Rule allows for e-PHI to be sent over an electronic open network as long as it is adequately protected."

DHCS recommends MCP's consult with their counsel to determine secure means of electronic transmission based on this guidance from HHS. 

Can DHCS please clarify if the noticing requirements detailed in APL 21-011 for providers (i.e., MCP to notify provider within 24 hours of the decision) also apply to Referring Entities as defined by DHCS in the CLR Implementation Guidance?

All referrals to ECM and Community Supports are an authorization request and trigger APL 21-011 noticing requirements. Under APL 21-011, MCPs must use the appropriate Notice of Action (NOA) template which must include a concise explanation of the reasons for the decision. These requirements apply for all CLRs made by Referring Entities.

A written clarification is requested from DHCS to confirm that MCPs may share PHI, including serious mental illness (SMI)/ substance use disorder (SUD) and child welfare status, with Referring Entities that are not covered entities, without patient authorization.

​DHCS recommends indicating whether ECM or the Community Support are authorized and the reason associated with the denial as applicable. No exchange of SMI/SUD or child welfare information is necessary to share the overall service (ECM/Community Supports) and authorization decision. MCPs can also follow their existing procedures for meeting DHCS noticing requirements under APL-21-011 for ECM and Community Supports since the inception of the service in 2022. DHCS recommends MCPs consult with their legal counsel to determine whether additional details related to SMI/SUD or child welfare are necessary and can be shared via noticing under existing federal and state guidance.

​Requesting DHCS confirmation on whether the new CLR notice letters to Members must include the following attachments: NOA, Your Rights, State Hearing, and IMR form.

Noticing to Members should meet the existing, full requirements under APL 21-011. CLR Member Noticing requirements are not distinct from APL 21-011.

Will DHCS require plans to submit the new CLR member-facing letters for review? If so, what will the turnaround time be for review and approval?

MCPs should use their existing noticing templates for authorized services under APL 21-011 to meet Member noticing requirements.

Raising concerns that multiple Member notifications could have the opposite effect, causing confusion rather than clarity. Currently, under APL 21-011, Members receive a single letter when they are approved or denied for ECM services. With CLR, they could receive three or more letters with NOAs, which may lead to unnecessary concern.

Additionally, MCPs often find that Members are unaware they were even referred for ECM in the first place. Having the ECM provider reach out before a NOA letter is sent would be a more member-centric approach, ensuring they understand the referral and what to expect. Can DHCS explore ways to streamline this process to reduce confusion and improve the Member experience?

CLR Implementation Guidance has been updated to reflect only one required notice for Members at the time of authorization in alignment with requirements for APL 21-011. ECM has been subject to APL 21-011 Member Noticing requirements since its inception in 2022.

The example cited of Members not being aware of the referral placed on their behalf to ECM represents a technical assistance opportunity for MCPs with Referring Entities to improve Referral Entity practices of discussing referrals with the Member prior to completing a referral as outlined in the CLR Implementation Guidance.

DHCS requires MCPs to use electronic methods for communicating CLR status, explicitly excluding faxes and portals. This is concerning, as the industry standard for UM prior authorization notifications relies on validated, contracted fax lines.  While we appreciate DHCS's efforts to move away from fax communication, implementing this requirement by July 1 without the necessary technology in place presents significant challenges for MCPs in achieving compliance.

For non-contracted referring providers, we seek clarification on what qualifies as a secure electronic method, excluding fax and portal. How does DHCS define “electronic method," and can it provide examples of secure electronic PHI sharing with entities lacking validated fax numbers or emails?

Guidance on what qualifies as a secure electronic method is provided in Exhibit G of the MCP contract, the Business Associate Addendum, § 9.2. This section includes obligations related to PHI Safeguards and Security, including compliance with subpart C of 45 CFR Part 164. DHCS recommends MCPs consult with their legal counsel to determine secure means of electronic information sharing to meet CLR noticing requirements. MCPs may wish to explore secure email or similar methods and devise noticing templates that share the minimum necessary information to meet requirements under APL 21-011 and CLR Implementation Guidance.

​Clarification requested from DHCS about notification/communication expectations for Members while incarcerated.

​DHCS recommends designing Member Noticing for incarcerated Members in coordination with the pre-release services coordinator at each correctional institution to determine the appropriate address and means for sharing the notice in a confidential manner that is received by the Member.

​Service requests (referrals) are regularly submitted by Community Supports providers to refer Members to their respective organization for Community Supports services. The assigned Community Supports providers who render the services are the Referring Entity. The same agency who initiated the referral would be providing CLR updates via the RTF. In these cases, are CLR notifications required upon loop closure? If so, notifying the Community Supports provider/Referring Entity seems redundant and adds administrative burden to the MCP to send a notification to the Community Supports provider/Referring Entity who is already aware of referral loop closure as they are the same entity who notified the MCP of referral status via the RTF submission. 

Yes, the requirement for CLR Notification upon Referral Loop Closure still applies in the use case of the Referring Entity also being the ultimate Service Provider. DHCS is maintaining this requirement for the following reasons:

• Some referrals from Community Supports Providers may be for other Community Supports or may be assigned to alternative Community Supports Providers. In both these cases Referral Loop Closure notification is important for the Provider's awareness and ongoing care coordination with the Member.

​In the case that the Referral is placed for a Community Support and the Referring Entity is also the Service Provider, maintaining notification requirements for Referral Loop Closure provides an important data quality check for both MCPs and Providers. Additionally, CLR requirements for Monitoring and Supporting CLRs emphasize the role of MCPs in reviewing Referral Loop Closure reasons by Service Provider to identify gaps in engagement approaches and best practices. Finally, CLR Requirements for Referral Loop Closure notification are not subject to APL 21-011 and allow MCPs flexibility in sending batch, electronic notification to Referring Entities with a high volume of Referral Loop Closures each month.