JP2019537481A - 医用画像処理からの三次元プリンティング、ホログラフィ及び仮想現実レンダリングのためのシステム及び方法 - Google Patents

Abstract

ワークフローがネットワークを通じて提供される。ネットワークサーバは、ネットワークを介して、３Ｄセグメント化された医用画像データを３Ｄプリンタでプリントするためのプリント可能な又は閲覧するためにレンダリングされる情報に変換する要求を受信する。変換されたデータへのアクセスは１人以上の許可ユーザに制限される。３Ｄセグメント化された医用画像データを変換されたデータファイルに変換する。変換されたデータファイルは、特定の人体解剖学的構造又は対象領域の複数のサブセグメント化を可能にする医用画像データファイル形式である。医用画像データファイル形式は、マスクセグメント化情報、カラーパレット、シャドーイング、透明度、及び不透明度の格納を可能にする。

Description

本発明の実施形態は、一般に、医療情報処理システムに関する。より詳細には、発明の実施形態は、医用画像処理からの三次元プリンティング、ホログラフィック、及びバーチャルリアリティレンダリングに関する。

三次元（３Ｄ）プリンティングは、デジタルファイルから三次元立体オブジェクトの生成を可能にする。積層プロセスにおいて、完全に形成されたオブジェクトが生成されるまで、一方の層が他方の層の後に追加される。３Ｄプリンティングは多くの医療用用途を有する。例えば、癌性腫瘍の３Ｄプリントモデルは、抗癌剤、並びに、腫瘍がどのように発生し、成長し、及び拡散するかを研究する際に用いられてきた。

３Ｄプリンティングは組織工学にも用いられてきた。例えば、血管の置換、骨への化学物質の結合、心臓弁の製造、人間の耳の複製、合成皮膚の作成、合成器官の作成、及び薬剤のプリンティングにおける３Ｄプリンタの使用について研究が行われてきた。

医療環境においてプリンティングアプリケーションを可能にするネットワークを示す略ブロック図である。 ３Ｄプリンティングのためのデータアクセス制御及び画像処理を示す略ブロック図である。 プリンティングプロセスのためのワークフローを示す略フロー図である。 ３Ｄプリンティングクラウドに送信することができるセグメント化モデルを生成するためのグラフィックユーザインタフェースの使用を示す。 グラフィックユーザインタフェースの使用を示し、モジュールへの色の適用、及びネットワーク内の事業体間で交換可能なファイルへのカラーパレットの埋め込みを示す。 ＤＩＣＯＭファイルのストレージ構造を示すブロック図である。 プリント前に実行されるファイル変換ワークフローを示す。 幾つかのアプリケーションをロードし、レンダリングすることができる医療用ホログラフィックプラットフォームのためのグラフィックユーザインタフェースを示す。 元の二次元（２Ｄ）放射線図（軸方向、冠状、及び矢状）を用いる医療ボリューム（心臓）レンダリングのグラフィックユーザインタフェース表示を示す。 人体特定領域、特に大動脈弁、大動脈基部、及び冠動脈入口点の視覚化を補助する切断平面を有する特定の視野角の医療ホログラムレンダリングを示す。 ホログラム作成、ホログラムローディング、クライアントサーバ接続、及びクライアントとレンダリングサーバとの間のホログラム操作を示す略フロー図である。 ホログラム作成、ローディング、及び複数のクライアントと単一のレンダリングサーバとの間のホログラム操作を示す略フロー図である（図１６／１及び図１６／２を含む）。 医療用ホログラフィックプラットフォームの使用を示す略ブロック図である。 複数のアプリケーションによるホログラフィック環境を示す略ブロック図である。

図１は、一実施形態による医用画像の三次元（３Ｄ）プリンティングを用いるクラウドベースの画像処理システム（３Ｄプリンティングシステムと称する）を示すブロック図である。図１は、ネットワークを介して１つ以上のクラウドシステムに通信可能に結合される１つ以上の事業体又は機関を含むシステム１００を示す。事業体は、世界中に存在する様々な施設を有する医療機関等の様々な組織を表してもよい。事業体は、世界中に存在する様々な施設を有する医療機関、ファイル変換機関、プリンティング機関、又はそれらの任意の組み合わせ等の様々な組織を表してもよい。例えば、事業体は、単数又は複数の画像取込装置１０４、画像格納システム（例えば、ＰＡＣＳ）１０５、ルータ１０６、及び／又はデータゲートウェイマネージャ１０７を含むか又はそれらに関連付けられてもよい。画像格納システム１０５は、事業体１０１にアーカイビングサービスを提供する第三者事業体によって維持されてもよく、それは管理者又は事業体１０１に関連するユーザ等のワークステーション１０８によってアクセスされてもよい。本願全体を通して、医療機関は組織事業体の一例として利用されることに留意されたい。しかし、それ程限定されず、プリンティング事業体及び／又はファイル変換事業体等の他の組織又は事業体も適用されてもよい。

一実施形態において、クラウド１０３は、１つ以上のサービスプロバイダに関連付けられ、ネットワークを介して地理的に分散された一組のサーバ又はサーバのクラスタを表してもよい。例えば、クラウド１０３は、Ｃａｌｉｆｏｒｎｉａ州Ｆｏｓｔｅｒ ＣｉｔｙのＴｅｒａＲｅｃｏｎ等の医用画像処理サービスプロバイダと関連付けられてもよい。例えば、クラウド１０３は、Ｃａｌｉｆｏｒｎｉａ州Ｆｏｓｔｅｒ ＣｉｔｙのＴｅｒａＲｅｃｏｎ等の医用画像処理サービスプロバイダ、プリンティングサービスプロバイダ、ファイル変換サービスプロバイダ、又はそれらの任意の組み合わせ（図示せず）と関連付けられてもよい。プリンティングタスクは、３Ｄプリンティングサービスを通じて外部化することができるか、又は、事業体がそれ自体のプリンティング機能を有している場合はローカルに配置することができる。ローカルに配置されたプリンティング機能の場合、変換サービス（クラウドベース又はローカルに配置されてもよい）は、３Ｄプリンタによってサポートされている形式のプリント可能ファイルを提供する。ネットワークは、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、インターネット又はイントラネット等の広域ネットワーク（ＷＡＮ）、又はそれらの組み合わせであってもよい。クラウド１０３は、ネットワークを介してアプリケーションサービスを様々なクライアント１１３（例えば、タブレットコンピューティングデバイス、モバイルデバイス、デスクトップ、ラップトップ、又はそれらの任意の組み合わせ）に提供することができる様々なサーバ及びデバイスで構成することができる。一実施形態において、クラウド１０３は、画像処理サービスを提供するための１つ以上のクラウドサーバ１０９と、画像及び他の医療データを格納するための１つ以上のデータベース１１０と、他の事業体へ／からデータを転送するための１つ以上のルータ１１２とを含んでいる。クラウドサーバがサーバクラスタ又は１つを超えるサーバからなる場合、クラスタ内のサーバ間のデータ転送を制御する規則が存在していてもよい。例えば、１つの国のサーバ上のデータを別の国のサーバに配置してはいけない理由がある可能性がある。

サーバ１０９は、ネットワークを介してクライアント１１３に医用画像処理サービスを提供するための画像処理サーバであってもよい。例えば、サーバ１０９は、ｉＮｔｕｉｔｉｏｎサーバ、ＴｅｒａＲｅｃｏｎ ＡｑｕａｒｉｕｓＮＥＴ（商標）サーバ、及び／又はＴｅｒａＲｅｃｏｎ ＡｑｕａｒｉｕｓＡＰＳサーバの一部として実装されてもよい。ユーザは、画像処理を実行するよう要求をサーバ１０９に送信することができるクライアントデバイス１１３上で画像を操作することができる。データゲートウェイマネージャ１０７及び／又はルータ１０６は、ＴｅｒａＲｅｃｏｎ ＡｑｕａｒｉｕｓＧＡＴＥデバイスの一部として実装されてもよい。医用撮像装置１０４は、血管、Ｘ線、ＣＴ装置、ＭＲＩ走査装置、核医学装置、超音波装置、又は他の任意の医用撮像装置等の画像診断装置であってもよい。医用撮像装置１０４は、標本の複数の断面図から情報を収集し、それらを再構成し、複数の断面図に関する医用画像データを生成する。医用撮像装置１０４はモダリティとも称される。

データベース１１０は、医療におけるデジタル画像と通信（ＤＩＣＯＭ）互換データ又は他の画像データ等の医療データを格納するためのデータストアであってもよい。データベース１１０は、また、暗号化機能を組み込んでもよい。データベース１１０は複数のデータベースを含んでもよく及び／又はストレージプロバイダ等のサードパーティベンダによって保守されてもよい。データストア１１０は、リレーショナルデータベース管理システム（ＲＤＢＭＳ）、例えば、Ｏｒａｃｌｅ（商標）データベース又はＭｉｃｒｏｓｏｆｔ（登録商標）ＳＱＬサーバ、等により実装されてもよい。クライアント１１３は、デスクトップ、ラップトップ、タブレットコンピューティングデバイス、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）等のような様々なクライアントデバイスを表してもよい。幾つかのクライアント１１３は、医用画像処理ツール等のリソースにアクセスするクライアントアプリケーション（例えば、シンクライアントアプリケーション）又はネットを介してサーバ１０９によってホストされるアプリケーションを含んでいてもよい。シンクライアントの実施例は、Ｗｅｂブラウザ、電話アプリケーション等を含む。クライアントアプリケーションは、ネットワークを介してプリントするオプションを有することができる。

