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\等，這個就是跳脫符號的利用，這也是上上篇所留下的伏筆。再聊囉。