ระบบควบคุมตัวอย่างในห้องแล็บ: ติดตามการส่งมอบทุกครั้ง

ทำไมบันทึกตัวอย่างจึงขาดช่วงระหว่างการเก็บและผลลัพธ์

ผลการทดสอบในห้องแล็บจะน่าเชื่อถือเมื่อเจ้าหน้าที่แสดงได้ว่าเกิดอะไรขึ้นกับตัวอย่างก่อนการทดสอบ การส่งมอบที่หายไปเพียงครั้งเดียวอาจทำให้ตอบคำถามพื้นฐานไม่ได้ว่าใครเป็นผู้ถือครองตัวอย่าง ได้รับตัวอย่างเมื่อใด และตัวอย่างยังเหมาะสำหรับการวิเคราะห์หรือไม่

บันทึกกระดาษ ข้อความในกล่องจดหมาย และการแจ้งด้วยวาจามักทำให้เรื่องราวกระจายอยู่หลายที่ ผู้ปฏิบัติงานภาคสนามอาจบันทึกเวลาเก็บตัวอย่างในแบบฟอร์ม พนักงานขนส่งเซ็นชื่อในบันทึกอีกชุด และห้องแล็บป้อนข้อมูลตัวอย่างหลังได้รับแล้ว เมื่อมีข้อร้องเรียน การตรวจประเมิน หรือผลลัพธ์ที่ผิดปกติ เจ้าหน้าที่ต้องย้อนสร้างประวัติขึ้นมาใหม่

ระบบควบคุมตัวอย่างในห้องแล็บบันทึกการส่งมอบทุกครั้งเป็นเหตุการณ์ จึงสร้างประวัติต่อเนื่องตั้งแต่การเก็บตัวอย่างไปจนถึงการเผยแพร่ผลลัพธ์

สถานะไม่ได้พิสูจน์ว่ามีการส่งมอบ

สถานะตัวอย่างเป็นป้ายสั้นๆ เช่น «เก็บแล้ว» «กำลังขนส่ง» «รับแล้ว» «กำลังทดสอบ» หรือ «รายงานแล้ว» สถานะช่วยให้เห็นว่างานอยู่ขั้นตอนไหน แต่ไม่ได้บอกว่าใครเปลี่ยนสถานะ เปลี่ยนเพราะอะไร หรือตัวอย่างมีสภาพตามที่กำหนดหรือไม่

เหตุการณ์การควบคุมจะบันทึกรายละเอียดเบื้องหลังการเปลี่ยนสถานะ เมื่อพนักงานขนส่งส่งตัวอย่างน้ำให้ช่างเทคนิคในห้องแล็บ บันทึกควรระบุผู้ส่งและผู้รับ วันเวลา สถานที่เมื่อจำเป็น และสภาพตัวอย่าง ช่างเทคนิคสามารถยืนยันได้ว่าซีลยังสมบูรณ์และอุณหภูมิของกล่องเก็บความเย็นอยู่ในช่วงที่ยอมรับได้

ความแตกต่างนี้สำคัญเมื่อต้องตรวจสอบ คำว่า «รับแล้ว» บอกเพียงว่าห้องแล็บมีตัวอย่าง ส่วนเหตุการณ์การส่งมอบบอกว่า Jordan Lee รับตัวอย่าง W-104 เวลา 10:18 น. วันที่ 4 มิถุนายน ตรวจซีลแล้ว และนำตัวอย่างไปเก็บในพื้นที่ควบคุมอุณหภูมิ

บันทึกที่ทำให้เรื่องราวไม่ขาดตอน

ทีมต้องมีบันทึกมาตรฐานเดียวตั้งแต่เก็บตัวอย่างจนถึงรายงานผล ช่องข้อมูลที่ต้องใช้ขึ้นอยู่กับห้องแล็บและประเภทการทดสอบ แต่โดยทั่วไปควรมีรหัสตัวอย่างที่ไม่ซ้ำ วันและเวลาเก็บ สถานที่เก็บ และชื่อผู้เก็บตัวอย่าง นอกจากนี้ต้องบันทึกการส่งมอบทุกครั้ง รวมถึงผู้ส่ง ผู้รับ เวลา และการตัดสินใจว่าจะรับหรือปฏิเสธตัวอย่าง

บันทึกควรครอบคลุมการตรวจสอบสภาพ เช่น ความสมบูรณ์ของภาชนะ สถานะซีล อุณหภูมิ ปริมาณ และความเสียหายที่มองเห็นได้ รวมถึงสถานที่จัดเก็บ การมอบหมายการทดสอบ นักวิเคราะห์ ขั้นตอนสำคัญในการประมวลผล ผลลัพธ์สุดท้าย ผู้ตรวจสอบ เวลาเผยแพร่ และการแก้ไขภายหลัง

เจ้าหน้าที่ควรบันทึกข้อยกเว้นทันทีที่เกิดขึ้น หากพนักงานขนส่งมาถึงล่าช้าหรือภาชนะรั่ว บันทึกต้องระบุสภาพจริง ผู้ที่พบปัญหา และการดำเนินการที่ทำ การเปลี่ยนสถานะหรือลบเหตุการณ์จะซ่อนข้อมูลที่ผู้ตรวจสอบอาจต้องใช้

