JP3888995B2 - 情報管理システム - Google Patents

Description

本発明は、情報管理システムに関し、特に、診療情報に関するデータベース、その他のデータベースを管理するサーバとデータベースに対するアクセスが可能なクライアントとを備える情報管理システムの障害発生時の保証に関する技術に関する。

データベースを管理するサーバとこのデータベースにアクセス可能なクライアントを備える情報管理システムでは、データの真正性、見読性、保存性などが求められる。このために、サーバ、ネットワーク、クライアントで発生する種々のソフトウェア障害やハードウェア障害に対する対策を講じる必要がある。

近年、病院などの医療施設では、患者の受付業務、診療情報や監査情報の入出力、会計業務などのあらゆる部門で多くのコンピュータが導入されている。各部門の扱うデータの整合性を図り業務の効率化を図るために、このような診療情報をサーバで一括して管理し、各部門に設置したクライアントからサーバの管理するデータベースにアクセスすることが考えられる。

診療情報を電子化した場合には、上述した真正性、見読性、保存性を確保することはもちろん、プライバシー保護が必要となってくる。見読性及び保存性の確保としては、端末のモニタやプリンタへの出力が可能であり、必要に応じて速やかに参照することが可能であり、継続的にデータの参照が可能であり、確実なバックアップが可能であるなどの要求を満たす必要がある。また、真正性の確保としては、利用者認証、改竄防止、混同防止、履歴の保存などの要件を満たす必要がある。さらに、プライバシー保護の観点では、システムセキュリティ、ネットワークセキュリティ、アクセス制御、ロギング（履歴の保存）などの要件を満たす必要がある。

このような観点に基づいて、従来技術とその問題点について以下に考察する。

システムログイン時には、通常、ユーザＩＤとユーザＩＤ毎に設定されたパスワードの入力を求め、これらが一致した場合にのみログインを認めるように構成される場合が多い。一旦設定されたパスワードは変更されることが少なく、このパスワードがなんらかの方法で漏洩した場合、いわゆる「なりすまし」などの不正行為を防止することが困難である。特に、病院などの診療施設では、スタッフの入れ替わりが激しく、現在病院内に存在しないスタッフのユーザＩＤおよびパスワードが使用可能状態になったままになるおそれもある。このように、不正なアクセスにより情報が漏洩することやデータの改竄されることを防止する必要がある。

本発明の目的は、システムログイン時に使用するパスワードを所定期間で変更させて、不正に入手したパスワードによるアクセスを防止することにある。

本発明に係る情報管理システムは、システムログイン時に使用する第１パスワードを設定させる第１パスワード設定手段と、第１パスワードを変更するための第２パスワードを設定させる第２パスワード設定手段と、第１パスワードの設定または変更からの経過時間をカウントする有効期限管理手段と、有効期限管理手段がカウントする経過時間が所定値を超えた場合または第１パスワードが所定回数誤って入力されたことを検出した場合に、対応するユーザIDを使用不可状態にする手段と、使用不可能状態であるユーザIDに対して、失念フラグの設定および第２パスワードを第１パスワードにコピーする旨の指示を受け付けて、失念フラグを設定するとともに第２パスワードを第１パスワードにコピーする失念フラグ設定手段と、失念フラグが設定されているとき、有効期限管理手段がカウントする経過時間が所定値を超える前に第１パスワードの再設定が行われた場合に失念フラグをリセットし、有効期限管理手段がカウントする経過時間が所定値を超えた場合に第１パスワードを無効にする第１パスワード再設定手段とを備える。

ここで、第１パスワードは診療情報に関するシステムにログインするためのものとすることができる。

本発明に係る情報管理システムのパスワード管理方法は、システムログイン時に使用する第１パスワードと第１パスワードを変更するための第２パスワードを設定する旨の指示を受け付けて、それぞれ第１パスワード設定手段および第２パスワード設定手段が第１パスワードおよび第２パスワードを設定する段階と、第１パスワードの設定または変更があった場合に、有効期限管理手段がその時からの経過時間のカウントを開始する段階と、有効期限管理手段によりカウントされる第１パスワードの設定または変更からの経過時間が所定値を超えたかあるいは第１パスワードが所定回数誤って入力されたと判断した場合に、ユーザIDを使用不可状態にする手段が対応するユーザIDを使用不可状態にする段階と、失念フラグ設定手段が、使用不可能状態であるユーザIDに対して、失念フラグの設定および第２パスワードを第１パスワードにコピーする旨の指示を受け付けて、失念フラグを設定するとともに第２パスワードを第１パスワードにコピーする段階と、失念フラグが設定されており、かつ第２パスワードが第１パスワードにコピーされてからの経過時間が所定値を超える前に第１パスワードの変更がされた場合に、第１パスワード再設定手段が失念フラグをリセットする段階と、失念フラグが設定されており、かつ第２パスワードが第１パスワードにコピーされてからの経過時間が所定値を超えた場合に、第１パスワード再設定手段が第１パスワードを無効にする段階とを備える。

