JP2016202340A - 医用画像処理システム、医用画像処理装置、その制御方法、及びプログラム - Google Patents

Abstract

【課題】医用画像に対する造形依頼が重複して行われることを抑止可能な仕組みを提供すること【解決手段】立体造形装置１０３で立体造形を行うための依頼を受け付けることが可能な医用画像処理システム１００であって、医用画像を用いた造形依頼を医用画像ごとに受付可能な画面を生成する際に、生成された画面を介して造形依頼を受け付けた医用画像に対する更なる造形依頼を受け付けることのできないように、当該医用画像に対応する依頼ボタンを非表示にした画面を生成する。【選択図】図１

Description

本発明は、医用画像に対する造形依頼が重複して行われることを抑止可能な医用画像処理システム、医用画像処理装置、その制御方法、及びプログラムに関する。

Ｘ線ＣＴやＭＲＩといったモダリティで生成された複数の医用画像を用いてコンピュータ上でボリュームデータを生成し、ボリュームレンダリングを行うことにより人体の部位を立体的に表示する仕組みが存在する。

また、コンピュータで人体の部位を仮想的に立体表示するだけでなく、立体造形装置で造形物として出力する仕組みが存在する。この造形物は、医療現場や研究現場等で活用されている。

このように立体造形装置で造形物として出力することは、医用に関する知識や医用画像の画像処理に関する知識、更には立体造形装置に関する知識が求められるため、容易に行うことができない。

そこで特許文献１には、医用画像と、造形物として出力したい人体の部位と、その他の造形に必要な指示内容をサービス事業者のシステムに送信するだけで、対象の部位の造形物を造形することの可能な仕組みが開示されている。

特開２００２−８６５７６号公報

しかしながら、特許文献１の仕組みでは、依頼側のユーザが何度も同じ造形依頼を行ってしまい、サービス事業者側のサーバの処理負荷が高くなってしまう問題がある。サービス事業者側のサーバでは、人体の部位を医用画像から抽出するための画像処理が行われる。医用画像を立体造形装置で造形するためにはボリュームデータを生成しなければならず、この生成されたボリュームデータから特定の部位を抽出するとなると、二次元の画像処理よりも処理負荷が高い。すなわち、依頼側のユーザが造形依頼したことを忘れて何度も同じ造形依頼を行ってしまうと、サーバは何度も画像処理を行わなければならなくなり、処理負荷が高くなってしまう。

本発明の目的は、医用画像に対する造形依頼が重複して行われることを抑止可能な仕組みを提供することである。

上記の目的を達成するために本発明の医用画像処理システムは、立体造形装置で立体造形を行うための依頼を受け付けることが可能な医用画像処理システムであって、医用画像を記憶する記憶手段と、前記記憶手段に記憶される医用画像を用いた造形依頼を前記医用画像ごとに受付可能な画面を生成する画面生成手段とを備え、前記画面生成手段は、前記画面生成手段で生成された画面を介して造形依頼を受け付けた医用画像に対する更なる造形依頼を受け付けることのできない前記画面を生成することを特徴とする。

本発明によれば、医用画像に対する造形依頼が重複して行われることを抑止可能となる。

本発明の概要を示す図である。 医用画像処理システム１００のシステム構成を示す図である。 クライアント端末１０１、医用画像処理サーバ１０２のハードウェア構成を示す図である。 クライアント端末１０１、医用画像処理サーバ１０２の機能構成を示す図である。 医用画像一覧画面７００を表示する一連の処理のフローチャートを示す図である。 医用画像管理テーブル６００のテーブル構成を示す図である。 医用画像一覧画面７００の画面構成を示す図である。 依頼内容入力画面１０００を表示する一連の処理のフローチャートを示す図である。 造形部位管理テーブル９００のテーブル構成を示す図である。 依頼内容入力画面１０００の画面構成を示す図である。 依頼内容を受け付ける一連の処理のフローチャートを示す図である。 依頼情報管理テーブル１２００のテーブル構成を示す図である。 医用画像から３Ｄ ＰＤＦデータを生成するまでの処理の概要を示す図である。 依頼結果を表示する一連の処理のフローチャートを示す図である。 ３Ｄ ＰＤＦデータを表示した場合を示す図である。 依頼を確定する一連の処理のフローチャートを示す図である。 依頼を取り消す一連の処理のフローチャートを示す図である。

以下、図面を参照して本発明の実施形態について詳細に説明する。

まず図１を用いて本発明の概要について説明する。本発明の医用画像処理システム１００では、クライアント端末１０１と医用画像処理サーバ１０２と立体造形装置１０３とを含むシステムである。クライアント端末１０１と医用画像処理サーバ１０２とが通信可能に接続されており、更に医用画像処理サーバ１０２と立体造形装置１０３とが通信可能に接続されている。

クライアント端末１０１は、あらかじめ医用画像処理サーバ１０２にＸ線ＣＴやＭＲＩといったモダリティで生成された医用画像を送信しておき、医用画像処理サーバ１０２はこれを記憶する。本実施形態における医用画像とは、モダリティで生成された断面画像である。また、医用画像はＤＩＣＯＭ（Ｄｉｇｉｔａｌ Ｉｍａｇｉｎｇ ａｎｄ ＣＯｍｍｕｎｉｃａｔｉｏｎ ｉｎ Ｍｅｄｉｃｉｎｅ）規格の画像であり、ＤＩＣＯＭの付帯情報（以下、ＤＩＣＯＭタグという。）に検査日、患者名、検査種、部位等の情報が格納されている。すなわち、医用画像にはこれらの情報が含まれている。そして、医用画像処理サーバ１０２で医用画像を記憶する際には、１の検査で生成された複数の医用画像をシリーズ化（グルーピング）して記憶しておく。尚、本実施形態ではこのシリーズ化した医用画像群を医用画像と称する。

クライアント端末１０１は、医用画像処理サーバ１０２に記憶されている医用画像に含まれる人体の部位を示す造形物を立体造形装置で造形したい場合、クライアント端末１０１でその旨の指示を受け付ける。クライアント端末１０１のディスプレイに１１０に示すような画面を表示させる。この画面を医用画像処理サーバ１０２で生成する際に、すでに依頼済みである医用画像については、更なる依頼が行われないように依頼ボタンを非表示にする。このようにすることで、依頼者であるユーザはすでに依頼済みであることを識別可能となり、かつ医用画像処理サーバ１０２に造形依頼がなされないので医用画像処理サーバ１０２の処理負荷が軽減される。

次に、依頼者であるユーザは対象の医用画像のレコードに備えられている依頼ボタンを押下する。この押下を検知すると、クライアント端末１０１のディスプレイに１２０に示すような画面を表示させる。この画面で造形したい人体の部位の選択を受け付ける。

造形したい部位をユーザが選択し、クライアント端末１０１がＯＫボタンの押下を検知すると、造形依頼がクライアント端末１０１から医用画像処理サーバ１０２に送信される。医用画像処理サーバ１０２は、この依頼を受け付けると対象の医用画像を用いてボリュームデータを生成する。ボリュームデータとは、医用画像を三次元的に積層し、医用画像の各ピクセルが有するＣＴ値（水を０、空気を−１０００とした場合の相対値）を当該ピクセルに対応するボクセルのパラメータとして持たせたデータのことである。医用画像処理サーバ１０２は、このボリュームデータに見た目の情報（色、視点、光源、光沢等）を付与し、３Ｄデータを生成する。この３Ｄデータは、例えばＶＲＭＬ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）形式やＳＴＬ（Ｓｔａｎｄａｒｄ Ｔｒｉａｎｇｕｌａｔｅｄ Ｌａｎｇｕａｇｅ）形式といった３Ｄモデルを示すデータである。

