เวิร์กโฟลว์และการนำไปใช้
จากข้อมูลย้อนหลังสู่เวิร์กโฟลว์จริง: คู่มือ 3 ขั้นตอนทำ Retrospective Batch Review
เครื่องยนต์ที่จัดกลุ่มได้ตรงทุกเคสยังไม่มีมูลค่า จนกว่าจะมีคนตอบได้ว่าเช้าวันจันทร์ควรเปิดเคสไหนก่อน นี่คือเวิร์กโฟลว์รันข้ามคืนที่เริ่มได้โดยไม่ต้องแตะ HIS และล้มแล้วรันใหม่ได้
- เจ้าหน้าที่ IT โรงพยาบาล
- นักสถิติข้อมูลสุขภาพ
- ผู้จัดการโครงการนำร่อง
เครื่องยนต์จัดกลุ่มที่ให้ผลตรงกับโปรแกรม Thai DRG ต้นฉบับทุกเคส ยังไม่มีมูลค่าใด ๆ ต่อโรงพยาบาล จนกว่าจะมีคนตอบคำถามข้อเดียวนี้ได้ว่า เช้าวันจันทร์ ผู้ลงรหัสหนึ่งคนควรเปิดเคสไหนก่อน ระยะห่างระหว่างสองเรื่องนี้ไม่ใช่เรื่องอัลกอริทึม แต่เป็นเรื่องเวิร์กโฟลว์ และเป็นจุดที่โครงการนำร่องส่วนใหญ่ตายลงอย่างเงียบ ๆ
คำตอบที่ใช้ได้จริงน่าเบื่อกว่าที่คาด ไม่ต้องเชื่อมต่อแบบเรียลไทม์ ไม่ต้องแก้ HIS ไม่ต้องรอผู้ผลิตระบบเดิมเปิด API สิ่งที่ต้องการมีเพียงไฟล์ส่งออกวันละหนึ่งไฟล์ งานประมวลผลที่รันตอนไม่มีใครทำงาน และคิวที่เรียงลำดับเสร็จแล้วเมื่อถึงเวลาเปิดออฟฟิศ
ทำไมต้องเริ่มด้วย batch ไม่ใช่การเชื่อมต่อแบบเรียลไทม์
เรียลไทม์ฟังดูก้าวหน้ากว่าเสมอ แต่สำหรับโครงการแรกมันผิดด้วยเหตุผลทางเทคนิคข้อเดียวที่ตรงไปตรงมา คือ ตัวแปรของสูตร AdjRW ยังไม่ครบจนกว่าผู้ป่วยจะจำหน่าย ทั้ง LOS และสถานะการจำหน่ายเป็นอินพุตโดยตรงของการคำนวณ การคำนวณระหว่างที่ผู้ป่วยยังนอนอยู่จึงให้ได้เพียงค่าประมาณที่ต้องคำนวณซ้ำอยู่ดี ในขณะที่ต้นทุนขององค์กรถูกจ่ายเต็มจำนวนตั้งแต่วันแรก
เชื่อมต่อเรียลไทม์ตั้งแต่โครงการแรก
- ต้องแก้หรือเปิด interface กับ HIS ซึ่งเป็นระบบที่ห้ามล้มในเวลาทำการ
- ผูกกับรอบปล่อยเวอร์ชันของผู้ผลิตระบบเดิม ซึ่งไม่ใช่ตารางเวลาของคุณ
- ยังไม่มี LOS และสถานะจำหน่ายที่แน่นอน จึงยังคำนวณ AdjRW สุดท้ายไม่ได้
- ถ้าประมวลผลผิด ต้องไล่แก้ทีละเคสระหว่างที่ระบบยังทำงานอยู่
- ขอบเขตข้อมูลกว้างขึ้นทันที เพราะต่อกับฐานข้อมูลผู้ป่วยโดยตรง
รันข้ามคืนแบบ batch
- อ่านอย่างเดียว ทางเดียว ไม่เขียนกลับเข้า HIS แม้แต่ฟิลด์เดียว
- ล้มแล้วรันใหม่ได้ทั้งรอบ โดยไม่มีใครเห็นและไม่มีงานค้างในระบบเดิม
- ทุกเคสในรอบจำหน่ายแล้ว ตัวแปรของสูตรจึงครบและคำนวณครั้งเดียวจบ
- ทีม IT ควบคุมได้ว่าฟิลด์ใดออกจากระบบไปบ้าง เพราะมันคือไฟล์เดียว
- ยกเลิกเมื่อไหร่ก็ได้ ด้วยการหยุดงานตามกำหนดเวลาหนึ่งบรรทัด
สามขั้นตอนของหนึ่งรอบการทำงาน
- 1
เตรียมและส่งออกข้อมูล
กำหนดชุดฟิลด์ให้แคบที่สุดเท่าที่สูตรต้องการ ตัดข้อมูลระบุตัวบุคคลออกตั้งแต่ต้นทาง แล้วตั้งให้ส่งออกอัตโนมัตินอกเวลาราชการ เฉพาะเคสที่ จำหน่ายแล้ว ในวันนั้น ขั้นนี้ใช้เวลาตั้งค่ามากที่สุด และกำหนดคุณภาพของอีกสองขั้นทั้งหมด
- 2
ประมวลผลและจัดลำดับความสำคัญ
จัดกลุ่มทุกเคสด้วยเกณฑ์เดียวกับที่ใช้เบิกจริง เทียบกับค่าที่ส่งเบิกไป แล้วเรียงลำดับด้วย ส่วนต่าง AdjRW ที่ตีเป็นเงินแล้ว ไม่ใช่ด้วยลำดับที่มาถึง ผลลัพธ์ต้องเป็นคิวที่มีลำดับ ไม่ใช่รายงานที่มีจำนวนหน้า
- 3
ทบทวนโดยคนและปิดลูป
ผู้ลงรหัสเปิดคิวจากบนลงล่างจนหมดเวลาที่จัดสรรไว้ต่อวัน ทุกเคสที่แก้ต้องบันทึกว่าใครแก้ด้วยหลักฐานใด และเคสที่ตัดสินใจ ไม่แก้ ต้องบันทึกเหตุผลเช่นกัน เพราะนั่นคือข้อมูลชุดเดียวที่จะทำให้รอบถัดไปคัดกรองแคบลงได้
ขั้นที่ 1: ไฟล์ที่ต้องส่งออก และกับดักที่ทำให้ผลเพี้ยนเงียบ ๆ
- รหัสวินิจฉัย
ICD-10พร้อมลำดับ: โรคหลัก (PDx) หนึ่งรหัส และโรคร่วมหรือโรคแทรก (SDx) ได้สูงสุด 12 รหัสต่อเคส - รหัสหัตถการ
ICD-9-CMทุกรายการของเคสนั้น พร้อมลำดับ - อายุ ณ วันรับเป็นปีเต็ม และสำหรับผู้ป่วยอายุต่ำกว่า 1 ปี ต้องมีวันเดือนปีเกิดจริงมาด้วย ไม่ใช่ส่งมาเพียงว่าอายุ 0 ปี
- เพศ ตามชุดรหัสที่ตกลงกันไว้ล่วงหน้าเพียงชุดเดียวตลอดไฟล์
- วันรับและวันจำหน่าย หรือค่า LOS อย่างใดอย่างหนึ่ง แต่ไม่ใช่ทั้งสองอย่างที่ขัดกันเอง
- สถานะการจำหน่าย ตามรหัสมาตรฐานที่ใช้ส่งเบิกอยู่แล้ว
- น้ำหนักแรกรับหน่วยกรัม สำหรับทารกแรกเกิดทุกราย
- รหัสอ้างอิงเคสที่สร้างขึ้นภายใน เช่น
CASE-00841ซึ่งแปลงกลับเป็น HN หรือ AN ได้เฉพาะในโรงพยาบาล - ค่า AdjRW ที่ส่งเบิกไปจริง เพื่อให้รู้ว่าส่วนต่างอยู่ตรงไหน ไม่ใช่รู้เพียงว่ามีส่วนต่าง
| ฟิลด์ | รูปแบบที่ปลอดภัย | กับดักที่พบบ่อย |
|---|---|---|
| รหัส ICD-10 | ตัวพิมพ์ใหญ่ ไม่มีจุด เช่น I500 | ไฟล์เดียวปนกันทั้ง I50.0 และ I500 เพราะมาจากคนละหน้าจอคนละปี |
| รหัส ICD-9-CM | เก็บเป็นข้อความ ไม่ใช่ตัวเลข | เปิดตรวจด้วยโปรแกรมตารางคำนวณแล้วบันทึกทับ 0331 กลายเป็น 331 |
| ลำดับการวินิจฉัย | คอลัมน์แยก PDX, SDX1 ถึง SDX12 | ยุบทุกรหัสไว้ช่องเดียวคั่นด้วยจุลภาค ลำดับซึ่งกำหนดโรคหลักหายไปพร้อมกัน |
| เพศ | ชุดรหัสเดียวตลอดไฟล์ | 1 กับ 2 ปนกับ M กับ F เพราะรวมข้อมูลมาจากสองระบบ |
| วันที่ | YYYY-MM-DD ปี ค.ศ. | พ.ศ. ปนกับ ค.ศ. และ 03/04/2026 ที่อ่านได้สองแบบโดยไม่มีอะไรฟ้อง |
| การเข้ารหัสอักขระ | UTF-8 ทั้งไฟล์ | TIS-620 จากระบบเดิม ทำให้ชื่อหอผู้ป่วยและหมายเหตุกลายเป็นอักขระเสีย |
| ขอบเขตของรอบ | เฉพาะเคสที่จำหน่ายแล้ว | เคสที่ยังนอนอยู่ถูกส่งออกมาด้วย แล้วถูกคิด LOS ผิด ทั้งที่ไฟล์นำเข้าสำเร็จ |
ในบรรดากับดักทั้งหมด รูปแบบวันที่แพงที่สุด เพราะ LOS ไม่ใช่ข้อมูลประกอบ แต่เป็นตัวแปรตรงในสูตร AdjRW ตาม Appendix H และสูตรนั้นแบ่งเป็นสาขาตามช่วงวันนอน ความคลาดเคลื่อนหนึ่งวันที่ตกบนรอยต่อจึงไม่ได้ทำให้ค่าเพี้ยนเล็กน้อย แต่ทำให้เคสเปลี่ยนสูตรที่ใช้คำนวณไปเลย
สาขาของสูตร AdjRW (Appendix H)
day case (<24 ชม.) AdjRW = RW0d
short stay AdjRW = RW0d + LOS × (RW - RW0d) ÷ ceil(WtLOS/3)
inlier AdjRW = RW
outlier AdjRW = RW + OF × b12 × (LOS - OT) ... จนถึงเพดาน
ตัวอย่างเชิงอธิบาย RW = 1.2000 RW0d = 0.4000 WtLOS = 6.0
ceil(WtLOS/3) = 2
LOS = 0 -> AdjRW = 0.4000 -> ฿2,840
LOS = 1 -> AdjRW = 0.4000 + 1×0.8000÷2 = 0.8000 -> ฿5,680
LOS = 2 -> AdjRW = 1.2000 (inlier) -> ฿8,520ขอบเขตข้อมูลตาม PDPA มาตรา 26
พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 26 จัดให้ ข้อมูลสุขภาพเป็นข้อมูลส่วนบุคคลอ่อนไหว ซึ่งโดยหลักต้องได้รับความยินยอมโดยชัดแจ้ง เว้นแต่เข้าข้อยกเว้นที่กฎหมายกำหนด เช่น เวชศาสตร์ป้องกัน การรักษาทางการแพทย์ หรือประโยชน์สาธารณะด้านสาธารณสุข การพึ่งพาข้อยกเว้นต้องให้ฝ่ายกฎหมายและ DPO พิจารณาเป็นรายกรณี แต่สำหรับโครงการนำร่องมีทางที่ตรงกว่า คือออกแบบให้ชุดข้อมูลที่ข้ามเส้นออกไประบุตัวบุคคลไม่ได้ตั้งแต่ต้นทาง
- 1De-identification ที่ต้นทาง ตัดชื่อ นามสกุล เลขบัตรประชาชน HN AN ที่อยู่ เบอร์โทร และบันทึกแพทย์ฉบับเต็มออกก่อนไฟล์จะถูกเขียนลงดิสก์ ไม่ใช่ตัดทีหลัง เหลือเพียงรหัสอ้างอิงที่โรงพยาบาลสร้างเอง และเก็บตารางแปลงกลับไว้ในโรงพยาบาลเท่านั้น
- 2ทางเลือกติดตั้งภายใน (on-premise) สำหรับโรงพยาบาลที่นโยบายไม่อนุญาตให้ข้อมูลออกนอกเครือข่ายแม้ในรูปที่ไม่ระบุตัวตน ควรถามผู้ให้บริการตรง ๆ ว่ารองรับหรือไม่ ตั้งแต่ก่อนเซ็นสัญญา ไม่ใช่ตอนจะขยายผล
- 3ข้อตกลงการประมวลผลข้อมูล ระบุให้ชัดว่าใครเป็นผู้ควบคุมข้อมูลและใครเป็นผู้ประมวลผล ขอบเขตการใช้ ระยะเวลาเก็บรักษา การลบเมื่อสิ้นสุดโครงการ และข้อห้ามนำข้อมูลไปใช้เพื่อวัตถุประสงค์อื่นรวมถึงการฝึกแบบจำลอง
ขั้นที่ 2: จัดลำดับด้วยเงิน ไม่ใช่ด้วยลำดับที่มาถึง
หนึ่งรอบให้ผลออกมาเป็นเคสจำนวนมาก และเกือบทั้งหมดไม่มีอะไรต้องแก้ คุณค่าของขั้นนี้จึงอยู่ที่ การตัดเคสที่ไม่ต้องดูออกไปให้มากที่สุดอย่างมีเหตุผลที่อธิบายได้ เพราะทรัพยากรที่จำกัดที่สุดคือเวลาของผู้ลงรหัส ไม่ใช่เวลาเครื่อง และส่วนต่างที่ใหญ่ที่สุดมักไม่ได้มาจากโรคร่วมที่ตกหล่นทีละข้อ แต่มาจากการเลือกโรคหลัก เคสตัวอย่างที่มีชุดวินิจฉัยเดียวกันคือ I10, I50.0 และ J18.0 ให้ AdjRW ต่างกันระหว่าง 0.9877 กับ 2.0261 หรือ +105% บนเคสเดียว และไม่มีทางแยกออกมาได้ด้วยสายตา
| ระดับ | ส่วนต่าง AdjRW | มูลค่าต่อเคส ที่ ฿7,100 ต่อ RW | สิ่งที่ทำ |
|---|---|---|---|
| A | ตั้งแต่ 0.50 ขึ้นไป | ตั้งแต่ ฿3,550 | ทบทวนทุกเคส โดยผู้ลงรหัสอาวุโส |
| B | 0.10 ถึง 0.49 | ฿710 ถึง ฿3,479 | ทบทวนตามกำลังคนที่มีในแต่ละวัน ไล่จากบนลงล่าง |
| C | ต่ำกว่า 0.10 | ต่ำกว่า ฿710 | ไม่ทบทวนรายเคส แต่เก็บสถิติไว้ดูแนวโน้มรายเดือน |
| E | จัดกลุ่มไม่สำเร็จ | ยังตีมูลค่าไม่ได้ | ส่งกลับทีม IT ให้แก้ที่ไฟล์ ไม่ใช่ให้ผู้ลงรหัสแก้ที่รหัส |
ขั้นที่ 3: คนทบทวน และการปิดลูปที่คนส่วนใหญ่ข้าม
กระบวนการเดิมที่ไล่จากแพทย์สรุปโรค ไปยังผู้ลงรหัส แล้วจึงถึงผู้ตรวจสอบ กินเวลาราว 20-30 วัน และเวลาส่วนใหญ่ไม่ได้หมดไปกับการตัดสินใจ แต่หมดไปกับการรอและการค้นหา สิ่งที่ batch เปลี่ยนได้จริงจึงไม่ใช่การแทนที่การตัดสินใจของคน แต่คือการย้ายการรอและการค้นหาออกไปจากเวลาทำการ
- ทุกข้อเสนอต้องมาพร้อมเหตุผลที่ตรวจสอบได้ ระบุว่าอ้างเกณฑ์ข้อใด และต้องมีหลักฐานอะไรในเวชระเบียนจึงจะใช้ได้ ข้อเสนอที่บอกเพียงว่าค่าจะสูงขึ้นเป็นข้อเสนอที่ผู้ทบทวนไม่ควรรับ
- การตัดสินใจไม่แก้มีค่าเท่ากับการแก้ ถ้าเหตุผลที่บันทึกซ้ำ ๆ คือระบบเสนอโดยไม่มีหลักฐานรองรับ แปลว่าเกณฑ์คัดกรองต้องแคบลง ไม่ใช่ผู้ทบทวนต้องขยันขึ้น
- ผลย้อนกลับต้องไปถึงผู้บันทึกต้นทาง ถ้าเดือนหนึ่งมี 40 เคสติดปัญหาเรื่องเดียวกัน ปัญหานั้นแก้ที่แบบฟอร์มสรุปการจำหน่าย ไม่ใช่ที่ผู้ลงรหัส
- รหัสที่แก้แล้วต้องถูกแก้ในระบบเดิม โดยผู้มีสิทธิ์ และมีร่องรอยที่ย้อนกลับมาตรวจสอบได้ว่าใครแก้ เมื่อใด ด้วยเหตุผลใด
เคสที่ระบบเสนอแล้วคนปฏิเสธ ไม่ใช่ความล้มเหลวของรอบนั้น มันคือข้อมูลชุดเดียวที่จะทำให้รอบถัดไปคัดกรองได้แคบลง
ตัวชี้วัดของโครงการนำร่อง และเกณฑ์ตัดสินใจว่าจะขยายผลหรือหยุด
371,163
เคสอ้างอิงที่ผลตรงกับโปรแกรม Thai DRG ต้นฉบับ
100%
DRG / RW / AdjRW ตรงกันทุกค่า
6.3.3
เวอร์ชันเกณฑ์ที่ใช้จัดกลุ่ม
20-30 วัน
ระยะเวลากระบวนการเดิมที่ใช้เป็นเส้นฐาน
- อัตราเคสที่จัดกลุ่มสำเร็จ ควรเข้าใกล้ค่าคงที่ภายในสองถึงสามสัปดาห์แรก ถ้ายังแกว่ง ปัญหาอยู่ที่ขั้นที่ 1 ไม่ใช่ขั้นที่ 3
- ความแม่นของคิว สัดส่วนเคสที่ถูกเสนอแล้วผู้ทบทวนเห็นด้วยและแก้จริง สำคัญกว่าจำนวนเคสที่ระบบเสนอทั้งหมด
- มูลค่าที่ยืนยันแล้ว ไม่ใช่มูลค่าที่ตรวจพบ นับเฉพาะเคสที่ผ่านการทบทวนโดยคนและถูกแก้ในระบบเดิมแล้ว ตัวเลขนี้เล็กกว่าที่ระบบรายงานเสมอ และเป็นตัวเดียวที่นำเสนอบอร์ดได้
- เวลาที่ผู้ทบทวนใช้จริงต่อเคส ถ้าไม่ลดลงเลยหลังผ่านไปหนึ่งเดือน แปลว่าเหตุผลประกอบที่ระบบให้มายังไม่ดีพอ
- ระยะเวลาตั้งแต่จำหน่ายจนส่งเบิก เทียบกับเส้นฐานของโรงพยาบาลเอง ไม่ใช่ค่าเฉลี่ยของที่อื่น
- ไม่มีข้อมูลระบุตัวบุคคลหลุดออกนอกขอบเขตแม้แต่ครั้งเดียว ข้อนี้ไม่ใช่ตัวชี้วัดที่เอาไปชั่งน้ำหนักกับข้ออื่น แต่เป็นเงื่อนไขที่ถ้าไม่ผ่านก็จบ
สิ่งที่ทำให้รูปแบบนี้ได้ผลไม่ใช่ความล้ำของสถาปัตยกรรม มันเป็นรูปแบบที่เก่าที่สุดรูปแบบหนึ่งในงานคอมพิวเตอร์ สิ่งที่ทำให้มันเหมาะกับงานนี้คือมันเคารพข้อจำกัดที่มีอยู่จริงของโรงพยาบาล คือ HIS ที่ห้ามล้ม ทีม IT ที่มีงานเต็มมือ ข้อมูลสุขภาพที่เป็นข้อมูลอ่อนไหวตามกฎหมาย และเวลาของผู้ลงรหัสที่มีจำกัดในแต่ละวัน เริ่มจากไฟล์เดียวและคิวเดียว ถ้าตัวเลขออกมาไม่คุ้ม คุณจะรู้ภายในไม่กี่สัปดาห์ ด้วยต้นทุนที่ต่ำพอจะยอมรับคำตอบนั้นได้
คำถามที่พบบ่อย
- Retrospective Batch Review ต่างจากการเชื่อมต่อระบบแบบเรียลไทม์อย่างไร
- Retrospective Batch Review คือการส่งออกข้อมูลเคสที่จำหน่ายแล้วเป็นไฟล์วันละครั้ง ประมวลผลนอกเวลาทำการ แล้วส่งผลกลับมาเป็นคิวเคสที่ควรทบทวนในเช้าวันถัดไป ต่างจากเรียลไทม์ตรงที่ไม่ต้องแก้หรือเปิด API เข้าระบบ HIS ไม่มีการเขียนข้อมูลกลับ และถ้ารอบใดผิดพลาดก็รันใหม่ได้ทั้งรอบโดยไม่กระทบงานประจำวัน อีกเหตุผลหนึ่งเป็นเรื่องเทคนิคล้วน ๆ คือ LOS และสถานะจำหน่ายซึ่งเป็นอินพุตของสูตร AdjRW จะครบถ้วนก็ต่อเมื่อผู้ป่วยจำหน่ายแล้วเท่านั้น
- การส่งข้อมูลเวชระเบียนออกไปประมวลผลขัดกับ PDPA หรือไม่
- พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 26 กำหนดให้ข้อมูลสุขภาพเป็นข้อมูลส่วนบุคคลอ่อนไหว ซึ่งโดยหลักต้องได้รับความยินยอมโดยชัดแจ้ง เว้นแต่เข้าข้อยกเว้นที่กฎหมายกำหนด เช่น เวชศาสตร์ป้องกัน การรักษาทางการแพทย์ หรือประโยชน์สาธารณะด้านสาธารณสุข แนวทางที่ตรงที่สุดสำหรับโครงการนำร่องคือทำ de-identification ที่ต้นทาง ตัดชื่อ เลขบัตรประชาชน HN AN และข้อมูลติดต่อออกก่อนสร้างไฟล์ เหลือเพียงรหัสอ้างอิงภายในที่แปลงกลับได้เฉพาะในโรงพยาบาล ควบคู่กับข้อตกลงการประมวลผลข้อมูล และควรให้ฝ่ายกฎหมายหรือ DPO พิจารณาก่อนเริ่มเสมอ
- ข้อมูลขั้นต่ำที่ต้องส่งออกมีอะไรบ้าง
- ต้องการรหัสวินิจฉัย ICD-10 พร้อมลำดับ โดยมีโรคหลักหนึ่งรหัสและโรคร่วมหรือโรคแทรกได้สูงสุด 12 รหัสต่อเคส รหัสหัตถการ ICD-9-CM อายุ เพศ วันรับและวันจำหน่ายหรือค่า LOS สถานะการจำหน่าย น้ำหนักแรกรับสำหรับทารกแรกเกิด และรหัสอ้างอิงเคสที่โรงพยาบาลสร้างขึ้นเอง ควรส่งค่า AdjRW ที่เบิกไปจริงมาด้วยเพื่อเปรียบเทียบส่วนต่างได้ ทั้งหมดนี้ไม่มีรายการใดที่ระบุตัวผู้ป่วยได้
- ควรเริ่มด้วยข้อมูลย้อนหลังกี่เดือน
- การประเมินเส้นฐานควรใช้ข้อมูลย้อนหลัง 12 เดือน เพราะครอบคลุมความผันผวนตามฤดูกาลของ case mix และมีจำนวนเคสมากพอจะแยกได้ว่าส่วนต่างมาจากรูปแบบที่เกิดซ้ำหรือมาจากเคสผิดปกติไม่กี่เคส หลังได้เส้นฐานแล้ว รอบการทำงานประจำจะกลับมาเป็นรอบข้ามคืนตามปกติ คือประมวลผลเฉพาะเคสที่จำหน่ายในวันนั้น
- จะรู้ได้อย่างไรว่าโครงการนำร่องควรขยายผลหรือควรหยุด
- ให้ยึดมูลค่าที่ยืนยันแล้ว ซึ่งหมายถึงส่วนต่าง AdjRW เฉพาะของเคสที่ผ่านการทบทวนโดยคนและถูกแก้ในระบบเดิมเรียบร้อยแล้ว ไม่ใช่มูลค่าที่ระบบตรวจพบทั้งหมด ขยายผลเมื่อมูลค่าที่ยืนยันแล้วต่อเดือนสูงกว่าต้นทุนรวมของระบบบวกเวลาคนที่ใช้ทบทวน อย่างต่อเนื่องอย่างน้อยสองเดือน โดยดูประกอบกับความแม่นของคิวและเวลาที่ผู้ทบทวนใช้ต่อเคส และมีเงื่อนไขที่ห้ามผิดพลาดคือต้องไม่มีข้อมูลระบุตัวบุคคลหลุดออกนอกขอบเขตที่ตกลงไว้เลย
แหล่งอ้างอิงและเอกสารที่เกี่ยวข้อง
- [1]คู่มือการจัดกลุ่มวินิจฉัยโรคร่วม (Thai DRG) ฉบับที่ 6.3 - Appendix H นิยามและสูตรคำนวณ AdjRW - สำนักงานกลางสารสนเทศบริการสุขภาพ (สกส.)
- [2]หลักเกณฑ์การจ่ายชดเชยค่าบริการผู้ป่วยในตามระบบ DRG - สำนักงานหลักประกันสุขภาพแห่งชาติ (สปสช.)
- [3]พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 26 ว่าด้วยข้อมูลส่วนบุคคลอ่อนไหวและข้อยกเว้น - ราชกิจจานุเบกษา
- [4]ICD-10-TM / ICD-9-CM มาตรฐานรหัสโรคและหัตถการที่ใช้ในระบบเบิกจ่ายของไทย - กระทรวงสาธารณสุข
Portfolio Review
อยากรู้ว่าตัวเลขของโรงพยาบาลคุณเป็นเท่าไหร่
เรานำเคส IPD ย้อนหลังของคุณมาจัดกลุ่มใหม่ทั้งหมด แล้วรายงานเป็น Leakage Baseline ที่กระทบยอดกับสิ่งที่เบิกไปจริงได้ - ไม่ใช่ค่าเฉลี่ยอุตสาหกรรม
อ่านต่อ
ถอดรหัส Thai DRG กับการจัดสรรงบผู้ป่วยใน: AdjRW, WtLOS และจุด Outlier Trim Point
งบผู้ป่วยในไม่ได้จ่ายตามค่าใช้จ่ายที่เกิดขึ้น แต่จ่ายตามสูตรที่มีขอบเขตชัดเจน บทความนี้กางสูตรจริงตามภาคผนวก H ให้เห็นทุกช่วง ตั้งแต่เคสวันเดียวจนถึงเพดานที่นอนต่อแล้วไม่ได้เงินเพิ่ม
ทำไม AdjRW ที่หายไป 0.05 ต่อเคส ถึงทำให้โรงพยาบาลสูญรายได้หลักล้านต่อปีโดยไม่รู้ตัว
ส่วนต่างเล็กน้อยระดับทศนิยมที่มองไม่เห็นในเคสเดียว เมื่อคูณด้วยจำนวนเคสทั้งปีและอัตราจ่ายต่อ RW กลายเป็นเงินหลักล้าน - และไม่มีบรรทัดไหนในงบการเงินที่จะฟ้องให้คุณรู้
เส้นแบ่งบางๆ ระหว่าง Upcoding กับ CDI: เพิ่มรายได้อย่างไรโดยไม่เสี่ยงถูกเรียกเงินคืน
ทั้งสองอย่างทำให้ AdjRW สูงขึ้นเหมือนกัน ต่างกันตรงที่อย่างหนึ่งรอดจากการตรวจสอบย้อนหลัง อีกอย่างหนึ่งไม่รอด - และสิ่งที่แยกมันออกจากกันไม่ใช่ตัวเลข แต่คือหลักฐานที่ชี้ได้ในเวชระเบียน