JP2009140057A - 診療記録管理システム、診療記録管理プログラム、診療記録管理方法 - Google Patents

診療記録管理システム、診療記録管理プログラム、診療記録管理方法 Download PDF

Info

Publication number
JP2009140057A
JP2009140057A JP2007313371A JP2007313371A JP2009140057A JP 2009140057 A JP2009140057 A JP 2009140057A JP 2007313371 A JP2007313371 A JP 2007313371A JP 2007313371 A JP2007313371 A JP 2007313371A JP 2009140057 A JP2009140057 A JP 2009140057A
Authority
JP
Japan
Prior art keywords
information
medical
electronic signature
record management
insured
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
Application number
JP2007313371A
Other languages
English (en)
Inventor
Koji Yoshioka
孝司 吉岡
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2007313371A priority Critical patent/JP2009140057A/ja
Priority to US12/328,367 priority patent/US20090144200A1/en
Publication of JP2009140057A publication Critical patent/JP2009140057A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/88—Medical equipments

Abstract

【課題】レセプトの正当性を確認することができると共に、不正行為を抑止することができる医療記録管理システム、医療記録管理方法、医療記録管理プログラムを提供する。
【解決手段】医療機関が保険の被保険者に対する診療を行った場合、該診療の結果に関する情報である第１情報を取得する第１情報取得部と、被保険者に関する情報と該情報に基づいて生成された保険の保険者の電子署名とを合わせた情報である第２情報を取得する第２情報取得部と、第１情報に基づいて被保険者の電子署名を生成し、該第１情報と該電子署名とを合わせた情報を第３情報として生成する第３情報生成部と、第２情報及び第３情報を含む第４情報に基づいて医療機関の電子署名を生成し、該第４情報と該電子署名とを合わせた情報を第５情報として生成する第５情報生成部とを備えた。
【選択図】図１

Description

