दावा अस्वीकृति के मूल कारण का प्रशिक्षण: प्रशासनिक कर्मचारियों को डेटा को दोबारा दर्ज करने से हटाकर, दावा अस्वीकृति के कारणों का पता लगाने की ओर कैसे ले जाया जाए

अस्पताल की बिलिंग टीम अस्वीकृत दावों की एक लंबी कतार पर काम करती है। हर दावे को ठीक करने का तरीका एक जैसा है: कोई व्यक्ति एक फ़ील्ड को सही करता है, डेटा को दोबारा दर्ज करता है और फिर से सबमिट कर देता है। एक हफ्ते बाद, उसी पैटर्न वाले दावे फिर से आ जाते हैं। किसी ने यह नहीं पूछा कि उन्हें पहली बार में क्यों अस्वीकार किया गया था, इसलिए सुधार कभी उस चरण तक नहीं पहुँचता जिससे गलती हुई थी।

यह एक उदाहरण मात्र है, कोई प्रमाणित मामला नहीं। यह उस अंतर को दर्शाता है जिसे दावा अस्वीकृति के मूल कारण का पता लगाने वाले प्रशिक्षण का उद्देश्य दूर करना है: अस्वीकृत दावे को ठीक करने और यह पता लगाने के बीच का अंतर कि कार्यप्रवाह के किस भाग के कारण यह अस्वीकृति हुई।

यह मार्गदर्शिका अस्पताल के प्रशिक्षण एवं विकास (L&D) निदेशकों और उनके साथ काम करने वाले सूचना विज्ञान या अनुपालन प्रमुखों के लिए है। इसमें प्रदर्शन संबंधी समस्या का वर्णन करना, सीखने और संदर्भ संबंधी कमियों का निदान करना, तैयारी और अभ्यास की योजना बनाना, किसी मामले पर काम करना और यह आकलन करना शामिल है कि क्या कौशल कार्य में लागू होता है। यह प्रशिक्षण डिज़ाइन के बारे में है। केवल पहचान रहित मामलों का उपयोग करें, और किसी को भी प्रशिक्षण देने से पहले अपने राजस्व चक्र, सूचना विज्ञान और अनुपालन प्रमुखों से प्रत्येक मामले, कोड और उत्तर का सत्यापन करवाएं।

दावा अस्वीकृति के मूल कारण का प्रशिक्षण क्या है?

दावा अस्वीकृति के मूल कारण का पता लगाने के प्रशिक्षण में प्रशासनिक कर्मचारियों को बार-बार होने वाली अस्वीकृतियों की जांच करने और उनके पीछे की कार्यप्रणाली संबंधी समस्याओं की पहचान करने का प्रशिक्षण दिया जाता है। यह कार्य विश्लेषणात्मक है। कर्मचारी दावे और रिकॉर्ड में मौजूद साक्ष्यों का अध्ययन करते हैं, भुगतानकर्ता द्वारा कही गई बातों को संगठन के भीतर हुई गड़बड़ी से अलग करते हैं, और एक ऐसा विशिष्ट कारण बताते हैं जिस पर कार्रवाई की जा सके।

त्वरित तथ्य

1. प्रदर्शन संबंधी समस्या का वर्णन करें।

कार्य से शुरुआत करें: बार-बार होने वाली अस्वीकृतियों की जांच करें और कार्यप्रवाह संबंधी कारणों की पहचान करें। दो शब्द महत्वपूर्ण हैं। बार-बार होने का अर्थ है कि कार्य की इकाई एक पैटर्न है, न कि एक एकल दावा। कार्यप्रवाह संबंधी कारण का अर्थ है कि समाधान संगठन की अपनी प्रक्रिया में निहित है, न कि भुगतानकर्ता के भुगतान में।

स्वास्थ्य सेवा वित्त संबंधी दिशानिर्देश भी यही बात कहते हैं। हेल्थकेयर फाइनेंशियल मैनेजमेंट एसोसिएशन (HFMA) के एक लेख में, डेनिस विल्सन और ट्रेसी टोमाक ने अस्वीकृति के तीन स्तरों का वर्णन किया है। कारण भुगतानकर्ता द्वारा बताया गया कोड है, जैसे कि दावा समायोजन कारण कोड (CARC)। समस्या व्यापक श्रेणी है, जैसे कि कोडिंग या दस्तावेज़ीकरण। मूल कारण वह आंतरिक विफलता है जिसके कारण भुगतान में अंतर आया। वे बताते हैं कि मूल कारणों की पहचान के लिए चिकित्सा रिकॉर्ड, शुल्क और बिल किए गए दावे की आंतरिक समीक्षा आवश्यक है, और डेटा में केवल भुगतान पर दिए गए कारण कोड के बजाय वास्तविक मूल कारणों को प्रतिबिंबित करना चाहिए।विल्सन और टोमाक, एचएफएवे यह भी कहते हैं कि मूल कारण को इस प्रकार लिखा जाना चाहिए ताकि पाठक किसी विशिष्ट कारण पर कार्रवाई कर सके।

