臨床編碼系統 - LOINC 1?

LOINC國內的專家很多。因為，自己的思維跟一些「專家」的思維不同，真不知該寫粗還是寫細。
寫粗，簡單。請參考LOINC官方網站 。這就結束了，一切自己研究。以前衛生署下還有一個LOINC與健保碼對應的網站，現在也不知跑去哪了。
寫細，很頭痛。我不是醫檢師，很多專業用語，我也搞不清楚。再來，若講資訊結構與應用，我講了我的想法，又跟現況應用不合，那我不又是誤人子弟了。

所以，看這篇之前，務必心理要有個底，以下言論純屬個人看法。


LOINC的全名是Logical Observation Identifiers Names and Codes。光是這個英文名稱就可以瞎掰好多好多。
Logical中文應該是翻譯成邏輯吧。靠，這個邏輯有什麼關係。那應該說他是一個可推論的東西，是的，根據他的定義與描述，你可以推論出唯一結果。健保碼可以嗎？我不知道耶。
Observation他是觀察所得。加上前面一個字，就可知道他用來對於我們觀察所得的推論。
Identifiers這個叫辨識碼。也就是具有可推論之觀察所得給給辨識碼。
Names and Codes也就是這個辨識碼包含了名稱與編碼。

所以，LOINC是針對醫療情境中，對於所有具有可推論性的觀察所得賦予一個具有名稱與編碼的辨識碼。反過來說，對於猜測性或不明確性的東西，對於LOINC來說，他是做不到的。

有了這個基本認知後，我們就要反過來看國內的檢驗部門的作為、檢驗系統的作法以及健保給付標準的模式，來看看中間的差異性。
.....
.....
.....
抱歉，這個議題不能討論。否則，又得罪一堆人。套用現在流行語，香蕉蘋果當然不能拿來一起比。

回主題。我們討論的是臨床編碼系統。

LOINC被定位為查詢碼。也就是說，每一個編碼的背後都是一組具有邏輯性，可被推論之屬性。透過這些定義，我們知道對方是要什麼資料，或者要我們作什麼事情。

而這一組屬性總共分成六個軸度。你可以想像，他就好像是達文西密碼中的拱心石藏密筒，總共有六組旋鈕，每組旋鈕各有自己的數字，當然，在LOINC中就不是數字，而是一個個獨立且單純之資料內容。
任意的一個組合，如果成功，那就表示在LOINC中有定義好編碼。如果失敗，那就表示在LOINC中沒有定義好編碼。（這就是要去看本地化的方式了）

接著就來好好聊聊LOINC是什麼。（一樣，只談結構，不談細節，我不是醫檢人員沒資格談）等談到電子病歷結構標準時，我們再來把兩者整合的部份在細談。

目前英文的使用手冊是2013年12月。
有一份中文簡體版的，可惜是2007年12月。不過，一些專有名詞的翻譯多少還是有幫助的。

臨床編碼系統 - ICD

之前簡單帶到ICD的說明。如果，真正想深入了解這個編碼，找我就不對了，請找專業團隊「台灣病歷資訊管理學會」。很感謝該團隊在當年制定電子病歷時鼎力相助。手邊有本ICD-9-CM 分類規則彙編，還是該學會送的。
這兒，僅是純粹打屁賺篇幅而已。

疾病分類(Disease classification)就如該書前言所描述：
   疾病分類是將患者之疾病診斷及處置相關訊息予以編碼並加以整合，藉以產生統計性分類(Statistical classfication)資料，以方便需要時之查詢或使用。

簡單的一段話就道盡ICD的精髓所在。

注意，此編碼的限定範圍是在疾病診斷及處置（手術）。開玩笑，人的身體到處都可能引發疾病。所以，他的編碼分類規則就會先從人體的器官或組織加以分類。
另外，「分類」就把他想像成從小一直背的界門綱目科屬種。依據疾病特性，一層一層歸類，越來越精確。
因目前有ICD-9與ICD-10的版本，兩者在編碼上不同。引用版本時要注意。

