JP2014235552A - メッセージ管理方法、メッセージ管理プログラムおよびメッセージ管理システム - Google Patents

Abstract

【課題】確認が不要なメッセージが残ることを抑制できるメッセージ管理方法、メッセージ管理プログラムおよびメッセージ管理システムを提供する。【解決手段】設定部５４は、グループ宛に作成されたメッセージから抽出された情報に基づき、前記メッセージの担当者を前記グループに対応づけられた複数のメンバーから設定する。追加部５５は、前記メッセージを前記複数のメンバーそれぞれのメッセージリストに追加する。除外部５２は、前記担当者による前記メッセージの確認に応じて、前記担当者を除く前記複数のメンバーそれぞれの前記メッセージリストより、前記メッセージを除外する。【選択図】図４

Description

本発明は、メッセージ管理方法、メッセージ管理プログラムおよびメッセージ管理システムに関する。

従来から利用者に対して複数の担当者によりサービスを提供する場合がある。例えば、在宅医療では、医師、看護師、介護士、薬剤師などがそれぞれの立場で、患者の診療、看護、介護を行う。患者の容態等の情報は、患者を担当する各担当者間で情報を共有する。例えば、介護士は、担当患者の容態変化について医師等に連絡する場合、電話、電子メール、ＦＡＸ等で連絡を行う。

ところで、各担当者は、それぞれ所属する組織が異なる場合、連絡に手間や時間がかかる。例えば、医師と介護士とは、通常、所属する組織が診療所と、介護ステーションと異なる。このため、介護士から医師に連絡する場合、介護士は、別組織である診療所等に連絡して同じ患者を担当する医師の連絡先を問い合せ、問い合せ先に連絡する。

そこで、複数の担当者間で情報を共有する技術として、例えば、代表アドレスを作成し、代表アドレス宛のメールを各担当者に振分けて、各担当者から参照可能とする従来技術がある。図３０は、従来技術の受信メール表示画面を示す図である。この従来技術では、個人宛のメールと代表アドレス宛のメールとが別なフォルダに分かれて格納される。この受信メール表示画面には、アカウント選択ボタンとして、「個人」、「Ｂ課」、「Ｃ課」が設けられている。「個人」は、個人宛のメールを表示させるボタンである。「Ｂ課」および「Ｃ課」は、それぞれの代表アドレス宛のメールを表示させるボタンである。図３０の例は、Ｂ課の代表アドレス宛のメールをリスト表示した状態を示している。開封数は、メールが振り分けられた各担当者のうち何人の担当者が開封したかを示している。状態は、メールに対する返信の状態を示している。状態は、メールが振り分けられたいずれかの担当者が返信した場合、回答済みと表示され、いずれかの担当者が返信を作成中の場合、回答中と表示され、いずれかの担当者も返信を作成していない場合、未回答と表示される。

特開２００９−１７５９００号公報

しかしながら、電話、電子メール、ＦＡＸ等により異なる組織の担当者宛に連絡を行う場合は、担当者の連絡先を調べなければならず、また、担当者の休暇等の場合、患者のフォローが行えない。

また、従来技術を用いて、例えば、異なる組織の担当者に対する連絡を組織宛に行う場合、それぞれの組織では、担当者の休暇等の場合、患者のフォローが行えないため、担当者以外のスタッフにもメッセージを回送する。しかし、従来技術では、担当者以外のスタッフにもメッセージを回送した場合、担当者がメッセージを確認したとしてもスタッフの受信リストに回送されたメッセージが残ってしまう。

一側面では、確認が不要なメッセージが残ることを抑制できるメッセージ管理方法、メッセージ管理プログラムおよびメッセージ管理システムを提供することを目的とする。

本発明の一側面によれば、メッセージ管理方法は、コンピュータが、グループ宛に作成されたメッセージから抽出された情報に基づき、前記メッセージの担当者を前記グループに対応づけられた複数のメンバーから設定する。メッセージ管理方法は、コンピュータが、前記メッセージを前記複数のメンバーそれぞれのメッセージリストに追加する。メッセージ管理方法は、コンピュータが、前記担当者による前記メッセージの確認に応じて、前記担当者を除く前記複数のメンバーそれぞれの前記メッセージリストより、前記メッセージを除外する。

本発明の一側面によれば、確認が不要なメッセージが残ることを抑制できる。

図１は、本実施例に係る組織の構成の一例を示す図である。 図２は、本実施例に係る簡略化した組織の構成の一例を示す図である。 図３は、ＤＢ構成の一例を示す図である。 図４は、メッセージ管理システムの概略的な構成の一例を示す図である。 図５は、共通患者情報テーブルのデータ構成の一例を示す図である。 図６は、連携事業所情報テーブルのデータ構成の一例を示す図である。 図７は、メッセージ管理テーブルのデータ構成の一例を示す図である。 図８は、メッセージ既読者テーブルのデータ構成の一例を示す図である。 図９は、事業所Ｆに関する患者情報テーブルのデータ構成の一例を示す図である。 図１０は、事業所Ｆに関するスタッフ情報テーブルのデータ構成の一例を示す図である。 図１１は、事業所Ｆに関する事業所情報テーブルのデータ構成の一例を示す図である。 図１２は、事業所Ｆに関する個人メッセージ管理テーブルのデータ構成の一例を示す図である。 図１３は、事業所Ｇに関する患者情報テーブルのデータ構成の一例を示す図である。 図１４は、事業所Ｇに関するスタッフ情報テーブルのデータ構成の一例を示す図である。 図１５は、事業所Ｇに関する事業所情報テーブルのデータ構成の一例を示す図である。 図１６は、事業所Ｇに関する個人メッセージ管理テーブルのデータ構成の一例を示す図である。 図１７は、メッセージを送付した際の表示画面の一例を示す図である。 図１８は、図１７に示すメッセージの送付によるデータの変化の一例を示す図である。 図１９は、担当者以外のスタッフがメッセージを確認した際の表示画面の一例を示す図である。 図２０は、図１９に示すメッセージの確認によるデータの変化の一例を示す図である。 図２１は、担当者がメッセージを確認した際の表示画面の一例を示す図である。 図２２は、図２１に示すメッセージの確認によるデータの変化の一例を示す図である。 図２３は、メッセージ送信処理の手順の一例を示すフローチャートである。 図２４は、メッセージ配信処理の手順の一例を示すフローチャートである。 図２５は、未読メッセージ一覧表示処理の手順の一例を示すフローチャートである。 図２６は、フラグ更新処理の手順の一例を示すフローチャートである。 図２７は、送信メッセージ一覧表示処理の手順の一例を示すフローチャートである。 図２８は、既読者一覧表示処理の手順の一例を示すフローチャートである。 図２９は、メッセージ管理プログラムを実行するコンピュータを示す図である。 図３０は、従来技術の受信メール表示画面を示す図である。

以下に、本発明にかかるメッセージ管理方法、メッセージ管理プログラムおよびメッセージ管理システムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［組織の構成］
最初に、本実施例に係る組織の構成の一例について説明する。図１は、本実施例に係る組織の構成の一例を示す図である。従来から、複数の担当者が連携して利用者に対してサービスを提供する場合がある。例えば、在宅医療では、医師、看護師、介護士、薬剤師がそれぞれの立場で、患者に対して診療、看護、介護などのサービスを提供する。このような場合、各担当者は、別な組織に属する場合がある。例えば、図１の例では、医師Ａは、在宅医療診療所Ｚに所属する。看護師Ｂは、訪問看護ステーションＹに所属する。ケアマネージャＣは、居宅介護支援事業所Ｘに所属する。薬剤師Ｄは、訪問薬局Ｗに所属する。サービス責任者Ｅは、訪問介護ステーションＶに所属する。ホームヘルパＦは、訪問介護ステーションＶに所属する。このように複数の担当者が連携して利用者に対してサービスを提供する場合、各担当者間で情報の共有を行う場合がある。例えば、在宅医療では、医師Ａと、看護師Ｂと、ケアマネージャＣと、薬剤師Ｄと、サービス責任者Ｅと、ホームヘルパＦとの間で患者の容態等の情報の共有を行う。本実施例では、各担当者間の情報の共有をメッセージ管理システムにより行う場合を説明する。

なお、以下では、説明を簡易にするため、２つの事業所の担当者により、患者Ｐにサービスを提供する場合を例にして説明を行う。図２は、本実施例に係る簡略化した組織の構成の一例を示す図である。図２に示すように、事業所Ｆは、スタッフＸ、Ｙ、Ｚが所属する。事業所Ｇは、スタッフＡ、Ｂ、Ｃが所属する。患者Ｐは、事業所Ｆおよび事業所Ｇからのサービスの提供を受けている。事業所Ｆでの患者Ｐの担当者は、スタッフＸとする。事業所Ｇでの患者Ｐの担当者は、スタッフＡとする。

［データベースの構成］
次に、本実施例に係るメッセージ管理システムに用いるデータベース（ＤＢ）の構成について説明する。図３は、ＤＢ構成の一例を示す図である。本実施例に係るメッセージ管理システムでは、ＤＢを共通ＤＢ３０と、事業所ＤＢ４０とに分けて管理する。図３の例では、事業所Ｆと事業所Ｇ用に２つの事業所ＤＢ４０が設けられている。

共通ＤＢ３０は、各事業所に関する情報や、共通して管理する情報を管理するデータベースである。共通ＤＢ３０は、共通患者情報テーブル３１と、連携事業所情報テーブル３２と、メッセージ管理テーブル３３と、メッセージ既読者テーブル３４とを有する。これら各テーブルの詳細な構成は、後述する。

