JP7047655B2 - 情報提供装置、情報提供方法、及び情報提供プログラム - Google Patents

Description

本件は、情報提供装置、情報提供方法、及び情報提供プログラムに関する。

ウェブサービスにパーソナルデータを提供する仕組みが知られている（例えば、特許文献１参照）。

特開２０１７－１５１９４２号公報

ところで、上述した仕組み以外にも、個人（以下、ユーザという）が自らの意志で自らのデータ（例えばパーソナルデータなど）を蓄積・管理するための仕組みとしてPersonal Data Store（ＰＤＳ）が提案されている。そして、ＰＤＳを用いて実装された情報銀行も提案されている。ＰＤＳ又は情報銀行（以下、単にＰＤＳという）はユーザの指示、または予め指定した条件に基づきユーザに代わり妥当性を判断の上、データを第三者に提供する。

例えば、ユーザが健康診断の際に保健センターに提示した個人情報や健康診断の診断結果に関するデータをＰＤＳに預託すると、ＰＤＳは病院などの第三者にデータを提供する際、データを安全に第三者に提供する必要性から、ユーザ本人の同意を取得してから、データを提供する。これにより、第三者はＰＤＳから提供された情報を利活用することができる。

しかしながら、第三者にデータを提供する場合、ＰＤＳはデータを提供する度にユーザ本人から同意を取得することが好ましいが、ユーザにとっては度重なる同意の手続きには手間がかかるという問題がある。

そこで、１つの側面では、ユーザに対する同意手続きを軽減できる情報提供装置、情報提供方法、及び情報提供プログラムを提供することを目的とする。

１つの実施態様では、情報提供装置は、ユーザから第１の時期に同意を得て前記ユーザ以外の第三者に提供した前記ユーザのパーソナルデータを記憶するデータ記憶部と、前記パーソナルデータを前記第１の時期より後の第２の時期に前記第三者に提供する場合、前記パーソナルデータの前記第１の時期の情報量と前記第２の時期の情報量を比較し、前記第１の時期の情報量と前記第２の時期の情報量が異なる場合、異なる情報の変化量に応じて、前記ユーザからの同意の取得要否を判断する、処理を実行する処理部と、を有する。

ユーザに対する同意手続きを軽減することができる。

図１は第１実施形態に係る情報提供システムの一例を説明するための図である。 図２はＰＤＳサーバのハードウェア構成の一例である。 図３はＰＤＳサーバのブロック図の一例である。 図４はデータ記憶部の一例である。 図５は同意情報記憶部の一例である。 図６は第１実施形態に係るＰＤＳサーバの動作の一例を示すフローチャートである。 図７は医療端末に表示されるデータ要求画面の一例である。 図８はユーザ端末に表示される提供同意確認画面の一例である。 図９（ａ）は同意情報を管理する管理テーブルの一例である。図９（ｂ）は同意情報を管理する管理テーブルの他の一例である。 図１０（ａ）は病歴データを管理する管理テーブルの一例である。図１０（ｂ）は病歴データを管理する管理テーブルの他の一例である。 図１１はユーザ端末に表示される提供同意確認画面の他の一例である。 図１２は第２実施形態に係る情報提供システムの一例である。 図１３は第２実施形態に係るＰＤＳサーバの動作の一部を例示するフローチャートである。 図１４はＥＰ図の一例である。

以下、本件を実施するための形態について図面を参照して説明する。

（第１実施形態）
図１は第１実施形態に係る情報提供システムＳＴの一例を説明するための図である。第１実施形態に係る情報提供システムＳＴはセンター端末１００とＰＤＳサーバ２００と医療端末３００とユーザ端末４００とを備えている。ＰＤＳサーバ２００は情報提供装置の一例である。センター端末１００、ＰＤＳサーバ２００、及び医療端末３００は通信ネットワークＮＷを介して互いに接続されている。通信ネットワークＮＷとしては、例えばインターネットがある。

また、通信ネットワークＮＷには携帯基地局ＢＳが接続されている。したがって、ユーザ端末４００が携帯基地局ＢＳの通信可能領域ＡＲ内に位置していれば、ユーザ端末４００は無線通信ＷＬを利用して通信ネットワークＮＷに接続することができる。尚、無線通信ＷＬとしては、例えばLong Term Evolution（ＬＴＥ）などが利用される。このように、センター端末１００、医療端末３００、及びユーザ端末４００はいずれもＰＤＳサーバ２００にアクセスすることができる。

センター端末１００はパーソナルデータをＰＤＳサーバ２００に提供する施設に設置される。第１実施形態では、図１に示すように、センター端末１００は健康診断を実施する保健センターに設置されている。センター端末１００としては例えばPersonal Computer（ＰＣ）などがある。保健センターにおいて例えばユーザＵＡの健康診断が終了すると、健診担当者１０はユーザＵＡに由来する各種のパーソナルデータをセンター端末１００に入力する。第１実施形態に係るパーソナルデータとしては、ユーザＵＡの氏名や住所といった個人情報を含む基本データ、身長や体重といった健康診断の結果を含む健診データ、ユーザＵＡが患った病気の病歴を含む病歴データ、血圧や脈拍などを含むバイタルデータなどがある。センター端末１００はパーソナルデータが入力されると、入力されたパーソナルデータをＰＤＳサーバ２００に登録する。尚、センター端末１００がパーソナルデータをユーザ端末４００に送信し、ユーザ端末４００がパーソナルデータをＰＤＳサーバ２００に登録してもよい。

ＰＤＳサーバ２００はＰＤＳが実装されたサーバ装置である。ＰＤＳサーバ２００はクラウドサービスを提供するデータセンターＤＣに設置される。ＰＤＳサーバ２００はセンター端末１００から登録されたパーソナルデータを蓄積して管理する。詳細は後述するが、ＰＤＳサーバ２００は医療端末３００からパーソナルデータの取得を要求するデータ取得要求を受信する。ＰＤＳサーバ２００はデータ取得要求を受信すると、各種の処理を実行して、自身が管理するパーソナルデータをパーソナルデータの由来者（例えばユーザＵＡなど）の同意を取得せずに由来者以外の第三者に提供してよいか否かを判断する。ＰＤＳサーバ２００は由来者の同意を取得せずに第三者に提供してよいと判断した場合、由来者の同意の取得を省略してパーソナルデータを第三者に提供する。

