特許 6289064 医療情報システム及び推奨アプリケーションの検索方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6289064

(24)【登録日】2018年2月16日

(45)【発行日】2018年3月7日

(54)【発明の名称】医療情報システム及び推奨アプリケーションの検索方法

(51)【国際特許分類】

   G06Q 50/22 20180101AFI20180226BHJP

   A61B 5/00 20060101ALI20180226BHJP

【ＦＩ】

   G06Q50/22

   A61B5/00 G

【請求項の数】8

【全頁数】28

(21)【出願番号】特願2013-254314(P2013-254314)

(22)【出願日】2013年12月9日

(65)【公開番号】特開2015-114710(P2015-114710A)

(43)【公開日】2015年6月22日

【審査請求日】2016年11月2日

(73)【特許権者】

【識別番号】594164542

【氏名又は名称】キヤノンメディカルシステムズ株式会社

(74)【代理人】

【識別番号】110000866

【氏名又は名称】特許業務法人三澤特許事務所

(72)【発明者】

【氏名】朴 龍勲

(72)【発明者】

【氏名】坂上 弘祐

(72)【発明者】

【氏名】長島 正晃

(72)【発明者】

【氏名】宇都宮 和樹

【審査官】 貝塚 涼

(56)【参考文献】

【文献】 特開２０１１−０１１０６９（ＪＰ，Ａ）

【文献】 特開２０１０−１４６３２３（ＪＰ，Ａ）

【文献】 特開２００１−１０４２５３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

Ａ６１Ｂ ５／００

(57)【特許請求の範囲】

【請求項1】

利用者が使用するクライアント端末と、
通信ネットワークを介して前記クライアント端末と接続し、前記利用者が医療画像診断装置によって取得された患者の内部情報を示す医療画像の読影を行う際に利用するアプリケーションが特定の処理に対して複数存在する場合に、前記利用者に関する情報、並びに、前記利用者の属性を一部に備える類似利用者に関する情報及び、前記アプリケーションの検索に当たって入力される検索条件を基に前記利用者に対して適切なアプリケーションを推奨するテナント型医療情報システムと、
を備えることを特徴とする医療情報システム。

【請求項2】

前記テナント型医療情報システムは、前記利用者に対して適切なアプリケーションを推奨するに当たって、読影の対象となる前記医療画像に関する前記医療画像診断装置へのオーダ情報も検索の条件として用いることを特徴とする請求項１に記載の医療情報システム。

【請求項3】

前記テナント型医療情報システムは、
前記利用者が前記医療画像の読影を行う際に利用するアプリケーションを検索する検索装置と、
前記利用者が検索した前記利用者に対して推奨する前記アプリケーションに関する情報を統合して前記クライアント端末に表示させる統合ビューアと、
を備えることを特徴とする請求項１または請求項２に記載の医療情報システム。

【請求項4】

前記検索装置は、
前記利用者による検索処理の開始を監視する条件監視部と、
前記利用者に関する情報を基に、利用者情報記憶部に記憶されているアプリケーションの利用者に関する情報の中から前記類似利用者に関する情報を抽出する利用者情報取得部と、
前記アプリケーションの検索に当たって入力される前記検索条件を基に、推奨の候補となるアプリケーションに関する情報を起動アプリ記憶部から取得する起動アプリ取得部と、
前記起動アプリ取得部によって取得されたアプリケーションに関する情報を基に、推奨の対象となるアプリケーションを絞り込むアプリ絞込部と、
前記利用者情報取得部及び、前記アプリ絞込部からの情報に基づいて、アプリケーションの利用頻度をアプリ利用頻度記憶部から取得するアプリ利用頻度取得部と、
前記類似利用者に関する情報と前記アプリケーションの利用頻度を基に前記利用者にとって適切なアプリケーションを判定する好適アプリ判定部と、
を備えることを特徴とする請求項３に記載の医療情報システム。

【請求項5】

前記検索装置は、
読影の対象となる前記医療画像に関する前記医療画像診断装置へのオーダ情報を取得するオーダ情報取得部と、
前記オーダ情報取得部で取得したオーダ情報を基にその内容を解析するオーダ情報解析部と、
を備えることを特徴とする請求項３または請求項４に記載の医療情報システム。

【請求項6】

医療画像診断装置によって取得された患者の内部情報を示す医療画像の読影を行う際にアプリケーションを利用する利用者によってクライアント端末を用いて入力された前記利用者の情報を受信するステップと、
入力された利用者情報を基に、利用者情報取得部が前記利用者の属性を一部に備える類似利用者に関する情報を取得するステップと、
前記アプリケーションの推奨を受ける際、前記アプリケーションの検索に当たって前記利用者によって入力される検索条件に関する情報を基に、起動アプリ取得部がアプリケーションを抽出するステップと、
前記抽出されたアプリの情報を基に、アプリ絞込部が推奨の候補となるアプリケーションを絞り込むステップと、
前記利用者情報、並びに前記類似利用者に関する情報、及び、絞り込まれた前記アプリケーションに関する情報から、アプリ利用頻度取得部が該当するアプリケーションの利用頻度を把握するステップと、
これまで収集された情報を基に、好適アプリ判定部が前記利用者に対して推奨するアプリケーションを判定するステップと、
を備えることを特徴とする推奨アプリケーションの検索方法。

【請求項7】

前記利用者に対して推奨するアプリケーションを判定する前に、オーダ情報取得部が、前記アプリケーションを利用して読影を行う、前記医療画像に関するオーダ情報を取得するステップを備えることを特徴とする請求項６に記載の推奨アプリケーションの検索方法。

【請求項8】

医療画像診断装置によって取得された患者の内部情報を示す医療画像の読影を行う際に利用するアプリケーションの推奨を得るに当たって、前記医療画像に関するオーダ情報を取得するステップと、
前記オーダ情報を解析して、利用者が好適に利用することができる前記アプリケーションを判定するステップと、
を備えることを特徴とする推奨アプリケーションの検索方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施の形態は、医療情報システム及び推奨アプリケーションの検索方法に関する。

【背景技術】

【0002】

近年、技術の進展に伴って、医療機関内にも各種電子機器を利用した医療画像診断装置やシステムが導入されている。医療画像診断装置は、被検体内部の情報を収集し、この収集された情報に基づいて被検体内部を画像化して医療画像を生成する装置であり、例えば、Ｘ線ＣＴ装置（computed tomography：コンピュータ断層撮影装置）や、磁気共鳴診断装置（ＭＲＩ：magnetic resonance imaging）等が該当する。

【0003】

医療機関内にこのような環境が構築される一方、医療機関で勤務する医師の側から見ると、異動が多かったり、或いは、派遣されて勤務する医師も多いという実態がある。このような医師は、診察や読影を行う際には、不慣れな利用環境の下で端末やアプリケーションを使用することになる。

【0004】

そこでこのような実態に鑑み、例えば、医師等のユーザが自分にとって有用な臨床アプリケーションを容易に見つけだすことができ、かつ所定のネットワークに接続された端末であれば各々のユーザ毎にカスタマイズされた利用環境及び臨床アプリケーションを利用することが可能なシステムが提案されている（特許文献１参照）。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１０−１５７０１９号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかしながら、上記特許文献１において開示されている発明では、次の点について配慮がなされていない。

【0007】

すなわち、これら医療機関に構築されるシステムに関しては、導入する医療機関の規模にもよるが、システムを開発する会社それぞれに得意な分野があることから医療機関内の全てのシステムが１社のシステムで運用される、ということは少ないと考えられる。また、医療情報を生成するアプリケーションにしても、Ｘ線画像の解析に強いアプリケーションやＸ線ＣＴ装置で得られたボリュームデータから３Ｄ画像を生成するに適したアプリケーション等々、様々なアプリケーションが存在し、導入される。

【0008】

従って１つの医療機関内に、例えば、複数のシステム、複数のアプリケーションが導入された場合、それぞれのシステム、アプリケーションが区々となってしまうことから、ユーザである医師、或いは、技師の使い勝手は決して良くないと考えられる。不慣れな利用環境の下で端末やアプリケーションを使用する場合にはなおさらである。

【0009】

確かに一旦利用するアプリケーションが選択されてしまえば問題はないかもしれないが、アプリケーションを選択する場面においては、当該アプリケーションを利用する者の好み、嗜好等もあり、或いは、アプリケーションの内容等が高度でありユーザの実力によって使いこなせない、といった場合もあり得、なかなか適切なアプリケーションの選択を行えないこともある。

【0010】

また、同じ部位に関する読影であっても、読影を行う利用者が属する所属科ごとに利用するアプリケーションが異なることも考えられる。さらには、特に読影にあまり慣れていない利用者や、新規に利用することが可能となったアプリケーションをリリース後時間を置かずに利用する場合には、読影に適したアプリケーションを検索することは一層困難であることが多い。

【0011】

本発明は上記課題を解決するためになされたものであり、本発明の目的は、利用者が読影のためにアプリケーションを利用する際、アプリケーションの検索を行うに当たって、アプリケーションに関する利用条件のみならず利用者の属性をも考慮し当該利用者に対して最適なアプリケーションの提供を行うことが可能な医療情報システム及び推奨アプリケーションの検索方法を提供することにある。

【課題を解決するための手段】

【0012】

