Անցնել բովանդակությանը​​ 
Տուն CalAIM. Medi-Cal-ի վերափոխումը Հաճախակի տրվող հարցեր փակ ցիկլի ուղղորդման վերաբերյալ​​ 

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-ը MCP-ներին տրամադրում է արտոնյալ ժամանակահատված՝ CLR համակարգերն ու գործընթացները տեղում տեղադրելու համար՝ CLR քաղաքականության ուժի մեջ մտնելուց հետո՝ հուլիսի 1, 2025: Մինչդեռ DHCS-ը ակնկալում է, որ MCP-ները կներդնեն CLR-ը մինչև հուլիս 1, 2025, DHCS-ը ընդունում է, որ կարող է լրացուցիչ ժամանակ պահանջվել CLR-ի գործառնական և ներդրման պահանջները կատարելագործելու համար, ինչպիսիք են նկատելու և հետևելու մեթոդաբանությունները, համակարգի թարմացումները և աշխատանքային հոսքերը գործարկման օրվանից հետո։ Հետևաբար, DHCS-ը կսկսի ակտիվորեն վերահսկել համապատասխանությունը՝ սկսած հուլիսի 1, 2026:​​ 

Անդամների ուղղորդումների հետևում​​ 

Բժշկական խնամքի բժիշկները երբեմն հաճախակի և արժեքավոր տեղեկատվություն են ստանում ուղեգրերի և ներգրավվածության կարգավիճակի վերաբերյալ անմիջապես իրենց բարելավված խնամքի կառավարման (ԲԿՄ) մատակարարներից: Հնարավո՞ր է լրացուցիչ պահանջների և հանդիպումների տվյալների հիշատակմանը զուգահեռ ներառել CLR հետևման պահանջները լրացնելու այլընտրանքային տվյալների աղբյուրներ։​​ 

MCP-ները կարող են օգտագործել այլընտրանքային տվյալների աղբյուրներ՝ ուղեցույցում նշված CLR հետևման աղբյուրները լրացնելու համար։ Սակայն, MCP-ները չեն կարող պահանջել, որ ECM/համայնքային աջակցություն մատուցողները հետևման համար տվյալներ ներկայացնեն վերադարձի փոխանցման ֆայլից (RTF) բացի այլ միջոցներով։​​ 

Will the DHCS confirm the MCP can close the loop as “Services Received” if the ECM or Community Supports provider confirms services are rendered or begun via data included on the RTF? The term billable service implies the MCP has received a claim which could take six months.​​ 

MCPs can close the loop of a CLR as “Services Received” once the Provider confirms services are rendered via the Reason for Referral Loop Closure data element in the RTF.​​ 

Ինչպե՞ս են CLR-ի հետևման և ծանուցման պահանջները կիրառվում սթափեցնող կենտրոնների նկատմամբ։  24-ժամյա ծառայության համար անդամի տեղեկացում պե՞տք է։​​ 

CLR պահանջները չեն կիրառվի զգաստության կենտրոնների նկատմամբ, քանի որ ծառայությունները հաճախ մատուցվում են իրական ժամանակում, մնալու տևողությունը 24 ժամից պակաս է, և ծառայությունները սովորաբար լիազորվում են հետադարձ ուժով՝ այս համայնքային աջակցությանը ժամանակին հասանելիությունը հեշտացնելու համար։​​ 

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-ը ապահովել անցում RTF-ում նոր CLR կարգավիճակի դաշտերի և առկա կարգավիճակի դաշտերի միջև փոխազդեցության համար և հեռացնել նոր 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.​​ 

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.​​ 

Խորհուրդ է տրվում դիմել CLR ներդրման ուղեցույցի Բ հավելվածի 1.A.3. բաժնին՝ ենթադրյալ թույլտվության կարգավորումների շրջանակներում ECM մատակարարներից MCP-ներին ուղարկվող ուղեգրերի/թույլտվության հարցումների կոդավորման վերաբերյալ ուղեցույցի համար:​​ 

Ի՞նչ մակարդակի կարգավիճակի մասին է DHCS-ը ակնկալում, որ MCP-ները հաշվետվություն ներկայացնեն:​​ 

Please see the CLR Implementation Guidance section on Tracking for the full specifications and data elements that MCPs are required to track for services under CLR requirements (ECM and Community Supports). Appendix B provides additional details on values for key tracking variables such as “Referral Status” and how the data should be collected from ECM and Community Supports Providers via the monthly RTF. JSON Phase 4 templates released in February contain the detailed data elements for CLR monitoring submissions.​​ 