事業所ＤＢ４０は、事業所毎に設けられ、事業所毎の情報を管理するデータベースである。事業所ＤＢ４０は、患者情報テーブル４１と、スタッフ情報テーブル４２と、事業所情報テーブル４３と、複数の個人メッセージ管理テーブル４４とを有する。これら各テーブルの詳細な構成も、後述する。

［メッセージ管理システムの構成］
次に、本実施例に係るメッセージ管理システム１０の機能的構成について説明する。図４は、メッセージ管理システムの概略的な構成の一例を示す図である。メッセージ管理システム１０は、ネットワーク１３を介して端末装置１１と通信可能に接続され、各種の情報を交換することが可能とされている。かかるネットワーク１３の一態様としては、有線または無線を問わず、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）、移動体通信網などの任意の通信網が挙げられる。

端末装置１１は、事業所のスタッフが電子メールを用いて他のスタッフとの連絡に用いることが可能な装置である。端末装置１１は、例えば、タブレット端末、スマートフォン、ＰＤＡ（Personal Digital Assistant）などであってもよい。また、端末装置１１は、デスクトップ型ＰＣ（Personal Computer）、ノート型ＰＣなどの情報処理装置であってもよい。なお、図４の例では、端末装置１１を２つ有する場合を例示したが、開示のシステムはこれに限定されず、端末装置１１を任意の数とすることができる。

メッセージ管理システム１０は、例えば、センタなどに設けられたサーバコンピュータ上で動作し、各端末装置１１において事業所のスタッフ宛てに作成された電子メールなどのメッセージを振り分けて管理するシステムである。メッセージ管理システム１０は、１台のコンピュータ上で動作するものとしてもよく、また、クラウドなどの複数台のコンピュータ上で分散して動作するものとしてもよい。また、メッセージ管理システム１０は、コンピュータ上で動作する１または複数のＶＭ（Virtual Machine：仮想マシン）上で動作してもよい。

図４に示すように、メッセージ管理システム１０は、記憶部２０と、処理部２１とを有する。なお、メッセージ管理システム１０は、図４に示した機能部以外にも各種の機能部を有してもよい。

記憶部２０は、各種のデータを記憶する機能部である。例えば、記憶部２０は、ディスクアレイ装置、サーバコンピュータに備えられたハードディスク、ＳＳＤ（Solid State Drive）などの記憶装置、ＲＡＭ（Random Access Memory）、フラッシュメモリなどの半導体メモリである。なお、各種のデータは、複数の装置に分散して記憶されてもよい。

記憶部２０は、処理部２１で用いられる各種データを記憶する。例えば、記憶部２０は、共通ＤＢ３０と、複数の事業所ＤＢ４０とを記憶する。図４の例では、事業所Ｆと事業所Ｇ用に２つの事業所ＤＢ４０が設けられている。以下では、事業所ＤＢ４０のうち、事業所Ｆ用の事業所ＤＢ４０について述べる場合、事業所ＤＢ４０Ｆと標記し、事業所Ｇ用の事業所ＤＢ４０について述べる場合、事業所ＤＢ４０Ｇと標記する。

共通ＤＢ３０は、共通患者情報テーブル３１と、連携事業所情報テーブル３２と、メッセージ管理テーブル３３と、メッセージ既読者テーブル３４とを有する。また、事業所ＤＢ４０は、患者情報テーブル４１と、スタッフ情報テーブル４２と、事業所情報テーブル４３と、複数の個人メッセージ管理テーブル４４とを有する。

次に、各テーブルのデータ構成について説明する。最初に、共通ＤＢ３０に含まれる各テーブルのデータ構成について説明する。共通患者情報テーブル３１は、サービスが提供される利用者として、患者に関する情報を記憶したテーブルである。例えば、共通患者情報テーブル３１には、患者に関する個人情報と、患者にサービスを提供する事業所の情報が記憶されている。

図５は、共通患者情報テーブルのデータ構成の一例を示す図である。図５に示すように、共通患者情報テーブル３１は、「共有患者ＩＤ」、「氏名」、「生年月日」、「性別」、「住所」、「連携事業所ＩＤ」の各項目を有する。

共有患者ＩＤの項目は、各事業所において共通で使用する患者を識別する識別情報を記憶する領域である。各患者には、数字や文字などを組み合わせてそれぞれを識別する識別情報として共有患者ＩＤが付与される。共有患者ＩＤの項目には、患者に対して付与された共有患者ＩＤが格納される。氏名、生年月日、性別、住所の各項目は、患者の個人情報として氏名、生年月日、性別、住所を記憶する領域である。性別は、「Ｍ」が男性、「Ｆ」が女性を示す。連携事業所ＩＤの項目は、患者にサービスを提供する事業所の識別情報を記憶する領域である。各事業所には、それぞれを識別する識別情報として連携事業所ＩＤが付与される。連携事業所ＩＤの項目は、複数設けられている。図５の例では、連携事業所ＩＤの項目は、連携事業所ＩＤ［ｎ］、連携事業所ＩＤ［ｎ＋１］と複数設けられている。各連携事業所ＩＤの項目には、患者にサービスを提供する事業所の連携事業所ＩＤが１つずつ格納される。図５の例では、共有患者ＩＤ「ＵＰｎｔＩＤ＿０００１」の患者は、氏名が「Ｐ」であり、生年月日が「１９３５／１０／７」であり、性別が男性であり、住所が「東京都」であることを示す。また、共有患者ＩＤ「ＵＰｎｔＩＤ＿０００１」の患者は、連携事業所ＩＤが「ＬｎｋＦｃｌＩＤ＿０００１」、「ＬｎｋＦｃｌＩＤ＿０００２」の事業所からサービスが提供されていることを示す。

図４に戻り、連携事業所情報テーブル３２は、メッセージ管理システム１０によりメッセージを連携可能な事業所に関する情報を記憶したテーブルである。例えば、連携事業所情報テーブル３２には、患者に関する情報の共有をメッセージ管理システム１０により行う事業所の情報が記憶されている。

図６は、連携事業所情報テーブルのデータ構成の一例を示す図である。図６に示すように、連携事業所情報テーブル３２は、「連携事業所ＩＤ」、「名前」、「住所」、「電話番号」の各項目を有する。

連携事業所ＩＤの項目は、各事業所を識別する連携事業所ＩＤを記憶する領域である。名前、住所、電話番号の項目は、事業所の名前、事業所の所在地、事業所の電話番号を記憶する領域である。図６の例では、連携事業所ＩＤ「ＬｎｋＦｃｌＩＤ＿０００１」の事業所は、名前が「事業所Ｆ」であり、所在地が「東京都」であり、電話番号が「０３−ｘｘｘｘ−ｘｘｘｘ」であることを示す。

図４に戻り、メッセージ管理テーブル３３は、メッセージ管理システム１０を利用する事業所のスタッフ宛てに送付されたメッセージに関する情報を記憶したテーブルである。例えば、メッセージ管理テーブル３３は、送付されたメッセージの情報が記憶されている。

図７は、メッセージ管理テーブルのデータ構成の一例を示す図である。図７に示すように、メッセージ管理テーブル３３は、「メッセージＩＤ」、「共有患者ＩＤ」、「送付元情報」、「送付先情報」の各項目を有する。

メッセージＩＤの項目は、メッセージを識別する識別情報を記憶する領域である。各メッセージには、送付の処理がなされた際にそれぞれを識別する識別情報としてメッセージＩＤが付与される。メッセージＩＤの項目は、メッセージに対して付与されたメッセージＩＤが格納される。共有患者ＩＤの項目は、患者の共有患者ＩＤを記憶する領域である。共有患者ＩＤの項目には、メッセージが担当者間で情報を共有する患者に関する情報である場合、共有患者ＩＤが格納され、スタッフ個人宛の情報である場合、共有患者ＩＤが未格納されて空白とされる。

送付元情報に項目は、メッセージの送付元に関する情報を記憶する領域であり、「事業所ＩＤ」、「送信者ＩＤ」、「担当者Ｆｌａｇ」、「送信日時」の各項目を有する。送付元情報の事業所ＩＤの項目は、メッセージの送付元の事業所の共通事業所ＩＤを記憶する領域である。送付元情報の送信者ＩＤの項目は、メッセージの送付元のスタッフの識別情報を記憶する領域である。各事業所のスタッフには、それぞれを識別する識別情報としてスタッフＩＤが付与される。送付元情報の送信者ＩＤの項目には、メッセージの送付元のスタッフのスタッフＩＤが格納される。送付元情報の担当者Ｆｌａｇの項目は、送信元のスタッフが担当者であるか否かを記憶する領域である。送付元情報の担当者Ｆｌａｇの項目には、メッセージが担当者間で情報を共有する患者に関する情報である場合、送信元のスタッフが担当者であるか否かが格納される。例えば、送付元情報の担当者Ｆｌａｇの項目には、送信元のスタッフが担当者である場合、「Ｔｒｕｅ」が格納され、送信元のスタッフが担当者ではない場合、「Ｆａｌｓｅ」が格納される。送付元情報の送信日時の項目は、メッセージの送付された送付日時を記憶する領域である。

