2.A.33 HD - hierarchic designator

欄位清單

整體說明

• 此資料型態相當重要。
• 無論是資訊系統或者者交換情境中，對每個已存在的instance（有人翻案例、個體或實體，我覺得應該是實體）都想要給他一個編號/流水號來當作辨識之用。此編號/流水號應誰控制管理呢？這總得跟別人說清楚。
• 注意，以我個人經驗，很多人會把這個與ID, IS, CNE, CWE這幾個資料型態給搞混了。這幾個好像也是有人單位負責制定一堆的編碼。但是，這些所制定的編碼會被重複使用在很多地方。
• HD所制定的編碼卻有唯一值的意義。
• 此辨識編碼是唯一值，那要如何確保呢？尤其是在一個交換情境中，剛好有兩家以上醫院把辨識編碼以流水號方式產生唯一性，這樣難免會有錯誤發生。
• 所以，要知道這個編碼是「誰」編的，而這個「誰」不會只產出一種辨識編碼系統。這個「誰」要怎麼用統一的方式去定義他而不會產生誤解呢？
• HD這個資料型態就是很單純的提供「誰」的「辨識編碼系統」。（不是指那個編碼/流水號唷）。注意從「辨識編碼系統」就可以知道是「誰」；也就是說，真正的「誰」，其實是指那個「辨識編碼系統」。
• 例如說，每家醫院都會有自己的病歷號編碼，這個病歷號從資訊角度而言，當然會保持唯一性，這個叫做「本地唯一性」。但從交換的角度，在院內是唯一，但送到院外就不一定是「全域唯一性」了。
• 所以，病歷號就是一個「辨識編碼系統」，那這家醫院就是那個「誰」。而這家醫院的員工編號也是另一個「辨識編碼系統」呀， 當然這個「誰」就還此再細分一下，才能知道是兩個不同的「辨識編碼系統。

相容性說明

欄位說明

• HD.1 (ID, O, 0300)
  • 透過使User-defined Table 0300 - Namespace ID 這個參照表來規定命名空間。
  • 這個參照表HL7並沒有提供任何建議值。
  • 不過，講到這，可能要補充一下，所有IS使用者定義參照表，注意，這個使用者不是最終使用者去定義的。而是編寫實作指引書的團隊，經過標準審查會議後所公告的內容。
  • 如果採用OID+次層的表達模式，這個欄位就不需要用到了。
• HD.2 (ST, C)
  • 辨識編碼系統所代表的編碼就放在這兒。
  • 要配合HD.3一同來解釋。
  • 我想很多人一定會搞混了，尤其是配合HD.3時會怎麼演變。假設我們規定全國醫療院所的病歷號在交換時所採行的辨識編碼系統是採自定方式，那HD.3 = L。並且規定是使用各自的醫療機構代碼，那HD.2 = 1234567890 (醫院的機構代碼長度10碼)。
  • 如果我們規定採用ISO的OID模式時，HD.3 = ISO。而HD.2 = 2.16.886.100.10000.10000（假設這家醫院的OID碼是如此，要查詢的話請至goid吧。）
  • 如果HD.3 = URI，那HD.2就有可能是：ftp://www.saintelsewhere.org。
  • 這時候有個問題了，剛剛不是說，不一定只有病歷號這個辨識編碼系統吧，光是醫院的OID怎麼夠呢？如果你有體驗到這點，恭喜你，慢慢進入狀況了。原則上醫院所分配的節點之下，就要由醫院自行管理了。所以，你可以直接用醫院OID在家下一層的方式來代表這個辨識編碼系統，否則，你就得使用一個公用的管理表格來定義，這就是HD.1的使用目的。

• HD.3 (ID, C, 0301)

  • 這是註記說這個辨識編碼系統是用什麼標準方式呈現。使用HL7 Table 0301 - Universal ID type來規範。他的幾個重要編碼值如下：

    • DNS：表示我現在提供的是網域名稱啦。
    • GUID：我現在提供的辨識系統是採GUID的編碼方式。
    • HL7：這是保留給未來HL7 Schema用。這要留到實作指引書的部份。
    • ISO：採ISO提供的辨識方式。這就是OID啦。
    • L, M, N：這個辨識編碼系統是自定的啦。
    • URI：採URI的辨識方式。
    • x500：採X.500的名稱目錄。

範例

|^2.16.840.1.113883.19^ISO|
|^478A0114-EBF0-7701-A023-6841FF05731A^UUID|
|^falcon.iupui.edu^DNS|
|LAB1^2.16.840.1.113883.19.1.2.3.3.4.6.7^ISO|