關於接受照護或其他健康相關服務的個人或動物的人口統計學和其他行政資訊。

resource的邏輯ID，在resource的URL中使用。一旦指定，這個值永遠不會改變。

一個resource使用新增操作（create operation）提交給伺服器時，此resource沒有id，它的id在resource被創建後由伺器分配/指定。

關於resource的metadata。這是由基礎建設維護的內容。內容的更改可能並不總是與resource的版本更改相關聯。

構建resource時遵循的一系列規則的參照，在處理內容時必須理解這些規則。通常這是對IG所定義之特殊規則及其他profiles的參照。

宣告這套規則限制了內容只能被有限的交易夥伴所理解。這從本質上限制了資料的長期有用性。然而，現有的健康生態體系高度分裂，還沒有準備好以普遍可計算的方式定義、收集和交換資料。只要有可能，實作者和/或規範編寫者應該避免使用這個資料項目。通常在使用時，此URL是對IG的參照，此IG將這些特殊規則與其他profiles、value sets等一起定義為其敘述的一部分。

編寫此resource的語言

提供語言是為了支援索引和可存取性（通常，文字表述轉語音等服務使用此語言標籤）。html lanuage tag適用於此敘述。resource上的語言標籤可用於指定從resource中的資料所產成的其他表述之語言。不是所有的內容都必須使用此語言。不應該假定Resource.language自動適用於敘述。如果指定語言，它也應該被指定在html中的div資料項目（關於xml:lang和html lang屬性之間的關係，見HTML5中的規則）。

人類語言；鼓勵使用CommonLanguages代碼表中的代碼，但不強制一定要使用此代碼表，你也可使用其他代碼表的代碼或單純以文字表示。

人可讀的敘述，包含resource的摘要，可用於向人表述resource的內容。敘述不需要對所有的結構化資料進行編碼，但需要包含足夠的細節使人在閱讀敘述時理解「臨床安全性」。resource定義有哪些內容應該在敘述中表示，以確保臨床安全。

內嵌（contained）的resource沒有敘述，非內嵌（contained）的resource則 建議應該（SHOULD） 有敘述。有時resource可能只有文字表述，很少或沒有額外的結構化資料（只要滿足所有minOccurs=1的資料項目）。這可能出現在舊系統的資料，當資訊以 「文字表述區塊（text blob） 」的形式被取得，或者文字表述是原始輸入或說明，而編碼資訊稍後再添加。

這些resource內嵌（contains）的resource不會另外存於任何FHIR伺服器，意即它們無法在任何FHIR伺服器中被找到，也無法有自己獨立的資料異動／交易（transaction）範圍。

當內容可以從任何FHIR伺服器找到時，不應該以內嵌（contained）resource的方式呈現，因為一旦失去識別，再次恢復它是非常困難的（並且取決於情境）。內嵌（contained）的resource可在它們的meta資料項目中表述profiles和tag，但不應該有安全標號（security labels）。

可用於表示不屬於此resource基本定義的額外資訊。為了擴充的使用安全和可管理，對擴充的定義和使用有一套嚴格的管理。儘管任何實作者都可以定義一個擴充，但作為擴充定義的一部分，必須（SHALL） 滿足一系列要求。

任何應用程式、專案或標準使用擴充時，都不應該帶有任何負面的聯想。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

可以用來表示不屬於此resource的基本定義的額外資訊，並修改包含它所內嵌（contained）的資料項目的理解和/或對包含資料項目之後續使用的理解。通常修飾用的資料項目提供否定或限定的資訊。為了使擴充的使用安全和可管理，對擴充的定義和使用有一套嚴格的管理。雖然任何實作者都可以定義一個擴充，但在定義擴充時 必須（SHALL） 滿足一組要求。處理resource的應用程式需要檢查修飾用的擴充資料項目。
修飾用的擴充資料項目 必須沒有（SHALL NOT） 改變resource或DomainResource上任何資料項目的含義（包括不能改變modifierExtension本身的含義）。

任何應用程式、專案或標準使用擴充時，都不應該帶有任何負面的聯想。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

修飾用的資料項目擴充允許將不能安全地忽略的擴充，與絕大多數可以安全地忽略的擴充明確區分開來。這樣做有助於促進可互操作性，因為無需禁止實作者使用擴充，想要瞭解更多資訊，請參見[修飾用的資料項目擴充之定義]（http://hl7.org/fhir/R4/extensibility.html#modifierExtension）。

病人的唯一識別碼（identifier）

病人幾乎總是被指定一個特定的數值型的唯一識別碼（identifier）

適用於身分證字號

病人幾乎總是被指定一個特定的數值型的唯一識別碼（identifier）

這個唯一識別碼（identifier）的用途

應用程式可以假定一個識別碼是永久的，除非它明確說它是暫時的。

如果知道，請說明此識別碼的目的；應填入所綁定值集中的其中一個代碼。

允許從一組識別碼中為特定的使用情境選擇適當的識別碼

識別碼的代碼型別，用於決定特定目適用的識別碼。

這個資料項目只涉及識別碼的一般類別。它 必須沒有（SHALL NOT） 被用於與Identifier.system 1..1對應的代碼。一些識別碼可能由於常見的用法而屬於多個類別。在系統是已知的情況下，型別是不必要的，因為型別總是系統定義的一部分。然而，系統經常需要處理系統不為人知的識別碼。型別和系統之間不是1:1的關係，因為許多不同的系統有相同的型別。

識別碼的型別，用於決定特定目的所適用的識別碼；應填入所綁定值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

允許使用者在不知道識別碼系統的情況下利用識別碼

由專門術語系統（terminology system）所定義之代碼的參照

代碼可以在列舉清單（enumerations）或代碼清單（code lists）中非常隨意地定義，直至有非常正式的定義，例如：SNOMED CT—更多資訊見HL7 v3核心原則（Core Principles）。編碼的排序是未定義的因而 必須沒有（SHALL NOT） 被用來推斷意義。一般來說，最多只有一個編碼值（coding values）會被標記為UserSelected = true。

允許代碼系統中的替代編碼，以及翻譯到其他編碼系統。

定義代碼中符號意義的代碼系統識別

URI可以是一個OID（urn:oid:...）或一個UUID（urn:uuid:...）；OID和UUID 必須（SHALL） 參照HL7 OID註冊中心；否則，URI應該來自HL7的FHIR定義的特殊URI列表，或者它應該參照一些明確建立的系统定義。

需要明確說明符號定義的來源

選擇此代碼時使用的代碼系統版本；請注意，一個維護良好的代碼系統不需要版本報告，因為代碼的意義在不同系統版本中是一致的；然而，不能始終保證這點，當不能保證意義一致時， 必須（SHALL） 將版本資訊也一併作交換。

如果專門術語沒有明確定義應該使用什麼字串來識別代碼系統的版本，建議使用版本正式發布的日期（用FHIR日期格式表示）作為版本日期。

系統定義的語法之符號；符號可能是一個預先定義的代碼，也可能是代碼系統定義的語法中的表達式（如後組合配對／後組合式）。

需要參照系統中的一個特定代碼

遵循系統的規則以呈現代碼含義的表示法

需要能為不了解此系統的讀者呈現可讀的代碼含義

表明此編碼是由使用者直接選擇，例如：從可用項目（代碼或顯示名稱）的清單中選擇。