一実施形態によれば、サーバ１０９は、医療機関からの医師、保険会社からの外交員、患者、医学研究者等を代表してもよいクライアント１１３に高度画像処理サービスを提供するよう構成される。クラウドサーバ１０９は、画像処理とも称され、１つ以上の医用画像及び医用画像に関連するデータのホストとして動作する能力を有して、クライアント１１３等の複数の参加者が協働する方法で又は会議環境において画像の検討／処理フォーラムに参加することを可能にする。異なる参加者は、検討セッション又は画像のワークフロープロセスの異なる段階及び／又はレベルに参加してもよい。それらの役割（医師、保険外交員、患者、サードパーティのデータアナリスト、研究者等）に関連する権限に応じて、様々な参加者は、画像に関連付けられた患者のプライバシーを損なうことなく、画像に関する情報の一部又はツール及び機能のサブセットにのみアクセスするよう制限されてもよい。それらの役割に関連付けられた権限に応じて、様々な参加者は画像を操作、マスキング、及び／又は色付けすることができる。サーバ１０９は、任意の保護医療情報を削除するよう任意のデータファイルを匿名化及び／又は非特定化することができる。

幾つかの実施形態によれば、データゲートウェイマネージャ１０７は、医療機関等のデータプロバイダ（例えば、ＰＡＣＳシステム）へ／から医療データを自動的又は手動で転送するよう構成される。かかるデータゲートウェイ管理は、管理者又はその他の認可された人員によって構成されてもよい一組の規則又はポリシーに基づいて実行されてもよい。一実施形態において、クラウド内で行われる画像検討セッション又は画像処理操作中の医用画像データの更新に応答して、データゲートウェイマネージャは、更新された画像データ又は更新された画像データと元の画像データとの間の相違を元の医用画像データを提供したＰＡＣＳ１０５等のデータプロバイダにネットワーク（例えば、インターネット）を介して送信するよう構成される。同様に、データゲートウェイマネージャ１０７は、データプロバイダから任意の新規画像及び／又は画像データを送信するよう構成することができ、ここで新規画像は事業体１０１に関連付けられた画像取込装置１０４等の画像取込装置によって取り込まれていてもよい。加えて、データゲートウェイマネージャ１０７は、更に、同じ事業体（例えば、医療機関の複数の施設）に関連付けられる複数のデータプロバイダ間でデータを転送してもよい。更に、クラウド１０３は、クラウドシステムによって提供されるある特定の高度画像処理リソースを用いて受信画像のある特定の前処理操作を自動的に実行するよう高度前処理システム（図示せず）を含んでいてもよい。例えば、前処理システムは画像を前処理して、ユーザが骨除去等の所定のモデルによりモデリングを開始できるようにすることができる（すなわち、画像は、ユーザが骨のない画像を閲覧できるように、骨を除去するよう前処理され得る）。一実施形態において、ゲートウェイマネージャ１０７は、ある特定のインターネットポートを介してクラウド１０３と通信するよう構成されている。転送されているデータは、様々な暗号化及び圧縮方法を用いて暗号化及び／又は圧縮されてもよい。この文脈における用語「インターネットポート」は、また、イントラネットポート又はイントラネット上のプライベートポートであってもよい。

一実施形態において、変換クラウドは、１つ以上のサービスプロバイダに関連付けられ、ネットワークを介して地理的に分散された一組のサーバ又はサーバのクラスタを表してもよい。例えば、変換クラウドは、ＤＩＣＯＭファイルを２Ｄ、３Ｄ、及び／又は４Ｄプリンタと互換性のあるファイル形式に変換することができるファイル変換サービスに関連付けられてもよい。４Ｄプリンティングが意味するものは、刺激に反応して予めプログラムされた方法で変形することができる構造のプリンティングである。別の実施例において、変換クラウドは、ＤＩＣＯＭファイルをホログラフィックディスプレイと互換性のあるファイル形式に変換することができるファイル変換サービスに関連付けられてもよい。一実施形態において、変換クラウドは、ファイル変換サービスを提供するための１つ以上の変換サーバ１１４、画像及び他の医療データを格納するか及び／又は２Ｄ、３Ｄ、及び／又は４Ｄプリンタ又はホログラフィックディスプレイと互換性のある任意のファイル形式を格納するための１つ以上のデータベース、及び他の事業体（図示せず）に／からデータを転送するための１つ以上のルータを含むことができる。クラウドサーバがサーバクラスタ又は１つを超えるサーバからなる場合、クラスタ内のサーバ間のデータ転送を制御する規則が存在していてもよい。

変換サーバ１１４は、ネットワークを介してＤＩＣＯＭファイル／非ＤＩＣＯＭファイルを２Ｄ、３Ｄ、及び／又は４Ｄプリンタと互換性のある（又は読み取り可能な）ファイル形式に変換することに関するサービスを提供するためのファイル変換サーバであってもよい。変換サーバ１１４は、ネットワークを介してＤＩＣＯＭファイルをホログラフィックディスプレイと互換性のある（読み取り可能な）ファイル形式に変換することに関するサービスを提供するためのファイル変換サーバであってもよい。変換サーバ１１４はＤＩＣＯＭファイルを受信することができる。変換サーバ１１４は、匿名化及び／又は非特定化されたＤＩＣＯＭファイルを受信することができる。ＤＩＣＯＭファイルはファイルの種類の一例に過ぎないが、ファイルは任意の撮像ファイルであってもよい。変換は、例えば、ＤＩＣＯＭファイルを、例えば、ＯＢＪ、ＳＴＬ、ＶＲＭＬ、Ｘ３Ｇ、ＰＬＹ、ＦＢＸ、ＨＤＦ、他の任意の互換形式、又はそれらの任意の組み合わせに変換することができる。

例えば、１人以上のユーザは、クライアント装置１１３上のクライアントアプリケーション（例えば、画像処理ソフトウェア）上で画像を操作し、クライアントアプリケーションから画像をプリントすることができる。サーバ１０９は、クライアントアプリケーションからプリント要求を受信し、画像がどのようにその時点でクライアントアプリケーション上で表示されているかに関する情報によりＤＩＣＯＭファイルを作成することができる（すなわち、ディスプレイ上で見られるものは３Ｄプリントされるモデルと同じであってもよい）。サーバ１０９は、作成したＤＩＣＯＭファイルを変換サーバ１１４に送信してファイル変換を実行することができる。ファイル変換のための形式は、２Ｄ、３Ｄ、及び／又は４Ｄプリンタと互換性があってもよい。ファイル変換のための形式はホログラフィックディスプレイと互換性があってもよい。

変換クラウド内のデータベースはデータベース１１０と類似していてもよい。データベースは、ＤＩＣＯＭ、非ＤＩＣＯＭ、ＯＢＪ、ＳＴＬ、ＶＲＭＬ、Ｘ３Ｇ、ＰＬＹ、ＦＢＸ、ＨＤＦ、その他の任意の互換性のあるプリンティング形式、又はそれらの任意の組み合わせを格納することができる。

一実施形態によれば、変換サーバ１１４は、医療機関からの医師、保険会社からの外交員、患者、医学研究者、技術者、専門家、又はそれらの任意の組み合わせを代表してもよいクライアント１１３にファイル変換サービスを提供するよう構成される。変換サーバ１１４は、任意の保護医療情報を削除するよう任意のデータファイルを匿名化及び／又は非特定化することができる。

一実施形態において、プリンティングクラウドは、１つ以上のサービスプロバイダに関連付けられ、ネットワークを介して地理的に分散された一組のサーバ又はサーバのクラスタを表してもよい。例えば、プリンティングクラウドは、プリンティングと互換性のあるファイル（例えば、２Ｄ、３Ｄ、４Ｄ、ホログラフィック）を受信し、プリントすることができるプリンティングサービスに関連付けられてもよい。一実施形態において、プリンティングクラウドは、プリンティングサービスを提供するための１つ以上のプリンティングサーバ１１５、画像及び他の医療データを格納するか及び／又は２Ｄ、３Ｄ、及び／又は４Ｄプリンティング又はホログラフィックディスプレイと互換性のある任意のファイル形式を格納するための１つ以上のデータベース、及び他の事業体（図示せず）に／からデータを転送するための１つ以上のルータを含むことができる。プリンティングサーバがサーバクラスタ又は１つを超えるサーバからなる場合、クラスタ内のサーバ間のデータ転送を制御する規則が存在していてもよい。

プリンティングサーバ１１５は、ネットワークを介して２Ｄ、３Ｄ、４Ｄ、又はホログラフィックプリンティングに関するサービスを提供するためのプリンティングサーバであってもよい。プリンティングサーバ１１５は互換プリンティングファイルを受信することができる。例えば、プリンティングサーバ１１５は、変換サーバ１１４から互換プリンティングファイルを受信してファイルをプリントすることができる。プリンティングサーバ１１５は、ＰＨＩを削除し、データを匿名化し、及び／又はデータを非特定化することができる。プリンティングクラウド内のデータベースはデータベース１１０と類似していてもよい。データベースは、ＤＩＣＯＭ、非ＤＩＣＯＭ、ＯＢＪ、ＳＴＬ、ＶＲＭＬ、Ｘ３Ｇ、ＰＬＹ、ＦＢＸ、ＨＤＦ、ＡＭＦ、ＳＴＰ、その他の任意の互換性のあるプリンティング形式、又はそれらの任意の組み合わせを格納することができる。

図１は、例示的な一実施形態を示しているが、サーバ、データベース、クラウド、及び／又は機関のいずれも共に一体化することができる（図示せず）。例えば、クラウド１０３及び変換クラウドは、１つのデータベース又は１つのサーバのみを必要とするように、組み合わせることができる。

従って、高度画像処理及びプリンティングのためのクラウドベースシステムを用いることは幾つかの利点を有する。クラウドシステムとは、サーバベースで、ソフトウェアクライアントが極めて小さく、恐らくはＷｅｂブラウザ、プラグインを有するＷｅｂブラウザ、又はモバイル又は電話アプリケーション等であるシステムを指す。クラウドシステム内のサーバ又はサーバクラスタは計算に極めて強力であり、複数のユーザを同時にサポートできる。サーバはどこに存在していてもよく、クラウドシステム内のソフトウェアのユーザがソフトウェア及びハードウェアのインストール及び保守に気を配る必要がないように、第三者によって管理されてもよい。

