JP6994196B2 - Drug traceability system - Google Patents

Description

The present invention relates to a drug traceability system. More specifically, the present invention relates to a traceability system for individual management of drugs and visualization of distribution within the medical institution by performing individual authentication of the drug in the medical institution using a computing system.

Some medical drugs handled in medical institutions such as hospitals are required to be strictly controlled by the Narcotics and Psychotropics Control Law as medical narcotics (for example, fentanyl injection). Currently, medical drug management is recorded in paper-based books by the drug manager after the medical drug is delivered to the hospital by a wholesaler and then stored in a drug vault. For example, the fentanyl injection solution is enclosed in an ampoule, and a plurality of ampoules are further enclosed in one box as one product and stored in a drug safe. Each time the drug is shipped from the drug safe to the surgery department or returned from the surgery department, the drug manager records the fact in the books. In addition, when using medical narcotics, there are cases where all the drugs contained in one ampoule are used and cases where some of them are used. Strict control is also required for the remaining drugs when some are used, and appropriate disposal is obligatory.

JP-A-2002-269234 Japanese Patent Application Laid-Open No. 2008-206850 JP-A-2004-195033 JP 2015-149008

However, legal obligations for medical narcotics and manual operation of books place a heavy psychological and business burden on medical professionals including drug managers. On the other hand, there have been incidents related to the unauthorized use of medicines, such as the domestic distribution of expensive fake hepatitis C drugs and the extraction of medical drugs by medical professionals, and more precise, appropriate and convenient management of medicines. A method is required.

As a method for managing pharmaceutical products, for example, there is a management system using an IC tag or a QR code (registered trademark) as shown in Patent Document 1 and Patent Document 2, but the introduction cost of such a system is by no means low. It's not a thing. In addition, the IC tag and QR code are physically different from the drug itself, and cannot be said to be sufficient for individual drug management (for example, the information on the IC tag may be illegally rewritten or used. IC tags and QR codes can be replaced).

Further, as a method of managing the remaining amount of the drug, there is a method of writing the remaining amount in the IC tag as shown in Patent Document 3, but this method also allows the IC tag to be rewritten or replaced. Further, in the case of the remaining amount management by the IC tag, it is not possible to perform detailed traceability of the drug such as when, where, who used the drug and how much.

On the other hand, as shown in Patent Document 4, there is a method of determining a feature point from a difference in color information of an object itself and performing authentication for each object (hereinafter, referred to as "individual authentication").

The present invention has been made in view of such a problem, and an object of the present invention is to perform individual drug management in a medical institution and in-medical institution by performing individual authentication of the drug in a medical institution using a computing system. It is to visualize the distribution. In addition, visualization of distribution of drugs includes not only the distribution process of drugs but also traceability by visualizing information related to drugs (actors of drugs, time of occurrence of actions, amount of use, etc.).

One aspect of the present invention is a computer included in a drug traceability system in a medical institution in order to achieve such an object.
The delivery data for performing the delivery registration of the drug is received, and the delivery data includes the first characteristic data of the drug.
Perform the issue registration based on the issue data,
By storing the first feature data as master data for individual authentication of the drug, individual data of the drug can be registered.
The payout data for performing the payout registration of the drug is received, and the payout data includes the second characteristic data of the drug.
By collating the master data with the second feature data, the first individual authentication of the drug is performed.
When the first individual authentication is successful, the payout registration is performed based on the payout data.
The return data for registering the return of the drug is received, and the return data includes the third characteristic data of the drug.
By collating the master data with the third feature data, a second individual authentication of the drug is performed.
When the second individual authentication is successful, the return registration is performed based on the return data.

Further, in the computer according to one aspect of the present invention, performing the return registration is based on the return data.
Determining whether or not the drug has been used
Registering the usage status of the drug and
When it is determined that the drug has been used, it is determined whether or not there is a residue of the drug.
It is characterized by including registration of disposal of the drug when it is determined that there is no remaining drug, and registration of the remaining amount of the drug when it is determined that there is a residue of the drug. ..

Further, the computer according to one aspect of the present invention is
The temporary payment data for performing the temporary payment registration of the drug is received, and the temporary payment data includes the fourth characteristic data of the drug.
By collating the master data with the fourth feature data, a third individual authentication of the drug is performed.
It is characterized in that it is further configured to perform the temporary payment registration based on the temporary payment data when the third individual authentication is successful.

The computer according to one aspect of the present invention is
The damage data for performing the damage registration of the drug is received, and the damage data includes the fifth characteristic data of the drug.
By collating the master data with the fifth feature data, a fourth individual authentication of the drug is performed.
It is characterized in that it is further configured to perform the damage registration based on the damage data when the fourth individual authentication is successful.

Further, the computer according to one aspect of the present invention is
The date and time when the operation for each registration performed when each individual authentication of the drug is successful and the ID of the person in charge are accumulated as history data.
Data for tracing the location of the entire drug in the medical institution, data for tracing the operation history of the entire drug, and tracing the location and operation history of each drug in the medical institution based on at least the historical data. It is characterized by being further configured to generate at least one of the data for.

