JP6926594B2 - データ更新処理プログラム、データ更新処理装置及びデータ更新処理方法 - Google Patents

Description

本発明は、データ更新処理プログラム、データ更新処理装置及びデータ更新処理方法に関する。

医療機関内で使用されている医薬品や検査項目は、電子カルテ上、医療機関内で独自に付番されたコード（以下、「ローカルコード」と呼ぶ）を用いて管理されている。これに対し、最近では、複数の医療機関における診療情報を収集することで診療情報の交換、共有、分析等を行う事業（例えば、厚生労働省電子的診療情報交換推進事業（ＳＳ−ＭＩＸ：Standardized Structured Medical Information eXchangeやＳＳ−ＭＩＸ２））が立ち上がってきている。

このような事業において各医療機関から電子カルテデータを収集する場合、ローカルコードからは医薬品や検査項目を識別することはできないため、一意に識別可能な標準コードとして、ＨＯＴ（医薬品の標準コード）や、ＪＬＡＣ１０（検査の標準コード）を用いる必要がある。

なお、従来、電子カルテの入力非標準コード用語を、標準コードに変換して表示する技術が知られている（例えば、特許文献１等参照）。

特開２００５−３２０９６号公報

電子カルテのマスタにおいて、ローカルコードに対して正しい標準コードが管理できていれば問題ないが、マスタへの登録漏れや標準コードとローカルコードの紐付けミスなどがあると、マスタを修正する必要がある。この場合、マスタ変更前に収集したデータについても、改めて収集しなおす必要がある。

しかしながら、収集したデータの全てを再収集するのでは、長時間を要するし、収集したデータの中から再収集するデータを人手で探し出すのでは、手間と労力を要する。

１つの側面では、本発明は、標準コードの変更があった場合に、再生成すべき登録情報を抽出することが可能なデータ更新処理プログラム、データ更新処理装置及びデータ更新処理方法を提供することを目的とする。

一つの態様では、データ更新処理プログラムは、医療機関で生成されたデータから、前記医療機関で用いられるローカルコードと前記医療機関以外で定められた標準コードとを含むメッセージ形式の登録情報を生成して、第１記憶部に記憶し、記憶した前記登録情報に含まれるローカルコードと前記登録情報のキー情報とを対応付けて、第２記憶部に記憶し、前記標準コードと前記ローカルコードとを対応付けて記憶する第３記憶部において標準コードの変更があった場合に、前記第２記憶部を参照して、変更された標準コードに対応するローカルコードに対応付けられている前記登録情報のキー情報を抽出し、抽出した前記キー情報に対応する前記医療機関で生成されたデータからメッセージ形式の登録情報を再生成し前記第１記憶部に記憶する、処理をコンピュータに実行させるためのプログラムである。

標準コードの変更があった場合に、再生成すべき登録情報を抽出することができる。

一実施形態に係るデータ収集システムの構成を概略的に示す図である。 電子カルテサーバ及びデータ収集サーバのハードウェア構成を示す図である。 電子カルテサーバ及びデータ収集サーバの機能ブロック図である。 電子カルテマスタのデータ構造の一例を示す図である。 図５（ａ）は、ＤＢ更新イベントテーブルのデータ構造の一例を示す図であり、図５（ｂ）は、マスタ更新イベントテーブルのデータ構造の一例を示す図である。 図６（ａ）、図６（ｂ）は、フォルダ・ファイル形式のデータについて説明するための図である。 出力済みテーブルのデータ構造の一例を示す図である。 ファイルの更新について説明するための図である。 図９（ａ）、図９（ｂ）は、データ更新時の処理を示すフローチャートである。 マスタ更新時の処理を示すフローチャートである。 バッチ処理を示すフローチャートである。 変形例（その１）における電子カルテサーバ、中継サーバ及びデータ収集サーバの機能ブロック図である。 変形例（その２）における電子カルテサーバ及びデータ収集サーバの機能ブロック図である。

以下、一実施形態について、図１〜図１１に基づいて詳細に説明する。

図１には、本実施形態に係るデータ収集システム１００の構成が概略的に示されている。本実施形態のデータ収集システム１００は、医療機関において蓄積される電子カルテデータを収集して、分析等を行うためのシステムであり、ＳＳ−ＭＩＸやＳＳ−ＭＩＸ２の仕様に基づくシステムである。

