JP2014215707A - 個人情報管理装置、方法及びプログラム - Google Patents

Abstract

【課題】業務種別ごとに予め設定された利用者であれば他者の個人情報に対してもアクセスできるようにし、個人情報の秘匿性を維持しつつ利用者の利便性向上を図る。
【解決手段】ＰＨＲサーバＳＶ１の記憶ユニット３に、業務定義テーブル３４及び操作対象定義テーブル３５をさらに設ける。そして、アプリケーションサーバＳＶ２からの認証要求に対し認証を行ってSession IDを発行したのち、利用者端末ＴＭからの業務実施要求に応じて、業務定義テーブル３４からAPIを読み出すと共に、操作対象定義テーブル３５から操作対象となる利用者のPatient IDを読み出す。そして、この読み出されたPatient IDに関連付けて記憶された健康情報又は医療情報を健康情報テーブル３３１又は医療情報テーブル３３２から選択し、この選択された情報に対し上記読み出されたAPIにより定義された操作内容の操作を行い、その結果を要求元へ返送する。
【選択図】図２

Description

この発明は、利用者からの要求に応じて、データベースに蓄積された利用者の健康情報や医療情報に対し予め許容されたアクセス制御を実行するアプリケーション・インタフェース（ＡＰＩ）を備えた個人情報管理装置、方法及びプログラムに関する。

一般に、個人の健康に関する情報は、カルテ情報は医療機関、健診の情報は健診機関や保険者、運動情報はフィットネスクラブ、体重等の情報は家庭というように、様々な場所に散在している。このため、個人が自身の健康情報を活用しようとすると、例えば該当する情報をそれぞれの機関等が運用するサーバ等にアクセスして取得しなければならず、手続や操作がきわめて面倒である。

そこで、個人の健康に関する様々な情報を一元的に管理・活用することを可能にするＰＨＲ（Personal Health Record）システムが提案されている（例えば、特許文献１又は非特許文献１を参照）。ＰＨＲシステムを利用すれば、個人が自らの意思で自身の健康に関する複数種類の情報を何時でもどこでも簡単に取得できるようになり、これにより自身の健康状態を適切に把握して健康増進や生活習慣病予防に役立てることが可能となる。

特開２０１１−１００３６１号公報

「Creative Healthサービス」、ＮＴＴデータ、インターネット＜URL: http://www.creativehealth.jp/ap/a/a0000.jsp＞

ところが、現在提案されているＰＨＲシステムでは、データベースに蓄積された健康情報に対し利用者がアクセスする際に、利用者ＩＤに関連付けられた健康情報のみにアクセス許可を与えるようになっている。このため、利用者の健康情報に対しては本人しかアクセスすることができず、例えば家族又は主治医が上記利用者の健康情報を直接確認することができない。

この発明は上記事情に着目してなされたもので、その目的とするところは、業務種別ごとに予め設定された利用者であれば他者の個人情報に対してもアクセスできるようにし、これにより個人情報の秘匿性を維持しつつ利用者の利便性を高めた個人情報管理装置、方法及びプログラムを提供することにある。

上記目的を達成するためにこの発明の第１の観点は、利用者の識別情報に対応付けて当該利用者の個人情報を記憶する個人情報データベースに加えて、業務ごとにその業務種別を表す情報に対応付けて当該業務の操作内容を表す情報及びその操作対象範囲を表す情報を少なくとも記憶する業務情報テーブルを備える。そして、利用者が使用するアクセス装置から業務種別を表す情報を含む操作要求を受信した場合に、先ず当該受信された業務種別を表す情報をもとに上記業務情報テーブルを検索して、対応する業務の操作内容を表す情報とその操作対象範囲を表す情報を読み出す。次に、この読み出された操作対象者の範囲に属する個人情報を上記個人情報データベースから選択し、この選択された個人情報に対し上記読み出された業務の操作内容を表す情報により定義された操作を実行するようにしたものである。

この発明の第２の観点は、上記業務情報テーブルとして、業務種別を表す情報に対応付けて当該業務の操作内容を表す情報と操作対象となる個人又は集合を表す情報を記憶する第１のテーブルと、上記操作対象となる個人又は集合を表す情報に対応付けて当該個人に対応する利用者又は集合に属する複数の利用者の利用者識別情報を記憶する第２のテーブルを備える。そして、利用者が使用するアクセス装置から上記操作要求を受信した場合に、先ず上記第１のテーブルから、上記受信された操作要求に含まれる業務種別を表す情報に対応する業務の操作内容を表す情報と操作対象となる個人又は集合を表す情報を読み出す。続いて、上記第２のテーブルから、上記読み出された操作対象となる個人又は集合を表す情報に対応する利用者の利用者識別情報を読み出すようにしたものである。

この発明の第３の観点は、上記業務情報テーブルに、業務種別を表す情報に対応付けて操作要求元として許可された利用者の識別情報をさらに記憶する。そして、利用者が使用するアクセス装置から業務種別を表す情報と操作要求元を表す利用者識別情報を含む操作要求を受信した場合に、先ず上記業務情報テーブルから上記受信された操作要求に含まれる業務種別を表す情報に対応する操作要求元として許可された利用者の識別情報を読み出し、上記受信された操作要求に含まれる操作要求元を表す利用者識別情報が上記読み出された利用者の識別情報と一致するか否かを判定する。そして、一致すると判定された場合に、上記業務情報テーブルから上記受信された業務種別を表す情報に対応する業務の操作内容を表す情報とその操作対象範囲を表す情報を読み出すようにしたものである。

