Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

<html><head><title></title></head><body>Transcript of 27-07-2007 IRC demo

First thoughts about UI
Sharon's evaluation of our Peru order entry system

OpenMRS Google Summer of Code Project 2007

Hamish Fraser

Drug order entry interface for TB and HIV medication

This project is to build one of the key components of an electronic medical record system, the interface for entering drug orders. Drug regimen errors are a major concern in developed countries and are believed to kill tens of thousands of patients each year in the US alone. Drug order entry has become a key goal of any EMR installation due to many clinical studies that have shown that such systems can reduce errors in drug regimen prescribing. The ideal scenario is that all medications are prescribed online by the doctors in real time. This offers the maximum opportunity to provide warnings and corrections of potential errors. In the environments where we work in developing countries the drug orders of often written on paper and entered by other staff. While this reduces the potential for warnings to reach the prescriber it still offers important opportunities to reduce errors in drug entry by warning data entry staff to check the paper records or send them back to the doctor for checking. With a good interface we hope to encourage doctors to move to direct entry and review of their orders online.

Partners In Health have developed several drug order entry interfaces over the last 5 years for use in Peru, Haiti, the Philippines and South Africa. Examples of the HTML for some of these are attached. The goal of each of these sub-projects have varied from providing tools to enter individual drugs in a simple but comprehensive fashion (Peru A) to entering a limited number of standard drug regimens (OpenMRS Rwanda). The tool used in the Philippines is the most flexible to date. There are important tradeoffs between flexibility to enter any drug, dose and frequency versus the speed and efficiency of entering a standardized regimen with the dose and frequency of each drug pre-defined. Drug entry is the type of problem with a “long tail†where most of our current patients will need a quick and simple standard regimen, but some will require very detailed and complex regimens. Factors that lead to greater complexity include:

  • Doses based on a patients weight
  • Combination drugs that include several different ingredients in varying proportions (stored in the drug combination table)
  • Drugs that must be started at a low dose which is increased in increments
  • Drugs that interact and therefore must not be prescribed together, or where the dose needs to be reduced when prescribed together
  • Drugs that are contra-indicated by previous side effects or allergy
  • Drugs that may be contra-indicated in the light of abnormal laboratory results

This project will build on key features of the OpenMRS system including:

  • The drug orders tables as well as the concept dictionary (rather than the observations tables as used by some implementations)
  • JSP pages with Dojo to provide interactivity
  • A new table for drug order sets (combinations of drugs, doses etc.)
  • Systems for decision support rules. As this component of OpenMRS is not complete yet we will likely start with a lookup table of drugs for tuberculosis treatment and possible contra-indications

Important considerations for a successful system include good performance over slow internet connections. This may require an alternative page that makes very few connections to the server or it may be possible. The system should be designed to support multiple languages with a lookup table of translations ideally linked to the main language tables for OpenMRS.

Design of the interface

The graphic shows a prototype design for the drug order entry system. Once we have some working prototypes we will test them extensively both within the team and with physicians and other users. Our goal will be to minimize the amount of time and clicks it takes to enter drug orders while minimizing errors. At the same time it is important that the user can “drill down†and see exactly what is prescribed and modify the order in a highly flexible fashion.

We can discuss the details on Tuesday and plan to get you started.

</body></html>

  • No labels