JP2016224995A - サーバ装置、データ連携方法およびコンピュータプログラム - Google Patents

Abstract

【課題】電子化された健康データについてセキュリティを向上させるとともに情報の信頼性を向上させることが可能なサーバ装置を提供する。【解決手段】特定の個人を識別することができる情報を保持せず、個人ごとのデータを少なくとも保持するデータ保持部と、特定の個人を識別することができる情報及び個人ごとのデータを少なくとも保持する他のシステムから少なくとも該データを取得して前記データ保持部に登録するデータ登録部と、を備え、前記データ登録部は、前記他のシステムと連携する連携ＩＤを用いて該他のシステムからデータを取得して前記データ保持部に登録する、サーバ装置が提供される。【選択図】図１

Description

本開示は、サーバ装置、データ連携方法およびコンピュータプログラムに関する。

現在、医師が発行する処方せんや、薬局で発行されるお薬手帳は、紙媒体で運用されているが、利便性や効率性向上の観点から、ＥＨＲ（Ｅｌｅｃｔｒｉｃ Ｈｅａｌｔｈ Ｒｅｃｏｒｄ：電子健康記録）と呼ばれるような、電子的に健康データを共有，管理する仕組みの構築が求められている。現状では、例えば電子カルテの共有、処方せんの電子化、お薬手帳の電子化などの取り組みが進められている。

また、例えばお薬手帳に関連する技術として、薬剤の名称や服用方法などの情報を予め記録しておき、その情報に基づいて薬剤指導書を生成し、印刷する技術が提案されている（例えば、特許文献１参照）。この技術では、患者が所有する手帳等にも薬剤に関する情報を保管できるように、保管用の情報が薬剤指導書の一部に設けられる。

特開平１１−２８８７７号公報

上述したような電子化されたお薬手帳（電子お薬手帳）や処方せん等の健康データを共有・管理するシステムでは、各ユーザの個人的な情報が扱われることになるため、セキュリティの向上が望まれている。そのため、お薬手帳や処方せん等の健康データを共有・管理するシステムにおいて、セキュリティを向上させた技術が考え出されてきている。

また電子お薬手帳は、即時性のあるデータを取得し、情報を蓄積することができるが、データ取得のタイミングがユーザによる自発的な呈示のため、情報の網羅性が無かったり、情報が限られたりする側面がある。また、個人情報が誤記されている場合や、一部情報が未分類のままの場合もある。

そこで、本開示では、電子化された健康データについてセキュリティを向上させるとともに情報の信頼性を向上させることが可能な、新規かつ改良されたサーバ装置、データ連携方法およびコンピュータプログラムを提案する。

本開示によれば、特定の個人を識別することができる情報を保持せず、個人ごとのデータを少なくとも保持するデータ保持部と、特定の個人を識別することができる情報及び個人ごとのデータを少なくとも保持する他のシステムから少なくとも該データを取得して前記データ保持部に登録するデータ登録部と、を備え、前記データ登録部は、前記他のシステムと連携する連携ＩＤを用いて該他のシステムからデータを取得して前記データ保持部に登録する、サーバ装置が提供される。

また、本開示によれば、特定の個人を識別することができる情報及び個人ごとのデータを少なくとも保持する他のシステムから、少なくとも該データを取得して、特定の個人を識別することができる情報を保持せず個人ごとのデータを少なくとも保持するデータ保持部に登録するステップを備え、前記データ保持部に登録するステップは、前記他のシステムと連携する連携ＩＤを用いて該他のシステムからデータを取得して前記データ保持部に登録する、データ連携方法が提供される。

また、本開示によれば、特定の個人を識別することができる情報及び個人ごとのデータを少なくとも保持する他のシステムから、少なくとも該データを取得して、特定の個人を識別することができる情報を保持せず個人ごとのデータを少なくとも保持するデータ保持部に登録するステップをコンピュータに実行させ、前記データ保持部に登録するステップは、前記他のシステムと連携する連携ＩＤを用いて該他のシステムからデータを取得して前記データ保持部に登録する、コンピュータプログラムが提供される。

以上説明したように本開示によれば、電子化された健康データについてセキュリティを向上させるとともに情報の信頼性を向上させることが可能な、新規かつ改良されたサーバ装置、データ連携方法およびコンピュータプログラムを提供することが出来る。

本開示の一実施形態にかかる情報処理システム１の構成例を示す説明図である。 本開示の一実施形態にかかる情報処理システム１に含まれるデータセンター１００の構成例を示す説明図である。 本開示の一実施形態にかかる情報処理システム１に含まれる病院内システム３００の構成例を示す説明図である。 本開示の一実施形態にかかる情報処理システム１に含まれる薬局内システム４００の構成例を示す説明図である。 薬局内システム４００の薬局内データベース４１０に記録される個人／薬歴情報の例を示す説明図である。 データサーバ１１０のサーバ内データベース１１１に記録されるユーザ薬歴情報の具体例を示す説明図である。 薬局内システム４００によるユーザ薬歴情報の登録処理例に示す流れ図である。 薬局内システム４００によるユーザ薬歴情報の登録処理例に示す流れ図である。 本実施形態にかかる情報処理システム１の動作概要を示す説明図である。 本開示の一実施形態にかかる情報処理システム１の処理動作の一例を示す流れ図である。 本実施形態にかかる情報処理システム１の動作概要を示す説明図である。 本開示の一実施形態にかかる情報処理システム１の処理動作の一例を示す流れ図である。 本実施形態にかかる情報処理システム１の動作概要を示す説明図である。 本開示の一実施形態にかかる情報処理システム１の処理動作の一例を示す流れ図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、以下に示す項目順序に従って本開示を説明する。
＜１．本開示の一実施形態＞
［システム構成例］
［データセンター構成例］
［病院内システム構成例］
［薬局内システム構成例］
［薬局内データベースの具体例］
［サーバ内データベースの具体例］
［ユーザ薬歴情報の登録処理例］
＜２．まとめ＞

＜１．本開示の一実施形態＞
［システム構成例］
まず、図面を参照しながら本開示の一実施形態にかかる情報処理システムの構成例を説明する。図１は、本開示の一実施形態にかかる情報処理システム１の構成例を示す説明図である。以下、図１を用いて本開示の一実施形態にかかる情報処理システム１の構成例について説明する。

図１に示したように、本開示の一実施形態にかかる情報処理システム１は、データセンター１００と、健康保険組合システム２００と、病院内システム３００と、薬局内システム４００と、を含んで構成される。図１に示したように、データセンター１００と、健康保険組合システム２００と、病院内システム３００と、薬局内システム４００とは、ネットワーク１０を介して相互に接続されている。

