JP6561761B2 - 医療情報管理システム及び管理サーバー - Google Patents
医療情報管理システム及び管理サーバー Download PDFInfo
- Publication number
- JP6561761B2 JP6561761B2 JP2015206842A JP2015206842A JP6561761B2 JP 6561761 B2 JP6561761 B2 JP 6561761B2 JP 2015206842 A JP2015206842 A JP 2015206842A JP 2015206842 A JP2015206842 A JP 2015206842A JP 6561761 B2 JP6561761 B2 JP 6561761B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- key
- data
- medical
- user
- 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.)
- Active
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/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- 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/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
-
- 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
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16Z—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS, NOT OTHERWISE PROVIDED FOR
- G16Z99/00—Subject matter not provided for in other main groups of this subclass
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Description
本発明は、医療情報管理システム及び管理サーバーに関する。
近年、医療技術の多様化に伴い、特定機能を持つ病院や診療所等の複数の医療施設が医療情報を共有し、連携して患者の検査や治療を行う医療連携が普及しつつある。例えば、通信ネットワークを介して接続されたサーバーに、連携先からしか参照できない医療情報をアップロードし、必要な時に医療情報をダウンロードするシステムが利用されている。
また、複数の医療施設が保有する診療データを蓄積するためのデータ共有ＤＢを備えた診療データ共有サーバーにおいて、各医療施設からアップロードされた診療データと同一患者の過去の診療データが既に登録済みか否かを判定し、既に登録済みの場合には、診療データを患者毎に割り当てた管理ＩＤに関連付けて登録し、未登録の場合には、診療データを新規の管理ＩＤに関連付けて登録する技術が提案されている（特許文献１参照）。
上記のような従来のシステムは、複数の医療施設間で医療情報を共有することで業務の効率化を図るものであるが、一方で、共有される医療情報が漏洩しないように、参照又は外部に出力できる情報を制限したい、という要望があった。
例えば、医療情報を特定の連携グループ間で共有する場合は、個人情報が必要になる場合もあるが、個人情報が必要ない医療情報を共有する場合は、医療情報を匿名化した状態で提供することが望まれる。
また、モバイル端末等のクライアント端末から医療情報を参照した場合、クライアント端末にダウンロードされた医療情報が残っていると、端末を紛失したり、保存されている医療情報がコピーされたりして、情報が漏洩する恐れがある。
また、特定のクライアント端末に対してのみ医療情報の参照・出力を許可したり、参照は許可するが出力は許可しないように制御したりする等、端末毎に制限を設けることができると、データの安全性が向上する。
また、モバイル端末等のクライアント端末から医療情報を参照した場合、クライアント端末にダウンロードされた医療情報が残っていると、端末を紛失したり、保存されている医療情報がコピーされたりして、情報が漏洩する恐れがある。
また、特定のクライアント端末に対してのみ医療情報の参照・出力を許可したり、参照は許可するが出力は許可しないように制御したりする等、端末毎に制限を設けることができると、データの安全性が向上する。
本発明は、上記の従来技術における問題に鑑みてなされたものであって、医療情報を共有可能なシステムにおいて、医療情報の漏洩を防止するとともに、医療情報の参照・出力を制限することを課題とする。
上記課題を解決するために、請求項１に記載の発明は、複数の医療施設において生成された医療情報を管理する管理サーバーと、前記複数の医療施設に設置された複数のクライアント端末と、がデータ通信可能に接続された医療情報管理システムであって、前記管理サーバーは、前記医療情報毎に、公開先を含む認可情報を記憶する第１記憶手段と、前記公開先の候補となる前記医療情報を共有する連携先毎に、連携先鍵を記憶する第２記憶手段と、前記複数のクライアント端末のいずれかから前記医療情報のダウンロード要求があった場合に、当該医療情報がダウンロードされる度にコンテンツ鍵を生成し、当該医療情報を当該生成されたコンテンツ鍵を用いて暗号化して第１情報を生成する第１生成手段と、前記コンテンツ鍵及び当該コンテンツ鍵により暗号化された医療情報に対応する認可情報を、当該認可情報に含まれる公開先に対応する連携先鍵を用いて暗号化して第２情報を生成する第２生成手段と、前記ダウンロード要求があったクライアント端末に前記第１情報及び前記第２情報を提供する提供手段と、を備え、前記複数のクライアント端末のそれぞれは、前記連携先鍵を取得する第１取得手段と、前記管理サーバーから取得された前記第２情報を、前記第１取得手段により取得された連携先鍵を用いて復号して前記コンテンツ鍵及び前記認可情報を取得する第２取得手段と、前記第２取得手段により取得された認可情報に応じた権限の範囲内で、前記管理サーバーから取得された前記第１情報を、前記第２取得手段により取得されたコンテンツ鍵を用いて復号して前記医療情報を取得する第３取得手段と、を備える。
請求項２に記載の発明は、請求項１に記載の医療情報管理システムにおいて、前記連携先鍵は、ユーザー毎に用意されたユーザー鍵、前記クライアント端末毎に用意された端末鍵、又は、前記医療情報に係る患者毎に用意された患者鍵である。
請求項３に記載の発明は、請求項１又は２に記載の医療情報管理システムにおいて、前記認可情報には、さらに、前記医療情報の有効期間又は認可種別が含まれる。
請求項４に記載の発明は、請求項１から３のいずれか一項に記載の医療情報管理システムにおいて、前記複数のクライアント端末のそれぞれは、前記第２取得手段により取得された認可情報において暗号化出力が認可されている場合に、前記管理サーバーから取得された前記第１情報及び前記第２情報を記録メディアに書き込む書込手段を備える。
請求項５に記載の発明は、複数の医療施設に設置された複数のクライアント端末とデータ通信可能に接続され、前記複数の医療施設において生成された医療情報を管理する管理サーバーであって、前記医療情報毎に、公開先を含む認可情報を記憶する第１記憶手段と、前記公開先の候補となる前記医療情報を共有する連携先毎に、連携先鍵を記憶する第２記憶手段と、前記複数のクライアント端末のいずれかから前記医療情報のダウンロード要求があった場合に、当該医療情報がダウンロードされる度にコンテンツ鍵を生成し、当該医療情報を当該生成されたコンテンツ鍵を用いて暗号化して第１情報を生成する第１生成手段と、前記コンテンツ鍵及び当該コンテンツ鍵により暗号化された医療情報に対応する認可情報を、当該認可情報に含まれる公開先に対応する連携先鍵を用いて暗号化して第２情報を生成する第２生成手段と、前記ダウンロード要求があったクライアント端末に前記第１情報及び前記第２情報を提供する提供手段と、を備える。
本発明によれば、医療情報の漏洩を防止するとともに、医療情報の参照・出力を制限することができる。
［第１の実施の形態］
まず、図を参照して本発明に係る医療情報管理システムの第１の実施の形態について説明する。なお、本発明は、図示例に限定されるものではない。
まず、図を参照して本発明に係る医療情報管理システムの第１の実施の形態について説明する。なお、本発明は、図示例に限定されるものではない。
図１に、第１の実施の形態における医療情報管理システム１００のシステム構成を示す。
図１に示すように、医療情報管理システム１００は、データセンターに設置された管理サーバー１０と、連携先医療施設に設置されたクライアント端末２０と、第三者認証局３０と、を備えて構成されている。管理サーバー１０、クライアント端末２０、第三者認証局３０は、インターネット等の通信ネットワークＮを介してデータ通信可能に接続されている。
なお、医療情報管理システム１００を構成する連携先医療施設の数や、各連携先医療施設内のクライアント端末２０の数は、特に限定されない。
図１に示すように、医療情報管理システム１００は、データセンターに設置された管理サーバー１０と、連携先医療施設に設置されたクライアント端末２０と、第三者認証局３０と、を備えて構成されている。管理サーバー１０、クライアント端末２０、第三者認証局３０は、インターネット等の通信ネットワークＮを介してデータ通信可能に接続されている。
なお、医療情報管理システム１００を構成する連携先医療施設の数や、各連携先医療施設内のクライアント端末２０の数は、特に限定されない。
管理サーバー１０は、複数の連携先医療施設において生成された医療情報を蓄積し、管理する。また、管理サーバー１０は、医療施設間の医療連携サービスを提供するものであり、各医療施設からの要求に応じて、他の医療施設において実施された検査の結果や撮影画像の画像データ等を提供する。
医療情報は、各患者の診療の過程で生成される情報である。医療情報として、例えば、医用画像データ、検体検査データ、電子カルテデータ、読影レポート、病理診断レポート等が挙げられる。また、医療情報は、患者を撮影して得られた医用画像にＤＩＣＯＭ（Digital Imaging and Communications in Medicine）規格に則って患者情報や検査情報等の付帯情報を付帯させた画像データの他、ＰＤＦ、ＰＮＧ、Ｅｘｃｅｌ、Ｗｏｒｄ等、様々なデータ形式を取り得る。
管理サーバー１０は、端末情報テーブルＴ１、利用者情報テーブルＴ２、連携情報テーブルＴ３、認可情報テーブルＴ４、暗号化履歴テーブルＴ５を備える。
クライアント端末２０は、医療施設が他の医療施設と医療の連携を行うために用いるコンピューターである。クライアント端末２０は、通信ネットワークＮを介して管理サーバー１０にアクセスし、管理サーバー１０へ医療情報をアップロードしたり、管理サーバー１０に格納されている医療情報をダウンロードしたりする際に用いられる。
クライアント端末２０は、ＬＡＮ（Local Area Network）等の施設内ネットワークにより、医療施設内に設置されたＰＡＣＳ（Picture Archiving and Communication System）とデータ通信可能に接続されており、ＰＡＣＳから医療情報を取り込む。ＰＡＣＳは、医療施設内のモダリティーにより生成された医用画像の画像データ等の医療情報を患者情報や検査情報と対応付けて記憶する施設内サーバーである。モダリティーとして、例えば、ＣＲ（Computed Radiography）、ＦＰＤ（Flat Panel Detector）、ＣＴ（Computed Tomography）、ＭＲＩ（Magnetic Resonance Imaging）等が用いられる。
クライアント端末２０は、ユーザー証明書Ｖ１が記憶されているＩＣカード（Integrated Circuit Card）Ｃ１から情報を取得する。
クライアント端末２０は、端末証明書Ｖ２、連携データ情報Ｖ３、鍵情報Ｖ４等の情報を記憶する。
クライアント端末２０は、出力対象の医療情報を記録メディア（以下、単にメディアという。）Ｍ１に書き込む。
クライアント端末２０は、端末証明書Ｖ２、連携データ情報Ｖ３、鍵情報Ｖ４等の情報を記憶する。
クライアント端末２０は、出力対象の医療情報を記録メディア（以下、単にメディアという。）Ｍ１に書き込む。
第三者認証局３０は、クライアント端末２０からの依頼に応じて端末鍵を生成する。また、第三者認証局３０は、管理サーバー１０からの依頼に応じて端末鍵の検証を行う。
図２に、管理サーバー１０の機能的構成を示す。
図２に示すように、管理サーバー１０は、制御部１１、ＲＡＭ（Random Access Memory）１２、通信部１３、記憶部１４等を備えて構成されており、各部はバス１５により接続されている。
図２に示すように、管理サーバー１０は、制御部１１、ＲＡＭ（Random Access Memory）１２、通信部１３、記憶部１４等を備えて構成されており、各部はバス１５により接続されている。
制御部１１は、ＣＰＵ（Central Processing Unit）等により構成され、管理サーバー１０の各部の処理動作を統括的に制御する。制御部１１は、記憶部１４に記憶されている各種プログラムを読み出してＲＡＭ１２に展開し、当該プログラムとの協働により各種処理を実行する。
ＲＡＭ１２は、制御部１１により実行制御される各種処理において、記憶部１４から読み出された各種プログラム、入力若しくは出力データ及びパラメーター等を一時的に記憶するワークエリアを形成する。
通信部１３は、ネットワークインターフェース等により構成され、通信ネットワークＮを介して接続された外部機器との間でデータの送受信を行う。例えば、通信部１３は、クライアント端末２０から送信された医療情報を受信する。また、通信部１３は、医療情報のダウンロード要求があったクライアント端末２０に医療情報を送信する。
記憶部１４は、ＨＤＤ（Hard Disk Drive）や半導体の不揮発性メモリー等により構成される。記憶部１４は、制御部１１により実行される各種プログラムを記憶しているほか、各種プログラムを実行するために必要なパラメーターやデータを記憶している。具体的に、記憶部１４には、サーバープログラムＰ１、アプリケーションプログラムＰ２、端末情報テーブルＴ１、利用者情報テーブルＴ２、連携情報テーブルＴ３、認可情報テーブルＴ４、暗号化履歴テーブルＴ５が記憶されている。
サーバープログラムＰ１は、管理サーバー１０におけるデータ管理処理、連携先医療施設への医療情報の提供処理等を実行するためのプログラムである。
アプリケーションプログラムＰ２は、クライアント端末２０によりダウンロードされ、クライアント端末２０において使用されるプログラムである。
アプリケーションプログラムＰ２は、クライアント端末２０によりダウンロードされ、クライアント端末２０において使用されるプログラムである。
端末情報テーブルＴ１には、管理サーバー１０にアクセス可能なクライアント端末２０毎の情報が格納される。端末情報テーブルＴ１には、「端末ＩＤ」に対して、「鍵有効期間」、「端末鍵」が対応付けられている（第２記憶手段）。各クライアント端末２０は、医療情報を共有する連携先として設定可能であり、医療情報の公開先の候補となる。
「端末ＩＤ」は、クライアント端末２０を識別するための識別情報である。
「鍵有効期間」は、「端末ＩＤ」により特定されるクライアント端末２０に対して生成された「端末鍵」の有効期間である。
「端末鍵」は、「端末ＩＤ」により特定されるクライアント端末２０に対して用意された、各クライアント端末２０に固有の鍵である。「端末鍵」は、例えば、第三者認証局３０によって生成される。
「端末ＩＤ」は、クライアント端末２０を識別するための識別情報である。
「鍵有効期間」は、「端末ＩＤ」により特定されるクライアント端末２０に対して生成された「端末鍵」の有効期間である。
「端末鍵」は、「端末ＩＤ」により特定されるクライアント端末２０に対して用意された、各クライアント端末２０に固有の鍵である。「端末鍵」は、例えば、第三者認証局３０によって生成される。
利用者情報テーブルＴ２には、医療情報管理システム１００の利用者毎の情報が格納される。利用者情報テーブルＴ２には、「ユーザーＩＤ」に対して、「利用者情報」、「ユーザー有効期間」、「パスワード」、「ユーザー鍵」が対応付けられている（第２記憶手段）。各利用者（ユーザー）は、医療情報を共有する連携先として設定可能であり、医療情報の公開先の候補となる。
「ユーザーＩＤ」は、ユーザーを識別するための識別情報である。
「利用者情報」は、利用者（ユーザー）に関する情報であり、ユーザーが所属する組織名、権限等を含む。
「ユーザー有効期間」は、「ユーザーＩＤ」により特定されるユーザーが医療情報管理システム１００の利用を許可された期間である。
「パスワード」は、医療情報管理システム１００の利用時に、ユーザー認証の際に入力を求められるパスワードである。
「ユーザー鍵」は、「ユーザーＩＤ」により特定されるユーザーに対して用意された、各ユーザーに固有の鍵である。
「ユーザーＩＤ」は、ユーザーを識別するための識別情報である。
「利用者情報」は、利用者（ユーザー）に関する情報であり、ユーザーが所属する組織名、権限等を含む。
「ユーザー有効期間」は、「ユーザーＩＤ」により特定されるユーザーが医療情報管理システム１００の利用を許可された期間である。
「パスワード」は、医療情報管理システム１００の利用時に、ユーザー認証の際に入力を求められるパスワードである。
「ユーザー鍵」は、「ユーザーＩＤ」により特定されるユーザーに対して用意された、各ユーザーに固有の鍵である。
連携情報テーブルＴ３には、クライアント端末２０から医療情報が送信される送信単位毎（連携毎）の情報が格納される。連携情報テーブルＴ３には、「連携ＩＤ」に対して、「送信元ユーザーＩＤ」が対応付けられている。
「連携ＩＤ」は、クライアント端末２０から管理サーバー１０に対して送信される医療情報の送信単位毎（連携毎）に付与される識別情報である。
「送信元ユーザーＩＤ」は、医療情報の送信元のユーザーを示すユーザーＩＤである。
「連携ＩＤ」は、クライアント端末２０から管理サーバー１０に対して送信される医療情報の送信単位毎（連携毎）に付与される識別情報である。
「送信元ユーザーＩＤ」は、医療情報の送信元のユーザーを示すユーザーＩＤである。
認可情報テーブルＴ４には、連携データ毎の認可情報が格納される（第１記憶手段）。認可情報テーブルＴ４には、「連携データＩＤ」に対して、「連携ＩＤ」、「認可情報」が対応付けられている。連携データは、医療情報管理システム１００において医療情報を共有する際に１単位として扱われる一纏まりの情報であり、一又は複数のファイルから構成される。
「連携データＩＤ」は、一つのコンテンツ鍵で暗号化される医療情報の単位（連携データ）毎に付与される識別情報である。
「認可情報」は、医療情報（連携データ）毎に設定された、当該医療情報に対する権限を示す情報である。「認可情報」には、処理を許可されたユーザーやクライアント端末２０等の公開先、医療情報の有効期間等が含まれる。
「連携データＩＤ」は、一つのコンテンツ鍵で暗号化される医療情報の単位（連携データ）毎に付与される識別情報である。
「認可情報」は、医療情報（連携データ）毎に設定された、当該医療情報に対する権限を示す情報である。「認可情報」には、処理を許可されたユーザーやクライアント端末２０等の公開先、医療情報の有効期間等が含まれる。
図３に、認可情報の例を示す。
認可情報は、連携データＩＤ毎に、各認可種別に対して、有効期間、ユーザーＩＤ、端末ＩＤ、匿名化要否が対応付けられている。図３に示す患者鍵使用可否については、第１の実施の形態では使用しないので、第２の実施の形態において説明する。
認可情報は、連携データＩＤ毎に、各認可種別に対して、有効期間、ユーザーＩＤ、端末ＩＤ、匿名化要否が対応付けられている。図３に示す患者鍵使用可否については、第１の実施の形態では使用しないので、第２の実施の形態において説明する。
認可種別は、連携データに対して行われる処理を分類したものである。ここでは、認可種別として、画像参照、患者参照、外部出力、暗号化出力を用いる。画像参照は、連携データの画像部分の参照（表示）である。患者参照は、連携データの患者情報部分の参照（表示）である。外部出力は、連携データのメディアＭ１への出力（書き込み）である。暗号化出力は、暗号化された連携データのメディアＭ１への出力（書き込み）である。
有効期間は、参照・出力が許可されている期間である。
認可情報に含まれるユーザーＩＤは、参照・出力が許可されているユーザーに対応するユーザーＩＤである。
認可情報に含まれる端末ＩＤは、参照・出力が許可されているクライアント端末２０に対応する端末ＩＤである。
匿名化要否は、連携データ内の患者情報等の個人情報の匿名化が必要であるか否かを示す情報である。
認可情報に含まれるユーザーＩＤは、参照・出力が許可されているユーザーに対応するユーザーＩＤである。
認可情報に含まれる端末ＩＤは、参照・出力が許可されているクライアント端末２０に対応する端末ＩＤである。
匿名化要否は、連携データ内の患者情報等の個人情報の匿名化が必要であるか否かを示す情報である。
図３に示す例では、連携データＩＤ「Ｄ００１」の連携データの「画像参照」は、ユーザーＩＤ「Ｕ００１」、「Ｕ００２」、「Ｕ００３」のユーザーによって可能である。また連携データＩＤ「Ｄ００１」の連携データの「画像参照」については、有効期間、端末ＩＤは指定されていないため、いつでも、どのクライアント端末２０からでも画像を参照することができる。
また、連携データＩＤ「Ｄ００１」の連携データの「患者参照」は、「２０１５／５／１〜２０１５／５／１５」の間、ユーザーＩＤ「Ｕ００１」、「Ｕ００２」のユーザーによって可能である。
また、連携データＩＤ「Ｄ００１」の連携データの「外部出力」は、「２０１５／５／１〜２０１５／５／５」の間、ユーザーＩＤ「Ｕ００１」のユーザーによって、端末ＩＤ「Ｔ００１」のクライアント端末２０からのみ可能である。
また、連携データＩＤ「Ｄ００１」の連携データの「暗号化出力」は、「２０１５／５／１〜２０１５／５／１５」の間、ユーザーＩＤ「Ｕ００１」のユーザーによって、端末ＩＤ「Ｔ００１」のクライアント端末２０からのみ可能である。
また、連携データＩＤ「Ｄ００２」の連携データの「画像参照」については、「２０１５／５／１〜２０１５／５／１５」の間であれば、誰でも、どのクライアント端末２０からでも参照可能となっている。
また、連携データＩＤ「Ｄ００１」の連携データの「患者参照」は、「２０１５／５／１〜２０１５／５／１５」の間、ユーザーＩＤ「Ｕ００１」、「Ｕ００２」のユーザーによって可能である。
また、連携データＩＤ「Ｄ００１」の連携データの「外部出力」は、「２０１５／５／１〜２０１５／５／５」の間、ユーザーＩＤ「Ｕ００１」のユーザーによって、端末ＩＤ「Ｔ００１」のクライアント端末２０からのみ可能である。
また、連携データＩＤ「Ｄ００１」の連携データの「暗号化出力」は、「２０１５／５／１〜２０１５／５／１５」の間、ユーザーＩＤ「Ｕ００１」のユーザーによって、端末ＩＤ「Ｔ００１」のクライアント端末２０からのみ可能である。
また、連携データＩＤ「Ｄ００２」の連携データの「画像参照」については、「２０１５／５／１〜２０１５／５／１５」の間であれば、誰でも、どのクライアント端末２０からでも参照可能となっている。
暗号化履歴テーブルＴ５には、ダウンロード毎の情報が格納される。暗号化履歴テーブルＴ５には、「ダウンロードコンテンツＩＤ」に対して、「連携データＩＤ」、「コンテンツ鍵」、「有効期間」が対応付けられている。
「ダウンロードコンテンツＩＤ」は、医療情報（連携データ）がダウンロードされる度に付与される識別情報である。
「連携データＩＤ」は、ダウンロードの対象となる連携データに対応する連携データＩＤである。
「コンテンツ鍵」は、ダウンロード毎に生成される鍵である。
「有効期間」は、「コンテンツ鍵」の有効期間である。
「ダウンロードコンテンツＩＤ」は、医療情報（連携データ）がダウンロードされる度に付与される識別情報である。
「連携データＩＤ」は、ダウンロードの対象となる連携データに対応する連携データＩＤである。
「コンテンツ鍵」は、ダウンロード毎に生成される鍵である。
「有効期間」は、「コンテンツ鍵」の有効期間である。
制御部１１は、記憶部１４に記憶されているサーバープログラムＰ１に従って、クライアント端末２０から送信された医療情報を管理し、クライアント端末２０からの要求に応じて医療情報を提供する。
制御部１１は、複数のクライアント端末２０のいずれかから医療情報（連携データ）のダウンロード要求があった場合に、当該医療情報がダウンロードされる度にコンテンツ鍵を生成し、当該医療情報を当該生成されたコンテンツ鍵を用いて暗号化して第１情報としての暗号化連携データを生成する。すなわち、制御部１１は、第１生成手段として機能する。
図４（ａ）は、連携データの暗号化を示すイメージ図である。連携データをコンテンツ鍵を用いて暗号化して、暗号化連携データが得られる。
制御部１１は、コンテンツ鍵により暗号化された医療情報（連携データ）に対応する認可情報を、記憶部１４に記憶されている認可情報テーブルＴ４から取得する。
また、制御部１１は、取得した認可情報に含まれる公開先（端末ＩＤ・ユーザーＩＤ）に対応する連携先鍵（端末鍵・ユーザー鍵）を、記憶部１４に記憶されている端末情報テーブルＴ１、利用者情報テーブルＴ２から取得する。
制御部１１は、コンテンツ鍵及びコンテンツ鍵により暗号化された医療情報（連携データ）に対応する認可情報を、当該認可情報に含まれる公開先に対応する連携先鍵を用いて暗号化して第２情報としての暗号データを生成する。すなわち、制御部１１は、第２生成手段として機能する。
また、制御部１１は、取得した認可情報に含まれる公開先（端末ＩＤ・ユーザーＩＤ）に対応する連携先鍵（端末鍵・ユーザー鍵）を、記憶部１４に記憶されている端末情報テーブルＴ１、利用者情報テーブルＴ２から取得する。
制御部１１は、コンテンツ鍵及びコンテンツ鍵により暗号化された医療情報（連携データ）に対応する認可情報を、当該認可情報に含まれる公開先に対応する連携先鍵を用いて暗号化して第２情報としての暗号データを生成する。すなわち、制御部１１は、第２生成手段として機能する。
図４（ｂ）は、コンテンツ鍵及び認可情報の暗号化を示すイメージ図である。ここでは、対象となる連携データに対して、端末ＩＤ「Ｔ００１」のクライアント端末２０から、ユーザーＩＤ「Ｕ００１」、「Ｕ００２」のユーザーによる処理が許可されていることとする。まず、コンテンツ鍵及び認可情報を端末ＩＤ「Ｔ００１」に対応する端末鍵で暗号化して、暗号データ１を生成する。次に、暗号データ１をユーザーＩＤ「Ｕ００１」に対応するユーザー鍵で暗号化して、暗号データ２を生成するとともに、暗号データ１をユーザーＩＤ「Ｕ００２」に対応するユーザー鍵で暗号化して、暗号データ３を生成する。コンテンツ鍵及び認可情報は、各処理工程において、連携データＩＤと対応付けられて管理される。
制御部１１は、通信部１３を介して、ダウンロード要求があったクライアント端末２０に暗号化連携データ及び暗号データを提供する。すなわち、制御部１１は、提供手段として機能する。管理サーバー１０では、連携データがダウンロードされる度に、暗号化履歴テーブルＴ５にコンテンツ鍵を保存するため、暗号化連携データについては、管理サーバー１０内に保存する必要はない。
図５に、クライアント端末２０の機能的構成を示す。
図５に示すように、クライアント端末２０は、制御部２１、ＲＡＭ２２、通信部２３、操作部２４、表示部２５、ＩＣカードリーダー・ライター２６、データ書込部２７、記憶部２８等を備えて構成され、各部はバス２９等により接続されている。
図５に示すように、クライアント端末２０は、制御部２１、ＲＡＭ２２、通信部２３、操作部２４、表示部２５、ＩＣカードリーダー・ライター２６、データ書込部２７、記憶部２８等を備えて構成され、各部はバス２９等により接続されている。
制御部２１は、ＣＰＵ等により構成され、クライアント端末２０の各部の処理動作を統括的に制御する。制御部２１は、記憶部２８に記憶されている各種プログラムを読み出してＲＡＭ２２に展開し、当該プログラムとの協働により各種処理を実行する。
ＲＡＭ２２は、制御部２１により実行制御される各種処理において、記憶部２８から読み出された各種プログラム、入力若しくは出力データ及びパラメーター等を一時的に記憶するワークエリアを形成する。
通信部２３は、ネットワークインターフェース等により構成され、通信ネットワークＮや施設内ネットワークを介して接続された外部機器との間でデータの送受信を行う。例えば、通信部２３は、管理サーバー１０に医療情報を送信し、管理サーバー１０から医療情報を受信する。
操作部２４は、カーソルキー、数字入力キー及び各種機能キー等を備えたキーボードと、マウス等のポインティングデバイスを備えて構成され、キーボードに対するキー操作やマウス操作により入力された操作信号を制御部２１に出力する。例えば、操作部２４は、クライアント端末２０を操作するユーザーが管理サーバー１０にアップロードする医療情報を指定する際や、管理サーバー１０からダウンロードする医療情報を指定する際に用いられる。
表示部２５は、ＬＣＤ（Liquid Crystal Display）等のモニターを備えて構成されており、制御部２１から入力される表示信号の指示に従って、各種画面を表示する。
ＩＣカードリーダー・ライター２６は、ＩＣカードＣ１から各種データを読み取り、読み取ったデータを制御部２１に出力する。
ＩＣカードＣ１は、各ユーザーが所持するカードであり、各ユーザーに対応するユーザー証明書Ｖ１が記憶されている。ユーザー証明書Ｖ１は、「ユーザーＩＤ」、「利用者情報」、「ユーザー鍵」を含む。
ＩＣカードＣ１は、各ユーザーが所持するカードであり、各ユーザーに対応するユーザー証明書Ｖ１が記憶されている。ユーザー証明書Ｖ１は、「ユーザーＩＤ」、「利用者情報」、「ユーザー鍵」を含む。
データ書込部２７は、制御部２１からの制御信号に基づき、ＣＤ−Ｒ、ＤＶＤ−Ｒ等のメディアＭ１に各種データを書き込む書込手段である。
記憶部２８は、ＨＤＤや半導体の不揮発性メモリー等により構成される。記憶部２８は、制御部２１により実行される各種プログラムを記憶しているほか、各種プログラムを実行するために必要なパラメーターやデータを記憶している。具体的に、記憶部２８には、アプリケーションプログラムＰ２、端末証明書Ｖ２、連携データ情報Ｖ３、鍵情報Ｖ４等が記憶されている。
アプリケーションプログラムＰ２は、クライアント端末２０において、医療情報のアップロード処理やダウンロード処理等を実行するためのプログラムである。アプリケーションプログラムＰ２は、管理サーバー１０からダウンロードされ、使用される。
端末証明書Ｖ２は、クライアント端末２０が管理サーバー１０へのアクセスを許可された端末であることを示す情報であり、「端末ＩＤ」、「鍵有効期間」、「端末鍵」を含む。
連携データ情報Ｖ３は、管理サーバー１０からダウンロードされた医療情報（連携データ）に関する情報であり、「連携ＩＤ」、「連携データＩＤ」、「暗号化連携データ」、「有効期間」を含む。
鍵情報Ｖ４は、暗号化連携データを復号するための鍵に関する情報であり、「連携データＩＤ」、「暗号データ（暗号化されたコンテンツ鍵・認可情報）」、「有効期間」を含む。
制御部２１は、医療情報のアップロード時、操作部２４から指定された医療情報（連携データ）を、通信部２３を介して管理サーバー１０に送信する。
制御部２１は、医療情報のダウンロード時、連携データＩＤと、当該連携データＩＤと対応付けられている暗号化連携データ（暗号化された連携データ）及び暗号データ（暗号化されたコンテンツ鍵・認可情報）の全てを、通信部２３を介して管理サーバー１０から取得する。
制御部２１は、ＩＣカードリーダー・ライター２６を制御して、ＩＣカードＣ１に記憶されているユーザー鍵（連携先鍵）を取得する。また、制御部２１は、記憶部２８に記憶されている端末証明書Ｖ２から端末鍵（連携先鍵）を取得する。すなわち、制御部２１は、第１取得手段として機能する。
制御部２１は、管理サーバー１０から取得された暗号データに対して、クライアント端末２０が持っている鍵で復号できるか、確かめる。ユーザー鍵、端末鍵、又は、ユーザー鍵及び端末鍵の両方のいずれにより暗号化されるかは、管理サーバー１０とクライアント端末２０との間で予め決められている。ユーザー鍵及び端末鍵の両方を用いる場合には、その順番も予め決められている。
制御部２１は、管理サーバー１０から取得された暗号データを、ＩＣカードＣ１のユーザー証明書Ｖ１から取得されたユーザー鍵、記憶部２８の端末証明書Ｖ２から取得された端末鍵を用いて復号してコンテンツ鍵及び認可情報を取得する。すなわち、制御部２１は、第２取得手段として機能する。
制御部２１は、管理サーバー１０から取得された暗号データを、ＩＣカードＣ１のユーザー証明書Ｖ１から取得されたユーザー鍵、記憶部２８の端末証明書Ｖ２から取得された端末鍵を用いて復号してコンテンツ鍵及び認可情報を取得する。すなわち、制御部２１は、第２取得手段として機能する。
図６（ａ）は、暗号データの復号を示すイメージ図である。ここでは、使用中のクライアント端末２０の端末ＩＤが「Ｔ００１」、使用中のユーザーのユーザーＩＤが「Ｕ００１」であることとする。また、暗号データ２，３については、図４（ｂ）のように生成されたものである。暗号データ２に対し、ユーザーＩＤ「Ｕ００１」に対応するユーザー鍵を用いて復号を試みると、復号することができ、暗号データ１が得られる。一方、暗号データ３は、ユーザーＩＤ「Ｕ００２」に対応するユーザー鍵で暗号化されたものであるから、ユーザーＩＤ「Ｕ００１」に対応するユーザー鍵を用いて復号を試みても、復号することはできない。次に、暗号データ１に対し、端末ＩＤ「Ｔ００１」に対応する端末鍵を用いて復号を試みると、復号することができ、コンテンツ鍵及び認可情報が得られる。
制御部２１は、取得された認可情報に応じた権限の範囲内で、管理サーバー１０から取得された暗号化連携データを、取得されたコンテンツ鍵を用いて復号して医療情報（連携データ）を取得する。すなわち、制御部２１は、第３取得手段として機能する。
図６（ｂ）は、暗号化連携データの復号を示すイメージ図である。暗号化連携データをコンテンツ鍵を用いて復号して、連携データが得られる。
制御部２１は、取得された認可情報において暗号化出力が認可されている場合に、データ書込部２７を制御して、管理サーバー１０から取得された暗号化連携データ及び暗号データをメディアＭ１に書き込ませる。
なお、コンテンツ鍵、端末鍵、ユーザー鍵は、暗号化と復号に同じ鍵を使う共通鍵暗号方式であってもよいし、暗号化と復号に別個の鍵（公開鍵と秘密鍵の組み合わせ）を使う公開鍵暗号方式であってもよい。
次に、医療情報管理システム１００における動作について説明する。以下の処理において、管理サーバー１０における処理は、制御部１１と記憶部１４に記憶されているサーバープログラムＰ１との協働によるソフトウェア処理によって実現され、クライアント端末２０における処理は、制御部２１と記憶部２８に記憶されているアプリケーションプログラムＰ２との協働によるソフトウェア処理によって実現される。
＜端末登録シーケンス＞
図７は、端末登録シーケンスを示すラダーチャートである。端末登録シーケンスは、医療情報管理システム１００において、クライアント端末２０が正規の端末であることを証明するための電子証明書（端末証明書Ｖ２）を生成する際の手順を示している。この操作を行える利用者は、通常システム運用上で制限をかけるが（連携先医療施設における管理者等）、制限をかけなくてもよい。
図７は、端末登録シーケンスを示すラダーチャートである。端末登録シーケンスは、医療情報管理システム１００において、クライアント端末２０が正規の端末であることを証明するための電子証明書（端末証明書Ｖ２）を生成する際の手順を示している。この操作を行える利用者は、通常システム運用上で制限をかけるが（連携先医療施設における管理者等）、制限をかけなくてもよい。
まず、クライアント端末２０において、制御部２１は、乱数を発生させる等して、他のクライアント端末２０と重複しないような端末ＩＤを生成する（ステップＳ１）。例えば、端末ＩＤとして、「FEA92C15-6EE4-4665-A0B0-C491E30B85E7」が用いられる。
次に、制御部２１は、通信部２３を介して第三者認証局３０にアクセスし、端末ＩＤに対応する端末鍵の生成を要求し、第三者認証局３０から端末鍵を取得する（ステップＳ２）。第三者認証局３０には、端末ＩＤと端末鍵とが対応付けられて記憶される。
次に、制御部２１は、通信部２３を介して管理サーバー１０に対して、端末ＩＤ及び端末鍵を送信し（ステップＳ３）、クライアント端末２０の登録を要求する。
管理サーバー１０では、通信部１３を介してクライアント端末２０から端末ＩＤ及び端末鍵を受信すると、制御部１１は、端末情報テーブルＴ１を参照し、端末ＩＤがテーブル内で重複していないことを確認する（ステップＳ４）。端末ＩＤが重複している場合には、制御部１１は、クライアント端末２０に対し、端末ＩＤの生成からやり直しを要求する。
次に、制御部１１は、通信部１３を介して第三者認証局３０にアクセスし、端末鍵の検証を要求する（ステップＳ５）。第三者認証局３０は、端末ＩＤと端末鍵の組み合わせが正しいものであることを管理サーバー１０に通知する。
次に、制御部１１は、端末鍵の有効期間（鍵有効期間）を決定する（ステップＳ６）。鍵有効期間として、予め定められている期間を用いてもよいし、所定の条件に基づいて期間を決定することとしてもよい。
次に、制御部１１は、端末情報テーブルＴ１に、クライアント端末２０から受信された端末ＩＤ及び端末鍵、ステップＳ６で決定された鍵有効期間を対応付けて保存する（ステップＳ７）。これらの情報は、医療情報管理システム１００のサーバープログラムＰ１を用いなければ、参照できない状態で保存される。
次に、制御部１１は、通信部１３を介してクライアント端末２０に、鍵有効期間を送信する（ステップＳ８）。
クライアント端末２０において、制御部２１は、記憶部２８に端末証明書Ｖ２として、ステップＳ１で生成された端末ＩＤ、管理サーバー１０から受信された鍵有効期間、ステップＳ２で取得された端末鍵を保存する（ステップＳ９）。これらの情報は、クライアント端末２０を使用する権限がなければ、参照できない状態で保存される。
以上で、端末登録シーケンスが終了する。
以上で、端末登録シーケンスが終了する。
＜利用者登録シーケンス＞
図８は、利用者登録シーケンスを示すラダーチャートである。利用者登録シーケンスは、医療情報管理システム１００において、正規の利用者であることを登録する際の手順を示している。
図８は、利用者登録シーケンスを示すラダーチャートである。利用者登録シーケンスは、医療情報管理システム１００において、正規の利用者であることを登録する際の手順を示している。
まず、クライアント端末２０において、ユーザーは、操作部２４からユーザーＩＤ、利用者情報、パスワードを入力し、制御部２１は、入力されたこれらの情報を取得する（ステップＳ１１，Ｓ１２，Ｓ１３）。
次に、制御部２１は、ＩＣカードリーダー・ライター２６によりＩＣカードＣ１を読み取らせ、ユーザー証明書Ｖ１からユーザー鍵を取得する（ステップＳ１４）。なお、ユーザーＩＤ及び利用者情報についても、ユーザー証明書Ｖ１から取得することとしてもよい。
次に、制御部２１は、通信部２３を介して管理サーバー１０に対して、ユーザーＩＤ、利用者情報、パスワード及びユーザー鍵を送信し（ステップＳ１５）、利用者の登録を要求する。
管理サーバー１０では、通信部１３を介してクライアント端末２０からユーザーＩＤ、利用者情報、パスワード及びユーザー鍵を受信すると、制御部１１は、ユーザー鍵の有効期間（ユーザー有効期間）を決定する（ステップＳ１６）。ユーザー有効期間として、予め定められている期間を用いてもよいし、所定の条件に基づいて期間を決定することとしてもよい。
次に、制御部１１は、利用者情報テーブルＴ２に、クライアント端末２０から受信されたユーザーＩＤ、利用者情報、パスワード及びユーザー鍵、ステップＳ１６で決定されたユーザー有効期間を対応付けて保存する（ステップＳ１７）。これらの情報は、医療情報管理システム１００のサーバープログラムＰ１を用いなければ、参照できない状態で保存される。
以上で、利用者登録シーケンスが終了する。
以上で、利用者登録シーケンスが終了する。
以下、処理の前提として、クライアント端末２０において管理サーバー１０にアクセスする場合には、クライアント端末２０からユーザーＩＤとパスワードが入力され、管理サーバー１０においてユーザー認証が行われる。
なお、利用者情報テーブルＴ２において、ユーザーＩＤに対応するユーザー有効期間が期限切れとなっている場合には、当該ユーザーＩＤに対応するユーザーによる管理サーバー１０に対するアクセスが拒否される。
なお、利用者情報テーブルＴ２において、ユーザーＩＤに対応するユーザー有効期間が期限切れとなっている場合には、当該ユーザーＩＤに対応するユーザーによる管理サーバー１０に対するアクセスが拒否される。
＜アップロードシーケンス＞
図９は、アップロードシーケンスを示すラダーチャートである。アップロードシーケンスは、クライアント端末２０から管理サーバー１０に対して医療情報をアップロードする際の手順を示している。クライアント端末２０では、医療情報をアップロードする際、医療情報を参照・出力するための条件となる認可情報が設定される。
図９は、アップロードシーケンスを示すラダーチャートである。アップロードシーケンスは、クライアント端末２０から管理サーバー１０に対して医療情報をアップロードする際の手順を示している。クライアント端末２０では、医療情報をアップロードする際、医療情報を参照・出力するための条件となる認可情報が設定される。
まず、クライアント端末２０において、制御部２１は、ユーザーによる操作部２４からの操作に応じて、医療施設内に設置されたＰＡＣＳ等からアップロードの対象となる連携データ（医療情報）を取り込む（ステップＳ２１）。
次に、制御部２１は、ユーザーによる操作部２４からの操作に応じて、送信する連携データ毎に、認可情報を設定する（ステップＳ２２）。認可情報には、連携データを参照・出力可能な有効期間、連携データを参照・出力可能なユーザーのユーザーＩＤ、連携データを参照・出力可能な端末の端末ＩＤ、匿名化要否等が含まれる。また、図３に示す例のように、認可種別毎に権限を設定してもよい。クライアント端末２０の表示部２５には、連携データの公開先をユーザー毎に設定するか、端末毎に設定するか、又は、それらの組み合わせとするか等を選択・設定するための操作画面が表示される。
次に、制御部２１は、通信部２３を介して管理サーバー１０に対して、連携データと認可情報を対応付けて送信し（ステップＳ２３）、連携データのアップロードを要求する。
管理サーバー１０では、通信部１３を介して連携データ及び認可情報を受信すると、制御部１１は、クライアント端末２０から送信された送信単位（一又は複数の連携データを含む。）に対し、連携ＩＤを付与する（ステップＳ２４）。
次に、制御部１１は、連携情報テーブルＴ３に、ステップＳ２４で付与された連携ＩＤ、クライアント端末２０を使用中のユーザーに対応する送信元ユーザーＩＤを対応付けて保存する（ステップＳ２５）。
次に、制御部１１は、連携情報テーブルＴ３に、ステップＳ２４で付与された連携ＩＤ、クライアント端末２０を使用中のユーザーに対応する送信元ユーザーＩＤを対応付けて保存する（ステップＳ２５）。
次に、制御部１１は、連携データ毎に、連携データＩＤを付与する（ステップＳ２６）。
次に、制御部１１は、連携データ毎に、認可情報テーブルＴ４に、ステップＳ２４で付与された連携ＩＤ、ステップＳ２６で付与された当該連携データに対応する連携データＩＤ、クライアント端末２０から受信された当該連携データに対応する認可情報を対応付けて保存する（ステップＳ２７）。
次に、制御部１１は、連携データ毎に、認可情報テーブルＴ４に、ステップＳ２４で付与された連携ＩＤ、ステップＳ２６で付与された当該連携データに対応する連携データＩＤ、クライアント端末２０から受信された当該連携データに対応する認可情報を対応付けて保存する（ステップＳ２７）。
次に、制御部１１は、連携データ毎に、当該連携データを、連携ＩＤ、連携データＩＤと対応付けて保存する（ステップＳ２８）。例えば、制御部１１は、記憶部１４において、「連携ＩＤ」の名称のフォルダーを作成し、このフォルダーの下位階層に各連携データに対応する「連携データＩＤ」の名称のフォルダーを作成し、各連携データを当該連携データに対応するフォルダーに格納する。ＤＩＣＯＭ画像に関しては、画像データ部分と患者情報等の付帯情報部分とに分割して保存される。
以上で、アップロードシーケンスが終了する。
以上で、アップロードシーケンスが終了する。
＜ダウンロードシーケンス＞
図１０及び図１１は、ダウンロードシーケンスを示すラダーチャートである。ダウンロードシーケンスは、クライアント端末２０が管理サーバー１０から医療情報をダウンロードする際の手順を示している。
図１０及び図１１は、ダウンロードシーケンスを示すラダーチャートである。ダウンロードシーケンスは、クライアント端末２０が管理サーバー１０から医療情報をダウンロードする際の手順を示している。
クライアント端末２０では、制御部２１が、使用中のユーザーに基づいて、管理サーバー１０から入手可能な医療情報（連携ＩＤ）のリストを取得し、取得したリストを表示部２５に表示させる。
ユーザーが操作部２４からの操作により連携ＩＤを指定すると、制御部２１は、指定された連携ＩＤに基づいて、通信部２３を介して管理サーバー１０に、ダウンロード要求を送信する（ステップＳ３１）。
ユーザーが操作部２４からの操作により連携ＩＤを指定すると、制御部２１は、指定された連携ＩＤに基づいて、通信部２３を介して管理サーバー１０に、ダウンロード要求を送信する（ステップＳ３１）。
管理サーバー１０では、通信部１３を介してクライアント端末２０からダウンロード要求を受信すると、制御部１１は、連携情報テーブルＴ３から指定された連携ＩＤに対応する送信元ユーザーＩＤを取得する（ステップＳ３２）。
ここで、「送信元ユーザーＩＤ」に対応する送信元ユーザーが、クライアント端末２０においてログイン中のユーザー本人でない場合、認可情報テーブルＴ４から連携ＩＤに対応する連携データＩＤ及び認可情報を取得する（ステップＳ３３）。連携ＩＤに対応する連携データＩＤが複数存在する場合には、クライアント端末２０に候補を提示し、ユーザーにより選択された連携データＩＤに対応する連携データをダウンロードの対象とする。
ここで、「送信元ユーザーＩＤ」に対応する送信元ユーザーが、クライアント端末２０においてログイン中のユーザー本人でない場合、認可情報テーブルＴ４から連携ＩＤに対応する連携データＩＤ及び認可情報を取得する（ステップＳ３３）。連携ＩＤに対応する連携データＩＤが複数存在する場合には、クライアント端末２０に候補を提示し、ユーザーにより選択された連携データＩＤに対応する連携データをダウンロードの対象とする。
なお、クライアント端末２０においてログイン中のユーザー本人がアップロードした情報については、参照・出力が可能であるため、説明を省略する。
次に、制御部１１は、今回のダウンロードに対して、ダウンロードコンテンツＩＤを生成する（ステップＳ３４）。
また、制御部１１は、今回のダウンロードに対して、乱数を利用して、連携データの暗号化に用いるコンテンツ鍵を生成する（ステップＳ３５）。
また、制御部１１は、ステップＳ３３において取得された認可情報から有効期間を取得する（ステップＳ３６）。具体的には、認可情報に含まれる認可種別毎の有効期間を全て含む範囲を、連携データに対応する有効期間とする。
また、制御部１１は、今回のダウンロードに対して、乱数を利用して、連携データの暗号化に用いるコンテンツ鍵を生成する（ステップＳ３５）。
また、制御部１１は、ステップＳ３３において取得された認可情報から有効期間を取得する（ステップＳ３６）。具体的には、認可情報に含まれる認可種別毎の有効期間を全て含む範囲を、連携データに対応する有効期間とする。
次に、制御部１１は、暗号化履歴テーブルＴ５に、ステップＳ３４で生成されたダウンロードコンテンツＩＤ、ダウンロードの対象となる連携データに対応する連携データＩＤ、ステップＳ３５で生成されたコンテンツ鍵、ステップＳ３６で取得された有効期間を対応付けて保存する（ステップＳ３７）。
次に、制御部１１は、ダウンロードの対象となる連携データをコンテンツ鍵で暗号化し、暗号化連携データを生成する（ステップＳ３８）。この際、連携データに対応する認可情報において、全ての認可種別について匿名化要否が「ＹＥＳ」の場合には、連携データに含まれる患者情報等の個人情報をアスタリスク等で置き換えて匿名化した後、匿名化後の連携データをコンテンツ鍵で暗号化する。
次に、制御部１１は、ステップＳ３５で生成されたコンテンツ鍵と、ステップＳ３３で取得された認可情報と、を端末鍵及びユーザー鍵を用いて暗号化し、暗号データを生成する（ステップＳ３９）。具体的には、まず、制御部１１は、認可情報において参照又は出力が許可されている端末ＩＤを取得し、端末情報テーブルＴ１からこの端末ＩＤに対応する端末鍵を取得し、この端末鍵を用いて、コンテンツ鍵と認可情報を暗号化する。認可情報において複数の端末ＩＤに対して参照又は出力が許可されている場合には、各端末ＩＤに対応する各端末鍵を用いて、コンテンツ鍵と認可情報を暗号化する。続いて、制御部１１は、認可情報において参照又は出力が許可されているユーザーＩＤを取得し、利用者情報テーブルＴ２からこのユーザーＩＤに対応するユーザー鍵を取得し、このユーザー鍵を用いて、端末鍵で暗号化されたコンテンツ鍵と認可情報を暗号化する。認可情報において複数のユーザーＩＤに対して参照又は出力が許可されている場合には、各ユーザーＩＤに対応する各ユーザー鍵を用いて、端末鍵で暗号化されたコンテンツ鍵と認可情報を暗号化する。
なお、端末情報テーブルＴ１において、端末ＩＤに対応する鍵有効期間が期限切れとなっている場合には、当該端末ＩＤに対応する端末鍵の使用は不可とする。
次に、図１１に移り、制御部１１は、通信部１３を介してクライアント端末２０に、暗号化連携データ及び暗号データを連携データＩＤと対応付けて送信する（ステップＳ４０）。暗号データについては、認可情報により指定されている各端末ＩＤと各ユーザーＩＤの組み合わせ毎に生成された全ての暗号データが送信される。
クライアント端末２０では、通信部２３を介して連携データＩＤ、暗号化連携データ及び暗号データを受信すると、制御部２１は、ＩＣカードリーダー・ライター２６によりＩＣカードＣ１のユーザー証明書Ｖ１からユーザー鍵を取得し、記憶部２８に記憶されている端末証明書Ｖ２から端末鍵を取得する。そして、制御部２１は、ユーザー鍵及び端末鍵を用いて暗号データの復号を試みる。
なお、端末証明書Ｖ２において、端末鍵に対応する鍵有効期間が期限切れとなっている場合には、当該端末鍵の使用は不可とする。
クライアント端末２０のユーザー及びクライアント端末２０に対して参照又は出力が許可されている場合には、制御部２１は、ユーザー鍵及び端末鍵を用いて暗号データを復号し、コンテンツ鍵及び認可情報を取得する（ステップＳ４１）。
なお、端末証明書Ｖ２において、端末鍵に対応する鍵有効期間が期限切れとなっている場合には、当該端末鍵の使用は不可とする。
クライアント端末２０のユーザー及びクライアント端末２０に対して参照又は出力が許可されている場合には、制御部２１は、ユーザー鍵及び端末鍵を用いて暗号データを復号し、コンテンツ鍵及び認可情報を取得する（ステップＳ４１）。
次に、制御部２１は、取得された認可情報から有効期間を取得する（ステップＳ４２）。具体的には、認可情報に含まれる認可種別毎の有効期間を全て含む範囲を、連携データに対応する有効期間とする。
次に、制御部２１は、ステップＳ３１で指定された連携ＩＤ、ダウンロード対象の連携データに対応する連携データＩＤ、管理サーバー１０から受信された暗号化連携データ、ステップＳ４２で取得された有効期間を、連携データ情報Ｖ３として記憶部２８に保存する（ステップＳ４３）。
次に、制御部２１は、ダウンロード対象の連携データに対応する連携データＩＤ、管理サーバー１０から受信された暗号データ（暗号化されたコンテンツ鍵・認可情報）、ステップＳ４２で取得された有効期間を、鍵情報Ｖ４として記憶部２８に保存する（ステップＳ４４）。
以上で、ダウンロードシーケンスが終了する。
次に、制御部２１は、ダウンロード対象の連携データに対応する連携データＩＤ、管理サーバー１０から受信された暗号データ（暗号化されたコンテンツ鍵・認可情報）、ステップＳ４２で取得された有効期間を、鍵情報Ｖ４として記憶部２８に保存する（ステップＳ４４）。
以上で、ダウンロードシーケンスが終了する。
なお、連携データに対応する認可情報において、全ての認可種別において、ユーザーＩＤ、端末ＩＤが指定されていない場合には、暗号化されずにそのままダウンロードされる。この場合には、コンテンツ鍵も生成されない。クライアント端末２０では、鍵情報Ｖ４に「鍵は存在しない」旨の情報が保存される。
また、認可情報において、連携データに対応する匿名化要否が「ＹＥＳ」であって、ユーザーＩＤ、端末ＩＤが指定されていない場合には、連携データに対し匿名化は行われるが、暗号化はされない。
また、認可情報において、連携データに対応する匿名化要否が「ＹＥＳ」であって、ユーザーＩＤ、端末ＩＤが指定されていない場合には、連携データに対し匿名化は行われるが、暗号化はされない。
＜表示シーケンス＞
図１２は、表示シーケンスを示すラダーチャートである。表示シーケンスは、ダウンロード済みの医療情報を表示する際の手順を示している。
図１２は、表示シーケンスを示すラダーチャートである。表示シーケンスは、ダウンロード済みの医療情報を表示する際の手順を示している。
クライアント端末２０において、ユーザーが操作部２４からの操作により連携ＩＤを指定すると（ステップＳ５１）、制御部２１は、記憶部２８に記憶されている連携データ情報Ｖ３から、指定された連携ＩＤに対応する連携データＩＤ及び暗号化連携データを取得する（ステップＳ５２）。
次に、制御部２１は、記憶部２８に記憶されている鍵情報Ｖ４から、ステップＳ５２において取得された連携データＩＤに対応する暗号データ（暗号化されたコンテンツ鍵・認可情報）を取得する（ステップＳ５３）。
次に、制御部２１は、ユーザー証明書Ｖ１に含まれるユーザー鍵、及び、端末証明書Ｖ２に含まれる端末鍵を用いて暗号データの復号を試みる（ステップＳ５４）。
ユーザー鍵及び端末鍵を用いた暗号データの復号が成功し、コンテンツ鍵を取得することができた場合には（ステップＳ５５；ＹＥＳ）、制御部２１は、暗号データの復号により取得された認可情報に基づいて、連携データの参照について有効期間内であるか否かを判断する（ステップＳ５６）。連携データの参照について、認可種別が「画像参照」、「患者参照」等、複数存在する場合には、該当する認可種別に対応する情報により判断すればよい。
ステップＳ５５において、コンテンツ鍵を取得することができなかった場合（ステップＳ５５；ＮＯ）、又は、ステップＳ５６において、連携データの参照について有効期間内でない場合には（ステップＳ５６；ＮＯ）、クライアント端末２０及び管理サーバー１０は、ダウンロードシーケンス（図１０及び図１１参照）を実行する（ステップＳ５７）。
クライアント端末２０では、再ダウンロード後、制御部２１は、対象の連携データを参照可能であるか否かを判断する（ステップＳ５８）。具体的には、制御部２１は、ユーザー証明書Ｖ１のユーザー鍵、端末証明書Ｖ２の端末鍵を用いて暗号データの復号ができるか否かを試みる。ユーザー鍵及び端末鍵を用いた暗号データの復号が成功した場合には、制御部２１は、コンテンツ鍵及び認可情報を取得する。そして、制御部２１は、認可情報において、クライアント端末２０のユーザー及び端末に対して参照が許可され、かつ、有効期間内である場合には、対象の連携データを参照可能であると判断する。一方、制御部２１は、クライアント端末２０のユーザー又は端末に対して参照が許可されていない場合、有効期間内でない場合、又は、ユーザー鍵及び端末鍵を用いた暗号データの復号ができなかった場合には、対象の連携データを参照可能でないと判断する。
対象の連携データを参照可能である場合（ステップＳ５８；ＹＥＳ）、又は、ステップＳ５６において、連携データの参照について有効期間内である場合には（ステップＳ５６；ＹＥＳ）、制御部２１は、コンテンツ鍵を用いて暗号化連携データを復号し、連携データを取得する（ステップＳ５９）。
制御部２１は、取得された連携データを表示部２５に表示させる（ステップＳ６０）。
制御部２１は、取得された連携データを表示部２５に表示させる（ステップＳ６０）。
ステップＳ６０の後、又は、ステップＳ５８において、対象の連携データを参照可能でない場合には（ステップＳ５８；ＮＯ）、表示シーケンスが終了する。
なお、上記の説明では、管理サーバー１０とクライアント端末２０とが通信可能に接続されていることとしたが、クライアント端末２０側に暗号化連携データと暗号データが保存されていれば、オフラインであっても、クライアント端末２０が利用可能な鍵（ユーザー鍵・端末鍵）を用いて、データを参照することができる。
＜出力シーケンス＞
図１３は、クライアント端末２０において実行される出力シーケンスを示すフローチャートである。出力シーケンスは、医療情報をメディアＭ１に出力する際の手順を示している。
図１３は、クライアント端末２０において実行される出力シーケンスを示すフローチャートである。出力シーケンスは、医療情報をメディアＭ１に出力する際の手順を示している。
ステップＳ６１〜ステップＳ６４の処理は、図１２のステップＳ５１〜ステップＳ５４の処理と同様であるため、説明を省略する。
次に、ユーザー鍵及び端末鍵を用いた暗号データの復号が成功し、コンテンツ鍵を取得することができた場合には（ステップＳ６５；ＹＥＳ）、制御部２１は、暗号データの復号により取得された認可情報に基づいて、連携データの外部出力が可能であるか否かを判断する（ステップＳ６６）。具体的には、制御部２１は、認可情報の認可種別「外部出力」において、有効期間内であって、クライアント端末２０を使用中のユーザーに対応するユーザーＩＤ及びクライアント端末２０に対応する端末ＩＤが指定されている場合には、連携データの外部出力が可能であると判断する。
連携データの外部出力が可能である場合には（ステップＳ６６；ＹＥＳ）、制御部２１は、暗号データの復号により取得されたコンテンツ鍵を用いて暗号化連携データを復号し、連携データを取得する（ステップＳ６７）。
次に、制御部２１は、認可情報に基づいて、外部出力について匿名化が必要であるか否かを判断する（ステップＳ６８）。具体的には、制御部２１は、認可情報の認可種別「外部出力」において、匿名化要否が「ＹＥＳ」の場合には、外部出力について匿名化が必要であると判断する。
外部出力について匿名化が必要である場合には（ステップＳ６８；ＹＥＳ）、制御部２１は、連携データを匿名化し（ステップＳ６９）、データ書込部２７を制御して、匿名化された連携データをメディアＭ１に書き込ませる（ステップＳ７０）。
外部出力について匿名化が必要である場合には（ステップＳ６８；ＹＥＳ）、制御部２１は、連携データを匿名化し（ステップＳ６９）、データ書込部２７を制御して、匿名化された連携データをメディアＭ１に書き込ませる（ステップＳ７０）。
ステップＳ６８において、外部出力について匿名化が必要でない場合には（ステップＳ６８；ＮＯ）、制御部２１は、データ書込部２７を制御して、連携データをメディアＭ１に書き込ませる（ステップＳ７１）。
ステップＳ６６において、連携データの外部出力が可能でない場合には（ステップＳ６６；ＮＯ）、制御部２１は、認可情報に基づいて、連携データの暗号化出力が可能であるか否かを判断する（ステップＳ７２）。具体的には、制御部２１は、認可情報の認可種別「暗号化出力」において、有効期間内であって、クライアント端末２０を使用中のユーザーに対応するユーザーＩＤ及びクライアント端末２０に対応する端末ＩＤが指定されている場合には、連携データの暗号化出力が可能であると判断する。
連携データの暗号化出力が可能である場合には（ステップＳ７２；ＹＥＳ）、制御部２１は、データ書込部２７を制御して、出力対象の連携データに対応する連携データ情報Ｖ３及び鍵情報Ｖ４をメディアＭ１に書き込ませる（ステップＳ７３）。
ステップＳ７０、ステップＳ７１、ステップＳ７３の後、ステップＳ６５において、コンテンツ鍵を取得することができなかった場合（ステップＳ６５；ＮＯ）、又は、ステップＳ７２において、連携データの暗号化出力が可能でない場合には（ステップＳ７２；ＮＯ）、出力シーケンスが終了する。
以上説明したように、第１の実施の形態の医療情報管理システム１００によれば、連携データがダウンロードされる度にコンテンツ鍵を生成し、連携データをコンテンツ鍵を用いて暗号化して暗号化連携データを生成し、コンテンツ鍵及び連携データに対応する認可情報を、認可情報に含まれる公開先（端末ＩＤ・ユーザーＩＤ）に対応する連携先鍵（端末鍵・ユーザー鍵）を用いて暗号化して暗号データを生成し、ダウンロード要求があったクライアント端末２０に暗号化連携データ及び暗号データを提供するので、連携データの漏洩を防止するとともに、連携データの参照・出力を制限することができる。
クライアント端末２０では、連携データを管理サーバー１０からダウンロードした後も、連携データやコンテンツ鍵は暗号化された状態で保存されるので、許可されたクライアント端末２０を許可されたユーザーが使用している場合のみ、復号を可能とすることで、セキュリティーレベルを向上させることができる。例えば、コンテンツ鍵がユーザー鍵で暗号化されている場合には、そのユーザー鍵が保存されたＩＣカードＣ１がなければ、連携データを取得することはできない。
また、オフラインであっても、権限を有するユーザー及びクライアント端末２０であれば、クライアント端末２０において取得可能なユーザー鍵・端末鍵により暗号データを復号し、コンテンツ鍵を取得することができる。
また、オフラインであっても、権限を有するユーザー及びクライアント端末２０であれば、クライアント端末２０において取得可能なユーザー鍵・端末鍵により暗号データを復号し、コンテンツ鍵を取得することができる。
また、クライアント端末２０において、外部出力は認可されていないが、暗号化出力は認可されている場合には、暗号化されたデータ（連携データ情報Ｖ３及び鍵情報Ｖ４）をそのまま出力することができる。他のクライアント端末では、メディアＭ１から連携データ情報Ｖ３及び鍵情報Ｖ４を取得することで、オフラインであっても、他のクライアント端末２０のユーザー・端末が連携データの参照・出力を許可されていれば、他のクライアント端末２０において取得可能なユーザー鍵・端末鍵により暗号データを復号し、コンテンツ鍵を取得することができる。
また、認可情報に有効期間が設定されているので、ダウンロード対象の連携データの公開を時間的に制限することができる。
［第２の実施の形態］
次に、本発明を適用した第２の実施の形態について説明する。
図１４に、第２の実施の形態における医療情報管理システム２００のシステム構成を示す。医療情報管理システム２００は、第１の実施の形態に示した医療情報管理システム１００に対して患者鍵を用いた医療情報の参照・出力制御を付加したものである。
なお、管理サーバー１０の機能的構成、クライアント端末２０の機能的構成については、図２及び図５に示したものと同様であるため、同一の構成については同一の符号を用いて、図示及び説明を省略する。
以下、第２の実施の形態に特徴的な構成及び処理について説明する。
次に、本発明を適用した第２の実施の形態について説明する。
図１４に、第２の実施の形態における医療情報管理システム２００のシステム構成を示す。医療情報管理システム２００は、第１の実施の形態に示した医療情報管理システム１００に対して患者鍵を用いた医療情報の参照・出力制御を付加したものである。
なお、管理サーバー１０の機能的構成、クライアント端末２０の機能的構成については、図２及び図５に示したものと同様であるため、同一の構成については同一の符号を用いて、図示及び説明を省略する。
以下、第２の実施の形態に特徴的な構成及び処理について説明する。
管理サーバー１０は、端末情報テーブルＴ１、利用者情報テーブルＴ２、連携情報テーブルＴ３、認可情報テーブルＴ４、暗号化履歴テーブルＴ５に加え、患者情報テーブルＴ６を備える。患者情報テーブルＴ６は、記憶部１４に記憶されている。
患者情報テーブルＴ６には、医療情報管理システム２００において、複数の連携先医療施設において共有される医療情報に係る患者毎の情報が格納される。患者情報テーブルＴ６には、「患者ＵＵＩＤ」に対して、「患者情報」、「有効期間」、「患者鍵」が対応付けられている（第２記憶手段）。各患者は、医療情報を共有する連携先として設定可能であり、医療情報の公開先の候補となる。
「患者ＵＵＩＤ」は、患者を識別するための識別情報である。
「患者情報」は、患者に関する情報であり、患者の氏名、生年月日、性別等を含む。
「有効期間」は、「患者ＵＵＩＤ」に対応する「患者鍵」の利用を許可された期間である。
「患者鍵」は、「患者ＵＵＩＤ」により特定される患者に対して用意された、各患者に固有の鍵である。
「患者ＵＵＩＤ」は、患者を識別するための識別情報である。
「患者情報」は、患者に関する情報であり、患者の氏名、生年月日、性別等を含む。
「有効期間」は、「患者ＵＵＩＤ」に対応する「患者鍵」の利用を許可された期間である。
「患者鍵」は、「患者ＵＵＩＤ」により特定される患者に対して用意された、各患者に固有の鍵である。
第２の実施の形態では、図３に示す認可情報において、連携データＩＤ毎に、各認可種別（画像参照、患者参照、外部出力、暗号化出力）に対して、有効期間、ユーザーＩＤ、端末ＩＤ、匿名化要否に加え、患者鍵使用可否が対応付けられている（第１記憶手段）。
患者鍵使用可否は、対応する連携データに対して患者鍵を使用可能であるか否かを示す情報である。患者鍵使用可否が「ＹＥＳ」の場合には、連携データがダウンロードされた場合に、患者鍵を使用してコンテンツ鍵を取得することができる。つまり、患者鍵使用可否が「ＹＥＳ」の場合には、認可情報に、公開先として「医療情報（連携データ）に係る患者」が含まれていることになる。第２の実施の形態では、認可情報の患者鍵使用可否が「ＹＥＳ」の場合について説明する。
患者鍵使用可否は、対応する連携データに対して患者鍵を使用可能であるか否かを示す情報である。患者鍵使用可否が「ＹＥＳ」の場合には、連携データがダウンロードされた場合に、患者鍵を使用してコンテンツ鍵を取得することができる。つまり、患者鍵使用可否が「ＹＥＳ」の場合には、認可情報に、公開先として「医療情報（連携データ）に係る患者」が含まれていることになる。第２の実施の形態では、認可情報の患者鍵使用可否が「ＹＥＳ」の場合について説明する。
制御部１１は、複数のクライアント端末２０のいずれかから医療情報（連携データ）のダウンロード要求があった場合に、当該医療情報がダウンロードされる度にコンテンツ鍵を生成し、当該医療情報を当該生成されたコンテンツ鍵を用いて暗号化して暗号化連携データを生成する。すなわち、制御部１１は、第１生成手段として機能する。
制御部１１は、コンテンツ鍵により暗号化された医療情報（連携データ）に対応する認可情報を、記憶部１４に記憶されている認可情報テーブルＴ４から取得する。
制御部１１は、取得した認可情報に含まれる公開先（医療情報に係る患者）に対応する連携先鍵（患者鍵）、すなわち、コンテンツ鍵により暗号化された医療情報に係る患者に対応する患者鍵を、記憶部１４に記憶されている患者情報テーブルＴ６から取得する。
制御部１１は、コンテンツ鍵及びコンテンツ鍵により暗号化された医療情報（連携データ）に対応する認可情報を、患者鍵を用いて暗号化して第２情報としての患者鍵暗号データを生成する。すなわち、制御部１１は、第２生成手段として機能する。
制御部１１は、取得した認可情報に含まれる公開先（医療情報に係る患者）に対応する連携先鍵（患者鍵）、すなわち、コンテンツ鍵により暗号化された医療情報に係る患者に対応する患者鍵を、記憶部１４に記憶されている患者情報テーブルＴ６から取得する。
制御部１１は、コンテンツ鍵及びコンテンツ鍵により暗号化された医療情報（連携データ）に対応する認可情報を、患者鍵を用いて暗号化して第２情報としての患者鍵暗号データを生成する。すなわち、制御部１１は、第２生成手段として機能する。
制御部１１は、通信部１３を介して、ダウンロード要求があったクライアント端末２０に暗号化連携データ及び患者鍵暗号データを提供する。すなわち、制御部１１は、提供手段として機能する。
クライアント端末２０は、ＩＣカードＣ２から情報を取得する。ＩＣカードＣ２は、各患者が所持するカードであり、各患者に対応する患者証明書Ｖ５が記憶されている。患者証明書Ｖ５は、「患者ＵＵＩＤ」、「患者情報」、「有効期間」、「患者鍵」を含む。
クライアント端末２０は、端末証明書Ｖ２、連携データ情報Ｖ３、鍵情報Ｖ４に加え、患者鍵情報Ｖ６等の情報を記憶する。患者鍵情報Ｖ６は、記憶部２８に記憶されている。
患者鍵情報Ｖ６は、患者鍵を利用して暗号化連携データを復号するための鍵に関する情報であり、「患者ＵＵＩＤ」、「患者鍵暗号データ（患者鍵で暗号化されたコンテンツ鍵・認可情報）」、「有効期間」を含む。
患者鍵情報Ｖ６は、患者鍵を利用して暗号化連携データを復号するための鍵に関する情報であり、「患者ＵＵＩＤ」、「患者鍵暗号データ（患者鍵で暗号化されたコンテンツ鍵・認可情報）」、「有効期間」を含む。
ＩＣカードリーダー・ライター２６は、ＩＣカードＣ２から各種データを読み取り、読み取ったデータを制御部２１に出力する。また、ＩＣカードリーダー・ライター２６は、ＩＣカードＣ２に対して各種データを書き込む。
制御部２１は、医療情報のアップロード時、操作部２４から指定された医療情報（連携データ）を、通信部２３を介して管理サーバー１０に送信する。この時の処理については、図９に示したアップロードシーケンスと同様であるが、ステップＳ２２において認可情報を設定する際に、さらに、患者鍵使用可否を設定する。
制御部２１は、医療情報のダウンロード時、連携データＩＤと、当該連携データＩＤと対応付けられている暗号化連携データ（暗号化された連携データ）、暗号データ（端末鍵・ユーザー鍵で暗号化されたコンテンツ鍵・認可情報）の全て、患者鍵暗号データ（患者鍵で暗号化されたコンテンツ鍵・認可情報）を、通信部２３を介して管理サーバー１０から取得する。
制御部２１は、ＩＣカードリーダー・ライター２６を制御して、ＩＣカードＣ２に記憶されている患者鍵（連携先鍵）を取得する。すなわち、制御部２１は、第１取得手段として機能する。
制御部２１は、管理サーバー１０から取得された患者鍵暗号データに対して、クライアント端末２０が持っている患者鍵で復号できるか、確かめる。
制御部２１は、管理サーバー１０から取得された患者鍵暗号データを、ＩＣカードＣ２から取得された患者鍵を用いて復号してコンテンツ鍵及び認可情報を取得する。すなわち、制御部２１は、第２取得手段として機能する。
制御部２１は、管理サーバー１０から取得された患者鍵暗号データを、ＩＣカードＣ２から取得された患者鍵を用いて復号してコンテンツ鍵及び認可情報を取得する。すなわち、制御部２１は、第２取得手段として機能する。
制御部２１は、取得された認可情報に応じた権限の範囲内で、管理サーバー１０から取得された暗号化連携データを、取得されたコンテンツ鍵を用いて復号して医療情報（連携データ）を取得する。すなわち、制御部２１は、第３取得手段として機能する。
次に、医療情報管理システム２００における動作について説明する。以下の処理において、管理サーバー１０における処理は、制御部１１と記憶部１４に記憶されているサーバープログラムＰ１との協働によるソフトウェア処理によって実現され、クライアント端末２０における処理は、制御部２１と記憶部２８に記憶されているアプリケーションプログラムＰ２との協働によるソフトウェア処理によって実現される。
＜患者登録シーケンス＞
図１５は、患者登録シーケンスを示すラダーチャートである。患者登録シーケンスは、医療情報管理システム２００において、正規の患者であることを登録する際の手順を示している。
図１５は、患者登録シーケンスを示すラダーチャートである。患者登録シーケンスは、医療情報管理システム２００において、正規の患者であることを登録する際の手順を示している。
まず、クライアント端末２０において、ユーザーは、操作部２４から患者情報及び有効期間を入力し、制御部２１は、入力されたこれらの情報を取得する（ステップＳ８１，Ｓ８２）。
次に、制御部２１は、通信部２３を介して管理サーバー１０に対して、患者情報及び有効期間を送信し（ステップＳ８３）、患者の登録を要求する。
次に、制御部２１は、通信部２３を介して管理サーバー１０に対して、患者情報及び有効期間を送信し（ステップＳ８３）、患者の登録を要求する。
管理サーバー１０では、通信部１３を介してクライアント端末２０から患者情報及び有効期間を受信すると、制御部１１は、登録対象の患者に対して、他の患者と重複しないような患者ＵＵＩＤを発行する（ステップＳ８４）。
次に、制御部１１は、登録対象の患者に対して、患者鍵を発行する（ステップＳ８５）。
次に、制御部１１は、登録対象の患者に対して、患者鍵を発行する（ステップＳ８５）。
次に、制御部１１は、患者情報テーブルＴ６に、ステップＳ８４で発行された患者ＵＵＩＤ、ステップＳ８５で発行された患者鍵、クライアント端末２０から受信された患者情報及び有効期間を対応付けて保存する（ステップＳ８６）。
次に、制御部１１は、通信部１３を介してクライアント端末２０に、患者ＵＵＩＤ及び患者鍵を送信する（ステップＳ８７）。
次に、制御部１１は、通信部１３を介してクライアント端末２０に、患者ＵＵＩＤ及び患者鍵を送信する（ステップＳ８７）。
クライアント端末２０において、制御部２１は、管理サーバー１０から受信された患者ＵＵＩＤ及び患者鍵、ステップＳ８１で入力された患者情報、ステップＳ８２で入力された有効期間から患者証明書Ｖ５を生成し、ＩＣカードリーダー・ライター２６を制御して、ＩＣカードＣ２に患者証明書Ｖ５を書き込ませ、患者証明書Ｖ５を登録する（ステップＳ８８）。
以上で、患者登録シーケンスが終了する。
以上で、患者登録シーケンスが終了する。
医療情報（連携データ）がアップロードされる際、連携データは、当該連携データに係る患者の患者ＵＵＩＤと対応付けられて、管理サーバー１０の記憶部１４に記憶される。
＜患者鍵の使用を含むダウンロードシーケンス＞
図１６及び図１７は、患者鍵の使用を含むダウンロードシーケンスを示すラダーチャートである。患者鍵の使用を含むダウンロードシーケンスは、ダウンロードの対象となる医療情報（連携データ）に対応する認可情報において、患者鍵使用可否が「ＹＥＳ」の場合に実行される処理である。患者鍵が使用される状況としては、例えば、患者がＩＣカードＣ２を持参して医療施設を訪問し、訪問先の医師にＩＣカードＣ２を提示して、医師がＩＣカードＣ２をクライアント端末２０のＩＣカードリーダー・ライター２６にセットした場合等が挙げられる。ここでは、第１の実施の形態と異なる処理を中心に説明する。
図１６及び図１７は、患者鍵の使用を含むダウンロードシーケンスを示すラダーチャートである。患者鍵の使用を含むダウンロードシーケンスは、ダウンロードの対象となる医療情報（連携データ）に対応する認可情報において、患者鍵使用可否が「ＹＥＳ」の場合に実行される処理である。患者鍵が使用される状況としては、例えば、患者がＩＣカードＣ２を持参して医療施設を訪問し、訪問先の医師にＩＣカードＣ２を提示して、医師がＩＣカードＣ２をクライアント端末２０のＩＣカードリーダー・ライター２６にセットした場合等が挙げられる。ここでは、第１の実施の形態と異なる処理を中心に説明する。
ステップＳ９１〜ステップＳ９９の処理は、図１０のステップＳ３１〜ステップＳ３９の処理と同様であるため、説明を省略する。
次に、管理サーバー１０において、制御部１１は、ステップＳ９５で生成されたコンテンツ鍵と、ステップＳ９３で取得された認可情報と、を患者鍵を用いて暗号化し、患者鍵暗号データを生成する（ステップＳ１００）。具体的には、制御部１１は、連携データに対応する患者ＵＵＩＤを取得し、患者情報テーブルＴ６からこの患者ＵＵＩＤに対応する患者鍵を取得し、この患者鍵を用いてコンテンツ鍵と認可情報を暗号化する。
なお、患者情報テーブルＴ６において、患者ＵＵＩＤに対応する有効期間が期限切れとなっている場合には、当該患者ＵＵＩＤに対応する患者鍵の使用は不可とする。
次に、図１７に移り、制御部１１は、通信部１３を介してクライアント端末２０に、ステップＳ９８で生成された暗号化連携データ、ステップＳ９９で生成された暗号データ、ステップＳ１００で生成された患者鍵暗号データ、連携データに対応する患者ＵＵＩＤ及びステップＳ９６で取得された有効期間を連携データＩＤと対応付けて送信する（ステップＳ１０１）。ステップＳ１０１では、図１１のステップＳ４０の処理に加えて、患者鍵暗号データ、患者ＵＵＩＤ及び有効期間が管理サーバー１０からクライアント端末２０に送信されている。
ステップＳ１０２〜ステップＳ１０５の処理は、図１１のステップＳ４１〜ステップＳ４４の処理と同様であるため、説明を省略する。
次に、クライアント端末２０では、制御部２１は、管理サーバー１０から受信された患者ＵＵＩＤ、患者鍵暗号データ（患者鍵で暗号化されたコンテンツ鍵・認可情報）及び有効期間を、患者鍵情報Ｖ６として記憶部２８に保存する（ステップＳ１０６）。
以上で、患者鍵の使用を含むダウンロードシーケンスが終了する。
以上で、患者鍵の使用を含むダウンロードシーケンスが終了する。
クライアント端末２０において、ダウンロードされた暗号化連携データの参照・出力を行う場合には、制御部２１は、処理対象となる連携データ（連携データＩＤ）を指定して、管理サーバー１０から連携データに対応する患者ＵＵＩＤを取得し、この患者ＵＵＩＤに対応する患者鍵暗号データを患者鍵情報Ｖ６から取得する。
次に、制御部２１は、ＩＣカードリーダー・ライター２６を制御して、ＩＣカードＣ２に記憶されている患者証明書Ｖ５から患者鍵を取得し、患者鍵を用いて患者鍵暗号データの復号を試みる。ここで、患者鍵暗号データの復号が成功し、コンテンツ鍵及び認可情報を取得することができた場合には、ユーザー鍵及び端末鍵を用いた暗号データの復号が不要となる。つまり、患者鍵を利用可能な状況であれば、ユーザー鍵や端末鍵を持っていなくても、コンテンツ鍵を取得することができる。患者鍵による患者鍵暗号データの復号ができなかった場合には、第１の実施の形態と同様、ユーザー鍵及び端末鍵を用いて暗号データを復号すればよい。
次に、制御部２１は、ＩＣカードリーダー・ライター２６を制御して、ＩＣカードＣ２に記憶されている患者証明書Ｖ５から患者鍵を取得し、患者鍵を用いて患者鍵暗号データの復号を試みる。ここで、患者鍵暗号データの復号が成功し、コンテンツ鍵及び認可情報を取得することができた場合には、ユーザー鍵及び端末鍵を用いた暗号データの復号が不要となる。つまり、患者鍵を利用可能な状況であれば、ユーザー鍵や端末鍵を持っていなくても、コンテンツ鍵を取得することができる。患者鍵による患者鍵暗号データの復号ができなかった場合には、第１の実施の形態と同様、ユーザー鍵及び端末鍵を用いて暗号データを復号すればよい。
以上説明したように、第２の実施の形態の医療情報管理システム２００によれば、連携データがダウンロードされる度にコンテンツ鍵を生成し、連携データをコンテンツ鍵を用いて暗号化して暗号化連携データを生成し、コンテンツ鍵及び連携データに対応する認可情報を患者鍵を用いて暗号化して患者鍵暗号データを生成し、ダウンロード要求があったクライアント端末２０に暗号化連携データ及び患者鍵暗号データを提供するので、連携データの漏洩を防止するとともに、連携データの参照・出力を制限することができる。
例えば、ある患者を担当することになった医師（ユーザー）のもとで、患者証明書Ｖ５が登録されたＩＣカードＣ２を読み取ることで、患者鍵を使用可能となる。
例えば、ある患者を担当することになった医師（ユーザー）のもとで、患者証明書Ｖ５が登録されたＩＣカードＣ２を読み取ることで、患者鍵を使用可能となる。
なお、上記各実施の形態における記述は、本発明に係る医療情報管理システムの例であり、これに限定されるものではない。システムを構成する各装置の細部構成及び細部動作に関しても本発明の趣旨を逸脱することのない範囲で適宜変更可能である。
例えば、上記各実施の形態では、医療情報を扱う単位として連携データを用いて説明したが、医療情報を暗号化する際の単位については、特に限定されない。
また、第１の実施の形態では、ユーザー鍵及び端末鍵を用いてコンテンツ鍵及び認可情報を暗号化する場合について説明し、第２の実施の形態では、ユーザー鍵及び端末鍵を用いてコンテンツ鍵及び認可情報を暗号化するとともに、患者鍵を用いてコンテンツ鍵及び認可情報を暗号化する場合について説明したが、使用する鍵（ユーザー鍵、端末鍵、患者鍵）の組み合わせについては任意に選択可能である。
１０ 管理サーバー
１１ 制御部
１３ 通信部
１４ 記憶部
２０ クライアント端末
２１ 制御部
２３ 通信部
２４ 操作部
２５ 表示部
２６ ＩＣカードリーダー・ライター
２７ データ書込部
２８ 記憶部
１００ 医療情報管理システム
２００ 医療情報管理システム
Ｍ１ メディア
Ｎ 通信ネットワーク
Ｐ１ サーバープログラム
Ｐ２ アプリケーションプログラム
Ｔ１ 端末情報テーブル
Ｔ２ 利用者情報テーブル
Ｔ３ 連携情報テーブル
Ｔ４ 認可情報テーブル
Ｔ５ 暗号化履歴テーブル
Ｔ６ 患者情報テーブル
Ｖ１ ユーザー証明書
Ｖ２ 端末証明書
Ｖ３ 連携データ情報
Ｖ４ 鍵情報
Ｖ５ 患者証明書
Ｖ６ 患者鍵情報
１１ 制御部
１３ 通信部
１４ 記憶部
２０ クライアント端末
２１ 制御部
２３ 通信部
２４ 操作部
２５ 表示部
２６ ＩＣカードリーダー・ライター
２７ データ書込部
２８ 記憶部
１００ 医療情報管理システム
２００ 医療情報管理システム
Ｍ１ メディア
Ｎ 通信ネットワーク
Ｐ１ サーバープログラム
Ｐ２ アプリケーションプログラム
Ｔ１ 端末情報テーブル
Ｔ２ 利用者情報テーブル
Ｔ３ 連携情報テーブル
Ｔ４ 認可情報テーブル
Ｔ５ 暗号化履歴テーブル
Ｔ６ 患者情報テーブル
Ｖ１ ユーザー証明書
Ｖ２ 端末証明書
Ｖ３ 連携データ情報
Ｖ４ 鍵情報
Ｖ５ 患者証明書
Ｖ６ 患者鍵情報
Claims (5)
- 複数の医療施設において生成された医療情報を管理する管理サーバーと、前記複数の医療施設に設置された複数のクライアント端末と、がデータ通信可能に接続された医療情報管理システムであって、
前記管理サーバーは、
前記医療情報毎に、公開先を含む認可情報を記憶する第１記憶手段と、
前記公開先の候補となる前記医療情報を共有する連携先毎に、連携先鍵を記憶する第２記憶手段と、
前記複数のクライアント端末のいずれかから前記医療情報のダウンロード要求があった場合に、当該医療情報がダウンロードされる度にコンテンツ鍵を生成し、当該医療情報を当該生成されたコンテンツ鍵を用いて暗号化して第１情報を生成する第１生成手段と、
前記コンテンツ鍵及び当該コンテンツ鍵により暗号化された医療情報に対応する認可情報を、当該認可情報に含まれる公開先に対応する連携先鍵を用いて暗号化して第２情報を生成する第２生成手段と、
前記ダウンロード要求があったクライアント端末に前記第１情報及び前記第２情報を提供する提供手段と、
を備え、
前記複数のクライアント端末のそれぞれは、
前記連携先鍵を取得する第１取得手段と、
前記管理サーバーから取得された前記第２情報を、前記第１取得手段により取得された連携先鍵を用いて復号して前記コンテンツ鍵及び前記認可情報を取得する第２取得手段と、
前記第２取得手段により取得された認可情報に応じた権限の範囲内で、前記管理サーバーから取得された前記第１情報を、前記第２取得手段により取得されたコンテンツ鍵を用いて復号して前記医療情報を取得する第３取得手段と、
を備える医療情報管理システム。 - 前記連携先鍵は、ユーザー毎に用意されたユーザー鍵、前記クライアント端末毎に用意された端末鍵、又は、前記医療情報に係る患者毎に用意された患者鍵である請求項１に記載の医療情報管理システム。
- 前記認可情報には、さらに、前記医療情報の有効期間又は認可種別が含まれる請求項１又は２に記載の医療情報管理システム。
- 前記複数のクライアント端末のそれぞれは、
前記第２取得手段により取得された認可情報において暗号化出力が認可されている場合に、前記管理サーバーから取得された前記第１情報及び前記第２情報を記録メディアに書き込む書込手段を備える請求項１から３のいずれか一項に記載の医療情報管理システム。 - 複数の医療施設に設置された複数のクライアント端末とデータ通信可能に接続され、前記複数の医療施設において生成された医療情報を管理する管理サーバーであって、
前記医療情報毎に、公開先を含む認可情報を記憶する第１記憶手段と、
前記公開先の候補となる前記医療情報を共有する連携先毎に、連携先鍵を記憶する第２記憶手段と、
前記複数のクライアント端末のいずれかから前記医療情報のダウンロード要求があった場合に、当該医療情報がダウンロードされる度にコンテンツ鍵を生成し、当該医療情報を当該生成されたコンテンツ鍵を用いて暗号化して第１情報を生成する第１生成手段と、
前記コンテンツ鍵及び当該コンテンツ鍵により暗号化された医療情報に対応する認可情報を、当該認可情報に含まれる公開先に対応する連携先鍵を用いて暗号化して第２情報を生成する第２生成手段と、
前記ダウンロード要求があったクライアント端末に前記第１情報及び前記第２情報を提供する提供手段と、
を備える管理サーバー。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015206842A JP6561761B2 (ja) | 2015-10-21 | 2015-10-21 | 医療情報管理システム及び管理サーバー |
| US15/286,183 US20170116375A1 (en) | 2015-10-21 | 2016-10-05 | Medical information management system and management server |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015206842A JP6561761B2 (ja) | 2015-10-21 | 2015-10-21 | 医療情報管理システム及び管理サーバー |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2017078973A JP2017078973A (ja) | 2017-04-27 |
| JP6561761B2 true JP6561761B2 (ja) | 2019-08-21 |
Family
ID=58559098
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015206842A Active JP6561761B2 (ja) | 2015-10-21 | 2015-10-21 | 医療情報管理システム及び管理サーバー |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20170116375A1 (ja) |
| JP (1) | JP6561761B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2019036221A (ja) * | 2017-08-19 | 2019-03-07 | 栗原 智之 | 医療連携システム |
| CN110519315A (zh) * | 2018-05-21 | 2019-11-29 | 陈立新 | 文件远控系统 |
| TWI690823B (zh) * | 2018-05-21 | 2020-04-11 | 立新 陳 | 文件遠控系統 |
| US11437150B2 (en) * | 2018-05-31 | 2022-09-06 | Inspire Medical Systems, Inc. | System and method for secured sharing of medical data generated by a patient medical device |
| CN109508556A (zh) * | 2018-09-27 | 2019-03-22 | 量子云未来（北京）信息科技有限公司 | 一种应用于医疗行业的文件存储及传输方法及系统 |
| CN109548018B (zh) * | 2019-01-11 | 2021-11-23 | 腾讯科技（深圳）有限公司 | 无线网络接入方法、装置、设备及系统 |
| CN109981282A (zh) * | 2019-01-28 | 2019-07-05 | 平安科技（深圳）有限公司 | 提高影像数据传输安全的方法、装置、系统及存储介质 |
| US11182086B2 (en) * | 2019-07-19 | 2021-11-23 | Cignet Technology, Inc. | Method and system for application-based management of user data storage rights |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5892900A (en) * | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
| US6226618B1 (en) * | 1998-08-13 | 2001-05-01 | International Business Machines Corporation | Electronic content delivery system |
| JP2000293603A (ja) * | 1999-04-09 | 2000-10-20 | Hitachi Ltd | 地域医療情報システム及び電子患者カード |
| US20020004727A1 (en) * | 2000-07-03 | 2002-01-10 | Knaus William A. | Broadband computer-based networked systems for control and management of medical records |
| JP2002251328A (ja) * | 2000-11-02 | 2002-09-06 | Hitachi Ltd | コンテンツ蓄積管理方法 |
| JP4634751B2 (ja) * | 2004-07-08 | 2011-02-16 | 株式会社東芝 | 記憶媒体処理方法、記憶媒体処理装置及びプログラム |
| JP4161043B2 (ja) * | 2005-01-31 | 2008-10-08 | 三洋電機株式会社 | コンテンツ利用情報記憶装置 |
| US20090254997A1 (en) * | 2005-09-21 | 2009-10-08 | Fathy Fouad Yassa | Method and apparatus for content rights management |
| US20090193267A1 (en) * | 2008-01-28 | 2009-07-30 | Chiasen Chung | Secure electronic medical record storage on untrusted portal |
| US20160117448A1 (en) * | 2013-06-28 | 2016-04-28 | Koninklijke Philips N.V. | System for managing access to medical data |
| US9467450B2 (en) * | 2013-08-21 | 2016-10-11 | Medtronic, Inc. | Data driven schema for patient data exchange system |
-
2015
- 2015-10-21 JP JP2015206842A patent/JP6561761B2/ja active Active
-
2016
- 2016-10-05 US US15/286,183 patent/US20170116375A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20170116375A1 (en) | 2017-04-27 |
| JP2017078973A (ja) | 2017-04-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6561761B2 (ja) | 医療情報管理システム及び管理サーバー | |
| US11087021B2 (en) | Secure access to individual information | |
| US11144660B2 (en) | Secure data sharing | |
| US11531781B2 (en) | Encryption scheme for making secure patient data available to authorized parties | |
| US10249386B2 (en) | Electronic health records | |
| US20220198419A1 (en) | System and method for managing payments for accessing patients' information | |
| US9390228B2 (en) | System and method for securely storing and sharing information | |
| US20090193267A1 (en) | Secure electronic medical record storage on untrusted portal | |
| EP2329424B1 (en) | System and method of encryption for dicom volumes | |
| JP2016529768A (ja) | 医療データへのアクセスを管理するシステム | |
| US20170091464A1 (en) | Systems and methods for linking medical records with images for distribution | |
| US10893027B2 (en) | Secure access to individual information | |
| US11343330B2 (en) | Secure access to individual information | |
| EP3219048A1 (en) | System and method for securely storing and sharing information | |
| US20180032684A1 (en) | Accessing an interoperable medical code | |
| WO2021067141A1 (en) | System and method for providing access of a user's health information to third parties | |
| US11361257B2 (en) | Method and system for managing diagnostic imaging orders | |
| JP2006113704A (ja) | 医用システムのパスワード管理方法及び医用装置用パスワード管理システム | |
| KR102350614B1 (ko) | 블록체인 레지스트리를 이용한 건강데이터 교류 시스템 및 방법과 이를 수행하기 위한 프로그램을 기록한 기록매체 | |
| KR20220015073A (ko) | 유비쿼터스 환경을 이용한 의료 정보 공유 전산시스템 및 방법 | |
| Gawlik et al. | Requirements for Integrating End-to-End Security into Large-Scale EHR Systems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180910 |
|
| TRDD | Decision of grant or rejection written | ||
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20190531 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20190625 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20190708 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6561761 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |