DIY PACSサーバー

少し前に、当社は、市内の医療診断センターの1つでPACSサーバー（ Picture Archiving and Communication System ）の実装に関する作業を完了しました。 それ以前には、オープンソースのPACSサーバーであるdcm4cheeがありましたが、これはJavaで書かれているため、高速では輝きませんでした。 さらに、顧客の要件の1つは、サーバーの内部構造にアクセスできることでした。 したがって、独自に作成することにしました。 さらに、同社はPACSシステムのクライアント部分とサーバー部分の両方で同様の開発の経験があったため、妥協点は、顧客の要件を満たす独自のPACSアーカイブを作成することでした。 サーバーコアの実装のほとんどを処理する必要がありましたが、この間に特定の経験を積んだため、Habraコミュニティと共有したいと思います。 しかし、まず最初に。

前文

一般的な理解のために、診断センターにおけるPACSシステムの役割を考慮してください。 診断センターには、MRI、CTスキャナー、超音波ステーションまたはECGデバイス（DICOMプロトコルに関してこれらのデバイスのいずれかをModalityと呼びます）および診断ソフトウェア（ OsiriXが医師によって使用されました）の診断装置があります。 トモグラフで画像を受信したら、診断ステーションに送信する必要があります。 明らかに、これには、断層撮影装置、超音波ステーション、ECGデバイスから画像を収集し、それらを検索してネットワーク経由で画像を送信できる、何らかの統合リンクが必要です。 このようなリンクはPACSサーバーです：







明らかに、多様な医療機器の相互作用には単一のプロトコルが必要です。 そして、まさにそのようなプロトコルはDICOM （ 医学におけるデジタルイメージングおよび通信 ）であり、過去20年にわたって大幅に改善され、医療機器を一般的な情報システムに簡単に統合できるようになりました。 医療機器のほぼすべてのメーカーがこのプロトコルに従っています。 したがって、DICOMプロトコルのサポートは、PACSサーバーの当然の要件でした。 クラスタで動作可能なマルチスレッドの高負荷PACSを実装することが決定されました。 サーバーはC ++で開発され、C ++で記述されたDICOMプロトコルを操作するのに最も適切なライブラリである-DCMTKが今日使用されました 。 このライブラリのおかげで、負荷の高いPACS​​システムを迅速に実装することが可能になりました。

データベースを設計します

PACSシステムのデータベースを使用すると、保存された画像に関する情報を保存し、それらを検索できます。 また、画像はネットワークを介して送信できる必要があり、それを使用して画像に関するメタ情報（画像内の人物、作成されたクリニック、研究を行った人物など）が必要です。 これらの目的のために、DICOMプロトコルは特別な4レベルのデータモデルを提供します 。これについてはここで簡単に学ぶことができます 。 可能なすべてのファイル属性の完全なリストは、公式のプロトコルWebサイト[1]にあります。 異なるデバイスから取得した画像では、これらの属性のリストは異なりますが、これは完全に正常です。 ただし、ユニバーサルイメージ検索をサポートするために、一部の属性は必須のままです。 それらのいくつかがあります-患者名、患者ID、患者の誕生日、モダリティタイプ（CT、MRI、超音波など）、研究日（研究の日付）などを含む合計10があります。実践が示すように、データベース内のそれらは不要です。



画像のメタ情報に多数のオプションパラメータが存在することは、DICOMプロトコルの欠点の1つです。 一部のデバイスはいくつかのパラメーターを設定し、他のデバイスはいくつか設定します。 したがって、検索のためにデータベースでそれらをサポートすることは無意味です。 その結果、いくつかのオプションに取り組み、このDBオプションを決定しました。







ご覧のとおり、データベーススキーマはDICOMファイルのマルチレベル構造に対応しています。 1人の患者は多くの段階をとることができます（研究を読む）。 研究は、研究プロトコルで定義された一連のシリーズです。 シリーズには多くの画像が保存されています。

PACSシステムの主な機能

標準PACSシステムの主な機能（サービス）について簡単に考えてみましょう。ほとんどすべての機能については既に説明しました。 ワークステーションとPACSシステム間の相互作用はクライアントサーバーであるため、すべての操作はクライアントとサーバーの2つのバージョンでも実装されます。 DCMTKには両方のオプションが実装されています。 PACSはサーバー側を実装します。

操作の接頭辞「C-」はコンポジットを意味します。これは、操作が不可欠で自給自足であり、他の操作を参照せずに実行されることを意味します。 接頭辞が「N-」の操作（N-CREATE、N-SET、N-GETなど）もあります。これは、より一般的な操作の一部として実行されます（ステータスの設定、スタディの開始に関する通知など）。 これらの操作は、この記事には関係ありません。