図１に示すように、データ収集システム１００は、電子カルテサーバ７０と、データ更新処理装置としてのデータ収集サーバ１０とを備える。電子カルテサーバ７０とデータ収集サーバ１０は、インターネットなどのネットワーク８０に接続されている。なお、実際には、電子カルテサーバ７０は複数存在し、それぞれがネットワーク８０に接続されているものとする。

電子カルテサーバ７０は、医療機関ごとに設置されるサーバであり、医療機関内において生成される電子カルテ情報を管理する。電子カルテサーバ７０は、図２に示すようなハードウェア構成を有する。図２に示すように、電子カルテサーバ７０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これら電子カルテサーバ７０の構成各部は、バス９８に接続されている。電子カルテサーバ７０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラムをＣＰＵ９０が実行することにより、図３に示す、各部の機能が実現される。なお、図３には、ＨＤＤ９６等に格納されている電子カルテＤＢ８２及び電子カルテマスタ８４も図示されている。なお、電子カルテサーバ７０の各機能及びＤＢ，マスタの詳細については後述する。

データ収集サーバ１０は、複数の電子カルテサーバ７０から電子カルテ情報を収集し、第１記憶部としての標準化ストレージ４０（図３参照）に格納するサーバである。データ収集サーバ１０は、図２に示すように、電子カルテサーバ７０と同様のハードウェア構成を有している。すなわち、データ収集サーバ１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ＨＤＤ）９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。データ収集サーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（データ更新処理プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（データ更新処理プログラムを含む）をＣＰＵ９０が実行することにより、図３に示す、各部の機能が実現される。なお、図３には、ＨＤＤ９６等に格納されている各種テーブル等も図示されている。

次に、図３に基づいて、電子カルテサーバ７０及びデータ収集サーバ１０の機能について、詳細に説明する。図３に示すように、電子カルテサーバ７０は、データ入力部７２、及び第３記憶部としてのマスタ更新部７４、の機能を有する。

データ入力部７２は、医療機関に属する医療従事者（医師や看護師、医療事務など）から入力されたデータを電子カルテＤＢ８２に格納する。電子カルテＤＢ８２には、電子カルテデータが格納されており、データ収集サーバ１０からのアクセスが可能となっている。

マスタ更新部７４は、電子カルテサーバ７０の管理者等から入力されたマスタの更新情報を取得して、電子カルテマスタ８４を更新する。ここで、電子カルテマスタ８４は、一例として、図４に示すようなデータ構造を有する。すなわち、電子カルテマスタ８４には、医療機関で医薬品や検査項目を管理するために独自に設定しているコード（ローカルコード）及び名称（ローカル名称）と、薬品や検査項目の標準コード（ＪＬＡＣ１０やＨＯＴコードなど）と、が対応付けて記憶されている。この電子カルテマスタ８４に記憶されている情報は、管理者等が手入力するため、誤りや抜け等がある場合がある。電子カルテマスタ８４に対しても、データ収集サーバ１０からのアクセスが可能となっている。

図３に戻り、データ収集サーバ１０は、更新イベント作成部１２、更新イベント取得部１４、抽出部としての更新データ取得部１６、データ変換部１８、及び格納処理部２０としての機能を有する。

更新イベント作成部１２は、電子カルテＤＢ８２の更新を検出した場合に、更新された電子カルテデータの一部の情報（キー情報）を電子カルテＤＢ８２から取得して、ＤＢ更新イベントテーブル３２に格納する。また、更新イベント作成部１２は、電子カルテマスタ８４の更新を検出した場合に、電子カルテマスタ８４において更新（変更や追加）された情報を取得して、マスタ更新イベントテーブル３０に格納する。

ここで、ＤＢ更新イベントテーブル３２は、図５（ａ）に示すようなデータ構造を有する。ＤＢ更新イベントテーブル３２には、電子カルテＤＢ８２のキー情報を格納でき、具体的には、図５（ａ）に示すように、「ボリュームラベル」、「医療機関ＩＤ」、「患者ＩＤ」、「診療日」、「データ種別」、「オーダＮｏ．」、「ローカルコード」の各データを格納することができる。

