JP2023007217A - サーバ及び医療システム - Google Patents

Abstract

【課題】患者に対して適切でないメッセージが送られるのを防ぐサーバ及び医療システムを提供する。【解決手段】医療システムにおいて、医療施設が有する施設側端末装置（クライアント３０）から患者が有する患者側端末装置（モバイル端末装置４０）へのメッセージを中継するサーバ１０は、メッセージを施設側端末装置より受信する受信部１００ａと、受信部１００ａにより受信したメッセージの適否を判定する適否判定部１００ｂと、適否判定部１００ｂによりメッセージが適切でないと判定された場合に患者側端末装置へのメッセージの転送を中止する転送中止部１００ｃと、を備える。【選択図】図９

Description

本発明は、サーバ及び医療システムに関する。

医師や看護師等の医療従事者から患者に対してメッセージを送信するための医療システムが知られている。例えば特許文献１に、この種の医療システムの具体的構成が記載されている。

特許文献１に記載の医療システムは、病院内のネットワークシステムで相互通信可能に接続されたサーバと医療従事者用情報端末を備える。サーバには、患者用情報端末からアップロードされた患者の測定データ（体重、血圧、血糖値等）が保存される。医療従事者用情報端末は、サーバにアップロードされた測定データを受信し、この測定データを確認した医療従事者に患者へのアドバイスを入力させ、入力されたアドバイスを含むメッセージを患者用情報端末に送信する。

特開２０１１－１８０８１７号公報

特許文献１に記載の医療システムでは、患者へのメッセージに定型の内容だけでなく任意の内容も含めることができる。この場合、医療従事者が意図しなくとも、メッセージの中に他の患者の個人情報や誤った診察情報が含まれてしまう可能性がある。すなわち、適切でないメッセージが患者に送られる可能性がある。

本発明は、上記の事情に鑑みてなされたものであり、患者に対して適切でないメッセージが送られるのを防ぐことができるサーバ及びこのようなサーバを備える医療システムを提供することを目的とする。

本発明の一実施形態に係るサーバは、医療施設が有する施設側端末装置から患者が有する患者側端末装置へのメッセージを中継するサーバであり、前記メッセージを前記施設側端末装置より受信する受信部と、前記受信部により受信したメッセージの適否を判定する適否判定部と、前記適否判定部により前記メッセージが適切でないと判定された場合に前記患者側端末装置への前記メッセージの転送を中止する転送中止部と、を備える。

本発明の一実施形態に係る医療システムは、医療施設が有する施設側端末装置と、患者が有する患者側端末装置と、前記施設側端末装置から前記患者側端末装置へのメッセージを中継する、上記のサーバと、を備える。

本発明の一実施形態によれば、サーバ及び医療システムにおいて、患者に対して適切でないメッセージが送られるのを防ぐことができる。

本発明の一実施形態に係る医療システムを示すブロック図である。 本発明の一実施形態に係るサーバのハードウェア構成を示すブロック図である。 本発明の一実施形態に係る患者情報テーブルの一例を示す図である。 本発明の一実施形態に係る履歴情報テーブルの一例を示す図である。 本発明の一実施形態に係る診療科情報テーブルの一例を示す図である。 本発明の一実施形態に係る医師情報テーブルの一例を示す図である。 本発明の一実施形態に係る予約・診察情報テーブルの一例を示す図である。 本発明の一実施形態に係る投薬情報テーブルの一例を示す図である。 本発明の一実施形態に係る医療システムの機能構成を示すブロック図である。 本発明の一実施形態において、サーバの制御部により実行される、メッセージ中継プログラムを示すフローチャートである。 図１０のステップＳ１０５のメッセージ適否判定処理を示すフローチャートである。 図１０のステップＳ１０６のメッセージ適否判定処理を示すフローチャートである。 クライアントの不正利用の可能性を判定する処理を示すフローチャートである。

以下、本発明の一実施形態について、詳細に説明する。

図１は、本発明の一実施形態に係る医療システム１を示すブロック図である。図１に示されるように、医療システム１は、サーバ１０、電子カルテシステム２０、クライアント３０及びモバイル端末装置４０を備える。

サーバ１０、電子カルテシステム２０及びクライアント３０は、医療施設（具体的には病院）に設置されており、病院内に構築された院内ネットワーク（例えばＬＡＮ：Local Area Network）内で相互通信可能に接続される。

サーバ１０は、ハードウェア構成としては一般的な構成（汎用のサーバ）を有する。図２は、本発明の一実施形態に係るサーバ１０のハードウェア構成を示すブロック図である。サーバ１０は、図２に示されるように、制御部１００、通信インタフェース１１０、操作部１２０、モニタ１３０及びメモリ１４０を備える。

なお、サーバ１０は、図２に示されていない他のハードウェア構成を備えていてもよい。また、サーバ１０は、図２に示される全てのハードウェア構成を備えるものでなくてもよい。例えば、操作部１２０やモニタ１３０を備えないサーバ１０も本発明の範疇である。すなわち、サーバ１０の態様には自由度があり、各種の設計変更が可能である。

