This paper discusses the problems encountered during implementation, how they were overcome, giving an inside view of one of the very good pharmacy modules currently available in the market.
The pharmacy in a hospital is an area where the medical and non-medical components of a hospital information system (HIS) meet. Alongside inventory control are components relating to drug allergy warnings, drug-drug interaction alerts and intelligent pharmaceutical substitution of prescribed drugs from within current inventory stock. Sir Ganga Ram Hospital, New Delhi, went in for enterprise wide computerisation of its hospital, including its pharmacy in June 2007. The hospital has an in-house pharmacy with a daily turnover of over Rs 13 lakhs. Implementation of the HIS in our pharmacy has been turbulent but has resulted in a system that is meeting most of our requirements.
Sir Ganga Ram Hospital had been running a FoxPro based system for over 20 years. The system had been custom developed by a local Delhi based team. It covered admission and discharges, had a basic laboratory module, a billing module where all charges had to be manually entered for most items, an inventory control system and a basic pharmacy system. Medicine stock was received by the hospital and batch level prices were entered at the time of receiving the stock from vendors. Requests for patient medication were sent to the pharmacy on slips of paper. The pharmacist typed in details of the medicines dispensed to the patient in the system which automatically reduced the stock and also billed the patient based on the price entered for that medicine at the time of receiving the stock from the vendor.
There were however many lacunae in the system. There was no interface for the care providers to prescribe medicines, get real time drug to drug interaction alerts or get notified of patient’s drug allergies. In the pharmacy, the system did not allow substitution of an ordered drug with another similar drug from current pharmacy stock. There were security related issues also. Since FoxPro is not a very secure system, there was always the potential of manipulation of data directly in the transaction tables. Also a transaction history and audit trails were not maintained. Apart from the pharmacy module the other FoxPro modules were also getting antiquated. What was missing was a tight integration of the various modules running in different parts of the hospital. It was hence decided to upgrade the entire HIS and go in for a more secure and integrated system.
We surveyed the market. There were many vendors supplying software. However at that time there were very few that were mature. Mature means an application that has been successfully implemented in at least a couple of hospitals other than the one it was originally designed for. We chose TrakCare (now with InterSystems, USA) because it has a track record of over a hundred implementations worldwide, many of them in third world countries. There were some apprehensions about the vendor being not in India; however their implementation local partner turned out to be very competent and we had a successful implementation. An integrated pharmacy module was what we got along with the rest of the software.
Computerised Physician Order Entry (CPOE)
This paper slip step of the FoxPro system has now been removed, with the care providers being able to place medication orders in the system at the ward level itself. This allows the hospital to also limit the number of medicines they can order. We can limit the list of medicines visible to care providers initially to only those that are listed in the hospital formulary. Since formulary drugs are available at a much lower price than non-formulary drugs, their purchase price having been negotiated with the vendor, it adds up to a substantial cost saving. In case the care provider does not find the medication in the formulary list, he has the option to uncheck the ‘Limit to Formulary’ box and see all medicines.
The HIS system warns of drug-drug interactions and gives details of each interaction type. However to be really useful, all medication prescription entries need to done in the system by the doctor who is more likely to attend to the alert than if the same entry is being done by a nurse on the behest of a doctor.
Allergy alerts are also provided by the system. In case the patient has been flagged to be allergic to a particular medication, even during a previous visit to the hospital, such alert information is carried forward during the lifetime of the patient, unless manually cancelled by a care provider. The system does not stop the prescription from going through; it simply warns the doctor.
Drug details (monographs) are available in the system. A doctor can click on a drug he is planning to prescribe and read up details on the indications, dosage, side effects, interactions, etc. This data had been provided to us as part of the drug database that we purchased prior to starting the system.
“There were some apprehensions about the vendor being not in India; however their implementation local partner turned out to be very competent and we had a successful implementation. An integrated pharmacy module was what we got along with the rest of the software.”
Intelligent drug substitution works by substituting another drug only if the generic drug, strength, drug form, route and unit of packing are the same for both the drugs. Thus, tablet Crocin does not substitute with injection Calpol. Nor does tablet Crocin 250 mg substitute with tablet Calpol 500 mg. It also will not substitute Tetanus Toxoid vial with Tetanus Toxoid ampoule, since the packing unit is not the same. Drug substitution mapping has been a very laborious step and it took us many months even after the start of the system to get everything correctly mapped. Now it works flawlessly.
We have been able to stop ‘leaks’ from our stocks. At any time it is possible to know the medicine stock lying at various substores. This also allows us to move stocks from a location where they are in excess to areas where they are urgently needed. It also allows us to recall a batch from circulation should it be required since we can trace movements of each batch to various substores as well as patients to whom they had been dispensed.
Billing for medication
Each batch of a drug has a price attached to it at the time of receiving the drug in the hospital’s receiving section. This is what gets billed to each patient without any additional user intervention.
Stock transfer on ‘go-live’
One of the biggest problems was transferring of stock quantities from the FoxPro system to the new system at the time of ‘go-live’. We realised that stock data in the old system had many inconsistencies. We did make mistakes and had to upload the inventory twice before we got it right, necessitating the pharmacy to remain closed for a couple of days and putting a severe burden on the hospital. What we learnt from this was how to migrate stock from an older system into a new system differently. We have since then used this method for transitions in other stores and have had no problems.
We tied up with the publishers of a popular printed drug database provider to get data in an electronic format that could be uploaded into our new system. Unfortunately, the structure of the database we received was more in keeping with the provider’s own requirement, which was to store the data in an easy to read format for their website and printed publications. For data upload into an intelligent drug substitution system, the data has to be as ‘granular’ as possible, i.e. broken down to its smallest component. Drug substitution requires the drug form (tablet, injection, drops, etc.) to be stored in a field separate from that of its strength (2 mg, 100 mg, etc.). The packing unit (ampoule, vial) also needs to be in its own separate field. What we received were combined fields with data stored like Injection Fortum 500 mg/1000 mg. We had to manually split the Injection, Fortum, 500 and gm words into individual fields and also create an entirely new row for the 1000 mg injection. Another problem was that drug interaction data was maintained as a textual narration. A proper interaction warning system requires it to be in a tabular form, with the first column having the name of the first drug, the second column having the name of the second drug and the third column having the interaction details. The entire process of making the provided data conform to our system took months of manual data manipulation. It was not that our system was too demanding and had not been built in a user friendly way. Any system that provides intelligent drug substitution will need data in a ‘granular’ form.
“The success or failure of the pharmacy system depends on how well the rest of the information system has been implemented. It also depends on how tightly the software vendor has integrated the systems.”
Another problem with obtaining data from a drug database provider was that updates were available on a monthly basis. For a hospital that inducts new drugs as and when they appear in the market, this was too much of a delay. We started entering drugs on our own when they appeared in the market. There was then an issue of duplicate drugs being uploaded into the system once the monthly update arrived, if we had already entered that drug on our own. And the work required to individually split the provided update data into individual fields each time was too daunting. We hence discontinued our subscription and now manage updates internally. A disadvantage of this approach is that we are not populating drug monograph and drug to drug interaction data.
MIMS apparently maintains data in a granular form that is compatible with pharmacy systems. However for this to be practically useful, the system should have a comprehensive list of Indian drugs and should provide very frequent updates that can be simply uploaded into the system with minimum manipulation.
Inviting open tenders for medicines
We maintain all data on drugs that come in a tablet form at a unit tablet level. Thus the stock count in the system is of the number of tablets and not number of strips. Similarly all price data in the system is of unit tablet cost and not cost of the strip. Although this system works well internally it creates problems when we invite quotations from vendors. Vendors prefer to quote prices as mentioned on the strip. To act as a bridge between how vendors maintain and quote prices and how we manage them internally, we made a stand alone software that vendors download from our website and use to send in their quotations. They enter quantities in strips and prices as mentioned on the strip. The software converts it into the formats we use and allows us to directly upload into our system.
How much has the new system helped us?
Compared to the years before implementation of the current HIS, overall pharmacy profits have gone up by approximately 15%. Considering our daily turnover of about Rs 13 Lakhs, this is a fair amount. There are many possible factors leading to this.
Less ‘leaky’ inventories.
Intelligent drug substitution.
Better utilisation of stock leading to a smaller inventory and less capital tied up. For example if one substore needs an item they do not have, we can locate it from another substore and transfer it from there.
Complete billing. In the previous partly manual system, items were used for patients and sometimes not billed. That does not happen anymore.
Better MIS reports, leading to more intelligent decisions regarding functioning of the pharmacy.
Has it affected care providers and patients?
The initial impression has been that the time lag between prescribing of medication and its delivery has not been changed much by the new pharmacy module. This implies that other bottlenecks exist in the delivery of medication to wards. To identify these bottlenecks and their dependency on each other, our hospital is planning an audit. Amongst other thing, this will include following up a large number of prescriptions originating from the wards and measuring the time taken between various activity benchmarks, e.g. time between doctors prescribing a medication and actual entry of that order in the HIS, time between packing of the medication in the pharmacy and its pickup from the pharmacy, and so on. Another aspect that is being studied is the effect the new system has on preventing prescription errors, allergy alerts, etc. The problem with such studies is that we do not have much historical data to compare it with, since such studies were not done in the past in preparation, as baselines, for future studies.
A pharmacy information system is only part of an overall hospital information system. The success or failure of the pharmacy system depends on how well the rest of the information system has been implemented. It also depends on how tightly the software vendor has integrated the systems. For instance, in our hospital, purchase, good receiving, stock transfers, stock consumption on dispensing, billing to patients and their reflection in the finance module are all linked. Unless a hospital ensures that what they are getting is similarly linked, implementing a pharmacy information system may not give them the best returns on investment.
To read the complete paper log on to the website: