特開 2023-176141 サーバ装置及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023176141

(43)【公開日】2023-12-13

(54)【発明の名称】サーバ装置及びプログラム

(51)【国際特許分類】

   G16H 80/00 20180101AFI20231206BHJP

【ＦＩ】

G16H80/00

【審査請求】未請求

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2022088264

(22)【出願日】2022-05-31

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡ

(71)【出願人】

【識別番号】519135633

【氏名又は名称】公立大学法人大阪

(71)【出願人】

【識別番号】308038613

【氏名又は名称】公立大学法人和歌山県立医科大学

(74)【代理人】

【識別番号】110002273

【氏名又は名称】弁理士法人インターブレイン

(72)【発明者】

【氏名】幕内 陽介

(72)【発明者】

【氏名】岡村 浩史

(72)【発明者】

【氏名】梅本 由香里

(72)【発明者】

【氏名】西川 彰則

【テーマコード（参考）】

5L099

【Ｆターム（参考）】

5L099AA01

(57)【要約】      （修正有）

【課題】医療を受ける対象者と医療側の担当者の間の情報伝達を簡便にするサーバ装置及びプログラムを提供する。
【解決手段】健康観察システムにおいて、複数のドナーと複数の医療者との間の情報伝達を支援する情報処理装置であるサーバ装置３００は、臓器、組織又は細胞を提供する複数のドナーの各々と、医療側の担当者とを対応付けて記憶する担当情報記憶部３４６と、複数のドナーのうちの何れかのドナーの端末から当該ドナーの体調報告を受信するドナーインターフェース部３１２の受信部３１４と、ドナーに対応付けて体調報告を記憶する体調報告記憶部３４８と、ドナーに対応する医療者の端末へ体調報告を送信する医療者インターフェース部３１３の送信部３１７と、を備える。
【選択図】図５

【特許請求の範囲】

【請求項1】

臓器、組織又は細胞を提供する複数のドナーの各々と、医療側の担当者とを対応付けて記憶する第１記憶部と、
前記複数のドナーのうちのいずれかのドナーの端末から当該ドナーの体調報告を受信する受信部と、
前記ドナーに対応付けて前記体調報告を記憶する第２記憶部と、
前記ドナーに対応する前記担当者の端末へ前記体調報告を送信する第１送信部と、を備えることを特徴とするサーバ装置。

【請求項2】

前記ドナーが前記臓器、前記組織又は前記細胞の採取前である場合に、第１体調報告を入力するための第１入力画面のデータを前記ドナーの前記端末へ送信し、前記ドナーが前記臓器、前記組織又は前記細胞の採取後である場合に、前記第１体調報告と項目構成が異なる第２体調報告を入力するための第２入力画面のデータを前記ドナーの前記端末へ送信する第２送信部、を更に備え、
前記受信部は、前記第１体調報告又は前記第２体調報告を受信することを特徴とする請求項１に記載のサーバ装置。

【請求項3】

身体のいずれかにおける痛みの有無を入力するための第３入力画面のデータと、当該第３入力画面において前記痛みが有る旨を入力された場合にのみ前記痛みが有る部位を特定するための操作を受け付ける第４入力画面のデータとを、前記ドナーの前記端末へ送信する第２送信部、を更に備えることを特徴とする請求項１に記載のサーバ装置。

【請求項4】

前記第４入力画面は、複数の候補部位に対して前記痛みの有無の入力が可能であって、前記有無が入力されていない１つ以上の前記候補部位に対して前記痛みが無い旨を一括して設定する手段を備えることを特徴とする請求項３に記載のサーバ装置。

【請求項5】

前記第１送信部は、前記担当者が担当する前記ドナーのリストと、時系列で示された複数回の前記体調報告のサマリーとを表示する表示画面のデータを、前記担当者の前記端末へ送信することを特徴とする請求項１に記載のサーバ装置。

【請求項6】

前記受信部が前記体調報告を受信したときに、前記担当者の前記端末へ前記体調報告の着信があった旨を通知する通知部を備えることを特徴とする請求項１に記載のサーバ装置。

【請求項7】

前記第１送信部が前記体調報告を前記担当者の前記端末へ送信したときに、前記ドナーの前記端末へ前記体調報告の伝達が済んだ旨を通知する通知部を備えることを特徴とする請求項１に記載のサーバ装置。

【請求項8】

所定時間までに前記受信部が前記体調報告を受信しなかったときに、前記ドナーの前記端末と前記担当者の前記端末へアラートを通知する通知部を備えることを特徴とする請求項１に記載のサーバ装置。

【請求項9】

臓器、組織又は細胞を提供するドナーが使用する端末に、
前記ドナーが前記臓器、前記組織又は前記細胞の採取前である場合に、第１体調報告を入力するための第１入力画面を表示し、前記ドナーが前記臓器、前記組織又は前記細胞の採取後である場合に、前記第１体調報告と項目構成が異なる第２体調報告を入力するための第２入力画面を表示する表示機能と、
前記第１入力画面において前記第１体調報告の入力を受け付け、あるいは前記第２入力画面において前記第２体調報告の入力を受け付ける受付機能と、
前記第１体調報告又は前記第２体調報告を、サーバ装置へ送信する送信機能と、を発揮させることを特徴とするプログラム。

【請求項10】

医療を受ける対象者と医療側の担当者との間における情報伝達を支援するサーバ装置であって、
前記対象者の状況報告を入力するための入力画面のデータを生成する生成部と、
前記入力画面の前記データを前記対象者の端末へ送信する第１送信部と、
前記対象者の前記端末から、前記入力画面において入力された前記状況報告を受信する受信部と、
前記対象者に対応付けて前記状況報告を記録する記録部と、
前記担当者の端末へ前記状況報告を送信する第２送信部と、
前記対象者に関する所定イベントの発生情報を取得する取得部と、
を備え、
前記生成部は、前記所定イベントが生じたことを契機として、前記入力画面において入力される前記状況報告の項目を切り替えることを特徴とするサーバ装置。

【請求項11】

医療を受ける対象者が使用する端末に、
前記対象者の状況報告を入力するための入力画面を表示する表示機能と、
前記入力画面において前記状況報告の入力を受け付ける受付機能と、
前記入力画面において入力された前記状況報告をサーバ装置へ送信する送信機能と、
前記対象者に関する所定イベントの発生情報を取得する取得機能と、を発揮させ、
前記表示機能において、前記所定イベントが生じたことを契機として、前記入力画面において入力される前記状況報告の項目を切り替えることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、医療に関わる情報伝達を支援する技術に関する。

【背景技術】

【0002】

医療行為として、健康な人から採取された臓器、組織又は細胞を患者に移植する生体移植が行われることがある。臓器、組織又は細胞の提供者を「ドナー」という。ドナーの安全のために、臓器、組織又は細胞の採取の前後においてドナーの健康管理を行う必要がある。主に採取担当の医師がドナーの健康管理を行い、医療専門職である移植コーディネーター（以下、単に「コーディネーター」という。）がそれをサポートする。

【0003】

具体的には、医師がドナーを診察し、医薬品の使用による副作用などがあれば適切に処置する。コーディネーターは、医師が診察しないときに、電話でドナーと連絡を取って健康チェックを行う。健康チェックでは、コーディネーターがドナーの体調を聞き取り、異常が無いか確認する。異常があれば、コーディネーターはドナーに受診を勧める。このように、コーディネーターによる健康チェックは、ドナーの安全確保のために重要な役割を果たす。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００７－０４４４４２号公報

【特許文献2】特開２００２－０５６０９９号公報

【特許文献3】特開平１１－０４５３０４号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかし、健康チェックのための電話連絡は、ドナーとコーディネーターの両者にとって負担が大きい。ドナーは、たとえば就業時間中に通話できない。コーディネーターは、たとえば他の業務中に通話できない。予め通話時間を調整するとしても、それぞれの都合を合わせることは容易でない。コーディネーターは、他のドナーの電話連絡と時間が重複しないように、予定を割り振る必要がある。予定通りに電話をかけても、着信側が通話中であれば、再びかけ直さなければならない。また、健康チェックの所定項目は多数あり、それらを漏れなく聞き取るためには時間を要する。コーディネーターが判断して応答する時間を含めると、ドナー一人当たりの通話時間は長くなる。

【0006】

特許文献１は、採血におけるドナーの安全に関する。採血による副反応を防ぐために、採血を開始する前に、ドナーの心拍などを計測して自律神経の活動状態を評価する。自律神経の活動状態が不安定であれば、採血を中止する。この対応は、院内の事前検査だけで済むので、ドナーと医療者のコミュニケーションは特に問題にならない。

