Implementación general​​ 

Can 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 proporciona a los MCP un período de gracia para poner en marcha los sistemas y procesos de CLR después de que la política de CLR entre en vigor el 1de julio de 2025. Si bien DHCS espera que los MCP implementen CLR para el 1de julio de 2025, DHCS reconoce que es posible que se necesite tiempo adicional para refinar los requisitos operativos y de implementación de CLR, como las metodologías de notificación y seguimiento, las actualizaciones del sistema y los flujos de trabajo después de la fecha de puesta en marcha. Por lo tanto, el DHCS comenzará a monitorear activamente el cumplimiento a partir del 1de julio de 2026.​​ 

Seguimiento de referencias de miembros​​ 

Los MCP a veces obtienen información frecuente y valiosa sobre las referencias y el estado de participación directamente de sus proveedores de Administración de Atención Mejorada (ECM). ¿Es posible incluir orígenes de datos alternativos para completar los requisitos de seguimiento de CLR a la mención de notificaciones complementarias y datos de encuentros?​​ 

Los MCP pueden usar fuentes de datos alternativas para complementar las fuentes de seguimiento de CLR descritas en la guía; sin embargo, los MCP no pueden exigir a los proveedores de ECM/apoyo comunitario que envíen datos para su seguimiento a través de medios distintos al archivo de transmisión de retorno (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 “Services Received” once the Provider confirms services are rendered via the Reason for Referral Loop Closure data element in the RTF.​​ 

¿Cómo se aplican los requisitos de seguimiento y notificación de CLR a los centros de sobriedad?  ¿Es necesario notificar al miembro para un servicio de 24 horas?​​ 

Los requisitos de CLR no se aplicarán a los Centros de Sobriedad porque los servicios a menudo se brindan en tiempo real, la duración de la estadía es inferior a 24 horas y los servicios generalmente se autorizan de manera retroactiva para facilitar el acceso oportuno a este Apoyo Comunitario.​​ 

Can DHCS clarify the intended use of the “Declined” Referral Status value by ECM and Community Supports Providers?​​ 

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).​​ 

El requisito de compartir el motivo del Cierre del Bucle de Referencia con las Entidades Referentes requiere compartir información de salud protegida (PHI) con entidades no cubiertas sin la autorización del Miembro. Los MCP creen que este requisito no cumple con la HIPAA y solicitan al DHCS que elimine este requisito.​​ 

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.​​ 

¿Puede DHCS proporcionar un cruce de pasos para las interacciones entre los nuevos campos de estado de CLR y los campos de estado existentes en RTF, y eliminar los nuevos requisitos de estado de CLR del RTF de ECM y, en su lugar, usar los estados de ECM existentes para el seguimiento de CLR? El RTF de ECM ya realiza un seguimiento de CLR a través de los estados establecidos, pero los nuevos estados de CLR no se alinean, lo que crea una complejidad innecesaria. Eliminarlos reduciría la confusión y la carga administrativa, al tiempo que mantendría la alineación del proceso.​​ 

DHCS no puede dar cabida a la solicitud de quitar la variable Estado de referencia, ya que se trata de un valor clave para estandarizar el seguimiento de CLR. Sin embargo, el DHCS está trabajando en posibles soluciones, al tiempo que considera los comentarios de MCP sobre las implicaciones de eliminar los campos existentes.​​   

¿Puede el DHCS proporcionar una aclaración sobre la diferencia entre el estado de referencia 1 - Aceptado y 3 Pendiente, ya que no está claro en el flujo de trabajo actual de ECM cómo diferenciarlos?​​ 

“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.​​ 

A los MCP les preocupa que el DHCS esté permitiendo que los proveedores rechacen referencias que podrían conducir a la aceptación selectiva de los miembros y a una posible discriminación. Por ejemplo, negarse a atender a personas transgénero o hablantes de ciertos idiomas. ¿Puede DHCS reconsiderar esta opción de CLR o implementar salvaguardas contra la discriminación de los miembros?​​ 

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”?​​ 

