對病人、一群病人、設備和地點、和／或由這些所產生的檢體進行診斷測試的發現與解釋，報告包括臨床情境，如請求和服務提供者的資訊，以及一些混合的不可被中斷的一個或一系列結果、影像、文字和編碼的解釋，以及格式化的診斷報告。

這是為了捕捉單一的報告資訊，不適合用於顯示涵蓋多個報告的摘要資訊。例如：此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規範為每個人保留一個核心的簡易性。

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

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

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

由執行者或其他系統指定給該報告的業務用識別碼

此識別碼通常由診斷服務提供者的資訊系統指定

當從來源實驗室查詢此報告以及在FHIR情境之外連接到此報告時，需要知道在應使用什麼識別碼。

有關請求的服務的細節

注意：通常每個結果有一個檢驗服務請求，但是在某些情況下，多個檢驗服務請求可以用同一個檢驗結果resource來表示。請注意，也存在一個服務請求導致多個報告的情況。

允許追蹤報告的授權，並追蹤提案／建議是否被採納。

診斷報告的狀態

診斷報告狀態；應填入所綁定值集中的其中一個代碼

診斷服務通常會發布臨時／不完整的報告，有時候也會撤銷之前已發布的報告。

對建立報告的臨床科、部門或診斷服務進行分類的代碼（例如：心臟病學、生物化學、血液學、MRI）。主要為了搜尋、排序和顯示時使用。

允許使用各種分類方案的多個類別。精細度由值集中的類別概念來定義。可使用DiagnosticReport.code中的metadata和（或）專門術語層次結構進行更細微的過濾。

診斷報告分類；應填入所綁定值集值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

描述該診斷報告的代碼或名稱

鼓勵使用所綁定值集中的代碼，但不強制一定要使用此值集，你也可使用其他值集的代碼或單純以文字表示。

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

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

報告的對象體，通常但不總是病人。然而，診斷服務也對從其他各種來源收集的檢體進行分析。

必須(SHALL) 知道對象的背景

此DiagnosticReport所涉及的健康照護事件（例如：病人和健康照護服務提供者的互動）。

這通常是事件發生的就醫，但有些事件可能是在就醫完成之前或之後開始，但仍與就醫的情境有關（如住院前的實驗室檢驗）。

將此服務請求連接就醫（Encounter）情境

觀察值與之相關的時間或時段。當報告的對象是病人時，這通常是處置的時間或檢體採集的時間，但往往不知道日期／時間的來源，只知道日期／時間本身。

如果對病人進行診斷處置，這就是進行該處置的時間。如果有檢體，可以從檢體採集時間得出診斷相關時間，但檢體資訊並不總是可用，而且檢體和診斷相關時間之間並不總是自動的確切關係。

需要知道在病歷的什麼地方儲存檔案／呈現此報告

這個版本的報告提供給健康照護提供者的日期和時間，通常是在報告被審查和核實之後。

可能與resource本身的更新時間不同，因為那是紀錄的狀態（可能是第二個副本），而不是發報告的實際時間。

臨床醫師需要確認報告的發布日期

負責發此報告的診斷服務

這不一定是一些混合的不可被中斷的一個或一系列資料項目的來源或解釋結果的實體，它是對臨床報告負責的實體。

如果對結果有疑問，需要知道應與誰聯絡；還可能需要追蹤次級資料分析的報告來源。

對報告的結論和解釋負責的健康照護服務提供者或組織

可能不是對臨床報告負責的同一個實體

如果對結果有疑問，需要知道應與誰聯絡；還可能需要追蹤次級資料分析的報告來源。

關於此診斷報告所依據的檢體的詳細資訊

如果在檢驗結果名稱中充分指明檢體的代碼，那麼此附加資料就可能是多餘的。如果有多個檢體，可在每個檢驗檢查或檢驗檢查套組中表示。

需要能夠報告已收集檢體之資訊，這些資訊是報告的基礎。

檢驗檢查為此診斷報告的一部分

