Introduction

Medical record systems are an essential component of clinical care. Substandard quality records can compromise the quality of medical care. Traditionally, medical records have been handwritten or typed, but the widespread availability of modern information technology (IT) has increasingly allowed for digitization of medical records. The implementation of electronic medical record (EMR) systems may improve the quality of documentation by improving legibility and standardizing the clinical data recorded. For the comprehensive implementation of an EMR system, a health care institution must be fully digitized. This requires significant infrastructure, which is often lacking in the developing world. A registry is distinct from a medical record system as it records data for research purposes and does not directly affect patient care. Registry data are typically captured at the end of the patient’s stay in hospital, a system referred to as back-end capture. The medical record system, however, is an example of a front-end data capture system.

We previously reported on the successful development and implementation of a metropolitan electronic surgical registry (ESR) in the city of Pietermaritzburg, South Africa [1]. This ESR acquired data at a single point in time at the end of patient care. In that previous study we proposed a number of potential improvements to the information system. They included the acquisition of data at multiple time points during the process of care, such as at admission, operative intervention, endoscopy, and discharge. The production of printed medical records at each of these points of data entry would integrate the distinct functions of an ESR and the EMR system.

The current report documents our experience with an electronic information system that integrates the distinct concepts of an EMR system, an ESR, and a clinical decision support system (CDSS). In light of the significant infrastructure required for implementation of a complete EMR system, we opted to develop a so-called hybrid EMR (HEMR) system, which could combine digital and handwritten notes. Electronic data entry would take place at key points during the process of care. At these points, a computer-generated printed record would be created and added to the patient’s hospital folder. All other notes, including daily assessments on ward rounds, would be handwritten in the file. This combination results in a hybrid medical record system, which includes both electronic and handwritten records.

We attempted to take this innovation further by using the front end point of entry as a mechanism to both generate medical records and set up and populate a registry. An additional objective was to create a CDSS that guides junior staff down appropriate clinical pathways. This is based on the educational principle of forcing clients to make an observation and thereafter forcing them to respond to the observation. For example, the client who enters deranged physiologic variables into the HEMR system would receive a warning alert on the computer screen describing the abnormality. Theoretically, this would force the client to respond to this recorded derangement. It was hoped that this would result in a unique system that combined an EMR system for clinical care with an ESR for research purposes.

Methodology

The components of an effective EMR system are infrastructure, software, human factors, and ergonomics. If any of these components are ignored in the developmental process, the success of the information system might be compromised. The process of implementing the HEMR system was broken down into a number of phases based on the classic strategic planning process of analysis, synthesis, and implementation [2]. Following its implementation, we examined the efficacy and quality of the HEMR system by assessing the compliance rates of data capture. Ethical approval to construct and implement the HEMR system was obtained (Biomedical Research Ethics Committee number BCA221/13). Once the project was ready for its pilot phase, we implemented it within the Pietermaritzburg Metropolitan Department of Surgery based at Greys Hospital, Kwazulu-Natal, South Africa. This hospital provides a tertiary level of surgical care for general, pediatric, and trauma patients.

Analysis

The first phase involved establishing patient selection criteria and data points. For the purposes of this HEMR system, patient inclusion was limited to those requiring tertiary hospital admission because of general, pediatric, and trauma-related surgical pathologies. The project planned to capture data at multiple points of patient care: at the time of admission, operative intervention, endoscopic intervention, adverse events (morbidity), and end of patient care (discharge, transfer, or death). The following data points were included into the design.

Admission

  • Patient demographic details (name, surname, ethnicity, sex, age)

  • Time and date of hospital presentation

  • Vital signs on admission (pulse, respiratory rate, blood pressure)

  • History and clinical examination

  • Resuscitation fluid type(s) and volumes

Discharge

  • ICD-10 classification of surgical pathology

  • Investigation modalities

  • Investigation results

  • Outcome

  • Discharge summary

Operative details

  • Time and date of surgery

  • Method of anesthesia

  • Duration of surgery

  • Operative access

  • Operative procedure(s)

Adverse events

  • Time and date of adverse event (morbidity)

  • ICD-10 code for adverse event (morbidity)

