根據前篇安裝說明與步驟相信各位已經安裝好Fhirbase Server了，接下來就是測試與應用的重要階段，此篇要跟大家解說的是如何運用JASONB使用Fhirbase和FHIR資源。JSONB的工作原理不同：它以二進制形式存儲JSON文檔(這是JSONB名稱來自JSON二進製文件的來源)。以二進制形式，離散值的訪問速度比文本形式中的訪問速度快得多-無需一次又一次地解析JSON文檔。一個文檔僅被解析一次PostgreSQL將VARCHAR值強制轉換為JSONB。不利的一面是，當將原始JSON文檔保存在JSONB中時，無法保留其格式：二進制形式會丟棄空格，但是在大多數情況下，它並不重要。每個FHIR資源都有兩個資料表：一個資料表包含一個資源的當前版本，而歷史資料表包含所有以前的資源版本。如果各位想查詢資料表，可進入Terminal 視窗，利用指令進入DBA模式查詢。也可以透過Pgadmin的Web GUI介面來執行CRUD功能。
指令查詢資料表patient 紀錄
 |
| Fhirbase Table |
 |
| Patient search front 100 |
在執行Fhirbase資料運用前，先來詳細了解一下Jasonb的語法和指令，先了解一下Jason和Jasonb相同的運算符號。
※注意
這些運算符對於
我們以查詢患者'Aaron697'為例，下列語法會產生錯誤:
(ERROR: invalid input syntax for type JSON)
因PostgreSQL有嚴格的類型系統(Type System)，因此它不能比較“ Aaron697”（類型VARCHAR）和JSONB值，即使它只是JSONB中的一個字串(String)。為了使此查詢正常工作，我們需要應用雙箭頭運算符（->>），返回VARCHAR而不是JSONB：
正確的語法指令如后:
json和jsonb類型都有並行變體。field/element/path提取運算符返回與其左側輸入相同的類型（json或jsonb），但指定為returning的類型除外text，它們將值強制為文本。如果JSON輸入的結構不符合請求，則field/element/path提取運算符將返回NULL而不是失敗。例如，如果不存在這樣的元素。接受整數JSON數組下標的字段/元素/路徑提取運算符都支持從數組末尾開始的負下標。
我們以查詢患者'Aaron697'為例，下列語法會產生錯誤:
(ERROR: invalid input syntax for type JSON)
- SELECT resource->'name'->0->'given'->0
- FROM patient
- WHERE resource->'name'->0->'given'->0 = 'Aaron697'
- LIMIT 5;
->>正確的語法指令如后:
- SELECT resource->'name'->0->'given'->>0
- FROM patient
- WHERE resource->'name'->0->'given'->>0 = 'Aaron697'
- LIMIT 5;
這句語法的意思是取得(Get)resource欄位下第0組的name下的第0組given 'Aaron697'名稱患者最少列出5筆紀錄，知道概念後，我們利用Pgadmin4 Web-GUI介面來測試一下吧!
 |
| 查詢指令 |
 |
產出的結果 |
謂詞運算符(Predicate Operators)
謂詞運算符可以在任何深度進行檢查JSON值中是否存在特定的值或鍵，並傳回True。和箭頭符號(
->, #>, ->>, #>>)最大不同的是箭頭符號只使用一個Gin_Index索引，而稱謂符號是如果左側值中包含右側JSONB值，則返回TRUE：@>，如下列範例所示:
左側值中包含右側的HL7及FHIR值則回傳True。
SELECT '[“ FHIR”，“ HL7”，“ FHIRBASE”]' :: jsonb @ > '[“ HL7”，“ FHIR”]' :: jsonb ;
左側值中包含右側姓名Aaron則回傳True。SELECT '{“ name”：[{“ given”：“ Aharon”}，{“ given”：“ Aaron”}]}' ：:: jsonb @ > '{“ name”：[{“ given”：“ Aaron” }]}' :: jsonb ;
在另外一例，我們可以使用查找所有表明患者符合檢驗值LOINC"72166-2"和長期吸菸SNOMED值"449868002"是吸煙者的觀察值：
SELECT * FROM observation
WHERE (resource @> '{"code": {"coding": [{"code": "72166-2"}]}}'::jsonb) -- LOINC: Smoking status
AND (resource @> '{"value": {"CodeableConcept": { "coding": [{"code": "449868002"}]}}}'); -- SNOMED: Current every day smoker
此查詢大約需要100毫秒才能執行。它的速度非常快，但壞消息是，當表中有更多記錄時，查詢時間將線性增加。發生這種情況的原因是PostgreSQL對該查詢執行了順序掃描，並實際上檢查了每個觀察值是否包含指定條件。\timing
為此我們可在列上創建一個GIN索引...observation.resource來優化查詢。
CREATE INDEX observation_idx ON observation USING GIN (resource);