【0007】

特許文献２は、生活習慣病などを念頭にユーザの自己管理をサポートする技術を開示する。ユーザ端末に接続されたバイタルセンサーで計測されたユーザの生体データをサーバへ送り、サーバが健康度を求め、それをユーザへ送り返す。この技術は、ユーザ端末とサーバの間の情報伝達がメインであり、医療者がユーザとコミュニケーションをとることはない。

【0008】

特許文献３は、複数の医療機関で作成された医療データを集中管理し、各医療機関がネットワークを介して医療データを利用するシステムを提案している。一般利用者に対しても医療データを提供するようになっているが、患者と医療者のコミュケーションを目的とした仕組みではない。

【0009】

本発明はこのような課題に鑑みてなされたものであり、その目的の一つは、医療を受ける対象者と医療側の担当者の間の情報伝達を簡便にすることにある。

【課題を解決するための手段】

【0010】

本発明のある態様のサーバ装置は、臓器、組織又は細胞を提供する複数のドナーの各々と、医療側の担当者とを対応付けて記憶する第１記憶部と、複数のドナーのうちのいずれかのドナーの端末から当該ドナーの体調報告を受信する受信部と、ドナーに対応付けて体調報告を記憶する第２記憶部と、ドナーに対応する担当者の端末へ体調報告を送信する第１送信部と、を備える。

【0011】

本発明のある態様のプログラムは、臓器、組織又は細胞を提供するドナーが使用する端末に、ドナーが臓器、組織又は細胞の採取前である場合に、第１体調報告を入力するための第１入力画面を表示し、ドナーが臓器、組織又は細胞の採取後である場合に、第１体調報告と項目構成が異なる第２体調報告を入力するための第２入力画面を表示する表示機能と、第１入力画面において第１体調報告の入力を受け付け、あるいは第２入力画面において第２体調報告の入力を受け付ける受付機能と、第１体調報告又は第２体調報告を、サーバ装置へ送信する送信機能と、を発揮させる。

【0012】

本発明の別の態様のサーバ装置は、医療を受ける対象者と医療側の担当者との間における情報伝達を支援するサーバ装置であって、対象者の状況報告を入力するための入力画面のデータを生成する生成部と、入力画面のデータを対象者の端末へ送信する第１送信部と、対象者の端末から、入力画面において入力された状況報告を受信する受信部と、対象者に対応付けて状況報告を記録する記録部と、担当者の端末へ状況報告を送信する第２送信部と、対象者に関する所定イベントの発生情報を取得する取得部と、を備え、生成部は、所定イベントが生じたことを契機として、入力画面において入力される状況報告の項目を切り替える。

【0013】

本発明の別の態様のプログラムは、医療を受ける対象者が使用する端末に、対象者の状況報告を入力するための入力画面を表示する表示機能と、入力画面において状況報告の入力を受け付ける受付機能と、入力画面において入力された状況報告をサーバ装置へ送信する送信機能と、対象者に関する所定イベントの発生情報を取得する取得機能と、を発揮させ、表示機能において、所定イベントが生じたことを契機として、入力画面において入力される状況報告の項目を切り替える。

【発明の効果】

【0014】

本発明によれば、医療を受ける対象者と医療側の担当者の間の情報伝達を簡便にする技術を提供できる。

【図面の簡単な説明】

【0015】

【図1】図１（Ａ）は、従来の採取スケジュールの例を示す図である。図１（Ｂ）は、今後予想される採取スケジュールの例を示す図である。

【図2】健康観察システムのネットワーク構成図である。

【図3】ドナー端末の表示画面の遷移図である。

【図4】ドナー端末の表示画面の遷移図である。

【図5】サーバ装置の機能ブロック図である。

【図6】Ｗｅｂ（World Wide Web）アプリ方式によるドナーサービスのシーケンス図である。

【図7】Ｗｅｂアプリ方式によるドナーサービスのシーケンス図である。

【図8】医療者端末における表示画面の遷移図である。

【図9】Ｗｅｂアプリ方式による医療者サービスのシーケンス図である。

【図10】Ｗｅｂアプリ方式による医療者サービスのシーケンス図である。

【図11】変形例１におけるドナー端末の機能ブロック図である。

【図12】ネイティブアプリ方式によるドナーサービスのシーケンス図である。

【図13】変形例２における医療者端末の機能ブロック図である。

【図14】ネイティブアプリ方式による医療者サービスのシーケンス図である。

【発明を実施するための形態】

【0016】

以下、本発明の実施形態を、図面を参照して詳細に説明する。
まず、生体移植について説明する。生体移植とは、健康な人から提供された臓器、組織又は細胞を患者に移植することである。移植される臓器は、たとえば腎臓、肝臓および骨髄である。移植される組織は、たとえば角膜、皮膚、心臓弁及び血管である。移植される細胞は、たとえば造血幹細胞である。造血幹細胞は、末梢血、骨髄又は臍帯血から得られる。また輸血も、液体の臓器である血液を入れる臓器移植の一種と言える。

【0017】

生体移植では、臓器、組織又は細胞の提供者であるドナーの安全に十分配慮する必要がある。ドナーの安全を担保することによって、生体移植が促進されるという面もある。以下では、造血幹細胞移植のための末梢血幹細胞採取（ＰＢ採取）を例としてドナーに対する処置と健康管理について説明する。

【0018】

造血幹細胞移植は、白血病に対する治療法として、患者の体内で正常な血液を作るため、ドナーから正常な血液を作る能力を移す処置である。末梢血幹細胞採取は、ドナーから造血幹細胞を採取する方法の一つである。

【0019】

図１（Ａ）は、従来の採取スケジュールの例を示す図である。
図示した例で、ドナーは、採取日の５日前に通院し健康診断を受ける。その後も通院が続き、ドナーに対して連日注射によるＧ－ＣＳＦ（顆粒球コロニー刺激因子）製剤の投与が行われる。

【0020】

Ｇ－ＣＳＦ製剤には、白血球を増加させるとともに、体を流れる血液の中に含まれる造血幹細胞を増やす効果がある。Ｇ－ＣＳＦ製剤の投与によって、移植に必要な程度量の造血幹細胞を末梢血から採取することが可能になる。白血球数が増え過ぎる場合には、投与する製剤の量を減らすなどの調整が行われる。

【0021】

Ｇ－ＣＳＦ製剤には、筋・骨格系症状、皮膚症状及び肝機能障害などの合併症がある。稀に、呼吸器症状、ショック、及びアナフィラキシーも生じる。そのため副作用として、骨の痛み、発熱、頭痛、倦怠感、不眠、食欲不振、及び吐き気などの体調不良が生じることがある。痛みの処置としては、痛み止め薬を使用できる。合併症の診断は、製剤の投与のための外来診療において合わせて行われる。

【0022】

順調に推移すれば、前日に入院して採取日に成分分離装置を用いて造血幹細胞の採取が行われる。成分分離によって、必要な成分だけが抽出される。常に医療スタッフが待機し体調管理を行いながら、１回に３～４時間かけて採取が行われる。また、採取は、２日に分けて行われることもある。一般的には、採取が終了した日の翌日に、ドナーは退院する。

【0023】

Ｇ－ＣＳＦ製剤の投与を受けて１週間ぐらいの間は、白血球数が多く、血栓症を起こしやすいので生活に配慮が必要となる。採取後に、一過性に脾臓が腫れることがあるが、大きな合併症は認められていない。そのため、週に１回程度の頻度でコーディネーターが電話連絡で健康チェックを行う。もしも異常があれば、コーディネーターは受診を勧める。

【0024】

採取後１４日目頃に健康診断が行われ、採取に関連する合併症及び副作用がなければ終診となる。このように、コーディネーターの電話連絡と医師の外来診察によってフォローアップが行われる。

【0025】

今後の見通しとしては、近日中に持続型のＧ－ＣＳＦ製剤の末梢血幹細胞採取への適応追加が予定されている。持続型のＧ－ＣＳＦ製剤を使用する場合には、採取スケジュールが少し変わる。

【0026】

図１（Ｂ）は、今後予想される採取スケジュールの例を示す図である。
持続型のＧ－ＣＳＦ製剤は、１回の投与で十分な効果が得られる。したがって、一度投与された後、ドナーは入院するまで投与のための通院をしなくて済むようになる。

【0027】

但し、持続型のＧ－ＣＳＦ製剤は、従来使用されているＧ－ＣＳＦ製剤よりも合併症について配慮が必要であると考えられている。そのため、採取日を挟み少なくとも２週間程度は、健康状態の評価を毎日行った方がよい。ドナーの日常的な負担を考慮すると、毎日通院することは困難なので、コーディネーターが電話連絡による健康チェックを行うことになると予想される。

【0028】

また、日本造血・免疫細胞療法学会の方針を踏まえれば、末梢血幹細胞採取の件数が増えていくことが予想される。

【0029】

現状では、遠隔で健康チェックを行う手段として電話連絡を行っているが、上述のように電話連絡は不便な面が多い。そこで、ＩＣＴ（Information and Communication Technology）技術を利用した健康観察システムを提案する。

【0030】

ＩＣＴ技術を利用すれば、ドナーは任意のタイミングでスマートフォン又はＰＣ（パーソナルコンピュータ）などから体調を報告できる。一方、医師又はコーディネーターも任意のタイミングでスマートフォン又はＰＣなどでそれを閲覧できる。そのため、コーディネーターが、重複しないように通話の予定を組んだり、電話をかけ直したりといった不便が解消される。ドナーにとっても、手軽で便利である。これにより、医療とコーディネートの体制を効率化することができる。そして、将来的な移植件数の増加に対して業務の混乱をきたすことなく安全に対応できる準備が整うと期待される。

【0031】

図２は、健康観察システムのネットワーク構成図である。
健康観察システムは、ドナー端末１００ａ～ｃなど、医療者端末２００ａ～ｃなど、及びサーバ装置３００を含む。

【0032】

ドナー端末１００ａ～ｃなどは、造血幹細胞（以下、単に「細胞」ということがある。）を提供するドナーが使用する端末である。ドナー端末１００ａ～ｃなどをまとめて言うときや特に区別しないときには「ドナー端末１００」と総称する。医療者端末２００ａ～ｃなどは、ドナーの健康を観察する医療者が使用する端末である。医療者端末２００ａ～ｃなどをまとめて言うときや特に区別しないときには「医療者端末２００」と総称する。以下では、医療者が医師であるものと想定して説明する。但し、医療者をコーディネーターとしてもよい。コーディネーターの場合には、診断や治療など医師のみに認められている行為は行わないものとする。医師及びコーディネーターなど医療の観点から所定のドナーに接する者は、「医療側の担当者」である。例示する医療者端末２００は、「医療側の担当者の端末」に該当する。

【0033】

以下では、ドナー端末１００と医療者端末２００がスマートフォンであるものとして説明する。但し、ドナー端末１００と医療者端末２００は、タブレット端末やＰＣなどでもよい。

【0034】

ドナー端末１００は、ブラウザ１０２とメーラー１０４を有し、医療者端末２００は、ブラウザ２０２とメーラー２０４を有する。ブラウザ１０２とブラウザ２０２は、Ｗｅｂページの表示とユーザ操作に使用される一般的なソフトウェアである。メーラー１０４とメーラー２０４は、電子メールの送受信および編集を行う際に使用される一般的なソフトウェアである。また、ドナー端末１００と医療者端末２００は、インターネットに接続して通信を行う通信機能を備えている。

【0035】

サーバ装置３００は、ドナーと医療者の間の情報伝達を支援する情報処理装置である。サーバ装置３００は、インターネットと接続している。ドナー端末１００からサーバ装置３００へアクセスされたときに、サーバ装置３００はドナー向けのサービス（以下、「ドナーサービス」という。）を提供する。また、医療者端末２００からサーバ装置３００へアクセスされたときに、サーバ装置３００は医療者向けのサービス（以下、「医療者サービス」という。）を提供する。ドナーサービスは、ドナーへ情報を提供し、ドナーからの情報登録を受け付けるサービスである。医療者サービスは、医療者へ情報を提供し、医療者からの情報登録を受け付けるサービスである。ドナーサービスと医療者サービスによって、両者のコミュニケーションが図られる。続いて、ドナー端末１００に表示される画面の例を示して、ドナーサービスについて詳述する。

【0036】

図３と図４は、ドナー端末１００の表示画面の遷移図である。
これらの図は、ドナーが、ドナー端末１００を用いて、体調を報告するときに表示される画面を示している。ドナー端末１００のディスプレイに表示されるログイン画面４００は、メールアドレスエリア４０２、パスワードエリア４０４およびログインボタン４０６を含む。ドナーは、メールアドレスエリア４０２に自らのメールアドレスを入力し、パスワードエリア４０４にパスワードを入力する。そして、ドナーは、ログインボタン４０６にタッチし、サーバ装置３００へのログインを要求する。

【0037】

ドナーのログインが成功すると、ドナー端末１００のディスプレイに経過画面４１０が表示される。経過画面４１０には、これまでの経過情報が表示される。各日付に対応して、経過日数、報告状況、体温、痛みの有無、痛み止め薬の使用の有無が表示される。採取前の場合、経過日数として採取開始日の何日前であるか表示される。細胞採取後の場合、経過日数として採取開始日から何日後であるか表示される。採取開始日は、造血幹細胞を最初に採取した日（採取前は、最初に採取する予定の日）である。造血幹細胞の採取は、複数日に渡る場合がある。体調報告を既に行っていれば、報告状況として「済」と示した報告済ボタン４１２が表示され、体調報告を未だ行っていなければ、報告状況として「未」と示した未報告ボタン４１４が表示される。この例では、昨日（４月１日）に体調報告が行われ、今日（４月２日）については未だ体調報告を行われていない。体温、痛みの有無および痛み止め薬の使用の有無は、体調報告の一部（サマリー）である。ドナーは、経過画面４１０を左スクロールすることによって、これより前の経過情報を見ることができる。

【0038】

ドナーが報告済ボタン４１２にタッチすると、入力済みの体調報告の全体が表示される（不図示）。一方、ドナーが未報告ボタン４１４にタッチすると、体調報告を入力するための画面が表示される。報告する体調の項目は、細胞の提供を行う前と後とで異なる。

【0039】

細胞を採取する前の段階であれば、採取前の標準入力画面４２０が表示される。採取前の標準入力画面４２０には、身体のいずれかにおける痛みの有無を問うメッセージが表示され、痛みの有無の入力が促される。どこも痛くない場合には、ドナーは、痛み無いボタン４２２をタッチする。そして、ドナーが次へボタン４２８をタッチすると、痛みに関する入力は終わる。この場合、すべての部位に関して痛みが無いことになる。戻るボタン４２６がタッチされた場合には、痛みに関する入力は取り消され、経過画面４１０の表示へ戻る。標準入力画面は、痛みが有る部位を特定するための操作を受け付けない画面である。

【0040】

どこかが痛い場合には、ドナーは、痛み有るボタン４２４をタッチする。痛み有るボタン４２４がタッチされると、採取前の拡張入力画面４３０の表示へ切り替わる。拡張入力画面は、痛みが有る部位を特定するための操作を受け付ける画面である。この例では、痛みが感じられる候補となる各部位（以下、「候補部位」という。）対応するプルダウンメニュー４３２ａ～ｃなどが設けられている。プルダウンメニュー４３２ａ～ｃなどをまとめて言うときや特に区別しないときには「プルダウンメニュー４３２」と総称する。プルダウンメニュー４３２において、痛みに関して「無い」、「軽度」又は「重度」を選択することができる。痛みの程度を区別せずに、「無い」又は「有る」だけを選択するようにしてもよい。たとえば、胸部にのみ軽い痛みを感じている場合に、ドナーは胸部に対応するプルダウンメニュー４３２ｃにおいて「軽度」を選択する。痛みが無い候補部位に関して、ドナーはプルダウンメニュー４３２ａ，ｂなどで「無い」を選択する。「未入力を『無い』とする」と表示されたチェックボックス４３４をＯＮにした場合には、未入力の候補部位に関して「無い」を一括設定することができる。これにより、痛みが無い候補部位に対してプルダウンメニュー４３２の操作を行う煩わしさが解消される。次へボタン４２８と戻るボタン４２６の操作については、採取前の標準入力画面４２０の場合と同様である。なお、採取前の標準入力画面４２０と採取前の拡張入力画面４３０は、「第１体調報告を入力するための第１入力画面」の例である。

【0041】

図４の説明に移る。細胞を採取した後の段階であれば、採取後の標準入力画面４４０が表示される。細胞を採取した後では、痛みが生じた場合にドナー自身の判断で、痛め止め薬を服用できる。また、痛みが激しいために通学・通勤ができないことも想定される。そのため、採取後の標準入力画面４４０には、採取前の標準入力画面４２０と同じ入力項目の他に、痛め止め薬の使用および通学・通勤の状況に関する入力項目が含まれる。