These data points, together with the basic architecture, were initially designed as a blueprint (on paper). This blueprint included plans to capture data pertaining to the aforementioned data points through both free text and predesigned dropdown menus. As an example, data such as ethnicity, sex, time, date, mechanism of injury, operative procedure, and outcome would be entered by way of predesigned dropdown menus. Data relating to the discharge summary and vital signs would be entered as free text.

Synthesis

The second phase of the project involved translating the HEMR blueprint into a digital format. FileMaker Pro 11 (IT Solutions, Philadelphia, PA, USA) is a commercially available cross-platform database application that has previously been used to create surgical registries. This was our chosen software platform on which to perform the necessary development.

The aforementioned categories of data were designed as a relational database. A relational database is a collective set of multiple data sets organized by tables, with well-defined relations. The design of registry tables and their relations is referred to as the “data model.” The data model is the core of any EMR system. The design is usually driven by the functional requirements of the information system. The benefit of a relational database data model over a simple flat file (or single table registry) is the ability to create unique, one-to-many relations.

Patients entered into the HEMR system (relational database) were automatically assigned a reference identification (ID) number. The patient’s unique reference ID number, name, surname, sex, and birth date were entered into a parent (primary) table. A number of child (secondary) tables are related to the parent table. For this particular information system, six tables were designed: general, pediatric, and trauma surgical tables for admissions and discharges; an operative table for all operative interventions; an endoscopy table for all endoscopic procedures; and a morbidity table for adverse events (Fig. 1).

Fig. 1
figure 1

Data model illustrating the relational database design

Full size image

For simplicity, all trauma-related surgical pathologies were entered into the trauma table (irrespective of patient age). Non-trauma-related surgical pathologies were categorized into the general and pediatric surgical tables based on patient age. Patients <13 years of age were classified as pediatric. These six tables were created as child tables, relating to the parent table (Fig. 1). This design prevents duplications by ensuring the ability of a single patient entry into the parent table to have a potentially unlimited number of admission and discharge, operative, endoscopic, and morbidity entries.

Using the aforementioned software platform, the data model design was expanded into a series of digital layouts, which collectively constituted the HEMR system interface. Navigation buttons were included on the interface to facilitate easy interaction and simplify the process of data entry. Structured data are entered using dropdown menus and check boxes, although clients also have the option of entering free text into text boxes. A menu system was used to prompt the client to enter data. With reference to the dropdown menus, the client selected a choice from predesigned value lists. These value lists applied to options such as operative access and operative procedure. These lists were comprehensive and designed to convert narrative data into a discrete data point. When the client selected the “referral center” box, a dropdown menu appeared listing multiple satellite clinics and hospitals as options. The option “other” was included in all dropdown menus and, when selected, provided the client the opportunity to enter data in free text. Figures 2, 3, 4, 5, 6 and 7 illustrate selected screen shots of the various registry layouts.

Fig. 2
figure 2

HEMR system interface (prior to committing record and data locking)

Full size image
Fig. 3
figure 3

HEMR system interface (data committed and locked)

Full size image
Fig. 4
figure 4

HEMR system interface. General surgery admission interface

Full size image
Fig. 5
figure 5

HEMR system interface. Operative intervention interface

Full size image
Fig. 6
figure 6

HEMR system interface. Morbidity entry with ICD-10 search engine

Full size image
Fig. 7
figure 7

HEMR system interface. General surgery discharge interface

Full size image

The design of the HEMR system included automated clinical reports for the purpose of weekly departmental morbidity and mortality meetings. Data and statistics within these reports included the total number of surgical admissions and discharges, operations, morbidities, and deaths captured on the HEMR system during the relevant week.

Computer hardware specifications were considered following the construction of the data model. Fifteen desktop computers were collectively positioned within the emergency department (ED), endoscopy suite, operating theater (OT), surgical wards, and offices. Windows 7 Professional (Microsoft, Redmond, WA, USA) was the operating system installed on the machines. Technical specifications of the computers are described in the Appendix. Local network connectivity enabled multiple client access to the registry without conflicts.

Implementation

There were two components to implementation of the HEMR system: client training and human factors engineering.

Training

A training program was initiated for clients involved in the use of the HEMR system. Clients included all rankings of medical doctors within the general, pediatric, and trauma surgical teams. Allied health staff did not play any role in the use of the HEMR system.