制御部１００は、サーバ１０全体を制御するものであり、ＣＰＵ（Central Processing Unit）１００Ａ、ＲＡＭ（Random Access Memory）１００Ｂ、ＲＯＭ（Read Only Memory）１００Ｃ、入出力インタフェース１００Ｄ、表示制御回路１００Ｅ及びこれらのポートを結ぶバスライン１００Ｆ等よりなるマイクロコンピュータである。

ＣＰＵ１００Ａは、ＲＯＭ１００Ｃに記憶されたプログラムを読み込み、読み込まれたプログラムに従ってサーバ１０を制御する。

ＲＡＭ１００Ｂは、プログラムやデータを一時的に記憶する記憶部であり、ワークエリアを提供する。ＲＡＭ１００Ｂは、例えば、ＤＲＡＭ（Dynamic Random Access Memory）である。

ＲＯＭ１００Ｃは、メッセージ中継プログラムをはじめとする各種プログラムを記憶する不揮発性メモリである。ＲＯＭ１００Ｃは、例えばフラッシュメモリである。

ＲＯＭ１００Ｃに記憶されたメッセージ中継プログラムは、クライアント３０からモバイル端末装置４０へのメッセージを中継するプログラムである。概略的には、メッセージ中継プログラムは、メッセージをクライアント３０より受信し、受信したメッセージの適否を判定し、メッセージが適切であると判定した場合にはモバイル端末装置４０へメッセージを転送し、メッセージが適切でないと判定した場合にはモバイル端末装置４０へのメッセージの転送を中止するプログラムである。メッセージ中継プログラムの詳細は後述する。

なお、このメッセージ中継プログラムの実行により、クライアント３０からモバイル端末装置４０（言い換えると患者）に対して適切でないメッセージが送られるのを防ぐことができる。

入出力インタフェース１００Ｄは、通信インタフェース１１０及び操作部１２０と接続されており、通信インタフェース１１０及び操作部１２０とＣＰＵ１００Ａとの通信を中継する。

通信インタフェース１１０は、電子カルテシステム２０、クライアント３０、モバイル端末装置４０と通信する。通信インタフェース１１０は、例えば、電子カルテサーバ２２にアクセスして必要な情報を取得し、また、クライアント３０からのメッセージをモバイル端末装置４０へ転送する。

操作部１２０は、キーボードやマウス、タッチパネル等のユーザインタフェースであり、オペレータからの入力操作を受け付けてＣＰＵ１００Ａに通知する。

モニタ１３０は、例えばＬＣＤ（Liquid Crystal Display）であり、表示制御回路１００Ｅの制御下で駆動する。表示制御回路１００Ｅは、例えば設定画面をモニタ１３０に表示させる。

メモリ１４０は、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）であり、患者情報テーブル１４２及び履歴情報テーブル１４４を保持する。

患者情報テーブル１４２には、患者に関する情報が登録される。例えば病院の事務員が不図示の端末装置を操作して、初診時に患者が記入した問診票に記載の情報を患者情報テーブル１４２に登録する。

図３に、患者情報テーブル１４２の一例を示す。図３に示されるように、患者情報テーブル１４２の各レコードには、患者ＩＤ（Identification）、患者氏名、通知先、電話番号等の情報が登録される。

患者ＩＤは、患者情報テーブル１４２の各レコードに割り当てられたＩＤである。患者氏名は、モバイル端末装置４０の保有者を示す。通知先は、例えばモバイル端末装置４０にて受信可能なメールアドレスである。電話番号は、例えばモバイル端末装置４０又は患者の自宅の電話番号である。

履歴情報テーブル１４４には、クライアント３０からモバイル端末装置４０へのメッセージに関する履歴情報が登録される。メッセージに関する履歴情報は、サーバ１０の制御部１００によるメッセージ中継プログラムの実行時に、履歴情報テーブル１４４に登録される。

図４に、履歴情報テーブル１４４の一例を示す。図４に示されるように、履歴情報テーブル１４４の各レコードには、履歴ＩＤ、情報共有日時、患者ＩＤ、通知先、共有内容、診療科ＩＤ、医師ＩＤ、通知結果等の情報が登録される。

履歴ＩＤは、履歴情報テーブル１４４の各レコードに割り当てられたＩＤである。情報共有日時は、クライアント３０からモバイル端末装置４０へのメッセージをサーバ１０が受信した日時（又はサーバ１０がメッセージをモバイル端末装置４０へ転送した日時）を示す。共有内容は、メッセージ本文を示す。診療科ＩＤは、後述する診療科情報テーブル２２０の各レコードに割り当てられたＩＤである。医師ＩＤは、後述する医師情報テーブル２２２の各レコードに割り当てられたＩＤである。通知結果は、クライアント３０からのメッセージをモバイル端末装置４０に転送したか否かを示す情報である。

履歴情報テーブル１４４の患者ＩＤは、メッセージの送信相手（すなわち患者）のＩＤを示す。履歴情報テーブル１４４は、例えば患者ＩＤをキーとして、患者情報テーブル１４２と関連付けられる。このように、本実施形態では、同じ名称のフィールドによってテーブル同士が関連付けられる。