送付先情報に項目は、メッセージの送付先に関する情報を記憶する領域である。複数の事業所で情報の共有を可能とするため、送付先情報の項目は、複数設けられている。図７の例では、送付先情報の項目は、送付先情報［ｎ］と複数設けられている。送付先情報に項目は、「事業所ＩＤ」、「担当者ＩＤ」、「スタッフＩＤ」の各項目を有する。送付先情報の事業所ＩＤの項目は、メッセージの送付先の事業所の共通事業所ＩＤを記憶する領域である。送付先情報の担当者の項目は、メッセージの送付先の事業所における担当者のスタッフＩＤを記憶する領域である。送付先情報のスタッフＩＤの項目は、メッセージの送付先に関する情報を記憶する領域である。事業所の複数のスタッフで情報の共有を可能とするため、送付先情報のスタッフＩＤの項目は、複数設けられている。図７の例では、送付先情報のスタッフＩＤの項目は、スタッフＩＤ［ｍ］、スタッフＩＤ［ｍ＋１］と複数設けられている。送付先情報の各スタッフＩＤの項目には、メッセージの送付先とされたスタッフのスタッフＩＤが１つずつ格納される。図７の例では、メッセージＩＤ「ＭｓｇＩＤ＿０００１」のメッセージは、共有患者ＩＤが空白であることから個人宛のメッセージであることを示す。また、メッセージＩＤ「ＭｓｇＩＤ＿０００１」のメッセージは、送付元の事業所ＩＤが「ＬｎｋＦｃｌＩＤ＿０００２」であり、送信者が「ＳｔｆＩＤ＿０００２」であり、担当者Ｆｌａｇが未設定であり、送信日時が「２０１３／０４／２８ １０：４５：２１」であることを示す。また、メッセージＩＤ「ＭｓｇＩＤ＿０００１」のメッセージは、送付先の事業所ＩＤが「ＬｎｋＦｃｌＩＤ＿０００２」であり、送信先のスタッフＩＤが「ＳｔｆＩＤ＿０００１」、「ＳｔｆＩＤ＿０００３」であることを示す。

図４に戻り、メッセージ既読者テーブル３４は、メッセージを確認したスタッフに関する情報を記憶したテーブルである。

図８は、メッセージ既読者テーブルのデータ構成の一例を示す図である。図８に示すように、メッセージ既読者テーブル３４は、「リストＩＤ」、「メッセージＩＤ」、「連携事業所名」、「氏名」、「担当者Ｆｌａｇ」、「既読日時」の各項目を有する。

リストＩＤの項目は、レコードを識別する識別情報としてリストＩＤを記憶する領域である。リストＩＤの項目には、定められたリストＩＤが格納される。メッセージＩＤの項目は、既読とされたメッセージのメッセージＩＤを記憶する領域である。連携事業所名の項目は、メッセージを確認したスタッフの所属する事業所の連携事業所ＩＤを記憶する領域である。氏名の項目は、メッセージを確認したスタッフの氏名を記憶する領域である。担当者Ｆｌａｇの項目は、メッセージを確認したスタッフが担当者であるか否かを記憶する領域である。例えば、担当者Ｆｌａｇの項目には、メッセージを確認したスタッフが担当者である場合、「Ｔｒｕｅ」が格納され、メッセージを確認したスタッフが担当者ではない場合、「Ｆａｌｓｅ」が格納される。既読日時の項目は、既読となった日時を記憶する領域である。

次に、事業所ＤＢ４０に含まれる各テーブルのデータ構成について説明する。なお、図４に示す事業所ＤＢ４０Ｆと事業所ＤＢ４０Ｇは共に、同じデータ構成である。以下では、データ構成については、図９〜図１２を用いて、事業所ＤＢ４０Ｆを例にして説明する。記憶されたデータの例については、事業所ＤＢ４０Ｆと事業所ＤＢ４０Ｇのそれぞれについて説明する。

患者情報テーブル４１は、事業所においてサービスを提供する患者に関する情報を記憶したデーブルである。

図９は、事業所Ｆに関する患者情報テーブルのデータ構成の一例を示す図である。図９に示すように、患者情報テーブル４１は、「患者ＩＤ」、「共有患者ＩＤ」、「担当スタッフＩＤ」、「事業所ＩＤ」の各項目を有する。

患者ＩＤの項目は、事業所における患者の識別情報を記憶する領域である。本実施例に係るメッセージ管理システム１０では、各事業所において、患者に識別情報として独自の患者ＩＤを付与することが可能とされている。患者ＩＤの項目には、事業所における患者の患者ＩＤが格納される。なお、事業所における患者の患者ＩＤは、共有患者ＩＤを用いてもよい。共有患者ＩＤの項目は、各事業所において共通で使用する共有患者ＩＤを記憶する領域である。共有患者ＩＤの項目には、メッセージ管理システム１０によりメッセージを共有する場合、共有患者ＩＤが格納される。担当スタッフＩＤの項目は、患者を担当するスタッフのスタッフＩＤを記憶する領域である。事業所ＩＤの項目は、他の事業所の事業所ＩＤを記憶する領域である。情報を共有する各事業所を記憶するため、事業所ＩＤの項目は、複数設けられている。図９の例では、事業所ＩＤの項目は、事業所ＩＤ［ｎ］、事業所ＩＤ［ｎ＋１］と複数設けられている。各事業所ＩＤの項目には、患者に関する情報を共有する各事業所の事業所ＩＤが１つずつ格納される。図９の例では、患者ＩＤ「ＰｎｔＩＤ＿０００１」の患者は、共有患者ＩＤが「ＵＰｎｔＩＤ＿０００１」であり、担当スタッフが「ＳｔｆＩＤ＿０００１」であることを示す。また、患者ＩＤ「ＰｎｔＩＤ＿０００１」の患者は、事業所ＩＤが「ＦｃｌＩＤ＿０００１」、「ＦｃｌＩＤ＿０００２」の各事業所と情報を共有することを示す。また、図９の例では、患者ＩＤ「ＰｎｔＩＤ＿０００２」の患者について、共有患者ＩＤが未設定とされている。これは、例えば、メッセージ管理システム１０に連携事業所ＩＤが登録された事業所以外の事業所と連携している場合である。すなわち、本実施例に係るメッセージ管理システム１０は、各事業所が独自に連携している事業所についても管理可能としている。

図４に戻り、スタッフ情報テーブル４２は、事業所に所属するスタッフに関する情報を記憶したデーブルである。

図１０は、事業所Ｆに関するスタッフ情報テーブルのデータ構成の一例を示す図である。図１０に示すように、スタッフ情報テーブル４２は、「スタッフＩＤ」、「氏名」、「職種」の各項目を有する。

スタッフＩＤの項目は、事業所から付与されたスタッフのスタッフＩＤを記憶する領域である。氏名、職種の各項目は、スタッフの氏名および職種を記憶する領域である。図１０の例では、スタッフＩＤ「ＳｔｆＩＤ＿０００１」のスタッフは、「Ｘ」であり、職種が「医師」であることを示す。

図４に戻り、事業所情報テーブル４３は、メッセージ管理システム１０によりメッセージを連携可能な事業所に関する情報を記憶したテーブルである。例えば、事業所情報テーブル４３には、患者に関する情報の共有をメッセージ管理システム１０により行っている事業所の情報が記憶されている。また、事業所情報テーブル４３には、メッセージ管理システム１０以外で事業所が独自に連携している事業所の情報についても登録可能としている。

図１１は、事業所Ｆに関する事業所情報テーブルのデータ構成の一例を示す図である。図１１に示すように、事業所情報テーブル４３は、「事業所ＩＤ」、「名前」、「住所」、「電話番号」、「連携事業所ＩＤ」の各項目を有する。

事業所ＩＤの項目は、事業所における他の事業所の識別情報を記憶する領域である。本実施例に係るメッセージ管理システム１０では、各事業所において、他の事業所に識別情報として独自の事業所ＩＤを付与することが可能とされている。事業所ＩＤの項目には、事業所における他の事業所の事業所ＩＤが格納される。なお、事業所における他の事業所の事業所ＩＤは、連携事業所ＩＤを用いてもよい。名前、住所、電話番号の項目は、事業所の名前、事業所の所在地、事業所の電話番号を記憶する領域である。連携事業所ＩＤの項目は、事業所の連携事業所ＩＤを記憶する領域である。連携事業所ＩＤの項目には、メッセージ管理システム１０によって連携事業所ＩＤが付与されている場合、連携事業所ＩＤが格納される。図１１の例では、事業所ＩＤ「ＦｃｌＩＤ＿０００１」の事業所は、名前が「事業所Ｇ」であり、所在地が「東京都」であり、電話番号が「０３−ｘｘｘｘ−ｘｘｘｘ」であり、連携事業所ＩＤが「ＬｎｋＦｃｌＩＤ＿０００２」であることを示す。また、図１１の例では、事業所ＩＤ「ＦｃｌＩＤ＿０００２」、「ＦｃｌＩＤ＿０００３」の各事業所は、連携事業所ＩＤが未設定であることから独自に連携している事業所であることを示す。

図４に戻り、個人メッセージ管理テーブル４４は、各スタッフに送付されたメッセージに関する情報を記憶したテーブルである。

図１２は、事業所Ｆに関する個人メッセージ管理テーブルのデータ構成の一例を示す図である。個人メッセージ管理テーブル４４は、スタッフ毎に作成される。図１２の例では、スタッフＸ、Ｙ、Ｚ用にそれぞれ作成された個人メッセージ管理テーブル４４が示されている。個人メッセージ管理テーブル４４は、「メッセージＩＤ」、「メッセージＴｙｐｅ」、「既読Ｆｌａｇ」、「担当者既読Ｆｌａｇ」、「返信メッセージＩＤ」の各項目を有する。