Training included an introductory lecture, followed by personal training. The introductory lecture provided visual interaction with the HEMR interface. The lecture took place every 4 months for nonpermanent staff members. Thereafter, the clients received training in a computer laboratory. Eight clients received training by the developer at each session within the laboratory. Each client was allocated to a computer with a preinstalled copy of the HEMR file. During the training session, all clients were given the following tasks.

  1. 1.

    Create a unique patient ID

  2. 2.

    Enter and complete a surgical admission

  3. 3.

    Enter and complete an operative entry

  4. 4.

    Enter and complete an endoscopic entry

  5. 5.

    Enter a morbidity entry using an ICD-10 search engine

  6. 6.

    Complete a discharge summary including ICD-10 classification of disease

Following completion of the computer laboratory teaching session, each client received an instructional paperback guide.

Human factors engineering and decision support

Prior to the development of the HEMR system, we designed and implemented a standardized paper-based tick-box style admission document. This document was used for admissions of all surgical patients. Decision nodes were incorporated into its design and aimed to elicit an interpretation of patient data pertaining to oxygen saturation, blood pressure, core body temperature, and level of consciousness. Based on the data entered on the document, the decision nodes questioned the presence or absence of a threatened airway, the need for supplementary oxygen, and the presence or absence of shock or hypothermia. An audit of 100 surgical admission tick-box documents was performed. Errors of recognition of pathology data were evident from the audit results. In 1 of 14 (7 %) cases of documented hypoxia, 4 of 7 (57 %) cases of documented shock, and 3 of 7 (43 %) cases of documented hypothermia, the data were incorrectly interpreted as representing normal physiology. Considering these results, a CDSS was incorporated into the design of the HEMR system. Following documentation of a saturation level of oxygen in hemoglobin (SaO2) of <90 %, the presence of a systolic blood pressure of <90 mmHg, or a mean arterial pressure of <70 mmHg (in adult patients), a core temperature of <35 °C, or a Glasgow Coma Score of ≤8, these data would automatically trigger a visual alert describing the pathology and provide suggested practical steps to be followed. A screen shot of the “shock alert” is shown in Fig. 8.

Fig. 8
figure 8

Decision support alert notifying the presence of shock

Full size image

Quality control

The HEMR file was uploaded via a host computer onto a secure server. Separate usernames and passwords were created for both administrator and client access. Administrator access was set up with unrestricted privileges. This enabled the system administrator to monitor the activity of all working clients, edit accidental entries, and rectify errors. This facilitated the administrator in the process of data aggregation, validation, and analysis. Client access was limited to data entry only. Automated hourly backups of the HEMR file were integrated into its design for the purpose of data protection. The data entered into the HEMR system were analyzed and validated on a weekly basis. The developer and a co-administrator completed any omitted data. A daily copy of the file was exported onto an external drive and stowed in a secure electronic safe for data protection in the event of fire damage to the host computer.

Efficacy

The efficacy of the HEMR system was analyzed after 3 months. The data entered were exported onto a series of digital Microsoft Excel spreadsheets. The quality of the data entry was assessed by establishing a compliance rate for each discrete data set.

Results

The HEMR system was officially implemented on January 1, 2013 at Greys Hospital. A quarterly annual audit of the months of January, February, and March 2013 was performed. Over the 3-month period, 1,114 surgical admissions were entered into the HEMR system. Male patients predominated: 647 (58 %). Overall, 937 (84.1 %) were Black, 91 (8.2 %) Indian, 62 (5.5 %) White, and 24 (2.2 %) were of mixed race. The 1,114 admissions included 597 (304 elective, 293 emergency) general surgery admissions, 329 (13 elective, 316 emergency) trauma admissions, and 188 (89 elective, 99 emergency) pediatric admissions. There were 708 (64 %) emergency and 406 (36 %) elective admissions. A total of 605 surgical operations were performed, including 182 (30 %) elective, 70 (12 %) semi-elective, and 353 (58 %) emergency operative procedures. Altogether, there were 44 (3.9 %) adverse events (morbidities) and 48 deaths (4.3 %) over the 3-month period. An audit of the compliance of client data entry was performed on the following data points: date of admission, patient surname, temperature, respiratory rate, blood pressure, pulse, completion of admission and discharge documents, operative data (when relevant), diagnosis, and patient outcome. The average compliance was 98 % (range 87–100 %). Table 1 illustrates the compliance rates for each of the aforementioned data points.

