VIII.總結

29 轉換後才是挑戰：SMART APP, CDS Hook, CQL等

我們現在有能力獲得一個符合FHIR IG標準的FHIR文件了，而且這個文件是可以實際應用上傳交換的，
然後呢

今天要介紹一點比較後段的東西了，當我們完成轉換持有可以交換的FHIR文件後，

我們執行上傳後會遇到的第一個關卡應該是目標端的資料判定，以健保署接受的TWPAS來說，

會有專業的醫師對上傳的內容進行審查，如果審查通過才會對申請的內容進行給付。

然而，既然資料上傳、蒐集等動作都可以透過自動化完成了，如果到最後還是醫師要一件一件看，

沒效率不說，可能還會累死人。

所以CQL(Clinical Quality Language)被引入來減少這些審查醫師的負擔，

本篇系列文不會談到CQL的使用方法跟建置，但簡單介紹一下

CQL的基本結構長這樣：

library DiabetesManagement version "1.0.0"
using FHIR version "4.0.1"
codesystem "SNOMED": "http://snomed.info/sct"
define
	"DiabeticPatients" : [
		Condition: "SNOMED:44054006"
	]

#from cio.com.tw/96242

CQL可以把FHIR文件裡使用的Code反向提出歸納，定義標籤，

審查醫師在看FHIR文檔之前，先透過CQL來歸納定義，就能第一時間得到資訊的摘要(Summary)

CQL的好處是他不只是單純為了FHIR設計的，同時相容於QDM, OMOP等模型，
並且由於他的撰寫方式非常接近自然語言，醫事人員撰寫CQL也可以很直覺。
另一個重點是CQL可以直接錨定FHIR內的ResourceType，針對該Resource來找尋對應的屬性項檢查

(岔個話題，事實上FUME也可以達成從FHIR中抽取資料的反向轉換，筆者也已實驗成功
但意義不大)

CQL的另一個好處是其相容於CDS HOOK，對第一線的臨床判斷來說更加速。

跟FHIRPath來比較的話，FHIRPath是設計來抽取FHIR內的屬性項的Query Language；
而CQL更著重在應用端判斷與檢核。

那剛剛上面談到的CDS HOOKS是什麼，CDS是用來提供臨床決策的一個機制，
當醫師下了診斷或是臨床上有突發事件的時候，CDS HOOKs會監測這些醫療資訊，回傳給CDS Service(大腦)去判斷
讓醫事人員能夠及時，準確且客觀的判斷臨床狀況。

而CDS本身相容於FHIR與CQL，可以說CDS本身是這幾個語言與標準的應用面，

想嘗試的讀者可以試試看下面的SandBox

https://sandbox.cds-hooks.org/

這是sandbox中的其中一個Requests

#CDS

{
  "hookInstance": "79dfb091-7a9f-458e-bd21-4fa232a50ea3",
  "hook": "patient-view",
  "fhirServer": "https://launch.smarthealthit.org/v/r2/fhir",
  "context": {
	"patientId": "smart-1288992",
	"userId": "Practitioner/COREPRACTITIONER1"
  },
  "prefetch": {
	"patient": {
	  "resourceType": "Patient",
	  "id": "smart-1288992",
	  "meta": {
		"versionId": "634",
		"lastUpdated": "2021-05-12T02:30:37.942-04:00",
		"tag": [
		  {
			"system": "https://smarthealthit.org/tags",
			"code": "smart-8-2017"
		  }
		]
	  },
	  "text": {
		"status": "generated",
		"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"> <p> Daniel Adams </p> </div>"
	  },
	  "identifier": [
		{
		  "use": "usual",
		  "type": {
			"coding": [
			  {
				"system": "http://hl7.org/fhir/v2/0203",
				"code": "MR",
				"display": "Medical record number"
			  }
			],
			"text": "Medical record number"
		  },
		  "system": "http://hospital.smarthealthit.org",
		  "value": "1288992"
		}
	  ],
	  "active": true,
	  "name": [
		{
		  "use": "official",
		  "family": [
			"Adams"
		  ],
		  "given": [
			"Daniel",
			"X."
		  ]
		}
	  ],
	  "telecom": [
		{
		  "system": "email",
		  "value": "daniel.adams@example.com"
		}
	  ],
	  "gender": "male",
	  "birthDate": "1929-08-16",
	  "address": [
		{
		  "use": "home",
		  "line": [
			"1 Hill AveApt 14"
		  ],
		  "city": "Tulsa",
		  "state": "OK",
		  "postalCode": "74117",
		  "country": "USA"
		}
	  ]
	}
  }
}

這裡就要談到FHIR要怎麼用了，

如同系列文的最開始所說的，FHIR其實已經在你的手機裡很久了，
APPLE、GOOGLE等企業已經開發可以接受FHIR的應用程式，負責記錄使用者的生理健康狀態，
底層也是透過FHIR標準在進行界接，

建立標準的目的並不是為了定義，而是實用，

有了統一的標準之後，大家才能把資料互相傳遞，就跟USB相同

因此這邊要講到SMART on FHIR，全名是Substitutable Medical Applications and Reusable Technologies on FHIR

簡單來說SMART on FHIR定義了FHIR APP的框架，如何安全穩定的存取FHIR API，並且相容於其他APP的框架，

應用程式開發者可以透過這個框架來很快速的投放FHIR API的應用與資料界接，

https://docs.smarthealthit.org/

並且相容於CDS HOOKS與FHIR，使用者可以就像是在APP Store那樣下載需要的應用程式app，配合上指定的FHIR Server界接，
就能夠在應用程式上呈現出需要的內容。

明天是總結與心得，

雖然FHIR還有很多面向沒有談到，但因為這個領域實在是太大了，加上投入的人並沒有很多，資源不多

包含Bulk Data, FHIR Shorthand, FHIR R5, R6等更新差異等，就有緣再來談吧。