JP2013257771A - 処方薬データ管理装置、処方薬データ管理システム、処方薬データ管理方法及び処方薬データ管理プログラム - Google Patents

Abstract

【課題】お薬手帳の代替として薬局及び病院等で薬の処方履歴を入力でき、且つ、緊急時においてはＩＤ及びパスワードを用いることなくこの処方履歴にアクセスすることを可能とする。
【解決手段】端末とネットワークを介して接続される処方薬データ管理装置が、或るユーザに対して処方及び／又は調剤が行われた場合に該処方及び／又は調剤の内容を前記端末から受信してデータベースに登録する。前記端末から前記データベースの参照依頼があった場合に前記端末から受信した所定の情報を用いて認証を行う。前記認証が成功した場合に前記登録手段によりデータベースに登録した登録内容を前記端末に提示する。前記認証では、平常時には第１の所定の情報を用いて前記認証を行うが、緊急時には前記第１の所定の情報と一部又は全部が異なる情報である第２の所定の情報を用いて前記認証を行う。
【選択図】図１

Description

本発明は、患者に対して処方された薬を管理する為の、処方薬データ管理装置、処方薬データ管理システム、処方薬データ管理方法及び処方薬データ管理プログラムに関する。

日本国においては、調剤薬局（以下、「薬局」と呼ぶ。）や医療機関（以下、「病院」と呼ぶ。）において薬が処方及び調剤された場合に、この処方及び調剤された医薬品（以下、「薬」と呼ぶ。）の履歴をまとめる為の手帳がユーザに手渡されている。この手帳は一般的に「おくすり手帳」、「お薬手帳」及び「薬識手帳」等と称されている。

そして、患者は一冊のお薬手帳を携帯し、調剤時にお薬手帳を提出することにより、今回調剤された薬の内容を追記してもらう。

このお薬手帳は、患者一人につき一冊にまとめることにより、今までの履歴を漏れなく記入することができる。もっとも、お薬手帳は、各患者自身が保管を行っており、薬局や病院に持って行くことを忘れることがある。また、急患の為お薬手帳を所持していない場合もある。このような場合は新たなお薬手帳を発行することとなり処方の回数が増えるにつれ、手帳の数が増えてしまっていた。後日これらの手帳の内容を一冊に統合することにより記入漏れを防止することは可能であるが、実際に統合するには人手がかかるため行われず、記入漏れがそのままとなることが多かった。また、新たなお薬手帳の発行すら行われず、手帳が無い為にそこへの記入が漏れる、という事態も生じてしまっていた。

更に、お薬手帳を紛失してしまうことも考えられ、このような場合にはお薬手帳に記載されていた今までの履歴が参照できない状態となってしまっていた。

このような不都合を防止する為、調剤された薬の履歴を電子化するという技術が提案されている。例えば、特許文献１には、処方された医薬品の履歴を記憶した履歴データベースをユーザ毎に設けることが記載されている。

そして、特許文献１に記載の技術では、このデータベースを参照することにより、渡航先となる海外の国においても、過去に処方された医薬品と同等の医薬品を見つけることができる。

特開２０１２−３８１４７号公報

上述した特許文献１では、履歴データベースをユーザ毎に割り当てられたＩＤとパスワードで管理している。そして、履歴データベースの内容を参照する為にはＩＤとパスワードを入力し、認証を成功させる必要があった。この場合にユーザ自身がパスワードに加えてＩＤも記憶しておくことは現実的に困難である。そのため、ユーザはＩＤを記載又は電子的に記憶したカードを用いてＩＤを入力し、その後、パスワードを入力することとなる。

しかしながら、災害などの緊急時にはこのカードを携帯していないことが考えられる。このような場合であっても、特許文献１等では一律にＩＤとパスワードの入力が必要となる。そのため、病院側としては履歴データベースにアクセスすることができない。従って、緊急時にはユーザにいままで処方されていた薬が何かがわからず正しい薬の処方が出来ないという課題があった。

更に、特許文献１に記載されている履歴データベースは、その作成手法及び入力方法に関して詳細に言及されていないという課題があった。

そこで、本発明は、お薬手帳の代替として薬局及び病院等で薬の処方履歴を入力でき、且つ、緊急時においてはＩＤ及びパスワードを用いることなくこの処方履歴にアクセスすることが可能な、処方薬データ管理装置、処方薬データ管理システム、処方薬データ管理方法及び処方薬データ管理プログラムを提供することを目的とする。

本発明の第１の観点によれば、端末とネットワークを介して接続される処方薬データ管理装置であって、或るユーザに対して処方及び／又は調剤が行われた場合に該処方及び／又は調剤の内容を前記端末から受信してデータベースに登録する登録手段と、前記端末から前記データベースの参照依頼があった場合に前記端末から受信した所定の情報を用いて認証を行う認証手段と、前記認証が成功した場合に前記登録手段によりデータベースに登録した登録内容を前記端末に提示する提示手段と、を備え、前記認証手段は平常時には第１の所定の情報を用いて前記認証を行うが、緊急時には前記第１の所定の情報と一部又は全部が異なる情報である第２の所定の情報を用いて前記認証を行うことを特徴とする処方薬データ管理装置が提供される。

