JP2022528096A - Ｄｉｃｏｍオブジェクトのためのユニバーサルウェブサービス - Google Patents

Abstract

オブジェクト（たとえば、ＤＩＣＯＭオブジェクト）のためのユニバーサルサービスおよびその処理方法について記載される。１つの実施形態において、方法は、ウェブサービスエンジンにおいて、１以上の医用におけるデジタル画像と通信（ＤＩＣＯＭ）オブジェクトのためのリモートウェブクライアントからウェブサービス要求を受け取ることと、ウェブサービス要求からＤＩＣＯＭメッセージサービス要素（ＤＩＭＳＥ）要求を生成することであって、ＤＩＭＳＥサービス要求のための情報を含む修正されたベースＵＲＬを構文解析することを含み、修正されたベースＵＲＬが、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠する、ＤＩＭＳＥ要求を生成することと、ＤＩＭＳＥサービス要求をサーバに送信することと、サーバからＤＩＭＳＥサービス要求に対する応答を受け取ることと、応答を、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠するように再フォーマットすることと、再フォーマットされた応答をリモートウェブクライアントに戻すことと、を含む。【選択図】図３

Description

本発明の実施形態は、医用画像の検索、問い合わせおよび記憶の分野に関し、具体的には、医用におけるデジタル画像と通信（ＤＩＣＯＭ）オブジェクトに関連するウェブサービス要求を処理することに関する。

医師およびその他の医療従事者は、医療上の決断を行う際に患者の関連する臨床情報を全て再考察することが多い。通常、臨床情報は、健康管理検査資料（ｈｅａｌｔｈｃａｒｅ ｓｔｕｄｉｅｓ）および構造化レポートに含まれる。多くの場合、これらの情報は、病歴に関する情報、異なる分野からの診断レポート、画像、およびその他の臨床データを電子フォーマットで含む。

しばしば、医用画像および画像レポートは、ＤＩＣＯＭオブジェクトとして記憶される。通常、これらの健康管理検査資料は、医師が自身の患者の検査を指図することに応じて生成される。多くの場合、検査が行われると、生成された検査資料は画像保管通信システム（ＰＡＣＳ）に送られる。

２００３年、全国電機製造業者協会（ＮＥＭＡ）は、ＤＩＣＯＭオブジェクト（たとえば、画像、医用画像レポート）のアクセスおよび提示のためのウェブサービス標準を発表した。具体的に言えば、この標準は、ＨＴＴＰ／ＨＴＴＰＳプロトコルを使用してＤＩＣＯＭオブジェクトにアクセスするための機構を提供する。多くのベンダーがＮＥＭＡ ＤＩＣＯＭウェブサービス標準をサポートしている。たとえば、ＷＡＤＯ－ＲＳは、インターネットを介して１以上のＤＩＣＯＭオブジェクトをダウンロードする能力を提供し、ＱＩＤＯ－ＲＳは、インターネットを介してＤＩＣＯＭオブジェクトを問い合わせる能力を提供し、ＳＴＯＷ－ＲＳは、インターネットを介してＤＩＣＯＭオブジェクトを遠隔記憶のために送信する能力を提供し、ＷＡＤＯ－ＲＳの旧バージョンであるＷＡＤＯ－ＵＲＩは、インターネット要求毎に１つのＤＩＣＯＭオブジェクトをダウンロードする能力を提供する。この標準の現在のバージョンは以下で見つけることができる。
ｈｔｔｐ：／／ＤＩＣＯＭ．ＮＥＭＡ．ｏｒｇ／ｍｅｄｉｃａｌ／ＤＩＣＯＭ／ｃｕｒｒｅｎｔ／ｏｕｔｐｕｔ／ｃｈｔｍｌ／ｐａｒｔ１８／ＰＳ３．１８．ｈｔｍｌ

ＮＥＭＡがＤＩＣＯＭのウェブサービスのための標準を発表した時には、各ＰＡＣＳベンダーが自社のＰＡＣＳへのインターネットアクセスを提供する独自の標準的な指定ウェブサービスの実装を構築するものと予想されていた。この標準は非常に上手くいっていたが、ＷＡＤＯ－ＲＳ／ＱＩＤＯ－ＲＳを唯一の通信インターフェイスとして使用したいと望むＤＩＣＯＭクライアント（サービスクラスユーザ、すなわちＳＣＵ）にとっては、ベンダーサポート、または非標準的ＷＡＤＯ－ＲＳ／ＱＩＤＯ－ＲＳ実装、またはカスタムウェブ認証要件の欠如によってアクセスできないＰＡＣＳがいくつか存在するようになる。

これらのウェブサービスをサポートするベンダーは、独自のベンダー固有のＰＡＣＳへのアクセスしか提供しない。たとえば、ＡＧＦＡ（登録商標） ＰＡＣＳからのダウンロードにはＡＧＦＡ（登録商標） ＷＡＤＯ－ＲＳを使用しなければならず、Ｓｙｎａｐｓｅ（登録商標） ＰＡＣＳからのダウンロードにはＦＵＪＩＦＩＬＭ ＷＡＤＯ－ＲＳを使用しなければならない。あらゆるＤＩＣＯＭ ＰＡＣＳにアクセスできるＷＡＤＯ－ＲＳ／ＱＩＤＯ－ＲＳを有しているベンダーは存在しない。

オブジェクト（たとえば、ＤＩＣＯＭオブジェクト）のためのユニバーサルウェブサービスおよびその処理方法について説明する。１つの実施形態では、方法が、ウェブサービスエンジンにおいて、１以上の医用におけるデジタル画像と通信（ＤＩＣＯＭ）オブジェクトのためのリモートウェブクライアントからウェブサービス要求を受け取ることと、ウェブサービス要求からＤＩＣＯＭメッセージサービス要素（ＤＩＭＳＥ）要求を生成することであって、ＤＩＭＳＥサービス要求のための情報を含む修正されたベースＵＲＬを構文解析することを含み、修正されたベースＵＲＬが、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠する、ＤＩＭＳＥ要求を生成することと、ＤＩＭＳＥサービス要求をサーバに送信することと、サーバからＤＩＭＳＥサービス要求に対する応答を受け取ることと、応答を、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠するように再フォーマットすることと、再フォーマットされた応答をリモートウェブクライアントに戻すことと、を含む。

別の実施形態では、医用画像管理システムが、１以上のクライアントおよび１以上のリモートサーバと通信するネットワークインターフェイスと、１以上のクライアントから、１以上のリモートサーバに向けられた第１の要求セットを受け取り、第１の要求セットに応じて、ＤＩＣＯＭウェブサービス要求またはＤＩＭＳＥ要求である第２の要求セットをリモートサーバに発行する、回路を有するアクセスエンジンと、を含む。

本発明は、以下に示す詳細な説明および本発明の様々な実施形態の添付図面からさらに完全に理解されると思われるが、これらは本発明を特定の実施形態に限定するものではなく、説明および理解のためのものにすぎないと受け取るべきである。

本発明の実施形態を実装できる例示的な医療情報コンピュータシステム環境を示す図である。 ＤＩＣＯＭオブジェクトにアクセスするためのコンピュータシステムアーキテクチャ例を示す図である。 ウェブサービス要求に対処する医用画像管理システムの１つの実施形態の一部のブロック図である。 ウェブサービス要求からＤＩＭＳＥサービス要求への変換例を示す図である。 ウェブサービス要求からＤＩＭＳＥサービス要求への変換例を示す図である。 ウェブサービス要求からＤＩＭＳＥサービス要求への変換例を示す図である。 ＱＩＤＯ－ＲＳウェブサービス要求に対処するプロセスの１つの実施形態のフロー図である。 ＷＡＤＯ－ＲＳウェブサービス要求に対処するプロセスの１つの実施形態のフロー図である。 ＷＡＤＯ－ＲＳウェブサービス要求に対処するプロセスの１つの実施形態のフロー図である。 ＳＴＯＷ－ＲＳウェブサービス要求に対処するプロセスの１つの実施形態のフロー図である。 ウェブサービス要求を処理するプロセスの１つの実施形態のフロー図である。 医用画像および情報管理システムの論理的表現の例示的な実施形態を示す図である。

以下の説明では、本発明を完全に説明できるように数多くの詳細を示す。しかしながら、当業者には、これらの特定の詳細を伴わずに本発明を実施できることが明らかであろう。その他の場合には、本発明を曖昧にしないように、周知の構造および装置については詳細にではなくブロック図形式で示す。

本発明の実施形態は、ＤＩＣＯＭオブジェクトにアクセスするためのシステムおよび方法に関する。ＤＩＣＯＭオブジェクトは、ＰＡＣＳ、ＶＮＡまたはその他のサーバに記憶することができる。１つの実施形態では、ＤＩＣＯＭオブジェクトが健康管理検査資料の一部である。１つの実施形態では、単一のユニバーサルＤＩＣＯＭウェブインターフェイスを通じてアクセスが提供される。１つの実施形態では、ユニバーサルＤＩＣＯＭウェブインターフェイスがＮＥＭＡ対応であり、あらゆるＤＩＣＯＭ ＰＡＣＳ、またはＤＩＣＯＭクライアント（たとえば、サービスクラスユーザの（ＳＣＵの））アプリケーションエンティティタイトル（ＡｅＴｉｔｌｅまたはＡＥＴ）を許可するサーバにアクセスすることができる。本明細書に開示する実施形態は、以下の利点のうちの１以上を提供する。たとえば、実施形態は、どのベンダーＰＡＣＳが使用されているかにかかわらず単一のクライアント／ＳＣＵインターネット認証を可能にし、ベンダーＰＡＣＳにかかわらず一貫したＤＩＣＯＭウェブサービス実装を提供し、クライアント／ＳＣＵがＤＩＣＯＭ Ｃ－ＦＩＮＤ／Ｃ－ＭＯＶＥ／Ｃ－ＧＥＴ／Ｃ－ＳＴＯＲＥプロトコルをサポートする要件がなく、未だＤＩＣＯＭウェブサービスをサポートしていないＰＡＣＳベンダーへのインターネットアクセスを可能にする。本明細書で使用するＳＣＵは、限定するわけではないが、ＤＩＭＳＥメッセージ（ＴＣＰ）クライアントまたはウェブクライアントを含むクライアントを表す。本発明の概要を簡潔に説明したところで、図１～図１０を参照しながら本発明の実施形態を説明する。

本明細書では、法令要件を満たすように本発明の実施形態の主題を特異的に説明する。しかしながら、この説明自体は、本発明の範囲を限定するように意図されたものではない。むしろ、本発明者らは、現在のまたは将来的な他の技術と併せて、異なるステップ、または本明細書で説明するものと同様のステップの組み合わせを含むように、特許請求する主題を他の形でも具体化できることを目論んでいる。

本発明の実施形態を簡潔に説明したところで、以下、本発明の実施形態の実装における使用に適した例示的な動作環境について説明する。

全体的に図面を参照すると、特に最初に図１に本発明の実施形態を実装できる医療情報コンピュータシステム環境を示し、全体を参照番号１２０として指定する。当業者であれば、図示の医療情報コンピュータシステム環境１２０は１つの好適なコンピュータ環境の一例にすぎず、本発明の使用または機能の範囲に関するいずれかの限定を示唆するように意図されたものではないと理解するであろう。また、医療情報コンピュータシステム環境１２０は、図示のいずれかの単一のコンポーネントまたはコンポーネントの組み合わせに関連する依存性または要件を有するものでもないと解釈されたい。

本開示の実施形態は、数多くの汎用または専用コンピュータシステム環境または構成と共に動作することができる。本発明との使用に適することができる周知のコンピュータシステム、環境および／または構成の例としては、ほんの一例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド装置またはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能な消費者電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、および上述したシステムまたは装置のうちのいずれかを含む分散コンピュータ環境などが挙げられる。

本発明の実施形態は、コンピュータがプログラムモジュールなどのコンピュータ実行可能命令を実行する一般的状況で説明することができる。一般に、プログラムモジュールは、以下に限定するわけではないが、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネントおよびデータ構造を含む。本発明は、通信ネットワークを通じてリンクされた遠隔処理装置によってタスクが実行される分散コンピュータ環境で実施することもできる。分散コンピュータ環境では、一例としてメモリ記憶装置を含む局所的および／または遠隔的コンピュータ記憶媒体に関連付けてプログラムモジュールを配置することができる。

引き続き図１を参照すると、例示的な医療情報コンピュータシステム環境１２０は、制御サーバ１２２の形の汎用コンピュータ装置を含む。制御サーバ１２２のコンポーネントは、処理ユニットと、内部システムメモリと、持続（ｐｅｒｓｉｓｔｅｎｔ）ストレージ１２４を含む様々なシステムコンポーネントを制御サーバ１２２に結合するための好適なシステムバスとを制限なく含むことができる。システムバスは、様々なバスアーキテクチャのうちのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含む複数のタイプのバス構造のうちのいずれかとすることができる。限定ではなく一例として、このようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、高度ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子標準協会（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとしても知られている周辺コンポーネント相互接続（ＰＣＩ）バスを含む。

通常、制御サーバ１２２は、たとえば持続ストレージ１２４などの様々なコンピュータ可読媒体に記憶されたデータを含み、またはこのようなデータにアクセスすることができる。コンピュータ可読媒体は、サーバ１２２がアクセスできるいずれかの利用可能な媒体とすることができ、揮発性および不揮発性媒体、並びに取り外し可能および取り外し不能媒体を含む。限定ではなく一例として、コンピュータ可読媒体は、コンピュータ記憶媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、データベース、フォーマット済みファイル、レジストリキーまたはその他のデータなどの情報を記憶するためのいずれかの方法または技術で実装された揮発性および不揮発性媒体、並びに取り外し可能および取り外し不能媒体を制限なく含むことができる。この点、コンピュータ記憶媒体は、以下に限定するわけではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）またはその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたはその他の磁気記憶装置、あるいは所望の情報を記憶するために使用できるとともに制御サーバ１２２がアクセスできる他のいずれかの媒体を含むことができる。限定ではなく一例として、通信媒体は、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線およびその他の無線媒体などの無線媒体とを含む。コンピュータ可読媒体の範囲には、上記のうちのいずれかの組み合わせを含めることもできる。