クラウドコンピューティングは、サービスを提供するシステムの物理的な場所及び構成に関するエンドユーザの知識を必要としない、計算、ソフトウェア、データアクセス、ストレージサービス、及びプリンティングサービスを提供する。クラウドコンピューティングプロバイダは、Ｗｅｂブラウザ、デスクトップ、及びモバイルアプリからアクセスされるインターネットを介してアプリケーションを配信する一方で、ビジネスソフトウェア及びデータは遠隔地のサーバに格納されている。クラウドアプリケーションサービスは、インターネットを介したサービスとしてソフトウェアを配信するため、顧客の所有するコンピュータにアプリケーションをインストールし、実行する必要がなくなり、メンテナンス及びサポートが簡略化される。

クラウドシステムは様々な構成で実装することができる。例えば、クラウドシステムは、パブリッククラウドシステム、コミュニティクラウドシステム、ハイブリッドクラウドシステム、プライベートクラウドシステム、又はそれらの組み合わせであってもよい。パブリッククラウドはクラウドコンピューティングを従来からの主流の意味で説明し、それによってリソースは、ユーティリティコンピューティングベースで請求するオフサイトのサードパーティプロバイダから、Ｗｅｂアプリケーション／Ｗｅｂサービス、又は他のインターネットサービスを介してインターネット上のセルフサービスベースで公衆に動的に提供される。コミュニティクラウドは、内部で又はサードパーティによって管理されるか及び内部又は外部でホストされるかに関わらず、共通の懸念（セキュリティ、コンプライアンス、管轄、等）を有する特定のコミュニティからの幾つかの組織の間でインフラストラクチャを共有する。コストはパブリッククラウドよりも少ない（しかしプライベートクラウドよりも多い）ユーザに分散されるため、クラウドコンピューティングの利点の幾つかだけが実現される。ハイブリッドクラウドは固有の事業体を残すが共に結合される２つ以上のクラウド（プライベート、コミュニティ、又はパブリック）の構成であり、複数の展開モデルの利点を提供している。簡単に言うと、図１に示すように、プログラムとデータが１つ展開システムから別のものへ容易に移動されることを可能にする方法で接続される複数のクラウドシステムとして定義することもできる。プライベートクラウドは、内部で又はサードパーティによって管理されるか又は内部又は外部でホストされるかに関わらず、単一の組織のためだけに運用されるインフラストラクチャである。一般に、プライベートクラウドへのアクセスは、その単一の組織又はその関連会社に制限される。

クラウドコンピューティングにおいて、クライアント１１３等のクライアントのユーザは、画像処理に関連するソフトウェア及びハードウェアを維持する必要はない。幾つかの状況において、Ｃｉｔｒｉｘ又はＪａｖａ（登録商標）又はプラグイン等の小さなソフトウェアのインストールがあってもよい。かかる構成は、ユーザに対する初期費用及び保守コストを低下させ、ハードウェア、ソフトウェア、又は保守コストは全く無いか、若しくは低い。クラウドサーバはバックアップ及び冗長性並びにセキュリティを扱うことができるため、ユーザはこれらの問題について心配する必要はない。ユーザは、同じものをインストールする必要なく、全て及び最新の臨床ソフトウェアに対するアクセスを有することができる。ツール及びソフトウェアは、サーバにおいて最新バージョンに（自動的に又はその他の方法で）アップグレードされる。プリンティング等のツールへのアクセスは、ソフトウェア制限によってではなく、アクセスレベルによって駆動され得る。クラウドサーバは、画像を前処理し、処理するためのより高い計算能力を有することができ、それらはより優れたバックアップ、冗長性、セキュリティオプションと共により大型で、より強力であってもよい。

一実施形態によれば、クラウドによって提供されるプリンティングサービスは、例えば、ユーザの数、症例アップロード（例えば、症例数、画像数、又は画像データ量）、症例ダウンロード（例えば、症例数、画像数、又は画像データ量）、処理及び／又は閲覧された症例数、画像処理要件、ユーザの種類（例えば、専門家、専門分野、又は一般ユーザ）に基づく、臨床試験によるか又は調査研究による、症例の種類、帯域幅要件、処理能力／速度要件、処理能力／速度に対する優先度（例えば、ＥＲ内のシステムは高い優先度に対する対価を支払ってもよい）、返済又は請求コード（例えば、ユーザは保険によって払い戻されるある特定の措置を実行するために支払うのみであってもよい）、ソフトウェアを用いる時間（例えば、年、月、週、日、時間、分でさえも）、ソフトウェアを用いる時刻、同時実行ユーザ数、セッション数、プリントサイズ、プリント数、プリントの量（ｃｍＡ３当たり）、ファイルサイズ、画像操作の量、プリントするための材料の種類、プリント色、又はそれらの任意の組み合わせに基づく等の様々なライセンス許諾モデルに基づいて提供することができる。

別の実施形態において、サーバ１０９、変換サーバ１１４、及び／又はプリンティングサーバ１１５は、ＤＩＣＯＭファイルを取得し、ＰＨＩを削除することができる匿名化モジュールを有することができる。別の実施形態において、クラウド１０３、変換クラウド、及び／又はプリンティングクラウドは、匿名化のために別個のサーバを有することができる。別の実施形態において、ＤＩＣＯＭファイルがクラウド１０３、変換クラウド、及び／又はプリンティングクラウドにアップロードされる前に、ＤＩＣＯＭファイルを非特定化及び／又は匿名化することができる別個のサーバが存在してもよい。

一実施形態において、ユーザは匿名化される項目を指定することができ、ここで各項目は、図７に示すように、ＧＵＩ１１００に列挙されたエントリのうちの１つで指定される。各項目は、そのＤＩＣＯＭタグ１１０１、名前１１０２、置き換えられる元の値１１０３、及び対応する元の値を置き換えるための置換値１１０４によって参照される。この実施例において、図７に示すように、ユーザは、列１１０４をクリックし、新しい値を入力することによって、新しい値を設定することができる。ＤＩＣＯＭタグがデータタイプである場合、データセレクタが表示されて、ユーザがデータを選択することを可能にする。許可されている値が予め定義されている場合、ドロップダウンリストが予め定義されている値又は文字列のうちの１つを選択するために表示される。タグのために定義されているマスクがある場合、マスクされた編集ＧＵＩは、ユーザが表示されたマスクに従って値を変更することを可能にするよう表示される。ユーザ入力は、ＤＩＣＯＭタグの種類に基づいてシステムによって調べられてもよい。情報が正しくない場合は、ユーザは正しい値を再入力するよう促されてもよい。全てのユーザ入力が収集された後、新しい匿名テンプレート又は構成ファイルが作成され、格納される。また、図７におけるＧＵＩの形式又は構成は例証の目的だけのために説明され、他の形式又はレイアウトもまた利用されてもよいことに留意されたい。ＧＵＩは、ブラウザ又は電話又は他のモバイルデバイスアプリケーションの形態であってもよい。

ゲートウェイマネージャ１０７及び／又はサーバはデータを匿名化することができる。３Ｄ医用画像データは、匿名化テンプレートに基づいて３Ｄ医用画像データに関連するある特定のメタデータを除去することを含んで匿名化される。匿名化された３Ｄ医用画像データは、次いで、ネットワークを介してクラウドサーバへ自動的にアップロードされる。

図１は、３Ｄプリンティングクラウドベースのワークフローを示す一方で、ワークフローは、いずれかのクラウドにアクセスすることなく、特定のＬＡＮ／ＭＡＮ内で実行される、病院及び病院ネットワーク等の特定の環境内でワークフローの全てのコンポーネントを展開するために、ローカルに配置することができる。

図２は、一実施形態による３Ｄプリンティングを用いるクラウドベースの画像処理システム（３Ｄプリンティングシステムと称する）を示すブロック図である。３Ｄプリンティングシステムは、ＬＡＮ、ＭＡＮ、ＷＡＮ、又はそれらの任意の組み合わせであってもよいネットワークを介して１つ以上のクライアントに通信可能に結合される画像処理サーバであってもよい。画像処理サーバは、様々なプリンティングライセンス許諾モデルに基づいて、クラウドベースの画像処理サービスを３Ｄプリンティングと共にクライアントに提供するよう構成される。各クライアントは、画像処理サーバによって提供されるリソースにアクセスするよう画像処理サーバ内の画像処理サーバアプリケーションと通信するためのクライアントアプリケーションを含むことができる。画像処理システムは、各クライアントに１つずつ、仮想サーバ又は画像処理アプリケーションのインスタンスとして実装することができる。

一実施形態によれば、サーバ１０９は、ワークフロー管理システム２０５、医療データストレージ２０６、画像処理システム２０７、アクセス制御システム２１０、３Ｄプリンティングアプリケーション、追跡システム、又はそれらの任意の組み合わせを含むが、これらに限定されない。医療データストア２０６は、図１のデータベース１１０の一部として実装されてもよい。医療データストア２０６は、医療画像、医療データセンタ（例えば、ＰＡＣＳシステム）１０５又は他の画像格納システム２１５（例えば、ＣＤ−ＲＯＭ、若しくはハードドライブ）から受信され、画像処理システム２０７及び／又は画像前処理システム２０４によって処理される画像データ、ＤＩＣＯＭ、ＯＢＪ、ＳＴＬ、ＶＲＭＬ、Ｘ３Ｇ、ＰＬＹ、ＦＢＸ、ＨＤＦ、ＡＭＦ、ＳＴＰ、他の任意の互換性のあるプリンティング形式、ホログラフィックディスプレイ形式、又はそれらの任意の組み合わせを格納するよう利用される。画像処理システム２０７は、様々なライセンス許諾条件又は契約に従って、それぞれ、それらの各クライアントアプリケーションを介してクライアントによって呼び出され、利用され得る様々な医用画像処理ツール又はアプリケーションを含む。

