特許 7532237 診療支援システム、認証方法およびプログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-02

(45)【発行日】2024-08-13

(54)【発明の名称】診療支援システム、認証方法およびプログラム

(51)【国際特許分類】

   G06F 21/32 20130101AFI20240805BHJP

   G16H 50/20 20180101ALI20240805BHJP

   G06T 7/00 20170101ALI20240805BHJP

【ＦＩ】

G06F21/32

G16H50/20

G06T7/00 510B

【請求項の数】 10

(21)【出願番号】P 2020208222

(22)【出願日】2020-12-16

(65)【公開番号】P2022095098

(43)【公開日】2022-06-28

【審査請求日】2023-11-15

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100126240

【弁理士】

【氏名又は名称】阿部 琢磨

(74)【代理人】

【識別番号】100223941

【弁理士】

【氏名又は名称】高橋 佳子

(74)【代理人】

【識別番号】100159695

【弁理士】

【氏名又は名称】中辻 七朗

(74)【代理人】

【識別番号】100172476

【弁理士】

【氏名又は名称】冨田 一史

(74)【代理人】

【識別番号】100126974

【弁理士】

【氏名又は名称】大朋 靖尚

(72)【発明者】

【氏名】山嵜 深

【審査官】塩澤 如正

(56)【参考文献】

【文献】特開２０１４－１４６２７５（ＪＰ，Ａ）

【文献】特開２００３－０３０１５４（ＪＰ，Ａ）

【文献】特開２０１１－１１８５５６（ＪＰ，Ａ）

【文献】特開２００２－００８０３４（ＪＰ，Ａ）

【文献】特開２００４－００５２７３（ＪＰ，Ａ）

【文献】特開２０１６－１９８１９７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／３２

Ｇ１６Ｈ ５０／２０

Ｇ０６Ｔ ７／００

(57)【特許請求の範囲】

【請求項1】

記憶部に予め記憶された登録ユーザの過去の生体情報を取得する第１の生体情報取得部と、
認証を要求するユーザ側の端末から送信された現在の生体情報を取得する第２の生体情報取得部と、
前記第１の生体情報取得部が取得した前記過去の生体情報と前記第２の生体情報取得部が取得した前記現在の生体情報とに基づいて、前記認証を要求するユーザが前記登録ユーザであるか否かを判定して認証を行う認証部と、
認証を要求するユーザの症状を取得する症状取得部と、を有し、
前記記憶部には前記登録ユーザの複数種類の過去の生体情報が記憶されており、
前記認証部は、前記症状に基づいて、前記複数種類の生体情報のうち、認証に用いる少なくとも２種類の生体情報の種類を決定し、前記少なくとも２種類以上の生体情報の各々に対する前記症状の影響度合いに基づいて認証を行うことを特徴とする診療支援システム。

【請求項2】

前記症状取得は、前記ユーザ側の端末から送信された症状に関する情報に基づいてユーザの症状を取得することを特徴とする請求項１に記載の診療支援システム。

【請求項3】

前記認証部は、前記複数種類の生体情報に対する前記症状の影響があるか否かを判断し、前記複数種類の生体情報のうち、影響があると判断した生体情報以外の生体情報を認証に用いることを特徴とする請求項１または請求項２に記載の診療支援システム。

【請求項4】

前記複数種類の生体情報にはユーザの顔の画像情報、音声情報、指紋情報、虹彩情報のうちの少なくとも１つが含まれることを特徴とする請求項３に記載の診療支援システム。

【請求項5】

認証に用いる少なくとも２つ以上の生体情報に対して重み付けを行う重み付け部を更に有し、
前記症状が認証に用いる生体情報に影響する症状である場合、前記重み付け部は、前記症状によって影響される生体情報の重みが他の生体情報の重みよりも小さくなるように重み付けを行い、
前記認証部は、前記重み付け部によって重み付けされた生体情報に基づいて認証を行うことを特徴とする請求項１または２に記載の診療支援システム。

【請求項6】

