4 ขั้นตอนสู่การแลกเปลี่ยนข้อมูลสุขภาพ

ด้วย HL7 FHIR

นพ. รัฐ ปัญโญวัฒน์
20 เมษายน 2563
 แนะนําตัว

• นพ. รัฐ ปัญโญวัฒน์

• Health Informatics, MSc

Karolinska Institutet, Sweden

• Chief Information Officer

บริษัท รพ.ราชพฤกษ์ จํากัด (มหาชน)

• https://rath.asia
 4 ขั้นตอน

1. สร้าง Implementation Guide

2. ติดตั้ง FHIR Servers / Facade

3. สร้าง FHIR Client Application

4. แลกเปลี่ยนตาม Implementation
Guide ที่สร้างไว้
 ขั้นตอนที่ 1:
สร้าง Implementation Guide
 มาตรฐาน FHIR
เป็นมาตรฐานที่กําหนดว่าจะแลกเปลี่ยนข้อมูลสุขภาพกันอย่างไรดี

1. กําหนดวิธีการแลกเปล่ี่ยน
ตัวหลักคือ RESTful API

2. กําหนดโครงสร้างสิ่งที่จะแลกเปลี่ยนกัน
ด้วยการประกอบหน่วยย่อยของการแลกเปลี่ยน (เรียกว่า Resources) ต่าง ๆ เข้าด้วยกัน
จนได้ข้อมูลที่ต้องการ แล้วส่งในรูปแบบ JSON/XML*

* จริง ๆ ส่งเป็น RDF (Turtle) ได้ด้วย แต่คนนําไปใช้น่าจะยังน้อย // ในอนาคตอาจมีการเพ่ิม, ลด, เปลี่ยนแปลงรูปแบบการแลกเปลี่ยน

 โครงสร้างของ JSON / XML
ที่จะแลกเปลี่ยน
ตัวอย่าง Data Type บางส่วน

Element Element Element

string integer uri
(Primitive) (Primitive) (Primitive)

Element Element Element Element

CodeableConcept Quantity HumanName
(Complex) (Complex) (Complex)

Element Element Element

Contributor Extension Dosage
(Metadata) (Special) (Special)

หน่วยย่อยที่สุดของข้อมูล แต่ละ element จะมี Data Type

เรียกว่า Element บอกประเภทของ element นั้น
 โครงสร้างของ JSON / XML
ที่จะแลกเปลี่ยน (2)
Resource เป็นหน่วยเล็กที่สุดที่สามารถแลกเปลี่ยน
• เพ่ิม contstraint
ผ่าน RESTful API ได้
• เพิ่ม extensions
• กําหนด ValueSet
Resource
Resource: 

• ฯลฯ

Patient
Element Element Element Element

Element Element Element Element

Resource 

with Profile: 

ThaiPatient
Element Element Element Element

Resource มักไม่สามารถใช้ได้เลย เราต้อง

แต่ละ Resource จะประกอบ
เอามาปรับให้ตรงกับความต้องการ
ด้วย element ต่าง ๆ โดยการสร้างเป็น Profile
 โครงสร้างของ JSON / XML
ที่จะแลกเปลี่ยน (3)
Resource 

Resource: 

with Profile: 

Patient
ThaiPatient

RESTful API

ผู้ส่ง Resource: Bundle ผู้รับ

Resource 

Resource: 

Metadata with Profile: 
 etc.
Medications
ThaiPatient

ส่งข้อมูลไปที่ผู้รับ โดยใส่ Resource, Profile หรือ Bundle

เข้าไปใน body ของ HTTP request/response แล้วส่งผ่าน RESTful API
 Resources

• หน่วยเล็กที่สุดของข้อมูลที่แลกเปลี่ยนกันผ่าน RESTful API ได้

• เปรียบเหมือน Class ใน Object-oriented paradigm —> เวลาจะใช้

ก็สร้าง instance ของ resource (Class) ขึ้นมา

Element (s)
 ตัวอย่าง JSON ของ