医療端末３００はパーソナルデータを利用する病院や診療所などに設置される。第１実施形態では、図１に示すように、医療端末３００は富士病院に設置されている。医療端末３００としては例えばＰＣなどがある。例えばユーザＵＡが健康診断を終えた日の数日後に富士病院で医師２０の診察を受ける予定である場合、医師２０は事前にユーザＵＡのパーソナルデータを取得する。具体的には、医師２０は医療端末３００を操作して、ＰＤＳサーバ２００が管理するユーザＵＡのパーソナルデータの取得を試行する。医療端末３００は医師２０の操作に基づいて上述したデータ取得要求をＰＤＳサーバ２００に向けて送信する。ＰＤＳサーバ２００は、ユーザＵＡの同意状況やユーザＵＡ以外の他のユーザの同意状況などに応じて、ユーザＵＡのパーソナルデータの一部又は全部を提供したり、逆に、パーソナルデータの提供を拒否したりする。これにより、ユーザＵＡにとって第三者である医師２０はユーザＵＡの同意状況に応じたパーソナルデータを取得して利用することができる。

ユーザ端末４００はユーザＵＡが利用する端末装置である。ユーザ端末４００としては例えばスマートフォンやタブレット端末などがある。ユーザ端末４００としてＰＣが利用されてもよい。ユーザ端末４００はＰＤＳサーバ２００からパーソナルデータの提供の同意が要求された場合、提供同意確認画面を表示する。ユーザＵＡは提供同意確認画面に対し、パーソナルデータのデータ項目毎に提供同意の許可又は拒否を選択する。ＰＤＳサーバ２００はユーザ端末４００で選択された提供同意に基づいて、ユーザＵＡのパーソナルデータの提供先への提供を判断する。

次に、図２を参照して、上述したＰＤＳサーバ２００のハードウェア構成について説明する。

図２はＰＤＳサーバ２００のハードウェア構成の一例である。尚、上述したセンター端末１００、医療端末３００、及びユーザ端末４００については基本的にＰＤＳサーバ２００と同様のハードウェア構成であるため、説明を省略する。図２に示すように、ＰＤＳサーバ２００は、少なくともハードウェアプロセッサとしてのCentral Processing Unit（ＣＰＵ）２００Ａ、Random Access Memory（ＲＡＭ）２００Ｂ、Read Only Memory（ＲＯＭ）２００Ｃ及びネットワークＩ／Ｆ（インタフェース）２００Ｄを含んでいる。ＰＤＳサーバ２００は、必要に応じて、Hard Disk Drive（ＨＤＤ）２００Ｅ、入力Ｉ／Ｆ２００Ｆ、出力Ｉ／Ｆ２００Ｇ、入出力Ｉ／Ｆ２００Ｈ、ドライブ装置２００Ｉの少なくとも１つを含んでいてもよい。ＣＰＵ２００Ａからドライブ装置２００Ｉまでは、内部バス２００Ｊによって互いに接続されている。すなわち、ＰＤＳサーバ２００はコンピュータによって実現することができる。尚、ＣＰＵ２００Ａに代えてMicro Processing Unit（ＭＰＵ）をハードウェアプロセッサとして利用してもよい。

入力Ｉ／Ｆ２００Ｆには、入力装置７１０が接続される。入力装置７１０としては、例えばキーボードやマウスなどがある。出力Ｉ／Ｆ２００Ｇには、表示装置７２０が接続される。表示装置７２０としては、例えば液晶ディスプレイがある。入出力Ｉ／Ｆ２００Ｈには、半導体メモリ７３０が接続される。半導体メモリ７３０としては、例えばUniversal Serial Bus（ＵＳＢ）メモリやフラッシュメモリなどがある。入出力Ｉ／Ｆ２００Ｈは、半導体メモリ７３０に記憶されたプログラムやデータを読み取る。入力Ｉ／Ｆ２００Ｆ及び入出力Ｉ／Ｆ２００Ｈは、例えばＵＳＢポートを備えている。出力Ｉ／Ｆ２００Ｇは、例えばディスプレイポートを備えている。

ドライブ装置２００Ｉには、可搬型記録媒体７４０が挿入される。可搬型記録媒体７４０としては、例えばCompact Disc（ＣＤ）－ＲＯＭ、Digital Versatile Disc（ＤＶＤ）といったリムーバブルディスクがある。ドライブ装置２００Ｉは、可搬型記録媒体７４０に記録されたプログラムやデータを読み込む。ネットワークＩ／Ｆ２００Ｄは、例えば通信回路及びＬＡＮポートを備えている。ネットワークＩ／Ｆ２００Ｄは上述した通信ネットワークＮＷと接続される。

上述したＲＡＭ２００Ｂには、ＲＯＭ２００ＣやＨＤＤ２００Ｅに記憶されたプログラムがＣＰＵ２００Ａによって一時的に格納される。ＲＡＭ２００Ｂには、可搬型記録媒体７４０に記録されたプログラムがＣＰＵ２００Ａによって一時的に格納される。格納されたプログラムをＣＰＵ２００Ａが実行することにより、ＣＰＵ２００Ａは後述する各種の機能を実現し、また、後述する各種の処理を実行する。尚、プログラムは後述するフローチャートに応じたものとすればよい。

次に、図３乃至図５を参照して、上述したＰＤＳサーバ２００の機能構成について説明する。

図３はＰＤＳサーバ２００のブロック図の一例である。図４はデータ記憶部２１０の一例である。図５は同意情報記憶部２２０の一例である。図３に示すように、ＰＤＳサーバ２００はデータ記憶部２１０、同意情報記憶部２２０、データ管理部２３０、処理部２４０、及び通信部２５０を備えている。尚、データ記憶部２１０及び同意情報記憶部２２０は例えば上述したＨＤＤ２００Ｅによって実現することができる。データ管理部２３０及び処理部２４０は例えば上述したＣＰＵ２００Ａによって実現することができる。通信部２５０は例えば上述したネットワークＩ／Ｆ２００Ｄによって実現することができる。

データ記憶部２１０はセンター端末１００から登録されたパーソナルデータを記憶する。パーソナルデータは、図４に示すように、パーソナルデータのデータ項目毎に複数の管理テーブルＴ１，Ｔ２，Ｔ３，Ｔ４，Ｔ５によって管理される。管理テーブルＴ１は、図４に示すように、病歴データを管理する。詳細は省略するが、管理テーブルＴ２は基本データを管理する。管理テーブルＴ３は健診データを管理する。管理テーブルＴ４は食事の献立を含む食事データを管理する。管理テーブルＴ５はバイタルデータを管理する。

ここで、管理テーブルＴ１はユーザＩＤフィールド、病歴フィールド、提供フィールド、及びデータ登録日時フィールドを含んでいる。ユーザＩＤフィールドには、ユーザＵＡを含む複数のユーザを識別する識別子が登録される。尚、ユーザＵＡには病歴がないため、管理テーブルＴ１にはユーザＩＤ「Ａ」を含む病歴データが示されていない。病歴フィールドにはユーザが患った病気の病歴が登録される。例えばユーザＩＤ「Ｂ」により識別されるユーザは高血圧と大腸癌を患ったため、これらの病気が病歴として登録される。提供フィールドには病気の履歴の提供に同意する情報（例えばＯＫなど）又は病気の履歴の提供に同意しない情報（例えばＮＧなど）が病歴毎に登録される。第１実施形態では、ユーザＩＤ「Ｂ」により識別されるユーザはパーソナルデータの提供を拒否していることが示されている。許可又は拒否する情報はパーソナルデータの登録時点では未登録であり、処理部２４０の処理結果やユーザ端末４００に対する操作結果などに基づいて登録される。データ登録日時フィールドにはパーソナルデータが登録された日時が登録される。

同意情報記憶部２２０は同意情報を記憶する。詳細は後述するが、同意情報はユーザ端末４００に対して行われた操作結果などに基づいて処理部２４０によって生成される。同意情報は、図５に示すように、管理テーブルＴ６によって管理される。管理テーブルＴ６はユーザＩＤフィールド、データ項目フィールド、データ提供先フィールド、同意取得結果フィールド、及び取得日時フィールドを含んでいる。ユーザＩＤフィールドはユーザＵＡを含む複数のユーザを識別する識別子が登録される。尚、図５は、ユーザＵＡの同意を取得していない状態の管理テーブルＴ６を示している。データ項目フィールドには基本データや病歴データといったパーソナルデータのデータ項目が登録される。データ提供先フィールドには富士病院や川崎スポーツクラブといったパーソナルデータを提供する提供先が登録される。同意取得結果フィールドにはパーソナルデータのデータ項目毎にパーソナルデータの提供に関する同意の取得結果が登録される。例えば、ユーザＩＤ「Ｂ」によって識別されるユーザは基本データと健診データの提供には同意するが、病歴データの提供には同意しないことを表している。取得日時フィールドには同意の取得日時が登録される。

データ管理部２３０はデータ記憶部２１０が記憶するパーソナルデータを管理する。より詳しくは、データ管理部２３０は通信部２５０を介してパーソナルデータを受信すると、受信したパーソナルデータをパーソナルデータのデータ項目毎に分類してデータ記憶部２１０に登録して管理する。これにより、データ記憶部２１０は種々のデータ項目のパーソナルデータを記憶する（図４参照）。データ管理部２３０は処理部２４０が生成したパーソナルデータの提供依頼を通信部２５０を介して受信すると、データ記憶部２１０からパーソナルデータを取得して、通信部２５０を介して提供する。

処理部２４０は同意情報記憶部２２０が記憶する同意情報を管理する。また、処理部２４０はデータ取得要求を通信部２５０を介して受信すると、通信部２５０を介して提供同意を要求する。処理部２４０はユーザ端末４００で行われた操作結果を受け付けると、操作結果とデータ取得要求に含まれる各種の情報に基づいて同意情報を生成し、生成した同意情報を同意情報記憶部２２０に登録する。これにより、同意情報記憶部２２０は同意情報を記憶する（図５参照）。処理部２４０は同意情報を登録すると、パーソナルデータの提供依頼を生成してデータ管理部２３０に向けて出力する。その他、処理部２４０は種々の処理を実行する。

通信部２５０はＰＤＳサーバ２００とセンター端末１００、医療端末３００、及びユーザ端末４００との通信を制御する。例えば、通信部２５０はセンター端末１００から送信されたパーソナルデータを受信すると、受信したパーソナルデータをデータ管理部２３０に出力する。通信部２５０は医療端末３００から送信されたデータ取得要求を受信すると、受信したデータ取得要求を処理部２４０に出力する。通信部２５０は処理部２４０から出力されたパーソナルデータの提供依頼を受け付けると、受け付けた提供依頼をデータ管理部２３０に出力する。通信部２５０はデータ管理部２３０から出力されたパーソナルデータを受け付けると、受け付けたパーソナルデータを医療端末３００に送信する。

続いて、ＰＤＳサーバ２００の動作について説明する。

図６は第１実施形態に係るＰＤＳサーバ２００の動作の一例を示すフローチャートである。図７は医療端末３００に表示されるデータ要求画面の一例である。図８はユーザ端末４００に表示される提供同意確認画面の一例である。図９（ａ）は同意情報を管理する管理テーブルＴ６の一例である。図９（ｂ）は同意情報を管理する管理テーブルＴ６の他の一例である。図１０（ａ）は病歴データを管理する管理テーブルＴ１の一例である。図１０（ｂ）は病歴データを管理する管理テーブルＴ１の他の一例である。図１１はユーザ端末４００に表示される提供同意確認画面の他の一例である。