ここで、第１パスワードは診療情報に関するシステムにログインするためのものとすることができる。

本発明では、このような情報管理システムのパスワード管理方法のプログラムを記録する記録媒体を提案する。

ここで、記録媒体とは、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、CD-ROM、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが想定できる。

本発明では、システムログイン時に使用するパスワードを所定期間で変更させて、不正に入手したパスワードによるアクセスを防止するができる。予め登録してある第２パスワードを用いて第１パスワードの更新を行うことにより、第１パスワードを不正に取得した者がこの第１パスワードを更新することを防止できる。

〔概略構成〕
本発明の１実施形態が採用される診療情報管理システムについて概要構成を図１に示す。

病院内には、たとえばギガビット・イーサネット（登録商標）などで構成される基幹ＬＡＮ１が設けられている。この基幹ＬＡＮ１には、各種サーバおよびクライアント端末が接続されている。

主なサーバとしては、電子カルテを含む診療情報を管理するＩＩＭＳサーバ１１、医事会計サーバ１２、イントラネットサーバ１３、放射線事務（ＲＩＳ）サーバ１４、物流管理サーバ１５、資源・ＬＡＮ管理サーバ１６、レポートサーバ１７などが基幹ＬＡＮ１に接続されている。

また、事務系クライアント２１、医療系クライアント２２、画像系クライアント２３などのクライアント端末が接続されている。

基幹ＬＡＮ１には、さらに、再来自動受付機２５、ルータ２７を介してインターネット接続を行う場合のファイアウォール２６などが接続されている。

基幹ＬＡＮ１には他システム３０が接続されており、各サーバ間でのデータの共有が可能となっている。他システム３０には、たとえば、病理システム３１、院内表示システム３２、栄養管理システム３３、注射管理システム３４、調剤システム３５、輸血管理システムを含む検査システム３６、財務管理システム３７、労務管理システム３８などが含まれる。

レポートサーバ１７は画像系ＬＡＮ２を介して、非ＣＲ系画像サーバ１８、ＣＲ系画像サーバ１９に接続されている。この画像系ＬＡＮ２にはさらに読影用クライアント２４が接続されている。また、非ＣＲ系画像サーバ１８およびＣＲ系画像サーバ１９は、モダリティ系ＬＡＮ３を介して他システム３０中の各種撮影装置群３９のシステムに接続されている。

〔クラスタリングシステムのバックアップ〕
診療情報を管理するＩＩＭＳサーバ１１は、事務系クライアント２１、医療系クライアント２２、画像系クライアント２３などのクライアント端末に診療情報のデータを利用したシステムを提供するものであって、通常運用時に用いられる主系サーバと、主系サーバの異常時に用いられる従系サーバとを備えるクラスタ構造となっている。このクラスタリングシステムについて、概略構成を図２に示す。

図２に示すように、ＩＩＭＳサーバ１１は通常運用時に用いられる主系サーバ５１と、主系サーバ５１の異常時に用いられる従系サーバ５３とを備えている。

主系サーバ５１は基幹データベースＡを格納する記憶手段５２と接続されている。記憶手段５２は、ディスク・アレイなどの記録媒体で構成されており、診療情報などのデータベースを含む基幹データベースＡを格納している。主系サーバ５１は、事務系クライアント２１、医療系クライアント２２、画像系クライアント２３などからの要求に応じて記憶手段５２内の基幹データベースＡ中のデータを参照させ、各クライアントから送出されてきた更新データを記憶手段５２内の基幹データベースに反映するように構成される。

従系サーバ５３は、基幹データベースＡ’を格納する記憶手段５４と接続されている。記憶手段５４は記憶手段５２と同様のディスク・アレイなどの記録媒体で構成されている。この記憶手段５４に格納されている基幹データベースＡ’は、記憶手段５２に格納されている基幹データベースＡの写しである。

主系サーバ５１および従系サーバ５３には、ディスク・アレイなどの記録媒体で構成される共通ディスク５５が接続されている。この共通ディスク５５には、主系サーバ５１が記憶手段５２内の基幹データベースＡの内容を更新する際の更新データが書き込まれる連絡ファイルが構成される。この連絡ファイル内に書き込まれる更新データは、従系サーバ５３によって逐次記憶手段５４の基幹データベースＡ’に反映される。

また、記憶手段５４に格納されている基幹データベースＡ’は、ディスク・アレイなどの記録媒体で構成される記憶手段５６にバックアップＡ”として格納される。記憶手段５６はたとえば従系サーバ５３によって制御されており、所定の時間間隔（たとえば、１日
１回）で基幹データベースＡ’のバックアップＡ”が格納される。このとき、共通ディスク５５の連絡ファイルから記憶手段５４の基幹データベースＡ’への更新データの転送は停止する。この間、主系サーバ５１からの更新データは、共通ディスク５５の連絡ファイルに貯めておき、基幹データベースＡ’のバックアップＡ”が記憶手段５５への格納が終了した時点で、連絡ファイルから記憶手段５４の基幹データベースＡ’への更新データの転送を再開するように構成する。