यही अंतर प्रशिक्षण का लक्ष्य है। पुनः कुंजी निर्धारण तर्क स्तर पर कार्य करता है। मूल कारण विश्लेषण तीसरे स्तर पर कार्य करता है।

प्रदर्शन विवरण को एक वाक्य में लिखें और राजस्व चक्र प्रमुख से इसकी जाँच करवाएँ: "संबंधित अस्वीकरणों के एक समूह को देखते हुए, कर्मचारी दावे और रिकॉर्ड की समीक्षा करता है, भुगतानकर्ता के कारण को आंतरिक कारण से अलग करता है, एक विशिष्ट कारण बताता है और सुधार का प्रस्ताव देता है और यह बताता है कि इसके लिए कौन जिम्मेदार है।"

2. सीखने और संदर्भ संबंधी कमियों का निदान करें

कुछ भी बनाने से पहले, उस कार्य की तुलना अपने वर्तमान कार्यक्रम में अपनाई जाने वाली प्रथाओं और मूल्यांकनों से करें। आमतौर पर तीन प्रश्न प्रशिक्षण की कमी को अन्य कमियों से अलग करते हैं:

1. क्या वर्तमान कार्यप्रणाली में वास्तविक कार्य का उपयोग किया जाता है? यदि प्रशिक्षण में कर्मचारियों को कारण कोड पढ़ना और मानक सुधार लागू करना सिखाया जाता है, तो उन्होंने पुनः दर्ज करने का अभ्यास किया है। यदि मूल्यांकन कोड परिभाषाओं पर आधारित प्रश्नोत्तरी है, तो यह स्मृति का मापन करता है, न कि जांच का।
2. संज्ञानात्मक आवश्यकता क्या है? ब्लूम के संशोधित वर्गीकरण में, खंडनों की तुलना करके एक पैटर्न खोजना और यह तय करना कि कौन सा कारण साक्ष्य के लिए सबसे उपयुक्त है, विश्लेषण और मूल्यांकन स्तरों पर आते हैं। कोड खोजना निचले स्तर पर आता है। इन स्तरों के साथ गतिविधियों का मिलान हमारी मार्गदर्शिका में शामिल है। ब्लूम के वर्गीकरण के अनुसार सीखने की गतिविधियों का मिलान करना.
3. क्या कौशल के अलावा कोई और चीज बाधा बन रही है? पहुँच, उपकरण और स्वामित्व की जाँच करें। जो कर्मचारी पंजीकरण स्क्रीन नहीं देख सकते, जिनके पास त्रुटि के बारे में फ्रंट डेस्क को सूचित करने का कोई तरीका नहीं है, या जिनकी गणना प्रति घंटे निपटाए गए दावों के आधार पर की जाती है, वे प्रशिक्षण में बताई गई बातों को गलत तरीके से दर्ज करेंगे। प्रशिक्षण से इतर कारणों की रिपोर्ट उन लोगों को दें जो उन्हें ठीक कर सकते हैं।

3. डिजाइन की तैयारी और अभ्यास

एक बार जब आपको पता चल जाए कि प्रशिक्षण से किन कमियों को दूर किया जा सकता है, तो प्रत्येक चरण को एक अलग कार्य सौंप दें।

तैयार करना। संक्षिप्त निदान के साथ पूर्वापेक्षाओं की जाँच करें: अस्वीकृति शब्दावली, पंजीकरण से भुगतान तक दावा जीवनचक्र, और कारण कोड फ़ील्ड का अर्थ। इस चरण में स्व-गति से अध्ययन करना उपयुक्त है। स्मरण जाँच केवल पूर्वापेक्षाओं की पुष्टि करती है।

अभ्यास करें. पहचान छिपाए गए मामलों पर डेटा अखंडता विश्लेषण करें। विश्लेषण में, कर्मचारी अस्वीकृत दावे को लेते हैं, रिकॉर्ड, शुल्क और पंजीकरण के माध्यम से उसकी पूरी जानकारी खंगालते हैं और यह लिखते हैं कि गलती कहाँ दर्ज की गई थी। कई कर्मचारियों को एक ही मामला एक से अधिक तरीकों से मिल सकता है, इसलिए चर्चा ही सीखने का मुख्य स्रोत है। केवल लेबल लगाने के बजाय, कारण पूछें।