医療データセンタから又は画像取込装置（図示せず）から又はＣＤ若しくはコンピュータデスクトップ等の別の画像ソースから受信された画像データに応答して、一実施形態によれば、画像前処理システム２０４は、画像データのある特定の前処理を自動的に実行し、前処理された画像データを医療データストレージ２０６に格納するよう構成されてもよい。例えば、ＰＡＣＳ１０５から又は直接、医用画像取込装置から画像データを受信すると、画像前処理システム２０４は、骨除去、中心線抽出、球体検出、位置合わせ、パラメトリックマップ計算、再フォーマット化、時間密度解析、構造のセグメント化、自動３Ｄ操作、及び他の操作等のある特定の操作を自動的に実行する。画像前処理システム２０４は別個のサーバとして実装されてもよいか、又は、サーバ１０９と統合されてもよい。更に、画像前処理システム２０４は、サーバ１０９等の複数のクラウドサーバのために画像データ前処理を実行してもよい。

一実施形態において、クライアント／サーバ画像データ処理アーキテクチャはシステム２００にインストールすることができる。アーキテクチャは、クライアント区画（例えば、クライアントアプリケーション）及びサーバ区画（例えば、サーバアプリケーション２０９）を含むことができる。システム２００のサーバ区画は、サーバ１０９上で実行することができ、それぞれ、クライアントにインストールされたそのクライアント区画と通信することができる。一実施形態において、サーバ１０９は複数のサーバ上に分散され、実行されている。別の実施形態において、システムは１つ以上のサーバ上で動作するＷｅｂ対応アプリケーションである。Ｗｅｂブラウジングアプリケーションがインストールされている任意のコンピュータ又は装置は、追加のハードウェア及び／又はソフトウェア要件のいずれかもなしで、又は最小限で、システムのリソースにアクセスし、利用してもよい。

一実施形態において、サーバ１０９は、医用画像取込装置から受信した医用画像データのためのデータサーバとして動作してもよい。受信した医用画像データは、次いで、医療データストア２０６に格納される。一実施形態において、例えば、クライアント２０２が未処理の医用画像データを要求する場合、サーバアプリケーション２０９は医療データストア２０６からデータを検索して取り出し、クライアント２０２に代わって取り出したデータをレンダリングする。

画像前処理システム２０４は、更に、ワークフロー管理システム２０５によって用いられるワークフロー情報を生成してもよい。ワークフロー管理システム２０５は、別個のサーバであってもよいか又はサーバ１０９と統合されてもよい。ワークフロー管理システム２０５は、本発明の幾つかの実施形態に従って複数の機能を実行する。例えば、ワークフロー管理システム２０５は、医用画像取込装置から受信した医用画像データを取得し、格納する際にデータサーバ機能を実行する。それはまた、２Ｄ又は３Ｄの医用画像ビューを生成するために医用画像データを処理する際にグラフィックエンジンとして機能するか又は画像処理システム２０７を呼び出してもよい。

一実施形態において、ワークフロー管理システム２０５は、グラフィックエンジンを有する画像処理システム２０７を呼び出して、２Ｄ及び３Ｄ画像生成を実行する。クライアント（例えば、複数のクライアント）がある特定の医用画像ビューを要求すると、ワークフロー管理システム２０５は医療データストア２０６に格納されている医用画像データを検索して取り出し、医用画像データから２Ｄ又は３Ｄ医用画像ビューをレンダリングする。医用画像ビューのための最終結果はクライアントに送信される。

一実施形態において、ユーザがサーバ１０９から受信した医用画像ビューに対して調整を行うと、これらのユーザ調整要求はワークフロー管理システム２０５に送り返される。ワークフロー管理システム２０５は、次いで、ユーザの要求に基づいて追加のグラフィック処理を実行し、新しく生成され、更新された医用画像ビューがクライアントに返される。このアプローチは、ネットワークを介して大量の未処理医用画像データを転送する必要性をなくす一方で、２Ｄ又は３Ｄ画像処理能力を最小限に有するか又は全く持たないクライアントコンピュータに２Ｄ又は３Ｄ画像閲覧を提供するため有利である。

上で説明したように、クラウドベースのアプリケーションとして実装される場合、システム２００はクライアント側区画とサーバ側区画とを含む。システム２００の機能は、クライアント側又はサーバ側区画に分散される。相当数の機能がクライアント側区画に分散されている場合、システム２００は「シッククライアント」アプリケーションと称されてもよい。代替として、限られた数の機能がクライアント側区画に分散される一方で、機能の大部分がサーバ側区画によって実行される場合、システム２００は「シンクライアント」アプリケーションと称されてもよい。別の実施形態において、システム２００の機能は、クライアント側及びサーバ側区画の両方に重複して分散されてもよい。機能は処理及びデータを含んでいてもよい。サーバ１０９はＷｅｂサーバとして実装されてもよい。Ｗｅｂサーバは、サードパーティのＷｅｂウェブサーバ（例えば、Ａｐａｃｈｅ（商標）ＨＴＴＰサーバ、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ及び／又はサービス、等）であってもよい。

画像処理操作は、医用撮像装置によって収集された医用画像データを入力として受信し、医用画像データを処理し、メタデータを出力として生成する。メタデータは、メタデータ要素とも称され、医用画像データを説明、処理、及び／又は管理するためのパラメータ及び／又は命令を広く指す。例えば、ワークフロー段階の画像処理操作によって生成されたメタデータは、診断目的のために医用画像ビューを生成するよう医用画像データに適用することができる画像処理パラメータを含む。更に、医用画像ビューの様々な自動及び手動操作もメタデータとして取り込むことができる。医用画像ビューの様々な自動及び手動のマスキング及び／又は色付けもメタデータとして取り込むことができる。従って、メタデータは、メタデータが保存された場合の状態にシステムを戻すことを可能にする。メタデータは、また、クライアント装置に表示されるように画像をプリント（例えば、３Ｄプリント）するために用いることができる。メタデータは、また、クライアント装置に表示されるように画像のホログラムを表示するために用いることができる。ワークフロー管理システム２０５は、また、情景から生成された医用画像ビューのユーザ調整中に情景の更新及び保存を可能にする。

図２に戻って参照すると、一実施形態によれば、サーバ１０９は、クライアントから医療データストア２０６に格納されたリソース（例えば、画像処理ツール）及び／又は医療データへのアクセスを制御するためのアクセス制御システム２１０を含むことができる。クライアントは、それらそれぞれのアクセス権限に応じて、リソースのある特定の部分にアクセスするか及び／又は医療データストア２０６に格納されたデータを仲介してもよいか又はしなくてもよい。例えば、ユーザ権限によって、一部のユーザはプリントすることができる一方で、他のユーザはプリントすることができない可能性がある。各ユーザの好みがクレジットに関連付けられているクレジットシステムがあってもよい。クレジットは、プリント可能な量（ｃｍ^３）又はプリント可能なオブジェクト数を特定することができる。追跡システムは、ユーザに関連付けられたクレジット数、プリント、総量、プリントの種類、又はそれらの任意の組み合わせを追跡することができる。

ＤＩＣＯＭ（医療におけるデジタル画像と通信）形式は、超音波及びスキャン等の医用画像の転送及び格納に対して一般的に用いられている。ＤＩＣＯＭファイルは、患者と医用画像に関する情報を格納することができる画像データ及びヘッダの両方を含むことができる。ユーザはＤＩＣＯＭファイルを開き、編集し、及び保存することができる。メタデータは、患者データ（例えば、患者名、ＩＤ、性別、生年月日、又はそれらの任意の組み合わせ）、検査データ（例えば、検査ＩＤ、紹介医師、検査日付及び時刻、検査の説明、又はそれらの任意の組み合わせ）シリーズデータ（例えば、シリーズ番号、モダリティ、シリーズ日付及び時刻、シリーズの説明、又はそれらの任意の組み合わせ）、機器データ（例えば、機器の機関及び製造元）、画像データ（例えば、転送構文、ＹＢＲ ｆｕｌｌ ４２２及びＲＧＢ等の光度測定解釈、画像の幅及び高さ、ピクセル当たりのビット数、及びフレーム数）、色（例えば、方向、色、レンダリング、及び色表現により行われるシェーディングによるシェーディングを有することができる表面モード）、テクスチャ、形状、ベクトル情報、ピクセル情報、セグメンテーションボリューム及びサブボリューム、ライティング、シャドーイング、ルックアップテーブル（ＬＵＴ）、マルチボリューム管理、又はそれらの任意の組み合わせを含むことができる。かかる情報はＤＩＣＯＭヘッダファイルのヘッダ内に含めることができる。例えば、色情報はＤＩＣＯＭヘッダファイルのヘッダ内の色表面を示すことができる。

サーバ１０９は３Ｄプリンティングアプリケーションを含むことができる。ユーザがワークフロー内にいる場合、ユーザは画像を操作することができる（上で説明したように）。かかる画像の操作は画像のメタデータ内に保存することができる。ユーザが画像の操作を行った後にユーザがプリントをクリックすると、３Ｄアプリケーションは、画像の操作がメタデータ内に取り込まれるように、新規ＤＩＣＯＭファイルを作成するか又はＤＩＣＯＭファイルを更新することができる。例えば、ＤＩＣＯＭメタデータは、色（例えば、方向、色、色表現により行われるシェーディングによるシェーディングを有することができる表面モード）、ベクトル情報、ピクセル情報、セグメンテーションボリューム及びサブボリューム、ライティング、陰影、ＬＵＴ、又はそれらの任意の組み合わせを含むことができる。新規ＤＩＣＯＭファイル又は更新されたＤＩＣＯＭファイルは、ユーザがクライアントに表示されている画像と全く同じ３Ｄプリントを取得又は受け取ることを可能にすることができる。独自のＬＵＴを有することができるボリューム及び／又はサブボリュームがあってもよい。ＤＩＣＯＭファイルは、ユーザがプリント機能を実行する時に作成することができる。別の実施形態において、ＤＩＣＯＭファイルは、ユーザが画像を操作する度に作成／更新することができる。

