JP2021086543A - 医療用取引管理システム、医療用取引管理方法、および医療用取引管理プログラム - Google Patents

Abstract

【課題】医療機関における各種管理を容易にし、利用者の利便性を向上させる。【解決手段】医療機関担当者端末２０と企業担当者端末１０とサーバ装置１００の少なくとも１つに各種データを記憶する記憶部１０５を備え、記憶部１０５は、前記医療機関担当者に関する医療機関担当者データと、前記企業担当者に関する企業担当者データとを記憶する構成であり、前記医療機関担当者データは、少なくとも承認者としての権限を有するのか否かを認識可能に構成されており、前記医療機関担当者が前記企業担当者に見積の依頼を行う依頼処理部１０１ｇと、前記依頼処理部により得られた見積についての契約文書を前記企業担当者に求める契約文書依頼ステップＳ９と、前記見積と前記契約文書の少なくとも一方について可否の承認を行う契約承認ステップＳ１４とを備えた。【選択図】図１２

Description

この発明は、医療用の取引に利用するような医療用取引管理システム、医療用取引管理方法、および医療用取引管理プログラムに関する。

近年、医療機関において、スケジュールの管理や取引先との契約書などの書類の管理は、大きな負担となっている。スケジュールを管理するものとして、例えば、在庫管理および通知システムが提案されている（特許文献１参照）。このシステムは、関係情報、現在残量、および使用量の履歴に基づいて消耗品の注文スケュールを推奨するように構成されている。

しかし、医療機関において管理しなければならないことは様々であり、より便利なソフトウェアが望まれていた。

特開２０１２−２４３３２４号公報

この発明は、上述の問題に鑑みて、医療機関における各種管理を容易にする医療用取引管理システム、医療用取引管理方法、および医療用取引管理プログラムを提供し、利用者の利便性を向上させることを目的とする。

この発明は、医療に関するサービスを行う医療機関で業務する医療機関担当者が使用する複数の医療機関担当者端末と、前記医療機関に物または／およびサービスを提供する取引先企業の企業担当者が使用する複数の企業担当者端末と、前記医療機関担当者端末および前記企業担当者端末と通信回線を介して接続されたサーバ装置とを備え、前記医療機関担当者端末と前記企業担当者端末と前記サーバ装置の少なくとも１つに各種データを記憶する記憶手段を備え、前記記憶手段は、前記医療機関担当者に関する医療機関担当者データと、前記企業担当者に関する企業担当者データとを記憶し、前記医療機関担当者データは、少なくとも承認者としての権限を有するのか否かを認識可能に構成されており、前記医療機関担当者が前記企業担当者に見積の依頼を行う依頼処理部と、前記依頼処理部により得られた見積についての契約文書を前記企業担当者に求める契約文書処理部と、前記見積と前記契約文書の少なくとも一方について可否の承認を行う承認処理部とを備えた医療用取引管理システム、医療用取引管理方法、および医療用取引管理プログラムであることを特徴とする。

この発明により、医療機関における各種管理を容易にすることができる。

医療用取引管理システムのシステム構成を示すブロック図。 サーバ装置の構成を示すブロック図。 サーバ装置のデータ構成を示すデータ構成説明図。 医療機関担当者端末に表示したログイン画面の画面構成図。 医療機関担当者端末に表示したトップページ画面の画面構成図。 医療機関担当者端末に表示した依頼ページ画面の画面構成図。 医療機関担当者端末に表示した文書整理ページ画面の画面構成図。 医療機関担当者端末に表示した契約文書更新ページ画面の画面構成図。 医療機関担当者端末に表示したカテゴリ設定ページ画面の画面構成図。 医療機関担当者端末に表示されたスケジュール管理ページ画面の画面構成図。 医療機関担当者端末に表示されたユーザ設定ページ画面の画面構成図。 医療用取引管理システムの動作を示すフローチャート。

以下、本発明の一実施形態を図面と共に説明する。
図１は、医療用取引管理システムの全体構成を示すブロック図である。
医療用取引管理システムＡは、病院や介護施設、クリニックなど医療に関するサービスを行う医療機関で業務する医師や医療事務などの医療機関担当者が使用する複数の医療機関担当者端末２０、医療機関に物やサービスを提供する医療機関の取引先である企業（業者）に属する企業担当者が使用する複数の企業担当者端末１０、システムを管理する管理者が使用する管理者端末９０およびサーバ装置１００を有している。サーバ装置１００は、インターネットを介して企業担当者端末１０、医療機関担当者端末２０、管理者端末３０と接続されている。

企業担当者端末１０、医療機関担当者端末２０、および管理者端末３０は、通信部１４、２４、３４、制御部１１、２１、３１、入力部１２、２２、３２、および表示部１３、２３、３３を有するパーソナルコンピュータやタブレット端末、スマートフォンなどの通信可能なコンピュータで構成されている。サーバ装置１００は、制御部１０１、入力部１０２、表示部１０３、通信部１０４、および記憶部１０５を有するサーバコンピュータにより構成されている。

制御部１１、２１、３１、１０１は、各種演算や制御動作を実行する。表示部１３、２３、３３、１０３は、液晶ディスプレイまたは有機ＥＬディスプレイ等の適宜の表示装置により構成されている。また、入力部１２、２２、３２、１０２は、キーボードやマウスまたは、表示部１３、２３、３３、１０３に重ねて設けられたタッチパネル等の適宜の入力装置によって構成されている。

通信部１４、２４、３４、１０４は、ＬＡＮボードまたはＷｉＦｉ通信ユニット等の有線または無線の通信機器で構成されて有線または無線での通信を実行し、インターネット１へ接続する。入力部１２、２２、３２、１０２は、企業担当者、医療機関担当者、および管理者によって行われる操作を受け付ける。入力部１２、２２、３２、１０２を操作した際の操作データは、通信部１４、２４、３４、１０４によってサーバ装置１００へ送信される。

記憶部１５、２５、３５、１０５は、ハードディスクまたは不揮発性メモリ等の記憶手段により構成されており、各種データを記憶している。また、記憶部１５は、企業担当者用プログラム１５ａを記憶しており、記憶部２５は、医療機関担当者用プログラム２５ａを記憶しており、記憶部３５は、管理者用プログラム３５ａを記憶しており、記憶部１０５は、サーバ用プログラム１０５ａを記憶している。これらのプログラムは、各制御部１１、２５、３５、１０１によって実行される。

図２は、サーバ装置１００の制御部１０１がサーバ用プログラム１０５ａによって実行する動作の機能ブロック図である。
サーバ装置１００の制御部１０１は、ログイン処理部１０１ａ、ダッシュボード表示部１０１ｂ、文書整理部１０１ｆ、依頼処理部１０１ｇ、スケジュール整理部１０１ｈ、カテゴリ設定部１０１ｉ、およびユーザ設定部１０１ｊとして機能する。ダッシュボード表示部１０１ｂは、カレンダー表示部１０１ｃ、受信メッセージ表示部１０１ｄ、および受信契約書表示部１０１ｅを有している。これらの各機能部の説明は、これらの機能部が表示する画面と共に後述する。

なお、これらの各機能部は、企業担当者端末１０、医療機関担当者端末２０、および管理者端末３０からの各プログラム（１５ａ、２５ａ、３５ａ）による各アクセスに対して、各端末（１０、２０、３０）にてローカルで操作しているかのように各機能を提供するが、各機能部をサーバ装置１００ではなく各端末（１０、２０、３０）に備えるなど、適宜の構成とすることができる。

サーバ装置１００の記憶部１０５は、企業担当者、医療機関担当者または管理者であって、それぞれ端末を操作し、システムを利用するユーザの情報であるユーザ関連データ１１１、企業担当者と医療機関担当者間の契約書など書類の情報である書類関連データ１１２、医療機関担当者が企業担当者（または企業）に依頼を行った際のメッセージなど依頼の情報である依頼関連データ１１３、ユーザのスケジュール情報であるスケジュール関連データ１１４、および社内メモ関連データ１１５を有している。

図３は、サーバ装置１００の記憶部１０５に記憶されているデータベースのデータ構成図である。
図３（ａ）は、ユーザ関連データ１１１のデータ構成を示す。図３（ｂ）は、書類関連データ１１２のデータ構成を示す。図３（ｃ）は、依頼関連データ１１３のデータ構成を示す。図３（ｄ）は、スケジュール関連データ１１４のデータ構成を示す。

ユーザ関連データ１１１は、医療機関テーブル１２０、企業テーブル１２１、医療機関担当者テーブル１２２、企業担当者テーブル１２３、管理者テーブル１２４、医療機関と企業の中間テーブル１２５を有している。

医療機関テーブル１２０は、医療機関名、医療機関ごとに付与されたＩＤなどを有する。企業テーブル１２１は、企業名、企業ごとに付与されたＩＤなどを有する。

医療機関担当者テーブル１２２は、医療機関担当者ごとに付与されたＩＤ、医療機関担当者の氏名、医療機関担当者の所属する医療機関の医療機関外部キー、役職、メールアドレス、および権限などを有する。権限には、医療機関担当者として企業担当者とメッセージ送受信等の実務を行う「一般」と、医療機関担当者からの見積承認申請や契約文書承認申請に対して承認を行う「承認者」と、全ての操作を行える「管理者」のいずれかが記憶される。企業担当者テーブル１２３は、企業担当者ごとに付与されたＩＤ、企業担当者の氏名、企業担当者の所属する企業の企業外部キー、役職、メールアドレス、および権限などを有する。管理者テーブル１２４は、管理者ごとに付与されたＩＤ、氏名および、メールアドレスなどを有している。

書類関連データ１１２は、契約文書テーブル１３０、その他の文書テーブル１３１、文書カテゴリテーブル１３２、文書の添付ファイルテーブル１３３を有している。

契約文書テーブル１３０は、契約を交わす医療機関と企業の医療機関外部キー、企業外部キー、文書カテゴリ外部キー、契約開始日、契約終了日、タイトル、および内容などを有している。その他文書テーブル１３１は、文書を送受信した医療機関と企業の医療機関外部キー、企業外部キー、文書カテゴリ外部キー、添付ファイル外部キーおよびタイトルなどを有する。

文書カテゴリテーブル１３２は、カテゴリ名および、検討日などを有している。文書の添付ファイルテーブル１３３は、契約文書外部キー、オリジナルファイル名および、保存ファイル名などを有している。

依頼関連データ１１３は、依頼テーブル１４０、依頼カテゴリテーブル１４１、依頼スレッドテーブル１４２、スレッド内メッセージテーブル１４３、メッセージ既読テーブル１４４、メッセージ添付ファイルテーブル１４５を有している。

依頼テーブル１４０は、依頼タイトル、依頼をする医療機関外部キー、依頼のカテゴリ外部キーなどを有している。依頼カテゴリテーブル１４１は、カテゴリ名、医療機関外部キーなどを有している。依頼スレッドテーブル１４２は、依頼外部キー、企業外部キー、ステータスなどを有している。

スレッド内メッセージテーブル１４３は、スレッド外部キー、添付ファイル外部キー、送信者名、本文などを有している。既読テーブル１４４は、既読者外部キー、スレッド外部キーなどを有している。メッセージ添付ファイルテーブル１４５は、メッセージ外部キー、オリジナルファイル名、保存ファイル名などを有している。

これらの依頼関連データ１１３（テーブル１４０〜１４５）により、１つの依頼について複数の企業に打診し、各企業の担当者とやり取りするデータを適切に保存できる。すなわち、依頼テーブル１４０の１つの依頼には、企業別に依頼スレッドが作成されて依頼スレッドテーブル１４２に記憶され、かつ、その企業の依頼スレッド内で医療機関担当者からのメッセージと企業担当者からのメッセージがスレッド内メッセージ１４３に記憶される。このスレッド内メッセージテーブル１４３の送信者外部キーは、メッセージを送信した医療機関担当者のＩＤ（医療機関担当者テーブル１２２参照）または企業担当者のＩＤ（企業担当者テーブル１２３参照）が記憶されている。

このようなデータ構造であるから、医療機関担当者は、一覧表示される依頼の１つを選択すると、その依頼についてメッセージの送信または／および受信をしている企業が一覧表示され、さらにそのうちの１つの企業を選択すると、その企業との間で医療機関担当者が送信したメッセージと企業担当者が送信したメッセージがスレッド式にて時系列で一覧表示されるといった形でメッセージを確認できる。スレッド式の表示は、例えば左右のうち一方に医療機関担当者が送信したメッセージを表示し、他方に企業担当者が表示したメッセージを表示するという形で実施できる。

また、スレッド内メッセージテーブル１４３の送信者モデルタイプには、送信者が医療機関担当者であるか企業担当者であるかを示す識別子が記憶されており、この送信者モデルタイプ（医療機関担当者か企業担当者かを示す）と送信者外部キー（どの医療機関担当者または企業担当者かを示す）によって送信者を特定できるように構成されている。

スケジュール関連データ１１４は、スケジュールテーブル１５０を有している。スケジュールテーブル１５０は、医療機関外部キー、ユーザ外部キー、開始日、終了日、タイトルなどを有している。

社内メモ関連データ１１５は、社内メモテーブル１５１を有している。社内メモテーブル１５１は、ユーザ外部キー、メモ対象外部キーなどを有している。

