เชื่อมต่อข้อมูลทางการแพทย์ด้วย Health Informatics Standard

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

การแพทย์ต่างๆ ตามไปที่โรงพยาบาลโดยอัตโนมัติ และหลายท่านคงสงสัย ว่าทาไมมันถึงไม่เกิดเสียที ทั้งๆ ที่เทคโนโลยีด้านการสื่อสารก็
พัฒนามาไกลแล้ว อุตสาหกรรมอื่นๆ ก็ส่งข้อมูลข้ามจังหวัด ข้ามประเทศได้ ไม่เห็นมีปัญหา ทาไมใน Healthcare ถึงทาแบบเดียวกันไม่ได้
เสียที?
การส่งข้อมูลระหว่างระบบไอทีที่ต่างกัน โดยหวังทั้งสองระบบนี้จะทางานประสานกันได้ถูกต้อง เรียกว่า Interoperability (ไม่ใช่
official definition) ซึ่งมีหลายระดับและมีความยากของมันอยู่ จึงเป็นที่มาของ blog นี้ (หากท่านใดสนใจในแง่ประโยชน์ของ Health
Information Exchange (HIE) แบบมี framework ให้ค้นคาว่า Learning Health System ดู)

โดยพอสรุปโดยสังเขป ดังนี้

 เราต้องมี standard เพื่อลดความจาเป็นในการ custom ระบบทุกครั้งเวลาเชื่อมต่อข้อมูลกันระหว่าง 2 ระบบ

 Interoperability มี 3 ระดับ ต่อกันเฉยๆ เรียก Foundational ต่อกันแบบมีโครงสร้างเรียก Structural (syntactic) ต่อกันแบบ
เข้าใจความหมายตรงกันเรียก Semantic
 HL7 v2 เป็น healthcare messaging standard ที่ใช้เยอะที่สุดในโลก
 จะไปถึง semantic interoperability ได้ต้องมี 1) reference information model 2) terminology/classification system
 SNOMED-CT เป็น medical terminology ที่ใหญ่ทสี่ ุดในโลก และใช้ในโปรเจคท์ต่างๆ มากมาย
 HL7 v3 มีส่วนประกอบหลัก 3 ส่วน (RIM, messaging, CDA) HL7 RIM เป็น information model, v3 messaging กะให้ใช้
แทน v2 แต่ล้มเหลว, HL7 CDA คนใช้พอสมควร ส่วนหนึ่งเพราะ Meaningful Use ดัน
 HL7 FHIR เป็นน้องใหม่ไฟแรง ที่ทุกคนคาดหวังว่าจะเป็น standard ของยุคหน้า
 OpenEHR เป็น architecture framework ที่ใช้เยอะในยุโรปและหลายๆ ประเทศ
 ผู้เขียนคิดว่า healthcare interoperability ในไทยคงอีกนานกว่าจะเกิด เพราะหลายๆ ปัจจัย
 SMEs และ Startups สาย healthcare ก็ดๆู เรื่องพวกนี้ไว้บ้างก็ดี แต่ยังไม่ได้เร่งด่วนว่าต้อง implement
1. ทาไมถึงต้องมี Standard

ระบบไอทีในทางการแพทย์มีตั้งแต่เล็กๆ เช่น ระบบที่ใช้ควบคุมอุปกรณ์การแพทย์บางอย่าง ระบบในแผนกต่างๆ เช่น ห้องตรวจ

ห้องยา x-ray ห้องแล็บ ไปจนถึงระบบใหญ่ๆ อย่างระบบโรงพยาบาล (Electronics Health Records – EHR) การที่เราจะเชื่อมต่อระบบ
สองระบบ จริงๆ ไม่ได้ยากมาก ก็ดูว่าแต่ละที่เก็บข้อมูลแบบไหนแล้วก็ตกลงกันว่าจะแลกเปลี่ยนข้อมูลกันอย่างไร
ปัญหาจะเริ่มเกิดขึ้นเมื่อเราต้องเชื่อมต่อระบบหลายๆ ระบบเข้าด้วยกัน ตั้งแต่ร ะดับภายในสถานพยาบาลเดียวกันและระหว่าง
สถานพยาบาล ความซับซ้อนจะยิ่งมากขึ้นเมื่อแต่ละสถานพยาบาลดันใช้ EHR คนละระบบ แบบนี้ทาให้เราต้องใช้ทรัพยากรเยอะในการ
เชื่อมต่อแต่ละครั้ง สมมติมีระบบใหม่จะเข้าสู่ตลาดก็ต้องมาต่อกับพวกระบบเดิมๆ ทีละอันอีก จานวนการเชื่อมต่อมากขึ้นทวีคูณตามจานวน
ระบบที่เราต้องเชื่อมต่อ

จึงเป็นที่มาว่าเราต้องมีมาตรฐานกลาง (Standard) แล้วทุกคนทาตาม Standard นั้น ชีวิตก็จะดี สังคมสงบสุข แต่การจะไปถึงจุด

นั้นได้นี่แหละครับคือความยาก

