(57)【要約】【課題】医薬品の成分処方が実施される際に、予備知識のない患者が容易に希望の医薬品を選択することができるようなシステムを構築する。【解決手段】保険者サーバ４００は、医療機関サーバ１００の端末から医薬品の成分についての処方内容情報を受信して処方箋ＤＢ４５０に登録する。保険者サーバ４００は、患者端末３００又は調剤薬局予約端末１１５から希望する処方条件を受信し、各薬品メーカー医薬品ＤＢ４７０を検索して処方条件を満足する少なくとも１つの医薬品を決定し、患者に提示する。【選択図】図１
2007148608.tif 000002
【特許請求の範囲】
【請求項１】
医薬品の処方に関して処方内容を入力する第１の端末装置、および被保険者である患者の希望する処方条件を入力する第２の端末装置の両端末と通信する保険者側のサーバ計算機による処方方法であって、前記サーバ計算機のメモリに格納されたプログラムを実行することによって、
前記第１の端末装置から被保険者の識別子と対応して医薬品の成分についての情報を含む前記処方内容を受信して被保険者ごとに処方箋情報を格納する処方箋データベースの該当する被保険者のレコードに登録し、
前記第２の端末装置からの被保険者の前記識別子を指定する要求に応答し、前記処方箋データベースから該当する未処方の処方箋情報を取り出し、表示のために前記第２の端末装置へ送信し、
送信した処方箋情報に対し、前記第２の端末装置から新薬か後発薬かの区分を含む前記処方条件を受信し、各薬品メーカーごとに前記成分に対応する医薬品の薬品名を格納する医薬品データベースを検索して前記処方条件を満足する少なくとも１つの医薬品の薬品名を決定し、
決定した前記薬品名を表示のために前記第２の端末装置へ送信することを特徴とする被保険者情報を利用した処方方法。
【請求項２】
前記サーバ計算機は、さらに前記第２の端末装置から選択された薬品名と調剤の予約をする薬局名の指定を受信し、指定された調剤薬局のサーバ計算機へ前記選択された薬品名を含む前記処方情報を送信することを特徴とする請求項１記載の被保険者情報を利用した処方方法。
【請求項３】
前記サーバ計算機は、さらに
前記第２の端末装置によって選択された薬品名に対応する情報を前記処方箋データベースの該当するレコードに登録し、
被保険者に対応して処方した薬品名を格納する調剤レセプトデータベースの該当する薬品名と前記処方箋データベースの該当する薬品名とを突き合わせて整合性を判定することを特徴とする請求項１記載の被保険者情報を利用した処方方法。
【請求項４】
医薬品の処方に関して処方内容を入力する第１の端末装置と、被保険者である患者の希望する処方条件を入力する第２の端末装置と、ネットワークを介して両端末と通信する保険者側のサーバ計算機とを有するシステムであって、
前記サーバ計算機は、前記第１の端末装置から被保険者の識別子と対応して医薬品の成分についての情報を含む前記処方内容を受信して被保険者ごとに処方箋情報を格納する処方箋データベースの該当する被保険者のレコードに登録する手段と、
前記第２の端末装置からの被保険者の前記識別子を指定する要求に応答し、前記処方箋データベースから該当する未処方の処方箋情報を取り出し、表示のために前記第２の端末装置へ送信する手段と、
送信した処方箋情報に対し、前記第２の端末装置から新薬か後発薬かの区分を含む前記処方条件を受信し、各薬品メーカーごとに前記成分に対応する医薬品の薬品名を格納する医薬品データベースを検索して前記処方条件を満足する少なくとも１つの医薬品の薬品名を決定する手段と、
決定した前記薬品名を表示のために前記第２の端末装置へ送信する手段とを有し、
前記第１の端末装置は、前記処方内容を入力して前記サーバ計算機へ送信する手段を有し、
前記第２の端末装置は、前記サーバ計算機から前記処方箋情報および決定した前記薬品名を受信して表示する手段と、前記被保険者の識別子に対応する前記処方条件を入力して前記サーバ計算機へ送信する手段とを有することを特徴とする被保険者情報を利用した処方システム。
【請求項５】
前記サーバ計算機は、さらに前記第２の端末装置から選択された薬品名と調剤の予約をする薬局名の指定を受信し、指定された調剤薬局のサーバ計算機へ前記選択された薬品名を含む前記処方情報を送信する手段を有し、
前記第２の端末装置は、さらに薬品名を選択し、前記薬局名を入力して前記サーバ計算機へ送信する手段を有することを特徴とする請求項４記載の被保険者情報を利用した処方システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、被保険者情報を利用した医薬品の処方技術に係わり、特に患者の希望する処方条件を満足するような医薬品を選択する処方技術に関する。
【背景技術】
【０００２】
従来、医療機関において患者に処方箋が渡され、患者は、その処方箋を持って調剤薬局に行き、調剤薬局の局員に処方箋を手渡して調剤してもらい、その調剤してもらった薬剤を受け取っていた。また、調剤された薬剤の薬剤名、服薬量及び服薬の仕方などが記録された薬剤情報箋が患者に手渡されていた。
【０００３】
また、処方箋の情報を保険者サーバで管理し、薬品の飲み合わせや限界値をチェックする仕組みは提案されている。しかしながら、処方の際に新薬や後発薬を選択できるようになった際の算出方法、及び、処方箋情報の管理方法は、確立されていない。
【０００４】
なお、本発明に関連するものとして、例えば特許文献１がある。
【０００５】
【特許文献１】特開２００５−１７３７０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
現在、日本では、医療機関が処方箋を発行する際に、新薬を指定することが多く、特許の切れた安価な後発薬を指定することは少ない。そのため、医療保険者の医療費負担を圧迫している。
【０００７】
従来、調剤薬局は医療機関が発行する処方箋に従い、処方箋に記載された薬品しか処方することができなかったが、医療費負担の増加が保険者の財政を圧迫している状況から、近い将来、処方箋の書式形式を同成分、同効能の医薬品であれば、新薬にするか後発薬にするかを患者が選択できる形に変更するという構想が、現在、厚生労働省で検討されている。
（問題１）
処方箋の書式形式が変更された場合に、患者が新薬で処方するか、後発薬で処方するかを選択できるようになるが、患者は、どの新薬がどの後発薬に該当するか、どの薬に何の成分が含まれているかの知識を持ち合わせていない場合が非常に多く、選択の希望を調剤薬局の薬剤師に伝える必要がある。薬剤師は、処方箋に記載されている情報を前提として、患者の希望に添った薬品を処方するなど、従来にない業務が発生し、薬剤師に掛かる負荷が大きくなるとともに、現在でも多くの調剤薬局では、患者が殺到し、医薬品を受け取るのにかなりの時間を要する場合が多く、新たな業務負荷により、これまで以上に患者が医薬品を受け取るのに時間がかかることが予想される。
（問題２）
また、患者が後発薬での処方を希望していても、調剤薬局によっては、後発薬を十分に取扱っていない場合があることも考えられ、調剤薬局を選択することも必要となってくる。
（問題３）
加えて、従来は、患者の同一疾患における複数医療機関へのはしご受診等で処方された処方内容や、他疾患によって他医療機関にて処方された処方内容を確認することができなかった。
（問題４）
また、従来、調剤レセプトは、保険点数が２０００点以上でなければ、処方箋を添付して送付する必要がなく、過誤請求があっても各保険者は、処方箋とレセプトの内容の整合性確認をすることができなかった。
【０００８】
本発明の目的は、処方箋の書式形式の変更が行われた際の上記の問題点を解決し、患者が希望通りに医薬品の処方方法を選択でき、保険者の医療費負担を軽減させることができる被保険者情報を利用した安全な処方方法およびそのシステムを提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために本発明では、保険者がサーバ計算機により処方箋データを管理し、この情報と患者の処方希望情報を用いて、患者の希望する処方条件を満足するような医薬品を提示する。より詳細には、
本発明のサーバ計算機は、患者の希望処方条件を基に、各薬品メーカーの医薬品データベースから合致する情報を算出する。
【００１０】
また、本発明は、保険者サーバが一元的に被保険者である患者の処方箋データベースを管理することにより、医療機関が処方の際に、患者の過去の処方履歴を確認し、医薬品の飲み合わせや限界値を確認し、処方する。
【００１１】
また、本発明は、保険者サーバが患者からの調剤薬局の指定に基づいて、指定された調剤薬局に対し処方の予約をする。
【００１２】
また、本発明は、保険者サーバが一元的に被保険者である患者の処方箋データベースを管理することにより、一次審査と代行決裁機関である、支払基金および国民健康保険連合会から送付された調剤レセプトを保険者サーバにより処方箋情報と突合し、審査確認をする。
【発明の効果】
【００１３】
本発明によれば、患者による後発薬の選択を促し、医薬品の重複処方等を予防することができ、調剤薬局の業務を効率化することができ、保険者の調剤における医療費負担を軽減することができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の被保険者情報を利用する処方方法と予約方法の実施形態について図面を用いて詳細に説明する。
【００１５】
図１は、実施形態の被保険者情報を利用する処方方法を実施するシステムの構成を示すブロック図である。図1において、１００は医療機関サーバ、１０５は保険証情報読取端末、１１０は処方箋情報確認更新端末、１１５は調剤薬局予約端末である。保険証情報読取端末１０５、処方箋情報確認更新端末１１０および調剤薬局予約端末１１５は、ローカルネットワークにより医療機関サーバ１００に接続される。２００は調剤薬局サーバ、２０５は保険証情報読取端末、２１０は処方箋情報確認端末である。保険証情報読取端末２０５および処方箋情報確認端末２１０は、ローカルネットワークにより調剤薬局サーバ２００に接続される。３００は患者端末、４００は保険者サーバである。４４０は記憶部、４４５は被保険者データベース（ＤＢ）、４５０は処方箋ＤＢ、４５５は処方内容ＤＢ、４６０は調剤レセプトＤＢ、４６５は調剤薬局情報ＤＢである。４７０は各薬品メーカー医薬品ＤＢである。５００、６００はネットワークであり、ネットワーク５００は、上記サーバおよび患者端末３００間を接続し、ネットワーク６００は、保険者サーバ４００と各薬品メーカー医薬品ＤＢ４７０間を接続する。ネットワーク５００、６００はインターネット等でもよい。
【００１６】
保険者サーバ４００は、医療保険者所有のサーバ計算機であり、そのメモリ上には、資格確認プログラム４０５、処方箋情報参照・更新プログラム４１０、希望処方条件設定プログラム４１５、処方パターン算出プログラム４２０、予約受付プログラム４２５、処方箋情報送信プログラム４３０、調剤レセプト・処方箋突合プログラム４３５の各プログラムが格納され、保険者サーバ４００のＣＰＵによって実行される。また、保険者サーバ４００の磁気ディスク等で構成される記憶部４４０上には、上記被保険者ＤＢ４４５から調剤薬局情報ＤＢ４６５までのＤＢが格納されている。
【００１７】
各薬品メーカー医薬品ＤＢ４７０は、各薬品メーカーのサーバの磁気ディスク等による二次記憶装置上にあり、調剤薬局情報ＤＢ４６５とそのサーバおよびネットワーク６００を介して接続されている。
【００１８】
保険証情報読取端末１０５、２０５は、それぞれ医療機関サーバ１００、調剤薬局サーバ２００（調剤薬局のサーバ計算機）に接続され、二次元バーコード認識装置、ＩＣチップ読取書込装置、保険者番号を識別し入力する装置及び表示装置を備えて構成される。また、保険証情報読取端末１０５、２０５は、Ｗｅｂブラウザを備え、医療機関サーバ１００およびネットワーク５００を介して、保険者サーバ４００にアクセスし、読み取った保険証情報を保険者サーバ４００に送信し、被保険者ＤＢ４４５の情報に関する表示画面を取得して表示する。
【００１９】
処方箋情報確認更新端末１１０は、医療機関サーバ１００に接続され、印刷装置、入力装置及び表示装置を備えて構成される。また、処方箋情報確認更新端末１１０は、Ｗｅｂブラウザを備え、医療機関サーバ１００およびネットワーク５００を介して、保険者サーバ４００にアクセスし、処方箋ＤＢ４５０及び処方箋算出情報に関する表示画面を取得し、表示する。また、処方箋情報確認更新端末１１０は、医療機関の入力した処方箋情報を保険者サーバ４００に送信する。また、処方箋情報及び患者属性情報を二次元バーコードに印刷する機能を有する。
【００２０】
調剤薬局予約端末１１５は、医療機関サーバ１００に接続され、二次元バーコード認識装置、ＩＣチップ読取書込装置、入力装置及び表示装置を備えて構成される。また、調剤薬局予約端末１１５は、Ｗｅｂブラウザを備え、医療機関サーバ１００およびネットワーク５００を介して、保険者サーバ４００にアクセスし、処方箋算出情報に関する表示画面を取得し、表示する。また、調剤薬局予約端末１１５は、患者の入力した希望処方情報を保険者サーバ４００に送信する。
【００２１】
処方箋確認端末２１０は、調剤薬局サーバ２００に接続され、入力装置及び表示装置を備えて構成される。また、処方箋情報確認端末２１０は、Ｗｅｂブラウザを備え、調剤薬局サーバ２００およびネットワーク５００を介して保険者サーバ４００にアクセスし、処方箋ＤＢ４５０の情報に関する表示画面を取得し、表示する。また、処方箋情報確認端末２１０は、入力された情報を保険者サーバ４００に送信する。
【００２２】
患者端末３００は、携帯端末、携帯電話、ＰＣ等であってよく、二次元バーコード認識装置、入力装置、表示装置およびＧＰＳ機能を備えて構成される。また、患者端末３００は、ＷＥｂブラウザを備え、ネットワーク５００を介して、保険者サーバ４００にアクセスし、処方箋算出情報に関する表示画面を取得し、表示する。また、患者端末３００は、患者の入力した希望処方情報を保険者システム４００に送信する。同様に調剤薬局予約端末１１５は、患者の入力した希望処方情報を保険者システム４００に送信できる。
【００２３】
次に図２〜図１０で示す各ＤＢのデータ構成例について説明する。図２は、被保険者ＤＢ４４５のデータ構成例であり、各レコードは、被保険者の加入保険者を示す保険者番号４４５１と、保険者内での被保険者のユニークな番号を示す記号番号４４５２と、被保険者の氏名を示す氏名４４５３と、被保険者の生年月日を示す生年月日４４５４と、被保険者の性別を示す性別４４５５の各データ項目からなる。なお、保険者番号４４５１と記号番号４４５２の組み合わせにより、被保険者をユニークなものとして特定することができる。
【００２４】
図３〜図６は、処方箋ＤＢ４５０の構成例である。図３〜図６に関しては、データ構成は同一のため、ここでは、図３を用いて説明する。ＤＢの各レコードは、保険者番号４４５１、記号番号４４５２、氏名４４５３、生年月日４４５４、性別４４５５、処方箋ごとにユニークな番号を持つ処方箋番号４５０６、処方箋が医療機関から交付された年月日を表す交付年月日４５０７、処方箋を発行した医療機関を示す医療機関コード４５０８、医療機関名を表す４５０９、処方箋を発行した保険医氏名を示す保険医氏名４５１０、処方箋の使用期限日を示す処方箋使用期限４５１１、調剤薬局への予約を行った年月日を示す予約状況４５１２、予約した調剤薬局名を示す４５１３、調剤薬局が患者に対して処方を行った年月日を示す処方年月日を示す４５１４、実際に処方を行った調剤薬局を示す調剤薬局４５１５、処方箋の処方内容を示す処方内容４５１６、および予約の際に、算出された処方パターンの選択を示す識別子４５１７の各データ項目で構成されている。なお、本実施例では、処方内容４５１６の内容は成分１（４５１６１）と成分２（４５１６２）の２種類のみ記載されているが、実際の運用上は、２つ以上になることもある。また、処方箋の処方期限については、処方箋の発行日を含めて４日以内と薬事法により定められている。
【００２５】
図７は、処方内容ＤＢ４５５のデータ構成例である。処方内容ＤＢ４５５は、処方箋の内容と患者の選択した希望処方情報から、算出された処方内容を一時的に格納するＤＢである。ＤＢの各レコードは、処方内容を区別する識別子４５１７、識別子で区別された予約可能な調剤薬局を示す予約調剤薬局４５１３、処方候補薬品名を示す薬品１（４５５３）、薬品２（４５５４）、薬品１（４５５３）と薬品２（４５５４）の合計金額を表す価格４５５５、調剤薬局と予約する際の端末の位置からの距離を示す距離４５５６の各データ項目にて構成される。なお、薬品名は処方箋の内容によって２つ以上になることもある。また、距離の算出方法に関しては、既存の技術、例えばＧＰＳなどで端末の位置を把握し、図９で示す調剤薬局情報ＤＢの郵便番号４６５１及び、住所４６５２より算出する。
【００２６】
図８は、調剤レセプトＤＢ４６０のデータ構成例を示すものである。調剤レセプトとは、調剤薬局にて処方を行った際に患者の加入している保険者に対し、請求を行う際に用いる診療明細書のことである。図８のデータ構成例では、調剤レセプトが電子化され、管理されている例を示す。ＤＢの各レコードは、保険者番号４４５１、記号番号４４５２、氏名４４５３、生年月日４４５４、性別４４５５、調剤レセプトごとに振られている番号を格納する調剤レセプト番号４６０６、調剤した年月日を示す調剤年月日４６０７、調剤薬局を示す調剤薬局コード４６０８、調剤した薬局名を示す調剤薬局４５１５、調剤した際の処方箋番号を示す４５０６、処方内容４６１１、内容の詳細を示す薬品１（４５５３）と薬剤２（４５５４）、および保険者に請求する際に用いる保険点数４６１２の各データ項目で構成されている。
【００２７】
図９は、調剤薬局情報ＤＢ４６５のデータ構成例を示すものである。ＤＢの各レコードは、調剤薬局の所在地を示す郵便番号４６５１、住所４６５２、調剤を行った薬局を示す調剤薬局コード４６０８、調剤薬局４５１５、薬局ごとの扱い薬品メーカーを管理している扱い後発薬メーカー４６５５、扱い新薬メーカー４６５６、および各薬局の周辺地図を示した薬局地図画像４６５７の各データ項目で構成されている。
【００２８】
図１０は、各薬品メーカー医薬品ＤＢ４７０のデータ構成例を示すものである。ここではＡ社とＣ社を例として取り上げている。ＤＢの各レコードは、処方箋の成分に対応する成分４７０１、各成分に対応する薬品名４７０２、各薬品の形状を示す形状４７０３、薬品の価格を示す価格４７０４、および薬品が保険内薬品であるか否かを示す保険内／外薬品４７０５の各データ項目で構成されている。
【００２９】
次に、図１１〜図１７に示すフローチャートの処理手順について、図１８〜図２１で示す表示画面の例を参照しながら説明する。なお、本実施例では、各ＤＢの“山田太郎”の例を用いて説明を行う。
【００３０】
図１１は、資格確認プログラム４０５が実行する患者所有の保険証の有効性の確認を行う処理の手順を示すフローチャートである。この処理を、被保険者ＤＢ４４５のデータ構成例を用いて説明する。
（１）保険証情報読取端末１０５は、患者の保険証情報である保険者番号と記号番号を読み取る（ステップ１０２）。医療機関サーバ１００は、この入力データを受け取る。ここでは保険証情報の読取は、保険証記載の数字情報の入力装置での入力を想定しているが、二次元バーコード、ＩＣチップ、磁気情報の読取であってもよい。なお、保険者番号とは患者が所属している保険者の番号を示すもので、記号番号とは保険者内でのユニークな番号である。保険者番号と記号番号の組合せにより被保険者を特定することができる。
（２）保険者サーバ４００は、ステップ１０２で読み取った患者の保険者番号と記号番号を送信する（ステップ１０３）。本実施例では、送信される保険者番号は“１１１１１”、記号番号は“２２２２２２２”となる。
（３）保険者サーバ４００は、ステップ１０３で送信されてきた患者の保険者番号・記号番号と被保険者ＤＢ４４５の保険者番号４４５１、記号番号４４５２を突合し、送信された記号番号と被保険者ＤＢ４４５の記号番号４４５２が合致すれば、ステップ１０６に進む（ステップ１０４、ステップ１０５）。本実施例では、送信された保険者番号、記号番号より“山田太郎”の資格の確認が行われる。
（４）保険者サーバ４００は、患者の資格を確認した後、処方箋情報参照・更新プログラム４１０へ処理を進める（ステップ１０６）。
【００３１】
図１２は、処方箋情報参照・更新プログラム４１０の処理手順を示すフローチャートである。処方箋情報参照・更新プログラム４１０は、実行する患者の過去の処方箋情報を参照し、医療機関が処方方針を決定した情報を登録する。この処理は、医療機関にて医師が、患者に処方された薬品の履歴を確認することによって、薬品の飲み合わせや、限界値を考慮した処方を行い、その情報により処方箋ＤＢ４５０を更新し、処方箋情報確認更新端末１１０にて処方箋情報及び患者の属性情報を含んだ処方箋を印刷し、患者に交付する処理である。
（１）保険者サーバ４００は、入力を受付けた保険者番号と記号番号を基に、患者の処方箋情報を特定し、過去の処方箋情報を抽出し、医療機関の処方箋情報確認更新端末１１０に送信する（ステップ２０２）。 なお、本実施例では、保険者サーバ４００から処方箋情報確認更新端末１１０に送信される情報は図３に示すものである。
（２）処方箋情報確認更新端末１１０は、ステップ２０２で抽出された処方箋情報を受信し、表示装置に表示する（ステップ２０３）。なお、表示される情報を本実施例では図１８の表示画面６０５に示す。
（３）処方箋情報確認更新端末１１０において、患者の診察後に医師が表示された情報を参照し、薬品の飲み合わせや限界値を考慮した処方情報として、４４５１〜４５１１および４５１６のデータ入力を行い、医療機関サーバ１００は、入力データを保険者サーバ４００に送信する（ステップ２０４）。
（４）保険者サーバ４００は、送信された処方箋情報を受信し、処方箋番号４５０６にユニークな処方箋番号を自動的に割り振り、新しい処方箋番号と受信した処方箋情報により処方箋ＤＢ４５０を更新する（ステップ２０５）。本実施例では、更新された処方箋ＤＢ４５０の該当するレコードは、図４に示すものとなる。なお４５１２〜４５１５のデータ項目には、「未予約」又は「未処方」が記録される。
（５）保険者サーバ４００は、ＤＢ更新のために記録した処方箋情報として、４４５１〜４５１１及び４５１６のデータを医療機関サーバ１００経由で処方箋情報確認更新端末１１０に送信する（ステップ２０６）。
（６）処方箋情報確認更新端末１１０は、登録された処方箋情報を受信し、新しい処方箋番号の情報を含んだ処方箋を印刷する（ステップ２０７）。また、患者に対する処方箋情報の提供は、二次元バーコードの印刷やＩＣカードへの書き込みであってもよい。
【００３２】
図１３は、希望処方条件設定プログラム４１５が実行する処理の手順を示すフローチャートであり、次にこれについて説明する。端末側が調剤薬局予約端末１１５、患者端末３００のどちらでも同じフローチャートとなる。
（１）調剤薬局予約端末１１５または患者端末３００は、保険者番号と記号番号の入力を受け取り、保険者サーバ４００に送信し、保険者が有する希望処方条件の設定ホームページへログインを行う（ステップ３０２）。
（２）保険者サーバ４００は、受信した記号番号と処方箋ＤＢ４５０の記号番号を突合させ、処方年月日に“未処方”の情報があるかどうかを検索する（ステップ３０３）。本実施例では、図４の診察後処方箋ＤＢの処方年月日４５１４より“未処方”のレコードを検索する。
（３）ステップ３０３での検索の結果、処方箋ＤＢ４５０に“未処方”のレコードがある場合は、ステップ３０５に進む（ステップ３０４）。本実施例では、図４の診察後処方箋ＤＢの処方年月日４５１４に“未処方”のレコードがあるため、ステップ３０５に進む。また、“未処方”のレコードがない場合は、条件設定のプログラムを終了する。
（４）“未処方”の情報が抽出された場合、保険者サーバ４００は、図４の診察後処方箋ＤＢに格納された未処方の処方箋レコードの４４５１〜４５１１及び４５１６のデータを調剤薬局予約端末１１５または患者端末３００に送信する（ステップ３０５）。
（５）調剤薬局予約端末１１５または患者端末３００は、“未処方”の処方箋情報を受信し、未処方の処方箋番号４５０６を画面に表示する（ステップ３０６）。なお、本実施例では、図４の未処方の処方箋レコードは１件であるため、表示される処方箋番号は“２０１０１”のみとなる。
（６）調剤薬局予約端末１１５または患者端末３００は、利用者から処方箋番号の選択情報を受け取ると、図１９に示す表示画面６１０を表示する。調剤薬局予約端末１１５または患者端末３００は、選択された処方箋番号と、処方条件として希望住所情報６１０１、希望価格帯情報６１０２、新薬または後発薬希望情報６１０３、希望薬品形状情報６１０４、および保険内または保険外情報６１０５の入力データを受け取り、これら入力データを保険者サーバ４００に送信する（ステップ３０７）。希望住所情報６１０１は、処方を希望する医療機関や薬局の住所である。また６１５は、表示画面６１０の選択情報を整理したものである。
（７）保険者サーバ４００は、処方箋番号の選択情報と選択された希望処方条件の情報を受信し、処方可能な薬品の組合せを算出する（ステップ３０８）。なお、算出方法については、図１４の説明にて詳細に記述する。
（８）保険者サーバ４００は、ステップ３０８で算出した処方パターン情報が格納されている処方内容ＤＢ４５５の情報を調剤薬局予約端末１１５または患者端末３００に送信する（ステップ３０９）。
（９）調剤薬局予約端末１１５または患者端末３００は、処方内容として処方可能な組合せ情報を受信し、表示する（ステップ３１０）。表示される画面は本実施例では、図２０の６２０である。
（１０）調剤薬局予約端末１１５または患者端末３００は、図１５の予約受付処理へ進む（ステップ３１１）
図１４は、処方パターン算出プログラム４２０が実行する処理の手順を示すフローチャートであり、次にこれについて説明する。処方パターン算出プログラム４２０は、端末から受信した希望処方条件を基に、調剤薬局情報ＤＢ４６５と各薬品メーカー医薬品ＤＢ４７０から該当する医薬品を検索し、抽出するプログラムである。なお、処方内容は、選択された希望処方条件をもとにＡＮＤ条件で絞り込まれる。
（１）保険者サーバ４００は、調剤薬局ＤＢ４６５の住所４６５２と端末の位置情報をＧＰＳ等既存の技術利用にて計測した位置情報から端末の現在位置から近い調剤薬局を特定する（ステップ４０２）。なお、調剤薬局を検索する距離範囲は、Ｓ３０７の希望住所情報の設定時に設定することができる。本実施例では、図１９の表示画面６１０が示す通り、半径５００Ｍ以内で検索している。本実施例において、該当する調剤薬局は、“◎□薬局”と“△△薬局”の２つであるとする。
（２）保険者サーバ４００は、特定された調剤薬局を調剤薬局ＤＢ４６５の扱い後発薬メーカー４６５５、扱い新薬メーカー４６５６と選択された処方条件の新薬または後発薬希望情報６１０３を突合し、条件に合致したものを抽出し、絞り込む（ステップ４０３）。本実施例では、図１９の表示画面６１０で示す通り、“後発薬”を選択しているため、◎□薬局で該当する薬品メーカーはＡ社とＣ社となり、△△薬局で該当する薬品メーカーは、Ｂ社となる。
（３）保険者サーバ４００は、処方箋ＤＢ４５０の処方内容４５１６の成分と絞りこんだ薬品メーカーの成分を各薬品メーカー医薬品ＤＢ４７０の成分４７０１から検索して突合させ、条件に合致したものを抽出する（ステップ４０４）。なお、本実施例では、図４の診察後処方箋ＤＢの示す通り、成分１に“ＡＡＡＡＡＡ”、成分２に“いいいいい”が格納されており、突合させた際に抽出される薬品名は、◎□薬局取り扱いのＡ社の４７１０の行の薬品名と４７２０の行の薬品名、また、Ｃ社の４７６０の行の薬品名となる。△△薬局取り扱いのＢ社には、成分１、成分２共に、該当する薬品が存在しない。
（４）保険者サーバ４００は、選択された保険内または保険外情報６１０５と絞り込んだ薬品メーカーの薬品の保険内／外薬品情報を各薬品メーカー医薬品ＤＢ４７０の保険内／外薬品４７０５から検索し突合させ、条件に合致した薬品を抽出する（ステップ４０５）。本実施例では、図１９の表示画面６１０で示す通り、“保険内”を選択しているため、該当する薬品は、成分“ＡＡＡＡＡＡ”については、Ａ社製の薬品名“ＡＢＣ”と“ＢＣＤ”に絞られる。また、成分いいいいいについては、Ａ社製の薬品名“ＯＰＱ”と“ＨＩＪ”と“ＬＭＮ”に絞られ、Ｃ社製では、薬品名“ＲＳＴ”と“ＢＣＣ”と“ＣＣＡ”に絞られる。
（５）保険者サーバ４００は、選択された希望薬品形状情報６１０４と絞りこんだ薬品の薬品形状を各薬品メーカー医薬品ＤＢ４７０の薬品形状４７０３から検索し突合し、条件に合った薬品を抽出する（ステップ４０６）。本実施例では、図１９の表示画面６１０で示す通り、希望薬品形状情報６１０４で“カプセル”を選択しているため、該当する薬品は、成分“ＡＡＡＡＡＡ”については、Ａ社製の薬品名“ＡＢＣ”に絞られる。成分“いいいいい”については、Ａ社製の薬品名“ＯＰＱ”とＣ社製の薬品名“ＲＳＴ”に絞られる。
（６）保険者サーバ４００は、絞り込まれた情報を基に、薬品の組み合せを算出する（ステップ４０７）。本実施例では、ステップ４０６で絞り込まれた通り、成分“ＡＡＡＡＡＡ”については、Ａ社製の薬品名“ＡＢＣ”のみが該当し、成分“いいいいい”については、Ａ社製の薬品名“ＯＰＱ”とＣ社製の薬品名“ＲＳＴ”が該当する。従って、組み合わせは、Ａ社製の薬品名“ＡＢＣ”とＡ社製の薬品名“ＯＰＱ”または、Ａ社製の薬品名“ＡＢＣ”とＣ社製の薬品名“ＲＳＴ”の２通りが候補となる。
（７）保険者サーバ４００は、ステップ４０６で絞り込んだ各薬品の価格を各薬品メーカー医薬品ＤＢ４７０の価格４７０４から検索し、検索した価格によってステップ４０７で算出した組み合わせの合計価格を算出し、選択された希望価格帯情報６１０２を突合し、条件に合致した薬品を抽出する（ステップ４０８）。本実施例では、図１９の表示画面６１０に示す通り、希望価格帯情報６１０２で“８００円以下”を選択している。ステップ４０７で算出した２通りの組合せとも合計価格が８００円を超えないため、ここでの絞込みは特に行われない。
（８）保険者サーバ４００は、Ｓ４０２〜Ｓ４０８で絞り込んだ処方内容を処方内容ＤＢ４５５に格納する（ステップ４０９）。なお、本実施例に関する格納情報を図７の処方内容ＤＢの構成例に示す。
【００３３】
図１５は、予約受付プログラムが実行する処理の手順を示すフローチャートである。次にこれについて説明する。
（１）調剤薬局予約端末１１５または患者端末３００は、図２０に示す表示画面６２０の識別子４５１７の選択情報を受け取り、保険者サーバ４００に送信する（ステップ５０２）。なお、本実施例では、識別子の“１”を選択するものとする。
（２）保険者サーバ４００は、選択された識別子の選択情報を受信し、調剤薬局情報ＤＢ４６５の該当薬局の地図画像４６５７を図２１に示す表示画面６２５の形式に編集する（ステップ５０３）。「住所」は、調剤薬局等の住所である。本実施例では、識別子“１”を選択しているため、編集する地図画像４６５７は、“１．ＪＰＧ”となる。
（３）保険者サーバ４００は、編集した予約詳細画面を調剤薬局予約端末１１５または患者端末３００に送信する（ステップ５０４）。本実施例では、予約詳細画面は図２１に示す表示画面６２５となる。
（４）調剤薬局予約端末１１５または患者端末３００は、予約詳細画面情報を受信し、表示する（ステップ５０５）。
（５）調剤薬局予約端末１１５または患者端末３００は、予約情報を受付けた場合は、ステップ５０７に進み、予約しない場合は、ステップ５０１に戻る（ステップ５０６）。本実施例では、図２１に示す表示画面６２５の条件で予約するものとする。
（６）調剤薬局予約端末１１５または患者端末３００は、ステップ５０６で患者が予約を選択した場合、保険者サーバ４００に予約情報を送信する（ステップ５０７）。ここで、調剤薬局予約端末１１５を使用時は、“印刷”ボタンの入力を受け、表示画面６２５を印刷する。
（７）保険者サーバ４００は、予約情報を受信し、図５の予約後処方箋ＤＢの予約状況４５１２と予約調剤薬局４５１３、識別子４５１７に情報を登録する（ステップ５０８）。本実施例では、図５で示す通り、予約状況４５１２には“２００５／０６／２８”を登録し、予約調剤薬局４５１３には“◎□薬局”を登録し、識別子４５１７には“１”を登録する。
（８）保険者サーバ４００は、予約情報が登録された予約後処方箋ＤＢの処方箋情報を調剤薬局サーバ２００の処方箋情報確認端末２１０に送信する（ステップ５０９）。本実施例では送信先は◎□薬局の処方箋情報確認端末２１０となる。
（９）処方箋情報確認端末２１０は、調剤薬局サーバ２００を経由して処方箋情報を受信する（ステップ５１０）。なお、この情報を基に調剤薬局は、調剤を実施する。
【００３４】
図１６は、処方情報送信プログラム４３０の実行する処理の手順を示すフローチャートであり、患者が予約した調剤薬局にて処方を受けた情報に基づいて処方箋ＤＢ４５０を更新する処理を示している。この処理について、図６の処方後処方箋ＤＢのデータ構成例をもちいて説明する。
（１）調剤薬局サーバ２００の保険証情報読取端末２０５は、入力された保険者番号、記号番号、処方箋番号、処方年月日、および処方調剤薬局の情報を、調剤薬局サーバ２００を介して保険者サーバ４００に送信する（ステップ６０２）。なお、本実施例では、保険者番号は“１１１１１”、記号番号は“２２２２２２２”、処方箋番号は“２０１０１”処方年月日は“２００５／０６／２９”、処方調剤薬局は“◎□薬局”となる。
（２）保険者サーバ４００は、処方情報を受信し、記号番号と処方箋番号の突合により、該当する処方箋情報を特定し、処方箋ＤＢ４５０を更新する（ステップ６０３）。なお、本実施例では、更新された処方箋ＤＢ４５０は、図６に示すものとなる。図５の処方年月日４５１４と調剤薬局４５１５では“未処方”であったものが、図６では、処方年月日４５１４が“２００５／０６／２９”に、調剤薬局４５１５が“◎□薬局”にそれぞれ更新されている。
【００３５】
図１７は、調剤レセプト・処方箋突合プログラム４３５の実行する処理の手順を示すフローチャートである。調剤レセプトとは、調剤薬局にて処方を行った際に患者の加入している保険者に対し、請求を行う際に用いる診療明細書のことである。調剤レセプトには、処方された医薬品名及び、保険者への請求金額が記載されている。また、調剤レセプトは、調剤薬局から一次審査及び代行決裁機関である社会保険診療報酬支払基金（以下、支払基金）に送付され、審査を受けた後に、各保険者に送付される。各保険者は、支払基金から送付された調剤レセプトに対して、内容点検を行う。現在は、保険点数が２０００点を超える高額の調剤レセプト以外は、処方箋を添付する必要はなく、処方箋とレセプトの内容の整合性を確認する内容点検は困難であったが、本発明では保険者サーバ４００にて処方箋ＤＢ４５０を管理しているため、突合による内容点検が可能となる。なお、本実施例では、“山田太郎”の“２００５／０６／２９”分調剤レセプトについて内容点検を行うものとする。また、保険点数は1点１０円を示し、患者は窓口にて３割を負担したものとする。
（１）保険者サーバ４００は、上記手続きを経てすでに作成済の調剤レセプトＤＢ４６０のデータ構成例の記号番号４４５２と処方箋番号４５０６と調剤年月日４６０７を図６の処方後の処方箋ＤＢ４５０に格納された記号番号４４５２と処方箋番号４５０６と処方年月日４５１４をキーに突合し、該当する処方箋情報を特定する（ステップ７０２）。
（２）保険者サーバ４００は、Ｓ７０２で突合した調剤レセプトと処方箋情報の処方内容の薬品名と成分の整合性を各薬品メーカー医薬品ＤＢ４７０を検索した結果によって審査する（ステップ７０３）。突合した結果整合性が取れていれば、処理は終了する。整合性が取れていない場合は、過誤請求の疑いがあるため、支払基金に該当調剤レセプトデータを送信し、返戻する（ステップ７０４）。本実施例では、Ａ社−ＡＢＣとＡ社−ＯＰＱは、それぞれ成分ＡＡＡＡＡＡと成分いいいいいと整合性が取れている。また、保険点数についてもＡ社−ＡＢＣとＡ社−ＯＰＱの被保険者負担分は６００円となる。被保険者負担分は、３割であるため、保険者への請求は１４００円となり、保険点数は“１４０点”となる。これは、調剤レセプトＤＢ４６０の保険点数４６１２と合致する。
【図面の簡単な説明】
【００３６】
【図１】実施形態のシステムの全体構成図である。
【図２】被保険者ＤＢのデータ構成例を示す図である。
【図３】診療前処方箋ＤＢのデータ構成例を示す図である。
【図４】診察後処方箋ＤＢのデータ構成例を示す図である。
【図５】予約後処方箋ＤＢのデータ構成例を示す図である。
【図６】処方後処方箋ＤＢのデータ構成例を示す図である。
【図７】処方箋内容ＤＢのデータ構成例を示す図である。
【図８】調剤レセプトＤＢの構成例を示す図である。
【図９】調剤薬局情報ＤＢの構成例を示す図である。
【図１０】各薬品メーカー医薬品ＤＢのデータ構成例を示す図である。
【図１１】資格確認プログラムの処理手順を示すフローチャートである。
【図１２】処方箋情報参照・更新プログラムの処理手順を示すフローチャートである。
【図１３】希望処方条件設定プログラムの処理手順を示すフローチャートである。
【図１４】処方箋パターン算出プログラムの処理手順を示すフローチャートである。
【図１５】予約受付プログラムの処理手順を示すフローチャートである。
【図１６】処方情報送信プログラムの処理手順を示すフローチャートである。
【図１７】調剤レセプト・処方箋突合プログラムの処理手順を示すフローチャートである。
【図１８】処方箋情報確認画面の例を示したものである。
【図１９】希望処方条件設定画面の例を示したものである。
【図２０】処方パターン画面の例を示したものである。
【図２１】予約詳細画面の例を示したものである。
【符号の説明】
【００３７】
１００：医療機関サーバ、１１０：処方箋情報確認更新端末、１１５：調剤薬局予約端末、２００：調剤薬局サーバ、３００：患者端末、４００：保険者サーバ、４１０：処方箋情報参照・更新プログラム、４１５：希望処方条件設定プログラム、４２０：処方パターン算出プログラム、４２５：予約受付プログラム、４３０：処方箋情報送信プログラム、４３５：調剤レセプト・処方箋突合プログラム、４５０：処方箋ＤＢ、４６０：調剤レセプトＤＢ、４６５：調剤薬局情報ＤＢ、４７０：各薬品メーカー医薬品ＤＢ。
【図１】
2007148608.tif 000003
【図２】
2007148608.tif 000004
【図３】
2007148608.tif 000005
【図４】
2007148608.tif 000006
【図５】
2007148608.tif 000007
【図６】
2007148608.tif 000008
【図７】
2007148608.tif 000009
【図８】
2007148608.tif 000010
【図９】
2007148608.tif 000011
【図１０】
2007148608.tif 000012
【図１１】
2007148608.tif 000013
【図１２】
2007148608.tif 000014
【図１３】
2007148608.tif 000015
【図１４】
2007148608.tif 000016
【図１５】
2007148608.tif 000017
【図１６】
2007148608.tif 000018
【図１７】
2007148608.tif 000019
【図１８】
2007148608.tif 000020
【図１９】
2007148608.tif 000021
【図２０】
2007148608.tif 000022
【図２１】
2007148608.tif 000023