JP6078459B2 - 情報管理システムとそのデータ連携方法 - Google Patents

Description

この発明は、例えば地域の医療機関や保健関連機関相互間で、患者の診療情報を通信ネットワークを介して受け渡し、これにより紹介先の医師が患者の診療情報を参照できるようにする情報管理システムとこのシステムで使用されるデータ連携方法に関する。

患者の病状に応じて、地域の医療機関がそれぞれの特徴を生かして機能分担を図り、医療機関間で連携することにより、地域全体で患者を中心にした医療サービスを提供する取り組みが進められている。この地域医療の連携を実現するために、地域内のある病院が保存する患者の診療データを、必要に応じて他病院や診療所の医師が閲覧できるような仕組みとして、ＥＨＲ（Electronic Health Record）がある。

Ａ病院及びＢ病院が医療連携に参加している地域において、Ａ病院に所属するある医療従事者Ｘが、Ｂ病院で受診した患者の診療情報を閲覧する場合には、医療従事者ＸがＢ病院のサーバにアクセスできるようにする必要がある。この場合、Ｂ病院側で誰がアクセスしたのかを識別するために、Ａ病院に所属する医療従事者ＸのアカウントをＢ病院側のシステムにも用意する必要があり、運用が煩雑になることが懸念されていた。

これを解決するために、複数の病院のデータサーバに一度の認証手続きでアクセスできるようにするために、ＩＤ連携型のシングルサインオンを用いて、患者データに対し安全にアクセスできるようにする手法が提案されている（例えば特許文献１を参照）。この手法を用いれば、各病院のデータサーバが独自に管理するユーザＩＤを知らせ合うことなく、データサーバ間で患者等のユーザの個別情報を転送して、ＩＤ連携を実現することができる。

また、セキュリティの観点から、データサーバ間のユーザＩＤ連携用に仮名(かめい)を利用するシステムも提案されている（例えば特許文献２を参照）。このシステムは、ユーザを認証してユーザの身元を管理するユーザ認証・管理サーバと、ユーザに様々なサービスを提供するサービス提供サーバを備え、各データサーバが独自に管理するユーザＩＤをユーザ認証・管理サーバにより仮名を介して変換することにより、ユーザＩＤの連携を実施する。仮名を使う理由は、実ユーザのＩＤの漏洩を防ぐと共に、各々のサーバに存在するユーザＩＤ同士を紐付けすることによって発生する個人情報の漏洩を防ぐためである。

特開２００７−２９９３０３号公報 特開２０１３−２９８８６号公報

ところが、特許文献１に記載された手法では、各病院のデータサーバ間でユーザＩＤをやり取りしながら連携しなければならないため、ユーザＩＤの連携に煩わしさがある。一方、特許文献２に記載されたシステムでは、ユーザ数にサービスサーバ数を乗じた膨大な数の仮名を登録し運用することになり、仮名とそれに紐付けられるユーザＩＤの維持管理に多くの手間と時間が必要となる。また、システムを使うかどうかわからない医療従事者のユーザＩＤを登録しておくことは、セキュリティ上非常に好ましくない。

この発明は上記事情に着目してなされたもので、その目的とするところは、仮名の登録数を減らし、これにより仮名とそれに紐付けられるユーザＩＤの維持管理に要する負荷の軽減を図った情報管理システムとこのシステムで使用されるデータ連携方法を提供することにある。

上記目的を達成するためにこの発明は以下の態様を備えることを特徴とする。
（１）管理対象のユーザの各々に対しその個別情報及び個別ユーザＩＤを独自に管理する第１及び第２のデータサーバと、これら第１及び第２のデータサーバと通信ネットワークを介して通信可能な連携サーバとを具備する情報管理システムにあって、
前記第１及び第２のデータサーバは、自サーバ以外のデータサーバが管理するユーザ群をゲストユーザと定義して、このゲストユーザに対しゲストユーザＩＤを発行し記憶する手段を備え、
前記連携サーバは、前記管理対象ユーザ及びゲストユーザについて、当該各ユーザをシステム全体で共通に管理するための共通ユーザＩＤを発行すると共に、前記各ユーザについて自サーバが第１及び第２のデータサーバと個別に通信を行うための通信用識別子を発行し、前記発行された共通ユーザＩＤと通信用識別子とを相互に関連付けた第１の連携情報を生成して記憶する手段を備え、
前記第１及び第２のデータサーバは、前記管理対象ユーザ及びゲストユーザについて前記連携サーバにより発行された通信用識別子を当該連携サーバから受信する手段と、前記受信された通信用識別子と、前記各ユーザについて自サーバが独自に管理する個別ユーザＩＤ及びゲストユーザＩＤとを相互に関連付けた第２の連携情報を生成して記憶する手段とを備え、
前記第１のデータサーバで管理されているユーザが前記第２のデータサーバで管理されている他のユーザの個別情報に対しアクセスする際に、
前記連携サーバは、前記第１のデータサーバから送られるアクセス元ユーザ及びアクセス先となる他のユーザに関するアサーション取得要求に応じて、第２のデータサーバで定義されたゲストユーザ及びアクセス先となる他のユーザに対しそれぞれ発行された通信用識別子を前記第１の連携情報から検索し、当該検索された各通信用識別子を含むアサーション情報を取得要求元の第１のデータサーバへ返送する通信用識別子変換処理を行い、
前記第１のデータサーバは、前記他のユーザの個別情報に対するデータアクセス要求を、前記連携サーバから返送されたアサーション情報と共に第２のデータサーバへ送信し、
前記第２のデータサーバは、前記第１のデータサーバから送られたデータアクセス要求及びアサーション情報を受信すると、当該受信されたアサーション情報に含まれる各通信用識別子をもとに、ゲストユーザＩＤ及びアクセス先ユーザの個別ユーザＩＤを前記第２の連携情報から検索し、当該検索された各ユーザＩＤと前記受信されたアサーション情報とに基づいて前記アクセス先ユーザの個別情報に対するアクセス処理を実行するようにしたものである。

（２）前記連携サーバは、前記通信用識別子の変換の可否を判定するための変換ルールを記憶する手段をさらに備え、前記第１のデータサーバから送られたアサーション取得要求に含まれるアクセス元ユーザの属性情報が前記記憶された変換ルールを満たすか否かを判定し、変換ルールを満たすと判定された場合に、前記第２のデータサーバのゲストユーザについて発行された通信用識別子を、前記記憶された第１の連携情報から検索するようにしたものである。

（３）前記第２のデータサーバは、管理対象のユーザごとにその個別ユーザＩＤに関連付けて当該管理対象ユーザの個別情報に対するアクセス条件を記憶する手段を備え、前記データアクセス要求を受信した場合に、当該データアクセス要求と共に受信したアサーション情報に含まれるアクセス元ユーザの属性情報が前記記憶されたアクセス条件を満たすか否かを判定し、アクセス条件を満たすと判定された場合に、前記データアクセス要求により指定された管理対象ユーザの個別情報に対するアクセス処理を実行するようにしたものである。

（４）前記第１及び第２のデータサーバ及び前記連携サーバの各々は、前記アサーション取得要求の発生から管理対象ユーザの個別情報に対するアクセス処理の終了までに自サーバ内で実行された処理を表すセッション情報、及び当該処理の実行単位を表すスレッド情報を含むログ情報を生成して記憶する手段をさらに備えるようにしたものである。

（５）管理対象のユーザの各々に対しその個別情報及び個別ユーザＩＤを独自に管理する第１及び第２のデータサーバと、これら第１及び第２のデータサーバと通信ネットワークを介して通信可能な連携サーバとを具備する情報管理システムにあって、
前記連携サーバは、前記管理対象のユーザについて、当該ユーザをシステム全体で共通に管理するための共通ユーザＩＤを発行すると共に、前記ユーザについて自サーバが第１及び第２のデータサーバと個別に通信を行うための通信用識別子を発行し、前記発行された共通ユーザＩＤと通信用識別子とを相互に関連付けた第１の連携情報を生成して記憶する手段を備え、
前記第１及び第２のデータサーバは、前記管理対象のユーザについて前記連携サーバにより発行された通信用識別子を当該連携サーバから受信する手段と、前記受信された通信用識別子と、前記ユーザについて自サーバが独自に管理する個別ユーザＩＤとを相互に関連付けた第２の連携情報を生成して記憶する手段とを備え、
前記第１のデータサーバで管理されているユーザが前記第２のデータサーバで管理されている他のユーザの個別情報に対しアクセスする際に、
前記連携サーバは、前記第１のデータサーバから送られるアクセス元ユーザ及びアクセス先となる他のユーザに関するアサーション取得要求に応じて、第２のデータサーバにおけるアクセス先となる他のユーザについて発行された通信用識別子を前記第１の連携情報から検索すると共に、前記アクセス元ユーザに対し通信用識別子を一時的に発行し、当該検索及び発行された通信用識別子を含むアサーション情報を取得要求元の第１のデータサーバへ返送する通信用識別子の変換処理を行い、
前記第１のデータサーバは、前記他のユーザの個別情報に対するデータアクセス要求を、前記連携サーバから返送されたアサーション情報と共に第２のデータサーバへ送信し、
前記第２のデータサーバは、前記第１のデータサーバから送られたデータアクセス要求及びアサーション情報を受信すると、当該受信されたアサーション情報に含まれる各通信用識別子をもとにアクセス先ユーザの個別ユーザＩＤを前記第２の連携情報から検索し、当該検索されたユーザＩＤと前記受信されたアサーション情報とに基づいて前記アクセス先ユーザの個別情報に対するアクセス処理を実行するようにしたものである。

