Design and Development of a Web-Based Saudi National Diabetes Registry

Abstract

Background

Given that diabetes is an extremely common disorder in Saudi Arabia, the National Diabetes Registry was designed by King Saud University Hospital Diabetes Center in collaboration with King Faisal Specialist Hospital & Research Center, Riyadh, Saudi Arabia, in the year 2001. The aim of the registry is to identify risk factors related to diabetes and to provide statistics to public health programs and health care professionals for use in planning and evaluation. The registry was designed to provide information on the extent and nature of specific types of diabetes, diabetes complications, and treatment of diabetes in the Kingdom.

The registry has been available since 2001, with major collaborations from 26 hospitals as part of Phase I in which 100,000 patient data is to be collected on a regional level from Ar-Riyadh before extending the program to other regions of Saudi Arabia.

Methods

The web application was designed using relational database techniques along with on-line help topics to assist users to get acquainted with application functionalities. All Internet forms were designed with validation checks and appropriate messages to ensure quality of data.

The security measures established within the application ensure that only authorized users can gain access to the functionalities of the registry at allowed times. Administrative features were designed to manage the registry-related operations easily.

Results

The diabetes registry has been in operation for almost 10 years, and around 67,000 patients have been registered to date. The Web-application offers an anytime-anywhere access to the registry’s data, removing geographical boundaries and allowing the national registry to provide real-time data entry, updates, reporting, and mapping functionalities more easily.

Conclusion

Merging related information in the form of databases can provide improved health care operations through instant access to data, ease of managing complex data structures, and creation of reports to be used by health care planners and hospital administrators.

Introduction

With the explosion of Internet availability, Web-based applications have become extremely popular, especially in cases where distribution centers are needed to enter, update, and analyze information stored in one centralized place. Disease registries are one of the best candidates for Internet-enabled applications, as they serve an important role in the support, investigation, and application of emerging treatments and technologies in health care and in the study of rare or unusual diseases or treatments.

Diabetes mellitus is one of the most prevalent diseases in Saudi Arabia, affecting children and adults. In the late 1970s and early 1980s, diabetes was not considered a commonly encountered medical diagnosis in Saudi Arabia, even in high risk groups,¹ and among the male Saudi population, the prevalence of diabetes was not different from other parts of the world.² However, this seems to have changed dramatically in the 1990s, as the prevalence of diabetes in Saudi Arabia is now one of the highest in the world.^3,4

Given that diabetes is an extremely common disorder in Saudi Arabia, the Saudi National Diabetes Registry (SNDR) was designed in 2001 by King Saud University Hospital Diabetes Center in collaboration with King Faisal Specialist Hospital & Research Center, both located in Riyadh, Saudi Arabia. The registry includes all patients presenting to all collaborating hospitals. These comprise all Saudi patients, with no age, sex, or nationality exclusion criteria. The registry website can be accessed from http://www.diabetes.org.sa under the national programs tab (Figure 1).

Figure 1.

SNDR website homepage.

Application Website

The purpose of this registry is to be a reliable, valid, and timely information source for diabetes in the Kingdom of Saudi Arabia. The registry’s aim is to identify risk factors related to diabetes and to provide statistics to public health programs and health care professionals for use in planning and evaluation. The registry results are used to investigate the causes and prevalence of diabetes and to develop preventive strategies to decrease the occurrences of these complications.

Methods and Materials

The Web-based SNDR application was initially developed using Active Server Pages 3.0 (Microsoft Corp., Riyadh, Saudi Arabia) as the server-side code and JavaScript 1.4 (Netscape Communications Corporation, Mountain View, CA) as the client-side code. Internet Information Server 5.0 (Microsoft) is used as the web server, and SQL Server 2000 (Microsoft) as the back-end database server to store the registry data. The registry is now under the process of upgrading to Microsoft .net platform, retaining all the existing functionalities.