เวิร์กโฟลว์เดียวช่วยให้ทุกคนกรอกรายละเอียดในที่เดียว ตัวอย่างเช่น แอปแบบไม่ต้องเขียนโค้ดที่สร้างด้วย AppMaster สามารถกำหนดให้ผู้รับตรวจสอบสภาพก่อนยืนยันการรับส่งมอบ เวิร์กโฟลว์จะเก็บเวลาและผู้รับผิดชอบไว้กับบันทึกตัวอย่าง แทนการพึ่งความจำภายหลังหรือข้อความที่กระจัดกระจาย

กำหนดข้อมูลที่ตัวอย่างแต่ละชิ้นต้องมี

ระบบควบคุมตัวอย่างในห้องแล็บควรเริ่มด้วยกฎง่ายๆ คือสร้างบันทึกทันทีที่ตัวอย่างเข้ามาอยู่ในความดูแล กำหนดรหัสตัวอย่างที่ไม่ซ้ำตั้งแต่ตอนเก็บ ไม่ใช่เมื่อมาถึงห้องแล็บ ฉลากเขียนมือใช้ได้กับทีมขนาดเล็ก แต่ต้องตรงกับบันทึกดิจิทัลทุกประการ รหัสซ้ำสร้างความสับสนที่แก้ด้วยหมายเหตุภายหลังได้ยาก

ใช้รูปแบบรหัสที่เจ้าหน้าที่อ่านได้เร็ว เช่น วันที่เก็บรวมกับหมายเลขลำดับสั้นๆ อย่าใส่ชื่อบุคคลหรือรายละเอียดคดีที่ละเอียดอ่อนลงในรหัส ให้เก็บข้อมูลเหล่านั้นไว้ในช่องที่มีการป้องกันของบันทึกตัวอย่าง

บันทึกแรกควรตอบคำถามพื้นฐานได้โดยไม่ต้องค้นหาแบบฟอร์มกระดาษหรือโทรหาผู้เก็บตัวอย่าง เก็บชื่อและข้อมูลติดต่อของผู้เก็บ วันและเวลาที่แน่นอน สถานที่ ประเภทตัวอย่าง โครงการหรือคำขอทดสอบที่เกี่ยวข้อง การวิเคราะห์ที่ต้องการ และกำหนดเวลาที่ต้องการผล

รายละเอียดการเก็บเพียงอย่างเดียวไม่ได้บอกว่าตัวอย่างยังเหมาะสำหรับการทดสอบหรือไม่ ต้องบันทึกสภาพเริ่มต้นที่ชัดเจนด้วย เช่น สมบูรณ์ รั่ว แช่แข็ง แช่เย็น ขุ่น แห้ง หรือเสียหาย หมายเหตุแบบพิมพ์อิสระมีประโยชน์ในกรณีพิเศษ แต่ตัวเลือกมาตรฐานสำหรับสภาพทั่วไปช่วยให้ค้นหาและเปรียบเทียบข้อมูลได้ง่ายขึ้น

กำหนดช่องเฉพาะสำหรับภาชนะและซีล บันทึกชนิดภาชนะ ปริมาณหรือปริมาตร หมายเลขซีลเมื่อมี และซีลยังสมบูรณ์ตอนเก็บหรือไม่ ตัวอย่างน้ำอาจต้องใช้ขวดปลอดเชื้อขนาด 500 mL ซีลป้องกันการเปิดที่สมบูรณ์ และจัดเก็บที่ 2-8 C หากใช้ภาชนะอื่นหรือพบซีลแตก บันทึกควรแสดงข้อมูลนั้นทันที

คำแนะนำการจัดเก็บต้องชัดเจนเช่นกัน คำว่า «เก็บให้เย็น» เปิดโอกาสให้เกิดความผิดพลาด ส่วน «เก็บที่ 2-8 C ป้องกันแสง และนำส่งภายใน 24 ชั่วโมง» ให้คำแนะนำที่ชัดเจนแก่พนักงานขนส่งและผู้รับในห้องแล็บ

แอปแบบไม่ต้องเขียนโค้ดที่สร้างด้วย AppMaster สามารถกำหนดให้ต้องกรอกข้อมูลเหล่านี้ก่อนบันทึกข้อมูลการเก็บตัวอย่าง และแสดงช่องสภาพหรือการจัดเก็บที่แตกต่างกันตามประเภทตัวอย่าง เพื่อไม่ให้ผู้เก็บตัวอย่างภาคสนามต้องตอบคำถามที่ไม่เกี่ยวข้อง

อย่าทำให้ทุกช่องเป็นข้อมูลเสริม กำหนดให้ต้องมีรหัส ผู้เก็บ เวลา สถานที่ ประเภทตัวอย่าง สภาพเริ่มต้น ภาชนะ และข้อกำหนดการจัดเก็บ หากขาดข้อมูลที่จำเป็น ให้เลือกเหตุผลข้อยกเว้นที่กำหนดไว้และเพิ่มหมายเหตุ ห้องแล็บจะได้เห็นช่องว่างและตรวจสอบก่อนเริ่มการทดสอบ

วางแผนเส้นทางตัวอย่างก่อนสร้างเวิร์กโฟลว์

แบบฟอร์มควบคุมตัวอย่างทำงานได้ดีที่สุดเมื่อสอดคล้องกับเส้นทางที่ตัวอย่างเดินทางจริง พูดคุยกับผู้เก็บ ผู้รับ ผู้ทดสอบ ผู้ตรวจสอบ และผู้รายงานผล เขียนทุกจุดที่ตัวอย่างต้องผ่านด้วยภาษาง่ายๆ ก่อนสร้างช่องหน้าจอหรือกฎ

เริ่มจากสถานะที่ชัดเจนจำนวนไม่มาก ห้องแล็บหลายแห่งใช้เส้นทาง เช่น เก็บแล้ว รับแล้ว อยู่ระหว่างทดสอบ รอตรวจสอบ และรายงานแล้ว เพิ่มสถานะเมื่อสถานะนั้นอธิบายการเปลี่ยนแปลงด้านการควบคุมหรืองานจริงเท่านั้น สถานะ «รอ» อาจทำให้สับสน หากไม่รู้ว่าใครถือตัวอย่างและงานหยุดเพราะอะไร

สถานะบอกว่าตัวอย่างอยู่ตรงไหนในกระบวนการ ส่วนบันทึกการควบคุมบอกว่าใครรับผิดชอบในเวลาที่กำหนด ควรเก็บข้อมูลสองส่วนนี้แยกกัน

ระบุช่วงเวลาที่ต้องสร้างบันทึกการควบคุม

สร้างรายการควบคุมใหม่ทุกครั้งที่ความรับผิดชอบเปลี่ยนมือ หรือตัวอย่างย้ายไปยังสถานที่ที่ทำให้ผู้ควบคุมเปลี่ยนไป ช่างเทคนิคภาคสนามที่ใส่หลอดลงในกล่องเก็บความเย็นบันทึกการเก็บตัวอย่าง พนักงานขนส่งที่รับกล่องบันทึกการรับ และช่างเทคนิคในห้องแล็บที่นำหลอดออกไปวิเคราะห์บันทึกการส่งมอบครั้งถัดไป

ใช้กฎง่ายๆ ถ้ามีคนถามว่า «เวลา 10:30 ใครเป็นคนถือตัวอย่าง» เวิร์กโฟลว์ต้องมีเหตุการณ์ที่ตอบคำถามนี้ได้ แต่ละเหตุการณ์ควรมีรหัสตัวอย่าง วันและเวลา ผู้รับผิดชอบ สถานที่หรือจุดส่งมอบ และผลตรวจสอบสภาพ

การตรวจสอบสภาพควรใช้ช่องแบบมีโครงสร้าง เจ้าหน้าที่เลือกค่า เช่น ซีลสมบูรณ์ ภาชนะเสียหาย อุณหภูมิอยู่ในเกณฑ์ หรืออุณหภูมินอกช่วง หมายเหตุใช้อธิบายข้อยกเว้นได้ แต่ไม่ควรใช้แทนการตรวจสอบ

ทำให้บันทึกอ่านได้แม้มีการแก้ไข

หมายเหตุและการแก้ไขเป็นเรื่องปกติในงานห้องแล็บ ช่างเทคนิคอาจเพิ่มข้อความว่า «ฉลากเปียกเล็กน้อย» หรือแก้คำสะกดชื่อสถานที่ การกระทำเหล่านี้ไม่ควรเขียนทับเหตุการณ์การควบคุมเดิมโดยไม่ทิ้งร่องรอย

เก็บรายการส่งมอบเดิมไว้ แล้วเพิ่มบันทึกการแก้ไขแยกต่างหาก พร้อมชื่อผู้แก้ไข เวลา เหตุผล และค่าที่ปรับปรุง แนบหมายเหตุกับเหตุการณ์ที่เกี่ยวข้องโดยไม่เปลี่ยนสถานะตัวอย่าง วิธีนี้ทำให้บันทึกตัวอย่างในห้องปฏิบัติการตรวจสอบได้ง่ายขึ้นเมื่อมีการตรวจคุณภาพหรือคำถามจากลูกค้า

ใน AppMaster ทีมสามารถสร้างตัวอย่าง เหตุการณ์การควบคุม การตรวจสอบสภาพ และการแก้ไขเป็นบันทึกแยกกัน กระบวนการทางธุรกิจแบบภาพสามารถกำหนดให้การส่งมอบต้องครบก่อนเลื่อนสถานะ ประวัติที่ได้จะแสดงเส้นทางตัวอย่างทั้งหมด ไม่ใช่เพียงการอัปเดตล่าสุด

สร้างเวิร์กโฟลว์ทีละขั้นตอน

