HL7 v2.6學習心得–第二章 訊息的應用與追蹤

我們一路走來學會一些HL7的專有名詞，感覺上還是很空洞。畢竟還是要能用才行呀。只是「要能用」有兩個階段。「標準設計階段」與「標準實作階段」

• 標準設計階段：是從應用流程情境著手，也就是說「為什麼要病歷交換」。當然，決定不要，那就什麼都不用做下去了。如果決定要，那就先把交換目的、參與者、訊息流程搞清楚。有了訊息流程，我們就可以來參考既有的標準中所公告的驅動事件中是否有符合的。有符合就直接拿來用，沒有符合就得走入自定訊息的範疇。選定要用哪個訊息之後，就是完成了動態階段。接著就依據這個驅動事件所見的區段欄位進行「標準實作指引書」的編寫。完成後，就交付給系統開發人員，進入了標準實作階段。
• 標準實作階段：是從資料來源與程式寫作的角度來著手。實作者被要求參考某特定應用情境的「標準實作指引書」，然後觀察訊息要求的欄位內容與資料型態後，進而思考，這些被要求的內容，要從哪裡生出來（資料來源）。生不出來的，就要去決定處理模式。緊接著就是決定要用什麼方式實作囉。如果訊息很簡單的話，直接寫程式，頂多採用一些HL7 API來方便發展。如果發現訊息結構與資料來源很複雜，甚至覺得後續還會有擴充，那建議就去找一個SOA的平台來處理這塊。每家的產品個有其優缺點，這個都需要依據自身條件仔細評估。

細講這些內容前，我覺得還是要把整個HL7的訊息結構跑一遍，讓感覺更踏實一點比較好。如果你有購買原版的光碟片，或者是某協會的會員，你可以下載的HL7標準書的壓縮檔，解壓縮之後，會有這麼多檔案。

目前我們只有開啟過第一章、第二章與第二.A章。而且第一章沒細看，後面兩章沒看完。後面還這麼多章，算了，放棄了。哈～別讓我傷心難過。搞定第二章，就天下太平了啦。假設我們已經搞定了第二章，我們就可以挑一個應用情境，選擇我們要使用的驅動事件，就可以決定區段欄位，接著就可以來實作訊息，寫程式了。我先講這篇的目的，是怕大家陷入第二章無聊、乏味的資料內容裡，最後紛紛掛冠求去，最後又是落的我一人自言自語了（哈～現在就是在自言自語呀）

假設今天有一個情境，就是甲病人在B醫院就診，而B醫院的醫師需要調閱甲病人在A醫院的出院病歷摘要做參考。當然B醫院的醫師，在甲病人的授權下，透過HL7訊息（是哪一個？）來向A醫院索取。B醫院接收到訊息後，如果A醫院要求的是enhance model，那B醫院就趕快發個訊息（ACK）給對方說我收到了。A醫院這邊的系統就都一個訊息給診間的醫師說，對方已收到訊息，處理中。當然，也有一種情境，A醫院直接回應說因當時病人並未授權將此資料轉給其他醫療院所，所以拒絕提供。這個就像是你辦金融卡的時候，她會問你要不要跨行，如果你當初勾不跨行，當然就不可以跨行，這個是在一開始時病人要自行評估的事情。（怎麼，現在變成強迫病人了呢）

A醫院基於B醫院所的訊息要求，處理後（如果病人當初沒有簽同意書，就拒絕囉）將此病患的出院病歷摘要調出來了（拜託這時候才是CDA R2的檔案，而且簽不簽章根本不重要）然後附在HL7訊息中回給了B醫院（為什麼知道要回給B醫院？唉唷，是回當初的訊息啦，當初的訊息是指向B醫院，所以，誰跟我調重不重要，不重要，重點是要不要回應這個訊息）。B醫院收到訊息後，就回給A醫院說收到了。A醫院端就把這次的訊息交換轉到Log去，一切都結束了。B醫院就發個通知給診間的醫師說，所調閱的病歷收到了。醫師當然可以經由這個通知直接開取，或到某個功能表中（外部參考文件，因為有可能同時向多家醫院調閱）讀取文件。

好，到底是哪一個訊息呢？是第9章 Medical Records / Information Management的範疇嗎？喔，這章是用在文件有新文件之通知，或文件增修，取消等通知。那是第11章嗎？第11章是講轉診/轉檢，好像勉強可以，可是，你會發現到這個只能用於單一目的的調閱文件，我不能夠在訊息中指定一些條件，來規範我所需要調閱的病歷文件。想想應該是是第5章Query比較好。

你說怎麼會知道，唉唷～你不研究怎麼會知道。我有研究的人，卻被要求閉嘴。那好吧，我用寫的總可以吧。

打開第5章一看，要看什麼？不用一字一字看啦，除非你對Query要深入研究。我大概只會先看目錄，查看trigger event有沒有感覺可以用的。

注意第5.4.4有個好玩的東西QSB create subscription，哈～HL7訊息也可以訂閱制。例如說，LIS就是定期要發報告到HIS，就可以用這種訊息。

那我們要用哪一個呢？原則上就是前面三個，但是要決定是哪一個時又得先知道這三個回應模式的區別。

• Segment：傳統的作法，就是把資料又區段來攜帶。
• Tabular：資料用表格化方式回應。
• Display：資料直接已列印格式，或人可讀的格式回應。

那是用哪一個呢？我沒有答案耶，要先問你的病歷交換情境是什麼？已剛剛舉的例子而言，我就要問B醫院你在不在意所拿到的出院病歷摘要一定要當時的，還是你可以接受由A醫院整理後最新的資料給你。如果是這樣子那就採QBP/RDY，因為你也只是看看資料就好，你又沒有要保存那份資料。但是，B醫院就是很在意的話，那你就得要求對方以夾帶文件的方式回應，那就是用到QBP/RSP這著驅動事件了呀。

相對地A醫院也有自己的作業模式吧。所以，到底是哪一種，要大家來討論囉。但是我知道，起碼不是現在的作法。那現在的作法對不對呢？只要大老們說對，那就是對了。

HL7 v2.6學習心得–第二.A章 Data Types–3(primitive data type)

上一篇提到的分類方式，其實也不怎麼正確。性質相同的放再一起講，當然會節省時間。只可惜醫療是這麼地複雜，許多資料型態其實是跨領域的。再來，HL7的資料型態一直有個關鍵問題，就是「資料型態的資料型態還是資料型態」，這個在v3.0也是一樣。