2. ระดับของ Interoperability

อันนี้ก็เป็นอีกเรื่องที่แต่ละตาราแต่ละค่ายแบ่งไม่ค่อยจะเหมือนกัน ส่วนตัวผู้เขียนชอบของ HIMSS ซึ่งจะแบ่งออกเป็น

1) Foundational interoperability: ระบบ 2 ระบบส่งข้อมูลถึงกันได้ แต่ส่งแล้วจะเป็นยังไงต่อไม่ต้องสนใจ

2) Structural interoperability: ระบบ 2 ระบบใช้ข้อมูลมีโครงสร้างที่เหมือนกัน
3) Semantic interoperability: ระบบ 2 ระบบ เข้าใจตรงกันว่าอีกฝ่ายหมายถึงอะไร
 1) Foundational interoperability

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

ว่ามี Foundational interoperability อันนี้ก็อาศัยเทคโนโลยีการสื่อสารต่างๆ

2) Structural interoperability

ถ้าโรงพยาบาล A กับโรงพยาบาล B ตกลงกันว่าจะส่งข้อมูลในโครงสร้างที่ตรงกัน เช่น เรียงลาดับตาม “ชื่อเต็ม: ตัวหนังสือ, อายุ:

ตัวเลข, เพศ: 0 กับ 1 ถ้าโรงพยาบาล A” ส่งไปว่า “ชื่อ: Rath, นามสกุล: Panyowat, อายุ: 30, เพศ: ชาย” แบบนี้โรงพยาบาล B จะ
สับสน แต่ถ้าส่งว่า “ชื่อเต็ม: Rath Panyowat, อายุ: 30, เพศ: 0” แบบนี้โครงสร้างตรงกัน ถือว่ามี Structural interoperability บางคน
ก็เรียกระดับนี้ว่า Syntactic interoperability (มาจากคาว่า syntax) จริงๆ level นี้ก็เหมือน grammar ในภาษา ก่อนจะพูดแล้วเข้าใจได้
ก็ต้องเรียงคาให้ถูกก่อน
 3) Semantic interoperability

ถ้าโรงพยาบาล A กับโรงพยาบาล B ส่งข้อมูลในโครงสร้างที่ตรงกันแล้ว และทั้งสองระบบเข้าใจความหมายตรงกัน เช่น

โรงพยาบาล A ส่งไปว่า “คนไข้เป็น coronary artery disease” สมมติว่าแม้ว่าปกติแล้ว EHR ของโรงพยาบาล B เรียกโรคนี้ว่า
Myocardial Infarction แต่ EHR ของโรงพยาบาล B ก็สามารถเข้าใจได้ว่า coronary artery disease หมายถึง Myocardial infarction
อันนี้คือมี Semantic interoperability

Semantic interoperability นี่ แหละเป็น Goal ของวงการ Health Informatics แต่มัน ยากตั้ งแต่ structural
interoperability โดยแต่ละ EHR อาจมีข้อมูลในฐานข้อมูลเป็นล้าน record ต้องมา custom ให้เข้ากับ standard ที่จะใช้เป็นโครงสร้าง
ข้อมูล หลังจากนั้นข้อมูลแต่ละอย่าง (หรือเรียก concept ในภาษา modeling) ก็ต้องไปผูก (bind) กับ standard กลุ่ม terminology
หรือ classification เพื่อให้ระบบอื่นๆ สามารถเข้าใจตรงกันได้ ซึ่ง healthcare เป็นเรื่องที่กว้างมาก concept จึงมีจานวนมหาศาล
(SNOMED-CT terminology มีมากกว่า 300,000 concept)

จริงๆ ยังมีวิธีการแบ่งระดับของ interoperability อื่นๆ อีก โดยหนังสือ Principles of Health Interoperability ก็แบ่งอีกแบบ
แต่ main idea เหมือนกัน โดยทุกแบบจะมี semantic interoperability แต่ level ที่ต่ากว่าแบ่งไม่เหมือนกัน หรืออาจมีการเพิ่ม level ที่
สูงกว่า semantic เช่น clinical interoperability เข้ามา (ก็คือเชื่อมต่อในระดับ workflow ของ 2 องค์กรประสานกันไปได้)

ต่อไปจะกล่าวถึง Standard ที่สาคัญๆ ที่จะทาให้เรามี interoperability ในระดับต่างๆ ได้สาเร็จ

3. HL7 v2

HL7 มาจากคาเต็มว่า Health Level 7 เป็นคาเรียกรวมๆ กลุ่มของ standard (คือมีหลาย standard อยู่ในกลุ่ม) ที่พัฒนาโดย
HL7 international ในสหรัฐอเมริกา ในบรรดา standard หลายๆ ตัวที่อยู่ในกลุ่ม ตัวที่ได้รับความนิยมและถูกพูดถึงบ่อยๆ ก็มี HL7 v2
(version 2), HL7 v3 (version 3) และล่าสุด HL7 FHIR

Logo ของ HL7 International

