Prison architecture based on the panopticon principle. What is the analogy with information systems?.
Digitization of Health Services: Part II
Designing health information systems that are fit for purpose!!
Conversation between Dr Akshay S Dinesh (ASD), Dr Amit Mishra (AM), Professor Sundeep Sahay (SS) and
Professor T Sundararaman (TS)
ASD: In our previous conversation we discussed that Ayushman Bharat Digital Mission (ABDM) primarily focuses on digital health infrastructure for exchanging health records, but non-digital pathways are crucial for its success. ABDM is thus addressing the requirements of an uncertain future. But there are many existing functional digital systems serving public health functions outside ABDM, like those for maternal-child health and disease surveillance. Are these health management information systems (HMISs) effective, fit for purpose and efficient?
What is the use made of all this data generated? [Note: “HMISs” here is a generic term to refer to any government health department’s public health management related information system. This is not to be confused with one specific system that was started under National Health Mission in 2008 which is called HMIS and which we will refer to as HMIS-NHM in this conversation.]
TS: There are now more than 20 functional health management information systems (HMISs), each of which is an ongoing flow of information from peripheral health care providers and facilities to state and national programme management units. This would include three major systems which largely have information related to Reproductive and Child Health (RCH). These three are the HMIS-NHM, the RCH portal and the U-WIN portal for immunization. Other IT separate systems serving RCH service delivery include one for special newborn care units (SNCUs), the Swasthya Kiran system for Rastriya Bal Swasthya Karyakram (RBSK), the family planning logistic information system (FPLIS), and systems for reporting on implementation of the PCPNDT act (viz- sex determination) and the Medical Termination of Pregnancy act (MTP).
Then in the area of communicable disease we have independent HMISs for the End TB programme called NIKSHAY, for the HIV control programme, and for six vector borne disease control programme that includes malaria and dengue, and one for Viral Hepatitis. For non-communicable diseases, you have an HMIS for sickle cell disease and two for non-communicable disease.
Then there are daily and monthly facility reports from Health and Wellness Centres (HWCs): and the e-Sanjeevani for telemedicine, and another NCD report.
We also have hospital information systems; and there is an ASHA reporting system. In some states the health department also files the mortality report. We are talking only of systems as something that requires reporting from the primary health care providers and which have information flows all the way to the national centres. There are others, including some started by states. We are also restricting this discussion to those within the accountability of the health department. This elaborate listing is to provide the necessary background to this conversation.
SS: But you forgot the monster among these, Sundar, the IHIP? And I think ANMOL should also be added to this list.
TS: Oh yes, I know I was missing something there…. yes, the IHIP of course. IHIP or the Integrated Health Information Platform serves the Integrated Disease Surveillance Programme (IDSP) and Sundeep is referring to it as such because it requires the full case sheet equivalent details to be entered for all outpatients for a list of about 30 diseases. But this is not the only portal that requires name-based entries where health records of individual patients are entered. Name-based entries have a much higher work-load as compared to entry of aggregate numbers. The RCH portal, the UWIN and Nikshay and HIV portals have a similar high data-load requirement that name based entry involves.
And many of these name-based entries now have “apps” which is a software loaded on a smart-phone that allows digital entry by the front-line provider. ANMOL (acronym for ANM-Online) is an “app” that ANMs use for entering data on pregnancy care and receiving follow up prompts. The data going in is identical to that going into the RCH portal. In many states ANMOL has become an app-based portal of data entry into RCH portal- and so it is no longer a duplication. At the district hospital/CHC or PHC the data is first written down into a recording register and then manually entered into the RCH portal. The RCH portal is able to accept both forms of entry. There is some confusion and problems regarding two streams of data entry especially in preventing duplication, but essentially these are last mile problems rather than major issues- and so at least with regard to ANMOL and the RCH portal some degree of integration has taken place.
SS: I see ANMs relying on ANMOL for their outreach, in the form of receiving weekly prompts on the mobile phone on whom to visit. I think that’s useful for them. However, in Orissa we saw a lack of synchronization between ANMOL and RCH portal, more from the medical officers.
ASD: So now the question is, and knowing that none of these HMISs are interoperable except maybe ANMOL with RCH portal, what is the use being made of all this information on flow. A lot of data goes up but what comes back to those who provide data. Is there any improvement in work performance? What is the purpose of all of this data collection? How does it help?
SS: I think it’s a problem which has existed for many years. We have written about it in an article in EPW called “Where does all this data go?” The problem is getting aggravated, particularly for the ANMs and now for community health officers (CHOs). Many I met, report that over 70% of work-time is now on data related work, and this is seriously compromising their caregiving work. I think these problems will continue unless we think about data architecture, not just software architecture. One reading of our ABDM discussion is that it is primarily about the software architecture. This needs to shift first to a data architecture, and then examine how an appropriate software architecture can support the data architecture.
TS: Let me try and describe the crisis in public health management information systems. Digitization of HMISs has increased the burden of data-work, reducing the time available for healthcare and not contributed measurably to improved outcomes. There is vicious cycle that has been set up between poor data quality and poor use of information. Even when use of existing information is so low, there are relentless pressures to further increase data collection. To understand the determinants of this vicious cycle, I would refer to the readers to a 2011 online NHSRC publication, the HMIS Resource Persons Manual. This was part of a series of four manuals, all of which is good reading, but this manual is particularly useful to think about design and about data quality. This 190-page manual details the NHSRC’s learning from the field and is still just as relevant today as it was 14 years ago. To make this Manual more accessible to the average public health practitioner, we have created a “Beginners’ Guide to HMIS Problematics”, in power-point format that you could flip through. In summary, the determinants of data quality are best seen as a composite of issues pertaining to organizational processes, procedures or processes followed, and institutional capacity. Honesty and integrity in reporting is not the main issue and to the extent it is an issue it cannot be solved by name-based reporting. But attributing poor data quality to false reporting prevents us from thinking about the issue
Lack of data reliability has many causes. Many publications have correctly drawn attention to infrastructural issues. These include lack of human resources, unpredictable internet availability, lack of offline recording and reporting systems, the ability to provide on a dynamic basis the appropriate smart phones or tablets, especially when they are overloaded with four or five apps, or their data limits are reached or for other reasons compromised. Further delays and data gaps can be due to first entry into primary registers or apps, and then physical transport to block or district level to enter the data into the computer. Where name-based records are to be entered these delays are so much, that incomplete entry is the norm rather than the exception, even if apps are used for entry.
Reasons related to data architecture have drawn less attention. One example of this is the excessive data elements required in recording and reporting formats. Too often, the underlying logic seems to be to disaggregate each function into a number of activities and place a data element to monitor each. Or each activity is further disaggregated based on attributes and each reported as a separate data element. For example, the health sub-centres HMIS-NHM reporting format has over 350 data elements of which 38 relate to antenatal care, 37 to deliveries and after and 21 to the anaemia control program, 15 for family planning and over 50 just related to immunization. Most format cells would invite a “0” but the meaning of this would be unclear for it could be due to non-reporting, or a reported non-event, etc. All together it could reach over 1000 data elements- and most of this are not used for any corrective action.
Poor data quality is often attributed to using only aggregate numbers and name-based reporting was introduced to solve this. But this increases incomplete reporting. For example, in IHIP-IDSP, every PHC has to report every diarrhoea and every respiratory infection on a name-based basis. In practice the provider picks two or three cases out of the 20 or 30 cases and reports these, but this is neither a random selection nor purposive- it is an arbitrary pick to tick the box- data reporting completed!
I also think incomplete and poor-quality data relates to the fact, that those who provide the data get very little useful feedback except for the reminders or to-do lists of the ANMOL-RCH. But these reminders are entirely based upon their own data entry- and hence it is not very clear why it is so essential or whether there is a simpler way of getting there. For the service provider, much of this data work becomes a huge and unproductive burden.
SS: We have multiple systems reporting the same data, but with significant discrepancies. For example, a PhD student analyzing dengue surveillance in a large state found that the IHIP and NVBDCP systems reported vastly different case numbers for the same period—15 vs. 75 cases. The discrepancies were due to factors like selective reporting, differing standards for defining positive cases and outbreaks, and variations in data entry processes. Similar issues occur with duplication across systems like HMIS-NHM, RCH portal, and UWIN, where over 120 data elements are entered multiple times but never match due to inconsistent standards and entry challenges.
I would also draw attention to the problem of primary registers where data is recorded. ANMs are dealing with over 30 registers and these are in addition to the apps! The problem is well acknowledged but never addressed. In a field study in Punjab there was nearly 60-65% duplication of data being entered across these registers. Duplicated data is about an individual’s identifiers, but also about health events and health services delivered. A unified data base at the primary care level would be a good place to start addressing issues of the data architecture.
AM: I would take that to mean creating an electronic health record at the facility level. We know that ANMs maintain and write into many registers. We could take an existing app like ANMOL which records RCH services and expand it to include all services and what we would get is an electronic health record system.
SS: To a certain level I agree, but I don’t think every report needs to be patient-name-based. A lot of aggregate data also needs to be collected.
ASD: I was wondering, is such centralization the answer? Will making everything be part of one system work? Or should we say that this diversity is natural and some of this friction is to be expected and that is good for the ecosystem?! Is the National Digital Health Authority working on this problem?
SS: We need to rethink how digitization supports health systems. Many service delivery problems are institutional, not digital, and digitization alone cannot address them. New systems like IHIP and MCTS have been introduced with the goal of replacing older ones on the logic that AM is suggesting, but existing systems continue, increasing the workload for health workers without improving care. To make digitization effective, we must first address systemic issues and define role of digitization in improving healthcare services.
Data in health management systems needs to be converted into actionable indicators. At each level of care, relevant indicators should guide action, and only few indicators are required at the top. But current systems lack a clear hierarchy of indicators, with all data flowing upwards instead of being tailored to the needs of different levels. The ABDM, for example, seems focused on transaction-based systems rather than decision-support or addressing critical health challenges like antimicrobial resistance or climate-related health issues.
In countries like Norway, health data is managed locally, and national registries are primarily for research. Larger countries, by contrast, should prioritize decentralization. ABDM’s focus on automating transactions misses the opportunity to address urgent health system problems, where digital technologies could play a larger role.
ASD: I see that you are drawing attention to both the use of information to inform public policy in addition to public health management? Is our HMIS fit for that purpose, given the fact that it records mainly public service delivery and much of healthcare is by the private sector?
TS: One particular problem with use of HMISs in public policy is the lack of private sector data. There are two ways to look at it. In the short and even intermediate terms we must accept that public health management information systems are most appropriate to better manage public health service delivery with better resource allocation and better outputs. For population-based data required for policy purposes we should continue to depend on surveys. And do a good job with this. I think this is an acceptable solution. you should not arbitrarily take private sector data, with varying degrees of coverage, quality and completeness and add it into the data from public facilities.
Meanwhile, as a parallel effort we should develop portals for private providers to report on, and be able to show private sector data as such and avoid its duplication. We do have legal provisions to enable this. In states that have tried this, the private sector has responded by saying, yes, we are ready, but we can’t do this for hundreds of indicators. You give us 20 or 30 indicators, and we will do it. I think this is a good opportunity. Let us persuade programme managers to prioritize a short list of indicators for private sector. And that logic may help you reform your public sector data collection also. I think for this reason and for innovative thinking, an engagement with the private sector is useful. I think we should go ahead with that..
This will progress gradually and the progress will vary across different state and district contexts- but we can live with that.
But even now, in addition to surveys, we can develop sentinel district-sites where we have comprehensive public health data from both public and private providers, which when used in addition to mortality data (discussed in earlier conversation) will provide quality evidence for public health decisions, even on emerging issues like climate change and OneHealth.
ASD: Even if we don’t think about these future problems or big problems, we can say that the public health management information systems taken together are in a crisis situation, characterized by excessive data collection, poor quality of data and little use of this information, and persistent pressures for more health information portals, more apps and more data collection. What explains how we have got into this mess?
- TS. The fragmentation of health information systems is a reflection of fragmentation in health systems itself. Health information systems operating in siloes, each with its own standards and data flows and this mirrors the fragmentation of primary health care into disease specific programs having separate funding, authority, and monitoring mechanisms. As healthcare expands, adding more verticals creates unsustainable and impractical demands on information systems. But disease-centered public health planning is unable to think beyond the vertical approach and conceptualize an alternative horizontally integrated primary health care approach and its concomitant monitoring system.
Further all of public health workforce management is based on a tradition control and command hierarchical approach- an inheritance of our colonial past. As general administrators from the civil services take over directorate’s technical functions this only gets reinforced. It seems that more modern human resource management understanding of worker motivation and performance are not in play, and the design of monitoring systems reflect this.
Early efforts at health sector reform often emphasized the importance of monitoring with the popular quote “If you cannot measure it, you can’t manage it” or something similar attributed to Peter Drucker, the Management guru. Well, the Drucker institute itself seems to have clarified that this is a misinterpretation. In fact, while measuring is important, it is not easy to measure the most important functions, and management is much more than such monitoring The emphasis should be on social relationships, that current monitoring-driven approaches to management often undermine.
Digitization of health monitoring was once the major component of health sector reform Ironically from being the subject of reforms, HMISs has become one of its main objects. There can be no health systems strengthening without HMIS reforms.
ASD: Could you describe some of the essential principles that must guide HMIS reform? Have these been stated before?
SS: When we were working together in NHSRC we had evolved a few principles of design which to my mind are still quite valid. Some of them are simple intuitive principles. Others are based on recent experience in implementation and still others on a theoretical understanding. Not all of them are necessarily validated- and we can disagree on some, but if there is to be a reform of HMISs then it has to be based on some agreed-on principles, guided by which different managements can develop their systems. The current comparator is one dominant person saying that since we have all these problems with existing systems, let me introduce a new system replacing all the earlier ones. And then the cycle repeats.
- No data should be collected and reported more than once.
- Every data collected should contribute to at least one indicator (implying that these are contribute to usable information.)
- There should be a hierarchy of indicators- with many more indicators available at facility and district level, less at state level and least generated at national level.
- There should be a provision for correction of data entered up to three months at least – with authorization of the district health officer, and these corrections should be visible on a data audit trail.
- Except for certain events that come under disease surveillance, there must be no daily reporting requirements- as this adversely affects the ratio between service provision time and data-work time and because data analysis and corrective action is not on a daily basis. Monthly reports are adequate for almost all data needs.
There has to be guideline document on data and indicator definitions for purposes of standardizations. Further this has to be recognized as a dynamic document, with an updated guideline showing version number and the most recent updates.
AM: I think these principles can also be extended to digital facility records. A digital facility record is a computerized, comprehensive primary registers collecting all required data on a standard format- where aggregate numbers of relevant data for each programme from each facility can be exported to the information systems of the relevant programme. Such a unified health record would solve most problems. If the system can fetch demography records from the ABHA ID, much of the problem of the repeated entry of the demographics would be solved. The health service provider has to just enter the details related to the health service delivered which will save their time but also will as part of the process computerize all the records.
SS: But Amit, how will they fetch records? I mean, then you’re sort of implying that they need to access some server and download the demographic data for every individual act of health service delivery. But that’s not really feasible at the primary care.
AM: I agree with your concerns. It has to be integrated in some way. I’ve just looked at the different settings. I don’t think that you can ignore computerizing the primary records for a very long period of time. I think this is also essential to get correct aggregate numbers. I agree that current systems of building electronic health records are not providing for culling out aggregate numbers across records, but this can be done. For example, this happens in England and Scotland.
TS: If I get what you are saying, Amit, the service provider will record most of the services she provides on to one or more digital apps, and in the back-end all entries gets documented into an electronic record specific for each patient. From these records, the necessary aggregate numbers required for the various reports can be generated. Vertical-disease specific supervisors could cull out the data related to their programmes as digitally generated programme specific registers which is what they are used to. For example, if her first out-patient for the day is a TB patient, the second is a pregnancy test, the third is a child for immunization, she enters her workflow; the workflow is documented digitally and will feed into the respective database of programmes.
AM: Yes, that is what I would advocate. And I would clarify that I am not talking of one centralized health record, and we should allow multiple options to emerge.
SS: I remember when we were in Himachal, we were talking to the doctors who we found were filling up data on their OPD encounters in the EMR system and we were asking them why and what can we do about it. And I think one guy gave a very interesting answer. He said, I see 100 patients a day, 85 of them are very routine cases like fever, fracture, headaches, all that. Why do I need a record for them? I don’t need a record for them. I need a record for the 10% of people who are coming with chronic diseases like TB or cancer or HIV. Let me just fill up the records for that 10%, it’ll be more relevant for me. Let the other 90% be dealt with through a triage kind of thing. I hear Sundar saying the same thing- why collect data we do not need. I remember this conversation when we were working with NVBDCP on malaria and they wanted to track every suspected case of malaria. And the guys in Orissa said, if you try to do that, the whole population would be suspected. But if you just want to track positive cases, then it will be more manageable for us and it’ll be more actionable. So similarly, I think we have to look at the level of the ANM on what she needs to take action, what is that information she needs? And the other stuff could be just taken as counts. You know, not as detailed patient records.
TS: In principle I have no objection to what Amit his suggested and this could fit in very well with the ABDM and its unique ABHA ID. But what has been the experience? The IHIP started as an effort to create one unified record that would handle all health encounters, but it landed up becoming another vertical portal with incomplete data even on its core requirements. The RCH portal was another such effort to create a unified record at least for RCH services, but that is also a vertical. The main barriers are not technical – they are institutional. But we could encourage efforts towards the creation of an integrated electronic health record suitable for use by multiple health programmes.
Till that happens, we should take an incremental approach, where we try to rationalize existing system. In parallel as the most immediate measure in this regard we must ensure there is sharing and use of information at the district and sub-district level and across the different boundaries. This use of information should take the form of an active conversation around the data, so that discrepancies are understood and attended to and meaning is made of existing data. If the institutional processes for this can be established, then digital inter-operability is a step nearer. But there are some design changes that are required in the software too.
ASD: So let us move from data architecture to software architecture. What are the principles of software architecture that would encourage the decentralized use of information that you are suggesting?
TS: With regards to software architecture, we would suggest the following principles:
-
- The centre should only specify its indicator needs and the data quality standards and the portal on which this data needs to be posted. It should not demand that all facility level data entry is directly into the central application. States can use their own applications as long as they can fulfil the core indicator requirements of the centre
- Applications in use either by the centre or by the states, should allow for facility managers and mid-level managers to not only see their data but be able to drill down for local analysis and use. Currently most systems are designed to facilitate analysis and use for the top, which cuts out district and sub-district possibilities for analysis. Yet most management correctives must take place only at these levels.
- Applications in use should allow information to come in both as name based records or as aggregate numbers. It should allow for the fact that the granularity of reports will vary based on institutional capacity at the local level, and the applications should allow for that.
AM: But availability of such a system which provides for different levels of granularity of reporting is a utopian task. Your idea is a very romantic ideal — to have such a system which addresses complexity and is designed for complex adaptive systems. But in reality such a system doesn’t exist. I have not seen it happening anywhere. I think we must insist on computerization of primary records at the facility level, which can then be integrated with all other systems to feed them necessary data whether it is aggregate or name-based. I think that will help solve the problem. Given the mandate of ABDM, I would even recommend to have a large program to computerize primary registers where we build a single interface to be used for data entry into all existing HMISs. I see manual recording in primary registers as a major problem and every other reform has just ignored it. We cannot look for an incremental solution for a problem which was there 30 years ago and would remain same for next 30 years if nothing major happens.
TS: I see that each of us are finding the ideal of the other as utopian. Let me map my areas of agreement and disagreement with you. I agree that we must proceed towards computerization of primary record on the lines you describe. Further to the extent possible, it requires embedding digitization into the workflow, instead of digitization being a separate additional process. I would caution that we should not mandate a single centralized health record template and states could develop their own. Central programme monitoring systems should have technical provisions for inter-operability, so as to receive data for their needs from state systems.
I prefer this ideal of multiple decentralized, interacting systems to a centralized singular architecture. There are larger philosophical and political problems with such centralization. And there are pragmatic reasons also against it. No one currently has or should have the power to impose this across the states. The Centre could (though it should not) impose the IT system of its choice. But even then, state systems would persist because there will be state requirements for data collection and analysis that are more or different from what the central IT system allows, or even just because they are familiar and comfortable with their existing system.
I would disagree that no systems exist that can do this. Not by choice but by compulsion, most systems even as now combine data coming in with varying quality, completeness and granularity to arrive at usable information. We need to accept this and build on it. Let me take you back to the November 10th 2008 letter of the then Mission Director, GC Chaturvedi’s, which established the HMIS-NHM. That order basically stated that the central government has specified the data and indicators that it requires and will provide a portal for uploading this data. But the state can have its own IT systems, but would upload the centrally required data into the central portals through a digital connectivity link. Many states went ahead and developed data reporting systems of their own- often using DHIS2 platform customized to the states needs and readiness. DHIS 2 is a very decentralized-user friendly application that is now the global norm.
But those were the heydays of decentralization and district planning. Unfortunately, subsequent development of systems did not use this approach. And every time the centre comes up with a new web-platforms, states are pushed to changing over. Currently for example Tamil Nadu is refusing to abandon its state (Pregnancy and Infant Cohort Monitoring and Evaluation) PICME system and switch over to the central RCH portal. The RCH portal could have some advantages, but the state PICME portal has evolved and stabilized over a decade, is familiar to all its users and is essential for the payment of the maternity grant of Rs 25,000 in five instalments. If they are forced to change to RCH portal, they may still have to run the PICME portal for their needs. But the RCH portal has no way to accept the transfer of data from PICME to itself. That’s just bad design thinking. And the love of centralized solutions.
If states cannot develop their own software, the Centre can provide a default option, but this is different from enforcing that all states upload on a central portal. The ABDM policy document does recommend such decentralization, but there is no attempt to follow this, especially in HMISs that serve public health needs.
ASD: You mentioned DHIS-2 as a global norm. Can you tell a bit more about it?
SS: DHIS2 (dhis2.org) is a free and open-source digital platform which provides the flexibility to be customized and adapted to multiple use cases with limited core computer science expertise. District Health Information Systems-2 (DHIS2) was first born in Kerala India in 2005, involving collaborative development between developers from HISP India and University of Oslo, Norway students in 2005, and was evolved and taken into states of Kerala, Gujarat, Jharkhand and Madhya Pradesh, with NHSRC playing a significant contribution to developing its use of DHIS2 for decentralized analysis and action. The development of this platform was subsequently taken up by a development team at the University of Oslo who have further evolved it into a robust global public good which has been adopted by 80+ countries and also by WHO in the framework of a Collaborative Centre agreement with Oslo. Unfortunately, even as DHIS2 has been adopted globally, it gradually lost its roots in India.
ASD: Okay, so I was thinking, that perhaps the reasons for the crisis lie in the mix-up of two purposes of data collection. One being public health management- where data is used to identify the gaps in service delivery thereby enabling corrective action, and the other being management of people’s behaviour and the surveillance of performance. These different purposes require different data architectures.
TS: Interesting that you suggest this. A concept that can help understand the HMISs paradox of, on one hand public health systems demanding reporting, often on a daily basis, on over a thousand data elements, while at the same time making so little use of information, is the “Panopticon”. This term was first used for prison architecture, where from a central watch-tower, the activities of all inmates and wardens can be constantly observed. Typically, the “watch-tower” of this panopticon, is empty. It is the very fact of being under constant surveillance, that leads to inmates aligning their behaviour to the prescribed norms. “In a control logic, the HMIS is a tool of constant surveillance of the workforce—a panopticon, in the sense that sociologists use the term (Foucault 1975). It sets out a grid of expected actions, behaviours, and reports from the workforce. It is not the actual analysis and use that leads to change, but the very existence of such an all-seeing eye would bring about the desired behaviour change.” (Sundeep Sahay et al, 2017, page 67). As a system of surveillance encouraging providers to conform to a specific behaviour the HMIS paradox begins to make sense. Needless to say, the panopticon does not work. If on the other hand the point was using information to drive corrective action, then it calls for a different data and software architecture on the lines we outlined earlier. There is a catch-22 in this recommendation. Whereas the panopticon implicitly holds the behaviour of peripheral providers accountable for all programme gaps, an information-use driven architecture is likely to point fingers upwards at senior management and governance failures.
ASD: We have discussed some principles of design related to data architecture and software architecture. You also mentioned that there are some ethical or value-based principles, that should inform design. Could you spell these out:
TS: First principle: no person can be denied care on the basis of a lack of ID. Remember Pasteur’s maxim for all healthcare providers “One does not ask of one who suffers: What is your religion, what is your country? One merely says: You suffer and that is enough for me.” The Hippocratic oath, and the modern updates of this medical pledge, should remain the supreme principle. Of, course a care-seeker without an ID may not be able to access his past health records, but that can never be grounds for refusal of present access needs.
The second principle is something Andy Haines, then Director of the London School of Tropical Medicine and Hygiene, mentioned in a talk in NHSRC in 2012, when discussing the famous collapse of the digitization efforts of the NHS-UK (2002 to 2011). The principle was that the data that the HMISs requires providers to record must be useful to them, and only as a collateral, from these records, must you generate the data that the rest of the system requires. This would lead to more reliable data and a better flow. Digitization should reduce the burden of data work on the provider and not increase it.
The third is regarding data privacy and confidentiality. With regard to health records, the ABDM guidelines are in the correct direction. Records will be stored with facilities, and accessed by other providers or authorities only with informed consent. But policy and guidelines are not enough, and it requires the backing of a data privacy law which provides for penalties if rights are violated. This principle should also extend to patient name-based data. Only anonymized, aggregate data can be shared. This principle has implications for current name-based data systems used for monitoring or verification purposes, where protocols that safeguard privacy and confidentiality must be put in place.
Finally, we need a data policy, built around the concept that all data collected by public health management information systems must be seen as a public good, while respecting individual privacy. Which would mean that aggregate anonymized data must be made available on the public domain. With regard to legacy data, the data policy should clearly state what data would be saved, and for how long, and where and in what form and the rules for access to such data. We note that the lack of availability of data to the public and to researchers has made it much harder to identify and rectify flaws in data quality. During early NRHM days, HMIS-NHM data up to district level was available, analyzed by multiple researchers with technical support institutions and commented upon. That spirit has to be revived.
AM: I would also like to add that there must be a guideline or a policy that all systems have to have to finally deposit their data into some kind of a central repository for researchers to access the data. If that doesn’t happen, this problem of ‘me using my system, only you using yours, I’m not sharing data’, will be there. So, if states agree that okay all central and state system will deposit their data into central repository for research purposes, much of the problem can be solved later.
SS: Before we close, Sundar, I would like to draw attention to some important gaps, that this entire digitization of health effort is not addressing at all. Much of what you have discussed is the work we did in 2008 relating to excess data. But there are also important new gaps. I think we are entering to a stage where there are large problems like anti-microbial resistance, (AMR), climate and health, heat as a health issue, environmental health or OneHealth and others. I think the system should be geared to look at these challenges. On AMR, there are two systems, one from ICMR and one from NCDC. And they both have a small sample of about 25-30 facilities each from where they get data. But that data is really to report it into GLASS (Global Antimicrobial Resistance and Use Surveillance System) and WHONET, but nothing for local level action at community levels where the problem is most acute.
There is little acknowledgement of these issues and there’s no demand for AMR related data by the authorities. So, there are no budgets, and there is no game-plan for addressing this. There are also new tools like AI and machine learning that have become available and maybe potentially relevant to engage with these larger problems based on more complex and multi-faceted data, which we have not discussed.
ASD: Just last week I was reviewing a PLOS article, on facilitators and barriers for digital health, where the discussion was entirely on hardware and people issues-low digital literacy, poor network, malfunctioning device, stigma, application malfunction, difficult to understand language and so on? There was no mention of these issues on data architecture and software architecture and ethical principles that we have discussed. But what is to be done- at the level of the district manager or even a state mission director? We cannot conclude that no digital systems should be deployed unless we have built the necessary capacity and addressed these issues. We cannot even stop the introduction of newer systems. Is there any recommendation for what health systems managers can do now– even as we all hope for digitization-reform to kick-in at the governance level.
TS: A key starting point for state and district managers is to encourage the use of available data for public health management, especially at facility, district, and state levels. System managers should analyze data across systems. Poor-quality data shouldn’t prevent its use—messy data still tells a story. Multi-stakeholder “ conversations over data” involving public health experts, program managers, data providers, and others help identify discrepancies and guide corrective actions. Capacity building for data analysis is also essential, as it often requires contextualized public health knowledge. And a third more difficult suggestion is for using the current HMIS-NHM system as a central organizing node of information flow with aggregated data from other systems feeding into it, and being compared and analyzed to understand discrepancies. Discrepancies between systems can help identify process-related issues and help improve data use.
At the national level, a national consensus to limit the number of required data elements and avoid introducing standalone systems could be a starting point. Existing systems could be incrementally reduced to perhaps about a maximum of three, with facilities and not individual providers as the unit of reporting. New services should have far fewer but more relevant indicators, with the introduction of any new data requirement being accompanied by an equivalent or twice-as-much reduction in existing under-used data and indicators.
At the level of policy, we need to begin with the recognition that a crisis exists, that HMISs reforms are required, and that for thinking about the direction of reforms. we need to establish design principles with regard to data, software and ethics as proposed in this conversation. As the saying goes, “The best time for reforms is 15 years back. The next best time is now”.
ASD- Thanks to all the participants in this dialogue. I have not finished with my questions but intend to follow up on the website where this is posted. I would invite readers to also do the same. The panel will remain available for a response.
Acknowledgements: Our thanks to Dr. Shalini Singh for her peer review and Ms. Roubitha David, for her assistance in transcription and editorial coordination The cover image used is from the Freedom Park in Bangalore.
Annexure: Don’t miss the Beginners guide to HMIS problematics!
About the Participants:
Dr. Akshay S Dinesh (MBBS, FHM, PGDMLE) is a generalist straddling public health and technology for a progressive society. Akshay is the co-founder of Action for Equity and is also associated with JeevaRaksha as an emergency medicine trainer, with IPH Bengaluru as an honorary associate, with SOCHARA as a digital archivist, with DemTech.ai as the head of engineering, with Nivarana as the Technical Editor, with Bahutva Karnataka, Sarvatrika Arogya Andolana – Karnataka, and free software, free knowledge, open data communities in India as a volunteer and contributor. You can read more about Akshay here.
Dr Amit Mishra is a healthcare professional with a master’s degree in health administration from TISS, Mumbai, and a diploma in health and social care data sciences from the University of Edinburgh. For over the past 15 years, he has been associated with the design, development, and implementation of health information systems. He was part of the HMIS reforms team established within NHSRC which supported the design and implementation of HMIS under the National Rural Health Mission in its first few years. Later, he worked with the Ministry of Health & Family Welfare to implement several digital health projects. He was the nodal resource person from NHSRC who served on the core team that led the development of metadata standards for integrating public health information systems in India. He also led the implementation of a project to build a registry of public health facilities in India called NIN. Currently, he is working with the Ministry of Public Health in Qatar to build data systems for non-communicable diseases.
Sundeep Sahay is a professor in Informatics at University of Oslo, and has affiliate positions in the Faculty of Medicine in Oslo and Sheffield University, UK. Over the last 25 years, he has been engaged with research, policy and practice across multiple countries in Afirca and Asia, with a strong focus on the public health system in India. He has also been engaged in various policy engagements with WHO, ADB, UNICEF and other. He has been one of the pioneers in establishing the R&D network HISP (Health Information Systems Programme) (dhis2.org) in 2000 at the Department of Informatics, and also set up and nurtured HISP India, an NGO, over more than 20 years in an honorary capacity. Between 2007 and 2009, he was seconded to NHSRC, Delhi, where he led the national Health Management Information System reform process under NRHM. He is one of the leading scholars in the research fields of Information Systems and ICT for Development, with nearly 300 peer-reviewed publications and has been the primary supervisor for 30+ doctoral candidates. His current research focus is on Antimicrobial Resistance, Environmental AMR and Climate and Health.