本発明は、保険が適用される診療の記録の管理を行う診療記録管理システム、診療記録管理プログラム、診療記録管理方法に関するものである。
近年のＩＴ（Information Technology）システムの進展に伴い、医療業界においても大規模病院を中心に医療ＩＴシステムの導入が積極的に進められている。医療ＩＴシステムとしては主に、支払基金や保険者に提出するレセプト（診療報酬明細書）のコンピュータ処理等を行う事務管理系情報システムや、電子カルテ、オーダリング等の診療支援システム、地域・遠隔医療のためのシステム等が挙げられる。
更に、近年、病院を中心として、これら全体を統合した情報システムの導入が急速に進められている。また、政府は、２００６年１月「ＩＴ新改革戦略」の重点テーマ「ＩＴによる医療の構造改革」でレセプトの完全オンライン化（２０１１年完了目標）を掲げており、国主導による医療ＩＴ化は、今後益々急速に推進されていくことが予想される。
レセプトオンライン化とは、医療機関等から請求されるレセプトデータを電子化・コンピュータ化し、情報システム・情報通信技術を用いて支払基金及び保険者へレセプトの提出を行うものである。しかしながら、医療機関側にとって、システム投資に対する経済負担が大きく、事務効率化等のメリットが不明確であること等の理由からレセプトオンライン化の普及率は低く、現状、可搬型媒体、紙等を用いたオフラインによる提出が主流となっている。
なお、本発明の関連ある従来技術として、医師の処方と薬局の実処方との内容に違いがあれば、その時点で対処できるようにアラームを出力する医療処方管理方法がある（例えば、特許文献１参照）。また、取引者相互間で直接決済できるとともに、十分な安全性を備えた電子小口決済システムがある（例えば、特許文献２参照）。
特開２００６−１９５５２６号公報 特開平７−８５１７１号公報
現状、可搬型媒体、紙等を用いたオフラインによるレセプト提出において社会問題となっているのが、医療機関による医療費の架空請求や水増し請求等の不正行為である。これらは、医療機関が受診していない被保険者についてレセプトを作成し、支払基金及び保険者に対して医療費の不正請求を行う行為であり、現状、このような行為は、支払基金、及び保険者側の内容審査では発見することができていない。
また、この不正行為が起こる要因として、被保険者が診療を受けたとされる診療情報の存在証明、ならびに診療情報から支払基金、及び保険者に請求するために作成されるレセプトの対応関係を示すものが何もないことが挙げられる。この対応関係を証明するために、保険者は被保険者へ医療費通知を送付し、被保険者自身の受診記録を確認してもらい、見覚えのない受診記録や誤り等があれば連絡をもらうという仕組みをとっている。
しかしながら、現状、数ヶ月前の受信記録が提示されることが多い。従って、被保険者にとって、いつ、どの病院に、どんな診療を受けて、何日間通院したか、いくら支払ったか、等については時間が経過すると曖昧になるため、被保険者側からの確認は困難である。また、被保険者にとっては保険者からの通知内容に関心がない、つまり、確認しなくても損をしない、また、誤りを連絡したところで健康保険料が安くなるわけでもないため、通知内容を見てもらえる確証がない。その結果、被保険者と保険者の協力による医療費不正請求のチェックは行われていないのが現状である。
今後、国による医療ＩＴ化の進展に伴い、オンラインレセプト化の完全移行が進められるにあたって、このような医療機関等による医療費の不正請求への対策は、必要不可欠である。
本発明は上述した問題点を解決するためになされたものであり、レセプトの正当性を確認することができると共に、不正行為を抑止することができる診療記録管理システム、診療記録管理プログラム、診療記録管理方法を提供することを目的とする。
上述した課題を解決するため、本発明の一態様は、保険が適用される診療の記録の管理を行う診療記録管理システムであって、医療機関が前記保険の被保険者に対する診療を行った場合、該診療の結果に関する情報である第１情報を取得する第１情報取得部と、前記被保険者に関する情報と該情報に基づいて生成された前記保険の保険者の電子署名とを合わせた情報である第２情報を取得する第２情報取得部と、前記第１情報取得部により取得された第１情報に基づいて前記被保険者の電子署名を生成し、該第１情報と該電子署名とを合わせた情報を第３情報として生成する第３情報生成部と、前記第２情報取得部により取得された第２情報及び前記第３情報生成部により生成された第３情報を含む第４情報に基づいて前記医療機関の電子署名を生成し、該第４情報と該電子署名とを合わせた情報を第５情報として生成する第５情報生成部とを備える。
また、本発明の一態様は、保険が適用される診療の記録の管理をコンピュータに実行させる診療記録管理プログラムであって、医療機関が前記保険の被保険者に対する診療を行った場合、該診療の結果に関する情報である第１情報を取得し、前記被保険者に関する情報と該情報に基づいて生成された前記保険の保険者の電子署名とを合わせた情報である第２情報を取得し、取得された前記第１情報の前記被保険者による承認を取得した場合、該第１情報に基づいて前記被保険者の電子署名を生成し、該第１情報と該電子署名とを合わせた情報を第３情報として生成し、取得された前記第２情報及び生成された前記第３情報を含む第４情報に基づいて前記医療機関の電子署名を生成し、該第４情報と該電子署名とを合わせた情報を第５情報として生成することをコンピュータに実行させる。
また、本発明の一態様は、保険が適用される診療の記録の管理を行う診療記録管理方法であって、医療機関が前記保険の被保険者に対する診療を行った場合、該診療の結果に関する情報である第１情報を取得し、前記被保険者に関する情報と該情報に基づいて生成された前記保険の保険者の電子署名とを合わせた情報である第２情報を取得し、取得された前記第１情報の前記被保険者による承認を取得した場合、該第１情報に基づいて前記被保険者の電子署名を生成し、該第１情報と該電子署名とを合わせた情報を第３情報として生成し、取得された前記第２情報及び生成された前記第３情報を含む第４情報に基づいて前記医療機関の電子署名を生成し、該第４情報と該電子署名とを合わせた情報を第５情報として生成することを行う。
開示のシステムによれば、レセプトの正当性を確認することができると共に、不正行為を抑止することができる。
以下、本発明の実施の形態について図面を参照しつつ説明する。
まず、本実施の形態に係る診療記録管理証明システム（診療記録管理システム）の構成について説明する。
図１は、本実施の形態に係る診療記録管理証明システムの構成の一例を示すブロック図である。図１の診療記録管理証明システムは、インターネット１、電子署名情報を管理する認証機関のサーバである認証機関サーバ２を備える。周知のように電子署名は、署名対象情報を要約（メッセージダイジェスト化）した情報を送信者の秘密鍵で暗号化した署名情報、署名対象情報、及び公開鍵証明書を相手方へ送信するものである。受信者は、公開鍵証明書の有効性確認を行った上で、暗号化された署名情報を公開鍵証明書に含まれる公開鍵で復号し、署名対象情報から得た要約情報と比較を行う。この比較結果が同一か否かによって、正当な相手からの送信か否かを判断する技術である。詳細は、後述する。
このようなシステムは、証明書の正当性を保証する必要があるため、医療機関、保険者、被保険者の公開鍵を蓄積した認証機関サーバ２を備える。図２は、本実施の形態に係る認証機関サーバの構成の一例を示すブロック図である。この認証機関サーバ２は、医療機関、保険者、被保険者の公開鍵を蓄積した公開鍵ＤＢ２１、依頼に応じて公開鍵証明書を発行する証明書発行部２２、公開鍵証明書の検証を行う証明書検証部２３、及びインターネット１経由での通信を行う通信手段２４を有する。
この診療記録管理証明システムのうち、医療機関には、医療機関サーバ３が設けられる。図３は、本実施の形態に係る医療機関サーバの構成の一例を示すブロック図である。この医療機関サーバ３は、医療機関担当者が処理を行うためのサーバである。この医療機関サーバ３は、後述する保険者サーバ８へ送信された情報を蓄積する文書管理ＤＢ３１、文書管理ＤＢ３１へのアクセス制御を行う文書管理ＴＢ３２、情報に医療機関の電子署名を付加する署名生成部３３、付加された電子署名の検証を行う署名検証部３４、及びインターネット１経由での通信を行う通信手段３５を有する。
また、受付端末４は、医療機関の受付担当者が医療機関サーバ３の操作を行うための端末である。また、診療端末５は、医療機関の診療担当者（医師、看護婦等）が医療機関サーバ３の操作を行うための端末である。更に、会計端末６は医療機関の会計担当者が医療機関サーバ３の操作を行うための端末である。同様に、レセプト作成・申請端末７は医療機関のレセプト作成・申請担当者が医療機関サーバ３の操作を行うための端末である。これら受付端末４、診療端末５、会計端末６、レセプト作成・申請端末７の各端末は医療機関サーバ３と通信可能である。
この診療記録管理証明システムのうち、保険者の機関には、保険者サーバ８が設けられる。図４は、本実施の形態に係る保険者サーバの構成の一例を示すブロック図である。この保険者サーバ８は、医療機関サーバ３へ送信された情報を蓄積する文書管理ＤＢ８１、文書管理ＤＢ８１へのアクセス制御を行う文書管理ＴＢ８２、被保険者の個人情報及び証明書を格納した被保険者証の発行を行う被保険者証発行部８３、送られてきた情報に付される電子署名を検証する署名検証部８４、及びインターネット１経由で通信を行うための通信手段８５を有する。
レセプト受付端末９は、保険者の担当者が保険者サーバ８の操作を行うための端末である。保険者端末１０は、保険者の担当者が保険者サーバ８の操作を行うための端末である。
なお、本実施の形態では、保険者がＩＣ（Integrated Circuit：集積回路）チップを搭載した被保険者証ＩＣカードを被保険者に発行し、保険者サーバ８内の被保険者証発行部８３にて、個人情報、及び証明書をＩＣチップに格納することを前提に説明する。ＩＣカードとは、情報の記録や演算を行うためにＩＣチップを組み込んだカードのことである。いわゆる、スマートカード、セキュリティカードとも呼ばれ、カード内に半導体メモリを組み込むことにより、従来の磁気ストライプカードと比べて情報量が数十倍から数千倍になり、更にＣＰＵやコプロセッサ等を組み込めばカード内部で情報処理が可能になる。更には、ＩＣチップ内に記録された情報は変造や解析が難しいという特徴を持っており、セキュリティ機能も有している。銀行のキャッシュカードやクレジットカード等は、磁気記録情報を不正に読み出される行為（スキミング）への対策として、従来の磁気ストライプカードからＩＣカードへの移行が急速に進められている。更に、今後は、被保険者証や公的機関が発行する免許証等もＩＣカード化への移行が検討されている。
なお、この前提に伴い、受付端末４、診療端末５、会計端末６には、該被保険者証ＩＣカードの読み取りを行うための装置（以降、ＩＣカードリーダーと呼ぶ）が装備される。
なお、本実施の形態では、被保険者証ＩＣカード内に個人情報、及び証明書を記録・管理する形態を前提に説明しているが、該情報は保険者サーバ８内で蓄積・管理され、インターネット１を介して、必要時に医療機関側からアクセスされる形態も考えられる。
次に、電子署名の対象となる署名対象情報が送信装置から受信装置へ伝送される場合の処理である電子署名付き情報伝送処理について説明する。
送信装置は、予め、鍵ペア（秘密鍵、及び公開鍵）を生成し、認証機関サーバ２に公開鍵を送信することにより公開鍵証明書の発行を依頼する。送信装置は、この秘密鍵と公開鍵証明書を記憶しておく。送信装置より情報送信を行う際、まず、送信装置は、署名対象情報の要約情報（メッセージダイジェスト）を生成し、この要約情報を送信者の秘密鍵で暗号化したものを署名情報とする。続けて、署名対象情報、署名情報、及び送信者の公開鍵証明書を相手方へ送信し、それを受信した相手方（受信装置）は、取得した送信者の公開鍵証明書の有効性検証を認証機関サーバ２により行い、有効であれば、この公開鍵で署名情報の復号を行う。受信装置は、続けて、署名対象情報の要約を生成し、復号した情報と比較して同一であれば、真に送信者から送信されたもので改変がないことを証明できる。
ここでの要約情報とは、暗号学的一方向性Ｈａｓｈ関数を用いて署名対象情報から算出された情報（Ｈａｓｈ情報）であり、署名対象情報のサイズを圧縮できるという意味で、メッセージダイジェストとも言われる。また、暗号学的一方向性Ｈａｓｈ関数で生成されたＨａｓｈ情報は、その署名対象情報からしか生成することができない唯一の情報となり、生成されたＨａｓｈ情報から元の情報を復元することができないという特徴を持っている。このため、情報の暗号化や電子署名生成にはよく使われている。この暗号学的一方向性Ｈａｓｈ関数には、ＭＤ５、ＳＨＡ−１、ＳＨＡ−２５６のようなアルゴリズムがある。どのアルゴリズムを用いて情報から要約情報（Ｈａｓｈ情報）を生成しているかについての情報（Ｈａｓｈ情報生成アルゴリズム）は公開鍵証明書に記載されている。
次に、電子署名付き情報伝送処理の詳細について、以下に説明する。電子署名付き情報伝送処理は、送信装置による公開鍵登録処理及び送信処理、受信装置による受信処理及び検証処理からなる。
まず、送信装置と認証機関サーバ２との間での公開鍵登録処理について説明する。図５は、本実施の形態に係る公開鍵登録処理の動作の一例を示すフローチャートである。なお、本実施の形態では、医療機関サーバ３が電子署名の送信装置となっている。
まず、送信装置は、送信者の操作に従って、鍵ペア（秘密鍵、及び公開鍵）の生成を行う（Ｓ１００１）。続けて、送信者により証明書発行依頼情報が送信装置へ入力されると（Ｓ１００２）、送信装置は、その入力された証明書発行依頼情報を公開鍵とともに認証機関サーバ２へ送信する（Ｓ１００３）。
この情報を通信手段２４にて受信した認証機関サーバ２の証明書発行部２２は（Ｓ１００４）、公開鍵を含む公開鍵証明書を生成し（Ｓ１００５）、公開鍵ＤＢ２１に生成した公開鍵証明書を蓄積する（Ｓ１００６）。
その後、証明書発行部２２は、通信手段２４を制御し、インターネット１を介し、証明書発行依頼情報を送信してきた送信装置へ、発行した公開鍵証明書を送信する（Ｓ１００７）。
この情報を受信した送信装置は（Ｓ１００８）、Ｓ１００１で生成した秘密鍵、及び認証機関サーバ２から発行された公開鍵証明書を自身が有する記憶装置（医療機関サーバ３の署名生成部３３内の記憶領域）に蓄積し（Ｓ１００９）、その処理を完了する。
次に、送信装置による電子署名付き情報の送信処理、受信装置による受信処理及び検証処理について説明する。図６は、本実施の形態に係る電子署名付き情報に対する処理の動作の一例を示すフローチャートである。
まず、送信者が、送信装置へある署名対象情報に対する電子署名生成＆受信装置に対する送信指示の入力を行うと（Ｓ２００１）、送信装置は、指示された署名対象情報の要約情報（Ｈａｓｈ情報）を、記憶領域に記憶された秘密鍵により暗号化し（Ｓ２００２）、同じく記憶している公開鍵証明書とともに受信装置へ送信する（Ｓ２００３）。
これらの情報を受信した受信装置は（Ｓ２００４）、まず、送られてきた公開鍵証明書の有効期限や失効情報等を確認するため、認証機関サーバ２へ公開鍵証明書を送信する（Ｓ２００５）。ここでは、認証機関サーバ２が証明書発行・証明書検証の一連の機能をサポートしているものとする。次に認証機関サーバ２は受信した公開鍵証明書の有効性検証を行い（Ｓ２００６）、検証結果を受信装置へ送信する（Ｓ２００７）。
次に、受信装置は、この有効性検証結果を受信する（Ｓ２００８）。続けて、この有効性検証結果を受信した受信装置は、有効かどうか確認を行い（Ｓ２００９）、有効性が確認できると（Ｓ２００９，ＹＥＳ）、まず、送信装置から取得した送信者の公開鍵証明書に含まれるＨａｓｈ情報生成アルゴリズムを参照し、送信装置より受信した署名対象情報からＨａｓｈ情報を生成する（Ｓ２０１０）。続けて、受信装置は、公開鍵証明書に含まれる公開鍵を利用して、送信装置より受信した署名情報の復号処理を行う（Ｓ２０１１）。受信装置は、Ｓ２０１０で生成されたＨａｓｈ情報と、Ｓ２０１１での復号処理によって得られた情報とを比較し、同一かどうかの判断を行う（Ｓ２０１２）。この判断で同一であることを確認できると（Ｓ２０１２，ＹＥＳ）、送信装置（送信者）から送られてきた情報であり、改変がないことが証明できたとして（Ｓ２０１３）、それらの情報を保管する（Ｓ２０１４）。
逆に、有効性検証結果が有効でない場合（Ｓ２００９，ＮＯ）や生成されたＨａｓｈ情報と復号された情報とが異なる場合（Ｓ２０１２，ＮＯ）、受信装置は、その情報が送信装置（送信者）からのものと証明できなかった（あるいは通信途中で改変された等）と判断し（Ｓ２０１５）、受信装置の操作者に証明できなかった旨の表示を行う等の通知処理を行う（Ｓ２０１６）。また、受信装置は、Ｓ２００９の処理で、公開鍵証明書の有効性が確認できなかった場合も同様に、送信装置（送信者）からのものと証明できなかったと判断し（Ｓ２０１５）、受信装置の操作者に証明できなかった旨の表示を行う等の通知処理を行う（Ｓ２０１６）。
次に、本実施の形態に係る診療記録管理証明システムによる診療記録管理証明処理の動作について説明する。
図７及び図８は、本実施の形態に係る診療記録管理証明処理の動作の一例を示すフローチャートである。
最初に、保険者は、被保険者属性（被保険者に関する情報）とこの被保険者属性に対する保険者の電子署名とからなる情報（第２情報）を格納した被保険者証ＩＣカードを被保険者に発行する。被保険者属性とは、例えば、保険番号、被保険者名、性別、生年月日、助成証明書、被保険者の公開鍵証明書である。図９は、本実施の形態に係る保険者の電子署名が付加された被保険者属性の一例を示す図である。被保険者証ＩＣカードには、保険者の電子署名が付加された被保険者属性が格納される。
ここで、被保険者属性に保険者の電子署名を付加する方法は、電子署名付き情報伝送処理のうち送信装置の処理に相当し、保険者サーバ８は、送信装置に相当する。
本実施の形態においては、認証機関サーバ２と保険者が連携しており、被保険者の秘密鍵と公開鍵の鍵ペアを被保険者に作成させ、秘密鍵は被保険者の電子署名のためにＩＣチップ内に格納され、公開鍵は認証機関サーバ２により管理される。この図の被保険者属性の例の場合、被保険者の公開鍵証明書が“８ｆｄ７２１ｂａ”と表現されており、この値は、ＩＣチップ内にも格納される。また、助成証明書とは、例えば、自己負担額の１割を国や管轄する自治体が負担する等を表す証明書のことを言う。この助成証明書は、被保険者自身が国や管轄する自治体への申請により付加されるもので、被保険者証ＩＣカードは状況に応じて随時更新されていくことが想定される。
まず、被保険者は、被保険者証ＩＣカードを持参して医療機関に来院し、受付を行う。受付時、被保険者は、受付端末４に装備されているＩＣカードリーダーに保険者から発行された被保険者証ＩＣカードを挿入する（Ｓ３００１）。ここで、ＩＣカードの所有者であることを確認するための暗証番号（以下、ＰＩＮ（Personal Identification Number）コードと呼ぶ）が所有者自身によって既に設定されており、所有者が、カード挿入時、または操作時（つまり、ＩＣチップ内にアクセスする）、受付端末４の入力装置へＰＩＮコードを入力することにより、受付端末４は、挿入された被保険者証ＩＣカードが本人所有のカードであることを確認することができる。
続けて、受付端末４は、受付処理を行う（Ｓ３００２）。ここでの受付処理とは、受付端末４が、被保険者証ＩＣカードから保険者の電子署名が付加された被保険者属性を取り出し、該被保険者属性の検証を行い、保険者が発行した被保険者証ＩＣカードであることを確認する処理である。
具体的には、医療機関サーバ３内の文書管理ＴＢ３２が、取り出した被保険者属性の電子署名の検証処理を署名検証部３４に行わせる。本検証処理の場合、電子署名付きの情報がインターネット１を介して送信されてきたわけではないが、予め被保険者証ＩＣカード内に電子署名が付加されている状態でも、上記した検証処理は可能である。よって、この検証処理が成功した場合、正当な保険者からの情報であることが確認できるとともに、復号された被保険者属性を取得して利用することが可能となる。なお、この検証処理で復号できない場合、文書管理ＴＢ３２は、エラー通知を受付端末４へ通知し処理を中断する。また、受付端末４は、表示装置にエラー表示を行う等、受付担当者へ通知する処理を実行する。
受付処理が正常であった場合、続けて、受付端末４は、受付済みであることを示す情報と、被保険者証ＩＣカードから抽出した被保険者属性を診療端末５へ送信する（Ｓ３００３）。該受付処理が完了すると、被保険者は、受付担当者から受付端末４のＩＣカードリーダーに挿入されている被保険者証ＩＣカードを受け取り、診療を行う担当科へ移動する。
担当科の診療端末５は、受付端末４から受付済みであることを示す情報と、被保険者属性を受信する（Ｓ３００４）。被保険者は、診療を行う担当科の診療端末５に装備されたＩＣカードリーダーに被保険者証ＩＣカードを挿入し（Ｓ３００５）、本人確認のためのＰＩＮコードを診療端末５の入力装置を使って入力する。診療端末５は、ＰＩＮコードの入力により、本人所有の被保険者証ＩＣカードであることが確認できると、受付端末４から送られてきた被保険者属性と照合する（Ｓ３００６）。この照合で一致すれば、受付端末４にて受付を済ませた本人であることを確認できる。
被保険者は、担当科の医師による診療を受け、担当医は、該診察に対する診療情報（第１情報）を診療端末５により作成する（Ｓ３００７）。続けて、医療機関サーバ３内の文書管理ＴＢ３２を介して、該診療情報を文書管理ＤＢ３１に蓄積する（Ｓ３００８、第１情報取得部の処理）。診療情報の作成・蓄積が完了し、診療が全て完了すると、診療端末５は、診療済みであることを示す情報と、被保険者証ＩＣカードから抽出した被保険者属性を会計端末６へ送信する（Ｓ３００９）。被保険者は担当医から診療端末５のＩＣカードリーダーに挿入されている被保険者証ＩＣカードを受け取り、会計へ移動する。
会計端末６は、診療済みであることを示す情報と被保険者属性とを、診療端末５から受信する（Ｓ３０１０）。被保険者は、会計端末６に装備されたＩＣカードリーダーに被保険者証ＩＣカードを挿入し（Ｓ３０１１）、本人確認のためのＰＩＮコードを会計端末６の入力装置を使って入力する。会計端末６は、ＰＩＮコードの入力により、本人所有の被保険者証ＩＣカードであることが確認できると、診療端末５から送られてきた被保険者属性と照合する（Ｓ３０１２、第２情報取得部の処理）。この照合で一致すれば、会計端末６は、診療を受けた本人であること、診療済みであることを確認できる。確認できれば、会計端末６は、医療機関サーバ３内の文書管理ＤＢ３１に蓄積された診療情報を取り出し、被保険者が理解できる診療情報に変換し、変換した診療情報を診療内容確認画面として会計端末６の表示装置に表示する。
ここで、被保険者は、会計端末６の表示装置に示される診療情報を参照し、今回診療した内容についての確認を行う（Ｓ３０１３）。図１０は、本実施の形態に係る診療内容確認画面の一例を示す図である。診療内容確認画面には、例えば、診療日時、保険番号、氏名、疾病名、診療行為、投薬情報、保険点数、総医療費、自己負担額等が表示される。これにより、被保険者は、表示内容の確認、及び診療を受けた事実と正しいかどうかの確認を行う。
先の記述で会計端末６は診療情報を被保険者が理解できる内容に変換すると述べた。これは、担当医師が作成する診療情報の内容とは異なり、医学的な専門用語を排除し、素人である被保険者が確認可能な記述方法で表示することを意味しており、極力、変換後の診療情報は被保険者にとってわかりやすい表現になっていることが望ましい。例えば、この図の診療内容確認画面に示されるように、診療行為が、診察問診１回、レントゲン１枚等の表現になっているとわかりやすい。
また、この図の診療内容確認画面の例は、自己負担額が２割の場合を示している。通常の自己負担は３割であるが、被保険者証ＩＣカードから抽出された助成証明書（被保険者属性）が参照され、この助成証明書が自己負担額の１割を国や管轄する自治体が負担することを示すことにより、自己負担額が２割であると認識される。この例では、総医療費３，５６０円の２割負担である７１２円が、被保険者の負担額として表示されている。
このように被保険者証ＩＣカードに格納された被保険者属性を用いた、被保険者への確認がこの時点で行われる。この時点で行われることで、被保険者への事後確認が不要になる。また医療機関による架空の診療情報の作成を防止することが可能となる。表示された診療情報が正しくない（ＮＧ）の場合、被保険者は、会計担当者に何らかの不備があった旨を伝え、再確認ボタンをクリックすることでエラー処理とすることができる。一方、表示された診療情報が正しければ、ＯＫボタンをクリック（Ｓ３０１３−１）、自己負担額の７１２円を支払う。
ＯＫボタンがクリックされると、会計端末６は、続けて、表示装置に電子署名付加確認画面を表示する。図１１は、本実施の形態に係る電子署名付加確認画面の一例を示す図である。この時、被保険者は、被保険者証ＩＣカードが会計端末６に装備されたＩＣカードリーダーに挿入されていることを確認し（Ｓ３０１３−２）、続けて、ＯＫボタンをクリックする（Ｓ３０１３−３）。
ＯＫボタンがクリックされると、会計端末６は、ＰＩＮコード入力画面を表示する。図１２は、本実施の形態に係るＰＩＮコード入力画面の一例を示す図である。ここで、被保険者は、再度、会計端末６の入力装置を使って被保険者証ＩＣカードに対応するＰＩＮコードの入力を行う（Ｓ３０１３−４）。
本実施の形態において、会計端末６は、電子署名付加時に再度、ＰＩＮコードの入力を促すようにしている。被保険者は、ＰＩＮコードの入力が完了すると、ＯＫボタンをクリックする（Ｓ３０１３−５）。ＰＩＮコードの入力が完了し、ＯＫボタンがクリックされると、会計端末６は、該診療情報に被保険者自身の電子署名を付加する（Ｓ３０１４、第３情報生成部の処理）。
ここで、診療情報に被保険者の電子署名を付加する方法は、電子署名付き情報伝送処理のうち送信装置の処理に相当し、医療機関サーバ３は、送信装置に相当する。
これにより、保険者による確認が可能となる。電子署名付加用の秘密鍵は本人以外の第三者はもちろん、本人でさえ知りえない情報であることが前提となるため、先に説明したとおり、変造や解析が不可能なＩＣチップ内に格納されるのが最良の形態である。また、秘密鍵に対応する公開鍵が、保険者、もしくは保険者と連携する認証機関サーバ２で管理されることにより、電子署名の検証処理を可能にする。
被保険者証ＩＣカードは本人により物理的に保持されること、更に被保険者証ＩＣカード内の秘密鍵にアクセスするためのＰＩＮコードが入力され、本人しか知りえない暗証番号であることにより、本人以外の第三者が本人になりすまして不正に電子署名を付加することを防止することが可能となる。つまり、本実施の形態によれば、医療機関が被保険者本人になりすまして架空の診療情報を作成することが極めて困難になる。
電子署名の付加処理が完了すると、会計端末６は、電子署名付加完了画面を表示する。図１３は、本実施の形態に係る電子署名付加完了画面の一例を示す図である。電子署名付加完了画面が表示されると、被保険者は、ＩＣカードリーダーから被保険者証ＩＣカードを取り出し（Ｓ３０１４−１）、ＯＫボタンをクリックする（Ｓ３０１４−２）。ＯＫボタンがクリックされると、会計端末６は、電子署名が付加された診療情報（第３情報）を、医療機関サーバ３内の文書管理ＴＢ３２を介して文書管理ＤＢ３１に蓄積する（Ｓ３０１５）。
この時、文書管理ＤＢ３１は、Ｓ３００８で蓄積された診療情報に上書きするが、電子署名付加前後の各診療情報を保持しても良い。図１４は、本実施の形態に係る被保険者の電子署名が付加された診療情報の一例を示す図である。診療情報には、検索用タグ、チェックフラグが設けられる。この図の例においては、検索用タグとして保険番号と診療日時の２つの情報が使われ、それぞれ、誰の、いつの、診療情報かを識別可能としている。この検索用タグを用いることにより、現在処理が進められている診療情報の特定を可能にする。また、レセプト作成・申請が処理済み「済」であるか未処理「未」であるかを示すチェックフラグを設けることで、未作成である診療情報の確認に使用することができる。
電子署名が付加された診療情報の蓄積が完了すると、会計端末６は、診療情報に電子署名付加済みであることを示す情報と、被保険者証ＩＣカードから抽出した被保険者属性とを、レセプト作成・申請端末７へ送信する（Ｓ３０１６）。レセプト作成・申請端末７は、会計端末６から診療情報に電子署名付加済みであることを示す情報と、被保険者属性を受信する（Ｓ３０１７）。
レセプト作成・申請端末７は、受信した被保険者属性を基に、医療機関サーバ３内の文書管理ＴＢ３２を介して、文書管理ＤＢ３１に蓄積された被保険者の電子署名が付加された診療情報を取り出す。次に、レセプト作成・申請端末７は、取り出した診療情報がレセプト作成・申請が「未」であることを確認後、保険者へ申請するためのレセプト情報の作成を行う（Ｓ３０１８）。この確認は、先に説明したレセプト作成・審査が処理済みであるか否かを示すチェックフラグを確認することで可能となる。図１５は、本実施の形態に係るレセプト情報の一例を示す図である。レセプト情報は、診療情報と同様の内容を含む。
続けて、レセプト作成・申請端末７は、医療機関サーバ３内の文書管理ＤＢ３１から取り出された被保険者の電子署名が付加された診療情報と、会計端末６から送信された保険者の電子署名が付加された被保険者属性と、Ｓ３０１８で作成されたレセプト情報の３つの情報とを結合してマスター情報（第４情報）とし、該マスター情報に医療機関の電子署名を付加する（Ｓ３０１９、第５情報生成部の処理）。本実施の形態において、作成されるレセプト情報は、作成した医療機関の電子署名が付加されない。これは、先に説明したとおり、レセプト情報を含むマスター情報に医療機関の電子署名を付加しているためであり、冗長なデータ保持を防いでいる。なお、レセプト情報のより厳密な正当性保証を実現するために、該レセプト情報に医療機関の電子署名を付加しても良い。
ここで、マスター情報に医療機関の電子署名を付加する方法は、電子署名付き情報伝送処理のうち送信装置の処理に相当し、医療機関サーバ３は、送信装置に相当する。
医療機関の電子署名が付加されたマスター情報（第５情報）は、医療機関サーバ３内の文書管理ＴＢ３２を介して、文書管理ＤＢ３１に蓄積される（Ｓ３０２０）。レセプト作成・申請端末７は、レセプトの申請時期であるか否かを判断し（Ｓ３０２１）、申請時期であれば（Ｓ３０２１，ＹＥＳ）、レセプト作成・申請端末７の表示装置にその旨を表示する。
レセプト作成・申請担当者は、レセプト作成・申請端末７による表示を見て、保険者に対するレセプト申請処理を確定する。確定されると、医療機関サーバ３は、通信手段３５を介して、医療機関の電子署名が付加されたマスター情報を保険者サーバ８へ送信する（Ｓ３０２２）。申請時期でない場合（Ｓ３０２１，ＮＯ）、このフローは終了する。なお、レセプト申請時期に関しては、通常、１ヶ月単位で各被保険者のレセプトを作成し、翌月締め切り日（通常は１０日まで）に各保険者への申請が行われる。
保険者サーバ８は、通信手段８５を介して医療機関サーバ３から送信されたマスター情報を受信し（Ｓ３０２３）、レセプト受付端末９の表示装置に受付完了の旨を表示する。図１６は、本実施の形態に係るマスター情報の一例を示す図である。マスター情報は、上述したように、診療情報、被保険者属性、レセプト情報を含む。
レセプト作成・申請担当者が、レセプト受付端末９を用いて、受付処理を確定すると、レセプト受付端末９は、保険者サーバ８内の文書管理ＴＢ８２を介して文書管理ＤＢ８１にマスター情報を蓄積する（Ｓ３０２４）。その後、保険者サーバ８内の文書管理ＴＢ８２は、この蓄積したマスター情報の電子署名の検証処理を署名検証部８４に行わせる（Ｓ３０２５）。
ここで、署名検証部８４は、受信したマスター情報（診療情報、被保険者属性、レセプト情報の３情報）を用いた審査・検証処理（Ｓ３０２５）を行う。図１７は、本実施の形態に係る審査・検証処理の動作の一例を示すフローチャートである。具体的には、まず、医療機関の電子署名が付加されたマスター情報の検証を行う（Ｓ３０２５−１）。上記したように電子署名検証処理は、送られてきた情報が相手方、即ち医療機関から送られてきたことを検証するために、実際に電子署名検証を行う処理であり、その詳細は上述した通りである。
ここで、マスター情報に付加された医療機関の電子署名を検証する方法は、電子署名付き情報伝送処理のうち受信装置の処理に相当し、保険者サーバ８は、受信装置に相当する。
よって、この検証処理が成功した場合（Ｓ３０２５−２，ＹＥＳ）、すなわち正当な相手からの情報であることを確認できた場合、レセプト受付端末９は、復号されたマスター情報、すなわち被保険者の電子署名が付加された診療情報、保険者の電子署名が付加された被保険者属性、レセプト情報の３情報を、文書管理ＴＢ８２から取得する。一方、この処理で復号できない場合（Ｓ３０２５−２，ＮＯ）、文書管理ＴＢ８２は、エラー通知をレセプト受付端末９へ通知し処理を中断する。更に、レセプト受付端末９は、表示装置にエラー表示を行う等、レセプト受付担当者へ通知する処理を実行する（Ｓ３０２５−８）。
続けて、レセプト受付端末９は、被保険者の電子署名が付加された診療情報と、保険者の電子署名が付加された被保険者属性との２情報を利用し、それぞれに付加された電子署名の検証を行う。これも、医療機関の電子署名が付加されたマスター情報同様、各情報に付加された電子署名により、情報の作成者、及び正当性を確認する。この電子署名検証の方法は、医療機関の電子署名が付加されたマスター情報の検証と同様であり、保険者サーバ８内の文書管理ＴＢ８２は、署名検証部８４に診療情報の電子署名の検証処理（Ｓ３０２５−３）、及び被保険者属性の電子署名の検証処理を行わせる（Ｓ３０２５−５）。
ここで、診療情報に付加された被保険者の電子署名を検証する方法は、電子署名付き情報伝送処理のうち受信装置の処理に相当し、保険者サーバ８は、受信装置に相当する。同様に、被保険者属性に付加された保険者の電子署名を検証する方法は、電子署名付き情報伝送処理のうち受信装置の処理に相当し、保険者サーバ８は、受信装置に相当する。
これらの検証処理の両方が成功した場合（Ｓ３０２５−６，ＹＥＳ）、文書管理ＴＢ８２は、正当な相手からの情報であること、復号された診療情報及び被保険者属性の正当性が確認できたことをレセプト受付端末９へ通知する。一方、これらの検証処理のいずれかで復号できない場合（Ｓ３０２５−４，ＮＯ、Ｓ３０２５−６，ＮＯ）、文書管理ＴＢ８２は、エラー通知をレセプト受付端末９へ通知し処理を中断する。更に、レセプト受付端末９は、表示装置にエラー表示を行う等、レセプト受付担当者へ通知する処理を実行する（Ｓ３０２５−８）。
ここまでの処理により、診療情報の検証処理（Ｓ３０２５−３）及び被保険者属性の検証処理（Ｓ３０２５−５）が成功すると、保険者は、保険者が管理する正当な被保険者であること、つまり被保険者本人であることを確認でき、かつ、その被保険者がどの医療機関で、いつ診療を受け、診療情報の承認を行ったことを確認できる。つまり、該医療機関への来院、および診療を受けたことが証明される。
図１６のマスター情報の例においては、被保険者属性には自己負担の１割を国が負担することを示す助成証明書があるため、被保険者は（通常自己負担３割のところ）総医療費の２割を負担して７１２円を支払っていることが確認できる。
次に、レセプト受付端末９は、続けてレセプト情報の正当性確認を行う（Ｓ３０２５−７）。具体的には、被保険者が承認した診療情報をもとに、医療行為、及び投薬情報等を過剰に申告・申請していないかの確認、つまり診療情報とレセプト情報の対応が取れていることの正当性確認を行う。先に行った診療情報、及び被保険者属性の正当性に関しては、既に確認済みのため、これらについても正当性を証明することができる。
以上の審査・検証処理による効果について説明する。まず、診療情報、及び被保険者属性に付加された電子署名の検証により、被保険者の本人確認と被保険者属性の正当性が確認できる。また、診療情報に被保険者が電子署名を付加したことにより、マスター情報の正当性を確認でき、マスター情報に医療機関が電子署名を付加しているので、医療機関による不正請求でないことを確認することが可能となる。また、マスター情報に付加された電子署名の検証により、診療情報とレセプト情報の対応が取れていること、及び被保険者属性の正当性が確認できるため、保険者に対する請求額の正当性を確認することが可能となる。
図１６のマスター情報の例においては、このレセプト請求に対して保険者が医療機関（Ｆクリニック）に支払う保険費（保険者に対する請求額は７割）は、総医療費３、５６０円の７割の２、４９２円であることを確認できる。
これらの審査・検証処理が完了すると、レセプト受付端末９は、審査・検証結果を保険者端末１０へ送信する（Ｓ３０２６）。次に、保険者端末１０は、この審査・検証結果を受信する（Ｓ３０２７）。この審査・検証結果は、保険者端末１０の表示装置に表示され、保険者担当者に通知される（Ｓ３０２８）。保険者担当者は、保険者端末１０において、通知された保険費の額を医療機関に対して支払いを行う処理を確定させる（Ｓ３０２９）。
また、図１６のマスター情報の例では、助成証明書として自己負担の１割が国負担となっており、この請求のために、このマスター情報が医療機関から行政機関（国や自治体）へ送信される。この例では、行政機関がマスター情報を受信し、このマスター情報に対して行政機関が医療機関（Ｆクリニック）に支払う助成費（助成による行政機関への請求額は１割）は、３，５６０円の１割の３５６円であることを確認できる。
上述したように、本実施の形態によれば、医療業界におけるオンラインレセプト処理において、複数の組織間を電子文書が転々流通する際の、電子文書原本性保証、及び電子文書の作成者の証明を行うことが可能になる。具体的には、保険者は、被保険者がいつ（診療日時）、何を（診療情報）承認したかを、確認することができる。また、保険者は、保険者に対して請求・提示されるレセプト情報の正当性が確認できる。また、保険者は、診療情報とレセプト情報が対応していることを確認できる。従って、保険者は、従来のように被保険者への事後確認を行うことなく、保険者自身が支払う保険費の適正化を図ることが可能となり、医療機関側の不正請求（架空請求、水増し請求、２重請求等）を検出・防止し、かつ抑止効果に寄与できる。
更に、医療記録管理システムを構成するコンピュータ（例えば、医療機関サーバ）において上述した各ステップを実行させるプログラムを、医療記録管理プログラムとして提供することができる。上述したプログラムは、コンピュータにより読み取り可能な記録媒体に記憶させることによって、医療記録管理システムを構成するコンピュータに実行させることが可能となる。ここで、上記コンピュータにより読み取り可能な記録媒体としては、ＲＯＭやＲＡＭ等のコンピュータに内部実装される内部記憶装置、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。
本発明は、その精神または主要な特徴から逸脱することなく、他の様々な形で実施することができる。そのため、前述の実施の形態は、あらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明の範囲は、特許請求の範囲によって示すものであって、明細書本文には、何ら拘束されない。更に、特許請求の範囲の均等範囲に属する全ての変形、様々な改良、代替および改質は、全て本発明の範囲内のものである。
以上の実施の形態に関し、更に以下の付記を開示する。
（付記１） 保険が適用される診療の記録の管理を行う診療記録管理システムであって、
医療機関が前記保険の被保険者に対する診療を行った場合、該診療の結果に関する情報である第１情報を取得する第１情報取得部と、
前記被保険者に関する情報と該情報に基づいて生成された前記保険の保険者の電子署名とを合わせた情報である第２情報を取得する第２情報取得部と、
前記第１情報取得部により取得された第１情報に基づいて前記被保険者の電子署名を生成し、前記第１情報と該電子署名とを合わせた情報を第３情報として生成する第３情報生成部と、
前記第２情報取得部により取得された第２情報及び前記第３情報生成部により生成された第３情報を含む第４情報に基づいて前記医療機関の電子署名を生成し、該第４情報と該電子署名とを合わせた情報を第５情報として生成する第５情報生成部と、
を備える診療記録管理システム。
（付記２） 付記１に記載の診療記録管理システムにおいて、
更に、前記第５情報により生成された第５情報に含まれた前記医療機関の電子署名、前記第２情報に含まれた前記被保険者の電子署名、前記第３情報に含まれた前記保険者の電子署名を検証することができる検証部を備える診療記録管理システム。
（付記３） 付記１に記載の診療記録管理システムにおいて、
前記第３情報生成部は、前記被保険者による前記第１情報の承認を取得した場合に前記第３情報を生成する診療記録管理システム。
（付記４） 付記１に記載の診療記録管理システムにおいて、
前記第２情報を保持している可搬記憶媒体が、前記第２情報取得部による読み出しの可能な状態にされた場合、前記第２情報取得部は、前記可搬記憶媒体から前記第２情報を取得する診療記録管理システム。
（付記５） 付記１に記載の診療記録管理システムにおいて、
前記電子署名は、該電子署名の対象となる情報の要約が、該電子署名の指示者の秘密鍵により暗号化された情報である診療記録管理システム。
（付記６） 付記５に記載の診療記録管理システムにおいて、
前記被保険者に関する情報は、前記被保険者の電子署名の検証のための公開鍵の証明書を含む診療記録管理システム。
（付記７） 付記５に記載の診療記録管理システムにおいて、
前記可搬記憶媒体は更に、前記被保険者の電子署名の生成のための秘密鍵を保持する診療記録管理システム。
（付記８） 付記１に記載の診療記録管理システムにおいて、
前記第５情報生成部は、前記第２情報及び前記第３情報に基づいて前記保険者への請求額を算出して前記第４情報に含める診療記録管理システム。
（付記９） 付記１に記載の診療記録管理システムにおいて、
前記第５情報生成部は、前記第２情報及び前記第３情報に基づいて前記被保険者への請求額を算出して前記第４情報に含める診療記録管理システム。
（付記１０） 付記９に記載の診療記録管理システムにおいて、
前記被保険者に関する情報は、前記被保険者が公的な助成の対象であることを示す助成証明書を含むことができ、
前記第５情報生成部は、前記助成証明書に基づいて前記被保険者への請求額を算出する診療記録管理システム。
（付記１１） 保険が適用される診療の記録の管理をコンピュータに実行させる診療記録管理プログラムであって、
医療機関が前記保険の被保険者に対する診療を行った場合、該診療の結果に関する情報である第１情報を取得し、
前記被保険者に関する情報と該情報に基づいて生成された前記保険の保険者の電子署名とを合わせた情報である第２情報を取得し、
取得された前記第１情報の前記被保険者による承認を取得した場合、該第１情報に基づいて前記被保険者の電子署名を生成し、該第１情報と該電子署名とを合わせた情報を第３情報として生成し、
取得された前記第２情報及び生成された前記第３情報を含む第４情報に基づいて前記医療機関の電子署名を生成し、該第４情報と該電子署名とを合わせた情報を第５情報として生成する
ことをコンピュータに実行させる診療記録管理プログラム。
（付記１２） 付記１１に記載の診療記録管理プログラムにおいて、
更に、生成された前記第５情報に含まれた前記医療機関の電子署名、前記第２情報に含まれた前記被保険者の電子署名、前記第３情報に含まれた前記保険者の電子署名を検証する診療記録管理プログラム。
（付記１３） 付記１１に記載の診療記録管理プログラムにおいて、
前記被保険者による前記第１情報の承認を取得した場合に前記第３情報を生成する診療記録管理プログラム。
（付記１４） 付記１１に記載の診療記録管理プログラムにおいて、
前記第２情報を保持している可搬記憶媒体が、前記第２情報取得部による読み出しの可能な状態にされた場合、前記可搬記憶媒体から前記第２情報を取得する診療記録管理プログラム。
（付記１５） 付記１１に記載の診療記録管理プログラムにおいて、
前記電子署名は、該電子署名の対象となる情報の要約が、該電子署名の指示者の秘密鍵により暗号化された情報である診療記録管理プログラム。
（付記１６） 付記１５に記載の診療記録管理プログラムにおいて、
前記被保険者に関する情報は、前記被保険者の電子署名の検証のための公開鍵の証明書を含む診療記録管理プログラム。
（付記１７） 付記１５に記載の診療記録管理プログラムにおいて、
前記可搬記憶媒体は更に、前記被保険者の電子署名の生成のための秘密鍵を保持する診療記録管理プログラム。
（付記１８） 付記１１に記載の診療記録管理プログラムにおいて、
前記第２情報及び前記第３情報に基づいて前記保険者への請求額を算出して前記第４情報に含める診療記録管理プログラム。
（付記１９） 付記１１に記載の診療記録管理プログラムにおいて、
前記第２情報及び前記第３情報に基づいて前記被保険者への請求額を算出して前記第４情報に含める診療記録管理プログラム。
（付記２０） 保険が適用される診療の記録の管理を行う診療記録管理方法であって、
医療機関が前記保険の被保険者に対する診療を行った場合、該診療の結果に関する情報である第１情報を取得し、
前記被保険者に関する情報と該情報に基づいて生成された前記保険の保険者の電子署名とを合わせた情報である第２情報を取得し、
取得された前記第１情報の前記被保険者による承認を取得した場合、該第１情報に基づいて前記被保険者の電子署名を生成し、該第１情報と該電子署名とを合わせた情報を第３情報として生成し、
取得された前記第２情報及び生成された前記第３情報を含む第４情報に基づいて前記医療機関の電子署名を生成し、該第４情報と該電子署名とを合わせた情報を第５情報として生成する
ことを行う診療記録管理方法。
本実施の形態に係る診療記録管理証明システムの構成の一例を示すブロック図である。 本実施の形態に係る認証機関サーバの構成の一例を示すブロック図である。 本実施の形態に係る医療機関サーバの構成の一例を示すブロック図である。 本実施の形態に係る保険者サーバの構成の一例を示すブロック図である。 本実施の形態に係る公開鍵登録処理の動作の一例を示すフローチャートである。 本実施の形態に係る電子署名付き情報に対する処理の動作の一例を示すフローチャートである。 本実施の形態に係る診療記録管理証明処理の第１の動作の一例を示すフローチャートである。 本実施の形態に係る診療記録管理証明処理の第２の動作の一例を示すフローチャートである。 本実施の形態に係る保険者の電子署名が付加された被保険者属性の一例を示す図である。 本実施の形態に係る診療内容確認画面の一例を示す図である。 本実施の形態に係る電子署名付加確認画面の一例を示す図である。 本実施の形態に係るＰＩＮコード入力画面の一例を示す図である。 本実施の形態に係る電子署名付加完了画面の一例を示す図である。 本実施の形態に係る被保険者の電子署名が付加された診療情報の一例を示す図である。 本実施の形態に係るレセプト情報の一例を示す図である。 本実施の形態に係るマスター情報の一例を示す図である。 本実施の形態に係る審査・検証処理の動作の一例を示すフローチャートである。
符号の説明
１ インターネット
２ 認証機関サーバ
３ 医療機関サーバ
４ 受付端末
５ 診療端末
６ 会計端末
７ レセプト作成・申請端末
８ 保険者サーバ
９ レセプト受付端末
１０ 保険者端末
２１ 公開鍵ＤＢ
２２ 証明書発行部
２３ 証明書検証部
２４ 通信手段
３１ 文書管理ＤＢ
３２ 文書管理ＴＢ
３３ 署名生成部
３４ 署名検証部
３５ 通信手段
８１ 文書管理ＤＢ
８２ 文書管理ＴＢ
８３ 被保険者証発行部
８４ 署名検証部
８５ 通信手段