まず、図６に示すように、処理部２４０はデータ取得要求を受信する（ステップＳ１０１）。例えば、図７に示すように、医師２０が基本データと健診データと病歴データを含むユーザＵＡのパーソナルデータを要求する操作を医療端末３００に対して行うと、医療端末３００はユーザＵＡのパーソナルデータを要求するデータ取得要求をＰＤＳサーバ２００に向けて送信する。これにより、処理部２４０はデータ取得要求を受信する。尚、上述したように、データ取得要求はパーソナルデータの利用目的（例えば診察利用など）及びパーソナルデータの提供先（例えば富士病院など）も含んでいる。

ステップＳ１０１の処理が完了すると、次いで、処理部２４０は同意情報記憶部２２０を確認して、同意済であるか否かを判断する（ステップＳ１０２）。すなわち、処理部２４０は同意情報記憶部２２０がユーザＵＡの同意情報を記憶しているか否かを確認することにより、過去にユーザＵＡの同意を得て、ユーザＵＡのパーソナルデータを富士病院に提供しているか否かを判断する。

ここで、処理部２４０は同意情報記憶部２２０を確認して、同意済でないと判断した場合（ステップＳ１０２：ＮＯ）、提供同意を要求する（ステップＳ１０３）。例えば、ユーザＵＡが富士病院の診察を初めて受ける場合、同意情報記憶部２２０はユーザＵＡの同意情報を記憶していないため（図５参照）、処理部２４０は同意済でないと判断し、提供同意を要求する。この場合、処理部２４０はユーザ端末４００に向けてＰＤＳサーバ２００との接続を指定するリンク情報（具体的にはハイパーリンク）を含む電子メールを送信する。

ユーザ端末４００が電子メールを受信すると、ユーザＵＡは電子メールに含まれるリンク情報に対して指示（例えばタップ操作やクリック操作など）を行う。これにより、ユーザ端末４００はＰＤＳサーバ２００へのログイン画面を表示する。ログイン画面に対し、ユーザＵＡが認証情報（例えば暗証情報や生体情報など）を入力する操作を行うと、ユーザ端末４００は、図８に示すように、提供同意確認画面を表示する。

提供同意確認画面は、パーソナルデータの利用目的、パーソナルデータの提供先、パーソナルデータのデータ項目、及び操作ボタンＢＴ１，ＢＴ２を含んでいる。特に、データ項目は、データ項目の項目名とデータ項目に該当するパーソナルデータの提供の許否を選択可能な複数の選択欄Ｂｘを含んでいる。ユーザＵＡはパーソナルデータの提供に同意できるデータ項目の選択欄Ｂｘを選択し、操作ボタンＢＴ１を押下する。図８では、ユーザＵＡはデータ項目に該当する全てのパーソナルデータの提供に同意している。

処理部２４０はユーザ端末４００において操作ボタンＢＴ１の押下を検出すると、図６に示すように、全てのパーソナルデータの提供に同意しているか否かを判断する（ステップＳ１０４）。上述したように、ユーザＵＡはデータ項目に該当する全てのパーソナルデータの提供に同意しているため、処理部２４０は全てのパーソナルデータの提供に同意していると判断する（ステップＳ１０４：ＹＥＳ）。この場合、処理部２４０は全部のデータ項目のパーソナルデータの提供に同意することを表す肯定の同意情報を生成して同意情報記憶部２２０に登録する（ステップＳ１０５）。したがって、図９（ａ）に示すように、管理テーブルＴ６は、ユーザＵＡのユーザＩＤ「Ａ」、データ取得要求に含まれるデータ項目、全部のデータ項目のパーソナルデータの提供に同意することを表す情報、同意の取得日時を含む同意情報を管理する。

一方、ユーザＵＡがデータ項目に該当する全てのパーソナルデータの提供に同意しなかった場合、処理部２４０は全てのパーソナルデータの提供に同意していないと判断する（ステップＳ１０４：ＮＯ）。この場合、処理部２４０は一部又は全部のデータ項目のパーソナルデータの提供に同意しないことを表す否定の同意情報を生成して同意情報記憶部２２０に登録する（ステップＳ１０６）。例えば、ユーザＩＤ「Ｂ」のユーザが病歴データの提供を拒否する場合、処理部２４０は否定の同意情報を生成して同意情報記憶部２２０に登録する。これにより、図９（ａ）に示すように、管理テーブルＴ６は、ユーザＩＤ「Ｂ」、データ取得要求に含まれるデータ項目、一部又は全部のデータ項目のパーソナルデータの提供に同意しないことを表す情報、同意又は不同意の取得日時を含む同意情報を管理する。

ステップＳ１０５又はステップＳ１０６の処理が完了すると、図６に示すように、データ管理部２３０は通信部２５０を介して同意済のパーソナルデータを提供する（ステップＳ１０７）。より詳しくは、データ取得要求に含まれるデータ項目のパーソナルデータの中から同意を取得できたパーソナルデータを提供する。これにより、ユーザＵＡが初めて富士病院で診察を受ける場合には、医療端末３００はデータ取得要求に応じたユーザＵＡの全てのパーソナルデータを取得でき、医療端末３００を操作する医師２０はユーザＵＡのパーソナルデータを確認してから、ユーザＵＡを診察することができる。

次に、ユーザＵＡが富士病院で初めて診察を受けてから半年後に健康診断を実施し、その後、ユーザＵＡが同じ富士病院で再び診察を受ける場合について説明する。

ユーザＵＡが富士病院で初めて診察を受けた際、図４を参照して説明したように、ユーザＵＡに病歴が存在しなかったため、上述したように、ユーザＵＡは全てのパーソナルデータの提供に同意した。しかしながら、健康診断を実施した結果、ユーザＵＡに高血圧が発症した場合、センター端末１００又はユーザ端末４００から病歴データが登録されると、図１０（ａ）に示すように、管理テーブルＴ１は病歴に高血圧を含むユーザＵＡの病歴データを管理する。

ここで、図７を参照して説明したように、医師２０が基本データと健診データと病歴データを含むユーザＵＡのパーソナルデータを要求する操作を医療端末３００に対して再び行うと、医療端末３００はユーザＵＡのパーソナルデータを要求するデータ取得要求をＰＤＳサーバ２００に向けて送信する。これにより、処理部２４０は図６に示すステップＳ１０１の処理を実行してデータ取得要求を受信する。