這是ICD-10的線上版：http://apps.who.int/classifications/icd10/browse/2010/en


一般而言（在紙本時代），醫師對於某些疾病的描述並不會「深入」，畢竟是人腦，要用嘴與病患交談，還要用手書寫病歷，的確不容易。醫院會有疾分師，會再依據醫師開的藥，或者治療計畫等，利用這些工具書認真地定義出這一次就診，應該屬於什麼疾病（什麼診斷）。
當然，人生病是不會照著教科書地，有些情況是很複雜。所以，一般都會有主診斷、次診斷的選擇。這些就是疾分師的專業了。
雖然，我們知道健保申報只是疾病分類的功能之一而已。但是...
如果要用紙本病歷來實踐臨床決策，說實在地，我們是期望醫生的大腦跟電腦一樣了。

但是，到了電子病歷時代呢？會有什麼樣的演變。

這是「事前」、「事後」還是「事中」的問題。（所有的臨床編碼都有這樣子的問題）
在紙本病歷時代是事後。先由醫師寫完病歷，在依據這些資料由疾分師給一個「更正確」的疾病分類碼。（可能是為了符合健保需求）

如果用一般HIS，其結果只是把醫師書寫在紙本的東西，改書寫在電腦上，對整個流程似乎沒有任何助益。當然，有人會說我把HIS改得很強。喔～那當然可以。對我而言，所有的應用於流程上來處理資料者都叫做MIS。不管是HIS、SIS、LIS、CIS，任何的S。

真的使用到電子病歷呢？說實在，完蛋了。因為，電子病歷只是最終結果。所以，你不可能要求電子病歷完成編碼作業。（天呀～我在說什麼）
對電子病歷而言，這些內容都是「事前」都要完成的事項。無論你是透過什麼S，或者正統的CPOE（Computerized Physician Order Entry）而來。也就是說需要一個全新的病歷輸入系統。

接著的問題是你這個新的輸入介面是否能夠讓醫師精確表達他的診斷（事中）。或者還是得再經過某個人，給予精確編碼。
至於「事前」！開玩笑，醫師又不是算命師。怎可預知這個人得了什麼病。

世界接軌 VS 鬼接介事

推動國際標準的主要目的就是與世界接軌。如果不遵守人家的遊戲規則，自己蒙著頭硬幹，那不就變成跟鬼接了。
其實，國際標準也不是那麼不通情理，大都有提供處理本地化的模式。只是不去研究所提供的方法，就直接說不適用於國內。說實在，我到現在還是很難接受。
就用這張圖來說明一下，實施本地化模式可能有哪幾種情境。注意，各種國際標準有其特殊用途與結構，所以本地化的模式不盡相同，這邊僅是探討思維邏輯，不探討實際方法。
這是SNOMED CT文件中的一張圖。

說要與世界接軌，其實可能方法有五種。

1. 直接引用法
2. 中文翻譯法
3. 新增中文法
4. 複製結構法
5. 創新設計法

直接引用法

• 這個最單純，直接拿來用即可。
• 可能會遇到某些國際標準需要付費，而政府或單位機構不肯花這個錢。
• Concept ID與Description等，都沿用。

直接翻譯法

• 這個方式最簡單，就是把人家的東西直接拿來，設計結構與方法不變，編碼內容不變。只是把描述性的資料由英文改成中文。
• 這個最大問題與病歷中文化是一樣的。翻譯完之後，說不一定醫生也看不懂了。
• 這有個好處，只要沒有授權問題，改中文不需要通知原創單位。
• Concept ID沿用。把Description等改成中文。

新增中文法

• 不修改原始資料。    
• 基於原創的結構方法，增加非得以中文表示之項目。
• 一切遵循原創的遊戲規則，為新增項目增訂編碼。
• Concept ID沿用，不足之處再提出申請。Description等除非新增Concept ID，否則沿用。