Claims (7)

  1. 保険が適用される診療の記録の管理を行う診療記録管理システムであって、
    医療機関が前記保険の被保険者に対する診療を行った場合、該診療の結果に関する情報である第１情報を取得する第１情報取得部と、
    前記被保険者に関する情報と該情報に基づいて生成された前記保険の保険者の電子署名とを合わせた情報である第２情報を取得する第２情報取得部と、
    前記第１情報取得部により取得された第１情報に基づいて前記被保険者の電子署名を生成し、該第１情報と該電子署名とを合わせた情報を第３情報として生成する第３情報生成部と、
    前記第２情報取得部により取得された第２情報及び前記第３情報生成部により生成された第３情報を含む第４情報に基づいて前記医療機関の電子署名を生成し、該第４情報と該電子署名とを合わせた情報を第５情報として生成する第５情報生成部と、
    を備える診療記録管理システム。
  2. 請求項１に記載の診療記録管理システムにおいて、
    更に、前記第５情報生成部により生成された第５情報に含まれる前記医療機関の電子署名、前記第２情報に含まれた前記被保険者の電子署名、前記第３情報に含まれた前記保険者の電子署名を検証することができる検証部を備える診療記録管理システム。
  3. 請求項１または請求項２に記載の診療記録管理システムにおいて、
    前記第３情報生成部は、前記被保険者による前記第１情報の承認を取得した場合に前記第３情報を生成する診療記録管理システム。
  4. 請求項１乃至請求項３のいずれかに記載の診療記録管理システムにおいて、
    前記第２情報を保持している可搬記憶媒体が、前記第２情報取得部による読み出しの可能な状態にされた場合、前記第２情報取得部は、前記可搬記憶媒体から前記第２情報を取得する診療記録管理システム。
  5. 請求項１乃至請求項４のいずれかに記載の診療記録管理システムにおいて、
    前記電子署名は、該電子署名の対象となる情報の要約が、該電子署名の指示者の秘密鍵により暗号化された情報である診療記録管理システム。
  6. 保険が適用される診療の記録の管理をコンピュータに実行させる診療記録管理プログラムであって、
    医療機関が前記保険の被保険者に対する診療を行った場合、該診療の結果に関する情報である第１情報を取得し、
    前記被保険者に関する情報と該情報に基づいて生成された前記保険の保険者の電子署名とを合わせた情報である第２情報を取得し、
    取得された前記第１情報の前記被保険者による承認を取得した場合、該第１情報に基づいて前記被保険者の電子署名を生成し、該第１情報と該電子署名とを合わせた情報を第３情報として生成し、
    取得された前記第２情報及び生成された前記第３情報を含む第４情報に基づいて前記医療機関の電子署名を生成し、該第４情報と該電子署名とを合わせた情報を第５情報として生成する
    ことをコンピュータに実行させる診療記録管理プログラム。
  7. 保険が適用される診療の記録の管理を行う診療記録管理方法であって、
    医療機関が前記保険の被保険者に対する診療を行った場合、該診療の結果に関する情報である第１情報を取得し、
    前記被保険者に関する情報と該情報に基づいて生成された前記保険の保険者の電子署名とを合わせた情報である第２情報を取得し、
    取得された前記第１情報の前記被保険者による承認を取得した場合、該第１情報に基づいて前記被保険者の電子署名を生成し、該第１情報と該電子署名とを合わせた情報を第３情報として生成し、
    取得された前記第２情報及び生成された前記第３情報を含む第４情報に基づいて前記医療機関の電子署名を生成し、該第４情報と該電子署名とを合わせた情報を第５情報として生成する
    ことを行う診療記録管理方法。
