پیاده‌سازی عمومی​​ 

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 در تاریخ 1 جولای، 2025 ، به MCPها مهلت می‌دهد تا سیستم‌ها و فرآیندهای CLR را راه‌اندازی کنند. در حالی که DHCS انتظار دارد MCPها CLR را تا ماه جولای 1 ، 2025 پیاده‌سازی کنند، DHCS اذعان می‌کند که ممکن است زمان بیشتری برای اصلاح الزامات عملیاتی و پیاده‌سازی CLR مانند روش‌های اطلاع‌رسانی و ردیابی، به‌روزرسانی‌های سیستم و گردش‌های کاری پس از تاریخ راه‌اندازی مورد نیاز باشد. بنابراین، DHCS از ابتدای جولای 1 ، 2026 نظارت فعال بر انطباق با مقررات را آغاز خواهد کرد.​​ 

پیگیری ارجاعات اعضا​​ 

MCPها گاهی اوقات اطلاعات مکرر و ارزشمندی در مورد ارجاعات و وضعیت همکاری مستقیماً از ارائه دهندگان خدمات مدیریت مراقبت پیشرفته (ECM) خود دریافت می‌کنند. آیا می‌توان منابع داده جایگزین برای تکمیل الزامات ردیابی CLR را به داده‌های تکمیلی مربوط به ادعاها و برخوردها اضافه کرد؟​​ 

MCPها می‌توانند از منابع داده جایگزین برای تکمیل منابع ردیابی CLR که در راهنما ذکر شده است، استفاده کنند؛ با این حال، MCPها نمی‌توانند از ارائه‌دهندگان ECM/Community Supports بخواهند که داده‌ها را برای ردیابی از طریق روشی غیر از فایل ارسال بازگشتی (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 چگونه در مراکز ترک اعتیاد اعمال می‌شود؟  آیا برای خدمات ۲۴ ساعته، اطلاع رسانی به اعضا الزامی است؟​​ 

الزامات CLR برای مراکز ترک اعتیاد اعمال نخواهد شد زیرا خدمات اغلب به صورت بلادرنگ ارائه می‌شوند، مدت اقامت کمتر از ۲۴ ساعت است و خدمات معمولاً به صورت عطف به ماسبق مجاز می‌شوند تا دسترسی به موقع به این پشتیبانی اجتماعی تسهیل شود.​​ 

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 فراهم کند و الزامات وضعیت CLR جدید را از ECM RTF حذف کند و در عوض از وضعیت‌های ECM موجود برای ردیابی CLR استفاده کند؟ ECM RTF در حال حاضر CLR را از طریق وضعیت‌های تعیین‌شده ردیابی می‌کند، اما وضعیت‌های جدید CLR با آن هم‌تراز نیستند و پیچیدگی غیرضروری ایجاد می‌کنند. حذف آنها باعث کاهش سردرگمی و بار اداری می‌شود و در عین حال هماهنگی فرآیندها را حفظ می‌کند.​​ 

DHCS قادر به پذیرش درخواست حذف متغیر وضعیت ارجاع نیست، زیرا این یک مقدار کلیدی برای استانداردسازی ردیابی CLR است. با این حال، DHCS در حال کار بر روی راه‌حل‌های ممکن است، ضمن اینکه بازخورد MCP را در مورد پیامدهای حذف مزارع موجود در نظر می‌گیرد.​​   

آیا DHCS می‌تواند در مورد تفاوت بین وضعیت ارجاع ۱ - پذیرفته‌شده و ۳ - در حال بررسی، توضیحی ارائه دهد، زیرا در گردش کار فعلی 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ها تحت ترتیبات مجوز احتمالی، لطفاً به پیوست B بخش 1.A.3 از راهنمای پیاده‌سازی CLR مراجعه کنید.​​ 

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 ها با ارجاعات تکراری از یک عضو و برای یک خدمت برخورد خواهند کرد؟ لطفا در این مورد راهنمایی بیشتری بفرمایید.​​ 

لطفا سناریوهای مثال زیر را ببینید:​​ 

• سناریوی ۱: ارجاع برای خدماتی که عضو از قبل مجوز آن را دارد. در صورتی که یک 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) به نهاد ارجاع‌دهنده اطلاع دهند.​​ 

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/Community Supports را بدهد، MCPها همچنان تصمیم مربوط به مجوز را به عضو اطلاع خواهند داد. هیچ الزام اطلاع رسانی دیگری اعمال نمی‌شود.​​ 

