Srinagarind / SMC / Medical Hub

Reference HIS Prototype

Reference model · concept / vendor evaluation only

Srinagarind Smart HIS Reference Model

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

Reference Scope
0Patient data used
4Prototype views
6Core scenarios
JCI / HA-ITControl-oriented design

Why Separate Page

แยก “อนาคตของ HIS” ออกจาก “อดีตและช่องว่างของระบบเดิม”

หน้า War Room ใช้เล่า current state, สัญญาเดิม, gap และ roadmap ส่วนหน้านี้ใช้เป็น workshop canvas สำหรับออกแบบ HIS ที่ควรเป็นและใช้สอบ vendor แบบเป็นระบบ

Sandbox Reference only

Operating Model

เป้าหมายของ prototype นี้

เราไม่ได้สร้าง HIS เพื่อแทน vendor แต่สร้างแบบจำลองเพื่อเห็นโครงสร้างที่ควรถามหาในระบบจริง: ข้อมูลต้องไหลจากผู้ป่วยและ visit ไปสู่คำสั่งการรักษา ผลตรวจ ยา การเงิน ERP dashboard และหลักฐาน audit ได้

Patient / HN Encounter Orders Results Medication Billing / ERP Audit Evidence

Vendor Use

ใช้กับ vendor อย่างไร

ทุก scenario ในส่วนนี้ควรถูกแปลงเป็น demo script และ UAT case ให้ vendor สาธิตกับ workflow จริง โดยต้องเห็นหน้าจอ log ผู้รับผิดชอบ exception และรายงานที่ตรวจย้อนกลับได้

  • ถามว่าทำได้หรือไม่ และขอดูการทำงานจริง ไม่ใช่เฉพาะ slide
  • ขอ evidence: audit log, API spec, data dictionary, downtime procedure
  • ทดสอบ exception เช่น ผู้ป่วยผิดคน ยาซ้ำ critical result ค้างรับทราบ
  • ตรวจว่าข้อมูลต่อกับ ERP HR/Finance และ dashboard ได้โดยไม่ใช้ manual Excel เป็นหลัก

อ่านหน้านี้แบบไม่ใช่สาย IT

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

สิ่งที่ควรดูเวลา vendor สาธิต

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

คำถามหลักสำหรับแพทย์

ระบบนี้ลดภาระการพิมพ์หรือคลิกซ้ำได้จริงหรือไม่ เห็นข้อมูลคนไข้ครบพอสำหรับตัดสินใจหรือไม่ alert รบกวนเกินไปหรือไม่ และเมื่อเกิด critical result, allergy, ยาซ้ำ หรือ downtime ทีมรักษายังทำงานได้ปลอดภัยหรือไม่

Live HO UI Observation

บทเรียนจากหน้าจอ HO จริงที่ควรแปลงเป็น HIS รุ่นใหม่

จากการเปิดดูหน้าจอ HO จริงแบบ read-only พบว่า HO เป็น desktop ribbon application ที่มีเมนูหลัก Home, Departmental, Masters, Configuration และ Reports พร้อมข้อมูลผู้ใช้/หน่วยงาน ปุ่มค้นหา และ shortcut ของ workflow หลายกลุ่ม ข้อมูลนี้ใช้เป็น input เพื่อออกแบบ reference HIS ไม่ใช่การประเมินความถูกผิดของระบบเดิมทั้งหมด

Read-only No patient chart opened

สิ่งที่ควรรักษาไว้

  • มี role/location context ชัดเจน เช่น แพทย์ หน่วยงาน และจุดบริการที่กำลังใช้งาน
  • มี shortcut สำหรับ workflow สำคัญ เช่น appointment, patient list, order, ward view และ doctor workbench
  • มี search และ advanced search ซึ่งสำคัญต่อการทำงานเร็วในโรงพยาบาลขนาดใหญ่
  • แบ่งกลุ่มเมนูตามงาน เช่น OP, IP, A&E, master/configuration/report

สิ่งที่ควรอัปเกรด

  • เปลี่ยนจากเมนูจำนวนมากเป็น task-based workspace ตามบทบาทผู้ใช้
  • เพิ่ม patient context header ที่เห็นตัวตนผู้ป่วย สถานะ visit, allergy, critical alert และสิทธิ์สำคัญตลอดเวลา
  • ทำให้ปุ่มที่มีความเสี่ยงสูงมี guardrail เช่น confirmation, reason, audit และ role check
  • ทำให้ dashboard และรายงาน trace กลับ transaction ต้นทางได้ ไม่ใช่เพียงตัวเลขสรุป

