(57)【要約】【課題】通信網を介して情報を送受信する際に有効期限等を設定することなく機密性を確保することができる通信装置を提供する。【解決手段】薬局端末１１は、個人情報と医療情報とを含む直接請求レセプトファイル５１に基づいて、個人情報と異なりかつ個人情報と一意に対応する情報である対応付情報を生成するとともに、生成した対応付情報と個人情報とを含む個人情報ファイル５２ｅと、直接請求レセプトファイル５１を元に直接請求レセプトファイル５１に含まれる個人情報を削除し、かつ、生成した対応付情報を含ませた非個人情報レセプトファイル５３ｅとを作成する。薬局端末１１は、生成した個人情報ファイル５２ｅと非個人情報レセプトファイル５３ｅとを、センター２内の所定の異なるデータベースに対して通信網４を介しそれぞれ送信する。【選択図】図１
2013250937.tif 000002
【特許請求の範囲】
【請求項１】
所定の第１情報と所定の第２情報とを含む第１ファイルに基づいて、前記第１情報と異なりかつ前記第１情報と一意に対応する情報である対応付情報を生成する対応付情報生成手段と、
前記対応付情報と前記第１情報とを含む第２ファイルを作成する第２ファイル作成手段と、
前記第１ファイルを元に、前記第１ファイルに含まれる前記第１情報を削除し又は所定の第３情報に置き換え、かつ、前記対応付情報を含ませることで第３ファイルを作成する第３ファイル作成手段と、
前記第２ファイルと前記第３ファイルとを所定の異なるデータベースに対して通信網を介しそれぞれ送信する送信手段と
を備えることを特徴とする通信装置。
【請求項２】
前記対応付情報が、所定のハッシュ関数で生成された疑似乱数に対応するものである
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記対応付情報が、前記第２ファイル及び前記第３ファイルを生成する毎に変化する
ことを特徴とする請求項１又は２に記載の通信装置。
【請求項４】
前記第１情報が、保健医療に係る患者の個人情報又は当該保健医療に係る保険医師の個人情報を含み、
前記第２情報が、前記保健医療の内容を示す医療情報を含む
ことを特徴とする請求項１から３のいずれか１項に記載の通信装置。
【請求項５】
所定の第１情報と所定の第２情報とを含む第１ファイルに基づいて、前記第１情報と異なりかつ前記第１情報と一意に対応する情報である対応付情報を生成する対応付情報生成手段と、
前記対応付情報と前記第１情報とを含む第２ファイルを作成する第２ファイル作成手段と、
前記第１ファイルを元に、前記第１ファイルに含まれる前記第１情報を削除し又は所定の第３情報に置き換え、かつ、前記対応付情報を含ませることで第３ファイルを作成する第３ファイル作成手段と、
前記第２ファイルと前記第３ファイルとを所定の異なるデータベースに対して通信網を介しそれぞれ送信する送信手段と
を有する通信装置と、
前記送信手段に対して通信網を介して接続された複数のデータベースと
を備えることを特徴とする通信システム。
【請求項６】
所定の第１情報と所定の第２情報とを含む第１ファイルに基づいて、前記第１情報と異なりかつ前記第１情報と一意に対応する情報である対応付情報を生成する対応付情報生成過程と、
前記対応付情報と前記第１情報とを含む第２ファイルを作成する第２ファイル作成過程と、
前記第１ファイルを元に、前記第１ファイルに含まれる前記第１情報を削除し又は所定の第３情報に置き換え、かつ、前記対応付情報を含ませることで第３ファイルを作成する第３ファイル作成過程と、
前記第２ファイルと前記第３ファイルとを所定の異なるデータベースに対して通信網を介しそれぞれ送信する送信過程と
を含むことを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信網を介して医療情報等を送信する際に用いて好適な通信装置、通信システム、及び通信方法に関する。
【背景技術】
【０００２】
特許文献１には、医療情報を通信網を介して送受信する際に医療情報の第３者への漏洩を防止するための技術の一例が示されている。特許文献１に記載されている通信システムでは、受信側装置又は送信側装置で、患者を特定するための識別情報と所定期間だけ関連付けられる通信用識別子が生成される。そして、レセプト等の医療情報を通信網を介して送受信する場合に、医療情報に含まれる患者を特定するための識別情報が、その通信用識別子に置き換えられる。また、受信側装置又は送信側装置では、識別情報と通信用識別子との対応付けを示す情報が所定期間経過時に消去される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第４１８５７００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載されている通信システムでは、通信網上で送受信される医療情報が仮に盗聴されたとしても患者の識別情報が通信用識別子に置き換えられているので、医療情報と患者とを対応付けることはできない。ただし、識別情報と通信用識別子とを対応付けるための情報は受信側装置又は送信側装置に記憶される。したがって、不正な侵入等によってその対応付け情報が漏洩した場合は、医療情報と患者とを対応付けることが可能となる。しかしながら、特許文献１に記載されている通信システムでは、識別情報と通信用識別子とを対応付け情報に有効期限を設定し、対応付けのための情報を所定期間経過時に消去している。したがって、そのような不正侵入等による被害発生の可能性を小さくすることができる。
【０００５】
上記のように特許文献１に記載されている通信システムでは、通信用識別子に所定期間の有効期限が設定されている。そのため、受信側装置と送信側装置との間の通信は、この通信用識別子の有効期限内に行われる。しかしながら、例えば、受信側装置と送信側装置との間に、さらにデータベース等の他の装置を介在させる構成を考えると、有効期限内に通信を行うことが難しくなる場合が生じると考えられる。
【０００６】
本発明は、上記の事情に鑑みてなされたものであり、通信網を介して情報を送受信する際に、時間的な制約を少なくしても機密性を確保することができる通信装置、通信システム及び通信方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明は、所定の第１情報と所定の第２情報とを含む第１ファイルに基づいて、前記第１情報と異なりかつ前記第１情報と一意に対応する情報である対応付情報を生成する対応付情報生成手段と、前記対応付情報と前記第１情報とを含む第２ファイルを作成する第２ファイル作成手段と、前記第１ファイルを元に、前記第１ファイルに含まれる前記第１情報を削除し又は所定の第３情報に置き換え、かつ、前記対応付情報を含ませることで第３ファイルを作成する第３ファイル作成手段と、前記第２ファイルと前記第３ファイルとを所定の異なるデータベースに対して通信網を介しそれぞれ送信する送信手段とを備えることを特徴とする。
【０００８】
また本発明は、前記対応付情報が、所定のハッシュ関数で生成された疑似乱数に対応するものであることを特徴とする。
【０００９】
また本発明は、前記対応付情報が、前記第２ファイル及び前記第３ファイルを生成する毎に変化することを特徴とする。
【００１０】
また本発明は、前記第１情報が、保健医療に係る患者の個人情報又は当該保健医療に係る保険医師の個人情報を含み、前記第２情報が、前記保健医療の内容を示す医療情報を含むことを特徴とする。
【００１１】
また本発明は、所定の第１情報と所定の第２情報とを含む第１ファイルに基づいて、前記第１情報と異なりかつ前記第１情報と一意に対応する情報である対応付情報を生成する対応付情報生成手段と、前記対応付情報と前記第１情報とを含む第２ファイルを作成する第２ファイル作成手段と、前記第１ファイルを元に、前記第１ファイルに含まれる前記第１情報を削除し又は所定の第３情報に置き換え、かつ、前記対応付情報を含ませることで第３ファイルを作成する第３ファイル作成手段と、前記第２ファイルと前記第３ファイルとを所定の異なるデータベースに対して通信網を介しそれぞれ送信する送信手段とを有する通信装置と、前記送信手段に対して通信網を介して接続された複数のデータベースとを備えることを特徴とする。
【００１２】
また本発明は、所定の第１情報と所定の第２情報とを含む第１ファイルに基づいて、前記第１情報と異なりかつ前記第１情報と一意に対応する情報である対応付情報を生成する対応付情報生成過程と、前記対応付情報と前記第１情報とを含む第２ファイルを作成する第２ファイル作成過程と、前記第１ファイルを元に、前記第１ファイルに含まれる前記第１情報を削除し又は所定の第３情報に置き換え、かつ、前記対応付情報を含ませることで第３ファイルを作成する第３ファイル作成過程と、前記第２ファイルと前記第３ファイルとを所定の異なるデータベースに対して通信網を介しそれぞれ送信する送信過程とを含むことを特徴とする。
【発明の効果】
【００１３】
本発明によれば、所定の第１情報と所定の第２情報とを含む第１ファイルに基づいて、対応付情報と第１情報とを含む第２ファイルが作成される。それとともに、第１ファイルを元に、第１ファイルに含まれる第１情報を削除し又は所定の第３情報に置き換えて、かつ、対応付情報を含む第３ファイルが作成される。例えば第１情報を患者の識別情報あるいは個人情報、第２情報を患者の識別情報、個人情報等を除く医療情報として考えれば、第２ファイルには対応付情報と患者の識別情報等とが含まれることになる。また、第３ファイルには対応付情報と患者の識別情報等を除く医療情報とが含まれることになる。対応付情報は、第１情報と異なりかつ第１情報と一意に対応する情報である。したがって、第２ファイル又は第３ファイルの一方が仮に盗聴されたとしても、対応付情報は患者の識別情報等を表す第１情報とは異なっているので、患者と医療情報とを対応付けることはできない。
【００１４】
また、第２ファイルと第３ファイルとは異なるデータベースに対して送信されるので、仮に一つのデータベースに対して侵入等による情報の漏洩が発生したとしても、患者と医療情報とを対応付けることはできない。
【００１５】
以上のように、本発明によれば、第１のファイルに含まれる第１の情報と第２の情報とを第２ファイルと第３ファイルとに分離して送信するとともに、第２ファイルと第３ファイルとを異なるデータベースに記憶する。その際、第２ファイルと第３ファイルとにそれぞれ対応付情報を含ませることで、第２ファイルと第３ファイルとが対応付けられる。したがって、本発明によれば、情報の送信時においてデータが分散されるとともに、情報の保管時においてもデータが分散されることで機密性が確保される。さらに、対応付け情報には時間的制約は必要とされない。よって、従来に比べて時間的な制約をより少なくした上で機密性を確保することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態を示したシステム構成図である。
【図２】図１に示した通信システム１０の動作例を示したフローチャートである。
【図３】図１に示した薬局端末１１の詳細な動作例を示したフローチャートである。
【図４】図３の動作例で処理対象となる各ファイルを説明するための説明図である。
【発明を実施するための形態】
【００１７】
以下、図面を参照して本発明の実施の形態について説明する。図１は、本発明の一実施の形態としての通信システムの構成例を示したシステム構成図である。図２は、図１に示した通信システム１０の動作例を示したフローチャートである。
【００１８】
図１に示した通信システム１０は、薬局１に設置されている薬局端末１１と、センター２に設置されているレセプト情報ＤＢ（データベース）サーバ２１及び個人情報ＤＢサーバ２２と、健康保険組合（以下、健保と称する）３に設置されている健保端末３１とを備えている。これらの薬局端末１１と、レセプト情報ＤＢサーバ２１及び個人情報ＤＢサーバ２２と、健保端末３１とは、通信網４を介して接続されている。
【００１９】
なお、本実施形態においてレセプトとは、保険医療等において、各医療機関又は各薬局が、患者（すなわち被保険者又は被扶養者）毎に傷病名や１ヶ月毎の診療内容、調剤した薬剤等の医療情報を記録した明細書を意味し、診療報酬明細書又は調剤報酬明細書と呼ばれるものである。各医療機関又は各薬局は、レセプトを各保険者に提出し、診療報酬又は調剤報酬の請求を行う。レセプトは、例えばレセプトの個人情報（あるいは識別情報）と発行元情報を記載した部分と、具体的な医療内容部分と、その医療内容に対する請求書部分とから構成される。また、レセプトデータとは、このようなレセプトが含む各項目の内容を表す電子データを意味する。また、所定のレセプトデータを含むファイルをレセプトファイルと呼ぶこととする。
【００２０】
なお、本実施形態の通信システム１０は、薬局１と健保３との間で直接審査支払いを行うシステムとして構成されている。そのため、本実施形態では、レセプトデータを含むレセプトファイルを、直接請求レセプトファイルと読んでいる。なお、直接審査支払いを行う場合、レセプトを受領した各保険者は、各レセプトに記載された医療情報に対して点検を実施し、決済金額を決定すると共に、各医療機関又は各薬局に対して決定された金額の診療報酬又は調剤報酬の支払いを行う。
【００２１】
また、図１は、通信システム１０において、薬局端末１１から送信したレセプトデータを、レセプト情報ＤＢサーバ２１及び個人情報ＤＢサーバ２２に蓄積する情報の流れと、レセプト情報ＤＢサーバ２１及び個人情報ＤＢサーバ２２に蓄積されているレセプトデータを健保端末３１で受信する情報の流れとを示している。なお、図１は、通信システム１０の構成の一例を示したものであって、薬局１や薬局端末１１、センター２やレセプト情報ＤＢサーバ２１及び個人情報ＤＢサーバ２２、及び健保３や健保端末３１の台数は、各１台に限定されず、複数であってもよい。さらに、薬局１や薬局端末１１と同様の構成で、医療機関や同機関内の端末を設けることもできる。
【００２２】
薬局端末１１は、パーソナルコンピュータ等の情報処理装置である。薬局端末１１は、ＣＰＵ（中央処理装置）、揮発及び不揮発の記憶装置、キーボード、マウス等の入力装置、液晶ディスプレイ等の表示装置、ネットワークカード等の通信装置等を備えている。そして、薬局端末１１は、ＣＰＵで不揮発記憶装置に記憶されている所定のプログラムを実行することで動作する。
【００２３】
レセプト情報ＤＢサーバ２１は、所定のデータベース（以下、レセプト情報ＤＢと呼ぶ）を管理するアプリケーションを実行するサーバである。レセプト情報ＤＢサーバ２１は、通信網４を介して薬局端末１１や健保端末３１と接続し、薬局端末１１や健保端末３１の要求に応じて自サーバが管理するレセプト情報ＤＢに所定のファイル（後述する非個人情報化レセプトファイル）を書き込んだり、同ＤＢから読み出したりする。
【００２４】
個人情報ＤＢサーバ２２は、所定のデータベース（以下、個人情報ＤＢと呼ぶ）を管理するアプリケーションを実行するサーバである。個人情報ＤＢサーバ２３は、通信網４を介して薬局端末１１や健保端末３１と接続し、薬局端末１１や健保端末３１の要求に応じて自サーバが管理する個人情報ＤＢに所定のファイル（後述する個人情報ファイル）を書き込んだり、同ＤＢから読み出したりする。
【００２５】
なお、レセプト情報ＤＢサーバ２１と個人情報ＤＢサーバ２２とは、例えば異なるパスワードを設定すること等によって別々に所定のアクセス制御を行う。ただし、レセプト情報ＤＢサーバ２１と個人情報ＤＢサーバ２２にアクセスするための異なるパスワード等の管理は、例えば、薬局端末１１や健保端末３１でプログラムによって管理するようにしてもよい。この場合、例えば薬局端末１１や健保端末３１の操作者は、所定の認証手続を行って、薬局端末１１や健保端末３１で実行されているプログラムを動作させることで、異なるパスワードを意識せずレセプト情報ＤＢサーバ２１と個人情報ＤＢサーバ２２への各ファイルを送信や受信を実行させることができる。
【００２６】
健保端末３１は、パーソナルコンピュータ等の情報処理装置である。健保端末３１は、ＣＰＵ、揮発及び不揮発の記憶装置、キーボード、マウス等の入力装置、液晶ディスプレイ等の表示装置、ネットワークカード等の通信装置等を備えている。そして、健保端末３１は、ＣＰＵで不揮発記憶装置に記憶されている所定のプログラムを実行することで動作する。
【００２７】
通信網４は、無線や有線の１又は複数の通信網からなるコンピュータネットワークである。本実施形態では、一例として、通信網４がＩＰ（インターネットプロトコル）に従って通信が制御されるＩＰネットワークであって、ＩＰアドレスを用いて各装置間が接続されることとする。
【００２８】
次に、図１及び図２を参照して、通信システム１０の基本動作について説明する。前提として、薬局端末１１では、操作者が薬局端末１１のキーボードやマウスを操作することで所定のレセプトデータを入力し、入力された所定のレセプトデータを含む直接請求レセプトファイル５１が作成済みであるとする。作成された直接請求レセプトファイル５１は、薬局端末１１内の所定の記憶装置に記憶されている。ここで、直接請求レセプトファイル５１は、例えば報酬請求における１件分のレセプトデータを含むファイルである。直接請求レセプトファイル５１は、例えば保健医療に係る患者の個人情報（あるいは識別情報；以下、同様）又は当該保健医療に係る保険医師の個人情報を含む第１情報と、保健医療の内容を示す医療情報を含む第２情報とを含んでいる。
【００２９】
ここで例えば操作者が所定の操作を行うことで薬局端末１１に対して直接請求レセプトファイル５１の送信動作が指示されると、薬局端末１１は、直接請求レセプトファイル５１を、非個人情報化したレセプトファイルと個人情報ファイルとに分離する処理を行う（ステップＳ１１）。
【００３０】
ここで、非個人情報化したレセプトファイルとは、直接請求レセプトファイル５１から個人情報を除いたファイルである。直接請求レセプトファイル５１が複数のデータレコード（以下、単にレコードと称する）からなり、各レコードが複数のデータフィールド（以下、単にフィールドと称する）を含むものとした場合、非個人情報化レセプトファイルは、直接請求レセプトファイル５１における個人情報を表す各フィールドの情報を削除し（又は所定の文字や文字列を表す情報に置き換え）たものである。さらに、非個人情報化レセプトファイルは、削除等した個人情報に一意に対応する情報である対応付情報を追加して含むものである。この対応付情報は、削除等した個人情報とは異なるものである。この対応情報は、例えば個人情報を元にして（すなわち個人情報を表す文字列を原文として）所定のハッシュ関数で生成された疑似乱数に対応する文字列とすることができる。あるいは（もしくはそれに加えて）、この対応付情報は、作成日時等に基づきファイル作成毎に変化した値となるように生成された文字列とすることができる。また、対応付情報は、レセプトの請求月ごとに更新される連番等の数値であってもよい。
【００３１】
また、個人情報ファイルは、直接請求レセプトファイル５１に含まれる個人情報を含むファイルである。すなわち、個人情報ファイルは、直接請求レセプトファイル５１が複数のレコードからなり、各レコードが複数のフィールドを含むものとした場合、非個人情報化レセプトファイルを作成する際に直接請求レセプトファイル５１から削除し（又は所定の文字や文字列を表す情報に置き換え）た個人情報を表す各フィールドの情報を含むものである。さらに、個人情報ファイルは、上述した対応付情報（すなわち削除等した個人情報と異なるが一意に対応する情報）を含むものである。
【００３２】
なお、本実施形態において、個人情報は、患者の個人情報のほか、担当した保険医師の個人情報を含むものとする。具体的には、個人情報は、患者の「氏名」、「生年月日」及び「性別」、保険医師の「氏名」、並びに、保険者及び被保険者の識別情報である保険証の「記号」及び「番号」を含むものであるとする。ここで、個人情報は、上述した直接請求レセプトファイル５１が含む第１情報（保健医療に係る患者の個人情報又は当該保健医療に係る保険医師の個人情報）と、第２情報（保健医療の内容を示す医療情報）のうちの第１情報に対応している。また、例えば直接請求レセプトファイル５１のうちの第１情報以外の情報が、第２情報である。
【００３３】
さて、図２のステップＳ１１で、薬局端末１１が、直接請求レセプトファイル５１を、非個人情報化レセプトファイルと個人情報ファイルとに分離すると、薬局端末１１は、生成した非個人情報化レセプトファイルと個人情報ファイルとを健保の証明書を用いて暗号化する（ステップＳ１２）。すなわち、薬局端末１１は、一定の認証局で健保３に対して発行されたデジタル証明書に含まれている健保３の公開鍵を用いて、ステップＳ１１で生成した非個人情報化レセプトファイルと個人情報ファイルとを暗号化する（ステップＳ１２）。図１では、暗号化した非個人情報化レセプトファイルと暗号化した個人情報ファイルとを、非個人情報化レセプトファイル５３ｅと個人情報ファイル５２ｅとして示した。
【００３４】
次に、薬局端末１１は、ステップＳ１２で暗号化した非個人情報化レセプトファイル５３ｅと個人情報ファイル５２ｅとを、ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）通信を使ってセンター２に送信する（ステップＳ１３）。その際、薬局端末１１は、非個人情報化レセプトファイル５３ｅをレセプト情報ＤＢサーバ２１に対して送信する。また、薬局端末１１は、個人情報ファイル５２ｅを個人情報ＤＢサーバ２２に対して送信する。ここで、ＳＳＬ通信は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）／ＩＰモデルのＴＣＰ層（ＯＳＩ（Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルのトランスポート層）と、アプリケーション層（ＯＳＩ参照モデルのセッション層）間でパケットを暗号化する通信方式である。
【００３５】
一方、センター２では、薬局端末１１から送信された非個人情報化レセプトファイル５３ｅをレセプト情報ＤＢサーバ２１で受信して、レセプト情報ＤＢに蓄積するとともに、薬局端末１１から送信された個人情報ファイル５２ｅを個人情報ＤＢサーバ２２で受信して、個人情報ＤＢに蓄積する（ステップＳ２１）。
【００３６】
さらに、センター２では、健保端末３１からの所定の要求を受信した場合、その要求に応じて、非個人情報化レセプトファイル６３ｅをレセプト情報ＤＢサーバ２１から健保端末３１に対して送信するとともに、個人情報ファイル６２ｅを個人情報ＤＢサーバ２２から健保端末３１に対して送信する（ステップＳ２２）。ここで非個人情報化レセプトファイル６３ｅと個人情報ファイル６２ｅとは、非個人情報化レセプトファイル５３ｅと個人情報ファイル５２ｅと同一のファイルである。その際、レセプト情報ＤＢサーバ２１及び個人情報ＤＢサーバ２２は、ＩＰＳｅｃ＋ＩＫＥ（ＩＰ  Ｓｅｃｕｒｉｔｙ  ＰｒｏｔｏｃｏｌとＩｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅプロトコルとを組み合わせたもの）通信を使って、非個人情報化レセプトファイル６３ｅ及び個人情報ファイル６２ｅを送信する。ここで、ＩＰＳｅｃは、パケットをＴＣＰ／ＩＰモデルのＩＰ層（ＯＳＩ参照モデルのネットワーク層）で暗号化するプロトコルである。また、ＩＫＥは、鍵交換プロトコルの１つである。
【００３７】
さらに、健保３では、健保端末３１が、ＩＰＳｅｃ＋ＩＫＥで、レセプト情報ＤＢサーバ２１及び個人情報ＤＢサーバ２２から送られてきた非個人情報化レセプトファイル６３ｅ及び個人情報ファイル６２ｅを受信する（ステップＳ３１）。次に、健保端末３１は、ステップＳ３１で受信した非個人情報化レセプトファイル６３ｅ及び個人情報ファイル６２ｅを自健保の証明書を用いて複号化する（ステップＳ３２）。すなわち、健保端末３１は、一定の認証局で健保３に対して発行されたデジタル証明書に含まれている健保３の秘密鍵を用いて、ステップＳ３１で受信した非個人情報化レセプトファイル６３ｅと個人情報ファイル６２ｅとを復号化する（ステップＳ３２）。
【００３８】
次に、健保端末３１は、非個人情報化レセプトファイル６３ｅを復号化したファイルと個人情報ファイル６２ｅとを復号化したファイルに含まれる対応付情報を使って、非個人情報化レセプトファイルと個人情報ファイルを統合し、直接請求レセプトファイルを復元する（ステップＳ３３）。図１では、この復元した直接請求レセプトファイルを直接請求レセプトファイル６４として示した。直接請求レセプトファイル６４は、直接請求レセプトファイル５１と同一のファイルである。
【００３９】
次に、図３及び図４を参照して、図２に示した薬局端末１１の動作（すなわちステップＳ１１〜Ｓ１３の処理）について具体例を示して説明する。図３は、薬局端末１１の動作例を示したフローチャートである。図４は、図１に示した直接請求レセプトファイル５１の一例、個人情報ファイル５２ｅの暗号化前のファイルである個人情報ファイル５２の一例及び非個人情報化レセプトファイル５３ｅの暗号化前のファイルである非個人情報化レセプトファイル５３の一例を示した図である。
【００４０】
図４に示した直接請求レセプトファイル５１は、上から順に第１レコードから第５レコードとして、行毎にＹＫレコード、ＲＥレコード、ＨＯレコード、ＳＨレコード及びＣＺレコードを含んでいる。ＹＫレコード、ＲＥレコード、ＨＯレコード、ＳＨレコード及びＣＺレコードの各１番目のフィールドには「ＹＫ」、「ＲＥ」、「ＨＯ」、「ＳＨ」及び「ＣＺ」の文字列が含まれている。ここで「ＹＫ」は、当該レコードが薬局の情報を記録したものであることを示す。「ＲＥ」は、当該レコードが１レセプト毎のレセプトの情報を記録したものであることを示す。「ＨＯ」は、当該レコードが健保の情報を記録したものであることを示す。「ＳＨ」は、当該レコードが医薬品の剤形、用法等を記録したものであることを示す。そして、「ＣＺ」は、当該レコードが１月のうちの調剤日単位の情報を記録したものであることを示す。
【００４１】
図４に示した直接請求レセプトファイル５１において、第２レコードであるＲＥレコードは、５番目のフィールドとして患者の氏名を記録する氏名フィールド５１１、６番目のフィールドとして患者の性別を記録する性別フィールド５１２、７番目のフィールドとして患者の生年月日を記録する生年月日フィールド５１３、及び、所定番目のフィールドとして保険医師の氏名を記録する保険医師氏名フィールド５１４を含んでいる。また、第３レコードであるＨＯレコードは、３番目のフィールドとして保険証の記号を記録する記号フィールド５１５、及び、４番目のフィールドとして保険証の番号を記録する番号フィールド５１６を含んでいる。
【００４２】
次に、図４に示した個人情報ファイル５２は、上から順に第１レコード及び第２レコードとして、２つのレコードを含んでいる。個人情報ファイル５２において、第１レコードは、１番目のフィールドとして第１対応付情報フィールド５２１、２番目のフィールドとして氏名フィールド５２２、３番目のフィールドとして性別フィールド５２３、及び４番目のフィールドとして生年月日フィールド５２４を含んでいる。第１レコードは、さらに、５番目のフィールドとして保険医師氏名フィールド５２５を含んでいる。第１対応付情報フィールド５２１は、直接請求レセプトファイル５１のＲＥレコードに含まれている複数のフィールド５１１、５１２、５１３及び５１４と、当該個人情報ファイル５２の第１レコードとを対応付ける情報である対応付情報を記録するフィールドである。この例では、第１対応付情報フィールド５２１に記録されている複数の数字からなる文字列「８７８７９０８」が対応付情報である。氏名フィールド５２２には、直接請求レセプトファイル５１の氏名フィールド５１１と同一の情報が記録される。性別フィールド５２３には、直接請求レセプトファイル５１の性別フィールド５１２と同一の情報が記録される。生年月日フィールド５２４には、直接請求レセプトファイル５１の生年月日フィールド５１３と同一の情報が記録される。そして、保険医師氏名フィールド５２５には、直接請求レセプトファイル５１の保険医師氏名フィールド５１４と同一の情報が記録される。
【００４３】
また、個人情報ファイル５２において、第２レコードは、１番目のフィールドとして第２対応付情報フィールド５２６、２番目のフィールドとして記号フィールド５２７及び３番目のフィールドとして番号フィールド５２８を含んでいる。第２対応付情報フィールド５２６は、直接請求レセプトファイル５１のＨＯレコードに含まれている複数のフィールド５１５及び５１６と、当該個人情報ファイル５２の第２レコードとを対応付ける情報である対応付情報を記録するフィールドである。この例では、第２対応付情報フィールド５２６に記録されている複数の数字からなる文字列「４４３８９８２」が対応付情報である。記号フィールド５２７には、直接請求レセプトファイル５１の記号フィールド５１５と同一の情報が記録される。そして、番号フィールド５２８には、直接請求レセプトファイル５１の番号フィールド５１８と同一の情報が記録される。
【００４４】
次に、図４に示した非個人情報化レセプトファイル５３は、直接請求レセプトファイル５１と同一の構成を有し、上から順に第１レコードから第５レコードとして、行毎にＹＫレコード、ＲＥレコード、ＨＯレコード、ＳＨレコード及びＣＺレコードを含んでいる。この非個人情報化レセプトファイル５３は、次のフィールドの内容を除き、各フィールドに直接請求レセプトファイル５１における対応するフィールドのものと同一の内容が記録される。
【００４５】
すなわち、直接請求レセプトファイル５１のＲＥレコードの５番目のフィールドである氏名フィールド５１１に対応する、非個人情報化レセプトファイル５３のＲＥレコードの５番目のフィールド５３１には、個人情報ファイル５２の第１レコードの第１対応付情報フィールド５２１に記録された対応付情報と同一の内容（「８７８７９０８」）が記録される。直接請求レセプトファイル５１のＲＥレコードの６番目のフィールドである性別フィールド５１２に対応する、非個人情報化レセプトファイル５３のＲＥレコードの６番目のフィールド５３２には何も記録されない。直接請求レセプトファイル５１のＲＥレコードの７番目のフィールドである生年月日フィールド５１３に対応する、非個人情報化レセプトファイル５３のＲＥレコードの７番目のフィールド５３３には何も記録されない。さらに、直接請求レセプトファイル５１のＲＥレコードの所定番目のフィールドである保険医師フィールド５１４に対応する、非個人情報化レセプトファイル５３のＲＥレコードの所定番目のフィールド５３４には何も記録されない。
【００４６】
また、直接請求レセプトファイル５１のＨＯレコードの３番目のフィールドである記号フィールド５１５に対応する、非個人情報化レセプトファイル５３のＨＯレコードの３番目のフィールド５３５には、個人情報ファイル５２の第２レコードの第２対応付情報フィールド５２６に記録された対応付情報と同一の内容（「４４３８９８２」）が記録される。そして、直接請求レセプトファイル５１のＨＯレコードの４番目のフィールドである番号フィールド５１６に対応する、非個人情報化レセプトファイル５３のＨＯレコードの４番目のフィールド５３６には何も記録されない。
【００４７】
なお、図４では、例えば、フィールド５３２に空白文字が含まれているように示されているが、これはフィールド５３２が存在することを示すために、前のフィールドとの区切り文字「，」と次のフィールドとの区切り文字「，」との間に若干の間隔を持たせたためである。ただし、この例のように、フィールド５３２に何も文字を記録しないことに代えて、例えば、空白文字“  ”を記録したり、フィールド番号を示す情報（例えば６番目のフィールドであることを示す“＃６”といった文字列）を記録したりしてもよい。なお空白文字“  ”やフィールド番号を示す情報等を、第３情報と称する。
【００４８】
次に、図３を参照して、薬局端末１１が、図４に示した直接請求レセプトファイル５１に基づいて、分離及び暗号化したファイルを作成及び送信する処理の流れについて説明する。例えば操作者が所定の操作を行うことで薬局端末１１に対して直接請求レセプトファイル５１の送信を指示すると、薬局端末１１は、直接請求レセプトファイル５１のＲＥレコードの「氏名」（フィールド５１１）、「生年月日」（フィールド５１２）及び「性別」（フィールド５１３）の各情報を原文として、所定のハッシュ関数を適用することで疑似乱数である「第１対応付情報」を生成する（ステップＳ１０１）。この例では、「第１対応付情報」として文字列「８７８７９０８」が生成されたとする。また、カギ括弧（「  」）で項目名を囲んで表記したものは、その項目の内容（すなわちその項目のデータ）に対応するものである。
【００４９】
次に、薬局端末１１は、直接請求レセプトファイル５１のＨＯレコードの「記号」（フィールド５１５）及び「番号」（フィールド５１６）の各データを原文として、所定のハッシュ関数を適用することで疑似乱数である「第２対応付情報」を生成する（ステップＳ１０２）。この例では、「第２対応付情報」として文字列「４４３８９８２」が生成されたとする。
【００５０】
次に、薬局端末１１は、ステップＳ１０１で生成した「第１対応付情報」、直接請求レセプトファイル５１のＲＥレコード中の「氏名」（フィールド５１１）、「生年月日」（フィールド５１２）、「性別」（フィールド５１３）及び「保険医師氏名」（フィールド５１４）を表すデータを含む第１ＣＳＶ（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅｓ）データを作成する（ステップＳ１０３）。ここで、第１ＣＳＶデータは、「第１対応付情報」と、これらのフィールド５１１、フィールド５１２、フィールド５１３及びフィールド５１４の各フィールドに記録された各文字列とを、区切り文字“，”をはさんで結合した文字列である。この例では、第１ＣＳＶデータは、文字列「８７８７９０８，神谷  一郎，１，１９１１０６０７，山田  太郎」となる。
【００５１】
次に、薬局端末１１は、「第２対応付情報」、直接請求レセプトファイル５１のＨＯレコードの「記号」（フィールド５１５）及び「番号」（フィールド５１６）を表すデータを含む第２ＣＳＶデータを作成する（ステップＳ１０４）。ここで、第２ＣＳＶデータは、「第２対応付情報」と、これらのフィールド５１５及びフィールド５１６の各フィールドに記録された各文字列とを、区切り文字“，”をはさんで結合した文字列である。この例では、第２ＣＳＶデータは、文字列「４４３８９８２，天あい，１２３４」となる。
【００５２】
次に、薬局端末１１は、ステップＳ１０３で生成した第１ＣＳＶデータとステップＳ１０４で生成した第２ＣＳＶデータとを含む健保向け個人情報ファイル５２を作成する（ステップＳ１０５）。この例では、図４に示した個人情報ファイル５２が作成される。図４に示した個人情報ファイル５２は、ステップＳ１０３で生成した第１ＣＳＶデータを第１レコードとし、ステップＳ１０４で生成した第２ＣＳＶデータを第２レコードとして生成されている。
【００５３】
次に、薬局端末１１は、直接請求レセプトファイル５１のＲＥレコードの「氏名」（フィールド５１１）をステップＳ１０１で生成した「第１対応付情報」に置換する（ステップＳ１０６）。次に、薬局端末１１は、直接請求レセプトファイル５１のＲＥレコードの「生年月日」（フィールド５１２）、「性別」（フィールド５１３）及び「保険医師氏名」（フィールド５１４）を削除する（ステップＳ１０７）。
【００５４】
次に、薬局端末１１は、直接請求レセプトファイル５１のＨＯレコードの「記号」（フィールド５１５）をステップＳ１０２で生成した「第２対応付情報」に置換する（ステップＳ１０８）。次に、薬局端末１１は、直接請求レセプトファイル５１のＨＯレコードの「番号」（フィールド５１６）を削除する（ステップＳ１０９）。ここで、非個人化情報レセプトファイル５３が作成される。この例では、ステップＳ１０６〜Ｓ１０９の処理によって、図４に示した非個人化情報レセプトファイル５３が作成される。
【００５５】
次に、薬局端末１１は、ステップＳ１０５で作成した個人情報ファイル５２を送り先健保３の公開鍵で暗号化するとともに、ステップＳ１０９で作成した非個人情報化レセプトファイル５３を送り先の健保３の公開鍵で暗号化する（ステップＳ１１０）。次に、薬局端末１１は、図１に示したように、ステップＳ１１０で暗号化した非個人情報化レセプトファイル５３ｅと暗号化した個人情報ファイル５２ｅとをＳＳＬ通信で別々のサーバ、すなわちレセプト情報ＤＢサーバ２１と個人情報ＤＢサーバ２２とにそれぞれ送信する（ステップＳ１１１）。
【００５６】
以上のようにして、薬局端末１１は、図４に示した直接請求レセプトファイル５１を基づいて、図４に示した個人情報ファイル５２を暗号化したファイル（個人情報ファイル５２ｅ）と、非個人情報化レセプトファイル５３を暗号化したファイル（非個人情報化レセプトファイル５３ｅ）とを作成し、図１に示したレセプト情報ＤＢサーバ２１と個人情報ＤＢサーバ２２とにそれぞれ送信する。
【００５７】
本実施形態の通信システム１０によれば、例えば保健医療に係る患者の個人情報又は当該保健医療に係る保険医師の個人情報を含む第１情報と、例えば保健医療の内容を示す医療情報を含む第２情報とを含む直接請求レセプトファイル５１（第１ファイル）に基づいて、対応付情報と第１情報とを含む個人情報ファイル５２（第２ファイル）が作成される。それとともに、直接請求レセプトファイル５１（第１ファイル）を元に、直接請求レセプトファイル５１（第１ファイル）に含まれる第１情報を削除し又は空白文字等（第３情報）に置き換えて、かつ、対応付情報を含む非個人情報化レセプトファイル５３（第３ファイル）が作成される。ここで例えば第１情報を患者の個人情報（あるいは識別情報）、第２情報を患者の個人情報（あるいは識別情報）等を除く医療情報として考えれば、個人情報ファイル５２（第２ファイル）には対応付情報と患者の個人情報とが含まれることになる。また、非個人情報化レセプトファイル５３（第３ファイル）には対応付情報と患者の個人情報等を除く医療情報とが含まれることになる。対応付情報は、例えば第１情報を元にハッシュ関数を用いて生成された疑似乱数等のデータであり、第１情報と異なりかつ第１情報と一意に対応する情報である。したがって、個人情報ファイル５２（第２ファイル）又は非個人情報化レセプトファイル５３（第３ファイル）の一方が通信網４で伝送中等に仮に盗聴されたとしても、対応付情報は患者の個人情報等を表す第１情報とは異なっているので、個人情報のみ、または医療情報のみを知ることができるだけであり、患者と医療情報とを対応付けることはできない。
【００５８】
また、個人情報ファイル５２（第２ファイル）と非個人情報化レセプトファイル５３（第３ファイル）とは異なるデータベースに対して送信されるので、仮に一つのデータベースに対して侵入等による情報の漏洩が発生したとしても、患者と医療情報とを対応付けることはできない。
【００５９】
以上のように、本実施形態によれば、個人情報を含む第１の情報と医療情報を含む第２の情報とを個人情報ファイル５２（第２ファイル）と非個人情報化レセプトファイル５３（第３ファイル）とに分離して送信するとともに、個人情報ファイル５２（第２ファイル）と非個人情報化レセプトファイル５３（第３ファイル）とを異なるデータベースに記憶している。その際、個人情報ファイル５２（第２ファイル）と非個人情報化レセプトファイル５３（第３ファイル）とにそれぞれ対応付情報を含ませることで、個人情報ファイル５２（第２ファイル）と非個人情報化レセプトファイル５３（第３ファイル）とが対応付けられる。したがって、情報の送信時においてデータが分散されるとともに、情報の保管時においてもデータが分散されることで機密性が確保される。さらに、対応付け情報には時間的制約は必要とされない。よって、従来に比べて時間的な制約をより少なくした上で機密性を確保することができる。
【００６０】
なお、本実施形態の構成と、特許請求の範囲に記載した構成との対応は次のとおりである。図３のステップＳ１０１又はステップＳ１０２が「対応付情報生成手段」に対応している。図３のステップＳ１０５が「第２ファイル作成手段」に対応している。図３のステップＳ１０６〜Ｓ１０９が「第３ファイル作成手段」に対応している。そして、図３のステップＳ１１１が「送信手段」に対応している。
【００６１】
なお、本発明の実施の形態は上記のものに限定されず、例えば、薬局端末１１等に対してＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）メモリ等をプロテクトキーとして用いたアクセス制限を掛けたり、通信網４においてＳＳＬ、ＩＰＳｅｃ＋ＩＫＥとは異なるパケット暗号化を用いたりするといった変更を適宜行うことができる。また、図１に示した通信システム１０を構成する各コンピュータ、サーバ等において実行されるプログラムは、その一部又は全部がコンピュータ読み取り可能な記録媒体や通信回線を介して流通させることが可能である。
【符号の説明】
【００６２】
１０  通信システム
１１  薬局端末
２１  レセプト情報ＤＢサーバ
２２  個人情報ＤＢサーバ
３１  健保端末
５１  直接請求レセプトファイル
５２  個人情報ファイル
５２ｅ  暗号化した個人情報ファイル
５３  非個人情報化ファイル
５３ｅ  暗号化した非個人情報化ファイル
６２ｅ  暗号化した個人情報ファイル
６３ｅ  暗号化した非個人情報化ファイル
６４  直接請求レセプトファイル
【図１】
2013250937.tif 000003
【図２】
2013250937.tif 000004
【図３】
2013250937.tif 000005
【図４】
2013250937.tif 000006