クローズド ループ紹介 (CLR) についてよく寄せられる質問​​ 

一般的な実装​​ 

Department of Health Care Services(DHCS)は、DHCSがMedi-Cal Managed Care Plans(MCPs)のCLRの実施について、2025年7月1日の稼働日から1年後にコンプライアンスレビューを開始するとはどういう意味ですか?DHCSは、MCPが2025年7月1日までにCLRに完全に準拠することを期待していますか?​​ 

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) 以外の手段で追跡用のデータを提出するよう要求することはできません。​​ 

DHCSは、ECMまたはコミュニティサポートプロバイダーがRTFに含まれるデータを介してサービスが提供または開始されたことを確認した場合、MCPが「サービス受領」としてループを閉じることができることを確認しますか?請求可能なサービスという用語は、MCP が 6 か月かかる可能性のある請求を受け取ったことを意味します。​​ 

MCP は、プロバイダが RTF の Reason for Referral Loop Closure データ要素を介してサービスがレンダリングされたことを確認したら、CLR のループを "Services Received" として閉じることができます。​​ 

CLR の追跡と通知の要件は、しらふのセンターにどのように適用されますか?24時間サービスの場合、会員への通知は必要ですか?​​ 

CLR要件は、サービスがリアルタイムで提供されることが多く、滞在時間が24時間未満であり、サービスは通常、このコミュニティサポートへのタイムリーなアクセスを容易にするために遡及的に承認されるため、Sobering Centersには適用されません。​​ 

DHCSは、ECMおよびコミュニティサポートプロバイダーによる「拒否」紹介ステータス値の使用目的を明確にできますか?​​ 

標準の CLR 紹介状態の値は、時間の経過と共にさまざまなサービスに適用される場合があります。現在、DHCSは、ECMおよびコミュニティサポートサービスプロバイダーが、プロバイダーの能力が不足している、メンバーがサービスエリアに住んでいない、またはその他の理由で「拒否」紹介ステータスに入る可能性があると予想しています。MCP は、ネットワーク プロバイダーと協力し、ECM およびコミュニティ サポートのポリシーに従って紹介を拒否する理由と、紹介ステータス値にどのように記載するかを判断するための明確な文書化された手順を提供する必要があります。DHCSは、MCPがネットワークプロバイダーが紹介を拒否できるようにするための新しいポリシーを採用すべきだと言っているわけではありません。​​ 

PHM ポリシー ガイドの DHCS 補遺: クローズド ループ紹介実装ガイダンスの表 4: 紹介処理には、"サービス プロバイダー名" と "サービス プロバイダーの電話番号" がリストされています。DHCSは、これがメンバーの割り当てられたリードケアマネージャーであり、電話番号であるかどうかを明確にしていただけますか?​​ 

「サービスプロバイダー名」および「サービスプロバイダー電話番号」は、MCPまたは紹介エンティティからECMまたはコミュニティサポートの紹介リクエストを受け取ったエンティティ(つまり、サービスプロバイダー)の名前と電話番号です。たとえば、「CalAIM Data Guidance: Member-Level Information Sharing Between MCPs and ECM Providers Guidance」の 23-24 ページでは、情報は「ECM Provider Name」および「ECM Provider Phone Number」と一致しています。このフィールドの目的は、MCP が、CLR 要件が適用されるさまざまなプロバイダー/サービスについて、メンバーの紹介とサービス提供をサポートするために活用できる連絡先情報を記録したことを確認することです。​​ 

DHCSは「サービスプロバイダー組織名」と「サービスプロバイダー名」の違いを説明できますか?​​ 

「サービス プロバイダー組織名」は、ECM プロバイダー (つまり、組織名) です。「サービスプロバイダー名」とは、ECMサービスを提供するために割り当てられたECMリードケアマネージャー(メンバーに割り当てられた組織の人)です。​​ 

紹介ループの終了理由を参照エンティティと共有するための要件では、メンバーの許可なしに対象外のエンティティと保護された健康情報(PHI)を共有する必要があります。MCPは、この要件がHIPAAに準拠していないと考えており、DHCSにこの要件を削除するよう要求しています。​​ 