Another aspect of the present invention is a computer included in a drug traceability system in a medical institution.
The payout data for performing the payout registration of the drug is received, and the payout data includes the first characteristic data of the drug.
Perform the payout registration based on the payout data,
By storing the first feature data as master data for individual authentication of the drug, individual data of the drug can be registered.
The return data for registering the return of the drug is received, and the return data includes the second characteristic data of the drug.
By collating the master data with the second feature data, individual authentication of the drug is performed.
When the individual authentication is successful, the return registration is performed based on the return data.

Another aspect of the present invention is a method performed by a computer included in a drug traceability system in a medical institution, wherein the method is:
A step of receiving delivery data for registering the delivery of the drug, wherein the delivery data includes the first characteristic data of the drug.
The step of performing the goods issue registration based on the goods issue data, and
A step of registering individual data of the drug by storing the first feature data as master data for individual authentication of the drug, and
A step of receiving payout data for performing payout registration of the drug, wherein the payout data includes a second characteristic data of the drug.
The step of performing the first individual authentication of the drug by collating the master data with the second feature data, and
When the first individual authentication is successful, the step of performing the payout registration based on the payout data and the step of performing the payout registration.
A step of receiving return data for registering the return of the drug, wherein the return data includes a third characteristic data of the drug.
A step of performing a second individual authentication of the drug by collating the master data with the third feature data, and
It is characterized by including a step of performing the return registration based on the return data when the second individual authentication is successful.

Further, another aspect of the present invention is a computer program executed by a computer included in a drug traceability system in a medical institution, wherein the computer program is executed by the computer.
A step of receiving delivery data for registering the delivery of the drug, wherein the delivery data includes the first characteristic data of the drug.
The step of performing the goods issue registration based on the goods issue data, and
A step of registering individual data of the drug by storing the first feature data as master data for individual authentication of the drug, and
A step of receiving payout data for performing payout registration of the drug, wherein the payout data includes a second characteristic data of the drug.
The step of performing the first individual authentication of the drug by collating the master data with the second feature data, and
When the first individual authentication is successful, the step of performing the payout registration based on the payout data and the step of performing the payout registration.
A step of receiving return data for registering the return of the drug, wherein the return data includes a third characteristic data of the drug.
A step of performing a second individual authentication of the drug by collating the master data with the third feature data, and
When the second individual authentication is successful, the computer is made to execute the step of performing the return registration based on the return data.

As described above, according to the present invention, by performing individual authentication of a drug in a medical institution using a computing system, it is possible to perform individual management of the drug and visualization of distribution in the medical institution. Further, in the present invention, not only the distribution process of the drug but also traceability by visualizing the information related to the drug (actor for the drug, time of occurrence of the action, amount of use, etc.) becomes possible.

It is a figure which shows the ampoule and the label which concerns on one Embodiment of this invention. It is a figure which shows the whole structure of the system which concerns on one Embodiment of this invention. It is a flowchart which shows the process from the warehousing to the withdrawal of the medicine which concerns on one Embodiment of this invention. It is a flowchart which shows the return process of the drug which concerns on one Embodiment of this invention. It is a figure which shows the data stored in the warehousing data storage part which concerns on one Embodiment of this invention. It is a figure which shows the data stored in the inventory data storage part which concerns on one Embodiment of this invention. It is a figure which shows the data stored in the delivery data storage part which concerns on one Embodiment of this invention. It is a figure which shows the data stored in the drug data storage part which concerns on one Embodiment of this invention. It is a figure which shows the data stored in the payout data storage part which concerns on one Embodiment of this invention. It is a figure which shows the data stored in the return data storage part which concerns on one Embodiment of this invention. It is a figure which shows the screen for tracing the location of the whole drug which concerns on one Embodiment of this invention. It is a figure which shows the screen for tracing the operation history of the whole drug which concerns on one Embodiment of this invention. It is a figure which shows the screen for tracing the location and operation history of each drug which concerns on one Embodiment of this invention.

In the present specification, the fentanyl injection solution (FIG. 1) contained in an ampoule will be described as an example of a drug. However, the agents to which the present invention can be applied are not limited to those contained in ampoules, and include all agents such as tablets, powders and patches. FIG. 1 is a diagram showing an ampoule and a label according to an embodiment of the present invention. For example, as shown in FIG. 1, all or part of the label of the ample is imaged by an imaging device such as a camera, converted into a digital image, and then the feature data of each object is extracted from the difference in color information between the pixels of the image. By doing so, it is possible to discriminate each object (individual authentication). This is not limited to the label of the ampoule, and individual authentication is possible if it is an object such as a tablet itself (Patent Document 4).

Hereinafter, the system according to the embodiment of the present invention will be described in detail with reference to the attached drawings. FIG. 2 is a diagram showing an overall configuration of a system according to an embodiment of the present invention. In FIG. 2, the drug individual management server 100 is configured to communicate with the drug department terminal 102 and the surgery department terminal 103 via a network 101 (for example, an in-hospital intranet). Although the individual drug management server 100 is represented as one server computer in FIG. 2, it can also be constructed as a distributed computing system using a plurality of server computers. Further, through the present specification including FIG. 2, the drug department and the surgery department are assumed as an example of the movement destination of the drug, and the computer for communicating with the drug individual management server 100 is the drug department terminal 102 and the surgery department terminal 103. It is shown as. However, the individual drug management server 100 can further communicate with a computer terminal placed at a nurse station or the like in each ward for delivery to each ward, for example. In this way, the traceability of the drug can be performed by installing the computer terminal in a place where the drug can be moved and performing individual authentication and data registration for each move.

