लैब सैंपल कस्टडी: हर हैंडऑफ़ को ट्रैक करें

कलेक्शन से परिणाम तक सैंपल रिकॉर्ड में कमी क्यों आ जाती है

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

कागज़ी नोट, इनबॉक्स संदेश और मौखिक अपडेट अक्सर इस पूरी जानकारी को कई जगह बाँट देते हैं। कोई फील्ड वर्कर फ़ॉर्म पर कलेक्शन का समय लिख सकता है, कूरियर अलग लॉग पर हस्ताक्षर कर सकता है और लैब सैंपल मिलने के बाद ही उसे दर्ज कर सकती है। शिकायत, ऑडिट या अप्रत्याशित परिणाम आने पर स्टाफ को बाद में पूरी जानकारी फिर से तैयार करनी पड़ती है।

लैब सैंपल कस्टडी हर ट्रांसफ़र को एक इवेंट के रूप में दर्ज करती है। इससे कलेक्शन से परिणाम जारी होने तक का लगातार इतिहास बनता है।

स्टेटस हैंडऑफ़ का प्रमाण नहीं होता

सैंपल स्टेटस छोटा-सा लेबल होता है, जैसे «कलेक्ट किया गया», «ट्रांज़िट में», «प्राप्त», «टेस्टिंग में» या «रिपोर्ट किया गया»। इससे स्टाफ को पता चलता है कि काम किस चरण में है, लेकिन यह नहीं पता चलता कि स्टेटस किसने बदला, क्यों बदला या सैंपल ने ज़रूरी शर्तें पूरी की थीं या नहीं।

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

समीक्षा के दौरान यह अंतर महत्वपूर्ण होता है। «प्राप्त» का मतलब है कि सैंपल लैब के पास है। हैंडऑफ़ इवेंट बताता है कि Jordan Lee ने 4 जून को 10:18 बजे सैंपल W-104 स्वीकार किया, सील की जाँच की और उसे रेफ्रिजरेटेड स्टोरेज में रखा।

ऐसे रिकॉर्ड जो पूरी जानकारी को जोड़े रखें

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

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

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

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

हर सैंपल के लिए ज़रूरी जानकारी तय करें

लैब सैंपल कस्टडी एक सरल नियम से शुरू होती है: सैंपल आपकी ज़िम्मेदारी में आते ही उसका रिकॉर्ड बनाएँ। यूनिक सैंपल ID कलेक्शन के समय दें, सैंपल के लैब पहुँचने पर नहीं। छोटी टीम के लिए हाथ से लिखा लेबल काम कर सकता है, लेकिन उसे डिजिटल रिकॉर्ड से बिल्कुल मेल खाना चाहिए। डुप्लिकेट ID ऐसी उलझन पैदा करते हैं जिसे बाद का कोई नोट पूरी तरह दूर नहीं कर सकता।

ऐसा ID फ़ॉर्मैट रखें जिसे स्टाफ जल्दी पढ़ सके, जैसे कलेक्शन की तारीख और छोटा क्रमांक। ID में व्यक्तिगत नाम और संवेदनशील केस विवरण न रखें। इन विवरणों को सैंपल रिकॉर्ड के सुरक्षित फ़ील्ड में रखें।

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

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

कंटेनर और सील के लिए अलग-अलग फ़ील्ड रखें। कंटेनर का प्रकार, मात्रा या वॉल्यूम, उपलब्ध होने पर सील नंबर और कलेक्शन के समय सील सही थी या नहीं, यह दर्ज करें। उदाहरण के लिए, पानी के सैंपल के लिए 500 mL की स्टेराइल बोतल, सही टैम्पर सील और 2-8 C पर स्टोरेज ज़रूरी हो सकता है। अगर कलेक्टर अलग कंटेनर इस्तेमाल करे या टूटी सील पाए, तो रिकॉर्ड में यह तुरंत दिखना चाहिए।

