Building the new Data Connection Test (DCT) Mobile Application & Server
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.
Connectivity Toolbox
Features & Use-cases
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.
ODX - An Innovative Application for Spreadsheet Standardisation
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: