During our work in connecting diagnostic devices out in the field, it became clear that not all locations were created equally. Sometimes there would be little to no issues with connecting to the mobile internet, whereas in others, it was an everyday struggle.

Evaluating the quality of a site before a site visit was essential to a successful deployment. Due to a phone’s small form factor, one could be mailed physically to a site, preconfigured with the data sizes and SIMs that should be used. This would allow us to test with multiple phones and networks and limit user error.

Partnering with FIND, we needed a way of determining the compatibility of a site by instructing local teams and cutting out the need for expensive diagnostic equipment.

The mobile application that we produced, DCT - also referred to as the ‘parachute phone’ – is cross-platform. It will run on both iOS and Android, as well as older Windows phone technology. In order to collect the testing results, there is a centralised server deployed in the cloud that collects and reports on the results from each site; this is also the endpoint that is used for testing.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus lacus augue, maximus scelerisque erat id, lobortis vehicula metus. Proin tristique laoreet augue, vitae tristique ligula. Vivamus quis mauris consectetur tortor aliquet gravida. Fusce congue sem nibh, nec varius nisi laoreet non. Fusce suscipit tortor interdum nibh maximus euismod sit amet sit amet est. Nam nec velit porta, facilisis metus id, ullamcorper turpis. Etiam eros erat, semper in sem vel, convallis cursus dui. Donec sed volutpat sapien. Suspendisse ut erat id tellus dapibus euismod eget volutpat augue. Suspendisse potenti. Proin quis diam sodales, pharetra ante quis, sollicitudin leo. Maecenas magna mauris, vestibulum ut nunc quis, tristique bibendum nisl.

Open Interop is designed to support unlimited customisation and data manipulation, allowing a complete and comprehensive data system structure.

Our open-source software is already being utilised by the industry, including WHONet and point of care devices to enhance their data management.

Transforming data

Once the platform has received the data, it can be transformed using Open Interop's 'Tempr' (Templated endpoint mapping record) definitions. This can be configured in a number of ways, the simplest being a template builder which lets you select field names and define their endpoint. Alternatively, you can write the template manually using a popular mapping syntax called Moustache.js, or you can write code which will generate your output (currently only JavaScript is supported at release).

You can also chain Tempr's together, which allows you to perform an additional action based on the results of the previous Tempr. This is beneficial if you would like to create a record in your EMR and then use the ID of said record in another request, for example to update a surveillance system.

Transmitting data

Open Interop allows you to transmit data in a number of ways:

• HTTP requests in JSON format, this includes HL7 FHIR (available at release)
• HTTP requests in XML format (Planned Q1 2020)
• Streamed TCP socket data (Planned Q1 2020)
• Streamed UDP socket data (Planned Q1 2020)

You can optionally choose to store the request and response of these transmissions – therefore, storing the data that is transmitted to the platform (though purely for debugging purposes). When used in a production environment, the interoperability layer does not persist data that is passed through it.

How does it work?

Open Interop is designed to support unlimited customisation and data manipulation, allowing a complete and comprehensive data system structure. Configured to receive data in JSON, HL7 FHIR, XML, and CSV formats, Open Interop provides unrivalled flexibility.

You can build your own services and deploy them to the architecture to introduce your own data sources, or intermediary middleware, in order to process, encrypt, and otherwise manipulate the messages received by the platform.

Current uses

Open Interop has been deployed onto embedded hardware and can be used on a very small form factor to fit in your pocket for site visits if required.

We have current use cases wherein Open Interop receives data from a number of systems including WHONet, point of care devices, and simple spreadsheets via the use of data connectors. In addition to this, API based data generators are used to simulate device testing. We can manipulate this data and transmit it into DHIS2 as an event line listing for trackers, specifically into the WHO's TB tracker.

Our recent work launching an AMR Surveillance System in Nepal highlighted the recurring issue that exists in standardising spreadsheet data from multiple locations. The human and animal data gathered for transmission into the Nepal One Health system was coming from over 20 different laboratories, with multiple spreadsheet formats used by the locations. Prior to this innovation, data had to be manually cleansed and reformatted by individuals within Nepal’s National Public Health Laboratory (NPHL) and Central Veterinary Laboratory (CVL). This process was extremely time consuming, so the requirement for a more automated cleansing mechanism was identified early on in the project. To address this issue, and simplify the data cleansing process, SfHF has developed a desktop application, Open Data XLS Transformer (or ODX), which can be mapped to automatically cleanse and standardise spreadsheets ahead of loading them into an analytics platform, or health information system. Spreadsheets are passed through a ‘fix cycle’, where the automatic “correction” mappings and “error” call out features are used to produce a clean, standardised spreadsheet output.

Using ODX to reformat, fix and cleanse spreadsheet data 

The initial development of ODX allows for the transmission of information from multiple public health laboratory spreadsheets to DHIS2, specifically for AMR AST/DST testing. The application aims to solve the manual process required to sort data and can make both “corrections” and identify “errors” in spreadsheets uploaded to a data analytics system. It can be modified to map for spreadsheets from different origins and can be programmed to be sent to the desired analytics platform (not exclusively DHIS2). The current version of ODX has been programmed to identify relevant headings and information for data analytics. 

The main features of the application are the ODX mappings, which can be set up to ‘correct’ and standardise column headings, common spelling mistakes or name variations for pathogens and antibiotics, and reformat the spreadsheet so that all columns are in the same order and header information is in the same place. ODX is also able to identify any ‘errors’ in a spreadsheet that would prevent data rows from being sent into an analytics platform, such as missing information or information entered in an unrecognised format. This cleansing process is known as a ‘fix cycle’, as the user may need to pass a spreadsheet through ODX more than once to ensure that all errors have been addressed. Additional features can be added to meet country-specific needs, such as the more unique requirement of the Nepal project for mappings to correct for variation in date format used, as some Nepal laboratories use both the Gregorian and Bikram Sambat date formats. 

The following walkthrough video demonstrates how the ODX application runs, and how it has been used in Nepal: