Introduction
This report builds on the proceedings of the workshop, “Free and Open Source Software and Standards for Public Health Information Systems in India: Making them work by bridging the policy-practice gap”, organised in Delhi in February 2017 by the Observer Research Foundation (ORF), with technical inputs from University of Oslo, Norway. The workshop explored the opportunities, challenges, experiences and strategies in applying FOSS (free and open source software) for strengthening public health information systems in India.
The workshop was divided into four themes: i) the overall policy landscape within the public system, in general, and public health information systems (HIS) in particular; ii) practical experiences in utilising FOSS-based applications within the public health system in India; iii) learnings from other countries, such as South Africa and Brazil; and iv) identifying particular policy-practice gaps and approaches to address them. Each theme was discussed by a lead and six panellists over a half-day session. The lead provided opening comments on the particular theme and then invited each panellist for specific interventions, followed by open discussions with the audience. The lead then summarised the discussions and drew implications for bridging the extant policy-practice gap.
Panel one discussed the existing policy landscape. The lead was Amit Mishra from the National Institute of Smart Governance who has been involved with a number of these initiatives from the MDDS (Minimum Data and Data Standards), the facility registry, discussions and procurement of HIE (Health Information Exchange). The second panel discussed practical experiences in using FOSS and was led by Dr T Sundararaman from TISS, Mumbai. Panel three discussed learnings from global experiences led by Bob Jolliffe from University of Oslo, Norway and included panellists from WHO SEARO, CDC India, CSIR South Africa, HISP Sri Lanka, and Tajikistan. The fourth panel summarised the learnings from the deliberations and was led by this author.
I. Thematic Summary of Workshop Proceedings
-
Sub-optimal state of public Health Information Systems (HIS) in India
The state of HIS reform in India is in its nascent stage. The introduction of ICTs in this sector so far reflects only a state of automation rather than transformation; indeed, the potential of ICTs for health sector transformation remains grossly underutilised.
The HMIS (Health Management Information System), the backbone of India’s national HIS, suffers from a serious credibility gap. For example, while HMIS reports vaccination coverage as high (at 90-100 percent), third-party surveys indicate that they are as low as 60-65 percent. The other sources of data are household surveys, which come only once in 10 years. A state or district official who has a maximum tenure of two or three years, cannot be made accountable for data which will come only once every 10 years. Further, sample sizes of certain states are inadequate to either generate robust indicators or make meaningful comparative analyses.
-
Key drivers (and inhibitors) for strengthening HIS
Various drivers to strengthening national HIS include the following:
2.1: Introduction of performance metrics: Niti Aayog and the MoH are rolling out a performance index on health outcomes to privilege better performing states over others. Data from HMIS, HRIS (Human Resource Information Systems) and surveillance databases will be key sources of data for this computation, making it imperative to improve the quality of reporting.
2.2. Strengthening planning processes: MoH seeks to address the anomaly of strengthening public HIS in a context where 75 percent of out-patients and 60 percent of in-patients are treated in private healthcare facilities, from where reporting is inadequate. Robust and trustworthy public HIS are key to strengthening planning processes for monitoring progress towards SDGs.
2.3 Strengthening policy efforts: National policy initiatives—such as developing nutrition road maps – are adversely affected by the conspicuous absence of quality data. While Aadhar-based systems hold the potential of individual-based monitoring of progress, centralised databases based on Aadhar, are not sensitive to localised needs, and State access must be ensured.
2.4 The ‘Digital India’ initiative: Political push from the centre in the form of the ‘Digital India’ initiative promotes the digitisation of services, including in health. However, centralised initiatives under this Digital India framework should be avoided, as they impede local initiatives.
2.5 Spillover effects from the software industry: India is the world’s largest sourcing destination for IT services with an annual revenue of about US$143 billion, growing at a rate of about 8.3 percent annually. These services are generated by some 16,000 firms employing a workforce of over 10 million and with a presence in more than 80 countries. Another key driver is FOSS adoption—as of 2017, almost 90 percent of India’s IT companies have adopted these solutions, and also provided them for global enterprises. However, FOSS applications for public health remains limited.
2.6 Trade agreements: Multilateral regional trade agreements like the Trans Pacific Partnership (TPP) or the Regional Comprehensive Economic Partnership (RCEP), to which India is a signatory, favour stronger intellectual property rights regimes and give rise to certain security concerns. There is push from foreign companies mostly based in the United States to ensure that source codes remain proprietary, and this inhibits the growth of FOSS-based ecosystems.
-
Understanding FOSS and framing it as a Global Public Good
3.1 Philosophical basis: FOSS reflects a post-development perspective that suggests economic and social change must flow from the communities themselves and not from external sources. FOSS combines free software and open source. Free software coming from the Richard Stallman-inspired thinking that free software is not ‘free’ as in free beer but ‘free’ as in free speech. Open source software is inspired by Linus Torvalds’ Linux. FOSS combines these two streams of free software and open source, representing a broader philosophy (from free) combined with practical software development solutions (from open source). FOSS ownership is not about owning a commodity like a handbag, but it is about owning a bundle of rights to modify, reuse, edit, evolve piece of software code. Peter May argues that FOSS is not anti-capitalist but only ‘differently capitalist’, representing two maturity models—one philosophical and the other more practical. Today, FOSS has become a global standard with private firms drawing upon open source, to fuel their commercial business models.
3.2 FOSS as a GPG: FOSS should arguably be treated as a ‘global public good’ defined by characteristics of non-rivalry and non-exclusivity. A GPG example is of a watch tower giving light to navigating ships. It is ‘non-rivalry’ in that if a particular ship accesses that light, it does not stop others from doing so. It is also ‘non-exclusive’ in the sense that it is meant for universal access and is not limited to a particular segment or particular geography. This provision of light, however, does not happen on its own but requires a robust governance framework shaping both the supply and consumption of services. If FOSS as a GPG represents a normative ideal, governance needs to address the various distortions in achieving that goal. Distortions come from procurement practices, capacity, participation, and infrastructure, among others. The workshop has tried to identify these distortions in practice, and approaches to address them.
GPG principles applied to data raise serious ethical and security dilemmas, and challenges power configurations. Medical information has different nuances to it, but often this is not about FOSS and non-FOSS, but how FOSS will accelerate the process. Google, which today stands as the primary aggregator of personal information in the world, was built on a lot of FOSS software. Principles of pseudonymisation or anonymisation may not always work, as we can move from statistical databases to identify individuals. With advances in big data and machine learning, the world may be unleashing a monster that can go out of control.
3.3 Increasing spread of FOSS: In supercomputing, 90-95 percent of the top 500 supercomputers globally run on Linux. The IDC reports that by 2019 the growth of Linux will be in the region of eight percent while the growth of proprietary operating systems, around three percent. Linux and open source are growing much faster than proprietary operating systems. Gartner reports that by 2018, 50 percent of every new database will be based on FOSS, and by 2019 this proportion will be 70 percent. In health, global organisations like WHO (World Health Organization), CDC (Centers for Disease Control), UNICEF, PEPFAR (U.S. President’s Emergency Plan for AIDS Relief) and NORAD (Norwegian Agency for Development Cooperation) are all supporting the adoption of FOSS-based platforms, such as those based on DHIS2 and OpenMRS, for health system strengthening efforts. The use of these platforms requires a more mature understanding of the Total Cost of Ownership (TCO) that includes costs of maintaining and evolving the platform over time.
-
FOSS-related policy landscape in India
The Government of India has adopted various policy initiatives to support the use of FOSS in public systems. A 2014 policy statement recommended the adoption of FOSS for all e-governance applications. To implement this policy, government organisations must include a specific requirement in the Request for Proposals for suppliers to consider FOSS along with CSS (Closed Source Systems), and suppliers should provide justification for exclusion of FOSS in their response.
In 2014, the GoI issued its Open API policy by which it seeks to make all government services digitally accessible to citizens through multiple channels such as the web, mobile, and common service delivery outlets. For this, there is a need for an interoperable ecosystem of data, applications, and processes to make the right information available to the right user at the right time. The policy encourages the formal use of Open APIs to strengthen interoperability.
Further, the Government’s National Policy on Information Technology aims to increase revenue from IT services to US$300 billion by 2020, including US$200 billion through exports. Another policy, issued in February 2015, is on collaborative application development to open up the source code of government applications, and for all source codes to be placed in a single platform for promoting collaborative application development.
The government announced in 2012, the National Data Sharing and Accessibility Policy to strengthen sharing of information across ministries and systems for promoting evidence-based decision making. and data, while discouraging data duplications. Earlier, in 2010, a policy was announced on the use of open standards for all e-governance applications. The standard should be adopted and maintained by NGOs where all stakeholders can opt to participate in a transparent, collaborative and consensual manner. Open standards would be technology neutral specification and capable of localisation support where applicable. In 2005, the Department of Electronics and IT established the National Resources Centre for FOSS, strengthened by the National Policy on IT in 2012 to promote the use of FOSS and open standards.
Summarising the policy landscape around FOSS in India, there are stipulations to support FOSS-based developments to reduce cost and gain more flexibility and long-term sustainability. There are also policies in place to promote data sharing by using open standards and open APIs and creating a broader enabling eco- system.
-
Policy initiatives in public HIS implementation
There is a committee in the MoH that is considering three sets of standards: the MDDS (MetaData and Data Standards); facility registry (called NIN – National Identification Number); and provider and the patient registries.
In defining data standards, the guiding design principles include:
i) Data should be entered only once and used many times. This principle is grossly violated in India, leading to added work burden and poor quality data which cannot be exchanged;
2) Patients should have ownership over their data and ability to access it at all times. This is technically enabled through open APIs;
3) Providers submitting and using data should be able to use and refer to the data as and when required. Currently this is mostly not possible due to the absence of feedback mechanisms;
4) The focus should be on building district-level health system databases including data related to service delivery, access to health services, epidemiological profiling, mortality profiling, human resources, drug supply logistics, financing, quality of care and equity. This requires an enabling National e-Health Architecture based on guidelines and standards, including open APIs to develop point-of-care applications.
The Ministry of Communication Technologies MDDS initiative under the National e-Governance Plan aims to promote interoperability amongst e-governance applications. The MDDS Committee centrally constituted within the Ministry has created a set of demographic and domain-specific standards, including data element names, their values, and code directories. Various challenges were experienced in its design, including the non-standard nature of existing legacy data that were not easily generalisable. The MDDS exercise involved creating health domain metadata standards spanning both patient specific and aggregate data, containing some 1,000 data elements segregated in 39 entities across 141 code directories. These standards were submitted for public consultation in February 2014 but due to resistance from various quarters could not be adopted and notified.
Another initiative concerns the building of a health facility registry through the National Identification Number (NIN) portal, where each facility would be assigned a unique NIN. After studying global experiences, the MoH identified two approaches to building such a registry: one, doing a new health facility survey from scratch, computerising the results, and notifying this as the registry; and, two, compiling data from various systems into one place to create a master facility list. India adopted the second approach using the HMIS and the Mother and Child Tracking System (MCTS) as the source systems and generating the NIN with attribute details on 23 parameters. NIN is based on a 10-digit number (including a check digit) generated from a centralised system. This number includes certain facility attributes such as the type, location, address, geocodes, and services provided by the facility. These NINs were then sent to the states for confirmation to identify common functional facilities in both the systems. However, the mapping had its own issues because both systems had specific ways of documenting facility names, facility types, and attributes. Therefore, only 59 percent of the facilities could be mapped and 30 percent of the facilities could not be mapped with each other. The other 11 percent were duplicates or invalid entries in both the masters. At present, the NIN portal contains 200,000 facilities data duly verified. Since its launch in 2016, States have added more than 11,000 facilities, but still excludes facilities from private, railways, and particular programmes such as tuberculosis, cancer, mental health, and others. The facility registry currently includes 84 percent functional facilities; 16 percent of facilities are non-functional (either duplicates or closed). There are also data quality issues that need to be sorted out.
The facility registry is not in active use as various types of facilities, laboratories and legacy systems are not included. Further, the reporting hierarchy is not specified, creating an impediment to its use in the development of other systems. There are future efforts underway to create a look-up registry to connect the NIN portal with other systems. Mechanisms are being created where other facilities currently not included can get enrolled into the NIN portal through providing an API interface and open access to enable registration. This requires a fair degree of process standardisation that is still not in place, and needs to be accompanied by a continuous process of rationalisation to remove duplications and ensure quality and integrity of data in the portal. Due to the evolving nature of the health system, the facility registry needs to be necessarily agile, iterative and capable of adopting to stakeholders’ needs; otherwise it risks becoming obsolete and unused.
Another important requirement is to have a strong quality improvement programmes in place. For example, the NIN has some 5,093 sub-centres and 440 primary health centres—these numbers are higher than those reported in official rural health statistics. Some of these discrepancies may be true because the numbers have fluctuated over time, but this needs to be verified through a quality improvement programme that triangulates data from different sources. Such a process needs to be within an institutional framework owned by the Ministry of Health but also involving cross-ministry collaboration, such as that responsible for the Census.
Another important policy initiative that is required concerns FOSS procurement. Current systems are typically based on an RFP involving a large bureaucratic effort. The RFP is an important point as it becomes the seed from which the plant grows. As has been seen in various recent RFPs, they tend to favour large profit-making corporations by specifying minimum criteria for turnover, team size, and required certifications. As a consequence, smaller and more specialised organisations such as NGOs and universities typically get excluded. Further, the RFPs club together software, hardware, infrastructure, and data centres, among others, thus excluding organisations that specialise only in software systems. The RFP specifies a set of fixed requirements and does not adequately consider future enhancements. The NIC is responsible for building RFPs for MOH systems and their approach is techno-centric. Further, getting the RFP processed through the Ministry of Finance is not an easy job. As RFPs are made for particular systems, it leads to the creation of islands of different systems (e.g., HMIS, MCTS, RCH, and many others).
There is an urgent need to build more innovative models of FOSS procurement such as through community-based approaches, involving building multiple prototypes in different settings. Grand competitions could invite different groups to build different prototypes, and these should be evaluated by technical teams to identify which prototype is taken forward through collaborative efforts. Another model is of reverse auctions, where money for development is fixed, and parties are invited to propose the features they can provide within that sum. These are just two alternatives to the standard L1 model which hardly works for IT.
Currently, it seems with FOSS policies related to procurement and standards, monuments and museums are being created, with little focus on their implementation and compliances on the ground. There are also a lot of duplication of efforts, with limited means for their reconciliation.
-
The FOSS ecosystem in India
The FOSS ecosystem consists of the government, industry, academia and the FOSS community with mutual dependencies between them. Some examples include the ICFOSS supported by the Kerala government and the Free Software Movement of Karnataka. While globally, France has the highest indicator for FOSS adoption, India is below the average level. In India, a pioneering example is that of the State of Kerala which was the first to adopt a pro-open source software policy; ICFOSS was a consequence of that policy. The policy enjoyed strong political commitment, and the Kerala Legislative Assembly switched to use of FOSS in 2005. Strong education in FOSS occurs in Kerala schools and colleges. There are also FOSS-based state initiatives in Himachal Pradesh, Punjab, Andhra Pradesh and Karnataka.
The success of FOSS initiatives in cases such as the IT at School programme, the Sarv Shiksha Abhiyaan, e-literacy missions like Akshaya in Kerala—can be attributed partly to the fact that teachers were themselves motivated to learn basic software applications and train secondary community of teachers. There were software engineers who understood the importance of developing local language applications and who contributed to state efforts. The State was also willing to shield them from vendor pressures to use proprietary applications. In Karnataka, however, the exact reverse happened: in the capital, Bengaluru—regarded as the IT hub of India—vendors exerted pressure on the state government for the use of their customised solutions for the e-literacy mission. This led to less than optimum results compared to Kerala. There are other positive examples from Kerala such as the State Electricity Board that switched from proprietary to FOSS software to avoid license costs. The ITED School provides education totally based on FOSS. The Spices Board ERP is another successful example from Kerala.
In general, with only few exceptions, there have been limited efforts from the government to enable an ecosystem around FOSS. For example, there is no list describing FOSS-based applications and their providers, or guidelines to support their adoption. Well intentioned policies thus fall short in their implementation.
-
Practical experiences in deploying FOSS: national public health system
To understand the status of FOSS for public health in India, it is important to examine the history of how HIS has evolved in the country. The first phase was pre-2005, when the World Bank and other development partners supported IT initiatives with a general logic of tightening monitoring for particular programmes that they were supporting. The situation changed dramatically after 2005 with the NRHM adopting the agenda of strengthening health systems, including the HIS. The MoH then conceptualised the HMIS that cut across states, which involved a rationalisation of the data elements and indicators and highlighted the tension between centralisation and decentralisation. This was reflected in a famous circular from NRHM which said that it is up to the district/states to do whichever is their best way of collecting information, but then they should put it on a central HMIS portal that will integrate the entire information. This created the impetus to use the FOSS-based DHIS2 in about 22 states. While only a few portals were developed from 2004 to 2010, thereafter was a surge of second-generation systems through states for particular programmes and services.
Most of the systems could not support the needs for interoperability, which promoted the development of top-down standards. The uptake of DHIS2, one of the pioneers in the use of FOSS in the public sector, has suffered due to the absence of an enabling ecosystem of government intention, policy and broader support mechanisms. The problems of interoperability between DHIS2 and other MoH closed systems have also constrained its use in states. While policies from the Prime Minister’s Office emphasised FOSS as a priority, on-ground situation hardly changed. The MDDS and NIN standards were meant to address these challenges but were not put to use and became stand-alone instead. As a result, ad hoc measures were developed to allow interoperability between district and national systems.
In summary, while FOSS has always been on the agenda, it has remained second priority. While FOSS provides advantages in terms of costs, it involves a lot of work in customisation and requires specialised capacity which is not easily forthcoming within a government system.
The MoH makes software primarily to support planning and monitoring, largely excluding the needs of health functionaries like ANMs, ASHAs and medical doctors. For example, when a doctor is dealing with a patient, they do not want to spend their limited time on entering data in the computer. The same is true with health workers, who may have to walk 25 km to get access to a computer; this is a huge waste of their time and constrains their ability to provide care. A large hospital in Punjab has been trying to use computers for the last 10 years, but so far has only automated patient registration and billing processes. Patient care related data is not included, reducing its value for use by doctors. Another example of the top-down design process is of the MoH trying to develop a Human Resources for Health Information System (HRHIS). They convened a meeting with different states to identify best practice examples that can be adopted at the national level. The state systems were largely at the transaction level to mark attendance, track leaves, and other administrative tasks. This raises the question of whether the MoH should seek to adopt such a system to strengthen their surveillance processes, rather than one which can provide policy-level support.
While the national HMIS deals with general datasets, departments such as the National Vector Borne Disease Control Programme (NVBDCP) have particular data needs not captured in HMIS. So also do states, who have specific programmes running with particular data needs and also do districts. Meeting these different data needs of varying administrative levels and health programmes presents a non-trivial challenge, particularly in situations of uneven infrastructure. NITI Aayog and its previous avatar, the Planning Commission, promoted the notion of micro level planning and micro level data, which led to the initiation of the disastrous MCTS. As long as it involves a limited dataset, it can be centralised; otherwise, the data should remain at the local level, with bridges to interoperate when and if required. Currently, though data is being collected, the quality is not satisfactory and thus not being used. Erroneously, it was believed MCTS will solve data quality problems, but these were only aggravated. As a result, reliance on survey data continues. On the analysis side, MoH has relied on expensive proprietary tools like SAS and ArcGIS that requires high expertise, limiting its use value for public health planning, especially at sub-national levels. Complete centralisation will not promote FOSS adoption, and perhaps regional models such as in the North East RRC are required.
What is the difference between using open source and using a closed source? Open source tends to be more flexible than closed systems. With OSS, there are other things to be handled – the code base, libraries, helpdesk and training, which in closed source can be purchased in a package. Execution is not about the software, but putting software into place to solve a task, requiring active leadership both in defining content and giving technical guidance. FOSS does not solve these problems as it is just a tool. The NACO (National AIDS Control Organization) closed system failure was a combination of poor specifications, poor management, poor vendor performance and awful change management. It was also hard to use old technology to satisfy this diversity of needs. Issues of vendor lock-in is not restricted to public health but happens across all systems. Often, when the government hires a vendor, they think that there is no need for a senior-level IT or subject-matter expert. That is a recipe for disaster.
The debate on whether or not to centralise is key especially while dealing with patient data, which need not be shared centrally. Decentralised or hybrid architectures are required to better suit the needs of supporting FOSS adoption. These questions need to be addressed in the context of the national e-health architecture, which takes into account the purpose of the system, and what action needs to be supported. Health is a state subject and the needs of states are different from those of the centre. States thus must be given the liberty to define its architecture. These efforts need to be supported by national policy initiatives, for example, by mandating organisations like CDAC (Centre for Development of Advanced Computing) and NIC (National Informatics Centre) who engage in open source development based on public money, to deposit their code in open source repositories like Github, which currently is not the case.
-
Practical experiences in deploying FOSS: state public health system
Implementation action lies with the states and not with the centre, that deals with macro policy issues. The Constitution specifies health as a state subject. Kerala has health indicators at par with European countries. NRHM did not prioritise Kerala, which raised the issue of how the state sustains its achievements and deals with new geriatric and lifestyle diseases in the manner of Europe and Japan. Kerala was the first in the world to adopt and scale up DHIS2, and was pioneering. Learnings from Kerala are valuable for the country.
From the state of UP, there is an example of lack of interoperability between state and national HMIS. UP is already using the HMIS system and almost 99 percent of all facilities are uploading data on time. However, they are still struggling with issues of data quality. There has also been a lot of parallel manual reporting to the HMIS. The State’s Principal Secretary decided that all manual reporting will be dropped and removed from the system. The state has built an integrated state portal using DHIS2 called UPHMIS but are struggling on how to integrate HMIS (Health Management Information System), MCTS (Mother and Child Tracking System) and UPHMIS (UP Health Management Information System). In the last one year, the Principal Secretary’s request from the national-level API access to UPHMIS has not been responded to. As a result, the state is forced to share data manually, which is time-consuming and cumbersome. HISP India, the developers of UPHMIS, have had meetings with Vyayam and Deloitte, who are maintaining the national portal, and API access is promised but not provided. This problem of lack of interoperability is long-standing, and the system providers have not enabled access.
The HRIS (Human Resources Information System) was set up in the states of Bihar and Jharkhand through a project of Intrahealth International in technical coordination with NHSRC (National Health Systems Resource Centre and HISP (Health Information Systems Programme), India. This included the creation of a registry of all the public health staff, including doctors, support staff, and operation managers. Staff capacity was developed to manage the software beyond donor support. The absence of a dedicated person to manage the system and intermittent technical support are some of the ongoing challenges to the running of the system. The different HR systems being used across the state show variations, some catering only to doctors and others only to the paramedic staff. Systems also varied with their operating systems, application interface and server deployment models. Potentially, these differences will impede future interoperability of data.
Another example of a FOSS product is the Electronic Vaccine Intelligence system for logistics management through the Ministry of Health Immunization Division. As the lead time from when a vaccine leaves its source to when it reaches its destination is four to six months, there is no certainty of how much vaccine is where and its status. This system was piloted in two districts of UP, and then rolled out across 12 states. The system is currently owned by MoH with access only to their users. The system is working in 359 districts, each having a dedicated person to oversee data entry. The system is currently stand-alone, developed by a private vendor Logistimo, and the product was purchased by UNDP and given to the MoH, excluding the source code. However, this does not qualify it as open source. To make it open source, the code must be put into a common repository and made publicly accessible.
-
Electronic Medical Record Systems: The patient-doctor relationship
Often the important question of why we need the HIS is missed out. For a patient diagnosed with malaria, for example, the important question is “should I give chloroquine or quinine?”; it is not so much whether the system is open or closed source. The important consideration is the balance between scale and access. A locally customised application may improve local access but will be difficult to scale. There is the romanticism of healthcare delivery, which is challenged by HIS. There are local terms, such as “gabramand” (referring to symptoms of anxiety, palpitation and sweating) in Gujarat, which cannot be captured in a structured HIS. Locally, gabramand helps to abstract the diagnosis of myocardial infarction. The information flow in healthcare starts with the local, becomes global and then local again. The question is whether open or closed source systems facilitate this local-global-local flow. Arguably, FOSS facilitates this flow better. In the Indian context, the romanticism of the doctor-patient relationship is valued and needs to be retained. An important design consideration is the role of participation of the doctors and patients in the process to help preserve the romanticism to some extent.
In summary, there are three questions of relevance. One, how to design and implement the technology to facilitate the information flow in this direction of local-global-local. Two, how to create the perception of reliable support so that the doctor concentrates on healthcare delivery and not the technology. Three, how to create the system so that technology facilitates the doctor-patient relationship rather than impedes it.
Another important aspect concerns the participation and engagement with users in the design of EMR systems. At NIC, the effort has been to develop patient-centric systems, for example to better schedule appointments. First, it was difficult to convince doctors that a person will come at a pre-decided time. Subsequently, it was negotiated to agree on slabs of time, so that a patient who comes at 9:00 am could be seen till 10 am. To make this appointment scheduling system, a first step was to make it public, through the web or mobile apps for which NIC established a wing for e-hospitals and developed an open source application which is working in over 40 hospitals, including NIMHANS. Given the problems of procurement, the MEITY (Ministry of Electronics and Information Technology) initiated the e-hospital and ORS (online registration system) funded by the Ministry. The system was launched on 1 July 2015 by the Prime Minister at AIIMS, where people would be queuing for appointments from 4:00 am when the counters only open at 9.30 am. Patients with Aadhar numbers were given priority in registration to enable potential linking of data across hospitals. In the absence of a common EMR, it was difficult to link multiple visits of patients to different facilities. Many states have been reluctant to adopt the NIC system because they demanded for more modules than currently offered. Also, there are questions and doubts raised about cloud hosting options.
AIIMS has an 80-percent bed occupancy rate. For a 2,500-bed hospital, this represents a significant loss of resources. The Indian Statistical Institute approached AIIMS to do this analysis, for which FOSS was used. Working with the data was not necessarily about open source, requiring specialised expertise. Only a certain proportion of people who booked through the ORS showed up, and this information was needed by the administrator. The application could read into the ICD10 codes and identify the disease, and the different parameters around such an admission for that disease. This analysis was based on a community approach, which AIIMS appreciated, and are now trying to automate some of these processes.
-
The role and challenges of Standards
The government has spent large amounts of money in buying SNOMED CT licenses, which they have distributed to states. However, there are no clear directions on how to implement them. Till date, there is no hospital fully compliant in using these standards, as it requires the profiling of workflows under a standards framework. Open source software and standards need to be treated separately. Standards can be implementable without a fee and involving participation of various stakeholders. The South African government recognised the importance of selecting open standards. Kerala is committed to using the SNOOMED CT by not just declaring the standards but coming up with incentives, enforcement and compliance policies to ensure that standards are embedded into solutions.
Declared standards offer vendor freedom because the rules of engagement are known and they can build compliant solutions, helping promote interoperability through API access. For example, in the Philippines, the Department of Health did not create a declared set of standards on their own. They had 100 working members of a community including implementers, government and academia who met and shared existing systems, standards in use, and tried to build consensus and gave freedom for vendors to play in the same sandbox. It is not only about standards being free to download but also to be free to participate in how they are developed.
Can SNOMED CT be qualified as an open standard in India because the MoH has made this available to all stakeholders free of cost? An open standard is not absolute, coming with varying degrees of openness. SNOMED is not an open standard on all parameters. In India, some systems have started adopting embedding SNOMED CT, for example AIIMS with their e-death system. C-DAC Noida’s hospital information system is being piloted in Telangana. There are now around 200 licences and affiliate licences given by the national release centre managed by C-DAC Pune. Adoption has started but is in the initial stage.
The advantage of a cloud-based system is that any change made in one hospital, can be made available to all hospitals. Currently, some 120 hospitals are on board and other facilities can potentially be brought on board. The system has helped to make things visible, as hospitals which said they were having about 5,000 OPDs a day actually have only 2,000. Bringing transparency in systems also comes with its own backlash. Hospitals like AIIMS have now gone fully digital and this has led to crores of savings, money which they were spending on vendors every year. A new hospital can be on-boarded to the new system in 30 minutes, while a PHC with no specialties can be on-boarded in five minutes. It is a completely plug-and-play system, compliant with HL7, MDDS, and LYONIC.
In the Ministry of IT, there are two originations – standard development organisation (STQC) and C-DAC, Pune—that test compliance of EHR systems to standards notified in 2013 and then revised in 2016. They will soon be pilot testing different applications which claim that they are EHR standards compliant. STQC testing is costly and time consuming, and the advantage of it not being free may be lost. It is thus important to consider the cost of embedding a standard and not just the royalty being paid by the private provider. What does it mean to make a hospital information system SNOMED CT compliant and compared to the cost of doing so, what benefits are obtained? These are the questions that need to be examined. It is not important to simply have a list of standards like SNOMED CT or HL7, but there needs to be guidance on how it must be used. Standards need to be profiled to model actual use cases, how to search for a patient, how to request a clinical document, how to register it there. Organisations like IHE (Integrating Healthcare Enterprise) are working on building such standard profiles. Typically, a base standard is taken, like HL7 or CDA (Clinical Document Architecture), and applied for registration of patients in India. By nature, this is a local but an expensive and time-taking process. Implementing standards, enhance complexity and its cost-benefits need to be carefully considered. Also, it needs to be asked if such systems be developed without resorting to centralisation.
Standards are not mandatory so far. One of the largest government sponsored insurance schemes in the country is the Rashtriya Swasth Bima Yojana, now being re-launched as the National Health Protection Scheme, envisioned to cover about 30 crore people. Insurance companies that will be empaneled will ask health service providers to use these EHR standards. In the US, some kind of sovereign fund is provided to help implement standards. When it comes to insurance and service provision, ICD takes a precedence, coming with more than 18,000 lines of standards and codes over five layers. Any layer can be customised to user needs, such as for insurance companies based on a financing framework. There may be inherent constraints with ICD10 because that was designed for a different purpose, for disease classification and reporting, and for insurance companies the purpose will be different. For doctors, SNOMED gives more flexibility as compared to ICD, while for government reporting, ICD is more useful. There needs to be a mapping system across different standards.
There are other standards also required. For example, IDSP uses the week Monday to Sunday and for the other programmes, their week is different. Further, it is unclear what is meant by a ‘referral hospital’, and how they are different from medical colleges and district hospitals. India needs a defined national e-health architecture that would be followed by all States based on compliance to different standards with some inherent in-built flexibility.
-
Global experiences around FOSS initiatives
Many countries in Asia are working with DHIS2, being treated as a de facto global standard. Commcare is being used in many countries in the HIV and MCH areas. So is OpenMRS which is compatible with DHIS2, and iHRIS based on a unique ID scheme for health workforce registry and geocoding of health facilities. Building the master patient index is challenging as there are many systems that use patient records with different ID systems. To enable interoperability, an indexing scheme with MedicCR is being developed by Mohawk College in Canada. The Open HIE project has developed an Open Health Information Mediator platform that enables interoperability. Bangladesh has Bhamni working with DHIS2, while Bhutan and Nepal have DHIS2 at scale and are starting to introduce Bahmni. India is beginning with the health facility registry initiative. There is the WHO-ITU National E-Health Strategy Framework. The Philippines has a social health protection scheme and health insurance programme called PhilHealth. They have a certified governance scheme, including KPIs, robust technical working groups with clear terms of reference, providing accountability and oversight of investments.
Other initiatives exist across Asia. Maldives, for example, has 187 inhabited islands and recently through the Ministry of ICT have made power and internet available across the entire country. Other elements are being added in the infrastructure, including standards and interoperability. For its part, Malaysia has implemented SNOMED CT and HL7 and is creating a more interoperable environment through the Malaysia Health Information Exchange. Indonesia, meanwhile, has some 10,000 separate HIS, with little rules, and is now in the process of implementing DHIS2. Proprietary or open source does not matter since the facilities are doing their own thing. In terms of legislation, Fiji did not want to reinvent the wheel, and took the health data policy from the Philippines and adapted it to its needs. In Bangladesh, an open source environment has taken off in the last five to 10 years, under the initiative of the current DG for Health. The World Health Organization (WHO), together with AEHIN, is encouraging the commitment to good practices starting with having an adequate strategy, embedding Cobit5 techniques for good governance within the Ministry of Health, having TOGAF (The Open Group Architectural Framework) training as an enterprise architectural certified technique.
Other examples exist. Since 2009, Sri Lanka has put in place the National e-Health Policy, e-health guidelines and standards. Currently, there is no strong support for using open source in State sector organisations, however, the government seeks to ensure that warranty terms would include statements stating that software, open source or proprietary, would confirm to stated specifications and quality assurance standards, and the government entity shall have access and ownership to the source code after the warranty period. Another clause in the policy allows for the customisation or modification of an existing licence, commercial or open source. This provides the background to call for tenders for open source implementation. The e-health policy document does not specify details around open source, which is provided in the National e-Government Policy. The agency working for this National e-Government Policy is ICT Agency (ICTA) of Sri Lanka.
Tajikistan is a small country in Central Asia with a population of eight million. It became independent in 1991, and suffered a six-year civil war thereafter. The pre-pilot phase of DHIS-2—selected because of its open source nature—started in 2008 in a few districts and is now rolled out nationally. The government selected DHIS2 because it gave flexibility of self-adjustment when infrastructure was not fully ready. An important part of using DHIS2 was the revision of data. On a quarterly basis, 70 districts were each reporting on 10,000 data elements and 3,000 indicators, which subsequently dropped to 3,000 elements and 450 indicators, 50 of them core. DHIS2 is hosted on an in-house built data centre of the MoH and intranet on a virtual private network (VPN) for making the application secure. Inter-agency meetings were held with Agency of Statistics, Ministry of Justice, responsible for civil registrations and the MFA who run civil registry offices abroad. While DHIS2 implementation in Tajikistan is a success, it runs on a forked version of 2.13, making it difficult to update to new releases. Developments taking place at the local level are not given back to the global, creating a missing link. Such local developments are taking place in many countries without links to the core. Was suggested to constitute a Board of Representatives from nations to have a voice for the global. Tajikistan has fueled two innovations for DHIS2 global. One, the development of the categories-combinations, and the second the development of the national CRVS system as a module in DHIS2. Tajikistan does not have any policies specific to FOSS, and they tend to be excluded from any procurement. However, there are well established policies around data security.
South Africa has been in the grip of a number of conflicts, and in 2012 if not earlier, students decided to rename the Rhodes University, following a movement called Rhodes Must Fall. Cecil John Rhodes came with an innovation to South Africa at a time when Slavery was being outlawed. He found a kind of tricky way of perpetuating slavery without breaking the law by introducing taxes, going on to become an influential figure in government and business. This University is named in his honor. The movement of Rhodes to Fall led to the removal of the statue but also other implications. This provides an example of context of FOSS in South Africa, since history influences technological and financial choices. One software company which tried to use Afrikaans irritated government leaders wanting to create a more inclusive society. However, there are also many dominant private sector companies such as Oracle.
People wanted to use open software to take advantage of the internet, sometimes with negative consequences. A lawyer, Priya Cheti, established the first black-owned IT legal firm, and advised government on a major procurement, which nearly destroyed her career. There are many people building open software for fun too, of African-American women developing code for their NASA project, and Nji Colins Gbah from Cameroon. South Africa had a National Advisor on innovation, heading IT coordination among the different government departments, and one of those led to the formation of the working group on open source software. There is the Southern Smile (India, Brazil, and South Africa) and summits of FOSS have been held in these countries and agreements of collaboration on FOSS developed. The Go Open campaign was also to develop leadership in e-government. The National Advisory Council on Innovation when it produced its first document back in 2002 touched on the challenges of patents. In South Africa, patents are not allowed, while copyright is to protect software rights. The Gauteng Provincial Government has developed an open innovation roadmap and released it as a public good.
The South African Constitution of 1955 includes the Freedom Charter which raises the question, If you do not want apartheid, what kind of country do you want? People gave many suggestions including to keep open doors of learning and culture. This is relevant to the current student movement of “fees must fall” as students remind government of their constitutional undertakings, and that all cultural treasures shall be open to all through free exchange of books ideas and contact with other lands. These movements are relevant to the discussion on FOSS.
South Africa negotiated an agreement with India and Brazil in 2006 around inter-operability standards for government information systems. In 2003, South Africa had its first FOSS and open standards policy, subsequently revised in in 2007. Policy-makers were interested to know the return on investment on IT and why money was spent on IT and not on doctors and nurses and health infrastructure. The widespread use of incompatible platforms and applications remains a problem, which was the impetus for setting up the FOSS Standing Committee and the creation of the MIOS (Minimum Inter-Operability Standards) document. The Department of Science and Technology has an agency called the National Advisory Council for Innovation which conducted research on Open Standards and Open Sources and sent to the Cabinet, the highest executive body in the country. It was concluded that open standards are a non-negotiable base for ICT in the public sector, from which the FOSS and open standards committee was formed. The MIOS was updated in 2011 and the government signed the open government declaration that recognises the importance of open standards to promote civil society and enhance the interoperability of government information systems.
South Africa wanted an open source implementation of the standard, described through the ideas of a canary in the mine. If you walk in a mine and if the canary dies it means the mine is poisonous and you have to get out quickly. To ensure that this really is an open standard, there must be open source implementation. One of the success stories of South Africa is Mark Shuttleworth, involved in the SSL component of the Apache project, and later established a financially successful company. He then started Ubuntu, a southern African word meaning “I am”. There is also Ushahidi in Kenya, a successful open source project. South Africa invests heavily in building awareness, and every government IT official knows about FOSS and associated policies. TV campaigns are also held together with companies.
In South Africa, every national department has a Chief Information Officer, and there is a Central IT Agency (CITA) parallel to the NIC in India. CITA faced challenges of poor capacity, and weak project and programme management. Often the vendor kept IP for a system which the government paid for and also for its royalties over 20 to 30 years. The drive towards FOSS was to address such challenges.
Australia has a national health data dictionary with many data elements whose use is mandatory for any new system development. The Australian government had made it mandatory for all systems to report data on national minimum dataset. This is not only in Australia, and all 36 OECD countries have some form of national data dictionary available. If the centre is not ready to come up with standards, States take their own stand. The Australian example is not about sending all data to the centre, but about government asking data on few parameters centrally to generate national statistics required for policy and programme purposes.
-
Human resources for health, FOSS
In India, 70 percent of the population living in 600,000 villages have poor access to healthcare, while delivery of healthcare is concentrated to 5,000 towns and cities. The entire medical education is urban-centric and hospital-centric, where public health is marginalised. There is a reluctance among doctors to serve in the rural areas, despite various incentives. Further, there is a problem with the MBBS system which does not encourage rural service, and the focus is only on cure and not prevention. Even though malaria is the biggest killer, for example, it is not getting emphasised enough. In this context, it is important for states to be given the flexibility to decide what they want to do. NRHM had that flexibility, and that is why Kerala could work with HISP to roll out DHIS2. Such a decentralised model may not work in other states. There is also the problem of lack of data. The MCI does not know how many doctors are working in the country, or how many of them have died or left for overseas. The same is true in the case of nurses, pharmacists and dentists. In this world of digitalisation, it is criminal not to have these figures. Is it deliberate that the country is unable to register online some 500,000 doctors who are produced annually in the country? The question is not about open or closed source, but about taking relevant stakeholders on board.
Building capacity in FOSS is not only about software technicalities, but also broader understanding of thinking such as that free software is not free. There are knowledge gaps, misconceptions, myths and undue expectations of what FOSS can provide. Overall, there is a weak understanding of what it is and the surrounding issues, including strengths, weaknesses, possible approaches, and previous experiences. There are a lot more things required, including capacity, infrastructure, long-term support, cloud hosting, and managing servers. From the perspective of states, what is the capacity that needs to be built over time? Should it be on customisation of the software, technically dealing with the software or on use of the information, the analytics, application to addressing health problems. These expectations are poorly understood and suffers because of continuous movement of technical staff. It is thus difficult to build the community on a long-term, sustainable basis. Different capacities are required for building and consuming the platform. An institution like PGI could be useful to teach data analytics and more technical groups are needed to teach on the production side. In FOSS, the country needs to move away from the traditional model of training to more collaborative and peer-based leaning models putting the onus on the individual to learn. This requires a more proactive engagement rather than a more passive, receptive model of classroom teaching.
There is space for more advocacy and orientation workshops, use of social media, and conscious linking up with FOSS communities at the global and national levels, and groups of academia, civil society, NGOs, and communities of practice. Inspiration can be drawn from Mohammed Younis, founder of the Grameen Bank who argues that there is a lot more to human beings. If, for example, an individual is trained as a software engineer, it does not mean that a person cannot be engaged with issues that are economic in nature, given that this is an era of a highly connected world and the Internet of Things. This can be thought of as the ‘internet of people’ which the country must cultivate. This is not emphasised enough. In a way it is partly what is driving the success of FOSS phenomenon. Many contributors in this domain come from outside the technology space, including legal professors who have promoted a commons-based approach.
India often fails, because training responsibility is placed under the central or state information technology agency and, as a result, the task gets buried. Some other countries have succeeded. Malaysia has got an effective free and open source project office. Spain has got an impressive free and open source software project and Brazil has done well at the central and state-level information technology agency. Italy has the Libre Office project. In collaboration with government, the idea of a project office can be created such as those in Spain, Brazil and Malaysia.
II: Key Recommendations
A key aim of the ORF workshop was to identify policy-practice gaps that impede the realisation of the potential of FOSS-based solutions to strengthen public health information systems, and with it, health systems more broadly. While the two-day workshop covered discussions from multiple countries, the gaps identified are specific to the Indian context. In identifying these gaps and how to address them, the workshop participants have drawn upon learnings from more than two decades of research in information systems that has taught Indian policy-makers that “airplanes do not fly, airlines do”. This implies that FOSS technology on its own can do little, and for it to be effective it requires various socio-technical elements such as policies, institutions, people, capacities, histories, infrastructure, practices and other things to come together. Policy, which only focuses on the FOSS artefact, will undoubtedly be inadequate as many more things are required. To understand what these “many other things” are, this report draws upon the framing of GPG and its characteristics of non-rivalry and non-exclusivity. With this framing, policy-practice relating to knowledge, governance, procurement and capacity are identified.
The knowledge gap:
The knowledge involved around FOSS is not uni-disciplinary that it relates only to computers and software; rather, it is multi-disciplinary, involving informatics, public health, and implementation research, among others. Knowledge needs to cover domains of both the production of FOSS and its consumption. Production involves technical knowledge of software engineering, standards, design, and programming. Consumption concerns knowledge about public health, governance, participation, implementation, and global networking, among others. Such knowledge is not easy to mobilise in practice, leading to a knowledge gap. This gap is magnified because of the uneven knowledge existing across and within countries, and between private and public sector settings. If core development of the FOSS platform is centralised in the West, national users in developing countries face knowledge and infrastructure constraints in fulfilling their core requirements, which in turn contributes to creating dependencies.
Policy efforts to bridge the knowledge policy-practice gap could include the following:
- Building broad awareness about FOSS, its advantages and challenges.
- Identifying institutions and experts relevant for different knowledge domains.
- Publishing government approved lists of FOSS applications and solution providers.
- Providing incentives for institutions to engage in multi-disciplinary collaborative projects.
- Enabling global networking and collaboration to encourage building perspectives that represent state-of-the-art knowledge.
The governance gap
Governance is an overarching concept that covers all areas identified as policy-practice gaps. It broadly involves establishing mechanisms on how choices are made related to procurement, establishing criteria to designate experts, selecting standards and various others. Governance of FOSS-based solutions is by design a complex task, as it involves bringing people together from different institutions, disciplines, and health programmes representing a variety of (sometimes conflicting) interests. In India, the governance gap is pronounced because ICT-based projects are initiated by senior administrators, making these initiative heavily dependent on individuals. Once the administrator leaves his/her positions, typically within three years, the initiated project tends to fade away. ICT projects for the government typically involve development through agencies such as NIC and CDAC which tend to be technical and computer-science oriented, marginalising required social sciences and humanities knowledge. Historically, health departments have worked within isolated and compartmentalised frameworks, and establishing governance frameworks that are inter-departmental or inter-ministerial are in conflict with the existing working culture. Establishing multi-sectoral governance frameworks are difficult for logistical reasons to get participants together.
Some policy efforts to bridge the governance policy-practice gap could include the following:
- Ensuring that government supported FOSS initiatives define governance frameworks, that explicitly address concerns of sustainability and scalability.
- Establishing mechanisms by which relevant stakeholders are given a voice in the process of how choices are made and implemented. In designing such mechanisms, it must be acknowledged that enabling participation is a political process, where certain stakeholders have more power and resources than others, leading to governance gaps.
- Establishing higher level governance frameworks to approach questions of standards, platforms, hosting, and building collaborations, including broader representations of experts, academia and civil society activists.
- Establishing strong mechanisms, including incentives and disincentives, for implementation of policies relating to FOSS, for example, to ensure all vendors publicly publish their APIs and deposit all code to public repositories.
- Publishing case studies of how other countries, especially leaders in FOSS such as South Africa and Brazil, have approached the challenge of governance, and discuss how these can be adapted to the Indian context.
- Donors supporting FOSS projects should do so within established governance frameworks, and not creating something new that is in conflict with government policies.
The procurement gap
Government systems have historically procured software based on tenders which pre-specify requirements, and tend to be biased towards large and commercial firms providing proprietary solutions. Organisations specialising in FOSS solutions, typically smaller NGOs and university departments, tend to get excluded from such procurement processes. Tenders also club together hardware, support, data center and software in one document, and specify financial criteria of organisations to bid for these tenders. Such an approach excludes specialist software firms from participating. Another contributing factor is the misconception of government administrators that FOSS implies that everything is free – including licensing, support, training, specific configuration, and server hosting, among others. The reality is that only licensing in FOSS projects is without costs, and other aspects such as training and support need to be budgeted as in any software project, whether FOSS or proprietary.
Some policy efforts to bridge the procurement policy-practice gap could include the following:
- Encouraging FOSS providers to detail out TCO (Total Cost of Ownership) over at least 3-5 years, making all elements of the costing explicit.
- Providing better orientation to government procurement agencies of what cost elements are included in FOSS budgets and what are not.
- Encouraging development based on platform principles of “build once, use multiple times”.
- Developing innovations in tendering processes to overcome limitations of experience in procuring FOSS-based systems, including the ability to develop tenders where the requirements are necessarily fully pre-specified. Tendering models could encourage the building of requirements as a part of the project evolving through a collaboration between developers and users, rather than being pre-specified.
- Other innovations could include creating a level playing field where multiple prototypes are allowed to be created and then objectively evaluated for making final selections.
- Decoupling procurement of software from other aspects of ICT projects including hardware, hosting, data center services etc. Entry level conditions should be relaxed for enabling smaller groups (NGOs and university departments) to bid for FOSS related tenders.
The capacity gap
The views expressed above belong to the author(s). ORF research and analyses now available on Telegram! Click here to access our curated content — blogs, longforms and interviews.
PDF Download
PREV
