中正大學／FHIR 快速掃描 R4 版本
•Transferir como PPTX, PDF•
1 gostou•1,631 visualizações
FHIR R4 開發簡介、文件導讀、API 介接、PHR 基本應用、後端應用範例 本著作係採用創用 CC 姓名標示-相同方式分享 4.0 國際 授權條款授權， （授權網址：https://creativecommons.org/licenses/by-sa/4.0/deed.zh_TW） 歡迎多加參考與利用。
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 中正大學／FHIR 快速掃描 R4 版本
Semelhante a 中正大學／FHIR 快速掃描 R4 版本 (20)
中正大學／FHIR 快速掃描 R4 版本
- 1. FHIR 開發簡介與應用 Lorex L. Yang（楊宇凡）<ceo@sita.tech> May 14, 2020 / 中正大學
- 2. 這節議程要來跟大家聊聊 FHIR 所規範的 資料格式／型態 如何使用工具 與 FHIR SERVER 互動 如何透過 REST API 存取 FHIR SERVER 寫出一個簡單的病人／檢 驗報告管理小工具 （如果時間夠的話XD）
- 3. 由於上次議程已經對 FHIR 做過介紹 這節議程將會以資訊人員的角度切入 探討 FHIR 標準的相關技術細節
- 4. 歡迎發問、回答 ヽ( ° ▽°)ノ
- 7. Fast 快速 Healthcare 健康照護 Interoperability 互通 Resources 資源
- 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 方便檢視
- 13. Overview Resource 類別（必填） 流水號 人類可讀區域 Resource 內容 Meta 資訊 擴展資料 （本地化／客製化資料）
- 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 會針對這邊的資料進行檢查，如果有問題就會噴錯
- 16. FHIR 文件導讀
- 17. 隨便抓一個 Resource 看一下 Resource 介紹／ 關聯／ 使用範圍 內容、資料結構與細部說明 （重要！） 欄位值的 Reference 與限制 可被搜尋的參數清單
- 18. Resource Content 欄位名稱 對應數量 資料型態（Data Type） 欄位定義與 規範／限制 旗標
- 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）
- 20. Data Type
- 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 為本地化／客製化資料
- 23. 另外還有一個 Reference 就是剛剛看到的 Special Purpose Data Type
- 24. Reference 是對應到其他 Resource 的參照 可以透過 ID 與其他 Resource 對應在一起
- 26. 網站有提供範例，可以直接開來看
- 27. Search Parameters • 這邊列出的是可以直接被搜尋的欄位值 • 通常這裡有的欄位會優先使用
- 28. 每個 Resource 都有一個 Structure 有學過 DB 的話，直接看 UML 比較快
- 30. FHIR 模組概觀
- 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
- 35. Clinical Scenario Patient List Condition Encounter MedicationRequest Medication Procedure Encounter Observation Specimen DiagnosticReport ImagingStudy EMR → EHR (CDA) (FHIR)
- 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 醫療照護服務
- 38. Terminology／Documents Resources • Terminology CodeSystem 編碼系統（e.g. ICD10、LOINC、ATC、健保代碼…等） ValueSet 列舉值（Enumeration） ConceptMap 不同 CodeSystem 之間的對照 • Documents DocumentReference 文件參考 DocumentManifest 文件索引
- 39. Scheduling／Security Resources • Scheduling Appointment 預約 AppointmentResponse 預約確認 Schedule 班表／行程表 Slot 班表中的一格時段 • Security & Privacy AuditEvent 稽核紀錄 Consent 同意書 Provenance 人對事件的簽章／授權 Bundle 一串資料
- 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 計費項目
- 42. 如何存取 FHIR 資料
- 43. REST API • 當代主流的資訊交換技術，廣泛應用於軟體開發 • 充分使用 HTTP 通訊協議 • 擁有簡潔直觀的 URI • 透過 REST API 可以對 FHIR 資料庫進行各項操作（增／刪／改／查） • 接受 FHIR 所支援的 Data Format（JSON and XML）
- 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
- 47. REST API 使用方法 <Method> <baseURL>/<resource>/[id]{?options} HTTP 方法 網址 目標 resource id 選項
- 48. 看不懂嗎？套個範例 GET https://hapi.fhir.tw/fhir/Observation/41123?_pretty=true HTTP Method BaseURL Resource OptionsId
- 49. 使用工具與 FHIR Server 互動
- 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
- 53. 取得所有 Patient 資料 GET https://hapi.fhir.tw/fhir/Patient
- 54. 取得單一 Patient 資料 GET https://hapi.fhir.tw/fhir/Patient/1
- 55. 新增一筆 Patient 資料 • POST https://hapi.fhir.tw/fhir/Patient • Payload 如右
- 56. 編輯剛剛的 Patient 資料 • PATCH https://hapi.fhir.tw/fhir/Patient/265/gender/male • Payload 如右
- 57. 刪除剛剛新增的 Patient 資料 • DELETE https://hapi.fhir.tw/fhir/Patient/265
- 58. 組織臨床資料，並寫入 FHIR Server 內 以 Patient 為例
- 59. 範例病人資料 • 姓名：王大明 • 性別：男 • 連絡電話：0912-345-678 • 聯絡地址：高雄市小港區大馬路999號 • 資料有效狀態：YES • 生日：84/01/01
- 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 格式不正確）
- 62. 組織資料步驟 • 確認 Complex Type 內的格式內容，然後依次展開後填入
- 63. 寫入資料 • POST https://hapi.fhir.tw/fhir/Patient • Body 資料如右 • 執行結果如下
- 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：顯示並上傳表單
- 71. 用 Fetch 來抓／丟資料 然後交給 jQuery 做 DOM 操作 並且把資料 Render 出來
- 72. 撈資料與上傳資料 • 以前在前端使用 XMLHttpRequest（XHR）進行實作 傳統的 XHR 寫起來很麻煩，Code 也醜不拉機的 基於 Event 的異步模型寫起來並沒有現代的 Promise、async/await 來的友好 • 現在通常改用 Fetch 來實作 基於標準的 Promise 進行設計 支援 async/await，搭配 ES6 的 Arrow Function 寫起來可以更簡潔美觀 語法簡潔、並且更加語意化，Code 可讀性高 符合關注分離，不將輸入、輸出等混雜在同一個 Object 裡 • 還是不懂？ Fetch 寫起來比較簡潔、比較好學！學他就對了！
- 73. XHR vs Fetch XHR 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();
- 77. 列出資料清單 listPatient.js / listObservation.js 清空畫面並顯示 Loading 資訊 使用 Fetch 撈資料 建立表格標題 遍歷陣列 並動態新增資料至表格中 判斷是否有下一頁 然後顯示下一頁按紐
- 79. 上傳資料－送出表單資料 uploadPatient.js / uploadObservation.js 清除警告訊息 檢查資料 有漏填或填錯的就顯示警告訊息 組織 FHIR 規範的資料結構 使用 Fetch 送資料給 FHIR Server 並顯示回傳結果
- 80. 顯示資料細項 getPatient.js / getObservation.js 清空畫面並顯示 Loading 資訊 使用 Fetch 撈資料 顯示資料內容
- 81. 畫面展示
- 82. 補充 2：如果你是寫後端的… 示範以 node.js 撰寫程式進行介接
- 83. 既然都支援 REST 了，直接串就好 • 創建空資料夾，然後 npm init $ npm init • 安裝 dependencies $ npm i -S axios • 新增 payload.json，先把 payload 寫進去 • 新增 main.js，寫入主程式
- 86. Q&A
- 87. Thank you.