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?
DHCS は、CLR ポリシーが 2025年 7 月 1日に発効した後、CLR システムとプロセスを導入するための猶予期間を MCP に提供しています。DHCS は、MCP が 2025年 7 月 1日までに CLR を実装することを期待していますが、運用開始日後の手法の把握と追跡、システムの更新、ワークフローなど、CLR の運用および実装要件を改善するために追加の時間が必要になる可能性があることを認識しています。したがって、DHCSは7月 1日からコンプライアンスの積極的な監視を開始します 2026。
メンバー紹介の追跡
MCPは、紹介やエンゲージメントステータスに関する貴重な情報を、ECM(Enhanced Care Management)プロバイダーから直接頻繁に受け取ることがあります。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時間未満であり、サービスは通常、このコミュニティサポートへのタイムリーなアクセスを容易にするために遡及的に承認されるため、Sobering Centersには適用されません。
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 追跡を標準化するための重要な値である Referral Status 変数を削除する要求に対応できません。ただし、DHCSは、既存のフィールドを削除することの影響に関するMCPフィードバックを考慮しながら、可能な解決策に取り組んでいます。
DHCSは、現在のECMワークフローではそれらを区別する方法が不明確であるため、紹介ステータス1-Acceptedと3-Pendingの違いについて明確にすることができますか。
“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は、会員からの問い合わせに1営業日以内に回答するという要件の遵守状況をどのように監視しますか?
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 Implementation Guidance の ECM プロバイダーから MCP への紹介/承認要求のコーディングに関するガイダンス (推定承認の取り決めに基づく)。
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は保留中の紹介に対して5営業日以内に通知するように指示し、リージョナルセンターは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は、データ処理の完了から2営業日以内(必要に応じてRTFの受領から合計7日)以内にRTFを処理し、紹介エンティティに通知するために最大5営業日が許可されています。
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が紹介者と通知を共有するために電子的方法(ファックスを除く)を使用することを義務付けています。ただし、他の非電子的方法が相互に合意されていない限り、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時間以内にプロバイダーに通知すること)が、CLR実装ガイダンスで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.
MCPが、重篤な精神疾患(SMI)/物質使用障害(SUD)および児童福祉状況を含むPHIを、患者の許可なしに、対象事業体ではない紹介事業体と共有できることを確認するために、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.
メンバーへの新しいCLR通知書に、NOA、お客様の権利、州ヒアリング、およびIMRフォームを添付する必要があるかどうかについてDHCSに確認を依頼する。
メンバーへの通知は、APL 21-011に基づく既存の完全な要件を満たす必要があります。CLR Member Noticingの要件は、APL 21-011と区別されません。
DHCSは、新しいCLRメンバー向けのレターをレビューのために提出する計画を要求しますか?その場合、レビューと承認の所要時間はどのくらいですか?
MCPは、APL 21-011に基づく認定サービスに既存の通知テンプレートを使用して、メンバーの通知要件を満たす必要があります。
複数のメンバー通知が逆の効果をもたらし、明確さではなく混乱を引き起こす可能性があるという懸念を提起します。現在、APL 21-011に基づき、メンバーはECMサービスに対して承認または拒否されたときに1通のレターを受け取ります。CLR を使用すると、NOA を含むレターを 3 つ以上受け取る可能性があり、不必要な懸念につながる可能性があります。
さらに、MCPは、メンバーがそもそもECMに紹介されたことに気づいていないことに気づくことがよくあります。NOAレターが送信される前にECMプロバイダーに連絡を取ることは、よりメンバー中心のアプローチであり、紹介と何を期待するかを確実に理解することができます。DHCSは、このプロセスを合理化して混乱を減らし、メンバーのエクスペリエンスを向上させる方法を模索できますか?
CLR実装ガイダンスは、APL 21-011の要件に沿って、承認時にメンバーに義務付けられている通知を1つだけ反映するように更新されました。ECMは、2022年の開始以来、APL 21-011 Member Nonoticeing要件の対象となっています。
引用した例で、メンバーが自分に代わって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に記載されています。このセクションには、45 CFR Part 164 のサブパート C への準拠を含む、PHI のセーフガードとセキュリティに関連する義務が含まれています。DHCSは、MCPが弁護士に相談して、CLR通知要件を満たすための電子情報共有の安全な手段を決定することを推奨しています。MCPは、安全な電子メールまたは同様の方法を検討し、APL 21-011およびCLR実装ガイダンスの要件を満たすために必要最小限の情報を共有するテンプレートを考案したい場合があります。
DHCSからの要求事項は、収監中のメンバーへの通知/コミュニケーションの期待についてです。
DHCSは、各矯正施設の釈放前サービスコーディネーターと連携して、受刑者向けのメンバー通知を設計し、メンバーが受け取る通知を秘密裏に共有するための適切なアドレスと手段を決定することをお勧めします。
サービスリクエスト(紹介)は、コミュニティサポートプロバイダーによって定期的に提出され、コミュニティサポートサービスのためにメンバーをそれぞれの組織に紹介します。サービスを提供する割り当てられたコミュニティサポートプロバイダーは、紹介エンティティです。紹介を開始したのと同じ機関が、RTF を介して CLR の更新を提供します。このような場合、ループの終了時に CLR 通知は必要ですか?その場合、コミュニティサポートプロバイダー/紹介エンティティへの通知は冗長に見え、RTF提出を通じてMCPに紹介ステータスを通知したのと同じエンティティであるため、紹介ループの終了をすでに認識しているコミュニティサポートプロバイダー/紹介エンティティに通知を送信するために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 の終了通知と承認決定書を参照エンティティに送信するのは重複しており、これら 2 つの通信は同時に送信されるため、重複します。DHCSは、MCPがCLRステータス:クローズ、CLRクローズ理由:サービス認証拒否について、参照エンティティに個別のCLR通知を送信する必要があるかどうかを明確にしていただけますか?
MCP がサービス認証を拒否した場合は、紹介エンティティに対する拒否の認証通知で十分です。したがって、承認が拒否されたことによる CLR の終了の場合、個別の CLR の終了通知は必要ありません。
ECM紹介フォーム
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が指定するPopulation of Focusの適格基準を超えて、ECMサービスの認可に追加の要件を課すことはできません。たとえば、MCP は、ケアプランが完了するまで承認を保留することはできません。(108ページ、ECM PG)
- ECM HCPCSガイダンス – クレームとエンカウンターの標準化されたコード
JSONレポート
DHCSは、少なくとも 1年1月までCLR要素に関するJSONレポートを要求することを再考できますか、 2026?CLR JSON レポートを少なくとも 2026年 1 月 1日に移動すると、プロセスの実装とデータ交換が適切に完全に実装できるようになります。
監視データ用の CLR データ要素を含む フェーズ 4 の CLR JSON テンプレートは、関連するテスト スケジュールとともに 2025 年 2 月に MCP にリリースされ、最終的なフェーズ 4 の JSON ガイダンスは 2025年 3 月 28日にリリースされました。ECM およびコミュニティ サポート情報共有ツール (MIF、RTF、ASF) の更新に関するすべてのガイダンスは 2024 年 12 月にリリースされ、CLR をサポートするための具体的な更新がドキュメントに概説されています。
DHCSは、MCPが2024年12月に発表された要件に沿ってメンバー情報共有ガイダンスの更新を進め、新しいメンバー情報共有ガイダンスの 1年7月日、 2025日に向けてECMおよびコミュニティサポートプロバイダーに技術支援とサポートを提供することを強く推奨します。