複製結構法

• 這個是不得已的作法。例如，要錢卻不買。
• 學習原創的結構與方法，自行編定編碼與中文描述方式。
• 這個有點麻煩，雖然使用的遊戲規則一樣，但是編碼不同，還是不能接軌。不過可以耍賤招，就是在自訂編碼的時候，順便做好與原創編碼的對應關係。要跟國際接時，再轉一次碼。
• Concept ID新增，Description等新增。

創新設計法

• 這招最厲害了。管他什麼國際標準，就是自己搞一套。愛怎麼用，就怎麼用。只要國內能接受就好。不能接受？靠政府力量，誰能不接受。
• 至於能不能與世界接軌，再說吧。
• 沒有Concept ID、Description等。

臨床編碼系統 - 如何取得SNOMED CT - 更新

既然提到了SNOMED CT也就順便教各位如何取得一套。

你只要有email原則上都可以使用。不過，我還是覺得有學校mail的比較好。畢竟這是要錢的東西，只是用在研究還OK。

首先到https://uts.nlm.nih.gov/home.html

然後點選右上角Sign up。

就接受吧。

 再接受吧。

 還是接受呀。（有機會再來談談他的計費模式）

 輸入註冊資料。

 順利填完資料後，會發一封mail給你。

 在信件中有一條URL，請複製後貼在瀏覽器開啟之。這樣子就完成第一階段。（請再等幾天吧，授權通過後，再來補資料）

更新：

經過一天的等待，你會收到另一封信。這封信你就得回覆，放心不用打任何英文。

回覆後，應該不用等一天的時間，你就會收到一封通知你審核通過的信件。

如果，你跟我一樣收到這封信件的話，恭喜你。
接著就是下載檔案了。

就用當初設定的帳號密碼登入。

選擇下載。至於International與US差異，我也不清楚。我選前者。

轉到這來，就有了下載連結。

接著就給他勇敢地點下去囉。

恭喜你，終於可以與我一起翱翔在真正電子病歷的世界裡。
（不過，我得很遺憾的地跟你說，你跟我學會的東西不保證能使用在台灣）

臨床編碼系統 - 差在哪裡

之前已經提到臨床編碼系統只是在降低認知的差異性。
非臨床類的編碼系統比較容易理解，他就是一個Lookup Table。主要用途是當作限制式使用。也就是說，你只能從這個範圍內選擇一個值來代表。一般可以選擇的項目不是很多。
就實作的角度而言，這些Lookup Table的內容，可以想像成是一個Dictionary。或者你想像成一個<Key, Value>結構的東西。
Key是給電腦用的。你可以視為欄位名稱。
Value是給人用的。你可以視為內容值。尤其是量測內容值。

非臨床類的Value常常只是Description。這部份還是留待講到CDA R2時，再來說明。
我們先來看看臨床類的編碼。
這邊要介紹常用的三種編碼ICD、LOINC、SNOMED CT（SNOMED本身涵蓋範圍很廣，加上CT是指限定在Clinical Terms上）。

我們就引用<Key, Value>的概念來說明。
（補充：其實，真正的說法應該是<Code, Value>）

• ICD是分類碼，他只有Key，沒有Value。Key就是Value。你只是透過某些具有階層意義的數字來讓概念越加明確精準。注意這個有版本問題。國內仍以ICD 9為主，國外則是ICD 10。版本之間結構差異頗大，但內容變化不大。
• LOINC是查詢碼/操作碼，他定義了Key，然後要補上Value。這個東西分事前與事後。事前比較像操作碼，用一個Key，來代表六種屬性規範（後續再細講），要求別人依據此規範去執行作業。事後就是查詢碼，依據六種屬性規範給定你想找的東西，然後取得一個Key，透過此Key到電子病歷中查詢。注意這個有版本問題。各版次間結構不變，只是項目內容修正。
• SNOMED是定義碼，他只有Key，有/沒有Value。他是把臨床上所有具有意義之名詞賦予一個Concept ID，以及[0..n]的Description ID。至於有或沒有值要看他是如何應用在電子病歷結構檔中。有時候，Key本身就是Value跟ICD很像。有時候，Key本身只是欄位，你要補上Value，他又跟LOINC很像。注意這個沒有版次的問題。但仍需下載新的資料庫。

