Skip to content

Why Drugs Should be Coded to the Brand

In the Philippines, we have the Generics Law which requires doctors to write prescriptions only in generics. It also prohibits government agencies to use brands in the procurement process. This “procure-by-generics” rule is very important because it assures fair competition amongst sellers of that generic drug. Contrast that to a “procure-by-brand” rule which practically ensures the market goes only to that specific seller who has that brand in stock.

For the rest of this article, we will presume that generic drugs are as effective as branded drugs (this topic is for another day — or even for another blog), and that all generic drugs on the market have been tested adequately by the responsible quality assurance agencies to have met minimum standards. Bottomline: generic drugs and branded drugs have the same effectivity and efficacy.

Assuming that generic drugs are functionally similar to branded, in health informatics, we need to be able to identify a drug consistently across disparate information systems. The question is: do we use codes for generic drugs or codes for branded drugs? I have met several doctors and public health officials who insist that the drug codes should be generics because that is required by law. They also think that generic drugs cannot be coded to the brand because they DO NOT have brand!

Wrong.

If we are going to build databases that store transactions for drugs, we should use coding systems that go down to the brand level. Contrary to what many people think, generic drugs have “brands” that differentiate them by name from others — this is their manufacturer. An example is shown below.

To fully comprehend the need for coding to the brand, we need to understand the four important steps in drug management that require drug codes. In order, they are:

  1. Drug registration
  2. Before drugs are allowed to be sold in any country, they must be registered with an official agency tasked for that purpose. In the US, this is the Food and Drugs Administration or FDA. In the Philippines, it is also called by the same name (but it used to be called BFAD). Due to the specific requirements of registration, each drug should be coded down to the brand (even down to form and strength) to differentiate them from each other. If they are coded by generics ONLY, FDA will not be able to distinguish one brand of that generic with that of another.

    But what if the drug is being registered as a generic drug? There is still a “brand” linked to it which is the manufacturer’s name. So paracetamol UNILAB is different from paracetamol WYETH. So each of these should have a different brand code although they will share the same generic code “paracetamol”.

  3. Procurement
  4. Now when government agencies buy drugs, they should not refer to brands or else that would constitute unfair competition and favoritism (euphemisms for graft and corrupt practices). It is also prohibited by RA 9184 or the Procurement Law. Informatics-wise, this means each branded drug must refer to the same generic code so that when a procurement for a specific generic code is made, a list of registered brands (from the FDA list) can be made available to the purchasers.

  5. Clinical administration
  6. Once purchased, these drugs reach the health facilities (eg, hospitals and clinics). Here, if the facility has an electronic medical record, the drugs given to patients by mouth or by injection or by other routes are digitally recorded. We should use the brand/form/strength code in the EMR and not the generic code. If we just code using generics, we will not be able to find out which brand was actually given to the patient. This is important because of the next step, adverse drug reaction reporting.

  7. Adverse drug reaction reporting
  8. If a patient dies or develops an allergy due to the drug administered, this is an adverse drug reaction. It should be reported to the FDA so that the FDA can find out which drugs to pull out from the market so the public is protected from further injury. But if the EMR coded only for the generic code, FDA might pull out all generic drugs when in fact, it may have been just a specific brand causing all the problems.

And that is why drugs should be branded down to the brand.

The big question is: where do we get these standard codes for the Philippines?

Suggestions are welcome. The reader is kindly directed to read more on RxNORM, a database of drug codes created and maintained by the National Library of Medicine in Bethesda, Maryland. Its structure offers a structured look at how these kinds of drug coding systems should be built.

Electronic prescriptions

While so much money has been spent (and will be spent) on electronic medical records, we have been missing the whole point – it may not be practical to computerize everything and anything in healthcare. The cost just exceeds the benefits. So this constrains us to reflect as to what areas would benefit the most from automation?

Easy – ask yourself – what are the cost centers?

Looking at a health facility, these are: room and board, drugs and supplies, labs, and radiology. Automating these business processes would bring bang for the buck. Automating other areas would bring satisfaction to the health informatics professional but not for the company bottom-line.

Electronic prescription seems the lowest lying fruit. This is what consumes most of the time of doctors and also a common reason for patient safety problems (illegible prescriptions, misreadings of pharmacists).

