基于臨床超聲設備環境下的Worklist 應用

李昕，魯 曉，張 勇，丁博淵，邱 邐，羅燕

（四川大學華西醫院超聲醫學科，四川成都 610041）

目前，臨床超聲醫生在對患者進行超聲診療時，需對患者進行身份信息核查工作，這是降低醫療風險非常重要的環節之一，患者信息錯誤導致的醫療風險，將為患者帶來無法挽回的后果[1]。傳統的手動輸入患者信息和研究標識信息（患者姓名，患者標識，出生日期，性別和登記號）時，會出現信息不對等的錯誤。Worklist 的應用是基于DICOM 協議中的CFind 查詢服務技術保證超聲信息系統（Ultrasound Information System,UIS）與設備之間產生的數據具有一致性和完整性的功能，可以從UIS 接收Json 消息，將轉換或映射數據以生成DICOM 消息的模式傳遞到影像歸檔和通信系統（Picture Archiving and Communication System，PACS）[2]。工作流程中需要UIS提供的患者和檢查信息才能流向模態（Modality），利用DICOM 方式工作清單（DICOM Modality Worklist）對此提供支持。如今，醫院的發展更依賴于互聯網對數據的傳遞，從而形成閉環管理，減少數據差異產生的問題。現在，超聲設備已經通過一致性聲明和系統供應商之間測試，建立了用于查詢或檢索，存儲和打印類的基本DICOM 通信協議。依賴HIS（Hospital Information System,HIS）接口將患者的信息傳遞到超聲UIS 中。通過該服務功能將患者的數據自動、可靠、準確無誤地從數據庫中轉換到設備工作列表中，從而減少醫務人員的干預，同時避免因數據錯誤產生的影響，大幅度提高了醫務人員的工作效率[3-5]。目前Worklist 功能已經廣泛運用在放射、護理等領域。

1 Worklist定義

Worklist 作為影像設備訪問工作列表，主要用于影像設備與業務系統，通過特定協議完成數據交互[6]。DICOM 協議中包含很豐富的服務，而Worklist服務僅僅是其中之一。通過模態查詢數據提供者，并獲取醫療環境下患者基本信息，同樣也可獲取與科研等相關的數據信息。根據DICOM 協議部分描述，Worklist 工作原理中定義了以下角色構成。服務類客體(Service Class User，SCU)以及服務類供體（Service Class Provider，SCP）,兩者之間還需依靠DICOM SOP（Service Object Pair，SOP）類建立關聯。而DICOM SOP類是由DICOM IOD 與DIMSE服務共同定義。Worklist 正是利用Query/Retrieve 服務類同時結合C-Find 的服務元，執行DICOM IOD 查詢服務的過程。當SCU 需要與SCP 之間交互時，兩者互為實施DICOM SOP 通訊的雙方，需要依托應用實體(Application Entity，AE)對其屬性信息進行控制和處理。對于C-Find 服務元素來講，請求查詢操作分為三個狀態（操作成功、失敗后發送成功、發送失敗）。而C-Move 服務元素主要針對反饋應答及反饋操作計數。C-Get 服務則為提取性操作。C-Find的過程會包含必要鍵屬性及可選鍵屬性同時發起查詢請求，當接收到指定的鍵屬性后執行匹配操作，并反饋狀態消息，例如患者信息、檢查項目信息、設備操作信息等[7-8]。而在實際應用中，通常第三方信息系統與影像設備之間都具備查詢服務能力。而運用此項服務最大的價值在于可以將消息形成閉環從而減少輸入導致的錯誤。假設把SCP比作服務端，把SCU 比作客戶端，模擬具體的交互過程如圖1 所示。

圖1 SCP與SCU交互過程

SCU 首先發起對話請求，試探SCP 端的響應。當SCP 響應連接請求后建立連接的同時會反饋成功連接狀態給與SCU 端。此時SCU 第二次發送請求，此次請求中主要涉及到C-Find 查詢。SCP 接收查詢請求同時建立對話，按照查詢要求定義返回SCU 需求數據，其中包含返回狀態值。交互完畢后釋放對話連接，完成此次查詢活動[9]。

結合實際的醫療環境來闡述具體的工作原理，當患者需要進行彩超檢查，患者通過就診卡或已繳費單據前往超聲科預約臺，如圖2 所示。登記的過程是將患者的信息（卡號、患者姓名、性別、年齡、檢查項目等信息）通過HIS 系統傳遞到UIS 服務器。而UIS 服務器根據收到的以上信息會將患者按照具體的檢查時間預約至指定的檢查房間。同時UIS 服務器會將患者預約信息及狀態、檢查信息向PACS 服務器進行推送，當PACS 收到信息后，按照請求信息進行字段整理,最終形成一張可供設備調閱的工作列表。由超聲設備向PACS 服務器發送對話請求，PACS 服務器收到超聲設備發送的請求后進行響應，雙方建立連接。此時設備按照需要的字段向PACS服務器再次發送請求，PACS 服務器按照超聲設備需要的信息進行整理過濾后推送給設備并發送狀態信息，最后設備收到PACS 服務器發送的數據信息后也會向PACS 服務器反饋一條狀態信息證明此次對話是否成功，并斷開此次對話服務。