ステップＳ１０１の処理が完了すると、次いで、ステップＳ１０２の処理において、処理部２４０は同意情報記憶部２２０を確認して、同意済であるか否かを再び判断する。ここで、ユーザＵＡが再び診察を受ける場合、同意情報記憶部２２０にはユーザＵＡの同意情報が記憶されている（図９（ａ）参照）。特に、過去にユーザＵＡの同意を得て、ユーザＵＡのパーソナルデータが富士病院に提供されていれば、処理部２４０は同意済であると判断する（ステップＳ１０２：ＹＥＳ）。この場合、処理部２４０は変化量が第１閾値より大きいか否かを判断する（ステップＳ１０８）。

具体的には、まず、処理部２４０は、データ取得要求に基づいてユーザＵＡのパーソナルデータの変更箇所を特定する。より詳しく説明すると、処理部２４０は、前回データ取得要求を受信した際のユーザＵＡのパーソナルデータを、データ管理部２３０を通じて取得して過去のパーソナルデータとして保持しておく。次に、処理部２４０は今回データ取得要求を受信した際のユーザＵＡのパーソナルデータを、データ管理部２３０を通じて改めて取得して現在のパーソナルデータとして保持する。そして、処理部２４０は過去のパーソナルデータの情報量と現在のパーソナルデータの情報量をデータ項目毎に比較して、情報量の差分の有無をデータ項目毎に判断する。処理部２４０は特定のデータ項目について差分があると判断した場合、その特定のデータ項目についてのパーソナルデータの変更箇所を特定する。この結果、第１実施形態であれば、図４と図９（ａ）を対比すると、処理部２４０はパーソナルデータの変更箇所として高血圧を特定する。

次に、処理部２４０は変化量を算出し、算出した変化量が第１閾値より大きいか否かを判断する。より詳しく説明すると、処理部２４０が変更箇所を特定すると、特定した変更箇所と共通する変更箇所を含む、ユーザＵＡを除外した他のユーザの病歴データの中から提供の同意状況を確認する。したがって、変更箇所として高血圧が特定された場合、処理部２４０は病歴フィールドに高血圧が登録されたユーザＩＤ「Ｂ」のユーザなどの同意状況を確認する。仮に、病歴フィールドに高血圧が登録された病歴データが１０００件あり、その中で、高血圧が登録された病歴データの提供に同意する件数が７２３件、高血圧が登録された病歴データの提供に同意しない件数が２７７件である場合、ユーザＵＡを除いた約７２％の割合のユーザが高血圧の病歴データの提供に同意している。逆に、ユーザＵＡを除いた約２８％の割合のユーザが高血圧の病歴データの提供に同意していない。したがって、処理部２４０は提供に同意していない割合を変化量として算出し、変化量が第１閾値（例えば３０％など）より大きいか否かを判断する。このように、ユーザによっては当初自身のパーソナルデータの提供に同意していたが、疾病により病歴が変更になると、病歴の内容によっては提供に同意しなくなる可能性があり、パーソナルデータの提供の同意が不同意に変化する。処理部２４０はこのような変化を定量的に特定し、処理を分岐している。

ここで、処理部２４０は変化量が第１閾値以下であると判断した場合（ステップＳ１０８：ＮＯ）、同意要求を省略する（ステップＳ１０９）。具体的には、上述したように、変化量が約２８％であり、第１閾値として３０％が設定されている場合、処理部２４０は変化量が第１閾値以下であると判断する。すなわち、病歴が高血圧であれば、ユーザＵＡを除いた約７２％の割合のユーザが病歴データの提供に同意しているため、同意要求を省略しても差し支えないと想定することができる。したがって、このような場合、処理部２４０は同意要求を省略する。

ステップＳ１０９の処理が完了すると、データ管理部２３０はステップＳ１０７の処理を実行する。すなわち、データ管理部２３０はユーザＵＡの病歴データについて同意済であると判断し、病歴データを基本データ及び健診データとともに、同意済のパーソナルデータとして、医療端末３００に提供する。このように、ユーザＵＡの同意を取得する要求を省略して、医療端末３００にパーソナルデータされるため、ユーザＵＡの同意手続きの手間を低減することができる。尚、データ管理部２３０はパーソナルデータを提供する前又は提供した後、ユーザＵＡの病歴データの提供フィールドに提供に同意する情報を登録する。

次に、ユーザＵＡが富士病院で初めて診察を受けてから１年後（前回診察を受けてから半年後）に健康診断を実施し、その後、ユーザＵＡが富士病院で３回目の診察を受ける場合について説明する。

ユーザＵＡが富士病院で前回診察を受けた際、図１０（ａ）を参照して説明したように、ユーザＵＡに病歴が存在したが、上述したように、ユーザＵＡを除いた多くのユーザがユーザＵＡの病歴と同じ病歴について提供に同意しているため、処理部２４０は病歴データの提供に同意すると判断した。しかしながら、健康診断を実施した結果、ユーザＵＡに、高血圧に加えてさらに、うつ病が発症した場合、センター端末１００又はユーザ端末４００から病歴データが登録されると、図１０（ｂ）に示すように、管理テーブルＴ１は病歴に高血圧とうつ病を含むユーザＵＡの病歴データを管理する。

ここで、図７を参照して説明したように、医師２０が基本データと健診データと病歴データを含むユーザＵＡのパーソナルデータを要求する操作を前回診療時と同様に医療端末３００に対して行うと、医療端末３００はユーザＵＡのパーソナルデータを要求するデータ取得要求をＰＤＳサーバ２００に向けて送信する。これにより、処理部２４０は図６に示すステップＳ１０１の処理を実行してデータ取得要求を受信する。

