ลดเคลมติด C ตั้งแต่ต้นทาง: HIS ควรตรวจอะไร และช่วยทีมตามแก้อย่างไร

สิ้นวัน งานรักษาจบแล้ว แต่งานของทีมเคลมยังไม่จบ หน้าจอแจ้งว่ามีรายการ “ติด C” เจ้าหน้าที่ต้องเปิด HIS สลับกับระบบส่งเคลมและรายงานผล เพื่อหาว่าผิดตรงไหน ใครแก้ได้ และรายการที่ส่งใหม่ผ่านแล้วหรือยัง

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

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

ติด C เป็นผลตรวจที่ต้องตามสาเหตุให้เจอ

ในบริบทของบทความนี้ “ติด C” หมายถึงรายการที่ไม่ผ่านเงื่อนไขการตรวจตามผลตอบกลับที่เกี่ยวข้อง ต้องอ่านทั้งรหัส รายละเอียด ประเภทบริการ และสิทธิที่ส่ง ขณะที่ C, Deny และสถานะรอตรวจเอกสารต้องมีกระบวนการติดตามที่เหมาะกับแต่ละกรณี

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

บทความเน้นช่องทาง e-Claim ของ สปสช. และการส่งข้อมูลผ่าน FDH ไม่ใช้ตารางรหัสเดียวกันแทนทุกระบบของทุกผู้จ่าย รายละเอียดรหัส เงื่อนไข และกำหนดเวลาต้องตรวจจากคู่มือหรือประกาศที่ใช้กับบริการนั้น

ปัญหาที่หน้างานเจอ: มีข้อมูลแล้ว ทำไมยังต้องแก้ซ้ำ?

ข้อมูลอยู่ใน HIS แต่ไปไม่ถึงชุดส่งเคลม

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

แก้แล้ว แต่แต่ละระบบยังแสดงผลไม่ตรงกัน

รายงาน สถานการณ์ติด C จังหวัดแพร่ วันที่ 5 พฤศจิกายน 2567 มีกรณีสถานะ FDH กับ e-Claim ไม่ตรงกัน หาจุดแก้ใน HIS ยาก และมีข้อจำกัดหลังปิด Visit บางหน่วยบริการยังพบรายการที่ไม่ประสงค์เบิกปะปนกับงานรอแก้ด้วย กรณีเหล่านี้เป็นบทเรียนย้อนหลังสำหรับออกแบบกระบวนการ ไม่ได้ยืนยันว่าทุกระบบยังมีข้อจำกัดเดิมในปัจจุบัน

เห็นยอดรวม แต่ยังไม่รู้ว่าจะให้ใครทำต่อ

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

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

ก่อนส่ง e-Claim: HIS ควรช่วยตรวจอะไรบ้าง?

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

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

รายงานเขตสุขภาพที่ 4 ปี 2568 ยกตัวอย่างรหัส C305/C349 ด้านเลขอ้างอิงและ Authentication, C201 ด้านการวินิจฉัยหลัก, C515 ด้านรับ–ส่งต่อ, C562 ด้าน Drug Catalog และ C555 ด้านยอดรวมไม่ตรงรายการย่อย ตัวอย่างเหล่านี้ช่วยตั้งกลุ่มปัญหา แต่ไม่ใช่บัญชีกฎตรวจล่าสุดสำหรับทุกสิทธิ อ่านรายงานต้นทาง หน้า 7

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

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

แจ้งเตือนให้แก้ได้ และจัดคิวงานให้ถึงคนรับผิดชอบ

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

ตัวอย่างสมมติ: “ยังไม่พร้อมส่ง: ไม่พบเลขยืนยันการรับบริการในชุดข้อมูลส่งออก — ตรวจพบเลขใน HIS แล้ว ให้ทีมเชื่อมต่อข้อมูลตรวจการส่งออกและสร้างชุดข้อมูลใหม่” ข้อความนี้ต่างจากการสั่งให้เจ้าหน้าที่ไปขอเลขใหม่ทั้งที่มีอยู่แล้ว

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

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

หลังติด C: เทียบต้นทาง ชุดส่ง และผลตอบกลับให้เป็นรอบเดียวกัน

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

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

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

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

กฎตรวจต้องตามทันเงื่อนไข และข้อมูลต้องตรงกับบริการจริง

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

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

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

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

มีตัวอย่างผลลัพธ์ในไทย และควรวัดอะไรในโรงพยาบาลของเรา?

งานวิจัย โรงพยาบาลชัยนาทนเรนทร เผยแพร่ปี 2567 ศึกษาการใช้โปรแกรมร่วมกับกระบวนการตรวจข้อมูล โดยรายงานสัดส่วนข้อมูลติด C ต่อจำนวนการนอนโรงพยาบาล 16.14% ในปี 2565 และ 2.30% ในช่วงมกราคม–สิงหาคม 2566 เป็นผลก่อน–หลังในโรงพยาบาลเดียวและช่วงสังเกตยาวไม่เท่ากัน จึงใช้เป็นตัวอย่างการพัฒนา ไม่ใช่ผลที่รับประกันกับทุกแห่ง

งานวิจัย จังหวัดสกลนคร เผยแพร่ปี 2569 ครอบคลุม 18 โรงพยาบาลและผู้รับผิดชอบ 96 คน รายงานจำนวนข้อมูลติด C ลดลง 41.37% หลังพัฒนาระบบกำกับคุณภาพข้อมูล ขณะเดียวกันความพึงพอใจต่อ Dashboard อยู่ระดับปานกลาง สะท้อนว่าคุณภาพข้อมูลและความสะดวกในการใช้งานต้องติดตามแยกกัน

สำหรับการเริ่มโครงการในโรงพยาบาล ควรเก็บข้อมูลตั้งต้นและตกลงนิยามตัวชี้วัดร่วมกันก่อน เช่น

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

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

เริ่มจากปัญหาที่พบบ่อย แล้วทำให้จบวงจร

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

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

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

ทีม CK Doctor ยินดีหารือโจทย์งานเคลม การเชื่อมข้อมูล และกระบวนการติดตามรายได้ร่วมกับโรงพยาบาล โดยกำหนดขอบเขตและตรวจสอบความสามารถที่รองรับจริงก่อนเริ่มโครงการ ดูภาพรวม CK Doctor HIS

อ่านต่อ: Audit Log ของ HIS: ออกแบบให้ตอบได้ว่าใครเปลี่ยนอะไรและเพราะอะไร

แหล่งอ้างอิงและภาพประกอบ

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

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