こうした３Ｄデータを立体造形装置１０３で造形可能なジョブ（以下、造形ジョブという。）をドライバ（以下、立体造形ドライバという。）で生成し、造形ジョブを立体造形装置１０３に送信し、造形物を出力する。このように、医用画像を用いた人体の部位の造形依頼を行うと立体造形装置で造形を行う仕組みにおいて、すでに依頼済みの医用画像については依頼ボタンを表示しないことで更なる造形依頼を受けるけることのできない画面を生成する。これにより、ユーザが重複して造形依頼を行わないようにすることができる。以下、この概要の詳細について説明する。

図２は、医用画像処理システム１００のシステム構成を示す図である。尚、図２に示すシステム構成は、あくまで一例である。

医用画像処理システム１００は、クライアント端末１０１、医用画像処理サーバ１０２、立体造形装置１０３を含むシステムである。クライアント端末１０１と医用画像処理サーバ１０２、医用画像処理サーバ１０２と立体造形装置１０３のそれぞれは、ローカルエリアネットワーク（ＬＡＮ）２０１またはインターネット等を介して通信可能に接続されている。尚、立体造形装置１０３を医用画像処理システム１００に含めない形態であってもよい。

クライアント端末１０１は、立体造形の依頼を行う依頼者側の１または複数の装置である。クライアント端末１０１は、パーソナルコンピュータであってもよいし、携帯端末（携帯電話、スマートフォン、ウェアラブルデバイス）であってもよい。

医用画像処理サーバ１０２（医用画像処理装置）は、立体造形の依頼を受け付ける事業者側の１または複数の装置である。医用画像処理サーバ１０２はサーバ装置を想定するが、複数のクライアント端末１０１からの依頼を処理可能であれば、どのような装置であってもよい。

立体造形装置１０３は、３Ｄデータの造形物を出力する１または複数の装置（いわゆる３Ｄプリンタ）である。立体造形装置１０３は事業者が有していてもよいし、そうでなくてもよい。立体造形装置１０３の造形方法は積層造形法や超音波造形法等、様々な方法があるが特に問わない。また造形物を構成する素材についても、樹脂や金属、ゴムといった様々な素材があるが特に問わない。依頼者側が依頼する際の選択肢を広げることができるため、医用画像処理サーバ１０２は、様々な種類の立体造形装置１０３と通信可能に接続しておくことが望ましい。

図３は、クライアント端末１０１及び医用画像処理サーバ１０２のハードウェア構成を示す図である。尚、図３に示すハードウェア構成はあくまで一例である。

ＣＰＵ３０１は、システムバス３０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ３０２あるいは外部メモリ３１１には、ＣＰＵ３０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステムプログラムが記憶されている。また外部メモリ３１１には、各装置が実行する機能を実現するために必要な各種プログラム等が記憶されている。ＲＡＭ３０３は、ＣＰＵ３０１の主メモリ、ワークエリア等として機能する。

ＣＰＵ３０１は、処理の実行に際して必要なプログラム等をＲＡＭ３０３にロードして、プログラムを実行することで各種動作を実現するものである。

また、入力コントローラ３０５は、キーボードやマウス等のポインティングデバイスといった入力デバイス３０９からの入力を制御する。

ビデオコントローラ３０６は、ディスプレイ３１０等の表示器への表示を制御する。表示器はＣＲＴや液晶ディスプレイでも構わない。

メモリコントローラ３０７は、ハードディスクやフレキシブルディスク或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の外部メモリ３１１へのアクセスを制御する。外部メモリ３１１（記憶手段）は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する。

通信Ｉ／Ｆコントローラ３０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。

尚、ＣＰＵ３０１は、例えばＲＡＭ３０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ３１０上での表示を可能としている。また、ＣＰＵ３０１は、ディスプレイ３１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明のクライアント端末１０１及び医用画像処理サーバ１０２が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ３１１に記録されている。この各種プログラム等は必要に応じてＲＡＭ３０３にロードされることによりＣＰＵ３０１によって実行されるものである。さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルは外部メモリ３１１に格納されている。

図４は、クライアント端末１０１及び医用画像処理サーバ１０２の機能構成の一例を示す図である。尚、図４に示す各機能は、図２に示す各ハードウェアや各種プログラム等により実現される構成要素である。また、図４に示す機能構成はあくまで一例である。

クライアント端末１０１は機能部として、通信制御部４０１と、表示部４０２と、ウェブブラウザ部４０３とを備える。

通信制御部４０１は、医用画像処理サーバ１０２と各種情報を送受信するための機能部である。通信制御部４０１は、クライアント端末１０１の通信Ｉ／Ｆコントローラ３０８を介して、ネットワーク上の医用画像処理サーバ１０２と通信する。

表示部４０２は、各種情報を表示するための機能部である。表示部４０２は、クライアント端末１０１のビデオコントローラ３０６を介して各種情報が記された画像をディスプレイ３１０に対して送信し、ディスプレイ３１０に各種情報を表示させる。

ウェブブラウザ部４０３は、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等で記述されたウェブページ（本実施形態でいう画面）を表示及び動作させるための機能部である。ウェブブラウザ部４０３は、更に、レンダリング部４０４と操作受付部４０５とを備える。

レンダリング部４０４は、ウェブページの記述内容を解析し、文字や画像をディスプレイに表示するための機能部である。操作受付部４０５は、ウェブページに対する操作を受け付けるための機能部である。更に、操作受付部４０５は、受け付けた操作に応じてウェブページやファイルの取得要求を、通信制御部４０１を介して医用画像処理サーバ１０２に送信する。

医用画像処理サーバ１０２は機能部として、通信制御部４１１と、記憶部４１２と、画面生成部４１３と、立体造形ドライバ部４１５と、３Ｄ制御部４１７とを備える。

通信制御部４１１は、クライアント端末１０１及び立体造形装置１０３と各種情報を送受信するための機能部である。通信制御部４０１は、医用画像処理サーバ１０２の通信Ｉ／Ｆコントローラ３０８を介して、ネットワーク上のクライアント端末１０１及び立体造形装置１０３と通信する。

記憶部４１２は、各種情報をＲＡＭ３０３または外部メモリ３１１に記憶するための機能部である。記憶部４１２が記憶する各種情報としては、後述する各種テーブルやクライアント端末１０１に表示させるためのウェブページのテンプレート等である。

画面生成部４１３（画面生成手段）は、クライアント端末１０１で表示させるための画面（ウェブページ）を生成するための機能部である。画面生成部４１３は、記憶部４１２に記憶されている各種情報を用いて画面を生成する。画面生成部４１３は、造形部位特定部４１４を更に備える。

造形部位特定部４１４は、クライアント端末１０１から指示された医用画像を記憶部４１２から取得し、この医用画像から造形可能な人体の部位を特定するための機能部である。造形部位特定部４１４は、医用画像のＤＩＣＯＭタグに含まれる検査部位の情報から、造形可能な人体の部位を特定する。