1996年の医療保険の相互運用性と説明責任に関する法律(HIPAA)は、MCPを含む対象事業体が、治療、支払い、または医療業務(ケアコーディネーションやケース管理を含む特定の管理、法律、財務、および品質改善活動)を含む特定の目的で、患者の許可なしに「保護医療情報」(PHI)を使用または開示することを認めています。このような開示は、治療、支払い、および医療業務を目的としている限り、他の対象事業体(医療提供者など)と対象外事業体(住宅提供者、コミュニティベースの組織(CBO)など)の両方に行うことができます。​​  

「Referral Loop Closure Reason」と「Referral Loop Closure Date」は、どちらもHIPAAに基づくPHIを構成します。MCPは、対象となる事業体として、その情報をindivi​​ 治療とケアの調整を目的とした二重承認。45 CFR 164.506(c)(1)は、対象事業体が自身の治療、支払い、および医療業務の目的でPHIを使用および開示できると規定しています。​​ 

DHCS は、新しい CLR ステータス フィールドと RTF の既存のステータス フィールドとの間の対話のための横断歩道を提供し、ECM RTF から新しい CLR ステータス要件を削除して、代わりに既存の ECM ステータスを CLR 追跡に使用できますか?ECM RTF は既に確立されたステータスを通じて CLR を追跡していますが、新しい CLR ステータスは整合せず、不必要に複雑になります。それらを削除すると、プロセスの整合性を維持しながら、混乱と管理上の負担が軽減されます。​​ 

DHCS は、CLR 追跡を標準化するための重要な値である Referral Status 変数を削除する要求に対応できません。ただし、DHCSは、既存のフィールドを削除することの影響に関するMCPフィードバックを考慮しながら、可能な解決策に取り組んでいます。​​   

DHCSは、現在のECMワークフローではそれらを区別する方法が不明確であるため、紹介ステータス1-Acceptedと3-Pendingの違いについて明確にすることができますか。​​ 

「保留中」とは、MIF上のECMまたはコミュニティサポートプロバイダーへの紹介が、プロバイダーがまだ紹介を閲覧しておらず、メンバーにサービスを提供する能力があることを確認しておらず、アウトリーチを開始する予定である場合のデフォルトの照会ステータスです。「受理済み」は、プロバイダーが紹介を審査し、メンバーに連絡を取るつもりであるがまだ行っていない場合に示されます。Referral Status 変数の値の詳細については、CLR 実装ガイダンスの表 11 を参照してください。​​ 

MCPは、DHCSがプロバイダーが紹介を拒否するのを許しており、それがメンバーの選択的な受け入れや潜在的な差別につながる可能性があることを懸念しています。例えば、トランスジェンダーの人々や特定の言語を話す人々へのサービス提供を拒否することなどです。DHCSは、このCLRオプションを再考したり、メンバーの差別に対する保護措置を実施したりできますか?​​ 

標準の CLR 紹介状態の値は、時間の経過と共にさまざまなサービスに適用される場合があります。現在、DHCSは、ECMおよびコミュニティサポートサービスプロバイダーが、プロバイダーの能力が不足している、メンバーがサービスエリアに住んでいない、またはその他の理由で「拒否」紹介ステータスに入る可能性があると予想しています。MCP は、ネットワーク プロバイダーと協力し、ECM およびコミュニティ サポートのポリシーに従って紹介を拒否する理由と、紹介ステータス値にどのように記載するかを判断するための明確な文書化された手順を提供する必要があります。DHCSは、MCPがネットワークプロバイダーが紹介を拒否できるようにするための新しいポリシーを採用すべきだと言っているわけではありません。​​ 

DHCSは、「長期間にわたってオープンしているCLR」を定義するのがMCPの裁量によることを確認できますか?​​ 

確認。DHCSは、これがメンバーの既知のニーズとサービスの種類によって異なる可能性があると予想しています。CLR 実装ガイダンスに従って、すべての紹介ステータスは少なくとも毎月更新する必要があります。​​ 

DHCSは、「MCPは1営業日以内に問い合わせに対応することが期待されている」という要件で「問い合わせに対応する」とはどういう意味か明確にしていただけますか?​​ 

MCP は、少なくとも問い合わせの受領を確認し、1 営業日以内に CLR のステータスを提供する必要があります。たとえば、MCP は、紹介が承認され、[日付] にサービス プロバイダーに渡されたことを紹介エンティティまたはメンバーに通知することができます (それが MCP が紹介のステータスに関する最新の更新である場合)。この要件の目的は、紹介パートナーが紹介者のステータスをより迅速に理解し、メンバーを最善のサポートできるようにすることです。DHCSは、現時点ではこの要件の例外を発行する予定はありません。​​ 