สร้างระบบควบคุมตัวอย่างรอบรหัสตัวอย่างถาวรหนึ่งรหัส กำหนดรหัสตั้งแต่เก็บตัวอย่าง และใช้รหัสนั้นบนฉลาก บันทึกการเก็บ บันทึกการส่งมอบ บันทึกการทดสอบ และผลลัพธ์สุดท้าย บาร์โค้ดหรือ QR code ช่วยลดการพิมพ์ผิด แต่เจ้าหน้าที่ควรเห็นรหัสบนหน้าจอก่อนบันทึกเหตุการณ์ทุกครั้ง

เริ่มจากแบบฟอร์มเก็บตัวอย่าง กำหนดให้ต้องมีข้อมูลที่บอกว่าตัวอย่างมาจากไหนและใครเป็นผู้เก็บ ได้แก่ วันและเวลาเก็บ ชื่อผู้เก็บ สถานที่หรือแหล่งที่มา ประเภทตัวอย่าง รหัสภาชนะ และสภาพขณะเก็บ เพิ่มหมายเหตุสำหรับข้อมูล เช่น ซีลเสียหายหรืออุณหภูมินอกช่วงปกติ

เพิ่มการส่งมอบแต่ละครั้งเป็นบันทึกแยก

อย่าเขียนทับข้อมูลของผู้เก็บเมื่อมีการเปลี่ยนมือ สร้างบันทึกการส่งมอบทุกครั้งที่มีคนส่งหรือรับตัวอย่าง แต่ละบันทึกควรแสดงชื่อทั้งสองฝ่าย วันเวลา สถานที่ส่งมอบ และรหัสตัวอย่าง

ผู้รับควรยืนยันสภาพตัวอย่างก่อนรับผิดชอบ ให้ตัวเลือกที่ชัดเจน เช่น ซีลสมบูรณ์ ภาชนะเสียหาย ฉลากอ่านไม่ได้ ตรวจอุณหภูมิแล้ว หรือปริมาณไม่เพียงพอ หากพบปัญหา ให้บังคับเพิ่มคำอธิบายสั้นๆ และแจ้งผู้รับผิดชอบตรวจสอบ

บันทึกการส่งมอบที่ใช้งานได้ควรมีรหัสตัวอย่างและสถานะปัจจุบัน ผู้ปล่อยตัวอย่าง ผู้รับ วันเวลาและสถานที่ส่งมอบ รวมถึงการตรวจสอบสภาพและหมายเหตุ เพิ่มรูปถ่ายประกอบเมื่อเป็นนโยบายของห้องแล็บ

เก็บทุกเหตุการณ์ไว้ใต้รหัสตัวอย่างเดียวกัน ไม่ใช่ในสเปรดชีตหรือเธรดอีเมลแยกกัน เจ้าหน้าที่จึงเห็นประวัติตามลำดับเวลาและตอบคำถามในการตรวจประเมินได้ว่าใครถือตัวอย่างในแต่ละช่วง

ปิดบันทึกด้วยผลลัพธ์ที่เผยแพร่แล้ว

เมื่อการทดสอบเสร็จ นักวิเคราะห์บันทึกผล วิธีการ เวลาที่เสร็จ และหมายเหตุ จากนั้นผู้ตรวจสอบหรือเจ้าหน้าที่ที่ได้รับอนุญาตจะเผยแพร่ผล พร้อมบันทึกชื่อและเวลาเผยแพร่ แยกการเผยแพร่ผลจากการบันทึกการทดสอบ เพื่อให้เห็นว่าใครสร้างผลและใครอนุมัติผล

AppMaster ช่วยให้ทีมสร้างแบบฟอร์มและกฎสถานะได้โดยไม่ต้องเขียนโค้ด กระบวนการทางธุรกิจสามารถป้องกันการส่งมอบหรือการเผยแพร่ผล หากข้อมูลที่จำเป็นยังไม่ครบ ตัวอย่างเช่น ระบบอาจไม่ยอมรับตัวอย่างจนกว่าผู้รับจะบันทึกสภาพซีล กฎนี้ปิดช่องว่างที่พบบ่อยก่อนจะไปถึงรายงานสุดท้าย

ทำให้ตรวจสอบการส่งมอบทุกครั้งได้ง่าย

บันทึกการควบคุมจะมีประโยชน์เมื่อผู้ตรวจสอบตอบคำถามห้าข้อได้โดยไม่ต้องค้นหาอีเมลหรือเอกสารกระดาษ ได้แก่ ใครส่ง ใครรับ ส่งมอบเมื่อใด ที่ไหน และย้ายเพราะอะไร ใส่ช่องเหล่านี้ไว้ในแบบฟอร์มการส่งมอบทุกแบบ และกำหนดให้กรอกก่อนยืนยัน

ใช้ชื่อจากบัญชีเจ้าหน้าที่แทนข้อความอิสระเมื่อทำได้ เพื่อป้องกันข้อมูลอย่าง «J. Smith» ในบันทึกหนึ่งและ «John» ในอีกบันทึกหนึ่ง สำหรับสถานที่ ให้รายการสั้นๆ ที่ได้รับอนุมัติ เช่น จุดเก็บตัวอย่าง จุดรับตัวอย่าง ห้องเก็บความเย็น หรือพื้นที่ทดสอบ