The pharmacy terminal 102 is a computer used by a person in charge of the pharmacy department or a drug manager. An imaging device such as a camera for imaging a drug is connected to the drug unit terminal 102. When a drug such as a medical drug is delivered to the hospital by a wholesaler, the person in charge registers the warehousing data via the terminal 102 of the pharmacy department. Medical drugs are stored in the drug safe of the pharmacy department, and other drugs are stored in the storage shelves. When the received drug is discharged from the surgical department, the person in charge of the pharmaceutical department registers the delivery data via the terminal 102 of the pharmaceutical department. At this time, the person in charge of the pharmacy department opens a box (product) containing a plurality of drugs, images each drug with an imaging device connected to the pharmacy terminal 102, and registers individual data. When updating data related to a drug using the registered individual data as master data, individual authentication is performed by imaging the drug with an imaging device and collating it with the master data. That is, unless the drug itself is present, data on the drug cannot be updated, and it can be guaranteed that the drug was "certainly at that time" (while using an IC tag or QR code). If so, it can be physically separated from the drug, so data can be updated without the drug itself). Further, when the drug is returned from the surgery department or the like, the person in charge registers the return data via the terminal 102 of the pharmacy department.

The surgical department terminal 103 is a computer used by the person in charge of the surgical department. An imaging device is also connected to the surgical unit terminal 103. When a drug such as a medical drug issued from the pharmacy department is to be dispensed to the operation room for use, the person in charge registers the withdrawal data via the operation department terminal 103. Further, when returning to the pharmacy department using or not using the medicine, the return data is registered via the operation department terminal 103.

The individual drug management server 100 is a server computer managed by a medical institution and installed in a server room or the like in a hospital. The individual drug management server 100 is configured to provide each terminal with a dedicated application or website for executing the present invention in response to a request from the drug department terminal 102 or the surgery department terminal 103. When the drug individual management server 100 receives the warehousing data from the drug unit terminal 102, the drug individual management server 100 performs inventory registration based on the warehousing data. Further, when the drug individual management server 100 receives the delivery data from the drug unit terminal 102, the drug delivery registration and the drug registration are performed based on the delivery data. Then, when the payout data is received from the surgical unit terminal 103 or the like, the payout registration is performed based on the payout data. Further, when the return data is received from the surgical unit terminal 103 or the like, the return registration, the remaining amount registration, or the disposal registration is performed based on the return data. Further, the drug individual management server 100 aggregates the data aggregated in the drug individual management server 100, and the traceability data of the drug (for example, the location of the drug) in response to a request from the drug department terminal 102, the operation department terminal 103, or the like. , Data showing the operation history such as payout and return) can be provided.

Next, the configuration of the individual drug management server 100 in FIG. 2 will be described in detail. The drug individual management server 100 includes a CPU 110, a RAM 111, an input device 112, an output device 113, a communication control device 114, and a storage device 116, which are connected to each other via a system bus 115. The storage device 116 is composed of a non-volatile storage medium (ROM, HDD, etc.), and has a program storage area for storing software programs related to each registration process of the present invention and a data storage area for storing data handled by the software program. And have. Each means of the program storage area described later is actually an independent software program, its routines, components, and the like, and is stored in the storage device 116. Each means is called from the storage device 116 by the CPU 110 at the time of execution and expanded in the work area of the RAM 111, so that each means can exert each function while appropriately accessing a database or the like.

As for the software programs stored in the program storage area in the storage device 116 of FIG. 2, if only those related to the present invention are listed, the inventory registration processing unit 120, the delivery registration processing unit 121, the payout registration processing unit 122, and the return registration are listed. A processing unit 123 is provided. These means are executed by the CPU 110.

As for the data storage area in the storage device 116 of FIG. 2, if only those related to the present invention are listed, the warehousing data storage unit 130, the inventory data storage unit 131, the delivery data storage unit 132, the drug data storage unit 133, and the withdrawal data storage unit are listed. A unit 134 and a return data storage unit 135 are provided. Both are constant storage areas reserved in the storage device 116.

Next, the function of each means stored in the storage device 116 of FIG. 2 will be described. The inventory registration processing unit 120 of FIG. 2 receives warehousing data from the pharmacy unit terminal 102 and stores it in the warehousing data storage unit 130. Further, the inventory registration processing unit 120 generates inventory data based on the received warehousing data and stores it in the inventory data storage unit 131.

The delivery registration processing unit 121 of FIG. 2 receives delivery data from the pharmacy unit terminal 102 and stores it in the delivery data storage unit 132. Further, the delivery registration processing unit 121 updates the inventory data stored in the inventory data storage unit 131 based on the received delivery data. Further, the delivery registration processing unit 121 generates drug data based on the received delivery data and stores it in the drug data storage unit 133.

The payout registration processing unit 122 of FIG. 2 receives the payout data from the operation unit terminal 103 or the like and stores it in the payout data storage unit 134. Further, the payout registration processing unit 122 updates the drug data stored in the drug data storage unit 133 based on the received payout data.

The return registration processing unit 123 of FIG. 2 receives return data from the surgery department terminal 103, the pharmacy department terminal 102, and the like, and stores the return data in the return data storage unit 135. The return registration processing unit 123 determines the state of the drug based on the received return data, and updates the drug data stored in the drug data storage unit 133 according to the determination result.