「資料型態的資料型態還是資料型態」一定要設「停損點」吧，否則會無窮迴圈下去。所幸在v 2.x會收斂，到了v 3.0還真會無窮迴圈下去。那2.x版的「停損點」到底是什麼呢？說穿了就是有些資料型態是最基礎的資料型態。

這麼講可能不好懂，如果你有Java或其他物件導向程式語言的背景，那就比較容易懂了。資料型態其實有分成兩種，其中一種是Primitive，例如說byte、int、float、double等。當一個變數宣告成這類型的資料型態時，除了有記憶體指向之外，還留有記憶體空間。簡單地說，就是可以直接指派符合其資料型態之內容值了。不同程式語言其Primitive Data Type的定義並不一定相同。

另外一種資料型態叫Reference，其實就是這個變數宣告成某一個物件。這個物件當然會有欄位，欄位又會有自己的資料型態。要一直碰到屬於Primitive的資料型態時，就可以放心指派內容值的。否則就一直要用點文法來遊歷了。

另外，還有一個觀念，除了有int整數型態之外，在java還會提供一個類別叫Integer，他是整數類別，他的目標是讓你更方便處理整數。當然，你可以透過這個類別來取得真正的整數值。

可惜，HL7 的Data Type全部都是Reference Data Type。因為HL7不牽涉到實作面呀，他不會限定你只能用java還是C#或其他語言呀。所以，他根本不會給你Primitive的定義。那都不能放內容值，那要怎麼實作呀。其實就是有一些「停損點」的資料型態，他可以讓你自己跟你所採用的程式語言的Primitive Data Type作對應。這樣不就結了嘛。這也是HL7相關API要去處理的事情。

接著我們就要來觀察，到底哪幾個資料型態具有「停損點」的功能。哈～其實就是從程式語言常用的Primitive 倒推回去囉。當然，其中一個String是比較麻煩。有些程式語言認為是類別，但是有些程式語言已經幫你做處理而當作Primitive了。或者是說，這個資料型態已經沒有定義欄位者，也可以算是了。

其他的資料型態，幾乎是基於這些所衍生的。

時間類

• DT – Date

最大資料長度是8，其格式為YYYY[MM[DD]]。[]表示可選。YYYY是指四碼長度的西元年，MM是數字的月，DD是數字的日。|20110101|與|201110|都是合法的。

• TM – time

最大資料長度是16，其格式為HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ]。HH：時、MM：分、SS：秒、.SSSS是：微秒、+/-ZZZZ：時區。

• DTM - date/time

最大資料長度是24，其格式為YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]。就是前面兩種資料型態之合體。

數值類

• NM – numeric

最大資料長度是16（這個沒有多大意義）。反正又是一個可以帶正負號且可以有小數點的字串。哈～我這可不是誇張說法。注意，我一開始再聊時就說，其實HL7就是一個大字串。前面那些日期類的資料型態，看似數字，其實全部看成字串就對了啦。

字串類

這個應該可不用多講，就當作複習囉。

• ST - string data

就是放一些長度不超過999的字串。

• TX - text data

如果字串比較長的，那就用這個資料型態囉。

• FT - formatted text data

如果字串內想要有點排版的樣式，那就是用這個囉。

編碼類

• ID - coded value for HL7 defined tables

這個解講過囉。就是帶一組由HL7所定義的參照表編號。

• IS - coded value for user-defined tables

與前者類似，只不過這邊攜帶的是使用者定義的參照表編號。注意，不是參考表編號是使用者制訂，而是這種類型的參照表會有哪些內容值，可由使用者自行定義。

• SI - sequence ID

長度是4，這個專門用來定義流水號編碼。他是一個非負整數。也就是0～9999。

其實，有了以上這幾個資料型態作基礎後，其他的資料型態就會比較好理解。真的嗎？哈～那要看認真程度啦。因為後續的資料型態都會有特定用途與目的，如果對於所要解決的問題不是清楚的話，會完全搞不懂幹嘛要多這個資料型態。屆時，你只會一直罵無聊而已。

HL7 v2.6學習心得–第二.A章 Data Types–2

原文參考：2.15 Data Types與2.A Data Types

==============================

整理了89個資料型態並加以分類。不過，沒有分的很好，可能還需要再邊讀邊修邊改了（因為，其他類居然是最多的）。這邊應該設定成索引篇，往後會基於此篇跳接至後面有詳細內容之篇幅去。

1. 文字類(4)

• 24 ED encapsulated data
• 31 FT formatted text data
• 74 ST string data
• 78 TX text data

2. 編碼類(16)

• 3 CCD charge code and date
• 6 CE coded element
• 7 CF coded element with formatted values
• 8 CNE coded with no exceptions
• 13 CWE coded with exceptions
• 35 ID coded values for HL7 defined tables
• 36 IS coded values for user-defined tables
• 37 JCC job code/class
• 44 MSG message type
• 49 OCD occurrence code and date
• 51 OSP occurrence span code and date
• 58 PTA policy type and amount
• 68 SCV scheduling class value pair
• 69 SI sequence ID
• 79 UVC UB value code and amount
• 81 VID version identifier

3. 統計類(11)

• 1 AD address
• 30 FN family name
• 46 NDL name with date and location
• 53 PL person location
• 55 PPN performing person time stamp
• 67 SAD street address
• 85 XAD extended address
• 86 XCN extended composite ID number and name for name for persons
• 87 XON extended composite name and identification number for organizations
• 88 XPN extended person name
• 89 XTN extended telecommunication number

4. 辨識類(9)

• 2 AUI authorization information
• 9 CNN composite ID number and name simplified
• 14 CX extended compsite ID with check digit
• 18 DLN driver
• 25 EI entity identifier
• 26 EIP entity identifier pair
• 33 HD hierarchic designator
• 54 PLN practitioner license or other Id number
• 65 RP reference pointer

5. 數值類(11)

• 10 CP composite price
• 11 CQ composite quanlity with units
• 40 MA multiplexed array
• 41 MO money
• 42 MOC money and chaege code
• 43 MOP money or percentage
• 45 NA numeric array
• 47 NM numeric
• 48 NR numeric range
• 70 SN structured numeric
• 82 VR value range

6. 時間類(8)

