Загальне впровадження​​ 

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 надає MCP пільговий період для впровадження систем і процесів CLR після того, як політика CLR набуде чинності 1 липня 2025. Хоча DHCS очікує, що MCP впровадять CLR до липня 1, 2025, DHCS визнає, що після дати запуску може знадобитися додатковий час для вдосконалення операційних та впровадницьких вимог CLR, таких як методології виявлення та відстеження, оновлення системи та робочі процеси. Таким чином, DHCS почне активний моніторинг дотримання вимог, починаючи з липня 1, 2026.​​ 

Відстеження рефералів учасників​​ 

Медичні працівники іноді отримують часту та цінну інформацію про направлення та статус залучення безпосередньо від своїх постачальників послуг розширеного управління медичним обслуговуванням (ECM). Чи можливо включити альтернативні джерела даних для виконання вимог відстеження CLR окрім згадки про додаткові заяви та дані про зустрічі?​​ 

MCP можуть використовувати альтернативні джерела даних для доповнення джерел відстеження CLR, зазначених у керівництві; однак MCP не можуть вимагати від ECM/постачальників підтримки громад надання даних для відстеження засобами, відмінними від файлу зворотної передачі (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.​​ 

Як вимоги до відстеження та повідомлення CLR застосовуються до центрів витверезення?  Чи потрібне повідомлення учасника для цілодобового обслуговування?​​ 

Вимоги CLR не застосовуватимуться до центрів витверезіння, оскільки послуги часто надаються в режимі реального часу, тривалість перебування в них становить менше 24 годин, а послуги зазвичай авторизуються ретроактивно, щоб полегшити своєчасний доступ до цієї громадської підтримки.​​ 

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

Вимога повідомляти про причину закриття циклу направлення організаціям, що направляють, вимагає обміну захищеною медичною інформацією (PHI) з організаціями, що не охоплюються страховкою, без дозволу Учасника. MCP вважають, що ця вимога не відповідає HIPAA, і просять DHCS вилучити її.​​ 

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

Чи може DHCS забезпечити перехрестя для взаємодії між новими полями стану CLR та існуючими полями стану в RTF, а також видалити нові вимоги до стану CLR з RTF ECM та натомість використовувати існуючі статуси ECM для відстеження CLR? ECM RTF вже відстежує CLR через встановлені статуси, але нові статуси CLR не узгоджуються, що створює зайву складність. Їх усунення зменшило б плутанину та адміністративне навантаження, зберігаючи при цьому узгодженість процесів.​​ 

DHCS не може задовольнити запит на видалення змінної «Статус направлення», оскільки це ключове значення для стандартизації відстеження CLR. Однак DHCS працює над можливими рішеннями, враховуючи відгуки MCP щодо наслідків видалення існуючих полів.​​   

Чи може DHCS надати роз'яснення щодо різниці між статусом направлення 1 – Прийнято та 3 – Очікує розгляду, оскільки в поточному робочому процесі ECM незрозуміло, як їх розрізняти.​​ 

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

Члени MCP стурбовані тим, що DHCS дозволяє постачальникам послуг відхиляти направлення, що може призвести до вибіркового прийняття членами та потенційної дискримінації. Наприклад, відмова обслуговувати трансгендерних осіб або носіїв певних мов. Чи може DHCS, будь ласка, переглянути цей варіант CLR або запровадити запобіжні заходи проти дискримінації членів?​​ 

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

Підтверджено. DHCS передбачає, що це може змінюватися залежно від відомих потреб Учасника та типу послуги. Згідно з інструкціями з впровадження CLR, усі статуси направлень необхідно оновлювати принаймні щомісяця.​​ 

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

Як DHCS контролюватиме дотримання вимоги відповідати на запити Членів протягом одного робочого дня?​​ 

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

Запитується роз'яснення від DHCS щодо очікуваних подальших дій, пов'язаних з членами, яким відмовлено в послугах через їхню відповідність вимогам. Чи може DHCS надати чіткий приклад процедури, яка відповідає цій вимозі?​​ 

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

Будь ласка, зверніться до Додатка B Розділу 1.A.3. Керівництва з впровадження CLR для отримання інструкцій щодо кодування направлень/запитів на авторизацію, що надходять від постачальників ECM до MCP відповідно до домовленостей про презумптивну авторизацію.​​ 

Про який рівень статусу очікує звітності від MCP Департамент охорони здоров'я та соціальних служб (DHCS)?​​ 

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

Якого рівня втручання очікує DHCS, якщо направлення залишаються в очікуванні протягом тривалого періоду? Чи потрібно це закріплювати в Меморандумі про взаєморозуміння (МВ) з кожним агентством?​​ 

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

Що робити, якщо кожна установа запитує різні втручання від MCP (наприклад, WIC каже повідомляти протягом п'яти робочих днів про направлення, що очікують розгляду, Регіональний центр каже повідомляти протягом 30 робочих днів тощо)?​​ 

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

Як MCP повинні підходити до дублікатів направлень від одного й того ж Члена та для однієї й тієї ж послуги? Будь ласка, надайте додаткові вказівки з цього приводу.​​ 

Будь ласка, дивіться приклади сценаріїв нижче:​​ 

• Сценарій 1: Направлення на послугу, на яку Учасник вже має дозвіл. У випадку, якщо MCP отримує направлення на (наприклад, ECM), а Учасник вже має відкрите доручення на ECM, MCP повинен зафіксувати ключову інформацію про направлення в отриманні направлення (дата, Орган, що направляє, послуга) та відповідне рішення про доручення (наприклад, відмовлено) та надати необхідний контекст Органу, що направляє, у Повідомленні про дії (NOA) про відмову (наприклад, Учаснику відмовлено, оскільки він вже має активне, відкрите доручення ECM). Постачальники медичних послуг (MCP) також повинні надати контактну інформацію для того, щоб Організація, що направляє,/Учасник міг зв’язатися з MCP, якщо вони бажають подати запит на зміну Постачальника послуг для свого поточного відкритого авторизації, якщо це можливо.​​ 
• 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 Помічає​​ 

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

У цьому сценарії MCP є суб'єктом, що направляє, і вимоги щодо повідомлення не застосовуються. Однак, як найкраща практика, DHCS закликає MCP інформувати Членів про те, що вони мають право на отримання послуги та були направлені на неї, щоб збільшити ймовірність залучення Членів.​​ 

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 розуміє, що MCP може знадобитися додатковий час для отримання та обробки даних після отримання RTF від постачальників. MCP мають до п’яти робочих днів для обробки RTF та повідомлення Органу, що надсилає дані, протягом двох робочих днів після завершення обробки даних (сім днів загалом з моменту отримання RTF, якщо необхідно).​​ 

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

У випадку, якщо Учасник, його опікун/доглядач, член сім'ї, друг чи сусід подає направлення та запит на отримання дозволу ECM/Community Supports, MCP все одно повідомлять Учасника про рішення щодо дозволу. Жодних інших вимог щодо повідомлення не застосовується.​​ 

Чого очікувати від Учасника, якщо він відмовився від отримання письмових повідомлень від MCP?​​ 

MCP повинні дотримуватися своїх внутрішніх політик щодо альтернативних методів зв'язку з Членами щодо ключової інформації або NOA у випадку, якщо вони відмовилися від отримання письмових повідомлень. Наприклад, MCP може натомість зв’язатися з Учасником телефоном або дозволеним, безпечним електронним способом, якщо він відмовився від письмового спілкування.​​ 

Чи застосовуються вимоги щодо повідомлення Учасника, коли в авторизації ECM відмовлено через те, що Учасник вже зареєстрований в ECM?​​ 

Так, усі звернення до ECM та Community Supports є запитом на авторизацію та призводять до вимог щодо повідомлення APL 21-011. Згідно з APL 21-011, MCP повинні використовувати відповідний шаблон NOA, який повинен містити стислий опис причин рішення. У випадку, якщо ECM відхилено через існуючу авторизацію, MCP повинні чітко повідомити причину відмови та запропонувати спосіб зв’язку з MCP, щоб за потреби змінити свого постачальника ECM.​​ 

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 вимагає від MCP використовувати електронний метод (крім факсу) для обміну повідомленнями з організаціями, що надсилають повідомлення, якщо не буде взаємно узгоджено інші неелектронні методи. Ця вимога викликає правові занепокоєння щодо можливості обміну інформацією електронною поштою.​​ 

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

Чи може DHCS уточнити, чи вимоги щодо повідомлення, детально описані в APL 21-011 для постачальників (тобто MCP має повідомити постачальника протягом 24 годин після прийняття рішення), також застосовуються до організацій, що направляють, як це визначено DHCS у Керівництві з впровадження 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.​​ 

Від DHCS запитується письмове роз'яснення щодо того, що медичні працівники можуть надавати захищену медичну інформацію (ЗМІ), включаючи серйозні психічні захворювання (СЗЗ)/розлади, пов'язані зі вживанням психоактивних речовин (РЗП), та статус соціального забезпечення дитини, організаціям, що направляють пацієнтів, які не є охопленими організаціями, без дозволу пацієнта.​​ 

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

Запитую підтвердження DHCS щодо того, чи повинні нові листи-повідомлення CLR для членів містити такі додатки: NOA, Ваші права, Державне слухання та форму IMR.​​ 

Повідомлення для Членів повинно відповідати чинним, повним вимогам APL 21-011. Вимоги щодо повідомлення членів CLR нічим не відрізняються від APL 21-011.​​ 

Чи вимагатиме DHCS від планів подання нових листів, звернених до членів CLR, на розгляд? Якщо так, то який буде час для розгляду та затвердження?​​ 

MCP повинні використовувати свої існуючі шаблони повідомлень для авторизованих послуг згідно з APL 21-011, щоб відповідати вимогам щодо повідомлень Членів.​​ 

Висловлюється занепокоєння, що численні повідомлення членів можуть мати протилежний ефект, спричиняючи плутанину, а не ясність. Наразі, згідно з APL 21-011, учасники отримують один лист, коли їм схвалено або відмовлено в послугах ECM. З CLR вони можуть отримати три або більше листів з NOA, що може призвести до зайвого занепокоєння.​​ 

Крім того, MCP часто виявляють, що члени навіть не знають, що їх взагалі направили на ECM. Звернення постачальника ECM до надсилання листа NOA було б більш орієнтованим на учасників підходом, що гарантувало б розуміння ними суті звернення та того, чого очікувати. Чи може DHCS дослідити способи оптимізації цього процесу, щоб зменшити плутанину та покращити досвід членів?​​ 

Керівництво з впровадження CLR було оновлено, щоб відобразити лише одне обов'язкове повідомлення для Членів під час авторизації відповідно до вимог APL 21-011. З моменту свого заснування у 2022 році ECM підпадає під вимоги APL 21-011 щодо повідомлення членів.​​ 

Наведений приклад того, що Члени не знали про направлення, зроблене від їхнього імені до ECM, представляє собою можливість технічної допомоги для MCP з Органами, що надають направлення, для покращення практики Органів, що надають направлення, щодо обговорення направлень з Членом перед завершенням направлення, як це зазначено в Керівництві з впровадження 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?​​ 

Вказівки щодо того, що кваліфікується як безпечний електронний метод, наведені у Додатку G до договору MCP, Додатку для ділових партнерів, § 9.2. Цей розділ містить зобов'язання, пов'язані із гарантіями та безпекою PHI, зокрема дотримання підрозділу C частини 164 45 CFR. DHCS рекомендує MCP проконсультуватися зі своїми юрисконсультами, щоб визначити безпечні засоби електронного обміну інформацією для виконання вимог CLR щодо повідомлення. MCP можуть дослідити безпечну електронну пошту або аналогічні методи та розробити шаблони повідомлень, які містять мінімально необхідну інформацію для виконання вимог APL 21-011 та Керівництва з впровадження CLR.​​ 

Запитується роз'яснення від DHCS щодо очікуваних повідомлень/комунікації для членів під час перебування у в'язниці.​​ 

DHCS рекомендує розробити систему інформування ув'язнених членів у координації з координатором послуг з підготовки до звільнення в кожній виправній установі, щоб визначити відповідну адресу та способи поширення повідомлення конфіденційним чином, яке отримає член.​​ 

Постачальники послуг громадської підтримки регулярно подають запити на послуги (направлення) для направлення Учасників до їхньої відповідної організації для отримання послуг громадської підтримки. Призначені постачальники послуг підтримки громади, які надають послуги, є Органом, що направляє. Та сама установа, яка ініціювала направлення, надаватиме оновлення CLR через RTF. У цих випадках чи потрібні сповіщення CLR після закриття циклу? Якщо так, то повідомлення постачальника послуг підтримки громади/організації, що направляє, видається зайвим і додає адміністративного навантаження на MCP щодо надсилання повідомлення постачальнику послуг підтримки громади/організації, що направляє, який вже знає про закриття циклу направлення, оскільки це та сама організація, яка повідомила MCP про статус направлення через подання RTF.​​  

Так, вимога щодо повідомлення CLR після закриття циклу направлення все ще застосовується у випадку використання, коли суб'єкт, що здійснює направлення, також є кінцевим постачальником послуг. DHCS зберігає цю вимогу з таких причин:​​ 

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

У випадку, якщо направлення подається для отримання підтримки громади, а організація, що направляє, також є постачальником послуг, дотримання вимог щодо повідомлення про закриття циклу направлення забезпечує важливу перевірку якості даних як для MCP, так і для постачальників. Крім того, вимоги CLR щодо моніторингу та підтримки CLR підкреслюють роль MCP у розгляді причин закриття циклу направлення постачальником послуг з метою виявлення прогалин у підходах до взаємодії та найкращих практиках. Зрештою, вимоги CLR щодо сповіщення про закриття циклу направлення не підпадають під дію APL 21-011 та дозволяють MCP гнучко надсилати пакетні електронні сповіщення організаціям, що здійснюють направлення, з великою кількістю закриттів циклу направлення щомісяця.​​ 

Згідно з APL 21-011, MCP наразі надсилають листи про рішення щодо авторизації організаціям, що направляють запити. У разі відмови у наданні послуг, Органи, що надають послуги, вже отримують лист, у якому їх повідомляють про відмову та причину відмови. Таким чином, надсилання повідомлення про закриття CLR та листа про рішення про авторизацію до суб'єктів, що направляють запит, було б дублюванням, оскільки ці два повідомлення надсилатимуться одночасно. Чи може DHCS, будь ласка, уточнити, чи повинні MCP надсилати окремі сповіщення CLR суб'єктам, що направляють запит, для статусу CLR: Закрито, Причина закриття CLR: Відмовлено в авторизації послуги?​​  

Якщо MCP відмовляє у наданні послуги, то достатньо повідомлення про відмову у наданні авторизації, надісланого Референтній особі. Таким чином, у разі закриття CLR через відмову в авторизації окреме повідомлення про закриття CLR не потрібне.​​ 

Форма направлення ECM​​ 

Будь ласка, уточніть, чи служить форма направлення ECM запитом на авторизацію, оскільки у формі немає місця для кодів ECM або якості одиниць.​​ 

Так, Стандарти та шаблон форми направлення ECM слугують направленням ECM до MCP від імені Членів, що ініціює запит на авторизацію ECM. У Посібнику з політики ECM DHCS зазначає, що звернення ECM запускають терміни перегляду авторизації та вимоги щодо повідомлення, передбачені 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)).​​ 