【0042】

ドナーは、痛め止め薬の使用に関して、使用無いボタン４４２、Ａ薬ボタン４４４、Ｂ薬ボタン４４６およびその他ボタン４４８のいずれかを選択する。ドナーが痛め止め薬を服用していない場合には、使用無いボタン４４２が選択される。痛め止めのＡ薬を服用している場合には、Ａ薬ボタン４４４が選択され、痛め止めのＢ薬を服用している場合には、Ｂ薬ボタン４４６が選択される。その他の痛め止め薬を服用している場合には、その他ボタン４４８が選択される。この例では示していないが、その他ボタン４４８が選択された場合に、その他の痛め止め薬の名称を入力できるようにしてもよい。

【0043】

また、ドナーは、通学・通勤に関して、可能ボタン４５０又は不可能ボタン４５２を選択する。体調面で通学あるいは通勤に支障がある場合には、ドナーは、不可能ボタン４５２を選択し、支障がない場合には可能ボタン４５０を選択する。この例では示していないが、通学あるいは通勤の機会が無い場合に選択される機会無しボタンを設けるようにしてもよい。

【0044】

どこも痛くない場合には、ドナーは痛み無いボタン４２２を選択し、更に、痛め止め薬の使用と通学・通勤に関する入力操作を行う。これらの入力結果が、体調報告に含められる。

【0045】

一方、ドナーが痛み有るボタン４２４を選択した場合には、採取後の拡張入力画面４６０の表示へ切り替わる。採取後の拡張入力画面４６０には、痛みが有る部位に関する入力手段が含まれる。この入力手段は、採取前の拡張入力画面４３０（図３）の場合と同様である。ドナーは、痛みが有る部位に関して入力操作を行い、更に、下スクロールによって痛め止め薬の使用および通学・通勤の項目を表示させてこれらに関する入力操作を行う。

【0046】

痛みに関する入力に続いて、体温などのバイタルサインおよびその他の症状などの項目も体調報告として入力することができるようになっている。これらの入力画面については省略する。すべての項目が入力されると、入力された体調報告がサーバ装置３００に登録される。なお、採取後の標準入力画面４４０と採取後の拡張入力画面４６０は、「第１体調報告と項目構成が異なる第２体調報告を入力するための第２入力画面」の例である。

【0047】

本実施形態では、ドナーサービスがＷｅｂアプリ方式によって実装されているものとして説明する。Ｗｅｂアプリ方式では、ドナー端末１００のブラウザ１０２が、サーバ装置３００からＷｅｂページデータを取得して、Ｗｅｂページデータに基づいて上述の画面（Ｗｅｂページ）を表示する。また、Ｗｅｂページにおける動作の一部は、Ｗｅｂページデータに含まれるスクリプト（たとえば、ｊａｖａスクリプト）に記述されており、ブラウザ１０２がこの記述を参照して表示処理や入力操作を制御することもある。Ｗｅｂページデータは、画面のデータの例である。以下、ドナーサービスの処理の詳細について説明する。

【0048】

健康観察システムに含まれるドナー端末１００、医療者端末２００およびサーバ装置３００の各構成要素は、ＣＰＵ（Central Processing Unit）および各種コプロセッサなどの演算器、メモリやストレージといった記憶装置、それらを連結する有線又は無線の通信線を含むハードウェアと、記憶装置に格納され、演算器に処理命令を供給するソフトウェアによって実現される。コンピュータプログラムは、デバイスドライバ、オペレーティングシステム、それらの上位層に位置する各種アプリケーションプログラム、また、これらのプログラムに共通機能を提供するライブラリによって構成されてもよい。以下に説明する各ブロックは、ハードウェア単位の構成ではなく、機能単位のブロックを示している。

【0049】

図５は、サーバ装置３００の機能ブロック図である。
サーバ装置３００は、通信部３１０、データ処理部３２０およびデータ格納部３４０を含む。
通信部３１０は、インターネットを介してドナー端末１００および医療者端末２００などとの通信処理を担当する。データ格納部３４０は各種データを格納する。データ処理部３２０は、通信部３１０により取得されたデータと、データ格納部３４０に格納されているデータに基づいて各種処理を実行する。データ処理部３２０は、通信部３１０およびデータ格納部３４０のインターフェースとしても機能する。

【0050】

通信部３１０は、ドナー端末１００との通信処理を担うドナーインターフェース部３１２と医療者端末２００との通信処理を担う医療者インターフェース部３１３とを含む。

【0051】

ドナーインターフェース部３１２は、ドナー端末１００からデータを受信する受信部３１４と、ドナー端末１００へデータを送信する送信部３１６とを含む。受信部３１４は、ドナーサービス用のＵＲＬ（Uniform Resource Locator）によってドナー端末１００からのアクセスを受け付ける。受信部３１４がドナー端末１００のブラウザ１０２からＨＴＴＰ（Hypertext Transfer Protocol）リクエストを受信し、送信部３１６は、ＨＴＴＰレスポンスとしてＷｅｂページデータをドナー端末１００へ送信する。このＷｅｂページデータによって表示されるＷｅｂページは、図３と図４に関連して説明した各種画面に相当する。Ｗｅｂページは、ドナー端末１００のブラウザ１０２によって表示される。Ｗｅｂページデータは、画面のデータの例である。

【0052】

同様に、医療者インターフェース部３１３は、医療者端末２００からデータを受信する受信部３１５と、医療者端末２００へデータを送信する送信部３１７とを含む。受信部３１５は、医療者サービス用のＵＲＬによって医療者端末２００からのアクセスを受け付ける。受信部３１５が医療者端末２００のブラウザ２０２からＨＴＴＰリクエストを受信し、送信部３１７は、ＨＴＴＰレスポンスとしてＷｅｂページデータを医療者端末２００へ送信する。このＷｅｂページデータによって表示されるＷｅｂページは、図８に関連して後述する各種画面に相当する。Ｗｅｂページは、医療者端末２００のブラウザ２０２によって表示される。

【0053】

データ処理部３２０は、認証部３２２、画面生成部３２４、記録部３２６および通知部３２８を含む。
認証部３２２は、アカウント情報を用いてドナーおよび医療者を認証する。画面生成部３２４は、ドナー端末１００および医療者端末２００において表示される各種画面のデータ（Ｗｅｂページデータ）を生成する。記録部３２６は、ドナーから送られた体調報告および医療者から送られた診断データを記録する。通知部３２８は、ドナー端末１００および医療者端末２００へ通知を送る。通知の方法は、ドナーインターフェース部３１２および医療者インターフェース部３１３によるメッセージの送信でもよいし、電子メール、ＳＮＳ（Social Networking Service）のメッセージ機能あるいはプッシュ通知など公知技術を用いてもよい。

【0054】

データ格納部３４０は、アカウント情報記憶部３４２、ドナー情報記憶部３４４、担当情報記憶部３４６、体調報告記憶部３４８および診断データ記憶部３５０を含む。

【0055】

アカウント情報記憶部３４２は、ドナーと医療者のアカウント情報を記憶する。この例におけるアカウント情報は、メールアドレスとパスワードの組み合わせである。アカウント情報は、ユーザＩＤとパスワードの組み合わせ、あるいはユーザ名とパスワードの組み合わせなどであってもよい。

【0056】

ドナー情報記憶部３４４は、ドナー情報を記憶する。ドナー情報には、個人情報、Ｇ－ＣＳＦ情報、採取開始日およびフォロー終了日などが含まれる。個人情報は、たとえば氏名、メールアドレスおよび電話番号を含む。Ｇ－ＣＳＦ情報は、Ｇ－ＣＳＦ製剤の投与に関する情報であって、投与開始日およびＧ－ＣＳＦ製剤の種類などを含む。投与開始日は、最初にＧ－ＣＳＦ製剤を投与した日である。

【0057】

担当情報記憶部３４６は、各ドナーを担当する医療者を記憶する。担当情報によってドナーと医療者との対応付けが可能であって、更にドナー端末１００と医療者端末２００との対応関係も特定できる。医療者の氏名とメールアドレスなどの医療者情報も、データ格納部３４０に記憶されているものとする。

【0058】