Empedernido. DHCS anticipa que esto puede variar según las necesidades conocidas del Miembro y el tipo de servicio. De acuerdo con la Guía de implementación de CLR, todos los estados de referencia deben actualizarse al menos una vez al mes.​​ 

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.​​ 

¿Cómo supervisará el DHCS el cumplimiento del requisito de responder a las consultas de los Miembros en el plazo de un día hábil?​​ 

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.​​ 

Aclaración solicitada al DHCS con respecto a las expectativas de seguimiento relacionadas con los Miembros a los que se les negaron los servicios debido a la elegibilidad. ¿Puede el DHCS proporcionar un ejemplo claro de un procedimiento que cumpla con este requisito?​​ 

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.​​ 

Consulte la sección 1.A.3 del Apéndice B. de la Guía de implementación de CLR para obtener orientación sobre la codificación de las solicitudes de referencias/autorización provenientes de los proveedores de ECM a los MCP en virtud de acuerdos de autorización presunta.​​ 

¿Qué nivel de estado espera el DHCS que informen los MCP?​​ 

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.​​ 

¿Qué nivel de intervención espera el DHCS cuando las referencias permanecen pendientes durante un período prolongado? ¿Es necesario que eso quede registrado en el Memorándum de Entendimiento (MOU) con cada agencia?​​ 

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.​​ 

