II.FHIR Resource
上一篇文章主要在談Resource的基本定義與屬性，今天會將範圍再稍微擴大一些，
來介紹一些筆者在IG中常見到的Resource類型
這篇系列我不太會去談到底層的Resource，也不會講太深，
因為每個Resource的使用會受到IG Profile很大的影響，因此在此主要是概述
我會把Resource在應用面分成幾個範疇(個人分類)：
1.基礎Resource:
基礎Resource指的是構成一些醫療事件的最基本要素，
如Patient 病患資料, Encounter 門診資料、 Specimen 檢體資料、 ImageStudy 影像資料等
這些基礎Resource能夠描述底層的基本訊息，這個病患是誰，他在哪裡看診，
他的檢體編號是多少，他的影像資料要去哪裡找...等等
2.應用Resource
應用Resource指的是在基礎Resource之上，由多個基礎Resource來描述的事件，
如Observation 診斷訊息、 DocumentReference(R5 deprecated) 文件資料、 Procedure 手術資訊，
BP 血壓資訊等，
這些Resource的特色是他們必然會有需要引用基礎Resource的欄位，
最顯而易見的就是Patient，因為這些醫療事件必然要有被執行者，
並且，這些應用Resource的意義基本上可以看做是該名患者被執行的醫療事件或保險狀態等。
3.包裝Resource
包裝Resource顧名思義，是拿來打包這些應用Resource的Resource，
以應用角度來看，這些包裝Resource表達的是多個醫療事件整合起來的文件、表單等
以保險給付來做例子，Claim Resource會包含病患的手術報告(Procedure)、使用的醫材(Medication)、
初步的影像、檢驗檢查(DiagnosticReport)等，
而這些包含的Resource都是應用Resource，
每一個應用Resource又都會有共同或獨立的基礎Resource，以此成為一個完整的醫療文件。
這樣的概念很像在疊金字塔，有了底層的基礎Resource做基底，
才有辦法去定義這些應用Resource的利用範圍；
有了這些應用Resource，才能集成成一個表單或文件提供給需求方做解讀或申請。
接下來來談一下FHIR R4的Resource表吧
https://hl7.org/fhir/R4/resourcelist.html
由上至下由底層到頂層，我這裡會列舉出比較容易碰觸到的Resource，
因為有太多Resource的完成度還在0至1，平常在實作面上也很少遇到，有興趣的讀者請自行翻閱。
1. Foundation -> 這層的大多數都是系統層面的東西，去定義FHIR Server的架構，
或是提供使用者操作FHIR Server的服務
Comformance
CapabilityStatement(N) -> 能力聲明，定義該FHIR Server能包含到的功能或服務
StructureDefinition(N) -> 結構定義，描述資料結構、內容或資源的填入方式
ImplementationGuide(1) -> 實作指引，規範解決特定問題的FHIR Resource使用方式、填答方法與限制
SearchParameter(3) -> 搜尋參數，定義特定Resource的搜尋參數以提供RESTful API使用
OperationDefinition(N) -> 操作定義，定義如何使用RESTful API介面與FHIR Server互動
StructureMap(2) -> 結構映射，定義兩組結構內的轉換關係，如CDA R2 -> FHIR
Terminology
CodeSystem(N) -> 代碼系統，定義特定的醫療術語代碼(Code)的使用，
這些術語代碼組合成為了FHIR資源的臨床可用性
ValueSet(N) -> 代碼集合，一群CodeSystem的集合，指涉一個代碼欄位中可使用
的CodeSystem與Code範圍
ConceptMap(3) -> 概念映射，一組概念間的映射關係，
可能是代碼或醫療概念的別名與互相對應
Security
Provenance(3) -> 憑證驗證，定義一個FHIR Resource該如何被驗證其資安層級的真實性，
紀錄所有該Resource的更動
Documents
Composition(2) -> 資源集合，包含多個Resource的整合Resource，
其必為Document Bundle的第一個欄目，
且Bundle中所有資源都必紀錄於Composition
DocumentReference(3) -> 文件參照，醫療事件或報告的底層文檔Resource，
儲存了文件的路徑、名稱或各式關於該文件的描述。
Other
OperationOutcome(N)-> 操作結果，FHIR Server回應使用者使用RESTful API的回覆Resource，
為錯誤、警告與資訊的集合。
Subscription(3) -> 訂閱功能，定義兩個FHIR Server間Resource的更新推送，
若有狀態改變會告知對方以channel傳送資訊回去。
Bundle(N) -> 表單，所有提交Resource的最上層，
不同的機構單位交換資訊或是FHIR Server的搜索操作等，都是使用Bundle
2. Base -> 這層的幾乎都是基礎Resource，用來構成醫療文件的基礎，
可能是醫療行為的執行與被執行者、或是設施、樣本等客體。
Individuals
Patient(N) -> 病患，關於病患的基本資料、身分、名稱等
Practitioner(3) -> 醫事人員，關於醫事人員的基本資料、身分、執照號碼、名稱等
PractitionerRole(2) -> 醫事人員角色，描述特定人員在時空間的角色，可能是可以執行業務的範圍
Entities
Organization(3) -> 醫事機構，描述醫事機構的代號、性質與名稱等
Location(3) -> 物件位置，描述特定物件的所在地
Substance(2) -> 物質，描述一種物質，可以是一種配方、放射劑量、或是指定物質的包裝樣態
Device(2) -> 裝置，描述一種提供服務的裝置，可能是醫療器材或是設備。
Management
Encounter(2) -> 醫療服務，描述執行者與被執行者之間的互動，可以是門診別，住院診療或執行醫療事件
3. Clinical -> 臨床Resource類別，為FHIR描述醫療資訊與臨床的核心內容
Summary
AllergyIntolerance(3) -> 過敏資訊，描述過敏的狀態或是耐受性
Condition(3) -> 症狀資訊，描述一種症狀、病症
Procedure(3) -> 手術資訊，描述執行的手術
ClinicalImpression(0) -> 主訴，描述患者尋求醫療服務的主要原因
Diagnostics
Observation(N) -> 診斷觀察，描述執行者對被執行者的臨床觀察或數據觀察
Media(1) -> 媒體，主要是非DICOM格式的影像，描述可以作為診斷依據或觀察的非文本資源
DiagnosticReport(3) -> 檢查報告，對於病患(被執行者)的診斷報告，可以是病理、生理等報告數據
ImagingStudy(3) -> DICOM影像，可以作為診斷使用的醫學影像
QuestionnaireResponse(3)-> 問卷回答，指病患透過問卷填答的資料集合
Medications
MedicationRequest(3) -> 處方，包含使用的藥物類型、使用方法、頻次及數量等
Medication(3) -> 藥物，包含藥物的檢驗認證碼、藥物的類型、包裝數量等
Immunization(3) -> 疫苗，但不包含具有免疫學證據的免疫製劑
Care Provision
CarePlan(2) -> 照護計畫，對於病患所規劃的照護、醫療計畫等
4. Financial -> 保險、財務上的Resource，主要負責應對保險申請或支付等方法
Support
Coverage(2) -> 保險內容，在台灣來說通常是全民健保，若有額外使用的保險也可使用
Billing
Claim(2) -> 保險申請單，包裝Resource，用來整合提交出險所需的FHIR Resource
5. Specialized -> 這裡的Resource通常是提供特殊的FHIR Resource服務或是一種特別用途的Resource
Definition Artifacts
Questionnaire(3) -> 問卷，可以透過問卷工具產出QuestionnaireResponse，後面會談到
目前筆者有實際使用或了解的Resource大概這麼多，應該足夠涵蓋現在大多在使用的特定IG的Resource使用，
結合昨天談到的Resource欄位定義與閱讀，大致可以理解這些Resource應該要怎麼使用。
對於使用目的而言，特定的Resource進行組合即可以表達特定的需求，
至於屬於最上層集合的Bundle，會再花一個欄位在後面說明。
明天的主題會稍微不太一樣，來談談Questionnaire這個Resource提供的功能
iThome鐵人賽
看影片追技術