「ボリュームラベル」は、標準化ストレージ４０のルートディレクトリに対応した識別子であり、「医療機関ＩＤ」は、医療機関を一意に識別する識別情報である。「患者ＩＤ」は、患者の識別情報、「診療日」は、実際に診療が行われた年月日が格納される。「データ種別」は、データの種類（例えばオーダや、入院実施、退院実施、担当医の変更など）を示す文字列であり、「オーダＮｏ．」は、オーダの識別番号である。「ローカルコード」は、医療機関内で管理されている薬品や検査項目に対して割り当てられたコード番号である。

また、マスタ更新イベントテーブル３０は、図５（ｂ）に示すようなデータ構造を有する。具体的には、マスタ更新イベントテーブル３０には、「ローカルコード」、「変更後標準コード」、及び「変更発生日時」が対応付けて格納される。

「ローカルコード」は、ＤＢ更新イベントテーブル３２のローカルコードと同様であり、「変更後標準コード」は、変更された後の標準コードである。「変更発生日時」は、標準コードの変更があった（検出した）日時の情報である。

更新イベント取得部１４は、ＤＢ更新イベントテーブル３２が更新された場合（データが追加された場合）に、更新（追加）された情報をＤＢ更新イベントテーブル３２から取得する。また、更新イベント取得部１４は、夜間等におけるバッチ処理により、マスタ更新イベントテーブル３０に更新があったかを判断し、更新があった場合に、更新（追加）された情報をマスタ更新イベントテーブル３０から取得する。更新イベント取得部１４は、取得した情報を更新データ取得部１６に受け渡す。

更新データ取得部１６は、更新イベント取得部１４からＤＢ更新イベントテーブル３２の更新情報（追加されたキー情報）を受け取った場合に、更新情報（追加されたキー情報）を用いて、電子カルテＤＢ８２から更新された電子カルテデータを取得する。更新データ取得部１６は、取得した電子カルテデータをデータ変換部１８に受け渡す。この場合、データ変換部１８は、取得した電子カルテデータを加工し、フォルダ・テキスト形式のデータを生成する。そして、格納処理部２０は、ＳＳ−ＭＩＸやＳＳ−ＭＩＸ２において策定された標準化ストレージ４０に対する格納仕様に従って、フォルダ・テキスト形式のデータを標準化ストレージ４０に出力（ＳＳ−ＭＩＸ出力）する。

ここで、フォルダ・テキスト形式のデータとは、図６（ａ）に示すように、階層化されたフォルダにファイル（ＨＬ７ファイル）を格納する形式のデータである。ファイルは、図６（ｂ）に示すようなテキストファイルである。図６（ｂ）の例は、検体検査オーダに対するメッセージであり、電子カルテで医師が検体検査の依頼オーダを発行した際のデータである。

図６（ｂ）において、下線を付した箇所には、標準コードとローカルコードが記載されている。例えば、「2B0300000022311^PT^JC10^30046^PT^99X03」であれば、「2B0300000022311」が検査項目名称「PT」に対する検査項目の標準コード（JLAC10）を意味し、「30046」が、検査項目名称「PT」に対し、病院の電子カルテ独自に管理しているローカルコードを意味する。なお、図６（ｂ）の例では、JLAC10コードが記載されているが、医薬品のコードであるHOTコードなどもある。基本的には、電子カルテでは、病院で独自のコード（ローカルコード）を付番して検査項目や医薬品を管理しているが、本システムにおいてデータを利活用するために、業界標準である標準コードが対応付けられている。

格納処理部２０は、上述したようにフォルダ・テキスト形式のデータを標準化ストレージ４０に出力すると、電子カルテデータのキー情報とともに、出力したデータ内から抽出されるローカルコードと標準コードの組み合わせを、第２記憶部としての出力済みテーブル３４に登録する。

ここで、出力済みテーブル３４は、図７に示すようなデータ構造を有する。具体的には、出力済みテーブル３４は、図７に示すように、図５（ａ）のＤＢ更新イベントテーブル３２と同様のデータに加え、「診療科コード」、「ファイル名」、「標準コード」、「再出力用キー」が格納される。

