ผมว่าความงงอย่างหนึ่งของคนที่เข้ามาทำงานกับ 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 หวังว่าจะเป็นประโยชน์นะครับ 😄

FHIR