ステップＳ１０１の処理が完了すると、次いで、ステップＳ１０２の処理において、処理部２４０は同意情報記憶部２２０を確認して、同意済であるか否かを再び判断する。ここで、ユーザＵＡが３度目の診察を受ける場合、同意情報記憶部２２０にはユーザＵＡの同意情報が記憶されている（図９（ａ）参照）。特に、過去にユーザＵＡの同意を得て、ユーザＵＡのパーソナルデータが富士病院に提供されていれば、ステップＳ１０２の処理において、処理部２４０は同意済であると判断する。この場合、ステップＳ１０８の処理において、処理部２４０は変化量が第１閾値より大きいか否かを判断する。

ここで、上述したように、まず、処理部２４０は、データ取得要求に基づいてユーザＵＡのパーソナルデータの変更箇所を特定する。この結果、第１実施形態であれば、図１０（ａ）と図１０（ｂ）を対比すると、処理部２４０はパーソナルデータの変更箇所としてうつ病を特定する。次に、処理部２４０は、特定した変更箇所を利用して、変化量を算出し、算出した変化量が第１閾値より大きいか否かを判断する。

変更箇所としてうつ病が特定された場合、処理部２４０は病歴フィールドにうつ病が登録されたユーザＩＤ「Ｂ」のユーザなどの同意状況を確認する。仮に、病歴フィールドにうつ病が登録された病歴データが１５３件あり、その中で、うつ病が登録された病歴データの提供に同意する件数が４３件、うつ病が登録された病歴データの提供に同意しない件数が１１０件である場合、ユーザＵＡを除いた約２８％の割合のユーザが高血圧の病歴データの提供に同意している。逆に、ユーザＵＡを除いた約７２％の割合のユーザがうつ病の病歴データの提供に同意していない。

したがって、処理部２４０は変化量が第１閾値より大きいと判断した場合（ステップＳ１０８：ＹＥＳ）、ステップＳ１０３の処理を実行する。すなわち、上述したように、提供に同意していないことを表す変化量が約７２％であり、第１閾値として３０％が設定されている場合、処理部２４０は変化量が第１閾値より大きいと判断する。すなわち、病歴がうつ病であれば、ユーザＵＡを除いた約７２％の割合のユーザが病歴データの提供に同意していないため、同意要求を省略することが望ましくないと想定することができる。したがって、このような場合、処理部２４０は提供同意を要求する。

これにより、処理部２４０はユーザ端末４００に向けてＰＤＳサーバ２００との接続を指定するリンク情報（具体的にはハイパーリンク）を含む電子メールを送信し、ユーザ端末４００は電子メールを受信する。そして、ユーザＵＡが電子メールに含まれるリンク情報に対して指示を行うと、ユーザ端末４００はＰＤＳサーバ２００へのログイン画面を表示する。ログイン画面に対し、ユーザＵＡが認証情報を入力する操作を行うと、ユーザ端末４００は、図１１に示すように、提供同意確認画面を表示する。

ユーザＵＡはパーソナルデータの提供に同意できるデータ項目の選択欄Ｂｘと提供に同意できないデータ項目の選択欄Ｂｘを選択し、操作ボタンＢＴ１を押下する。図１１では、ユーザＵＡはデータ項目に該当する一部のパーソナルデータ（具体的には病歴データ）の提供に同意していない。一方、ユーザＵＡはデータ項目に該当する残りの一部のパーソナルデータ（具体的には基本データ及び健診データ）の提供に同意している。

処理部２４０はユーザ端末４００において操作ボタンＢＴ１の押下を検出すると、ステップＳ１０４の処理において、全てのパーソナルデータの提供に同意しているか否かを判断する。上述したように、ユーザＵＡはデータ項目に該当する一部のパーソナルデータの提供に同意していないため、処理部２４０は全てのパーソナルデータの提供に同意していないと判断する。この場合、ステップＳ１０６の処理において、処理部２４０は否定の同意情報を生成して同意情報記憶部２２０に登録する（ステップＳ１０６）。例えば、ユーザＩＤ「Ａ」のユーザが病歴データの提供を拒否する場合、処理部２４０は否定の同意情報を生成して同意情報記憶部２２０に登録する。これにより、図９（ｂ）に示すように、管理テーブルＴ６は、ユーザＩＤ「Ａ」、データ取得要求に含まれるデータ項目、一部のデータ項目のパーソナルデータ（具体的には病歴データ）の提供に同意しないことを表す情報、取得日時を含む同意情報を管理する。

以上、第１実施形態によれば、ＰＤＳサーバ２００はデータ記憶部２１０と処理部２４０を備えている。データ記憶部２１０はユーザＵＡから初診時に同意を得てユーザＵＡ以外の第三者に相当する病院に提供したユーザＵＡのパーソナルデータを記憶する。処理部２４０はユーザＵＡのパーソナルデータを初診時より後の再診時などに同一の病院に提供する場合、パーソナルデータの初診時の情報量と再診時などの情報量を比較し、初診時の情報量と再診時などの情報量が異なる場合、異なる情報の変化量に応じて、ユーザＵＡへの同意の取得要否を判断する、処理を実行する。これにより、ユーザＵＡに対する同意手続きを軽減することができる。

（第２実施形態）
続いて、図１２から図１４を参照して、本件の第２実施形態について説明する。図１２は第２実施形態に係る情報提供システムＳＴの一例である。図１２に示すように、第２実施形態に係る情報提供システムＳＴは、第１実施形態に係る情報提供システムＳＴと異なり、センター端末１００を備えていない。また、第２実施形態に係る情報提供システムＳＴは、第１実施形態に係る情報提供システムＳＴと異なり、医療端末３００に代えて、事業者端末５００を備えている。事業者端末５００はパーソナルデータを利用する事業所などに設置される。第２実施形態では、図１２に示すように、事業者端末５００は富士レンタカーに設置されている。事業者端末５００も医療端末３００と同様にＰＣなどが利用される。

ここで、ユーザＵＡが車両を借り受ける予定である場合、ユーザＵＡは事前に各種のパーソナルデータをユーザ端末４００に入力する。第２実施形態に係るパーソナルデータとしては、ユーザＵＡの氏名や住所といった個人情報を含む基本データ、免許証番号を含む免許データなどがある。ユーザ端末４００はパーソナルデータが入力されると、入力されたパーソナルデータをＰＤＳサーバ２００に登録する。