प्रतिक्रिया। इसे कुल स्कोर के बजाय निर्णयों से जोड़ें। "आपने गुम हुई अनुमति की पहचान कर ली है, जो एक वास्तविक कारण है, लेकिन आपने यह जांच नहीं की कि यह गुम थी या गलत विज़िट के विरुद्ध दर्ज की गई थी" यह कथन "10 में से 7" से कहीं अधिक उपयोगी है।

लाइव इनपुट या अतुल्यकालिक समीक्षा? लाइव कोचिंग तब सबसे अधिक उपयोगी होती है जब मामला अस्पष्ट हो और कर्मचारियों को किसी अनुभवी सहकर्मी से भुगतानकर्ता की नीति और डेटा प्रविष्टि की त्रुटि के बीच अंतर समझने की आवश्यकता हो। लिखित कारण विवरण की तुलना टिप्पणीयुक्त मॉडल उत्तर से करने के लिए अतुल्यकालिक समीक्षा पर्याप्त है। कई टीमें दोनों तरीकों का उपयोग करती हैं: पहले स्व-गति से तैयारी, फिर सबसे कठिन मामलों पर एक निर्देशित सत्र।

4. एक वास्तविक उदाहरण के माध्यम से काम करें

यह केवल उदाहरण के लिए है और इसमें पहचान छिपाई गई है। राजस्व चक्र या सूचना प्रौद्योगिकी विशेषज्ञ को उपयोग से पहले मामले और उत्तर के मानदंडों को सत्यापित करना चाहिए।

मामला। एक महीने के भीतर, एक ही सेवा के लिए ग्यारह बाह्य रोगी दावों को एक ही भुगतानकर्ता कारण से अस्वीकार कर दिया गया। प्रत्येक दावे को संशोधित करके उसी फ़ील्ड को दोबारा भरकर पुनः प्रस्तुत किया गया। ग्यारह में से तीन दावे फिर से अस्वीकार कर दिए गए।

कार्य। कर्मचारी दावों और रिकॉर्ड की समीक्षा करता है, भुगतानकर्ता द्वारा बताए गए कारण को आंतरिक कारण से अलग करता है, एक विशिष्ट कारण बताता है, और यह बताता है कि उन्हें आगे किस प्रकार की जानकारी या सहायता की आवश्यकता है।

पहला प्रयास। "भुगतानकर्ता ने कहा कि जानकारी गलत थी। मैंने फ़ील्ड को ठीक किया और दोबारा सबमिट किया।" यह कारण को दोहराता है और सामान्य समाधान लागू करता है। यह किसी पैटर्न या कारण की तलाश नहीं करता।

प्रतिक्रिया दें और पुनः प्रयास करें। कोच ने मामले में दो तथ्यों की ओर इशारा किया: सभी ग्यारह दावों में एक ही सेवा और पंजीकरण स्थान साझा किया गया है, और जो तीन दावे वापस आए हैं, उन्हें अलग-अलग कर्मचारियों द्वारा ठीक किया गया था। पुनः प्रयास में व्यक्ति से यह देखने के लिए कहा गया है कि फ़ील्ड को पहली बार कहाँ दर्ज किया गया था और क्या उसी प्रक्रिया से सभी ग्यारह दावे प्राप्त हुए थे।

एक और मजबूत प्रयास। "सभी ग्यारह दावे एक ही स्थान पर पंजीकृत किए गए थे, इसलिए मुझे लगता है कि त्रुटि पंजीकरण के समय हुई है, बिलिंग के समय नहीं। मैं उन दावों के पंजीकरण संबंधी दस्तावेज़ निकालूंगा और जांच करूंगा कि क्या फ़ील्ड डिफ़ॉल्ट मान से भरा जा रहा है। यदि ऐसा है, तो बिलिंग के समय पुनः दर्ज करने पर भी त्रुटि आती रहेगी। जब तक मैं यह सुनिश्चित नहीं कर लेता कि भुगतानकर्ता का नियम नहीं बदला है, तब तक मैं इसे भुगतानकर्ता की नीति का मुद्दा नहीं मानूंगा। मैं यह जानकारी पंजीकरण प्रमुख के साथ साझा करूंगा और उनसे पूछूंगा कि इस फ़ील्ड का स्वामित्व किसके पास है।" इस उत्तर में एक पैटर्न, कारण का विशिष्ट स्थान, इसकी पुष्टि या खंडन करने वाली जांच और कार्रवाई करने वाले व्यक्ति का उल्लेख किया गया है।