「診療科コード」は、診療を行った診療科の識別コードであり、「ファイル名」は、ファイルの名称である。また、「標準コード」は、ローカルコードに対応する標準コード（電子カルテマスタ８４でローカルコードに対応付けられている標準コード）である。「再出力用キー」は、電子カルテのデータを一意に取得するために必要なキー情報である。なお、「再出力用キー」については、出力済みテーブル３４から省略してもよい。ここで、格納処理部２０は、標準化ストレージ４０に出力したフォルダ・テキスト形式のデータからローカルコードと標準コードの組み合わせを複数抽出できる場合がある。この場合、全ての組み合わせが異なる場合には、全ての組み合わせを出力済みテーブル３４に格納する。一方、組み合わせの中に重複する組み合わせが存在する場合には、重複する組み合わせは１つのみ出力済みテーブル３４に格納する（すなわち、重複する内容は格納しない）ものとする。

ところで、更新データ取得部１６は、バッチ処理の際に、更新イベント取得部１４からマスタ更新イベントテーブル３０の更新情報を受け取ることがある。この場合、更新データ取得部１６は、更新された標準コードに対応しているローカルコードをキーとして、出力済みテーブル３４に格納されている対応するデータを全て特定し、抽出する。そして、特定し、抽出したデータのキー情報又は再出力用キーを用いて、電子カルテＤＢ８２から電子カルテデータを再取得する。この再取得により、標準コードが更新後の標準コードになっている電子カルテデータを取得することができる。この場合、データ変換部１８は、上述したのと同様に、再取得した電子カルテデータを加工し、フォルダ・テキスト形式のデータを再生成する。そして、格納処理部２０は、フォルダ・テキスト形式のデータを標準化ストレージ４０に再出力する。この再出力においては、図８に示すようにしてメッセージを出力する。すなわち、初回オーダ時には、図８の右欄（名前の欄）の1行目（ただし末尾は１（有効））が格納されているが、マスタの変更があると、1行目の末尾を０に変更して、無効にする。そして、２行目に示すように削除オーダを発行した後、３行目の新規オーダを発行する。

（データ収集サーバ１０の処理について）
次に、図９〜図１１のフローチャートに沿って、データ収集サーバ１０による処理について説明する。

（データ更新時の処理（その１））
図９（ａ）は、電子カルテＤＢ８２のデータの更新時の更新イベント作成部１２の処理を示すフローチャートである。図９（ａ）の処理では、まず、ステップＳ１０において、更新イベント作成部１２が、電子カルテＤＢ８２の更新があるまで待機する。更新イベント作成部１２は、電子カルテＤＢ８２を監視し、直前の状態との差分に基づいて、更新があったか否かを判断する。電子カルテＤＢ８２の更新があった場合、更新イベント作成部１２は、ステップＳ１２に移行する。なお、データ入力部７２が電子カルテＤＢ８２を更新した場合に、更新イベント作成部１２にその旨を通知するようにしてもよい。

ステップＳ１２に移行すると、更新イベント作成部１２が、更新されたデータのキー情報を取得し、ＤＢ更新イベントテーブル３２に格納する。その後は、ステップＳ１０に戻り、更新イベント作成部１２は、ステップＳ１０、Ｓ１２の処理・判断を繰り返し実行する。

（データ更新時の処理（その２））
図９（ｂ）は、電子カルテマスタ８４が更新されたときの、更新イベント取得部１４、更新データ取得部１６、データ変換部１８、格納処理部２０の処理を示すフローチャートである。

図９（ｂ）の処理では、まず、ステップＳ２０において、更新イベント取得部１４が、ＤＢ更新イベントテーブル３２にデータが存在するか否かを判断する。ここでの判断が否定された場合には、ステップＳ２０を繰り返し実行するが、肯定された場合には、ステップＳ２２に移行する。

ステップＳ２２に移行すると、更新イベント取得部１４が、ＤＢ更新イベントテーブル３２のキー情報を取得して更新データ取得部１６に受け渡す。そして、更新データ取得部１６が、受け取ったキー情報に基づいて、電子カルテＤＢ８２のデータを取得する。これにより、更新データ取得部１６は、更新された電子カルテデータを電子カルテＤＢ８２から取得することができる。

次いで、ステップＳ２４では、データ変換部１８が、更新データ取得部１６が取得した電子カルテデータを加工してフォルダ・テキスト形式のデータとし、格納処理部２０が、フォルダ・テキスト形式のデータを標準化ストレージ４０に出力する。

