JP2003196396A - 医療情報管理方法およびシステム - Google Patents

Abstract

(57)【要約】 【課題】 処方箋管理および適正な調剤処理および支払
審査を簡便確実かつ迅速に実行可能であり、かつ処理効
率に優れた医療情報管理方法およびシステムを提供す
る。 【解決手段】 処方箋データを受け付ける処方箋データ
受付ステップｓ２０１と、患者の属性情報に紐付けて処
方箋データをデータベースに登録する処方箋データ登録
ステップｓ２０２と、薬局端末より患者の属性情報を絡
めた処方箋検索リクエストを受付けるリクエスト受付ス
テップｓ２０３と、属性情報をデータベースにおいて照
合し該当患者の処方箋データを全て抽出する処方箋デー
タ抽出ステップｓ２０４と、抽出した処方箋データが含
む処方医薬品およびその処方分量に関する情報を制限テ
ーブルに対照し制限事項に抵触するか判定する処方判定
ステップｓ２０５と、判定結果と処方内容の修正指示と
処方内容を修正した処方箋データとの少なくともいずれ
かを薬局端末に送る処方箋送付ファイル送信ステップｓ
２０７とを実行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、医療情報管理方法
に関し、特に医療機関が発行し調剤薬局が調剤に用いる
処方箋をサーバで管理する方法に関する。

【０００２】

【発明の背景】近年の医療保険制度の危機的状況に対処
する制度改革の一環として、処方は医師、調剤は薬剤師
といった職能分離を図る「医薬分業体制」への移行や、
薬価差益の減額・撤廃が現実化しつつある。このような
厳しさを増す状況に対処すべく、調剤レセプトを電子化
して業務効率やカスタマーサービスの向上を図る動きが
ある。そこで調剤薬局では、医療機関にて患者毎に発行
された“紙”の処方箋に基づき調剤を行う一方で、この
調剤結果に基づいて調剤レセプトを電子的に作成し、審
査支払機関にその電子データを送信する処理を実現しよ
うとしている。

【０００３】

【発明が解決しようとする課題】しかしながら、従来の
手法によれば種々の問題点が存在した。例えば、調剤薬
局が紙の処方箋を参照しながら調剤レセプトを作成する
際に、医薬品名、数量、患者の保険番号などといった処
方箋記載内容をあらためて転記する必要があり、煩雑で
効率の低い処理を調剤薬局側に強いていた。しかも、せ
っかく電子データとして作成した調剤レセプトであって
も、審査支払機関に送る際には、紙の処方箋と別途送る
しかなく、業務効率の観点からは電子化した意義が低く
なりがちであった。

【０００４】もちろん、これを受け取る審査支払機関の
側でも、“紙”の処方箋と、電子データの調剤レセプト
とを照合して審査するために、電子データの調剤レセプ
トを一旦プリントアウトしてから前記処方箋と編綴する
作業が必要となっていた。つまり、“調剤レセプトの電
子化”とは言え、その実は、調剤レセプトデータを電子
的に保管して紙ファイルを低減する程度しか効果を発現
できていないのである。しかも、患者一人の１日分の薬
剤費が２０５円以下であれば調剤レセプトにおける薬剤
名を省略することができることとなっているため、処方
箋に基づかない架空レセプトが発行されたとしても、そ
れをチェックして排除することが難しかった。

【０００５】また、同じ疾病について複数の医療機関を
受診するいわゆる“はしご受診”を行う患者に対し、各
医療機関から発行された複数の処方箋に基づき多量の医
薬品を重複調剤してしまう惧れを排除できなかった。し
たがって、医薬品毎に定められた投与限界量や、医薬品
同士の飲合わせ禁忌等について、調剤前にチェックする
ことも困難であった。してみれば、過剰な医薬品を服用
しても、その服用量に応じた治療効果が得られる訳では
ない旨を患者に理解させる機会を提供しずらく、ひいて
は医療費高騰を招来する惧れすらあった。

【０００６】そこで本発明はこのような従来の課題に着
目してなされたもので、処方箋管理および適正な調剤処
理および支払審査を簡便確実かつ迅速に実行可能であ
り、かつ処理効率に優れた医療情報管理方法およびシス
テムを提供することを目的とする。なお、ここで言う
「調剤処理」は、薬剤の調合処理、レセプト発行処理お
よびレセプト請求処理などの総称とする。

【０００７】

【課題を解決するための手段】上記目的を達成する本発
明の医療情報管理方法は、医療機関が発行し調剤薬局が
調剤に用いる処方箋をサーバで管理する方法であって、
サーバが、医療機関由来の処方箋データを受け付ける処
方箋データ受付ステップと、前記処方箋を発行された患
者の属性情報に紐付けて、前記処方箋データをデータベ
ースに登録する処方箋データ登録ステップと、調剤薬局
の薬局端末より、患者の属性情報を絡めた処方箋検索リ
クエストを受付けるリクエスト受付ステップと、受け付
けた前記属性情報をデータベースにおいて照合し、該当
患者の処方箋データを全て抽出する処方箋データ抽出ス
テップと、抽出した処方箋データが含む処方医薬品およ
びその処方分量に関する情報を、医薬品処方に関する医
療上の制限事項を定めた制限テーブルに対照し、前記制
限事項に抵触するか判定する処方判定ステップと、前記
判定の結果と、当該判定結果に応じて前記制限事項を遵
守すべく生成した処方内容の修正指示と、前記判定結果
に応じて前記制限事項を遵守すべく処方内容を修正した
処方箋データとの少なくともいずれかを、薬局端末に送
る処方箋送付ファイル送信ステップと、を備えたことを
特徴とする。

【０００８】

【発明の実施の形態】以下に本発明の実施形態について
図面を用いて詳細に説明する。図１は本実施形態におけ
る処方箋管理機関システムを含むネットワーク概要図で
ある。この実施例の背景として、今まで存在した医療機
関、調剤薬局、および審査支払機関の他に、本発明の医
療情報管理方法を実行する処方箋管理機関を設けて、こ
の処方箋管理機関の果たす役割を本発明におけるサーバ
（医療情報管理システム）としての処方箋管理機関シス
テムが担う状況を想定する。勿論、本実施例だけに本発
明の適用範囲が限定されるものではなく、処方箋に基づ
いて調剤および調剤レセプト作成を行ういずれの状況に
も本発明を適用することが可能であるのは言うまでもな
い。