Table 1 Client data entry compliance rates
Full size table

User satisfaction

A questionnaire was designed for the purpose of client feedback. It included 10 questions relating to the clients’ impressions of the HEMR system. The target population included 50 surgical interns. Questionnaires were circulated to the first 50 clients, and all were completed and retrieved for analysis. All participants were directly involved in the use of the HEMR system. Overall, 92 % of the clients considered themselves at either an average or an above-average level of experience with IT (Table 2). In all, 78 % of clients had no previous experience with an electronic registry or EMR system. None considered the quality of the HEMR design as poor or very poor (Table 3). A single client considered the ease of navigation difficult, with 72 % considering the data entry process easy (Tables 4, 5). The ease of searching and finding criteria in the dropdown menus was assessed. The majority of clients were able to find the criteria they sought up to 80 % of the time (Table 6). The majority of clients required minimal senior support during data capture (Table 7). The average time to complete an admission entry was 13 min (range 5–30 min). The average time to complete a discharge was 10 min (range 4–20 min). In all, 96 % of clients preferred the new HEMR system for its improved legibility, ease of retrieval, and faster processing. Only 4 % of clients preferred the former system of handwritten admission and discharge documents. This response was due to their preference of writing over typing. The majority (96 %) believed the HEMR system was more productive than the previous paper-based system.

Table 2 Clients’ prior computer experience
Full size table
Table 3 Clients’ rating of HEMR system design
Full size table
Table 4 Clients’ rating of ease of navigation
Full size table
Table 5 Clients’ rating of ease of data entry
Full size table
Table 6 Incidence of successful criteria searches
Full size table
Table 7 Incidence of requirement for senior support
Full size table

Limitations

Underreporting of adverse events (morbidity)

During the 3-month period, 44 adverse events (3.9 %) and 48 deaths (4.3 %) were recorded. Although we have no previous comparative system in place to monitor the frequency of adverse events, this value may be falsely low because of underreporting. In recognizing this limitation and to facilitate improved surveillance of morbidity, we have since designed a standardized paper-based document for completion on all surgical rounds. The document includes a check-box for the presence or absence of morbidity for every patient assessed. Consultants and senior registrars identify and record new morbidities following the daily ward rounds. Once a morbidity is documented on the paper-based document, the client proceeds to enter the adverse event in the HEMR system. This adverse incident reporting feature has now been incorporated as a departmental quality improvement initiative to improve morbidity surveillance. Since the inception of this policy, the prospective collection has escalated to a total of 624 (14.9 %) adverse events over 11 months. A similar adverse events reporting system described by Bilimoria et al. [3] appeared to have comparable incidences of morbidity in a tertiary surgical department. We are reviewing the electronic hospital records of all patients at discharge to identify any unreported adverse events, which are then added to the HEMR retrospectively. We plan to compare the incidence of prospectively and retrospectively recorded adverse events in a future study following completion of 12 months of data collection. This will enable us to provide a numeric for the degree of underreporting by clients.

Power failure

In one instance, a power failure compromised the active status of the host computer (hosting the HEMR file). This event resulted in the temporary inability of client computers to access the HEMR system. A simple solution to this problem was to connect the host computer to a power source protected by the hospital backup-generator. Although client computers not connected to this source would temporarily lose power, once repowered and running, the file would still be available on the network, as the active status of the host computer would not be compromised.

Weaning off an old system

At the time the HEMR system was implemented, several patients were already within the hospital system (admitted by the old method of handwritten admission documents). To avoid confusion and patient mixing, new patients were identified by the presence of a yellow sticker with the unique reference ID number. The absence of a yellow sticker with ID number indicated an admission under the old system. These patients were discharged according to the old system of handwritten discharges. This would continue until such time that all patients admitted via the former system had worked their way out of the hospital system.

Lock mechanism for registry control

A mechanism to prevent clients scrolling through all patient records in the HEMR system was integrated into the design. Following the creation of a reference ID number, the client followed a set of illustrated instructions with a programmed mechanism to commit and lock the data into the HEMR. This mechanism prevents future manipulation of data by the clients. This mechanism is illustrated in Figs. 2 and 3.

