Health Informatics

วิธีการใช้ประโยชน์จากข้อมูลสุขภาพที่ผูกกับ SNOMED CT

21 September 2021

อ่านเอกสาร Data Analytics with SNOMED CT นี้มาครับ รู้สึกว่ามีประเด็นน่าสนใจหลายเรื่อง จึงสรุปไว้อ่านเองและถือโอกาสแชร์ด้วย

โจทย์ที่ผมต้องการอยากทราบก็คือ ถ้าหากเราสามารถเก็บข้อมูลสุขภาพโดยผูกกับ SNOMED CT code ไว้แล้ว เราจะใช้ประโยชน์จากข้อมูลเหล่านี้ได้มากกว่าการเก็บข้อมูลวิธีอื่น ๆ อย่างไร ? ซึ่งในเอกสารก็มีอธิบายไว้ 6 วิธี

  1. Subsets
  2. Subsumption
  3. Using defining relationships
  4. Description logic over terminology
  5. Description logic over terminology and structure
  6. Using statistical classifications

เพื่อไม่ให้ซับซ้อนเกินไป ผมจะไม่ใช้ Expression Constraint Langauge (ECL) ของ SNOMED CT ในการอธิบายครับ แต่จะแปลงเป็น term แบบธรรมดา ๆ เลย เช่น แทนที่จะเขียน “75570004 |viral pneumonia|” ก็เขียน “viral pneumonia” ตรง ๆ เลย

1. Subsets

ยกตัวอย่างเช่น หาคนไข้ที่มี diagnosis อยู่ใน set ของ ‘kidney disease codes’

  • การสร้าง subset ทำได้ 2 แบบคือ
    1. extensional – ก็คือการเลือก code มาใส่ set แบบ manual ซึ่งใช้แรงงานเยอะ และมีโอกาสพลาดสูง
    2. intensional – การใช้ query เป็นตัวสร้าง set ข้อดีคือเมื่อ SNOMED CT ออก release ใหม่ ก็สามารถ recompute สมาชิกใน set ได้โดยไม่ต้องไปแก้แบบ manual เหมือนวิธี extensional
  • การสร้าง extensional subset สามารถทำได้โดย การสร้าง Simple reference set หรืออาจใช้ Ordered reference set หรือ Annotation reference set หากต้องการรายละเอียดเพิ่มเติม
  • การสร้าง intensional subset ทำได้โดยการสร้าง Query specification reference set ซึ่งสามารถรันคำสั่ง query ได้หลายคำสั่ง และสามารถรวมเอา codes จาก subset อื่นมาด้วยได้

ในเอกสารจะยกตัวอย่างการสร้าง intensional subset โดย query จาก concept ที่เป็น descendants (และให้ include ตัวมันเอง) ของ concept ID 58437007 (tuberculosis of meninges) จะเห็นว่ามี term เช่น “Tuberculous leptomeningitis” รวมอยู่ใน set ด้วย ซึ่งถ้าเรา search โดยใช้คำ keyword เช่น “tuberculosis” + “meninges” แบบธรรมดา ๆ ก็คงไม่มีคำนี้ขึ้นมาในผลการค้นหา

หมายเหตุเล็กน้อย: ในเอกสารพบ 4 concepts แต่ผมลองรัน ECL จริง ๆ พบ 5 concepts

ภาพ capture จาก SNOMED CT Browser

2. Subsumption