Patients in the registry are registered using their unique national identification (NID) number. Every institution using this web-based registry is assigned an institution code. This code is used as a key to relate patients to their respective hospitals. The combination of NID number and the institution code uniquely defines each patient and is the primary key within the database design. In the follow-up tables, the follow-up number is recorded in addition to this combination to define uniquely a patient’s visit to the hospital.

The registry was designed to be used nationwide by different hospitals, using the data centralization concept where data is stored in one central database on a Web-server. However, the national users are only able to access, manipulate, and work on the patient data that belong to their respective hospital, thereby ensuring complete segregation among hospitals. The national registrar, however, has access to national statistics for data reporting purposes.

Database Design

The SNDR database comprises 4 main tables and 11 supporting tables. Supporting tables are used to store data that do not change frequently but that still need to be updated from time to time such as the lists of medication or city codes. Relationships among tables are set to ensure data integrity, as shown in Figure 2. The NID number, along with an institution code, uniquely defines each patient in the application and is used as a primary key on various tables. A unique constraint is created on the medical record number (MRN), which pairs with the institution code, so that the same MRN cannot be listed more than once for an institution, thereby avoiding data duplication.

Figure 2.

Diabetes database physical model.

Help Facility

An intensive online help facility is available for all users to acquaint themselves with the features and usage of the registry application.

Data Security and Integrity

By logging-in to the application, the users understand that the information in the system is confidential and that they agree to use this information only for the purpose of providing health care and research services. User logins and passwords identify each user of the application. Unique user logins are assigned for each hospital. These unique identifiers provide restricted access to various components of the SNDR.

The application encrypts the password at the time of login using the MD5 message-digest algorithm (RSA Data Security, Inc., Bedford, MA). MD5 is a message-digest hash algorithm that is used for validation and verification of message integrity. It creates a highly unique 16-byte (128-bit) digest from a set of data that are almost impossible to recreate without the same exact input data.⁵ The users of the registry are assigned nine different authority levels in the current application (Figure 3), which can be associated with a time period when they will remain valid. The users with read-only access (levels 1 and 2) cannot enter data into the system. They are only allowed to view the data. The users with write permission (all levels except 1 and 2) can enter data into the registry. Only the registrar has full access to all the registry features including the Administrative Page. None of the users have access to the administrative functions other than registrars. Therefore, the terms registrar and administrator are used interchangeably for our application. User levels 1–7 can be considered as common user levels with various authorities and level 8 as the administrative or registrar position. Every hospital has registry users with different user levels. There is no limitation on the number of users for any user level including registrar level. The only requirement is that registrars should have detailed background knowledge about diabetes, and that all users should be trained well on the use of the registry based on their user levels.

Figure 3.

User levels and privileges.

The browse-only user access is usually provided to researchers and hospital administrators for browsing charts, search results, and annual reports. A patient’s identifiable information is not accessible to browse-only users, but rather statistics and counts only.

There is an additional user level, namely, national registrar. This level is not explicitly mentioned in the application, rather controlled within the programming code. Only one user is allowed to be at this level. This national registrar can access registry data of all participating hospitals and can create registrar accounts for each hospital. These registrars can then create users for their individual hospitals.

Another security measure to protect sensitive data is the inclusion of the cookie set-up procedure that needs to be carried out by the registrar of the registry for each individual user’s computer. Before setting up the cookie, the web browser should be enabled to accept cookies. The user’s full name, user ID, and cookie set-up password, which is known only to the registrars, are required to complete the cookie set-up process. The user can access the login page of the registry after a successful cookie set-up. The user must provide the exact user name and password assigned to him/her by the registrar to login successfully into the registry. After a successful login, the user can use the registry features according to the defined authorization level.

No users can bypass these security levels. Security checks are performed before each Web page is shown to the user. The user is redirected to a warning page with an appropriate message if he/she is not authorized to access that particular page. If, while using the application, a user exceeds his/her time limitation, then the user’s session is abandoned by the application automatically.