これらの各テーブル１２０〜１５１は、そのテーブルの固有の識別情報としてＩＤを有しており、他のテーブルの情報と連結するための外部キーを必要に応じて有している。外部キーは、その名称と同じ名称のテーブルのＩＤが記憶されている。例えば企業担当者テーブル１２３であれば、「医療機関外部キー」には医療機関テーブル１２０のＩＤと一致するＩＤが記憶されており、「企業外部キー」には企業テーブル１２１のＩＤと一致するＩＤが記憶されている。このようにＩＤと外部キーによって各テーブル（データ）が連結されている。

図４〜図１１は、医療機関担当者端末２０のディスプレイ４０に表示する各種画面の説明図である。いずれの画面も、サーバ装置１００の記憶部１０５に記憶されている各種データ（図３参照）を読み出して、そのデータが表示されているものである。

図４は、ログイン処理部１０１ａによって医療機関担当者端末２０のディスプレイ４０に表示されたログインページ４１の画面構成図である。
ログインページ４１は、メールアドレスの入力を受け付けるメールアドレス入力部４２と、パスワードの入力を受け付けるパスワード入力部４３と、ログインの実行を受け付けるログインボタン４４とを備えている。

登録されたメールアドレスと設定されたパスコードを用いることで、サーバ装置１００は、医療機関担当者テーブル１２２（図３参照）または管理者ユーザテーブル１２４に登録済みで医療機関担当者端末２０を用いる医療機関担当者、または企業担当者テーブル１２３（図３参照）に登録済みで企業担当者端末１０を用いる企業担当者がログインすることを許容する。

ログインボタン４４が選択されると、サーバ装置１００は、ログイン処理部１０１ａによりメールアドレスとパスワードの照合を行い、メールアドレスおよびパスワードが正しければ、医療機関担当者端末２０のログインを許容し、ユーザデータに基づいたトップページデータ（ダッシュボードデータ）を医療機関担当者端末２０に送信する。医療機関担当者端末２０は、トップページデータを受信し、表示部２３によって表示する。

図５は、ダッシュボード表示部１０１ｂによって医療機関担当者端末２０のディスプレイ４０に表示されたトップページ５０（ダッシュボード）の画面構成図である。
トップページ５０は、タスクバー６０、コマンド部７０、カレンダー８０、および通知部９０を有している。タスクバー６０は、画面左側に、コマンド部７０は、タスクバー６０の右側上部（中央上部）に、カレンダー８０は、タスクバー右側下部（中央下部）に、通知部９０は、画面右側に表示されている。

タスクバー６０は、選択されるとトップページ（ダッシュボード）画面を表示するダッシュボードタブ６１、文書整理ページを表示する文書を整理する文書整理タブ６２、依頼ページを表示する依頼をする依頼タブ６３、スケジュールページを表示するスケジュール管理タブ６４、カテゴリ設定ページを表示するカテゴリ設定タブ６５、ユーザ設定ページを表示するユーザ設定タブ６６を有している。

トップページ画面５０が表示されているとき、タスクバー６０のダッシュボードタブ６１は、タスクバー６０内の他のタブと異なる色で表示される。

コマンド部７０は、選択されると、文書整理ページを表示する文書を整理する文書整理ボタン７２、依頼ページを表示する依頼をする依頼ボタン７３、スケジュールページを表示するためのスケジュール管理ボタン７４、カテゴリ設定ページを表示するためのカテゴリ設定ボタン７５、ユーザ設定ページを表示するユーザ設定ボタン７６を有している。

カレンダー８０は、カレンダー表示部１０１ｃによって、医療機関担当者個人が入力した個人スケジュール８１と、医療機関担当者が所属する医療機関のグループスケジュール８２を併せて表示している。

個人スケジュール８１は、カレンダー８０に表示される複数の日付部分のうち、スケジュールテーブル１５０（図３参照）に記憶されている終了日（若しくは開始日）と同一の日付部分に、当該スケジュールのタイトルが表示されたものである。この個人スケジュール８１は、医療機関担当者の個別のスケジュールであるため、他の医療機関担当者がログインしている場合には表示されないものである。

グループスケジュール８２は、カレンダー８０に表示される複数の日付部分のうち、契約文書テーブル１３０（図３参照）に記憶されている契約終了日と同一の日付部分に、当該契約文書の契約タイトルが表示される。このグループスケジュール８２は、１つの医療機関において全医療機関担当者に共通するスケジュール８２であるため、当該医療機関に所属する他の医療機関担当者がログインした場合であってもカレンダー８０に表示される。また、グループスケジュール８２としては、契約文書の更新等の検討を開始すべき検討日も表示される。

なお、カレンダー８０における１つの日付部分に複数のスケジュール（８１，８２）を表示する必要がある場合には、１つのスケジュール（８１．８２）のタイトルを表示し、表示できていないスケジュール（８１，８２）の件数と、これらの表示できていないスケジュール（８１，８２）を確認するための表示ボタン（図示の例では「もっとみる」と記載）を表示する。
本例では、２０１９年１１月のカレンダーを表示し、１３日、１５日、２２日、２７日、３０日に予定（スケジュール）が入っていることを表示している。

通知部９０は、メッセージ通知部９１および契約文書通知部９２を有している。メッセージ通知部９１は、画面右上部に、契約文書通知部９２は、画面右下部（メッセージ通知部の下部）に位置している。

メッセージ通知部９１は、受信メッセージ表示部１０１ｄによって、依頼テーブル１４０のステータスが「見積中」である依頼で、かつ、企業担当者からメッセージを受信している状態の依頼を一覧表示する。各依頼については、「依頼タイトル」およびそのメッセージを送信した企業の「企業名」（取引業者）と未読メッセージの「件数」を表示する。

契約文書通知部９２は、受信契約書表示部１０１ｅによって、契約文書テーブル１３０のステータスが「契約手続中」で企業担当者から送信された契約文書を一覧表示する。各契約文書については、「件名」およびその契約文書を送信した企業の「企業名」（取引業者）を表示する。

本例では、メッセージ通知部９１は、１件の未読のメッセージがあることを表示している。契約文書通知部９２は、取引業者（企業）から１件の契約書がアップロードされたことを表示している。

メッセージ通知部９１および契約文書通知部９２に表示される通知は、医療機関担当者がその通知されたメッセージや契約文書を確認（既読）したとき、通知部９０から削除される。通知部９０は、メッセージ通知部９１と契約文書通知部９２の両方の通知するものがなくなった場合、“現在、タスクはありません。”という表記を表示する。

図６は、依頼処理部１０１ｇによって医療機関担当者端末２０のディスプレイ４０に表示された画面の説明図であり、図６（Ａ）は、既に行った又は進行中の依頼を表示する依頼ページ１８０の画面構成図であり、図６（Ｂ）は、依頼を新規作成する新規依頼作成メニュー１９０の画面構成図である。

依頼ページ１８０は、タスクバー６０、依頼を新規作成する新規依頼ボタン１８１、依頼の検索、絞り込みを行う検索部１６０、依頼一覧を表示する依頼一覧表示部１７０を有している。

依頼ページ１８０が表示されているとき、タスクバー６０における依頼をするタブ６２は、タスクバー６０内の他のタブと異なる色で表示される。

検索部１６０は、依頼が終了しているか、継続中かを選択する終了チェック選択部１６１、依頼先である取引業者（企業）を選択する取引業者選択部１６２、依頼のカテゴリを選択するカテゴリ選択部１６３、依頼の状態を選択する状態選択部１６４、依頼を行った日を入力する依頼日入力部１６５、依頼の件名入力部１６６、および検索を実行する検索ボタン１６７を有している。

検索部１６０は、検索条件である終了チェック選択部１６１、取引業者選択部１６２、取引業者選択部１６３、カテゴリ選択部１６３、状態選択部１６４、日付入力部１６５、件名入力部１６６のいずれか１つまたは複数を用いた検索を可能とする。

医療機関担当者端末２０の制御部２５は、検索条件が入力されたのち、検索ボタン１６７が選択されると、検索条件に該当する依頼をサーバ装置１００から受信して依頼一覧表示部１７０に表示する。

依頼一覧表示部１７０は、選択されると依頼中である依頼のスレッドを表示する依頼中スレッド選択部１７１、完了した依頼のスレッドを表示する完了スレッド選択部１７２を有する。依頼一覧表示部１７０は、選択された依頼中スレッド選択部１７１あるいは、完了スレッド選択部１７２のいずれかに対応した依頼を表示する。

依頼は、依頼ごとにスレッド１７３として表示される。依頼一覧表示部１７０に表示された複数のスレッド１７３は、それぞれの依頼をした日を示す依頼日１７４、取引業者（企業）を示す依頼先１７５、依頼のカテゴリを示す依頼カテゴリ１７６、依頼の状態を示すステータス１７７、依頼の件名を示す依頼件名１７８が表示され、依頼の本文を表示するためのアイコン１７９が備えられている。

依頼のスレッド１７３が選択されると、スレッド１７３内の依頼先（企業）ごとのスレッドである企業スレッド１８２が表示される。企業スレッド１８２は、依頼の状態を企業ごとに表示する企業別ステータス１８３、選択されると依頼の詳細を表示する企業別依頼詳細ボタン１８４を有している。企業別依頼詳細ボタン１８４が選択されると、依頼内容やこれまでに行われた企業とのメッセージのやりとりなどを表示する。

医療機関担当者端末２０は、依頼ページ１８０が備えた新規依頼ボタン１８１が選択されると、依頼を新規作成する新規依頼作成メニュー１９０（図６（Ｂ））を表示する。新規依頼作成メニュー１９０は、依頼ページ１８０をバックグラウンドとして、その上にフォアグラウンドとして表示される。

図６（Ｂ）に示す新規依頼作成メニュー１９０は、取引先（依頼先企業）が単数、あるいは複数選択される新規取引先選択部１８８、依頼カテゴリが選択される新規依頼カテゴリ選択部１８９、件名が入力される新規件名入力部１９１、本文が入力される新規本文入力部１９２、添付ファイルを表示する添付ファイル表示部１９３、選択されると添付ファイル選択を促す画面を表示する添付ファイル追加ボタン１８５、選択されると新規依頼作成をキャンセルするキャンセルボタン１８６、依頼の新規作成情報を送信する新規依頼送信ボタン１８７を有する。

新規取引先選択部１８８、新規依頼カテゴリ選択部１８９、新規件名入力部１９１、新規本文入力部１９２のそれぞれが入力され、新規依頼を送信する新規依頼送信ボタン１８７が選択されると、作成された依頼が新規取引先選択部１８８で選択された企業へ送信される。そうして、新規依頼作成メニュー１９０は閉じられ、作成した新規依頼が依頼一覧表示部１７０に表示される。この新依頼作成メニュー１９０は、新規依頼送信ボタン１８７が選択された場合や新規依頼作成をキャンセルするキャンセルボタン１８６が選択された場合に閉じられる。

新規依頼が保存されると、依頼ページ１８０の新たなスレッド１７３として、表示される。

依頼は、医療機関担当者からの採用検討のための依頼であって、企業へカタログを請求する、見積もり書を依頼する、契約書を依頼するなどの依頼である。これらの採用検討のための依頼を医療機関担当者が行うとき、医療機関担当者端末２０は、医療機関担当者により操作され、依頼をするページから新規依頼ボタン１８１が選択され、新規依頼作成メニュー１９０の各項目が入力され、新規依頼送信ボタン１８７が押下されることで行われる。

また、新規依頼作成メニュー１９０の、新規取引先選択部１８８は、複数の取引先の選択を許容する。新規依頼の作成がなされると、サーバ装置１００は、一覧表示部１７において、１つの依頼につき１つのスレッド１７３を作成する。複数の取引先を選択された場合も、１つの依頼につき１つのスレッド１７３を作成し、スレッド１７３が選択されると、依頼をした企業の数だけ企業スレッド１８２を表示する。

図７は、文書整理部１０１ｆによって医療機関担当者端末２０のディスプレイ４０に表示される画面の説明図であり、図７（Ａ）は、文書を整理する文書整理ページ２００の画面構成図であり、図７（Ｂ）は、新規文書を整理する新規文書整理メニュー２４０の画面構成図である。

図７（Ａ）に示す文書整理ページ２００は、タスクバー６０、選択されると新規文書の整理を促す新規文書整理メニュー２４０を表示する新規文書整理ボタン２１７、文書を検索する検索部２１０、および文書を一覧表示する文書一覧表示部２２０を有している。

文書整理ページ２００を表示しているとき、タスクバー６０の文書を整理するタブ６４は、タスクバー６０内の他のタブと異なる色で表示される。

検索部２１０は、文書を検索する際の検索条件として、取引先業者（企業）が選択される取引業者選択部２１１、文書のカテゴリが選択される文書カテゴリ選択部２１２、書類の契約満了日が入力される契約満了日入力部２１３、件名やファイル名などキーワードが入力されるキーワード入力部２１４、を有し、検索を実行する検索ボタン２１５を有する。

医療機関担当者端末２０により、検索条件が入力されたのち、検索ボタン１６７が選択されると検索条件にあった文書を文書一覧表示部２２０に表示する。

文書一覧表示部２２０は、選択されると整理済みの契約書のみを表示する整理済み書類選択ボタン２２１、未整理の契約書のみを表示する未整理書類選択ボタン２２２、その他の書類を表示するその他書類選択ボタン２３３を有している。

文書一覧表示部２２０は、整理済み書類選択ボタン２２１、未整理書類選択ボタン２２２、あるいはその他書類選択ボタン２２３のいずれかが選択され、選択された条件に対応する書類の一覧を表示する。また、検索部２１０に検索条件が入力され、検索ボタン２１５が選択されたたときは、さらに検索条件に一致した書類を表示する。