Багато направлень/запитів на авторизацію ECM надходять з джерел поза межами самих постачальників ECM, а DHCS не включає коди авторизації або одиниці вимірювання до Стандартів направлень ECM. Ми розуміємо, що деяким командам MCP ECM може знадобитися співпрацювати зі своїми командами UM, щоб описати нові вимоги та скоригувати процеси UM відповідно до них.​​ 

Кілька додаткових, релевантних ресурсів щодо авторизації та кодування ECM:​​ 

• Авторизації ECM повинні мати початковий термін дії 12 місяців:​​ 
• (Оновлено в липні 2023 р.) Стандартні терміни авторизації ECM: Для всіх Учасників, яким їх MCP дозволив отримувати ECM, початковий період авторизації становитиме 12 місяців, а період повторної авторизації — 6 місяців. MCP не можуть встановлювати додаткові вимоги для авторизації послуг ECM, окрім критеріїв відповідності для населення фокусної групи, визначених DHCS. Наприклад, медичні працівники (MCP) не можуть відмовити у видачі дозволу, доки не буде завершено план догляду. (Сторінка 108, ECM PG)​​ 
• Керівництво ECM HCPCS – Стандартизовані коди для претензій та зіткнень​​ 

Звітність JSON​​ 

Чи може DHCS переглянути запит на будь-які звіти JSON щодо елементів CLR принаймні до січня 1, 2026? Було б доцільно перенести звітність CLR JSON принаймні на січень 1, 2026, щоб забезпечити повну та належну реалізацію процесів та обмін даними.​​ 

Шаблони JSON CLR фази 4, що включають елементи даних CLR для моніторингу, були опубліковані для MCP у лютому 2025 року разом із відповідним графіком тестування, а остаточне керівництво JSON фази 4 було опубліковано у березні 28, 2025. Усі інструкції щодо оновлення ECM та інструментів обміну інформацією для підтримки спільноти (MIF, RTF та ASF) були випущені в грудні 2024 року, а конкретні оновлення для підтримки CLR були викладені в документах.​​  

DHCS наполегливо закликає MCP продовжити оновлення Керівництва щодо обміну інформацією для членів відповідно до вимог, опублікованих у грудні 2024 року, та надавати технічну допомогу та підтримку ECM та постачальникам підтримки громад для липня 1, 2025, коли нові Керівництва щодо обміну інформацією для членів будуть введені в дію.​​