跳至主要内容​​ 

闭环转诊 (CLR) 常见问题​​ 

一般实施​​ 

卫生保健服务部 (DHCS) 能否澄清一下,DHCS 将在1年 7 月2025日生效一年后开始对 Medi-Cal 管理式医疗计划 (MCP) 实施 CLR 的情况进行合规性审查,这意味着什么?DHCS 是否希望 MCP 能够在 7 月1 、 2025之前完全符合 CLR 要求?​​ 

在 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) 之外的方式提交跟踪数据。​​ 

如果 ECM 或社区支持提供商通过 RTF 中包含的数据确认服务已提供或开始,DHCS 是否会确认 MCP 可以将循环关闭为“已收到服务”?计费服务一词意味着 MCP 已收到索赔,这可能需要六个月的时间。​​ 

一旦提供商通过 RTF 中的转介循环闭合原因数据元素确认已提供服务,MCP 便可将 CLR 循环闭合为“已收到服务”。​​ 

CLR 跟踪和通知要求如何适用于醒酒中心?24 小时服务是否需要通知会员?​​ 

CLR 要求不适用于醒酒中心,因为服务通常是实时提供的,停留时间不到 24 小时,并且服务通常是追溯授权的,以方便及时获得此社区支持。​​ 

DHCS 能否澄清 ECM 和社区支持提供商对“拒绝”转诊状态值的预期用途?​​ 

标准 CLR 推荐状态值可能随着时间的推移适用于一系列服务。目前,DHCS 预计 ECM 和社区支持服务提供商可能会因以下任何原因进入“拒绝”转介状态:提供商缺乏能力、会员不住在其服务区域内或其他原因。MCP 应与其网络提供商合作,并提供清晰的记录程序,以确定根据 ECM 和社区支持政策拒绝转诊的允许原因以及如何在转诊状态值中注明。DHCS 并不意味着 MCP 应该采用新政策来允许网络提供商拒绝转诊。​​ 

在 PHM 政策指南的 DHCS 附录:闭环转诊实施指南中,表 4:转诊处理列出了“服务提供商名称”和“服务提供商电话号码”。DHCS 能否澄清这是会员指定的首席护理经理吗?以及他们的电话号码?​​ 

“服务提供商名称”和“服务提供商电话号码”是从 MCP 或推荐实体接收 ECM 或社区支持推荐请求的实体(即服务提供商)的名称和电话号码。例如,在 CalAIM 数据指南:MCP 和 ECM 提供商之间的会员级信息共享指南的第 23-24 页上,信息将与“ECM 提供商名称”和“ECM 提供商电话号码”一致。这些字段的目的是确认 MCP 已记录联系信息,他们可以利用这些信息来支持会员针对适用 CLR 要求的不同提供商/服务的推荐和服务交付。​​ 

DHCS 能否解释“服务提供商组织名称”和“服务提供商名称”之间的区别?​​ 

“服务提供商组织名称”是ECM提供商(即组织名称)。“服务提供商名称”是被指定提供 ECM 服务的 ECM 首席护理经理(组织中分配给会员的人员)。​​ 

与推荐实体共享推荐环路闭合原因的要求要求在未经会员授权的情况下与未涵盖的实体共享受保护的健康信息 (PHI)。MCP 认为此要求不符合 HIPAA 并要求 DHCS 删除此要求。​​ 

1996 年《健康保险流通与责任法案》(HIPAA)允许涵盖实体(包括 MCP)在无需患者授权的情况下,出于某些目的使用或披露“受保护的健康信息”(PHI),包括治疗、付款或医疗保健运营(某些行政、法律、财务和质量改进活动,包括护理协调和病例管理)。此类披露既可以向其他涵盖实体(例如,医疗保健提供者)进行,也可以向非涵盖实体(例如,住房提供者、社区组织 (CBO))进行,只要披露是为了治疗、支付和医疗保健运营的目的。​​  