メッセージＩＤの項目は、メッセージのメッセージＩＤを記憶する領域である。メッセージＴｙｐｅの項目は、メッセージがスタッフの個人宛に送付されたものか、複数のスタッフの共有として送付されたものかを記憶する領域である。メッセージＴｙｐｅの項目には、メッセージがスタッフの個人宛である場合、「Ｐｅｒｓｏｎａｌ」と格納され、メッセージが複数のスタッフの共有の場合、「Ｇｒｏｕｐ」が格納される。既読Ｆｌａｇの項目は、メッセージが既読であるか否かを記憶する領域である。既読Ｆｌａｇの項目には、メッセージが既読である場合、「Ｔｒｕｅ」が格納され、メッセージが既読ではない場合、「Ｆａｌｓｅ」が格納される。担当者既読Ｆｌａｇの項目は、担当者がメッセージを既読であるか否かを記憶する領域である。担当者既読Ｆｌａｇの項目には、担当者がメッセージを既読である場合、「Ｔｒｕｅ」が格納され、担当者がメッセージを既読ではない場合、「Ｆａｌｓｅ」が格納される。返信メッセージＩＤの項目は、メッセージに対して返信が行われた場合、返信されたメッセージのメッセージＩＤを記憶する領域である。

次に、図１３〜図１６を用いて、事業所ＤＢ４０Ｇに記憶されたデータの例について説明する。図１３は、事業所Ｇに関する患者情報テーブルのデータ構成の一例を示す図である。事業所Ｇに関する患者情報テーブル４１のデータ構成は、図９と同様とされている。図１３の例では、患者ＩＤ「ＰｎｔＩＤ＿０００１」の患者は、共有患者ＩＤが「ＵＰｎｔＩＤ＿０００１」であり、担当者が「ＳｔｆＩＤ＿０００１」であることを示す。また、患者ＩＤ「ＰｎｔＩＤ＿０００１」の患者は、事業所ＩＤが「ＦｃｌＩＤ＿０００１」、「ＦｃｌＩＤ＿０００２」の各事業所と情報を共有することを示す。

図１４は、事業所Ｇに関するスタッフ情報テーブルのデータ構成の一例を示す図である。事業所Ｇに関するスタッフ情報テーブル４２のデータ構成は、図１０と同様とされている。図１４の例では、スタッフＩＤ「ＳｔｆＩＤ＿０００１」のスタッフは、「Ａ」であり、職種が「ケアマネージャ」であることを示す。

図１５は、事業所Ｇに関する事業所情報テーブルのデータ構成の一例を示す図である。事業所Ｇに関する事業所情報テーブル４３のデータ構成は、図１１と同様とされている。図１５の例では、連携事業所ＩＤ「ＦｃｌＩＤ＿０００１」の事業所は、名前が「事業所Ｆ」であり、所在地が「東京都」であり、電話番号が「０３−ｘｘｘｘ−ｘｘｘｘ」であり、連携事業所ＩＤが「ＬｎｋＦｃｌＩＤ＿０００１」であることを示す。

図１６は、事業所Ｇに関する個人メッセージ管理テーブルのデータ構成の一例を示す図である。図１６の例では、スタッフＡ、Ｂ、Ｃ用にそれぞれ作成された個人メッセージ管理テーブル４４が示されている。事業所Ｇに関する個人メッセージ管理テーブル４４のデータ構成は、図１２と同様とされている。図１６の例では、メッセージＩＤ「ＭｓｇＩＤ＿０００１」のメッセージは、個人宛であり、既読Ｆｌａｇおよび担当者既読Ｆｌａｇが共に「Ｆａｌｓｅ」であることからメッセージが未読であることを示す。また、メッセージＩＤ「ＭｓｇＩＤ＿０００１」のメッセージは、返信されたメッセージが未設定であることから返信が行われていないことを示す。

図４に戻り、処理部２１は、各種のデータを処理する機能部である。処理部２１としては、メッセージ管理システム１０が動作するサーバコンピュータのＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等の電子回路である。処理部２１は、各種の処理手順を規定したプログラムが電子回路上で実行されることにより、種々の処理を実行する。処理部２１は、各種のプログラムが動作することにより各種の処理部として機能する。例えば、処理部２１は、処理部として、表示処理部５０と、送信メッセージ処理部５１と、除外部５２と、更新部５３とを有する。

表示処理部５０は、端末装置１１への画像の表示を制御する。例えば、表示処理部５０は、端末装置１１からの各種の要求に応じて各種の画面の画面情報を生成して端末装置１１へ送信する。これにより、端末装置１１では、受信された画面情報に基づき、各種の画面が表示される。一例として、表示処理部５０は、端末装置１１からアクセス要求があった場合、ログイン画面の画面情報を生成して端末装置１１へ送信する。このログイン画面には、事業所ＩＤおよびスタッフＩＤを入力する領域が設けられている。表示処理部５０は、事業所ＩＤおよびスタッフＩＤが指定されてログインなどの所定操作がログイン画面で行われた場合、メッセージ送受信画面の画面情報を生成して端末装置１１へ送信する。このメッセージ送受信画面では、他のスタッフから送付されたメッセージが一覧表示され、各メッセージの確認および返信が可能とされている。また、メッセージ送受信画面では、未読のメッセージを抽出して未読メッセージ一覧画面に一覧表示させることが可能とされている。また、メッセージ送受信画面では、送付済みメッセージを抽出して送信メッセージ一覧画面に一覧表示させることが可能とされている。

送信メッセージ処理部５１は、メッセージの送付に関する各種の処理を実行する処理部である。送信メッセージ処理部５１は、設定部５４と、追加部５５とを有する。送信メッセージ処理部５１は、メッセージが作成されて送付が指示された場合、送付が指示されたメッセージの送付を行う。

例えば、本実施例に係るメッセージ管理システム１０では、宛先とする事業所ＩＤおよび患者ＩＤを指定してグループ宛のメッセージの送信が可能とされている。なお、宛先とする事業所ＩＤは、連携事業所ＩＤであってもよい、事業所独自の事業所ＩＤであってもよく、メッセージ管理システム１０が内部で連携事業所ＩＤに変換してもよい。宛先とする患者ＩＤも共有患者ＩＤであってもよい、事業所独自の患者ＩＤであってもよく、メッセージ管理システム１０が内部で共通患者ＩＤに変換してもよい。設定部５４は、グループ宛のメッセージの送付が指示された場合、グループ宛に作成されたメッセージから抽出された情報に基づき、メッセージの担当者を設定する。例えば、設定部５４は、送付が指示されたメッセージから、宛先とする事業所ＩＤおよび患者ＩＤの情報を抽出する。設定部５４は、各事業所ＤＢ４０に基づき、抽出した事業所ＩＤおよび患者ＩＤから、それぞれの事業所での担当者のスタッフＩＤ、および担当者以外のスタッフのスタッフＩＤを特定する。

追加部５５は、送付先とされた複数のメンバーそれぞれのメッセージリストにメッセージを追加する。例えば、追加部５５は、送付が指示されたメッセージを送付元に関する情報および送付先に関する情報と共にメッセージ管理テーブル３３に登録する。そして、追加部５５は、複数のメンバーの何れかから最初にメッセージの受信要求があった際に、メッセージ管理テーブル３３に格納されたメッセージの到着情報をメンバー毎のメッセージ管理テーブルに登録する。すなわち、追加部５５は、宛先が事業所ＩＤおよび患者ＩＤのメッセージについては、担当者および担当者以外のスタッフにメッセージを配信する。これにより、各スタッフの未読メッセージ一覧画面には、配信されたメッセージが追加して表示される。

除外部５２は、担当者によるメッセージの確認に応じて、担当者を除く各スタッフそれぞれのメッセージリストより、メッセージを除外する。例えば、除外部５２は、担当者がメールを確認した場合、担当者以外のスタッフの未読メッセージ一覧画面からメッセージを除外する。

更新部５３は、担当者によるメッセージの確認に応じて、当該メッセージの送信元での当該メッセージの確認通知のステータスを更新する。例えば、送信メッセージ一覧画面は、送付したメッセージについての確認状況を表示可能とされている。更新部５３は、担当者によるメッセージの確認に応じて、送信メッセージ一覧画面でのメッセージの確認通知のステータスを更新する。

ここで、本実施例に係るメッセージ管理システム１０により表示される表示画面の一例を説明する。図１７は、メッセージを送付した際の表示画面の一例を示す図である。図１７の例では、事業所Ｇにおいて未読メッセージ一覧画面７０を表示させた例が示されている。また、図１７の例は、事業所ＦのスタッフＹが事業所Ｇおよび患者Ｐを指定してメッセージを送付した場合を示している。例えば、共通ＤＢ３０、事業所ＤＢ４０Ｆおよび事業所ＤＢ４０Ｇに図５〜図１６に示したようなデータが格納されている場合、事業所ＧのスタッフＡ、Ｃの未読メッセージ一覧画面７０には、個人宛のメッセージが表示される。例えば、スタッフＡの未読メッセージ一覧画面７０には、「個人」として、送信元事業所が「事業所Ｇ」、送信者が「Ｂ」、件名が「明日のミーティングについて」と表示されている。