文書一覧表示部２２０は、企業より受け取った１つの文書（若しくはひとまとまりの文書）を１つのスレッド２３３として複数並べて一覧表示する。各スレッド２３３は、それぞれの文書の作成日、または受け取り日である文書作成日２２４、文書の作成者あるいは文書の送付元である作成者（企業担当者）２２５、書類の取引を行った取引業者（企業）２２６、文書のカテゴリ２２７、契約書の契約満了日２２８ａ（または文書の有効期限を示す終了日２２８ａ）、および契約の金額２２８ｂ、文書の件名２２９を有している。

文書一覧表示部２２０は、さらに、選択されると文書とともに送受信されたメッセージの本文を表示するアイコン２３０、保存ファイルを表示する保存ファイルボタン２３１、および編集を行う編集ボタン２３２が備えられている。

医療機関担当者端末２０は、医療機関担当者により新規文書整理ボタン２１７が選択されると、整理する書類が契約書であるか、その他の書類であるかを選択する画面を表示する。医療機関担当者により、書類が契約書であることの選択がされると、文書を新規作成する新規文書整理メニュー２４０を表示する。新規文書整理メニュー２４０は、文書整理ページ２００をバックグラウンドとして、その上にフォアグラウンドとして表示される。

図７（Ｂ）に示す新規文書整理メニュー２４０は、契約をする取引業者（企業）を選択する取引業者選択部２４１、契約書の件名を入力する件名入力部２４２、契約の開始日を選択する契約開始日選択部２４３、契約の終了日を選択する契約終了日選択部２４４、契約更新の検討を開始する日を選択する検討日選択部２４５、契約のカテゴリを選択する契約カテゴリ選択部２４６、契約金額を入力する契約金額入力部２４７、メモを記入するメモ記入部２４８、選択されると添付ファイルの選択を促す画面を表示する添付ファイル選択部２４９、添付ファイル選択部２４９により選択された添付ファイルを表示する添付ファイル表示部２５２、選択されると新規文書整理をキャンセルするキャンセルボタン２５１、新規文書整理を登録する保存ボタン２５０を有している。

新規文書整理メニュー２４０は、少なくとも取引業者選択部２４１、件名入力部２４２、契約開始日選択部２４３、契約終了日選択部２４４、契約カテゴリ選択部２４５、契約金額入力部２４７が記入され、その後、保存ボタン２５０が選択されると、作成された新規文書を契約文書テーブル１３０（図３参照）に追加保存して新規文書整理メニュー２４０を閉じる。また、キャンセルボタン２５１が選択された際も、新規文書整理メニュー２４０は閉じられる。

新規文書が保存されると、この新規文書は、文書整理ページ２００の新たなスレッド２３３として表示される。また保存された契約文書の契約開始日、契約終了日、契約検討日は、カレンダー８０およびカレンダー３０２に表示される。

図８は、文書整理部１０１ｆにより医療機関担当者端末２０のディスプレイ４０に表示された契約文書編集メニュー２６０の画面構成図である。
文書整理ページ２２０のスレッド２３３が有する編集ボタン２３２が選択されると、契約文書編集メニュー２６０を表示する。契約文書編集メニュー２６０は、文書整理ページ２００をバックグラウンドとして、その上にフォアグラウンドとして表示される。

契約文書編集メニュー２６０は、文書の件名を示す文書件名２６１、契約開始日を選択する開始日選択部２６２、契約の終了日を選択する契約終了日選択部２６３、契約更新の検討を開始する日を選択する検討日選択部２６４、契約のカテゴリを選択する契約カテゴリ選択部２６５、契約金額を入力する契約金額入力部２６６、メモを記入するメモ記入部２６７、選択されると契約文書の編集をキャンセルするキャンセルボタン２６８、契約文書の編集を保存する保存ボタン２６９を有している。

契約文書編集メニュー２６０は、少なくとも件名入力部２６１、契約開始日選択部２６２、契約終了日選択部２６３、契約カテゴリ選択部２６５、契約金額入力部２６６が記入され、その後、保存ボタン２６９が選択されると、編集した内容が契約文書テーブル１３０（図３参照）に保存されて契約文書編集メニュー２６０が閉じられる。また、キャンセルボタン２６８が選択された際も契約文書編集メニュー２６０は閉じられる。

契約文書の編集内容が保存されると、文書整理ページ２００の文書一覧部２２０の元のスレッドは更新される。また保存された契約文書の契約開始日、契約終了日、契約検討日は、カレンダー８０およびカレンダー３０２に表示される。

図９は、カテゴリ設定部１０１ｉにより医療機関担当者端末２０のディスプレイ４０に表示される画面の説明図であり、図９（Ａ）はカテゴリ設定ページ２７０の画面構成図であり、図９（Ｂ）はカテゴリ新規作成メニュー２７１の画面構成図である。
カテゴリ設定ページ２７０は、タスクバー６０、契約文書についてのカテゴリを編集する契約文書カテゴリ部２８０、および依頼についてのカテゴリを編集（追加、変更、削除）する依頼カテゴリ部２９０を有している。

カテゴリ設定ページ２７０が表示されているとき、タスクバー６０のカテゴリ設定タブ６５は、タスクバー６０内の他のタブと異なる色で表示される。

契約文書カテゴリ部２８０と依頼カテゴリ部２９０は、それぞれ登録された複数のカテゴリを一覧で表示する。

契約文書カテゴリ部２８０と依頼カテゴリ部２９０は、それぞれ選択されるとカテゴリ新規メニューを開くカテゴリ新規作成ボタン２８１、２９１、カテゴリごとのスレッドであるカテゴリスレッド２８２、２９２、カテゴリ名を示すカテゴリ名表示部２８３、２９３、カテゴリに登録されている件数を示すカテゴリ登録数表示部２８４、２９４、選択されるとカテゴリの編集画面を表示するカテゴリ編集ボタン２８５、２９５、および選択されるとカテゴリスレッド２８２、２９２を削除する削除ボタン２８６、２９６を有する。

カテゴリ新規作成ボタン２８１が選択されると、カテゴリ新規作成メニュー２７１を表示する。カテゴリ新規作成メニュー２７１は、カテゴリ設定ページ２７０をバックグラウンドとしてその上にフォアグラウンドとして表示される（図９ｂ）。

図９（Ｂ）に示すカテゴリ新規作成メニュー２７１は、カテゴリの名称が入力されるカテゴリ名称入力部２７２、検討日が選択されるカテゴリ選択部２７３、選択されるとカテゴリ作成をキャンセルするキャンセルボタン２７４、カテゴリを作成するカテゴリ作成ボタン２７５を有する。カテゴリ名称入力部にカテゴリの名称が入力され、カテゴリ作成ボタン２７５が選択されると、新規カテゴリが作成されて文書カテゴリテーブル１３２（図３参照）に追加登録される。

各カテゴリに設定される検討日は、契約書類に登録された契約終了日に対してどれくらいの期間だけ前に検討を開始するのが良いかを示す検討開始時期が記憶されている。この検討日は、実施例では、契約終了日の６か月前、１年前、１年６か月前、または２年前から選択可能に構成されているが、これに限らず、他の期間も選択できるようにする、あるいは直接入力できるようにするなど、適宜の構成とすることができる。

なお、この実施例では、カテゴリ単位で検討日を設定できる構成としているが、契約文書テーブル１３０（図３参照）に「検討日」の項目を追加し、契約終了日のどれだけ前に更新等の契約の検討を開始するのが良いかを契約文書毎に個別に登録できるようにしてもよい。この場合、契約文書テーブル１３０の「検討日」に期間が登録されていなければその契約文書のカテゴリに設定された検討日を採用し、契約文書テーブル１３０の「検討日」に期間が登録されていれば契約終了日からのその期間前の日を「検討日」として採用すると良い。これにより、カテゴリ毎に検討日が定まっていて入力数を減らせて利便性が高く、かつ、契約文書に応じて検討日を個別に変更できて柔軟性の高いシステムを提供できる。

カテゴリ作成ボタン２７４が選択される、あるいは、キャンセルボタン２７３が選択されたとき、カテゴリ新規作成メニュー２７１は閉じられる。作成された新規カテゴリは、カテゴリ設定ページ２７０に新たなスレッド２８２として、表示される。

カテゴリ編集ボタン２８５が選択されると、カテゴリ編集メニューが表示される（図省略）。カテゴリ編集メニューは、カテゴリの名称編集部および、検討日編集部を有する。

カテゴリ削除ボタン２８６、２９６によるカテゴリの削除は、カテゴリ内に分類されている書類がない場合でないとできない。カテゴリ内に分類されている書類がある場合は、エラーが表示される。

図１０は、スケジュール整理部１０１ｈにより医療機関担当者端末２０のディスプレイ４０に表示される画面の説明図であり、図１０（Ａ）は、カレンダーページ３００の画面構成図であり、図１０（Ｂ）は、スケジュール登録メニュー３１０の画面構成図である。
図１０（Ａ）に示すように、カレンダーページ３００は、タスクバー６０、選択されるとカレンダーにスケジュールの新規登録を促すスケジュール登録ボタン３０１、１か月のカレンダーを表示するカレンダー表示３０２を有する。

カレンダー表示３０２は、選択されると表示しているカレンダーの月を前月あるいは次月にする月送りボタン３０３、“今日”を含む月を表示する今日ボタン３０２、医療機関担当者が個人的に登録したスケジュールである個人スケジュール３０５、医療機関担当者が属する医療機関が取引先企業と交わした契約書のスケジュールである契約書スケジュール３０６（グループスケジュール８２）を有する。
前述した“今日”は、サーバ装置１００と医療機関担当者端末２０が最後に通信した時点での時刻によって定められる。

個人スケジュール３０５、契約書スケジュール３０６は、カレンダーの日付部分に表示される。個人スケジュール３０５は、スケジュールの件名が表示され、契約書スケジュール３０６は、取引先企業の名称が表示される。

個人スケジュールは、スケジュールを開始する開始スケジュールとスケジュールを終了する日を示す終了スケジュールを有し、カレンダーの日付部分に表示される開始スケジュールと終了スケジュールは、それぞれ違う色を有する。スケジュールが日をまたがないときは、開始スケジュールと同じ色で表示される。

契約書スケジュール３０６は、契約が開始される日を表示した契約開始スケジュール３０７と、契約が終了される日を表示した契約終了スケジュール３０８と、契約の検討を開始する日を表示した契約検討スケジュール３０９を有している。
カレンダーの日付部分に表示される契約開始スケジュール３０７と契約終了スケジュール３０８と契約検討スケジュール３０９はそれぞれ異なる色を有する。

スケジュール登録ボタン３０１が選択されると、医療機関担当者はカレンダーに個人のスケジュール（個人スケジュール３０５）の登録を促すスケジュール登録メニュー３１０を表示する（図１０（Ｂ））。

図１９（Ｂ）に示すように、スケジュール登録メニュー３１０は、スケジュールページ３００をバックグラウンドとしてその上にフォアグラウンドとして表示される。

スケジュール登録メニューはスケジュールの開始日時が選択される開始日時選択部３１１、スケジュールの終了日時が選択される終了日時選択部３１２、１日を通してのスケジュールを登録する際に選択される終日ボタン３１３、スケジュールの件名が入力される件名入力部３１４、メモが記入されるメモ記入部３１５、選択されるとカレンダー登録をキャンセルするキャンセルボタン３１６、カレンダー登録をする登録ボタン３１７を有する。

スケジュール登録メニュー３１０は、キャンセルボタン３１６または登録ボタン３１７が選択されたとき、閉じる。スケジュール登録メニュー３１０から登録されたスケジュールは、スケジュールページ３００のカレンダー３０２に表示される。また、新規文書作成メニュー２４０から登録された契約文書の契約開始日、契約終了日、契約検討日は、カレンダー３０２に表示される。それに加え、契約文書編集メニュー２６０によって編集、保存された契約開始日、契約終了日、契約検討日もカレンダー３０２に表示される。

カレンダー３０２に表示されるスケジュールは、トップページ５０のカレンダー８０にも記載される。トップページ５０のカレンダー８０とスケジュールページ３００のカレンダー３０２は、同じものである。しかし、表示されるサイズが異なるために、表示すべきスケジュールの件名や企業名の省略幅が異なるものである。

図１１は、ユーザ設定部１０１ｊにより医療機関担当者端末２０のディスプレイ４０に表示されたユーザ設定ページ３２０の画面構成図である。
ユーザ設定ページ３２０は、タスクバー６０、ユーザ一覧表示部３３０、ユーザ登録部３４０を有している。

ユーザ設定ページ３２０を表示しているとき、タスクバー６０のユーザ設定タブ６６は、タスクバー６０内の他のタブと異なる色で表示されている。

ユーザ一覧表示部３３０は、医療機関担当者の属する医療機関に属する医療機関担当者をスレッド一覧で表示している。ユーザ一覧表示部３３０は、スレッド３３５ごとにユーザ名を表示するユーザ名表示部３３１、ユーザ（医療機関担当者）のメールアドレスを表示するメールアドレス表示部３３２、“権限”を表示する権限表示部３３３を有する。

権限表示部３３３に表示される権限は、取引先企業からの契約書や見積書などを承認する権限を有する“承認者”と、医療機関担当者に付与される権限であって承認する権限を有さない“一般”と、全ての動作を行える“管理者”の３種類が設定されている。