根据 HIPAA,转诊循环关闭原因和转诊循环关闭日期均构成 PHI;作为涵盖实体,MCP 可以与未涵盖实体共享该信息,而无需个人​​ 为了治疗和护理协调的目的进行双重授权。45 CFR 164.506(c)(1) 规定,涵盖实体可以出于自身治疗、支付和医疗保健运营目的使用和披露 PHI。​​ 

DHCS 能否为 RTF 中新的 CLR 状态字段和现有状态字段之间的交互提供交叉对照,并从 ECM RTF 中删除新的 CLR 状态要求,而使用现有的 ECM 状态进行 CLR 跟踪?ECM RTF 已经通过已建立的状态跟踪 CLR,但新的 CLR 状态并不一致,从而造成了不必要的复杂性。删除它们可以减少混乱和管理负担,同时保持流程的一致性。​​ 

DHCS 无法满足删除推荐状态变量的请求,因为这是标准化 CLR 跟踪的关键值。然而,DHCS 正在研究可能的解决方案,同时考虑 MCP 对删除现有字段的影响的反馈。​​   

DHCS 能否澄清转介状态 1(已接受)和 3(待处理)之间的区别,因为在当前的 ECM 工作流程中尚不清楚如何区分它们。​​ 

当提供商尚未查看转介并确认他们有能力为会员提供服务并打算启动外展时,“待定”是向 MIF 上的 ECM 或社区支持提供商提出的转介的默认转介状态。一旦提供商审核了推荐并打算联系会员但尚未这样做,就会显示“已接受”。有关推荐状态变量值的更多描述,请参阅 CLR 实施指南表 11。​​ 

MCP 担心 DHCS 允许提供商拒绝转介,这可能会导致选择性会员接受和潜在的歧视。例如,拒绝为变性人或某些语言的使用者提供服务。DHCS 能否重新考虑此 CLR 选项或实施防止会员歧视的保障措施?​​ 

标准 CLR 推荐状态值可能随着时间的推移适用于一系列服务。目前,DHCS 预计 ECM 和社区支持服务提供商可能会因以下任何原因进入“拒绝”转介状态:提供商缺乏能力、会员不住在其服务区域内或其他原因。MCP 应与其网络提供商合作,并提供清晰的记录程序,以确定根据 ECM 和社区支持政策拒绝转诊的允许原因以及如何在转诊状态值中注明。DHCS 并不意味着 MCP 应该采用新政策来允许网络提供商拒绝转诊。​​ 

DHCS 能否确认 MCP 有权自行定义“已开放较长时间的 CLR”?​​ 

确认的。DHCS 预计这可能会因会员的已知需求和服务类型而异。根据 CLR 实施指南,所有推荐状态必须至少每月更新一次。​​ 

DHCS 能否澄清“MCP 应在一个工作日内回复询问”要求中的“回复询问”是什么意思?​​ 

MCP 至少需要在一个工作日内确认收到询问并提供 CLR 的状态。例如,如果这是 MCP 对推荐状态的最新更新,则 MCP 可能会通知推荐实体或会员,推荐已获得授权并于 [日期] 传递给服务提供商进行外展。此要求的目的是让推荐合作伙伴更及时地了解推荐的状态,以便他们也能为会员提供最好的支持。目前,DHCS 不打算对此要求发布例外情况。​​ 

DHCS 将如何监控是否遵守在一个工作日内回复会员询问的要求?​​ 

DHCS 将于实施日期1年 7 月2025日一年后开始对 MCP 的 CLR 进行合规性审查。DHCS 可能会考虑要求提供临时文件、完成审计或采取其他措施来确保满足此要求,并将提前通知 MCP。​​ 

要求 DHCS 澄清有关因资格问题而被拒绝提供服务的会员的后续行动期望。DHCS 能否提供一个满足此要求的程序的清晰示例?​​ 