この発明の第１の観点によれば、利用者が操作要求により業務種別を指定すると、この業務種別に対応する業務の操作内容を表す情報と操作対象範囲を表す情報が業務情報テーブルから読み出される。そして、この操作対象範囲に属する個人情報が個人情報データベースから選択され、この選択された個人情報に対し上記読み出された業務の操作内容を表す情報により定義された操作が実行される。したがって、操作対象範囲を表す情報として予め定めた複数の利用者を業務種別に対応付けて予め記憶しておけば、利用者はこれら複数の利用者の個人情報に対し業務内容に応じた操作を行うことが可能となる。すなわち、利用者の個人情報に対し、本人以外に例えば家族や主治医も閲覧等を行うことが可能となる。

この発明の第２の観点によれば、業務の操作内容を表す情報と操作対象となる個人又は集合を表す情報を第１のテーブルに記憶し、上記操作対象となる個人又は集合に属する複数の利用者の利用者識別情報を第２のテーブルに記憶するようにしたので、第１のテーブルに操作対象となる個人又は集合に属する複数の利用者の識別情報を含む全ての情報を記憶する場合に比べ、テーブルの記憶容量を減らすことができ、かつ操作対象となる個人又は集合に属する複数の利用者の識別情報の追加、更新又は削除を簡単かつ短時間に行えるようになる。

この発明の第３の観点によれば、操作要求元として許可された利用者の識別情報を業務情報テーブルに記憶しておき、操作要求に含まれる操作要求元を表す利用者識別情報が上記業務情報テーブルに記憶されている利用者の識別情報と一致する場合にのみ、操作要求が受付けられる。このため、業務種別によって、操作元を特定の利用者に制限することが可能となる。

すなわちこの発明の各観点によれば、業務種別ごとに予め設定された利用者であれば他者の個人情報に対してもアクセスできるようにし、これにより個人情報の秘匿性を維持しつつ利用者の利便性を高めた個人情報管理装置、方法及びプログラムを提供することができる。

この発明の一実施形態に係る個人情報管理装置を中核とするシステムの全体構成図。 図１に示したシステムの個人情報管理装置（ＰＨＲサーバ）の機能構成を示すブロック図。 図２に示したＰＨＲサーバに設けられた利用者情報テーブルの一例を示す図。 図２に示したＰＨＲサーバに設けられた認証セッション情報管理テーブルの一例を示す図。 図２に示したＰＨＲサーバに設けられた業務定義テーブルの一例を示す図。 図２に示したＰＨＲサーバに設けられた操作対象定義テーブルの一例を示す図。 図２に示したＰＨＲサーバに設けられた健康情報テーブルの一例を示す図。 図２に示したＰＨＲサーバに設けられた医療情報テーブルの一例を示す図。 図１に示したシステムにおけるログイン時のデータの流れを示すシーケンス図。 図１に示したシステムにおけるログイン後の業務実行時のデータの流れを示すシーケンス図。 図１に示したシステムにおけるログアウト時のデータの流れを示すシーケンス図。 図１０に示した業務実行の第１の例を示すシーケンス図。 図１０に示した業務実行の第２の例を示すシーケンス図。

以下、図面を参照してこの発明に係わる実施形態を説明する。
［一実施形態］
（構成）
図１は、この発明の一実施形態に係る個人情報管理装置を中核とするシステムの全体構成図である。
この実施形態に係るシステムは、個人情報管理装置としてのＰＨＲサーバＳＶ１と、ＰＨＲサービスを利用するためのアプリケーションを提供するアプリケーションサーバＳＶ２と、利用者が使用する利用者端末ＴＭ，ＵＴ１〜ＵＴｎと、複数の健康機器ＶＤ１〜ＶＤｋが設置されたヘルスケアスポットＨＳを備えている。そして、健康機器ＶＤ１〜ＶＤｋにより測定された健康情報を、ヘルスケアスポットＨＳから通信ネットワークＮＷを介してＰＨＲサーバＳＶ１に送信し蓄積する。また、利用者端末ＴＭ，ＵＴ１〜ＵＴｎから通信ネットワークＮＷ及びアプリケーションサーバＳＶ２を介してアクセス要求を送信することで、ＰＨＲサーバＳＶ１に蓄積された健康情報や医療情報に対するアクセス制御を可能にする。

なお、通信ネットワークＮＷは、例えばインターネットに代表されるＩＰ（Internet Protocol）網と、このＩＰ網に対しアクセスするための複数のアクセス網とから構成される。アクセス網としては、光ファイバを使用した有線網はもとより、例えば３Ｇ又は４Ｇ等の規格の下で動作する携帯電話網や、無線ＬＡＮ（Local Area Network）等が用いられる。

（１）利用者端末
利用者端末ＴＭは、例えば固定設置されたパーソナル・コンピュータからなる。また利用者端末ＵＴ１〜ＵＴｎは、フィーチャーフォン、スマートフォン又はタブレット型端末等の携帯端末からなる。これらの利用者端末ＴＭ，ＵＴ１〜ＵＴｎは、何れも電子メールを送受信するためのメーラ、Ｗｅｂアクセスするためのブラウザを備えている。