สิ่งที่ควรใช้สอบ vendor

  • ระบบใหม่รองรับ workflow เดิมที่คนใช้อยู่จริงได้ครบหรือไม่ โดยไม่เพิ่มภาระคลิกเกินจำเป็น
  • หน้าจอทำงานของแพทย์รวม appointment, patient list, order, result, note และ follow-up ได้แค่ไหน
  • ถ้าเปิดหลาย module พร้อมกัน ระบบยังคุม patient context และ audit trail ได้หรือไม่
  • การค้นหาผู้ป่วย/visit/ผลตรวจมี security และ log เพียงพอหรือไม่
สรุปสำหรับทีมแพทย์: HIS ใหม่ไม่ควรเป็นเพียง “หน้าจอสวยกว่า HO” แต่ควรทำให้การทำงานเดิมเร็วขึ้น ปลอดภัยขึ้น และตรวจสอบย้อนหลังได้ดีขึ้น จุดสำคัญคือระบบต้องรู้เสมอว่า “ใครกำลังดูผู้ป่วยคนไหน ที่ visit ใด กำลังทำ action อะไร และมีความเสี่ยงอะไรที่ต้องเตือน”

Live HO Function Inventory

แผนที่ฟังก์ชันจากการสำรวจโปรแกรม HO จริง

ส่วนนี้สรุปจากการกดสำรวจหน้าจอ HO แบบ read-only เพื่อให้ทีมแพทย์และกรรมการโครงการเห็นว่า ระบบเดิมจัดงานอย่างไร และ HIS ใหม่ควรออกแบบให้ครอบคลุม workflow เดิมพร้อมยกระดับด้านความปลอดภัย audit, master data governance, interoperability และหลักฐาน JCI/HA-IT อย่างไร

Read-only UI walk-through No save / no order confirmation
วิธีอ่านสำหรับ non-tech: ชื่อแท็บคือกลุ่มงานหลักในโปรแกรม HO เดิม ส่วนรายการด้านในคือปุ่มหรือหน้าจอที่พบจากการสำรวจ เมื่อกดเปิดแต่ละกลุ่ม จะเห็นว่า workflow นั้นทำหน้าที่อะไร มีข้อสังเกตอะไร และควรแปลเป็น requirement ของ HIS ใหม่อย่างไร เพื่อไม่ให้ TOR เขียนเป็นแค่รายการ module แต่สะท้อนงานจริงของโรงพยาบาล

Data / FHIR Map

แผนที่ข้อมูลกลางที่ควรใช้คุย TOR และ integration

ตารางนี้ช่วยแปลงคำว่า module ให้เป็นข้อมูลจริงที่ระบบต้องมี เจ้าของข้อมูล มาตรฐานที่ควร map และหลักฐานที่ต้องขอจาก vendor

FHIR-ready Conceptual mapping
ความหมายแบบไม่เทคนิค: data map คือการตกลงกันก่อนว่า “ข้อมูลสำคัญของโรงพยาบาลอยู่ที่ไหน ใครเป็นเจ้าของ ใช้รหัสอะไร และส่งต่อไปส่วนอื่นอย่างไร” ส่วน FHIR ให้มองเป็นภาษากลางที่ช่วยให้ HIS, lab, x-ray, pharmacy, ERP และ dashboard คุยกันเป็นระบบมากขึ้น

DB-Rep / HealthObject Metadata Review

สิ่งที่ฐานข้อมูลเดิมบอกเราเรื่อง HIS ใหม่

สรุปนี้มาจากการอ่าน metadata ของ DB-Rep เท่านั้น ใช้เพื่อออกแบบ TOR, migration, data governance และ vendor demo ไม่ได้เปิดเวชระเบียนรายบุคคล และไม่แสดงจำนวนแถวของตาราง production บนหน้าเว็บ