Of courses you can create your own e-prescription software but why reinvent the wheel? The US National Library of Medicine in Bethesda has created two e-prescription software: MyMedicationList (for patients) and MyRxPad (for doctors). They run on Java on any platform. Try it out!

Informatics in Action: Hands Rosling

Standards for Health Information in the Philippines 1999

An NIH publication.

Full text here.

Effect of Image Compression on Telepathology

Archives of Pathology & Laboratory Medicine
Volume 124, Issue 11 (November 2000) pp. 1653-1656

Full text available here.

History of Health Informatics in the Philippines

This needs updating but I am posting it here for those who are looking for references.

Get it here.

What’s in the license fee of a proprietary hospital information system?

What actually do we pay for when we purchase a proprietary hospital information system? Let’s dissect where the money goes.

1. software development. This goes to the salary of the programmers who were hired by the vendor to develop the software. Interestingly, if the software is already running in another hospital, this cost has been covered (by hospital A for hospital B). So the subsequent use of the software is technically profit for the vendor already. Some vendors however opt for a loss-leading strategy and not charge for software development. They absorb the cost of software development (and not pass this to the hospital) but lock-in the hospital to a service level agreement to run the system for a certain period.

2. customization. Most vendors already know that the software is useless right after installation. The software has to be customized to fit the language and the workflow of the hospital (names of doctors and nurses, list of drugs, drug prices, room numbers, etc). So the vendors allocate their own workers to customize the software. This cost is often passed on to the hospital.

3. implementation. Vendors already know that a customized software is like a treadmill. It’s useless unlessĀ  the health staff run on the treadmill. So the vendors hire nurses (sometimes called clinical coordinators) to train the internal health staff how to use the software (like personal trainers in the gym!). This is very expensive because it is time-consuming and frustrating. Some vendors charge for a regular monthly fee exactly to make sure that these clinical coordinators remain. Often, the clinical coordinators end up using the system and encode for the staff if needed. In some cases, these coordinators are directly hired by the hospital.

4. maintenance. If the hospital does not have an internal IT staff, then the vendor can charge for this. Again, this is recurring and is always passed on to the hospital.

Bottomline#1: The cost of implementing a hospital information system is prohibitive. The cost are the same for FOSS HIS except for two items:

  1. there is no upfront cost for licenses with FOSS
  2. in the end, the FOSS HIS is owned by the hospital rather than the vendor.

Bottomline#2: implement in modules

  1. master patient index
  2. clinical drug administration and/or results review
  3. diagnosis and procedures
  4. claims management system

Bottomline#3: if you don’t know how to do this, try it out first using FOSS hospital information systems like OpenMRS!

Hospital Information Systems Cost Centers

Want to automate the hospital?

First, it depends on how big is the hospital. HIS are expensive and unless the hospital is big enough to generate revenues, a full HIS is not advisable. Having said that, there is benefit for HIS — it’s just that you have to make sure you lay down the HIS in modules (or components) which are affordable to the hospital and that the hospital is able to recoup expenses quickly through efficiencies experienced with automation.

There are at least four cost centers in hospital information systems:

  1. project management
  2. customization
  3. implementation
  4. maintenance

Project management – the formation of a team (internal with or without external consultants) to see the project from beginning to maintenance mode

Customization – the effort of customizing the software to fit the needs of the hospital

Implementation – the cost of getting the health staff to use the system

Maintenance – the cost of making sure the system is always available and accessible to the staff

I didn’t mention software license as a cost center because I am presuming the hospitals will be using Free and Open Source Software such as OpenMRS. If the hospital insists on proprietary systems, they have to factor in that cost between 1. Project management and 2. Customization. Watch out if you take this (proprietary) option — make sure you have enough funds to carry you through to Implementation and Maintenance.

Better to use FOSS first (and fail) than to use proprietary (and fail). Project management teams that fail after a FOSS implementation will appreciate greatly the lessons they get from the FOSS system. If they decide to opt for a proprietary sytem after a failed FOSS solution, that would then be acceptable. But opting proprietary solutions first is high risk because the ‘education’ of the project management team has still not happened.