図２に戻って参照すると、一実施形態によれば、サーバ１０９は、画像データファイル、ＤＩＣＯＭファイル、ＤＩＣＯＭヘッダ、又は保護された医療情報を含む任意の他のファイルから保護医療情報を除去するようデータを匿名化及び／又は非特定化するための匿名化システムを含むことができる。匿名化システムは、データがサーバ１０９によって処理される前にデータを匿名化及び／又は非特定化することができる。匿名化システムは、データが変換クラウドに送信される前にデータを匿名化及び／又は非特定化することができる。

図３は、一実施形態による３Ｄプリンティングを用いるクラウドベースの画像処理のための方法を示すフロー図である。方法は、サーバ１０９等のサーバによって実行されてもよい。画像データ（例えば、ＤＩＣＯＭファイルを含む）は、ネットワークを介してストレージ媒体（例えば、ＰＡＣＳ、クラウドベースストレージ、ローカルドライブ、ＣＤ、ハードドライブ、ＤＶＤ、ＵＳＢ、Ｗｅｂアップローダ、クライアント装置上の任意のＤＩＣＯＭフォルダ、又はそれらの任意の組み合わせ）からサーバにおいて受信され得る。サーバは、画像データを操作する（すなわち、セグメント化、色、マスク、手動処理、自動処理、前処理、又はそれらの任意の組み合わせ）ようクライアント装置からの要求を受信することができる。サーバは、クライアント装置によって要求されたように画像データを操作することができる。サーバは、画像データをプリントするようクライアント装置による要求を受信することができる。サーバは、画像操作の結果及びサーバによる色の濃淡等の追加のデータが埋め込まれた新しいファイル（例えば、ＤＩＣＯＭファイル）を作成することができる。例えば、新規ＤＩＣＯＭファイルは、色（例えば、方向、色、色表現により行われるシェーディングによるシェーディングを有することができる表面モード）、ベクトル情報、ピクセル情報、セグメンテーションボリューム及びサブボリューム、ライティング、陰影、ＬＵＴ値、明度、不透明度、又はそれらの任意の組み合わせを含むことができる。サーバは新規ＤＩＣＯＭファイルをデータベースに格納することができる。サーバは新規ＤＩＣＯＭファイルを変換クラウドに送信することができる。

図４は、一実施形態による３Ｄプリンティングを用いるクラウドベースの画像処理のための方法を示すフロー図である。方法は、サーバ１０９等のサーバによって実行されてもよい。画像データ（ＤＩＣＯＭファイルを含む）は、ネットワークを介してストレージ媒体（上で説明した）からサーバにおいて受信することができる。サーバは、画像データ（上で説明した）を操作するようクライアント装置から要求を受信することができる。サーバは、クライアント装置によって要求されたように画像データを操作することができる。サーバは、画像データをプリントするようクライアント装置による要求を受信することができる。サーバは、画像操作の結果及びサーバによる色の濃淡等の追加のデータが埋め込まれた新しいファイル（例えば、ＤＩＣＯＭファイル）を作成することができる。サーバは新規ＤＩＣＯＭファイルをデータベースに格納することができる。サーバは、保護医療情報（例えば、患者名、生年月日、等）を削除するために新規ファイルを匿名化又は非特定化することができる。サーバは新規ファイルを変換クラウドに送信することができる。別の実施形態において、画像データファイルは、サーバ１０９によって受信される前に匿名化又は非特定化することができる。

一実施形態において、ＤＩＣＯＭ形式に基づく新規ファイル形式はＳＴＬ変換を回避することができる。一実施形態において、新規形式は、「そのまま」プリントされるモデルをエクスポートし、高品質の画像解像度を維持することを可能にすることができる。一実施形態において、サーバ１０９はモデルのアップロードの進捗状況を追跡することができる。一実施形態において、サーバは、クライアントデバイスによるドラッグアンドドロップ要求を実行して、画像データをクライアントビューアにアップロードすることができる。図５Ａ〜５Ｅは、一実施形態による、３Ｄプリンティングを用いるクラウドベースの画像処理システムのある特定のＧＵＩを示すスクリーンショットである。図５Ａ〜５ＥのＧＵＩは、クライアントアプリケーション（例えば、シンクライアント）又は様々なユーザによって操作されるＷｅｂベースのアプリケーションによって提示されてもよい。例えば、図５Ａは、クライアントアプリケーション内のツールを介してある特定の領域を色付け、マスキング、強調、又は除去するようユーザによって前処理又は操作されていてもよい解剖学的画像を有することができるユーザによって操作されるＧＵＩページを表すことができる。図５Ａを参照すると、この実施例において、ユーザは３Ｄ概要ビューにおいて解剖学的画像を閲覧することができる。図５Ｂを参照すると、ユーザは多数のツール及びオプションをクリックし、有することができる。例えば、１つのオプションは３Ｄプリンタにエクスポートすることであってもよい。図５Ｃを参照すると、プリントされるエクスポートファイルはＤＩＣＯＭプロトコル転送をサポートすることができる。エクスポートしたファイルはＤＩＣＯＭノードにプッシュされてモデルをユーザーアカウントにアップロードすることができる。ユーザは、ユーザの３Ｄプリンティングアカウントへの３Ｄモデルの自動転送を作成するための自動化オプションを有することができる。図５Ｄは、ユーザのプリンティングアカウントへのアクセス制御を有するユーザによって操作されるＧＵＩページを表すことができる。ユーザのプリンティングアカウントはクラウド上又はＷｅｂ環境内でホストとして動作され得る。各ユーザは自身のユーザーライブラリを管理することができる。図５Ｅは、モデル製作の前に各モデルをプレビューし、確認することができる（すなわち、３Ｄプリンティングが開始する）ユーザによって操作されるＧＵＩページを表すことができる。モデルをプリントする準備が整っていることをユーザが確認する場合、ユーザはショッピングカートアイコンをクリックすることができる。図５Ｅは、各ユーザが自身のモデルライブラリに対するアクセスを有することができる、ユーザによって操作されるＧＵＩページを表している。ユーザのアカウントにプッシュされるモデルはプリントする準備が整っていてもよい。ユーザによって受け取られる３Ｄモデルは、画像処理プラットフォームから作成されたものと同じモデルであってもよい。

図６は、ある特定のＧＵＩを示すスクリーンショットである。図６は、解剖学的画像を有することができる、ユーザによって操作されるＧＵＩページを表すことができる。ユーザは、任意の特定のサブボリューム（対象領域）又はそれらの全てに適用されるＬＵＴ（１つ又は複数）を閲覧し、画像を操作するためのオプションを利用することができる。ＬＵＴは、ＷＷ、ＷＬ、不透明度、明度、上昇直線、直角三角形、上昇直線、色、マスク、テクスチャ、又はそれらの任意の組合せを操作するためのツールを含むことができるが、それらに限定されない。ＬＵＴの値は、新規ＤＩＣＯＭファイルに含まれる（上で説明したように）又はＤＩＣＯＭファイルにおいて更新され得る。

一実施形態において、３Ｄプリンティングを有するクラウドベースの画像処理システムは画像処理サーバからＤＩＣＯＭとしてエクスポートすることができる。一実施形態において、３Ｄプリンティングを有するクラウドベースの画像処理システムは複数のボリュームをサポートすることができる。一実施形態において、３Ｄプリンティングを有するクラウドベースの画像処理システムは、ボリューム／サブボリューム毎にＬＵＴをサポートすることができる（すなわち、各ボリュームはそれ自体のＬＵＴを有することができる）。一実施形態において、３Ｄプリンティングを有するクラウドベースの画像処理システムはＬＵＴを埋め込むことができる。

図８は、一実施形態によるＬＵＴ及びマスキングのグラフを示している。この技術は、医療用ボリュームを複数のサブボリュームにより処理して、骨、血管、器官、腫瘍等のような特定の人体構造を明確に識別し、それらに特定のレンダリング（色、陰影、透明度、不透明度、テクスチャ等）を適用することを可能にする。この技術は、また、３Ｄプリンティング用のプリント可能ファイルを作成するために用いられるサブボリューム最適化レンダリングの作成も可能にする。この技術は、また、ホログラフィック技術、装置、及び／又はプラットフォームを用いて患者固有のセグメント化のホログラムのレンダリング、及び／又は仮想現実技術、装置、及び／又はプラットフォームを用いて患者の仮想表現を可能にする。

図９は、一実施形態によるＤＩＣＯＭファイルのストレージ構造を示すブロック図である。ＤＩＣＯＭファイルは、画像、メタデータ、及びその他の情報を格納するよう構成され得る。他の情報は、オーバーレイオブジェクト、プロプライエタリ情報（例えば、画像オブジェクト、プロプライエタリメタデータ、元の画像に含まれないメタデータ、元のメタデータに含まれないメタデータ、又はそれらの任意の組み合わせ）、ＬＵＴ、マルチボリューム管理、レンダリング、形状表面の詳細、本明細書に説明する任意の特徴、又はそれらの任意の組み合わせを含むことができる。ＤＩＣＯＭファイルは、約２バイト（すなわち、約１６ビット）であってもよい。画像及び／又はメタデータは、約１０ビットから約１２ビットのＤＩＣＯＭファイル、例えば、１０ビット、１１ビット、又は１２ビットに格納することができる。他の情報は、約１ビットから約４ビット（例えば、１ビット、２ビット、３ビット、又は４ビット）のＤＩＣＯＭファイルに格納することができる。他の情報は、ファイルの任意の部分にわたって、例えば、最後に、中間に、最初に、画像及びメタデータ情報を格納するビット内に広がる、又はそれらの任意の組み合わせで格納することができる。ＤＩＣＯＭファイル（又は本明細書で言及されている他のファイル種類）は、例えば、ＯＢＪ、ＳＴＬ、ＶＲＭＬ、Ｘ３Ｇ、ＰＬＹ、ＦＢＸ、ＨＤＦ、３Ｄプリンティング又はホログラフィックディスプレイのための他の互換形式、又はそれらの任意の組み合わせに変換することができる。