利用者端末ＴＭは、ブラウザにより例えばＬＡＮ（図示せず）を介してアプリケーションサーバＳＶ２が提供するアプリケーションに対しアクセスする。また、携帯端末からなる利用者端末ＵＴ１〜ＵＴｎは、通信インタフェースＮＷを介してアプリケーションサーバＳＶ２に対しアクセスする。そして、利用者端末ＴＭ，ＵＴ１〜ＵＴｎは、上記アプリケーションサーバＳＶ２が提供するアプリケーションを選択的に利用することで、ＰＨＲサーバＳＶ１に蓄積された健康情報又は医療情報に対し、要求した業務に対応する操作を行う。

（２）健康機器
健康機器ＶＤ１〜ＶＤｋは、例えば血圧計、体温計、歩数計、体重組成計又は血糖計からなり、その各測定データをヘルスケアスポットＨＳ内に設けられたルータ、ゲースウェイ等のネットワーク接続機器へ送信する。ネットワーク接続機器は、上記健康機器ＶＤ１〜ＶＤｋから送信された測位データを、利用者の識別情報と共に通信ネットワークＮＷを介してＰＨＲサーバＳＶ１へ転送する。

なお、健康機器ＶＤ１〜ＶＤｋとネットワーク接続機器との間は、ＵＳＢケーブル又は近距離無線ネットワークを介して接続される。近距離無線ネットワークとしては、例えばBluetooth（登録商標）等の小電力無線データ伝送規格を採用した無線ネットワークが用いられる。

（３）アプリケーションサーバ
アプリケーションサーバＳＶ２は、ＰＨＲサーバＳＶ１に蓄積された健康情報又は医療情報を利用した複数種類の業務を実行するためのアプリケーション（ＡＰＬ）を備える。そして、利用者端末ＴＭ，ＵＴ１〜ＵＴｎに上記各業務のメニューを表示し、利用者がこれらの業務種別の一つを選択した場合に、対応するアプリケーションが起動してＰＨＲサーバＳＶ１との間で認証処理及び業務実行のための一連の処理を行う。

（４）ＰＨＲサーバ
ＰＨＲサーバＳＶ１は、例えば健康サービス事業者がＷｅｂ上で管理運用するもので、以下のように構成される。図２はその機能構成を示すブロック図である。
すなわち、ＰＨＲサーバＳＶ１は、制御ユニット１と、通信インタフェース２と、記憶ユニット３を備えている。

通信インタフェース２は、制御ユニット１の制御の下、上記ヘルスケアスポットＨＳとの間、及びアプリケーションサーバＳＶ２との間で、それぞれ通信ネットワークＮＷで規定されるプロトコルに従いデータ通信を行う。

記憶ユニット３は、記憶媒体としてＨＤＤ（Hard Disc Drive）又はＳＳＤ（Solid State Drive）等の随時書込及び読出しが可能な不揮発性メモリを用いたもので、利用者情報データベース３１、認証セッション情報管理テーブル３２及び個人情報データベース３３に加えて、第１のテーブルとしての業務定義テーブル３４と、第２のテーブルとしての操作対象定義テーブル３５を備えている。

利用者情報データベース３１は、ＰＨＲサービスに対する利用登録が完了した利用者に関する認証情報及び属性情報を記憶する。図３はその一例を示すもので、利用者の識別情報（Patient ID）に関連付けて、利用者の氏名、Login ID、Password、BirthDay、sex、Tel Noを記憶している。

認証セッション情報管理テーブル３２は、利用者がＰＨＲサービスを利用する際に、ＰＨＲサーバＳＶ１とアプリケーションサーバＳＶ２との間に設定されるセッションに関する情報を一時的に保持するために使用される。図４はその一例を示すもので、Patient IDに関連付けて、Session ID、Activation Time、Deactivation Timeが保存される。

個人情報データベース３３は、健康情報テーブル３３１と、医療情報テーブル３３２を備え、それぞれヘルスケアスポットＨＳから受信した健康情報、及び医療機関の検査で得られた医療情報を記憶する。図７及び図８はその一例を示すものである。健康情報テーブル３３１には、Serial Noに対応付けて、Data Type、Value、Patient ID、及びMeasuring Dateが記憶される。医療情報テーブル３３２にも同様に、Serial Noに対応付けて、Data Type、Value、Patient ID、及びMeasuring Dateが記憶される。なお、以後、上記健康情報及び医療情報をまとめて個人情報と呼称する。

業務定義テーブル３４は、ＰＨＲサーバＳＶ１に蓄積された個人情報を利用した業務に関する情報を記憶するために使用される。業務に関する情報は、業務種別（Work）と、要求元の利用者（Access User）と、業務を遂行するための操作内容を表す情報（API）と、操作対象となる個人又はグループを表す情報（Subject）を含む。APIは、操作対象となる情報のカテゴリ（Category）と、操作内容の種類（CRUD）と、操作対象となるデータタイプ（Data type）とから構成される。図５にその一例を示す。なお、CRUDとは、作成（Create）、読み出し（Read）、更新（Update）、削除（Delete）の頭文字を表す。

操作対象定義テーブル３４は、上記業務定義テーブル３３で定義された、操作対象となる個人又はグループを表す情報（Subject）に関連付けて、当該個人の利用者又はグループに属する複数の利用者の識別情報（Patient ID）を記憶するために用いられる。図６はその一例を示すもので、Subject_group に関連付けてそのMemberのPatient IDが記憶されている。

制御ユニット１はＣＰＵ（Central Processing Unit）を備え、この実施形態に係るＡＰＩを実現する上で必要な処理機能として、認証処理部１１と、業務／ＡＰＩ変換処理部１２と、業務／操作対象変換処理部１３と、ＡＰＩ実行処理部１４を備えている。なお、これらの処理機能は、何れも図示しないプログラムメモリに格納されたプログラムを上記ＣＰＵに実行させることにより実現される。

認証処理部１１は、以下の処理機能を有する。
(1) アプリケーションサーバＳＶ２から要求元の利用者のLogin IDとPasswordを含む認証処理要求が送られた場合に、当該Login ID及びPasswordをもとに利用者情報テーブル３１を検索し、該当する利用者が登録されているか否かを判定する。そして、該当する利用者が登録されていた場合には、Session IDを発行して当該Session IDを認証結果と共にアプリケーションサーバＳＶ２に通知する処理。
(2) 上記該当する利用者が登録されていた場合に、利用者情報テーブル３１から対応するPatient IDを読み出し、上記発行されたSession IDをActivation Time及びDeactivation Timeと共に、上記Patient IDと関連付けて認証セッション情報管理テーブル３２に格納する処理。

業務／ＡＰＩ変換処理部１２は、以下の処理機能を有する。
(1) アプリケーションサーバＳＶ２から要求業務情報とSession IDが送られた場合に、認証セッション情報管理テーブル４から対応するPatient IDを読み出す処理。
(2) 上記受信した要求業務情報に対応するAssess Userを業務定義テーブル３４から読み出し、Assess Userとして“ＮＵＬＬ”が設定されているか否かを判定する。そして、“ＮＵＬＬ”が設定されていれば、操作元の指定がないので、上記認証セッション情報管理テーブル４から読み出されたPatient IDをそのままAssess Userとして設定する処理。
(3) 上記業務定義テーブル３４から読み出されたAssess Userに予めPatient IDが設定されている場合には、上記認証セッション情報管理テーブル４から読み出されたPatient IDを上記Assess Userとして設定されていたPatient IDと照合し、一致すれば上記要求を有効とし、一致しない場合には上記要求を廃棄する処理。
(4) 上記受信された要求業務情報に対応するAPIを業務定義テーブル３４から読み出す処理。

業務／操作対象変換処理部１３は、上記受信された要求業務情報に対応する操作対象を表す情報Subjectを業務定義テーブル３４から読み出す。そして、この読み出されたSubjectに属する利用者のPatient IDを、操作対象定義テーブル３５から読み出す処理を行う。

ＡＰＩ実行処理部１４は、上記操作対象定義テーブル３５から読み出されたPatient IDをもとに、健康情報テーブル３３１又は医療情報テーブル３３２から操作対象となる利用者の健康情報又は医療情報を選択する。そして、この選択された利用者の健康情報又は医療情報に対し、上記業務定義テーブル３４から読み出されたAPIにより定義された操作を実行し、その結果に相当する情報を要求元のアプリケーションサーバＳＶ２へ返送する処理を行う。

（動作）
次に、以上のように構成されたＰＨＲサーバＳＶ１の動作を説明する。
ここでは、ＰＨＲサービスに対し既に利用登録が完了した利用者が、利用者端末ＴＭのアプリケーションを利用して、ＰＨＲサーバＳＶ１に蓄積された個人情報に対し希望する業務に対応する操作を実行させる場合を例にとって説明する。

（１）ＰＨＲサーバＳＶ１に対するログイン
図９にこのログイン時のシーケンスを示す。
利用者が利用者端末ＴＭを操作し、ブラウザの機能を用いてアプリケーションサーバＳＶ２に対しアクセスすると、アプリケーションサーバＳＶ２からログイン画面＋クッキーが送られて利用者端末ＴＭに表示される。この状態で利用者が、ＰＨＲサービスへの利用登録時に予め割り当てられたLogin IDとPasswordを入力すると、この入力されたLogin ID及びPasswordが認証情報として利用者端末ＴＭからアプリケーションサーバＳＶ２へ送られる。

アプリケーションサーバＳＶ２は、上記認証情報を受信すると、この認証情報に含まれるLogin ID及びPasswordを含む認証処理要求をＰＨＲサーバＳＶ１へ送信する。

ＰＨＲサーバＳＶ１は、上記認証処理要求を通信インタフェース２で受信すると、認証処理部１１の制御の下で以下の認証処理を実行する。すなわち、先ず上記受信された認証処理要求に含まれるLogin ID及びPasswordをもとに利用者情報テーブル３１を検索し、該当する利用者が登録されているか否かを判定する。そして、該当する利用者が登録済であれば、Session IDを発行して当該Session IDを認証結果と共にアプリケーションサーバＳＶ２に返送する。次に、利用者情報テーブル３１から対応するPatient IDを読み出し、上記発行されたSession IDをActivation Time及びDeactivation Timeと共に、上記Patient IDと関連付けて認証セッション情報管理テーブル３２に格納する。

例えば、いま利用者の「田中浩二」がLogin ID＝tanakatanaka及びPassword＝ABCDEを入力して認証を要求したとする。この場合、Login ID＝tanakatanaka及びPassword＝ABCDEは、図３に示すように利用者情報テーブル３１に既に登録されているので、要求元の利用者は登録済と判定される。そして、Session ID＝rfhbfgredghが発行され、認証結果を表す情報が上記発行されたSession ID＝4rswfyuir9l 共にアプリケーションサーバＳＶ２に返送される。またそれと共に、上記発行されたSession ID＝4rswfyuir9lが、Activation Timeと共に、上記利用者「田中浩二」のPatient IDと関連付けられて、認証セッション情報管理テーブル３２に図４に示すように格納される。