データセンター１００は、健康保険組合システム２００、病院内システム３００及び薬局内システム４００から、ネットワーク１０を介して送られてくる情報を格納する。データセンター１００が格納する、健康保険組合システム２００、病院内システム３００及び薬局内システム４００から、ネットワーク１０を介して送られてくる情報は、例えば、個人ごとの健康に関するデータである。健康に関するデータには、例えば、各個人の診療情報や調剤情報が含まれる。また、データセンター１００は、病院内システム３００や薬局内システム４００からの要求に応じて、記録している情報を提供する。以下の説明では、データセンター１００が格納する情報は個人ごとの健康に関するデータであるとして説明する。なお、データセンター１００の構成例については後述する。

健康保険組合システム２００は、病院内システム３００を使用する医療機関や薬局内システム４００を使用する薬局から送られてくる診療情報や調剤情報に基づいて生成される、電子レセプトデータを格納する。健康保険組合システム２００が保持する電子レセプトデータは、データセンター１００からの求めに応じて、または自動的に、データセンター１００に提供される。

データセンター１００と、健康保険組合システム２００との間でやり取りされる情報は、診療情報や調剤情報という非常にデリケートな情報であるので、データセンター１００と、健康保険組合システム２００との間は、ネットワーク１０とは別に専用線やＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）等のような、セキュアな通信回線２によって接続されることが望ましい。

病院内システム３００は、患者（ユーザ）が通院する病院内に設けられるシステムである。病院内システム３００は、患者の個人情報や、患者の健康に関するデータである健康データとしての薬歴データ等からなる個人／診察情報を、患者ごとに保持している。例えば、個人／診察情報には、病院等において患者に対して発行された処方箋に関する情報等からなる診察データが含まれる。病院内システム３００が保持する個人／診察情報は、ネットワーク１０を通じてデータセンター１００に送られる。なお、病院内システム３００からデータセンター１００に情報が送られる際には、ユーザ個人を特定することができる情報は送られない。病院内システム３００の構成例については後述する。

薬局内システム４００は、患者が処方された薬剤を購入する薬局内に設けられるシステムである。薬局内システム４００は、患者の個人情報や、患者の健康に関するデータである健康データとしての薬歴データ等からなる個人／薬歴情報を、患者ごとに保持している。例えば、個人／薬歴情報には、薬局等で患者のために調剤された薬剤に関する情報や、その薬剤に関する情報等からなる調剤データが含まれる。薬局内システム４００が保持する個人／診察情報は、ネットワーク１０を通じてデータセンター１００に送られる。なお、薬局内システム４００からデータセンター１００に情報が送られる際には、ユーザ個人を特定することができる情報は送られない。薬局内システム４００の構成例については後述する。

図１には、病院内システム３００及び薬局内システム４００で用いられるＩＣカード２０も図示されている。ＩＣカード２０は、患者固有のＩＤである個人識別ＩＤが格納されており、後述するリーダライタ３３０、４３０との間で、所定の周波数による近接非接触通信を行なって、個人識別ＩＤをリーダライタ３３０、４３０に提供する。

ここで、個人識別ＩＤは、一意にユーザを特定することのできる識別情報であるが、他人が個人識別ＩＤを入手しただけでは、一般的にはその個人識別ＩＤにより識別されるユーザ個人を特定することができない（または特定することが困難である）情報とされる。例えば、ユーザの氏名，住所，電話番号などの個人情報は、それらの情報からほぼ直接的にユーザを特定することが可能である。しかし、番号や記号などからなるＩＤを個人識別ＩＤとしてユーザに付与すれば、個人識別ＩＤとユーザとの対応を知っていない限り、個人識別ＩＤから、その個人識別ＩＤのユーザを特定することは困難である。

なお、個人識別ＩＤを取得する契機となる媒体は、個人識別ＩＤが直接記録されたＩＣカード等に限らず、書き換えや置き換えが不可能な固有の媒体であればよい。例えば生体情報から固有の情報を個人識別ＩＤとして取得する場合、個人識別ＩＤを取得するための媒体は、人体の一部または全部などとされる。

以上、図１を用いて本開示の一実施形態にかかる情報処理システム１の構成例について説明した。次に、本開示の一実施形態にかかる情報処理システム１を構成する各システムの構成例について説明する。

［データセンター構成例］
図２は、本開示の一実施形態にかかる情報処理システム１に含まれるデータセンター１００の構成例を示す説明図である。以下、図２を用いてデータセンター１００の構成例について説明する。

図２に示したように、データセンター１００は、データサーバ１１０と、情報処理サーバ１２０と、を含んで構成される。

データサーバ１１０は、病院内システム３００や薬局内システム４００から供給された薬歴データを管理するとともに、病院内システム３００や薬局内システム４００からの要求に応じて、記録している薬歴データを提供する。データサーバ１１０は、サーバ内データベース１１１と、通信部１１２と、更新部１１３と、ユーザ検索部１１４と、薬歴検索部１１５と、を含んで構成される。

サーバ内データベース１１１は、患者ごとの薬歴情報を記録している。この患者ごとの薬歴情報には、薬局内システム４００を使用する薬局を特定する情報、薬局内システム４００において用いられている患者の識別情報、薬局内システム４００から供給される患者の薬歴データなどが含まれる。

通信部１１２は、ネットワーク１０を介して、病院内システム３００や薬局内システム４００と通信し、薬歴データ等のデータを送受信する。また通信部１１２は、例えばセキュアな通信回線２を介して、健康保険組合システム２００との間でデータを送受信する。更新部１１３は、病院内システム３００や薬局内システム４００からデータが供給されると、そのデータに基づいてサーバ内データベース１１１の更新を行う。

また本実施形態では、更新部１１３は、健康保険組合システム２００が保持する電子レセプトデータに基づいてサーバ内データベース１１１の更新を行う。更新部１１３が、健康保険組合システム２００が保持する電子レセプトデータに基づいてサーバ内データベース１１１の更新を行うことで、データサーバ１１０は、サーバ内データベース１１１に保持される電子化された健康データについて、その情報の信頼性を向上させることができる。

ユーザ検索部１１４は、サーバ内データベース１１１に記録されている薬歴情報から、所望の患者を特定する情報、すなわち、薬局内システム４００において用いられている患者の識別情報を検索する。薬歴検索部１１５は、サーバ内データベース１１１に記録されている薬歴情報から、所望の患者の薬歴データを検索する。

情報処理サーバ１２０は、必要に応じて、データサーバ１１０のサーバ内データベース１１１にアクセスし、薬歴情報の加工や、薬歴情報に基づいた患者への通知処理等を実行する。