図１０は、一実施形態による診断ソフトウェアアプリケーション上でのモデルの３Ｄプリンティングを示すフローチャートである。サーバは、医用撮像装置から、例えば、ＤＩＣＯＭファイルを含む生画像データを受信することができる。サーバは、クライアントアプリケーション、前処理サーバ、後処理サーバ、又はそれらの任意の組み合わせに基づいて、自動化、半自動化、又は手動結果により画像データを操作（例えば、セグメント化）することができる。サーバは、埋め込まれる他の情報と共にＤＩＣＯＭファイルをエクスポートするためのクライアントアプリケーションによる要求を受信することができる。埋め込まれる他の情報は操作に関するデータを含むことができる。サーバは埋め込まれた他の情報により新規ＤＩＣＯＭファイルを作成することができる。サーバは、ユーザーアカウントへのＤＩＣＯＭプッシュを介して、埋め込まれた他の情報と共に新規ＤＩＣＯＭファイルをアップロードすることができる。サーバは、３Ｄモデルをプリントするために、埋め込まれた他の情報を有する新規ＤＩＣＯＭファイルを３Ｄプリンティング互換形式（例えば、ＯＢＪファイル）に変換することができる。

一実施形態において、ユーザは、３ＤプリントされるモデルがＬＵＴ及び／又はメタデータ内の任意の特性を含めてクライアント上に表示されるものと同じ属性を表すように、クライアント上に表示されるオブジェクトをプリントすることができる。言い換えれば、ユーザがディスプレイ上で見るものは、ユーザが３Ｄプリントされたモデルとして受け取るもの、又はホログラフィック及び／又は仮想現実装置内でレンダリングするものであってもよい。

図１１は、一実施形態による、別のファイル種類（例えば、ＯＢＪ）へのＤＩＣＯＭファイルの変換を示すブロック図である。本明細書に説明するものと同じ技法が、任意のファイル種類（例えば、ＤＩＣＯＭ、非ＤＩＣＯＭ、ＯＢＪ、ＳＴＬ、ＶＲＭＬ、Ｘ３Ｇ、ＰＬＹ、ＦＢＸ、又はＨＤＦ）を、診断ソフトウェアアプリケーションから３Ｄモデルをプリントするための任意のファイル種類（例えば、ＤＩＣＯＭ、非ＤＩＣＯＭ、ＯＢＪ、ＳＴＬ、ＶＲＭＬ、Ｘ３Ｇ、ＰＬＹ、ＦＢＸ、又はＨＤＦ）に変換できることに留意されたい。一実施形態において、サーバはファイルを自動的に（すなわち、ユーザの操作なしに）又はユーザの要求により変換することができる。サーバはボクセルモデルをポリゴンファイル形式に（例えば、ＤＩＣＯＭからＯＢＪへ）変換することができる。変換は、埋め込まれた他の情報を有する新規ＤＩＣＯＭファイルを用いて、関連する他の情報を有する各ボリュームを単一のプリンタ読取り可能形式に変換することができる。

上で説明したようなセグメント化された医療用ファイルは、図８に示すファイル形式記述を用いてその生の形式（ＤＩＣＯＭ）でレンダリングすることができる。レンダリングは、ユーザがその閲覧装置に関係なく、３Ｄモデル又はホログラムとして３Ｄ再構成にアクセスすることを可能にする。例えば、閲覧装置は、仮想現実閲覧装置又は複合現実（拡張現実）閲覧装置であってもよい。

例えば、セグメント化されたモデルは、その生の形式で、サーバ側のホスティングでレンダリングされるか、１つ又は複数のＧＰＵに接続される。このサーバ側レンダリングは、モデルがそのファイルサイズに関係なくレンダリングされることを可能にする。レンダリングはボリューム操作（回転、パン、ズーム、ＷＷ／ＷＬ、切断平面等）の結果である。この操作結果は、ユーザ識別情報を用いてサーバに接続されるクライアント装置にリアルタイムで送信される。このプラットフォームは、ユーザがユーザの特定のデータを含む独自の環境に接続することを可能にする。

３Ｄホログラム及び／又は任意のロードされたアプリケーションは、共有機能を介して１人又は複数のユーザによってリアルタイムで見ることができる。この機能は、ホログラフィック環境をリアルタイムで見て、それについて通信する複数の使用を可能にする。これは、医療従事者がロードされた画像について通信することを可能にする。

例えば、図１２は、それぞれが独自の機能、用途、及び使用法を有する幾つかのアプリケーションをロードし、レンダリングすることができる医療ホログラフィックプラットフォームを示している。

図１３は、予めセグメント化されたデータ及びカスタマイズされたＬＵＴ並びにその元の２Ｄ放射線図（軸方向、冠状、及び矢状）を用いる医療ボリューム（心臓）レンダリングを示しており、放射線図のそれぞれは、ＭＩＰ及びＭＰＲ等の特定のレンダリングにより個々に操作することができる。

図１４Ａ及び図１４Ｂは、この場合、大動脈弁、大動脈基部、及び冠動脈入口点等の人体特定領域をより良好に視覚化するために切断平面を有する特定の視野角を用いるＨＯＬＯＰＯＲＴＡＬ拡張及び複合現実コンテンツ作成システムを用いる医療ホログラムレンダリングを示す。

図１５は、ホログラム作成、ローディング、及びクライアントサーバ接続、並びにクライアントとレンダリングサーバとの間のホログラム操作を説明している。ブロック１５０において、生画像データがサーバによって受信される。ブロック１５１において、画像はサーバによって操作される。ブロック１５２において、サーバは他の埋め込まれた情報を有するＤＩＣＯＭファイルをエクスポートする要求を受信する。ブロック１５３において、サーバは他の埋め込まれた情報を有する新規ＤＩＣＯＭファイルを作成する。ブロック１５４において、埋め込まれた他の情報を有する新規ＤＩＣＯＭファイルがアップロードされる。ブロック１５５において、埋め込まれた他の情報を有するＤＩＣＯＭファイルがサーバのグラフィックス処理ユニット（ＧＰＵ）にロードされる。ブロック１５６において、サーバはレンダリング結果を接続されている装置に送信する。ブロック１５７において、ホログラフィックプラットフォームアプリケーションのユーザは、接続されている装置上のインターフェースを用いてサポートされるインタラクションを介して画像操作を実行する。例えば、サポートされるインタラクションは、音声コマンド、ジェスチャ制御キーボード／マウス制御等を含むことができる。ブロック１５８において、サーバは、コマンドに応答して、例えば、ビュー位置、ビュー角度、位置、切断平面等のうちの１つ又は複数への変更を含む新規画像をレンダリングする。ブロック１５９において、ユーザはホログラフィックプラットフォームアプリケーションを終了する。

図１６は、共有体験構成における、ホログラム作成、ローディング、及び複数のクライアントと１つのレンダリングサーバとの間のホログラム操作を説明している。ブロック１６０において、生画像データがサーバによって受信される。ブロック１６１において、画像はサーバによって操作される。ブロック１６２において、サーバは他の埋め込まれた情報を有するＤＩＣＯＭファイルをエクスポートする要求を受信する。ブロック１６３において、サーバは他の埋め込まれた情報を有する新規ＤＩＣＯＭファイルを作成する。ブロック１６４において、埋め込まれた他の情報を有する新規ＤＩＣＯＭファイルがアップロードされる。ブロック１６５において、埋め込まれた他の情報を有するＤＩＣＯＭファイルがサーバのグラフィックス処理ユニット（ＧＰＵ）にロードされる。ブロック１６６において、サーバはレンダリング結果を接続されている装置に送信する。ブロック１６７において、接続されている装置を介してホログラフィックプラットフォームに接続する各許可ユーザがサポートされるインタラクションを介して画像操作を実行することを可能にする共有アクティベーションが実行される。例えば、サポートされるインタラクションは、音声コマンド、ジェスチャ制御キーボード／マウス制御等を含むことができる。ブロック１６８において、サーバは、第１のユーザ（ユーザ１）からのコマンドに応答して、例えば、ビュー位置、ビュー角度、位置、切断平面等のうちの１つ又は複数への変更を含む新規画像をレンダリングする。ブロック１６９において、ユーザはアプリケーションを終了する。

ブロック１７０において、接続された装置の第２のユーザ（ユーザ２）がホログラフィックプラットフォームに接続する。ブロック１７１において、第２のユーザは、共有機能を選択して開かれたコラボレーションルームを選択する。ブロック１７１において、第２のユーザは別個のホログラフィック空間を作成し、第１のユーザと同じレンダリングを要求する。例えば、要求は、ホログラフィック空間内の第２のユーザの仮想位置を反映するようホログラフィック空間内の位置補正を含む。ブロック１７３において、サーバは、第２のユーザからのコマンドに応答して、例えば、ビュー位置、ビュー角度、位置、切断平面等のうちの１つ又は複数への変更を含む新規画像をレンダリングする。

ブロック１８０において、接続された装置の第３のユーザ（ユーザ３）がホログラフィックプラットフォームに接続する。ブロック１８１において、第３のユーザは、共有機能を選択して開かれたコラボレーションルームを選択する。ブロック１８１において、第３のユーザは別個のホログラフィック空間を作成し、第１のユーザと同じレンダリングを要求する。例えば、要求は、ホログラフィック空間内の第３のユーザの仮想位置を反映するようホログラフィック空間内の位置補正を含む。ブロック１８３において、サーバは、第３のユーザからのコマンドに応答して、例えば、ビュー位置、ビュー角度、位置、切断平面等のうちの１つ又は複数への変更を含む新規画像をレンダリングする。