HL7 v2 เป็น standard ที่พัฒนาขึ้นมาในปลายยุค 80s ในยุคนั้นโรงพยาบาลต่างๆ ในอเมริกาเริ่มนาระบบ IT เข้ามาใช้ ตอนนั้น

ระบบที่เป็น monolithic (EHR ยักษ์ใหญ่ที่มีฟีเจอร์ทุกอย่าง) ยังไม่เป็น ที่นิยมนัก สิ่งที่โรงพยาบาลต่างๆ ทาก็คือการซื้อระบบเล็ก ๆ ให้
แผนกต่างๆ ใช้ ซึ่งแน่นอนว่า ปัญหาที่ตามมาคือระบบของแต่ละแผนกคุยกันไม่รู้เรื่อง จึงเกิดเป็นความพยายามในการสร้าง messaging
standard สาหรับการส่งข้อมูลนี้ขึ้นมา

คาว่า Health Level 7 มาจากการที่ตัว standard เป็น protocol ที่ทางานบน layer 7 ของ OSI model (Application layer
หรือก็คือระดับเดียวกับพวก HTTP, FTP, SMTP พวกนั้นแหละครับ) ตัว message ก็เป็นเหมือนภาพด้านล่าง รายละเอียดการทางาน
หลักๆ ก็คือ แต่ละบรรทัดเป็นตัวแทนของ segment (เช่น MSH ก็คือ message header) แต่ละ segment ก็จะมี field ย่อยๆ โดยแต่ละ
field ก็จะแยกกันด้วย

ตัวอย่าง HL7 v2 message (ภาพจาก Wikipedia)

HL7 v2 นี่ได้รับการ implement อย่างกว้างขวางจากฝ่ายต่างๆ กลายเป็น interoperability standard ที่ได้รับการ

implement มากที่สุดในโลก อย่างไรก็ดี เนื่องจากตอนที่สร้าง HL7 v2 นี้ขึ้นมา กระบวนการสร้างเป็นไปอย่างฉุกละหุกและขาดการ
วางแผนล่วงหน้า เป็น standard ที่ implement ได้ไม่ยากและ customize ได้เยอะ ซึ่งทาให้แต่ละผู้ผลิต software ทาการ customize
standard นี้ต่างกันไป แรกๆ ส่งแค่ transactional message หากันก็ไม่มีปัญหาอะไร เมื่อเวลาผ่านไปนานเข้า ความต้องการ
การแลกเปลี่ยนข้อมูลที่มากกว่าแค่ messaging ทาให้ HL7 v2 นี้ไม่ตอบโจทย์อีกต่อไป เราต้องการ standard ที่เชื่อมกันได้จริงๆ โดยไม่
ต้องมา customize ใหม่ทุกครั้ง จึงนาไปสู่การพัฒนา HL7 v3
 HL7 v2 ทาให้เกิดโครงสร้าง (structure) ของข้อมูลเมื่อแลกเปลี่ยนข้อมูลกัน หรือก็คือ HL7 v2 เป็น standard ที่ทาให้เกิด
structural (syntactic) interoperability (จริงๆ มันมี some degree ของ semantic ได้ด้วย)

4. แล้วจะไปถึง Semantic Interoperability ได้อย่างไร

ก่อนจะไปถึง HL7 v3 ผมอยากเกริ่นซักนิดก่อนว่าเราจะทาให้เกิด Semantic Interoperability ได้อย่างไร จากตัวอย่างที่ยกมา

ก่อนหน้านี้ การทาให้ระบบ 2 ระบบเข้าใจความหมายของ “คาศัพท์” (terms) ที่ต่างกันได้ตรงกัน (เช่น coronary artery disease กับ
Myocardial Infarction) terms ทั้ง 2 terms นั้นก็ต้องผูกเข้ากับ “คาศัพท์กลาง” คาเดียวกัน คาศัพท์กลางนี้ เป็นหน้าที่ของ
terminologies (เช่น SNOMED-CT) และ classification systems (เช่น ICD, LOINC)

นอกเหนือจากความเข้าใจคาศัพท์ที่ตรงกันแล้ว ยังมีอีกมุมหนึ่งคือการเข้าใจความสัมพันธ์ของข้อมูลต่างๆ เช่น “นาย A เป็นคนไข้

เข้ารับการรักษาวันที่ 25 เมษายน ที่คลินิกโรคหัวใจ กินยาแล้วมีความดันตก” ข้อมูลชุดนี้ประกอบด้วยข้อมูลย่อยมากมาย “นาย A”
“คนไข้” “25 เมษายน” “คลินิกโรคหัวใจ” ฯลฯ ซึ่งแต่ละข้อมูลมันมีความสัมพันธ์ระหว่างกันอยู่ การจะถ่ายทอดความสัมพันธ์เหล่านี้ข้ าม
ระบบได้ เราต้องมี model สาหรับการอ้างอิงความสัมพันธ์ของข้อมูลต่างๆ หรือเรียกว่า Reference Information Model ซึ่ง standard
ที่ช่วยเราเรื่องนี้ชื่อว่า HL7 RIM และ OpenEHR (ซึ่งทั้ง 2 ค่ายก็ implement ต่างกันอีก)