Next, the data stored in each storage unit of the storage device 116 of FIG. 2 will be described. The warehousing data storage unit 130 of FIG. 2 stores data related to a box (product) containing a plurality of drugs that are delivered to the hospital by a wholesaler and will be stored in a storage shelf of the drug department or a drug safe. FIG. 5 is a diagram showing warehousing data stored in the warehousing data storage unit 130 according to the embodiment of the present invention.

The warehousing data in FIG. 5 includes a "product number" uniquely indicating the product, a "receipt date and time" indicating the date and time when the product is warehousing, a "receipt person ID" uniquely indicating the person in charge of warehousing the product, and a wholesaler. It is possible to store a "wholesale trader name" indicating the name of the trader, a "pharmaceutical product name" indicating the name of the drug, and the like.

The warehousing data in FIG. 5 is transaction data generated when a person in charge of the pharmacy department or a drug manager stores a product in a storage shelf or a drug safe. Since this data is generated for each product containing a plurality of drugs, it has a one-to-many relationship with the drug data (FIG. 8) described later. The “receipt person ID” is, for example, an ID for uniquely identifying an employee engaged in a medical institution, and is associated with an employee master (not shown). As a result, the employee's name and the like can be obtained from the employee master (the same applies to the "○○ person in charge ID" described later).

The inventory data storage unit 131 of FIG. 2 stores data related to products stored in the storage shelf of the drug department or the drug safe. FIG. 6 is a diagram showing inventory data stored in the inventory data storage unit 131 according to the embodiment of the present invention.

The inventory data in FIG. 6 includes a "product number" uniquely indicating the product, a "receipt date and time" indicating the date and time when the product was received, a "receipt person ID" uniquely indicating the person in charge of receiving the product, and a wholesaler. Unique "wholesale trader name" indicating the name of the trader, "drug product name" indicating the name of the drug that is the content of the product, "delivery date and time" indicating the date and time when the product was delivered, and the person in charge of shipping the product. It is possible to store the "delivery person ID" shown in.

The inventory data in FIG. 6 is also transaction data generated when a person in charge of the pharmacy department or a drug manager stores a product in a storage shelf or a drug safe. This data is also generated for each product.

The delivery data storage unit 132 of FIG. 2 stores data related to products to be delivered from the storage shelf of the pharmacy department or the drug safe. FIG. 7 is a diagram showing the delivery data stored in the delivery data storage unit 132 according to the embodiment of the present invention.

The shipping data in FIG. 7 includes a "product number" uniquely indicating the product, a "delivery date and time" indicating the date and time when the product is delivered, a "delivery person ID" uniquely indicating the person in charge of shipping the product, and the product. It is possible to store a "drug number" that uniquely indicates a drug in combination with a number, and a "feature point" that will be described in detail below.

The delivery data in FIG. 7 is transaction data generated when a person in charge of the pharmacy department or a drug manager leaves a drug from a storage shelf or a drug safe. This data is generated on a drug-by-drug basis. Therefore, this data can be uniquely identified by the combination of the "product number" and the "drug number" (for example, the combination of the "product number" and the "drug number", such as "J1-100004-1". A drug-specific ID can be generated). The “drug number” is, for example, a sequence number assigned at the time of generating the present data. The "feature point" is, for example, feature data extracted from the difference in color information between pixels of a drug image (in the example of FIG. 7, it is a list of pixel coordinates extracted as a feature of each drug). The characteristic data is extracted when the drug is delivered and registered in the drug data (FIG. 8) described later as master data for individual authentication.

The drug data storage unit 133 of FIG. 2 stores data regarding individual drugs after opening the product. FIG. 8 is a diagram showing drug data stored in the drug data storage unit 133 according to the embodiment of the present invention.

The drug data in FIG. 8 includes a "product number" that uniquely indicates the box (product) containing the drug, a "drug number" that uniquely indicates the drug in combination with the product number, and "drug number" that indicates characteristic data of each drug. Uniquely indicates the "characteristic point", the "state" indicating the current state of the drug, the "remaining amount" indicating the remaining amount of the drug, the "delivery date and time" indicating the date and time when the drug was delivered, and the person in charge of delivering the drug. "Delivery person ID", "Disbursement date and time" indicating the date and time when the drug was dispensed to the operation room, "Distribution person ID" uniquely indicating the person in charge of dispensing the drug, Drugs from the operation room, etc. It is possible to store a "return date and time" indicating the date and time of return, and a "return person ID" uniquely indicating the person in charge of returning the drug.