स्टोरेज निर्देश भी स्पष्ट होने चाहिए। «ठंडा रखें» में गलती की गुंजाइश रहती है। «2-8 C पर रखें, रोशनी से बचाएँ और 24 घंटे के भीतर पहुँचाएँ» कूरियर और लैब रिसीवर को साफ़ निर्देश देता है।

AppMaster में बना नो-कोड ऐप स्टाफ को कलेक्शन रिकॉर्ड सेव करने से पहले ये फ़ील्ड भरने के लिए कह सकता है। सैंपल के प्रकार के अनुसार अलग स्थिति और स्टोरेज फ़ील्ड भी दिखाए जा सकते हैं, ताकि फील्ड कलेक्टर को गैर-ज़रूरी सवालों से न गुजरना पड़े।

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

वर्कफ़्लो बनाने से पहले सैंपल की पूरी यात्रा समझें

कस्टडी फ़ॉर्म तब सबसे अच्छा काम करता है जब वह सैंपल के वास्तविक रास्ते के अनुसार बना हो। सैंपल कलेक्ट करने, प्राप्त करने, टेस्ट करने, समीक्षा करने और रिपोर्ट करने वाले लोगों से बात करें। फ़ील्ड, स्क्रीन या नियम बनाने से पहले हर पड़ाव को सरल भाषा में लिखें।

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

स्टेटस बताता है कि सैंपल प्रक्रिया में कहाँ है। कस्टडी रिकॉर्ड बताता है कि किसी खास समय पर ज़िम्मेदारी किसने स्वीकार की। इन दोनों को अलग फ़ील्ड रखें।

कस्टडी रिकॉर्ड की ज़रूरत वाले क्षण दर्ज करें

जब ज़िम्मेदारी किसी दूसरे व्यक्ति को मिले या सैंपल ऐसी जगह जाए जहाँ उसका नियंत्रण बदलता हो, तब नया कस्टडी रिकॉर्ड बनाएँ। कूलर में वायल रखने वाला फील्ड तकनीशियन कलेक्शन दर्ज करे। कूलर स्वीकार करने वाला कूरियर रिसीट दर्ज करे। विश्लेषण के लिए वायल निकालने वाला लैब तकनीशियन अगला हैंडऑफ़ दर्ज करे।

एक व्यावहारिक नियम अपनाएँ: अगर कोई पूछ सकता है, «10:30 बजे सैंपल किसके पास था?», तो वर्कफ़्लो में उस सवाल का जवाब देने वाला इवेंट होना चाहिए। हर इवेंट में सैंपल ID, तारीख और समय, ज़िम्मेदार व्यक्ति, स्थान या ट्रांसफ़र पॉइंट और स्थिति जाँच दर्ज करें।

स्थिति जाँच के लिए संरचित फ़ील्ड रखें। स्टाफ सील सही, कंटेनर क्षतिग्रस्त, तापमान स्वीकार्य या तापमान सीमा से बाहर जैसे विकल्प चुन सके। टिप्पणी अपवाद समझा सकती है, लेकिन उसे जाँच का विकल्प न बनाएँ।

सुधारों के बाद भी रिकॉर्ड को पढ़ने योग्य रखें

लैब के काम में नोट और सुधार सामान्य हैं। तकनीशियन «लेबल थोड़ा गीला है» लिख सकता है या स्थान के नाम में टाइपो सुधार सकता है। इनमें से किसी भी कार्रवाई से मूल कस्टडी इवेंट चुपचाप नहीं बदलना चाहिए।

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

AppMaster में टीमें सैंपल, कस्टडी इवेंट, स्थिति जाँच और सुधार को अलग-अलग रिकॉर्ड के रूप में मॉडल कर सकती हैं। विज़ुअल बिज़नेस प्रोसेस स्टेटस आगे बढ़ने से पहले पूरा हैंडऑफ़ अनिवार्य कर सकते हैं। इससे केवल नवीनतम अपडेट के बजाय सैंपल का पूरा रास्ता दिखाई देता है।