請求項１に記載の発明の特徴は、医療情報システムにおいて、利用者が使用するクライアント端末と、通信ネットワークを介してクライアント端末と接続し、利用者が医療画像診断装置によって取得された患者の内部情報を示す医療画像の読影を行う際に利用するアプリケーションが特定の処理に対して複数存在する場合に、利用者に関する情報、並びに、利用者の属性を一部に備える類似利用者に関する情報及び、アプリケーションの検索に当たって入力される検索条件を基に利用者に対して適切なアプリケーションを推奨するテナント型医療情報システムとを備える。

【0013】

請求項６に記載の発明の特徴は、推奨アプリケーションの検索方法において、医療画像診断装置によって取得された患者の内部情報を示す医療画像の読影を行う際にアプリケーションを利用する利用者によってクライアント端末を用いて入力された利用者の情報を受信するステップと、入力された利用者情報を基に、利用者情報取得部が利用者の属性を一部に備える類似利用者に関する情報を取得するステップと、アプリケーションの推奨を受ける際、アプリケーションの検索に当たって利用者によって入力される検索条件に関する情報を基に、起動アプリ取得部がアプリケーションを抽出するステップと、抽出されたアプリの情報を基に、アプリ絞込部が推奨の候補となるアプリケーションを絞り込むステップと、利用者情報、並びに類似利用者に関する情報、及び、絞り込まれた前記アプリケーションに関する情報から、アプリ利用頻度取得部が該当するアプリケーションの利用頻度を把握するステップと、これまで収集された情報を基に、好適アプリ判定部が利用者に対して推奨するアプリケーションを判定するステップとを備える。

【0014】

請求項８に記載の発明の特徴は、推奨アプリケーションの検索方法において、医療画像診断装置によって取得された患者の内部情報を示す医療画像の読影を行う際に利用するアプリケーションの推奨を得るに当たって、医療画像に関するオーダ情報を取得するステップと、オーダ情報を解析して、利用者が好適に利用することができるアプリケーションを判定するステップとを備える。

【図面の簡単な説明】

【0015】

【図1】本発明の実施の形態における医療情報システムの全体構成を示すブロック図である。

【図2】本発明の実施の形態におけるテナント型医療情報システムの内部構成を示すブロック図である。

【図3】本発明の実施の形態における統合ビューアの内部構成を示すブロック図である。

【図4】本発明の第１の実施の形態における検索装置及び検索データベースの内部構成を示すブロック図である。

【図5】本発明の実施の形態におけるアプリケーションの検索、推奨の流れを示すフローチャートである。

【図6】本発明の実施の形態におけるアプリケーションの検索、推奨の流れを示すフローチャートである。

【図7】本発明の実施の形態における利用者情報記憶部に格納される利用者に関する情報のテーブルの一例を示す説明図である。

【図8】本発明の実施の形態における推奨アプリケーションの検索を行う際に利用者がアプリケーションの検索条件を入力する画面の一例を示す画面例である。

【図9】本発明の実施の形態における検索データベース内の起動アプリ記憶部に格納されるアプリケーションに関する情報のテーブルの一例を示す説明図である。

【図10】本発明の実施の形態における検索データベース内のアプリ利用頻度記憶部に格納されるそれぞれのアプリケーションの利用頻度に関する情報のテーブルの一例を示す説明図である。

【図11】本発明の実施の形態におけるオーダ情報記憶部に格納される医療画像の取得処理に関するオーダ情報のテーブルの一例を示す説明図である。

【図12】本発明の実施の形態における推奨アプリケーションの検索の流れを説明するための説明図である。

【図13】本発明の実施の形態における推奨アプリケーションの検索の流れを説明するための説明図である。

【図14】本発明の実施の形態における推奨アプリケーションの検索の流れを説明するための説明図である。

【図15】本発明の実施の形態における推奨アプリケーションの検索の流れを説明するための説明図である。

【図16】本発明の実施の形態における推奨アプリケーションの検索を行った結果を利用者に提示する画面の一例を示す画面例である。

【図17】本発明の第２の実施の形態における検索装置及び検索データベースの内部構成を示すブロック図である。

【図18】本発明の第２の実施の形態におけるアプリケーションの好適条件を格納するテーブルの一例を示す説明図である。

【図19】本発明の第３の実施の形態における医療情報システムの全体構成を示すブロック図である。

【図20】本発明の第３の実施の形態における地域データセンタの内部構成を示すブロック図である。

【発明を実施するための形態】

【0016】

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

【0017】

（第１の実施の形態）
［医療情報システムの全体構成］
図１は、本発明の実施の形態における医療情報システムＳの全体構成を示すブロック図である。医療情報システムＳは、利用者が使用するクライアント端末１と、システム運営者が設置し、通信ネットワークＮを介してクライアント端末１から送信される利用者からの読影を行うに当たって利用するアプリケーションの検索要求に基づいて最適なアプリケーションの推奨を行うテナント型医療情報システム２と、テナント型医療情報システム２と通信ネットワークＮを介して接続され、アプリ提供者によって提供されるアプリケーションを備えるアプリケーションサーバ３（以下、明細書における表記及び図面の表記として「アプリサーバ３」と表わす）と、を備える。

【0018】

さらにこの実施の形態における医療情報システムＳには、通信ネットワークＮを介して、医療画像診断装置４と、管理サーバ５とが併せて接続されている。

【0019】

クライアント端末１は、利用者である、医師、或いは、技師によって使用される情報端末である。このクライアント端末１としては、例えば、ＰＣ（パーソナルコンピュータ）や、ＷＳ（診療ワークステーション）等が考えられる。また、クライアント端末１が携帯可能であることを否定するものではない。

【0020】

さらに、クライアント端末１は、例えば、アプリケーションの検索条件を入力といった、少なくとも利用者の操作を受け付ける入力部と、読影等の各種処理を行うＣＰＵを備える処理部と、テナント型医療情報システム２によって検索条件等に基づいて検索された当該利用者が読影を行うに当たって利用する推奨アプリケーションを表示する表示部を備えている。

【0021】

テナント型医療情報システム２は、利用者が医療画像の読影を行うに当たって利用するアプリケーションを検索、推奨する機能を果たす。また、検索の結果である推奨アプリケーションに関する様々な情報をクライアント端末１の表示部に表示させる機能も果たす。ここで「医療画像」とは、利用者が読影の対象とする画像であり、最終的に例えば、検査レポートに掲載されたり、診察に役立てたりするための画像である。

【0022】

テナント型医療情報システム２は、システム運営者が設けるもので、利用者は当該システムを利用することで、必要とする最適なアプリケーションを効率良く検索、利用することができる。すなわち、テナント型医療情報システム２には利用することが可能な単数、または複数のアプリケーションが接続されており、利用者はテナント型医療情報システム２を介してこれらのアプリケーションを検索、利用、或いは必要に応じて入手し、必要な医療情報を取得することができる。従って、利用者が医療情報の取得に当たり、個別にアプリケーションを探し出して利用するといった手間を省くことができる。

【0023】

なお、ここで「医療情報」とは、例えば、カルテ等の文字情報、血液検査等の数値データや波形データ、Ｘ線ＣＴ装置のような医療画像診断装置が取得（撮影）する医療画像に関する情報、或いは検査レポート等の文字・画像混在情報等、を含む概念である。

【0024】

また、利用者自ら医療情報の収集を行う場合には、多くの場合、どうしても自らの思考（嗜好）に合った特定のアプリケーションを利用しがちであり、特に、新規なアプリケーションについては利用されにくいのが現状である。また、例えば、読影に不慣れな利用者にとっては最適なアプリケーションの選択、利用は困難な場合も多い。

【0025】

そこで、本発明の実施の形態におけるテナント型医療情報システム２を利用することで、後述するように、利用者の属性に合わせて利用者に適したアプリケーションを検索、推奨してくれる。そのため、利用者は推奨されたアプリケーションを利用することで、医療画像の読影の結果、所望の医療情報を取得することができる。

【0026】

なお、システム運営者が設けるテナント型医療情報システム２は、このシステム運営者が「大家」という位置付けにあり、一方、検索、推奨されて利用者に利用されるアプリケーションを提供するアプリ提供者は、いわば「店子」の位置付けとなる。従って、大家（システム運営者）が設けるテナント型医療情報システム２内には店子（アプリ提供者）がアプリケーションを提供しており、この点を示して「テナント」と表わしている。利用者は自分が要求する医療画像を取得するに当たって、テナントであるアプリ提供者が提供する読影の目的、実力等に合った各種アプリケーションを利用する。

【0027】

図２は、本発明の実施の形態におけるテナント型医療情報システム２の内部構成を示すブロック図である。テナント型医療情報システム２は、本体部２Ａと画像管理部２Ｂの大きく２つの部分に分かれている。本体部２Ａは、アプリケーションの検索、推奨、利用者による検査レポートの作成等、利用者からの要求を受け付けて利用者に必要な医療情報を生成して戻す機能を備えている。一方、画像管理部２Ｂは、医療画像診断装置４が取得した医療画像を保管、管理する。

【0028】

本体部２Ａは、統合ビューア２１と、検索装置２２と、検索データベース２３と、シンクライアントマネージャ２４と、アプリケーション２５（アプリケーションＡ）と、課金エンジン２６と、課金データベース２７とから構成されている。また、画像管理部２Ｂは、画像情報マネージャ２８と、画像レポートデータベース２９とから構成されている。

【0029】