• 20 DR date/time range
• 21 DT date
• 22 DTM date/time
• 23 DTN day type and number
• 32 GTS general timing specification
• 75 TM time
• 76 TQ timing quantity
• 77 TS time stamp

7. 臨床類(11)

• 4 CCP channel calibration parameters
• 5 CD channel definition
• 12 CSU channel sensitivity and units
• 17 DLD discharge to location and date
• 19 DLT delta
• 50 OSD order sequence definition
• 56 PRL parent result link
• 72 SPS specimen source
• 80 VH visiting hours
• 83 WVI channel identifier
• 84 WVS waveform source

8. 其他類(19)

• 15 DDI daily deductible information
• 16 DIN date and institution name
• 27 ELD error location and description
• 28 ERL error location
• 29 FC finacial class
• 34 ICD insurance certification definition
• 38 LA1 location with address variation 1
• 39 LA2 location with address variation 2
• 52 PIP practitioner institutional privileges
• 57 PT proecssing type
• 59 QIP auery input parameter list
• 60 QSC query selection criteria
• 61 RCD row column definition
• 62 RFR refernce range
• 63 RI repeat interval
• 64 RMC room coverage
• 66 RPT repeat pattern
• 71 SPD specialty description
• 73 SRT sort order

HL7 v2.6學習心得 第二.A章 Data Types - 1

原文參考：2.15 Data Types與2.A Data Types

=============================

上一篇提到了三個資料型態，TX、FT與CF。談談資料型態的時間也應該到了。

資料型態很簡單懂，但很煩。學會一個結構，基本上都是差不多，但是2.6的資料型態共計有89個。逐一講解是很累人的事，不過，真的要搞懂HL7，還真的要每一個都去瞧瞧。反倒是每一章的訊息結構不用那麼急去瞭解，這可以等到碰到問題時再去看都來得及。

我也只能先試著寫看看，如果可以就全部給他翻一遍。等等，這個翻不是翻譯的意思唷，是瀏覽的意思。標準文件翻譯的工作是HL7 taiwan的事情。如果你有不小心看到我的學習心得，你應該知道我並沒有照著標準書的內容逐字講解唷。哈～一朝被蛇咬，十年怕草繩。這邊也順便宣告，我不會再參與HL7 taiwan會務活動，不再選什麼有的沒有的，讓有些人放心吧。專心做好知識推廣比有沒有那個位置更重要。沒那位置做推廣，不犯法吧。廢話少說，就開始吧。

在2.15節中是HL7 Table 0440 - Data Types。（Table？別忘了，之前介紹欄位屬性表時有提供唷）在這個表中只有 照字母排序的方式列出。而我想要改用幾個分類項目來討論。你猜出了嗎？我想比照v3.0的方式來分類（當然分法不同）。

1. 文字類：就是上一篇提到的，當然還有其他的。
2. 編碼類：流水號，以及在介紹屬性表時所提到的table編碼等。
3. 統計類：英文的字眼是Demographics。就是關於這個人的聯絡地址、電話、姓名等。
4. 數值類：整數、實數、貨幣等。
5. 時間類：就是時間。但是在電腦領域中，我一直認為時間最難搞定。
6. 臨床類：比較屬於臨床性資料，例如說心電圖的波形，檢驗數值等。
7. 其他類：若實在歸不了類，就放這兒吧。

雖然，我會盡量照這個順序來把資料型態好好搞清楚，不過，可以想像未來這幾篇應該會不斷地更新。畢竟我也是在學習中。

HL7 v2.6學習心得 第二章 USE OF ESCAPE SEQUENCES IN TEXT FIELDS

原文參考：2.7 Use of Escape Sequences in Text Fields

=============================