事業所ＦのスタッフＹから事業所Ｇおよび患者Ｐを指定してメッセージが送付された場合、設定部５４は、送付されたメッセージから、宛先とする事業所ＩＤおよび患者ＩＤの情報を抽出する。そして、設定部５４は、各事業所ＤＢ４０に基づき、抽出した事業所ＩＤおよび患者ＩＤから、それぞれの事業所での担当者のスタッフＩＤ、および担当者以外のスタッフのスタッフＩＤを特定する。例えば、図１７の例では、スタッフＡが担当者と特定され、スタッフＢ、Ｃが担当者以外のスタッフと特定される。追加部５５は、送付先とされた複数のメンバーそれぞれのメッセージリストにメッセージを追加する。例えば、例えば、追加部５５は、送付が指示されたメッセージを送付元に関する情報および送付先に関する情報と共にメッセージ管理テーブル３３に登録する。そして、追加部５５は、複数のメンバーの何れかから最初にメッセージの受信要求があった際に、メッセージ管理テーブル３３に格納されたメッセージをメンバー毎のメッセージ管理テーブル３３に登録する。これにより、図１７の例では、スタッフＡ、Ｂ、Ｃの未読メッセージ一覧画面に事業所ＦのスタッフＹから送付されたメッセージが追加される。表示処理部５０は、担当者とされたスタッフのメッセージリストにおいて、担当者であることを示してメッセージを表示する。例えば、表示処理部５０は、スタッフＡの未読メッセージ一覧画面において、担当者であることを示す「必読」を表示させる。これにより、スタッフＡは、自身が担当者であることを判別できる。

また、図１７の例では、事業所Ｆにおいて送信メッセージ一覧画面７１を表示させた例が示されている。例えば、送信メッセージ一覧画面７１には、患者が「Ｐ」、件名が「ご家族からの依頼」、送信者が「Ｙ」、送信日時が「２０１３／０４／３０ １９：３２：１１」、送信先情報の事業所を「事業所Ｇ」、担当者「Ａ」が表示されている。ここで、表示処理部５０は、メッセージを送付すると、送信メッセージ一覧画面７１において送付先の事業所での担当者を表示させる。これにより、事業所Ｆのスタッフは、事業所Ｇでの患者Ｐの担当者がスタッフＡであることを判別できる。

図１８は、図１７に示すメッセージの送付によるデータの変化の一例を示す図である。図１８には、共通ＤＢ３０のメッセージ管理テーブル３３と、事業所ＤＢ４０ＧのスタッフＡ、Ｂ、Ｃの個人メッセージ管理テーブル４４とが示されている。図１７に示すメッセージが送付されたことにより、メッセージ管理テーブル３３は、図７と比べて、メッセージＩＤが「ＭｓｇＩＤ＿０００２」のレコードが追加されている。また、スタッフＡ、Ｂ、Ｃの個人メッセージ管理テーブル４４も、図１６と比べて、メッセージＩＤが「ＭｓｇＩＤ＿０００２」のレコードが追加されている。

図１９は、担当者以外のスタッフがメッセージを確認した際の表示画面の一例を示す図である。図１９の例は、事業所ＧにおいてスタッフＢが患者Ｐに関するメッセージを確認した場合を示している。スタッフＢが未読メッセージ一覧画面７０で患者Ｐに関するメッセージを確認した場合、スタッフＢの未読メッセージ一覧画面７０には、患者Ｐに関するメッセージが表示されなくなる。一方、スタッフＡ、Ｃの未読メッセージ一覧画面７０には、患者Ｐに関するメッセージが表示される。例えば、スタッフＡが不在であり、スタッフＡが担当である患者Ｐのメッセージを担当者以外のスタッフが確認しても、スタッフＡの未読メッセージ一覧画面７０には、メッセージが表示される。これにより、スタッフＡは、担当である患者Ｐのメッセージを担当者以外のスタッフが確認済みの場合でも、未読メッセージ一覧画面７０から確認できる。

また、図１９の例では、事業所Ｆにおいて送信メッセージ一覧画面７１を表示させた例が示されている。例えば、送信メッセージ一覧画面７１には、既読者の項目に「見る」が表示される。この「見る」を選択することにより、既読者一覧画面７２が表示される。既読者一覧画面７２には、事業所ＧのスタッフＢが２０１３／０５／０１ ８：４５：３２にメッセージを確認したことが表示されている。これにより、事業所Ｆのスタッフは、メッセージを確認したスタッフを知ることができる。

図２０は、図１９に示すメッセージの確認によるデータの変化の一例を示す図である。図２０には、共通ＤＢ３０のメッセージ管理テーブル３３およびメッセージ既読者テーブル３４と、事業所ＤＢ４０ＧのスタッフＡ、Ｂ、Ｃの個人メッセージ管理テーブル４４とが示されている。図１９に示すメッセージの確認が行われたことにより、メッセージ既読者テーブル３４には、メッセージＩＤが「ＭｓｇＩＤ＿０００２」のメッセージを事業所ＧのスタッフＢが確認したことを示すレコードが追加されている。また、スタッフＢの個人メッセージ管理テーブル４４は、メッセージＩＤが「ＭｓｇＩＤ＿０００２」のレコードの既読Ｆｌａｇが「Ｔｒｕｅ」に更新されている。

図２１は、担当者がメッセージを確認した際の表示画面の一例を示す図である。図２１の例は、事業所ＧにおいてスタッフＡが担当する患者Ｐに関するメッセージを確認した場合を示している。スタッフＡが未読メッセージ一覧画面７０で担当する患者Ｐに関するメッセージを確認した場合、スタッフＡの未読メッセージ一覧画面７０には、患者Ｐに関するメッセージが表示されなくなる。また、スタッフＣの未読メッセージ一覧画面７０でも、患者Ｐに関するメッセージが除外されてメッセージが表示されなくなる。すなわち、スタッフＡが担当である患者Ｐのメッセージを確認した場合、担当者以外のスタッフＢ、Ｃの未読メッセージ一覧画面７０には、メッセージが表示されなくなる。これにより、メッセージ管理システム１０では、担当であるスタッフＡがメッセージを確認したことにより、確認が不要となったメッセージがスタッフＢ、Ｃの未読メッセージ一覧画面７０に残ることを抑制できる。

また、図２１の例では、事業所Ｆにおいて送信メッセージ一覧画面７１を表示させた例が示されている。例えば、送信メッセージ一覧画面７１には、既読者の項目に「見る」が表示される。この「見る」を選択することにより、既読者一覧画面７２が表示される。既読者一覧画面７２には、事業所ＧのスタッフＢが２０１３／０５／０１ ８：４５：３２にメッセージを確認したことが表示されている。また、既読者一覧画面７２には、事業所Ｇの担当者のスタッフＡが２０１３／０５／０１ １１：５８：１０にメッセージを確認したことが表示されている。これにより、事業所Ｆのスタッフは、担当者がメッセージを確認したかを知ることができる。

図２２は、図２１に示すメッセージの確認によるデータの変化の一例を示す図である。図２２には、共通ＤＢ３０のメッセージ管理テーブル３３およびメッセージ既読者テーブル３４と、事業所ＤＢ４０ＧのスタッフＡ、Ｂ、Ｃの個人メッセージ管理テーブル４４とが示されている。図２１に示すメッセージの確認が行われたことにより、メッセージ既読者テーブル３４には、メッセージＩＤが「ＭｓｇＩＤ＿０００２」のメッセージを事業所ＧのスタッフＡが確認したことを示すレコードが追加されている。また、スタッフＡの個人メッセージ管理テーブル４４は、メッセージＩＤが「ＭｓｇＩＤ＿０００２」のレコードの既読Ｆｌａｇと担当者既読Ｆｌａｇがそれぞれ「Ｔｒｕｅ」に更新されている。また、スタッフＢ、Ｃの個人メッセージ管理テーブル４４は、メッセージＩＤが「ＭｓｇＩＤ＿０００２」のレコードの担当者既読Ｆｌａｇが「Ｔｒｕｅ」に更新されている。このように、担当者既読Ｆｌａｇが「Ｔｒｕｅ」に更新された場合、メッセージは、未読メッセージ一覧画面７０に表示されなくなる。

［処理の流れ］
次に、本実施例に係るメッセージ管理システム１０の各種の処理の流れを説明する。最初に、本実施例に係るメッセージ管理システム１０により、メッセージを送信するメッセージ送信処理の流れについて説明する。図２３は、メッセージ送信処理の手順の一例を示すフローチャートである。このメッセージ送信処理は、メッセージ送受信画面からメッセージの送信を指定する所定の操作が行われたタイミングで実行される。

図２３に示すように、送信メッセージ処理部５１は、送付が指示されたメッセージについて送付元情報の項目に格納する各種の情報を特定する（Ｓ１０）。例えば、送信メッセージ処理部５１は、メッセージの送付が指示された事業所の連携事業所ＩＤを、送付元情報の項目の事業所の項目に格納する事業所ＩＤと特定する。また、送信メッセージ処理部５１は、メッセージの送付を指示したスタッフのスタッフＩＤを、送付元情報の項目の送信者ＩＤの項目に格納するスタッフＩＤと特定する。また、送信メッセージ処理部５１は、宛先として患者ＩＤが指定されている場合、メッセージの送付を指示したスタッフが担当者であるか判定する。例えば、送信メッセージ処理部５１は、送付元の事業所の患者情報テーブル４１の宛先とされた患者ＩＤのレコードに、メッセージの送付を指示したスタッフのスタッフＩＤが登録されているか否か判定する。送信メッセージ処理部５１は、スタッフＩＤが登録されている場合、送付元情報の項目の担当者Ｆｌａｇの項目に「Ｔｒｕｅ」を格納し、スタッフＩＤが登録されていない場合、送付元情報の項目の担当者Ｆｌａｇの項目に「Ｆａｌｓｅ」を格納するものと特定する。また、送信メッセージ処理部５１は、患者情報テーブル４１から宛先の患者ＩＤに対応する共有患者ＩＤを特定する。また、送信メッセージ処理部５１は、送信が指定された日時を送付元情報の項目の送付日時の項目に格納する日時と特定する。

