JP2003288256A - 分散処理方法および分散処理システム - Google Patents

Abstract

(57)【要約】 【課題】 通信による経済的コストや時間的コストを軽
減することのできる分散処理方法および分散処理システ
ムを提供する。 【解決手段】 センタシステム２０および分院システム
６０には、同一のデータを持つデータベース３０ａおよ
び３０ｂをそれぞれ設ける。センタシステム２０に設け
られたアプリケーション処理部２４はデータベース３０
ａを用いた処理を行い、分院システム６０に設けられた
アプリケーション処理部６４はデータベース３０ｂを用
いた処理を行う。アプリケーション処理部の停止時に、
インポート／エクスポートサブシステム２２および６２
は、それぞれ下りおよび上りのスナップショットデータ
を生成し、相手方のインポート／エクスポートサブシス
テム６２および２２は、それぞれこれを読み込んで、デ
ータベースに反映する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、分散処理方法お
よび分散処理システムに関する。特に、必要時のみに接
続する通信網を用いた分散処理方法および分散処理シス
テムに関する。

【０００２】

【従来の技術】分散処理システムにおいては、各々の分
散拠点間においてデータの一貫性を維持することが必要
である。ここで、一貫性の維持とは次のようなことをい
う。

【０００３】第１に、複数の拠点において同一のデータ
が参照されることである。つまり、ある拠点において
「Ａ」というデータが参照される場合、処理によって他
のデータで更新されない限り、他の拠点においても
「Ａ」というデータが参照される。

【０００４】第２に、データの変更が伝播されることで
ある。つまり、ある拠点においてある時点で「Ａ」とい
うデータが「Ｂ」と更新されたとき、処理によって他の
データで更新されない限り、他の拠点においてもその後
のいずれかの時点では当該データが「Ｂ」と更新され
る。

【０００５】第３に、同一データの非同期な変更による
矛盾が防止あるいは解消されることである。このため
に、例えば、データの更新に関する排他制御が用いられ
る。

【０００６】従来技術の一つである分散データベース管
理システムは、分散拠点間で通信を行うことにより上記
のようなデータの一貫性を維持している。図１３は、従
来技術による分散データの管理方法を示す参考図であ
る。図１３において、符号１０１および１０２はそれぞ
れコンピュータ、１００はコンピュータ１０１および１
０２を相互に接続するネットワークである。また、１１
１および１１２はそれぞれコンピュータ１０１および１
０２上のデータベースである。データベース１１１およ
び１１２は互いに同一のデータを保持して管理している
ものとする。データベース１１１上のあるデータが更新
される（１）と、データベース１１１に備えられた更新
同期機能がこれを検知してデータベース１１２に通知し
（２）、通知を受けたデータベース１１２に備えられた
更新同期機能がデータベース１１２上の対応するデータ
を更新する（３）。逆に、データベース１１２上のある
データが更新される（４）と、データベース１１２に備
えられた更新同期機能がこれを検知してデータベース１
１１に通知し（５）、通知を受けたデータベース１１１
に備えられた更新同期機能がデータベース１１１上の対
応するデータを更新する（６）。また、例えば両データ
ベース側で独立に同時に同一データの更新が試みられた
場合や通信障害の場合にもデータベース１１１と１１２
との間の一貫性を保つために、上記更新同期機能は２相
コミット等の方法を用いた同期処理を行う。

【０００７】

【発明が解決しようとする課題】上記のような分散デー
タベースを用いて複数の拠点間で完全に同期的にデータ
の更新を行う場合、これらの拠点間で常時ネットワーク
を接続しておく必要があり、通信コストの負担が大きく
なるという問題がある。ネットワークの料金が割り当て
られる通信帯域および使用時間に応じて課金される場合
には常時接続によってコストが膨らむことは勿論のこ
と、伝送される情報量に応じた課金の場合にも、リアル
タイムな同期更新を行うためには２相コミットや稼動監
視等のためのオーバヘッドデータの伝送のためのコスト
が必要となる。

【０００８】また、コストの問題以外にも、データの更
新の際に、一拠点におけるデータ更新だけでなく、他の
拠点におけるデータ更新や拠点間での通信のための時間
がかかるため、これらを含めた全体としてのデータ更新
時間が長くなり、アプリケーションシステムのレスポン
スタイム設計上不利になるという問題がある。

【０００９】これらの問題は、広範なネットワークが必
要とされ、且つデータの更新頻度が比較的低いシステム
において、特に顕著な影響として現れる。

【００１０】この発明は、上記のような事情を考慮して
なされたものであり、通信による経済的コストや時間的
コストを軽減することのできる分散処理方法および分散
処理システムを提供することを目的とする。また、この
発明は、データ更新の伝播のための拠点間でのデータ伝
送量を削減することを目的とする。

【００１１】また、この発明は、上記分散処理方法を用
いることにより、安価な通信コストにより実現でき、多
地域にわたって分散する分院を持つ医療機関にも向いた
医療業務管理システムを提供することを目的とする。

【００１２】

【課題を解決するための手段】上記の課題を解決するた
めに、この発明は、複数のシステムにおいて独立に更新
されるデータの一貫性を維持するための分散処理方法で
あって、第１のシステムおよび第２のシステムにおいて
それぞれ独立にデータを更新する独立更新過程と、前記
独立更新過程における前記第１のシステムによるデータ
の更新の差分が少なくとも含まれる第１のスナップショ
ットデータを前記第１のシステムから前記第２のシステ
ムに伝送する第１のデータ伝送過程と、前記第１のスナ
ップショットデータを基に前記第２のシステムにおいて
データを更新する第１のデータ反映過程と、前記独立更
新過程における前記第２のシステムによるデータの更新
の差分が少なくとも含まれる第２のスナップショットデ
ータを前記第２のシステムから前記第１のシステムに伝
送する第２のデータ伝送過程と、この第２のスナップシ
ョットデータを基に前記第１のシステムにおいてデータ
を更新する第２のデータ反映過程とを有することを特徴
とする分散処理方法を要旨とする。なお、第１のデータ
伝送過程の後に第１のデータ反映過程が実行される。ま
た、第２のデータ伝送過程の後に第２のデータ反映過程
が実行される。なお、第１のデータ伝送過程と第２のデ
ータ伝送過程との間には順序の制約はない。また、第１
のデータ反映過程と第２のデータ反映過程との間には順
序の制約はない。後述するようにこれらの過程は業務サ
イクルに応じて繰り返し実行される。

【００１３】また、この発明の分散処理方法は、前記第
１のデータ伝送過程において、前記第１のスナップショ
ットデータの伝送前に前記第１のシステムと第２のシス
テムとの間の通信を接続し、当該伝送後に当該通信を切
断し、前記第２のデータ伝送過程において、前記第２の
スナップショットデータの伝送前に前記第１のシステム
と第２のシステムとの間の通信を接続し、当該伝送後に
当該通信を切断することを特徴とするものである。

【００１４】また、この発明の分散処理方法は、前記独
立更新過程において、データ更新の際にはデータ更新が
行われた時刻を表す更新時刻情報を更新後のデータとと
もに記録し、前記第２のスナップショットデータは前記
更新時刻情報を含んでおり、前記第２のデータ反映過程
においては、前記第１のシステムのデータが持つ前記更
新時刻情報と前記第２のスナップショットデータが持つ
前記更新時刻情報とを比較し、前記第２のスナップショ
ットデータのほうがより新しく更新されたデータである
場合にのみ、前記第２のスナップショットデータを用い
て前記第１のシステムのデータを更新することを特徴と
するものである。なお、ここで更新時刻情報とは、日付
に関する情報と１日の中の時刻に関する情報を含むもの
であっても良い。また、ここで更新とは、データの追加
や変更や削除などを総称するものである。例えば、リレ
ーショナルデータベースのテーブルにデータが保持され
る場合、具体的には、データの追加はＳＱＬ（Structur
ed Query Language ）のＩＮＳＥＲＴ文によって行わ
れ、変更は同じくＵＰＤＡＴＥ文によって行われ、削除
は同じくＤＥＬＥＴＥ文によって行われるものである。

【００１５】また、この発明の分散処理方法は、前記第
１のスナップショットデータは前記更新時刻情報を含ん
でおり、前記第１のデータ反映過程においては、前記第
２のシステムのデータが持つ前記更新時刻情報と前記第
１のスナップショットデータが持つ前記更新時刻情報と
を比較し、前記第１のスナップショットデータのほうが
より新しく更新されたデータである場合にのみ、前記第
１のスナップショットデータを用いて前記第２のシステ
ムのデータを更新することを特徴とするものである。

【００１６】また、この発明の分散処理方法は、前記第
２のデータ反映過程においては、前記第２のスナップシ
ョットデータが持つ前記更新時刻情報と前記第１のシス
テムが管理し現在の日付または日時を表す現在日時情報
との差が所定範囲内の場合にのみ、前記第２のスナップ
ショットデータを用いて前記第１のシステムのデータを
更新することを特徴とするものである。

【００１７】また、この発明の分散処理方法は、前記第
１のシステムおよび前記第２のシステムはデータの更新
履歴を表す履歴データを保持しており、前記独立更新過
程において、データ更新の際に、当該データに関する当
該更新前の履歴データを削除あるいは上書きすることな
く当該更新に関する新たな履歴データを蓄積することを
特徴とするものである。

【００１８】また、この発明の分散処理方法は、前記独
立更新過程において、前記第２のシステム上で監査対象
データ項目のデータの変更が生じた際に、当該監査対象
データ項目の変更前の値を保持したまま、当該監査対象
データ項目に対応付けられた変更後データを更新し、前
記第２のデータ反映過程において、前記監査対象データ
項目が変更されているデータだけを抽出して監査結果デ
ータとして出力することを特徴とするものである。

【００１９】また、この発明の分散処理方法は、前記独
立更新過程において、更新対象となるデータの日付が、
更新時現在の日付から予め設定されたバックデート更新
許容上限日数を減じた日付よりも古い場合には、当該更
新を拒絶する処理を行うことを特徴とするものである。

【００２０】また、この発明は、第１のシステムおよび
第２のシステムにおいて独立にデータの更新を行う分散
処理システムであって、第１のシステムにおいてデータ
の更新を行う第１のアプリケーション処理部と、第２の
システムにおいてデータの更新を行う第２のアプリケー
ション処理部と、前記第１のアプリケーション処理部に
よるデータの更新の差分が少なくとも含まれる第１のス
ナップショットデータを出力する第１のインポート／エ
クスポート処理部と、前記第１のスナップショットデー
タを取得し、この第１のスナップショットデータを基に
前記第２のシステムにおいてデータを更新する第２のイ
ンポート／エクスポート処理部とを有し、前記第２のイ
ンポート／エクスポート処理部は、前記第２のアプリケ
ーション処理部によるデータの更新の差分が少なくとも
含まれる第２のスナップショットデータを出力し、前記
第１のインポート／エクスポート処理部は、前記第２の
スナップショットデータを取得し、この第２のスナップ
ショットデータを基に前記第１のシステムにおいてデー
タを更新することを特徴とする分散処理システムを要旨
とする。

【００２１】また、この発明の分散処理システムは、前
記第１のスナップショットデータを前記第１のシステム
から前記第２のシステムに伝送する前に前記第１のシス
テムと前記第２のシステムとの間の通信を接続し当該伝
送後に当該通信を切断し、前記第２のスナップショット
データを前記第２のシステムから前記第１のシステムに
伝送する前に前記第１のシステムと前記第２のシステム
との間の通信を接続し当該伝送後に当該通信を切断する
ことを特徴とするものである。

【００２２】また、この発明の分散処理システムは、前
記第１のアプリケーション処理部および前記第２のアプ
リケーション処理部は、データ更新の際にデータ更新が
行われた時刻を表す更新時刻情報を更新後のデータとと
もに記録し、前記第２のインポート／エクスポート処理
部は、前記更新時刻情報を含んだ前記第２のスナップシ
ョットデータを出力し、前記第１のインポート／エクス
ポート処理部は、前記第１のアプリケーション処理部に
よって記録された前記更新時刻情報と前記第２のスナッ
プショットデータに含まれた前記更新時刻情報とを比較
し、前記第２のスナップショットデータのほうがより新
しく更新されたデータである場合にのみ、前記第２のス
ナップショットデータを用いて前記第１のシステムのデ
ータを更新することを特徴とするものである。

【００２３】また、この発明の分散処理システムは、前
記第１のインポート／エクスポート処理部は、前記更新
情報を含んだ前記第１のスナップショットデータを出力
し、前記第２のインポート／エクスポート処理部は、前
記第２のアプリケーション処理部によって記録された前
記更新時刻情報と前記第１のスナップショットデータに
含まれた前記更新時刻情報とを比較し、前記第１のスナ
ップショットデータのほうがより新しく更新されたデー
タである場合にのみ前記第１のスナップショットデータ
を用いて前記第２のシステムのデータを更新することを
特徴とするものである。

【００２４】また、この発明の分散処理システムは、前
記第１のインポート／エクスポート処理部は、前記第２
のスナップショットデータに含まれる前記更新時刻情報
と前記第１のシステムが管理し現在の日付または日時を
表す現在日時情報との差が所定範囲内の場合にのみ、前
記第２のスナップショットデータを用いて前記第１のシ
ステムのデータを更新することを特徴とするものであ
る。

【００２５】また、この発明の分散処理システムは、前
記第１のシステムおよび前記第２のシステムはデータの
更新履歴を表す履歴データを保持しており、前記第１の
アプリケーション処理部および前記第２のアプリケーシ
ョン処理部は、データ更新の際に、当該データに関する
当該更新前の履歴データを削除あるいは上書きすること
なく当該更新に関する新たな履歴データを蓄積すること
を特徴とするものである。

【００２６】また、この発明の分散処理システムにおい
ては、前記第２のアプリケーション処理部は、前記第２
のシステム上で監査対象データ項目のデータの変更が生
じた際に当該監査対象のデータ項目の変更前の値を保持
したまま、当該監査対象データ項目に対応付けられた変
更後データを更新し、前記第１のインポート／エクスポ
ート処理部は、前記監査対象データ項目が変更されてい
るデータだけを抽出して監査結果データとして出力する
ことを特徴とするものである。

【００２７】また、この発明の分散処理システムにおい
ては、前記第２のアプリケーション処理部は、更新対象
となるデータの日付が更新時現在の日付から予め設定さ
れたバックデート更新許容上限日数を減じた日付よりも
古い場合には、当該更新を拒絶する処理を行うことを特
徴とするものである。

【００２８】また、この発明の分散処理システムは、前
記第１のアプリケーション処理部は予約受付の処理を行
って予約に関するデータを更新し、前記第２のアプリケ
ーション処理部は前記第１のアプリケーション処理部に
よって受け付けられた予約に基づいて行われる活動の実
績のデータを更新することを特徴とするものである。

【００２９】

【発明の実施の形態】以下、図面を参照しこの発明の一
実施形態について説明する。図１は、同実施形態による
医療業務管理システムの構成を示すブロック図である。
図１において、符号２０はセンタシステム（第１のシス
テム）、４０はＦＴＰ（File Transfer Protocol, ファ
イル転送プロトコル）サーバ、６０は複数の分院システ
ム（第２のシステム）である。センタシステム２０とＦ
ＴＰサーバ４０とは接続されており、これら相互間の通
信が可能となっている。また、ＦＴＰサーバ４０と分院
システム６０とはＩＳＤＮ（Integrated Services Digi
tal Network,統合デジタル通信網）１を介して接続され
ており、これら相互間の通信が可能となっている。

【００３０】センタシステム２０には、アプリケーショ
ン処理部２４（第１のアプリケーション処理部）とデー
タベース３０ａとインポート／エクスポートサブシステ
ム２２（第１のインポート／エクスポート処理部）が設
けられている。データベース３０ａにはセンタシステム
２０が扱うデータが格納されている。また、インポート
／エクスポートサブシステム２２は、外部とのデータの
やりとりのために、データベース３０ａから取り出した
データをファイルとして出力する機能および入力される
ファイルを基にデータをデータベース３０ａに格納する
機能を有している。