体調報告記憶部３４８は、ドナー毎に報告日時に対応付けられた体調報告を記憶する。体調報告には、たとえば痛み症状、その他の症状およびバイタルサインが含まれる。痛み症状として、各候補部位の痛みに関する「無い」、「軽度」又は「重度」の別が設定される。候補部位は、頭部、首・喉、胸部、背中、腹部、腰部・臀部、腕、足および関節などである。細胞を採取した後の段階では、更に痛み止め薬の使用および通学・通勤の情報が、痛み症状に加わる。その他の症状として、発熱、疲労感、睡眠の問題、めまい、食欲不振、吐き気、嘔吐、かゆみ、皮膚の変化、下痢、注射部位の反応、味覚異常、息苦しさおよび咳などの有無が設定される。細胞を採取した後の段階で、更に穿刺部位の異常に関する「無い」、「熱感」、「腫れ」又は「痛み」の別が設定されるようにしてもよい。バイタルサインは、たとえば脈拍、酸素飽和度、体温および血圧である。酸素飽和度は、ドナーに貸し出されたパルスオキシメータで計測される。

【0059】

診断データ記憶部３５０は、ドナー毎に診断日時に対応付けられた診断データを記憶する。診断データは、たとえば脾腫の情報、製剤減量・中止の情報および採取の情報を含む。脾腫とは、脾臓がはれてふくらんだ状態である。脾腫の情報には、脾腫の有無、脾腫の測定方法および測定値が含まれる。脾腫の測定方法は、「触診」又は「エコー」である。製剤減量・中止の情報には、Ｇ－ＣＳＦ製剤に関する「減量無し」、「減量５０％」、「中止」又は「投与なし」の別と、それらの理由が設定される。持続型のＧ－ＣＳＦ製剤を使用する場合には、連日投与する必要はないので「投与なし」と設定されることがある。採取の情報には、「未採取」又は「採取済み」が設定される。予定通り採取された場合には、採取開始日以降において「採取済み」が設定される。

【0060】

図６と図７は、Ｗｅｂアプリ方式によるドナーサービスのシーケンス図である。
ドナーインターフェース部３１２の受信部３１４がドナー端末１００からのアクセスを受信すると（Ｓ６００）、送信部３１６は、図３に示したログイン画面４００のデータ（Ｗｅｂページデータ）をドナー端末１００へ送信する（Ｓ６０２）。

【0061】

ドナー端末１００がログイン画面４００のデータを受信すると、ブラウザ１０２は、ログイン画面４００を表示する（Ｓ６０４）。ブラウザ１０２はアカウント情報の入力を受け付け（Ｓ６０６）、ドナー端末１００はアカウント情報をサーバ装置３００へ送信する（Ｓ６０８）。

【0062】

ドナーインターフェース部３１２の受信部３１４がアカウント情報を受信すると、認証部３２２は、ドナーを認証する（Ｓ６１０）。受信したアカウント情報がアカウント情報記憶部３４２に記憶されているドナーのアカウント情報と一致すると、ドナー認証が成功する。ドナー認証が成功すると、画面生成部３２４は、ドナー情報記憶部３４４と体調報告記憶部３４８などを参照して、図３に示した経過画面４１０のデータを生成する（Ｓ６１２）。送信部３１６は、経過画面４１０のデータをドナー端末１００へ送信する（Ｓ６１４）。

【0063】

ドナー端末１００が経過画面４１０のデータを受信すると、ブラウザ１０２は、経過画面４１０を表示する（Ｓ６１６）。ブラウザ１０２が未報告ボタン４１４のタッチを受け付けると（Ｓ６１８）、ドナー端末１００は、未報告ボタン４１４のイベントをサーバ装置３００へ送信する（Ｓ６２０）。未報告ボタン４１４のイベントは、標準入力画面の要求に相当する。

【0064】

ドナーインターフェース部３１２の受信部３１４が未報告ボタン４１４のイベントを受信すると、送信部３１６は、診断データ記憶部３５０又はドナー情報記憶部３４４などを参照して、細胞の採取前か採取後かを判定する（Ｓ６２２）。採取前と採取後の区別は、診断データに含まれる採取の情報（「未採取」又は「採取済み」）によって判定される。あるいは、送信部３１６は、ドナー情報に含まれる採取開始日によって判定するようにしてもよい。送信部３１６は、細胞の採取前の場合に、図３に示した採取前の標準入力画面４２０のデータをドナー端末１００へ送信し、細胞の採取後の場合に、図４に示した採取後の標準入力画面４４０のデータをドナー端末１００へ送信する（Ｓ６２４）。

【0065】

図７の説明に移る。ドナー端末１００が採取前の標準入力画面４２０又は採取後の標準入力画面４４０のデータを受信すると、ブラウザ１０２は、その標準入力画面を表示する（Ｓ６２６）。ブラウザ１０２が痛み無いボタン４２２のタッチを受け付けた場合には、標準入力画面による処理が継続される。一方、ブラウザ１０２が痛み有るボタン４２４のタッチを受け付けると（Ｓ６２８）、ドナー端末１００は、痛み有るボタン４２４のイベントをサーバ装置３００へ送信する（Ｓ６３０）。痛み有るボタン４２４のイベントは、拡張入力画面の要求に相当する。

【0066】

ドナーインターフェース部３１２の受信部３１４が痛み有るボタン４２４のイベントを受信すると、送信部３１６は、拡張入力画面のデータをドナー端末１００へ送信する（Ｓ６３２）。細胞の採取前の場合には、図３に示した採取前の拡張入力画面４３０のデータが送信され、一方、細胞の採取後の場合には、図４に示した採取後の拡張入力画面４６０のデータが送信される。

【0067】

ドナー端末１００が採取前の拡張入力画面４３０又は採取後の拡張入力画面４６０のデータを受信すると、ブラウザ１０２は、その拡張入力画面を表示する（Ｓ６３４）。

【0068】

ブラウザ１０２は、表示されている各入力画面において体調報告の入力を受け付け（Ｓ６３６）、ドナー端末１００は、入力された体調報告をサーバ装置３００へ送信する（Ｓ６３８）。

【0069】

ドナーインターフェース部３１２の受信部３１４が体調報告を受信すると、記録部３２６は、体調報告を記録する（Ｓ６４０）。具体的には、体調報告記憶部３４８において報告日時に対応付けて体調報告が記憶される。その後、通知部３２８は、体調報告の着信があった旨を医療者端末２００へ通知する（Ｓ６４２）。このとき、通知部３２８は、担当情報記憶部３４６などを参照して、体調報告を送ったドナーを担当する医療者を特定する。そして、通知部３２８は、その医療者の医療者端末２００を通知の送信先とする。通知部３２８は、通知において、たとえば「ドナーの○○○○さんから体調報告が来ました。」のようにドナーの氏名を含むメッセージを送ってもよい。医療者端末２００のブラウザ２０２は、通知を受けると、所定のメッセージ（たとえば、「ドナーから体調報告が来ました。」）あるいは通知されたメッセージを表示し又は音声出力する。ブラウザ２０２は、通知音を出力してもよい。これにより、医療者は、自らが担当するドナーから体調報告があったことをすぐに知ることができる。

【0070】

続いて、医療者端末２００に表示される画面の例を示して、医療者サービスについて詳述する。

【0071】

図８は、医療者端末２００における表示画面の遷移図である。
ドナー端末１００のディスプレイに表示されるログイン画面５００は、メールアドレスエリア５０２、パスワードエリア５０４およびログインボタン５０６を含む。医療者は、メールアドレスエリア５０２に自らのメールアドレスを入力し、パスワードエリア５０４にパスワードを入力する。そして、医療者は、ログインボタン５０６にタッチし、サーバ装置３００へのログインを要求する。

【0072】

医療者のログインが成功すると、医療者端末２００のディスプレイにメイン画面５１０が表示される。メイン画面５１０には、この医療者が担当しているドナーのリストが表示される。図示した「××××」と「○○○○」は、ドナーの氏名を表している。氏名の他に、経過日数も表示される。また、メイン画面５１０には、ドナーの経過情報が含まれる。医療者は、下スクロールによって各ドナーの経過情報を表示させることができる。

【0073】

メイン画面５１０には、既に体調報告が行われたことを示す報告済ボタン５１２と、未だ体調報告が行われていないことを示す未報告ボタン５１４と、既に診断が行われたことを示す診断済ボタン５１６と、未だ診断が行われていないことを示す未診断ボタン５１８とが含まれる。

【0074】

医療者が報告済ボタン５１２にタッチすると、体調報告画面５２０が表示される。体調報告画面５２０には、ドナーによって登録された体調報告の内容が表示される。また、医療者が未報告ボタン５１４にタッチすると、医療者がドナーに代わって体調報告を入力することができる。外来診察又は電話連絡による問診が行われた場合には、医療者がドナーに代わって体調報告を入力してもよい。

【0075】