立体造形ドライバ部４１５は、立体造形装置１０３に対して造形指示を行うための機能部である。立体造形ドライバ部４１５は、更に造形ジョブ生成部４１６を備える。

造形ジョブ生成部４１６は、後述する３Ｄデータ生成部４２０で生成された３Ｄデータを立体造形装置１０３で造形するための造形ジョブを生成する機能部である。立体造形装置１０３で造形するための造形ジョブの生成方法は、従来技術であるので説明は省略する。

３Ｄ制御部４１７は、三次元空間上での立体的なデータの生成や表示といった制御を行うための機能部である。３Ｄ制御部４１７は、更にボリュームデータ生成部４１８と、造形部位抽出部４１９と、３Ｄデータ生成部４２０と、３Ｄ ＰＤＦデータ生成部４２１とを備える。

ボリュームデータ生成部４１８は、医用画像からボリュームデータを生成するための機能部である。ボリュームデータ生成部４１８は、複数の医用画像を用いてボリュームデータを生成する。また、ボリュームデータ生成部４１８は、ボリュームデータを生成するための医用画像が足りない場合には、足りない部分を適宜補間する。ボリュームデータの生成方法については従来技術を用いるため、詳細な説明は省略する。

造形部位抽出部４１９は、クライアント端末１０１で選択された人体の部位をボリュームデータから抽出するための機能部である。抽出するための既知のアルゴリズムを、人体の部位ごとに記憶部４１２に記憶しておき、造形部位抽出部４１９は抽出する際に記憶部４１２から必要なアルゴリズムを選択して部位の抽出を行う。ボリュームデータから特定の部位を抽出する方法やそのアルゴリズムについても、従来の技術を用いるため詳細な説明は省略する。

３Ｄデータ生成部４２０は、造形部位抽出部４１９で特定の部位が抽出されたボリュームデータを用いて、３Ｄデータを生成するための機能部である。３Ｄデータ生成部４２０は、ＶＲＭＬ形式やＳＴＬ形式といった立体造形ドライバ部４１５が解析可能な形式の３Ｄデータを生成する。

３Ｄ ＰＤＦデータ生成部４２１は、３Ｄデータが含まれるＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）データ（以下、３Ｄ ＰＤＦデータという。）を生成するための機能部である。３Ｄ ＰＤＦデータは、ユーザが３Ｄデータを自由な視点で表示することが可能なＰＤＦデータである。３Ｄ ＰＤＦデータの生成方法についても、従来の技術を用いるため、詳細な説明は省略する。

図５は、医用画像一覧画面７００を表示する一連の処理のフローチャートを示す図である。図５のステップＳ５０１、ステップＳ５０９、ステップＳ５１０の各ステップは、クライアント端末１０１のＣＰＵ３０１によって実行される処理である。また、図５のステップＳ５０２乃至ステップＳ５０８の各ステップは、医用画像処理サーバ１０２のＣＰＵ３０１によって実行される処理である。尚、図５に示す処理内容や処理順はあくまで一例であり、これに限らない。

ステップＳ５０１では、クライアント端末１０１の通信制御部４１１は、医用画像一覧画面の取得要求を医用画像処理サーバ１０２に送信する。

ステップＳ５０２では、医用画像処理サーバ１０２の通信制御部４１１は、クライアント端末１０１から送信された医用画像一覧画面の取得要求を受信する。そして、ステップＳ５０３では、医用画像処理サーバ１０２の画面生成部４１３は、記憶部４１２から医用画像一覧画面のテンプレートと図６の医用画像管理テーブル６００に格納されている情報を取得し、図７に示すような医用画像一覧画面７００を生成する。医用画像一覧画面７００には医用画像一覧７０１を備えており、医用画像管理テーブル６００のレコードごとに医用画像一覧７０１にレコードを設ける。そして、医用画像一覧７０１の各レコードには、対応する画像ＩＤ６０１を埋め込んでおく。

また、ステップＳ５０２で画面を生成する際には、後述する処理で配置する依頼ボタン７０２と、確認ボタン７０３と、確定ボタン７０４と、取消ボタン７０５とはまだ配置しない。更に、医用画像一覧７０１には、医用画像のレコードごとに表示ボタン７０６を配置する。表示ボタン７０６は、医用画像を表示するためのボタンである。そのため、表示ボタン７０６は、表示ボタン７０６が配置されるレコードに対応する医用画像の医用画像保存場所６０７から医用画像を取得して表示可能なボタンとして配置する。

医用画像管理テーブル６００は、医用画像処理サーバ１０２の外部メモリ３１１に記憶された医用画像に関する情報を格納するためのデータテーブルである。医用画像管理テーブル６００は、医用画像処理サーバ１０２の外部メモリ３１１に記憶される。また、クライアント端末１０１やモダリティから医用画像を受信すると、医用画像管理テーブル６００に新たなレコードを作成し、医用画像のＤＩＣＯＭタグから各種情報を取得し、医用画像管理テーブル６００に格納する。尚、医用画像管理テーブル６００のテーブル構成は一例であるので、これに限らない。

医用画像管理テーブル６００は項目として、画像ＩＤ６０１と、検査日６０２と、患者名６０３と、検査種６０４と、部位６０５と、枚数６０６と、医用画像保存場所６０７とを備える。画像ＩＤ６０１は、受信した医用画像ごとに一意に割り振られる識別情報が格納される項目である。検査日６０２は、モダリティによって撮影された日が格納される項目である。患者名６０３は、患者の氏名が格納される項目である。部位６０５は、医用画像が撮影された部位が格納される項目である。枚数６０６は、受信した医用画像の枚数が格納される項目である。医用画像保存場所６０７は、医用画像が保存されているフォルダを示す情報が格納される項目である。

ステップＳ５０４では、医用画像処理サーバ１０２の画面生成部４１３は、医用画像管理テーブル６００のいずれかのレコードを参照する。そして、参照したレコードに対してステップＳ５０５乃至ステップＳ５０８の各ステップが完了したら、医用画像管理テーブル６００のすべてのレコードに対してステップＳ５０５乃至ステップＳ５０８の処理が完了したか否かを判定する。完了したと判定した場合には、ステップＳ５０９に処理を進める。すなわち、医用画像管理テーブル６００のすべてのレコードに対してステップＳ５０５乃至ステップＳ５０８の処理が行われるまでループさせる。以下、ステップＳ５０５乃至ステップＳ５０８の各ステップについて説明する。

ステップＳ５０５では、医用画像処理サーバ１０２の画面生成部４１３は、参照中のレコードの枚数６０６が所定枚数以上の医用画像であり、かつ図１２の依頼情報管理テーブル１２００に当該医用画像の依頼情報が存在しない医用画像であるか否かを判定する。そうである場合にはステップＳ５０６に処理を進め、そうでない場合にはステップＳ５０７に処理を進める。尚、所定枚数より多い医用画像であり、かつ依頼情報が存在しない医用画像か否かを判定してもよい。医用画像の枚数については、医用画像から人体の部位を示すボリュームデータを生成可能な枚数をあらかじめ設定しておく。または、ボリュームデータにした場合に粗さが目立たない程度の枚数や、造形物として出力した際に曲面が滑らかになる枚数を設定してもよい。

また、依頼情報管理テーブル１２００は、造形依頼に関する情報が格納されるデータテーブルである。依頼情報管理テーブル１２００の１レコード分を本実施形態では依頼情報と称する。依頼情報管理テーブル１２００の詳細については後述する。