JP2007313371A 2007-12-04 2007-12-04 診療記録管理システム、診療記録管理プログラム、診療記録管理方法 Pending JP2009140057A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007313371A JP2009140057A (ja) 2007-12-04 2007-12-04 診療記録管理システム、診療記録管理プログラム、診療記録管理方法
US12/328,367 US20090144200A1 (en) 2007-12-04 2008-12-04 Medical care record management system, medical care record management program, and medical care record management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007313371A JP2009140057A (ja) 2007-12-04 2007-12-04 診療記録管理システム、診療記録管理プログラム、診療記録管理方法

Publications (1)

Publication Number Publication Date
JP2009140057A true JP2009140057A (ja) 2009-06-25

Family

ID=40676743

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007313371A Pending JP2009140057A (ja) 2007-12-04 2007-12-04 診療記録管理システム、診療記録管理プログラム、診療記録管理方法

Country Status (2)

Country Link
US (1) US20090144200A1 (ja)
JP (1) JP2009140057A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104917769A (zh) * 2015-06-11 2015-09-16 北京嘉和美康信息技术有限公司 一种电子病历签名方法及装置
WO2017094538A1 (ja) * 2015-12-03 2017-06-08 ソニー株式会社 Ｉｄ取得端末装置および方法、情報処理装置および方法、並びにプログラム

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8498884B2 (en) 2010-03-19 2013-07-30 Universal Healthcare Network, LLC Encrypted portable electronic medical record system
DE102011002018B4 (de) * 2011-04-13 2015-06-18 Opta Data Abrechnungs Gmbh Verfahren und Vorrichtung zur elektronischen Verwaltung von einem Leistungsnehmer von einer Verordnungsstelle individuell zugeordneter Behandlungseinheiten bei Inanspruchnahme bei einem Leistungsanbieter
CN103294915A (zh) * 2013-05-28 2013-09-11 美合实业（苏州）有限公司 一种多功能医疗信息记录装置
US10340038B2 (en) 2014-05-13 2019-07-02 Nant Holdings Ip, Llc Healthcare transaction validation via blockchain, systems and methods
US10755819B2 (en) * 2017-09-29 2020-08-25 International Business Machines Corporation Multi agent consensus resolution and re-planning

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001508883A (ja) * 1996-12-20 2001-07-03 ファイナンシャル サーヴィシーズ テクノロジー コンソーティアム 電子文書を処理する方法およびシステム
US6208973B1 (en) * 1998-02-27 2001-03-27 Onehealthbank.Com Point of service third party financial management vehicle for the healthcare industry
US7467094B2 (en) * 1999-06-23 2008-12-16 Visicu, Inc. System and method for accounting and billing patients in a hospital environment
US6877655B1 (en) * 1999-08-04 2005-04-12 Canon Kabushiki Kaisha Providing services utilizing a smart card
US7464040B2 (en) * 1999-12-18 2008-12-09 Raymond Anthony Joao Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information
US20090024416A1 (en) * 2000-03-15 2009-01-22 Mclaughlin Mark R Healthcare Medical Information Management System
WO2001071637A1 (fr) * 2000-03-24 2001-09-27 Dai Nippon Printing Co., Ltd. Appareil de traitement de documents electroniques et procede de traitement
US20020049614A1 (en) * 2000-05-23 2002-04-25 Rice Marion R. Image signatures with unique watermark ID
US6796489B2 (en) * 2000-06-06 2004-09-28 Ingeo Systems, Inc. Processing electronic documents with embedded digital signatures
AU7182701A (en) * 2000-07-06 2002-01-21 David Paul Felsher Information record infrastructure, system and method
US6826536B1 (en) * 2000-07-22 2004-11-30 Bert Forman Health care billing monitor system for detecting health care provider fraud
US20020120474A1 (en) * 2000-11-06 2002-08-29 Hele John C.R. Automated insurance policy application
KR100392331B1 (ko) * 2001-02-02 2003-07-22 서오텔레콤(주) 통신망을 이용한 의료보험 관리시스템 및 그 방법
US20030083906A1 (en) * 2001-10-29 2003-05-01 Howell Eric J. Method and apparatus for processing health insurance applications over a network
US7308583B2 (en) * 2002-01-25 2007-12-11 Matsushita Electric Industrial Co., Ltd. Data distribution system
US20040103061A1 (en) * 2002-11-25 2004-05-27 Wood Richard Glee Smart card for accelerated payment of medical insurance
US7209886B2 (en) * 2003-01-22 2007-04-24 Biometric Technologies, Inc. System and method for implementing healthcare fraud countermeasures
US20040172313A1 (en) * 2003-02-11 2004-09-02 Stein Robert Gary System and method for processing health care insurance claims
US7512807B2 (en) * 2003-02-25 2009-03-31 Activcard Ireland, Limited Method and apparatus for biometric verification with data packet transmission prioritization
US7702524B1 (en) * 2003-06-16 2010-04-20 Scheduling.Com, Inc. Method and system for online secure patient referral system
JP2005051734A (ja) * 2003-07-15 2005-02-24 Hitachi Ltd 電子文書の真正性保証方法および電子文書の公開システム
US9820658B2 (en) * 2006-06-30 2017-11-21 Bao Q. Tran Systems and methods for providing interoperability among healthcare devices
US7739127B1 (en) * 2004-09-23 2010-06-15 Stephen Don Hall Automated system for filing prescription drug claims
JP2009503672A (ja) * 2005-07-27 2009-01-29 インゲニア・テクノロジー・リミテッド スペックルパターンを使用した処方箋認証
US8560350B2 (en) * 2005-11-22 2013-10-15 Robert J. Nadai Method, system and computer program product for generating an electronic bill having optimized insurance claim items
US20090083073A1 (en) * 2007-09-26 2009-03-26 Jayesh Mehta Home Healthcare Documentation Clearing House
US8423385B2 (en) * 2008-04-14 2013-04-16 Clipboardmd, Inc. Electronic patient registration verification and payment system and method
WO2010019706A1 (en) * 2008-08-13 2010-02-18 Secure Exchange Solutions, Llc Trusted card system using secure exchange

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104917769A (zh) * 2015-06-11 2015-09-16 北京嘉和美康信息技术有限公司 一种电子病历签名方法及装置
WO2017094538A1 (ja) * 2015-12-03 2017-06-08 ソニー株式会社 Ｉｄ取得端末装置および方法、情報処理装置および方法、並びにプログラム
JPWO2017094538A1 (ja) * 2015-12-03 2018-09-20 ソニー株式会社 Ｉｄ取得端末装置および方法、情報処理装置および方法、並びにプログラム
US11038885B2 (en) 2015-12-03 2021-06-15 Sony Corporation ID acquisition terminal apparatus and method and information processing apparatus and method

