เชื่อมต่อข้อมูลทางการแพทย์ด้วย 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 ระบบ เข้าใจตรงกันว่าอีกฝ่ายหมายถึงอะไร

Foundational interoperability

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

Structural interoperability

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

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

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 นี่ได้รับการ implement อย่างกว้างขวางจากฝ่ายต่าง ๆ กลายเป็น interoperability standard ที่ได้รับการ implement มากที่สุดในโลก อย่างไรก็ดี เนื่องจากตอนที่สร้าง HL7 v2 นี้ขึ้นมา กระบวนการสร้างเป็นไปอย่างฉุกละหุกและขาดการวางแผนล่วงหน้า เป็น standard ที่ implement ได้ไม่ยากและ customize ได้เยอะ ซึ่งทำให้แต่ละผู้ผลิต software ทำการ customize standard นี้ต่างกันไป แรก ๆ ส่งแค่ transactional message หากันก็ไม่มีปัญหาอะไร เมื่อเวลาผ่านไปนานเข้า ความต้องการการแลกเปลี่ยนข้อมูลที่มากกว่าแค่ messaging ทำให้ HL7 v2 นี้ไม่ตอบโจทย์อีกต่อไป เราต้องการ standard ที่เชื่อมกันได้จริง ๆ โดยไม่ต้องมา customize ใหม่ทุกครั้ง จึงนำไปสู่การพัฒนา HL7 v3

 “when you have seen one implementation of v2, you have seen one implementation; everyone is different”

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 อย่างนะครับ ใครสนใจลองดูเพิ่มเติมได้ครับ 🙂 และการใช้คำว่า Reference Information Model นี่จริง ๆ ก็ไม่ถูกทั้งหมดนะครับ (คือถูกสำหรับ HL7 แต่สำหรับ OpenEHR จะเข้าใจคำนี้ต่างกันนิด)

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

.

5. Terminologies และ Classification Systems

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

.

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 ด้วยหลาย ๆ เหตุผลครับ

.

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 มาเป็นตัวอย่าง ไม่รู้ทำไมเหมือนกันครับ 55) สีดำคือ concept ลูกศรคือ relationship ส่วน description ไม่ได้โชว์ในนี้

ผมว่าถ้าไม่ได้ทำงานในสาย 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-CT คือความยากในการเรียนรู้และการ implement ครับ สนใจเรียนรู้เพิ่มเติมเกี่ยวกับ SNOMED-CT ได้ที่ SNOMED CT E-Learning Server และหากท่านใดสนใจแนวคิดการออกแบบของ SNOMED-CT ลองศึกษาเพิ่มเติมได้ใน Desiderata for Controlled Medical Vocabularies in the Twenty-First Century ครับ

.

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” เป็นต้นครับ ซึ่งนำมาซึ่งความยาก (ตัวอย่างเรื่อง bilirubin นี่แค่สมมติเฉย ๆ นะครับ)
• LOINC ฟรี แต่ SNOMED-CT มีค่า license

.

Drug Code & Procedure Code

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

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

เนื่องจากแต่ละเรื่องมีรายละเอียดที่ยาวมาก เลยได้แต่สรุปสั้น ๆ ครับ ไว้มีโอกาสผมอาจมาลงรายละเอียดใน terminologies ที่สำคัญ ๆ ใน blog ถัด ๆ ไปครับ 🙂

.

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

.

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

เนื่องจาก 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 ส่วนนี้ออกจากกัน (งงใช่ไหมครับ 555)

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

• 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 ฯลฯ (ชื่อ archetype นี่ผมสมมติเฉย ๆ นะครับ แต่หลักการคือตามนั้น) เอาหลาย ๆ template มาประกอบร่างกัน ก็จะกลายเป็น EHR architecture ขึ้นมา

สำหรับข้อเสียของ OpenEHR ทางฝั่ง HL7 community เขาโจมตีมาบ่อย ๆ นะครับ เนื่องจากผมยังไม่ค่อยเข้าใจเท่าไหร่ เลยขอข้ามไปก่อนละกันครับ :p (แต่ฝั่ง OpenEHR นี่ก็โจมตี HL7 บ่อย ๆ เถอะ 55) แต่ไม่ได้หมายความว่าเขาเป็นศัตรูกันอะไรนะ ก็มีหลายโปรเจคท์ที่เป็นความร่วมมือ

.

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 อื่น ๆ จะมีปัจจัยเรื่องเงินแบบนี้มาหนุนได้หรือเปล่า

อีกปัจจัยหนึ่งก็คือ ขนาดในต่างประเทศเอง ประเทศอุตสาหกรรมส่วนใหญ่ก็ยังพูดได้ไม่เต็มปากว่าตนเองประสบความสำเร็จในการสร้าง 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 น่าสนใจ

.

สรุป

ถึงแม้จะเป็น blog ที่ยาวมาก (อีกแล้ว) แต่จริง ๆ อันนี้แค่ Health Informatics standard 101 เท่านั้นนะครับ เป็นฟิลด์ที่กว้างและมีรายละเอียดเยอะมาก ผมก็ไม่ได้รู้เยอะกว่าใน blog นี้เท่าไหร่หรอกครับ 55 ไว้มีโอกาสมาเขียนเรื่องอื่น ๆ ที่เกี่ยวข้องต่อไปครับ 🙂

ส่วนสรุปเนื้อหา ขอก็อปยาวไปไม่อ่านมาเลยนะครับ

• เราต้องมี 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

---

UPDATE 2020:

บทความนี้เป็นบทความที่ผมเขียนตั้งแต่ปี 2017 แล้ว และเป็นมุมมองของผมในขณะนั้น ถ้าถามผมตอนนี้ ทั้ง IT vendor และ healthcare startup ควรเริ่มศึกษา health informatics standard ครับ อย่างน้อย ๆ ก็ FHIR อย่างน้อย ๆ เลยคือ มันทำให้คุณทำ solution ครั้งเดียว แต่ขายให้กับทุกสถานพยาบาลที่รองรับ FHIR เหมือนกันได้นะครับ อีกเรื่องคือ ถ้าลองศึกษาดูก็จะพบว่าจริง ๆ มันก็ไม่ได้ยาก

จริง ๆ ยังมีเหตุผลอื่น ๆ และมาตรฐานอื่น ๆ ที่น่าสนใจอีกหลายตัวครับ แต่คำแนะนำผมคือ อย่างน้อยลองศึกษาและนำ FHIR มาใช้ดูครับ

Interoperability