以上、図２を用いてデータセンター１００の構成例について説明した。次に、本開示の一実施形態にかかる情報処理システム１に含まれる病院内システム３００の構成例について説明する。

［病院内システム構成例］
図３は、本開示の一実施形態にかかる情報処理システム１に含まれる病院内システム３００の構成例を示す説明図である。以下、図３を用いて病院内システム３００の構成例について説明する。

図３に示したように、病院内システム３００は、病院内レセプトコンピュータ３１０と、病院内装置３２０と、リーダライタ３３０と、を含んで構成される。病院内レセプトコンピュータ３１０と、病院内装置３２０とは、ローカルネットワークを介して相互に接続されている。このローカルネットワークは、ルータ（図示せず）によってネットワーク１０に接続されている。

病院内レセプトコンピュータ３１０は、病院内データベース３１１と、入力部３１２と、制御部３１３と、を含んで構成される。病院内レセプトコンピュータ３１０は、病院の医師や職員等による入力部３１２の入力操作に応じて病院内データベース３１１の情報を更新する。

病院内データベース３１１は、患者の個人情報、患者の健康に関するデータである健康データとしての薬歴データなどからなる個人／診察情報を、患者ごとにデータベース化して保持する。個人／診察情報に含まれる薬歴データには、病院等において患者に対して発行された処方せんに関する情報等からなる診察データが含まれる。病院内データベース３１１に記録される薬歴データは、必要に応じてデータセンター１００に送信されて記録され、複数の病院内システム３００や薬局内システム４００で共有される。

入力部３１２は、例えばキーボードやマウス、タッチパネルなどからなる入力デバイスであり、ユーザの入力操作に応じた情報を制御部３１３に供給する。制御部３１３は、入力部３１２から供給される情報に応じて、病院内レセプトコンピュータ３１０の動作を制御する。

病院内装置３２０は、例えばデスクトップ型コンピュータやノートブック型コンピュータ等からなる。病院内装置３２０は、リーダライタ３３０から供給される個人識別ＩＤや、医師・職員等の入力操作に応じた各種処理を実行する。図３に示したように、病院内装置３２０は、取得部３２１と、制御部３２２と、通信部３２３と、表示部３２４と、を含んで構成される。

取得部３２１は、リーダライタ３３０がＩＣカード２０との間の近接非接触通信によって取得した個人識別ＩＤを取得する。制御部３２２は、ローカルエリアネットワークを介して病院内レセプトコンピュータ３１０と各種のデータ授受を行なったり、各種データを表示部３２４に表示させたりする制御を行う。

通信部３２３は、ローカルエリアネットワークやネットワーク１０を介して、他の装置との間で情報の送受信を行う。表示部３２４は、各種データ（文字情報、画像情報等）を表示する。

リーダライタ３３０は、病院内装置３２０とＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）その他のインタフェースによって接続されており、ＩＣカード２０との間で所定の周波数（例えば１３．５６ＭＨｚ）による近接非接触通信を行う。リーダライタ３３０は、ＩＣカード２０との間で近接非接触通信を行うことでＩＣカード２０から取得した個人識別ＩＤを病院内装置３２０に提供する。

以上、図３を用いて病院内システム３００の構成例について説明した。なお、図３に示した病院内レセプトコンピュータ３１０、病院内システム３２０、リーダライタ３３０が１つの装置で構成されていても良い。次に、薬局内システム４００の構成例について説明する。

［薬局内システム構成例］
図４は、本開示の一実施形態にかかる情報処理システム１に含まれる薬局内システム４００の構成例を示す説明図である。以下、図４を用いて薬局内システム４００の構成例について説明する。

図４に示したように、薬局内システム４００は、薬局内レセプトコンピュータ４１０と、薬局内装置４２０と、リーダライタ４３０と、を含んで構成される。薬局内レセプトコンピュータ４１０と、薬局装置４２０とは、ローカルネットワークを介して相互に接続されている。このローカルネットワークは、ルータ（図示せず）によってネットワーク１０に接続されている。

薬局内レセプトコンピュータ４１０は、薬局内データベース４１１と、入力部４１２と、制御部４１３と、を含んで構成される。薬局内レセプトコンピュータ４１０は、薬局の薬剤師や職員等による入力部４１２の入力操作に応じて薬局内データベース４１１の情報を更新する。

薬局内データベース４１１は、患者の個人情報、患者の健康に関するデータである健康データなどからなる個人／薬歴情報を、患者ごとにデータベース化して保持する。健康データは、患者の薬歴に関するデータ（薬歴データ）等が含まれる。個人／薬歴データに含まれている薬歴データには、薬局等においてユーザのために調剤された薬剤に関する情報や、その薬剤の処方せんに関する情報等からなる調剤データが含まれている。なお、薬局内データベース４１１で管理される健康データは、薬歴データに限らず、患者の健康に関するものであればどのようなデータであってもよい。薬局内データベース４１１に記録される薬歴データは、必要に応じてデータセンター１００に送信されて記録され、複数の病院内システム３００や薬局内システム４００で共有される。

入力部４１２は、例えばキーボードやマウス、タッチパネルなどからなる入力デバイスであり、ユーザの入力操作に応じた情報を制御部４１３に供給する。制御部４１３は、入力部４１２から供給される情報に応じて、薬局内レセプトコンピュータ４１０の動作を制御する。

薬局内装置４２０は、例えばデスクトップ型コンピュータやノートブック型コンピュータ等からなる。薬局内装置４２０は、リーダライタ４３０から供給される個人識別ＩＤや、薬剤師・職員等の入力操作に応じた各種処理を実行する。図４に示したように、薬局内装置４２０は、取得部４２１と、制御部４２２と、通信部４２３と、表示部４２４と、を含んで構成される。

取得部４２１は、リーダライタ４３０がＩＣカード２０との間の近接非接触通信によって取得した個人識別ＩＤを取得する。制御部４２２は、ローカルエリアネットワークを介して薬局内レセプトコンピュータ４１０と各種のデータ授受を行なったり、各種データを表示部４２４に表示させたりする制御を行う。

通信部４２３は、ローカルエリアネットワークやネットワーク１０を介して、他の装置との間で情報の送受信を行う。表示部４２４は、各種データ（文字情報、画像情報等）を表示する。

リーダライタ４３０は、薬局内装置４２０とＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）その他のインタフェースによって接続されており、ＩＣカード２０との間で所定の周波数（例えば１３．５６ＭＨｚ）による近接非接触通信を行う。リーダライタ４３０は、ＩＣカード２０との間で近接非接触通信を行うことでＩＣカード２０から取得した個人識別ＩＤを薬局内装置４２０に提供する。

