JP7388356B2 - 医療用情報処理システム、医療用情報処理装置、および医療用情報処理方法 - Google Patents

医療用情報処理システム、医療用情報処理装置、および医療用情報処理方法 Download PDF

Info

Publication number
JP7388356B2
JP7388356B2 JP2020537099A JP2020537099A JP7388356B2 JP 7388356 B2 JP7388356 B2 JP 7388356B2 JP 2020537099 A JP2020537099 A JP 2020537099A JP 2020537099 A JP2020537099 A JP 2020537099A JP 7388356 B2 JP7388356 B2 JP 7388356B2
Authority
JP
Japan
Prior art keywords
test
user
information
medical
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020537099A
Other languages
English (en)
Other versions
JPWO2020036207A1 (ja
Inventor
孝佳 平井
由香子 藤本
健人 中田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Sony Group Corp
Original Assignee
Sony Corp
Sony Group Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp, Sony Group Corp filed Critical Sony Corp
Publication of JPWO2020036207A1 publication Critical patent/JPWO2020036207A1/ja
Application granted granted Critical
Publication of JP7388356B2 publication Critical patent/JP7388356B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/30—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for calculating health indices; for individual health risk assessment
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/20—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems

Description

本開示は、医療用情報処理システム、医療用情報処理装置、および医療用情報処理方法に関する。
近年、医療費の増大が問題となっており、医療費の増大を抑制する方法が求められている。例えば、以下の特許文献１では、医療機関での受診を指導された人が実際に医療機関での診察や治療を受けているか否かを検出し、必要に応じて再指導を行うことで症状の重篤化を防ぎ、もって医療費の増大を抑制する技術が提案されている。
特開２００４－１６４１７３号公報
しかし、特許文献１に記載の技術などについては、多くの場合に医療機関での受診が求められるため、特許文献１に記載の技術などは医療費の増大に対する解決策としては不十分であった。例えば、ユーザは、医療に関する検査を受けようとするとき、多くの場合に病院などの医療機関にて検査を含む診察を受けることが求められる。したがって、医療機関は相当程度のリソース（例えば医師や設備など）を保有することが求められ、これは医療費の増大につながる。
そこで、本開示は上記に鑑みてなされたものであり、本開示は、医療費の増大をより適切に抑制することが可能な、新規かつ改良された医療用情報処理システム、医療用情報処理装置、および医療用情報処理方法を提供する。
本開示によれば、医療に関する検査の種別を示す検査種別情報を含む検査手配リクエストと、ユーザに関する情報であるユーザ情報と、を取得する取得部と、前記検査手配リクエストと前記ユーザ情報に基づいて、前記検査を実施可能な検査リソースを前記ユーザに提示する提示部と、前記ユーザに対して行われた前記検査の成果物を前記ユーザ情報に紐づけて管理する管理部と、前記ユーザによる入力に基づいて前記成果物を出力する出力部と、を備える、医療用情報処理システムが提供される。
また、本開示によれば、医療に関する検査の種別を示す検査種別情報を含む検査手配リクエストと、ユーザに関する情報であるユーザ情報と、を取得する取得部と、前記検査手配リクエストと前記ユーザ情報に基づいて、前記検査を実施可能な検査リソースを前記ユーザに提示する提示部と、前記ユーザに対して行われた前記検査の成果物を前記ユーザ情報に紐づけて管理する管理部と、前記ユーザによる入力に基づいて前記成果物を出力する出力部と、を備える、医療用情報処理装置が提供される。
また、本開示によれば、医療に関する検査の種別を示す検査種別情報を含む検査手配リクエストと、ユーザに関する情報であるユーザ情報と、を取得することと、前記検査手配リクエストと前記ユーザ情報に基づいて、前記検査を実施可能な検査リソースを前記ユーザに提示することと、前記ユーザに対して行われた前記検査の成果物を前記ユーザ情報に紐づけて管理することと、前記ユーザによる入力に基づいて前記成果物を出力することと、を有する、コンピュータにより実行される医療用情報処理方法が提供される。
本開示は、医療に関する検査の実施、および当該検査の成果物の利用をより適切な態様で実現することによって、医療費の増大をより適切に抑制することができる。
以上説明したように本開示によれば、医療費の増大をより適切に抑制することが可能になる。
なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。
第１の実施形態に係る医療用情報処理システムのシステム構成例を示すブロック図である。 マッチングサーバ１００の機能構成例を示すブロック図である。 管理サーバ２００の機能構成例を示すブロック図である。 ユーザ端末４００の機能構成例を示すブロック図である。 検査リソースの手配に至るまでの処理の流れの例を示すシーケンス図である。 検査リソースの手配に至るまでの処理の流れの例を示すシーケンス図である。 検査成果物の出力処理の流れの例を示すシーケンス図である。 第２の実施形態に係る医療用情報処理システムのシステム構成例を示すブロック図である。 診断サーバ６００の機能構成例を示すブロック図である。 ユーザへの総合結果情報の提供に関する処理の流れの例を示すシーケンス図である。 問診ＡＩのユーザインタフェースの具体例を示す図である。 問診ＡＩのユーザインタフェースの具体例を示す図である。 問診ＡＩのユーザインタフェースの具体例を示す図である。 問診ＡＩのユーザインタフェースの具体例を示す図である。 問診ＡＩのユーザインタフェースの具体例を示す図である。 問診ＡＩのユーザインタフェースの具体例を示す図である。 問診ＡＩのユーザインタフェースの具体例を示す図である。 マッチングサーバ１００、管理サーバ２００、検査端末３００、ユーザ端末４００、および診断サーバ６００を具現する情報処理装置９００のハードウェア構成例を示すブロック図である。
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
なお、説明は以下の順序で行うものとする。
１．第１の実施形態
１．１．システム構成
１．２．装置の機能構成
１．３．処理の流れ
２．第２の実施形態
２．１．システム構成
２．２．装置の機能構成
２．３．処理の流れ
３．ユーザインタフェース
４．ハードウェア構成
５．まとめ
＜１．第１の実施形態＞
（１．１．システム構成）
まず、図１を参照して、本開示の第１の実施形態に係る医療用情報処理システムのシステム構成例について説明する。
図１に示すように、本実施形態に係る医療用情報処理システムは、マッチングサーバ１００と、管理サーバ２００と、検査端末３００と、ユーザ端末４００と、を備え、これらの装置がネットワーク５００によって接続されている。
（マッチングサーバ１００）
マッチングサーバ１００は、検査を受けるユーザと、検査を行う検査リソースとをマッチングする医療用情報処理装置である。より具体的に説明すると、マッチングサーバ１００は、まず、医療に関する検査（以降、便宜的に「検査」と呼称する場合がある）の種別を示す検査種別情報を含む検査手配リクエストと、ユーザに関する情報であるユーザ情報と、をユーザ端末４００から取得する。
ここで、「医療に関する検査」とは、ユーザや傷病の状態を評価するために行われる行為全般を指し、診断、治療、手術、またはユーザの症状の推定とは別に行われるものを指す。より具体的には、医療に関する検査には、ユーザの身体状態を評価する検査や、特定の傷病の有無や程度を評価する検査などが含まれ、ユーザ自身による検査や医療検査従事者が所定の検査装置を用いて行うものなどが含まれる。そして、医療に関する検査が行われた後に、その成果物（以降、「検査成果物」と呼称する場合がある）に基づいて医師などが診断、治療、手術、またはユーザの症状の推定などを行う。なお例えば、検査がＸ線検査であれば検査成果物はＸ線画像情報などであり、検査が血液検査であれば検査成果物は血中物質に関する各種数値などである。また、医療に関する検査は、医師や歯科医師、看護師、臨床検査技師の監督下における検査を含んでもよい。また、検査成果物を示すデータには、検査に使用された機器や器具の情報、検査を行った検査者の情報、検査機関の情報などが紐づけられていてもよい。また、検査成果物を示すデータには、どのような種別の医療データかを示すメタデータが付与されていてもよい。
また、検査種別情報によって示される「検査の種別（以降、「検査種別」と呼称する場合がある）」とは、検査を区別するものを指し、例えば、検査の種類、区分、分類、またはカテゴリなどのように検査を区別するものを示す何らかの語に置き換えられてもよい。
また、「ユーザ情報」とは、検査を受けるユーザに関する何らかの情報を指す。本実施形態において、ユーザ情報には、ユーザの識別情報（例えばＩＤなど）、ユーザの属性情報（例えば氏名、性別、年齢、血液型、住所、電話番号、家族構成、職業、保険情報またはクレジットカード情報など）、ユーザの位置情報（例えば緯度、経度、または高度など）、ユーザが過去に受けた検査に関する履歴情報（例えばユーザが検査を受けた日時、期間、または検査内容など）、またはユーザが今後受ける検査に関する設定情報など（例えば検査に関するユーザの希望事項、必要事項、または制限事項など）が含まれることを想定しているが、ユーザ情報は、必ずしもこれらの情報に限定されない。なお、ユーザ端末４００がスマートフォンなどのようにユーザに携帯される装置であったり、ウェアラブル装置などのようにユーザに装着される装置であったりする場合、ユーザの位置情報は、ユーザ端末４００の位置情報と等価であるため、「ユーザ端末４００の端末情報」として扱われてもよい。
そして、マッチングサーバ１００は、取得した検査手配リクエストとユーザ情報に基づいて、検査を実施可能な検査リソースをユーザに提示する。
ここで、本実施形態において「検査リソース」には、医療検査機関、医療検査従事者、検査装置（車両や飛行体などのように移動機能を有し、ユーザの位置まで移動可能な検査装置も含む）、またはユーザ自身に使用される検査キットなどが含まれることを想定しているが、検査リソースは必ずしもこれらに限定されない。また上記のとおり、「医療に関する検査」が診断、治療、手術、またはユーザの症状の推定とは別に行われるものを指すため、検査リソースは、検査成果物に基づく診断、治療、手術、またはユーザの症状の推定を行わないことを想定しているが、必ずしもこれに限定されない。例えば、検査リソースである病院は、ユーザの検査を行った後に、検査成果物に基づいて適宜診断などを行ってもよい。以上の処理によって、ユーザは適切な検査を容易に受けることができる。
（管理サーバ２００）
管理サーバ２００は、検査成果物、および検査リソースを管理する医療用情報処理装置である。検査成果物の管理についてより具体的に説明すると、管理サーバ２００は、検査リソースによって検査が行われた後に検査端末３００から検査成果物を受信し、検査成果物をマッチングサーバ１００から受信したユーザ情報に紐づけて管理する。そして、管理サーバ２００は、ユーザによる入力に基づいて検査成果物をユーザ所望の装置に対して出力する。
上記のとおり、従来、ユーザは医療に関する検査を受けようとするとき、病院などの医療機関で診察を受けることが必要になる場合が多く、これによって医療費が増大していた。一方、本実施形態に係る医療用情報処理システムによって、ユーザは、管理サーバ２００に対して入力を行うことで検査成果物を所望の装置に対して出力することができるため、検査成果物をもとに様々な行動をとることができる。例えば、ユーザは、検査成果物を自らの装置に対して出力することで自ら診断を行ったり、検査成果物を診断サービス提供者の装置に対して出力することで診断サービスを受けたりすることができる。これによって、例えば、軽微な症状のユーザによる来院などが抑制され、診断医の人件費などが低減するため、医療費の増大が抑制され得る。
管理サーバ２００による検査リソースの管理についてより具体的に説明すると、管理サーバ２００は、検査リソース自体、または検査リソースを管理する装置など（例えば医療検査機関のサーバなど）との通信によって、検査リソースが稼働する予定に関する情報（または検査リソースの稼働状況に関する情報など）を受信し、当該情報を管理する。検査リソースが２以上存在する場合、管理サーバ２００は、当該情報を検査リソース毎に管理する。
そして、管理サーバ２００は、検査リソースの手配を行うことができる。例えば、管理サーバ２００は、空き状態になっている時間帯に検査リソースを予約することができる。検査リソースがユーザに提示されるだけでなく検査リソースの手配まで行われることによって、ユーザはより容易に検査を受けることができる。
（検査端末３００）
検査端末３００は、検査成果物を管理サーバ２００に対して送信する医療用情報処理装置である。より具体的に説明すると、検査端末３００は、医療検査従事者が操作する装置であり、検査が終了した後に医療検査従事者の操作によって（または自動で）検査成果物を管理サーバ２００に対して送信する装置である。なお、ユーザが検査キットを用いて自ら検査する場合には、検査端末３００はユーザが操作する装置である。また、検査端末３００は、検査に使用される検査装置（検査キットを含む）であってもよい。また、検査成果物がユーザ端末４００との通信やその他の方法（例えば郵送など）によって管理サーバ２００に提供される場合、医療用情報処理システムは検査端末３００を備えなくてもよい。
（ユーザ端末４００）
ユーザ端末４００は、検査手配リクエストおよびユーザ情報を送信する情報処理装置である。例えば、ユーザ端末４００は、所定のプログラムを実行することでユーザに対して所定のユーザインタフェースを提供する。そして、ユーザが当該ユーザインタフェースを介して各種入力を行うと、ユーザ端末４００は、当該入力に基づいて検査種別情報を含む検査手配リクエスト、およびユーザ情報を生成する。
検査手配リクエストの生成についてより具体的に説明すると、ユーザは、複数の選択肢の中から所望の検査種別を選択したり、検査種別をテキスト形式で直接入力したりできてもよい。また、ユーザが、患部を撮影した静止画像情報や動画情報などを入力し、ユーザ端末４００がこれらの情報を解析することによって適切な検査種別やその候補を出力してもよい。また、ユーザが複数の問いに対して回答することで、ユーザ端末４００が回答結果に基づいて適切な検査種別やその候補を出力してもよい。ユーザが適切な検査種別を入力することは容易ではないところ、ユーザ端末４００は、上記の方法によってユーザに対して大きな負荷をかけることなく適切な検査手配リクエストを生成することができる。
（ネットワーク５００）
ネットワーク５００は、上記の装置間を所定の通信によって接続するネットワークである。なお、ネットワーク５００は、必ずしも全ての装置間を接続する必要はなく、互いに通信可能な装置を限定してもよい。例えば、検査端末３００は、ユーザ端末４００やマッチングサーバ１００などと通信できなくてもよい。
ネットワーク５００に用いられる通信方式および回線の種類などは特に限定されない。例えば、ネットワーク５００は、ＩＰ－ＶＰＮ（Internet Protocol-Virtual Private Network）などの専用回線網で実現されてもよい。また、ネットワーク５００は、インターネット、電話回線網、衛星通信網などの公衆回線網や、Ｅｔｈｅｒｎｅｔ（登録商標）を含む各種のＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などで実現されてもよい。さらに、ネットワーク５００は、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの無線通信網で実現されてもよい。
以上、本実施形態に係る医療用情報処理システムのシステム構成例について説明した。なお、図１を参照して説明した上記のシステム構成はあくまで一例であり、本実施形態に係る医療用情報処理システムのシステム構成は係る例に限定されない。例えば、マッチングサーバ１００の機能の全部または一部は、管理サーバ２００に備えられてもよい。また、逆に管理サーバ２００の機能の全部または一部は、マッチングサーバ１００に備えられてもよい。本実施形態に係る医療用情報処理システムのシステム構成は、仕様や運用に応じて柔軟に変形可能である。
（１．２．装置の機能構成）
続いて、図２～図４を参照して、医療用情報処理システムに備えられる装置の機能構成例について説明する。
（マッチングサーバ１００の機能構成例）
まず、図２を参照して、マッチングサーバ１００の機能構成例について説明する。図２に示すように、マッチングサーバ１００は、通信部１１０と、処理部１２０と、記憶部１３０と、を備える。また、処理部１２０は、認証部１２１と、マッチング部１２２と、出力部１２３と、を備える。
通信部１１０は、外部装置と通信する機能構成である。例えば、通信部１１０は、ユーザ端末４００から検査手配リクエスト、ユーザ情報、およびユーザ認証に使用される入力情報などを受信する（すなわち、通信部１１０は、検査手配リクエストおよびユーザ情報を取得する取得部として機能する）。そして、通信部１１０は、ユーザ端末４００に対して、検査リソースとのマッチング処理の結果、検査リソースの手配処理の結果、ユーザ認証の結果などを送信する。また、通信部１１０は、管理サーバ２００に対して手配対象の検査リソースに関する情報を送信する。そして、通信部１１０は、管理サーバ２００から検査リソースの手配結果などを受信する。なお、通信部１１０が通信する情報および通信するケースはこれらに限定されない。
処理部１２０は、マッチングサーバ１００が行う処理全般を統括的に制御する機能構成である。例えば、処理部１２０は、各機能構成の起動や停止を制御することができる。なお、処理部１２０の処理内容は特に限定されない。例えば、処理部１２０は、各種サーバ、汎用コンピュータ、ＰＣ（Personal Computer）、またはタブレットＰＣなどにおいて一般的に行われる処理（例えばＯＳ（Operating System）に関する処理など）を制御してもよい。
認証部１２１は、ユーザ認証を行う機能構成である。より具体的には、ユーザ端末４００からユーザ認証に使用される入力情報が提供された場合、認証部１２１は当該入力情報を用いて所定のユーザ認証処理を行う。なお、ユーザ認証処理の内容は特に限定されない。例えば、認証部１２１は、ユーザの識別情報（例えばＩＤなど）およびパスワードを用いる認証、またはユーザの生体情報を用いる生体認証などを行う。これによって、認証部１２１は、権限を有しない第三者からのアクセスを防ぐことができる。生体情報は、例えば指紋情報や静脈情報、顔情報である。
マッチング部１２２は、検査手配リクエストおよびユーザ情報に基づいて、ユーザと検査リソースとをマッチングする機能構成である。より具体的には、マッチング部１２２は、検査手配リクエストに含まれる検査種別情報に基づいて、当該検査種別に該当する検査を実施可能な検査リソースを記憶部１３０から抽出する。例えば、記憶部１３０は、各検査リソースとそれらの検査種別情報とを紐付けたテーブルを有しており、マッチング部１２２は、当該テーブルを用いて検査手配リクエストに含まれる検査種別情報と一致する情報と紐づけられている検査リソースを抽出する。また、検査手配リクエストが検査種別情報以外の情報を含んでいる場合、マッチング部１２２は、当該情報に基づいてマッチング処理を行ってもよい。例えば、検査手配リクエストが検査の優先度（または緊急度など）を含む場合において当該優先度が高い値を示している場合、マッチング部１２２は、他の検査手配リクエストよりも優先的にマッチング処理を行ってもよい（例えば割り込んでマッチング処理を行ったり、他の検査手配リクエストによって既にマッチングされた検査リソースへの変更（交換）を行ったりしてもよい）。
さらにマッチング部１２２は、検査手配リクエストに基づいて抽出した検査リソースの中から、ユーザ情報に基づいてより適切な検査リソースを抽出する。例えば、ユーザの位置情報（例えば緯度、経度、高度など）がユーザ情報に含まれる場合、マッチング部１２２は、ユーザの位置から所定の距離以内に位置する検査リソースを抽出してもよいし、ユーザの位置に近い順に所定数の検査リソースを抽出してもよいし、ユーザの位置に最も近い検査リソースを抽出してもよい。なお、検査リソースの位置は、検査リソースの位置情報として予め記憶部１３０に記憶されている。また、ユーザが過去に受けた検査に関する履歴情報（例えばユーザが検査を受けた日時、期間、検査内容など）がユーザ情報に含まれる場合、マッチング部１２２は、ユーザが過去に検査を受けたことのある検査リソースを抽出してもよいし、ユーザが頻繁に検査を受けている検査リソースを抽出してもよい。また、ユーザが今後受ける検査に関する設定情報（例えば検査に関するユーザの希望事項、必要事項、制限事項など。なお、当該情報は、検査手配リクエストに含まれていてもよい）がユーザ情報に含まれる場合、マッチング部１２２は、当該設定情報を抽出条件として使用してもよい。例えば、ユーザが検査を受けたい地域や日時などが設定されている場合、マッチング部１２２は、当該地域や日時などを検査リソースの抽出条件として使用してもよい。マッチング部１２２は、これらの抽出処理により、ユーザが利用しやすい検査リソースを抽出することができる。なお、上記では、マッチング部１２２が検査手配リクエストに基づいて検査リソースを抽出した後に、さらにユーザ情報に基づいて検査リソースを抽出する旨を説明したところ、抽出処理の順番は特に限定されない。
なお、マッチング部１２２は、検査手配リクエストおよびユーザ情報だけでなく、その他の情報にも基づいてマッチング処理を行ってもよい。例えば、マッチング部１２２は、検査リソースに対する評価や口コミなどの情報に基づいてマッチング処理を行ってもよい。より具体的には、マッチング部１２２は、より評価の高い検査リソースを優先的にマッチングしてもよいし、検査手配リクエストに含まれる優先度（または緊急度など）が高いほど、より評価の高い検査リソースをマッチングしてもよい。また、マッチング部１２２は、検査の内容や検査リソースに基づいてマッチング処理を行ってもよい。より具体的には、検査の内容が血液検査であり、検査リソースが使用期間の制限を有する血液検査キット（例えば使用期間が発送日から２日以内である血液検査キットなど）である場合、マッチング部１２２は、当該使用期間に基づいてユーザが十分余裕をもって検査可能であると考えられる検査リソースとのマッチングを行ってもよい。マッチング部１２２によるマッチング処理の内容は上記に限定されず、医療用情報処理システムの仕様や運用に応じて柔軟に変更可能である。
出力部１２３は、各種情報を外部装置に対して出力する機能構成である。また、上記で説明したマッチング部１２２および当該出力部１２３は、相互に連携して処理をすることにより、検査リソースをユーザに提示する提示部として機能することに留意されたい。例えば、マッチング部１２２によってユーザと検査リソースとのマッチングが行われた場合、出力部１２３は、マッチング処理結果をユーザ端末４００に対して出力する。このとき、マッチングされた検査リソースが複数存在する場合、出力部１２３は、所定の方法で各検査リソースをユーザ端末４００に対して出力する。例えば、出力部１２３は、ユーザと検査リソースとの離隔距離が近い順に各検査リソースを出力することなどが可能である。また、出力部１２３は、検査リソースに関する各種情報（例えば検査リソースの内容、検査リソースの予約可能日時、検査リソースの到着予定日時（検査リソースがユーザの位置まで移動可能な検査装置である場合など）、検査リソースの送達予定日時（検査リソースが検査キットである場合など）、またはユーザが過去に受けた検査履歴など）も併せてユーザ端末４００に対して出力してもよい。なお、ユーザが過去に受けた検査履歴が併せて出力される場合、出力部１２３は、過去の検査履歴がある検査リソースについて所定のアイコンを出力することが望ましい。そして、出力部１２３は、ユーザが当該アイコンを選択すると過去の検査履歴が表示されるように出力を行うことが望ましい。
また、管理サーバ２００によって検査リソースの手配が行われた場合、出力部１２３は、手配結果をユーザ端末４００に対して出力する。また、認証部１２１によってユーザ認証が行われた場合、出力部１２３は、当該ユーザ認証の結果をユーザ端末４００に対して出力する。なお、出力部１２３が出力する情報および出力するケースはこれらに限定されない。また、出力部１２３による出力方法は出力先の装置の仕様（または機能など）に応じて柔軟に変更され得る。例えば、出力部１２３は、出力先の装置が備える機構（例えば表示機構、音声出力機構、または発光機構など）に応じて出力方法を変更してもよい。
記憶部１３０は、各種情報を記憶する機能構成である。例えば、記憶部１３０は、マッチング処理に使用される、各検査リソースとそれらの検査種別情報とを紐付けたテーブルなどを有している。また、記憶部１３０は、ユーザ端末４００や管理サーバ２００などから提供された情報（例えば検査手配リクエスト、ユーザ情報、ユーザ認証に使用される入力情報、または検査リソースの手配結果など）、マッチングサーバ１００の各機能構成による処理結果など（例えばユーザ認証結果、またはマッチング処理結果など）を記憶する。また、記憶部１３０は、マッチングサーバ１００の各機能構成によって使用されるプログラムやパラメータなどを記憶する。なお、記憶部１３０が記憶する情報の内容はこれらに限定されない。
以上、マッチングサーバ１００の機能構成例について説明した。なお、図２を用いて説明した上記の機能構成はあくまで一例であり、マッチングサーバ１００の機能構成は係る例に限定されない。例えば、マッチングサーバ１００は、図２に示す機能構成の全てを必ずしも備えなくてもよい。また、マッチングサーバ１００の機能構成は、仕様や運用に応じて柔軟に変形可能である。
（管理サーバ２００の機能構成例）
続いて、図３を参照して、管理サーバ２００の機能構成例について説明する。図３に示すように、管理サーバ２００は、通信部２１０と、処理部２２０と、記憶部２３０と、を備える。また、処理部２２０は、認証部２２１と、管理部２２２と、手配部２２３と、出力部２２４と、を備える。
通信部２１０は、外部装置と通信する機能構成である。例えば、通信部２１０は、マッチングサーバ１００から手配対象の検査リソースに関する情報を受信する。そして、通信部２１０は、マッチングサーバ１００に対して、検査リソースの手配結果を送信する。また、通信部２１０は、ユーザ端末４００から検査成果物の出力に関する入力情報や、ユーザ認証に使用される入力情報などを受信する。そして、通信部２１０は、ユーザ端末４００に対して、検査成果物の出力結果や、ユーザ認証の結果などを送信する。また、通信部２１０は、検査端末３００から検査成果物などを受信する。なお、通信部２１０が通信する情報および通信するケースはこれらに限定されない。また、通信部２１０は、個人情報保護の観点から、ユーザの個人情報または個人情報を含む検査成果物を取得する際は、ユーザがその取得に対して同意しているかを示す同意情報の有無を確認し、同意情報が有る場合に限りその取得をできてもよい。
処理部２２０は、管理サーバ２００が行う処理全般を統括的に制御する機能構成である。例えば、処理部２２０は、各機能構成の起動や停止を制御することができる。なお、処理部２２０の処理内容は特に限定されない。例えば、処理部２２０は、各種サーバ、汎用コンピュータ、ＰＣ、またはタブレットＰＣなどにおいて一般的に行われる処理（例えばＯＳに関する処理など）を制御してもよい。
認証部２２１は、ユーザ認証を行う機能構成である。より具体的に説明すると、ユーザ端末４００は、マッチングサーバ１００を介することなく直接管理サーバ２００へアクセスする場合があり、認証部２２１は、この場合においてユーザ認証を行う。なお、認証部２２１によるユーザ認証処理の内容は、上記で説明したマッチングサーバ１００の認証部１２１と同様であり得るため、説明を省略する。
管理部２２２は、検査成果物および検査リソースを管理する機能構成である。検査成果物の管理についてより具体的に説明すると、検査成果物が検査端末３００から提供された場合、管理部２２２は、当該検査成果物をユーザ情報に紐づけて所定のフォーマットで記憶部２３０に格納していく。また、管理部２２２は、所定の期間より古い検査成果物を削除したり、最新の検査成果物によって過去に行われた同一検査の検査成果物を上書きしたりしてもよい。また、検査成果物が検査端末３００から提供された場合、管理部２２２は、検査内容などに基づいて料金を計算し、ユーザに対して当該料金の請求処理を行う。例えば、クレジットカード情報などがユーザ情報として登録されている場合、管理部２２２は、当該情報に基づいてクレジットカード決済処理などを行う。また、ユーザが保険会社との連携を選択している場合において、検査成果物が検査端末３００から提供された場合、管理部２２２は、検査成果物が提供された旨や検査成果物自体を保険会社の装置に対して提供してもよい。これによって、ユーザは検査頻度や検査成果物を保険会社に通知することができるため、所定の保険サービス（例えば保険料の低減など）を受けることができる。
検査リソースの管理についてより具体的に説明すると、検査リソースが稼働する予定に関する情報（または検査リソースの稼働状況に関する情報）が検査リソース自体、または検査リソースを管理する装置など（例えば医療機関のサーバなど）から提供された場合、管理部２２２は、当該情報を所定のフォーマットで記憶部２３０に格納していく。
手配部２２３は、検査リソースの手配を行う機能構成である。より具体的には、ユーザによる選択などによって検査リソースが決定された場合、手配部２２３は、当該検査リソースに対して検査を予約する。例えば、手配部２２３は、検査リソース自体、または検査リソースが有する所定の装置（例えば検査リソースである医療機関が有するサーバなど）に対して、検査リソースの手配を希望する旨の情報を送信することによって検査を予約する。
「検査リソースの手配を希望する旨の情報」には、例えば、検査を受けるユーザのユーザ情報（例えば属性情報など）、ユーザの識別情報、ユーザの位置情報、検査の日時、検査の場所（例えば検査リソースがユーザの位置まで移動可能な検査装置などである場合）、または検査の内容などの情報が含まれる。なお、検査リソースの手配を希望する旨の情報に含まれる情報はこれらに限定されない。また、これらの情報はユーザによる入力に基づいて設定されてもよいし、ユーザ端末４００や管理サーバ２００の機能によって自動的に設定されてもよい。また、検査リソースの手配を希望する旨の情報に、ユーザ情報などの個人情報が含まれる場合には、事前にユーザに承諾を得る処理が行われることが望ましい。
出力部２２４は、各種情報を外部装置に対して出力する機能構成である。例えば、手配部２２３によって検査リソースの手配が行われた場合、出力部２２４は、検査リソースの手配結果をマッチングサーバ１００に対して出力する。また、認証部２２１によってユーザ認証が行われた場合、出力部２２４は、当該ユーザ認証の結果をユーザ端末４００に対して出力する。
また、出力部２２４は、ユーザによる直接的または間接的な入力に基づいてユーザ所望の装置に対して検査成果物を出力する。例えば、出力部２２４は、検査成果物に基づく診断、治療、手術、またはユーザの症状の推定を行う機関の装置に対して検査成果物を出力する。「ユーザによる直接的な入力」とは、例えば、ユーザが検査成果物のダウンロード（ユーザ端末４００への保存）を選択する場合などを含む。また、「ユーザによる間接的な入力」とは、例えば、ユーザが診断サービス提供者（例えば機械学習を利用した症状の推定を行う診断サービス提供用アプリケーションなどを含む）の要請を受けて検査成果物のアップロード（診断サービス提供者のサーバへの保存）を選択する場合などを含む。なお、出力部２２４は、検査成果物以外の情報（例えばユーザ情報など）も併せて出力してもよい。また、出力部２２４は、出力先に応じて出力する情報を制御してもよい。例えば、出力先がユーザ端末４００以外の装置である場合、出力部２２４は、ユーザ情報などの個人情報を出力しなくてもよい。また、個人情報保護の観点から、ユーザが診断サービス提供者に検査成果物をアップロードする場合においては、出力部２２４は、検査成果物のアップロードについて同意する否かをユーザに選択させる同意処理を行うことで、ユーザが検査成果物のアップロードについて同意したことを示す同意情報を生成し、診断サービス提供者に同意情報を提供することが好ましい。
また、ユーザ所望の装置に対する検査成果物の出力が行われた場合、出力部２２４は、出力結果をユーザ端末４００に対して出力する。なお、出力部２２４が出力する情報および出力するケースはこれらに限定されない。また、出力部２２４による出力方法は出力先の装置の仕様（または機能など）に応じて柔軟に変更され得る。例えば、出力部２２４は、出力先の装置が備える機構（例えば表示機構、音声出力機構、または発光機構など）に応じて出力方法を変更してもよい。
記憶部２３０は、各種情報を記憶する機能構成である。例えば、記憶部２３０は、ユーザ情報に紐づけられた検査成果物や、検査リソースが稼働する予定に関する情報（または検査リソースの稼働状況に関する情報）を所定のフォーマットで記憶する。また、記憶部２３０は、マッチングサーバ１００、検査端末３００、またはユーザ端末４００などから提供された情報（例えばユーザ認証に使用される入力情報など）、管理サーバ２００の各機能構成による処理結果など（例えばユーザ認証結果、または検査リソースの手配結果など）を記憶する。また、記憶部２３０は、管理サーバ２００の各機能構成によって使用されるプログラムやパラメータなどを記憶する。なお、記憶部２３０が記憶する情報の内容はこれらに限定されない。
以上、管理サーバ２００の機能構成例について説明した。なお、図３を用いて説明した上記の機能構成はあくまで一例であり、管理サーバ２００の機能構成は係る例に限定されない。例えば、管理サーバ２００は、図３に示す機能構成の全てを必ずしも備えなくてもよい。また、管理サーバ２００の機能構成は、仕様や運用に応じて柔軟に変形可能である。
（ユーザ端末４００の機能構成例）
続いて、図４を参照して、ユーザ端末４００の機能構成例について説明する。図４に示すように、ユーザ端末４００は、通信部４１０と、処理部４２０と、記憶部４３０と、入力部４４０と、表示部４５０と、を備える。また、処理部４２０は、生成部４２１を備える。
通信部４１０は、外部装置と通信する機能構成である。例えば、通信部４１０は、マッチングサーバ１００に対して検査手配リクエスト、ユーザ情報、およびユーザ認証に使用される入力情報などを送信する。そして、通信部４１０は、マッチングサーバ１００から検査リソースとのマッチング処理の結果、検査リソースの手配処理の結果、ユーザ認証の結果などを受信する。また、通信部４１０は、管理サーバ２００に対して検査成果物の出力に関する入力情報や、ユーザ認証に使用される入力情報などを送信する。そして、通信部４１０は、管理サーバ２００から検査成果物の出力結果や、ユーザ認証の結果などを受信する。なお、通信部４１０が通信する情報および通信するケースはこれらに限定されない。
処理部４２０は、ユーザ端末４００が行う処理全般を統括的に制御する機能構成である。例えば、処理部４２０は、各機能構成の起動や停止を制御することができる。なお、処理部４２０の処理内容は特に限定されない。例えば、処理部４２０は、各種サーバ、汎用コンピュータ、ＰＣ、またはタブレットＰＣなどにおいて一般的に行われる処理（例えばＯＳに関する処理など）を制御してもよい。
生成部４２１は、問診アプリケーションに関する処理を行い、検査手配リクエストを生成する機能構成である。ここで、「問診アプリケーション」とは、医者などの代りに問診を行うアプリケーションを指し、ユーザ端末４００（および必要に応じてユーザ端末４００と連携する他の装置）にインストールされる。なお、問診アプリケーションは、ユーザによる入力を解析することで問診を行い検査手配リクエストの生成を行うところ、所定の人工知能（ＡＩ：Artificial Intelligence）を使用してこれらの処理を実現する。より具体的には、生成部４２１は、ユーザによって入力された情報（例えばテキスト情報、患部が撮影された静止画像情報や動画情報など）を、問診アプリケーションが有する人工知能に対して入力することで、問診結果や検査手配リクエストの出力を受ける。当該人工知能が有する機能は、例えば、ニューラルネットワーク、回帰モデルなどの機械学習手法、または統計的手法などに基づいて実現され得る。以降、本実施形態に係る問診アプリケーションを「問診ＡＩ」と呼称する場合がある。問診ＡＩの機能やユーザインタフェースの具体例については後述する。なお、問診アプリケーションの機能を実現する手段は、決定木やランダムフォレスト、線形回帰、ベイズモデル等による手法でもよい。
記憶部４３０は、各種情報を記憶する機能構成である。例えば、記憶部４３０は、マッチングサーバ１００や管理サーバ２００などから提供された情報（例えばマッチング処理結果、検査リソースの手配結果、ユーザ認証結果、または検査成果物の出力結果など）、ユーザ端末４００の各機能構成による処理結果など（例えば問診結果、または検査手配リクエストなど）を記憶する。また、記憶部４３０は、ユーザ端末４００の各機能構成によって使用されるプログラムやパラメータなどを記憶する。なお、記憶部４３０が記憶する情報の内容はこれらに限定されない。
入力部４４０は、ユーザによる入力を受ける機能構成である。例えば、入力部４４０はマウス、キーボード、タッチパネル、ボタン、スイッチ、マイクロフォン、またはカメラなどの入力装置を備えており、ユーザがこれらの入力装置を用いることによって、所望の情報を入力することができる。また、入力部４４０は、位置センサ、加速度センサ、またはジャイロセンサなどの各種センサ装置を備えており、例えば位置センサによってユーザの位置情報（例えば緯度、経度、高度など）が入力され得る。なお、入力部４４０が備える入力装置およびセンサ装置は特に限定されない。
表示部４５０は、各種情報を表示する機能構成である。より具体的には、表示部４５０は、ディスプレイなどの表示装置や、プロジェクタなどの投影装置などを備えており、これらの装置を用いることによって、自装置の処理結果、またはマッチングサーバ１００や管理サーバ２００から出力された情報などをユーザに提供することができる。なお、表示部４５０が備える装置は上記に限定されない。
以上、ユーザ端末４００の機能構成例について説明した。なお、図４を用いて説明した上記の機能構成はあくまで一例であり、ユーザ端末４００の機能構成は係る例に限定されない。例えば、ユーザ端末４００は、図４に示す機能構成の全てを必ずしも備えなくてもよい。また、ユーザ端末４００の機能構成は、仕様や運用に応じて柔軟に変形可能である。
（１．３．処理の流れ）
上記では、医療用情報処理システムに備えられる装置の機能構成例について説明した。続いて、図５～図７を参照して、各装置による処理の流れの例について説明する。
（検査リソースの手配に至るまでの処理の流れの例）
まず、図５および図６を参照して、検査リソースの手配に至るまでの処理の流れの例について説明する。
ステップＳ１０００では、ユーザがユーザ端末４００の入力部４４０を用いて、医療用情報処理システムへのログインのための入力を行う。例えば、ユーザは、ユーザの識別情報（例えばＩＤなど）およびパスワードを入力したり、生体認証のための生体情報を入力したりする。なお、ユーザ端末４００の機能により、ログインのための入力操作が自動化されてもよい。ステップＳ１００４では、通信部４１０がユーザによって入力された入力情報をマッチングサーバ１００に対して送信する。例えば、通信部４１０は、ユーザの識別情報（例えばＩＤなど）およびパスワードがハッシュ化されたハッシュパス情報を入力情報として送信する。
ステップＳ１００８では、マッチングサーバ１００の認証部１２１が入力情報を用いて所定のユーザ認証処理を行う。例えば、認証部１２１は、入力情報として提供されたハッシュパス情報と、事前に登録されたハッシュパス情報とが一致するか否かに基づいてユーザ認証を行う。ステップＳ１０１２では、出力部１２３が通信部１１０を介してユーザ認証結果をユーザ端末４００に対して出力する。
ユーザ認証が成功した場合、ステップＳ１０１６にて、ユーザ端末４００の表示部４５０が問診ＡＩのメニューを表示する。ステップＳ１０２０では、生成部４２１がユーザによる入力に基づいて検査手配リクエストを生成する。ステップＳ１０２４では、通信部４１０は、検査手配リクエストおよびユーザ情報をマッチングサーバ１００に対して送信する。
ステップＳ１０２８では、マッチングサーバ１００のマッチング部１２２が検査手配リクエストおよびユーザ情報に基づいて、ユーザと検査リソースとをマッチングする。ステップＳ１０３２では、出力部１２３が通信部１１０を介してマッチング処理結果をユーザ端末４００に対して出力する。例えば、マッチング処理の結果として２以上の検査リソースが抽出された場合、出力部１２３は、候補となる各検査リソースに関する情報をユーザ端末４００に対して出力する。
ステップＳ１０３６では、ユーザ端末４００の表示部４５０がマッチング処理結果である検査リソースを表示する。ステップＳ１０４０では、ユーザが入力部４４０を用いて、検査リソースを選択する。なお、マッチング処理の結果として提供された検査リソースが１つである場合、ユーザは入力部４４０を用いて当該検査リソースによる検査を受けるか否かを選択する。
ステップＳ１０４４では、通信部４１０がユーザによって選択された検査リソースに関する情報（図中では「検査リソース選択情報」と記載）をマッチングサーバ１００に対して送信する。ステップＳ１０４８では、マッチングサーバ１００の出力部１２３が通信部１１０を介して検査リソース選択情報を管理サーバ２００に対して出力する。
ステップＳ１０５２では、管理サーバ２００の手配部２２３が検査リソース選択情報に基づいて検査リソースを手配する。ステップＳ１０５６では、出力部２２４が通信部２１０を介して検査リソースの手配結果をマッチングサーバ１００に対して出力する。ステップＳ１０６０では、マッチングサーバ１００の出力部１２３が通信部１１０を介して検査リソースの手配結果をユーザ端末４００に対して出力する。ステップＳ１０６４では、ユーザ端末４００の表示部４５０が検査リソースの手配結果を表示することで、検査リソースの手配に至るまでの一連の処理が終了する。
（検査成果物の出力処理の流れの例）
続いて、図７を参照して、検査成果物の出力処理の流れの例について説明する。
ステップＳ１１００では、検査の終了後に検査端末３００が検査成果物を取得する。ステップＳ１１０４では、検査端末３００が検査成果物を管理サーバ２００に対して送信する。ステップＳ１１０８では、管理サーバ２００の管理部２２２が、当該検査成果物をユーザ情報に紐づけて所定のフォーマットで記憶部２３０に格納することで検査成果物を管理する。
その後、ユーザが検査成果物をもとに様々な行動（例えば診断サービスの利用など）を行おうとした場合、ステップＳ１１１２にて、ユーザがユーザ端末４００の入力部４４０を用いて、医療用情報処理システムへのログインのための入力を行う。ステップＳ１１１６では、通信部４１０がユーザによって入力された入力情報を管理サーバ２００に対して送信する。
ステップＳ１１２０では、管理サーバ２００の認証部２２１が入力情報を用いて所定のユーザ認証処理を行う。ステップＳ１１２４では、出力部２２４が通信部２１０を介してユーザ認証結果をユーザ端末４００に対して出力する。
ユーザ認証が成功した場合、ステップＳ１１２８にて、ユーザ端末４００の表示部４５０が所定のメニューを表示する。なお、当該メニューの表示は問診ＡＩによって実現されてもよい。ステップＳ１１３２では、ユーザが入力部４４０を用いて、出力対象となる検査成果物および出力先を入力する。
ステップＳ１１３６では、通信部４１０がユーザによって入力された入力情報を管理サーバ２００に対して送信する。ステップＳ１１４０では、管理サーバ２００の出力部２２４が、入力情報に基づいて検査成果物をユーザ所望の装置に対して出力する。ステップＳ１１４４では、出力部２２４が通信部２１０を介して検査成果物の出力結果をユーザ端末４００に対して出力する。ステップＳ１１４８では、ユーザ端末４００の表示部４５０が検査成果物の出力結果を表示することで、一連の検査成果物の出力処理が終了する。
なお、図５～図７のシーケンス図における各ステップは、必ずしも記載された順序に沿って時系列に処理される必要はない。すなわち、シーケンス図における各ステップは、記載された順序と異なる順序で処理されても、並列的に処理されてもよい。
＜２．第２の実施形態＞
（２．１．システム構成）
上記では、本開示の第１の実施形態について説明した。続いて、本開示の第２の実施形態について説明する。
まず、図８を参照して、第２の実施形態に係る医療用情報処理システムのシステム構成例について説明する。図８に示すように、本実施形態に係る医療用情報処理システムは、新たに診断サーバ６００と、診断ＡＩ７００と、を備える。なお、その他の装置については第１の実施形態と同一であり得るため、説明を省略する。
（診断サーバ６００）
診断サーバ６００は、診断ＡＩ７００を用いて行われるユーザの症状の推定処理を制御する医療用情報処理装置である。より具体的には、管理サーバ２００がユーザによる入力に基づいて検査成果物を診断サーバ６００に対して出力した場合、診断サーバ６００は、当該検査成果物を診断ＡＩ７００へ入力することで、症状の推定結果の出力を受ける。
そして、診断サーバ６００は、検査成果物の識別情報（例えば検査ＩＤなど）を用いて当該推定結果と検査成果物を紐づけることで総合結果情報を生成する。さらに、診断サーバ６００は、総合結果情報を所定の装置（例えばユーザ端末４００など）に対して提供する。これによって、ユーザは症状の推定結果を取得することができる。
（診断ＡＩ７００）
診断ＡＩ７００は、診断サーバ６００から提供された検査成果物に基づいてユーザの症状の推定を行う推定部として機能する機能構成である（なお、当該診断ＡＩ７００を用いる診断サーバ６００が推定部として機能させても良い）。より具体的には、診断ＡＩ７００は、所定の医療用情報処理装置にインストールされるアプリケーションであり、人工知能によってユーザの症状の推定を行う。また、診断ＡＩ７００は、ユーザの症状の推定結果に基づいて医療機関での受診や薬の摂取などの提案を併せて行ってもよい。
診断ＡＩ７００（または問診ＡＩ）に使用される人工知能が有する機能は、例えば、ニューラルネットワーク、回帰モデルなどの機械学習手法、または統計的手法に基づいて実現され得る。例えば、機械学習手法の場合、医師による診断結果と検査成果物を紐づけた学習データまたは問診結果と問診内容を紐づけた学習データが、ニューラルネットワークまたは回帰モデルを用いた所定の計算モデルに入力されることで学習が行われ、生成されたパラメータを有する処理モデルを有する処理回路によって、当該人工知能の機能が実現される。なお、診断ＡＩ７００は、診断サーバ６００を介することなく直接管理サーバ２００から検査成果物を取得してもよい。また、診断ＡＩ７００は、診断サーバ６００に備えられてもよいし、上記で説明した問診ＡＩと同一のアプリケーションであってもよい（例えば診断ＡＩ７００は、問診ＡＩと同一のアプリケーションでありユーザ端末４００に備えられていてもよい）。
（２．２．装置の機能構成）
上記では、第２の実施形態に係る医療用情報処理システムのシステム構成例について説明した。続いて、図９を参照して、本実施形態に係る診断サーバ６００の機能構成例について説明する。なお、その他の装置の機能構成例については第１の実施形態と同一であり得るため、説明を省略する。
図９に示すように、診断サーバ６００は、通信部６１０と、処理部６２０と、記憶部６３０と、を備える。また、処理部６２０は、管理部６２１と、診断ＡＩ連携部６２２と、出力部６２３と、を備える。
通信部６１０は、外部装置と通信する機能構成である。例えば、通信部６１０は、管理サーバ２００から検査成果物などを受信する。そして、通信部６１０は、診断ＡＩ７００に対して検査成果物を送信することで、診断ＡＩ７００からユーザの症状の推定結果を受信する。その後、通信部６１０は、例えばユーザ端末４００などに対して、当該推定結果を用いて生成された総合結果情報を送信する。なお、通信部６１０が通信する情報および通信するケースはこれらに限定されない。
処理部６２０は、診断サーバ６００が行う処理全般を統括的に制御する機能構成である。例えば、処理部６２０は、各機能構成の起動や停止を制御することができる。なお、処理部６２０の処理内容は特に限定されない。例えば、処理部６２０は、各種サーバ、汎用コンピュータ、ＰＣ、またはタブレットＰＣなどにおいて一般的に行われる処理（例えばＯＳ（Operating
System）に関する処理など）を制御してもよい。
管理部６２１は、総合結果情報を管理する機能構成である。より具体的には、ユーザの症状の推定結果が診断ＡＩ７００から提供された場合、管理部６２１は、検査成果物の識別情報（例えば検査ＩＤなど）を用いて当該推定結果と検査成果物を紐づけることで総合結果情報を生成する。このとき、管理部６２１は、診断ＡＩ７００や診断に関する各種情報（例えば診断ＡＩ７００の名称、種類、バージョン情報、または診断が行われた日時など）も総合結果情報に含めてもよい。すなわち、管理部６２１は、ユーザの症状の推定結果がどのような診断ＡＩ７００と検査成果物に基づいて行われたものであるか認識可能な状態で管理を行うことができる。
そして、管理部６２１は、総合結果情報を所定のフォーマットで記憶部６３０に格納していく。また、管理部６２１は、所定の期間より古い総合結果情報を削除したり、最新の総合結果情報によって過去に行われた同一検査の総合結果情報を上書きしたりしてもよい。また、ユーザの症状の推定結果が診断ＡＩ７００から提供された場合、管理部６２１は、推定結果などに基づいて料金を計算し、ユーザに対して当該料金の請求処理を行う。例えば、クレジットカード情報などがユーザ情報として登録されている場合、管理部６２１は、当該情報に基づいてクレジットカード決済処理などを行う。また、ユーザが保険会社との連携を選択している場合において、ユーザの症状の推定結果が診断ＡＩ７００から提供された場合、管理部６２１は、ユーザの症状の推定結果が提供された旨や総合結果情報を保険会社の装置に対して提供してもよい。これによって、ユーザは診断頻度や総合結果情報を保険会社に通知することができるため、所定の保険サービス（例えば保険料の低減など）を受けることができる。
診断ＡＩ連携部６２２は、ユーザの症状の推定処理において診断ＡＩ７００と連携を行う機能構成である。より具体的には、管理サーバ２００から検査成果物が提供された場合、診断ＡＩ連携部６２２は、通信部６１０を介して検査成果物を診断ＡＩ７００へ入力する。その後、診断ＡＩ７００によるユーザの症状の推定処理が終了した場合、診断ＡＩ連携部６２２は、通信部６１０を介してユーザの症状の推定結果を受ける。なお、仮に２以上の診断ＡＩ７００が存在する場合、診断ＡＩ連携部６２２は、症状の推定処理に使用する診断ＡＩ７００を選択してもよい。例えば、診断ＡＩ連携部６２２は、検査や検査リソースの内容、検査の優先度（または緊急度など）、検査の結果、同一ユーザについて過去に使用された診断ＡＩ７００の履歴情報、今後使用される診断ＡＩ７００に関する設定情報（例えば診断ＡＩ７００に関するユーザの希望事項、必要事項、制限事項など）、または診断ＡＩ７００に対する評価や口コミなどの情報に基づいて症状の推定処理に使用する診断ＡＩ７００を選択してもよい。なお、診断ＡＩ連携部６２２による診断ＡＩ７００の選択方法はこれらに限定されず、医療用情報処理システムの仕様や運用に応じて柔軟に変更可能である。
出力部６２３は、各種情報を外部装置に対して出力する機能構成である。例えば、管理部６２１によって総合結果情報が生成された場合、出力部６２３は、当該総合結果情報をユーザ端末４００などに対して出力する。なお、総合結果情報の出力先はユーザ端末４００に限定されない。例えば、出力部６２３は、管理サーバ２００などに対して総合結果情報を出力することで、管理サーバ２００を介してユーザに総合結果情報を提供してもよい。また、出力部６２３による出力方法は出力先の装置の仕様（または機能など）に応じて柔軟に変更され得る。例えば、出力部６２３は、出力先の装置が備える機構（例えば表示機構、音声出力機構、または発光機構など）に応じて出力方法を変更してもよい。
記憶部６３０は、各種情報を記憶する機能構成である。例えば、記憶部６３０は、検査成果物や、ユーザの症状の推定結果などを記憶する。また、記憶部６３０は、診断サーバ６００の各機能構成によって使用されるプログラムやパラメータなどを記憶する。なお、記憶部６３０が記憶する情報の内容はこれらに限定されない。
以上、診断サーバ６００の機能構成例について説明した。なお、図９を用いて説明した上記の機能構成はあくまで一例であり、診断サーバ６００の機能構成は係る例に限定されない。例えば、診断サーバ６００は、図９に示す機能構成の全てを必ずしも備えなくてもよい。また、診断ＡＩ７００が医療機関での受診や薬の摂取などの提案も行う場合、診断サーバ６００は、医療機関での受診や薬の手配を行う機能を備えていてもよい（このとき、当該機能は、管理サーバ２００の手配部２２３が備えている機能と同一または類似であり得る）。また、診断サーバ６００の機能構成は、仕様や運用に応じて柔軟に変形可能である。
（２．３．処理の流れ）
上記では、本実施形態に係る診断サーバ６００の機能構成例について説明した。続いて、図１０を参照して、本実施形態に係る処理の流れの例について説明する。図１０は、ユーザへの総合結果情報の提供に関する処理の流れの例を示すシーケンス図である。
ステップＳ１２００では、管理サーバ２００の出力部２２４が、通信部２１０を介して検査成果物を診断サーバ６００に対して出力する。ステップＳ１２０４では、診断サーバ６００の診断ＡＩ連携部６２２が、通信部６１０を介して検査成果物を診断ＡＩ７００に対して入力する。
ステップＳ１２０８では、診断ＡＩ７００が、入力された検査成果物を用いてユーザの症状の推定を行う。ステップＳ１２１２では、診断サーバ６００の診断ＡＩ連携部６２２が、通信部６１０を介して診断ＡＩ７００からユーザの症状の推定結果を受ける。ステップＳ１２１６では、管理部６２１が、検査成果物の識別情報（例えば検査ＩＤなど）を用いて当該推定結果と検査成果物を紐づけることで総合結果情報を生成し、管理する。
ステップＳ１２２０では、出力部６２３が、通信部６１０を介して総合結果情報をユーザ端末４００に対して出力する。ステップＳ１２２４では、ユーザ端末４００の表示部４５０が総合結果情報を表示することで、総合結果情報の提供に関する一連の処理が終了する。
なお、図１０のシーケンス図における各ステップは、必ずしも記載された順序に沿って時系列に処理される必要はない。すなわち、シーケンス図における各ステップは、記載された順序と異なる順序で処理されても、並列的に処理されてもよい。
＜３．ユーザインタフェース＞
上記では、本開示の第２の実施形態について説明した。続いて、図１１～図１７を参照して、問診ＡＩのユーザインタフェースの具体例について説明する。上記のとおり、問診ＡＩは、医者などの代りに問診を行うアプリケーションを指し、ユーザによる入力を解析することで問診を行い検査手配リクエストの生成を行う。以降では、検査手配リクエストの生成に関するものを含む各種ユーザインタフェースについて説明していく。なお、以下では、問診ＡＩがインストールされているユーザ端末４００がスマートフォンである場合を一例として説明する（もちろん、ユーザ端末４００はスマートフォンに限定されない）。
まず、ユーザは、図１１のＡに示すアイコン１０をタップなどの方法で選択することによって問診ＡＩを起動することができる。問診ＡＩが起動すると、図１１のＢに示すメニュー画面が表示される。
当該メニュー画面に表示されているボタン１１は、ユーザ情報の設定画面に遷移するために使用されるボタンである。ユーザは、ボタン１１の選択により遷移した後の画面にて、ユーザ情報として例えば、ユーザの属性情報（例えば氏名、性別、年齢、血液型、住所、電話番号、家族構成、職業、保険情報またはクレジットカード情報など）、またはユーザが今後受ける検査に関する設定情報など（例えば検査に関するユーザの希望事項、必要事項、または制限事項など）を設定することができる。
検査依頼ボタン１２は、検査リソースの手配の依頼時に使用されるボタンである。過去履歴ボタン１３は、過去の検査依頼（換言すると、検査リソースの手配の依頼）、または過去の検査成果物に関する履歴情報の確認時に使用されるボタンである。状態入力ボタン１４は、現在のユーザの状態（例えば身長、体重、体脂肪、ＢＭＩ、体温、視力、または聴力など）の入力時に使用されるボタンである。なお、現在のユーザの状態は、ウェアラブル装置などの外部装置との連携によって入力されてもよい。
ユーザは、図１２のＡ（図１１のＢと同一画面）に示す検査依頼ボタン１２をタップなどの方法で選択することによって図１２のＢに示す検査依頼画面に遷移することができる。ボタン１５は、ユーザが問診ＡＩによる問診（以降「ＡＩ問診」と呼称する）を受けて問診ＡＩが推薦する検査種別の中から所望の検査種別を選択する際に使用されるボタンである。ボタン１６は、ユーザがＡＩ問診を受けることなく検査種別を指定する際に使用されるボタンである。ボタン１７は、ユーザが過去に受けた検査種別を確認して同一の検査種別を選択する際に使用されるボタンである。このように、検査依頼の方法が複数設けられることによって、ユーザは、容易に検査種別を決定し、検査依頼を行うことができる。ボタン１８は、図１２のＡに示すメニュー画面に遷移するために使用されるボタンである。
図１３のＡに示す画面は、図１２のＢに示すようにユーザがボタン１５を選択した後に表示されるＡＩ問診のメニュー画面である。ボタン１９は、ユーザが画像情報（例えば患部の静止画像情報や動画情報など）に基づいてＡＩ問診を受ける場合に使用されるボタンである。ボタン２０は、ユーザが問診ＡＩからの質問に回答していくことによって問診を受ける場合に使用されるボタンである。ボタン２１は、ユーザが医師などの医療検査従事者に対して電話することで問診を受ける場合に使用されるボタンである。このように、問診方法が複数設けられることによって、ユーザは、症状などに応じて適切な問診を受けることができる。
ユーザは、図１３のＡに示すようにボタン１９をタップなどの方法で選択することによって図１３のＢに示す画像情報入力画面に遷移することができる。領域２２は、例えばユーザ端末４００に備えられているカメラによって生成された撮像画像情報を表示する領域である。ユーザは、領域２２を確認しながら所定のボタンを押下することなどによって患部が撮像された撮像画像情報を入力する。なお、ユーザ端末４００が、スマートフォンなどのようにユーザが片手で把持しながら撮像操作を行う装置である場合、撮像画像情報が動画情報である方が静止画像情報であるよりもユーザがより撮像操作を行い易いと考えられるため、撮像画像情報は動画情報であることが望ましい。領域２３は、問診ＡＩが撮像画像情報を解析した結果を表示する領域である。より具体的には、問診ＡＩは、入力された撮像画像情報を解析することで、患部の部位、状態、または深刻度などを推定するとともに、解析の進捗度や、解析結果の推定精度なども出力する。図１３のＢに示す例では、右腕（患部の部位）に４ｃｍの切り傷（患部の状態および深刻度）ができている旨、および解析率が８０％（解析の進捗度）であり認定確率が９２％（解析結果の推定精度）である旨が解析結果として表示されている。
図１４に示す画面は、図１３のＢに示した画面で撮像画像情報の入力および解析が終了した後に遷移する画面である。ボタン２４～ボタン２６は、図１３のＢの領域２３に表示されていた解析結果の修正時に使用されるボタンである。例えば、ユーザがボタン２４を選択することによって、修正候補を表示するプルダウンリスト２７が表示される。プルダウンリスト２７には、例えば、問診ＡＩによる撮像画像情報の解析によって出力された候補が表示される（図１４の例では、修正候補として左腕および右足が表示されている）。これによって、問診ＡＩの解析精度が低い場合であっても、ユーザは解析結果を適切に修正することができる。ＯＫボタン２８は、ユーザが解析結果の確認および修正を終えて内容を確定する際に使用されるボタンである。再撮影ボタン２９は、図１３のＢに示した画面に戻り、再び撮像画像情報の入力が行われる際に使用されるボタンである。電話ボタン３０は、ヘルプデスクへの操作方法の確認時などに使用されるボタンである。
図１５に示す画面は、図１４に示した画面でＯＫボタン２８がタップなどの方法で選択されることによって遷移する画面である。問診ＡＩは、撮像画像情報の解析結果（またはその修正内容）に基づいて推奨される検査種別を出力する（図１５の例では神経検査）。ボタン３２は、ユーザが当該検査種別の検査を受けることを希望する際に使用されるボタンである。ユーザがボタン３２を選択すると、問診ＡＩが検査手配リクエストを生成し、当該検査手配リクエストがマッチングサーバ１００に送信されることによってマッチング処理が行われる。ボタン３３は、ユーザが当該検査種別の検査を受けることを希望しない場合に使用されるボタンである。ユーザがボタン３３を選択すると、検査手配リクエストの生成およびマッチング処理は行われず、代わりに「早めに医療機関で受診することを推奨する」旨のテキスト情報などが表示される。
図１６に示す画面は、図１４に示した画面でＯＫボタン２８がタップなどの方法で選択されることによって遷移する画面であり、問診ＡＩによって緊急性が高いと判断された場合に表示される画面である。領域３４には、問診ＡＩによって推奨される医療機関が表示される。問診ＡＩは、問診結果やユーザ情報（例えばユーザの位置情報など）などに基づいて検査が可能であり、かつ、ユーザが短時間でアクセスすることが可能な医療機関を出力し、領域３４に表示する。なお、マッチングサーバ１００が問診ＡＩと連携することで推奨される医療機関を提供し、問診ＡＩが当該医療機関を領域３４に表示してもよい。ボタン３５は救急医療の要請時に使用されるボタンであり、ボタン３６はタクシーの配車要請時に使用されるボタンである。これらのボタンが設けられることで、ユーザは、推奨される医療機関へ迅速かつ容易にアクセスすることができる。
上記で説明した図１３のＡ（図１７のＡと同一画面）にて、ユーザがボタン２０を選択した場合、図１７のＢに示す画面が表示される。領域３７には、問診ＡＩからの質問が表示され（図１７のＢの例では、「症状を選んでください」という質問が表示されている）、ユーザは当該質問に回答していくことによって問診を受けることができる。結果ボタン３８は、最後の質問への回答が終了した場合に表示され、問診結果を表示する画面へ遷移するためのボタンである。結果ボタン３８が選択された場合、例えば、図１５の画面（緊急性が高い場合には図１６の画面）が表示される（その際、再撮影ボタン２９などは適宜省略される）。これによって、（撮像画像情報ではなく）問診ＡＩからの質問への回答に基づいても適切に検査手配リクエストが生成される。例えば、問診ＡＩは、ユーザへの回答の結果に基づいて症状がインフルエンザであることが推定された場合、ユーザが検査を希望すると、ユーザの位置情報に基づいて検査リソースからユーザの近くにある病院（インフルエンザを検査することが可能な病院）を抽出する。次に問診ＡＩは、ユーザにその病院の来院可能な時間帯を提示する。ユーザが時間帯を指定すると、問診ＡＩは推定した症状と選択された時間帯に基づき、検査手配リクエストを生成し、送信する。このとき、問診ＡＩは病院の予約ＤＢにアクセスして、予約可能な時間帯を取得し、予約可能な時間帯を来院可能な時間帯として提示するのが好ましい。
＜４．ハードウェア構成＞
上記では、問診ＡＩのユーザインタフェースの具体例について説明した。続いて、図１８を参照して、マッチングサーバ１００、管理サーバ２００、検査端末３００、ユーザ端末４００、および診断サーバ６００を具現する情報処理装置９００のハードウェア構成例について説明する。
図１８は、情報処理装置９００のハードウェア構成を示す図である。情報処理装置９００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９０１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９０３と、ホストバス９０４と、ブリッジ９０５と、外部バス９０６と、インタフェース９０７と、入力装置９０８と、出力装置９０９と、ストレージ装置（ＨＤＤ）９１０と、ドライブ９１１と、通信装置９１２と、を備える。
ＣＰＵ９０１は、演算処理装置および制御装置として機能し、各種プログラムに従って情報処理装置９００内の動作全般を制御する。また、ＣＰＵ９０１は、マイクロプロセッサであってもよい。ＲＯＭ９０２は、ＣＰＵ９０１が使用するプログラムや演算パラメータ等を記憶する。ＲＡＭ９０３は、ＣＰＵ９０１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一時記憶する。これらはＣＰＵバスなどから構成されるホストバス９０４により相互に接続されている。当該ＣＰＵ９０１、ＲＯＭ９０２およびＲＡＭ９０３の協働により、マッチングサーバ１００の処理部１２０、管理サーバ２００の処理部２２０、検査端末３００の処理部（図示なし）、ユーザ端末４００の処理部４２０、または診断サーバ６００の処理部６２０の各機能が実現される。
ホストバス９０４は、ブリッジ９０５を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バスなどの外部バス９０６に接続されている。なお、必ずしもホストバス９０４、ブリッジ９０５および外部バス９０６を分離構成する必要はなく、１つのバスにこれらの機能を実装してもよい。
入力装置９０８は、マウス、キーボード、タッチパネル、ボタン、マイクロフォン、スイッチ、レバー、またはカメラなどユーザが情報を入力するための入力手段と、ユーザによる入力に基づいて入力信号を生成し、ＣＰＵ９０１に出力する入力制御回路などから構成されている。情報処理装置９００のユーザは、当該入力装置９０８を操作することにより、各装置に対して各種情報を入力したり処理動作を指示したりすることができる。当該入力装置９０８により、ユーザ端末４００の入力部４４０の機能が実現される。
出力装置９０９は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）ディスプレイ装置、液晶ディスプレイ（ＬＣＤ）装置、ＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）装置およびランプなどの表示装置を含む。さらに、出力装置９０９は、スピーカおよびヘッドホンなどの音声出力装置を含む。表示装置は映像データ等の各種情報をテキストまたはイメージで表示する。一方、音声出力装置は、音声データ等を音声に変換して出力する。当該出力装置９０９により、ユーザ端末４００の表示部４５０の機能が実現される。
ストレージ装置９１０は、データ格納用の装置である。ストレージ装置９１０は、記憶媒体、記憶媒体にデータを記録する記録装置、記憶媒体からデータを読み出す読出し装置および記憶媒体に記録されたデータを削除する削除装置などを含んでもよい。ストレージ装置９１０は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）で構成される。このストレージ装置９１０は、ハードディスクを駆動し、ＣＰＵ９０１が実行するプログラムや各種データを格納する。当該ストレージ装置９１０によりマッチングサーバ１００の記憶部１３０、管理サーバ２００の記憶部２３０、検査端末３００の記憶部（図示なし）、ユーザ端末４００の記憶部４３０、または診断サーバ６００の記憶部６３０の各機能が実現される。
ドライブ９１１は、記憶媒体用リーダライタであり、情報処理装置９００に内蔵、あるいは外付けされる。ドライブ９１１は、装着されている磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記憶媒体９１３に記録されている情報を読み出して、ＲＡＭ９０３に出力する。また、ドライブ９１１は、リムーバブル記憶媒体９１３に情報を書き込むこともできる。
通信装置９１２は、例えば、通信網９１４に接続するための通信デバイス等で構成された通信インタフェースである。当該通信装置９１２によりマッチングサーバ１００の通信部１１０、管理サーバ２００の通信部２１０、検査端末３００の通信部（図示なし）、ユーザ端末４００の通信部４１０、または診断サーバ６００の通信部６１０の各機能が実現される。
＜５．まとめ＞
以上で説明してきたように、マッチングサーバ１００は、検査手配リクエストとユーザ情報とを取得し、これらの情報に基づいて、検査を実施可能な検査リソースをユーザに提示する。また、管理サーバ２００は、検査リソースによって検査が行われた後に検査端末３００から検査成果物を受信し、当該検査成果物をユーザ情報に紐づけて管理する。そして、管理サーバ２００は、ユーザによる入力に基づいて検査成果物をユーザ所望の装置に対して出力する。以上の一連の処理によって、ユーザは、検査成果物をもとに様々な行動をとることができる。例えば、ユーザは、検査成果物を自らの装置に対して出力することで自ら診断を行ったり、検査成果物を診断サービス提供者の装置に対して出力することで診断サービスを受けたりすることができる。これによって、例えば、軽微な症状のユーザによる来院などが抑制され、診断医の人件費などが低減するため、医療費の増大が抑制される。
また、問診ＡＩによって検査手配リクエストが生成されることによって、ユーザは容易に検査リソースの手配を要求することができる。また、診断ＡＩ７００が用いられることによってユーザの症状の推定がより容易かつ正確に行われる。
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
なお、以下のような構成も本開示の技術的範囲に属する。
（１）
医療に関する検査の種別を示す検査種別情報を含む検査手配リクエストと、ユーザに関する情報であるユーザ情報と、を取得する取得部と、
前記検査手配リクエストと前記ユーザ情報に基づいて、前記検査を実施可能な検査リソースを前記ユーザに提示する提示部と、
前記ユーザに対して行われた前記検査の成果物を前記ユーザ情報に紐づけて管理する管理部と、
前記ユーザによる入力に基づいて前記成果物を出力する出力部と、を備える、
医療用情報処理システム。
（２）
前記検査リソースは、前記成果物に基づく診断、治療、手術、または前記ユーザの症状の推定を行わない、
前記（１）に記載の医療用情報処理システム。
（３）
前記検査リソースは、医療検査機関、医療検査従事者、検査装置、または前記ユーザ自身に使用される検査キット、を含む、
前記（２）に記載の医療用情報処理システム。
（４）
前記出力部は、前記成果物に基づく診断、治療、手術、または前記ユーザの症状の推定を行う機関の装置に対して前記成果物を出力する、
前記（２）または（３）に記載の医療用情報処理システム。
（５）
前記成果物に基づいて前記ユーザの症状の推定を行う推定部をさらに備える、 前記（２）または（３）に記載の医療用情報処理システム。
（６）
前記ユーザ情報は、前記ユーザの位置情報、前記ユーザが過去に受けた前記検査に関する履歴情報、または前記ユーザが今後受ける前記検査に関する設定情報の少なくともいずれか１つを含む、
前記（１）から（５）のいずれか１項に記載の医療用情報処理システム。
（７）
前記ユーザ情報は、前記ユーザの位置情報を含み、
前記提示部は、前記検査手配リクエストに基づいて前記検査を実施可能な検査リソースを抽出し、さらに前記ユーザの位置情報と、抽出した前記検査リソースの位置情報とに基づいて、提示する検査リソースを抽出する、
前記（１）から（６）のいずれか１項に記載の医療用情報処理システム。
（８）
前記提示部は、前記ユーザの位置情報と、前記検査手配リクエストに基づいて抽出した前記検査リソースの位置情報に基づいて、前記ユーザの位置から所定の距離以内に位置する検査リソースを抽出して提示する、
前記（７）に記載の医療用情報処理システム。
（９）
前記提示部は、前記ユーザの位置情報と、前記検査手配リクエストに基づいて抽出した前記検査リソースの位置情報に基づいて、前記ユーザの位置に近い順に検査リソースを提示する、
前記（７）に記載の医療用情報処理システム。
（１０）
前記検査リソースの手配を行う手配部をさらに備える、
前記（１）から（９）のいずれか１項に記載の医療用情報処理システム。
（１１）
前記ユーザによる入力に基づいて前記検査手配リクエストを生成する生成部をさらに備える、
前記（１）から（１０）のいずれか１項に記載の医療用情報処理システム。
（１２）
医療に関する検査の種別を示す検査種別情報を含む検査手配リクエストと、ユーザに関する情報であるユーザ情報と、を取得する取得部と、
前記検査手配リクエストと前記ユーザ情報に基づいて、前記検査を実施可能な検査リソースを前記ユーザに提示する提示部と、
前記ユーザに対して行われた前記検査の成果物を前記ユーザ情報に紐づけて管理する管理部と、
前記ユーザによる入力に基づいて前記成果物を出力する出力部と、を備える、
医療用情報処理装置。
（１３）
医療に関する検査の種別を示す検査種別情報を含む検査手配リクエストと、ユーザに関する情報であるユーザ情報と、を取得することと、
前記検査手配リクエストと前記ユーザ情報に基づいて、前記検査を実施可能な検査リソースを前記ユーザに提示することと、
前記ユーザに対して行われた前記検査の成果物を前記ユーザ情報に紐づけて管理することと、
前記ユーザによる入力に基づいて前記成果物を出力することと、を有する、
コンピュータにより実行される医療用情報処理方法。
１００ マッチングサーバ
１１０ 通信部
１２０ 処理部
１２１ 認証部
１２２ マッチング部
１２３ 出力部
１３０ 記憶部
２００ 管理サーバ
２１０ 通信部
２２０ 処理部
２２１ 認証部
２２２ 管理部
２２３ 手配部
２２４ 出力部
２３０ 記憶部
３００ 検査端末
４００ ユーザ端末
４１０ 通信部
４２０ 処理部
４２１ 生成部
４３０ 記憶部
４４０ 入力部
４５０ 表示部
５００ ネットワーク
６００ 診断サーバ
６１０ 通信部
６２０ 処理部
６２１ 管理部
６２２ 診断ＡＩ連携部
６２３ 出力部
６３０ 記憶部
７００ 診断ＡＩ

Claims (13)

  1. 医療に関する検査の種別を示す検査種別情報を含む検査手配リクエストと、ユーザに関する情報であるユーザ情報と、を取得する取得部と、
    前記検査手配リクエストと前記ユーザ情報に基づいて、医療検査機関、医療検査従事者、検査装置、および前記ユーザ自身に使用される検査キットのいずれか複数の検査リソースの中から、前記検査を実施可能な検査リソースを前記ユーザに提示する提示部と、
    前記ユーザに対して行われた前記検査の成果物を前記ユーザ情報に紐づけて管理する管理部と、
    前記ユーザによる入力に基づいて前記成果物を出力する出力部と、を備える、
    医療用情報処理システム。
  2. 前記提示部は、前記複数の検査リソースとそれらの前記検査種別情報とを紐付けたテーブルを用いて、前記検査手配リクエストに含まれる前記検査種別情報に対応する前記検査リソースを、前記検査を実施可能な検査リソースとする、
    請求項１に記載の医療用情報処理システム。
  3. 前記検査手配リクエストは、前記検査の優先度を含み、
    前記提示部は、前記検査の優先度に基づいて、より優先度の高い前記検査手配リクエストを優先して用いる、
    請求項１に記載の医療用情報処理システム。
  4. 前記提示部は、前記複数の検査リソースに対する個々の評価に基づいて、前記複数の検査リソースから、より評価の高い検査リソースを、前記検査を実施可能な検査リソースとする、
    請求項２に記載の医療用情報処理システム。
  5. 前記提示部は、前記検査の内容及び前記検査リソースに基づいて、前記複数の検査リソースの中から、前記検査を実施可能な検査リソースを前記ユーザに提示する、
    請求項１に記載の医療用情報処理システム。
  6. 前記提示部は、前記検査リソースが使用期間の制限を有する検査キットである場合、前記使用期間に基づいて、前記複数の検査リソースの中から、前記検査を実施可能な検査リソースを前記ユーザに提示する、
    請求項５に記載の医療用情報処理システム。
  7. 前記検査リソースは、前記成果物に基づく診断、治療、手術、または前記ユーザの症状の推定を行わない、
    請求項１に記載の医療用情報処理システム。
  8. 前記出力部は、前記成果物に基づく診断、治療、手術、または前記ユーザの症状の推定を行う機関の装置に対して前記成果物を出力する、
    請求項６に記載の医療用情報処理システム。
  9. 前記成果物に基づいて前記ユーザの症状の推定を行う推定部をさらに備える、
    請求項６に記載の医療用情報処理システム。
  10. 前記検査リソースの手配を行う手配部をさらに備える、
    請求項１に記載の医療用情報処理システム。
  11. 前記ユーザによる入力に基づいて前記検査手配リクエストを生成する生成部をさらに備える、
    請求項１に記載の医療用情報処理システム。
  12. 医療に関する検査の種別を示す検査種別情報を含む検査手配リクエストと、ユーザに関する情報であるユーザ情報と、を取得する取得部と、
    前記検査手配リクエストと前記ユーザ情報に基づいて、医療検査機関、医療検査従事者、検査装置、および前記ユーザ自身に使用される検査キットのいずれか複数の検査リソースの中から、前記検査を実施可能な検査リソースを前記ユーザに提示する提示部と、
    前記ユーザに対して行われた前記検査の成果物を前記ユーザ情報に紐づけて管理する管理部と、
    前記ユーザによる入力に基づいて前記成果物を出力する出力部と、を備える、
    医療用情報処理装置。
  13. 医療に関する検査の種別を示す検査種別情報を含む検査手配リクエストと、ユーザに関する情報であるユーザ情報と、を取得することと、
    前記検査手配リクエストと前記ユーザ情報に基づいて、医療検査機関、医療検査従事者、検査装置、および前記ユーザ自身に使用される検査キットのいずれか複数の検査リソースの中から、前記検査を実施可能な検査リソースを前記ユーザに提示することと、
    前記ユーザに対して行われた前記検査の成果物を前記ユーザ情報に紐づけて管理することと、
    前記ユーザによる入力に基づいて前記成果物を出力することと、を有する、
    コンピュータにより実行される医療用情報処理方法。
JP2020537099A 2018-08-15 2019-08-14 医療用情報処理システム、医療用情報処理装置、および医療用情報処理方法 Active JP7388356B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2018152969 2018-08-15
JP2018152969 2018-08-15
PCT/JP2019/031987 WO2020036207A1 (ja) 2018-08-15 2019-08-14 医療用情報処理システム、医療用情報処理装置、および医療用情報処理方法

Publications (2)

Publication Number Publication Date
JPWO2020036207A1 JPWO2020036207A1 (ja) 2021-08-10
JP7388356B2 true JP7388356B2 (ja) 2023-11-29

Family

ID=69525373

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020537099A Active JP7388356B2 (ja) 2018-08-15 2019-08-14 医療用情報処理システム、医療用情報処理装置、および医療用情報処理方法

Country Status (3)

Country Link
US (1) US20210313053A1 (ja)
JP (1) JP7388356B2 (ja)
WO (1) WO2020036207A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7312721B2 (ja) * 2020-04-03 2023-07-21 任天堂株式会社 情報処理システム、情報処理プログラム、情報処理装置、および情報処理方法
JP7368925B2 (ja) * 2020-06-05 2023-10-25 豊田合成株式会社 感染症向け医療用モビリティ
JP6948497B1 (ja) * 2020-06-05 2021-10-13 株式会社コスミックコーポレーション 生体情報評価システム及び生体情報評価プログラム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002236757A (ja) 2000-12-06 2002-08-23 Health Wave Japan:Kk 検査管理装置および疾病検査方法
JP2018081397A (ja) 2016-11-15 2018-05-24 ディメンシア・フロント株式会社 認知症予防推進方法、及び、認知症予防推進システム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748907A (en) * 1993-10-25 1998-05-05 Crane; Harold E. Medical facility and business: automatic interactive dynamic real-time management
JP4091303B2 (ja) * 2002-01-07 2008-05-28 富士通株式会社 診療予約システム、診療予約方法、コンピュータ装置、端末装置、およびコンピュータプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002236757A (ja) 2000-12-06 2002-08-23 Health Wave Japan:Kk 検査管理装置および疾病検査方法
JP2018081397A (ja) 2016-11-15 2018-05-24 ディメンシア・フロント株式会社 認知症予防推進方法、及び、認知症予防推進システム

Also Published As

Publication number Publication date
US20210313053A1 (en) 2021-10-07
WO2020036207A1 (ja) 2020-02-20
JPWO2020036207A1 (ja) 2021-08-10

Similar Documents

Publication Publication Date Title
US11681356B2 (en) System and method for automated data entry and workflow management
JP4879519B2 (ja) 医療情報管理システム
US20190320900A1 (en) Telemedicine system
US20170011195A1 (en) System And Method Of User Identity Validation in a Telemedicine System
US20140222526A1 (en) System and method for augmenting healthcare-provider performance
JP7388356B2 (ja) 医療用情報処理システム、医療用情報処理装置、および医療用情報処理方法
US20100262435A1 (en) Targeted health care content delivery system
JP4627218B2 (ja) 医療情報管理システム
JP2016536680A (ja) ユーザの役割とコンテキストアウェアアルゴリズムとを組み合わせて、介護提供者の注意を安全に引き付け、情報過多を減少し、ワークフロー及び判断支援を最適化するように、臨床情報、オーディオ、ビデオ及び通信制御を提示するユニークな方法
US20100063845A1 (en) Systems and Methods for Allowing Patient Access to a Patient Electronic Health Records
US20160239616A1 (en) Medical support system, method and apparatus for medical care
JP4699094B2 (ja) 医療情報管理システム
KR20200024374A (ko) 진료 매칭 방법 및 이를 수행하는 전자 장치
JP2019133270A (ja) コンピュータプログラム、支援装置及び支援方法
JP7382741B2 (ja) 医療機関選定支援装置
CA3083090A1 (en) Medical examination support apparatus, and operation method and operation program thereof
US20190244691A1 (en) Medical record/management system with augmented patient images for rapid retrieval
US20150051918A1 (en) Computer-based system and method for presenting customized medical information
JP2023103774A (ja) 医用情報処理装置、医用情報処理方法及び医用情報処理プログラム
JP7444069B2 (ja) 医療用情報処理システム、医療用情報処理装置、および医療用情報処理方法
JP7024451B2 (ja) 遠隔診療端末装置及びコンピュータプログラム
KR20220026378A (ko) 심리 상담사 추천 시스템 및 심리 상담사 추천 방법
CN114450756A (zh) 医疗装置、系统以及方法
WO2019130494A1 (ja) コンピュータシステム、アラート方法及びプログラム
JP7467392B2 (ja) 情報提供装置、作業者端末及びコンピュータープログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220629

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230627

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230822

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20231017

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231030

R151 Written notification of patent or utility model registration

Ref document number: 7388356

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151