この発明の各態様によれば以下のような効果が奏せられる。
（１）第１及び第２のデータサーバでは、自サーバ以外のデータサーバが管理するユーザ群がゲストユーザとして定義され、このゲストユーザに対しゲストユーザＩＤが発行される。また、それに応じて連携サーバでは、上記第１及び第２のデータサーバでそれぞれ定義されたゲストユーザに対し通信用識別子が発行されて記憶される。そして、第１のデータサーバから第２のデータサーバが管理しているユーザの個別情報に対しアクセスする際には、第１のデータサーバの要求に応じ、上記第２のデータサーバにおいて定義されたゲストユーザの通信用識別子が連携サーバから第１のデータサーバに通知される。そして、第１のデータサーバから第２のデータサーバに対し、データアクセス要求が上記通知されたゲストユーザの通信用識別子を含むアサーション情報と共に送られ、第２のデータサーバではこの送られたアサーション情報に含まれる通信用識別子をもとにゲストユーザＩＤが特定され、当該ゲストユーザＩＤがアクセス元としてアクセス先ユーザの個別情報のアクセス処理が実行される。すなわち、第１のデータサーバから第２のデータサーバの個別情報に対しアクセスする場合に、アクセス元ユーザの通信用識別子はアクセス先のデータサーバのゲストユーザ用の通信用識別子に置き換えられる。

したがって、全データサーバにおいてすべてのユーザのユーザＩＤをそれぞれ管理し、それに応じて連携サーバが上記すべてのユーザＩＤに対し通信用識別子を発行しこれを維持管理する場合に比べ、連携サーバが管理する通信用識別子の数を減らすことが可能となり、これにより通信用識別子とそれに紐付けられるユーザＩＤの維持管理に要する負荷を軽減することが可能となる。また、データサーバごとにゲストユーザを定義することで、システムを使うかどうかわからないユーザのユーザＩＤを全データサーバが管理する必要がなくなる。このため、システムを使用しないユーザのＩＤの漏洩を未然に防止することが可能となり、これによりユーザＩＤの管理に対するセキュリティを高めることができる。

（２）連携サーバにおいて、通信用識別子の変換の可否を判定するための変換ルールが設定され、アクセス元ユーザの属性情報が当該変換ルールを満たすか否かが判定され、変換ルールを満たすと判定された場合にアクセス元ユーザ用の通信用識別子がゲストユーザの通信用識別子に変換される。このため、予め設定した属性情報を持つユーザ以外はゲストユーザとして認定しないようにすることができ、これにより例えば予め定めた組織に属しかつ適切な資格を有するユーザだけがゲストユーザとしてデータアクセスを行うことが可能となる。

（３）データサーバおいて、ユーザごとにそのユーザＩＤに関連付けて当該ユーザの個別情報に対するアクセス条件が設定され、データアクセス要求を受信した場合に、アクセス元ユーザの属性情報が上記アクセス条件を満たすと判定された場合にのみ、上記データアクセス要求により指定されたアクセス先ユーザの個別情報に対するアクセス処理が実行される。このため、例えば患者ごとに設定したその診療情報の開示条件を満たすアクセス元ユーザに対してのみ、当該診療情報が開示される。したがって、個別情報に対するアクセス元を適切に制限することができる。

（４）第１及び第２のデータサーバ及び連携サーバでは、ユーザの個別情報に対するアクセス処理が行われるごとに、そのセッション情報及びスレッド情報を含むログ情報が生成されて記憶される。このため、上記ユーザの個人情報に対するアクセスが行われた場合に、どのユーザがどのユーザの個人情報に対しどのようなアクセスを行ったかを、記憶されたログ情報のセッション情報及びスレッド情報を追跡することで特定することが可能となる。すなわち、各データサーバが自サーバで管理していないユーザをゲストユーザとして受け付けても、アクセス元のユーザを確実に特定することが可能となる。

（５）前記第１のデータサーバで管理されているユーザが前記第２のデータサーバで管理されている他のユーザの個別情報に対しアクセスする際に、連携サーバでは、第１のデータサーバの要求に応じ、アクセス元ユーザに対し第２のデータサーバとの連携用の通信用識別子が一時的に発行され、第１のデータサーバに通知される。そして、第１のデータサーバから第２のデータサーバに対し、上記一時的に発行された通信用識別子を含むアサーション情報がデータアクセス要求と共に送られ、第２のデータサーバではこの送られたアサーション情報に含まれる一時的な通信用識別子をもとにアクセス元ユーザが管理される。すなわち、第１のデータサーバから第２のデータサーバの個別情報に対しアクセスする場合に、アクセス元ユーザの通信用識別子は第２のデータサーバ用として一時的に発行された通信用識別子に置き換えられる。

したがって、前記（１）と同様に、全データサーバにおいてすべてのユーザのユーザＩＤをそれぞれ管理し、それに応じて連携サーバが上記すべてのユーザＩＤに対し通信用識別子を発行しこれを維持管理する場合に比べ、連携サーバが管理する通信用識別子の数を減らすことが可能となり、これにより通信用識別子とそれに紐付けられるユーザＩＤの維持管理に要する負荷を軽減することが可能となる。このため、システムを使用しないユーザのＩＤの漏洩を未然に防止することが可能となり、これによりユーザＩＤの管理に対するセキュリティを高めることができる。

すなわちこの発明によれば、仮名の登録数を減らし、これにより仮名とそれに紐付けられるユーザＩＤの維持管理に要する負荷の軽減を図った情報管理システムとこのシステムで使用されるデータ連携方法を提供することができる。

この発明の一実施形態に係る情報管理システムの概略構成図。 図１に示したシステムで使用される連携サーバの機能構成を示すブロック図。 図１に示したシステムで使用されるアクセス元の病院公開サーバの機能構成を示すブロック図。 図１に示したシステムで使用されるアクセス先の病院公開サーバの機能構成を示すブロック図。 ユーザのユーザＩＤ及び仮名をアクセス元及びアクセス先の各病院公開サーバでそれぞれ管理する場合の各サーバによるデータ保有例を示す図。 ゲストユーザ用の仮名方式を用いた場合の各サーバによるデータ保有例を示す図。 一時的に発行される仮名を用いる場合の各サーバによるデータ保有例を示す図。 連携サーバが保持する変換ルール設定ファイルの一例を示す図。 ゲストユーザ用の仮名方式を用いた場合のアクセス処理手順と処理内容の前半部分を示すフローチャート。 ゲストユーザ用の仮名方式を用いた場合のアクセス処理手順と処理内容の後半部分を示すフローチャート。 一時的に発行される仮名を使用する場合のアクセス処理手順と処理内容の前半部分を示すフローチャート。 一時的に発行される仮名を使用する場合のアクセス処理手順と処理内容の後半部分を示すフローチャート。

以下、図面を参照してこの発明に係わる実施形態を説明する。
［一実施形態］
（構成）
図１は、この発明の一実施形態に係る情報管理システムの概略構成図である。
このシステムは連携サーバＳＶ０を備え、病院等の医療機関が独自に運用する複数の病院公開サーバＳＶ１〜ＳＶｎが通信ネットワークＮＷを介して上記連携サーバＳＶ０との間で通信可能としたものである。通信ネットワークとしては、例えばＩＰ（Internet Protocol）網が用いられる。なお、ＵＴ０は連携サーバＳＶ０に接続されるシステム運用者用の運用者端末を示し、またＵＴ１〜ＵＴｎは病院公開サーバＳＶ１〜ＳＶｎにそれぞれ接続される、医師や看護師等の医療従事者が使用するユーザ端末を示している。

（１）連携サーバＳＶ０
連携サーバＳＶ０はサービス事業者や自治体等が運用するもので、図２に示すように、処理ユニット１０と、情報格納ユニット１１と、変換ルール設定ファイル記憶部１２と、通信インタフェースユニット１３と、ユーザインタフェースユニット１４とを備えている。なお、変換ルール設定ファイル記憶部１２は、情報格納ユニット１１とは別に設けずに、情報格納ユニット１１内に設けるようにしてもよい。

通信インタフェースユニット１３は、処理ユニット１０の制御の下で、通信ネットワークＮＷで規定された通信プロトコルに従い、各病院公開サーバＳＶ１〜ＳＶｎとの間で認証やＩＤ連携、アクセス制御のための各種制御データを送受信する機能を有する。

ユーザインタフェースユニット１４には、システム運用者が操作する運用者端末ＵＴ０が接続される。ユーザインタフェースユニット１４は、運用者端末ＵＴ０において入力された操作データを取り込んで処理ユニット１０に通知する機能と、処理ユニット１０から出力された各種表示データを運用者端末ＵＴ０へ出力して表示させる機能を有する。

情報格納ユニット１２は、記憶媒体としてＨＤＤやＳＳＤ等の随時書込み読出しが可能な不揮発性記憶媒体を使用したもので、この発明の一実施形態を実施するために必要な記憶部として、ユーザ情報格納部１１１と、ＩＤ連携情報格納部１１２と、アクセス制御ルールを記憶するアクセス制御情報格納部１１３と、ログ情報を管理するログ情報格納部１１４を備えている。

ユーザ情報格納部１１１はユーザ情報管理テーブルを記憶する。ユーザ情報管理テーブルには、システムを利用する各ユーザの属性情報が格納される。属性情報は、ユーザに対し発行されたシステム共通のユーザＩＤに対し、当該ユーザの姓名、所属組織、内部組織及び保有資格等を関連付けたものである。