次に、送信メッセージ処理部５１は、送付が指示されたメッセージについて送付先情報の項目に格納する各種の情報を特定する（Ｓ１１）。例えば、宛先として事業所ＩＤおよび患者ＩＤが指定されている場合、送信メッセージ処理部５１は、宛先の事業所ＩＤを、それぞれ送付先情報の項目の事業所の項目に格納する事業所ＩＤと特定する。設定部５４は、各事業所ＤＢ４０の患者情報テーブル４１に基づき、宛先の事業所ＩＤおよび宛先の患者ＩＤに対応する共有患者ＩＤから宛先の事業所毎に担当者のスタッフＩＤを特定する。そして、設定部５４は、事業所毎に担当者のスタッフＩＤを、送付先情報の項目の担当者ＩＤの項目に格納するスタッフＩＤと特定する。また、設定部５４は、事業所毎に担当者以外のスタッフのスタッフＩＤを特定する。そして、設定部５４は、事業所毎に、担当者以外のスタッフのスタッフＩＤを、送付先情報の項目のスタッフＩＤの項目に格納するスタッフＩＤと特定する。一方、宛先として事業所ＩＤおよびスタッフＩＤが指定されている場合、送信メッセージ処理部５１は、宛先の事業所ＩＤを、送付先情報の項目の事業所の項目に格納する事業所ＩＤと特定する。また、送信メッセージ処理部５１は、送付先情報の項目の担当者ＩＤの項目を未設定とし、宛先のスタッフＩＤを、送付先情報の項目のスタッフＩＤの項目に格納するスタッフＩＤと特定する。

そして、送信メッセージ処理部５１は、上述のＳ１０およびＳ１１において特定した各種の情報を設定したメッセージのレコードをメッセージ管理テーブル３３に追加し（Ｓ１２）、処理を終了する。

このメッセージ送信処理により、メッセージ管理システム１０では、送信が指示されたメッセージに関する情報が設定されたレコードがメッセージ管理テーブル３３に追加される。

次に、本実施例に係るメッセージ管理システム１０が宛先のスタッフに対してメッセージを配信するメッセージ配信処理の流れについて説明する。図２４は、メッセージ配信処理の手順の一例を示すフローチャートである。このメッセージ配信処理は、スタッフがログインしたタイミング、およびメッセージ送受信画面に対して受信メッセージの確認を指示する所定の操作が行われたタイミングで実行される。

送信メッセージ処理部５１は、ログインした事業所のユーザに対する新たなメッセージが到着しているか否かを判定する（Ｓ２０）。例えば、送信メッセージ処理部５１は、ログインした事業所の事業所ＩＤおよびログインしたユーザのユーザＩＤが送付先情報の項目に格納されたレコードをメッセージ管理テーブル３３から求める。そして、送信メッセージ処理部５１は、求めたレコードのうち、メッセージＩＤが、ログインした事業所のユーザの個人メッセージ管理テーブル４４に未登録のレコードを新たなメッセージと特定する。新たなメッセージの到着がない場合（Ｓ２０否定）、処理を終了する。

一方、新たなメッセージの到着がある場合（Ｓ２０肯定）、全ての新たなメッセージに対する処理が完了したか否かを判定する（Ｓ２１）。処理が完了した場合（Ｓ２１肯定）、処理を終了する。

一方、処理が完了していない場合（Ｓ２１否定）、追加部５５は、未処理の新たなメッセージを処理対象のメッセージと選択する（Ｓ２２）。追加部５５は、処理対象のメッセージのレコードを宛先のスタッフの個人メッセージ管理テーブル４４に追加する（Ｓ２３）。例えば、追加部５５は、送付先情報の項目の事業所の項目に事業所ＩＤが格納された各事業所について、担当者の項目およびスタッフＩＤの項目にスタッフＩＤが格納された各スタッフの個人メッセージ管理テーブル４４に、メッセージＩＤのレコードを追加する。この際、追加部５５は、メッセージ管理テーブル３３の共有患者ＩＤの項目に患者ＩＤが格納されているメッセージについては、メッセージＴｙｐｅの項目を「Ｇｒｏｕｐ」とする。患者ＩＤが格納されていないメッセージについては、メッセージＴｙｐｅの項目を「Ｐｅｒｓｏｎａｌ」とする。また、追加部５５は、既読Ｆｌａｇの項目および担当者既読Ｆｌａｇの項目をそれぞれ「Ｆａｌｓｅ」とし、返信メッセージＩＤの項目を空白とする。レコードを追加が完了すると、処理は、上述のＳ２１へ移行する。

このメッセージ配信処理により、メッセージ管理システム１０では、宛先のスタッフにメッセージが配信される。また、メッセージ管理システム１０では、宛先とされたスタッフの何れかから最初にメッセージの受信要求があった際に、メッセージを宛先とされたスタッフ毎の個人メッセージ管理テーブル４４に登録する。すなわち、メッセージ管理システム１０は、メッセージの送信が指示されたタイミングではなく、最初にメッセージの受信要求があったタイミングでメッセージが宛先のスタッフに配信される。メッセージ管理システム１０は、受信要求されたタイミングでメッセージを宛先のスタッフに配信することにより、メッセージの送信が指示されたタイミングでの処理負荷を軽減させることができる。

次に、本実施例に係るメッセージ管理システム１０が未読のメッセージ一覧を表示させる未読メッセージ一覧表示処理の流れについて説明する。図２５は、未読メッセージ一覧表示処理の手順の一例を示すフローチャートである。この未読メッセージ一覧表示処理は、未読メッセージ一覧画面の表示を指示する所定の操作が行われたタイミングで実行される。なお、ログイン画面からのログインにより、画像を操作するスタッフの所属する事業所ＩＤおよびスタッフのスタッフＩＤは、特定されているものとする。

表示処理部５０は、未読メッセージ一覧画面を表示させる（Ｓ３０）。次に、表示処理部５０は、画像を操作するスタッフの個人メッセージ管理テーブル４４から、既読Ｆｌａｇの項目および担当者既読Ｆｌａｇの項目がそれぞれ「Ｆａｌｓｅ」のレコードを検索する（Ｓ３１）。

表示処理部５０は、検索された件数がゼロであるか否かを判定する（Ｓ３２）。件数がゼロである場合（Ｓ３２肯定）、処理を終了する。

一方、件数がゼロではない場合（Ｓ３２否定）、表示処理部５０は、検索されたメッセージＩＤのレコードをメッセージ管理テーブル３３から読み出す（Ｓ３３）。表示処理部５０は、読み出した全てのレコードに対する処理が完了したか否かを判定する（Ｓ３４）。処理が完了した場合（Ｓ３４肯定）、処理を終了する。

一方、処理が完了していない場合（Ｓ３４否定）、表示処理部５０は、未処理のレコードを処理対象のレコードと選択する（Ｓ３５）。表示処理部５０は、処理対象のレコードの共有患者ＩＤの項目に患者ＩＤが設定されているか否かを判定する（Ｓ３６）。共有患者ＩＤの項目に患者ＩＤが設定されている場合（Ｓ３６肯定）、表示処理部５０は、画像を操作するスタッフが担当者であるか否か判定する（Ｓ３７）。例えば、表示処理部５０は、処理対象のレコードの、画像を操作するスタッフの所属する事業所ＩＤが設定された送付先情報の項目の担当者ＩＤの項目に、画像を操作するスタッフのスタッフＩＤが設定されている場合、担当者であると判定する。なお、表示処理部５０は、画像を操作するスタッフの事業所の患者情報テーブル４１に基づいて担当者であるかを判定してもよい。担当者である場合（Ｓ３７肯定）、表示処理部５０は、「必読」を表示してメッセージを未読メッセージ一覧画面に追加して表示させ（Ｓ３８）、上述のＳ３４へ移行する。一方、担当者ではない場合（Ｓ３７否定）、表示処理部５０は、メッセージを未読メッセージ一覧画面に追加して表示させ（Ｓ３９）、上述のＳ３４へ移行する。

一方、共有患者ＩＤの項目に患者ＩＤが設定されていない場合（Ｓ３６否定）、表示処理部５０は、自身が送付先のメッセージであるか否かを判定する（Ｓ４０）。例えば、表示処理部５０は、処理対象のレコードの、画像を操作するスタッフの事業所ＩＤが設定された送付先情報の項目のスタッフＩＤの項目に、画像を操作するスタッフのスタッフＩＤが設定されている場合、自身が送付先のメッセージと判定する。自身が送付先のメッセージではない場合（Ｓ４０否定）、表示処理部５０は、個人メッセージ管理テーブル４４から当該メッセージのレコードを削除し（Ｓ４１）、上述のＳ３４へ移行する。一方、自身が送付先のメッセージである場合（Ｓ４０肯定）、表示処理部５０は、「個人」を表示してメッセージを未読メッセージ一覧画面に追加して表示させ（Ｓ４２）、上述のＳ３４へ移行する。

