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。而不存在則須設成預設值。