此要求的目的是提高导致最初转介至 ECM 或社区支持的需求仍然得到满足的可能性。如果由于资格问题导致 ECM 授权被拒绝,MCP 的下一步可能是考虑根据会员的需求申请 CCM,并提供 CCM 作为替代方案,或者通知会员的 D-SNP 他们对护理管理的需求,并确认会员已从 D-SNP 获得护理管理支持。​​ 

大多数 ECM 转介都会绕过该计划并直接转至 ECM 提供商,而这些提供商会假定招募会员。在不了解引荐来源的情况下,计划如何跟踪 CLR 的最小数据集?如果需要跟踪,这将给我们的 ECM 提供商网络增加大量报告和管理负担。​​ 

有关在推定授权安排下 ECM 提供商向 MCP 发出的转介/授权请求的编码指导,请参阅 CLR 实施指南附录 B 第 1.A.3 节。​​ 

DHCS 希望 MCP 报告什么级别的状态?​​ 

请参阅 CLR 实施指南中有关跟踪的部分,了解 MCP 需要根据 CLR 要求(ECM 和社区支持)跟踪服务的完整规范和数据元素。附录 B 提供了有关关键跟踪变量(例如“转诊状态”)的值的更多详细信息,以及如何通过每月 RTF 从 ECM 和社区支持提供商收集数据。2 月份发布的 JSON 第 4 阶段模板包含 CLR 监控提交的详细数据元素。​​ 

当转介长时间处于待处理状态时,DHCS 期望采取何种程度的干预?这是否需要在与每个机构的谅解备忘录(MOU)中予以纪念?​​ 

请参阅 CLR 实施指南第 II.B.2 节“支持待处理和重新转介”,了解 MCP 可以采取的一系列示例行动,以支持 ECM 和社区支持提供商处理待处理转介,以及在这些情况下与会员和转介实体进行跟进的建议。​​ 

如果每个机构都要求 MCP 采取不同的干预措施(例如,WIC 要求在五个工作日内通知待处理的转介,区域中心要求在 30 个工作日内通知,等等),该怎么办?​​ 

目前,CLR 要求仅适用于向 MCP 提出的 ECM 和社区支持推荐。CLR 通知要求概述了对通知引用实体的期望(例如社区组织 (CBO)、服务提供者、初级保健医生 (PCP)) 应按照 APL 21-011 中要求的时间表对转诊授权决定做出通知,并在规定的时间内对转诊关闭原因做出通知。有关详细的 MCP CLR 通知要求,请参阅 CLR 实施指南第 II.BI 节。​​ 

由于 MCP 需要使用 DHCS 转介表来获取 ECM/社区支持,MCP 是否可以修改此表格以包含“电子邮件地址”以用于电子通知目的?​​ 

ECM 推荐标准已将“推荐个人电子邮件地址”作为 ECM 推荐标准表 2 中的必需元素。无需更新即可收集此信息。​​ 

MCP 如何处理来自同一会员且针对同一服务的重复推荐?请就此提供进一步指导。​​ 

请参阅下面的示例场景:​​ 

    • 场景 1:推荐会员已经获得授权的服务。如果 MCP 收到推荐(例如 ECM),而会员已经拥有 ECM 的开放授权,则 MCP 应在推荐收据上记录关键推荐信息(日期、推荐实体、服务)和适当的授权决定(例如,被拒绝),并在拒绝行动通知 (NOA) 中向推荐实体提供必要的背景信息(例如,会员被拒绝是因为他们已经拥有有效的开放 ECM 授权)。如果 MCP 希望请求更改其当前开放授权的提供商(如适用),则 MCP 还应提供推荐实体/会员的联系信息,以便其联系 MCP。​​ 
    • 场景 2:会员正在处理另一项开放转介的服务转介。如果同一服务的两个转介同时向会员开放(例如推荐日期、推荐实体、服务、授权状态)。MCP 仍需满足第二个引用实体的 CLR 通知要求。DHCS 要求 MCP 记录两次转介的信息,因为如果重复的转介导致对分配合适的服务提供商产生不确定性,MCP 仍然期望通过与转介实体的沟通来支持转介,并支持与会员进行任何必要的协调。例如,如果两个不同的 ECM 提供商为会员提交推荐,则 MCP 有必要在会员和推荐 ECM 提供商之间进行协调,以便为会员分配一个首选的 ECM 提供商。

      MCP 应遵循现有的政策和程序,并审查由推荐实体推荐但被拒绝授权的会员的份额/数量。如果同一会员和同一服务的重复推荐数量较多,MCP 应促进讨论并与推荐实体提供技术援助,以增加符合资格并获得授权的推荐。​​ 