The drug data in FIG. 8 is transaction data generated when a person in charge of the drug department or a drug manager opens the product. The "drug number" is associated with the drug master (not shown), whereby the name of the drug or the like can be obtained from the drug master. The "characteristic point" is the characteristic data of each drug registered as the master data for individual authentication (the "characteristic point" of the delivery data (FIG. 7)). For example, when updating drug data, individual authentication is performed by collating the feature points extracted by re-imaging the target drug with the "feature points" of the drug data. This makes it possible to ensure that the drug itself was in place when the drug data was updated (ie, if any changes occurred to the drug). When updating drug data, the data before the update is stored as historical data (not shown) and used as traceability data. The "state" is a numerical value indicating the current state of the drug, for example, 0: received, 1: being delivered, 2: received (surgical department), 3: paid out (operation room), 4: paid out (done). North Ward), 5: Payout (East Ward), 6: Payout (West Ward), 7: Payout (Outpatient), 8: Temporary Payment, 9: Returning (Unused), 10: Returning (Used) It can store 11: returned (unused), 12: returned (used), 13: damaged (unused), 14: damaged (used), 15: discarded, and so on. Temporary payment means to secure a certain number of drugs in advance in preparation for paying out to the ward when the person in charge of the pharmacy department is absent, such as at night. In this case, the drug is placed in the temporary payment drug storage area, and is paid out to the ward or the like as needed. As the "remaining amount", for example, a numerical value excluding a unit such as mg, which indicates the remaining amount of the drug, can be stored.

The payout data storage unit 134 of FIG. 2 stores data related to the drug to be paid out to each ward, outpatient department, or operation room. FIG. 9 is a diagram showing payout data stored in the payout data storage unit 134 according to the embodiment of the present invention.

The payout data in FIG. 9 shows a "product number" that uniquely indicates the box (product) containing the drug, a "drug number" that uniquely indicates the drug in combination with the product number, and a date and time when the drug is dispensed. It is possible to store the "payout date and time" and the "payout person ID" that uniquely indicates the person in charge of paying out the drug.

The payout data in FIG. 9 is transaction data generated when a person in charge of the pharmacy department or the surgery department pays out the medicine to each ward, outpatient department, operation room, or the like.

The return data storage unit 135 of FIG. 2 stores data related to the drug to be returned from each ward, outpatient department, surgery department, or the like. FIG. 10 is a diagram showing return data stored in the return data storage unit 135 according to the embodiment of the present invention.

The return data in FIG. 10 includes a "product number" that uniquely indicates the box (product) containing the drug, a "drug number" that uniquely indicates the drug in combination with the product number, and a "date and time for returning the drug". "Return date and time", "Return person ID" that uniquely indicates the person in charge of returning the drug, "Status" that indicates the status of the returned drug, and "Remaining amount" that indicates the remaining amount of the returned drug, etc. Can be stored.

The return data in FIG. 10 is transaction data generated when a person in charge of the surgery department returns the drug to the pharmacy department. In the "state", a numerical value indicating the state of the returned drug, for example, 9: returning (unused), 10: returning (used), ..., Etc. can be stored. The "remaining amount" can store, for example, a numerical value excluding a unit such as mg, which indicates the remaining amount of the returned drug.

Next, with reference to the flowchart of FIG. 3 and the data of FIG. 5-9, the process from the receipt to the withdrawal of the drug according to the embodiment of the present invention will be described along the flow. FIG. 3 is a flow chart showing a process from warehousing to unloading of the drug according to the embodiment of the present invention. In this process, in order to store the drug delivered to the hospital by the wholesaler in the storage shelf of the drug department or the drug safe, the person in charge of the drug department or the like stores the drug in the drug individual management server 100 via the drug department terminal 102. It starts from where the data was sent.

First, the inventory registration processing unit 120 of the individual drug management server 100 receives the warehousing data (FIG. 5) from the drug unit terminal 102 and stores it in the warehousing data storage unit 130 (step 301). The warehousing is done in units of boxes (products) containing multiple drugs. Since the product is unopened at the time of warehousing, individual data of each drug is not registered here.

Next, the inventory registration processing unit 120 performs inventory registration based on the received receipt data (step 302). Specifically, inventory data (FIG. 6) is generated based on the warehousing data and stored in the inventory data storage unit 131. The "delivery date and time" and "delivery person ID" of the inventory data generated here are empty data at the present time.

Next, in order to discharge the drug from the storage shelf of the drug department or the drug safe, the delivery registration processing unit 121 of the drug individual management server 100 receives the delivery data (FIG. 7) from the drug department terminal 102 and stores the delivery data. It is stored in the unit 132 (step 303). Since shipping is performed on a drug-by-drug basis and the product is opened at the time of shipping, individual data of each drug is registered here. As described above, the individual data registration is a feature extracted from the difference in color information between pixels of the obtained drug image by imaging each drug using an image pickup device connected to the drug unit terminal 102. The data (for example, the “feature point” of the delivery data (FIG. 7)) is registered in the drug individual management server 100.

Next, the issue registration processing unit 121 performs issue registration based on the received issue data (step 304). Specifically, the "delivery date and time" and the "delivery person ID" of the inventory data (FIG. 6) stored in the inventory data storage unit 131 are updated based on the delivery data.