【００３１】ＦＴＰサーバ４０は、インポート／エクス
ポートサブシステム２２から出力された下りスナップシ
ョットデータ４６（第１のスナップショットデータ）お
よびインポート／エクスポートサブシステム２２に入力
するための上りスナップショットデータ４８（第２のス
ナップショットデータ）を保持している。ＦＴＰサーバ
４０上のこれらのファイルは、ＦＴＰによる通信をＦＴ
Ｐクライアントからアクセスすることができるようにな
っている。ＦＴＰクライアントからは、ＦＴＰサーバへ
のログインや、ファイルの一覧リストの取得や、ファイ
ルのアップロード（ＰＵＴコマンドの実行）や、ファイ
ルのダウンロード（ＧＥＴコマンドの実行）などの操作
が可能となっている。

【００３２】各々の分院システム６０には、アプリケー
ション処理部６４（第２のアプリケーション処理部）と
データベース３０ｂとインポート／エクスポートサブシ
ステム６２（第２のインポート／エクスポート処理部）
が設けられている。データベース３０ｂには分院システ
ム６０が扱うデータが格納されている。また、インポー
ト／エクスポートサブシステム６２は、前記のインポー
ト／エクスポートサブシステム２２と同様の機能を有し
ており、外部とのデータのやりとりのために下りスナッ
プショットデータ６６（第１のスナップショットデー
タ）や上りスナップショットデータ６８（第２のスナッ
プショットデータ）の入出力を行う。なお、分院システ
ム６０はＦＴＰクライアントの機能を有しており、この
ＦＴＰクライアントの機能を用いて下りスナップショッ
トデータ（４６，６６）をＦＴＰサーバ４０からダウン
ロードしたり、上りスナップショットデータ（４８，６
８）をＦＴＰサーバ４０にアップロードしたりすること
が可能となっている。

【００３３】センタシステム２０上のデータベース３０
ａには、患者マスタ３１ａ、患者履歴マスタ３２ａ、予
約受付データ３３ａ、患者来院データ３４ａ、手術内容
データ３５ａ、入金データ３６ａ、およびその他のデー
タが格納されている。また、これに対応して、分院シス
テム６０上のデータベース３０ｂには、患者マスタ３１
ｂ、患者履歴マスタ３２ｂ、予約受付データ３３ｂ、患
者来院データ３４ｂ、手術内容データ３５ｂ、入金デー
タ３６ｂ、およびその他のデータが格納されている。

【００３４】この医療業務管理システムが管理する業務
内容は次の通りである。センタシステム２０を利用する
センタ側と分院システム６０を利用する分院側とでは、
業務上の役割が異なっている。

【００３５】センタ側では、電話やファクシミリやイン
ターネットやセンタへの来所による患者の一次受付を行
う。この一次受付においては、予約オペレータによって
予約票が起票され、この予約票を基に入力オペレータが
アプリケーション処理部２４を通して入力を行い、予約
受付データ３３ａが作成される。また、新規の患者につ
いては、このとき同時に患者マスタ３１ａや患者履歴マ
スタ３２ａへの登録が行われる。またセンタ側で料金の
一部を収受し、入金データ３６ａに登録することも可能
である。

【００３６】分院側では、予約された日時に来院した患
者に対してカウンセリングや治療や手術を行い、それら
の料金を収受する。このとき、分院側の担当者は、アプ
リケーション処理部６４を通して、患者来院データ３４
ｂや手術内容データ３５ｂや入金データ３６ｂへの登録
を行う。また患者の都合等に応じて、分院側で予約の変
更を受け付け、予約受付データ３２ｂを更新することも
可能である。

【００３７】業務時間帯にはＦＴＰサーバ４０と分院シ
ステム６０間でＩＳＤＮ１の呼は設定されておらず、デ
ータベース３０ａと３０ｂはそれぞれ独立に更新され
る。

【００３８】次に、データベース３０ａおよび３０ｂに
格納され、センタシステム２０および分院システム６０
で扱われるデータの内容について説明する。なお、デー
タベース３０ａおよび３０ｂはリレーショナルデータベ
ースであり、データは行および列を有する２次元のテー
ブルの形式で管理されている。図２は、この医療業務管
理システムにおいて用いられている患者マスタのデータ
構造を示す表図である。患者マスタは患者ＩＤ、カル
テ、カナ氏名、氏名、性別、年齢、生年月日、住所、電
話番号、職業、残金、備考、登録日、更新者、更新日時
（更新時刻情報）の列を持っている。図２のＫＥＹの欄
に「◎」印で示されている患者ＩＤは、この患者マスタ
の主キー（プライマリキー, primary key ）である。

【００３９】また、図３は、患者履歴マスタのデータ構
造を示す表図である。患者履歴マスタは、上記患者マス
タが持つ列に加えて、履歴の列を持っている。この履歴
は整数（int ）型のデータであり、この履歴と患者ＩＤ
の複合が患者履歴マスタの主キーとなっている。つま
り、患者マスタの行と患者履歴マスタの行は１対ｎに対
応しており、意味的には、患者履歴マスタは過去の患者
マスタの更新履歴を全て保存している。

【００４０】また、図４は、分院マスタのデータ構造を
示す表図である。分院マスタは、分院ＩＤ、名称、所在
地、地図、更新日時（更新時刻情報）の列を持ってお
り、分院ＩＤがこの分院マスタの主キーである。

【００４１】また、図５は、患者来院データのデータ構
造を示す表図である。患者来院データは、患者ＩＤ、オ
ペ種別、初診日時、最終来院日時、更新者の列を持って
おり、患者ＩＤとオペ種別の複合が患者来院データの主
キーとなっている。なお「オペ」とは、「オペレーショ
ン」を略した語であり、手術を表す。

【００４２】また、図６は、予約受付データのデータ構
造を示す表図である。予約受付データは、予約番号、枝
番、患者、患者年齢、分院、来院日時、オペ種別、予約
名、予約状況、支払区分、来院動機、広告媒体、広告、
情報、受付日時、受付者、オペレータ、分院受付者、登
録日、更新者、更新日時（更新時刻情報）、キャンセル
の列を持っており、予約番号と枝番の複合が予約受付デ
ータの主キーとなっている。

【００４３】次に、センタシステム側のデータベース３
０ａおよび分院システム側のデータベース３０ｂの更新
と、それぞれの側での更新を相手側のデータベースに反
映させるための処理のタイミングについて説明する。図
７は、本実施形態において、センタシステム側および分
院システム側でのデータの更新と相手側への反映の処理
手順を示すシーケンス図である。

【００４４】まず、図７のステップＡ１において、セン
タシステム側で下りスナップショットデータが作成され
る。これは、図１に示したインポート／エクスポートサ
ブシステム２２がデータベース３０ａからデータを取り
出し、作成したファイルをＦＴＰサーバ上に置くことに
よって行われる。例えば、ＦＴＰサーバ４０からの要求
により、インポート／エクスポートサブシステム２２が
直接下りスナップショットデータ４６を出力する。ま
た、インポート／エクスポートサブシステム２２にＦＴ
Ｐクライアントの機能を持たせて、インポート／エクス
ポートサブシステム２２が作成した下りスナップショッ
トデータ４６を、ＦＴＰによってＦＴＰサーバ４０上に
アップロード（ＰＵＴコマンドの実行）するようにして
も良い。なお、下りスナップショットデータは、すべて
の分院システム６０に共通のものであっても良いし、各
々の分院システム６０用のものを個別に作成しても良
い。

【００４５】また、各々の分院システム６０用に、当該
分院システム６０に関係するデータのみを含む下りスナ
ップショットデータを個別に作成しても良い。これは、
例えば、患者の属性データとしてその患者が訪れる分院
のコード情報を持ち、この分院コード情報を参照するこ
とによって、各分院毎に該当する患者のデータだけを下
りスナップショットデータに含めるようにする。これに
より、ＦＴＰサーバ４０と分院システム６０との間のフ
ァイル転送のデータ量を削減することが可能となる。な
お、本実施形態においては、上記下りスナップショット
データにはデータベース３０ａ上の全データが含まれて
いるが、前回からの変更分だけを下りスナップショット
データに含めるようにしても良い。

【００４６】次に、予め定められた時間スケジュールに
従って、あるいは図示されない手順によってステップＡ
１の完了の通知を受けたことをトリガとして、ステッＢ
１において、分院システム側のから下りスナップショッ
トデータを要求するデータが送信される。これは、分院
システム側のＦＴＰクライアント機能から、図１に示し
たＦＴＰサーバ４０に対してＧＥＴコマンドに基づく要
求が送信されることにより行われる。