在一系列備選方案中，直接選擇的代碼是新翻譯最合適的起點；關於「直接選擇」的確切意義，存在模糊不清之處，可能需要貿易夥伴的同意，以更完整澄清此資料項目的使用及其後果。

已被確定為一個臨床安全準則—此確切的系統／代碼對(code pair)是被明確選擇的，而不是由系統根據一些規則或是程式語言處理判斷。

輸入資料的使用者所見／所選／所說的人類可讀文字表述，和（或）其代表使用者的預期含義。

很多時候，此文字表述與其中一個代碼的顯示名稱相同。

專門術語中的代碼並不總是能捕捉人類使用的細微差別的正確意義，或者根本就沒有合適的代碼；這些情況下，文字表述被用來捕捉來源的全部意義。

建立值的命名空間－即一個描述一組值的唯一URL

Identifier.system總是區分大小寫

有許多識別碼的集合。為了進行兩個識別碼的對應，我們需要知道我們處理的是哪一組。系統指明了一個特定的唯一識別碼集。

識別碼中通常與使用者有關的部分，在系統情境內是唯一的。

如果此值是一個完整的URI，那麼此系統 必須（SHALL） 是urn:ietf:rfc:3986。此值的主要目的是為了可運算的對應。因此，為了比較的目的，它可能會被正規化（例如：去除不重要的空白、破折號等）。一個為人顯示的格式化的值可以使用Rendered Value擴充來傳達。除非對Identifier.system的了解使處理者確信不區分大小寫的處理是安全的，否則Identifier.value應被視為區分大小寫。

識別碼有效／曾經有效使用的時段或期間

簽發／管理識別碼的機構

Identifier.assigner可以省略.reference資料項目，只包含一個.display資料項目，反映指定機構的名稱或其他文字表述資訊。

適用於護照號碼

病人幾乎總是被指定一個特定的數值型的唯一識別碼（identifier）

這個唯一識別碼（identifier）的用途

應用程式可以假定一個識別碼是永久的，除非它明確說它是暫時的。

如果知道，請說明此識別碼的目的；應填入所綁定值集中的其中一個代碼。

允許從一組識別碼中為特定的使用情境選擇適當的識別碼

識別碼的代碼型別，用於決定特定目適用的識別碼。

這個資料項目只涉及識別碼的一般類別。它 必須沒有（SHALL NOT） 被用於與Identifier.system 1..1對應的代碼。一些識別碼可能由於常見的用法而屬於多個類別。在系統是已知的情況下，型別是不必要的，因為型別總是系統定義的一部分。然而，系統經常需要處理系統不為人知的識別碼。型別和系統之間不是1:1的關係，因為許多不同的系統有相同的型別。

識別碼的型別，用於決定特定目的所適用的識別碼；應填入所綁定值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

允許使用者在不知道識別碼系統的情況下利用識別碼

由專門術語系統（terminology system）所定義之代碼的參照

代碼可以在列舉清單（enumerations）或代碼清單（code lists）中非常隨意地定義，直至有非常正式的定義，例如：SNOMED CT—更多資訊見HL7 v3核心原則（Core Principles）。編碼的排序是未定義的因而 必須沒有（SHALL NOT） 被用來推斷意義。一般來說，最多只有一個編碼值（coding values）會被標記為UserSelected = true。

允許代碼系統中的替代編碼，以及翻譯到其他編碼系統。

定義代碼中符號意義的代碼系統識別

URI可以是一個OID（urn:oid:...）或一個UUID（urn:uuid:...）；OID和UUID 必須（SHALL） 參照HL7 OID註冊中心；否則，URI應該來自HL7的FHIR定義的特殊URI列表，或者它應該參照一些明確建立的系统定義。

需要明確說明符號定義的來源

選擇此代碼時使用的代碼系統版本；請注意，一個維護良好的代碼系統不需要版本報告，因為代碼的意義在不同系統版本中是一致的；然而，不能始終保證這點，當不能保證意義一致時， 必須（SHALL） 將版本資訊也一併作交換。

如果專門術語沒有明確定義應該使用什麼字串來識別代碼系統的版本，建議使用版本正式發布的日期（用FHIR日期格式表示）作為版本日期。

系統定義的語法之符號；符號可能是一個預先定義的代碼，也可能是代碼系統定義的語法中的表達式（如後組合配對／後組合式）。

需要參照系統中的一個特定代碼

遵循系統的規則以呈現代碼含義的表示法

需要能為不了解此系統的讀者呈現可讀的代碼含義

表明此編碼是由使用者直接選擇，例如：從可用項目（代碼或顯示名稱）的清單中選擇。

在一系列備選方案中，直接選擇的代碼是新翻譯最合適的起點；關於「直接選擇」的確切意義，存在模糊不清之處，可能需要貿易夥伴的同意，以更完整澄清此資料項目的使用及其後果。

已被確定為一個臨床安全準則—此確切的系統／代碼對(code pair)是被明確選擇的，而不是由系統根據一些規則或是程式語言處理判斷。

輸入資料的使用者所見／所選／所說的人類可讀文字表述，和（或）其代表使用者的預期含義。

很多時候，此文字表述與其中一個代碼的顯示名稱相同。

專門術語中的代碼並不總是能捕捉人類使用的細微差別的正確意義，或者根本就沒有合適的代碼；這些情況下，文字表述被用來捕捉來源的全部意義。

建立值的命名空間－即一個描述一組值的唯一URL

Identifier.system總是區分大小寫

有許多識別碼的集合。為了進行兩個識別碼的對應，我們需要知道我們處理的是哪一組。系統指明了一個特定的唯一識別碼集。

識別碼中通常與使用者有關的部分，在系統情境內是唯一的。

如果此值是一個完整的URI，那麼此系統 必須（SHALL） 是urn:ietf:rfc:3986。此值的主要目的是為了可運算的對應。因此，為了比較的目的，它可能會被正規化（例如：去除不重要的空白、破折號等）。一個為人顯示的格式化的值可以使用Rendered Value擴充來傳達。除非對Identifier.system的了解使處理者確信不區分大小寫的處理是安全的，否則Identifier.value應被視為區分大小寫。

識別碼有效／曾經有效使用的時段或期間

簽發／管理識別碼的機構

Identifier.assigner可以省略.reference資料項目，只包含一個.display資料項目，反映指定機構的名稱或其他文字表述資訊。

適用於居留證號碼

病人幾乎總是被指定一個特定的數值型的唯一識別碼（identifier）

這個唯一識別碼（identifier）的用途

應用程式可以假定一個識別碼是永久的，除非它明確說它是暫時的。

如果知道，請說明此識別碼的目的；應填入所綁定值集中的其中一個代碼。

允許從一組識別碼中為特定的使用情境選擇適當的識別碼

識別碼的代碼型別，用於決定特定目適用的識別碼。

這個資料項目只涉及識別碼的一般類別。它 必須沒有（SHALL NOT） 被用於與Identifier.system 1..1對應的代碼。一些識別碼可能由於常見的用法而屬於多個類別。在系統是已知的情況下，型別是不必要的，因為型別總是系統定義的一部分。然而，系統經常需要處理系統不為人知的識別碼。型別和系統之間不是1:1的關係，因為許多不同的系統有相同的型別。

識別碼的型別，用於決定特定目的所適用的識別碼；應填入所綁定值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

允許使用者在不知道識別碼系統的情況下利用識別碼

由專門術語系統（terminology system）所定義之代碼的參照

代碼可以在列舉清單（enumerations）或代碼清單（code lists）中非常隨意地定義，直至有非常正式的定義，例如：SNOMED CT—更多資訊見HL7 v3核心原則（Core Principles）。編碼的排序是未定義的因而 必須沒有（SHALL NOT） 被用來推斷意義。一般來說，最多只有一個編碼值（coding values）會被標記為UserSelected = true。

允許代碼系統中的替代編碼，以及翻譯到其他編碼系統。

定義代碼中符號意義的代碼系統識別

URI可以是一個OID（urn:oid:...）或一個UUID（urn:uuid:...）；OID和UUID 必須（SHALL） 參照HL7 OID註冊中心；否則，URI應該來自HL7的FHIR定義的特殊URI列表，或者它應該參照一些明確建立的系统定義。

需要明確說明符號定義的來源

選擇此代碼時使用的代碼系統版本；請注意，一個維護良好的代碼系統不需要版本報告，因為代碼的意義在不同系統版本中是一致的；然而，不能始終保證這點，當不能保證意義一致時， 必須（SHALL） 將版本資訊也一併作交換。

如果專門術語沒有明確定義應該使用什麼字串來識別代碼系統的版本，建議使用版本正式發布的日期（用FHIR日期格式表示）作為版本日期。

系統定義的語法之符號；符號可能是一個預先定義的代碼，也可能是代碼系統定義的語法中的表達式（如後組合配對／後組合式）。

需要參照系統中的一個特定代碼

遵循系統的規則以呈現代碼含義的表示法

需要能為不了解此系統的讀者呈現可讀的代碼含義

表明此編碼是由使用者直接選擇，例如：從可用項目（代碼或顯示名稱）的清單中選擇。

在一系列備選方案中，直接選擇的代碼是新翻譯最合適的起點；關於「直接選擇」的確切意義，存在模糊不清之處，可能需要貿易夥伴的同意，以更完整澄清此資料項目的使用及其後果。

已被確定為一個臨床安全準則—此確切的系統／代碼對(code pair)是被明確選擇的，而不是由系統根據一些規則或是程式語言處理判斷。

輸入資料的使用者所見／所選／所說的人類可讀文字表述，和（或）其代表使用者的預期含義。

很多時候，此文字表述與其中一個代碼的顯示名稱相同。

專門術語中的代碼並不總是能捕捉人類使用的細微差別的正確意義，或者根本就沒有合適的代碼；這些情況下，文字表述被用來捕捉來源的全部意義。

建立值的命名空間－即一個描述一組值的唯一URL

Identifier.system總是區分大小寫

有許多識別碼的集合。為了進行兩個識別碼的對應，我們需要知道我們處理的是哪一組。系統指明了一個特定的唯一識別碼集。

識別碼中通常與使用者有關的部分，在系統情境內是唯一的。

如果此值是一個完整的URI，那麼此系統 必須（SHALL） 是urn:ietf:rfc:3986。此值的主要目的是為了可運算的對應。因此，為了比較的目的，它可能會被正規化（例如：去除不重要的空白、破折號等）。一個為人顯示的格式化的值可以使用Rendered Value擴充來傳達。除非對Identifier.system的了解使處理者確信不區分大小寫的處理是安全的，否則Identifier.value應被視為區分大小寫。

識別碼有效／曾經有效使用的時段或期間

簽發／管理識別碼的機構

Identifier.assigner可以省略.reference資料項目，只包含一個.display資料項目，反映指定機構的名稱或其他文字表述資訊。

適用於病歷號

病人幾乎總是被指定一個特定的數值型的唯一識別碼（identifier）

這個唯一識別碼（identifier）的用途

應用程式可以假定一個識別碼是永久的，除非它明確說它是暫時的。

如果知道，請說明此識別碼的目的；應填入所綁定值集中的其中一個代碼。

允許從一組識別碼中為特定的使用情境選擇適當的識別碼

識別碼的代碼型別，用於決定特定目適用的識別碼。

這個資料項目只涉及識別碼的一般類別。它 必須沒有（SHALL NOT） 被用於與Identifier.system 1..1對應的代碼。一些識別碼可能由於常見的用法而屬於多個類別。在系統是已知的情況下，型別是不必要的，因為型別總是系統定義的一部分。然而，系統經常需要處理系統不為人知的識別碼。型別和系統之間不是1:1的關係，因為許多不同的系統有相同的型別。

識別碼的型別，用於決定特定目的所適用的識別碼；應填入所綁定值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

允許使用者在不知道識別碼系統的情況下利用識別碼

由專門術語系統（terminology system）所定義之代碼的參照

代碼可以在列舉清單（enumerations）或代碼清單（code lists）中非常隨意地定義，直至有非常正式的定義，例如：SNOMED CT—更多資訊見HL7 v3核心原則（Core Principles）。編碼的排序是未定義的因而 必須沒有（SHALL NOT） 被用來推斷意義。一般來說，最多只有一個編碼值（coding values）會被標記為UserSelected = true。

允許代碼系統中的替代編碼，以及翻譯到其他編碼系統。

定義代碼中符號意義的代碼系統識別

URI可以是一個OID（urn:oid:...）或一個UUID（urn:uuid:...）；OID和UUID 必須（SHALL） 參照HL7 OID註冊中心；否則，URI應該來自HL7的FHIR定義的特殊URI列表，或者它應該參照一些明確建立的系统定義。

需要明確說明符號定義的來源

選擇此代碼時使用的代碼系統版本；請注意，一個維護良好的代碼系統不需要版本報告，因為代碼的意義在不同系統版本中是一致的；然而，不能始終保證這點，當不能保證意義一致時， 必須（SHALL） 將版本資訊也一併作交換。

如果專門術語沒有明確定義應該使用什麼字串來識別代碼系統的版本，建議使用版本正式發布的日期（用FHIR日期格式表示）作為版本日期。

系統定義的語法之符號；符號可能是一個預先定義的代碼，也可能是代碼系統定義的語法中的表達式（如後組合配對／後組合式）。

需要參照系統中的一個特定代碼

遵循系統的規則以呈現代碼含義的表示法

需要能為不了解此系統的讀者呈現可讀的代碼含義

表明此編碼是由使用者直接選擇，例如：從可用項目（代碼或顯示名稱）的清單中選擇。

在一系列備選方案中，直接選擇的代碼是新翻譯最合適的起點；關於「直接選擇」的確切意義，存在模糊不清之處，可能需要貿易夥伴的同意，以更完整澄清此資料項目的使用及其後果。

已被確定為一個臨床安全準則—此確切的系統／代碼對(code pair)是被明確選擇的，而不是由系統根據一些規則或是程式語言處理判斷。

輸入資料的使用者所見／所選／所說的人類可讀文字表述，和（或）其代表使用者的預期含義。

很多時候，此文字表述與其中一個代碼的顯示名稱相同。

專門術語中的代碼並不總是能捕捉人類使用的細微差別的正確意義，或者根本就沒有合適的代碼；這些情況下，文字表述被用來捕捉來源的全部意義。

建立值的命名空間－即一個描述一組值的唯一URL

Identifier.system總是區分大小寫