本発明の第２の観点によれば、管理装置と、端末とが接続されている処方薬データ管理システムであって、前記端末は、或るユーザに対して処方及び／又は調剤が行われた場合に、前記管理装置に対して前記処方及び／又は調剤の内容を送信する手段と、前記管理装置に対して、データベースの参照依頼と共に認証用の所定の情報を送信する手段と、前記認証が成功した場合に前記管理装置から提示された内容をユーザに対して提示する手段と、を備え、前記管理装置は上記本発明の第１の観点により提供される処方薬データ管理装置である、ことを特徴とする処方薬データ管理システムが提供される。

本発明の第３の観点によれば、端末とネットワークを介して接続されるコンピュータを処方薬データ管理装置として機能させる処方薬データ管理プログラムであって、前記コンピュータを、或るユーザに対して処方及び／又は調剤が行われた場合に該処方及び／又は調剤の内容を前記端末から受信してデータベースに登録する登録手段と、前記端末から前記データベースの参照依頼があった場合に前記端末から受信した所定の情報を用いて認証を行う認証手段と、前記認証が成功した場合に前記登録手段によりデータベースに登録した登録内容を前記端末に提示する提示手段と、を備え、前記認証手段は平常時には第１の所定の情報を用いて前記認証を行うが、緊急時には前記第１の所定の情報と一部又は全部が異なる情報である第２の所定の情報を用いて前記認証を行う処方薬データ管理装置として機能させることを特徴とする処方薬データ管理プログラムが提供される。

本発明の第４の観点によれば、管理装置と、端末とが接続されているシステムが行う処方薬データ管理方法であって、前記端末が、或るユーザに対して処方及び／又は調剤が行われた場合に、前記管理装置に対して前記処方及び／又は調剤の内容を送信するステップと、前記管理装置が、或るユーザに対して処方及び／又は調剤が行われた場合に該処方及び／又は調剤の内容を前記端末から受信してデータベースに登録する登録ステップと、前記端末が、前記管理装置に対して、データベースの参照依頼と共に認証用の所定の情報を送信するステップと、前記管理装置が、前記端末から前記データベースの参照依頼があった場合に前記端末から受信した所定の情報を用いて認証を行う認証ステップと、前記管理装置が、前記認証が成功した場合に前記登録ステップによりデータベースに登録した登録内容を前記端末に提示する提示ステップと、前記端末が、前記認証が成功した場合に前記管理装置から提示された内容をユーザに対して提示するステップと、を有し、前記認証ステップでは平常時には第１の所定の情報を用いて前記認証を行うが、緊急時には前記第１の所定の情報と一部又は全部が異なる情報である第２の所定の情報を用いて前記認証を行うことを特徴とする処方薬データ管理装置が提供される。

本発明によれば、お薬手帳の代替として薬局及び病院等で薬の処方履歴を入力でき、且つ、緊急時においてはＩＤ及びパスワードを用いることなくこの処方履歴にアクセスすることが可能となる。

本発明の実施形態の基本的構成を表すブロック図である。 本発明の実施形態におけるカード及びユーザＩＤについて表す図である。 本発明の実施形態におけるログイン時の表示例を表す図である。 本発明の実施形態の基本的動作を表す図である。

次に、本発明の実施形態について図面を用いて詳細に説明する。

図１を参照すると、本実施形態である処方薬データ管理システム１０００が表されている。処方薬データ管理システム１０００は、メインサーバ装置１０１、冗長サーバ装置１０２、携帯端末１０３、第三者端末１０４、薬局端末１０５、病院端末１０６及び個人端末１０７を含んでいる。これら全ての構成機器は全てネットワーク１２０を介して接続されている。この接続は有線接続であっても良いし、一部又は全部が無線接続であっても良い。更に、公衆網を利用しても良いが専用網を利用しても良い。加えて、これらの組合せであっても良い。例えば、携帯端末１０３とメインサーバ装置１０１とが携帯電話網を介して無線で接続される一方で、病院端末１０６とメインサーバ装置１０１とは専用線で有線接続されているような接続であっても良い。

なお、以下の説明において携帯端末１０３、第三者端末１０４、薬局端末１０５、病院端末１０６及び個人端末１０７を「端末群」と呼ぶ。

本実施形態では、「お薬手帳」で管理していた病院・薬局で処方してもらった薬一覧を、データベース化し、一元管理する。これにより、お薬手帳の発行が不要となり、記入漏れが起きなくなる。又、通常はカードなどの媒体で、「処方された薬のデータ・個人情報・個人情報を開示する為のキーワード群が保管されているサーバ」にアクセスを行うが、災害などの緊急時は、別の認証方法に切り替える。これにより災害時であってカードなどの媒体を所持していない場合にも、病院や薬局で処方されていた薬の内容が正しく確認できるものである。

ここで、メインサーバ装置１０１は、上記の「処方された薬のデータ・個人情報・個人情報を開示する為のキーワード群が保管されているサーバ」に相当する。

メインサーバ装置１０１は、「処方された薬のデータ」としてユーザに処方された医薬品名と、その処方量及び処方された日時等が記録されたデータベースを含む。このデータベースには、更に処方を行った医師の名前や、調剤を行った薬局の名前等が含まれていても良い。