ＰＨＲサーバＳＶ１から上記認証結果が返送されると、アプリケーションサーバＳＶ２は業務リストの表示画面データを生成して利用者端末ＴＭへ送信する。利用者端末ＴＭでは上記業務リストが表示される。かくして、利用者端末ＴＭとＰＨＲサーバＳＶ１との間には、アプリケーションサーバＳＶ２を介して、利用者「田中浩二」に対するセッションが確立される。

（２）業務の実行
図１０に業務実行シーケンスの一例を示す。
上記業務リストが表示された状態で、利用者が実行を希望する業務を選択すると、当該選択された業務の実施要求がアプリケーションサーバＳＶ２へ送られる。上記業務実施要求を受信するとアプリケーションサーバＳＶ２は、実施を要求する業務名を表す要求業務情報を、認証処理時にＰＨＲサーバＳＶ１から通知されたSession IDと共にＰＨＲサーバＳＶ１へ送信する。

上記要求業務情報を受信するとＰＨＲサーバＳＶ１は、以下のように業務の実行処理を行なう。
すなわち、先ず業務／ＡＰＩ変換処理部１２の制御の下で、上記要求業務情報と共に受信されたSession IDをもとに認証セッション情報管理テーブル３２を検索し、認証セッション情報管理テーブル３２から対応するPatient IDを読み出す。

次に、上記受信した要求業務情報に対応するAssess Userを業務定義テーブル３４から読み出し、Assess Userとして“ＮＵＬＬ”が設定されているか否かを判定する。そして、“ＮＵＬＬ”であれば、操作元の指定がないので、上記認証セッション情報管理テーブル４から読み出されたPatient IDをそのままAssess Userとして設定する。なお、上記業務定義テーブル３４から読み出されたAssess Userに予めPatient IDが設定されている場合には、上記認証セッション情報管理テーブル４から読み出されたPatient IDを上記Assess Userとして設定されていたPatient IDと照合し、一致すれば上記要求を有効とし、一致しない場合には上記要求を廃棄する。

次に、上記受信された要求業務情報に対応するAPIを業務定義テーブル３４から読み出す。また、業務／操作対象変換処理部１３の制御の下で、上記受信された要求業務情報に対応する操作対象を表す情報Subjectを業務定義テーブル３４から読み出す。そして、この読み出されたSubjectに属する利用者のPatient IDを、操作対象定義テーブル３５から読み出す。

次に、ＡＰＩ実行処理部１４の制御の下で、上記操作対象定義テーブル３５から読み出されたPatient IDをもとに、健康情報テーブル３３１又は医療情報テーブル３３２から操作対象となる利用者の健康情報又は医療情報を選択する。そして、この選択された利用者の健康情報又は医療情報に対し、上記業務定義テーブル３４から読み出されたAPIにより定義された操作を実行し、その結果に相当する情報を要求元のアプリケーションサーバＳＶ２へ返送する。

アプリケーションサーバＳＶ２は、上記ＰＨＲサーバＳＶ１から業務に対応する操作の実行結果を表す情報を受信すると、この受信された情報を利用者に通知するための表示データを生成し、この生成された表示データを利用者端末ＴＭへ送信する。

ここで、業務に対応する操作の具体的な実行例を説明する。
（２−１）利用者「田中浩二」が自身の健康情報を閲覧する場合
図１２はその処理手順と処理内容を示すシーケンス図である。
いま、業務の種類として図５の業務定義テーブルに示したように７種類の業務が定義されており、表示された業務リストの中から利用者「田中浩二」が「個人情報取得」を選択したとする。そうすると、この「個人情報取得」を表す識別情報が利用者端末ＴＭからアプリケーションサーバＳＶ２へ送られる。アプリケーションサーバＳＶ２は、上記「個人情報取得」と、先に認証処理においてＰＨＲサーバＳＶ１から発行されたSession ID＝4rswfyuir9lをＰＨＲサーバＳＶ１へ送信する。

ＰＨＲサーバＳＶ１は、アプリケーションサーバＳＶ２から上記「個人情報取得」とSession ID＝4rswfyuir9lを受信すると、先ず上記受信されたSession ID＝4rswfyuir9lをもとに認証セッション情報管理テーブル３２を検索し、認証セッション情報管理テーブル３２から対応するPatient ID＝694872を読み出す。

次に、上記受信した「個人情報取得」に対応するAssess Userを業務定義テーブル３４から読み出し、Assess Userとして“ＮＵＬＬ”が設定されているか否かを判定する。そして、いま業務定義テーブル３４には図５に示すように要求元を指定しない“ＮＵＬＬ”が設定されているので、上記認証セッション情報管理テーブル４から読み出されたPatient ID＝694872をそのままAssess Userとして設定する。

なお、業務種別として「健診状況確認」が選択された場合のように、業務定義テーブル３４のAssess Userに図５に示すように予めPatient ID＝266595が設定されている場合には、上記認証セッション情報管理テーブル４から読み出されたPatient ID＝694872を上記Assess Userとして予め設定されていたPatient ID＝266595と照合する、そして、この場合は一致しないので上記要求を廃棄する。

続いて、上記受信された「個人情報取得」に対応するAPI＝バイタル，CRUD，ALLを業務定義テーブル３４から読み出す。また、上記受信された「個人情報取得」に対応する操作対象を表す情報Subjectを業務定義テーブル３４から読み出す。いま、Subject＝ＮＵＬＬなので、操作対象Subjectとして要求元の利用者のPatient ID＝694872を設定する。

