eGovernment for Development

eGovernment for Development
eHealth Case Study No.2

TeleHealth India: The Challenges Facing Teleconsultation via an eHealth Portal

Case Study Authors

Anonymous

Application

In 2001, an idea was conceived to support health systems in one state in India using ICTs. The project actually got underway in 2003 with creation of an e-health portal.

Application Description

The intention of the TeleHealth portal is to provide a single source of informational support on health in the state, serving everyone from individual citizens through primary health workers and medical professionals in tertiary care centres to health administrators. To date, the portal itself has been created, and it has developed and tested a teleconsultation application that links a primary health centre with the Mercy College Hospital in the state capital. In the primary health centre, the medical officer identifies non-emergency cases where there is some doubt that would normally cause her to refer the patient to Mercy College. Just after lunchtime, she fills a form located on the portal for each one of the patients. At mid-afternoon, the head of Medicine at the College Hospital accesses each case form, and provides expert comments online. These comments are accessed by the medical officer on the portal the following day, with guidance on how the case can be managed locally (or advice on further referral of the patient).

Application areas under development include creation of:

• · an online resource centre for medical literature;
• · an online discussion forum for physicians located in rural primary health centres; and
• · an online discussion forum for medical specialists located in urban tertiary care centres.

It is also intended to use the portal as a platform for initial and continuing medical education.

Role of ICT

The TeleHealth application is a Web-based portal hosted on a server PC. Alongside basic HTML, site pages are created using Java, ASP and SQL database.

Application Drivers/Purpose

The initial driver for the project came from staff in local medical academic institutions, seeking to find ways in which ICTs could be used to improve the delivery of health services.

Stakeholders

The core stakeholders are the health professionals within the state's health system, and the patients that they serve. As noted, the main originating stakeholders are a small group of medical specialists in a number of different academic institutions. Various health administrators need to be involved in progressing the system. Finally, there are funders within the state and central government, and technologists in government who have had an important influence on the project.

Health and the Poor

The teleconsultation module of the portal is intended to have a fairly direct impact, reaching out into poor communities. In the majority of cases referred through the teleconsultation module, the need for the patient to travel to the state capital is avoided. Previously they would have had to make that journey, at a direct cost of something like US$2 for travel of patient and relatives, plus the opportunity cost of income lost through having to travel instead of working.

Impact: Costs and Benefits

The development costs of the portal are unknown because this has occurred through the time given by the originating team or their students as a design exercise. The teleconsultation pilot cost around US$400 for each of the two PCs installed (one in the health centre, one in the College). Portal and server hosting costs are estimated at around US$200 per year.

Only a very limited number of pilot teleconsultations have taken place, but it is estimated that the dial-up costs from the health centre are US20c per consultation, as compared to an estimated cost of US$10 per patient if they travel to the medical college for a referral. On one of the pilot days, there were eight referrals via the portal. One had to be rejected because the form was incomplete, one patient was referred to a gynaecologist, and six were able to be managed locally. Since the health centre medical officer had planned to refer all six to the college, that suggests a daily saving of nearly US$60. Even allowing for daily variations and uncertainties in the calculations, this suggests a financial payback period for each health centre installation of less than one month.

However, as discussed below, the project has faced major difficulties which are hindering its full implementation.

Evaluation: Failure or Success?

The project is only at a pilot stage. It has succeeded as far as proof of concept is concerned, but cannot yet be evaluated since it has not been fully implemented.

Enablers/Critical Success Factors

1. Hybrid team . The successful piloting of this e-health application can be put down in part to the 'hybrid' nature of the team involved, drawing together skills from different areas including social science, medicine, and ICTs. In particular, the non-technical team members have taught themselves ICT skills so that they can understand both sides of the health-ICT divide.

Constraints/Challenges

1. Mindset and politics of technical staff . The main problems suffered by this project have come from the technical staff involved in the state government. They have always kept the technical and administrative controls for the portal to themselves. They have made it difficult to add new members to the portal discussion forums, forcing the project to make use of Yahoo groups instead of using the group feature within the portal. The portal's IP address has also been re-assigned at times - for six weeks it was used to declare the results of state high school examinations. One could attribute these problems to the traditional divide between 'techies' and mainstream health professionals. Indeed, this is the excuse used by the technocrats: that the non-technical project staff do not have the skills to manage the portal (despite the fact that these latter staff are running their own Web sites and online discussion groups). However, the underlying issues seem more likely to be political, from the simple desire of technical staff to retain power by retaining control, to their involvement with potentially competing projects.
2. The politics of funding . Getting funding for the project has always been difficult, explaining the delays between conception of the project in 2001 and only really getting started in 2003. The project was begun with no funding, but the state government was interested. Funds were twice allocated for the project, but then transferred to other projects that had a higher political priority. As a result all progress had to be made from the project team's own resources. When a central funding award was finally made for the project, 95% of the money was assigned to an agency 2000km away, located in the constituency of a senior federal government minister.
3. More politics . The state's own health department is keen on the portal to progress. However, there is animosity between the head of that department and the head of the main IT institution involved. This has hindered progress.
4. Incentivising system use . A sister project to this pilot was developed to support the medical consultation process. Although the system has worked well in trials, and is being used for medical education, there has been no usage of the system by medical professionals despite it being available for more than one year. Those professionals are demanding first that a full-time staff member be appointed for the project, and second that they should be given some incentives to perform online consultations using the new system. Without these, they refuse to be involved with the system.

Recommendations

1. Creating hybrids . This project shows both the benefits and problems of the hybridisation necessary for an e-health project to succeed. The core project team has worked well in its combining of health and ICT competencies. Yet the divide between technical and non-technical staff has been a fundamental constraint to project progress. One lesson is that it is better to try to create hybrid individuals rather than hybrid teams for e-health projects: i.e. individuals who combine an understanding of health systems/services with an understanding of ICTs. One could try to create those individuals by training ICT staff in health matters. However, experience on the project suggests that it is much better to hybridise the other way: by taking existing health domain specialists and helping them to understand the technology.
2. Patient-/health-centred design . In too many e-health projects, the application design is technology-driven. The technical staff take a very basic brief and then go off, design the architecture and develop the underlying software according to their own understanding, capabilities and interests. Training is then designed to make the health professionals understand, accept and adapt to the features the technologist has designed. This, of course, is the tail wagging the dog. A proper approach to design would start with the patient or the health professional and find out what they require. The approach would also be flexible, taking feedback from prototyping in order to redesign and create a more usable system. One key area this issue arises is in the question of security and privacy of health data. From a patient-centric perspective very strict protocols would be designed in, to avoid personal health data from being revealed. In the techno-centric approach used for some parts of the TeleHealth project, there was no real consideration of the need to protect data - patient details for teleconsultation were available on the portal.
3. Avoid 'hard', software engineering approaches . As a follow-on from the previous point, e-health projects are sometimes developed using 'hard' software engineering approaches that have little consideration of actual information needs or of political realities. Instead, softer systems development methods are required that understand the political context for the e-health system, and which also develop that system on the basis of the true information needs of key health users.
4. KISS: keep it simple, stupid . The software design needs to be such that system management and also system use are fairly simple processes that can readily be grasped by non-technical health professionals.

Further Information

n/a

Case Details

Case Editor : Richard Heeks.
Author Data Sources/Role : Project Coordinator Role.
Outcome : Too Early to Evaluate
Region : South Asia. Start Date : 2001. Submission Date : January 2004.