ยกตัวอย่างเช่น ค้นหาคนไข้ที่มี diagnosis เป็น subtype ของ ‘kidney disease’

  • subsumption testing คือการตรวจว่า concept หรือ expression ใด ๆ เป็นประเภทเดียวกันกับอีก concept/expression หรือไม่
  • สำหรับการตรวจสอบ concept ทำได้โดยดูว่ามี is-a relationship หรือเปล่า เช่น “viral pneumonia” “is a” “infectious disease” ดังนั้น “infectious disease” subsumes “viral pneumonia”
  • สำหรับการตรวจสอบ expression ต้องมีการกำหนด candidate expression (expression ที่ต้องการจะทดสอบ) และ predicated expression (expression ที่จะเอา candidate มาทดสอบ
    • เช่น candidate คือ “viral pneumonia” ทดสอบกับ predicated คือ “infectious disease” ซึ่งมี “finding site” เป็น “lung structure” แบบนี้ก็จะกล่าวได้ว่า predicated expression นั้น subsume candidate expressions (candidate เป็นสมาชิกของ predicated)
  • การ implement subsumption
    • Concept -> เอกสารแนะนำให้ใช้ precomputed transitive closure table หรือไม่ก็ description logic reasoner (ผมใช้ไม่เป็นเหมือนกันครับทั้งสองวิธีเลย)
    • Expression -> เอกสารแนะนำให้ใช้ description logic reasoner หรือใช้การเปรียบเทียบ normal form expressions (ผมทำไม่เป็นเช่นกันครับ)
  • อันนี้อาจรู้สึกว่าไม่เห็นต่างจากการ query หา descendants ตาม hierarchy ใน ICD-10 เลย ซึ่งก็มีส่วนจริงครับ แต่การใช้ SNOMED CT มีข้อได้เปรียบหลายประการ จะอธิบายส่วนนี้เพิ่มเติมในหัวข้อ 6. Using statistical classifications

3. Using defining relationships

SNOMED CT มี attribute มากกว่า 50 ชนิด เช่น finding site, associated morphology, causative agent, procedure site, method, laterality, has active ingredient ซึ่ง SNOMED CT Concept Model จะมีกฎเกณฑ์มากำหนดให้กับ attribute เหล่านี้ เช่น finding site ควรต้องผูกกับ body structure เป็นต้น เราสามารถใช้ attribute เหล่านี้มา query หาสิ่งที่เราต้องการ

ในเอกสารยกตัวอย่างการค้นหาคนไข้ที่ได้รับการวินิจฉัยว่าเป็นโรคที่มีลักษณะ (associated morphology) เป็น benign neoplasm ซึ่งพบที่ (finidng site) เป็น ‘kidney’ (และ subtype ของ kidney)

ภาพจาก Figure 6.3.3 จากในเอกสาร Data Analytics with SNOMED CT

จากตัวอย่าง จะเห็นว่า

  • เราสามารถใช้ associated morphology ในการหา benign neoplasm ทั้งหมดได้ ไม่ว่าจะอวัยวะใด
  • เราสามารถใช้ finding site ในการหาโรคที่เกิดที่ไต และส่วนประกอบย่อยอื่น ๆ ของไตได้
  • การ combine 2 คุณสมบัติ ทำให้สามารถหา code ที่เฉพาะเจาะจงกับสิ่งที่ต้องการได้

ซึ่งเมื่อลองนำ ECL ดังกล่าวไปรัน จะพบถึง 24 concepts

ในขณะที่หากใช้ ICD-10 แม้ว่า hierarchy จะเอื้อให้หา code ของ benign neoplasm ที่ไตได้ (หากเป็น attribute แบบอื่นอาจไม่ตรงกับ hierarchy ของ ICD-10) แต่ code ก็มีเพียงแค่ code เดียว (D30.0) ไม่ได้มีความละเอียดพอที่จะบันทึก diagnosis เหมือน SNOMED CT (เนื่องจาก ICD-10 เป็นการ classify “กลุ่มโรค” เพื่อใช้ประโยชน์ทางสถิติ ซึ่งไม่ควรนำมาใช้สำหรับบันทึกการวินิจฉัยทางคลินิก เพราะไม่ละเอียดพอ)

ภาพจาก https://icd.who.int/browse10/2019/en#/D30.0

4. Description logic over terminology

SNOMED CT เขียนโดย Description Logic (DL) ดังนั้นจึงใช้ DL reasoners และ query engines สำหรับการ query เพิ่มเติมได้ ซึ่งมีตัวอย่างการใช้ประโยชน์คือ

  • Property chaining
    • ใช้ในการ infer properties เช่น “x มี parent เป็น y” และ “y มี parent เป็น z” ดังนั้น “x มี grandparent เป็น z”
  • Reasoning over concrete values
    • บาง concept เช่น “amoxicillin 500mg tablet” มี concrete value (500) เป็นส่วนประกอบ การแปลง concept แบบนี้เป็น OWL 2 จะสามารถ reasoning โดยรวมเอาพวก concrete value แบบนี้เข้ามาด้วย
  • ทดสอบการเท่ากัน (equivalence) และทดสอบการ subsumption ของ postcoordinated expressions (โดยไม่ต้องสร้าง normal forms)
    • ดังที่กล่าวไปในหัวข้อ 2. Subsumption
  • Reasoning over minimum sufficient sets
    • เช่น การ define “pulmonary tuberculosis” อาจประกอบด้วยคุณสมบัติ 4 อย่าง แต่เราอาจสามารถใช้คุณสมบัติแค่ 3 อย่างในการ reasoning ว่าเป็น pulmonary tuberculosis ได้
ภาพจาก 6.4 Description Logic Over Terminology

ในเอกสารมีการยกตัวอย่างว่า หากเราต้องการหาโรคทั้งหมดที่เกี่ยวข้องกับ “streptococcus pyogenes” เราสามารถใช้ description logic reasoner ในการ include “acute rheumatic arthritis” เข้ามาด้วย เพราะ property มีการ chaining ไปจนถึง concept นั้น

ภาพจาก Figure 6.4-1 จากในเอกสาร Data Analytics with SNOMED CT

การ implement Description logic over terminology

  • ต้อง transform SNOMED CT เป็น OWL 2 ก่อน แล้วโหลดเข้า Description Logic Editor (เช่น Protégé) หรือใช้พวก terminology service ที่มีความสามารถดังกล่าว เช่น Snorocket, ELK และ FACT++,
  • สามารถใช้ Semantic query languages( เช่น SPARQL) กับ RDF representations ของ SNOMED CT

5. Description logic over terminology and structure

ถึงแม้จะเก็บข้อมูลมาในรูปแบบที่ต่างกัน แต่หากใช้ SNOMED CT เราสามารถประมวลผลความสัมพันธ์ได้

ในเอกสารยกตัวอย่างการเก็บ family history 2 แบบ แบบแรกบันทึกในช่อง Family history โดยให้มี problem เป็น “heart diseases” และความสัมพันธ์กับผู้ป่วยเป็น “mother” แบบที่สองคือบันทึกในช่อง Clinical history (ประวัติปัจจุบัน) โดยใช้ concept “family history: cardiac disorder”

ซึ่งหากใช้ SNOMED CT เราสามารถ reasoning ได้ว่า ข้อมูล 2 ชุดนี้ คือสิ่งเดียวกัน

ภาพจาก Figure 6.5-1 จากในเอกสาร Data Analytics with SNOMED CT

แนวทางการ implement สามารถทำได้เช่นเดียวกันกับข้อก่อนหน้า

6. Using statistical classifications

ข้อได้เปรียบของการบันทึกข้อมูลเป็น SNOMED CT แล้วจึง map ไปที่ classification (เช่น ICD-10) ในภายหลัง ด้วยเหตุผลคือ

  • Classification มักจะเป็น mono-hierarchy เช่น “viral pneumonia” เป็น “Diseases of the respiratory system” แต่ไม่ใช่ “Certain infectious and parasitic diseases” ซึ่งในการ query หาโรคติดเชื้ออาจไม่พบโรคนี้ แต่ SNOMED CT เป็น poly-hierarchy
  • Classification มักมีการจัด concept ที่ใกล้ ๆ กันเอาไว้ด้วยกัน (ดังที่ได้กล่าวไปก่อนหน้านี้ว่า ICD-10 เป็นการจัด “กลุ่มโรค”) ซึ่งเป็นประโยชน์ในการรายงานสถิติ แต่การใช้ในทางคลินิกเรามักต้องการบันทึกข้อมูลที่มีความละเอียดมากกว่านั้น

การ implement

  • ในไฟล์ release ของ SNOMED CT (RF2) จะมี Extended Map reference set  ซึ่งสามารถใช้ในการ mapping ไป ICD-10 ได้ (ผมก็ไม่เคยเห็นเหมือนกันครับ)

ความเห็นผม

  • จุดแข็งของ SNOMED CT ก็คือการใช้ description logic ในการ define concept ต่าง ๆ ซึ่งก็มีการกำหนด attribute มามากมาย ทำให้เรามีวิธีการ query ข้อมูลที่ค่อนข้างยืดหยุ่นกว่าการใช้ classification
  • และหากต้องการจะ query ที่ซับซ้อนมากขึ้น ก็ยังสามารถใช้พวก description logic reasoner ในการ query ได้อีก
  • ในตัวอย่างที่ทางเอกสารยกมา จริง ๆ ก็มีหลายเคสที่ไม่ได้บันทึกข้อมูลต้นทางเป็น SNOMED CT แต่ใช้วิธีการมา map เข้า SNOMED CT ในภายหลัง เพื่อการต่อยอดในอนาคต ดังนั้น ผมว่าเราไม่จำเป็นต้องรอให้ประเทศไทยเป็นสมาชิก SNOMED International, ไม่จำเป็นต้องรอให้มี national terminology server ฯลฯ ทางรพ., vendor, หรือโครงการไหนพร้อม สามารถเริ่มใช้ SNOMED CT ได้เลย ข้อมูลที่มี structure ที่ดีจะสามารถใช้ประโยชน์ในการวิเคราะห์ข้อมูลได้อีกมากในอนาคต
  • และหากจะมีการนำ SNOMED CT มาใช้ ไม่ควรใช้แค่ diagnosis แต่ควรใช้ในทุกส่วนให้ได้มากที่สุด ซึ่งในหลาย ๆ ส่วนอาจต้องใช้ natural language processing (NLP) ประกอบ เช่น พวก clinical document, progress note, nurse note, ฯลฯ
  • อย่างไรก็ดี ต้องบอกว่าผมเองยังไม่เคยศึกษา ICD-11 แบบลึก ๆ จริง ๆ อาจจะตอบโจทย์ในส่วนของการบันทึกข้อมูล diagnosis ได้เช่นกัน

You Might Also Like

No Comments

Leave a Reply