【００４７】ステップＡ２で、この要求に応じて、セン
タシステム側から分院システム側に下りスナップショッ
トデータが送信される（第１のデータ伝送過程）。下り
スナップショットデータを受信した分院システム側で
は、ステップＢ２において、後に詳述する方法により、
この下りスナップショットデータをデータベース３０ｂ
にローディングする。このローディングにより、センタ
システム側の最新のデータが分散システム側に反映され
る（第１のデータ反映過程）。

【００４８】この後、ステップＡ３において、センタシ
ステム側のデータがアプリケーション処理部によって必
要に応じて更新される（独立更新過程）。またこれと並
行して、ステップＢ３において、分院システム側のデー
タがアプリケーション処理部によって必要に応じて更新
される（独立更新過程）。ステップＡ３およびステップ
Ｂ３でのデータ更新は、それぞれセンタシステム側およ
び分院システム側において独立かつ非同期的に行われ、
この間は両システム間の通信は切断されている。

【００４９】予め定められたスケジュールによりステッ
プＡ３およびＢ３が終了すると、ステップＢ４におい
て、分散システム側で上りスナップショットデータが作
成される。これは、インポート／エクスポートサブシス
テム６２がデータベース３０ｂからデータを取り出して
ファイルとして出力することにより行われる。続けて、
ステップＢ５において、分院システム側からセンタシス
テム側にこの上りスナップショットデータが送信される
（第２のデータ伝送過程）。これは、分院システム側の
ＦＴＰクライアント機能が上りスナップショットデータ
をＦＴＰサーバ４０にアップロード（ＰＵＴコマンドの
実行）することにより行われる。

【００５０】上りスナップショットデータを受信したセ
ンタシステム側では、ステップＡ４において、この上り
スナップショットデータをデータベース３０ａにローデ
ィングする。これは、インポート／エクスポートサブシ
ステム２２がＦＴＰサーバ４０のファイルシステムに直
接アクセスできる場合には、上りスナップショットデー
タ４８をファイルとして直接読み込んで後に詳述する方
法によりデータをデータベース３０ａにローディングす
ることにより行われる。あるいは、インポート／エクス
ポートサブシステム２２が有するＦＴＰクライアントの
機能を用いてＦＴＰサーバ４０から上りスナップショッ
トデータをダウンロード（ＧＥＴコマンドの実行）する
ようにしても良い。このローディングにより、分散シス
テム側の最新のデータがセンタシステム側に反映される
（第２のデータ反映過程）。

【００５１】上述したステップＡ１からＡ４までの一連
の処理は、業務サイクルに応じて繰り返し行われる。具
体的には、例えば、ステップＡ１からＡ４までの処理が
１日サイクルで実行され、早朝にステップＡ１，Ｂ１，
Ａ２，Ｂ２の処理を行い、朝から夕方までの間にステッ
プＡ３およびＢ３の処理を行い、夜間にステップＢ４，
Ｂ５，Ａ４の処理を行うようにする。但し、業務サイク
ルはこのような１日サイクルに限定されるものではな
い。

【００５２】次に、インポート／エクスポートサブシス
テム２２および６２がデータベース３０ａおよび３０ｂ
間に不整合が起こらないようにデータをローディングす
る方法について詳述する。ここで、「不整合」とは、例
えば図７に示したステップＡ３およびＢ３においてセン
タシステム２０と分院システム６０が同一のデータをそ
れぞれ独立に更新し、その後この更新を相手側システム
に反映させる際にその反映方法が不適切である場合に生
じるものである。また、複数の分院システム６０が同一
のデータをそれぞれ独立に更新し、その後この更新をセ
ンタシステムに反映させる際にその反映方法が不適切で
ある場合にも、この不整合が生じる。不整合を防止する
方法として、以下に、（１）日時による更新管理、
（２）更新履歴の管理、および（３）データ値域の分離
による管理について説明する。

【００５３】（１）日時による更新管理 図８の（ａ）〜（ｃ）は、前述の患者来院データの更新
例を示す表図である。図８（ａ）は、センタシステム側
のデータベースに格納された患者来院データの中の１行
を示す。この行の主キーの値は、患者ＩＤ＝「１２３４
５６７８９０」、オペ種別＝「ＡＢＣ７８」である。

【００５４】ここで、インポート／エクスポートサブシ
ステムに、データベースへのローディングのために、図
８（ｂ）に示すスナップショットデータが入力された場
合、インポート／エクスポートサブシステムは以下のよ
うな判断および処理を行う。なお、図８（ｂ）に示すよ
うに、このスナップショットデータには、患者ＩＤ＝
「１２３４５６７８９０」、オペ種別＝「ＡＢＣ７８」
という主キーの値を持つ行が存在するものとする。イン
ポート／エクスポートサブシステムは、この行のデータ
を読み込み、この行と同一の主キー値を持つデータベー
ス（図８（ａ））上の行を検索する。そして、両者の更
新日時（更新時刻情報）の列の値を比較する。データベ
ース上の行の更新日時は「17 Jun 2000, 14:28pm」であ
り、スナップショットデータ上の行の更新日時は「17 J
un 2000, 08:55am」であり、データベース上の行のほう
が時刻が遅い。従って、スナップショットデータとして
転送されてきた分院システム側でのデータは、センタシ
ステム側のデータよりも前に更新されていたことを意味
する。従って、インポート／エクスポートサブシステム
は、遅いほうの更新を生かすため、スナップショットデ
ータの当該行をデータベースに反映させずにそのまま破
棄する。

【００５５】一方、インポート／エクスポートサブシス
テムに、データベースへのローディングのために、図８
（ｃ）に示すスナップショットデータが入力された場
合、インポート／エクスポートサブシステムは以下のよ
うな判断および処理を行う。インポート／エクスポート
サブシステムは、スナップショットデータ（図８
（ｃ））から患者ＩＤ＝「１２３４５６７８９０」、オ
ペ種別＝「ＡＢＣ７８」という主キー値を持つ行を読み
込んだとき、この行と同一の主キー値を持つデータベー
ス（図８（ａ））上の行を検索する。そして、両者の更
新日時の列の値を比較する。データベース上の行の更新
日時は「17 Jun 2000, 14:28pm」であり、スナップショ
ットデータ上の行の更新日時は「19 Jun 2000, 10:42a
m」であり、スナップショットデータ上の行のほうが時
刻が遅い。従って、スナップショットデータとして転送
されてきた分院システム側でのデータは、センタシステ
ム側のデータよりも後で更新されたことを意味する。従
って、インポート／エクスポートサブシステムは、遅い
ほうの更新を生かすため、スナップショットデータの当
該行の値を用いて、データベースを更新する。

【００５６】このように、センタシステム側および分院
システム側の両方でデータの更新日時を保持して、スナ
ップショットデータの中にこの更新日時の情報を含め、
両者間で更新日時を比較して、その結果に応じてデータ
をスナップショットデータを用いた更新を行うかどうか
を決定することにより、最後の更新データを両システム
側のデータベースが保持することができるようになる。
なお、ここではセンタシステム側のデータベースに上り
スナップショットデータを反映させる例を説明したが、
分院システム側のデータベースに下りスナップショット
データを反映させる場合も同様である。また、図８に示
す例では更新日時の情報を分単位以外表すこととした
が、これ以外の単位で時刻を管理しても良い。例えば、
時間単位、秒単位、あるいは秒以下の単位で時刻を管理
しても良い。

【００５７】また、上記以外のチェックのために更新日
時の情報を利用することもできる。図９は、スナップシ
ョットデータの日付をチェックするためのセンタシステ
ムの構成を示す。図９において、符号２７は、センタシ
ステム２０に設けられたシステム日付記憶部である。図
７に示した処理手順（ステップＡ１からＡ４まで）が１
日サイクルで実行されることを前提として、システム日
付記憶部２７には当日の日付が記憶されており、インポ
ート／エクスポートサブシステム２２は、上りスナップ
ショットデータ４８内のデータに記録された更新日時と
システム日付記憶部２７から読み出した日付とを比較す
る。そして、上りスナップショットデータ４８内のデー
タに記録された更新日時が、システム日付記憶部２７か
ら読み出した当日日付（現在日時情報）よりも前である
場合には、そのデータをエラーデータと判断してデータ
ベース３０ａに反映させずにそのまま破棄し、必要に応
じて日付チェックによるエラーが検出された旨のメッセ
ージまたは信号を出力する。