有許多識別碼的集合。為了進行兩個識別碼的對應，我們需要知道我們處理的是哪一組。系統指明了一個特定的唯一識別碼集。

識別碼中通常與使用者有關的部分，在系統情境內是唯一的。

如果此值是一個完整的URI，那麼此系統 必須（SHALL） 是urn:ietf:rfc:3986。此值的主要目的是為了可運算的對應。因此，為了比較的目的，它可能會被正規化（例如：去除不重要的空白、破折號等）。一個為人顯示的格式化的值可以使用Rendered Value擴充來傳達。除非對Identifier.system的了解使處理者確信不區分大小寫的處理是安全的，否則Identifier.value應被視為區分大小寫。

識別碼有效／曾經有效使用的時段或期間

簽發／管理識別碼的機構

Identifier.assigner可以省略.reference資料項目，只包含一個.display資料項目，反映指定機構的名稱或其他文字表述資訊。

這位病人的紀錄是否在使用中（active）。許多系統使用這個屬性來標記為非現有（non-current）病人，例如那些根據機構的業務規則在一段時間內沒有被看到的病人。

它經常被用來過濾病人清單以排除inactive的病人

已過世的病人也可能因為同樣的原因被標記為inactive，但在過世後的一段時間內可能是active。

如果一筆病人紀錄沒有在使用，但與另一筆使用中的病人紀錄相連結，那麼未來的病人／紀錄更新應該發生在另一筆病人紀錄。

若紀錄因為錯誤而創建，需要能夠將這位病人紀錄標記為不使用

個人名字

一位病人可能有多個姓名，有不同的用途或適用期。對於動物來說，這個姓名是一個「HumanName」，它是人類指定和使用的，具有相同的模式。

需要能夠追踪病人的多個姓名。例如：正式姓名及配偶姓名。 必須（SHALL） 總是提供姓名的完整拼法。

個人名字

一位病人可能有多個姓名，有不同的用途或適用期。對於動物來說，這個姓名是一個「HumanName」，它是人類指定和使用的，具有相同的模式。

需要能夠追踪病人的多個姓名。例如：正式姓名及配偶姓名。 必須（SHALL） 總是提供姓名的完整拼法。

此姓名的用途

應用程式可以假定一個姓名是永久的，除非它明確說它是暫時或舊的。

人名的使用情況；應填入所綁定值集中的其中一個代碼。

允許從一組姓名中為特定的使用情境選擇適當的姓名

完整姓名的文字表述。由於世界各地的文化差異，取得資料的系統可能不知道如何正確地呈現姓名；此外，不是所有的名字部分都呈現予姓或名。因此，我們強烈建議創建者透過這個資料項目提供姓名的顯示文字。

可以同時提供文字表述（text）和部分（part）。更新姓名的應用程式 必須（SHALL） 確保當test和lpart都存在時，text中不包含part中沒有的內容。

一個可呈現的、未編碼的形式。

姓名中與族譜相關的部分。在一些文化中（如厄立特里亞），兒子的姓氏是其父親的名字。

姓氏可以使用擴充名（de、nl、es相關文化）分解成具體的部分（part）

姓名中的「名」

如果只記錄首字母，可以用它們來代替完整姓名。首字母可以分為多個名，但由於實際情況的限制，通常不會這樣做。這個資料項目不被稱為 「first name」，因為「given name」並不總是排在前面。

由於學術、法規、就業或貴族身份等原因而獲得的名，並出現在姓名的開頭。

由於學術、法規、就業或貴族身份等原因而獲得的名，並出現在姓名的開頭。

表明這個姓名對此病人有效的時間區間或期間

允許多個姓名按其歷史情境（效期）儲存

個人名字

一位病人可能有多個姓名，有不同的用途或適用期。對於動物來說，這個姓名是一個「HumanName」，它是人類指定和使用的，具有相同的模式。

需要能夠追踪病人的多個姓名。例如：正式姓名及配偶姓名。 必須（SHALL） 總是提供姓名的完整拼法。

此姓名的用途

應用程式可以假定一個姓名是永久的，除非它明確說它是暫時或舊的。

人名的使用情況；應填入所綁定值集中的其中一個代碼。

允許從一組姓名中為特定的使用情境選擇適當的姓名

完整姓名的文字表述。由於世界各地的文化差異，取得資料的系統可能不知道如何正確地呈現姓名；此外，不是所有的名字部分都呈現予姓或名。因此，我們強烈建議創建者透過這個資料項目提供姓名的顯示文字。

可以同時提供文字表述（text）和部分（part）。更新姓名的應用程式 必須（SHALL） 確保當test和lpart都存在時，text中不包含part中沒有的內容。

一個可呈現的、未編碼的形式。

姓名中與族譜相關的部分。在一些文化中（如厄立特里亞），兒子的姓氏是其父親的名字。

姓氏可以使用擴充名（de、nl、es相關文化）分解成具體的部分（part）

姓名中的「名」

如果只記錄首字母，可以用它們來代替完整姓名。首字母可以分為多個名，但由於實際情況的限制，通常不會這樣做。這個資料項目不被稱為 「first name」，因為「given name」並不總是排在前面。

由於學術、法規、就業或貴族身份等原因而獲得的名，並出現在姓名的開頭。

由於學術、法規、就業或貴族身份等原因而獲得的名，並出現在姓名的開頭。

表明這個姓名對此病人有效的時間區間或期間

允許多個姓名按其歷史情境（效期）儲存

個人名字

一位病人可能有多個姓名，有不同的用途或適用期。對於動物來說，這個姓名是一個「HumanName」，它是人類指定和使用的，具有相同的模式。

需要能夠追踪病人的多個姓名。

此姓名的用途

應用程式可以假定一個姓名是永久的，除非它明確說它是暫時或舊的。

人名的使用情況；應填入所綁定值集中的其中一個代碼。

允許從一組姓名中為特定的使用情境選擇適當的姓名

完整姓名的文字表述。由於世界各地的文化差異，取得資料的系統可能不知道如何正確地呈現姓名；此外，不是所有的名字部分都呈現予姓或名。因此，我們強烈建議創建者透過這個資料項目提供姓名的顯示文字。

可以同時提供文字表述（text）和部分（part）。更新姓名的應用程式 必須（SHALL） 確保當test和lpart都存在時，text中不包含part中沒有的內容。

一個可呈現的、未編碼的形式。

表明這個姓名對此病人有效的時間區間或期間

允許多個姓名按其歷史情境（效期）儲存

個人名字

一位病人可能有多個姓名，有不同的用途或適用期。對於動物來說，這個姓名是一個「HumanName」，它是人類指定和使用的，具有相同的模式。

需要能夠追踪病人的多個姓名。

此姓名的用途

應用程式可以假定一個姓名是永久的，除非它明確說它是暫時或舊的。

人名的使用情況；應填入所綁定值集中的其中一個代碼。

允許從一組姓名中為特定的使用情境選擇適當的姓名

完整姓名的文字表述。由於世界各地的文化差異，取得資料的系統可能不知道如何正確地呈現姓名；此外，不是所有的名字部分都呈現予姓或名。因此，我們強烈建議創建者透過這個資料項目提供姓名的顯示文字。

可以同時提供文字表述（text）和部分（part）。更新姓名的應用程式 必須（SHALL） 確保當test和lpart都存在時，text中不包含part中沒有的內容。