Ի՞նչ մակարդակի միջամտություն է ակնկալում DHCS-ը, երբ ուղեգրերը մնում են անավարտ երկար ժամանակահատվածում: Արդյո՞ք դա պետք է ամրագրվի յուրաքանչյուր գործակալության հետ կնքված փոխըմբռնման հուշագրում (ՓՀ):​​ 

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-ները նույն անդամից և նույն ծառայության համար կրկնակի ուղեգրերին: Խնդրում եմ տրամադրել լրացուցիչ ուղեցույց այս հարցի վերաբերյալ։​​ 

Խնդրում ենք տեսնել ստորև բերված օրինակելի սցենարները.​​ 

  • Սցենար 1. Ուղեգիր այն ծառայության համար, որի համար անդամն արդեն լիազորված է: Այն դեպքում, երբ MCP-ն ստանում է ուղեգիր (օրինակ՝ ECM) և անդամն արդեն ունի ECM-ի բաց լիազորագիր, MCP-ն պետք է գրանցի ուղեգրման ստացականում ուղեգրման հիմնական տեղեկությունները (ամսաթիվ, ուղղորդող կազմակերպություն, ծառայություն) և համապատասխան լիազորագրի որոշումը (օրինակ՝ մերժված) և տրամադրի անհրաժեշտ համատեքստը ուղղորդող կազմակերպությանը մերժման գործողության մասին ծանուցման մեջ (օրինակ՝ անդամը մերժվում է, քանի որ նա արդեն ունի ակտիվ, բաց ECM լիազորագիր): Բժշկական խորհրդատուները (ԲԿԾ) պետք է տրամադրեն նաև ուղղորդող կազմակերպության/անդամի կոնտակտային տվյալները՝ ԲԿԾ-ի հետ կապվելու համար, եթե նրանք ցանկանում են դիմել մատակարարի փոփոխության համար իրենց ներկայիս, բաց լիազորագրի համար, ըստ անհրաժեշտության:​​ 
  • 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/համայնքային աջակցության թույլտվության համար, MCP-ները միևնույն է, անդամին կտեղեկացնեն թույլտվության որոշման մասին։ Այլ նկատառումների պահանջներ չեն կիրառվում։​​ 

Ի՞նչ ակնկալիքներ կան անդամից, եթե նա հրաժարվել է MCP-ից գրավոր ծանուցումներ ստանալուց։​​ 

MCP-ները պետք է հետևեն իրենց ներքին քաղաքականությանը՝ անդամների հետ կապվելու այլընտրանքային մեթոդների վերաբերյալ՝ հիմնական տեղեկատվությունը կամ NOA-ները տրամադրելու համար, եթե նրանք հրաժարվել են գրավոր հաղորդագրություններ ստանալուց։ Օրինակ, MCP-ն կարող է փոխարենը կապ հաստատել անդամի հետ հեռախոսով կամ թույլատրելի, անվտանգ էլեկտրոնային եղանակով, եթե նրանք հրաժարվել են գրավոր հաղորդակցությունից։​​ 

Արդյո՞ք անդամի ծանուցման պահանջները կիրառվում են, երբ ECM-ի թույլտվությունը մերժվում է ECM-ում արդեն գրանցված անդամի պատճառով։​​ 

Այո, ECM-ին և համայնքային աջակցությանը ուղղված բոլոր ուղղորդումները լիազորման հարցում են և առաջացնում են APL 21-011 ծանուցման պահանջներ։ APL 21-011-ի համաձայն, MCP-ները պետք է օգտագործեն համապատասխան NOA ձևանմուշը, որը պետք է ներառի որոշման պատճառների համառոտ բացատրությունը: Եթե ECM-ը մերժվում է առկա լիազորագրի պատճառով, MCP-ները պետք է հստակորեն նշեն մերժման պատճառը և առաջարկեն MCP-ի հետ կապվելու եղանակ՝ ցանկության դեպքում իրենց ECM մատակարարին փոխելու խնդրանքով։​​ 

Can DHCS please clarify who constitutes as a self-referral? For example, would a neighbor or teacher be considered a self-referral for purposes of CLR noticing requirements? What is DHCS’ expectation for documenting that type of referral?​​ 

Referrals made by a Member, their neighbor, family member, friend, or guardian/caretaker are considered self-referrals. In the case of a self-referral for ECM/Community Supports authorization, MCPs must still provide notice of the authorization decision to the Member. No other noticing requirements to Referring Entities apply. MCPs must track, support and monitor all referrals made to ECM and Community Supports, including self-referrals. Teachers, in their professional capacity, serve a Member, and are not classified as a “self or caretaker referral,” therefore, are subject to noticing requirements for Referring Entities.​​ 

