Going Wireless; Clouds and Mobiles

1. Going Wireless; Clouds and Mobiles Health Information Systems Strengthening

2. Going Wireless ”Cloudcomputing” mHealth • Security and confidentiality issues around health data (shift from paper -> stand alone computers -> web-based services) • Challenges of human resources • Global priorities with implications for IHIAs Civil registration and vital events systems Universal Health Coverage Insurance schemes Pay for performance schemes (P4P)

3. Evolution of HISP / DHIS HISP since 1994 • Essential dataset / Hierarchy of standards • Decentralization • Local information use, bottom-up HIS development Now, more diverse • Many agendas: NGOs, international orgs. • Partnerships • Top-down and bottom-up Technology has changed: from offline to online and mobile

4. From stand-alone to web-based Software services increasingly available as online services rather than installed applications on computers • Gmail, yahoo, googledocs, dropbox, facebook Access to data from any computer (that is online) This has implications, also for HIS/IHIA

5. Stand-alone HIS deployment Software installed on each computer (e.g. Sierra Leone) or mobile (e.g. Punjab) • Hard to manage across many users • How to maintain the data definitions, share data, get access to data etc? • Reinstall deleted software, upgrades, bug-fixes, etc.

6. Distributed stand-alone implementation in Sierra Leone Each district (13) had their own instance of DHIS2 Each district run a Local Area Network (LAN), where several people within the district could access the same database, running on a Linux (district) server

7. Challenges of stand-alone implementation • Maintaining servers on LANs distributed around the country is challenging and costly • Power supply interruptions frequent • Workstation problems can be dealt with by local IT companies, but DHIS on the server requires more specialized competence • Even with hardware working 100%, keeping the entire HMIS metadata in synch between so many systems over time is an uphill battle => comparability loss • Software: virus and mal-ware infections, bad security practices (USB-sticks) Each of these factors point to the non-sustainability of distributed architecture and the resulting pressure to technically centralize

8. Online Deployment • Web browser only requirement • Computer can be reset to fix problems • No data lost in case of disk crash

9. Great promises of ”cloud computing” Only one installation of the software and database + backups • All changes instantly apply to all users • No need to travel around the country to update and synchronize software and database • All users can get access to peer data for comparison analysis • Capacity to maintain the server can be centralized and professionalized • External experts can be given access to help solve issues But where will the data reside? WARNING: Technical expertise to maintain the server is crucial and needed from day 1 – all users depend on the server running

10. Requirements for reliable hosting

11. Modes of online deployment In country Internationally

12. Three examples Kenya hosting privately abroad Rwanda hosting within MoH Ghana hosting at a national private ISP

13. Kenya “Due to poor Internet connectivity and inadequate capacity of the servers at the Ministry of Health headquarters, a reliable central server using cloud computing was set up” “Cloud computing" in this context meant a third part commercial Linux hosting company with its primary site in London, UK. Since Sep 2011 used in all districts (~250) Online usingmobile Internet (USB modems) Reporting rates are around 92% (forms submitted/forms expected)

14. Rwanda Smaller than Kenya. 11 million living within a land area of 25,000 square kilometers. Approximately 550 registered health facilities spread across 30 districts Original plan in mid-2011 was to follow the Kenya example. MOH e-Health Coordinator intervened - data had to be stored within the country! Revised plan to host DHIS in the National Data Centre, along with other eHealth systems With training and configuration of the system complete, the NDC wasn't ready .. DHIS2 was set up within the MOH as a temporary solution

16. Ghana Scale similar to Kenya ... 170 districts and 4000 facilities New server specifically for running DHIS Like Kenya, there were perceived difficulties in locating server within MOH Decision was made to physically host the server with a local Accra Internet Service Provider

17. Learnings from the deployment cases Despite challenges, the online deployments are viewed as successful by national stakeholders Reporting rates are high, users are active, data is visible in ways it wasn't before Handover of full control of the servers to the country teams remains an outstanding concern in all cases (Rwanda is furthest along this path) The more distributed model of Sierra Leone is very hard to sustain over time

18. Managing risks • Data is held by government in trust on behalf of citizens. • Ghana and Kenya both prefers internal hosting. Outsourced hosting is pragmatic. • Centralized data storage has increased dependencies - mobile operators, ISPs, hosting providers, technical support (HISP) • Ghana and Rwanda risk hardware failure • Kenya risk in terms of governance and sovereignty • Outsourcing hardware to the “cloud" can obviate the need for internal technical competence and infrastructure, but generates requirements for new IS management capacity • The storage of patient data raises security compliance challenges on extra territorial servers! [or any server…]

19. Some Concerns Are tradeoffs and total-cost-of-ownership issues understood when promoting eHealth and mHealth initiatives? Regulatory and policy environment regarding governance of health data is far behind the technological possibilities. Does it matter if HMIS data is hosted in London or Chicago? Important to have a viable exit strategy with vendors – generally means maintain control of the data (e.g. avoid premium charges or subscriptions required to access own data)

20. Individualbased data in publichealth? Better data quality? Qualityofhealth services? Universal Health Coverage (UHC)