前記症状と前記複数種類の生体情報との影響関係を記録した関係記録部を有し、
前記認証部は前記関係記録部から取得した前記影響関係に基づいて認証に用いる生体情報の種類を決定することを特徴とする請求項１ないし請求項５のいずれか１項に記載の診療支援システム。

【請求項7】

前記症状がユーザの視力に影響がある場合、音声で認証のための操作をガイドする音声ガイド部を有することを特徴とする請求項１ないし請求項６のいずれか１項に記載の診療支援システム。

【請求項8】

記憶部に予め記憶された登録ユーザの過去の生体情報を取得する第１の生体情報取得工程と、
認証を要求するユーザ側の端末から送信された現在の生体情報を取得する第２の生体情報取得工程と、
第１の生体情報取得工程で取得した前記過去の生体情報と、前記第２の生体情報取得工程で取得した前記現在の生体情報とに基づいて、前記認証を要求するユーザが前記登録ユーザであるか否かを判定して認証を行う認証工程と、
認証を要求するユーザの症状を取得する症状取得工程と、を実行し、
前記記憶部には前記登録ユーザの複数種類の過去の生体情報が記憶されており、
前記認証工程では、前記症状に基づいて、前記複数種類の生体情報のうち、認証に用いる少なくとも２種類の生体情報の種類を決定し、前記少なくとも２種類以上の生体情報の各々に対する前記症状の影響度合いに基づいて認証を行うことを特徴とする認証方法。

【請求項9】

請求項８に記載の認証方法を実行するプログラム。

【請求項10】

請求項９に記載のプログラムを格納した記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、診療支援システム、認証方法およびプログラムに関する。

【背景技術】

【0002】

近年、遠隔地にある診療所、または患者宅と専門病院等とをネットワークで結び、リアルタイム双方向の画像通信を行うことで、遠隔地の患者等の画像情報等に基づいて専門医等の医療従事者が診療を行うようなシステムが知られている。

【0003】

このようなシステムを使用するユーザ本人の現在の画像と、予めＩＣカードに記憶されたユーザ本人の画像とに基づいて認証を行うシステムが特許文献１に開示されている。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２００７－２９３４９９号公報

【発明の概要】

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

【0005】

しかし、予め記憶していた画像や音声などの本人の情報との比較によって認証を行うシステムの場合、患者（ユーザ）の症状によっては、現在のユーザの情報が予め記憶されていた本人の情報から変化してしまい、うまく認証できない場合が発生することが考えられる。

【0006】

そこで、本発明は、遠隔診療を受けようとするユーザの症状による認証の精度の低下を軽減することができる診療支援システム、認証方法およびプログラムを提供することを目的とする。

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

【0007】

そこで、本発明に関る診療支援システムは、記憶部に予め記憶された登録ユーザの過去の生体情報を取得する第１の生体情報取得部と、認証を要求するユーザ側の端末から送信された現在の生体情報を取得する第２の生体情報取得部と、前記第１の生体情報取得部が取得した前記過去の生体情報と前記第２の生体情報取得部が取得した前記現在の生体情報とに基づいて、前記認証を要求するユーザが前記登録ユーザであるか否かを判定して認証を行う認証部と、認証を要求するユーザの症状を取得する症状取得部と、を有し、前記記憶部には前記登録ユーザの複数種類の過去の生体情報が記憶されており、前記認証部は、前記症状に基づいて、前記複数種類の生体情報のうち、認証に用いる少なくとも２種類の生体情報の種類を決定し、前記少なくとも２種類以上の生体情報の各々に対する前記症状の影響度合いに基づいて認証を行うことを特徴とするものである。

【発明の効果】

【0008】

本発明によれば、システムを利用するユーザの症状によってシステムに送信する現在のユーザの情報が認証のために予め記憶されていた本人の情報から変化した場合にも、認証の精度の低下を軽減することができるという効果がある。

【図面の簡単な説明】

【0009】

【図1】第１の実施形態に係る診療支援システムの全体構成図