ユーザ登録部３４０は、招待したい同じ医療機関に属する医療機関担当者（新たなユーザ）のメールアドレスが入力されるメールアドレス入力部３４１と、サーバ装置１００にメールアドレス入力部３４１に入力されたメールアドレス情報を送信する送信ボタン３４２を有する。サーバ装置１００は、送信されたメールアドレス情報を受信し、そのメールアドレス宛に医療用取引管理システムＡへのユーザ登録を促すメールを送信する。メールを受け取った医療機関担当者は、指示に従い、ユーザの登録がされると、新たなスレッド３３５としてユーザ一覧表示部３３０に表示される。

図１２は、医療機関担当者がある商品・サービスに関して、複数の企業に対して見積依頼をし、その中から選択した業者と契約するまでの流れを示すフローチャートである。

このフローチャートは、医療機関担当者が使用する医療機関担当者端末２０の制御部２１が、サーバ装置１００にアクセスし、ログイン処理部１０１ａによるログインを行った後、トップページ５０（図５参照）の依頼タブ６３が選択されて依頼処理部１０１ｇが機能してからの処理を示している。

依頼処理部１０１ｇは、図６（Ａ）に示す依頼ページ１８０を表示し、新規依頼ボタン１８１が選択されて図６（Ｂ）の新規依頼作成メニュー１９０で依頼（見積依頼）が行われると（ステップＳ１）、見積依頼のメッセージを企業担当者へ送信し、ステータス１７７を「依頼中」（見積依頼中）に設定する。このとき、複数の企業が指定されていれば、複数の企業へ見積依頼のメッセージを一斉配信する。各企業へ配信されたメッセージは、その企業の企業担当者であれば誰でも確認して返信できるようになっている。

依頼処理部１０１ｇは、企業担当者端末１０からの返信メッセージおよび見積を受け付けると、当該返信メッセージと見積を依頼した医療機関へ送信する（ステップＳ２）。この返信メッセージと見積は、その医療機関の医療機関担当者であれば誰でも確認でき、かつ、誰でも次の処理を進めることができる。

依頼処理部１０１ｇは、追加連絡が必要で（ステップＳ３：要）、追加メッセージが医療機関担当者によって送信された場合（ステップＳ４）、ステップＳ２へ処理を進めて企業担当者による返信メッセージと見積の提出まで待機する。

追加連絡が不要であれば（ステップＳ３：不要）、依頼処理部１０１ｇは、医療機関担当者の操作による見積承認申請の入力を受け付け、承認権限のある承認者に当該見積承認申請のメッセージを送信し、ステータス１７７を「承認待」（見積承認待）に変更する（ステップＳ４）。この見積承認申請は、複数の１つの依頼に対して１つの企業を採用することを条件とする。したがって、１つの依頼に対して２以上の企業の見積りに対して見積承認申請をすることはできず、２つ目の見積承認依頼申請を行った場合、依頼処理部１０１ｇは、どの企業のどの見積を採用予定か決定するようにエラーメッセージを表示するなど、適宜の構成とすることができる。すなわち、１つの依頼の中で２以上の企業のステータスが「承認待」とすることを許容しない。したがって、１つ目の企業の見積承認申請が却下され、「依頼中」のステータスに変更された場合は、２つ目の企業に対して見積承認申請をすることができる。この見積承認申請は、図６（Ａ）のステータス１７７が選択されることによって、また、見積承認申請の際、見積を添付するとともに、医療機関担当者から承認者へのメッセージを入力することができる。このため、承認者はそのメッセージに記載された情報を得て判断することができる。

承認者が医療機関担当者端末２０または管理者端末３０により見積承認申請を却下した場合（ステップＳ７：却下）、ステップＳ１に処理を戻してやり直す。
承認者が承認した場合（ステップＳ７：承認）、依頼処理部１０１ｇは、承認されたことを示すメッセージを医療機関担当者に送信してステータス１７７を「承認済」（見積承認済）に変更する。そして、依頼処理部１０１ｇは、医療機関担当者によってステータス１７７が「完了」（確定）に変更されることを受け付ける（ステップＳ８）。

依頼処理部１０１ｇは、医療機関担当者によって見積確定した企業への契約文書の依頼を受け付け、ステータス１７７を「依頼中」（契約文書依頼中）に変更する（ステップＳ９）。なお、ステップＳ８とステップＳ９を１つにまとめ、医療機関担当者がステータス１７７を「完了」に変更すると、契約文書の依頼を受け付けてステータス１７７を「依頼中」に変更する構成にしてもよい。
依頼処理部１０１ｇは、企業担当者による返信メッセージの入力と契約文書の提出を受け付けると（ステップＳ１０）、そのまま医療機関担当者へ送信する。

追加連絡が要であれば（ステップＳ１１：要）、依頼処理部１０１ｇは、追加メッセージの送信を受け付け（ステップＳ１２）、ステップＳ１０へ処理を戻して相手方の返信メッセージ等の到着を待機する。

追加連絡が不要であれば（ステップＳ１０：不要）、依頼処理部１０１ｇは、医療機関担当者による契約承認申請の入力を受け付ける（ステップＳ１３）。この契約承認申請の入力は、図６（Ａ）のステータス１７７が選択されることによって、ステータスを「承認待」（契約文書承認待）に変更して実行する等、適宜の方法で実行することができる。

依頼処理部１０１ｇは、承認者による契約承認の入力を受け付け（ステップＳ１４）、当該契約承認の入力結果が「却下」であった場合は（ステップＳ１５；却下）、ステップＳ９に処理を戻してやり直す。
契約承認の入力結果が「承認」であった場合（ステップＳ１５；承認）、依頼処理部１０１ｇは、医療機関担当者へ承認完了等を示す通知を行い、ステータス１７７を「承認済」（契約文書承認済）に変更する。

依頼処理部１０１ｇは、医療機関担当者による「契約確定」の入力を受け付け（ステップＳ１６）、ステータス１７７を「完了」（契約成立）に変更して処理を終了する。この契約確定では、新規文書整理メニュー２４０（図７（Ｂ）参照）で契約文書のカテゴリの設定、契約日および契約満了日の入力など、医療機関担当者による必要情報の入力を受け付け、入力されたデータを契約文書テーブル１３０（図３参照）に記憶する。

以上の構成および動作により、医療用取引管理システムＡは、医療機関における各種管理を容易にし、利用者の利便性を向上させることができる。

また、見積と契約文書の少なくとも一方について承認申請を行う構成であるため、必ず承認を受けて契約を成立させることができ、医療機関が企業との取引を問題なく着実に実施することができる。

また、承認対象となる書類とメッセージを、承認権限を有する者へ送信する構成であるため、承認者は、承認対象である見積書または／および契約文書を全部着実確認することができる。

また、見積承認申請と契約文書承認申請の両方を行う構成であるため、要所で確実に承認して契約までの一連の手続きを滞りなくスムーズに運ぶことができる。すなわち、承認の回数が多すぎると業務効率が悪くなり、逆に承認回数が少なすぎると承認者が気づいた時点では大幅に手遅れということが生じるが、このようなことなく１つずつのステップを確実に実行して結果として正確で速い処理を実現できる。

また、スレッドが企業単位で見ることができる構成であるため、複数の企業の情報が混在してどの企業のことであったかが混乱するといったことが生じ難く、適切に処理していくことができる。

また、ステータス１７７は、変化する順番が定まっているため、予定外の事態が生じることを防止でき、承認ルートを確実に通過させて契約締結するといったことができる。

また、トップページ５０は、カレンダー８０、および通知部９０を有するため、医療機関担当者は、企業担当者から受信した情報と、カレンダー情報を１画面で確認して便利に利用することができる。すなわち、カレンダー８０では、スケジュールに応じてしなければならない業務を確認でき、通知部９０では、企業担当者から受信して処理しなければならない情報を確認できるため、処理しなければならない業務と期限のある業務とを同時に確認して適切に振り分けて進めることができる。しかもトップページ５０として最初の画面（メインの画面）に表示されるため、確認漏れも防止でき、確実に業務を進めることができる。

また、カレンダー８０にグループスケジュール８２として契約満了日が表示されるため、医療機関担当者は、契約満了日が迫っている契約について契約満了前に契約の更新や再契約、あるいは取引先の変更といったことを実施することができる。したがって、契約満了日が過ぎているにもかかわらず気づかないでそのままにするといったことを防止できる。

また、医療機関担当者個人の個人スケジュール８１と、その医療機関に所属する医療機関担当者全員に表示されるグループスケジュール８２を、１つのカレンダー８０にまとめて表示するため、医療機関担当者は自分のスケジュールを確認しつつ自身の所属する医療機関全体で進めなければならない業務を各自分担して進めて行くことができる。

また、通知部９０は、メッセージ通知部９１および契約文書通知部９２を有しており、企業担当者からの見積等のメッセージと、契約することが決まり企業担当者から送信されてきた契約文書とを両方確認できるため、それぞれ適切に処理することができる。しかも、契約前で雑多な情報も含まれやすい見積等のメッセージと、契約が決まって重要である契約文書等が、メッセージ通知部９１と契約文書通知部９２に分かれて表示されるため、重要度に応じた処理を適切に実行することが容易に実現される。特に、重要な契約文書が雑多なメッセージに埋もれるということが生じないため、操作に不慣れな医療機関担当者であっても漏れのない適切な処理を確実に実施できる。

また、カレンダー８０には、契約満了日の前に検討日が表示されるため、契約に時間のかかるようなものであっても検討開始すべき時期を的確に把握でき、スムーズに契約の更新や再契約等を進めることができる。しかも、文書のカテゴリによって検討日がデフォルトで決定される構成であるため、適切な検討日を容易に設定することができるとともに、検討日の設定漏れを防止することができる。さらに、契約文書に個別に検討日を登録することもできるため、様々な契約に対して柔軟に対応することができる。

また、医療機関担当者は、１つの依頼（見積依頼）を１つの単位として、複数企業に対して見積依頼のメッセージを一斉にまたは個別に送信でき、その後は企業単位でメッセージの送受信を実施できて、企業毎に企業別ステータス１８３を付与できる。このため、金額やスペック等で折り合わない企業については企業別ステータス１８３を「完了」等に順次設定していき、最終的に残った企業を「採用候補」として、図示省略する「院内承認」あるいは「完了」に設定するボタンを押してその企業の見積の承認を得て契約を進めるといったことができる。また、途中で見積の承認が拒否された場合に、ステータス１７７が「依頼中」に戻るため、次に条件の良かった別の企業の企業別ステータス１８３を「採用候補」として見積承認申請をし、承認が得られれば契約を進めるといったこともできる。したがって、多数の企業の中から最適な企業と契約する作業を効率よく進めることができる。

この発明は、上述の実施形態の構成のみに限定されるものではなく、多くの実施の形態を得ることができる。

この発明は、医療機関と企業の間で商品およびサービスの取引を行うに際して利用することができる。

Ａ…医療用取引管理システム
２０…医療機関担当者端末
１００…サーバ装置
１０１ｂ…ダッシュボード表示部
１０１ｃ…カレンダー表示部
１０１ｄ…受信メッセージ表示部
１０１ｅ…受信契約書表示部
１０１ｆ…文書整理部
１０１ｇ…依頼処理部
１０１ｈ…スケジュール整理部
１０１ｉ…カテゴリ設定部
１１３…依頼関連データ
１１４…スケジュール関連データ

この発明は、医療用の取引に利用するような医療用取引管理システム、医療用取引管理方法、および医療用取引管理プログラムに関する。

近年、医療機関において、スケジュールの管理や取引先との契約書などの書類の管理は、大きな負担となっている。スケジュールを管理するものとして、例えば、在庫管理および通知システムが提案されている（特許文献１参照）。このシステムは、関係情報、現在残量、および使用量の履歴に基づいて消耗品の注文スケュールを推奨するように構成されている。

しかし、医療機関において管理しなければならないことは様々であり、より便利なソフトウェアが望まれていた。

特開２０１２−２４３３２４号公報

この発明は、上述の問題に鑑みて、医療機関における各種管理を容易にする医療用取引管理システム、医療用取引管理方法、および医療用取引管理プログラムを提供し、利用者の利便性を向上させることを目的とする。

この発明は、医療に関するサービスを行う医療機関で業務する医療機関担当者が使用する複数の医療機関担当者端末と、前記医療機関に物または／およびサービスを提供する取引先企業の企業担当者が使用する複数の企業担当者端末と、前記医療機関担当者端末および前記企業担当者端末と通信回線を介して接続されたサーバ装置とを備え、前記医療機関担当者端末と前記企業担当者端末と前記サーバ装置の少なくとも１つに各種データを記憶する記憶手段を備え、前記記憶手段は、前記医療機関担当者に関する医療機関担当者データと、前記企業担当者に関する企業担当者データとを記憶し、前記医療機関担当者データは、少なくとも承認者としての権限を有するのか否かを認識可能に構成されており、前記医療機関担当者が前記企業担当者に見積の依頼を行う依頼処理部と、前記依頼処理部により得られた見積についての契約文書を前記企業担当者に求める契約文書処理部と、前記見積と前記契約文書の少なくとも一方について可否の承認を行う承認処理部とを備え、前記依頼処理部は、１つの依頼について複数の企業へ依頼メッセージを送信できる構成であり、前記依頼ごとに依頼のスレッドとして表示される依頼一覧表示部を備え、前記依頼一覧表示部は、前記依頼のスレッドごとに、前記企業担当者から見積を受信すると企業単位でメッセージの送受信を行って企業スレッドと時系列で表示し、前記依頼のスレッドに依頼のステータスを表示する構成とし、この依頼のステータスは、前記企業担当者へ見積を依頼して選定している依頼中の状態であることを示す第１のステータスと、前記医療機関担当者が１つの見積を選択して前記承認者としての権限を有する者へ承認申請を行っている状態であることを示す第２ステータスと、前記承認申請が承認された承認済であることを示す第３ステータスとに変更される構成であり、前記企業スレッドに、採用候補であることを示すステータスと院内承認であることを示すステータスとに変更される企業別ステータスを表示する医療用取引管理システム、医療用取引管理方法、および医療用取引管理プログラムであることを特徴とする。