เหตุผลการย้ายช่วยป้องกันประวัติที่คลุมเครือ เจ้าหน้าที่อาจเลือก «นำส่งตามปกติ» «ย้ายไปจัดเก็บ» «มอบหมายเพื่อทดสอบ» หรือ «ส่งตรวจซ้ำ» ควรปรับตัวเลือกให้ตรงกับงานจริงของห้องแล็บ แทนการให้รายการทั่วไปที่ยาวเกินไป

ตรวจสอบสภาพ ณ จุดส่งมอบ

ผู้รับควรบันทึกสภาพตัวอย่างก่อนรับผิดชอบ รายการตรวจสอบง่ายๆ ช่วยให้การตรวจสอบสม่ำเสมอทุกกะ ควรมีสภาพซีล ช่วงอุณหภูมิ ความเสียหายของภาชนะ ปริมาตรตัวอย่าง และความชัดเจนของฉลาก

หากพบปัญหา ให้บังคับเพิ่มหมายเหตุ คำว่า «เสียหาย» ไม่ได้บอกว่าภาชนะรั่ว แตก หรือมาถึงโดยไม่มีฝา หมายเหตุที่ดีควรระบุสิ่งที่เห็น สิ่งที่ทำ และผู้ที่ได้รับแจ้ง เช่น «ซีลยกขึ้นบางส่วนเมื่อมาถึง ภาชนะไม่รั่ว ผู้รับนำไปเก็บที่ 4 C และแจ้งหัวหน้าห้องแล็บ»

รูปถ่ายช่วยได้เมื่อเป็นไปตามนโยบายของห้องแล็บ โดยเฉพาะบรรจุภัณฑ์ที่แตกหรือฉลากไม่ชัด แนบรูปกับบันทึกตัวอย่างเดียวกัน เพื่อไม่ให้เจ้าหน้าที่ต้องค้นหาในโฟลเดอร์อื่น

ล็อกการส่งมอบที่ยืนยันแล้ว

เมื่อผู้ส่งและผู้รับยืนยันการส่งมอบแล้ว ให้ล็อกรายละเอียดเดิม เจ้าหน้าที่แก้ไขรายการภายหลังได้ด้วยบันทึกการแก้ไขใหม่ แต่ไม่ควรเขียนทับเวลาแรก ผลตรวจสอบสภาพ หรือชื่อผู้รับผิดชอบ

บันทึกการแก้ไขควรเก็บรายการเดิมให้เห็น แสดงข้อมูลที่แก้ ระบุผู้แก้ไข และบังคับใส่เหตุผล หากช่างเทคนิคบันทึกสถานที่จัดเก็บผิด บันทึกควรแสดงว่าแก้จาก «ห้องเก็บความเย็น» เป็น «พื้นที่ทดสอบ» แทนการแทนที่ข้อมูลเดิมอย่างเงียบๆ

แบบฟอร์ม AppMaster สามารถรวบรวมข้อมูลการส่งมอบ ขณะที่กระบวนการทางธุรกิจกำหนดให้ทั้งสองฝ่ายยืนยันก่อนเปลี่ยนสถานะตัวอย่าง กระบวนการเดียวกันยังสร้างงานข้อยกเว้นให้หัวหน้างานเมื่อผู้รับรายงานความเสียหาย อุณหภูมิมีปัญหา หรือปริมาณต่ำ

ตัวอย่าง: ตัวอย่างเดินทางจากภาคสนามไปสู่ผลลัพธ์สุดท้าย

ผู้เก็บตัวอย่างภาคสนามเก็บตัวอย่างน้ำจาก River Site 14 เวลา 09:12 น. ใช้โทรศัพท์หรือแท็บเล็ตสร้างบันทึก สแกนบาร์โค้ดบนขวด และกรอกเวลาเก็บ สถานที่ ประเภทตัวอย่าง และชื่อของตนเอง นอกจากนี้ยังบันทึกหมายเลขซีลและถ่ายรูปภาชนะที่ปิดผนึกแล้ว

เวลา 09:25 น. ผู้เก็บใส่ขวดลงในกล่องขนส่งแบบควบคุมความเย็น บันทึกรหัสกล่อง อุณหภูมิ และเวลาที่คาดว่าจะมาถึง ประวัติการควบคุมจึงแสดงว่าใครถือตัวอย่าง เก็บไว้ที่ไหน และมีสภาพอย่างไรก่อนเริ่มขนส่ง

พนักงานขนส่งรับกล่องเวลา 10:05 น. ทั้งสองฝ่ายยืนยันการส่งมอบในเวิร์กโฟลว์ ระบบเพิ่มเวลาและระบุพนักงานขนส่งเป็นผู้รับผิดชอบ ลายเซ็นบนกระดาษใช้ได้ แต่การยืนยันแบบดิจิทัลค้นหาในภายหลังได้ง่ายกว่า

ฝ่ายรับตัวอย่างพบปัญหา