主系サーバ５１になんらかの障害が発生した場合には、従系サーバ５３にシステムを切り換えて、従系サーバ５３に制御されている記憶手段５４内の基幹データベースＡ’を利用してシステム提供を行う。この場合には、主系サーバ５１でシステム提供を行っていたときの更新されたデータが連絡ファイルを介して逐次基幹データベースＡ’に反映されており、主系サーバ５１に障害が発生した時点のデータによるシステム提供が可能となる。

主系サーバ５１の障害が発生してサーバを切り換えることにより、主従が切り換えられることとなり、現在システム提供を行っているサーバから基幹データベースに対する更新データは、同時に連絡ファイルに送信されて現在システム提供を行っていないサーバ配下の基幹データベースの更新データとされる。

記憶手段５６に格納されている基幹データベースＡ’のバックアップＡ”は、 オンラインとは切り離された状態であり、適宜バックアップを作成することができる。たとえば、データベース中のアクティブでないデータについて、磁気テープ、磁気ディスク、その他の外部媒体５７にバックアップを作成することが考えられ、このバックアップ作業は基幹データベースＡ’からのバックアップ作業中を除いていつでも可能である。

上述のシステムについてその動作を図３に基づいて説明する。ここでは、ＩＩＭＳサーバ１１内の主系サーバ５１、従系サーバ５３を一体とみなした場合の動作として説明する。

ステップＳ１１では、クライアント端末からのアクセスがあったか否かを判別する。事務系クライアント２１、医療系クライアント２２、画像系クライアント２３などからアクセスがあった場合には、ステップＳ１２に移行する。ステップＳ１２では、主系サーバ５１により記憶手段５２内の基幹データベースＡを利用したシステム提供を実行する。

ステップＳ１３では、クライアント端末からのデータ更新があったか否かを判別する。クライアント端末から基幹データベースＡに対するデータ更新があった場合には、ステップＳ１４に移行する。ステップＳ１４では、クライアント端末からの更新データを受け付けて記憶手段５２内の基幹データベースＡを更新する。このとき同時に、更新が正常に完了したことを確認して、共通ディスク５５の連絡ファイルに更新データを書き込む。

連絡ファイルに書き込まれる更新データの例としては、カルテ情報（患者の診療記録など）、指示情報（検査や処方など）、部門実施情報（指示情報に対する実施内容）、病名情報、プロファイル情報（患者の個人情報など）、テンプレート情報（診断書などの雛形）、受付情報（来院患者に関する情報）、サマリ情報（入院患者に対して退院時に入院中の診療記録を要約として作成したものなど）などがある。これらの情報の単位は、基幹データベースの構成に応じて変更が可能である。

ステップＳ１５では、従系サーバ５３により、共通ディスク５５の連絡ファイル内の更新データにより、記憶手段５４に格納されている基幹データベースＡ’を更新する。

ステップＳ１６では、バックアップ時期に到達したか否かを判別する。バックアップ時
期は、記憶手段５４内の基幹データベースＡ’のバックアップＡ”を記憶手段５６に格納する時期であり、たとえば１日１回所定の時刻に定めることができる。このバックアップ時期であると判断した場合には、ステップＳ１７に移行する。ステップＳ１７では、共通ディスク５５の連絡ファイルから記憶手段５４の基幹データベースＡ’への更新データの転送を停止する。ステップＳ１８では、記憶手段５４内の基幹データベースＡ’のバックアップＡ”を記憶手段５６に格納する。ステップＳ１９では、共通ディスク５５の連絡ファイルから記憶手段５４の基幹データベースＡ’への更新データの転送を再開する。

ステップＳ２０では、主系サーバ５１に障害が発生したか否かを判別する。主系サーバ５１に障害が発生した場合には、ステップＳ２１に移行する。ステップＳ２１では、主系サーバ５１をネットワークから切り離し、従系サーバ５３によるシステム提供を実行するように、サーバの切り換え処理を行う。

このような構成とすることにより、通常運用時の主系サーバ５１で障害が発生しても、継続してオンラインシステムの提供を行うことができ、バックアップ作成時に業務を停止させることもなくなる。

〔データ参照機能〕
前述したような主系サーバ５１と従系サーバ５３とを備えるクラスタリングシステムにおいて、主系サーバ５１に障害が発生した場合、従系サーバ５３へのシステム移行処理を行う間、基幹データベースへのアクセスができなくなる。また、主系サーバ５１で発生した障害が軽度なものであり従系サーバ５３へのシステム移行を行う必要がない場合であっても、主系サーバ５１の復旧までの間、基幹データベースへのアクセスができなくなる。このように、主系サーバ５１で障害が発生した場合に、少なくとも基幹データベース内のデータを閲覧することができるようなデータ参照ツールを提供する。このデータ参照ツールの概略構成図を図４に示す。