これらの情報はユーザ毎に管理されている。また、ユーザにはそれぞれユーザを識別する為のユーザＩＤが割り当てられており、更に、ユーザ毎にパスワードが設定されている。ユーザＩＤやパスワードとしては、任意の文字列が割り当てられる。これはどのような文字列であっても良いが、他者より類推されにくいものが好ましい。例えば、英字や数字等をランダムに組合せた又は所定のアルゴリズムで生成した、所定の文字数（例えば８文字）以上の文字列を用いることが好ましい。

続いて、ユーザＩＤの取り扱いに関して説明する。ユーザＩＤには上述したように、「英字や数字等をランダムに組合せた又は所定のアルゴリズムで生成した、所定の文字数以上の文字列」が用いられる。もっともこのような文字列をユーザが常に記憶しておくことは現実的には困難である。そこで、本実施形態では図２に表されるようなカード１３０を利用する。カード１３０にはユーザＩＤ１３１が含まれている。

カード１３０は任意の方法で実現することが可能である。例えば、紙や、プラスチック等の合成樹脂により実現し、そこに文字列を記載しても良い。この場合、ユーザはこの文字列を目視し、端末群に含まれる何れかの端末に対して入力する。また、例えば磁気カードでカード１３０を実現しても良い。この場合ユーザＩＤ１３１はカード１３０に電子的に記録される。そして、端末群に含まれる何れかの端末が、このカード１３０からユーザＩＤ１３１を読み取るようにしても良い。この場合、ユーザＩＤ１３１は必ずしも文字列で実現する必要は無く、端末及びサーバ装置が認識可能な所定のデータで実現すればよい。その他、ユーザＩＤ１３１を一次元バーコードや二次元バーコードにより実現し、端末群に含まれる何れかの端末がこれらのバーコードを読み取るようにしても良い。

またメインサーバ装置１０１のデータベースには「個人情報」として、例えばユーザの、氏名、生年月日、住所、血液型及び電話番号（自宅固定電話機もしくは携帯電話機）が含まれる。これらの情報は一般的なお薬手帳にも記入される内容である。加えて、それ以外にも「個人情報」として、例えば、アレルギーの有無、副作用歴の有無、過去の病歴及びかかりつけ医・薬局の名称等が含まれていても良い。

更に、このデータベースには「個人情報を開示する為のキーワード群」が含まれる。このキーワードは任意に定めても良いが、より簡便な方法としては、上記「個人情報」の一部又は全部をそのまま「個人情報を開示する為のキーワード群」としても利用することが考えられる。

本実施形態では、平常時はカード１３０から読み取ったユーザＩＤ１３１と、パスワードとにより認証を行い、この認証に成功した端末には「処方された薬のデータ」や「個人情報」に対してのアクセスを許可する。一方で、災害など緊急時にはカード１３０がなくても、氏名をキーに、Ｎ個（Ｎは２以上の整数）設定した項目の中のＭ個（Ｍは１以上の整数、且つ、Ｎ≧Ｍの条件を満たす数である）以上の条件と合致した場合、「処方された薬のデータ」や「個人情報」に対してのアクセスを許可する。

本実施形態では、このように状況を「平常時」と「緊急時」とに区別する。ここで、緊急時とは例えば、地震、竜巻及び水害といった自然災害が発生している事態が考えられる。また、これらの自然災害に起因する火災等も考えられる。さらには、人為的な理由に伴う、戦争やテロ行為の発生時を緊急事態と判断しても良い。また、大規模な飛行機事故や列車事故等が発生した場合に緊急事態と判断しても良い。そして、「緊急時」でない場合には「平常時」と判断できる。

これら例示した緊急事態は或る一定の地域に存在するユーザ全員に影響を及ぼすものである。そのため本実施形態を利用するユーザ全員や、これら、或る一定の地域に存在する端末群からアクセスを試みたユーザ全員に対して一律に「緊急事態」として取り扱うことが考えられる。

このような構成をとる場合に、災害等が発生している緊急時であるのか、それとも問題が生じていない平常時であるのかは、メインサーバ装置１０１及び冗長サーバ装置１０２を管理する管理者が適宜設定することが考えられる。また、メインサーバ装置１０１及び冗長サーバ装置１０２が例えば気象庁から送信される緊急地震速報を受信した場合、受信してから一定時間は緊急時であるとメインサーバ装置１０１及び冗長サーバ装置１０２が自動的に判断し、緊急時であると設定するようにしても良い。何れの場合であっても、メインサーバ装置１０１及び冗長サーバ装置１０２が、端末群からの認証時にメインサーバ装置１０１及び冗長サーバ装置１０２自身の設定を確認することにより「平常時」であるのか「緊急時」であるのかを判定することが可能となる。

一方で、このように複数のユーザに関して一律に判断するのではなく、ユーザ毎に個別具体的に判断するようにしても良い。

例えば、上述したような災害等が発生していなくとも、或るユーザにとっては「緊急時」と判断すべき場合が考えられる。具体的には、事故等に合い手術や投薬が必要な場合や、突発的に病状が発生して手術や投薬が必要な場合等が考えられる。また、上記した以外にもユーザが持病を有しており定期的な投薬が必要であるにも関わらず、常備薬を紛失してしまった場合等が考えられる。

このような場合には、個人端末１０７や病院端末１０６及び救急車に積載されている端末といった一部の端末からメインサーバ装置１０１及び冗長サーバ装置１０２に対して「緊急時」である旨を設定できるようにしても良い。