一個可呈現的、未編碼的形式。

表明這個姓名對此病人有效的時間區間或期間

允許多個姓名按其歷史情境（效期）儲存

可與此人聯絡的詳細聯絡方式（如電話或電子郵件地址等）

一位病人可能有多種聯絡方式，有不同的用途或適用期。可能需要有緊急聯絡此人的選項，也需要幫忙識別身份。地址可能不會直接聯絡到此人，但可能到透過他人代為聯絡（意即家中的電話）。

人們有（主要）方式與他們聯絡，如電話、電子郵件。

聯絡方式的通訊形式－需要什麼通訊系統進行聯絡

應填入所綁定值集中的其中一個代碼。

實際的聯絡方式之細節，針對指定的通訊系統提供有意義的形式（電話號碼或是電子郵件位址）

額外的文字資料，例如電話分機號碼、或關於聯絡人的說明，有時也包括於此值。

需支援非嚴格格式控制之舊有號碼

確定聯絡方式的用途

應用程式可以假定一個聯絡方法是目前使用中，除非它明確說它是暫時的或舊的。

應填入所綁定值集中的其中一個代碼。

需要追蹤此人使用這種聯絡的方式，使用者可以選擇適合他們用途的聯絡方式。

具體說明使用一組聯繫方式的優先順序，較小排名序位的聯絡方式比較大排名序位的聯絡方式之序位還要前面。

請注意，排名序位沒有一定要遵循聯絡方式在實例中呈現的順序。

此聯絡方式的使用效期

Administrative Gender 為行政管理及保存紀錄目的之病人性別

行政管理用之性別可能不符合由遺傳學或個人偏好的識別所決定的生物性別。請注意，對於人類，特別是動物，除了男性和女性，還有其他合法歸類的可能性，儘管絕大多數系統和情境只支持男性和女性。提供決策支援或執行業務規則的系統最好以檢驗檢查（Observation）呈現特定性別或感興趣的性別（解剖學、染色體、社會等）。然而，由於這些檢驗檢驗不常被記錄，預設為行政管理用之性別是常見的做法。在這種預設的情況下，規則的執行應該允許行政管理用和生物、染色體和其他性別方面的差異。例如：關於男性子宮切除的警訊應該作為警告或可推翻的錯誤來處理，而不是 「硬（hard） 」錯誤。關於溝通病人性別的更多資訊，請參閱Patient Gender及Sex的部分。

病人性別；應填入所綁定值集中的其中一個代碼。

性別用於結合（至少）姓名和出生日期以識別個人身份

個人的出生日期

如果真實的出生日期未知，至少應該提供一個估計的出生年份作為猜測。有一個標準的擴充 「patient-birthTime」，應該於需要出生時間（Time）資訊時使用（例如：在產科／新生兒照護系統中）。

個人的年齡驅動著許多臨床過程／進程

表示此人是否過世

如果實例中沒有值，就意味著沒有關於此人是否過世的聲明。大多數系統會把沒有數值解釋為這個人還活著的標誌。

病人已經過世的事實影響了臨床過程／進度。另外，在人際溝通和關係管理中，有必要知道這個人是否活著。

此人的地址

病人可能有多個地址，有不同的用途或適用期。

可能需要記錄病人的地址，以便聯繫、結算或報告的要求，也有助於識別身份。

這個欄位包含病人的目前婚姻（民事）狀態

病人的婚姻狀態；應填入所綁定值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

如果不是所有的系統都能取得此資訊

表示病人是否是為多胞胎（佈林值）或表示實際的出生順序（整數值）

在提供valueInteger的情況下，這個數字是序列中的出生序。例如：三胞胎中的中間胎兒是valueInteger=2，第三胎兒是valueInteger=3，如果是為三胞胎提供布林值，那麼所有3位病人的紀錄都是valueBoolean=true（沒有指明出生序）。

用於消除多胎孩童的歧義，特別是在照護人員沒有見到病人的情況下，例如：在實驗室。

病人的影像（照片）

指引： 使用個人影像，而不是臨床影像。 限制尺寸為縮圖。 保持低位元組小檔案以便更新resource。

許多EHR系統有能力取得病人的影像，這也符合較新的社群媒體的使用。

病人的聯絡人（如監護人、伴侶、朋友）。

聯絡涵蓋所有種類的聯絡人：家人、業務聯絡、監護人、照顧者。不適用於登記血統和家庭關係，因這超出聯絡的目的。

需能聯絡到的病人的人。

可以透過正式參照一個專門術語或知識本體來定義一個概念，或者也可以文字表述此概念。

應填入所綁定值集中的其中一個代碼。

根據情況決定哪位聯絡人最有關聯以作聯繫

與聯絡人有關的姓名

聯絡人需要以姓名來識別，但通常不需要此聯絡人的其他姓名的細節。

此姓名的用途

應用程式可以假定一個姓名是永久的，除非它明確說它是暫時或舊的。

人名的使用情況；應填入所綁定值集中的其中一個代碼。

允許從一組姓名中為特定的使用情境選擇適當的姓名

完整姓名的文字表述。由於世界各地的文化差異，取得資料的系統可能不知道如何正確地呈現姓名；此外，不是所有的名字部分都呈現予姓或名。因此，我們強烈建議創建者透過這個資料項目提供姓名的顯示文字。

可以同時提供文字表述（text）和部分（part）。更新姓名的應用程式 必須（SHALL） 確保當test和lpart都存在時，text中不包含part中沒有的內容。

一個可呈現的、未編碼的形式。

姓名中與族譜相關的部分。在一些文化中（如厄立特里亞），兒子的姓氏是其父親的名字。

姓氏可以使用擴充名（de、nl、es相關文化）分解成具體的部分（part）

姓名中的「名」

如果只記錄首字母，可以用它們來代替完整姓名。首字母可以分為多個名，但由於實際情況的限制，通常不會這樣做。這個資料項目不被稱為 「first name」，因為「given name」並不總是排在前面。

由於學術、法規、就業或貴族身份等原因而獲得的名，並出現在姓名的開頭。

由於學術、法規、就業或貴族身份等原因而獲得的名，並出現在姓名的開頭。

表明這個姓名對此病人有效的時間區間或期間

允許多個姓名按其歷史情境（效期）儲存

此人的詳細聯絡方式，例如：電話號碼或電子郵件地址。

聯絡人可能有多種聯絡方式，有不同的用途或適用期。可能需要有緊急聯絡此人的選項，及需要幫忙身份識別。

人們可透過（主要）方式與他們聯絡，例如電話、電子郵件。

聯絡方式的通訊形式－需要什麼通訊系統進行聯絡

應填入所綁定值集中的其中一個代碼。

實際的聯絡方式之細節，針對指定的通訊系統提供有意義的形式（電話號碼或是電子郵件位址）。

額外的文字資料，例如電話分機號碼、或關於聯絡人的說明，有時也包括於此值。

需支援非嚴格格式控制之舊有號碼

確定聯絡方式的用途

應用程式可以假定一個聯絡方法是目前使用中，除非它明確說它是暫時的或舊的。

應填入所綁定值集中的其中一個代碼。

需要追蹤此人使用這種聯絡的方式，使用者可以選擇適合他們用途的聯絡方式。