ステップＳ５０６では、医用画像処理サーバ１０２の画面生成部４１３は、参照中のレコードに対応する医用画像一覧７０１のレコードに依頼ボタン７０２（受付部）を配置する。依頼ボタン７０２は、医用画像から人体の部位の造形依頼（造形指示）を受付可能なボタンである。必要な枚数を有する医用画像は、造形依頼が可能な医用画像であるので依頼ボタン７０２を配置する。更に、造形依頼は可能だが、すでに造形依頼がなされている場合には、更なる依頼を行ってしまうと医用画像処理サーバ１０２の処理負荷が高くなってしまう。そのため、造形依頼は可能だが依頼済みである場合には、依頼ボタンを配置せず、造形依頼が可能で依頼済みでないなら依頼ボタンを配置する。このように医用画像ごとに識別表示させることで、医用画像処理サーバ１０２の処理負荷を軽減することが可能となる。また、ユーザに対しても依頼済みであることを医用画像ごとに認識させることが可能となる。更には、ステップＳ５０５の判定を行うことで、医用画像が所定枚数未満（所定枚数以下であってもよい。）である場合には、ステップＳ５０６が実行されないので、当該医用画像のレコードには依頼ボタン７０２が配置されない。これにより医用画像の枚数が足りない場合にユーザが造形依頼することを抑止できる。

本実施形態では、依頼済みの医用画像のレコードには依頼ボタンを配置しないことで更なる造形指示を受け付けない形態としたが、依頼ボタンは配置するが押下できないようなボタンとすることで依頼済みであることを認識させてもよい。または、依頼ボタンは配置するが依頼ボタンの色や形や依頼ボタンに表示する文字列を変更することで依頼済みであることを認識させてもよい。更には、依頼ボタンを配置し、配置した依頼ボタンの押下も可能とするが、依頼ボタンが押下された場合にエラーを通知して造形依頼がなされないように制御してもよい。

ステップＳ５０７では、医用画像処理サーバ１０２の画面生成部４１３は、参照中のレコードの医用画像に対応する依頼情報が依頼情報管理テーブル１２００に存在し、かつ依頼情報のステータス１２０８が依頼者確認中であるか否かを判定する。つまり、参照中のレコードの医用画像を用いた造形を依頼済みであり、かつ依頼に応じた依頼結果が出力されているか否かを判定する。そうである場合にはステップＳ５０８に処理を進め、そうでない場合にはステップＳ５０４に処理を戻し、ループが完了したか否かを判定する。ループが完了したと判定されたら、ステップＳ５０９に処理を進める。

ステップＳ５０８では、医用画像処理サーバ１０２の画面生成部４１３は、参照中のレコードに対応する医用画像一覧７０１のレコードに確認ボタン７０３、確定ボタン７０４、取消ボタン７０５を配置する。

確認ボタン７０３は、依頼結果を確認するためのボタンである。依頼情報の確認形式１２０６が３Ｄデータである場合には、確認ボタン７０３を３Ｄデータ保存場所１２０９が示す保存場所から依頼結果の３Ｄデータをダウンロード可能なボタンとする。一方、依頼情報の確認形式１２０６が３Ｄ ＰＤＦデータである場合には、確認ボタン７０３を３Ｄ ＰＤＦデータ保存場所１２１０が示す保存場所から依頼結果の３Ｄ ＰＤＦデータを表示可能なボタンとする。すなわち、依頼者であるユーザから選択された確認形式に応じて、確認ボタン７０３が押下された場合の動作が決定される。そして、３Ｄデータをダウンロード可能なボタンなのか、３Ｄ ＰＤＦデータを表示可能なボタンなのかを識別可能にするべく、確認ボタン７０３の表示形態を変える。例えば、確認ボタン７０３の色を変えることで識別可能にする。

また、確定ボタン７０４は、依頼の最終確定を行うためのボタンである。取消ボタン７０５は、依頼をキャンセルするためのボタンである。このように識別表示させることで、依頼結果が出力された場合に確認ボタン７０３が表示されるので、依頼者であるユーザは依頼結果が出力されているか否かを医用画像ごとに認識することができる。

ステップＳ５０８が完了したら、ステップＳ５０４に処理を戻し、ループが完了したか否かを判定する。ループが完了したと判定されたら、ステップＳ５０９に処理を進める。

ステップＳ５０９では、医用画像処理サーバ１０２の通信制御部４１１は、ステップＳ５０３乃至ステップＳ５０８で生成された医用画像一覧画面７００をクライアント端末１０１に送信する。

ステップＳ５１０では、クライアント端末１０１の通信制御部４０１は、医用画像処理サーバ１０２から送信された医用画像一覧画面７００を受信する。そして、ステップＳ５１１では、クライアント端末１０１のレンダリング部４０４は、受信した医用画像一覧画面７００をレンダリングし、表示部４０２はレンダリング結果をクライアント端末１０１のディスプレイ３１０に表示する。

医用画像一覧画面７００が表示された後、クライアント端末１０１は、図８、図１４、図１６、図１７に示す各フローチャートを並列処理により実行する。

図８は、依頼内容入力画面１０００を表示する一連の処理のフローチャートを示す図である。図８のステップＳ８０１、ステップＳ８０２、ステップＳ８０７、ステップＳ８０８の各ステップは、クライアント端末１０１のＣＰＵ３０１によって実行される処理である。また、図８のステップＳ８０３乃至ステップＳ８０６の各ステップは、医用画像処理サーバ１０２のＣＰＵ３０１によって実行される処理である。尚、図８に示す処理内容や処理順はあくまで一例であり、これに限らない。

ステップＳ８０１では、クライアント端末１０１の操作受付部４０５は、医用画像一覧画面７００の依頼ボタン７０２に対する押下を受け付けたか否かを判定する。依頼ボタン７０２に対する押下を受け付けたと判定した場合には、ステップＳ８０２に処理を進める。依頼ボタン７０２に対する押下を受け付けていないと判定した場合には、そのまま待機する。

ステップＳ８０２では、クライアント端末１０１のウェブブラウザ部４０３は、押下を受け付けた依頼ボタン７０２のレコードに埋め込まれた画像ＩＤを取得する。そして、クライアント端末１０１の通信制御部４０１は、この画像ＩＤが示す医用画像（以下、図８においては、対象の医用画像という。）の造形依頼を行うための依頼内容入力画面の取得要求を医用画像処理サーバ１０２に送信する。

ステップＳ８０３では、医用画像処理サーバ１０２の通信制御部４１１は、クライアント端末１０１から送信された依頼内容入力画面の取得要求を受信する。

ステップＳ８０４では、医用画像処理サーバ１０２の造形部位特定部４１４は、対象の医用画像の部位から造形部位を特定する。すなわち、対象の医用画像から造形可能な部位を特定する。具体的に説明を行う。対象の医用画像の部位６０５と検査種６０４とを参照し、これらと一致する部位９０１と検査種９０２とを有するレコードを図９に示す造形部位管理テーブル９００から特定する。造形部位管理テーブル９００は、部位９０１ごとに造形可能な造形部位９０４を規定したデータテーブルである。つまり、この特定したレコードの造形部位９０４が示す部位が当該医用画像から造形可能な部位である。本実施形態では、このように造形部位管理テーブル９００を用いて対象の医用画像から造形可能な部位を特定したが、医用画像を解析することで特定してもよい。すなわち、医用画像を画像処理により解析し、どのような部位が写っているのかを特定する方法である。医用画像をボリュームデータにして、三次元的に解析する方法でもよい。