Observations可包含檢驗檢查值

需支援單一結果或一組結果，結果分組是隨機但有意義的。

一個或多個連結指向診斷調查期間進行的任何成像的全部細節。一般情況下，這是由支援DICOM的儀器進行的成像，但這並不是必須的。一個完整的PACS viewer可以使用這些資訊來提供來源影像的視圖。

影像檢查（ImagingStudy）和影像（image）資料項目在某種程度上是重疊的—通常，影像（image）資料項目的影像參照清單也會在某個影像檢查（ImagingStudy） resource中找到。然而，每一種都迎合了不同類型的目的的顯示。兩者都不提供，或者兩者都提供。

與此報告相關的關鍵影像的清單。這些影像一般是在診斷過程中產生的，可以直接是病人的，也可以是經過處理的檢體（即感興趣的玻片）。

許多診斷服務包含將報告中的影像作為服務的一部份

resource中資料項目的唯一ID（用於內部參照）。這可以是任何不含空格的字串。

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

無論使用或定義擴充的機構或管轄區，任何應用程式、專案或標準使用擴充都不背負任何汙名（stigma）。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

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

無論使用或定義擴充的機構或管轄區，任何應用程式、專案或標準使用擴充都不背負任何汙名（stigma）。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

修飾用的資料項目擴充將不能安全地忽略的擴充與絕大多數可以安全地忽略的擴充明確區分開來。透過消除禁止實作者擴充存在的需求來促進可互通性。更多訊息，請參見修飾用的資料項目擴充之定義。

關於影像的意見，一般情況下，這是用來解釋為什麼影像被包括在內，或請瀏覽者注意重要特徵。

此意見應與影像一起顯示，報告中通常會在其他部分（如結論）對影像內容進行補充討論。

此報告的健康照護提供者應該對報告中每張影像做出意見

參照的影像來源

此診斷報告的簡要及臨床情境的摘要結論（解釋／臆斷）

需要能夠提供一個不會在基本結果資料中丟失結論

代表診斷報告的摘要結論（解釋／臆斷）的一個或多個代碼

診斷服務發佈之含豐富文字的整個結果，允許多種格式，但它們在語義上 必須（SHALL） 是相同的。

在這種情況下，「application／pdf 」被推薦為最可靠及最可互操作的格式。

讓實驗室有能力為臨床真實性提供自己的完全格式化報告

對病人、一群病人、設備和地點、和／或由這些所產生的檢體進行診斷測試的發現與解釋，報告包括臨床情境，如請求和服務提供者的資訊，以及一些混合的不可被中斷的一個或一系列結果、影像、文字和編碼的解釋，以及格式化的診斷報告。

這是為了捕捉單一的報告資訊，不適合用於顯示涵蓋多個報告的摘要資訊。例如：此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規範為每個人保留一個核心的簡易性。

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

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

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

由執行者或其他系統指定給該報告的業務用識別碼

此識別碼通常由診斷服務提供者的資訊系統指定

當從來源實驗室查詢此報告以及在FHIR情境之外連接到此報告時，需要知道在應使用什麼識別碼。

有關請求的服務的細節

注意：通常每個結果有一個檢驗服務請求，但是在某些情況下，多個檢驗服務請求可以用同一個檢驗結果resource來表示。請注意，也存在一個服務請求導致多個報告的情況。

允許追蹤報告的授權，並追蹤提案／建議是否被採納。

診斷報告的狀態

診斷報告狀態；應填入所綁定值集中的其中一個代碼

診斷服務通常會發布臨時／不完整的報告，有時候也會撤銷之前已發布的報告。

對建立報告的臨床科、部門或診斷服務進行分類的代碼（例如：心臟病學、生物化學、血液學、MRI）。主要為了搜尋、排序和顯示時使用。

允許使用各種分類方案的多個類別。精細度由值集中的類別概念來定義。可使用DiagnosticReport.code中的metadata和（或）專門術語層次結構進行更細微的過濾。