DHCSは、会員からの問い合わせに1営業日以内に回答するという要件の遵守状況をどのように監視しますか?​​ 

DHCSは、2025年7月1日の実施日から1年後にMCPのCLRのコンプライアンスレビューの実施を開始します。DHCSは、この要件が満たされていることを確認するために、アドホックドキュメンテーションの要求、監査の完了、またはその他の措置の導入を検討する場合があり、事前にMCPに通知します。​​ 

DHCSからの要求事項は、資格のためにサービスを拒否されたメンバーに関連するフォローアップの期待についてです。DHCSは、この要件を満たす手順の明確な例を提供できますか?​​ 

この要件の目的は、ECMまたはコミュニティサポートへの最初の紹介につながったニーズが、メンバーにとって引き続き対処される可能性を高めることです。適格性のためにECMの承認が拒否された場合、MCPの次のステップは、メンバーのニーズに対するCCMの適用を検討し、代替としてCCMを提供すること、またはメンバーのD-SNPにケアマネジメントの必要性を通知し、メンバーがケアマネジメントサポートのためにD-SNPからアウトリーチを受けたことを確認することである可能性があります。​​ 

ほとんどのECM紹介はプランをバイパスして、メンバーを登録すると推定されるECMプロバイダーに直接送信されます。プランでは、紹介の出所を可視化せずに CLR の最小データ セットをどのように追跡できますか?追跡が必要な場合、ECMプロバイダーネットワークに大幅なレポート作成と管理の負担がかかります。​​ 

付録Bセクション1.A.3を参照してください。CLR Implementation Guidance の ECM プロバイダーから MCP への紹介/承認要求のコーディングに関するガイダンス (推定承認の取り決めに基づく)。​​ 

DHCSは、MCPが報告するステータスのレベルをどの程度想定していますか?​​ 

CLR 要件 (ECM およびコミュニティ サポート) に基づいて MCP が追跡する必要がある完全な仕様とデータ要素については、追跡に関する CLR 実装ガイダンスのセクションを参照してください。付録Bでは、「紹介ステータス」などの主要なトラッキング変数の値や、毎月のRTFを介してECMおよびコミュニティサポートプロバイダーからデータを収集する方法について詳しく説明します。2 月にリリースされた JSON フェーズ 4 テンプレートには、CLR 監視申請の詳細なデータ要素が含まれています。​​ 

紹介が長期間保留中の場合、DHCSはどの程度の介入を期待していますか?それは、各機関との覚書(MOU)に記す必要がありますか?​​ 

CLR 実装ガイダンスのセクション II.B.2「保留中および再紹介のサポート」では、MCP が保留中の紹介のアウトリーチと、このような場合にメンバーおよび紹介エンティティにフォローアップするための推奨事項について、ECM およびコミュニティ サポート プロバイダーをサポートするために実行できるアクションの例の一覧を参照してください。​​ 

各機関がMCPに異なる介入を要求した場合はどうなるでしょうか(たとえば、WICは保留中の紹介に対して5営業日以内に通知するように指示し、リージョナルセンターは30営業日以内に通知するように指示するなど)。​​ 

現時点では、CLR 要件は、ECM およびコミュニティ サポートの MCP への紹介にのみ適用されます。CLR の Noting 要件は、参照エンティティの Nolicing に対する期待を概説しています (例:CBO、プロバイダー、プライマリケア医(PCP))が、APL 21-011で要求されるタイムラインおよび概説された時間枠内の紹介の終了理由に従った紹介の承認決定について。詳細な MCP CLR 通知要件については、CLR 実装ガイダンスのセクション II.B.I を参照してください。​​ 

MCPはECM/コミュニティサポートにDHCS紹介フォームを使用する必要があるため、MCPは電子通知の目的でこのフォームを変更して「メールアドレス」を含めることはできますか?​​ 

ECM紹介基準では、ECM紹介基準の表2に「紹介する個々のメールアドレス」が必須要素としてすでに含まれています。この情報を収集するために更新は必要ありません。​​ 