図１に示して上述した持続ストレージ１２４を含むコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、および制御サーバ１２２のための他のデータのストレージを提供する。制御サーバ１２２は、１以上のリモートコンピュータ１２８への論理接続を使用してコンピュータネットワーク１２６内で動作することができる。リモートコンピュータ１２８は、たとえば以下に限定するわけではないが、臨床検査室（たとえば、分子臨床検査室）、病院およびその他の入院患者環境、獣医環境、外来環境、医療費請求事務室および財務室、病院管理環境、在宅医療環境および診療所などの、医療または研究環境内の様々な位置に配置することができる。臨床医は、以下に限定するわけではないが、１または複数の治療担当医、集中治療専門医、外科医、放射線医、循環器専門医および腫瘍医などの専門医、救急医療技師、医師の助手、実地看護師、看護師、補助看護師、薬剤師、栄養士、微生物学者、検査室専門家、検査室技師、放射線技師、研究者、獣医および学生などを含む。リモートコンピュータ１２８は、医療団体全体をネットワーク上で一体化できるように非伝統的な医療環境内に物理的に配置することもできる。リモートコンピュータ１２８は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、携帯情報端末または他の共通ネットワークノードなどとすることができ、制御サーバ１２２に関して上述した要素の一部または全部を含むことができる。限定ではなく一例として、制御サーバ１２２は、ネットワーク１２６を伴わずにローカルソフトウェアとしてリモートコンピュータ１２８上に存在することもできる。

例示的なコンピュータネットワーク１２６は、ローカルエリアネットワーク（ＬＡＮ）および／またはワイドエリアネットワーク（ＷＡＮ）を制限なく含むことができる。このようなネットワーク環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的である。制御サーバ１２２は、ＷＡＮネットワーク環境で利用される場合、インターネットなどのＷＡＮを介して通信を確立するためのモデムまたはその他の手段を含むことができる。ネットワーク環境では、プログラムモジュールまたはその一部を、制御サーバ１２２、持続ストレージ１２４、またはいずれかのリモートコンピュータ１２８に関連付けて記憶することができる。限定ではなく一例として、いずれか１以上のリモートコンピュータ１２８に関連するメモリ上には、様々なアプリケーションプログラムが存在することができる。当業者であれば、図示のネットワーク接続は例示であり、コンピュータ（たとえば、制御サーバ１２２およびリモートコンピュータ１２８）間の通信リンクを確立する他の手段を利用することもできると理解するであろう。

臨床医は、活動中に、キーボード、（一般にマウスと呼ばれる）ポインティングデバイス、トラックボールまたはタッチパッドなどの入力装置を通じて制御サーバ１２２にコマンドおよび情報を入力し、あるいは１以上のリモートコンピュータ１２８を介して制御サーバ１２２にコマンドおよび情報を伝えることができる。他の入力装置は、マイクまたはスキャナなどを制限なく含むことができる。コマンドおよび情報は、遠隔医療装置から制御サーバ１２２に直接送信することもできる。制御サーバ１２２および／またはリモートコンピュータ１２８は、モニタに加えてスピーカおよびプリンタなどの他の周辺出力装置を含むこともできる。

制御サーバ１２２およびリモートコンピュータ１２８の他の多くの内部コンポーネントについては図示していないが、当業者であれば、このようなコンポーネントおよびその相互接続は周知であると理解するであろう。従って、本明細書では、制御サーバ１２２およびリモートコンピュータ１２８の内部構造に関するさらなる詳細についてはこれ以上開示しない。

図２は、医用におけるデジタル画像と通信（ＤＩＣＯＭ）オブジェクトのためのユニバーサルウェブサービスに対処するコンピュータシステムアーキテクチャの例を示すブロック図である。なお、図２に示すコンピュータシステムアーキテクチャは、１つの好適なコンピュータシステムの例にすぎず、いずれかの単一のモジュール／コンポーネントまたはモジュール／コンポーネントの組み合わせに関連するいずれかの依存性または要件を有するように意図されたものではないと理解されるであろう。

図２を参照すると、ＳＣＵ（クライアント）２０１₁～ＳＣＵ（クライアント）２０１_Nが、医用画像管理システム２０３に送信されるウェブサービス要求２０２を生成する。１つの実施形態では、ＳＣＵ（クライアント）２０１₁～ＳＣＵ（クライアント）２０１_Nが、医用画像の閲覧、問い合わせまたは記憶のためのリモートウェブクライアントを含む。（単複の）ユニバーサルアクセスエンジン２１０は、ウェブサービスエンジンとして動作し、ＳＣＵ（クライアント）２０１₁～ＳＣＵ（クライアント）２０１_Nからウェブサービス要求２０２を受け取る。１つの実施形態では、ウェブサービス要求が、ＱＩＤＯ－ＲＳ、ＷＡＤＯ－ＲＳ、ＳＴＯＷ－ＲＳまたはＷＡＤＯ－ＵＲＩ要求を含む。しかしながら、ウェブサービス要求はこれらの要求に限定されず、ＮＥＭＡ、ＤＩＣＯＭまたはＩＨＥによって承認された将来的なＤＩＣＯＭウェブサービスを含むこともできる。別の実施形態では、ウェブサービス要求が、アクセスエンジン２１０によって（ＱＩＤＯ－ＲＳ）のようなＤＩＣＯＭウェブサービス要求またはＣ－ＦＩＮＤのようなＤＩＣＯＭメッセージ（ＤＩＭＳＥ）要求のいずれかに変換できるＵＲＬを使用する。さらに別の実施形態では、アクセスエンジン２１０がＳＣＵ／クライアント装置上のアプリケーションとして動作し、ソフトウェアインターフェイスを使用して、アクセスエンジン２１０がＤＩＣＯＭウェブサービス要求またはＤＩＣＯＭメッセージ（ＤＩＭＳＥ）要求のいずれかとして実装できる要求を発行する。従って、この場合、サービスは、ＰＡＣＳまたはＶＮＡのような１以上のリモート医用データシステムに対するウェブサービスの交換台（ｓｗｉｔｃｈ ｂｏａｒｄ）として機能する医用画像クライアントがアクセスできるローカルプロセスであり、この交換台は、リモートＰＡＣＳ／ＶＮＡによってサポートされている時にＤＩＣＯＭウェブ要求を発行して、上述したようなＤＩＭＳＥサービスを別様に使用し、応答は、クライアントが使用できるようにＤＩＣＯＭウェブサービスフォーマットに変換される。

１つの実施形態では、ウェブサービス要求２０２が、ＤＩＣＯＭウェブサービスをサポートしていない、あるいは非標準的な方法またはＳＣＵ２０１が認証するのが困難な方法でＤＩＣＯＭウェブサービスをサポートしているＰＡＣＳ２０５のためのものである。これらの条件のいずれかが当てはまる場合、ユニバーサルアクセスエンジン２１０は、ウェブサービス要求を受け取ったことに応じてＤＩＭＳＥサービス要求を生成する。１つの実施形態では、ＤＩＭＳＥサービス要求が、Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ動作を含む。１つの実施形態では、ユニバーサルアクセスエンジン２１０が、ウェブサービス要求２０２内に埋め込まれたソースＰＡＣＳ２０５識別子に基づいてＤＩＭＳＥサービス要求を生成する。１つの実施形態では、ウェブサービス要求２０２が、ＳＣＵ ＡｅＴｉｔｌｅ、ソースＰＡＣＳ ＡｅＴｉｔｌｅ、ソースＰＡＣＳホストおよびポートのうちの１以上などの、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ要求のために必要な追加情報を含む。１つの実施形態では、アクセスエンジン２１０がウェブサービス要求２０２を構文解析してウェブサービスのタイプ（たとえば、ＱＩＤＯ－ＲＳ）を識別し、ＤＩＣＯＭクライアントを生成し、識別されたウェブサービスのタイプに基づいてＤＩＣＯＭクライアントに１つのＤＩＭＳＥサービス要求を発行させる。１つの実施形態では、生成されたＤＩＭＳＥサービス要求が、ＤＩＣＯＭオブジェクトにアクセスするためのＤＩＣＯＭメッセージングを指定する標準に準拠する。１つの実施形態では、この標準がＮＥＭＡ ＤＩＣＯＭ ＰＳ３．１である。

ユニバーサルアクセスエンジン２１０は、ソースＰＡＣＳ／ＤＩＣＯＭサーバ２０５₁～ソースＰＡＣＳ／ＤＩＣＯＭサーバ２０５_NなどのソースＰＡＣＳ、ＤＩＣＯＭサーバまたはＶＮＡにＤＩＭＳＥサービス要求２０４を送信する。ソースＰＡＣＳは、ＤＩＭＳＥサービス要求に対する応答を生成し、この応答をユニバーサルアクセスエンジン２１０に送信する。ユニバーサルアクセスエンジン２１０は、この応答をリモートウェブクライアントが理解するフォーマットに再フォーマットし、再フォーマットされた応答をＳＣＵ（クライアント）２０１₁～ＳＣＵ（クライアント）２０１_Nなどのリモートウェブクライアントに戻す。

図３は、ネットワークインターフェイス３０１およびユニバーサルアクセスエンジン３０２を含む、ウェブサービス要求に対処する医用画像管理システムの１つの実施形態の一部のブロック図である。１つの実施形態では、ユニバーサルアクセスエンジン３０２が、１以上のプロセッサまたはその他のハードウェア（回路、専用ロジックなど）、ソフトウェア（たとえば、チップ上で動作するソフトウェア）、ファームウェア、またはこれらの組み合わせを含む。

図３を参照すると、ネットワークインターフェイス３０１がウェブクライアントからウェブサービス要求３１１を受け取る。ウェブサービス要求３１１はユニバーサルアクセスエンジン３０２に送信され、ここではパーサー（ｐａｒｓｅｒ）３２１がウェブサービスの要求を構文解析して要求のタイプを決定する。要求のタイプを決定したことに応じて、ＤＩＣＯＭクライアント生成器３２２がＤＩＣＯＭ ＳＣＵクライアントを生成する。たとえば、ＭｕｌｔｉＴｅｃｈ ｍｓｉＣＯＭ３などのサードパーティライブラリがＳＣＵクライアントソフトウェアを提供することもでき、あるいは当業者がそこから独自のＳＣＵクライアントを構築することもできる。やはりウェブサービス要求のタイプに基づいて、ＤＩＭＳＥ要求形成器３２３がＤＩＭＳＥ要求を生成または別様に形成する。１つの実施形態では、ＤＩＭＳＥ要求が、Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ動作のためのＤＩＣＯＭオブジェクトを含む。ＤＩＭＳＥ要求形成器３２３がＤＩＭＳＥ要求オブジェクトを生成したことに応じて、ＤＩＭＳＥ要求発行器３２４がＤＩＭＳＥ要求３１２を発行する。１つの実施形態では、ＤＩＭＳＥ要求発行器３２４が、ネットワークインターフェイス３０１にＤＩＭＳＥ要求３１２を発行し、ネットワークインターフェイス３０１は、ＤＩＭＳＥ要求３１２を受け取り、パーサー３２１によって識別されたＰＡＣＳ／ＤＩＣＯＭ／ＶＮＡサーバにネットワーク（たとえば、インターネットなど）を介して送信する。

その後、ＤＩＭＳＥ要求を受け取ったＰＡＣＳ／ＤＩＣＯＭ／ＶＮＡサーバは、ＤＩＭＳＥ要求３１２に対するＤＩＭＳＥ応答３１３を生成し、これが医用画像管理システムのネットワークインターフェイス３０１によって受け取られる。ＤＩＭＳＥ要求に対する応答３１３は、ユニバーサルアクセスエンジン３０２の応答生成器３３１に送信される。応答３１３に応じて、変換器／再フォーマット器３４１が、応答３１３をウェブサービス要求に準拠したフォーマットに変換および／または再フォーマットする。限定ではなく一例として、Ｃ－ＦＩＮＤ応答は、ＱＩＤＯ－ＲＳのためのＮＥＭＡ標準ＰＳ３．１８に指定されるようなアプリケーション／ｄｉｃｏｍ＋ｘｍｌまたはアプリケーション／ｄｉｃｏｍ＋ｊｓｏｎに変換することができる。任意に、応答生成器３３１は、たとえばウェブサービス要求がＪＰＥＧまたはＰＮＧ応答を必要とする場合、レンダラ３４２を使用してＤＩＣＯＭオブジェクトを表示用にレンダリングすることができる。任意に、応答生成器３３１は、バルクデータを求めるＷＡＤＯ－ＲＳウェブサービス要求を満たすために、抽出器３４３を使用してＤＩＭＳＥ要求応答３１３からバルクデータを抽出することができる。任意に、応答生成器３３１は、ＷＡＤＯ－ＲＳメタデータウェブサービス要求を満たすために、抽出器３４３を使用してＤＩＣＯＭヘッダ情報を変換してメタデータ応答を生成することができる。任意に、ＤＩＭＳＥ応答３１３、あるいはその一部またはそこからレンダリングされた要素の一部は、キャッシュコントローラ３４４を使用してキャッシュメモリに記憶することができる。１つの実施形態では、ウェブサービス要求３１１が繰り返される場合、クライアント生成器３２２の代わりにキャッシュメモリを使用して医療コンテンツにアクセスする。

ウェブサービス応答は、変換／再フォーマット後にウェブサービス応答発行器３４５に送信され、ウェブサービス応答発行器３４５は、ネットワークインターフェイス３０１にウェブサービス応答３１４を発行し、ネットワークインターフェイス３０１は、最初にウェブサービス要求３１１を生成したウェブクライアントにこれを送信する。