【００５８】このような更新日時のチェックを行うこと
により、システムオペレーション上の誤り等によって古
い日時の不当なスナップショットデータが読み込まれた
ことを検出することが可能となる。また、この方法によ
り過去データの改ざんを防ぐことも可能となる。

【００５９】また、次のような方法により、分院システ
ム側でデータ更新の日付をチェックするようにしても良
い。予め、システム設定値として、バックデートでのデ
ータ更新を許容する上限日数を定めておく。そして、分
院システム側のアプリケーション処理部６４は、利用者
からのデータ更新要求があったときにこのシステム設定
値を参照し、対象となっているデータの日付（例えば、
患者の手術実施日など）がから上記上限日数以内に限
り、データの更新を実行し、そうでない場合にはデータ
の更新を拒絶する。

【００６０】例えば、設定されたバックデートデータ更
新上限日数が「２」であり、現在日付が「２０００年７
月１４日」である場合、「２０００年７月１２日」以降
のデータは許容範囲内（「７月１４日」−「７月１２
日」≦２）であるので更新を許すが、「２０００年７月
１１日」以前のデータの更新は拒絶する。このような方
法により、分院システム側でのバックデートでのデータ
更新に歯止めをかけ、データの健全性を維持することが
可能となる。

【００６１】なお、処理サイクルが１日でなく他の単位
（例えば１時間単位など）である場合には、システム日
付記憶部２７は日付以外に時間帯情報をあわせて記憶
し、インポート／エクスポートサブシステム２２は日付
および時間帯情報を併用してスナップショットデータの
日時をチェックするようにする。また、日時情報の代わ
りに、時系列的に割り振られる番号等のデータを用いて
同様のチェックを行うようにしても良い。また、図９で
は、センタシステム２０において上りスナップショット
データの日時をチェックする例を示したが、同様に、分
院システム６０において下りスナップショットデータの
日時をチェックして、古いデータを検出するようにして
も良い。

【００６２】つまり、上りスナップショットデータが持
つ前記更新時刻情報と前記第１のシステムが管理し現在
の日付または日時を表す現在日時情報とを比較し、これ
ら両者の差が所定範囲内の場合にのみ、上りスナップシ
ョットデータを用いてセンタシステムのデータを更新す
る。

【００６３】（２）更新履歴の管理 図１０および図１１は、データ更新履歴の保存および管
理の例を示す表図である。図１０（ａ）は、上りスナッ
プショットデータを用いたローディングを行う直前のセ
ンタシステム側データベースの患者マスタを示す。ま
た、図１０（ｂ）は、同じくセンタシステム側データベ
ースの患者履歴マスタを示す。これらの両テーブルに
は、患者ＩＤ＝「１２３４５７８９０」の患者に関する
データが登録されている。また、患者履歴マスタ（図１
０（ｂ））には、患者ＩＤ＝「１２３４５７８９０」の
患者に関して、履歴＝１，２，３の３つの行のデータが
存在しており、これらそれぞれの行に更新日時が記録さ
れている。これら３つの行のうち、最も更新日時の新し
い行（つまり、履歴＝３、更新日時＝「19 Jun 2000, 1
0:42am」の行）がセンタシステム側での最新の更新履歴
であり、この行のデータと患者マスタの当該患者ＩＤの
行のデータとが一致している。

【００６４】図１０（ｃ）は、患者マスタに関する上り
スナップショットデータを示す。また図１１（ｄ）は、
患者履歴マスタに関する上りスナップショットデータを
示す。患者履歴マスタの上りスナップショットデータ
（図１１（ｄ））には、患者ＩＤ＝「１２３４５６７８
９０」の患者に関して、履歴＝１００１，１００２の２
つの行のデータが存在しており、これらそれぞれの行に
更新日時が記録されている。これら２つの行のうち、最
も更新日時の新しい行（つまり、履歴＝１００２、更新
日時＝「21 Jun 2000, 15:02pm」の行）が分院システム
側での最新の更新履歴であり、この行のデータと患者マ
スタの上りスナップショットデータ（図１０（ｃ））の
当該患者ＩＤの行のデータとが一致している。

【００６５】インポート／エクスポートサブシステム２
２は、上記の各上りスナップショットデータを反映させ
て、センタシステム側のデータベースの更新を行う。図
１１（ｅ）はスナップショットデータ反映後のセンタシ
ステム側の患者マスタを示し、図１１（ｆ）は同じくス
ナップショットデータ反映後のセンタシステム側の患者
履歴マスタを示す。図１１（ｅ）に示すように、センタ
システム側の患者マスタには、分院システム側での最新
のデータ更新結果が反映される。また、図１１（ｆ）に
示すように、センタシステム側の患者履歴マスタには、
分院システム側での更新履歴が付加され、すべての更新
履歴を保存する。このように更新履歴データを保存する
ことにより、センタシステム側および全ての分院システ
ム側での更新状況を時系列的に再現することが可能とな
る。

【００６６】（３）データ値域の分離による管理 センタシステム側および分院システム側それぞれで発番
付与する必要のあるデータについては、データの値の範
囲をセンタシステム側と分院システム側とで分けるよう
にする。例えば、０〜９９９９９の範囲の番号をそれぞ
れ独自に付与する必要がある場合、センタシステム側で
は０〜４９９９９の範囲の番号を付与し、分院システム
側では５００００〜９９９９９の範囲の番号を付与する
ようにする。これにより、センタシステムおよび分院シ
ステムの間で同期をとることなくシステム全体にわたっ
てユニークな番号を付与することが可能となる。なお、
データの範囲が重複しない限り範囲の割り当て方は任意
である。

【００６７】以上（１）〜（３）で述べた方法により、
センタシステム側および分院システム側のデータベース
での更新内容が相手側に反映される。図７のステップＢ
３において分院システム側で更新されたデータはステッ
プＢ４、Ｂ５、Ａ４でセンタシステム側に反映され、ス
テップＡ３においてセンタシステム側で更新されたデー
タは次サイクルのステップＡ１、Ｂ１、Ａ２、Ｂ２で分
院システム側に反映されるため、少なくとも１サイクル
に１回、データ更新の開始時点、すなわちステップＡ３
とステップＢ３それぞれの開始時点では、センタシステ
ム側のデータベース３０ａと分院システム側のデータベ
ース３０ｂの内容は一致する。

【００６８】このようにして、センタシステム側と分院
システム側との間で通信を常時接続することなく、１サ
イクル毎に最新のデータを相手側に伝えることができる
ため、両方のシステムにおいて相手側でのデータ更新を
も反映した最新のデータに基づいた業務処理を行うこと
が可能となる。

【００６９】次に、本実施形態のように分散処理によっ
て各拠点で更新されるデータを効率的に監査する方法に
ついて説明する。ここで、図６に示した予約受付データ
に定義されている「予約状況」の列には、次のような意
味を持つデータが保持されるものとする。すなわち、予
約状況が「Ａ予約」である場合、予約日時に患者が手術
を受ける意思で来院することを表す。予約状況が「Ｂ予
約」である場合、予約日時に患者が来院し、そのときの
カウンセリング結果に応じて手術を受けるかどうかを決
定することを表す。予約状況が「Ｃ予約」である場合、
予約日時に患者はカウンセリングのみを受ける意思で来
院することを表す。また、「Ｈ予約」はその他の予約を
表す。

【００７０】事前にセンタ側においてなされた予約状況
に応じて手術実施時の分院側医師に対する報酬率が異な
る場合、分院側が有利な報酬率を不正に得るために実態
に関係なく恣意的にデータベース上の予約状況を更新す
るという事態が起こり得る。業務上の監査の観点から
は、このような不正な更新を検出する必要があるが、本
実施形態においては、分院システム側で予約変更が生じ
た時点では、センタシステムおよび分院システム間の通
信は切断されているため、分院システム側で予約受付デ
ータの更新をリアルタイムに監視することはできない。
そこで、予約内容（監査対象データ項目）に変更が生じ
た場合にも、予約状況の列の値を直接書き換えるのでは
なく、予約受付データに「予約状況結果」（変更後デー
タ）という別の列を設け、この「予約状況結果」に変更
後の予約内容を表わす値を書き込むようにする。そし
て、図１２に示すように、センタシステム２０側のイン
ポート／エクスポートサブシステム２２は、「予約状況
結果」が予約状況の変更があったことを表わしているよ
うなデータのみを抽出して、監査結果データ２９として
出力する。つまり、前記独立更新過程において、前記第
２のシステム上で監査対象データ項目のデータの変更が
生じた際に、当該監査対象データ項目の変更前の値を保
持したまま、当該監査対象データ項目に対応付けられた
変更後データを更新し、前記第２のデータ反映過程にお
いて、前記監査対象データ項目が変更されているデータ
だけを抽出して監査結果データとして出力するようにす
る。なお、本実施形態ではインポート／エクスポートサ
ブシステム２２が「予約状況結果」が予約状況の変更が
あったことを表わしているようなデータのみを抽出して
監査結果データ２９を出力することとしたが、アプリケ
ーション処理部２４が同様の監査結果データ２９を出力
する機能を持つようにしても良い。