次いで、ステップＳ２６では、格納処理部２０が、キー情報とともに、出力したデータが有するローカルコードと標準コードの組み合わせを含む情報を出力済みテーブル３４に登録する。ここで、出力したデータに、ローカルコードと標準コードの組み合わせが複数存在する場合がある。このような場合には、すべての組み合わせを出力済みテーブル３４に登録する。ただし、重複する組み合わせ（ローカルコードと標準コードが一致する組み合わせ）については、１つのみ登録するものとする。

そして、ステップＳ２８では、更新イベント取得部１４が、ＤＢ更新イベントテーブル３２から取得したキー情報を削除する。なお、ＤＢ更新イベントテーブル３２から取得したキー情報は、ステップＳ２２の後（キー情報を取得した直後）に削除してもよい。ステップＳ２８の処理の後は、ステップＳ２０に戻り、以降ステップＳ２０〜Ｓ２８の処理が繰り返し実行される。

（マスタ更新時の処理）
図１０は、マスタが更新されたときに更新イベント作成部１２により実行される処理を示すフローチャートである。

図１０の処理では、まずステップＳ３０において、更新イベント作成部１２が、電子カルテマスタ８４のうち、いずれかの標準コードが更新されたか否かを判断する。このステップＳ３０の判断が否定された場合には、ステップＳ３０を繰り返し実行するが、肯定された場合には、ステップＳ３２に移行する。なお、電子カルテマスタ８４の標準コード以外（名称など）が変更された場合には、ステップＳ３０の判断は否定される（ステップＳ３２以降の処理は行わない）ものとする。なお、マスタ更新部７４が電子カルテマスタ８４の標準コードを更新した場合に、更新イベント作成部１２にその旨を通知するようにしてもよい。

ステップＳ３２に移行した場合、更新イベント作成部１２は、更新があった標準コードに対応するローカルコードがマスタ更新イベントテーブル３０に存在しているか否かを判断する。このステップＳ３２の判断が肯定された場合には、ステップＳ３４に移行し、更新イベント作成部１２が、マスタ更新イベントテーブル３０を更新する。すなわち、マスタ更新イベントテーブル３０の変更後標準コードと変更発生日時とを、新たな標準コードと変更発生日時とで更新する。一方、ステップＳ３２の判断が否定された場合には、ステップＳ３６に移行し、更新イベント作成部１２は、マスタ更新イベントテーブル３０にローカルコード、変更後標準コード、および変更発生日時を新規登録する。

以上のようにして、ステップＳ３４又はステップＳ３６の処理が行われた後は、ステップＳ３０に戻る。ステップＳ３０に戻った後は、上述した処理が繰り返し実行される。

（バッチ処理）
バッチ処理は、データ収集サーバ１０の負荷が少ない夜間などにおいて１日１回程度実行される処理である。図１１には、バッチ処理のフローチャートが示されている。

図１１では、まずステップＳ４０において、更新イベント取得部１４が、前回のバッチ処理終了時以降において、マスタ更新イベントテーブル３０に新たに追加されたデータがあるか否かを判断する。この場合、更新イベント取得部１４は、マスタ更新イベントテーブル３０の変更発生日時を確認し、バッチ処理終了時以降に新たに追加されたデータを特定する。このステップＳ４０の判断が否定された場合には、バッチ処理において処理すべきデータがないため、図１１の全処理を終了する。一方、ステップＳ４０の判断が肯定された場合には、ステップＳ４２に移行する。

ステップＳ４２に移行すると、更新イベント取得部１４は、新たにマスタ更新イベントテーブル３０に追加されたデータのローカルコードを取得する。そして、更新データ取得部１６は、取得したローカルコードをキーとして、出力済みテーブル３４から合致するレコードをすべて取得する。このステップＳ４２では、更新があった標準コードに対応するローカルコードを含んでいる電子カルテデータを出力済みテーブル３４において特定し、キー情報等を抽出しているといえる。

次いで、ステップＳ４４では、更新データ取得部１６が、取得した全レコードの処理が終了したか否かを判断する。このステップＳ４４の判断が肯定された場合には、ステップＳ４０に戻るが、否定された場合には、ステップＳ４６に移行する。