なお、本体部２Ａの各部の内部構成、機能や働きについては、以下、利用者に対して最適なアプリケーションを検索、推奨する流れに沿って別途説明する。

【0030】

画像管理部２Ｂを構成する画像情報マネージャ２８は、医療画像診断装置４によって取得される医療画像に関する情報を管理する。一方、画像レポートデータベース２９は、画像情報マネージャ２８を介して医療画像診断装置４から送られてきた医療画像を記憶する。また、アプリサーバ３に記憶されているアプリケーションを利用して加工、生成される医療画像についても記憶することとしても良い。

【0031】

なお、テナント型医療情報システム２の設置場所については、図１に示す医療情報システムＳにおいて特に示されていない。従って、テナント型医療情報システム２は、医療機関内に設けられていても良く、或いは、クラウド・コンピューティング技術を用いて医療機関外に設けられていても良い。さらに、各医療機関ごとに設けられていても、或いは、複数の医療機関で共有していても良い。

【0032】

アプリサーバ３は、アプリ提供者が提供するアプリケーションを記憶している。テナント型医療情報システム２（検索装置２２）によって利用者の要求に基づいて検索、推奨されるアプリケーションは、いずれかのアプリサーバ３内にて提供されている。利用者が読影に当たって推奨されたアプリケーションを利用する場合には、例えば、当該アプリケーションを備えるアプリサーバ３に対して、医療画像の加工、生成が依頼される。アプリサーバ３では要求に応じて医療画像を加工、生成し、改めてテナント型医療情報システム２に送信する。アプリサーバ３から生成された医療画像を受信したテナント型医療情報システム２では、この医療画像と検査レポートとを当該要求を出した利用者のクライアント端末１にまとめて（統合して）表示させる。

【0033】

なお、アプリサーバ３は、格納するアプリケーションごとに設けられていても良く、或いは、アプリ提供者ごとに設けられていても良い。後者の場合、１つのアプリサーバ３内に当該アプリ提供者が提供するアプリケーションが単数、或いは、複数含まれて（記憶されて）いる。

【0034】

また、以下の説明、或いは、各図面において、適宜「アプリ」と表わされる場合があるが、この「アプリ」とは「アプリケーション」の略である。

【0035】

医療画像診断装置４は、被検体を撮影してその内部情報を取得する医療画像取得（撮影）装置である。医療画像診断装置４としては、例えば、上述したようにＸ線ＣＴ装置や磁気共鳴診断装置等が該当する。医療画像診断装置４において取得された各撮影データは、例えば、テナント型医療情報システム２に送信されて、画像管理部に格納（記憶）される。また、図１には示していないが、例えば、通信ネットワークＮに接続されている画像サーバ等に記憶されていても良い。

【0036】

管理サーバ５は、例えば、医療機関内に構築されている、例えば、病院情報管理システム（ＨＩＳ：Hospital Information System）、放射線部門情報管理システム（ＲＩＳ：Radiological Information System）、医用画像管理システム（ＰＡＣＳ：Picture Archiving Communication System）等が該当する。

【0037】

本発明の実施の形態において当該管理サーバ５内には、特に以下に説明する実施の形態において必要な利用者情報記憶部５ａとオーダ情報記憶部５ｂのみを示している。従って、このほかの機能を果たす各部が含まれているのはもちろんである。

【0038】

利用者情報記憶部５ａは、当該医療情報システムＳを利用して読影や診察等を行う医師、或いは、技師に関する、例えば、ＩＤや所属科といった属性に関する情報が記憶されている。オーダ情報記憶部５ｂは、医療画像診断装置４において被検体の内部情報を医療画像として取得する際の要求（オーダ）情報である。従って、医療画像診断装置４は、当該オーダ情報に基づいて医療画像を取得することになる。なお、管理サーバ５に入力された各種情報は、併せてテナント型医療情報システム２にも送られ、利用者からの要求に対処する際に用いられる。

【0039】

利用者情報記憶部５ａやオーダ情報記憶部５ｂは、この発明の実施の形態においては、管理サーバ５内に設けられているように示されているが、例えば、これらはそれぞれ独立して通信ネットワークＮに接続されていても、或いは、テナント型医療情報システム２内に設けられていても良く、これらの情報の記憶場所はどこであっても良い。

【0040】

なお、図１に示す医療情報システムＳでは、通信ネットワークＮに２つのクライアント端末１Ａと１Ｂ（以下、適宜これら複数のクライアント端末をまとめて「クライアント端末１」と表わす。）、アプリサーバ３Ａ及び３Ｂ（以下、適宜これらのアプリサーバをまとめて「アプリサーバ３」と表わす。）が接続されているが、通信ネットワークＮに接続されるクライアント端末１、或いは、アプリサーバ３の数は単数、或いは複数のいずれでも良く、その数は任意である。 また、医療画像診断装置４は、図１では１つのみ通信ネットワークＮに接続されているが、この医療画像診断装置４の数についても任意である。

【0041】

通信ネットワークＮは、クライアント端末１、テナント型医療情報システム２、アプリサーバ３、医療画像診断装置４、及び管理サーバ５をそれぞれつなぎ、互いの間で、例えば医療情報のやりとりを可能とする。通信ネットワークＮの例としては、ＬＡＮ（Local Area Network）やインターネット等の通信ネットワークを挙げることができる。また、この通信ネットワークＮで使用される通信規格は、ＤＩＣＯＭ（Digital Imaging and Communication in Medicine）等、いずれの規格であっても良い。

【0042】

［テナント型医療情報システム（本体部）の構成］
上述したように、テナント型医療情報システム２の本体部２Ａは、統合ビューア２１と、検索装置２２と、検索データベース２３と、シンクライアントマネージャ２４と、アプリケーション２５（アプリケーションＡ）と、課金エンジン２６と、課金データベース２７とから構成されている。

【0043】

統合ビューア２１は、利用者から医療画像を読影する際に利用するアプリケーションの検索要求が出された場合に、検索装置２２を用いて利用者に対して推奨可能なアプリケーションを検索する。検索されたアプリケーションは、利用者が使用するクライアント端末１の表示部にその情報を出力するとともに、利用者からの新たな要求に基づいて、後述するように、例えば、「読影例」や「利用ガイド」を表示させる。

【0044】

図３は、本発明の実施の形態における統合ビューア２１の内部構成を示すブロック図である。統合ビューア２１は、受信部２１ａと、情報解析部２１ｂと、情報収集部２１ｃと、情報統合部２１ｄと、送信部２１ｅとから構成される。

【0045】

情報解析部２１ｂは、例えば、検査レポートが作成される場合に、利用者から出される要求を解析する。また、情報収集部２１ｃは、情報解析部２１ｂにおいて解析された情報に基づいて必要な情報を、例えば、管理サーバ５から収集する。情報統合部２１ｄは、例えば、利用者に推奨するアプリケーションに関して、アプリケーションに関する基本的な情報と、例えば当該アプリケーションを利用して得られた医療情報とを統合して利用者が使用するクライアント端末１の表示部に表示させる。

【0046】

なお、ここでは本発明の実施の形態を説明する上で必要な構成のみを示しており、テナント型医療情報システム２として機能するに必要とされる構成については当然備えられている。

【0047】

さらに、統合ビューア２１自体は医療情報を統合的に利用者に提示するアプリケーションである。しかし、以下の説明に係る実施の形態においては、テナント型医療情報システム２に当該アプリケーションが読み込まれることによって統合ビューア２１が実装されることを前提とする。

【0048】

統合ビューアは、Ｗｅｂアプリケーション、ファットクライアントアプリケーション、或いは、シンクライアントアプリケーション等、いずれの実装形態を採用しても良い。一方、統合ビューアは医療情報を統合的に利用者に提示する回路としてテナント型医療情報システム２に設けられていても良い。

【0049】

検索装置２２は、利用者が医療画像の読影を行うに当たって適切なアプリケーションを推奨してもらう場合に、該当するアプリケーションを検索する装置である。図４は、本発明の第１の実施の形態における検索装置２２及び検索データベース２３の内部構成を示すブロック図である。

【0050】

検索装置２２は、送受信部２２ａと、条件監視部２２ｂと、利用者情報取得部２２ｃと、起動アプリ取得部２２ｄと、アプリ絞込部２２ｅと、アプリ利用頻度取得部２２ｆと、オーダ情報取得部２２ｇと、オーダ情報解析部２２ｈと、好適アプリ判定部２２ｉと、を備える。また、検索データベース２３内には、起動アプリ記憶部２３ａと、アプリ利用頻度記憶部２３ｂとが設けられている。

【0051】

なお、検索装置２２、及び、検索データベース２３の内部に設けられている各部の詳細な働きについては、以下、推奨アプリケーションの検索の流れを説明する際に併せて説明をする。また、起動アプリ記憶部２３ａとアプリ利用頻度記憶部２３ｂが検索データベース２３に設けられているが、これらについては、例えば、管理サーバ５、或いは、それぞれが独立して通信ネットワークＮに接続されるように構成されていても良い。

【0052】

シンクライアントマネージャ２４は、図１に示すアプリサーバ３に通信ネットワークＮを介して接続されている。例えば、利用者に推奨するアプリケーションを入手して利用者が利用することができるようにテナント型医療情報システム２に取り込む。また利用者が検査レポートを作成する場合には、同じように必要とする医療画像の加工、生成を行うためのアプリケーションをテナント型医療情報システム２に取り込む。

【0053】