造形部位管理テーブル９００は、立体造形装置で造形する人体の部位に関する情報を格納するためのデータテーブルである。造形部位管理テーブル９００は、医用画像処理サーバ１０２の外部メモリ３１１に記憶される。尚、造形部位管理テーブル９００のテーブル構成は一例であるので、これに限らない。

造形部位管理テーブル９００は項目として、部位９０１、検査種９０２、器官種別９０３、造形部位９０４、抽出アルゴリズム９０５を備える。部位９０１は、造形部位９０４が含まれる人体の範囲を示す情報が格納される項目である。検査種９０２は、Ｘ線ＣＴやＭＲＩといったモダリティでの検査種別を示す情報が格納される項目である。器官種別９０３は、造形部位９０４が属する器官の種別を示す情報が格納される項目である。器官種別９０３に応じて後述する造形部位選択欄１００１での造形部位９０４の表示位置が決定される。例えば、器官種別９０３が示す分類ごとに造形部位９０４を表示する。造形部位９０４は、造形可能な部位を示す情報が格納される項目である。抽出アルゴリズム９０５は、造形部位９０４を医用画像から抽出するための既知のアルゴリズムが格納される項目である。この造形部位管理テーブル９００は、あらかじめ医用画像処理サーバ１０２の管理者であるユーザによって医用画像処理サーバ１０２の外部メモリ３１１に記憶しておく。

ステップＳ８０５では、医用画像処理サーバ１０２の画面生成部４１３は、ステップＳ８０４で特定した造形可能な部位に対する選択を受け付けることの可能な、依頼内容入力画面を生成する。

依頼内容入力画面１０００の一例を図１０に示す。依頼内容入力画面１０００は、造形部位選択欄１００１、造形方法選択欄１００２、確認形式選択欄１００３、ＯＫボタン１００４を備える。造形部位選択欄１００１は、依頼者であるユーザが造形したい人体の部位を選択するためのチェックボックス形式の選択欄である。この選択欄では、ステップＳ８０４で特定した部位に対する選択を受け付けるようにする。すなわち、ステップＳ８０４で特定されなかった部位に対する選択は受け付けないようにする。尚、ステップＳ８０４で特定した部位の選択欄のみを設けることが望ましい。このようにすることで、対象の医用画像から特定される造形可能な部位に対する選択を受け付けることが可能となるので、依頼者であるユーザが医用画像に対する専門的な知識を有していなくても、造形できない部位の造形依頼を行うことを抑止できる。

本実施形態では、ステップＳ８０４で特定していない部位の選択欄は配置しないことで造形できない部位の造形依頼を抑止する形態としたが、当該選択欄は配置するが選択できないような選択欄としてもよい。または、当該選択欄は配置するが選択欄の色や形や選択欄に表示する文字列に打ち消し線等の装飾を施してもよい。更には、選択欄を配置し選択も可能とするが、ＯＫボタン１００４の押下ができないように制御してもよい。例えば、ＯＫボタン１００４を非表示にしたり、ＯＫボタン１００４の色や形等を変更したりする。更には、ＯＫボタン１００４が押下された場合にエラーを通知して造形依頼がなされないように制御してもよい。

造形方法選択欄１００２は、立体造形装置１０３での造形要否とその造形方法を選択するための選択欄である。造形要否はラジオボタン形式、造形方法はチェックボックス形式で選択可能となっている。更に、造形要否で造形要を選択すると造形方法が選択できるようになる。造形要否で造形不要を選択すると確認形式選択欄１００３で選択した形式のデータが生成され、立体造形装置１０３での造形はなされない。つまり、依頼者であるユーザは３Ｄデータや３Ｄ ＰＤＦデータを取得する目的で依頼することができる。確認形式選択欄１００３は、依頼者であるユーザが選択した人体の部位がどのような立体像となるのかを確認する際の確認形式を選択するための選択欄である。本実施形態では、３Ｄデータでの確認と、３Ｄ ＰＤＦデータでの確認の二種類がある。また、ＯＫボタン１００４は依頼内容入力画面１０００で受け付けた依頼内容を医用画像処理サーバ１０２に送信するためのボタンである。ＯＫボタン１００４には、対象の医用画像の画像ＩＤ６０１が埋め込まれている。更に、図１０の依頼内容入力画面１０００には示さないが、依頼者であるユーザの氏名や連絡先（電話番号、住所）等の依頼者情報を入力するための入力フォームも備える。また、立体造形装置で使用する素材の選択も受け付ける。

ステップＳ８０６では、医用画像処理サーバ１０２の通信制御部４１１は、ステップＳ８０５で生成した依頼内容入力画面１０００をクライアント端末１０１に送信する。

ステップＳ８０７では、クライアント端末１０１の通信制御部４０１は、医用画像処理サーバ１０２から送信された依頼内容入力画面１０００を受信する。そして、ステップＳ８０８では、クライアント端末１０１のレンダリング部４０４は、受信した依頼内容入力画面１０００をレンダリングし、表示部４０２はレンダリング結果をクライアント端末１０１のディスプレイ３１０に表示する。このようにして表示された依頼内容入力画面１０００に対して依頼者であるユーザが依頼内容を入力する。

図１１は、依頼内容を受け付ける一連の処理のフローチャートを示す図である。図１１のステップＳ１１０１、ステップＳ１１０２、ステップＳ１１１５の各ステップは、クライアント端末１０１のＣＰＵ３０１によって実行される処理である。また、図１１のステップＳ１１０３乃至ステップＳ１１１４の各ステップは、医用画像処理サーバ１０２のＣＰＵ３０１によって実行される処理である。尚、図１１に示す処理内容や処理順はあくまで一例であり、これに限らない。

ステップＳ１１０１では、クライアント端末１０１の操作受付部４０５は、依頼内容入力画面１０００のＯＫボタン１００４に対する押下を受け付けたか否かを判定する。ＯＫボタン１００４に対する押下を受け付けたと判定した場合には、ステップＳ１１０２に処理を進める。ＯＫボタン１００４に対する押下を受け付けていないと判定した場合には、そのまま待機する。

ステップＳ１１０２では、クライアント端末１０１のウェブブラウザ部４０３は、押下を受け付けたＯＫボタン１００４に埋め込まれた画像ＩＤと、依頼内容入力画面１０００に入力された依頼内容（造形部位、造形方法、確認形式等）を取得する。そして、クライアント端末１０１の通信制御部４０１は、この画像ＩＤが示す医用画像（以下、図１１においては、対象の医用画像という。）の造形依頼をするべく、取得した画像ＩＤと依頼内容を医用画像処理サーバ１０２に送信する。

ステップＳ１１０３では、医用画像処理サーバ１０２の通信制御部４１１は、クライアント端末１０１から送信された依頼内容と画像ＩＤとを受信する。そして、ステップＳ１１０４では、医用画像処理サーバ１０２の記憶部４１２は、依頼情報管理テーブル１２００に新規レコード（依頼情報）を作成し、このレコードに受信した依頼内容と画像ＩＤとを登録する。

依頼情報管理テーブル１２００は、造形の依頼に関する情報を格納するためのデータテーブルである。依頼情報管理テーブル１２００は、医用画像処理サーバ１０２の外部メモリ３１１に記憶される。尚、依頼情報管理テーブル１２００のテーブル構成は一例であるので、これに限らない。