वर्कफ़्लो को चरण-दर-चरण बनाएँ

लैब सैंपल कस्टडी को एक स्थायी सैंपल ID के आसपास बनाएँ। इसे कलेक्शन के समय दें और लेबल, कलेक्शन रिकॉर्ड, हैंडऑफ़ लॉग, टेस्ट रिकॉर्ड और अंतिम परिणाम में इस्तेमाल करें। बारकोड या QR कोड टाइपिंग की गलतियाँ कम करता है, लेकिन इवेंट सेव करने से पहले स्टाफ को स्क्रीन पर ID फिर भी दिखाई देनी चाहिए।

कलेक्शन फ़ॉर्म से शुरुआत करें। सैंपल कहाँ से आया और उसे किसने कलेक्ट किया, यह तय करने वाले फ़ील्ड अनिवार्य करें: कलेक्शन की तारीख और समय, कलेक्टर का नाम, स्थान या स्रोत, सैंपल प्रकार, कंटेनर ID और कलेक्शन के समय की स्थिति। क्षतिग्रस्त सील या सामान्य सीमा से बाहर तापमान जैसी बातों के लिए नोट जोड़ें।

हर ट्रांसफ़र को अलग रिकॉर्ड बनाएँ

सैंपल के हाथ बदलने पर कलेक्टर का विवरण ओवरराइट न करें। हर बार ट्रांसफ़र या रिसीव होने पर हैंडऑफ़ रिकॉर्ड बनाएँ। हर रिकॉर्ड में दोनों लोगों के नाम, तारीख और समय, ट्रांसफ़र स्थान और सैंपल ID दिखाई देनी चाहिए।

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

व्यावहारिक हैंडऑफ़ रिकॉर्ड में सैंपल ID और वर्तमान स्टेटस, सैंपल रिलीज़ करने वाला व्यक्ति, स्वीकार करने वाला व्यक्ति, ट्रांसफ़र की तारीख, समय और स्थान, स्थिति जाँच तथा नोट शामिल होते हैं। सहायक फ़ोटो तभी जोड़ें जब आपकी लैब इसका इस्तेमाल करती हो।

हर इवेंट को अलग स्प्रेडशीट या ईमेल थ्रेड में रखने के बजाय उसी सैंपल ID के अंतर्गत सेव करें। तब स्टाफ समय के क्रम में पूरी हिस्ट्री देख सकेगा और ऑडिट के सवाल का जवाब दे सकेगा: हर चरण में यह सैंपल किसके पास था?

जारी किए गए परिणाम के साथ रिकॉर्ड पूरा करें

टेस्टिंग समाप्त होने पर विश्लेषक परिणाम, विधि, पूरा होने का समय और परिणाम संबंधी नोट दर्ज करे। इसके बाद समीक्षक या अधिकृत स्टाफ सदस्य परिणाम जारी करके अपना नाम और रिलीज़ का समय दर्ज करे। परिणाम जारी करना टेस्ट एंट्री से अलग रखें, ताकि रिकॉर्ड में यह स्पष्ट रहे कि परिणाम किसने बनाया और किसने उसे मंज़ूर किया।

AppMaster टीमों को बिना कोड के ये फ़ॉर्म और स्टेटस नियम बनाने देता है। बिज़नेस प्रोसेस ज़रूरी फ़ील्ड खाली होने पर हैंडऑफ़ या परिणाम जारी होने से रोक सकता है। उदाहरण के लिए, रिसीवर सील की स्थिति दर्ज न करे तो ऐप स्वीकृति रोक सकता है। इससे अंतिम रिपोर्ट तक पहुँचने से पहले कस्टडी की एक आम कमी दूर हो जाती है।

हर हैंडऑफ़ को जाँचना आसान बनाएँ