【０００９】本発明を実現するサーバとしての処方箋管
理機関システム１０は、前記処方箋管理機関が運営・管
理しているサーバーであって、例えば処方箋管理サービ
スを提供する管轄エリア毎に運営される。そして、イン
トラネットやインターネット、或いは公衆回線網など各
種の通信回線網と接続してそのプロトコルに則ったデー
タ通信を実行する通信装置を付帯させている。当該処方
箋管理機関システム１０はこの通信装置を介し、医療機
関における医療機関システム２０や、或いは調剤薬局が
備える調剤薬局システム（調剤薬局端末）３０、並びに
審査支払機関が備える審査支払機関システム（審査支払
機関端末）４０等と、患者や医療機関、調剤薬局等のID
や属性情報等の各種データや認証結果等の送受信を処理
する。また一方で、処方箋データとそれから派生した調
剤結果および調剤レセプトの管理を行う。

【００１０】勿論この処方箋管理機関システム１０はサ
ーバコンピュータとして、各種演算処理を行う中央処理
部１１、メモリに代表される記憶部１２、ディスプレイ
等の表示部１３、そしてキーボードやマウス等の入力部
１４を備えている。また、ファイヤウォールサーバとし
て外部からの不正進入を抑止したり、WWWサーバとして
機能するものでもあるし、データ通信相手とのコミュニ
ケーションを図るメールサーバーとしても機能可能なも
のである。

【００１１】このような処方箋管理機関システム１０
は、データベースとして例えば処方箋受付データベース
１１０、医療機関データベース１３０、調剤薬局データ
ベース１４０、処方箋管理データベース１５０、飲合わ
せ不可データベース２００、限界量データベース２１
０、処方箋登録データベース２５０、調合修正ファイル
２８０を備えている。主に認証用の情報を蓄積管理して
いるのが、医療機関データベース１３０および調剤薬局
データベース１４０である。これらのデータベース１３
０、１４０では図７および図８に示すように、処方箋管
理機関と結んだ医療機関および調剤薬局について、医療
機関コード１３１および調剤薬局コード１４１をキーに
各種属性情報を絡めたレコードを管理している。属性情
報には、例えばID情報１３２、１４２、医療機関名１３
３、調剤薬局名１４３、住所１３４、１４５、電話番号
等の連絡先１３５、１４６など当該医療機関や調剤薬局
に由来する情報が適宜含まれている。

【００１２】また、処方箋受付データベース１１０は、
患者が医療機関を訪れてそこで発行される処方箋データ
を当該医療機関の医療機関システム２０から受け付ける
データベースである。このデータベース１１０は、例え
ば医療機関毎にデータを蓄積することとし、当該医療機
関が発行した処方箋データの発行順に行列を形成する。
データ構造としては、図６に示すように、処方を受けた
患者の保険者番号１１１、記号番号１１２、氏名１１
３、生年月日１１４、性別１１５、処方内容１１６、処
方箋交付年月日１２１、処方箋を発行した医療機関コー
ド１２２、保険医氏名１２３、処方箋の使用期間１２
４、摘要１２５、受付番号１２６から構成される。特
に、処方内容１１６は、医薬品名１１７、分量１１８、
用法１１９、調剤日数１２０といった詳細な処方内容の
情報が含まれている。また、受付番号１２６は、各医療
機関システム２０で発行するが、当該処方箋管理機関シ
ステム１０でも発行することができる。なお、この処方
箋受付データベース１１０は、医療機関システム２０に
おいては同じ内容のデータベースが処方箋作成データベ
ース１１０’として管理運営される。

【００１３】更に処方箋受付データベース１１０で受け
付けた処方箋データは、処方箋管理データベース１５０
（図９参照）において管理されることになる。この処方
箋管理データベース１５０は、受け付けた各処方箋デー
タに関して、調剤薬局からの検索リクエストがかかった
状態なのか、或いは既に調剤が完了した状態なのかいっ
たステータス情報１６０を付加してリアルタイムに管理
している。処方箋管理機関システム１０は、このステー
タス情報１６０に基づき、調剤薬局システム２０等から
の処理要求に応じるか否か判断出来る。加えて、調剤を
行うべく処方箋データの照会をしてきた調剤薬局の薬局
コード１６１が、照会年月日１６２と共に処方箋データ
毎に登録されている。この照会に対して処方箋管理機関
システム１０が返した回答に関し、その回答年月日１６
３と回答内容１６４とが合わせて記録されている。その
他のレコード内容は、処方箋受付データベース１１０で
受け付けた処方箋データと同様の内容となっている。

【００１４】この他、処方箋データが含む処方医薬品お
よびその処方分量に関する情報に関して、医薬品処方に
関する医療上の制限事項に抵触しないか判定するための
飲合わせ不可データベース２００、および限界量データ
ベース２１０が制限テーブルとして配置される（図１２
および図１３参照）。なお、これらのデータベース２０
０、２１０は後述する審査支払機関システム４０も同２
００’、２１０’として備えている。飲合わせ不可デー
タベース２００は、互いに飲み合わせると不適切である
とされる医薬品の組合せをテーブル化したものであり、
図１２に示すように、医薬品欄２０１、２０２でそれら
組合せを特定している。一方、限界量データベース２１
０は、一定期間内における一患者に対する医薬品投与量
の限界を定めた情報を、各医薬品２１１毎の限界量２１
２に関しテーブル化したものである。

【００１５】上記のような医療上の制限事項に基づく処
方箋データおよび調剤結果の判定の上で、処方箋管理デ
ータベース１５０の処方箋データは処方箋登録データベ
ース２５０に登録される（図１５参照）。このデータベ
ース２５０におけるデータ構造としては、上述した処方
箋管理データベース１５０にて管理されている処方箋デ
ータと同様の情報を含むと共に、更に前記飲合わせや限
界量に関する判定結果２６７、２６８ならびにコメント
２６９が付与されたものとなっている。

【００１６】また、調合修正ファイル２８０は、前記の
制限事項に抵触する処方内容または調剤内容に関して、
処方箋データ毎または調剤データ毎に抽出して調合修正
のポイントとしてデータ構成したものである（図１６参
照）。このファイルは審査支払機関システム４０でも調
合修正受付ファイル２８０’として備えている一方、医
療機関に設置されているのが、医療機関システム２０で
ある。処方箋管理機関システム１０と同様に、中央処理
部２１、記憶部２２、表示部２３、入力部２４、並びに
出力部２５を備えると共に、前述したように処方箋作成
データベース１１０’を備える。当該医療機関にて受診
した患者に発行した処方箋はこの処方箋作成データベー
ス１１０’において管理される。

【００１７】医療機関の発行した処方箋データに基づき
実際の調剤を行うのが調剤薬局であり、この調剤薬局が
備えるのが調剤薬局システム３０である。これも上記同
様に、中央処理部３１、記憶部３２、表示部３３、入力
部３４、並びに出力部３５を備える。またデータベース
として、前記処方箋受付データベース２２０’、メッセ
ージデータベース３３０、調剤データベース３００、レ
セプトデータベース３４０、医薬品点数データベース３
６０を備える。このうち、処方箋受付データベース２２
０’については既に上述しているため説明は省略する。