また、メインサーバ装置１０１及び冗長サーバ装置１０２に対して予め設定するのではなく、認証時にメインサーバ装置１０１及び冗長サーバ装置１０２に対して「緊急時」である旨を送信するようにしても良い。これらの場合には、メインサーバ装置１０１及び冗長サーバ装置１０２が、認証を求めている端末が「緊急時」である旨を設定できる端末であるか否かを判断し、設定できる端末である旨を確認できた場合に「緊急時」として取り扱うようにすれば良い。

なお、端末群に含まれる全ての端末から「緊急時」である旨を設定できる権限を与えてしまうと、全ての認証に対して「緊急時」であると取り扱い可能となってしまう。

すると、「平常時」であるか「緊急時」であるかを区別する意味が無くなってしまうので、上述のように個人端末１０７や病院端末１０６といった一部の端末からのみ「緊急時」である旨を設定できるようにすることが好ましい。

図３には、緊急時に端末上に表示される入力画面の一例が表されている。

今回は個人情報を開示する為のキーワード群として、個人情報を利用することを想定している。具体的には、氏名をログインＩＤとしてまず採用している。そのため、氏名を入力してログイン認証を開始する。そして、キーワード（今回は５つとする）の項目を選択し、選択した項目にキーワードを入力する。今回は、５つ設定した項目の中の３つ以上のキーワードが正解していれば認証成功とする。

このように、本実施形態では緊急時の認証用の情報として、氏名や生年月日といったお薬手帳に一般的に入力される情報を流用する。これにより、認証用の情報を新たに作成することは無いという効果を奏する。また、これらの情報は、単なるランダムな英数字ではないので、ユーザが忘れることはないという利点もある。なお、過去の病歴やかかりつけの薬局名等を認証用の情報としても良い。これらの情報は忘れやすい情報ではあるものの、他者が知ることが困難な情報でもあるため、セキュリティ性向上の観点からこれらの情報を認証用に用いても良い。

冗長サーバ装置１０２は、メインサーバ装置１０１の予備となるサーバ装置であり、メインサーバ装置１０１と同様のデータベースを含む。すなわち、本実施形態はメインサーバ装置１０１と、冗長サーバ装置１０２との冗長構成となっている。メインサーバ装置１０１に故障が無い場合は、本実施形態に含まれる端末群はメインサーバ装置１０１に含まれるデータベースを利用する。また、メインサーバ装置１０１に含まれるデータベース内の情報が更新された場合には、冗長サーバ装置１０２に含まれるデータベース内の情報もメインサーバ装置１０１に含まれるデータベースと同じ内容に更新される。

もっとも、何らかの障害が発生し、メインサーバ装置１０１にアクセスできなくなった場合には、本実施形態に含まれる端末群は冗長サーバ装置１０２に含まれるデータベースを利用するようにする。

なお、メインサーバ装置１０１と冗長サーバ装置１０２は、災害時を想定し、例えば東京・大阪など距離が離れた場所に設置する。このようにすることにより、或る災害により一方のサーバ装置が故障しても他方のサーバ装置を利用することが可能となる。

なお、メインサーバ装置１０１と冗長サーバ装置１０２は、各々が単一のサーバ装置で実現されても良いし、複数のサーバ装置が協働することによりそれぞれが実現されても良い。更に冗長サーバ装置１０２が１つではなく複数設けられていても良い。

携帯端末１０３、第三者端末１０４、薬局端末１０５、病院端末１０６及び個人端末１０７は、それぞれがメインサーバ装置１０１と通信を行う端末である。

携帯端末１０３は、認証を試みるユーザ自身の端末であり例えば携帯電話機により実現される。

また、第三者端末は認証を試みるユーザや病院以外が所有している端末である。また、薬局端末１０５は薬局に設置されている端末であり、病院端末１０６は病院に設置されている端末であり、個人端末１０７は認証を試みるユーザ自身が所有している端末である。第三者端末１０４、薬局端末１０５、病院端末１０６及び個人端末１０７並びにメインサーバ装置１０１及び冗長サーバ装置１０２のそれぞれは、専用の装置又は本実施形態特有のソフトウェアをインストールした汎用のパーソナルコンピュータ等により実現される。

続いて、図４のフローチャートを参照して本実施形態の動作について説明する。

本実施形態の端末群に含まれる何れかの端末から、メインサーバ装置１０１に対してアクセスを試みる（ステップＳ１１）。

アクセスを試みる旨を通知されたメインサーバ装置１０１は、まず、現在が緊急時か否かの確認を行う（ステップＳ１２）。上述したように、メインサーバ装置１０１は現在が「緊急時」である場合は、メインサーバ装置１０１の管理者等によりその旨が予め設定されている。そのため、メインサーバ装置１０１は自身の設定を確認することにより、現在が「緊急時」であるか否かを確認できる。また、一部の端末に対して「緊急時」である旨を設定できる権限を与える場合は、アクセスを試みている端末が、「緊急時」である旨を設定できる権限を与えられている端末か否かを確認し、権限を与えられている端末であり且つこの端末が緊急時である旨を通知している場合には現在が「緊急時」であると確認できる。