For each user session, the user ID, institution code of the user, access start and end times of the session, and the PC identity, which is used for the accession, are recorded in the LogAccess database table. Only the registrar can view the LogAccess information periodically or as the need arises. This feature is accessible from the administrative section and enables registrars to track registry usage. Similarly, the deletion of records by any authorized user is also recorded in the database for any future reference.

Within the SNDR Web-based application, every form has been designed with various data validation checks and warnings. JavaScript client-side scripting language is used to provide this interactivity for the data entry and update processes.

Database stored procedures are used heavily in the application for fast database operations. The compiled nature of stored procedures gives the application a performance boost, as the whole application is database driven.⁶

Web Forms

This section features a sequence of Web forms and functionalities that are in use by users from 26 participating hospitals. More than 67,000 patients’ data have been entered and validated to be used for analysis and reporting.

The users can enter a new patient by entering the NID number or view an existing one by entering either a NID number or MRN (Figure 4). When the user enters the NID number, the application checks the existence of the record in the database. If it finds the record, then control is redirected to the patient main page. Otherwise, a blank Demographics Form for a new record entry is presented to the user.

Figure 4.

Application’s Main Page.

Within the application, data recorded for each patient is divided into the following categories: Demographic, Diabetes Status & Family History, Treatment and Complication Forms. Data pertaining to these forms are entered into the system and can be easily updated as necessary. Figures 5–9 are screen shots of these data entry forms in order of their actual sequence.

Figure 5.

Patient Demographic Data Form.

Figure 9.

Patient data page.

Figure 6.

Diabetes Status & Family History Data Form.

Figure 7.

Treatment Data Form.

Figure 8.

Complications & Associated Diseases Data Form.

Each category of the follow-up information is recorded consecutively. The application gives every new follow-up visit an auto-incremented follow-up number. As the user starts entering data for follow-up, all the forms appear in a sequence starting from Family History to Complications. All follow-up forms have the same follow-up number and date recorded for them.

Data from each form are collected by the interviewer and then entered into the system. The person who collects data and who enters it into the system can be the same or different user. Therefore, the system records the names of both the interviewer and the data entry personnel along with the date of each entry. This information is featured at the bottom of each data form as dropdown lists, which are populated from the users database table. Because each user is associated by an institution code in this table, the dropdown lists contain only those users who belong to a particular hospital.

In the application, all related patient information can be accessed from the patient’s main page (Figure 9). From this page, various actions, can be performed, such as changing the status of the record from pending to valid or vice versa, or deleting either the entire record or individual follow-ups of a patient. The New Record button on this page allows users to add a new patient to the registry. All patient data, including follow-ups, can be updated from this page. The format of the hard copy data collection form is maintained on the Web-based application forms to facilitate data entry.

Results

The data entered using the Web forms just described allow users to query the database using chart and search facilities described here.

Distribution Charts

Distribution of database variables, such as gender, type of diabetes, marital status, type of treatment, and complications, can be generated in the form of frequency tables and charts. Internet Chart FX 6.0 (Software FX, Inc., Boca Raton, FL) software is used for the creation of these charts on the server side. This is a dynamic charting tool that allows users to modify the appearance of the charts, providing flexibility in data presentation. The type of chart display can be changed from the dynamic chart menu (Figure 10).

Figure 10.

Chart result page.

Search

An extensive search facility is provided in the registry. This feature allows users to filter registry data by specifying search criteria, which can be defined as any combination of database variables (Figure 11).

Figure 11.

Search page.

The search results are listed in a table format, with the total count of resulting records at the top of the report page. The pagination technique is used for the display of information. The resulting table consists of the NID number, MRN, serial number, and names of the patients along with a link to the patient’s data page (Figure 12).

Figure 12.

Search results.

Administrative Features