【００１８】調剤データベース３００は、処方箋管理機
関システム１０が抽出した患者毎の処方箋データに基づ
き行った調剤結果を登録するデータベースである（図１
７参照）。ここでは処方箋受付データベース２２０’に
おいて受け付けた処方箋データの他に、実際に調剤した
調剤内容を登録している。例えば、調剤を行った調剤薬
局のコード３１８、調剤薬局名３１９、調剤薬局システ
ム３０側で判定した飲合わせ結果３２０および限界量の
結果３２１ならびにコメント３２２、調剤年月日３２３
の情報が含まれる。また、医療機関で発行した処方箋通
りに調剤したか否かを回答３２４で記録してある。

【００１９】メッセージデータベース３３０は、前記制
限事項に関する判定結果に応じたメッセージ３３３
（例：「処方された薬の飲合わせは異常ありません。薬
の量も基準範囲内です。」）が登録されている（図１８
参照）。ここでは飲合わせおよび限界量のそれぞれの判
定結果３３１、３３２の場合分けに応じてメッセージが
登録されている。レセプトデータベース３４０は、前記
調剤データベース３００にて登録された調剤結果に対
し、調剤料や調合料、加算料、請求点数といった情報を
付加して調剤レセプトを形成するものである（図１９参
照）。このレセプトデータベース３４０は、審査支払機
関システム４０においてはレセプトデータベース３４
０’として配置されている。前記調剤レセプトのデータ
を作成する際に参照されるのが、医薬品点数データベー
ス３６０である（図２０参照）。医薬品毎の単位数量あ
たりの請求点数が設定されたデータ構造をなしている。

【００２０】調剤薬局システム３０から調剤レセプトの
データを受け取って、それに対する支払いを審査するの
が審査支払機関である。この審査支払機関が備えるのが
審査支払機関システム４０である。これも上記同様に、
中央処理部４１、記憶部４２、表示部４３、入力部４４
などを備える。またデータベースとして、飲合わせ不可
データベース２００’、限界量データベース２１０’調
合修正ファイル２８０’、レセプトデータベース３４
０’、レセプト調査要データベース４００を備える。飲
合わせ不可データベース２００’、限界量データベース
２１０’調合修正ファイル２８０’、レセプトデータベ
ース３４０’に関しては既出のため説明を省略する。レ
セプト調査要データベース４００は、処方箋管理機関シ
ステム１０由来の調合修正受付ファイルに基づき特定し
た、修正調剤を伴う調剤レセプトのうち、前記制限事項
に突合した調剤レセプトデータをあらためて格納するデ
ータベースである（図２３参照）。

【００２１】なお、上記の各データベースのうち、１１
０、１３０、１４０、１５０、２００、２１０、２５
０、２８０は、別々の記憶装置に設けられてネットワー
ク結合した各個独立のデータベースとして機能するもの
でもよいし、適宜組み合わせたり或いは１つの記憶装置
に集約して設けてもよい。また同様に、前記データベー
スのうち、２２０’、３００、３３０、３４０、３６０
は、別々の記憶装置に設けられてネットワーク結合した
各個独立のデータベースとして機能するものでもよい
し、適宜組み合わせたり或いは１つの記憶装置に集約し
て設けてもよい。また同様に、前記データベースのう
ち、２００’、２１０’、２８０’、３４０’、４００
は、別々の記憶装置に設けられてネットワーク結合した
各個独立のデータベースとして機能するものでもよい
し、適宜組み合わせたり或いは１つの記憶装置に集約し
て設けてもよい。更に、飲合わせ不可データベース２０
０、限界量データベース２１０については、処方箋管理
機関システム１０、医療機関システム２０、調剤薬局シ
ステム３０、および審査支払起案システム４０で共有す
るとしてもよい。

【００２２】加えて、処方箋管理機関システム１０と医
療機関システム２０、調剤薬局システム３０、審査支払
機関４０らをつなぐネットワークに関して本実施形態で
は、インターネットだけに限らず、エクストラネットを
用いたＷＡＮ（Wide Area Network）、ＡＴＭ回線、パ
ソコン通信回線、ＬＡＮ、無線ネットワークなど様々な
ネットワークを採用することも出来る。また、ＩＰＶＰ
Ｎなど仮想専用ネットワーク技術を用いれば、インター
ネットにおいても通信に関する高い機密性を効率よく実
現できて好適である。他に、審査支払機関が処方箋管理
機関を兼ねるとすれば、処方箋管理機関システム１０と
審査支払機関システム４０とがネットワークを通じて共
働するとしてもよいし、もともと一つのシステムとして
統合されているとしてもよい。

【００２３】図２は本実施形態における医療情報管理方
法を含む全体手順を示す流れ図であり、図３は本実施形
態における飲合わせおよび限界量のチェック過程を示す
流れ図、図４は、本実施形態における調剤過程を示す流
れ図、図５は本実施形態における調剤レセプトの審査過
程を示す流れ図である。以下、本発明の医療情報管理方
法の実際手順について、医療機関、処方箋管理機関、調
剤薬局、ならびに審査支払機関の各者の関係をふまえつ
つ説明する。まず、病を患うある者が患者として医療機
関を訪れたとする。

【００２４】この患者は、例えば保険証や診察券などを
提示して所定の診療を受ける。その結果、投薬が必要と
なれば、この医療機関の医師が処方箋を発行する。この
医療機関では、医療機関システム２０において、医薬品
名、数量、被保険者の属性情報等からなる処方箋情報が
作成される。また、この処方箋情報には、患者の受付順
に受付番号が採番され、図６で示したような処方箋デー
タが生成され処方箋作成データベース１１０’に登録さ
れていく。患者の所持する保険証若しくは診察券等が記
録媒体としての機能を備えるのであれば、当該患者の被
保険者番号や受付番号といった、患者と処方箋とを特定
可能な情報をこの診察券等に記録するとすれば好適であ
る。前記処方箋情報は処方箋管理機関システム１０に送
られる。

【００２５】処方箋管理機関システム１０では、これを
受付けて処方箋受付データベース１１０に格納する（ｓ
２０１）。一旦格納した処方箋情報は、被保険者番号、
記号番号、患者の氏名、生年月日、性別、処方箋を発行
した医療機関コード、受付番号、医薬品名等の情報を付
帯させた処方箋データとして処方箋管理データベース１
５０に登録する（ｓ２０２）。このとき、当該処方箋デ
ータに対し、調剤薬局システム３０からの処方箋検索リ
クエストを受け付けるとの意味で「受付」なるステータ
ス情報を設定する。