ここで緊急時でない場合は（ステップＳ１２においてＮｏ）、通常の認証方式でログインを行う。このとき、ログインＩＤとしてカード１３０に含まれているユーザＩＤ１３１を、パスワードとして所定文字数以上の文字列を用いる。

一方、緊急時である場合は（ステップＳ１２においてＹｅｓ）、緊急時認証方式でログインを行う（ステップＳ１３）。このとき、ログインＩＤとして氏名を用い、又パスワードとして「個人情報を開示できるキーワード群」５項目のうち、３項目が照合できればログイン可能とする。

ステップＳ１３及びステップＳ１４の何れの場合であっても、認証に成功した場合は（ステップＳ１５においてＹｅｓ）、処方されている薬のデータや、個人情報が表示される（ステップＳ１６）。また、表示と共に又は表示に変えて紙などに印刷されるようにしても良い。また、処方されている薬のデータのみを表示等させ、個人情報については表示等させないようにしても良い。

一方、ステップＳ１３及びステップＳ１４の何れの場合であっても、認証に失敗した場合は（ステップＳ１５においてＮｏ）、アクセス失敗となり処方されている薬のデータや個人情報は表示等されず、アクセスに失敗した旨がアクセスを試みた端末に返される（ステップＳ１７）。

以上説明した本実施形態では、「お薬手帳」で管理していた処方薬一覧が、メインサーバ装置１０１にアクセスすることで、「お薬手帳」がなくても処方された薬の内容が確認でき、災害などの緊急時、混乱時にカードＩＤが把握できなくとも、氏名でログイン後、Ｎ個のキーワードの中からＭ個のキーワードが一致した場合、正しい薬の内容が確認・閲覧できるという効果を奏する。

なお、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。以下、幾つかの変形例について説明する。

［変形例１］
上述したように、災害等の緊急時には（ステップＳ１２においてＹｅｓ）、氏名及びキーワードを用いて認証を行っていた（ステップＳ１３）。

しかし、これはあくまで緊急時という非常事態に対応する為のものであり、個人情報保護の観点からはいたずらに適用範囲を広めるべきではない。

そこで本変形例では、災害等の緊急時に、一部の端末（以下、「第１の端末」と呼ぶ。）からは氏名及びキーワードを用いて認証を行わせるが、それ以外の端末（以下、「第２の端末」と呼ぶ。）からは災害等の緊急時には（ステップＳ１２においてＹｅｓ）であっても、ステップＳ１４に進み、ユーザＩＤ１３１及びパスワードを用いた認証を行わせる。

どの端末を一部の端末とするかは任意に決定することができる。例えば、災害地域及びその近傍に設置されている端末を第１の端末とし、災害地から離れた地域に設置されている端末は第２の端末とすることが考えられる。

また、病院端末１０６や薬局端末１０５のみを第１の端末とし、一般ユーザが利用する携帯端末１０３や第三者端末１０４は第２の端末とすることが考えられる。

更に、ユーザ自身が所持する個人端末１０７のみを第１の端末とし、それ以外の端末は第２の端末とすることが考えられる。

加えて、これらの基準を組み合わせることも考えられる。

このように、ステップＳ１３に進む端末を制限することにより、ユーザの氏名や血液型等を把握している第三者からの不正アクセスを防止するとともに、第一の端末により、ユーザＩＤ１３１が無くとも必要な情報を取得することが可能となる。

［変形例２］
一般的な状況として、まず病院にいる医師の診察を受けると共に医師より処方箋を出され、その後ユーザがその処方箋を薬局に持って行き、薬剤師より調剤をしてもらうとことが考えられる。

そこで、本変形例では、医師が病院端末１０６で処方内容をメインサーバ装置１０１に登録すると、この処方内容がデータベースに登録されるとともに、患者が希望する薬局にＥメール等の手段により、或るユーザに関して処方がなされた旨等を薬局端末１０５に通知するようにする。

通知を受けた薬局では、この通知に基づいて調剤を行っておくことにより、その後薬局を訪れたユーザに対して速やかに薬を渡すことができる。

なお、この変形例を取る場合ＥメールにユーザＩＤ１３１及びパスワードを記載又は添付してもよいが、情報漏洩の可能性が有る。その為、例えば病院端末１０６で処方内容をメインサーバ装置１０１に登録すると共に使い捨てのパスワードであるワンタイムパスワードを病院端末１０６とメインサーバ装置１０１間で生成するようにしても良い。そして、Ｅメールにはこのワンタイムパスワードのみを記載又は添付する。そして、薬局端末１０５からはこのワンタイムパスワードを用いて一度だけ処方内容を確認できるようにしても良い。これにより情報漏洩のリスクを低減できる。なおこの際にはユーザＩＤ１３１の入力を不要とし、ワンタイムパスワードのみで認証を行えるようにしても良い。

また、今回の処方内容自体を直接Ｅメールに記載又は添付しても良い。こうするだけであっても、メインサーバ装置１０１への登録操作のみで、薬局への連絡をも済ませることができるので、ユーザ及び医師の利便性向上に繋がる。

［変形例３］
本変形例では、メインサーバ装置１０１に含まれるデータベースについて参照できる範囲を限定する。或る患者が今までどのような処方をされてきたかということは、個人情報に相当するため、必要以上に開示しないことが望ましい。すなわち、場合によっては開示する範囲を限定することが望ましい。