【００７１】あるいは、予約状況結果の列を設ける代わ
りに、予約状況として以下の値を追加することにより、
不正な更新に関する監査を可能とする。すなわち、「Ｇ
−予約」は、患者が分院に来院した際に前記の「Ａ予
約」、「Ｂ予約」、「Ｃ予約」が取消しまたは変更され
たことを表す。また、「Ｇ＋Ａ予約」、「Ｇ＋Ｂ予
約」、「Ｇ＋Ｃ予約」は、上記「Ｇ−予約」によって以
前の予約を取り消した後に、それぞれ「Ａ予約」、「Ｂ
予約」、「Ｃ予約」に相当する予約がなされたことを表
す。予約状況が「Ｇ−予約」であるデータを無効化デー
タと呼び、予約状況が「Ｇ＋Ａ予約」、「Ｇ＋Ｂ予
約」、「Ｇ＋Ｃ予約」のいずれかであるデータを無効後
再生成データと呼ぶ。

【００７２】そして、予約状況の区分（「Ａ予約」、
「Ｂ予約」、「Ｃ予約」）の変更を伴うような更新の場
合には、必ず「Ｇ−予約」、「Ｇ＋Ａ予約」、「Ｇ＋Ｂ
予約」、「Ｇ＋Ｃ予約」という値を用いるように、分院
システム側のアプリケーションを構成する。そして、図
１２に示すように、センタシステム２０側のインポート
／エクスポートサブシステム２２は、これら「Ｇ−」あ
るいは「Ｇ＋」の予約状況を有するデータのみを抽出し
て、監査結果データ２９として出力する。つまり、業務
中の分院システムのデータ更新の際に、更新前のデータ
を、当該データを無効にする無効化データによって置き
換えて保存するとともに、更新後のデータを無効後再生
成データとして新たに生成し、上りスナップショットデ
ータをセンタシステムのデータベースに反映させるデー
タ反映過程において、前記無効化データおよび前記無効
後再生成データを抽出して監査結果データとして出力す
る。

【００７３】これらのような方法で監査結果データ２９
を出力することにより、センタシステム側では特定のデ
ータ項目の特定の更新パターンのみに関して選択的に監
査結果データを出力するため、膨大な件数にのぼるすべ
てのデータ更新について監査をする必要がなく、限られ
た件数の監査データをチェックすれば良く、監査効率を
向上させることが可能となる。

【００７４】なお、上記実施形態では、分院システム側
からセンタシステム側へのデータの反映と、センタシス
テム側から分院システム側へのデータの反映とを、同期
的に順次行うようにしたが、これらを異なる順序で行っ
たり、同時に行ったり、非同期的に行うようにしても良
い。

【００７５】また、センタシステム側のデータと分院シ
ステム側のデータとは、対等な関係として扱っても良い
し、いずれかのデータを主として他方のデータを従とし
て扱っても良い。例えば対等な関係を持つ場合には、セ
ンタシステム側のインポート／エクスポートサブシステ
ムと分院システム側のインポート／エクスポートサブシ
ステムとは互いに同様のチェックを行うことにより、相
手側から送られてくるスナップショットデータを自己の
データに反映させる。また例えば、センタシステム側の
データを主として、分院システム側のデータを従として
扱う場合には、上りスナップショットデータについては
センタシステム側のインポート／エクスポートサブシス
テムが上で述べた各種のチェックを行ってセンタシステ
ム側のデータに反映させ、下りスナップショットデータ
については分院システム側のインポート／エクスポート
サブシステムが全件のデータを無条件に分院システム側
のデータベースにローディングする。また、ここに記し
たもの以外のバリエーションによる実施も可能である。

【００７６】また、上記実施形態では、センタシステム
側と分院システム側との間のスナップショットデータの
転送をＦＴＰを用いているが、ＦＴＰ以外の手段を用い
るようにしても良い。また、ＦＴＰサーバ４０やこれを
代替する中間のサーバも必須ではなく、異なる構成によ
り、インポートエクスポートサブシステム２２から出力
された下りスナップショットデータが通信によって転送
されインポートエクスポートサブシステム６２がこれを
読み込むことができ、逆にインポートエクスポートサブ
システム６２から出力された上りスナップショットデー
タが通信によって転送されインポートエクスポートサブ
システム２２がこれを読み込むことができれば良い。

【００７７】また、本発明の実施にあたって、システム
内の各機能の配置方法は上記実施形態の通りでなくても
良い。例えば、図１において、インポート／エクスポー
トサブシステムは、センタシステム２０内ではなくＦＴ
Ｐサーバ４０内に置かれていても良い。

【００７８】また、上記実施形態では、医療管理業務の
システムに本発明を適用したが、これ以外の業務を本発
明の分散処理システムによって実現するようにしても良
い。

【００７９】上述のセンタシステム２０、ＦＴＰサーバ
４０、分院システム６０はコンピュータシステムにより
実現されている。上述したデータベースの操作の処理
や、スナップショットデータの作成および読み込みの処
理や、アプリケーション処理などの各処理の手順は、プ
ログラムの形式でコンピュータ読み取り可能な記録媒体
に記憶されており、このプログラムをコンピュータが読
み出して実行することによって上記各処理が行われる。
ここでコンピュータ読み取り可能な記録媒体とは、フロ
ッピー（登録商標）ディスク、光磁気ディスク、ＣＤ−
ＲＯＭ、磁気ハードディスク、半導体メモリ等、磁気的
手段、電気的手段、光学的手段などによる情報記録媒体
を言う。

【００８０】

【発明の効果】以上説明したように、この発明によれ
ば、第１のシステムおよび第２のシステムにおいてそれ
ぞれ独立にデータを更新し、独立更新過程における第１
のシステムによるデータの更新の差分が少なくとも含ま
れる第１のスナップショットデータを第１のシステムか
ら前記第２のシステムに伝送し、第１のスナップショッ
トデータを基に第２のシステムにおいてデータを更新す
るとともに、独立更新過程における第２のシステムによ
るデータの更新の差分が少なくとも含まれる第２のスナ
ップショットデータを第２のシステムから第１のシステ
ムに伝送し、この第２のスナップショットデータを基に
第１のシステムにおいてデータを更新するため、それぞ
れのシステムにおいて独立に更新されたデータを互いに
相手側システムに反映させることが可能となる。

【００８１】また、この発明によれば、上記の第１のデ
ータ伝送過程において第１のスナップショットデータの
伝送前に第１のシステムと第２のシステムとの間の通信
を接続し当該伝送後に当該通信を切断するため、また同
じく第２のデータ伝送過程において第２のスナップショ
ットデータの伝送前に第１のシステムと第２のシステム
との間の通信を接続し当該伝送後に当該通信を切断する
ため、独立更新過程においては上記両システム間での通
信が必要なく、通信コストを軽減することが可能とな
る。このようにして、第１のシステム側と第２のシステ
ム側との間で通信を常時接続することなく、１サイクル
毎に最新のデータを相手側に伝えることができるため、
両方のシステムにおいて相手側でのデータ更新をも反映
した最新のデータに基づいた業務処理を行うことが可能
となる。

