2012-07-12 Pharmacy Meeting Notes

There are two distinct modules. Pharmacy module is almost done. It focuses on supporting the pharmacist in filling a prescription from the doctor. The inventory module is not started yet and belongs to us. It keeps track of the drugs. We are free to do what we like. We probably should make all of our own tables to minimize the interface between modules. They prefer the modules to be independent. 

All UI's in V4 or V5 only pertain to the pharmacy module.  No inventory module screens have been made yet.  And no extensions for the store manager role (vs. the pharmacist role) have been added yet.

Relationship between main store and dispensaries. ( ie central pharmacy and satellites ): 

Inventory module supports the main store. Purchasing is done by another group. The main store will have to notify that other person or group when stuff is needed. Receiving from the vendor is done by the main store.  Obviously, main can view every dispensaries inventory Dispensaries cannot requisition (transfer) from each other. They can only requisition from the main store. Not decided on how much of the overall stock that a dispensary can see.

Prescriptions are written only by the doctor (by law).  Pharmacists have read only access to prescription.  If they think there is a problem with the prescription (in a teaching hospital, interns make mistakes), they ask the doctor to review the prescription.  The doctor may edit the prescription.  Once prescription is written, patient name goes into queue that all pharmacists can see.

The pharmacist needs to see/check inventory when filling a prescription.  They need notification in case there is no local stock (ie a new drug).  Drug packages for patients are not prepared in advance.  When the patient shows up at the pharmacy, the pharmacist pulls up the patient name from the queue and collects the drugs to fill the prescription.  If there are questions for the doctor, they must be answered while the patient is at the window.  Assume pills are dispensed in exact numbers (not in a package/vial of xx pills).  The patient pays for the drugs and takes them away.  At this point, the prescription is done, the patient's name is removed from the queue, and all distributed drugs are deducted from inventory.  There is no virtual stock.  Maybe some day they will prepare packages in advance (like in US).

Pharmacist checks local inventory or is alerted when safety stock level is hit. (safety stock levels not stored anywhere yet)  They generate a requisition for multiple drugs that is sent to main store.  Local pharmacy sends representative to main store to pick up drugs.  When representative gets to main store, Requisition package is notprepared in advance (first come first served). Store manager pulls up requisition list and fills requisition with whatever is on hand (if not enough, partially fill requisition).  Drugs given to representative, whose name is recorded in db.  At this point, the requisition is done and removed from the queue, and all distributed drugs are deducted from store inventory and added to dispensary inventory. (What if guy steals it or crashes car? Need to adjust inventory.)  There is no virtual stock and there is no receiving by the dispensary.  If the requisition was partially filled, it is closed anyway.  The dispensary needs to generate a new requisition for any amount it did not get.

Swapping. A variation on requisition. Expired ( or about to expire drugs ) can be traded back to the main store.  They are replaced on a one to one basis.  Expired drugs may be scrapped or swapped back to vendor.

Where does Inventory module fit into Purchase Order task flow? 

There is no PO module at this time. There is no hospital MRP system.  It's all on paper.  Two tasks: Generate PO for purchasing group, and  receive incoming drugs from vendor.

Swapping of expired drugs back to the vendor sometimes occurs.  It is not clear if this is one to one.  For example, I may take back your old stock and give you a 50% discount on the replacement stock.

The requisitions and PO's should be separate entities/tables.  However, it may be possible to base them on the Encounter entity.  The encounter basically holds all of the information for a patient visit, including observations and orders (lab or drug).

Prescriptions may attempt to leverage the regimen entity, but this should be determined by the pharmacy module team (not us).

Alerts for drug expiration will be triggered at expiry date + 2 months.

Units prices for patient are read only by pharamacist (maybe have an override). Stored in a master table.

Philosophy is to just do it and fix it later if it didn't work.  Don't get stuck in too much planning.

All task flows need updating based on this info.  Less emphasis on the prescription task flow details, because most of that is being handled by the pharmacy module, which is not our domain.

Implement drug_groups table from db through GET/POST.  Should closely resemble the drug_ingredients table in behavior.