【００２６】また、登録する或いは登録した処方箋デー
タに関して、各処方箋データに紐付けられた患者の属性
情報を対照することで、同一患者が一定期間内に同内容
の処方を受けたことを検知するとすれば好適である。こ
こで、短期間での再受診が検知されたならば、該当患者
に関して一定期間内の再受診が検知された旨を、関係す
る調剤薬局システム３０または医療機関システム２０に
通知する。これにより、該当患者は自身の“はしご受
診”について認識することが出来る。

【００２７】処方箋を発行された前記の患者は、処方さ
れた医薬品を受け取るべく調剤薬局を訪れる。ここで前
記の受付番号や被保険者番号等を調剤薬局側に通知する
か、若しくはこれらを記録した前記診察券等を提示す
る。調剤薬局における調剤薬局システム３０では、当該
患者の受付番号や被保険者番号といった患者の属性情報
を絡めた処方箋検索リクエストを生成し、処方箋管理機
関システム１０に送信する（ｓ３０１）。調剤薬局の側
で、処方箋管理機関システム１０に格納されている当該
患者の処方箋データを参照して実際の調剤行為を行うた
めである。

【００２８】処方箋管理機関システム１０ではこのリク
エストを受けて、当該リクエストに含まれる前記受付番
号や被保険者番号をキーにして処方箋管理データベース
１５０における処方箋データの検索と抽出を実行する
（ｓ２０３）。但し検索の結果、該当する処方箋データ
のステータス情報が、前述したように「受付」の設定と
なっていない場合には、既に他の調剤薬局システム３０
からの検索リクエストを受け付けた後であるとして処方
箋データの抽出は拒否する。該当した処方箋データのス
テータス情報が「受付」にしてもそうでないにしても、
このステータス情報を調剤薬局システム３０に返す。調
剤薬局システム３０では、調剤を行おうとする処方箋デ
ータのステータス情報を受信し、表示部３３に出力する
（ｓ３０２）。

【００２９】処方箋管理データベース１５０において検
索された処方箋データのステータス情報が、「受付」で
あった場合、該当する処方箋データを全て抽出し、処方
箋抽出テーブル１７０に一度格納する（図１０参照）。
ここで図３を参照して処方箋管理機関システム１０にお
ける処理を詳述する。処方箋管理データベース１５０か
ら抽出した処方箋データを処方箋抽出テーブル１７０に
一時格納したならば（ｓ１）、続いて、抽出した処方箋
データにおいては複数の医薬品を含むか判定する（ｓ
２）。これにより医薬品の種類が複数あれば、医薬品同
士の飲合わせを判定する必要が出てくる訳である。そこ
で飲合わせ不可データベース２００において処方箋デー
タを突合処理する（ｓ３）。

【００３０】この突合処理の結果、医薬品同士の飲合わ
せが不適切である場合、処方箋抽出テーブル１７０の飲
合わせ欄１８７に「ＮＧ」を登録する。他方、飲合わせ
に問題が無ければ、同欄１８７に「ＯＫ」を登録する。
続いて、複数の医薬品のうちに同じ医薬品が含まれてい
る場合、つまり医薬品の重複があるか否か判定し（ｓ
５）、重複があれば、同種の医薬品の数量を集計してそ
の結果を集計テーブル１９０（図１１参照）に格納す
る。図に示すように、医薬品１９１毎の合計数量１９２
が記録されていく。

【００３１】処方箋管理データベース１５０より抽出さ
れた処方箋データが一種類の医薬品しか含まない場合、
若しくは複数の医薬品を含むが同種の医薬品が重複して
いる場合には、限界量データベース２１０における処方
箋データの突合処理を行う（ｓ７）。一定期間内に一患
者に投薬可能な限界量を越えた量の医薬品が処方されて
いると判定されたならば（ｓ８）、処方箋抽出テーブル
１７０の限界量欄１８８に「ＮＧ」を登録する。一方、
限界量を越えていないと判定されたならば、同欄１８８
に「ＯＫ」を登録する（ｓ９’）。この飲合わせと限界
量とに関する突合判定の結果、飲合わせが「ＯＫ」かつ
限界量が「ＮＧ」の場合（ｓ１０）、限界量以内に処方
総量を低減すべく、限界量をオーバーした差分を該当す
る医薬品の処方分量から差し引きし処方箋抽出テーブル
１７０を更新する（ｓ１１）。これにより修正した処方
箋データ（修正処方箋データ）が形成されるのである。
そして処方箋抽出テーブルの限界量コメント欄１８９に
おいて、「修正済み」である旨を追記する（ｓ１２）。
以上の処理が終了した処方箋データに関しては、処方箋
登録データベース２５０に登録する（ｓ１３）。

【００３２】以上、図３に即して説明した処理は、図２
の流れ図で言えば、ステップｓ２０４およびｓ２０５に
相当する。処方箋管理データベース２５０に登録した処
方箋データは、既に調剤薬局システム３０からの検索リ
クエストを受けた訳であるから、そのステータス情報を
「確認中」と更新し（ｓ２０６）、他の調剤薬局システ
ム３０からの各種リクエストを受付ない設定とする。ま
た、この処方箋データに、これを発行した医療機関の属
性情報等を付加した処方箋送付ファイル２２０（図１４
参照）を作成して調剤薬局システム３０に返信する（ｓ
２０７）。調剤薬局システム３０に送った処方箋データ
に関しては、その処理状況について処方箋登録データベ
ース２５０において更新登録しておく（ｓ２０８）。

【００３３】一方、調剤薬局システム３０では処方箋管
理機関システム１０から送られてきた処方箋送付ファイ
ルを受信し、処方箋受付ファイル２２０’に格納する
（ｓ３０３）。調剤薬局の側では、この処方箋受付ファ
イル２２０’に含まれる処方箋データに基づき、実際に
薬剤師が調剤業務を行うことになる。調剤の際には、処
方箋データに示された飲合わせ及び限界量の判定結果情
報（ＯＫかＮＧなのか、修正は行われたのか）に留意し
た調剤が行われる。この調剤結果は、例えば調剤薬局シ
ステム３０における入力部３４より入力され、処方箋受
付ファイル２２０’に追加登録される（ｓ３０４）。調
剤結果が付加された処方箋受付ファイル２２０’は調剤
データとして調剤データベース３００に格納すると共
に、処方箋管理機関システム１０に送信される（ｓ３０
５）。