この発明により、医療機関における各種管理を容易にすることができる。

医療用取引管理システムのシステム構成を示すブロック図。 サーバ装置の構成を示すブロック図。 サーバ装置のデータ構成を示すデータ構成説明図。 医療機関担当者端末に表示したログイン画面の画面構成図。 医療機関担当者端末に表示したトップページ画面の画面構成図。 医療機関担当者端末に表示した依頼ページ画面の画面構成図。 医療機関担当者端末に表示した文書整理ページ画面の画面構成図。 医療機関担当者端末に表示した契約文書更新ページ画面の画面構成図。 医療機関担当者端末に表示したカテゴリ設定ページ画面の画面構成図。 医療機関担当者端末に表示されたスケジュール管理ページ画面の画面構成図。 医療機関担当者端末に表示されたユーザ設定ページ画面の画面構成図。 医療用取引管理システムの動作を示すフローチャート。

以下、本発明の一実施形態を図面と共に説明する。
図１は、医療用取引管理システムの全体構成を示すブロック図である。
医療用取引管理システムＡは、病院や介護施設、クリニックなど医療に関するサービスを行う医療機関で業務する医師や医療事務などの医療機関担当者が使用する複数の医療機関担当者端末２０、医療機関に物やサービスを提供する医療機関の取引先である企業（業者）に属する企業担当者が使用する複数の企業担当者端末１０、システムを管理する管理者が使用する管理者端末９０およびサーバ装置１００を有している。サーバ装置１００は、インターネットを介して企業担当者端末１０、医療機関担当者端末２０、管理者端末３０と接続されている。

企業担当者端末１０、医療機関担当者端末２０、および管理者端末３０は、通信部１４、２４、３４、制御部１１、２１、３１、入力部１２、２２、３２、および表示部１３、２３、３３を有するパーソナルコンピュータやタブレット端末、スマートフォンなどの通信可能なコンピュータで構成されている。サーバ装置１００は、制御部１０１、入力部１０２、表示部１０３、通信部１０４、および記憶部１０５を有するサーバコンピュータにより構成されている。

制御部１１、２１、３１、１０１は、各種演算や制御動作を実行する。表示部１３、２３、３３、１０３は、液晶ディスプレイまたは有機ＥＬディスプレイ等の適宜の表示装置により構成されている。また、入力部１２、２２、３２、１０２は、キーボードやマウスまたは、表示部１３、２３、３３、１０３に重ねて設けられたタッチパネル等の適宜の入力装置によって構成されている。

通信部１４、２４、３４、１０４は、ＬＡＮボードまたはＷｉＦｉ通信ユニット等の有線または無線の通信機器で構成されて有線または無線での通信を実行し、インターネット１へ接続する。入力部１２、２２、３２、１０２は、企業担当者、医療機関担当者、および管理者によって行われる操作を受け付ける。入力部１２、２２、３２、１０２を操作した際の操作データは、通信部１４、２４、３４、１０４によってサーバ装置１００へ送信される。

記憶部１５、２５、３５、１０５は、ハードディスクまたは不揮発性メモリ等の記憶手段により構成されており、各種データを記憶している。また、記憶部１５は、企業担当者用プログラム１５ａを記憶しており、記憶部２５は、医療機関担当者用プログラム２５ａを記憶しており、記憶部３５は、管理者用プログラム３５ａを記憶しており、記憶部１０５は、サーバ用プログラム１０５ａを記憶している。これらのプログラムは、各制御部１１、２５、３５、１０１によって実行される。

図２は、サーバ装置１００の制御部１０１がサーバ用プログラム１０５ａによって実行する動作の機能ブロック図である。
サーバ装置１００の制御部１０１は、ログイン処理部１０１ａ、ダッシュボード表示部１０１ｂ、文書整理部１０１ｆ、依頼処理部１０１ｇ、スケジュール整理部１０１ｈ、カテゴリ設定部１０１ｉ、およびユーザ設定部１０１ｊとして機能する。ダッシュボード表示部１０１ｂは、カレンダー表示部１０１ｃ、受信メッセージ表示部１０１ｄ、および受信契約書表示部１０１ｅを有している。これらの各機能部の説明は、これらの機能部が表示する画面と共に後述する。

なお、これらの各機能部は、企業担当者端末１０、医療機関担当者端末２０、および管理者端末３０からの各プログラム（１５ａ、２５ａ、３５ａ）による各アクセスに対して、各端末（１０、２０、３０）にてローカルで操作しているかのように各機能を提供するが、各機能部をサーバ装置１００ではなく各端末（１０、２０、３０）に備えるなど、適宜の構成とすることができる。

サーバ装置１００の記憶部１０５は、企業担当者、医療機関担当者または管理者であって、それぞれ端末を操作し、システムを利用するユーザの情報であるユーザ関連データ１１１、企業担当者と医療機関担当者間の契約書など書類の情報である書類関連データ１１２、医療機関担当者が企業担当者（または企業）に依頼を行った際のメッセージなど依頼の情報である依頼関連データ１１３、ユーザのスケジュール情報であるスケジュール関連データ１１４、および社内メモ関連データ１１５を有している。

図３は、サーバ装置１００の記憶部１０５に記憶されているデータベースのデータ構成図である。
図３（ａ）は、ユーザ関連データ１１１のデータ構成を示す。図３（ｂ）は、書類関連データ１１２のデータ構成を示す。図３（ｃ）は、依頼関連データ１１３のデータ構成を示す。図３（ｄ）は、スケジュール関連データ１１４のデータ構成を示す。

ユーザ関連データ１１１は、医療機関テーブル１２０、企業テーブル１２１、医療機関担当者テーブル１２２、企業担当者テーブル１２３、管理者テーブル１２４、医療機関と企業の中間テーブル１２５を有している。

医療機関テーブル１２０は、医療機関名、医療機関ごとに付与されたＩＤなどを有する。企業テーブル１２１は、企業名、企業ごとに付与されたＩＤなどを有する。

医療機関担当者テーブル１２２は、医療機関担当者ごとに付与されたＩＤ、医療機関担当者の氏名、医療機関担当者の所属する医療機関の医療機関外部キー、役職、メールアドレス、および権限などを有する。権限には、医療機関担当者として企業担当者とメッセージ送受信等の実務を行う「一般」と、医療機関担当者からの見積承認申請や契約文書承認申請に対して承認を行う「承認者」と、全ての操作を行える「管理者」のいずれかが記憶される。企業担当者テーブル１２３は、企業担当者ごとに付与されたＩＤ、企業担当者の氏名、企業担当者の所属する企業の企業外部キー、役職、メールアドレス、および権限などを有する。管理者テーブル１２４は、管理者ごとに付与されたＩＤ、氏名および、メールアドレスなどを有している。

書類関連データ１１２は、契約文書テーブル１３０、その他の文書テーブル１３１、文書カテゴリテーブル１３２、文書の添付ファイルテーブル１３３を有している。

契約文書テーブル１３０は、契約を交わす医療機関と企業の医療機関外部キー、企業外部キー、文書カテゴリ外部キー、契約開始日、契約終了日、タイトル、および内容などを有している。その他文書テーブル１３１は、文書を送受信した医療機関と企業の医療機関外部キー、企業外部キー、文書カテゴリ外部キー、添付ファイル外部キーおよびタイトルなどを有する。

文書カテゴリテーブル１３２は、カテゴリ名および、検討日などを有している。文書の添付ファイルテーブル１３３は、契約文書外部キー、オリジナルファイル名および、保存ファイル名などを有している。

依頼関連データ１１３は、依頼テーブル１４０、依頼カテゴリテーブル１４１、依頼スレッドテーブル１４２、スレッド内メッセージテーブル１４３、メッセージ既読テーブル１４４、メッセージ添付ファイルテーブル１４５を有している。

依頼テーブル１４０は、依頼タイトル、依頼をする医療機関外部キー、依頼のカテゴリ外部キーなどを有している。依頼カテゴリテーブル１４１は、カテゴリ名、医療機関外部キーなどを有している。依頼スレッドテーブル１４２は、依頼外部キー、企業外部キー、ステータスなどを有している。

スレッド内メッセージテーブル１４３は、スレッド外部キー、添付ファイル外部キー、送信者名、本文などを有している。既読テーブル１４４は、既読者外部キー、スレッド外部キーなどを有している。メッセージ添付ファイルテーブル１４５は、メッセージ外部キー、オリジナルファイル名、保存ファイル名などを有している。

これらの依頼関連データ１１３（テーブル１４０〜１４５）により、１つの依頼について複数の企業に打診し、各企業の担当者とやり取りするデータを適切に保存できる。すなわち、依頼テーブル１４０の１つの依頼には、企業別に依頼スレッドが作成されて依頼スレッドテーブル１４２に記憶され、かつ、その企業の依頼スレッド内で医療機関担当者からのメッセージと企業担当者からのメッセージがスレッド内メッセージ１４３に記憶される。このスレッド内メッセージテーブル１４３の送信者外部キーは、メッセージを送信した医療機関担当者のＩＤ（医療機関担当者テーブル１２２参照）または企業担当者のＩＤ（企業担当者テーブル１２３参照）が記憶されている。

このようなデータ構造であるから、医療機関担当者は、一覧表示される依頼の１つを選択すると、その依頼についてメッセージの送信または／および受信をしている企業が一覧表示され、さらにそのうちの１つの企業を選択すると、その企業との間で医療機関担当者が送信したメッセージと企業担当者が送信したメッセージがスレッド式にて時系列で一覧表示されるといった形でメッセージを確認できる。スレッド式の表示は、例えば左右のうち一方に医療機関担当者が送信したメッセージを表示し、他方に企業担当者が表示したメッセージを表示するという形で実施できる。

また、スレッド内メッセージテーブル１４３の送信者モデルタイプには、送信者が医療機関担当者であるか企業担当者であるかを示す識別子が記憶されており、この送信者モデルタイプ（医療機関担当者か企業担当者かを示す）と送信者外部キー（どの医療機関担当者または企業担当者かを示す）によって送信者を特定できるように構成されている。

スケジュール関連データ１１４は、スケジュールテーブル１５０を有している。スケジュールテーブル１５０は、医療機関外部キー、ユーザ外部キー、開始日、終了日、タイトルなどを有している。

社内メモ関連データ１１５は、社内メモテーブル１５１を有している。社内メモテーブル１５１は、ユーザ外部キー、メモ対象外部キーなどを有している。

これらの各テーブル１２０〜１５１は、そのテーブルの固有の識別情報としてＩＤを有しており、他のテーブルの情報と連結するための外部キーを必要に応じて有している。外部キーは、その名称と同じ名称のテーブルのＩＤが記憶されている。例えば企業担当者テーブル１２３であれば、「医療機関外部キー」には医療機関テーブル１２０のＩＤと一致するＩＤが記憶されており、「企業外部キー」には企業テーブル１２１のＩＤと一致するＩＤが記憶されている。このようにＩＤと外部キーによって各テーブル（データ）が連結されている。

図４〜図１１は、医療機関担当者端末２０のディスプレイ４０に表示する各種画面の説明図である。いずれの画面も、サーバ装置１００の記憶部１０５に記憶されている各種データ（図３参照）を読み出して、そのデータが表示されているものである。

図４は、ログイン処理部１０１ａによって医療機関担当者端末２０のディスプレイ４０に表示されたログインページ４１の画面構成図である。
ログインページ４１は、メールアドレスの入力を受け付けるメールアドレス入力部４２と、パスワードの入力を受け付けるパスワード入力部４３と、ログインの実行を受け付けるログインボタン４４とを備えている。

登録されたメールアドレスと設定されたパスコードを用いることで、サーバ装置１００は、医療機関担当者テーブル１２２（図３参照）または管理者ユーザテーブル１２４に登録済みで医療機関担当者端末２０を用いる医療機関担当者、または企業担当者テーブル１２３（図３参照）に登録済みで企業担当者端末１０を用いる企業担当者がログインすることを許容する。

ログインボタン４４が選択されると、サーバ装置１００は、ログイン処理部１０１ａによりメールアドレスとパスワードの照合を行い、メールアドレスおよびパスワードが正しければ、医療機関担当者端末２０のログインを許容し、ユーザデータに基づいたトップページデータ（ダッシュボードデータ）を医療機関担当者端末２０に送信する。医療機関担当者端末２０は、トップページデータを受信し、表示部２３によって表示する。

図５は、ダッシュボード表示部１０１ｂによって医療機関担当者端末２０のディスプレイ４０に表示されたトップページ５０（ダッシュボード）の画面構成図である。
トップページ５０は、タスクバー６０、コマンド部７０、カレンダー８０、および通知部９０を有している。タスクバー６０は、画面左側に、コマンド部７０は、タスクバー６０の右側上部（中央上部）に、カレンダー８０は、タスクバー右側下部（中央下部）に、通知部９０は、画面右側に表示されている。