なお、サーバ１０の各テーブルに登録されるフィールドは、上記に例示されるものに限らない。各テーブルには、上記に例示されたフィールドに代えて別のフィールドが登録されてもよく、また、上記に例示されたフィールドに加えて別のフィールドが登録されてもよい。一例として、患者情報テーブル１４２には、上記に例示されたフィールドに加えて、性別、年齢、体重、身長等のフィールドが登録されてもよい。

クライアント３０は、施設側端末装置の一例である。クライアント３０もサーバ１０と同様に、ハードウェア構成として一般的な構成（汎用のＰＣ（Personal computer））を有する。クライアント３０は、医療従事者（例えば医師）により操作される端末装置であり、例えば各診療科の各診察室に設置される。

クライアント３０は、医師による操作に従い、例えば患者の診察記録を電子カルテシステム２０に登録する。また、クライアント３０は、医師による操作に従い、定型の又は任意のメッセージをモバイル端末装置４０へ送信する。このメッセージは、サーバ１０で中継されてモバイル端末装置４０へ送信される。

クライアント３０より送信されるメッセージは、例えば、ＲＦＣ（Request for Comments）に準拠した一般的な電子メールメッセージである。なお、メッセージは、ＳＭＳ（Short Message Service）メッセージやコミュニケーションアプリによるインスタントメッセージであってもよい。コミュニケーションアプリは、メッセージングアプリ、チャットアプリ、ＳＮＳ（Social Networking Service）アプリと呼称されることもある。

モバイル端末装置４０は、患者側端末装置の一例である。モバイル端末装置４０は、患者が保有するモバイル端末装置であり、例えばスマートフォン、フィーチャフォン、タブレット端末、ノートＰＣである。モバイル端末装置４０は、公衆回線やＶＰＮ（Virtual Private Network）等の閉域網の通信回線を介してサーバ１０と通信可能に接続される。

電子カルテシステム２０は、医師が患者の診察記録（カルテ）を記入して管理するためのシステムである。電子カルテシステム２０は、電子カルテサーバ２２を含む。

電子カルテサーバ２２は、サーバ１０と同様に、ハードウェア構成として一般的な構成（汎用のサーバ）を有する。

電子カルテサーバ２２のメモリにもテーブルが保持される。例示的には、電子カルテサーバ２２のメモリには、診療科情報テーブル２２０、医師情報テーブル２２２、予約・診察情報テーブル２２４、投薬情報テーブル２２６が保持される。

診療科情報テーブル２２０には、診療科に関する情報が予め登録される。診療科情報テーブル２２０は、例えば診療科が新設されたり統廃合されたりした場合に更新される。

図５に、診療科情報テーブル２２０の一例を示す。図５に示されるように、診療科情報テーブル２２０の各レコードには、診療科ＩＤ、診療科名等の情報が登録される。診療科名は、診療科ＩＤに関連付けられた診療科の名称である。

医師情報テーブル２２２には、医師に関する情報が予め登録される。医師情報テーブル２２２は、例えば医師の着任や退職等に応じて更新される。

図６に、医師情報テーブル２２２の一例を示す。図６に示されるように、医師情報テーブル２２２の各レコードには、医師ＩＤ、診療科ＩＤ、医師名等の情報が登録される。医師名は、診療科ＩＤと関連付けられた診療科に所属する医師の氏名である。

予約・診察情報テーブル２２４には、診察予約及び診察に関する情報が登録される。図７に、予約・診察情報テーブル２２４の一例を示す。図７に示されるように、予約・診察情報テーブル２２４の各レコードには、予約・診察ＩＤ、診療科ＩＤ、診療科名、医師ＩＤ、医師名、予約日、予約時間、患者ＩＤ、診察日、診察時間、診察内容等の情報が登録される。

予約・診察ＩＤは、予約・診察情報テーブル２２４の各レコードに割り当てられたＩＤである。例えば、医師がクライアント３０を操作して電子カルテシステム２０にログインし、患者の診察予約を行うと、予約内容に応じたレコードが予約・診察情報テーブル２２４に登録される。

例示的には、医師がクライアント３０に対して予約日時（予約日、予約時間）を入力すると、クライアント３０を介して電子カルテサーバ２２のプログラムが実行される。電子カルテサーバ２２は、診察情報テーブル２２４に新たな予約・診察ＩＤのレコードを生成し、このレコードに、予約日時を登録するとともに既存の情報（予約患者の患者ＩＤ、診察する医師名及び医師ＩＤ並びにこの医師が所属する診療科名及び診療科ＩＤ）を登録する。

なお、医師は、ログインＩＤを入力して電子カルテシステム２０へログインしている。このログインＩＤは、診療科情報テーブル２２０及び医師情報テーブル２２２と関連付けられている。また、診察予約時、クライアント３０は、医師による操作に従い、予約患者の情報を患者情報テーブル１４２から取得している。そのため、患者ＩＤ、医師名、医師ＩＤ、診療科名及び診療科ＩＤは、電子カルテサーバ２２から呼び出すことができる。

