(57)【要約】【課題】レシピエントに適合するドナーを発見するために手間がかかるという問題を解決するドナー検索サーバを提供する。【解決手段】通信部２２１は、複数の病院端末１のそれぞれから、レシピエント情報およびドナー情報を受信する。認証部２２２は、通信部２２１がレシピエント情報を受信するたびに、そのレシピエント情報を医療情報格納部２１１に格納していく。また、認証部２２２は、通信部２２１がドナー情報を受信するたびに、そのレシピエント情報を医療情報格納部２１１に格納していく。管理部２４１は、常に、医療情報格納部２１１に格納されたレシピエント情報およびドナー情報から、互いに同等な適合性を示すレシピエント適合性情報およびドナー適合性情報を含むレシピエント情報およびドナー情報の組を探す。【選択図】図２
2009211373.tif 000002
【特許請求の範囲】
【請求項１】
格納手段と、
複数の登録用端末のそれぞれから、移植片の受容を希望するレシピエントの識別情報、および、該レシピエントの適合性を示すレシピエント適合性情報を含むレシピエント情報と、前記移植片の提供を許可するドナーの識別情報、および、該ドナーの適合性を示すドナー適合性情報を含むドナー情報と、を受信する受信手段と、
前記受信手段が前記レシピエント情報を受信するたびに、該レシピエント情報を前記格納手段に格納していき、また、前記受信手段が前記ドナー情報を受信するたびに、該ドナー情報を前記格納手段に格納していく格納制御手段と、
前記格納手段に格納されたレシピエント情報およびドナー情報から、互いに同等な適合性を示すレシピエント適合性情報およびドナー適合性情報を含むレシピエント情報およびドナー情報の組を繰り返し探す管理手段と、を含むドナー検索サーバ。
【請求項２】
請求項１に記載のドナー検索サーバにおいて、
前記レシピエント情報は、前記レシピエントの宛先を示す宛先情報をさらに含み、
前記ドナー情報は、前記ドナーの宛先を示す宛先情報をさらに含み、
前記管理手段は、前記組を見つけると、前記レシピエントに適合したドナーが発見された旨のマッチング情報を、該組を構成するレシピエント情報およびドナー情報のそれぞれが含む宛先情報のそれぞれが示す宛先に送信する、ドナー検索サーバ。
【請求項３】
請求項１または２に記載のドナー検索サーバにおいて、
前記ドナー情報は、前記ドナーの登録生体認証情報を含み、
前記受信手段は、前記複数の登録用端末のそれぞれから、入力生体認証情報を受信し、
前記管理手段は、前記格納手段に格納されたドナー情報から、前記受信手段が受信した入力生体認証情報と同じ登録生体認証情報を含むドナー情報を探し、該ドナー情報が見つかると、該ドナー情報を当該登録用端末に送信する、ドナー検索サーバ。
【請求項４】
請求項１または２に記載のドナー検索サーバにおいて、
前記レシピエント情報は、前記レシピエントの登録生体認証情報を含み、
前記受信手段は、前記複数の登録用端末のそれぞれから、入力生体認証情報を受信し、
前記管理手段は、前記格納手段に格納されたレシピエント情報から、前記受信手段が受信した入力生体認証情報と同じ登録生体認証情報を含むレシピエント情報を探し、該レシピエント情報が見つかると、該レシピエント情報を当該登録用端末に送信する、ドナー検索サーバ。
【請求項５】
請求項１ないし４のいずれか１項に記載のドナー検索サーバにおいて、
前記受信手段は、前記複数の登録用端末のそれぞれから、医療機関の識別情報と、該医療機関で前記レシピエントを受け入れることが可能か否かを示す受け入れフラッグとを含む受け入れ情報を受信し、
記憶手段と、
前記受信手段が前記受け入れ情報を受信するたびに、該受け入れ情報を前記記憶手段に格納していき、また、定期的に、前記記憶手段に格納された受け入れ情報を前記複数の登録用端末のそれぞれに送信する処理手段と、を含むドナー検索サーバ。
【請求項６】
請求項１ないし４のいずれか１項に記載のドナー検索サーバにおいて、
医療機関に関する医療機関情報を前記医療機関の位置情報ごとに対応付けた設置情報を格納する記録手段と、
ユーザ端末から、該ユーザ端末の位置情報を受信する受付手段と、
前記記録手段に格納された設置情報の中で、少なくとも前記受付手段が受信した位置情報に最も近い位置情報を含む設置情報を、前記ユーザ端末に送信する配信手段と、を含むドナー検索サーバ。
【請求項７】
複数の登録用端末のそれぞれから、移植片の受容を希望するレシピエントの識別情報、および、該レシピエントの適合性を示すレシピエント適合性情報を含むレシピエント情報を受信し、
前記前記レシピエント情報が受信されるたびに、該レシピエント情報を格納していき、
前記移植片の提供を許可するドナーの識別情報、および、該ドナーの適合性を示すドナー適合性情報を含むドナー情報と、を受信し、
前記ドナー情報が受信されるたびに、該ドナー情報を格納していき、
前記格納されたレシピエント情報およびドナー情報から、互いに同等な適合性を示すレシピエント適合性情報およびドナー適合性情報を含むレシピエント情報およびドナー情報の組を繰り返し探す、ドナー検索方法。
【請求項８】
請求項７に記載のドナー検索方法において、
前記レシピエント情報は、前記レシピエントの宛先を示す宛先情報をさらに含み、
前記ドナー情報は、前記ドナーの宛先を示す宛先情報をさらに含み、
前記組が見つかると、前記レシピエントに適合したドナーが発見された旨のマッチング情報を、該組のレシピエント情報およびドナー情報のそれぞれが含む宛先情報のそれぞれが示す宛先に送信する、ドナー検索方法。
【請求項９】
請求項７または８に記載のドナー検索方法において、
前記ドナー情報は、前記ドナーの登録生体認証情報を含み、
前記複数の登録用端末のそれぞれから、入力生体認証情報を受信し、
前記格納されたドナー情報から、前記受信された入力生体認証情報と同じ登録生体認証情報を含むドナー情報を探し、該ドナー情報が見つかると、該ドナー情報を当該登録用端末に送信する、ドナー検索方法。
【請求項１０】
請求項７または８に記載のドナー検索方法において、
前記レシピエント情報は、前記レシピエントの登録生体認証情報を含み、
前記複数の登録用端末のそれぞれから、入力生体認証情報を受信し、
前記格納されたレシピエント情報から、前記受信された入力生体認証情報と同じ登録生体認証情報を含むレシピエント情報を探し、該レシピエント情報が見つかると、該レシピエント情報を当該登録用端末に送信する、ドナー検索方法。
【請求項１１】
請求項７ないし１０のいずれか１項に記載のドナー検索方法において、
前記複数の登録用端末のそれぞれから、医療機関の識別情報と、該医療機関で前記レシピエントを受け入れることが可能か否かを示す受け入れフラッグとを含む受け入れ情報を受信し、
前記受け入れ情報が受信されるたびに、該受け入れ情報を格納していき、また、定期的に、前記格納された受け入れ情報を前記複数の登録用端末のそれぞれに送信する処理手段と、を含むドナー検索方法。
【請求項１２】
請求項７ないし１０のいずれか１項に記載のドナー検索方法において、
医療機関に関する医療機関情報を前記医療機関の位置情報ごとに対応付けた設置情報を格納し、
ユーザ端末から、該ユーザ端末の位置情報を受信し、
前記格納された設置情報の中で、少なくとも前記受信された位置情報に最も近い位置情報を含む設置情報を、前記ユーザ端末に送信する、ドナー検索方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移植を希望するレシピエントに適合するドナーを探すためのドナー検索サーバおよびドナー検索方法に関する。
【背景技術】
【０００２】
ドナーからレシピエントに移植片を移し変える移植は、レシピエントの病気や怪我の治療に有効な場合がある。なお、ここで移植は、内臓移植や組織移植などの狭義の移植ではなく、それらの移植に加え輸血や髄液注入などを含む広義の移植であるとする。
【０００３】
移植を行うためには、レシピエントの適合性と同等な適合性を有するドナー（以下、レシピエントに適合したドナーと称することもある）を発見する必要がある。
【０００４】
適合性は、移植片の種類に応じて異なる。例えば、移植が輸血の場合（移植片が血液の場合）、適合性は、血液型（赤血球の型）で表され、レシピエントの血液型と同じ血液型を有するドナーが、レシピエントに適合したドナーとなる。
【０００５】
レシピエントに適合したドナーを発見するためには、先ず、レシピエントが、自身の適合性を医療機関に通知する（または、医療機関で調査する）。その後、その医療機関のスタッフは、そのレシピエントの適合性を、ドナーの適合性を管理するドナー管理機関に通知する。そして、ドナー管理機関のスタッフは、定期的に、通知されたレシピエントの適合性と、管理しているドナーの適合性とを照合して、レシピエントに適合したドナーを発見していた。
【０００６】
上述の方法では、ドナーが発見されるまでに多くの人手を介するため、ドナーの発見までにかかる時間が長大化し、その結果、移植に遅れが生じていた。移植の遅れは、レシピエントの生命に関わる場合もあるため、ドナーの発見までにかかる時間の短縮化が強く望まれていた。
【０００７】
特許文献１には、臓器移植の一例である献血に関して、ドナーの発見までにかかる時間を短縮化することが可能な献血依頼電子メール送信システムが記載されている。
【０００８】
この献血依頼電子メール送信システムでは、ドナーの血液型および電子メールアドレスを含む希望者情報がデータベースに格納される。また、献血を希望するレシピエントは、自分の血液型をメールサーバに送信する。メールサーバは、レシピエントから送信された血液型と同じ血液型を含む希望者情報をデータベースから抽出する。また、メールサーバは、そのドナーの電子メールアドレスに献血依頼を送信する。その献血依頼を受け取ったドナーは、医療機関に出向き、そこで献血を行う。
【０００９】
これにより、レシピエントは、人手を介さなくてもレシピエントと同じ血液型のドナーを発見することが可能になり、献血に関して、ドナーの発見までにかかる時間を短縮化することが可能になる。
【特許文献１】特開２００４−１２６６４３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
内臓移植や組織移植などの狭義の移植の場合、適合性は、複数の座（遺伝子座）のＨＬＡ（ヒト白血球型抗原：Human Leukocyte Antigen）型で表される。レシピエントおよびドナーは、互いに同等なＨＬＡ型を有する場合、互いに同等な適合性を有する。なお、レシピエントおよびドナーが互いに同等なＨＬＡ型を有するとは、レシピエントおよびドナーのそれぞれのＨＬＡ型の複数の座うち、互いに異なっている座の数が０または所定数より少ないことを意味する。
【００１１】
特許文献１に記載の発明を狭義の臓器移植に適用して、血液型の代わりにＨＬＡ型が送信され、かつ、希望者情報が抽出されれば、狭義の臓器移植でも、ドナーの発見までにかかる時間を短縮化することが可能になる。
【００１２】
しかしながら、ＨＬＡ型には、非常に多くの種類があるため、レシピエントと同等な適合性を有する人の数は非常に少ない。
【００１３】
このため、特許文献１に記載の発明では、レシピエントがＨＬＡ型を送信しても、そのＨＬＡ型と同等なＨＬＡ型を含む希望者情報が既に格納されているとは限らない。したがって、レシピエントは、自身に適合するドナーを発見できるとは限らない。
【００１４】
このような場合、特許文献１に記載の献血依頼電子メール送信システムでは、レシピエントは、時間をおいて何度もＨＬＡ型を送信して、自身に適合したドナーが登録されたか否かを随時確認しなければならない。
【００１５】
このため、レシピエントに適合するドナーを発見するために手間がかかるという問題を有する。なお、このような問題は、狭義の臓器移植に限らず、レシピエントが稀な血液型（例えば、ボンベイ型）である場合などでは、広義の臓器移植でも生じる。
【００１６】
本発明の目的は、上記の課題である、レシピエントに適合するドナーを発見するために手間がかかるという問題を解決するドナー検索サーバおよびドナー検索方法を提供することである。
【課題を解決するための手段】
【００１７】
本発明によるドナー検索サーバは、格納手段と、複数の登録用端末のそれぞれから、移植片の受容を希望するレシピエントの識別情報、および、該レシピエントの適合性を示すレシピエント適合性情報を含むレシピエント情報と、前記移植片の提供を許可するドナーの識別情報、および、該ドナーの適合性を示すドナー適合性情報を含むドナー情報と、を受信する受信手段と、前記受信手段が前記レシピエント情報を受信するたびに、該レシピエント情報を前記格納手段に格納していき、また、前記受信手段が前記ドナー情報を受信するたびに、該ドナー情報を前記格納手段に格納していく格納制御手段と、前記格納手段に格納されたレシピエント情報およびドナー情報から、互いに同等な適合性を示すレシピエント適合性情報およびドナー適合性情報を含むレシピエント情報およびドナー情報の組を繰り返し探す管理手段と、を含む。
【００１８】
また、本発明によるドナー検索方法は、複数の登録用端末のそれぞれから、移植片の受容を希望するレシピエントの識別情報、および、該レシピエントの適合性を示すレシピエント適合性情報を含むレシピエント情報を受信し、前記前記レシピエント情報が受信されるたびに、該レシピエント情報を格納していき、前記移植片の提供を許可するドナーの識別情報、および、該ドナーの適合性を示すドナー適合性情報を含むドナー情報と、を受信し、前記ドナー情報が受信されるたびに、該ドナー情報を格納していき、
前記格納されたレシピエント情報およびドナー情報から、互いに同等な適合性を示すレシピエント適合性情報およびドナー適合性情報を含むレシピエント情報およびドナー情報の組を繰り返し探す。
【発明の効果】
【００１９】
本発明によれば、レシピエントに適合するドナーを発見するための手間を軽減することが可能になる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の実施形態について図面を参照して説明する。
【００２１】
図１は、本発明の一実施形態の医療通信システムを示したブロック図である。
【００２２】
図１において、ドナー検索システムは、病院端末１と、全国医療ネットワークセンタ２と、移動体通信キャリアサーバ３と、ユーザ端末４および５とを含む。
【００２３】
病院端末１、全国医療ネットワークセンタ２および移動体通信キャリアサーバ３は、通信ネットワーク１００を経由して相互に接続可能である。また、移動体通信キャリアサーバ３、ユーザ端末４および５は、通信ネットワーク２００を経由して相互に接続可能である。
【００２４】
通信ネットワーク１００および２００は、公衆網である。通信ネットワーク１００は、固定網でもよいし、移動網でもよい。また、通信ネットワーク２００は、移動網である。
【００２５】
病院端末１は、登録用端末の一例である。病院端末１は、病院などの医療機関に設置され、ユーザ１０にて操作される。ユーザ１０は、例えば、医療機関のスタッフ（医師および看護師など）や、全国医療ネットワークセンタ２を管理する組織の勤務者などである。
【００２６】
なお、病院端末１の数は、複数あればよいが、複数の医療機関のそれぞれに設置されることが望ましい。また、一つの医療機関に複数の病院端末１が設置されてもよい。
【００２７】
図２は、病院端末１の構成例を示したブロック図である。図２において、病院端末１は、入力部１１と、通信部１２と、表示部１３と、制御部１４とを含む。
【００２８】
入力部１１は、ユーザ１０から、入力ログイン認証情報と、レシピエントに関するレシピエント情報と、ドナーに関するドナー情報と、受け入れ情報と、入力生体認証情報とを受け付ける。
【００２９】
入力ログイン認証情報は、ユーザ１０を認証するための認証情報であり、例えば、ユーザ１０や医療機関の名前とパスワードからなる。
【００３０】
レシピエント情報は、レシピエント登録情報と、レシピエントの個人情報と、レシピエントの登録生体認証情報とを含む。
【００３１】
レシピエント登録情報は、レシピエントが受容を希望する移植片の種類と、レシピエントの適合性を示すレシピエント適合性情報とを含む。移植片の種類は、例えば、各種臓器、各種組織（皮膚、心臓弁および血管など）、血液および骨髄液などである。適合性は、移植片の種類に応じて異なっていている。例えば、適合性は、移植片が赤血球の場合、血液型であり、移植片が臓器、組織および骨髄液などの場合、複数の座を有するＨＬＡ型である。
【００３２】
なお、レシピエントが骨髄バンクに登録してある場合、レシピエント登録情報は、移植片の種類を骨髄液とし、レシピエント適合性情報を骨髄バンクに登録された適合性を示す情報としたものでもよい。
【００３３】
レシピエントの個人情報は、レシピエントの識別情報（例えば、レシピエントの名前）、レシピエントの宛先を示す宛先情報（例えば、電子メールアドレスなど）、レシピエントの血液型、および、疾患の有無などを含む。レシピエントの登録生体認証情報は、レシピエントの指紋情報や虹彩情報などの生体認証情報である。
【００３４】
また、ドナー情報は、ドナー登録情報と、ドナーの個人情報と、ドナーの生体認証情報とを含む。
【００３５】
ドナー登録情報は、ドナーが提供を許可する移植片の種類と、ドナーの適合性を示すドナー適合性情報とを含む。ここで、ドナーが骨髄バンクに登録してある場合、ドナーの登録情報は、移植片の種類を骨髄液とし、ドナーの適合性情報を骨髄バンクに登録された情報としたものでもよい。なお、ドナーが提供を許可する移植片の種類は、従来では、ドナーカードにドナーが手書きで書いていた。
【００３６】
ドナーの個人情報は、ドナーの名前、ドナーの宛先を示す宛先情報（例えば、電子メールアドレスなど）、ドナーの赤血球の血液型、および、疾患の有無などを含む。ドナーの生体認証情報は、ドナーの指紋情報や虹彩情報などである。
【００３７】
受け入れ情報は、医療機関の識別情報と、その医療機関がレシピエントを受け入れることが可能か否かを示す受け入れフラグとを含む。
【００３８】
入力生体認証情報は、患者の生体認証情報である。
【００３９】
通信部１２は、全国医療ネットワークセンタ２から、ログイン情報と、登録画面情報と、レシピエント情報と、ドナー情報とを受信する。
【００４０】
ログイン情報は、ユーザ１０を認証するためのログイン画面を示す情報であり、入力ログイン認証情報を入力するための入力フォームなどを含む。また、登録画面情報は、レシピエント情報またはドナー情報を登録するための登録画面を示し、レシピエント情報およびドナー情報を入力するための入力フォームなどを含む。
【００４１】
表示部１３は、通信部１２が受信したログイン情報、登録画面情報、レシピエント情報およびドナー情報を表示する。
【００４２】
制御部１４は、入力部１１が受け付けた入力ログイン認証情報、入力生体認証情報、レシピエント情報、ドナー情報および受け入れ情報を全国医療ネットワークセンタ２に送信する。
【００４３】
図１に戻る。全国医療ネットワークセンタ２は、ドナー検索サーバの一例である。全国医療ネットワークセンタ２は、全国医療ネットワークセンタ２を管理する組織の勤務者によって操作される。全国医療ネットワークセンタ２は、一つのサーバから構成されてもよいし、複数のサーバから構成されてもよい。本実施形態では、全国医療ネットワークセンタ２は、複数のサーバから構成されるものとする。
【００４４】
図３は、全国医療ネットワークセンタ２の構成例を示したブロック図である。図３において、全国医療ネットワークセンタ２は、データベースサーバ２１と、認証サーバ２２と、Ｗｅｂサーバ２３と、運用管理サーバ２４とを含む。データベースサーバ２１、認証サーバ２２、Ｗｅｂサーバ２３および運用管理サーバ２４は、通信ネットワーク３００を経由して相互に接続可能である。なお、通信ネットワーク３００は、固定網かつ専用網であることが、レシピエントおよびドナーの個人情報を保護するという点から望ましい。
【００４５】
データベースサーバ２１は、医療情報格納部２１１を含む。
【００４６】
医療情報格納部２１１は、格納手段の一例である。医療情報格納部２１１は、登録ログイン認証情報を格納する。登録ログイン認証情報は、ユーザ１０を認証するための認証情報である。
【００４７】
認証サーバ２２は、通信部２２１と、認証部２２２とを含む。
【００４８】
通信部２２１は、受信手段の一例である。通信部２２１は、病院端末１のそれぞれから、入力ログイン認証情報、レシピエント情報、ドナー情報、受け入れ情報および入力生体認証情報を受信する。
【００４９】
また、通信部２２１は、ユーザ端末５から、提供を許可する移植片の種類を変更する旨の変更要求を受け付ける。なお、変更要求は、ドナーの入力生体認証情報と、提供を許可する移植片の種類とを含む。
【００５０】
認証部２２２は、格納制御手段の一例である。認証部２２２は、医療情報格納部２１１に格納された登録ログイン認証情報から、通信部２２１が受信した入力ログイン認証情報と同じ登録ログイン認証情報を探す。
【００５１】
認証部２２２は、入力ログイン認証情報と同じ登録ログイン認証情報を見つけると、認証が成功したと判断し、認証の成功を示す認証結果として、Ｗｅｂサーバ２３内の登録情報画面を病院端末１に送信する。また、認証部２２２は、入力ログイン認証情報と同じ登録ログイン認証情報が見つからないと、認証が失敗したと判断し、認証の失敗を示す認証結果として、Ｗｅｂサーバ２３内のログイン情報を病院端末１に送信する。
【００５２】
認証部２２２は、認証が成功したと判断すると、その後、通信部２２１がその病院端末１からレシピエント情報、ドナー情報または受け入れ情報を受信するたびに、その受信したレシピエント情報、ドナー情報または受け入れ情報を医療情報格納部２１１に格納していく。
【００５３】
また、認証部２２２は、通信部２２１が変更要求を受信すると、医療情報格納部２１１に格納されたドナー情報から、その変更要求内の入力生体認証情報と同じ登録生体認証情報を含むドナー情報を探す。認証部２２２は、そのドナー情報を見つけると、そのドナー情報に含まれる移植片の種類を、変更要求内の移植片の種類に変更する。
【００５４】
Ｗｅｂサーバ２３は、Ｗｅｂ情報格納部２３１と、処理部２３２とを含む。
【００５５】
Ｗｅｂ情報格納部２３１は、記憶手段の一例である。Ｗｅｂ情報格納部２３１は、ログイン情報と、登録画面情報と、設置情報とを格納する。設置情報では、医療機関に関する医療機関情報が医療機関の位置情報ごとに対応付けられている。ここで、医療機関は、例えば、病院（救急病院を含む）、献血場所およびＡＥＤ（Automated External Defibrillator：自動体外式除細動器）の設置場所などである。また、医療機関情報は、例えば、医療機関の名前、医療機関の種類、医療機関で受けられる治療の種類などである。
【００５６】
なお、設置情報は、医療機関の位置情報が変更されたり、新たな医療機関が設置されたりした場合に、速やかに更新されることが望ましい。
【００５７】
処理部２３２は、病院端末１と認証サーバ２２とが接続されると、Ｗｅｂ情報格納部２３１に格納されたログイン情報を病院端末１に送信する。
【００５８】
また、処理部２３２は、定期的に、Ｗｅｂ情報格納部２３１に格納された設置情報を移動体通信キャリアサーバ３に通知する。
【００５９】
また、処理部２３２は、認証サーバ２２の通信部２２１が受け入れ情報を受信するたびに、その受け入れ情報をＷｅｂ情報格納部２３１に格納していく。
【００６０】
また、処理部２３２は、定期的に、Ｗｅｂ情報格納部２３１に格納された全ての受け入れ情報を病院端末１のそれぞれに送信する。
【００６１】
運用管理サーバ２４は、管理部２４１を含む。
【００６２】
管理部２４１は、データベースサーバ２１の医療情報格納部２１１に格納されたレシピエント情報およびドナー情報から、互いに同じ移植片の種類を含むレシピエント情報およびドナー情報の組を繰り返し探す。このとき管理部２４１は、常時、その組を探すことが望ましい。
【００６３】
管理部２４１は、その組が見つかると、その組みから、互いに同等な適合性を示すレシピエント適合性情報およびドナー適合性情報を含むレシピエント情報およびドナー情報の組（以下、適合組と称することもある）を探す。
【００６４】
例えば、適合性がＨＬＡ型で表される場合、管理部２４１は、レシピエント適合性情報およびドナー適合性情報のそれぞれが示すＨＬＡ型を互いに照合し、互いに異なっているＨＬＡ型の座の相違数が所定数より少ないレシピエント適合性情報およびドナー適合性情報の組を、適合組として探す。なお、相違数は、０を含む。また、管理部２４１は、相違数が所定数より少ない組が複数ある場合、その複数の組の中で、相違数が最も少ない組を適合組みとする。
【００６５】
管理部２４１は、適合組を見つけると、レシピエントに適合したドナーが発見された旨のマッチング情報を移動体通信キャリアサーバ３に通知する。このとき、マッチング情報には、適合組を構成するレシピエント情報およびドナー情報のそれぞれに含まれる宛先情報のそれぞれが付けられている。
【００６６】
そして、管理部２４１は、医療情報格納部２１１に格納された、適合組のレシピエント情報およびドナー情報を対応付ける。
【００６７】
また、管理部２４１は、通信部２２１が受信した入力生体認証情報と同じ登録生体認証情報を含むレシピエント情報またはドナー情報を、医療情報格納部２１１に格納されたレシピエント情報およびドナー情報から探す。認証部２２２は、そのレシピエント情報またはドナー情報を見つけると、そのレシピエント情報またはドナー情報を病院端末１に送信する。
【００６８】
このとき、管理部２４１は、レシピエント情報を見つけ、そのレシピエント情報にドナー情報が対応付けられていれば、そのレシピエント情報およびドナー情報の両方を送信する。また、管理部２４１は、ドナー情報を見つけ、そのドナー情報にレシピエント情報が対応付けられていれば、そのドナー情報およびレシピエント情報の両方を送信する。
【００６９】
図１に戻る。移動体通信キャリアサーバ３は、移動体通信キャリアにて管理され、ユーザ端末４および５に無線通信サービスを提供する。
【００７０】
図４は、移動体通信キャリアサーバ３の構成例を示したブロック図である。図４において、移動体通信キャリアサーバ３は、通信部３１と、設置情報格納部３２と、配信部３３とを含む。
【００７１】
通信部３１は、受付手段の一例である。配信部３３は、全国医療ネットワークセンタ２から、マッチング情報と、設置情報とを受信する。また、通信部３１は、ユーザ端末４および５から、そのユーザ端末の位置情報を受信する。
【００７２】
設置情報格納部３２は、記録手段の一例である。設置情報格納部３２は、設置情報の宛先を示す設置宛先情報を格納する。
【００７３】
配信部３３は、通信部３１が受信したマッチング情報を、マッチング情報に付いた宛先情報のそれぞれが示す宛先に通知する。例えば、配信部３３は、電子メールやプッシュ（Ｐｕｓｈ）型サービスを用いて、マッチング情報を通知する。これにより、全国医療ネットワークセンタ２の管理部２４１は、マッチング情報を、適合組を構成するレシピエント情報およびドナー情報のそれぞれが含む宛先に送信することになる。
【００７４】
また、配信部３３は、通信部３１が設置情報を受信すると、その設置情報を設置情報格納部３２に格納する。そして、配信部３３は、設置情報格納部３２に格納された設置宛先情報のそれぞれが示す宛先のそれぞれに、そのユーザ端末の位置情報を取得する旨の位置取得要求を送信する。
【００７５】
配信部３３は、ユーザ端末４または５からそのユーザ端末の位置情報を受信すると、設置情報格納部３２の中で、少なくともユーザ端末の位置情報に最も近い医療機関の位置情報を含む設置情報を、そのユーザ端末に送信する。
【００７６】
なお、配信部３３は、位置取得要求を、ユーザ端末４および５の位置情報を管理しているホームメモリに送信することで、ホームメモリからそのユーザ端末の位置情報を取得してもよい。
【００７７】
なお、移動体通信キャリアサーバ３の機能は、全国医療ネットワークセンタ２に組み込まれてもよい。
【００７８】
図１に戻る。ユーザ端末４および５は、例えば、携帯電話などの携帯端末である。ユーザ端末４は、レシピエントであるユーザ２０にて使用され、ユーザ端末５は、ドナーであるユーザ３０にて使用される。なお、図１では、ユーザ端末４の数は、２だけだが、実際には、２以上であればよい。
【００７９】
図５は、ユーザ端末４および５の構成例を示したブロック図である。図５において、ユーザ端末４および５は、位置情報取得部４１と、入力部４２と、通信部４３と、端末制御部４４と、表示部４５とを含む。
【００８０】
位置情報取得部４１は、ＧＰＳ機能により、自端末の位置情報を取得する。
【００８１】
入力部４２は、ユーザ２０または３０から、医療機関の設置場所を取得する旨の場所取得要求を受け付ける。
【００８２】
また、ユーザ端末５の入力部４２は、ユーザ３０から変更要求を受け付ける。
【００８３】
通信部４３は、移動体通信キャリアサーバ３からマッチング情報と、位置取得要求と、設置情報とを受信する。
【００８４】
端末制御部４４は、通信部４３が位置取得要求を受信した場合、および、入力部４２が場所取得要求を受け付けた場合、位置情報取得部４１にて取得された位置情報を、自端末の位置情報として移動体通信キャリアサーバ３に送信する。
【００８５】
また、端末制御部４４は、入力部４２が受け付けた変更要求を全国医療ネットワークセンタ２に送信する。
【００８６】
表示部４５は、通信部４３が受信したマッチング情報および設置情報を表示する。
【００８７】
次に動作を説明する。
【００８８】
先ず、レシピエント情報の登録に関するドナー検索システムの動作を説明する。図６は、この動作例を説明するためのフローチャートである。
【００８９】
ステップＳ１０１では、レシピエント（ユーザ２０）が、自身のレシピエント情報の登録をユーザ１０に依頼する。その依頼を受けたユーザ１０は、ステップＳ１０２を実行する。
【００９０】
ステップＳ１０２では、ユーザ１０は、病院端末１を操作して、病院端末１から通信ネットワーク１００を経由して全国医療ネットワークセンタ２の認証サーバ２２にアクセスする。認証サーバ２２は、病院端末１からアクセスされると、ステップＳ１０３を実行する。
【００９１】
ステップＳ１０３では、病院端末１の認証部２２２は、病院端末からアクセスされた旨を、運用管理サーバ２４を経由してＷｅｂサーバ２３の処理部２３２に送信する。処理部２３２は、その旨を受信すると、Ｗｅｂ情報格納部２３１からログイン情報を取得し、そのログイン情報を認証部２２２に送信する。認証部２２２は、ログイン情報を受信すると、ステップＳ１０４を実行する。
【００９２】
ステップＳ１０４では、認証部２２２は、ログイン情報を、通信部２２１を経由して病院端末１の通信部１２に送信する。
【００９３】
通信部１２は、ログイン情報を受信すると、そのログイン情報を制御部１４に送信する。制御部１４は、ログイン情報を受信すると、そのログイン情報を表示部１３に表示する。その後、制御部１４は、入力部１１が入力ログイン認証情報を受け付けると、ステップＳ１０５を実行する。
【００９４】
ステップＳ１０５では、制御部１４は、入力ログイン認証情報を、通信部１２を経由して、認証サーバ２２の通信部２２１に送信する。通信部２２１は、入力ログイン認証情報を受信すると、その入力ログイン認証情報を認証部２２２に送信する。認証部２２２は、入力ログイン認証情報を受信すると、ステップＳ１０６を実行する。
【００９５】
ステップＳ１０６では、認証部２２２は、データベースサーバ２１の医療情報格納部２１１にアクセスする。認証部２２２は、入力ログイン認証情報を、医療情報格納部２１１内の登録ログイン認証情報と照合していくことで、入力ログイン認証情報と同じ登録ログイン認証情報を医療情報格納部２１１から探す。
【００９６】
認証部２２２は、入力ログイン認証情報と同じ登録ログイン認証情報を見つけると、ステップＳ１０７を実行し、入力ログイン認証情報と同じ登録ログイン認証情報が見つからないと、ステップＳ１０８を実行する。
【００９７】
ステップＳ１０７では、認証部２２２は、認証が成功したと判断し、認証が成功した旨を、運用管理サーバ２４を経由してＷｅｂサーバ２３の処理部２３２に送信する。処理部２３２は、その旨を受信すると、Ｗｅｂ情報格納部２３１から登録画面情報を取得し、その登録画面情報を認証部２２２に送信する。認証部２２２は、登録画面情報を受信すると、その登録画面情報を、通信部２２１を経由して病院端末１の通信部１２に送信する。
【００９８】
通信部１２は、登録画面情報を受信すると、その登録画面情報を制御部１４に送信する。制御部１４は、登録画面情報を受信すると、その登録画面情報を表示部１３に表示する。
【００９９】
その後、制御部１４は、入力部１１がユーザ１０からレシピエント情報を受け付けると、ステップＳ１０９を実行する。
【０１００】
ステップＳ１０８では、認証部２２２は、認証が失敗したと判断し、認証が失敗した旨を、運用管理サーバ２４を経由してＷｅｂサーバ２３の処理部２３２に送信する。処理部２３２は、その旨を受信すると、Ｗｅｂ情報格納部２３１からログイン情報を取得し、そのログイン情報を認証部２２２に送信する。認証部２２２は、ログイン情報を受信すると、そのログイン情報に認証の失敗を示す認証不可情報を付けて、通信部２２１を経由して病院端末１の通信部１２に送信する。なお、認証不可情報は、例えば、認証の失敗を示すポップアップ画面を示す。
【０１０１】
通信部１２は、ログイン情報を受信すると、そのログイン情報を制御部１４に送信する。制御部１４は、ログイン情報を受信すると、そのログイン情報を表示部１３に表示する。その後、制御部１４は、入力部１１が入力ログイン認証情報を受け付けると、ステップＳ１０５を実行する。
【０１０２】
ステップＳ１０９では、制御部１４は、レシピエント情報を、通信部１２を経由して認証サーバ２２の通信部２２１に送信する。通信部２２１は、レシピエント情報を受信すると、そのレシピエント情報を認証部２２２に送信する。認証部２２２は、レシピエント情報を受信すると、そのレシピエント情報をデータベースサーバ２１の医療情報格納部２１１に格納する。
【０１０３】
なお、ドナー情報の登録に関するドナー検索システムの動作は、図６で説明した動作において、ユーザ２０をユーザ３０に読み替え、レシピエントをドナーに読み換えればよいため、詳細な説明は省略する。
【０１０４】
次に、レシピエント情報とドナー情報のマッチングを行う際のドナー検索システムの動作を説明する。図７は、この動作を説明するためのフローチャートである。
【０１０５】
ステップＳ２０１では、常時、運用管理サーバ２４の管理部２４１は、データベースサーバ２１の医療情報格納部２１１に格納されたレシピエント情報およびドナー情報から、互いに同じ移植片の種類を含むレシピエント情報およびドナー情報の組を繰り返し探す。管理部２４１は、その組が見つかると、その組みから、適合組を探す。
【０１０６】
管理部２４１は、その適合組を見つけると、ステップＳ２０２を実行し、その適合組が見つからないと、ステップＳ２０１を実行する。
【０１０７】
ステップＳ２０２では、管理部２４１は、マッチング情報を生成する。マッチング情報に、その適合組を構成するレシピエント情報およびドナー情報のそれぞれに含まれる宛先情報のそれぞれを付ける。管理部２４１は、その宛先情報を付けたマッチング情報を、認証サーバ２２を経由して移動体通信キャリアサーバ３の通信部３１に送信する。通信部３１は、マッチング情報を受信すると、ステップＳ２０３を実行する。
【０１０８】
ステップＳ２０３では、通信部３１は、マッチング情報を配信部３３に送信する。配信部３３は、マッチング情報を受信すると、そのマッチング情報に付いた宛先情報が示す宛先のそれぞれに（以下、ユーザ端末４および５とする）に、そのマッチング情報を通知する。ユーザ端末４および５の通信部４３は、マッチング情報を受信すると、ステップＳ２０４を実行する。
【０１０９】
ステップＳ２０４では、通信部４３は、そのマッチング情報を端末制御部４４に送信する。端末制御部４４は、マッチング情報を受信すると、そのマッチング情報を表示部４５に表示する。
【０１１０】
マッチング情報を確認したユーザ２０および３０は、所定の医療機関に出向き、移植を行う。
【０１１１】
しかしながら、ユーザ端末がマッチング情報を受信しても、そのユーザ端末のユーザ２０または３０が意識不明である場合、そのユーザはマッチング情報を確認することができない。
【０１１２】
この場合、意識不明者が搬送された医療機関のスタッフであるユーザ１０は、その搬送されたユーザの生体認証情報を取得し、その取得した生体認証情報を入力生体認証情報として病院端末１の入力部１１に入力する。入力部１１が入力生体認証情報を受け付けると、制御部１４は、その入力生体認証情報を、通信部１２を経由して認証サーバ２２の通信部２２１に送信する。通信部２２１は、入力生体認証情報を受信すると、その入力生体認証情報を、認証サーバ２２を経由して管理部２４１に送信する。
【０１１３】
続いて、管理部２４１は、入力生体認証情報を受信すると、その入力生体認証情報を、医療情報格納部２１１に格納されたレシピエント情報およびドナー情報から、その入力生体認証情報と同じ登録生体認証情報を含むレシピエント情報またはドナー情報を探す。
【０１１４】
管理部２４１は、レシピエント情報またはドナー情報を見つけると、そのレシピエント情報またはドナー情報を、認証サーバ２２を経由して、病院端末１の通信部１２に送信する。
【０１１５】
このとき、管理部２４１は、見つけたレシピエント情報にドナー情報が対応けられていると、そのレシピエント情報およびドナー情報の両方を送信する。また、管理部２４１は、見つけたドナー情報にレシピエント情報が対応付けられていると、そのドナー情報およびレシピエント情報の両方を送信する。
【０１１６】
そして、通信部１２は、レシピエント情報およびドナー情報の少なくとも一方を受信すると、その受信した情報を制御部１４に送信する。制御部１４は、その情報を受信すると、その受信した情報を表示部１３に表示する。
【０１１７】
次に、受け入れ情報の登録の際のドナー検索システムの動作を説明する。
【０１１８】
先ず、図６で説明したステップ１０２からステップＳ１０７が実行される。その後、病院端末１の制御部１４は、入力部１１がユーザ１０から受け入れ情報を受け付けると、その受け入れ情報を、通信部１２を経由して、認証サーバ２２の通信部２２１に送信する。
【０１１９】
通信部２２１は、受け入れ情報を受信すると、その受け入れ情報を、認証部２２２を経由してＷｅｂサーバ２３の処理部２３２に送信する。処理部２３２は、受け入れ情報を受信すると、その受け入れ情報をＷｅｂ情報格納部２３１に格納する。
【０１２０】
また、処理部２３２は、定期的に、Ｗｅｂ情報格納部２３１に格納された受け入れ情報を全て取得し、その受け入れ情報を、運用管理サーバ２４および認証サーバ２２を経由して病院端末１のそれぞれの通信部１２に送信する。
【０１２１】
通信部１２は、受け入れ情報を受信すると、その受け入れ情報を制御部１４に送信する。制御部１４は、受け入れ情報を受信すると、その受け入れ情報を表示部１３に表示する。
【０１２２】
次に、設置情報の配信の際のドナー検索システムの動作を説明する。
【０１２３】
先ず、処理部２３２は、定期的に、Ｗｅｂ情報格納部２３１から設置情報を取得し、その設置情報を、運用管理サーバ２４および認証サーバ２２を経由して移動体通信キャリアサーバ３の通信部３１に送信する。通信部３１は、設置情報を受信すると、その設置情報を配信部３３に送信する。配信部３３は、設置情報を受信すると、その設置情報を設置情報格納部３２に格納する。
【０１２４】
配信部３３は、設置情報格納部３２に格納された設置宛先情報を取得し、その設置宛先情報のそれぞれが示す宛先のそれぞれに位置取得要求を送信する。
【０１２５】
その宛先であるユーザ端末４および５の通信部４３は、位置取得要求を受信すると、その位置取得要求を端末制御部４４に送信する。端末制御部４４は、位置取得要求を受信すると、位置情報取得部４１から自端末の位置情報を取得し、その位置情報を通信部４３を経由して移動体通信キャリアサーバ３の通信部３１に送信する。
【０１２６】
通信部３１は、位置情報を受信すると、その位置情報を配信部３３に送信する。配信部３３は、位置情報を受信すると、少なくともその受信した位置情報に最も近い医療機関の位置情報を含む設置情報を設置情報格納部３２から取得し、その取得した設置情報を、位置情報を送信したユーザ端末の通信部４３に送信する。
【０１２７】
通信部４３は、設置情報を受信すると、その設置情報を端末制御部４４に送信する。端末制御部４４は、設置情報を受信すると、その設置情報を表示部４５に表示する。
【０１２８】
なお、ユーザ１０および２０が自発的に設置情報を取得することもできる。この場合、そのユーザは、そのユーザのユーザ端末に場所取得要求を入力する。入力部４２が場所取得要求を受け付けると、端末制御部４４は、位置情報取得部４１から自端末の位置情報を取得し、その位置情報を、通信部４３を経由して移動体通信キャリアサーバ３の通信部３１に送信する。通信部４３が位置情報を受信した後の動作は、上記の動作と同じであるため、詳細な説明は省略する。
【０１２９】
次に、ドナーが提供を許可する移植片を変更する際の動作を説明する。
【０１３０】
先ず、ユーザ端末５の入力部４２が、ドナーであるユーザ３０から変更要求を受け付けると、端末制御部４４は、その変更要求を、全国医療ネットワークセンタ２の認証サーバ２２の通信部２２１に送信する。通信部２２１は、変更要求を受信すると、その変更要求を認証部２２２に送信する。
【０１３１】
認証部２２２は、変更要求を受信すると、医療情報格納部２１１に格納されたドナー情報から、変更要求内の入力生体認証情報と同じ登録生体認証情報を含むドナー情報を探す。認証部２２２は、そのドナー情報を見つけると、そのドナー情報に含まれる移植片の種類を、変更要求内の移植片の種類に変更する。
【０１３２】
次に効果を説明する。
【０１３３】
本実施形態によれば、通信部２２１は、複数の病院端末１のそれぞれから、レシピエント情報およびドナー情報を受信する。認証部２２２は、通信部２２１がレシピエント情報を受信するたびに、そのレシピエント情報を医療情報格納部２１１に格納していく。また、認証部２２２は、通信部２２１がドナー情報を受信するたびに、そのレシピエント情報を医療情報格納部２１１に格納していく。管理部２４１は、常に、医療情報格納部２１１に格納されたレシピエント情報およびドナー情報から、互いに同等な適合性を示すレシピエント適合性情報およびドナー適合性情報を含むレシピエント情報およびドナー情報の組を探す。
【０１３４】
この場合、常に、互いに同等な適合性を示すレシピエント適合性情報およびドナー適合性情報含むレシピエント情報およびドナー情報の組が探される。
【０１３５】
このため、レシピエントは、時間をおいて何度も情報を送信しなくても、自身に適合するドナーを発見することが可能になる。したがって、レシピエントに適合するドナーを発見するために手間を軽減することが可能になる。
【０１３６】
また、本実施形態では、管理部２４１は、レシピエント情報およびドナー情報の組を見つけると、レシピエントに適合したドナーが発見された旨のマッチング情報を、その組のレシピエント情報およびドナー情報のそれぞれが含む宛先情報のそれぞれが示す宛先に送信する。
【０１３７】
この場合、レシピエントは、直ぐに、自身に適合したドナーが発見されたことを知ることが可能になる。また、ドナーは、自身の移植片が役立つことを知ることが可能になる。したがって、移植に対する関心が高まり、ドナー登録する人の数が増加する可能性がある。
【０１３８】
また、本実施形態では、管理部２４１は、医療情報格納部２１１に格納されたドナー情報から、通信部２２１が受信した入力生体認証情報と同じ登録生体認証情報を含むドナー情報を探し、そのドナー情報が見つかると、そのドナー情報およびレシピエント情報を病院端末１に送信する。
【０１３９】
従来、病院端末１が設置された医療機関に、意識不明の患者が搬送された場合、患者がドナーカードを所持していなければ、その患者がドナーであることが判断できなかった。本実施形態では、患者がドナーカードを所持していなくても、その患者がドナーであることを確認することが可能になる。
【０１４０】
また、本実施形態では、管理部２４１は、医療情報格納部２１１に格納されたレシピエント情報から、通信部２２１が受信した入力生体認証情報と同じ登録生体認証情報を含むレシピエント情報を探し、そのレシピエント情報が見つかると、そのドナー情報を病院端末１に送信する。
【０１４１】
この場合、意識不明の患者がレシピエントであることを確認することが可能になる。
【０１４２】
また、本実施形態では、通信部２２１は、病院端末１のそれぞれから、医療機関の識別情報と、その医療機関でレシピエントが受け入れることが可能か否かを示す受け入れフラッグとを含む受け入れ情報を受信する。処理部２３２は、通信部２２１が受け入れ情報を受信するたびに、その受け入れ情報をＷｅｂ情報格納部２３１に格納していく。また、処理部２３２は、定期的に、Ｗｅｂ情報格納部２３１に格納された受け入れ情報を病院端末１のそれぞれに送信する。
【０１４３】
この場合、病院端末１が医療機関のそれぞれに設置されれば、レシピエントを受け入れることが可能な医療機関を、他の医療機関のスタッフが知ることが可能になる。したがって、迅速にレシピエントを受け入れ可能な医療機関に搬送することが可能になり、迅速な移植を行うことが可能になる。
【０１４４】
また、本実施形態では、設置情報格納部３２は、医療機関に関する医療機関情報を医療機関の位置情報ごとに対応付けた設置情報を格納する。通信部３１は、ユーザ端末の位置情報を受信する。配信部３３は、設置情報格納部３２に格納された設置情報の中で、少なくとも通信部３１が受信した位置情報に最も近い位置情報を含む設置情報を、そのユーザ端末に送信する。
【０１４５】
この場合、ユーザは、最も近い医療機関を知ることが可能になり、例えば、急に体調が悪化したり、急に怪我をした場合などでも、直ぐに医療機関に出向くことが可能になる。
【０１４６】
以上説明した各実施形態において、図示した構成は単なる一例であって、本発明はその構成に限定されるものではない。
【０１４７】
例えば、通信ネットワーク２００は、移動網としたが、固定網でもよい。
【０１４８】
また、移動体通信キャリアサーバ３の代わりに、アプリケーションサービスプロバイダ（ＡＳＰ：Application Service Provider）または仮想移動体サービス事業者（ＭＶＮＯ：Mobile Virtual Network Operator）にて管理されるサーバが用いられてもよい。
【図面の簡単な説明】
【０１４９】
【図１】本発明の第一の実施形態のドナー検索システムを示したブロック図である。
【図２】病院端末の構成例を示したブロック図である。
【図３】全国医療ネットワークセンタの構成例を示したブロック図である。
【図４】移動体通信キャリアサーバの構成例を示したブロック図である。
【図５】ユーザ端末の構成例を示したブロック図である。
【図６】レシピエント情報の登録に関するドナー検索システムの動作を説明するためのフローチャートである。
【図７】レシピエント情報とドナー情報のマッチングを行う際のドナー検索システムの動作を説明するためのフローチャートである。
【符号の説明】
【０１５０】
１        病院端末
２        全国医療ネットワークセンタ
３        移動体通信キャリアサーバ
４、５    ユーザ端末
１１      入力部
１２      通信部
１３      表示部
１４      制御部
２１      データベースサーバ
２２      認証サーバ
２３      Ｗｅｂサーバ
２４      運用管理サーバ
３１      通信部
３２      設置情報格納部
３３      配信部
４１      位置情報取得部
４２      操作部
４３      通信部
４４      端末制御部
４５      表示部
２１１    医療情報格納部
２２１    通信部
２２２    認証部
２３１    Ｗｅｂ情報格納部
２３２    処理部
２４１    管理部
【図１】
2009211373.tif 000003
【図２】
2009211373.tif 000004
【図３】
2009211373.tif 000005
【図４】
2009211373.tif 000006
【図５】
2009211373.tif 000007
【図６】
2009211373.tif 000008
【図７】
2009211373.tif 000009