ステップＳ４６に移行すると、更新データ取得部１６は、取得したレコードの中から１つのレコードを特定する。次いで、ステップＳ４８では、更新データ取得部１６が、特定したレコードの標準コードがマスタ更新イベントテーブル３０の更新コードと異なるか否かを判断する。このステップＳ４８の判断が否定された場合には、特定したレコードに関して、特に処理を行う必要がないため、ステップＳ４４に戻る。一方、ステップＳ４８の判断が肯定された場合には、ステップＳ５０に移行する。

ステップＳ５０に移行すると、更新データ取得部１６は、特定したレコードに基づいて、電子カルテＤＢ８２から電子カルテデータを取得する。

次いで、ステップＳ５２では、データ変換部１８が、更新データ取得部１６が取得した電子カルテデータを加工してフォルダ・テキスト形式のデータとし、格納処理部２０が、フォルダ・テキスト形式のデータを標準化ストレージ４０に出力する。

次いで、ステップＳ５４では、格納処理部２０が、キー情報とともに、出力したデータ内に含まれるローカルコードと標準コードの組み合わせを出力済みテーブル３４に登録する。

その後は、ステップＳ４４に戻り、ステップＳ４２において取得した全レコードの処理が終わるまで、ステップＳ４６〜Ｓ５４の処理・判断を繰り返す。そして、ステップＳ４４の判断が肯定されると、ステップＳ４０に戻る。ステップＳ４０に戻った場合、更新イベント取得部１４が、前回のバッチ処理終了時以降に新たに追加されたデータがまだ残っているかを判断し、残っていれば、上述した処理を実行し、残っていなければ（ステップＳ４０：否定）、図１１の全処理を終了する。

これまでの説明から明らかなように、本実施形態では、更新データ取得部１６、データ変換部１８、格納処理部２０により、標準化ストレージ４０にデータを格納する第１処理部及び第３処理部としての機能が実現されている。また、格納処理部２０により、標準化ストレージ４０に記憶したデータとローカルコードとを対応付けて出力済みテーブル３４に記憶する第２処理部及び第４処理部としての機能が実現されている。

以上、詳細に説明したように、本実施形態によると、更新データ取得部１６、データ変換部１８、格納処理部２０は、医療機関で生成された電子カルテデータから、ローカルコードと標準コードとを含むメッセージ形式（テキスト形式）のファイルを生成して、標準化ストレージ４０に出力する。また、格納処理部２０は、出力したファイルに含まれるローカルコードとファイルの情報とを対応付けて、出力済みテーブル３４に記憶する。そして、更新データ取得部１６は、電子カルテマスタ８４の標準コードの変更があった場合に、出力済みテーブル３４を参照して、変更された標準コードに対応するローカルコードに対応付けられているファイルの情報を抽出する。これにより、出力済みテーブル３４において、出力済みのファイルの情報とファイルに含まれるローカルコードとが対応付けられているため、標準コードが変更されたときに再出力する必要のあるファイルを特定することが可能となっている。この場合、管理者等が人手によって再出力すべきファイルを特定する必要がないため、利便性が高い。また、すべての標準化ストレージ４０に出力されたデータを再出力しなくてもよいため、再出力に要する時間を短縮することができる。

また、本実施形態では、階層化されたフォルダ内にメッセージ形式（テキスト形式）のファイルが記憶されている。このように、人手ではファイルの中身を確認するのに手間を要する形式でファイルが管理されていても、自動的に再出力すべきファイルを特定することができる。

また、本実施形態では、出力したファイルにおいて、ローカルコードと標準コードの組み合わせが重複していた場合には、重複して出力済みテーブル３４に記憶させないようにしている。これにより、出力済みテーブル３４のデータ量の低減や、更新データ取得部１６による処理量の低減を図ることができる。

また、本実施形態では、ファイルを再出力した場合に、再出力したファイルとファイルに含まれるローカルコードとを対応付けて、出力済みテーブル３４に格納するため、標準コードが再度更新された場合にも、再出力すべきファイルを特定することができる。

また、本実施形態では、出力済みテーブル３４において、ファイルに対応付けて標準コードも記憶している。これにより、仮にローカルコードが更新された場合にも、標準コードに基づいて再出力すべきファイルを特定することが可能である。

なお、上記実施形態においては、データ収集サーバ１０が、電子カルテＤＢ８２と同一のデータを保持するレプリカＤＢを有していてもよい。この場合、更新データ取得部１６は、電子カルテＤＢ８２にアクセスせずに、レプリカＤＢから電子カルテデータを取得するようにしてもよい。