予約された診察を行う際、電子カルテサーバ２２は、クライアント３０からの指示に応じて、該当する予約・診察ＩＤのレコードを呼び出す。医師がクライアント３０に対して診察結果等を入力すると、電子カルテサーバ２２は、その情報（診察日、診察時間、診察内容等）を、呼出中の予約・診察ＩＤのレコードに登録する。

投薬情報テーブル２２６には、患者に処方する薬に関する情報が登録される。図８に、投薬情報テーブル２２６の一例を示す。図８に示されるように、投薬情報テーブル２２６の各レコードには、投薬ＩＤ、予約・診察ＩＤ、薬名称、数量等の情報が登録される。

医師は、クライアント３０に対して診察結果等を入力する際、薬の処方情報（薬名称、数量等）も入力する。電子カルテサーバ２２は、薬の処方情報が入力されると、投薬情報テーブル２２６に新たな投薬ＩＤのレコードを生成し、このレコードに、該当する予約・診察ＩＤ、薬名称、数量等の情報を登録する。

なお、電子カルテサーバ２２の各テーブルに登録されるフィールドは、上記に例示されるものに限らない。各テーブルには、上記に例示されたフィールドに代えて別のフィールドが登録されてもよく、また、上記に例示されたフィールドに加えて別のフィールドが登録されてもよい。一例として、予約・診察情報テーブル２２４には、上記に例示されたフィールドに加えて、血圧値、体温、心拍数、脈拍数、酸素飽和度等のバイタルサインのフィールドや、生化学検査、血液検査、脳波検査等の検査値のフィールドが登録されてもよい。

図９は、医療システム１の機能構成を示すブロック図である。図９に示されるように、サーバ１０の制御部１００は、機能構成として、受信部１００ａ、適否判定部１００ｂ、転送中止部１００ｃ、通知部１００ｄ、記録部１００ｅ、不正利用判定部１００ｆを備える。なお、サーバ１０は、図９に示していない他の機能構成を備えていてもよい。

図１０は、本発明の一実施形態において、サーバ１０の制御部１００により実行される、メッセージ中継プログラム（言い換えるとメッセージ中継方法）の処理手順を示すフローチャートである。例えば、サーバ１０のシステムが起動されると、制御部１００がクライアント３０からモバイル端末装置４０へのメッセージの受信を待機する状態に遷移する。

クライアント３０からモバイル端末装置４０へのメッセージが送信されると、制御部１００は、このメッセージを受信する（ステップＳ１０１）。すなわち、ステップＳ１０１において、制御部１００は、メッセージをクライアント３０より受信する受信部１００ａとして動作する。

制御部１００は、クライアント３０からメッセージを受信すると、履歴情報テーブル１４４に新たな履歴ＩＤのレコードを生成する（ステップＳ１０２）。

制御部１００は、新たに生成されたレコードに対して各種情報を登録する（ステップＳ１０３）。例示的には、制御部１００は、クライアント３０からメッセージを受信した日時を「情報共有日時」フィールドに登録する。また、制御部１００は、患者情報テーブル１４２のなかから、メッセージの送信相手として指定された通知先（すなわちメッセージの宛先）を取得するとともに患者ＩＤを取得し、取得された通知先、患者ＩＤのそれぞれを対応するフィールドに登録する。制御部１００は、通知先を複数取得した場合、取得された全ての通知先を「通知先」フィールドに登録するとともに、対応する全ての患者ＩＤを「患者ＩＤ」フィールドに登録する。また、制御部１００は、メッセージ本文（例えばテキストデータ）を「共有内容」フィールドに登録する。また、制御部１００は、メッセージを送信した医師の医師ＩＤ及び所属する診療科の診療科ＩＤを取得し、取得された医師ＩＤ、患者ＩＤのそれぞれを対応するフィールドに登録する。医師ＩＤ、患者ＩＤは、例えばメッセージのヘッダから取得することができる。

このように、ステップＳ１０３（並びに後述のステップＳ２０３及びＳ２０６）において、制御部１００は、メッセージの送信履歴を記録する記録部１００ｅとして動作する。

制御部１００は、ステップＳ１０３にて複数の通知先を取得したか否かを判定する（ステップＳ１０４）。すなわち、ステップＳ１０４において、制御部１００は、クライアント３０から受信したメッセージがそれぞれ異なる患者が有する複数のモバイル端末装置４０に一斉送信されるものか否かを判定する適否判定部１００ｂとして動作する。

なお、ステップＳ１０４において、制御部１００は、ステップＳ１０３にて複数の通知先を取得したか否かではなく、単純に、メッセージの宛先が複数あるか否かを判定してもよい。

ステップＳ１０３にて複数の通知先を取得していた場合（ステップＳ１０４：ＹＥＳ）、制御部１００は、ステップＳ１０５のメッセージ適否判定処理を実行する。概説すると、ステップＳ１０５では、患者の個人情報が他者に知られる可能性がある場合、モバイル端末装置４０に対するメッセージの転送を中止し、その可能性がない場合、モバイル端末装置４０に対してメッセージを転送する。

