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的作法，我只能說，我存疑。