なお、上記実施形態においてデータ収集サーバ１０が有していた機能は、他の装置が有していてもよい。例えば、図１２に示すように、データ収集サーバ１０は、標準化ストレージ４０を有するものとし、データ収集サーバ１０と電子カルテサーバ７０との間に位置する中継サーバ６０が、上記実施形態においてデータ収集サーバ１０が有していた機能を有していてもよい。また、図１３に示すように、電子カルテサーバ７０が、上記実施形態においてデータ収集サーバ１０が有していた機能を有していてもよい。なお、図１２、図１３の例では、データ収集サーバ１０が、データを受信して、受信したデータを標準化ストレージ４０に格納するための受信アプリケーションを有していてもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） 医療機関で生成されたデータから、前記医療機関で用いられるローカルコードと前記医療機関以外で定められた標準コードとを含むメッセージ形式の登録情報を生成して、第１記憶部に記憶し、
記憶した前記登録情報に含まれるローカルコードと前記登録情報とを対応付けて、第２記憶部に記憶し、
前記標準コードと前記ローカルコードとを対応付けて記憶する第３記憶部において標準コードの変更があった場合に、前記第２記憶部を参照して、変更された標準コードに対応するローカルコードに対応付けられている前記登録情報を抽出する、
処理をコンピュータに実行させるためのデータ更新処理プログラム。
（付記２） 前記登録情報は、前記第１記憶部において、階層化されたフォルダ内に記憶されることを特徴とする付記１に記載のデータ更新処理プログラム。
（付記３） 前記登録情報に所定のローカルコードが複数含まれる場合、
前記第２記憶部に記憶する処理では、前記所定のローカルコードを重複して前記登録情報に対応付けないことを特徴とする付記１又は２に記載のデータ更新処理プログラム。
（付記４） 抽出した前記登録情報を再生成し、前記第１記憶部に記憶し、
再生成した前記登録情報と該登録情報に含まれるローカルコードとを対応付けて、前記第２記憶部に記憶する、処理を前記コンピュータに更に実行させる付記１〜３のいずれかに記載のデータ更新処理プログラム。
（付記５） 前記第２記憶部には、記憶する前記登録情報と対応付けて、該登録情報に含まれる標準コードを記憶する、ことを特徴とする付記１〜４のいずれかに記載のデータ更新処理プログラム。
（付記６） 医療機関で生成されたデータから、前記医療機関で用いられるローカルコードと前記医療機関以外で定められた標準コードとを含むメッセージ形式の登録情報を生成して、第１記憶部に記憶する第１処理部と、
前記第１記憶部に記憶した前記登録情報に含まれるローカルコードと前記登録情報とを対応付けて、第２記憶部に記憶する第２処理部と、
前記標準コードと前記ローカルコードとを対応付けて記憶する第３記憶部において標準コードの変更があった場合に、前記第２記憶部を参照して、変更された標準コードに対応するローカルコードに対応付けられている前記登録情報を抽出する抽出部と、
を備えるデータ更新処理装置。
（付記７） 前記登録情報は、前記第１記憶部において、階層化されたフォルダ内に記憶されることを特徴とする付記６に記載のデータ更新処理装置。
（付記８） 前記登録情報に所定のローカルコードが複数含まれる場合、
前記第２処理部は、前記所定のローカルコードを重複して前記登録情報に対応付けないことを特徴とする付記６又は７に記載のデータ更新処理装置。
（付記９） 抽出した前記登録情報を再生成し、前記第１記憶部に記憶する第３処理部と、
再生成した前記登録情報と該登録情報に含まれるローカルコードとを対応付けて、前記第２記憶部に記憶する第４処理部と、を更に備える付記６〜８のいずれかに記載のデータ更新処理装置。
（付記１０） 前記第２処理部は、前記第２記憶部に記憶する前記登録情報と対応付けて、該登録情報に含まれる標準コードを前記第２記憶部に記憶する、ことを特徴とする付記６〜９のいずれかに記載のデータ更新処理装置。
（付記１１） 医療機関で生成されたデータから、前記医療機関で用いられるローカルコードと前記医療機関以外で定められた標準コードとを含むメッセージ形式の登録情報を生成して、第１記憶部に記憶し、
記憶した前記登録情報に含まれるローカルコードと前記登録情報とを対応付けて、第２記憶部に記憶し、
前記標準コードと前記ローカルコードとを対応付けて記憶する第３記憶部において標準コードの変更があった場合に、前記第２記憶部を参照して、変更された標準コードに対応するローカルコードに対応付けられている前記登録情報を抽出する、
処理をコンピュータが実行することを特徴とするデータ更新処理方法。

