The Colloquim was conducted by Nuwan Waidyanatha from China while Chamindu Sampath projected the slides at LIRNEasia.

Introduction to research

The project is taking place in Kurunagala and Tamil Nadu. In 24 health sub centres and 4 public Helath Centres in Tamil Nadu and in Sri Lanka in 12 Hostpitals

Disease infomation

• The system architecture
• Determinants of Morbidity in India
• Determinants of notifiable diseases in Sri Lanka

RTBP Communication Technology

• mHealthSurvey mobile application
• T-Cube Web Interface
• Sahana Messaging/Alerting Module

mhealthSurvey Shortcomings

• Certification exercises
• Signal to Noise Ratio
• Real-Time vs Off-time
• Semantics and syntax
• Cost benefits

Objective of the Research

The basic objective was to see if we can collect data and detect and report the outbreaks.

Specific Objectives:

• Evaluating the effectiveness of the m-Health RTBP for detecting and reporting outbreaks
• Evaluating the benefits and efficiencies of communicating disease information
• Contribution of community organization and gender participation
• Develop a Toolkit for assessing m-Health RTBPs

The Data collection is done by Health workers and goes through the mHealthSurvey mobile phone software to the Epidemiologist for spatial and temporal analysis done using T-Cube Web Interface before going to the Sahana Alerting Module Interface and then agian to the health workers.

A sequence analysis of the functions that is happening and their was no purpose but a formal process. By using technology we can use the information is transfers more efficiently. In India the delay is minimised to minutes from 7-30 days. In Sri Lanka from 15-30 days into minutes.

RS: Amount of data has to be reduced with this?

NW: The answer is NO

SL: In Sri Lanka process the technology is jumping several steps?

NW: Because of the number of people visiting the doctors and the doctors do not get the chance to diagnose . And with this process most of the unnecessar repetitive procedures are omited. Hence we can jump (Please see the slides attached)

Regarding the mHealthSurvey software design. It’s built on Java 2 Micro edition and works  with CDC 1.1 and above (JSR). It works with MIDP 2.0 or above and use GPRS to transfer data. The software is tested on Nokia3110c, Motorola SLVR L7, Gionee v6900. Amoi A636, Sony Ericsson s302c.

The application also helps the health worker to enter the records accurately, said Chamindu when demonstrating the software.

Data collection process is done when the patient comes and meets the nurse, nurse gives a diagnosis chit which will be filled by the nurse and the doctor will fill the chit with diagnosis and treatment, then the data entry officer will digitized the data and submit. In Sri Lanka it’s real time but in India after working hours.

RS: Can they read the hand writting?

CS: Yes most of the are pharmacist , so they can read the doctors hand writing.

T-Cube Web Interface [Auton Lab] give the following features

• AD Tree data structure
• Trained Bayesian Networks
• Fast response to queries
• Statistical estimations techniques
• Data visualization over temporal and spatial dimensions
• Automated alerts

The software also generate the Epidemiological  report instantly, when regular database take days to generate.

Messaging/Alerting CAP/EDXL Broker [Sahana] – The feature

• Single input multiple output engine; channeled through multiple technologies
• Manage publisher /subscribers and SOP
• Adopt PHIN Communication and Alerting Guidelines for EDXL/CAP
• Relating the template editor with the SMS/Email Messaging module
• Do direct and cascading alert from a regional jurisdictional prospective
• Designing short, long, and voice text messages
• Addressing in multi languages

People are actually using this to send alerts. The detect the disease and the doctors who are responsible will have to send the alert to respective individuals. Currently it have short and long Common Alerting Protocol (CAP) messages. In future it will adopt voice CAP messages to send messages.

SL: What is someone hacked and send wrong information?

CS: We also do comprehensive message. The health workers are trained on how to act on suspicious messages.

NW: Sender name, Source will make the receiver to verify the alert.

RS: This is something to mention as this shows that we are not behaving like a normal project based organization but we are connecting and building on the project. Also what is the level of the person who can issue alerts?

NW: Medical officer of Health, Regional Epidemiologist, and Public Health Inspector

Evaluation metric verticals and horizontals

• Three verticals – data collection, event detection and reporting
• Four layers – social, content, application, Transport
• Arrows showing the Interoperability between layers and verticals
• Objectively assess by calculating various indicators: costs, efficiencies, error rates, etc
• Subjectively assess through interviews and simulations

SL: Perhaps the social level should be changed?

RS: Should be user level

NW: Social looks at more institutional problem

RS: then make it institutional

A small certification exercise was done. It was benchmarked against a standard that was derived, with Sri Lanka and India regarding the use of the software. And accordingly they were certified on their ability to use the mhealthsurvey. Sri Lanka was better and most in India they failed. However now they should be quite efficient as it’s being a year.

Signal and noise ration: In India the noise is very low and data was clean.  and during holiday there were no data. In Sri Lanka there was a friction.  However we managed to get the approval and the data came in. And with lot of pushing the data came in but lot of noise in the data. agian in the holidays no data came in.

Off-time vs Real-time: Real time is when people will be sending the data at least within the day. In India most of them do send the on the same day but most of the occasion they send it the next day. In Sri Lanka the Health workers did not want to disturbed when at work. Hence they did it in the afternoon.

There were problems in terms of entering the data. As they make mistakes and enter other symbols. Also local language (they use different terms) , UK/USA spellings,  different adjectives are few problems regarding entering the data.

mHealth dala collection lessons as a  summery

For India

• Nurses sending data
• Near zero noise because impacts their work
• No time to enter data patient care  and routine work comes first
• Under reporting to avoid extra work
• Improvise mHealthSurvey for collection and reporting of other
• Older slow to learn
• No prior experience beyond voice
• Resolve technical problems on their own
• Replaced handsets on their own

For Sri Lanka

• Outsourced data entry clerks
• No incentive because 1) lack of knowledge 2) not direct impact
• Data entry is their only job
• No strings attached with reporting quantity
• Nothing like that
• Young were quick to learn
• Knew all capabilities of mobile
• Resolve technical problems on their own
• Replaced handsets on their own

Cost benefits are as follows

• Both India and Sri Lanka spend on data collection now
• For half the cost RTBP can introduce collection of a richer data set along with detection and alerting components too
• Operational expenses are the bulk of the costs
• RTBP can shrink the capitol expenses in India
• Its the filing cupboards and none ICT based delivery that eat up most of the cost

SL: I would highlight the fact that the OPEX and CAPEX is not the same for RTBP Sivaganga.

mHealth can fix the imbalance:

• Ideally health facilities should be powered for data collection, health departments for detection and alerting, with health workers fully on response
• Both in India and Sri Lanka its all data collection and  almost zero resources on detection and mitigation.
• Sri Lanka – health departments consume bulk of the resources

RS: Now we are getting to the e-gov and it’s better if you talk to Helani and Chanuka on this.

Conclusions

• mhealthSurvey is a worthy candidate for patient disease/syndrome digitization
• However, must be improved to minimize the noise and delays
• Need a better GUI if Medical Officers are to enter high volume real-time data opposed to a data entry clerk
• Need a compete and comprehensive standardized disease syndrome ontology
• Need to investigate other digitization techniques

Click for the full paper