診斷報告分類；應填入所綁定值集值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

描述該診斷報告的代碼或名稱

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

鼓勵使用所綁定值集中的代碼，但不強制一定要使用此值集，你也可使用其他值集的代碼或單純以文字表示。

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

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

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

由專門術語系統（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列表，或者它應該參照一些明確建立的系统定義。

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

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

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

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

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

由專門術語系統（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) 知道對象的背景

此DiagnosticReport所涉及的健康照護事件（例如：病人和健康照護服務提供者的互動）。

這通常是事件發生的就醫，但有些事件可能是在就醫完成之前或之後開始，但仍與就醫的情境有關（如住院前的實驗室檢驗）。

將此服務請求連接就醫（Encounter）情境

觀察值與之相關的時間或時段。當報告的對象是病人時，這通常是處置的時間或檢體採集的時間，但往往不知道日期／時間的來源，只知道日期／時間本身。

如果對病人進行診斷處置，這就是進行該處置的時間。如果有檢體，可以從檢體採集時間得出診斷相關時間，但檢體資訊並不總是可用，而且檢體和診斷相關時間之間並不總是自動的確切關係。

需要知道在病歷的什麼地方儲存檔案／呈現此報告

這個版本的報告提供給健康照護提供者的日期和時間，通常是在報告被審查和核實之後。

可能與resource本身的更新時間不同，因為那是紀錄的狀態（可能是第二個副本），而不是發報告的實際時間。

臨床醫師需要確認報告的發布日期

負責發此報告的診斷服務

這不一定是一些混合的不可被中斷的一個或一系列資料項目的來源或解釋結果的實體，它是對臨床報告負責的實體。

如果對結果有疑問，需要知道應與誰聯絡；還可能需要追蹤次級資料分析的報告來源。

對報告的結論和解釋負責的健康照護服務提供者或組織

可能不是對臨床報告負責的同一個實體

如果對結果有疑問，需要知道應與誰聯絡；還可能需要追蹤次級資料分析的報告來源。

關於此診斷報告所依據的檢體的詳細資訊

如果在檢驗結果名稱中充分指明檢體的代碼，那麼此附加資料就可能是多餘的。如果有多個檢體，可在每個檢驗檢查或檢驗檢查套組中表示。

需要能夠報告已收集檢體之資訊，這些資訊是報告的基礎。

檢驗檢查為此診斷報告的一部分

Observations可包含檢驗檢查值

需支援單一結果或一組結果，結果分組是隨機但有意義的。

一個或多個連結指向診斷調查期間進行的任何成像的全部細節。一般情況下，這是由支援DICOM的儀器進行的成像，但這並不是必須的。一個完整的PACS viewer可以使用這些資訊來提供來源影像的視圖。

影像檢查（ImagingStudy）和影像（image）資料項目在某種程度上是重疊的—通常，影像（image）資料項目的影像參照清單也會在某個影像檢查（ImagingStudy） resource中找到。然而，每一種都迎合了不同類型的目的的顯示。兩者都不提供，或者兩者都提供。

與此報告相關的關鍵影像的清單。這些影像一般是在診斷過程中產生的，可以直接是病人的，也可以是經過處理的檢體（即感興趣的玻片）。

許多診斷服務包含將報告中的影像作為服務的一部份

resource中資料項目的唯一ID（用於內部參照）。這可以是任何不含空格的字串。

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

無論使用或定義擴充的機構或管轄區，任何應用程式、專案或標準使用擴充都不背負任何汙名（stigma）。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

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

無論使用或定義擴充的機構或管轄區，任何應用程式、專案或標準使用擴充都不背負任何汙名（stigma）。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

修飾用的資料項目擴充將不能安全地忽略的擴充與絕大多數可以安全地忽略的擴充明確區分開來。透過消除禁止實作者擴充存在的需求來促進可互通性。更多訊息，請參見修飾用的資料項目擴充之定義。