この未読メッセージ一覧表示処理理により、メッセージ管理システム１０では、画像を操作するスタッフが未確認かつ担当者も未確認のメッセージが未読メッセージ一覧画面に表示される。これにより、メッセージ管理システム１０は、スタッフが確認すべきメッセージを未読メッセージ一覧画面に表示させることができる。

次に、本実施例に係るメッセージ管理システム１０が未読のメッセージを参照された際のフラグを更新するフラグ更新処理の流れについて説明する。図２６は、フラグ更新処理の手順の一例を示すフローチャートである。このフラグ更新処理は、未読のメッセージの参照を指示する所定の操作が行われたタイミングで実行される。なお、ログイン画面からのログインにより、画像を操作するスタッフの所属する事業所ＩＤおよびスタッフのスタッフＩＤは、特定されているものとする。

除外部５２は、画像を操作するスタッフの個人メッセージ管理テーブル４４において、参照されたメッセージの既読Ｆｌａｇの項目を「Ｔｒｕｅ」に更新する（Ｓ５０）。除外部５２は、画像を操作するスタッフが担当者であるか否か判定する（Ｓ５１）。例えば、除外部５２は、画像を操作するスタッフの事業所の患者情報テーブル４１に基づいて画像を操作するスタッフが担当者であるか判定する。担当者ではない場合（Ｓ５１否定）、除外部５２は、後述のＳ５３の処理へ移行する。

一方、担当者である場合（Ｓ５１肯定）、除外部５２は、画像を操作するスタッフが所属する事業所の全スタッフの個人メッセージ管理テーブル４４において、参照されたメッセージの担当者既読Ｆｌａｇの項目を「Ｔｒｕｅ」に更新する（Ｓ５２）。更新部５３は、メッセージ既読者テーブル３４に、画像を操作するスタッフにより、メッセージが参照されたことを示すレコードを追加する更新を行い（Ｓ５３）、処理を終了する。

このフラグ更新処理により、メッセージ管理システム１０では、スタッフ自身が確認したメッセージおよび担当者が確認したメッセージが除外されて未読メッセージ一覧画面に表示されなくなる。これにより、メッセージ管理システム１０は、未読メッセージ一覧画面に確認が不要なメッセージが残ることを抑制できる。

また、メッセージ管理システム１０では、メッセージ既読者テーブル３４にメッセージが参照されたことを示すレコードを追加することにより、メッセージの確認通知のステータスが更新される。

次に、本実施例に係るメッセージ管理システム１０が送信メッセージ一覧画面を表示させる送信メッセージ一覧表示処理の流れについて説明する。図２７は、送信メッセージ一覧表示処理の手順の一例を示すフローチャートである。この送信メッセージ一覧表示処理は、送信メッセージ一覧画面の表示を指示する所定の操作が行われたタイミングで実行される。なお、ログイン画面からのログインにより、画像を操作するスタッフの所属する事業所ＩＤおよびスタッフのスタッフＩＤは、特定されているものとする。

表示処理部５０は、メッセージ管理テーブル３３から画像を操作するスタッフの所属する事業所が送信したメッセージを検索する（Ｓ６０）。表示処理部５０は、検索された件数がゼロであるか否かを判定する（Ｓ６１）。件数がゼロである場合（Ｓ６１肯定）、処理を終了する。

一方、件数がゼロではない場合（Ｓ６１否定）、表示処理部５０は、検索された全てのレコードに対する処理が完了したか否かを判定する（Ｓ６２）。処理が完了した場合（Ｓ６２肯定）、処理を終了する。

一方、処理が完了していない場合（Ｓ６２否定）、表示処理部５０は、未処理のレコードを処理対象のレコードと選択する（Ｓ６３）。表示処理部５０は、メッセージ既読者テーブル３４から処理対象のレコードのメッセージについての既読者のレコードを検索する（Ｓ６４）。例えば、表示処理部５０は、処理対象のレコードのメッセージＩＤが設定されたレコードをメッセージ既読者テーブル３４から検索する。表示処理部５０は、検索された件数がゼロであるか否かを判定する（Ｓ６５）。件数がゼロである場合（Ｓ６５肯定）、表示処理部５０は、処理対象のレコードのメッセージを送信メッセージ一覧画面に表示させ（Ｓ６６）、上述のＳ６２へ移行する。

一方、件数がゼロではない場合（Ｓ６５否定）、表示処理部５０は、「見る」のリンクを表示させて処理対象のレコードのメッセージを送信メッセージ一覧画面に表示させ（Ｓ６７）、上述のＳ６２へ移行する。

この送信メッセージ一覧表示処理により、メッセージ管理システム１０では、送信メッセージ一覧画面が表示される。これにより、メッセージ管理システム１０は、送信メッセージ一覧画面からメッセージが確認されたかを確認できる。また、メッセージ管理システム１０は、送信メッセージ一覧画面から宛先の事業所での担当者を確認できる。

次に、本実施例に係るメッセージ管理システム１０が既読者一覧画面を表示させる既読者一覧表示処理の流れについて説明する。図２８は、既読者一覧表示処理の手順の一例を示すフローチャートである。この既読者一覧画面表示処理は、送信メッセージ一覧画面に表示された「見る」のリンクを指定する操作が行われたタイミングで実行される。なお、ログイン画面からのログインにより、画像を操作するスタッフの所属する事業所ＩＤおよびスタッフのスタッフＩＤは、特定されているものとする。また、「見る」のリンクが指定されたメッセージのメッセージＩＤも特定されているものとする。

表示処理部５０は、メッセージ既読者テーブル３４から、「見る」のリンクが指定されたメッセージの既読者のレコードを検索する（Ｓ７０）。例えば、表示処理部５０は、「見る」のリンクが指定されたメッセージのメッセージＩＤが設定されたレコードをメッセージ既読者テーブル３４から検索する。

表示処理部５０は、検索された全てのレコードの表示が完了したか否かを判定する（Ｓ７１）。表示が完了した場合（Ｓ７１肯定）、処理を終了する。

一方、表示が完了していない場合（Ｓ７１否定）、表示処理部５０は、未表示のレコードを処理対象のレコードと選択する（Ｓ７２）。表示処理部５０は、処理対象のレコードの既読者が担当者であるか否か判定する（Ｓ７３）。例えば、表示処理部５０は、処理対象のレコードにおいて担当者Ｆｌａｇの項目が「Ｔｒｕｅ」の場合、既読者が担当者であると判定する。なお、表示処理部５０は、画像を操作するスタッフの事業所の患者情報テーブル４１に基づいて担当者であるかを判定してもよい。

既読者が担当者である場合（Ｓ７３肯定）、表示処理部５０は、既読者を担当者として既読者一覧画面に表示させ（Ｓ７４）、上述のＳ７１へ移行する。一方、既読者が担当者ではない場合（Ｓ７３否定）、表示処理部５０は、既読者を既読者一覧画面に表示させ（Ｓ７５）、上述のＳ７１へ移行する。

この既読者一覧表示処理により、メッセージ管理システム１０では、既読者一覧画面にメッセージを確認したスタッフが表示される。これにより、メッセージ管理システム１０は、メッセージを確認したスタッフを把握できる。

［効果］
上述してきたように、本実施例に係るメッセージ管理システム１０は、事業所宛に作成されたメッセージから抽出された患者ＩＤに基づき、メッセージの担当者を事業所の複数のスタッフから設定する。メッセージ管理システム１０は、メッセージを複数のスタッフそれぞれの未読メッセージ一覧画面のリストに追加する。メッセージ管理システム１０は、担当者によるメッセージの確認に応じて、担当者を除く複数のスタッフそれぞれの未読メッセージ一覧画面のリストより、メッセージを除外する。これにより、メッセージ管理システム１０は、確認が不要なメッセージが残ることを抑制できる。

また、本実施例に係るメッセージ管理システム１０は、担当者によるメッセージの確認に応じて、当該メッセージの送信元での当該メッセージの確認通知のステータスを更新する。これにより、メッセージ管理システム１０は、送信元でステータスを確認することにより、担当者のメッセージの確認状況を把握できる。

また、本実施例に係るメッセージ管理システム１０は、事業所宛に作成されたメッセージをメッセージ管理テーブル３３に登録する。そして、メッセージ管理システム１０は、複数のスタッフの何れかから最初にメッセージの受信要求があった際に、メッセージ管理テーブル３３に格納されたメッセージをメンバー毎の個別メッセージ管理テーブル４４に登録する。これにより、メッセージ管理システム１０は、メッセージの送信が指示されたタイミングでの処理負荷を軽減させることができる。

また、本実施例に係るメッセージ管理システム１０は、担当者とされたスタッフの未読メッセージ一覧画面において、担当者であることを示してメッセージを表示する。これにより、メッセージ管理システム１０は、担当者であることを示してメッセージを把握できる。

また、本実施例に係るメッセージ管理システム１０は、送信メッセージ一覧画面において、事業所Ｆのスタッフが、事業所Ｇ宛に作成した特定の案件に関するメッセージを、特定の案件に対応づけられた事業所Ｇの担当者と対応付けて表示する。これにより、メッセージ管理システム１０は、他の事業所の担当者を把握できる。

また、本実施例に係るメッセージ管理システム１０は、宛先とする事業所ＩＤおよび患者ＩＤを指定してグループ宛のメッセージの送信が可能とされている。これにより、メッセージ管理システム１０は、宛先とする事業所の担当者を知らなくてもメッセージを届けることができる。