कस्टडी रिकॉर्ड तभी उपयोगी होता है जब समीक्षक ईमेल या कागज़ी फ़ॉर्म खोजे बिना पाँच सवालों के जवाब दे सके: सैंपल किसने भेजा, किसने प्राप्त किया, ट्रांसफ़र कब हुआ, कहाँ हुआ और सैंपल क्यों ले जाया गया। ये फ़ील्ड हर हैंडऑफ़ फ़ॉर्म में रखें और ट्रांसफ़र की पुष्टि से पहले इन्हें भरना अनिवार्य करें।

जहाँ संभव हो, फ्री टेक्स्ट के बजाय स्टाफ अकाउंट से नाम लें। इससे एक रिकॉर्ड में «J. Smith» और दूसरे में «John» जैसी अलग एंट्री नहीं होंगी। स्थानों के लिए कलेक्शन साइट, रिसीविंग बेंच, कोल्ड स्टोरेज या टेस्टिंग एरिया जैसी छोटी स्वीकृत सूची दें।

ट्रांसफ़र का कारण अस्पष्ट हिस्ट्री से बचाता है। स्टाफ «नियमित डिलीवरी», «स्टोरेज में ले जाया गया», «टेस्टिंग के लिए असाइन किया गया» या «दोबारा विश्लेषण के लिए भेजा गया» जैसे विकल्प चुन सकता है। लंबी सामान्य सूची देने के बजाय विकल्पों को लैब के वास्तविक काम से मिलाएँ।

ट्रांसफ़र के समय स्थिति जाँचें

रिसीवर को ज़िम्मेदारी स्वीकार करने से पहले सैंपल की स्थिति दर्ज करनी चाहिए। सरल चेकलिस्ट से अलग-अलग शिफ्ट में समीक्षा एक जैसी रहती है। इसमें सील की स्थिति, तापमान सीमा, कंटेनर की क्षति, सैंपल की मात्रा और लेबल की पठनीयता शामिल करें।

अगर किसी को समस्या मिले, तो नोट अनिवार्य करें। «क्षतिग्रस्त» से यह पता नहीं चलता कि कंटेनर लीक हुआ, टूट गया या ढक्कन के बिना आया। उपयोगी नोट में स्टाफ ने क्या देखा, क्या किया और किसे बताया, यह लिखा होता है। उदाहरण: «आने पर सील का एक हिस्सा उठा हुआ था। कंटेनर से रिसाव नहीं हुआ। रिसीवर ने इसे 4 C स्टोरेज में रखा और लैब सुपरवाइज़र को सूचित किया।»

जहाँ लैब नीति अनुमति दे, वहाँ फ़ोटो मददगार हो सकती है, खासकर टूटी पैकेजिंग या अस्पष्ट लेबल के मामले में। उसे उसी सैंपल रिकॉर्ड से जोड़ें, ताकि स्टाफ को अलग फ़ोल्डर खोजना न पड़े।

पुष्टि किए गए हैंडऑफ़ को लॉक करें

सेंडर और रिसीवर के ट्रांसफ़र की पुष्टि करने के बाद मूल हैंडऑफ़ विवरण लॉक करें। स्टाफ बाद की एंट्री को नए सुधार रिकॉर्ड से ठीक कर सकता है, लेकिन पहली टाइमस्टैम्प, स्थिति के परिणाम या ज़िम्मेदार लोगों को ओवरराइट न करे।

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

AppMaster फ़ॉर्म हैंडऑफ़ फ़ील्ड एकत्र कर सकता है, जबकि बिज़नेस प्रोसेस स्टेटस बदलने से पहले दोनों पुष्टियाँ अनिवार्य कर सकता है। यही प्रोसेस तब सुपरवाइज़र के लिए अपवाद कार्य बना सकता है जब रिसीवर क्षति, तापमान की समस्या या कम मात्रा की सूचना दे।

उदाहरण: फील्ड से अंतिम परिणाम तक सैंपल की यात्रा