タスクバー６０は、選択されるとトップページ（ダッシュボード）画面を表示するダッシュボードタブ６１、文書整理ページを表示する文書を整理する文書整理タブ６２、依頼ページを表示する依頼をする依頼タブ６３、スケジュールページを表示するスケジュール管理タブ６４、カテゴリ設定ページを表示するカテゴリ設定タブ６５、ユーザ設定ページを表示するユーザ設定タブ６６を有している。

トップページ画面５０が表示されているとき、タスクバー６０のダッシュボードタブ６１は、タスクバー６０内の他のタブと異なる色で表示される。

コマンド部７０は、選択されると、文書整理ページを表示する文書を整理する文書整理ボタン７２、依頼ページを表示する依頼をする依頼ボタン７３、スケジュールページを表示するためのスケジュール管理ボタン７４、カテゴリ設定ページを表示するためのカテゴリ設定ボタン７５、ユーザ設定ページを表示するユーザ設定ボタン７６を有している。

カレンダー８０は、カレンダー表示部１０１ｃによって、医療機関担当者個人が入力した個人スケジュール８１と、医療機関担当者が所属する医療機関のグループスケジュール８２を併せて表示している。

個人スケジュール８１は、カレンダー８０に表示される複数の日付部分のうち、スケジュールテーブル１５０（図３参照）に記憶されている終了日（若しくは開始日）と同一の日付部分に、当該スケジュールのタイトルが表示されたものである。この個人スケジュール８１は、医療機関担当者の個別のスケジュールであるため、他の医療機関担当者がログインしている場合には表示されないものである。

グループスケジュール８２は、カレンダー８０に表示される複数の日付部分のうち、契約文書テーブル１３０（図３参照）に記憶されている契約終了日と同一の日付部分に、当該契約文書の契約タイトルが表示される。このグループスケジュール８２は、１つの医療機関において全医療機関担当者に共通するスケジュール８２であるため、当該医療機関に所属する他の医療機関担当者がログインした場合であってもカレンダー８０に表示される。また、グループスケジュール８２としては、契約文書の更新等の検討を開始すべき検討日も表示される。

なお、カレンダー８０における１つの日付部分に複数のスケジュール（８１，８２）を表示する必要がある場合には、１つのスケジュール（８１．８２）のタイトルを表示し、表示できていないスケジュール（８１，８２）の件数と、これらの表示できていないスケジュール（８１，８２）を確認するための表示ボタン（図示の例では「もっとみる」と記載）を表示する。
本例では、２０１９年１１月のカレンダーを表示し、１３日、１５日、２２日、２７日、３０日に予定（スケジュール）が入っていることを表示している。

通知部９０は、メッセージ通知部９１および契約文書通知部９２を有している。メッセージ通知部９１は、画面右上部に、契約文書通知部９２は、画面右下部（メッセージ通知部の下部）に位置している。

メッセージ通知部９１は、受信メッセージ表示部１０１ｄによって、依頼テーブル１４０のステータスが「見積中」である依頼で、かつ、企業担当者からメッセージを受信している状態の依頼を一覧表示する。各依頼については、「依頼タイトル」およびそのメッセージを送信した企業の「企業名」（取引業者）と未読メッセージの「件数」を表示する。

契約文書通知部９２は、受信契約書表示部１０１ｅによって、契約文書テーブル１３０のステータスが「契約手続中」で企業担当者から送信された契約文書を一覧表示する。各契約文書については、「件名」およびその契約文書を送信した企業の「企業名」（取引業者）を表示する。

本例では、メッセージ通知部９１は、１件の未読のメッセージがあることを表示している。契約文書通知部９２は、取引業者（企業）から１件の契約書がアップロードされたことを表示している。

メッセージ通知部９１および契約文書通知部９２に表示される通知は、医療機関担当者がその通知されたメッセージや契約文書を確認（既読）したとき、通知部９０から削除される。通知部９０は、メッセージ通知部９１と契約文書通知部９２の両方の通知するものがなくなった場合、“現在、タスクはありません。”という表記を表示する。

図６は、依頼処理部１０１ｇによって医療機関担当者端末２０のディスプレイ４０に表示された画面の説明図であり、図６（Ａ）は、既に行った又は進行中の依頼を表示する依頼ページ１８０の画面構成図であり、図６（Ｂ）は、依頼を新規作成する新規依頼作成メニュー１９０の画面構成図である。

依頼ページ１８０は、タスクバー６０、依頼を新規作成する新規依頼ボタン１８１、依頼の検索、絞り込みを行う検索部１６０、依頼一覧を表示する依頼一覧表示部１７０を有している。

依頼ページ１８０が表示されているとき、タスクバー６０における依頼をするタブ６２は、タスクバー６０内の他のタブと異なる色で表示される。

検索部１６０は、依頼が終了しているか、継続中かを選択する終了チェック選択部１６１、依頼先である取引業者（企業）を選択する取引業者選択部１６２、依頼のカテゴリを選択するカテゴリ選択部１６３、依頼の状態を選択する状態選択部１６４、依頼を行った日を入力する依頼日入力部１６５、依頼の件名入力部１６６、および検索を実行する検索ボタン１６７を有している。

検索部１６０は、検索条件である終了チェック選択部１６１、取引業者選択部１６２、取引業者選択部１６３、カテゴリ選択部１６３、状態選択部１６４、日付入力部１６５、件名入力部１６６のいずれか１つまたは複数を用いた検索を可能とする。

医療機関担当者端末２０の制御部２５は、検索条件が入力されたのち、検索ボタン１６７が選択されると、検索条件に該当する依頼をサーバ装置１００から受信して依頼一覧表示部１７０に表示する。

依頼一覧表示部１７０は、選択されると依頼中である依頼のスレッドを表示する依頼中スレッド選択部１７１、完了した依頼のスレッドを表示する完了スレッド選択部１７２を有する。依頼一覧表示部１７０は、選択された依頼中スレッド選択部１７１あるいは、完了スレッド選択部１７２のいずれかに対応した依頼を表示する。

依頼は、依頼ごとにスレッド１７３として表示される。依頼一覧表示部１７０に表示された複数のスレッド１７３は、それぞれの依頼をした日を示す依頼日１７４、取引業者（企業）を示す依頼先１７５、依頼のカテゴリを示す依頼カテゴリ１７６、依頼の状態を示すステータス１７７、依頼の件名を示す依頼件名１７８が表示され、依頼の本文を表示するためのアイコン１７９が備えられている。

依頼のスレッド１７３が選択されると、スレッド１７３内の依頼先（企業）ごとのスレッドである企業スレッド１８２が表示される。企業スレッド１８２は、依頼の状態を企業ごとに表示する企業別ステータス１８３、選択されると依頼の詳細を表示する企業別依頼詳細ボタン１８４を有している。企業別依頼詳細ボタン１８４が選択されると、依頼内容やこれまでに行われた企業とのメッセージのやりとりなどを表示する。

医療機関担当者端末２０は、依頼ページ１８０が備えた新規依頼ボタン１８１が選択されると、依頼を新規作成する新規依頼作成メニュー１９０（図６（Ｂ））を表示する。新規依頼作成メニュー１９０は、依頼ページ１８０をバックグラウンドとして、その上にフォアグラウンドとして表示される。

図６（Ｂ）に示す新規依頼作成メニュー１９０は、取引先（依頼先企業）が単数、あるいは複数選択される新規取引先選択部１８８、依頼カテゴリが選択される新規依頼カテゴリ選択部１８９、件名が入力される新規件名入力部１９１、本文が入力される新規本文入力部１９２、添付ファイルを表示する添付ファイル表示部１９３、選択されると添付ファイル選択を促す画面を表示する添付ファイル追加ボタン１８５、選択されると新規依頼作成をキャンセルするキャンセルボタン１８６、依頼の新規作成情報を送信する新規依頼送信ボタン１８７を有する。

新規取引先選択部１８８、新規依頼カテゴリ選択部１８９、新規件名入力部１９１、新規本文入力部１９２のそれぞれが入力され、新規依頼を送信する新規依頼送信ボタン１８７が選択されると、作成された依頼が新規取引先選択部１８８で選択された企業へ送信される。そうして、新規依頼作成メニュー１９０は閉じられ、作成した新規依頼が依頼一覧表示部１７０に表示される。この新依頼作成メニュー１９０は、新規依頼送信ボタン１８７が選択された場合や新規依頼作成をキャンセルするキャンセルボタン１８６が選択された場合に閉じられる。

新規依頼が保存されると、依頼ページ１８０の新たなスレッド１７３として、表示される。

依頼は、医療機関担当者からの採用検討のための依頼であって、企業へカタログを請求する、見積もり書を依頼する、契約書を依頼するなどの依頼である。これらの採用検討のための依頼を医療機関担当者が行うとき、医療機関担当者端末２０は、医療機関担当者により操作され、依頼をするページから新規依頼ボタン１８１が選択され、新規依頼作成メニュー１９０の各項目が入力され、新規依頼送信ボタン１８７が押下されることで行われる。

また、新規依頼作成メニュー１９０の、新規取引先選択部１８８は、複数の取引先の選択を許容する。新規依頼の作成がなされると、サーバ装置１００は、一覧表示部１７において、１つの依頼につき１つのスレッド１７３を作成する。複数の取引先を選択された場合も、１つの依頼につき１つのスレッド１７３を作成し、スレッド１７３が選択されると、依頼をした企業の数だけ企業スレッド１８２を表示する。

図７は、文書整理部１０１ｆによって医療機関担当者端末２０のディスプレイ４０に表示される画面の説明図であり、図７（Ａ）は、文書を整理する文書整理ページ２００の画面構成図であり、図７（Ｂ）は、新規文書を整理する新規文書整理メニュー２４０の画面構成図である。

図７（Ａ）に示す文書整理ページ２００は、タスクバー６０、選択されると新規文書の整理を促す新規文書整理メニュー２４０を表示する新規文書整理ボタン２１７、文書を検索する検索部２１０、および文書を一覧表示する文書一覧表示部２２０を有している。

文書整理ページ２００を表示しているとき、タスクバー６０の文書を整理するタブ６４は、タスクバー６０内の他のタブと異なる色で表示される。

検索部２１０は、文書を検索する際の検索条件として、取引先業者（企業）が選択される取引業者選択部２１１、文書のカテゴリが選択される文書カテゴリ選択部２１２、書類の契約満了日が入力される契約満了日入力部２１３、件名やファイル名などキーワードが入力されるキーワード入力部２１４、を有し、検索を実行する検索ボタン２１５を有する。

医療機関担当者端末２０により、検索条件が入力されたのち、検索ボタン１６７が選択されると検索条件にあった文書を文書一覧表示部２２０に表示する。

文書一覧表示部２２０は、選択されると整理済みの契約書のみを表示する整理済み書類選択ボタン２２１、未整理の契約書のみを表示する未整理書類選択ボタン２２２、その他の書類を表示するその他書類選択ボタン２３３を有している。

文書一覧表示部２２０は、整理済み書類選択ボタン２２１、未整理書類選択ボタン２２２、あるいはその他書類選択ボタン２２３のいずれかが選択され、選択された条件に対応する書類の一覧を表示する。また、検索部２１０に検索条件が入力され、検索ボタン２１５が選択されたたときは、さらに検索条件に一致した書類を表示する。

文書一覧表示部２２０は、企業より受け取った１つの文書（若しくはひとまとまりの文書）を１つのスレッド２３３として複数並べて一覧表示する。各スレッド２３３は、それぞれの文書の作成日、または受け取り日である文書作成日２２４、文書の作成者あるいは文書の送付元である作成者（企業担当者）２２５、書類の取引を行った取引業者（企業）２２６、文書のカテゴリ２２７、契約書の契約満了日２２８ａ（または文書の有効期限を示す終了日２２８ａ）、および契約の金額２２８ｂ、文書の件名２２９を有している。

文書一覧表示部２２０は、さらに、選択されると文書とともに送受信されたメッセージの本文を表示するアイコン２３０、保存ファイルを表示する保存ファイルボタン２３１、および編集を行う編集ボタン２３２が備えられている。

医療機関担当者端末２０は、医療機関担当者により新規文書整理ボタン２１７が選択されると、整理する書類が契約書であるか、その他の書類であるかを選択する画面を表示する。医療機関担当者により、書類が契約書であることの選択がされると、文書を新規作成する新規文書整理メニュー２４０を表示する。新規文書整理メニュー２４０は、文書整理ページ２００をバックグラウンドとして、その上にフォアグラウンドとして表示される。

図７（Ｂ）に示す新規文書整理メニュー２４０は、契約をする取引業者（企業）を選択する取引業者選択部２４１、契約書の件名を入力する件名入力部２４２、契約の開始日を選択する契約開始日選択部２４３、契約の終了日を選択する契約終了日選択部２４４、契約更新の検討を開始する日を選択する検討日選択部２４５、契約のカテゴリを選択する契約カテゴリ選択部２４６、契約金額を入力する契約金額入力部２４７、メモを記入するメモ記入部２４８、選択されると添付ファイルの選択を促す画面を表示する添付ファイル選択部２４９、添付ファイル選択部２４９により選択された添付ファイルを表示する添付ファイル表示部２５２、選択されると新規文書整理をキャンセルするキャンセルボタン２５１、新規文書整理を登録する保存ボタン２５０を有している。

新規文書整理メニュー２４０は、少なくとも取引業者選択部２４１、件名入力部２４２、契約開始日選択部２４３、契約終了日選択部２４４、契約カテゴリ選択部２４５、契約金額入力部２４７が記入され、その後、保存ボタン２５０が選択されると、作成された新規文書を契約文書テーブル１３０（図３参照）に追加保存して新規文書整理メニュー２４０を閉じる。また、キャンセルボタン２５１が選択された際も、新規文書整理メニュー２４０は閉じられる。