なお、制御部１００は、ステップＳ１０５のメッセージ適否判定処理の実行後、図１０のフローチャートの処理を終了し、クライアント３０からモバイル端末装置４０へのメッセージの受信を待機する状態に復帰する。

図１１は、図１０のステップＳ１０５のメッセージ適否判定処理を示すフローチャートである。

図１１に示されるように、制御部１００は、クライアント３０から受信したメッセージの適否を判定する（ステップＳ２０１）。例示的には、制御部１００は、ステップＳ１０３にて「共有内容」フィールドに登録されたメッセージ本文に特定の情報が含まれるか否かを判定する。

特定の情報は、例えば個人情報である。ここでは、患者情報テーブル１４２の各レコードに登録された患者氏名、通知先、電話番号等の個人情報がメッセージ本文に含まれるか否かが判定される。

メッセージ本文に個人情報が含まれない（言い換えると、メッセージが適切な）場合（ステップＳ２０１：ＹＥＳ）、制御部１００は、メッセージで指定された全ての宛先（複数のモバイル端末装置４０）にメッセージを一斉送信（全ての宛先に転送）する（ステップＳ２０２）。

制御部１００は、クライアント３０からのメッセージをモバイル端末装置４０に転送したことを示す情報（例えば「転送ＯＫ」）を、ステップＳ１０２にて新たに生成されたレコードの「通知結果」フィールドに登録する（ステップＳ２０３）。

制御部１００は、メッセージをモバイル端末装置４０に転送したことをクライアント３０に通知する（ステップＳ２０４）。この通知により、医師は、患者に対してメッセージが正常に送信されたことを把握することができる。

メッセージ本文に個人情報が含まれる（言い換えると、メッセージが適切でない）場合（ステップＳ２０１：ＮＯ）、このままメッセージを一斉送信すると、ある患者の個人情報が他の患者に知られる可能性がある。そこで、制御部１００は、複数のモバイル端末装置４０に対するメッセージの転送を中止する（ステップＳ２０５）。これにより、患者の個人情報が他者に流出することが避けられる。

制御部１００は、クライアント３０からのメッセージの転送を中止したことを示す情報（例えば「転送ＮＧ」）を、ステップＳ１０２にて新たに生成されたレコードの「通知結果」フィールドに登録する（ステップＳ２０６）。

なお、「通知結果」フィールドに登録された情報は、適切でないメッセージの転送を中止できたかどうか（別の観点では、適切なメッセージを転送できたかどうか）を評価する情報として有用である。

制御部１００は、モバイル端末装置４０へのメッセージの転送を中止したことをクライアント３０に通知する（ステップＳ２０７）。この通知により、医師は、患者に対してメッセージが送信されなかったことを把握することができる。なお、この通知には、医師へのアドバイス（例えば、メッセージ本文に患者の個人情報が含まれていたためメッセージが送信されなかったこと、患者の個人情報を削除したうえでメッセージを再送すること、など）が含まれていてもよい。

このように、ステップＳ２０１において、制御部１００は、受信部１００ａにより受信したメッセージの適否を判定する適否判定部１００ｂとして動作する。具体的には、適否判定部１００ｂとして動作する制御部１００は、メッセージが複数のモバイル端末装置４０に一斉送信されるものである場合、メッセージに患者の個人情報が含まれるか否かによって、メッセージの適否を判定する。

また、ステップＳ２０５において、制御部１００は、適否判定部１００ｂによりメッセージが適切でないと判定された場合にモバイル端末装置４０へのメッセージの転送を中止する転送中止部１００ｃとして動作する。

また、ステップＳ２０７において、制御部１００は、転送中止部１００ｃによりモバイル端末装置４０へのメッセージの転送が中止されたことをクライアント３０に通知する通知部１００ｄとして動作する。

ここで、患者（具体的には、メッセージ本文に含まれる個人情報によって特定される患者）が個人情報を他者に開示することについて同意している場合を考える。この場合、制御部１００は、例外的に、メッセージで指定された全ての宛先にメッセージを一斉送信してもよい。個人情報の開示に患者が同意しているかどうかの情報は、例えば患者情報テーブル１４２に登録されている。

なお、患者の個人情報に代えて又は加えて、他の特定の情報がメッセージに含まれるか否かによって、メッセージの適否を判定してもよい。

一例として、医師が意図せずとも、広告宣伝に該当する内容がメッセージに含まれてしまうケースが考えられる。このようなメッセージ（以下「広告宣伝メッセージ」と記す。）を患者の同意なしで送信すると、特定電子メール法に抵触する可能性がある。そこで、制御部１００は、広告宣伝メッセージか否かによって、メッセージの適否を判定してもよい。

なお、広告宣伝メッセージを送信することについて患者が同意している場合、制御部１００は、広告宣伝メッセージをモバイル端末装置４０に送信してもよい。広告宣伝メッセージの送信に患者が同意しているかどうかの情報は、例えば患者情報テーブル１４２に登録されている。

図１０の説明に戻る。ステップＳ１０３にて単一の通知先を取得していた場合（ステップＳ１０４：ＮＯ）、制御部１００は、ステップＳ１０６のメッセージ適否判定処理を実行する。概説すると、ステップＳ１０６では、診察に関する情報が誤りである可能性がある場合、モバイル端末装置４０に対するメッセージの転送を中止し、その可能性がないとみなされる場合、モバイル端末装置４０に対してメッセージを転送する。