【００８２】また、この発明によれば、独立更新過程に
おいてデータ更新の際にはデータ更新が行われた時刻を
表す更新時刻情報を更新後のデータとともに記録し、第
２のスナップショットデータはこの更新時刻情報を含ん
でおり、第２のデータ反映過程においては、第１のシス
テムのデータが持つ更新時刻情報と第２のスナップショ
ットデータが持つ更新時刻情報とを比較し、第２のスナ
ップショットデータのほうがより新しく更新されたデー
タである場合にのみ第２のスナップショットデータを用
いて前記第１のシステムのデータを更新するため、第１
のシステムと第２のシステムにおいて最も新しく更新さ
れたデータを第１のシステムのデータとして残すことが
可能となる。また、逆方向のデータの反映についても同
様に最も新しく更新されたデータを第２のシステムのデ
ータとして残すことが可能となる。

【００８３】また、この発明によれば、第２のデータ反
映過程においては、第２のスナップショットデータが持
つ更新時刻情報と第１のシステムが管理し現在の日付ま
たは日時を表す現在日時情報との差が所定範囲内の場合
にのみ、第２のスナップショットデータを用いて第１の
システムのデータを更新するため、システムオペレーシ
ョン上の誤り等の理由によって所定範囲外の古い更新に
基づくスナップショットデータが読み込まれた場合に
も、これを検出することができる。

【００８４】また、この発明によれば、独立更新過程に
おいて、第２のシステム上で監査対象データ項目のデー
タの変更が生じた際に、当該監査対象データ項目の変更
前の値を保持したまま、当該監査対象データ項目に対応
付けられた変更後データを更新し、前記第２のデータ反
映過程において、前記監査対象データ項目が変更されて
いるデータだけを抽出して監査結果データとして出力す
るため、大量に行われるデータ更新の中から限られた量
の監査データをチェックすれば良くなり、監査効率を向
上させることが可能となる。

【００８５】また、この発明によれば、独立更新過程に
おいて第２のシステムのデータ更新の際に、更新前のデ
ータを当該データを無効にする無効化データによって置
き換えて保存するとともに、更新後のデータを無効後再
生成データとして新たに生成し、第２のデータ反映過程
において無効化データおよび無効後再生成データを抽出
して監査結果データとして出力するため、大量に行われ
るデータ更新の中から限られた量の監査データをチェッ
クすれば良くなり、監査効率を向上させることが可能と
なる。

【００８６】また、この発明によれば、第１のアプリケ
ーション処理部は、予約受付の処理を行って予約に関す
るデータを更新し、第２のアプリケーション処理部は、
第１のアプリケーション処理部によって受け付けられた
予約に基づいて行われる活動の実績のデータを更新する
ため、予約から治療、手術、入金管理にいたるまで、総
合的な医療業務管理システムを安価な通信コストで実現
することが可能となる。

【図面の簡単な説明】

【図１】 この発明の一実施形態による医療業務管理シ
ステムの構成を示すブロック図である。

【図２】 同実施形態による医療業務管理システムにお
いて用いられる患者マスタのデータ構造を示す表図であ
る。

【図３】 同実施形態による医療業務管理システムにお
いて用いられる患者履歴マスタのデータ構造を示す表図
である。

【図４】 同実施形態による医療業務管理システムにお
いて用いられる分院マスタのデータ構造を示す表図であ
る。

【図５】 同実施形態による医療業務管理システムにお
いて用いられる患者来院データのデータ構造を示す表図
である。

【図６】 同実施形態による医療業務管理システムにお
いて用いられる予約受付データのデータ構造を示す表図
である。

【図７】 同実施形態によるセンタシステム側および分
院システム側でのデータの更新および相手側への反映の
処理手順を示すシーケンス図である。

【図８】 同実施形態による前記患者来院データの更新
例を示す表図である。

【図９】 同実施形態によるスナップショットデータの
日付チェックするためのセンタシステムの構成を示すブ
ロック図である。

【図１０】 同実施形態によるデータ更新履歴の保存お
よび管理の例を示す表図である。

【図１１】 同実施形態によるデータ更新履歴の保存お
よび管理の例を示す表図である。

【図１２】 同実施形態による監査のための構成を示す
ブロック図である。

【図１３】 従来技術による分散データの管理方法を示
す参考図である。

【符号の説明】

１ ＩＳＤＮ ２０ センタシステム ２２ インポート／エクスポートサブシステム ２４ アプリケーション処理部 ２７ システム日付記憶部 ２９ 監査結果データ ３０ａ，３０ｂ データベース ３１ａ，３１ｂ 患者マスタ ３２ａ，３２ｂ 患者履歴マスタ ３３ａ，３３ｂ 予約受付データ ３４ａ，３４ｂ 患者来院データ ３５ａ，３５ｂ 手術内容データ ３６ａ，３６ｂ 入金データ ４０ ＦＴＰサーバ ４６ 下りスナップショットデータ ４８ 上りスナップショットデータ ６０ 分院システム ６２ インポート／エクスポートサブシステム ６４ アプリケーション処理部 ６６ 下りスナップショットデータ ６８ 上りスナップショットデータ