ＩＤ連携情報格納部１１２はＩＤ連携情報管理テーブルを記憶する。ＩＤ連携情報管理テーブルには、ユーザごとにそのシステム共通のユーザＩＤに関連付けて、仮名と、連携先を表す病院公開サーバの識別情報が格納される。仮名とは、各病院公開サーバＳＶ１〜ＳＶｎがユーザに対し独自に割り当てた個別ユーザＩＤに対し、連携サーバＳＶ０が発行した通信用識別子であり、病院公開サーバＳＶ１〜ＳＶｎ間で患者ユーザの診断情報にアクセス（操作）する際に個別ユーザＩＤの代わりに使用される。

アクセス制御情報格納部１１３は、患者ユーザの診療情報に対するアクセス制御ルールを表す情報をアクセス制御リストとして記憶する。このアクセス制御リストは、患者の共通ユーザＩＤ（データオーナＩＤ）に対し、当該患者の診療情報の識別情報と、開示相手を表す情報と、読み出し／書込みの許否を表す情報（Ｒ／Ｗ）とを関連付けたものからなる。

ログ情報格納部１１４は、ユーザの個別情報に対するアクセス処理が行われるごとに後述する制御ユニット１０で生成されるログ情報を格納するために使用される。ログ情報は、ユーザの個別情報に対するアクセス処理が行われるごとに、そのときのセッションＩＤ及びスレッドＩＤを時系列で記録したものである。

なお、セッションとは、コンピュータシステムやネットワーク通信において、接続／ログインから、切断／ログオフするまでの一連の操作や通信のことを指す。特にＷｅｂの分野では、アクセス数の単位の一つで、Ｗｅｂサイトを訪れたユーザがサイト内で行う一連の行動をまとめて１セッションという。これを判別するために、サーバ側から発行されるのがセッションＩＤである。スレッドとは、ソフトウェアやプログラミング等の分野で、並列処理に対応したＯＳ（Operating System）上でのプログラムの最小の実行単位であり、各スレッドにはスレッドを一意に識別するためのＩＤが付与される。

変換ルール設定ファイル記憶部１２には、仮名の変換ルールが記憶される。変換ルールは、病院の医療従事者が、他病院が保存する患者の診療情報に対しアクセスする際に、アクセス元の医療従事者ユーザの仮名をゲストユーザ用の仮名もしくは一時的に払い出される仮名に置き換えるためのルールを記述したものであり、ユーザの組織、内部組織及び資格により定義される。図８はその一例を示すものである。

処理ユニット１０は、ＣＰＵ（Central Processing Unit）を備え、この発明の実施形態を実施するために必要な処理機能として、Ｗｅｂアクセス受付部１０１と、認証・ＩＤ連携処理部１０２と、アクセス制御判定部１０３と、リモートデータアクセス処理部１０４と、データ操作処理部１０５と、ログ出力部１０６を有している。これらの処理部は、何れも図示しないプログラムメモリに格納されたアプリケーション・プログラムを上記ＣＰＵに実行させることにより実現される。

Ｗｅｂアクセス受付部１０１は、ユーザインタフェースユニット１４を介して運用者端末ＵＴ０からの要求を受け付ける処理を行う。

認証・ＩＤ連携処理部１０２は、以下の処理機能を有する。
(1) 病院公開サーバＳＶ１〜ＳＶｎから認証要求が送られた場合に、当該要求元のサーバＳＶ１〜ＳＶｎに接続されたユーザ端末ＵＴ１〜ＵＴｎに認証画面を表示させ、この認証画面においてユーザが入力したユーザＩＤ等をもとに認証処理を実行する。そして、認証が終了すると、ユーザ情報格納部１１１及びＩＤ連携情報格納部１１２から当該ユーザに関する情報を読み出し、当該ユーザの仮名、所属組織、内部組織及び保有資格を含むアサーション情報を生成して、要求元のサーバＳＶ１〜ＳＶｎに返却する処理を行う。

(2) 病院公開サーバＳＶ１〜ＳＶｎからユーザＩＤ連携要求が通知された場合に、連携サーバＳＶ０と連携対象となる病院公開サーバとの間の通信に使用する通信識別子（仮名）を発行する。そして、この発行された仮名と、上記ユーザＩＤ連携要求により引数として与えられた共通ユーザＩＤを、ＩＤ連携情報格納部１１２に記憶させる。またそれと共に、上記発行された仮名を連携対象となる病院公開サーバＳＶ１〜ＳＶｎに返却し、当該仮名と連携対象となるサーバＳＶ１〜ＳＶｎの連携用ユーザＩＤ又はゲストユーザ用のゲストユーザＩＤとを関連付けて、当該病院公開サーバＳＶ１〜ＳＶｎのＩＤ連携用データ記憶部に記憶させる処理を行う。

リモートデータアクセス処理部１０４は、ネットワークＮＷ経由で病院公開サーバＳＶ１〜ＳＶｎにアクセスする処理を行う。データ操作処理部１０５は、自サーバＳＶ０内におけるデータを操作する処理を行う。

アクセス制御判定部１０３は、データ操作処理部１０５から各種要求が発生した場合に、当該要求に含まれる属性情報がアクセス制御情報記憶部１１３に記憶されたアクセス制御ルールに合致しているかどうかを判定し、その判定結果を返却する処理を行う。

ログ出力部１０６は、アクセス元の病院公開サーバＳＶ１〜ＳＶｎからアサーション取得要求を受信してからユーザの個別情報に対するアクセスが終了するまでに自サーバ内で実行された処理を表すセッションＩＤ、及び当該処理の実行単位を表すスレッドＩＤを含むログ情報を生成し、この生成されたログ情報をログ情報格納部１１４に記憶させる処理を行う。

（２）病院公開サーバＳＶ１〜ＳＶｎ
病院公開サーバＳＶ１〜ＳＶｎには、患者情報に対するアクセス元（患者情報の紹介先）となる病院のサーバと、患者情報のアクセス先（患者情報の紹介元）となる病院のサーバが含まれ、これらのサーバは一部異なる機能を備える。なお、全ての病院公開サーバＳＶ１〜ＳＶｎが、患者情報に対するアクセス元となる機能と患者情報のアクセス先となる機能の両方を備えてもよい。

（２−１）患者情報に対するアクセス元となる病院のサーバＳＶ１
患者情報に対するアクセス元となる病院のサーバＳＶ１は、図３に示すように、処理ユニット２０と、記憶ユニット２１と、通信インタフェースユニット２３と、ユーザインタフェースユニット２４とを備えている。

通信インタフェースユニット２３は、処理ユニット２０の制御の下で、通信ネットワークＮＷにより規定される通信プロトコルに従い、連携サーバＳＶ０及び他の病院公開サーバＳＶ２〜ＳＶｎとの間で認証やＩＤ連携、アクセス制御等のための各種制御データを送受信する機能を有する。

ユーザインタフェースユニット２４には、医師や保健師、看護師等の医療従事者が操作するユーザ端末ＵＴ１が接続される。ユーザインタフェースユニット２４は、ユーザ端末ＵＴ１において入力された操作データを取り込んで処理ユニット２０に通知する機能と、処理ユニット２０から出力された各種表示データをユーザ端末ＵＴ１へ出力して表示させる機能を有する。

記憶ユニット２１は記憶媒体としてＨＤＤやＳＳＤ等の随時書込み読出しが可能な不揮発性記憶媒体を使用したもので、この発明の一実施形態を実施するために必要な記憶部として、患者ユーザ情報格納部２１１と、医療従事者情報格納部２１２と、ＩＤ連携情報格納部２１３と、アクセス制御情報格納部２１４と、診療情報格納部２１５と、ログ情報格納部２１６を備えている。

患者ユーザ情報格納部２１１は、患者ユーザ情報管理テーブルを記憶する。患者ユーザ情報管理テーブルには、当該病院が管理する患者ごとに当該病院公開サーバＳＶ１が独自に発行した患者のユーザＩＤに関連付けて、当該患者の姓名、住所などの属性情報が記憶される。図６に医療従事者情報の一例を示す。

医療従事者情報格納部２１２は、医療従事者情報管理テーブルを記憶する。この医療従事者情報管理テーブルには、当該病院に所属する医師や保健師、看護師等の医療従事者に対し当該病院公開サーバＳＶ１が独自に発行したユーザＩＤに関連付けて、当該医療従事者の氏名、住所等の属性情報が記憶される。図６に医療従事者情報の一例を示す。

ＩＤ連携情報格納部２１３は、病院独自のＩＤ連携情報管理テーブルを記憶する。このＩＤ連携情報管理テーブルには、当該病院が管理する医療従事者や患者等のユーザに対して当該病院公開サーバＳＶ１が独自に発行した連携用のユーザＩＤに関連付けて、前記連携サーバＳＶ０により発行された通信用識別子（仮名）が記憶される。図６にその記憶データの一例を示す。

アクセス制御情報格納部２１４は、当該病院が管理する患者の診療情報に対するアクセス制御ルールを表すアクセス制御情報管理テーブルを格納する。アクセス制御情報管理テーブルには、患者のユーザＩＤに関連付けて許可対象のアクセス（操作）の種類と、一つ又は複数の開示条件が記憶される。アクセスの種類には、例えば参照（閲覧）、変更、追加、削除等の複数種類の操作が含まれる。

診療情報記憶部２１５は、当該病院が独自に管理する患者の個別データ（例えば診療情報）を記憶するために用いられる。診療情報には電子カルテのデータや検査データ、診断画像データ、処方箋データ等が含まれる。

ログ情報格納部２１６は、患者ユーザの診療情報に対するアクセス（操作）が行われるごとに後述する制御ユニット２０で生成されるログ情報を格納するために使用される。ログ情報は、患者ユーザの診療情報に対するアクセス（操作）が行われるごとに、そのときのセッションＩＤ及びスレッドＩＤを記録したものである。