図４Ａ～図４Ｃに、ウェブサービス要求からＤＩＭＳＥサービス要求への変換例を示す。図４Ａを参照すると、ウェブクライアントであるＳＣＵ４０１は、ＱＩＤＯ－ＲＳウェブサービス要求を生成してユニバーサルＱＩＤＯ－ＲＳエンジン４０２に送信し、ユニバーサルＱＩＤＯ－ＲＳエンジン４０２は、これをＤＩＭＳＥ Ｃ－ＦＩＮＤ要求に変換してソースＰＡＣＳ４０３（ＤＩＣＯＭサーバ）に送信する。ソースＰＡＣＳ４０３は、ＤＩＭＳＥ Ｃ－ＦＩＮＤ要求に応じて応答を生成してユニバーサルＱＩＤＯ－ＲＳエンジン４０２に送信し、ユニバーサルＱＩＤＯ－ＲＳエンジン４０２は、この応答を再フォーマットしてＳＣＵ４０１に応答として送信する。

図４Ｂを参照すると、ウェブクライアントであるＳＣＵ４１１は、ＷＡＤＯ－ＲＳウェブサービス要求を生成してユニバーサルＷＡＤＯ－ＲＳエンジン４１２に送信し、ユニバーサルＷＡＤＯ－ＲＳエンジン４１２は、これをＤＩＭＳＥ Ｃ－ＧＥＴまたはＣ－ＭＯＶＥ要求に変換してソースＰＡＣＳ４１３（ＤＩＣＯＭサーバ）に送信する。ソースＰＡＣＳ４１３は、ＤＩＭＳＥ Ｃ－ＧＥＴまたはＣ－ＭＯＶＥ要求に応じて応答を生成してユニバーサルＷＡＤＯ－ＲＳエンジン４１２に送信し、ユニバーサルＷＡＤＯ－ＲＳエンジン４１２は、この応答を再フォーマットしてＳＣＵ４１１に応答として送信する。

図４Ｃを参照すると、ウェブクライアントであるＳＣＵ４２１は、ＳＴＯＷ－ＲＳウェブサービス要求を生成してユニバーサルＳＴＯＷ－ＲＳエンジン４２２に送信し、ユニバーサルＳＴＯＷ－ＲＳエンジン４２２は、これをＣ－ＳＴＯＲＥ ＤＩＭＳＥ要求に変換してソースＰＡＣＳ４２３（ＤＩＣＯＭサーバ）に送信する。ソースＰＡＣＳ４２３は、Ｃ－ＳＴＯＲＥ ＤＩＭＳＥ要求に応じて応答を生成してユニバーサルＳＴＯＷ－ＲＳエンジン４２２に送信し、ユニバーサルＳＴＯＷ－ＲＳエンジン４２２は、この応答を再フォーマットしてＳＣＵ４２１に応答として送信する。

ＤＩＣＯＭウェブサービスのためのＮＥＭＡ標準（ＰＳ３．１８）には、医用データの検査資料を求める特定のウェブサーバ要求のために以下のＵＲＬフォーマットが指定されている。
ＱＩＤＯ－ＲＳ：｛ＳＥＲＶＩＣＥ｝／ｓｔｕｄｉｅｓ
ＷＡＤＯ－ＲＳ：｛ＳＥＲＶＩＣＥ｝／ｓｔｕｄｉｅｓ／｛ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤ｝
ＳＴＯＷ－ＲＳ：｛ＳＥＲＶＩＣＥ｝／ｓｔｕｄｉｅｓ［／｛ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤ｝］
ここで、｛ＳＥＲＶＩＣＥ｝は、サービスのためのベースＵＲＬである。このＵＲＬは、プロトコル（ｈｔｔｐまたはｈｔｔｐｓ）、ホスト、ポートおよびアプリケーションの組み合わせとすることができる。「アプリケーション」の定義はベンダー次第になっている。たとえば、ＶＮＡへの要求は以下のように見えうる。
ｈｔｔｐ：／／ｍｙＶｎａ：８０８０／ｗａｄｏ－ｒｓ／ＭｙＣｕｓｔｏｍｅｒＤｏｍａｉｎ／ｓｔｕｄｉｅｓ
ここで、ＭｙＣｕｓｔｏｍｅｒＤｏｍａｉｎはアプリケーション名の一部であり、ＶＮＡ上の多くのコンテンツ区分のうちの１つを指定する。

１つの実施形態では、本明細書に開示する（単複の）ユニバーサルアクセスエンジンの１つの新たな特徴が、ＤＩＣＯＭウェブサービス標準に準拠したままで、ＤＩＣＯＭ Ｃ－ＦＩＮＤ／Ｃ－ＧＥＴ／Ｃ－ＭＯＶＥ／Ｃ－ＳＴＯＲＥ要求のために必要な全ての情報を含むようにアプリケーション名を拡張することである。

１つの実施形態では、（単複の）ユニバーサルアクセスエンジンへのコールが｛ＳＥＲＶＩＣＥ｝を以下のように定義する。
ＱＩＤＯ－ＲＳ ＵＲＬ：
ｈｔｔｐ：／／＜ＵｎｉｖｅｒｓａｌＳｅｒｖｅｒ＞／ｑｉｄｏ－ｒｓ／ｃｆｉｎｄ／＜ＳＣＵ ＡＥＴ＞／＜ＳＣＰ ＡＥＴ＞／＜ＳＣＰ Ｈｏｓｔ＞／＜ＳＣＰ Ｐｏｒｔ＞／＜Ｄｅｓｔ ＡＥＴ＞
ＷＡＤＯ－ＲＳ ＵＲＬ：
ｈｔｔｐ：／／＜ＵｎｉｖｅｒｓａｌＳｅｒｖｅｒ＞／ｗａｄｏ－ｒｓ／ｃｍｏｖｅ／＜ＳＣＵ ＡＥＴ＞／＜ＳＣＰ ＡＥＴ＞／＜ＳＣＰ Ｈｏｓｔ＞／＜ＳＣＰ Ｐｏｒｔ＞／＜Ｄｅｓｔ ＡＥＴ＞
または
ｈｔｔｐ：／／＜ＵｎｉｖｅｒｓａｌＳｅｒｖｅｒ＞／ｗａｄｏ－ｒｓ／ｃｇｅｔ／＜ＳＣＵ ＡＥＴ＞／＜ＳＣＰ ＡＥＴ＞／＜ＳＣＰ Ｈｏｓｔ＞／＜ＳＣＰ Ｐｏｒｔ＞
ＳＴＯＷ－ＲＳ ＵＲＬ：
ｈｔｔｐ：／／＜ＵｎｉｖｅｒｓａｌＳｅｒｖｅｒ＞／ｓｔｏｗ－ｒｓ／ｃｓｔｏｒｅ／＜ＳＣＵ ＡＥＴ＞／＜ＳＣＰ ＡＥＴ＞／＜ＳＣＰ Ｈｏｓｔ＞／＜ＳＣＰ Ｐｏｒｔ＞
ここで、プロトコルはｈｔｔｐまたはｈｔｔｐｓとすることができ、＜ＵｎｉｖｅｒｓａｌＳｅｒｖｅｒ＞はユニバーサルアクセスサービスを実装するローカルウェブサーバであり、ＱＩＤＯ－ＲＳ、ＷＡＤＯ－ＲＳ、ＳＴＯＷ－ＲＳは任意のサービス識別子である。１つの実施形態では、たとえばｑｉｄｏ－ｒｓの代わりにｑｉｄｏなどのいずれかの一意のキーワードを使用してサーバタイプを識別することも、あるいはさらなる構文解析ロジックを適用してサービス識別子を省略することもできる。１つの実施形態では、サービス識別子が省略され、ｈｔｔｐ要求からサービスコンテキストが以下のように定義される。
・ＰＯＳＴを使用するｈｔｔｐ要求はＳＴＯＷ－ＲＳを識別する。
・ｈｔｔｐ要求がＧＥＴを使用していて｛ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤ｝が存在しない場合にはＱＩＤＯ－ＲＳを想定する。
・ｈｔｔｐ要求がＧＥＴを使用していて｛ＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤ｝が存在する場合にはＷＡＤＯ－ＲＳを想定する。
たとえば、以下のＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤを含まないｈｔｔｐ ｇｅｔ要求はＱＩＤＯ－ＲＳのためのものである。
ｈｔｔｐ：／／＜ＵｎｉｖｅｒｓａｌＳｅｒｖｅｒ＞／＜ＳＣＵ ＡＥＴ＞／＜ＳＣＰ ＡＥＴ＞／＜ＳＣＰ Ｈｏｓｔ＞／＜ＳＣＰ Ｐｏｒｔ＞／＜Ｄｅｓｔ ＡＥＴ＞／Ｓｔｕｄｉｅｓ
一方、以下のＳｔｕｄｙＩｎｓｔａｎｃｅＵＩＤを含むＵＲＬは、ＷＡＤＯ－ＲＳのためのものである。
ｈｔｔｐ：／／＜ ＵｎｉｖｅｒｓａｌＳｅｒｖｅｒ＞／＜ＳＣＵ ＡＥＴ＞／＜ＳＣＰ ＡＥＴ＞／＜ＳＣＰ Ｈｏｓｔ＞／＜ＳＣＰ Ｐｏｒｔ＞／＜Ｄｅｓｔ ＡＥＴ＞／Ｓｔｕｄｉｅｓ／１．３．６．１．４．１．５９６２．１．３．１．１．２００４０８２６１８５０５９

上記のコールでは、ｃｆｉｎｄ／ｃｍｏｖｅ／ｃｇｅｔ／ｃｓｔｏｒｅが、ウェブサービスが従来のＤＩＣＯＭウェブサービスの使用とユニバーサルリモートＰＡＣＳアクセスとの間で切り替えを行うことを可能にする任意のタグである。たとえば、ｈｔｔｐｓ：／／ｍｙＳｅｒｖｅｒ／ｑｉｄｏ－ｒｓ／ｓｔｕｄｉｅｓまたはｈｔｔｐｓ：／／ｍｙＳｅｒｖｅｒ／ｓｔｕｄｉｅｓは、ＱＩＤＯ－ＲＳを使用してｍｙＳｅｒｖｅｒ ＰＡＣＳを問い合わせることができるのに対し、ｈｔｔｐｓ：／／ｍｙＳｅｒｖｅｒ／ｑｉｄｏ－ｒｓ／ｃｆｉｎｄ／ａｅＡ／ａｅＢ／Ｐａｃｓ／ａｅＣ／ｓｔｕｄｉｅｓまたはｈｔｔｐｓ：／／ｍｙＳｅｒｖｅｒ／ｃｆｉｎｄ／ａｅＡ／ａｅＢ／Ｐａｃｓ／ａｅＣ／ｓｔｕｄｉｅｓは、ｍｙＳｅｒｖｅｒを使用してリモートＰＡＣＳ ａｅＢにＣ－ＦＩＮＤ要求を行い、応答はＱＩＤＯ－ＲＳのために再フォーマットされる。

ｍｙＳｅｒｖｅｒがＰＡＣＳまたはＶＮＡウェブサーバでない場合、あるいはｍｙＳｅｒｖｅｒ ＰＡＣＳのためのＤＩＣＯＭウェブサービスが必要でないまたは望ましくない場合には、ｃｆｉｎｄ／ｃｍｏｖｅ／ｃｓｔｏｒｅタグを省略して、クエリは以下のように見えうる。
ｈｔｔｐ：／／ｍｙＳｅｒｖｅｒ／ａｅＡ／ａｅＢ／Ｐａｃｓ／ａｅＣ／ｓｔｕｄｉｅｓ（サービス識別子を省略）、
または、
ｈｔｔｐ：／／ｍｙＳｅｒｖｅｒ／ｑｉｄｏ－ｒｓ／ａｅＡ／ａｅＢ／Ｐａｃｓ／ａｅＣ／ｓｔｕｄｉｅｓ（サービス識別子を含む）。
この実施形態では、ユニバーサルアクセスエンジンが、１以上の独立したソースＰＡＣＳサーバへのプロキシにすぎない。

上記のコールでは、＜ＳＣＵ ＡＥＴ＞がＳＣＵのＡｅＴｉｔｌｅを呼び出している。これはＤＩＣＯＭ要求の許可に使用され、リモートＰＡＣＳに必要なものとすることができる。

また、上記のコールでは、＜ＳＣＰ ＡＥＴ＞がリモートＰＡＣＳの呼び出されたＡｅＴｉｔｌｅであり、＜ＳＣＰ ホスト＞がリモートＰＡＣＳの機械名であり、＜ＳＣＰ Ｐｏｒｔ＞がリモートＰＡＣＳのためのＤＩＣＯＭポートである。たとえば、Ｓｙｎａｐｓｅ（登録商標）ＰＡＣＳは、ＤＩＭＳＥ要求のためにデフォルトでポート１０４を使用する。

上記のコールでは、＜Ｄｅｓｔ ＡＥＴ＞が、Ｃ－ＭＯＶＥによって使用される復帰アドレスＡｅＴｉｔｌｅである。１つの実施形態では、要求されたコンテンツを再びユニバーサルウェブサービスにＣ－ＳＴＯＲＥするために、このアドレスをリモートＰＡＣＳ上に構成する必要がある。なお、＜Ｄｅｓｔ ＡＥＴ＞は、Ｃ－ＦＩＮＤを使用するＱＩＤＯ－ＲＳには厳密に必要ではない。正しいＱＩＤＯ－ＲＳ応答は、クエリによって見つかった各ＤＩＣＯＭインスタンスにアクセスするためのＷＡＤＯ－ＲＳ ＵＲＬを含むべきであるため、ここでは便宜的に＜Ｄｅｓｔ ＡＥＴ＞を含めている。＜Ｄｅｓｔ ＡＥＴ＞を含めることで、このＱＩＤＯ－ＲＳは、Ｃ－ＭＯＶＥをサポートするＷＡＤＯ－ＲＳ ＵＲＬを構築するために必要な全ての情報を有する。ユニバーサルＷＡＤＯ－ＲＳがＣ－ＭＯＶＥの代わりにＣ－ＧＥＴを使用する場合、ＵＲＬ内に＜Ｄｅｓｔ ＡＥＴ＞は不要である。

ＱＩＤＯ－ＲＳワークフロー
１つの実施形態では、リモートウェブクライアントによってＱＩＤＯ－ＲＳ要求が発行された後にＱＩＤＯ－ＲＳワークフローが開始する。本明細書で説明するユニバーサルウェブサービスエンジンは、ＱＩＤＯ－ＲＳ要求を受け取った場合、または要求内の｛ＳＥＲＶＩＣＥ｝の後のパラメータの構文解析時に要求がＱＩＤＯ－ＲＳであることを認識した場合、＜ＳＣＵ ＡＥＴ＞および＜ＳＣＰ ＡＥＴ＞を提供したＡｅＴｉｔｌｅを使用して＜ＳＣＰ Ｐｏｒｔ＞上の＜ＳＣＰ Ｈｏｓｔ＞にＣ－ＦＩＮＤ要求を発行する内部ＤＩＣＯＭ ＳＣＵクライアントを生成する。その後、ＳＣＰホスト（たとえば、ＰＡＣＳ、ＶＮＡサーバなど）は、Ｃ－ＦＩＮＤ応答を生成して返送する。ユニバーサルウェブサービスエンジンは、このＣ－ＦＩＮＤ応答を、初期ウェブ要求の（単複の）ＡｃｃｅｐｔタイプおよびＮＥＭＡ ＤＩＣＯＭウェブサービス標準によって指定されるＤＩＣＯＭ＋ＸＭＬまたはＤＣＩＯＭ＋ＪＳＯＮに変換する。１つの実施形態では、Ａｃｃｅｐｔ Ｔｙｐｅが指定されていない場合、ＤＩＣＯＭ－ＸＭＬがＮＥＭＡ標準ＰＳ３．１８デフォルトである。また、任意に１つの実施形態では、ユニバーサルウェブサービスエンジンが、将来的な同じＤＩＣＯＭオブジェクトを求める繰り返しのクエリにより速く応答するために、応答（フォーマットされたまたはネイティブＤＩＣＯＭまたはカスタム）をキャッシュに入れる。ユニバーサルウェブサービスエンジンは、再フォーマットされたＣ－ＦＩＮＤ応答をリモートウェブクライアントに戻す。１つの実施形態では、全てのＣ－ＦＩＮＤメッセージが受け取られて既知のサイズの１つのｈｔｔｐ応答で戻されるまで、ＱＩＤＯ－ＲＳ応答がバッチ処理される。別の実施形態では応答がストリーミングされ、この最中に、各Ｃ－ＦＩＮＤメッセージが受け取られた後にＱＩＤＯ－ＲＳフォーマット（ＤＩＣＯＭ－ＸＭＬまたはＤＩＣＭＯ－ＪＳＯＮ）のデータチャンクが戻される。

図５は、ＱＩＤＯ－ＲＳ要求に対処するプロセスの１つの実施形態のフロー図である。１つの実施形態では、このプロセスが、ハードウェア（回路、専用ロジックなど）、ソフトウェア（たとえば、チップ上で実行されるソフトウェア）、ファームウェア、またはこれらの組み合わせを含むことができる処理ロジックによって実行される。１つの実施形態では、プロセスが、たとえば限定するわけではないが、図２および図３に関連して上述した医用画像管理プラットフォームなどの医用画像管理プラットフォームによって実行される。

図５を参照すると、プロセスは、処理ロジックがＱＩＤＯ－ＲＳ要求を受け取ること（処理ブロック５０１）によって開始する。処理ロジックは、ＱＩＤＯ－ＲＳ要求を受け取ったことに応じて、要求がＱＩＤＯ－ＲＳ要求であると認識する（処理ブロック５０２）。１つの実施形態では、処理ロジックが、ＱＩＤＯ－ＲＳ要求を構文解析してサービス識別子を発見することによって、要求をＱＩＤＯ－ＲＳ要求として認識する。この構文解析は、ＱＩＤＯ－ＲＳ ＵＲＬ要求の｛ＳＥＲＶＩＣＥ｝部分内およびその後に行うことができる。

処理ロジックは、要求をＱＩＤＯ－ＲＳ要求として認識した後に、サードパーティＤＩＣＯＭライブラリまたはカスタムソフトウェアを使用することによって内部ＤＩＣＯＭ ＳＣＵクライアントを生成する（処理ブロック５０３）。このようなクライアントは当業者に周知であり、ＤＩＣＯＭ標準ＰＳ３．１８に指定されている。

ＤＩＣＯＭ ＳＣＵクライアントは、ＤＩＣＯＭ ＳＣＵクライアントの生成後に、最初のＱＩＤＯ－ＲＳウェブサービス要求によって識別されるＰＡＣＳ／ＶＮＡ／ＤＩＣＯＭサーバ（たとえば、ＳＣＰホスト）にＣ－ＦＩＮＤ要求を発行する（処理ブロック５０４）。

その後、処理ロジックは、Ｃ－ＦＩＮＤ応答を受け取って（処理ブロック５１１）、このＣ－ＦＩＮＤ応答をたとえばＮＥＭＡ標準ＰＳ３．１８ＤＩＣＯＭ＋ＸＭＬまたはＤＩＣＯＭ＋ＪＳＯＮなどの他のフォーマットに変換する（処理ブロック５１２）。ＪＳＯＮ、ＸＭＬまたはその他のフォーマットの別のスキーマを使用して結果を戻すこともできる。１つの実施形態では、Ｃ－ＦＩＮＤ応答がＤＩＣＯＭ＋ＸＭＬまたはＤＩＣＯＭ＋ＪＳＯＮのいずれに変換されるかが、初期ＨＴＴＰ／ＨＴＴＰＳ要求内のＡｃｃｅｐｔタイプの仕様に基づく。

また、処理ロジックは、任意にＣ－ＦＩＮＤ応答をキャッシュに入れる（処理ブロック５１３）。処理ロジックは、再フォーマットされたＣ－ＦＩＮＤ応答をリモートウェブクライアントに送信する（処理ブロック５１４）。１つの実施形態では、再フォーマットされたＣ－ＦＩＮＤ応答を送信することが、全てのＣ－ＦＩＮＤメッセージが受け取られてこれらを既知のサイズの１つの応答として戻す後まで応答をバッチ処理することを含むことができる。別の実施形態では、再フォーマットされたＣ－ＦＩＮＤ応答を送信することが、ＱＩＤＯ－ＲＳ応答をストリーミングして、各Ｃ－ＦＩＮＤメッセージの後にフォーマットされた（たとえば、ＤＩＣＯＭ＋ＸＭＬまたはＤＩＣＯＭ＋ＪＳＯＮ）データチャンクを戻すことを含む。

Ｃ－ＧＥＴを含むＷＡＤＯ－ＲＳのワークフロー
１つの実施形態では、リモートウェブクライアントによってＷＡＤＯ－ＲＳ要求が発行された後に、Ｃ－ＧＥＴを含むＷＡＤＯ－ＲＳのワークフローが開始する。本明細書で説明するユニバーサルウェブサービスエンジンは、ＷＡＤＯ－ＲＳ要求を受け取った場合、またはＷＡＤＯ－ＲＳ要求内の｛ＳＥＲＶＩＣＥ｝の後のパラメータの構文解析時に要求がＷＡＤＯ－ＲＳであることを認識した場合、＜ＳＣＵ ＡＥＴ＞および＜ＳＣＰ ＡＥＴ＞を提供したＡｅＴｉｔｌｅを使用して＜ＳＣＰ Ｐｏｒｔ＞上の＜ＳＣＰ Ｈｏｓｔ＞にＣ－ＧＥＴ要求を発行する内部ＤＩＣＯＭ ＳＣＵクライアントを生成する。

その後、ＳＣＰホスト（たとえば、ＰＡＣＳ、ＶＮＡサーバなど）は、Ｃ－ＧＥＴ応答を生成して返送する。初期ウェブ要求の（単複の）Ａｃｃｅｓｓタイプによって異なる転送構文が指定されている場合、ユニバーサルウェブサービスエンジンは、Ｃ－ＧＥＴ応答を使用して各ＤＩＣＯＭオブジェクトを異なる転送構文に変換する。たとえば、ＤＩＣＯＭウェブサービス標準では、ＪＰＥＧ２０００不可逆圧縮で符号化された医用ＤＩＣＯＭ画像を要求するために以下をＵＲＬパラメータとして使用できることが指定されている。
ａｃｃｅｐｔ＝ｍｕｌｔｉｐａｒｔ／ｒｅｌａｔｅｄ；ｔｙｐｅ＝“ａｐｐｌｉｃａｔｉｏｎ／ｏｃｔｅｔ－ｓｔｒｅａｍ；ｔｒａｎｓｆｅｒ－ｓｙｎｔａｘ＝１．２．８４０．１０００８．１．２．４．９１”
別の実施形態では、リモートＰＡＣＳによってサポートされている場合、Ｃ－ＧＥＴ要求に所望の転送構文が含まれる。１つの実施形態では、ウェブサービス要求内の初期ＵＲＬがＮＥＭＡ標準ＰＳ３．１８の通りにフレームリストを供給した場合、ユニバーサルウェブサービスエンジンは、要求されたフレームを抽出する。別の実施形態では、リモートＰＡＣＳによって所望のフレーム番号がサポートされている場合、Ｃ－ＧＥＴ要求に所望のフレーム番号が含まれる。

１つの実施形態では、ウェブクライアントからの最初のウェブサービス要求において初期ＵＲＬによってＮＥＭＡ標準ＰＳ３．１８の通りに要求された場合、ユニバーサルウェブサービスエンジンが、各ＤＩＣＯＭオブジェクトを表示のためにレンダリングする。限定ではなく一例として：
ｈｔｔｐ：／／｛ＳＥＲＶＩＣＥ｝／ｓｔｕｄｉｅｓ／９９９．０８３０００／ｓｅｒｉｅｓ／９９９．０８３０００．５／ｉｎｓｔａｎｃｅｓ／９９９．０８３０００．５．１０４／ｒｅｎｄｅｒｅｄ？ａｃｃｅｐｔ＝ｉｍａｇｅ／ｊｐｅｇ
１つの実施形態では、ウェブクライアントからの初期ウェブ要求によってＤＩＣＯＭウェブサービスＰＳ３．１８ ６．１．１．８および６．５．１．２．２．の通りに要求された場合、ユニバーサルウェブサービスエンジンがバルクデータを抽出する。
１つの実施形態では、ユニバーサルウェブサービスエンジンがＤＩＣＯＭヘッダ情報を抽出して、ＤＩＣＯＭ＋ＸＭＬまたはＤＩＣＯＭ＋ＪＳＯＮの形で、あるいはウェブ要求の（単複の）Ａｃｃｅｐｔタイプによって要求されるその他のフォーマットでメタデータ応答を生成する。限定ではなく一例として：
ｈｔｔｐ：／／｛ＳＥＲＶＩＣＥ｝／ｓｔｕｄｉｅｓ／９９９．０８３０００／ｍｅｔａｄａｔａ
１つの実施形態では、ユニバーサルウェブサービスエンジンが、同じ医療コンテンツを求める繰り返しの要求時により速く応答するために、ＤＩＣＯＭオブジェクトまたはレンダリングされたＤＩＣＯＭ画像をキャッシュに入れる。

１つの実施形態では、ユニバーサルウェブサービスエンジンが、戻されるべき各再フォーマットされた応答項目をＮＥＭＡ標準ＰＳ３．１８によって指定されるようなＨＴＭＬボディ部分としてラップして、この応答をリモートクライアントに戻す。１つの実施形態では、ユニバーサルウェブサービスエンジンがＣ－ＧＥＴ応答をバッチ処理し、再フォーマットされたＷＡＤＯ－ＲＳ応答全体を既知のサイズの１つのボディとして戻す。別の実施形態では、Ｃ－ＧＥＴ応答オブジェクトが受け取られて処理される時に、各再フォーマットされた応答項目（たとえば、ＤＩＣＯＭオブジェクト、レンダリングされた画像またはフレーム、バルクデータ項目、メタデータ）がチャンク化され（ｃｈｕｎｋｅｄ）、またはリモートクライアントに逆ストリーミングされる。

図６は、Ｃ－ＧＥＴを使用してＷＡＤＯ－ＲＳウェブサービス要求に対処するプロセスの１つの実施形態のフロー図である。１つの実施形態では、プロセスが、ハードウェア（回路、専用ロジックなど）、ソフトウェア（たとえば、チップ上で動作するソフトウェア）、ファームウェア、またはこれらの組み合わせを含むことができる処理ロジックによって実行される。１つの実施形態では、プロセスが、たとえば限定するわけではないが、図２および図３に関連して上述した医用画像管理プラットフォームなどの医用画像管理プラットフォームによって実行される。

図６を参照すると、プロセスは、処理ロジックがＷＡＤＯ－ＲＳ要求を受け取ること（処理ブロック６０１）によって開始する。１つの実施形態では、ＷＡＤＯ要求がユニバーサルアクセス（ウェブサービス）エンジンによって受け取られる。処理ロジックは、ＷＡＤＯ－ＲＳ要求に応じて、要求がＷＡＤＯ－ＲＳであると認識する（処理ブロック６０２）。１つの実施形態では、処理ロジックが、ＷＡＤＯ－ＲＳ要求をウェブサービス識別子について構文解析することによって、要求がＷＡＤＯ－ＲＳであると認識する。１つの実施形態では、｛Ｓｅｒｖｉｃｅ｝の後に発生する構文解析によってウェブサービスが識別される。処理ロジックは、要求がＷＡＤＯ－ＲＳであると認識したことに応じて内部ＤＩＣＯＭ ＳＣＵクライアントを生成し（６０３）、最初のＷＡＤＯ－ＲＳウェブサービス要求内で識別されるＰＡＣＳ／ＶＮＡ／ＤＩＣＯＭサーバ（たとえば、ＳＣＰホスト）に送信されるＣ－ＧＥＴ要求を発行する（処理ブロック６０４）。