給幾張圖簡單說明一下。後續在分別介紹這三個常用的臨床編碼系統。

ICD 10

這可以在Wiki取得。

 若選腫瘤群組，則到下一層，會有更多精確定義的腫瘤。注意，Key的內容是Append。

這是線上查詢系統：

LOINC

這個是下載LOINC後所提供的軟體，叫做RELMA，他是提供你現有系統的編碼與LOINC對應之用。你可輸入一些關鍵字，然後列出符合之項目。在經由六個屬性軸，來決定哪一個Key才是符合現在情境所需。

SNOMED CT

這是當你擁有SNOMED版權時，你可以下載一套CliniClue，可提供你查詢管理之用。

圖中是查詢一個asthma（氣喘）。因為是設定Starts with，系統列出所有以asthma開頭之編碼描述。點選後，則展開此編碼之結構（跟ICD概念類似），你就可以找到唯一的Conception ID。然後在右手邊會出現不同來源之Description ID。下方就是電子病歷的重點「關聯」，這個要跟CDA R2整合在一起就可以發揮驚人的效果。

找到asthma，可以有嚴重度與發病頻率的關聯，分別在此關聯下，又可以有哪些限定範圍之Conception ID。

後記：

1. SNOMED就是為了電子病歷而設計的。若不用，真不知我們的電子病歷有什麼資格叫電子病歷。當然，也可以不用呀，台灣可以自己定一套呀。這就看政府要不要砸錢呀，定完後看哪一國會聽你的。然後再跟鬼接界世。
2. 一份真正的電子病歷，就是一個最原始的病歷檔。用在臨床決策支援系統，就能發揮其效益。懂得使用電子病歷的臨床決策支援系統，其設計模式又是另一們學問。
3. 目前國內一堆跟臨床有關的研究，其資料來源是健保資料庫。而我們都知道，醫院為了健保申報最佳化，申報資料都是有微調的可能。基於不能完全信賴的資料源所做出來的研究，實在難以說服我。（喔～又夜郎自大了，能說服審查委員就好）。
4. 多年前就建議申報若能以最原始的資料，也就是電子病歷，這樣子醫院也不需要大費周章的搞申報紀錄檔，連後續的複核交付紙本的作業都省了。這個當然不可能實踐，健保局不願意，醫院更不會同意。Dead lock。

臨床編碼系統 - 起承轉合

講完OID，其實根本就不算是臨床編碼系統的範圍，那個叫做common sense，叫做基礎知識。只是，我們不重視基礎知識，也就亂搞一通了。

（哈！得踩煞車）

假設，大家有了這個OID的基礎知識後，接著要問的是那臨床編碼系統是要怎麼用呢？

到這邊，又要拉出好幾條線出來。你要問我，哪個先，那個後，那個要先講，哪個要後講，坦白說，我真的不知道。

因為，這是我十多年來的知識累積，他是一個相互依存，相互發展的東西。很多文件我看完了，不久就作廢了。當我在看到另一份文件時，裡面就有可能包含之前被廢棄文件的知識在裡面。所以，你要叫我告訴你當初的知識怎麼來，我還真的無法告訴你。我不是學者，我沒有那麼多的時間去整理。在追求HL7 v3知識的過程中，我只能不斷地往前衝。而且，我英文程度不好，對一個英文是被體育老師教的人來說，真的是一段苦日子。

（哈！又得踩煞車）