アプリケーション２５（アプリケーションＡ）は、システム運営者が提供するアプリケーションの１つである。つまり、アプリ提供者がアプリケーションを提供するのと同じように、テナント型医療情報システム２を運営するシステム運営者が自ら提供するアプリケーションである。システム運営者が提供するアプリケーションであることから、アプリケーション２５（アプリケーションＡ）は、例えば、クライアント端末１に表示される基本的な画面設定に関するアプリケーション、或いは、画像管理部２Ｂに記憶、管理されている医療画像の処理を行うアプリケーションである。

【0054】

なお、図２では、１つのアプリケーション２５（アプリケーションＡ）が統合ビューア２１に接続されているが、このようなアプリケーションがどのくらいの数、統合ビューア２１に接続されている（テナント型医療情報システム２内に設けられている）かは自由である。

【0055】

テナント型医療情報システム２には、アプリサーバ３が接続されている。上述したように、いくつのアプリサーバ３がテナント型医療情報システム２に接続されるかは、医療情報システムＳにアプリケーションを提供するアプリ提供者の数、或いは、提供されるアプリケーションの数によって増減する。図２においては、アプリケーションＢを提供するアプリサーバ３ＡとアプリケーションＣを提供するアプリサーバ３Ｂとがテナント型医療情報システム２に接続されている。

【0056】

課金エンジン２６は、利用者がテナント型医療情報システム２、或いは、アプリサーバ３に記憶されているアプリケーションを利用した際の利用料金等を算出する。課金エンジン２６に接続されている課金データベース２７は、利用者の利用料金等の算出を行う際に基礎となる料金に関する情報が記憶されている。

【0057】

［利用者にアプリケーションを推奨する流れ］
図５、図６は、本発明の実施の形態におけるアプリケーションの検索、推奨の流れを示すフローチャートである。すなわち、以下に説明する実施の形態においては、医師等（利用者）が医療画像の読影を行う際に利用するアプリケーションを如何に簡易かつ適切に推奨されるか、その流れを説明するものである。

【0058】

利用者は医療画像の読影を行う際、クライアント端末１を使用する。ここで読影の対象となる医療画像が、例えば、利用者にとってあまり経験のない部位に関する画像であったり、或いは、利用者が読影自体に習熟していない場合、読影を行うに必要な医療画像を得るために用いるアプリケーションを選択することは以外と困難を伴うことも多い。また、読影のベテランの場合は、読影に当たって通常利用するアプリケーションの選択に迷うことはないと思われるが、例えば新しいアプリケーションがリリースされた場合に、普段利用しているアプリケーション以外に当該新たなアプリケーションの推奨を受けることはアプリケーション利用の幅が広がる点からも有用であると考えられる。新たなアプリケーションがリリースされた場合に利用者に推奨されれば、それだけその後の利用につながることになり、アプリケーションをリリースしたアプリ提供者にとっても有用である。従って、読影が開始される際に利用者に適したアプリケーションの推奨を行うことは非常にメリットの大きなことである。

【0059】

実際に利用者が読影を行う際にアプリケーションの推奨を受けるには、以下の流れに従うことになる。まず、利用者は読影に利用するアプリケーションの推奨を受けるべく、推奨されるアプリケーション（以下、このようなアプリケーションを「推奨アプリケーション」と表わす）の検索を行う。そのために利用者はクライアント端末１の入力部を使用して推奨アプリケーションの検索画面を開く。検索画面が開かれた情報は、通信ネットワークＮを介して当該検索を行うテナント型医療情報システム２にもたらされ、統合ビューア２１（情報解析部２１ｂ）が検索画面が開かれたことを検知する（ＳＴ１）。

【0060】

検索画面が開かれると、例えば、検索を行うアプリケーションが起動し、利用者は当該検索画面においてログインする。ログインに必要な情報は、利用者を一義的に特定することが可能な、例えば、利用者のＩＤといったログイン情報が入力される。

【0061】

このログイン情報は、統合ビューア２１を介して検索装置２２に送信される。当該ログイン情報を受信した検索装置２２の条件監視部２２ｂは、さらに利用者情報取得部２２ｃにログイン情報を送る。利用者情報取得部２２ｃは、当該ログイン情報を基に利用者に関する情報（以下、このような情報を「利用者情報」と表わす）を取得する（ＳＴ２）。

【0062】

具体的には、利用者情報取得部２２ｃは、この実施の形態においては管理サーバ５内に設けられている利用者情報記憶部５ａにアクセスすることで利用者情報を取得する。図７は、本発明の実施の形態における利用者情報記憶部５ａに格納される利用者に関する情報のテーブルの一例を示す説明図である。

【0063】

当該テーブルには、例えば、図７のテーブルに示されているように、「利用者ＩＤ」、「利用者名」、「所属科」、及び「権限」が記憶されている。もちろん、これらの項目はこれら４つの項目に制限されるわけではなく、任意に項目を設定することができる。また利用者情報記憶部５ａに記憶される利用者に関する情報については、例えば、テナント型医療情報システム２内に新たに利用者に関する情報を適宜利用者情報記憶部５ａに記憶させる機能を持つ、例えば、利用者情報登録部を設けることで対応しても良い。さらには、各医療機関内に既に構築されている各種システム内に登録されている情報を利用することとしても良い。

【0064】

例えば、利用者である医師Ａが読影に当たって利用するアプリケーションの推奨を受けようとしている場合、ログインに使用した「利用者ＩＤ」は「１００」である。この利用者ＩＤに紐付けられている通り、医師Ａは、「放射線科」に所属しており、「技師」との権限を有している。一方、「利用者ＩＤ」が「４００」であった場合、推奨アプリケーションの検索を行うのは、「放射線科」の「医師Ｄ」であって、権限は「技師長」である。

【0065】

利用者情報取得部２２ｃは、さらに、推奨アプリケーションの検索を行う利用者に似ている利用者（以下、このような利用者を「類似利用者」と表わす）の情報についても取得する（ＳＴ３）。この類似利用者とは、推奨アプリケーションの検索を行う利用者とその属性が似ている者のことである。例えば、推奨アプリケーションの検索を行う利用者が医師Ａである場合、「類似利用者」は、同じ放射線科に属し技師という権限を備える「医師Ｂ」と「医師Ｃ」である。

【0066】

以下に説明する実施の形態においては、推奨アプリケーションの検索に当たって、この利用者情報、並びに類似利用者に関する情報（以下、このような情報を「類似利用者情報」と表わす）を利用する。利用者が自ら設定する推奨して欲しいアプリケーションの条件の他に、自身と似た属性を持つ者がどのようなアプリケーションを利用しているかを考慮することで、利用者により適したアプリケーションを推奨することができると考えられるからである。

【0067】

利用者によってログインされると、推奨して欲しいアプリケーションを検索するための条件を入力するための画面がクライアント端末１の表示部に表示される。

【0068】

図８は、本発明の実施の形態における推奨アプリケーションの検索を行う際に利用者がアプリケーションの検索条件を入力する画面の一例を示す画面例である。なお、図８に示す画面例はあくまでも一例であり、画面のレイアウトや利用者が入力しなければならない条件の設定等については任意に設定することが可能である。

【0069】

当該画面例においては、最上部に「読影アプリケーション検索」という表題が示されており、併せて利用者が誰であるかが示されている。ここでは読影の際に利用するアプリケーションの推奨を受けるべく検索を行う者の利用者ＩＤが「１００」であること（図５を参照すると、当該利用者は「医師Ａ」である）がわかる。

【0070】

この実施の形態においては、入力条件として「予算」と「検査種別」が設定されている。「予算」とは、自らが利用するアプリケーションの価格としてどのくらいの価格のアプリケーションであれば利用できるかを示すものである。最近では医療機関内における予算管理も厳しくなってきており、どのような価格のアプリケーションであっても自由に利用が可能である、ということではないことも多い。従って、利用者が所属する科、グループ、或いは、医療機関全体といった、予算管理が行われている単位で当該アプリケーションに使える予算を設定する。

【0071】

なお、「予算」を設定する際には、推奨されたアプリケーションを回数を決めて利用する際の利用額とするのか、或いは、アプリケーション自体を買い取る際の買取額とするのかは自由である。図８の画面例では、プルダウンタブを用いて予算額の範囲を決める領域と金額を入力する領域とが設けられているが、さらにこの「利用額」「買取額」の別を選択できるようにしても良い。

【0072】

一方、「検査種別」とは、読影の対象となる医療画像がいずれの医療画像診断装置によって得られたものであるかを選択する項目である。医療画像診断装置によって得られる医療画像は異なり、しかも得られた医療画像をどのように解析、加工して読影するかも異なり、それぞれに適したアプリケーションが存在する。従って、読影のために利用する適切なアプリケーションを推奨するには必須の条件といえる。ここではプルダウンメニューに様々設定されているであろう医療画像診断装置の中から「ＣＴ装置」が選択されている。

【0073】

以上の通り図８に示されている入力画面例では、「予算」は「１１，０００円以下」、「検査種別」は「ＣＴ」と示されている。従って、当該検索条件からすれば、入力した利用者（医師Ａ）は、ＣＴ装置で得られた医療画像を読影する際に利用することのできる予算１１，０００円以下のアプリケーションの検索を行いたい（そのようなアプリケーションの推奨を受けたい）ことが理解できる。

【0074】

