Contenu connexe Similaire à 中正大學/FHIR 快速掃描 R4 版本 (20) Plus de Lorex L. Yang (7) 中正大學/FHIR 快速掃描 R4 版本8. FHIR 是什麼?
• 是一種新興的醫療資訊交換標準,目前被廣泛用於歐美國家
• 由 HL7 International(國際健康資訊第七層協會)制定
• 奠基於 HL7 v2 & HL7 v3 標準
• 相容過去 30 年來主要相關標準
• 本身就是各醫療健康領域的 SOP 模型
• 本身就是儲存資料庫
• 提供標準化的 Web API 供主流資訊系統介接,現有資訊人員容易上手
• 把整個醫療流程/體系中會接觸到的所有資料標準化為單一資料結構
• 是一個醫療健康系統實作框架
• 主要目標為
促進醫療單位有效溝通醫療相關資訊
廣泛應用於多種設備,包含但不限於電腦、手機、平板等裝置
9. Review: So what is FHIR?
• 基本上就是一個資料模型
• 把整個醫療流程/體系中會接觸到的資料全部標準化為單一資料結構
• 支援多種不同資料格式(XML or JSON)
• 採用主流資訊實作標準
沒醫學基礎的工程師也可以理解,很好上手
要跟其他系統對接也很方便
• 可讀性高
醫療人員不用懂程式設計,也能看得懂資料
• 格式嚴謹,Document 齊全且明確
• Developer Friendly ❤
12. FHIR 結構
• 對醫療人員/醫學系學生來說,
FHIR 是一種描述醫療資源/行為/數據/流程…etc 的方法
• 對開發人員/醫資or醫工系學生來說,
我們熟悉的 FHIR 事實上是一堆 Data Structure
• 每一個醫療資源/行為/數據/流程…etc 都是一個 Resource
• 依照不同的分類,FHIR 將幾個 Resource 組成一支 Module 方便檢視
14. Overview
• Resource Type
存放 Resource 類別,為必填選項
實務上 FHIR Server 會根據 Resource Type 去進行資料檢查,所以不能寫錯
• 流水號(id)
為這筆 Record 在 FHIR Server 裡面的唯一識別碼,通常由 Server 端產生
流水號為跨 Resource 共用,也就是有了 Patient/123 之後就不可能會有
Organization/123
Resource 內的 id 跟 identifier 不一樣
id 是目前這筆 Record 在這台 Server 內的流水號
identifier 則是這筆 Record 的唯一識別碼,不同 Server 間可以用同一個 identifier 來定位同一筆
資料
• Meta 資訊
為伺服器端產生的摘要資訊
記載變更次數、最後更新時間、Profile、資料來源……等
15. Overview
• 人類可讀區域(text)
記載人類可讀的摘要資訊與這筆 Record 目前的狀態
以 XHTML 格式存在,可以直接被網頁前端 Render
• 擴展資料(extension)
為 FHIR 中可擴展、本地化、客製化的資料
非必填,有需要的時候自行使用即可
• Resource 內容(data)
Resource 的資料本體,就是剛剛在文件看到的 Resource Content
通常 Server 會針對這邊的資料進行檢查,如果有問題就會噴錯
19. Data Structure? Data Format? Data
Type?
• 所謂的 Data Structure(資料結構),是對一組資料組成的定義
• 而 Data Format(資料格式),則是表達這組資料的方法(例如 XML、JSON 等)
• 一個 Data Structure 可以用許多不同的 Data Format 所表示
• 一個 Resource 只有一種 Structure,但是支援多種 Data Format
• 在開發實務上,並不需要認識所有的 Data Format,僅需挑一種來用即可
• 至於 Data Type(資料型態),則是定義一項資料值的類型(例如 Number、
String、Time…etc)
21. Data Type 四大類
• Simple / Primitive Types
大多是常見且格式定義明確的資料型態
例如 integer 是 “整數”、date 是 “日期”,兩者都有既定的格式
• Complex / General-Purpose Data types
顧名思義比較複雜,大多由數個型態為 Primitive Type 的元素組成
一個 Complex Type 內,甚至可以由其他 Complex Type 構成
• Metadata Types
拿來存放 metadata 的資料型態,大多在 R4 版本仍為 Trial Use 階段
• Special Purpose Data types
規範用於其他地方的資料型態
例如 Reference 為指向到另一筆資料的參照,Extension 為本地化/客製化資料
31. Core Resources
• Core Resources(鐵三角)
Patient-患者
Organization-組織
Practitioner-醫事人員
• 還有 Encounter
醫療照護事件的人事時地物
33. Clinical Resources
• Summary
Condition 所有症狀/主訴/診斷
Procedure 所有處置
FamilyMemberHistroy 病史/家族病史
• Diagnostic
Observation 檢驗值
DiagnosticReport 加上解釋的檢驗報告
Specimen
ImagingStudy 影像資料(相當於 DICOM Study)
QuestionaireResponse 問卷填寫結果
MolecularSequence 基因序列
34. Clinical Resources
• Medication
MedicationRequest 處方
MedicationDispense 發藥
MedicationAdministration 領藥/用藥
MedicationStatement
Medication 藥物
Immunization
ImmunizationRecommendation
36. Care Resources
• Care Provision
CarePlan 照護計畫
CareTeam 照護團隊
Goal 照護目標
ReferralRequest 轉診請求
ServiceRequest 服務(處置)請求
NutritionOrder 營養醫囑
RiskAssessment 風險評估
37. Base Resources
• Individuals
Person 自然人
RelatedPerson 關係人(家屬、照護者…etc)
PractitionerRole 醫護人員角色/職務
Group 群組
• Entities
Location 地點/位置
Device 裝置/設備
DeviceDefinition 設備種類定義
DeviceMetric 設備序列
HealthcareService 醫療照護服務
40. Clinical Reasoning Resources
• DecisionSupportServiceModule
GuidanceResponse
Measure
MeasureResponst
ActivityDefinition
ServiceDefinition
PlanDefinition
41. Financial & Insurance Resources
• Insuarance
Coverage 保險方案/身分
EligibilityRequest 保險身分確認請求
EligibilityResponse 保險身分確認回復(給付額度/如何報銷)
EnrollmentRequest 保險方案請求
EnrollmentResponse 保險方案回復
• Financial
Claim 申報/應收帳款
ClaimResponse 支付
PaymentNotice 收據
PaymentReconcillation 對帳單
ExplanationOfBenefit 支付紀錄
Account 帳戶
ChargeItem 計費項目
44. RESTful API 與一般 API 的比較
一般 API
• 獲取使用者資料 GET /getAllUsers
• 獲取使用者資料 GET /getUser/1
• 新增使用者資料 POST /createUser
• 更新使用者資料 GET /updateUser/1
• 刪除使用者資料 GET /deleteUser/1
RESTful API
• 獲取使用者資料 GET /users
• 獲取使用者資料 GET /user/1
• 新增使用者資料 POST /user
• 更新使用者資料 PUT /user/1
• 刪除使用者資料 DELETE /user/1
46. REST API 的應用情境
單一資源(例如 /user/1)
GET 列出該筆Resource與
其下的 Attributes
POST 在該筆Resource下新
增給定的 Attributes
PUT 使用給定的Resource
與Attributes 取代原有
Resource(整筆替換)
PATCH 只更新該筆Resource
下指定的 Attributes
(部分更新)
DELETE 刪除該筆Resource
多重資源(例如 /users)
GET 列出該資源組裡面所有
Resources
POST 在該資源組中新增
Resource
PUT 若該資源組中無指定
Resource,則新增
(跟POST 一樣),否
則就整筆替代該
Resource
DELETE 刪除整個資源組下的所
有 Resources
50. FHIR Server
• 考量到現場環境,當場下載並開一個 HAPI FHIR Server 並不是建議的選項
以下是幾個推薦的公開測試伺服器:
• 臺灣公開測試伺服器(推薦使用)
站點在國內,速度快,並支援 SSL 安全加密連線
https://hapi.fhir.tw/
• UHN 公開測試伺服器
為 HAPI FHIR 開發組織 UHN 提供的測試伺服器
http://hapi.fhir.org/
• 其他伺服器列表,請參考:
https://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing
56. 編輯剛剛的 Patient 資料
• PATCH https://hapi.fhir.tw/fhir/Patient/265/gender/male
• Payload 如右
60. 組織資料步驟
• 判定、或取得各欄位所屬的 Resource 與 Field Name,並建一張表對應
原始欄位 原始資料 對應欄位 資料格式
姓名 王大明 Patient.name HumanName
性別 男 Patient.gender code
(male | female | other |
unknown)
連絡電話 0912-345-678 Patient.telecom ContactPoint
聯絡地址 高雄市小港區大馬路999號 Patient.address Address
資料有效狀態 Yes Patient.active boolean
生日 84/01/01 Patient.birthDate date
61. 組織資料步驟
• 以 JSON 為例,去組織資料,暫時先不要理 Complex Type 的欄位
(紅色字體為 Complex Type 欄位,因為還沒完成所以顯示 JSON 格式不正確)
66. 注意事項
• 考量到時間問題,因此以最簡單的 HTML + JavaScript + jQuery 進行實作
• 因為 Code 有點多,在這邊將會就實作架構進行簡介,有興趣的話可以把整個
Repository 抓回去慢慢讀
• 本 Demo 程式僅供參考,實務上的開發會比這個複雜的多
• 所有 Code 都可以在這裡找到,議程一開始提供的資源列表裡面也有:
https://gitlab.sita.tech/medic/fhir-training-example
67. 開發環境
• 選一個喜歡的文字編輯器
用來寫程式碼,可以是文字編輯器、也可以是 IDE
推薦使用 Visual Studio Code
帶有正體中文界面,並且易於使用(記得安裝 Live Server 擴充元件)
• 選一個喜歡的瀏覽器
推薦使用 Mozilla Firefox,或是 Google Chrome
以上兩者都具有非常優良的偵錯工具,可以在開發階段協助 Debug
不建議使用 Internet Explorer,你會踩雷踩到懷疑人生。真的堅持要用的話,請出去(誤)
• 準備一台 FHIR Server
可以自己建,也可以使用 HAPI FHIR CLI 搭建臨時環境
網路上也有很多公開的測試伺服器
• 安裝 Git
用來把教學用的範例 Code 抓下來讀或修改
大家都在用的版本控制工具,可以針對你的 Code 進行版本控制
68. Features
• Patient 管理
可以查看所有 Patient 的摘要資料清單
可以新增單筆 Patient 資料
在 Patient 清單上,可以點進去查看該筆 Patient 的詳細資料
• Observation 管理
可以查看所有 Observation 的摘要資料清單
可以新增單筆 Observation 資料
可以在 Patient 的詳細資料頁面中,看到與該 Patient 關聯的 Observation
69. 檔案結構
• index.html:網站進入點
• css 資料夾:存放 Bootstrap CSS 檔案
• js 資料夾:存放各式 js 檔案
Bootstrap JS
Popper.js
jQuery
• js-fhir 資料夾:本次實作寫的 script
init.js:初始化設定、動作
config.js:設定檔
getXXX.js:取得單筆資料
listXXX.js:列出該 Resource 的資料清單
uploadXXX.js:顯示並上傳表單
72. 撈資料與上傳資料
• 以前在前端使用 XMLHttpRequest(XHR)進行實作
傳統的 XHR 寫起來很麻煩,Code 也醜不拉機的
基於 Event 的異步模型寫起來並沒有現代的 Promise、async/await 來的友好
• 現在通常改用 Fetch 來實作
基於標準的 Promise 進行設計
支援 async/await,搭配 ES6 的 Arrow Function 寫起來可以更簡潔美觀
語法簡潔、並且更加語意化,Code 可讀性高
符合關注分離,不將輸入、輸出等混雜在同一個 Object 裡
• 還是不懂?
Fetch 寫起來比較簡潔、比較好學!學他就對了!
74. DOM 操作
• 點擊按鈕後,需要動態呈現表單
• 抓到資料後,需要動態產生表格、資料內容
(動態產生 DOM 元素)
• 通常以原生 JS 操作 DOM、或透過 jQuery 進行操作
原生 JS 執行速度較快,缺點是 Code 比較長、實作相對麻煩
jQuery 語法較簡潔,學習門檻較低,功能強大
75. 範例程式碼中常用的 jQuery 操作
• 透過 element id 選取 DOM 元素
let content = $('#content');
• 清空該 DOM 元素下所有節點
content.empty();
• 將新的 DOM 元素附加在目前的 DOM 元素底下(從尾端插入)
content.append(html);
• 將新的 DOM 元素附加在目前的 DOM 元素底下(從前端插入)
content.prepend(html);
• 刪除選取的 DOM 元素
content.remove();
83. 既然都支援 REST 了,直接串就好
• 創建空資料夾,然後 npm init
$ npm init
• 安裝 dependencies
$ npm i -S axios
• 新增 payload.json,先把 payload 寫進去
• 新增 main.js,寫入主程式