医療者が診断済ボタン５１６にタッチすると、登録されている診断内容を表示する画面が表示される（不図示）。一方、医療者が未診断ボタン５１８にタッチすると、診断内容を入力する診断画面５３０に移る。なお、体調報告画面５２０には診断ボタン５２２が設けられており、診断ボタン５２２がタッチされた場合にも診断画面５３０に移る。

【0076】

診断画面５３０は、脾腫の有無を入力するための脾腫無いボタン５３２と脾腫有るボタン５３４を含む。更に、脾腫の測定方法を入力するための触診ボタン５３６とエコーボタン５３８、及び脾腫の測定値を入力するための測定値エリア５４０が含まれる。

【0077】

診断画面５３０を下スクロールすることによって、製剤減量・中止の項目が表示される。医療者が製剤を減量しないと判断した場合には、減量無しボタン５４２にタッチする。医療者が製剤を５０％減量すると判断した場合には、減量５０％ボタン５４４にタッチする。医療者が製剤の投与を中止すると判断した場合には、中止ボタン５４６にタッチする。製剤投与の必要がない場合には、投与なしボタン５４８にタッチする。また、製剤減量・中止に関して判断の理由を入力するための理由エリア５５０が設けられている。

【0078】

図示していないが、採取の情報を入力するための未採取ボタンと採取済みボタンも診断画面５３０に含まれる。未だ採取していなければ、医療者は未採取ボタンをタッチし、既に細胞が採取されていれば、採取済みボタンをタッチする。一度採取済みが登録された後は、採取の情報の入力を省いてもよい。このようにして入力された診断内容がサーバ装置３００に登録される。また、医療者は、医療者端末２００からドナー情報をサーバ装置３００に登録することができる。

【0079】

図９と図１０は、Ｗｅｂアプリ方式による医療者サービスのシーケンス図である。
医療者インターフェース部３１３の受信部３１５は、医療者端末２００からのアクセスを受信すると（Ｓ７００）、送信部３１７は、図８に示したログイン画面５００のデータ（Ｗｅｂページデータ）を医療者端末２００へ送信する（Ｓ７０２）。

【0080】

医療者端末２００がログイン画面５００のデータを受信すると、ブラウザ２０２は、ログイン画面５００を表示する（Ｓ７０４）。ブラウザ２０２がアカウント情報の入力を受け付け（Ｓ７０６）、医療者端末２００は、アカウント情報をサーバ装置３００へ送信する（Ｓ７０８）。

【0081】

医療者インターフェース部３１３の受信部３１５がアカウント情報を受信すると、認証部３２２は、医療者を認証する（Ｓ７１０）。受信したアカウント情報がアカウント情報記憶部３４２に記憶されている医療者のアカウント情報と一致すると、医療者認証が成功する。医療者認証が成功すると、画面生成部３２４は、ドナー情報記憶部３４４と担当情報記憶部３４６と体調報告記憶部３４８などを参照して、図８に示したメイン画面５１０のデータを生成する（Ｓ７１２）。送信部３１７は、メイン画面５１０のデータを医療者端末２００へ送信する（Ｓ７１４）。

【0082】

医療者端末２００がメイン画面５１０のデータを受信すると、ブラウザ２０２は、メイン画面５１０を表示する（Ｓ７１６）。ブラウザ２０２が報告済ボタン５１２のタッチを受け付けると（Ｓ７１８）、医療者端末２００は、報告済ボタン５１２のイベントをサーバ装置３００へ送信する（Ｓ７２０）。報告済ボタン５１２のイベントは、体調報告の要求に相当する。

【0083】

医療者インターフェース部３１３の受信部３１５が報告済ボタン５１２のイベントを受信すると、画面生成部３２４は、体調報告記憶部３４８などを参照して、図８に示した体調報告画面５２０のデータを生成する（Ｓ７２２）。送信部３１７は、体調報告画面５２０のデータを医療者端末２００へ送信する（Ｓ７２４）。その後、通知部３２８は、体調報告の伝達が済んだ旨をドナー端末１００へ通知する（Ｓ７２６）。このとき、通知部３２８は、送られた体調報告のドナーを特定し、そのドナーが使用するドナー端末１００を通知の送信先とする。通知部３２８は、通知において、たとえば「医師の△△△△さんが体調報告を見ました。」のように医師の氏名を含むメッセージを送ってもよい。ドナー端末１００のブラウザ１０２は、通知を受けると、所定のメッセージ（たとえば、「医師が体調報告を見ました。」）あるいは通知されたメッセージを表示し又は音声出力する。ブラウザ１０２は、通知音を出力してもよい。これにより、ドナーは、体調報告が担当の医療者に伝えられたことを確認できる。ドナーが体調に不安を感じているときには、きちんと健康管理されていることを知って安心できる。

【0084】

図１０の説明に移る。医療者端末２００が体調報告画面５２０のデータを受信すると、ブラウザ２０２は、体調報告画面５２０を表示する（Ｓ７２８）。ブラウザ２０２が診断ボタン５２２のタッチを受け付けると（Ｓ７３０）、医療者端末２００は、診断ボタン５２２のイベントをサーバ装置３００へ送信する（Ｓ７３２）。診断ボタン５２２のイベントは、診断画面５３０の要求に相当する。

【0085】

医療者インターフェース部３１３の受信部３１５が診断ボタン５２２のイベントを受信すると、送信部３１７は、図８に示した診断画面５３０のデータを医療者端末２００へ送信する（Ｓ７３６）。

【0086】

医療者端末２００が診断画面５３０のデータを受信すると、ブラウザ２０２は、診断画面５３０を表示する（Ｓ７３８）。ブラウザ２０２は、診断データの入力を受け付け（Ｓ７４０）、医療者端末２００は、診断データをサーバ装置３００へ送信する（Ｓ７４２）。

【0087】

医療者インターフェース部３１３の受信部３１５が診断データを受信すると、記録部３２６は、診断データを記録する（Ｓ７４４）。具体的には、診断データ記憶部３５０において診断日時に対応付けて診断データが記憶される。

【0088】

本実施形態によれば、ドナーは任意の時間に体調を報告できる。また、医療者も任意の時間に体調報告を見ることができる。電話連絡による聞き取りのような時間的な制約を受けないので、ドナーも医療者も便利である。

【0089】

更に、所定の入力項目を有する入力画面に対する操作によってドナーの体調が報告されるので、漏れなく必要な情報が伝えられるという面もある。

【0090】

更に、Ｗｅｂアプリ方式の場合にはブラウザ１０２，２０２によって動作可能であるので、ドナー端末１００と医療者端末２００は、専用のアプリケーションプログラムをインストールする必要がなく、簡単に健康観察システムを利用できるというメリットもある。

【0091】

［変形例１］
実施形態では、Ｗｅｂアプリ方式でドナーサービスを提供する例を示したが、ネイティブアプリ方式によってドナーサービスを提供してもよい。ネイティブアプリとは、端末のハードウェア構成（たとえば、ＣＰＵ）やオペレーティングシステムを実行環境として実行されるアプリケーションプログラムである。変形例１では、ドナー端末１００にドナーサービス用のネイティブアプリがインストールされるものとする。

【0092】

ドナー端末１００の表示とユーザ操作の仕様については、ネイティブアプリ方式であっても、図３と図４に関連して説明したＷｅｂアプリ方式の場合と同様である。

【0093】

図１１は、変形例１におけるドナー端末１００の機能ブロック図である。
ドナー端末１００は、ユーザインターフェース処理部１６０、通信部１１０、データ処理部１２０およびデータ格納部１４０を含む。ここでいうユーザは、ドナーを指す。
ユーザインターフェース処理部１６０は、タッチパネルなどの入力デバイスを介してユーザからの操作を受け付けるほか、画像表示や音声出力など、ユーザインターフェースに関する処理を担当する。通信部１１０は、インターネットを介してサーバ装置３００などとの通信処理を担当する。データ格納部１４０は、各種データを格納する。データ処理部１２０は、通信部１１０により取得されたデータ、ユーザインターフェース処理部１６０を介して入力された操作指示およびデータ格納部１４０に格納されているデータに基づいて各種処理を実行する。データ処理部１２０は、通信部１１０、ユーザインターフェース処理部１６０およびデータ格納部１４０のインターフェースとしても機能する。データ格納部１４０は、ネイティブアプリのプログラムや上述したデータなどの各種データを格納する。

【0094】

ユーザインターフェース処理部１６０は、ユーザに対して画像や音声などの各種情報を出力する出力部１６２と、ユーザからの入力を受け付ける入力部１６６とを含む。

【0095】

