背景：

        如上一篇專欄博文所描述，Worklist可以看做是PACS系統、MODALITY裝置和RIS系統之間的資訊交換。從RIS系統到MODALITY通過Worklist可以提供諸如患者個人資訊（姓名、年齡、生日等）和其他管理資料，以及提供關於成像過程和產生影象相關的一個唯一UID等資訊。基本的結構如下圖：

（具體來源不清楚了，非本人原創）

問題提出：

        上一次利用DCMTK開源庫順利的模擬了“傳送C-Find請求，查詢worklist資訊”的整個過程，通過利用DCMTK開源庫提供的wlmscpfs.exe和findscu.exe工具包，使得模擬過程簡單明瞭。此次希望通過fo-dicom（C#版的DCMTK）庫來模擬該過程。

解決方案：

1）前提條件：

        為了使得該模擬過程與上一篇博文的過程具有可比性，此次只利用fo-dicom庫來構建C#版本的傳送C-Find請求的過程，worklist服務端依然使用DCMTK提供的工具包wlmscpfs.exe。

2）利用fo-dicom傳送C-Find請求：

        具體程式碼如下，

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

using Dicom;
using Dicom.Network;
using Dicom.Log;

namespace FindSCU1
{

    class Program
    {

        static void Main(string[] args)
        {

            string id = "123456";
            var cfind = DicomCFindRequest.CreateWorklistQuery(patientId: id);
            cfind.OnResponseReceived = (DicomCFindRequest rq, DicomCFindResponse rp) =>
            {
                Console.WriteLine("********Patient Name is  {0}**********", rp.Dataset.Get<string>(DicomTag.PatientName));
             };
            var client = new DicomClient();
            client.AddRequest(cfind);
            client.Send("127.0.0.1", 104, false, "SCU-LargeV", "OFFIS");
            Console.Read();
        }
    }
}
 

3）實際測試：

        利用wlmscpfs.exe開啟worklist服務，輸入如下指令：

        >wlmscpfs.exe 104 –d –dfp d:\DcmWorklist\wlistdb 

        顯示效果如下：

        表示worklist服務端已經順利啟動……

        找到步驟2）中生成的可執行程式FindSCU1.exe，雙擊直接執行，此時服務端和客戶端的結果如下：

（客戶端） （服務端）

4）錯誤除錯：

        只是簡單的傳送了一次以PatientID為目標的worklist查詢服務，程式碼總共沒有幾行的，為什麼會出現異常呢？根據上述客戶端的異常提示，通過單步除錯，定位到首次丟擲異常的“事故點”：DicomDatasetReaderObserver.cs的OnElement

        發現該函式內部，由於無法識別VR型別為SQ的欄位，因此而丟擲了throw new DicomDataException("Unhandled VR in DICOM parser observer: {0}", vr.Code)異常。

仔細回想一下我們的程式碼在哪個位置會出現SQ型別的欄位呢？只有在CreateWorklistQuery函式中可能新增過SQ型別的欄位，進入到DicomCFindRequest.cs中的CreateWorklistQuery函式內部，發現的確有如下程式碼：

        dimse.Dataset.Add(new DicomSequence(DicomTag.ReferencedStudySequence));

        為了證實我們的猜測，此處直接將該行程式碼註釋掉，然後在fo-dicom原始碼工程中編譯DICOM工程，重新生成Dicom.dll程式集。重新編譯執行我們的測試工程FinSCU1.exe。服務端和客戶端能夠順利執行，

總結驗證：

        修改fo-dicom庫原始碼畢竟不是常規方法，在網路上搜索發現Github上有人遇到過類似的情形（https://github.com/rcd/fo-dicom/issues/62#issuecomment-46248073，如下圖）最終也是修改fo-dicom原始碼解決的。所以猜測可能是fo-dicom原始碼中的部分邏輯還沒有完善，還存在著些許漏洞。

        為了驗證是否是由於dimse.Dataset.Add(new DicomSequence(DicomTag.ReferencedStudySequence));添加了SQ格式的欄位而導致的服務端錯誤，我們利用上次建立wlistqry.wl查詢檔案的DCMTK工程，向其中寫入SQ格式的(0008,1110)DCM_ReferencedStudySequence欄位，程式碼如下：

        dataset->insertEmptyElement(DCM_ReferencedStudySequence);

        然後利用findscu.exe 來進行查詢操作，檢視worklist服務端程式wlmscpfs是否正常，驗證結果圖如下：

        由此證明，根本原因並不是由於WorklistQuery中插入了SQ格式的欄位所引起的，在此僅僅標記一下，等待後續的繼續排查和驗證。

（未完待續……）