圖2 UIS-PACS系統與設備交互過程

超聲檢查前，需要對患者的身份信息進行核實，往往醫務人員需要通過特定的某些字段來確認患者的基本信息和檢查信息是否與預約系統中一致。

在未啟用Worklist 功能前，醫生需要核對患者手中的預約單，通過超聲設備Patient 界面手動輸入患者的檢查ID（Patient Number）以及患者姓名（Patient’s Name）特定字段進行檢查。日常工作中，傳統的輸入模式存在以下問題：

1）采用人工輸入導致浪費大量時間以及工作效率的降低。

2）醫生在錄入患者數據過程中產生的檢查ID號錯誤，導致圖像信息的傳輸失敗。

3）數據通過手動輸入，信息過于單一，且只對患者的ID 號進行保存，對于后期科研數據的研究有一定影響。

啟用Worklist 技術對于現有模式優化存在以下幫助：

1）醫生通過Worklist 獲取到每日的預約患者信息，通過掃描患者預約單上的檢查號，在超聲機上精準定位到患者，并進行檢查，減少了人為出錯的概率，從而大大提高了工作效率。

2）患者數據通過Worklist 工作列表抓取預約的數據，杜絕了檢查號不一致導致傳輸失敗的問題，真正意義上保證了患者圖像文件的準確性及個人圖像信息的歸檔。

3）超聲設備中Worklist 含有豐富的字段（如醫囑、部位、診斷等）可以進行抓取并歸檔，對于后期按照病種進行研究有一定支撐作用。

2 Worklist字段參數

有關Worklist 的參數構造可詳見DICOM 標準，該標準定義了必填項、可選項參數，基于DICOM3.0標準中的定義，設備與外部服務之間的信息交互需嚴格遵循此協議。該文僅列出Worklist 中所涉及到的必要字段，如表1 所示。

表1 Worklist字段

Worklist 的字段是非常豐富的，并不限于以上列舉的字段，科研人員可以借助提供的字段（Tag）做更多更豐富的數據類型研究。

3 Worklist配置方法

以目前科室正在使用的設備為例詳細闡明Worklist 的配置方法。基于服務器端及超聲設備端的配置界面，介紹如何通過C-Find 查詢服務實現抓取患者信息的過程。配置由服務器端配置以及設備端的配置兩部分組成。

3.1 服務器端配置

服務器端采用Oracle 數據庫進行搭建，系統工作模式采用點對點的配置模式，每一臺設備存在一條對應獨立的配置項。前期需要定義服務器的IP地址、端口號等條件，保證服務器具備與設備間互通的網絡要求。并且需要給服務器分配一個SCP的角色，Worklist SCP 的AE-TiTle 和Port需要告知設備，設備上需要配置Worklist SCP 的參數才能正常查詢Worklist，作為SCU 設備,需與相對應的服務端配置保持一致，需要和對應服務器端的配置一致。服務器端需根據編碼規則定義字段建立屬性編碼，例如Patient’s Name、Patient ID、Patient’s Sex、Accession Number、Study Descripition、Modality 等，與超聲設備上字段對應，從而達到超聲設備端抓取患者信息的功能。也可以按照檢查室進行配置，利用檢查室條件限定只查詢當前檢查室的患者登記信息。服務器端主要關注的配置點包含服務節點描述、影像接收狀態、影像注冊狀態、AE-TiTle、端口、日志記錄。

3.2 超聲設備端調試與配置

基于DICOM 協議的介紹，明確要求配置查詢/檢索服務配置（Query/Retrieve Service Configuration），其中，AE-TiTle（Calling AET/Called AET）為必填配置，負責服務器端的發起接收功能，Called AET 負責主動發起消息。Port 配置（Port Query/Port Retrieve），Port Query 負責檢索，Port Retrieve 負責數據取回。同樣IP 地址也需要配置，包括設備端的IP 及服務器端的IP 地址。