【００３４】調剤薬局における上記一連の調剤処理を仔
細に説明するのが図４である。処方箋管理機関システム
１０から処方箋送付ファイル２２０を受け付けて、処方
箋受付ファイル２２０’に格納する（ｓ３０）ところか
ら処理が始まる。格納した処方箋受付ファイル２２０’
が含む飲合わせ及び限界量の判定結果について、飲合わ
せがＯＫでかつ限界量がＮＧであるか否かを参照する
（ｓ３２）。飲合わせがＯＫでかつ限界量がＮＧである
場合、処方通りでよいか否かを限界量コメント２４２で
もって判断する（ｓ３３）。既に処方分量が修正された
ものである場合、処方箋通りに調合した旨の情報を処方
箋受付ファイルに追加する（ｓ３４’）。

【００３５】他方、飲合わせがＯＫでかつ限界量がＮＧ
でない場合、飲合わせ、限界量ともにＯＫか否かを参照
する（ｓ３２）。ＯＫの場合には前記ステップｓ３４’
に処理を進める。飲合わせおよび限界量ともＯＫではな
い場合、調剤薬局が判断して調合した医薬品とその分量
についてその情報を処方箋受付ファイル２２０’に追加
登録する（ｓ３４）。そして、飲合わせや限界量につい
ての判定結果をキーに、メッセージデータベース３３０
においてメッセージ検索を行う。検索されたメッセージ
３３３は、適宜な一時テーブルに格納し（ｓ３５）、処
方箋受付ファイル２２０’に追加登録する。

【００３６】処方箋受付ファイル２２０’の内容は、調
剤薬局システム３０の出力部３５において適宜出力され
（ｓ３６）、調剤データとして調剤データベース３００
に格納されることとなる。このとき、処方箋データ通り
の調剤が行われたか否かの回答が回答欄３２４において
追記される。この調剤データベース３００に格納された
調剤データは、処方箋データに対する実際の調剤結果と
して処方箋管理機関システム１０に送られることとなる
（ｓ３８）。

【００３７】図２の流れ図に説明を戻す。ステップｓ３
０５で、調剤薬局システム３０から送信された調剤デー
タを、処方箋管理機関システム１０は受信する（ｓ２０
９）。これより処方箋管理機関システム１０では、調剤
薬局における実際の調剤結果たる調剤データを取得す
る。この調剤データは、調剤薬局が処方箋データ通りに
調剤を行ったか否かを示す前記回答の情報（回答年月日
およびその回答内容）を付加した上で、処方箋登録デー
タベース２５０に登録される。また、該当する処方箋デ
ータのステータス情報を「完了」と更新する（ｓ２０
９）。

【００３８】上記のように処方箋登録データベース２５
０に蓄積されていき、そのステータス情報が「完了」で
ある処方箋データのうち、調剤薬局システム３０からの
回答の内容「処方通り以外」であるものについては、処
方箋管理機関システム１０がこれを適宜なタイミングで
抽出する。抽出した処方箋データは、調合修正ファイル
２８０に格納すると共に、審査支払機関システム４０に
送信される（ｓ２１０）。

【００３９】他方、調剤薬局システム３０では、調剤を
行った後に調剤レセプトを作成する。そのため、当該調
剤薬局システム３０は、調剤レセプトの作成対象となる
前記調剤データについて、前記調剤データベース３００
において、前記患者の被保険者番号、記号番号、生年月
日、性別等をキーにして抽出処理を行う（ｓ３０６）。
抽出した調剤データは適宜な抽出テーブルに一時格納さ
れる。調剤薬局システム３０は、抽出したこの調剤デー
タに対して、医薬品点数データベース３６０を対照して
薬剤点数を計算する（ｓ３０７）。この計算結果は前記
の抽出テーブルに追加される。そして、例えば入力部３
４からの調剤料および加算料等の入力を受け付けて、前
記の抽出テーブルに追加する（ｓ３０８）。薬剤点数や
調剤料、加算料などが追加された抽出テーブルの内容は
調剤レセプトとなり、このレセプトデータは、レセプト
データベース３４０に格納される。また審査支払機関シ
ステム４０に送られる（ｓ３０９）。

【００４０】審査支払機関システム４０は、処方箋管理
機関システム１０から送られた調合修正ファイル２８０
と、調剤薬局システム３０から送られたレセプトデータ
とを受信する。前記調合修正ファイル２８０は、調合修
正受付ファイル２８０’に格納し（ｓ４０１）、レセプ
トデータはレセプトデータベース３４０’に格納する
（ｓ４０２）。審査支払機関システム４０では、処方箋
データ通りの調剤が行われた結果生成された通常のレセ
プトに関し、処方箋管理機関システム１０から得た処方
箋データ等との照合を行って支払い審査を行う。

【００４１】一方で、処方箋データが飲合わせや限界量
等の制限事項に抵触した内容であったために、当該処方
箋データの通りには調剤されなかったレセプトに関して
は特にチェックを行うこととしている。そこで、前記調
合修正ファイル２８０’とレセプトデータベース３４
０’とを突合させ、調剤薬局において調合を修正した分
のレセプトデータを抽出する（ｓ４０３）。抽出したレ
セプトデータはレセプト抽出テーブル３９０（図２３参
照）に格納する。ここに格納したレセプトデータについ
ては、飲合わせ不可データベース２００’および限界量
データベース２１０’について突合させ、再度の飲合わ
せ及び限界量のチェックを実行する。このチェックで飲
合わせ又は限界量に関して問題があると判定されたレセ
プトデータに関しては、レセプト調査要データベース４
００（図２４参照）に格納し、以後の仔細なチェック対
象とされる。

【００４２】この審査支払機関システム４０での一連の
処理を詳述したのが図５である。図５においては、前記
調合修正受付ファイル２８０’と、レセプトデータベー
ス３４０’との突合処理をステップｓ４０としている。
その突合処理の結果（ｓ４１）、突合しなかった場合
（つまり、調合修正がなされたレセプトデータが存在し
なかった場合）、レセプトデータベース３４０’中のす
べてのレセプトデータベースは、処方箋データ通りに調
剤された結果において生成されたものであると言える。

【００４３】他方、突合した場合、調合修正がなされた
レセプトデータが存在する。ここで突合したレセプトデ
ータに対しては、レセプト抽出テーブル３９０に格納し
（ｓ４２）、上記したように飲合わせ不可データベース
２００’および限界量データベース２１０’における突
合処理を行う（ｓ４３）。ここにおける処理で突合した
場合、突合したレセプトデータをレセプト調査要データ
ベース４００格納する（ｓ４５）。突合しない場合には
処理は終了する。図５の処理を行うことにより、簡単な
審査は機械的に行い、仔細なチェックを人が行うこと
で、審査員の業務負荷を軽減し、かつ精度の高い審査を
することが期待できる。