สรุป 2 อย่างที่ต้องมีถ้าจะให้ระบบ “เข้าใจตรงกัน” ได้ คือ

1) Reference Information Model

2) Terminologies/classification systems

ทั้ง 2 อย่างนี้เป็นการอธิบายของผู้เขียนเอง แต่ถ้าเป็น ISO/TR 20514 จะแบ่งเป็น 4 อย่าง ผู้ที่สนใจลองดูเพิ่มเติมได้

 นอกจากนี้มีประเด็นเสริมในเรื่องที่คนมักเข้าใจผิดเล็กน้อย คือหลายๆ standard สามารถอยู่ร่วมกันได้ เช่น เราไม่ต้องเลือก
ระหว่าง HL7 กับ SNOMED-CT เพราะมันทางานด้วยกันได้ เช่นเดียวกับที่เราก็สามารถใช้ SNOMED-CT ไปพร้อมๆ กับ LOINC, ICD,
classification อื่นๆ ได้

5. Terminologies และ Classification Systems

terminology, nomenclature, vocabulary และ classification system สรุปง่ายๆ ก็คือ เป็นคล้ายๆ สมุดหน้าเหลืองที่บอก
ว่า ร้า นนี้เ บอร์ โ ทรอะไร อยู่ห มวดไหน อั น นี้ก็ คื อข้ อ มูล ที่ เราสนใจใช้ code อะไร อยู่ ในกลุ่ ม ไหน เป็ นต้ น terminologies และ
classification ที่ควรรู้จักมีดังนี้

1) International Classification of Disease (ICD)

อันนี้คนที่ทางานสายสุขภาพทุกคนน่าจะรู้จักดีอยู่แล้ว สั้นๆ ก็คือเป็นการ classify โรคของ WHO เพื่อประโยชน์ในการวัดอัตรา

การป่วย (morbidity) และอัตราการตาย (mortality) ของโรคต่างๆ ในแต่ละประเทศ ในบางประเทศ (เช่น ไทย) ยังใช้เป็นส่วนประกอบใน
การคานวณการเบิกจ่าย (reimbursement) ให้สถานพยาบาลต่างๆ
ICD ล่าสุดคือ ICD-10 (ICD-11 วางแผนจะนามาใช้ในปี 2018) แต่ละประเทศก็จะ implement ให้เป็นเวอร์ชั่นของตัวเอง และ
อาจไม่ได้ตาม ICD ทัน (เช่น ใน U.S. ก็ใช้ ICD-9 อยู่นานมาก)
ICD-10 เป็น classification ที่เหมาะสาหรับงานทาง public health และการ claim แต่ไม่เหมาะสาหรับใช้ในทาง clinical ด้วย
หลายๆ เหตุผล

2) SNOMED-CT
SNOMED-CT เป็น medical terminology ที่ใหญ่ที่สุดในโลก พัฒนาโดยองค์กรชื่อ SNOMED international (ชื่อเดิม IHTSDO) โดย
SNOMED-CT เป็น concept-oriented terminology (จะเข้าใจได้อาจต้องเข้าใจเรื่อง conceptual modeling ก่อน)

Core components ของ SNOMED-CT ประกอบด้วย

 Concepts: ปัจจุบันมากกว่า 300,000 concept

 Descriptions: คาอธิบายของ concept นั้น โดย 1 concept มีได้หลาย description ปัจจุบันมีมากกว่า 1 ล้าน descriptions
 Relationships: ความสัมพันธ์ระหว่าง concept ต่างๆ ปัจจุบันมีมากกว่า 900,000 relationships
 ตัวอย่าง classic ของ SNOMED-CT concept ก็คือ Myocardial Infarction ครับ (คือคนที่สอนเรื่อง SNOMED-CT ชอบใช้ MI มา
เป็นตัวอย่าง ไม่รู้ทาไมเหมือนกันครับ) สีดาคือ concept ลูกศรคือ relationship ส่วน description ไม่ได้โชว์ในนี้

ภาพจาก ihtsdotools.org

ทั้งนี้หากผู้อ่านไม่ได้ทางานในสาย health IT อาจไม่ต้องสนใจว่ามันทางานยังไง key takeaway ก็คือ

 SNOMED-CT เป็น terminology ที่ใหญ่มาก และครอบคลุม concept แทบทุกอย่างในทางการแพทย์

 SNOMED-CT ได้รับการ implement ในหลายประเทศทั่วโลกเพื่อใช้ในงานต่างๆ
 หลายๆ standard ใช้ SNOMED-CT เป็นส่วนประกอบในการพัฒนา เช่น RxNorm (U.S.), AMT (Australia), dm+d (UK),
HKMTT (Hong Kong) ฯลฯ

SNOMED International SNOMED CT Browser ที่ http://browser.ihtsdotools.org/

 ปัญหาสาคัญของ SNOMED-CT คือความยากในการเรียนรู้และการ implementation หากสนใจเรียนรู้เพิ่มเติมเกี่ยวกับ