処理ユニット２０はＣＰＵ（Central Processing Unit）を備え、この発明の一実施形態を実施するために必要な処理機能として、Ｗｅｂアクセス受付部２０１と、認証・ＩＤ連携処理部２０２と、アクセス制御判定部２０３と、リモートデータアクセス処理部２０４と、データ操作処理部２０５と、ログ出力部２０６を有している。これらの処理部は、何れも図示しないプログラムメモリに格納されたアプリケーション・プログラムを上記ＣＰＵに実行させることにより実現される。

Ｗｅｂアクセス受付部２０１は、ユーザ端末ＵＴ１における操作情報をユーザインタフェースユニット２４を介して受け付ける処理を行う。

データ操作処理部２０５は、ユーザ端末ＵＴ１おいて医療従事者により他の病院公開サーバＳＶ２〜ＳＶｎが保有する患者の診療情報に対するアクセスを要求する操作が行われた場合に、その要求をＷｅｂアクセス受付部２０１から受け取り、アクセス先となる患者とアクセス元となる医療従事者のアクセス先サーバにおけるアサーション情報の取得要求を認証・ＩＤ連携処理部２０２へ出力する。そして、認証・ＩＤ連携処理部２０２から上記アサーション情報が返送されると、当該アサーション情報をもとに患者の診察情報に対するアクセス要求をリモートデータアクセス処理部２０４へ出力する処理を行う。

認証・ＩＤ連携処理部２０２は、以下の処理機能を有する。
(1) ユーザ端末ＵＴ１においてログイン操作が行われた場合に連携サーバＳＶ０へ認証要求を送信し、この要求に対し連携サーバＳＶ０から送られる認証画面をユーザ端末ＵＴ１に表示させる。そして、この認証画面においてユーザが入力した認証に必要なデータを連携サーバＳＶ０へ送信し、その認証結果を表す情報（認証トークン）を連携サーバＳＶ０から受信する処理を行う。一度この認証手順が完了すると、以後連携サーバＳＶ０への問い合わせや認証行為なしでのログイン操作、つまりシングルサインオンが可能になる。

(2) データ操作処理部２０５からアサーション情報の取得要求を受け取ると、当該取得要求を連携サーバＳＶ０へ送信する。そして、この取得要求に対し連携サーバＳＶ０からアクセス先サーバにおける仮名と属性情報を含むアサーション情報が返送されると、この返送されたアサーション情報を上記データ操作処理部２０５に返送する処理を行う。

アクセス制御判定部２０３は、上記各要求がアクセス制御情報格納部２１４に格納されたアクセス制御ルールに合致しているかどうかを判定する。リモートデータアクセス処理部２０４は、上記データ操作処理部２０５から患者の診察情報に対するアクセス要求を受け取った場合に、データ取得要求を通信インタフェースユニット２３からネットワークＮＷを介してアクセス先の病院公開サーバＳＶ２〜ＳＶｎへ送信する処理と、アクセス先の病院公開サーバＳＶ２〜ＳＶｎから患者の診療情報が送られた場合にこの情報を通信インタフェースユニット２３を介して受信する処理を行う。

ログ出力部２０６は、アクセス元のユーザ端末ＵＴ１から他の病院公開サーバが管理する患者の診療情報に対するアクセス要求を受信してから、当該患者の診療情報を受信するまでに、自サーバ内で実行された処理を表すセッションＩＤ、及び当該処理の実行単位を表すスレッドＩＤを含むログ情報を生成し、この生成されたログ情報をログ情報格納部２１６に記憶させる処理を行う。

（２−２）患者情報のアクセス先（紹介元）となる病院の公開サーバＳＶ２
患者のアクセス先となる病院の病院公開サーバＳＶ２は、図４に示すように、処理ユニット３０と、記憶ユニット３１と、通信インタフェースユニット３３と、ユーザインタフェースユニット３４とを備えている。なお、当該アクセス先となる病院公開サーバＳＶ２が備える機能のうち、アクセス元となる病院公開サーバＳＶ１が備える機能と同一部分については説明を省略する。

記憶ユニット３２は、記憶媒体としてＨＤＤやＳＳＤ等の随時書込み読出しが可能な不揮発性記憶媒体を使用したもので、この発明の一実施形態を実施するために必要な記憶部として、前記アクセス元の病院公開サーバＳＶ１と同様に、患者ユーザ情報格納部３１１と、医療従事者情報格納部３１２と、ＩＤ連携情報格納部３１３と、アクセス制御情報格納部３１４と、診療情報格納部３１５と、ログ情報格納部３１６を備えている。

処理ユニット３０は、ＣＰＵ（Central Processing Unit）を備え、この発明の一実施形態を実施するために必要な処理機能として、Ｗｅｂアクセス受付部３０１と、認証・ＩＤ連携処理部３０２と、アクセス制御判定部３０３と、リモートデータアクセス処理部３０４と、データ操作処理部３０５と、ログ出力部３０６を有している。これらの処理部は、何れも図示しないプログラムメモリに格納されたアプリケーション・プログラムを上記ＣＰＵに実行させることにより実現される。

上記各処理部のうち認証・ＩＤ連携処理部３０２は、ユーザ端末ＵＴ１の操作によりゲストユーザの登録処理が行われた場合に、当該ゲストユーザに対し自サーバで独自のゲストユーザＩＤを発行してこれを医療従事者情報格納部３１２記憶させる処理を行う。またそれと共に、連携サーバＳＶ０に対し仮名の発行を依頼し、この発行依頼に対し連携サーバＳＶ０から送られたゲストユーザ用の仮名をＩＤ連携情報格納部３１３に上記ゲストユーザＩＤと関連付けて格納する処理を行う。

（動作）
次に、以上のように構成されたシステムにおいて実行されるＩＤ連携動作を、複数の実施例に分けて説明する。
（１）全ユーザに個別に仮名を発行する場合
この例は、全ユーザに個別に仮名を発行してＩＤ連携を行うもので、本発明の前提となる動作であるが、本発明の動作の理解を助けるために参考例として説明する。図５はこの参考例におけるシステムのデータ保有例を示したものである。

同図において、水野太郎医師はＡ病院の内科の医師、田中次郎医師はＡ病院の医師であるとする。患者である鈴木花子は、Ａ病院にもＢ病院にも通院していると仮定する。Ａ病院公開サーバＳＶ１の医療従事者情報管理テーブル２１２には、水野太郎医師と田中次郎医師のユーザＩＤに関連付けて姓名や住所などの属性情報が記憶されている。患者ユーザ情報管理テーブル２１１には、患者である鈴木花子のユーザＩＤに関連付けて、姓名や住所などの属性情報が記憶されている。また、Ｂ病院の病院公開サーバＳＶ２には、患者である鈴木花子の属性情報が患者ユーザ情報管理テーブル３１１に登録されている。Ａ病院とＢ病院とが地域医療連携していない場合は、水野太郎医師はＢ病院には登録されていない。

水野太郎医師が、Ａ病院において患者である鈴木花子の治療の参考として、Ｂ病院公開サーバＳＶ２に保存されている診療情報を見る必要がある場合に、Ｂ病院公開サーバＳＶ２の運用者に閲覧可能にするための情報の登録を依頼する。運用者は、Ｂ病院公開サーバＳＶ２の医療従事者情報管理テーブル３１２に、水野太郎医師（ユーザＩＤ： BDoc_901）を登録する。次に連携サーバＳＶ０が、水野太郎医師のＢ病院公開サーバＳＶ２での仮名を発行してＩＤ連携情報管理テーブル１１２に（ユーザＩＤ： md0001，仮名： V5pw4j）を追加登録し、さらに当該仮名をＢ病院公開サーバＳＶ２へ送ってそのＩＤ連携情報格納部３１３のＩＤ連携情報管理テーブルに水野太郎医師の仮名とユーザＩＤ（仮名： V5pw4j，ユーザＩＤ： BDoc_901）を追加登録することで、個別ユーザＩＤを流通させない、仮名を用いたＩＤ連携を可能にする。

さらに、Ｂ病院公開サーバＳＶ２のアクセス制御情報管理テーブルに、資格が医師、組織がＡ病院で内部組織が内科であるユーザに、鈴木花子（ユーザＩＤ： BPat_001）の診療情報の閲覧を許可する、というアクセス制御ルールを設定する。これにより、Ａ病院にいる水野太郎医師が、Ｂ病院公開サーバＳＶ２に保存されている鈴木花子の診療情報を閲覧できるようになる。

ところが、このようなすべての医療従事者に対し仮名を発行して管理する方式では、地域連携しているすべての病院公開サーバＳＶ１〜ＳＶｎ及び連携サーバＳＶ０に対して、医療従事者のユーザＩＤ及び仮名を登録しなければならず、地域連携する病院及び医療従事者が多くなればなるほど、登録や維持管理の手間が膨大となってしまう。

（２）ゲストユーザ用の仮名方式を用いた場合（実施例１）
実施例１は、ゲストユーザ用の仮名を用いてＩＤ連携を行う方式である。各病院公開サーバに、地域連携している他の病院に所属する医療従事者をゲストユーザと定義してこのゲストユーザ用の仮名を登録しておき、ある病院の医療従事者が別の病院の公開サーバに保存されている患者の診療情報を閲覧するときに、アクセス元の医療従事者の仮名を、アクセス先となる病院のゲストユーザ用の仮名に置き換えることにより、病院公開サーバ間での医療従事者のＩＤ連携を行うようにしたものである。

図６は、ゲストユーザ用の仮名方式を用いた場合の各サーバにおけるデータ保有例を示すものである。また図９及び図１０は実施例１における各サーバの処理手順と処理内容を示すフローチャートである。
Ｂ病院公開サーバＳＶ２に格納されている患者の診療情報を、当該患者の紹介先となるＡ病院公開サーバＳＶ１から閲覧可能にするために、Ｂ病院公開サーバのＳＶ２の運用者は、ユーザ端末ＵＴ２を操作してＢ病院公開サーバＳＶ２の医療従事者情報管理テーブルに図６に示すようにゲスト医師（ユーザＩＤ: BDoc_gst）を登録する。そして、連携サーバＳＶ０に対し仮名の発行要求を送る。