また、メッセージ管理システム１０は、事業所ＤＢ４０に基づき、事業所ＩＤおよび患者ＩＤから事業所での担当者のスタッフＩＤを特定する。よって、担当者が変更されても事業所ＤＢ４０を更新することにより、担当者にメッセージを届けることができる。

また、例えば、医師などに連絡する場合に、連絡すべき内容であるか判断に迷い、宛先として医師を指定してメッセージを送ることに精神的にバリアが生じる場合がある。このような場合でも、本実施例に係るメッセージ管理システム１０は、個別の担当者を指定せずに事業所を宛先としてメッセージを送付するため、メッセージの送付が行いやすくなる。

また、本実施例に係るメッセージ管理システム１０は、事業所宛てのメッセージおよび個人宛のメッセージを同じメッセージリストに一覧表示する。これにより、本実施例に係るメッセージ管理システム１０は、１つのメッセージリストを確認することで、受信されたメッセージを確認できるため、メッセージを見落とすことを抑制できる。

さて、これまで開示の装置に関する実施例について説明したが、開示の技術は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

例えば、上記の実施例では、既読者一覧画面に、メッセージを確認した担当者および担当者以外のスタッフを一覧表示する場合について説明したが、開示の装置はこれに限定されない。例えば、表示処理部５０は、担当者により確認された場合と、担当者以外のスタッフに確認された場合とで、表示態様を異ならせてもよい。例えば、表示処理部５０は、送信メッセージ一覧画面において、担当者により確認された場合と、担当者以外のスタッフに確認された場合とで、色や文字サイズ、文字種、背景パターンなどを変えて表示態様を異ならせてもよい。また、表示処理部５０は、既読者一覧画面において、担当者により確認されたレコードと、担当者以外のスタッフに確認されたレコードとの色や文字サイズ、文字種、背景パターンなどを変えて表示態様を異ならせてもよい。

また、上記の実施例では、担当者により確認されたメッセージを担当者以外のスタッフの未読メッセージ一覧画面から除外する場合について説明したが、開示の装置はこれに限定されない。例えば、担当者により確認されたメッセージを担当者以外のスタッフの受信トレイなどの受信メッセージのリストから除外してもよい。

また、上記の実施例では、メッセージの宛先として事業所を指定する場合について説明したが、開示の装置はこれに限定されない。例えば、宛先としては、複数のメンバーが所属し、担当者が定められるグループであればいずれであってもよい。

また、上記の実施例では、送付が指示されたメッセージをメッセージ管理テーブル３３に格納し、最初にメッセージの受信要求があった際に、個人メッセージ管理テーブル４４に格納する場合について説明したが、開示の装置はこれに限定されない。例えば、送付が指示された段階でメッセージをメッセージ管理テーブル３３および個人メッセージ管理テーブル４４に格納するようにしてもよい。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的状態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、メッセージ管理システム１０の表示処理部５０、送信メッセージ処理部５１、除外部５２、更新部５３、設定部５４および追加部５５の各処理部が適宜統合されてもよい。また、各処理部の処理が適宜複数の処理部の処理に分離されてもよい。さらに、各処理部にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

［メッセージ管理プログラム］
また、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することもできる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。図２９は、メッセージ管理プログラムを実行するコンピュータを示す図である。

図２９に示すように、コンピュータ３００は、ＣＰＵ（Central Processing Unit）３１０、ＨＤＤ（Hard Disk Drive）３２０、ＲＡＭ（Random Access Memory）３４０を有する。これら３００〜３４０の各部は、バス４００を介して接続される。

ＨＤＤ３２０には上記のメッセージ管理システム１０の表示処理部５０、送信メッセージ処理部５１、除外部５２、更新部５３、設定部５４および追加部５５と同様の機能を発揮するメッセージ管理プログラム３２０ａが予め記憶される。なお、メッセージ管理プログラム３２０ａについては、適宜分離しても良い。

また、ＨＤＤ３２０は、各種情報を記憶する。例えば、ＨＤＤ３２０は、ＯＳや範囲選択のメッセージ管理に用いる各種データを記憶する。

そして、ＣＰＵ３１０が、メッセージ管理プログラム３２０ａをＨＤＤ３２０から読み出して実行することで、実施例の各処理部と同様の動作を実行する。すなわち、メッセージ管理プログラム３２０ａは、表示処理部５０、送信メッセージ処理部５１、除外部５２、更新部５３、設定部５４および追加部５５と同様の動作を実行する。

なお、上記したメッセージ管理プログラム３２０ａについては、必ずしも最初からＨＤＤ３２０に記憶させることを要しない。

例えば、コンピュータ３００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」にプログラムを記憶させておく。そして、コンピュータ３００がこれらからプログラムを読み出して実行するようにしてもよい。

さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ３００に接続される「他のコンピュータ（またはサーバ）」などにプログラムを記憶させておく。そして、コンピュータ３００がこれらからプログラムを読み出して実行するようにしてもよい。

１０ メッセージ管理システム
１１ 端末装置
１３ ネットワーク
２０ 記憶部
２１ 処理部
３０ 共通ＤＢ
３１ 共通患者情報テーブル
３２ 連携事業所情報テーブル
３３ メッセージ管理テーブル
３４ メッセージ既読者テーブル
４０ 事業所ＤＢ
４１ 患者情報テーブル
４２ スタッフ情報テーブル
４３ 事業所情報テーブル
４４ 個人メッセージ管理テーブル
５０ 表示処理部
５１ 送信メッセージ処理部
５２ 除外部
５３ 更新部
５４ 設定部
５５ 追加部
７０ 未読メッセージ一覧画面
７１ 送信メッセージ一覧画面
７２ 既読者一覧画面

Claims (9)

1. コンピュータが、
   グループ宛に作成されたメッセージから抽出された情報に基づき、前記メッセージの担当者を前記グループに対応づけられた複数のメンバーから設定し、
   前記メッセージを前記複数のメンバーそれぞれのメッセージリストに追加し、
   前記担当者による前記メッセージの確認に応じて、前記担当者を除く前記複数のメンバーそれぞれの前記メッセージリストより、前記メッセージを除外する、
   処理を実行することを特徴とするメッセージ管理方法。
2. コンピュータが、
   前記担当者による前記メッセージの確認に応じて、当該メッセージの送信元での当該メッセージの確認通知のステータスを更新する
   処理をさらに実行することを特徴とする請求項１に記載のメッセージ管理方法。
3. 前記追加する処理は、グループ宛に作成されたメッセージを共通のメッセージ管理テーブルに登録し、前記複数のメンバーの何れかから最初にメッセージの受信要求があった際に、前記メッセージ管理テーブルに格納された前記メッセージをメンバー毎のメッセージ管理テーブルに登録する
   ことを特徴とする請求項１または２に記載のメッセージ管理方法。
4. コンピュータが、
   担当者とするメンバーが記憶された担当情報に基づき、前記複数のメンバーのうち担当者とされたメンバーの前記メッセージリストにおいて、担当者であることを示して前記メッセージを表示する
   処理をさらに実行することを特徴とする請求項１〜３の何れか１つに記載のメッセージ管理方法。
5. コンピュータが、
   第１のグループのメンバーである第１の担当者が、前記第１のグループと異なる第２のグループ宛に作成した特定の案件に関するメッセージを、前記特定の案件に対応づけられた前記第２のグループの第２の担当者と対応付けて表示する
   処理を実行することを特徴とするメッセージ管理方法。
6. コンピュータが、
   前記メッセージが前記第２の担当者により確認された場合と、前記第２のグループのメンバーであって前記第２の担当者と異なるメンバーに確認された場合とで、送信済みメッセージリストでの表示態様を異ならせる
   処理をさらに実行することを特徴とする請求項５に記載のメッセージ管理方法。
7. コンピュータに、
   グループ宛に作成されたメッセージから抽出された情報に基づき、前記メッセージの担当者を前記グループに対応づけられた複数のメンバーから設定し、
   前記メッセージを前記複数のメンバーそれぞれのメッセージリストに追加し、
   前記担当者による前記メッセージの確認に応じて、前記担当者を除く前記複数のメンバーそれぞれの前記メッセージリストより、前記メッセージを除外する、
   処理を実行させることを特徴とするメッセージ管理プログラム。
8. コンピュータに、
   第１のグループのメンバーである第１の担当者が、前記第１のグループと異なる第２のグループ宛に作成した特定の案件に関するメッセージを、前記特定の案件に対応づけられた前記第２のグループの第２の担当者と対応付けて表示する
   処理を実行させることを特徴とするメッセージ管理プログラム。
9. 第１のグループのメンバーである第１の担当者が、前記第１のグループと異なる第２のグループ宛に作成した特定の案件に関するメッセージから抽出された情報に基づき、前記メッセージを担当する前記第２のグループの第２の担当者を前記第２のグループに対応づけられた複数のメンバーから設定する設定部と、
   前記メッセージを前記複数のメンバーそれぞれのメッセージリストに追加する追加部と、
   前記担当者による前記メッセージの確認に応じて、前記担当者を除く前記複数のメンバーそれぞれの前記メッセージリストより、前記メッセージを除外する除外部と、
   前記第１の担当者のメッセージリストに前記メッセージを前記第２の担当者と対応付けて表示する表示処理部と
   を有することを特徴とするメッセージ管理システム。

Images