【図2】第１の実施形態における処理手順を示すフローチャート

【図3】第１の実施形態における症状の入力画面を示した図

【図4】第１の実施形態における認証に使用する生体情報決定の処理手順を示すフローチャート

【図5】第２の実施形態に係る診療支援システムの全体構成図

【図6】第３の実施形態に係る診療支援システムの全体構成図

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

【0010】

以下に、図面を参照しながら、本発明に係る第１の実施形態について説明する。ただし、発明の範囲は図示例に限定されるものではない。

【0011】

＜第１の実施形態＞
第１の実施形態に係る診療支援システムは、ユーザとしての患者がユーザ側の端末からネットワークを介して医療従事者側の端末と接続して遠隔診療を受診する場合において、ユーザの症状に基づいて認証に用いる生体情報を決定して認証を行う。

【0012】

図１は、第１の実施形態に係る診療支援システムおよび前記診療支援システムによって通信を行うユーザ側の端末および医療従事者側の端末を表した全体構成図である。

【0013】

図１には、診療支援システム１０と、診療支援システム１０と通信を行うユーザ（患者）側の端末２および医師等が使用する医療医従事者側の端末３を示している。ユーザ側の端末２と医療従事者側の端末３とは通信網４を介して互いに通信可能に接続されている。通信網４は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、固定電話回線、携帯電話回線等で構成される。ユーザ側の端末２は、患者などの遠隔診療による診療を受診する側（ユーザ）が操作する端末であり、患者は通信網４を介して診療支援システム１０から遠隔診療を利用するための認証を受けて医療従事者側の端末３と通信を行う。

【0014】

診療支援システム１０は、その機能的な構成として、受信部１１、送信部１２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１４、記憶部１５、制御部１６を有している。

【0015】

受信部１１および送信部１２は、例えば無線ＬＡＮカード、優先ＬＡＮカード、固定電話回線ＩＦ、携帯電話回線ＩＦ等の通信用のインターフェース機器で実現される。受信部１１は通信網４を介して、ユーザ側の端末２や医療従事者側の端末３から認証情報等のデータを受信する機能を司る。また、送信部１２は、ユーザ側の端末２や医療従事者側の端末３に対して認証結果情報（通信の許可または禁止）などのデータを送信する機能を司る。受信部１１および送信部１２は上述した通信用のインターフェースのように一つのデバイスに実装されていても良い。本実施形態では、便宜上、機能別に記載しているに過ぎない。

【0016】

ＲＯＭ１３（記録媒体）は、不揮発性のメモリ等で実現され、本実施の形態の実行に係る各種プログラム等を記憶（格納）する。ＲＡＭ１４は、揮発性のメモリ等で実現され、各種データを一時的に記憶する。記憶部１５は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等で実現され、各種データを記憶する。本実施形態においては、診療支援システムの利用者として登録されている登録ユーザの過去の生体情報が記憶されている。

【0017】

制御部１６は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等で実現され、診療支援システム１０における処理を統括制御する。

【0018】

制御部１６は、その機能的な構成として、第１の生体情報取得部１７、症状取得部１８、第２の生体情報取得部１９、認証部２０を有する。制御部１６内の各部の機能については、図２のフローチャートの説明と併せて説明する。

【0019】

図２は、診療支援システム１０の制御部１６によって制御される、第１の実施形態における処理手順を示すフローチャートである。なお、以下では、通信網４を介した通信方式として、例えば、ＨＴＴＰＳ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）等の暗号化された通信方式を利用することにより、通信データが第三者に漏洩しないようなセキュリティ対策を行うものとする。

【0020】