なお、制御部１００は、ステップＳ１０６のメッセージ適否判定処理の実行後、図１０のフローチャートの処理を終了し、クライアント３０からモバイル端末装置４０へのメッセージの受信を待機する状態に復帰する。

図１２は、図１０のステップＳ１０６のメッセージ適否判定処理を示すフローチャートである。

図１２に示されるように、制御部１００は、クライアント３０から受信したメッセージの適否の可能性を判定する（ステップＳ３０１）。例示的には、制御部１００は、ステップＳ１０３にて「共有内容」フィールドに登録されたメッセージ本文に薬の名称が含まれるか否かを判定する。補足すると、制御部１００は、薬の情報を保持するデータベース（不図示）を照会し、照会結果に基づいてメッセージ本文に薬の名称が含まれるか否かを判定する。

メッセージ本文に薬の名称が含まれない場合（ステップＳ３０１：ＮＯ）、診察に関する情報が誤りである可能性がないとみなされる（言い換えると、メッセージが適切であるとみなされる。）。この場合、制御部１００は、フラグをオンして（ステップＳ３０２）、ステップＳ３０６の処理に進む。

メッセージ本文に薬の名称が含まれる場合（ステップＳ３０１：ＹＥＳ）、クライアント３０から受信したメッセージが適切でない可能性がある。そこで、制御部１００は、電子カルテサーバ２２にアクセスして、この名称の薬が患者に処方されたことがあるか否かを判定する（ステップＳ３０３）。

例示的には、制御部１００は、予約・診察情報テーブル２２４のなかから、該当する患者の患者ＩＤが登録されたレコードを抽出し、抽出された各レコードの予約・診察ＩＤを取得する。制御部１００は、取得された予約・診察ＩＤのレコードを投薬情報テーブル２２６のなかから抽出する。制御部１００は、抽出された投薬情報テーブル２２６のレコードの「薬名称」フィールドを照会し、メッセージ本文に含まれる薬と一致する名称があるか否かを判定する。一致する名称がある場合、メッセージ本文に含まれる薬が患者に過去に処方されている。一致する名称がない場合、メッセージ本文に含まれる薬が患者に過去に処方されたことがない。

メッセージ本文に含まれる薬が患者に処方されたことがある場合（ステップＳ３０３：ＹＥＳ）、診察に関する情報が誤りである可能性がないとみなされる（言い換えると、メッセージが適切であるとみなされる。）。この場合、制御部１００は、フラグをオンして（ステップＳ３０４）、ステップＳ３０６の処理に進む。

メッセージ本文に含まれる薬が患者に処方されたことがない場合（ステップＳ３０３：ＮＯ）、例えば他の患者に処方すべき薬の情報がメッセージに含まれている等の理由により、メッセージが適切でない可能性がある。そこで、制御部１００は、フラグをオフして（ステップＳ３０５）、ステップＳ３０６の処理に進む。

このように、ステップＳ３０３～Ｓ３０５において、制御部１００は、電子カルテサーバ２２に登録された情報に基づいてメッセージの適否を判定する適否判定部１００ｂとして動作する。

フラグがオンの場合（ステップＳ３０６：ＹＥＳ）、制御部１００は、モバイル端末装置４０にメッセージを転送する（ステップＳ３０７）。制御部１００は、クライアント３０からのメッセージをモバイル端末装置４０に転送したことを示す情報を、ステップＳ１０２にて新たに生成されたレコードの「通知結果」フィールドに登録する（ステップＳ３０８）。制御部１００は、メッセージをモバイル端末装置４０に転送したことをクライアント３０に通知する（ステップＳ３０９）。

フラグがオフの場合（ステップＳ３０６：ＮＯ）、制御部１００は、モバイル端末装置４０に対するメッセージの転送を中止する（ステップＳ３１０）。これにより、適切でないメッセージが患者に送信されるのを防ぐことができる。制御部１００は、クライアント３０からのメッセージの転送を中止したことを示す情報を、ステップＳ１０２にて新たに生成されたレコードの「通知結果」フィールドに登録する（ステップＳ３１１）。制御部１００は、モバイル端末装置４０へのメッセージの転送を中止したことをクライアント３０に通知する（ステップＳ３１２）。

なお、投薬情報に代えて又は加えて、診察に関する他の情報が誤りであるか否かによって、メッセージの適否を判定してもよい。一例として、制御部１００は、電子カルテサーバ２２にアクセスして、適正な診療科からメッセージが送信されたか否かを判定する。

例示的には、制御部１００は、予約・診察情報テーブル２２４のなかから、該当する患者の患者ＩＤが登録されたレコードを抽出し、抽出された各レコードの診療科ＩＤを取得する。この診療科ＩＤは、患者が通う診療科を示す。