出力部１６２は、各種画面およびデータをドナー端末１００のディスプレイに表示する表示処理部１６４を含む。入力部１６６は、各種画面におけるユーザ操作を受け付ける受付部１６８を含む。データ処理部１２０は、各種画面を生成する画面生成部１２２を含む。通信部１１０は、データを受信する受信部１１２とデータを送信する送信部１１４を含む。

【0096】

これらの機能ブロックは、ドナーサービス用のネイティブアプリのプログラムをＣＰＵで実行することによって実現される。

【0097】

図１２は、ネイティブアプリ方式によるドナーサービスのシーケンス図である。
ドナー端末１００の表示処理部１６４は、図３に示したログイン画面４００を表示する（Ｓ６５０）。受付部１６８は、アカウント情報の入力を受け付け（Ｓ６５２）、送信部１１４は、アカウント情報をサーバ装置３００へ送信する（Ｓ６５４）。

【0098】

ドナーインターフェース部３１２の受信部３１４がアカウント情報を受信すると、認証部３２２は、ドナーを認証する（Ｓ６５６）。ドナー認証が成功すると、送信部３１６は、認証されたドナーに対応するドナー情報、体調報告及び診断データなどをドナー端末１００へ送信する（Ｓ６５８）。

【0099】

Ｓ６５４で送信されるアカウント情報は、ログインの要求であると共に、ドナー情報、体調報告及び診断データなどの要求に相当する。送信部１１４は、アカウント情報とは別に、ドナー情報、体調報告及び診断データなどの要求をサーバ装置３００へ送信してもよい。

【0100】

ドナー端末１００の受信部１１２が、ドナー情報、体調報告及び診断データなどを受信すると、画面生成部１２２は、受信したデータに基づいて図３に示した経過画面４１０を生成する（Ｓ６６０）。表示処理部１６４は、生成された経過画面４１０を表示する（Ｓ６６２）。受付部１６８が未報告ボタン４１４のタッチを受け付けると（Ｓ６６４）、表示処理部１６４は、診断データ又はドナー情報に基づいて細胞の採取前か採取後かを判定する（Ｓ６６６）。採取前と採取後の区別は、診断データに含まれる採取の情報（「未採取」又は「採取済み」）によって判定される。あるいは、表示処理部１６４は、ドナー情報に含まれる採取開始日によって判定するようにしてもよい。表示処理部１６４は、細胞の採取前の場合に、図３に示した採取前の標準入力画面４２０を表示し、細胞の採取後の場合に、図４に示した採取後の標準入力画面４４０を表示する（Ｓ６６８）。受付部１６８が痛み有るボタン４２４のタッチを受け付けると（Ｓ６７０）、表示処理部１６４は、細胞の採取前の場合に、採取前の拡張入力画面４３０を表示し、細胞の採取後の場合に、採取後の拡張入力画面４６０を表示する（Ｓ６７２）。受付部１６８は、表示されている各入力画面において体調報告の入力を受け付け（Ｓ６７４）、送信部１１４は、体調報告をサーバ装置３００へ送信する（Ｓ６７６）。

【0101】

ドナーインターフェース部３１２の受信部３１４が体調報告を受信すると、記録部３２６は、体調報告を記録する（Ｓ６７８）。通知部３２８は、体調報告の着信があった旨を医療者端末２００へ通知する（Ｓ６８０）。

【0102】

変形例１のネイティブアプリ方式でも実施形態と同様のドナーサービスを提供できる。ネイティブアプリ方式の場合には、画面のデータやイベントなどのデータ伝送量が少ないので、ドナー端末１００の動作が機敏である。また、通信負荷が少ないので、通信障害を招きにくいというメリットもある。

【0103】

［変形例２］
実施形態では、Ｗｅｂアプリ方式で医療者サービスを提供する例を示したが、ネイティブアプリ方式によって医療者サービスを提供してもよい。変形例２では、医療者端末２００に医療者サービス用のネイティブアプリがインストールされるものとする。

【0104】

医療者端末２００の表示とユーザ操作の仕様については、ネイティブアプリ方式であっても、図８に関連して説明したＷｅｂアプリ方式の場合と同様である。

【0105】

図１３は、変形例２における医療者端末２００の機能ブロック図である。
医療者端末２００は、ユーザインターフェース処理部２６０、通信部２１０、データ処理部２２０およびデータ格納部２４０を含む。ここでいうユーザは、医療者を指す。基本的な構成は、変形例１におけるドナー端末１００の場合（図１１）と同様である。

【0106】

これらの機能ブロックは、医療者サービス用のネイティブアプリのプログラムをＣＰＵで実行することによって実現される。

【0107】

図１４は、ネイティブアプリ方式による医療者サービスのシーケンス図である。
医療者端末２００の表示処理部２６４は、図８に示したログイン画面５００を表示する（Ｓ７５０）。受付部２６８は、アカウント情報の入力を受け付け（Ｓ７５２）、送信部２１４は、アカウント情報をサーバ装置３００へ送信する（Ｓ７５４）。

【0108】

医療者インターフェース部３１３の受信部３１５がアカウント情報を受信すると、認証部３２２は、医療者を認証する（Ｓ７５６）。医療者認証が成功すると、送信部３１７は、担当情報、ドナー情報、体調報告及び診断データなどを医療者端末２００へ送信する（Ｓ７５８）。送信される担当情報、ドナー情報、体調報告及び診断データは、この医療者の担当に関する情報だけでもよい。

【0109】

Ｓ７５４で送信されるアカウント情報は、ログインの要求であると共に、担当情報、ドナー情報、体調報告及び診断データなどの要求に相当する。送信部２１４は、アカウント情報とは別に、担当情報、ドナー情報、体調報告及び診断データなどの要求をサーバ装置３００へ送信してもよい。

【0110】

医療者端末２００の受信部２１２が担当情報、ドナー情報、体調報告及び診断データなどを受信すると、画面生成部２２２は、受信したデータに基づいて図８に示したメイン画面５１０を生成する（Ｓ７６０）。表示処理部２６４は、生成されたメイン画面５１０を表示する（Ｓ７６２）。受付部２６８が報告済ボタン５１２のタッチを受け付けると（Ｓ７６４）、送信部２１４は、報告済ボタン５１２のイベントをサーバ装置３００へ送信する（Ｓ７６６）。報告済ボタン５１２のイベントは、ドナー端末１００への通知の要求に相当する。

【0111】

医療者インターフェース部３１３の受信部３１５が報告済ボタン５１２のイベントを受信すると、通知部３２８は、体調報告の伝達が済んだ旨をドナー端末１００へ通知する（Ｓ７７０）。ドナー端末１００への通知を行わない仕様の場合には、報告済ボタン５１２のイベントの送信（Ｓ７６６）を省いてもよい。

【0112】

画面生成部２２２は、体調報告などに基づいて図８に示した体調報告画面５２０を生成し（Ｓ７７２）、表示処理部２６４は、体調報告画面を表示する（Ｓ７７４）。受付部２６８が診断ボタン５２２のタッチを受け付けると（Ｓ７７６）、表示処理部２６４は、図８に示した診断画面５３０を表示する（Ｓ７７８）。受付部２６８が診断データの入力を受け付けると（Ｓ７８０）、送信部２１４は、診断データをサーバ装置３００へ送信する（Ｓ７８２）。

【0113】

医療者インターフェース部３１３の受信部３１５が診断データを受信すると、記録部３２６は、診断データを記録する（Ｓ７８４）。

【0114】

変形例２のネイティブアプリ方式でも実施形態と同様の医療者サービスを提供できる。ネイティブアプリ方式の場合には、画面のデータやイベントなどのデータ伝送量が少ないので、医療者端末２００の動作が機敏である。また、通信負荷が少ないので、通信障害を招きにくいというメリットもある。

【0115】

［変形例３］
造血幹細胞以外の細胞、臓器又は組織の採取において上述の技術を適用してもよい。更に、医療に関連する行為の全般において上述の技術を適用してもよい。たとえば、診断、治療、検査、カウンセリング又はアドバイスなどにも応用できる。

【0116】

また、ドナー以外を対象者としてもよい。医療を受ける対象者には、患者の他に、検査、カウンセリング又はアドバイスを受ける者などが含まれる。これらの対象者が使用する対象者端末は、上述したドナー端末１００に相当する。

【0117】

医師及びコーディネーター以外の担当者が、健康観察システムを利用してもよい。医療側の担当者は、看護師、専門技師又は医療事務などの医療関係者、あるいは医療に協力するケアマネージャー又は管理栄養士などの医療協力者であってもよい。なお、移植コーディネーターは、医療専門職の一種である。これらの担当者が使用する担当者端末は、上述した医療者端末２００に相当する。