次に、上記操作対象として設定したPatient ID＝694872をもとに、個人情報データベース３３から該当する個人情報を選択する。この場合、上記業務定義テーブル３４から読み出されたAPIには操作対象のデータ種別としてCategory＝バイタルが設定されているため、健康情報テーブル３３１からPatient ID＝694872に対応付けられた健康情報が選択される。そして、この選択されたPatient ID＝694872に対応する健康情報に対し、上記業務定義テーブル３４から読み出されたAPIの操作内容CRUDに従い操作を実行する。

いま、利用者「田中浩二」の操作要求は「個人情報取得」であるため、健康情報テーブル３３１から上記Patient ID＝694872に対応付けられた健康情報が読み出される。例えば、健康情報テーブル３３１には図７に示すようにPatient ID＝694872に対応付けて「最高血圧」、「最低血圧」、「脈」及び「歩数」の各測定データが記憶されているため、これらの測定データがそれぞれ読み出される。

そして、この読み出された各測定データは要求元のアプリケーションサーバＳＶ２へ返送される。アプリケーションサーバＳＶ２は、上記ＰＨＲサーバＳＶ１から返送された測定データを受信すると、この受信された測定データの表示データを生成して利用者端末ＴＭへ送信し表示させる。この結果、利用者端末ＴＭには、上記「最高血圧」、「最低血圧」、「脈」及び「歩数」の測定データが表示され、利用者「田中浩二」は自身の測定データを確認することが可能となる。

（２−２）利用者「田中浩二」が家族（田中美奈子）の健康情報を閲覧する場合
図１３はその処理手順と処理内容を示すシーケンス図である。
利用者端末ＴＭにおいて、表示された業務リストの中から利用者「田中浩二」が「家族バイタル」を選択したとする。そうすると、この「家族バイタル」を表す識別情報が利用者端末ＴＭからアプリケーションサーバＳＶ２へ送られる。アプリケーションサーバＳＶ２は、上記「家族バイタル」と、先に認証処理においてＰＨＲサーバＳＶ１から発行されたSession ID＝4rswfyuir9lをＰＨＲサーバＳＶ１へ送信する。

ＰＨＲサーバＳＶ１は、アプリケーションサーバＳＶ２から上記「家族バイタル」とSession ID＝4rswfyuir9lを受信すると、先ず上記受信されたSession ID＝4rswfyuir9lをもとに認証セッション情報管理テーブル３２を検索し、認証セッション情報管理テーブル３２から対応するPatient ID＝694872を読み出す。

次に、上記受信した「家族バイタル」に対応するAssess Userを業務定義テーブル３４から読み出し、Assess Userとして“ＮＵＬＬ”が設定されているか否かを判定する。そして、いま業務定義テーブル３４には図５に示すように要求元を指定しない“ＮＵＬＬ”が設定されているので、上記認証セッション情報管理テーブル４から読み出されたPatient ID＝694872をそのままAssess Userとして設定する。

続いて、上記受信された「家族バイタル」に対応するAPI＝バイタル，*R**，ALLを業務定義テーブル３４から読み出す。また、上記受信された「家族バイタル」に対応する操作対象を表す情報Subjectを業務定義テーブル３４から読み出す。そして、Subject＝Session ID＋家族なので、操作対象定義テーブル３５から694872＿家族に対応付けられて記憶されているMember＝694872，645200を読み出し、この読み出された694872，645200を操作対象として設定する。

次に、上記操作対象として設定したPatient ID＝694872，645200をもとに、個人情報データベース３３から該当する個人情報を選択する。この場合、上記業務定義テーブル３４から読み出されたAPIには操作対象のデータ種別としてCategory＝バイタルが設定されているため、健康情報テーブル３３１からPatient ID＝694872，645200に対応付けられた健康情報が全て選択される。

そして、この選択されたPatient ID＝694872，645200に対応する健康情報に対し、上記業務定義テーブル３４から読み出されたAPIの操作内容CRUDに従い操作を実行する。すなわち、いまAPIの操作内容は*R**であるため、健康情報テーブル３３１から上記Patient ID＝694872，645200に対応付けられた健康情報がそれぞれ読み出される。例えば、健康情報テーブル３３１には図７に示すようにPatient ID＝694872に対応付けて「最高血圧」、「最低血圧」、「脈」及び「歩数」の各測定データが記憶され、さらにPatient ID＝645200に対応付けて「歩数」の測定データが記憶されているため、これらの測定データがそれぞれ読み出される。

そして、この読み出された各測定データは要求元のアプリケーションサーバＳＶ２へ返送される。アプリケーションサーバＳＶ２は、上記ＰＨＲサーバＳＶ１から返送された測定データを受信すると、この受信された測定データの表示データを生成して利用者端末ＴＭへ送信し表示させる。

この結果、利用者端末ＴＭには、利用者「田中浩二」の「最高血圧」、「最低血圧」、「脈」及び「歩数」の測定データと、家族「田中美奈子」の「歩数」の測定データがそれぞれ表示される。したがって、利用者「田中浩二」は自身の各測定データと併せて、家族「田中美奈子」の「歩数」の測定データを確認することが可能となる。

以後同様に、利用者が業務リストに表示された異なる業務を選択するごとに、この選択された業務種別に対応付けて業務定義テーブル３４及び操作対象定義テーブル３５に定義されたSubject Memberの個人情報に対し、業務定義テーブル３４のAPIで定義された内容の操作が実行される。