प्रत्येक प्रतिक्रिया तर्कसंगत है या अपूर्ण है? प्रत्येक मूल्यांकन को स्वीकृत मानदंडों के आधार पर करें, न कि कोच की पसंद के आधार पर। पहला प्रयास एक सामान्य आदत है, लेकिन यह तर्क के स्तर तक ही सीमित रहता है। बेहतर प्रयास भुगतानकर्ता की नीति को डेटा प्रविष्टि से अलग करता है और व्यक्ति की भूमिका के दायरे में ही रहता है।

5. क्षमता का आकलन करें और स्थानांतरण की योजना बनाएं

क्षमता का प्रमाण उस अस्वीकृति पैटर्न के प्रति प्रतिक्रिया है जिसे शिक्षार्थी ने पहले नहीं देखा है। सही कारण की पहचान और समय के साथ उनके द्वारा जांचे गए पैटर्न की पुनरावृत्ति दर को अंक दें। एक सरल मानदंड के लिए 0 से 2 तक के पैमाने का उपयोग किया जाता है:

एंकर: 0 अनुपस्थित या असमर्थित है, 1 प्रासंगिक कमियों के साथ आंशिक है, और 2 पूर्ण है और सहमत मानदंडों के अनुसार उचित है। गंभीर त्रुटियों को अलग से परिभाषित करें, जैसे कि अनुमोदित प्रणालियों के बाहर पहचान योग्य रोगी जानकारी को संभालना, ताकि समग्र स्कोर किसी एक त्रुटि को छिपा न सके। यह रूब्रिक एक प्रस्ताव है, मान्य तत्परता मानक नहीं: इसे सूचना विज्ञान या अनुपालन प्रमुख के साथ अनुकूलित करें और इसका पायलट परीक्षण करें। हमारी मार्गदर्शिका उपयोगी प्रतिक्रिया के साथ इंटरैक्टिव अभ्यास डिजाइन करना यह दर्शाता है कि निर्णयों से संबंधित प्रतिक्रिया कैसे लिखी जाए।

स्थानांतरण की योजना सोच-समझकर बनाएं। कर्मचारियों द्वारा कुछ समय तक अपने काम पर लगे रहने के बाद एक अनुवर्ती समीक्षा जोड़ें, जैसे कि मासिक समीक्षा जिसमें प्रत्येक व्यक्ति अपने द्वारा जांचे गए एक अस्वीकृति पैटर्न और समाधान के बाद क्या हुआ, उसे प्रस्तुत करे।

जहां इंटरैक्टिव डिलीवरी मददगार होती है

इंटरैक्टिव फॉर्मेट तब मददगार होते हैं जब सभी को जवाब सुनने से पहले अपनी राय देनी होती है। लाइव सेशन में, फैसिलिटेटर एक डीआइडेंटिफाइड डिनायल समरी दिखा सकता है, प्रत्येक व्यक्ति से संभावित कारण और उनके द्वारा जांचे जाने वाले पहले रिकॉर्ड को टाइप करने के लिए कह सकता है, और फिर चर्चा से पहले स्प्रेड दिखा सकता है। तैयारी के लिए इसी केस को सेल्फ-पेस्ड तरीके से भी चलाया जा सकता है। AhaSlides इंटरैक्टिव लर्निंग और लाइव और सेल्फ-पेस्ड डिलीवरी के बीच स्विच करने की सुविधा देता है। इसमें किसी भी वास्तविक रोगी डेटा को शामिल न करें, किसी भी विशिष्ट ऑथरिंग, फीडबैक या रिपोर्टिंग फंक्शन की अपने वर्कफ़्लो के साथ तुलना करके जांच करें, और AI, सिमुलेटर और सिस्टम इंटीग्रेशन को तब तक बाहरी या अपुष्ट मानें जब तक आप उन्हें काम करते हुए न देख लें। फॉर्मेट चुनने के मार्गदर्शन के लिए, हमारा लेख देखें। अनुकूली, इंटरैक्टिव और लाइव लर्निंग का उपयोग कब करें.

जो परिवर्तन हुआ उसे मापें

पहले से तय करें कि किन बातों से पता चलेगा कि कर्मचारी कार्य को पूरा कर सकते हैं। किसी अनदेखे अस्वीकृति पैटर्न पर सही कारण की पहचान की तुलना आधारभूत स्तर से करें और जांच किए गए पैटर्न की पुनरावृत्ति दर पर नज़र रखें। यह निर्धारित करें कि इसमें कौन-कौन शामिल हैं, हर का मान क्या है और समय क्या है। यदि परिणाम बेहतर होते हैं, तो प्रशिक्षण का श्रेय देने से पहले यह जांच लें कि उसी अवधि में और क्या-क्या परिवर्तन हुए हैं, जैसे कि भुगतानकर्ता की नीति में अपडेट, नई पंजीकरण स्क्रीन या दावों की संख्या में परिवर्तन।