簡單地分類吧：

1. 臨床編碼系統本身

2. 臨床編碼系統應用

臨床編碼系統本身

臨床編碼系統的總類非常多。又可以簡易區分成臨床類與非臨床類。

• 臨床類

常見的有LOINC，ICD，SNOMED CT等，當然不只這些，還有藥品的部份等。國內不常用（可以不用），所以就省略不予介紹。況且，每一個臨床編碼系統都是一門高深學問，這也是另一個在學習過程中，痛苦的事情。總不能教我再去唸一個醫學系吧。後續我也僅能簡單介紹其概念而已。

• 非臨床類

這個類型的更多，多到讓你抓狂。如果硬要分，有一種分法，就是行政類、控制類、統計類等，不過實在很難區分。另外一種分法，就是來源了，例如是來自HL7 v2、HL7 v3、某特定單位等。

臨床編碼系統應用

講到應用那更是千頭萬緒。例如，在HL7 v2的時候怎麼用，在HL7 v3的時候怎麼用，在CDA R2的時候怎麼用。上述不同的情境下，用法還是有點差異的。

到這邊就有點討厭了。先講臨床編碼系統本身吧，就算我講的很白話，你還是聽不懂的。因為，那就是一堆碼再加上他的描述，你不是專業的從業人員，真不知你要懂那麼細幹嘛。

先講臨床編碼系統應用吧，那我又得從資料型態開始講起，你才知道碼與描述要怎麼擺放。然後，這個資料型態又要怎麼應用在標準區段裡面。問題是，光講一個資料型態你還是搞不懂，得講完一些常用的資料型態才夠。而且，v2與v3的資料型態又不一樣，就算講完，你還是不知道要怎麼用的。（常常要我3小時內講完CDA R2，哈～真的很困難啦）

我想，能夠讓人看懂下面這張圖，也許就是功德一件了（哈～說不一定是害人匪淺）。

臨床編碼系統 - 編碼的編碼 - 3

看了國外OID管理，可別說這是人家特有的東西。既然挾持了人家，若不好好用，不是太浪費了嗎。

國內OID的管理網站在這兒：http://oid.nat.gov.tw/OIDWeb/chmain.html

從這張圖應該可以理解到，凡申請到節點者，需管理自己的子節點。台灣就算是搶來2.16.886，也是要好好管理的。

國內許多醫療院所都是財團法人，所以，都會是2.16.886.104起頭。為什麼是104，那你要去問當初負責管理的人。

我們就來查長庚醫院吧。長庚是2.16.886.104.100565。至於長庚醫療財團法人要怎麼繼續使用下去，那就是長庚自己的事了。

注意，台大醫院可不是財團法人唷，要從這找，是找不到的。而且，臺灣大學是公家機關，為了搞電子公文，他們可是很認真地在使用OID唷。（哈～這才是台灣推OID的原本目的吧）

學校：2.16.886.111

國立臺灣大學：2.16.886.111.100000

國立臺灣大學醫學院附設醫院：2.16.886.111.100000.100000

國立臺灣大學醫學院附設醫院北護分院：2.16.886.111.100000.100000.100001

現在應該知道樹狀結構的意義了吧。

只可惜，台灣只用在電子公文上，所以，只針對組織單位加以編碼，這就辜負了Object這個字眼。HL7不就是用在編碼系統嗎？事實上，他可以代表任何東西，資訊系統也可以，資訊系統下的功能也可以，運用乃存乎一心。

那HL7 Taiwan呢？當然有囉。

他是社團法人，所以是2.16.886.103。那子節點呢？沒有！！

當初我才「     」（原本要打開始，但是實際上我才把編碼規則定好，定義了幾個而已，所以只能打門，後來也沒機會做了，這下子連個門都沒有了，只好留空白）訂了一些。哈～也只有我自己知道而已。相關文件，也就深埋在我的備份硬碟裡。
雖然，期盼有一天能浮出水面，但...這一切又豈是我能強求的呢。