これに対し連携サーバＳＶ０は、Ｂ病院ゲストユーザ用のシステム共通ユーザＩＤと仮名を発行し、この発行されたユーザＩＤ（mdg00b）と仮名（f6SmF9）を図６に示すように自サーバＳＶ０内のＩＤ連携情報管理テーブルに追加登録する。またそれと共に、Ｂ病院公開サーバSV2のＩＤ連携情報管理テーブルに、上記発行されたゲストユーザ用の仮名（f6SmF9）をユーザＩＤ（BDoc_gst）と関連付けて追加登録する。さらに、Ｂ病院公開サーバＳＶ２のアクセス制御情報管理テーブルには、「資格が医師、組織がＡ病院で内部組織が内科であるユーザに、鈴木花子（ユーザＩＤ: BPat_001）の診療情報の閲覧を許可する」というアクセス制御ルールを設定する。

さて、この状態でＡ病院に所属する水野太郎医師が、Ｂ病院公開サーバＳＶ２に保存されている鈴木花子の診療情報を閲覧するために、自身のユーザ端末ＵＴ１からＡ病院公開サーバＳＶ１に対し閲覧依頼を送信したとする。Ａ病院公開サーバＳＶ１は、上記閲覧依頼をＷｅｂアクセス受付部２０１で受信すると、図９に示すようにデータ操作処理部２０５に対しデータ取得処理を依頼する。データ操作処理部２０５は、患者である鈴木花子と水野太郎医師のアサーションを認証・ＩＤ連携処理部２０２に要求する。

認証・ＩＤ連携処理部２０２は、上記患者である鈴木花子と水野太郎医師のＡ病院公開サーバＳＶ１おける仮名（Mw0qJZ）、（AgYe6f）をＩＤ連携情報管理テーブルから取得する。そして、この取得したＡ病院公開サーバＳＶ１おける仮名（Mw0qJZ）、（AgYe6f）を含むアサーション取得要求を連携サーバＳＶ０へ順次送信し、連携サーバＳＶ０から上記鈴木花子と水野太郎医師のＢ病院公開サーバＳＶ１おけるアサーション情報を取得する。

例えば、Ａ病院公開サーバＳＶ１の認証・ＩＤ連携処理部２０２は、図９に示すように先ず鈴木花子のＡ病院公開サーバＳＶ１おける仮名（Mw0qJZ）を含むアサーション取得要求を連携サーバＳＶ０へ送信する。連携サーバＳＶ０は認証・ＩＤ連携処理部１０２の制御の下、上記ＩＤ連携情報管理テーブルから上記仮名（Mw0qJZ）に関連付けられた鈴木花子の共通ユーザＩＤ（mp0001）を取得する。そして、この共通ユーザＩＤをキーにＩＤ連携情報管理テーブルから鈴木花子のＢ病院公開サーバＳＶ２における仮名（9d5AQL）を取得し、この取得した仮名を含むアサーション情報を要求元のＡ病院公開サーバＳＶ１へ返送する。

次に、Ａ病院公開サーバＳＶ１の認証・ＩＤ連携処理部２０２は、水野太郎医師のＡ病院公開サーバＳＶ１おける仮名（AgYe6f）を含むアサーション取得要求を連携サーバＳＶ０へ送信する。連携サーバＳＶ０は、認証・ＩＤ連携処理部１０２の制御の下で、ＩＤ連携情報管理テーブルから上記仮名（AgYe6f）に関連付けられた水野太郎医師の共通ユーザＩＤ（md0001）を取得する。そして、この共通ユーザＩＤをキーにＩＤ連携情報管理テーブルから水野太郎医師のＢ病院公開サーバＳＶ２における仮名の取得を試みる。

しかし、水野太郎医師のＢ病院公開サーバＳＶ２における仮名は登録されていない。そこで、ユーザ情報管理テーブルから上記共通ユーザＩＤに関連付けられた水野太郎医師の属性情報を読み出し、この読み出した水野太郎医師の属性情報を変換ルール設定ファイル記憶部１２に格納された変換ルール設定ファイルと照合する。そして、属性情報と合致する変換ルールが見つかると、ＩＤ連携情報管理テーブルからゲストユーザ用の仮名を取得する。

例えば、いま水野太郎医師の属性情報が図６に示すように所属組織＝Ａ病院、内部組織＝内科、保有資格＝医師であり、変換ルール設定ファイルの内容が図８に示すものだったとすると、水野太郎医師の属性情報は変換ルール１に合致する。このため、ＩＤ連携情報管理テーブルからゲストユーザ用の仮名である“f6SmF9”を取得する。

認証・ＩＤ連携処理部１０２は、上記取得されたゲストユーザ用の仮名（f6SmF9）を利用して水野太郎医師のＢ病院公開サーバＳＶ２用のアサーション情報を作成し、Ａ病院公開サーバＳＶ１に返送する。

図８について補足説明をする。上記例では水野太郎医師の属性情報が変換ルール設定ファイルの変換ルール１と完全に合致する例を取り上げて説明した。しかし、この合致については種々の設定が可能である。
図８においては、変換ルール２は組織と資格は記載があるが、内部組織は空白となっている。また変換ルール３は、資格は１つのみ属性が記載されているが、組織と内部組織は複数の属性を指定している。空白の定義には２通りが考えられる。１つは「空白という値を持っている」という扱いにするものである。変換ルール２では、内部組織は空白になっているため、内科の水野医師は合致せず、内部組織に属さない田中医師は合致する、と見なす。もう１つは、「特に規定しない」という扱いにするものである。この場合変換ルール２は、「内部組織は問わない」という解釈となる。このため、水野医師も田中医師も合致すると見なす。

また、これとは別に、ユーザが複数の属性（資格、組織、内部組織）を持っている場合も、２つの判定手法が考えられる。１つは、ユーザの属性とルールの属性がすべて合致したときのみ許可するというもの、もう１つは、複数の属性のうちのどれかが合致すればよいというものである。例えば、佐藤医師がＡ病院でもＢ病院でも内科かつ小児科に属しているが、長沼医師はＢ病院の小児科のみに属しているとする。変換ルール３では、前者の判定手法であれば佐藤医師のみ合致し、後者の判定手法であれば佐藤医師も長沼医師も合致することになる。

さらに、図８では資格、組織及び内部組織の３つの属性に基づき、変換ルールとの合致を判定するようにしたが、判定には他の属性を用いることも可能である。ユーザが認証したときの認証方式（ワンタイムパスワード方式なのか、生体認証なのか等）や、アクセス元の端末のＩＰアドレスやドメインを示す情報を含めてもよい。また、アクセス先のサーバ情報を用いて、特定のサーバのみ許可するといったルールも作成することができる。さらに、これらの情報をいろいろと組み合わせて、ＡＮＤ条件やＯＲ条件などを用いて、変換ルールを作成してもよい。
以上述べたように、図８に関する説明はあくまでも一例であり、この記載に限定されるものではない。

連携サーバＳＶ０から、アクセス先となる鈴木花子のＢ病院公開サーバＳＶ２におけるアサーション情報と、アクセス元となる水野太郎医師のＢ病院公開サーバＳＶ２におけるアサーション情報が返送されると、Ａ病院公開サーバＳＶ１は上記各アサーション情報を認証・ＩＤ連携処理部２０２からデータ操作処理部２０５に返却する。データ操作処理部２０５はリモートデータアクセス処理部２０４に、Ｂ病院公開サーバＳＶ２に保存されている鈴木花子の診療情報の閲覧を要求する。このとき、リモートデータアクセス処理部２０４には、上記閲覧要求と共に鈴木花子及び水野太郎医師のアサーション情報も送付する。リモートデータアクセス処理部２０４は、Ｂ病院公開サーバＳＶ２へデータの取得要求を送信する。

Ｂ病院公開サーバＳＶ２は、上記データ取得要求とアサーション情報を受信すると、図１０に示すようにデータ操作処理部３０５から認証・ＩＤ連携処理部３０２に上記アサーション情報を渡す。認証・ＩＤ連携処理部３０２は、鈴木花子のアサーション情報から仮名（9d5AQL）を抽出し、この仮名（9d5AQL）をもとにＩＤ連携情報管理テーブルからユーザＩＤ（BPat_001）を取得する。続いて、水野太郎医師のアサーション情報から仮名（f6SmF9）を抽出し、この仮名（f6SmF9）をもとにＩＤ連携情報管理テーブルからゲスト医師のユーザＩＤ（BDoc_gst）を取得する。そして、この取得された鈴木花子のユーザＩＤ（BPat_001）とゲスト医師のユーザＩＤ（BDoc_gst）をデータ操作処理部３０５に返却する。

次にデータ操作処理部３０５は、鈴木花子の診療情報に対するアクセスが可能かどうかの判定をアクセス制御判定部３０３に依頼する。アクセス制御判定部３０３は、前の処理で取得された鈴木花子のユーザＩＤ（BPat_001）と、水野太郎医師のアサーション情報から得られた資格＝医師、所属組織＝Ａ病院、内部組織＝内科を、アクセス制御情報管理テーブルに記憶されたアクセス制御ルールと照合し、一致すると上記診療情報へのアクセスが可能と判断してその結果をデータ操作処理部３０５に返却する。