【００４４】本発明によれば、従来の手法における種々
の問題点を克服し優れた効果を奏することとなる。例え
ば、調剤薬局は“紙”の処方箋を参照しながら調剤レセ
プトを作成することなく、処方箋データと医薬品点数デ
ータベースとから調剤薬局システムがレセプトの自動生
成を行うことも可能となる。もちろん、医薬品名、数
量、患者の保険番号などといった処方箋記載内容を人手
であらためて転記する必要もないから、業務効率と正確
性に優れることとなる。処方箋データやレセプトデータ
はもちろん電子データであり、処方箋管理機関、医療機
関システム、調剤薬局、審査支払機関の各者間で、迅速
確実かつ簡便な取扱いが可能となる。

【００４５】しかも、患者一人の１日分の薬剤費が２０
５円以下の調剤レセプトに関しても、処方箋データとの
照合処理を容易に可能とし、確実な支払い審査体制を構
築・運営することにも繋がるのである。この場合、処方
箋に基づかない架空レセプトが発行されたとしても、そ
れを容易にチェックして排除することが可能である。

【００４６】また、同じ疾病について複数の医療機関を
受診するいわゆる“はしご受診”を行う患者に対し、各
医療機関から発行された複数の処方箋に基づき多量の医
薬品を重複調剤してしまう惧れを確実に排除できる。し
たがって、医薬品毎に定められた投与限界量や、医薬品
同士の飲合わせ禁忌等について、調剤前にチェックする
ことも可能となる。ひいては、過剰な医薬品を服用して
も、その服用量に応じた治療効果が得られる訳ではない
旨を患者に理解させる機会を適切に提供することもで
き、医療費高騰を抑制する一助ともなる。

【００４７】本発明に係る実施の形態としては、前記目
的を達成すべく、次の通りとしてもよい。前記医療情報
管理方法において、サーバが、患者の属性情報とそれに
紐付けられた処方箋データとを対照することで、同一患
者が一定期間内に同内容の処方を受けたことを検知する
再受診検知ステップと、再受診が検知されたならば、該
当患者に関して一定期間内の再受診が検知された旨を、
関係する前記薬局端末または医療機関の端末に通知する
再受診通知ステップと、を備えることとする。

【００４８】また、前記医療情報管理方法において、サ
ーバが、前記処方箋データに基づき調剤薬局において実
際に調剤された調剤データを、薬局端末より受診する調
剤データ受付ステップと、受け付けた調剤データを、対
応する処方箋データに関連づけしてデータベースに登録
する調剤データ登録ステップと、を含むこととする。

【００４９】更に、前記医療情報管理方法において、サ
ーバが、データベースに登録した処方箋データ、修正処
方箋データ、及び調剤データの少なくともいずれかを、
審査支払機関の端末に送信する審査情報送信ステップを
含むこととする。

【００５０】また、前記医療情報管理方法において、前
記制限テーブルを、飲合わせ制限がある医薬品組合せを
定めた飲合わせテーブルと、医薬品毎の服用限界量を定
めた限界量テーブルとの少なくともいずれかから構成す
ることとする。

【００５１】更に、前記医療情報管理方法において、前
記データベースに登録した処方箋データに対し、その処
理状況に応じて更新するステータス情報を関係づけする
ステータス付加ステップと、処方箋検索リクエストを未
だ受けていない処方箋データのステータスを、「受付可
能」とするステップと、処方箋検索リクエストを受けた
際に、該当する処方箋データのステータスが「受付可
能」であって、前記処方箋データ抽出ステップを実行可
能かを判定するステップと、を含むこととする。

【００５２】また、前記医療情報管理方法を実現するシ
ステムであって、医療機関由来の処方箋データを受け付
ける処方箋データ受付手段と、前記処方箋を発行された
患者の属性情報に紐付けて、前記処方箋データをデータ
ベースに登録する処方箋データ登録手段と、調剤薬局の
薬局端末より、患者の属性情報を絡めた処方箋検索リク
エストを受付けるリクエスト受付手段と、受け付けた前
記属性情報をデータベースにおいて照合し、該当患者の
処方箋データを全て抽出する処方箋データ抽出手段と、
抽出した処方箋データが含む処方医薬品およびその処方
分量に関する情報を、医薬品処方に関する医療上の制限
事項を定めた制限テーブルに対照し、前記制限事項に抵
触するか判定する処方判定手段と、前記判定の結果と、
当該判定結果に応じて前記制限事項を遵守すべく生成し
た処方内容の修正指示と、前記判定結果に応じて前記制
限事項を遵守すべく処方内容を修正した処方箋データと
の少なくともいずれかを、薬局端末に送る処方箋送付フ
ァイル送信手段と、を備えたことを特徴とする医療情報
管理システムをなすこととする。

【００５３】更に、医療機関が発行し調剤薬局が調剤に
用いる処方箋の管理をサーバ上で実現するプログラムで
あって、医療機関由来の処方箋データを受け付ける処方
箋データ受付ステップと、前記処方箋を発行された患者
の属性情報に紐付けて、前記処方箋データをデータベー
スに登録する処方箋データ登録ステップと、調剤薬局の
薬局端末より、患者の属性情報を絡めた処方箋検索リク
エストを受付けるリクエスト受付ステップと、受け付け
た前記属性情報をデータベースにおいて照合し、該当患
者の処方箋データを全て抽出する処方箋データ抽出ステ
ップと、抽出した処方箋データが含む処方医薬品および
その処方分量に関する情報を、医薬品処方に関する医療
上の制限事項を定めた制限テーブルに対照し、前記制限
事項に抵触するか判定する処方判定ステップと、前記判
定の結果と、当該判定結果に応じて前記制限事項を遵守
すべく生成した処方内容の修正指示と、前記判定結果に
応じて前記制限事項を遵守すべく処方内容を修正した処
方箋データとの少なくともいずれかを、薬局端末に送る
処方箋送付ファイル送信ステップと、を備えたことを特
徴とする医療情報管理プログラムをなすこととする。

【００５４】また、前記医療情報管理プログラムを記録
したコンピュータ読み取り可能な記録媒体をなすことと
する。

【００５５】更に、前記薬局端末であって、患者の属性
情報を絡めた処方箋検索リクエストをサーバに送信する
リクエスト送信手段と、サーバが行った処方判定ステッ
プにおける判定結果に応じて前記制限事項を遵守すべく
生成した処方内容の修正指示および処方箋データ、また
は前記判定結果に応じて前記制限事項を遵守すべく処方
内容を修正した修正処方箋データを、前記サーバより受
診する処方箋送付ファイル受信手段と、受信した処方箋
送付ファイルに基づいて実際になされた調剤データを、
サーバに送信する調剤データ送信手段と、を備えること
を特徴とする薬局端末をなすこととする。