In addition, the delivery registration processing unit 121 performs drug registration based on the received delivery data (step 305). Specifically, drug data (FIG. 8) is generated based on the delivery data and stored in the drug data storage unit 133. The "feature points" of the drug data registered here become master data for individual authentication, and are collated with the feature points extracted when the drug data is updated in the subsequent processing (if the collation is not successful). Control so that drug data cannot be updated). If the collation is successful, the "feature points" of the drug data, which is the master data, can be updated with the successful feature data ("feature points"). As a result, subtle changes in the feature data can be reflected in the master data. Further, the "payout date / time", "payout person in charge ID", "return date / time", and "return person in charge ID" of the drug data generated here are empty data at present. The "state" of the drug data stores "1" and "outgoing" when leaving the warehouse, and "0" and "incoming" when not yet delivered. This is because, for example, the product contains a plurality of ampoules of fentanyl injection, and only a part of them may be delivered. In this case, individual data is registered including ampoules that have not yet been delivered. In this treatment, the drug is described as being delivered to the surgical site, but the present invention also assumes that the drug is delivered to the ward or outpatient department. When paying out to a ward or the like, the payout data is received and the payout registration (steps 306 and 307) is performed first without receiving the goods issue data or registering the goods issue (steps 303 and 304), and based on the received payout data. Register the drug (details will be described later). When the drug is received at the surgical department or each payout destination, the receipt registration is performed at the surgical department terminal 103 or the terminal of each payout destination, and the "status" of the drug data is set to "2" "received (surgical department)". Alternatively, it can be updated with a numerical value indicating "received (○○○)" (○○○ is a word indicating the payout destination such as the north ward). This makes it possible to perform finer drug traceability. The order of steps 304 and 305 may be reversed.

Next, the payout registration processing unit 122 of the drug individual management server 100 receives the payout data (FIG. 9) from the surgical unit terminal 103 and stores it in the payout data storage unit 134 (step 306). At this time, the person in charge of the surgical department images the target drug using the imaging device connected to the surgical department terminal 103, and features data (“feature points” of the payout data from the difference in color information between the pixels of the drug image. ") Is extracted.

Next, the payout registration processing unit 122 performs payout registration based on the received payout data (step 307). Specifically, based on the payout data, the "payout date and time" and the "payout person in charge ID" of the drug data (FIG. 8) stored in the drug data storage unit 133 are updated. At this time, the "feature points" of the payout data and the "feature points" of the drug data are collated (individual authentication), and if the collation is not successful, the payout registration is not performed and this process ends. Alternatively, it is also possible to notify the surgical unit terminal 103 of an error to that effect and prompt the patient to take an image of the drug again. By individual authentication, it is not possible to pay out unless the drug itself is on the spot, in other words, it is possible to guarantee that the target drug was "certainly in the place when the payout registration was performed". can. When a drug is paid out to each ward or outpatient, the drug is registered based on the payout data, so the "feature points" of the payout data are registered in the "feature points" of the drug data, and the master for individual authentication. Used as data. After step 307, this process ends.

Next, with reference to the flowchart of FIG. 4 and the data of FIGS. 8 and 10, the drug return process according to the embodiment of the present invention will be described along the flow. FIG. 4 is a flow chart showing a return process of the drug according to the embodiment of the present invention. This process is started when the person in charge of the surgery department sends the return data to the drug individual management server 100 via the surgery department terminal 103 in order to return the drug to the storage shelf of the drug department or the drug safe. Ru.

First, the return registration processing unit 123 of the individual drug management server 100 receives the return data (FIG. 10) from the surgery unit terminal 103 and stores it in the return data storage unit 135 (step 401). This process describes the return from the surgical department, which is the payout destination of the drug, as a continuation of the process flow of FIG. 3, but when the drug is paid out to a ward, etc., it is from the terminal (not shown) of each payout destination. You will receive the return data.

Next, the return registration processing unit 123 performs return registration based on the received return data (step 402). Specifically, based on the return data, the "return date and time" and the "return person in charge ID" of the drug data (FIG. 8) stored in the drug data storage unit 133 are updated. In addition, the "state" is updated to "9" "returning (unused)" or "10" "returning (used)" according to the usage status of the drug. Furthermore, in the case of used return, the "remaining amount" can be registered based on the return data. At the time of return registration, the "feature points" of the return data and the "feature points" of the drug data are collated (individual authentication), and if the collation is not successful, the return registration is controlled.

Next, when the drug returned from the surgery department is received by the pharmacy department, the return registration processing unit 123 receives the return data (FIG. 10) from the pharmacy department terminal 102 and stores it in the return data storage unit 135 (step 403). ). The processing after step 404 differs depending on the usage status of the drug. Therefore, if the return data received in step 403 includes data on a plurality of drugs and the usage status is different for each, step 404 and subsequent steps are executed for each drug.

Next, the return registration processing unit 123 determines whether or not the drug has been used based on the received return data (step 404). If it is determined that the drug has not been used, the process proceeds to the No route, and the return registration processing unit 123 performs return registration based on the received return data (step 405). Specifically, based on the returned data, the "state" of the drug data (FIG. 8) stored in the drug data storage unit 133 is updated to "11" and "returned (unused)". Although not shown, finer drug traceability can be performed by registering the date and time when the return was received and the ID of the person in charge in step 405 (discard registration and step 408 of step 407 shown below). The same can be said for the remaining amount registration). In addition, individual authentication is also performed at the time of return registration in step 405, and if the authentication is not successful, it is controlled not to perform return registration. After step 405, this process ends.

If it is determined in step 404 that the drug has been used, the process proceeds to the Yes route, and the return registration processing unit 123 determines whether or not there is a drug remaining based on the return data (step 406). If it is determined that there is no remaining drug, the process proceeds to the No route, and the return registration processing unit 123 performs disposal registration based on the received return data (step 407). Specifically, based on the returned data, the "state" of the drug data (FIG. 8) stored in the drug data storage unit 133 is updated to "15" and "disposal". In addition, individual authentication is also performed at the time of disposal registration, and if the authentication is not successful, it is controlled not to perform disposal registration. After step 407, this process ends.