ここでは、たとえば、主系サーバ５１に障害が発生した際に、カルテなどの診療記録を主系サーバ５１の記憶手段５２上にあるデータではなく、従系サーバ５３の記憶手段５４内にあるデータにアクセスするように切り換えることにより、過去の診療記録の参照を最小限保証するように構成する。

ＩＩＭＳサーバ１１は、主系サーバ５１と主系サーバ５１に制御される記憶手段５２、従系サーバ５３と従系サーバ５３に制御される記憶手段５４を備えている。記憶手段５２には基幹データベースＡが格納されており、記憶手段５４には基幹データベースＡの更新データが逐次反映される基幹データベースＡ’が格納されている。また、ＩＩＭＳサーバ１１には、主系サーバ５３における障害発生やその復旧などをクライアント側に通知するための通知手段６２が設けられている。この通知手段６２は、SymfoNETなどで構成することができる。

従系サーバ５３は、接続されるクライアント６０に対して記憶手段５４内に格納された基幹データベースＡ’のデータを閲覧させるためのデータ参照ツール６１を有している。このデータ参照ツール６１は、従系サーバ５３内のシステムを利用することなく、クライアント６０に対して記憶手段５４内のデータを参照させることができるように構成されている。

このデータ参照ツールを用いた動作を図５に示すフローチャートを用いて説明する。

ステップＳ３１では、主系サーバ５１に障害が発生したか否かを判別する。主系サーバ５１に障害が発生したと判断した場合にはステップＳ３２に移行する。ステップＳ３２で
は、主系サーバ５１で発生した障害が軽度であり短時間での復旧が可能であるか否かを判別する。短時間での復旧が可能であると判断した場合にはステップＳ３３に移行し、復旧作業により障害の解除を待機する。ステップＳ３２において短時間の復旧が困難であると判断した場合には、ステップＳ３４に移行する。ステップＳ３４では、主系サーバ５１から従系サーバ５３へシステムを切り換える切換処理を開始する。

ステップＳ３５では、通知手段６２により接続中のクライアント６０に対して、「主系サーバがダウンしました、一時参照のみ使用可能となります。参照系サーバへ接続しますか？」のメッセージを送信する。ステップＳ３６では、送信したメッセージに対してクライアント６０からの確認を待機する。クライアント６０でメッセージ画面に表示される「ＯＫ」ボタンが操作されると、ステップＳ３７に移行する。

ステップＳ３７では、クライアント６０との接続を従系サーバ５３に切り換えてデータ参照ツール６１を起動し、データ参照専用画面の表示を行う。データ参照専用画面では、たとえば、図６に示すように、患者選択画面１０１を表示する。患者選択画面１０１は、受付患者一覧、予約患者一覧、病棟・受持患者一覧、患者カナ検索などの一覧表示部１０２と、詳細情報を参照したい患者ＩＤの入力を受け付ける患者ＩＤ入力部１０３とを備えている。一覧表示部１０２に表示された患者データから選択して患者ＩＤ入力部１０３にその患者ＩＤを入力すると、図７に示すようなその患者のカルテ歴表示画面１１１を表示する。カルテ歴表示画面１１１は、主にＳＯＡ欄１１２とＰ欄１１３とから構成されている。ＳＯＡ欄１１２は、患者の主訴（Subjective）、検査結果などの客観的結果（Objective）、医師の所見（Assessment）などが記載される欄であり、Ｐ欄１１３は、処方箋や再診予約などの方策（Plan）が記載される欄である。これらＳＯＡ欄１１２、Ｐ欄１１３に表示されるデータは、過去に診察を行った際に記録されたものであって、データの更新を行うことはできないようになっている。

ステップＳ３８では、主系サーバ５１の復旧作業が完了したか、あるいは従系サーバ５３への切換処理が完了したかを判別する。復旧作業または切換作業が完了した判断した場合には、ステップＳ３９に移行する。

ステップＳ３９では、通知手段６２により復旧あるいは切換完了のメッセージをクライアント６０に送信する。ステップＳ４０では、クライアント６０からの確認を待機する。クライアント６０においてメッセージ画面で表示される「ＯＫ」ボタンが操作されると、ステップＳ４１に移行する。ステップＳ４１では、復旧した主系サーバ５１あるいは切換が完了した従系サーバ５３によりシステムを復帰する。

データ参照ツール６１が起動している間は、クライアント６０で参照しているデータの一部をローカル参照テーブルとしてクライアント６０に保有させておく。このローカル参照テーブルの一例を図８に示す。ここでは、ローカル参照テーブル２０１は、患者ＩＤ（ＰＩＤ）、患者氏名カナ（ＰＮＡＭＥＫ）、患者氏名（ＰＮＡＭＥ）、性別（ＳＥＸ）、生年月日（ＢＩＲＴＨ）などの項目を備えている。ステップＳ４１でシステムが復帰した際に、サーバ側からクライアント６０が保有するローカル参照テーブル２０１を取得し、その患者ＩＤなどから該当するデータが自動的に展開されるように構成することができる。

