سوالات متداول ارجاع حلقه بسته (CLR)​​ 

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

آیا وزارت خدمات مراقبت‌های بهداشتی (DHCS) می‌تواند لطفاً توضیح دهد که منظور از اینکه DHCS یک سال پس از تاریخ شروع به کار در ژوئیه 1 ، 2025 ، بررسی‌های انطباق اجرای CLR در طرح‌های مراقبت مدیریت‌شده (MCP) مدی-کال را آغاز خواهد کرد، چیست؟ آیا DHCS انتظار دارد که MCPها تا ماه جولای 1 ، 2025 کاملاً با CLR مطابقت داشته باشند؟​​ 

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) ارسال کنند.​​ 

آیا DHCS تأیید می‌کند که اگر ECM یا ارائه‌دهنده خدمات پشتیبانی اجتماعی تأیید کنند که خدمات از طریق داده‌های موجود در RTF ارائه یا آغاز شده‌اند، MCP می‌تواند حلقه را به عنوان «خدمات دریافتی» ببندد؟ اصطلاح خدمات قابل پرداخت به این معنی است که MCP ادعایی دریافت کرده است که می‌تواند شش ماه طول بکشد.​​ 

MCPها می‌توانند حلقه CLR را به عنوان «خدمات دریافتی» ببندند، زمانی که ارائه‌دهنده خدمات، ارائه خدمات را از طریق عنصر داده‌ای «دلیل ارجاع حلقه بسته شدن» در RTF تأیید کند.​​ 

الزامات ردیابی و اطلاع‌رسانی CLR چگونه در مراکز ترک اعتیاد اعمال می‌شود؟  آیا برای خدمات ۲۴ ساعته، اطلاع رسانی به اعضا الزامی است؟​​ 

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

آیا DHCS می‌تواند کاربرد مورد نظر از مقدار وضعیت ارجاع «رد شده» توسط ECM و ارائه دهندگان پشتیبانی اجتماعی را روشن کند؟​​ 

مقادیر استاندارد وضعیت ارجاع CLR ممکن است در طول زمان در طیف وسیعی از خدمات اعمال شود. در حال حاضر، DHCS پیش‌بینی می‌کند که ارائه‌دهندگان خدمات ECM و Community Supports ممکن است به هر یک از دلایل زیر، وضعیت ارجاع «رد شده» را وارد کنند: ارائه‌دهنده فاقد ظرفیت باشد، عضو در منطقه تحت پوشش او زندگی نکند، یا به دلایل دیگر. MCPها باید با ارائه‌دهندگان شبکه خود همکاری کنند و رویه‌های مستند و روشنی را ارائه دهند تا مشخص شود کدام دلایل برای رد ارجاع مطابق با سیاست‌های ECM و پشتیبانی‌های اجتماعی مجاز است و چگونه باید در مقدار وضعیت ارجاع ذکر شود. منظور DHCS این نیست که MCPها باید سیاست‌های جدیدی اتخاذ کنند تا به ارائه‌دهندگان شبکه اجازه دهند ارجاعات را رد کنند.​​ 

در ضمیمه DHCS به راهنمای سیاست PHM: راهنمای اجرای ارجاع حلقه بسته، جدول 4: پردازش ارجاع، «نام ارائه دهنده خدمات» و «شماره تلفن ارائه دهنده خدمات» را فهرست کرده است. میشه لطفا DHCS توضیح بده که آیا این همون مدیر مراقبتیِ سرپرستِ تعیین‌شده برای عضو هست یا نه و شماره تلفنش رو هم بده؟​​ 

«نام ارائه‌دهنده خدمات» و «شماره تلفن ارائه‌دهنده خدمات» نام و شماره تلفن نهادی (یعنی ارائه‌دهنده خدمات) است که درخواست ارجاع ECM یا پشتیبانی اجتماعی را از MCP یا نهاد ارجاع‌دهنده دریافت می‌کند. برای مثال، در صفحات ۲۳-۲۴ راهنمای داده‌های CalAIM: اشتراک‌گذاری اطلاعات در سطح اعضا بین MCPها و راهنمای ارائه‌دهندگان ECM، اطلاعات با «نام ارائه‌دهنده ECM» و «شماره تلفن ارائه‌دهنده ECM» مطابقت دارد. هدف از این فیلدها تأیید این است که MCP اطلاعات تماس ثبت‌شده‌ای دارد که می‌تواند از آن برای پشتیبانی از ارجاع و ارائه خدمات به عضو برای ارائه‌دهندگان/خدمات مختلفی که الزامات CLR در مورد آنها اعمال می‌شود، استفاده کند.​​ 