１０ データ収集サーバ（データ更新処理装置）
１６ 更新データ取得部（第１処理部の一部、第３処理部の一部、抽出部）
１８ データ変換部（第１処理部の一部、第３処理部の一部）
２０ 格納処理部（第１処理部の一部、第３処理部の一部、第２処理部、第４処理部）
３４ 出力済みテーブル（第２記憶部）
４０ 標準化ストレージ（第１記憶部）
８４ 電子カルテマスタ（第３記憶部）

Claims (7)

1. 医療機関で生成されたデータから、前記医療機関で用いられるローカルコードと前記医療機関以外で定められた標準コードとを含むメッセージ形式の登録情報を生成して、第１記憶部に記憶し、
   記憶した前記登録情報に含まれるローカルコードと前記登録情報のキー情報とを対応付けて、第２記憶部に記憶し、
   前記標準コードと前記ローカルコードとを対応付けて記憶する第３記憶部において標準コードの変更があった場合に、前記第２記憶部を参照して、変更された標準コードに対応するローカルコードに対応付けられている前記登録情報のキー情報を抽出し、抽出した前記キー情報に対応する前記医療機関で生成されたデータからメッセージ形式の登録情報を再生成し前記第１記憶部に記憶する、
   処理をコンピュータに実行させるためのデータ更新処理プログラム。
2. 前記登録情報は、前記第１記憶部において、階層化されたフォルダ内に記憶されることを特徴とする請求項１に記載のデータ更新処理プログラム。
3. 前記登録情報に所定のローカルコードが複数含まれる場合、
   前記第２記憶部に記憶する処理では、前記所定のローカルコードを重複して前記登録情報のキー情報に対応付けないことを特徴とする請求項１又は２に記載のデータ更新処理プログラム。
4. 再生成した前記登録情報のキー情報と該登録情報に含まれるローカルコードとを対応付けて、前記第２記憶部に記憶する、処理を前記コンピュータに更に実行させる請求項１〜３のいずれか一項に記載のデータ更新処理プログラム。
5. 前記第２記憶部には、記憶する前記登録情報のキー情報と対応付けて、該登録情報に含まれる標準コードを記憶する、ことを特徴とする請求項１〜４のいずれか一項に記載のデータ更新処理プログラム。
6. 医療機関で生成されたデータから、前記医療機関で用いられるローカルコードと前記医療機関以外で定められた標準コードとを含むメッセージ形式の登録情報を生成して、第１記憶部に記憶する第１処理部と、
   前記第１記憶部に記憶した前記登録情報に含まれるローカルコードと前記登録情報のキー情報とを対応付けて、第２記憶部に記憶する第２処理部と、
   前記標準コードと前記ローカルコードとを対応付けて記憶する第３記憶部において標準コードの変更があった場合に、前記第２記憶部を参照して、変更された標準コードに対応するローカルコードに対応付けられている前記登録情報のキー情報を抽出し、抽出した前記キー情報に対応する前記医療機関で生成されたデータからメッセージ形式の登録情報を再生成し前記第１記憶部に記憶する抽出部と、
   を備えるデータ更新処理装置。
7. 医療機関で生成されたデータから、前記医療機関で用いられるローカルコードと前記医療機関以外で定められた標準コードとを含むメッセージ形式の登録情報を生成して、第１記憶部に記憶し、
   記憶した前記登録情報に含まれるローカルコードと前記登録情報のキー情報とを対応付けて、第２記憶部に記憶し、
   前記標準コードと前記ローカルコードとを対応付けて記憶する第３記憶部において標準コードの変更があった場合に、前記第２記憶部を参照して、変更された標準コードに対応するローカルコードに対応付けられている前記登録情報のキー情報を抽出し、抽出した前記キー情報に対応する前記医療機関で生成されたデータからメッセージ形式の登録情報を再生成し前記第１記憶部に記憶する、
   処理をコンピュータが実行することを特徴とするデータ更新処理方法。
   

Images