その後、処理ロジックは、ＰＡＣＳまたはＶＮＡまたはＤＩＣＯＭサーバからＣ－ＧＥＴ応答を受け取る（処理ブロック６１１）。処理ロジックは、Ｃ－ＧＥＴ応答に応じて複数の動作を実行することができる。１つの実施形態では、処理ロジックが、各ＤＩＣＯＭオブジェクトを別の転送構文に変換する（任意）（処理ブロック６１２）。１つの実施形態では、初期ＵＲＬがＮＥＭＡ標準ＰＳ３．１８の通りにフレームリストを指定した場合、変換プロセスの一部として、要求されるフレームを抽出することができる（処理ブロック６１３）。１つの実施形態では、初期ウェブ要求によって標準（たとえば、ＮＥＭＡ標準ＰＳ３．１８）の通りに要求された場合、処理ロジックが、各ＤＩＣＯＭ画像またはフレームを表示（たとえば、ＪＰＥＧ、ＰＮＧ）のためにレンダリングする（処理ブロック６１４）。１つの実施形態では、初期ＵＲＬによって標準（たとえば、ＮＥＭＡ標準ＰＳ３．１８）の通りに要求された場合、処理ロジックがバルクデータを抽出する（処理ブロック６１５）。１つの実施形態では、処理ロジックが各ＤＩＣＯＭオブジェクトからＤＩＣＯＭヘッダ情報を抽出し、ＤＩＣＯＭ＋ＸＭＬまたはＤＩＣＯＭ＋ＪＳＯＮ、あるいはウェブ要求の（単複の）Ａｃｃｅｐｔタイプによって要求されたその他のフォーマットでメタデータ応答を生成する。さらに別の実施形態では、処理ロジックが、ＤＩＣＯＭオブジェクトまたはレンダリングされた画像をキャッシュに入れる（任意の）（処理ブロック６１６）。キャッシュに入れられたコンテンツは、同じ医用データを求める繰り返しの要求時により速い応答を可能にする。

処理ロジックは、ＷＡＤＯ－ＲＳ応答フォーマットを満たすようにＣ－ＧＥＴ応答を再フォーマットする（処理ブロック６１７）。１つの実施形態では、処理ロジックが、標準（たとえば、ＮＥＭＡ標準ＰＳ３．１８）によって指定されるようなＨＴＭＬボディ部分で各応答項目（ＤＩＣＯＭオブジェクト、フレーム、レンダリングされた表示、バルクデータ、メタデータ）をラップする。次に、処理ロジックは、最初にＷＡＤＯ－ＲＳ要求を送信したウェブクライアントに再フォーマットされたＣ－ＧＥＴ応答を送信する（処理ブロック６１８）。１つの実施形態では、応答をバッチ処理して既知のサイズの１つのＨＴＭＬオブジェクトとして戻すことができる。別の実施形態では、応答項目が利用可能になると、応答がチャンク化されまたはストリーミングされる。

Ｃ－ＭＯＶＥを含むＷＡＤＯ－ＲＳ
１つの実施形態では、リモートウェブクライアント（たとえば、ＳＣＵ）によってＷＡＤＯ－ＲＳ要求が発行された後に、Ｃ－ＭＯＶＥを含むＷＡＤＯ－ＲＳワークフローが開始する。本明細書で説明するユニバーサルウェブサービスエンジンは、ＷＡＤＯ－ＲＳ要求を受け取った場合、またはＷＡＤＯ－ＲＳ要求内の｛ＳＥＲＶＩＣＥ｝の後のパラメータの構文解析時に要求がＷＡＤＯ－ＲＳであることを認識した場合、＜ＳＣＵ ＡＥＴ＞、＜ＳＣＰ ＡＥＴ＞および＜ＤＥＳＴ ＡＥＴ＞を提供したＡｅＴｉｔｌｅを使用して＜ＳＣＰ Ｐｏｒｔ＞上の＜ＳＣＰ Ｈｏｓｔ＞にＣ－ＭＯＶＥ要求を発行する内部ＤＩＣＯＭ ＳＣＵクライアントを生成し、ＳＣＰホストにＣ－ＭＯＶＥ要求が送信される。

その後、ＳＣＰホスト（たとえば、ＰＡＣＳ、ＶＮＡ、サーバなど）は、Ｃ－ＭＯＶＥ応答を生成して返送する。１つの実施形態では、ユニバーサルウェブサービスエンジンが、Ｃ－ＭＯＶＥ応答を使用して、Ｃ－ＭＯＶＥからのＣ－ＳＴＯＲＥ応答を処理する内部ＤＩＣＯＭ ＳＣＰを提供する。Ｃ－ＳＴＯＲＥ ＤＩＣＯＭオブジェクトは、後述するように即座に処理することができる。Ｃ－ＳＴＯＲＥ ＤＩＣＯＭオブジェクトは、処理後にキャッシュに入れまたは廃棄することができる。

１つの実施形態では、本明細書でＣ－ＧＥＴワークフローと共に説明したように初期ウェブ要求の（単複）のＡｃｃｅｓｓタイプによって指定されている場合、ユニバーサルウェブサービスエンジンが各Ｃ－ＳＴＯＲＥ ＤＩＣＯＭオブジェクトを別の転送構文に変換する。別の実施形態では、リモートＰＡＣＳによってサポートされている場合、要求される転送構文がＣ－ＭＯＶＥ要求において指定される。１つの実施形態では、ウェブサービス要求内の初期ＵＲＬがＮＥＭＡ標準ＰＳ３．１８の通りにフレームリストを供給した場合、ユニバーサルウェブサービスエンジンは、Ｃ－ＳＴＯＲＥ ＤＩＣＯＭオブジェクトから要求されるフレームを抽出する。別の実施形態では、リモートＰＡＣＳによってサポートされている場合、要求されるフレームがＣ－ＭＯＶＥ要求において指定される。

１つの実施形態では、初期ウェブ要求によってＮＥＭＡ標準ＰＳ３．１８の通りに、かつＣ－ＧＥＴワークフローについて本明細書で説明したように要求された場合、ユニバーサルウェブサービスエンジンが、各Ｃ－ＳＴＯＲＥ ＤＩＣＯＭオブジェクトを表示のためにレンダリングする。１つの実施形態では、ウェブ要求の初期ＵＲＬによってＮＥＭＡ標準ＰＳ３．１８の通りに要求された場合、ユニバーサルウェブサービスエンジンがバルクデータを抽出する。１つの実施形態では、ユニバーサルウェブサービスエンジンが各ＤＩＣＯＭオブジェクトからＤＩＣＯＭヘッダ情報を抽出し、ＤＩＣＯＭ＋ＸＭＬまたはＤＩＣＯＭ＋ＪＳＯＮ、あるいはウェブ要求の（単複）のＡｃｃｅｓｓタイプによって要求されるその他のフォーマットでメタデータ応答を生成する。１つの実施形態では、ユニバーサルウェブサービスエンジンが、同じ医療コンテンツを求める繰り返しの要求時により速く応答するために、ＤＩＣＯＭオブジェクトまたはレンダリングされた画像をキャッシュに入れる。

１つの実施形態では、ユニバーサルウェブサービスエンジンが、各応答項目を、ＮＥＭＡ標準ＰＳ３．１８によって指定され、本明細書でＣ－ＧＥＴワークフローにおいて説明したようなＨＴＭＬボディ部分としてラップする。再フォーマットされたＣ－ＭＯＶＥ応答は、ＷＡＤＯ－ＲＳ応答としてリモートクライアントに送信される。１つの実施形態では、ユニバーサルウェブサービスエンジンが、Ｃ－ＭＯＶＥ応答全体をバッチ処理して既知のサイズの１つのＨＴＭＬオブジェクトとして戻す。別の実施形態では、ＤＩＣＯＭオブジェクトが処理されて応答項目が利用可能になると、上述したＣ－ＧＥＴワークフローと同様に応答がチャンク化されまたはストリーミングされる。

図７は、Ｃ－ＭＯＶＥを使用してＷＡＤＯ－ＲＳウェブサービス要求に対処するプロセスの１つの実施形態のフロー図である。１つの実施形態では、このプロセスが、ハードウェア（回路、専用ロジックなど）、ソフトウェア（たとえば、チップ上で実行されるソフトウェア）、ファームウェア、またはこれらの組み合わせを含むことができる処理ロジックによって実行される。１つの実施形態では、プロセスが、たとえば限定するわけではないが、図２および図３に関連して上述した医用画像管理プラットフォームなどの医用画像管理プラットフォームによって実行される。

図７を参照すると、プロセスは、処理ロジックがＷＡＤＯ－ＲＳ要求を受け取ること（処理ブロック７０１）によって開始する。１つの実施形態では、ＷＡＤＯ要求がユニバーサルアクセス（ウェブサービス）エンジンによって受け取られる。処理ロジックは、ＷＡＤＯ－ＲＳ要求に応じて、要求がＷＡＤＯ－ＲＳであると認識する（処理ブロック７０２）。１つの実施形態では、処理ロジックが、ＵＲＬの｛Ｓｅｒｖｉｃｅ｝部分を構文解析することによって要求がＷＡＤＯ－ＲＳであると認識する。１つの実施形態では、サービス認識構文解析が｛Ｓｅｒｖｉｃｅ｝の後のＵＲＬも含む。処理ロジックは、要求がＷＡＤＯ－ＲＳであると認識したことに応じて内部ＤＩＣＯＭ ＳＣＵクライアントを生成し（７０３）、最初のＷＡＤＯ－ＲＳ｛Ｓｅｒｖｉｃｅ｝要求によって識別されるＰＡＣＳ／ＶＮＡ／ＤＩＣＯＭサーバ（たとえば、ＳＣＰホスト）に送信されるＣ－ＭＯＶＥ要求を発行する（処理ブロック７０４）。

その後、処理ロジックは、Ｃ－ＭＯＶＥ要求に応じて、ＳＣＰホストからのＣ－ＳＴＯＲＥ要求を処理する（処理ブロック７１１）。１つの実施形態では、処理ロジック内のＤＩＣＯＭ ＳＣＰクライアントが、さらなる処理のために各Ｃ－ＳＴＯＲＥ応答を受け取る。ＳＣＰクライアントは、サードパーティＤＩＣＯＭライブラリを使用して生成することも、あるいはＤＩＣＯＭ標準ＰＳ３．１の仕様に従うソフトウェアにおいて構築することもできる。また、１つの実施形態では、処理ロジックが、Ｃ－ＳＴＯＲＥ応答の一部として受け取られたＤＩＣＯＭオブジェクトをキャッシュに入れる（任意）（処理ブロック７１３）。処理ロジックは、送信された全てのＣ－ＳＴＯＲＥオブジェクトが含まれていることを示すＣ－ＭＯＶＥ応答を受け取る（処理ブロック７１２）。別の実施形態では、外部ＳＣＰクライアントまたはＰＡＣＳまたはＶＮＡが、Ｃ－ＳＴＯＲＥ ＤＩＣＯＭオブジェクトを受け取って記憶し／キャッシュに入れることができる。この場合、処理ロジックは、Ｃ－ＭＯＶＥ完了応答を受け取った後に、（ＤＩＭＳＥまたはウェブサービスを介して）外部ＳＣＰ ＰＡＣＳまたは外部ＳＣＰストレージまたは外部ＳＣＰキャッシュまたは外部ＳＣＰデータベースにアクセスすることによって、ＷＡＤＯ－ＲＳによって要求されたＤＩＣＯＭオブジェクトを取得する。

処理ロジックは、受け取ったＤＩＣＯＭオブジェクトを再フォーマットし（処理ブロック７１４）、最初にＷＡＤＯ－ＲＳウェブサービス要求を生成したウェブクライアントに再フォーマットされた応答を送信する（処理ブロック７１５）。

ＷＡＤＯ－ＵＲＩワークフロー
１つの実施形態では、ＷＡＤＯ－ＵＲＩウェブ要求のためのワークフローが、上述したＣ－ＧＥＴまたはＣ－ＭＯＶＥを含むＷＡＤＯ－ＲＳのためのワークフローと同様に実装されるが、３つ変更点がある。第１に、ＵＲＬ応答当たりに１つのＤＩＣＯＭオブジェクトまたはフレームしか存在しない。第２に、ウェブ応答がｈｔｍｌボディ全体である。１つの実施形態では、ＷＡＤＯ－ＵＲＩと共にマルチパートボディ境界が使用される。第３に、ＷＡＤＯ－ＵＲＩがＤＩＣＯＭヘッダの要素のためのバルクデータ要求をサポートしていない。

ＳＴＯＷ－ＲＳワークフロー
１つの実施形態では、リモートウェブクライアントによってＳＴＯＷ－ＲＳ要求が発行された後にＳＴＯＷ－ＲＳワークフローが開始する。本明細書で説明するユニバーサルウェブサービスエンジンは、ＳＴＯＷ－ＲＳ要求を受け取った場合、またはＷＡＤＯ－ＲＳ要求内の｛ＳＥＲＶＩＣＥ｝の後のパラメータの構文解析時に要求がＷＡＤＯ－ＲＳであることを認識した場合、ＳＴＯＷボディ入力からの各ＤＩＣＯＭインスタンスをＣ－ＳＴＯＲＥに適したＤＩＣＯＭオブジェクトに変換して＜ＳＣＵ ＡＥＴ＞および＜ＳＣＰ ＡＥＴ＞を提供したＡｅＴｉｔｌｅを使用して＜ＳＣＰ Ｐｏｒｔ＞上の＜ＳＣＰ Ｈｏｓｔ＞にＣ－ＳＴＯＲＥ要求を発行する内部ＤＩＣＯＭ ＳＣＵクライアントを生成する。ＤＩＣＯＭ転送構文ネゴシエーションに応じて、ＤＩＣＯＭオブジェクトの転送構文をリモートＰＡＣＳ上でサポートされているフォーマットに変換することが必要な場合もある。ユニバーサルウェブサービスエンジンは、ＤＩＭＳＥ Ｃ－ＳＴＯＲＥを使用して、各ＤＩＣＯＭオブジェクトをリモートＰＡＣＳ／ＶＮＡ／ＤＩＣＯＭサーバ（たとえば、ＳＣＰホスト）に送信する。

その後、ＳＣＰホスト（たとえば、ＰＡＣＳ、ＶＮＡ、サーバなど）は、ストレージ要求の成功または失敗を示すＤＩＭＳＥ応答を生成して返送する。ユニバーサルウェブサービスエンジンは、ＮＥＭＡ標準ＰＳ３．１８ ６．６．１．３．２「応答メッセージボディ」の通りにＳＴＯＷステータスに変換されたＣ－ＳＴＯＲＥステータスでウェブクライアントに応答する。

図８は、ＳＴＯＷ－ＲＳウェブサービス要求に対処するプロセスの１つの実施形態である。１つの実施形態では、このプロセスが、ハードウェア（回路、専用ロジックなど）、ソフトウェア（たとえば、チップ上で実行されるソフトウェア）、ファームウェア、またはこれらの組み合わせを含むことができる処理ロジックによって実行される。１つの実施形態では、プロセスが、たとえば限定するわけではないが、図２および図３に関連して上述した医用画像管理プラットフォームなどの医用画像管理プラットフォームによって実行される。

図８を参照すると、プロセスは、処理ロジックがＳＴＯＷ－ＲＳ要求を受け取ること（処理ブロック８０１）によって開始する。処理ロジックは、ＳＴＯＷ－ＲＳ要求を受け取ったことに応じて、要求がＳＴＯＷ－ＲＳであると認識する（処理ブロック８０２）。１つの実施形態では、処理ロジックが、ＳＴＯＷ－ＲＳ｛ＳＥＲＶＩＣＥ｝をサービス識別子について構文解析することによって、要求がＳＴＯＷ－ＲＳであると認識する。１つの実施形態では、処理ロジックが、｛ＳＥＲＶＩＣＥ｝の後のパラメータも構文解析する。

処理ロジックは、要求をＳＴＯＷ－ＲＳとして認識したことに応じて内部ＤＩＣＯＭ ＳＣＵクライアントを生成し（処理ロジック８０３）、ＳＴＯＷボディ入力からの各ＤＩＣＯＭインスタンスをＣ－ＳＴＯＲＥ動作に適したＤＩＣＯＭオブジェクトに変換する（処理ブロック８０４）。たとえば、１つの実施形態では、ＤＩＣＯＭ＋ＸＭＬまたはＤＩＣＯＭ＋ＪＳＯＮフォーマットのＤＩＣＯＭヘッダデータがＤＩＣＯＭ要素に変換され、ＳＴＯＷ－ＲＳがメタデータリンクとして識別するバルクまたはバイナリコンテンツが適合され、バルクデータを含むＳＴＯＷ－ＲＳボディ部分によって置換され、ＳＴＯＷ－ＲＳによって提供されるＵＲＬリンクを使用してバルクデータを求める別のウェブ要求を行う処理ロジックによって、ＳＴＯＷ－ＲＳ要求に含まれる参照バルクデータが取得される。１つの実施形態では、処理ロジックが、ＤＩＣＯＭ転送構文ネゴシエーションに応じて、ＤＩＣＯＭオブジェクトの転送構文をリモートＰＡＣＳ／ＶＮＡ／ＤＩＣＯＭサーバによってサポートされているフォーマットに変換することができる。その後、処理ロジックは、各正常に組み立てられてフォーマットされたＤＩＣＯＭオブジェクトについて、最初のＳＴＯＷ－ＲＳウェブサービス要求によって識別されたＰＡＣＳ／ＶＮＡ／ＤＩＣＯＭサーバ（たとえば、ＳＣＰホスト）にＣ－ＳＴＯＲＥ要求を発行する（処理ブロック８０５）。

その後、処理ロジックは、Ｃ－ＳＴＯＲＥステータス応答を受け取る（処理ブロック８１１）。処理ロジックは、Ｃ－ＳＴＯＲＥステータス応答を受け取ったことに応じてＣ－ＳＴＯＲＥステータスをＳＴＯＷ－ＲＳステータスに変換し（処理ブロック８１２）、ＳＴＯＷ－ＲＳステータスを含む応答をウェブクライアントに送信する（処理ブロック８１３）。

上述したワークフローは、多くの状況で適用するのに役立つことができる。たとえば、複数のＰＡＣＳからのＤＩＣＯＭコンテンツを問い合わせて表示するベンダー中立のＤＩＣＯＭアプリケーションを開発する場合、１つの実装は、ＷｉｎｄｏｗｓユーザＩＤのような単純な認証スキーマを有するＷＡＤＯ－ＲＳ／ＱＩＤＯ－ＲＳを使用してＰＡＣＳベンダーにアクセスすることである。本明細書で説明したユニバーサルアクセスエンジンを使用しなければ、いくつかのベンダーＰＡＣＳは、クライアントが発行したＤＩＣＯＭウェブサービスを使用してサポートすることができない。たとえば、ＰＳ３．１８に完全に準拠していないｖｅｎｄｏｒ＿１は、ウェブ要求内のカスタムフィールドまたはヘッダ、あるいは応答のカスタムフォーマットを必要とする。別の例は、ユーザ名およびパスワードの手動入力を使用してウェブベースのフォームを介して生成されるＳＳＯクッキートークンのようなカスタムウェブサービス認証を備えたｖｅｎｄｏｒ＿２である。ベンダー固有のフォーマットまたは認証システムのためにコードが追加される場合、所望のＤＩＣＯＭアプリケーションはユニバーサルまたはベンダー中立ではない。また、ｖｅｎｄｏｒ＿３はＤＩＣＯＭウェブサービスをサポートしておらず、代わりに古いＤＩＭＳＥ ＤＩＣＯＭメッセージングに依拠している可能性もある。

ユニバーサルウェブサービスソフトウェアを使用すれば、ＤＩＣＯＭアプリケーションは、ユニバーサルウェブサービスソフトウェアへのＷＡＤＯ－ＲＳ／ＱＩＤＯ－ＲＳを形成することによってｖｅｎｄｏｒ＿１、ｖｅｎｄｏｒ＿２およびｖｅｎｄｏｒ３にアクセスすることができる。たとえば：
｛Ｖｅｎｄｏｒ＿１ ＳＥＲＶＩＣＥ｝＝ｈｔｔｐ：／／ｕｎｉｖｅｒｓａｌＨｏｓｔ／ｍｙＳｃｕＡＥＴ／Ｖｅｎｄｏｒ１ＡＥＴ／Ｖｅｎｄｏｒ１Ｈｏｓｔ／１０５

ＤＩＣＯＭアプリケーションは、本明細書で説明したワークフローを使用して、アプリケーション内からのＷＡＤＯ－ＲＳおよびＱＩＤＯ－ＲＳのみを使用してベンダー＿１、＿２および＿３と相互作用することができる。

別のスキーマの実施形態
上述したＵＲＬスキーマには複数の代替例がある。１つの実施形態では、ユニバーサルウェブサービスエンジンが、元々のウェブ要求における１以上のデータ（ｄａｔｕｍｓ）を使用してメモリからパラメータを取得することによって、ＤＩＭＳＥ要求のための１以上のパラメータを決定する。限定ではなく一例として、これらの１以上のデータは、ウェブサービス要求内のソース名を含む。ユニバーサルウェブサービスエンジンは、ソース名を使用してメモリ（たとえば、ルックアップテーブル）内の検索を実行して、ＤＩＭＳＥ要求のためのＤＩＣＯＭサーバ、ポートおよびＡｅＴｉｔｌｅを取得する。ウェブサービス要求内のデータに基づいて、他のタイプの情報をメモリから検索することもできる。たとえば、ソース名検索は、今やソースＰＡＣＳがＤＩＣＯＭウェブサービス対応であり、ＱＩＤＯ－ＲＳおよびＷＡＤＯ－ＲＳを使用して直接アクセスできることを示すことができる。この場合、検索は、ベンダーの別の｛ＳＥＲＶＩＣＥ２｝値を提供し、処理ロジックは、｛ＳＥＲＶＩＣＥ｝を｛ＳＥＲＶＩＣＥ２｝に置換して、修正されたＵＲＬと（存在する場合には）元々のｈｔｔｐ Ａｃｃｅｐｔ値とを含む新たなウェブ要求を行い、ベンダーから元々のクライアントに直接ウェブ応答を戻す。

１つの実施形態では、ユニバーサルＤＩＣＯＭウェブサービスが、ソース名およびルックアップテーブルを使用してリモートＰＡＣＳおよびリモート接続パラメータを識別する。
ｐｒｏｔｏｃｏｌ：／／ｗｅｂｈｏｓｔ［：ｐｏｒｔ］／［ｓｅｒｖｉｃｅＮａｍｅ］／ｓｏｕｒｃｅＮａｍｅ／｛ＮＥＭＡ ＰＳ３．１８ ｐａｒａｍｅｔｅｒｓ｝
たとえば、ＧＥＴ ｈｔｔｐ：／／ｍｙＨｏｓｔ：１０００／ｓｏｕｒｃｅ１／ｓｔｕｄｉｅｓ
処理ロジックは、これがＰＳ３．１８に準拠していないベンダーソース１のＱＩＤＯ－ＲＳクエリであると判定し、ソース１上のデータ検索を介してベンダーへのＣ－ＦＩＮＤ要求のためのＤＩＭＳＥパラメータを取得する。

なお、ある実施形態では、検索列名（ｌｏｏｋ ｕｐ ｃｏｌｕｍｎ ｎａｍｅｓ）が任意である。入力方法およびこのテーブルデータの持続は任意である。たとえば、１つの実施形態では、ＤＩＭＳＥパラメータを、フォーマットされたファイルから読み取り、レジストリキーからロードし、データベースから読み取り、ｗｅｂ．ｃｏｎｆｉｇから読み取り、あるいはユニバーサルアクセスエンジンまたはそのアプリケーション内でハードコード化することができる。

上記の例はＷＡＤＯ－ＲＳ要求に拡張することもでき、この場合はＣ－ＭＯＶＥワークフローが使用され、たとえば以下に示す宛先ＡｅＴｉｔｌｅが必要とされる。

これらの例は、ＤＩＣＯＭ ＰＳ３．１８に準拠するソースを識別するように修正することができ、検索データは、たとえば以下に示すソースが承認したウェブ要求のためのユーザ名およびパスワードを提供する。

別の実施形態では、テーブルにＳＴＯＷ－ＲＳベースＵＲＬが追加される。

さらに別の実施形態では、ＷＡＤＯ－ＵＲＩベースがＷＡＤＯ－ＲＳベースに取って代わり、またはさらなるテーブル列である。

さらに別の実施形態では、テーブルに新たな列が追加され、テーブル内に値が入力されることによってソース固有のアクセス方法（ウェブサービスまたはＤＩＭＳＥ）が決定される。この列は任意であり、アクセス方法は、ソース検索のために｛ＳＥＲＶＩＣＥ｝基準値が定められていない場合にＤＩＭＳＥを適用するような単純なロジックに従うことができる。

別の実施形態では、ＵＲＬ内のソース名データが、各々に構成されたソースに割り当てられる一意のポートに取って代わられる。たとえば、
ｐｒｏｔｏｃｏｌ：／／ｗｅｂｈｏｓｔ：ｐｏｒｔ／｛ＮＥＭＡ ｓｔａｎｄａｒｄ ＰＳ３．１８ ｐａｒａｍｅｔｅｒｓ｝
たとえば、ｈｔｔｐ：／／ｍｙＨｏｓｔ：１０００／ｓｔｕｄｉｅｓ
ポートがソース名の代わりに検索キーとして働く関連するクレーム内の変異検索テーブル（ｖａｒｉａｎｔ ｌｏｏｋｕｐ ｔａｂｌｅｓ）のいずれかによる

別の代替例では、ｓｏｕｒｃｅＮａｍｅ およびｉｎｐｕｔＰｏｒｔの両方がリモートＰＡＣＳ／ＶＮＡ／ＤＩＣＯＭサーバを識別するために使用される。たとえば、
ｐｒｏｔｏｃｏｌ：／／ｗｅｂｈｏｓｔ：ｐｏｒｔ／ｓｏｕｒｃｅＮａｍｅ／｛ＮＥＭＡ ｓｔａｎｄａｒｄ ＰＳ３．１８ ｐａｒａｍｅｔｅｒｓ｝
たとえば、ｈｔｔｐ：／／ｍｙＨｏｓｔ：１０００／ａ１／ｓｔｕｄｉｅｓ／
修正されたテーブル、またはｉｎｐｕｔＰｏｒｔが追加された変異テーブル、のいずれかによる

図９は、メモリ（たとえば、ルックアップテーブル）からのパラメータを使用してウェブサービス要求を処理するプロセスの１つの実施形態のフロー図である。１つの実施形態では、このプロセスが、ハードウェア（回路、専用ロジックなど）、ソフトウェア（たとえば、チップ上で実行されるソフトウェア）、ファームウェア、またはこれらの組み合わせを含むことができる処理ロジックによって実行される。１つの実施形態では、プロセスが、たとえば限定するわけではないが、図２および図３に関連して上述した医用画像管理プラットフォームなどの医用画像管理プラットフォームによって実行される。

