以下、本発明の一実施形態に係る薬剤受発注管理システム1について、図面を参照して説明する。本実施形態に係る薬剤受発注管理システム1は、例えば、患者の病気や検査目的に合わせて、各患者向けに特徴付けられた薬剤の受発注を管理し、いわゆるオーダーメード医療の実現に寄与する。特に本実施形態では、個々の患者向けのRI(Radio Isotope)を用いた放射性医薬品の受発注管理を行うシステムについて説明する。
図1は、本実施形態に係る薬剤受発注管理システム1の構成図である。
本システム1は、同図に示すように、発注サーバ100と、受注サーバ200と、生産管理サーバ300とを有する。発注サーバ100と受注サーバ200とがネットワーク9を介して接続されている。発注サーバ100は、例えば医療機関などの施設に設置される発注側システムである。受注サーバ200及び生産管理サーバ300は、例えば医薬品メーカなどに設置される受注側システムである。
医療機関では、医師らが個々の患者に対して治療計画を策定し、必要な薬剤を発注する。つまり、治療計画に基づいて、個々の患者向けに処方された薬剤が医薬品メーカに対して発注される。本システムによれば、医療機関では、後述するように、個々の発注を特定するための施設ごとの発注番号が患者IDと対応付けられる。そして、医薬品メーカから納入される薬剤には、この施設ごとの発注番号が付されている。これにより、医療機関では患者とその患者向け薬剤との関係性が明確な状態で患者へ投与され得る。
発注サーバ100、受注サーバ200及び生産管理サーバ300は、いずれも、例えばプロセッサ、主記憶装置及び外部記憶装置などを有する汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ100、受注サーバ200、生産管理サーバ300の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
発注サーバ100には、入力装置101及び出力装置103が接続されている。入力装置101は、例えば、キーボード、マウス、タッチパネル及びバーコードリーダ等の入力装置でよい。出力装置103は、ディスプレイなどの表示装置、及びプリンタなどの印刷装置でよい。
発注サーバ100は、発注処理部111と、照合処理部113と、発注データベース120と、患者データベース130とを有する。
図2は、発注データベース120のデータ構造の一例を示す。本実施形態では、医療機関等の施設として、A大学(施設ID:8876)及びB市立病院(施設ID:1468)が薬剤を発注する例で説明する。そこで、図2AがA大学の発注データベース120、図2BがB市立病院の発注データベース120である。
発注データベース120は、発注する薬剤に関する薬剤データと、患者と、発注を識別する情報とを対応付けて記憶する。発注データベース120は、例えば、データ項目として発注日時1201と、施設発注番号1202と、患者名1203と、患者ID1205と、性別1207と、薬剤種別1209と、検定時刻1211と、注文量1213とを有する。
発注日時1201は、医薬品メーカへ薬剤の発注した日時で、例えば、発注処理部111が発注リクエストを送信した日時である。
施設発注番号1202は、発注する施設で各発注に対して付与された識別情報である。本実施形態では、施設の識別情報である施設IDと発注日毎にユニークな連番で構成されてもよい。従って、発注データベース120において、発注日時1201及び施設発注番号1202が主キーとなる。
なお、一つの医療機関に対して複数の異なる施設IDが割り当てられることがある。例えば、配送先の住所が同一であっても、医療機関内で診療科が異なる場合などは、それぞれの診療科に異なる施設IDを割り当ててもよい。
患者ID1205は、医療機関内で各患者に付与された識別情報である。患者ID1205で患者データベース130に登録されている患者の個人情報と紐付けができる。
薬剤種別1209は、患者に投与する予定の製品(薬剤)の種別を示す。本実施形態では、放射性薬剤の種別を示す。
検定時刻1211は、放射性薬剤を用いた検査を行う時刻である。検定時刻1211に検査日を含めてもよい。検査日は検査が行われる日であり、発注日と同じ日またはそれ以降の日である。医薬品メーカは、検定時刻1211を基準とした製品を製造する。
注文量1213は、発注する薬剤の量であり、放射性薬剤の場合、検定時刻1211における放射能量でよい。本実施形態では、注文量1213の単位はメガベクレルでよい。
本実施形態では、放射性薬剤は液体で、容器(バイアル瓶)に密閉された製品として医療機関に納入される。そこで、医療機関は発注を一つの容器単位としてよいし、一つの発注に一つの施設発注番号が付されるようにしてもよい。つまり、一つの施設発注番号が一人の患者の患者IDに対応する。複数の薬剤をまとめて発注する際、上記の一容器に対する施設発注番号の他に、複数容器をまとめた発注番号があっても良い。
図1に戻ると、患者データベース130は、患者個人の属性情報、病気及び病状に関する情報などが記憶されている。例えば、患者データベース130には、患者の氏名、性別等の個人情報の他、患者毎に作成された治療計画のデータも保存されている。
発注データベース120及び患者データベース130に対するデータ入力は、例えば、ユーザが入力装置101を用いて行うことができる。発注データベース120及び患者データベース130に登録されているデータは、出力装置103に出力させることができる。
発注処理部111は、放射性薬剤の発注処理を行う。発注処理部111は、例えば、一つの発注について一つの発注リクエストを受注サーバ200へ送信するようにしてもよい。発注リクエストには、例えば、少なくとも、施設発注番号1202、薬剤種別1209、検定時刻1211及び注文量1213を含んでもよい。発注リクエストには、患者名等の患者個人の特定につながる情報は含まれない。発注リクエストを送信したときに、発注処理部111が発注データベース120において発注日時1201を設定するようにしてもよい。発注リクエストの送信は、例えば、入力装置101を介して入力されたユーザの指示をきっかけとしてもよいし、所定の時刻に行ってもよい。
発注処理部111が送信する発注リクエストには、発注サーバ100が設置されている医療機関等の施設の施設IDが含まれていてもよい。施設IDは、例えば、発注リクエストを含む送信メッセージのヘッダに含まれていてもよい。また、本システムにおいて固有の施設IDを付与する代わりに、施設のコンピュータ(例えば発注サーバ100)のMACアドレスを識別情報として用いてもよい。
なお、発注リクエストは電話またはファクシミリなどで行われてもよい。このとき、発注リクエストに必要な情報が出力装置103に出力され、ユーザがこの情報に基づいて発注リクエストをしてもよい。医薬品メーカでは、電話またはファクシミリなどで発注リクエストを受けたときは、ユーザが発注リクエストに係る情報を受注サーバ200に入力してもよい。
照合処理部113は、発注した薬剤を使用する前に行う処理であって、患者と納入された薬剤とを照合する。例えば、照合処理部113は、薬剤の容器または包装等に付与された薬剤の識別情報と患者の識別情報とを照合させて、両者の対応関係が正しいか否かを判定する。これにより、納入された薬剤が、それを投与する患者向けの薬剤であるか否かがわかるので、医師等がこの判定結果に基づいて、その薬剤を患者へ投与してよいか否かを判断できる。
例えば、納入された薬剤の投与単位の容器または包装には、発注した施設名とその施設における個別発注番号またはそれに相当する情報が記載されていてもよい。このとき、薬剤を受け入れた施設では、照合処理部113が、容器または包装の個別発注番号と施設に設置された発注データベース120の情報とを比較することで患者と薬剤の照合が可能となる。
受注サーバ200は、受注判定部201と、受注データベース220と、施設データベース230とを有する。
図3は、受注データベース220のデータ構造の一例を示す。
受注データベース220は、施設から受注した薬剤に関する情報を保存する。受注データベース220は、データ項目として、例えば、受注日時2201と、施設発注番号2202と、製品個別ID2203と、薬剤種別2205と、検定時刻2207と、注文量2209と、バルクID2211と、液量2213とを有する。
受注日時2201は、受注判定部201による受注判定により受注が確定した日時である。受注日時2201は受注判定部201により設定されてよい。
施設発注番号2202は、発注リクエストに含まれる施設発注番号である。
製品個別ID2203は、受注サーバ200及び生産管理サーバ300において受注した製品を一意に識別する識別子である。製品個別ID2203は施設発注番号2202と一対一に対応するものであり、受注判定部201によって付与されてよい。製品個別ID2203は、製品容器であるバイアル瓶(薬剤投与)単位にユニークでよい。受注データベース220においては、製品個別ID2203が主キーである。
受注サーバ200及び生産管理サーバ300での製品個別ID2203と発注サーバ100での施設発注番号1202とが一対一に対応するので、製品が医療機関に納入された後、納入された薬剤の製造工程における状況確認が必要になったときでも、製品個別ID2203によってすべての製造工程での状況を追跡可能である。
薬剤種別2205は、発注リクエストに含まれる薬剤種別である。
検定時刻2207は、発注リクエストに含まれる検定時刻である。
注文量2209は、発注リクエストに含まれる注文量である。
バルクID2211は、一日に一回または複数回製造されるバルクのうち、製品個別ID2203の製品が割り当てられたバルクの識別情報である。受注判定部201が製品個別ID2203を生産計画にあるいずれかのバルクに割り当てる。
液量2213は、バルクID2211のバルクから小分けにされる液量である。受注判定部201が受注判定処理において算出する。
受注判定部201は、発注サーバ100からの発注リクエストを受けて、その発注リクエストを受注するか否かを判定する。例えば、受注判定部201が、新たに発注リクエストを受けたときに、その発注に係る薬剤を確保できるか否かを判定する。医薬品メーカでは、予め定められた生産計画に基づいて薬剤の製造が行われる。そのため、既に多くを受注している場合は、新たな発注を受注できない場合もある。
また、受注判定部201が、バルク溶液の残量(小分けを行う際のロス分を差し引いた小分け可能な液量から既に他の製品へ割り当てた使用量を差し引いた液量)と、発注を受けた製品のために必要な液量とを比較して、受注が可能であるか否かを判定してもよい。発注を受けた製品のために必要な液量は、例えば、検定時刻、注文量に基づいて定まる。同一のバルクから注文量が同じで検定時刻の異なる複数の製品を製造する場合、液量を変えることで対応できる。つまり、検定時刻が遅いほど、放射能の減衰を考慮して液量を増やせばよい。また、同一のバルクから検定時刻が同じで注文量の異なる複数の製品を製造する場合も、液量を変えることで対応できる。つまり、注文量が多いほど液量を増やせばよい。一つのバルクから、検定時刻が同一で注文量の異なる複数の製品を製造することができるし、異なる検定時刻で注文量が同一の複数の製品を製造することもできるし、検定時刻及び注文量のいずれも異なる複数の製品を製造することもできる。
受注判定部201が発注を受けた製品のために必要な液量を確保できたときはその発注リクエストを受注し、確保できないときは受注しない。受注判定の結果は、発注リクエストを送信した発注サーバ100へ通知されてもよい。受注判定部201の具体的な処理は後述する。
複数施設の発注サーバ100からインターネット等のネットワーク9を通じて複数の発注リクエストを受けたとき、受注判定部201は、受け付けた時刻の早い順に受注判定を行ってもよい。あるいは、受注判定部201は、所定時間の間に受け付けた複数の発注リクエストをプールしておき、受付時刻以外の基準で受注判定の優先順位を定めてもよい。例えば、受注判定部201は、施設別の過去の受注実績が多い施設(または少ない施設)を優先させてもよいし、注文量の多い発注(または少ない発注)を優先させてもよい。
なお、発注サーバ100が発注リクエストとともに発注サーバ100の識別情報(MACアドレス等)を送信する場合は、受注サーバ200は、この識別情報から発注元の施設を特定してもよい。
図4は、施設データベース230のデータ構造の一例を示す。
施設データベース230は、データ項目として、例えば、施設ID2301と、施設名称2303と、配送先住所2305と、生産サイトAからの配送時間2307と、生産サイトBからの配送時間2309とを有する。
生産サイトAからの配送時間2307及び生産サイトBからの配送時間2309は、医薬品メーカの生産サイトA及びBのそれぞれから各施設へ製品を配送するときに要する配送時間である。
図1に戻ると、受注サーバ200には、入力装置21と出力装置23とが接続されている。入力装置21は、例えば、キーボード、マウス、タッチパネル及びバーコードリーダ等の入力装置でよい。出力装置23は、ディスプレイなどの表示装置、及びプリンタなどの印刷装置でよい。出力装置23は、例えば、薬剤の容器または包装に付すためのラベルや伝票を印刷してもよい。ラベルや伝票には、少なくとも施設発注番号が含まれる。
生産管理サーバ300は、生産計画管理部301と、配送計画管理部303と、生産計画データベース320と、配送計画データベース330とを有する。
生産計画管理部301は、予め生産計画を立てて、その内容を生産計画データベース320に保存する。本実施形態では、医薬品メーカは液体の放射性薬剤をバルク単位に製造する。バルク溶液から指定された液量がバイアル瓶に分注されて個別の薬剤となる。例えば、生産計画管理部301が立案する生産計画では、生産サイトごとに、一日に一回または複数回、所定量のバルク溶液が製造されるようにしてもよい。
生産計画管理部301は、生産計画を出力装置に出力してもよい。例えば、バルク溶液の残量から各施設における注文可能な検定時刻と容量についてリスト表示を行う。リスト中の検定時刻及び容量について出荷可能な本数を併せて表示してもよい。
受注判定部201において発注リクエストの受注が可能と判定されたとき、生産計画管理部301が受注に係る情報を生産計画データベース320に反映させてもよい。
図5は、生産計画データベース320のデータ構造の一例を示す。
生産計画データベース320は、データ項目として、例えば、バルクID3201と、生産サイト3203と、薬剤種別3204と、製造日時3205と、製造量3207と、使用量3209と、残量3211と、製品個別ID3213とを有する。
バルクID3201は、医薬品メーカで製造される複数のバルクを一意に識別する識別子である。バルクID3201が生産計画データベース320の主キーである。
生産サイト3203は、医療品メーカの生産サイトの識別情報である。医薬品メーカが有する生産サイトは複数あってもよい。本実施形態では、生産サイトA及び生産サイトBの二つのサイトがある場合を例に説明する。
薬剤種別3204は、製造される薬剤の種別である。
製造日時3205は、バルク溶液が製造される日時である。
製造量3207は、製造されるバルク溶液の量である。
使用量3209は、製造量3207のうち、既にいずれかの発注に係る製品に割り当てられた液量である。使用量3209は、製品個別ID3213の受注に対して割り当てられた液量の合計である。
残量3211は、製造量3207のうち、新たな発注へ割り当て可能な液量である。バルク溶液の一定のロスを考慮して定められてもよい。
製品個別ID3213は、バルクID3201に割り当てられた製品個別IDである。すなわち、バルクID3201に定めるバルクから分注して生産される薬剤の製品個別IDである。製品個別ID3213は、一つのバルクID3201に対して複数登録可能である。つまり、一つのバルクから複数の製品用に薬液が小分けにされる。このときの液量を調整することにより、同一注文量で検定時刻が異なる複数の製品を製造することができる。さらに、分注するときの液量を調整することにより、同一検定時刻で注文量が異なる複数の製品を製造することができる。
図1に戻ると、配送計画管理部303は、製造された個別の薬剤を発注元の施設へ配送する計画を立案する。配送計画管理部303によって立案された配送計画が配送計画データベース330に保存される。製造及び梱包が完了した製品は、配送計画データベース330の計画に従って出荷される。
配送計画には、例えば、配送先の名称、住所、担当窓口等の配送先情報、出荷予定時刻、届予定時刻が含まれてよい。配送計画では、検定時刻及び配送に要する時間が考慮されたうえで出荷時刻が定められていてもよい。配送計画は、個々の製品について出荷元である生産サイトから届け先までの配送手段及びその他の手続きに要する時間が考慮されていてもよい。配送手段は、例えば、トラック、航空機、鉄道、オートバイ及び徒歩等がある。複数の製品について配送先が一定範囲のエリアである場合や同一の航空機便を使用する場合にはそれらの製品をまとめて管理し、他の製品輸送スケジュールを含めた全体輸送スケジュールの余裕時間を考慮して製品の生産順番を決定してもよい。
図6は、本実施形態に係る薬剤受発注管理システム1を使った薬剤の受発注及び製造の業務フローを示す。
まず、医療機関において、発注サーバ100を用いて患者別の薬剤を発注する(S101)。このとき、発注リクエストが医薬品メーカの受注サーバ200へ送信される。
医薬品メーカでは、受注サーバ200がこの発注を受注可能であるか否かを判定し、受注可能である場合に受注が確定する(S201)。受注判定では、発注に係る薬剤の製造に必要な液量が算出される。
医療品メーカでは、受信した発注リクエストに含まれる施設発注番号に個別製品IDが関連づけられる。この関連づけは、人を介在せず自動的に行われることが望ましい。
次に、受注が確定すると、個別の製品の容器となるバイアル瓶に製品個別IDを付与して、バイアル瓶が準備される(S203)。さらに、バイアル瓶の準備後、またはこの準備と並行して、医薬品メーカの所定の生産サイトにおいて、受注した製品が割り当てられているバルク溶液が製造される(S205)。
バイアル瓶の準備が完了し、かつ、バルク溶液が製造されると、受注判定で算出された液量のバルク溶液がバイアル瓶へ分注される(S207)。
本実施形態に係る放射性薬剤は、個々の製品の特徴が異なるので、その個別の薬剤を特徴づける分注工程以降は、各製品を個別に管理する必要がある。そのために、本実施形態では、個々の製品に個別製品IDを付与している。医療品メーカでは、個別製品IDに薬剤の個別の特徴を含む製品情報、生産管理情報、受注情報、及び配送情報のすべてが紐づけられる。
ここで、放射性薬剤(製品)の個別の特徴とは、例えば液量、濃度、組成、薬物量、放射能量、検定時刻等がある。本実施形態では、濃度を一定としているので、薬物液体における液量と薬物量は等価である。
各製品を特徴づける生産工程以降では、特徴の異なる他の製品と混同しないように、個別の製品に識別情報を付して管理が行われる。例えば、本実施形態では、バイアル瓶を薬剤の一次容器とする剤形に液量の違いで個別製品を特徴付けるので、液剤の分注(小分け)行程以前に生産当日において一意となる製品個別製品ID(バイアル番号)をバイアル瓶に付す。製品個別製品IDをバイアル瓶に付す方法は、例えば、焼き付け、ラベル貼付、インクジェットマーカ、レーザーマーカ、文字やデータコードの印字、RFID((Radio Frequency Identifier))の利用等でよい。
液剤の分注工程では、個別製品IDをカメラ等で読み取り、受注データを参照して液量を特定し、バルク溶液からの小分けを行う。
分注後は、バイアル瓶をゴム栓及びアルミ栓で閉塞し(ゴム栓の打栓、アルミ栓の巻き締め)、異物検査工程を経てラベルを貼付する。
異物検査工程において不良品を判定されたバイアルは、カメラにてバイアル番号が確認され個別管理される生産管理情報にフィードバックされる。その後、再製造可能である場合は異なるバイアル番号が設定されたバイアル瓶を用いて製造が行なわれる。異物検査が合格となったバイアルは製品固有のバイアル番号が確認され対応する製品固有のIDがついたラベルが発行・貼付される。
分注後、ラベルが貼付されるまでの工程でバイアル瓶の混同が起きないように、ラベル貼付又はラベルの印字確認の信号を受けてから、次のバイアルに薬剤を分注するようにしてもよい。また、インデックスホイールを使用した生産装置の場合には、バイアル瓶が収まる個々のインデックス溝の位置情報に基づき個々のバイアル瓶をトレースしても良い。
なお、同一の特徴を有する製品が複数ある場合は、バッチ処理のごとく、それらをまとめて製造及びラベル貼付を行い、続いて他の特徴の製品を同様に生産するようにしてもよい。
なお、バイアル瓶に付される識別情報は、個別製品IDと一意に紐づけされた別の識別情報を用いてもよい。
図7は、ラベル7の一例を示す。
ラベル7は、施設の名称701及び施設内の通し番号702を有する。施設の名称701及び施設内の通し番号702が施設発注番号に相当する。ラベルは、さらに、個別製品ID703と、薬剤種別704と、注文量705と、検定時刻706とを有する。ラベル7は、さらに、これらの情報を有する2次元コード707を有する。
図6に戻ると、医薬品メーカでは、配送のための伝票出力及び製品の梱包が行われる(S209)。
一次容器であるバイアル瓶へのラベル貼付が終わると、バイアル瓶は二次(遮蔽)容器に梱包される。この際も梱包前にバイアル番号が確認されバイアル瓶と特定の二次容器の組み合わせに対し、二次容器の上面の位置に個別製品IDが印字された天面ラベルが貼付されるようにしてもよい。なお、この工程が完了しない間は前行程である異物検査工程の位置からバイアル瓶が生産ライン上で移動しないようになっていてもよい。これにより、バイアル瓶の混同が防止される。
放射性医薬品では、遮蔽材料を用いた井戸型容器と蓋によって構成された遮蔽容器(二次容器)に放射性薬液を封入したバイアル瓶等の一次容器が格納された状態で、病院等の使用者に届けられる。この一次容器と二次容器が不可分の関係をもって流通する場合は、一次容器でなく二次容器に個別製品IDを付してもよい。一次容器及び二次容器の双方に個別製品IDを付してもよい。
二次容器に個別製品IDを付す場合、一次容器の上面に個別製品IDを付してもよい。これは以下の理由による。すなわち、使用時、二次容器の遮蔽容器の蓋が外されると、遮蔽容器内の一次容器であるバイアル瓶上面が外部から見える構造になっている。そして、この状態のまま、医師等がバイアル瓶のアルミ栓を除去し、ゴム栓に注射針を刺して内部の薬剤を注射器に移して使用する。つまり、通常の使用時には、一次容器は二次容器から取り出されることはない。医師等の放射線被曝を抑制する観点からもこのような使用形態が好ましい。よって、一次容器の側面や底面に製品個別IDを付すよりも、側面に付すのがよい。
一次容器に製品個別IDを付す方法として、一次容器に直接付す方法と間接的に付す方法のいずれでもよい。直接付す方法としては、例えば、製品個別IDが一次容器に直接印字等されてもよい。間接的に付す方法としては、例えば、個別製品IDが印字されたラベル等が一次容器に貼付されてもよい。
個別製品IDは、情報を得る目的で生産、出荷、配送、施設での受け入れ等に使用される為、一次容器、二次容器、及び輸送箱等各包装材料のそれぞれの表面にあってもよい。RFIDを用いる場合、必ずしも目視可能な表面になくてもよい。
梱包された製品は、配送計画に従って発注元の医療機関等の施設へ出荷される(S211)。
製品は、段ボール箱等の輸送容器で梱包され出荷される。生産サイトから輸送業者等の輸送者への引き渡しを行い、トラック等の輸送手段にて製品が輸送されてもよい。生産サイトから輸送者への製品引き渡しについて、引き渡された製品と輸送者それぞれのIDの紐づけを行い個々の製品と輸送者を関係づける。輸送者の携帯端末にて引き渡しや配送・引き渡し完了の情報を発信しても良い。さらには、GPS機能を利用して輸送中の位置情報を把握しても良い。位置情報は時刻と共に情報を得ることで、速度を把握することができ、配送の遅延予測などに利用できる。
医療機関では、配送されてきた製品の照合処理を行って、製品(薬剤)と患者とを照合させ(S103)、患者へ薬剤を投与する(S105)。
薬剤の一次容器及び/または二次容器の表面には個別製品ID2203が付与される。一次または二次容器への製品個別IDの付与は、例えば、一次または二次容器の表面に直接印字してもよいし、製品個別IDが印字されたラベルを一次または二次容器に貼附してもよい。個別製品ID2203は、人が解読可能な数字、記号及び文字等で記載されていてもよい。さらには、個別製品ID2203は、機械読み取り可能なバーコードあるいは二次元コードなどの画像でもよいし、RFIDに保存されてもよい。
製品個別ID2203を付す場所は、使用時まで薬剤と不可分である容器でよい。これにより、医療機関等の施設における準備段階での薬剤の取り違いなどのミスを抑制できる。
図8は、受注判定部201の処理手順を示すフローチャートである。
受注判定部201は、発注処理部111から送信された発注リクエストを受け付ける(S701)。
受注判定部201は、発注リクエストに含まれる施設発注番号1202から施設IDを抽出し、この施設IDに基づいて施設データベース230から施設に関する情報、例えばサイトAからの配送時間2307及びサイトBからの配送時間2309を取得する(S703)。
受注判定部201は、生産計画データベース320を参照し、発注リクエストに含まれる検定時刻1211及び注文量1213とサイトAからの配送時間2307及びサイトBからの配送時間2309などから、この発注リクエストを受注することができるか否かを判定する(S707)。
例えば、受注判定部201は、まず、その発注に係る製品に割り当てることが可能なバルク候補を抽出してもよい。受注判定部201は、バルクの製造日時3205により定まる時刻が検定時刻1211以前で、かつ、放射能の減衰を考慮して検定時刻1211及び注文量1213から定まる必要な液量以上の残量が残っているバルクを候補としてもよい。そして、その候補の中で、バルク製造後に個別製品を製造(分注)するのに要する時間、梱包に要する時間及び配送時間等を考慮して、検定時刻1211よりも所定時間前に配送が完了するバルクの有無を判定してもよい。
ステップS707で必要な溶液が確保できないと判定されたときは、受注せずに処理を終了する(S707:No)。
ステップS707で必要な溶液が確保でき、受注可能と判定されたときは(S707:Yes)、受注判定部201が発注リクエストに対する製品個別IDを発行し(S709)、受注データベース220を更新する(S711)。
受注判定部201は、さらに、この受注内容を反映させるために生産計画データベース320を更新する(S713)。
これにより、必要な薬剤の液量が確保されることを確認した場合にのみ受注する。
図9は、照合処理部113の処理手順を示すフローチャートである。
照合処理部113は、納入された薬剤の一次容器または二次容器に付された施設発注番号1202を取得する(S801)。施設発注番号1202がバーコードまたは2次元コードで印刷されている場合及びRFIDに記憶されている場合は、所定のリーダで読み込んでもよい。その他の場合は、ユーザが手入力してもよい。
次に、照合処理部113は、薬剤を投与する患者の患者IDを取得する(S803)。患者IDの取得は、例えば、患者が身につけているラベルに印刷されたバーコードまたは2次元コードを所定のリーダで読み込んでもよいし、ユーザが手入力してもよい。
照合処理部113は、発注データベース120を参照して、上記の処理で取得した施設発注番号及び患者IDに基づいて患者と薬剤のマッチングを行う(S805)。つまり、照合処理部113は、上記の処理で取得した施設発注番号及び患者IDが発注データベース120で対応付けられているか否かを判定する。
患者と薬剤がマッチすれば(S805:Yes)、照合処理部113は、患者データベース130から患者情報を取得して、出力装置103に表示させる(S807)。
患者と薬剤が照合されなければ(S805:No)、出力装置103に所定のアラートを表示させる(S809)。
これにより、医師等は、この薬剤がこの患者向けのものであることを確認でき、医療過誤の抑止効果がある。
本実施形態によれば、特定の患者向け薬剤に施設で付与された識別情報と医薬品メーカで付与された識別情報を一対一に対応させることにより、発注から受注、生産、物流、納品、投与準備、投与前患者本人確認、投与及び薬剤使用管理まで、トレーサビリティが保証される。
本実施形態によれば、病院の施設での誤投与防止策として一般的に用いられている薬剤への患者個別コードの発行・貼付が不要となり、貼り間違いのリスクが無くなる。また、患者の個人情報を医薬品メーカに渡すことなく、病院等の施設において、納入された特定の患者個人向け医薬品であるか否かを投与前に判別することができる。さらに、病院等の施設では、薬剤の使用記録を容易に作成できる(RI管理台帳等)。さらに、患者個人固有のID(マイナンバー等)を用いれば複数施設での多重投与を防止できる。さらに、個々の患者に対応した投与量にて夫々薬剤を調整し個別管理を行うので、病院等の施設での患者個人に対応した操作を低減できる。
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
例えば、受注サーバ及び生産管理サーバは、それらを纏めて一つのコンピュータマシンで集中的に実現することもできるし、それぞれ一つのコンピュータマシンに分けて実現することもできるし、それぞれ複数のコンピュータマシンで分散的に実現することもできる。
また、上述の実施形態では医療機関と医薬品メーカとが直接に受発注及び納品を行う形態であるが、医療機関と医薬品メーカとの間に卸し業者及び小売業者等が介在していてもよい。