例えば図８に示すような入力画面を介して検索条件が入力されると、統合ビューア２１から検索装置２２へと送信される。検索装置２２の条件監視部２２ｂは、検索条件が入力されたことを検知するとともに（ＳＴ４）、全ての条件が入力されたか否かを監視する（ＳＴ５）。検索条件は、利用者に対して当該利用者が読影を行う際に最適なアプリケーションを推奨するために必要な条件であることから、ここでは、条件監視部２２ｂによって設定された全ての条件が入力されたか否か判断され、全ての条件が入力されない限り検索処理を行わず待機することとしている（ＳＴ５のＮＯ）。

【0075】

条件監視部２２ｂによる全ての検索条件が入力されたか否かの判断は、例えば当該実施の形態における入力画面例（図８参照）では、画面例右下に「検索ボタン」が設けられているので、この検索ボタンが利用者によって押されたか否か（条件監視部２２ｂがその信号を受信したか否か）を基に判断される。

【0076】

条件監視部２２ｂによって検索ボタンが押された旨の信号を受信し、利用者が検索条件を全て入力したと判断された場合には（ＳＴ５のＹＥＳ）、起動アプリ取得部２２ｄにその旨送信され、推奨アプリケーションの検索が開始される。

【0077】

起動アプリ取得部２２ｄは、検索データベース２３内の起動アプリ記憶部２３ａに格納されている情報を取得する（ＳＴ６）。起動アプリ記憶部２３ａには、アプリ提供者から提供されるアプリケーションに関する各種情報が記憶されている。図９は、本発明の実施の形態における検索データベース内の起動アプリ記憶部に格納されるアプリケーションに関する情報のテーブルの一例を示す説明図である。

【0078】

図９に示されているテーブルには、設定される項目に合わせてそれぞれのアプリケーションに関する情報が格納されている。ここでは、「アプリＩＤ」、「アプリ名」、「価格」、「検査種別」の４つの項目が示されている。ここで項目として示されている「価格」と「検査種別」の意味については、入力画面例（図８参照）の箇所で説明した内容と同様である。例えば、「アプリＩＤ」が「２」で示される「アプリＢ」の場合、「価格」は「１０，５００円」であり、「検査種別」は「ＣＴ」である。

【0079】

なお、アプリケーションに関する情報をテーブルに格納するに当たって設定される項目の数は図９に示すテーブルのように４つに限られず、任意に設定することが可能である。また、ここでは特に示していないが、テナント型医療情報システム２を用いてアプリケーションが利用された場合、或いは、アプリ提供者によって新規なアプリケーションが提供された場合には、あるタイミングでそれらのアプリケーションに関する情報が起動アプリ記憶部２３ａに記憶（格納）される。

【0080】

起動アプリ取得部２２ｄが起動アプリ記憶部２３ａから取得したアプリケーションに関する情報は、アプリ絞込部２２ｅへと送られる。アプリ絞込部２２ｅには、併せて条件監視部２２ｂから検索条件が入力されたこと、及び検索条件が通知されるので、アプリ絞込部２２ｅは検索条件に従ってアプリ絞込部２２ｅから受けたアプリケーションに関する情報を基に検索条件に合致するアプリケーションを絞り込む（ＳＴ７）。

【0081】

例えば、当該実施の形態においては、検索条件として「予算」は１１，０００円以下であり、「検査種別」はＣＴ（装置）である（図８の入力画面例参照）。そこでアプリ絞込部２２ｅは、これらの検索条件を基に起動アプリ取得部２２ｄから送信されたアプリケーションの情報から合致するアプリケーションを抽出する。上述したように、起動アプリ記憶部２３ａには、図９に示すようなテーブルが格納されており、検索条件を基にアプリ絞込部２２ｅが絞り込みを掛けると、７つあるアプリケーションに関する情報の中から、「アプリＩＤ」が「２」、「４」、「６」、すなわち、「アプリＢ」、「アプリＣ」、「アプリＥ」の３つを抽出することができる。

【0082】

アプリ絞込部２２ｅによって入力条件に沿ったアプリケーションが抽出されると、次に、アプリ利用頻度取得部２２ｆにおいて抽出されたアプリケーションの利用頻度を把握する。具体的には、まず、利用者情報取得部２２ｃから利用者情報及び類似利用者情報がアプリ利用頻度取得部２２ｆに入力される。併せてアプリ絞込部２２ｅから抽出されたアプリケーションに関する情報がアプリ利用頻度取得部２２ｆに入力される。つまり、アプリ利用頻度取得部２２ｆに集まった、利用者情報、類似利用者情報、絞り込まれて抽出されたアプリケーションに関する情報を利用して抽出されたアプリケーションに関する利用頻度を把握する。

【0083】

ここで利用者情報は、読影に当たって自身に適切と考えられるアプリケーションの推奨を受ける医師Ａ（利用者ＩＤ：１００）に関する情報である。また、類似利用者情報は、利用者である医師Ａとその属性が類似する利用者に関する情報であり、上述した通り、医師Ｂ（利用者ＩＤ：２００）と医師Ｃ（利用者ＩＤ：３００）に関する情報である。一方、絞り込まれて抽出されたアプリケーションは、「アプリＢ」、「アプリＣ」、「アプリＥ」である。アプリ利用頻度取得部２２ｆは、アプリ利用頻度記憶部２３ｂからこれらの条件を含むアプリケーションの利用頻度に関する情報を取得する。

【0084】

アプリ利用頻度取得部２２ｆは、検索サーバ２３内に設けられているアプリ利用頻度記憶部２３ｂから上述した３つの情報を基に利用頻度に関する情報を抽出する。図１０は、本発明の実施の形態における検索データベース２３内のアプリ利用頻度記憶部２３ｂに格納されるそれぞれのアプリケーションの利用頻度に関する情報のテーブルの一例を示す説明図である。

【0085】

ここでは５つの項目が示されており、「アプリＩＤ」、「アプリ名」、「利用者ＩＤ」、「疾病」、「利用頻度」である。例えば、「アプリＩＤ：１」、「アプリ名：アプリＡ」、「利用者ＩＤ：１００」、「疾病：心筋梗塞症」、「利用頻度：２０」（テーブルの１番目）についての情報は、利用者情報を基にアプリ利用頻度取得部２２ｆがアプリ利用頻度記憶部２３ｂから取得した情報である。また、テーブルの上から１０番目に示されている情報は、「アプリＩＤ：６」、「アプリ名：アプリＥ」、「利用者ＩＤ：２００」、「疾病：大動脈解離」、「利用頻度：０」となっている。

【0086】

但し、このようにアプリ利用頻度取得部２２ｆがアプリケーションの情報を取得しても、図１０に示すテーブルからも明らかなように、このままでは利用者に対して適切なアプリケーションを推奨するには数が多すぎる。そこで、さらにアプリケーションを絞り込むために、利用者が読影する医療画像に関する情報を利用する。

【0087】

具体的には、条件監視部２２ｂから入力条件が入力された旨の情報がオーダ情報取得部２２ｇに送られる。オーダ情報取得部２２ｇは、読影対象となっている医療画像に関する情報を取得する（ＳＴ９）。さらに、オーダ情報取得部２２ｇは、当該医療画像に関する情報を基にオーダ情報記憶部５ｂから当該医療画像が医療画像診断装置４において取得される基となったオーダ情報を取得する（ＳＴ１０）。

【0088】

医療画像は、例えば管理装置５を構成する各種システムにてオーダ情報が生成され、当該オーダ情報に基づいて医療画像診断装置４によって取得、生成される。従って、オーダ情報は、いわば医療画像を取得するための依頼書、発注書の役割を果たすものである。

【0089】

図１１は、本発明の実施の形態におけるオーダ情報記憶部５ｂに格納される医療画像の取得処理に関するオーダ情報のテーブルの一例を示す説明図である。図１１に示すテーブルによれば、オーダ情報は、８つの項目をもって規定されている。なお、オーダ情報記憶部５ｂにいくつの項目をもってオーダ情報を規定するかは任意に設定することができる。

【0090】

当該実施の形態においては、「オーダＩＤ」、「患者ＩＤ」、「依頼元科」、「依頼元医師ＩＤ」、「ステータス」、「実施予定日」、「依頼先科」、「オーダ情報テキスト」の各項目が設けられている。例えば、「オーダＩＤ」が「２」のオーダ情報は、「患者ＩＤ：２０００」、「依頼元科：外科」、「依頼元医師ＩＤ：５００」、「ステータス：依頼中」、「実施予定日：２０１１年８月２２日」、「依頼先科：放射線科」とされる。ここで、「ステータス」とは、読影がなされたか否かの情報を示す項目であり、「依頼中」は読影を現在依頼中であり未だ完了していないことを示している。

【0091】

さらに「オーダ情報テキスト」には、図１１のテーブルに示されているように、テキスト形式で具体的な撮影の依頼内容が表わされている。また、当該オーダ情報テキスト内には、患者を診察した医師である依頼元医師による所見も含まれており、例えば、「オーダＩＤ」が「２」のオーダ情報の場合、「腹部大動脈瘤の疑い」と、疑われる疾病も示されている。

【0092】

なお、図１１に示すオーダ情報は、例えば、ＨＬ７（HEALTH LEVEL 7）のような標準形式で作成されても良く、或いは、各医療機関における独自のフォーマットにて作成されても良い。

【0093】