SNOMED-CT หาได้ที่ SNOMED CT E-Learning Server และหากท่านใดสนใจแนวคิดการออกแบบของ SNOMED-CT ลองศึกษาเพิ่มเติม
ได้ใน Desiderata for Controlled Medical Vocabularies in the Twenty-First Century ได้

3) LOINC

Logical Observation Identifiers Names and Codes (LOINC) เป็น terminology สาหรับผลการตรวจแล็บ และ clinical
observation (เช่น พวก EKG, vital sign) ใช้มากใน U.S. แต่ประเทศอื่นๆ อีก 160 กว่าประเทศก็ใช้ด้วยเหมือนกัน สาหรับประเทศไทย
ทาง THIS เองก็กาลังพยายามผลักดันให้ LOINC เป็น standard สาหรับ lab order ในไทย

ผู้เขียนเคยถาม อาจารย์บุญชัย ว่าในเมื่อมี SNOMED-CT อยู่แล้ว ทาไมคนถึงยังใช้ LOINC อยู่ อาจารย์ให้เหตุผลดังนี้

 LOINC เรียนรู้ง่ายกว่า implement ได้ง่ายกว่า และ LOINC ยังมี tool ให้ map กับ SNOMED-CT ได้
 LOINC เป็น pre-coordinate concept คือประกอบร่างมาให้แล้ว เช่น “Bilirubin.direct [Mass/volume] in Serum or
Plasma” ส่วน SNOMED-CT เป็นทั้ง pre ทั้ง post ถ้าเป็น post-coordination concept เราอาจต้องมาประกอบร่างเอง
“bilirubin” + “direct” + “plasma” เป็นต้นครับ ซึ่งนามาซึ่งความยาก
 LOINC ฟรี แต่ SNOMED-CT มีค่า license

Search LOINC ที่ https://search.loinc.org

4) Drug Code & Procedure Code

คือยาทุกตัว และหัตถการทุกอย่าง จะมี code ของมัน และต่างประเทศก็ใช้ standard ที่ไม่เหมือนกัน

 U.S. ใช้ drug code หลักตอนนี้คือ RxNorm ส่วน procedure code หลักๆ คือ Current Procedural Terminology (CPT)
 ของไทย drug code ปัจจุบันเรามี Thai Medicines Terminology จากทาง THIS ให้ใช้
6. HL7 v3

กลับมาที่ HL7 หลังจาก HL7 v2 ใช้ไปซักพักแล้วเกิดปัญหาไปต่อไม่ได้ ทาง HL7 international ก็เลยพัฒนา HL7 v3 ขึ้นมา
คราวนี้วางแผนดีๆ พยายามออกแบบให้ดี กะเอาให้ semantic interoperability เลย อย่างที่กล่าวไปก่อนหน้านี้ว่าการจะทาได้ต้องมี
reference information model สาหรับข้อมูลที่เกี่ยวข้อง ซึ่ง HL7 v3 ก็เลือกเดินทางนั้น เลยเกิดเป็น HL7 RIM ขึ้นมา ซึ่งเป็น model
สาหรับข้อมูลทุกอย่าง เผยแพร่ให้ใช้เมื่อราวปี 2005 (อธิบายเพิ่มคือ HL7 v3 เป็นกลุ่มของ standard นะครับ มีหลาย standard อยู่ในนั้น
ไม่ได้อยู่โดดๆ เหมือน HL7 v2)

HL7 RIM

แนวคิดหลักคือ จะแบ่งข้อมูลออกเป็น 5 class หลักๆ คือ Act, ActRelationship, Participants, Roles, Entities พวกนี้ รวมๆ
เรียกว่า RIM Backbone ข้อมูลทางการแพทย์ทุกอย่างก็จะ เป็น sub-class ของ class ใด class หนึ่งในนี้แหละ ในบาง class ก็มีการทา
terminology binding เพื่อ semantic interoperability

Class diagram ของ HL7 RIM

.
HL7 v3 messaging

HL7 แต่แรกเลยเกิดมาเพื่อเป็น messaging standard พอมาเป็น HL7 v3 ฟังก์ชั่นนี้ก็ยังอยู่ แต่ว่าเปลี่ยนจาก message แบบใน
v2 มาใช้เป็น XML-based message แทน โดยการสร้าง message ก็ต้องอ้างอิงจาก HL7 RIM ปัญหาก็คือ เนื่องจากความซับซ้อนของ
HL7 RIM เลยทาให้เกิดความยากในการ implement HL7 v3 messaging ตามมา ทาให้ไม่มีใครเปลี่ยนจาก HL7 v2 มาเป็น v3 สรุปก็
เลยตกไป

HL7 CDA