ช่างเทคนิคในห้องแล็บรับตัวอย่างเวลา 11:18 น. ระหว่างรับเข้า ช่างเทคนิคสแกนบาร์โค้ดและเปรียบเทียบหมายเลขซีลกับบันทึกการเก็บตัวอย่าง จากนั้นพบรอยฉีกเล็กๆ ที่ซีลด้านนอก

ช่างเทคนิคบันทึกผลตรวจสอบสภาพ เพิ่มรูปถ่าย และเลือก «ซีลเสียหาย» เป็นข้อยกเว้น เวิร์กโฟลว์ส่งบันทึกให้ผู้ตรวจสอบและไม่อนุญาตให้มอบหมายตัวอย่างไปทดสอบ

บันทึกประกอบด้วยเวลารับเข้า ชื่อช่างเทคนิค ความเสียหายและรูปถ่าย อุณหภูมิเมื่อมาถึง และชื่อผู้ตรวจสอบที่รับผิดชอบข้อยกเว้น

ตรวจสอบก่อนทดสอบ

ผู้ตรวจสอบตรวจดูรูปตอนเก็บ รายละเอียดการขนส่ง และหมายเหตุเมื่อรับเข้า จากนั้นติดต่อผู้เก็บตัวอย่าง ซึ่งยืนยันว่าฝาขวดยังปิดสนิทและรอยฉีกกระทบเฉพาะซีลป้องกันการเปิดด้านนอก ผู้ตรวจสอบบันทึกคำอธิบาย ตัดสินว่าตัวอย่างยังเหมาะสำหรับวิเคราะห์ และปิดข้อยกเว้นเวลา 12:02 น.

เวิร์กโฟลว์จึงปล่อยตัวอย่างให้นักวิเคราะห์ เวลา 12:15 น. นักวิเคราะห์รับการส่งมอบ ทำการทดสอบที่อนุมัติ และป้อนค่าที่วัดได้ ระบบเก็บการสังเกตเดิม ข้อยกเว้น คำตัดสินของผู้ตรวจสอบ และผลลัพธ์ไว้ด้วยกัน

หัวหน้างานตรวจสอบบันทึกที่เสร็จแล้วเวลา 14:40 น. ตรวจว่าการส่งมอบทุกครั้งมีชื่อบุคคล เวลา และข้อมูลสภาพ จากนั้นอนุมัติผลลัพธ์สุดท้าย เวิร์กโฟลว์จะแสดงผลว่าเผยแพร่แล้วหลังอนุมัติเท่านั้น หากผู้ตรวจสอบปฏิเสธซีลที่เสียหาย บันทึกจะแสดงเหตุผลและหยุดการเผยแพร่

แอปแบบไม่ต้องเขียนโค้ดที่สร้างด้วย AppMaster ช่วยนำทีมผ่านการตรวจสอบเหล่านี้ในกระบวนการเดียว ลดการพึ่งพาความจำและสเปรดชีตหลายชุด

ข้อผิดพลาดที่ทำให้บันทึกการควบคุมขาดช่วง

ช่องว่างส่วนใหญ่ในระบบควบคุมตัวอย่างเริ่มจากทางลัดเล็กๆ ช่างเทคนิคพิมพ์รหัสจากความจำ แก้หมายเหตุสภาพเดิม หรือป้อนผลก่อนปิดการทดสอบ ภายหลังบันทึกอาจดูครบ แต่ไม่แสดงสิ่งที่เกิดขึ้นอย่างชัดเจน

รหัสตัวอย่างแบบพิมพ์อิสระสร้างปัญหาได้เร็ว «Water-14» «water 14» และ «WTR14» อาจหมายถึงภาชนะเดียวกัน แต่ระบบอาจมองเป็นตัวอย่างคนละรายการ สร้างรหัสตามรูปแบบเดียว ใช้การสแกนบาร์โค้ดหรือ QR code เมื่อทำได้ และปฏิเสธข้อมูลที่ไม่ตรงรูปแบบ เจ้าหน้าที่ควรค้นหาบันทึกเดิมก่อนสร้างรายการใหม่

การตรวจสอบสภาพต้องมีประวัติของตัวเอง หากพนักงานขนส่งบันทึกว่ากล่องมาถึงที่ 5 C และผู้รับในห้องแล็บภายหลังพบฝาแตก ข้อมูลทั้งสองต้องอยู่ในบันทึกตัวอย่างเดียวกัน อย่าแทนที่หมายเหตุแรกด้วยหมายเหตุที่สอง ให้เก็บเวลา ผู้บันทึก สภาพ และรูปหรือความคิดเห็นของการตรวจสอบแต่ละครั้ง

การส่งมอบยังต้องมีการยืนยันสองส่วน ผู้ปล่อยและผู้รับควรยืนยันการส่งมอบพร้อมเวลาและสถานที่ คนเดียวอาจทำทั้งสองขั้นตอนได้เมื่อย้ายตัวอย่างเข้าตู้เย็นที่ล็อกไว้หลังเวลาทำการ อนุญาตข้อยกเว้นนี้ได้ แต่ต้องกำหนดเหตุผลและแจ้งให้หัวหน้างานตรวจสอบ