図９を参照すると、プロセスは、処理ロジックがウェブサービスの要求を受け取り（処理ブロック９０１）、ソースルックアップテーブルの１以上の検索キーを決定する（処理ブロック９０２）ことによって開始する。１つの実施形態では、１以上のＵＲＬ入力パラメータが、ソース名および／またはポートを含むことができる。

処理ロジックは、ＵＲＬからサービス要求タイプを識別し、任意に９０２からの入力パラメータを使用してルックアップテーブルから適用するリモート接続方法のタイプを決定する。ルックアップテーブルを使用して、９０２から決定された情報に基づいて新たなウェブサービス要求または新たなＤＩＭＳＥ要求を行うために必要な情報を取得する（処理ブロック９０３）。１つの実施形態では、処理ロジックが、メモリ（たとえば、ルックアップテーブル）内に配置された検索に基づいて入力パラメータ９０２のためのＤＩＭＳＥパラメータを識別する。

処理ロジックは、９０３において決定されたパラメータを使用して要求を生成し（処理ブロック９０４）、生成された要求をＰＡＣＳ／ＶＮＡ／ＤＩＣＯＭサーバに送信する（処理ブロック９０５）。

例示的な医用画像管理システム
図１０に、上述した現在および以前のパラメータ値を含むレイアウトを生成して描画する医用画像および情報管理システム１０００の論理的表現の例示的な実施形態を示す。１つの実施形態では、システム１０００が、上述したような医用画像システムの一部である。

医用画像および情報管理システム１０００は、第１の伝送媒体１０２０を介して通信インターフェイスロジック１０１０に結合される１以上のプロセッサ１００１を含む。通信インターフェイスロジック１０１０は、他の電子装置との通信、とりわけ医師、看護師および／または医療技師などの遠隔ユーザ、健康管理検査資料を記憶する遠隔データベース（たとえば、ＰＡＣＳ）、検査資料を生成して送信する医療モダリティ、および１以上の遠隔地（たとえば、クラウドベースのサーバ）との通信を可能にする。本開示の１つの実施形態によれば、通信インターフェイスロジック１０１０は、有線コネクタのための１以上のポートを含む物理的インターフェイスとして実装することができる。これに加えてまたはこれに代えて、通信インターフェイスロジック１０１０は、他の電子装置との無線通信をサポートするための１以上の無線ユニットと共に実装することもできる。

（単複の）プロセッサ１００１は、第２の伝送媒体１０２５を介して持続ストレージ１０３０にさらに結合される。本開示の１つの実施形態によれば、持続ストレージ１０３０は、（ａ）インターフェイスロジック１０４１と、（ｂ）ユニバーサルアクセスエンジンロジック１０４２と、（ｃ）ウェブサービス要求認識ロジック（たとえば、パーサー）１０４３と、（ｄ）要求生成および発行ロジック１０４４と、（ｅ）ウェブサービス応答生成（たとえば、再構成）ロジック１０４５と、（ｆ）パラメータ検索ロジック１０４６と、（ｇ）レンダラ／出力生成ロジック１０３３と、（ｈ）ディスプレイ制御ロジック１０３４と、（ｉ）注記データベース１０３６と、（ｊ）記録データベース１０３７と、を実装するためのデータおよびコードを含むことができる。

１つの実施形態では、インターフェイスロジック１０４１が、クライアントおよびホストを含むプラットフォーム内のコンポーネント間、並びにユーザとディスプレイ画面上に表示されている表示領域との間の相互作用を可能にするロジックを含む。

１つの実施形態では、ユニバーサルアクセスエンジンロジック１０４２が、上述したようなウェブサービス要求およびその応答の処理および協調を可能にするロジックを含む。ウェブサービス要求認識ロジック１０４３は、受け取られたウェブサービス応答に含まれるウェブサービスのタイプを決定するロジックを含む。１つの実施形態では、ウェブサービス要求認識ロジック１０４３が、ウェブサービス要求がウェブサービス識別子を含むかどうかを判定する構文解析ロジックを含む。ＤＩＭＳＥ要求生成および発行ロジック１０４４は、上述したようなＤＩＭＳＥ要求を生成して発行するロジックを含む。ウェブサービス応答生成ロジック１０４５は、ＳＣＰホストから受け取られたＤＩＭＳＥ要求からの応答からウェブサービス応答を生成するロジックを含む。１つの実施形態では、ウェブサービス応答生成ロジック１０４５が、上述したような応答を再フォーマットする再フォーマットロジックを含む。パラメータ検索ロジック１０４６は、上述したようなＤＩＭＳＥ要求を策定する上でパラメータを使用できるように、メモリ（たとえば、ルックアップテーブル）内の検索を実行してウェブサービス要求含まれていた情報を使用してパラメータを発見するロジックを含む。

レンダラ／出力生成ロジック１０３３は、上述したようなレンダリングされた出力を生成するロジックを含む。状態の保存は、少なくとも（ｉ）１以上の情報と、（ｉｉ）非一時的コンピュータ可読媒体内の１以上の情報の各々の視認性とを記憶することを含むことができる。レイアウトテンプレートは、自動画像解析アルゴリズムからの所見に関連する画像データを示す健康管理検査資料の１以上の画像を示すことができる。

ディスプレイ制御ロジック１０３４は、上述したようなユーザインターフェイス、画像、ＤＩＣＯＭオブジェクト、検査資料またはその一部、ローカルにレンダリングされた医療記録を表示するロジックを含む。１つの実施形態では、ディスプレイ制御ロジック１０３４が、画像、上述したユーザインターフェイスを表示するブラウザページを作成するためのロジックを含む。

注記データベース１０３６は、医師、看護師、医療技師などが記録した、ユーザがレイアウトテンプレートの表示領域内にインポートできる注記を記憶する。最後に、記録データベース１０３７は、ユーザがレイアウトテンプレートの表示領域内にインポートできる医療記録を記憶する。

本明細書で説明する実施形態の例は複数存在する。

例１は、ウェブサービスエンジンにおいて、１以上の医用におけるデジタル画像と通信（ＤＩＣＯＭ）オブジェクトのためのリモートウェブクライアントからウェブサービス要求を受け取ることと、ウェブサービス要求からＤＩＭＳＥサービス要求を生成することであって、ＤＩＭＳＥサービス要求のための情報を含む修正されたベースＵＲＬを構文解析することを含み、修正されたベースＵＲＬが、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠する、ＤＩＭＳＥサービス要求を生成することと、ＤＩＭＳＥサービス要求をサーバに送信することと、サーバからＤＩＭＳＥサービス要求に対する応答を受け取ることと、応答を、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠するように再フォーマットすることと、再フォーマットされた応答をリモートウェブクライアントに戻すことと、を含む方法である。

例２は、修正されたベースＵＲＬが、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ要求のために必要な情報を含む、ということを任意に含むことができる例１の方法である。

例３は、標準が、ＮＥＭＡ ＤＩＣＯＭウェブサービス標準ＰＳ３．１８である、ということを任意に含むことができる例２の方法である。

例４は、ウェブサービス要求が、ＱＩＤＯ－ＲＳ、ＷＡＤＯ－ＲＳ、ＳＴＯＷ－ＲＳまたはＷＡＤＯ－ＵＲＩ要求を含み、ＤＩＭＳＥサービス要求が、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ動作を含む、ということを任意に含むことができる例１の方法である。

例５は、ベースＵＲＬの後にウェブサービス要求を構文解析してウェブサービスのタイプを識別することと、ＤＩＣＯＭクライアントを生成することと、識別されたウェブサービスのタイプに基づいて選択された１つのＤＩＭＳＥサービスをＤＩＣＯＭクライアントにより発行することと、を任意に含むことができる例１の方法である。

例６は、ウェブサービス要求が、１以上のデータを含み、方法が、１以上のデータを使用してＤＩＭＳＥ要求のための１以上のパラメータをメモリから取得することによって１以上のパラメータを決定することをさらに含む、ということを任意に含むことができる例１の方法である。

例７は、１以上のデータが、リモートサーバにアクセスするための接続方法を決定するために使用される、ということを任意に含むことができる例６の方法である。

例８は、医用画像管理システムであって、１以上のＤＩＣＯＭオブジェクトのためのリモートウェブクライアントからウェブサービス要求を受け取るネットワーク通信インターフェイスと、ネットワーク通信インターフェイスに結合されて、受け取った健康管理検査資料を記憶するメモリと、メモリに結合されて、受け取った健康管理検査資料を表示するディスプレイ画面と、ネットワーク接続インターフェイス、メモリおよびディスプレイ画面に結合される１以上のプロセッサとを備え、１以上のプロセッサが、ウェブサービス要求からＤＩＭＳＥサービス要求を生成し、ＤＩＭＳＥサービス要求を生成することは、ＤＩＭＳＥサービスのための情報を含む修正されたベースＵＲＬを構文解析することを含み、修正されたＵＲＬは、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠し、ＤＩＭＳＥサービス要求は、ネットワーク通信インターフェイスを介してサーバに送信され、ネットワーク通信インターフェイスを介してサーバから受け取られた、ＤＩＭＳＥサービス要求に対する応答を再フォーマットし、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠する再フォーマットされた応答を、ネットワーク通信インターフェイスを介してリモートウェブクライアントに戻すように構成される、システムである。

例９は、修正されたベースＵＲＬが、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ要求のために必要な情報を含む、ということを任意に含むことができる例８のシステムである。

例１０は、標準が、ＮＥＭＡ ＤＩＣＯＭウェブサービス標準ＰＳ３．１８であることを任意に含む、ということができる例９のシステムである。

例１１は、ウェブサービス要求が、ＱＩＤＯ－ＲＳ、ＷＡＤＯ－ＲＳ、ＳＴＯＷ－ＲＳまたはＷＡＤＯ－ＵＲＩ要求を含み、ＤＩＭＳＥサービス要求が、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ動作を含む、ということを任意に含むことができる例８のシステムである。

例１２は、１以上のプロセッサが、ベースＵＲＬの後にウェブサービス要求を構文解析してウェブサービスのタイプを識別し、ＤＩＣＯＭクライアントを生成し、ＤＩＣＯＭクライアントを使用して、識別されたウェブサービスのタイプに基づいて選択された１つのＤＩＭＳＥサービスを発行するように構成される、ということを任意に含むことができる例８のシステムである。

例１３は、ウェブサービス要求が、１以上のデータを含み、１以上のプロセッサが、１以上のデータを使用してＤＩＭＳＥ要求のための１以上のパラメータをメモリから取得することによって１以上のパラメータを決定するように構成される、ということを任意に含むことができる例８のシステムである。

例１４は、１以上のデータが、リモートサーバにアクセスするための接続方法を決定するために使用される、ということを任意に含むことができる例１３のシステムである。

例１５は、命令を記憶した非一時的コンピュータ可読記憶媒体であって、命令が、少なくともプロセッサと、メモリと、ディスプレイ画面とを有するシステムによって実行された時に、システムに、ウェブサービスエンジンにおいて、１以上の医用におけるデジタル画像と通信（ＤＩＣＯＭ）オブジェクトのためのリモートウェブクライアントからウェブサービス要求を受け取ることと、ウェブサービス要求からＤＩＭＳＥサービス要求を生成することであって、ＤＩＭＳＥサービスのための情報を含むサービスのための修正されたベースＵＲＬを構文解析することを含み、ＤＩＭＳＥサービス要求は、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠する、ＤＩＭＳＥサービス要求を生成することと、ＤＩＭＳＥサービス要求をサーバに送信することと、サーバからＤＩＭＳＥサービス要求に対する応答を受け取ることと、応答を、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠するように再フォーマットすることと、再フォーマットされた応答をリモートウェブクライアントに戻すことと、を含む方法を実行させる、コンピュータ可読記憶媒体である。

例１６は、標準が、ＮＥＭＡ ＤＩＣＯＭウェブサービス標準ＰＳ３．１８であり、さらに、修正されたベースＵＲＬが、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ要求のために必要な情報を含む、ということを任意に含むことができる例１６のコンピュータ可読記憶媒体である。

例１７は、ウェブサービス要求が、ＱＩＤＯ－ＲＳ、ＷＡＤＯ－ＲＳ、ＳＴＯＷ－ＲＳまたはＷＡＤＯ－ＵＲＩ要求を含み、ＤＩＭＳＥサービス要求が、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ動作を含む、ということを任意に含むことができる例１７のコンピュータ可読記憶媒体である。

例１８は、方法が、ベースＵＲＬの後にウェブサービス要求を構文解析してウェブサービスのタイプを識別することと、ＤＩＣＯＭクライアントを生成することと、識別されたウェブサービスのタイプに基づいて選択された１つのＤＩＭＳＥサービスをＤＩＣＯＭクライアントにより発行することと、をさらに含む、ということを任意に含むことができる例１８のコンピュータ可読記憶媒体である。

例１９は、ウェブサービス要求が、１以上のデータを含み、方法が、１以上のデータを使用してＤＩＭＳＥ要求のための１以上のパラメータをメモリから取得することによって１以上のパラメータを決定することをさらに含む、ということを任意に含むことができる例１５のコンピュータ可読記憶媒体である。

例２０は、１以上のデータが、リモートサーバにアクセスするための接続方法を決定するために使用される、ということを任意に含むことができる例１９のコンピュータ可読記憶媒体である。

例２１は、医用画像管理システムであって、１以上のクライアントおよび１以上のリモートサーバと通信するネットワークインターフェイスと、１以上のクライアントから、１以上のリモートサーバに向けられた第１の要求セットを受け取り、第１の要求セットに応じて、ＤＩＣＯＭウェブサービス要求またはＤＩＭＳＥ要求である第２の要求セットをリモートサーバに発行する、回路を有するアクセスエンジンと、を含む医用画像管理システムである。

