(57)【特許請求の範囲】
【請求項１】
複数の患者それぞれを識別する識別子と、当該複数の患者それぞれに対する医療行為の予約の日時とを、それぞれ対応づけて記憶する、予約日時記憶手段と、
前記複数の患者それぞれに対する前記医療行為の緊急性のレベルと当該各患者の前記識別子とをそれぞれ対応づけて記憶する、レベル記憶手段と、
前記レベル記憶手段に記憶されている前記各レベルを、前記医療行為の予約の日時になる前の所定のタイミングごとに、時間の経過に伴って高くなるように更新する、レベル更新手段と、
前記レベルが基準レベルよりも高い第二の患者に対して施す前記医療行為の予約の要求を受け付けた際に、当該予約の日時を、前記レベル記憶手段に記憶されている前記複数の患者のうち、前記レベルが最も低い患者の予約の、前記予約日時記憶手段に記憶されている日時に確定し、かつ、前記予約日時記憶手段に記憶されている当該患者の予約の日時を他の日時に変更する、予約調整処理手段と、
を有することを特徴とする予約管理装置。
【請求項２】
前記予約調整処理手段は、前記第二の患者に対して施す前記医療行為の予約の日時を、所定の期間に属する予約を行った前記複数の患者のうちの前記レベルが最も低い患者の予約の日時に確定する、
請求項１記載の予約管理装置。
【請求項３】
前記所定の期間は、前記第二の患者の病名によって異なる、
請求項２記載の予約管理装置。
【請求項４】
前記患者または前記第二の患者の書類に記載される病状を示す病状データを入力する病状データ入力手段と、
前記病状データ入力手段によって入力された、前記患者または前記第二の患者の前記病状データに基づいて、当該患者または第二の患者の前記レベルを判別する、レベル判別手段と、を有し、
前記レベル記憶手段は、前記レベル判別手段によって判別された前記レベルを記憶する、
請求項１ないし請求項３のいずれかに記載の予約管理装置。
【請求項５】
複数の患者それぞれを識別する識別子と、当該複数の患者それぞれに対する医療行為の予約の日時とを、それぞれ対応づけて記憶する、予約日時記憶手段と、
前記複数の患者それぞれに対する前記医療行為の緊急性のレベルと当該各患者の前記識別子とをそれぞれ対応づけて記憶する、レベル記憶手段と、
前記レベル記憶手段に記憶されている前記各レベルを、前記医療行為の予約の日時になる前の所定のタイミングごとに、時間の経過に伴って高くなるように更新する、レベル更新手段と、
前記レベルが第一の基準レベルよりも高い第二の患者に対して施す前記医療行為の予約の要求を受け付けた際に、当該予約の日時を、前記レベル記憶手段に記憶されている前記レベルが第二の基準レベルよりも低い前記患者の予約の、前記予約日時記憶手段に記憶されている日時に確定し、かつ、前記予約日時記憶手段に記憶されている当該患者の予約の日時を他の日時に変更する、予約調整処理手段と、
を有することを特徴とする予約管理装置。
【請求項６】
前記他の日時は、前記第二の患者のために予約の日時が変更される患者の第二希望の日時であり、
前記予約調整処理手段は、前記第二の患者のために予約の日時が変更される患者の予約の日時を前記他の日時に確定する、
請求項１ないし請求項５のいずれかに記載の予約管理装置。
【請求項７】
複数の患者それぞれを識別する識別子と、当該複数の患者それぞれに対する医療行為の予約の日時とを、それぞれ対応づけて予約日時記憶手段に記憶させておき、
前記複数の患者それぞれに対する前記医療行為の緊急性のレベルと当該各患者の前記識別子とをそれぞれ対応づけてレベル記憶手段に記憶させておき、
コンピュータに、
前記レベル記憶手段に記憶されている前記各レベルを、前記医療行為の予約の日時になる前の所定のタイミングごとに、時間の経過に伴って高くなるように更新する第一の処理と、
前記レベルが基準レベルよりも高い第二の患者に対して施す前記医療行為の予約の要求を受け付けた際に、当該予約の日時を、前記レベル記憶手段に記憶されている前記複数の患者のうち、前記レベルが最も低い患者の予約の、前記予約日時記憶手段に記憶されている日時に確定し、かつ、前記予約日時記憶手段に記憶されている当該患者の予約の日時を他の日時に変更する第二の処理と、
を実行させる、
ことを特徴とする予約管理方法。
【請求項８】
前記他の日時は、前記第二の患者のために予約の日時が変更される患者の第二希望の日時であり、
前記コンピュータに、前記第二の処理において、前記第二の患者のために予約の日時が変更される患者の予約の日時を前記他の日時に確定する処理を実行させる、
請求項７記載の予約管理方法。
【請求項９】
予約に関する管理を行うコンピュータに用いられるコンピュータプログラムであって、
前記コンピュータに、
複数の患者それぞれを識別する識別子と、当該複数の患者それぞれに対する医療行為の予約の日時とを、それぞれ対応づけて予約日時記憶手段に記憶させる第一の処理と、
前記複数の患者それぞれに対する前記医療行為の緊急性のレベルと当該各患者の前記識別子とをそれぞれ対応づけてレベル記憶手段に記憶させる第二の処理と、
前記レベル記憶手段に記憶されている前記各レベルを、前記医療行為の予約の日時になる前の所定のタイミングごとに、時間の経過に伴って高くなるように更新する第三の処理と、
前記レベルが基準レベルよりも高い第二の患者に対して施す前記医療行為の予約の要求を受け付けた際に、当該予約の日時を、前記レベル記憶手段に記憶されている前記複数の患者のうち、前記レベルが最も低い患者の予約の、前記予約日時記憶手段に記憶されている日時に確定し、かつ、前記予約日時記憶手段に記憶されている当該患者の予約の日時を他の日時に変更する第四の処理と、
を実行させる、
ことを特徴とするコンピュータプログラム。
【請求項１０】
前記他の日時は、前記第二の患者のために予約の日時が変更される患者の第二希望の日時であり、
前記コンピュータに、前記第四の処理において、前記第二の患者のために予約の日時が変更する患者の予約の日時を前記他の日時に確定する処理を実行させる、
請求項９記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、医療機関での診察などの予約を管理する装置および方法などに関する。
【背景技術】
【０００２】
従来、病院などの医療機関において、患者は、診察または検査などの医療行為の予約を、先着順に、空いている日時の中から都合のよい日時を選ぶことによって行う。
【０００３】
また、従来、特許文献１、２に記載されるような医療機関における医事の方法が知られている。特許文献１には、患者を他の医療部署に紹介する方法が記載されている。特許文献２には、地域の医療機関がそれぞれ端末を備え、個々の端末をネットワークを介して相互接続し、診察医が診断に自信がもてない場合には、共有データベースに登録されている専門医を緊急度を加味して呼び出し診断を行ない全員が一致することで診察を行う、という方法が記載されている。
【特許文献１】特開２００１−１８８８５８号公報
【特許文献２】特開２００６−２４３９５３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、上述の従来の方法では、緊急を要する患者の予約が優先的に行われないことがある。そうすると、早い時期に緊急を要する患者の予約が取れない、という問題が生じ得る。このような場合には、他のいずれかの患者の予約の日時を、その緊急の患者のために変更することが考えられる。しかし、どの患者の予約の日時を変更するのかを決めるのは容易ではない。
【０００５】
本発明は、このような問題点に鑑み、緊急を要する患者がいる場合に予約の調整を従来よりも好適にかつ容易に行うことを、目的とする。
【課題を解決するための手段】
【０００６】
本発明の一形態に係る予約管理装置は、複数の患者それぞれを識別する識別子と、当該複数の患者それぞれに対する医療行為の予約の日時とを、それぞれ対応づけて記憶する、予約日時記憶手段と、前記複数の患者それぞれに対する前記医療行為の緊急性のレベルと当該各患者の前記識別子とをそれぞれ対応づけて記憶する、レベル記憶手段と、前記レベル記憶手段に記憶されている前記各レベルを、前記医療行為の予約の日時になる前の所定のタイミングごとに、時間の経過に伴って高くなるように更新する、レベル更新手段と、前記レベルが基準レベルよりも高い第二の患者に対して施す前記医療行為の予約の要求を受け付けた際に、当該予約の日時を、前記レベル記憶手段に記憶されている前記複数の患者のうち、前記レベルが最も低い患者の予約の、前記予約日時記憶手段に記憶されている日時に確定し、かつ、前記予約日時記憶手段に記憶されている当該患者の予約の日時を他の日時に変更する、予約調整処理手段と、を有する。
【０００７】
好ましくは、前記予約調整処理手段は、前記第二の患者に対して施す前記医療行為の予約の日時を、所定の期間に属する予約を行った前記複数の患者のうちの前記レベルが最も低い患者の予約の日時に確定する。または、前記所定の期間は、前記第二の患者の病名によって異なる。
【０００８】
本発明の他の形態に係る予約管理装置は、複数の患者それぞれを識別する識別子と、当該複数の患者それぞれに対する医療行為の予約の日時とを、それぞれ対応づけて記憶する、予約日時記憶手段と、前記複数の患者それぞれに対する前記医療行為の緊急性のレベルと当該各患者の前記識別子とをそれぞれ対応づけて記憶する、レベル記憶手段と、前記レベル記憶手段に記憶されている前記各レベルを、前記医療行為の予約の日時になる前の所定のタイミングごとに、時間の経過に伴って高くなるように更新する、レベル更新手段と、前記レベルが第一の基準レベルよりも高い第二の患者に対して施す前記医療行為の予約の要求を受け付けた際に、当該予約の日時を、前記レベル記憶手段に記憶されている前記レベルが第二の基準レベルよりも低い前記患者の予約の、前記予約日時記憶手段に記憶されている日時に確定し、かつ、前記予約日時記憶手段に記憶されている当該患者の予約の日時を他の日時に変更する、予約調整処理手段と、を有する。
【発明の効果】
【０００９】
本発明によると、緊急を要する患者がいる場合に予約の調整を従来よりも好適にかつ容易に行うことができる。
【発明を実施するための最良の形態】
【００１０】
図１は診察スケジュール管理装置１とスキャナ２との接続の例を示す図、図２は診察スケジュール管理装置１のハードウェア構成の例を示す図、図３は診察スケジュール管理装置１の機能的構成の例を示す図である。
【００１１】
図１に示す診察スケジュール管理装置１は、病院などの医療機関における診察のスケジュールを管理する装置である。この診察スケジュール管理装置１には、スキャナ２が接続されている。
【００１２】
診察スケジュール管理装置１は、図２に示すように、ＣＰＵ（Central Processing Unit）１０ａ、ＲＡＭ（Random Access Memory）１０ｂ、ＲＯＭ（Read Only Memory）１０ｃ、ハードディスク１０ｄ、ＮＩＣ（Network Interface Card）１０ｅ、液晶ディスプレイ１０ｆ、キーボード１０ｇ、ポインティングデバイス１０ｈ、ＵＳＢインタフェース１０ｉ、そのほか種々のハードウェアによって構成される。
【００１３】
ＲＯＭ１０ｃまたはハードディスク１０ｄには、図３に示すような患者病状情報取得部１０１、病名推定処理部１０２、予約可能枠検索部１０３、予約画面表示処理部１０４、スケジューリング処理部１０５、日次処理部１０６、病気関連マスタ記憶部１２１、スケジュールテーブル記憶部１２２、および患者マスタ記憶部１２３などの機能を実現するためのプログラムおよびデータが格納されている。これらのプログラムおよびデータは必要に応じてＲＡＭ１０ｂにロードされ、ＣＰＵ１０ａによってプログラムが実行される。
【００１４】
ＮＩＣ１０ｅは、医療機関内のサーバまたは外部のサーバなどとＬＡＮ回線またはインターネットなどを介して接続するための装置である。ＵＳＢインタフェース１０ｉは、スキャナ２と接続するためのＩ／Ｏ（Input/Output）デバイスである。
【００１５】
液晶ディスプレイ１０ｆには、後述する診察の予約のための画面などが表示される。キーボード１０ｇおよびポインティングデバイス１０ｈは、医療機関の従業員が診察スケジュール管理装置１にデータを入力したり指令を与えたりするための入力装置である。
【００１６】
診察スケジュール管理装置１として、パーソナルコンピュータまたはワークステーションなどが用いられる。
【００１７】
以下、内科、脳外科、眼科、および外科などの複数の診療科を有する医療機関Ｘにおいて診察スケジュール管理装置１が用いられる場合を例に説明する。
【００１８】
なお、医療機関Ｘでは、各診療科の診察のスケジュールの管理および他の医療機関からの紹介状の処理を特定の部門が一元的に行う。また、患者ごとに、ユニークな患者コードが１つずつ与えられている。
【００１９】
図４は担当診療科マスタＭＴ１の例を示す図、図５は疾病疑義器官マスタＭＴ２の例を示す図、図６は推定病名マスタＭＴ３の例を示す図、図７は予約規則マスタＭＴ４の例を示す図、図８はスケジュールテーブルＴＬの例を示す図、図９は予約患者テーブルＴＹの例を示す図である。
【００２０】
図３において、診察スケジュール管理装置１の病気関連マスタ記憶部１２１には、病気に関する図４、図５、図６、および図８に示すようなマスタが記憶されている。
【００２１】
図４の担当診療科マスタＭＴ１には、胃、脳、気管、および目などの器官（部位）ごとの担当診療科データＤＴＡが格納されている。担当診療科データＤＴＡの「診療科」フィールドは、医療機関Ｘの中の、その器官の診察を担当する診療科を示す。
【００２２】
図５の疾病疑義器官マスタＭＴ２には、胃のもたれ、胃の痛み、吐血、および立ちくらみなどの症状ごとの疾病疑義器官データＤＴＢが格納されている。疾病疑義器官データＤＴＢの「器官」フィールドおよび「深刻度点数」フィールドは、それぞれ、その症状が見られるときに病気を患っていると疑われる器官およびその症状の深刻さの度合いを表わす点数（以下、「深刻度点数」と記載する。）を示す。深刻度点数の値が大きいほど、より深刻であることを意味する。
【００２３】
図６の推定病名マスタＭＴ３には、１人の患者に見られる症状の深刻度点数の合計点数ごとの推定病名データＤＴＣが格納されている。推定病名マスタＭＴ３は、人体の器官ごとに１つずつ病気関連マスタ記憶部１２１に記憶されている。推定病名データＤＴＣの「推定病名」フィールドは、その合計点数から推定される病名（以下、「推定病名」と記載する。）を示す。
【００２４】
図７の予約規則マスタＭＴ４には、推定病名ごとの予約規則データＤＴＤが格納されている。予約規則マスタＭＴ４は、診療科ごとに１つずつ病気関連マスタ記憶部１２１に記憶されている。
【００２５】
予約規則データＤＴＤの「初期緊急レベル」フィールドは、患者がその推定病名の病気を患っていると判定（推定）された時点における、その患者に対する診察の緊急性のレベルを示す。以下、診察の緊急性のレベルを「緊急性レベル」と記載する。緊急性が高い順に、「１」、「２」、…、「９」の９段階の緊急性レベルがある。推定病名は、後述するように、他の医療機関からの紹介状の処理を行う際に、判定（推定）される。
【００２６】
ところで、患者の病状は、推定病名の判定の時点から診察を受けることなく日にちが経過すると、悪化するおそれがある。つまり、緊急性が徐々に高まる、と言える。そこで、診察スケジュール管理装置１は、後述するように、患者の推定病名の判定の日から診察の日まで、緊急度を定期的に高くする処理を行う。
【００２７】
予約規則データＤＴＤの「レベル更新タイミング」フィールドおよび「更新レベル数」フィールドは、それぞれ、その推定病名の患者の緊急性レベルを上げるインターバルおよび１回当たりに上げるレベル数を示す。
【００２８】
また、患者が病気を患っている疑いがある以上、推定病名を判定してから診察までの期間が短いほうが望ましい。
【００２９】
予約規則データＤＴＤの「診察待許容期間」フィールドは、その推定病名の病気であると判定されてから何日以内に診察を受けるべきであるかを示す。
【００３０】
そのほか、病気関連マスタ記憶部１２１には、病名ごとに、その病気を発症したときに併発することが多い他の病気（つまり、合併症）およびその深刻度を示す合併症マスタＭＴ５が記憶されている。
【００３１】
病気関連マスタ記憶部１２１に記憶されているこれらのマスタの内容は、医師または学者などが試験を行ったり経験的に得られる情報を解析したりすることによって、定められている。そして、診察スケジュール管理装置１の運用を開始する前に予めインストールされている。
【００３２】
図３のスケジュールテーブル記憶部１２２には、診療科ごとの、図８に示すようなスケジュールテーブルＴＬが記憶されている。
【００３３】
スケジュールテーブルＴＬには、その診療科での患者の診察のスケジュールの情報が格納されている。
【００３４】
具体的には、医療機関Ｘでは、診療科ごとに、１人の患者を診察する時間（以下、「単位診察時間」と記載する。）が定められている。そして、１日の診察時間帯を、開業時刻を先頭に単位診察時間ごとに区切っている。例えば、単位診察時間が１５分でありかつ開業時刻が１０時０分である診療科の場合は、図８に示すように１０時０分〜１０時１５分、１０時１５分〜１０時３０分、…のように区切っている。以下、区切られた１つ１つの時間帯を「診察時間枠」と記載する。
【００３５】
スケジュールテーブルＴＬには、日ごとの診察時間枠ごとのセルによって構成される。そして、各セルには、原則として、その日のその診察時間枠に予約を取った患者の患者コードおよび緊急性レベルが示される。
【００３６】
例えば、２００８年３月１１日の１３時０分〜１３時１５分の診察時間枠には「Ｋ００２，３」という情報が示されるが、これは、その日のその診察時間枠に、患者コードが「Ｋ００２」でありかつ緊急性レベルが「３」である患者が予約が取られていることを意味する。
【００３７】
ただし、緊急性レベルが所定のレベルよりも低い患者の予約は、緊急性の高い他の患者のために、変更されることがある。その場合は、その患者の予約は、第二希望の診察時間枠に変更される。例えば、患者コードが「Ｋ００２」である患者の予約は、２００８年３月１３日の１１時０分〜１１時１５分の診察時間枠にも取られている。しかし、この診察時間枠のセルには、患者コードの後ろに緊急性レベルの代わりに「第二」という値が示されている。これは、その予約が第二希望のものであることを、意味する。
【００３８】
言い換えれば、所定のレベル以上の高さの緊急性レベルを有する患者の予約は変更されない。つまり、確定されている。一方、所定のレベルよりも低い緊急性レベルを有する患者の予約は、仮予約の状態である。
【００３９】
この所定のレベルは、診療科ごとに任意に設定することができる。以下、所定のレベルが「１」である場合を例に説明する。
【００４０】
なお、毎日の所定の時刻に、所定の日数（例えば、２８日）先の日の各診察時間枠のセルが、スケジュールテーブルＴＬに追加される。これにより、所定の日数先の日の予約の受付が可能になる。追加された時点では、セルには何も示されない。
【００４１】
図３の患者マスタ記憶部１２３には、診療科ごとの、図９に示すような予約患者テーブルＴＹが記憶されている。
【００４２】
予約患者テーブルＴＹには、その診療科での診察の予約を取った患者ごとの患者予約データＤＴＦが格納されている。
【００４３】
患者予約データＤＴＦの「患者コード」フィールドおよび「患者名」フィールドは、それぞれ、その患者の患者コードおよび氏名を示す。「推定病名」フィールドは、その患者が患っていると推定される病気つまり推定病名を示す。
【００４４】
「緊急性レベル」フィールドおよび「現緊急性レベル」フィールドは、それぞれ、その患者の推定病名の推定時における（つまり、初期の）緊急性レベルおよび現在の緊急性レベルを示す。
【００４５】
「仮予約日時」フィールドは、その患者の診察の仮の予約が入っている診察時間枠の日時を示す。「第二希望予約日時」フィールドは、その患者の第二希望である診察の診察時間枠の日時を示す。
【００４６】
「本予約日時」フィールドは、その患者の正式な（確定した）予約が入っている診察時間枠の日時を示す。この日時は、確定されたものであって、緊急を要する他の患者の都合によっては変更されない。
【００４７】
そのほか、患者予約データＤＴＦには、その患者の連絡先である電話番号および電子メールアドレスなどが示される。
【００４８】
図１０は病名推定処理の流れの例を説明するフローチャート、図１１は普通患者予約処理の流れの例を説明するフローチャート、図１２は緊急患者予約処理の流れの例を説明するフローチャート、図１３は予約患者テーブルＴＹの更新の例を示す図、図１４はスケジュールテーブルＴＬの更新の例を示す図、図１５は現緊急性レベル更新処理の流れの例を説明するフローチャートである。
【００４９】
図３の患者病状情報取得部１０１は、他の医療機関から医療機関Ｘを紹介された患者の病状に関する情報を取得する処理を行う。病名推定処理部１０２は、患者病状情報取得部１０１によって取得された情報に基づいて、患者の病名を推定する処理および緊急性レベルを求める処理を行う。患者病状情報取得部１０１および病名推定処理部１０２のこれらの処理は、例えば図１０のフローチャートに示す手順で行われる。
【００５０】
医療機関Ｘに患者の診察を依頼する他の医療機関は、その患者の症状のほか、その患者の氏名、患者コード、電話番号、および電子メールアドレスなどを記載した紹介状を医療機関Ｘに郵送しまたはファックスする。医療機関Ｘの従業員は、他の医療機関からの紹介状をスキャナ２の原稿台にセットし、読取ボタンを押すなどの所定の操作を行う。すると、スキャナ２は、紹介状に記されている画像を読み取って、診察スケジュール管理装置１に送信する。
【００５１】
診察スケジュール管理装置１において、患者病状情報取得部１０１は、スキャナ２から画像を受信すると（図１０の＃３０１）、その画像に対して文字認識処理を行うことによって、画像に記されている文字列を認識する（＃３０２）。
【００５２】
認識した文字列の中から、疾病疑義器官マスタＭＴ２（図５参照）に示される病状を検索し抽出する（＃３０３）。これにより、病状の情報が得られる。この際に、患者の氏名、患者コード、電話番号、および電子メールアドレスも抽出しておく。なお、紹介状を電子メールによってやり取りしてもよい。
【００５３】
病名推定処理部１０２は、器官ごとにカウンタを用意し、抽出された病状の疾病疑義器官データＤＴＢ（図５参照）に示される深刻度点数を、その疾病疑義器官データＤＴＢに示される器官のカウンタに加算する（＃３０４）。なお、カウンタの初期値は０点である。
【００５４】
例えば、患者病状情報取得部１０１は、「吐血」、「立ちくらみ」、および「倦怠感」という３つの症状を抽出した場合は、図５から分かるように、胃のカウンタに３点、２点、および１点を加算し、脳のカウンタに２点および１点を加算する。これにより、患者の人体の器官ごとの深刻さの大きさ、つまり、深刻度点数の合計点数が求められる。
【００５５】
そして、病名推定処理部１０２は、合計点数が最も高い器官の推定病名マスタＭＴ３（図６参照）の中からその合計点数の推定病名データＤＴＣを検索し、その推定病名データＤＴＣに示される推定病名を、その患者の病名であると、判定する（＃３０５）。
【００５６】
さらに、判定した病名（推定病名）の病気に一般に合併症が見られることがある場合は、次のように重み付けを行うことによって、判定結果を補正する（＃３０６）。
【００５７】
病名推定処理部１０２は、判定した病名の病気の合併症を、合併症マスタＭＴ５に基づいてチェックする。また、ステップ＃３０４で求めた他の器官の深刻度点数の合計点数および当該他の器官の推定病名マスタＭＴ３に基づいて、その患者が発症していると考えられる他の病名を判定する。
【００５８】
そして、当該他の病名が、チェックした合併症の病名と一致するのであれば、その患者がその合併症をも発病していると推定できるので、病名推定処理部１０２は、その患者の深刻度点数の合計点数に、その合併症の深刻度に応じた重み付けを行うことによって、より重い病名に補正する。
【００５９】
例えば、その患者の深刻度点数の合計点数が７点であってそれに基づいて推定病名を「胃がん（軽度）」と判定し、その患者に合併症の疑いが見つかった場合は、その合計点数を、その合併症の深刻度に応じた点数（例えば、１点）を加算することにもって重み付けする。そして、重み付け後の合計点数に基づいて推定病名を例えば「胃がん（中度）」と補正する。
【００６０】
フローチャートに戻って、病名推定処理部１０２は、患者の推定病名を判定し、必要に応じて推定病名の補正を行ったら、その患者の患者コード、氏名、電話番号、電子メールアドレス、および判定し必要に応じて補正した推定病名などを示す患者予約データＤＴＦを生成し（図１３（ａ）参照）、予約患者テーブルＴＹに格納させる（＃３０７）。
【００６１】
そのほか、患者予約データＤＴＦの「設定日」フィールドには、当日の日付が示される。「緊急性レベル」フィールドおよび「現緊急性レベル」フィールドには、その患者の推定病名に応じた緊急性レベルが示される。この緊急性レベルは、その推定病名に係る器官の推定病名マスタＭＴ３（図７参照）の中の、算出し必要に応じて重み付けした合計点数の予約規則データＤＴＤの、「初期緊急性レベル」フィールドに示されるレベルと同じレベルである。「仮予約日時」、「第二希望予約日時」、および「本予約日時」の各フィールドには、この時点では何も示されない。
【００６２】
図３の予約可能枠検索部１０３は、紹介状に係る患者のための診察の予約が可能である診察時間枠の検索の処理を行う。予約画面表示処理部１０４は、予約の操作のための画面を液晶ディスプレイ１０ｆに表示させる処理を行う。スケジューリング処理部１０５は、患者の患者コードなどを図８のスケジュールテーブルＴＬのセルに書き込むことによって、患者の診察のスケジューリングを行う。つまり、予約可能枠検索部１０３、予約画面表示処理部１０４、およびスケジューリング処理部１０５は、紹介状に係る患者の診察の予約の処理を行う。
【００６３】
この処理の間、従業員は、その患者に電話を掛けるなどして、その患者と連絡を取りながら、診察スケジュール管理装置１を操作する。
【００６４】
診察の予約の処理の方法および従業員による操作の仕方は、患者の緊急性レベルによって異なる。以下、診察の予約の処理の手順および従業員による操作を、図１１および図１２に示すフローチャートを参照しながら、詳細に説明する。
【００６５】
その患者の患者予約データＤＴＦ（図９参照）の「現緊急性レベル」フィールドに示される緊急性レベル（以下、「現緊急性レベル」と記載する。）が「１」よりも低い場合つまり「２」〜「９」のいずれかである場合は、図１１のフローチャートに示す手順で、その患者の予約の処理などが進行する。
【００６６】
予約可能枠検索部１０３は、その患者が今から何日以内に診察を受けるべきであるかをチェックし、それまでの期間の空いている診察時間枠を、その患者の推定病名に係る器官の診察を担当する診療科のスケジュールテーブルＴＬの中から検索する（図１１の＃３１１）。何日以内に診察を受けるべきであるかは、その患者の推定病名の予約規則データＤＴＤ（図７参照）の「診察待許容期間」を参照することによって知ることができる。
【００６７】
予約画面表示処理部１０４は、予約可能枠検索部１０３によって検索された各診察時間枠の日時を液晶ディスプレイ１０ｆに表示させる（＃３１２）。
【００６８】
なお、従業員が所定のコマンドを入力するごとに、予約画面表示処理部１０４は、その患者の患者コード、氏名、電話番号、および電子メールアドレスなどを表示する。これにより、従業員は、その患者の情報を必要に応じていつでも確認することができる。
【００６９】
ここで、従業員は、空いている診察時間枠の日時をその患者に伝え、希望の診察時間枠を２つ回答してもらう。そして、画面上の２つの診察時間枠それぞれの領域をクリックするなどして、２つの診察時間枠を診察スケジュール管理装置１に対して指定する。
【００７０】
スケジューリング処理部１０５は、２つの診察時間枠の指定を受け付けると（＃３１３）、早いほうの診察時間枠への仮予約を行う（＃３１４）。具体的には、そのスケジュールテーブルＴＬの中の、その診察時間枠のセルに、その患者の患者コードおよび現緊急性レベルを書き込む。また、その患者の患者予約データＤＴＦの「仮予約日時」に、その診察時間枠の日時を書き込む。
【００７１】
さらに、スケジューリング処理部１０５は、遅いほうの診察時間枠を予備として押さえる処理を行う（＃３１５）。具体的には、そのスケジュールテーブルＴＬの中の、その診察時間枠のセルに、その患者の患者コードおよび「第二」を書き込む。また、その患者の患者予約データＤＴＦの「第二希望予約日時」に、その診察時間枠の日時を書き込む。
【００７２】
以上の処理によって、医療機関Ｘが紹介状を受け取った際の、現緊急性レベルが「２」〜「９」の場合の患者の診察の予約の処理が完了する。
【００７３】
後に説明するように、仮予約日時の所定の日前（本実施形態では、５日前）になったら、その患者の診察の診察時間枠は、原則として、指定した２つの診察時間枠のうちの早いほうに確定する。つまり、本予約がなされる。ただし、まだ所定の日前になるまでは、遅いほうの診察時間枠に変更される可能性がある。
【００７４】
一方、その患者の現緊急性レベルが「１」である場合は、図１２のフローチャートに示す手順で、その患者の予約の処理が進行する。
【００７５】
予約可能枠検索部１０３は、そのスケジュールテーブルＴＬの中の、直近の開業日の空いている診察時間枠を検索する（図１２の＃３２１）。空いている診察時間枠があれば（＃３２２でＹｅｓ）、予約画面表示処理部１０４は、検索された各診察時間枠の日時を液晶ディスプレイ１０ｆに表示させる（＃３２３）。
【００７６】
ここで、従業員は、空いている診察時間枠の日時をその患者に伝え、希望の診察時間枠を１つ回答してもらう。そして、画面上のその診察時間枠の領域をクリックするなどして、その診察時間枠を診察スケジュール管理装置１に対して指定する。
【００７７】
スケジューリング処理部１０５は、その診察時間枠の指定を受け付けると、その診察時間枠にその患者の予約を入れる（＃３２４）。具体的には、そのスケジュールテーブルＴＬの中の、その診察時間枠のセルに、その患者の患者コードおよび現緊急性レベルを書き込む。また、その患者の患者予約データＤＴＦの「本予約日時」に、その診察時間枠の日時を書き込む。
【００７８】
直近の開業日に空いている診察時間枠がない場合は（＃３２２でＮｏ）、その患者の推定病名の病気の診察待許容期間（図７参照）にまで検索範囲を広げて、空いている診察時間枠を検索する（＃３２５）。空いている診察時間枠があれば（＃３２６でＹｅｓ）、予約画面表示処理部１０４は、検索された各診察時間枠の日時を液晶ディスプレイ１０ｆに表示させる（＃３２７）。
【００７９】
ここで、従業員は、空いている診察時間枠の日時をその患者に伝え、希望の診察時間枠を１つ回答してもらう。そして、その診察時間枠を診察スケジュール管理装置１に対して指定する。
【００８０】
スケジューリング処理部１０５は、その診察時間枠の指定を受け付けると、ステップ＃３２４の場合と同様に、その診察時間枠にその患者の予約を入れる（＃３２８）。
【００８１】
診察待許容期間にまで検索範囲を広げても空いている診察時間枠がない場合は（＃３２６でＮｏ）、その検索範囲の中から、最も低い緊急性レベルを示すセルを検索する（＃３２９）。ただし、既に予約の日時が確定しているもの、つまり、本日から５日後までのセルおよび緊急性レベルとして「１」を示すセルは、検索の対象から除外する。
【００８２】
予約画面表示処理部１０４は、検索された診察時間枠の日時を液晶ディスプレイ１０ｆに表示させる（＃３３０）。
【００８３】
ここで、従業員は、その診察時間枠の日時をその患者に伝え、その日時にその患者が来院できることを確認する。そして、その旨を診察スケジュール管理装置１に入力する。
【００８４】
すると、スケジューリング処理部１０５は、その診察時間枠に仮予約をしていた他の患者の予約を、当該他の患者の第二希望の予約の日時（当該他の患者の患者予約データＤＴＦの「第二希望予約日時」フィールドに示される日時）の診察時間枠に移動させ（＃３３１）、これによって空いた診察時間枠に、今回の処理対象の患者の予約を入れる（＃３３２）。
【００８５】
この際に、スケジューリング処理部１０５は、当該他の患者および今回の処理対象の患者それぞれの患者予約データＤＴＦを、例えば図１３のように、更新する。当該他の患者の「本予約日時」フィールドに第二希望の診察時間枠の日時を書き込み、現緊急度レベル」フィールドを「１」に書き換える。今回の処理対象の患者の患者予約データＤＴＦの「本予約日時」に、ステップ＃３２４の場合と同様に、空けてもらった診察時間枠の日時を書き込む。
【００８６】
また、スケジューリング処理部１０５は、そのスケジュールテーブルＴＬを図１４のように更新する。当該他の患者の第二希望の診察時間枠のセルに、当該他の患者の患者コードおよび更新後の現緊急性レベルを書き込む。空けてもらった診察時間枠のセルを、今回の処理対象の患者の患者コードおよび現緊急性レベルに書き換える。
【００８７】
なお、緊急性レベルが「１」である場合は、患者に希望を聞いたり確認を取ったりすることなく、先に自動的に予約の処理を行ってもよい。そして、事後的に患者に連絡してもよい。
【００８８】
図３の日次処理部１０６は、毎日の所定の時刻（例えば、開業時刻の１時間前）に、次のような日次処理を実行する。
【００８９】
日次処理部１０６は、各予約患者テーブルＴＹについて、現緊急性レベルを更新する処理を、図１５に示すフローチャートの手順で行う。
【００９０】
日次処理部１０６は、予約患者テーブルＴＹの１番目の患者の患者予約データＤＴＦに注目する（＃３４１）。その患者予約データＤＴＦの「設定日」フィールドおよび「現緊急性レベル」フィールドの値をチェックする（＃３４２）。
【００９１】
現緊急性レベルが「１」より低ければ（＃３４３でＹｅｓ）、現在の日付と設定日との差（日にちの間隔）を算出し、その差が、その患者の推定病名の予約規則データＤＴＤ（図７参照）の「レベル更新タイミング」フィールドに示される日数の整数倍であれば（＃３４５でＹｅｓ）、その予約規則データＤＴＤの「更新レベル数」フィールドに示される数だけ、現緊急性レベルを高くする（＃３４６）。
【００９２】
整数倍でない場合は（＃３４５でＮｏ）、更新は行わない。また、現緊急性レベルが「１」であれば（＃３４３でＮｏ）、その患者の現緊急性レベルをもう上げられないので、更新は行わない。なお、スケジュールテーブルＴＬに登録されている、その患者の緊急性レベルも同様に更新しておく。
【００９３】
残りの未注目の患者の患者予約データＤＴＦの現緊急性レベルについても同様に、更新の処理を行う。
【００９４】
また、日次処理部１０６は、本日より５日先の日の診察時間枠に入っている予約を確定させる。すなわち、「仮予約日時」フィールドに本日より５日先の日を示しかつ「本予約日時」フィールドに何の日時も示さない患者予約データＤＴＦを検索する。そして、その患者予約データＤＴＦの「本予約日時」フィールドに、その「仮予約日時」フィールドに示される日時を書き込む。
【００９５】
そして、確定させた予約の情報を液晶ディスプレイ１０ｆに表示させる。従業員は、各予約に係る患者に電話を掛けるなどして、正式な予約の日時を通知する。または、電子メールによって自動的に通知してもよい。
【００９６】
また、日次処理部１０６は、所定の日数（例えば、２８日）先の日の各診察時間枠のセルを、スケジュールテーブルＴＬに追加する。
【００９７】
図１６は診察スケジュール管理装置１の全体的な処理の流れの例を説明するフローチャートである。
【００９８】
次に、紹介状に係る患者の予約のための全体的な処理の流れを、図１６のフローチャートを参照しながら説明する。
【００９９】
診察スケジュール管理装置１は、毎日所定の時刻になるごとにまたは紹介状のデータを受信するごとに、次のような処理を実行する。
【０１００】
診察スケジュール管理装置１は、毎日所定の時刻になったら（図１６の＃１１でＹｅｓ）、各患者の現緊急性レベルを更新する処理（＃１２）、予約を確定する処理（＃１３）、および先の日の診察時間枠を追加する処理を実行する（＃１４）。現緊急性レベルを更新する処理の手順は、前に図１５で説明した通りである。
【０１０１】
または、診察スケジュール管理装置１は、紹介状のデータを受信すると（＃１５）、前に図１０で説明した方法でその紹介状に係る患者の病名を推定し緊急性レベルを算出する処理を行う（＃１６）。
【０１０２】
そして、その病名（推定病名）および緊急性レベルに応じて、その患者の予約の処理を行う。緊急性レベルが「１」よりも低い場合は（＃１７でＹｅｓ）、前に図１１で説明した手順で予約の処理を行う（＃１８）。緊急性レベルが「１」である場合は（＃１７でＮｏ）、前にＬで説明した手順で予約の処理を行う（＃１９）。
【０１０３】
本実施形態によると、緊急を要する患者がいる場合に予約の調整を従来よりも好適にかつ容易に行うことができる。特に、予約済の患者の緊急性レベルが、時間が経つに連れて高まるので、当初の緊急性レベルが低い患者であっても的確に扱うことができる。
【０１０４】
また、他の医療機関からの紹介を受けた患者の緊急性のレベルを従来よりも簡単にかつ的確に判別することができる。よって、重篤な患者であるにも関わらず予約の時期が遅くなったり、軽微な症状の患者であるにも関わらず他の患者よりも優先的に予約の時期が早くなったりするなどのアンバランスを、的確に解消することができる。
【０１０５】
また、紹介者と医療機関Ｘとのコネクションの強さに左右されないので、さらに一層、的確な予約の調整を行うことができる。
【０１０６】
本実施形態では、紹介状に記載されている病状に基づいて推定病名および緊急性レベルを求めたが、他の医療機関の医師が診断した病名に基づいて行ってもよい。または、レントゲン写真などの画像や心音などの音声に基づいて行ってもよい。または、ＭＥＤＩＳ−ＤＣやＳＮＯＭＥＤＯなどのデータベースを用いて推定病名および緊急性レベルを求めてもよい。
【０１０７】
本実施形態では、緊急性レベルが「１」の患者の予約を新たに行う際に、空いている診察時間枠がなければ、所定の期間の中の、最も緊急性レベルの低い他の患者の診察時間枠を譲ってもらったが、所定の緊急性レベル（例えば、「６」）未満の他の患者の診察時間枠の中から任意に選択できるようにしてもよい。
【０１０８】
本実施形態では、診察の予約を行う場合を例に説明したが、検査または入院などの予約を行う場合にも、本発明を適用することができる。
【０１０９】
その他、診察スケジュール管理装置１の全体または各部の構成、処理内容、処理順序、マスタ、テーブルの構成などは、本発明の趣旨に沿って適宜変更することができる。
【図面の簡単な説明】
【０１１０】
【図１】診察スケジュール管理装置とスキャナとの接続の例を示す図である。
【図２】診察スケジュール管理装置のハードウェア構成の例を示す図である。
【図３】診察スケジュール管理装置の機能的構成の例を示す図である。
【図４】担当診療科マスタの例を示す図である。
【図５】疾病疑義器官マスタの例を示す図である。
【図６】推定病名マスタの例を示す図である。
【図７】予約規則マスタの例を示す図である。
【図８】スケジュールテーブルの例を示す図である。
【図９】予約患者テーブルの例を示す図である。
【図１０】病名推定処理の流れの例を説明するフローチャートである。
【図１１】普通患者予約処理の流れの例を説明するフローチャートである。
【図１２】緊急患者予約処理の流れの例を説明するフローチャートである。
【図１３】予約患者テーブルの更新の例を示す図である。
【図１４】スケジュールテーブルの更新の例を示す図である。
【図１５】現緊急性レベル更新処理の流れの例を説明するフローチャートである。
【図１６】診察スケジュール管理装置の全体的な処理の流れの例を説明するフローチャートである。
【符号の説明】
【０１１１】
１  診察スケジュール管理装置（予約管理装置）
１０１  患者病状情報取得部（病状データ入力手段）
１０２  病名推定処理部（レベル判別手段）
１０５  スケジューリング処理部（予約調整処理手段）
１０６  日次処理部（レベル更新手段）
１２２  スケジュールテーブル記憶部（予約日時記憶手段）
１２３  患者マスタ記憶部（レベル記憶手段）
ＤＴＦ  患者予約データ
ＴＬ  スケジュールテーブル
【図１】
0005176653.tif 000002
【図２】
0005176653.tif 000003
【図３】
0005176653.tif 000004
【図４】
0005176653.tif 000005
【図５】
0005176653.tif 000006
【図６】
0005176653.tif 000007
【図７】
0005176653.tif 000008
【図８】
0005176653.tif 000009
【図９】
0005176653.tif 000010
【図１０】
0005176653.tif 000011
【図１１】
0005176653.tif 000012
【図１２】
0005176653.tif 000013
【図１３】
0005176653.tif 000014
【図１４】
0005176653.tif 000015
【図１５】
0005176653.tif 000016
【図１６】
0005176653.tif 000017