（３）ログアウト
図１１にこのログアウト時のシーケンスを示す。
利用者端末ＴＭに表示された業務リスト表示画面において、利用者がログアウトボタンをクリックしたとする。そうすると、この入力されたログアウト情報が利用者端末ＴＭからアプリケーションサーバＳＶ２へ送られる。アプリケーションサーバＳＶ２は、上記ログアウト情報を受信すると、ログアウト処理要求をSession IDと共にＰＨＲサーバＳＶ１へ送信する。

ＰＨＲサーバＳＶ１は、上記ログアウト処理要求を通信インタフェース２で受信すると、当該ログアウト処理要求と共に受信したSession IDを無効にする。また、認証セッション情報管理テーブル３２の対応するPatient IDに関連付けられているDeactivation Timeにセッション終了時刻を記載する。そして、ログアウトの結果を表す情報を要求元のアプリケーションサーバＳＶ２へ返送する。アプリケーションサーバＳＶ２は、上記ログアウト結果を表す情報を受信すると、利用者端末ＴＭへログアウト後の表示画面データを送り表示させる。

（効果）
以上詳述したようにこの実施形態では、ＰＨＲサーバＳＶ１の記憶ユニット３に、業務定義テーブル３４及び操作対象定義テーブル３５をさらに設けている。そして、アプリケーションサーバＳＶ２からの認証要求に対し認証を行ってSession IDを発行したのち、利用者端末ＴＭからの業務実施要求に応じて、先ず業務定義テーブル３４から対応するAccess Userを読み出して指定の有無を判定し、指定がなければ業務定義テーブル３４からAPIを読み出すと共に、操作対象定義テーブル３５から操作対象となる利用者のPatient IDを読み出す。そして、この読み出されたPatient IDに関連付けて記憶された健康情報又は医療情報を健康情報テーブル３３１又は医療情報テーブル３３２から選択し、この選択された情報に対し上記読み出されたAPIにより定義された操作内容の操作を行い、その結果を要求元へ返送するようにしている。

したがって、業務種別に対応付けて操作対象とする利用者を操作対象定義テーブル３５に予め登録しておけば、利用者はこれら複数の利用者の健康情報又は医療情報に対し要求した業務内容に応じた操作を行うことが可能となる。すなわち、利用者の健康情報や医療情報に対し、本人以外の例えば家族や主治医が閲覧等を行うことが可能となる。

また、操作対象定義テーブル３５を業務定義テーブル３４とは独立して設け、操作対象となる個人又は集合に属する利用者のPatient IDをこの操作対象定義テーブル３５に記憶させてこれを共有するようにしている。このため、業務定義テーブル３４において各業務種別に対応付けてそれぞれ操作対象となる利用者のPatient IDを記憶しておく場合に比べ、業務定義テーブル３４の記憶容量を減らすことができ、かつ操作対象となる個人又は集合に属する複数の利用者のPatient IDの追加、更新又は削除を簡単かつ短時間に行うことが可能となる。

さらに、利用者端末ＴＭから要求された業務情報に対応するAssess Userを業務定義テーブル３４から読み出し、Assess Userとして予めPatient IDが設定されている場合には、認証セッション情報管理テーブル４から読み出されたPatient IDを上記Assess Userとして設定されていたPatient IDと照合し、一致すれば上記要求を有効とし、一致しない場合には上記要求を廃棄するようにしている。したがって、業務種別によって、操作元を利用者を制限することが可能となり、これにより特定の情報に対する秘匿性を高く保持することができる。

［他の実施形態］
前記実施形態では、業務定義テーブル３４と操作対象定義テーブル３５とを別々に設けたが、操作対象定義テーブルで定義された操作対象者（Member）を業務定義テーブルのSubjectに記載するようにしてもよい。

前記実施形態ではＰＨＲサーバＳＶ１内に記憶ユニット３を設けた場合を例にとって説明したが、記憶ユニット３をＰＨＲサーバＳＶ１とは独立する蓄積サーバに設け、これらのサーバ間をＷＡＮやＬＡＮ（Local Area Network）等のネットワークを介して接続するようにしてもよい。

また、前記実施形態では個人情報として健康情報及び医療情報を取り扱う場合を例にとって説明したが、個人情報としては例えば利用者のスケジュール情報や行動履歴情報、会議議事録、人事情報等を取り扱う場合にも、この発明は同様に適用可能である。
その他、個人情報管理装置の種類と構成、各データベース及びテーブルの構成、業務実施要求を受信してからその結果情報を返送するまでのＰＨＲサーバＳＶ１における処理手順と処理内容、業務の種類とそれに対応する操作内容等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。

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

ＳＶ１…ＰＨＲサーバ、ＳＶ２…アプリケーションサーバ、ＴＭ，ＵＴ１〜ＵＴｎ…利用者端末、ＨＳ…ヘルスケアスポット、ＶＤ１〜ＶＤｋ…健康機器、ＮＷ…通信ネットワーク、１…制御ユニット、２…通信インタフェース、３…記憶ユニット、１１…認証処理部、１２…業務／ＡＰＩ変換処理部、１３…業務／操作対象変換処理部、１４…ＡＰＩ実行処理部、３１…利用者情報データベース、３２…認証セッション情報管理テーブル、３３…個人情報データベース、３３１…健康情報テーブル、３３２…医療情報テーブル、３４…業務定義テーブル、３５…操作対象定義テーブル。

Claims (7)