Metadata only Reviewed 13 May 2026
1,516 User tables
22,486 User-table columns
149 Views
31 Functions
340 Tables without PK
0 Visible outgoing FK constraints
อ่านแบบผู้บริหาร: HealthObject ไม่ใช่แค่ฐานข้อมูลเวชระเบียน แต่เป็นฐานข้อมูลธุรกรรมโรงพยาบาลขนาดใหญ่ที่มี patient/visit, order, medication, billing, inventory, lab/result, provider และ interface/log ปะปนกันมานาน ดังนั้น HIS ใหม่ต้องถูกมองเป็นโครงการ data foundation และ workflow transformation ไม่ใช่การเปลี่ยนหน้าจอหรือซื้อ module ใหม่อย่างเดียว

ภาพรวมที่เห็นจาก schema

  • ตารางจำนวนมากสะท้อน workflow จริงหลายปี ทั้ง clinical, finance, inventory, appointment และ HR/provider
  • กลุ่ม patient/encounter มีอย่างน้อย 300+ ตารางจากการจัดกลุ่มตามชื่อ table
  • ตาราง order/medication และ billing/inventory เป็นแกนที่ต้อง map ให้ดีในการ migrate
  • มีตารางแนว history, backup, temp, sequence และ legacy object อยู่ใน namespace เดียวกัน

ความเสี่ยงเชิง data governance

  • relationship หลายจุดน่าจะพึ่ง application logic มากกว่า FK ใน database
  • ตารางไม่มี primary key บางส่วน อาจเป็น staging/sequence/legacy แต่ต้องจัดทะเบียนให้ชัด
  • audit columns มีแพร่หลาย แต่ต้องนิยามความหมายของ create, modify, sign, cancel, verify และ override ให้เป็นทางการ
  • หากไม่มี data dictionary และ lineage จะทำ dashboard, AI, migration และ accreditation evidence ได้ยาก

สิ่งที่ต้องแก้ใน HIS ใหม่

  • บังคับส่งมอบ data dictionary, ERD/logical model, API spec และ report definition catalog
  • แยก production transaction, staging, archive, temp และ analytics layer ให้ชัด
  • ใช้ governed API/HL7/FHIR/interface catalog แทนการพึ่ง direct database query เป็นหลัก
  • ผูก TOR และงวดงานกับ evidence: UAT, audit log, migration reconciliation, restore test และ workflow demo จริง
Reference / Other686 tables
Patient / Encounter308 tables
Orders / Medication140 tables
Inventory / Supply119 tables
Billing / Finance97 tables
Lab / Results56 tables
Audit / Interface / Log38 tables
Provider / User / HR33 tables
Appointment / Schedule26 tables
Radiology / Image13 tables

TOR must ask

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

Vendor must prove

workflow จริง, audit trail, interface retry/reconciliation, data migration mapping, KPI lineage และ downtime recovery evidence

Hospital must own

data dictionary, configuration, API/report definitions, export rights, migration reconciliation และ access/audit policy

Prototype Apps

หน้าจอจำลองที่ควรสร้างต่อ

ขั้นถัดไปควรเปลี่ยน reference model จากการ์ดอธิบาย เป็นหน้าจอจำลองที่แพทย์ พยาบาล IT และกรรมการสามารถกดทดลอง workflow ได้

สรุปสำหรับทีมคลินิก: หน้าจอจำลองเหล่านี้คือ “ตัวอย่างงานจริง” ที่อยากให้ HIS ใหม่ช่วย ไม่ใช่ข้อกำหนดเชิงเทคนิคอย่างเดียว ถ้าหน้าจอเหล่านี้ทำได้ดี จะช่วยลดงานซ้ำ ลดความเสี่ยงจากการสื่อสารตกหล่น และทำให้ข้อมูลสำหรับคุณภาพ/JCI/HA-IT เกิดจากการทำงานประจำวันโดยอัตโนมัติ

Voice-to-draft EMR

แพทย์พูดภาษาไทยปนอังกฤษ ระบบถอดเสียงเป็น draft note แพทย์ตรวจแก้ก่อน sign-off เป็นเวชระเบียนจริง

หลักควบคุมไม่ให้ AI สร้าง final note หรือ order โดยไม่มีแพทย์ยืนยัน

Patient Timeline

รวม visit, diagnosis, order, result, medication, admission, discharge และ billing event ในมุมมองเดียว

หลักควบคุมทุกจุดต้อง trace กลับ transaction ต้นทางและผู้รับผิดชอบได้

Critical Result Console

แสดงผล critical lab/radiology ที่ยังไม่รับทราบ พร้อมเวลาแจ้ง ผู้รับผิดชอบ escalation และ action ต่อ