آیا DHCS می‌تواند تفاوت بین «نام سازمان ارائه‌دهنده خدمات» و «نام ارائه‌دهنده خدمات» را توضیح دهد؟​​ 

«نام سازمان ارائه‌دهنده خدمات» همان ارائه‌دهنده ECM (یعنی نام سازمان) است. «نام ارائه‌دهنده خدمات» مدیر مراقبت ارشد ECM است که برای ارائه خدمات ECM (شخصی در سازمان که به عضو اختصاص داده شده است) منصوب شده است.​​ 

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

قانون قابلیت انتقال و پاسخگویی بیمه سلامت مصوب ۱۹۹۶ (HIPAA) به نهادهای تحت پوشش، از جمله MCPها، اجازه می‌دهد تا بدون اجازه بیمار، از «اطلاعات سلامت محافظت‌شده» (PHI) برای اهداف خاصی، از جمله درمان، پرداخت یا عملیات مراقبت‌های بهداشتی (برخی فعالیت‌های اداری، حقوقی، مالی و بهبود کیفیت، از جمله هماهنگی مراقبت و مدیریت پرونده) استفاده یا آن را افشا کنند. چنین افشاگری‌هایی می‌تواند هم برای سایر نهادهای تحت پوشش (مثلاً ارائه‌دهندگان خدمات درمانی) و هم برای نهادهای غیر تحت پوشش (مثلاً ارائه‌دهندگان مسکن، سازمان‌های اجتماعی (CBO)) انجام شود، مادامی که افشاگری‌ها برای اهداف درمان، پرداخت و عملیات مراقبت‌های بهداشتی باشد.​​  

دلیل بسته شدن حلقه ارجاع و تاریخ بسته شدن حلقه ارجاع، هر دو PHI تحت HIPAA را تشکیل می‌دهند؛ به عنوان نهادهای تحت پوشش، MCPها می‌توانند این اطلاعات را بدون نیاز به اطلاعات شخصی با نهادهای غیر تحت پوشش به اشتراک بگذارند.​​ مجوز دوگانه برای اهداف درمان و هماهنگی مراقبت. 45 CFR 164.506(c)(1) مقرر می‌کند که نهادهای تحت پوشش می‌توانند از PHI برای اهداف درمانی، پرداخت و عملیات مراقبت‌های بهداشتی خود استفاده و آن را افشا کنند.​​ 

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

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

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

«در انتظار» وضعیت پیش‌فرض ارجاع برای ارجاعی است که به یک ECM یا ارائه‌دهنده پشتیبانی اجتماعی در MIF انجام می‌شود، زمانی که ارائه‌دهنده هنوز ارجاع را مشاهده نکرده و تأیید نکرده است که ظرفیت خدمت‌رسانی به عضو را دارد و قصد دارد اطلاع‌رسانی را آغاز کند. «پذیرفته‌شده» زمانی نشان داده می‌شود که ارائه‌دهنده، ارجاع را بررسی کند و قصد داشته باشد با عضو تماس بگیرد اما هنوز این کار را نکرده است. برای توضیحات بیشتر در مورد مقادیر متغیر وضعیت ارجاع، لطفاً به جدول ۱۱ راهنمای پیاده‌سازی CLR مراجعه کنید.​​ 

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

مقادیر استاندارد وضعیت ارجاع CLR ممکن است در طول زمان در طیف وسیعی از خدمات اعمال شود. در حال حاضر، DHCS پیش‌بینی می‌کند که ارائه‌دهندگان خدمات ECM و Community Supports ممکن است به هر یک از دلایل زیر، وضعیت ارجاع «رد شده» را وارد کنند: ارائه‌دهنده فاقد ظرفیت باشد، عضو در منطقه تحت پوشش او زندگی نکند، یا به دلایل دیگر. MCPها باید با ارائه‌دهندگان شبکه خود همکاری کنند و رویه‌های مستند و روشنی را ارائه دهند تا مشخص شود کدام دلایل برای رد ارجاع مطابق با سیاست‌های ECM و پشتیبانی‌های اجتماعی مجاز است و چگونه باید در مقدار وضعیت ارجاع ذکر شود. منظور DHCS این نیست که MCPها باید سیاست‌های جدیدی اتخاذ کنند تا به ارائه‌دهندگان شبکه اجازه دهند ارجاعات را رد کنند.​​ 