また、クライアント６０側で参照しているデータに対する更新データを受け付け、クライアント６０側のローカルデータベースに記憶しておくように構成することも可能である。この場合も、ステップＳ４１におけるシステム復帰時に、サーバ側からクライアント６０のローカルデータベースの更新データを取得し、主系サーバ５１が復旧した後の基幹データベースへ反映する更新データとすることが可能である。

このように構成することによって、主系サーバ５１に障害が発生しても基幹データベースの見読性を継続的に維持することが可能となり、診療業務の遅滞を招くことを防止できる。

〔受付情報表示〕
ＩＩＭＳサーバ１１では、事務系クライアント２１や再来自動受付機２５などで受け付けた患者の受付情報や予約情報などを受付データベースとして管理している。ＩＩＭＳサーバ１１や基幹系ＬＡＮ１中に障害が発生して、受付データベースを閲覧できない状態となると業務に支障をきたすこととなる。このような場合に備えて、受付データベース中のデータを必要に応じて収集してこれを表示することを可能とする受付表示システムを設けている。この受付表示システムの概略構成を図９に示す。

ＩＩＭＳサーバ１１内の基幹データベースは、事務系クライアント２１や再来自動受付機２５などから入力された受付情報や予約情報を管理する受付データベース７１を含んでいる。

各診療科毎に基幹ＬＡＮ１を介してＩＩＭＳサーバ１１と接続されるマスタ端末７２が設置されている。このマスタ端末７２には、ＩＩＭＳサーバ１１内の受付データベース７１から必要なデータを収集する収集ツール７３と、収集ツール７３で収集したデータをテキストファイル形式で保存する記憶手段７４とを備えている。

医療系クライアント２２などの診療端末７５は、同じ診療科のマスタ端末７２に接続されており、マスタ端末７２の記憶手段７４内のデータを表示するための受付情報表示ツール７６を備えている。

マスタ端末７２の収集ツール７３は、定期的にサーバ１１上の受付データベース７１から受付データの収集を行う。たとえば、５分間隔で受付データベース７１にデータベースアクセスルーチンを介してアクセスを行い、その診療科に関する本日分の受付情報を取得するように構成できる。収集ツール７３によって収集した受付情報は、テキストファイル形式で記憶手段７４に格納される。

通常運用時では、各クライアントからＩＩＭＳサーバ１１にアクセスを行って、受付データベース７１から受付情報の一覧表示を行うことが可能となっている。ＩＩＭＳサーバ１１に障害が発生した場合には、この受付データベース７１に対するアクセスができなくなる。この場合には、受付情報表示ツール７６を起動して同じ診療科のマスタ端末７２にアクセスを行い、記憶手段７４から最新の受付情報を取得して診療端末７５上で表示させることが可能となる。

また、ＩＩＭＳサーバ１１がダウンしている場合には、電子カルテなどの診療情報を利用することもできなくなるので、マスタ端末７２から取得した受付情報に基づいて患者属性、患者特定バーコードなどの患者識別データが入ったカルテフォーマットの様式、指示伝票の様式などを、診療端末７５からプリンタ７７に印刷させるように構成する。

基幹系ＬＡＮ１を含むネットワークに障害が発生している場合には、マスタ端末７２と診療端末７５との間でのデータの入力ができなくなるおそれがある。このような場合には、マスタ端末７２で受付情報の表示を行ったり、カルテフォーマットの様式や指示伝票の様式をプリンタに印刷させるように構成する。

受付情報表示ツール７６によりマスタ端末７２から取得した受付情報の表示画面の一例
を図１０に示す。

受付情報一覧画面１２１は、マスタ端末７２の収集ツール７３が受付データベース７１からデータを収集した日時を表示するデータ収集日時欄１２２を備えている。また、受付患者一覧用タグ１２３、診療受付患者一覧用タグ１２４、救急外来診療状況一覧用タグ１２５、看護婦相談室用タグ１２６などを備えており、それぞれのタグをクリックすることにより各一覧表示を行うことが可能となっている。

受付情報一覧画面１２１の中央には一覧表示部１２９が設けられており、表示条件に合致する受付患者の情報が表示されるように構成されている。この一覧表示部１２９では、受付番号、予約時間、受付時間、状態、患者氏名、患者ＩＤ、区分、受付内容、性別、年齢、予約者、予約先診療科、対診コメントなどの項目が表示されるように構成されている。

受付情報一覧画面１２１の上部には、印刷ボタン１２７が設けられている。印刷ボタン１２８をクリックすることにより、表示されている受付情報の一覧印刷を行うことが可能となっている。ここでは図示していないが、カルテフォーマットの様式での印刷や指示伝票の様式での印刷を、各患者データ毎または表示されている患者データについて一括で指示できるような指示ボタンを設けることも可能である。

マスタ端末７２は各診療科毎に設置することもでき、各フロア毎に設置することもでき、また各部署毎に設置することも可能である。また、各マスタ端末７２の収集ツール７３は、本日分の全受付情報を収集するように構成することも可能であり、また設置場所により必要となる受付情報のみを収集するように構成することが可能である。