例２２は、ＤＩＣＯＭウェブサービス要求が、ＱＩＤＯ－ＲＳ、ＷＡＤＯ－ＲＳ、ＳＴＯＷ－ＲＳまたはＷＡＤＯ－ＵＲＩ要求を含み、ＤＩＭＳＥ要求が、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ動作を含む、ということを任意に含むことができる例２１の医用画像管理システムである。

例２３は、第１の要求セットのうちの少なくとも１つが、１以上のデータを含み、アクセスエンジンが、１以上のデータおよび任意の持続データからウェブサービスまたはＤＩＭＳＥのどちらを使用すべきであるかを決定し、アクセスエンジンが、１以上のデータおよび任意の持続データから有効な要求を生成してリモートサーバに発行することができる、ということを任意に含むことができる例２１の医用画像管理システムである。

上記の詳細な説明の一部は、コンピュータメモリ内のデータビットに対する演算のアルゴリズムおよび記号的表現の観点から示したものである。これらのアルゴリズム的な記述および表現は、データ処理技術における当業者が自らの研究内容を他の当業者に最も効果的に伝えるために使用する手段である。ここで、および一般的に、アルゴリズムとは、望ましい結果をもたらす首尾一貫した一連のステップであると考えられる。これらのステップは、物理量の物理的操作を必要とするものである。これらの量は、必ずというわけではないが、通常は、記憶、転送、合成、比較および他の形の操作が可能な電気または磁気信号の形を取る。主に共通使用という理由で、時にはこれらの信号を、ビット、値、要素、記号、文字、用語、番号などと呼ぶことが便利であると分かっている。

しかしながら、これらのおよび同様の用語は、全て適切な物理量に関連付けられるべきものであり、またこれらの量に与えられた便利な表記に過ぎないことに留意されたい。以下の説明から明らかなように、特に別途述べていない限り、説明全体を通じて「処理する（ｐｒｏｃｅｓｓｉｎｇ）」、「算出する（ｃｏｍｐｕｔｉｎｇ）」、「計算する（ｃａｌｃｕｌａｔｉｎｇ）」、「決定する（ｄｅｔｅｒｍｉｎｉｎｇ）」または「表示する（ｄｉｓｐｌａｙｉｎｇ）」などの用語を利用した説明は、コンピュータシステムのレジスタおよびメモリ内の物理（たとえば、電子）量として表されるデータを操作し、コンピュータシステムのメモリ、レジスタ、またはその他のこのような情報記憶装置、送信または表示装置内の物理量として同様に表される他のデータに変形させるコンピュータシステムまたは同様の電子コンピュータ装置の動作および処理を意味すると理解されたい。

本発明は、本明細書の動作を実行する装置にも関する。この装置は、必要な目的のために特別に構成することも、あるいはコンピュータに記憶されたコンピュータプログラムによって選択的に起動または再構成される汎用コンピュータを含むこともできる。このようなコンピュータプログラムは、以下に限定されるわけではないが、フロッピーディスク、光ディスク、ＣＤ－ＲＯＭ、および光磁気ディスクを含むあらゆる種類のディスク、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、あるいは電子命令を記憶するのに適したあらゆるタイプの媒体などのコンピュータ可読記憶媒体に記憶することができ、これらはそれぞれコンピュータシステムバスに結合される。

本明細書に示すアルゴリズムおよび表示は、本質的にいずれかの特定のコンピュータまたはその他の装置に関連するものではない。本明細書の教示に従うプログラムと共に様々な汎用システムを使用することもでき、あるいはいくつかの実施形態の方法を実行するために、より特殊化した装置を構成することが便利であると証明することもできる。以下の説明から、これらの様々なシステムに必要な構造が明らかになるであろう。また、本発明は、いずれかの特定のプログラミング言語を参照しながら説明したものではない。本明細書で説明した本発明の教示を実施するために、様々なプログラミング言語を使用することができると理解されるであろう。

機械可読媒体は、機械（コンピュータなど）による読み取りが可能な形で情報を記憶または送信するいずれかの機構を含むことができる。たとえば、機械可読媒体は、リードオンリメモリ（「ＲＯＭ」）、ランダムアクセスメモリ（「ＲＡＭ」）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、電気、光、音響またはその他の形の伝播信号（たとえば、搬送波、赤外線信号、デジタル信号など）などを含む。

上記の説明を読めば、当業者には本発明の多くの変更および修正が明らかになると思われるが、一例として図示し説明したあらゆる特定の実施形態は、決して限定的と見なされるように意図したものではないと理解されたい。従って、様々な実施形態の詳細についての言及は、本発明にとって必須とみなされる特徴のみを記載した特許請求の範囲を限定するように意図したものではない。

Claims (23)

1. ウェブサービスエンジンにおいて、１以上の医用におけるデジタル画像と通信（ＤＩＣＯＭ）オブジェクトのためのリモートウェブクライアントからウェブサービス要求を受け取ることと、
   前記ウェブサービス要求からＤＩＭＳＥサービス要求を生成することであって、ＤＩＭＳＥサービス要求のための情報を含む修正されたベースＵＲＬを構文解析することを含み、前記修正されたベースＵＲＬが、ＤＩＣＯＭオブジェクトにアクセスして当該ＤＩＣＯＭオブジェクトを提示するためのウェブベースサービスを指定する標準に準拠する、前記ＤＩＭＳＥサービス要求を生成することと、
   前記ＤＩＭＳＥサービス要求をサーバに送信することと、
   前記サーバから前記ＤＩＭＳＥサービス要求に対する応答を受け取ることと、
   前記応答を、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する前記標準に準拠するように再フォーマットすることと、
   前記再フォーマットされた応答を前記リモートウェブクライアントに戻すことと、
   を含む、方法。
2. 前記修正されたベースＵＲＬは、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ要求のために必要な情報を含む、
   請求項１に記載の方法。
3. 前記標準は、ＮＥＭＡ ＤＩＣＯＭウェブサービス標準ＰＳ３．１８である、
   請求項２に記載の方法。
4. 前記ウェブサービス要求は、ＱＩＤＯ－ＲＳ、ＷＡＤＯ－ＲＳ、ＳＴＯＷ－ＲＳまたはＷＡＤＯ－ＵＲＩ要求を含み、前記ＤＩＭＳＥサービス要求は、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ動作を含む、
   請求項１に記載の方法。
5. 前記ベースＵＲＬの後に前記ウェブサービス要求を構文解析してウェブサービスのタイプを識別することと、
   ＤＩＣＯＭクライアントを生成することと、
   識別されたウェブサービスの前記タイプに基づいて選択された１つのＤＩＭＳＥサービスを前記ＤＩＣＯＭクライアントにより発行することと、
   をさらに含む、請求項１に記載の方法。
6. 前記ウェブサービス要求は、１以上のデータを含み、前記方法は、前記１以上のデータを使用して前記ＤＩＭＳＥ要求のための１以上のパラメータをメモリから取得することによって前記１以上のパラメータを決定することをさらに含む、
   請求項１に記載の方法。
7. 前記１以上のデータは、リモートサーバにアクセスするための接続方法を決定するために使用される、
   請求項６に記載の方法。
8. 医用画像管理システムであって、
   １以上のＤＩＣＯＭオブジェクトのためのリモートウェブクライアントからウェブサービス要求を受け取るネットワーク通信インターフェイスと、
   前記ネットワーク通信インターフェイスに結合されて、受け取った健康管理検査資料を記憶するメモリと、
   前記メモリに結合されて、前記受け取った健康管理検査資料を表示するディスプレイ画面と、
   前記ネットワーク接続インターフェイス、前記メモリおよび前記ディスプレイ画面に結合される１以上のプロセッサであって、
   前記ウェブサービス要求からＤＩＭＳＥサービス要求を生成し、前記ＤＩＭＳＥサービス要求を生成することは、ＤＩＭＳＥサービスのための情報を含む修正されたベースＵＲＬを構文解析することを含み、前記修正されたＵＲＬは、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠し、前記ＤＩＭＳＥサービス要求は、前記ネットワーク通信インターフェイスを介してサーバに送信され、
   前記ネットワーク通信インターフェイスを介して前記サーバから受け取られた、前記ＤＩＭＳＥサービス要求に対する応答を再フォーマットし、
   ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する前記標準に準拠する前記再フォーマットされた応答を、前記ネットワーク通信インターフェイスを介して前記リモートウェブクライアントに戻す、
   ように構成される１以上のプロセッサと、
   を備える、システム。
9. 前記修正されたベースＵＲＬは、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ要求のために必要な情報を含む、
   請求項８に記載のシステム。
10. 前記標準は、ＮＥＭＡ ＤＩＣＯＭウェブサービス標準ＰＳ３．１８である、
    請求項９に記載のシステム。
11. 前記ウェブサービス要求は、ＱＩＤＯ－ＲＳ、ＷＡＤＯ－ＲＳ、ＳＴＯＷ－ＲＳまたはＷＡＤＯ－ＵＲＩ要求を含み、前記ＤＩＭＳＥサービス要求は、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ動作を含む、
    請求項８に記載のシステム。
12. 前記１以上のプロセッサは、
    前記ベースＵＲＬの後に前記ウェブサービス要求を構文解析してウェブサービスのタイプを識別し、
    ＤＩＣＯＭクライアントを生成し、
    前記ＤＩＣＯＭクライアントを使用して、識別されたウェブサービスの前記タイプに基づいて選択された１つのＤＩＭＳＥサービスを発行する、
    ように構成される、請求項８に記載のシステム。
13. 前記ウェブサービス要求は、１以上のデータを含み、前記１以上のプロセッサは、前記１以上のデータを使用して前記ＤＩＭＳＥ要求のための１以上のパラメータをメモリから取得することによって前記１以上のパラメータを決定するように構成される、
    請求項８に記載のシステム。
14. 前記１以上のデータは、リモートサーバにアクセスするための接続方法を決定するために使用される、
    請求項１３に記載のシステム。
15. 命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記命令は、少なくともプロセッサと、メモリと、ディスプレイ画面とを有するシステムによって実行されたとき、前記システムに、
    ウェブサービスエンジンにおいて、１以上の医用におけるデジタル画像と通信（ＤＩＣＯＭ）オブジェクトのためのリモートウェブクライアントからウェブサービス要求を受け取ることと、
    前記ウェブサービス要求からＤＩＭＳＥサービス要求を生成することであって、ＤＩＭＳＥサービスのための情報を含むサービスのための修正されたベースＵＲＬを構文解析することを含み、前記ＤＩＭＳＥサービス要求は、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する標準に準拠する、前記ＤＩＭＳＥサービス要求を生成することと、
    前記ＤＩＭＳＥサービス要求をサーバに送信することと、
    前記サーバから前記ＤＩＭＳＥサービス要求に対する応答を受け取ることと、
    前記応答を、ＤＩＣＯＭオブジェクトにアクセスして提示するためのウェブベースサービスを指定する前記標準に準拠するように再フォーマットすることと、
    前記再フォーマットされた応答を前記リモートウェブクライアントに戻すことと、
    を含む方法を実行させる、コンピュータ可読記憶媒体。
16. 前記標準は、ＮＥＭＡ ＤＩＣＯＭウェブサービス標準ＰＳ３．１８であり、さらに、前記修正されたベースＵＲＬは、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ要求のために必要な情報を含む、
    請求項１５に記載のコンピュータ可読記憶媒体。
17. 前記ウェブサービス要求は、ＱＩＤＯ－ＲＳ、ＷＡＤＯ－ＲＳ、ＳＴＯＷ－ＲＳまたはＷＡＤＯ－ＵＲＩ要求を含み、前記ＤＩＭＳＥサービス要求は、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ動作を含む、
    請求項１５に記載のコンピュータ可読記憶媒体。
18. 前記方法は、
    前記ベースＵＲＬの後に前記ウェブサービス要求を構文解析してウェブサービスのタイプを識別することと、
    ＤＩＣＯＭクライアントを生成することと、
    識別されたウェブサービスの前記タイプに基づいて選択された１つのＤＩＭＳＥサービスを前記ＤＩＣＯＭクライアントにより発行することと、
    をさらに含む、請求項１５に記載のコンピュータ可読記憶媒体。
19. 前記ウェブサービス要求は、１以上のデータを含み、前記方法は、前記１以上のデータを使用して前記ＤＩＭＳＥ要求のための１以上のパラメータをメモリから取得することによって前記１以上のパラメータを決定することをさらに含む、
    請求項１５に記載のコンピュータ可読記憶媒体。
20. 前記１以上のデータは、リモートサーバにアクセスするための接続方法を決定するために使用される、
    請求項１９に記載のコンピュータ可読記憶媒体。
21. １以上のクライアントおよび１以上のリモートサーバと通信するネットワークインターフェイスと、
    回路を有し、前記１以上のクライアントから、前記１以上のリモートサーバに向けられた第１の要求セットを受け取り、前記第１の要求セットに応じて、ＤＩＣＯＭウェブサービス要求またはＤＩＭＳＥ要求である第２の要求セットを前記リモートサーバに発行するアクセスエンジンと、
    を備える、医用画像管理システム。
22. 前記ＤＩＣＯＭウェブサービス要求は、ＱＩＤＯ－ＲＳ、ＷＡＤＯ－ＲＳ、ＳＴＯＷ－ＲＳまたはＷＡＤＯ－ＵＲＩ要求を含み、前記ＤＩＭＳＥ要求は、ＤＩＣＯＭ Ｃ－ＦＩＮＤ、Ｃ－ＧＥＴ、Ｃ－ＭＯＶＥまたはＣ－ＳＴＯＲＥ動作を含む、
    請求項２１に記載の医用画像管理システム。
23. 前記第１の要求セットのうちの少なくとも１つは、１以上のデータを含み、前記アクセスエンジンは、１以上のデータおよび任意の持続データからウェブサービスまたはＤＩＭＳＥのどちらを使用すべきであるかを決定し、前記アクセスエンジンは、１以上のデータおよび任意の持続データから有効な要求を生成して前記リモートサーバに発行することができる、
    請求項２１に記載の医用画像管理システム。

Images