การป้อนผลลัพธ์ต้องมีจุดควบคุมที่ชัดเจน ช่างเทคนิคอาจทราบผลที่คาดไว้ก่อนการตรวจสอบทั้งหมดเสร็จ แต่เวิร์กโฟลว์ควรหยุดการเผยแพร่จนกว่าการทดสอบจะเสร็จ และยืนยันว่ามีรหัสตัวอย่าง วิธีการ นักวิเคราะห์ และการตรวจสอบสภาพที่จำเป็นครบถ้วน หมายเหตุร่างมีได้ระหว่างการทดสอบ แต่ผลที่เผยแพร่ต้องมีประวัติครบ

ใช้กฎง่ายๆ ตั้งแต่จุดป้อนข้อมูล ปฏิเสธรหัสที่ไม่ถูกต้องหรือซ้ำ เพิ่มการตรวจสอบสภาพใหม่แทนการแก้รายการเดิม บังคับให้ผู้ส่งและผู้รับยืนยันการส่งมอบ และหยุดการเผยแพร่ผลขณะที่การทดสอบยังเปิดอยู่

การควบคุมเหล่านี้ทำให้การติดตามการส่งมอบตัวอย่างพึ่งความจำลดลง ผู้ตรวจสอบสามารถติดตามตัวอย่างตั้งแต่เก็บจนถึงผลลัพธ์ โดยไม่ต้องสร้างเหตุการณ์ใหม่จากอีเมลหรือกระดาษ

ตรวจสอบอย่างรวดเร็วก่อนเผยแพร่ผล

ผลลัพธ์สุดท้ายไม่ควรออกจากห้องแล็บจนกว่าบันทึกจะเล่าเรื่องราวได้ครบและอ่านเข้าใจง่าย เริ่มจากรหัสตัวอย่าง ต้องตรงกับบันทึกการเก็บ ฉลากภาชนะ บันทึกการส่งมอบ บันทึกการทดสอบ และผลลัพธ์ สถานะปัจจุบันก็ควรสอดคล้อง เช่น «ทดสอบเสร็จแล้ว» หรือ «พร้อมตรวจสอบ»

ตรวจสอบบันทึกการควบคุมตามลำดับ ตั้งแต่การเก็บจนถึงการวิเคราะห์ การส่งมอบทุกครั้งต้องมีชื่อผู้ส่ง ผู้รับ และเวลา การบันทึกเพียงว่า «ห้องแล็บรับแล้ว» ยังเปิดช่องให้เกิดข้อสงสัยมากเกินไป

ก่อนเผยแพร่ ยืนยันว่ารหัสตัวอย่างเดียวกันปรากฏในบันทึกตัวอย่างของห้องปฏิบัติการทุกส่วน ตรวจว่าการส่งมอบแต่ละครั้งระบุผู้ส่งและผู้รับ จากนั้นค้นหาเวลาที่ว่าง ซ้ำ หรือเรียงลำดับผิด ตรวจสอบอุณหภูมิ สภาพซีล ความเสียหายของภาชนะ และสถานที่จัดเก็บ อ่านหมายเหตุข้อยกเว้นทุกข้อ และยืนยันว่าทีมแก้ไขหรืออนุมัติแต่ละปัญหาแล้ว

ช่องสภาพที่ว่างต้องได้รับการตรวจสอบ แม้ผลลัพธ์จะดูเป็นปกติ หากช่างเทคนิคบันทึกว่ากล่องมาถึงที่ 12 C แต่วิธีการกำหนดให้ต่ำกว่านี้ ผู้ตรวจสอบต้องทราบก่อนตัดสินใจว่าจะเผยแพร่ ระบุข้อจำกัด ทดสอบซ้ำ หรือปฏิเสธผล

เปรียบเทียบผลลัพธ์กับประวัติทั้งหมด

ผู้อนุมัติควรเปรียบเทียบบันทึกการทดสอบกับระบบควบคุมตัวอย่างทั้งหมด ไม่ใช่ดูเฉพาะผลจากเครื่องมือขั้นสุดท้าย ยืนยันว่านักวิเคราะห์ทำงานกับตัวอย่างที่ถูกต้อง การทดสอบเริ่มหลังห้องแล็บรับตัวอย่าง และขั้นตอนการจัดเก็บกับการเตรียมตัวอย่างสอดคล้องกับวิธีการ

การเปลี่ยนสถานะที่ชัดเจนช่วยให้ผู้ตรวจสอบพบช่องว่าง ตัวอย่างอาจผ่านสถานะเก็บแล้ว กำลังขนส่ง รับแล้ว จัดเก็บ เตรียม ทดสอบ ตรวจสอบ และเผยแพร่ หากสถานะกระโดดจาก «กำลังขนส่ง» ไป «ทดสอบแล้ว» ต้องมีคนอธิบายว่าขั้นตอนรับหรือจัดเก็บที่หายไปอยู่ที่ไหน