If it is determined in step 406 that there is a drug remaining, the process proceeds to the Yes route, and the return registration processing unit 123 registers the remaining amount based on the received return data (step 408). Specifically, based on the return data, the "state" of the drug data (FIG. 8) stored in the drug data storage unit 133 is updated to "12" and "return (used)". It is also possible to register the "remaining amount" based on the returned data. If the "remaining amount" has already been registered by the person in charge of the surgical department in step 402, the registered "remaining amount" is compared with the "remaining amount" of the return data received in step 403. In the case of a mismatch, an error notification can be sent to the pharmacy terminal 102 (unless the remaining drug is illegally extracted, the remaining amount should match). Individual authentication is also performed when registering the remaining amount, and if the authentication is not successful, control is performed so that the remaining amount is not registered. After step 408, this process ends.

Although not shown in the processing flow of FIGS. 3 and 4, when provisionally paying a drug, a person in charge of the drug department or the like performs individual authentication of the target drug via the drug department terminal 102 and operates the drug individual management server 100. By accumulating the date and time and the ID of the person in charge as historical data (temporary payment registration), it can be used as traceability data. Also, at the time of temporary payment registration, the "state" of the drug data (FIG. 8) is updated to "8" and "temporary payment".

In addition, even if the drug is damaged, each person in charge performs individual authentication of the target drug via a predetermined terminal, accumulates historical data, and changes the "state" of the drug data according to the usage status. Update to "13" "damaged (unused)" or "14" "returning (used)" (damage registration). It is desirable to perform individual authentication of the target drug even when registering damage, but it may be difficult to perform individual authentication depending on the damage situation. In this case, the entire image of the target drug can be captured by using the imaging device, and can be stored in the drug individual management server 100 in association with the drug data (FIG. 8) as an image for showing the damage state.

Each time an operation for loading / unloading, paying out or returning a drug, temporary payment or damage registration is performed in the processing flow of FIGS. 3 and 4, individual authentication is performed, and the date and time and charge for each operation on the drug individual management server 100 The ID of the person is stored as historical data. The traceability data as shown in FIG. 9-11 can be presented by using the history data and the drug data (FIG. 8).

FIG. 11 is a diagram showing a screen for tracing the location of the entire drug according to the embodiment of the present invention. FIG. 11 is a screen showing where 131 ampoules of fentanyl injection 0.5 mg are located in a medical institution as of 17:59 on May 1, 2017. The information on this screen and the screen is generated in the drug individual management server 100, and is displayed on each terminal in response to a request from the drug department terminal 102, the surgery department terminal 103, and the like. In FIG. 11, there are 3 unused ampoules and 6 used ampoules in the drug safe of the pharmacy department (0 damaged ampoules), 12 in the temporary payment storage area, 29 in the disposal box, and the operating department. It shows that there are 75 in the drug safe, 2 in the operation room, and 4 in the eastern ward. These pieces of information can be generated, for example, by counting the number of records of drug data (FIG. 8) for each "state". Further, the location information in FIG. 11 is not limited to the current location information, but may also indicate the location information at a certain point in the past. For example, by using the "▲" or "▼" button next to the date or hour in FIG. 11, the date / time / minute can be changed, and by pressing the "Display" button, the changed date / time / minute can be changed. It is possible to aggregate and display the location information in. When generating past location information, historical data of drug data is used. Further, in FIG. 11, by changing the list box for designating the drug (the part displayed as “fentanyl injection 0.5 mg”) to another drug, the location of the drug other than the fentanyl injection 0.5 mg is located. Information can also be displayed.

FIG. 12 is a diagram showing a screen for tracing the operation history of the entire drug according to the embodiment of the present invention. FIG. 12 is a screen for displaying the operation history of an ampoule of fentanyl injection 0.5 mg in a certain medical institution. For example, the history No. in FIG. However, the history of "1" indicates that 40 ampoules were dispensed from the drug safe of the pharmacy department to the drug safe of the surgery department at 16:09:44 on March 13, 2017. In addition, history No. However, the history of "3" indicates that one ampoule was dispensed from the drug safe of the pharmacy department to the operation room. History No. However, the history of "4" indicates that one used ampoule was returned from the operation room to the drug safe of the pharmacy department. This information can be generated based on the historical data of the drug data (FIG. 8). The information to be displayed can be narrowed down by changing the contents of the list box for specifying the operation category and the destination in the upper part of FIG. 12 (for example, from the drug safe in the drug department to the drug in the surgery department). Only payout information to the safe can be displayed). Further, also in FIG. 12, by changing the list box for designating the drug to another drug, the operation history of the drug other than the fentanyl injection solution 0.5 mg can be displayed.

FIG. 13 is a diagram showing a screen for tracing the location and operation history of each drug according to an embodiment of the present invention. FIG. 13 shows the current ampoule of 0.5 mg fentanyl injection identified by the drug individual ID “J1-12356-1” (combination of “product number” and “drug number” in drug data (FIG. 8)). It is a screen that displays the location and the operation history. FIG. 13 shows that the target ampoule is in the disposal box and has been discarded. This information can be generated based on the "state" of the drug data (FIG. 8). In addition, the target ampoule was moved from the drug safe of the pharmacy department to the drug safe of the operating department at 16:09:44 on March 13, 2017, and at 17:47:05 on the 14th of the same month of the same year. It indicates that it was returned from the drug safe to the drug safe of the pharmacy department in a used state and was discarded as it was. This information can be generated based on the historical data of the drug data (FIG. 8). Further, although not shown in FIG. 13, the history data can be used to further display the person in charge of performing each operation, the remaining amount of the drug (usage amount), and the like.