依頼情報管理テーブル１２００は項目として、依頼ＩＤ１２０１、画像ＩＤ１２０２、造形部位１２０３、造形方法１２０４、造形要否１２０５、確認形式１２０６、依頼者情報１２０７を備える。更には、ステータス１２０８、３Ｄデータ保存場所１２０９、３Ｄ ＰＤＦデータ保存場所１２１０を備える。

依頼ＩＤ１２０１は、依頼情報ごとに一意に割り振られる識別情報が格納される項目である。画像ＩＤ１２０２は、依頼された造形で使用する医用画像の画像ＩＤ６０１が格納される項目である。造形部位１２０３は、造形部位選択欄１００１で選択を受け付けた造形部位が格納される項目である。造形方法１２０４は、造形方法選択欄１００２で選択を受け付けた造形方法が格納される項目である。造形要否１２０５は、造形方法選択欄１００２で選択を受け付けた造形要否が格納される項目である。確認形式１２０６は、確認形式選択欄１００３で選択を受け付けた確認形式が格納される項目である。依頼者情報１２０７は、依頼者の氏名や住所といった情報が格納される項目である。ステータス１２０８は、造形依頼の進捗状況が格納される項目である。依頼を受け付けると依頼受付、後述する処理で依頼結果が出力されると依頼者確認中、依頼の最終確定がなされると依頼確定、立体造形装置に造形指示を行うと造形中、依頼内容が完了した場合には料金請求中、請求した金額が振り込まれると依頼完了となる。必要に応じて、その他のステータスを格納してもよい。３Ｄデータ保存場所１２０９は、後述する処理で生成される３Ｄデータの保存場所が格納される項目である。３Ｄ ＰＤＦデータ保存場所１２１０は、後述する処理で生成される３Ｄ ＰＤＦデータの保存場所が格納される項目である。

ステップＳ１１０５では、医用画像処理サーバ１０２のボリュームデータ生成部４１８は、対象の医用画像を医用画像保存場所６０７から取得し、これを用いてボリュームデータを生成する。対象の医用画像は複数枚あるので、これを積層することでボリュームデータを生成する。ボリュームデータの生成については従来技術を用いるため、詳細な説明は省略する。

ステップＳ１１０６では、医用画像処理サーバ１０２の造形部位抽出部４１９は、ステップＳ１１０５で生成したボリュームデータから、依頼を受け付けた造形部位１２０３を抽出する。造形部位抽出部４１９は、造形部位１２０３に対応する造形部位９０４を特定し、この造形部位９０４に対応する抽出アルゴリズム９０５を用いることで自動的に依頼された人体の部位を抽出する。ボリュームデータから特定の部位を抽出する方法についても、従来技術であるので詳細な説明は省略する。ステップＳ１１０５及びステップＳ１１０６でボリュームデータの生成と指定された部位の抽出を行った場合の概要を、図１３の１３０１に示す。このように複数枚の医用画像から指定された部位の立体像を生成する。図１３は肝臓を抽出した場合を示す。

ステップＳ１１０７では、医用画像処理サーバ１０２の３Ｄ制御部４１７は、依頼された人体の部位の抽出が成功したか否かを判定する。抽出アルゴリズム９０５を用いても医用画像が不鮮明だったり医用画像の枚数が不足していたりすると、依頼された部位を抽出できない可能性がある。そのため、抽出アルゴリズム９０５を実行してエラーが出力された場合には、抽出が失敗したと判定する。依頼された人体の部位の抽出が成功したと判定した場合には、ステップＳ１１０９に処理を進める。そうでない場合、つまり失敗したと判定した場合には、ステップＳ１１０８に処理を進める。

ステップＳ１１０８では、医用画像処理サーバ１０２の通信制御部４１１は、依頼された人体の部位の抽出に失敗した旨の処理結果をクライアント端末１０１に送信する。ステップＳ１１１５では、クライアント端末１０１の通信制御部４０１は、この処理結果を受信し、依頼者であるユーザに通知する。

一方抽出に成功した場合には、ステップＳ１１０９では、医用画像処理サーバ１０２の３Ｄデータ生成部は、ステップＳ１１０６で抽出した部位の３Ｄデータを生成する。依頼された部位が抽出されたボリュームデータを用いて、ＶＲＭＬ形式やＳＴＬ形式等の立体造形ドライバ部４１５で解析可能な３Ｄデータを生成する。３Ｄデータの生成についても従来技術を用いるため説明は省略する。図１３では、１３０２の部分に該当する。

ステップＳ１１１０では、医用画像処理サーバ１０２の記憶部４１２は、ステップＳ１１０９で生成された３Ｄデータを医用画像処理サーバ１０２の外部メモリ３１１に保存する。そして、保存した場所を処理中の依頼に対応するレコードの３Ｄデータ保存場所１２０９に格納する。

ステップＳ１１１１では、医用画像処理サーバ１０２の記憶部４１２は、処理中の依頼に対応するレコードの確認形式１２０６が３Ｄ ＰＤＦデータであるか否かを判定する。すなわち、確認形式選択欄１００３で３Ｄ ＰＤＦデータで確認する旨が依頼者であるユーザによって選択されたか否かを判定する。確認形式１２０６が３Ｄ ＰＤＦデータであると判定した場合には、ステップＳ１１１２に処理を進める。確認形式１２０６が３Ｄ ＰＤＦデータでない、つまり３Ｄデータであると判定した場合には、ステップＳ１１１４に処理を進める。

ステップＳ１１１２では、医用画像処理サーバ１０２の３Ｄ ＰＤＦデータ生成部４２１は、ステップＳ１１０９で生成された３Ｄデータを含む３Ｄ ＰＤＦデータを生成する。処理中の依頼に対応するレコードの３Ｄデータ保存場所１２０９から３Ｄデータを取得し、この３Ｄデータを含めたＰＤＦデータを生成する。３Ｄ ＰＤＦデータの生成方法についても、従来技術を用いるため説明を省略する。図１３では、１３０３の部分に該当する。

ステップＳ１１１３では、医用画像処理サーバ１０２の記憶部４１２は、ステップＳ１１１２で生成された３Ｄ ＰＤＦデータを医用画像処理サーバ１０２の外部メモリ３１１に保存する。そして、保存した場所を処理中の依頼に対応するレコードの３Ｄ ＰＤＦデータ保存場所１２１０に格納する。

ステップＳ１１１４では、医用画像処理サーバ１０２の通信制御部４１１は、依頼された部位の抽出と３Ｄデータまたは３Ｄ ＰＤＦデータの生成が成功した旨の処理結果をクライアント端末１０１に送信する。そして、ステップＳ１１１５では、クライアント端末１０１の通信制御部４０１は、この処理結果を受信し、依頼者であるユーザに通知する。

ステップＳ１１１５までの処理が完了したら、クライアント端末１０１は、医用画像一覧画面７００の更新を行う。すなわち、図５に示す一連の処理を実行する。こうすることで医用画像一覧画面７００が最新の状態に更新される。

図１４は、依頼結果を表示する一連の処理のフローチャートを示す図である。図１４のステップＳ１４０１、ステップＳ１４０２、ステップＳ１４０６、ステップＳ１４０７の各ステップは、クライアント端末１０１のＣＰＵ３０１によって実行される処理である。また、図１４のステップＳ１４０３乃至ステップＳ１４０５の各ステップは、医用画像処理サーバ１０２のＣＰＵ３０１によって実行される処理である。尚、図１４に示す処理内容や処理順はあくまで一例であり、これに限らない。