ここでは読影の対象である医療画像に関する情報から、オーダ情報取得部２２ｇは、「オーダＩＤ」が「２」のオーダ情報を取得する。オーダ情報取得部２２ｇがオーダ情報を取得するに当たっては、オーダ情報における「実施予定日」の日付が、例えば、現実の日付と同一の日付、或いは、それよりも前の日付となっているオーダ情報を取得する。このようなオーダ情報であれば、未だ読影処理がなされていないと判断できるからである。

【0094】

なお、当然のことながら、「ステータス」の項目も確認される。図１１に示されるオーダ情報においては、実施予定日が同じ「２０１１年８月２２日」であっても、オーダＩＤが「１」のオーダ情報については、ステータスは「完了」とあることから、当該オーダ情報に関する医療画像ついては既に読影処理が完了している。一方、オーダＩＤが「２」のオーダ情報に関する医療画像については、ステータスが「依頼中」となっていることから未だ当該医療画像に対する読影処理は行われていない。そこで、このオーダ情報を取得して読影処理に必要な推奨アプリケーションの検索に使用する。

【0095】

オーダ情報取得部２２ｇは、該当するオーダ情報を取得すると、当該オーダ情報をオーダ情報解析部２２ｈへ送る。オーダ情報解析部２２ｈでは、受信したオーダ情報の中から、例えばオーダ情報テキストに示されている語句を構文解析する（図６のＳＴ１１）。

【0096】

オーダ情報解析部２２ｈでは、例えば、オーダ情報テキストの作成ルールと構文解析から必要な情報を取得する。オーダ情報テキスト内の語句のうち、例えば、疾病の名称といった、あるまとまりを持った語句を抽出する。例えば、「オーダＩＤ」が「２」のオーダ情報を例に取ると、オーダ情報テキストの中から依頼元医師の所見である「大動脈」との語句を抽出する。また、「Ｘ線ＣＴ検査造影腹部仰臥位３Ｄ作成必要」との一連の語句から、検査装置が「Ｘ線ＣＴ」であり、「造影（剤）」を利用して「腹部」の検査を行う、といった内容が理解できるため、これらの各語句を抽出する。

【0097】

なお、オーダ情報解析部２２ｈが構文解析を行う際には、抽出される語句が適切でなければならない。すなわち、ここで説明している実施の形態においては利用者（医師Ａ）は、オーダＩＤが「２」であるオーダ情報に基づいて取得された医療画像について読影を行う。従って、患者ＩＤが「２００００」に対して疑われる疾病は「腹部大動脈瘤」である（図１１参照）。

【0098】

また、医師Ａがもともと「腹部大動脈瘤」に関する読影を行った経験がない、或いは少ない、または、経験があってもこれまで利用したことがない新規なアプリケーションが提供されているが当該アプリケーションを医師Ａは利用したことがない場合に、医師Ａに対して最適なアプリケーションを推奨することを前提としている。

【0099】

このような状況にあって、オーダ情報解析部２２ｈが「腹部大動脈瘤」をキーワードとなる語句として抽出して検索すると、過去に「腹部大動脈瘤」に関する医療画像の読影に利用されたアプリケーションが検索され、推奨されることになる。但し、医師Ａ自身は「腹部大動脈瘤」に関する医療画像の読影を行った経験がないことから、このようなアプリケーションが推奨されたとしても、利用者である医師Ａにとってこれらのアプリケーションが利用勝手の良いアプリケーションであるかは不明である。

【0100】

そこで利用者（医師Ａ）に対してより良いアプリケーションを推奨するべく、これまで読影に利用されてきたアプリケーションを広く抽出し、その中から上述した、例えば類似利用者情報等を用いて好適なアプリケーションを絞り込み推奨することとしている。そのため、オーダ情報解析部２２ｈが構文解析を行って語句を抽出する際には、疾病名をそのまま抽出するだけではなく、広く複数の疾病が検索されるように語句を抽出している。従って、当該実施の形態においては、抽出する語句を「腹部大動脈瘤」とするのではなく、例えば、「大動脈瘤」、或いは、「大動脈」とする。ここでは「大動脈」と抽出された場合を例に挙げて説明する。

【0101】

オーダ情報解析部２２ｈが構文解析を行い、「大動脈」をキーワードとしてオーダ情報の内容を抽出したら、オーダ情報解析部２２ｈは好適アプリ判定部２２ｉへとキーワードを送信する。好適アプリ判定部２２ｉには、当該キーワードの他、利用者情報、類似利用者情報、並びに、絞り込まれたアプリケーションに関する情報、これらのアプリケーションの利用頻度に関する情報が入力される（ＳＴ１２）。好適アプリ判定部２２ｉでは、これらの条件を基に、利用者に対して最も適したアプリケーションを検索、推奨する。好適アプリを判定する流れについては、以下、図１２ないし図１５に示す、本発明の実施の形態における推奨アプリケーションの検索の流れを説明するための説明図を用いて説明する。

【0102】

まず、好適アプリ判定部２２ｉがオーダ情報解析部２２ｈから送られてきたキーワード（ここでは「大動脈」）を基に、図１０に示すアプリケーションの利用頻度に関する情報のテーブルにおいて「大動脈」の語句が疾病の名称の中に含まれるアプリを抽出する。なお、上述したように、図１０に示されるテーブルは、既に入力された検索条件を基に、アプリケーションの中から「アプリＡ」、「アプリＢ」、「アプリＣ」、「アプリＥ」が検索され、これらに関する利用頻度を好適アプリ判定部２２ｉが把握できるように調整されている。

【0103】

ここでは、図１０のテーブルにも示されているように、上から２つ以外のアプリケーションは、「大動脈」がその名称の中に含まれる疾病に対して利用されることが理解できる（上２つは、「心筋梗塞症」の医療画像の読影の際に利用されるアプリケーションである）。また、利用者情報及び類似利用者情報を用いて、これらの情報に合致しないアプリケーションに関しては選択されないようにする。利用者情報、類似利用者情報を用いるのは、類似利用者（医師Ｂ、或いは、医師Ｃ）のアプリケーションの利用傾向を把握することで、利用者（医師Ａ）に対して新たに利用することになるアプリケーションであってもより使い勝手の良いアプリケーションを推奨するためである。

【0104】

これらの情報を用いて、図１０に示したテーブルに示されるアプリケーションの中から好適アプリ判定部２２ｉが推奨アプリケーションの候補として選択したアプリケーションが図１２のテーブルに示されている。図１２に示すテーブルでは、便宜上、好適アプリ判定部２２ｉにおいて選択されたアプリケーションには色が付されており、反対に選択されなかったアプリケーションは白抜きで示されている。

【0105】

上述したように、「大動脈」をその中に含まない疾病である「心筋梗塞症」については選択されていない。また、利用者ＩＤが「４００」の者が過去利用したアプリケーションについても選択されていない。これは、利用者ＩＤが「４００」の者は、図７に示されているように、その権限は「技師長」であり、利用者である医師Ａや医師Ｂ、医師Ｃとは、その属性が異なることから類似利用者とは判断されていないからである。

【0106】

このようにして選択されたアプリケーション（図１２において色が付されているアプリケーション）を基に、今度は疾病ごとに利用者ごとのアプリケーションの利用頻度を把握する。この状態を表わしたのが、図１３、図１４である。いずれも特定の疾病について誰がどのアプリケーションをどれだけ利用しているかが明確にされている。

【0107】

図１３では、「大動脈解離」について示されている。図１３によると、「大動脈解離」に関する医療画像の読影を行う際には、医師Ａは、アプリＢを最も良く利用する（２０回）。一方、アプリＣは２回、アプリＥについては、０回である。同じように、医師Ｂは、アプリＢを１３回、アプリＣを２回、アプリＥを０回、医師Ｃは、アプリＢを２０回、アプリＣを２６回、アプリＥを３回である。図１３を見ると、医師Ａと医師Ｂに関しては、いずれもアプリＢの利用頻度が一番高く、次にアプリＣであることから、医師Ａと医師Ｂはアプリケーションの利用傾向が似ていると把握できる。一方、医師ＣはアプリＢよりもアプリＣの方が利用頻度が高く、医師Ａや医師Ｂの利用傾向とは異なる。

【0108】

図１４「腹部大動脈縮窄」に関する各利用者のアプリケーションの利用傾向を示す説明図である。「腹部大動脈縮窄」に関する医療画像を読影する場合、いずれの利用者もアプリＢは利用していない。一方、医師Ａと医師ＢはアプリＥの利用頻度が高いのに対して、医師ＣはアプリＣを頻繁に利用している。従って、「腹部大動脈縮窄」の読影に際し利用されるアプリケーションの傾向も、「大動脈解離」の場合と同様、医師Ａと医師Ｂとが似ていることが分かる。

【0109】

以上２つの疾病に関するアプリケーションの利用傾向を見ると、また、医師Ａのアプリケーションの利用傾向が似ているのは、医師Ｂであることが分かる。従って、医師Ａに類似する利用者は医師Ｂである、と判定される（ＳＴ１３）。

【0110】

そこで、いよいよ以上説明した傾向を基に、利用したことがないアプリケーションを新たに利用する場合、或いは、読影の経験がない医療画像を読影する際に利用する場合にどのアプリケーションを利用することが、医師Ａにとって最適であるかが好適アプリ判定部２２ｉにおいて判定される。すなわち、医師Ａが「腹部大動脈瘤」に関する医療画像を読影する際に利用するアプリケーションとしてどのアプリケーションを推奨することが最も適切なアプリケーションの推奨になるかが判定される。