關於影像的意見，一般情況下，這是用來解釋為什麼影像被包括在內，或請瀏覽者注意重要特徵。

此意見應與影像一起顯示，報告中通常會在其他部分（如結論）對影像內容進行補充討論。

此報告的健康照護提供者應該對報告中每張影像做出意見

參照的影像來源

此診斷報告的簡要及臨床情境的摘要結論（解釋／臆斷）

需要能夠提供一個不會在基本結果資料中丟失結論

代表診斷報告的摘要結論（解釋／臆斷）的一個或多個代碼

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

診斷服務發佈之含豐富文字的整個結果，允許多種格式，但它們在語義上 必須（SHALL） 是相同的。

在這種情況下，「application／pdf 」被推薦為最可靠及最可互操作的格式。

讓實驗室有能力為臨床真實性提供自己的完全格式化報告

對病人、一群病人、設備和地點、和／或由這些所產生的檢體進行診斷測試的發現與解釋，報告包括臨床情境，如請求和服務提供者的資訊，以及一些混合的不可被中斷的一個或一系列結果、影像、文字和編碼的解釋，以及格式化的診斷報告。

這是為了捕捉單一的報告資訊，不適合用於顯示涵蓋多個報告的摘要資訊。例如：此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規範為每個人保留一個核心的簡易性。

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

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

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

由執行者或其他系統指定給該報告的業務用識別碼

此識別碼通常由診斷服務提供者的資訊系統指定

當從來源實驗室查詢此報告以及在FHIR情境之外連接到此報告時，需要知道在應使用什麼識別碼。

有關請求的服務的細節

注意：通常每個結果有一個檢驗服務請求，但是在某些情況下，多個檢驗服務請求可以用同一個檢驗結果resource來表示。請注意，也存在一個服務請求導致多個報告的情況。

允許追蹤報告的授權，並追蹤提案／建議是否被採納。

診斷報告的狀態

診斷報告狀態；應填入所綁定值集中的其中一個代碼

診斷服務通常會發布臨時／不完整的報告，有時候也會撤銷之前已發布的報告。

對建立報告的臨床科、部門或診斷服務進行分類的代碼（例如：心臟病學、生物化學、血液學、MRI）。主要為了搜尋、排序和顯示時使用。

允許使用各種分類方案的多個類別。精細度由值集中的類別概念來定義。可使用DiagnosticReport.code中的metadata和（或）專門術語層次結構進行更細微的過濾。

診斷報告分類；應填入所綁定值集值集中適合的代碼，確定無適合的代碼才可以使用其他值集的代碼來表示。

描述該診斷報告的代碼或名稱

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

鼓勵使用所綁定值集中的代碼，但不強制一定要使用此值集，你也可使用其他值集的代碼或單純以文字表示。

resource中資料項目的唯一ID（用於內部參照）。這可以是任何不含空格的字串。

擴充的資料項目

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

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

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

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

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

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

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

resource中資料項目的唯一ID（用於內部參照），這可以是任何不含空格的字串。

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

無論使用或定義擴充的機構或管轄區，任何應用程式、專案或標準使用擴充都不背負任何污名（stigma）。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

resource中資料項目的唯一ID（用於內部參照），這可以是任何不含空格的字串。

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

無論使用或定義擴充的機構或管轄區，任何應用程式、專案或標準使用擴充都不背負任何污名（stigma）。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

報告的對象體，通常但不總是病人。然而，診斷服務也對從其他各種來源收集的檢體進行分析。

必須(SHALL) 知道對象的背景

此DiagnosticReport所涉及的健康照護事件（例如：病人和健康照護服務提供者的互動）。

這通常是事件發生的就醫，但有些事件可能是在就醫完成之前或之後開始，但仍與就醫的情境有關（如住院前的實驗室檢驗）。

將此服務請求連接就醫（Encounter）情境

觀察值與之相關的時間或時段。當報告的對象是病人時，這通常是處置的時間或檢體採集的時間，但往往不知道日期／時間的來源，只知道日期／時間本身。

