(57)【要約】【課題】  患者ごとのスレッドの取得要求を、当該患者を対象とした検査の読影を行う医師から受け付けた場合に、当該患者に関するスレッド情報を、当該患者の情報に関するセキュリティを確保しつつ、可能な限り当該医師に提供すること。【解決手段】  医師から、患者に関するスレッドの情報の取得要求を受け付けると、当該患者に関するスレッドの情報を含む画面を生成する。その際、患者に関するスレッドの取得要求が当該患者を対象とした検査の読影を行う医師からの取得要求であれば、患者に関するスレッドのうち当該読影医が関係しないスレッドの情報も含む画面を生成する。【選択図】図５
2016126798.tif 000002
【特許請求の範囲】
【請求項１】
検査を含む患者情報に紐付いて管理されるスレッドと、スレッドごとに閲覧可能なユーザを管理するユーザ情報と、検査に紐付く医師を管理する医師情報と、を記憶する記憶手段と、
医師から、患者情報をキーとしてスレッドの取得要求を受け付ける受付手段と、
前記受付手段で受け付けた患者情報に従って、当該患者情報に紐付くスレッドを前記記憶手段から特定する特定手段と、
前記特定手段で特定されたスレッドが、前記受付手段で取得要求を行った医師が前記記憶手段の前記ユーザ情報により閲覧可能であるとされるスレッドである場合には、スレッドの内容を参照可能な画面を生成する生成手段と
を備え、
前記生成手段は、前記特定手段で特定されたスレッドが、前記受付手段で取得要求を行った医師が前記記憶手段の前記ユーザ情報により閲覧可能でないとされるスレッドである場合にも、前記受付手段で取得要求を行った医師が前記医師情報に含まれる場合には、当該スレッドを識別可能な画面を生成することを特徴とする情報処理システム。
【請求項２】
前記生成手段は、前記特定手段で特定されたスレッドが、前記受付手段で取得要求を行った医師が前記記憶手段の前記ユーザ情報により閲覧可能でないとされるスレッドであり、かつ前記受付手段で取得要求を行った医師が前記医師情報に含まれない場合には、当該スレッドを含まない画面を生成することを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記患者に関するスレッドのうち前記医師が関係しないスレッドの内容を閲覧する要求を当該医師から受け付ける閲覧要求受付手段と、
前記閲覧要求受付手段により前記スレッドの閲覧要求を受け付けた医師に、当該スレッドの内容の参照を許可するか否かの指示を受け付ける閲覧許可指示受付手段と
を更に備え、
前記生成手段は、前記閲覧許可指示受付手段により、前記スレッドの内容の参照を許可する指示を受け付けた場合に、前記閲覧要求受付手段により当該スレッドの内容を閲覧する要求を行った医師が当該スレッドの内容を参照可能な画面を生成することを特徴とする請求項１または２に記載の情報処理システム。
【請求項４】
前記記憶手段は、前記スレッドを作成したスレッド作成ユーザ情報を更に管理し、
前記閲覧許可指示受付手段は、前記記憶手段で記憶する前記スレッド作成ユーザからスレッドの内容の参照を許可するか否かの指示を受け付けることを特徴とする請求項３に記載の情報処理システム。
【請求項５】
検査を含む患者情報に紐付いて管理されるスレッドと、スレッドごとに閲覧可能なユーザを管理するユーザ情報と、検査に紐付く医師を管理する医師情報と、を記憶する記憶手段を備える情報処理システムの制御方法であって、
前記情報処理システムの受付手段が、医師から、患者情報をキーとしてスレッドの取得要求を受け付ける受付工程と、
前記情報処理システムの特定手段が、前記受付工程で受け付けた患者情報に従って、当該患者情報に紐付くスレッドを前記記憶手段から特定する特定工程と、
前記情報処理システムの生成手段が、前記特定工程で特定されたスレッドが、前記受付工程で取得要求を行った医師が前記記憶手段の前記ユーザ情報により閲覧可能であるとされるスレッドである場合には、スレッドの内容を参照可能な画面を生成する生成工程と
を備え、
前記生成工程は、前記特定工程で特定されたスレッドが、前記受付工程で取得要求を行った医師が前記記憶手段の前記ユーザ情報により閲覧可能でないとされるスレッドである場合にも、前記受付工程で取得要求を行った医師が前記医師情報に含まれる場合には、当該スレッドを識別可能な画面を生成することを特徴とする情報処理システムの制御方法。
【請求項６】
コンピュータを、請求項１乃至４のいずれか１項に記載の情報処理システムの各手段として機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
情報処理システム、情報処理システムの制御方法、およびコンピュータプログラムに関し、特に、患者ごとのスレッドの取得要求を、当該患者を対象とした検査の読影を行う医師から受け付けた場合に、当該患者に関するスレッド情報を、当該患者の情報に関するセキュリティを確保しつつ、可能な限り当該医師に提供することが可能な仕組みに関する。
【背景技術】
【０００２】
近年、インターネットに代表される計算機ネットワークの発達に伴い、ネットワークに接続されるサーバ上で様々なサービスが提供されるようになってきており、医療の分野おけるシステムも、インターネットで提供されるようになってきている。
【０００３】
医療の分野では、例えば、ＣＴ（Ｃｏｍｐｕｔｅｄ  Ｔｏｍｏｇｒａｐｈｙ）やＭＲＩ（Ｍａｇｎｅｔｉｃ  Ｒｅｓｏｎａｎｃｅ  Ｉｍａｇｉｎｇ）等といったモダリティ（医用画像生成装置ともいう）で撮影された患者の医用画像のデジタル化が実現されており、医用画像データとしてサーバに格納して保存されている。
【０００４】
通常、サーバに格納された医用画像は、医用画像を読影することができる専門医によって読影されるが、専門医は圧倒的に人員が不足しているため、近年では、撮影した医用画像を、ネットワークを介して、院外の専門医に依頼して読影を行ってもらうシステム（遠隔読影システムとも言う）が普及している。
このような遠隔読影システムでは、患者の情報に関するセキュリティの確保が要求されている。
【０００５】
特許文献１には、遠隔読影システムにおいて、患者の画像データリスト（画像データＩＤ、画像データ撮影日、検査施設ＩＤ、画像モダリティ、検査担当者ＩＤ等の検査情報を含む）から、画像の表示要求を読影医から受け付けた場合に、読影医ごとに設定された医療情報アクセス権に従って、患者の画像データの表示を許可するか否かを決定する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−１９８０４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、上述したような遠隔読影システムにおいて、近年では、読影医が担当する患者の読影結果のレポートを作成する際に、他の読影医との意見交換や、読影センターの事務員に対する依頼などのメッセージのやり取りを行うことができるサービス（いわゆるＳＮＳ）も行われている。
【０００８】
そのようなメッセージのやり取りを行うサービスにおいては、メッセージのやり取りの画面（患者ごとの検査に関するスレッドの情報を含む画面であり、以下、スレッド画面と呼ぶ）の取得要求を、患者を対象とした読影依頼（検査）に対して、当該読影依頼（検査）の読影を担当する読影医（以下、担当読影医と呼ぶ）から受け付けた場合に、当該患者の情報に関するセキュリティを確保しつつ、当該患者に関する情報を、可能な限り当該担当読影医に提供することが可能な当該患者に関するスレッド画面を表示することが求められている。
【０００９】
しかしながら、上述した特許文献１の技術は、患者の画像データリスト（スレッド画面に相当）から、ユーザが選択した画像データを表示する際に、読影医ごとに設定された医療情報アクセス権に従って、患者の画像データの表示を許可するか否かを決定する技術であるため、画像データリストを表示する時点では、担当読影医であるか否かによって、表示する情報は変えていない。つまり、特許文献１の技術を用いたとしても、スレッド画面では、スレッド画面の取得要求を受け付けたユーザが担当読影医であろうがあるまいが、スレッド画面で表示する情報が同じとなることが考えられる。
【００１０】
本発明は、患者ごとのスレッドの取得要求を、当該患者を対象とした検査の読影を行う医師から受け付けた場合に、当該患者に関するスレッド情報を、当該患者の情報に関するセキュリティを確保しつつ、可能な限り当該医師に提供することが可能な仕組みを提供することである。
【課題を解決するための手段】
【００１１】
本発明は、検査を含む患者情報に紐付いて管理されるスレッドと、スレッドごとに閲覧可能なユーザを管理するユーザ情報と、検査に紐付く医師を管理する医師情報と、を記憶する記憶手段と、医師から、患者情報をキーとしてスレッドの取得要求を受け付ける受付手段と、前記受付手段で受け付けた患者情報に従って、当該患者情報に紐付くスレッドを前記記憶手段から特定する特定手段と、前記特定手段で特定されたスレッドが、前記受付手段で取得要求を行った医師が前記記憶手段の前記ユーザ情報により閲覧可能であるとされるスレッドである場合には、スレッドの内容を参照可能な画面を生成する生成手段とを備え、前記生成手段は、前記特定手段で特定されたスレッドが、前記受付手段で取得要求を行った医師が前記記憶手段の前記ユーザ情報により閲覧可能でないとされるスレッドである場合にも、前記受付手段で取得要求を行った医師が前記医師情報に含まれる場合には、当該スレッドを識別可能な画面を生成することを特徴とする。
【００１２】
また、本発明は、検査を含む患者情報に紐付いて管理されるスレッドと、スレッドごとに閲覧可能なユーザを管理するユーザ情報と、検査に紐付く医師を管理する医師情報と、を記憶する記憶手段を備える情報処理システムの制御方法であって、前記情報処理システムの受付手段が、医師から、患者情報をキーとしてスレッドの取得要求を受け付ける受付工程と、前記情報処理システムの特定手段が、前記受付工程で受け付けた患者情報に従って、当該患者情報に紐付くスレッドを前記記憶手段から特定する特定工程と、前記情報処理システムの生成手段が、前記特定工程で特定されたスレッドが、前記受付工程で取得要求を行った医師が前記記憶手段の前記ユーザ情報により閲覧可能であるとされるスレッドである場合には、スレッドの内容を参照可能な画面を生成する生成工程とを備え、前記生成工程は、前記特定工程で特定されたスレッドが、前記受付工程で取得要求を行った医師が前記記憶工程の前記ユーザ情報により閲覧可能でないとされるスレッドである場合にも、前記受付工程で取得要求を行った医師が前記医師情報に含まれる場合には、当該スレッドを識別可能な画面を生成することを特徴とする。
【発明の効果】
【００１３】
本発明によると、患者ごとのスレッドの取得要求を、当該患者を対象とした検査の読影を行う医師から受け付けた場合に、当該患者に関するスレッド情報を、当該患者の情報に関するセキュリティを確保しつつ、可能な限り当該医師に提供することが出来る。
【図面の簡単な説明】
【００１４】
【図１】遠隔読影システムの構成の一例を示すシステム構成図。
【図２】依頼端末１０９、読影端末１１２〜１１４、各サーバ１０１〜１０７、１１６に適用可能な情報処理装置としてのコンピュータのハードウェア構成図。
【図３】ＰＣ３０１に表示されるレポート作成画面４０１の一例を示す図。
【図４】データベース１０８で管理されるレポートデータ４００の一例を示す図。
【図５】ＰＣ３０１に表示されるスレッド一覧画面５０１の一例を示す図。
【図６】データベース１０８で管理されるスレッドデータ６００の一例を示す図。
【図７】ＰＣ３０１に表示されるスレッド詳細画面７０１の一例を示す図。
【図８】データベース１０８で管理されるスレッドメッセージデータ８００の一例を示す図。
【図９】ＰＣ３０１に表示されるスレッド参加依頼画面９０１の一例を示す図。
【図１０】データベース１０８で管理されるユーザデータ１００の一例を示す図。
【図１１】データベース１０８で管理される患者データ１１０の一例を示す図
【図１２】ＰＣ３０１にスレッドの一覧画面を表示するフローチャートの一例を示す図。
【図１３】ステップＳ１２０４の処理の詳細を示すフローチャートの一例を示す図。
【図１４】ステップＳ１２０５の処理の詳細を示すフローチャートの一例を示す図。
【図１５】ステップＳ１２０６の処理の詳細を示すフローチャートの一例を示す図。
【図１６】ステップＳ１２１１の処理の詳細を示すフローチャートの一例を示す図。
【図１７】ステップＳ１２１３の処理の詳細を示すフローチャートの一例を示す図。
【発明を実施するための形態】
【００１５】
以下、図面を参照して、本発明の実施形態を詳細に説明する。なお、以下説明する実施形態は、本発明を具体的に実施した場合の一例を示すもので、特許請求の範囲に記載した構成の具体的な実施例の１つである。
【００１６】
図１は、遠隔読影システムの構成の一例を示すシステム構成図である。
本実施形態に係る遠隔読影システムは、読影を依頼する側である病院等の医療機関（依頼施設）と、依頼された読影を行ってその結果を返す機関である読影センターと、医療機関（依頼施設）と読影センターとの仲介を担うデータセンターと、のそれぞれの機関における機器により構成されるものである。
【００１７】
それぞれの機関における機器は、インターネットなどのネットワーク１１７に接続されており、該ネットワーク１１７を介して互いにデータ通信を行うことができる（通信可能）。
まず、依頼施設における機器について説明する。
【００１８】
１０９は、読影を依頼する依頼施設の医師が使用する依頼端末である。依頼施設の読影依頼担当者は、依頼端末１０９を用いて、読影依頼情報を入力する。入力された依頼情報は遠隔読影サーバ１０１で処理され、依頼情報はデータベース１０８に保管される。
【００１９】
遠隔読影に用いる画像データは、モダリティ１１１から端末機器１１０に送信され、端末機器１１０は、モダリティ１１１から送信されてきた画像データをアーカイブしてから、データセンターの受信サーバ１０７に送信する。
【００２０】
モダリティ１１１から送信されてきた画像データは、受信サーバ１０７で処理され、ストレージ管理サーバ１０５に送られる。
【００２１】
ストレージ管理サーバで１０５では、画像データに対してユニークなＩＤを発行し、画像データを外部記憶装置１１５に保管する。
次に、読影センターについて説明する。
【００２２】
１１２、１１３は、読影端末であり、依頼施設から読影の依頼を受けた読影センターの読影医は、読影端末１１２、１１３で、配信サーバ１０６を用いて外部記憶装置１１５からダウンロードした読影用の画像を参照し、読影した結果のレポートを、読影端末１１２、１１３上で動作するレポート用アプリケーション（レポートクライアントとも呼ぶ）を用いて作成する。作成したレポートは、レポートサーバ１０３で処理され、データベース１０８に保管される。また読影医は、読影医の自宅にある読影端末１１４からも、システムを利用することができる。
【００２３】
なお、図３以降の説明では、依頼端末１０９、読影端末１１２〜１１４をまとめて、ＰＣ３０１と呼ぶ。
【００２４】
本読影システムでは、遠隔読影システムを利用するユーザの指示に従って、依頼端末１０９、読影端末１１２〜１１４からのアクセス要求を受け付けると、ネットワーク１１７を介して、データセンターの認証サーバ１１６によりユーザの認証が行われる。
【００２５】
認証通過後、依頼端末１０９、読影端末１１２〜１１４の画面に、ポータルサーバ１０２が提供する、読影の状況や、メインメニューを備えたポータル画面が表示される。
【００２６】
また、読影医は、読影端末１１２〜１１４から、データセンターのＳＮＳ（いわゆるソーシャルネットワーキングサービスのことであり、ユーザ同士がメッセージをやり取りすることが出来るＷＥＢサイトのこと）サーバ１０４にアクセスすることで、レポートを作成する際に、読影端末１１３から他の読影医との意見交換、また、読影センターの事務員に対する依頼などのメッセージのやり取りを行うことができる。
【００２７】
なお、メッセージのやり取りは、参加者、タイトル、各メッセージを一纏めにした、「スレッド」という単位で、ＳＮＳサーバ１０４で処理される。スレッドの内容はデータベース１０８に保管される。
【００２８】
ＳＮＳを利用するユーザは、読影の依頼を行う依頼病院の医師、読影を行う読影医、依頼病院からの読影依頼を読影医に振り分ける読影センターの事務員等である。
本発明に関係するサーバはＳＮＳサーバ１０４と、データベース１０８である。
【００２９】
なお、本実施例では、画像を管理するサーバやＳＮＳを管理するサーバなどを別々のサーバとしたが、他の実施例として、１０１〜１０７、１１６の各サーバが行う処理を１つのサーバで行っても良い。
【００３０】
次に、図２を用いて、依頼端末１０９、読影端末１１２〜１１４、各サーバ１０１〜１０７、１１６に適用可能な情報処理装置としてのコンピュータのハードウェア構成例について、図２のブロック図を用いて説明する。
なお、図２に示した構成は一例であり、後述する各処理を実現可能な構成であれば、如何なる構成を採用しても構わない。
【００３１】
図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  ／  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。
【００３２】
２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。
【００３３】
また、２０５は入力コントローラで、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。２０６はビデオコントローラで、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。なお、表示器はＣＲＴだけでなく、液晶ディスプレイ等の他の表示器であってもよい。これらは必要に応じて管理者が使用するものである。
【００３４】
２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。
【００３５】
２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したネットワーク１１７）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。
【００３６】
なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３７】
本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明も後述する。
【００３８】
では、ここから、本発明において、ＰＣ３０１のディスプレイ２１０に表示される各画面について説明する。
まず、図３について説明する。
【００３９】
図３は、本発明において、ＰＣ３０１に表示されるレポート作成画面３００の一例を示す図であり、読影医は、レポート作成画面３００から、読影結果のレポートを作成する。
【００４０】
３０２は、ワークリストであり、データベース１０８で管理する図４のレポートデータの４０６から、遠隔読影システムにログインした読影医が読影の担当となっている読影依頼を検索し、検索の結果によって得られる当該読影医が担当となっている読影依頼の一覧が表示される。
【００４１】
読影医は、ある患者を対象とした検査の読影依頼に対する読影を行う場合には、当該読影依頼の担当読影として、読影依頼に紐付いて後述する図４のデータテーブルで管理される。
【００４２】
ワークリスト３０２において、読影医がレポートを選択すると３０４に依頼の詳細が表示される。また、ワークリスト３０２において、読影医がレポートを選択し、マウス等を操作して患者スレッドボタン３０３を押下すると、ＰＣ３０１からＳＮＳサーバ１０４に、当該患者を対象とした読影依頼（検査）に対して、当該読影依頼（検査）の読影を担当する担当読影医であるということを示す情報を含むスレッド一覧表示のリクエストが送信され、ＳＮＳサーバから図５のスレッド一覧画面が送信され、ＰＣ３０１に表示される。
【００４３】
図４は、データベース１０８で管理されるレポートデータ４００の一例を示す図である。
レポートデータ４００は、依頼施設から読影依頼が読影センターに届いたときに、読影センターで読影医に読影依頼を割り当てることにより作成される。
【００４４】
レポートデータ４００には、レポートを識別する情報である「レポートＩＤ」４０１、読影の依頼を行った依頼施設の名前を示す「依頼施設名」４０２、読影の依頼を識別する「依頼Ｎｏ」４０３、読影の依頼の対象である患者の名前を示す「患者名」４０４、現在の読影のステータスを示す「ステータス」４０５、そして読影依頼（検査）の読影を担当する読影医の名前を示す「担当読影医」４０６（検査に紐付く医師を管理する医師情報）が紐付けて記憶される。
【００４５】
図５は、本発明において、ＰＣ３０１に表示されるスレッド一覧画面５０１の一例を示す図である。スレッド一覧画面５０１は、ＰＣ３０１に表示されたレポート作成画面３００で、読影医がマウス等を操作して患者スレッドボタン３０３を押下することにより、ＰＣ３０１に表示される。
【００４６】
図５のスレッド一覧画面５０１は、読影医であるユーザ「読影太郎」が、レポート作成画面３００で、ワークリスト３０２から「患者Ａ」のレポートを選択して、患者スレッドボタン３０３を押下したときの表示例である。
【００４７】
なお、スレッド一覧画面５０１は、データベース１０８で管理される図６のスレッドデータ６００に基づいてＳＮＳサーバ１０４で生成される。
【００４８】
具体的には、まず、図６のスレッドデータ６００の患者名６０９が、患者Ａであるスレッドを特定する。次に患者Ａのスレッドのうち、スレッドオーナー６０３、または、参加者６０４に読影太郎が含まれるスレッドを５０２に表示し、患者Ａのスレッドのうち、スレッドオーナー６０３、または、参加者６０４に読影太郎が含まれないスレッドを５０２に表示するようにスレッド一覧画面５０１を生成する。
【００４９】
５０２には、スレッドデータ６００に含まれるスレッドのうち、患者Ａに関するスレッド、かつ読影太郎がスレッドオーナー（スレッドの作成者）、もしくは参加者であるスレッド（閲覧可能スレッドや、参加スレッドとも呼ぶ）が一覧で表示される（スレッドデータ６００内のスレッドＩＤ１、９、１０のスレッド）。
【００５０】
５０４はスレッドのタイトルである。タイトル５０４は、リンクになっており、タイトル５０４が読影医によるマウス等の操作によりクリックされると、図７のスレッド詳細画面７０１が表示される。
【００５１】
５０３には、読影太郎が、スレッドオーナーにも参加者にも含まれていないが、患者Ａに関するスレッド（閲覧権限のないスレッドや、未参加スレッドとも呼ぶ）が一覧で表示される（スレッドデータ６００内のスレッドＩＤ２、５のスレッド）。
【００５２】
５０３に含まれるスレッドについては、タイトルはリンクになっておらず、スレッドの詳細は閲覧することが出来ない。スレッドの詳細を閲覧するには、５０７の参加依頼ボタンが、読影医によるマウス等の操作によりクリックされ、その後スレッドオーナーによって参加が承認される必要がある。
【００５３】
ただ、患者Ａを対象とした読影依頼の担当読影医に、当該担当読影医が参加していないスレッドのタイトルを見せることにより、当該担当読影医に患者Ａに関して他にもメッセージのやり取りがされていることを認識させ、当該担当読影医が参加していない患者Ａのスレッドへ誘導することが出来るという効果を得ることが出来る。
【００５４】
また、当該担当読影医が参加していないスレッドについては、スレッドオーナーにより承認されなければ詳細を閲覧させないことで、患者の個人情報の開示範囲を的確に管理することができる。つまり、患者の個人情報の保護という点においてセキュリティを高めることが出来る。
【００５５】
なお、ここまで、スレッド一覧画面５０１が、ＰＣ３０１に表示されたレポート作成画面３００で、読影医がマウス等を操作して患者スレッドボタン３０３を押下することにより、ＰＣ３０１に表示される例について説明してきたが、スレッド一覧画面５０１は、ポータル画面から、スレッド検索画面（図５の５０６だけが表示された画面）を表示させ、スレッド検索画面の検索項目の入力欄から患者名当により検索を実行することで、担当読影医以外のユーザ（事務員や担当読影医以外の読影医等）であっても、患者のスレッドを検索することが出来る。
【００５６】
その場合、検索を実行したユーザが参加しているスレッドのみスレッド一覧画面５０１に表示される。つまり、５０３は表示されない。
【００５７】
なぜなら、検索の対象となっている患者を対象とした読影依頼（検査）の担当読影医にとっては、当該患者の読影をする上で、当該患者について他のスレッドでどのようなメッセージがやり取りされているかという情報が必要になることが考えられるが、当該患者を対象とした読影依頼（検査）の担当読影医以外のユーザにとっては、当該患者について他のスレッドでどのようなメッセージがやり取りされているかという情報が必要になる可能性が低く、当該ユーザが参加しているスレッド以外のスレッドの情報を当該ユーザに見せることは、患者の個人情報の保護という点において好ましくないと考えられるからである。
【００５８】
なお、スレッド検索画面から、患者のスレッドの検索を行った場合には、担当読影医か否かに関わらず５０３は表示しないとしても良いが、５０３を表示することにより得られる上述の効果をかんがみると、担当読影医が、スレッド検索画面から、担当となっている患者を検索した場合には、５０３は表示されても良い。その場合、スレッド検索画面（図５の５０６だけが表示された画面）から、患者のスレッドの検索を行ったユーザ（遠隔読影システムにログインしているユーザ）が当該患者を対象とした読影依頼（検査）の担当読影医であるかどうかは、データベース１０８で管理される図４のレポートデータ４００、および図６のスレッドデータ６００に基づいてＳＮＳサーバで判断され、図５のスレッド一覧画面５０１が生成される。
【００５９】
具体的には、図４のレポートデータ４００の患者名４０４を参照することで、表示の対象となっている患者のレポートを特定し、次に、当該患者を対象とした依頼の担当読影医４０６に検索を行ったユーザ（遠隔読影システムにログインしているユーザ）が含まれていれば５０３を表示する。もしくは、図６のスレッドデータ６００から表示の対象となっている患者のスレッドを特定し、特定されたスレッドのいずれかの関連依頼ＩＤ６０７と一致する図４のレポートデータ４００の依頼Ｎｏ４０３の担当読影医４０６に、検索を行ったユーザ（遠隔読影システムにログインしているユーザ）が含まれていれば５０３を表示するとしてもよい。
【００６０】
なお、本実施例では、図４のレポートデータ４００を用いて、患者の担当読影か否かを特定するとしたが、他の実施例として、後述する図１１の患者データに、当該患者を対象とした読影依頼（検査）の担当読影医の情報を紐付けて記憶させ、図１１の患者データから、当該患者を対象とした読影依頼（検査）の担当読影医であるか否かを判断しても良い。
次に、図５の画面を生成するために用いられるデータについて、図６を用いて説明する。
【００６１】
図６は、データベース１０８で管理されるスレッドデータ６００の一例を示す図である。
【００６２】
スレッドデータ６００にはスレッドを識別する情報であるスレッドＩＤ６０１、スレッドのタイトルを示すスレッドタイトル６０２、スレッドを作成したユーザ（スレッドのオーナー）を示すスレッドオーナー６０３、スレッドに参加しているユーザ（参加依頼が承認されたユーザを含む）を示す参加者６０４（スレッドごとに閲覧可能なユーザを管理するユーザ情報）、図５の５０４を押下することでスレッドの参加依頼を行っているユーザを示す参加依頼中６０５、スレッドのオーナーからスレッドの参加を拒否されたユーザを示す参加否認６０６、当該スレッドに関連する依頼データのＩＤ、依頼施設の名称、対象患者の名称が含まれる。
【００６３】
ここで、本発明における「スレッド」の定義について説明する。本発明における「スレッド」とは、電子掲示板（本実施例ではＳＮＳサーバ１０４が提供する図５のスレッド一覧画面５０１および、スレッド詳細画面７０１のこと）における、ある特定の話題に関する投稿の集まりのことを示す。図６のスレッドデータ６００のスレッドＩＤ６０１が「８」の行を例にすると、事務員Ａが作成した「所見変更依頼」という話題のスレッドに対して、参加者６０４に示すユーザから返信を受け付けたり、その返信に対して更に返信を受け付けたりすることで、所見変更依頼という話題のスレッドが形成される。なお、スレッドは、検査を含む患者情報に紐付いている。
【００６４】
データベース１０８で管理される図４のレポートデータ４００と、図６のスレッドデータ６００は、検査を含む患者情報に紐付いて管理されるスレッドと、スレッドごとに閲覧可能なユーザを管理するユーザ情報と、検査に紐付く医師を管理する医師情報と、を記憶する記憶手段の一例である。
【００６５】
図５の５０２には、図６のスレッドデータ６００のうち、患者名６０９が表示の対象となっている患者であり、かつ表示の要求を行ったユーザ（遠隔読影システムにログインしているユーザ）がスレッドオーナー６０３もしくは参加者６０４に含まれるスレッドが表示される。
【００６６】
図５の５０３には、図６のスレッドデータ６００のうち、患者名６０９が表示の対象となっている患者であり、かつ表示の要求を行ったユーザ（遠隔読影システムにログインしているユーザ）がスレッドオーナー６０３もしくは参加者６０４に含まれないスレッドが表示される。
【００６７】
次に、図５のスレッド一覧画面５０１で、タイトル５０４が読影医のマウス等の操作により押下されることにより、ＰＣ３０１に表示される画面について図７を用いて説明する。
【００６８】
図７は、本発明において、ＰＣ３０１に表示されるスレッド詳細画面７０１の一例を示す図である。スレッド詳細画面７０１は、ＰＣ３０１に表示された図５のスレッド一覧画面５０１で、読影医がマウス等を操作してタイトル５０４を押下することにより、ＰＣ３０１に表示される。
【００６９】
スレッド詳細画面７０１は、データベース１０８で管理される図８のスレッドメッセージデータ８００に基づいてＳＮＳサーバ１０４で生成される。
【００７０】
７０２は、メッセージ表示部である。メッセージ表示部７０２には、スレッド上で交わされた１件１件のメッセージが、メッセージを書き込んだユーザ名や日時とともに表示される。
【００７１】
７０３は参加依頼の承認・拒否ボタンである。参加依頼の承認・拒否ボタン７０３は、スレッドへの参加依頼があった場合に表示される参加依頼を承認・拒否するためのボタンである。また、７０３の左側には、参加依頼メッセージが表示される。
【００７２】
承認・拒否ボタン７０３のうち、承認ボタンがユーザによるマウス等の操作に従って押下されると、図６の当該スレッドの参加者６０４に当該ユーザが追加される。
【００７３】
承認・拒否ボタン７０３のうち、拒否ボタンがユーザによるマウス等の操作に従って押下されると、図６の当該スレッドの参加否認６０６に当該ユーザが追加される。
なお、参加依頼の承認・拒否のボタンは、スレッドオーナーがスレッド詳細画面７０１を表示した場合のみ表示される。
７０４は、メッセージ入力欄であり、メッセージを入力することが出来る。
次に、図７の画面を生成するために用いられるデータについて、図８を用いて説明する。
【００７４】
図８は、データベース１０８で管理されるスレッドメッセージデータ８００の一例を示す図である。スレッドメッセージデータ８００には、メッセージＩＤ８０１、スレッドＩＤ８０２、ユーザ名８０３、メッセージテキスト８０４が紐付いて管理されている。
【００７５】
８０１は、メッセージを識別するためのメッセージＩＤである。８０２は、当該メッセージが、どのスレッドのメッセージであるかを示すスレッドＩＤ８０２である。
【００７６】
８０３は、当該メッセージを作成したユーザの名前を示すユーザ名８０３である。８０４は、当該メッセージの内容を示す。
【００７７】
図７のスレッド詳細画面７０１には、ＰＣ３０１に表示された図５のスレッド一覧画面５０１で、読影医がマウス等を操作することにより押下されたタイトル５０４のスレッドＩＤと一致するスレッドＩＤ８０２のメッセージテキスト８０４が表示される。
【００７８】
次に、図５のスレッド一覧画面５０１で、参加依頼ボタン５０７が読影医のマウス等の操作により押下されることにより、ＰＣ３０１に表示される画面について図９を用いて説明する。
【００７９】
図９は、本発明において、ＰＣ３０１に表示されるスレッド参加依頼画面９０１の一例を示す図である。スレッド参加依頼画面９０１は、ＰＣ３０１に表示された図５のスレッド一覧画面５０１で、読影医がマウス等を操作して参加依頼ボタン５０７を押下することにより、ＳＮＳサーバ１０４で生成されＰＣ３０１に表示される。
【００８０】
スレッド参加依頼画面９０１には、読影医によるマウス等の操作により参加依頼ボタン５０７が押下されたスレッドのタイトルや、関連する患者の情報を表示する情報表示部９０２と、参加依頼の際にスレッドのオーナーに送付するメッセージを入力することができる、メッセージ入力部９０３が備えられている。
【００８１】
スレッドに参加したいユーザは、メッセージ入力部９０３に参加依頼のメッセージを入力後、送信ボタン９０４を押下して、参加依頼メッセージをＳＮＳサーバ１０４に送信する。
【００８２】
ＳＮＳサーバ１０４は、参加依頼メッセージを受信すると、図６のスレッドデータ６００の６０５に参加依頼メッセージを送信したユーザを追加し、さらに、スレッドメッセージデータ８００に、受信した参加依頼メッセージを、参加依頼メッセージが送信されたスレッドのスレッドＩＤを付与して登録する。
次に、データベース１０８で管理されるその他のデータについて、図１０、図１１を用いて説明する。
【００８３】
図１０は、データベース１０８で管理されるユーザデータ１００の一例を示す図である。
ユーザデータ１００には、ユーザ一人一人に設定するユーザＩＤと、ユーザ名称、および、システムに対するユーザの役割が含まれている。
【００８４】
図１１は、データベース１０８で管理される患者データ１１０の一例を示す図である。
患者データ１１０には、患者が属している依頼施設のＩＤと、依頼施設が患者に付与したＩＤ、および患者名が含まれている。
【００８５】
なお、通常患者ＩＤは、通常同一患者であっても依頼病院ごとに異なるが、マイナンバーなどの仕組みを導入することにより、依頼施設が異なっても、同一の患者であれば同じ患者ＩＤを付与しても良い。
では、ここから、本発明においてＰＣ３０１、または、ＳＮＳサーバ１０４において実行される各処理について説明する。
【００８６】
図１２は、本発明において、ＰＣ３０１にスレッドの一覧画面を表示するフローチャートの一例を示す図である。
図１２に示すフローチャートに示す各ステップの処理、および図１２のサブフローである図１３〜図１７は、ＰＣ３０１、またはＳＮＳサーバ１０４のＣＰＵ２０１が外部メモリ２１１に格納されるプログラムをＲＡＭ２０３にロードして実行することにより実現される。
【００８７】
なお、図１２の処理を実行する前に、ＰＣ３０１において、遠隔読影システムにログインするための情報（ユーザＩＤやパスワード等）の入力をユーザから受け付け、その情報を用いてログイン処理を行っているものとする。
【００８８】
ステップＳ１２０１において、ＰＣ３０１は、ＰＣ３０１のディスプレイ２１０に表示された図３のレポート作成画面３００のワークリスト３０２から、対象のレポートの選択を受け付けた後、患者スレッドボタン３０３が読影医のマウス等の操作により押下される、または、スレッド検索画面で、ユーザから患者名によるスレッド検索要求を受け付けると、当該患者のスレッド一覧取得の要求をＳＮＳサーバ１０４に送信する。
【００８９】
患者のスレッド一覧の取得の要求にはスレッドの一覧を表示する患者の患者名および、スレッド一覧取得要求を実行したユーザの情報が含まれている。以下の実施例の説明では、患者Ａのスレッドを検索するものとする。
【００９０】
ステップＳ１２０１は、本発明における、医師から、患者情報をキーとしてスレッドの取得要求を受け付ける受付手段の一例である。
【００９１】
ステップＳ１２０２において、ＰＣ３０１からの患者のスレッド一覧要求を受信したＳＮＳサーバ１０４は、患者のスレッド一覧取得要求の中身を解析する。
【００９２】
ステップＳ１２０３において、ＳＮＳサーバ１０４は、患者のスレッド一覧取得要求が、当該患者を対象とした読影依頼（検査）の担当読影医からのものかどうかを判断する。患者のスレッド一覧取得要求が担当読影医からのものであれば、ステップＳ１２０４において、当該患者のスレッドのうち、スレッド一覧取得要求を行った担当読影医が未参加スレッドを含むスレッド検索が実行され、患者のスレッド一覧取得要求が担当読影医からのものでなければ、ステップＳ１２０５において、当該患者のスレッドのうち、スレッド一覧取得要求を行ったユーザが参加する参加スレッド検索が実行される。検索結果はＲＡＭ２０３に保管される。
【００９３】
ステップＳ１２０４の処理の詳細は、後述する図１３を用いて説明する。また、ステップＳ１２０５の処理の詳細は、後述する図１４を用いて説明する。
【００９４】
ステップＳ１２０３において、患者のスレッド一覧取得要求が担当読影医からのものであるとＳＮＳサーバ１０４が判断する場合は、図５で説明したとおりである。具体的には、４つの方法が考えられる。１つ目は、図４のレポートデータ４００に基づいて作成されるワークリストからレポートを選択した後に、図３の患者スレッドボタン３０３が押下されることにより、患者のスレッド一覧取得要求がされた場合には、担当読影医であると判断し（ワークリストには、当該読影医が担当読影医であるレポートしか表示されないため）、スレッド検索画面から患者のスレッド一覧取得要求がされた場合に、担当読影医ではないと判断する方法である。
【００９５】
２つ目は、スレッド検索画面から、ある患者のスレッド一覧取得要求がされた場合に、図４のレポートデータ４００を検索（具体的には患者名４０４を参照）することで、当該患者を対象としたレポートを特定する。そして、特定されたレポートの担当読影医４０６を参照し、担当読影医４０６に、当該スレッド一覧取得要求を行ったユーザが含まれる場合に、当該ユーザを担当読影医として特定する方法である。
【００９６】
３つ目は、２つ目の方法に加えて、図４のレポートデータ４００に基づいて作成されるワークリストからレポートを選択した後に、図３の患者スレッドボタン３０３が押下されることにより、患者のスレッド一覧取得要求がされた場合には、担当読影医であると判断する方法である。
４つ目は、ある患者のスレッド一覧取得要求がされた場合に、図６のスレッドデータ６００を検索（具体的には患者名６０９を参照）することで、当該患者のスレッドを特定する。次に、特定されたスレッドのいずれかの関連依頼ＩＤ６０７と一致する図４のレポートデータ４００（具体的には、依頼Ｎｏ４０３が関連依頼ＩＤ６０７と一致するレポートデータ）を特定する。そして、特定されたレポートデータの担当読影医４０６に、スレッド一覧取得要求を行ったユーザが含まれている場合に担当読影医と判断する方法である。
【００９７】
ステップＳ１２０６において、ＳＮＳサーバ１０４は、検索結果データをもとに図５のスレッド一覧画面を生成し、図５のスレッド一覧画面をＰＣ３０１に送信する。ステップＳ１２０６の処理の詳細は、後述する図１５を用いて説明する。
【００９８】
ステップＳ１２０７において、ＰＣ３０１は、ＳＮＳサーバ１０４から送信された図５のスレッド一覧画面を、ＰＣ３０１のディスプレイ２１０に表示する。
【００９９】
ステップＳ１２０８において、ＰＣ３０１は、図５のスレッド一覧画面を介して、ユーザから操作を受け付けたかを判断する。ユーザから操作を受け付けたならば、ステップＳ１２０９に進み、ユーザから操作を受け付けなければ、ユーザから操作を受け付けるまで待機する。
【０１００】
ステップＳ１２０９において、ＰＣ３０１は、図５のスレッド一覧画面を介して、ユーザから受け付けた操作の内容をＳＮＳサーバ１０４に送信する。
【０１０１】
ＰＣ３０１から、ユーザ操作の内容を受け取ったＳＮＳサーバ１０４は、ステップＳ１２１０、ステップＳ１２１２、ステップＳ１２１４で操作内容を判断する。
【０１０２】
参加依頼ボタン（図５の５０７）が押下された場合には（ステップＳ１２１０でＹＥＳ）、ステップＳ１２１１の参加依頼処理が実行される。ステップ１２１１の処理の詳細は、後述する図１６を用いて説明する。ステップＳ１２１１の処理が終了すると、ステップＳ１２０８に戻る。
【０１０３】
スレッド一覧画面のスレッドタイトルのリンク（図５の５０４）が押下された場合には（ステップＳ１２１２でＹＥＳ）、ステップＳ１２１３のメッセージ表示処理が実行される。ステップ１２１３の処理の詳細は、後述する図１７を用いて説明する。ステップＳ１２１３の処理が終了すると、ステップＳ１２０８に戻る。
【０１０４】
前記２つの操作以外で、終了指示以外の操作が行われた場合は、ステップＳ１２１５のその他処理が実行される。ステップＳ１２１５の処理が終了すると、ステップＳ１２０８に戻る。
【０１０５】
終了指示がされた場合には（ステップＳ１２１４でＹＥＳ）、本処理を終了する。
以上で、図１２の説明を終了する。
次に、図１３を用いて、ステップＳ１２０４の処理の詳細について説明する。
【０１０６】
図１３はステップＳ１２０４の処理の詳細を示すフローチャートの一例を示す図である。
ステップＳ１３０１において、ＳＮＳサーバ１０４は、まず検索条件の解析を行う。
【０１０７】
次にステップＳ１３０２で、ＳＮＳサーバ１０４は、スレッド一覧表示を要求したユーザ、つまり担当読影医（以下、読影医Ａと呼ぶ）が参加しているスレッドを、データベース１０８で管理されるスレッドデータ６００から指定された条件（少なくとも患者名と病院名を含む）で検索する。具体的には、検索条件に含まれる病院のスレッドデータ６００の、患者名６０９に患者Ａが含まれるスレッドを特定し、特定した患者Ａのスレッドのうち、参加者６０４に読影医Ａが含まれるスレッドを検索する。
ステップＳ１３０２は、本発明における、受付手段で受け付けた患者情報に従って、当該患者情報に紐付くスレッドを前記記憶手段から特定する特定手段の一例である。
【０１０８】
次にステップＳ１３０３で、ＳＮＳサーバ１０４は、同一病院内のスレッドデータ６００の、患者名６０９に患者Ａが含まれ、かつ参加者６０４に読影医Ａが含まれないスレッドを検索する。ここで、同一病院内としているのは、通常、患者ＩＤは、通常同一患者であっても依頼病院ごとに異なるためである。
【０１０９】
ただし、患者情報にマイナンバー（患者を識別するためのナンバーであり、別々の病院であっても同一の患者であれば同じナンバーである）を含む場合、マイナンバーで患者を特定することで、複数の病院にまたがって、患者Ａのスレッドを検索することも可能である。その場合、検索条件に病院名は含まれていなくとも良い。
【０１１０】
最後にステップＳ１３０４で、ＳＮＳサーバ１０４は、ステップＳ１３０２、ステップＳ１３０３のステップでの検索結果をマージして、ＳＮＳサーバ１０４のＲＡＭ２０３に保管する。
以上で図１３の説明を終了する。
次に、図１４を用いて、ステップＳ１２０５の処理の詳細について説明する。
【０１１１】
図１４はステップＳ１２０５の処理の詳細を示すフローチャートの一例を示す図である。
ステップＳ１４０１において、ＳＮＳサーバ１０４は、まず検索条件の解析を行う。
【０１１２】
次にステップＳ１４０２で、ＳＮＳサーバ１０４は、スレッド一覧表示を要求したユーザ、つまり担当読影医以外のユーザ（事務員や患者Ａの担当ではない読影医等であり、以下ユーザＢとする）が参加しているスレッドを、データベース１０８で管理されるスレッドデータ６００から指定された条件（少なくとも患者名と病院名を含む）で検索する。具体的には、検索条件に含まれる病院のスレッドデータ６００の中から、患者名６０９に患者Ａが含まれるスレッドを特定し、特定した患者Ａのスレッドのうち、参加者６０４にユーザＢが含まれるスレッドを検索する。
【０１１３】
ステップＳ１４０２は、本発明における、受付手段で受け付けた患者情報に従って、当該患者情報に紐付くスレッドを前記記憶手段から特定する特定手段の一例である。
【０１１４】
最後にステップＳ１４０３で、ＳＮＳサーバ１０４は、ステップＳ１４０２での検索結果をＳＮＳサーバ１０４のＲＡＭ２０３に保管する。
以上で図１４の説明を終了する。
次に、図１５を用いて、ステップＳ１２０６の処理の詳細について説明する。
【０１１５】
図１５は、ステップＳ１２０６の処理の詳細を示すフローチャートの一例を示す図である。
【０１１６】
ステップＳ１５０１において、ＳＮＳサーバ１０４は、図１３のステップＳ１３０４や、図１４のステップＳ１４０３で、ＳＮＳサーバ１０４のＲＡＭ２０３に保管された検索結果であるスレッドデータを取得する。
【０１１７】
次に、ＳＮＳサーバ１０４は、ステップＳ１５０１で取得したスレッドデータを順に処理し、表示データを作成しＲＡＭ２０３への保管を行うループ（ステップＳ１５０２〜ステップＳ１５１０までの処理）を実行する。
ステップＳ１５０２において、ＳＮＳサーバ１０４のＲＡＭ２０３から取得した検索結果からスレッドデータを１件とりだす。
【０１１８】
次にステップＳ１５０３において、ＳＮＳサーバ１０４は、取り出したスレッドデータが、スレッド一覧表示を要求したユーザが参加しているスレッド（図６のスレッドデータ６００の参加者６０４に当該ユーザが含まれるか）かどうかを判断する。スレッド一覧表示を要求したユーザが未参加のスレッドであれば、ステップＳ１５０４に進み、スレッド一覧表示を要求したユーザが参加しているスレッドであればステップＳ１５０６に進む。
【０１１９】
なお、ＳＮＳサーバ１０４のＲＡＭ２０３から取得した検索結果が、図１４のステップＳ１４０３で、ＳＮＳサーバ１０４のＲＡＭ２０３に記憶されたものであれば、必ずステップＳ１５０６に進む。
【０１２０】
ステップＳ１５０４において、ＳＮＳサーバ１０４は、スレッド一覧表示を要求したユーザが、該当スレッドデータ内の参加拒否ユーザに含まれている（図６のスレッドデータ６００の参加否認６０６に当該ユーザが含まれている）かどうかを判断する。スレッド一覧表示を要求したユーザが、該当スレッドデータ内の参加拒否ユーザに含まれていれば、ループの先頭に戻る。スレッド一覧表示を要求したユーザが、該当スレッドデータ内の参加拒否ユーザに含まれていなければ、ステップＳ１５０５に進む。
【０１２１】
ステップＳ１５０５において、ＳＮＳサーバ１０４は、閲覧権限がないスレッド（未参加スレッド）の表示欄、具体的には図５の５０３の枠が作成済みかどうか判断し、作成済みでなければ、ステップＳ１５０９で、ＳＮＳサーバ１０４は閲覧権限のないスレッドの表示枠を作成する。
【０１２２】
次にステップＳ１５１０で、ＳＮＳサーバ１０４は、閲覧権限がないスレッドの表示データを作成する。表示データには、スレッドの関連種類、スレッドのタイトル（図５の５０４）、およびスレッドに関連する患者名が含まれる。また、スレッドオーナーへの参加依頼を行う、参加依頼ボタン（図５の５０７）も含まれる。参加依頼ボタンの状態は、表示するスレッドデータの参加依頼中ユーザのカラム（図６のスレッドデータ６００の参加依頼中６０５）の内容に依存し、参加依頼中６０５の中にスレッド一覧表示を要求したユーザが含まれているときは、参加依頼ボタンが操作不可能状態のボタンとなる。
ステップＳ１５０９、ステップＳ１５１０は、本発明における、特定手段で特定されたスレッドが、前記受付手段で取得要求を行った医師が前記記憶手段の前記ユーザ情報により閲覧可能でないとされるスレッドである場合にも、前記受付手段で取得要求を行った医師が前記医師情報に含まれる場合には、当該スレッドを識別可能な画面を生成する生成手段の一例である。
【０１２３】
ステップＳ１５０６において、ＳＮＳサーバ１０４は、閲覧可能スレッドの表示欄、具体的には図５の５０２の枠が作成済みかどうか判断し、作成済みでなければ、ステップＳ１５０７で閲覧可能スレッドの表示枠を作成する。次にステップＳ１５０８で、閲覧可能スレッドの表示データを作成する。
【０１２４】
表示データには、スレッドの関連種類、スレッドのタイトル（図５の５０４）、およびスレッドに関連する患者名が含まれる。スレッドのタイトル５０４には、スレッドに含まれるメッセージを表示するためのリンクを埋め込む。
【０１２５】
ステップＳ１５０７、ステップＳ１５０８は、本発明における、特定手段で特定されたスレッドが、前記受付手段で取得要求を行った医師が前記記憶手段の前記ユーザ情報により閲覧可能であるとされるスレッドである場合には、スレッドの内容を参照可能な画面を生成する生成手段の一例である。
【０１２６】
ステップＳ１５０１で取得したスレッドデータすべてに対して、ステップＳ１５０２〜ステップＳ１５１０までの処理を実行すると図１５の処理を終了する。
次に、図１６を用いて、ステップＳ１２１１の処理の詳細について説明する。
【０１２７】
図１６は、ステップＳ１２１１の処理の詳細を示すフローチャートの一例を示す図である。
【０１２８】
ステップＳ１６０１において、ＳＮＳサーバ１０４は、ユーザによるマウス操作等により参加依頼ボタン５０７が押下されたスレッドのスレッド参加依頼画面９０１の表示データを生成し、ＰＣ３０１にスレッド参加依頼画面９０１の表示データを送信する。
【０１２９】
ＳＮＳサーバ１０４から、スレッド参加依頼画面９０１の表示データを受け取ったＰＣ３０１は、ステップＳ１６０２で、スレッド参加依頼画面９０１をＰＣ３０１のディスプレイ２１０に表示する。
【０１３０】
ステップＳ１６０３において、ＰＣ３０１は、スレッド参加依頼画面９０１を介してユーザから操作を受け付けるまで待機し、メッセージ入力が行われ、送信ボタン（スレッド参加依頼画面９０１の９０４）がユーザによるマウス等の操作により押されると、ステップＳ１６０４で、ＰＣ３０１は、ユーザによるマウス操作等により参加依頼ボタン５０７が押下されたスレッドへの参加依頼の要求をＳＮＳサーバ１０４に送信する。
【０１３１】
ＳＮＳサーバ１０４は、ユーザによるマウス操作等により参加依頼ボタン５０７が押下されたスレッドの参加依頼の要求を受信すると、ステップＳ１６０５で要求の解析を行う。
【０１３２】
そして、ステップＳ１６０６において、ＳＮＳサーバ１０４は、該当スレッド内にシステムからのメッセージとして、参加依頼があった旨のメッセージを追加する。具体的には、スレッドメッセージデータ８００に、受信した参加依頼メッセージを、参加依頼メッセージが送信されたスレッドのスレッドＩＤを付与して登録する。
【０１３３】
次に、ステップＳ１６０７において、ＳＮＳサーバ１０４は、図６のスレッドデータ６００の６０５に、参加依頼メッセージを送信したユーザを追加する。
【０１３４】
最後に、ステップＳ１６０８において、ＳＮＳサーバ１０４は、参加依頼ボタン５０７を操作不可能状態のボタンにしたスレッド一覧画面５０１を再生成し、ステップ１１０９で、再生成したスレッド一覧画面５０１をＰＣ３０１に送信する。
【０１３５】
ステップＳ１６１０において、ＰＣ３０１は、再生成したスレッド一覧画面５０１をＳＮＳサーバ１０４から受信後、受信したスレッド一覧画面５０１を使用して、ＰＣ３０１のディスプレイ２１０に表示しているスレッド一覧画面５０１を更新し、図１６の処理を終了する。
次に、図１７を用いて、ステップＳ１２１３の処理の詳細について説明する。
【０１３６】
図１７は、ステップＳ１２１３の処理の詳細を示すフローチャートの一例を示す図である。
【０１３７】
ステップＳ１７０１において、ＳＮＳサーバ１０４は、メッセージ表示要求の解析を行う。具体的には、スレッド一覧画面５０１において、ユーザのマウス等による操作によって、タイトル５０４が押下されたスレッドのスレッドＩＤを特定する。
【０１３８】
ステップＳ１７０２において、ＳＮＳサーバ１０４は、スレッドメッセージデータ８００を検索し、ステップＳ１７０１で特定したスレッドＩＤとスレッドＩＤ８０２が同じであるメッセージを取得する。
【０１３９】
ステップＳ１７０３において、ＳＮＳサーバ１０４は、ステップＳ１７０２で取得したメッセージ一覧の画面データ（図７のスレッド詳細画面７０１）を生成し、ＳＮＳサーバ１０４のＲＡＭ２０３に保管する。
【０１４０】
ステップＳ１７０４において、ＳＮＳサーバ１０４は、ステップＳ１７０２で取得したメッセージデータに、システムからのスレッド参加依頼メッセージがあり、かつメッセージ一覧表示の実行者が、該当スレッドのオーナーであるか否かを判定する。
【０１４１】
スレッド参加依頼メッセージがあり（スレッドメッセージデータ８００の例では、メッセージＩＤ１０１０が該当する）、かつメッセージ一覧表示の実行者が、該当スレッドのオーナーであった（ステップＳ１７０２で取得したメッセージデータのスレッドＩＤ８０２と一致するスレッドデータ６００のスレッドＩＤ６０１のスレッドオーナー６０３がメッセージ一覧表示の実行者であった）場合、ステップＳ１７０５に進み、スレッド参加依頼メッセージがない、もしくはメッセージ一覧表示の実行者が、該当スレッドのオーナーでない場合、ステップＳ１７０６に進む。
【０１４２】
ステップＳ１７０５において、ＳＮＳサーバ１０４は、ＲＡＭ２０３に保管したスレッド詳細画面７０１の、メッセージの該当箇所に、スレッド参加の可否を操作するためのボタンのデータ（図７の参加依頼の承認・拒否ボタン７０３）を付加する。
ステップＳ１７０６において、ＳＮＳサーバ１０４は、スレッド詳細画面７０１をＰＣ３０１に送信する。
【０１４３】
ステップＳ１７０７において、スレッド詳細画面７０１をＳＮＳサーバ１０４から受け取ったＰＣ３０１は、スレッド詳細画面７０１をＰＣ３０１のディスプレイ２１０に表示し、ステップＳ１７０８で、スレッド詳細画面７０１を介してユーザからの操作を受け付けるイベント待ちループを実行する。ユーザからの操作があった場合、ステップＳ１７０９において、ＰＣ３０１は、ユーザからの操作内容をＳＮＳサーバ１０４に送信する。
【０１４４】
ステップＳ１７１０において、ＳＮＳサーバ１０４は、ユーザからの操作内容をＰＣ３０１から受け取ると、ユーザからの操作内容を判断する。
【０１４５】
ステップＳ１７１０で、ユーザからの操作内容が、スレッドへの参加依頼の承認の操作であると判断した場合（図７の参加依頼の承認・拒否ボタン７０３のうち「承認」のボタンが押下された場合）、ステップＳ１７１１で、ＳＮＳサーバ１０４は、図６のスレッドデータ６００の該当スレッドの参加者６０４にスレッドへの参加依頼を行ったユーザの情報を追加する。
【０１４６】
ステップＳ１７１０で、ユーザからの操作内容が、参加依頼の拒否の操作であると判断した場合、ステップＳ１７１２でＳＮＳサーバ１０４は、図６のスレッドデータ６００の該当スレッドの参加否認６０６に、スレッドへの参加依頼を行ったユーザの情報を追加する。
【０１４７】
ステップＳ１７１３において、ＳＮＳサーバ１０４は、該当スレッドにスレッド参加依頼の承認／拒否のメッセージを追加する（スレッドメッセージデータ８００の例では、メッセージＩＤ１０１１が該当する）。
【０１４８】
ステップＳ１７１０で、その他の操作だと判断した場合、ステップＳ１７１４において、ＳＮＳサーバ１０４は、ユーザによるメッセージ入力操作（図７の７０４にメッセージが入力され、送信ボタンがユーザによるマウス等の操作によって押下された）かどうかを判断する。
【０１４９】
ステップＳ１７１４で、ユーザによるメッセージ入力操作であると判断した場合、ステップＳ１７１５において、ＳＮＳサーバ１０４は、ユーザが入力したメッセージ内容をスレッドメッセージデータ８００に追加する。
【０１５０】
ステップＳ１７１４で、ユーザによるメッセージ入力操作以外の操作であると判断した場合、ステップＳ１７１６において、ＳＮＳサーバ１０４は、終了操作かどうかを判断し、終了操作であればスレッド詳細画面７０１を閉じる処理を行い、終了操作でなければ、ステップＳ１７１７でその他の処理を行う。
【０１５１】
ステップＳ１７１８において、ＳＮＳサーバ１０４は、スレッド詳細画面７０１の再生成を行い、再生成したスレッド詳細画面７０１をＰＣ３０１に送信し、ＰＣ３０１はステップＳ１７０７以降を繰り返す。
【０１５２】
以上で、図１７の説明を終了する。
以上で、本発明においてＰＣ３０１、または、ＳＮＳサーバ１０４において実行される各処理の説明を終了する。
【０１５３】
以上、本発明によると、患者ごとのスレッドの取得要求を、当該患者を対象とした検査の読影を行う医師から受け付けた場合に、当該患者に関するスレッド情報を、当該患者の情報に関するセキュリティを確保しつつ、可能な限り当該医師に提供することができる。
【０１５４】
また、本発明によると、ある患者を対象とした読影依頼（検査）の担当読影医に、当該担当読影医が参加していないスレッドのタイトルを見せることにより、当該担当読影医に当該患者に関して他にもメッセージのやり取りがされていることを認識させつつ、当該担当読影医が参加していないスレッドについては、スレッドオーナーにより承認されなければ詳細を閲覧させないことで、患者の個人情報の保護という点においてセキュリティを高めることが出来る。
【０１５５】
また、本発明によると、スレッドの検索の対象となっている患者を対象とした読影依頼（検査）の担当読影医以外のユーザに当該ユーザが参加しているスレッド以外のスレッドの情報を当該ユーザに見せないことで患者の個人情報の開示範囲を的確に管理することができる。つまり、患者の個人情報の保護という点においてセキュリティを高めることが出来る。
【０１５６】
スレッドの検索の対象となっている患者を対象とした読影依頼（検査）の担当読影医に、当該担当読影医が参加していないスレッドのタイトルを見せることにより、当該担当読影医に当該患者に関して他にもメッセージのやり取りがされていることを認識させ、当該担当読影医が参加していない当該患者のスレッドへ誘導することが出来るという効果を得ることが出来る。また、当該担当読影医が参加していないスレッドについては、スレッドオーナーにより承認されなければ詳細を閲覧させないことで、患者の個人情報の開示範囲を的確に管理することができる。つまり、患者の個人情報の保護という点においてセキュリティを高めることが出来る。
【０１５７】
本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。
【０１５８】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
【０１５９】
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１６０】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【０１６１】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【０１６２】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【０１６３】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１６４】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１６５】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１６６】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【０１６７】
なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【０１６８】
１０４  ＳＮＳサーバ
１０８  データベース
３０１  ＰＣ
【図１】
2016126798.tif 000003
【図２】
2016126798.tif 000004
【図３】
2016126798.tif 000005
【図４】
2016126798.tif 000006
【図５】
2016126798.tif 000007
【図６】
2016126798.tif 000008
【図７】
2016126798.tif 000009
【図８】
2016126798.tif 000010
【図９】
2016126798.tif 000011
【図１０】
2016126798.tif 000012
【図１１】
2016126798.tif 000013
【図１２】
2016126798.tif 000014
【図１３】
2016126798.tif 000015
【図１４】
2016126798.tif 000016
【図１５】
2016126798.tif 000017
【図１６】
2016126798.tif 000018
【図１７】
2016126798.tif 000019