## 大林慈濟基於 FHIR PHR 討論之內容
## 4月1日討論內容
1. 放射治療期間應該要有一個SOP定期健康管理，包含健康監控，異常記錄以及提醒，並定時安排病人回診以及放射治療，SOP如下圖所示:
2. 以下為放腫科血液測量之警示值，要依據此警示值給予病人回饋並應告知如何改善，或者於系統記錄某個時間檢查時異常結果回報，如圖所示為警示值:
3. 病人自主輸入資訊考量資訊是否正確，需要做準確的防呆來判斷可能輸入錯誤的數值。
4. 圖片的上傳JSON物件來源分為兩部分，一個為Observation，一個為Condition，需要能夠處理圖片轉成JSON data 的格式。
5. 醫護端的Observation為醫戶端所用，民眾端得知資訊為異常的資訊即可。
6. 身高跟體重需要算出%數值來辨別是否異常。
7. 以大眾化來起頭輸入觀察值，血壓、心律...等

### 基於會議記錄產生的回應
1. 有個SOP管理系統，這一點我的想法是建立一個與病人的聊天室，基於FHIR Communication規格，若有異常的時候，醫生可以藉由傳訊息的方式來通知病人或是需要改時間治療也可以透過此聊天室來通知
2. 基於警示值的通知，我們利用APP的提醒訊息達成此之作用，若在醫院量測時有出現異常值，會由醫生端填寫完測量資料給那位病人，PHR系統APP端會直接在FHIR Server端抓取的值做出判斷，若真的異常會發送訊息通知給民眾告知需要改善以及如何做出相對應的治療。
3. 基於輸入數值正確之問題，我們可以在網頁做輸入時，設定一個基準值，如果非正常的基準值，那就會出現彈跳視窗告訴使用者應該要輸入正確的數值，或者可以搭配物聯網，直接將量測的數值上傳至FHIR Server中也可以。
4. 算出%數值表示是否異常，我們可以用程式碼來做程式計算之目的，可以規劃病人每2、3天做出生理監測的測量，如果超過我們預定設定的%數值，這樣就表示異常，也會用訊息提醒民眾。
5. 以大眾化輸入觀察值的部分，我們可以查詢網路上通常民眾可以自己測量的範圍，在做出對應的表單給予民眾填寫。
#### 目前規劃(後續規劃可以再討論)
1. 能夠根據放腫科的需求產生符合規格的FHIR Service Request JSON Data
2. 設計出屬於民眾端的ServiceRequest系統
3. 基於web Restful API 建立一個安全且無虞的資訊安全系統
4. 能夠根據不同的病患產生不同種類的Condition表單

## FHIR PHR 概述
此系統用於病人端，其中包含了patient、observation、condition...等FHIR 規格，在這裡主要針對病人端可能使用或操作來做為此PHR系統，而此系統可以是APP或網頁的方式呈現，需要設計出符合FHIR規格以及民眾端需要使用的系統是一個挑戰，也包含了一些學問，此系統可以與EMR端進行資料互通，中間有一個FHIR Server來建構溝通的橋樑，利用http協定上傳或調閱，這樣便能完成此系統，以下為簡單示意圖:

## PHR系統開發方向
目前極力設計出Observation的部分，主要是針對民眾端平時可以用儀器測量並於網頁填寫測量資料為主，以及病人的基本資料填寫，能夠先完成以上兩步驟時可以另約時間討論FHIR condition的規格以及其網頁設計，一步一步的建置更完整的PHR系統。至於ServiceRequest的部分因為民眾端可能沒有許多醫學知識，所以民眾端開發方向只提供調閱，主要是確認每一次治療時間以及下一次治療時間，並搭配APP的提醒訊息以及網頁顯示。

## 整體架構
#### 說明
首先民眾端要使用此系統時應該要有一個明確的帳戶，所以會在protal端建立病人的帳戶，完成註冊時可以登入，登入之後會有一些基本的功能(填寫生理監測、填寫症狀表單或查看電子病歷...等)，然後我們會基於Https協定將資料上傳至FHIR Server中，在另一端(EMR)可以從FHIR Server進行上傳或調閱的動作，可視情況來設計專屬於EMR端的系統。

## 實作步驟
1. 由民眾端上傳病人的基本資料至FHIR Server中
2. 填寫生理監測的表單並上傳至FHIR Server
3. 從FHIR Server中進行調閱FHIR 資料
4. 利用canva設計網頁產生折線圖或方便查閱的調閱網頁，建議使用折線圖，可以視醫護端的需求增加異常值的框線標記或是警示病人...等