CDA R2與DICOM整合之模式 - 2

用手機上網，速度很慢。檔案太大發佈不了，只好提供檔案下載了。

CDA R2與DICOM整合之模式 - 1

這篇文章2009年寫的。當時是寫給衛生署（今衛服部）資訊中心主任看的。還記得當時，很多人反對。至於現在是怎麼作，我也不知道。只是剛剛在翻找舊檔案，突然看到這篇就貼過來給大家參考。
==========

1       目的

DICOM針對非影像資訊訂定了DICOM SR(Structure Report)，寄望處理醫學影像報告。但在實務上，一份電子病歷的來源，並非僅有單純的DICOM資料，也有可能來自檢驗資訊系統的檢驗報告。若醫院要推動全面無片化、無紙化的目標，結果在報告部分卻需維護不同的格式，對整體發展上會造成困擾。

環顧世界各國，許多國家已經採用CDA R2作為電子病歷的基礎標準。因此，對於DICOM SR與CDA R2的整合，就變得很重要了。所幸，這方面的問題也被解決了。

將DICOM SR(Structure Report)轉換成HL7 CDA R2的表達方式，其主要目的就是讓影像資訊能以如檢驗報告方式來攜帶，使得影像資訊系統與臨床資訊系統得以交換資訊。圖 1之架構模式，經由這樣的轉碼機制，能確保任何臨床資訊系統或者是電子病歷系統都能夠順利的讀取醫學影像報告。

圖 1：影像報告之產生與轉譯

2       DICOM SR文件結構

DICOM SR文件主要分檔頭與本文兩大部分，請參考圖 2。檔頭所包含的資訊有病患、一般檢驗等。表 1所列為檔頭所涵蓋的物件模組內容以及原版文件參考目錄。

圖 2：DICOM SR文件結構

2.1      檔頭說明

DICOM SR檔頭所包含的模組有Patient Module、Specimen Identification Module、Clinical Trial Subject Module、General Study Module、Patient Study Module、Clinical Trial Study Module、SR Document Series Module、Clinical Trial Series Module、General Equipment Module、SR Document General Module、SR Document Content Module、SOP Common Module等數項。

• Patient Module：定義與此次診斷檢查有關的病患資料。其內容是與本次影像解釋的診斷所需欄位與一般性的欄位。
• Specimen Identification Module：用來規範的欄位是用來定義檢體之用。
• Clinical Trial Subject Module：所涵蓋的欄位是用來定義當病患被當作臨床試驗主體時。
• General Study Module：所規範的欄位是用來描述與定義此病患執行測試之結果。
• Patient Study Module：所定義的欄位是提供關於在某次執行測試結果之資訊。
• Clinical Trial Study Module：包含的屬性是定義於某次臨床試驗的測試內容。
• SR Document Series Module：定義SR文件序列的屬性。
• Clinical Trial Series Module：所包含的屬性是用來定義臨床試驗序列之內容。
• General Equipment Module：所規範的欄位是用來定義與描述設備產生系列內容的片段資訊。
• SR Document General Module：用來定義SR文件案例的一般性屬性。此些屬性定義了SR文件並提供整份文件內容。
• SR Document Content Module：用以傳遞SR文件容的屬性。
• SOP Common Module：此模組的屬性是用以規範根內容項目與其內容樹。

表 1：DICOM SR檔頭規範

IE	Module	Reference	Usage
Patient	Patient	C.7.1.1	M
	Specimen Identification	C.7.1.2	C - Required if the Observation Subject is a Specimen
	Clinical Trial Subject	C.7.1.3	U
Study	General Study	C.7.2.1	M
	Patient Study	C.7.2.2	U
	Clinical Trial Study	C.7.2.3	U
Series	SR Document Series	C.17.1	M
	Clinical Trial Series	C.7.3.2	U