اگر عضوی از دریافت اخطاریه‌های کتبی از MCP انصراف داده باشد، چه انتظاراتی از او می‌رود که آن را اعلام کند؟​​ 

در صورتی که اعضا از دریافت مکاتبات کتبی انصراف داده باشند، MCPها باید سیاست‌های داخلی خود را در مورد روش‌های جایگزین تماس با اعضا برای ارائه اطلاعات کلیدی یا NOAها دنبال کنند. برای مثال، اگر عضو از برقراری ارتباط کتبی انصراف داده باشد، MCP می‌تواند به جای آن از طریق تلفن یا روش‌های الکترونیکی مجاز و امن با او تماس بگیرد.​​ 

آیا الزامات اطلاع‌رسانی به اعضا در مواردی که مجوز ECM به دلیل ثبت‌نام قبلی عضو در ECM رد می‌شود، اعمال می‌شود؟​​ 

بله، تمام ارجاعات به ECM و Community Supports یک درخواست مجوز محسوب می‌شوند و الزامات اطلاع‌رسانی 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 ارجاع داده شده‌اند، بی‌اطلاع هستند. تماس با ارائه‌دهنده‌ی ECM قبل از ارسال نامه‌ی NOA، رویکردی عضومحورتر خواهد بود و تضمین می‌کند که آن‌ها ارجاع و آنچه را که باید انتظار داشته باشند، درک می‌کنند. آیا DHCS می‌تواند راه‌هایی را برای ساده‌سازی این فرآیند بررسی کند تا سردرگمی کاهش یابد و تجربه اعضا بهبود یابد؟​​ 

راهنمای پیاده‌سازی CLR به‌روزرسانی شده است تا تنها یک اطلاعیه مورد نیاز برای اعضا را در زمان مجوز، مطابق با الزامات APL 21-011، منعکس کند. 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?​​ 

راهنمایی در مورد اینکه چه چیزی به عنوان یک روش الکترونیکی امن واجد شرایط است، در ضمیمه G قرارداد MCP، ضمیمه همکار تجاری، بند 9.2 ارائه شده است. این بخش شامل تعهدات مربوط به حفاظت و امنیت PHI، از جمله رعایت بند فرعی C از 45 CFR Part 164 است. DHCS به MCPها توصیه می‌کند که با مشاور حقوقی خود مشورت کنند تا روش‌های امن اشتراک‌گذاری اطلاعات الکترونیکی را برای برآورده کردن الزامات اطلاع‌رسانی CLR تعیین کنند. ممکن است MCPها بخواهند ایمیل‌های امن یا روش‌های مشابه را بررسی کنند و الگوهای اعلانی را طراحی کنند که حداقل اطلاعات لازم را برای برآورده کردن الزامات APL 21-011 و راهنمای پیاده‌سازی CLR به اشتراک بگذارند.​​ 

از DHCS در مورد انتظارات مربوط به اطلاع‌رسانی/ارتباط با اعضا در دوران حبس، توضیحاتی درخواست شده است.​​ 

DHCS توصیه می‌کند که برای اعضای زندانی، با هماهنگی هماهنگ‌کننده خدمات پیش از آزادی در هر موسسه اصلاح و تربیت، برنامه‌ای برای اطلاع‌رسانی به اعضا طراحی شود تا آدرس و روش مناسب برای به اشتراک گذاشتن اطلاع‌رسانی به صورت محرمانه که توسط عضو دریافت می‌شود، تعیین شود.​​ 