ステップＳ１４０１では、クライアント端末１０１の操作受付部４０５は、医用画像一覧画面７００の確認ボタン７０３に対する押下を受け付けたか否かを判定する。確認ボタン７０３に対する押下を受け付けたと判定した場合には、ステップＳ１４０２に処理を進める。確認ボタン７０３に対する押下を受け付けていないと判定した場合には、そのまま待機する。

ステップＳ１４０２では、クライアント端末１０１のウェブブラウザ部４０３は、押下を受け付けた確認ボタン７０３のレコードに埋め込まれた画像ＩＤを取得する。そして、クライアント端末１０１の通信制御部４０１は、この画像ＩＤが示す医用画像（以下、図１４においては、対象の医用画像という。）の依頼結果の取得要求を医用画像処理サーバ１０２に当該画像ＩＤを含めて送信する。

ステップＳ１４０３では、医用画像処理サーバ１０２の通信制御部４１１は、クライアント端末１０１から送信された依頼結果の取得要求を受信する。

ステップＳ１４０４では、医用画像処理サーバ１０２の記憶部４１２は、対象の医用画像の処理結果を外部メモリ３１１から取得する。対象の医用画像の画像ＩＤをクライアント端末１０１から受信しているので、この画像ＩＤに対応する画像ＩＤ１２０２を依頼情報管理テーブル１２００のレコードから特定する。そして、特定したレコードの確認形式１２０６が３Ｄデータである場合には、３Ｄデータ保存場所１２０９から依頼結果である３Ｄデータを取得する。一方、特定したレコードの確認形式１２０６が３Ｄ ＰＤＦデータである場合には、３Ｄ ＰＤＦデータ保存場所１２１０から依頼結果である３Ｄ ＰＤＦデータを取得する。

ステップＳ１４０５では、医用画像処理サーバ１０２の通信制御部４１１は、ステップＳ１４０４で取得した処理結果（３Ｄデータまたは３Ｄ ＰＤＦデータ）をクライアント端末１０１に送信する。

ステップＳ１４０６では、クライアント端末１０１の通信制御部４１１は、医用画像処理サーバ１０２から送信された処理結果を受信する。そして、ステップＳ１４０７では、処理結果として３Ｄデータを受信した場合には、クライアント端末１０１は、外部メモリ３１１に３Ｄデータを保存する。そしてユーザからの指示に応じて、保存した３Ｄデータをクライアント端末１０１にインストールされるアプリケーションによって表示する。一方、処理結果として３Ｄ ＰＤＦデータを受信した場合には、クライアント端末１０１の表示部４０２は、クライアント端末１０１にインストールされるＰＤＦのビューワを起動し、受信した３Ｄ ＰＤＦデータをディスプレイ３１０に表示する。図１５は、３Ｄ ＰＤＦデータをＰＤＦのビューワによって表示した場合の一例を示す。このビューワ上で３Ｄデータを操作すると、視点の変更を行うことができる。このようにして、造形依頼を行う前に依頼結果をユーザが確認することができる。また、造形を依頼者であるユーザ自身が行う場合でも立体造形装置１０３で出力可能な３Ｄデータをダウンロードすることが可能となる。

図１６は、依頼を確定する一連の処理のフローチャートを示す図である。図１６のステップＳ１６０１、ステップＳ１６０２の各ステップは、クライアント端末１０１のＣＰＵ３０１によって実行される処理である。また、図１６のステップＳ１６０３乃至ステップＳ１６０９の各ステップは、医用画像処理サーバ１０２のＣＰＵ３０１によって実行される処理である。尚、図１６に示す処理内容や処理順はあくまで一例であり、これに限らない。

ステップＳ１６０１では、クライアント端末１０１の操作受付部４０５は、医用画像一覧画面７００の確定ボタン７０４に対する押下を受け付けたか否かを判定する。確定ボタン７０４に対する押下を受け付けたと判定した場合には、ステップＳ１６０２に処理を進める。確定ボタン７０４に対する押下を受け付けていないと判定した場合には、そのまま待機する。

ステップＳ１６０２では、クライアント端末１０１のウェブブラウザ部４０３は、押下を受け付けた確定ボタン７０４のレコードに埋め込まれた画像ＩＤを取得する。そして、クライアント端末１０１の通信制御部４０１は、この画像ＩＤが示す医用画像（以下、図１６においては、対象の医用画像という。）の最終的な確定要求を医用画像処理サーバ１０２に当該画像ＩＤを含めて送信する。

ステップＳ１６０３では、医用画像処理サーバ１０２の通信制御部４１１は、クライアント端末１０１から送信された確定要求を受信する。そして、ステップＳ１６０４では、医用画像処理サーバ１０２の記憶部４１２は、確定要求がなされた対象の医用画像の造形が必要か否かを判定する。対象の医用画像の画像ＩＤをクライアント端末１０１から受信しているので、この画像ＩＤに対応する画像ＩＤ１２０２を依頼情報管理テーブル１２００のレコードから特定する。そして、特定したレコードの造形要否１２０５が要であれば、造形が必要であると判定する。造形が必要であると判定した場合には、ステップＳ１６０５に処理を進める。そうでない場合、つまり造形が必要でないと判定した場合には、ステップＳ１６０８に処理を進める。

ステップＳ１６０５では、医用画像処理サーバ１０２の立体造形ドライバ部４１５は、対象の医用画像の３Ｄデータを医用画像処理サーバ１０２の外部メモリ３１１から取得する。ステップＳ１６０４で特定したレコードの３Ｄデータ保存場所１２０９から取得すればよい。

ステップＳ１６０６では、医用画像処理サーバ１０２の造形ジョブ生成部４１６は、ステップＳ１６０５で取得した３Ｄデータを用いて造形ジョブを生成する。このとき、造形方法１２０４と、更に造形する素材の情報があればこれらを含めて造形ジョブを生成する。造形ジョブ生成については、従来技術を用いるものとする。

ステップＳ１６０７では、医用画像処理サーバ１０２の立体造形ドライバ部４１５は、ステップＳ１６０６で生成した造形ジョブを立体造形装置１０３に送信することで、造形指示を行う。このとき、送信先の立体造形装置１０３は、ステップＳ１６０４で特定したレコードの造形方法１２０４を実行可能な立体造形装置１０３を特定し、特定した立体造形装置１０３に送信する。立体造形装置１０３は造形ジョブを受信すると、立体造形を開始する。造形が完了すると、事業者は依頼者情報１２０７に基づいて、造形物を依頼者であるユーザに配送する。

ステップＳ１６０８では、医用画像処理サーバ１０２は、受け付けた依頼内容に応じて依頼者であるユーザに請求書を発行する。そして、ステップＳ１６０９では、医用画像処理サーバ１０２の記憶部４１２は、ステップＳ１６０４で特定したレコードのステータス１２０８を料金請求中に更新する。こうすることで造形依頼が確定される。

ステップＳ１６０９までの処理が完了したら、医用画像処理サーバ１０２からクライアント端末１０１に対して医用画像一覧画面７００の更新要求を送信する。クライアント端末１０１は、この更新要求を受信すると、図５に示す一連の処理を実行する。こうすることで医用画像一覧画面７００が最新の状態に更新される。