如果對病人進行診斷處置，這就是進行該處置的時間。如果有檢體，可以從檢體採集時間得出診斷相關時間，但檢體資訊並不總是可用，而且檢體和診斷相關時間之間並不總是自動的確切關係。

需要知道在病歷的什麼地方儲存檔案／呈現此報告

這個版本的報告提供給健康照護提供者的日期和時間，通常是在報告被審查和核實之後。

可能與resource本身的更新時間不同，因為那是紀錄的狀態（可能是第二個副本），而不是發報告的實際時間。

臨床醫師需要確認報告的發布日期

負責發此報告的診斷服務

這不一定是一些混合的不可被中斷的一個或一系列資料項目的來源或解釋結果的實體，它是對臨床報告負責的實體。

如果對結果有疑問，需要知道應與誰聯絡；還可能需要追蹤次級資料分析的報告來源。

對報告的結論和解釋負責的健康照護服務提供者或組織

可能不是對臨床報告負責的同一個實體

如果對結果有疑問，需要知道應與誰聯絡；還可能需要追蹤次級資料分析的報告來源。

關於此診斷報告所依據的檢體的詳細資訊

如果在檢驗結果名稱中充分指明檢體的代碼，那麼此附加資料就可能是多餘的。如果有多個檢體，可在每個檢驗檢查或檢驗檢查套組中表示。

需要能夠報告已收集檢體之資訊，這些資訊是報告的基礎。

檢驗檢查為此診斷報告的一部分

Observations可包含檢驗檢查值

需支援單一結果或一組結果，結果分組是隨機但有意義的。

一個或多個連結指向診斷調查期間進行的任何成像的全部細節。一般情況下，這是由支援DICOM的儀器進行的成像，但這並不是必須的。一個完整的PACS viewer可以使用這些資訊來提供來源影像的視圖。

影像檢查（ImagingStudy）和影像（image）資料項目在某種程度上是重疊的—通常，影像（image）資料項目的影像參照清單也會在某個影像檢查（ImagingStudy） resource中找到。然而，每一種都迎合了不同類型的目的的顯示。兩者都不提供，或者兩者都提供。

與此報告相關的關鍵影像的清單。這些影像一般是在診斷過程中產生的，可以直接是病人的，也可以是經過處理的檢體（即感興趣的玻片）。

許多診斷服務包含將報告中的影像作為服務的一部份

resource中資料項目的唯一ID（用於內部參照）。這可以是任何不含空格的字串。

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

無論使用或定義擴充的機構或管轄區，任何應用程式、專案或標準使用擴充都不背負任何汙名（stigma）。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

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

無論使用或定義擴充的機構或管轄區，任何應用程式、專案或標準使用擴充都不背負任何汙名（stigma）。使用擴充是允許FHIR規範為每個人保留一個核心的簡易性。

修飾用的資料項目擴充將不能安全地忽略的擴充與絕大多數可以安全地忽略的擴充明確區分開來。透過消除禁止實作者擴充存在的需求來促進可互通性。更多訊息，請參見修飾用的資料項目擴充之定義。

關於影像的意見，一般情況下，這是用來解釋為什麼影像被包括在內，或請瀏覽者注意重要特徵。

此意見應與影像一起顯示，報告中通常會在其他部分（如結論）對影像內容進行補充討論。

此報告的健康照護提供者應該對報告中每張影像做出意見

參照的影像來源

此診斷報告的簡要及臨床情境的摘要結論（解釋／臆斷）

需要能夠提供一個不會在基本結果資料中丟失結論

代表診斷報告的摘要結論（解釋／臆斷）的一個或多個代碼

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

診斷服務發佈之含豐富文字的整個結果，允許多種格式，但它們在語義上 必須（SHALL） 是相同的。

在這種情況下，「application／pdf 」被推薦為最可靠及最可互操作的格式。

讓實驗室有能力為臨床真實性提供自己的完全格式化報告