Based on the above, according to the present invention, by performing individual authentication of a drug in a medical institution using a computing system, it is possible to perform individual management of the drug and visualization of distribution within the medical institution. Further, in the present invention, not only the distribution process of the drug but also traceability by visualizing the information related to the drug (actor for the drug, time of occurrence of the action, amount of use, etc.) becomes possible.

Claims (8)

A computer included in a drug traceability system in a medical institution.
The delivery data for performing the delivery registration of the drug is received, and the delivery data includes the first characteristic data of the drug.
Perform the issue registration based on the issue data,
By storing the first feature data as master data for individual authentication of the drug, individual data of the drug can be registered.
The payout data for performing the payout registration of the drug is received, and the payout data includes the second characteristic data of the drug.
By collating the master data with the second feature data, the first individual authentication of the drug is performed.
When the first individual authentication is successful, the payout registration is performed based on the payout data.
The return data for registering the return of the drug is received, and the return data includes the third characteristic data of the drug.
By collating the master data with the third feature data, a second individual authentication of the drug is performed.
A computer characterized in that when the second individual authentication is successful, the return registration is performed based on the return data. Performing the return registration is based on the return data.
Determining whether or not the drug has been used
Registering the usage status of the drug and
When it is determined that the drug has been used, it is determined whether or not there is a residue of the drug.
It is characterized by including registration of disposal of the drug when it is determined that there is no remaining drug, and registration of the remaining amount of the drug when it is determined that there is a residue of the drug. The computer according to claim 1. The temporary payment data for performing the temporary payment registration of the drug is received, and the temporary payment data includes the fourth characteristic data of the drug.
By collating the master data with the fourth feature data, a third individual authentication of the drug is performed.
The computer according to claim 1 or 2, further configured to perform the temporary payment registration based on the temporary payment data when the third individual authentication is successful. The damage data for performing the damage registration of the drug is received, and the damage data includes the fifth characteristic data of the drug.
By collating the master data with the fifth feature data, a fourth individual authentication of the drug is performed.
The computer according to claim 1 or 2, further configured to perform the damage registration based on the damage data when the fourth individual authentication is successful. The date and time when the operation for each registration performed when each individual authentication of the drug is successful and the ID of the person in charge are accumulated as history data.
Data for tracing the location of the entire drug in the medical institution, data for tracing the operation history of the entire drug, and tracing the location and operation history of each drug in the medical institution based on at least the historical data. The computer according to any one of claims 1 to 4, characterized in that it is further configured to generate at least one piece of data for. A computer included in a drug traceability system in a medical institution.
The payout data for performing the payout registration of the drug is received, and the payout data includes the first characteristic data of the drug.
Perform the payout registration based on the payout data,
By storing the first feature data as master data for individual authentication of the drug, individual data of the drug can be registered.
The return data for registering the return of the drug is received, and the return data includes the second characteristic data of the drug.
By collating the master data with the second feature data, individual authentication of the drug is performed.
A computer characterized in that when the individual authentication is successful, the return registration is performed based on the return data. It is a method performed by a computer included in a drug traceability system in a medical institution.
A step of receiving delivery data for registering the delivery of the drug, wherein the delivery data includes the first characteristic data of the drug.
The step of performing the goods issue registration based on the goods issue data, and
A step of registering individual data of the drug by storing the first feature data as master data for individual authentication of the drug, and
A step of receiving payout data for performing payout registration of the drug, wherein the payout data includes a second characteristic data of the drug.
The step of performing the first individual authentication of the drug by collating the master data with the second feature data, and
When the first individual authentication is successful, the step of performing the payout registration based on the payout data and the step of performing the payout registration.
A step of receiving return data for registering the return of the drug, wherein the return data includes a third characteristic data of the drug.
A step of performing a second individual authentication of the drug by collating the master data with the third feature data, and
A method comprising: a step of performing the return registration based on the return data when the second individual authentication is successful. A computer program executed by a computer included in a drug traceability system in a medical institution, wherein the computer program is executed by the computer.
A step of receiving delivery data for registering the delivery of the drug, wherein the delivery data includes the first characteristic data of the drug.
The step of performing the issue registration based on the issue data, and
A step of registering individual data of the drug by storing the first feature data as master data for individual authentication of the drug, and
A step of receiving payout data for performing payout registration of the drug, wherein the payout data includes a second characteristic data of the drug.
The step of performing the first individual authentication of the drug by collating the master data with the second feature data, and
When the first individual authentication is successful, the step of performing the payout registration based on the payout data and the step of performing the payout registration.
A step of receiving return data for registering the return of the drug, wherein the return data includes a third characteristic data of the drug.
A step of performing a second individual authentication of the drug by collating the master data with the third feature data, and
A computer program comprising causing the computer to execute the step of performing the return registration based on the return data when the second individual authentication is successful.

Images