MCPは、同じメンバーから同じサービスに対する重複した紹介にどのようにアプローチしますか?これについてさらにガイダンスを提供してください。​​ 

以下のシナリオ例をご覧ください。​​ 

• シナリオ 1: メンバーがすでに承認されているサービスの紹介。MCPが紹介を受けた場合(例:ECM)、メンバーがすでにECMの公開承認を得ている場合、MCPは、紹介受領に関する主要な紹介情報(日付、紹介者、サービス)と適切な承認決定(例:拒否)を記録し、拒否の通知(NOA)で紹介者に必要なコンテキストを提供する必要があります(例:以下)。 メンバーは、すでにアクティブでオープンな ECM 認証を持っているため、拒否されます)。MCP は、紹介エンティティ/メンバーが現在のオープン認証のプロバイダーの変更をリクエストする場合に MCP に連絡するための連絡先情報も提供する必要があります。​​ 
• シナリオ 2: サービスの紹介で、メンバーが別の未解決の紹介を進行中である。MCP は、同じサービスの 2 つの紹介が同時にメンバーに対して開いている場合 (例:紹介日、紹介エンティティ、サービス、承認ステータス)。MCP は、2 番目の参照エンティティの CLR 通知要件を満たすことが引き続き期待されます。DHCSは、MCPが紹介者とのコミュニケーションを通じて紹介をサポートし、重複した紹介がサービスの適切なプロバイダーの割り当てに不確実性を生じさせる場合にメンバーとの必要な調整をサポートすることを期待しているため、MCPに両方の紹介に関する情報を記録することを要求しています。たとえば、2つの異なるECMプロバイダーがメンバーの紹介を提出した場合、MCPはメンバーと紹介ECMプロバイダー全体で調整し、メンバーがECMプロバイダーを優先して割り当てる必要があります。
  
  MCPは、既存のポリシーと手続きに従い、紹介事業体から紹介され、承認が拒否されたメンバーのシェア/ボリュームを見直す必要があります。同じメンバーおよび同じサービスに対して重複する紹介が多数ある場合、MCPは、紹介者と話し合いを促進し、技術支援を提供して、適格性を満たし、承認された紹介を増やす必要があります。​​ 

CLR の認識​​ 

MCPが内部データを使用して個人をECMまたはコミュニティサポートの対象として特定した場合(つまり、「紹介タイプ」は「2.MCPによって特定された」)、通知要件は適用されますか?​​ 

このシナリオでは、MCPが紹介エンティティであり、注意要件は適用されません。ただし、ベストプラクティスとして、DHCSはMCPがメンバーに資格があり、サービスに紹介されたことをメンバーに通知して、メンバーのエンゲージメントの可能性を高めることを奨励しています。​​ 

多くの場合、MCP がプロバイダーから RTF データを取り込み、クリーニングするには時間がかかります。紹介ループの閉鎖のための2営業日の「気づき時計」はいつ始まりますか?​​ 

DHCSは、MCPがプロバイダーからRTFを受け取った後、データの取り込みと処理に追加の時間が必要になる場合があることを理解しています。MCPは、データ処理の完了から2営業日以内(必要に応じてRTFの受領から合計7日)以内にRTFを処理し、紹介エンティティに通知するために最大5営業日が許可されています。​​ 

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は電子的方法(ファックスを除く)を使用します。この要件は、電子メールで情報を共有できることについて法的な懸念を引き起こします。​​ 

安全な電子的方法として適格なものに関するガイダンスは、​​  MCP契約の別紙G、ビジネスアソシエイト補遺、§9.2。このセクションには、45 CFR Part 164 のサブパート C への準拠を含む、PHI のセーフガードとセキュリティに関連する義務が含まれています。DHCSは、MCPがHealth and Human Services(HHS)のFAQを確認することを推奨しています。​​  セキュリティルールでは、電子PHI(e-PHI)を電子メールまたはインターネット経由で送信することが許可されていますか?その場合、どのような保護を適用する必要がありますか?​​ 