例えば、医師は処方を行うにあたり、患者の処方履歴を全て参照して検討することが好ましい。よって、医師には患者の処方履歴を全て開示する必要がある。もっとも、各薬局が今までの処方履歴全てを把握する必要がないとも考えられる。また、処方箋は調剤以外の目的にも利用されることが有る。例えば、コンタクトレンズを購入する際には医師が処方した処方箋の提示が求められる。よって、コンタクトレンズの販売業者の端末から処方履歴を参照し、これを処方箋の提示として扱うことができれば利便性が向上する。しかし、コンタクトレンズの販売業者は、レンズの度数や、目のカーブ、乱視の度合い等の情報さえ入手できれば良く、これ以外の他の処方に関する履歴にアクセスさせる必要はないと考えられる。
このように、場合によっては開示する範囲を限定することが望ましい。そこで、本変形例では上述していたパスワード（本変形における説明の便宜上、以下「メインパスワード」と呼ぶ。）とは別に、更にサブパスワードを生成する。

例えば、眼科の医師がコンタクトレンズの購入に必要な或る処方を行い、この処方内容を病院端末１０６を用いてメインサーバ装置１０１に登録する。この場合にメインサーバ装置１０１はこの或る処方についてのサブパスワードを生成し、病院端末１０６や個人端末１０７にサブパスワードを送信する。

ユーザは、その後コンタクトレンズの販売業者のもとを訪れてこのサブパスワードを販売業者に教える。販売業者はユーザＩＤ１３１及びサブパスワードを利用して認証を行い、コンタクトレンズの購入に必要な或る処方にアクセスすることができる。もっとも、サブパスワードによる認証ではこの或る処方に関してのみしかアクセスできず、他の処方に関してはアクセスできないようにしておく。これにより、開示させる範囲を限定することができる。なお、メインパスワードを用いて認証すればデータベースの内容を全て参照できる点は上述の実施形態と同様であるので、ユーザや医師はメインパスワードを利用するようにすれば良い。

なお、サブパスワードを１つの処方と紐付けるのではなく、期間や回数といった条件毎にサブパスワードを生成しても良い。例えば、アクセス可能範囲を「所定の月数の範囲で遡って参照可」、「今回だけ参照可」等の条件で限定し、この限定されたアクセス可能範囲とサブパスワードを生成するようにしても良い。

［変形例４］
本変形では、処方履歴内に含まれる各履歴を参照できる範囲を端末毎に設定する。例えば、個人端末１０７を所有しているユーザを第１のユーザとする。

この場合、第１のユーザのユーザＩＤ及びパスワードを利用した場合、病院端末１０６や個人端末１０７からは全ての履歴を参照でき、第三者端末１０４からは一部の履歴（例えば、直近１ヶ月の履歴）のみを参照できるようにする。

こうすることにより第１のユーザがカード１３０を落としてしまった場合であって、更にパスワードが漏洩してしまった場合であっても第三者は直近一ヶ月の履歴が参照できるに止まる。よって、情報流出を最大限に食い止められつつも、普段は病院端末１０６や個人端末１０７から全ての履歴を参照できるので利便性を低下させないことが可能となる。

なお、上記の処方薬データ管理システムに含まれる各機器は、ハードウェア、ソフトウェア又はこれらの組合わせにより実現することができる。また、上記の処方薬データ管理システムに含まれる各機器により行なわれる処方薬データ方法も、ハードウェア、ソフトウェア又はこれらの組合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。

プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ(Read Only Memory)、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ(Programmable ROM)、ＥＰＲＯＭ(Erasable PROM)、フラッシュＲＯＭ、ＲＡＭ(random access memory)）を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１） 端末とネットワークを介して接続される処方薬データ管理装置であって、
或るユーザに対して処方及び／又は調剤が行われた場合に該処方及び／又は調剤の内容を前記端末から受信してデータベースに登録する登録手段と、
前記端末から前記データベースの参照依頼があった場合に前記端末から受信した所定の情報を用いて認証を行う認証手段と、
前記認証が成功した場合に前記登録手段によりデータベースに登録した登録内容を前記端末に提示する提示手段と、
を備え、
前記認証手段は平常時には第１の所定の情報を用いて前記認証を行うが、緊急時には前記第１の所定の情報と一部又は全部が異なる情報である第２の所定の情報を用いて前記認証を行うことを特徴とする処方薬データ管理装置。

（付記２） 付記１に記載の処方薬データ管理装置であって、
前記第１の所定の情報とは、前記端末を利用するユーザを識別する為の識別符号とパスワードの組であり、前記第１の所定の情報を用いた認証では前記識別符号とパスワードの組が正当であれば認証成功と判断し、
前記第２の所定の情報とは少なくとも前記ユーザの個人情報を含むＮ（Ｎは２以上の整数）個に項目分けされた情報であり、前記第２の所定の情報を用いた認証では前記Ｎ個の項目の中のＭ個（Ｍは１以上の整数、且つ、Ｎ≧Ｍの条件を満たす数）が正当であれば認証成功と判断する、
ことを特徴とする処方薬データ管理装置。

