We make EMR (Electronic Medical Record) Software. Being users ourselves, our development approach has been entirely from the users' perspective. The ease and simplicity of the PowerBuilder development environment deserves due credit for the relative success of our efforts. Our main developer has had no formal training in software, and still treats the development efforts as a hobby. As we are laypeople, for the most part, some ideas that we have incorporated may be considered by the more experienced as out-of-the-box thinking.

Medical Records traditionally have been textual and generally written in long hand. With the onset of computers, the shift to transcription occurred, where as dictation of the clinical details was done during the consult. A secretary or transcriber would then carefully convert the recording to a clinical document using a document editor. However, both for handwritten as well as transcribed documents, the information recording is generally in a non-database format. Thus, the entries become repetitive and are not available for statistical analysis later.

While some of the ideas that we are explaining here have been briefly mentioned in previous articles (see Multi-Select Dropdown List Box-type Entries for DataWindows and Methods for Faster and Efficient Data Entry in DataWindows), in this article we will be discussing the rationale behind them. These are the general ideas incorporated by us that were helped by the ease of use of PowerBuilder, but may be applicable for all development platforms.

HIMSS Adoption Levels
HIMSS (Health Information Management Systems Society, see http://www.himss.org) has categorized Health Systems Software implementations to various stages with Stage 0 being none and 1 the most base - consisting of only accounts and going upwards to level 7. Each higher level calls for a higher integration of clinical details. While solutions do exist for almost all the levels, the actual adoption is very weak for stage 4 and up (see http://www.himssanalytics.org/). This is the stage when the clinical details and protocols start getting integrated with care. While the usage of adoption levels are discussed for major hospitals, at the level of individual clinics, usage is believed to be far lower.

A sample from the American Medical Association revealed that EMRs were available in an office setting to 17% of physicians in late 2007 and early 2008. Of these, 17% of the physicians with EMR, only 4% were considered to be fully functional EMR systems. [1] While there are many reasons for this poor usage of EMRs, the one that is of interest and pertinent to this article is making the software easy to adopt and use. And limiting user resistance to change is one of the ways.

A shift to EMR usage is required but has still not taken place despite incentives being offered to users by President Obama. The exact reasons for the resistance to such adoption is beyond the scope of this article, but we'd just like to outline some steps to take to eliminate user resistance - what we believe to be a major reaon for this poor uptake.

Reasons why usage of software applications in health care is less than in other fields

1. A higher level of complexity (means developers don't understand the process as well).
2. Relatively fewer numbers of standardized protocols - means a higher demand for customization (easy customization through the PB environment means that a large number of existing applications are created in PB).
3. Most health care professionals start earning at an older age so by that time they are less enthusiastic about doing things in a new and different way
4. A wide variety of specialties means a higher number of customized screens
5. The frequent change in staff and residency programs across departments as well as hospitals, as they are the actual users of the software.

Our Approach
Our development approach, from the start, has been based on the following observations - some of which are more relevant in India.

Doctors, especially the senior ones, have been writing or dictating all their lives. Use of a computer keyboard, mouse or even a stylus is an anathema and does not gel well with their thought process. So:

• The PC screen requires far more attention than the doctor is willing to give it when talking to a patient.
• Security checks and repeated questions ("Are you sure you want to delete -----?") waste precious time.
• Mis-clicks and mistypes are perceived not as mistakes by the person entering data but as genuine problems with the software.
• The learning curve involved in shifting from writing to recording information is phenomenal and a change management approach is required.

While these have been genuine hindrances to getting the medical profession to start using IT, we have tried to provide the users with genuine carrots to induct them into the IT fold. These include:

• Comprehensive and formatted reports of each filled forms as individual (i.e., per patient) copies so that the printout goes out as a complete document
• Ease of use, e.g., intuitive printing of the above
• Auto-typing and default entries
• Single key stroke or select entry of text blocks
• Mass copy of data

These help to make PC-based entries faster than writing. The Unique Selling Preposition or USP we talk about is "A complete record is generated in less time than writing even one page manually." Add to that the benefits of faster and anywhere access to data, duplicate copies on demand anywhere, easy output for research papers and audit reports.

Change Management
Doctors are busy people. For them, any new solution should be completely working from day one. Since IT personnel are unaware of particular health care needs and practices, there has been a frequent mismatch of the final delivery of products viz a viz the need as expressed by the users.

Our change management plan includes presentations and meetings where we emphasize the need as following:

1. Legal requirements make it mandatory to store medical data
   a. It is better stored on a computer.
   
2. There are many repetitive entries where a set of normalized tables can make the job easier
   
3. While a learning curve is there, over a period of time, keyboard entry is faster and better than writing by hand
   a. Ready copies and faster access are add-ons
   
4. Also provide ready outputs for research and audit

Methods we routinely use for our applications

1. Less security
2. Fewer validation checks
3. A less frequent need for manual updates
4. More templates and autotext options
5. Most likely action is default
6. Everything a user needs is put on one screen
7. Individualized screens for every user
8. Longer text blocks allow selects from dropdown or multi select lists

Demonstrating the tabs on one side and multiple related datawindows in a single screen

Recommendations

1. Involve the professionals in the development
2. Be ready for long-term involvement with the client (one of the reasons why health care applications are not as successful is frequent job changes by the developers. Each new developer takes more time to get a feel for the user requirements)
3. Ease of use is required but does not mean easy development.
4. Do not make too many revisions especially once the application is stable (one of the reasons why we are still in PB 9 and recommend Windows XP)

Conclusion
Health care applications are complex and PowerBuilder is the best platform to service its needs (see Table 1). However, be ready for a long-term effort that can be made easier if there is help from IT savvy people in the client's workplace.

Resource

1. Dan Belletti, Christopher Zacke, C Daniel Mullins. Perspectives on electronic medical records adoption: electronic medical records (eMR) in outcomes research. Patient Related Outcome Measures 2010:1 29-37.