¿Qué pasa si cada agencia solicita diferentes intervenciones del MCP (por ejemplo, WIC dice que se notifique dentro de los cinco días hábiles para las referencias pendientes, el Centro Regional dice que se notifique dentro de los 30 días hábiles, 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.​​ 

¿Cómo abordarían los MCP las referencias duplicadas del mismo Miembro y para el mismo servicio? Sírvanse proporcionar más orientación al respecto.​​ 

Consulte los escenarios de ejemplo a continuación:​​ 

• Escenario 1: Referencia para un servicio para el cual el Miembro ya está autorizado. En el caso de que un MCP reciba una remisión para (por ejemplo, ECM) y el Miembro ya tenga una autorización abierta para ECM, el MCP debe registrar la información clave de la remisión en la recepción de la remisión (fecha, Entidad Referente, servicio) y la determinación de autorización apropiada (por ejemplo, denegada) y proporcionar el contexto necesario a la Entidad Remitente en la Notificación de Acción (NOA) de denegación (p. ej., se deniega al miembro porque ya tiene una autorización ECM activa y abierta). Los MCP también deben proporcionar información de contacto para que la Entidad/Miembro Referente se comunique con el MCP si desea solicitar un cambio de Proveedor para su autorización abierta actual, según corresponda.​​ 
• 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.​​ 

Observación de CLR​​ 

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?​​ 

En este escenario, el MCP es la entidad de referencia y no se aplican los requisitos de notificación. Sin embargo, como mejor práctica, DHCS alienta a los MCP a informar a los miembros que son elegibles y que han sido referidos a un servicio para aumentar la probabilidad de participación de los miembros.​​ 

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 entiende que los MCP pueden necesitar tiempo adicional para ingerir y procesar datos al recibir el RTF de los proveedores. Los MCP tienen permitido hasta cinco días hábiles para procesar el RTF y notificar a la Entidad Referente dentro de los dos días hábiles posteriores a la finalización del procesamiento de datos (siete días en total a partir de la recepción del RTF, si es necesario).​​ 

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?​​ 

En el caso de que un Miembro, su tutor/cuidador, o un familiar, amigo o vecino haga una referencia y solicite la autorización de ECM/Apoyos Comunitarios, los MCP aún notificarán la decisión de autorización al Miembro. No se aplican otros requisitos de notificación.​​ 

¿Cuáles son las expectativas para los Miembros que se dan cuenta si un Miembro ha optado por no recibir notificaciones por escrito del MCP?​​ 

Los MCP deben seguir sus políticas internas sobre métodos alternativos para ponerse en contacto con los Miembros con información clave o NOA en caso de que hayan optado por no recibir comunicaciones escritas. Por ejemplo, el MCP puede ponerse en contacto con el Miembro por teléfono o por un método electrónico seguro y permitido si ha optado por no recibir comunicaciones escritas.​​ 

¿Se aplican los requisitos de notificación de los miembros cuando se deniega la autorización para ECM debido a que el miembro ya está inscrito en ECM?​​ 

Sí, todas las referencias a ECM y Apoyos Comunitarios son una solicitud de autorización y activan los requisitos de notificación de APL 21-011. Bajo APL 21-011, los MCP deben usar la plantilla NOA apropiada que debe incluir una explicación concisa de las razones de la decisión. En el caso de que se deniegue el ECM debido a una autorización existente, los MCP deben comunicar claramente el motivo del rechazo y ofrecer un método para ponerse en contacto con el MCP para solicitar un cambio en su proveedor de ECM, si lo desea.​​ 

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.​​ 

El DHCS requiere que los MCP utilicen un método electrónico (sin incluir el fax) para compartir avisos con las Entidades Referentes, a menos que se acuerden mutuamente otros métodos no electrónicos. Este requisito plantea preocupaciones legales sobre la posibilidad de compartir información por correo electrónico.​​ 

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.​​  

¿Puede el DHCS aclarar si los requisitos de notificación detallados en APL 21-011 para los proveedores (es decir, MCP debe notificar al proveedor dentro de las 24 horas posteriores a la decisión) también se aplican a las Entidades Referentes según lo definido por el DHCS en la Guía de Implementación de CLR?​​ 

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.​​ 

Se solicita una aclaración por escrito del DHCS para confirmar que los MCP pueden compartir PHI, incluidas las enfermedades mentales graves (SMI)/trastornos por uso de sustancias (SUD) y el estado de bienestar infantil, con las Entidades de Referencia que no son entidades cubiertas, sin la autorización del paciente.​​ 

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.​​ 

Solicitar la confirmación del DHCS sobre si las nuevas cartas de notificación de CLR a los miembros deben incluir los siguientes archivos adjuntos: NOA, Sus derechos, Audiencia estatal y formulario de IMR.​​ 

La notificación a los Miembros debe cumplir con todos los requisitos existentes según APL 21-011. Los requisitos de notificación de miembros de CLR no son distintos de los de APL 21-011.​​ 

¿Exigirá DHCS a los planes que presenten las nuevas cartas de CLR para su revisión? Si es así, ¿cuál será el tiempo de respuesta para la revisión y aprobación?​​ 

Los MCP deben usar sus plantillas de notificación existentes para los servicios autorizados bajo APL 21-011 para cumplir con los requisitos de notificación de los miembros.​​ 

Planteando la preocupación de que múltiples notificaciones de los Miembros pudieran tener el efecto contrario, causando confusión en lugar de claridad. Actualmente, bajo APL 21-011, los miembros reciben una sola carta cuando se aprueban o deniegan los servicios de ECM. Con CLR, podrían recibir tres o más cartas con NOA, lo que puede generar preocupaciones innecesarias.​​ 

Además, los MCP a menudo descubren que los Miembros no saben que fueron remitidos para ECM en primer lugar. Hacer que el proveedor de ECM se comunique antes de que se envíe una carta de NOA sería un enfoque más centrado en los miembros, asegurándose de que entiendan la referencia y qué esperar. ¿Puede DHCS explorar formas de agilizar este proceso para reducir la confusión y mejorar la experiencia de los miembros?​​ 

La Guía de implementación de CLR se ha actualizado para reflejar solo un aviso requerido para los miembros en el momento de la autorización en consonancia con los requisitos de APL 21-011. ECM ha estado sujeto a los requisitos de notificación de miembros de APL 21-011 desde su creación en 2022.​​ 

El ejemplo citado de los Miembros que no están al tanto de la remisión realizada en su nombre a ECM representa una oportunidad de asistencia técnica para que los MCP con Entidades Referentes mejoren las prácticas de las Entidades de Remisión de discutir las remisiones con el Miembro antes de completar una remisión, como se describe en la Guía de Implementación de CLR.​​ 

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?​​ 

En el Anexo G del contrato MCP, el Anexo de Socios Comerciales, § 9.2, se proporciona orientación sobre lo que califica como un método electrónico seguro. Esta sección incluye obligaciones relacionadas con las salvaguardas y la seguridad de PHI, incluido el cumplimiento de la subparte C de 45 CFR Parte 164. El DHCS recomienda que los MCP consulten con su asesor legal para determinar los medios seguros de intercambio electrónico de información para cumplir con los requisitos de notificación de CLR. Es posible que los MCP deseen explorar el correo electrónico seguro o métodos similares e idear plantillas de notificación que compartan la información mínima necesaria para cumplir con los requisitos de APL 21-011 y la Guía de implementación de CLR.​​ 

Se solicitó una aclaración al DHCS sobre las expectativas de notificación/comunicación para los miembros mientras están encarcelados.​​ 

El DHCS recomienda diseñar un Aviso de Membresía para los Miembros encarcelados en coordinación con el coordinador de servicios de pre-liberación en cada institución correccional para determinar la dirección y los medios apropiados para compartir la notificación de manera confidencial que recibe el Miembro.​​ 

Las solicitudes de servicio (referencias) son presentadas regularmente por los proveedores de Apoyo Comunitario para referir a los Miembros a su respectiva organización para los servicios de Apoyo Comunitario. Los proveedores de Apoyos Comunitarios asignados que prestan los servicios son la Entidad de Referencia. La misma agencia que inició la remisión proporcionaría actualizaciones de CLR a través del RTF. En estos casos, ¿son necesarias las notificaciones de CLR tras el cierre del bucle? Si es así, notificar al proveedor/entidad de referencia de apoyo a la comunidad parece redundante y agrega carga administrativa al MCP para enviar una notificación al proveedor/entidad de referencia de apoyo a la comunidad que ya está al tanto del cierre del ciclo de referencia, ya que es la misma entidad que notificó al MCP el estado de referencia a través de la presentación RTF.​​  

Sí, el requisito de notificación de CLR tras el cierre del bucle de referencia sigue aplicándose en el caso de uso de que la entidad de referencia también sea el proveedor de servicios final. DHCS mantiene este requisito por las siguientes razones:​​ 

• 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.​​ 

En el caso de que la Referencia se coloque para un Apoyo Comunitario y la Entidad Referente también sea el Proveedor de Servicios, mantener los requisitos de notificación para el Cierre del Bucle de Referencia proporciona una importante verificación de la calidad de los datos tanto para los MCP como para los Proveedores. Además, los requisitos de CLR para la supervisión y el apoyo de CLR enfatizan el papel de los MCP en la revisión de las razones de cierre del bucle de referencia por parte del proveedor de servicios para identificar brechas en los enfoques de participación y las mejores prácticas. Finalmente, los requisitos de CLR para la notificación de cierre de bucle de referencia no están sujetos a APL 21-011 y permiten a los MCP flexibilidad en el envío de notificaciones electrónicas por lotes a las entidades remitentes con un alto volumen de cierres de bucle de referencia cada mes.​​ 

De acuerdo con APL 21-011, los MCP actualmente envían cartas de decisión de autorización a las Entidades Referentes. En el caso de denegaciones de solicitudes de servicio, las Entidades Referentes ya reciben una carta informándoles de la denegación y el motivo de la denegación. Por lo tanto, sería una duplicación enviar la notificación de cierre de CLR y la carta de decisión de autorización a las Entidades Referentes, ya que estas dos comunicaciones se enviarían al mismo tiempo. ¿Puede el DHCS aclarar si los MCP deben enviar notificaciones de CLR por separado a las entidades de referencia para el estado de CLR: Cerrado, Cierre de CLR Motivo: Autenticación de servicio denegada?​​  

Si el MCP niega la autorización del servicio, entonces el aviso de autorización de la denegación a la Entidad Referente es suficiente. Por lo tanto, en el caso de cierre de CLR debido a una autorización denegada, no se requiere un aviso de cierre de CLR por separado.​​ 

Formulario de referencia de ECM​​ 

Sírvase aclarar si el formulario de referencia de ECM sirve como solicitud de autorización, ya que no hay espacio en el formulario para los códigos de ECM o la calidad de las unidades.​​ 

Sí, los Estándares de Referencia y la Plantilla de Formulario de ECM sirven como una referencia de ECM a los MCP en nombre de un Miembro que desencadena una solicitud de autorización para ECM. A lo largo de la Guía de políticas de ECM, el DHCS describe que las referencias de ECM desencadenan los plazos de revisión de autorización y los requisitos de notificación de APL 21-011.​​  

DHCS’ policy is that MCPs cannot ask community partners or ECM Providers to submit additional documentation beyond the ECM Referral Standards to make ECM authorization determinations. For example, Referring Entities are not required to provide supplemental eligibility checklists, outreach authorization forms, ICD-10 codes, proof of homelessness, Treatment Authorization Request (TAR) forms, or other extra information beyond what is specified in the ECM Referral Standards to confirm eligibility and authorize ECM (please see sections on Referrals and Authorizations in the ECM Policy Guide for details (p 107)).​​ 

Muchas referencias/solicitudes de autorización de ECM se originan en fuentes externas a los propios proveedores de ECM, y DHCS no incluye códigos o unidades de autorización en los Estándares de referencia de ECM. Entendemos que es posible que algunos equipos de ECM de MCP necesiten colaborar con sus equipos de mensajería unificada para describir los nuevos requisitos y ajustar los procesos de mensajería unificada para adaptarse.​​ 

Algunos recursos adicionales y relevantes para la autorización y codificación de ECM:​​ 

• Las autorizaciones de ECM deben tener un período de autorización inicial de 12 meses:​​ 
• (Actualizado en julio de 2023) Plazos estándar de autorización de ECM: Para todos los Miembros autorizados a recibir ECM por su MCP, el período de autorización inicial será de 12 meses y el período de reautorización será de 6 meses. Los MCP no pueden imponer requisitos adicionales para la autorización de servicios de ECM más allá de los criterios de elegibilidad de la Población de Enfoque especificados por el DHCS. Por ejemplo, los MCP no pueden retener una autorización hasta que se haya completado un plan de atención. (Página 108, ECM PG)​​ 
• Guía ECM HCPCS – Códigos estandarizados para reclamaciones y encuentros​​ 

Informes JSON​​ 

¿Puede el DHCS reconsiderar la solicitud de informes JSON en torno a los elementos de CLR hasta al menos el 1de enero de 2026? Sería prudente trasladar los informes JSON de CLR al menos al 1de enero de 2026, para permitir que la implementación del proceso y el intercambio de datos se implementen completamente de manera adecuada.​​ 

Las plantillas JSON de CLR de la fase 4, incluidos los elementos de datos de CLR para los datos de supervisión, se publicaron en los MCP en febrero de 2025 con un programa de pruebas asociado, y la guía final de JSON de la fase 4 se publicó el 28de marzo de 2025. En diciembre de 2024 se publicaron todas las directrices para actualizar ECM y las herramientas de intercambio de información de apoyo a la comunidad (MIF, RTF y ASF), con actualizaciones específicas para admitir CLR que se describen en los documentos.​​  

DHCS recomienda encarecidamente a los MCP que avancen con la actualización de la Guía de Intercambio de Información para Miembros en consonancia con los requisitos publicados en diciembre de 2024 y brinden asistencia técnica y apoyo a los Proveedores de ECM y Apoyos Comunitarios para el 1de julio de 2025de julio de 2011 y la nueva Guía de Intercambio de Información para Miembros.​​