図１７及び図１８は、医療用ホログラフィックプラットフォームがコラボレーション及び共有を可能にするためにどのように機能するかを示している。

図１７は、単一のユーザ１９１のみが存在している場合を示している。ユーザ１９１は、機能１９２と対話するための利用可能なツール１９３を有し、ＲＡＤＶＩＥＷ試験及び性能監視ソフトウェア等の試験及び性能監視ソフトウェア１９５並びにコラボレーション／共有を含む機能を用いるために利用可能なツール１９６を有する。ユーザ１９１は、ツール１９９を用いて、ホログラフィック表示環境においてホログラム１９８と対話する。ツール１９４は、機能１９２と対話するためにユーザ１９１又は他のユーザによって用いられ得る他のツールセットを表し、ツール１９７は、試験及び性能監視ソフトウェア１９５のためにユーザ１９１又は他のユーザによって用いられ得る他のツールセットを表す。

図１８は、ユーザ２００がホログラム１９８の観察者として追加されていることを示している。ユーザ２０１はホログラム１９８を見るだけでモデルを制御しない。例えば、ホログラム１９８は、ホログラム１９８内のユーザ１９１のための視野位置と同じ視野位置にユーザ２０１を配置し、ホログラム１９８は、ユーザ１９１がホログラム１９８内で見るものと同じ視野角をユーザ２０１に示す。例えば、この観察者構成は、医療従事者及び／又は医学生及び／又は患者と通信及び／又は教育するために用いることができる。

図１９は、ユーザ２０１がホログラム２０２の観察者として追加されていることを示している。ユーザ２０１はホログラム２０２を見るだけでモデルを制御しない。例えば、ホログラム２０２は、ホログラム１９８内のユーザ１９１のための視野位置とは異なる視野位置にユーザ２０１を配置し、ホログラム１９８は、ユーザ１９１がホログラム１９８内で見るものとは異なる視野角をユーザ２０１に示す。例えば、この観察者構成も、医療従事者及び／又は医学生及び／又は患者と通信及び／又は教育するために用いることができる。代替の実施形態において、ユーザ２０１は、ユーザ２０１が見る視野位置及び視野角を変えることができる。

例えば、ホログラフィック空間にロードされるアプリケーションは、２Ｄアプリケーション（医療用２Ｄスライス操作若しくは他の任意の２Ｄアプリケーション）又は３Ｄアプリケーション（医療用３Ｄボリューム操作）であってもよい。２Ｄ又は３Ｄ画像をレンダリングするために用いられるレンダリング技術は、ＶＲ３Ｄ、ＭＩＰ、ＭＰＲ、Ｔｈｉｃｋ ＭＰＲ、Ｔｈｉｃｋ ＭＩＰ等、複数であってもよい。これらのレンダリングテクニックは、ユーザが、異なる方法を用いて、１つ若しくは別のレンダリング技術若しくはその組み合わせを用いて良好に視覚化することができる対象の幾つかの領域を良好に示すモデルをレンダリングすることを可能にする。

例えば、上で説明した医療用ホログラフィックプラットフォームは、ホログラムを操作するよう、医用画像又はセグメント化された医療用ビューアを取り込むための基本層として用いることができる。追加のアプリケーション、機能、及び機能のアンサンブルは、特定の臨床領域に焦点を当てた特定のアプリケーションを構築するために用いることができる。上で示したように、かかる医療用ホログラフィックプラットフォームは画像操作を可能にする。リアルタイムホログラム位置合わせ等の追加機能は、医療用ホログラフィックプラットフォームにおいて、例えば、特定のＡＰＩを用いるプラットフォームに対して含めることができる。

上で説明した医療用ホログラフィックプラットフォームは、ユーザが同じ物理的位置及び／又は異なる物理的位置においてリアルタイムでモデルを共有することを可能にするリアルタイムコラボレーションを含んでいる。例えば、音声制御がプラットフォームを制御するために用いられてもよい。例えば、医療用ホログラフィックプラットフォームは、患者教育、医療専門家教育、多くの学問分野にわたる専門家のコミュニケーション、手術室でのコラボレーション等のような様々な状況においてユーザ間で共同作業するために用いることができる。

医療用ホログラフィックプラットフォーム及びアーキテクチャは、ホログラムをレンダリングするか又は３Ｄ画像、拡張現実、若しくは仮想現実をレンダリングするために用いられる技術に関係なく、及び用いられるインターフェース装置に関係なく、１つ又は複数の装置の接続を可能にする。インターフェース装置は、例えば、ヘルメット、眼鏡、電話、タブレットコンピューティング装置、スマートフォン等のモバイル装置、ラップトップコンピューティング装置、ワークステーション、診断モニタ、複数のモニタ等を含むことができる。

例えば、医療用ホログラフィックプラットフォームは、決定論的及び／又は人工知能アルゴリズム等の様々な種類のアルゴリズムを用いる医用画像処理の結果として提供される自動化マスク（骨、胸郭等）、自動化ラベリング（骨、血管、器官等）、自動化中心線（血管、結腸、気管等）、及び他の自動化タスクを含む前処理医療データを読み取る。アルゴリズムはホログラムのビューのカスタマイズを可能にする。カスタマイズは、例えば、対象領域に焦点を合わせるため、情報をホログラムに追加するため、幾つかの身体特異性（血管、骨等）を検出するため、及び特定のビューに適用するために用いることができる。

図２０は、自動化された３ｄプリンティングワークフローを示す略フロー図である。ブロック２１１において、サーバは３Ｄセグメント化医用画像データを変換するための要求を受信する。例えば、サーバはインターネット又は広域ネットワークを介して要求を受信するクラウドサーバである。代替として、サーバはローカルエリアネットワーク（ＬＡＮ）上のサーバである。例えば、３Ｄセグメント化医用画像データは、ユーザと関連付けられるクライアント装置で実行されているアプリケーションからのものである。セグメント化は、例えば、特定の人体解剖学的構造又は対象領域の複数のサブセグメント化（個々のマスク）からなっている。セグメント化は、医用画像データを含む元のファイルをプリント可能ファイルに変換するために用いられる。ユーザは元のデータをセグメント化するために用いられる医療用アプリケーションを用いてこれを要求する。

ブロック２１２において、変換されたデータへのアクセス制限が特定される。例えば、変換されたモデルのアクセス（クラウド又はローカル設置ベースのアーキテクチャ）は、３Ｄプリンティングサービス要求を処理するため、又はサーバによって確立されたプラットフォームから変換されたモデルにアクセスするために特定のユーザに制限される。

ブロック２１３において、医用画像ファイルは医用画像データから作成される。医用画像ファイルはセグメント化及びサブセグメント化を含む。例えば、医用画像ファイルはＤＩＣＯＭファイル形式であり、マスクセグメント化情報、カラーパレット、シャドーイング、透明度、不透明度、及びこれら全ての情報がヘルスケアネットワーク内で都合よく転送されることを可能にする医療データからの対象領域の多くを含んでいる。例えば、ＤＩＣＯＭ画像は、アップロードされ、閲覧され、サイズ調整され、３Ｄプリンタによって読み取り可能なプリント可能ファイルに出力されるよう医療用３Ｄ後処理ワークステーション上で生成される。例えば、ＤＩＣＯＭ医用画像ファイル形式は、解剖学的構造の複数の異なるボリューム及びサブボリュームのセグメント化に関する情報を埋め込む。サブボリュームは、特定の骨、血管、及び筋肉等であってもよい。各ボリューム又はサブボリュームに対して、例えば、カラーパレット及びライティング（明度又は透明度）情報が格納される。

ブロック２１４において、医用画像ファイルは、３Ｄプリンタ上で用いるためのプリント可能ファイルを作成するために用いられる。プリントされる場合、結果として生じる３Ｄ物理的オブジェクトは、例えば、マスクセグメント化情報、カラーパレット、シャドーイング、透明度、不透明度、及び対象領域を含む正確なセグメント化及びサブセグメント化を表す。例えば、プリント可能ファイルは、特定の出力先プリンタによってサポートされるポリゴンメッシュファイルである。形式は、読み取り可能なＰＣ形式、ＯＢＪ、３ＭＦ、ＳＴＬ、ＦＢＸ、又は３Ｄプリンタによって用いられる他の幾つかの形式であってもよい。

図２１は、ホログラフィックプラットフォーム内でレンダリングすることができるか又は仮想現実環境においてレンダリングすることができるファイルを生成するための自動化されたワークフローを示す略フロー図である。例えば、ホログラフィックプラットフォームは、ホログラフィック閲覧専用の装置上で実行することができるか、又は、パーソナルコンピュータ、スマートフォン、又はタブレットコンピューティング装置等の汎用コンピューティング装置上にホログラフィック閲覧環境を確立するプログラムによって閲覧環境内で実行することができる。

ブロック２２１において、サーバは３Ｄセグメント化医用画像データを変換するための要求を受信する。例えば、サーバはインターネット又は広域ネットワークを介して要求を受信するクラウドサーバである。代替として、サーバはローカルエリアネットワーク（ＬＡＮ）上のサーバである。例えば、３Ｄセグメント化医用画像データは、ユーザと関連付けられるクライアント装置で実行されているアプリケーションからのものである。セグメント化は、例えば、特定の人体解剖学的構造又は対象領域の複数のサブセグメント化（個々のマスク）からなっている。セグメント化は、医用画像データを含む元のファイルをホログラフィック可能ファイルに変換するために用いられる。ユーザは元のデータをセグメント化するために用いられる医療用アプリケーションを用いてこれを要求する。

ブロック２２２において、変換されたデータへのアクセス制限が特定される。例えば、変換されたモデルのアクセス（クラウド又はローカル設置ベースのアーキテクチャ）は、ホログラム又は３Ｄモデルをホログラフィック又は仮想現実プラットフォームにレンダリングするために特定のユーザに制限される。例えば、ホログラフィック又は仮想現実プラットフォームは、ホログラフィック又は仮想現実を表示することに専念する装置上で動作するか、又は、パーソナルコンピュータ、スマートフォン、又はタブレットコンピューティング装置等の汎用コンピューティング装置上のアプリケーションとして動作する。

