5 บทเรียนจากการบูรณาการระบบ EHR ข้ามพรมแดน
ฉันใช้เวลาหลายเดือนในการเชื่อมต่อระเบียนผู้ป่วยระหว่างสองประเทศที่แตกต่างกัน ฉันได้ทำงานร่วมกับ Lead Business Analyst ที่มีประสบการณ์ทางคลินิกถึงสิบปี แนวทางของเธอเปลี่ยนมุมมองที่ฉันมีต่อซอฟต์แวร์ด้านสุขภาพไปอย่างสิ้นเชิง
นี่คือห้าบทเรียนจากโปรเจกต์นั้น
- การทำ Terminology mapping ยากกว่าการทำ Data mapping
วิศวกรมักมองว่าการบูรณาการเป็นเพียงปัญหาเรื่อง schema คุณแค่จับคู่ฟิลด์ A เข้ากับฟิลด์ B ก็จบ แต่ในด้านสุขภาพ วิธีนี้ใช้ไม่ได้ผล
ระบบหนึ่งใช้ ICD-10 ในขณะที่อีกระบบใช้ ICD-11 ซึ่งไม่สามารถจับคู่กันได้อย่างสมบูรณ์ ระบบหนึ่งใช้ LOINC สำหรับผลแล็บ ในขณะที่อีกระบบใช้รหัสภายในแบบเก่า
BA ของเราสร้าง concept crosswalk ขึ้นมาก่อนที่เราจะเริ่มเขียนโค้ด เธอจับคู่รหัสท้องถิ่นเข้ากับชุดมาตรฐานอย่าง SNOMED CT หากไม่มีสิ่งนี้ ความหมายทางคลินิกของเราจะผิดเพี้ยนไป
การจับคู่ฟิลด์ที่ผิดพลาดทำให้เกิดค่าที่ผิด แต่การจับคู่คำศัพท์ (terminology mapping) ที่ผิดพลาดจะทำให้เกิดค่าที่ดูเหมือนจะถูกต้องแต่ผิดหลักคลินิก ซึ่งอย่างหลังนั้นอันตรายกว่ามาก
- กฎหมายข้อมูลกำหนดโครงสร้างสถาปัตยกรรมตั้งแต่เนิ่นๆ
ฉันเคยคิดว่าเราจะออกแบบโมเดลข้อมูลก่อนแล้วค่อยจัดการเรื่องการปฏิบัติตามกฎระเบียบ (compliance) ทีหลัง แต่ฉันคิดผิด
ข้อมูลผู้ป่วยที่ข้ามพรมแดนต้องเผชิญกับกฎหมายหลายฉบับ เช่น HIPAA หรือ GDPR บางประเทศสั่งห้ามไม่ให้ข้อมูลสุขภาพออกนอกพรมแดนของตน
BA ของเราทำงานร่วมกับทีมกฎหมายตั้งแต่เนิ่นๆ เธอตัดสินใจว่าฟิลด์ใดสามารถทำสำเนา (replicate) ได้ และฟิลด์ใดจำเป็นต้องทำ de-identification
สิ่งนี้เปลี่ยนสถาปัตยกรรมของเรา เราสร้าง federated query layer แทนที่จะใช้ฐานข้อมูลที่ทำสำเนาไว้ที่เดียว (single replicated database) และเราได้เพิ่มแท็กการจัดประเภทข้อมูล (data classification tags) ลงใน schema ของเราโดยตรง
เชิญผู้เชี่ยวชาญด้านการปฏิบัติตามกฎระเบียบและ BA เข้ามาร่วมประชุมก่อนที่คุณจะเริ่มออกแบบโมเดลข้อมูล
- มาตรฐานเพียงอย่างเดียวไม่เพียงพอ
ทั้งสองระบบรองรับ HL7 อย่างไรก็ตาม ระบบหนึ่งใช้ HL7 v2 ในขณะที่อีกระบบใช้ FHIR R4 ทำให้ไม่สามารถสื่อสารกันได้หากไม่มีเลเยอร์การแปลข้อมูล (translation layer)
แม้แต่ภายใน FHIR เรายังพบปัญหาความไม่สอดคล้องของโปรไฟล์ (profile mismatches) ทั้งสองระบบอ้างว่าปฏิบัติตามมาตรฐาน แต่กลับใช้คู่มือการนำไปใช้งาน (implementation guides) ที่แตกต่างกัน
อย่าทึกทักเอาเองว่าการบูรณาการจะเป็นเรื่องง่ายเพียงเพราะระบบรองรับมาตรฐาน ให้ถามถึงเวอร์ชันและโปรไฟล์ที่เฉพาะเจาะจงเสมอ และควรเผื่อเวลาสำหรับเลเยอร์ตัวปรับเปลี่ยน (adapter layer) ด้วย
- แผนภาพเวิร์กโฟลว์ช่วยตรวจพบกรณีขอบ (edge cases) ที่ซ่อนอยู่
เมื่อก่อนฉันเคยมองว่าแผนภาพเวิร์กโฟลว์เป็นเพียงเอกสารส่วนเกิน แต่ฉันคิดผิด
BA ของเราทำแผนผังการส่งต่อผู้ป่วยอย่างละเอียด เธอพิจารณาสิ่งที่จะเกิดขึ้นเมื่อผู้ป่วยย้ายระหว่างการรักษา หรือเมื่อผลแล็บมาถึงหลังจากผู้ป่วยออกจากโรงพยาบาลแล้ว
สิ่งเหล่านี้ไม่ใช่กรณีขอบ (edge cases) ในโรงพยาบาล แต่มันเกิดขึ้นทุกวัน
แผนภาพเหล่านี้เปลี่ยนโมเดลข้อมูลของเรา เราได้เพิ่มแนวคิดเรื่องช่วงเวลาการดูแล (care episode) เพื่อติดตามการดูแลที่ต่อเนื่องระหว่างทั้งสองระบบ
- สร้างพจนานุกรมคำศัพท์ส่วนกลางตั้งแต่เนิ่นๆ
คำอย่าง encounter หรือ discharge มีความหมายต่างกันในแต่ละระบบ เราเสียเวลาไปมากเพราะทีมตีความคำศัพท์ต่างกัน
BA ของเราสร้างพจนานุกรมคำศัพท์ส่วนกลาง (shared glossary) ขึ้นมา ผู้มีส่วนได้ส่วนเสียทุกคนได้ตรวจสอบและยอมรับคำนิยามเหล่านี้ และเราได้อ้างอิงเอกสารนี้ในทุกๆ ข้อกำหนด (requirement)
ให้สันนิษฐานไว้ก่อนว่าคำศัพท์เฉพาะทางทุกคำอาจมีความคลุมเครือ และกำหนดนิยามไว้ในเอกสารที่มีทั้งสองฝ่ายลงนามรับรอง
Summary
BA ที่เก่งทำได้มากกว่าแค่การเขียน ticket พวกเขาทำหน้าที่เป็นสถาปนิกสำหรับข้อจำกัดด้านกฎระเบียบและความหมายทางคลินิก หากคุณกำลังสร้างซอฟต์แวร์ที่ซับซ้อน อย่ามองว่าบทบาทนี้เป็นภาระส่วนเกิน เพราะมันจะช่วยป้องกันไม่ให้ความสำเร็จทางเทคนิคกลายเป็นความล้มเหลวทางคลินิก
Optional learning community: https://t.me/GyaanSetuAi