Equipment	General Equipment	C.7.5.1	M
Document	SR Document General	C.17.2	M
	SR Document Content	C.17.3	M
	SOP Common	C.12.1	M

2.2      本文說明

圖 3是DICOM SR的BODY結構的範本。每一部分規範所需攜帶的資料內容。

圖 3：DICOM SR的BODY範本

3       DICOM SR與CDA R2之轉碼

HL7於2007年7月8日第一次釋出【Implementation Guide for CDA Release 2 – Diagnostic Imaging Report】進行投票；2008年9月進行第二次投票。詳細的轉碼內容，請參考<附件>。

簡略的對應原則，請參考表 2。

表 2：CDA R2與DICOM SR對應原則

SR Header (SR Document General Module)	SR Template	CDA Attribute
Verifying Observer Name (0040,A075) of Verifying Observer Sequence (0040,A073)	n.a.	/ClinicalDocument/legalAuthenticator/ AssignedEntity/Person/name
Verifying Organization (0040,A027) of Verifying Observer Sequence (0040,A073)	n.a.	/ClinicalDocument/legalAuthenticator/ AssignedEntity/Organization/name
Verification DateTime (0040,A030) of Verifying Observer Sequence (0040,A073)	n.a.	/ClinicalDocument/legalAuthenticator/time
Verifying Observer Identification Code Sequence (0040,A088) of Verifying Observer Sequence (0040,A073)	n.a.	/ClinicalDocument/legalAuthenticator/AssignedEntity/id and /ClinicalDocument/legalAuthenticator/AssignedEntity/code
Content Date (0008,0023), Content Time (0008,0033)	n.a.	/author/time
Person Name (0040,A123) of Author Observer Sequence (0040,A078)	Person Observer Name (TID 1003)	/author/AssignedAuthor/Person/name
Content Date (0008,0023), Content Time (0008,0033)	n.a.	/author/time
n.a.	Device Observer UID [HK1]  (TID 1004)	/author/AssignedAuthor/id
Study Instance UID ((0020,000D)	n.a.	/ServiceEvent/id
Requested Procedure ID (0040,1001) of the Referenced Request Sequence (0040,A370)	n.a.	/ServiceEvent/id
Placer Order Number/Imaging Service Request (0040,2016)	Procedure HL7 Placer Number of Evidence (TID 1005)	/Order/id
Filler Order Number/Imaging Service Request (0040,2017)	Procedure HL7 Filler Number of Evidence (TID 1005)	/Order/id
Accession Number (0008,0050)	Procedure Accession Number (TID 1005)	/Order/id
Procedure Code Sequence (0008,1032)	Procedure Code (TID 1005)	/ServiceEvent/code
Procedure Code Sequence (0008,1032)	Procedure Code (TID 1005)	/Act/code xor /Procedure/code
Patient ID (0010,0020)	Subject ID (Template 1007)	/recordTarget/PatientRole/id
Patient’s Name (0010,0010)	Subject Name (Template 1007)	/recordTarget/PatientRole/Patient/name
Patient’s Sex (0010,0040)	Subject Sex ID (Template 1007)	/recordTarget/PatientRole/Patient/ administrativeGenderCode
Patient’s Birth Date (0010,0030)	Subject Birth Date (Template 1007)	/recordTarget/PatientRole/Patient/ birthTime
n.a.	Subject ID xor Fetus ID (Template 1008)	/subject/relatedSubject/SubjectPerson/name
n.a.	Basic Diagnostic Imaging Report Document Titles (TID 2000)	/ClinicalDocument/code
Content Date (0008,0023) and Content Time ((0008,0033)	n.a.	/ClinicalDocument/effectiveTime
SOP Instance UID (0008,0018)	n.a.	/relatedDocument/ParentDocument/id
n.a.	Basic Diagnostic Imaging Report Document Titles (TID 2000)	/relatedDocument/ParentDocument/code