以上、図４を用いて薬局内システム４００の構成例について説明した。なお、図４に示した薬局レセプトコンピュータ４１０、薬局内装置４２０、リーダライタ４３０が１つの装置で構成されていても良い。次に、薬局内システム４００の薬局内データベース４１０に記録される個人／薬歴情報の具体例について説明する。

［薬局内データベースの具体例］
図５は、薬局内システム４００の薬局内データベース４１０に記録される個人／薬歴情報の例を示す説明図である。図５に示した例では、個人／薬歴情報には「調剤薬局ＩＤ」、「調剤薬局内ユーザＩＤ」、「レセプト連携ＩＤ」、「氏名」、「生年月日」、「住所」、「電話番号」、「保険証番号」、および「薬歴データ」が含まれている。

「調剤薬局ＩＤ」は、図１に示す情報処理システム１を構成する各装置において識別可能な、薬局内システム４００、すなわち薬局を特定するための情報である。例えば、薬局などの各機関が保険者に支払い請求を行なう際に用いられる保険医療機関コードなどが調剤薬局ＩＤとされる。

「調剤薬局内ユーザＩＤ」は、薬局内システム４００、すなわち薬局内レセプトコンピュータ４１０、薬局内装置４２０及びリーダライタ４３０からなるローカルなシステム内においてのみ用いられている、ユーザを識別するための情報である。例えば、薬局内システム４００を構成する薬局内レセプトコンピュータ４１０に登録されているユーザ番号などが調剤薬局内ユーザＩＤとされる。

従って、薬局内装置４２０等の薬局内システム４００を構成する各装置だけが、調剤薬局内ユーザＩＤに基づいて、その調剤薬局内ユーザＩＤが示す患者を特定することが可能である。このような調剤薬局内ユーザＩＤは、他人が入手しただけでは、直接的に患者を特定することができない情報である。

「レセプト連携ＩＤ」は、患者個人を識別する個人識別ＩＤと、健康保険組合システム２００に保持されているデータとを連携するための情報である。

また、個人／薬歴情報に含まれている「氏名」、「生年月日」、「住所」、「電話番号」、および「保険証番号」は、「調剤薬局内ユーザＩＤ」により特定されるユーザの氏名、生年月日、住所、電話番号、および保険証番号である。これらの「氏名」から「保険証番号」は、他人が直接的にユーザを特定可能な、いわゆる患者の個人情報である。

個人／薬歴情報に含まれている「薬歴データ」は、「調剤薬局内ユーザＩＤ」により特定されるユーザの薬歴データであり、この薬歴データには、薬局内システム４００で入力された調剤データなどが含まれている。すなわち、各薬局（薬局内システム４００）の薬局内データベース４１１に記録されている薬歴データには、その薬局で入力された情報のみが含まれており、他の薬局や病院（他の医療機関等）で入力された薬歴に関する情報は含まれていない。

より具体的には、薬歴データには、例えば調剤された薬剤を特定する調剤薬ＩＤや、内服等の調剤された薬剤の種別、調剤日時、薬剤の処方分日数、薬剤の使用頻度、薬剤の１回当たりの服用数量、副作用に関する情報などが調剤データとして含まれている。

このように、個人／薬歴情報には、薬局を特定するための調剤薬局ＩＤ、薬局内でユーザを識別するための調剤薬局内ユーザＩＤ、氏名等のユーザの個人情報、および薬局において入力された薬歴データが含まれている。

図１の情報処理システム１を構成する病院内システム３００や薬局内システム４００では、それら各システムで入力された薬歴データを含む個人／薬歴情報や個人／診察情報が、患者ごとに病院内データベース３１１や薬局内データベース４１１で管理される。

なお、病院内データベース３１１で管理される個人／診察情報に含まれる薬歴データには、病院で患者に対して発行された処方せんに関する情報（診察データ）が含まれている。具体的には、例えば薬歴データには、処方せんの発行日時、ジェネリック医薬品への変更の可否、処方薬剤を特定する処方薬ＩＤ、内服等の処方薬の種別、薬剤の処方分日数、薬剤の使用頻度、薬剤の１回当たりの服用数量、副作用に関する情報などが含まれている。

また、病院内データベース３１１で管理される個人／診察情報には、図５の「調剤薬局ＩＤ」および「調剤薬局内ユーザＩＤ」に代えて、「病院ＩＤ」および「病院内ユーザＩＤ」が含まれている。「病院ＩＤ」は、「調剤薬局ＩＤ」に対応する情報であり、情報処理システム内で、病院内システム３００を特定する情報である。「病院内ユーザＩＤ」は、「調剤薬局内ユーザＩＤ」に対応する情報であり、病院内システム３００内のみで用いられている、患者の識別情報である。

以上、薬局内システム４００の薬局内データベース４１０に記録される個人／薬歴情報の具体例について説明した。次に、データサーバ１１０のサーバ内データベース１１１に記録されるユーザ薬歴情報の具体例について説明する。

［サーバ内データベースの具体例］
図６は、データサーバ１１０のサーバ内データベース１１１に記録されるユーザ薬歴情報の具体例を示す説明図である。図６に示した例では、各ユーザ薬歴情報には、「個人識別ＩＤ」、「調剤薬局ＩＤ」、「調剤薬局内ユーザＩＤ」、「レセプト連携ＩＤ」、「薬歴データ」、および「最終更新日」が含まれている。

ユーザ薬歴情報に含まれる「個人識別ＩＤ」は、図１等に示したＩＣカード２０に記録されている個人識別ＩＤである。この個人識別ＩＤは、上述したようにＩＣカード２０を所有する患者を特定する情報として用いられる。また、「調剤薬局ＩＤ」は、薬局内システム４００を特定するための調剤薬局ＩＤである。より詳細には、ユーザ薬歴情報に含まれる「調剤薬局ＩＤ」は、調剤薬局ＩＤをハッシュ化することで得られるハッシュ値とされる。

「調剤薬局内ユーザＩＤ」は、薬局内システム４００内で用いられている、患者を識別する調剤薬局内ユーザＩＤであり、「レセプト連携ＩＤ」は、患者個人を識別する個人識別ＩＤと、健康保険組合システム２００に保持されているデータとを連携するための情報である。「薬歴データ」は、調剤薬局ＩＤにより特定される薬局内システム４００で入力された薬歴データである。「最終更新日」は、サーバ内データベース１１１における各個人識別ＩＤのデータを最後に更新した日付である。

なお、より詳細には、病院内システム３００に関する薬歴データを含むユーザ薬歴情報では、「調剤薬局ＩＤ」および「調剤薬局内ユーザＩＤ」に代えて、「病院ＩＤ」および「病院内ユーザＩＤ」が用いられる。