（付記３） 付記１又は２に記載の処方薬データ管理装置であって、
前記端末を第１の端末と第２の端末とに区別し、前記緊急時に前記第１の端末については前記第２の所定の情報を用いて前記認証を行うが、前記第２の端末については前記緊急時であっても前記第１の所定の情報を用いて前記認証を行うことを特徴とする処方薬データ管理装置。

（付記４） 付記１乃至３の何れか１に記載の処方薬データ管理装置であって、
或る端末から或るユーザに対して或る処方及び／又は調剤の内容を受信した場合に、前記或るユーザに関する処方及び／又は調剤の内容を参照する為の情報を生成し、該生成した情報を前記或る端末以外の端末に送信することを特徴とする処方薬データ管理装置。

（付記５） 付記４に記載の処方薬データ管理装置であって、
前記生成した情報を用いて参照可能なのは前記或るユーザに関する処方及び／又は調剤の内容の前記或る処方及び／又は調剤の内容だけであることを特徴とする処方薬データ管理装置。

（付記６） 付記１乃至５の何れか１に記載の処方薬データ管理装置であって、
前記端末が複数存在する端末の中のどの端末であるかを判断し、前記認証が成功した場合に前記データベースを提示する範囲が端末により異なることを特徴とする処方薬データ管理装置。

（付記７） 付記１乃至６の何れか１に記載の処方薬データ管理装置であって、
前記端末の一部に緊急時である旨を設定する権限を付与し、前記参照依頼をしている依頼元の端末が前記権限を付与されている端末であり且つ該端末が緊急時である旨を通知している場合には、緊急時であると判断して前記認証を行うことを特徴とする処方薬データ管理装置。

（付記８） 管理装置と、端末とが接続されている処方薬データ管理システムであって、
前記端末は、
或るユーザに対して処方及び／又は調剤が行われた場合に、前記管理装置に対して前記処方及び／又は調剤の内容を送信する手段と、
前記管理装置に対して、データベースの参照依頼と共に認証用の所定の情報を送信する手段と、
前記認証が成功した場合に前記管理装置から提示された内容をユーザに対して提示する手段と、を備え、
前記管理装置は付記１乃至７の何れか１に記載の処方薬データ管理装置である、
ことを特徴とする処方薬データ管理システム。

（付記９） 端末とネットワークを介して接続されるコンピュータを処方薬データ管理装置として機能させる処方薬データ管理プログラムであって、
前記コンピュータを、
或るユーザに対して処方及び／又は調剤が行われた場合に該処方及び／又は調剤の内容を前記端末から受信してデータベースに登録する登録手段と、
前記端末から前記データベースの参照依頼があった場合に前記端末から受信した所定の情報を用いて認証を行う認証手段と、
前記認証が成功した場合に前記登録手段によりデータベースに登録した登録内容を前記端末に提示する提示手段と、
を備え、
前記認証手段は平常時には第１の所定の情報を用いて前記認証を行うが、緊急時には前記第１の所定の情報と一部又は全部が異なる情報である第２の所定の情報を用いて前記認証を行う処方薬データ管理装置として機能させることを特徴とする処方薬データ管理プログラム。

（付記１０） 管理装置と、端末とが接続されているシステムが行う処方薬データ管理方法であって、
前記端末が、或るユーザに対して処方及び／又は調剤が行われた場合に、前記管理装置に対して前記処方及び／又は調剤の内容を送信するステップと、
前記管理装置が、或るユーザに対して処方及び／又は調剤が行われた場合に該処方及び／又は調剤の内容を前記端末から受信してデータベースに登録する登録ステップと、
前記端末が、前記管理装置に対して、データベースの参照依頼と共に認証用の所定の情報を送信するステップと、
前記管理装置が、前記端末から前記データベースの参照依頼があった場合に前記端末から受信した所定の情報を用いて認証を行う認証ステップと、
前記管理装置が、前記認証が成功した場合に前記登録ステップによりデータベースに登録した登録内容を前記端末に提示する提示ステップと、
前記端末が、前記認証が成功した場合に前記管理装置から提示された内容をユーザに対して提示するステップと、
を有し、
前記認証ステップでは平常時には第１の所定の情報を用いて前記認証を行うが、緊急時には前記第１の所定の情報と一部又は全部が異なる情報である第２の所定の情報を用いて前記認証を行うことを特徴とする処方薬データ管理方法。

本発明は、処方薬の管理を行うシステムに好適ではあるが、管理対象は処方箋に限定されず、種々の履歴の管理に適用可能である。

１０１ メインサーバ装置
１０２ 冗長サーバ装置
１０３ 携帯端末
１０４ 第三者端末
１０５ 薬局端末
１０６ 病院端末
１０７ 個人端末
１２０ ネットワーク
１３０ カード
１３１ ユーザＩＤ
１０００ 処方薬データ管理システム

Claims (10)

1. 端末とネットワークを介して接続される処方薬データ管理装置であって、
   或るユーザに対して処方及び／又は調剤が行われた場合に該処方及び／又は調剤の内容を前記端末から受信してデータベースに登録する登録手段と、
   前記端末から前記データベースの参照依頼があった場合に前記端末から受信した所定の情報を用いて認証を行う認証手段と、
   前記認証が成功した場合に前記登録手段によりデータベースに登録した登録内容を前記端末に提示する提示手段と、
   を備え、
   前記認証手段は平常時には第１の所定の情報を用いて前記認証を行うが、緊急時には前記第１の所定の情報と一部又は全部が異なる情報である第２の所定の情報を用いて前記認証を行うことを特徴とする処方薬データ管理装置。