## FHIR Observation之應用情境
#### PHR端
1. 能夠上傳一些基本的生理監測資料(ex:血壓、心率...等)
2. 可以搭配物聯網的裝置自動上傳測量資料，達到數值精確
3. 此系統需要一些防呆，假設輸入的值為不正常的數值，那應該要防呆
4. 建議ID的部分可以搭配健保IC卡做連動，這樣不需要在自己手動填入ID，可以以搭配國家的健保快意通達成資訊整合

#### EMR端
1. 能夠針對某個病人調閱平時所有的生理監測資料，並用表格或是折線圖的方式呈現
2. 利用框線把異常的數值匡列起來，方便醫生給予病人下一次回診時需要改善之建議
3. 會設立一些該檢測的標準值，標準值得參考來自大林慈濟提供的數值
4. 可以搭配APP方面，若有異常值的出現可以用訊息提醒民眾。

## 目前設計出的簡易系統展示
#### Patient
#### Observation
#### Condition

## 衍伸問題
1. 資訊安全問題: 因為沒有使用加密系統時做此PHR系統，故會出現有惡意的程式來竊取民眾的資料，所以可以與大林慈濟的資訊人員來合作，是否有一套完整的資訊息統來完成此PHR系統。
2. 使用對稱式加解密: 如果從PHR傳送過來的資料可以視做一個封包，那麼可以使用大林慈濟那邊的公鑰做出加密把此封包變成祕文，這樣在FHIR Server上所出現的資料就是祕文，之後醫護端可以用大林慈濟的私鑰把此密文解開，這樣就是由民眾端所傳送來的資料就可以解析了。
3. 驗證問題: 在一個未知的封包怎麼知道這封包真的是由那位病人所傳送的呢，我們可以民眾端傳送資料之前，先向大林慈濟的資訊人員申請一個憑證，我們利用這個憑證來做資料填寫的部分，之後利用這個憑證加密文件，憑證也可以是大林慈濟端的公鑰，申請才能給，那醫護端可以用自己的私鑰解開，如果能解開成為一個完整的JSON資料，那代表這個資料是由民眾端所傳送的，反之則不是，藉由此方法去踢除非此病人的資料，也可以預防惡意攻擊導致系統癱瘓。

## 此次行程需要記錄之內容
1. 與醫學專家討論各種其他病患的需求，切需要有一個人負責記錄並使用hackmd。
2. 基於PHR系統與其他醫學專家合作，需要能夠及時的提出自己的想法並記錄於Hackmd上，這需要一個人。
3. 討論民眾端的Observation之網頁呈現方式需與專家討論一個需求，一個人負責記錄在hackmd上。
4. FHIR Condition之醫學專家意見收集，需要有一個人負責記錄，以便此系統的後續開發。

## 5/24-5/26行程
#### 5/24
1. 5/24 搭14:40的火車往台北(16:52)
2. 吃晚餐順便進行專家會議。
3. 夜宿台北，逛台北sogo
#### 5/25
1. 5/25 10:20火車往台中(12:24)
2. 13:30約某間咖啡館討論合作或專案，直到15:30
3. 夜宿台中，逛台中市區的百貨公司。
#### 5/26
1. 15:57分搭普悠瑪往花蓮(19:52)
2. 早上可以在台中稍微逛一下，去outlet

## 暑期規劃
1. 7月找一個時間去大林慈濟與謝組長以及其他科室的人討論癌病PHR的系統開發。
2. 7月FHIR Condition 症狀表單的開發，需要有2-3位的人參與大林慈濟的視訊會議以了解需求，給予工讀金，每周5天，一天4小時為工資給發。
3. 8月FHIR ServiceRequest民眾端放射治療處方調閱並查看，需要有2-3位的人參與大林慈濟的視訊會議以了解需求，給予工讀金，每周5天，一天4小時為工資給發。
4. 在7、8月能隨時與我確認需要做甚麼內容，以及線上討論參與，開發出最基礎的癌病PHR系統
5. 能夠有一個人去研究Dicom RT之內容，我們會基於此內容去做開發醫護端PHR系統，此為Dicom RT連結: https://dicom.innolitics.com/ciods/rt-structure-set/rt-series
6. 9月討論資訊安全之議題，需要一個工作團隊與大林慈濟的資訊人員安排視訊討論看能否基於Web Restful API完成資安問題。