以上、データサーバ１１０のサーバ内データベース１１１に記録されるユーザ薬歴情報の具体例について説明した。次に、ユーザ薬歴情報の登録処理例について説明する。

［ユーザ薬歴情報の登録処理例］
図７は、薬局内システム４００によるユーザ薬歴情報の登録処理例に示す流れ図である。以下、図７を用いて薬局内システム４００によるユーザ薬歴情報の登録処理例について説明する。

薬局内システム４００が設けられた薬局に新規のユーザが来局し、処方せんを提出すると、薬局では薬剤師等が提出された処方せんに基づいて、薬局内レセプトコンピュータ４１０の入力部４１２を操作し、ユーザの調剤データの入力を開始する。すると、制御部４１３は、調剤データの入力を受け付けて、薬剤師等の入力部４１２への操作に応じた情報を調剤データとして取得する（ステップＳ１０１）。

また、薬局内システム４００が設けられた薬局にユーザが初めて来局した場合には、薬内データベース４１１には、個人情報等、そのユーザに関する情報は登録（記録）されていないので、薬剤師等は入力部４１２を操作して、ユーザの氏名や生年月日等の個人情報を入力する。また薬剤師等は、入力部４１２を操作して、後述の個人識別ＩＤと、ユーザの保険証番号とを紐付けるためのレセプト連携ＩＤ、またはそのレセプト連携ＩＤの基となるパスコードを入力する。

例えば、薬局内データベース４１１に、図５に示した個人／薬歴情報が記録される場合には、薬剤師等により、ユーザの氏名、生年月日、住所、電話番号、および保険証番号が入力されるとともに、必要に応じてユーザの調剤薬局内ユーザＩＤが付与される。制御部４１３は、これらの情報が入力されると、入力部４１２から取得した調剤データから薬歴データを生成するとともに、入力されたユーザの氏名等の情報や、生成した薬歴データ、ユーザに付与された調剤薬局内ユーザＩＤから個人／薬歴情報を生成する。

なお、ユーザが以前、薬局に来たことがあり、既に薬局内データベース４１１にユーザの個人／薬歴情報が記録されている場合には、個人／薬歴情報の生成は行なわれない。

続いて、制御部４１３は、生成した個人／薬歴情報を薬局内データベース４１１に供給して記録させるとともに、調剤薬局内ユーザＩＤ、ユーザの氏名、およびステップＳ１０１の処理で取得された調剤データ（薬歴データ）を、ローカルエリアネットワークを介して薬局内装置４２０に供給する（ステップＳ１０２）。

続いて、薬局内装置４２０の制御部４２２は、制御部４１３から供給された調剤薬局内ユーザＩＤ、レセプト連携ＩＤ（またはパスコード）、ユーザの氏名、および調剤データを一時的に保持する（ステップＳ１０３）。

薬剤師等は、ユーザの調剤データや個人情報などの入力を終えると、必要に応じて処方された薬剤を調剤し、ユーザに対する投薬を行なう。さらに、ユーザが初めて薬局に来局した場合、薬剤師等はユーザに対して電子お薬手帳の新規登録の希望を確認する。すなわち薬剤師等は、データセンター１００へのユーザ登録の希望を確認する。

ユーザが電子お薬手帳の新規登録を希望すると、薬剤師等は薬局内装置４２０を操作し、新規登録のための処理を行なう。薬局内装置４２０の制御部４２２は、薬剤師等の操作に応じて、一時的に保持している調剤薬局内ユーザＩＤ、ユーザの氏名、および調剤データを、表示部４２４に供給して表示させる。

薬剤師等およびユーザは、表示部４２４に表示された氏名などの情報を確認し、その後、ユーザは所持しているＩＣカード２０をリーダライタ４３０にかざす。すると、リーダライタ４３０はＩＣカード２０と近接非接触通信を行なって、ＩＣカード２０から個人識別ＩＤを受信する。取得部４２１は、リーダライタ４３０からユーザの個人識別ＩＤを取得して、制御部４２２に供給する（ステップＳ１０４）。

続いて、制御部４２２は、一時的に保持しているユーザの調剤薬局内ユーザＩＤと、取得部４２１から供給された個人識別ＩＤとの対応付けを行なう（ステップＳ１０５）。そして制御部４２２は、薬局内システム４００の調剤薬局ＩＤを必要に応じて薬局内レセプトコンピュータ４１０から取得し、調剤薬局ＩＤに対するハッシュ化を行なう。そして制御部４２２は、ハッシュ化の演算により得られたハッシュ値（調剤薬局ＩＤ）と、個人識別ＩＤ、調剤薬局内ユーザＩＤ、レセプト連携ＩＤ、および調剤データを通信部４３３に供給する。

通信部４２３は、制御部４２２から供給された調剤薬局ＩＤ（ハッシュ値）、個人識別ＩＤ、調剤薬局内ユーザＩＤ、レセプト連携ＩＤ、および調剤データを、ネットワーク１０を介してデータサーバ１１０に送信し（ステップＳ１０６）、登録要求処理は終了する。すなわち、通信部４２３は、調剤薬局ＩＤ、個人識別ＩＤ、調剤薬局内ユーザＩＤ、レセプト連携ＩＤ、および調剤データが含まれた、ユーザの新規登録の要求を送信する。

このようにして薬局内システム４００から新規登録の要求が送信されてくると、データサーバ１１０は、その要求に応じて登録処理を行なう。図８は、データサーバ１１０による個人／薬歴情報の登録処理を示す流れ図である。以下、図８を用いて、データサーバ１１０による個人／薬歴情報の登録処理について説明する。

通信部１１２は、薬局内システム４００から送信されてきた調剤薬局ＩＤ（ハッシュ値）、個人識別ＩＤ、調剤薬局内ユーザＩＤ、レセプト連携ＩＤ、および調剤データを受信して、更新部１１３に供給する（ステップＳ１１１）。更新部１１３は、通信部１１２から供給された調剤薬局ＩＤ（ハッシュ値）、個人識別ＩＤ、調剤薬局内ユーザＩＤ、レセプト連携ＩＤ、調剤データ、および最終更新日が含まれるユーザ薬歴情報を生成し、生成したユーザ薬歴情報をサーバ内データベース１１１に追加する（ステップＳ１１２）。すなわち、新たに生成されたユーザ薬歴情報がサーバ内データベース１１１に記録される。これにより、例えば図６に示したユーザ薬歴情報が新たに記録される。なお、ユーザ薬歴情報の生成時においては、更新部１１３は、ユーザの調剤データをそのまま薬歴データとする。