メッセージのヘッダには、メッセージを送信した医師が所属する診療科の診療科ＩＤが含まれる。制御部１００は、抽出された各レコードの診療科ＩＤのなかに、メッセージのヘッダに含まれる診療科ＩＤと一致するものがあるか否かを判定する。一致する診療科ＩＤがある場合、患者が通う診療科からメッセージが送信されている。そのため、制御部１００は、メッセージが適切であると判定する。一致する診療科ＩＤがない場合、患者が通っていない診療科からメッセージが送信されている。この場合、例えば医師がメッセージの送信先を誤った可能性がある。そのため、制御部１００は、メッセージが適切でないと判定する。

制御部１００は、履歴情報テーブル１４４に登録された履歴情報を活用してクライアント３０の不正利用の可能性を判定することができる。図１３に、この不正利用の可能性を判定する処理のフローチャートを示す。業務終了後の定刻（例えば２０：００）になると、図１３のフローチャートの処理の実行が開始される。なお、この処理の実行頻度や実行開始時刻は設定変更可能であってもよい。

図１３に示されるように、制御部１００は、クライアント３０の不正利用の可能性を判定するための対象期間を設定する（ステップＳ４０１）。対象期間は、例えば一日（本実施形態では、前日２０：００から本日２０：００までの期間）である。なお、対象期間は設定変更可能であってもよい。

制御部１００は、履歴情報テーブル１４４のなかから、対象期間内にモバイル端末装置４０に送信されたメッセージのレコードを抽出する（ステップＳ４０２）。例示的には、「情報共有日時」フィールドに登録された日時が対象期間内で且つ「通知結果」フィールドに「転送ＯＫ」の情報が登録されたレコードが抽出される。便宜上、ステップＳ４０２にて抽出された少なくとも１つのレコードを「第１の抽出レコード群」と記す。

制御部１００は、対象期間内において同じ患者に対して多数のメッセージが送信されたか否かを判定する（ステップＳ４０３）。

例示的には、制御部１００は、第１の抽出レコード群のなかに同じ患者ＩＤが登録されたレコードが所定数（例えば１０通／日）以上あるか否かを判定する。

該当レコードが所定数以上ある場合（ステップＳ４０３：ＹＥＳ）、対象期間内において同じ患者に対して多数のメッセージが送信されている。例えば医師がクライアント３０を用いて患者に私的なメッセージを送信したなど、クライアント３０を不正利用した可能性がある。そこで、制御部１００は、該当レコードに登録された情報共有日時及び医師ＩＤを取得し、取得された情報共有日時及び医師ＩＤとともに、疑わしい理由（例えば情報共有頻度過多）をメモリ１４０に記録して（ステップＳ４０４）、ステップＳ４０５の処理に進む。

該当レコードが所定数未満の場合（ステップＳ４０３：ＮＯ）、対象期間内において同じ患者に対して多数のメッセージが送信されていない。この場合、情報共有数という観点では、クライアント３０が不正利用された可能性がないとみなされる。そのため、制御部１００は、ステップＳ４０４の処理を実行せずに、ステップＳ４０５の処理に進む。

制御部１００は、業務時間外に患者に対してメッセージが送信されたか否かを判定する（ステップＳ４０５）。

例示的には、制御部１００は、第１の抽出レコード群のなかから、業務時間外（例えば前日の２０：００から今日７：００までの期間）にモバイル端末装置４０に送信されたメッセージのレコードを抽出する。レコードが抽出された場合、業務時間外であるにも拘わらず患者に対してメッセージが送信されている（ステップＳ４０５：ＹＥＳ）。この場合も、例えば医師がクライアント３０を用いて患者に私的なメッセージを送信したなど、クライアント３０を不正利用した可能性がある。そこで、制御部１００は、該当レコードに登録された情報共有日時及び医師ＩＤを取得し、取得された情報共有日時及び医師ＩＤとともに、疑わしい理由（例えば情報共有時間異常）をメモリ１４０に記録して（ステップＳ４０６）、ステップＳ４０７の処理に進む。

レコードが抽出されない場合、業務時間外に患者に対してメッセージが送信されていない（ステップＳ４０５：ＮＯ）。この場合、情報共有時間という観点では、クライアント３０が不正利用された可能性がないとみなされる。そのため、制御部１００は、ステップＳ４０６の処理を実行せずに、ステップＳ４０７の処理に進む。

制御部１００は、対象期間内に医師が送信したメッセージの宛先がその医師の診察実績のある患者の宛先であるか否かを判定する（ステップＳ４０７）。

例示的には、制御部１００は、第１の抽出レコード群の各レコードの医師ＩＤと患者ＩＤとの組合せを取得する。制御部１００は、取得された組合せ毎に、予約・診察情報テーブル２２４のなかに同じ組合せ（すなわち医師ＩＤと患者ＩＤ）を持つレコードがあるか否かを判定する。

予約・診察情報テーブル２２４のなかに同じ組合せを持つレコードがない場合（ステップＳ４０７：ＮＯ）、医師が診察実績のない患者にメッセージを送信している可能性が高い。この場合も、例えば医師がクライアント３０を用いて患者に私的なメッセージを送信したなど、クライアント３０を不正利用した可能性がある。そこで、制御部１００は、該当レコードに登録された情報共有日時及び医師ＩＤを取得し、取得された情報共有日時及び医師ＩＤとともに、疑わしい理由（例えば診断未実施）をメモリ１４０に記録して（ステップＳ４０８）、ステップＳ４０９の処理に進む。

