跳至内容​​ 
首页CalAIM:改革加州医疗保险闭环转介常见问题​​ 

Closed Loop Referral (CLR) FAQ​​ 

一般实施​​ 

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 将在 7 月1 、 2025之前实施 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 能否为 RTF 中新的 CLR 状态字段和现有状态字段之间的交互提供交叉对照,并从 ECM RTF 中删除新的 CLR 状态要求,而使用现有的 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.​​ 

有关在推定授权安排下 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 期望采取何种程度的干预?这是否需要在与每个机构的谅解备忘录(MOU)中予以纪念?​​ 

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 还应提供推荐实体/会员的联系信息,以便其联系 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/社区支持授权,MCP 仍将向会员提供授权决定的通知。不适用其他注意要求。​​ 

如果会员选择不接收 MCP 的书面通知,会员需要注意什么?​​ 

如果会员选择不接收书面通信,MCP 应遵循其内部政策,采用其他方法与会员联系,提供关键信息或 NOA。例如,如果会员选择不进行书面沟通,MCP 可以通过电话或允许的安全电子方式联系会员。​​ 

当会员已注册 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 在 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 提供书面澄清,确认 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 的要求。ECM 自 2022 年成立以来一直受到 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 通知?如果是这样,通知社区支持提供商/推荐实体似乎是多余的,并且增加了 MCP 的管理负担,需要向社区支持提供商/推荐实体发送通知,而后者已经知道推荐循环闭合,因为他们是通过 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 个月。MCP 不得对 DHCS 指定的重点人群资格标准以外的 ECM 服务授权施加额外要求。例如,MCP 不得在护理计划完成之前拒绝授权。(第 108 页,ECM PG)​​ 
  • ECM HCPCS 指南 – 索赔和遭遇的标准化代码​​ 

JSON 报告​​ 

DHCS 能否重新考虑至少在 1 月1和2026之前要求提供有关 CLR 元素的任何 JSON 报告?将 CLR JSON 报告移至至少 1 月1和2026是明智之举,这样才能让流程实施和数据交换得到充分适当的实施。​​ 

包含用于监控数据的 CLR 数据元素的阶段 4 CLR JSON 模板已于 2025 年 2 月向 MCP 发布,并附带相关测试计划,最终阶段 4 JSON 指南已于 3 月28 、 2025发布。所有更新 ECM 和社区支持信息共享工具(MIF、RTF 和 ASF)的指南均于 2024 年 12 月发布,其中包含文件中概述的支持 CLR 的具体更新。​​  

DHCS 强烈鼓励 MCP 根据 2024 年 12 月发布的要求继续更新会员信息共享指南,并为 ECM 和社区支持提供商提供技术援助和支持,以便在 7 月1 、 2025日起实施新的会员信息共享指南。​​