DHCS-ը պահանջում է, որ MCP-ները օգտագործեն էլեկտրոնային եղանակ (բացառությամբ ֆաքսի)՝ ուղղորդող կազմակերպությունների հետ ծանուցումներ փոխանակելու համար, եթե փոխադարձ համաձայնությամբ այլ ոչ էլեկտրոնային մեթոդներ չեն կիրառվում։ Այս պահանջը իրավական մտահոգություններ է առաջացնում էլեկտրոնային փոստով տեղեկատվություն փոխանակելու հնարավորության վերաբերյալ։​​ 

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-ից գրավոր պարզաբանում է պահանջվում՝ հաստատելու համար, որ բժշկական խնամքի մասնագետները կարող են անձնական առողջության տվյալները (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 անդամների ծանուցման պահանջներին 2022 թվականին իր ստեղծման օրվանից ի վեր։​​ 

Բերված օրինակը, որ անդամները տեղյակ չեն իրենց անունից ECM-ին ներկայացված ուղեգրի մասին, ներկայացնում է տեխնիկական օգնության հնարավորություն ուղղորդող կազմակերպություններ ունեցող MCP-ների համար՝ բարելավելու ուղղորդող կազմակերպությունների պրակտիկան՝ անդամի հետ ուղեգրերը քննարկելու համար՝ նախքան ուղեգրումն ավարտելը, ինչպես նշված է CLR ներդրման ուղեցույցում:​​ 

DHCS requires MCPs to use electronic methods for communicating CLR status, explicitly excluding faxes and portals. This is concerning, as the industry standard for UM prior authorization notifications relies on validated, contracted fax lines.  While we appreciate DHCS’s efforts to move away from fax communication, implementing this requirement by July 1 without the necessary technology in place presents significant challenges for MCPs in achieving compliance.​​ 

For non-contracted referring providers, we seek clarification on what qualifies as a secure electronic method, excluding fax and portal. How does DHCS define “electronic method,” and can it provide examples of secure electronic PHI sharing with entities lacking validated fax numbers or emails?​​ 

Անվտանգ էլեկտրոնային մեթոդի համարվող մեթոդի վերաբերյալ ուղեցույցը տրամադրված է MCP պայմանագրի G հավելվածում՝ Գործարար գործընկերի հավելվածում, § 9.2: Այս բաժինը ներառում է PHI պաշտպանության և անվտանգության հետ կապված պարտավորությունները, ներառյալ 45 CFR Մաս 164-ի C ենթաբաժնի համապատասխանությունը: DHCS-ը խորհուրդ է տալիս MCP-ներին խորհրդակցել իրենց իրավաբանական խորհրդատուի հետ՝ CLR ծանուցման պահանջները բավարարելու համար էլեկտրոնային տեղեկատվության փոխանակման անվտանգ միջոցներ որոշելու համար։ MCP-ները կարող են ցանկանալ ուսումնասիրել անվտանգ էլ. փոստի կամ նմանատիպ մեթոդներ և մշակել ծանուցման ձևանմուշներ, որոնք կպարունակեն APL 21-011-ի և CLR ներդրման ուղեցույցի պահանջները բավարարելու համար անհրաժեշտ նվազագույն տեղեկատվությունը։​​ 

DHCS-ից պարզաբանում է պահանջվել անդամների կողմից բանտարկության ընթացքում ծանուցման/հաղորդակցության ակնկալիքների վերաբերյալ։​​ 

DHCS-ը խորհուրդ է տալիս մշակել անդամների ծանուցման համակարգ բանտարկված անդամների համար՝ յուրաքանչյուր ուղղիչ հիմնարկի նախնական ազատման ծառայությունների համակարգողի հետ համաձայնեցնելով՝ անդամի կողմից ստացված ծանուցումը գաղտնի եղանակով տրամադրելու համապատասխան հասցեն և միջոցները որոշելու համար։​​ 

Համայնքային աջակցության մատակարարները պարբերաբար ներկայացվում են ծառայությունների հարցումներ (ուղղորդումներ)՝ անդամներին իրենց համապատասխան կազմակերպություն ուղղորդելու համար համայնքային աջակցության ծառայությունների համար: Նշանակված համայնքային աջակցության մատակարարները, որոնք մատուցում են ծառայությունները, հանդիսանում են ուղղորդող կազմակերպությունը։ Նույն գործակալությունը, որը նախաձեռնել էր ուղղորդումը, կտրամադրեր CLR թարմացումներ RTF-ի միջոցով։ Այս դեպքերում, արդյո՞ք CLR ծանուցումներ են պահանջվում ցիկլի փակման ժամանակ։ Այդ դեպքում, համայնքային աջակցություն մատուցողին/ուղղորդող կազմակերպությանը տեղեկացնելը թվում է ավելորդ և ավելացնում է վարչական բեռը MCP-ի համար՝ ծանուցում ուղարկելու այն համայնքային աջակցություն մատուցողին/ուղղորդող կազմակերպությանը, որն արդեն տեղյակ է ուղղորդման ցիկլի փակման մասին, քանի որ նրանք նույն կազմակերպությունն են, որը MCP-ին տեղեկացրել է ուղղորդման կարգավիճակի մասին RTF ներկայացման միջոցով։​​  

Այո, ուղղորդման ցիկլի փակման դեպքում 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-ի համար թույլտվության հարցում։ Էլեկտրոնային գնման քաղաքականության ուղեցույցում DHCS-ը նշում է, որ Էլեկտրոնային գնման վերաբերյալ դիմումները գործարկում են 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 լիազորման և կոդավորման վերաբերյալ մի քանի լրացուցիչ, համապատասխան ռեսուրսներ՝​​ 

  • Էլեկտրոնային կառավարման լիազորագրերը պետք է ունենան 12 ամիս սկզբնական լիազորման ժամկետ՝​​ 
  • (Թարմացվել է 2023 թվականի հուլիս) Ստանդարտ ECM լիազորման ժամկետներ. Բոլոր անդամների համար, որոնք լիազորված են իրենց MCP-ի կողմից ECM ստանալու, սկզբնական լիազորման ժամկետը կլինի 12 ամիս, իսկ վերալիազորման ժամկետը՝ 6 ամիս: MCP-ները չեն կարող ECM ծառայությունների թույլտվության համար լրացուցիչ պահանջներ սահմանել՝ DHCS-ի կողմից սահմանված «Կիզակետային բնակչության» իրավասության չափանիշներից դուրս: Օրինակ, բազմակողմանի խնամքի ծրագրերը (MCP) չեն կարող կասեցնել թույլտվությունը մինչև խնամքի ծրագրի ավարտը: (Էջ 108, ECM PG)​​ 
  • ECM HCPCS ուղեցույց – Ստանդարտացված կոդեր պահանջների և հանդիպումների համար​​ 

JSON հաշվետվություն​​ 

Կարո՞ղ է DHCS-ը վերանայել CLR տարրերի վերաբերյալ ցանկացած JSON հաշվետվություն ներկայացնելու խնդրանքը մինչև առնվազն 1 թվականի հունվարը, 2026 ։ Խելամիտ կլինի CLR JSON հաշվետվությունների ներկայացումը տեղափոխել առնվազն մինչև 1 հունվար, 2026, որպեսզի գործընթացների իրականացումը և տվյալների փոխանակումը լիարժեքորեն իրականացվեն։​​ 

4-րդ փուլի CLR JSON ձևանմուշները, որոնք ներառում են մոնիթորինգի տվյալների CLR տվյալների տարրեր, MCP-ներին թողարկվել են 2025 թվականի փետրվարին՝ համապատասխան փորձարկման ժամանակացույցով, իսկ 4-րդ փուլի վերջնական JSON ուղեցույցը թողարկվել է մարտի 28, 2025: Էլեկտրոնային կառավարման համակարգի (ECM) և համայնքային աջակցության տեղեկատվության փոխանակման գործիքների (MIF, RTF և ASF) թարմացման բոլոր ուղեցույցները թողարկվել են 2024 թվականի դեկտեմբերին՝ փաստաթղթերում նշված CLR-ին աջակցելու հատուկ թարմացումներով։​​  

DHCS-ը խստորեն խրախուսում է MCP-ներին շարունակել անդամների տեղեկատվության փոխանակման ուղեցույցի թարմացումը՝ համապատասխանեցնելով այն 2024 թվականի դեկտեմբերին հրապարակված պահանջներին, և տեխնիկական օգնություն և աջակցություն տրամադրել ECM-ին և համայնքային աջակցության մատակարարներին՝ հուլիսի 1, 2025 անդամների տեղեկատվության փոխանակման նոր ուղեցույցի գործարկման համար։​​