図１７は、依頼を取り消す一連の処理のフローチャートを示す図である。図１７のステップＳ１７０１、ステップＳ１７０２の各ステップは、クライアント端末１０１のＣＰＵ３０１によって実行される処理である。また、図１７のステップＳ１７０３乃至ステップＳ１７０５の各ステップは、医用画像処理サーバ１０２のＣＰＵ３０１によって実行される処理である。尚、図１７に示す処理内容や処理順はあくまで一例であり、これに限らない。

ステップＳ１７０１では、クライアント端末１０１の操作受付部４０５は、医用画像一覧画面７００の取消ボタン７０５に対する押下を受け付けたか否かを判定する。取消ボタン７０５に対する押下を受け付けたと判定した場合には、ステップＳ１７０２に処理を進める。取消ボタン７０５に対する押下を受け付けていないと判定した場合には、そのまま待機する。

ステップＳ１７０２では、クライアント端末１０１のウェブブラウザ部４０３は、押下を受け付けた取消ボタン７０５のレコードに埋め込まれた画像ＩＤを取得する。そして、クライアント端末１０１の通信制御部４０１は、この画像ＩＤが示す医用画像（以下、図１７においては、対象の医用画像という。）の造形依頼の取消要求を医用画像処理サーバ１０２に当該画像ＩＤを含めて送信する。

ステップＳ１７０３では、医用画像処理サーバ１０２の通信制御部４１１は、クライアント端末１０１から送信された取消要求を受信する。そして、ステップＳ１７０４では、医用画像処理サーバ１０２の記憶部４１２は、取消要求のなされた依頼の依頼結果を外部メモリ３１１から削除する。クライアント端末１０１から画像ＩＤを受信しているので、この画像ＩＤに対応する画像ＩＤ１２０２を依頼情報管理テーブル１２００のレコードから特定する。そして特定したレコードの３Ｄデータ保存場所１２０９と３Ｄ ＰＤＦデータ保存場所１２１０から依頼結果である３Ｄデータと３Ｄ ＰＤＦデータを削除する。

ステップＳ１７０５では、医用画像処理サーバ１０２の記憶部４１２ｈ、取消要求のなされた依頼情報、つまりステップＳ１７０４で特定したレコードを依頼情報管理テーブル１２００から削除する。こうすることで造形依頼が取り消される。

ステップＳ１７０５までの処理が完了したら、医用画像処理サーバ１０２からクライアント端末１０１に対して医用画像一覧画面７００の更新要求を送信する。クライアント端末１０１は、この更新要求を受信すると、図５に示す一連の処理を実行する。こうすることで医用画像一覧画面７００が最新の状態に更新される。

以上説明したように、医用画像に対する造形依頼が重複して行われることを抑止可能となる。

本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行可能にすることによっても達成される場合も本発明に含まれる。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。

なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

１００ 医用画像処理システム
１０１ クライアント端末
１０２ 医用画像処理サーバ
１０３ 立体造形装置

Claims (9)

1. 立体造形装置で立体造形を行うための依頼を受け付けることが可能な医用画像処理システムであって、
   医用画像を記憶する記憶手段と、
   前記記憶手段に記憶される医用画像を用いた造形依頼を前記医用画像ごとに受付可能な画面を生成する画面生成手段と
   を備え、
   前記画面生成手段は、前記画面生成手段で生成された画面を介して造形依頼を受け付けた医用画像に対する更なる造形依頼を受け付けることのできない前記画面を生成することを特徴とする医用画像処理システム。
2. 前記画面生成手段は、前記記憶手段に記憶される医用画像を用いた造形依頼を前記医用画像ごとに受付可能な受付部を含む前記画面を生成することを特徴とする請求項１に記載の医用画像処理システム。
3. 前記画面生成手段は、前記画面生成手段で生成された画面を介して造形依頼を受け付けた医用画像に対する更なる造形依頼を行うことのできないよう、当該医用画像に対応する前記受付部の表示を制御することを特徴とする請求項２に記載の医用画像処理システム。
4. 前記記憶手段は、更に前記医用画像の枚数を当該医用画像ごとに記憶し、
   前記画面生成手段は、前記記憶手段に記憶される医用画像の枚数が所定枚数以下または所定枚数未満である場合には、当該医用画像に対する造形依頼を受け付けることのできない前記画面を生成することを特徴とする請求項１乃至３のいずれか１項に記載の医用画像処理システム。
5. 医用画像を記憶する記憶手段を備え、立体造形装置で立体造形を行うための依頼を受け付けることが可能な医用画像処理システムの制御方法であって、
   前記医用画像処理システムの画面生成手段が、前記記憶手段に記憶される医用画像を用いた造形依頼を前記医用画像ごとに受付可能な画面を生成する画面生成ステップと
   を備え、
   前記画面生成ステップは、前記画面生成ステップで生成された画面を介して造形依頼を受け付けた医用画像に対する更なる造形依頼を受け付けることのできない前記画面を生成することを特徴とする医用画像処理システムの制御方法。
6. 医用画像を記憶する記憶手段を備え、立体造形装置で立体造形を行うための依頼を受け付けることが可能な医用画像処理システムの制御方法を実行可能なプログラムであって、
   前記医用画像処理システムを、
   前記記憶手段に記憶される医用画像を用いた造形依頼を前記医用画像ごとに受付可能な画面を生成する画面生成手段
   として機能させ、
   前記画面生成手段は、前記画面生成手段で生成された画面を介して造形依頼を受け付けた医用画像に対する更なる造形依頼を受け付けることのできない前記画面を生成することを特徴とするプログラム。
7. 立体造形装置で立体造形を行うための依頼を受け付けることが可能な医用画像処理装置であって、
   医用画像を記憶する記憶手段と、
   前記記憶手段に記憶される医用画像を用いた造形依頼を前記医用画像ごとに受付可能な画面を生成する画面生成手段と
   を備え、
   前記画面生成手段は、前記画面生成手段で生成された画面を介して造形依頼を受け付けた医用画像に対する更なる造形依頼を受け付けることのできない前記画面を生成することを特徴とする医用画像処理装置。
8. 医用画像を記憶する記憶手段を備え、立体造形装置で立体造形を行うための依頼を受け付けることが可能な医用画像処理装置の制御方法であって、
   前記医用画像処理装置の画面生成手段が、前記記憶手段に記憶される医用画像を用いた造形依頼を前記医用画像ごとに受付可能な画面を生成する画面生成ステップと
   を備え、
   前記画面生成ステップは、前記画面生成ステップで生成された画面を介して造形依頼を受け付けた医用画像に対する更なる造形依頼を受け付けることのできない前記画面を生成することを特徴とする医用画像処理装置の制御方法。
9. 医用画像を記憶する記憶手段を備え、立体造形装置で立体造形を行うための依頼を受け付けることが可能な医用画像処理装置の制御方法を実行可能なプログラムであって、
   前記医用画像処理装置を、
   前記記憶手段に記憶される医用画像を用いた造形依頼を前記医用画像ごとに受付可能な画面を生成する画面生成手段
   として機能させ、
   前記画面生成手段は、前記画面生成手段で生成された画面を介して造形依頼を受け付けた医用画像に対する更なる造形依頼を受け付けることのできない前記画面を生成することを特徴とするプログラム。
   
   

Images