Also Published As

Publication number Publication date
US20090144200A1 (en) 2009-06-04

Similar Documents

Publication Publication Date Title
US11170376B2 (en) Informational and analytical system and method for ensuring the level of trust, control and secure interaction of counterparties when using electronic currencies and contracts
US6609200B2 (en) Method and system for processing electronic documents
US8904181B1 (en) System and method for secure three-party communications
KR100869091B1 (ko) 개인 정보 증명 프로그램을 기록한 컴퓨터로 판독가능한기록 매체, 방법 및 장치
US20060136332A1 (en) System and method for electronic check verification over a network
US20110270760A1 (en) Methods and apparatus for a financial document clearinghouse and secure delivery network
WO2002052480A1 (en) Dynamic electronic chain-of-trust document with audit trail
JP2005502927A (ja) 認証済みの電子オリジナル・ドキュメントの電子的伝送、格納、および取り出しのためのシステムおよび方法
JP2009140057A (ja) 診療記録管理システム、診療記録管理プログラム、診療記録管理方法
CN109658273B (zh) 基于区块链的商业保险快速理赔方法、存储介质和设备
US11468442B1 (en) Payment card reconciliation by authorization code
WO2013057874A1 (ja) 電子レシートシステム、端末装置、電子レシートの提供方法およびプログラム
US10719581B2 (en) System and method for securing the remuneration of patient responsibilities for healthcare services in a revenue management cycle
Ismail Electronic land administration system in Malaysia: The need for new enabling provisions
JP2007048146A (ja) 保険証認証システム
WO2020242550A1 (en) Ensuring trust levels when using electronic currencies
TW201019248A (en) IP insurance-adjusting risk assessment management system and method
CN115099800A (zh) 基于区块链的用于对不良资产数据进行转让的方法及装置
Reed Legally binding electronic documents: digital signatures and authentication
KR102144702B1 (ko) 메신저 인증 기반의 진료비 허위·부당 청구 예방 시스템 및 방법
Liu et al. Integrating SET and EDI for secure healthcare commerce
Smedinghoff the Legal Challenges of Implementing electronic transactions
CA3175232A1 (en) A system and method using a web3.0 digital self-sovereign-identity wallet, digital identity tokens, blockchain, and identity based authentication to deliver assets, more specifically electronic signatures and electronic prescriptions bound with validated digital identity credentials
KR20070078269A (ko) 전자지불보증에 의한 의료비 정산 및 전자청구문서 전송방법
JP2024003533A (ja) 取引取消プログラム、取引取消システム、及び取引取消方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090319

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090714

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20091201