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 ກໍາລັງໃຫ້ MCPs ໄລຍະເວລາຜ່ອນຜັນສໍາລັບການໄດ້ຮັບລະບົບ CLR ແລະຂະບວນການຕ່າງໆຫຼັງຈາກນະໂຍບາຍ CLR ມີຜົນບັງຄັບໃຊ້ໃນວັນ 1 ກໍລະກົດ, 2025. ໃນຂະນະທີ່ DHCS ຄາດຫວັງວ່າ MCPs ຈະປະຕິບັດ CLR ພາຍໃນເດືອນກໍລະກົດ 1, 2025, DHCS ຍອມຮັບວ່າອາດຈໍາເປັນຕ້ອງໃຊ້ເວລາເພີ່ມເຕີມເພື່ອປັບປ່ຽນຄວາມຕ້ອງການດ້ານການປະຕິບັດ ແລະການປະຕິບັດ CLR ເຊັ່ນ: ວິທີການສັງເກດ ແລະການຕິດຕາມ, ການປັບປຸງລະບົບ ແລະຂັ້ນຕອນການເຮັດວຽກຫຼັງຈາກວັນທີສົດ. ດັ່ງນັ້ນ, DHCS ຈະເລີ່ມຕິດຕາມຢ່າງຈິງຈັງສຳລັບການປະຕິບັດຕາມຕັ້ງແຕ່ວັນ 1 ກໍລະກົດ, 2026.
ຕິດຕາມການອ້າງອີງສະມາຊິກ
MCPs ບາງຄັ້ງໄດ້ຮັບຂໍ້ມູນເລື້ອຍໆແລະມີຄຸນຄ່າກ່ຽວກັບການສົ່ງຕໍ່ແລະສະຖານະການມີສ່ວນພົວພັນໂດຍກົງຈາກຜູ້ໃຫ້ບໍລິການດ້ານການຄຸ້ມຄອງການດູແລ (ECM) ຂອງພວກເຂົາ. ມັນເປັນໄປໄດ້ທີ່ຈະປະກອບມີແຫຼ່ງຂໍ້ມູນທາງເລືອກສໍາລັບການເຮັດສໍາເລັດຂໍ້ກໍານົດການຕິດຕາມ CLR ກັບການກ່າວເຖິງການຮຽກຮ້ອງເພີ່ມເຕີມແລະຂໍ້ມູນການພົບ?
MCPs ອາດຈະໃຊ້ແຫຼ່ງຂໍ້ມູນທາງເລືອກເພື່ອເສີມແຫຼ່ງການຕິດຕາມ CLR ທີ່ລະບຸໄວ້ໃນຄໍາແນະນໍາ; ແນວໃດກໍ່ຕາມ, MCPs ບໍ່ສາມາດຮຽກຮ້ອງໃຫ້ ECM/Community Supports Providers ສົ່ງຂໍ້ມູນການຕິດຕາມຜ່ານທາງອື່ນນອກເໜືອໄປຈາກ Return Transmission File (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 ແລະຂໍ້ກໍານົດການແຈ້ງການໃຊ້ກັບສູນ sobering ແນວໃດ? ການແຈ້ງເຕືອນສະມາຊິກແມ່ນຕ້ອງການສໍາລັບການບໍລິການ 24 ຊົ່ວໂມງບໍ?
ຂໍ້ກຳນົດ CLR ຈະບໍ່ນຳໃຊ້ກັບສູນ Sobering ເພາະວ່າການບໍລິການມັກຈະຖືກຈັດສົ່ງໃນເວລາຈິງ, ໄລຍະເວລາພັກເຊົາແມ່ນຕ່ຳກວ່າ 24 ຊົ່ວໂມງ, ແລະ ໂດຍທົ່ວໄປແລ້ວການບໍລິການແມ່ນໄດ້ຮັບອະນຸຍາດຕາມຫຼັງເພື່ອອຳນວຍຄວາມສະດວກໃນການເຂົ້າເຖິງການຊ່ວຍເຫຼືອຊຸມຊົນນີ້ໃຫ້ທັນເວລາ.
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) ກັບຫນ່ວຍງານທີ່ບໍ່ມີການຄຸ້ມຄອງໂດຍບໍ່ມີການອະນຸຍາດຈາກສະມາຊິກ. MCPs ເຊື່ອວ່າຄວາມຕ້ອງການນີ້ແມ່ນບໍ່ປະຕິບັດຕາມ 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 ສາມາດໃຫ້ຄວາມກະຈ່າງແຈ້ງກ່ຽວກັບຄວາມແຕກຕ່າງລະຫວ່າງສະຖານະພາບການສົ່ງຕໍ່ 1 – ຍອມຮັບ ແລະ 3-ຍັງຄ້າງຢູ່, ເນື່ອງຈາກວ່າມັນບໍ່ຈະແຈ້ງໃນຂັ້ນຕອນການເຮັດວຽກຂອງ 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.
MCPs ມີຄວາມກັງວົນວ່າ 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.
ກະລຸນາເບິ່ງເອກະສານຊ້ອນທ້າຍ B ພາກທີ 1.A.3. ຂອງຄໍາແນະນໍາການຈັດຕັ້ງປະຕິບັດ CLR ສໍາລັບຄໍາແນະນໍາກ່ຽວກັບການຂຽນລະຫັດການສົ່ງຕໍ່ / ການຮ້ອງຂໍການອະນຸຍາດທີ່ມາຈາກຜູ້ໃຫ້ບໍລິການ ECM ກັບ MCPs ພາຍໃຕ້ການຈັດການການອະນຸຍາດທີ່ສົມມຸດຕິຖານ.
DHCS ຄາດຫວັງໃຫ້ MCPs ລາຍງານສະຖານະການໃນລະດັບໃດ?
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.
MCPs ຈະເຂົ້າຫາການອ້າງອີງທີ່ຊໍ້າກັນຈາກສະມາຊິກດຽວກັນ ແລະການບໍລິການດຽວກັນແນວໃດ? ກະລຸນາໃຫ້ຄໍາແນະນໍາເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້.
ກະລຸນາເບິ່ງສະຖານະການຕົວຢ່າງຂ້າງລຸ່ມນີ້:
- ສະຖານະການທີ 1: ການສົ່ງຕໍ່ການບໍລິການທີ່ສະມາຊິກໄດ້ຮັບອະນຸຍາດແລ້ວ. ໃນກໍລະນີທີ່ MCP ໄດ້ຮັບການສົ່ງຕໍ່ສໍາລັບ (e. g. ECM) ແລະສະມາຊິກມີໃບອະນຸຍາດເປີດສໍາລັບ ECM ແລ້ວ, MCP ຄວນບັນທຶກຂໍ້ມູນການອ້າງອິງທີ່ສໍາຄັນໃນໃບຮັບການອ້າງອິງ (ວັນທີ, ຫນ່ວຍງານອ້າງອີງ, ການບໍລິການ) ແລະການກໍານົດການອະນຸຍາດທີ່ເຫມາະສົມ (ຕົວຢ່າງ, ປະຕິເສດ) ແລະສະຫນອງສະພາບການທີ່ຈໍາເປັນຕໍ່ຫນ່ວຍງານອ້າງອີງໃນຫນັງສືແຈ້ງການຂອງການປະຕິບັດ), ສະມາຊິກປະຕິເສດແລ້ວ (NO. ການອະນຸຍາດ ECM ທີ່ເຄື່ອນໄຫວ, ເປີດ). MCPs ຄວນໃຫ້ຂໍ້ມູນການຕິດຕໍ່ສໍາລັບຫນ່ວຍງານທີ່ອ້າງອິງ / ສະມາຊິກເພື່ອຕິດຕໍ່ 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 ຊຸກຍູ້ໃຫ້ MCPs ແຈ້ງສະມາຊິກວ່າເຂົາເຈົ້າມີສິດໄດ້ຮັບ ແລະຖືກສົ່ງຕໍ່ກັບການບໍລິການເພື່ອເພີ່ມຄວາມເປັນໄປໄດ້ຂອງການມີສ່ວນຮ່ວມຂອງສະມາຊິກ.
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 ເຂົ້າໃຈວ່າ MCPs ອາດຈະຕ້ອງການເວລາເພີ່ມເຕີມເພື່ອເອົາຂໍ້ມູນ ແລະປະມວນຜົນຂໍ້ມູນເມື່ອໄດ້ຮັບ RTF ຈາກຜູ້ໃຫ້ບໍລິການ. MCPs ໄດ້ຮັບອະນຸຍາດໃຫ້ເຖິງຫ້າມື້ເຮັດວຽກເພື່ອປະມວນຜົນ 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, MCPs ຈະຍັງສະຫນອງການແຈ້ງການຂອງການຕັດສິນໃຈການອະນຸຍາດໃຫ້ສະມາຊິກ. ບໍ່ມີຂໍ້ກໍາຫນົດການສັງເກດການອື່ນໆນໍາໃຊ້.
ແມ່ນຫຍັງຄືຄວາມຄາດຫວັງຂອງສະມາຊິກທີ່ສັງເກດເຫັນຖ້າຫາກວ່າສະມາຊິກໄດ້ເລືອກອອກຈາກການໄດ້ຮັບແຈ້ງການເປັນລາຍລັກອັກສອນຈາກ MCP?
MCPs ຄວນປະຕິບັດຕາມນະໂຍບາຍພາຍໃນຂອງພວກເຂົາກ່ຽວກັບວິທີທາງເລືອກໃນການຕິດຕໍ່ກັບສະມາຊິກທີ່ມີຂໍ້ມູນທີ່ສໍາຄັນຫຼື NOAs ໃນກໍລະນີທີ່ພວກເຂົາເລືອກອອກຈາກການຮັບການສື່ສານເປັນລາຍລັກອັກສອນ. ສໍາລັບຕົວຢ່າງ, MCP ອາດຈະຕິດຕໍ່ກັບສະມາຊິກທາງໂທລະສັບຫຼືວິທີການທາງອີເລັກໂທຣນິກທີ່ປອດໄພຖ້າພວກເຂົາເລືອກອອກຈາກການສື່ສານເປັນລາຍລັກອັກສອນ.
ຂໍ້ກໍານົດການສັງເກດເຫັນສະມາຊິກມີຜົນບໍເມື່ອການອະນຸຍາດສໍາລັບ ECM ຖືກປະຕິເສດເນື່ອງຈາກສະມາຊິກໄດ້ລົງທະບຽນຢູ່ໃນ ECM ແລ້ວ?
ແມ່ນແລ້ວ, ການສົ່ງຕໍ່ ECM ແລະການຊ່ວຍເຫຼືອຊຸມຊົນທັງໝົດແມ່ນເປັນການຮ້ອງຂໍການອະນຸຍາດ ແລະກະຕຸ້ນຄວາມຕ້ອງການແຈ້ງການ APL 21-011. ພາຍໃຕ້ APL 21-011, MCPs ຈະຕ້ອງໃຊ້ແມ່ແບບ NOA ທີ່ເໝາະສົມເຊິ່ງຈະຕ້ອງມີຄໍາອະທິບາຍຫຍໍ້ກ່ຽວກັບເຫດຜົນຂອງການຕັດສິນໃຈ. ໃນກໍລະນີທີ່ ECM ຖືກປະຕິເສດຍ້ອນການອະນຸຍາດທີ່ມີຢູ່ແລ້ວ, MCPs ຄວນບອກເຫດຜົນຂອງການຫຼຸດລົງຢ່າງຊັດເຈນແລະສະເຫນີວິທີການຕິດຕໍ່ກັບ 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 ຮຽກຮ້ອງໃຫ້ MCPs ໃຊ້ວິທີການທາງອີເລັກໂທຣນິກ (ບໍ່ລວມເອົາແຟັກ) ເພື່ອແບ່ງປັນແຈ້ງການກັບໜ່ວຍງານທີ່ອ້າງອີງ, ເວັ້ນເສຍແຕ່ວິທີການອື່ນໆທີ່ບໍ່ແມ່ນທາງອີເລັກໂທຣນິກຈະຕົກລົງຮ່ວມກັນ. ຂໍ້ກໍານົດນີ້ເຮັດໃຫ້ເກີດຄວາມກັງວົນທາງດ້ານກົດຫມາຍກ່ຽວກັບການສາມາດແບ່ງປັນຂໍ້ມູນຜ່ານທາງອີເມວ.
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 ເພື່ອຢືນຢັນວ່າ MCPs ອາດຈະແບ່ງປັນ 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 ສໍາລັບການທົບທວນຄືນບໍ? ຖ້າເປັນດັ່ງນັ້ນ, ໄລຍະເວລາຂອງການທົບທວນແລະອະນຸມັດແມ່ນຫຍັງ?
MCPs ຄວນໃຊ້ແມ່ແບບການສັງເກດເຫັນທີ່ມີຢູ່ແລ້ວຂອງເຂົາເຈົ້າສໍາລັບການບໍລິການທີ່ໄດ້ຮັບອະນຸຍາດພາຍໃຕ້ APL 21-011 ເພື່ອຕອບສະຫນອງຄວາມຕ້ອງການແຈ້ງການຂອງສະມາຊິກ.
ເຮັດໃຫ້ເກີດຄວາມກັງວົນວ່າການແຈ້ງເຕືອນສະມາຊິກຫຼາຍຄັ້ງສາມາດມີຜົນກະທົບກົງກັນຂ້າມ, ເຊິ່ງກໍ່ໃຫ້ເກີດຄວາມສັບສົນຫຼາຍກວ່າຄວາມຊັດເຈນ. ໃນປັດຈຸບັນ, ພາຍໃຕ້ APL 21-011, ສະມາຊິກໄດ້ຮັບຈົດຫມາຍສະບັບດຽວເມື່ອພວກເຂົາໄດ້ຮັບການອະນຸມັດຫຼືປະຕິເສດການບໍລິການ ECM. ດ້ວຍ CLR, ພວກເຂົາສາມາດໄດ້ຮັບຈົດຫມາຍສາມຫຼືຫຼາຍກວ່ານັ້ນກັບ NOAs, ເຊິ່ງອາດຈະນໍາໄປສູ່ຄວາມກັງວົນທີ່ບໍ່ຈໍາເປັນ.
ນອກຈາກນັ້ນ, MCPs ມັກຈະພົບວ່າສະມາຊິກບໍ່ຮູ້ເຖິງວ່າພວກເຂົາຖືກອ້າງເຖິງ ECM ໃນສະຖານທີ່ທໍາອິດ. ການໃຫ້ຜູ້ໃຫ້ບໍລິການ ECM ເຂົ້າເຖິງກ່ອນທີ່ຈົດໝາຍ NOA ຈະຖືກສົ່ງໄປເປັນວິທີການທີ່ເນັ້ນໃສ່ສະມາຊິກຫຼາຍຂຶ້ນ, ຮັບປະກັນວ່າເຂົາເຈົ້າເຂົ້າໃຈການສົ່ງຕໍ່ ແລະສິ່ງທີ່ຄາດຫວັງ. DHCS ສາມາດຊອກຫາວິທີການປັບປຸງຂະບວນການນີ້ເພື່ອຫຼຸດຜ່ອນຄວາມສັບສົນ ແລະປັບປຸງປະສົບການສະມາຊິກໄດ້ບໍ?
ຄໍາແນະນໍາການຈັດຕັ້ງປະຕິບັດ CLR ໄດ້ຖືກປັບປຸງເພື່ອສະທ້ອນເຖິງພຽງແຕ່ຫນຶ່ງແຈ້ງການທີ່ຈໍາເປັນສໍາລັບສະມາຊິກໃນເວລາທີ່ອະນຸຍາດໃຫ້ສອດຄ່ອງກັບຂໍ້ກໍານົດສໍາລັບ APL 21-011. ECM ໄດ້ປະຕິບັດຕາມຂໍ້ກໍານົດການແຈ້ງການສະມາຊິກ APL 21-011 ນັບຕັ້ງແຕ່ການເລີ່ມຕົ້ນໃນປີ 2022.
ຕົວຢ່າງທີ່ອ້າງເຖິງສະມາຊິກທີ່ບໍ່ຮູ້ກ່ຽວກັບການສົ່ງຕໍ່ທີ່ວາງໄວ້ໃນນາມຂອງພວກເຂົາຕໍ່ ECM ເປັນຕົວແທນໃຫ້ໂອກາດການຊ່ວຍເຫຼືອດ້ານວິຊາການສໍາລັບ MCPs ກັບຫນ່ວຍງານທີ່ອ້າງອີງເພື່ອປັບປຸງການປະຕິບັດການສົ່ງຕໍ່ Entity ຂອງການສົນທະນາການສົ່ງຕໍ່ກັບສະມາຊິກກ່ອນທີ່ຈະສໍາເລັດການສົ່ງຕໍ່ຕາມທີ່ໄດ້ລະບຸໄວ້ໃນຄໍາແນະນໍາການຈັດຕັ້ງປະຕິບັດ 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?
ຄໍາແນະນໍາກ່ຽວກັບສິ່ງທີ່ມີຄຸນສົມບັດເປັນວິທີການເອເລັກໂຕຣນິກທີ່ປອດໄພແມ່ນສະຫນອງໃຫ້ຢູ່ໃນ Exhibit G ຂອງສັນຍາ MCP, ເອກະສານຊ້ອນຮ່ວມທຸລະກິດ, § 9.2. ພາກນີ້ລວມມີພັນທະທີ່ກ່ຽວຂ້ອງກັບການປົກປ້ອງ ແລະຄວາມປອດໄພຂອງ PHI, ລວມທັງການປະຕິບັດຕາມພາກສ່ວນຍ່ອຍ C ຂອງ 45 CFR ພາກທີ 164. DHCS ແນະນຳໃຫ້ MCPs ປຶກສາກັບທີ່ປຶກສາດ້ານກົດໝາຍຂອງເຂົາເຈົ້າເພື່ອກຳນົດວິທີການທີ່ປອດໄພຂອງການແບ່ງປັນຂໍ້ມູນທາງອີເລັກໂທຣນິກເພື່ອຕອບສະໜອງໄດ້ຕາມຂໍ້ກຳນົດຂອງ CLR. MCPs ອາດຈະຕ້ອງການຄົ້ນຫາອີເມລ໌ທີ່ປອດໄພ ຫຼືວິທີການທີ່ຄ້າຍຄືກັນ ແລະສ້າງແມ່ແບບການສັງເກດທີ່ແບ່ງປັນຂໍ້ມູນທີ່ຈໍາເປັນຂັ້ນຕ່ໍາເພື່ອຕອບສະຫນອງຄວາມຕ້ອງການພາຍໃຕ້ APL 21-011 ແລະຄໍາແນະນໍາການຈັດຕັ້ງປະຕິບັດ CLR.
ຄວາມກະຈ່າງແຈ້ງທີ່ຮ້ອງຂໍຈາກ DHCS ກ່ຽວກັບການແຈ້ງເຕືອນ / ຄວາມຄາດຫວັງຂອງການສື່ສານສໍາລັບສະມາຊິກໃນຂະນະທີ່ຖືກຄຸມຂັງ.
DHCS ແນະນໍາໃຫ້ອອກແບບແຈ້ງການສະມາຊິກສໍາລັບສະມາຊິກທີ່ຖືກຄຸມຂັງໂດຍການປະສານງານກັບຜູ້ປະສານງານການບໍລິການກ່ອນການປ່ອຍຕົວໃນແຕ່ລະສະຖາບັນການແກ້ໄຂເພື່ອກໍານົດທີ່ຢູ່ທີ່ເຫມາະສົມແລະວິທີການແບ່ງປັນແຈ້ງການໃນລັກສະນະເປັນຄວາມລັບທີ່ໄດ້ຮັບໂດຍສະມາຊິກ.
ການຮ້ອງຂໍການບໍລິການ (ການອ້າງອິງ) ຖືກສົ່ງເປັນປະຈໍາໂດຍຜູ້ໃຫ້ບໍລິການສະຫນັບສະຫນູນຊຸມຊົນເພື່ອສົ່ງສະມາຊິກໄປຫາອົງການຈັດຕັ້ງຂອງພວກເຂົາສໍາລັບການບໍລິການສະຫນັບສະຫນູນຊຸມຊົນ. ຜູ້ໃຫ້ບໍລິການຊ່ວຍເຫຼືອຊຸມຊົນທີ່ຖືກມອບໝາຍໃຫ້ຜູ້ທີ່ໃຫ້ບໍລິການແມ່ນໜ່ວຍງານອ້າງອີງ. ອົງການດຽວກັນທີ່ເປັນຜູ້ລິເລີ່ມການສົ່ງຕໍ່ຈະໃຫ້ການປັບປຸງ CLR ຜ່ານ RTF. ໃນກໍລະນີເຫຼົ່ານີ້, ຕ້ອງມີການແຈ້ງເຕືອນ CLR ເມື່ອປິດ loop ບໍ? ຖ້າເປັນເຊັ່ນນັ້ນ, ການແຈ້ງບອກຜູ້ໃຫ້ບໍລິການຊ່ວຍເຫຼືອຊຸມຊົນ/ໜ່ວຍງານອ້າງອີງເບິ່ງຄືວ່າຊໍ້າຊ້ອນ ແລະເພີ່ມພາລະການບໍລິຫານໃຫ້ກັບ MCP ເພື່ອສົ່ງການແຈ້ງເຕືອນໄປຫາຜູ້ໃຫ້ບໍລິການຊ່ວຍເຫຼືອຊຸມຊົນ/ໜ່ວຍງານອ້າງອີງທີ່ຮູ້ແລ້ວກ່ຽວກັບການປິດການສົ່ງຕໍ່ເນື່ອງຈາກເຂົາເຈົ້າເປັນໜ່ວຍງານດຽວກັນທີ່ແຈ້ງໃຫ້ MCP ກ່ຽວກັບສະຖານະການສົ່ງຕໍ່ຜ່ານການສົ່ງ RTF.
ແມ່ນແລ້ວ, ຄວາມຕ້ອງການສໍາລັບການແຈ້ງເຕືອນ CLR ເມື່ອການປິດການສົ່ງຕໍ່ Loop ຍັງຄົງໃຊ້ໃນກໍລະນີການນໍາໃຊ້ຂອງອົງການອ້າງອິງຍັງເປັນຜູ້ໃຫ້ບໍລິການສູງສຸດ. 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.
ໃນກໍລະນີທີ່ການອ້າງອິງຖືກວາງໄວ້ສໍາລັບການສະຫນັບສະຫນູນຊຸມຊົນແລະຫນ່ວຍງານອ້າງອີງຍັງເປັນຜູ້ໃຫ້ບໍລິການ, ການຮັກສາຄວາມຕ້ອງການແຈ້ງການສໍາລັບ Referral Loop Closure ສະຫນອງການກວດສອບຄຸນນະພາບຂໍ້ມູນທີ່ສໍາຄັນສໍາລັບທັງ MCPs ແລະຜູ້ໃຫ້ບໍລິການ. ນອກຈາກນັ້ນ, ຂໍ້ກໍານົດ CLR ສໍາລັບການຕິດຕາມແລະສະຫນັບສະຫນູນ CLRs ເນັ້ນຫນັກເຖິງບົດບາດຂອງ MCPs ໃນການທົບທວນເຫດຜົນການປິດການສົ່ງຕໍ່ໂດຍຜູ້ໃຫ້ບໍລິການເພື່ອກໍານົດຊ່ອງຫວ່າງໃນວິທີການມີສ່ວນຮ່ວມແລະການປະຕິບັດທີ່ດີທີ່ສຸດ. ສຸດທ້າຍ, ຄວາມຕ້ອງການ CLR ສໍາລັບການແຈ້ງເຕືອນການປິດການສົ່ງຕໍ່ Loop ແມ່ນບໍ່ຂຶ້ນກັບ APL 21-011 ແລະອະນຸຍາດໃຫ້ຄວາມຍືດຫຍຸ່ນຂອງ MCPs ໃນການສົ່ງ batch, ການແຈ້ງເຕືອນທາງອີເລັກໂທຣນິກໃຫ້ກັບຜູ້ອ້າງອີງທີ່ມີປະລິມານການປິດການສົ່ງຕໍ່ທີ່ສູງໃນແຕ່ລະເດືອນ.
ຕາມ APL 21-011, MCPs ປະຈຸບັນສົ່ງຈົດໝາຍການຕັດສິນການອະນຸຍາດໄປຫາໜ່ວຍງານອ້າງອີງ. ໃນກໍລະນີຂອງການປະຕິເສດຄໍາຮ້ອງສະຫມັກການບໍລິການ, ອົງການອ້າງອີງແລ້ວໄດ້ຮັບຈົດຫມາຍແຈ້ງໃຫ້ເຂົາເຈົ້າຂອງການປະຕິເສດແລະເຫດຜົນຂອງການປະຕິເສດ. ດັ່ງນັ້ນ, ນີ້ຈະຊ້ໍາກັນເພື່ອສົ່ງແຈ້ງການປິດ CLR ແລະຈົດຫມາຍຕັດສິນການອະນຸຍາດໄປຫາຫນ່ວຍງານອ້າງອີງ, ເນື່ອງຈາກວ່າທັງສອງການສື່ສານນີ້ຈະຖືກສົ່ງໄປໃນເວລາດຽວກັນ. DHCS ສາມາດໃຫ້ຄວາມກະຈ່າງແຈ້ງໄດ້ຖ້າ MCPs ຕ້ອງສົ່ງການແຈ້ງເຕືອນ CLR ແຍກຕ່າງຫາກໄປຫາໜ່ວຍງານອ້າງອີງສໍາລັບສະຖານະ CLR : ປິດ, ເຫດຜົນການປິດ CLR: ການບໍລິການ Auth ປະຕິເສດບໍ?
ຖ້າ MCP ປະຕິເສດການອະນຸຍາດການບໍລິການ, ຫຼັງຈາກນັ້ນ, ແຈ້ງການການອະນຸມັດການປະຕິເສດຕໍ່ອົງການອ້າງອີງແມ່ນພຽງພໍ. ດັ່ງນັ້ນ, ໃນກໍລະນີຂອງການປິດ CLR ເນື່ອງຈາກການປະຕິເສດການອະນຸຍາດ, ການແຈ້ງການປິດ CLR ແຍກຕ່າງຫາກແມ່ນບໍ່ຈໍາເປັນ.
ແບບຟອມການສົ່ງຕໍ່ ECM
ກະລຸນາໃຫ້ຄວາມກະຈ່າງແຈ້ງວ່າແບບຟອມການອ້າງອິງ ECM ເປັນຄໍາຮ້ອງຂໍການອະນຸຍາດບໍເນື່ອງຈາກບໍ່ມີພື້ນທີ່ຢູ່ໃນແບບຟອມສໍາລັບລະຫັດ ECM ຫຼືຄຸນນະພາບຂອງຫນ່ວຍງານ.
ແມ່ນແລ້ວ, ມາດຕະຖານການສົ່ງຕໍ່ ECM ແລະແມ່ແບບແບບຟອມເຮັດໜ້າທີ່ເປັນການສົ່ງຕໍ່ ECM ກັບ MCPs ໃນນາມສະມາຊິກທີ່ເຮັດໃຫ້ເກີດການຮ້ອງຂໍການອະນຸຍາດສໍາລັບ 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) ໄລຍະເວລາການອະນຸຍາດ ECM ມາດຕະຖານ: ສໍາລັບສະມາຊິກທຸກຄົນທີ່ໄດ້ຮັບອະນຸຍາດໃຫ້ໄດ້ຮັບ ECM ໂດຍ MCP ຂອງເຂົາເຈົ້າ, ໄລຍະເວລາການອະນຸຍາດເບື້ອງຕົ້ນຈະແມ່ນ 12 ເດືອນ ແລະໄລຍະເວລາການອະນຸມັດຄືນໃໝ່ຈະເປັນ 6 ເດືອນ. MCPs ອາດຈະບໍ່ກໍານົດຄວາມຕ້ອງການເພີ່ມເຕີມສໍາລັບການອະນຸຍາດການບໍລິການ ECM ເກີນກວ່າເງື່ອນໄຂການມີສິດໄດ້ຮັບຂອງປະຊາກອນທີ່ກໍານົດໂດຍ DHCS. ຕົວຢ່າງ, MCPs ອາດຈະບໍ່ຍຶດເອົາການອະນຸຍາດຈົນກວ່າແຜນການດູແລຈະສໍາເລັດ. (ໜ້າ 108, ECM PG)
- ECM HCPCS ຄໍາແນະນໍາ - ລະຫັດມາດຕະຖານສໍາລັບການຮຽກຮ້ອງແລະການພົບ
ລາຍງານ JSON
DHCS ສາມາດພິຈາລະນາຄືນການຮ້ອງຂໍໃຫ້ມີລາຍງານ JSON ໃດໆກ່ຽວກັບອົງປະກອບ CLR ຈົນຮອດຢ່າງໜ້ອຍເດືອນມັງກອນ 1, 2026? ມັນຈະເປັນການລະມັດລະວັງທີ່ຈະຍ້າຍການລາຍງານ CLR JSON ອອກໄປຫາຢ່າງໜ້ອຍເດືອນມັງກອນ 1, 2026, ເພື່ອໃຫ້ການປະຕິບັດຂະບວນການ ແລະການແລກປ່ຽນຂໍ້ມູນຖືກຈັດຕັ້ງປະຕິບັດຢ່າງເໝາະສົມ.
ໄລຍະທີ 4 ແມ່ແບບ CLR JSON ລວມມີອົງປະກອບຂໍ້ມູນ CLR ສໍາລັບຂໍ້ມູນການຕິດຕາມໄດ້ຖືກປ່ອຍອອກມາໃຫ້ MCPs ໃນເດືອນກຸມພາ 2025 ດ້ວຍຕາຕະລາງການທົດສອບທີ່ກ່ຽວຂ້ອງ, ແລະຄໍາແນະນໍາ JSON ໄລຍະ 4 ສຸດທ້າຍໄດ້ຖືກປ່ອຍອອກມາເມື່ອເດືອນມີນາ 28, 2025. ຄຳແນະນຳທັງໝົດສຳລັບການປັບປຸງ ECM ແລະເຄື່ອງມືແບ່ງປັນຂໍ້ມູນຊ່ວຍເຫຼືອຊຸມຊົນ (MIF, RTF, ແລະ ASF) ໄດ້ຖືກປ່ອຍອອກມາໃນເດືອນທັນວາ 2024 ດ້ວຍການອັບເດດສະເພາະເພື່ອຮອງຮັບ CLR ທີ່ລະບຸໄວ້ໃນເອກະສານ.
DHCS ຊຸກຍູ້ຢ່າງແຂງແຮງ MCPs ກ້າວໄປຂ້າງໜ້າດ້ວຍການອັບເດດຂໍ້ແນະນຳການແບ່ງປັນຂໍ້ມູນສະມາຊິກໃຫ້ສອດຄ່ອງກັບຄວາມຕ້ອງການທີ່ອອກໃນເດືອນທັນວາ 2024 ແລະໃຫ້ການຊ່ວຍເຫຼືອ ແລະການຊ່ວຍເຫຼືອດ້ານວິຊາການແກ່ ECM ແລະຜູ້ໃຫ້ການຊ່ວຍເຫຼືອຊຸມຊົນສຳລັບເດືອນກໍລະກົດ 1, 2025, ຖ່າຍທອດສົດການແນະນຳການແບ່ງປັນຂໍ້ມູນສະມາຊິກໃໝ່.