具體說明使用一組聯繫方式的優先順序，較小排名序位的聯絡方式比較大排名序位的聯絡方式之序位還要前面。

請注意，排名序位沒有一定要遵循聯絡方式在實例中呈現的順序。

此聯絡方式的使用效期

聯絡人的地址

需要紀錄用以聯絡聯絡人的郵件地址或到訪地址

Administrative Gender為行政管理的及保存紀錄目的之聯絡人性別

聯絡人的性別；應填入所綁定值集中的其中一個代碼。

用以正確稱呼聯絡人

聯絡人為機構或聯絡人為其工作的機構

監護人或與業務相關聯絡與此機構有關

與此病人有關的聯絡人或機構的有效聯絡期

可用於與病人溝通其健康狀況的語言。

如果沒有指定語言，這意味著預設使用當地語言。如果你需要多種模式的熟練程度，那麼你需要多個Patient.Communication關聯。對於動物來說，語言不是相關的欄位，應該不存在於實例中。如果病人不講預設的當地語言，那麼可以使用 「（Interpreter Required Standard）需要口譯員」來明確聲明需要口譯員。

如果病人不會說當地語言，可能需要翻譯，因此，對於病人和其他相關人員來說，所講的語言和熟練程度都是需要記錄的重要內容。

小寫的ISO-639-1字母兩個代碼表示的語言，後面可以有連字符號，大寫的ISO-3166-1字母兩個代碼表示使用此語言的地區；例如「en 」代表英語，或者 「en-US 」代表美國英語，而 「en-EN 」代表英國英語。

帶有這種精確字母大小寫的aa-BB結構是最廣泛使用的地方性符號之一。但並不是所有的系統都對其進行編碼，而是將其作為純文字表述。因此，data type為CodeableConcept而不是code。

應填入所綁定值集中的其中一個代碼。

在多語言國家的大多數系統都會想要溝通語言。並非所有的系統實際上都需要區域方言。

表示病人是否偏好此語言（相對於其他它已掌握到一定水平的語言）

此語言專門用以溝通健康照護資訊

掌握多種語言達到一定水平的人可能更偏好一種或多種語言，也就是說，在用某一種語言溝通時感到更有信心，使其他語言成為一種備用語言。

病人指定的照護服務提供者

這可能是基層健康照護提供者（在一般科醫生的情境下），也可能是在社區／失能環境中由病人提名的照護管理者，甚至是提供人力來履行照護提供者角色的機構。它不能用來記錄Care Teams，這些團隊應該在CareTeams resource中，可以連接到CarePlan或EpisodeOfCare。由於各種原因，病人可能會被記錄有多個一般科醫生，例如：一位學生在學校學期期間將他的家庭醫生與大學的醫生一起列出，或者一位至偏遠地區「飛進／飛出 」的工作者會有當地的醫師及其家庭醫生，以保持對醫療問題的瞭解。
如果需要，各行政管轄區可決定將其規範為只有1位，或每種型別1位。

病人紀錄的保管機構

僅有一個管理特定病人紀錄的機構。其他機構將擁有自己的「病人」紀錄，並可透過使用「Link」屬性將紀錄結合在一起（或可以包含關聯可信的「Person」resource）。

需要知道誰識別、管理和更新這位病人的紀錄

連結到另一個涉及同一實際病人的Patient resource。

不存在連結的病人紀錄有相互連結的假設

有多種使用案例：
由於難以一致地指明與人相關的文件而錯誤地重複製作病人紀錄，並在多個伺服器上發佈病人的資訊。

此連超所參照的另一個Patient resource

在這裡參照一個RelatedPerson，就不需要另外使用Person來將Patient及RelatedPerson作為同一個人關聯起來。

這個Patient resource與另一個Patient resource之間的連結型別

連結的型別；應填入所綁定值集中的其中一個代碼。

關於接受照護或其他健康相關服務的個人或動物的人口統計學和其他行政資訊。

resource的邏輯ID，在resource的URL中使用。一旦指定，這個值永遠不會改變。

一個resource使用新增操作（create operation）提交給伺服器時，此resource沒有id，它的id在resource被創建後由伺器分配/指定。

關於resource的metadata。這是由基礎建設維護的內容。內容的更改可能並不總是與resource的版本更改相關聯。

構建resource時遵循的一系列規則的參照，在處理內容時必須理解這些規則。通常這是對IG所定義之特殊規則及其他profiles的參照。

宣告這套規則限制了內容只能被有限的交易夥伴所理解。這從本質上限制了資料的長期有用性。然而，現有的健康生態體系高度分裂，還沒有準備好以普遍可計算的方式定義、收集和交換資料。只要有可能，實作者和/或規範編寫者應該避免使用這個資料項目。通常在使用時，此URL是對IG的參照，此IG將這些特殊規則與其他profiles、value sets等一起定義為其敘述的一部分。

編寫此resource的語言

提供語言是為了支援索引和可存取性（通常，文字表述轉語音等服務使用此語言標籤）。html lanuage tag適用於此敘述。resource上的語言標籤可用於指定從resource中的資料所產成的其他表述之語言。不是所有的內容都必須使用此語言。不應該假定Resource.language自動適用於敘述。如果指定語言，它也應該被指定在html中的div資料項目（關於xml:lang和html lang屬性之間的關係，見HTML5中的規則）。

人類語言；鼓勵使用CommonLanguages代碼表中的代碼，但不強制一定要使用此代碼表，你也可使用其他代碼表的代碼或單純以文字表示。

人可讀的敘述，包含resource的摘要，可用於向人表述resource的內容。敘述不需要對所有的結構化資料進行編碼，但需要包含足夠的細節使人在閱讀敘述時理解「臨床安全性」。resource定義有哪些內容應該在敘述中表示，以確保臨床安全。

內嵌（contained）的resource沒有敘述，非內嵌（contained）的resource則 建議應該（SHOULD） 有敘述。有時resource可能只有文字表述，很少或沒有額外的結構化資料（只要滿足所有minOccurs=1的資料項目）。這可能出現在舊系統的資料，當資訊以 「文字表述區塊（text blob） 」的形式被取得，或者文字表述是原始輸入或說明，而編碼資訊稍後再添加。

這些resource內嵌（contains）的resource不會另外存於任何FHIR伺服器，意即它們無法在任何FHIR伺服器中被找到，也無法有自己獨立的資料異動／交易（transaction）範圍。

當內容可以從任何FHIR伺服器找到時，不應該以內嵌（contained）resource的方式呈現，因為一旦失去識別，再次恢復它是非常困難的（並且取決於情境）。內嵌（contained）的resource可在它們的meta資料項目中表述profiles和tag，但不應該有安全標號（security labels）。

可用於表示不屬於此resource基本定義的額外資訊。為了擴充的使用安全和可管理，對擴充的定義和使用有一套嚴格的管理。儘管任何實作者都可以定義一個擴充，但作為擴充定義的一部分，必須（SHALL） 滿足一系列要求。

任何應用程式、專案或標準使用擴充時，都不應該帶有任何負面的聯想。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

年齡

The nationality of the patient.

