一般實施​​ 

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

在 CLR 政策於 2025 7 月 1 日生效後，DHCS 將為 MCP 提供寬限期，以便在 CLR 系統和流程實施。儘管 DHCS 預計 MCP 將在 2025 7 月 1 之前實施 CLR，但 DHCS 確認可能需要額外的時間來改善 CLR 操作和實施要求，例如注意和跟踪方法、系統更新和啟動日期後的工作流程。因此，DHCS 將從 7 月 1 2026 開始主動監控合規性。​​ 

追蹤會員推薦​​ 

MCP 有時會直接從加強護理管理 (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 追蹤和通知要求如何適用於清醒中心？24 小時服務是否需要會員通知？​​ 

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 中現有狀態欄位之間的互動提供行人路口，並從 ECM RTF 中移除新的 CLR 狀態要求，而改為使用現有的 ECM 狀態進行 CLR 跟踪？ECM RTF 已經通過建立的狀態跟踪 CLR，但新的 CLR 狀態並不對齊，從而造成不必要的複雜性。移除它們可以減少混亂和管理負擔，同時維持流程的一致性。​​ 

DHCS 無法容納移除「轉介狀態」變數的要求，因為這是標準化 CLR 追蹤的關鍵值。但是，DHCS 正在研究可能的解決方案，同時考慮對移除現有字段的影響的 MCP 反饋。​​   

由於當前 ECM 工作流程中尚不清楚如何區分轉介狀態 1 — 已接受和 3-待處理狀態之間的區別，DHCS 能否提供澄清。​​ 

“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 可以提供符合此要求的程序的清晰示例嗎？​​ 

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

有關根據假設授權安排的 ECM 提供者向 MCP 的轉介/授權請求編碼指引，請參閱《CLR 實施指引》附錄 B 第 1.A.3 節。​​ 

DHCS 期望 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.​​ 

當轉介長期待處理時，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 起計七天）處理 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/社區支持授權，MCP 仍會向會員提供授權決定的通知。不適用其他注意要求。​​ 

如果成員選擇不接收來自 MCP 的書面通知，會員會注意到什麼期望？​​ 

如果他們選擇不接受書面通訊，MCP 應遵循其內部政策，就其他方法與會員聯絡提供重要資料或 NOA 的方法。例如，如果會員選擇退出書面通訊，MCP 可以改為通過電話或允許安全的電子方式與會員聯繫。​​ 

由於會員已註冊 ECM，因為會員已註冊 ECM 而拒絕 ECM 授權時，會員是否適用注意要求？​​ 

是的，所有轉介給 ECM 和社群支援都是授權請求，並觸發 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 在《中國安排》實施指引中所定義的推薦實體？​​ 

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 要求書面澄清，以確認 MCP 可能在未經患者授權的情況下，與非受保實體的推薦實體共享 PHI，包括嚴重精神疾病（SMI）/藥物使用障礙（SUD）和兒童福利狀態。​​ 

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。在發送 NOA 信件之前，要求 ECM 提供商與我們聯繫，將是一種以會員為中心的方法，確保他們了解轉介以及預期的情況。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?​​ 

MCP 合約附件 G、《商業關係人附錄》第 9.2 條提供了有關哪些資格為安全電子方法的指引。本節包括與 PHI 保安措施和安全相關的義務，包括遵守 45 CFR 第 164 部分 C 章。DHCS 建議 MCP 諮詢其法律顧問，以確定安全的電子信息共享方式，以滿足 CLR 通知要求。MCP 可能希望探索安全的電子郵件或類似的方法，並設計通知模板，以共享最低必要信息以滿足 APL 21-011 和 CLR 實施指南的要求。​​ 

DHCS 要求澄清關於在監禁期間會員的通知/通訊期望。​​ 

DHCS 建議與每個懲教機構的釋放前服務協調人員協調為被監禁成員設計會員通知，以確定會員收到的機密方式分享通知的適當地址和方式。​​ 

社群支援服務供應商定期提交服務請求（轉介），以將會員推薦給其各自的組織以獲取社區支援服務。提供服務的指派社群支援提供者是「推薦實體」。啟動轉介的同一機構將通過 RTF 提供 CLR 更新。在這些情況下，循環關閉時是否需要 CLR 通知？如果是這樣，通知社區支持供應商/推薦實體似乎是多餘的，而且會增加了管理負擔，向社區支持提供商/推薦實體發送通知的社區支持提供商/推薦實體，因為他們是通過 RTF 提交的提交通知 MCP 相同的實體。​​  

是的，在推薦實體也是最終服務提供者的使用情況下，轉介循環結束時，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 轉介標準和表格範本可用作代表成員向 MCP 轉介的 ECM，從而觸發 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 年 7 月更新）標準 ECM 授權時間範圍：對於所有由其 MCP 授權接收 ECM 的會員，初始授權期將為 12 個月，重新授權期為 6 個月。超過 DHCS 指定的焦點群體資格標準之外，MCP 不得對 ECM 服務授權的額外要求。例如，在完成護理計劃之前，MCP 可能不會拒絕授權。(第 108 頁, 商務委員會頁面)​​ 
• ECM HCPCS 指南 — 索償和遇見的標準化代碼​​ 

JSON 報告​​ 

DHCS 可以重新考慮要求關於 CLR 元素的任何 JSON 報告，直到至少 1 月 1，2026 為止？將 CLR JSON 報告轉移至至少 1 2026，以便完全適當地實施過程實施和數據交換是謹慎的。​​ 

包含用於監控資料的 CLR 資料元素的第 4 階段 CLR JSON 範本已於 2025 年 2 月發佈至 MCP，並具有相關的測試時間表，而最終的第 4 階段 JSON 指南已於 2025 3 月 28 發布。更新 ECM 和社區支持信息共享工具（MIF、RTF 和 ASF）的所有指南都在 2024 年 12 月發布，其中文件中概述了支持 CLR 的具體更新。​​  

DHCS 強烈鼓勵 MCP 繼續根據 2024 年 12 月發布的要求更新會員信息共享指南，並為 7 月 1, 2025 的新會員信息分享指南提供技術協助和支持給 ECM 和社區支持提供商提供技術協助和支持。​​