上回提到，如果資料來源內容包含了那些分隔符號的話，一定要避開，否則剖析程式是會誤判的。如果要避開，那就是在這個符號前面加上跳脫符號。大部分的程式語言(程式語言我沒全學過，不敢說全部）都是用"\"來當作跳脫符號，在HL7的預設值也是，不過倒是可以在MSH宣告時換成其他的符號。不清楚？那又請回到上上篇囉。大部分講到這就結束了，我又不是老師，這是自我學習耶！當然要再深入一點。

到底還會在什麼情形下使用到呢？且慢慢道來。

1. Formatting Codes 格式化編碼

當欄位的資料型態是TX、FT或CF時，其資料內容會是非常豐富的。相對地，會碰到地雷的機會也就變大了。主要的幾個地雷，就是分隔符號，若遇到時，就得用下列跳脫符號來避免之： \F\ ：field separator 欄位分隔符號 \S\ ：component separator 組件（成員/成份）分隔符號 \T\ ：subcomponent separator 次組件分隔符號 \R\ ：repetition separator 重複分隔符號 \E\ ：escape character 跳脫符號。 接著我們來看看TX、FT與CF 這幾個資料型態到底有什麼特殊性。 > TX(text data) 他的欄位屬性表很乾脆。什麼都沒有。 簡單說他是可以顯示在終端機或印表機上的字串。注意，這個是很單純的字串唷，除了內容要避開地雷符號外，唯一需要擔心的就是字串結束符號的差異。DOS是CR/LF；UNIX是LF。 > FT(formatted text data) 他的欄位屬性表也好不到哪裡去。 多了長度65536。之前有提供唷長度設成65536是什麼意思唷。回想。 這下子尷尬了。資料型態中說，要知道怎麼用，請參考section 2.7.6, “Usage and Examples of Formatted Text” 啊不就是這邊要講的。恩，耐心等一下囉。 >CF(code element with formatted values) 他的欄位屬性表，終於比較正常一點了。 仔細一看，原來也沒什麼了不起，就是因為他CF.2與CF.5的資料型態是FT，那還是回到上一個問題。（至於其他的詳細說明，應該是要留到資料型態時，才會細講。） 好吧，還是來講格式的內容。

2. Usage and Examples of Formatted Text (格式化文字的使用與範例)

注意若是TX時，是有甚麼就印甚麼，不會多印空白，或者縮格等功能。想要有漂亮的格式，就得乖乖使用下列幾個符號。注意，那個符號前的"."是一定要的。 > .sp<數字>：留空行。數字代表往下留幾行空白。 > .br：換行。其實也就是.sp的意思。 > .sk<數字>：留空白。數字代表往右留幾個空白。 > .fi：自動換行。這個是預設值。 > .nf：不自動換行。可與.fi做相互切換。 > .ce：將目前所在行置中。 > .in<數字>：段落首行縮排。數字可以為正負。 > .ti<數字>：這個叫temporarily indent，照字面翻譯是暫時縮排。應該要這麼說，.in好像是絕對位置；.ti是相對位置。一般會與.br相配合的話。 以上的符號若是用在FT型態的資料內容時，就需要用跳脫符號告訴HL7剖析器說，這是用來做格式化之用。說實在，還真慚愧，搞HL7到現在，還真的沒用過。 就用標準書的內容當範例吧： 當你接收到這個內容時，如果你有心，你可以解譯成： 為什麼說是你有心呢？你不解譯也沒關係。並不影響其實值內容，他僅是用來排版好看而已。而且，上圖也只是其中一種呈現的結果，端看你要如何設計HL7剖析器。

3. Highlighting 凸顯

當然跳脫符號沒這簡單。還有好多其他的應用。這邊再舉一個凸顯某些文字表示方式。例如說檢驗報告的異常值時，就可以用這個方法。 他所使用的符號是： > \H\：凸顯資料開始。 > \N\：凸顯資料結束。 至於說你是要如何呈現這個凸顯資料，例如說變成紅色、變成粗體、變成斜體，端看HL7剖析器是如何處理。

另外一些就是字元表達方式，在這就不囉唆了。

=============================

HL7 v2.6學習心得–第二章 MESSAGE CONSTRUCTION RULES

原文參考：2.6 MESSAGE CONSTRUCTION RULES

=============================

上一篇終於把訊息結構給講完，但也留下更多的問題。發送端處理訊息的方法與態度，會影響接收端收到訊息後的處理方法與態度。為了避免雙方後續的爭議，也許應把訊息建構（解構）的規則好好地說清楚。

這個訊息建構規則(Message Construction Rules)，可以分成兩個層次與兩個個體。

兩個層次：

• 一般通則：建構/解構訊息的基本規則。也就是本篇想要來討論的。
• 特定規則。這個訊息若是用在特定情境時，例如說轉診，才會有的特定規則。這部分要參考2.B conformance Using Message Profiles，也就是實作指引書的規範。這部分以後應該會聊到。（如果我堅持下去的話）

兩個個體：

• 發送端：建構訊息者，產生交換訊息並將訊息發送至特定接收者。
• 接收端：解構訊息者，接收交換訊息並將訊息轉譯至特定資訊系統。

再強調一下，每一個實作點，都會扮演發送端與接收端的角色，只在於此訊息的複雜程度而已。回覆一個「我收到了」的訊息，也算是發送端了。

接著來看兩個個體分別要做什麼事情。

1. 發送端 Sender

發送端主要任務就是建構訊息。從程式寫作角度，建構訊息會有一個「資料來源」。例如說是從資料庫、從文字檔，還是直接從使用者介面取得。但這邊所討論的訊息建構，則純粹從HL7訊息規則的角度來說明。  (1) 假設資料來源已取得，命名為data。這個data就先不管是一個dataset還是xml還是CSV檔。先想像成具有特定格式的大字串即可。  (2) 確認要要遵守的實作指引書（Profile）的版本，並決定要採用的trigger event，然後得知所需求的區段清單有哪些，命名為segment_list。這個segment_list當然可以自己建立，或者取得XML Schema，或者可以下載一些API，例如說HAPI。  (3) 驗證data。這是要先確保此訊息所需要的資料來源都有準備好。否則，建構出來的訊息並不能滿足「特定規則」層級的驗證規則。  (4) 欄位對應。將data來源的欄位與segment清單中的欄位進行對應關係。這樣子，才知道資料來源的內容值應該要放到什麼位置去。  (5) 逐一針對在segment_list中的區段逐一開始建構。  (5.1) 輸入區段名稱。就是那三個英文字母，如MSH。原則上第一個一定是MSH，除非你的系統設計在這塊又是設計一個物件來處理，那就比較沒有前後問題，但是最後組起整個大字串的時候，還是照segment_list的順序。  (5.1) 逐一處理在這個區段內的欄位清單。注意，每個區段有哪些欄位是固定的，這個可以寫成單獨物件來處理所有的segment的欄位，而無須向訊息的區段要先準備好segment_list。  (5.1.1) 輸入欄位分隔符號，預設是"|"。一般在設計上，會去讀一個列舉常數，這個列舉常數把自訂區隔符號都先定義好。  (5.1.2) 逐一處理此欄位的資料型態內容。有些會處理到重複的問題。  (5.1.2.1) 建構組件內容()。這部分先保留，要拉到另一段(6)來講，結構比較清楚。  (5.1.2.2) 如果不是最後一個組件內容，則輸入重複分隔符號，預設是"~"。  (5.1.3) 如果確認是最後一個組件，則跳離，處理下一個欄位內容。  (5.2) 所有欄位都處理完後，表示這個區段結束，然後插入一個區段結束符號，一定是，也就是0D。  (5.3) 在處理下一個在segment_list的segment。  (6) 專門處理某欄位資料型態下各組件結構。  (6.1) 逐一處理欄位內的組件。  (6.1.1) 取得此組件的次組件清單。  (6.1.2) 逐一處理此組件的次組件。  (6.1.2.1) 將資料內有欄位區隔符號者取代為\F\。  (6.1.2.2) 將資料內有組件分隔符號者取代為\S\。  (6.1.2.3) 將資料內有組件分隔符號者取代為\R\。  (6.1.2.4) 將資料內有組件分隔符號者取代為\E\。  (6.1.2.5) 將資料內有組件分隔符號者取代為\T\。  (6.1.2.6) 將資料內容放入此次組件中。  (6.1.2.7) 如果不是最後一個次組件，則插入次組件分隔符號，預設是"&"。  (6.1.3) 如果不是最後一個組件，則插入組件分隔符號，預設是"^"。  (6.2) 處理下一個欄位組件。

2. 接收端 receiver

接收者很單純，不對就退。不過還是有三個原則。  (1) 有些區段、欄位、組件、次組件或重複次數雖然發送端有準備，但不是你期望看到的，那你就忽略他吧。  (2) 處理一些你期望有資料的可選區段，但對方卻沒有送來。  (3) 處理一些你期望要有的欄位與組件，但對方卻沒有送來。 後面兩種情境，你可能需要多關注一下。這些你期望的資料對你的系統而言是是可不可為NULL值。可NULL當然對系統影響不大，只是畫面、報表不好看而已。若是不可NULL，那就得問你的系統容錯性如何了。若沒有處理這個問題，直接把資料丟到資料庫而出現問題，你的程式又不處理，放任使用者傻傻的不知所措。請問這個是訊息的問題還是你程式的問題呢。不要再怪罪訊息，或者質疑對方會送NULL值資料，然後不願意採用標準。

這篇所聊的內容你若看不懂，我想也不用太在意，畢竟你也不需要去寫一個HL7 gen/par程式。市面上有太多的API可以使用，很多ESB有支援HL7，或者Interface Engine、Message queue、Message gateway 都有支援HL7。所以，採用HL7 v2.x做病歷交換根本不是技術問題，純粹是心態問題。甚至是因為還搞不清楚什麼是病歷交換。

==============================

這篇有提到幾個符號如\F\等，這個就是跳脫符號的利用，這也是上上篇所留下的伏筆。再聊囉。

HL7 v2.6學習心得 第二章 Message Framework ─ 3

原文參考2.5.4 Message delimiters

==============================

話說上回聊到有欄位分隔符號與重複分隔符號後，那你一定會問「還有哪些分隔符號？」是地，還有一些分隔符號需要學習的。而且，對於實作HL7訊息者，這個是非常重要的資訊。因為你就是透過這幾個字元來辨識程式的邏輯。

在HL7 v2.x版中其實有分成XML版與ER7版。若你走的XML版本，那這些分隔符號其實你可以不用理他，你要遵守的是XML的剖析規則。但是，你要走的是ER7格式（就是傳統格式），這些分隔符號就顯得非常重要。因為我們有可能需要將XML格式轉成ER7的格式，所以，這部分還是要學習一下。因為，你無法保證你的接收端都懂得接收XML格式的檔案。

接著就來看，有哪些分隔符號。其實不多，只有六種。

1. Segment Terminator 區段結束符號

其實一個HL7訊息，基本上是一個大字串，把這個大字串存成一個檔案，然後送給接收者（當然是以電子方式囉，不是印出來寄過去）。之前也聊過，一個訊息是由很多的區段所組成，每個區段都用三個大寫的英文字母來代表，如MSH、PID等。這時候要再多加一條規則，就是每一個區段結束後，請再多加一個carriage return。在ASCII編碼中十進制是13，十六進制是0D。注意，他是屬於控制字元，不是顯示字元，在電腦畫面上不會佔一格，你是看不見的。若要以顯示字元表達時，習慣是用<CR>。講到這，不得不強調一下。各位在電腦畫面上都是看到每一個新的區段，其字母都會整整齊齊在新的一行左邊出現。各位，這是加工後的結果。為了顯示好看，又加上了<LF>的結果。注意唷，不要copy&paste，就當作訊息送出去。好一點的設計，會把訊息這個大字串，分成顯示還是傳送用。 注意，這個結束符號是不得改變的唷。

2. Field Separator 欄位分隔符號

除了前面這個區段結束符號不得改變之外，從現在開始所講的分隔符號都是可以自訂的。當然，HL7標準是有些建議值，這就是之前說過的"|"。 可以自訂？發送端搞個自訂，那接收端怎麼知道呢？簡單呀，這些自訂的分隔符號字元，就直接擺在訊息裡，讓接收端的程式自己去想辦法囉。所以，這個資料一定要放在訊息的最開頭。訊息又是由區段組成，所以，訊息的前三個字是MSH這個區段名稱，然後是分隔符號，然後就是其他的分隔符號(先忍耐，後續就會個別講到）。假設都是用預設的話，那訊息的一開頭就為長成這樣子： MSH|^~\&| 若是你想改用"*"做欄位分隔符號，其他不變，那你的訊息開頭就會變成： MSH*^~\&* 你改成這樣子，你就必須要保證，欄位內容值絕對不會出現"*"，否則一切都毀了。 所以盡量採預設值，如果你的欄位內容值就是含有"|的話，那還是有其他的變通管道。那就跳脫符號"\"，這個留到第6點來說明。

3. Repetition Separator 重複分隔符號

這個符號在之前就講過囉，預設是用"~"。

4. Component Separator 組件分隔符號

之前有講過，每個欄位都會有資料型態，而這個資料型態是屬於reference type。也就是說，這個資料型態也可能包含有數個欄位內容。好像是一個組件的感覺。我們用PID這個區段來解釋。 別的不管，先看第5個欄位 Patient Name。看英文名稱應該知道是用來代表病患姓名。再來看他得資料型態，很抱歉，他不是字串，而是一個叫XPN的資料型態。那我們來找找，XPN長什麼樣子。注意，從v2.5之後，資料型態就獨立成一份文件CH02A Data Types。 原來XPN還這麼複雜唷。這個資料表示描述資料型態，基本上跟欄位資料表示類似，好像也是一個一個的欄位呀。既然欄位要分隔，這個也是要分隔呀。可是，若用了與欄位相同分隔符號的話，就會天下大亂了，只好找個新的符號。HL7的預設符號是"^"。這時候，你看到下列訊息時，應該不會覺得很刺眼了吧。 PID|1||PATID1234^5^M11^ADT1^MR^GOOD HEALTH HOSPITAL~123456789^^^USSSA^SS||EVERYMAN^ADAM^A^III||19610615|M||C|2222 HOME STREET^^GREENSBORO^NC^27401-1020|GL|(555) 555-2004|(555)555-2004||S|| 仔細算欄位分隔符號"|'的第5個空間（哈～眼瞎了我不負責。這是給電腦看的啦），是不是EVERYMAN^ADAM^A^ 。如果不是，請保重，相信我就好。再用"^"組件分隔符號對照到XPM的順序，我說Give Name是ADAM，這下子你同意了吧。拜託，訊息交換不是這樣子搞的啦。我常說，這嚨是電腦徑的啦。講到這，你都懂，你的功力也大增了。

5. Subcomponent Separator 次組件分隔符號

講到組件分隔符號時，看到了XPN資料型態的欄位表。他也有一個欄位叫DT，也就是資料型態。很煩吧，「資料型態的資料型態還是資料型態」。所以，也會面臨欄位區隔的問題。這時候，HL7的預設分隔符號是"&"。 那還不會不有下一層呢，感謝唷！沒有了。

6. Escape Character 跳脫符號

這跳脫符號的用法跟其他程式語言所定義的是一樣的。預設的跳脫符號是"\"。真的要詳細講跳脫符號的話，得另闢專章了。

這時候該來談談那個這些符號的順序性了。在第2點欄位分隔符號時，有提到MSH這個區段，他就是用來描述整個訊息的基本資料。這條區段是特別給HL7訊息剖析程式看的。程式收到訊息的第一件事情就是確認字串開頭是不是MSH，不是，什麼都不用做了。看到MSH，放心了，在看下一個字元，喔這就是分隔符號了。確認了這個分隔符號後，就是在去找下一個跟這個一樣的字元，然後這兩個分隔符號內的東西，就是這個訊息會用到的分隔符號（這些是訊息建構規則）。依序是：

1. ^ 組件分隔符號。
2. ~ 重複分隔符號。
3. \ 跳脫符號。
4. & 次組件分隔符號。

=============================

這邊留下了好多伏筆。資料型態、跳脫符號、訊息建構規則等。哈～只能慢慢等我的學習心得。注意，我可沒有免費教你們唷。我只是把我學習過程分享出來而已。

HL7 v2.6學習心得–第二章 Message Framework ─ 2

>原文參考2.5.3 Fields。

==============================

今天要來談的欄位(Fields) 有很多重要觀念需要詳細講解。這部份還需要配合資料型態背景，所以，要先做概念性解說。

Fields

原文說明：A field is a string of characters. Fields for use within HL7 segments are defined by HL7.

說穿了欄位就是由字元所形成之字串用在HL7訊息的區段中。

注意，HL7並沒有定義資料是如何儲存在真實系統的應用程式中。當這些資料要被轉換時，都是先轉乘字串型態。

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 10.0px 'Times New Roman'}

每個欄位可能會有三種群體狀態。

1. 有值：欄位填入非空白，有意義的內容。

2. 無值：欄位是空白，沒有任何有意義內容。

3. 空值：欄位填入了""，也就是NULL值的意思（兩個雙引號，但中間沒有任何空白或有意義的內容）。

接收端遇到這三種情境要如何處理，可以參考2.6 Message Construction Rules。

為了描述每一個欄位的定義，標準書中使用了統一的表個規範。

上次一的ADT^A01訊息中，第一個區段就是MSH，我們就來看看這個MSH有哪些欄位。而他的metadata又有哪些。

上圖(一樣，只能給部分，全圖請看原本標準書）就是描述個區段內有什麼欄位的屬性表。注意，所有的區段都是用相同的屬性表來描述（所以，這叫Metadata)

我們要先學會看懂這個屬性表中的欄位定義，才有能力進一步知道，這個區段內各欄位的應用情境。

1. Position 位置

在表中的第一欄，欄位名稱是SEQ。

注意這個順序是不可以被挪動。也就是說，就算這個欄位沒有被使用到，那個位置還是要留下來的。也就是要留下欄位分隔符號。在兩個欄位分隔符號的中間，就是「無值」（注意，不是空值唷）。假設欄位分隔符號目前定義是|，若某欄位沒有用到就是要用||來表示之。

2. Maximum length 最大長度

在表中的第二欄，欄位名稱是LEN。

原則上這個欄位不是很重要。這邊的長度限制，也並不會與原始資料在資訊系統的長度一致。而且，再系統實作的時候，都是為字串，原則上就是可以變動。只是比較嚴謹的作法時，會檢查長度。

如果欄位資料很長時 (長字串，如text或memo)，這個數字會是65536。如果是標記成99999，那表示這個欄位可以任意長度。

3. Data type 資料型態

在表中的第三欄，欄位名稱是DT。

這個欄位描述非常、非常、非常重要。也是實作階段要特別注意的地方，但是，這個資料型態與資料庫或程式語言所描述的資料型態是不同的。這個比較像是物件導向程式語言所reference type。

這部份的知識，必須另闢討論序列。可參考2.15 Data types這個章節。

4. Optionality 可選性

在表中的第四欄，欄位名稱是OPT。

    定義這個欄位在這個區段中的存在狀況。

    這個存在狀況可以分成：

    R - required 必要。無論如何這個欄位一定要有值，就算發送端沒有這個欄位，那也要放空值。

    O - optional 可選。可有可無。若無，那就留下欄位分隔符號即可。

    C - conditional on the trigger event or on some other fields。條件存在。會因為不同的驅動事件或因為某個欄位存不存在或是等於什麼條件時，這個欄位就需要存在。

X - not used with this trigger event 不採用。這個欄位在這個驅動事件時不使用。但仍須留下欄位區隔符號。

B - backward 相容。沒別的目的，就是為了與前面的版本相容而留下來的。如果不用也無所謂，但仍須留下欄位區隔符號。

5. Repetition 重複性

    在表中的第五欄，欄位名稱是RP/#。

    這個是用來表示這個欄位在這個區段中是否可重複出現。這下子有個問題浮現了。兩個欄位區隔符號的中間代表這個欄位，可是這個欄位又可重複？那表示需要有一個重複區隔符號。

    那為什麼不用欄位區隔符號？注意，在SEQ不是提到這個順序性是固定的，要是用欄位分隔符號來做重複，那後面的欄位順序不要亂了嗎？由於，這些分隔符號都可以自定，先用預設符號是~。若有個訊息是長這樣時|AAA~BBB~CCC|，表示這個欄位重複了三次。

    N或空白：表至這個欄位不可以重複。

    Y：表示這個欄位可以重複，且可以重複任意次數。注意，可重複並不代表一定要重複，若出現一次也是合法的。

    數字：如果你確定知道這個欄位最多可以重複幾次時，那就把上限值寫入。

6. Table 參照表

    在表中的第六欄，欄位名稱是TBL#。

    許多欄位的內容值是受限制的。HL7把這些限制範圍都用另一個參照表來描述，並給每一個參照表一個號碼。如果這個欄位有用到參照表，那就把這個參考表的編號填入本欄中。

    所謂的限制範圍其實又可根據他的強度與來源，共分成三大類型：

    （1）HL7 Table：這個是HL7標準給定的內容值，使用者不得修改之。此類欄位的資料型態會是ID。

    （2）User-defined Tables：使用者可以自行定義、增加、修改參考表內容。此類欄位的資料型態會是IS。

    （3）External Tables：前兩者的參考表都來自HL7內部定義。若此參考表是別的單位組織所致定時就屬於本類。此類欄位的資料型態會是CF、CNE與CWE。

    至於ID、IS、CF、CNE與CWE屬於資料型態範疇，有討論到實在詳細說明。

    另外在新版的標準書中還增加了兩類的參照表，Imported Tables與Local Tables這邊就保留吧。

7. ID number 流水號

    在表中的第七欄，欄位名稱是ITEM#。

    HL7針對每一個定義不同的欄位都指定一個欄位號碼且不重複。這個只是查表方便而已，但有些API會把這個當鍵值。

8. Name 欄位名稱

    在表中的第八欄，欄位名稱是ELEMENT NAME。

    就是這個欄位的完整名稱。

看懂這個屬性表，後續各章節所提到的所有訊息，各區段有什麼欄位內容其表達方式都一樣。

=============================

這次有提到欄位分隔符號與重複分隔符號，那還有哪些呢？也許是下一次的主題吧。

HL7 v2.6學習心得–第二章 Message Framework ─ 1

原文參考：2.5 MESSAGE FRAMEWORK

==============================

上次提到的驅動事件(Trigger Event)是動態模式。也就是說，到底發生了什麼事情下，我才要發動這個訊息交換的任務。緊接著就要回答說，好，那要傳遞什麼訊息內容出去呢？這時候就來到了靜態模式。 不同的Trigger Event下會定義出不同的訊息內容。但是，所有的訊息內容都必須遵守相同的框架。也就是，Message Framework。要開始了解得先把幾個名詞給搞懂。

Message

原文說明：A message is the atomic unit of data transferred between systems.

訊息(message)是資料交換的最基本單元。這個最基本單元卻是由許多有一定排列順序的區段(segment)所組成。 每一個訊息都會依據其使用目的定義一個訊息型態(message type)。例如說病患管理就會是ADT這個訊息型態。要詳細知道有哪些，可能就得努力翻閱後續章節的內容。 如果現有的訊息型態無法滿足需求時，可以自定訊息型態，把首字定為"Z"即可。

Segments與Segment groups

原文說明：A segment is a logical grouping of data fields.Two or more segments may be organized as a logical unit called a segment group.

區段(segment)是有一組具有邏輯意義的資料欄位所組合。兩個或兩個以上的區段可以結合成另一個邏輯意義的區段組(segment group)。每個不同定義的區段會有三個英文字母的命名，注意，三個字母皆為大寫。

如果現有的區段無法滿足時，可以自定區段，只要命名首自為"Z"即可。

每個區段可以被設定成[必要、可選]與[重複]的屬性。

在一個訊息中，有可能同一個區段會在不同的邏輯位置上出現。所謂的不同邏輯位置，有可能是這個區段在不同的區段組中出現，而這個訊息剛好用到這兩個區段組。不過，一般而言，因為是屬於不同的邏輯位置，所以在資料交換的時候並不會造成誤解。如會造成誤解，那這個訊息就是錯的。也就是說，如果你的程式寫出來的訊息有這種現象，那驗證是過不了的。

表達方式

有了以上的基礎後，我們來看看標準文件中是如何呈現。我們舉一個ADT^A01的例子。

ADT就是指訊息型態。A01是指驅動事件。標準文件的第三章 Patient Administration所討論的都是ADT這個訊息型態。而A01這個事件是發生住院或報到通知時，所需要傳遞的訊息結構。下圖是這個訊息下所定義的區段。（很抱歉，下圖只是部分資料，全文還是請參考原版標準文件。我很想完整呈現，但是，我實在擔心誰又那麼無聊發律師信給我了）

圖中有MSH、SFT等等，這就是segment的名稱。現在看不懂是作什麼用的，沒關係，後面會帶到。先搞懂這些就是區段就好。

再看有些有[]或{}，也些卻沒有。[]表示可選；{}表示可重複。而什麼都沒有的，就是必要區段，且只能出現一次。[{ }]的意思是，這個區段為可選，若有出現的話可以重複。可惜上圖沒有區段組。

若有區段組時，他的結構是必須是嚴謹的巢狀結構。（這個考試會考，唉～何須在意考試呢，能做出一個符合規範的標準訊息勝過一切）。

底下舉例來說明，區段與區段組結構的合法性。

[SEG1]

{

 SEG2

 [SEG1]

}

這個是合法的。主要是看SEG1這個區段能不能辨識出他邏輯位置。第一個SEG1是可選，表示訊息中不一定會出現。現在假設他不會出現。

再看SEG2與另一個SEG1形成一個區段組。這整個區段組是可以重複的，但每一個重複的區段組***一定要有SEG2***這個區段。然後配上可以有可無的SEG1。

反過來說，當你看到一個SEG1單獨存在時，我知道那一定是第一個。若是第二個SEG1時，他的前面一定會有SEG2。

再看另一個範例。

[SEG1]

{

 [SEG2]

  SEG1

  SEG3

}

這個就是非法的。一樣來看SEG1會不會造成辨識錯誤。第一個SEG1不變，但是我們這時候要假設他出現了。

然後，後續的可重複的區段組中SEG2是可選的，那我們假設他沒有出現，接著又看到SEG1，哇！他是必要的。這下子慘了，因為訊息結構變成了

SEG1

SEG1

可是，這兩個SEG1在標準制定階段，是標記在不同邏輯位置上。可是實作時，卻無法辨識出來。那這個標準結構就是有問題了。

〈待續〉

==============================

接下來要討論的field很重要唷。

HL7 v2.6學習心得–第二章 Trigger events

HL7 v2.x版的第二章是靈魂所在。英文章名為Control，是指不同應用情境下皆採相同的控制方法。

之前我們已經提到幾個關鍵字，field, field separator, segment等。第二章有更多的專有名詞需要先認識一下。

首先來看Trigger events。

對於有寫視窗程式者比較容易進入狀況。程式設計的主要思維就是如何因應使用者對系統所採取的行動，這個行動對系統而言為event。若使用者沒有做任何行動時，系統也只有等待。

在訊息交換的領域中也是一樣的。原則上不會沒事就傳一個訊息出去。一定是基於某個事件下，才會發動傳送訊息這件事情，然後再看是什麼事情，才來決定應該要攜帶什麼樣的資料。在醫療環境中，可能發生的事件實在很多，這才會多出這麼多章來分別描述。

在標準書中的說明內容：「The Standard is written from the assumption that an event in the real world of healthcare creates the need for data to flow among systems. The real-world event is called the trigger event.」

這個real world就會有爭議了，畢竟國外的情境與國內的情境或多或少有差異。訊息交換適用於異質環境中，國外比較符合，國內大都是單一系統，所以很難體會異質環境。不過，隨著資訊技術多元化，所有醫療院所都不得不面臨異質化的問題。

既然是事件發生，就會有發送者與接受者兩端。兩個進行資料交換的系統，不會固定一邊是發送端，另一邊就是接收端。因為訊息必須是有去、有回。所以，這來回之間，只不過其差異是誰「先發送後接收」或「先接收後發送」而已。這個「來回」是大有學問的。

先講發送端。發送一個訊息出去有兩種可能，「主動」與「被動」。

主動就是當某事件成立時，發出一個訊息，或者發出查詢(Query)。

被動是在回應的要求下發出一個訊息。這下子又有學問了「在回應的要求下，才發訊息」，那應該在何時進行回應呢？

回應的模式再被分成「original model」與「enhanced mode」兩種。

original model簡單地說就是老神在在。發送端發出此類訊息，並不急著要接收端回應。接收端收到訊息後，等一切資料都準備妥當之後，才依據trigger event的標準規範，採相對應的訊息加以回應即可。（注意，這時候接收端變成發送端了）

enhanced model簡單地說就是急郎中。發送端發出此類訊息時，務必請接收端發個回應說已經收到了。然後，接收端把資料都準備妥當後，在發訊息回應給當初的發送端。然後請當初的發送端回應一個收到的訊息。

所謂的電子病歷交換都必須是基於上述之模式下進行，如果只是單一方面將資料匯出，這叫資料的「匯出匯入」模式。真正的電子病歷交換需在Trigger event的指引，發送端清楚的告訴對方，我要什麼資料（Query），或者我已經完成什麼事情（unsolicited update）。接收端接到訊息後，才根據訊息內容進行處理與回應。

目前EEC的作法，我只能說，我存疑。

HL7 v2.6學習心得 - 相關標準

• ANSI標準
• ANSI X3.30：1985年 日曆格式與順序表示法。
• ANSI X3.4：1986年 編碼字元集。American National Standard code for information interchange (7-bit ASCII)
• ANSI X3.43：1986年 資訊系統用於資訊交換的本地每日時間表示法。
• ANSI X3.50：1986年 美國在有限字元集下，習慣使用的單位表示法。
• ANSI X3.51：1986年 用於資訊交換之世界各國、本地時間差與美國時區的參考表示法。
• ISO標準
• ISO 5218：1977年 資訊交換─人類性別表示法。
• ISO 1000：1981年 SI Units and Recommendations for the use of their multiples and of certain
• other units
• ISO 2955：1983年 資訊處理─在有限字元集下資訊系統與其他系統的單位表達式。
• ISO 8072：1986年 網路標準。
• ISO 8601：1988年 資料元與交換格式─資訊交換（日期與時間表達式）。
• ISO 8859：1988年 資訊處理─八位元位元組的圖形字元集。
• ISO 8859/1：1988年 資訊處理─拉丁字母編號1
• ISO 8859/2：1988年 資訊處理─拉丁字母編號2
• ISO 8859/3：1988年 資訊處理─拉丁字母編號3
• ISO 8859/4：1988年 資訊處理─拉丁字母編號4
• ISO 8859/5：1988年 資訊處理─Latin/Cyrillic Alphabet
• ISO 8859/6：1988年 資訊處理─Latin/Arabic Alphabet
• ISO 8859/7：1988年 資訊處理─Latin/Greek Alphabet
• ISO 8859/8：1988年 資訊處理─Latin/Hebrew Alphabet
• ISO 8859/9：1988年 資訊處理─拉丁字母編號5
• JAS2020：ISO2020的子集，用於大部分的漢字轉換。
• JIS X 0202：ISO 2022與跳脫順序的漢字。
• 編碼與字彙來源
• ACR：Index for Radiological Diagnosis, Revised 3rd Edition  放射診斷索引，第三次修訂版。
• CPT4：Current Procedural Terminology 現在手術術語。
• CAS：USAN 1990 and the USP dictionary of drug names
• EUCLIDES：European standard for clinical laboratory data exchange臨床檢驗交換歐洲標準。
• Home Health：Home Healthcare Classification System.
• HIBCC：Standard for electronic business data interchange.
• ICCS：Commission on Professional and Hospital Activities.
• ICD-9：International Classification of Diseases, 9th Revision.
• ICD9-CM：International Classification of Diseases, Clinical Modification Manual of Clinical Microbiology.
• NANDA：North American Nursing Diagnosis Association, Philadelphia PA.
• NDC：National drug codes
• NIC：Nursing Interventions Classification, Iowa Intervention Project. U. of Iowa.
• NLM：Unified Medical Language.
• Omaha System：Omaha Visiting Nurse Association, Omaha NE
• Read：Clinical Classification of Medicine
• SNOMED III：Systemized Nomenclature of Medicine
• WHO：Drug Code
• UMDNS：Universal Medical Device Nomenclature System
• FDA K10：Device Codes Device and analyte process codes
• LOINC：Laboratory Object Identifier and Numerical Code

HL7 v2.6學習心得 - HL7 Encoding Rules

>原文參見 1.7.1 HL7 Encoding Rules

=========================================

編碼規則主要是規範下列幾件事情：

1. 欄位長度
2. 欄位分隔符號
3. 資料型態
4. 重複次數

具有相同邏輯意義的欄位會被組合在一起，稱之為segment，中文翻譯成「區段」。 區段與區段之間會有「區段分隔符號」。

在一個訊息中，每個區段之前會有三個英文字母來代表這個區段的定義。 個別區段將被定義必要或可選，以及可以重複的次數。 各欄位在訊息中位置，則需分別參考相對應的區段。

所有資料是使用所選擇的字元集的可顯示字元。所選字元集是定義在MSH區段中。 欄位分隔符號需選自ASCII字元集中的可顯字元。其他的分隔符號也是要選擇可顯字元，除了Carriage Return。

編碼規則於空值與不存在是視為不同的定義：

• 空值是在兩個欄位區隔符號中間有有兩個雙引號。
• 不存在是在兩個欄位區隔符號中間沒有任何資料。

這兩個定義不同，會牽涉到後續接收者對資料的處理方式。空值(NULL)時，存入資料庫時須設為null。而不存在則須設成預設值。

臨床編碼系統 - 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