หลักควบคุมต้องปิด loop ได้ ไม่ใช่แค่แสดงผลตรวจ

Voice-to-text EMR Workflow

ระบบบันทึกเวชระเบียนด้วยเสียงไม่ใช่แค่ Whisper แต่ต้องมี workflow ความปลอดภัยครบชุด

แนวทางนี้ใช้เป็น reference สำหรับคุยกับ vendor และทีมแพทย์ว่า voice-to-text ควรถูกออกแบบเป็นระบบช่วยร่างเวชระเบียน ไม่ใช่ระบบเขียนเวชระเบียนแทนแพทย์โดยอัตโนมัติ จุดสำคัญคือแยกบทบาทระหว่าง speech-to-text, LLM ที่ช่วยเรียบเรียง, clinical validation และการส่งเข้า HIS แบบมีหลักฐานตรวจสอบย้อนหลัง

Draft-first Doctor sign-off required
1

แพทย์พูด

บันทึกเสียงระหว่างตรวจ หรือกดอัดหลังตรวจ โดยต้องผูกกับผู้ป่วย/visit ที่ถูกต้องก่อนเริ่มอัดเสียง

2

ถอดเสียง

ใช้ speech-to-text เช่น Whisper หรือ model transcription รุ่นใหม่ เพื่อแปลงเสียงไทยปนอังกฤษเป็นข้อความดิบ

3

ทำความสะอาดข้อความ

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

4

LLM เรียบเรียง

ให้ LLM จัดเป็น SOAP note, progress note, discharge summary หรือ structured field โดยยังคงเป็น draft เท่านั้น

5

แพทย์ตรวจแก้

แพทย์ต้องเห็น transcript ต้นฉบับ เทียบกับ draft ที่ AI สรุป แก้ไขเอง และกดยืนยันก่อนเป็นเวชระเบียนจริง

6

ส่งเข้า HIS พร้อม audit

ระบบบันทึกผู้พูด เวลา version ประวัติการแก้ไข และผู้ sign-off โดยไม่ให้ AI สร้าง order จริงเองโดยไม่มีแพทย์ยืนยัน

องค์ประกอบที่ต้องมี

  • Microphone/app สำหรับอัดเสียงที่เลือก visit ถูกต้องและหยุดอัดได้ชัดเจน
  • Speech-to-text engine ที่รองรับไทยปนอังกฤษและศัพท์การแพทย์ แต่ต้องยอมรับว่ายังผิดได้
  • LLM สำหรับเรียบเรียง ไม่ใช่แค่ถอดเสียง เช่น แยก S/O/A/P, medication plan, follow-up และ patient instruction
  • Medical dictionary/local term list เช่น ชื่อยา ชื่อโรค ชื่อหัตถการ ชื่อแผนก และคำย่อของโรงพยาบาล
  • Review screen ที่แพทย์เห็น audio/transcript/draft พร้อมปุ่ม accept/edit/reject และ version history
  • Integration เข้า HIS เป็น draft note ก่อน แล้วค่อย sign-off เป็น official EMR

ต้นทุนที่ต้องคิด

  • ค่า transcription ตามจำนวนนาทีเสียง: อ้างอิง OpenAI ปัจจุบัน gpt-4o-mini-transcribe ประมาณ 0.003 USD/นาที และ gpt-4o-transcribe ประมาณ 0.006 USD/นาที
  • ค่า LLM สำหรับเรียบเรียงและตรวจโครงสร้าง คิดตามจำนวน token ของ transcript, prompt, output และจำนวนรอบแก้ไข
  • ค่า integration กับ HIS: mapping note type, encounter, provider, audit log, permission และระบบ draft/sign-off
  • ค่า security/compliance: encryption, retention policy, access log, PDPA review, consent policy และ data residency ถ้าจำเป็น
  • ค่า change management: training แพทย์, template รายสาขา, UAT, helpdesk และการวัดผลคุณภาพหลัง go-live
  • ค่า infrastructure: server/API gateway, storage เสียงชั่วคราว, monitoring, queue, backup และ failover