新たに生成されたユーザ薬歴情報がサーバ内データベース１１１に記録されると、ユーザの新規登録が完了し、登録処理は終了する。

以上のようにして、薬局内システム４００は、薬局を特定する調剤薬局ＩＤ、ユーザを特定する個人識別ＩＤおよび調剤薬局内ユーザＩＤ、並びにユーザの調剤データをデータサーバ１１１に送信して、ユーザの登録を要求する。また、データサーバ１１０は、薬局内システム４００から送信されてきた、これらの情報を受信してユーザ薬歴情報を生成し、登録する。

登録時には、薬局内システム４００とデータサーバ１１０との間で、ネットワーク２０を介して個人識別ＩＤ、レセプト連携ＩＤおよび調剤薬局内ユーザＩＤが、ユーザを特定するための情報として授受される。しかしながら、これらの情報が他人に見られたとしても、一般的にはユーザ個人を特定することはほぼ不可能であるから、個人情報が漏洩してしまうことを防止することができ、これによりシステムのセキュリティを向上させることができる。

また、登録時には、薬局内システム４００とデータサーバ１１０との間で、薬局を特定する調剤薬局ＩＤの授受も行われるが、この調剤薬局ＩＤはハッシュ化されたもの、つまりハッシュ値である。したがって、他人がこのハッシュ値から薬局を特定することは困難であるため、これによりセキュリティ向上を図ることができる

このように、電子化された調剤データを、個人を特定せずにデータサーバ１１０に構築することができる。しかし、従来の紙ベースのお薬手帳と同様に、患者が薬局にＩＣカードを持参するのを忘れると、データサーバ１１０に構築される調剤データも完全なものではなくなってしまう。また、個人情報に誤記があったり、一部の情報が正しく分類されなかったり、分類そのものがされなかったりする場合もある。さらに、電子お薬手帳が普及しても、データの蓄積には長時間を要する。

一方、健康保険組合システム２００に構築されるデータは、途中で審査支払機関や健康保険組合によるチェックがあり、不十分なものがあれば病院や薬局に差し戻されるので、個人の薬歴が網羅されているなど精度が高いデータである。しかし、そのようなチェックや差し戻しの時間の関係上、調剤データが健康保険組合システム２００に生成されるまで、薬の処方から２ヶ月程度遅れる。

そこで本実施形態では、データサーバ１１０に構築されるデータと、健康保険組合システム２００に構築されるデータとを、レセプト連携ＩＤを用いて連携させる。これにより、データサーバ１１０に個人情報そのものを保持させること無く、精度が高い調剤データをデータサーバ１１０に構築させることができる。

図９は、本実施形態にかかる情報処理システム１の動作概要を示す説明図である。ユーザが病院内システム３００や薬局内システム４００に対してＩＣカード２０を提示すると、ＩＣカード２０に登録されている個人識別ＩＤが病院内システム３００や薬局内システム４００に提供される。病院内システム３００や薬局内システム４００は、調剤薬局ＩＤ、調剤薬局内ユーザＩＤ、個人識別ＩＤ、診察データや薬歴データ、レセプト連携ＩＤをデータセンター１００に送信する。データセンター１００は、送信されたデータからユーザ薬歴情報を構築する。データセンター１００は、氏名、生年月日、住所等の、直接個人を特定する情報は保持しない。

ユーザは、また病院内システム３００や薬局内システム４００は、健康保険組合２００の電子レセプトと連携するためのレセプト連携ＩＤ、またはレセプト連携ＩＤを生成するための元データ（暗号化の種となるパスコードなど）を作成しておき、予め健康保険組合２００に登録しておく。健康保険組合システム２００は、レセプト連携ＩＤを生成するための元データが登録された場合には、その元データからレセプト連携ＩＤを生成する。例えば、健康保険組合システム２００は、ユーザの保険証番号、ユーザの生年月日、パスコードからなる文字列をＳＨＡ−２５６等のハッシュ関数を用いて一方向ハッシュ化したものをレセプト連携ＩＤとして生成し、内部に保持しておく。

また、病院内システム３００や薬局内システム４００は、審査支払機関５００に対して保険・公費負担分の請求処理を実行する。この際には、氏名、生年月日、保険証番号、診察データや診療データが、病院内システム３００や薬局内システム４００から審査支払機関５００に送られる。審査支払機関５００では、データのチェックや、不備があれば病院や薬局に差し戻す。データが確定すると、審査支払機関５００は、健康保険組合システム２００へ保険・公費負担分の請求処理を実行する。

そして、データセンター１００から所定のタイミングで健康保険組合システム２００に対して、最終更新日およびレセプト連携ＩＤを用いて薬歴データの問い合わせを送信し、健康保険組合システム２００は、問い合わせに応じて、レセプト連携ＩＤおよび薬歴データをデータセンター１００に返信する。データセンター１００は、健康保険組合システム２００から送信された薬歴データを、レセプト連携ＩＤをキーにして更新する。

図１０は、本開示の一実施形態にかかる情報処理システム１の処理動作の一例を示す流れ図である。図１０に示した流れ図は、薬歴データを薬局内システム４００からデータセンター１００に登録する際の動作を示したものである。

ユーザが薬局にＩＣカード２０を持参して、ＩＣカード２０をリーダライタ４３０に接触させると（ステップＳ１２１）、図７及び図８に示したような処理が薬局内システム４００及びデータサーバ１１０で実行されて、個人／薬歴情報がデータサーバ１１０のサーバ内データベース１１１に挿入される（ステップＳ１２２）。

個人／薬歴情報がデータサーバ１１０のサーバ内データベース１１１に挿入されると、データサーバ１１０は、保険証番号、レセプト連携ＩＤ、最終更新日をセットにして健康保険組合システム２００に当該レセプト連携ＩＤを有するユーザの薬歴情報を問い合わせる（ステップＳ１２３）。健康保険組合システム２００は、レセプト連携ＩＤをキーにして、内部に保持しているデータベース等から薬歴情報を取得し、問い合わせ元のデータサーバ１１０へ取得した薬歴情報を送信する（ステップＳ１２４）。

データサーバ１１０は、受信した薬歴情報を、レセプト連携ＩＤをキーにして、サーバ内データベース１１１に統合する（ステップＳ１２５）。

図１０に示した一連の処理により、本開示の一実施形態にかかる情報処理システム１は、データセンター１００には、患者個人を直接特定するような氏名、住所等の情報を保持させずに、健康保険組合システム２００に保持されている薬歴情報との連携を可能にする。

図９及び図１０に示したものは最も基本的な場合であるが、例えば、健康保険組合側が、パスコードを予め知っていたり、データサーバ１１０を仲介せず、ユーザや病院・薬局から健康保険組合に対して薬歴情報を直接問い合わせたりすることも出来る。

図１１は、本実施形態にかかる情報処理システム１の動作概要を示す説明図である。図１１に示した動作概要は、図９に示したものとは異なり、データサーバ１１０を仲介せず、ユーザや病院・薬局から健康保険組合に対して薬歴情報を直接問い合わせる場合を示したものである。図１１では、ユーザや、病院内システム３００、薬局内システム４００から健康保険組合システム２００に対して薬歴情報を直接問い合わせ、健康保険組合システム２００は、その問い合わせに対する結果をデータサーバ１１０に送信する例が示されている。

図１２は、本開示の一実施形態にかかる情報処理システム１の処理動作の一例を示す流れ図である。図１２に示した流れ図は、薬歴データを薬局内システム４００からデータセンター１００に登録する際の動作を示したものである。

ユーザが薬局にＩＣカード２０を持参して、ＩＣカード２０をリーダライタ４３０に接触させると（ステップＳ１３１）、図７及び図８に示したような処理が薬局内システム４００及びデータサーバ１１０で実行されて、個人／薬歴情報がデータサーバ１１０のサーバ内データベース１１１に挿入される（ステップＳ１３２）。

個人／薬歴情報がデータサーバ１１０のサーバ内データベース１１１に挿入されると、ユーザや、病院内システム３００、薬局内システム４００は、保険証番号、最終更新日をセットにして健康保険組合システム２００に当該保険証番号からレセプト連携ＩＤを算出し、そのレセプト連携ＩＤを有するユーザの薬歴情報を問い合わせる（ステップＳ１３３）。健康保険組合システム２００は、レセプト連携ＩＤをキーにして、内部に保持しているデータベース等から薬歴情報を取得し、問い合わせ元のデータサーバ１１０へ取得した薬歴情報を送信する（ステップＳ１３４）。

データサーバ１１０は、受信した薬歴情報を、レセプト連携ＩＤをキーにして、サーバ内データベース１１１に統合する（ステップＳ１３５）。

図１２に示した一連の処理により、本開示の一実施形態にかかる情報処理システム１は、データセンター１００には、患者個人を直接特定するような氏名、住所等の情報を保持させずに、健康保険組合システム２００に保持されている薬歴情報との連携を可能にする。また、ユーザや病院内システム３００、薬局内システム４００から問い合わせる際には、レセプト連携ＩＤを用いないので、仮にユーザや病院内システム３００、薬局内システム４００からのすべての通信が盗聴されたとしても、レセプト連携ＩＤと紐付けることが出来ず、データサーバ１１０から薬歴情報を取得することは不可能であり、セキュリティの向上が可能となる。

ここまで述べてきた例では、健康保険組合システム２００からデータサーバ１１０への薬歴情報の送信開始のトリガを、データサーバ１１０や、ユーザ、病院内システム３００、薬局内システム４００からの問い合わせとするものであったが、本開示は係る例に限定されない。例えば、審査支払機関５００から健康保険組合システム２００へデータが更新されたタイミングで、自動的に健康保険組合システム２００からデータサーバ１１０へ薬歴情報が送信されるようにしても良い。

図１３は、本実施形態にかかる情報処理システム１の動作概要を示す説明図である。図１３に示した動作概要は、図９、図１１に示したものとは異なり、審査支払機関５００から健康保険組合システム２００へデータが更新されたタイミングで、自動的に健康保険組合システム２００からデータサーバ１１０へ薬歴情報が送信される場合を示したものである。このように、自動的に健康保険組合システム２００からデータサーバ１１０へ薬歴情報が送信されるような構成とするには、予め、ユーザ、病院内システム３００、薬局内システム４００から健康保険組合システム２００にレセプト連携ＩＤや、レセプト連携ＩＤの基となるデータを登録しておく。

図１４は、本開示の一実施形態にかかる情報処理システム１の処理動作の一例を示す流れ図である。図１４に示した流れ図は、薬歴データを薬局内システム４００からデータセンター１００に登録する際の動作を示したものである。

ユーザが薬局にＩＣカード２０を持参して、ＩＣカード２０をリーダライタ４３０に接触させると（ステップＳ１４１）、図７及び図８に示したような処理が薬局内システム４００及びデータサーバ１１０で実行されて、個人／薬歴情報がデータサーバ１１０のサーバ内データベース１１１に挿入される（ステップＳ１４２）。

個人／薬歴情報がデータサーバ１１０のサーバ内データベース１１１に挿入され、その後、薬歴情報が健康保険組合システム２００へ更新されると（ステップＳ１４３）、健康保険組合システム２００は、その更新をトリガとして、レセプト連携ＩＤをキーにして、内部に保持しているデータベース等から薬歴情報を取得し、問い合わせ元のデータサーバ１１０へ取得した薬歴情報を送信する（ステップＳ１４４）。

データサーバ１１０は、受信した薬歴情報を、レセプト連携ＩＤをキーにして、サーバ内データベース１１１に統合する（ステップＳ１４５）。

図１２に示した一連の処理により、本開示の一実施形態にかかる情報処理システム１は、データセンター１００には、患者個人を直接特定するような氏名、住所等の情報を保持させずに、健康保険組合システム２００に保持されている薬歴情報との連携を可能にする。また、審査支払機関５００から健康保険組合システム２００へデータが更新されたタイミングで、自動的に健康保険組合システム２００からデータサーバ１１０へ薬歴情報が送信されるので、データの盗聴の心配も無くなり、システムのセキュリティが向上できる。

＜２．まとめ＞
以上説明したように本実施形態によれば、即時性に優れるが抜けのある可能性のある電子お薬手帳のデータと、時間的な遅れはあるがより網羅的で、精度が高い電子レセプトのデータとを、個人を特定できる情報と薬歴とを双方含んだ通信を行わなくとも連携させることが可能になる。これにより、本実施形態にかかる情報処理システム１は、即時性と網羅性を相互補完した薬歴データを作成できる。

具体的には、電子お薬手帳を作成したその日から、健康保険組合システム２００に構築されている所定の期間以前（例えば２ヶ月前より以前）のデータと連携できる。これにより、情報量が多く、所定の期間の間、ユーザは電子お薬手帳を利用していれば、レセプトが電子化されてからの全データがデータサーバ１１０に揃うことになる。もちろん、電子お薬手帳を使用しなかった場合であっても、所定の期間が経過すると、データサーバ１１０のデータは電子レセプトから補完される。