แม้ HL7 v3 messaging จะอ่อนแอก็แพ้ไป แต่ยังมีมรดกจาก HL7 RIM ที่ถือได้ว่าประสบความสาเร็จอยู่นั่นคือ HL7 Clinical
Document Architecture (CDA) เป็น standard ที่บอกว่า document ต่างๆ ทางการแพทย์มันควรเป็นอย่างไร document ในที่นี้ก็คือ
เอกสาร ยกตัวอย่างเช่น care plan, referral note, progress note พวกนี้คือ document ทั้งหมด

CDA document เป็น XML document ที่ใช้ HL7 RIM เป็นฐานในการให้ความหมายข้อมูลต่างๆ โดย HL7 CDA standard
แค่บอกว่า document ควรมีลักษณะอย่างไร แต่ไ ม่ได้บอกว่าจะส่ง document นั้นยังไง จะไปใช้ v3 messaging, v2 messaging,
ส่งผ่าน email, เซฟใส่ USB ส่งไปรษณีย์ หรืออะไรก็แล้วแต่เราเลย

CDA document เป็นระบบ incremental semantic interoperability คือ implement ได้ 3 level ถ้า level 1 ก็มีแค่
header ที่มี meta-data นิดหน่อย ที่เหลือเป็น narrative text ธรรมดา มนุษย์อ่านเข้าใจแต่ machine ไม่เข้าใจ ถ้า level 3 ตรง
narrative text นั้นก็จะไปอยู่ใน body ในรูปของ structured data และ entry จาก HL7 RIM (ซึ่งทาให้ machine สามารถเข้าใจเนื้อหา
ได้มากขึ้น) วิธีนี้ทาให้การ adopt standard ทาได้ง่ายขึ้น ถ้ากาลังน้อยก็เอาแค่ level 1 ถ้าเงินเยอะก็จัด level 3

ภาพจาก http://iehr.eu/knowledge/what-is-hl7-cda/

เนื่องจาก CDA เป็น standard กว้างๆ เวลาองค์กรต่างๆ จะนา CDA ไปใช้ในงานเฉพาะเจาะจง (เช่น จะเอาไปทา referral
note) จะต้องสร้าง template ขึ้นมาก่อน (constraint CDA) วิธีการนา CDA ไปใช้นี้เรียกว่า implementation guide ไปๆ มาๆ เกิด
implementation guide ขึ้นมามากมาย
 หลังรัฐบาล Obama ประกาศ HITECH Act และ Meaningful Use เรื่อง interoperability กลายเป็นเรื่องหนึ่งที่สาคัญ และ
ทาง ONC สนใจใช้ HL7 CDA เป็น standard สาหรับ clinical document ทาง HL7 เลยร่วมกับ CDA ทาการสังคายนาบรรดา
implementation guide ทั้งหลาย รวมเอามาแต่อันที่สาคัญๆ ออกมาเป็น Consolidated-CDA หรือ C-CDA

C-CDA กลายเป็น criteria หนึ่งในการที่ EHR นั้นจะได้รับการรับรองว่าผ่าน Meaningful Use stage 2 โดย CDA document
template ที่คนพูดถึงบ่อยคือ Continuity of Care Document (CCD) ซึ่งเป็นเอกสารสาหรับส่งต่อคนไข้เมื่อเปลี่ยนผู้ให้บริการทาง
การแพทย์ (providers)

7. HL7 FHIR

หลังจากความล้มเหลวของ HL7 v3 ในแง่ความยากในการ implement ทาง HL7 เลยคิดว่าต้องคิดใหม่ทาใหม่ (Make HL7

great again!) ช่วงปี 2011 เลยตั้งทีมใหม่ขึ้นมาเพื่อสร้าง standard ที่ตอบโจทย์สังคมมากขึ้น ก็เลยเกิดเป็น HL7 FHIR ขึ้นมา ซึ่งปรากฏว่า
ได้รับกระแสตอบรับที่ดีมาก และหลายคนตั้งความหวังว่านี่จะเป็น standard ของยุคหน้า

HL7 FHIR มีส่วนประกอบหลักๆ อยู่ 3 ส่วนคือ

1) Resources: หน่วยย่อยที่สุดของข้อมูล เช่น patient resource, allergy resource, family history resource เป็นต้น แต่ละ
resource ก็จะมีโครงสร้างว่ามีข้อมูลอะไรบ้างใน resource นัน้
2) References: ความสัมพันธ์ระหว่าง resources ต่างๆ เช่น medication resource ก็สัมพันธ์กับ condition resource,
patient resource, practitioner resource, เป็นต้น
3) Profiles: การนา resources ต่างๆ มาประกอบกันให้เอาไปใช้งานได้ เช่น จะสร้าง discharge summary ต้องใช้ resources
อะไรบ้าง ต้อง binding กับ terminology อะไร เป็นต้น

การเข้าถึงส่วนประกอบต่างๆ เหล่านี้จะทาผ่าน REST API เหมือนเว็บอื่นๆ เช่น ต้องการ patient resource ก็ GET request ไป
mydomain/Patient/id เป็นต้น อันนี้ทาให้ developer รู้สึกว่า HL7 FHIR เรียนรู้และ implement ได้ง่ายกว่า standard อื่นๆ

