(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-02
(45)【発行日】2024-08-13
(54)【発明の名称】サーバ及び医療システム
(51)【国際特許分類】
G16H 20/00 20180101AFI20240805BHJP
【FI】
G16H20/00
(21)【出願番号】P 2021110325
(22)【出願日】2021-07-01
【審査請求日】2023-08-09
(73)【特許権者】
【識別番号】000237639
【氏名又は名称】富士通フロンテック株式会社
(74)【代理人】
【識別番号】110004185
【氏名又は名称】インフォート弁理士法人
(74)【代理人】
【識別番号】100121083
【氏名又は名称】青木 宏義
(74)【代理人】
【識別番号】100138391
【氏名又は名称】天田 昌行
(74)【代理人】
【識別番号】100074099
【氏名又は名称】大菅 義之
(72)【発明者】
【氏名】桐生 智明
(72)【発明者】
【氏名】石塚 達也
(72)【発明者】
【氏名】悴田 剛
【審査官】鹿野 博嗣
(56)【参考文献】
【文献】特開2020-150562(JP,A)
【文献】特開2008-276507(JP,A)
【文献】特開2009-003548(JP,A)
【文献】特開平05-183576(JP,A)
【文献】特開2008-293294(JP,A)
【文献】特開2010-211492(JP,A)
【文献】米国特許出願公開第2010/0198931(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G16H 10/00-80/00
(57)【特許請求の範囲】
【請求項1】
医療施設が有する施設側端末装置から患者が有する患者側端末装置へのメッセージを中継するサーバであって、
前記メッセージを前記施設側端末装置より受信する受信部と、
前記受信部により受信したメッセージの適否を判定する適否判定部と、
前記適否判定部により前記メッセージが適切でないと判定された場合に前記患者側端末装置への前記メッセージの転送を中止する転送中止部と、
を備え
、
前記適否判定部は、前記メッセージがそれぞれ異なる患者が有する複数の前記患者側端末装置に一斉送信されるものか否かを判定し、前記メッセージが前記複数の患者側端末装置に一斉送信されるものである場合、前記メッセージに患者の個人情報が含まれるか否かによって、前記メッセージの適否を判定する、
サーバ。
【請求項2】
前記サーバは電子カルテサーバにアクセス可能であり、
前記適否判定部は、前記電子カルテサーバに登録された情報に基づいて前記メッセージの適否を判定する、
請求項1に記載のサーバ。
【請求項3】
前記転送中止部により前記患者側端末装置への前記メッセージの転送が中止されたことを前記施設側端末装置に通知する通知部、を更に備える、
請求項1
または請求項2に記載のサーバ。
【請求項4】
前記通知部による通知には、前記メッセージの送信者へのアドバイスが含まれる、
請求項3に記載のサーバ。
【請求項5】
前記メッセージの送信履歴を記録する記録部と、
前記記録部に記録された送信履歴に基づいて前記施設側端末装置の不正利用の可能性を判定する不正利用判定部と、を更に備える、
請求項1から請求項4の何れか一項に記載のサーバ。
【請求項6】
医療施設が有する施設側端末装置と、
患者が有する患者側端末装置と、
前記施設側端末装置から前記患者側端末装置へのメッセージを中継する、請求項1から請求項5の何れか一項に記載のサーバと、を備える、
医療システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サーバ及び医療システムに関する。
【背景技術】
【0002】
医師や看護師等の医療従事者から患者に対してメッセージを送信するための医療システムが知られている。例えば特許文献1に、この種の医療システムの具体的構成が記載されている。
【0003】
特許文献1に記載の医療システムは、病院内のネットワークシステムで相互通信可能に接続されたサーバと医療従事者用情報端末を備える。サーバには、患者用情報端末からアップロードされた患者の測定データ(体重、血圧、血糖値等)が保存される。医療従事者用情報端末は、サーバにアップロードされた測定データを受信し、この測定データを確認した医療従事者に患者へのアドバイスを入力させ、入力されたアドバイスを含むメッセージを患者用情報端末に送信する。
【先行技術文献】
【特許文献】
【0004】
【発明の概要】
【発明が解決しようとする課題】
【0005】
特許文献1に記載の医療システムでは、患者へのメッセージに定型の内容だけでなく任意の内容も含めることができる。この場合、医療従事者が意図しなくとも、メッセージの中に他の患者の個人情報や誤った診察情報が含まれてしまう可能性がある。すなわち、適切でないメッセージが患者に送られる可能性がある。
【0006】
本発明は、上記の事情に鑑みてなされたものであり、患者に対して適切でないメッセージが送られるのを防ぐことができるサーバ及びこのようなサーバを備える医療システムを提供することを目的とする。
【課題を解決するための手段】
【0007】
本発明の一実施形態に係るサーバは、医療施設が有する施設側端末装置から患者が有する患者側端末装置へのメッセージを中継するサーバであり、前記メッセージを前記施設側端末装置より受信する受信部と、前記受信部により受信したメッセージの適否を判定する適否判定部と、前記適否判定部により前記メッセージが適切でないと判定された場合に前記患者側端末装置への前記メッセージの転送を中止する転送中止部と、を備える。前記適否判定部は、前記メッセージがそれぞれ異なる患者が有する複数の前記患者側端末装置に一斉送信されるものか否かを判定し、前記メッセージが前記複数の患者側端末装置に一斉送信されるものである場合、前記メッセージに患者の個人情報が含まれるか否かによって、前記メッセージの適否を判定する。
【0008】
本発明の一実施形態に係る医療システムは、医療施設が有する施設側端末装置と、患者が有する患者側端末装置と、前記施設側端末装置から前記患者側端末装置へのメッセージを中継する、上記のサーバと、を備える。
【発明の効果】
【0009】
本発明の一実施形態によれば、サーバ及び医療システムにおいて、患者に対して適切でないメッセージが送られるのを防ぐことができる。
【図面の簡単な説明】
【0010】
【
図1】本発明の一実施形態に係る医療システムを示すブロック図である。
【
図2】本発明の一実施形態に係るサーバのハードウェア構成を示すブロック図である。
【
図3】本発明の一実施形態に係る患者情報テーブルの一例を示す図である。
【
図4】本発明の一実施形態に係る履歴情報テーブルの一例を示す図である。
【
図5】本発明の一実施形態に係る診療科情報テーブルの一例を示す図である。
【
図6】本発明の一実施形態に係る医師情報テーブルの一例を示す図である。
【
図7】本発明の一実施形態に係る予約・診察情報テーブルの一例を示す図である。
【
図8】本発明の一実施形態に係る投薬情報テーブルの一例を示す図である。
【
図9】本発明の一実施形態に係る医療システムの機能構成を示すブロック図である。
【
図10】本発明の一実施形態において、サーバの制御部により実行される、メッセージ中継プログラムを示すフローチャートである。
【
図11】
図10のステップS105のメッセージ適否判定処理を示すフローチャートである。
【
図12】
図10のステップS106のメッセージ適否判定処理を示すフローチャートである。
【
図13】クライアントの不正利用の可能性を判定する処理を示すフローチャートである。
【発明を実施するための形態】
【0011】
以下、本発明の一実施形態について、詳細に説明する。
【0012】
図1は、本発明の一実施形態に係る医療システム1を示すブロック図である。
図1に示されるように、医療システム1は、サーバ10、電子カルテシステム20、クライアント30及びモバイル端末装置40を備える。
【0013】
サーバ10、電子カルテシステム20及びクライアント30は、医療施設(具体的には病院)に設置されており、病院内に構築された院内ネットワーク(例えばLAN:Local Area Network)内で相互通信可能に接続される。
【0014】
サーバ10は、ハードウェア構成としては一般的な構成(汎用のサーバ)を有する。
図2は、本発明の一実施形態に係るサーバ10のハードウェア構成を示すブロック図である。サーバ10は、
図2に示されるように、制御部100、通信インタフェース110、操作部120、モニタ130及びメモリ140を備える。
【0015】
なお、サーバ10は、
図2に示されていない他のハードウェア構成を備えていてもよい。また、サーバ10は、
図2に示される全てのハードウェア構成を備えるものでなくてもよい。例えば、操作部120やモニタ130を備えないサーバ10も本発明の範疇である。すなわち、サーバ10の態様には自由度があり、各種の設計変更が可能である。
【0016】
制御部100は、サーバ10全体を制御するものであり、CPU(Central Processing Unit)100A、RAM(Random Access Memory)100B、ROM(Read Only Memory)100C、入出力インタフェース100D、表示制御回路100E及びこれらのポートを結ぶバスライン100F等よりなるマイクロコンピュータである。
【0017】
CPU100Aは、ROM100Cに記憶されたプログラムを読み込み、読み込まれたプログラムに従ってサーバ10を制御する。
【0018】
RAM100Bは、プログラムやデータを一時的に記憶する記憶部であり、ワークエリアを提供する。RAM100Bは、例えば、DRAM(Dynamic Random Access Memory)である。
【0019】
ROM100Cは、メッセージ中継プログラムをはじめとする各種プログラムを記憶する不揮発性メモリである。ROM100Cは、例えばフラッシュメモリである。
【0020】
ROM100Cに記憶されたメッセージ中継プログラムは、クライアント30からモバイル端末装置40へのメッセージを中継するプログラムである。概略的には、メッセージ中継プログラムは、メッセージをクライアント30より受信し、受信したメッセージの適否を判定し、メッセージが適切であると判定した場合にはモバイル端末装置40へメッセージを転送し、メッセージが適切でないと判定した場合にはモバイル端末装置40へのメッセージの転送を中止するプログラムである。メッセージ中継プログラムの詳細は後述する。
【0021】
なお、このメッセージ中継プログラムの実行により、クライアント30からモバイル端末装置40(言い換えると患者)に対して適切でないメッセージが送られるのを防ぐことができる。
【0022】
入出力インタフェース100Dは、通信インタフェース110及び操作部120と接続されており、通信インタフェース110及び操作部120とCPU100Aとの通信を中継する。
【0023】
通信インタフェース110は、電子カルテシステム20、クライアント30、モバイル端末装置40と通信する。通信インタフェース110は、例えば、電子カルテサーバ22にアクセスして必要な情報を取得し、また、クライアント30からのメッセージをモバイル端末装置40へ転送する。
【0024】
操作部120は、キーボードやマウス、タッチパネル等のユーザインタフェースであり、オペレータからの入力操作を受け付けてCPU100Aに通知する。
【0025】
モニタ130は、例えばLCD(Liquid Crystal Display)であり、表示制御回路100Eの制御下で駆動する。表示制御回路100Eは、例えば設定画面をモニタ130に表示させる。
【0026】
メモリ140は、HDD(Hard Disk Drive)やSSD(Solid State Drive)であり、患者情報テーブル142及び履歴情報テーブル144を保持する。
【0027】
患者情報テーブル142には、患者に関する情報が登録される。例えば病院の事務員が不図示の端末装置を操作して、初診時に患者が記入した問診票に記載の情報を患者情報テーブル142に登録する。
【0028】
図3に、患者情報テーブル142の一例を示す。
図3に示されるように、患者情報テーブル142の各レコードには、患者ID(Identification)、患者氏名、通知先、電話番号等の情報が登録される。
【0029】
患者IDは、患者情報テーブル142の各レコードに割り当てられたIDである。患者氏名は、モバイル端末装置40の保有者を示す。通知先は、例えばモバイル端末装置40にて受信可能なメールアドレスである。電話番号は、例えばモバイル端末装置40又は患者の自宅の電話番号である。
【0030】
履歴情報テーブル144には、クライアント30からモバイル端末装置40へのメッセージに関する履歴情報が登録される。メッセージに関する履歴情報は、サーバ10の制御部100によるメッセージ中継プログラムの実行時に、履歴情報テーブル144に登録される。
【0031】
図4に、履歴情報テーブル144の一例を示す。
図4に示されるように、履歴情報テーブル144の各レコードには、履歴ID、情報共有日時、患者ID、通知先、共有内容、診療科ID、医師ID、通知結果等の情報が登録される。
【0032】
履歴IDは、履歴情報テーブル144の各レコードに割り当てられたIDである。情報共有日時は、クライアント30からモバイル端末装置40へのメッセージをサーバ10が受信した日時(又はサーバ10がメッセージをモバイル端末装置40へ転送した日時)を示す。共有内容は、メッセージ本文を示す。診療科IDは、後述する診療科情報テーブル220の各レコードに割り当てられたIDである。医師IDは、後述する医師情報テーブル222の各レコードに割り当てられたIDである。通知結果は、クライアント30からのメッセージをモバイル端末装置40に転送したか否かを示す情報である。
【0033】
履歴情報テーブル144の患者IDは、メッセージの送信相手(すなわち患者)のIDを示す。履歴情報テーブル144は、例えば患者IDをキーとして、患者情報テーブル142と関連付けられる。このように、本実施形態では、同じ名称のフィールドによってテーブル同士が関連付けられる。
【0034】
なお、サーバ10の各テーブルに登録されるフィールドは、上記に例示されるものに限らない。各テーブルには、上記に例示されたフィールドに代えて別のフィールドが登録されてもよく、また、上記に例示されたフィールドに加えて別のフィールドが登録されてもよい。一例として、患者情報テーブル142には、上記に例示されたフィールドに加えて、性別、年齢、体重、身長等のフィールドが登録されてもよい。
【0035】
クライアント30は、施設側端末装置の一例である。クライアント30もサーバ10と同様に、ハードウェア構成として一般的な構成(汎用のPC(Personal computer))を有する。クライアント30は、医療従事者(例えば医師)により操作される端末装置であり、例えば各診療科の各診察室に設置される。
【0036】
クライアント30は、医師による操作に従い、例えば患者の診察記録を電子カルテシステム20に登録する。また、クライアント30は、医師による操作に従い、定型の又は任意のメッセージをモバイル端末装置40へ送信する。このメッセージは、サーバ10で中継されてモバイル端末装置40へ送信される。
【0037】
クライアント30より送信されるメッセージは、例えば、RFC(Request for Comments)に準拠した一般的な電子メールメッセージである。なお、メッセージは、SMS(Short Message Service)メッセージやコミュニケーションアプリによるインスタントメッセージであってもよい。コミュニケーションアプリは、メッセージングアプリ、チャットアプリ、SNS(Social Networking Service)アプリと呼称されることもある。
【0038】
モバイル端末装置40は、患者側端末装置の一例である。モバイル端末装置40は、患者が保有するモバイル端末装置であり、例えばスマートフォン、フィーチャフォン、タブレット端末、ノートPCである。モバイル端末装置40は、公衆回線やVPN(Virtual Private Network)等の閉域網の通信回線を介してサーバ10と通信可能に接続される。
【0039】
電子カルテシステム20は、医師が患者の診察記録(カルテ)を記入して管理するためのシステムである。電子カルテシステム20は、電子カルテサーバ22を含む。
【0040】
電子カルテサーバ22は、サーバ10と同様に、ハードウェア構成として一般的な構成(汎用のサーバ)を有する。
【0041】
電子カルテサーバ22のメモリにもテーブルが保持される。例示的には、電子カルテサーバ22のメモリには、診療科情報テーブル220、医師情報テーブル222、予約・診察情報テーブル224、投薬情報テーブル226が保持される。
【0042】
診療科情報テーブル220には、診療科に関する情報が予め登録される。診療科情報テーブル220は、例えば診療科が新設されたり統廃合されたりした場合に更新される。
【0043】
図5に、診療科情報テーブル220の一例を示す。
図5に示されるように、診療科情報テーブル220の各レコードには、診療科ID、診療科名等の情報が登録される。診療科名は、診療科IDに関連付けられた診療科の名称である。
【0044】
医師情報テーブル222には、医師に関する情報が予め登録される。医師情報テーブル222は、例えば医師の着任や退職等に応じて更新される。
【0045】
図6に、医師情報テーブル222の一例を示す。
図6に示されるように、医師情報テーブル222の各レコードには、医師ID、診療科ID、医師名等の情報が登録される。医師名は、診療科IDと関連付けられた診療科に所属する医師の氏名である。
【0046】
予約・診察情報テーブル224には、診察予約及び診察に関する情報が登録される。
図7に、予約・診察情報テーブル224の一例を示す。
図7に示されるように、予約・診察情報テーブル224の各レコードには、予約・診察ID、診療科ID、診療科名、医師ID、医師名、予約日、予約時間、患者ID、診察日、診察時間、診察内容等の情報が登録される。
【0047】
予約・診察IDは、予約・診察情報テーブル224の各レコードに割り当てられたIDである。例えば、医師がクライアント30を操作して電子カルテシステム20にログインし、患者の診察予約を行うと、予約内容に応じたレコードが予約・診察情報テーブル224に登録される。
【0048】
例示的には、医師がクライアント30に対して予約日時(予約日、予約時間)を入力すると、クライアント30を介して電子カルテサーバ22のプログラムが実行される。電子カルテサーバ22は、診察情報テーブル224に新たな予約・診察IDのレコードを生成し、このレコードに、予約日時を登録するとともに既存の情報(予約患者の患者ID、診察する医師名及び医師ID並びにこの医師が所属する診療科名及び診療科ID)を登録する。
【0049】
なお、医師は、ログインIDを入力して電子カルテシステム20へログインしている。このログインIDは、診療科情報テーブル220及び医師情報テーブル222と関連付けられている。また、診察予約時、クライアント30は、医師による操作に従い、予約患者の情報を患者情報テーブル142から取得している。そのため、患者ID、医師名、医師ID、診療科名及び診療科IDは、電子カルテサーバ22から呼び出すことができる。
【0050】
予約された診察を行う際、電子カルテサーバ22は、クライアント30からの指示に応じて、該当する予約・診察IDのレコードを呼び出す。医師がクライアント30に対して診察結果等を入力すると、電子カルテサーバ22は、その情報(診察日、診察時間、診察内容等)を、呼出中の予約・診察IDのレコードに登録する。
【0051】
投薬情報テーブル226には、患者に処方する薬に関する情報が登録される。
図8に、投薬情報テーブル226の一例を示す。
図8に示されるように、投薬情報テーブル226の各レコードには、投薬ID、予約・診察ID、薬名称、数量等の情報が登録される。
【0052】
医師は、クライアント30に対して診察結果等を入力する際、薬の処方情報(薬名称、数量等)も入力する。電子カルテサーバ22は、薬の処方情報が入力されると、投薬情報テーブル226に新たな投薬IDのレコードを生成し、このレコードに、該当する予約・診察ID、薬名称、数量等の情報を登録する。
【0053】
なお、電子カルテサーバ22の各テーブルに登録されるフィールドは、上記に例示されるものに限らない。各テーブルには、上記に例示されたフィールドに代えて別のフィールドが登録されてもよく、また、上記に例示されたフィールドに加えて別のフィールドが登録されてもよい。一例として、予約・診察情報テーブル224には、上記に例示されたフィールドに加えて、血圧値、体温、心拍数、脈拍数、酸素飽和度等のバイタルサインのフィールドや、生化学検査、血液検査、脳波検査等の検査値のフィールドが登録されてもよい。
【0054】
図9は、医療システム1の機能構成を示すブロック図である。
図9に示されるように、サーバ10の制御部100は、機能構成として、受信部100a、適否判定部100b、転送中止部100c、通知部100d、記録部100e、不正利用判定部100fを備える。なお、サーバ10は、
図9に示していない他の機能構成を備えていてもよい。
【0055】
図10は、本発明の一実施形態において、サーバ10の制御部100により実行される、メッセージ中継プログラム(言い換えるとメッセージ中継方法)の処理手順を示すフローチャートである。例えば、サーバ10のシステムが起動されると、制御部100がクライアント30からモバイル端末装置40へのメッセージの受信を待機する状態に遷移する。
【0056】
クライアント30からモバイル端末装置40へのメッセージが送信されると、制御部100は、このメッセージを受信する(ステップS101)。すなわち、ステップS101において、制御部100は、メッセージをクライアント30より受信する受信部100aとして動作する。
【0057】
制御部100は、クライアント30からメッセージを受信すると、履歴情報テーブル144に新たな履歴IDのレコードを生成する(ステップS102)。
【0058】
制御部100は、新たに生成されたレコードに対して各種情報を登録する(ステップS103)。例示的には、制御部100は、クライアント30からメッセージを受信した日時を「情報共有日時」フィールドに登録する。また、制御部100は、患者情報テーブル142のなかから、メッセージの送信相手として指定された通知先(すなわちメッセージの宛先)を取得するとともに患者IDを取得し、取得された通知先、患者IDのそれぞれを対応するフィールドに登録する。制御部100は、通知先を複数取得した場合、取得された全ての通知先を「通知先」フィールドに登録するとともに、対応する全ての患者IDを「患者ID」フィールドに登録する。また、制御部100は、メッセージ本文(例えばテキストデータ)を「共有内容」フィールドに登録する。また、制御部100は、メッセージを送信した医師の医師ID及び所属する診療科の診療科IDを取得し、取得された医師ID、患者IDのそれぞれを対応するフィールドに登録する。医師ID、患者IDは、例えばメッセージのヘッダから取得することができる。
【0059】
このように、ステップS103(並びに後述のステップS203及びS206)において、制御部100は、メッセージの送信履歴を記録する記録部100eとして動作する。
【0060】
制御部100は、ステップS103にて複数の通知先を取得したか否かを判定する(ステップS104)。すなわち、ステップS104において、制御部100は、クライアント30から受信したメッセージがそれぞれ異なる患者が有する複数のモバイル端末装置40に一斉送信されるものか否かを判定する適否判定部100bとして動作する。
【0061】
なお、ステップS104において、制御部100は、ステップS103にて複数の通知先を取得したか否かではなく、単純に、メッセージの宛先が複数あるか否かを判定してもよい。
【0062】
ステップS103にて複数の通知先を取得していた場合(ステップS104:YES)、制御部100は、ステップS105のメッセージ適否判定処理を実行する。概説すると、ステップS105では、患者の個人情報が他者に知られる可能性がある場合、モバイル端末装置40に対するメッセージの転送を中止し、その可能性がない場合、モバイル端末装置40に対してメッセージを転送する。
【0063】
なお、制御部100は、ステップS105のメッセージ適否判定処理の実行後、
図10のフローチャートの処理を終了し、クライアント30からモバイル端末装置40へのメッセージの受信を待機する状態に復帰する。
【0064】
図11は、
図10のステップS105のメッセージ適否判定処理を示すフローチャートである。
【0065】
図11に示されるように、制御部100は、クライアント30から受信したメッセージの適否を判定する(ステップS201)。例示的には、制御部100は、ステップS103にて「共有内容」フィールドに登録されたメッセージ本文に特定の情報が含まれるか否かを判定する。
【0066】
特定の情報は、例えば個人情報である。ここでは、患者情報テーブル142の各レコードに登録された患者氏名、通知先、電話番号等の個人情報がメッセージ本文に含まれるか否かが判定される。
【0067】
メッセージ本文に個人情報が含まれない(言い換えると、メッセージが適切な)場合(ステップS201:YES)、制御部100は、メッセージで指定された全ての宛先(複数のモバイル端末装置40)にメッセージを一斉送信(全ての宛先に転送)する(ステップS202)。
【0068】
制御部100は、クライアント30からのメッセージをモバイル端末装置40に転送したことを示す情報(例えば「転送OK」)を、ステップS102にて新たに生成されたレコードの「通知結果」フィールドに登録する(ステップS203)。
【0069】
制御部100は、メッセージをモバイル端末装置40に転送したことをクライアント30に通知する(ステップS204)。この通知により、医師は、患者に対してメッセージが正常に送信されたことを把握することができる。
【0070】
メッセージ本文に個人情報が含まれる(言い換えると、メッセージが適切でない)場合(ステップS201:NO)、このままメッセージを一斉送信すると、ある患者の個人情報が他の患者に知られる可能性がある。そこで、制御部100は、複数のモバイル端末装置40に対するメッセージの転送を中止する(ステップS205)。これにより、患者の個人情報が他者に流出することが避けられる。
【0071】
制御部100は、クライアント30からのメッセージの転送を中止したことを示す情報(例えば「転送NG」)を、ステップS102にて新たに生成されたレコードの「通知結果」フィールドに登録する(ステップS206)。
【0072】
なお、「通知結果」フィールドに登録された情報は、適切でないメッセージの転送を中止できたかどうか(別の観点では、適切なメッセージを転送できたかどうか)を評価する情報として有用である。
【0073】
制御部100は、モバイル端末装置40へのメッセージの転送を中止したことをクライアント30に通知する(ステップS207)。この通知により、医師は、患者に対してメッセージが送信されなかったことを把握することができる。なお、この通知には、医師へのアドバイス(例えば、メッセージ本文に患者の個人情報が含まれていたためメッセージが送信されなかったこと、患者の個人情報を削除したうえでメッセージを再送すること、など)が含まれていてもよい。
【0074】
このように、ステップS201において、制御部100は、受信部100aにより受信したメッセージの適否を判定する適否判定部100bとして動作する。具体的には、適否判定部100bとして動作する制御部100は、メッセージが複数のモバイル端末装置40に一斉送信されるものである場合、メッセージに患者の個人情報が含まれるか否かによって、メッセージの適否を判定する。
【0075】
また、ステップS205において、制御部100は、適否判定部100bによりメッセージが適切でないと判定された場合にモバイル端末装置40へのメッセージの転送を中止する転送中止部100cとして動作する。
【0076】
また、ステップS207において、制御部100は、転送中止部100cによりモバイル端末装置40へのメッセージの転送が中止されたことをクライアント30に通知する通知部100dとして動作する。
【0077】
ここで、患者(具体的には、メッセージ本文に含まれる個人情報によって特定される患者)が個人情報を他者に開示することについて同意している場合を考える。この場合、制御部100は、例外的に、メッセージで指定された全ての宛先にメッセージを一斉送信してもよい。個人情報の開示に患者が同意しているかどうかの情報は、例えば患者情報テーブル142に登録されている。
【0078】
なお、患者の個人情報に代えて又は加えて、他の特定の情報がメッセージに含まれるか否かによって、メッセージの適否を判定してもよい。
【0079】
一例として、医師が意図せずとも、広告宣伝に該当する内容がメッセージに含まれてしまうケースが考えられる。このようなメッセージ(以下「広告宣伝メッセージ」と記す。)を患者の同意なしで送信すると、特定電子メール法に抵触する可能性がある。そこで、制御部100は、広告宣伝メッセージか否かによって、メッセージの適否を判定してもよい。
【0080】
なお、広告宣伝メッセージを送信することについて患者が同意している場合、制御部100は、広告宣伝メッセージをモバイル端末装置40に送信してもよい。広告宣伝メッセージの送信に患者が同意しているかどうかの情報は、例えば患者情報テーブル142に登録されている。
【0081】
図10の説明に戻る。ステップS103にて単一の通知先を取得していた場合(ステップS104:NO)、制御部100は、ステップS106のメッセージ適否判定処理を実行する。概説すると、ステップS106では、診察に関する情報が誤りである可能性がある場合、モバイル端末装置40に対するメッセージの転送を中止し、その可能性がないとみなされる場合、モバイル端末装置40に対してメッセージを転送する。
【0082】
なお、制御部100は、ステップS106のメッセージ適否判定処理の実行後、
図10のフローチャートの処理を終了し、クライアント30からモバイル端末装置40へのメッセージの受信を待機する状態に復帰する。
【0083】
図12は、
図10のステップS106のメッセージ適否判定処理を示すフローチャートである。
【0084】
図12に示されるように、制御部100は、クライアント30から受信したメッセージの適否の可能性を判定する(ステップS301)。例示的には、制御部100は、ステップS103にて「共有内容」フィールドに登録されたメッセージ本文に薬の名称が含まれるか否かを判定する。補足すると、制御部100は、薬の情報を保持するデータベース(不図示)を照会し、照会結果に基づいてメッセージ本文に薬の名称が含まれるか否かを判定する。
【0085】
メッセージ本文に薬の名称が含まれない場合(ステップS301:NO)、診察に関する情報が誤りである可能性がないとみなされる(言い換えると、メッセージが適切であるとみなされる。)。この場合、制御部100は、フラグをオンして(ステップS302)、ステップS306の処理に進む。
【0086】
メッセージ本文に薬の名称が含まれる場合(ステップS301:YES)、クライアント30から受信したメッセージが適切でない可能性がある。そこで、制御部100は、電子カルテサーバ22にアクセスして、この名称の薬が患者に処方されたことがあるか否かを判定する(ステップS303)。
【0087】
例示的には、制御部100は、予約・診察情報テーブル224のなかから、該当する患者の患者IDが登録されたレコードを抽出し、抽出された各レコードの予約・診察IDを取得する。制御部100は、取得された予約・診察IDのレコードを投薬情報テーブル226のなかから抽出する。制御部100は、抽出された投薬情報テーブル226のレコードの「薬名称」フィールドを照会し、メッセージ本文に含まれる薬と一致する名称があるか否かを判定する。一致する名称がある場合、メッセージ本文に含まれる薬が患者に過去に処方されている。一致する名称がない場合、メッセージ本文に含まれる薬が患者に過去に処方されたことがない。
【0088】
メッセージ本文に含まれる薬が患者に処方されたことがある場合(ステップS303:YES)、診察に関する情報が誤りである可能性がないとみなされる(言い換えると、メッセージが適切であるとみなされる。)。この場合、制御部100は、フラグをオンして(ステップS304)、ステップS306の処理に進む。
【0089】
メッセージ本文に含まれる薬が患者に処方されたことがない場合(ステップS303:NO)、例えば他の患者に処方すべき薬の情報がメッセージに含まれている等の理由により、メッセージが適切でない可能性がある。そこで、制御部100は、フラグをオフして(ステップS305)、ステップS306の処理に進む。
【0090】
このように、ステップS303~S305において、制御部100は、電子カルテサーバ22に登録された情報に基づいてメッセージの適否を判定する適否判定部100bとして動作する。
【0091】
フラグがオンの場合(ステップS306:YES)、制御部100は、モバイル端末装置40にメッセージを転送する(ステップS307)。制御部100は、クライアント30からのメッセージをモバイル端末装置40に転送したことを示す情報を、ステップS102にて新たに生成されたレコードの「通知結果」フィールドに登録する(ステップS308)。制御部100は、メッセージをモバイル端末装置40に転送したことをクライアント30に通知する(ステップS309)。
【0092】
フラグがオフの場合(ステップS306:NO)、制御部100は、モバイル端末装置40に対するメッセージの転送を中止する(ステップS310)。これにより、適切でないメッセージが患者に送信されるのを防ぐことができる。制御部100は、クライアント30からのメッセージの転送を中止したことを示す情報を、ステップS102にて新たに生成されたレコードの「通知結果」フィールドに登録する(ステップS311)。制御部100は、モバイル端末装置40へのメッセージの転送を中止したことをクライアント30に通知する(ステップS312)。
【0093】
なお、投薬情報に代えて又は加えて、診察に関する他の情報が誤りであるか否かによって、メッセージの適否を判定してもよい。一例として、制御部100は、電子カルテサーバ22にアクセスして、適正な診療科からメッセージが送信されたか否かを判定する。
【0094】
例示的には、制御部100は、予約・診察情報テーブル224のなかから、該当する患者の患者IDが登録されたレコードを抽出し、抽出された各レコードの診療科IDを取得する。この診療科IDは、患者が通う診療科を示す。
【0095】
メッセージのヘッダには、メッセージを送信した医師が所属する診療科の診療科IDが含まれる。制御部100は、抽出された各レコードの診療科IDのなかに、メッセージのヘッダに含まれる診療科IDと一致するものがあるか否かを判定する。一致する診療科IDがある場合、患者が通う診療科からメッセージが送信されている。そのため、制御部100は、メッセージが適切であると判定する。一致する診療科IDがない場合、患者が通っていない診療科からメッセージが送信されている。この場合、例えば医師がメッセージの送信先を誤った可能性がある。そのため、制御部100は、メッセージが適切でないと判定する。
【0096】
制御部100は、履歴情報テーブル144に登録された履歴情報を活用してクライアント30の不正利用の可能性を判定することができる。
図13に、この不正利用の可能性を判定する処理のフローチャートを示す。業務終了後の定刻(例えば20:00)になると、
図13のフローチャートの処理の実行が開始される。なお、この処理の実行頻度や実行開始時刻は設定変更可能であってもよい。
【0097】
図13に示されるように、制御部100は、クライアント30の不正利用の可能性を判定するための対象期間を設定する(ステップS401)。対象期間は、例えば一日(本実施形態では、前日20:00から本日20:00までの期間)である。なお、対象期間は設定変更可能であってもよい。
【0098】
制御部100は、履歴情報テーブル144のなかから、対象期間内にモバイル端末装置40に送信されたメッセージのレコードを抽出する(ステップS402)。例示的には、「情報共有日時」フィールドに登録された日時が対象期間内で且つ「通知結果」フィールドに「転送OK」の情報が登録されたレコードが抽出される。便宜上、ステップS402にて抽出された少なくとも1つのレコードを「第1の抽出レコード群」と記す。
【0099】
制御部100は、対象期間内において同じ患者に対して多数のメッセージが送信されたか否かを判定する(ステップS403)。
【0100】
例示的には、制御部100は、第1の抽出レコード群のなかに同じ患者IDが登録されたレコードが所定数(例えば10通/日)以上あるか否かを判定する。
【0101】
該当レコードが所定数以上ある場合(ステップS403:YES)、対象期間内において同じ患者に対して多数のメッセージが送信されている。例えば医師がクライアント30を用いて患者に私的なメッセージを送信したなど、クライアント30を不正利用した可能性がある。そこで、制御部100は、該当レコードに登録された情報共有日時及び医師IDを取得し、取得された情報共有日時及び医師IDとともに、疑わしい理由(例えば情報共有頻度過多)をメモリ140に記録して(ステップS404)、ステップS405の処理に進む。
【0102】
該当レコードが所定数未満の場合(ステップS403:NO)、対象期間内において同じ患者に対して多数のメッセージが送信されていない。この場合、情報共有数という観点では、クライアント30が不正利用された可能性がないとみなされる。そのため、制御部100は、ステップS404の処理を実行せずに、ステップS405の処理に進む。
【0103】
制御部100は、業務時間外に患者に対してメッセージが送信されたか否かを判定する(ステップS405)。
【0104】
例示的には、制御部100は、第1の抽出レコード群のなかから、業務時間外(例えば前日の20:00から今日7:00までの期間)にモバイル端末装置40に送信されたメッセージのレコードを抽出する。レコードが抽出された場合、業務時間外であるにも拘わらず患者に対してメッセージが送信されている(ステップS405:YES)。この場合も、例えば医師がクライアント30を用いて患者に私的なメッセージを送信したなど、クライアント30を不正利用した可能性がある。そこで、制御部100は、該当レコードに登録された情報共有日時及び医師IDを取得し、取得された情報共有日時及び医師IDとともに、疑わしい理由(例えば情報共有時間異常)をメモリ140に記録して(ステップS406)、ステップS407の処理に進む。
【0105】
レコードが抽出されない場合、業務時間外に患者に対してメッセージが送信されていない(ステップS405:NO)。この場合、情報共有時間という観点では、クライアント30が不正利用された可能性がないとみなされる。そのため、制御部100は、ステップS406の処理を実行せずに、ステップS407の処理に進む。
【0106】
制御部100は、対象期間内に医師が送信したメッセージの宛先がその医師の診察実績のある患者の宛先であるか否かを判定する(ステップS407)。
【0107】
例示的には、制御部100は、第1の抽出レコード群の各レコードの医師IDと患者IDとの組合せを取得する。制御部100は、取得された組合せ毎に、予約・診察情報テーブル224のなかに同じ組合せ(すなわち医師IDと患者ID)を持つレコードがあるか否かを判定する。
【0108】
予約・診察情報テーブル224のなかに同じ組合せを持つレコードがない場合(ステップS407:NO)、医師が診察実績のない患者にメッセージを送信している可能性が高い。この場合も、例えば医師がクライアント30を用いて患者に私的なメッセージを送信したなど、クライアント30を不正利用した可能性がある。そこで、制御部100は、該当レコードに登録された情報共有日時及び医師IDを取得し、取得された情報共有日時及び医師IDとともに、疑わしい理由(例えば診断未実施)をメモリ140に記録して(ステップS408)、ステップS409の処理に進む。
【0109】
予約・診察情報テーブル224のなかに同じ組合せを持つレコードがある場合(ステップS407:YES)、医師が診察実績のある患者にメッセージを送信している。この場合、診察実績の有無の観点では、クライアント30が不正利用された可能性がないとみなされる。そのため、制御部100は、ステップS408の処理を実行せずに、ステップS409の処理に進む。
【0110】
このように、ステップS403、S405及びS407において、制御部100は、記録部100eに記録された送信履歴に基づいてクライアント30の不正利用の可能性を判定する不正利用判定部100fとして動作する。
【0111】
制御部100は、ステップS404、S406、S408の何れかにおいて不正利用の可能性を示す情報がメモリ140に記録されたか否かを判定する(ステップS409)。
【0112】
不正利用の可能性を示す情報がメモリ140に記録された場合(ステップS409:YES)、制御部100は、例えば業務監査役のクライアント30に対し、メモリに記録された不正利用の可能性を示す情報を通知して(ステップS410)、
図13のフローチャートの処理を終了する。不正利用の可能性を示す情報がメモリ140に記録されていない場合(ステップS409:NO)、制御部100は、例えば業務監査役のクライアント30に対し、不正利用の可能性を示す情報がないことを通知して(ステップS411)、
図13のフローチャートの処理を終了する。これらの通知をもとに、業務監査役が、クライアント30が実際に不正利用されたかどうかを判断することができる。
【0113】
なお、
図13のフローチャートの次回の実行開始時、メモリ140に記録された不正利用の可能性を示す情報はリセット(消去)される。
【0114】
なお、本発明は上述した実施形態そのままに限定されるものではなく、実施段階でのその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施形態に示される全構成要素を適宜組み合わせても良い。更に、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。このような、発明の趣旨を逸脱しない範囲内において種々の変形や応用が可能である。
【符号の説明】
【0115】
1 :医療システム
10 :サーバ
20 :電子カルテシステム
22 :電子カルテサーバ
30 :クライアント
40 :モバイル端末装置
100 :制御部
100A :CPU
100B :RAM
100C :ROM
100D :入出力インタフェース
100E :表示制御回路
100F :バスライン
100a :受信部
100b :適否判定部
100c :転送中止部
100d :通知部
100e :記録部
100f :不正利用判定部
110 :通信インタフェース
120 :操作部
130 :モニタ
140 :メモリ
142 :患者情報テーブル
144 :履歴情報テーブル
220 :診療科情報テーブル
222 :医師情報テーブル
224 :診察情報テーブル
226 :投薬情報テーブル