このようなマスタ端末７２に設けられた収集ツール７３により受付情報を定期的に収集することによって、サーバに障害が発生した場合やネットワークに障害が発生した場合などのシステムダウン時にあっても、少なくとも障害発生時までの受付情報を再現することができ、診療業務を継続することが可能となる。

〔編集データの復元〕
クライアント側で患者データを編集中にクライアントに障害が発生した場合には、今まで入力したデータ内容が失われてしまうおそれがある。このような編集中のデータをクライアント復旧時に復元する編集データ復元機能について図１１に基づいて説明する。

クライアント端末には、サーバのデータベースにアクセスして患者選択を行い、選択した患者データを取得する患者選択部８１と、選択した患者データの参照・データ更新を行わせるツールボックス８２とを備えている。患者選択部８１により取得した患者データのレジストリ情報は、クライアント端末のハードディスク内のレジストリ格納領域８３に格納される。

レジストリ格納領域８３に格納されるレジストリ情報は、たとえば図１２に示すようなレジストリテーブル２１１とすることができる。ここでは、現在オープンしているアクティブウィンドウ構成、現在オープンしているアクティブ患者データ、データ編集を行っている利用者ＩＤなどの項目を備えている。

ツールボックス８２では、患者選択部８１で選択した患者データを内部メモリで管理し、利用者による編集を受け付ける。このとき、ツールボックス８２で選択している選択患者一覧と、各患者データに相当する共通テーブルをクライアント端末のハードディスク内のワークテーブル８４に格納する。

ツールボックス８２は、たとえば図１４に示すようなカルテ編集画面１４１を介して編集データの入力を受け付ける。カルテ編集画面１４１は、患者ＩＤ表示部１４２、ＳＯＡ表示欄１４３、Ｐ表示欄１４４、指示選択部１４５、編集データ入力部１４６などで構成されている。患者ＩＤ表示部１４２に表示される患者ＩＤや患者氏名などのデータは選択患者一覧に格納され、編集データ入力部１４６で入力される編集データは共通テーブルに格納される。

選択患者一覧は、図８に示すローカル参照テーブル２０１を用いることができ、少なくとも患者ＩＤ（ＰＩＤ）、患者氏名カナ（ＰＮＡＭＥＫ）、患者氏名（ＰＮＡＭＥ）などの項目で構成することができる。

また、共通テーブルの一例を図１３に示す。ここで、共通テーブル２２１は項目名（ＩＮＡＭＥ）、内容（ＴＥＸＴ＿Ｔ）、数量（ＮＵＭ）などの項目で構成することができる。

ツールボックス８２を介して入力される患者データに対する編集データは、ワークテーブル８４内の共通テーブル２２１に逐次反映される。また、患者が新たに追加された場合は、レジストリ情報を内部メモリに格納するとともに、ワークテーブル８４にも格納する。

編集が終了して患者データを閉じた場合には、その閉じた患者データの編集内容は、サーバ側のデータベースに反映される。このとき、ワークテーブル８４内に格納されている選択患者一覧および共通テーブルのデータを削除する。

データ編集中にクライアント端末がダウンした場合には、障害発生時にオープンしていたアクティブウィンドウ、同じく障害発生時にオープンしていた患者データなどのレジストリ情報がレジストリ格納領域８３に保存されており、また、編集中のデータについては共通テーブルとしてワークテーブル８４に保存されている。

障害が発生したクライアント端末が復旧された場合、起動時にツールボックス８２がレジストリ格納領域８３およびワークテーブル８４内を検索し、データが残っている場合には、すべての情報をメモリに格納し、編集の続行を受け付けることが可能となる。

このように構成することによって、電源やシステム障害などによりシステム再起動が発生し、再度オンラインを立ち上げた場合であっても、直前の保持データを再現させることができ、データ再入力の手間を省略することが可能となる。

〔端末使用状況監視〕
クライアント端末の操作履歴を収集してこれを表示・分析する端末使用状況監視機能について説明する。

図１５にその概略構成図を示す。

クライアント９１では、システム起動時に初期画面を表示する初期画面ツール９２を備えている。この初期画面ツール９２はオンラインシステムへのログイン受付時、オンラインシステムからログオフした時にも初期画面を表示する。また、クライアント９１はハードディスク上に稼働状況データを格納する稼働状況格納領域９３を備えている。初期画面ツール９２は、システム起動時、オンラインシステムへのログオン、ログオフ時に、ＯＳで管理している情報を取得し、利用者ＩＤや氏名などの利用者情報を取得して、そのとき
の日付・時刻情報とともに、稼働状況格納領域９３にテキストファイル形式で稼働状況データとして格納する。

稼働状況監視端末９４は、オンライン上に接続されたクライアント端末を利用することができ、端末稼働状況一覧ツール９５を搭載するものである。稼働状況監視端末９４は、各クライアント端末のマシン名を備える端末マスタ９６と、マシン名とＩＰアドレスの対応を格納するマシン名−アドレス対応ファイル９７とを備えている。