ปัจจุบัน HL7 FHIR เป็น release 3 อยู่ในสถานะ Standard for Trial Use (STD) ก็คือพร้อมให้องค์กรต่างๆ ลองเอาไปใช้ดู ก่อนจะ
ผ่านไปสู่ normative edition (เวอร์ชั่นสมบูรณ์) ต่อไป

สรุปก็คือ เป็น standard ที่ดูมีอนาคต สังคมคาดหวัง แต่มีความเสี่ยงถ้า implement ตอนนี้เลย เพราะยังไม่ใช่เวอร์ชั่นสมบูรณ์

8. OpenEHR

HL7 เป็นกลุ่มของ standard ที่ใช้ใน U.S. เป็นหลัก อาจมีบางอย่างที่ใช้ในต่างประเทศบ้าง เช่น HL7 RIM, หรือ HL7 CDA แต่
ในยุโรป, ออสเตรเลีย และทวีปอื่นๆ บางส่วน (ดูทั้งหมด) standard ที่ได้รับความนิยมคือ OpenEHR

OpenEHR เป็น architecture framework สาหรับ EHR (คล้ายๆ RIM) จริง ๆ แล้ว OpenEHR ไม่ใช่ standard (และไม่เคย
บอกว่าตัวเองเป็น standard) แต่แนวคิดของ OpenEHR เป็นสิ่งที่หลายๆ standard เช่น CEN/ISO EN13606 (EHR architecture
standard) ใช้เป็นต้นแบบในการพัฒนา standard รวมไปถึง national standard อื่นๆ เช่น Norwegian Clinical Knowledge
Manager

OpenEHR ใช้หลักการที่เรียกว่า Dual-model คือ มี information model 2 ส่วน คือ reference model และ archetypes
แนวคิดคือ ข้อมูลทางการแพทย์มีการเปลี่ยนแปลงบ่อย การผูกส่วนที่เป็นความรู้เข้ากับข้อมูล ทาให้ไม่เกิดความยืดหยุ่นในการเปลี่ยนแปลง
ดังนั้นต้องแยก 2 ส่วนนี้ออกจากกัน

ยกตัวอย่างเช่น

 Information model: เป็นหน่วยย่อยที่สุดของข้อมูล เช่น data type (text, number, time, ฯลฯ), data structure (table,
list, tree, ฯลฯ), EHR component (composition, section, entry, ฯลฯ)
 Archetype model: เป็น model สาหรับการจัดการความรู้ทางการแพทย์ เช่น Blood pressure model ก็จะประกอบด้วย
information model ที่เป็น number, time, subject ฯลฯ เมื่อนามาประกอบกันก็จะกลายเป็นฟิลด์ต่างๆ เช่น วัดได้เท่าไหร่
วัดอะไรบ้าง วัดท่านั่งหรือท่านอน วัดตอนหลับหรือตอนตื่น ฯลฯ บาง archetype ก็จะสามารถทา terminology binding ด้วย
ได้
 หลังจากนั้นก็นา Archetype มาประกอบกันเป็น template เช่น template ของประวัติคนไข้ก็จะประกอบด้วย archetype
history, archetype blood pressure, archetype physical exam ฯลฯ เอาหลายๆ template มาประกอบร่างกัน ก็จะกลายเป็น EHR
architecture ขึ้นมา

ทั้งนี้หากใครอยากลองดู OpenEHR Archetype ลองไปดูได้ที่ Clinical Knowledge Manger - http://www.openehr.org/ckm/

9. ที่เล่ามาทั้งหมดนี่เกี่ยวอะไรกับเมืองไทยไหม?

การผลักดันจากภาครัฐ ต้องบอกว่าการ adopt health informatics standard ในประเทศต่างๆ เท่าที่ผู้เขียนรู้จักมักจะต้องมีการ

ผลักดันบางอย่างจากภาครัฐ (กรณีที่ชัดเจนที่สุดก็ HITECH Act ) จริงๆ เรื่องนี้ในประเทศอุตสาหกรรม มีแรงผลักดันจาก 2 ปัจจัย คือ
1) Healthcare cost ที่สูงขึ้นเรื่อยๆ เขาเลยมีความคาดหวังว่า care co-ordination จะช่วยลด cost และเพิ่ม quality ซึ่งการที่จะ
ทาให้เกิด care-coordination ที่ดีได้ มันก็ต้องการ health information exchange
2) ความพร้อมทางเทคโนโลยีที่มีอยู่เดิม ทาให้เกิด EHR vendors จานวนมาก ใน U.S. มี certified EHR vendors มากกว่า 600
บริษัท (ข้อมูลปี 2016) ความหลากหลายขนาดนี้จึงต้องการ standard ในการเชื่อมต่อข้อมูลแน่นอน

ในขณะที่ในไทยเอง เรา adopt TMT ได้สาเร็จก็เป็นปัจจัยเรื่องเงิน เพราะค่ายากรมบัญชีกลางที่สูง ต้องการ tool บางอย่างมาติดตาม

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