एक फील्ड कलेक्टर 09:12 बजे River Site 14 से पानी का सैंपल लेता है। फ़ोन या टैबलेट से वह रिकॉर्ड बनाता है, बोतल का बारकोड स्कैन करता है और कलेक्शन का समय, स्थान, सैंपल प्रकार और अपना नाम दर्ज करता है। वह बोतल का सील नंबर भी दर्ज करता है और सील बंद कंटेनर की फ़ोटो जोड़ता है।

09:25 बजे कलेक्टर बोतल को ठंडे ट्रांसपोर्ट बॉक्स में रखता है। वह बॉक्स ID, तापमान और अनुमानित पहुँचने का समय दर्ज करता है। अब कस्टडी रिकॉर्ड बताता है कि सैंपल किसके पास था, कहाँ रखा गया था और ट्रांसपोर्ट शुरू होने से पहले उसकी स्थिति क्या थी।

कूरियर 10:05 बजे बॉक्स प्राप्त करता है। दोनों लोग वर्कफ़्लो में ट्रांसफ़र की पुष्टि करते हैं। रिकॉर्ड टाइमस्टैम्प जोड़ता है और कूरियर को ज़िम्मेदार व्यक्ति के रूप में दिखाता है। कागज़ी हस्ताक्षर काम कर सकते हैं, लेकिन डिजिटल पुष्टि बाद में ढूँढना आसान है।

इनटेक में समस्या मिलती है

लैब तकनीशियन 11:18 बजे सैंपल प्राप्त करता है। इनटेक के दौरान वह बारकोड स्कैन करता है और सील नंबर को कलेक्शन रिकॉर्ड से मिलाता है। तकनीशियन को बाहरी सील में छोटा-सा चीरा दिखाई देता है।

वह स्थिति जाँच दर्ज करता है, फ़ोटो जोड़ता है और «क्षतिग्रस्त सील» को अपवाद के रूप में चुनता है। वर्कफ़्लो रिकॉर्ड समीक्षक को भेजता है और तकनीशियन को सैंपल टेस्टिंग के लिए असाइन करने से रोकता है।

रिकॉर्ड में इनटेक का समय और तकनीशियन का नाम, देखी गई क्षति और फ़ोटो, पहुँचने पर तापमान तथा अपवाद के लिए नियुक्त समीक्षक शामिल होते हैं।

टेस्टिंग से पहले समीक्षा

समीक्षक कलेक्शन फ़ोटो, ट्रांसपोर्ट विवरण और इनटेक नोट देखता है। वह कलेक्टर से संपर्क करता है, जो पुष्टि करता है कि बोतल का ढक्कन बंद रहा था और चीरा केवल बाहरी टैम्पर सील पर था। समीक्षक कारण दर्ज करता है, तय करता है कि सैंपल विश्लेषण के लिए उपयुक्त है और 12:02 बजे अपवाद बंद करता है।

इसके बाद ही वर्कफ़्लो सैंपल को विश्लेषक के लिए जारी करता है। 12:15 बजे विश्लेषक हैंडऑफ़ स्वीकार करता है, स्वीकृत टेस्ट करता है और माप दर्ज करता है। सिस्टम मूल निरीक्षण, अपवाद, समीक्षा निर्णय और परिणाम को एक साथ रखता है।

सुपरवाइज़र 14:40 बजे पूरा रिकॉर्ड देखता है। वह जाँचता है कि हर ट्रांसफ़र में व्यक्ति, समय और स्थिति की एंट्री है, फिर अंतिम परिणाम को मंज़ूरी देता है। मंज़ूरी के बाद ही वर्कफ़्लो परिणाम को जारी किया हुआ चिह्नित करता है। अगर समीक्षक ने क्षतिग्रस्त सील को अस्वीकार किया होता, तो रिकॉर्ड में कारण दिखाई देता और रिलीज़ रुक जाती।

AppMaster में बना नो-कोड ऐप इन जाँचों में स्टाफ का मार्गदर्शन एक ही प्रोसेस में कर सकता है और याददाश्त तथा अलग-अलग स्प्रेडशीट पर निर्भरता कम कर सकता है।

