Skip to content

Proposed Philippine eHealth Development Plan

Here is my proposed eHealth development plan. Adopting heavily on the Rwandan Health Enterprise Architecture (rhea.jembi.org) and leveraging on the work of the OASIS (heaf.jembi.org), this (working) paper draws the important components of a health EA and how messages will be exchanged between implementations. For discussions here: pehdp.blogspot.com and for formalization through the Department of Health Joint DOH-PhilHealth IT Steering Committee.

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.