上記アクセスが可能であるとの判定結果を受け取るとデータ操作処理部３０５は、診療情報格納部３１５から鈴木花子の診療情報を読み出して、リモートデータアクセス処理部３０４に渡す。リモートデータアクセス処理部３０４は、上記読み出された鈴木花子の診療情報をＡ病院公開サーバＳＶ１のデータ操作処理部２０５に結果を渡す。データ操作処理部２０５はＷｅｂアクセス受付部２０１に結果を渡し、Ｗｅｂアクセス受付部２０１からユーザ端末ＵＴ１に対して鈴木花子の診療情報を送りディスプレイ等に表示させる。

かくして、アクセス先のＢ病院公開サーバＳＶ２では、アクセス元の水野太郎医師の個別ユーザＩＤと仮名を用いず、代わりにゲスト医師の仮名を用いたＩＤ連携が行われ、これにより病院公開サーバＳＶ１，ＳＶ２間での鈴木花子の診療情報の閲覧が可能となる。

ところで、以上述べた一連のＩＤ連携処理と診察情報の閲覧処理が終了すると、連携サーバＳＶ０、アクセス元のＡ病院公開サーバＳＶ１及びアクセス先のＢ病院公開サーバＳＶ２はそれぞれログ出力部１０６，２０６，３０６により、上記一連のＩＤ連携処理と診察情報の閲覧処理の過程で使用したセッションのＩＤ及びスレッドのＩＤを時系列で配列したログ情報を作成し、この作成したログ情報をそれぞれログ情報格納部１１４，２１６，３１６に格納する。

このとき、セッションＩＤはＷｅｂサイトの操作で１つ割り当てられる。このため、ゲスト医師の仮名はＡ病院に所属する複数の医療従事者によって使われる可能性があるが、医療従事者ごとにセッションＩＤが異なるため、上記ログ情報からどの医療従事者が操作したものかを区別することができる。また、スレッドＩＤはどの順番で処理が行われたのかを判断するのに用いられる。このため、アクセス元及びアクセス先となる各病院公開サーバで作成されたログ情報を見ることで、誰がどの操作をしたかを順を追って判定することが可能となる。

（３）一時的に払い出された仮名を使用した場合（実施例２）
実施例２は、一時的に払い出された仮名を使用してＩＤ連携を行う方式である。各病院公開サーバでは、地域連携している他の病院に所属する医療従事者のためのユーザＩＤを一切登録しない。そして、アクセス元となる病院公開サーバからアクセス先となる病院公開サーバにおける医療従事者のアサーションを要求された場合に、連携サーバＳＶ０がアクセス先となる病院公開サーバにおける医療従事者のために一時的に仮名を発行し、アクセス元の医療従事者の仮名を上記一時的に発行された仮名に置換することにより病院公開サーバ間での医療従事者のＩＤ連携を行うようにしたものである。

図７は、一時的に払い出された仮名を使用してＩＤ連携を行う方式を適用した場合の各サーバにおけるデータ保有例を示すものである。また図１１及び図１２は実施例２における各サーバの処理手順と処理内容を示すフローチャートである。
この実施例２では、一時的に仮名が払い出される方式を採用しているため、Ｂ病院公開サーバＳＶ２の運用者は図６に示したように医療従事者情報管理テーブル及びＩＤ連携情報管理テーブルにユーザ名及びそのユーザＩＤの登録を必要としない。但し、Ｂ病院公開サーバＳＶ２に保存された診療情報に対するＡ病院に所属する医療従事者からのアクセスの可否を判断するために、アクセス制御情報管理テーブルに「資格が医師、組織がＡ病院で内部組織が内科であるユーザに、鈴木花子（ユーザID:BPat_001）の診療情報の閲覧を許可する」というアクセス制御ルールを設定する。

さて、この状態でＡ病院に所属する水野太郎医師が、Ｂ病院公開サーバＳＶ２に保存されている鈴木花子の診療情報を閲覧するために、自身のユーザ端末ＵＴ１からＡ病院公開サーバＳＶ１に対し閲覧依頼を送信したとする。Ａ病院公開サーバＳＶ１は、上記閲覧依頼をＷｅｂアクセス受付部２０１で受信すると、図１１に示すようにデータ操作処理部２０５に対しデータ取得処理を依頼する。データ操作処理部２０５は、患者である鈴木花子と水野太郎医師のアサーションを認証・ＩＤ連携処理部２０２に要求する。

認証・ＩＤ連携処理部２０２は、上記患者である鈴木花子と水野太郎医師のＡ病院公開サーバＳＶ１おける仮名（Mw0qJZ）、（AgYe6f）をＩＤ連携情報管理テーブルから取得する。そして、この取得したＡ病院公開サーバＳＶ１おける仮名（Mw0qJZ）、（AgYe6f）を含むアサーション取得要求を連携サーバＳＶ０へ順次送信し、連携サーバＳＶ０から上記鈴木花子と水野太郎医師のＢ病院公開サーバＳＶ１おけるアサーション情報を取得する。

例えば、Ａ病院公開サーバＳＶ１の認証・ＩＤ連携処理部２０２は、図１１に示すように先ず鈴木花子のＡ病院公開サーバＳＶ１おける仮名（Mw0qJZ）を含むアサーション取得要求を連携サーバＳＶ０へ送信する。連携サーバＳＶ０は認証・ＩＤ連携処理部１０２の制御の下、上記ＩＤ連携情報管理テーブルから上記仮名（Mw0qJZ）に関連付けられた鈴木花子の共通ユーザＩＤ（mp0001）を取得する。そして、この共通ユーザＩＤをキーにＩＤ連携情報管理テーブルから鈴木花子のＢ病院公開サーバＳＶ２における仮名（9d5AQL）を取得し、この取得した仮名を含むアサーション情報を要求元のＡ病院公開サーバＳＶ１へ返送する。

次に、Ａ病院公開サーバＳＶ１の認証・ＩＤ連携処理部２０２は、水野太郎医師のＡ病院公開サーバＳＶ１おける仮名（AgYe6f）を含むアサーション取得要求を連携サーバＳＶ０へ送信する。連携サーバＳＶ０は、認証・ＩＤ連携処理部１０２の制御の下で、ＩＤ連携情報管理テーブルから上記仮名（AgYe6f）に関連付けられた水野太郎医師の共通ユーザＩＤ（md0001）を取得する。そして、この共通ユーザＩＤをキーにＩＤ連携情報管理テーブルから水野太郎医師のＢ病院公開サーバＳＶ２における仮名の取得を試みる。

しかし、水野太郎医師のＢ病院公開サーバＳＶ２における仮名は登録されていない。そこで、ユーザ情報管理テーブルから上記共通ユーザＩＤに関連付けられた水野太郎医師の属性情報を読み出し、この読み出した水野太郎医師の属性情報を変換ルール設定ファイル記憶部１２に格納された変換ルール設定ファイルと照合する。例えば、いま水野太郎医師の属性情報が図７に示すように所属組織＝Ａ病院、内部組織＝内科、保有資格＝医師であり、変換ルール設定ファイルの内容が図８に示すものだったとすると、水野太郎医師の属性情報は変換ルール１に合致する。そして、このように属性情報と合致する変換ルールが見つかると、一時的に仮名を発行し、この発行した仮名を用いて水野太郎医師のＢ病院公開サーバＳＶ２用のアサーション情報を作成し、Ａ病院公開サーバＳＶ１に返送する。
なお、図８に示した変換ルールの使用法については実施例１で述べた通りなので、ここでの説明は省略する。

連携サーバＳＶ０から、アクセス先となる鈴木花子のＢ病院公開サーバＳＶ２におけるアサーション情報と、アクセス元となる水野太郎医師のＢ病院公開サーバＳＶ２におけるアサーション情報が返送されると、Ａ病院公開サーバＳＶ１は上記各アサーション情報を認証・ＩＤ連携処理部２０２からデータ操作処理部２０５に返却する。データ操作処理部２０５はリモートデータアクセス処理部２０４に、Ｂ病院公開サーバＳＶ２に保存されている鈴木花子の診療情報の閲覧を要求する。このとき、リモートデータアクセス処理部２０４には、上記閲覧要求と共に鈴木花子及び水野太郎医師のアサーション情報も送付する。リモートデータアクセス処理部２０４は、Ｂ病院公開サーバＳＶ２へデータの取得要求を送信する。

Ｂ病院公開サーバＳＶ２は、上記データ取得要求とアサーション情報を受信すると、図１２に示すようにデータ操作処理部３０５から認証・ＩＤ連携処理部３０２に上記アサーション情報を渡す。認証・ＩＤ連携処理部３０２は、鈴木花子のアサーション情報から仮名（9d5AQL）を抽出し、この仮名（9d5AQL）をもとにＩＤ連携情報管理テーブルからユーザＩＤ（BPat_001）を取得する。続いて、水野太郎医師のアサーション情報から属性情報を抽出し、この抽出した水野太郎医師の属性情報を上記取得した鈴木花子のユーザＩＤ（BPat_001）と共にデータ操作処理部３０５に返却する。

次にデータ操作処理部３０５は、鈴木花子の診療情報に対するアクセスが可能かどうかの判定をアクセス制御判定部３０３に依頼する。アクセス制御判定部３０３は、前の処理で取得された鈴木花子のユーザＩＤ（BPat_001）と、水野太郎医師のアサーション情報から抽出した資格＝医師、所属組織＝Ａ病院、内部組織＝内科を、アクセス制御情報管理テーブルに記憶されたアクセス制御ルールと照合する。そして、属性がアクセス制御ルールと一致すると、上記診療情報へのアクセスが可能と判断してその結果をデータ操作処理部３０５に返却する。

