FHIR 標準應用廣泛，不同應用情境，其應採用的細部規格不盡相同。並且國際上公告之 FHIR 標準內容專業且詳盡，一般 IT 人員較不易了解。本文件之建議欄位參考原 FHIR Patient resource標準，考量地區醫資系統現況，縮減不常用之欄位，提出一易於發展之參考規格。此規範並加入可能的應用情境說明及簡易使用範例，讓醫資標準更接地氣。以利於各醫療保健單位發展支援 FHIR 標準之系統。
1. id : patient resource 之唯一碼，類似資料表之主鍵。數值個數(1…1)，每個 patient resource 一定會有唯一之 id。id可由 FHIR server 產生，或 client 端上傳前預先指定:
l 可由FHIR Server 產生: 由 Server 端創建的 id，可完全去個人識別，利於在 PHR 及臨床研究資料庫應用中保護個人隱私。 Post 新增，id 自動產生。
l 也可採用現行醫療健康系統之病歷號(PatientID):如醫院 HIS 或政府現有健康醫療系統之 PatientID。Put 修改，id 可由client 端給定。
議題：
i. 跨院整合系統：id建議由入口網站產生，或是使用hash後的政府、保險單位制定的號碼(EX身分證字號、社保碼)。前端範例程式(網頁端)病人資料讀取的時候(read or search)可輸入身分證號，server端再做hash進行搜尋
ii. 在各醫院內使用，較方便的方式FHIR id即為病歷號
iii. 假設各醫院有獨立的FHIR Server。在跨院、跨機構的資訊互通情境下，相同病患在不同 FHIR server 資訊互通會有patient id不一致的問題，主要之病人FHIR id 參照(Master Patient Index) 需進一步考量。
2. identifier：可加強身分確認之識別碼。可放置民眾各式證照號碼，如身分證字號、機構內病歷號、護照號碼、保險碼、台胞證碼、個人 e-mail等多個資訊。並可依此查詢，以確認系統是否已建立此病人資料。數值個數(0…n) 可提供0到n個identifier資料，以利patient data識別，並利於以identifier資料查詢是否有此病人。
identifier可包含以下子欄位:system(識別碼給定機構 URL )、value(此病人之識別碼)、use(識別碼用途)、type(此識別碼的型態)、Period(使用期限)、以及 assigner (識別碼給定機構參考)，各欄位細部規格如下:
2.1. system：給定此identifier code的機構 URI。數值個數(1…1)，建議一定提供。URI 原則上由編碼給定單位產生。若編碼給定單位無此URI，可由各地之標準訂立組織來給定及維護。
2.2. value：編碼單位給此病人之代碼。數值個數(1…1)，建議一定提供。
議題：
i. system、value原 FHIR 標準數值個數(0…1)，改為 (1…1) 必須提供
ii. 不使用use、type、period、assigner等欄位
3. active：是否為使用中的病人。數值個數(0…1) ，可不提供，或給定 true 或 false。此欄位可標示長期未到該單位就醫的病人，或者依據醫療單位的商業規則定義之，主要用以篩選病人清單排除不常見/不活躍(inactive)的病人。而基於某些理由，「過逝的病人」也可能被設為inactive(意即active value=false)，但也可能病人過逝後一段時間，又被設定為 active(意即active value=true)。
議題：
i. 可否用來標示照護中心或特定醫院已出院之病人?
4. name：病人姓名。姓名全名放置於text，以利呈現。數值個數(0…n)，可存在多個姓名，如繁體、簡體、英文的姓名。英文姓名可參考護照姓名，分Last name與First name，分別放入family(姓)與given(名)標籤。中文姓名First name與Last name 放置規格如下:
4.1 text：放置姓名
4.2 family：可放姓氏。或空白，當上傳系統姓名合在一起。
4.3 given：可放名稱。或姓名全名，以利查詢。
議題：
i. 不使用use、prefix、suffix、period 等子欄位
ii. family 空白，given 放全名規格需進一步確立，並測試 FHIR API搜尋狀況。
iii. 中文特殊字元跨系統互通，在各系統支援之狀況，如可否輸入、查詢、呈現須測試。是否提供測試範例及周全之測試中文字元集。
iv. 回台灣就醫，大陸病歷中之姓名、地址、及文字呈現資訊之簡體中文是否會強制轉為繁體使用。
5. telecom：病人聯絡資訊。數值個數(0…1)，可不提供，或記錄電話、手機號碼、email、社交軟體帳號(如 Line、WeChat、Facebook) 等多組聯絡資訊。telecom 可包含以下子欄位:system(通訊系統)、value(系統中對應之帳號或號碼)、use(此帳號或號碼之用途)、rank(聯絡資訊之優先使用次序)、Period(使用期限)，各欄位細部規格如下:
5.1. system：通訊系統。數值個數(0-1)，可不提供，或數值可為phone | fax | email | pager | url | sms | other 等，phone, fax, pager, and email 可直接作為 system 的 value 屬性，url 及 other 則以對應之通訊系統連結如 FB之連結https://www.facebook.com/ 作為此 system 的值
5.2. value: 通訊系統中對應之帳號或號碼。數值個數(0-1)，可能沒有或不提供，也可提供電話號碼、email 帳號、健康平台病人線上聯絡帳號、FB 帳號等。電話、手機、簡訊格式建議存放地區(National) 可直接撥接之標準規格，如台灣地區之家裡電話： (03)8561234公司電話 (04) 22513333 ext 5438，手機號碼 0954787878 等，email、Line、WeChat 存放其帳號
5.2. use：此帳號或號碼之用途，數值個數(0…1)；可不包含此資訊(0)，或提供以下編碼數值(1) :home | work | temp | old | mobile
5.3. rank：此聯絡資訊之優先使用次序，產生次數(0…1)；可不包含此資訊(0)，或以正整數表示優先次序(1) :1 =為最優先
5.3. Period：使用期限，產生次數(0…1)；通常不確定聯絡資訊使用期限，因此不包含此資訊(0)。若清楚聯絡資訊使用期限，則提供開始及結束時間。
<telecom>
<system value="phone"/>
<value value="(03) 5555 6473"/>
<use value="work"/>
<rank value="1"/>
</telecom>
<telecom>
<system value="phone"/>
<value value="(03) 3410 5613"/>
<use value="mobile"/>
<rank value="2"/>
</telecom>
議題：
i. 電話號碼是否分段，如0954787878 改為0954 787 878 or 0954-787-878
ii. 是否有國際聯絡電話需求，其建議格視為何? 或參考https://www.itu.int/rec/T-REC-E.123-200102-I/e
l 簡訊自動通知有其需求，自動發送簡訊機制需考量。是否可設定群組通知，其群組 ID 為何? 是否需考慮社群群組及簡訊自動通知權限管控機制
6. gender：病人性別。數值個數(0…1)，可不提供，或給定以下數值:male | female | other | unknown
7. birthDate：病人生日。數值個數(0…1)，可不提供，或提供生日，格式:年(西元四碼)-月(兩碼含0)-日(兩碼含0)。某些應用需曉得病人年齡，又不希望公開病人確定生日，則生日中出生月份及日期可亂數產生，或出生日期可亂數產生。且亂數生成月份及日期，不同於真實生日月份及日期。
8. deceased[x]：病人是否已死亡。數值個數(0…1)，可不提供，或給定是否死亡(true or false)或死亡日期(date 格式)。使用介面須能提供紀錄與呈現是否死亡或死亡時間之功能。
議題：
i. 提供範例
9. address: 住址。數值個數(0…n)，可不提供，或提供1到多個地址，可記錄居住地址、通訊地址、戶籍地址等資訊。原 FHIR 規範可包含 use(用途)、type(類別)、text(住址字串)、line(巷弄)、city(市)、district(區)、state(州省)、postalCode(郵遞區號)、country(國家)、period(使用期間) 等欄位，建議使用:
9.1. use：地址用途，數值個數(0-1)，可不提供，或以home | work | temp | old | billing 等代碼表示
9.2. type：型態為寄件或居住地址。數值個數(0-1)，可不提供，或以postal | physical | both 等代碼表示。
9.3. text：字串型態的住址。數值個數(0-1)，可不提供，但通常會紀錄字串格式之住址。
9.4. postalCode：郵遞區號。可不提供(也可將 postalCode 直接加入 text 字串住址當中)，或記錄郵遞區號號碼。
議題：
i. line(巷弄)、city(市)、district(區)、state(州省)、country(國家)、period(使用期間)等欄位，是否不建議使用。住址直接在 text 紀錄即可。
ii. 應可記錄繁體或簡體中文，須測試其跨系統互通。例如病人住在大陸，台灣醫院系統可否紀錄及處理簡體住址。
iii. 是否提供英文代碼之中文對應， 如address.use code之中文對應，以利在使用介面上呈現。
iv. 當病人在 FHIR server上有多個地址資訊，是否可設定及選擇僅提供其中幾個住址。 Telcom 聯絡資訊也有類似議題。
10. maritalStatus：病人目前的婚姻狀態。數值個數(0-1)，可不提供，或以代碼表示。HL7 代碼表共提供11種婚姻狀態代碼(如：婚姻終止、離婚、合法分居、已婚等)，代碼詳細資訊於下列連結：https://www.hl7.org/fhir/valueset-marital-status.html
議題：是否簡化原 HL7 代碼表，提供已婚(M)、未婚(U)、婚姻狀態不明(unk) 三種代碼
11. multipleBirth[x]: 病人是否為多胞胎其中之一。數值個數(0…1)，可不提供，或給定是否為多胞胎(true or false)或多胞胎中第幾個(正整數)。此欄位暫不考慮使用。
議題：可與婦產科討論新生兒多胞胎之 patient name、identifier 表示方式。
12. photo：病人相片。數值個數(0…n)，可不提供，或給定URL 或 base 64 編碼以包含相片或相片連結。建議以 URL 連結方式取得相片。相片可上傳到各式網頁多媒體雲端伺服器或以 FHIR media 規格上傳 FHIR server。
議題：
i. 相片及醫學影像上傳後，建議以上傳者的私鑰加密保護，以防範駭客或不良之雲端系統管理者竊取及濫用此隱私資料。使用者端需資料擁有者(上傳者)受權，並提供解密密鑰，以解讀加密資訊。
13. contact：病人之聯絡人。數值個數(0…n)，可不提供，或提供受病人信任的親友(如：監護人、伴侶或友人)或長期服務人員聯絡資訊。原 FHIR 規範可包含 relationship(與病人之關係)、name(姓名)、telecom(聯絡方式)、address(地址)、gender(性別)、organization(聯絡或服務人員所屬組織)、 period(可聯絡的期間)。name、telecom、address、gender 可資料格式可參考上列 patient resource 規範。其他建議使用欄位規格:
13.1. relationship：聯絡人與病人之關係。數值個數(0…n)，可不提供，或紀錄關係代碼。可能針對某些健康醫療照護，如手術同意、醫療費用處裡、照護服務、保險申請及給付等，會有不同之聯絡對象。關係代碼需進一步增修確認。
relationship現行關係代碼參考:https://www.hl7.org/fhir/patient-definitions.html#Patient.contact.relationship
13.2. organization：病人之聯絡人所屬組織。數值個數(0…1)，可不提供，或參考所屬組織。大型組織建議建立分層組織架構，病人通常連結到基層之聯絡組織與人員。
議題：
i. relationship 的代碼及其中文說明須進一步確認
ii. 考慮上班及排班，醫療照護組織及人員的服務時間，無法以period 開始及結束時間表示。醫療照護人員的服務時間需另外的方式提供。
14. communication：病人可用的溝通語言種類。數值個數(0…n)，可不提供，或提供病人可溝通之語言。在多語系國家，提供此資訊，可利於安排病人就醫。當病人身處異地，或僅熟悉特殊母語，而不熟當地官方語言，亦可用此欄位特別註記說明。以利病患就醫時，確認或安排翻譯人員。communication 可包含以下子欄位: language(可溝通之語言代碼或文字說明)、preferred(註明此與語言是否為就醫慣用語言)。
14.1. language：可溝通之語言代碼或文字說明，數值個數(1…1)，必須提供，數值建議為 common language: https://www.hl7.org/fhir/valueset-languages.html 規範之代碼，或至少須在 all-language 編碼範圍內:
https://www.hl7.org/fhir/valueset-all-languages.html
http://tools.ietf.org/html/bcp47
台灣各式語言編碼:https://osmtw.hackpad.tw/ep/pad/static/ngewyizFYzN
14.2. preferred：註明此與語言是否為就醫慣用語言，數值個數(0…1)，可不提供，或提供true | false。
議題：
i. 可否找到其他地區語言編碼連結
ii. 是否提供多語系之標準化病人臨床案例