آیا DHCS می‌تواند تأیید کند که تعریف «CLRهایی که برای مدت طولانی باز بوده‌اند» به صلاحدید MCP است؟​​ 

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

آیا DHCS می‌تواند لطفاً توضیح دهد که منظور از «پاسخ به استعلام» در عبارت «از MCPها انتظار می‌رود ظرف یک روز کاری به استعلام پاسخ دهند» چیست؟​​ 

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

چگونه DHCS بر رعایت الزام پاسخ به سوالات اعضا ظرف یک روز کاری نظارت خواهد کرد؟​​ 

DHCS یک سال پس از تاریخ اجرای جولای 1 ، 2025 ، بررسی‌های مربوط به انطباق CLR های MCP ها را آغاز خواهد کرد. DHCS ممکن است درخواست مستندات موردی، تکمیل ممیزی‌ها یا ارائه اقدامات دیگر را برای اطمینان از برآورده شدن این الزام در نظر بگیرد و از قبل به MCPها اطلاع خواهد داد.​​ 

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

هدف از این الزام، افزایش احتمال این است که نیازی که منجر به ارجاع اولیه به ECM یا Community Supports شده است، همچنان برای عضو برطرف شود. در صورت رد مجوز ECM به دلیل واجد شرایط بودن، گام بعدی برای MCP می‌تواند بررسی درخواست CCM برای نیازهای عضو و ارائه CCM به عنوان جایگزین یا اطلاع‌رسانی به D-SNP عضو در مورد نیاز او به مدیریت مراقبت و تأیید دریافت پشتیبانی از D-SNP برای مدیریت مراقبت باشد.​​ 

بیشتر ارجاعات ECM طرح را دور می‌زنند و مستقیماً به ارائه‌دهندگان ECM مراجعه می‌کنند که احتمالاً اعضا را ثبت‌نام می‌کنند. چگونه طرح‌ها می‌توانند حداقل داده‌های تعیین‌شده برای CLR را بدون مشاهده‌ی مبدأ ارجاع، ردیابی کنند؟ اگر ردیابی مورد نیاز باشد، بار گزارش‌دهی و اداری قابل توجهی به شبکه ارائه‌دهندگان ECM ما اضافه خواهد شد.​​ 

برای راهنمایی در مورد کدگذاری درخواست‌های ارجاع/مجوز از ارائه‌دهندگان ECM به MCPها تحت ترتیبات مجوز احتمالی، لطفاً به پیوست B بخش 1.A.3 از راهنمای پیاده‌سازی CLR مراجعه کنید.​​ 

DHCS انتظار دارد MCPها در چه سطحی از وضعیت، گزارش ارائه دهند؟​​ 

لطفاً برای مشاهده مشخصات کامل و عناصر داده‌ای که MCPها ملزم به ردیابی آنها برای خدمات تحت الزامات CLR (ECM و پشتیبانی‌های اجتماعی) هستند، به بخش «راهنمای پیاده‌سازی CLR» در مورد ردیابی مراجعه کنید. پیوست ب جزئیات بیشتری در مورد مقادیر متغیرهای کلیدی ردیابی مانند «وضعیت ارجاع» و نحوه جمع‌آوری داده‌ها از ECM و ارائه‌دهندگان پشتیبانی اجتماعی از طریق RTF ماهانه ارائه می‌دهد. قالب‌های JSON فاز ۴ که در ماه فوریه منتشر شدند، حاوی عناصر داده‌ای دقیق برای ارسال‌های مانیتورینگ CLR هستند.​​ 

وقتی ارجاعات برای مدت طولانی در حالت تعلیق باقی می‌مانند، DHCS چه سطح مداخله‌ای را انتظار دارد؟ آیا لازم است که این موضوع در تفاهم‌نامه (MOU) با هر آژانس ذکر شود؟​​ 