Standard & interoperability เป็น 1 ใน building block ของ WHO-ITU eHealth strategy toolkit
 อีกปัจจัยหนึ่งก็คือ ขนาดในต่างประเทศเอง ประเทศอุตสาหกรรมส่วนใหญ่ก็ยังพูดได้ไม่เต็มปากว่าตนเองประสบความสาเร็จใน
การสร้าง semantic interoperability ดังนั้นไทยอาจไม่ทาอะไรจริงจังจนกว่าจะเห็น success case แบบจับต้องได้จากประเทศอื่นๆ
อย่างไรก็ดี ล่าสุดผู้เขียนเห็นยุทธศาสตร์เทคโนโลยีสารสนเทศสุขภาพ กระทรวงสาธารณสุข (2559-2563) ฉบับร่างเผยแพร่ออก
มาแล้ว จะมีเรื่อง standard & interoperability อยู่ในนั้นด้วย

ภาคเอกชน ถ้าจะมีซักองค์กรที่ดัน standard ให้เกิดได้แบบ de facto องค์กรนั้นก็ต้องเป็น BDMS เท่านั้น เพราะเกิดจู่ๆ มา

วันนึง บอกโรงพยาบาลในเครือ BDMS ทั้งเครือจะเปิดให้รับส่งข้อมูลคนไข้ได้ เช่น ผ่าน CDA (โดยคนไข้อนุญาต) ผู้เขียนว่าโรงพยาบาล
เอกชนอื่นๆ หรือดีไม่ดีโรงพยาบาลรัฐบาลด้วย ก็คง implement ตาม
ส่วน SMEs, startup สาย Healthcare ผู้เขียนเห็นว่าก็ดูๆ ไว้บ้าง อาจใช้ CDA หรือ OpenEHR มาเป็นไอเดียสาหรับ
architecture หรืออาจลองดูๆ FHIR ไว้ แต่ถามว่าเป็นเรื่องด่วนที่ต้องทาตอนนี้เลยไหม ตอบว่าไม่รอให้องค์กรใหญ่ๆ หรือภาครัฐเขาดัน
ก่อน รายเล็กค่อยตาม (ยกเว้นว่าทา global product)

ผู้สนใจหาข้อมูลเพิ่มเติม

 หนังสือ Principles of Health Interoperability: SNOMED CT, HL7 and FHIR โดย Tim Benson และ Grahame Grieve
 eBook Ehealth in Thailand : interoperability and health information standards โดยอาจารย์บุญชัยและคณะ
 SNOMED: Introduction to SNOMED CT ดูแค่ครึ่งแรกที่เป็นของ SNOMED-CT ก็ได้ครับ
 C-CDA: ONC clip มี 3 ตอน
 FHIR: เข้า Youtube เสิร์ชหาเลคเชอร์ที่ Grahame Grieve พูดครับ (เป็นคนริเริ่ม FHIR)
 HL7, OpenEHR, interoperability: Channel ของ Rene Spronk, Orion Health, Furore_com ชอบมี lecture น่าสนใจ

สรุป
 เราต้องมี standard เพื่อลดความจาเป็นในการ custom ระบบทุกครั้งเวลาเชื่อมต่อข้อมูลกันระหว่าง 2 ระบบ
 Interoperability มี 3 ระดับ ต่อกันเฉยๆ เรียก Foundational ต่อกันแบบมีโครงสร้างเรียก Structural (syntactic) ต่อกันแบบ
เข้าใจความหมายตรงกันเรียก Semantic
 HL7 v2 เป็น healthcare messaging standard ที่ใช้เยอะที่สุดในโลก
 จะไปถึง semantic interoperability ได้ต้องมี 1) reference information model 2) terminology/classification system
 SNOMED-CT เป็น medical terminology ที่ใหญ่ที่สุดในโลก และใช้ในโปรเจคท์ต่างๆ มากมาย
 HL7 v3 มีส่วนประกอบหลัก 3 ส่วน (RIM, messaging, CDA) HL7 RIM เป็น information model , v3 messaging กะให้ใช้
แทน v2 แต่ล้มเหลว, HL7 CDA คนใช้พอสมควร ส่วนหนึ่งเพราะ Meaningful Use ดัน
 HL7 FHIR เป็นน้องใหม่ไฟแรง ที่ทุกคนคาดหวังว่าจะเป็น standard ของยุคหน้า
 OpenEHR เป็น architecture framework ที่ใช้เยอะในยุโรปและหลายๆ ประเทศ
 ผมคิดว่า healthcare interoperability ในไทยคงอีกนานกว่าจะเกิด เพราะหลายๆ ปัจจัย
 SMEs และ Startups สาย healthcare ก็ดๆู เรื่องพวกนี้ไว้บ้างก็ดี แต่ยังไม่ได้เร่งด่วนว่าต้อง implement

ที่มา
รัฐ ปัญโญวัฒน์
Co-founder of Health at Home
A doctor, MSc Health Informatics student, front-end web developer, UI/UX designer, and cat lover
Link: https://rath.asia/2017/04/health-informatics-standard-101/