वे बाधाएं जो बनी रह सकती हैं

• भुगतानकर्ता नीति। कुछ अस्वीकृतियाँ भुगतानकर्ता के नियमों में बदलाव के कारण होती हैं। अच्छी जाँच से इसका पता चल जाता है, लेकिन प्रशिक्षण से इसमें कोई बदलाव नहीं आता।
• सिस्टम की सीमाएँ। यदि सिस्टम यह नहीं दिखा सकता कि किसी फ़ील्ड में डेटा कहाँ दर्ज किया गया था, तो कर्मचारियों के पास पता लगाने के लिए बहुत कम जानकारी होती है।
• स्वामित्व। पंजीकरण के दौरान पाई गई किसी समस्या के समाधान की जिम्मेदारी पंजीकरण विभाग के किसी व्यक्ति को लेनी होगी।
• मामले का विवरण। अस्वीकृति का एक पैटर्न केवल एक ही प्रकार को दर्शाता है। स्कोर किसी व्यक्ति के समग्र निर्णय को नहीं दर्शाता है।
• स्थानांतरण। किसी प्रशिक्षण मामले पर प्रदर्शन, पूरी कतार के साथ प्रदर्शन के समान नहीं होता है।

प्रायोजकों को इनके बारे में पहले ही बता दें और अलग-अलग समाधानों की योजना बनाएं। प्रशिक्षण से कर्मचारियों की जांच क्षमता में सुधार होता है। इससे कतार से जुड़ी स्थितियों में कोई बदलाव नहीं आता।

ज़्यादातर पूछे जाने वाले सवाल

दावा अस्वीकृति के मूल कारण का प्रशिक्षण क्या है?

यह प्रशासनिक कर्मचारियों को बार-बार होने वाली दावा अस्वीकृतियों की जांच करने और प्रत्येक दावे को ठीक करके दोबारा जमा करने के बजाय, उन्हें उस कार्यप्रवाह चरण तक पहुंचाने का प्रशिक्षण देता है जिसके कारण वे अस्वीकृत हुए थे।

मूल कारण और अस्वीकृति कारण में क्या अंतर है?

इसका कारण भुगतानकर्ता द्वारा बताया गया कोड है। मूल कारण इसके पीछे की आंतरिक विफलता है। अस्वीकृति का कारण कोड समान हो सकता है, लेकिन इसके कई अलग-अलग मूल कारण हो सकते हैं।

आप यह आकलन कैसे करते हैं कि कर्मचारी मूल कारणों का पता लगा सकते हैं या नहीं?

एक ऐसा अस्वीकरण पैटर्न दें जो शिक्षार्थी ने पहले कभी नहीं देखा हो, और उनके द्वारा बताए गए कारण और उसके पीछे के साक्ष्य को सहमत मानदंडों के आधार पर अंक दें। कोड क्विज़ केवल पूर्वापेक्षाओं की पुष्टि करता है।

क्या आप प्रशिक्षण में वास्तविक दावों का उपयोग कर सकते हैं?

केवल पहचान छिपाए गए मामलों का ही उपयोग करें, और किसी भी प्रशिक्षण उपकरण में रोगी की जानकारी तब तक शामिल न करें जब तक कि आपके अनुपालन प्रमुख ने इसकी अनुमति न दे दी हो।

कहा से शुरुवात करे

किसी एक बार-बार होने वाली अस्वीकृति के पैटर्न को चुनें। प्रदर्शन विवरण लिखें, राजस्व चक्र या सूचना प्रौद्योगिकी प्रमुख से पहचान छिपाए गए मामले, जाँचों और समाधान के लिए जिम्मेदार व्यक्ति का सत्यापन करवाएँ, और 0 से 2 के पैमाने पर तीन मानदंडों वाला एक रूब्रिक और गंभीर त्रुटियों की सूची तैयार करें। इसे लागू करने से पहले एक छोटे समूह के साथ इसका परीक्षण करें।

यह देखने के लिए कि अस्वीकृति का मामला आपकी अपनी टीम के साथ लाइव कैसे चलाया जा सकता है, और बाद में स्व-गति से इसका पुन: उपयोग कैसे किया जा सकता है, AhaSlides का अन्वेषण करें।