لطفاً برای مشاهده فهرستی از اقدامات نمونه‌ای که MCPها می‌توانند برای حمایت از ECM و ارائه‌دهندگان پشتیبانی اجتماعی در اطلاع‌رسانی به ارجاعات در حال بررسی و توصیه‌هایی برای پیگیری با عضو و نهاد ارجاع‌دهنده در این موارد انجام دهند، به بخش II.B.2 «حمایت از ارجاعات در حال بررسی و ارجاع مجدد» از راهنمای اجرای CLR مراجعه کنید.​​ 

اگر هر سازمان درخواست مداخلات متفاوتی از MCP داشته باشد (مثلاً WIC بگوید ظرف پنج روز کاری برای ارجاعات در حال بررسی اطلاع دهید، مرکز منطقه‌ای بگوید ظرف 30 روز کاری اطلاع دهید و غیره) چه می‌شود؟​​ 

در حال حاضر، الزامات CLR فقط در مورد ارجاعات به MCPها برای ECM و پشتیبانی‌های اجتماعی اعمال می‌شود. الزامات اطلاع‌رسانی CLR، انتظارات مربوط به نهادهای ارجاع‌دهنده اطلاع‌رسانی (مثلاً) را تشریح می‌کند. سازمان‌های مردم‌نهاد (CBO)، ارائه‌دهندگان خدمات درمانی، پزشکان مراقبت‌های اولیه (PCP)) در مورد تصمیم مجوز ارجاع مطابق با جدول زمانی مورد نیاز در APL 21-011 و دلیل خاتمه ارجاع در بازه‌های زمانی مشخص شده. لطفاً برای جزئیات الزامات اطلاع‌رسانی MCP CLR به بخش II.BI از راهنمای پیاده‌سازی CLR مراجعه کنید.​​ 

از آنجایی که MCPها ملزم به استفاده از فرم ارجاع DHCS برای ECM/حمایت‌های اجتماعی هستند، آیا MCPها می‌توانند این فرم را طوری تغییر دهند که شامل «آدرس ایمیل» برای اهداف اطلاع‌رسانی الکترونیکی باشد؟​​ 

استانداردهای ارجاع ECM در حال حاضر «آدرس ایمیل ارجاع‌دهنده» را به عنوان یک عنصر الزامی در جدول ۲ استانداردهای ارجاع ECM در نظر گرفته‌اند. برای جمع‌آوری این اطلاعات نیازی به به‌روزرسانی نیست.​​ 

چگونه MCP ها با ارجاعات تکراری از یک عضو و برای یک خدمت برخورد خواهند کرد؟ لطفا در این مورد راهنمایی بیشتری بفرمایید.​​ 

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

• سناریوی ۱: ارجاع برای خدماتی که عضو از قبل مجوز آن را دارد. در صورتی که یک MCP ارجاعی برای (مثلاً ECM) دریافت کند و عضو از قبل مجوز باز برای ECM داشته باشد، MCP باید اطلاعات کلیدی ارجاع را در هنگام دریافت ارجاع (تاریخ، نهاد ارجاع‌دهنده، سرویس) و تعیین مجوز مناسب (مثلاً رد شده) ثبت کند و زمینه لازم را در اطلاعیه اقدام (NOA) رد درخواست به نهاد ارجاع‌دهنده ارائه دهد (مثلاً، درخواست عضو رد می‌شود زیرا از قبل مجوز فعال و باز ECM دارد). MCPها همچنین باید اطلاعات تماس نهاد/عضو ارجاع‌دهنده را ارائه دهند تا در صورت تمایل به درخواست تغییر ارائه‌دهنده مجوز فعلی و آزاد خود، در صورت لزوم، با MCP تماس بگیرند.​​ 
• سناریوی ۲: ارجاع برای خدماتی که عضو، ارجاع باز دیگری برای آن در دست اقدام دارد. در صورتی که دو ارجاع برای یک سرویس به طور همزمان برای عضو باز باشد (مثلاً MCP) باید عناصر کلیدی ردیابی CLR را در ارجاع دوم ثبت کند. تاریخ ارجاع، نهاد ارجاع‌دهنده، خدمات، وضعیت مجوز). همچنان انتظار می‌رود که MCP الزامات مربوط به اطلاع‌رسانی CLR را برای نهاد ارجاع‌دهنده دوم رعایت کند. DHCS از MCPها می‌خواهد که اطلاعات مربوط به هر دو ارجاع را ثبت کنند، زیرا MCPها همچنان انتظار دارند که از طریق ارتباط با نهاد ارجاع‌دهنده، ارجاع را پشتیبانی کنند و در صورتی که ارجاعات تکراری باعث ایجاد عدم قطعیت در تعیین ارائه‌دهنده مناسب خدمات شود، از هرگونه هماهنگی لازم با عضو پشتیبانی کنند. برای مثال، اگر دو ارائه‌دهنده‌ی ECM مختلف، معرفی‌نامه‌هایی را برای عضو ارسال کنند، لازم است MCP هماهنگی لازم را بین ارائه‌دهندگان ECM عضو و ارجاع‌دهنده انجام دهد تا تخصیص یک ارائه‌دهنده‌ی ECM مورد نظر عضو انجام شود.
  
  MCP باید از سیاست‌ها و رویه‌های موجود پیروی کند و سهم/حجم اعضایی را که توسط یک نهاد ارجاع‌دهنده معرفی شده‌اند و مجوز آنها رد شده است، بررسی کند. اگر تعداد زیادی ارجاع تکراری برای یک عضو و یک سرویس وجود داشته باشد، MCP باید بحثی را تسهیل کند و با نهاد ارجاع‌دهنده کمک فنی ارائه دهد تا ارجاعات واجد شرایط و مجاز افزایش یابد.​​ 