可以用來表示不屬於此resource的基本定義的額外資訊，並修改包含它所內嵌（contained）的資料項目的理解和/或對包含資料項目之後續使用的理解。通常修飾用的資料項目提供否定或限定的資訊。為了使擴充的使用安全和可管理，對擴充的定義和使用有一套嚴格的管理。雖然任何實作者都可以定義一個擴充，但在定義擴充時 必須（SHALL） 滿足一組要求。處理resource的應用程式需要檢查修飾用的擴充資料項目。
修飾用的擴充資料項目 必須沒有（SHALL NOT） 改變resource或DomainResource上任何資料項目的含義（包括不能改變modifierExtension本身的含義）。

任何應用程式、專案或標準使用擴充時，都不應該帶有任何負面的聯想。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

修飾用的資料項目擴充允許將不能安全地忽略的擴充，與絕大多數可以安全地忽略的擴充明確區分開來。這樣做有助於促進可互操作性，因為無需禁止實作者使用擴充，想要瞭解更多資訊，請參見[修飾用的資料項目擴充之定義]（http://hl7.org/fhir/R4/extensibility.html#modifierExtension）。

病人的唯一識別碼（identifier）

病人幾乎總是被指定一個特定的數值型的唯一識別碼（identifier）

適用於身分證字號

病人幾乎總是被指定一個特定的數值型的唯一識別碼（identifier）

這個唯一識別碼（identifier）的用途

應用程式可以假定一個識別碼是永久的，除非它明確說它是暫時的。

如果知道，請說明此識別碼的目的；應填入所綁定值集中的其中一個代碼。

允許從一組識別碼中為特定的使用情境選擇適當的識別碼

識別碼的代碼型別，用於決定特定目適用的識別碼。

這個資料項目只涉及識別碼的一般類別。它 必須沒有（SHALL NOT） 被用於與Identifier.system 1..1對應的代碼。一些識別碼可能由於常見的用法而屬於多個類別。在系統是已知的情況下，型別是不必要的，因為型別總是系統定義的一部分。然而，系統經常需要處理系統不為人知的識別碼。型別和系統之間不是1:1的關係，因為許多不同的系統有相同的型別。

識別碼的型別，用於決定特定目的所適用的識別碼；應填入所綁定值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

允許使用者在不知道識別碼系統的情況下利用識別碼

由專門術語系統（terminology system）所定義之代碼的參照

代碼可以在列舉清單（enumerations）或代碼清單（code lists）中非常隨意地定義，直至有非常正式的定義，例如：SNOMED CT—更多資訊見HL7 v3核心原則（Core Principles）。編碼的排序是未定義的因而 必須沒有（SHALL NOT） 被用來推斷意義。一般來說，最多只有一個編碼值（coding values）會被標記為UserSelected = true。

允許代碼系統中的替代編碼，以及翻譯到其他編碼系統。

定義代碼中符號意義的代碼系統識別

URI可以是一個OID（urn:oid:...）或一個UUID（urn:uuid:...）；OID和UUID 必須（SHALL） 參照HL7 OID註冊中心；否則，URI應該來自HL7的FHIR定義的特殊URI列表，或者它應該參照一些明確建立的系统定義。

需要明確說明符號定義的來源

選擇此代碼時使用的代碼系統版本；請注意，一個維護良好的代碼系統不需要版本報告，因為代碼的意義在不同系統版本中是一致的；然而，不能始終保證這點，當不能保證意義一致時， 必須（SHALL） 將版本資訊也一併作交換。

如果專門術語沒有明確定義應該使用什麼字串來識別代碼系統的版本，建議使用版本正式發布的日期（用FHIR日期格式表示）作為版本日期。

系統定義的語法之符號；符號可能是一個預先定義的代碼，也可能是代碼系統定義的語法中的表達式（如後組合配對／後組合式）。

需要參照系統中的一個特定代碼

An Extension

識別碼後綴詞

遵循系統的規則以呈現代碼含義的表示法

需要能為不了解此系統的讀者呈現可讀的代碼含義

表明此編碼是由使用者直接選擇，例如：從可用項目（代碼或顯示名稱）的清單中選擇。

在一系列備選方案中，直接選擇的代碼是新翻譯最合適的起點；關於「直接選擇」的確切意義，存在模糊不清之處，可能需要貿易夥伴的同意，以更完整澄清此資料項目的使用及其後果。

已被確定為一個臨床安全準則—此確切的系統／代碼對(code pair)是被明確選擇的，而不是由系統根據一些規則或是程式語言處理判斷。

輸入資料的使用者所見／所選／所說的人類可讀文字表述，和（或）其代表使用者的預期含義。

很多時候，此文字表述與其中一個代碼的顯示名稱相同。

專門術語中的代碼並不總是能捕捉人類使用的細微差別的正確意義，或者根本就沒有合適的代碼；這些情況下，文字表述被用來捕捉來源的全部意義。

建立值的命名空間－即一個描述一組值的唯一URL

Identifier.system總是區分大小寫

有許多識別碼的集合。為了進行兩個識別碼的對應，我們需要知道我們處理的是哪一組。系統指明了一個特定的唯一識別碼集。

識別碼中通常與使用者有關的部分，在系統情境內是唯一的。

如果此值是一個完整的URI，那麼此系統 必須（SHALL） 是urn:ietf:rfc:3986。此值的主要目的是為了可運算的對應。因此，為了比較的目的，它可能會被正規化（例如：去除不重要的空白、破折號等）。一個為人顯示的格式化的值可以使用Rendered Value擴充來傳達。除非對Identifier.system的了解使處理者確信不區分大小寫的處理是安全的，否則Identifier.value應被視為區分大小寫。

識別碼有效／曾經有效使用的時段或期間

簽發／管理識別碼的機構

Identifier.assigner可以省略.reference資料項目，只包含一個.display資料項目，反映指定機構的名稱或其他文字表述資訊。

適用於護照號碼

病人幾乎總是被指定一個特定的數值型的唯一識別碼（identifier）

這個唯一識別碼（identifier）的用途

應用程式可以假定一個識別碼是永久的，除非它明確說它是暫時的。

如果知道，請說明此識別碼的目的；應填入所綁定值集中的其中一個代碼。

允許從一組識別碼中為特定的使用情境選擇適當的識別碼

識別碼的代碼型別，用於決定特定目適用的識別碼。

這個資料項目只涉及識別碼的一般類別。它 必須沒有（SHALL NOT） 被用於與Identifier.system 1..1對應的代碼。一些識別碼可能由於常見的用法而屬於多個類別。在系統是已知的情況下，型別是不必要的，因為型別總是系統定義的一部分。然而，系統經常需要處理系統不為人知的識別碼。型別和系統之間不是1:1的關係，因為許多不同的系統有相同的型別。

識別碼的型別，用於決定特定目的所適用的識別碼；應填入所綁定值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

允許使用者在不知道識別碼系統的情況下利用識別碼

由專門術語系統（terminology system）所定義之代碼的參照

代碼可以在列舉清單（enumerations）或代碼清單（code lists）中非常隨意地定義，直至有非常正式的定義，例如：SNOMED CT—更多資訊見HL7 v3核心原則（Core Principles）。編碼的排序是未定義的因而 必須沒有（SHALL NOT） 被用來推斷意義。一般來說，最多只有一個編碼值（coding values）會被標記為UserSelected = true。

允許代碼系統中的替代編碼，以及翻譯到其他編碼系統。

定義代碼中符號意義的代碼系統識別