The education of the project management team is a good investment for the hospital but it often comes from the scars of a failed implementation. Why pay for proprietary licenses when the project management team is not yet ‘battle-scarred’? PM teams can get the scars with FOSS at a cost the hospital can afford. Put your money in the right place.

EHR Fundamentals

We’ve been receiving a lot of calls for installations of electronic health records. For starters, electronic health records are expensive. It’s not for all (definitely not for the weak-hearts, unsure, and equivocal).

Having said that, if a decision has been made, a systematic implementation is crucial to success.

First, is there a sponsor? The sponsor basically provides the political coverage (not to mention assuring the funds will be there when needed).

Second, the master patient index comes first. Get all patients encoded in the MPI. Nothing follows till at least 50% are already on the system.

Third, results review. Lab results and radiology image viewing (in that order).

Fourth, electronic prescription.

Fifth, if you reach this step, you have the right (and the project management savviness/maturity) to choose what you want to automate next.

There may be debates as to the order of the third and fourth steps. The forum is open to other opinions.

Why Health Facilities Should Prefer Open Source Over Proprietary Software

I have been very vocal about free and open source software (FOSS) for healthcare, mostly for philosophical reasons. But that approach is not always shared by other people with different views of the world. It seems ‘economics’ (being mostly quantitative) is easy for many to understand so let me use that as the platform for argument.

A hospital director can decide to either use FOSS or proprietary software. Whichever they use, they need to understand that they will still have to invest on ‘customization’ and ‘implementation’. Let me explain each.

Customization is when, after installing the software (eg, EHR), you still need to put in specific data about your facility. Examples: entering each room, bed, doctor, nurse, lab test, drug, drug prices, taxes, rules, workflow, etc. I have never seen an EHR software that has these data already built-in (and you never will) because these values differ widely between facilities. So when you install an EHR( regardless of whether it is FOSS or proprietary), there will be significant manpower time spent on customization — and that will have a price. For FOSS, it will be time lost by your internal staff when they do the customization; for proprietary software, the vendor’s employees will do this for you for a fee. Either way, the hospital pays for it.

After the EHR has been customized, you then go into ‘implementation’ or the actual use of the software by the workers in the facility. This is where things gets messy. Many hospitals are surprised that after all the effort (plus time and cost) of customizing, they suddenly discover that doctors and nurses are resisting the new system. Getting health workers to use electronic health information systems can be very challenging. Invariably (and this is a well-studied phenomenon), they will resist change. Most health informatics projects fail because of the implementation challenges. Whether you use FOSS or proprietary software, you will still need to hire a good project management team to implement the customized system.

The sad thing is that by the time hospitals fail in the implementation phase, so much money has been expended already in customization. That’s good money down the drain.

So the math is simple. For both FOSS and proprietary health information systems, there will be expenses in customization and implementation (ergo, they cancel out and there is not much difference with either system). But for FOSS, you don’t need to pay for an upfront license fee because it is free. For proprietary software, you need to pay outright a license fee (which can be substantial). This proprietary license fee is not refundable. If you fail in customization or in implementation, you’ll be stuck with license for software that does not work. Read the fine print: you can’t even sell it to another hospital. And even if you can, it won’t work because what you have is custom-fit for your hospital, not theirs.

Another way to look at it is — if you use FOSS and you customize it, the end product is owned by you, the health facility. But if you use a proprietary system and customize it, the end product will still be owned by the vendor — not by you, the health facility. Yes, your money would have been wasted because after all the effort (plus time and cost) you place on customization, you don’t even own intellectual property rights over your customized version.

Make sure you understand the licenses of the software you sign up for. These can make or break the success of your implementation.

Bottomline: FOSS is cheaper, better, more empowering for Philippine health facilities. Health facilities should prefer FOSS over proprietary software.

Recommendations:

1) Use CHITS (www.chits.ph) in rural health units (full disclosure: we manage the CHITS project — GPLv3)
2) Use OpenMRS (www.openmrs.org) for the rest: private clinics, district hospitals, provincial and regional hospitals GPLv2)
3) Hire people (IT/nurse/doctor) who can show certificates of attendance/competency for health informatics