ผมว่าความงงอย่างหนึ่งของคนที่เข้ามาทำงานกับ HL7® FHIR® ใหม่ ๆ ก็คือไม่ทราบว่าหากต้องการส่งข้อมูลแต่ละอย่าง ต้องใช้ resource ชนิดไหนมาส่ง บทความนี้เลยจะสรุป resource ที่สำคัญ ๆ ของแต่ละ module ครับ เนื่องจาก resource ใน FHIR R4 มีถึง 149 รายการ แม้ว่าจะเลือกมาที่สำคัญ ๆ แล้วก็ยังมีถึง 108 รายการ ซึ่งก็เยอะอยู่ดีครับ 😅 โดยเกณฑ์ที่ผมใช้ตัดสินว่า resource ไหนสำคัญ คือผมดูว่าเขาเอาไว้ที่หน้าแรกของแต่ละ module หรือเปล่า ถ้ามีก็ถือว่าสำคัญละกัน
ก่อนอื่นขออธิบายคำว่า module ก่อนครับ คือ FHIR เป็น platform specification นั่นคือเป็นข้อกำหนดว่าถ้าเราจะแลกเปลี่ยนข้อมูลกันผ่านมาตรฐานนี้ ต้องทำตามข้อกำหนดอะไรบ้าง เนื่องจาก spec นี้มีรายละเอียดเยอะ จึงได้มีการแบ่ง spec นี้ออกเป็น 5 level และ 13 module ครับ ซึ่งคำว่า FHIR module ที่ผมกล่าวถึงในบทความนี้ก็จะเป็น module ที่แบ่งตามนี้ครับ

(ภาพ Featured image โดย Erol Ahmed on Unsplash)
เสริม: ความงงอย่างหนึ่งตอนที่ผมศึกษา FHIR ใหม่ ๆ ก็คือ วิธีการแบ่ง module ตามข้างต้น เป็นคนละอย่างกันกับวิธีการจัดกลุ่ม resource นะครับ คือ resource เป็นสิ่งที่สำคัญก็จริง แต่ยังมี spec เรื่องอื่น ๆ อีกเยอะที่ไม่ใช่ resource ดังนั้น module คือการแบ่ง spec เป็นกลุ่ม ๆ ส่วน resource ก็มีวิธีการจัดกลุ่มของตนเอง ซึ่งไม่เหมือน module (อ่านแนวคิดการจัดกลุ่ม resource ได้ที่ architecture overview ครับ)