ऐसी गलतियाँ जो कस्टडी रिकॉर्ड में कमी पैदा करती हैं

लैब सैंपल कस्टडी में अधिकांश टूटन एक छोटे शॉर्टकट से शुरू होती है। तकनीशियन याद से ID टाइप करता है, स्थिति की टिप्पणी उसी जगह बदल देता है या टेस्टिंग बंद होने से पहले परिणाम दर्ज कर देता है। बाद में रिकॉर्ड पूरा दिखाई दे सकता है, लेकिन उसमें ठीक-ठीक क्या हुआ, यह स्पष्ट नहीं रहता।

फ्री-फ़ॉर्म सैंपल ID जल्दी समस्या पैदा करते हैं। «Water-14», «water 14» और «WTR14» एक ही कंटेनर को दर्शा सकते हैं, फिर भी सिस्टम उन्हें अलग सैंपल मान सकता है। हर ID अपने आप बनाएँ, जहाँ संभव हो बारकोड या QR स्कैन करें और अपेक्षित फ़ॉर्मैट से मेल न खाने वाली एंट्री अस्वीकार करें। नया रिकॉर्ड बनाने से पहले स्टाफ को मौजूदा रिकॉर्ड खोजना चाहिए।

स्थिति जाँच की अपनी हिस्ट्री होनी चाहिए। अगर कूरियर दर्ज करता है कि कूलर 5 C पर पहुँचा और बाद में लैब रिसीवर को टूटा ढक्कन मिलता है, तो दोनों निरीक्षण लैबोरेटरी सैंपल रिकॉर्ड में रहने चाहिए। पहली टिप्पणी को दूसरी से न बदलें। हर जाँच के लिए समय, व्यक्ति, स्थिति और फ़ोटो या टिप्पणी सेव करें।

हैंडऑफ़ में दो अलग पुष्टियाँ भी चाहिए। सैंपल रिलीज़ करने वाला और स्वीकार करने वाला व्यक्ति टाइमस्टैम्प और स्थान के साथ ट्रांसफ़र की पुष्टि करें। काम के घंटों के बाद लॉक किए गए रेफ्रिजरेटर में सैंपल रखने पर एक ही व्यक्ति दोनों चरण कर सकता है। इस अपवाद की अनुमति दें, लेकिन कारण अनिवार्य करें और सुपरवाइज़र की समीक्षा के लिए फ़्लैग करें।

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

एंट्री के समय सरल नियम लगाएँ: अमान्य या डुप्लिकेट सैंपल ID अस्वीकार करें, पुरानी स्थिति जाँच संपादित करने के बजाय नई जाँच जोड़ें, ट्रांसफ़र के लिए सेंडर और रिसीवर की पुष्टि अनिवार्य करें और टेस्टिंग खुली रहने पर परिणाम जारी होने से रोकें।

इन नियंत्रणों से सैंपल हैंडऑफ़ ट्रैकिंग याददाश्त पर कम निर्भर रहती है। समीक्षक ईमेल या कागज़ी नोट से घटनाएँ दोबारा बनाए बिना कलेक्शन से परिणाम तक सैंपल का रास्ता देख सकता है।

परिणाम जारी करने से पहले त्वरित जाँच

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

कलेक्शन से विश्लेषण तक कस्टडी लॉग को क्रम से देखें। हर ट्रांसफ़र में सेंडर, रिसीवर और टाइमस्टैम्प का नाम होना चाहिए। केवल «लैब ने प्राप्त किया» के रूप में दर्ज हैंडऑफ़ में बहुत कुछ अस्पष्ट रहता है।

रिलीज़ से पहले पुष्टि करें कि हर लैबोरेटरी सैंपल रिकॉर्ड में एक ही सैंपल ID है। जाँचें कि हर हैंडऑफ़ में सेंडर और रिसीवर दोनों हैं। फिर खाली, डुप्लिकेट या गलत क्रम वाले टाइमस्टैम्प देखें। तापमान, सील की स्थिति, कंटेनर की क्षति और स्टोरेज स्थान की समीक्षा करें। हर अपवाद नोट पढ़ें और सुनिश्चित करें कि टीम ने हर समस्या का समाधान या अनुमोदन दर्ज किया है।

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