新規文書が保存されると、この新規文書は、文書整理ページ２００の新たなスレッド２３３として表示される。また保存された契約文書の契約開始日、契約終了日、契約検討日は、カレンダー８０およびカレンダー３０２に表示される。

図８は、文書整理部１０１ｆにより医療機関担当者端末２０のディスプレイ４０に表示された契約文書編集メニュー２６０の画面構成図である。
文書整理ページ２２０のスレッド２３３が有する編集ボタン２３２が選択されると、契約文書編集メニュー２６０を表示する。契約文書編集メニュー２６０は、文書整理ページ２００をバックグラウンドとして、その上にフォアグラウンドとして表示される。

契約文書編集メニュー２６０は、文書の件名を示す文書件名２６１、契約開始日を選択する開始日選択部２６２、契約の終了日を選択する契約終了日選択部２６３、契約更新の検討を開始する日を選択する検討日選択部２６４、契約のカテゴリを選択する契約カテゴリ選択部２６５、契約金額を入力する契約金額入力部２６６、メモを記入するメモ記入部２６７、選択されると契約文書の編集をキャンセルするキャンセルボタン２６８、契約文書の編集を保存する保存ボタン２６９を有している。

契約文書編集メニュー２６０は、少なくとも件名入力部２６１、契約開始日選択部２６２、契約終了日選択部２６３、契約カテゴリ選択部２６５、契約金額入力部２６６が記入され、その後、保存ボタン２６９が選択されると、編集した内容が契約文書テーブル１３０（図３参照）に保存されて契約文書編集メニュー２６０が閉じられる。また、キャンセルボタン２６８が選択された際も契約文書編集メニュー２６０は閉じられる。

契約文書の編集内容が保存されると、文書整理ページ２００の文書一覧部２２０の元のスレッドは更新される。また保存された契約文書の契約開始日、契約終了日、契約検討日は、カレンダー８０およびカレンダー３０２に表示される。

図９は、カテゴリ設定部１０１ｉにより医療機関担当者端末２０のディスプレイ４０に表示される画面の説明図であり、図９（Ａ）はカテゴリ設定ページ２７０の画面構成図であり、図９（Ｂ）はカテゴリ新規作成メニュー２７１の画面構成図である。
カテゴリ設定ページ２７０は、タスクバー６０、契約文書についてのカテゴリを編集する契約文書カテゴリ部２８０、および依頼についてのカテゴリを編集（追加、変更、削除）する依頼カテゴリ部２９０を有している。

カテゴリ設定ページ２７０が表示されているとき、タスクバー６０のカテゴリ設定タブ６５は、タスクバー６０内の他のタブと異なる色で表示される。

契約文書カテゴリ部２８０と依頼カテゴリ部２９０は、それぞれ登録された複数のカテゴリを一覧で表示する。

契約文書カテゴリ部２８０と依頼カテゴリ部２９０は、それぞれ選択されるとカテゴリ新規メニューを開くカテゴリ新規作成ボタン２８１、２９１、カテゴリごとのスレッドであるカテゴリスレッド２８２、２９２、カテゴリ名を示すカテゴリ名表示部２８３、２９３、カテゴリに登録されている件数を示すカテゴリ登録数表示部２８４、２９４、選択されるとカテゴリの編集画面を表示するカテゴリ編集ボタン２８５、２９５、および選択されるとカテゴリスレッド２８２、２９２を削除する削除ボタン２８６、２９６を有する。

カテゴリ新規作成ボタン２８１が選択されると、カテゴリ新規作成メニュー２７１を表示する。カテゴリ新規作成メニュー２７１は、カテゴリ設定ページ２７０をバックグラウンドとしてその上にフォアグラウンドとして表示される（図９ｂ）。

図９（Ｂ）に示すカテゴリ新規作成メニュー２７１は、カテゴリの名称が入力されるカテゴリ名称入力部２７２、検討日が選択されるカテゴリ選択部２７３、選択されるとカテゴリ作成をキャンセルするキャンセルボタン２７４、カテゴリを作成するカテゴリ作成ボタン２７５を有する。カテゴリ名称入力部にカテゴリの名称が入力され、カテゴリ作成ボタン２７５が選択されると、新規カテゴリが作成されて文書カテゴリテーブル１３２（図３参照）に追加登録される。

各カテゴリに設定される検討日は、契約書類に登録された契約終了日に対してどれくらいの期間だけ前に検討を開始するのが良いかを示す検討開始時期が記憶されている。この検討日は、実施例では、契約終了日の６か月前、１年前、１年６か月前、または２年前から選択可能に構成されているが、これに限らず、他の期間も選択できるようにする、あるいは直接入力できるようにするなど、適宜の構成とすることができる。

なお、この実施例では、カテゴリ単位で検討日を設定できる構成としているが、契約文書テーブル１３０（図３参照）に「検討日」の項目を追加し、契約終了日のどれだけ前に更新等の契約の検討を開始するのが良いかを契約文書毎に個別に登録できるようにしてもよい。この場合、契約文書テーブル１３０の「検討日」に期間が登録されていなければその契約文書のカテゴリに設定された検討日を採用し、契約文書テーブル１３０の「検討日」に期間が登録されていれば契約終了日からのその期間前の日を「検討日」として採用すると良い。これにより、カテゴリ毎に検討日が定まっていて入力数を減らせて利便性が高く、かつ、契約文書に応じて検討日を個別に変更できて柔軟性の高いシステムを提供できる。

カテゴリ作成ボタン２７４が選択される、あるいは、キャンセルボタン２７３が選択されたとき、カテゴリ新規作成メニュー２７１は閉じられる。作成された新規カテゴリは、カテゴリ設定ページ２７０に新たなスレッド２８２として、表示される。

カテゴリ編集ボタン２８５が選択されると、カテゴリ編集メニューが表示される（図省略）。カテゴリ編集メニューは、カテゴリの名称編集部および、検討日編集部を有する。

カテゴリ削除ボタン２８６、２９６によるカテゴリの削除は、カテゴリ内に分類されている書類がない場合でないとできない。カテゴリ内に分類されている書類がある場合は、エラーが表示される。

図１０は、スケジュール整理部１０１ｈにより医療機関担当者端末２０のディスプレイ４０に表示される画面の説明図であり、図１０（Ａ）は、カレンダーページ３００の画面構成図であり、図１０（Ｂ）は、スケジュール登録メニュー３１０の画面構成図である。
図１０（Ａ）に示すように、カレンダーページ３００は、タスクバー６０、選択されるとカレンダーにスケジュールの新規登録を促すスケジュール登録ボタン３０１、１か月のカレンダーを表示するカレンダー表示３０２を有する。

カレンダー表示３０２は、選択されると表示しているカレンダーの月を前月あるいは次月にする月送りボタン３０３、“今日”を含む月を表示する今日ボタン３０２、医療機関担当者が個人的に登録したスケジュールである個人スケジュール３０５、医療機関担当者が属する医療機関が取引先企業と交わした契約書のスケジュールである契約書スケジュール３０６（グループスケジュール８２）を有する。
前述した“今日”は、サーバ装置１００と医療機関担当者端末２０が最後に通信した時点での時刻によって定められる。

個人スケジュール３０５、契約書スケジュール３０６は、カレンダーの日付部分に表示される。個人スケジュール３０５は、スケジュールの件名が表示され、契約書スケジュール３０６は、取引先企業の名称が表示される。

個人スケジュールは、スケジュールを開始する開始スケジュールとスケジュールを終了する日を示す終了スケジュールを有し、カレンダーの日付部分に表示される開始スケジュールと終了スケジュールは、それぞれ違う色を有する。スケジュールが日をまたがないときは、開始スケジュールと同じ色で表示される。

契約書スケジュール３０６は、契約が開始される日を表示した契約開始スケジュール３０７と、契約が終了される日を表示した契約終了スケジュール３０８と、契約の検討を開始する日を表示した契約検討スケジュール３０９を有している。
カレンダーの日付部分に表示される契約開始スケジュール３０７と契約終了スケジュール３０８と契約検討スケジュール３０９はそれぞれ異なる色を有する。

スケジュール登録ボタン３０１が選択されると、医療機関担当者はカレンダーに個人のスケジュール（個人スケジュール３０５）の登録を促すスケジュール登録メニュー３１０を表示する（図１０（Ｂ））。

図１９（Ｂ）に示すように、スケジュール登録メニュー３１０は、スケジュールページ３００をバックグラウンドとしてその上にフォアグラウンドとして表示される。

スケジュール登録メニューはスケジュールの開始日時が選択される開始日時選択部３１１、スケジュールの終了日時が選択される終了日時選択部３１２、１日を通してのスケジュールを登録する際に選択される終日ボタン３１３、スケジュールの件名が入力される件名入力部３１４、メモが記入されるメモ記入部３１５、選択されるとカレンダー登録をキャンセルするキャンセルボタン３１６、カレンダー登録をする登録ボタン３１７を有する。

スケジュール登録メニュー３１０は、キャンセルボタン３１６または登録ボタン３１７が選択されたとき、閉じる。スケジュール登録メニュー３１０から登録されたスケジュールは、スケジュールページ３００のカレンダー３０２に表示される。また、新規文書作成メニュー２４０から登録された契約文書の契約開始日、契約終了日、契約検討日は、カレンダー３０２に表示される。それに加え、契約文書編集メニュー２６０によって編集、保存された契約開始日、契約終了日、契約検討日もカレンダー３０２に表示される。

カレンダー３０２に表示されるスケジュールは、トップページ５０のカレンダー８０にも記載される。トップページ５０のカレンダー８０とスケジュールページ３００のカレンダー３０２は、同じものである。しかし、表示されるサイズが異なるために、表示すべきスケジュールの件名や企業名の省略幅が異なるものである。

図１１は、ユーザ設定部１０１ｊにより医療機関担当者端末２０のディスプレイ４０に表示されたユーザ設定ページ３２０の画面構成図である。
ユーザ設定ページ３２０は、タスクバー６０、ユーザ一覧表示部３３０、ユーザ登録部３４０を有している。

ユーザ設定ページ３２０を表示しているとき、タスクバー６０のユーザ設定タブ６６は、タスクバー６０内の他のタブと異なる色で表示されている。

ユーザ一覧表示部３３０は、医療機関担当者の属する医療機関に属する医療機関担当者をスレッド一覧で表示している。ユーザ一覧表示部３３０は、スレッド３３５ごとにユーザ名を表示するユーザ名表示部３３１、ユーザ（医療機関担当者）のメールアドレスを表示するメールアドレス表示部３３２、“権限”を表示する権限表示部３３３を有する。

権限表示部３３３に表示される権限は、取引先企業からの契約書や見積書などを承認する権限を有する“承認者”と、医療機関担当者に付与される権限であって承認する権限を有さない“一般”と、全ての動作を行える“管理者”の３種類が設定されている。

ユーザ登録部３４０は、招待したい同じ医療機関に属する医療機関担当者（新たなユーザ）のメールアドレスが入力されるメールアドレス入力部３４１と、サーバ装置１００にメールアドレス入力部３４１に入力されたメールアドレス情報を送信する送信ボタン３４２を有する。サーバ装置１００は、送信されたメールアドレス情報を受信し、そのメールアドレス宛に医療用取引管理システムＡへのユーザ登録を促すメールを送信する。メールを受け取った医療機関担当者は、指示に従い、ユーザの登録がされると、新たなスレッド３３５としてユーザ一覧表示部３３０に表示される。

図１２は、医療機関担当者がある商品・サービスに関して、複数の企業に対して見積依頼をし、その中から選択した業者と契約するまでの流れを示すフローチャートである。

このフローチャートは、医療機関担当者が使用する医療機関担当者端末２０の制御部２１が、サーバ装置１００にアクセスし、ログイン処理部１０１ａによるログインを行った後、トップページ５０（図５参照）の依頼タブ６３が選択されて依頼処理部１０１ｇが機能してからの処理を示している。

依頼処理部１０１ｇは、図６（Ａ）に示す依頼ページ１８０を表示し、新規依頼ボタン１８１が選択されて図６（Ｂ）の新規依頼作成メニュー１９０で依頼（見積依頼）が行われると（ステップＳ１）、見積依頼のメッセージを企業担当者へ送信し、ステータス１７７を「依頼中」（見積依頼中）に設定する。このとき、複数の企業が指定されていれば、複数の企業へ見積依頼のメッセージを一斉配信する。各企業へ配信されたメッセージは、その企業の企業担当者であれば誰でも確認して返信できるようになっている。

依頼処理部１０１ｇは、企業担当者端末１０からの返信メッセージおよび見積を受け付けると、当該返信メッセージと見積を依頼した医療機関へ送信する（ステップＳ２）。この返信メッセージと見積は、その医療機関の医療機関担当者であれば誰でも確認でき、かつ、誰でも次の処理を進めることができる。

依頼処理部１０１ｇは、追加連絡が必要で（ステップＳ３：要）、追加メッセージが医療機関担当者によって送信された場合（ステップＳ４）、ステップＳ２へ処理を進めて企業担当者による返信メッセージと見積の提出まで待機する。