درخواست‌های خدمات (ارجاعات) به طور منظم توسط ارائه‌دهندگان خدمات پشتیبانی اجتماعی ارسال می‌شوند تا اعضا را برای دریافت خدمات پشتیبانی اجتماعی به سازمان مربوطه خود ارجاع دهند. ارائه دهندگان خدمات پشتیبانی اجتماعی که خدمات را ارائه می‌دهند، نهاد ارجاع دهنده هستند. همان آژانسی که ارجاع را آغاز کرده است، به‌روزرسانی‌های CLR را از طریق RTF ارائه خواهد داد. در این موارد، آیا اعلان‌های 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 و الگوی فرم به عنوان ارجاع ECM به MCPها از طرف اعضا عمل می‌کند که درخواست مجوز برای 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 لحاظ نمی‌کند. ما درک می‌کنیم که برخی از تیم‌های ECM MCP ممکن است نیاز به همکاری با تیم‌های UM خود داشته باشند تا الزامات جدید را شرح داده و فرآیندهای UM را برای تطبیق با آنها تنظیم کنند.​​ 

چند منبع اضافی و مرتبط با مجوز و کدگذاری ECM:​​ 

• مجوزهای ECM ملزم به داشتن یک دوره مجوز اولیه ۱۲ ماهه هستند:​​ 
• (به‌روزرسانی‌شده در ژوئیه ۲۰۲۳) بازه‌های زمانی استاندارد مجوز ECM: برای همه اعضایی که توسط MCP خود مجاز به دریافت ECM هستند، دوره مجوز اولیه ۱۲ ماه و دوره مجوز مجدد ۶ ماه خواهد بود. MCPها نمی‌توانند الزامات اضافی برای مجوز خدمات ECM فراتر از معیارهای واجد شرایط بودن جمعیت کانونی مشخص شده توسط DHCS اعمال کنند. برای مثال، MCPها نمی‌توانند تا زمان تکمیل طرح مراقبتی، مجوز را متوقف کنند. (صفحه ۱۰۸، ECM PG)​​ 
• راهنمای ECM HCPCS - کدهای استاندارد برای ادعاها و برخوردها​​ 

گزارش‌دهی JSON​​ 

آیا DHCS می‌تواند درخواست هرگونه گزارش JSON در مورد عناصر CLR را حداقل تا ژانویه 1 ، 2026 دوباره بررسی کند؟ عاقلانه است که گزارش‌دهی CLR JSON حداقل به ژانویه 1 ، 2026 منتقل شود تا امکان پیاده‌سازی کامل فرآیند و تبادل داده‌ها به طور مناسب فراهم شود.​​ 

قالب‌های JSON فاز 4 CLR شامل عناصر داده CLR برای داده‌های نظارتی، در فوریه 2025 به همراه یک برنامه آزمایش مرتبط، برای MCPها منتشر شدند و راهنمای نهایی JSON فاز 4 در مارس 28 ، 2025 منتشر شد. تمام راهنمایی‌ها برای به‌روزرسانی ECM و ابزارهای اشتراک‌گذاری اطلاعات پشتیبانی‌شده توسط انجمن (MIF، RTF و ASF) در دسامبر ۲۰۲۴ منتشر شد و به‌روزرسانی‌های خاصی برای پشتیبانی از CLR که در اسناد ذکر شده است، ارائه گردید.​​  

DHCS قویاً MCPها را تشویق می‌کند که به‌روزرسانی راهنمای اشتراک‌گذاری اطلاعات اعضا را مطابق با الزامات منتشر شده در دسامبر 2024 انجام دهند و برای اجرای راهنمای جدید اشتراک‌گذاری اطلاعات اعضا در ماه ژوئیه 1 ، 2025 ، به ECM و ارائه‌دهندگان پشتیبانی اجتماعی کمک و پشتیبانی فنی ارائه دهند.​​