(54)【発明の名称】医療支援及び/又は介護支援のためのシステム、医療支援及び/又は介護支援のためのサーバ、医療支援及び/又は介護支援のための方法及び医療支援及び/又は介護支援のためのプログラム
(58)【調査した分野】(Int.Cl.,DB名)
医療者及び/又は介護者が利用者に給付するためのケア項目と、前記ケア項目の対価の情報と、前記ケア項目の給付に対して前記対価の発生が認められるための算定条件と、が紐づけられる算定基準を記憶する算定基準記憶部と、
利用者に紐づけられる利用者情報を取得する利用者情報取得部と、
前記取得された利用者の利用者情報が、前記算定基準に適合するか否かを判断し、適合すると判断する場合に前記算定基準に紐づけられる前記ケア項目に応じたオーダー候補情報を生成するオーダー生成部と、
前記利用者情報に、前記オーダー候補情報を生成するために必要な情報が充足しているかどうかを判別する利用者情報判別部と、
前記利用者情報判別部が、前記必要な情報が充足していないと判別した場合に、前記必要な情報のうち不足している情報を提案するための追加取得情報の提案情報を生成する追加取得情報提案部と、
前記追加取得情報の提案情報を表示する表示部と、
を備える医療支援及び/又は介護支援のためのシステム。
前記利用者情報は、入院申込時のオーダー情報、入院診療計画書に係る情報、DPC情報、患者背景に係る情報、医師・コメディカルによるアセスメント情報、検体検査結果に係る情報、生理検査結果に係る情報、病理検査結果に係る情報、画像データに係る情報、バイタルサインに係る情報、医療行為に係る情報、病名に係る情報、術式に係る情報、麻酔に係る情報、投薬・注射情報、退院・転院先に係る情報、退院・転院予定日に係る情報、過去に算定したことのある診療報酬項目に係る情報、重症度に係る情報、ケアを受けた施設名の履歴情報、他施設において受けたケアの履歴情報、他施設との地域連携パス情報、PHR情報のうち少なくとも1つの情報を含む請求項1に記載の医療支援及び/又は介護支援のためのシステム。
前記オーダー候補情報は、前記利用者に施すべき候補となる医療行為の情報、医療行為の実施計画、前記利用者に施すべき候補となる介護行為の情報、介護行為の実施計画、アセスメント結果の情報を含んだオーダーに係る提案、又はアセスメント結果の情報を含んだオーダーに係る提案に付随する情報を少なくとも1つ含む情報である請求項1から4のいずれか一項に記載の医療支援及び/又は介護支援のためのシステム。
前記オーダー生成部は、前記利用者情報に含まれる検査結果情報と、前記算定基準に含まれる栄養食事指導及び/又は特別食加算に関する算定条件に応じて、前記栄養食事指導及び/又は特別食加算に関するオーダー候補情報を生成する請求項1から5のいずれか一項に記載の医療支援及び/又は介護支援のためのシステム。
医療者及び/又は介護者が利用者に給付するためのケア項目と、前記ケア項目の対価の情報と、前記ケア項目の給付に対して前記対価の発生が認められるための算定条件と、が紐づけられる算定基準を記憶する算定基準記憶部と、
利用者に紐づけられる利用者情報を取得する利用者情報取得部と、
前記取得された利用者の利用者情報が、前記算定基準に適合するか否かを判断し、適合すると判断する場合に前記算定基準に紐づけられる前記ケア項目に応じたオーダー候補情報を生成するオーダー生成部と、
前記利用者情報に、前記オーダー候補情報を生成するために必要な情報が充足しているかどうかを判別する利用者情報判別部と、
前記利用者情報判別部が、前記必要な情報が充足していないと判別した場合に、前記必要な情報のうち不足している情報を提案するための追加取得情報の提案情報を生成する追加取得情報提案部と、
を備える医療支援及び/又は介護支援のためのサーバ。
医療者及び/又は介護者が利用者に給付するためのケア項目と、前記ケア項目の対価の情報と、前記ケア項目の給付に対して前記対価の発生が認められるための算定条件と、が紐づけられる算定基準を用いる医療支援及び/又は介護支援のための方法であって、
利用者情報取得部が、利用者に紐づけられる利用者情報を取得するステップと、
利用者情報判別部が、前記利用者情報に、オーダー候補情報を生成するために必要な情報が充足しているかどうかを判別するステップと、
追加取得情報提案部が、前記必要な情報が充足していないと判別した場合に、前記必要な情報のうち不足している情報を提案するための追加取得情報の提案情報を生成するステップと、
オーダー生成部が、前記取得された利用者の利用者情報が、前記算定基準に適合するか否かを判断し、適合すると判断する場合に前記算定基準に紐づけられる前記ケア項目に応じたオーダー候補情報を生成するステップと、
を備える医療支援及び/又は介護支援のための方法。
医療者及び/又は介護者が利用者に給付するためのケア項目と、前記ケア項目の対価の情報と、前記ケア項目の給付に対して前記対価の発生が認められるための算定条件と、が紐づけられる算定基準を用いる医療支援及び/又は介護支援のためのプログラムであって、
利用者に紐づけられる利用者情報を取得するステップと、
前記利用者情報に、オーダー候補情報を生成するために必要な情報が充足しているかどうかを判別するステップと、
前記必要な情報が充足していないと判別した場合に、前記必要な情報のうち不足している情報を提案するための追加取得情報の提案情報を生成するステップと、
前記取得された利用者の利用者情報が、前記算定基準に適合するか否かを判断し、適合すると判断する場合に前記算定基準に紐づけられる前記ケア項目に応じたオーダー候補情報を生成するステップと、
をコンピュータに実行させるための医療支援及び/又は介護支援のためのプログラム。
【発明を実施するための形態】
【0021】
<全体構成>
本発明の実施形態に係る医療支援及び/又は介護支援のためのシステム(以下医療・介護支援システムとする)1は、病院や診療所等の医療機関や介護事業者が運営する介護施設(以下、「医療機関等」という。)で使用されることを想定したシステムである。
図1は、本発明の実施形態に係る医療支援及び/又は介護支援のためのサーバ(以下医療・介護支援サーバとする)201を含む医療・介護支援システム1を示すシステム構成図である。
図1で示すように、本発明の実施形態に係る医療・介護支援システム1は、病院等の窓口で主に使用される受付端末111と、入退院支援部門(Patient Flow Management、患者支援センター、メディカルサポートなど様々な呼称がある)で主に使用される入退院支援部門端末121と、リハビリテーション部門、検査部門、栄養部門等の現場で主に使用される現場端末131と、医師や歯科医師等の指示者が使用する指示者端末141と、医事部門端末151と、医療・介護支援サーバ201と、基幹システム301とが、ネットワークNWを介して通信可能に接続されている。
【0022】
また、図では省略するが、リハビリテーション部門システム、検体検査システム、生理検査システム、栄養部門システム、DPC(Diagnosis Procedure Combination)コーディングシステム等の部門システムも接続されている。説明の簡略化のため、
図1では、各端末は1台として記載しているが、同種の複数の端末が接続されていても構わない。また、ネットワークNWは、医療施設内のLANや、インターネットなどの回線を用いても構わない。また、各端末やサーバとネットワークNWの接続は有線であっても無線であっても構わない。
【0023】
医療・介護支援サーバ201は、例えば、サーバ装置(サーバ用コンピュータ)等である。更に、医療・介護支援サーバ201は医療機関等の内部に設置されている必要はなく、物理的に医療機関等と独立した場所に設置されてもよいし、クラウドサービスや、ブロックチェーンのような分散型ネットワークでデータが管理されるサービスや、AWS(Amazon Web Services)のようなデータウェアハウスシステムを用いても構わない。
【0024】
医療・介護支援システム1は、医療機関等において、入院した患者や被介護者に対して、算定基準に従ってオーダーを生成することで患者等の利用者の状態に応じた適切な、医療行為等といったケアを受けられるようにするサービスを行うためのシステムである。オーダーとは、医療現場や介護現場におけるケアの行為等の指示を示すものであり、例えば検査オーダー、栄養食事指導オーダー、リハビリオーダー、処方オーダー等がある。オーダーは、オーダー情報として、現場等に伝達される。なお、本発明において、医療行為とは、医師や医療スタッフが患者に対して直接行う行為のみならず、医療物品の提供や、各種モニタリングや入院させること自体も含むものである。
【0025】
受付端末111は、病院等の窓口で主に使用される端末装置であり、患者等や被介護者の利用者の情報を入力し、また、利用者に対して請求書の発行を行うものである。
【0026】
入退院支援部門端末121は、入退院支援部門で主に使用される端末装置である。入退院支援部門は、医師により入院が必要と判断された患者や被介護者等に対して、入院患者や入院被介護者等の情報を入院前に把握するための組織である。また、入院予定患者や入院予定被介護者やその家族等に面談を行い、患者の収入、家族構成、退院先等の社会的アセスメント情報の収集を行う。また、入退院支援部門では、入院日や病棟の決定を行うこともある。収集された情報や、決定された入院日や病棟の情報は利用者情報として入退院支援部門端末121から入力され電子カルテ等のシステムに記録される。
【0027】
現場端末131は、リハビリテーション部門、検査部門システム、栄養部門等の医療行為や介護行為や、それらの指揮を行う現場で主に使用される端末装置である。現場端末131は、現場表示部132と、現場入力部133を含んで構成される。現場表示部132は、後述するオーダー候補情報や、オーダー情報の表示を行う。また、現場入力部133は、現場において、オーダー情報に基づくオーダーが実施(ケア項目が給付)され、完了した際にオーダー実施の完了を示す実施完了情報を入力する。さらに、現場入力部133は、オーダー情報に基づくオーダーを実施(ケア項目を給付)することが確定した際に実施完了情報を入力しても構わない。
【0028】
指示者端末141は、主に医師等が使用する端末装置である。医師は、診察や検査によって、病名(傷病)を決定する。病名には主病名・副病名(主傷病・副傷病)が含まれる。指示者端末141は、指示者表示部(表示部)142と、指示者入力部(入力部)143を含んで構成される。指示者表示部142は、後述するオーダー候補情報や、オーダー情報、追加取得情報の提案情報の表示を行う。また、指示者入力部143は、決定した病名等の入力や、検査結果情報等の入力や、オーダー候補情報や、オーダー情報に対する承認情報の入力を行う。
【0029】
医事部門端末151は、現場入力部133から送信されたオーダー実施の完了を示す実施完了情報を受信し、医事担当が当該オーダーに関する診療報酬明細(レセプト)を生成する。診療報酬明細は、算定基準の対価情報に応じて算定された診療報酬の明細書である。診療報酬は、医療・介護支援サーバ201の対価算定部216が算定基準記憶部221に記憶される算定基準と実施完了情報に紐づくオーダー情報を用いて算定される。医療・介護支援サーバ201は、算定された診療報酬を医事部門端末151へ送信する。
【0030】
医療・介護支援サーバ201は、利用者情報取得部211と、利用者情報判別部212、追加取得情報提案部213、追加取得情報取得部214、オーダー生成部215と、対価算定部216と、算定基準記憶部221とを含んで構成される。
【0031】
利用者情報取得部211は、利用者情報と算定基準を用いて電子カルテ等からケア項目である算定項目の対象となる利用者を抽出し、当該利用者の情報を取得する。
【0032】
利用者情報判別部212は、利用者情報取得部211が抽出した利用者の利用者情報の中に、算定項目に対応するオーダー候補情報を生成するために必要な情報が充足しているかどうかを判別する。具体的には、利用者情報取得部211が抽出した利用者に対する算定項目を判定する算定アルゴリズム(以下オーダー候補生成アルゴリズム)で使用される病名や検査値等の情報が、当該利用者の利用者情報に含まれているか否かを判別する。例えば、算定項目となるためには4つの条件が必要である場合に、3つの条件が充足し、あと1つの条件が充足していない場合に、非充足と判別する。2つ以上の条件が充足していない場合には、もとより算定項目の候補とはしない。より具体的には、例えば、利用者情報取得部211が抽出した利用者に対する算定項目が「特別食加算(貧血食)」である場合に、当該算定項目を判定するオーダー候補生成アルゴリズムで使用される「鉄欠乏性貧血」の病名等の条件の情報が1つだけ充足していないか否かを判別する。このように、算定項目となるための条件のうち、所定数の条件が充足していない場合に、追加取得情報提案を行うべきとして非充足と判別する。このように、充足しない情報の数又は、必要とされる算定条件の総数に対して充足しない情報の割合に、所定の閾値を設けることで、追加取得情報の提案情報を必要以上に多く生成することを抑制することができる。
【0033】
追加取得情報提案部213は、利用者情報判別部212が必要な情報が充足していないと判別した場合に、必要な情報のうち不足している情報を提案するための追加取得情報の提案情報を生成する。具体的には、利用者情報判別部212が、抽出した利用者に対する算定項目を判定するオーダー候補生成アルゴリズムで使用される病名や検査値等の情報を取得するための追加取得情報の提案情報を生成する。より具体的には例えば、利用者情報取得部211が抽出した利用者情報から、算定項目となりうる候補が「特別食加算(貧血食)」である場合について説明する。利用者情報の検査結果等から、利用者情報判別部212が当該利用者に対して「特別食加算(貧血食)」が算定項目の候補となり得ることを判別している。しかし、当該算定項目を確定させるために「鉄欠乏性貧血」の病名の情報が充足していない場合に、指示者である医師によるHb(ヘモグロビン)値の判断に基づく「鉄欠乏性貧血」の追加病名診断を提案する提案情報を生成するものである。なお必要に応じて追加検査の提案情報を生成しても構わない。
【0034】
追加取得情報取得部214は、追加取得情報の提案情報に応じた追加診断や追加検査をされた結果を利用者情報として取得する。追加取得情報取得部214が当該情報を取得したと判別したことにより、オーダー生成部215は、オーダーの生成を行うことができる。
【0035】
オーダー生成部215は、抽出した利用者の利用者情報と算定基準から、算定対象となるケア項目の候補を抽出し、当該ケア項目を実施するためのオーダー候補情報を生成する。オーダー候補情報は、各利用者に対して1つでも複数が生成されても構わない。またオーダー生成部215は、当該オーダー候補情報を生成するための根拠となった根拠情報をオーダー候補情報に対応して生成する。根拠情報は、利用者情報に応じた情報であり、例えば、患者の検査結果の値の情報である。更に、オーダー生成部215は、オーダー候補情報に応じた重要度情報を生成することができる。重要度情報は、複数のオーダー候補情報の中で優先して行うべきオーダー(ケア項目)について、他のオーダー候補情報に比して重要度を高く設定されるものである。オーダー候補情報の重要度は、例えば、オーダー候補情報生成のアルゴリズムによって、各医療学会が定める診療ガイドライン等で重症と判断されるようなオーダー候補については当該オーダーの提案が適するであろうと判断し、重要度を高く設定するように付与してもよい。更に、オーダー候補情報は、現場表示部132において表示するための1次オーダー候補情報として生成しても構わない。なお、2次オーダー候補情報は、1次オーダー候補情報に基づいて指示者表示部142に送信するためのオーダー候補情報を示す。
【0036】
対価算定部216は、算定基準記憶部221に記憶される算定基準と、実施完了情報に紐づくオーダー情報を用いて、当該オーダー情報の実施(ケア項目の給付)に対する対価である診療報酬等を算定する。
【0037】
算定基準記憶部221は、日本においては厚生労働省等が告示する診療報酬点数等に基づき、医療者や介護者が、患者等の利用者に施す(現物給付する)医療行為や介護行為であるケア項目と、当該ケア項目に対して例えば診療報酬や介護報酬のように対価情報を紐づけて記憶している。また、算定基準記憶部221は、当該医療行為や介護行為を給付した際に診療報酬や介護報酬等の対価の発生が認められるための条件と各医療行為や介護行為紐づけられ、算定条件として記憶している。また、算定基準記憶部221は、各ケア項目に応じたオーダー候補算定アルゴリズムをライブラリ等の形で記憶することができる。
【0038】
なお、算定基準記憶部221は、医療・介護支援サーバ201と物理的に独立した装置として備えられても構わない。また、算定基準記憶部221は、入退院支援部門端末121、現場端末131、指示者端末141及び医事部門端末151等からもアクセス可能であり、医師や看護師、栄養士、理学療法士、医事担当などが算定基準記憶部221に記憶されている算定基準やオーダー候補生成アルゴリズムのメンテナンスを行うことができる。
【0039】
基幹システム301は、医療機関等で使用される情報を一元的に管理するシステムである。基幹システム301は、電子カルテを管理する電子カルテシステム302、オーダリングシステム303、医事会計システム304、看護支援システム305を含んで構成される。電子カルテシステム302は、利用者情報を利用者(患者、被介護者等)ごとに電子カルテを管理するシステムである。また、オーダリングシステム303は、指示者端末141で承認を受けたオーダー候補情報を各現場端末にオーダー情報として送信するように管理するシステムである。また、医事会計システム304は、診療報酬等の医事会計情報の管理を行うシステムである。さらに、看護支援システム305は、看護支援のための情報を管理するシステムである。
【0040】
また図示はしないが、医療・介護支援システム1はオーダー設定部を備えていても構わない。オーダー設定部は、現場担当者が現場入力部133から入力を行うことで、オーダー候補情報(1次オーダー候補情報)から、特定のオーダーの抽出や、オーダーの実施予定日の変更を行なった2次オーダー候補情報を設定する。オーダー設定部は、医療・介護支援サーバ201に備えられてもよく、現場端末131に備えられていても構わない。
【0041】
なお、本発明における利用者情報は、以下の情報を含むものである。なお、以下に挙げる全ての情報が必要なわけではない。
(1)入院申込オーダー情報:病名、入院目的、推定入院期間、入院希望日、病棟、食事開始日、食事内容等
(2)入院診療計画書の情報:病名、症状、治療計画、検査内容と日程、手術内容と日程、推定入院期間等
(3)DPC情報:DPCコード、主病名、医療資源を最も投入した病名、入院時意識障害、入院経路、推定入院期間等
(4)患者背景に係る情報/問診情報:性別、妊娠有無、妊娠週数、年齢、入院前後における在宅医療の有無、介護情報、公費情報、栄養補給方法(経口、経腸、経静脈)、予定・緊急入院区分、既往歴、前回退院日、過去に算定したことのある診療報酬項目、ケアを受けた施設名(医療機関名等)の履歴情報、他施設(他医療機関等)における在宅ケアの履歴情報、他施設(他医療機関等)との地域連携パス情報、PHR情報、アレルギー情報、持参薬等
(5)医師・看護師などの医療職によるアセスメント情報(心身アセスメント情報):意識障害レベル、認知症高齢者の日常生活自立度判定基準、ADL(Activity of Daily Living)区分、重症度、医療・看護必要度、STAS−J、退院・転院先、退院・転院日予定日等
(6)検体検査結果に係る情報:血小板、HbA1C、早朝空腹時血糖、75gOGTT、LDL、HDL、TG、血中アルブミン値、血中ヘモグロビン濃度、血清ビリルビン値、プロトロンビン活性値、HBs抗体、HCV抗体、梅毒血性反応、IgE、IgM、CRP、蛋白尿、血尿、血清クレアチニン値、Child−Pugh分類、遺伝子検査情報等
(7)バイタルサインに係る情報:身長、体重、BMI、脈拍、血圧、体温等
(8)生理検査結果に係る情報:聴力、肺活量、1秒率、心不全NYHA分類、狭心症CCS分類、経皮的動脈圧酸素飽和度、動脈血酸素分圧、吸入器酸素分画比等
(9)画像データに係る情報:X線単純撮影画像、CT画像、MRI画像、核医学検査画像、マンモグラフィ画像、X線TV画像、デジタル病理画像、内視鏡画像、腹部エコー画像、心エコー画像、経食道エコー画像等
(10)医療行為に係る情報:入院中の処方オーダー情報、点滴オーダー情報、麻酔時間、麻酔種別、手術の術式・体位、透析、人工呼吸、人工肛門、IVH、腸ろう、腸管栄養、喀痰吸引、定期導尿、植込型ペースメーカー、植込型除細動器、処置行為、投薬・注射、放射線治療、リハビリテーション、在宅酸素情報等
(11)その他の情報:病棟、転院申込情報、算定上限回数情報等
【0042】
なお、PHR(Personal Health Record)情報とは、利用者である個人の健康状態や服薬履歴等の医療情報を医療機関等のみならず、当該利用者に紐づけて管理し、利用者本人や家族が随時確認でき、日常生活改善や健康増進、予防、診断、治療につなげることができる情報である。すなわち、医療機関等を超えて、利用者の医療情報を広く共有可能な情報である。
【0043】
<追加取得情報提案表示画面>
本発明の実施形態に係る追加取得情報提案が表示される端末の画面イメージについて、
図2を参照しながら説明する。
【0044】
図2は、指示者端末141の指示者表示部142において、追加取得情報の提案情報(追加取得情報提案)が表示される画像イメージである。当該画面には、利用者である患者に割り当てられている患者ID、患者が入院している病棟、患者の入院日、退院予定日、実施推奨日、追加取得情報項目、追加算定しうる項目(オーダー候補情報)、追加算定項目の算定要件、患者情報(利用者情報)が表示される。更に、右端には各行に対して「要実施」のボタンが表示されており、医師等の指示者が、追加取得情報項目の追加病名診断や追加検査を実施すべきことを判断した場合に当該ボタンを押す。
【0045】
図2においては、例えば、患者IDが003の患者が、東10階の病棟に入院しており、入院日は11月6日、退院予定日は11月14日であることが示されている。そして当該患者に対して、追加取得情報項目として、「鉄欠乏性貧血」の追加病名診断が必要であるという提案がされている。また、この追加取得情報項目の提案がされたのは、当該患者に対して追加算定しうる項目として「特別食加算(貧血食)」が候補として挙がったためであることが表示されている。そして、追加算定項目の算定要件として、「Hb(ヘモグロビン)値が10未満」であることが表示されている。
【0046】
このように、指示者である医師等は、
図2の表示を見ることで、患者毎に追加取得情報項目の追加病名診断や追加検査の必要性を判断することができる。
【0047】
<オーダー候補表示画面>
次に、本発明の実施形態に係るオーダーの候補が表示される端末の画面イメージについて、
図3を参照しながら説明する。
【0048】
図3は、現場端末131の現場表示部132又は指示者端末141の指示者表示部142において、オーダーの候補が表示される画像イメージである。当該画面には、利用者である患者に割り当てられている患者ID、患者が入院している病棟、患者の入院日、退院予定日、行為実施の推奨日(実施予定日)、オーダーの提案項目(オーダー候補情報)、オーダーを提案する根拠となる情報である根拠情報、補足情報が表示される。更に、右端には各行に対して「要実施」のボタンが表示されており、コメディカルや医師等の指示者が、提案されたオーダーを実施すべきことを判断した場合に当該ボタンを押す。なお、本発明においてコメディカルとは、医師以外の医療職(看護師、臨床検査技師、診療放射線技師、理学療法士、栄養士等)を示す。
【0049】
図3においては、例えば、患者IDが001の患者が、東15階の病棟に入院しており、入院日は11月2日、退院予定日は11月15日であることが示されている。そして当該患者に対して、11月2日に行う候補となるオーダー項目として、糖尿病に対する特別食、脂質異常症に対する特別食、集団での栄養食事指導が表示されている。更に、それらのオーダー候補が提案された根拠となる情報が表示されている。
【0050】
根拠情報は、当該患者の検査値としてHbA1c値が8.0%以上であるため、糖尿病診療ガイドラインに従い、糖尿病に対する特別食を提案しているということを示す情報である。同様に、当該患者の検査値としてLDL値が190mg/dL以上であることを根拠として、脂質異常症に対する特別食を提案しているということや、上記特別食の対象となっていることを根拠として、集団での栄養食事指導を行う提案が示されている。なお、オーダー候補情報や、根拠情報は、着色されて表示されても構わない。オーダー提案の重要度(優先度)を、色による重要度情報として表示することができる。それにより、例えば赤字である場合には重要度が高く、青字のものは重要度が低いという具合に、表示を見たものが一目でオーダー提案の重要度を認識できる。また、別途重要度の項目を設け、例えば重要度の順に番号を付しても良いし、パーセント表示のような相対値を付しても良い。また「重要度高」「重要度低」のように文字情報として表示をしても構わない。
【0051】
次に、本発明の実施形態に係る所定期間内におけるオーダーの候補が表示される端末の画面イメージについて、
図4を参照しながら説明する。
【0052】
図4は、栄養食事指導を行う現場端末131の現場表示部132において、所定の期間である11月3日から11月9日の期間内における栄養食事指導のオーダーの候補が表示される表示画面である。当該画面には、利用者である患者に割り当てられている患者ID、患者氏名、生年月日、主治医、患者が入院している病棟のような患者固有の情報と、入力されたオーダー提案候補と、検査値・根拠情報が一覧で表示される。オーダー提案候補の欄では、例えば、表示画面のデータの2段目は、患者IDが092の患者が11月3日に入院したことを示す黒字のひし形マークと、オーダー候補が既に入力されていることを示す白抜き丸マークが表示されている。また、検査値・根拠情報として、血液検査、入退院支援部門評価の情報があることが黒丸マークで示されている。また、血液検査は、詳細情報が表示されており、アルブミン等の、血液検査の詳細な項目が表示されている。また、表示画面の下部には、各日付におけるオーダー候補となっている患者の数が候補者数として表示されている。また、その下段には、各日付における予定入院指導枠(オーダーの実施可能枠)が表示される。つまり、11月6日は、予定入院指導枠は11人であるところに12人のオーダー候補者がいることを示しており、現場担当者である栄養士等(コメディカル)は、オーダー候補者の調整を行う必要があることを認識することができる。現場担当者は、現場端末131において、
図4で示される表示画面を見ながら、オーダー候補情報(1次オーダー候補情報)の絞り込みや、オーダー実施予定日を変更した2次オーダー候補情報を設定することができる。
【0053】
<処理の流れ>
次に、本発明の実施形態に係る医療・介護支援システム1の動作について、
図5、
図6に示すフローチャートを参照しながら説明する。
図5のフローチャートは、受付端末111と、入退院支援部門端末121と、医療・介護支援サーバ201と、現場端末131と、指示者端末141と、医事部門端末151の各動作の関連状態を示している。なお、当該フローチャート内の利用者情報は、電子カルテシステム302等を介して取り扱われる。またオーダー情報は、オーダリングシステム303を介して取り扱われても構わない。
【0054】
ステップS101において、医療機関の受付は、受付端末111から患者の基礎情報である患者基礎情報(利用者基礎情報)を入力し、指示者端末141や入退院支援部門端末121に送信される。患者基礎情報は、患者の氏名、患者ID、年齢情報(生年月日情報)、性別情報、保険加入状況や公費情報等である。
【0055】
ステップS102において、医師は、患者の診察、診療を行い、診療結果や病名、DPCコード等を指示者端末141から入力する。病名、診療情報やDPCコード等の情報は、受付端末111から送信された利用者基礎情報とともに利用者情報として電子カルテシステム302内の電子カルテ等に記録される。また、医師の診察、診療に基づいて検査を行った情報も電子カルテ等に利用者情報として記録される。更に、医師が診療の結果、入院が必要と判断された患者には、DPCコードが割り当てられることがある。DPCコードは、病名、在院日数、術式等の情報を含む数字14桁からなるコードである。
【0056】
ステップS103において、入退院支援部門は、受付端末111から送信された患者基礎情報に基づき、入院情報を利用者情報として生成する。具体的には、例えば、入退院支援部門が患者へのヒヤリングを行い、社会的アセスメントを通じて得られた利用者情報として入退院支援部門端末121から入力され、電子カルテ等に記録される。
【0057】
ステップS104において、利用者情報取得部211は、ステップS102やステップS103で送信された診療結果、病名、DPCコード等の情報及び患者の入院情報等の利用者情報から、算定対象となる患者の抽出を行う。具体的には、利用者情報取得部211は、電子カルテシステム302内に蓄積された電子カルテ等の情報と、算定基準に基づいて、医療行為等を行うべき患者の抽出を行う。
【0058】
ステップS105において、利用者情報判別部212は、ステップS104で抽出された患者の利用者情報中に、算定項目の候補に対応するオーダー候補情報を生成するために必要な情報が充足しているかどうかを判別する。充足すると判別された場合(Y)には、ステップS108へ処理を進め、充足しないと判別された場合(N)には、ステップS106へ処理を進める。
【0059】
ステップS106において、追加取得情報提案部213は、ステップS105で判別された充足していない必要な情報について、不足している情報を提案するための追加取得情報の提案情報を生成する。追加取得情報提案部213は、追加取得情報の提案情報を指示者端末141へ送信する。
【0060】
ステップS107において、指示者端末141の指示者表示部142は、ステップS106で送信された追加取得情報の提案情報(追加取得情報提案)を表示する。具体的には、
図2で示すように、指示者表示部142は、利用者情報等を一覧として表示する。指示者である医師等は、指示者入力部143から、要実施の入力(承認)を行う。医師等による追加診断や、追加検査の結果は、利用者情報として電子カルテシステム302等を介して医療・介護支援サーバに送信される。
【0061】
ステップS108において、オーダー生成部215は、抽出された患者に対するオーダー候補情報の生成を行う。生成されたオーダー候補情報は、指示者端末141へ送信され、ステップS107へ処理を進める。また、オーダー生成部215は、オーダー候補情報の根拠となる情報を利用者情報から抽出し、生成する。
【0062】
なお、オーダー候補情報や、根拠情報は、
図4で示すように表示可能な情報として生成される。
【0063】
また、ステップS108において、オーダー候補情報は、現場端末131で表示するための1次オーダー候補情報として生成しても構わない。その場合、ステップS108’において、現場端末131は、医療・介護支援サーバ201から送信された1次オーダー情報から、指示者端末141へ送信するための2次オーダー候補情報を設定する。具体的には、現場端末131において、
図3で示すような複数のオーダー候補情報に対して、現場担当者が「要実施」を選択すると、
図4で示す所定期間内におけるオーダーの候補が表示される。そして、当該オーダーの実施可能枠とオーダー候補の患者数に応じて、現場担当者が実施予定の調整を行い、オーダーの絞り込みやオーダー実施予定日を変更した2次オーダー候補情報を設定する。設定された2次オーダー候補情報は、指示者端末141へ送信される。ステップS108''において、医師等は送信された2次オーダー候補情報について、元となった1次オーダー候補の確認を行うことができる。具体的には、指示者端末141から、医療・介護支援サーバ201に対して、生成されたオーダー候補(1次オーダー候補情報)の確認のリクエストを行う。それに応じて、指示者表示部142は、医療・介護支援サーバ201から送信される1次オーダー候補情報を表示することができる。ステップS108''によって、医師等が、コメディカル等の現場担当者の判断を検証することができる。なお、ステップS108で、オーダー候補情報が直接指示者端末141に送信される場合には、ステップS108'、ステップS108''はスキップしても構わない。
【0064】
ステップS109において、医師等は送信されたオーダー候補情報に対して承認を行い、オーダーの指示を現場に行う。具体的には、指示者表示部142に表示されたオーダー候補情報を医師等が確認し、指示者入力部143から医師が選択したオーダー候補情報に対する承認の入力を行うことで、オーダー候補情報がオーダー情報として、当該オーダーを実施すべき現場担当者が扱う現場端末131に送信される。オーダー情報は、オーダリングシステム303を介して現場端末131に送信されても構わない。
【0065】
ステップS110において、現場担当者は、現場表示部132に表示されるオーダー情報に従い、オーダーを実施する(ケア項目の給付を行う)。すなわち、オーダー情報に対応する、医療行為等を患者に対して実施(給付)する。
【0066】
ステップS111において、現場担当者は、オーダーの実施が完了した旨を示す実施入力を行う。具体的には、現場入力部133から実施入力が行われると、完了したオーダーのオーダー情報に紐づけられる実施完了情報が生成される。そして実施完了情報は、医事部門端末151へ送信される。
【0067】
ステップS112において、医事部門端末151は、現場入力部133から送信されたオーダー実施の完了を示す実施完了情報を受信し、医事担当が当該オーダーに関する診療報酬明細を生成する。また、医事部門端末151は、生成した診療報酬明細を受付端末111へ送信する。
【0068】
ステップS113において、受付端末111は、医事部門端末151から診療報酬明細を受信し、患者に対する請求書の発行を行う。
【0069】
以上の説明において、追加取得情報の提案情報およびオーダー候補情報は、医師等の使用する指示者端末141に送信され、指示者表示部142に表示されるものとしたが、それに限られるものではない。例えば、担当する医師の上長等の助言者の端末装置にオーダー候補情報を送信し、当該端末装置の表示部に表示されたオーダー候補情報に基づいて、助言者が医師等の指示者に口頭や書面で情報を提供しても構わない。また、追加取得情報の提案情報やオーダー候補情報に対する承認の入力は、必ずしも指示者入力部143から行う必要はなく、他の端末装置の入力部から行っても構わない。
【0070】
(オーダー候補生成アルゴリズムについて)
次に、オーダー候補を生成するアルゴリズムの一例として、特別食の提供ならびに特別食加算の算定可否を判断する場合について
図6のフローチャートを用いて説明する。算定可否は、利用者情報が算定基準の条件に適合するか否かにより判断される。
【0071】
ステップS201において、オーダー生成部215は、利用者情報の病名として、脂質異常症の病名がついているどうかを判別する。当該病名がついている場合(Y)にはステップS202へ処理を進める。当該病名がついていない場合(N)には、ステップS205へ進む。
【0072】
ステップS202において、オーダー生成部215は、利用者情報の検査値(検査結果)として、LDL(Low Density Lipoprotein cholesterol)値が140mg/dL以上であるか、140mg/dL未満であるかを判別する。判別の基準となるLDL値は、特別食として脂質異常症食の対象となる患者について算定基準により定められている。利用者情報の検査値のLDL値が140mg/dL以上である場合、ステップS206へ進む。LDL値が140mg/dL未満である場合、ステップS203へ処理を進める。
【0073】
ステップS203において、オーダー生成部215は、利用者情報の検査値として、HDL(High Density Lipoprotein cholesterol)値が40mg/dL以上であるか、40mg/dL未満であるかを判別する。判別の基準となるHDL値は、特別食として脂質異常症食の対象となる患者について算定基準により定められている。利用者情報の検査値のHDL値が40mg/dL未満である場合、ステップS206へ進む。HDL値が40mg/dL以上である場合、ステップS204へ処理を進める。
【0074】
ステップS204において、オーダー生成部215は、利用者情報の検査値として、TG(TriGlyceride/中性脂肪)値が150mg/dL以上であるか、150mg/dL未満であるかを判別する。判別の基準となるTG値は、特別食として脂質異常症食の対象となる患者について算定基準に定められている。利用者情報の検査値のTG値が150mg/dL以上である場合、ステップS206へ進む。TG値が150mg/dL未満である場合、ステップS205へ処理を進める。
【0075】
ステップS205において、オーダー生成部215は、脂質異常症に対する特別食の算定対象外であることを決定し、オーダー候補情報を生成せずに処理を終了する。
【0076】
ステップS206において、オーダー生成部215は、脂質異常症に対する特別食の算定対象であることを決定し、「脂質異常症に対する特別食」をオーダー候補としてオーダー候補情報を生成する。なお、オーダー生成部215は算定対象となる場合の根拠情報も生成する。例えば、ステップS202において利用者情報の検査値のLDL値が180mg/dLであるとして算定対象とされた場合には、その旨を根拠情報として生成する。
【0077】
以上、利用者情報から算定項目である「特別食加算」であり特に「脂質異常症に対する特別食加算」の算定対象であるか否かを判定し、「脂質異常症に対する特別食」のオーダー候補としてオーダー候補情報を生成するアルゴリズムについて説明したが、オーダー候補生成アルゴリズムは、算定項目毎に準備されるものであり、医療・介護支援システム1において適宜選択して使用することができる。
【0078】
<システムの運用について>
上記説明した、医療・介護支援システムは、入院患者の様々な状況に応じて運用することができる。具体的には、(1)入院前・入院時利用者情報に基づく医療行為についてのオーダー提案、(2)入院後、特に入院後に状態の変化等が生じた後に取得される利用者情報(予後管理情報)に基づく医療行為についてのオーダー提案、(3)退院時情報に基づく医療行為についてのオーダー提案において適用することができる。
【0079】
(1)入院前・入院時利用者情報に基づく医療行為に応じた診療報酬の算定項目は、特別食加算、退院時共同指導料、介護支援等連携指導料、総合評価加算、入退院支援加算、栄養食事指導料(入院・集団)、リハビリテーション計画提供料、認知症ケア加算、褥瘡ハイリスク患者ケア加算、がん患者指導管理料、呼吸器リハビリテーション料、肺血栓塞栓症予防管理料等がある。これらの算定項目に応じた医療行為は、入院前に収集した利用者情報に基づいて決められる。入院前に収集した利用者情報は、診察時の病名情報(副病名等も含む)や検査における検査結果の情報、入院申込み時における、社会的アセスメント結果情報や入院契機病名情報、ADLスコア情報、ADLアセスメント情報、リスクファクター情報、術式・麻酔情報、治療法情報、退院先情報等があり、それらが電子カルテの情報として記録されている。
【0080】
(呼吸器リハビリテーション料の例)
ここで、入院前・入院時利用者情報に基づく医療行為に応じた診療報酬の算定項目として、呼吸器リハビリテーション料を例に説明する。利用者情報取得部211は、呼吸器リハビリテーション料の算定対象となる患者として、電子カルテシステム302の電子カルテの情報から利用者情報を取得する。例えば、算定基準に記載の呼吸器リハビリテーション料の算定対象となる既往症が電子カルテに記載されている患者の利用者情報を取得する。診療報酬点数表には、呼吸器リハビリテーション料の算定対象となる患者(算定条件)、実施する(給付を行う)医療行為(ケア項目)、及び対価としての診療報酬の点数(対価)が定められており、算定基準記憶部221には、診療報酬点数表に基づいた算定基準が記憶されている。
【0081】
オーダー生成部215は、入院前・入院時の利用者情報である術式情報、病名情報、入院日情報、術日情報、病棟情報を、呼吸器リハビリテーション料の算定基準に基づいて取得する。そして、オーダー生成部215は、呼吸器リハビリテーション料に応じたオーダー候補生成アルゴリズムを用いて、呼吸器リハビリテーションの対象となる患者を抽出する。オーダー生成部215は、オーダー候補生成アルゴリズムを用いて、術式情報、病名情報、入院日情報、術日情報、病棟情報により、呼吸器リハビリテーションの対象の患者としての重要度を判定し、重要度情報を生成する。オーダー生成部215は、オーダー提案の候補となる患者と、オーダー候補情報に対応する重要度情報を一覧化して現場表示部132において表示可能なデータとして生成する。現場担当者であるリハビリテーション技師は、候補となる患者を重要度に応じて検討し、呼吸器リハビリテーションの実施計画案を作成することができる。また、現場担当者は、現場端末131から、呼吸機能検査をオーダー候補情報として指示者端末141に送信することができる。医師は、指示者端末141の指示者入力部143から、検査のオーダー候補情報に対して承認を行い、検査オーダーを実施することができる。また、オーダー生成部215は、呼吸器リハビリテーション料の算定対象として、患者へのオーダー候補情報を生成する。呼吸器リハビリテーション料の算定項目に対する医療行為(ケア項目)は、算定基準より「呼吸訓練」であることが決定するため、オーダー候補情報として、当該医療行為がオーダー候補情報として生成される。オーダー生成部215は、更にオーダー候補を生成する根拠となった情報、例えば、「COPD既往歴有の患者」の情報を根拠情報として生成する。オーダー候補情報と根拠情報は、指示者端末141へ送信される。
【0082】
医師は指示者表示部142の表示されるオーダー候補情報と根拠情報を確認し、指示者入力部143から承認情報を入力することで、「呼吸訓練」についてのオーダー情報を生成する。生成されたオーダー情報は、当該オーダーを実施する現場端末131へ送信され、現場表示部132へ表示される。現場担当者は、オーダーの実施を行い(すなわち 、オーダー情報に対応する、医療行為等を患者に対して実施(給付)し)、オーダーの実施の完了を示す実施完了情報を現場入力部133から入力する。現場端末131は、実施完了情報を医事部門端末151へ送信する。実施完了情報を受信した医事部門端末151は、呼吸器リハビリテーション料の診療報酬明細の作成を行う。診療報酬明細は、算定基準において呼吸器リハビリテーション料として定められている診療報酬点数から算定された結果である。医事部門端末151で作成された診療報酬明細は、受付端末111へ送信され、患者に対して請求書が発行される。
【0083】
(2)入院後に取得される利用者情報に基づく医療行為に応じた診療報酬の算定項目は、摂食機能療法、排尿自立指導料、褥瘡ハイリスク患者ケア加算、マスク又は気管内挿管による閉鎖循環式全身麻酔(厚生労働大臣が定める麻酔が困難な患者に行う場合)、退院時共同指導料、介護支援等連携指導料等がある。
【0084】
(摂食機能療法算定の例)
ここで、入院後に取得される利用者情報に基づく医療行為に応じた診療報酬の算定項目として、摂食機能療法を例に説明する。利用者情報取得部211は、摂食機能療法の算定対象となる患者として、電子カルテシステム302等の電子カルテの情報等から患者情報を取得する。例えば、算定基準に記載の摂食機能療法の算定対象となる病名が電子カルテ等に記載されている患者の利用者情報を取得する。診療報酬点数表には、摂食機能療法の算定対象となる患者(算定条件)、実施する(給付を行う)医療行為(ケア項目)、及び対価としての診療報酬の点数(対価)が定められており、算定基準記憶部221には、診療報酬点数表に基づいた算定基準が記憶されている。
【0085】
オーダー生成部215は、利用者情報を、摂食機能療法の算定基準に基づいて取得する。そして、オーダー生成部215は、摂食機能療法に応じたオーダー候補生成アルゴリズムを用いて、嚥下機能検査の対象患者を抽出する。オーダー生成部215は、オーダー候補生成アルゴリズムを用いて、抽出した電子カルテの患者が、利用者情報により、算定基準に該当するか否かを判別する。該当すると判別された場合には、摂食機能療法の算定対象として、患者へのオーダー候補情報を生成する。摂食機能療法の算定項目に対する医療行為(ケア項目)は、算定基準より「(リハビリテーション技師による診療計画書案をもとに、)嚥下造影又は内視鏡下嚥下機能検査を行い、訓練指導を行う」ものである。オーダー生成部215は、更にオーダー候補を生成する根拠となった情報を根拠情報として生成する。オーダー候補情報と根拠情報は、指示者端末141へ送信される。
【0086】
医師は指示者表示部142の表示されるオーダー候補情報と根拠情報を確認し、指示者入力部143から承認を入力することで、「嚥下造影又は内視鏡下嚥下機能検査を行い、訓練指導を行う」行為についてのオーダー情報を生成する。生成されたオーダー情報は、当該オーダーを実施する現場端末131から送信され、現場表示部132へ表示される。現場担当者は、オーダーの実施を行い(すなわち 、オーダー情報に対応する、医療行為等を患者に対して実施(給付)し)、オーダーの実施の完了を示す実施完了情報を現場入力部133から入力する。現場端末131は、実施完了情報を医事部門端末151へ送信する。実施完了情報を受信した医事部門端末151は、摂食機能療法算定の診療報酬明細の作成を行う。診療報酬明細は、算定基準において摂食機能療法として定められている診療報酬点数から算定された結果である。医事部門端末151で作成された診療報酬明細は、受付端末111へ送信され、患者に対して請求書が発行される。
【0087】
(3)退院時情報に基づく医療行為に応じた診療報酬の算定項目は、退院時リハビリテーション指導料、退院時薬剤情報管理指導料、診療情報提供料、退院時共同指導料、介護支援等連携指導料等がある。
【0088】
(退院時リハビリテーション指導料算定の例)
ここで、退院時情報に基づく医療行為に応じた診療報酬の算定項目として、退院時リハビリテーション指導料を例に説明する。利用者情報取得部211は、退院時リハビリテーション指導料の算定対象となる患者として、電子カルテシステム302等の電子カルテの情報等から利用者情報を取得する。例えば、算定基準に記載の退院時リハビリテーション指導料の算定対象となる入院中の処置等の履歴情報により、電子カルテに記載されている患者の利用者情報を取得する。診療報酬点数表には、退院時リハビリテーション指導料の算定対象となる患者(算定条件)、実施する(給付を行う)医療行為(ケア項目)、及び対価としての診療報酬の点数(対価)が定められており、算定基準記憶部221には、診療報酬点数表に基づいた算定基準が記憶されている。
【0089】
オーダー生成部215は、利用者情報である退院先情報及び退院予定日情報、及び入院中の処置等の履歴情報を、退院時リハビリテーション指導料の算定基準に基づいて取得する。そして、オーダー生成部215は、退院時リハビリテーション指導料に応じたオーダー候補生成アルゴリズムを用いて、退院時リハビリテーション指導の必要性が高い患者を抽出する。オーダー生成部215は、オーダー候補生成アルゴリズムを用いて、抽出した患者が、退院先情報、退院予定日情報、及び入院中の処置等の履歴情報により、算定基準に該当するか否かを判別する。該当すると判別された場合には、退院時リハビリテーション指導料の算定対象として、患者へのオーダー候補情報を生成する。退院時リハビリテーション指導料の算定項目に対する医療行為(ケア項目)は、算定基準より「患者の退院に際し、指導を行う」ものである。オーダー候補情報として、当該医療行為がオーダー候補情報として生成される。オーダー生成部215は、更にオーダー候補を生成する根拠となった情報を根拠情報として生成する。オーダー候補情報と根拠情報は、指示者端末141へ送信される。
【0090】
医師は指示者表示部142の表示されるオーダー候補情報と根拠情報を確認し、指示者入力部143から承認を入力することで、「患者の退院に際し、指導を行う」行為についてのオーダー情報を生成する。生成されたオーダー情報は、当該オーダーを実施する現場端末131へ送信され、現場表示部132へ表示される。現場担当者は、オーダー情報に基づきオーダーを実施する(ケア項目の給付を行う)。具体的には、医師やリハビリテーション技師が他職種とともに患者に対してリハビリテーション指導を行う。すなわち 、オーダー情報に対応する、医療行為等を患者に対して実施(給付)する。そして、現場担当者は、オーダーの実施の完了を示す実施完了情報を現場入力部133から入力する。現場端末131は、実施完了情報を医事部門端末151へ送信する。実施完了情報を受信した医事部門端末151は、退院時リハビリテーション指導料の診療報酬明細の作成を行う。診療報酬明細は、算定基準において退院時リハビリテーション指導料として定められている診療報酬点数から算定された結果である。医事部門端末151で作成された診療報酬明細は、受付端末111へ送信され、患者に対して請求書が発行される。
【0091】
以上説明したように、(1)入院前・入院時利用者情報に基づく医療行為についてのオーダー提案、(2)入院後に取得される利用者情報に基づく医療行為についてのオーダー提案、(3)退院情報に基づく医療行為についてのオーダー提案において本発明を適用することができる。
【0092】
以上のように、本発明の実施形態に係る医療・介護支援システム1は、追加で必要となる情報の提案を行うことで、追加取得情報を含む利用者情報と算定基準を用いて、患者に対して施すべき医療行為等のオーダー候補情報を生成することができる。医師等は、算定項目に必要な情報の取得の提案を受けることにより、必要な追加診療や追加検査の要否を判断することができる。それにより、情報不足によるオーダー提案機会を逸することなく、患者個々の状況に応じた適正な医療行為等を施すことができる。また、それに応じた適正な診療報酬の算定を行うことができる。
【0093】
また、医療・介護支援システム1は、クリニカルパスで予め決定された医療行為等についても、適正な医療行為等を提案するように運用しても構わない。
【0094】
より具体的には、オーダー生成部215は、患者等の利用者の少なくとも入院前、入院時、又は入院後のいずれかのタイミングで利用者に適用されるクリニカルパスを構成する医療行為等のオーダーに対して、利用者の少なくとも入院前、入院時、又は入院後のいずれかのタイミングにおける利用者情報を用いて当該オーダーを変更(追加、削除を含む)するためのオーダー候補情報を生成することができる。すなわち、クリニカルパスを、個々の利用者に応じてカスタマイズすることができる。
【0095】
さらに、オーダー生成部215は、例えば、クリニカルパスを構成する医療行為等のオーダーに対して、患者等の利用者の入院後、特に入院後に状態の変化などが生じた後に取得される利用者の利用者情報を用いてオーダーを提案、変更(追加、削除を含む)するためのオーダー候補情報を生成することができる。すなわち、入院後に刻々と変化する患者等の状況に合わせて、適正な医療行為等を提案することができる。
【0096】
また、以上は、患者への医療行為に対する診療報酬の算定に用いられるものとして説明しているが、介護行為に対する介護報酬の算定に用いても構わない。また、医師は歯科医師を含むものであり、医療行為には、歯科医療行為を含むものである。
【0097】
また、以上の説明において、オーダー候補情報は、患者に施すべき候補となる医療行為、すなわち前記利用者に施すべき候補となる医療行為の情報を例として説明したが、それに限られるものではなく、医療行為の実施計画、前記利用者に施すべき候補となる介護行為の情報、介護行為の実施計画、アセスメント結果の情報を含んだオーダーに係る提案、又はアセスメント結果の情報を含んだオーダーに係る提案に付随する情報であっても構わない。
【0098】
(プログラム)
図7は、コンピュータ801の構成を示す概略ブロック図である。コンピュータ801は、CPU802、主記憶装置803、補助記憶装置804、インタフェース805を備える。
【0099】
ここで、実施形態に係る医療・介護支援サーバ201を構成する各機能を実現するためのプログラムの詳細について説明する。
【0100】
医療・介護支援サーバ201は、コンピュータ801に実装される。そして、医療・介護支援サーバ201の各構成要素の動作は、プログラムの形式で補助記憶装置804に記憶されている。CPU802は、プログラムを補助記憶装置804から読み出して主記憶装置803に展開し、当該プログラムに従って上記処理を実行する。また、CPU802は、プログラムに従って、上記の記憶部に対応する記憶領域を主記憶装置803に確保する。
【0101】
当該プログラムは、具体的には、コンピュータ801において、医療者及び/又は介護者が利用者に給付するためのケア項目と、前記ケア項目の対価の情報と、前記ケア項目の給付に対して前記対価の発生が認められるための算定条件と、が紐づけられる算定基準を用いる医療支援及び/又は介護支援のためのプログラムであって、利用者に紐づけられる利用者情報を取得するステップと、前記利用者情報に、オーダー情報を生成するために必要な情報が充足しているかどうかを判別するステップと、前記必要な情報が充足していないと判別した場合に、前記必要な情報のうち不足している情報を提案するための追加取得情報の提案情報を生成するステップと、前記取得された利用者の利用者情報
が、前記算定基準
に適合するか否かを判断し、適合すると判断する場合に前記算定基準に紐づけられる前記ケア項目に応じたオーダー候補情報を生成するステップと、を実現するプログラムである。
【0102】
なお、補助記憶装置804は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例としては、インタフェース805を介して接続される磁気ディスク、光磁気ディスク、CD−ROM、DVD−ROM、半導体メモリ等が挙げられる。また、このプログラムがネットワークNWを介してコンピュータ801に配信される場合、配信を受けたコンピュータ801が当該プログラムを主記憶装置803に展開し、上記処理を実行してもよい。
【0103】
また、当該プログラムは、前述した機能の一部を実現するためのものであってもよい。更に、当該プログラムは、前述した機能を補助記憶装置804に既に記憶されている他のプログラムとの組み合わせで実現するもの、いわゆる差分ファイル(差分プログラム)であってもよい。
【0104】
以上、本開示のいくつかの実施形態を説明したが、これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものとする。
【課題】追加で必要となる情報の提案を行うことで、追加情報を含む利用者情報に基づいて、利用者に適正な医療行為等を提案する医療支援及び/又は介護支援のためのシステムを提供する。
【解決手段】医療支援及び/又は介護支援のためのシステム1は、ケア項目と、ケア項目の対価の情報と、ケア項目の給付に対して対価の発生が認められるための算定条件とが紐づけられる算定基準を記憶する算定基準記憶部と、利用者情報を取得する利用者情報取得部と、取得された利用者情報と算定基準からオーダー候補情報を生成するオーダー生成部と、利用者情報にオーダー候補情報を生成するために必要な情報が充足しているかどうかを判別する利用者情報判別部と、必要な情報が充足していないと判別した場合に必要な情報のうち不足している情報を提案するための追加取得情報の提案情報を生成する追加取得情報提案部と、追加取得情報の提案情報を表示する表示部とを備える。