2. 請求項１に記載の処方薬データ管理装置であって、
   前記第１の所定の情報とは、前記端末を利用するユーザを識別する為の識別符号とパスワードの組であり、前記第１の所定の情報を用いた認証では前記識別符号とパスワードの組が正当であれば認証成功と判断し、
   前記第２の所定の情報とは少なくとも前記ユーザの個人情報を含むＮ（Ｎは２以上の整数）個に項目分けされた情報であり、前記第２の所定の情報を用いた認証では前記Ｎ個の項目の中のＭ個（Ｍは１以上の整数、且つ、Ｎ≧Ｍの条件を満たす数）が正当であれば認証成功と判断する、
   ことを特徴とする処方薬データ管理装置。
3. 請求項１又は２に記載の処方薬データ管理装置であって、
   前記端末を第１の端末と第２の端末とに区別し、前記緊急時に前記第１の端末については前記第２の所定の情報を用いて前記認証を行うが、前記第２の端末については前記緊急時であっても前記第１の所定の情報を用いて前記認証を行うことを特徴とする処方薬データ管理装置。
4. 請求項１乃至３の何れか１項に記載の処方薬データ管理装置であって、
   或る端末から或るユーザに対して或る処方及び／又は調剤の内容を受信した場合に、前記或るユーザに関する処方及び／又は調剤の内容を参照する為の情報を生成し、該生成した情報を前記或る端末以外の端末に送信することを特徴とする処方薬データ管理装置。
5. 請求項４に記載の処方薬データ管理装置であって、
   前記生成した情報を用いて参照可能なのは前記或るユーザに関する処方及び／又は調剤の内容全てのうち、前記或る処方及び／又は調剤の内容だけであることを特徴とする処方薬データ管理装置。
6. 請求項１乃至５の何れか１項に記載の処方薬データ管理装置であって、
   前記端末が複数存在する端末の中のどの端末であるかを判断し、前記認証が成功した場合に前記データベースを提示する範囲が端末により異なることを特徴とする処方薬データ管理装置。
7. 請求項１乃至６の何れか１項に記載の処方薬データ管理装置であって、
   前記端末の一部に緊急時である旨を設定する権限を付与し、前記参照依頼をしている依頼元の端末が前記権限を付与されている端末であり且つ該端末が緊急時である旨を通知している場合には、緊急時であると判断して前記認証を行うことを特徴とする処方薬データ管理装置。
8. 管理装置と、端末とが接続されている処方薬データ管理システムであって、
   前記端末は、
   或るユーザに対して処方及び／又は調剤が行われた場合に、前記管理装置に対して前記処方及び／又は調剤の内容を送信する手段と、
   前記管理装置に対して、データベースの参照依頼と共に認証用の所定の情報を送信する手段と、
   前記認証が成功した場合に前記管理装置から提示された内容をユーザに対して提示する手段と、を備え、
   前記管理装置は請求項１乃至７の何れか１項に記載の処方薬データ管理装置である、
   ことを特徴とする処方薬データ管理システム。
9. 端末とネットワークを介して接続されるコンピュータを処方薬データ管理装置として機能させる処方薬データ管理プログラムであって、
   前記コンピュータを、
   或るユーザに対して処方及び／又は調剤が行われた場合に該処方及び／又は調剤の内容を前記端末から受信してデータベースに登録する登録手段と、
   前記端末から前記データベースの参照依頼があった場合に前記端末から受信した所定の情報を用いて認証を行う認証手段と、
   前記認証が成功した場合に前記登録手段によりデータベースに登録した登録内容を前記端末に提示する提示手段と、
   を備え、
   前記認証手段は平常時には第１の所定の情報を用いて前記認証を行うが、緊急時には前記第１の所定の情報と一部又は全部が異なる情報である第２の所定の情報を用いて前記認証を行う処方薬データ管理装置として機能させることを特徴とする処方薬データ管理プログラム。
10. 管理装置と、端末とが接続されているシステムが行う処方薬データ管理方法であって、
    前記端末が、或るユーザに対して処方及び／又は調剤が行われた場合に、前記管理装置に対して前記処方及び／又は調剤の内容を送信するステップと、
    前記管理装置が、或るユーザに対して処方及び／又は調剤が行われた場合に該処方及び／又は調剤の内容を前記端末から受信してデータベースに登録する登録ステップと、
    前記端末が、前記管理装置に対して、データベースの参照依頼と共に認証用の所定の情報を送信するステップと、
    前記管理装置が、前記端末から前記データベースの参照依頼があった場合に前記端末から受信した所定の情報を用いて認証を行う認証ステップと、
    前記管理装置が、前記認証が成功した場合に前記登録ステップによりデータベースに登録した登録内容を前記端末に提示する提示ステップと、
    前記端末が、前記認証が成功した場合に前記管理装置から提示された内容をユーザに対して提示するステップと、
    を有し、
    前記認証ステップでは平常時には第１の所定の情報を用いて前記認証を行うが、緊急時には前記第１の所定の情報と一部又は全部が異なる情報である第２の所定の情報を用いて前記認証を行うことを特徴とする処方薬データ管理方法。

Images