クライアントの稼働状況を収集する場合には、図１６に示すフローチャートに基づいて処理を行う。

ステップＳ５１では、端末稼働状況一覧ツール９５を起動し、操作者からの入力に基づいてデータ収集を行うフロアを特定する。ステップＳ５２では、選択されたフロアに設置されているマシン名を端末マスタ９６から取得する。端末マスタ９６では、各フロアに設置されているクライアントのマシン名を管理しており、このデータから選択されたマシン名を得ることができる。

ステップＳ５３では、マシン名−アドレス対応ファイル９７から各クライアントのＩＰアドレスを取得する。マシン名ーアドレス対応ファイル９７では各マシン名とＩＰアドレスとの対応を有しており、端末マスタ９６から取得したマシン名からＩＰアドレスを取得することができる。ステップＳ５４では、取得したクライアントのＩＰアドレスに対してネットワークにログインされているか否かの確認を行う。例えば、ＰＩＮＧコマンドを使用することにより当該ＩＰアドレスに対応づけられたクライアント端末が起動状態であるか否かを判別することが可能となる。

ステップＳ５５では、起動確認ができたクライアントに対して、稼働状況データを送信させる。ここでは、クライアント９１の稼働状況格納領域９３に格納された稼働状況データを、端末稼働状況一覧ツール９５により収集することとなる。ステップＳ５６では、端末稼働状況一覧ツール９５で収集した各クライアントの稼働状況を一覧表示する。ステップＳ５７では、他のフロアの稼働状況一覧を表示するか否かを判別する。操作者により他のフロアの稼働状況一覧表示を行う旨の指示がなされた場合には、ステップＳ５１に移行して同様にして他のフロアの稼働状況を表示させる。

クライアント９１の初期画面ツール９２では、起動時、ログイン時、ログオフ時におけるＯＳ情報や利用者情報を収集しているため、何時、どのようなユーザＩＤによってどのような操作がなされたかの操作履歴を端末稼働状況一覧ツール９５により収集することができる。したがって、ネットワーク内でのトラブルが発生した場合に、各クライアントの使用状況を容易に分析することが可能となる。

また、各クライアント端末の稼働率を把握することにより、効率的な端末配置の計画を可能にする。

上述したように、オンライン接続されたクライアント端末の１つに端末使用状況監視機能を持たせて稼働状況監視端末９４とすることも可能であり、また、ＩＩＭＳサーバ１１側でこのような機能を持たせ、ＩＩＭＳサーバ１１に直接接続される端末上で操作および表示させることが可能な構成とすることもできる。

〔パスワード管理機能〕
オンラインシステムへのログイン時に用いられるパスワードの管理機能について説明する。

このオンラインシステムの利用者マスタは、図１７に示すような利用者マスタテーブル２３１を備えている。利用者マスタテーブル２３１は、ユーザＩＤ、第１パスワード、第２パスワード、経過日数、失念フラグなどの項目を備えている。

第２パスワードは、特に規約がなく利用者各自が忘れにくい内容のものであり、予め利用者に封書で提出させたものを設定している。第１パスワードは、クライアント端末で設定してあるパスワード変更ツールにより変更可能なものであり、第２パスワードを用いてこの第１パスワードの変更が可能となる。

経過日数は、第１パスワードが設定・変更からの経過日数をカウントするものであって、第１パスワードが変更されるとリセットされる。第１パスワードを無効にする期限は３ヶ月に設定されており、経過日数の値が、期限の２週間前になると利用者によるオンライン使用時に警告を表示する。

経過日数の値が３ヶ月を過ぎた場合やオンライン使用時の第１パスワードの入力間違いが３回以上あった場合には、そのユーザＩＤによる使用不可状態となる。利用者から管理者への連絡があった場合には、管理者がマスタ管理ツールにより、失念フラグを設定するとともに第２パスワードの値を第１パスワードにコピーする。失念フラグが設定されている場合には、第１パスワードを無効にする期限は１日に設定され、利用者による第１パスワードの変更がなされると失念フラグをリセットするとともに第１パスワードを無効にする期限も３ヶ月に設定される。失念フラグが設定された状態で、経過日数が１日を超えてしまった場合には、第１パスワードが無効とされ以後このユーザＩＤによるオンライン使用が禁止される。

この動作を図１８のフローチャートに基づいて説明する。

ステップＳ６１では、第１パスワード、第２パスワードの設定を行う。第２パスワードの設定は、上述したように、特に規約がなく利用者各自が忘れにくい内容のものを予め利用者に封書で提出させて設定する。第１パスワードはこの第２パスワードを用いて変更可能であり、利用者により変更がなされる毎に、経過日数の値がリセットされる。

ステップＳ６２では、経過日数の値が３ヶ月を過ぎたか、あるいはオンライン使用に３回以上の第１パスワードの入力ミスがあったかを判別し、このような場合にはステップＳ６３に移行する。

