文献情報
文献番号
200301065A
報告書区分
総括
研究課題名
保険証認証のためのデータ交換基準に関する研究(総括研究報告書)
課題番号
-
研究年度
平成15(2003)年度
研究代表者(所属機関)
里村 洋一(千葉大学)
研究分担者(所属機関)
- 本多正幸(長崎大学)
- 佐藤清司(NTTコムウエアー)
- 大久保美也子(NTT東日本)
研究区分
厚生労働科学研究費補助金 健康安全総合研究経費 医療技術評価総合研究
研究開始年度
平成15(2003)年度
研究終了予定年度
-
研究費
5,000,000円
研究者交替、所属機関変更
-
研究報告書（概要版）
研究目的
保険情報の誤りや不正使用は、全国で年間600万件にも上っており、その処理のための経費は1000億円を越えると推定されている。これは、クレジットカードの様な認証システムを導入すれば解決することである。本研究は、保険者の持つ被保険者データのデータベースと医療機関等をインターネットを介して結び、保険証の有効性を即時的に認証を行うシステムの開発である。しかし、健康保険情報はその安全管理に十分注意を払う必要があり、慎重な準備と技術的な検討が必要である。本研究は、実用可能なシステムの要件を整理して、システムの設計を行い、システムの動作検証を行う。
研究方法
本研究は主として次の4ステップについて行った。
1. センターと全保険者との接続を想定した方式の確立。
認証センターと保険者のデータを結ぶ方法として、保険者から提供された被保険者等に関する情報をセンターのDBに集録して、これを認証に使う「事前登録型認証」と、保険者が独自に持つ被保険者DBにセンターを介してアクセスする「リアルタイム型認証」である。
2. センターと全医療機関との接続を想定した方式の確立
認証に必要なデータの項目とその電文構成(通信プロトコール)を標準化するとともに、医療機関の情報環境が多様であることを考慮して、認証に必要な情報の入力手段を多様化する必要がある。
本研究では、MMLとJMIXを通信プロトコールの候補として検討した。また、医療機関における入力は、カード化した保険証だけでなく、紙の保険証から手入力を行う方式、ORCAや各種病院情報システムのプログラムに組み込む方式を検討対象とした。
3. 課金方式の確立
システムの実用化には、運用経費の捻出を考慮しなければならない。そこで、本研究では個々の認証について課金する方法を検討した。
4. 上記の成果を踏まえて構築した実験システムによる構内通信実験
上記の要件を満たすシステムを試作し、構内環境で実験的に稼動させて、システムの実用性をチェックした。
1. センターと全保険者との接続を想定した方式の確立。
認証センターと保険者のデータを結ぶ方法として、保険者から提供された被保険者等に関する情報をセンターのDBに集録して、これを認証に使う「事前登録型認証」と、保険者が独自に持つ被保険者DBにセンターを介してアクセスする「リアルタイム型認証」である。
2. センターと全医療機関との接続を想定した方式の確立
認証に必要なデータの項目とその電文構成(通信プロトコール)を標準化するとともに、医療機関の情報環境が多様であることを考慮して、認証に必要な情報の入力手段を多様化する必要がある。
本研究では、MMLとJMIXを通信プロトコールの候補として検討した。また、医療機関における入力は、カード化した保険証だけでなく、紙の保険証から手入力を行う方式、ORCAや各種病院情報システムのプログラムに組み込む方式を検討対象とした。
3. 課金方式の確立
システムの実用化には、運用経費の捻出を考慮しなければならない。そこで、本研究では個々の認証について課金する方法を検討した。
4. 上記の成果を踏まえて構築した実験システムによる構内通信実験
上記の要件を満たすシステムを試作し、構内環境で実験的に稼動させて、システムの実用性をチェックした。
結果と考察
1.認証に必要なデータセットに関して
保険証の認証は、保険者と被保険者の識別情報が基本となる。各種の既存の患者情報交換規約においても保険証情報が定義されているので、それらが利用可能であるかどうかを検討した。HL7での定義は、アメリカにおける医療保険の制度を反映しており、制度の異なるわが国での利用には適さない(家族単位の保険加入制度は日本の特性)ことから、そのままでの採用をあきらめた。
HL7のCDA使うことを想定したMMLは日本の保険制度を前提に作成されているが、データ項目が認証には不十分である上、HL7のオーバーヘッドを考慮すると実用的ではないと判断された。そこで、比較的シンプルなJMIXを基本として採用し、これに認証に必要な項目(扶養者名、認証判定結果など)を加えたXML文書とすることとした。認証用のDBもこれに基づいて設計した。
一般に、これまでの通信規格における保険証情報は、受診者をキーとして作られているが、本システムでは、保険証そのものをキーとする必要があり、データセットには被扶養者全員に関する情報が盛り込まれなければならない。また、検証結果を認証請求者に返信するプロセスがあり、そのデータ構成も検討した。
2.センターと保険者との接続に関して
認証センターは二つの方法で認証を行うと仮定した。第一は、保険者が自ら運営するコンピュータシステムに認証機構を設け、医療機関等から認証要求があれば、認証センターがその要求を当該保険者の認証システムに要求を伝達し、また、そこからの返信を医療機関へと転送する方法(これをリアルタイム型と呼ぶ)、第二は、保険者から提供された穂保険者データをセンターのシステムが管理し、医療機関等からの認証要求に対して直接回答する方式(データ委託型と呼ぶ)である。いずれの場合においても、認証に必要なデータ項目、システム間の電送プロトコール、および医療機関への返信様式を標準化する必要がある。本研究では、JMIXによる通信規格を提供することを前提に、センターと各保険者の接続は個別に対応することとした。
認証センターとリアルタイム保険者間の通信は、VPNによってセキュリティーを保持することとし、実装実験においても、VPNを用いた通信実験とした。
3.医療機関の検証要求の方式
医療機関の情報化の程度はさまざまであるので、どのような器機を必要とするかについて検討を行った結果、次の4種のタイプについてそれぞれの対応をとることとした。
A、 病院情報システムが導入されている場合: 病院情報システムの患者管理部分に保険証認証プロセスを組み込む。(医事会計システムとのインターフェイスプロトコルを共通化し、検証プログラムの効率的利用を図る)
B、 病院情報システムがないか、もしくはプログラム組み込みが不可能な場合:独立したPCを設置し、これに保険証認証プログラムをインストールしセンターとの通信を行う。(病院情報システムへの反映は、その病院の手法に任せる)
C、 診療所の管理システムがあって、日本医師会のORCAに対応している場合: ORCA用プログラムを開発しこれを各システムにインストールする。
D、 診療所に情報機器がない場合か、あってもORCAに対応していない場合: 保険証認証用のPCを独立に設置し、これに保険証認証プログラムをインストールしセンターとの通信を行う。
5. 保険証の記号、番号の入力手段について
保険証の様式は、その記載項目が統一されているが、記載位置や表示の形式は各保険者によってばらばらである。近年、プラスチックカードへの移行が進みつつあるが、記載の標準化については、従来の程度を脱していない。また、情報が磁気やその他の記録媒体に記録されている場合も限られており標準化も行われていない、自動的な読み取りは、ほとんど不可能である。このためキーボードに頼るほかないが、本研究では、将来のカード化を考慮して、磁気ストライプ、1次元バーコード(代表的な5種のコードに対応)、2次元バーコード(QRコードを選択した)に対応する入力機器を準備することとした。
中でも、QRコードは、保険証の空白部分に貼付することが可能であって、安価に作成が可能であり、また、医療機関において保険証のケース当に貼り付けて、その後の検証に利用できる可能性もあり、実用性が高いと考えられた。(参照:
6. 課金方式の検討
認認証センターの運営を維持するための資金は、医療機関と保険者の両者から、使用頻度に応じて徴収することを仮定してその課金方式を考察した。
使用料金は電話回線の利用を前提に、電話料の請求にあわせて請求と徴収を行うこととした。
7.構内通信による実験結果
製作したシステム使ってNTT社内回線を用いて、一方を認証センター(事前蓄積型保険者用)、他端を医療機関に見立てて、通信テストを行い。交換でデータの検証と通信時間の測定を行った。
実行した検証対象は次のとおりである
1. 保険者の追加登録
2. 利用機関の登録
3. ユーザーの登録
4. 保険証基本認証
4.1 保険者が保険証の情報を認証センタのサーバに事前蓄積する
4.2 患者が病院窓口で保険証を提示する
4.3 病院担当者がシステムにログインする
4.4 病院担当者がシステムに資格の認証に必要な事項を入力
4.5 個別認証を実行する
4.6 認証センタから認証結果を受け取る
5.保険証応用認証
5.1 保険者が保険証の情報を認証センタのサーバに事前蓄積する
5.2 保険者が保険証の情報を認証センタのサーバに事前蓄積する
5.3 患者が窓口で保険証を提示する
5.4 病院担当者がシステムにログインする
5.5 病院担当者がシステムに資格の認証に必要な事項を入力
①認証対象年月日が、変更された保険証情報の効力発生年月日前のとき
②認証対象年月日が、変更された保険証情報の効力発生年月日後かつ開始年月日前
③認証対象年月日が、変更された保険証情報の効力発生年月日後かつ開始年月日後
④有効期限日を縮めた場合に、認証対象年月日が、有効期間内のとき
⑤有効期限日を縮めた場合に、認証対象年月日が、有効期間外のとき
6.一括認証
6.1 病院担当者が保険証資格の一括認証を実行する
個別認証応用で登録済みの保険証情報を使用する
認証対象年月日は個別認証応用で設定したように保険証情報変更の前後の日付を設定する
6.2 認証センタから認証結果を受け取る
8. 結果と評価
A) 保険者側の多様なデータ保持内容に対する柔軟性
実運用では多種多様な保険者側サーバと接続またはデータ交換を行うことが必要であり、データ交換の標準化を行ったとしてもデータ内容まで細かに規定することは難しい。認証結果として表示する各項目が保険者側のデータが一部存在しない場合を想定した確認を行った。 実施結果として、リアルタイム型保険者から受け取るデータについて一部不具合が出たが、すべての項目内容について空文字を許容するように対応したことで、保険者側のデータが存在すればそのまま表示し、存在しなければ空白表示となるようにした。
B) 保険者が保持するキー項目及びクライアントのキーボード入力内容のあいまいさに関する対応
保険者が保持するキー項目と、クライアントのキーボード入力内容(保険者番号、記号、番号、年月日)についての全角・半角の違い、空白の扱い、日付形式チェックについて以下のように対応し、あいまいさの除去を行った。
項目
認証センタで認証(文字列比較)する際の扱い
保険者番号
記号
番号
前後の空白を除去する
全角数字、記号、アルファベットを半角に変換する
対象年月日
前後の空白を除去する
年月日の妥当性をチェックする
C) 認証センタサーバでのアプリケーション処理性能
3項で示した今回の試験環境で認証センタが要求を受信してから結果を返すまでの処理時間を測定した。(単独アクセス)
測定個所
平均ターンアラウンドタイム
(クライアントの送信～受信で20回測定した平均時間)
医療機関クライアント～認証センタ(事前蓄積型)
212 msec
医療機関クライアント～認証センタ～リアルタイム型保険者
466 msec
試験環境では(今回はデスクトップ型PCをサーバとして使用しているなどのため)量的な評価はできないが、将来、サーバ専用機を用いて評価を行う機会があれば、DBの登録件数や使用回線などをより実際に近づけた上で、多重アクセス度を上げることによる性能測定が必要である。
D) 医療機関～認証センタ間のデータ交換仕様に関する考察
CDA準拠のMMLに沿ったデータ交換仕様を採用したが、保険証の認証データ交換という単一目的にしてはオーバーヘッドが大きすぎるのではないかという懸念がある。
通信容量そのものについては大きな問題ではないと考えられるが、認証センタに処理が集中した場合にオーバーヘッド分がセンタ処理上どの程度負荷に影響するのかを評価する必要がある。
この問題に関してはフェーズ2で検討予定のJ-MIX準拠のデータ交換仕様との比較で評価を行える可能性がある。
保険証の認証は、保険者と被保険者の識別情報が基本となる。各種の既存の患者情報交換規約においても保険証情報が定義されているので、それらが利用可能であるかどうかを検討した。HL7での定義は、アメリカにおける医療保険の制度を反映しており、制度の異なるわが国での利用には適さない(家族単位の保険加入制度は日本の特性)ことから、そのままでの採用をあきらめた。
HL7のCDA使うことを想定したMMLは日本の保険制度を前提に作成されているが、データ項目が認証には不十分である上、HL7のオーバーヘッドを考慮すると実用的ではないと判断された。そこで、比較的シンプルなJMIXを基本として採用し、これに認証に必要な項目(扶養者名、認証判定結果など)を加えたXML文書とすることとした。認証用のDBもこれに基づいて設計した。
一般に、これまでの通信規格における保険証情報は、受診者をキーとして作られているが、本システムでは、保険証そのものをキーとする必要があり、データセットには被扶養者全員に関する情報が盛り込まれなければならない。また、検証結果を認証請求者に返信するプロセスがあり、そのデータ構成も検討した。
2.センターと保険者との接続に関して
認証センターは二つの方法で認証を行うと仮定した。第一は、保険者が自ら運営するコンピュータシステムに認証機構を設け、医療機関等から認証要求があれば、認証センターがその要求を当該保険者の認証システムに要求を伝達し、また、そこからの返信を医療機関へと転送する方法(これをリアルタイム型と呼ぶ)、第二は、保険者から提供された穂保険者データをセンターのシステムが管理し、医療機関等からの認証要求に対して直接回答する方式(データ委託型と呼ぶ)である。いずれの場合においても、認証に必要なデータ項目、システム間の電送プロトコール、および医療機関への返信様式を標準化する必要がある。本研究では、JMIXによる通信規格を提供することを前提に、センターと各保険者の接続は個別に対応することとした。
認証センターとリアルタイム保険者間の通信は、VPNによってセキュリティーを保持することとし、実装実験においても、VPNを用いた通信実験とした。
3.医療機関の検証要求の方式
医療機関の情報化の程度はさまざまであるので、どのような器機を必要とするかについて検討を行った結果、次の4種のタイプについてそれぞれの対応をとることとした。
A、 病院情報システムが導入されている場合: 病院情報システムの患者管理部分に保険証認証プロセスを組み込む。(医事会計システムとのインターフェイスプロトコルを共通化し、検証プログラムの効率的利用を図る)
B、 病院情報システムがないか、もしくはプログラム組み込みが不可能な場合:独立したPCを設置し、これに保険証認証プログラムをインストールしセンターとの通信を行う。(病院情報システムへの反映は、その病院の手法に任せる)
C、 診療所の管理システムがあって、日本医師会のORCAに対応している場合: ORCA用プログラムを開発しこれを各システムにインストールする。
D、 診療所に情報機器がない場合か、あってもORCAに対応していない場合: 保険証認証用のPCを独立に設置し、これに保険証認証プログラムをインストールしセンターとの通信を行う。
5. 保険証の記号、番号の入力手段について
保険証の様式は、その記載項目が統一されているが、記載位置や表示の形式は各保険者によってばらばらである。近年、プラスチックカードへの移行が進みつつあるが、記載の標準化については、従来の程度を脱していない。また、情報が磁気やその他の記録媒体に記録されている場合も限られており標準化も行われていない、自動的な読み取りは、ほとんど不可能である。このためキーボードに頼るほかないが、本研究では、将来のカード化を考慮して、磁気ストライプ、1次元バーコード(代表的な5種のコードに対応)、2次元バーコード(QRコードを選択した)に対応する入力機器を準備することとした。
中でも、QRコードは、保険証の空白部分に貼付することが可能であって、安価に作成が可能であり、また、医療機関において保険証のケース当に貼り付けて、その後の検証に利用できる可能性もあり、実用性が高いと考えられた。(参照:
6. 課金方式の検討
認認証センターの運営を維持するための資金は、医療機関と保険者の両者から、使用頻度に応じて徴収することを仮定してその課金方式を考察した。
使用料金は電話回線の利用を前提に、電話料の請求にあわせて請求と徴収を行うこととした。
7.構内通信による実験結果
製作したシステム使ってNTT社内回線を用いて、一方を認証センター(事前蓄積型保険者用)、他端を医療機関に見立てて、通信テストを行い。交換でデータの検証と通信時間の測定を行った。
実行した検証対象は次のとおりである
1. 保険者の追加登録
2. 利用機関の登録
3. ユーザーの登録
4. 保険証基本認証
4.1 保険者が保険証の情報を認証センタのサーバに事前蓄積する
4.2 患者が病院窓口で保険証を提示する
4.3 病院担当者がシステムにログインする
4.4 病院担当者がシステムに資格の認証に必要な事項を入力
4.5 個別認証を実行する
4.6 認証センタから認証結果を受け取る
5.保険証応用認証
5.1 保険者が保険証の情報を認証センタのサーバに事前蓄積する
5.2 保険者が保険証の情報を認証センタのサーバに事前蓄積する
5.3 患者が窓口で保険証を提示する
5.4 病院担当者がシステムにログインする
5.5 病院担当者がシステムに資格の認証に必要な事項を入力
①認証対象年月日が、変更された保険証情報の効力発生年月日前のとき
②認証対象年月日が、変更された保険証情報の効力発生年月日後かつ開始年月日前
③認証対象年月日が、変更された保険証情報の効力発生年月日後かつ開始年月日後
④有効期限日を縮めた場合に、認証対象年月日が、有効期間内のとき
⑤有効期限日を縮めた場合に、認証対象年月日が、有効期間外のとき
6.一括認証
6.1 病院担当者が保険証資格の一括認証を実行する
個別認証応用で登録済みの保険証情報を使用する
認証対象年月日は個別認証応用で設定したように保険証情報変更の前後の日付を設定する
6.2 認証センタから認証結果を受け取る
8. 結果と評価
A) 保険者側の多様なデータ保持内容に対する柔軟性
実運用では多種多様な保険者側サーバと接続またはデータ交換を行うことが必要であり、データ交換の標準化を行ったとしてもデータ内容まで細かに規定することは難しい。認証結果として表示する各項目が保険者側のデータが一部存在しない場合を想定した確認を行った。 実施結果として、リアルタイム型保険者から受け取るデータについて一部不具合が出たが、すべての項目内容について空文字を許容するように対応したことで、保険者側のデータが存在すればそのまま表示し、存在しなければ空白表示となるようにした。
B) 保険者が保持するキー項目及びクライアントのキーボード入力内容のあいまいさに関する対応
保険者が保持するキー項目と、クライアントのキーボード入力内容(保険者番号、記号、番号、年月日)についての全角・半角の違い、空白の扱い、日付形式チェックについて以下のように対応し、あいまいさの除去を行った。
項目
認証センタで認証(文字列比較)する際の扱い
保険者番号
記号
番号
前後の空白を除去する
全角数字、記号、アルファベットを半角に変換する
対象年月日
前後の空白を除去する
年月日の妥当性をチェックする
C) 認証センタサーバでのアプリケーション処理性能
3項で示した今回の試験環境で認証センタが要求を受信してから結果を返すまでの処理時間を測定した。(単独アクセス)
測定個所
平均ターンアラウンドタイム
(クライアントの送信～受信で20回測定した平均時間)
医療機関クライアント～認証センタ(事前蓄積型)
212 msec
医療機関クライアント～認証センタ～リアルタイム型保険者
466 msec
試験環境では(今回はデスクトップ型PCをサーバとして使用しているなどのため)量的な評価はできないが、将来、サーバ専用機を用いて評価を行う機会があれば、DBの登録件数や使用回線などをより実際に近づけた上で、多重アクセス度を上げることによる性能測定が必要である。
D) 医療機関～認証センタ間のデータ交換仕様に関する考察
CDA準拠のMMLに沿ったデータ交換仕様を採用したが、保険証の認証データ交換という単一目的にしてはオーバーヘッドが大きすぎるのではないかという懸念がある。
通信容量そのものについては大きな問題ではないと考えられるが、認証センタに処理が集中した場合にオーバーヘッド分がセンタ処理上どの程度負荷に影響するのかを評価する必要がある。
この問題に関してはフェーズ2で検討予定のJ-MIX準拠のデータ交換仕様との比較で評価を行える可能性がある。
結論
結語
本システムは、構内環境での実験で十分な信頼性と処理速度が確認された。今後は、実際の医療機関、保険者を結んで、フィールドテストを行い、実用性の検討が必要とされる。
本システムは、構内環境での実験で十分な信頼性と処理速度が確認された。今後は、実際の医療機関、保険者を結んで、フィールドテストを行い、実用性の検討が必要とされる。
公開日・更新日
公開日
-
更新日
-