CLR 通知​​ 

如果 MCP 使用其内部数据识别出某个人有资格获得 ECM 或社区支持(即‘转介类型’为“2.由 MCP 识别”),是否适用注意要求?​​ 

在这种情况下,MCP 是推荐实体,并且不适用通知要求。然而,作为最佳实践,DHCS 鼓励 MCP 告知会员他们符合资格并且已被推荐接受服务,以增加会员参与的可能性。​​ 

MCP 通常需要花费一些时间来从提供商处获取和清理 RTF 数据。转诊环路关闭的两个工作日的“通知时钟”何时开始?​​ 

DHCS 了解 MCP 在收到提供商的 RTF 后可能需要额外的时间来提取和处理数据。MCP 最多有五个工作日的时间来处理 RTF,并在完成数据处理后的两个工作日内通知推荐实体(如果需要,从收到 RTF 起总共需要七天)。​​ 

请 DHCS 确认 MCP 将如何继续注意推荐实体是否是会员?会员的监护人或照顾者?会员的家人、朋友或邻居?​​ 

如果会员、其监护人/看护人或家庭成员、朋友或邻居提出转介并请求 ECM/社区支持授权,MCP 仍将向会员提供授权决定的通知。不适用其他注意要求。​​ 

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

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

当会员已注册 ECM 而导致 ECM 授权被拒绝时,是否适用会员通知要求?​​ 

是的,所有对 ECM 和社区支持的推荐都是授权请求,并触发 APL 21-011 注意要求。根据 APL 21-011,MCP 必须使用适当的 NOA 模板,其中必须包含对决策原因的简明解释。如果由于现有授权而拒绝 ECM,MCP 应清楚地传达拒绝的原因,并提供联系 MCP 的方法以请求更改其 ECM 提供商(如果需要)。​​ 

DHCS 能否澄清谁构成自我推荐?例如,邻居或老师是否会被视为 CLR 注意要求的自我推荐?DHCS 对于记录此类转诊有何期望?​​ 

会员、其邻居、家庭成员、朋友或监护人/看护人的推荐被视为自我推荐。如果是自我推荐 ECM/社区支持授权,MCP 仍必须向会员提供授权决定的通知。对引用实体没有其他通知要求。MCP 必须跟踪、支持和监控对 ECM 和社区支持的所有推荐,包括自我推荐。教师以其专业身份为会员服务,不属于“自我或监护人推荐”,因此需要遵守推荐实体的通知要求。​​ 

DHCS 要求 MCP 使用电子方式(不包括传真)与推荐实体共享通知,除非双方同意使用其他非电子方式。这一要求引发了人们对通过电子邮件共享信息的法律担忧。​​ 

关于安全电子方法的指导在​​  MCP 合同附件 G,业务伙伴附录,§ 9.2。本节包括与 PHI 保障和安全相关的义务,包括遵守 45 CFR 第 164 部分的 C 分部。DHCS 建议 MCP 查看卫生与公众服务部 (HHS) 常见问题解答:​​  安全规则是否允许通过电子邮件或互联网发送电子 PHI(e-PHI)?如果是的话,必须采取什么保护措施?​​ 