【００５６】また、前記薬局端末であって、医薬品毎の
単位数量と請求点数との関係を定めた点数テーブルに、
前記調剤データを対照し、調剤データ毎の請求点数を計
算する点数計算手段と、算出された請求点数のデータを
調剤データに付加して調剤レセプトデータを生成するレ
セプト生成手段と、前記調剤レセプトデータと、これに
対応する処方箋データ或いは修正処方箋データとのう
ち、少なくとも調剤レセプトデータを、前記審査支払機
関の端末に送信するレセプト送信手段と、を備えること
を特徴とする薬局端末をなすこととする。

【００５７】更に、前記審査支払機関の端末であって、
処方箋データ、修正処方箋データ、及び調剤データの少
なくともいずれかを、サーバより受信する審査情報受信
手段と、調剤レセプトデータと、これに対応する処方箋
データ或いは修正処方箋データとのうち、少なくとも調
剤レセプトデータを、前記薬局端末より受信するレセプ
ト受信手段と、受信した処方箋データまたは修正処方箋
データと、調剤レセプトデータとを突合処理してその整
合性を判定するレセプトチェック手段と、レセプトチェ
ックの結果を出力装置に出力するチェック結果出力手段
と、備えることを特徴とする審査支払端末をなすことと
する。

【００５８】また、前記審査支払機関の端末であって、
前記レセプトデータが含む調剤医薬品およびその調剤分
量に関する情報を、医薬品調剤に関する医療上の制限事
項を定めた制限テーブルに対照し、前記制限事項に抵触
するか判定する調剤判定手段と、調剤判定の結果を出力
装置に出力する判定結果出力手段と、を備えることを特
徴とする審査支払端末をなすこととする。

【００５９】

【発明の効果】本発明によれば、処方箋管理および適正
な調剤処理および支払審査を簡便確実かつ迅速に実行可
能であり、かつ処理効率に優れた医療情報管理方法およ
びシステムを提供可能となる。

【図面の簡単な説明】

【図１】本実施形態における処方箋管理機関システムを
含むネットワーク概要図である。

【図２】本実施形態における医療情報管理方法を含む全
体手順を示す流れ図である。

【図３】本実施形態における飲合わせおよび限界量のチ
ェック過程を示す流れ図である。

【図４】本実施形態における調剤過程を示す流れ図であ
る。

【図５】本実施形態における調剤レセプトの審査過程を
示す流れ図である。

【図６】本実施形態における処方箋作成ＤＢ及び処方箋
受付ＤＢのデータ構成を示す図である。

【図７】本実施形態における医療機関ＤＢのデータ構成
を示す図である。

【図８】本実施形態における調剤薬局ＤＢのデータ構成
を示す図である。

【図９】本実施形態における処方箋管理ＤＢのデータ構
成を示す図である。

【図１０】本実施形態における処方箋抽出テーブルを示
す図である。

【図１１】本実施形態における集計テーブル（処方箋管
理機関）を示す図である。

【図１２】本実施形態における飲合わせＤＢのデータ構
成を示す図である。

【図１３】本実施形態における限界量ＤＢのデータ構成
を示す図である。

【図１４】本実施形態における処方箋送付ファイルおよ
び処方箋受付ファイルのデータ構成を示す図である。

【図１５】本実施形態における処方箋登録ＤＢのデータ
構成を示す図である。

【図１６】本実施形態における調合修正ファイルおよび
調合修正受付ファイルのデータ構成を示す図である。

【図１７】本実施形態における調剤ＤＢのデータ構成を
示す図である。

【図１８】本実施形態におけるメッセージＤＢのデータ
構成を示す図である。

【図１９】本実施形態におけるレセプトＤＢのデータ構
成を示す図である。

【図２０】本実施形態における医薬品点数ＤＢのデータ
構成を示す図である。

【図２１】本実施形態における集計テーブル（薬局）を
示す図である。

【図２２】本実施形態におけるレセプト抽出テーブルを
示す図である。

【図２３】本実施形態におけるレセプト調査要ＤＢのデ
ータ構成を示す図である。

【符号の説明】

ｓ２０１ 処方箋データ受付ステップ ｓ２０２ 処方箋データ登録ステップ ｓ２０３ リクエスト受付ステップ ｓ２０４ 処方箋データ抽出ステップ ｓ２０５ 処方判定ステップ ｓ２０７ 処方箋送付ファイル送信ステップ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 岩田 淳也 神奈川県川崎市幸区鹿島田890番地 株式 会社日立製作所ビジネスソリューション事 業部内 (72)発明者 藤原 茂之 東京都江東区新砂一丁目６番27号 株式会 社日立製作所公共システム事業部内 (72)発明者 前田 みゆき 神奈川県川崎市幸区鹿島田890番地 株式 会社日立製作所ビジネスソリューション事 業部内

Claims (13)

【特許請求の範囲】
1. 【請求項１】 医療機関が発行し調剤薬局が調剤に用い
   る処方箋をサーバで管理する方法であって、 サーバが、医療機関由来の処方箋データを受け付ける処
   方箋データ受付ステップと、 前記処方箋を発行された患者の属性情報に紐付けて、前
   記処方箋データをデータベースに登録する処方箋データ
   登録ステップと、 調剤薬局の薬局端末より、患者の属性情報を絡めた処方
   箋検索リクエストを受付けるリクエスト受付ステップ
   と、 受け付けた前記属性情報をデータベースにおいて照合
   し、該当患者の処方箋データを全て抽出する処方箋デー
   タ抽出ステップと、 抽出した処方箋データが含む処方医薬品およびその処方
   分量に関する情報を、医薬品処方に関する医療上の制限
   事項を定めた制限テーブルに対照し、前記制限事項に抵
   触するか判定する処方判定ステップと、 前記判定の結果に応じて前記制限事項を遵守すべく生成
   した処方内容の修正指示および処方箋データ、または前
   記判定結果に応じて前記制限事項を遵守すべく処方内容
   を修正した修正処方箋データを、薬局端末に送る処方箋
   送付ファイル送信ステップと、 を備えたことを特徴とする医療情報管理方法。
2. 【請求項２】 サーバが、患者の属性情報とそれに紐付
   けられた処方箋データとを対照することで、同一患者が
   一定期間内に同内容の処方を受けたことを検知する再受
   診検知ステップと、 再受診が検知されたならば、該当患者に関して一定期間
   内の再受診が検知された旨を、関係する前記薬局端末ま
   たは医療機関の端末に通知する再受診通知ステップと、 を備えることを特徴とする請求項１に記載の医療情報管
   理方法。