予約・診察情報テーブル２２４のなかに同じ組合せを持つレコードがある場合（ステップＳ４０７：ＹＥＳ）、医師が診察実績のある患者にメッセージを送信している。この場合、診察実績の有無の観点では、クライアント３０が不正利用された可能性がないとみなされる。そのため、制御部１００は、ステップＳ４０８の処理を実行せずに、ステップＳ４０９の処理に進む。

このように、ステップＳ４０３、Ｓ４０５及びＳ４０７において、制御部１００は、記録部１００ｅに記録された送信履歴に基づいてクライアント３０の不正利用の可能性を判定する不正利用判定部１００ｆとして動作する。

制御部１００は、ステップＳ４０４、Ｓ４０６、Ｓ４０８の何れかにおいて不正利用の可能性を示す情報がメモリ１４０に記録されたか否かを判定する（ステップＳ４０９）。

不正利用の可能性を示す情報がメモリ１４０に記録された場合（ステップＳ４０９：ＹＥＳ）、制御部１００は、例えば業務監査役のクライアント３０に対し、メモリに記録された不正利用の可能性を示す情報を通知して（ステップＳ４１０）、図１３のフローチャートの処理を終了する。不正利用の可能性を示す情報がメモリ１４０に記録されていない場合（ステップＳ４０９：ＮＯ）、制御部１００は、例えば業務監査役のクライアント３０に対し、不正利用の可能性を示す情報がないことを通知して（ステップＳ４１１）、図１３のフローチャートの処理を終了する。これらの通知をもとに、業務監査役が、クライアント３０が実際に不正利用されたかどうかを判断することができる。

なお、図１３のフローチャートの次回の実行開始時、メモリ１４０に記録された不正利用の可能性を示す情報はリセット（消去）される。

なお、本発明は上述した実施形態そのままに限定されるものではなく、実施段階でのその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施形態に示される全構成要素を適宜組み合わせても良い。更に、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。このような、発明の趣旨を逸脱しない範囲内において種々の変形や応用が可能である。

１ ：医療システム
１０ ：サーバ
２０ ：電子カルテシステム
２２ ：電子カルテサーバ
３０ ：クライアント
４０ ：モバイル端末装置
１００ ：制御部
１００Ａ ：ＣＰＵ
１００Ｂ ：ＲＡＭ
１００Ｃ ：ＲＯＭ
１００Ｄ ：入出力インタフェース
１００Ｅ ：表示制御回路
１００Ｆ ：バスライン
１００ａ ：受信部
１００ｂ ：適否判定部
１００ｃ ：転送中止部
１００ｄ ：通知部
１００ｅ ：記録部
１００ｆ ：不正利用判定部
１１０ ：通信インタフェース
１２０ ：操作部
１３０ ：モニタ
１４０ ：メモリ
１４２ ：患者情報テーブル
１４４ ：履歴情報テーブル
２２０ ：診療科情報テーブル
２２２ ：医師情報テーブル
２２４ ：診察情報テーブル
２２６ ：投薬情報テーブル

Claims (6)

1. 医療施設が有する施設側端末装置から患者が有する患者側端末装置へのメッセージを中継するサーバであって、
   前記メッセージを前記施設側端末装置より受信する受信部と、
   前記受信部により受信したメッセージの適否を判定する適否判定部と、
   前記適否判定部により前記メッセージが適切でないと判定された場合に前記患者側端末装置への前記メッセージの転送を中止する転送中止部と、
   を備える、
   サーバ。
2. 前記適否判定部は、前記メッセージがそれぞれ異なる患者が有する複数の前記患者側端末装置に一斉送信されるものか否かを判定し、前記メッセージが前記複数の患者側端末装置に一斉送信されるものである場合、前記メッセージに患者の個人情報が含まれるか否かによって、前記メッセージの適否を判定する、
   請求項１に記載のサーバ。
3. 前記サーバは電子カルテサーバにアクセス可能であり、
   前記適否判定部は、前記電子カルテサーバに登録された情報に基づいて前記メッセージの適否を判定する、
   請求項１又は請求項２に記載のサーバ。
4. 前記転送中止部により前記患者側端末装置への前記メッセージの転送が中止されたことを前記施設側端末装置に通知する通知部、を更に備える、
   請求項１から請求項３の何れか一項に記載のサーバ。
5. 前記メッセージの送信履歴を記録する記録部と、
   前記記録部に記録された送信履歴に基づいて前記施設側端末装置の不正利用の可能性を判定する不正利用判定部と、を更に備える、
   請求項１から請求項４の何れか一項に記載のサーバ。
6. 医療施設が有する施設側端末装置と、
   患者が有する患者側端末装置と、
   前記施設側端末装置から前記患者側端末装置へのメッセージを中継する、請求項１から請求項５の何れか一項に記載のサーバと、を備える、
   医療システム。

Images