ステップＳ６３では、このユーザＩＤによるオンライン使用不能状態とし、利用者からの連絡があった場合に失念フラグを設定する。ステップＳ６４では、第２パスワードの内容を第１パスワードにコピーする。ステップＳ６５では、第１パスワードを無効にする期限を１日に設定する。

ステップＳ６６では、利用者による第１パスワードの変更があったか否かを判別する。利用者による第１パスワードの変更があった場合にはステップＳ６７に移行する。ステップＳ６７では、第１パスワードを無効にする期限を３ヶ月に設定し、経過日数をリセットする。

ステップＳ６６において利用者による第１パスワードの変更がなかった場合、ステップＳ６８に移行する。ステップＳ６８では、第１パスワードを無効にする期限が過ぎたか否かを判別する。ここでは、１日の期限を超えていた場合にはステップＳ６９に移行する。ステップＳ６９では、第１パスワードを無効にし、このユーザＩＤによるオンライン使用
を禁止する。

このような構成とした場合には、第１パスワードを利用者により定期的に変更させることができ、パスワードの漏洩などによる「なりすまし」を防止することができる。

本発明では、システムログイン時に使用するパスワードを所定期間で変更させて、不正に入手したパスワードによるアクセスを防止するができる。予め登録してある第２パスワードを用いて第１パスワードの更新を行うことにより、第１パスワードを不正に取得した者がこの第１パスワードを更新することを防止できる。

概略構成を示すブロック図。 クラスタリングシステムの制御ブロック図。 バックアップシステムのフローチャート。 データ参照ツールの説明図。 データ参照ツールのフローチャート。 参照専用画面の説明図。 参照専用画面の説明図。 ローカル参照テーブルの説明図。 受付情報表示ツールの説明図。 受付情報一覧画面の説明図。 編集データ復元機能の説明図。 レジストリテーブルの説明図。 共通テーブルの説明図。 カルテ編集画面の説明図。 端末使用状況監視機能の説明図。 端末使用状況監視機能のフローチャート。 利用者マスタテーブルの説明図。 パスワード管理機能のフローチャート。

Claims (5)

1. システムログイン時に使用する第１パスワードを設定させる第１パスワード設定手段と、
   前記第１パスワードを変更するための第２パスワードを設定させる第２パスワード設定手段と、
   前記第１パスワードの設定または変更からの経過時間をカウントする有効期限管理手段と、
   前記有効期限管理手段がカウントする経過時間が所定値を超えた場合または前記第１パスワードが所定回数誤って入力されたことを検出した場合に、対応するユーザIDを使用不可状態にする手段と、
   使用不可能状態であるユーザIDに対して、失念フラグの設定および前記第２パスワードを前記第１パスワードにコピーする旨の指示を受け付けて、失念フラグを設定するとともに第２パスワードを第１パスワードにコピーする失念フラグ設定手段と、
   前記失念フラグが設定されているとき、前記有効期限管理手段がカウントする経過時間が所定値を超える前に前記第１パスワードの再設定が行われた場合に前記失念フラグをリセットし、前記有効期限管理手段がカウントする経過時間が所定値を超えた場合に前記第１パスワードを無効にする第１パスワード再設定手段と、
   を備える情報管理システム。
2. 前記第１パスワードは診療情報に関するシステムにログインするためのものである、請求項１に記載の情報管理システム。
3. システムログイン時に使用する第１パスワードと前記第１パスワードを変更するための第２パスワードを設定する旨の指示を受け付けて、それぞれ第１パスワード設定手段および第２パスワード設定手段が第１パスワードおよび第２パスワードを設定する段階と、
   前記第１パスワードの設定または変更があった場合に、有効期限管理手段がその時からの経過時間のカウントを開始する段階と、
   前記有効期限管理手段によりカウントされる前記第１パスワードの設定または変更からの経過時間が所定値を超えたかあるいは第１パスワードが所定回数誤って入力されたと判断した場合に、ユーザIDを使用不可状態にする手段が対応するユーザIDを使用不可状態にする段階と、
   失念フラグ設定手段が、使用不可能状態であるユーザIDに対して、失念フラグの設定および第２パスワードを第１パスワードにコピーする旨の指示を受け付けて、失念フラグを設定するとともに第２パスワードを第１パスワードにコピーする段階と、
   前記失念フラグが設定されており、かつ前記第２パスワードが第１パスワードにコピーされてからの経過時間が所定値を超える前に前記第１パスワードの変更がされた場合に、第１パスワード再設定手段が前記失念フラグをリセットする段階と、
   前記失念フラグが設定されており、かつ前記第２パスワードが第１パスワードにコピーされてからの経過時間が所定値を超えた場合に、前記第１パスワード再設定手段が前記第１パスワードを無効にする段階と、
   を備える情報管理システムのパスワード管理方法。
4. 前記第１パスワードは診療情報に関するシステムにログインするためのものである、請求項３に記載の情報管理システムのパスワード管理方法。
5. 請求項３または４に記載の情報管理システムのパスワード管理方法のプログラムを記録する記録媒体。

Images