【0118】

体調以外の状況を報告してもよい。状況報告には、身体的状況だけにとどまらず、天候や生活などの環境的状況も含まれる。天候の情報は、たとえば気温、湿度又は気圧である。生活の情報は、たとえば、運動時間、就業時間、睡眠時間、入浴回数、食事内容（接種カロリー、食品種類など）、食事形態（通常食、きざみ食、又は流動食の別など）又は食事回数である。環境的状況も、体調に影響を与えるので健康管理や診断に役立つ。

【0119】

採取の前後に限らず、医療を受ける対象者に関する所定イベントの前後において項目構成が異なる入力画面のデータが送信されるようにしてもよい。また、それらの画面が表示されるようにしてもよい。所定イベントには、手術や薬の服用などの治療、検査、病状の進行や回復の段階、入退院及び転院などが含まれる。所定イベントの発生情報は、ドナー情報、体調報告又は診断データなどに含まれる場合がある。あるいは、他のデータにおいて所定イベントの発生情報が特定されるようにしてもよい。つまり、上述したドナーインターフェース部３１２の受信部３１４及び医療者インターフェース部３１３の受信部３１５は、医療を受ける対象者に関する所定イベントの発生情報を取得する取得部に相当する。また、それ以外の受信手段又は入力手段によって、所定イベントの発生情報を取得してもよい。

【0120】

［変形例４］
サーバ装置３００は、所定時間までに体調報告が無かった場合に、ドナーと担当者（たとえば、医療者又はコーディネータ―）の双方に対してアラートを送るようにしてもよい。以下では、担当者は医療者であるものとして説明する。

【0121】

所定時間は、ドナーが体調報告を送る期限として設定されている時間（時刻）である。つまり、ドナーは、所定時間までに体調報告を送るルールになっている。たとえば、所定時間が午後５時であれば、ドナーは午後５時までに体調報告を送ることになっている。所定時間は、各ドナーにおいて共通でもよいし、ドナー個別に設定されてもよい。

【0122】

所定時間に至ると、通知部３２８は、体調報告記憶部３４８を参照して、まだ体調報告を受けていないドナー（以下、「未報告のドナー」という）を特定する。未報告のドナーがいなければ、アラートの通知を行わない。未報告のドナーがいる場合には、通知部３２８は、担当情報記憶部３４６を参照して、そのドナーを担当する医療者を特定する。

【0123】

通知部３２８は、特定されたドナーのドナー端末１００へアラートを通知する。ドナーへのアラートは、たとえば「体調報告を送ってください。」などのメッセージを含むようにしてもよい。ドナー端末１００は、通知を受けると、所定のメッセージ（たとえば、「体調報告を送りましょう。」）あるいは通知されたメッセージを表示し又は音声出力する。ドナー端末１００は、通知音を出力してもよい。このようにすることによって、ドナーへ体調報告を催促することができる。アラートを受けたドナーは、体調を報告する。

【0124】

更に、通知部３２８は、特定された医療者の医療者端末２００へアラートを通知する。医療者へのアラートは、たとえば「○○さんから体調報告がありません。」などのメッセージを含むようにしてもよい。「○○さん」は、未報告のドナーの名前である。医療者端末２００は、通知を受けると、所定のメッセージ（たとえば、「まだ体調報告を受けていないドナーがいます。」）あるいは通知されたメッセージを表示し又は音声出力する。医療者端末２００は、通知音を出力してもよい。アラートを受けた医療者は、たとえばドナーへ電話連絡を行う。このようにすることによって、医療者は、担当するドナーに対する体調確認の漏れを防げる。

【0125】

［その他の変形例］
変形例１で説明したネイティブアプリ方式のドナーサービスと変形例２で説明したネイティブアプリ方式の医療者サービスを組み合わせてもよい。また、一方のサービスをネイティブアプリ方式とし、他方のサービスをＷｅｂアプリ方式としてもよい。あるいは、同一のサービスに関して両方式を併用してもよい。更に、Ｗｅｂアプリ方式とネイティブアプリ方式を組み合わせたハイブリッドアプリ方式によってサービスを提供してもよい。

【0126】

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

【0127】

まとめると、サーバ装置３００においてドナーから体調報告を受けて一旦記憶し、医師あるいはコーディネーターへそれを送るので、ドナーは、任意の時間に任意の場所から体調を報告できる。医師あるいはコーディネーターは、任意の時間に任意の場所でドナーの体調を閲覧できる。これにより、リモートでの健康管理がしやすくなる。

【0128】

また、採取の前後で入力画面の項目を切り替えるので、採取の前後でそれぞれ注意しなければならない合併症や副作用の判断に必要な情報を報告することができる。

【0129】

また、どこかに痛みが有る場合に限って部位を特定させるので、ドナーは、操作方法を理解しやすい。

【0130】

また、痛みが有る部位の特定に関して未入力の候補部位について、一括して「無い」と設定するので、ドナーは、操作が楽である。

【0131】

また、医師あるいはコーディネーターの端末に、ドナーリストと時系列の体調報告のサマリーを表示するので、医師あるいはコーディネーターは、担当するドナー全員の状況を把握しやすい。

【0132】

また、ドナーが体調を報告すると医師あるいはコーディネーターへ通知されるので、伝達漏れを防止しやすい。

【0133】

また、体調報告が医師あるいはコーディネーターに伝達されるとドナーへ通知されるので、ドナーは安心できる。

【0134】

また、所定時間までに体調報告を受信していない場合に、未報告のドナーと、担当の医師あるいはコーディネーターへアラートを送るので、体調報告と体調確認の漏れを防げる。

【0135】

また、採取に限らず医療行為の全般に適用できるので、いろいろな医療分野で情報伝達が簡便になり、医療活動が円滑に進む。

【符号の説明】

【0136】

１００ ドナー端末、１０２ ブラウザ、１０４ メーラー、１１０ 通信部、１１２ 受信部、１１４ 送信部、１２０ データ処理部、１２２ 画面生成部、１４０ データ格納部、１６０ ユーザインターフェース処理部、１６２ 出力部、１６４ 表示処理部、１６６ 入力部、１６８ 受付部、２００ 医療者端末、２０２ ブラウザ、２０４ メーラー、２１０ 通信部、２１２ 受信部、２１４ 送信部、２２０ データ処理部、２２２ 画面生成部、２４０ データ格納部、２６０ ユーザインターフェース処理部、２６２ 出力部、２６４ 表示処理部、２６６ 入力部、２６８ 受付部、３００ サーバ装置、３１０ 通信部、３１２ ドナーインターフェース部、３１３ 医療者インターフェース部、３１４ 受信部、３１５ 受信部、３１６ 送信部、３１７ 送信部、３２０ データ処理部、３２２ 認証部、３２４ 画面生成部、３２６ 記録部、３２８ 通知部、３４０ データ格納部、３４２ アカウント情報記憶部、３４４ ドナー情報記憶部、３４６ 担当情報記憶部、３４８ 体調報告記憶部、３５０ 診断データ記憶部、４００ ログイン画面、４０２ メールアドレスエリア、４０４ パスワードエリア、４０６ ログインボタン、４１０ 経過画面、４１２ 報告済ボタン、４１４ 未報告ボタン、４２０ 採取前の標準入力画面、４２２ 痛み無いボタン、４２４ 痛み有るボタン、４２６ 戻るボタン、４２８ 次へボタン、４３０ 採取前の拡張入力画面、４３２ プルダウンメニュー、４３４ チェックボックス、４４０ 採取後の標準入力画面、４４２ 使用無いボタン、４４４ Ａ薬ボタン、４４６ Ｂ薬ボタン、４４８ その他ボタン、４５０ 可能ボタン、４５２ 不可能ボタン、４６０ 採取後の拡張入力画面、５００ ログイン画面、５０２ メールアドレスエリア、５０４ パスワードエリア、５０６ ログインボタン、５１０ メイン画面、５１２ 報告済ボタン、５１４ 未報告ボタン、５１６ 診断済ボタン、５１８ 未診断ボタン、５２０ 体調報告画面、５２２ 診断ボタン、５３０ 診断画面、５３２ 脾腫無いボタン、５３４ 脾腫有るボタン、５３６ 触診ボタン、５３８ エコーボタン、５４０ 測定値エリア、５４２ 減量無しボタン、５４４ 減量５０％ボタン、５４６ 中止ボタン、５４８ 投与なしボタン、５５０ 理由エリア

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】