【0111】

ここで、図１５には「腹部大動脈瘤」に関する医師Ｂと医師Ｃのアプリケーションの利用傾向が示されている。なお、医師Ａは、アプリケーションの推奨を受ける利用者であり、腹部大動脈瘤に関する医療画像の読影を経験していないことが前提なので、図１５に示す説明図ではいずれのアプリケーションにおいても利用頻度が不明であること（利用されていないこと）が示されている。

【0112】

上述したように、医師Ａとアプリケーションの利用傾向が似ているのは医師Ｂである。そこで図１５を参照すると、医師Ｂが腹部大動脈瘤に関する医療画像の読影を行う場合には、アプリＣを最も良く利用することが分かる。そこで、好適アプリ判定部２２ｉは、このように、オーダ情報から得られる読影対象となる画像の疾病（ここでは「腹部大動脈瘤」）に関して当該類似利用者（医師Ｂ）の利用頻度が高いアプリ（アプリＣ）を抽出する（ＳＴ１４）。そして、統合ビューア２１は、抽出された当該アプリケーションを利用者（医師Ａ）への推奨アプリケーションとしてクライアント端末１を介して提示する（ＳＴ１５）。

【0113】

図１６は、本発明の実施の形態における推奨アプリケーションの検索を行った結果を利用者に提示する画面の一例を示す画面例である。当該画面例では、最上部に、「読影アプリケーション検索結果」と表示されており、上述した流れに沿って推奨アプリケーションが検索され、当該画面上において推奨結果であるアプリケーションが提示（推奨）されている。

【0114】

具体的な推奨結果は、画面の上部に「アプリ名称」、「価格」、「対応検査種別」という３つの項目でその書誌的な事項が示されている。これらはそれぞれ、「アプリＣ」、「１１，０００円」、「ＣＴ」となるが、「価格」と「対応検査種別」については、入力条件を満たしていることが示されている。推奨アプリケーションとして、ここでは「アプリケーションＣ」が利用者である医師Ａに対して示されている。

【0115】

この推奨アプリケーションの具体的な機能については、その一端が画面例中央に示されている。ここでは、アプリケーションＣを利用して加工された医療画像の例が２枚表示されている。また、画面右側には「読影例」、「利用ガイド」といった２つのボタンが設けられている。利用者は、これらのボタンを適宜押す（クリックする）ことで、推奨されたアプリケーションＣに関して必要な情報を入手することができる。

【0116】

ここで「読影例」とは、アプリケーションＣを利用して医療画像を読影する際の様々な画像について例示的に示すものである。「利用ガイド」は、その名の通りアプリケーションＣの、いわば取扱説明書である。アプリケーションＣを用いて表示可能な医療画像を確認し、その他様々なアプリケーションＣに関する情報を確認し、当該アプリケーションＣを利用する場合には、画面例右下に設けられている「ダウンロード」のボタンを押すことで、アプリケーションＣを入手することができる。

【0117】

なお、図１６に示す画面例は、あくまでも例示であって、そのレイアウトや表示項目、例えば、推奨アプリケーションを利用した場合の画像等の表示枚数等については任意に設定することができる。また、ダウンロードボタンを押すと、統合ビューア２１、シンクライアントマネージャ２４を介して推奨されたアプリケーションをダウンロードすることができるが、このダウンロードがアプリケーションの購入であっても、或いは、購入はせず利用するだけの形態であっても構わない。

【0118】

ダウンロードボタンが押されて推奨アプリケーションがダウンロードされると、テナント型医療情報システム２に設けられている課金エンジン２６にその利用態様、或いは、購入に掛かる費用が課金される。

【0119】

また、例えば、推奨アプリケーションをダウンロードした時点、或いは、読影レポートが作成された時点でアプリ利用頻度記憶部２３ｂに当該推奨アプリケーションの利用回数が１回分追加される。例えば、上述した医師ＡがアプリケーションＣを腹部大動脈瘤に用いる、という利用の仕方については、今回初めてであることから、例えば、図１０に示すアプリ利用頻度記憶部２３ｂに記憶されるテーブルに新たに、「アプリＩＤ：４」、「アプリ名：アプリＣ」、「利用者ＩＤ：１００」、「疾病：腹部大動脈瘤」、「利用頻度：１」が追加して記憶されることになる。なお、どの時点で利用頻度の回数をカウントするかは自由に設定することができる。

【0120】

以上説明した構成、検索方法を採用することによって、利用者が読影のためにアプリケーションを利用する際、アプリケーションの検索を行うに当たって、アプリケーションに関する利用条件のみならず利用者の属性をも考慮し当該利用者に対して最適なアプリケーションの提供を行うことが可能な医療情報システム及び推奨アプリケーションの検索方法を提供することができる。

【0121】

特に、利用者に対する推奨アプリケーションの提示に当たって、利用者が入力した検索条件のみを利用して検索、推奨を行うのではなく、利用者自身に関する情報（利用者情報）及び、利用者にその属性が似ている利用者に関する情報（類似利用者情報）をも利用することで、より利用者に適したアプリケーションを推奨することができる。

【0122】

さらには、これら入力条件や利用者情報等は、いわば利用者側の情報と言えるが、これらの情報の他に、読影対象となる医療画像側の情報であって利用者以外の者によって入力された情報、すなわち、上述したオーダ情報を利用することで、より客観的に実際に読影を行うに当たって最適なアプリケーションを推奨することが可能となる。

【0123】

（第２の実施の形態）
次に本発明における第２の実施の形態について説明する。なお、第２の実施の形態において、上述の第１の実施の形態において説明した構成要素と同一の構成要素には同一の符号を付し、同一の構成要素の説明は重複するので省略する。

【0124】

第２の実施の形態における検索装置２２Ａと検索データベース２３Ａの内部構成は、第１の実施の形態における検索装置２２と検索データベース２３の内部構成が相違する。図１７は、本発明の第２の実施の形態における検索装置２２Ａ及び検索データベース２３Ａの内部構成を示すブロック図である。

【0125】

第２の実施の形態における検索装置２２Ａでは、好適条件取得部２２ｊと装置情報取得部２２ｋとが追加されて設けられている。ここで「好適条件」とは、利用者に対して推奨されたアプリケーションを利用する際に、当該推奨アプリケーションを利用するクライアント端末１に対して要求される動作環境（スペック）のことである。

【0126】

好適条件取得部２２ｊは、好適条件記憶部２３ｃから好適条件に関する情報を取得する。図１８は、本発明の第２の実施の形態におけるアプリケーションの好適条件を格納するテーブルの一例を示す説明図である。当該テーブルは好適条件記憶部２３ｃ内に設けられている。ここでは、４つの項目が設けられており、「アプリＩＤ」、「アプリ名」に「好適条件ＩＤ」及び「好適条件」が紐づけられている。例えば、「アプリＩＤ：２」、「アプリ名：アプリＢ」で示されるアプリケーションについては、好適条件が２つ定められており、１つは当該アプリケーションを動作させるに必要なＯＳとして「Ｗｉｎｄｏｗｓ（登録商標）２００８Ｒ２」が挙げられており、また、当該アプリケーションは、胸部画像を読影する際に利用されるに適していることが読み取れる。

【0127】

推奨アプリケーションの検索等を行うに当たってこの好適条件を検討することで、実際に利用者が推奨アプリケーションを利用する際に用いるクライアント端末１の動作環境等に見合ったアプリケーションを推奨することが可能となる。

【0128】

次に、検索装置２２には、装置情報取得部２２ｋが設けられ、検索データベース２３には装置情報記憶部２３ｄが設けられている。通常、依頼元医師によって作成されたオーダ情報に基づいて医療画像診断装置４にて所望の医療画像が取得、生成される。ここでいう「装置情報」とは、当該医療画像を取得する医療画像診断装置４に関する情報である。「装置情報」には、例えば、ＣＴ装置、ＭＲＩといった医療画像診断装置４の種類を表わす「装置種」と、同一種の医療画像診断装置４におけるモデルを表わす「装置型」のいずれも含まれる。装置情報記憶部２３ｄ内には、例えば、医療機関内に設置されている、各種医療画像診断装置の装置に関する情報が記憶されている。

【0129】

オーダ情報解析部２２ｈは、上述したようにオーダ情報取得部２２ｇが取得したオーダ情報を解析することで様々な情報を得て、好適アプリ判定部２２ｉに送信する。その解析された情報の中には医療画像を取得する際に利用される医療画像診断装置に関する情報も含まれる（例えば、図１１のオーダ情報「２」においては、「Ｘ線ＣＴ装置」が使用されることがオーダ情報に含まれている）。そこで、この使用される装置に関する情報をオーダ情報解析部２２ｈから装置情報取得部２２ｋへと送信し、使用される詳細な装置に関する情報を装置情報記憶部２３ｄから入手させる。装置情報取得部２２ｋは入手した「装置情報」を好適アプリ判定部２２ｉへと送信する。

【0130】

好適アプリ判定部２２ｉが利用者に対して推奨するアプリケーションを判定する際に、これまで説明してきた各種情報の他に、装置情報も加味して判定することによって、利用者に対して適切なアプリケーションを推奨することが可能となる。

【0131】

