JP2019185403A - レセプト情報・特定健診等情報データベースにおける患者突合方法及び装置 - Google Patents
レセプト情報・特定健診等情報データベースにおける患者突合方法及び装置 Download PDFInfo
- Publication number
- JP2019185403A JP2019185403A JP2018075685A JP2018075685A JP2019185403A JP 2019185403 A JP2019185403 A JP 2019185403A JP 2018075685 A JP2018075685 A JP 2018075685A JP 2018075685 A JP2018075685 A JP 2018075685A JP 2019185403 A JP2019185403 A JP 2019185403A
- Authority
- JP
- Japan
- Prior art keywords
- receipt
- hash value
- month
- same
- patient
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
【課題】ＮＤＢ等のレセプト情報データベースにおける名寄せの効率及び正確性を向上させる患者突合方法及び装置を提供する。【解決手段】保険者番号に基づく第１のハッシュ値と氏名に基づく第２のハッシュ値を有するレセプト情報データベースにおけるデータを突合して患者の名寄せを行う。まず、調剤レセプト以外のレセプト、調剤レセプトを分けて用いて、第１のハッシュ値と第２のハッシュ値及び診療年月を抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致に基づいてレセプトを連結し、同一患者の名寄せ用中間テーブルを生成する。次に、同一患者の中間テーブルを診療年月の時系列に沿って統合し、同一患者における第１のハッシュ値の対応テーブルを生成する。そして、対応テーブルにおいて複数種の第１のハッシュ値が存在する場合、ユニークな第１のハッシュ値に置き換えた名寄せテーブルを生成する。【選択図】図１
Description
本発明は、レセプト情報・特定健診等情報データベース（ＮＤＢ）におけるレセプトデータ及び特定健診等のデータを突合して患者の名寄せを行う技術に関するものである。
レセプト情報・特定健診等情報データベース（ＮＤＢ）とは、診療報酬請求のために、病院等から審査支払機関及び保険者に送信される電子レセプトデータ、及び保険者の保有する特定健診等のデータを、匿名化処理を経て格納・構築したデータベースであり、国民皆保険制度を採る我が国における保険診療の悉皆データである。ＮＤＢは平成２１年４月〜平成２８年１２月診療分で、約１２８億８，４００万件（平成２９年３月末時点）のレセプトデータが蓄積されるなど、世界最大級の健康関連データベースであり、これを有効に活用することで各種の臨床研究、政策研究が強力に推進できると期待されている。
しかし現状は、疾患別、地域別等の部分的な活用に留まっており、成果が十分に上がっているとは言いがたい。その理由として、ＮＤＢの巨大なサイズと並び、診療報酬請求のために設定されているレセプトの構造がそのままでは研究目的での利用に適さない形式となっていることが主因として挙げられる。その中でも、後述する「名寄せ」は大きな問題点である。
各医療機関は、患者ごとに、毎月、診療報酬を請求するので、レセプトデータは、１人の患者に対し、医療機関単位、１か月単位で送信されている。患者が複数月に渡って受診したり、同一月に複数の医療機関を受診したりすることは頻繁にあるため、同一患者の複数レセプトをつなぎ合わせる「名寄せ」作業を行わなければ、個人単位での分析を行うことはできない。そのため、ＮＤＢには、名寄せを可能とする個人紐付け用の匿名変数として、「ＩＤ１」と「ＩＤ２」が用意されている。ＩＤ１は保険者番号、被保険者証等記号・番号、生年月日、性別から個人情報保護のためにハッシュ関数を用いてハッシュ化された英数字列であり、ＩＤ２は氏名、生年月日、性別から同様にハッシュ関数を用いてハッシュ化された英数字列である。
ここで、ハッシュ関数とは、与えられたデータから一定長の疑似乱数（ハッシュ値）を生成するものであり、異なるデータから同じハッシュ値を生成することは極めて困難であるとされている。また生成された値（ハッシュ値）から元データを再現することはできないため、データの匿名化に有用とされている。しかしながら、保険者番号、記号・番号、生年月日、性別及び氏名といった個人情報を基にハッシュ値を生成するため、１つのハッシュ値を生成するだけでは、保険者番号や氏名といった個人情報に変化があった場合に突合が困難となる。そのため、ＮＤＢでは「ＩＤ１」と「ＩＤ２」の２つのハッシュ値が用意され、これらのハッシュ値を基に突合する構造となっている。
ところが、同一患者でも、就職・転職等で保険者は変化し、医療機関での表記ゆれ（例えば、“渡辺”と“渡邉”）や結婚・離婚等で氏名表記は変化するため、ＩＤ１、ＩＤ２ともに容易に変わり得ることが分かっている。下記表１は、別人物にも拘らずＩＤが同じとなる場合をまとめた表である。
上記表１に示すように、別人物にも拘らずＩＤが同じとなる場合としては、ＩＤ１もＩＤ２も同じである場合、ＩＤ１が異なるがＩＤ２が同じである場合及びＩＤ１が同じでＩＤ２が異なる場合が考えられる。
まず、ＩＤ１もＩＤ２も同じである場合とは、別人物同士で同一のＩＤ１、ＩＤ２が生成された場合である（Ｘ１）。ＩＤ１が異なるがＩＤ２が同じである場合とは、別人物同士で同一のＩＤ２が生成された場合（Ｙ１）や、同姓同名・同一生年月日で、同じ性別だった場合（Ｙ２）のことである。ＩＤ１が同じでＩＤ２が異なる場合とは、別人物同士で同一のＩＤ１が生成された場合（Ｚ１）や、同性・同一生年月日の複産(双子等)の場合（Ｚ２）のことである。なお、平成２６年の人口動態調査によれば、複産全体は１年間に１万件発生している。
下記表２は、表１とは異なり、同一人物にも拘らずＩＤが合わない場合をまとめた表である。
まず、ＩＤ１もＩＤ２も同じである場合とは、別人物同士で同一のＩＤ１、ＩＤ２が生成された場合である（Ｘ１）。ＩＤ１が異なるがＩＤ２が同じである場合とは、別人物同士で同一のＩＤ２が生成された場合（Ｙ１）や、同姓同名・同一生年月日で、同じ性別だった場合（Ｙ２）のことである。ＩＤ１が同じでＩＤ２が異なる場合とは、別人物同士で同一のＩＤ１が生成された場合（Ｚ１）や、同性・同一生年月日の複産(双子等)の場合（Ｚ２）のことである。なお、平成２６年の人口動態調査によれば、複産全体は１年間に１万件発生している。
下記表２は、表１とは異なり、同一人物にも拘らずＩＤが合わない場合をまとめた表である。
上記表２に示すように、同一人物にも拘らずＩＤが合わない場合としては、ＩＤ１は変わるがＩＤ２は不変である場合、ＩＤ１は不変であるがＩＤ２が変わる場合及びＩＤ１もＩＤ２も変わる場合が考えられる。
まず、ＩＤ１は変わるがＩＤ２は不変である場合としては、就職・転職（Ａ１−１）、離職（Ａ１−２）、定年（Ａ１−３）、就職・転職等で扶養が外れる（Ａ１−４）、扶養者の婚姻・離婚による保険変更（Ａ２−１）、養子縁組による扶養者変更に伴う保険変更（Ａ２−２）、扶養者の変更（Ａ２−３）、国保加入者における居住地変更（Ａ３）、後期高齢者制度への加入（Ａ４）又は保険証番号が流出した患者（Ａ５）といった場合が考えられる。ＩＤ１は不変であるがＩＤ２が変わる場合としては、養子による改姓（Ｂ１）、結婚・離婚による改姓（Ｂ２−１）、扶養者の結婚・離婚等による改姓（Ｂ２−２）、氏名変更（Ｂ３）、記入ミス・氏名等の記載ゆれ（Ｂ４）又は国籍取得に伴う氏名変更（Ｂ５）といった場合が考えられる。
まず、ＩＤ１は変わるがＩＤ２は不変である場合としては、就職・転職（Ａ１−１）、離職（Ａ１−２）、定年（Ａ１−３）、就職・転職等で扶養が外れる（Ａ１−４）、扶養者の婚姻・離婚による保険変更（Ａ２−１）、養子縁組による扶養者変更に伴う保険変更（Ａ２−２）、扶養者の変更（Ａ２−３）、国保加入者における居住地変更（Ａ３）、後期高齢者制度への加入（Ａ４）又は保険証番号が流出した患者（Ａ５）といった場合が考えられる。ＩＤ１は不変であるがＩＤ２が変わる場合としては、養子による改姓（Ｂ１）、結婚・離婚による改姓（Ｂ２−１）、扶養者の結婚・離婚等による改姓（Ｂ２−２）、氏名変更（Ｂ３）、記入ミス・氏名等の記載ゆれ（Ｂ４）又は国籍取得に伴う氏名変更（Ｂ５）といった場合が考えられる。
次に、ＩＤ１もＩＤ２も変わる場合としては、まず、上記の“Ａ”と“Ｂ”を掛け合わせた場合が考えられる。例えば、結婚に伴う退社・改姓（Ａ１−２＊Ｂ２−１）、離婚に伴う就職・改姓（Ａ１−１＊Ｂ２−１）又は養子による改姓・保険者変更（Ａ２−２＊Ｂ１）といった場合が考えられる。また“Ａ”と“Ｂ”を掛け合わせた場合以外としては、性転換（Ｃ３）の場合が考えられる。
同一人物にも拘らずＩＤが合わない場合については、例えば、就職・転職（Ａ１−１）、離職（Ａ１−２）又は定年（Ａ１−３）の何れかによりＩＤ１が変わった人は、厚生労働省「平成２６年雇用動向調査結果の概況」によると１年間に約７１３万人存在することが分かっている。就職・転職等で扶養が外れる（Ａ１−４）人は１年間に約８００万人、平成２６年の総務省統計局人口推計によると後期高齢者制度への加入（Ａ４）によりＩＤ１が変わる人が約１２２万人存在することが分かっている。また、２０１４年度時点での法務省戸籍統計によると、１年間の婚姻数は約６５万組であるので、それに近い数の改姓が行われていることも推測できる。このように、同一人物にも拘らずＩＤが合わない場合は非常に多く存在することが分かる。
そのため、就職・転職等の前と後で、１人の患者による受診を異なる２人の患者の受診と認識する等の可能性が生じ、ＮＤＢを用いた患者数の推計や患者１人あたりの推計値は大きな誤差を含むと考えられる。この問題を解決するためには、ＮＤＢに一生涯不変の個人ＩＤを付与する必要があるが、その実現に向けては議論が緒に就いたばかりである。また、不変ＩＤの導入が実現しても過去データについては現行のＩＤ１とＩＤ２を用いるほかない。
なお、ＮＤＢの患者突合性を高める動きとして、ＩＤ３を付与する動きがある。しかし、ＩＤ３は特定健診のＩＤ１において前述の表記ゆれ（全角半角の違い、頭に０が付与されているか否か）を改善し、特定健診等のデータとレセプトのデータの患者突合性を改善するものである。したがって、ＩＤ３を使用しても名寄せを行う必要性に変わりはない。
なお、ＮＤＢの患者突合性を高める動きとして、ＩＤ３を付与する動きがある。しかし、ＩＤ３は特定健診のＩＤ１において前述の表記ゆれ（全角半角の違い、頭に０が付与されているか否か）を改善し、特定健診等のデータとレセプトのデータの患者突合性を改善するものである。したがって、ＩＤ３を使用しても名寄せを行う必要性に変わりはない。
レセプトデータ及び健診データの名寄せについては、健診データとレセプトデータとを突合できる健康管理システムが知られている（特許文献１を参照）。
これは、健診データベースと、レセプトデータベースと、対応付け手段と、健診データ取込手段と、レセプトデータ取込手段と、第１の連結キー取得手段と、健診データ追加手段と、第２の連結キー取得手段と、レセプトデータ追加手段とを備えるシステムである。これによれば、外部から健診データを取り込んだ場合には、対応付けられた個人情報に基づいてレセプトデータベースから連結キーを取得し、その連結キーを付与して取り込んだ健診データを健診データベースに追加登録し、一方、外部からレセプトデータを取り込んだ場合は、対応付けられた個人情報に基づいて健診データベースから連結キーを取得し、その連結キーを付与して取り込んだレセプトデータをレセプトデータベースに追加登録することができる。その結果、健診データとレセプトデータとを突合することができる。
しかしながら、上記特許文献１に開示された健康管理システムは、就職・転職や氏名の表記ゆれ等により、個人紐付け用の匿名変数が容易に変わってしまうという問題を解決するものではない。
これは、健診データベースと、レセプトデータベースと、対応付け手段と、健診データ取込手段と、レセプトデータ取込手段と、第１の連結キー取得手段と、健診データ追加手段と、第２の連結キー取得手段と、レセプトデータ追加手段とを備えるシステムである。これによれば、外部から健診データを取り込んだ場合には、対応付けられた個人情報に基づいてレセプトデータベースから連結キーを取得し、その連結キーを付与して取り込んだ健診データを健診データベースに追加登録し、一方、外部からレセプトデータを取り込んだ場合は、対応付けられた個人情報に基づいて健診データベースから連結キーを取得し、その連結キーを付与して取り込んだレセプトデータをレセプトデータベースに追加登録することができる。その結果、健診データとレセプトデータとを突合することができる。
しかしながら、上記特許文献１に開示された健康管理システムは、就職・転職や氏名の表記ゆれ等により、個人紐付け用の匿名変数が容易に変わってしまうという問題を解決するものではない。
かかる状況に鑑みて、本発明は、ＮＤＢ等のレセプト情報データベースにおける名寄せの効率及び正確性を向上させる患者突合方法及び装置を提供することを目的とする。
上記課題を解決すべく、本発明の患者突合方法は、保険者番号に基づく第１のハッシュ値と氏名に基づく第２のハッシュ値の少なくとも２つの検索キーを有するレセプト情報データベースの突合方法であって、下記１）〜４）のステップを備え、データベースにおけるデータを突合して患者の名寄せを行う。
１）調剤レセプト以外のレセプトを用いて、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致に基づいてレセプトを連結し、同一患者の第１の名寄せ用中間テーブルを生成する。
２）調剤レセプトを用いて、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致に基づいてレセプトを連結し、同一患者の第２の名寄せ用中間テーブルを生成する。
３）同一患者の第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルを診療年月の時系列に沿って統合し、同一患者における第１のハッシュ値の対応テーブルを生成する。
４）対応テーブルにおいて複数種の第１のハッシュ値が存在する場合には、複数種の第１のハッシュ値をユニークな第１のハッシュ値に置き換えた名寄せテーブルを生成する。
１）調剤レセプト以外のレセプトを用いて、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致に基づいてレセプトを連結し、同一患者の第１の名寄せ用中間テーブルを生成する。
２）調剤レセプトを用いて、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致に基づいてレセプトを連結し、同一患者の第２の名寄せ用中間テーブルを生成する。
３）同一患者の第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルを診療年月の時系列に沿って統合し、同一患者における第１のハッシュ値の対応テーブルを生成する。
４）対応テーブルにおいて複数種の第１のハッシュ値が存在する場合には、複数種の第１のハッシュ値をユニークな第１のハッシュ値に置き換えた名寄せテーブルを生成する。
１）のステップにおいて、第１のハッシュ値と第２のハッシュ値及び診療年月以外に転帰区分を抽出することが好ましく、さらに転帰区分としては“死亡転帰”を抽出することが好ましい。調剤レセプトをそれ以外のレセプトと分けて用いるのは、外来では、医師が発行する処方箋に基づき院外の薬局で調剤が行われることが多く、医科入院外と調剤についてはペアでレセプトが発生することが多いため、一括処理を行うと患者の紐づけ情報が多対多となり、純正なマッチングが困難になるからである。
なお、調剤レセプトとそれ以外のレセプトを分けずに、一緒に処理することも可能である。かかる場合には、１）のステップにおいて、調剤レセプトを含めた処理を行い、２）のステップを省略する。また、その場合、３）のステップにおいては、第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルの統合は行わず、第１の名寄せ用中間テーブルのみを基に、同一患者における第１のハッシュ値の対応テーブルを生成する。
なお、調剤レセプトとそれ以外のレセプトを分けずに、一緒に処理することも可能である。かかる場合には、１）のステップにおいて、調剤レセプトを含めた処理を行い、２）のステップを省略する。また、その場合、３）のステップにおいては、第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルの統合は行わず、第１の名寄せ用中間テーブルのみを基に、同一患者における第１のハッシュ値の対応テーブルを生成する。
上記１）、２）の第１及び第２の名寄せ用中間テーブル生成ステップにおいて、具体的には、下記５），６）のステップを行う。
５）第１のハッシュ値と第２のハッシュ値の両方が一致する場合、同一患者のレセプトとして連結し、最初のレセプト発生月から最終のレセプト発生月まで、又は、最初のレセプト発生月から転帰区分にて死亡転帰が示される当該月まで、を１つのレセプトグループとして連結する。
６）それぞれのレセプトグループにおいて、第１のハッシュ値又は第２のハッシュ値の何れかのみ一致する場合、最終のレセプト発生月を連結対象とするレセプトグループの連結候補を、第１のハッシュ値が一致、最も時系列的に近い、同年月を除き期間がオーバーラップしない、又は、同じ第１若しくは第２のハッシュ値の候補の最初のレセプト発生月が同一ではない、の少なくとも何れかを満足する最初のレセプト発生月を連結対象とするレセプトグループと連結する。
ここで、レセプトグループとは、２つ以上のレセプトが紐付けされたものだけではなく、他のレセプトと紐付けされていない１つのレセプトも含む意味で用いている。
５）第１のハッシュ値と第２のハッシュ値の両方が一致する場合、同一患者のレセプトとして連結し、最初のレセプト発生月から最終のレセプト発生月まで、又は、最初のレセプト発生月から転帰区分にて死亡転帰が示される当該月まで、を１つのレセプトグループとして連結する。
６）それぞれのレセプトグループにおいて、第１のハッシュ値又は第２のハッシュ値の何れかのみ一致する場合、最終のレセプト発生月を連結対象とするレセプトグループの連結候補を、第１のハッシュ値が一致、最も時系列的に近い、同年月を除き期間がオーバーラップしない、又は、同じ第１若しくは第２のハッシュ値の候補の最初のレセプト発生月が同一ではない、の少なくとも何れかを満足する最初のレセプト発生月を連結対象とするレセプトグループと連結する。
ここで、レセプトグループとは、２つ以上のレセプトが紐付けされたものだけではなく、他のレセプトと紐付けされていない１つのレセプトも含む意味で用いている。
第１のハッシュ値が一致するものを優先して連結するのは、第２のハッシュ値については、同姓同名・同一生年月日・同性患者が同一ＩＤとなってしまうが、第１のハッシュ値では、同じ扶養に入っている同性の双子等を除き、別人が同一ＩＤとなる頻度が比較的少ないからである。最も時系列的に近いものを優先して連結するのは、時系列的に近いものの方がより同一人物である可能性が高いからである。
同年月を除き期間がオーバーラップしないものを連結するのは、期間がオーバーラップする場合には、同一人物でない可能性が高いからである。また、同年月を除くのは、就職や結婚などの事由が発生した月においては、同一人について複数の異なる第１又は第２のハッシュ値が存在することとなるからである。
同年月を除き期間がオーバーラップしないものを連結するのは、期間がオーバーラップする場合には、同一人物でない可能性が高いからである。また、同年月を除くのは、就職や結婚などの事由が発生した月においては、同一人について複数の異なる第１又は第２のハッシュ値が存在することとなるからである。
また、資格喪失したレセプトについては、審査支払機関を経由し保険者でチェックを行い再審査請求となるため、３か月間程度は新旧の第１のハッシュ値が並存し得ることとなる。そこで、第２のハッシュ値の一致に基づいてレセプトを連結する際には、同年月だけではなく、最終のレセプト発生月の前月及び前々月についてオーバーラップするものであっても連結してもよい。かかる場合においても、最終のレセプト発生月以降に最初のレセプト発生月を有するレセプトグループの方が、最終のレセプト発生月の前月又は前々月に最初のレセプト発生月を有するレセプトグループよりも同一人物である可能性は高いと考えられるため、最終のレセプト発生月以降、前月、前々月の順に優先して連結を行うことが好ましい。
同じ第１若しくは第２のハッシュ値の候補の最初のレセプト発生月が同一ではないものを連結するのは、最初のレセプト発生月が同一である場合には、どちらのレセプトグループと連結すべきかの判断が困難であるからである。
同じ第１若しくは第２のハッシュ値の候補の最初のレセプト発生月が同一ではないものを連結するのは、最初のレセプト発生月が同一である場合には、どちらのレセプトグループと連結すべきかの判断が困難であるからである。
上記６）において、それぞれのレセプトグループにおいて、第１のハッシュ値又は第２のハッシュ値の何れかのみ一致する場合、最終のレセプト発生月を連結対象とするレセプトグループの連結候補を、第１のハッシュ値が一致、最も時系列的に近い、同年月を除き期間がオーバーラップしない、及び、同じ第１若しくは第２のハッシュ値の候補の最初のレセプト発生月が同一ではない、の全てを満足するレセプトグループと連結するのがより好ましい。
また、死亡転帰が示されるレセプトグループでは、その最終月から３か月を超えた最初のレセプト発生月を有する他のレセプトグループとは連結しないことが好ましい。死亡転帰が示されるレセプトグループであっても、患者の死亡直後では、紐付けすべきレセプトも存在するが、３か月を超えた場合には、紐付けする必要はないと考えられるからである。
また、レセプト情報における医療機関所在地、診療開始年月日、傷病名、又は、患者の年齢階級の少なくとも何れかが一致するレセプトグループと連結することでもよい。例えば、同じハッシュ値であったとしても、遠く離れた土地でまったく異なる病名で受診した患者は別人物と考えるのが妥当であるし、異なるハッシュ値であったとしても、受診地や年齢階級、病名が一致する患者は同一人物である可能性が高まるからである。
なお、ここで一致とは、厳密な一致を要求するものではなく、近似した情報を含めてもよい。例えば、医療機関所在地の一致とは、同一の市区町村であることとしてもよいし、より広く同一の都道府県であることとしてもよい。また、傷病名が表現が異なるが実質的に同一の疾病である場合なども一致と判断できる。
なお、ここで一致とは、厳密な一致を要求するものではなく、近似した情報を含めてもよい。例えば、医療機関所在地の一致とは、同一の市区町村であることとしてもよいし、より広く同一の都道府県であることとしてもよい。また、傷病名が表現が異なるが実質的に同一の疾病である場合なども一致と判断できる。
本発明の患者突合プログラムは、上記の患者突合方法における各ステップを、コンピュータに実行させるプログラムである。
本発明の患者突合装置は、保険者番号に基づく第１のハッシュ値と氏名に基づく第２のハッシュ値の少なくとも２つの検索キーを有するレセプト情報データベースの突合を行う装置であって、下記ａ）〜ｄ）の手段を備え、データベースにおけるデータを突合して患者の名寄せを行う。
ａ）調剤レセプト以外のレセプトを入力し、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致を判断し、該判断に基づいて同一患者のレセプトを連結し、第１の名寄せ用中間テーブルを生成する第１の名寄せ用中間テーブル生成手段。
ｂ）調剤レセプトを入力し、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致を判断し、該判断に基づいて同一患者のレセプトを連結し、第２の名寄せ用中間テーブルを生成する第２の名寄せ用中間テーブル生成手段。
ｃ）同一患者の第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルを診療年月の時系列に沿って統合し、同一患者における第１のハッシュ値の対応テーブルを生成する対応テーブル生成手段。
ｄ）対応テーブルにおいて複数種の第１のハッシュ値が存在する場合には、複数種の第１のハッシュ値をユニークな第１のハッシュ値に置き換えた名寄せテーブルを生成する名寄せテーブル生成手段。
ａ）調剤レセプト以外のレセプトを入力し、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致を判断し、該判断に基づいて同一患者のレセプトを連結し、第１の名寄せ用中間テーブルを生成する第１の名寄せ用中間テーブル生成手段。
ｂ）調剤レセプトを入力し、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致を判断し、該判断に基づいて同一患者のレセプトを連結し、第２の名寄せ用中間テーブルを生成する第２の名寄せ用中間テーブル生成手段。
ｃ）同一患者の第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルを診療年月の時系列に沿って統合し、同一患者における第１のハッシュ値の対応テーブルを生成する対応テーブル生成手段。
ｄ）対応テーブルにおいて複数種の第１のハッシュ値が存在する場合には、複数種の第１のハッシュ値をユニークな第１のハッシュ値に置き換えた名寄せテーブルを生成する名寄せテーブル生成手段。
本発明によれば、ＮＤＢ等のレセプト情報データベースにおける名寄せの効率及び正確性を向上できるといった効果がある。また、これにより、「ある薬の処方数」だけではなく、「薬を飲んでいる患者の数」や「それらの患者が受けている医療行為の全体像」を臨床的に意味のある正確さで集計できるといった効果がある。
以下、本発明の実施形態の一例を、図面を参照しながら詳細に説明していく。なお、本発明の範囲は、以下の実施例や図示例に限定されるものではなく、幾多の変更及び変形が可能である。
本実施例では、平成２５年４月〜平成２６年３月の計１２か月分の医科入院レセプト、医科入院外レセプト、ＤＰＣレセプト、調剤レセプト全体を対象としている。ＤＰＣとは、平成１５年に導入された診断群分類に基づく入院医療費の１日あたり包括支払い制度であり、ＤＰＣ対象の入院で発生するレセプトの内、包括支払いに関連するレセプトがＤＰＣレセプトとなる。したがって、包括支払いに関連のない入院レセプトは医科入院レセプトとなる。これらのレセプトデータを使用して、複数月に渡るＩＤ等の変化を観察し、ＩＤ１、ＩＤ２のほか、診療年月、転帰区分を利用し作成した患者突合方法について説明する。
外来では、医師が発行する処方箋に基づき院外の薬局で調剤が行われることが多く、医科入院外と調剤についてはペアでレセプトが発生することが多い。そのため、一括処理を行うと患者の紐付け情報が多対多となり、純正なマッチングが困難になる。そこで、本実施例は、ＤＰＣ及び医科（入院／入院外）レセプトを用いた第１の名寄せ用中間テーブルと調剤レセプトを用いた第２の名寄せ用中間テーブルを別々に生成し、両者を突合して名寄せを完成させる仕組みとなっている。
なお、本実施例とは異なり、第１の名寄せ用中間テーブルの生成に、特定健診等のデータを用いてもよい。
外来では、医師が発行する処方箋に基づき院外の薬局で調剤が行われることが多く、医科入院外と調剤についてはペアでレセプトが発生することが多い。そのため、一括処理を行うと患者の紐付け情報が多対多となり、純正なマッチングが困難になる。そこで、本実施例は、ＤＰＣ及び医科（入院／入院外）レセプトを用いた第１の名寄せ用中間テーブルと調剤レセプトを用いた第２の名寄せ用中間テーブルを別々に生成し、両者を突合して名寄せを完成させる仕組みとなっている。
なお、本実施例とは異なり、第１の名寄せ用中間テーブルの生成に、特定健診等のデータを用いてもよい。
図１は、実施例１の患者突合方法のフロー図を示している。図１に示すように、まず、医科入院レセプト、医科入院外レセプト及びＤＰＣレセプトを用いて、第１の名寄せ用中間テーブルを生成する（ステップＳ０１）。次に、調剤レセプトを用いて、第２の名寄せ用中間テーブルを生成する（ステップＳ０２）。第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルを統合する（ステップＳ０３）。最後に、名寄せテーブルを生成する（ステップＳ０４）。
（第１の名寄せ用中間テーブル生成について）
図２は、第１の名寄せ用中間テーブル生成フロー図を示している。図１では名寄せテーブル生成の全体フローを示したが、図２では、個別のレセプトに着目して以下、説明を行う。図２に示すように、第１の名寄せ用中間テーブル生成においては、医科入院レセプト、医科入院外レセプト及びＤＰＣレセプトからＩＤ１、ＩＤ２、診療年月、転帰区分を抽出する（ステップＳ１１）。なおＤＰＣレセプトとは、ＤＰＣ入院の総括対象医科入院レセプト、ＤＰＣ入院のＤＰＣレセプト、及び、ＤＰＣ入院の総括対象ＤＰＣレセプトのことを指している。また、ステップＳ１１で示した転帰区分については死亡情報を抽出している。後述するが、レセプトデータに死亡転帰が示されている場合は、その月から３か月以内のレセプトデータのみを紐付け、３か月を超えたレセプトデータについては紐付けを行わない。
図２は、第１の名寄せ用中間テーブル生成フロー図を示している。図１では名寄せテーブル生成の全体フローを示したが、図２では、個別のレセプトに着目して以下、説明を行う。図２に示すように、第１の名寄せ用中間テーブル生成においては、医科入院レセプト、医科入院外レセプト及びＤＰＣレセプトからＩＤ１、ＩＤ２、診療年月、転帰区分を抽出する（ステップＳ１１）。なおＤＰＣレセプトとは、ＤＰＣ入院の総括対象医科入院レセプト、ＤＰＣ入院のＤＰＣレセプト、及び、ＤＰＣ入院の総括対象ＤＰＣレセプトのことを指している。また、ステップＳ１１で示した転帰区分については死亡情報を抽出している。後述するが、レセプトデータに死亡転帰が示されている場合は、その月から３か月以内のレセプトデータのみを紐付け、３か月を超えたレセプトデータについては紐付けを行わない。
抽出されたデータを基に、まず、複数月に渡ってＩＤ１及びＩＤ２が同じ患者は同一人物とする（ステップＳ１２）。図３は、ＩＤ１及びＩＤ２が同一の場合のグラフを示している。図３に示すように、レセプトグループＡは、ＩＤ１が“１３０”、ＩＤ２が“４７９”で共通するレセプトをグループ化している。レセプトグループＡでは、２０１５年４月、６月、１０〜１２月について共通のＩＤ１及びＩＤ２となっているが、診察にかからなかった月も含め、１つのグループとしている。このように紐付けたグループにおける最初のレセプト発生月及び最終のレセプト発生月について、他のレセプトグループと比較する。
レセプトグループ同士の比較は、ＩＤ１とＩＤ２の内、ＩＤ１を優先して行う。図４は、ＩＤ１とＩＤ２の紐付けの優先順位を示すグラフである。図４に示すように、レセプトグループＢのＩＤ１は“１３０”であり、レセプトグループＡと共通である。また、レセプトグループＢのＩＤ２は“４７９”であり、レセプトグループＣと共通である。年月についてみると、レセプトグループＡの最初のレセプト発生月は２０１６年２月で、レセプトグループＣの最初のレセプト発生月は２０１５年１２月であり、レセプトグループＢの最終のレセプト発生月である２０１５年１０月とより近いのはレセプトグループＣであるといえる。
しかしながら、ＩＤ１とＩＤ２のどちらにも紐付け可能な場合は、ＩＤ１を優先する。これは、ＩＤ２では同姓同名・同一生年月日・同性患者が同一ＩＤとなってしまうが，ＩＤ１では、同じ扶養に入っている同性の双子等を除き、別人が同一ＩＤとなる頻度が比較的少ないからである。
したがって、ＩＤ１を共通とするレセプトグループが存在する（ステップＳ１３）場合には、ＩＤ１を共通とするレセプトグループ同士を紐付けする（ステップＳ１４）。その後、ＩＤ２を共通とするレセプトグループが存在するかの判断を行い（ステップＳ１５）、ＩＤ２を共通とするレセプトグループが存在する場合には、ＩＤ２を共通とするレセプトグループ同士を紐付けする（ステップＳ１６）。
しかしながら、ＩＤ１とＩＤ２のどちらにも紐付け可能な場合は、ＩＤ１を優先する。これは、ＩＤ２では同姓同名・同一生年月日・同性患者が同一ＩＤとなってしまうが，ＩＤ１では、同じ扶養に入っている同性の双子等を除き、別人が同一ＩＤとなる頻度が比較的少ないからである。
したがって、ＩＤ１を共通とするレセプトグループが存在する（ステップＳ１３）場合には、ＩＤ１を共通とするレセプトグループ同士を紐付けする（ステップＳ１４）。その後、ＩＤ２を共通とするレセプトグループが存在するかの判断を行い（ステップＳ１５）、ＩＤ２を共通とするレセプトグループが存在する場合には、ＩＤ２を共通とするレセプトグループ同士を紐付けする（ステップＳ１６）。
（ＩＤ１を共通とするレセプトグループ同士の紐付けについて）
図５は、ＩＤ１を共通とするレセプトグループ同士の紐付けフロー図を示している。図５に示すように、まず、最初のレセプト発生月が先のレセプトグループの最終のレセプト発生月と同年月以降である、後のレセプトグループを抽出する（ステップＳ２１）。図６は、紐付けにおける最終のレセプト発生月と最初のレセプト発生月の関係を示すグラフである。図６に示すように、レセプトグループＡのＩＤ１とレセプトグループＢのＩＤ１はいずれも“１３０”であり共通している。そして、レセプトグループＡの最終のレセプト発生月は２０１５年の１０月であり、レセプトグループＢの最初のレセプト発生月も２０１５年の１０月であるため、後のレセプトグループであるレセプトグループＢは、最初のレセプト発生月が先のレセプトグループであるレセプトグループＡの最終のレセプト発生月と同年月となり、紐付け可能となる。これとは異なり、例えば、レセプトグループＢの最初のレセプト発生月が２０１５年の９月であるような場合には、上記条件を充たさず、紐付けは行わないこととなる。
図５は、ＩＤ１を共通とするレセプトグループ同士の紐付けフロー図を示している。図５に示すように、まず、最初のレセプト発生月が先のレセプトグループの最終のレセプト発生月と同年月以降である、後のレセプトグループを抽出する（ステップＳ２１）。図６は、紐付けにおける最終のレセプト発生月と最初のレセプト発生月の関係を示すグラフである。図６に示すように、レセプトグループＡのＩＤ１とレセプトグループＢのＩＤ１はいずれも“１３０”であり共通している。そして、レセプトグループＡの最終のレセプト発生月は２０１５年の１０月であり、レセプトグループＢの最初のレセプト発生月も２０１５年の１０月であるため、後のレセプトグループであるレセプトグループＢは、最初のレセプト発生月が先のレセプトグループであるレセプトグループＡの最終のレセプト発生月と同年月となり、紐付け可能となる。これとは異なり、例えば、レセプトグループＢの最初のレセプト発生月が２０１５年の９月であるような場合には、上記条件を充たさず、紐付けは行わないこととなる。
次に、抽出された後のレセプトグループが複数存在しないかにつき判断がなされ（ステップＳ２２）、１つしか存在しない場合には、該レセプトグループを選択する（ステップＳ２３）。これに対して、抽出された後のレセプトグループが複数存在する場合には、後のレセプトグループ同士の最初のレセプト発生月は異なるかの判断がなされる（ステップＳ２４）。
ここで、後のレセプトグループ同士の最初のレセプト発生月は同一である場合には紐付けはなされない（ステップＳ２８）。図７は、最初のレセプト発生月が同一である場合を示すグラフである。図７に示すように、レセプトグループＡ、Ｂ及びＣのＩＤ１は、いずれも“１３０”であり共通している。しかしながら、レセプトグループＡの最終のレセプト発生月に対するレセプトグループＢ及びＣの最初のレセプト発生月はいずれも２０１６年１月であり、最初のレセプト発生月が同一であるといえる。したがって、レセプトグループＡは、Ｂ又はＣのいずれとも紐付けはなされないこととなる。
ここで、後のレセプトグループ同士の最初のレセプト発生月は同一である場合には紐付けはなされない（ステップＳ２８）。図７は、最初のレセプト発生月が同一である場合を示すグラフである。図７に示すように、レセプトグループＡ、Ｂ及びＣのＩＤ１は、いずれも“１３０”であり共通している。しかしながら、レセプトグループＡの最終のレセプト発生月に対するレセプトグループＢ及びＣの最初のレセプト発生月はいずれも２０１６年１月であり、最初のレセプト発生月が同一であるといえる。したがって、レセプトグループＡは、Ｂ又はＣのいずれとも紐付けはなされないこととなる。
図５のステップＳ２４において、後のレセプトグループ同士の最初のレセプト発生月が異なる場合には、先のレセプトグループの最終のレセプト発生月に最も近い最初のレセプト発生月を有する後のレセプトグループを選択する（ステップＳ２５）。図８は、最初のレセプト発生月が異なる場合の紐付けの優先順位を示すグラフである。図８に示すように、レセプトグループＡ、Ｂ及びＣのＩＤ１は、いずれも“２６０”であり共通している。しかしながら、レセプトグループＡの最終のレセプト発生月２０１５年３月に対して、レセプトグループＢの最初のレセプト発生月は２０１５年５月、レセプトグループＣの最初のレセプト発生月は２０１６年１月となっている。このような場合には、レセプトグループＡは、レセプトグループＡの最終のレセプト発生月２０１５年３月により近い最初のレセプト発生月を有するレセプトグループＢと紐付けすることとなる。
図５のステップＳ２３及びステップＳ２５において、後のレセプトグループが選択された場合でも、先のレセプトグループの転帰区分に死亡転帰が示されている場合には、先のレセプトグループの最終のレセプト発生月から３か月を超えた最初のレセプト発生月を有する後のレセプトグループ（ステップＳ２６）については、紐付けがなされない（ステップＳ２８）。
これに対して、先のレセプトグループの転帰区分に死亡転帰が示されていない場合、又は、死亡転帰が示されているが、選択された後のレセプトグループが、先のレセプトグループの最終のレセプト発生月から３か月以内の最初のレセプト発生月を有する場合には、紐付けがなされる（ステップＳ２７）。
図９は、死亡転帰から３か月を超えた最初のレセプト発生月を有する場合を示すグラフである。図９に示すように、レセプトグループＡ及びＢのＩＤ１はいずれも“８６３”で共通している。しかしながら、レセプトグループＡには、図示しないが最終のレセプト発生月である２０１５年１０月のレセプトに死亡転帰が示されている。そして、レセプトグループＢの最初のレセプト発生月は２０１６年２月であり、死亡転帰が示されたレセプトグループであるレセプトグループＡの最終のレセプト発生月から３か月を超えている。したがって、レセプトグループＡとＢは紐付けされないこととなる。
これに対して、先のレセプトグループの転帰区分に死亡転帰が示されていない場合、又は、死亡転帰が示されているが、選択された後のレセプトグループが、先のレセプトグループの最終のレセプト発生月から３か月以内の最初のレセプト発生月を有する場合には、紐付けがなされる（ステップＳ２７）。
図９は、死亡転帰から３か月を超えた最初のレセプト発生月を有する場合を示すグラフである。図９に示すように、レセプトグループＡ及びＢのＩＤ１はいずれも“８６３”で共通している。しかしながら、レセプトグループＡには、図示しないが最終のレセプト発生月である２０１５年１０月のレセプトに死亡転帰が示されている。そして、レセプトグループＢの最初のレセプト発生月は２０１６年２月であり、死亡転帰が示されたレセプトグループであるレセプトグループＡの最終のレセプト発生月から３か月を超えている。したがって、レセプトグループＡとＢは紐付けされないこととなる。
（ＩＤ２を共通とするレセプトグループ同士の紐付けについて）
図２に示すように、ＩＤ１の紐付け（ステップＳ１４）の後、ＩＤ１についての途切れの前後で同一のＩＤ２を有するレセプトグループが存在する場合（ステップＳ１５）には、紐付けを行う（ステップＳ１６）。
ＩＤ２を共通とするレセプト同士の紐付けは、資格喪失したレセプトが存在することを考慮したアルゴリズムで処理を行う。なぜなら資格喪失したレセプトについては審査支払機関を経由し保険者でチェックを行い再審査請求となるため、３か月間程度は新旧のＩＤ１が併存しうるからである。具体的な処理について、図１０を参照しながら説明する。
図２に示すように、ＩＤ１の紐付け（ステップＳ１４）の後、ＩＤ１についての途切れの前後で同一のＩＤ２を有するレセプトグループが存在する場合（ステップＳ１５）には、紐付けを行う（ステップＳ１６）。
ＩＤ２を共通とするレセプト同士の紐付けは、資格喪失したレセプトが存在することを考慮したアルゴリズムで処理を行う。なぜなら資格喪失したレセプトについては審査支払機関を経由し保険者でチェックを行い再審査請求となるため、３か月間程度は新旧のＩＤ１が併存しうるからである。具体的な処理について、図１０を参照しながら説明する。
図１０は、ＩＤ２を共通とするレセプトグループ同士の紐付けフロー図を示している。図１０に示すように、まず、ＩＤ１が途切れた年月以降の、共通のＩＤ２を有するレセプトグループの内、最もＩＤ１が途切れた年月に近いものを探索する（ステップＳ３０１）。
ステップＳ３０１における探索により、ＩＤ１が途切れた年月以降のレセプトグループが検出されなかった場合（ステップＳ３０２）は、ＩＤ１が途切れた年月の前月において、共通のＩＤ２を有するレセプトグループを探索する（ステップＳ３０３）。図１１は、ＩＤ１が途切れた年月の前月に最初のレセプト発生月が存在する場合のグラフである。図１１に示すように、レセプトグループＡとレセプトグループＢのＩＤ２はいずれも“４７９”であり共通している。そして、レセプトグループＢの最初のレセプト発生月は、レセプトグループＡの最終のレセプト発生月の前月となっている。したがって、図１１に示すような場合には、レセプトグループＡとレセプトグループＢを紐付けし得ることとなる。
ステップＳ３０１における探索により、ＩＤ１が途切れた年月以降のレセプトグループが検出されなかった場合（ステップＳ３０２）は、ＩＤ１が途切れた年月の前月において、共通のＩＤ２を有するレセプトグループを探索する（ステップＳ３０３）。図１１は、ＩＤ１が途切れた年月の前月に最初のレセプト発生月が存在する場合のグラフである。図１１に示すように、レセプトグループＡとレセプトグループＢのＩＤ２はいずれも“４７９”であり共通している。そして、レセプトグループＢの最初のレセプト発生月は、レセプトグループＡの最終のレセプト発生月の前月となっている。したがって、図１１に示すような場合には、レセプトグループＡとレセプトグループＢを紐付けし得ることとなる。
ステップＳ３０３における探索により、ＩＤ１が途切れた年月の前月において、共通のＩＤ２を有するレセプトグループが検出されなかった場合（ステップＳ３０４）は、ＩＤ１が途切れた年月の前々月において、共通のＩＤ２を有するレセプトグループを探索する（ステップＳ３０５）。図１２は、ＩＤ１が途切れた年月の前々月に最初のレセプト発生月が存在する場合のグラフである。図１２に示すように、レセプトグループＡとレセプトグループＢのＩＤ２はいずれも“４７９”であり共通している。そして、レセプトグループＢの最初のレセプト発生月は、レセプトグループＡの最終のレセプト発生月の前々月となっている。したがって、図１２に示すような場合には、レセプトグループＡとレセプトグループＢを紐付けし得ることとなる。
上記ステップＳ３０２においてＩＤ１が途切れた年月に近いレセプトグループが検出された場合であっても、先のレセプトグループの死亡転帰から３か月を超えた最初のレセプト発生月を有する後のレセプトグループである場合（ステップＳ３０７）には、紐付けはなされない（ステップＳ３１０）。
これに対して、先のレセプトグループの死亡転帰から３か月を超えた最初のレセプト発生月を有する後のレセプトグループではない場合、又は、ステップＳ３０４若しくはステップＳ３０６のいずれかにおいて共通のＩＤ２を有するレセプトグループが検出された場合には、最初のレセプト発生月が同一である複数のレセプトグループが検出されたかの判断（ステップＳ３０８）がなされる。ここで、最初のレセプト発生月が同一である複数のレセプトグループが検出された場合には紐付けはなされない（ステップＳ３１１）。これに対して、最初のレセプト発生月が同一である複数のレセプトグループが検出されなかった場合は、ＩＤ１が途切れた年月に近いレセプトグループを紐付けする（ステップＳ３０９）。
これに対して、先のレセプトグループの死亡転帰から３か月を超えた最初のレセプト発生月を有する後のレセプトグループではない場合、又は、ステップＳ３０４若しくはステップＳ３０６のいずれかにおいて共通のＩＤ２を有するレセプトグループが検出された場合には、最初のレセプト発生月が同一である複数のレセプトグループが検出されたかの判断（ステップＳ３０８）がなされる。ここで、最初のレセプト発生月が同一である複数のレセプトグループが検出された場合には紐付けはなされない（ステップＳ３１１）。これに対して、最初のレセプト発生月が同一である複数のレセプトグループが検出されなかった場合は、ＩＤ１が途切れた年月に近いレセプトグループを紐付けする（ステップＳ３０９）。
（第２の名寄せ用中間テーブル生成について）
図１に示す第２の名寄せ用中間テーブルの生成（ステップＳ０２）について図１３を参照しながら説明する。図１３は、第２の名寄せ用中間テーブル生成フロー図を示している。図１３に示すように、まず、調剤レセプトからＩＤ１、ＩＤ２、診療年月を抽出する（ステップＳ４１）。次に、ＩＤ１が同一のレセプトを同一人物のものとしてグループ化する（ステップＳ４２）。ＩＤ２を共通とするレセプトグループが存在する場合（ステップＳ４３）には、ＩＤ２を共通とするレセプトグループと紐付けを行う（ステップＳ４４）。
なお、ステップＳ４４における紐付けは、図１０に示す第１の名寄せ用中間テーブル生成において、ＩＤ２を共通とするレセプトグループ同士の紐付けを行う場合と同様の方法により行う。
図１に示す第２の名寄せ用中間テーブルの生成（ステップＳ０２）について図１３を参照しながら説明する。図１３は、第２の名寄せ用中間テーブル生成フロー図を示している。図１３に示すように、まず、調剤レセプトからＩＤ１、ＩＤ２、診療年月を抽出する（ステップＳ４１）。次に、ＩＤ１が同一のレセプトを同一人物のものとしてグループ化する（ステップＳ４２）。ＩＤ２を共通とするレセプトグループが存在する場合（ステップＳ４３）には、ＩＤ２を共通とするレセプトグループと紐付けを行う（ステップＳ４４）。
なお、ステップＳ４４における紐付けは、図１０に示す第１の名寄せ用中間テーブル生成において、ＩＤ２を共通とするレセプトグループ同士の紐付けを行う場合と同様の方法により行う。
（第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルの統合について）
図１に示すように、ステップＳ０１において生成した第１の名寄せ用中間テーブルとステップＳ０２において生成した第２の名寄せ用中間テーブルは、ステップＳ０３において統合される。
図１４は、名寄せ用中間テーブルの統合フロー図を示している。図１４に示すように、第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルを統合し、実際には同一人物であるＩＤ１同士の一対一対応表を生成する（ステップＳ５１）。下記表３は先出ＩＤ１と後出ＩＤ１の一対一対応表を表している。ここで、「先出ＩＤ１」とは、医科、ＤＰＣ、調剤を問わず、一番目に出現したＩＤ１のことであり、「後出ＩＤ１」は二番目以降に出てきたＩＤ１のことである。
図１に示すように、ステップＳ０１において生成した第１の名寄せ用中間テーブルとステップＳ０２において生成した第２の名寄せ用中間テーブルは、ステップＳ０３において統合される。
図１４は、名寄せ用中間テーブルの統合フロー図を示している。図１４に示すように、第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルを統合し、実際には同一人物であるＩＤ１同士の一対一対応表を生成する（ステップＳ５１）。下記表３は先出ＩＤ１と後出ＩＤ１の一対一対応表を表している。ここで、「先出ＩＤ１」とは、医科、ＤＰＣ、調剤を問わず、一番目に出現したＩＤ１のことであり、「後出ＩＤ１」は二番目以降に出てきたＩＤ１のことである。
上記表３に示す先出ＩＤ１と後出ＩＤ１は、いずれも英数字は異なるがＩＤ２が共通することにより、同一人物と考えられるものである。表３では問題とはならないが、先出ＩＤ１と後出ＩＤ１が入れ替わったものが表示されている場合には、循環参照が問題となる。
図１５は循環参照の例を示すグラフである。図１５に示すように、レセプトグループＡのＩＤ１は“１３５”であり、レセプトグループＢのＩＤ１は、“５１２”であるため、ＩＤ１は異なるが、レセプトグループＡ及びレセプトグループＢのＩＤ２はいずれも“４７９”で共通している。しかしながら、レセプトグループＡ及びレセプトグループＢは、いずれも診療年月が２０１５年４月のみの１つのレセプトからなるレセプトグループであるため、一対一対応表を作成する際には、レセプトグループＡを先出ＩＤ１として、レセプトグループＢを後出ＩＤ１とすることもできるし、逆に、レセプトグループＢを先出ＩＤ１として、レセプトグループＡを後出ＩＤ１とすることも可能である。仮にどちらも入力すると、統合の際に互いが互いを参照するという循環参照が生じてしまうため、この不都合を回避する必要がある。
そこで、循環参照が発生する場合（ステップＳ５２）には、対応セットの一方を削除する（ステップＳ５３）。
図１５は循環参照の例を示すグラフである。図１５に示すように、レセプトグループＡのＩＤ１は“１３５”であり、レセプトグループＢのＩＤ１は、“５１２”であるため、ＩＤ１は異なるが、レセプトグループＡ及びレセプトグループＢのＩＤ２はいずれも“４７９”で共通している。しかしながら、レセプトグループＡ及びレセプトグループＢは、いずれも診療年月が２０１５年４月のみの１つのレセプトからなるレセプトグループであるため、一対一対応表を作成する際には、レセプトグループＡを先出ＩＤ１として、レセプトグループＢを後出ＩＤ１とすることもできるし、逆に、レセプトグループＢを先出ＩＤ１として、レセプトグループＡを後出ＩＤ１とすることも可能である。仮にどちらも入力すると、統合の際に互いが互いを参照するという循環参照が生じてしまうため、この不都合を回避する必要がある。
そこで、循環参照が発生する場合（ステップＳ５２）には、対応セットの一方を削除する（ステップＳ５３）。
（名寄せテーブル生成について）
図１６は、名寄せテーブル生成フロー図を示している。図１６に示すように、上述の一対一対応表を利用し、後出ＩＤ１を先出ＩＤ１に置き換える（ステップＳ６１）。これにより、同一人物の複数のＩＤ１が一種類に統合される。置き換えられたＩＤ１が別の対応セットの後出ＩＤ１であることもあるため、その場合は、さらに先出ＩＤ１へと置き換える。このように、全ての置き換えが完了していなければ（ステップＳ６２）、再度、後出ＩＤ１を先出ＩＤ１に置き換える（ステップＳ６１）。この作業を後出ＩＤ１がなくなるまで繰り返す。全ての置き換えが完了し、最終的に残ったＩＤ１を新しい名寄せ変数“ＩＤ０”とする（ステップＳ６３）。
なお、本実施例では、先出ＩＤ１をＩＤ０に使用しているが、後出ＩＤ１をＩＤ０に使用することでも構わない。
図１６は、名寄せテーブル生成フロー図を示している。図１６に示すように、上述の一対一対応表を利用し、後出ＩＤ１を先出ＩＤ１に置き換える（ステップＳ６１）。これにより、同一人物の複数のＩＤ１が一種類に統合される。置き換えられたＩＤ１が別の対応セットの後出ＩＤ１であることもあるため、その場合は、さらに先出ＩＤ１へと置き換える。このように、全ての置き換えが完了していなければ（ステップＳ６２）、再度、後出ＩＤ１を先出ＩＤ１に置き換える（ステップＳ６１）。この作業を後出ＩＤ１がなくなるまで繰り返す。全ての置き換えが完了し、最終的に残ったＩＤ１を新しい名寄せ変数“ＩＤ０”とする（ステップＳ６３）。
なお、本実施例では、先出ＩＤ１をＩＤ０に使用しているが、後出ＩＤ１をＩＤ０に使用することでも構わない。
具体的に、上記表３で説明する。まず、時系列的に新しいレセプトグループｃから後出ＩＤ１を先出ＩＤ１に置き換える。先出ＩＤ１が“78wmdjfg”、後出ＩＤ１が“Ajdke783”であるレセプトグループｃにおいては、後出ＩＤ１“Ajdke783”は先出ＩＤ１“78wmdjfg”に置き換えられる。また、レセプトグループｃの置き換え前の後出ＩＤ１“Ajdke783”は、レセプトグループｂの先出ＩＤ１“Ajdke783”と同一である。“Ajdke783”は“78wmdjfg”に置き換えられたため、レセプトグループｂの後出ＩＤ１“ue8k22ue”を先出ＩＤ１“Ajdke783”に置き換える際には、“78wmdjfg”に置き換えられる。同様に、レセプトグループｂの置き換え前の後出ＩＤ１“ue8k22ue”は、レセプトグループａの先出ＩＤ１“ue8k22ue”と同一であるため、レセプトグループａの後出ＩＤ１“p8d89jss”を先出ＩＤ１“ue8k22ue”に置き換える際には、“78wmdjfg”に置き換えられる。後出ＩＤ１がなくなるまで繰り返し、全ての置き換えが完了し、最終的に残ったＩＤ１は“78wmdjfg”になる。下記表４は、生成が完了した名寄せテーブルを表している。
上記表４に示すように、レセプトグループ（ａ〜ｃ）の全てについて、ＩＤ０“78wmdjfg”が設定されている。本実施例では３回目の更新により名寄せテーブルの生成が完了しているが、実際にはより多数の置き換えが行われる場合も存在する。また、このＩＤ０には、単回受診等で名寄せ対象とならなかったため元々のＩＤ１がそのまま残存したものも含まれる。
なお、レセプトグループにおける先出ＩＤ１と後出ＩＤ１については、古い方から新しい方に向かう時系列に沿った先後関係（古い・・・先；新しい・・・後）であっても、新しい方から古い方に向かう時系列に沿った先後関係（新しい・・・先；古い・・・後）であってもよい。
また、複数のレセプトグループの名寄せの順番については、特に限定されるものではなく、例えば、時系列に沿って古いレセプトを含むレセプトグループから処理してもよいし、或は、新しいレセプトを含むレセプトグループから処理してもよい。
また、複数のレセプトグループの名寄せの順番については、特に限定されるものではなく、例えば、時系列に沿って古いレセプトを含むレセプトグループから処理してもよいし、或は、新しいレセプトを含むレセプトグループから処理してもよい。
（ＩＤ０の妥当性について）
図１７は、ＩＤ０とＩＤ１の名寄せ精度の比較グラフであり、具体的には、平成２５年度の１年分の患者（ＤＰＣ、医科入院、医科入院外、調剤）を対象に、ＩＤ０にて名寄せを実施し、従来のＩＤ１による名寄せ患者数及び平成２５年１０月の推計人口と比較した性年齢階級別の結果を示している。なお、（１）は男性、（２）は女性についての結果を示している。図１７（１）及び（２）に示すように、男女とも、ＩＤ０による性年齢階級別患者数はＩＤ１による患者数を下回っており、追加名寄せ率（ＩＤ１名寄せに比してＩＤ０名寄せで同一人物の特定に追加的に成功した割合）は男性で６．２％、女性で７．１％であった。ＩＤ１により名寄せされた患者数は、０〜９歳や７５〜７９歳、９０歳以上、男性の８５〜８９歳、女性の２５〜２９歳において推計人口を大きく上回っていた。一方、ＩＤ０により名寄せされた患者数は、男性の８５歳以上や女性の９０歳以上で推計人口を大きく上回ったが、それ以外の性年齢階級ではおおむね推計人口の範囲内に収まった。
図１７は、ＩＤ０とＩＤ１の名寄せ精度の比較グラフであり、具体的には、平成２５年度の１年分の患者（ＤＰＣ、医科入院、医科入院外、調剤）を対象に、ＩＤ０にて名寄せを実施し、従来のＩＤ１による名寄せ患者数及び平成２５年１０月の推計人口と比較した性年齢階級別の結果を示している。なお、（１）は男性、（２）は女性についての結果を示している。図１７（１）及び（２）に示すように、男女とも、ＩＤ０による性年齢階級別患者数はＩＤ１による患者数を下回っており、追加名寄せ率（ＩＤ１名寄せに比してＩＤ０名寄せで同一人物の特定に追加的に成功した割合）は男性で６．２％、女性で７．１％であった。ＩＤ１により名寄せされた患者数は、０〜９歳や７５〜７９歳、９０歳以上、男性の８５〜８９歳、女性の２５〜２９歳において推計人口を大きく上回っていた。一方、ＩＤ０により名寄せされた患者数は、男性の８５歳以上や女性の９０歳以上で推計人口を大きく上回ったが、それ以外の性年齢階級ではおおむね推計人口の範囲内に収まった。
図１８は、患者突合装置の説明図を示している。図１８に示すように、コンピュータ３には、患者突合装置４及び通信手段４５が備えられている。コンピュータ３とサーバ５は、通信手段４５により、ネットワーク６を介して有線又は無線で接続されている。また、サーバ５にはＮＤＢが設けられている。
患者突合装置４には、第１の名寄せ用中間テーブル生成手段４１、第２の名寄せ用中間テーブル生成手段４２、対応テーブル生成手段４３及び名寄せテーブル生成手段４４が設けられている。
患者突合装置４には、第１の名寄せ用中間テーブル生成手段４１、第２の名寄せ用中間テーブル生成手段４２、対応テーブル生成手段４３及び名寄せテーブル生成手段４４が設けられている。
患者突合装置４を稼動する際には、コンピュータ４は、通信手段４５を用いて、サーバ５からデータを受信する。コンピュータ４は、受信したデータを使用して、第１の名寄せ用中間テーブル生成手段４１により第１の名寄せ用中間テーブルを生成する。次に、第２の名寄せ用中間テーブル生成手段４２により第２の名寄せ用中間テーブルを生成する。生成したテーブルを対応テーブル生成手段４３により統合する。統合したテーブルを基に、名寄せテーブル生成手段４４により名寄せテーブルを生成する。
完成した名寄せテーブルは、通信手段４５により、ネットワーク６を介してサーバに送信される。これにより、サーバ５におけるＮＤＢは、より名寄せ精度の向上したデータベースとして利用可能となる。
サーバ５におけるＮＤＢは日々新しい情報に更新されるため、上記のような、患者突合装置４の稼動は、一度だけではなく、定期的に行うことが望ましい。頻繁に患者突合装置４を稼動することで、より名寄せ精度の向上したデータベースとすることが可能である。
完成した名寄せテーブルは、通信手段４５により、ネットワーク６を介してサーバに送信される。これにより、サーバ５におけるＮＤＢは、より名寄せ精度の向上したデータベースとして利用可能となる。
サーバ５におけるＮＤＢは日々新しい情報に更新されるため、上記のような、患者突合装置４の稼動は、一度だけではなく、定期的に行うことが望ましい。頻繁に患者突合装置４を稼動することで、より名寄せ精度の向上したデータベースとすることが可能である。
本発明は、レセプト情報データ等の効果的な活用を支援するツールとして有用である。
３ コンピュータ
４ 患者突合装置
５ サーバ
６ ネットワーク
４１ 第１の名寄せ用中間テーブル生成手段
４２ 第２の名寄せ用中間テーブル生成手段
４３ 対応テーブル生成手段
４４ 名寄せテーブル生成手段
４５ 通信手段
４ 患者突合装置
５ サーバ
６ ネットワーク
４１ 第１の名寄せ用中間テーブル生成手段
４２ 第２の名寄せ用中間テーブル生成手段
４３ 対応テーブル生成手段
４４ 名寄せテーブル生成手段
４５ 通信手段
Claims (7)
- 保険者番号に基づく第１のハッシュ値と氏名に基づく第２のハッシュ値の少なくとも２つの検索キーを有するレセプト情報データベースの突合方法であって、
１）調剤レセプト以外のレセプトを用いて、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致に基づいてレセプトを連結し、同一患者の第１の名寄せ用中間テーブルを生成するステップと、
２）調剤レセプトを用いて、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致に基づいてレセプトを連結し、同一患者の第２の名寄せ用中間テーブルを生成するステップと、
３）同一患者の第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルを診療年月の時系列に沿って統合し、同一患者における第１のハッシュ値の対応テーブルを生成するステップと、
４）前記対応テーブルにおいて複数種の第１のハッシュ値が存在する場合には、複数種の第１のハッシュ値をユニークな第１のハッシュ値に置き換えた名寄せテーブルを生成するステップ、
を備え、前記データベースにおけるデータを突合して患者の名寄せを行うことを特徴とする患者突合方法。 - 第１及び第２の名寄せ用中間テーブル生成ステップにおいて、
第１のハッシュ値と第２のハッシュ値の両方が一致する場合、同一患者のレセプトとして連結し、最初のレセプト発生月から最終のレセプト発生月まで、又は、最初のレセプト発生月から転帰区分にて死亡転帰が示される当該月まで、を１つのレセプトグループとして連結するステップと、
それぞれのレセプトグループにおいて、第１のハッシュ値又は第２のハッシュ値の何れかのみ一致する場合、最終のレセプト発生月を連結対象とするレセプトグループの連結候補を、第１のハッシュ値が一致、最も時系列的に近い、同年月を除き期間がオーバーラップしない、又は、同じ第１若しくは第２のハッシュ値の候補の最初のレセプト発生月が同一ではない、の少なくとも何れかを満足する最初のレセプト発生月を連結対象とするレセプトグループと連結するステップ、
を備えることを特徴とする請求項１に記載の患者突合方法。 - 第１及び第２の名寄せ用中間テーブル生成ステップにおいて、
第１のハッシュ値と第２のハッシュ値の両方が一致する場合、同一患者のレセプトとして連結し、最初のレセプト発生月から最終のレセプト発生月まで、又は、最初のレセプト発生月から転帰区分にて死亡転帰が示される当該月まで、を１つのレセプトグループとして連結するステップと、
それぞれのレセプトグループにおいて、第１のハッシュ値又は第２のハッシュ値の何れかのみ一致する場合、最終のレセプト発生月を連結対象とするレセプトグループの連結候補を、第１のハッシュ値が一致、最も時系列的に近い、同年月を除き期間がオーバーラップしない、及び、同じ第１若しくは第２のハッシュ値の候補の最初のレセプト発生月が同一ではない、の全てを満足するレセプトグループと連結するステップ、
を備えることを特徴とする請求項１に記載の患者突合方法。 - 死亡転帰が示されるレセプトグループは、その最終月から３か月を超えた最初のレセプト発生月を有する他のレセプトグループとは連結しないことを特徴とする請求項２又は３に記載の患者突合方法。
- レセプト情報における医療機関所在地、診療開始年月日、傷病名、又は、患者の年齢階級の少なくとも何れかが一致するレセプトグループと連結することを特徴とする請求項２〜４の何れかに記載の患者突合方法。
- 請求項１〜５の何れかの患者突合方法における各ステップを、コンピュータに実行させる患者突合プログラム。
- 保険者番号に基づく第１のハッシュ値と氏名に基づく第２のハッシュ値の少なくとも２つの検索キーを有するレセプト情報データベースの突合を行う装置であって、
１）調剤レセプト以外のレセプトを入力し、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致を判断し、該判断に基づいて同一患者のレセプトを連結し、第１の名寄せ用中間テーブルを生成する第１の名寄せ用中間テーブル生成手段と、
２）調剤レセプトを入力し、第１のハッシュ値と第２のハッシュ値及び診療年月を少なくとも抽出し、診療年月の複数月にわたる第１のハッシュ値と第２のハッシュ値の少なくとも何れかの一致を判断し、該判断に基づいて同一患者のレセプトを連結し、第２の名寄せ用中間テーブルを生成する第２の名寄せ用中間テーブル生成手段と、
３）同一患者の第１の名寄せ用中間テーブルと第２の名寄せ用中間テーブルを診療年月の時系列に沿って統合し、同一患者における第１のハッシュ値の対応テーブルを生成する対応テーブル生成手段と、
４）前記対応テーブルにおいて複数種の第１のハッシュ値が存在する場合には、複数種の第１のハッシュ値をユニークな第１のハッシュ値に置き換えた名寄せテーブルを生成する名寄せテーブル生成手段、
を備え、前記データベースにおけるデータを突合して患者の名寄せを行うことを特徴とする患者突合装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018075685A JP2019185403A (ja) | 2018-04-10 | 2018-04-10 | レセプト情報・特定健診等情報データベースにおける患者突合方法及び装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018075685A JP2019185403A (ja) | 2018-04-10 | 2018-04-10 | レセプト情報・特定健診等情報データベースにおける患者突合方法及び装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2019185403A true JP2019185403A (ja) | 2019-10-24 |
Family
ID=68341336
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2018075685A Pending JP2019185403A (ja) | 2018-04-10 | 2018-04-10 | レセプト情報・特定健診等情報データベースにおける患者突合方法及び装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2019185403A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2022190778A1 (ja) * | 2021-03-09 | 2022-09-15 | レメディ・アンド・カンパニー株式会社 | 匿名医療情報管理システム |
| JP7236514B1 (ja) | 2021-09-22 | 2023-03-09 | 株式会社エム・エイチ・アイ | 情報提供システム、情報提供方法 |
| JP2023519551A (ja) * | 2020-04-03 | 2023-05-11 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 実体の複数の一意の識別子のための多値主キー |
-
2018
- 2018-04-10 JP JP2018075685A patent/JP2019185403A/ja active Pending
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2023519551A (ja) * | 2020-04-03 | 2023-05-11 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 実体の複数の一意の識別子のための多値主キー |
| JP7573639B2 (ja) | 2020-04-03 | 2024-10-25 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 実体の複数の一意の識別子のための多値主キー |
| WO2022190778A1 (ja) * | 2021-03-09 | 2022-09-15 | レメディ・アンド・カンパニー株式会社 | 匿名医療情報管理システム |
| JP7236514B1 (ja) | 2021-09-22 | 2023-03-09 | 株式会社エム・エイチ・アイ | 情報提供システム、情報提供方法 |
| JP2023045791A (ja) * | 2021-09-22 | 2023-04-03 | 株式会社エム・エイチ・アイ | 情報提供システム、情報提供方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7624027B1 (en) | Method and system for automated medical records processing | |
| US9141758B2 (en) | System and method for encrypting provider identifiers on medical service claim transactions | |
| US20130304506A1 (en) | System and method for managing health risks | |
| CA2884949C (en) | Systems and methods for verifying correlation of diagnosis and medication as part of qualifying program eligibility verification | |
| US20200013491A1 (en) | Interoperable Record Matching Process | |
| US7685002B2 (en) | Method and system for processing medical billing records | |
| Jönsen et al. | Total cost and cost predictors in systemic lupus erythematosus–8-years follow-up of a Swedish inception cohort | |
| JP2022190131A (ja) | 医療情報提供システム、サーバ、医療情報提供装置、医療情報提供媒体、医療情報提供方法及びプログラム | |
| Erickson et al. | Automatic address validation and health record review to identify homeless Social Security disability applicants | |
| Rabkin et al. | Nurse-led HIV services and quality of care at health facilities in Kenya, 2014–2016 | |
| JP2019185403A (ja) | レセプト情報・特定健診等情報データベースにおける患者突合方法及び装置 | |
| Leonhard et al. | Analysis of reimbursement of genetic counseling services at a single institution in a state requiring licensure | |
| Lewer et al. | Data resource: the Kent integrated dataset (KID) | |
| Withy et al. | Hawai ‘i physician workforce assessment 2020 | |
| US20150051915A1 (en) | Systems and methods for allocating payments across multiple healthcare accounts | |
| JP5433814B1 (ja) | 電子レセプトデータ変換システム及び電子レセプトデータ変換プログラム | |
| US20160378922A1 (en) | Methods and apparatuses for electronically documenting a visit of a patient | |
| Frederiksen et al. | The limitations of using Medicaid administrative data in abortion research | |
| JP6104674B2 (ja) | 匿名情報配信システム、匿名情報配信方法及び匿名情報配信プログラム | |
| US20220374548A1 (en) | Generating a compliance report of data processing activity | |
| Bogale et al. | Knowledge and practice of women with HIV on cervical cancer prevention and control and their attributes to utilize the screening services in Ethiopia: a cross sectional study | |
| Pollack et al. | Housing assistance among patients with cancer: SEER-Medicare US Department of Housing and Urban Development data linkage | |
| JP7085167B2 (ja) | 保険金支払支援システム、プログラム及び記録媒体 | |
| Adadey et al. | Incidence and mortality of cancer in the Volta Region of Ghana | |
| JP7224763B2 (ja) | 医療経営支援システム、医療経営支援方法、および医療経営支援プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A80 | Written request to apply exceptions to lack of novelty of invention |
Free format text: JAPANESE INTERMEDIATE CODE: A80 Effective date: 20180424 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180615 |