一方、富士レンタカーの従業員３０はユーザＵＡに車両を初めて貸し出す場合車両を貸し出す当日の貸出手続の手間や時間を省略するために、事前にユーザＵＡのパーソナルデータを取得する。具体的には、従業員３０は事業者端末５００を操作して、ＰＤＳサーバ２００が管理するユーザＵＡのパーソナルデータの取得を試行する。事業者端末５００は従業員３０の操作に基づいてデータ取得要求をＰＤＳサーバ２００に向けて送信する。ＰＤＳサーバ２００は、ユーザＵＡの同意状況やユーザＵＡ以外の他のユーザの同意状況などに応じて、ユーザＵＡのパーソナルデータの一部又は全部を提供したり、逆に、パーソナルデータの提供を拒否したりする。特に、ユーザＵＡが車両を初めて借り受ける場合、ユーザ端末４００はユーザＵＡの操作に応じて提供同意確認画面を表示する。ユーザＵＡが自身のパーソナルデータの提供に同意する選択を行うと、処理部２４０は同意情報を生成して同意情報記憶部２２０に登録し、データ管理部２３０は同意済のパーソナルデータを事業者端末５００に提供することができる。これにより、従業員３０はユーザＵＡの同意状況に応じたパーソナルデータを取得して利用することができる。

次に、図１３を参照して、ユーザＵＡが富士レンタカーで初めて車両を借り受けた時期と異なる時期に再び車両を借り受ける場合について説明する。

図１３は第２実施形態に係るＰＤＳサーバ２００の動作の一部を例示するフローチャートである。図１４はＥＰ図の一例である。特に、図１３に示すフローチャートは、図６を参照して説明したフローチャートに追加されるフローチャートである。具体的には、処理部２４０は、第１実施形態で説明したステップＳ１０２の処理において、同意情報記憶部２２０を確認して、同意済であると判断すると、処理部２４０は機微情報度を算出する（ステップＳ１２０）。ステップＳ１２０の処理が完了すると、次いで、処理部２４０は機微情報度が第２閾値より大きいか否かを判断する（ステップＳ１２１）。処理部２４０は機微情報度が第２閾値より大きいと判断した場合、第１実施形態で説明したステップＳ１０８の処理を実行する。逆に、処理部２４０は機微情報度が第２閾値以下であると判断した場合、第１実施形態で説明したステップＳ１０９の処理を実行する。

機微情報度は以下の算出式（１）によって表すことができる
機微情報度＝（１０^ｘ－１＋５^ｙ－１）・・・（１）
ここで、パラメータｘは図１４に示すEconomic-Privacy Map（ＥＰ図）の横軸に対応し、パーソナルデータが漏洩した際に被害者に与える精神的苦痛の度合を表している。一方、パラメータｙはＥＰ図の縦軸に対応し、パーソナルデータが漏洩した際に被害者に与える経済的損失の度合を表している。尚、ＥＰ図は個人情報だけでなく、いわゆるセンシティブ情報と呼ばれる機微情報もパーソナルデータとして含んでいる。機微情報は、氏名、住所、性別、生年月日といった個人情報と異なり、思想や信条など社会的な差別の原因となり得る個人的な情報などを含んでいる。

したがって、処理部２４０が事業者端末５００から送信されたデータ取得要求を再び受信した場合、同意情報記憶部２２０はユーザＵＡが富士レンタカーにパーソナルデータの提供に同意することを含む同意情報を記憶しているため、機微情報度を算出する。ここで、氏名や住所といった個人情報を含む基本データが漏洩したと仮定する場合、処理部２４０は、図１４を参照して、（ｘ，ｙ）＝（１，１）と特定する。同様に、免許証番号を含む免許データが漏洩したと仮定する場合、図１４を参照して、（ｘ，ｙ）＝（１，１）と特定する。このように、パラメータｘ，ｙのそれぞれについて２つの度合を特定した場合、処理部２４０はパラメータｘ，ｙのそれぞれについて最大の度合を採用する。本例では、パラメータｘ，ｙのいずれもが（１，１）であるため、処理部２４０は算出式（１）に代入する（ｘ，ｙ）として（１，１）を採用する。したがって、処理部２４０は機微情報度「２」を算出する。このように、処理部２４０はユーザＵＡに与える悪影響の度合が大きいほど、その度合が大きくなるように機微情報を定量化することができる。尚、処理部２４０は、例えば、（１，１）と（２，１）と（１，３）を特定した場合、算出式（１）に代入する（ｘ，ｙ）として（２，３）を採用して、機微情報度「３５」を算出する。

したがって、処理部２４０は算出した機微情報度が第２閾値（例えば１０など）より大きいか否かを判断する。上述したように、処理部２４０が機微情報度「２」を算出した場合、処理部２４０は機微情報度が第２閾値以下であると判断する（ステップＳ１２１：ＮＯ）。この場合、処理部２４０はステップＳ１０９の処理を実行する。すなわち、機微情報度が第２閾値以下であれば、パーソナルデータの漏洩により被害者に与える悪影響は少ないと想定されるため、処理部２４０はユーザＵＡへの同意要求を省略する。

逆に、処理部２４０が機微情報度「３５」を算出した場合、処理部２４０は機微情報度が第２閾値より大きいと判断する（ステップＳ１２１：ＹＥＳ）。この場合、処理部２４０はステップＳ１０８の処理を実行する。すなわち、機微情報度が第２閾値より大きければ、パーソナルデータの漏洩により被害者に与える悪影響は多いと想定されるため、ステップＳ１０８の処理の判断結果に基づいて、ステップＳ１０３又はステップＳ１０９処理を実行する。

以上、第２実施形態によれば、第１実施形態で説明した変化量だけでなく、機微情報度も利用して、ユーザに対する同意手続きを軽減することができる。

以上、本発明の好ましい実施形態について詳述したが、本発明に係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。例えば、上述した第１実施形態及び第２実施形態では、基本データなどを説明したが、購買履歴を含む購買データなどを本件の対象としてもよい。尚、購買データであれば、例えばショッピングモールの販売員などが購買データのデータ取得要求を行う。

