特許第6644646号(P6644646)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社ジェイマックシステムの特許一覧

特許6644646リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム
<>
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000002
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000003
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000004
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000005
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000006
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000007
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000008
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000009
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000010
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000011
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000012
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000013
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000014
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000015
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000016
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000017
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000018
  • 特許6644646-リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム 図000019
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6644646
(24)【登録日】2020年1月10日
(45)【発行日】2020年2月12日
(54)【発明の名称】リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラム
(51)【国際特許分類】
   G16H 15/00 20180101AFI20200130BHJP
【FI】
   G16H15/00
【請求項の数】8
【全頁数】13
(21)【出願番号】特願2016-118374(P2016-118374)
(22)【出願日】2016年6月14日
(65)【公開番号】特開2017-224118(P2017-224118A)
(43)【公開日】2017年12月21日
【審査請求日】2019年5月15日
(73)【特許権者】
【識別番号】399085912
【氏名又は名称】株式会社ジェイマックシステム
(74)【代理人】
【識別番号】100142365
【弁理士】
【氏名又は名称】白井 宏紀
(74)【代理人】
【識別番号】100146064
【弁理士】
【氏名又は名称】吉田 玲子
(72)【発明者】
【氏名】古瀬 司
(72)【発明者】
【氏名】菅野 裕之
【審査官】 渡邉 加寿磨
(56)【参考文献】
【文献】 特開2013−200591(JP,A)
【文献】 特開2005−18288(JP,A)
【文献】 特開2008−259622(JP,A)
【文献】 特開2015−191561(JP,A)
【文献】 特開2007−140925(JP,A)
【文献】 特開2002−190845(JP,A)
【文献】 特開2013−047940(JP,A)
【文献】 米国特許出願公開第2013/0179192(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 − 99/00
G16H 10/00 − 80/00
(57)【特許請求の範囲】
【請求項1】
医療施設に設けられた複数の診断部門間での検査部位名の対応関係が記憶されたメモリを備え、前記複数の診断部門のいずれか1つのクライアント端末から発行されかつ所望の検査部位名が記述された診断所見リクエストを前記複数の診断部門のいずれか1つのサーバに回送するリクエスト処理装置であって、
リクエスト先のサーバが属する診断部門がリクエスト元のクライアント端末が属する診断部門と異なるとき前記診断所見リクエストに記述された検査部位名を前記メモリを参照して変換する変換手段を備える、リクエスト処理装置。
【請求項2】
前記リクエスト先のサーバが属する診断部門が前記リクエスト元のクライアント端末が属する診断部門と一致するとき前記変換手段の処理を制限する制限手段をさらに備える、請求項1記載のリクエスト処理装置。
【請求項3】
前記診断所見リクエストを指定タイミングで前記リクエスト先のサーバに回送する回送手段、および
前記リクエスト先のサーバの回答が非探知を示すとき前記指定タイミングを更新する更新手段をさらに備える、請求項1または2記載のリクエスト処理装置。
【請求項4】
前記複数の診断部門は放射線診断部門および病理診断部門を含む、請求項1ないし3のいずれかに記載のリスエスト処理装置。
【請求項5】
前記診断所見リクエストは患者IDを含み、
前記リクエスト先のサーバによって探索される診断所見は前記患者IDによって識別される患者を対象として作成された診断所見である、請求項1ないし4のいずれかに記載のリクエスト処理装置。
【請求項6】
前記診断所見リクエストは所望の診断所見の保存位置を示すURLを要求するリクエストである、請求項1ないし5のいずれかに記載のリクエスト処理装置。
【請求項7】
医療施設に設けられた複数の診断部門間での検査部位名の対応関係が記憶されたメモリを備え、前記複数の診断部門のいずれか1つのクライアント端末から発行されかつ所望の検査部位名が記述された診断所見リクエストを前記複数の診断部門のいずれか1つのサーバに回送するリクエスト処理装置によって実行されるリクエスト処理方法であって、
リクエスト先のサーバが属する診断部門がリクエスト元のクライアント端末が属する診断部門と異なるとき前記診断所見リクエストに記述された検査部位名を前記メモリを参照して変換する変換ステップを備える、リクエスト処理方法。
【請求項8】
医療施設に設けられた複数の診断部門間での検査部位名の対応関係が記憶されたメモリを備え、前記複数の診断部門のいずれか1つのクライアント端末から発行されかつ所望の検査部位名が記述された診断所見リクエストを前記複数の診断部門のいずれか1つのサーバに回送するリクエスト処理装置に、
リクエスト先のサーバが属する診断部門がリクエスト元のクライアント端末が属する診断部門と異なるとき前記診断所見リクエストに記述された検査部位名を前記メモリを参照して変換する変換ステップを実行させるための、リクエスト処理プログラム。

【発明の詳細な説明】
【技術分野】
【0001】
この発明は、リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラムに関し、特に、複数の診断部門のいずれか1つのクライアント端末から発行された診断所見リクエストを複数の診断部門のいずれか1つのサーバに回送する、リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラムに関する。
【背景技術】
【0002】
複数の診断部門を抱える医療施設では、診断部門を跨いで診断所見を参照したいという要望が一般的に存在する。たとえば、放射線診断医(「放射線科医」または「読影医」と同義)は、放射線診断部門のサーバに保存された或る患者の診断所見に加えて、病理診断部門のサーバに保存された同じ患者の診断所見を参照したい場合がある。
【0003】
しかし、放射線診断医が病理部門の診断所見を参照しようとすると、現状では放射線科情報システムと異なる電子カルテシステムを利用する必要があり、操作が煩雑で使い勝手が悪いという問題がある。
【0004】
また、放射線診断部門から病理診断部門の診断所見を依頼する仕組みがないため、放射線診断医は病理診断部門の診断所見を確認しない場合が多い。この結果、放射線診断医は的確な診断を誤るおそれがある。このような誤診の問題は、病理診断部門に属する病理診断医などの他の医師にも起こり得る。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2000−348115号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
これに関連して、特許文献1は、レポートをファイル化してサーバへ保管することを開示するものの、他の診断部門からのリクエストに応答して診断所見を提供するような処理については何ら開示していない。
【0007】
それゆえに、この発明の主たる目的は、他の診断部門に属する医師の診断の的確性を高めることができる、リクエスト処理装置、リクエスト処理方法およびリクエスト処理プログラムを提供することである。
【課題を解決するための手段】
【0008】
この発明に係るリクエスト処理装置(30:実施例で相当する参照符号。以下同じ)は、医療施設に設けられた複数の診断部門間での検査部位名の対応関係が記憶されたメモリ(RGST1)を備え、複数の診断部門のいずれか1つのクライアント端末(10, 20)から発行されかつ所望の検査部位名が記述された診断所見リクエストを複数の診断部門のいずれか1つのサーバ(40, 50)に回送するリクエスト処理装置(30)であって、リクエスト先のサーバが属する診断部門がリクエスト元のクライアント端末が属する診断部門と異なるとき診断所見リクエストに記述された検査部位名をメモリを参照して変換する変換手段(S15, S21)を備える。
【0009】
好ましくは、リクエスト先のサーバが属する診断部門がリクエスト元のクライアント端末が属する診断部門と一致するとき変換手段の処理を制限する制限手段(S13, S19)がさらに備えられる。
【0010】
好ましくは、診断所見リクエストを指定タイミングでリクエスト先のサーバに回送する回送手段(S9, S17, S23)、およびリクエスト先のサーバの回答が非探知を示すとき指定タイミングを更新する更新手段(S31)がさらに備えられる。
【0011】
好ましくは、複数の診断部門は放射線診断部門および病理診断部門を含む。
【0012】
好ましくは、診断所見リクエストは患者IDを含み、リクエスト先のサーバによって探索される診断所見は患者IDによって識別される患者を対象として作成された診断所見である。
【0013】
好ましくは、診断所見リクエストは所望の診断所見の保存位置を示すURLを要求するリクエストである。
【0014】
この発明に従うリクエスト処理方法は、医療施設に設けられた複数の診断部門間での検査部位名の対応関係が記憶されたメモリ(RGST1)を備え、複数の診断部門のいずれか1つのクライアント端末(10, 20)から発行されかつ所望の検査部位名が記述された診断所見リクエストを複数の診断部門のいずれか1つのサーバ(40, 50)に回送するリクエスト処理装置(30)によって実行されるリクエスト処理方法であって、リクエスト先のサーバが属する診断部門がリクエスト元のクライアント端末が属する診断部門と異なるとき診断所見リクエストに記述された検査部位名をメモリを参照して変換する変換ステップ(S15, S21)を備える。
【0015】
この発明に従うリクエスト処理プログラムは、医療施設に設けられた複数の診断部門間での検査部位名の対応関係が記憶されたメモリ(RGST1)を備え、複数の診断部門のいずれか1つのクライアント端末(10, 20)から発行されかつ所望の検査部位名が記述された診断所見リクエストを複数の診断部門のいずれか1つのサーバ(40, 50)に回送するリクエスト処理装置(30)に、リクエスト先のサーバが属する診断部門がリクエスト元のクライアント端末が属する診断部門と異なるとき診断所見リクエストに記述された検査部位名をメモリを参照して変換する変換ステップ(S15, S21)を実行させるための、リクエスト処理プログラムである。
【発明の効果】
【0016】
メモリには複数の診断部門間での検査部位名の対応関係が記憶されるところ、リクエスト先のサーバが属する診断部門がリクエスト元のクライアント端末が属する診断部門と異なれば、診断所見リクエストに記述された検査部位名がメモリを参照して変換される。リクエスト元のクライアント端末を操作する医療従事者は、リクエスト先のサーバに保存された診断所見を踏まえて診断を行うことができる。これによって、他の診断部門に属する医師の診断の的確性が向上する。
【0017】
この発明の上述の目的,その他の目的,特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【図面の簡単な説明】
【0018】
図1】この実施例に適用される医療システムの構成の一例を示すブロック図である。
図2図1に示すリクエスト処理サーバの構成の一例を示すブロック図である。
図3図1に示す病理診断所見サーバの構成の一例を示すブロック図である。
図4図1に示す放射線診断所見サーバの構成の一例を示すブロック図である。
図5】リクエスト処理サーバに設けられたデータベースの構成の一例を示す図解図である。
図6】リクエスト処理サーバに設けられたレジスタの構成の一例を示す図解図である。
図7】(A)は放射線診断医用のクライアント端末から発行された診断所見リクエストの構造の一例を示す図解図であり、(B)はリクエスト処理サーバによって変換された診断所見リクエストの構造の一例を示す図解図である。
図8】(A)は放射線診断医用のクライアント端末から発行された診断所見リクエストの構造の他の一例を示す図解図であり、(B)はリクエスト処理サーバによって変換された診断所見リクエストの構造の一例を示す図解図である。
図9】(A)は病理診断医用のクライアント端末から発行された診断所見リクエストの構造の一例を示す図解図であり、(B)はリクエスト処理サーバによって変換された診断所見リクエストの構造の一例を示す図解図である。
図10】(A)は病理診断医用のクライアント端末から発行された診断所見リクエストの構造の他の一例を示す図解図であり、(B)はリクエスト処理サーバによって変換された診断所見リクエストの構造の一例を示す図解図である。
図11】(A)は病理診断医用のクライアント端末から発行された診断所見リクエストの構造のその他の一例を示す図解図であり、(B)はリクエスト処理サーバによって変換された診断所見リクエストの構造の一例を示す図解図である。
図12】(A)は病理診断医用のクライアント端末から発行された診断所見リクエストの構造のさらにその他の一例を示す図解図であり、(B)はリクエスト処理サーバによって変換された診断所見リクエストの構造の一例を示す図解図である。
図13】(A)は病理診断医用のクライアント端末から発行された診断所見リクエストの構造の他の一例を示す図解図であり、(B)はリクエスト処理サーバによって変換された診断所見リクエストの構造の一例を示す図解図である。
図14】(A)は病理診断医用のクライアント端末から発行された診断所見リクエストの構造のその他の一例を示す図解図であり、(B)はリクエスト処理サーバによって変換された診断所見リクエストの構造の一例を示す図解図である。
図15】リクエスト処理サーバに設けられたCPUの動作の一部を示すフロー図である。
図16】リクエスト処理サーバに設けられたCPUの動作の他の一部を示すフロー図である。
図17】病理診断所見サーバに設けられたCPUの動作の一部を示すフロー図である。
図18】放射線診断所見サーバに設けられたCPUの動作の一部を示すフロー図である。
【発明を実施するための形態】
【0019】
図1を参照して、この実施例の医療システムは、病理診断部門に配される病理診断用クライアント端末10および病理診断所見サーバ40と、放射線診断部門に配される放射線診断用クライアント端末20および放射線診断所見サーバ50とを備え、さらに病理診断用クライアント端末10または放射線診断用クライアント端末20から発行された診断所見リクエストを病理診断所見サーバ40または放射線診断所見サーバ50に回送するリクエスト処理サーバ30を備える。
【0020】
ここで、病理診断用クライアント端末10は病理診断医によって操作され、放射線診断用クライアント端末20は放射線診断医によって操作される。また、病理診断用クライアント端末10,放射線診断用クライアント端末20,リクエスト処理サーバ30,病理診断所見サーバ40および放射線診断所見サーバ50は、院内LAN60によって互いに接続される。さらに、リクエスト処理サーバ30は図2に示すように構成され、病理診断所見サーバ40は図3に示すように構成され、放射線診断所見サーバ50は図4に示すように構成される。
【0021】
リクエスト処理サーバ30において、バスBS3には、通信I/F30cn,CPU30pr,DRAM30rmおよびHDD30drが接続される。HDD30drには、データベースDB1およびレジスタRGST1が設けられる。また、院内LAN60とは、通信I/F30cnを介して接続される。
【0022】
病理診断所見サーバ40において、バスBS4には、通信I/F40cn,CPU40pr,DRAM40rmおよびHDD40drが接続される。HDD40drには、データベースDB2が設けられる。また、院内LAN60とは、通信I/F40cnを介して接続される。
【0023】
放射線診断所見サーバ50において、バスBS5には、通信I/F50cn,CPU50pr,DRAM50rmおよびHDD50drが接続される。HDD50drには、データベースDB3が設けられる。また、院内LAN60とは、通信I/F50cnを介して接続される。
【0024】
データベースDB1は、図5に示すように構成される。図5によれば、病理診断用クライアント端末10または放射線診断用クライアント端末20から発行された診断所見リクエストとリクエスト実行タイミングとが、共通のカラムに登録される。また、診断所見リクエストは、リクエスト元のクライアント,リクエスト先のサーバ,患者ID,検査日,検査部位名,通知先メールアドレスを項目として有する。
【0025】
診断所見リクエストによって要求される診断所見は、患者IDが示す患者を対象として、指定の検査日に指定の検査部位について作成された診断所見である。リクエスト先のサーバは、診断所見リクエストに対応する診断所見を探索し、探知した診断所見の保存位置を示すURL(Uniform Resource Locator)が記載されたメールを指定の通知先メールアドレスに通知する。
【0026】
レジスタRGST1は、図6に示すように構成される。図6によれば、病理診断用の検査部位名が各カラムの左側に記載され、放射線診断用の検査部位名が各カラムの右側に記載される。病理診断用の検査部位名としては“鼻咽頭”,“鼻腔”,“歯”,“肺”,“胸腔”,“乳腺”が想定され、放射線診断用の検査部位名としては“頭部”および“胸部”が想定される。
【0027】
病理診断用の検査部位名のうち“鼻咽頭”,“鼻腔”,“歯”には、放射線診断用の検査部位名のうち“頭部”が対応付けられる。また、病理診断用の検査部位名のうち“肺”,“胸腔”,“乳腺”には、放射線診断用の検査部位名のうち“胸部”が対応付けられる。
【0028】
また、病理診断所見サーバ40に設けられたデータベースDB2には、病理診断部門で作成された診断所見が保存される。同様に、放射線診断所見サーバ50に設けられたデータベースDB3には、放射線診断部門で作成された診断所見が保存される。
【0029】
リクエスト処理サーバ30に設けられたCPU30prは、図15図16に示すフロー図に従う処理を実行する。また、病理診断所見サーバ40に設けられたCPU40prは図17に示すフロー図に従う処理を実行し、放射線診断所見サーバ50に設けられたCPU50prは図18に示すフロー図に従う処理を実行する。
【0030】
なお、図15図16に示すフロー図に対応する制御プログラム(リクエスト処理プログラム)はHDD30drに記憶され、図17に示すフロー図に対応する制御プログラムはHDD40drに記憶され、図18に示すフロー図に対応する制御プログラムはHDD50drに記憶される。
【0031】
図15を参照して、ステップS1では病理診断用クライアント端末10または放射線診断用クライアント端末20から診断所見リクエストを受信したか否かを判別する。ステップS1の判別結果がNOであればそのままステップS7に進み、ステップS1の判別結果がYESであればステップS3およびS5で以下の処理を実行してからステップS7に進む。
【0032】
つまり、ステップS3では、受信した診断所見リクエストをデータベースDB1の空きカラムに登録する。ステップS5では、同じカラムに実行タイミングを登録する。登録される実行タイミングは、現在時刻を示す。
【0033】
ステップS7では、データベースDB1に診断所見リクエストが登録されているか否かを判別する。判別結果がNOであればステップS1に戻り、判別結果がYESであればステップS9に進む。ステップS9では、登録されている診断所見リクエストと同じカラムに登録された実行タイミングが現在時刻以降の時刻を示すか否かを判別する。判別結果がNOであればステップS1に戻る一方、判別結果がYESであれば診断所見リクエストを処理すべくステップS11に進む。
【0034】
ステップS11では、リクエスト元のクライアント端末が放射線診断用クライアント端末20であるか否かを判別する。ステップS13では、リクエスト先のサーバが病理診断所見サーバ40であるか否かを判別する。ステップS19では、リクエスト先のサーバが放射線診断所見サーバ50であるか否かを判別する。これらの判別処理では、処理対象の診断所見リクエストの記載が参照される。
【0035】
ステップS11の判別結果およびステップS13の判別結果のいずれもがYESであれば、ステップS15に進み、ステップS11の判別結果がNOでかつステップS19の判別結果がYESであればステップS21に進む。つまり、ステップS15またはS21の処理は、リクエスト先のサーバが属する診断部門がリクエスト元のクライアント端末が属する診断部門と異なるときに実行される。
【0036】
ステップS15では、処理対象の診断所見リクエストに記載された検査部位名に対応する病理診断用の検査部位名をレジスタRGST1から検出する。ステップS15ではまた、処理対象の診断所見リクエストに記載された検査部位名を検出された病理診断用の検査部位名に変換または置換する。なお、変換または置換はDRAM30rm上で行われ、データベースDB1に登録された診断所見リクエストは登録時の記載のままである。
【0037】
図7(A)に示す診断所見リクエストが処理対象である場合、放射線診断用の検査部位名は“頭部”であるため、ステップS15の処理によって図7(B)に示す診断所見リクエストが作成される。図7(B)によれば“頭部”が“鼻咽喉”,“鼻腔”,“歯”に変換される。
【0038】
また、図8(A)に示す診断所見リクエストが処理対象である場合、放射線診断用の検査部位名は“胸部”であるため、ステップS15の処理によって図8(B)に示す診断所見リクエストが作成される。図8(B)によれば“胸部”が“肺”,“胸腔”,“乳腺”に変換される。
【0039】
ステップS21では、処理対象の診断所見リクエストに記載された検査部位名に対応する放射線診断用の検査部位名をレジスタRGSTから検出する。ステップS21ではまた、処理対象の診断所見リクエストに記載された検査部位名を検出された放射線診断用の検査部位名に変換または置換する。ここでも、変換または置換はDRAM30rm上で行われ、データベースDB1に登録された診断所見リクエストは登録時の記載のままである。
【0040】
図9(A)に示す診断所見リクエストが処理対象である場合、病理診断用の検査部位名は“鼻咽頭”であるため、ステップS21の処理によって図9(B)に示す診断所見リクエストが作成される。図9(B)によれば“鼻咽頭”が“頭部”に変換される。
【0041】
図10(A)に示す診断所見リクエストが処理対象である場合、病理診断用の検査部位名は“鼻腔”であるため、ステップS21の処理によって図10(B)に示す診断所見リクエストが作成される。図10(B)によれば“鼻腔”が“頭部”に変換される。
【0042】
図11(A)に示す診断所見リクエストが処理対象である場合、病理診断用の検査部位名は“歯”であるため、ステップS21の処理によって図11(B)に示す診断所見リクエストが作成される。図11(B)によれば“歯”が“頭部”に変換される。
【0043】
図12(A)に示す診断所見リクエストが処理対象である場合、病理診断用の検査部位名は“肺”であるため、ステップS21の処理によって図12(B)に示す診断所見リクエストが作成される。図12(B)によれば“肺”が“胸部”に変換される。
【0044】
図13(A)に示す診断所見リクエストが処理対象である場合、病理診断用の検査部位名は“胸腔”であるため、ステップS21の処理によって図13(B)に示す診断所見リクエストが作成される。図13(B)によれば“胸腔”が“胸部”に変換される。
【0045】
図14(A)に示す診断所見リクエストが処理対象である場合、病理診断用の検査部位名は“乳腺”であるため、ステップS21の処理によって図14(B)に示す診断所見リクエストが作成される。図14(B)によれば“乳腺”が“胸部”に変換される。
【0046】
ステップS15の処理が終了するか、或いはステップS11の判別結果およびステップS19の判別結果のいずれもがNOであれば、ステップS17に進む。また、ステップS21の処理が終了するか、或いはステップS11の判別結果がYESでかつステップS13の判別結果がNOであれば、ステップS23に進む。
【0047】
ステップS17では、処理対象の診断所見リクエストを病理診断所見サーバ40に回送または転送する。ステップS19からステップS17に移行した場合は、変換前の診断所見リクエストが病理診断所見サーバ40に回送される。これに対して、ステップS15からステップS17に移行した場合は、変換後の診断所見リクエストが病理診断所見サーバ40に回送される。
【0048】
ステップS23では、処理対象の診断所見リクエストを放射線診断所見サーバ50に回送または転送する。ステップS13からステップS23に移行した場合は、変換前の診断所見リクエストが放射線診断所見サーバ50に回送される。これに対して、ステップS21からステップS23に移行した場合は、変換後の診断所見リクエストが放射線診断所見サーバ50に回送される。
【0049】
ステップS25では、回送先のサーバから回答を受信したか否かを繰り返し判別する。判別結果がNOからYESに更新されると、受信した回答が“探知”および“非探知”のいずれであるかをステップS27で判別する。
【0050】
受信した回答が“探知”であればステップS29に進み、処理対象の診断所見リクエストとこれに付随して登録された実行タイミングをデータベースDB1から削除する。これに対して、受信した回答が“非探知”であればステップS31に進み、処理対象の診断所見リクエストに付随して登録された実行タイミングを更新する。更新後の実行タイミングは、たとえば現在時刻よりも10分先の時刻を示す。ステップS29またはS31の処理が完了すると、ステップS1に戻る。
【0051】
病理診断所見サーバ40に設けられたCPU40prの動作は、図17に示すフロー図に従う。まず、リクエスト処理サーバ30から診断所見リクエストを受信したか否かをステップS41で繰り返し判別する。判別結果がNOからYESに更新されると、ステップS43に進み、受信した診断所見リクエストに適合する診断所見をHDD40drに設けられたデータベースDB2から探索する。探索にあたっては、DRAM40rmが使用される。ステップS45では少なくとも1つの診断所見が探知されたか否かを判別し、判別結果がYESであればステップS47に進む一方、判別結果がNOであればステップS51に進む。
【0052】
ステップS47では、“探知”を示す回答を作成し、作成した回答をリクエスト処理サーバ30に返送する。ステップS49では、探知された診断所見のURLが記載されたメール作成し、作成したメールを指定アドレス(=診断所見リクエストに記載された通知先メールアドレス)に返送する。一方、ステップS51では、“非探知”を示す回答を作成し、作成した回答をリクエスト処理サーバ30に返送する。ステップS49またはS51の処理が完了すると、ステップS41に戻る。
【0053】
図18を参照して、ステップS61では、リクエスト処理サーバ30から診断所見リクエストを受信したか否かを繰り返し判別する。判別結果がNOからYESに更新されると、ステップS63に進み、受信した診断所見リクエストに適合する診断所見をHDD50drに設けられたデータベースDB3から探索する。探索にあたっては、DRAM50rmが使用される。ステップS65では少なくとも1つの診断所見が探知されたか否かを判別し、判別結果がYESであればステップS67に進む一方、判別結果がNOであればステップS71に進む。
【0054】
ステップS67では、“探知”を示す回答を作成し、作成した回答をリクエスト処理サーバ30に返送する。ステップS69では、探知された診断所見のURLが記載されたメール作成し、作成したメールを指定アドレス(=診断所見リクエストに記載された通知先メールアドレス)に返送する。一方、ステップS71では、“非探知”を示す回答を作成し、作成した回答をリクエスト処理サーバ30に返送する。ステップS69またはS71の処理が完了すると、ステップS61に戻る。
【0055】
以上の説明から分かるように、病理診断用クライアント端末10および病理診断所見サーバ40は病理診断部門に属し、放射線診断用クライアント端末20および放射線診断所見サーバ50は放射線診断部門に属する。リクエスト処理サーバ30に設けられたHDD30drには、病理診断部門・放射線診断部門間での検査部位名の対応関係が記憶されたレジスタRGST1が備えられる。リクエスト処理サーバ30に設けられたCPU30prは、病理診断用クライアント端末10または放射線診断用クライアント端末20から発行された診断所見リクエストを病理診断所見サーバ40または放射線診断所見サーバ50に回送するべく、以下の処理を実行する。なお、診断所見リクエストには、所望の検査部位名が記述される。
【0056】
CPU30prはまず、リクエスト先のサーバが属する診断部門がリクエスト元のクライアント端末が属する診断部門と異なるとき、診断所見リクエストに記述された検査部位名をレジスタRGST1を参照して変換する(S15, S21)。変換が完了すると、CPU30prは、リクエスト先のサーバに診断所見リクエストを回送する(S17, S23)。
【0057】
したがって、リクエスト元のクライアント端末を操作する医師は、リクエスト先のサーバに保存された診断所見を踏まえて診断を行うことができる。これによって、他の診断部門に属する医師の診断の的確性が向上する。
【符号の説明】
【0058】
10 …病理診断用クライアント端末
20 …放射線診断用クライアント端末
30 …リクエスト処理サーバ
30pr …CPU
DB1 …データベース
RGST1 …レジスタ
40 …病理診断所見サーバ
50 …放射線診断所見サーバ
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18