データサーバ１１０と健康保険組合システム２００とのデータ連携のタイミングは、ユーザがＩＣカード２０をリーダライタにタッチして、新たな薬歴情報がデータサーバ１１０に登録されたタイミングであってもよく、ユーザ、病院内システム３００、薬局内システム４００から問い合わせたタイミングであってもよく、審査支払機関５００から健康保険組合システム２００へデータが更新されたタイミングであってもよい。いずれの場合であっても、データサーバ１１０と健康保険組合システム２００とのデータ連携を、セキュアに、また適切なタイミングで行える。

なお、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

例えば、本明細書の各装置が実行する処理における各ステップは、必ずしもシーケンス図またはフローチャートとして記載された順序に沿って時系列に処理する必要はない。例えば、各装置が実行する処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。

また、各装置に内蔵されるＣＰＵ、ＲＯＭおよびＲＡＭなどのハードウェアを、上述した各装置の構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供される。また、機能ブロック図で示したそれぞれの機能ブロックをハードウェアで構成することで、一連の処理をハードウェアで実現することもできる。

なお、本技術は以下のような構成も取ることができる。
（１）
特定の個人を識別することができる情報を保持せず、個人ごとのデータを少なくとも保持するデータ保持部と、
特定の個人を識別することができる情報及び個人ごとのデータを少なくとも保持する他のシステムから少なくとも該データを取得して前記データ保持部に登録するデータ登録部と、
を備え、
前記データ登録部は、前記他のシステムと連携する連携ＩＤを用いて該他のシステムからデータを取得して前記データ保持部に登録する、サーバ装置。
（２）
前記個人ごとのデータは、健康に関するデータである、前記（１）に記載のサーバ装置。
（３）
前記データ登録部は、前記個人ごとの健康に関するデータが送信されてきたタイミングで、前記連携ＩＤを用いて該他のシステムから健康に関するデータを取得して前記データ保持部に登録する、前記（２）に記載のサーバ装置。
（４）
前記データ登録部は、前記他のシステムから所定のタイミングで送信されてくる、前記個人ごとの健康に関するデータを取得して、前記連携ＩＤを用いて前記データ保持部に登録する、前記（２）または（３）に記載のサーバ装置。
（５）
前記データ保持部は、最終更新日の情報を有し、前記データ登録部は、前記他のシステムから前記最終更新日以降の前記個人ごとの健康に関するデータを取得して前記データ保持部に登録する、前記（２）〜（４）のいずれかに記載のサーバ装置。
（６）
前記連携ＩＤは、一方向ハッシュ化によって生成される、前記（２）〜（５）のいずれかに記載のサーバ装置。
（７）
前記他のシステムは、電子レセプトを用いたシステムである、前記（２）〜（６）のいずれかに記載のサーバ装置。
（８）
特定の個人を識別することができる情報及び個人ごとのデータを少なくとも保持する他のシステムから、少なくとも該データを取得して、特定の個人を識別することができる情報を保持せず個人ごとのデータを少なくとも保持するデータ保持部に登録するステップを備え、
前記データ保持部に登録するステップは、前記他のシステムと連携する連携ＩＤを用いて該他のシステムからデータを取得して前記データ保持部に登録する、データ連携方法。
（９）
特定の個人を識別することができる情報及び個人ごとのデータを少なくとも保持する他のシステムから、少なくとも該データを取得して、特定の個人を識別することができる情報を保持せず個人ごとのデータを少なくとも保持するデータ保持部に登録するステップをコンピュータに実行させ、
前記データ保持部に登録するステップは、前記他のシステムと連携する連携ＩＤを用いて該他のシステムからデータを取得して前記データ保持部に登録する、コンピュータプログラム。

１ 情報処理システム
１００ データセンター
１１０ データサーバ
１１１ サーバ内データベース
１１２ 通信部
１１３ 更新部
１１４ ユーザ検索部
１１５ 薬歴検索部
１２０ 情報処理サーバ
２００ 健康保険組合システム
３００ 病院内システム
４００ 薬局内システム

Claims (9)

1. 通信網を介して健康情報管理装置と接続される情報取得端末装置であって、
   ユーザを識別する個人識別情報を取得する取得部と、
   情報を送信および受信する通信部と、
   前記通信部及び前記取得部を制御する制御部と
   を備え、
   前記制御部は、前記健康情報管理装置に対して、前記個人識別情報を前記通信部により送信し、前記個人識別情報に対応付けられた連携ＩＤを用いて他のシステムから取得したユーザの第１の健康に関するデータを前記通信部により受信し、前記第１の健康に関するデータを出力するよう制御する、情報取得端末装置。
2. 前記制御部は、第２の健康に関するデータを前記通信部により受信し、前記第１の健康に関するデータ及び前記第２の健康に関するデータを出力するよう制御する、請求項１に記載の情報取得端末装置。
3. 前記個人識別情報は、ＩＣカードから前記取得部により取得した情報である、請求項１に記載の情報取得端末装置。
4. 前記個人識別情報は、生体情報から固有の情報を個人識別情報として前記取得部により取得した情報である、請求項１に記載の情報取得端末装置。
5. 前記第１の健康に関するデータは、診察情報または調剤情報である、請求項１に記載の情報取得端末装置。
6. 通信網を介して、情報取得端末装置と接続される健康情報管理装置であって、
   ユーザを識別する個人識別情報に対応づけて、他のシステムと連携する連携ＩＤを記憶する記憶部と、
   情報を送信および受信する通信部と、
   前記記憶部および前記通信部を制御する制御部と
   を備え、
   前記制御部は、
   前記情報取得端末装置から、前記個人識別情報を前記通信部により受信し、
   前記他のシステムに対して、前記個人識別情報に対応付けられている前記連携ＩＤを前記通信部により送信し、
   前記他のシステムから、前記連携ＩＤに対応付けられている第１の健康に関するデータを受信し、
   前記情報取得端末装置に対して、前記第１の健康に関するデータを送信するよう制御する、健康情報管理装置。
7. 前記記憶部は、さらに前記個人識別情報に対応づけて、第２の健康に関するデータを記憶し、
   前記制御部は、前記情報取得端末装置に対して、前記第１の健康に関するデータ、および前記第２の健康に関するデータを前記通信部より送信するよう制御する、請求項６に記載の健康情報管理装置。
8. 前記制御部は、前記情報取得端末装置から、第２の健康に関するデータを前記通信部により受信するよう制御する、請求項６に記載の健康情報管理装置。
9. 前記制御部は、前記情報取得端末装置から、前記第２の健康に関するデータを前記通信部により受信した場合に、前記他のシステムから前記第１の健康に関するデータを受信するよう制御する、請求項８に記載の健康情報管理装置。
   

Images