3. 【請求項３】 サーバが、前記処方箋データに基づき調
   剤薬局において実際に調剤された調剤データを、薬局端
   末より受診する調剤データ受付ステップと、 受け付けた調剤データを、対応する処方箋データに関連
   づけしてデータベースに登録する調剤データ登録ステッ
   プと、 を含むことを特徴とする請求項１に記載の医療情報管理
   方法。
4. 【請求項４】 サーバが、データベースに登録した処方
   箋データ、修正処方箋データ、及び調剤データの少なく
   ともいずれかを、審査支払機関の端末に送信する審査情
   報送信ステップを含むことを特徴とする請求項３に記載
   の医療情報管理方法。
5. 【請求項５】 前記制限テーブルを、飲合わせ制限があ
   る医薬品組合せを定めた飲合わせテーブルと、医薬品毎
   の服用限界量を定めた限界量テーブルとの少なくともい
   ずれかから構成することを特徴とする請求項１に記載の
   医療情報管理方法。
6. 【請求項６】 データベースに登録した処方箋データに
   対し、その処理状況に応じて更新するステータス情報を
   関係づけするステータス付加ステップと、 処方箋検索リクエストを未だ受けていない処方箋データ
   のステータスを、「受付可能」とするステップと、 処方箋検索リクエストを受けた際に、該当する処方箋デ
   ータのステータスが「受付可能」であって、前記処方箋
   データ抽出ステップを実行可能かを判定するステップ
   と、 を含むことを特徴とする請求項１に記載の医療情報管理
   方法。
7. 【請求項７】 請求項１〜６のいずれかの医療情報管理
   方法を実現するシステムであって、 医療機関由来の処方箋データを受け付ける処方箋データ
   受付手段と、 前記処方箋を発行された患者の属性情報に紐付けて、前
   記処方箋データをデータベースに登録する処方箋データ
   登録手段と、 調剤薬局の薬局端末より、患者の属性情報を絡めた処方
   箋検索リクエストを受付けるリクエスト受付手段と、 受け付けた前記属性情報をデータベースにおいて照合
   し、該当患者の処方箋データを全て抽出する処方箋デー
   タ抽出手段と、 抽出した処方箋データが含む処方医薬品およびその処方
   分量に関する情報を、医薬品処方に関する医療上の制限
   事項を定めた制限テーブルに対照し、前記制限事項に抵
   触するか判定する処方判定手段と、 前記判定の結果と、当該判定結果に応じて前記制限事項
   を遵守すべく生成した処方内容の修正指示と、前記判定
   結果に応じて前記制限事項を遵守すべく処方内容を修正
   した処方箋データとの少なくともいずれかを、薬局端末
   に送る処方箋送付ファイル送信手段と、 を備えたことを特徴とする医療情報管理システム。
8. 【請求項８】 医療機関が発行し調剤薬局が調剤に用い
   る処方箋の管理をサーバ上で実現するプログラムであっ
   て、 医療機関由来の処方箋データを受け付ける処方箋データ
   受付ステップと、 前記処方箋を発行された患者の属性情報に紐付けて、前
   記処方箋データをデータベースに登録する処方箋データ
   登録ステップと、 調剤薬局の薬局端末より、患者の属性情報を絡めた処方
   箋検索リクエストを受付けるリクエスト受付ステップ
   と、 受け付けた前記属性情報をデータベースにおいて照合
   し、該当患者の処方箋データを全て抽出する処方箋デー
   タ抽出ステップと、 抽出した処方箋データが含む処方医薬品およびその処方
   分量に関する情報を、医薬品処方に関する医療上の制限
   事項を定めた制限テーブルに対照し、前記制限事項に抵
   触するか判定する処方判定ステップと、 前記判定の結果と、当該判定結果に応じて前記制限事項
   を遵守すべく生成した処方内容の修正指示と、前記判定
   結果に応じて前記制限事項を遵守すべく処方内容を修正
   した処方箋データとの少なくともいずれかを、薬局端末
   に送る処方箋送付ファイル送信ステップと、 を備えたことを特徴とする医療情報管理プログラム。
9. 【請求項９】 請求項８に記載の医療情報管理プログラ
   ムを記録したコンピュータ読み取り可能な記録媒体。
10. 【請求項１０】 前記薬局端末であって、 患者の属性情報を絡めた処方箋検索リクエストをサーバ
    に送信するリクエスト送信手段と、 サーバが行った処方判定ステップにおける判定結果に応
    じて前記制限事項を遵守すべく生成した処方内容の修正
    指示および処方箋データ、または前記判定結果に応じて
    前記制限事項を遵守すべく処方内容を修正した修正処方
    箋データを、前記サーバより受診する処方箋送付ファイ
    ル受信手段と、 受信した処方箋送付ファイルに基づいて実際になされた
    調剤データを、サーバに送信する調剤データ送信手段
    と、 を備えることを特徴とする薬局端末。
11. 【請求項１１】 請求項１０に記載の薬局端末であっ
    て、 医薬品毎の単位数量と請求点数との関係を定めた点数テ
    ーブルに、前記調剤データを対照し、調剤データ毎の請
    求点数を計算する点数計算手段と、 算出された請求点数のデータを調剤データに付加して調
    剤レセプトデータを生成するレセプト生成手段と、 前記調剤レセプトデータと、これに対応する処方箋デー
    タ或いは修正処方箋データとのうち、少なくとも調剤レ
    セプトデータを、前記審査支払機関の端末に送信するレ
    セプト送信手段と、 を備えることを特徴とする薬局端末。
12. 【請求項１２】 前記審査支払機関の端末であって、 処方箋データ、修正処方箋データ、及び調剤データの少
    なくともいずれかを、サーバより受信する審査情報受信
    手段と、 調剤レセプトデータと、これに対応する処方箋データ或
    いは修正処方箋データとのうち、少なくとも調剤レセプ
    トデータを、前記薬局端末より受信するレセプト受信手
    段と、 受信した処方箋データまたは修正処方箋データと、調剤
    レセプトデータとを突合処理してその整合性を判定する
    レセプトチェック手段と、 レセプトチェックの結果を出力装置に出力するチェック
    結果出力手段と、を備えることを特徴とする審査支払端
    末。
13. 【請求項１３】 請求項１２に記載の審査支払機関の端
    末であって、 前記レセプトデータが含む調剤医薬品およびその調剤分
    量に関する情報を、医薬品調剤に関する医療上の制限事
    項を定めた制限テーブルに対照し、前記制限事項に抵触
    するか判定する調剤判定手段と、 調剤判定の結果を出力装置に出力する判定結果出力手段
    と、 を備えることを特徴とする審査支払端末。