ระบบเวิร์กโฟลว์ห้องปฏิบัติการอัตโนมัติช่วยลดงานตรวจสอบซ้ำๆ ได้ เวิร์กโฟลว์สามารถหยุดการเผยแพร่เมื่อการส่งมอบไม่มีผู้รับ เวลาที่จำเป็นว่างอยู่ หรือข้อยกเว้นยังไม่มีคำตัดสิน AppMaster รองรับเวิร์กโฟลว์แบบไม่ต้องเขียนโค้ดนี้ด้วยแบบฟอร์มการส่งมอบ กฎสถานะ และหน้าตรวจสอบที่แสดงประวัติตัวอย่างไว้ในที่เดียว

เก็บบันทึกการอนุมัติสุดท้ายไว้กับผลลัพธ์ ระบุว่าใครอนุมัติ เมื่อใด และมีข้อจำกัดใดแนบมากับผล การบันทึกสุดท้ายนี้ปิดประวัติการควบคุมตัวอย่าง

เริ่มจากเวิร์กโฟลว์เล็กๆ ที่ทีมใช้งานได้จริง

ระบบควบคุมตัวอย่างทำงานดีที่สุดเมื่อเวอร์ชันแรกมีขอบเขตแคบ เลือกตัวอย่างประเภทเดียว เช่น ตัวอย่างน้ำที่ทีมภาคสนามเก็บ และผู้ใช้งานประจำกลุ่มหนึ่ง อย่าพยายามแทนที่บันทึกกระดาษและระบบห้องแล็บทั้งหมดในวันแรก

ให้ผู้เก็บ ผู้รับ นักวิเคราะห์ และผู้อนุมัติช่วยกำหนดข้อมูลที่ต้องใช้ จำกัดรายการให้เหมาะกับงาน เช่น รหัสตัวอย่าง เวลาเก็บ ผู้เก็บ สถานที่ปัจจุบัน ผู้รับผิดชอบแต่ละการส่งมอบ สภาพเมื่อมาถึง และสถานะผลลัพธ์สุดท้าย ตกลงกฎข้อยกเว้นก่อนเริ่มโครงการนำร่อง

ตัวอย่างเช่น ผู้รับอาจบันทึกซีลแตก ฉลากหาย หรืออุณหภูมินอกช่วงที่ยอมรับได้ เวิร์กโฟลว์ควรกำหนดให้ใส่เหตุผล รูปถ่ายหรือหมายเหตุเมื่อห้องแล็บใช้งานสิ่งเหล่านี้ และคำตัดสินของหัวหน้างาน ช่องสภาพที่ว่างไม่ควรเลื่อนตัวอย่างไปข้างหน้า

AppMaster เปลี่ยนกระบวนการนี้เป็นแอปได้โดยไม่ต้องเขียนโค้ด ใช้ Data Designer สร้างบันทึกสำหรับตัวอย่าง การส่งมอบ การตรวจสอบสภาพ และสมาชิกทีม สร้างแบบฟอร์มบนเว็บหรือมือถือสำหรับการเก็บและรับตัวอย่าง แล้วใช้ Business Process Editor ควบคุมสิ่งที่จะเกิดขึ้นหลังเจ้าหน้าที่ส่งแบบฟอร์มแต่ละรายการ

กำหนดสิทธิ์ตามหน้าที่จริง ผู้เก็บสามารถสร้างตัวอย่างและบันทึกข้อมูลการเก็บ ช่างเทคนิคฝ่ายรับสามารถรับหรือทำเครื่องหมายปัญหา นักวิเคราะห์ป้อนสถานะและผลการทดสอบ และเฉพาะผู้ตรวจสอบที่ได้รับอนุญาตเท่านั้นที่เผยแพร่ผลสุดท้าย ข้อมูลก่อนหน้าควรมองเห็นได้ ไม่ใช่ถูกผู้ใช้ภายหลังเขียนทับ

ก่อนให้เจ้าหน้าที่ใช้กับตัวอย่างจริง ให้ทดสอบด้วยบันทึกทดลองที่ทำเครื่องหมายชัดเจน ทดสอบภาชนะเสียหาย รหัสตัวอย่างผิด การส่งมอบหลังพ้นเวลาที่กำหนด ผู้รับไม่พร้อม และผลที่ถูกปฏิเสธแล้วส่งกลับมาแก้ไข

ตรวจสอบบันทึกทดสอบแต่ละรายการ ยืนยันว่าแอปเก็บเวลา ผู้รับผิดชอบ สภาพ หมายเหตุข้อยกเว้น และคำตัดสินในทุกจุด และยืนยันว่าเจ้าหน้าที่ค้นหาประวัติทั้งหมดได้รวดเร็วด้วยรหัสตัวอย่าง

ทำโครงการนำร่องให้สั้นพอที่ทีมจะพูดคุยปัญหาได้ในขณะที่รายละเอียดต่างๆ ยังจำได้ดี แก้ป้ายชื่อช่องที่ไม่ชัด ตัวเลือกที่ขาดหาย และขั้นตอนอนุมัติที่ทำให้งานประจำล่าช้า เมื่อเจ้าหน้าที่ส่งมอบตามปกติได้โดยไม่ต้องใช้หมายเหตุแยกหรือสเปรดชีตอื่น จึงค่อยเพิ่มประเภทตัวอย่างหรือทีมถัดไป