09 – Strengthening Information Systems and Linkages to Care

Emphasis on the end-user

It is most important that the information system meet the needs of the people who use it. While this may sound obvious, many systems end up being designed and deployed without ever asking end-users about their specific needs. This can also happen when an existing solution is deployed in a different setting without adequate assessment and needs analysis. Furthermore, systems deployed with no end-user in mind are ineffective. If end-users find the system difficult and cumbersome to use, they will naturally either not use it at all or use it only because they are mandated – not because the system improves their day-to-day work.

Different end-users have different needs. For example, for a mobile app, the kind of visual interface needed by TB screeners working in the community will be very different from that needed by data entry operators retrospectively entering data into a screening form using a web-browser. Even though the data these individuals are entering are the same, a different type of interface is needed because they are working in different contexts. Consideration should also be given to the fact that TB screeners’ roles may vary across different countries.

While NTP managers need to have data presented to them in an easily consumable way via a dashboard, those working at lower levels of the health system need to see reports in much more detail. An optimal system is one that has been designed after thorough analysis of the needs of different types of end-users (5). The system should also have a feedback loop for end-users to report back about problems in the system. Users should be consulted regularly (particularly after changes are made to the system) to ensure that the system is continuing to meet their needs.

Reports and dashboards

A key use of information systems is to make data readily available for decision-making. This means that data need to be available in an easily consumable form, usually in a dashboard where key indicators are easily accessible. Data in the form of charts, graphs and tables can be used by programme managers and policy makers to assess programme performance, identify gaps that need intervention, and make decisions about protocols and standard operating procedures (SOPs).

India’s NIKSHAY system (see Box 3 below) allows for different dashboards for different levels of providers, and the viewing of real-time notification data down to the health facility level.

Role-based access and restrictions

Optimal systems provide different levels of access to different types of users. For example, the ability to edit a patient’s treatment regimen in the system may be restricted to clinicians only. Similarly, many systems may limit users’ access to data that are not relevant to their geographical region (e.g. provinces and districts). Such restrictions are important not only from the perspective of data integrity, but also in terms of patient privacy.

Designed in accordance with available infrastructure and context

Context is an important consideration when designing systems. For example, a system that requires constant connectivity to the Internet will not work in areas where such connectivity is not available.  Similarly, a system that is designed to operate on a massive cloud-based server infrastructure will not run off a laptop server, nor will an app designed for Apple devices work on more commonly used Android devices. An optimal system, therefore, is designed keeping in mind the context and available infrastructure in the setting where it will be used.

Health information exchange standards and data dictionary

Standards already exist for the exchange of clinical and administrative data between software applications used by various health care providers, such as HL7 and the up and coming FHIR (Fast Healthcare Interoperability Resources) standard. FHIR was created by the same consortium that created HL7; however, it is considered easier to implement because it utilizes very commonly used web-based application programming interface (API) technologies, including REST with XML or JSON, and Atom feeds. Data can be exchanged seamlessly among systems that are built to conform to these standards, allowing for improved interoperability (not only from a systems perspective but also from a user perspective). In situations where the same data need to be entered into multiple systems, the interoperability brought about by standards compliance can reduce the data entry burden on staff and result in reporting efficiencies.

To ensure interoperability when systems are designed, implementers may request that developers provide a data dictionary or devise one on their own. A data dictionary defines each term in the system and can be used to ensure consistency across the system (e.g. “sample type” means the same thing throughout the system and all “sample type” drop-down menus contain the same options). This consistency is also important for enabling correct and accurate reporting and facilitating linkages to external systems, including the national system. Software systems like OpenMRS have data dictionaries that can be mapped to recognized medical terminologies such as SNOMED, ICD9, ICD10 and LOINC.

Linkages with diagnosis and treatment

Diagnostic and follow-up tests are a critical point in the patient care cascade. In an optimal system, diagnostic devices are linked into the information system (where the device supports this) so that test results are automatically input into the system without the need for manual entry. This automatic entry can be combined with an active alert system to inform caregivers and programme coordinators of test results. This step is particularly important to prevent PTLFU and decrease the time to treatment initiation. In cases where devices do not permit direct integration, the information system should either include a data entry and reporting interface for lab staff or be linked to the laboratory’s information system, depending on the context. These linkages prevent test data from being entered into two different systems or being reported on paper (which requires data entry staff to come to collect results or have the results sent to them).

Scalability and adaptability

Scalability

Given that TB programmes operate at varying levels of scale and that protocols and processes can change based on new information, it is important for information systems to be scalable and adaptable. Scale can mean both geographical scale (e.g. a system must have room to add new basic management units (BMUs) and address hierarchies) and scale in terms of the amount of data and number of users the system can support. This means that both the software and the hardware should be built to support scalability and to not slow down noticeably when dealing with large amounts of data.

Adaptability

Adaptability can take different forms. Some adaptability can involve end-users configuring the system for themselves, e.g. setting simple preferences and user roles, updating facility directories, etc.  However, some changes to the system require a programmer to actually change the way the system works. The more adaptable a system is, the more easily and quickly such changes can be made.

Public–private mix

Besides notification, an optimal system will not only support public-sector data entry and analytics, but also data and interactions in the private sector as well. (Notification systems are discussed in more detail in a later section.) Private sector TB care can vary in scale and scope across countries, and it is much more effective for an information system to allow inclusion of both sectors. The degree to which private sector providers can use a national TB information system will vary, because many private providers, particularly those in large private sector hospitals or upscale clinics, have their own electronic systems.  The national system can facilitate private providers reporting into the system by providing a data standard to make all systems compatible.