Patient Resource Instance (1)
{"resourceType":"Patient","id":"f001","text":
{"status":"generated","div":"<div xmlns=\"http://
www.w3.org/1999/xhtml\"></div>"},"identifier":
[{"use":"usual","system":"urn:oid:2.16.840.1.113883.2.4
.6.3","value":"738472983"},
{"use":"usual","system":"urn:oid:2.16.840.1.113883.2.4.
6.3"}],"active":true,"name":
[{"use":"usual","family":"van de Heuvel","given":
["Pieter"],"suffix":["MSc"]}],"telecom":
[{"system":"phone","value":"0648352638","use":"mobile"}
,
{"system":"email","value":"p.heuvel@gmail.com","use":"h
ome"}],"gender":"male","birthDate":"1944-11-17","deceas
edBoolean":false,"address":[{"use":"home","line":["Van
Egmondkade 23"],"city":"Amsterdam","postalCode":"1024
RJ","country":"NLD"}],"maritalStatus":{"coding":
[{"system":"http://terminology.hl7.org/CodeSystem/v3-
MaritalStatus","code":"M","display":"Married"}],"text":
"Getrouwd"},"multipleBirthBoolean":true,"contact":
[{"relationship":[{"coding":[{"system":"http://
terminology.hl7.org/CodeSystem/
v2-0131","code":"C"}]}],"name":
{"use":"usual","family":"Abels","given":
["Sarah"]},"telecom":
[{"system":"phone","value":"0690383372","use":"mobile"}
]}],"communication":[{"language":{"coding":
[{"system":"urn:ietf:bcp:47","code":"nl","display":"Dut
ch"}],"text":"Nederlands"},"preferred":true}],"managing
Organization":{"reference":"Organization/
f001","display":"Burgers University Medical Centre"}}

http://hl7.org/fhir/patient-example-f001-pieter.json.html
 ตัวอย่าง JSON ของ
Patient Resource Instance (1)
{"resourceType":"Patient","id":"f001","text":
{"status":"generated","div":"<div xmlns=\"http://
www.w3.org/1999/xhtml\"></div>"},"identifier":
[{"use":"usual","system":"urn:oid:2.16.840.1.113883.2.4
.6.3","value":"738472983"},
{"use":"usual","system":"urn:oid:2.16.840.1.113883.2.4.
6.3"}],"active":true,"name":
[{"use":"usual","family":"van de Heuvel","given":
["Pieter"],"suffix":["MSc"]}],"telecom":
[{"system":"phone","value":"0648352638","use":"mobile"}
,
{"system":"email","value":"p.heuvel@gmail.com","use":"h
ome"}],"gender":"male","birthDate":"1944-11-17","deceas
edBoolean":false,"address":[{"use":"home","line":["Van
Egmondkade 23"],"city":"Amsterdam","postalCode":"1024
RJ","country":"NLD"}],"maritalStatus":{"coding":
[{"system":"http://terminology.hl7.org/CodeSystem/v3-
MaritalStatus","code":"M","display":"Married"}],"text":
"Getrouwd"},"multipleBirthBoolean":true,"contact":
[{"relationship":[{"coding":[{"system":"http://
terminology.hl7.org/CodeSystem/
v2-0131","code":"C"}]}],"name":
{"use":"usual","family":"Abels","given":
["Sarah"]},"telecom":
[{"system":"phone","value":"0690383372","use":"mobile"}
]}],"communication":[{"language":{"coding":
[{"system":"urn:ietf:bcp:47","code":"nl","display":"Dut
ch"}],"text":"Nederlands"},"preferred":true}],"managing
Organization":{"reference":"Organization/
f001","display":"Burgers University Medical Centre"}}

http://hl7.org/fhir/patient-example-f001-pieter.json.html
 ตัวอย่าง JSON ของ
Patient Resource Instance (2)
"resourceType": "Patient",
"id": "example",
"text": {
"status": "generated",
"div": “เอาไว้แสดงผลในโปรแกรม เช่น HTML"
},
"identifier": [
{
"use": "usual",
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "MR"
}
]
},
"system": "urn:oid:1.2.36.146.595.217.0.1",
"value": "12345",
"period": {
"start": "2001-05-06"
},
(ข้อมูลใน JSON ยังไม่สิ้นสุด)
 ตัวอย่าง JSON ของ
Patient Resource Instance (3)
"active": true,
"name": [
{
"use": "official",
"family": "Chalmers",
"given": [
"Peter",
"James"
]
},
{
"use": "usual",
"given": [
"Jim"
]
},
{
"use": "maiden", HumanName Data Type
"family": "Windsor",
"given": [
"Peter",
"James"
(ข้อมูลใน JSON ยังไม่สิ้นสุด)
 Profiles

• FHIR Resource ออกแบบมาให้ครอบคลุมการใช้งานส่วนใหญ่ แต่การใช้

งานจริงย่อมมีบริบทที่ต่างกันไปในแต่ละที่ จึงต้องมีการสร้างข้อจํากัด
(Constraint) ให้ Resource เพื่อสร้างเป็น Profile

• สิ่งที่ Profile ทําได้:

• จํากัดว่าจะให้ element ไหน เป็น required, อันไหนจะตัดออก

• กําหนด item ให้ element ที่เป็นพวกตัวเลือก เช่น เพศ, ประเภทต่าง ๆ

• เพิ่มข้อมูลที่ต้องการด้วย Extensions

• กําหนดว่าจะให้ API ทําอะไรได้บ้าง เช่น GET only, ห้าม PUT

• กําหนดว่าจะให้ Search จากอะไรได้บ้าง

• การตรวจสอบความสอดคล้อง (Conformance) ว่าข้อมูลถูกต้องตาม Profile หรือไม่

 ตัวอย่าง Profile -
US Core Patient Profile

เพิ่ม Extension ด้าน เชื้อชาติ, เผ่าพันธุ์ และ เพศ

ตอนเกิด

เปลี่ยน identifier เป็น required และทุกรายการ

ต้องมีระบบการ identify (system) และค่า (value)

เปลี่ยน name เป็น required และอย่างน้อยต้อง

มีชื่อหรือนามสกุล

และอื่น ๆ อีกมากมาย
 Profiles (2)
Profile สามารถสร้างมาจาก FHIR Core Resources หรือสร้างมาจาก
Profile อื่น (เรียกว่า Derived Profile)

FHIR Core Patient Resource

จําเพาะเจาะจงมากขึ้น
Constraint

US Core Patient

Constraint เพิ่ม

Mayo Clinic Patient

 Implementation Guide (IG)

• มีไว้อธิบายให้ implementer ทราบว่าถ้าจะนํา FHIR ไปใช้ใน

use case ที่ต้องการ ต้องทําอย่างไรบ้าง

• ตัวอย่าง IG
• US Core (National IG ของ USA)

• AU Base (National IG ของออสเตรเลีย)

• International Patient Summary (IPS - IG ที่กําลังผลักดันไว้แลกเปลี่ยนสรุปข้อมูล

คนไข้ระหว่างประเทศ)

• อื่น ๆ ดูได้จาก https://registry.fhir.org/guides

 Implementation Guide (2)
• เนื้อหาของ IG โดยทั่วไป

• คําบรรยาย (Narrative) ว่าเกี่ยวกับอะไร, ใครสร้าง, ใช้ยังไง, license,

version, แผนภาพต่าง ๆ ฯลฯ

• Profiles และ Extensions ที่เกี่ยวข้อง

• Terminology ที่ใช้ —> Value Sets, Code Systems, Concept Map

• อธิบาย API ที่เปิดให้ใช้ (Capability Statement, Search Parameter,

ฯลฯ)

• Test case, Security, และอื่น ๆ

ตัวอย่าง IG - US Core
 Tools ในการสร้าง Profiles/ IG

• ClinFHIR (URL)

• Firely - Forge (URL)

• Trifolia-on-FHIR (URL)
 ขั้นตอนที่ 2:
ติดตั้ง FHIR Server / Facade
 FHIR Servers

• เครื่อง Server ที่มีไว้ response ต่อ FHIR REST API request

• Server จะต้องประกาศว่าตนเองทําอะไรได้บ้าง support API ไหน

บ้าง operation ไหนบ้าง (ไม่จําเป็นต้องทําได้ทุกอย่างที่อยู่ใน FHIR
specification)

• Generic FHIR Server

FHIR server ที่ support API ทั่ว ๆ ไป และมี data storage เป็นของตนเอง

• FHIR Facade หรือ FHIR Adapter

FHIR server ที่ไม่มี data storage (ใช้ data storage ที่รพ.มีอยู่แล้ว เช่น HIS)
 การเชื่อมต่อกับ HIS
• มี 2 วิธี คือ 1) ทํา FHIR Facade และ 2) ใช้ FHIR Client Application

Datacenter ของรพ. โลกภายนอก

วุ้นแปลภาษา

FHIR HTTP (GET,POST, etc.)

FHIR resources
Create/Read/ FHIR Facade

Update/Delete

FHIR HTTP (GET,POST, etc.)

FHIR resources
HIS Server & Database FHIR Client App

ไม่ใช่ Server ทําแทนไม่ได้

 1. เอา FHIR Facade ไว้ที่รพ.

FHIR
GET
/PO
FHIR ST
Facade Res
ou rces
โรงพยาบาล 1 (HIS A)

O S T
ET /P
IR G
FH rc es
es ou
IR R
FH
Regional / Central
Data Repository
Facade
with FHIR Client
โรงพยาบาล 2 (HIS B)
 2. เอา FHIR Facade ไว้ที่ส่วนกลาง

FHI
RG
ET/
FHI POS
RR T
eso Native GET/POST
urc
es
โรงพยาบาล 1 (HIS A)
Native response
with FHIR Client
ST
/ P O Facade
ET
G
H I R rc es
F s ou
R e
I R
FH
Regional / Central
Data Repository

โรงพยาบาล 2 (HIS B)
with FHIR Client
 3. ใช้ Generic FHIR Server +
ทุกที่มี FHIR Client

FHI
RG
ET/
FHI POS
RR T
eso FHIR GET/POST
urc
es
โรงพยาบาล 1 (HIS A)
FHIR Resources
with FHIR Client
O S T
T / P Generic
G E
H I R c e s FHIR
F ou r
R e s
I R Server
FH
Regional / Central
Data Repository
with FHIR Client
โรงพยาบาล 2 (HIS B)
with FHIR Client
 4. ทุกที่มี FHIR Facade แล้วหา Router

FHI
RG
ET/
FHI POS
Facade RR T
eso FHIR GET/POST
urc
es
โรงพยาบาล 1 (HIS A)
FHIR Resources
with FHIR Facade
O S T
T / P Router
G E
R
FHI u rc es Facade
e s o
R R
FHI
Regional / Central
Data Repository
Facade
with FHIR Facade
โรงพยาบาล 2 (HIS B)
with FHIR Facade
 Terminology ใน FHIR

• Terminology มีขึ้นเพื่อให้สื่อสารถึงเรื่องเดียวกัน

• Terminology ใน FHIR ใช้ใน Resource ที่มีการเลือก item จาก

รายการที่เรากําหนดไว้ (Value Sets) ซึ่งเราเลือกมาจากระบบรหัส
(Code Systems) อีกทีหนึ่ง

• เช่น Code Systems SNOMED-CT มีกว่า 300,000 รหัส แต่เราจะใช้

ใน Resource: Condition ซึ่ง Resource นี้จํากัดให้ใส่ค่าเฉพาะ code
ที่เป็น condition เท่านั้น (Value set: Condition/Problem/
DiagnosisCodes)
 Terminology Server
• การบริหารจัดการ Terminology มีความซับซ้อน ซึ่ง app ของเราส่วน
ใหญ่ไม่ได้ต้องการจัดการความซับซ้อนตรงนี้

• จึงมักมีผู้ผลิต Server เฉพาะทางด้านนี้เรียก Terminology server เช่น

Ontoserver ของ CSIRO

• เราจึงอาจเห็นในหลาย ๆ FHIR implementation มีการแยก Terminology

server ออกมา

• แต่ FHIR Server หลาย ๆ ตัว (เช่น HAPI) มีความสามารถในการจัดการ

Terminology มาด้วยในตัว (เป็น terminology server ในตนเอง) แต่
ความสามารถก็จะไม่เท่า Terminology Server เฉพาะทาง
 FHIR Server เจ้าเด่น ๆ

• HAPI FHIR (จริง ๆ เป็นทั้ง client, server, และ data storage)

เป็น Open source URL: https://hapifhir.io

• IBM FHIR Server เป็น Open source เช่นกัน

URL: https://ibm.github.io/FHIR/

• Fire.ly - Vonk FHIR Server URL: https://vonk.fire.ly

• Health Samuri - AidBox

URL: https://www.health-samurai.io/aidbox
 ขั้นตอนที่ 3:
สร้าง FHIR Client Application
 รูปแบบการส่งข้อมูล
เมืองไทยน่าจะใช้ RESTful API เป็นหลัก*

HTTP POST request with Bundle body with Resource body

Transaction
 Document
 Message


Resource
Bundle Bundle Bundle

RESTful API
FHIR Client FHIR Server

HTTP GET request (search interaction)

RESTful API
Searchset

Bundle
FHIR Server
FHIR Client

* Document และ Message Bundle สามารถส่งด้วย protocol อื่นที่ไม่ใช่ RESTful API ได้
 การส่งข้อมูลเป็น Bundle
• การจับ Resources มาไว้ด้วยกัน เพื่อรับส่งระหว่าง client และ server ตาม
วัตถุประสงค์นั้น ๆ

• ประเภทหลัก ๆ (Type)

• Transaction: ใช้อ่าน/เขียน Resources หลาย ๆ อย่างใน HTTP request เดียว

• Document: เอกสารที่มีข้อมูลคงที่ ณ เวลาที่ออกเอกสาร ไม่สามารถ

เปลี่ยนแปลงข้อมูลย้อนหลังได้ มีผู้รับผิดชอบชัดเจน เช่น ใบส่งต่อผู้ป่วย

• Message: ใช้แทนการส่งข้อมูลแบบ messaging เช่น HL7 V2

• Searchset: ใช้ตอบกลับ search request โดยตอบกลับเป็น bundle ของ

Resources ที่ตรงกับผลการค้นหา
 FHIR RESTful API
Interaction HTTP method คําอธิบาย
read GET อ่านค่า state ล่าสุดของ instance นั้น ๆ ของ resource
vread GET อ่านแบบระบุเวอร์ชั่น
Instance
update PUT อัพเดท instance ด้วย id (หรือสร้างใหม่ถ้าไม่มี)
Level
patch PATCH อัพเดท instance แค่บางส่วน (partial update)
delete DELETE ลบ instance นั้น
history GET ดูประวัติการแก้ไขของ instance
create POST สร้าง instance ใหม่ของ resource ที่ระบุ
Type
Level
search GET/POST ค้นหาทั้ง resource type นั้น เช่น หา Patient ทั้งหมด
history GET ดูประวัติการแก้ไขที่เกิดกับ resource นั้น
capabilities GET ดูว่า server ทําอะไรได้บ้าง ตาม capability statement
Whole System batch/transaction POST แก้ไข/สร้าง/ลบ หลาย ๆ resource ใน request เดียว
Level history GET ดูประวัติการแก้ไขที่เกิดกับ resource ทั้งหมด
search GET ค้นหาจาก resource ทั้งหมด
FHIR RESTful API (2)

ตารางจาก https://www.hl7.org/fhir/http.html
 FHIR Operations
• สิ่งที่สามารถทํากับ Resource ต่าง ๆ แต่เพิ่มเติมนอกเหนือจาก
HTTP interactions เราสามารถสร้างเพิ่ม operation เองได้

ตารางจาก https://www.hl7.org/fhir/operationslist.html
 FHIR Client Application

• HTTP interaction และ operations ทั้งหมด สามารถทําได้ผ่าน API

client ทั่ว ๆ ไปเช่น Postman, Insomnia หรือแม้แต่ cURL

• แต่การจะคอยสร้าง instance ของ Resource, การคอยกําหนด

URL endpoint เหล่านี้ก็อาจไม่สะดวกนัก

• จึงต้องมี Application ฝั่ง client ที่ทําให้ทํางานง่ายขึ้นมาก

• ซึ่งการจะสร้าง App เหล่านี้ สามารถทุ่นเวลาด้วยการใช้ 3rd party

FHIR Client Library ได้ (เหมือนเราใช้ Library อื่น ๆ พัฒนา
โปรแกรม)
Open Source Client Library ที่เด่น ๆ

• HAPI (JAVA) (URL)

• Firely .NET API (URL)

• Client-py (Python) (URL)

• FHIR.JS (URL)

• Ruby FHIR Client (URL)

• ดูรายชื่อทั้งหมดได้ที่: https://wiki.hl7.org/
Open_Source_FHIR_implementations
 ขั้นตอนที่ 4:
แลกเปลี่ยนตาม Implementation
Guide ที่สร้างไว้
 สรุปขั้นตอนการแลกเปลี่ยนข้อมูล
1. ต้องการส่งข้อมูลใด ลองสร้าง Profile ของสิ่งนั้นดูก่อน ดูว่ามี
Resource ที่ตอบโจทย์อยู่แล้วหรือไม่ หากมีจะสร้าง Profile อย่างไร
(กําหนด Constraint, กําหนด Value Set, กําหนด Extensions)

2. ติดตั้ง FHIR Server หรือ FHIR Facade ณ จุดใดจุดหนึ่ง (หรือ

หลายจุด) ของการแลกเปลี่ยน

3. ติดตั้ง FHIR Client application ณ จุดที่ต้องการขอหรือส่งข้อมูล

กับ FHIR Server

4. ทําการแลกเปลี่ยนตาม Profile/Implementation Guide ที่สร้างไว้

Q&A
 ขอบคุณครับ

สนใจแลกพูดคุยเปลี่ยนเพิ่มเติม ติดต่อ: https://rath.asia หรือช่องทางเหล่านี้

Page: Rath Panyowat @rathpanyowat Rath Panyowat