上記アクセスが可能であるとの判定結果を受け取るとデータ操作処理部３０５は、診療情報格納部３１５から鈴木花子の診療情報を読み出して、リモートデータアクセス処理部３０４に渡す。リモートデータアクセス処理部３０４は、上記読み出された鈴木花子の診療情報をＡ病院公開サーバＳＶ１のデータ操作処理部２０５に結果を渡す。データ操作処理部２０５はＷｅｂアクセス受付部２０１に結果を渡し、Ｗｅｂアクセス受付部２０１からユーザ端末ＵＴ１に対して鈴木花子の診療情報を送りディスプレイ等に表示させる。

かくして、アクセス元の水野太郎医師の個別ユーザＩＤと仮名は勿論のこと、ゲスト医師のユーザＩＤ及び仮名も用いず、一時的に発行される仮名を用いたＩＤ連携が行われ、これにより病院公開サーバＳＶ１，ＳＶ２間での鈴木花子の診療情報の閲覧が可能となる。

また、以上述べた一連のＩＤ連携処理と診察情報の閲覧処理が終了すると、連携サーバＳＶ０、アクセス元のＡ病院公開サーバＳＶ１及びアクセス先のＢ病院公開サーバＳＶ２はそれぞれログ出力部１０６，２０６，３０６により、上記一連のＩＤ連携処理と診察情報の閲覧処理の過程で使用したセッションのＩＤ及びスレッドのＩＤを時系列で配列したログ情報を作成し、この作成したログ情報をそれぞれログ情報格納部１１４，２１６，３１６に格納する。

このとき、ゲストユーザ用の仮名を用いてユーザ認証を行う方法と同じく、各サーバにおいて実施される各々の処理をログ情報として出力する際に、セッションＩＤとスレッドＩＤも併せて出力することで、どの医療従事者がどの操作を実施したかを判別することができる。この方法以外に、連携サーバＳＶ０のログ情報として、医療従事者のユーザＩＤと一時的に払い出された仮名とを出力する方法がある。Ｂ病院公開サーバＳＶ２のログ情報格納部３１６には、一時的に払い出された仮名のログ情報が保存されるので、これを連携サーバＳＶ０のログ情報と付き合わせることで、どの医療従事者がどの操作を実施したかを判別することができる。

（実施形態の効果）
以上詳述したように一実施形態では、各病院公開サーバＳＶ１〜ＳＶｎに、地域連携している他の病院に所属する医療従事者をゲストユーザと定義し、連携サーバＳＶ０により上記ゲストユーザに対し仮名を発行して登録しておき、ある病院の医療従事者が別の病院の公開サーバに保存されている患者の診療情報を閲覧する際に、アクセス元の医療従事者の仮名をアクセス先となる病院のゲストユーザ用の仮名に置き換えることにより、病院公開サーバ間での医療従事者のＩＤ連携を行うようにしている。または、連携サーバＳＶ０が一時的に仮名を発行して、アクセス元の医療従事者の仮名を上記一時的に発行された仮名に置き換えることにより、病院公開サーバ間での医療従事者のＩＤ連携を行うようにしている。

したがって、連携サーバＳＶ０が管理する仮名の数を減らすことが可能となり、これにより仮名とそれに紐付けられるユーザＩＤの維持管理に要する負荷を軽減することが可能となる。例えば、連携サーバＳＶ０がすべてのユーザＩＤに対し仮名を発行しこれを維持管理する場合には、ユーザ数×連携対象の病院公開サーバ数に相当する数の仮名を維持管理する必要があったが、一実施形態ではユーザ数＋（連携対象の病院公開サーバ数×変換ルールで定義される属性数）となり、大幅に少なくすることができる。

また、病院公開サーバＳＶ１〜ＳＶｎごとにゲストユーザを定義することで、システムを使うかどうかわからないユーザのユーザＩＤを全ての病院公開サーバＳＶ１〜ＳＶｎが管理する必要がなくなる。このため、システムを使用しないユーザのＩＤの漏洩を未然に防止することが可能となり、これによりユーザＩＤの管理に対するセキュリティを高めることができる。

さらに、連携サーバＳＶ０において、仮名の変換の可否を判定するための変換ルール設定ファイルが用意され、アクセス元ユーザの属性情報が当該変換ルールを満たすか否かが判定される。そして、属性情報が変換ルールを満たすと判定された場合にのみアクセス元ユーザ用の仮名がゲストユーザの仮名に変換される。このため、予め設定した属性情報を持つユーザ以外はゲストユーザとして認定しないようにすることができ、これにより例えば予め定めた組織に属しかつ適切な資格を有するユーザだけがゲストユーザとしてデータアクセスを行うことが可能となる。

さらに、病院公開サーバＳＶ１〜ＳＶｎおいて、患者ごとにそのユーザＩＤに関連付けて当該患者の診療情報に対するアクセス制御ルールが設定され、データアクセス要求を受信した場合に、アクセス元ユーザの属性情報が上記アクセス制御ルールを満たすと判定された場合にのみ、上記データアクセス要求により指定された患者の診療情報に対するアクセス処理が実行される。このため、患者ごとに設定したその診療情報の開示条件を満たすアクセス元ユーザに対してのみ、当該診療情報が開示されることになり、患者の診療情報に対しアクセス可能な医療従事者を適切に制限することができる。

さらに、連携サーバＳＶ０、アクセス元の病院公開サーバＳＶ１及びアクセス先の病院公開サーバＳＶ２では、患者の診療情報に対するアクセス処理が行われるごとに、そのセッションＩＤ及びスレッドＩＤを含むログ情報が生成されて記憶される。このため、上記患者の診療情報に対するアクセスが行われた場合に、どのユーザがどの患者の個別情報に対しどのようなアクセスを行ったかを、上記記憶されたログ情報のセッション情報及びスレッド情報を追跡することで特定することが可能となる。

［他の実施形態］
前記一実施形態では、複数の病院公開サーバＳＶ１〜ＳＶｎを通信ネットワークＮＷを介して連携サーバＳＶ０に接続し、これにより紹介元と紹介先の病院間で患者の診療情報の閲覧を可能にする場合を例にとって説明した。しかし、これに限らず、複数の学校のサーバを連携サーバを介して接続することにより、例えば転校した生徒に関する情報を閲覧可能としてもよい。また、企業の工場や営業所、関連会社等のサーバを連携サーバを介して接続することにより、例えば異動又は転籍した従業員や社員に関する情報を閲覧可能としてもよい。

その他、連携サーバ及び各データサーバの構成やその処理手順及び処理内容、連携用ユーザＩＤや通信識別子の構成等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。

要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

ＳＶ０…連携サーバ、ＳＶ１〜ＳＶｎ…病院公開サーバ、ＮＷ…通信ネットワーク、ＵＴ０…運用者端末、ＵＴ１〜ＵＴｎ…ユーザ端末、１０，２０，３０…処理ユニット、１１，２１，３１…記憶ユニット、１２…変換ルール設定ファイル格納部、１３，２３，３３…通信インタフェースユニット、１４，２４，３４…ユーザインタフェースユニット、１０１，２０１，３０１…Ｗｅｂアクセス受付部、１０２，２０２，３０２…認証・ＩＤ連携処理部、１０３，２０３，３０３…アクセス制御判定部、１０４，２０４，３０…リモートデータアクセス処理部、１０５，２０５，３０５…データ操作処理部、１０６，２０６，３０６…ログ出力部、１１１…ユーザ情報格納部、１１２，２１３，３１３…ＩＤ連携情報格納部、１１３，２１４，３１４…アクセス制御情報格納部、１１４，２１６，３１６…ログ情報格納部、２１１，３１１…患者ユーザ情報格納部、２１２，３１２…医療従事者情報格納部、２１５，３１５…診療情報格納部。

Claims (7)

1. 管理対象のユーザの各々に対しその個別情報及び個別ユーザＩＤを独自に管理する第１及び第２のデータサーバと、これら第１及び第２のデータサーバと通信ネットワークを介して通信可能な連携サーバとを具備する情報管理システムであって、
   前記第１及び第２のデータサーバは、
   自サーバ以外のデータサーバが管理するユーザ群をゲストユーザと定義して、このゲストユーザに対しゲストユーザＩＤを発行し記憶する手段を備え、
   前記連携サーバは、
   前記管理対象ユーザ及びゲストユーザについて、当該各ユーザをシステム全体で共通に管理するための共通ユーザＩＤを発行すると共に、前記各ユーザについて自サーバが第１及び第２のデータサーバと個別に通信を行うための通信用識別子を発行し、前記発行された共通ユーザＩＤと通信用識別子とを相互に関連付けた第１の連携情報を生成して記憶する手段を備え、
   前記第１及び第２のデータサーバは、
   前記管理対象ユーザ及びゲストユーザについて前記連携サーバにより発行された通信用識別子を当該連携サーバから受信する手段と、
   前記受信された通信用識別子と、前記各ユーザについて自サーバが独自に管理する個別ユーザＩＤ及びゲストユーザＩＤとを相互に関連付けた第２の連携情報を生成して記憶する手段と
   を備え、
   前記第１のデータサーバで管理されているユーザが前記第２のデータサーバで管理されている他のユーザの個別情報に対しアクセスする際に、
   前記連携サーバは、前記第１のデータサーバから送られるアクセス元ユーザ及びアクセス先となる他のユーザに関するアサーション取得要求に応じて、第２のデータサーバで定義されたゲストユーザ及びアクセス先となる他のユーザに対しそれぞれ発行された通信用識別子を前記第１の連携情報から検索し、当該検索された各通信用識別子を含むアサーション情報を取得要求元の第１のデータサーバへ返送する通信用識別子変換処理を行い、
   前記第１のデータサーバは、前記他のユーザの個別情報に対するデータアクセス要求を、前記連携サーバから返送されたアサーション情報と共に第２のデータサーバへ送信し、
   前記第２のデータサーバは、前記第１のデータサーバから送られたデータアクセス要求及びアサーション情報を受信すると、当該受信されたアサーション情報に含まれる各通信用識別子をもとに、ゲストユーザＩＤ及びアクセス先ユーザの個別ユーザＩＤを前記第２の連携情報から検索し、当該検索された各ユーザＩＤと前記受信されたアサーション情報とに基づいて前記アクセス先ユーザの個別情報に対するアクセス処理を実行する
   ことを特徴とする情報管理システム。