In addition to querying the patients’ data, the application is capable of performing administrative tasks such as annual reports generation, transfer of patient files, data export, log access listing, and creation of new users and assignment of user rights (Figure 13).

Figure 13.

Administration Page.

Supporting tables of the registry database are used to store lists of important information including medication codes, cities, hospitals, regions, and users. This information does not change as frequently as the patient data. Still, there might be times to update the contents of these tables. This facility to add/update these supporting tables is available through the administrative section “Update Tables” menu.

Date Dependent Reports

A set of reports based on the start and end dates generates information, such as count of records entered by an employee, for administrative purposes (Figure 14).

Figure 14.

Administrative reports page.

Yearly Cross Tabulation Reports (All)

This report facility generates data for all the hospitals for each year, with total counts and column percentages distributed by gender (Figure 15). There are around 46 cross-tabulation reports.

Figure 15.

Annual reports page.

Data Export

In the export section (Figure 16), the registrar is given the option to export individual tables into text delimited format, ready to be analyzed using any commercially available statistical package. Export can also be performed for the data filtered by the user-defined criteria. File Manager Software (Soft Artisans Inc., Watertown, MA) is used for the export facility.

Figure 16.

Export Data page.

Transfer of Patients

The SNDR is a national registry and might receive a request at some point to transfer patient files to another hospital. This facility allows the registrar of one hospital to transfer a patient file to another hospital (upon request). This reduces the amount of time to re-capture patient data and at the same time ensures uniqueness of patient data across national hospitals. All transfer requests are automated with a click of a button along with email notifications (Figure 17).

Figure 17.

Patient Transfer Form.

Geographical Information System Functionalities

One of the important variables for data collection for the clinical registries is the place of current residence and hometown area. This information collected makes spatial data more available and is envisioned to project more interesting findings with respect to a patient’s place of current and past residence.

The SNDR has a built-in geographical information system functionality, where users and researchers can query the nonidentifiable live patient data in the form of maps. Several maps, which follow, are designed to show the patient’s distribution on regional and city levels along the line also providing comparison of diabetic complications, treatment, and diabetic population. Figure 18 shows the registry page, listing all possible maps available with a click.

Figure 18.

Maps generation feature within the SNDR.

GSI software ArcIMS 9.2 and ArcMap 9.3.1 (ESRI, Riyadh, Saudi Arabia) are used for the design and publishing of all maps. An open database connectivity is used to establish connection with the registry database residing on the web server. This allows real-time data projection using ArcIMS and Arc Publisher (ESRI) software.

The SNDR project is under Phase I, with major collaboration from the hospitals of Riyadh Region. This is apparent from the following maps (Figures 19 and 20), where highly registered cases are coming from the city of Riyadh and in general from the Ar-Riyadh region.

Figure 19.

City-level distribution of patients on diet treatment.

Figure 20.

City-level distribution of type 2 diabetes.

In addition to the published maps, a query tool was designed for free selection of variables. This is shown in Figure 21.

Figure 21.

Map query tool.

User defined queries on the right panel of Figure 22 allows users and researchers to select parameters and to see the live results from the database. Highlighted cities indicate the presence of patients with a specific type of diabetes.

Figure 22.

Map showing query results at city level.

Clicking on the city identification displayed in the resulting table lists all patients from that city and their demographic details, as shown in Figure 23.

Figure 23.

Demographic Results page.

Conclusions

The use of the Internet-SNDR (http://www.diabetes.org.sa), where all the data are centralized and real-time, gives physicians and other health care professionals continuous insight information of the disease and the medical care dynamics. This helps in reporting statistics to the ministry of health and highlighting the problem areas for the action plan. This action plan may include the availability of various drugs in the dispensaries, preparation of national guidelines for the management of diabetes patients, and preparation of training and educational programs for improving the lifestyle of the people.

Glossary

Abbreviations

(MRN)

medical record number

(NID)

national identification number

(SNDR)

Saudi National Diabetes Registry