ステップＳ１０１において、受信部１１はユーザ側の端末２から、ユーザのＩＤ情報と、認証のために必要な現在の生体情報を受信する。ユーザ側の端末２は例えばスマートフォンやタブレット端末、パーソナルコンピュータなどを含み、端末に備えられた若しくは端末に外付けで接続したカメラやマイク、指紋パターン検出デバイス等を用いてユーザ本人の現在の生体情報を取得するように構成されている。そして、ユーザは、遠隔診療を求めるために、ユーザ側の端末２を操作することによって、ユーザのＩＤおよび取得したユーザの現在の生体情報を、通信網４を介して診療支援システム１０に送信する。ここで、ユーザ側の端末２で取得する生体情報は複数種類であり、取得した複数種類の生体情報がユーザ側の端末２から診療支援システム１０に送信される。

【0021】

ステップＳ１０２において、図示しないＩＤ取得部は、受信部１１で受信したユーザのＩＤを取得し、システムに利用登録されている登録ユーザか否かを判断する。そして、受信したＩＤのユーザが登録ユーザである場合にはステップＳ１０３に進み、登録ユーザではなかった場合にはステップＳ１１０に進む。

【0022】

ステップＳ１０３において、第１の生体情報取得部１７は、記憶部１５にアクセスして、認証の要求をしてきたユーザの過去の生体情報を検索する。そして、ステップＳ１０４において、ステップＳ１０３での検索結果に基づいて、ユーザの過去の生体情報があるか否かの判断を行い、ユーザの過去の生体情報がある場合にはステップＳ１０５に進み、ユーザの過去の生体情報が無い場合にはステップＳ１１０に進む。

【0023】

ステップＳ１０５において、認証部２０はユーザ側の端末２から送信され、症状取得部１８によって取得したユーザの症状に関する情報と、記憶部１５に記憶されたユーザの過去の生体情報の種類に基づいて、認証に使用する生体情報の種類を決定する。ユーザの症状に関する情報はユーザのＩＤや現在の生体情報とともに受信しても良いし、ＩＤや現在の生体情報とは別に取得するようにしても良い。なお、認証に使用することを決定する生体情報の種類は複数種類でも良い。ここで、図４を用いてステップＳ１０５の中の詳細な実行手順を説明する。

【0024】

図４は、図２における認証に使用する生体情報を決定するステップＳ１０５の処理を示したフローチャートである。

【0025】

ステップＳ１０５１において、症状取得部１８は認証の要求をしてきたユーザの症状に関する情報を取得する。症状に関する情報とは、病状や怪我に関する情報であり、例えば、ユーザの身体の部位についての情報、症状の程度、等を含む。具体的には、例えば、「風邪症状で声を出し辛い」や、「顔面の一部に怪我」や、「指紋認証に使用する指に怪我を負った」等の情報を含む。

【0026】

ここで、症状に関する情報は、ユーザがユーザ側の端末２を操作して入力を行い、診療支援システム１０に対して送信する。また、入力する形式は問診票のように質問に対してユーザが回答を入力する形式にしても良く、症状に関する情報を認証後に医療従事者側の端末３が閲覧できるようにしても良い。

【0027】

図３は第１の実施形態における症状の入力例を示した図である。図３のように、ユーザ側の端末２の表示画面に、ユーザの症状を確認するための画面６０が表示される。ユーザは画面６０に表示される案内に従って、各項目について入力を行い、送信ボタン６１を押下する。送信ボタン６１が押下されると、入力された症状に関する情報が通信網４を介して診療支援システムに送信される。なお、図３に示した例では、症状として右目の腫れがある例を示している。

【0028】

ステップＳ１０５２において、認証部２０はユーザの症状による生体情報への影響を判断する。具体的には、症状取得部１８によって取得した症状の部位および症状の種類などの症状に関する情報と、認証に用いられる複数種類の生体情報との影響の関係をＲＯＭ１３等に予め記録されているテーブル等を参照して、症状がユーザの外観に影響がある症状か、症状がユーザの声に影響がある症状であるか、症状がユーザの指紋情報を用いた指紋認証に影響がある症状か、等を判断する。

【0029】

表１に、症状に関する情報と認証に用いる生体情報との影響関係を記録した関係記録部としてのテーブルの例を示す。表１における左端の縦の列には症状に関する情報に対応する情報が記されており、一番上の行には認証に使用するか否か判断の対象となる複数種類の生体認証が記されている。表の中の「〇」は認証の対象として使用可能であることを示し、「×」は認証の対象として使用できない可能性が高いことを示している。