توجه به CLR​​ 

اگر یک MCP با استفاده از داده‌های داخلی خود، فردی را واجد شرایط ECM یا پشتیبانی‌های اجتماعی تشخیص دهد (مثلاً «نوع ارجاع» «2» باشد.) توسط MCP شناسایی شده است)، آیا الزامات اطلاع رسانی اعمال می‌شود؟​​ 

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

اغلب دریافت و پاکسازی داده‌های RTF از ارائه‌دهندگان توسط MCPها زمان می‌برد. «زمان توجه» دو روز کاری برای بسته شدن حلقه ارجاع از چه زمانی شروع می‌شود؟​​ 

DHCS متوجه است که MCPها ممکن است پس از دریافت RTF از ارائه دهندگان، به زمان بیشتری برای دریافت و پردازش داده‌ها نیاز داشته باشند. به MCPها اجازه داده می‌شود تا پنج روز کاری، RTF را پردازش کرده و ظرف دو روز کاری پس از تکمیل پردازش داده‌ها (در صورت نیاز، در مجموع هفت روز از زمان دریافت RTF) به نهاد ارجاع‌دهنده اطلاع دهند.​​ 

آیا DHCS لطفاً تأیید می‌کند که اگر نهاد ارجاع‌دهنده عضو باشد، MCP چگونه باید این موضوع را اعلام کند؟ قیم یا سرپرست عضو؟ خانواده، دوست یا همسایه عضو؟​​ 

در صورتی که یک عضو، قیم/سرپرست او، یا یکی از اعضای خانواده، دوست یا همسایه، ارجاعی ارائه دهد و درخواست مجوز 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 خود ارائه دهند.​​ 

میشه لطفا DHCS توضیح بده منظور از خودارجاعی چیه؟ برای مثال، آیا همسایه یا معلم به عنوان خودارجاع برای اهداف اطلاع‌رسانی الزامات CLR در نظر گرفته می‌شوند؟ انتظار DHCS برای مستندسازی آن نوع ارجاع چیست؟​​ 

معرفی‌هایی که توسط یک عضو، همسایه، اعضای خانواده، دوست یا قیم/سرپرست او انجام می‌شود، خودارجاعی محسوب می‌شود. در صورت ارجاع خودخواسته برای دریافت مجوز ECM/Community Supports، MCPها همچنان باید تصمیم مربوط به مجوز را به عضو اطلاع دهند. هیچ الزام اطلاع‌رسانی دیگری برای نهادهای ارجاع‌دهنده اعمال نمی‌شود. MCPها باید تمام ارجاعات انجام شده به ECM و پشتیبانی‌های اجتماعی، از جمله ارجاعات شخصی را پیگیری، پشتیبانی و نظارت کنند. معلمان، در ظرفیت حرفه‌ای خود، به یک عضو خدمت می‌کنند و به عنوان «خودمعرف یا سرپرست» طبقه‌بندی نمی‌شوند، بنابراین، مشمول الزامات مربوط به نهادهای ارجاع‌دهنده هستند.​​ 