すなわち、利用者にとっても今回の読影処理を行うに当たって、過去に当該装置で取得された医療画像の読影処理に利用されたアプリケーションを利用した方が、全く異なる装置で取得された医療画像の読影処理に利用されたアプリケーションを利用するよりも使い勝手が良く、読影処理も適切に進められるものと考えられる。

【0132】

そこで、当該実施の形態においては、好適アプリ（推奨アプリケーション）の検索、推奨を図るに当たって、これまで説明してきた利用者情報等以外に、装置情報も併せて用いることによって、利用者に対してより適切なアプリケーションを推奨することができる。

【0133】

また、これら好適条件に関する情報、装置情報をアプリケーションを推奨するに当たって併せて用いることによって、当然のことながら、利用者が読影のためにアプリケーションを利用する際、アプリケーションの検索を行うに当たって、アプリケーションに関する利用条件のみならず利用者の属性をも考慮し当該利用者に対して最適なアプリケーションの提供を行うことが可能な医療情報システム及び推奨アプリケーションの検索方法を提供することができる。

【0134】

（第３の実施の形態）
次に本発明における第３の実施の形態について説明する。なお、第３の実施の形態において、上述の第１、または第２の実施の形態において説明した構成要素と同一の構成要素には同一の符号を付し、同一の構成要素の説明は重複するので省略する。

【0135】

第３の実施の形態における医療情報システムＳ１は、これまで説明してきた医療情報システムＳを、これまでのように特定の医療機関のみで利用するのではなく、ある地域全体で利用可能とした形態である。

【0136】

図１９は、本発明の第３の実施の形態における医療情報システムＳ１の全体構成を示すブロック図である。医療情報システムＳ１は、通信ネットワークＮ１にそれぞれ医療機関Ｈ（図１９では、医療機関Ｈ１ないしＨ３）が接続されるとともに、併せて地域データセンタ６も接続されている。

【0137】

医療機関Ｈの内部には、例えば、医療機関Ｈ１に示されているように、上述した医療情報システムＳが構築されている。また一方で、医療機関Ｈ１とは異なった構成を採用していても良い。

【0138】

地域データセンタ６は、地域の医療機関Ｈにおいて医療画像の読影処理を行う際に利用することのできるアプリケーションを推奨してもらうに必要な情報が格納されている。図２０は、本発明の第３の実施の形態における地域データセンタ６の内部構成を示すブロック図である。

【0139】

地域データセンタ６内には、通信ネットワークＮ１と接続し、各医療機関Ｈとの通信をやり取りする送受信部６ａと、地域利用者情報取得部６ｂと、地域利用者情報記憶部６ｃと、アプリ利用頻度取得部６ｄと、アプリ利用頻度記憶部６ｅとが設けられている。

【0140】

地域利用者情報記憶部６ｃには、医療機関Ｈから当該地域データセンタ６にアクセスして読影処理を行う際に利用するアプリケーションの推奨を受けた利用者に関する情報が記憶されている。従って、地域利用者情報取得部６ｂは、医療機関Ｈから地域データセンタ６にアクセスしアプリケーションの推奨を受けようとする利用者（以下、このような利用者を便宜的に「地域利用者」と表わす）に関する情報を地域利用者情報記憶部６ｃから取得する。併せて、地域利用者にその属性が似ている他の利用者（以下、このような利用者を「類似地域利用者」と表わす）に関する情報も取得する。ここで、類似地域利用者は、地域利用者と同じ医療機関Ｈに勤務する者であっても良く、或いは、同じ地域の別の医療機関Ｈに勤務する者であっても良い。

【0141】

アプリ利用頻度記憶部６ｅには、地域データセンタ６を利用してアプリケーションの選択がなされた場合に、それら選択されたアプリケーションの利用頻度に関する情報が記憶されている。そして、推奨アプリケーションの検索、選択が行われ、利用者が当該推奨アプリケーションを利用した場合に、推奨されたアプリケーションの利用頻度が１つ増えることになる。また、アプリケーションの推奨に当たっては、必要な情報（アプリケーションの利用頻度に関する情報）がアプリ利用頻度取得部６ｄによってアプリ利用頻度記憶部６ｅから取得される。

【0142】

ここで、地域利用者がある医療画像に関して読影処理を行う際に利用するアプリケーションの推奨を受ける流れは、基本的に上述した通りである。

【0143】

すなわち、地域利用者が検索画面を開き、ログインした際に入力された地域利用者に関する情報を基に、地域データセンタ６の地域利用者情報取得部６ｂが地域利用者情報記憶部６ｃから地域利用者に関する情報を取得する。併せて、地域利用者に類似する類似地域利用者に関する情報も取得する。検索装置２２内の条件監視部２２ｂでは、地域利用者が推奨を希望するアプリケーションに関する条件が入力されたことを検知して、起動アプリ取得部２２ｄに通知する。起動アプリ取得部２２ｄは、起動アプリ記憶部２３ａからアプリケーションに関する情報を入手し、アプリ絞込部２２ｅに送信する。

【0144】

アプリ絞込部２２ｅでは、推奨するアプリケーションを絞り込むとともに、アプリ利用頻度取得部６ｄに情報を送り、アプリ利用頻度記憶部６ｅは該当するアプリケーションに関する利用頻度をアプリ利用頻度記憶部６ｅから取得する。

【0145】

さらに、検索装置２２内のオーダ情報取得部２２ｇは、オーダ情報記憶部５ｂから読影の対象となっている医療画像に関するオーダ情報を取得し、オーダ情報解析部２２ｈにおいて、その内容が解析される。好適アプリ判定部２２ｉは、地域利用者情報、類似地域利用者情報、アプリケーションの利用頻度に関する情報、オーダ情報を解析した情報等を基に、地域利用者に対して推奨するアプリケーションを判定する。

【0146】

なお、ここで起動アプリ記憶部２３ａとオーダ情報記憶部５ｂは、地域データセンタ６内には設けられず、あくまでも各医療機関Ｈの内部に設けられている。医療機関Ｈの地域連携が進み、アプリケーションの推奨を受けるに当たっても地域データセンタ６内の情報が利用される状態となっても、起動アプリに関する情報やオーダ情報は、患者の個人情報としての側面が非常に強いため、地域データセンタ６内に置いておくことはできないと考えられるからである。従って、ここでは起動アプリ取得部２２ｄとオーダ情報取得部２２ｇについても各医療機関Ｈの内部に設けられている。

【0147】

好適アプリ判定部２２ｉによって推奨するアプリケーションが判定されたら、統合ビューア２１において表示の体裁が整えられ、利用者が使用するクライアント端末１の表示部に推奨アプリケーションが表示される。

【0148】

以上説明した通り、読影を行う際に利用するアプリケーションの推奨を行うに当たってある地域に属する複数の医療機関が地域データセンタに記憶されている地域利用者に関する情報等を用いることによって、一医療機関内の利用者情報のみならず、地域間において連係する複数の医療機関に属する利用者に関する情報をも用いることができることになるため、アプリケーションの推奨を受ける利用者により一層適したアプリケーションを推奨することができる。

【0149】

なお、この際、最初から地域データセンタ内に記憶されている、各種情報を利用して推奨アプリケーションの検索を行っても、或いは、利用者が属する医療機関Ｈの内部で一度アプリケーションの検索等を行い、適切な推奨アプリケーションが得られなかった場合に、次に地域データセンタ内の情報を利用して推奨アプリケーションの検索等を行うようにしても良い。

【0150】

また、当然のことながら、利用者が読影のためにアプリケーションを利用する際、アプリケーションの検索を行うに当たって、アプリケーションに関する利用条件のみならず利用者の属性をも考慮し当該利用者に対して最適なアプリケーションの提供を行うことが可能な医療情報システム及び推奨アプリケーションの検索方法を提供することができる。

【0151】

本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することを意図していない。この実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。例えば、これまでは、利用者の使用するクライアント端末、システム運営者が設置するテナント型医療情報システム、アプリ提供者が参加するアプリサーバからなる医療情報システムを基に説明を行ってきたが、例えば、テナント型医療情報システムの機能をクライアント端末内に設けることで上述した各機能を果たすことができるようにしても良い。

【0152】

また、利用者情報（類似利用者情報）の取得、起動アプリ取得部によるアプリケーションに関する情報の取得、或いは、オーダ情報の取得といった各処理については、上記説明においてはその処理に順番があるように説明をしているが、これはあくまでも説明の便宜のためであり、各処理が並行して行われるようにしても良い。

【0153】

この実施形態やその変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

【符号の説明】

【0154】

１ クライアント端末
２ テナント型医療情報システム
３ アプリサーバ
４ 医療画像診断装置
５ 管理サーバ
５ａ 利用者情報記憶部
５ｂ オーダ情報記憶部
２１ 統合ビューア
２２ 検索装置
２２ａ 送受信部
２２ｂ 条件監視部
２２ｃ 利用者情報取得部
２２ｄ 起動アプリ取得部
２２ｅ アプリ絞込部
２２ｆ アプリ利用頻度取得部
２２ｇ オーダ情報取得部
２２ｈ オーダ情報解析部
２２ｉ 好適アプリ判定部
２３ 検索データベース
２３ａ 起動アプリ記憶部
２３ｂ アプリ利用頻度記憶部
２４ シンクライアントマネージャ
２５ アプリケーションＡ
２６ 課金エンジン
２７ 課金データベース
２８ 画像情報マネージャ
２９ 画像レポートデータベース
Ｓ 医療情報システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】