【0030】

ステップ１０５３において、認証部２０はステップＳ１０５２での判断結果に基づいて認証に使用する生体情報を決定する。具体的には、例えば顔面の怪我のようにユーザの顔の外観に影響する症状である場合には、ユーザの顔の画像情報などの生体情報を認証に用いずに、ユーザの顔の画像情報以外の生体情報を認証に用いる。また、風邪症状で声を出し辛い症状や、風邪の影響で声が変質した恐れがある症状である場合には、声紋などの音声に関する生体情報を認証に用いずに、音声に関する生体情報以外の生体情報を認証に用いる。

【0031】

例えば、図３に示した症状の場合、症状は眼の腫れであることから、表１の関係記録部としてのテーブルに照らし合わせると、顔画像（画像情報）および虹彩（虹彩情報）は「×」となっており、音声、指紋（指紋情報）は「〇」となっている。そこで、認証部２０は、テーブルを参照して顔画像（画像情報）および虹彩（虹彩情報）は認証に使用せずに、音声および指紋（指紋情報）の生体情報を認証に使用する決定を行う。認証に用いる生体情報を決定したら図４の処理を終了する。言い換えると、認証部２０は、複数種類の生体情報に対する症状の影響があるか否かを判断し、複数種類の生体情報のうち、影響があると判断した生体情報以外の生体情報を認証に用いる。また、この例のように、複数種類の生体情報のうち、少なくとも２種類の生体情報を認証に用いることが好ましい。

【表1】

【0032】

ここで、再び図２を用いて処理手順を説明する。ステップＳ１０６において、第１の生体情報取得部１７は、記憶部１５からステップＳ１０５において決定した生体情報の種類に対応するユーザの過去の生体情報を取得する。ステップＳ１０５において決定した認証に用いる生体情報の種類が複数種類である場合には、対応する複数種類の生体情報を取得する。

【0033】

ステップＳ１０７において、認証部２０は、第１の生体情報取得部１７が取得したユーザの過去の生体情報と、第２の生体情報取得部１９が取得したユーザの現在の生体情報とを比較する。

【0034】

ステップＳ１０８において、認証部２０は、ステップＳ１０７での比較結果に基づいて、認証の要求をしてきたユーザ（認証要求者）が登録ユーザであるか否かの判定を行う。認証の要求をしてきたユーザが登録ユーザであると判定した場合にはステップＳ１０９に進み、認証の要求をしてきたユーザが登録ユーザではないと判定した場合にはステップＳ１１０に進む。

【0035】

ステップＳ１０９において、認証部２０は認証の要求をしてきたユーザの遠隔診療のためのネットワークへの接続を許可する。具体的には、ユーザ側の端末２の医療従事者側の端末３への接続を許可する。そして図２の処理を終了する。

【0036】

ステップＳ１１０において、認証部２０は認証の要求をしてきたユーザの遠隔診療のためのネットワークへの接続要求を却下してアクセスを禁止する。そして図２の処理を終了する。

【0037】

以上、説明した処理手順を実行することによって、システムを利用するユーザの症状によって、システムに送信する現在のユーザの情報が、認証のために予め記憶されていた本人の情報から変化した場合にも、認証の精度の低下を軽減することができる。

【0038】

＜第２の実施形態＞
第１の実施形態では、図４のステップＳ１０５３において、症状による影響があると判断した生体情報以外の生体情報を認証に用いる例を説明した。第２の実施形態では、図５における本実施形態における全体構成に、音声ガイド部２１が追加されている点と、図４のステップＳ１０５３において、複数種類の生体情報に対して重み付けを行い、認証に用いる点が第１の実施形態と異なる。その他については第１の実施形態と同様である。

【0039】