วิธีคุมงบ

  • เริ่ม pilot เฉพาะ OPD/สาขาที่มีภาระพิมพ์สูง ไม่เปิดทั้งโรงพยาบาลทันที
  • ตัดเสียงเงียบก่อนส่ง transcription และจำกัดความยาวต่อ note
  • ใช้ model เล็กสำหรับงานง่าย เช่น จัดรูปแบบ/สะกดคำ และใช้ model ใหญ่เฉพาะ case ซับซ้อนหรือ quality review
  • ใช้ template เฉพาะสาขาเพื่อลด token และลดการสรุปผิดบริบท
  • เก็บเสียงต้นฉบับเท่าที่จำเป็นตาม policy เพื่อลด storage และความเสี่ยง PDPA
  • วัด ROI จากเวลาพิมพ์ที่ลดลง คุณภาพ note และเวลาปิดเวชระเบียน ไม่วัดจากความว้าวของ AI อย่างเดียว

ข้อกำหนดสำหรับ TOR / Vendor demo

  • ให้ vendor สาธิตเสียงไทยปนอังกฤษจริง เช่น diagnosis, drug name, dose, lab value และแผน follow-up
  • ต้องแสดง confidence/uncertain phrase และวิธีให้แพทย์แก้ไขก่อน sign-off
  • ต้องพิสูจน์ว่า AI ไม่สามารถ submit order หรือ final note โดยไม่มีแพทย์ยืนยัน
  • ต้องมี audit log ครบ: ใครอัด ใครแก้ ใครยืนยัน เวลาใด และข้อความเปลี่ยนจากอะไรเป็นอะไร
  • ต้องมี test case สำหรับคำผิดที่เสี่ยงสูง เช่น ชื่อยาคล้ายกัน หน่วย dose ผิด และ negation เช่น “ไม่มีไข้”
  • ต้องตอบได้ว่าข้อมูลเสียง/transcript ถูกส่งออกนอกองค์กรหรือไม่ เก็บนานเท่าไร และลบอย่างไร
สรุปเชิงนโยบาย: voice EMR ควรถูกมองเป็น clinical documentation assistant ระดับ controlled pilot ก่อน ไม่ใช่ feature เสริมเล็ก ๆ ของ HIS เพราะความเสี่ยงไม่ได้อยู่ที่ถอดเสียงผิดอย่างเดียว แต่อยู่ที่การแปลความหมายผิด สรุปเกินจริง ใส่ negation ผิด หรือทำให้แพทย์ยืนยันข้อความโดยไม่ทันตรวจ ดังนั้นเงื่อนไขสำคัญที่สุดคือ draft-first, doctor-in-the-loop, audit ทุกเวอร์ชัน และห้าม action ทางการรักษาอัตโนมัติ

Clinical Sandbox

หน้าจอจำลอง workflow เพื่อใช้คุยกับแพทย์และ vendor

เลือก scenario ด้านซ้ายเพื่อดูว่าระบบ HIS รุ่นใหม่ควรแสดงข้อมูล ควบคุมความเสี่ยง และสร้างหลักฐานอย่างไร

Demo No real patient data

UAT Script Builder

สร้างร่าง UAT จาก scenario ที่เลือก

ใช้เป็น template สำหรับเปลี่ยน prototype เป็นเอกสารทดสอบจริง โดยระบุสิ่งที่ต้องใส่ สิ่งที่ต้องเห็น และหลักฐานที่ต้องเก็บ

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

Vendor Evaluation

วิธีใช้หน้านี้ในการประชุม vendor

ก่อน demo

เลือก scenario สำคัญ 5-10 รายการ แปลงเป็น script ระบุ input, expected output, log, owner และ evidence ที่ต้องเห็น

ระหว่าง demo

ให้ vendor ทำ workflow สดตั้งแต่ต้นจนจบ พร้อมทดสอบ exception เช่น alert, cancellation, downtime และ critical result

หลัง demo

ให้คะแนนตาม evidence จริง: workflow coverage, usability, safety control, interoperability, data ownership และ HA-IT resilience

Vendor Scorecard

แบบประเมิน vendor จาก evidence ที่พิสูจน์ได้

ใช้เป็นร่าง scoring framework สำหรับประชุม demo/UAT โดยคะแนนไม่ได้วัดว่า vendor พูดได้ดีแค่ไหน แต่วัดว่าพิสูจน์ workflow, safety, data และ continuity ได้จริงเพียงใด

0% Calculating

Comparison Matrix

พื้นที่เทียบ vendor หลายราย

ตอนนี้เป็น dummy matrix สำหรับเตรียมกรอบคิด ยังไม่ใช่คะแนนจริงของ IQVIA หรือ vendor ใด