なお、以上の説明に関して更に以下の付記を開示する。
（付記１）ユーザから第１の時期に同意を得て前記ユーザ以外の第三者に提供した前記ユーザのパーソナルデータを記憶するデータ記憶部と、前記パーソナルデータを前記第１の時期より後の第２の時期に前記第三者に提供する場合、前記パーソナルデータの前記第１の時期の情報量と前記第２の時期の情報量を比較し、前記第１の時期の情報量と前記第２の時期の情報量が異なる場合、異なる情報の変化量に応じて、前記ユーザからの同意の取得要否を判断する、処理を実行する処理部と、を有する情報提供装置。
（付記２）前記処理部は、前記変化量が第１閾値以下の場合、前記ユーザからの同意の取得を省略する、ことを特徴とする付記１に記載の情報提供装置。
（付記３）前記処理部は、前記パーソナルデータを前記第２の時期に前記第三者に提供する場合、前記パーソナルデータが漏洩した場合に前記ユーザに与える悪影響の度合を、該度合が大きいほど大きくなるように定量化した機微情報度を所定の算出式に基づいて算出し、算出した前記機微情報度に応じて、前記ユーザからの同意の取得要否を判断する、ことを特徴とする付記１又は２に記載の情報提供装置。
（付記４）前記処理部は、算出した前記機微情報度が第２閾値以下の場合、前記ユーザからの同意の取得を省略する、ことを特徴とする付記３に記載の情報提供装置。
（付記５）ユーザから第１の時期に同意を得て前記ユーザ以外の第三者に提供した前記ユーザのパーソナルデータを前記第１の時期より後の第２の時期に前記第三者に提供する場合、前記パーソナルデータの前記第１の時期の情報量と前記第２の時期の情報量を比較し、前記第１の時期の情報量と前記第２の時期の情報量が異なる場合、異なる情報の変化量に応じて、前記ユーザからの同意の取得要否を判断する、処理をコンピュータが実行する情報提供方法。
（付記６）前記コンピュータが、前記変化量が第１閾値以下の場合、前記ユーザからの同意の取得を省略する、処理を実行することを特徴とする付記５に記載の情報提供方法。
（付記７）前記コンピュータが、前記パーソナルデータを前記第２の時期に前記第三者に提供する場合、前記パーソナルデータが漏洩した場合に前記ユーザに与える悪影響の度合を定量化した機微情報度を所定の算出式に基づいて算出し、算出した前記機微情報度に応じて、前記ユーザからの同意の取得要否を判断する、処理を実行することを特徴とする付記５又は６に記載の情報提供方法。
（付記８）前記コンピュータが、算出した前記機微情報度が第２閾値以下の場合、前記ユーザからの同意の取得を省略する、処理を実行することを特徴とする付記７に記載の情報提供方法。
（付記９）ユーザから第１の時期に同意を得て前記ユーザ以外の第三者に提供した前記ユーザのパーソナルデータを前記第１の時期より後の第２の時期に前記第三者に提供する場合、前記パーソナルデータの前記第１の時期の情報量と前記第２の時期の情報量を比較し、前記第１の時期の情報量と前記第２の時期の情報量が異なる場合、異なる情報の変化量に応じて、前記ユーザからの同意の取得要否を判断する、処理をコンピュータに実行させる情報提供プログラム。

ＳＴ 情報提供システム
１００ センター端末
２００ ＰＤＳサーバ
２１０ データ記憶部
２２０ 同意情報記憶部
２３０ データ管理部
２４０ 処理部
２５０ 通信部
３００ 医療端末
４００ ユーザ端末
５００ 事業者端末

Claims (6)

1. ユーザから第１の時期に同意を得て前記ユーザ以外の第三者に提供した前記ユーザのパーソナルデータを記憶するデータ記憶部と、
   前記パーソナルデータを前記第１の時期より後の第２の時期に前記第三者に提供する場合、前記パーソナルデータの前記第１の時期の情報量と前記第２の時期の情報量を比較し、前記第１の時期の情報量と前記第２の時期の情報量が異なる場合、異なる情報の変化量に応じて、前記ユーザからの同意の取得要否を判断する、処理を実行する処理部と、
   を有する情報提供装置。
2. 前記処理部は、前記変化量が第１閾値以下の場合、前記ユーザからの同意の取得を省略する、
   ことを特徴とする請求項１に記載の情報提供装置。
3. 前記処理部は、前記パーソナルデータを前記第２の時期に前記第三者に提供する場合、前記パーソナルデータが漏洩した場合に前記ユーザに与える悪影響の度合を、該度合が大きいほど大きくなるように定量化した機微情報度を所定の算出式に基づいて算出し、算出した前記機微情報度に応じて、前記ユーザからの同意の取得要否を判断する、
   ことを特徴とする請求項１又は２に記載の情報提供装置。
4. 前記処理部は、算出した前記機微情報度が第２閾値以下の場合、前記ユーザからの同意の取得を省略する、
   ことを特徴とする請求項３に記載の情報提供装置。
5. ユーザから第１の時期に同意を得て前記ユーザ以外の第三者に提供した前記ユーザのパーソナルデータを前記第１の時期より後の第２の時期に前記第三者に提供する場合、前記パーソナルデータの前記第１の時期の情報量と前記第２の時期の情報量を比較し、
   前記第１の時期の情報量と前記第２の時期の情報量が異なる場合、異なる情報の変化量に応じて、前記ユーザからの同意の取得要否を判断する、
   処理をコンピュータが実行する情報提供方法。
6. ユーザから第１の時期に同意を得て前記ユーザ以外の第三者に提供した前記ユーザのパーソナルデータを前記第１の時期より後の第２の時期に前記第三者に提供する場合、前記パーソナルデータの前記第１の時期の情報量と前記第２の時期の情報量を比較し、
   前記第１の時期の情報量と前記第２の時期の情報量が異なる場合、異なる情報の変化量に応じて、前記ユーザからの同意の取得要否を判断する、
   処理をコンピュータに実行させる情報提供プログラム。

Images