以現有環境下的超聲設備為例，包括具體的配置以及調試過程，從設置、參數調試、調試中產生的問題以及解決方法幾個方面進行闡述。以飛利浦的某型號設備配置為例。完整的超聲設備Worklist 配置環境包含兩部分：第一部分為構建超聲設備的網絡環境，第二部分為超聲設備的服務類創建。參照某機型超聲設備說明文檔，首先需要配置超聲設備“NETWORK/DICOM”選項模塊中的基本網絡參數。配置IP 地址模式（動態地址或靜態地址），對于涉及到點對點傳輸方式與服務器交互，一般會采用靜態地址作為首選。點擊靜態IP 地址模式后彈出“IPv4 配置”界面，填寫參數包含IPv4 地址，子網掩碼、默認網關。其次需要建立與Worklist 服務之間的關聯，建立與服務器間的互通性關系。關于Worklist 服務類的創建，需要定義創建的類型，在超聲設備中Worklist 類型屬于“DICOM 工作列表服務器”，因此，需要在設備類型中選擇“DICOM 工作列表服務器”，通過輸入必要信息來配置設備，其中包括設備名稱、AE-TiTle、端口號及IP 地址。因AETiTle 具有對大小寫敏感的特性，配置時要求與服務端的AE-TiTle 保持一致性。對高級選項中所涉及的Worklist 的查詢頻率及查詢屬性的定義不做嚴格要求，保存設置后，超聲設備提供的Verify 功能可以有效驗證與服務器間的連通性。當數據校驗完成后，驗證信息會提示“通過”；當無法響應遠端請求，驗證狀態則會提示黃色感嘆號，并提示驗證報錯信息，例如“目的地址不可達”或“請求超時”等提示信息，以便為排錯提供依據。當Worklist 的功能設置完畢后，需要在設備上定義Worklist 應用于患者列表中的功能配置模塊，選擇“DICOM 模塊”默認會出現“DICOM工作列表服務器”選項，下拉列表中會顯示配置的設備名稱，選擇相應的設備名稱保存即可。Worklist 配置流程圖如圖3 所示。

圖3 Worklist配置流程圖

3.3 設備調試問題及排查

實施Worklist 項目涉及到的具體問題，歸納起來可分為兩大類：一類為網絡部分的連通性問題，另一類為通訊過程中服務端儲存的日志問題。

網絡部分需要確保超聲設備與服務器處于同一網段環境，以確保消息能成功被對方接收。最佳辦法是通過PING 命令向目的地址發送因特網控制報文協議（Internet Control Message Protocol，ICMP）[10]。超聲設備若偵測到對方連接故障，在傳輸隊列中會以狀態的形式呈現，如圖4 所示。

圖4 傳輸隊列狀態圖

紅色?標識代表超聲設備與目的地址之間連通性存在故障，提示目的地址不可達；綠色標識代表超聲設備與目的地址之間連通性正常，所有測試均正常通過；黃色標識代表超聲設備與目的地址之間連通性局部正常，某些測試或存在故障。

當出現紅色標識，需要查詢DICOM 相關配置，其中包括SCP端狀態，以及AE-TiTle的一致性問題[11-13]。

當出現黃色標識，首先排除網絡環境對于通信造成的影響，然后結合狀態提示查看日志進行判斷，考慮是否因進程卡死方面的因素導致傳輸數據堵塞，是否需要清理隊列后重新傳輸文件。

同時，參考服務器記錄日志有助于分析患者數據是否有效響應與正常提取。具體排查情況如下:首先是否正常接收設備發送的請求信息，其次解析C-Find 請求是否正常，當所有環節處于正常狀態下，發送“獲取患者信息”的請求。預約系統是否能正常反饋患者數據給與Worklist 服務器端，是否正常響應C-Find 請求，超聲設備是否能正常刷新患者數據到超聲設備隊列中[14-16]。

3.4 Worklist臨床應用效果

啟用Worklist 功能后，超聲設備按照規定的時間節點刷新患者數據信息，患者只需手持預約單前往檢查室，臨床醫生通過掃碼設備掃描患者條形碼中的檢查號信息，超聲設備在Worklist 患者隊列中篩選出符合檢查號的記錄，開始檢查即可。科室通過信息化系統與Worklist 的結合，并配合條形碼識別設備，減少因人工輸入導致的數據錯誤。

研究發現，通過人工錄入患者信息時，錯誤率約為6.1%（48 800 個案例中有2 928 個錯誤）。使用Worklist 自動獲取的方式，患者數據匹配率為100%的情況下則會發生檢查患者/科研患者選擇數據錯誤，而非輸入錯誤。對Worklist 不匹配的一項統計錯誤率是0.26%（48 800 個案例中有126 個錯配），另一項研究中，對于數據源頭出現錯誤的情況（登記患者信息錯誤）進行統計檢查，患者/科研患者的錯配率為0.73%（48 800 個案例中有356 個錯配），但該數據包括所有錯誤來源，而不僅僅是Worklist 不匹配的原因。

將患者的信息完全依賴互聯網傳輸的模式形成閉環，不僅可以降低患者信息匹配錯誤率，而且為未來的科研提供了前期必要的數據支撐[17-18]。對未來依照Worklist 的患者標識進行數據歸納及大數據方向的研究提供了重要支撐。

4 結論

Worklist 是將患者信息從HIS 系統傳遞到超聲設備端的最優采集機制，但這依然無法完美地解決因醫生選擇患者的過程中出錯的問題，該功能只能最大限度地減少發生錯誤的可能性，減少醫生因數據錯誤而耗費的大量糾錯時間。所以為了減少錯誤的發生率，該研究通過控制患者預約單的模式，同時結合掃描患者條形碼ID，并自動獲取數據以執行精確模態查詢，從而提高數據的準確性，減少臨床醫生的核對工作，提高檢查效率。