追加連絡が不要であれば（ステップＳ３：不要）、依頼処理部１０１ｇは、医療機関担当者の操作による見積承認申請の入力を受け付け、承認権限のある承認者に当該見積承認申請のメッセージを送信し、ステータス１７７を「承認待」（見積承認待）に変更する（ステップＳ４）。この見積承認申請は、複数の１つの依頼に対して１つの企業を採用することを条件とする。したがって、１つの依頼に対して２以上の企業の見積りに対して見積承認申請をすることはできず、２つ目の見積承認依頼申請を行った場合、依頼処理部１０１ｇは、どの企業のどの見積を採用予定か決定するようにエラーメッセージを表示するなど、適宜の構成とすることができる。すなわち、１つの依頼の中で２以上の企業のステータスが「承認待」とすることを許容しない。したがって、１つ目の企業の見積承認申請が却下され、「依頼中」のステータスに変更された場合は、２つ目の企業に対して見積承認申請をすることができる。この見積承認申請は、図６（Ａ）のステータス１７７が選択されることによって、また、見積承認申請の際、見積を添付するとともに、医療機関担当者から承認者へのメッセージを入力することができる。このため、承認者はそのメッセージに記載された情報を得て判断することができる。

承認者が医療機関担当者端末２０または管理者端末３０により見積承認申請を却下した場合（ステップＳ７：却下）、ステップＳ１に処理を戻してやり直す。
承認者が承認した場合（ステップＳ７：承認）、依頼処理部１０１ｇは、承認されたことを示すメッセージを医療機関担当者に送信してステータス１７７を「承認済」（見積承認済）に変更する。そして、依頼処理部１０１ｇは、医療機関担当者によってステータス１７７が「完了」（確定）に変更されることを受け付ける（ステップＳ８）。

依頼処理部１０１ｇは、医療機関担当者によって見積確定した企業への契約文書の依頼を受け付け、ステータス１７７を「依頼中」（契約文書依頼中）に変更する（ステップＳ９）。なお、ステップＳ８とステップＳ９を１つにまとめ、医療機関担当者がステータス１７７を「完了」に変更すると、契約文書の依頼を受け付けてステータス１７７を「依頼中」に変更する構成にしてもよい。
依頼処理部１０１ｇは、企業担当者による返信メッセージの入力と契約文書の提出を受け付けると（ステップＳ１０）、そのまま医療機関担当者へ送信する。

追加連絡が要であれば（ステップＳ１１：要）、依頼処理部１０１ｇは、追加メッセージの送信を受け付け（ステップＳ１２）、ステップＳ１０へ処理を戻して相手方の返信メッセージ等の到着を待機する。

追加連絡が不要であれば（ステップＳ１０：不要）、依頼処理部１０１ｇは、医療機関担当者による契約承認申請の入力を受け付ける（ステップＳ１３）。この契約承認申請の入力は、図６（Ａ）のステータス１７７が選択されることによって、ステータスを「承認待」（契約文書承認待）に変更して実行する等、適宜の方法で実行することができる。

依頼処理部１０１ｇは、承認者による契約承認の入力を受け付け（ステップＳ１４）、当該契約承認の入力結果が「却下」であった場合は（ステップＳ１５；却下）、ステップＳ９に処理を戻してやり直す。
契約承認の入力結果が「承認」であった場合（ステップＳ１５；承認）、依頼処理部１０１ｇは、医療機関担当者へ承認完了等を示す通知を行い、ステータス１７７を「承認済」（契約文書承認済）に変更する。

依頼処理部１０１ｇは、医療機関担当者による「契約確定」の入力を受け付け（ステップＳ１６）、ステータス１７７を「完了」（契約成立）に変更して処理を終了する。この契約確定では、新規文書整理メニュー２４０（図７（Ｂ）参照）で契約文書のカテゴリの設定、契約日および契約満了日の入力など、医療機関担当者による必要情報の入力を受け付け、入力されたデータを契約文書テーブル１３０（図３参照）に記憶する。

以上の構成および動作により、医療用取引管理システムＡは、医療機関における各種管理を容易にし、利用者の利便性を向上させることができる。

また、見積と契約文書の少なくとも一方について承認申請を行う構成であるため、必ず承認を受けて契約を成立させることができ、医療機関が企業との取引を問題なく着実に実施することができる。

また、承認対象となる書類とメッセージを、承認権限を有する者へ送信する構成であるため、承認者は、承認対象である見積書または／および契約文書を全部着実確認することができる。

また、見積承認申請と契約文書承認申請の両方を行う構成であるため、要所で確実に承認して契約までの一連の手続きを滞りなくスムーズに運ぶことができる。すなわち、承認の回数が多すぎると業務効率が悪くなり、逆に承認回数が少なすぎると承認者が気づいた時点では大幅に手遅れということが生じるが、このようなことなく１つずつのステップを確実に実行して結果として正確で速い処理を実現できる。

また、スレッドが企業単位で見ることができる構成であるため、複数の企業の情報が混在してどの企業のことであったかが混乱するといったことが生じ難く、適切に処理していくことができる。

また、ステータス１７７は、変化する順番が定まっているため、予定外の事態が生じることを防止でき、承認ルートを確実に通過させて契約締結するといったことができる。

また、トップページ５０は、カレンダー８０、および通知部９０を有するため、医療機関担当者は、企業担当者から受信した情報と、カレンダー情報を１画面で確認して便利に利用することができる。すなわち、カレンダー８０では、スケジュールに応じてしなければならない業務を確認でき、通知部９０では、企業担当者から受信して処理しなければならない情報を確認できるため、処理しなければならない業務と期限のある業務とを同時に確認して適切に振り分けて進めることができる。しかもトップページ５０として最初の画面（メインの画面）に表示されるため、確認漏れも防止でき、確実に業務を進めることができる。

また、カレンダー８０にグループスケジュール８２として契約満了日が表示されるため、医療機関担当者は、契約満了日が迫っている契約について契約満了前に契約の更新や再契約、あるいは取引先の変更といったことを実施することができる。したがって、契約満了日が過ぎているにもかかわらず気づかないでそのままにするといったことを防止できる。

また、医療機関担当者個人の個人スケジュール８１と、その医療機関に所属する医療機関担当者全員に表示されるグループスケジュール８２を、１つのカレンダー８０にまとめて表示するため、医療機関担当者は自分のスケジュールを確認しつつ自身の所属する医療機関全体で進めなければならない業務を各自分担して進めて行くことができる。

また、通知部９０は、メッセージ通知部９１および契約文書通知部９２を有しており、企業担当者からの見積等のメッセージと、契約することが決まり企業担当者から送信されてきた契約文書とを両方確認できるため、それぞれ適切に処理することができる。しかも、契約前で雑多な情報も含まれやすい見積等のメッセージと、契約が決まって重要である契約文書等が、メッセージ通知部９１と契約文書通知部９２に分かれて表示されるため、重要度に応じた処理を適切に実行することが容易に実現される。特に、重要な契約文書が雑多なメッセージに埋もれるということが生じないため、操作に不慣れな医療機関担当者であっても漏れのない適切な処理を確実に実施できる。

また、カレンダー８０には、契約満了日の前に検討日が表示されるため、契約に時間のかかるようなものであっても検討開始すべき時期を的確に把握でき、スムーズに契約の更新や再契約等を進めることができる。しかも、文書のカテゴリによって検討日がデフォルトで決定される構成であるため、適切な検討日を容易に設定することができるとともに、検討日の設定漏れを防止することができる。さらに、契約文書に個別に検討日を登録することもできるため、様々な契約に対して柔軟に対応することができる。

また、医療機関担当者は、１つの依頼（見積依頼）を１つの単位として、複数企業に対して見積依頼のメッセージを一斉にまたは個別に送信でき、その後は企業単位でメッセージの送受信を実施できて、企業毎に企業別ステータス１８３を付与できる。このため、金額やスペック等で折り合わない企業については企業別ステータス１８３を「完了」等に順次設定していき、最終的に残った企業を「採用候補」として、図示省略する「院内承認」あるいは「完了」に設定するボタンを押してその企業の見積の承認を得て契約を進めるといったことができる。また、途中で見積の承認が拒否された場合に、ステータス１７７が「依頼中」に戻るため、次に条件の良かった別の企業の企業別ステータス１８３を「採用候補」として見積承認申請をし、承認が得られれば契約を進めるといったこともできる。したがって、多数の企業の中から最適な企業と契約する作業を効率よく進めることができる。

この発明は、上述の実施形態の構成のみに限定されるものではなく、多くの実施の形態を得ることができる。

この発明は、医療機関と企業の間で商品およびサービスの取引を行うに際して利用することができる。

Ａ…医療用取引管理システム
２０…医療機関担当者端末
１００…サーバ装置
１０１ｂ…ダッシュボード表示部
１０１ｃ…カレンダー表示部
１０１ｄ…受信メッセージ表示部
１０１ｅ…受信契約書表示部
１０１ｆ…文書整理部
１０１ｇ…依頼処理部
１０１ｈ…スケジュール整理部
１０１ｉ…カテゴリ設定部
１１３…依頼関連データ
１１４…スケジュール関連データ

Claims (8)

1. 医療に関するサービスを行う医療機関で業務する医療機関担当者が使用する複数の医療機関担当者端末と、
   前記医療機関に物または／およびサービスを提供する取引先企業の企業担当者が使用する複数の企業担当者端末と、
   前記医療機関担当者端末および前記企業担当者端末と通信回線を介して接続されたサーバ装置とを備え、
   前記医療機関担当者端末と前記企業担当者端末と前記サーバ装置の少なくとも１つに各種データを記憶する記憶手段を備え、
   前記記憶手段は、
   前記医療機関担当者に関する医療機関担当者データと、
   前記企業担当者に関する企業担当者データとを記憶し、
   前記医療機関担当者データは、少なくとも承認者としての権限を有するのか否かを認識可能に構成されており、
   前記医療機関担当者が前記企業担当者に見積の依頼を行う依頼処理部と、
   前記依頼処理部により得られた見積についての契約文書を前記企業担当者に求める契約文書処理部と、
   前記見積と前記契約文書の少なくとも一方について可否の承認を行う承認処理部とを備えた
   医療用取引管理システム。
2. 前記承認処理部は、
   前記医療機関担当者による承認申請の依頼を受け付けると、前記承認者としての権限を有する者へ承認申請のメッセージを承認対象となる添付書類とともに送信する構成である
   請求項１記載の医療用取引管理システム。
3. 前記承認処理部は、
   前記見積の承認依頼であれば前記企業担当者から送信された見積を添付した見積承認申請のメッセージを前記承認者としての権限を有する者へ送信し、
   前記契約文書の承認依頼であれば前記企業担当者から送信された契約文書を添付した契約文書承認申請のメッセージを前記承認者としての権限を有する者へ送信する構成である
   請求項２記載の医療用取引管理システム。
4. 前記依頼処理部は、
   １つの依頼について複数の企業へ依頼メッセージを送信でき、
   前記企業担当者から見積を受信すると企業単位でメッセージの送受信を行ってスレッド式に時系列で表示できる構成である
   請求項３記載の医療用取引管理システム。
5. 前記複数の企業の企業担当者から見積を受信した場合に、
   最終的に１つの企業の前記見積について、前記承認者としての権限を有する者へ見積承認申請のメッセージを送信できる構成である
   請求項４記載の医療用取引管理システム。
6. １つの前記依頼について、現在の状態を示すステータスを記憶する構成であり、
   前記ステータスは、
   前記企業担当者へ見積を依頼して選定している依頼中の状態であることを示す第１ステータスと、
   医療機関担当者が１つの見積を選択して前記承認者としての権限を有する者へ承認申請を行っている状態であることを示す第２ステータスと、
   前記承認申請が承認された承認済であることを示す第３ステータスとを少なくとも備え、
   前記第１ステータス、前記第２ステータス、および前記第３ステータスは、次のステータスへ進む際に必ずこの順番に進むよう構成されている
   請求項５記載の医療用取引管理システム。
7. 医療に関するサービスを行う医療機関で業務する医療機関担当者が使用する複数の医療機関担当者端末と、
   前記医療機関に物または／およびサービスを提供する取引先企業の企業担当者が使用する複数の企業担当者端末と、
   前記医療機関担当者端末および前記企業担当者端末と通信回線を介して接続されたサーバ装置とを用い、
   前記医療機関担当者端末と前記企業担当者端末と前記サーバ装置の少なくとも１つの記憶手段に各種データを記憶し、
   前記記憶手段は、
   前記医療機関担当者に関する医療機関担当者データと、
   前記企業担当者に関する企業担当者データとを記憶し、
   前記医療機関担当者データは、少なくとも承認者としての権限を有するのか否かを認識可能に構成されており、
   依頼処理部により前記医療機関担当者が前記企業担当者に見積の依頼を行い、
   前記依頼処理部により得られた見積についての契約文書を契約文書処理部により前記企業担当者に求め、
   前記見積と前記契約文書の少なくとも一方について承認処理部により可否の承認を行う
   医療用取引管理方法。
8. コンピュータを、
   医療機関担当者端末と企業担当者端末とサーバ装置の少なくとも１つに各種データを記憶する記憶手段と、
   前記医療機関担当者が前記企業担当者に見積の依頼を行う依頼処理部として機能させ、
   前記記憶手段は、
   前記医療機関担当者に関する医療機関担当者データと、
   前記企業担当者に関する企業担当者データとを記憶し、
   前記医療機関担当者データは、少なくとも承認者としての権限を有するのか否かを認識可能に構成されており、
   前記依頼処理部により得られた見積についての契約文書を契約文書処理部により前記企業担当者に求め、
   前記見積と前記契約文書の少なくとも一方について承認処理部により可否の承認を行う構成である
   医療用取引管理プログラム。

Images