ブロック２２３において、医用画像ファイルは医用画像データから作成される。医用画像ファイルはセグメント化及びサブセグメント化を含む。例えば、セグメント化及びサブセグメント化は、マスクセグメント化情報、カラーパレット、シャドーイング、透明度、不透明度、及びこれら全ての情報がヘルスケアネットワーク内で都合よく転送されることを可能にする医療データからの対象領域を含んでいる。

図２２は、レンダリングされた医用画像を複数人が閲覧することを示す略フロー図である。ブロック２３１において、サーバは、クライアントシステムへのストリーミングのために３Ｄセグメント化医用画像データを医用閲覧データにレンダリングする。例えば、サーバはインターネット又は広域ネットワークを介して要求を受信するクラウドサーバである。代替として、サーバはローカルエリアネットワーク（ＬＡＮ）上のサーバである。例えば、３Ｄセグメント化医用画像データは、ユーザと関連付けられるクライアント装置で実行されているアプリケーションからのものである。セグメント化は、例えば、特定の人体解剖学的構造又は対象領域の複数のサブセグメント化（個々のマスク）からなっている。セグメント化は、特定の人体解剖学的構造又は対象領域の個々のセグメント化マスクの複数のサブセグメント化からなっている。例えば、サーバは、医用画像をその生の形式（例えば、ＤＩＣＯＭ医療データ形式）でレンダリングしてクライアントにストリーミングする。例えば、クライアントは、ＨｏｌｏＬｅｎｓ（商標）ヘッドセット等のホログラフィックデバイス、又はスマートフォン、タブレットコンピューティング装置、ラップトップコンピュータ等のモバイル装置及び／又は仮想現実装置上で動作するホログラフィックプラットフォームである。例えば、サーバレンダリングは、いずれかのファイルサイズの制限なしに、及びＣＴスキャナ及び／又はＭＲＩ装置等の１つ以上の撮像装置によって取得されるような元の形式でのレンダリングを可能にする。

ブロック２３２において、レンダリングされるような医療用閲覧データは、拡張現実環境及び／又は仮想現実環境に配置される。代替として、又は加えて、医療用閲覧データは、専用の医療用ビューアによってレンダリング及び閲覧される。例えば、医療ビューワは、例えば、拡張現実及び／又は仮想現実の使用を含む、特殊な医療用途及び機能を含む。

ブロック２３３において、エンドユーザは、レンダリングされた医療用閲覧データをレンダリングし、操作し、調整し、及びレンダリングのためのアルゴリズムを適用する。閲覧されるようなデータは、例えば、３Ｄレンダリングされたデータ、ホログラム、特別な医用画像閲覧装置で閲覧するためにフォーマットされた画像データのうちの１つ又はそれらの組み合わせであってもよい。

ブロック２３４において、他のユーザは、エンドユーザに表示される医療用閲覧データへの閲覧を提供される。例えば、１人又は複数の他のユーザが、エンドユーザのビューに表示されているものをリアルタイムで自身の閲覧装置で表示することを可能とされている。これは、例えば、そのロードされた要素を含む同じホログラフィック又は仮想環境を含む。例えば、医用画像ビューワは、設定と同期されて、同じ拡張現実眼鏡において同時に閲覧される拡張現実体積測定解剖学的オブジェクトを生成するために用いられる元の医用画像データの向きを含む仮想閲覧領域に配置される。又は同様に、ＰＣモニタ、モバイル装置、又は他の閲覧装置、又はそれらの組み合わせ等の別の装置で閲覧される。

共有ホログラフィック環境又は仮想環境は、エンドユーザによって操作及び共有することができ、例えば、ロードされたアプリケーション、ロードされた画像、ロードされた３Ｄレンダリング等について他のユーザとの検討を可能にする。共有環境は、各ユーザの実際の４Ｄ取込としての各ユーザの表現、又はそれらの３Ｄ表現を含むことができる。

代替として、又は加えて、異なるユーザ装置上の数人のユーザは、上で説明したように、観察者構成において異なるビューア位置を確立することができ、異なるビューア位置は、例えば、エンドユーザが見ているものとは異なる視野角を含む、エンドユーザのための閲覧位置とは異なる閲覧位置にビューアを配置することを含んでいる。

例えば、医用画像ビューワ上のユーザは、仮想閲覧領域に仮想的に配置される。同じ種類の医用画像ビューアにおいて同時に閲覧される拡張現実体積測定解剖学的オブジェクトを作成するために用いられる元の医用画像データの設定及び向きの同期が存在する。例えば、各医用画像ビューアは拡張現実眼鏡を含む。また、仮想現実についても同様に、ＰＣモニタ、モバイル装置、若しくは他の閲覧装置、又はそれらの組み合わせで閲覧することが用いられてもよい。

前記の検討は、単に例示的な方法及び実装を開示及び説明している。当業者によって理解されるように、開示した主題はその精神又は特徴から逸脱することなく他の特定の形態で具現化されてもよい。従って、本開示は、以下の特許請求の範囲に記載する本発明の適用範囲の例示であることを意図しているが、限定するものではない。

Claims (16)

1. ネットワークを通じて自動化される三次元（３Ｄ）プリンティングワークフローを提供するための方法であって、
   前記ネットワークを介してネットワークサーバにより、３Ｄセグメント化された医用画像データを３Ｄプリンタでプリントするためのプリント可能な情報に変換する要求を受信することと、
   変換されたデータへのアクセスを１人以上の許可ユーザに制限することと、
   前記３Ｄセグメント化医用画像データを変換されたデータファイルに変換することであって、前記変換されたデータファイルは、特定の人体解剖学的構造又は対象領域の複数のサブセグメント化を可能にする医用画像データファイル形式であり、前記医用画像データファイル形式は、マスクセグメント化情報、カラーパレット、シャドーイング、透明度、及び不透明度の格納を可能にすることと、
   前記変換されたデータファイルから、３Ｄプリンタ上で物理的オブジェクトにプリントするための３Ｄプリント可能ファイルを作成することであって、前記物理的オブジェクトは前記変換されたデータファイル内の情報に従って、マスクセグメント化情報、カラーパレット、シャドーイング、透明度、及び不透明度を含むことと、を含む、
   方法。
2. 前記ネットワークサーバはクラウドサーバであり、前記ネットワークはインターネット又は別の広域ネットワークである、請求項１に記載の方法。
3. 前記ネットワークは医療機関内のローカルエリアネットワークである、請求項１に記載の方法。
4. 前記医用画像データファイル形式はＤＩＣＯＭ医用画像データファイル形式である、請求項１に記載の方法。
5. 前記３Ｄプリント可能ファイルはポリゴンメッシュファイルである、請求項１に記載の方法。
6. 前記医用画像データファイル形式は、医療におけるデジタル画像と通信（ＤＩＣＯＭ）ファイル形式である、請求項１に記載の方法。
7. 医用画像データを変換データ形式における変換データに変換する方法であって、前記変換データ形式は、前記変換データがホログラフィック又は仮想現実装置上で閲覧するためにレンダリングされることを可能にし、
   ネットワークを介してネットワークサーバにより、セグメント化医用画像データを前記変換データ形式の前記変換データに変換する要求を受信することと、
   前記変換データへのアクセスを１人以上の許可ユーザに制限することと、
   前記セグメント化医用画像データを前記変換データ形式に変換することであって、前記変換データ形式は特定の人体解剖学的構造又は対象領域の複数のサブセグメント化を可能にし、前記変換データ形式は、マスクセグメント化情報、カラーパレット、シャドーイング、透明度、及び不透明度を格納することを可能にすることと、
   ホログラフィックプラットフォーム又は仮想現実プラットフォーム上に表示するために、前記変換データを許可ユーザに転送することと、を含む、
   方法。
8. 前記変換ファイル形式は、医療におけるデジタル画像と通信（ＤＩＣＯＭ）ファイル形式である、請求項７に記載の方法。
9. 前記セグメント化医用画像データはＤＩＣＯＭ医用画像データファイル形式である、請求項７に記載の方法。
10. 前記変換データはホログラフィック装置上で閲覧されている、請求項７に記載の方法。
11. 前記変換データは仮想現実装置上で閲覧されている、請求項７に記載の方法。
    
12. 前記ネットワークサーバはクラウドサーバであり、前記ネットワークはインターネット又は別の広域ネットワークである、請求項７に記載の方法。
13. 前記ネットワークは医療機関内のローカルエリアネットワークである、請求項７に記載の方法。
14. レンダリングされた医用画像を複数の人が閲覧することを可能にする方法であって、
    サーバによって、クライアントシステム上のエンドユーザにストリーミングするために三次元（３Ｄ）セグメント化医用画像データを医療用閲覧データにレンダリングすることと、
    前記クライアントシステム上の前記エンドユーザに、拡張現実環境又は仮想現実環境内で前記医療用閲覧データを表示することと、
    前記エンドユーザが、前記拡張現実環境又は前記仮想現実環境内に表示されるような前記レンダリングされた医療用閲覧データをレンダリング、操作、及び調整することを可能にすることと、
    １人以上の他のユーザに、前記エンドユーザに表示される医療用閲覧データへの閲覧を提供することと、を含む、
    方法。
15. 前記１人以上の他のユーザは、前記エンドユーザと同じ前記拡張現実環境又は前記仮想現実環境内のビューア位置及び同じビューア角度を有する、請求項１４に記載の方法。
16. 前記１人以上の他のユーザは、前記エンドユーザと前記拡張現実環境又は前記仮想現実環境内の１つ以上の異なるビューア位置及び１つ以上の異なるビューア角度を有する、請求項１４に記載の方法。