13 Module ของ FHIR
อธิบายเพิ่มเล็กน้อยว่า การแบ่ง Level เป็น 5 level นั้น level ที่อยู่ล่างสุด (level 1) จะเป็น module ที่เป็น infrastructure ให้ module อื่น ๆ พอขึ้นมาก็จะเป็นการใช้ประโยชน์ต่อยอดขึ้นไปเรื่อย ๆ สำหรับ module ทั้ง 13 module นั้น เรียงตาม level จากน้อยไปมากได้ดังนี้ครับ
Level 1 เป็น basic framework ของ spec
- Foundation: เป็น definition ของ infrastructure ที่ให้ module อื่น ๆ มาต่อยอด
Level 2 เป็นพวก module ทาง technical ที่ต้องใช้เพื่อการ implement FHIR รวมไปถึงพวกการทำ terminology binding
- Implementer Support: รวมเนื้อหาและเครื่องมือที่จำเป็นในการ implement
- Security & Privacy: รวมคำแนะนำและเครื่องมือในการจัดการเรื่อง security & privacy
- Conformance: การทดสอบ conformance กับ FHIR core, profile และการทำ implementation guide
- Terminology: การใช้งาน terminology
- Exchange: การแลกเปลี่ยน resources
Level 3 เอาไว้ใส่เชื่อมโยงกับ concepts ต่าง ๆ ใน healthcare system ในโลกความเป็นจริง
- Administration: เอาไว้เก็บข้อมูลคนไข้ ผู้ให้บริการ องค์กรต่าง ๆ อุปกรณ์ต่าง ๆ สารเคมีต่าง ๆ เป็นต้น
Level 4 เอาไว้บันทึกและแลกเปลี่ยนข้อมูลที่เกิดขึ้นระหว่างดำเนินกระบวนการต่าง ๆ ใน healthcare
- Clinical: ข้อมูลทางคลินิกที่เกี่ยวข้องกับ Patient เช่น problems, การแพ้ต่าง ๆ, แผนการรักษา เป็นต้น
- Diagnostics: ข้อมูลสิ่งที่ตรวจพบในทางคลินิกและการรายงานผล
- Medications: ข้อมูลยาและวัคซีน
- Workflow: ใช้บันทึกและติดตามกระบวนการต่าง ๆ ที่เกิดขึ้นใน workflow
- Financial: ข้อมูลทางการเงินและการเคลม
Level 5 เอาไว้ประมวลผลการให้เหตุผล (reasoning) ในกระบวนการต่าง ๆ ใน healthcare (อันนี้เข้าใจยากอยู่ครับ)
- Clinical Reasoning: Clinical Decision Support และ Quality Measures
หมายเหตุ ทุก resource และ element ใน FHIR จะมี maturity กำกับ โดยยิ่งน้อยแปลว่ายิ่ง immature ส่วนขั้นสูงสุดคือ N (normative) ถ้าเป็น N แล้วหมายความว่าใน FHIR version ถัดไป resource/element นั้นจะยังคงอยู่แน่นอน (backward-compatibility) สรุปก็คือ อันไหนเป็น N แล้วใช้ได้อย่างปลอดภัย นิ่งแล้วแน่นอน อันไหนเลขน้อย ๆ ก็อาจระวังหน่อยว่าอาจมีเปลี่ยนแปลงในเวอร์ชั่นถัด ๆ ไป อันนี้เอามาให้สังคมลองใช้ก่อน
สรุป resource ที่ใช้บ่อย
เนื่องจาก resource ทั้งหมดมีเยอะ แต่ในบริบทของไทย ผมว่า resource ที่น่าจะได้ใช้บ่อย ๆ มีดังนี้ครับ
ข้อมูลที่ต้องการแลกเปลี่ยน | Resource ที่ต้องใช้ |
---|---|
Demographic ของคนไข้ | Patient แต่ถ้าเป็นข้อมูลญาติใช้ RelatedPerson |
ข้อมูลหมอที่รักษา | Practitioner, PractitionerRole |
ข้อมูลสถานพยาบาล | Organization สำหรับเชิงบริหารจัดการ และใช้ Location สำหรับเชิงกายภาพ |
ข้อมูล visit ทุกชนิด IPD, OPD, Telehealth, ฯลฯ | Encounter แต่ถ้าอยากจัดกลุ่มหลาย ๆ visit ไว้ด้วยกันด้วยก็ใช้ EpisodeOfCare |
ประวัติแพ้ยาแพ้อาหาร | AllergyIntolerance |
การซักประวัติ ตรวจร่างกาย | Observation |
หัตถการที่ทำ | Procedure |
Problem list, การวินิจฉัย | Condition |
การสั่ง order, การ refer | ส่วนใหญ่ใช้ ServiceRequest ยกเว้นยาใช้ MedicationRequest และอาหารใช้ NutritionOrder |
ข้อมูลยา | MedicationStatement แต่ถ้าแยกเป็นแต่ละขั้นใน workflow ใช้ MedicationRequest, MedicationDispense, MedicationAdministration |
รายงานผลแล็บ | DiagnosticReport สำหรับการจัดกลุ่ม และแต่ละรายการใช้ Observation |
รายงานผล imaging | DiagnosticReport สำหรับการจัดกลุ่ม และแต่ละรายการใช้ ImagingStudy (DICOM) Media (Non-DICOM) |
ประวัติวัคซีน | Immunization |
ประวัติการนัด | Appointment |
การเงิน | Account, Coverage สำหรับข้อมูลเกี่ยวกับประกัน Claim สำหรับข้อมูลการส่งเคลม ClaimResponse สำหรับผลการเคลม |
ข้อมูลทุกชนิดที่เป็นรหัส | ใช้ CodeSystem และ ValueSet เป็นอย่างน้อย ถ้าจะใช้ terminology service |
การส่งข้อมูลทางเทคนิค | มักจะทำ Bundle ประเภท transaction ที่ใช้บ่อยรองลงมาก็ document |
ส่วนนี้ใน FHIR spec เองก็เขียนไว้ค่อนข้างดีครับ (แต่อาจไม่ค่อยตรงบริบทของไทย) ลองดูได้ที่หน้า Resource Guide
Level 1 – Infrastructure
1. Foundation (URL)
Module นี้เป็น infrastructure ของ resource อื่น ๆ เนื่องจากทุก resource ใน FHIR มีการพึ่งพิง resource ใน module นี้ไม่ว่าทางใดก็ทางหนึ่ง ยกตัวอย่างเช่น resource ที่เราใช้กันบ่อย ๆ เช่น Patient ก็เป็นการ inherit มาจาก DomainResource ซึ่ง inherit มาจาก Resource อีกที
แบ่ง resource ในกลุ่มนี้เป็น 3 กลุ่มย่อย
Foundation Framework
Resource | Maturity | Description |
---|---|---|
Resource (Base Resource) | N | เป็น abstract class ที่กำหนดลักษณะพื้นฐานที่ทุก resource ต้องมี ดังนั้นทุก resource ใน FHIR ต้อง derive มาจาก resource นี้ เสริม: Resource คือหน่วยที่เล็กที่สุดของการแลกเปลี่ยนข้อมูล แต่หน่วยที่เล็กที่สุดของข้อมูลใน FHIR คือ Element นะครับ ซึ่งแต่ละ data type ก็จะเป็นการ extend มาจาก Element อีกที |
DomainResource | N | เป็นการ extend Base Resource ขึ้นมาอีกขั้น โดยเพิ่มให้ Base Resource สามารถเพิ่ม narrative text, contained resource, extension, และ modifierExtension ได้ เสริม: resource ที่เราใช้งานเกือบทั้งหมดใน FHIR เป็นการ extend จาก DomainResource ยกเว้น Bundle, Parameters และ Binary ที่เป็นการ extend จาก Base Resource ตรง ๆ |
Basic | 1 | เอาไว้ใส่ concept ที่ยังไม่เคยมีการ define ใน FHIR มาก่อน โอกาสได้ใช้น่าจะค่อนข้างน้อย |
Binary | N | เอาไว้ใส่ข้อมูลดิบ ๆ แบบเป็น binary โดย common use case คือเอาไว้ reference ด้วย url จาก element ที่เป็น type Attachment เสริม: เพราะ Attachment ใส่ base64 binary มาเลยได้ แต่ในบางสถานการณ์อาจต้องการเก็บแยกเป็น resource ต่างหาก จึงต้องสร้างเป็น Binary resource แล้ว reference ผ่าน url เอา |
Bundle | N | 1 ใน resource ที่ใช้บ่อยที่สุดแล้ว เอาไว้รวมกลุ่ม resource หลาย ๆ อันเอาไว้เป็นก้อนเดียว เพื่อการส่งไปทั้งก้อน ตัว Bundle มีหลาย type ที่ใช้บ่อย ๆ ก็ transaction, batch, document, message, history, searchset เสริม: FHIR มีวิธีรวมกลุ่ม resource ไว้เป็นก้อนเดียวกัน 2 วิธี คือการทำ contained resource และการทำ Bundle สำหรับวิธีแรก การจะเข้าถึง content ที่เป็น contained resource ต้องเข้าถึง resource นั้น ๆ ก่อนเท่านั้น ส่วนการทำ Bundle แต่ละ resource จะกลายไปเป็น resource ของตนเอง จึงเข้าถึงได้โดยตรงจากวิธีปกติ (เช่น GET method) เหมือน resource ทั่ว ๆ ไป เสริม 2: ความชวนงงอีกอย่าง คือมี resource อีกประเภทเอาไว้จัดกลุ่มเนื้อหาผ่านการ reference แต่ไม่ใช่การเอา resource มารวมเป็นก้อนเดียวกัน พวกนี้ได้แก่ List, Group, Composition |
Content Management Resources
Resource | Maturity | Description |
---|---|---|
Questionnaire | 3 | ถึงแม้ชื่อจะชวนให้นึกถึงแบบสอบถามต่าง ๆ แต่จริง ๆ จุดประสงค์ของ resource นี้คือเอาไว้บันทึกแบบฟอร์มที่ใช้ในทางการแพทย์ทุกอย่าง (แบบสอบถามก็เป็นหนึ่งในนั้น) เช่น Past medical history (PMH), Family diseases, Social history, แบบสอบถามงานวิจัย, แบบประเมินคุณภาพ-ความพึงพอใจ, Patient intake form (e.g. clipboard), ฟอร์มเคลมประกัน |
QuestionnaireResponse | 3 | เอาไว้บันทึกคำตอบที่เกิดจากการตอบ Questionnaire |
List | 1 | เป็นวิธีจัดกลุ่ม resource เอาไว้ด้วยกัน (ผ่านการ reference) เพื่อให้ง่ายต่อการจัดการ เช่น List ของ current medication, List ของรายการสิ่งที่คนไข้แพ้ เสริม: resource ที่อยู่ใน List สามารถเป็นชนิดเดียวกันก็ได้ (เช่น ยาที่กิน) หรือคนละชนิดก็ได้ (เช่น แพ้ทั้งยา และอาหาร) |
Composition | 2 | เป็น resource ที่เอาไว้สร้าง FHIR Documents หรือก็คือการเอาข้อมูลมารวมกันเป็นก้อนเดียว (Bundle type = document) แล้วระบุข้อมูลอื่น ๆ ที่เกี่ยวข้อง ระบุชื่อของผู้สร้างและรับรอง document นั้น เมื่อ bundle เป็น document แล้ว ข้อมูลทุกอย่างในนั้นจะ immutable ไม่สามารถเปลี่ยนแปลงได้ |
DocumentReference | 3 | เอาไว้ reference ไป document ทุกชนิด (ทั้ง FHIR และไม่ใช่ FHIR) ทั้งที่เก็บไว้ที่ server เดียวกันและที่อื่น สามารถ reference ไป document ที่เก็บใน Binary resource ก็ได้ |
DocumentManifest | 2 | อันนี้ผมไม่ค่อยชัวร์ เหมือนจะใช้เยอะในพวก document indexing system เช่น IHE-XDS คือเป็นการ reference หลาย ๆ resource เข้าไว้ด้วยกัน (สามารถรวมหลาย ๆ document ไว้ด้วยกันได้ด้วย) แล้วเพิ่ม metadata ที่เกี่ยวข้องเข้าไป |
Data Exchange Resources
Resource | Maturity | Description |
---|---|---|
OperationOutcome | N | สร้างโดย server เอาไว้ response ต่อ operation ต่าง ๆ ส่วนใหญ่มักเกิดขึ้นเวลามีปัญหา เช่น เมื่อส่ง HTTP request มาที่ server แล้วไม่สำเร็จ จึงส่งกลับเป็น resource นี้ |
Parameters | N | เอาไว้ส่งเป็น parameter ของ operation ต่าง ๆ (ตามที่ระบุไว้ใน OperationDefinition ) |
Subscription | 3 | อันนี้ผมก็ไม่ค่อยแม่น แต่เหมือนจะเอาไว้ subscribe ต่อเหตุการณ์บางอย่างใน server เช่น มีการแก้ไข resource ที่เราสนใจ ก็ให้ notify เรา เป็นต้น |
MessageHeader | 4 | เอาไว้ใส่ใน Bundle เพื่อสร้าง bundle type messaging เพื่อส่งข้อมูลกันเป็น message หรือก็คือการส่งข้อมูลเมื่อมีเหตุการณ์บางอย่างที่เราสนใจ เช่น ถ้าเป็น request message ก็คือส่ง message ไปขอให้ระบบปลายทางดำเนินการบางอย่างต่อ |
MessageDefinition | 1 | เอาไว้กำหนดลักษณะของ message ที่จะแลกเปลี่ยนกันระหว่าง 2 ระบบ |
Level 2 – Techinical Implementation
2. Implementer Support (URL)
Module นี้มี resource ไม่เยอะ และค่อนข้าง advance เพราะโฟกัสที่วิธีการในการ implement FHIR ไปใช้จริง ๆ ใน module ก็จะมีพวก tool ต่าง ๆ ให้ดาวน์โหลด มีคู่มือต่าง ๆ ส่วน resource มีอยู่ 3 อันเองครับ (ผมยังไม่เคยใช้เองเลยซักอัน)
Resource | Maturity | Description |
---|---|---|
TestScript | 2 | เป็น resource หลักที่เอาไว้ test ว่าการ implement FHIR ของเรา comply กับ specification มากน้อยขนาดไหน สมมติเรา implement FHIR ในหลายที่ เราก็ automate test ได้ว่าทุกที่โอเคหรือเปล่าโดยใช้ TestScript เดียวกัน เสริม: การ test กับการ validate นี่ต่างกันนะครับ (แต่ประเด็นนี้ผมก็ไม่แม่นนะ) test คือ test ในเชิง infrastructure ว่า implementation ของเราทำตาม spec ได้ไหม ส่วน validate คือการตรวจว่าข้อมูลที่เราจะส่ง conform กับ profile/resource หรือเปล่า |
TestReport | 0 | เอาไว้บันทึกผลการ test |
StructureMap | 2 | เอาไว้ mapping ในเชิงโครงสร้างของข้อมูล หรือก็คือการ map ระหว่าง StructureDefinition ครับ เสริม: คือเบื้องหลังจริง ๆ แล้ว สิ่งต่าง ๆ ใน FHIR ทั้ง resource, data type, extension, profile เหล่านี้เกิดขึ้นได้เพราะเกิดการ define ใน StructureDefinition ครับ เรียกว่าเป็น resource ที่เป็น template ของ resource ต่าง ๆ ประมาณนั้นก็ได้ครับ เสริม 2: StructureMap เป็นการ mapping ในเชิงโครงสร้างข้อมูล ถ้าจะ map ระหว่าง terminology หรือคือการ mapping ที่ตัวข้อมูล ต้องไปใช้ ConceptMap ครับ |
3. Security & Privacy (URL)
FHIR ออกตัวว่าไม่บังคับการ implement ด้าน security และ privacy ใด ๆ แต่ถึงไม่บังคับเขาก็มีคำแนะนำเยอะอยู่เขียนไว้ใน module นี้ครับ แต่ถ้าพูดถึง resource ใน module นี้มีอยู่ 3 resource ครับ
Resource | Maturity | Description |
---|---|---|
Consent | 2 | เอาไว้เก็บ consent ครับ ซึ่งมีอยู่ 4 ประเภท privacy, medical treatment, research, advance care (เช่น do-not-resuscitate) ใน spec บอกว่าปัจจุบันยัง support แค่ privacy consent เป็นหลัก |
Provenance | 3 | เอาไว้เก็บข้อมูลที่เป็นบริบทที่เกิดขึ้นเมื่อมีการสร้าง/แก้ไข/ลบ ที่เกิดขึ้นกับ resource หนึ่ง ๆ เช่น แก้ไขโดยใคร อย่างไร ที่ไหน ทำไม ฯลฯ มักมีการบันทึกโดย application เมื่อเกิดแก้ไขดังกล่าว เสริม: จริง ๆ เวลาแก้ไขข้อมูลใน resource ต่าง ๆ ก็มี metadata พวกนี้อยู่แล้ว แต่หากต้องการเก็บข้อมูลโดยละเอียด Provenance resource จะมีรายละเอียดที่เยอะกว่า หรือบางสถานการณ์ implementor อาจอยากแยกการเก็บ Provenance ออกมาต่างหาก เลยต้องใช้ resource นี้ |
AuditEvent | 3 | เอาไว้ log event สำคัญ ๆ ที่เกิดขึ้นที่เราต้องการจะ log ซึ่งสามารถใช้ได้กว้างมากกับ event ทุกประเภท ทั้งที่เกิดขึ้นกับ resource และไม่ใช่การกระทำกับ resource เช่น user log in, HTTP log, config change, ฯลฯ |
4. Conformance (URL)
เป็น module ที่ว่าด้วยการปรับแต่ง FHIR ให้เข้ากับความต้องการของ local implementor ตัวอย่างเช่น 1) resource ต่าง ๆ ที่จะแลกเปลี่ยนจะบังคับให้มี element ไหนไหม หรือจะเอาออก หรือจะเพิ่มข้อมูลเข้าไป 2) กำหนด HTTP operation 3) กำหนด terminology เป็นต้น การกำหนดสิ่งเหล่านี้เรียกว่าการทำ Profiling
Resource ที่เกี่ยวข้องเรื่องนี้หลัก ๆ มี 7 อัน เราเรียกรวม ๆ resource ที่เกี่ยวข้องกับการทำ profile นี้ว่า conformance resources (แต่ใน module นี้มี 6 resource เพราะ MessageDefinition ถูกจัดไปอยู่ใน Foundation module)
Resource | Maturity | Description |
---|---|---|
CapabilityStatement | N | เอาไว้บอกว่า FHIR server นั้น ๆ สามารถทำอะไรได้บ้าง อันนี้ยาวมาก แต่หลักการก็คือก่อนที่ client จะมี operation อะไรกับ server ได้ เขาก็ควรรู้ก่อนว่าอีกฝ่ายที่เขากำลังคุยด้วยอยู่ทำอะไรได้บ้าง ทำแบบไหน ไม่ทำอะไรบ้าง ถ้ารู้ว่าไม่ support เรื่องที่เขาต้องการจะได้หาวิธีอื่น |
StructureDefinition | N | เอาไว้กำหนดคุณสมบัติของ resource ต่าง ๆ ว่าต้องมี element อะไรบ้าง มี extension อะไรไหม มี constraint อย่างไร ปกติเรามักใช้ StructureDefinition ในการสร้าง Profile เสริม: ถ้าเราเข้าไปดูลึก ๆ จริง ๆ แล้วแต่ละ resource ที่อยู่ใน FHIR core ก็ define ด้วย StructureDefinition เหมือนกันนะครับ ลองดูตัวอย่างการ define Patient resource ดูครับ รวมไปถึงการ define Data Type ก็เช่นกัน |
OperationDefinition | N | Operation ใน FHIR ก็คือพวกคำสั่งที่เราส่งไปด้วยการใส่ตามหลัง $ แล้วส่ง POST request ยกตัวอย่างเช่น การใช้ $validate ในการตรวจว่า resource ที่เราสนใจนั้น conform กับ profile หรือไม่ OperationDefinition ก็เป็น resource ที่เอาไว้สร้าง operation เหล่านี้ เพราะเวลาเราสร้าง profile เราก็กำหนด operation ให้ profile นั้น ๆ ได้ |
SearchParameter | 3 | ปกติทุก resource จะมีระบุไว้อยู่แล้วว่าสามารถค้นหา Element ไหนด้วยชื่ออะไรได้บ้าง เช่น เราใช้ name ในการหาชื่อคนไข้ แต่ใน Element จริง ๆ แยกเป็น family กับ given เวลาเราสร้าง profile เรากำหนดได้ว่าจะให้ค้นหา element ไหนได้บ้างกับ profile นั้น ๆ |
CompartmentDefinition | 1 | Compartment เอาไว้จัดกลุ่ม resource ที่เกี่ยวข้องกับเรื่องหนึ่ง ๆ เอาไว้เป็นกลุ่มเดียวกัน เพื่อให้ง่ายในการเข้าถึงข้อมูลหรือค้นหา เช่น เราสามารถค้นหา Condition ทั้งหมดของคนไข้คนหนึ่งได้ ก็เพราะ Condition เป็นส่วนหนึ่งของ Compartment Patient เราจึง GET [base]/Patient/[id]/Condition แบบนี้ได้ แต่ละ resource สามารถอยู่ได้หลาย Compartment และเวลาสร้าง profile เราสามารถสร้าง Compartment ได้เช่นเดียวกับ conformance resource อื่น ๆ |
ImplementationGuide | 1 | เป็นการมัดรวม resource และ profile ทั้งหมดที่เกี่ยวกับการ implement FHIR ใน use case หนึ่ง ๆ เอาไว้ด้วยกัน แล้วเพิ่มข้อมูลพวก narrative เอาไว้ให้คนอ่าน รวมถึงตัวอย่างถ้าจะนำไป implement จริง |
5. Terminology (URL)
Terminology อธิบายง่าย ๆ ก็คือ ชุดของค่า (value) ที่กำหนดไว้อยู่แล้ว ให้เราเลือกเอาจากค่านั้นมาใช้ เช่น ถ้า terminology ของจังหวัดในประเทศไทย ก็จะมีอยู่ 77 รายการ ตามจำนวนจังหวัด แต่ละรายการก็มีรหัสจังหวัด และชื่อจังหวัด ในทาง health informatics มีการใช้ terminolog ค่อนข้างเยอะ เพื่อการสื่อสารข้อมูลต่าง ๆ ซึ่ง module นี้ของ FHIR ก็มีไว้จัดการเรื่องนี้
อีกคำหนึ่งที่อาจต้องเข้าใจก็คือ Terminology Service ครับ คือ Terminology module นี้ก็จะมีการกำหนด service ต่าง ๆ ที่ server ควรจะทำได้ที่เกี่ยวข้องกับเรื่อง terminology เช่น operation พวก $lookup, $expand เป็นต้น แต่เนื่องจากหลาย ๆ terminology มีขนาดใหญ่และมีความสัมพันธ์ระหว่าง code ภายในซับซ้อน เช่น SNOMED-CT ที่มีกว่า 300,000 concepts แถมมีคนดูแลเฉพาะอีก การจะคอยดูแล terminology เหล่านี้ด้วยตนเองก็มักมีความวุ่นวาย หลาย ๆ ที่เลยนิยมตั้ง Terminology server ขึ้นมา เพื่อให้บริการ terminology service เหล่านี้ครับ
เกริ่นซะยาว สำหรับ module นี้ก็มี resource หลัก ๆ ดังนี้ครับ
Resource | Maturity | Description |
---|---|---|
CodeSystem | N | เอาไว้สร้าง terminology ครับ จะมีข้อมูลว่า terminology นั้นชื่ออะไร metadata ต่าง ๆ และก็มีระบุว่าประกอบด้วย code อะไรบ้างที่อยู่ในนั้น |
ValueSet | N | ValueSet ครับ คือ ชุดของ code ที่เราจะใช้จริงครับ เนื่องจากในสถานการณ์จริง ส่วนใหญ่เราไม่ได้ใช้ code จาก terminology ทั้งหมด ดังนั้นจึงต้องดึงมาใช้เฉพาะบางค่า ในขณะเดียวกันเราก็อาจจะใช้ code จากหลาย terminology มาผสมกันก็ได้ |
ConceptMap | 3 | พอเวลาใช้งานหลาย ๆ terminology บางครั้ง code จากในแต่ละ terminology ก็สามารถมีความสัมพันธ์กันได้ (เช่น บอกว่ามีความหมายเหมือนกัน หรือบอกว่าอันนึงเป็น subset ของอีกอัน) ConceptMap เอาไว้ทำเรื่องนี้ครับ |
NamingSystem | 1 | ถ้าใครเคยใช้ FHIR มาก่อนจะทราบดีว่ามันมี element ที่ชื่อว่า system อยู่ ซึ่งมักให้เราใส่ url เวลาเราทำอะไรก็ตามที่เกี่ยวกับ data type ประเภท coding หรือ identifier ซึ่ง system พวกนี้ถ้าดัง ๆ FHIR จะ define system มาให้เลย (เช่น SNOMED-CT) แต่ถ้าเรากำหนด coding, identifier ของเราเอง เราสามารถกำหนดรายละเอียดของ system ด้วย NamingSystem นี่แหละครับ เสริม: ผมเองยังไม่ค่อยเข้าใจการใช้งาน NamingSystem มากนัก เข้าใจว่าใช้เวลาแลกเปลี่ยนข้อมูลกับคนอื่น แล้วเขาไม่รู้จัก system ที่เราใช้ ถ้ามี NamingSystem ก็จะใช้ดู definition ได้ |
TerminologyCapabilities | 0 | เอาไว้บอกว่า server ที่ host terminology นั้น ๆ อยู่ให้บริการ terminology service อะไรบ้าง อย่างไร เสริม: หน้าที่คล้าย ๆ กับ CapabilityStatement แหละครับ แต่อันนี้เอาไว้ให้รายละเอียดเฉพาะ terminology service |
6. Exchange (URL)
Module นี้เป็น module ที่ไม่มี resource เลย (เท่าที่ผมลองหาดู) หน้าที่หลัก ๆ คือใช้กำหนดแนวทางในการแลกเปลี่ยน FHIR resource แบบต่าง ๆ เช่น พวก RESTful, messaging, document ฯลฯ ก็มีรายละเอียดอยู่ใน module นี้แหละครับ
Level 3 – Healthcare Entities
7. Administration (URL)
Module นี้หลัก ๆ ก็คือเอาไว้เก็บข้อมูลว่าใครเป็นใครใน healthcare แหละครับ แบ่ง resource ใน module นี้เป็น 5 กลุ่มย่อย
Patient Registers (URL)
Resource | Maturity | Description |
---|---|---|
Patient | N | เอาไว้เก็บข้อมูล demographic ของ “ผู้ที่ได้รับการดูแลรักษา (subject of care)” ซึ่งในที่นี้ก็เป็นได้ทั้ง คนไข้ที่มารับการรักษา, ผู้อยู่อาศัยใน nursing home, ไปจนถึงสัตว์ (animal) ที่รับการรักษา |
RelatedPerson | 2 | เอาไว้เก็บข้อมูลบุคคลที่มีส่วนเกี่ยวข้องในการดูแลรักษา Patient แต่ว่าไม่ใช่คนที่รับการดูแลรักษาโดยตรง และไม่ได้มีหน้าที่อย่างเป็นทางการที่จะต้องดูแล (ไม่ใช่บุคลากรของสถานพยาบาล) พูดง่าย ๆ ก็คือญาติคนไข้นั่นเอง |
Person | 2 | อันนี้ผมก็ไม่ค่อยเข้าใจ คือบอกว่าเอาไว้เก็บข้อมูลบุคคลที่ไม่เกี่ยวข้องอะไรกับการดูแลรักษา ขอติดไว้ก่อนครับ |
Group | 1 | เอาไว้จัดกลุ่ม Patient หรือ Devices ที่เราสนใจ (ด้วยการ reference สมาชิกกลุ่ม และเพิ่ม metadata) โดยได้เกิดการกระทำบางอย่างต่อทั้งกลุ่ม เช่น ให้การรักษา (group therapy), ทำการติดตามกลุ่มประชากรใน public health เป็นต้น |
Clinical Categorization Resources (URL)
Resource | Maturity | Description |
---|---|---|
EpisodeOfCare | 2 | เอาไว้จัดกลุ่ม Encounter ที่เกี่ยวข้องเอาไว้ด้วยกัน มักใช้ใน post-acute/long-term care, rehabilitation, chronic disease เช่น เก็บข้อมูล OPD visit เกี่ยวกับโรคเบาหวานทั้งหมดไว้เป็นก้อน EpisodeOfCare เดียวกัน เสริม: เป็น resource ที่เอาไว้บันทึกสิ่งที่เกิดขึ้น ซึ่งต่างจาก CarePlan ซึ่งเป็น resource ที่เอาไว้วางแผน (อาจไม่เกิดก็ได้) |
Encounter | 2 | หรือก็คือ visit แหละครับ คือการปฏิสัมพันธ์ระหว่าง Patient และ ผู้ให้บริการทางการแพทย์ (Providers) ไม่ว่าจะเป็นการให้การดูแลรักษา หรือการประเมินสถานะของคนไข้ ใช้เก็บข้อมูลได้ทั้ง OPD, ER, IPD และสถานการณ์อื่น ๆ |
Account | 2 | เก็บข้อมูลบัญชีทางการเงินของคนไข้ มีสิทธิ์การรักษาอะไรบ้าง กับที่ไหน ถ้าเคลมไม่ได้ใครจะจ่าย เป็นต้น แต่ไม่ได้เก็บยอดดุลในทางบัญชี (ณ เวอร์ชั่นนี้) |
Flag | 1 | ใช้เมื่ออยากติด flag เป็นพิเศษกับคนไข้บางกลุ่ม อันนี้ก็ติดได้เยอะมาก เช่น หมอประจำไม่อยู่, เดินทางมาจากเมืองที่มีโรคระบาด, โอกาสพลัดตกหกล้ม, มียอดค้างชำระ ฯลฯ |
Service Provider Directory Resources (URL)
Resource | Maturity | Description |
---|---|---|
Organization | 3 | กลุ่มของคนที่รวมตัวกันเพื่อวัตถุประสงค์ร่วมกัน มีการปฏิบัติตัวไปในทิศทางเดียวกัน ไม่ว่าจะเป็นการรวมตัวกันอย่างเป็นทางการหรือไม่เป็นทางการ เช่น บริษัท, แผนกในบริษัท, วอร์ด, องค์กรแพทย์, การรวมกลุ่มในชุมชน, บริษัทประกัน เป็นต้น มีความเป็นนามธรรมกว่า Location |
Location | 3 | สถานที่ทางกายภาพ (physical location) ที่เกิดการให้บริการทางสุขภาพหรือสิ่งที่เกี่ยวข้องเกิดขึ้น เช่น อาคาร, วอร์ด, หมายเลขเตียง, คลินิกเคลื่อนที่, รถพยาบาล, ตู้เย็น/ตู้อบ, บ้าน, ลานจอดรถ ฯลฯ |
Practitioner | 3 | ข้อมูล demographic ของผู้ที่ให้บริการทางสุขภาพ ได้แก่ แพทย์, พยาบาล, สหวิชาชีพอื่น ๆ, นักเทคนิคการแพทย์, นักสังคมสงเคราะห์, พนักงานต้อนรับ, ไปจนถึงเจ้าหน้าที่ IT ที่ดูแล record ของคนไข้ คือจริง ๆ ก็คือเกือบทุกคนที่ทำงานในรพ. โดยมีข้อแม้คือต้องเป็นคนที่มีหน้าที่อย่างเป็นทางการ (ถ้าไม่มีตรงนี้ต้องใช้ RelatedPerson) |
PractitionerRole | 2 | เอาไว้เก็บบทบาทในทางคลินิกของ Pracitioner เช่น อาชีพ, specialty, Location ที่ให้บริการ, HealthcareService ที่เขาให้, เวลาที่ให้บริการ ฯลฯ |
HealthcareService | 2 | เอาไว้เก็บข้อมูลรายละเอียดของบริการทางสุขภาพที่ให้บริการ ณ Location หนึ่ง ๆ |
Endpoint | 2 | เป็น technical endpoint ที่เอาไว้ใช้เป็นจุดในการส่งข้อมูลทางอิเล็กทรอนิกส์ เช่น endpoint สำหรับส่ง ServiceRequest เป็นต้น |
Scheduling and Appointments (URL)
ส่วนนี้เกี่ยวข้องกับเรื่องการนัด ซึ่งซ้ำกับ module Workflow เดี๋ยวขอลงรายละเอียดในส่วนนั้นทีเดียวครับ
Devices and Substances (URL)
Resource | Maturity | Description |
---|---|---|
Device | 2 | เอาไว้เก็บข้อมูลอุปกรณ์เครื่องมือแพทย์ ซึ่งรวมไปถึงพวก implant ด้วย เป็นการติดตามอุปกรณ์ที่มีตัวตนอยู่จริงทางกายภาพ |
DeviceDefinition | 0 | เอาไว้ระบุรายละเอียด คุณสมบัติของอุปกรณ์การแพทย์ต่าง ๆ เป็น master catalog ของอุปกรณ์การแพทย์ในสถานพยาบาลนั้น ๆ |
DeviceMetric | 1 | เอาไว้วัดค่าสถานะและการตั้งค่าต่าง ๆ ของ Device นั้น ๆ |
Substance | 2 | เอาไว้เก็บข้อมูลสารเคมี/จุลชีพ/วัตถุต่าง ๆ เช่น สารเคมีที่เป็นส่วนประกอบของยา, เชื้อ Staphylococcus, ไรฝุ่น, อาหาร, สารคัดหลั่ง เป็นต้น |
Level 4 – Healthcare Processes
8. Clinical (URL)
Module นี้เอาไว้บันทึกข้อมูลทางคลินิกที่เกี่ยวข้องกับ Patient (ส่วน Patient resource นั้นไว้บันทึกข้อมูล demographic) แต่ไม่รวมการบันทึกอาการ/การวัดค่าต่าง ๆ ที่ตรวจพบ ข้อมูลเหล่านั้นอยู่ใน Diagnosnostics module และไม่รวมข้อมูลเกี่ยวกับยาที่ใช้ เพราะอยู่ใน Medication module
Resource | Maturity | Description |
---|---|---|
AllergyIntolerance | 3 | เอาไว้เก็บข้อมูล adverse reaction ต่อสาร (Substance) หรือผลิตภัณฑ์ใด ๆ หลัก ๆ ก็คือการแพ้ยา แพ้อาหาร |
Condition (Problem) | 3 | เอาไว้เก็บ clinical condition, problem, diagnosis, issue, concern หรือประเด็นอื่น ๆ ที่มีผู้สนใจหรือคิดว่าต้องเกิดการดูแลในทางคลินิก เช่น ทั้งหมอและคนไข้สนใจ (เช่น problem, diagnosis) หมอสนใจแต่คนไข้อาจไม่ได้สนใจ (เช่น Anorexia) หรือคนไข้สนใจแต่หมอไม่ได้สนใจ (เช่น ศีรษะล้าน) พวกนี้ใช้ Condition บันทึกได้ทั้งหมด เสริม: ข้อแตกต่างระหว่าง Condition กับ Observation คือ 1) Observation มักใช้ในการบันทึกการประเมิน subjective (S), objective (O) แต่ Condition คือบันทึกสิ่งที่ clinician สรุปได้จากข้อมูล S และ O นั้น 2) Condition ต้องมีความต้องการการดูแลจัดการในระยะยาว ในขณะที่ Observation เป็นสิ่งที่ตรวจพบได้ใน Encounter นั้น ๆ แต่ไม่ได้ต้องจัดการระยะยาว |
Procedure | 3 | เอาไว้เก็บการกระทำที่ Practitioner ได้กระทำกับ Patient ซึ่งมีได้ตั้งแต่พวก intervention เช่น การผ่าตัด, หัตถการ ไปจนถึงพวกบริการต่าง ๆ เช่นการกายภาพบำบัด, การ counseling เปลี่ยนพฤติกรรม, บริการ day-care |
FamilyMemberHistory | 2 | เอาไว้เก็บประวัติการเจ็บป่วยของญาติ (RelatedPerson) ที่อาจส่งผลต่อ Patient |
CarePlan | 2 | เอาไว้บันทึกแผนการรักษา (คือเป็นแผนที่ Practitioner ว่าจะทำ ยังไม่จำเป็นต้องทำจริง) ที่จะกระทำกับ Patient เพื่อการดูแล Condition หนึ่ง ๆ (หรืออาจไม่ระบุ Condition ก็ได้) |
Goal | 2 | เอาไว้บันทึกเป้าหมายการดูแลรักษาที่อยากให้เกิดขึ้น ในระยะเวลาหนึ่ง มักสร้างขึ้นมาในบริบทของ CarePlan แต่อาจเป็นเป้าหมายของ กับ resource กลุ่ม Request อื่น ๆ ได้เช่นกัน |
CareTeam | 2 | เอาไว้บันทึกข้อมูลของทีมที่ดูแลรักษา Patient โดยสมาชิกทีมอาจมาจากฝั่งสถานพยาบาล หรือญาติคนไข้ก็ได้ หรือเป็นสมาชิกในนามองค์กรก็ได้ |
ClinicalImpression | 0 | เอาไว้บันทึก impression ที่เกิดจากการตรวจ (ยังไม่สรุปเป็น condition) หรือบันทึกตัว A (Assessment)ใน SOAP |
AdverseEvent | 0 | เอาไว้บันทีกพวกความผิดพลาดทางการรักษา หรืออันตรายที่เกิดกับคนไข้ที่เข้าร่วมงานวิจัย |
DetectedIssue | 1 | เอาไว้บันทึก issue ทางคลินิกที่เกิดขึ้นจากการกระทำอย่างน้อยหนึ่งอย่าง เช่น drug-drug interaction, Ineffective treatment frequency, Procedure-condition conflict, etc. อันนี้ในบางมุมผมก็ไม่ค่อยแม่นว่าใช้ต่างจาก AdverseEvent ยังไง |
RiskAssessment | 1 | เอาไว้บันทึก outcome อาจเกิดขึ้นกับ Patient ได้ เช่น prognosis ของโรค, ความเสี่ยงในการเกิดโรคจากพฤติกรรมหรือประวัติครอบครัว เป็นต้น |
9. Diagnostics (URL)
เป็น Module ที่เกี่ยวกับการตรวจวินิจฉัยโรค ทั้งการซักประวัติ ตรวจร่างกาย การตรวจแล็บ x-ray ไปจนถึง genomics
Resource | Maturity | Description |
---|---|---|
Observation | N | ใช้บันทึกการวัดและการตรวจต่าง ๆ ตั้งแต่ผลการตรวจร่างกาย (กดเจ็บที่ท้อง) ผลการวัดค่า (Vital sign) ผลแล็บ (Glucose) ผล imaging บางประเภท (Bone Density) การประเมินเบื้องต้น (APGAR, GCS) social history (สูบบุหรี่) เป็นต้น ส่วนใหญ่เป็นค่า ๆ เดียว เช่น Glucose 6.3 mmol/l แต่ก็สามารถประกอบด้วยหลายค่าเป็น component ได้ เช่น Vital signs SBP 120 mmHg DBP 80 mmHG |
DiagnosticReport | 3 | เอาไว้บันทึกรายงานผลการตรวจที่อยู่ในประเภทเดียวกันไว้ด้วยกัน เช่น รายงานการตรวจ CBC ก็จะประกอบด้วย Observation ของ Hb, Hct, WBC, Platelet ฯลฯ เข้ามาเป็น results ของ DiagnosticReport CBC เป็นต้น โดยนอกจากผลการตรวจแล้วยังสามารถใส่ metadata อื่น ๆ เข้าไปด้วยได้ |
Media | 1 | เอาไว้เก็บรูปภาพ, วิดีโอ, เสียง ที่ไม่ใช่ DICOM format |
ImagingStudy | 3 | เอาไว้เก็บผลการตรวจ imaging ที่เป็น DICOM format และ metadata ที่เกี่ยวข้อง |
MolecularSequence | 1 | เอาไว้เก็บ raw data ของ biological sequence |
Specimen | 2 | ตรงไปตรงมาครับ ก็คือเอาไว้บันทึกข้อมูลของ specimen ที่ใช้เก็บสิ่งส่งตรวจ |
BodyStructure | 1 | เอาไว้บันทึกส่วนต่าง ๆ ของร่างกาย ใช้ในหลาย ๆ resource ที่มีการอ้างถึง body part เช่น Observation, Procedure สามารถใช้ในกรณีที่มีการ reference terminology ภายนอกอยู่แล้วแต่ไม่ละเอียดเพียงพอได้ด้วย |
10. Medications (URL)
แบ่ง resource ในกลุ่มนี้เป็น 2 กลุ่มย่อย
Medications (URL)
Resource | Maturity | Description |
---|---|---|
MedicationRequest | 3 | ก็คือการสั่งยาครับ (prescription หรือ order) ใช้ได้กับการสั่งยาทุกชนิดทั้งในโรงพยาบาลและ over-the-counter เป็น resource ในกลุ่ม Request หมายถึงขอให้คนอื่นทำใน workflow แต่ไม่ได้บันทึกว่ามีการทำดังกล่าวเกิดขึ้นหรือไม่ เสริม: ใน spec มีข้อความบอกว่าใช้ MedicationRequest เพื่อเป็นการบันทึกข้อมูลยาที่มาจาก Provider รายอื่น ที่ไม่ได้มีจุดประสงค์เพื่อ request ได้ด้วย |
MedicationDispense | 2 | บันทึกข้อมูลการจ่ายยาไปถึง Patient เป็น resource ประเภท Event หมายถึงเป็นการบันทึกสิ่งที่เกิดขึ้นจริง โดยเป็นการตอบสนองต่อ MedicationRequest |
MedicationAdministration | 2 | บันทึกข้อมูลการนำยาเข้าสู่ร่างกายของ Patient จริง ๆ เป็น Event resource เช่นเดียวกัน |
MedicationStatement | 3 | ใช้เก็บข้อมูลรายการยาที่ Patient กำลังใช้อยู่, ได้ใช้ในช่วงที่ผ่านมา, หรือกำลังจะใช้ในอนาคตอันใกล้ ไม่ได้มีการระบุเวลาที่ชัดเจนว่าได้ยาตอนไหน ข้อมูลใน resource เป็นข้อมูลที่มาจากคนไข้เอง หรือมาจาก clinician ก็ได้ เป็น resource ที่ไม่ได้อยู่ใน workflow การสั่งยาโดยตรง แต่ใช้ในการบรรยายภาพรวมมากกว่า ตาม spec ระบุว่าเป็น resource ที่ใช้ทำ active medication list |
Medication | 3 | ใช้เก็บข้อมูลรายละเอียดของยาตัวหนึ่ง ๆ ส่วนใหญ่ไม่ค่อยได้ใช้ เพราะเรามักใช้วิธี reference external terminology ที่มีรายละเอียดยาอยู่แล้วมากกว่า แต่ resource นี้ก็สามารถใช้ได้กรณียังไม่มีข้อมูลใน terminology หรือต้องการใส่รายละเอียดเพิ่มเติม |
MedicationKnowledge | 0 | เอาไว้บันทึกข้อมูลที่เป็นความรู้เกี่ยวกับยานั้น ๆ เช่น ประเภทยา รูปภาพยา ราคายา ฯลฯ |
Immunizations (URL)
Resource | Maturity | Description |
---|---|---|
Immunization | 3 | ใช้บันทึกข้อมูลวัคซีนที่ Patient (ทั้งคนและสัตว์) เคยได้รับเข้าสู่ร่างกาย (administrated) ทั้งปัจจุบันและอดีต ไม่ว่าจะได้รับที่ใด แต่ไม่รวมถึงการให้สิ่งที่ไม่ใช่วัคซีนโดยตรง แม้ว่าสิ่งนั้นอาจสร้างภูมิคุ้มกันได้ |
ImmunizationRecommendation | 1 | เอาไว้บันทึกวัคซีนที่ Patient ควรจะได้รับในอนาคต สำหรับช่วงเวลาใดเวลาหนึ่ง |
ImmunizationEvaluation | 0 | เอาไว้ประเมินว่าการได้รับวัคซีนครั้งนั้น ๆ valid ตามแนวปฏิบัติที่แนะนำหรือไม่ |
11. Workflow (URL)
เป็น module ที่เกี่ยวข้องกับการบันทึกข้อมูลกิจกรรมต่าง ๆ ที่เกิดขึ้นในระบบที่เราสนใจ เช่น การขอให้คน/องค์กรอื่นทำกิจกรรมบางอย่าง การติดตามว่ากิจกรรมต่าง ๆ ถึงขั้นตอนไหนแล้ว กิจกรรมดังกล่าวคืออะไร มีขั้นตอนอย่างไรบ้าง ต้องทำอะไรก่อนหลัง เป็นต้น แบ่ง resource ในกลุ่มนี้เป็น 3 กลุ่มย่อย
Infrastructure
Resource | Maturity | Description |
---|---|---|
Task | 2 | เป็น resource หลักในการบันทึกว่ากิจกรรมที่ต้องทำคืออะไร และใช้ติดตามสถานะของกิจกรรมนั้นใน workflow ว่าถึงขั้นไหนแล้ว เป็น resource ที่ยอมรับว่าผมก็ไม่ค่อยเข้าใจครับ เท่าที่เข้าใจคือ Task จะเข้ามาเกี่ยวเมื่อจะใช้ FHIR ในการ execute workflow ด้วย (Workflow Management Pattern) แต่อ่านในหน้านี้ก็เหมือนว่าไม่ว่าจะขอให้ใครทำอะไรก็ควรใช้ Task resource สรุปคือขอเวลาไปทำความเข้าใจประเด็นนี้ก่อนครับ เดี๋ยวมาเขียนเพิ่ม |
Scheduling
Resource | Maturity | Description |
---|---|---|
Schedule | 3 | เป็น container ของ Slot เอาไว้ระบุช่วงเวลาที่จะใส่ Slot เข้ามา พร้อมทั้งระบุรายละเอียดอื่น ๆ ของช่วงเวลานั้น เช่น เป็นบริการอะไร ใครจะเป็นคนให้บริการ ฯลฯ |
Slot | 3 | ช่วงเวลาที่อยู่ใน Schedule ซึ่งคนที่เราให้ความสนใจ (เช่น แพทย์) จะอนุญาตให้ผู้อื่นสามารถจอง (Book) เพื่อรับบริการได้ และสามารถใช้ติดตามสถานะของ Slot นั้นได้ เช่น ถ้าไม่ว่างแล้ว status ก็เป็น busy |
Appointment | 3 | เอาไว้เก็บข้อมูลการขอนัด (request) ไม่ว่าจะเป็นอดีตหรืออนาคต การนัดคือการวางแผนพบกันของบุคคลที่เกี่ยวข้อง เพื่อเกิดเป็น Encounter |
AppointmentResponse | 3 | เอาไว้ตอบ request การขอนัด |
Clinical Process
Resource | Maturity | Description |
---|---|---|
ServiceRequest | 2 | เอาไว้บันทึกการขอ (request) โดยบุคคลหรือหน่วยงานหนึ่ง ไปยังบุคคลหรือหน่วยงานอีกหน่วยหนึ่งดำเนินบริการอย่างใดอย่างหนึ่ง ทั้งการขอตรวจ ขอรักษา ขอปรึกษา หรือขอให้ทำอะไรก็ตาม ที่ไม่มี resource อื่นที่จำเพาะเจาะจงกว่า (เช่น การขอให้จ่ายยามี MedicationRequest ที่จำเพาะกว่า จึงไม่ได้ใช้ ServiceRequest ในกรณีนี้) |
NutritionOrder | 2 | ใช้บันทึก order อาหาร (ทั้งทางปากและทางสายยาง) และการให้โภชนากรอื่น ๆ |
VisionPrescription | 2 | ใช้บันทึก order ให้ตัดแว่น หรือจ่าย contact lens ให้ Patient |
ActivityDefinition | 2 | เป็น definition resource คือเอาไว้นิยามว่า activity ที่เราสนใจนั้นมีลักษณะอย่างไร เพื่อให้ resource กลุ่มที่เป็น request resource มาเรียกใช้ (ขอให้คนอื่นทำ activity ที่ define ไว้) จากนั้นให้ resource กลุ่ม event resource มาบันทึกสิ่งที่เกิดขึ้นตอบสนองต่อ request นั้น ๆ |
PlanDefinition | 2 | เป็น definition resource เช่นกัน แต่เป็นภาพใหญ่ คือใช้ define ว่าแผนควรเป็นอย่างไร ประกอบด้วย activity อะไรบ้าง ใช้ประโยชน์ได้ในแง่ที่ค่อนข้าง advance เช่น clinical decision support, การติดตามคุณภาพ เป็นต้น |
DeviceRequest | 1 | เอาไว้ order พวก Device เช่น implant หรืออุปกรณ์อื่น ๆ เช่นไม้ค้ำ |
DeviceUseStatement | 0 | หลักการเดียวกับ MedicationStatement ครับ คือเอาไว้บันทึกว่า Patient ใช้ Device อะไรบ้าง |
SupplyRequest | 1 | ใช้ในงาน inventory management เอาไว้ขอ medical supply ต่าง ๆ (Medication, Device, Substance) เพื่อวัตถุประสงค์ต่าง ๆ เช่น ขอมารักษาคนไข้, ขอมา stock ที่ unit |
SupplyDelivery | 1 | เอาไว้ตอบ SupplyRequest ว่า deliver หรือไม่ อย่างไร |
12. Financial (URL)
เป็น module ที่เอาไว้จัดการข้อมูลเรื่องการเงินต่าง ๆ ที่เกิดขึ้นใน healthcare system นั่นคือ ข้อมูลที่เกิดขึ้นระหว่าง patient, provider, payer, policy maker เรื่องการเงินใน healthcare นี่มีความซับซ้อนของเขาซึ่งผมก็ไม่ค่อยเข้าใจเท่าไหร่ อันนี้เลยขอเขียนคร่าว ๆ ละกันนะครับ แบ่ง resource ในกลุ่มนี้เป็น 4 กลุ่มย่อย
Support (URL)
พวกนี้ก็เป็นข้อมูลสำหรับการบริหารจัดการ
Resource | Maturity | Description |
---|---|---|
Account | 2 | จริง ๆ อันนี้อยู่ใน Administrative module แต่เขียนซ้ำ เอาไว้เก็บข้อมูลบัญชีทางการเงินของคนไข้ มีสิทธิ์การรักษาอะไรบ้าง กับที่ไหน ถ้าเคลมไม่ได้ใครจะจ่าย เป็นต้น แต่ไม่ได้เก็บยอดดุลในทางบัญชี (ณ เวอร์ชั่นนี้) |
Contract | 1 | เก็บข้อมูลสัญญาทางกฎหมาย ในรูปแบบที่ machine processible เป็นการบังคับทางเดียว (เช่น นโยบาย) หรือเป็นการตกลงร่วมกันของหลายฝ่ายก็ได้ |
Coverage | 2 | เอาไว้เก็บข้อมูลว่าใครจ่ายค่ารักษาครั้งนั้น บริษัทประกัน หรืออาจเป็น self-pay เป็นข้อมูลในภาพรวม พวกข้อมูลที่อยู่ในบัตรประกัน ไม่ได้ลงรายละเอียดมากไปถึงรายละเอียดในกรมธรรม์ |
CoverageEligibilityRequest | 2 | เอาไว้ส่ง Request ไปยัง insurer (เช่น บริษัทประกัน) โดยส่งข้อมูล Patient และ Coverage ไป เพื่อถามว่า coverage เป็นยังไง |
CoverageEligibilityResponse | 2 | เอาไว้ให้ insurer ตอบกลับ CoverageEligibilityRequest |
EnrollmentRequest | 0 | เอาไว้ส่ง Request การขอเข้าไปอยู่ใน Coverage ที่ต้องการไปยัง insurer เช่น เอาไว้สมัครประกัน |
EnrollmentResponse | 0 | เอาไว้ให้ insurer ตอบกลับ EnrollmentRequest |
Billing (URL)
Resource | Maturity | Description |
---|---|---|
Claim | 2 | เอาไว้ส่งข้อมูลรายละเอียดบริการที่ได้ทำกับ Patient หรือกำลังจะทำ ส่งไปให้ insurer เพื่อประเมินการเบิกจ่าย ใช้ได้ทั้งในขั้นการเคลม (รักษาไปแล้วส่งไปเบิก), การ preauthorization (ส่งไปถามว่าถ้ารักษาจะเบิกได้ไหม), การ predetermination (ส่งไปถามว่าเบิกอะไรได้บ้าง) เสริม: ถ้าอยากติดตามสถานะการ Claim ใช้ Task |
ClaimResponse | 2 | เอาไว้ให้ insurer ตอบกลับ Claim |
Payment (URL)
Resource | Maturity | Description |
---|---|---|
PaymentNotice | 2 | เอาไว้แจ้งสถานะของการจ่ายเงิน นั่นคือ กำลังจะต้องจ่าย, จ่ายไปแล้ว, ยกเลิกแล้ว ให้แก่ผู้เกี่ยวข้องรับทราบ |
PaymentReconciliation | 2 | อันนี้ผมไม่ค่อยเข้าใจ เขาบอกไว้เก็บข้อมูล bulk payment ที่ payor เอาไว้แจ้งว่าได้จ่ายเงินไปเท่าไหร่ |
Other (URL)
Resource | Maturity | Description |
---|---|---|
ExplanationOfBenefit | 2 | เป็น resource ที่รวบข้อมูลจาก Claim, ClaimResponse, Coverage, Account แล้วตัดส่วนที่เป็นความลับของ provider, insurer ออก เพื่อเป็นข้อมูลให้ Patient รับทราบข้อมูลเกี่ยวกับการเคลมในครั้งนั้น หรือเป็นข้อมูลเอาไว้ analytic หรือรายงานต่อราชการต่อ |
Level 5 – Clinical Reasoning
13. Clinical Reasoning (URL)
Module นี้เป็นการใช้งาน FHIR ขั้นค่อนข้าง advance ซึ่งผมก็ไม่ได้เข้าใจเท่าไหร่ ขอสรุปคร่าว ๆ ตามที่เข้าใจนะครับ
Resource | Maturity | Description |
---|---|---|
GuidanceResponse | 2 | เอาไว้ตอบการเรียก clinical decision support service เช่น แจ้งผลการ evaluation, คำแนะนำให้ทำการกระทำต่าง ๆ |
Library | 2 | เป็นแหล่งรวม knowledge asset definitions ซึ่ง asset เหล่านี้อาจเขียนด้วยรูปแบบอื่น ๆ ที่ไม่ใช่ FHIR ก็ได้ (เช่น CQL) หรือเป็น FHIR ก็ได้ (เช่น PlanDefinitnion) |
Measure | 2 | เอาไว้เป็น definition ของเครื่องมือวัดเชิงข้อมูลต่าง ๆ เช่น clinical quality measure, public health indicator, หรือ population analytics measure |
MeasureReport | 2 | เอาไว้ตอบกลับการประเมิน Measure ผ่านทาง operation $evaluate-measure |
RequestGroup | 2 | อันนี้ผมก็ไม่ค่อยเข้าใจครับ บอกว่าเอาไว้จัดกลุ่ม request ของกิจกรรมที่เกี่ยวเนื่องกันที่ต้องพึ่งพาอีกกิจกรรมหนึ่ง (เช่น ให้ยา A หลังจากยา B) มักเกิดจากการใช้ PlanDefinition กับ Patient |
ก็จบลงแล้วครับ สำหรับการสรุป resource ที่สำคัญ ๆ ใน FHIR R4 หวังว่าจะเป็นประโยชน์นะครับ 😄