(57)【要約】  病院や診療所に位置するDICOMデバイスと、外部サービスおよび検索システムとの間で転送されるデータは、４層のプロトコルに基づいてフォーマットされる。第１の層はNDMAソケットプロトコルを含む。２番目の層は、NDMAヘッダーを含み、第１の層内で入れ子にされる。３番目の層は２番目の層内で入れ子にされ、XMLテキストを含む。４番目の層は３番目の層の中で入れ子にされ、DICOM、または他のバイナリデータを含む。この多層化データ構造は、外部通信機構に結合されるべき病院の安全なネットワーク内の医療用具と相互作用するDICOMを提供する。前記外部通信機構は、病院/診療所ネットワークセキュリティの保全を維持し、強いファイヤーウォールのような保護を取り入れる一方、NDMAコンテンツを取得または保存できる。【特許請求の範囲】
【請求項１】
バイナリ画像データを発生するデバイスと、バイナリ画像データの格納のための遠隔NDMAアーカイブシステムとの間でバイナリ画像データを通信するための多層化データ構造であり、
ソケットプロトコルを備える第１の層と、
第１の層内で入れ子にされ、国家デジタル乳房撮影アーカイブ(NDMA)のヘッダーを備える第２の層と、
２番目の層内で入れ子にされ、拡張可能なマーク付け言語(XML)テキストを備える３番目の層と、および
３番目の層内で入れ子にされ、前記バイナリデータを備える４番目の層とを備えるデータ構造。
【請求項２】
前記NDMAヘッダーは、前記データ構造のバージョンを示すバージョンインジケータ、前記バイナリ画像データのタイプを示すタイプインジケータ、前記第３および第４の層のコンテンツ長を示すコンテンツ長インジケータ、およびメッセージ参照シーケンス番号の少なくとも一つの備える請求項１記載のデータ構造。
【請求項３】
前記のタイプインジケータは、前記バイナリ画像データが、医療関連データ内に、デジタルイメージングおよび通信(DICOM)、バイナリのペイロードまたはテキストを備えるかどうかのインジケータである請求項２記載のデータ構造。
【請求項４】
前記バイナリ画像データは、前記のタイプインジケータに基づき、設定される請求項２記載のデータ構造。
【請求項５】
前記メッセージ参照シーケンス番号は、前記データ構造のコンテンツが応答メッセージであるかを示す請求項２記載のデータ構造。
【請求項６】
前記NDMAヘッダーは、加算およびアップデートの少なくとも一つ、前記バージョンインジケータの少なくとも一つ、前記タイプインジケータ、前記コンテンツ長、および、前記メッセージ参照シーケンス番号に拡張できる請求項２記載のデータ構造。
【請求項７】
前記データ構造は、将来のデータプロトコルの変更のために、後方互換性を、前記バージョンインジケータを介して提供する請求項２記載のデータ構造。
【請求項８】
前記NDMAヘッダーは、それぞれのサブセクション内に、入れ子にされたコンテンツの長さを示す、前記NDMAヘッダーの各サブセクションに対する長さインジケータを備える請求項１記載のデータ構造。
【請求項９】
前記XMLテキストは、ルート設定用の情報およびアプリケーションの記載情報を備える請求項１記載のデータ構造。
【請求項１０】
前記４番目の層は、非ASCIIのエンコードされたバイナリ画像のペイロードを備える請求項１記載のデータ構造。
【請求項１１】
前記第１の層は、送信コントロールプロトコル／インターネットプロトコル(TCP/IP)と互換性がある請求項１記載のデータ構造。
【請求項１２】
前記第１の層は、ヘッダーおよびプロトコル応答の少なくとも一つを備える送信コントロールプロトコル／インターネットプロトコル(TCP/IP)と互換性がある請求項１記載のデータ構造。
【請求項１３】
前記NDMAヘッダーは、前記データ構造がいかにして処理されるべきか、および、前記データ構造がいかにしてルート処理されるべきかの少なくとも一つを示すタイプインジケータを備える請求項１記載のデータ構造。
【請求項１４】
前記NDMAヘッダーは、前記XMLテキストの選択された部分を備える請求項１記載のデータ構造。
【請求項１５】
前記選択された部分は、ルート情報、時間情報、識別情報、抽出DICOM関連情報、およびバイナリデータの少なくとも一つを備える請求項１４記載のデータ構造。
【請求項１６】
前記バイナリ画像データは、非エンコードのテキストおよびバイナリ画像データをそこに持つメッセージを備える請求項１記載のデータ構造。
【請求項１７】
前記バイナリ画像データは、医療でのデジタルイメージングおよび通信(DICOM)画像データおよびDICOM構造の報告データの少なくとも一つを備える請求項１記載のデータ構造。
【請求項１８】
医療でのデジタルのイメージングおよび通信(DICOM)の互換性デバイスと、格納デバイスとの間でバイナリの画像データを転送するための方法であり、
ソケットを開け、そして続いて総数のバイトを示すソケットプロトコルヘッダーを送るステップと、
コンテンツタイプ XMLのために、各々がバージョンおよび長さの修飾子 (specifier) を含む、第１のNDMAヘッダーを送るステップと、
メッセージ識別子、要求された動作、および送信機および受信機の識別子を含むXMLメッセージを送るステップと、
コンテンツタイプのバイナリ画像データに対する第２のNDMAヘッダーを送るステップと、および
バイナリ画像データを含むバイナリのペイロードを送るステップとを備える方法。
【請求項１９】
前記ソケットプロトコルヘッダーに記述された合計のバイト数が送信されるまで、NDMAヘッダーおよび関連したコンテンツを送信するステップを備える請求項１８記載の方法。
【請求項２０】
前記送信機および受信機の記載は、前記バイナリ画像データの送信機および受信機の少なくとも一つで、証明するための証明データを含む請求項１８記載の方法。
【請求項２１】
XMLメッセージは、そのXMLメッセージに従うバイナリのペイロード内のバイナリの画像データに関係したデータを含み、前記バイナリ画像データに関係した前記データをソフトウエアアプリケーション処理するステップを備える請求項１８記載の方法。
【請求項２２】
前記バージョン指定子は、将来のデータプロトコル変更のために、後方互換性を許可する請求項１８記載の方法。
【請求項２３】
応答承認のためのバイナリのペイロードを除く、応答メッセージ識別子、要求された動作および、送信機および受信機の記載を含むXMLメッセージを送信するステップを更に備える請求項１８記載の方法。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
[関連出願へのクロス文献]
本願は、2003年6月4日にファイルされた米国仮出願 No. 60/475,940の「NDMAソケット転送プロトコル」に優先権を主張するものであり、その全体をここに引用する。ここで開示された内容は、米国特許出願シリアル番号(それと同日にファイルされた代理人事件 UPN-43 80/P3 179、“CROSS-ENTERPRISE WALLPLUG FOR CONNECTING INTERNAL HOSPITAL/CLINIC IMAGlNG SYSTEMS TO EXTERNAL STORAGE AND RETRIEVAL SYSTEMS”)で開示された内容に関連し、その全体を参考のために引用する。ここで開示された内容は、米国特許出願シリアル番号(それと同日にファイルされた代理人事件 UPN-43 2/P3189、“NDMA SCALABLE ARCHIVE HARDWARE/SOFTWARE ARCHITECTURE FOR LOAD BALANCING, INDEPENDENT PROCESSING, AND QUERYING OF RECORDS”)で開示された内容に関連し、その全体を参考のために引用する。ここで開示された内容は、米国特許出願シリアル番号(それと同日にファイルされた代理人事件 UPN-4383/P3190、“NDMA DATABASE SCHEMA, DICOM TO RELATIONAL SCHEMA TRANSLATION, AND XML TO SQL QUERY TRANSLATION”)で開示された内容に関連し、その全体を参考のために引用する。
【０００２】
[発明の分野]
一般に、この発明は、データを医療施設と外部サービスの間で転送するための多層化のデータ構造に関し、より特に、データをDICOMかHL7の互換性のイメージシステムと、NDMA互換性の格納システムの間で転送するための4層入れ子構造に関する。
【０００３】
[発明の背景]
デジタル乳房撮影データを保存するために以前のシステムは、デジタルデータのフィルムコピーを作り、そのコピーを格納しそして、元のデータを破棄することを含む。情報の分配は、コピーされたエックス線のコピーを提供することに基本的に相当する。このアプローチは、デジタルデータ自体を保存して、転送することの困難のために、しばしば採用阿された。デジタル医療イメージソースの導入および、それらの取得後にこれらの画像を処理する際のコンピュータの使用は、医療画像およびそれらの関連した情報の転送のための標準方法を作成する試みにつながった。確立した規格は、医療規格におけるデジタルイメージングおよび通信(DICOM)で公知である。DICOM規格への承諾は、他の病院か診療所居住者デバイスとの接続のための複数業者のサポートを必要とする医療用具に対して重要である。
【０００４】
DICOM規格は、多業者環境における、医療画像の転送を可能にするため、および、画像格納および通信系の開発と拡張を容易にして、そして医療情報システムに接続するためのプロトコルを説明する。(すべてでなければ)多くの一流の診断医療画像処理業者が、DICOM規格を彼らの生産設計に組み入れると予想される。また、DICOMが健康産業の中で画像を利用する仮想のあらゆる医療の職業で使用されると予想される。 例として、心臓病学、歯医者、内視鏡検査、乳房撮影、眼科、整形外科、病理学、小児科、放射線治療、放射線学、外科、および獣医の医療画像処理の適用を含む。したがって、DICOM規格の利用は、乳房撮影に加えて、これらの分野からの記録の通信および格納を容易にするであろう。したがって、病院内装置と、ネットワークを通じて取得される外部サービスとの間でインターフェースするために、および、情報の転送のみならず、サービスを提供する一般の方法が望まれている。また、そのような方法が、異なったプロバイダーから随意の時刻に、医療ケアーを習得する可動の人口を支持するために、アクセスされた記録の適切な追跡でもって、記録するために、企業の安全なクロスするアクセスを可能にすることが望まれている。
【０００５】
多くのユーザにとって、画像データが利用可能であるように、アーカイブ(記録)は適切である。開発されたアーカイブは、デジタル乳房撮影データを保存する 国家デジタル乳房撮影(Mammnography) アーカイブ (NDMA)である。そのNDMAは、患者の健康と医療記録につながった画像、レポート、および他のすべての関連情報のための流動的なリソースとして活動する。また、NDMAは、現在および以前の年の研究に対する倉庫であり、そして、臨床と研究使用にサービスと適用を提供する。そのような国家の胸部画像アーカイブの開発は、北アメリカで乳癌探求プログラムを大きく変革するかもしれない。患者のプライバシーは関心事である。したがって、NDMAは、患者のプライバシーと秘密性を確実にし、そして、すべての関連する連邦規定で、柔軟性がある。
【０００６】
この画像データへの分配、およびそれへのアクセスを容易にするために、DICOM互換性システムはNDMAと結合されるべきである。多くのユーザに届けるために、インターネットは適切なものに見えるであろうが、そのインターネットは、DICOMで利用されたプロトコルを扱うように設計されていない。したがって、NDMAは、記録のためにDICOMフォーマットをサポートし、かつ、病院内のあるDICOM相互作用をサポートするが、NDMAは、ファイル転送と操作にそれ自身のプロトコルと手順を用いる。
【０００７】
したがって、プライバシーとセキュリティを提供する方法で、DICOM側で操作を妨げない方法で、外部のネットワーク(NDMA)側で暗号化を提供する方法で、強力な認証と外部の管理を提供する方法で、および、効率的に多量のデータをDICOMシステムとNDMAとの間に転送できる方法で、DICOM互換性システムをNDMAに結合するメカニズムのための必要性が存在する。
【０００８】
[発明の概要]
病院か診療所に位置するDICOM互換性デバイスと、外部のNDMA互換性ストレージおよび情報検索システムとの間で転送されるデータは、４層化のソケットプロトコル(データ構造)によりフォーマットされる。この多層化のデータ構造の第１の層は、NDMAソケットプロトコルを含む。２番目の層は、第１の層の中で入れ子にされ、かつNDMAヘッダーを含む。３番目の層は、２番目の層の中で入れ子にされて、かつXMLテキストを含む。４番目の層は、３番目の層の中で入れ子にされて、かつ、DICOM、または他の２進の関連するデータを含む。この多層化データ構造は、NDMAコンテンツを取得するか格納できる外部通信機構に接続されるべき病院のソースネットワーク内の医療装置と相互作用するDICOMを提供し、他方、病院／診療所のネットワークセキュリティの保全を維持し、また、ファイヤーウォールのような強力な保護を備える。
【０００９】
多層化ソケットプロトコルは、患者のプライバシーを保護するためにすべての外部のトラフィックの暗号化をサポートし、外部のネットワークを通して転送された医療記録の暗号化を含む。病院の私設のネットワーク内でセキュリティを維持するために、すべての管理機能および通信デバイスとの接続を保証する。これは安全で、保護されたウェブインタフェースで達成される。ウェブインタフェースは、スマートカードおよびセキュリティ証明書を通じた強い認証の使用をサポートする。
【００１０】
この発明の例示的な実施例では、２値画像データを生成するデバイスと、その２値データの格納のための遠隔NDMA保存システムとの間でバイナリ(２値)画像データを通信するための多層のデータ構造は、４層を含む。第１の層はソケットプロトコルを含む。２番目の層は、第１の層内で入れ子にされて、国家デジタル乳房撮影アーカイブ(NDMA)のヘッダーを含む。３目の層は、２番目の層内で入れ子にされて、拡張可能なマーク付け言語(XML)テキストを含む。４番目の層は、３番目の層内で入れ子にされて、２値画像データを含む。
【００１１】
また、この発明は、医療でのデジタルのイメージングおよび通信(DICOM)の互換性デバイスと、格納デバイスとの(いずれか１方向)間でバイナリ画像データを転送するための方法を含む。例示的な実施例では、２値画像データは、DICOMの関連するデータか２進のペイロードのどちらかを備える。この発明に基づくそのような方法は、
ソケットを開け、そして続いて総数のバイトを示すソケットプロトコルヘッダーを送るステップと、
コンテンツタイプ XMLのために、各々がバージョンおよび長さの修飾子 (specifier) を含む、第１のNDMAヘッダーを送るステップと、
メッセージ識別子、要求された動作、および送信機および受信機の識別子を含むXMLメッセージを送るステップと、
コンテンツタイプのバイナリ画像データに対する第２のNDMAヘッダーを送るステップと、および
バイナリ画像データを含むバイナリのペイロードを送るステップとを備える。
【００１２】
この発明の他の特徴および利点は、以下の詳細な記述から明白になるであろう。
【００１３】
[発明の実施例の説明]
図１は、複数層化のソケットプロトコルを実施するためのこの発明に基づくシステムを示す。その発明によれば、多層化のソケットプロトコルは、ウォールプラグ(WallPlug)１２および NDMA１６との間で情報を転送するために使用される。そのNDMA１６は、医療画像および記録ファイルの待ち行列(queue)を送信するために、送信機のプロセス(MAQ)および受信機のプロセス(MAQRec)の間でソケットプロトコルを使用する。双方のプロセスは、マルチスレッド(スレッドと呼ばれる処理単位を複数生成し並行して複数の処理を行なう)であり、そして、大規模な誤り取り扱いおよび回復を与える。送信機のプロセスは、それの入力待ち行列でのファイルのスケジュール化およびバッチ(一括)処理を扱う。各送信機は、特定の入力待ち行列、ソケットポート数および、目的のIPアドレスを持つ。受信機は、ソケットポート数および、出力待ち行列のディレクトリイを持つ。一つの実施例では、多層化のソケットプロトコルは、情報転送に依存しないマシンのオペレーションシステムを与えるオペレーションシステムであるのWINDOWS(登録商標)およびLINUX(登録商標)/UNIX(登録商標)での使用に互換性がある。
【００１４】
図１は、この発明のプロトコルを実施するシステムの実施例に基づく、ファイヤーウォール化された病院システムに結合された、およびアーカイブおよび回復のシステムのアーカイブフロントエンドに結合されたウォールプラグ１２の簡略化したブロック図である。多層化のソケットプロトコルは、仮想のプライベートネットワーク(VPN) ２０ または２４を通じて、ウォールプラグ１２とNDMA１６との間で情報を転送するために使用される。ウォールプラグ１２は、TCPIP互換性ネットワーク１８を通じてファイヤーウォール化された病院システム１４に結合される。そのネットワーク１８は、DICOM互換性ネットワーク、HL7互換性ネットワーク、インターネットまたはウェブの互換性ネットワーク、または同種のようないずれかの適したTCPIP互換性ネットワークである。VPN互換性ネットワーク２０または２４は、いずれかの適したVPNであってもよい。
【００１５】
そのネットワーク１８は、ウォールプラグ１２内のサーバの結合を通じて、イネーブルにされた病院／診療所の医療デバイス、スマートカードまたは証明イネーブル化システムから、DICOM、HL7のような仮想の保護されたアクセスおよび／またはウェブアクセスを与える。そのウォールプラグ１２は、テスト記録、患者記録、管理制御または、それらの結合へ保護されたアクセスを与える。そのウォールプラグ１２は、病院側に安全なウェブユーザインターフェースおよび、DICOM病院器具インターフェースを示し、そして、VPN側にアーカイブへの安全な接続を与える。そのウォールプラグ１２は、接続された病院システムの外部接続について仮定を作らず、そして、VPN２０以外の接続なしで動作できる一つの実施例では、ウォールプラグ１２は、通信の冗長、ハードウエアテストおよび／または故障時の管理を与えるために、第２のVPN２４への外部接続を備える。
【００１６】
図２は、ウォールプラグ１２のブロック図を示し、この発明のプロトコルを実施するシステムの実施例に基づき、DICOM互換性ネットワーク１４に結合された第１のポータルシステム(ポータル)２８および、仮想のプライベートネットワーク２０に結合された第２のポータル３０を備える。病院のデバイスにNDMA互換性がない場合、ウォールプラグのポータル２８と病院システム１４を除いて、多層化のソケットプロトコルがいたる所で実装される。２つのポータル２８、３０は、プライベートの安全なネットワーク３２を通して互いに結合される。ウォールプラグ１２は、オンサイトの病院/診療所の医療インターフェースを、外部のサービスおよびシステムに提供する。一般に、２つの隔離されたプロセッサユニットを持つサーバまたは特定のハードウェアのどのようなペアからもウォールプラグ１２を組み立てることができる。例示的な構成では、各ポータルは、IBMサーバを備えてもよく、各ポータルは、２個のCPU、２つの冗長電源、および管理インターフェースを持つ。２つの管理インターフェースを、外部から２台のシステムをモニターするために使用できるASM(システム管理デバイス)に共に結合することができる。ポータル２８、３０は、必ずしも同じオペレーティングシステム下で作動する必要があるわけではない。例えば、図２で示された例示的な記述は、ポータル２８がウィンドウズ（登録商標） R2000下で動作し、ポータル３０はリナックスR下で動作する。ポータル２８、３０が、オペレーティングシステムの他の組み合わせ(同じオペレーティングシステムを含む)で動作することができて、そして図２で示された例示的なオペレーティングシステムに限定されるべきでないのが理解されるべきである。そのポータル２８、３０は、病院システム１４と、分配されたストレージと、検索サービスシステム１６との間で唯一のハードウェアインターフェースである。そのポータル２８、３０は、容易に配置され、維持され、そして、病院システム１４と、アーカイブシステム１６の間に安全な暗号化されたリンクを提供する。
【００１７】
図３は、この発明のプロトコルを実施するシステムの例示的な実施例に従って、テスト記録および患者記録のために用いられるソフトウェアとハードウェアを示すウォールプラグ１２のブロック図である。多層化のソケットプロトコルは、図３で示した様々なソフトウェアコンポーネントの間で、内部的に情報を転送するために使用される。データは、病院１４とアーカイブ１６の間を流れ、またリターンする。実行は、重要なトラフィック管理、ログ管理者およびスケジューラであるマップ４６に沿って、一般化された送信機および受信機を利用する。MAQ５２は、ワークリストからファイルを取り、そしてそれらを受信者に送る送信機である。他方は、MAQRec５４は、ファイルを受け取り、それらを待ち行列に置く受信機である。双方のプロセスは、すべての動作を、例えば監査ログ５７にログインし、そしてNDMAプロトコルを使用する。
【００１８】
図３に示されるように、病院側の上のポータルソフトウェアは、DICOMサーバ３８を実行することに、および、DICOMサーバ３８から、ウォールプラグ１２の２つの部分にリンクするプライベートネットワーク３２へファイルを転送するに責任を負う。これを行うソフトウェアは、DICOMサーバ３８にインターフェースするMAPと呼ばれるソフトウェアを含み、また、DICOMテストおよび診断ソフトウェア、入力MASおよびディレクトリイ４４内の新しいファイルを監視する待ち行列マネージャ、および、クロスオーバーケーブル３２上でソケットを通じてファイルをバックエンド(後処理系)ポータル３０へ転送するための機構を含む。それぞれのポータル２８、３０のファイルを移動するか、または操作するすべての活動は、２つのデータベース(動作上のメッセージのためのものと、すべてのファイルの移動を監査するもの)にログインされる。後者は、HIPAA(医療保険の携行と責任に関する法律)コンプライアンスに必要であり、双方は、定期的にアーカイブ１６に送って、マスターデータベースに入れられる。データベース６１は、ポータル２８のためのすべてのデータベースを、そして、データベース５７はポータル３０のためのすべてのデータベースを表す。待ち行列ソフトウェアは、誤りを検出して、必要に応じて次のステージに送信を再試行するであろう。たとえ下流の要素が一時的に動作不能になっても、何日も自動動作を許可するために、システム上で十分なローカルキャッシュを実装することができる。
【００１９】
また、ポータル２８のソフトウェアは、病院へ戻す記録の転送を支援する。プライベートケーブル上で実行するソケットプロトコル(WMAQRec 60)を用いたアプリケーションは、バックエンドのポータル３０からファイルを受け取り、そしてそれらをMArecvディレクトリイ６２に格納する。このMAP４６のソフトウェア受信機の要素は、これらのファイルを転送し、そしてDICOM サーバ３８を通じてCMOVE ７６を用いて、確かめられた位置へ記録する。 一方、プロトコルを通してファイルのすべての移動が登録され、そして、定期的にその記録はアーカイブ１６に転送される。
【００２０】
すべての送信機と受信機は、すべての処理、誤り、およびファイルの移動の広範囲なログを提供する。外部からログファイルの位置を指定することができる。すべてのログファイルは、レベル０(概要と誤りの記録専用)からより高い整数値までの出力の複数のレベルを、イネーブル／ディセーブルにするために用いることができる。誤り出力は、デバッグレベル、タイムスタンプ、プロセス識別子、概要状態インジケータ、および誤り詳細メッセージを含むように標準化される。すべての誤りと状態ログは、平坦なファイルとしてそれらをデータベースにインポートするのを簡単にするデリミタでフォーマットされる。
【００２１】
送信機と受信機は、待ち行列、ポート、および具体化で外部的に指定することができる入力/出力の目的地によって制御される。その結果、複数の送信機/受信機を複数のポート/目的地と定義することができる。同じ送付機・受信機の組は、マシンからマシンへ、単一のマシン内で待ち行列から待ち行列へ、または、マシンの一つの収集から他のものへデータを転送するために用いられる。このように、この発明の多層化のソケットプロトコルは、内部の、または、外部のネットワークであるか否かに関係なく、マシン間またはマシンのクラスタ間での外部通信だけでなく、内部通信もサポートする。ログはプロセスのすべてのために集められる。それぞれの転送ソケットは、大きい２進の記録のために最適化される。ソケットプロトコルを通して送られた情報は、能率を増進するために含まれた記録およびヘッダーに関するXML情報を含む。
【００２２】
多層化のソケットプロトコルは、XMLストリームの中でバイナリとテキストオブジェクトの同時の転送、メッセージパラメータを指定し、そして、任意に２進のコンテンツアイテムの概要を含むためにXMLの使用、バージョン識別(プロトコルのバージョンの表示)のためのヘッダー、(アプリケーションルーティングのための)メッセージタイプの指示、メッセージ長の指示、および、状況の情報のための応答パケットを提供する。その全体は、大きい記録および大きい遅延帯域幅の製品のために最適化された、標準のTCP/IPソケット上で実施される。また、多層化のソケットプロトコルは、情報の１つの位置からもう１つの位置への待ち行列の転送に対して、フレキシブルなメカニズムを提供し、終点を認証するセキュリティトークンを実行する能力を含む。
【００２３】
図４は、この発明の実施例に基づく、多層化NDMAソケット転送データ構造(プロトコル)の４つの層６６、６８、７０、７２を示す図である。多層化ソケットプロトコルは、ソケットによって結合された送信機と受信機の組みを実行する。すべてのプロセスはマルチスレッド化される。(つまり、同時に複数の記録を処理することができる。) すべてのプロセスは、容易にデータベースにインポートされる標準のログを作成する。多層化のソケットプロトコルは、送信機および受信機を認証するセキュリティトークンを果たすことを備える。
【００２４】
例証されるように、多層化ソケットプロトコルは４つの層、ソケット層６６、NDMA ヘッダー層６８, XML 層７０, およびバイナリ記録転送層７２を備える。ソケット層６６は後方互換性のためのバージョン管理、追跡のためのメッセージIDS、および、状態検証を送受信するための応答をサポートする。また、ソケット層６６は、メッセージタイプおよびコンテンツの迅速なルーティングのためのメッセージタイプ指示子を提供する。NDMA ヘッダー層６８は、メッセージ内で、テキストと２進のコンポーネントの両方の転送をサポートする。テキストヘッダーと２進のペイロードがあるMMEのような構造は、各メッセージに含まれる。XML層７０は、送信機及び受信機の情報および認可、情報長、およびタイムスタンプを担う。XML層７０は、ウォールプラグ１２上で構成された２進のペイロードからの解読された重要なデータを含む。この情報は、DICOMペイロード７２で解っているような、大きくて複雑な２進のペイロードの手間がかかり、および/または、反復性の解読を回避して、より迅速なデータの使用を許可する。エンディアンネス（Endianness:メモリ上でのバイトの並び）を検出するためにヘッダー構造を使用することができる(すなわち、送信の最上位ビットが１番目か最後であるかにかかわらず)。XMLメッセージ構造は、広範囲の機能をサポートし、拡張可能でうる。 XMLメッセージ構造は、他のメッセージ機能の実行を検証するために使用できる回答構造をサポートする。
【００２５】
図４で例証されるように、転送プロトコルの構造は、入れ子にされた層を備える。標準のTCPIPソケットは、ファイヤーウォール規則で許容された予め承認された組みのポートから選択されたポートを有する最上層６６で使用される。標準のTCPIPソケットは、NDMA ヘッダヘ６８を担う。このNDMAヘッダー６８は、続くメッセージ長さ、およびメッセージタイプを指定する。メッセージタイプは、メッセージがデータに関するDICOMを含むか、または２進のペイロードを含むかを示す。メッセージタイプのインジケータを導入することによって、XMLの２進のペイロードに替えてDICOMデータが送信されてもよい。受信されると、メッセージタイプのインジケータは、ペイロードがDICOM、他の２値画像データまたは従来のテキストペイロードを含むかどうか決定するためにチェックされる。また、NDMAヘッダー６８は、それぞれのサブセクション内で入れ子にされたコンテンツの長さを示すNDMAヘッダー６８の各サブセクションのための長さインジケータを含むことができ、ペイロードのタイプに依存して、入れ子にされたDICOMまたはバイナリ画像データまたはテキストデータのサイズを含む。メッセージタイプは、完全なメッセージを分析することなくコンテンツタイプを特定するために使用され、そして、メッセージの迅速なルーティングのためにアプリケーション内で使用される。また、プロトコルが後方互換性を提供するように、NDMAヘッダー６８はバージョン番号を指定する。また、NDMAヘッダー６８はメッセージ参照シーケンス番号を含む。現在のメッセージを先のメッセージ、または複数のメッセージに関連づけるためにメッセージ参照シーケンス番号を使用することができる。
これは、例えば、現在のメッセージが先のメッセージへの応答かそれとも認識であるかを示すために用いることができる。そのNDMAヘッダー６８は拡張可能である。例えば、長さインジケータ、メッセージタイプ、および/または、バージョンインジケータを加える、および/または、アップデートするために、NDMAヘッダー68を拡張できる。
【００２６】
NDMAヘッダー６８には、XML層７０が続く。このXML層７０は、特定のメッセージに関するより詳細な情報を含み、また、続くためにDICOMか他の２進のパケット７２から抽出された情報を含むかもしれない。これは、２進のペイロードからアプリケーションで必要である重要情報を抽出するために、および、各アプリケーションの中で完全な２進の構造を解読することを避けるために、実行される。また、そのXML層７０は、送信機および受信機の情報、元の識別子のポイント、タイムスタンプ、および証明書を担う。そのXML層70は、柔軟に追加できる仮想のエンベロープを形成し、役に立つ情報をルーティングアプリケーション、または、終点アプリケーションに提供する。
【００２７】
そのXML層７０は、「ペイロード」インジケータで終わる。メッセージの残りは、２進であると仮定される。テキストヘッダーと２進のペイロードがあるこのMIMEのような構造は、非常に効率が悪く、メッセージを長くする、ASCIIエンコードのバイナリデータを持つことなく、多層化プロトコルが、テキストと２進の情報の両方を通過することを許可する。また、バックエンドへの変更なしで病院/診療所の中に２進のペイロード７２が存在するとき、その構造は、２進のペイロード７２(典型的に２進のDICOM画像フォーマットまたは２進のDICOM構造化報告であるが、いずれの２進のペイロードより更に一般的である)がビットごとに通過するのを許容する。また、この発明の多層化のソケットプロトコルは、２進のパケットが決して変更されないタンパー証拠検証に使用されるべきであるハッシュ(意味のない不要データ)を含むかもしれない。プロトコル受信機/送信機は、ASCnとバイナリのエンコード方法の間で自動スイッチングを実施する。ペイロードのセクション７２は、２進のパケットを持たないメッセージ構造に対してゼロ長のものである。便宜上、NDMAヘッダー構造６８は、２進の情報の前部で繰り返される。多層化ソケットプロトコルの長さインジケータは、受信機が効率的に記述され、そして送信のそれぞれの部分の完成のために、迅速にテストできるのを許容する。
【００２８】
例示的な具体化では、この発明の多層化のソケットプロトコルは、受信機が、受信の終わりで、送信の状況(成功／失敗)および格納を示す１２バイトの応答の送信を必要とする。使用されるソケットポート番号は、通常、5000-5010と6000-6010であるが、許可されたいずれのポート上でもプロトコルを使用することができる。
【００２９】
ソケットプロトコルヘッダー６６の例
２バイト バージョン番号
２バイト メッセージタイプ
２バイト予約
４バイトのコンテンツ長 
４バイトメッセージID
【００３０】
XML セグメントのためのNDMAヘッダー構造６８ヘッダーの例
NDMNA/バージョン: 1.0 
コンテンツタイプ: XML 
コンテンツ長: 761 
XMLテキストは、ペイロードのタグを含む７６１バイトの長さを伴う。
NDMA/バージョン: 1.0 
コンテンツタイプ: Image 
コンテンツ長: 8788864 
(バイナリのコンテンツは、8788864バイト長を伴う )
【００３１】
図５と６は、NDMAアーカイブシステムのバックエンドシステムの図であり、それぞれNDMAアーカイブシステムの概要と基本的な部品について示す。多層化のソケットプロトコルは、図５と６での矢印によって示されたすべての情報転送に使用され、典型的には、内部のネットワークの別々のマシン間での情報転送に使用される。ここでの図５と６でより良い理解のために、関連した出願(本出願と同日に提出された米国弁護士側管理番号 UPN-4382/P3189、件名“NDMA SCALABLE ARCHIVE HARDWARE/SOFTWARE ARCHITECTURE FOR LOAD BALANCING, INDEPENDENT PROCESSING, AND QUERYlNG OF RECORDS”)を参照されたい。その開示は参考のためにその全体がここに取り込まれる。
【００３２】
多層化のソケットプロトコルの３つの特徴は、バックエンドシステムに、特定のデータタイプを扱うための処理または待ち行列に対し、異なるタイプの情報を迅速かつ容易にルート処理することを許可する。まず最初に、どんなプロトコルにも準備されたソケット番号を使用することができ、そして、受信機は、ユニークなポート番号を持つソケットに接続することができる。２番目に、あるタイプに関する記録のための特別な処理の引き金となるように、単一のポート上で到着する異なったタイプのトラフィックを切り離すために、プロトコルのメッセージタイプ識別子の情報を使用することができる。最後に、２進のオブジェクトからの情報が必要であるとき、しかし、そのオブジェクト自身を解読するのに時間を浪費するか、不都合なときはいつでも、オリジナルのDICOMまたは他の２進のオブジェクト７２から抽出され、かつ、プロトコルのXMLセクション７０に位置したXMLコンテンツを使用することができる。
【００３３】
一つの実施例では、タイプ指示子には、以下の機能を持つ。
タイプ 0   病歴のための質問
タイプ 1   質問への応答
タイプ 2   画像要求を格納
タイプ 3   HIPPA 検査格納要求
タイプ 4   調査記録について質問
タイプ 5   画像所有者ノードへの先の質問結果
タイプ 6   調査画像および病院情報をフェッチ
【００３４】
ソケットの例は以下を含む。
5004  バックエンドへの格納要求を送信
5005  バックエンドへの質問、バックエンドへの先の要求のルート化
5006  バックエンドへ検査記録の送信
5007  ポータルから受信、バックアップへの送信、応答のための受信
5008  質問から応答を受信
6007-8  テストおよび鼓動の記録
【００３５】
XML構造の例
<?xml version="1.0" encoding "UTF-8" ?> 
< Message type = "StoreImage" > 
<MessageID> 
<0riginalIP> 130.91.51.20</OriginalIP> 
<Timestamp> 5/ 12/ 2003 9:00:01 AM </Timestamp> 
<MessageNum>-13432</MessageNum> 
</MessageID> 
<Request action="Store" type="Image"> 
<ID>-13432</ID> 
< Priority> Routine </Priority> 
</Request> 
<Sender>
< Certificate > BB9118189xxxxxxxxx92D985DEB7C29 </Certif icate > 
<Requestor> 
<Facility>NSCP</Facility>
<ID>NSCP-60O7</ID> 
</Requestor> 
</Sender>
< Receiver> 
<Certificate>BB9118189xxxxxxxxx92D985DEB7C29</Certificate> 
<IP>130.91.51.20</IP> 
</Receiver> 
< Payload > 
<Record type="Image" format="DICOM"> 
<Item>
< Name > patientID </Name> 
<Value> pid_745566</Value> 
</Item>
<Item > 
<Name>NamePatientFull</Name> 
<Value>dummy_745566</Value> 
</Item > 
</Record >
</Payload>
</Message> 
【００３６】
NDMA ヘッダーおよび、XML およびバイナリデータの双方を有するメッセージの例
NDM/VERSION: 1.0 
CONTENT-TYPE: XML 
CONTENT-LENGTH: 761 
<?xml version=" 1.0" encoding="UTF-8"?> 
<Message type="StoreImage">
<MessageID>
<0riginalIP> 192. 168 .201.1 </OriginalIP>
<Timestamp>1052162767</Timestamp>
<MessageNum>9953</MessageNum>
</MessagelD>
<Sender>
<Certificate>F966175489xxxxxxxx38F37112E3</Certificate>
<Requestor>
<Facility>0RDEV</Facility>
<ID>IP 134167143162</ID>
</Requestor>
</Sender>
<Receiver>
<Certificate>0CF4AD709xxxxxxxxxxxBOBF8C4</Certificate>
<Ip> 130.91.50.151 </Ip>
</Receiver> 
<Request action="Store" type="Image">
<ID>9953</ID>
<Priority>LOW</Priority>
</Request>
<Payload>
<Record type="Image" format="DICOM">
<Item>
<Name>patientID</Name>
<Value>99990032</Value> 
</Item>
<Item>
<Name>NamePatientFull</Name>
<Value>xxxxx^xxxxx</Value>
</Item>
</Record>
</Payload>
</Message>
NDMA/VERSION: 1.0 
CONTENT-TYPE: Image 
CONTENT-LENGTH: 8788864
(バイナリコンテンツ長は8788864バイトになる)
【００３７】
アプリケーション層ヘッダー
ソケットヘッダー６６フォーマットの例
【００３８】
【表１】
2007520761.tif 000002
【００３９】
ソケットのメッセージタイプ
病気の質問              0 
応答                    1 
画像格納                2 
検査格納                3 
検査質問                4 
CADを要求               6 
認証要求                7
承認リストの格納        8
認識                    100
否定の認識              101
DSRNMD格納              501
DSRMMM格納              502
DSRANNOT格納            503
調査のフェッチ          901
診断をフェッチ          902
【００４０】
NDMAヘッダー６８フォーマットの例
NDMA/バージョン : 1.0
コンテンツタイプ : XML
コンテンツ長 : nnnnn 
【００４１】
NDMA XML７０．７２メッセージ構造の例
次の表２およびその続きの表３は、メッセージおよびそのメッセージの詳細を掲載する。
【００４２】
【表２】
2007520761.tif 000003
【００４３】
【表３】
2007520761.tif 000004
【００４４】
この発明に基づく多層化のNDMAソケット転送プロトコルは、入院記録に対する内部企業、および/または、相互の企業のデータ交換を可能にする。多層化のNDMAソケット転送プロトコルは、記録の転送、格納、検索、および処理のために病院内での異種、多くのベンダー、地理的に分配された異種のハードウェアシステムの相互作用を可能にする。特に、多層化のNDMAソケット転送プロトコルは、ウォールプラグタイプのデバイスを、NDMAアーカイブシステムソースにリンクする。
【００４５】
また、多層化のNDMAソケット転送プロトコルは、内部のアーカイブ通信をリンクする。したがって、アーカイブ動作は、地理的に分配され、多相系の上で実行することができるか、または単一のコンピュータ、またはコンピュータの集合で実行することができる。
【００４６】
この場所にある特定の具体化に関して例証されて、説明されますが、それにもかかわらず、現在の発明によって示された詳細に制限されるのは意図されません。
【００４７】
ここではある特定の具体化に関して図示して説明したが、この発明に示された詳細に限定されることに意図されない。むしろこの発明からそれることなく、クレームの等価な趣旨及び範囲内で種々の変形が作成できる。
【図面の簡単な説明】
【００４８】
【図１】DICOM 互換性ネットワークを通じてウォールプラグに結合されるファイオウォール処理の病院システムのブロック図
【図２】この発明を実施するシステムの実施例に基づく、DICOM 互換性ネットワークに結合された第１のポータル、仮想のプライベートのネットワークに結合される第２のポータル、および、プライベートのソースネットワークを通じて相互に結合された２つのポータルを備えるウォールプラグを示すブロック図
【図３】この発明を実施するシステムの実施例に基づく、ソフトウェアおよびハードウェアを示すウォールプラグのより詳細なブロック図
【図４】この発明の実施例に基づく、国家デジタル乳房撮影アーカイブの４つの入れ子にされた層の図
【図５】この発明を実施するシステムの実施例に基づく、ウォールプラグへ、およびそこへデータを転送するために使用される国家デジタル乳房撮影アーカイブでのソフトウェア要素のブロック図
【図６】この発明の実施例に基づくNDMAシステムのブロック図
【符号の説明】
【００４９】
１２：ウォールプラグ(WallPlug)
１６：検索サービスシステム
１８：NDMA 16TCPIP互換性ネットワーク
２０：VPN
２８：ポータル
３０：ポータル
３８：DICOMサーバ
４６：マップ
【図１】
2007520761.tif 000005
【図２】
2007520761.tif 000006
【図３】
2007520761.tif 000007
【図４】
2007520761.tif 000008
【図５】
2007520761.tif 000009
【図６】
2007520761.tif 000010
【手続補正書】
【提出日】平成18年9月27日(2006.9.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
バイナリ画像データを発生するデバイスと、バイナリ画像データの格納のための遠隔NDMAアーカイブシステムとの間でバイナリ画像データを通信するための多層化データ構造であり、
ソケットプロトコルを備える第１の層と、
第１の層内で入れ子にされ、国家デジタル乳房撮影アーカイブ(NDMA)のヘッダーを備える第２の層と、
２番目の層内で入れ子にされ、拡張可能なマーク付け言語(XML)テキストを備える３番目の層と、および
３番目の層内で入れ子にされ、前記バイナリデータを備える４番目の層とを備えるデータ構造。
【請求項２】
前記NDMAヘッダーは、前記データ構造のバージョンを示すバージョンインジケータ、前記バイナリ画像データのタイプを示すタイプインジケータ、前記第３および第４の層のコンテンツ長を示すコンテンツ長インジケータ、およびメッセージ参照シーケンス番号の少なくとも一つの備える請求項１記載のデータ構造。
【請求項３】
前記のタイプインジケータは、前記バイナリ画像データが、医療関連データ内に、デジタルイメージングおよび通信(DICOM)、バイナリのペイロードまたはテキストを備えるかどうかのインジケータである請求項２記載のデータ構造。
【請求項４】
前記バイナリ画像データは、前記のタイプインジケータに基づき、設定される請求項２記載のデータ構造。
【請求項５】
前記メッセージ参照シーケンス番号は、前記データ構造のコンテンツが応答メッセージであるかを示す請求項２記載のデータ構造。
【請求項６】
前記NDMAヘッダーは、加算およびアップデートの少なくとも一つ、前記バージョンインジケータの少なくとも一つ、前記タイプインジケータ、前記コンテンツ長、および、前記メッセージ参照シーケンス番号に拡張できる請求項２記載のデータ構造。
【請求項７】
前記データ構造は、将来のデータプロトコルの変更のために、後方互換性を、前記バージョンインジケータを介して提供する請求項２記載のデータ構造。
【請求項８】
前記NDMAヘッダーは、それぞれのサブセクション内に、入れ子にされたコンテンツの長さを示す、前記NDMAヘッダーの各サブセクションに対する長さインジケータを備える請求項１記載のデータ構造。
【請求項９】
前記XMLテキストは、ルーティング情報およびアプリケーションの記載情報を備える請求項１記載のデータ構造。
【請求項１０】
前記４番目の層は、非ASCIIのエンコードされたバイナリ画像のペイロードを備える請求項１記載のデータ構造。
【請求項１１】
前記第１の層は、送信コントロールプロトコル／インターネットプロトコル(TCP/IP)と互換性がある請求項１記載のデータ構造。
【請求項１２】
前記第１の層は、ヘッダーおよびプロトコル応答の少なくとも一つを備える送信コントロールプロトコル／インターネットプロトコル(TCP/IP)と互換性がある請求項１記載のデータ構造。
【請求項１３】
前記NDMAヘッダーは、前記データ構造がいかにして処理されるべきか、および、前記データ構造がいかにしてルート処理されるべきかの少なくとも一つを示すタイプインジケータを備える請求項１記載のデータ構造。
【請求項１４】
前記NDMAヘッダーは、前記XMLテキストの選択された部分を備える請求項１記載のデータ構造。
【請求項１５】
前記選択された部分は、ルーティング情報、時間情報、識別情報、抽出DICOM関連情報、およびバイナリデータの少なくとも一つを備える請求項１４記載のデータ構造。
【請求項１６】
前記バイナリ画像データは、非エンコードのテキストおよびバイナリ画像データをそこに持つメッセージを備える請求項１記載のデータ構造。
【請求項１７】
前記バイナリ画像データは、医療でのデジタルイメージングおよび通信(DICOM)画像データおよびDICOM構造の報告データの少なくとも一つを備える請求項１記載のデータ構造。
【請求項１８】
医療でのデジタルのイメージングおよび通信(DICOM)の互換性デバイスと、格納デバイスとの間でバイナリの画像データを転送するための方法であり、
ソケットを開け、そして続いて総数のバイトを示すソケットプロトコルヘッダーを送るステップと、
コンテンツタイプ XMLのために、各々がバージョンおよび長さの修飾子 (specifier) を含む、第１のNDMAヘッダーを送るステップと、
メッセージ識別子、要求された動作、および送信機および受信機の識別子を含むXMLメッセージを送るステップと、
コンテンツタイプのバイナリ画像データに対する第２のNDMAヘッダーを送るステップと、および
バイナリ画像データを含むバイナリのペイロードを送るステップとを備える方法。
【請求項１９】
前記ソケットプロトコルヘッダーに記述された合計のバイト数が送信されるまで、NDMAヘッダーおよび関連したコンテンツを送信するステップを備える請求項１８記載の方法。
【請求項２０】
前記送信機および受信機の記載は、前記バイナリ画像データの送信機および受信機の少なくとも一つで、証明するための証明データを含む請求項１８記載の方法。
【請求項２１】
XMLメッセージは、そのXMLメッセージに従うバイナリのペイロード内のバイナリの画像データに関係したデータを含み、前記バイナリ画像データに関係した前記データをソフトウエアアプリケーション処理するステップを備える請求項１８記載の方法。
【請求項２２】
前記バージョン指定子は、将来のデータプロトコル変更のために、後方互換性を許可する請求項１８記載の方法。
【請求項２３】
応答承認のためのバイナリのペイロードを除く、応答メッセージ識別子、要求された動作および、送信機および受信機の記載を含むXMLメッセージを送信するステップを更に備える請求項１８記載の方法。
【請求項２４】
ネットワーク上で複数のデータタイプのコンテンツを有するペイロードの通信のための多層化データ構造であり、
ソケットプロトコルを備える第１の層と、
ヘッターに続くペイロードデータのそれぞれのデータタイプを示すペイロードインジケータを含むヘッターを備え、前記第１の層内の第２の層と、および
ペイロードを備え、前記第２の層内の第３の層とを備えるデータ構造。
【請求項２５】
ヘッダーは、そのヘッダーに続くペイロードコンテンツの長さを示す長さインジケータを更に含む請求項２４記載のデータ構造。
【請求項２６】
第２の層内の第４の層、第４の層内の第３の層を更に備え、第４の層は拡張可能なマーク付け言語(XML)のデータを備える請求項２４記載のデータ構造。
【請求項２７】
第３の層は、キャラクタのデータタイプを持つペイロードコンテンツの第１の部分と、バイナリのデータタイプを持つペイロードコンテンツの第２の部分を含む請求項２６記載のデータ構造。
【請求項２８】
ペイロードコンテンツの第１の部分は、ペイロードコンテンツの第２の部分から抽出された情報に対応するXMLタグを含む請求項２７記載のデータ構造。
【請求項２９】
第４の層は送信および受信の情報を含む請求項２６記載のデータ構造。
【請求項３０】
ソケットプロトコルは、送信コントロールプロトコル／インターネットプロトコル(TCP/IP)である請求項２４記載のデータ構造。
【請求項３１】
第２の層のヘッダヘーは、バージョン番号を更に含む請求項２４記載のデータ構造。
【請求項３２】
第２の層のヘッダーは、メッセージ参照シーケンス番号を更に含む請求項２４記載のデータ構造。
【請求項３３】
ソケットプロトコルは、単一のポートで受信されたペイロード通信の処理を指示するメッセージタイプを含む請求項２４記載のデータ構造。
【請求項３４】
ネットワーク上の複数のデータタイプのコンテンツのペイロードを含む通信データのための方法であり、
ソケットを開き、そして、そのソケットを通じて通信されるべきデータの長さを含むソケットプロトコルヘッダーを送信するステップと、
ペイロードコンテンツの第１の部分に対する第１のデータタイプを示す第１のタイプインジケータを含む第１のヘッダーを送信するステップと、
第１のヘッダーに続くペイロードコンテンツの第１の部分を送信するステップと、
ペイロードコンテンツの第２の部分に対する第２のデータタイプを示す第２のタイプインジケータを含む第２のヘッダーを送信するステップと、そして
第２のヘッダーに続くペイロードコンテンツの第２の部分を送信するステップを備える方法。
【請求項３５】
第１のデータタイプはキャラクタのデータタイプである請求項３４記載の方法。
【請求項３６】
ペイロードコンテンツの第１の部分は、拡張可能なマーク付け言語(XML)のデータを含む請求項３５記載の方法。
【請求項３７】
第２のデータタイプは、バイナリのデータタイプである請求項３５記載の方法。
【請求項３８】
ヘッダーおよび、ペイロードコンテンツの第１の部分を受信するステップと、
第１のヘッダー内に含まれる第１のデータタイプを示す第１のタイプインジケータに基づくペイロードコンテンツの第１の部分を処理するステップと、
第２のヘッダーと、ペイロードコンテンツの第２の部分を受信するステップと、および
第２のヘッダー内に含まれる第２のデータタイプを示す第２のタイプインジケータに基づくペイロードコンテンツの第２の部分を処理するステップとを更に備える請求項３４記載の方法。
【請求項３９】
ペイロードコンテンツの第１の部分は、ペイロードコンテンツの第２の部分から抽出された情報を含む請求項３８記載の方法。
【請求項４０】
ペイロードコンテンツの第２の部分を処理するステップは、ペイロードコンテンツの第１の部分に更に基づく請求項３９記載の方法。
【請求項４１】
メッセージデータを含む対応するソケット層内の情報を処理するために、一つのポートで受信された情報を、複数の他のポートにルーティングするための方法であり、
その情報に対応するソケット層を調べるステップと、
ソケット層内のメッセージタイプを識別するステップと、
識別されたメッセージタイプを、複数の他のポートの一つに関連させるステップと、および
ソケット層内の情報を、認識されたメッセージタイプに関連した複数の他のポートの一つにルーティングさせるステップを備える方法。
【請求項４２】
メッセージタイプは、医療記録に対する質問、質問への応答、格納画像要求、医療保険の携行と責任に関する法律(HIPAA)検査格納要求、再検索記録に対する質問、画像所有者ノード要求への将来の質問結果、フェッチ再検索画像要求、又は、フェッチおよび  再検索画像要求の一つである請求項４１記載の方法。
【請求項４３】
認識されたメッセージタイプに関連した複数の他のポートは、予め決定されたサービスまたは動作を実行する請求項４１記載の方法。
【請求項４４】
予め決定されたサービスまたは動作は、(１)バックエンドへの格納要求を送信すること、(２)バックエンドに質問を送信し、そして今後の要求を、バックエンドにルーティングすること、(３)検査記録をバックエンドに送信すること、(４)ポータルから受信し、バックアップへ送信し、そして応答を受信すること、(５)質問から応答を受信し、または、(６)試験および鼓動記録を扱うことを含む請求項４３記載の方法。
【請求項４５】
ソケット層は、送信制御プロトコル／インターネットプロトコル(TCP/IP)と互換性がある請求項４１記載の方法。
【請求項４６】
ソケット層内で情報を処理するために、一つのポートで受信された情報を、一つ以上の他のポートにルーティングための方法であり、
ポートで情報に対応するソケット層を試験するステップと、
そのソケット層内の情報を、試験されたソケット層に基づき、一つ以上の他の層の一つにルーティングするステップを備える方法。
【請求項４７】
一つ以上の他のポートの一つが、予め決定されたサービスまたは動作を行う請求項４６記載の方法。
【請求項４８】
予め決定されたサービスまたは動作は、(１)バックエンドへの格納要求を送信すること、(２)質問をバックエンドに送信し、そして、以後の要求をバックエンドにルーティングすること、(３)検査記録をバックエンドに送信すること、(４)ポータルから受信してバックアップへ送信し、そして応答を受信すること、(５)質問から応答を受信すること、または(６)試験および鼓動記録を扱うことを含む請求項４７記載の方法。
【請求項４９】
ソケット層は、送信制御プロトコル／インターネットプロトコル(TCP/IP)と互換性がある請求項４６記載の方法。
【請求項５０】
ネットワーク上で多数のデータタイプのコンテンツのペイロードを含む通信データのための方法であり、
ペイロードおよび、ペイロードを示す一つ以上のタイプインジケータを通信チャンネル上で受信するステップと、
一つ以上のタイプインジケータに基づき、ペイロードの部分を処理するステップを備える方法。
【請求項５１】
ペイロードは、第１のデータタイプを含む第１の部分と、第２のデータタイプを含む第２の部分を含み、一つ以上のタイプインジケータは、第１のデータタイプを示す第１のタイプインジケータおよび、第２のデータタイプを示す第２のタイプインジケータを含む請求項５０記載の方法。
【請求項５２】
第１のデータタイプは、キャラクタのデータタイプであり、第２のデータタイプはバイナリのデータタイプである請求項５１記載の方法。
【請求項５３】
処理するステップは、
第１のタイプインジケータに基づき、第１の部分を処理するステップと、
第２のタイプインジケータに基づき、第２の部分を処理するステップとを備える請求項５１記載の方法。
【請求項５４】
受信したデータに対応するソケット層を試験するステップと、試験したソケット層に基づき、処理するステップで用いた一つ以上のインジケータを決定するステップを更に備える請求項５０記載の方法。
【国際調査報告】
2007520761.tif 000011