HHSは回答の中で、「セキュリティルールは、e-PHIを送信するための電子メールの使用を明示的に禁止していません。ただし、アクセス制御(45 CFR § 164.312(a))、完全性(45 CFR § 164.312(c)(1))、および伝送セキュリティ(45 CFR § 164.312(e)(1))の基準では、対象事業体に対して、e-PHIへのアクセスを制限し、e-PHIの完全性を保護し、不正アクセスから保護するためのポリシーと手順を実装することが義務付けられています。伝送セキュリティの規格(§164.312(e))には、完全性制御と暗号化に関するアドレス指定可能な仕様も含まれています。つまり、対象となる事業体は、オープンネットワークの使用を評価し、送信時にe-PHIを保護するための利用可能かつ適切な手段を特定し、解決策を選択し、決定を文書化する必要があります。セキュリティルールでは、e-PHIが適切に保護されている限り、電子オープンネットワークを介してe-PHIを送信することが認められています。」​​ 

DHCSは、MCPがHHSからのこのガイダンスに基づいて安全な電子送信手段を決定するために、MCPの弁護士に相談することをお勧めします。​​  

DHCSは、APL 21-011に詳述されているプロバイダー向けの通知要件(つまり、MCPが決定から24時間以内にプロバイダーに通知すること)が、CLR実装ガイダンスでDHCSによって定義されている紹介エンティティにも適用されるかどうかを明確にしていただけますか?​​ 

ECMおよびコミュニティサポートへのすべての紹介は、認証リクエストであり、APL 21-011通知要件をトリガーします。APL 21-011 では、MCP は​​  適切な行動通知(NOA)テンプレートには、決定の理由の簡潔な説明を含める必要があります。これらの要件は、紹介エンティティによって作成されたすべての CLR に適用されます。​​ 

MCPが、重篤な精神疾患(SMI)/物質使用障害(SUD)および児童福祉状況を含むPHIを、患者の許可なしに、対象事業体ではない紹介事業体と共有できることを確認するために、DHCSから書面による説明が要求されます。​​ 

DHCSでは、ECMまたはコミュニティサポートが承認されているかどうか、および該当する場合は拒否に関連する理由を示すことをお勧めします。​​  SMI/SUDや児童福祉情報の交換は、全体的なサービス(ECM/コミュニティサポート)の共有や認可決定のために必要ありません。MCPは、2022年のサービス開始以来、ECMおよびコミュニティサポートのAPL-21-011に基づくDHCS通知要件を満たすための既存の手順に従うこともできます。DHCSは、MCPが弁護士に相談して、SMI/SUDまたは児童福祉に関連する追加の詳細が必要であり、既存の連邦および州のガイダンスの下で通知を通じて共有できるかどうかを判断することをお勧めします。​​ 

メンバーへの新しい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 では、MCP に対して、FAX とポータルを明示的に除外して、CLR ステータスの通信に電子的な方法を使用することが義務付けられています。UM 事前承認通知の業界標準は、検証済みの契約済み FAX 回線に依存しているため、これは懸念事項です。DHCSがファックス通信から脱却する努力は評価していますが、必要な技術を導入せずにこの要件を7月1日までに実施することは、MCPがコンプライアンスを達成する上で大きな課題となります。​​ 

契約していない紹介プロバイダーについては、ファックスとポータルを除き、安全な電子的方法として適格なものについて明確にするよう求めています。DHCSは「電子的方法」をどのように定義し、検証済みのファックス番号や電子メールを持たないエンティティとの安全な電子PHI共有の例を提供できますか?​​ 

安全な電子的方法として適格なものに関するガイダンスは、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は、次の理由により、この要件を維持しています。​​ 

• コミュニティサポートプロバイダーからの紹介には、他のコミュニティサポートのためのものもあれば、別のコミュニティサポートプロバイダーに割り当てられるものもあります。どちらの場合も、紹介ループの終了通知は、プロバイダーの認識とメンバーとの継続的なケアの調整にとって重要です。​​ 

紹介がコミュニティサポートのために配置され、紹介エンティティがサービスプロバイダーでもある場合、紹介ループの終了の通知要件を維持することは、MCPとプロバイダーの両方にとって重要なデータ品質チェックを提供します。さらに、CLR の監視とサポートに関する CLR 要件では、エンゲージメント アプローチとベスト プラクティスのギャップを特定するために、サービス プロバイダーによる紹介ループの終了理由をレビューする MCP の役割が強調されています。最後に、紹介ループ終了通知のCLR要件はAPL 21-011の対象ではなく、MCPが毎月大量の紹介ループ終了を持つ紹介エンティティにバッチの電子通知を柔軟に送信することができます。​​