21. Some concepts relevant to UHC Access:health services that people might need are available, of good quality, and close to them Coverage of interventions: people who need an intervention actually receive it Effective coverage:people who need health intervention obtain them in a timely manner and at a level of quality necessary to obtain the desired effect Obstacles to obtaining effective coverage: physical access, affordability, acceptability Universal Health Coverage: people receive the services they need without incurring financial hardship

22. Individual data – increasing importance Universal health coverage (everybody counts) Insurance schemes Pregnant mother and child tracking Various mHealth initiatives (programme tracking) Implications • Civil Registration & Vital Statistics (CRVS) becomes increasingly important • Need for CRVS to speak with HIS/IHIA

23. CRVS: some key functions • Add, change, count, inquire data and events relating to individuals • Check routine data for errors and correctness • Provide data export for external systems • Process and tabulate vital events • Integrate CR with other data sources (surveys, sample registration, etc.) • Create birth, death, cause of death, live birth statistics

24. CRVS integration • Unique identifiers • Patient access to their own health data • Pay for performance schemes (P4P) • Avoid high-risk patients • Some insurance companies will not pay for new practices (reduce errors) • Physicians and hospitals can bill for additional services that are needed when patients are injured by mistakes • Citizen empowerment, doctor feedback • Privacy, Security • New data collection tools & routines

25. Recap Web-based HIS has many challenges as well as opportunities Application domain is becoming incresaingly complex, requiring multisectoral information Institutional barriers still remain, for example in CRVS Legal frameworks are not in place in most developing countries to protect indvidual data. The demand, however, continues to increase. Possibilities offered by technologies far outpace progress in legal frameworks i

26. mHealth

27. mHealth Public Health Patient Centered Program tracking Clinical Use Routine reporting Low-end Phone Medical Sensors SMS-reminders Diagnostic tool Treatment Support Smartphone Voice consultation

28. Use case  Types of mobile application & data bearer • Plaintext SMS • Structured SMS • SIM-apps • GPRS-apps (Java J2ME) • Mobile Browser – offline/online Paper is still a viable option in many contexts!

29. Aggregate data: routine reporting of health data from facilities/communities Robust Domesticated Not so prone to theft, preferably privately owned Long standby time on one charge (e.g. with small solar panel) Local service /maintenance competence Local mobile phone literacy Mobile coverage [ where there is no road, no power, no fixed line phone] Low End Mobile Phones

30. mHealth & HMIS goals Timeliness & Data Quality Assist local decision making based on accurate data on time NB: Not all improvements have to be measurable in terms of improved health services. Cost effective service provision and HMIS functions also important

31. How can mobiles improve HMIS? Data Quality - Validation rules On the spot data capture and transfer Save time and reduce mistakes caused by manual aggregation of data mHealth application areas • Routine data (HMIS) • Notifiable Diseases (IDSR) • Individual “Tracking” => aggregate

32. Types of mHealth data Name based/program tracking (ANC, HIV, TB) or aggregate data (ISDR & routine HMIS) CHALLENGES • Security of identifiable patient data • Complexity of work routine (not easy to capture on a small screen – or any screen) • mHealth - Additional burden or Helpful tool?

33. mHealth; empowering health workers or job surveillance? Integrate with GIS/GPS – for disease surveillance or can be used for task force surveillance and control [Example: daily reporting Punjab] Some managers would love to have a camera-drone following their health workers 24-7!

34. Missing Feedback in HMIS? What do we know about supervision? Feedback and reward from local community are significant to health worker motivation and performance Supervision feedback only when there are errors, mistakes, shortcomings Supervision is irregular and non-supportive and requires time & resources Mobile “Feedback” (access to processed data) • Progress over time • Comparisons to other organization units [vertical/horizontal] • HMIS metadata – completness, timeliness % • Push or Pull?

35. What’s in it for the end users? Save money and time spent on travel [maybe!] More time for service provision [ideally…] Closed User Group (CUG) agreement with mobile operator = free communication with colleagues Processed data ”Feedback” Integrate with mobile banking? Phone Credit top-up/ reimbursements/bonus

36. The plague of ‘pilotitis’ in HIS • HIS in developing countries – `pilotitis’ abound • HMIS – requires ‘all or nothing’? • Systems do not sustain or scale, and we keep repeating the same mistakes – Why? • We operate in isolation, do not share experiences, and are unable to link pilot work with national HIS needs

37. Pilotitis in Mhealth, Uganda

38. Problem of mHealth Pilots Additional burden for health workers Donor short attention span - unsustainable What works as a pilot does not necessarily scale Pilots may focus on technical feasibility while ignoring larger organizational and political mechanisms (e.g. health worker unions) Hard to evaluate and-compare mHelath projects

39. Partners in mHealth “Ecosystem of actors”: Ministry of Health, NGOs, researchers, Programme Donors &… Mobile Operators • Network coverage • Closed User Group Agreement • Social responsibility or New revenue streams? BUT mHealth Initiative may get stuck with one operator! Win-Win-Win?