DHCS از MCPها می‌خواهد که برای به اشتراک گذاشتن اطلاعیه‌ها با نهادهای ارجاع‌دهنده از روش الکترونیکی (به جز فکس) استفاده کنند، مگر اینکه روش‌های غیرالکترونیکی دیگری به صورت متقابل مورد توافق قرار گیرد. این الزام، نگرانی‌های قانونی در مورد امکان اشتراک‌گذاری اطلاعات از طریق ایمیل را افزایش می‌دهد.​​ 

راهنمایی در مورد اینکه چه چیزی به عنوان یک روش الکترونیکی امن واجد شرایط است، در ... ارائه شده است.​​  ضمیمه G قرارداد MCP، ضمیمه همکار تجاری، بند 9.2. این بخش شامل تعهدات مربوط به حفاظت و امنیت PHI، از جمله رعایت بند فرعی C از 45 CFR Part 164 است.  DHCS به MCPها توصیه می‌کند که سوالات متداول خدمات بهداشتی و انسانی (HHS) را بررسی کنند:​​  آیا قانون امنیتی اجازه ارسال اطلاعات شخصی الکترونیکی (e-PHI) را از طریق ایمیل یا از طریق اینترنت می‌دهد؟ اگر چنین است، چه حمایت‌هایی باید اعمال شود؟​​ 

در پاسخ خود، HHS اظهار داشت که «قانون امنیتی صراحتاً استفاده از ایمیل برای ارسال e-PHI را ممنوع نمی‌کند.» با این حال، استانداردهای کنترل دسترسی (45 CFR § 164.312(a))، یکپارچگی (45 CFR § 164.312(c)(1)) و امنیت انتقال (45 CFR § 164.312(e)(1)) نهادهای تحت پوشش را ملزم به اجرای سیاست‌ها و رویه‌هایی برای محدود کردن دسترسی، محافظت از یکپارچگی و جلوگیری از دسترسی غیرمجاز به e-PHI می‌کند. استاندارد امنیت انتقال (§ 164.312(e)) همچنین شامل مشخصات قابل آدرس‌دهی برای کنترل‌های یکپارچگی و رمزگذاری است. این بدان معناست که نهاد تحت پوشش باید استفاده خود از شبکه‌های باز را ارزیابی کند، ابزارهای موجود و مناسب برای محافظت از e-PHI را در حین انتقال شناسایی کند، یک راه‌حل انتخاب کند و تصمیم خود را مستند کند. قانون امنیتی اجازه می‌دهد تا زمانی که e-PHI به اندازه کافی محافظت شده باشد، از طریق یک شبکه باز الکترونیکی ارسال شود.​​ 

DHCS به MCPها توصیه می‌کند که برای تعیین روش‌های امن انتقال الکترونیکی بر اساس این راهنمایی HHS، با وکیل خود مشورت کنند.​​  

آیا DHCS می‌تواند لطفاً توضیح دهد که آیا الزامات اطلاع‌رسانی که در APL 21-011 برای ارائه‌دهندگان خدمات درمانی شرح داده شده است (یعنی MCP باید ظرف 24 ساعت از تصمیم، به ارائه‌دهنده خدمات درمانی اطلاع دهد) در مورد نهادهای ارجاع‌دهنده نیز، همانطور که توسط DHCS در راهنمای پیاده‌سازی CLR تعریف شده است، اعمال می‌شود؟​​ 

تمام ارجاعات به ECM و Community Supports یک درخواست مجوز محسوب می‌شوند و الزامات اطلاع‌رسانی APL 21-011 را به دنبال دارند. طبق APL 21-011، MCP ها باید از​​  الگوی اطلاعیه اقدام (NOA) مناسب که باید شامل توضیح مختصری از دلایل تصمیم باشد. این الزامات برای همه CLR های ساخته شده توسط نهادهای ارجاع دهنده اعمال می شود.​​ 

از DHCS درخواست می‌شود تا توضیح کتبی ارائه دهد که تأیید کند MCPها ممکن است PHI، از جمله بیماری روانی شدید (SMI)/اختلال مصرف مواد (SUD) و وضعیت رفاه کودک را بدون اجازه بیمار با نهادهای ارجاع‌دهنده‌ای که تحت پوشش نیستند، به اشتراک بگذارند.​​ 