In addition, the access of clients was limited to working on a single patient record at any one time. Scrolling through multiple patient records was not possible. This mechanism provided for patient confidentiality and prevented the possibility of accidental data entry into incorrect patient records.

Administration

Administration of the pilot HEMR system was dependent on two specialist clinicians (surgeons). Because of financial and resource limitations, designated staff could not be independently recruited and employed for the processes of training, data aggregation, and data cleaning. Although these administrative requirements were successfully managed during the pilot, a more sustainable strategy involving the support of additional clinical staff is planned for the near future. This strategy will aim to ensure the long-term sustainability of the HEMR system.

The overall compliance with data entry was good, with an average compliance of 97 %. This is a significant improvement on the average compliance of 80 % in our former electronic trauma registry [1]. We believe this success is explained by the incorporation of this system into the process of clinical care.

Costs

The estimated costs required for the computer hardware and software for this project, were ~150,000 South African rands ($15,720). No further fees were required for external technologic support or added human resources.

Discussion

Electronic medical registries are integral to systems improvement. There are a number of registries in the developing world that have predominantly focused on the management of infectious diseases, maternal and child health, and trauma [4–7]. The United Nations (UN) and the World Health Organization (WHO) have highlighted the need for accurate basic data relating to public health issues and diseases in the developing world.

The effective use of clinical information systems has provided data that have resulted in innovative progressive legislation and prevention programs in the developed world. It has also allowed critical analysis of the effectiveness of surgical systems. The lack of information on the burden of surgical disease in the developing world has generated much interest in the development of surgical registries. In North America the National Trauma Data Bank is the largest aggregated trauma registry ever assembled, but the resources required to create and manage such a system are beyond the reach of most developing world countries.

Our initial publication on the development of a trauma registry in our metropolitan complex demonstrated the feasibility of such an information system in a low to middle income country such as South Africa and the benefit in terms of the generation of quality data [1]. We have managed to build on our initial experience and developed an effective, simple, unique HEMR system.

Clinical information systems that attempt to be exhaustive become excessively burdensome, leading to clients incompletely entering data, resulting in major deficits. With this consideration, designers need to decide on the minimum data set they plan to collect. This data set must cover the most relevant sets of data. The Surgical Audit Board of the Royal Australasian College of Surgeons has drawn up a list of essential data that need to be captured [8]. The design of our data criteria included the minimum data set published in the Surgical Audit and Peer Review Guidelines in 2002.

The ergonomics of a system are vital to its success, and we attempted to integrate the system into the daily work routine of surgical staff. Any data entry that increases the workload rather than facilitates it is difficult to implement. There must be an immediate task-based reward for a successful system. In this system, it was the printed patient note, which went into the patient file. Despite this, the development of mechanical lock-out systems was important. A mechanical lock-out system prevents the client from proceeding with his or her designated task until a certain step is included. If it is used excessively, it results in increased levels of frustration without any improvement in the quality of the data entries. The admission of surgical patients requires a printed admission record. This ensured that all admissions were processed electronically. Similarly, all operative procedures required a printed operative record prior to release from the theater complex. Finally, patients could be issued discharge medication only if a printed discharge summary was produced using the HEMR system.

Ongoing monitoring is required to ensure quality control. The ability of the system administrator to view data entry in real time and to review the previous 24 h worth of entries was an essential component of quality control. Quality control remains an ongoing task and needs attention on a daily basis. Currently, it is the responsibility of two clinical staff members. A more sustainable strategy must be developed to ensure long-term continuation of the administration of the HEMR system. Despite its design and planning, limitations referring to imperfect compliance rates have been objectively measured (Table 1). We recognized the problem of underreporting adverse events (morbidity) and implemented a strategy to ameliorate this limitation. We plan to report on the success of this intervention in a future study.

Conclusions

We concluded that it is possible to construct and implement a unique, simple, cost-effective HEMR system in a developing world surgical service. This information system can be implemented in existing developing world institutions without nullifying existing paper-based patient records. Strategic planning, preparation, and execution of this project were essential to achieve the present level of success. Audits for the purposes of quality improvement initiatives are now possible. Limitations to the HEMR system have been identified. They have included the need to improve accuracy in the reporting of adverse events and develop an administrative strategy to ensure the long-term sustainability of this unique information system.