2. 前記連携サーバは、前記通信用識別子の変換の可否を判定するための変換ルールを記憶する手段をさらに備え、前記第１のデータサーバから送られたアサーション取得要求に含まれるアクセス元ユーザの属性情報が前記記憶された変換ルールを満たすか否かを判定し、変換ルールを満たすと判定された場合に、前記第２のデータサーバのゲストユーザについて発行された通信用識別子を、前記記憶された第１の連携情報から検索することを特徴とする請求項１記載の情報管理システム。
3. 前記第２のデータサーバは、管理対象のユーザごとにその個別ユーザＩＤに関連付けて当該管理対象ユーザの個別情報に対するアクセス条件を記憶する手段を備え、前記データアクセス要求を受信した場合に、当該データアクセス要求と共に受信したアサーション情報に含まれるアクセス元ユーザの属性情報が前記記憶されたアクセス条件を満たすか否かを判定し、アクセス条件を満たすと判定された場合に、前記データアクセス要求により指定された管理対象ユーザの個別情報に対するアクセス処理を実行することを特徴とする請求項１又は２記載の情報管理システム。
4. 前記第１及び第２のデータサーバ、及び前記連携サーバの各々は、前記アサーション取得要求の発生から管理対象ユーザの個別情報に対するアクセス処理の終了までに自サーバ内で実行された処理を表すセッション情報、及び当該処理の実行単位を表すスレッド情報を含むログ情報を生成して記憶する手段を、さらに備えることを特徴とする請求項３記載の情報管理システム。
5. 管理対象のユーザの各々に対しその個別情報及び個別ユーザＩＤを独自に管理する第１及び第２のデータサーバと、これら第１及び第２のデータサーバと通信ネットワークを介して通信可能な連携サーバとを具備する情報管理システムであって、
   前記連携サーバは、
   前記管理対象のユーザについて、当該ユーザをシステム全体で共通に管理するための共通ユーザＩＤを発行すると共に、前記ユーザについて自サーバが第１及び第２のデータサーバと個別に通信を行うための通信用識別子を発行し、前記発行された共通ユーザＩＤと通信用識別子とを相互に関連付けた第１の連携情報を生成して記憶する手段を備え、
   前記第１及び第２のデータサーバは、
   前記管理対象のユーザについて前記連携サーバにより発行された通信用識別子を当該連携サーバから受信する手段と、
   前記受信された通信用識別子と、前記ユーザについて自サーバが独自に管理する個別ユーザＩＤとを相互に関連付けた第２の連携情報を生成して記憶する手段と
   を備え、
   前記第１のデータサーバで管理されているユーザが前記第２のデータサーバで管理されている他のユーザの個別情報に対しアクセスする際に、
   前記連携サーバは、前記第１のデータサーバから送られるアクセス元ユーザ及びアクセス先となる他のユーザに関するアサーション取得要求に応じて、第２のデータサーバにおけるアクセス先となる他のユーザについて発行された通信用識別子を前記第１の連携情報から検索すると共に、前記アクセス元ユーザに対し通信用識別子を一時的に発行し、当該検索及び発行された通信用識別子を含むアサーション情報を取得要求元の第１のデータサーバへ返送する通信用識別子の変換処理を行い、
   前記第１のデータサーバは、前記他のユーザの個別情報に対するデータアクセス要求を、前記連携サーバから返送されたアサーション情報と共に第２のデータサーバへ送信し、
   前記第２のデータサーバは、前記第１のデータサーバから送られたデータアクセス要求及びアサーション情報を受信すると、当該受信されたアサーション情報に含まれる各通信用識別子をもとにアクセス先ユーザの個別ユーザＩＤを前記第２の連携情報から検索し、当該検索されたユーザＩＤと前記受信されたアサーション情報とに基づいて前記アクセス先ユーザの個別情報に対するアクセス処理を実行する
   ことを特徴とする情報管理システム。
6. 管理対象のユーザの各々に対しその個別情報及び個別ユーザＩＤを独自に管理する第１及び第２のデータサーバと、これら第１及び第２のデータサーバと通信ネットワークを介して通信可能な連携サーバとを具備する情報管理システムが実行するデータ連携方法であって、
   前記第１及び第２のデータサーバが、自サーバ以外のデータサーバが管理するユーザ群をゲストユーザと定義し、このゲストユーザに対しゲストユーザＩＤを発行して自サーバのＩＤ連携用データ記憶部に記憶させる過程と、
   前記連携サーバが、前記管理対象ユーザ及びゲストユーザについて、当該各ユーザをシステム全体で共通に管理するための共通ユーザＩＤを発行すると共に、前記各ユーザについて自サーバが第１及び第２のデータサーバと個別に通信を行うための通信用識別子を発行し、前記発行された共通ユーザＩＤと通信用識別子とを相互に関連付けた第１の連携情報を生成して、自サーバのＩＤ連携用データ記憶部に記憶させる過程と、
   前記第１及び第２のデータサーバが、前記管理対象ユーザ及びゲストユーザについて前記連携サーバにより発行された通信用識別子を当該連携サーバから受信する過程と、
   前記第１及び第２のデータサーバが、前記受信された通信用識別子と、前記各ユーザについて自サーバが独自に管理する個別ユーザＩＤ及びゲストユーザＩＤとを相互に関連付けた第２の連携情報を生成して自サーバのＩＤ連携用データ記憶部に記憶させる過程と
   を具備し、
   前記第１のデータサーバで管理されているユーザが前記第２のデータサーバで管理されている他のユーザの個別情報に対しアクセスする際に、
   前記連携サーバが、前記第１のデータサーバから送られるアクセス元ユーザ及びアクセス先となる他のユーザに関するアサーション取得要求に応じて、第２のデータサーバで定義されたゲストユーザ及びアクセス先となる他のユーザに対しそれぞれ発行された通信用識別子を前記第１の連携情報から検索し、当該検索された各通信用識別子を含むアサーション情報を取得要求元の第１のデータサーバへ返送する通信用識別子変換処理を行い、
   前記第１のデータサーバが、前記他のユーザの個別情報に対するデータアクセス要求を、前記連携サーバから返送されたアサーション情報と共に第２のデータサーバへ送信し、
   前記第２のデータサーバが、前記第１のデータサーバから送られたデータアクセス要求及びアサーション情報を受信すると、当該受信されたアサーション情報に含まれる各通信用識別子をもとに、ゲストユーザＩＤ及びアクセス先ユーザの個別ユーザＩＤを前記第２の連携情報から検索し、当該検索された各ユーザＩＤと前記受信されたアサーション情報とに基づいて前記アクセス先ユーザの個別情報に対するアクセス処理を実行する
   ことを特徴とするデータ連携方法。
7. 管理対象のユーザの各々に対しその個別情報及び個別ユーザＩＤを独自に管理する第１及び第２のデータサーバと、これら第１及び第２のデータサーバと通信ネットワークを介して通信可能な連携サーバとを具備する情報管理システムが実行するデータ連携方法であって、
   前記連携サーバが、前記管理対象のユーザについて、当該ユーザをシステム全体で共通に管理するための共通ユーザＩＤを発行すると共に、前記ユーザについて自サーバが第１及び第２のデータサーバと個別に通信を行うための通信用識別子を発行し、前記発行された共通ユーザＩＤと通信用識別子とを相互に関連付けた第１の連携情報を生成して自サーバのＩＤ連携用データ記憶部に記憶させる過程と、
   前記第１及び第２のデータサーバが、前記管理対象のユーザについて前記連携サーバにより発行された通信用識別子を当該連携サーバから受信する過程と、
   前記第１及び第２のデータサーバが、前記受信された通信用識別子と、前記ユーザについて自サーバが独自に管理する個別ユーザＩＤとを相互に関連付けた第２の連携情報を生成して、自サーバのＩＤ連携用データ記憶部に記憶させる過程と
   を具備し、
   前記第１のデータサーバで管理されているユーザが前記第２のデータサーバで管理されている他のユーザの個別情報に対しアクセスする際に、
   前記連携サーバが、前記第１のデータサーバから送られるアクセス元ユーザ及びアクセス先となる他のユーザに関するアサーション取得要求に応じて、第２のデータサーバにおけるアクセス先となる他のユーザについて発行された通信用識別子を前記第１の連携情報から検索すると共に、前記アクセス元ユーザに対し通信用識別子を一時的に発行し、当該検索及び発行された通信用識別子を含むアサーション情報を取得要求元の第１のデータサーバへ返送する通信用識別子の変換処理を行い、
   前記第１のデータサーバが、前記他のユーザの個別情報に対するデータアクセス要求を、前記連携サーバから返送されたアサーション情報と共に第２のデータサーバへ送信し、
   前記第２のデータサーバが、前記第１のデータサーバから送られたデータアクセス要求及びアサーション情報を受信すると、当該受信されたアサーション情報に含まれる各通信用識別子をもとにアクセス先ユーザの個別ユーザＩＤを前記第２の連携情報から検索し、当該検索されたユーザＩＤと前記受信されたアサーション情報とに基づいて前記アクセス先ユーザの個別情報に対するアクセス処理を実行する
   ことを特徴とするデータ連携方法。

Images