図５は第２の実施形態に係る診療支援システムおよび前記診療支援システムによって通信を行うユーザ側の端末および医療従事者側の端末を表した全体構成図である。ここでは第１の実施例で説明した構成については説明を省略し、第１の実施形態と異なる部分のみを説明する。第２の実施形態においては、診療支援システム１０の制御部１６は、更に音声ガイド部２１と重み付け部２２を有している。

【0040】

音声ガイド部２１は、症状取得部によって取得された症状がユーザの視力に影響する症状である場合、認証に必要なユーザの操作を音声で誘導するための音声情報を、送信部１２を介してユーザ側の端末２に対して送信する。前記音声情報を受信したユーザ側の端末２は、端末に備えられたもしくは接続されたスピーカから音声を出力してユーザの操作を誘導する。

【0041】

重み付け部２２は、症状取得部１８によって取得した症状の部位および症状の種類と、認証に用いられる複数種類の生体情報との影響度合いをＲＯＭ１３等に予め記録されている関係記録部としてのテーブル等を参照して判断する。具体的には、重み付け部２２は、複数種類の生体情報に対する症状の影響度合いを判断して、認証に用いる少なくとも２つ以上の生体情報に対して重み付けを行う。重み付け部２２は、複数の生体情報のうち、第１の生体情報に対する症状の影響度が、第２の生体情報に対する影響よりも大きい場合、第１の生体情報に付与する重み係数が、第２の生体情報に付与する重み係数よりも小さくなるように重み付けを行う。例えば、複数の生体情報として、ユーザの顔の外観画像とユーザの音声を用いて認証を行う場合において、症状が風邪症状であって、音声に対する症状の影響度が顔の外観画像に対する影響度よりも大きい場合、音声に付与する重み係数が、顔の外観画像に付与する重み係数よりも小さくなるように重み付けを行う。

【0042】

そして、認証部２０は、重み付け部２２によって行われた重み付け結果に基づいて認証を行う。

【0043】

重み付け部２２による重み付け結果を利用して認証を行うようにすることで、症状の影響が大きな生体情報の認証への寄与を下げつつ、複数の生体情報を認証に利用することができるため、認証の精度をより向上させることができる。

【0044】

＜第３の実施形態＞
第１および第２の実施形態では、ユーザの過去の生体情報を記憶した記憶部１５を診療支援システム内部に有している例を説明した。しかし、記憶部の場所は診療支援システム内部に限られない。図６は第３の実施形態に係る診療支援システムおよび医療従事者側の端末を表した全体構成図である。図６に示すように、本実施形態では、記憶部としてクラウド５にユーザの過去の生体情報を格納している。ここで、記憶先のクラウドは１か所に限らず分散していても良い。この場合、診療支援システム１０は、通信網４を介して記憶部としてのクラウド５からユーザの過去の生体情報を取得する。

【0045】

なお、クラウド５はＰｅｒｓｏｎａｌ Ｈｅａｌｔｈ Ｒｅｃｏｒｄ（ＰＨＲ）やＥｌｅｃｔｒｏｎｉｃ Ｈｅａｌｔｈ Ｒｅｃｏｒｄ（ＥＨＲ）を構成するクラウドでも良い。

【0046】

ユーザの過去の生体情報を記憶する記憶部を診療支援システムの外部に有することで、診療支援システム自体のコストを低減することができる。また、複数の診療支援システムでユーザの過去の生体情報を共有することが可能となる。

【0047】

以上、第１の実施形態、第２の実施形態、第３の実施形態で説明した処理手順を実行することによって、システムを利用するユーザの症状によってシステムに送信する現在のユーザの情報が認証のために予め記憶されていた本人の情報から変化した場合にも、認証の精度の低下を軽減することができるという効果を有する。

【0048】

なお、第１の実施形態、第２の実施形態、第３の実施形態に係る診療支援システムは、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

【符号の説明】

【0049】

１０ 診療支援システム
１５ 記憶部
１６ 制御部
１７ 第１の生体情報取得部
１８ 症状取得部
１９ 第２の生体情報取得部
２０ 認証部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】