JP2016192207A - 医療情報システム - Google Patents
医療情報システム Download PDFInfo
- Publication number
- JP2016192207A JP2016192207A JP2016068568A JP2016068568A JP2016192207A JP 2016192207 A JP2016192207 A JP 2016192207A JP 2016068568 A JP2016068568 A JP 2016068568A JP 2016068568 A JP2016068568 A JP 2016068568A JP 2016192207 A JP2016192207 A JP 2016192207A
- Authority
- JP
- Japan
- Prior art keywords
- patient
- inquiry
- information
- medical
- pain
- 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.)
- Pending
Links
Abstract
【課題】患者からの痛みに関する問診結果に基づき得られる情報を容易に医療関係者にフィードバックできる、医療情報システムを提供する。【解決手段】医療情報システム１は、医療情報サーバ１０と、医療情報サーバと通信可能な閲覧端末４０と、を備える。医療情報サーバは、患者に対する問診の際に患者から得られた回答内容と患者の患者ＩＤと問診の実施日情報とを少なくとも含む、問診結果情報を複数記憶する、問診結果データベース１０４を備えているとともに、閲覧端末からの要求に応じて、問診結果データベースに記憶された問診結果情報に基づき得られる情報を、閲覧端末に出力可能である。問診結果情報の回答内容には、痛みによりできないことや困っていることがあるか否かを問う第１問診項目に対する回答内容が含まれている。【選択図】図１
Description
この発明は、医療情報システムに関するものである。
2012年に改訂されたがん対策推進基本計画において「日本の医療用麻薬消費量は増加傾向にあるが、欧米先進諸国と比較すると依然として少なく、がん性疼痛に苦しむがん患者の除痛がまだ十分に行われていないことが推測される」とされており、現場でのがん性疼痛治療成績の大幅な改善が必須とされている。
病院では、医療関係者が、患者（がん患者等）に対して痛み等に関する問診を行う場合、患者からの問診結果を、紙や電子カルテ等に記録することが一般的である。このように、病院内の複数の患者から得られた問診結果は、一箇所に集約されることなく、患者毎に別々の場所や方法で管理される。このため、例えば、医師は、病院内の患者のうち、どの患者が痛みで苦しんでいるか、あるいは、どれくらいの割合の患者が痛くなくなったか等を把握したいときに、即座にこれらを把握したり集計したりすることができなかった。よって、病院内の患者に対する痛みの治療が十分効果的であるか等の治療の評価を、十分に行うことができなかった。
また、問診結果を電子カルテで管理する場合は、問診結果を人によって電子化して電子カルテに記録する作業が必要となり、その作業が完了するまでは、電子カルテ上での問診結果の閲覧ができなかった。よって、例えば、医師が、患者の診察前に電子カルテ上で整然とした形で問診結果を観ることは、困難だった。
一方、紙で問診結果を管理する場合は、診察前に問診結果を医師に伝えることは比較的容易であるが、後に振り返って問診結果をデータ利用できるようにするためには、別途、問診結果を電子データ化するデータ入力者を雇用する必要があった。
また、問診結果を電子カルテで管理する場合は、問診結果を人によって電子化して電子カルテに記録する作業が必要となり、その作業が完了するまでは、電子カルテ上での問診結果の閲覧ができなかった。よって、例えば、医師が、患者の診察前に電子カルテ上で整然とした形で問診結果を観ることは、困難だった。
一方、紙で問診結果を管理する場合は、診察前に問診結果を医師に伝えることは比較的容易であるが、後に振り返って問診結果をデータ利用できるようにするためには、別途、問診結果を電子データ化するデータ入力者を雇用する必要があった。
本発明は、上述した課題を解決するためのものであり、患者からの痛みに関する問診結果に基づき得られる情報を、容易に医療関係者にフィードバックできる、医療情報システムを提供することを目的とするものである。
本発明の医療情報システムは、
医療情報サーバと、
前記医療情報サーバと通信可能な閲覧端末と、
を備えた、医療情報システムであって、
前記医療情報サーバは、
患者に対する問診の際に前記患者から得られた回答内容と前記患者の患者ＩＤと前記問診の実施日情報とを少なくとも含む、問診結果情報を複数記憶する、問診結果データベースを備えているとともに、
前記閲覧端末からの要求に応じて、前記問診結果データベースに記憶された前記問診結果情報に基づき得られる情報を、前記閲覧端末に出力可能であり、
前記問診結果情報の前記回答内容には、痛みによりできないことや困っていることがあるか否かを問う第１問診項目に対する回答内容が含まれている。
本発明の医療情報システムによれば、患者からの痛みに関する問診結果に基づき得られる情報を、容易に医療関係者にフィードバックできる。医療関係者は、このフィードバックされる情報に基づいて、より適切に、患者に対する痛みの治療の評価や改善等が可能となる。
医療情報サーバと、
前記医療情報サーバと通信可能な閲覧端末と、
を備えた、医療情報システムであって、
前記医療情報サーバは、
患者に対する問診の際に前記患者から得られた回答内容と前記患者の患者ＩＤと前記問診の実施日情報とを少なくとも含む、問診結果情報を複数記憶する、問診結果データベースを備えているとともに、
前記閲覧端末からの要求に応じて、前記問診結果データベースに記憶された前記問診結果情報に基づき得られる情報を、前記閲覧端末に出力可能であり、
前記問診結果情報の前記回答内容には、痛みによりできないことや困っていることがあるか否かを問う第１問診項目に対する回答内容が含まれている。
本発明の医療情報システムによれば、患者からの痛みに関する問診結果に基づき得られる情報を、容易に医療関係者にフィードバックできる。医療関係者は、このフィードバックされる情報に基づいて、より適切に、患者に対する痛みの治療の評価や改善等が可能となる。
本発明の医療情報システムにおいて、
前記医療情報サーバと通信可能な問診端末をさらに備え、
前記問診端末は、
問診項目の内容が表示されるとともに前記問診項目に対する回答内容を入力可能な、問診画面を、表示可能であるとともに、
患者に対する問診の際に前記問診画面で入力された回答内容と前記患者の患者ＩＤと前記問診の実施日情報とを含む前記問診結果情報を、前記医療情報サーバへ送信可能であり、
前記医療情報サーバは、前記問診結果情報を前記問診端末から受信すると、該問診結果情報を前記問診結果データベースに格納すると、好適である。
これによれば、問診端末によって自動的に問診結果が電子化されて、医療情報サーバに蓄積されるので、例えば医療関係者によって紙ベースで記録された問診結果を電子化し、蓄積する作業等が不要となり、利便性が向上される。
前記医療情報サーバと通信可能な問診端末をさらに備え、
前記問診端末は、
問診項目の内容が表示されるとともに前記問診項目に対する回答内容を入力可能な、問診画面を、表示可能であるとともに、
患者に対する問診の際に前記問診画面で入力された回答内容と前記患者の患者ＩＤと前記問診の実施日情報とを含む前記問診結果情報を、前記医療情報サーバへ送信可能であり、
前記医療情報サーバは、前記問診結果情報を前記問診端末から受信すると、該問診結果情報を前記問診結果データベースに格納すると、好適である。
これによれば、問診端末によって自動的に問診結果が電子化されて、医療情報サーバに蓄積されるので、例えば医療関係者によって紙ベースで記録された問診結果を電子化し、蓄積する作業等が不要となり、利便性が向上される。
本発明の医療情報システムにおいて、
前記医療情報サーバは、前記閲覧端末から、所定の患者から所定の日に得られた問診結果の出力要求があると、前記問診結果データベースから、前記所定の患者及び前記所定の日に対応する前記問診結果情報を抽出し、抽出した前記問診結果情報に基づき得られる情報を、前記閲覧端末に出力すると、好適である。
これによれば、例えば、医療関係者は、必要に応じて簡単に、所望の日に所望の患者から得られた問診結果の詳細を参照できるので、その患者に対する痛みの治療について見直しや改善をより適切に行うことができる。
前記医療情報サーバは、前記閲覧端末から、所定の患者から所定の日に得られた問診結果の出力要求があると、前記問診結果データベースから、前記所定の患者及び前記所定の日に対応する前記問診結果情報を抽出し、抽出した前記問診結果情報に基づき得られる情報を、前記閲覧端末に出力すると、好適である。
これによれば、例えば、医療関係者は、必要に応じて簡単に、所望の日に所望の患者から得られた問診結果の詳細を参照できるので、その患者に対する痛みの治療について見直しや改善をより適切に行うことができる。
本発明の医療情報システムにおいて、
前記医療情報サーバは、前記閲覧端末から、痛みによりできないことや困っていることがある患者のリストの出力要求があると、前記問診結果データベースに記憶された前記問診結果情報に基づいて、前記第１問診項目に対して「ある」と回答した患者を特定し、特定した前記患者のリストを、前記閲覧端末へ出力すると、好適である。
これによれば、例えば、医療関係者は、必要に応じて簡単に、当日に痛みによりできないことや困っていることがある患者のリストを参照できるので、それらの患者に対する痛みの治療について見直しや改善をより適切に行うことができる。
前記医療情報サーバは、前記閲覧端末から、痛みによりできないことや困っていることがある患者のリストの出力要求があると、前記問診結果データベースに記憶された前記問診結果情報に基づいて、前記第１問診項目に対して「ある」と回答した患者を特定し、特定した前記患者のリストを、前記閲覧端末へ出力すると、好適である。
これによれば、例えば、医療関係者は、必要に応じて簡単に、当日に痛みによりできないことや困っていることがある患者のリストを参照できるので、それらの患者に対する痛みの治療について見直しや改善をより適切に行うことができる。
本発明の医療情報システムにおいて、
前記問診結果情報の前記回答内容には、痛みの治療を受けているか否かを問う第２問診項目に対する回答内容が含まれており、
前記医療情報サーバは、前記閲覧端末から、除痛率の出力要求があると、前記問診結果データベースに記憶された前記問診結果情報に含まれる、前記第１問診項目及び前記第２問診項目に対する回答内容に基づいて、前記除痛率を算出し、算出した前記除痛率を、前記閲覧端末へ出力するように構成されており、
痛みでできないことや困っていることがあり、かつ、痛みの治療を受けている患者の数をＮ１とし、痛みでできないことや困っていることが無く、かつ、痛みの治療を受けている患者の数をＮ２とし、痛みでできないことや困っていることがあり、かつ、痛みの治療を受けていない患者の数をＮ３としたとき、前記医療情報サーバは、前記除痛率を、以下の式（１）：
除痛率 ＝ ｛Ｎ２／（Ｎ１+Ｎ２+Ｎ３）｝×１００ （％） ・・・（１）
により求めると、好適である。
これによれば、例えば、医療関係者は、除痛率（痛みでできないことや困っていることがなくなった患者の割合）を簡単に把握できるので、より適切に、痛みの治療の評価や改善をすることが可能となる。
なお、上記「第１問診項目」及び「第２問診項目」は、問診時の問診項目が多数ある場合に、それぞれ１番目及び２番目の問診項目とする必要は無い。
前記問診結果情報の前記回答内容には、痛みの治療を受けているか否かを問う第２問診項目に対する回答内容が含まれており、
前記医療情報サーバは、前記閲覧端末から、除痛率の出力要求があると、前記問診結果データベースに記憶された前記問診結果情報に含まれる、前記第１問診項目及び前記第２問診項目に対する回答内容に基づいて、前記除痛率を算出し、算出した前記除痛率を、前記閲覧端末へ出力するように構成されており、
痛みでできないことや困っていることがあり、かつ、痛みの治療を受けている患者の数をＮ１とし、痛みでできないことや困っていることが無く、かつ、痛みの治療を受けている患者の数をＮ２とし、痛みでできないことや困っていることがあり、かつ、痛みの治療を受けていない患者の数をＮ３としたとき、前記医療情報サーバは、前記除痛率を、以下の式（１）：
除痛率 ＝ ｛Ｎ２／（Ｎ１+Ｎ２+Ｎ３）｝×１００ （％） ・・・（１）
により求めると、好適である。
これによれば、例えば、医療関係者は、除痛率（痛みでできないことや困っていることがなくなった患者の割合）を簡単に把握できるので、より適切に、痛みの治療の評価や改善をすることが可能となる。
なお、上記「第１問診項目」及び「第２問診項目」は、問診時の問診項目が多数ある場合に、それぞれ１番目及び２番目の問診項目とする必要は無い。
本発明の医療情報システムにおいて、
前記医療情報サーバは、
ＤＰＣのＥＦファイルを記憶する、ＥＦファイルデータベースと、
ＤＰＣのＥＦファイルのレセプト電算処理システム用コードのうちの医薬品コードと換算係数との対応関係を少なくとも規定する対応関係情報を記憶する、対応関係記憶部と、
をさらに備え、
前記医療情報サーバは、前記閲覧端末から、処方量集計の要求があると、前記集計にあたって、前記対応関係情報から、前記処方量集計の要求により指定される条件に合う薬の医薬品コードに対応する換算係数を読み込むとともに、前記ＥＦファイルデータベースに記憶されたＥＦファイルから、前記条件に合う薬の医薬品コードに対応する診療記録を抽出して、前記抽出した診療記録における使用量及び行為回数を読み込んで、前記換算係数、前記使用量、及び前記行為回数どうしの乗算により、該診療記録分の処方量を求め、求めた前記診療記録分の処方量に基づき得られる集計結果を、前記閲覧端末へ出力すると、好適である。
これによれば、例えば、医療関係者は、処方量の集計結果を知ることができるので、より適切に、痛みの治療の評価や改善をすることが可能となる。また、ＤＰＣ制度により標準化されたＥＦファイルを用いて処方量を集計するので、本発明の医療情報システムを、ＤＰＣ対象病院で容易に適用できる。よって、汎用性を向上できる。
前記医療情報サーバは、
ＤＰＣのＥＦファイルを記憶する、ＥＦファイルデータベースと、
ＤＰＣのＥＦファイルのレセプト電算処理システム用コードのうちの医薬品コードと換算係数との対応関係を少なくとも規定する対応関係情報を記憶する、対応関係記憶部と、
をさらに備え、
前記医療情報サーバは、前記閲覧端末から、処方量集計の要求があると、前記集計にあたって、前記対応関係情報から、前記処方量集計の要求により指定される条件に合う薬の医薬品コードに対応する換算係数を読み込むとともに、前記ＥＦファイルデータベースに記憶されたＥＦファイルから、前記条件に合う薬の医薬品コードに対応する診療記録を抽出して、前記抽出した診療記録における使用量及び行為回数を読み込んで、前記換算係数、前記使用量、及び前記行為回数どうしの乗算により、該診療記録分の処方量を求め、求めた前記診療記録分の処方量に基づき得られる集計結果を、前記閲覧端末へ出力すると、好適である。
これによれば、例えば、医療関係者は、処方量の集計結果を知ることができるので、より適切に、痛みの治療の評価や改善をすることが可能となる。また、ＤＰＣ制度により標準化されたＥＦファイルを用いて処方量を集計するので、本発明の医療情報システムを、ＤＰＣ対象病院で容易に適用できる。よって、汎用性を向上できる。
本発明の医療情報システムにおいて、
前記医療情報サーバは、患者が所定の疾患を有するか否かを特定する疾患有無情報と前記患者の患者ＩＤとを少なくとも含む、患者基本情報を複数記憶する、患者基本情報データベースをさらに備え、
前記ＥＦファイルデータベースに記憶されるＥＦファイルのデータ識別番号は、患者ＩＤと関連付けられており、
前記医療情報サーバは、前記処方量集計の要求により指定される条件が前記疾患の有無を含む場合、前記集計にあたって、前記患者基本情報の前記疾患有無情報に基づき、前記条件に合う患者の患者ＩＤを抽出し、抽出した前記患者ＩＤに関連付けられたデータ識別番号に対応する前記診療記録を用いて、前記集計結果を得ると、好適である。
これによれば、所定の疾患を有する患者とそうでない患者とに分けて、処方量の集計が可能となる。
前記医療情報サーバは、患者が所定の疾患を有するか否かを特定する疾患有無情報と前記患者の患者ＩＤとを少なくとも含む、患者基本情報を複数記憶する、患者基本情報データベースをさらに備え、
前記ＥＦファイルデータベースに記憶されるＥＦファイルのデータ識別番号は、患者ＩＤと関連付けられており、
前記医療情報サーバは、前記処方量集計の要求により指定される条件が前記疾患の有無を含む場合、前記集計にあたって、前記患者基本情報の前記疾患有無情報に基づき、前記条件に合う患者の患者ＩＤを抽出し、抽出した前記患者ＩＤに関連付けられたデータ識別番号に対応する前記診療記録を用いて、前記集計結果を得ると、好適である。
これによれば、所定の疾患を有する患者とそうでない患者とに分けて、処方量の集計が可能となる。
本発明によれば、患者からの痛みに関する問診結果に基づき得られる情報を、容易に医療関係者にフィードバックできる、医療情報システムを提供することができる。
以下に図面を参照しつつ、本発明の実施形態について例示説明する。
図１〜図１７を参照して、本発明の医療情報システムの一実施形態を説明する。
図１〜図１７を参照して、本発明の医療情報システムの一実施形態を説明する。
（医療情報システムの構成）
まず、図１を参照して、本実施形態の医療情報システム１の構成を説明する。医療情報システム１は、病院内で使用されるシステムとして構成されており、医療情報サーバ１０と、複数のクライアント端末２０と、電子カルテサーバ５０とを、備えている。医療情報サーバ１０は、病院内の無線及び／又は有線の通信網を介して、クライアント端末２０や電子カルテサーバ５０との間で、通信可能である。
本例では、クライアント端末２０として、問診端末３０と閲覧端末４０とがある。
医療情報サーバ１０は、仮想サーバ及び物理サーバのいずれとして構成されてもよいが、省スペース化の観点から、仮想サーバとして構成されると好適である。
問診端末３０、閲覧端末４０、及び電子カルテサーバ５０は、それぞれ複数台ずつ設けられてもよい。また、医療情報システム１は、電子カルテサーバ５０を備えなくてもよい。
まず、図１を参照して、本実施形態の医療情報システム１の構成を説明する。医療情報システム１は、病院内で使用されるシステムとして構成されており、医療情報サーバ１０と、複数のクライアント端末２０と、電子カルテサーバ５０とを、備えている。医療情報サーバ１０は、病院内の無線及び／又は有線の通信網を介して、クライアント端末２０や電子カルテサーバ５０との間で、通信可能である。
本例では、クライアント端末２０として、問診端末３０と閲覧端末４０とがある。
医療情報サーバ１０は、仮想サーバ及び物理サーバのいずれとして構成されてもよいが、省スペース化の観点から、仮想サーバとして構成されると好適である。
問診端末３０、閲覧端末４０、及び電子カルテサーバ５０は、それぞれ複数台ずつ設けられてもよい。また、医療情報システム１は、電子カルテサーバ５０を備えなくてもよい。
医療情報サーバ１０は、制御部１１と、通信部１２と、記憶部１３とを、備えている。医療情報サーバ１０は、さらに、図示しない表示部や入力部を備えていてもよい。
制御部１１は、例えばＣＰＵによって構成されており、記憶部１３のプログラム記憶部１００に記憶される医療情報プログラム１００ａを実行することによって、通信部１２及び記憶部１３を含む、医療情報サーバ１０の全体を制御する。
通信部１２は、無線通信及び／又は有線通信により、クライアント端末２０や電子カルテサーバ５０との間で、情報の送受信を行う。
記憶部１３は、プログラム記憶部１００と、患者基本情報データベース（以下、データベースを「ＤＢ」と記載する。）１０１と、外来ＤＢ１０２と、入院ＤＢ１０３と、問診結果ＤＢ１０４と、ＥＦファイルＤＢ１０５と、対応関係記憶部１０６と、を有している。
制御部１１は、例えばＣＰＵによって構成されており、記憶部１３のプログラム記憶部１００に記憶される医療情報プログラム１００ａを実行することによって、通信部１２及び記憶部１３を含む、医療情報サーバ１０の全体を制御する。
通信部１２は、無線通信及び／又は有線通信により、クライアント端末２０や電子カルテサーバ５０との間で、情報の送受信を行う。
記憶部１３は、プログラム記憶部１００と、患者基本情報データベース（以下、データベースを「ＤＢ」と記載する。）１０１と、外来ＤＢ１０２と、入院ＤＢ１０３と、問診結果ＤＢ１０４と、ＥＦファイルＤＢ１０５と、対応関係記憶部１０６と、を有している。
プログラム記憶部１００は、医療情報プログラム１００ａを記憶している。医療情報プログラム１００ａは、ＵＳＢメモリ、ＳＤメモリカード、ＣＤ等の記録媒体からプログラム記憶部１００に格納されてもよいし、あるいは、インターネットからダウンロードされてプログラム記憶部１００に格納されてもよい。
患者基本情報ＤＢ１０１は、患者毎に患者基本情報１０１ａを記憶している。本例において、患者基本情報１０１ａは、患者ＩＤ、氏名、カナ氏名、生年月日、性別、及び疾患有無情報を含む。ただし、患者基本情報１０１ａは、疾患有無情報を含まなくてもよい。患者ＩＤは、病院内で患者毎に与えられる固有の識別情報である。疾患有無情報は、患者が特定の疾患を有しているか否かを表す情報であり、本例では、患者ががんを有するか否か（より具体的には、がんと診断されたか否か）を表す情報である。
外来ＤＢ１０２は、外来患者毎に外来情報（外来の予約情報）１０２ａを記憶している。本例において、外来情報１０２ａは、患者ＩＤ、予約日付、予約時刻、診療科コード、予約項目コード、予約項目名称、及び併科有無情報を含む。ただし、外来情報１０２ａは、予約時刻、予約項目コード、予約項目名称、及び併科有無情報のうち少なくともいずれか１つを含まなくてもよい。併科有無情報は、その患者が複数の診療科の予約をしているか否かを表す情報である。
入院ＤＢ１０３は、入院患者毎に入院情報１０３ａを記憶している。本例において、入院情報１０３ａは、患者ＩＤ、入院番号、入院予定日、入院日、退院日、入院診療科、入院病棟、部屋番号、ベッド番号、医療チーム情報、及び主治医情報を含む。ただし、入院情報１０３ａは、入院予定日、部屋番号、ベッド番号、医療チーム情報、及び主治医情報のうち少なくともいずれか１つを含まなくてもよい。
外来ＤＢ１０２は、外来患者毎に外来情報（外来の予約情報）１０２ａを記憶している。本例において、外来情報１０２ａは、患者ＩＤ、予約日付、予約時刻、診療科コード、予約項目コード、予約項目名称、及び併科有無情報を含む。ただし、外来情報１０２ａは、予約時刻、予約項目コード、予約項目名称、及び併科有無情報のうち少なくともいずれか１つを含まなくてもよい。併科有無情報は、その患者が複数の診療科の予約をしているか否かを表す情報である。
入院ＤＢ１０３は、入院患者毎に入院情報１０３ａを記憶している。本例において、入院情報１０３ａは、患者ＩＤ、入院番号、入院予定日、入院日、退院日、入院診療科、入院病棟、部屋番号、ベッド番号、医療チーム情報、及び主治医情報を含む。ただし、入院情報１０３ａは、入院予定日、部屋番号、ベッド番号、医療チーム情報、及び主治医情報のうち少なくともいずれか１つを含まなくてもよい。
本例では、定期的に（例えば毎日１回）、当日以降の所定期間分（例えば当日分又は当日以降の一週間分等）の外来予約患者の患者基本情報１０１ａ及び外来情報１０２ａと、当日以降の所定期間分（例えば当日分又は当日以降の一週間分等）の入院患者（入院中の患者及び入院予定の患者）の患者基本情報１０１ａ及び入院情報１０３ａとが、電子カルテサーバ５０から医療情報サーバ１０に送信され、患者基本情報ＤＢ１０１、外来ＤＢ１０２、及び入院ＤＢ１０３にそれぞれ格納される。また、過去分の患者については、少なくとも、後述する問診端末３０を用いた問診を受けた患者の患者基本情報１０１ａ、外来情報１０２ａ、及び入院情報１０３ａが、患者基本情報ＤＢ１０１、外来ＤＢ１０２、及び入院ＤＢ１０３にそれぞれ残される。
ただし、患者基本情報１０１ａ、外来情報１０２ａ、及び入院情報１０３ａは、電子カルテサーバ５０を経由せずに、例えば、医療情報サーバ１０の入力部（図示せず）又は閲覧端末４０を介して、定期的に医療関係者により手入力される等して、患者基本情報ＤＢ１０１、外来ＤＢ１０２、及び入院ＤＢ１０３にそれぞれに格納されてもよい。このことについては、後に、図１７を参照しながらさらに詳しく説明する。
ただし、患者基本情報１０１ａ、外来情報１０２ａ、及び入院情報１０３ａは、電子カルテサーバ５０を経由せずに、例えば、医療情報サーバ１０の入力部（図示せず）又は閲覧端末４０を介して、定期的に医療関係者により手入力される等して、患者基本情報ＤＢ１０１、外来ＤＢ１０２、及び入院ＤＢ１０３にそれぞれに格納されてもよい。このことについては、後に、図１７を参照しながらさらに詳しく説明する。
問診結果ＤＢ１０４は、患者に対して行われた問診毎に問診結果情報１０４ａを記憶している。すなわち、同じ患者に対して複数回にわたり問診が行われた場合は、問診の回次毎に問診結果情報１０４ａが記憶される。後述するように、問診結果情報１０４ａは、問診端末３０を用いて患者への問診が行われた後に、問診端末３０から医療情報サーバ１０に送信されて、問診結果ＤＢ１０４に格納される。本例において、問診結果情報１０４ａは、患者ＩＤ、問診に対する患者からの回答内容、調査日（問診を行った日）、及び診療科情報を含む。
ＥＦファイルＤＢ１０５は、ＤＰＣのＥＦファイル１０５ａを記憶している。ＥＦファイル（「ＥＦ統合ファイル」とも呼ばれる）は、ＤＰＣ制度に基づき標準化されたフォーマットで作成されるテキストファイルである。
ＤＰＣ制度（ＤＰＣ／ＰＤＰＳ：Diagnosis Procedure Combination / Per-Diem Payment System）は、日本において、平成１５年４月より、閣議決定に基づき、特定機能病院を対象に導入された、急性期入院医療を対象とする診断群分類に基づく１日あたり包括払い制度である。現在、ある程度以上の規模を持つ数多くの病院が、ＤＰＣの対象病院となっており、ＤＰＣ対象病院の数は年々増加している。ＤＰＣの対象病院では、毎月、ＥＦファイルが作成されることになっている。ＥＦファイルには、医科点数表に基づく出来高による診療報酬の算定情報が入力される。各月のＥＦファイルには、当月の全外来患者分の記録が記入されたＥＦｇファイルと、当月の全入院患者分の記録が記入されたＥＦｎファイルとがある。以下の説明では、特に断りがない限り、ＥＦｇファイルとＥＦｎファイルとを区別せずに、「ＥＦファイル」という。
本例において、ＥＦファイル１０５ａは、任意のタイミングで、医療関係者によるクライアント端末２０（例えば、閲覧端末４０）の操作により、クライアント端末２０から医療情報サーバ１０に送信されて、ＥＦファイルＤＢ１０５に格納される。
ＥＦファイルについては、後にさらに詳しく説明する。
ＤＰＣ制度（ＤＰＣ／ＰＤＰＳ：Diagnosis Procedure Combination / Per-Diem Payment System）は、日本において、平成１５年４月より、閣議決定に基づき、特定機能病院を対象に導入された、急性期入院医療を対象とする診断群分類に基づく１日あたり包括払い制度である。現在、ある程度以上の規模を持つ数多くの病院が、ＤＰＣの対象病院となっており、ＤＰＣ対象病院の数は年々増加している。ＤＰＣの対象病院では、毎月、ＥＦファイルが作成されることになっている。ＥＦファイルには、医科点数表に基づく出来高による診療報酬の算定情報が入力される。各月のＥＦファイルには、当月の全外来患者分の記録が記入されたＥＦｇファイルと、当月の全入院患者分の記録が記入されたＥＦｎファイルとがある。以下の説明では、特に断りがない限り、ＥＦｇファイルとＥＦｎファイルとを区別せずに、「ＥＦファイル」という。
本例において、ＥＦファイル１０５ａは、任意のタイミングで、医療関係者によるクライアント端末２０（例えば、閲覧端末４０）の操作により、クライアント端末２０から医療情報サーバ１０に送信されて、ＥＦファイルＤＢ１０５に格納される。
ＥＦファイルについては、後にさらに詳しく説明する。
対応関係記憶部１０６は、対応関係情報１０６ａを記憶している。対応関係情報１０６aについては、後に詳しく説明する。
問診端末３０は、例えば、携帯電話（スマートフォン等）、タブレット端末、コンピュータ端末等として構成されており、制御部３１と、通信部３２と、記憶部３３と、入力部３４と、表示部３５とを、備えている。
制御部３１は、例えばＣＰＵによって構成されており、記憶部３３に記憶される問診プログラム３３ａを実行することによって、通信部３２、記憶部３３、入力部３４、及び表示部３５を含む、問診端末３０の全体を制御する。
通信部３２は、無線通信及び／又は有線通信により、医療情報サーバ１０との間で、情報の送受信を行う。
記憶部３３は、問診プログラム３３ａを記憶している。問診プログラム３３ａは、ＵＳＢメモリ、ＳＤメモリカード、ＣＤ等の記録媒体から記憶部３３に格納されてもよいし、あるいは、インターネットからダウンロードされて記憶部３３に格納されてもよい。
入力部３４は、例えば、押しボタン、キーボード、及び／又はマウス等から構成され、問診端末を操作するユーザ（医療関係者又は患者）からの入力を受け付ける。
表示部３５は、例えば液晶パネル等から構成され、様々な画面を表示する。
なお、入力部３４及び表示部３５をタッチパネルで構成してもよい。
制御部３１は、例えばＣＰＵによって構成されており、記憶部３３に記憶される問診プログラム３３ａを実行することによって、通信部３２、記憶部３３、入力部３４、及び表示部３５を含む、問診端末３０の全体を制御する。
通信部３２は、無線通信及び／又は有線通信により、医療情報サーバ１０との間で、情報の送受信を行う。
記憶部３３は、問診プログラム３３ａを記憶している。問診プログラム３３ａは、ＵＳＢメモリ、ＳＤメモリカード、ＣＤ等の記録媒体から記憶部３３に格納されてもよいし、あるいは、インターネットからダウンロードされて記憶部３３に格納されてもよい。
入力部３４は、例えば、押しボタン、キーボード、及び／又はマウス等から構成され、問診端末を操作するユーザ（医療関係者又は患者）からの入力を受け付ける。
表示部３５は、例えば液晶パネル等から構成され、様々な画面を表示する。
なお、入力部３４及び表示部３５をタッチパネルで構成してもよい。
閲覧端末４０は、図１の例ではコンピュータ端末（電子カルテ端末等）として構成されているが、これに限られず、例えば、携帯電話（スマートフォン等）やタブレット端末等として構成されてもよい。閲覧端末４０は、医療情報サーバ１０との間で無線通信及び／又は有線通信ができるようにされている。閲覧端末４０には、ウェブブラウザ用のプログラムがインストールされており、閲覧端末４０を操作するユーザ（医療関係者）がウェブブラウザを開いて医療情報サーバ１０にアクセスできるようにされている。閲覧端末４０のウェブブラウザ上でユーザからの入力があると、その入力内容に応じた要求が閲覧端末４０から医療情報サーバ１０に送信される。また、医療情報サーバ１０から情報が閲覧端末４０に送信されると、閲覧端末４０のウェブブラウザ上でその情報が表示される。
なお、問診端末３０にウェブブラウザ用のプログラムがインストールされている場合は、問診端末３０を閲覧端末４０として兼用してもよい。
なお、問診端末３０にウェブブラウザ用のプログラムがインストールされている場合は、問診端末３０を閲覧端末４０として兼用してもよい。
電子カルテサーバ５０には、病院内の各患者の電子カルテが記憶されている。電子カルテサーバ５０には、図示しない電子カルテ端末が接続される。閲覧端末４０は、電子カルテサーバ５０にアクセス可能に構成されて、電子カルテ端末として兼用されてもよい。
（問診端末の機能）
つぎに、図２〜図７を参照して、問診端末３０による問診機能について説明する。なお、問診端末３０の問診機能は、制御部３１が問診プログラム３３ａを実行することにより実現される。図２（ａ）〜図２（ｄ）、図３（ａ）〜図３（ｃ）、図４（ａ）及び図４（ｂ）は、それぞれ、問診プログラム３３ａの起動中に、問診端末３０の表示部３５に表示される画面の例を示している。図２〜図４の例では、問診端末３０がスマートフォンとして構成されており、問診プログラム３３ａがスマートフォン用のアプリケーションプログラムからなる。ただし、問診端末３０がスマートフォン以外の端末として構成される場合、問診プログラム３３ａは、問診端末３０上で作動し得るような形式のプログラムからなるものとする。また、図２〜図４の例では、医療関係者（例えば看護師）が、所定のタイミングで（例えば毎日１回）、問診端末３０に表示される画面に従って外来患者や入院患者に問診を行い、患者からの回答内容を問診端末３０に入力する。
つぎに、図２〜図７を参照して、問診端末３０による問診機能について説明する。なお、問診端末３０の問診機能は、制御部３１が問診プログラム３３ａを実行することにより実現される。図２（ａ）〜図２（ｄ）、図３（ａ）〜図３（ｃ）、図４（ａ）及び図４（ｂ）は、それぞれ、問診プログラム３３ａの起動中に、問診端末３０の表示部３５に表示される画面の例を示している。図２〜図４の例では、問診端末３０がスマートフォンとして構成されており、問診プログラム３３ａがスマートフォン用のアプリケーションプログラムからなる。ただし、問診端末３０がスマートフォン以外の端末として構成される場合、問診プログラム３３ａは、問診端末３０上で作動し得るような形式のプログラムからなるものとする。また、図２〜図４の例では、医療関係者（例えば看護師）が、所定のタイミングで（例えば毎日１回）、問診端末３０に表示される画面に従って外来患者や入院患者に問診を行い、患者からの回答内容を問診端末３０に入力する。
まず、医療関係者は、問診端末３０を操作して問診プログラム３３ａを起動させる。すると、表示部３５に、ログイン画面（図示せず）が表示される。ログイン画面において、医療関係者がＩＤとパスワードを入力してログインすると、次に、表示部３５上の画面は、診療科選択画面（図示せず）に切り換わる。診療科選択画面において、医療関係者は、問診の対象とする患者の診療科（本例では消化器内科）を選択する。
次に、表示部３５には、「問診対象患者選択」という文字が表示された、問診対象患者選択画面（図２（ａ））が表示される。図２（ａ）の問診対象患者選択画面には、機能選択アイコン４００が設けられている。機能選択アイコン４００が選択されると、機能選択画面４００ａがポップアップする。機能選択画面４００ａは、問診対象患者取得ボタン４０１、新規登録ボタン４０２、患者検索ボタン４０３、問診データアップロードボタン４０４、及びログアウトボタン４０５を含んでいる。なお、機能選択アイコン４００は、問診プログラム３３ａの起動中、常に画面上に表示される。
機能選択画面４００ａにおいて、問診対象患者取得ボタン４０１が選択されると、制御部３１は、通信部３２に、問診対象患者取得要求を医療情報サーバ１０へ送信させる。問診対象患者取得要求には、上記診療科選択画面で選択された診療科情報（本例では消化器内科）が含まれる。
一方、医療情報サーバ１０側では、通信部１２が問診対象患者取得要求を受信すると、制御部１１が、外来ＤＢ１０２及び入院ＤＢ１０３を参照して、問診の対象とする診療科（本例では消化器内科）で、当日に外来予定のある患者と当日に入院している又は入院予定のある患者との各患者ＩＤを抽出するとともに、患者基本情報ＤＢから、抽出した各患者ＩＤに対応する氏名をそれぞれ読み出す。そして、制御部１１は、抽出した各患者の患者ＩＤ及び氏名を、通信部１２に、問診端末３０へ送信させる。
そして、問診端末３０側において、通信部３２が患者ＩＤ及び氏名のリストを医療情報サーバ１０から受信すると、制御部３１は、図２（ｂ）に示すように、そのリストを、問診対象患者選択画面に表示させる。
図２（ｂ）の問診対象患者選択画面において、いずれかの患者が選択されると、制御部３１は、表示部３５に、問診項目を表示するとともに患者からの回答内容の入力を受け付ける、問診画面（図２（ｃ）〜図２（ｄ）、図３（ａ）〜図３（ｃ））を、入力に応じて順次表示させていく。
一方、医療情報サーバ１０側では、通信部１２が問診対象患者取得要求を受信すると、制御部１１が、外来ＤＢ１０２及び入院ＤＢ１０３を参照して、問診の対象とする診療科（本例では消化器内科）で、当日に外来予定のある患者と当日に入院している又は入院予定のある患者との各患者ＩＤを抽出するとともに、患者基本情報ＤＢから、抽出した各患者ＩＤに対応する氏名をそれぞれ読み出す。そして、制御部１１は、抽出した各患者の患者ＩＤ及び氏名を、通信部１２に、問診端末３０へ送信させる。
そして、問診端末３０側において、通信部３２が患者ＩＤ及び氏名のリストを医療情報サーバ１０から受信すると、制御部３１は、図２（ｂ）に示すように、そのリストを、問診対象患者選択画面に表示させる。
図２（ｂ）の問診対象患者選択画面において、いずれかの患者が選択されると、制御部３１は、表示部３５に、問診項目を表示するとともに患者からの回答内容の入力を受け付ける、問診画面（図２（ｃ）〜図２（ｄ）、図３（ａ）〜図３（ｃ））を、入力に応じて順次表示させていく。
具体的に、本例では、最初の問診画面として、図２（ｃ）の画面が表示される。図２（ｃ）の問診画面には、第１の問診項目としての「痛みでできないことや困っていることはありませんか？」という質問文と、回答内容を入力するための「ない」及び「ある」の選択ボタンとが、表示される。
図２（ｃ）の画面で「ない」が選択された場合、後述する図３（ａ）の問診画面に切り換わる。
一方、図２（ｃ）の画面で「ある」が選択されると、図２（ｄ）の問診画面に切り換わる。
図２（ｄ）の画面には、第２の問診項目としての「痛みによってできないことや困っていることはどんなことですか？」という質問文と、回答内容を入力するための「眠る」、「立つ」、「歩く」、「座る」、「飲食」、「腕・肩の動き」、「起きる」、「排泄」、「楽しみ」、「会話」、「不安」、及び「落ち込み」の選択ボタンとが、表示される。
図２（ｄ）の画面で１つ以上の選択ボタンが選択され、画面が所定方向（例えば左方向）にスワイプされると、図３（ａ）の問診画面に切り換わる。
図２（ｃ）の画面で「ない」が選択された場合、後述する図３（ａ）の問診画面に切り換わる。
一方、図２（ｃ）の画面で「ある」が選択されると、図２（ｄ）の問診画面に切り換わる。
図２（ｄ）の画面には、第２の問診項目としての「痛みによってできないことや困っていることはどんなことですか？」という質問文と、回答内容を入力するための「眠る」、「立つ」、「歩く」、「座る」、「飲食」、「腕・肩の動き」、「起きる」、「排泄」、「楽しみ」、「会話」、「不安」、及び「落ち込み」の選択ボタンとが、表示される。
図２（ｄ）の画面で１つ以上の選択ボタンが選択され、画面が所定方向（例えば左方向）にスワイプされると、図３（ａ）の問診画面に切り換わる。
図３（ａ）の画面には、第３の問診項目としての「痛み以外につらい症状はありませんか？」という質問文と、回答内容を入力するための「ない」、「だるい」、「食欲不振」、「口の渇きや痛み」、「吐き気・嘔吐」、「便秘」、及び「その他の症状」の選択ボタンとが、表示される。図３（ａ）の画面で、「ない」が選択されると、あるいは、「だるい」、「食欲不振」、「口の渇きや痛み」、「吐き気・嘔吐」、「便秘」、及び「その他の症状」のうち少なくとも１つの選択ボタンが選択され、画面が所定方向にスワイプされると、図３（ｂ）の問診画面に切り換わる。
図３（ｂ）の画面には、第４〜第６の問診項目と、それぞれの問診項目に対して回答内容を入力するための選択ボタンとが、表示される。第４の問診項目は「気持ちの落ち込みや不安、イライラなどはありますか？」というものであり、それに対応して、「ない」及び「ある」の選択ボタンが設けられている。第４の問診項目に対して「ある」が選択された場合は、気持ちの落ち込みや不安、イライラなどの程度を聞く画面（図示せず）がポップアップし、そのポップアップした画面において、「軽い」、「中ぐらい」、及び「強い」のいずれかを選択できるようにされている。第５の問診項目は「家族や仕事、経済的なことで気がかりなことはありますか？」というものであり、それに対して、「ない」及び「ある」の選択ボタンが設けられている。第６の問診項目は「治療や検査のことで分かりにくいことや聞きたいことはありますか？」というものであり、それに対して、「ない」及び「ある」の選択ボタンが設けられている。
図３（ｂ）の画面で第４〜第６の問診項目のそれぞれに対する選択ボタンが選択され、画面が所定方向にスワイプされると、図３（ｃ）の問診画面に切り換わる。
図３（ｃ）の画面には、第７の問診項目としての「鎮痛薬を服用していますか？」という質問文と、回答内容を入力するための「はい」及び「いいえ」の選択ボタンと、「問診終了」ボタンとが、表示される。
図３（ｃ）の画面で、第７の問診項目に対する回答が「はい」又は「いいえ」で選択され、「問診終了」ボタンが選択されると、問診が完了する。
図３（ｂ）の画面には、第４〜第６の問診項目と、それぞれの問診項目に対して回答内容を入力するための選択ボタンとが、表示される。第４の問診項目は「気持ちの落ち込みや不安、イライラなどはありますか？」というものであり、それに対応して、「ない」及び「ある」の選択ボタンが設けられている。第４の問診項目に対して「ある」が選択された場合は、気持ちの落ち込みや不安、イライラなどの程度を聞く画面（図示せず）がポップアップし、そのポップアップした画面において、「軽い」、「中ぐらい」、及び「強い」のいずれかを選択できるようにされている。第５の問診項目は「家族や仕事、経済的なことで気がかりなことはありますか？」というものであり、それに対して、「ない」及び「ある」の選択ボタンが設けられている。第６の問診項目は「治療や検査のことで分かりにくいことや聞きたいことはありますか？」というものであり、それに対して、「ない」及び「ある」の選択ボタンが設けられている。
図３（ｂ）の画面で第４〜第６の問診項目のそれぞれに対する選択ボタンが選択され、画面が所定方向にスワイプされると、図３（ｃ）の問診画面に切り換わる。
図３（ｃ）の画面には、第７の問診項目としての「鎮痛薬を服用していますか？」という質問文と、回答内容を入力するための「はい」及び「いいえ」の選択ボタンと、「問診終了」ボタンとが、表示される。
図３（ｃ）の画面で、第７の問診項目に対する回答が「はい」又は「いいえ」で選択され、「問診終了」ボタンが選択されると、問診が完了する。
その後、第１〜第７の各問診項目に対する選択内容（回答内容）の一覧が、図４（ａ）の問診内容確認画面に表示される。図４（ａ）の問診内容確認画面には、「問診登録」ボタン４１０があり、これが選択されると、問診登録画面４１０ａがポップアップする。
図４（ａ）に示す問診登録画面４１０ａは、通常登録ボタン４１１と要対応登録ボタン４１２とを含んでいる。通常登録ボタン４１１は、患者からの回答内容をそのまま登録するためのボタンである。要対応登録ボタン４１２は、問診を行った医療関係者が、その問診を受けた患者について優先的に対応する必要があると判断した場合に、その患者からの回答内容を登録するのに加えて、主治医等に対して、念押しで必ず対応してほしい患者である等の意思表示をするために、要対応登録するための、ボタンである。
より具体的には、問診登録画面４１０ａにおいて、通常登録ボタン４１１が選択されると、患者からの回答内容がいったん記憶部３３に登録され、表示部３５には図２（ｂ）の問診対象患者選択画面が再び表示される。
一方、問診登録画面４１０ａにおいて、要対応登録ボタン４１２が選択されると、患者からの回答内容が、要対応フラグとともに、いったん記憶部３３に登録さる。また、表示部３５には、図４（ｂ）に示すように問診対象患者選択画面が再び表示されるが、その際、その患者について要対応登録されたことを示す表示がなされる。図４（ｂ）に示す例では、要対応登録された患者（患者００３）の欄の背景色が、図２（ｂ）に示すような最初の背景色である第１背景色（例えば白）から、第２背景色（例えばピンク）へと、変更されている。これにより、背景色が第２背景色である患者００３について、優先的な対応が必要であることが、観て判るようになる。
なお、要対応登録は、問診登録画面４１０ａ上で行う場合以外にも、例えば、図２（ｂ）の問診対象患者選択画面上で行えるようにしてもよい。具体的には、例えば、問診対象患者選択画面において、要対応登録したい患者の欄をスワイプ操作し、それにより現れる要対応登録ボタンを選択することにより、要対応登録を行えるようにしてもよい。
より具体的には、問診登録画面４１０ａにおいて、通常登録ボタン４１１が選択されると、患者からの回答内容がいったん記憶部３３に登録され、表示部３５には図２（ｂ）の問診対象患者選択画面が再び表示される。
一方、問診登録画面４１０ａにおいて、要対応登録ボタン４１２が選択されると、患者からの回答内容が、要対応フラグとともに、いったん記憶部３３に登録さる。また、表示部３５には、図４（ｂ）に示すように問診対象患者選択画面が再び表示されるが、その際、その患者について要対応登録されたことを示す表示がなされる。図４（ｂ）に示す例では、要対応登録された患者（患者００３）の欄の背景色が、図２（ｂ）に示すような最初の背景色である第１背景色（例えば白）から、第２背景色（例えばピンク）へと、変更されている。これにより、背景色が第２背景色である患者００３について、優先的な対応が必要であることが、観て判るようになる。
なお、要対応登録は、問診登録画面４１０ａ上で行う場合以外にも、例えば、図２（ｂ）の問診対象患者選択画面上で行えるようにしてもよい。具体的には、例えば、問診対象患者選択画面において、要対応登録したい患者の欄をスワイプ操作し、それにより現れる要対応登録ボタンを選択することにより、要対応登録を行えるようにしてもよい。
問診の回答内容の登録の後、医療関係者は、問診結果のアップロード操作を行う。具体的に、医療関係者は、図２（ｂ）（又は図４（ｂ））の問診対象患者選択画面において、問診が完了した患者を選択し、その後、機能選択アイコン４００を選択して、機能選択画面４００ａ（図２（ａ）参照。）をポップアップさせる。そして、医療関係者が機能選択画面４００ａにおいて問診データアップロードボタン４０４を選択すると、制御部３１は、その患者からの回答内容を含む問診結果情報１０４ａを、通信部３２に、医療情報サーバ１０に送信させる（アップロードする）。問診結果情報１０４ａには、患者からの回答内容（要対応フラグがある場合には、さらに要対応フラグ）の他に、患者ＩＤ、調査日（問診を行った日。以下同じ。）、及び診療科情報が含まれる。
一方、医療情報サーバ１０側では、通信部１２が問診結果情報１０４ａを問診端末３０から受信すると、制御部１１が、受信した問診結果情報１０４ａを、問診結果ＤＢ１０４に格納する。
一方、医療情報サーバ１０側では、通信部１２が問診結果情報１０４ａを問診端末３０から受信すると、制御部１１が、受信した問診結果情報１０４ａを、問診結果ＤＢ１０４に格納する。
以上のようにして、医療関係者は、図２（ｂ）の問診対象患者選択画面の一覧に挙げられた各患者について、問診を行い、各患者の問診結果をアップロードする。
なお、図２（ｂ）の問診対象患者選択画面において、医療関係者は、所望する患者が一覧に無い場合、機能選択アイコン４００を選択し、ポップアップされる機能選択画面４００ａ（図２（ａ）参照。）において新規登録ボタン４０２を選択して、新規の患者の患者ＩＤ及び氏名を登録することにより、その患者を一覧に追加することができる。
また、図２（ｂ）の問診対象患者選択画面において、医療関係者は、所望の患者を一覧から素早く見つけたい場合、機能選択アイコン４００を選択し、ポップアップされる機能選択画面４００ａにおいて患者検索ボタン４０３を選択して、患者ＩＤや氏名を入力することにより、所望の患者を一覧から検索することができる。
また、機能選択画面４００ａにおいて、医療関係者は、ログアウトボタン４０５を選択すると、ログアウトすることができる。ログアウトが完了すると、制御部３１は、問診プログラム３３ａの実行を終了する。
また、図２（ｂ）の問診対象患者選択画面において、医療関係者は、所望の患者を一覧から素早く見つけたい場合、機能選択アイコン４００を選択し、ポップアップされる機能選択画面４００ａにおいて患者検索ボタン４０３を選択して、患者ＩＤや氏名を入力することにより、所望の患者を一覧から検索することができる。
また、機能選択画面４００ａにおいて、医療関係者は、ログアウトボタン４０５を選択すると、ログアウトすることができる。ログアウトが完了すると、制御部３１は、問診プログラム３３ａの実行を終了する。
なお、上述した例に限らず、問診プログラム３３ａに基づく問診端末の機能は、様々な変形例が可能である。
例えば、問診プログラム３３ａは、外来患者用と入院患者用とで別々に設けられてもよい。その場合、制御部３１は、例えば、外来患者用の問診プログラム３３ａの実行中に、図２（ａ）に示す機能選択画面４００ａにおいて問診対象患者取得ボタン４０１が選択されると、医療情報サーバ１０の外来ＤＢ１０２及び患者基本情報ＤＢを介して、当日に外来予定のある患者の情報を取得し、そのリストを、図２（ｂ）の問診対象患者選択画面に表示する。また、制御部３１は、例えば、入院患者用の問診プログラム３３ａの実行中に、図２（ａ）に示す機能選択画面４００ａにおいて問診対象患者取得ボタン４０１が選択されると、医療情報サーバ１０の入院ＤＢ１０３及び患者基本情報ＤＢを介して、当日に入院している患者の情報を取得し、そのリストを、図２（ｂ）の問診対象患者選択画面に表示する。
例えば、問診プログラム３３ａは、外来患者用と入院患者用とで別々に設けられてもよい。その場合、制御部３１は、例えば、外来患者用の問診プログラム３３ａの実行中に、図２（ａ）に示す機能選択画面４００ａにおいて問診対象患者取得ボタン４０１が選択されると、医療情報サーバ１０の外来ＤＢ１０２及び患者基本情報ＤＢを介して、当日に外来予定のある患者の情報を取得し、そのリストを、図２（ｂ）の問診対象患者選択画面に表示する。また、制御部３１は、例えば、入院患者用の問診プログラム３３ａの実行中に、図２（ａ）に示す機能選択画面４００ａにおいて問診対象患者取得ボタン４０１が選択されると、医療情報サーバ１０の入院ＤＢ１０３及び患者基本情報ＤＢを介して、当日に入院している患者の情報を取得し、そのリストを、図２（ｂ）の問診対象患者選択画面に表示する。
また、問診端末３０の問診機能は、問診端末３０の操作者（医療関係者）が、問診に先立って、問診の対象としようとする患者が図２（ｂ）の問診対象患者選択画面の一覧にあるか否かに関わらず、問診端末３０を用いてＱＲコード（登録商標）又はバーコードのようなコード情報を読み取ることによって、その患者を問診端末３０上で特定（以下、「コード認証」ともいう。）できるように構成されてもよい。この場合、例えば、問診端末３０の操作者（医療関係者）は、まず、問診の対象としようとする患者から、図５に示すようなスクリーニングカード６０を提示してもらう。スクリーニングカード６０には、その患者のために事前に生成されたＱＲコード６１が印刷されている。このＱＲコード６１からは、その患者の基本情報（例えば、患者ＩＤ、フリガナ、及び生年月日）が読み取れるようにされている。一方、問診端末３０上では、図６（ａ）に示すように、問診対象患者選択画面に、ＱＲコードアイコン４２０が設けられる。ＱＲコードアイコン４２０が選択されると、制御部３１は、ＱＲコードの読み取り機能を起動させ、操作者の操作に応じて、スクリーニングカード６０に印刷されたＱＲコード６１を読み取る。すると、制御部３１は、図６（ｂ）に示すように、読み取ったＱＲコード６１から得られた患者の基本情報と、「問診を開始します。よろしいですか？」という質問文とを含む画面を、表示部３５に表示する。図６（ｂ）の画面で「ＯＫ」が選択されると、画面が図２（ｃ）の最初の問診画面へと切り換わり、問診が開始される。問診が終了した後、画面が図２（ｂ）の問診対象患者選択画面に戻った際には、仮に問診開始前にその患者が一覧に無かった場合でも、その患者が一覧に表示される。
なお、スクリーニングカード６０については、後に、図１７を参照しながらさらに詳しく説明する。
なお、スクリーニングカード６０については、後に、図１７を参照しながらさらに詳しく説明する。
また、問診端末３０の問診機能は、問診端末３０の操作者（医療関係者）が、図２（ｂ）の問診対象患者選択画面の一覧にある患者のうちいずれかに対して問診を実施できなかった場合に、そのことを登録（以下、「スキップ登録」ともいう。）できるように構成されてもよい。この場合、例えば、操作者は、図７（ａ）に示すように、問診対象患者選択画面において、問診を実施できなかった患者（患者００３）の欄を左側へスワイプすると、スキップボタン４３０が現れる。そして、操作者がスキップボタン４３０を選択すると、図７（ｂ）に示すスキップ理由選択画面４３０ａがポップアップする。スキップ理由選択画面４３０ａにおいて、操作者は、その患者に対して問診を実施できなかった理由を、「拒否（当日のみ）」、「拒否（今後全て）」、「理解不能／わからない」、及び「状態不良」の選択肢の中から入力できる。理由の入力がなされると、その入力内容が、スキップ登録情報として問診結果情報１０４ａに含まれて、記憶部３３に登録される。また、表示部３５の画面は、図２（ｂ）の問診対象患者選択画面へと戻るが、その際、その患者については問診がスキップされたことが判るような表示がなされる。具体的には、例えば、図４（ｂ）の例と同様に、問診がスキップされた患者（患者００３）の欄の背景色が、図２（ｂ）に示すような最初の背景色である第１背景色から、第３背景色（例えば黄色）へと変更されることにより、その患者については問診がスキップされたことが観て判るようにされる。ただし、上述した要対応フラグが立てられた患者であることを示す第２背景色と、問診がスキップされた患者であることを示す第３背景色とは、互いに異なるものとする。
なお、問診端末３０は、病院内で外来患者や入院患者に対して問診するために使用される場合に限られない。例えば、医療関係者が病院外にいる在宅患者を訪問する際に、在宅患者に対して問診するために使用されてもよい。
なお、問診項目の内容や順番は、本例のものに限られず、任意のものを用いてよい。
また、問診プログラム３３ａには、問診項目の変更や追加を可能にする機能が設けられてもよい。
また、問診プログラム３３ａには、問診項目の変更や追加を可能にする機能が設けられてもよい。
（医療情報サーバの機能）
次に、図８〜図１７を参照して、医療情報サーバ１０の機能について説明する。閲覧端末４０上で立ち上げられたウェブブラウザから医療情報サーバ１０がアクセスされると、まず、閲覧端末４０には、図８に示す機能選択画面が表示される。図８の機能選択画面には、問診結果ボタン５０１、痛みで困っている患者リストボタン５０２、除痛率ボタン５０３、処方量ボタン５０４、データ匿名化ボタン５０５、及び患者情報ボタン５０６が設けられている。これらのボタンは、それぞれ別々の機能に対応している。
以降、問診結果ボタン５０１、痛みで困っている患者リストボタン５０２、除痛率ボタン５０３、処方量ボタン５０４、データ匿名化ボタン５０５、及び患者情報ボタン５０６のそれぞれが選択された場合に、医療情報サーバ１０が実行する機能について、順番に説明する。なお、各機能は、医療情報サーバ１０の制御部１１が医療情報プログラム１００ａを実行することにより実現される。
次に、図８〜図１７を参照して、医療情報サーバ１０の機能について説明する。閲覧端末４０上で立ち上げられたウェブブラウザから医療情報サーバ１０がアクセスされると、まず、閲覧端末４０には、図８に示す機能選択画面が表示される。図８の機能選択画面には、問診結果ボタン５０１、痛みで困っている患者リストボタン５０２、除痛率ボタン５０３、処方量ボタン５０４、データ匿名化ボタン５０５、及び患者情報ボタン５０６が設けられている。これらのボタンは、それぞれ別々の機能に対応している。
以降、問診結果ボタン５０１、痛みで困っている患者リストボタン５０２、除痛率ボタン５０３、処方量ボタン５０４、データ匿名化ボタン５０５、及び患者情報ボタン５０６のそれぞれが選択された場合に、医療情報サーバ１０が実行する機能について、順番に説明する。なお、各機能は、医療情報サーバ１０の制御部１１が医療情報プログラム１００ａを実行することにより実現される。
−問診結果出力機能−
図８の機能選択画面において、問診結果ボタン５０１が選択された場合、医療情報サーバ１０は、問診結果出力機能を実行する。問診結果出力機能は、問診結果情報１０４ａの内容を出力する機能である。
図８の機能選択画面において、問診結果ボタン５０１が選択されると、まず、閲覧端末４０上の画面は、図９（ａ）の問診結果一覧画面に切り換わる。図９（ａ）の問診結果一覧画面には、問診が行われた日（調査日）の選択ボタン５１０ａ、５１０ｂが設けられている。図９（ａ）の問診結果一覧画面には、選択ボタン５１０ａ、５１０ｂによって選択された調査日（図９（ａ）の例では2015年１月19日）に得られた、問診結果の一覧が表示される。この問診結果の一覧には、問診結果毎（ひいては患者毎）に、連番項目５１１、患者ＩＤ項目５１２、患者氏名項目５１３、調査日項目５１４、及び診療科項目５１５の情報がそれぞれ表示されるとともに、問診票確認ボタン５１６が設けられる。
患者ＩＤ項目５１２及び診療科項目５１５の情報は、制御部１１が、問診結果ＤＢ１０４から、選択ボタン５１０ａ、５１０ｂにより選択された調査日に対応する問診結果情報１０４ａを抽出し、抽出した問診結果情報１０４ａから患者ＩＤ及び診療科情報を読み出すことによって、それぞれ取得される。また、患者氏名項目５１３の情報は、制御部１１が、患者基本情報ＤＢ１０１を参照して、上記読み出した患者ＩＤに対応する患者氏名を読み出すことによって、取得される。
図８の機能選択画面において、問診結果ボタン５０１が選択された場合、医療情報サーバ１０は、問診結果出力機能を実行する。問診結果出力機能は、問診結果情報１０４ａの内容を出力する機能である。
図８の機能選択画面において、問診結果ボタン５０１が選択されると、まず、閲覧端末４０上の画面は、図９（ａ）の問診結果一覧画面に切り換わる。図９（ａ）の問診結果一覧画面には、問診が行われた日（調査日）の選択ボタン５１０ａ、５１０ｂが設けられている。図９（ａ）の問診結果一覧画面には、選択ボタン５１０ａ、５１０ｂによって選択された調査日（図９（ａ）の例では2015年１月19日）に得られた、問診結果の一覧が表示される。この問診結果の一覧には、問診結果毎（ひいては患者毎）に、連番項目５１１、患者ＩＤ項目５１２、患者氏名項目５１３、調査日項目５１４、及び診療科項目５１５の情報がそれぞれ表示されるとともに、問診票確認ボタン５１６が設けられる。
患者ＩＤ項目５１２及び診療科項目５１５の情報は、制御部１１が、問診結果ＤＢ１０４から、選択ボタン５１０ａ、５１０ｂにより選択された調査日に対応する問診結果情報１０４ａを抽出し、抽出した問診結果情報１０４ａから患者ＩＤ及び診療科情報を読み出すことによって、それぞれ取得される。また、患者氏名項目５１３の情報は、制御部１１が、患者基本情報ＤＢ１０１を参照して、上記読み出した患者ＩＤに対応する患者氏名を読み出すことによって、取得される。
なお、図９（ａ）の問診結果一覧画面には、診療科選択ボタン５１７が設けられている。診療科選択ボタン５１７が選択されると、ユーザ（医療関係者）が所望の診療科を選択できる画面（図示せず）が、ポップアップする。そのポップアップした画面においていずれかの診療科が選択されると、図９（ａ）の問診結果一覧画面の一覧が、選択された診療科によって絞り込まれる。図９（ａ）の例では、このようにして、問診結果一覧画面の一覧が消化器内科によって絞り込まれている。
図９（ａ）の問診結果一覧画面において、いずれかの問診結果（ひいては患者）に対応する問診票確認ボタン５１６が選択されると、図９（ｂ）に示す問診結果表示画面に切り換わる。図９（ｂ）の問診結果表示画面では、その調査日にその患者から得られた問診結果の一覧が表示される。図９（ｂ）の例では、図２及び図３を参照して説明した第１〜第７の各問診項目に対する回答内容が表示される。なお、各問診項目に対する回答内容（問診結果情報に基づき得られる情報）は、制御部１１が、図９（ａ）の問診結果一覧画面で選択された問診票確認ボタン５１６に対応する問診結果情報１０４ａに含まれる回答内容を読み出すことによって、取得される。
問診結果出力機能によれば、例えば、医師が、所望の調査日に所望の患者から得られた問診結果の詳細を閲覧できるので、その情報を参考にして、その患者に対して行う診断や処方の内容を検討したり、過去にその患者に対して行った診断や処方の内容を評価したりすることができる。
図１０は、図９（ｂ）の問診結果表示画面の変形例を示している。図１０に示す問診結果表示画面は、図９（ｂ）の例と同様に各問診項目に対する回答内容（問診結果情報に基づき得られる情報）を表示するとともに、主治医等の医療関係者によって入力されるための対応欄５２０を含んでいる。対応欄５２０は、主治医等がその患者に対して具体的にどのような対応をしたのかを記入できるようにされている。図の例では、対応欄５２０には、複数の対応内容が表示されており、対応内容毎に空欄が設けられている。そのうちいずれか一つの空欄に、マウス操作等によりチェックが入力されると、対応欄５２０に隣接して設けられた対応確認アイコン５２１が、図示しない「未確認」という表示から、図１０に示す「確認済」という表示へと切り換わる。これにより、対応欄５２０への記入がなされたことが一目瞭然で判るようになる。
問診結果表示画面に対応欄５２０を設けることにより、例えば、看護師が患者に対して問診した結果だけでなく、その結果を受けて主治医等がどのような対応をしたのかも、記録することができる。これにより、例えば、患者が痛み等の不調を主張し続けているにも関わらず、主治医が具体的な対策を取っていなかったり、主治医が他の医療関係者に対応を依頼したにも関わらず患者の不調が取れていない等の現状の把握が可能となる。
なお、対応欄５２０は、図１０に示す形式のもの以外にも、例えば、主治医等がキーボード操作等により文字を入力できるような空欄からなるものでもよい。
問診結果表示画面に対応欄５２０を設けることにより、例えば、看護師が患者に対して問診した結果だけでなく、その結果を受けて主治医等がどのような対応をしたのかも、記録することができる。これにより、例えば、患者が痛み等の不調を主張し続けているにも関わらず、主治医が具体的な対策を取っていなかったり、主治医が他の医療関係者に対応を依頼したにも関わらず患者の不調が取れていない等の現状の把握が可能となる。
なお、対応欄５２０は、図１０に示す形式のもの以外にも、例えば、主治医等がキーボード操作等により文字を入力できるような空欄からなるものでもよい。
図１０に示す問診結果表示画面は、さらに、その患者が要対応登録されたことを示すフラグアイコン５２２を含んでいる。フラグアイコン５２２は、その患者の問診結果情報１０４ａに、上述した要対応フラグが含まれている場合に、表示される。これにより、問診結果表示画面を観た者が、その患者について優先的に対応する必要があることを把握できる。
さらに、図１０に示す問診結果表示画面は、ハサミボタン５２３を含んでいる。ハサミボタン５２３が選択されると、図１１に示すスクリーンキャプチャ用画面５２３ａがポップアップする。スクリーンキャプチャ用画面５２３ａは、問診結果表示画面よりも大幅に小さな画面であり、問診結果表示画面の表示内容の一部又は全部をコンパクトにまとめて表示する。電子カルテサーバ５０にアクセス可能な閲覧端末４０上で、このスクリーンキャプチャ用画面５２３ａが表示されることにより、ユーザは、閲覧端末４０を操作しながら、スクリーンキャプチャ用画面５２３ａを画像としてコピー（スクリーンキャプチャ）して、これをその患者の電子カルテ内の例えば診察記事欄等にペーストすることで、電子カルテ内に問診結果を保存できるようになる。
スクリーンキャプチャ用画面５２３ａを画像としてコピーする手段としては、例えば、閲覧端末４０のＯＳ（Operating System）がWindows（登録商標）であれば、その標準ツールであるSnipping Toolを用いることができ、閲覧端末４０のＯＳがMac OS（登録商標）であれば、その標準ツールであるGrabを用いることができる。
スクリーンキャプチャ用画面５２３ａを画像としてコピーする手段としては、例えば、閲覧端末４０のＯＳ（Operating System）がWindows（登録商標）であれば、その標準ツールであるSnipping Toolを用いることができ、閲覧端末４０のＯＳがMac OS（登録商標）であれば、その標準ツールであるGrabを用いることができる。
電子カルテの仕様によっては、画像が電子カルテ内に挿入される際に、電子カルテサーバ５０のプログラムによって、画像が電子カルテ用に決められたサイズ及び／又は解像度に変換される場合があり、その場合、変換されることによって画像の画質が損なわれるおそれがある。そこで、スクリーンキャプチャ用画面５２３ａは、電子カルテ用に決められたサイズ及び／又は解像度に変換された後でも文字を読み取れる程度に鮮明であるよう、画面サイズや文字のサイズ等が最適化されているのが好ましい。これにより、電子カルテ内に挿入されたスクリーンキャプチャ用画面５２３ａの画像が、電子カルテ内に挿入された際に文字がぼやけて読めなくなるのを防止できる。
図１１の例では、スクリーンキャプチャ用画面５２３ａは、問診結果表示画面に表示された患者ＩＤ、患者氏名、問診日、診療科、及び各問診項目に対する回答内容を表示している。図の例では、スクリーンキャプチャ用画面５２３ａは、回答が得られなかった問診項目も含めた全ての問診項目について表示しているが、回答が得られた問診項目についてのみ表示してもよく、その場合、さらなる画面のコンパクト化が可能である。
−痛みで困っている患者リスト出力機能−
図８の機能選択画面において、痛みで困っている患者リストボタン５０２が選択された場合、医療情報サーバ１０は、痛みで困っている患者リスト出力機能を実行する。痛みで困っている患者リスト出力機能は、問診端末３０による問診において、第１の問診項目「痛みでできないことや困っていることはありませんか？」（図２（ｃ））に対して、「ある」と回答した患者のリストを、出力する機能である。
図８の機能選択画面において、痛みで困っている患者リストボタン５０２が選択されると、まず、閲覧端末４０上の画面は、ユーザが所望の調査日及び診療科を選択できる画面（図示せず）に切り換わる。その調査日及び診療科の選択画面において、いずれかの調査日及び診療科が選択されると、図１２の痛みで困っている患者リスト画面に切り換わる。
図８の機能選択画面において、痛みで困っている患者リストボタン５０２が選択された場合、医療情報サーバ１０は、痛みで困っている患者リスト出力機能を実行する。痛みで困っている患者リスト出力機能は、問診端末３０による問診において、第１の問診項目「痛みでできないことや困っていることはありませんか？」（図２（ｃ））に対して、「ある」と回答した患者のリストを、出力する機能である。
図８の機能選択画面において、痛みで困っている患者リストボタン５０２が選択されると、まず、閲覧端末４０上の画面は、ユーザが所望の調査日及び診療科を選択できる画面（図示せず）に切り換わる。その調査日及び診療科の選択画面において、いずれかの調査日及び診療科が選択されると、図１２の痛みで困っている患者リスト画面に切り換わる。
図１２の痛みで困っている患者リスト画面には、上記の調査日及び診療科の選択画面で選択された調査日（図１２の例では2015年１月19日）に問診を受けた、上記選択された診療科（図１２の例では消化器内科）の患者のうち、痛みでできないことや困っていることのある患者の一覧が、表示される。痛みでできないことや困っていることのある患者の一覧には、患者毎に、連番項目５３１、患者ＩＤ項目５３２、患者氏名項目５３３、及び、困っていること項目５３４の情報がそれぞれ表示される。
患者ＩＤ項目５３２及び困っていること項目５３４の情報は、制御部１１が、問診結果ＤＢ１０４から、上記の調査日及び診療科の選択画面で選択された調査日に問診を受けた、上記選択された診療科の患者のうち、第１の問診項目「痛みでできないことや困っていることはありませんか？」（図２（ｃ））に対して、「ある」と回答した患者の問診結果情報１０４ａを抽出し、抽出した問診結果情報１０４ａから、患者ＩＤと、第２の問診項目「痛みによってできないことや困っていることはどんなことですか？」（図２（ｄ））に対する回答内容とを読み出すことによって、それぞれ取得される。また、患者氏名項目５３３の情報は、制御部１１が、患者基本情報ＤＢ１０１を参照して、上記読み出した患者ＩＤに対応する患者氏名を読み出すことによって、取得される。
患者ＩＤ項目５３２及び困っていること項目５３４の情報は、制御部１１が、問診結果ＤＢ１０４から、上記の調査日及び診療科の選択画面で選択された調査日に問診を受けた、上記選択された診療科の患者のうち、第１の問診項目「痛みでできないことや困っていることはありませんか？」（図２（ｃ））に対して、「ある」と回答した患者の問診結果情報１０４ａを抽出し、抽出した問診結果情報１０４ａから、患者ＩＤと、第２の問診項目「痛みによってできないことや困っていることはどんなことですか？」（図２（ｄ））に対する回答内容とを読み出すことによって、それぞれ取得される。また、患者氏名項目５３３の情報は、制御部１１が、患者基本情報ＤＢ１０１を参照して、上記読み出した患者ＩＤに対応する患者氏名を読み出すことによって、取得される。
なお、図１２の痛みで困っている患者リスト画面には、リスト出力ボタン５３５が設けられている。ユーザは、リスト出力ボタン５３５によって、画面に表示されている一覧に関する電子データの出力形式（例えばＰＤＦ形式又はＥＸＣＥＬ形式）を選択できる。リスト出力ボタン５３５によって、電子データの出力形式が選択されると、制御部１１は、選択された出力形式の電子データを生成して、閲覧端末４０に出力する。ユーザは、閲覧端末４０にて出力された電子データを、印刷機（図示せず）で印刷することもできる。
痛みで困っている患者リスト出力機能によれば、例えば、医師が、当日に痛みでできないことや困っていることのある患者のリストを閲覧できるので、それらの患者に対する痛みの治療の内容（鎮痛剤の処方量等）について見直しや改善をすることができる。
−除痛率出力機能−
図８の機能選択画面において、除痛率ボタン５０３が選択された場合、医療情報サーバ１０は、除痛率出力機能を実行する。除痛率出力機能は、例えば病院単位、診療科単位、又は医師単位等の任意の単位で観たときの、除痛率の算出結果を出力する機能である。
図８の機能選択画面において、除痛率ボタン５０３が選択された場合、医療情報サーバ１０は、除痛率出力機能を実行する。除痛率出力機能は、例えば病院単位、診療科単位、又は医師単位等の任意の単位で観たときの、除痛率の算出結果を出力する機能である。
ここで、「除痛率」とは、痛みでできないことや困っていることがなくなった患者の割合を指しており、具体的には、以下の式（１）により算出される。
除痛率 ＝ ｛Ｎ２／（Ｎ１+Ｎ２+Ｎ３）｝×１００ （％） ・・・（１）
式（１）において、Ｎ１は、痛みでできないことや困っていることがあり、かつ、痛みの治療を受けている患者の数であり、Ｎ２は、痛みでできないことや困っていることが無く、かつ、痛みの治療を受けている患者の数であり、Ｎ３は、痛みでできないことや困っていることがあり、かつ、痛みの治療を受けていない患者の数である。
除痛率 ＝ ｛Ｎ２／（Ｎ１+Ｎ２+Ｎ３）｝×１００ （％） ・・・（１）
式（１）において、Ｎ１は、痛みでできないことや困っていることがあり、かつ、痛みの治療を受けている患者の数であり、Ｎ２は、痛みでできないことや困っていることが無く、かつ、痛みの治療を受けている患者の数であり、Ｎ３は、痛みでできないことや困っていることがあり、かつ、痛みの治療を受けていない患者の数である。
制御部１１は、式（１）を用いて除痛率を算出するにあたって、問診結果ＤＢ１０４から、除痛率算出の対象とする患者の問診結果情報１０４ａをそれぞれ抽出し、抽出した各問診結果情報１０４ａから読み取れる問診の回答内容に基づいて、上記患者の数Ｎ１〜Ｎ３をそれぞれカウントする。より具体的に、痛みでできないことや困っていることがあり、かつ、痛みの治療を受けている患者の数Ｎ１は、除痛率算出の対象とする患者のうち、第１の問診項目「痛みでできないことや困っていることはありませんか？」（図２（ｃ））に対する回答が「ある」であり、かつ、第７の問診項目「鎮痛薬を服用していますか？」（図３（ｃ））に対する回答が「はい」であった患者の数を、カウントして取得する。同様に、痛みでできないことや困っていることが無く、かつ、痛みの治療を受けている患者の数Ｎ２は、除痛率算出の対象とする患者のうち、第１の問診項目に対する回答が「ない」であり、かつ、第７の問診項目に対する回答が「はい」であった患者の数を、カウントして取得する。また、痛みでできないことや困っていることがあり、かつ、痛みの治療を受けていない患者の数Ｎ３は、第１の問診項目に対する回答が「ある」であり、かつ、第７の問診項目に対する回答が「いいえ」であった患者の数を、カウントして取得する。
図８の機能選択画面において、除痛率ボタン５０３が選択されると、まず、閲覧端末４０上の画面は、除痛率の算出条件の選択画面（図示せず）に切り換わる。算出条件の選択画面では、例えば、ユーザが、除痛率算出の対象とする単位（病院単位、診療科単位、医師単位等）や期間等を選択できるようになっている。算出条件の選択画面で、算出条件が選択されると、制御部１１は、問診結果ＤＢ１０４から、選択された算出条件に合致する患者の問診結果情報１０４ａを抽出する。この際、制御部１１は、必要に応じて、患者基本情報ＤＢ１０１、外来ＤＢ１０２、及び／又は入院ＤＢ１０３も併せて参照してもよい。そして、制御部１１は、抽出した問診結果情報１０４ａを用いて、上述したように式（１）を用いて除痛率を算出する。その後、閲覧端末４０上の画面は、図１３の除痛率算出結果画面に切り換わる。
図１３の除痛率算出結果画面には、上記除痛率の算出条件の選択画面で選択された算出条件に従って制御部１１が行った、除痛率の算出結果が、表示される。図１３の例では、横軸を調査回次（回目）、縦軸を除痛率（％）としたときの、2013年及び2014年のそれぞれにおける除痛率の変化を表すグラフが、表示されている。ここで、調査回次とは、何回目の問診端末３０による問診結果かを示している。すなわち、図１３の例では、除痛率が、調査回次毎に算出されている。
なお、除痛率算出結果の出力方法は、図１３の例のものに限られない。この他にも、除痛率算出結果を、例えば、横軸を入院日数（日目）としたときの除痛率の変化を表すグラフにより出力してもよいし、あるいは、所定の日（例えば当日）の除痛率の値を表示するように出力してもよい。
なお、除痛率算出結果の出力方法は、図１３の例のものに限られない。この他にも、除痛率算出結果を、例えば、横軸を入院日数（日目）としたときの除痛率の変化を表すグラフにより出力してもよいし、あるいは、所定の日（例えば当日）の除痛率の値を表示するように出力してもよい。
除痛率出力機能によれば、例えば、医師が、所望の単位（病院単位等）で観たときの除痛率の変化の傾向や現時点での値等を把握できるので、その単位で行われてきた痛みの治療が十分に効果的であったか等を評価し、今後の痛みの治療（鎮痛剤の処方量等）の参考にすることができる。
−処方量出力機能−
図８の機能選択画面において、処方量ボタン５０４が選択されると、医療情報サーバ１０は、処方量出力機能を実行する。処方量出力機能は、ある単位（病院単位、診療科単位、医師単位、患者単位等）で、ある期間にわたって処方された、ある薬の処方量の集計結果を、出力する機能である。
図８の機能選択画面において、処方量ボタン５０４が選択されると、医療情報サーバ１０は、処方量出力機能を実行する。処方量出力機能は、ある単位（病院単位、診療科単位、医師単位、患者単位等）で、ある期間にわたって処方された、ある薬の処方量の集計結果を、出力する機能である。
図８の機能選択画面において、処方量ボタン５０４が選択されると、まず、閲覧端末４０上の画面は、処方量の算出条件の選択画面（図示せず）に切り換わる。処方量の算出条件の選択画面では、例えば、ユーザが、処方量算出の対象とする薬を、その薬種や用法等により選択したり、処方量算出の対象とする単位（病院単位等）や期間等を選択したりする。処方量の算出条件の選択画面で、処方量算出の条件が選択されると、制御部１１は、ＥＦファイルＤＢ１０５から、選択された期間に対応するＥＦファイル１０５ａを抽出する。そして、制御部１１は、抽出したＥＦファイル１０５ａと、対応関係記憶部１０６に記憶された対応関係情報１０６ａとを用いて、上記の処方量の算出条件の選択画面で選択された薬の、上記選択された期間にわたって処方された処方量の集計をとる。その際、制御部１１は、必要に応じて、他のＤＢ（患者基本情報ＤＢ１０１等）を参照してもよい。このときに制御部１１が行う処方量集計処理については、後にさらに詳しく説明する。制御部１１による処方量集計が完了した後、閲覧端末４０上の画面は、例えば図１４にそれぞれ示すような処方量集計結果画面５５１〜５５３に切り換わり、そこで処方量の集計結果が出力される。
図１４に示す処方量集計結果画面５５１〜５５３は、それぞれ別々の処方量集計結果の出力例を示している。
処方量集計結果画面５５１は、病院単位で、2010年4月から2012年12月までの期間にわたって処方された、複数の薬（本例では、医療用麻薬）のそれぞれの処方量の集計結果を、横軸を年月、縦軸を処方量（mg）としたときのグラフにより、表している。ここで、集計対象の薬は、それぞれ、薬種（例えばオキシコドン）及び用法（より具体的には、投与経路。例えば経口。）により、指定されている。
処方量集計結果画面５５２は、患者単位で、2010年4月から2012年12月までの期間にわたって処方された、ある特定の薬（図の例では、薬種：フェンタニル、用法：貼付）の処方量の集計結果を、横軸を処方量（mg）、縦軸を患者としたときのグラフにより、表している。
処方量集計結果画面５５３は、ある特定の患者に対して、2010年4月から2012年12月までの期間にわたって処方された、ある特定の薬（図の例では、薬種：フェンタニル、用法：貼付）の処方量の集計結果を、横軸を年月、縦軸を処方量（mg）としたときのグラフにより、表している。
なお、図１４の例に限られず、処方量集計結果の出力形式は、任意のものが可能である。
処方量集計結果画面５５１は、病院単位で、2010年4月から2012年12月までの期間にわたって処方された、複数の薬（本例では、医療用麻薬）のそれぞれの処方量の集計結果を、横軸を年月、縦軸を処方量（mg）としたときのグラフにより、表している。ここで、集計対象の薬は、それぞれ、薬種（例えばオキシコドン）及び用法（より具体的には、投与経路。例えば経口。）により、指定されている。
処方量集計結果画面５５２は、患者単位で、2010年4月から2012年12月までの期間にわたって処方された、ある特定の薬（図の例では、薬種：フェンタニル、用法：貼付）の処方量の集計結果を、横軸を処方量（mg）、縦軸を患者としたときのグラフにより、表している。
処方量集計結果画面５５３は、ある特定の患者に対して、2010年4月から2012年12月までの期間にわたって処方された、ある特定の薬（図の例では、薬種：フェンタニル、用法：貼付）の処方量の集計結果を、横軸を年月、縦軸を処方量（mg）としたときのグラフにより、表している。
なお、図１４の例に限られず、処方量集計結果の出力形式は、任意のものが可能である。
ここで、図１５及び図１６を参照して、制御部１１が行う処方量の集計処理についてさらに詳しく説明する。図１５は、一般的なＤＰＣのＥＦファイルの例を示している。
ＥＦファイルは、それぞれ異なるデータ項目に対応する列５６１〜５７１と、診療記録毎に設けられる行５８０とからなる、表形式で記入された、テキストファイルである。実際には、ＥＦファイルには、EF-1からEF-31までの計３１のデータ項目が設けられているが、図１５には、簡単のため、そのうち一部のデータ項目に対応する列５６１〜５７１のみを図示している。図１５に示すように、ＥＦファイルは、データ項目として、EF-1：施設コード５６１、EF-2：データ識別番号５６２、EF-5：データ区分５６３、EF-9：レセプト電算処理システム用コード５６４、EF-11：診療明細名称５６５、EF-12：使用量５６６、EF-21：行為回数５６７、EF-24：実施年月日５６８、EF-25：レセプト科区分５６９、EF-26：診療科区分５７０、及び、EF-27：医師コード５７１を有している。
データ識別番号５６２は、患者毎に与えられる固有の識別番号である。本例において、データ識別番号５６２は、病院内で用いられる患者ＩＤを所定の匿名化処理によって変換したものであり、所定の復号化処理によって、患者ＩＤに戻すことが可能なように、患者ＩＤと関連付けられている。匿名化処理や復号化処理は、例えば、それぞれ所定の計算式を求めることにより行ってもよいし、あるいは、データ識別番号５６２と患者ＩＤとの対応表を参照することにより行ってもよい。
データ区分５６３は、２桁の数列からなる。例えば、データ区分５６３が「５０」である場合、「手術」を表す。データ区分５６３が「２１」である場合、「内服」を表す。
ＥＦファイルは、それぞれ異なるデータ項目に対応する列５６１〜５７１と、診療記録毎に設けられる行５８０とからなる、表形式で記入された、テキストファイルである。実際には、ＥＦファイルには、EF-1からEF-31までの計３１のデータ項目が設けられているが、図１５には、簡単のため、そのうち一部のデータ項目に対応する列５６１〜５７１のみを図示している。図１５に示すように、ＥＦファイルは、データ項目として、EF-1：施設コード５６１、EF-2：データ識別番号５６２、EF-5：データ区分５６３、EF-9：レセプト電算処理システム用コード５６４、EF-11：診療明細名称５６５、EF-12：使用量５６６、EF-21：行為回数５６７、EF-24：実施年月日５６８、EF-25：レセプト科区分５６９、EF-26：診療科区分５７０、及び、EF-27：医師コード５７１を有している。
データ識別番号５６２は、患者毎に与えられる固有の識別番号である。本例において、データ識別番号５６２は、病院内で用いられる患者ＩＤを所定の匿名化処理によって変換したものであり、所定の復号化処理によって、患者ＩＤに戻すことが可能なように、患者ＩＤと関連付けられている。匿名化処理や復号化処理は、例えば、それぞれ所定の計算式を求めることにより行ってもよいし、あるいは、データ識別番号５６２と患者ＩＤとの対応表を参照することにより行ってもよい。
データ区分５６３は、２桁の数列からなる。例えば、データ区分５６３が「５０」である場合、「手術」を表す。データ区分５６３が「２１」である場合、「内服」を表す。
レセプト電算処理システム用コード５６４は、９桁の数列からなる。レセプト電算処理システム用コード５６４のうち、先頭の数字が「６」であるものは、医薬品を表す。その他のレセプト電算処理システム用コード５６４は、医薬品以外のものを表す。
なお、本例において、処方量の算出には、ＥＦファイルの、レセプト電算処理システム用コード５６４のうちの医薬品コードに対応する診療記録５８０のみが用いられる。このため、ＥＦファイルＤＢ１０５に記憶されるＥＦファイル１０５ａは、少なくとも、医薬品コードに対応する診療記録５８０のみを含んでいればよい。言い換えれば、ＥＦファイルＤＢ１０５には、様々なレセプト電算処理システム用コード５６４に対応する診療記録５８０が混在したＥＦファイルが格納されてもよいが、データ容量削減の観点から、医薬品コードに対応する診療記録５８０のみを含むＥＦファイルが格納されると、好適である。その場合、ＥＦファイルＤＢ１０５にＥＦファイル１０５ａが取り込まれる際に、ＥＦファイル内の、医薬品コード以外のレセプト電算処理システム用コード５６４に対応する診療記録５８０を削除するとよい。
なお、本例において、処方量の算出には、ＥＦファイルの、レセプト電算処理システム用コード５６４のうちの医薬品コードに対応する診療記録５８０のみが用いられる。このため、ＥＦファイルＤＢ１０５に記憶されるＥＦファイル１０５ａは、少なくとも、医薬品コードに対応する診療記録５８０のみを含んでいればよい。言い換えれば、ＥＦファイルＤＢ１０５には、様々なレセプト電算処理システム用コード５６４に対応する診療記録５８０が混在したＥＦファイルが格納されてもよいが、データ容量削減の観点から、医薬品コードに対応する診療記録５８０のみを含むＥＦファイルが格納されると、好適である。その場合、ＥＦファイルＤＢ１０５にＥＦファイル１０５ａが取り込まれる際に、ＥＦファイル内の、医薬品コード以外のレセプト電算処理システム用コード５６４に対応する診療記録５８０を削除するとよい。
図１６は、対応関係記憶部１０６に記憶される対応関係情報１０６ａの例を示している。対応関係情報１０６ａは、ＥＦファイルにおけるレセプト電算処理システム用コード５６４のうちの医薬品コード５９１と、所定の集計項目情報５９４〜５９６や換算係数５９７等との、対応関係を規定している。本例では、対応関係情報１０６ａにおいて、医薬品コード５９１として、医療用麻薬の医薬品コード５９１のみが挙げられている。
集計項目情報５９４〜５９６は、処方量の集計の際にそれぞれの集計項目での集計を可能にするための情報であり、本例では、薬種分類５９４（例えば「第１類」）、薬種５９５（例えば「モルヒネ」）、及び用法５９６（より具体的には、投与経路。例えば「経口」。）がある。なお、図１６の例において、薬種分類５９４が「１、２」と記載されているのは、第１類及び第２類の両方に該当することを指す。
ただし、集計項目情報として、これら以外の任意のものが、医薬品コード５９１と対応付けられてもよい。
換算係数５９７は、それぞれの薬をある一定の尺度（力価や量等）で換算するための係数である。本例では、換算係数５９７として、経口モルヒネ換算係数（それぞれの医療用麻薬を経口モルヒネに換算した場合の、薬の力価）が用いられている。ただし、換算係数５９７としては、これに限らず、例えば、国際麻薬統制委員会（INCB）により規定されるS-DDD（フェンタニル0.6mg＝オキシコドン75mg＝モルヒネ100mg）や、重量等、任意のものを用いてよい。
集計項目情報５９４〜５９６は、処方量の集計の際にそれぞれの集計項目での集計を可能にするための情報であり、本例では、薬種分類５９４（例えば「第１類」）、薬種５９５（例えば「モルヒネ」）、及び用法５９６（より具体的には、投与経路。例えば「経口」。）がある。なお、図１６の例において、薬種分類５９４が「１、２」と記載されているのは、第１類及び第２類の両方に該当することを指す。
ただし、集計項目情報として、これら以外の任意のものが、医薬品コード５９１と対応付けられてもよい。
換算係数５９７は、それぞれの薬をある一定の尺度（力価や量等）で換算するための係数である。本例では、換算係数５９７として、経口モルヒネ換算係数（それぞれの医療用麻薬を経口モルヒネに換算した場合の、薬の力価）が用いられている。ただし、換算係数５９７としては、これに限らず、例えば、国際麻薬統制委員会（INCB）により規定されるS-DDD（フェンタニル0.6mg＝オキシコドン75mg＝モルヒネ100mg）や、重量等、任意のものを用いてよい。
本例では、ＥＦファイル１０５ａにおける、１つの診療記録５８０に対応する処方量（診療記録５８０毎の処方量）を、次の式（２）により求める。
診療記録毎の処方量 ＝ Ａ×Ｔ×Ｃ ・・・（２）
式（２）において、Ａは、その診療記録５８０における使用量５６６であり、Ｔは、その診療記録５８０における行為回数５６７であり、Ｃは、その診療記録５８０のレセプト電算処理システム用コードにおける医薬品コード（５６４、５９１）に対して、対応関係情報１０６ａで対応付けされた、換算係数５９７である。
例えば、図１５に示すＥＦファイルの例において、上から２行目の診療記録５８０に対応する処方量を算出するにあたっては、使用量５６６（Ａ）が「２」であり、行為回数５６７（Ｔ）が「７」であり、レセプト電算処理システム用コード（医薬品コード）が「622017101」であり、対応関係情報１０６ａにおいてその医薬品コード「622017101」に対応付けられた換算係数５９７（Ｃ）が「１５」であることから、処方量は、Ａ×Ｔ×Ｃ＝２×７×１５＝２１０となる。
診療記録毎の処方量 ＝ Ａ×Ｔ×Ｃ ・・・（２）
式（２）において、Ａは、その診療記録５８０における使用量５６６であり、Ｔは、その診療記録５８０における行為回数５６７であり、Ｃは、その診療記録５８０のレセプト電算処理システム用コードにおける医薬品コード（５６４、５９１）に対して、対応関係情報１０６ａで対応付けされた、換算係数５９７である。
例えば、図１５に示すＥＦファイルの例において、上から２行目の診療記録５８０に対応する処方量を算出するにあたっては、使用量５６６（Ａ）が「２」であり、行為回数５６７（Ｔ）が「７」であり、レセプト電算処理システム用コード（医薬品コード）が「622017101」であり、対応関係情報１０６ａにおいてその医薬品コード「622017101」に対応付けられた換算係数５９７（Ｃ）が「１５」であることから、処方量は、Ａ×Ｔ×Ｃ＝２×７×１５＝２１０となる。
そして、閲覧端末４０上の上記処方量の算出条件の選択画面において、処方量の算出条件が選択されて、選択された算出条件が処方量の集計要求として医療情報サーバ１０に送信されると、制御部１１は、上記式（２）を用いて、処方量集計の要求により指定される条件に合う薬の処方量を集計する。
ここで、処方量集計の要求は、集計の対象とする薬を、ＥＦファイルにおける１つ以上のデータ項目（例えば、データ識別番号５６２、レセプト電算処理システム用コード（ひいては医薬品コード）５６４（５９１）、実施年月日５６８、レセプト科区分５６９、診療科区分５７０、医師コード５７１等）により指定してもよいし、対応関係情報１０６ａにおける１つ以上の集計項目情報５９４〜５９６により指定してもよい。それに加えて、処方量集計の要求は、期間を指定してもよい。
そして、制御部１１は、処方量の集計にあたって、閲覧端末４０からの処方量集計の要求により指定される条件に合う薬に対応する医薬品コードを、ＥＦファイル１０５ａや対応関係情報１０６ａから抽出し、抽出した各医薬品コードに対応する診療記録５８０をＥＦファイル１０５ａから抽出し、抽出した各診療記録５８０毎の処方量を、式（２）により算出して、積算（加算）する。
例えば、処方量集計の要求が、薬種分類が「１」であり、薬種が「モルヒネ」であり、用法が「経口」である薬を指定する場合、まず、対応関係情報１０６ａを参照して、指定された条件に合致する薬種分類５９４、薬種５９５、及び用法５９６に対応する医薬品コード５９１を抽出する。図１６の例では、そのような医薬品コード５９１として、「618110023」と「618110024」が抽出される。次に、ＥＦファイル１０５ａを参照して、上記抽出した医薬品コード「618110023」又は「618110024」に対応する診療記録５８０を抽出する。図１５の例では、そのような診療記録５８０として、上から５行目及び６行目の診療記録５８０が抽出される。次に、抽出した診療記録５８０毎の処方量を算出して積算し、その積算結果を、そのＥＦファイル１０５ａに対応する処方量の集計結果として得る。
なお、処方量集計の要求によって、複数の月にわたる期間が指定された場合、ＥＦファイルＤＢ１０５から、上記指定された月にそれぞれ対応するＥＦファイル１０５ａを読み出して、各ＥＦファイル１０５ａに基づく処方量の集計結果どうしを積算することとなる。
ここで、処方量集計の要求は、集計の対象とする薬を、ＥＦファイルにおける１つ以上のデータ項目（例えば、データ識別番号５６２、レセプト電算処理システム用コード（ひいては医薬品コード）５６４（５９１）、実施年月日５６８、レセプト科区分５６９、診療科区分５７０、医師コード５７１等）により指定してもよいし、対応関係情報１０６ａにおける１つ以上の集計項目情報５９４〜５９６により指定してもよい。それに加えて、処方量集計の要求は、期間を指定してもよい。
そして、制御部１１は、処方量の集計にあたって、閲覧端末４０からの処方量集計の要求により指定される条件に合う薬に対応する医薬品コードを、ＥＦファイル１０５ａや対応関係情報１０６ａから抽出し、抽出した各医薬品コードに対応する診療記録５８０をＥＦファイル１０５ａから抽出し、抽出した各診療記録５８０毎の処方量を、式（２）により算出して、積算（加算）する。
例えば、処方量集計の要求が、薬種分類が「１」であり、薬種が「モルヒネ」であり、用法が「経口」である薬を指定する場合、まず、対応関係情報１０６ａを参照して、指定された条件に合致する薬種分類５９４、薬種５９５、及び用法５９６に対応する医薬品コード５９１を抽出する。図１６の例では、そのような医薬品コード５９１として、「618110023」と「618110024」が抽出される。次に、ＥＦファイル１０５ａを参照して、上記抽出した医薬品コード「618110023」又は「618110024」に対応する診療記録５８０を抽出する。図１５の例では、そのような診療記録５８０として、上から５行目及び６行目の診療記録５８０が抽出される。次に、抽出した診療記録５８０毎の処方量を算出して積算し、その積算結果を、そのＥＦファイル１０５ａに対応する処方量の集計結果として得る。
なお、処方量集計の要求によって、複数の月にわたる期間が指定された場合、ＥＦファイルＤＢ１０５から、上記指定された月にそれぞれ対応するＥＦファイル１０５ａを読み出して、各ＥＦファイル１０５ａに基づく処方量の集計結果どうしを積算することとなる。
なお、処方量の集計にあたって、上述のようにして得られた処方量の積算結果から、手術当日に注射により投与された薬の処方量を差し引いて、最終的な処方量の集計結果として出力してもよい。
その場合、手術当日に注射により投与された薬の処方量を算出するにあたっては、まず、ＥＦファイル１０５ａから、データ区分５６３が「５０」である診療記録５８０を読み込んで、読み込んだ診療記録５８０の実施年月日５６８から、手術日を特定する。そして、ＥＦファイル１０５ａから、上記特定した手術日（実施年月日５６８）に該当する診療記録５８０を抽出する。一方、対応関係情報１０６ａを参照して、用法５９６が「注射」である医薬品コード５９１を抽出する。そして、ＥＦファイル１０５ａから抽出した診療記録５８０のうち、用法５９６が「注射」である医薬品コード５６４、５９１に対応するものを抽出して、抽出した診療記録５８０毎の処方量を、上記式（２）を用いて算出し積算する。
その場合、手術当日に注射により投与された薬の処方量を算出するにあたっては、まず、ＥＦファイル１０５ａから、データ区分５６３が「５０」である診療記録５８０を読み込んで、読み込んだ診療記録５８０の実施年月日５６８から、手術日を特定する。そして、ＥＦファイル１０５ａから、上記特定した手術日（実施年月日５６８）に該当する診療記録５８０を抽出する。一方、対応関係情報１０６ａを参照して、用法５９６が「注射」である医薬品コード５９１を抽出する。そして、ＥＦファイル１０５ａから抽出した診療記録５８０のうち、用法５９６が「注射」である医薬品コード５６４、５９１に対応するものを抽出して、抽出した診療記録５８０毎の処方量を、上記式（２）を用いて算出し積算する。
なお、処方量の集計は、ＥＦファイル１０５ａのデータ項目や対応関係情報１０６ａで予め規定された集計項目情報以外の条件によって、行ってもよい。
例えば、患者基本情報ＤＢ１０１に記憶される患者基本情報１０１ａにおける、疾患有無情報（本例では、がんと診断されたか否かを表す情報）を用いて、がん患者とそうでない患者とに分けて処方量の集計を行ってもよい。
その場合、処方量の集計にあたって、ＥＦファイル１０５ａの各データ識別番号５６２を、患者ＩＤに復号化する必要がある。これにより、患者ＩＤを用いて、ＥＦファイル１０５ａの診療記録５８０と患者基本情報１０１ａにおける疾患有無情報とを紐付けできる。
また、がん患者に対する処方量の集計を行う場合、図示しない院内がん登録システムから、その患者ががんと診断された日（がん診断日）を特定し、ＥＦファイル１０５ａにおける実施年月日５６８から、上記特定したがん診断日以降の診療記録５８０のみを抽出し、抽出した診療記録５８０を用いて集計してもよい。
例えば、患者基本情報ＤＢ１０１に記憶される患者基本情報１０１ａにおける、疾患有無情報（本例では、がんと診断されたか否かを表す情報）を用いて、がん患者とそうでない患者とに分けて処方量の集計を行ってもよい。
その場合、処方量の集計にあたって、ＥＦファイル１０５ａの各データ識別番号５６２を、患者ＩＤに復号化する必要がある。これにより、患者ＩＤを用いて、ＥＦファイル１０５ａの診療記録５８０と患者基本情報１０１ａにおける疾患有無情報とを紐付けできる。
また、がん患者に対する処方量の集計を行う場合、図示しない院内がん登録システムから、その患者ががんと診断された日（がん診断日）を特定し、ＥＦファイル１０５ａにおける実施年月日５６８から、上記特定したがん診断日以降の診療記録５８０のみを抽出し、抽出した診療記録５８０を用いて集計してもよい。
処方量出力機能によれば、例えば、医療関係者は、処方量の集計結果を知ることができるので、より適切に、痛みの治療の評価や改善をすることが可能となる。また、ＤＰＣ制度により標準化されたＥＦファイルを用いて、上記式（２）により、薬の処方量を集計するので、ＤＰＣ制度の対象となる各病院で、容易に適用できる。よって、汎用性を向上できる。なお、ＥＦファイルの代わりに、電子カルテに基づいて処方量を自動的に集計するようなプログラムやシステムを構築することも可能ではあるが、病院毎に電子カルテのベンダー（ひいては仕様）が異なることから、そのようなプログラムやシステムは、汎用性が低く、数多くの病院へ適用することが困難である。
また、本例では、ＥＦファイルＤＢ１０５に記憶されるＥＦファイル１０５ａのデータ識別番号５６２が、病院内で患者毎に与えられる患者ＩＤと関連付けられている。これにより、必要に応じて、ＥＦファイル１０５ａのデータ識別番号５６２を復号化することにより、患者ＩＤによって、ＥＦファイル１０５ａの診療記録５８０を、患者ＩＤを含む他のあらゆる情報（例えば、患者基本情報１０１ａ、外来情報１０２ａ、入院情報１０３ａ、問診結果情報１０４ａ等）と紐付けできる。これによって、例えば、患者基本情報１０１ａにおける疾患有無情報や、院内がん登録システム（図示せず）から得られるがん診断日情報を用いて、処方量を集計したり、あるいは、ある特定の患者の問診結果情報１０４ａとその患者の処方量の集計結果とを、同時に閲覧端末４０に表示させたりすることが、可能となる。
−データ匿名化及び出力機能−
図８の機能選択画面において、データ匿名化ボタン５０５が選択された場合、医療情報サーバ１０は、データ匿名化及び出力機能を実行する。データ匿名化及び出力機能は、医療情報サーバ１０に蓄積された種々のデータを匿名化した上でファイルとして出力する機能である。出力されたファイルは、例えば、暗号化されてからＵＳＢ等の外部記憶媒体に格納されて、外部の機関にデータ解析のために送付される。匿名化及び出力されるデータは、例えば、問診結果や処方量集計結果等である。
ここで、医療情報サーバ１０は、匿名化処理として、連結可能匿名化を行うのが好ましい。この場合、医療情報サーバ１０は、匿名化の際に、匿名化前の患者ＩＤと匿名化後の患者ＩＤとを対応付ける対比表を作成し、内部に保管する。これにより、データを送付した先の外部機関から、ある患者について背景等の問い合わせがあった場合等に対応できる。
ただし、医療情報サーバ１０は、連結不可能匿名化を行ってもよい。
図８の機能選択画面において、データ匿名化ボタン５０５が選択された場合、医療情報サーバ１０は、データ匿名化及び出力機能を実行する。データ匿名化及び出力機能は、医療情報サーバ１０に蓄積された種々のデータを匿名化した上でファイルとして出力する機能である。出力されたファイルは、例えば、暗号化されてからＵＳＢ等の外部記憶媒体に格納されて、外部の機関にデータ解析のために送付される。匿名化及び出力されるデータは、例えば、問診結果や処方量集計結果等である。
ここで、医療情報サーバ１０は、匿名化処理として、連結可能匿名化を行うのが好ましい。この場合、医療情報サーバ１０は、匿名化の際に、匿名化前の患者ＩＤと匿名化後の患者ＩＤとを対応付ける対比表を作成し、内部に保管する。これにより、データを送付した先の外部機関から、ある患者について背景等の問い合わせがあった場合等に対応できる。
ただし、医療情報サーバ１０は、連結不可能匿名化を行ってもよい。
−患者情報登録機能−
図８の機能選択画面において、患者情報ボタン５０６が選択された場合、医療情報サーバ１０は、患者情報登録機能を実行する。患者情報登録機能は、医療関係者による患者基本情報１０１ａの手入力を受け付ける機能である。患者情報登録機能により入力された患者基本情報１０１ａは、患者基本情報ＤＢ１０１に格納される。
図８の機能選択画面において、患者情報ボタン５０６が選択されると、図１７に示す患者情報一覧画面が表示される。図１７の例では、当日に新規登録された患者の一覧が表示されている。
図１７の患者情報一覧画面には、新規登録ボタン６２０があり、これが選択されると、患者新規登録画面６２０ａがポップアップする。患者新規登録画面６２０ａでは、患者基本情報１０１ａ（患者ＩＤ、氏名、カナ氏名、生年月日、性別、及び疾患有無情報）をキーボード操作により入力できるようにされている。患者新規登録画面６２０ａにおいて登録ボタン６２１が選択されると、入力された患者基本情報１０１ａが患者基本情報ＤＢ１０１に登録される。
図８の機能選択画面において、患者情報ボタン５０６が選択された場合、医療情報サーバ１０は、患者情報登録機能を実行する。患者情報登録機能は、医療関係者による患者基本情報１０１ａの手入力を受け付ける機能である。患者情報登録機能により入力された患者基本情報１０１ａは、患者基本情報ＤＢ１０１に格納される。
図８の機能選択画面において、患者情報ボタン５０６が選択されると、図１７に示す患者情報一覧画面が表示される。図１７の例では、当日に新規登録された患者の一覧が表示されている。
図１７の患者情報一覧画面には、新規登録ボタン６２０があり、これが選択されると、患者新規登録画面６２０ａがポップアップする。患者新規登録画面６２０ａでは、患者基本情報１０１ａ（患者ＩＤ、氏名、カナ氏名、生年月日、性別、及び疾患有無情報）をキーボード操作により入力できるようにされている。患者新規登録画面６２０ａにおいて登録ボタン６２１が選択されると、入力された患者基本情報１０１ａが患者基本情報ＤＢ１０１に登録される。
さらに、図１７の患者情報一覧画面には、印刷ボタン６２１があり、これが選択されると、患者情報一覧画面に表示された各患者のための、スクリーニングカード６０（図５参照。）が印刷される。図５に示すスクリーニングカード６０には、患者新規登録画面６２０で入力された患者基本情報１０１ａのうち、患者ＩＤ、氏名、カナ氏名、生年月日、及び性別が表示されているとともに、これらの情報が読み取れるように生成されたＱＲコード６１が表示されている。
なお、スクリーニングカード６０は、問診対象者のみに発行されてもよい。この場合、例えば、印刷ボタン６２１が選択されると、患者情報一覧画面に表示された患者のうち、患者基本情報１０１ａの疾患有無情報が「疾患有り」とされた患者のみのスクリーニングカード６０が印刷されるようにしてもよい。
スクリーニングカード６０は、病院の診察券と同様に、患者に保管してもらう。
また、ＱＲコード６１は、医療関係者によって、その患者の電子カルテに挿入されて、病院側でも管理されてもよい。その場合、問診端末３０は、問診に先立って行われるコード認証（図６参照。）の際に、電子カルテに挿入されたＱＲコード６１を読み取ることにより、問診対象患者を特定してもよい。
なお、スクリーニングカード６０は、問診対象者のみに発行されてもよい。この場合、例えば、印刷ボタン６２１が選択されると、患者情報一覧画面に表示された患者のうち、患者基本情報１０１ａの疾患有無情報が「疾患有り」とされた患者のみのスクリーニングカード６０が印刷されるようにしてもよい。
スクリーニングカード６０は、病院の診察券と同様に、患者に保管してもらう。
また、ＱＲコード６１は、医療関係者によって、その患者の電子カルテに挿入されて、病院側でも管理されてもよい。その場合、問診端末３０は、問診に先立って行われるコード認証（図６参照。）の際に、電子カルテに挿入されたＱＲコード６１を読み取ることにより、問診対象患者を特定してもよい。
なお、問診対象者について、患者基本情報１０１ａの患者基本情報ＤＢ１０１への登録に加えて、外来情報１０２ａ及び入院情報１０３ａの外来ＤＢ１０２及び入院ＤＢ１０３への登録も、電子カルテサーバ５０を経由せずに行われても良い。これにより、仮に電子カルテサーバ５０からこれらの情報が医療情報サーバ１０へ自動的に送信されるようにするために必要となる、事前の電子カルテのベンダーとの調整に掛かる費用や手間を、無くすことができる。
この場合、問診対象者のうちの外来患者については、問診時に、その患者のＱＲコード６１からのコード認証が実施され、さらに問診結果情報１０４ａが医療情報サーバ１０に登録される際に、問診結果情報１０４ａに基づいて、外来情報１０２ａが外来ＤＢ１０２に自動登録されるようにしてもよい。このとき、外来情報１０２ａの予約日付として、問診実施日が登録される。
また、問診対象者のうちの入院患者については、初回の問診時に、その患者のＱＲコード６１からのコード認証が実施され、さらに問診結果情報１０４ａが医療情報サーバ１０に登録される際に、問診結果情報１０４ａに基づいて、入院情報１０２ａが入院ＤＢ１０３に自動登録されるようにしてもよい。このとき、入院情報１０２ａの入院日として、初回の問診実施日が登録される。また、入院情報１０２ａの退院日は、医療関係者によって手入力されてもよいし、あるいは、例えば、問診結果情報１０４ａの登録が所定日数にわたって無かった場合に、最後に問診結果情報１０４ａが登録された日の翌日を退院日として自動登録されてもよい。
この場合、問診対象者のうちの外来患者については、問診時に、その患者のＱＲコード６１からのコード認証が実施され、さらに問診結果情報１０４ａが医療情報サーバ１０に登録される際に、問診結果情報１０４ａに基づいて、外来情報１０２ａが外来ＤＢ１０２に自動登録されるようにしてもよい。このとき、外来情報１０２ａの予約日付として、問診実施日が登録される。
また、問診対象者のうちの入院患者については、初回の問診時に、その患者のＱＲコード６１からのコード認証が実施され、さらに問診結果情報１０４ａが医療情報サーバ１０に登録される際に、問診結果情報１０４ａに基づいて、入院情報１０２ａが入院ＤＢ１０３に自動登録されるようにしてもよい。このとき、入院情報１０２ａの入院日として、初回の問診実施日が登録される。また、入院情報１０２ａの退院日は、医療関係者によって手入力されてもよいし、あるいは、例えば、問診結果情報１０４ａの登録が所定日数にわたって無かった場合に、最後に問診結果情報１０４ａが登録された日の翌日を退院日として自動登録されてもよい。
医療情報サーバ１０は、上述した機能以外の様々な機能を有してよい。例えば、医療情報サーバ１０は、問診結果ＤＢ１０４に格納された問診結果情報１０４ａに基づいて、問診実施者数や問診実施率を算出する機能を有してもよい。問診実施者数や問診実施率の算出の対象とする単位（病院単位、診療科単位、医師単位等）や期間（１日、１週間等）は、ユーザが任意に設定可能とする。問診実施者数や問診実施率を算出する際には、問診結果情報１０４ａに含まれるスキップ登録情報を参照するとよい。これにより、例えば、問診対象者の数からスキップ登録された患者の数を差し引くことにより、実際に問診を受けた患者の数（問診実施者数）を算出できる。
以上説明したように、本実施形態の医療情報システム１では、医療情報サーバ１０が、閲覧端末４０からの要求に応じて、問診結果データベース１０４に記憶された問診結果情報１０４ａに基づき得られる情報を、閲覧端末４０に出力可能であり、また、問診結果情報１０４ａの回答内容には、痛みによりできないことや困っていることがあるか否かを問う第１の問診項目に対する回答内容が含まれている。これにより、患者からの痛みに関する問診結果に基づき得られる情報を、容易に医療関係者にフィードバックできる。医療関係者は、このフィードバックされる情報に基づいて、より適切に、患者に対する痛みの治療の評価や改善等が可能となる。
なお、上述した「痛みでできないことや困っていることはありませんか？」という質問は、実際に患者が感じている痛みのレベルが高いほど、「ある」と回答する患者の割合が高くなる、という傾向が得られるものであることが、臨床的に判った結果によるものである。すなわち、この質問に対する回答結果に基づいて得られる情報を医療関係者にフィードバックすることで、医療関係者は、それまで行われてきた痛みの治療の内容（医療用麻薬の処方量等）について、より適切に評価することができる。これに対し、例えば、上記の質問の代わりに、「痛みはありますか？」又は「痛みは十分に取れていますか？」等という、痛みの有無を直接問う質問を患者にした場合、さほど、実際に患者が感じている痛みのレベルの高さに応じた回答内容の変化を得ることができず、ひいては、痛みの治療の評価をさほど適切に行うことができない。これは、患者が、医師への遠慮等からの心理的原因で、痛みがさほど取れていなくとも、「ない」、「取れている」等と回答する場合があるからである。
また、本例では、問診端末３０が、患者に対する問診の際に問診画面で入力された回答内容と患者の患者ＩＤと問診の実施日情報とを含む問診結果情報１０４ａを、医療情報サーバ１０へ送信可能であり、医療情報サーバ１０は、問診結果情報１０４ａを問診端末３０から受信すると、該問診結果情報１０４ａを問診結果ＤＢ１０４に格納する。これによれば、問診端末３０によって自動的に問診結果が電子化されて、医療情報サーバ１０に蓄積されるので、例えば紙ベースで記録された問診結果を、医療関係者等によって電子化し、蓄積する作業等が不要となり、利便性が向上される。これにより、例えば、医師は、問診完了後に迅速に（例えば患者の診察前に）、問診結果を参照できるようになる。
また、本例では、医療情報サーバ１０にアクセスする医療関係者が、上述した「問診結果出力機能」、「痛みで困っている患者リスト出力機能」、及び「除痛率出力機能」のそれぞれによって、患者からの問診結果に関する情報を得ることができるとともに、「処方量出力機能」によって、患者に対する処方量に関する情報を得ることができる。これにより、医療関係者は、例えば、それまで行われてきた痛みの治療が適切であったか等の評価を、より適切に行うことができる。
例えば、本例の医療情報システム１は、病院において、医療関係者が次のようなＰＤＣＡ（Plan-Do-Check-Adjust）サイクルをまわすのに好適に適用できる。
（１）問診端末３０を用いて、毎日、痛みとつらさに関する聞き取りを実施。
（２）「痛みでできないことや困っていることはありませんか？」という質問で、介入対象患者の見える化。
（３）医療情報サーバ１０を用いて、痛みでできないことや困っていることのある患者を一覧化。
（４）多忙な現場で遅滞なく、医師に痛みでできないことや困っていることのある患者をフィードバック。
（５）医師が痛みでできないことや困っていることのある患者の聞き取り内容を確認し、医療用麻薬の処方量を増やすなどの緩和的介入をする。
（６）上記（１）〜（５）までのプロセスが毎日繰り返されて、数カ月後、医療情報サーバ１０を用いて、EFファイルに基づき医療用麻薬処方量を算出し、医師に行動変容が起きたか否か、及び改善サイクルがまわっているかを確認。
本例の医療情報システム１は、このようなＰＤＣＡサイクルをまわすために、好適にサポートできるものである。
例えば、本例の医療情報システム１は、病院において、医療関係者が次のようなＰＤＣＡ（Plan-Do-Check-Adjust）サイクルをまわすのに好適に適用できる。
（１）問診端末３０を用いて、毎日、痛みとつらさに関する聞き取りを実施。
（２）「痛みでできないことや困っていることはありませんか？」という質問で、介入対象患者の見える化。
（３）医療情報サーバ１０を用いて、痛みでできないことや困っていることのある患者を一覧化。
（４）多忙な現場で遅滞なく、医師に痛みでできないことや困っていることのある患者をフィードバック。
（５）医師が痛みでできないことや困っていることのある患者の聞き取り内容を確認し、医療用麻薬の処方量を増やすなどの緩和的介入をする。
（６）上記（１）〜（５）までのプロセスが毎日繰り返されて、数カ月後、医療情報サーバ１０を用いて、EFファイルに基づき医療用麻薬処方量を算出し、医師に行動変容が起きたか否か、及び改善サイクルがまわっているかを確認。
本例の医療情報システム１は、このようなＰＤＣＡサイクルをまわすために、好適にサポートできるものである。
本発明の医療情報システムは、病院等で利用できる。
１：医療情報システム、 １０：医療情報サーバ、 １１、３１：制御部、 １２、３２：通信部、 １３、３３：記憶部、 ２０：クライアント端末、 ３０：問診端末（クライアント端末）、 ３３ａ：問診プログラム、 ３４：入力部、 ３５：表示部、 ４０：閲覧端末（クライアント端末）、 ５０：電子カルテサーバ、 ６０：スクリーニングカード、 ６１：ＱＲコード、 １００：プログラム記憶部、 １００ａ：医療情報プログラム、 １０１：患者基本情報ＤＢ、 １０１ａ：患者基本情報、 １０２：外来ＤＢ、 １０２ａ：外来情報、 １０３：入院ＤＢ、 １０３ａ：入院情報、 １０４：問診結果ＤＢ、 １０４ａ：問診結果情報、 １０５：ＥＦファイルＤＢ、 １０５ａ：ＥＦファイル、 １０６：対応関係記憶部、 １０６ａ：対応関係情報、 ４００：機能選択アイコン、 ４００ａ：機能選択画面、 ４０１：問診対象患者取得ボタン、 ４０２：新規登録ボタン、 ４０３：患者検索ボタン、 ４０４：問診データアップロードボタン、 ４０５：ログアウトボタン、 ４１０：問診登録ボタン、 ４１０ａ：問診登録画面、 ４１１：通常登録ボタン、 ４１２：要対応登録ボタン、 ４２０：ＱＲコードアイコン、 ４３０：スキップボタン、 ４３０ａ：スキップ理由選択画面、 ５０１：問診結果ボタン、 ５０２：痛みで困っている患者リストボタン、 ５０３：除痛率ボタン、 ５０４：処方量ボタン、 ５０５：データ匿名化ボタン、 ５０６：患者情報ボタン、 ５１０ａ、５１０ｂ：問診が行われた日（調査日）の選択ボタン、 ５１１、５３１：連番項目、 ５１２、５３２：患者ＩＤ項目、 ５１３、５３３：患者氏名項目、 ５１４：調査日項目、 ５１５：診療科項目、 ５１６：問診票確認ボタン、 ５１７：診療科選択ボタン、 ５２０：対応欄、 ５２１：対応確認アイコン、 ５２２：フラグアイコン、 ５２３：ハサミボタン、 ５２３ａ：スクリーンキャプチャ用画面、 ５３４：困っていること項目、 ５３５：リスト出力ボタン、 ５５１〜５５３：処方量集計結果画面、 ５６１：施設コード、 ５６２：データ識別番号、 ５６３：データ区分、 ５６４：レセプト電算処理システム用コード、 ５６５：診療明細名称、 ５６６：使用量、 ５６７：行為回数、 ５６８：実施年月日、 ５６９：レセプト科区分、５７０：診療科区分、５７１：医師コード、 ５８０：診療記録、 ５９１：レセプト電算処理システム用コードのうちの医薬品コード、 ５９２：名称、 ５９３：単位名称、 ５９４：薬種分類（集計項目情報）、 ５９５：薬種（集計項目情報）、 ５９６：用法（集計項目情報）、 ５９７：換算係数、 ６００：医薬品コード毎の対応関係、 ６２０：新規登録ボタン、 ６２０ａ：患者新規登録画面、 ６２１：印刷ボタン
Claims (7)
- 医療情報サーバと、
前記医療情報サーバと通信可能な閲覧端末と、
を備えた、医療情報システムであって、
前記医療情報サーバは、
患者に対する問診の際に前記患者から得られた回答内容と前記患者の患者ＩＤと前記問診の実施日情報とを少なくとも含む、問診結果情報を複数記憶する、問診結果データベースを備えているとともに、
前記閲覧端末からの要求に応じて、前記問診結果データベースに記憶された前記問診結果情報に基づき得られる情報を、前記閲覧端末に出力可能であり、
前記問診結果情報の前記回答内容には、痛みによりできないことや困っていることがあるか否かを問う第１問診項目に対する回答内容が含まれていることを特徴とする、医療情報システム。 - 前記医療情報サーバと通信可能な問診端末をさらに備え、
前記問診端末は、
問診項目の内容が表示されるとともに前記問診項目に対する回答内容を入力可能な、問診画面を、表示可能であるとともに、
患者に対する問診の際に前記問診画面で入力された回答内容と前記患者の患者ＩＤと前記問診の実施日情報とを含む前記問診結果情報を、前記医療情報サーバへ送信可能であり、
前記医療情報サーバは、前記問診結果情報を前記問診端末から受信すると、該問診結果情報を前記問診結果データベースに格納する、請求項１に記載の医療情報システム。 - 前記医療情報サーバは、前記閲覧端末から、所定の患者から所定の日に得られた問診結果の出力要求があると、前記問診結果データベースから、前記所定の患者及び前記所定の日に対応する前記問診結果情報を抽出し、抽出した前記問診結果情報に基づき得られる情報を、前記閲覧端末に出力する、請求項１又は２に記載の医療情報システム。
- 前記医療情報サーバは、前記閲覧端末から、痛みによりできないことや困っていることがある患者のリストの出力要求があると、前記問診結果データベースに記憶された前記問診結果情報に基づいて、前記第１問診項目に対して「ある」と回答した患者を特定し、特定した前記患者のリストを、前記閲覧端末へ出力する、請求項１〜３のいずれか一項に記載の医療情報システム。
- 前記問診結果情報の前記回答内容には、痛みの治療を受けているか否かを問う第２問診項目に対する回答内容が含まれており、
前記医療情報サーバは、前記閲覧端末から、除痛率の出力要求があると、前記問診結果データベースに記憶された前記問診結果情報に含まれる、前記第１問診項目及び前記第２問診項目に対する回答内容に基づいて、前記除痛率を算出し、算出した前記除痛率を、前記閲覧端末へ出力するように構成されており、
痛みでできないことや困っていることがあり、かつ、痛みの治療を受けている患者の数をＮ１とし、痛みでできないことや困っていることが無く、かつ、痛みの治療を受けている患者の数をＮ２とし、痛みでできないことや困っていることがあり、かつ、痛みの治療を受けていない患者の数をＮ３としたとき、前記医療情報サーバは、前記除痛率を、以下の式（１）：
除痛率 ＝ ｛Ｎ２／（Ｎ１+Ｎ２+Ｎ３）｝×１００ （％） ・・・（１）
により求める、請求項１〜４のいずれか一項に記載の医療情報システム。 - 前記医療情報サーバは、
ＤＰＣのＥＦファイルを記憶する、ＥＦファイルデータベースと、
ＤＰＣのＥＦファイルのレセプト電算処理システム用コードのうちの医薬品コードと換算係数との対応関係を少なくとも規定する対応関係情報を記憶する、対応関係記憶部と、
をさらに備え、
前記医療情報サーバは、前記閲覧端末から、処方量集計の要求があると、前記集計にあたって、前記対応関係情報から、前記処方量集計の要求により指定される条件に合う薬の医薬品コードに対応する換算係数を読み込むとともに、前記ＥＦファイルデータベースに記憶されたＥＦファイルから、前記条件に合う薬の医薬品コードに対応する診療記録を抽出して、前記抽出した診療記録における使用量及び行為回数を読み込んで、前記換算係数、前記使用量、及び前記行為回数どうしの乗算により、該診療記録分の処方量を求め、求めた前記診療記録分の処方量に基づき得られる集計結果を、前記閲覧端末へ出力する、請求項１〜５のいずれか一項に記載の医療情報システム。 - 前記医療情報サーバは、患者が所定の疾患を有するか否かを特定する疾患有無情報と前記患者の患者ＩＤとを少なくとも含む、患者基本情報を複数記憶する、患者基本情報データベースをさらに備え、
前記ＥＦファイルデータベースに記憶されるＥＦファイルのデータ識別番号は、患者ＩＤと関連付けられており、
前記医療情報サーバは、前記処方量集計の要求により指定される条件が前記疾患の有無を含む場合、前記集計にあたって、前記患者基本情報の前記疾患有無情報に基づき、前記条件に合う患者の患者ＩＤを抽出し、抽出した前記患者ＩＤに関連付けられたデータ識別番号に対応する前記診療記録を用いて、前記集計結果を得る、請求項６に記載の医療情報システム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015070346 | 2015-03-30 | ||
| JP2015070346 | 2015-03-30 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2016192207A true JP2016192207A (ja) | 2016-11-10 |
Family
ID=57246983
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016068568A Pending JP2016192207A (ja) | 2015-03-30 | 2016-03-30 | 医療情報システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2016192207A (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109935345A (zh) * | 2019-03-12 | 2019-06-25 | 深圳安泰创新科技股份有限公司 | 诊疗随访方法、装置、设备及存储介质 |
| JP2019197281A (ja) * | 2018-05-07 | 2019-11-14 | 株式会社エム・エイチ・アイ | 情報提供システム、情報提供方法およびプログラム |
| JPWO2019069680A1 (ja) * | 2017-10-05 | 2020-09-24 | 富士フイルム富山化学株式会社 | 薬局管理システム、薬局管理方法、及び薬局管理プログラム |
| JP2021022188A (ja) * | 2019-07-29 | 2021-02-18 | 日本電気株式会社 | 受付システム、携帯端末、受付装置、制御方法、及びプログラム |
| CN112908468A (zh) * | 2021-01-23 | 2021-06-04 | 方翔 | 一种基于5g网络的智慧医疗管理系统 |
| JP7450310B1 (ja) | 2023-11-07 | 2024-03-15 | ｉＡｎａｌｙｓｉｓ合同会社 | 問診支援システム |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005122380A (ja) * | 2003-10-15 | 2005-05-12 | Fujitsu Ltd | 患者紹介処理方法，地域医療連携サーバ，地域医療連携プログラム及び記録媒体 |
| JP2006096026A (ja) * | 2004-07-08 | 2006-04-13 | Astrazeneca Ab | 診断システムおよび方法 |
| JP2010191891A (ja) * | 2009-02-20 | 2010-09-02 | Global Health Consulting Kk | 医療行為評価システム及び方法 |
| JP2011115390A (ja) * | 2009-12-03 | 2011-06-16 | Higashi Nihon Medicom Kk | 自動問診装置 |
-
2016
- 2016-03-30 JP JP2016068568A patent/JP2016192207A/ja active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005122380A (ja) * | 2003-10-15 | 2005-05-12 | Fujitsu Ltd | 患者紹介処理方法，地域医療連携サーバ，地域医療連携プログラム及び記録媒体 |
| JP2006096026A (ja) * | 2004-07-08 | 2006-04-13 | Astrazeneca Ab | 診断システムおよび方法 |
| JP2010191891A (ja) * | 2009-02-20 | 2010-09-02 | Global Health Consulting Kk | 医療行為評価システム及び方法 |
| JP2011115390A (ja) * | 2009-12-03 | 2011-06-16 | Higashi Nihon Medicom Kk | 自動問診装置 |
Non-Patent Citations (3)
| Title |
|---|
| 樋口 比登実 外１名: "ＷＨＯ方式３ｒｄ ｓｔｅｐのあらたな潮流（１）−３種強オピオイド注射剤とレスキュー剤が使用可能に", 医学のあゆみ, vol. 248, no. 6, JPN6017007858, 8 February 2014 (2014-02-08), JP, pages 445 - 452, ISSN: 0003512469 * |
| 的場 元弘: "オピオイド鎮痛薬と痛みの継続アセスメント −痛みのモニタリングの重要性−", がん患者と対症療法, vol. 25, no. 1, JPN6017007855, 31 October 2014 (2014-10-31), JP, pages 15 - 23, ISSN: 0003512467 * |
| 藤森 研司 外１名: "ＤＰＣデータによる放射線診療の分析可能性", 月刊新医療 ２月号, vol. 第３５巻 第２号, JPN6017007856, 1 February 2008 (2008-02-01), JP, pages 58 - 62, ISSN: 0003512468 * |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPWO2019069680A1 (ja) * | 2017-10-05 | 2020-09-24 | 富士フイルム富山化学株式会社 | 薬局管理システム、薬局管理方法、及び薬局管理プログラム |
| JP7048627B2 (ja) | 2017-10-05 | 2022-04-05 | 富士フイルム富山化学株式会社 | 薬局管理システム、薬局管理方法、及び薬局管理プログラム |
| JP2019197281A (ja) * | 2018-05-07 | 2019-11-14 | 株式会社エム・エイチ・アイ | 情報提供システム、情報提供方法およびプログラム |
| JP7099865B2 (ja) | 2018-05-07 | 2022-07-12 | 株式会社エム・エイチ・アイ | 情報提供システム、情報提供方法およびプログラム |
| CN109935345A (zh) * | 2019-03-12 | 2019-06-25 | 深圳安泰创新科技股份有限公司 | 诊疗随访方法、装置、设备及存储介质 |
| JP2021022188A (ja) * | 2019-07-29 | 2021-02-18 | 日本電気株式会社 | 受付システム、携帯端末、受付装置、制御方法、及びプログラム |
| JP7467839B2 (ja) | 2019-07-29 | 2024-04-16 | 日本電気株式会社 | 受付システム、受付装置、制御方法、及びプログラム |
| CN112908468A (zh) * | 2021-01-23 | 2021-06-04 | 方翔 | 一种基于5g网络的智慧医疗管理系统 |
| CN112908468B (zh) * | 2021-01-23 | 2024-01-12 | 上海熙软科技有限公司 | 一种基于5g网络的智慧医疗管理系统 |
| JP7450310B1 (ja) | 2023-11-07 | 2024-03-15 | ｉＡｎａｌｙｓｉｓ合同会社 | 問診支援システム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20230377077A1 (en) | Information system for physicians | |
| JP2016192207A (ja) | 医療情報システム | |
| US9501624B2 (en) | Pharmacy management and administration with bedside real-time medical event data collection | |
| CA2545127C (en) | Electronic medical information system, electronic medical information programs, and computer-readable recording media for storing the electronic medical information programs | |
| KR101249528B1 (ko) | 한의학 처방 및 조제 지원 시스템 | |
| JP2018512085A (ja) | データの所有者によって、選択された受信者のための許可を制御するシステムおよび方法 | |
| US20130311205A1 (en) | System and method for increasing patient adherence to medication treatment regimens | |
| US20130317840A1 (en) | System and method for increasing patient adherence to medication treatment regimens | |
| US20140379375A1 (en) | Method and device for maintaining and providing access to electronic clinical records | |
| US20130317839A1 (en) | System and method for increasing patient adherence to medication treatment regimens | |
| Saurman et al. | Use of a mental health emergency care-rural access programme in emergency departments | |
| JP6619113B1 (ja) | 服薬情報提供装置、服薬情報提供方法、およびコンピュータプログラム | |
| JP2002063274A (ja) | 提携病院・提携診療所等共同利用型医療機関連携支援情報システム | |
| KR100538580B1 (ko) | 온라인 상에서의 병원 업무 처리 방법 | |
| JP6661045B1 (ja) | 医療関係者マッチングシステム | |
| Arakawa et al. | Construction and usability of community health nursing database in rural north‐eastern Thailand | |
| JP6585458B2 (ja) | 診療支援システム | |
| US11544809B2 (en) | Information system for physicians | |
| WO2006126556A1 (ja) | 薬歴情報管理装置 | |
| JP2019179443A (ja) | コンピュータプログラム、端末及び方法 | |
| Ng et al. | Innovative partnership between a rural mental health center and community pharmacy: integration of a mental health pharmacist | |
| WO2015013694A2 (en) | System and method for increasing patient adherence to medication treatment regimens | |
| CA3115437C (en) | System and method for increasing patient adherence to medication treatment regimens | |
| KR20230117932A (ko) | 전자의무 기록장치와 연계된 모바일 문진 시스템 및 그 방법 | |
| JP2005025366A (ja) | 統一介護記録システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170224 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20170307 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20170905 |