परिणाम की तुलना पूरी हिस्ट्री से करें

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

स्पष्ट स्टेटस बदलाव समीक्षकों को कमियाँ खोजने में मदद करते हैं। सैंपल कलेक्ट किया गया, ट्रांज़िट में, प्राप्त, स्टोर किया गया, तैयार, टेस्ट किया गया, समीक्षा में और जारी किया गया जैसे चरणों से गुजर सकता है। अगर वह «ट्रांज़िट में» से सीधे «टेस्ट किया गया» हो जाए, तो किसी को छूटे हुए रिसीट या स्टोरेज चरण का कारण बताना चाहिए।

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

अंतिम मंज़ूरी का रिकॉर्ड परिणाम के साथ रखें। किसने मंज़ूरी दी, कब दी और उससे जुड़ी कोई शर्त हो तो उसे दर्ज करें। यह अंतिम एंट्री कस्टडी हिस्ट्री पूरी करती है।

ऐसी छोटी शुरुआत करें जिसे आपकी टीम इस्तेमाल कर सके

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

कलेक्टर, रिसीवर, विश्लेषक और अनुमोदक मिलकर ज़रूरी फ़ील्ड तय करें। सूची व्यावहारिक रखें: सैंपल ID, कलेक्शन समय, कलेक्टर, वर्तमान स्थान, हर हैंडऑफ़ स्वीकार करने वाला व्यक्ति, पहुँचने पर स्थिति और अंतिम परिणाम स्टेटस। पायलट शुरू होने से पहले अपवाद के नियम तय करें।

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

AppMaster इस प्रक्रिया को बिना कोड लिखे ऐप में बदल सकता है। सैंपल, हैंडऑफ़, स्थिति जाँच और स्टाफ सदस्य के रिकॉर्ड बनाने के लिए Data Designer इस्तेमाल करें। कलेक्शन और रिसीविंग के लिए वेब या मोबाइल फ़ॉर्म बनाएँ, फिर स्टाफ द्वारा हर फ़ॉर्म सबमिट करने के बाद क्या होगा, इसे नियंत्रित करने के लिए Business Process Editor का इस्तेमाल करें।

एक्सेस को वास्तविक ज़िम्मेदारियों के अनुसार सेट करें। कलेक्टर सैंपल बना और कलेक्शन विवरण दर्ज कर सके। रिसीविंग तकनीशियन उसे स्वीकार या फ़्लैग कर सके। विश्लेषक टेस्ट स्टेटस और परिणाम दर्ज कर सके। अंतिम परिणाम केवल अधिकृत समीक्षक ही जारी करे। पहले की एंट्री बाद के उपयोगकर्ताओं द्वारा ओवरराइट होने के बजाय दिखाई देती रहे।

स्टाफ को सक्रिय सैंपल देने से पहले स्पष्ट रूप से चिह्नित अभ्यास रिकॉर्ड के साथ वास्तविक स्थितियों की जाँच करें। क्षतिग्रस्त कंटेनर, गलत सैंपल ID, अपेक्षित होल्डिंग समय के बाद का हैंडऑफ़, अनुपलब्ध रिसीवर और सुधार के लिए लौटाए गए अस्वीकार किए गए परिणाम का परीक्षण करें।

हर टेस्ट रिकॉर्ड की समीक्षा करें। पुष्टि करें कि ऐप हर चरण पर टाइमस्टैम्प, ज़िम्मेदार व्यक्ति, स्थिति, अपवाद नोट और निर्णय दर्ज करता है। यह भी जाँचें कि स्टाफ सैंपल ID खोजकर पूरी हिस्ट्री जल्दी ढूँढ सके।

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