URI可以是一個OID（urn:oid:...）或一個UUID（urn:uuid:...）；OID和UUID 必須（SHALL） 參照HL7 OID註冊中心；否則，URI應該來自HL7的FHIR定義的特殊URI列表，或者它應該參照一些明確建立的系统定義。

需要明確說明符號定義的來源

選擇此代碼時使用的代碼系統版本；請注意，一個維護良好的代碼系統不需要版本報告，因為代碼的意義在不同系統版本中是一致的；然而，不能始終保證這點，當不能保證意義一致時， 必須（SHALL） 將版本資訊也一併作交換。

如果專門術語沒有明確定義應該使用什麼字串來識別代碼系統的版本，建議使用版本正式發布的日期（用FHIR日期格式表示）作為版本日期。

系統定義的語法之符號；符號可能是一個預先定義的代碼，也可能是代碼系統定義的語法中的表達式（如後組合配對／後組合式）。

需要參照系統中的一個特定代碼

遵循系統的規則以呈現代碼含義的表示法

需要能為不了解此系統的讀者呈現可讀的代碼含義

表明此編碼是由使用者直接選擇，例如：從可用項目（代碼或顯示名稱）的清單中選擇。

在一系列備選方案中，直接選擇的代碼是新翻譯最合適的起點；關於「直接選擇」的確切意義，存在模糊不清之處，可能需要貿易夥伴的同意，以更完整澄清此資料項目的使用及其後果。

已被確定為一個臨床安全準則—此確切的系統／代碼對(code pair)是被明確選擇的，而不是由系統根據一些規則或是程式語言處理判斷。

輸入資料的使用者所見／所選／所說的人類可讀文字表述，和（或）其代表使用者的預期含義。

很多時候，此文字表述與其中一個代碼的顯示名稱相同。

專門術語中的代碼並不總是能捕捉人類使用的細微差別的正確意義，或者根本就沒有合適的代碼；這些情況下，文字表述被用來捕捉來源的全部意義。

建立值的命名空間－即一個描述一組值的唯一URL

Identifier.system總是區分大小寫

有許多識別碼的集合。為了進行兩個識別碼的對應，我們需要知道我們處理的是哪一組。系統指明了一個特定的唯一識別碼集。

識別碼中通常與使用者有關的部分，在系統情境內是唯一的。

如果此值是一個完整的URI，那麼此系統 必須（SHALL） 是urn:ietf:rfc:3986。此值的主要目的是為了可運算的對應。因此，為了比較的目的，它可能會被正規化（例如：去除不重要的空白、破折號等）。一個為人顯示的格式化的值可以使用Rendered Value擴充來傳達。除非對Identifier.system的了解使處理者確信不區分大小寫的處理是安全的，否則Identifier.value應被視為區分大小寫。

識別碼有效／曾經有效使用的時段或期間

簽發／管理識別碼的機構

Identifier.assigner可以省略.reference資料項目，只包含一個.display資料項目，反映指定機構的名稱或其他文字表述資訊。

適用於居留證號碼

病人幾乎總是被指定一個特定的數值型的唯一識別碼（identifier）

這個唯一識別碼（identifier）的用途

應用程式可以假定一個識別碼是永久的，除非它明確說它是暫時的。

如果知道，請說明此識別碼的目的；應填入所綁定值集中的其中一個代碼。

允許從一組識別碼中為特定的使用情境選擇適當的識別碼

識別碼的代碼型別，用於決定特定目適用的識別碼。

這個資料項目只涉及識別碼的一般類別。它 必須沒有（SHALL NOT） 被用於與Identifier.system 1..1對應的代碼。一些識別碼可能由於常見的用法而屬於多個類別。在系統是已知的情況下，型別是不必要的，因為型別總是系統定義的一部分。然而，系統經常需要處理系統不為人知的識別碼。型別和系統之間不是1:1的關係，因為許多不同的系統有相同的型別。

識別碼的型別，用於決定特定目的所適用的識別碼；應填入所綁定值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

允許使用者在不知道識別碼系統的情況下利用識別碼

由專門術語系統（terminology system）所定義之代碼的參照

代碼可以在列舉清單（enumerations）或代碼清單（code lists）中非常隨意地定義，直至有非常正式的定義，例如：SNOMED CT—更多資訊見HL7 v3核心原則（Core Principles）。編碼的排序是未定義的因而 必須沒有（SHALL NOT） 被用來推斷意義。一般來說，最多只有一個編碼值（coding values）會被標記為UserSelected = true。

允許代碼系統中的替代編碼，以及翻譯到其他編碼系統。

定義代碼中符號意義的代碼系統識別

URI可以是一個OID（urn:oid:...）或一個UUID（urn:uuid:...）；OID和UUID 必須（SHALL） 參照HL7 OID註冊中心；否則，URI應該來自HL7的FHIR定義的特殊URI列表，或者它應該參照一些明確建立的系统定義。

需要明確說明符號定義的來源

選擇此代碼時使用的代碼系統版本；請注意，一個維護良好的代碼系統不需要版本報告，因為代碼的意義在不同系統版本中是一致的；然而，不能始終保證這點，當不能保證意義一致時， 必須（SHALL） 將版本資訊也一併作交換。

如果專門術語沒有明確定義應該使用什麼字串來識別代碼系統的版本，建議使用版本正式發布的日期（用FHIR日期格式表示）作為版本日期。

系統定義的語法之符號；符號可能是一個預先定義的代碼，也可能是代碼系統定義的語法中的表達式（如後組合配對／後組合式）。

需要參照系統中的一個特定代碼

遵循系統的規則以呈現代碼含義的表示法

需要能為不了解此系統的讀者呈現可讀的代碼含義

表明此編碼是由使用者直接選擇，例如：從可用項目（代碼或顯示名稱）的清單中選擇。

在一系列備選方案中，直接選擇的代碼是新翻譯最合適的起點；關於「直接選擇」的確切意義，存在模糊不清之處，可能需要貿易夥伴的同意，以更完整澄清此資料項目的使用及其後果。

已被確定為一個臨床安全準則—此確切的系統／代碼對(code pair)是被明確選擇的，而不是由系統根據一些規則或是程式語言處理判斷。

輸入資料的使用者所見／所選／所說的人類可讀文字表述，和（或）其代表使用者的預期含義。

很多時候，此文字表述與其中一個代碼的顯示名稱相同。

專門術語中的代碼並不總是能捕捉人類使用的細微差別的正確意義，或者根本就沒有合適的代碼；這些情況下，文字表述被用來捕捉來源的全部意義。

建立值的命名空間－即一個描述一組值的唯一URL

Identifier.system總是區分大小寫

有許多識別碼的集合。為了進行兩個識別碼的對應，我們需要知道我們處理的是哪一組。系統指明了一個特定的唯一識別碼集。

識別碼中通常與使用者有關的部分，在系統情境內是唯一的。

如果此值是一個完整的URI，那麼此系統 必須（SHALL） 是urn:ietf:rfc:3986。此值的主要目的是為了可運算的對應。因此，為了比較的目的，它可能會被正規化（例如：去除不重要的空白、破折號等）。一個為人顯示的格式化的值可以使用Rendered Value擴充來傳達。除非對Identifier.system的了解使處理者確信不區分大小寫的處理是安全的，否則Identifier.value應被視為區分大小寫。

識別碼有效／曾經有效使用的時段或期間