1. 利用者ごとに、その利用者識別情報に対応付けて、当該利用者の個人情報を記憶する個人情報データベースと、
   業務ごとに、その業務種別を表す情報に対応付けて、当該業務の操作内容を表す情報及びその操作対象範囲を表す情報を少なくとも記憶する業務情報テーブルと、
   利用者が使用するアクセス装置から、業務種別を表す情報を含む操作要求を受信した場合に、当該受信された業務種別を表す情報をもとに前記業務情報テーブルを検索して、対応する業務の操作内容を表す情報とその操作対象範囲を表す情報を読み出す手段と、
   前記読み出された操作対象範囲に属する個人情報を前記個人情報データベースから選択し、この選択された個人情報に対し前記読み出された業務の操作内容を表す情報により定義された操作を実行する手段と
   を具備することを特徴とする個人情報管理装置。
2. 前記業務情報テーブルは、
   業務種別を表す情報に対応付けて、当該業務の操作内容を表す情報と、操作対象となる個人又は集合を表す情報を記憶する第１のテーブルと、
   前記操作対象となる個人又は集合を表す情報に対応付けて、当該個人に対応する利用者又は集合に属する複数の利用者の利用者識別情報を記憶する第２のテーブルと
   を備え、
   前記読み出す手段は、
   利用者が使用するアクセス装置から前記操作要求を受信した場合に、前記第１のテーブルから、前記受信された操作要求に含まれる業務種別を表す情報に対応する業務の操作内容を表す情報と操作対象となる個人又は集合を表す情報を読み出す手段と、
   前記第２のテーブルから、前記読み出された操作対象となる個人又は集合を表す情報に対応する利用者の利用者識別情報を読み出す手段と
   を備えることを特徴とする請求項１記載の個人情報管理装置。
3. 前記業務情報テーブルは、業務種別を表す情報に対応付けて、操作要求元として許可された利用者の識別情報をさらに記憶し、
   前記読み出す手段は、
   利用者が使用するアクセス装置から、業務種別を表す情報と操作要求元を表す利用者識別情報を含む操作要求を受信した場合に、前記業務情報テーブルから、前記受信された操作要求に含まれる業務種別を表す情報に対応する操作要求元として許可された利用者の識別情報を読み出し、前記受信された操作要求に含まれる操作要求元を表す利用者識別情報が前記読み出された利用者の識別情報と一致するか否かを判定する手段と、
   前記判定する手段により一致すると判定された場合に、前記業務情報テーブルから、前記受信された業務種別を表す情報に対応する業務の操作内容を表す情報とその操作対象範囲を表す情報を読み出す手段と
   を備えることを特徴とする請求項１又は２記載の個人情報管理装置。
4. 利用者ごとに、その利用者識別情報に対応付けて、当該利用者の個人情報を記憶する個人情報データベースと、業務ごとに、その業務種別を表す情報に対応付けて、当該業務の操作内容を表す情報及びその操作対象範囲を表す情報を少なくとも記憶する業務情報テーブルとを備える個人情報管理装置が実行する個人情報管理方法であって、
   利用者が使用するアクセス装置から、業務種別を表す情報を含む操作要求を受信した場合に、当該受信された業務種別を表す情報をもとに前記業務情報テーブルを検索して、対応する業務の操作内容を表す情報とその操作対象範囲を表す情報を読み出す過程と、
   前記読み出された操作対象範囲に属する個人情報を前記個人情報データベースから選択し、この選択された個人情報に対し前記読み出された業務の操作内容を表す情報により定義された操作を実行する過程と
   を具備することを特徴とする個人情報管理方法。
5. 前記業務情報テーブルが、業務種別を表す情報に対応付けて、当該業務の操作内容を表す情報と、操作対象となる個人又は集合を表す情報を記憶する第１のテーブルと、前記操作対象となる個人又は集合を表す情報に対応付けて、当該個人に対応する利用者又は集合に属する複数の利用者の利用者識別情報を記憶する第２のテーブルとを備える場合に、
   前記読み出す過程は、
   利用者が使用するアクセス装置から前記操作要求を受信した場合に、前記第１のテーブルから、前記受信された操作要求に含まれる業務種別を表す情報に対応する業務の操作内容を表す情報と操作対象となる個人又は集合を表す情報を読み出す過程と、
   前記第２のテーブルから、前記読み出された操作対象となる個人又は集合を表す情報に対応する利用者の利用者識別情報を読み出す過程と
   を備えることを特徴とする請求項４記載の個人情報管理方法。
6. 前記業務情報テーブルが、業務種別を表す情報に対応付けて、操作要求元として許可された利用者の識別情報をさらに記憶する場合に、
   前記読み出す過程は、
   利用者が使用するアクセス装置から、業務種別を表す情報と操作要求元を表す利用者識別情報を含む操作要求を受信した場合に、前記業務情報テーブルから、前記受信された操作要求に含まれる業務種別を表す情報に対応する操作要求元として許可された利用者の識別情報を読み出し、前記受信された操作要求に含まれる操作要求元を表す利用者識別情報が前記読み出された利用者の識別情報と一致するか否かを判定する過程と、
   前記判定する手段により一致すると判定された場合に、前記業務情報テーブルから、前記受信された業務種別を表す情報に対応する業務の操作内容を表す情報とその操作対象範囲を表す情報を読み出す過程と
   を備えることを特徴とする請求項４又は５記載の個人情報管理方法。
7. 請求項１乃至３のいずれかに記載の個人情報管理装置が具備する手段が行う処理を、前記個人情報管理装置が備えるコンピュータに実行させるプログラム。

Images