フロントページの続き (72)発明者 ▲高▼田 誠二 東京都千代田区大手町２−２−２ アーバ ンネット大手町ビル 株式会社エヌ・テ ィ・ティエムイー内 (72)発明者 ▲斎▼藤 隆幸 東京都千代田区大手町２−２−２ アーバ ンネット大手町ビル 株式会社エヌ・テ ィ・ティエムイー内 (72)発明者 杉本 晋司 東京都千代田区大手町２−２−２ アーバ ンネット大手町ビル 株式会社エヌ・テ ィ・ティエムイー内 (72)発明者 土井 慎司 東京都千代田区大手町２−２−２ アーバ ンネット大手町ビル 株式会社エヌ・テ ィ・ティエムイー内 (72)発明者 林 正之 東京都千代田区大手町２−２−２ アーバ ンネット大手町ビル 株式会社エヌ・テ ィ・ティエムイー内 (72)発明者 志村 重光 東京都千代田区大手町２−２−２ アーバ ンネット大手町ビル 株式会社エヌ・テ ィ・ティエムイー内 (72)発明者 増田 英久 東京都港区三田３−４−10 リーラ聖坂 株式会社エイプルジャパン内 (72)発明者 阿井 秀虎 東京都港区三田３−４−10 リーラ聖坂 株式会社エイプルジャパン内 (72)発明者 金子 久志 東京都港区三田３−４−10 リーラ聖坂 株式会社エイプルジャパン内 (72)発明者 工島 芳和 東京都港区三田３−４−10 リーラ聖坂 株式会社エイプルジャパン内 (72)発明者 宇田川 裕子 東京都港区三田３−４−10 リーラ聖坂 株式会社エイプルジャパン内 (72)発明者 星野 大祐 東京都港区三田３−４−10 リーラ聖坂 株式会社エイプルジャパン内 (72)発明者 大山 有紀子 東京都港区三田３−４−10 リーラ聖坂 株式会社エイプルジャパン内 (72)発明者 小野 峰史 東京都港区三田３−４−10 リーラ聖坂 株式会社エイプルジャパン内 Ｆターム(参考） 5B045 BB28 BB42 DD17 DD18 EE06 GG01 5B082 GA04 GA14 GB02 5B085 BA06 BG03 BG04

Claims (17)

【特許請求の範囲】
1. 【請求項１】 複数のシステムにおいて独立に更新され
   るデータの一貫性を維持するための分散処理方法であっ
   て、 第１のシステムおよび第２のシステムにおいてそれぞれ
   独立にデータを更新する独立更新過程と、 前記独立更新過程における前記第１のシステムによるデ
   ータの更新の差分が少なくとも含まれる第１のスナップ
   ショットデータを前記第１のシステムから前記第２のシ
   ステムに伝送する第１のデータ伝送過程と、 前記第１のスナップショットデータを基に前記第２のシ
   ステムにおいてデータを更新する第１のデータ反映過程
   と、 前記独立更新過程における前記第２のシステムによるデ
   ータの更新の差分が少なくとも含まれる第２のスナップ
   ショットデータを前記第２のシステムから前記第１のシ
   ステムに伝送する第２のデータ伝送過程と、 この第２のスナップショットデータを基に前記第１のシ
   ステムにおいてデータを更新する第２のデータ反映過程
   と、 を有することを特徴とする分散処理方法。
2. 【請求項２】 前記第１のデータ伝送過程において、前
   記第１のスナップショットデータの伝送前に前記第１の
   システムと第２のシステムとの間の通信を接続し、当該
   伝送後に当該通信を切断し、 前記第２のデータ伝送過程において、前記第２のスナッ
   プショットデータの伝送前に前記第１のシステムと第２
   のシステムとの間の通信を接続し、当該伝送後に当該通
   信を切断することを特徴とする請求項１に記載の分散処
   理方法。
3. 【請求項３】 前記独立更新過程において、データ更新
   の際にはデータ更新が行われた時刻を表す更新時刻情報
   を更新後のデータとともに記録し、 前記第２のスナップショットデータは前記更新時刻情報
   を含んでおり、 前記第２のデータ反映過程においては、前記第１のシス
   テムのデータが持つ前記更新時刻情報と前記第２のスナ
   ップショットデータが持つ前記更新時刻情報とを比較
   し、前記第２のスナップショットデータのほうがより新
   しく更新されたデータである場合にのみ、前記第２のス
   ナップショットデータを用いて前記第１のシステムのデ
   ータを更新することを特徴とする請求項１または２に記
   載の分散処理方法。
4. 【請求項４】 前記第１のスナップショットデータは前
   記更新時刻情報を含んでおり、 前記第１のデータ反映過程においては、前記第２のシス
   テムのデータが持つ前記更新時刻情報と前記第１のスナ
   ップショットデータが持つ前記更新時刻情報とを比較
   し、前記第１のスナップショットデータのほうがより新
   しく更新されたデータである場合にのみ、前記第１のス
   ナップショットデータを用いて前記第２のシステムのデ
   ータを更新することを特徴とする請求項３に記載の分散
   処理方法。
5. 【請求項５】 前記第２のデータ反映過程においては、
   前記第２のスナップショットデータが持つ前記更新時刻
   情報と前記第１のシステムが管理し現在の日付または日
   時を表す現在日時情報との差が所定範囲内の場合にの
   み、前記第２のスナップショットデータを用いて前記第
   １のシステムのデータを更新することを特徴とする請求
   項３または４に記載の分散処理方法。
6. 【請求項６】 前記第１のシステムおよび前記第２のシ
   ステムはデータの更新履歴を表す履歴データを保持して
   おり、 前記独立更新過程において、データ更新の際に、当該デ
   ータに関する当該更新前の履歴データを削除あるいは上
   書きすることなく当該更新に関する新たな履歴データを
   蓄積することを特徴とする請求項１から５までのいずれ
   かに記載の分散処理方法。
7. 【請求項７】 前記独立更新過程において、前記第２の
   システム上で監査対象データ項目のデータの変更が生じ
   た際に、当該監査対象データ項目の変更前の値を保持し
   たまま、当該監査対象データ項目に対応付けられた変更
   後データを更新し、 前記第２のデータ反映過程において、前記監査対象デー
   タ項目が変更されているデータだけを抽出して監査結果
   データとして出力することを特徴とする請求項１から６
   までのいずれかに記載の分散処理方法。
8. 【請求項８】 前記独立更新過程において、更新対象と
   なるデータの日付が、更新時現在の日付から予め設定さ
   れたバックデート更新許容上限日数を減じた日付よりも
   古い場合には、当該更新を拒絶する処理を行うことを特
   徴とする請求項１から７までのいずれかに記載の分散処
   理方法。
9. 【請求項９】 第１のシステムおよび第２のシステムに
   おいて独立にデータの更新を行う分散処理システムであ
   って、 第１のシステムにおいてデータの更新を行う第１のアプ
   リケーション処理部と、 第２のシステムにおいてデータの更新を行う第２のアプ
   リケーション処理部と、 前記第１のアプリケーション処理部によるデータの更新
   の差分が少なくとも含まれる第１のスナップショットデ
   ータを出力する第１のインポート／エクスポート処理部
   と、 前記第１のスナップショットデータを取得し、この第１
   のスナップショットデータを基に前記第２のシステムに
   おいてデータを更新する第２のインポート／エクスポー
   ト処理部と、 を有し、 前記第２のインポート／エクスポート処理部は、前記第
   ２のアプリケーション処理部によるデータの更新の差分
   が少なくとも含まれる第２のスナップショットデータを
   出力し、 前記第１のインポート／エクスポート処理部は、前記第
   ２のスナップショットデータを取得し、この第２のスナ
   ップショットデータを基に前記第１のシステムにおいて
   データを更新することを特徴とする分散処理システム。
10. 【請求項１０】 前記第１のスナップショットデータを
    前記第１のシステムから前記第２のシステムに伝送する
    前に前記第１のシステムと前記第２のシステムとの間の
    通信を接続し当該伝送後に当該通信を切断し、 前記第２のスナップショットデータを前記第２のシステ
    ムから前記第１のシステムに伝送する前に前記第１のシ
    ステムと前記第２のシステムとの間の通信を接続し当該
    伝送後に当該通信を切断することを特徴とする請求項９
    に記載の分散処理システム。
11. 【請求項１１】 前記第１のアプリケーション処理部お
    よび前記第２のアプリケーション処理部は、データ更新
    の際にデータ更新が行われた時刻を表す更新時刻情報を
    更新後のデータとともに記録し、 前記第２のインポート／エクスポート処理部は、前記更
    新時刻情報を含んだ前記第２のスナップショットデータ
    を出力し、 前記第１のインポート／エクスポート処理部は、前記第
    １のアプリケーション処理部によって記録された前記更
    新時刻情報と前記第２のスナップショットデータに含ま
    れた前記更新時刻情報とを比較し、前記第２のスナップ
    ショットデータのほうがより新しく更新されたデータで
    ある場合にのみ、前記第２のスナップショットデータを
    用いて前記第１のシステムのデータを更新することを特
    徴とする請求項９または１０に記載の分散処理システ
    ム。
12. 【請求項１２】 前記第１のインポート／エクスポート
    処理部は、前記更新情報を含んだ前記第１のスナップシ
    ョットデータを出力し、 前記第２のインポート／エクスポート処理部は、前記第
    ２のアプリケーション処理部によって記録された前記更
    新時刻情報と前記第１のスナップショットデータに含ま
    れた前記更新時刻情報とを比較し、前記第１のスナップ
    ショットデータのほうがより新しく更新されたデータで
    ある場合にのみ、前記第１のスナップショットデータを
    用いて前記第２のシステムのデータを更新することを特
    徴とする請求項１１に記載の分散処理システム。
13. 【請求項１３】 前記第１のインポート／エクスポート
    処理部は、前記第２のスナップショットデータに含まれ
    る前記更新時刻情報と前記第１のシステムが管理し現在
    の日付または日時を表す現在日時情報との差が所定範囲
    内の場合にのみ、前記第２のスナップショットデータを
    用いて前記第１のシステムのデータを更新することを特
    徴とする請求項１１または１２に記載の分散処理システ
    ム。
14. 【請求項１４】 前記第１のシステムおよび前記第２の
    システムはデータの更新履歴を表す履歴データを保持し
    ており、 前記第１のアプリケーション処理部および前記第２のア
    プリケーション処理部は、データ更新の際に、当該デー
    タに関する当該更新前の履歴データを削除あるいは上書
    きすることなく当該更新に関する新たな履歴データを蓄
    積することを特徴とする請求項９から１３までのいずれ
    かに記載の分散処理システム。
15. 【請求項１５】 前記第２のアプリケーション処理部
    は、前記第２のシステム上で監査対象データ項目のデー
    タの変更が生じた際に、当該監査対象のデータ項目の変
    更前の値を保持したまま、当該監査対象データ項目に対
    応付けられた変更後データを更新し、 前記第１のインポート／エクスポート処理部は、前記監
    査対象データ項目が変更されているデータだけを抽出し
    て監査結果データとして出力することを特徴とする請求
    項９から１４までのいずれかに記載の分散処理システ
    ム。
16. 【請求項１６】 前記第２のアプリケーション処理部
    は、更新対象となるデータの日付が、更新時現在の日付
    から予め設定されたバックデート更新許容上限日数を減
    じた日付よりも古い場合には、当該更新を拒絶する処理
    を行うことを特徴とする請求項８から１５までのいずれ
    かに記載の分散処理システム。
17. 【請求項１７】 前記第１のアプリケーション処理部
    は、予約受付の処理を行って予約に関するデータを更新
    し、 前記第２のアプリケーション処理部は、前記第１のアプ
    リケーション処理部によって受け付けられた予約に基づ
    いて行われる活動の実績のデータを更新することを特徴
    とする請求項９から１６までのいずれかに記載の分散処
    理システム。