DHCS توصیه می‌کند که مشخص شود آیا ECM یا پشتیبانی اجتماعی مجاز هستند و دلیل مرتبط با رد درخواست نیز در صورت لزوم ذکر شود.​​  برای به اشتراک گذاشتن خدمات کلی (ECM/حمایت‌های اجتماعی) و تصمیم مجوز، نیازی به تبادل اطلاعات SMI/SUD یا رفاه کودکان نیست. MCPها همچنین می‌توانند از رویه‌های موجود خود برای برآورده کردن الزامات اطلاع‌رسانی DHCS تحت APL-21-011 برای ECM و پشتیبانی‌های اجتماعی از زمان آغاز به کار این سرویس در سال 2022 پیروی کنند. 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 ارجاع داده شده‌اند، بی‌اطلاع هستند. تماس با ارائه‌دهنده‌ی ECM قبل از ارسال نامه‌ی NOA، رویکردی عضومحورتر خواهد بود و تضمین می‌کند که آن‌ها ارجاع و آنچه را که باید انتظار داشته باشند، درک می‌کنند. آیا DHCS می‌تواند راه‌هایی را برای ساده‌سازی این فرآیند بررسی کند تا سردرگمی کاهش یابد و تجربه اعضا بهبود یابد؟​​ 

راهنمای پیاده‌سازی CLR به‌روزرسانی شده است تا تنها یک اطلاعیه مورد نیاز برای اعضا را در زمان مجوز، مطابق با الزامات APL 21-011، منعکس کند. ECM از زمان تأسیس خود در سال ۲۰۲۲، مشمول الزامات اطلاع‌رسانی به اعضا طبق APL 21-011 بوده است.​​ 

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

DHCS از MCPها می‌خواهد که برای اطلاع‌رسانی وضعیت CLR از روش‌های الکترونیکی استفاده کنند، و صراحتاً فکس‌ها و پورتال‌ها را مستثنی کنند. این موضوع نگران‌کننده است، زیرا استاندارد صنعت برای اعلان‌های مجوز قبلی UM به خطوط فکس معتبر و قراردادی متکی است.  اگرچه ما از تلاش‌های DHCS برای فاصله گرفتن از ارتباطات فکس قدردانی می‌کنیم، اما اجرای این الزام تا اول جولای بدون وجود فناوری لازم، چالش‌های قابل توجهی را برای MCPها در دستیابی به انطباق با این الزامات ایجاد می‌کند.​​ 

برای ارائه دهندگان ارجاع دهنده غیر قراردادی، ما به دنبال شفاف سازی در مورد آنچه که به عنوان یک روش الکترونیکی امن واجد شرایط است، به استثنای فکس و پورتال، هستیم. DHCS چگونه «روش الکترونیکی» را تعریف می‌کند و آیا می‌تواند نمونه‌هایی از اشتراک‌گذاری الکترونیکی امن PHI با نهادهایی که شماره فکس یا ایمیل معتبر ندارند، ارائه دهد؟​​ 

راهنمایی در مورد اینکه چه چیزی به عنوان یک روش الکترونیکی امن واجد شرایط است، در ضمیمه 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 به دلایل زیر این الزام را حفظ می‌کند:​​ 

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

در صورتی که ارجاع برای پشتیبانی اجتماعی انجام شود و نهاد ارجاع‌دهنده، ارائه‌دهنده خدمات نیز باشد، رعایت الزامات اعلان برای بسته شدن حلقه ارجاع، بررسی کیفیت داده‌های مهمی را برای MCPها و ارائه‌دهندگان فراهم می‌کند. علاوه بر این، الزامات CLR برای نظارت و پشتیبانی از CLRها، بر نقش MCPها در بررسی دلایل بسته شدن حلقه ارجاع توسط ارائه‌دهنده خدمات تأکید دارد تا شکاف‌های موجود در رویکردهای تعامل و بهترین شیوه‌ها را شناسایی کند. در نهایت، الزامات CLR برای اعلان بسته شدن حلقه ارجاع، تابع APL 21-011 نیست و به MCPها انعطاف‌پذیری در ارسال اعلان‌های دسته‌ای و الکترونیکی به نهادهای ارجاع‌دهنده با حجم بالای بسته شدن حلقه ارجاع در هر ماه را می‌دهد.​​