ภาพตู้เวชระเบียนสีดำด้านส่งแถบกระดาษสามเส้นผ่านเครื่องคัดแยกไปยังแฟ้ม โดยมีแถบสีอำพันถูกแยกเข้าซองยินยอม
aillmhealthcaredata-governanceconnectors

ChatGPT for Healthcare ต่อ Epic และข้อมูลทางการ: Source-Connected ไม่เท่ากับเชื่อได้ทันที

น้องกายEngineering

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

OpenAI ประกาศเมื่อ 1 กันยายน 2026 ว่า ChatGPT for Healthcare เชื่อม authorized patient context จาก Epic ได้ และเพิ่ม Healthcare Public Data plugin สำหรับฐานข้อมูลทางการเก้าชุด เช่น PubMed, DailyMed, RxNorm, ClinicalTrials.gov และ CMS Coverage จุดเปลี่ยนสำคัญคือ AI เริ่มทำงานเหนือ source ที่องค์กรควบคุม แทนการตอบจากความจำของโมเดลอย่างเดียว

WHY: การต่อ Source ลดช่องว่างหนึ่งชั้น แต่เปิด Risk อีกหลายชั้น

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

การเชื่อม EHR ต้องรักษา authorization เดิมของระบบต้นทาง หากผู้ใช้เห็นเฉพาะหน่วยงานหนึ่ง connector ไม่ควรขยายให้ค้นทั้งโรงพยาบาล และ agent ไม่ควรเก็บข้อมูลจาก request แรกไว้ใช้ใน task ถัดไปโดยไม่ตรวจ scope ใหม่ หลัก least privilege ต้องครอบคลุม user, patient, field, time window และ action

สองทิศทาง สอง Threat Model

ประกาศอธิบายสองประสบการณ์: นำ EHR context เข้า ChatGPT เพื่อ review ประวัติและเตรียมนัด กับฝัง ChatGPT ในหน้า EHR โดยไม่ออกจาก chart แรกเหมาะกับการสังเคราะห์ข้าม source แต่ต้องระวัง context ค้างหรือแนบผู้ป่วยผิดคน ส่วนแบบฝังลดการสลับหน้าจอ แต่ต้องพิสูจน์ว่า identity และ chart ที่เปิดอยู่ถูกส่งเข้ามาทุกครั้ง

ทั้งสองแบบควรแยก read จาก write อย่างชัดเจน การสรุปข้อมูลเพื่อให้คนตรวจมีความเสี่ยงคนละระดับกับการเขียน note, เปลี่ยน medication หรือส่ง order หากเปิด action ภายหลัง ควรมี preview, explicit confirmation, field-level diff และ audit log ที่บอก source กับผู้อนุมัติ

Public Data ก็ต้องมี Version และ Provenance

Healthcare Public Data plugin ช่วย query record, field, identifier และ version จากฐานทางการ OpenAI ยกตัวอย่างการเทียบเกณฑ์ trial, ตรวจฉลากยา และดู coverage policy งานแบบนี้ควรให้ output พก source identifier, retrieved time และ version ไปด้วย เพราะ “ข้อมูลทางการ” ยังเปลี่ยนตามเวลา

อย่านำคำตอบสรุปไปเก็บโดยทิ้ง provenance เหลือเพียงข้อความ หาก policy เปลี่ยน เราจะตอบไม่ได้ว่ารายงานเก่าอิงฉบับใด รูปแบบที่ปลอดภัยกว่าคือแยก observation ที่ดึงจาก source, inference ของโมเดล และ decision ของมนุษย์เป็นคนละ field

อ่าน Evaluation อย่างมีขอบเขต

OpenAI รายงานว่าแพทย์ประเมิน 27 use case บน EHR context รวม 4,363 ratings และให้คำตอบ 99.1% ว่าปลอดภัย อีกการประเมินห้า connected sources ได้ความแม่นระดับ “good” ขึ้นไปมากกว่า 93% ทุก source ตัวเลขเหล่านี้เป็นหลักฐานเบื้องต้นจากผู้ผลิต ไม่ใช่ SLA ของโรงพยาบาลเรา และไม่ได้บอก performance ในภาษา, specialty, data quality หรือ workflow ทุกแบบ

ก่อน rollout ให้สร้าง local eval จากเคสที่ de-identify แล้ว ครอบคลุมอย่างน้อย medication conflict, note ที่ขัดกัน, ผลแล็บล่าสุด, chart ว่าง, สิทธิ์ไม่พอ และ prompt injection ในเอกสารต้นทาง วัดทั้งความครบ ความถูกต้อง citation การปฏิเสธเมื่อข้อมูลไม่พอ และเวลาที่ clinician ใช้ตรวจ

Gate สำหรับ Pilot

  • ทำ data-flow map ว่าข้อมูลใดออกจาก Epic ไปไหน เก็บนานเท่าไร และลบอย่างไร
  • ใช้ role-based access, SSO และ audit log พร้อมตรวจ configuration จริง ไม่ใช่อาศัยชื่อ product tier
  • แสดง source และ timestamp ใน UI ทุกคำตอบที่มีผลต่อการตัดสินใจ
  • บังคับ human review และห้ามสร้าง clinical order อัตโนมัติใน pilot
  • มีช่องรายงาน error, rollback และวิธีตอบผู้ป่วยเมื่อ AI summary ผิด

ประกาศระบุว่าลูกค้าที่มีข้อตกลง Business Associate Agreement ที่เหมาะสมสามารถตั้ง regulated workflow ได้ แต่ compliance ไม่ได้เกิดจาก connector เพียงตัวเดียว การตั้งค่า, process ขององค์กร และ vendor agreement ต้องสอดคล้องกัน

Recap

การเชื่อม Epic และฐานข้อมูลทางการทำให้ ChatGPT for Healthcare มี context และ provenance ที่ใช้งานจริงมากขึ้น แต่ทุก connector คือทั้งสะพานข้อมูลและขอบเขตสิทธิ์ใหม่ คุณค่าจึงขึ้นกับ least privilege, versioned citations และ human review พอ ๆ กับความสามารถของโมเดล

พรุ่งนี้หากกำลังวาง pilot ให้เลือก use case แบบ read-only หนึ่งงาน วาด data flow ตั้งแต่ผู้ใช้ถึง source และกำหนดหลักฐานที่ reviewer ต้องเห็นก่อนยอมรับคำตอบ นั่นคือจุดเริ่มที่ปลอดภัยกว่าการเปิดทุก connector พร้อมกันครับ