HHS 在答复中表示,“安全规则并未明确禁止使用电子邮件发送电子 PHI。但是,访问控制(45 CFR § 164.312(a))、完整性(45 CFR § 164.312(c)(1))和传输安全(45 CFR § 164.312(e)(1))标准要求涵盖实体实施政策和程序来限制对 e-PHI 的访问、保护其完整性并防止未经授权的访问。传输安全标准(§ 164.312(e))还包括完整性控制和加密的可寻址规范。这意味着涵盖的实体必须评估其对开放网络的使用情况,确定在传输电子 PHI 时保护其可用且适当的方法,选择解决方案并记录该决定。只要受到充分保护,安全规则允许电子 PHI 通过电子开放网络发送。”​​ 

DHCS 建议 MCP 咨询其律师,根据 HHS 的指导确定安全的电子传输方式。​​  

DHCS 能否澄清 APL 21-011 中详细列出的针对提供商的通知要求(即 MCP 在做出决定后的 24 小时内通知提供商)是否也适用于 DHCS 在 CLR 实施指南中定义的推荐实体?​​ 

所有对 ECM 和社区支持的推荐都是授权请求,并触发 APL 21-011 注意要求。根据 APL 21-011,MCP 必须使用​​  适当的行动通知 (NOA) 模板,其中必须包括对决定原因的简明解释。这些要求适用于引用实体做出的所有 CLR。​​ 

要求 DHCS 提供书面澄清,确认 MCP 可以在未经患者授权的情况下与未涵盖实体的转介实体共享 PHI,包括严重精神疾病 (SMI)/物质使用障碍 (SUD) 和儿童福利状况。​​ 

DHCS 建议指明 ECM 或社区支持是否获得授权,以及适用的拒绝原因。​​  无需交换 SMI/SUD 或儿童福利信息即可共享整体服务(ECM/社区支持)和授权决策。自 2022 年服务开始以来,MCP 还可以按照其现有程序满足 APL-21-011 规定的 ECM 和社区支持 DHCS 通知要求。DHCS 建议 MCP 咨询其法律顾问,以确定是否需要与 SMI/SUD 或儿童福利相关的其他详细信息,并且是否可以根据现有的联邦和州指导通过通知分享。​​ 

请求 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 要求 MCP 使用电子方式传达 CLR 状态,明确排除传真和门户。这令人担忧,因为 UM 事先授权通知的行业标准依赖于经过验证的、签约的传真线路。虽然我们赞赏 DHCS 为摆脱传真通信所做的努力,但在没有必要技术的情况下在 7 月 1 日之前实施这一要求将对 MCP 实现合规性带来重大挑战。​​ 

对于非合同转诊提供商,我们寻求澄清什么才算安全的电子方法(不包括传真和门户)。DHCS 如何定义“电子方法”,它能否提供与缺乏经过验证的传真号码或电子邮件的实体进行安全电子 PHI 共享的示例?​​ 

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 维持这一要求的原因如下:​​ 

    • 社区支持提供者的一些推荐可能针对其他社区支持,或者可能分配给其他社区支持提供者。在这两种情况下,转诊环路闭合通知对于提供商的意识以及与会员的持续护理协调都很重要。​​ 
如果转诊是为了社区支持,并且转诊实体也是服务提供商,则维持转诊环路闭环的通知要求为 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 的政策是,MCP 不能要求社区合作伙伴或 ECM 提供商提交超出 ECM 推荐标准的其他文件来做出 ECM 授权决定。例如,转介实体无需提供补充资格清单、外展授权表、ICD-10 代码、无家可归证明、治疗授权请求 (TAR) 表或超出 ECM 转介标准中指定的其他额外信息来确认资格并授权 ECM(有关详细信息,请参阅 ECM 政策指南中的转介和授权部分(第 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日起实施新的会员信息共享指南。​​ 




上次修改日期: 5/29/2025 2:45 PM​​