In Sri Lanka, lack of co-ordination of surveillance system was identified as one of the major problems. The paper describes a GIS-enabled disease surveillance system that can overcome deficiencies of the existing National Disease Notification System
History of notification of communicable diseases in Sri Lanka dates back to late 19th century. The Quarantine and Prevention of Diseases Ordinance was introduced in 1897 to implement the notification system on communicable diseases in the country. The quarantine and prevention of diseases ordinance and subsequent amendments provides legal provisions for implementation of notification of diseases in Sri Lanka. All medical practitioners (in both government and private medical institutions) who attend to patients with a tentative diagnosis of diseases in the notifiable diseases list should notify the disease to proper authority. The disease should be notified immediately at the time of first suspicion without waiting for laboratory test results or confirmatory tests (Epidemiology Unit-Ministry of Health, 2005). Making the notification at the earliest possible is of paramount importance, thus enabling the field staff to start necessary preventive and control measures immediately.
The traditional paper-based disease notification system followed in Sri Lanka is depicted in figure1
SWOT analysis study carried out by World Health Organization in 2004 on existing disease surveillance system of Sri Lanka brought several important factors to the fore. According to the study, it was evident that current system does not capture morbidity data from outpatient settings and private hospitals. Event for inpatients, a considerable proportion of the cases do not find their way in to the notification system. According to the study, only 37.5% of districts and 55% of hospitals submitted all required reports on time. A review of clinical registers of hospitals showed that Disease Case Definitions are rarely being used in the notification process. The data analysis is almost confined to the central level and other levels are merely transmitting data. Due to inherent multiplicity of reporting channels, duplication of date is inevitable in the manual system. Only 11% of hospitals and 75 % of district surveillance systems received feedback in the form of WER. Inadequate in-service training in surveillance has been identified as a major obstacle in the strengthening process.
Further to the above mentioned weaknesses, it was found that there is no planned routine case-detection mechanism being operated in field level. Another problem highlighted by the survey is the fact that there are, by design, multiplicities of reporting channels. For instance, a case can be reported from more than one institution. This has a potential for duplication if care is not taken to link reports with their respective sources. Lack of coordination of surveillance systems was identified as one of the major problems at district and divisional levels.
Objective of this online notification architecture is to overcome the deficiencies of the existing National Disease Notification System providing computer assisted data collection, data compilation and analysis, data interpretation and feedback mechanism.
Following facts, those highlighted in the SWOT analysis were also considered in designing this web based architecture �
Need for a system of surveillance that not only achieves integrated disease surveillance at the functional level for the various specific disease programmes but also starts monitoring priority non-communicable diseases.
The laboratory system should also be strengthened through networking to be able to contribute to the process of notification.
The surveillance system in Sri Lanka needs to be expanded to include outpatients and community-level case-finding using a suitable mechanism.
The private sector institutions, including private practitioners need to be brought into the ambit of the surveillance system.
A formal system of continuing education and in-service training should be strengthened, and district-level training in surveillance established.
The proposed architecture is a web enable notification system, based on the standard documents used in the notification procedure. Free and Open Source resources (Apache web server, MySQL database engine and Sendmail mail server in Linux environment, Google Maps API and PHP and AJAX) have been used in the development process, in order to facilitate free use of the system by any interested party.
The system has several key components as shown in the Figure 2
Notification data management module has data entry interfaces based on notification forms H544, H411, H411a and H399 used in the manual disease notification (refer figure 1). It also has a duplicate entry management unit which assists system users to query database for duplicate entries, based on the name and the location of the patient and clean or merge duplicate entries. The duplicate management unit uses SOUNDEX phonetic algorithms to index names by sound to maximize the results set by minimizing the effect of minor differences found in spelling people and location names.
Form H544 is the key input interface of the system. It carries the information about the notifying institution and the notifier (medical officer), demographic data of the case being notified, date of onset, date admitted to the institution, the probable diagnosis and laboratory investigations, and the home address of the patient (for public health inspector to trace the patient’s residence). In addition to the above standard information, the electronic H544 form would indicate ICD 10 (International Classification of Diseases) code for each notifiable disease.
Once ICD 10 diagnosis is selected, the electronic H544 automatically provides SNOMED (Systematized Nomenclature of Medicine) codes compatible with the ICD code. SNOMED nomenclature was introduced to the system since SNOMED is more ‘clinical friendly’ coding system than ICD 10. The fact that the SNOMED coding system is widely supported by many other public health information systems enables the proposed system to inter-operate with wider range of health informatics applications. Further to this, Case Classification allows categorization of cases in to ‘Suspected’, ‘Probable’ and ‘Confirmed’.
Notification process is strengthened with automated Case Definitions assistance, since in outbreak investigation majority of the cases reported will have to be dependent on Case Definitions rather than laboratory procedures. When ICD code for the case is selected, system will automatically insert the ‘Surveillance case definition’ in editable manner.
In addition to the standard fields of the form H544, patient’s location can be marked in a Geographical Information System (GIS) bases satellite map. Google Maps API in combination with pre-populated latitudes and longitudes for major cities are used to implement an easy focusing map interface.
Each case reported using the form H544 will be notified to relevant authorities using email alerts, while the data is being fed to the central database. A special reference number will be assigned to all cases notified for future tracking and updating the information (e.g. laboratory investigations). This will ensure confidentiality of patient information.
When a H544 form is submitted, a H411 form with the details of the particular patient is automatically created and can be accessed by an area PHI of the relevant MOH area. PHI can use this electronic H411 form to investigate contacts and confirm the case. Upon submitting completed H411 form by the area PHI, H411a form will be generated by the system and can be completed and submitted to the system by the MOH. When MOH submit the H411a form the details of the form can be accessed by the Central Epidemiology Unit and Regional Epidemiologist for analysis and further actions. If notification process carried out using the electronic forms in the prescribed manner, at the end of each week the system will automatically generate the H399 form and forward for MOH approval. Once approved, the H399 will be available to be analyzed by the Central Epidemiology Unit and Regional Epidemiologist.
Reporting module with its sub-units (plotting library, statistics library, mapping API) is responsible of generating Weekly Epidemiological Return (WER), various charts and graphs and spatial representation of notified cases on satellite maps. Data analysis by each level is facilitated by graphical data representation and basic statistic functions like incidence, attack rates and case fatality rates. Time series heat map based geographical information system are used to visualize the spatio-temporal distribution of disease. The WER generated by the system can be accessed through the Internet and a URL will be emailed to all registered user with a reminder.
Administration module allows customization of the system, user management, ICD 10�SNOMED medical terminology management and case definition management. User management includes assigning ‘trainee role’ to users allowing users to obtain hands on experience on using system. This will provide in-service training which was a major recommendation by the WHO expert group. Further to this, user management module automatically groups users based on districts, Regional Director of Health Services areas and MOH areas.
Functional Elements of Surveillance system comprise of following areas.
Data compilation and analysis
Data interpretation for action
The model notification system architecture possesses all of the above mentioned components. The electronic version of the H544 form has introduced several key improvements. If the age of the patient is less than 18 years, system automatically prompts for the contact details of the guardian. It also introduced the Case Classification of ‘Confirmed’, ‘Suspected’ or ‘Probable’ which is not found in the paper based notification system. Electronic forms have several features to minimize possible variations of patient names, medical terms like automated suggestions and to minimize errors in feeding dates to the system, like pop-up calendars.
The system has the ability to map ICD 10 code to matching SNOMED concept. As shown in the Table 3, a single ICD 10 code might have many matching SNOMED concepts.
With reference to the above issue, database tables which hold the ICD 10 and SNOMED terms have to be designed with a one to many relationship and appropriate normalization levels to avoid data manipulation conflicts.
The electronic version of H544 has the automated Case Definitions assistance as well. When notifier selects an ICD 10 diagnosis, system will automatically add the Surveillance Case Definitions relevant to the ICD 10 diagnosis code in a special editable text area. Figure 6 shows the Surveillance Case Definition for the ICD 10 code B01 (Chickenpox/Varicella), ‘An illness with acute onset of diffuse (generalized) papulovesicular and/or vesiculopustular rash, appearing on the trunk and face and then spreading to extremities, without other apparent cause.’ represented in the electronic H544 form.
It is possible for a notifier to remove inappropriate terms in describing a particular case, and also possible to key in any other signs and symptom to describe the case. In this way notifier can save time needs to feed the notification information and allow reviewers to compare different instance(cases) of a single disease entity(diagnosis) with a minimal set of clinical features.
In mapping cases to geographical locations, pre-populated look-up table has been used to find the nearest latitude and longitude based on patient’s residential address. When entering patients address in house number, road, village/town and city format, Google map will automatically center the map to nearest location, on which notifier can mark the case using provided additional visual clues as in Figure 7.
When latitude and longitude of a case fed to the database, location of the case can be visualized accessing case details as in Figure 8.
Similarly case can be viewed in relation to the cases having same diagnosis in the vicinity of a predefined radius as shown in the Figure 9. This will aid determining the extent of the spread of a disease within a shorter period of time.
Density maps (heatmaps) can be used to visualize the pattern of spread of a disease over a longer period of time (spatio-temporal distribution), as shown in Figure 10.
The system is capable of generating various charts based on the out put of the statistical analysis requested.
Conclusions and Further Work Plan
The proposed architecture could address many of the suggestions proposed by the World Health Organisation team and weaknesses of the current notification system. It was evident that this model can be used to collect and analyze disease notification data within the current disease notification framework functioning in Sri Lanka. The proposed architecture has introduced several new concepts to the system like, GIS based mapping of cases, using surveillance case definitions and SNOMED nomenclature.
It also provide inbuilt facility for data analysis and data export. Automation of report generation and email alerts would be an additional advantage of using the proposed system.
In future improvements of the model, authors plan to include advanced statistical analysis features to the system giving it capabilities to perform complex statistical operations. Further to this possibilities would be explored to adopt Health Level 7 (HL7) standards giving the system more inter-interoperability with other public health information systems.