C-ECHO-ネットワーク上のクライアントの可用性を確認できるコマンド。 Windowsのpingコマンドに似ています。 コマンドの実装は非常に簡単です-ステータスSTATUS_Successで応答を送信するだけです：

DIMSE_sendEchoResponse(assoc, presID, request, STATUS_Success, NULL)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、assocはクライアントによって確立された接続であり、requestは着信要求です。



C-STORE -PACSサーバーにDCM形式で画像を保存できるコマンド。

これを行うコードは次のとおりです。

 OFCondition storeSCP() { T_DIMSE_C_StoreRQ* req = &m_msg->msg.CStoreRQ; DcmDataset* dset = 0x0; OFCondition cond = DIMSE_storeProvider(m_assoc, m_presID, req, NULL, OFTrue, &dset,storeSCPCallback, 0x0, DIMSE_BLOCKING, 0); if (cond.bad()) Log::error("C-STORE provider failed. Text: %s", cond.text()); return cond; } void storeSCPCallback( void* /*callbackData*/, T_DIMSE_StoreProgress *progress, T_DIMSE_C_StoreRQ* /*request*/, char * /*imageFileName*/, DcmDataset **imageDataSet, T_DIMSE_C_StoreRSP* response, DcmDataset **statusDetail) { if (progress->state == DIMSE_StoreEnd) { if ((imageDataSet != NULL) && (*imageDataSet != NULL)) { DcmFileFormat dcmff(*imageDataSet); // some error if (!commandStore(&dcmff)) response->DimseStatus = STATUS_STORE_Refused_OutOfResources; delete *imageDataSet; *imageDataSet = 0x0; } } delete *statusDetail; *statusDetail = 0x0; } bool ServerCoreImpl::commandStore(DcmFileFormat* file) { //  // 1.  ,  ()   PATIENT, STUDY, SERIES, OBJECT. // 2.      ,      // 3.    ,        ( //  ) //   true,    ,  false }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コールバックstoreSCPCallbackは、ファイルごとではなくパッケージごとにトリガーされます。 progress->state == DIMSE_StoreEnd



条件は、ファイルのダウンロードが完了したことを示し、ファイルを保存できます。 このコマンドを実装する際の唯一の困難は、ファイルを保存するときにディレクトリ構造を選択することです。 OBJECTSテーブルにファイルパスを保存しないために、残りのデータから計算します。 次のディレクトリ構造に決めました：PATH_K_STORAGE / STUDY.DATE（YEAR）/STUDY.DATE（MONTH）/STUDY.DATE（DAY）/STUDY.TIME（HOUR）/PATIENT.PID（first letter）/ PATIENT.PID/STUDY .UID / {images}。 この階層構造により、サブフォルダーの数を最小限に抑えることができるため、タイムラグなしでこのディレクトリ構造を操作できます。



また、OBJECTテーブルには非常に集中的にデータが入力されると言いたいです。 MRIトモグラフに関する1つの研究は平均20分間続き、その間、トモグラフは100〜300枚の画像、CTトモグラフ500〜700枚の画像を生成します。 1日あたりの合計画像数は、1440/20 * 500 = 1日あたり36000画像に達します。 診断センターでは、昼夜を問わず断層撮影の作業に実質的に中断はありません。 したがって、OBJECTテーブルにはできるだけ少ないデータを格納する必要があります。



C-MOVE -PACSからワークステーションまたは診断ステーションに画像を転送できるコマンド。 このコマンドは、呼び出し元のステーション（ソース）からPACSに送信され、イメージをアップロードするステーション（宛先）を示します。 特定の場合、source = destinationの場合、ファイルは単にダウンロードされます。



C-MOVEコマンドは、イメージのダウンロードのみを許可するC-GETコマンドよりも汎用性があります。 C-MOVEは、イメージだけでなく、他のイメージもダウンロードできます。 このコマンドは、画像をアップロードするステーションのAETitleを示します。 AETitleはクライアントの名前で、通常は大文字です（CLIENT_SCUなど）。 dicom-listener（サーバー）の起動時にインストールされます。







つまり、PACSサーバーに対してC-MOVEコマンドを初期化するクライアントはmini-PACSを起動する必要があります。これにより、C-STOREコマンドのみを受信できます。 そして、PACSサーバーは、C-MOVEコマンドを使用して、クライアントとの新しい接続を確立し、ストレージから画像を取得し、C-STOREコマンドのクライアントバージョンの下部に対してクライアントに実行する必要があります。 ちなみに、C-MOVEコマンドのみが、新しい接続を確立することで圧縮画像（JPEG）と非圧縮画像の両方を転送できます。

ただし、C-GETチームは、新しい接続を確立することなく、したがってクライアント側でサーバーを上げる必要なく、イメージをダウンロードできます。 この場合、PACSは、C-GETコマンドによって確立された接続を介してのみ、C-STOREコマンドのクライアントバージョンも実行します。



C-FIND-さまざまなレベルで画像を検索できるコマンド。 つまり、実際には4つのタイプのC-FINDコマンドがあります。患者レベル、研究レベル、シリーズレベル、および画像レベルのC-FINDです。

 void HandlerFind::findSCPCallback ( /* in */ void* callbackData, OFBool cancelled, T_DIMSE_C_FindRQ* request, DcmDataset* requestIdentifiers, int responseCount, /* out */ T_DIMSE_C_FindRSP *response, DcmDataset** responseDataSet, DcmDataset** statusDetail) { //   if (cancelled) { strcpy(response->AffectedSOPClassUID, request->AffectedSOPClassUID); response->MessageIDBeingRespondedTo = request->MessageID; response->DimseStatus = STATUS_FIND_Cancel_MatchingTerminatedDueToCancelRequest; response->DataSetType = DIMSE_DATASET_NULL; return; } if (responseCount == 1) { // //       . //          requestIdentifiers // } /*         responseDataSet     */ if (/*  */) { strcpy(response->AffectedSOPClassUID, request->AffectedSOPClassUID); response->MessageIDBeingRespondedTo = request->MessageID; response->DimseStatus = STATUS_Success; response->DataSetType = DIMSE_DATASET_NULL; return; } } OFCondition HandlerFind::find() { OFCondition cond = EC_Normal; T_DIMSE_C_FindRQ *req = &m_msg->msg.CFindRQ; FindCallbackData cdata; cond = DIMSE_findProvider(m_assoc, m_presID, req, findSCPCallback, &cdata, DIMSE_BLOCKING, 0); if (cond.bad()) Log::loggerDicom.error("C-FIND provider failed. Text: %s", cond.text()); return cond; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、コールバックで、応答オブジェクト-応答パラメーターとresponseDataSet-見つける必要がある患者/ステージ/シリーズ/画像に関する情報を記入する必要があります。 DCMTKのDIMSE_findProvider（）関数は、それらをクライアントに送り返します。



C-FINDチームは、クライアントがあまりにも一般的な検索条件を指定する可能性があり、クライアントが大量の情報を提供する必要があるため、危険です。 たとえば、昨年のすべてのステージをリクエストできます。 最初にすべてのデータをサーバーにアップロードしようとすると、サーバーがハングする可能性が高くなります。 したがって、大量のリクエストを行うことはできません。コールバックがトリガーされるとデータをロードする必要があります。 これを行うには、イテレータの形式でデータベースクエリを実装し、コールバックがトリガーされたときにnext（）を呼び出して、次のオブジェクトを取得する必要があります。 さらに、検索はコールバックの到着時にのみキャンセルできるため、PACSでの検索がデータベースからのサンプルでしばらくハングし、クライアントがリクエストをキャンセルした場合、クライアントで反応は発生しません。 これは、患者とステージの検索に関連しています。 シリーズレベルの検索では、15を超えるシリーズを含むステージに遭遇したことがないため、これは無関係です。 同様に、画像レベルでの検索-1000を超える画像を含むシリーズについては、実際には見ていません。

要約する

そこで、PACSシステムの主な機能と、診断センターの全体的な構造におけるその役割を検討しました。 医療産業用PACSシステムの実装の実用的側面とさまざまな側面も強調されています。 ただし、PACSシステムは通常、この機能に限定されません。 また、PACSシステムの機能に含まれるWADOサービス（DICOMオブジェクトへのWebアクセス）および作業タスクを管理するためのサービス（モダリティワークリスト）もあります。 この記事が役に立ち、多くの時間を節約できることを願っています。

参照資料

1.すべてのDICOMタグのリスト（http://medical.nema.org/Dicom/2011/11_06pu.pdf、8ページ）。

2. DICOMプロトコルの公式ページ-medical.nema.org/standard.html

3.ロシア語のPACSシステムについて-ru.wikipedia.org/wiki/PACS

4.ロシア語のDICOMについて-ru.wikipedia.org/wiki/DICOM