Early Detection of Infectious Disease in Developing Countries

1. CHAPTER 1 Introduction

1.1 Background

In the public health and medical communities, there has been a widely recognized need for monitoring and early diagnosis of infectious diseases in low-resource, low-income developing countries [1]. Such healthcare delivery strategies contribute to patient management by decreasing the testing and diagnosing times. In low-resource, low income environments, diagnostic infrastructures are not present. The analysis of the diagnosis needs be conducted at a site close to patients so that the analysis results can be communicated to the patient quickly, in order to manage cures for infectious diseases. The World Health Organization (WHO) has developed an operational terminology for quality healthcare delivery called “Affordable, Specific, User-friendly, Rapid, Equipment-free, Delivered to those in need,” (ASSURED). ASSURED guides health-care providers in creating healthcare delivery strategies that provide 85-95 % analytical performance values in sensitivity and specificity, which will increase the healthcare management in developing countries greatly [1][2]. The monitoring and early detection of biological entities causing the infectious diseases is vital for effective healthcare management and saving lives. An autonomous and portable detection system that can process assays and analyze deficient concentration samples are needed to comply with the WHO’s mandate for healthcare delivery in developing countries with low resources and many isolated communities. This critical issue—the need for diagnosis in such environments to control the spread of inflectious diseases-is the main driver for developing a health delivery system that is capable of executing the assays to detect infectious diseases.

Commercially available testing tools for infectious diseases are insufficient to meet the needs of the limited-resource setting or poor infrastructure-based healthcare deployments. Improved health in such environments would help the country prosper economically and socially. In contrast to these developing country scenaria, diseases such as tuberculosis, malaria, HIV/AIDS and other sexually transmitted diseases are preventable and treatable in the developed world. Developing countries are still under enormous pressure to provide healthcare solutions for diagnosing diseases, in spite of technological advancements available in the developed world. In these environments, accessibility to laboratory facilities often is not possible for rural patients, who often lack access to basic testing tools and trained healthcare personal [3].

Traditionally, rapid tests are often referred to as Point-of-Care (POC), because they are done by doctors or nurses in the clinic or the bedside. POC has been an evolving field of medicine and technology over the past few years. The most modern form of these diagnostic tests uses micro- or nanotechnologies –which are in effect miniature laboratories that allow complex biological reactions, which usually take a long time in a full-sized laboratory, to happen very rapidly. The Point-of-Care Testing (POCT) based diagnosis is a method for bringing medical laboratories to a patient’s home to conduct diagnostic tests (self-tests) so that the patient does not need to go to the doctor or laboratory in person. WHO envisions POCT as a way of meeting the complex and critical requirements for delivering healthcare to remote sites where healthcare delivery has challenges. Such a revolutionary technology helps to provide affordable, accessible solutions.  In order to be successful, the system must be available to local communities to conduct the tests for detection of infectious diseases. The collected test data then must be transmitted securely to a secure database for analysis by physicians that will lead to a diagnosis. An automated response can be set if all the stakeholders accept a hybrid diagnosis process. The secure test data must reach clinician/healthcare personnel without delay or inaccuracy. Such systems can be designed to provide low-cost detection of analytics even with low concentration samples, and they can run required assays faster than laboratory-based testing. These systems lead many who are concerned about health care in developing countries to hope that finally there is a way to provide quality, affordable health care for people in thosecountries.

The design and development of the POCT system and the associated security for communication infrastructure must be done with extreme rigour, as the system is mission critical and safety critical. Detection of mission anomaly is meant for ensuring the functional safety, an important aspect of the POCT. Diagnosis based on this testing is an essential process improvement for remote patient care management. With the security of all communications assured, physicians gain a tool to diagnose patients who previously could not afford or could not access reliable health care.

POCT device-based diagnostics is a medical tool composed of interconnected devices that can provide health care diagnostics in a patient’s community environment,  external to a hospital-based lab setting[3], [4]. This testing has many advantages compared to standard laboratory-based testing[5]. It provides faster diagnosis, reduces cost, and introduces automation, which provides the patient access. It plays a key role in e-health delivery. The advantages in microbiology and engineering, when linked with the advances in mobile computing technologies, have enabled the possibility of patients being diagnosed and treated away from the clinic. There is an increasing recognition that these m-health (mobile health) and e-health (electronic processes and communication) technologies will play a greater role in medical care. The present research will drive the implementation of digital health care.

The potential benefits of using the POCT device include access to robust data, a short turnaround time (TAT) for testing, portability (ideally handheld), affordability, accelerated clinical decision-making, and avoidance of the complex pre-processing of biological samples. It is less complicated to use than traditional testing, as it is controlled mostly by a wireless smartphone or a one-touch keypad. Unlike with Lateral Flow Immunoassay (LFIA) technology, with microfluidics-based molecular diagnostic technologies used in the POCT-device, required sensitivity and specificity  can be achieved. Sample (or reagent) volume reduction is achieved because of the reduction in surface-to-volume ratios. Highly reproducible and quantitative results can be accomplished with the microfluidic-based system, as well. It is a closed system that can be operated with minimal wireless communication infrastructure, depending on the need [3],  and expanded to a multi-layer and multi-user system as needed.

1.1.1 POCT device system architecture

Figure 1‑1 Schematic diagram of the Brunel POCT architecture

The interdisciplinary Electronic System Research Group at Brunel University has developed a modularized system architecture for operating a POCT device using microfludics technology. The device uses lab-on-chip technologies for diagnosis of infectious diseases.  A related project called   the “Electronic Self-Testing Instrument for Sexually Transmitted Infections” (eSTI2) was funded by the Medical Research Council. ESTI2 consortium is a multidisciplinary, multi-institutional entity of scientists, clinicians, public health experts, engineers, software specialists and industry specialists who were working together to develop new types of tests for sexually transmitted infections and other infectious diseases, that can give accurate results immediately and also communicate seamlessly with hospital computing systems through wireless smartphone technology.

Figure 1-1 shows the generic device architecture needed for the POC testing that utilizes lab-on-a-chip technologies. The device operation is divided into three core functionalities. Sample pre-treatment (or sample preparation) is the first functionality for increasing the concentration, where the sample is introduced into the device with reagents. Reduction of surface to volume ratio enhances aspects of assay kinetics,  per test [6]. After the first introduction of the sample into the device, it is be processed which may involve micro-mixing, heating and separation for extracting DNA molecules using cell lysis process. The released DNA molecules will be separated from the rest of the cell debris.. The separated DNA molecule will go through an amplification process (second core function) to get the required concentration to facilitate the detection of the DNA molecules.

The next process is the nucleic acid detection (third core function) using bio-sensing technologies. Achieving sample-in-answer-out in the device is possible by having the capacity for inclusion of sequential sample preparation steps, nucleic acid amplification, and DNA detection in an integrated manner [6]. All three core functionalities, are aided by the microfluidic network. The microfluidic network operation is managed by the electronic control system. The electronic system enables user interface and display units as well. In addition these devices are capable of multiplexed analytic detection, because of the inherent design. Power management is necessary because the device needs uninterruptable operation during the process. All the processes are controlled by the smartphone, and the results are communicated in digital form to outside world. The smartphone communicates with the device via the communication module within the device. The test data is tagged with a location attribute for data analytics. The collected data is  stored in a local storage unit such as an SD card.

The communication subsystem that is part of the electronic system provides connectivity for transferring test data securely to either an internal private cloud in a hospital / clinic environment or an external public cloud. The locally stored data canbe sent to a central data cloud for actual diagnosis by health care professionals. The communication system provides short-range wireless radio access technologies such as Wi-Fi, Bluetooth, cellular wireless radio connectivity, and wired USB and LAN links. The cellular network radio access technologies such as 3G, 4G or 5G can help to establish connectivity between the device and other external entities such as the cloud.

The communication links within the device as well as external to the device are important to ensure the mission critical operations are carried out without any failure. The external communication links must be highly secure to preserve patient confidentiality. The test data collected must not be compromised by any security breaches. Therefore sophisticated, secure encryption schemes must be deployed for safeguarding the patient data at all cost. Accessing the device and initiating the detection tests must be possible only for authorized users. Unauthorized operations of all kinds must be prevented by the security mechanisms activated in the system. The test data can only be accessible via security-enforced communication links,  including data moves within the device or external to the device such as system log dumps to a server and other types of data storage.

1.2 Aims and Objectives of Research

The goal of the project is to develop and evaluate communication pathways, data security mechanisms, and a scalable network for the system. This communication system will facilitates personalized medicine and clinical care pathway. This aim is achieved through the following objectives:

Specific objectives:

• Development of fail-safe communication system architecture suitable for the system deployment.
• Development of the system architecture independent of wireless technology evolution in communication.
• Development of a suitable communication protocol for the system.
• Development of mechanisms for data security.
• Development of appropriate encryption schemes for data transfer to maintain patient confidentiality.

1.3 Summary of Methodology used

Figure 1‑2 High-level System abstraction view

A system approach was followed as a methodology for the research. As shown in Figure 1-2, there are three main data processing layers present in the system. The Data Collection and Analytics layer (Cloud Layer) is responsible for providing analytics mechanisms for a physician to develop diagnostics based on the collected data.  The System Access Layer is responsible for authorizing access to system users to conduct the test as well as propagating the test data securely to the database. The Device Layer is the collection of the devices capable of carrying out the tests. All the system layers collaborate in providing error-free diagnostic results. A security violation in any one these layers will lead to a false diagnosis. The Access Layer represents a system component (or entity) that allows access to the device via communication links, mostly short-range connectivity such Wi-Fi, Bluetooth, or USB. The test data need to be sent to a data collection layer via cellular (or short range connectivity) communication links, where the data will be processed further to analyze the test results.

Figure 1‑3: V-Model Overview

The research focuses on the communication links and mechanisms needed to transmit the test data securely from the device via the Access Layer to the Data Collection Layer. The V-model (Figure1-3) with agile product development methodology was used to develop the device and its internal and external communication paths. The V-Model is a system engineering paradigm that represents an evolution of the waterfall model.  When this paradigm is internalized by a research organization, it provides a structured process for understanding research needs and linking them to requirements, design, and verification and to the final research outcome and future work for the research. It facilitates the continuous integration of the system through the parallel development with other multi-disciplinary teams. This early collaboration with other researchers accelerates the research progress by asking critical questions around whether the right topics are considered before scope of the research is finalized. When these active feedback loops are established between the left and right sides of the V-model, flexibility and agility of the development teams result in a continuous release process where early patient feedback can shape the products delivered.

Figure 1-3 shows a generic view of the system V-model. There are different representations of this model used in the industry, which reflects how different business groups have tailored the model to their unique business needs. Starting at the top left, system engineers engage with user experience researchers and marketing and sales teams to elicit and clarify users’ and customers’ needs.  These needs are translated into system requirements by capturing and analyzing personas, usages, usage scenarios, and use cases that represent how users will interact with the system. Same concept is utilized in the development of the communication architecture for the deployment of POCT devices for infectious disease diagnostics.

During the requirements definition phase, Use Case Maps (UCM) methodology (Chapter-3) was used to perform an analysis of the data to negotiate and resolve conflicting requirements.  The communication system architecture requirements establish  contractual baseline between the research scope and the other functional teams for the architecture to be developed.  This baseline is necessary because research needs will continue to evolve, so the  requirements will also evolve.  The baseline is used to provide a context for quantifying the schedule and cost impact of changes that will be imperative for completing a successful research project.  There is a continuous negotiation throughout the analysis phase as requirements become better understood. If requirements are found to be infeasible, then further engagement with the stakeholders may be needed to resolve the conflict.

As shown in Figure 1-3, an important aspect of the V-model is early engagement with the quality and test efforts. In general, system functional test plans can heavily leverage the usage scenarios and use cases gathered during the requirements definition phase.  The goal of functional testing is to verify that the functional, quality, and performance requirements have been met. During the system testing, missing functionality or performance requirements may be identified, which can be the basis of future research work. Integration test plans and test cases can be developed in parallel with the communication system architecture  requirements. The goal of integration testing is to verify that the components that are able to coexist and interact with each other as expected.  Developing these plans simultaneously with the architecture provides the researher crucial insight into how the architecture will be pieced together as components become available. Information derived from this activity influences the architecture and drives consideration of how the system will be tested. In the research, combinatorial design methodology was used to generate test cases for the system validation. The methodology is explained in detail in Chapter-2.

Figure 1‑4 V-Model for research

Figure 1-4 shows the customized V-model (based on Figure 1-3) for the research work that has been undertaken. Starting at the top left, the researcher conducts a literature survey, and he or she identifies the research scope. Then follows the creation of the system’s requirements, the architecture development, and the creation of detailed requirements. The left side of the V-model is completed with the system’s design and implementation. Starting from the lower right, unit testing and integration testing are done for the modules developed and configured. The unit level testing will identify issues with individual modules, such as hardware and software drivers. As illustrated in Figure 1-3, the integration testing helps to mitigate any interface related issues and it resolves coexistence issues. Then the process continues in collaboration with other research team members to create a prototype for functional testing. The simulation is done for point-to-point network configuration to decide the communication topologies needed.

The end-2-ened system (device internal and external aspects of the communication) is concerned with functional safety and functional security, both of which overlay in the system V-model.

Figure 1‑5: Functional Safety V-Model

For functional safety, the IEC 62304 standard (cite) was adopted to develop the system communication architecture. Figure 1-5 shows the functional safety V-model that corresponds to the general system V-model shown in Figure 1-3 and the research process V-model in Figure 1-4. More in-depth details of the IEC 62304 applied to the system design can be found in Chapter-2.

Figure 1‑6: V-Model for security

For the security analysis, the V-Model for the security system as shown in Figure 1-6 was used as a guiding model. Building a secure communications link for the system has different challenges, and the issues can be understood by creating thread models and threat mitigation strategies. The detailed description of the security analysis can be found in Chapter-4.

The next section shows an example of the end-2-end communication architecture developed in the research. Multiple configurations were generated, and the detailed explanation can be found in Chapter-6

1.3.1 Example of an end-2-end system configuration

The G-Node controls the device, and it acts as an intermediate layer for external communications. There are many possibilities to connect the system entities based on the essential needs. One such configuration is shown in Figure 1-7. More discussion about the configurations can be found in Chapter-6.

Figure 1‑7 End-2-End Connection Topology

As shown in Figure 1-7, the system consists of multiple secure communication links between the network entities. P-Node represents the device. The communication system is responsible for supporting the topology connections shown in Figure 1-7. G-Node is a representation of the gateway functionality needed for communication of multiple devices, while P-Cloud is the representation of cloud functionality required for storing test data and conducting diagnostics analytics (data storage and analytics cloud). There are five types of secure communication links that can be configured: G-Node to the local server, G-Node to P-Cloud, P-Node to P-Cloud, P-Node to the local server, a device to device communication (Machine to Machine (M2M) communication), and user to P-Node or user to G-Node. Some of the links shown in the figure are used for connecting network entities such as P-Cloud in the public domain, while the other links are used for establishing connectivity within a private sphere of connectivity (e.g. within a firewall of a hospital).

The communication system supports multiple cellular radio access technologies (RAT), 2G, 3G, and LTE. The device architecture was developed so that when the 5G standard is available commercially for deployment, it can be added to the device. In addition, location services module, Bluetooth, USB, Ethernet, and Wi-Fi connectivity paths are available in the communication sub-system.

There are other communication challenges from the communication system architecture itself. Modularized sub-systems are needed to provide decoupled architecture, to manage seamless data flow within the device. The internal data flow within the architecture will have an impact on the accuracy of data collection and further impact in transmitting the data to the P-Cloud. These challenges are addressed by having a protocol at the application layer of the design.

The P-Cloud has to support many salient features by means of a secure cloud structure within the cloud to ensure end-to-end  connectivity of the communication. It contains of multiple sub-clouds architectural components, namely, a measurement data cloud, a normalized data cloud for data mining and analysis, a configuration and provisioning data cloud, a system deployment data cloud, and a system operational data cloud. There are separate data access gateways to maintain data boundaries and data integrity. Distinct data access gateways and security groups are required in the P-Cloud to assure the security boundaries of users of the P-Cloud such as data provisioning agencies, health professionals, field technicians, and patients. Configurations such as those in the figure help to achieve successful deployments at the primary care level and are particularly amenable for use in remote settings with poor or no laboratory infrastructure [3].

1.4 Thesis structure

Chapter 1: Introduction and scope of research

This chapter introduces and explains the research idea, provides background information and explains why there is a need for the research. In addition, it lays out the organization of the thesis.

Chapter 2: System Design process and Mission Critical System Design Process for the POCT system

This chapter addresses the development cycle of the device.  It begins with  a description of the requirement gathering and moves on to outline the design process.  From there, the discussion moves to  the end-2-end system communication topology, the security principles of safety-critical communication software, and the development of a secure cloud architecture for the system.  Then it addresses the process of system  design complient with the ICE 62304 standard, the validation methodologies for testing the communication links, and the Agile development methodology for project management.

Chapter 3: Use Case Maps and Requirements for communication system development

Unambiguous requirements are key to successful product development. Various tools and methodologies exist to help with design, development, validation, and project management. This chapter discusses Use Case Maps (UCM) and EARS (Easy Approach to Requirements Syntax) methodology for creating communication system requirements.

Chapter 4: Security aspects of POCT system development

Data security is an important feature of the system. This chapter explains the aspects that need to be protected, given the attack threat model for the device and the communication links. Use cases related to security are discussed. Two types of security frameworks have been developed, challenge and response based framework and system behavioral based framework. The discussion addresses security provisioning in the context of the M2M (e.g. P-Node to G-Node) communication model in relation to healthcare professional and the patients who use the system.

Chapter 5: P-Cloud and NAS Implementation. In this chapter, the internal components subsystem of the P-Cloud is explained. The internal architecture of the P-Cloud, which will provide error-free data storage for the device is shown in detail. In addition, a practical implementation of the private P-Cloud using NAS is described, along with the results.

Chapter 6: Network Models for POCT system deployment and simulation results

In this chapter, the various use cases of connecting the system components are explained. Simulation of P2P connectivity representing the communication between P-Node and G-Node is shown with obtained results. For managing transmission control, a novel methodology was developed and implemented, collaborative congestion control, is introduced and explained.

Chapter 7: Conclusion and future work

Achievements – contribution to knowledge and system weaknesses identified and recommendation for further work to added these limitations

Chapter Research Scope	Chapter -1: Introduction and scope of research	Chapter-2: POCT System Design process and Mission Critical System Design Process for POCT	Chapter-3: Use Case Maps and Requirements for POCT system development	Chapter 4: Security aspects of POCT system development	Chapter 5: pCloud (Cloud Implementation for POCT System) and realization using NAS.	Chapter 6: Network Models for POCT system deployment and simulation results	Chapter 7: Conclusion and future work
Development of fail-safe communication system architecture suitable for system deployment.						
Development of system architecture independent of technology evolution in communication.						
Development of suitable communication protocol for system communication.				
Development mechanisms for data security				
Development of suitable encryption schemes for data transfer.							

Table 1‑1 Mapping between chapters and specific research goals

The traceability between the chapter contents and the specific goals are mapped in Table 1-1. The traceability shows the links between the chapters and the goals of the research in a matrix format for clear understanding. The row in the table labelled “Chapter” indicates the list of chapters in the thesis. The columns the table labelled “Research Scope” show the research objectives. The  traceability matrix shows the contents of the chapters relevant to the research objectives.

1.5 Contribution to knowledge

Figure 1‑8 Technical contribution

The research involved developing communication configurations for an end-2-end system architecture that supports device connectivity.  The research also involved creating a design methodology for a robust, dependable, safe, and secure communication platform for interconnecting the devices. Unanticipated network infrastructure changes and latent coding errors lead to operation faults despite that usually a significant effort has been expended in the design, verification, and validation of the software system [7]. It is becoming increasingly more apparent that one needs to adopt different approaches that will guarantee that a complex system meets all safety, security, and reliability requirements, in addition to complying with standards. There are many initiatives taken to develop safety and security critical systems, at different development phases and in different contexts, ranging from the system infrastructure design to the device design. Various approaches are implemented to design error free software for the safety-critical system. The approach and methodologies adopted in the research can overcome the challenges in developing error control and communication software for communication and system architecture (see Figure 1-8).

This present research makes a unique contribution to the healthcare system based on its incorporation of modern and evolving technologies such as mobile computing and secure and reliable cloud computing. Figure1-8 shows the internal system modules needed for controlling the device from the G-Node (or smartphone). These subsystem  modules can be used in the device’s standalone mode of operation, when the G-Node is not present.

As indicated in Figure 1-8, there are four key fields of contribution in this research, as listed below.

Contribution 1: System requirement modelling and device architecture, Figure 1-8 (1)

Figure 1‑9 Communication paths in POCT system

The research developed the required management approach for the communication links in order to deploy system securely, including a representation of requirements using Use Case Maps and EARS (Easy Approach to Requirement Syntax) methodology. Use Case Maps are used to express device communication requirements in a model form which is described inin Chapter-3. These requirements provided the guidance for developing the communication system in detail. Security-aware architecture for data communication between the building blocks for the device system was developed. Internal communication between the sub-systems is vital for ensuring error-free external communications. The research developed a layered architecture with multiple functional modules. The model takes into consideration all the stakeholders (patients, healthcare personal, clinicians, POCT device manufacturers and network operators) requirements [REF].

Contribution 2: A secure communication protocol independent of radio technology, Figure 1-8 (2)

A secure communication protocol with expandability that operates independent of radio access technology was developed. The radio technology independent protocol enables data transfer between P-Node, G-Node, and P-Cloud. The device communication system was implemented based on the IEC62304 standard, and it specifies the life cycle requirements for the medical device software and system based on the critical safety requirements. The communication subsystems were portioned to meet the IEC62304 risks classification classes. Communication between multiple components via connectivity (Bluetooth) and cellular protocols (2G and 3G) was demonstrated. [REF]

Contribution 3: An End-to-End Secure Communication, Figure 1-8 (3)

Security mechanisms were created and implemented for the end-2-end communication system  consisting of the P-Cloud, the G-Node, and the POCT device. Two kinds of security concepts (challenge-response based and behaviour based) have been developed to counteract security threats faced by the device and the communication system. A smart encryption model for transmitting secure data was developed. An encryption process of the system data storage and transmission was designed with encryption key management strategy for private cloud based on NAS,

[Ref]

Contribution 4: Coordinating multiple devices and systems, Figure 1-10

Figure 1‑10 Hierarchical model for POCT system management.

The POCT system needs to support multiple devices in a practical network deployment. A configurable deployment model based on the capacity and capabilities of the network and the POCT device was designed and implemented. The system is made up of the hierarchical model to support large-scale systems with expandability based on the growth. It is divided into three logical systems:, zone, site, and unit.  A zone consists of multiple system sites. A system site contains multiple instances of POCT device units. Due to data transmission in three levels, there will be scenarios where the packet drops may occur, and they must be eliminated due to mission criticality of the data. Hence a congestion control algorithm for managing the devices’ communication has been developed.

1.6 List of Publications

[1] Branavan. M., Mackay. R., E., Craw. P., Naveenathayalan. A., Ahern. J., Sivanesan. T., Hudson. C., Stead. T., Kremer. J., Garg. N., Balachandran. W., “Modular development of a prototype point of care molecular diagnostic platform for sexually transmitted infections,” Med. Eng. Phys., vol. 38, no. 8, pp. 741–748, Aug. 2016.

[2] Love. F., McMillin. B., Tulasidas. S., and Balachandran. W., “Multiple security domain non-deducibility for point-of-care diagnostic technology: Work In Progress (WiP) abstract,” in Proceedings of the 7th International Conference on Cyber-Physical Systems, 2016, p. 42.

[3] Tulasidas. S., Mackay. R, Craw. P., Hudson. C., Gkatzidou. V., and Balachandran. W., “Process of Designing Robust, Dependable, Safe and Secure Software for Medical Devices: Point of Care Testing Device as a Case Study,” Journal of Software. Engineering and Applications, vol. 6, no. 9, pp. 1–13, Aug. 2013.

[4] Tulasidas.S.,Hausner.J.,Terzakis.J.,Love.F.,Mattern.S.,Hudson.C.,Manivannan.N.,and Mackay. R., “Requirements for Point of Care Devices using Use Case Maps,” International Journal on Recent and Innovation Trends in Computing and Communication, vol. 3, no. 6, pp. 4284–4288, 2015.

[5] Tulasidas. S., Mackay. R., Hudson. C., and Balachandran. W., “Security Framework for Managing Data Security within Point of Care Tests Security Framework for Managing Data Security within Point of Care,” Journal of Software. Engineering and Applications, vol. 10, no. 10, pp. 174–193, Feb. 2017.

1.7 References

[1] Rosanna W. Peeling and Ruth McNerney, “Emerging technologies in point-of-care molecular diagnostics for resource-limited settings,” Expert Rev. Mol. Diagn., vol. 14, no. 5, pp. 525–534, Jun. 2014.

[2] A. N. Abou TayounP. R. BurchardI. MalikA. Schererand G. J. Tsongalis, “Democratizing Molecular Diagnostics for the Developing World,” Am. J. Clin. Pathol., vol. 141, no. 1, pp. 17–24, Jan. 2014.

[3] “https://bruneldoclab.com/.” [Online]. Available: https://bruneldoclab.com/. [Accessed: 10-Sep-2017].

[4] “5 Things You Need To Know About The Point-Of-Care Technology Market.” [Online]. Available: http://www.meddeviceonline.com/doc/things-you-need-to-know-about-the-point-of-care-technology-market-0001. [Accessed: 10-Sep-2016].

[5] Gabrielle TivenLisa FristMichael Changand Yechiel Engelhard, “Management for the World Module: Assessing point-of-care diagnostics for resource-limited settings,” 2011.

[6] J. .. McRae, M.P.a,  Simmons, G.b,  Wong, J.ac,  McDevitt, “Programmable Bio-nanochip Platform: A Point-of-Care Biosensor System with the Capacity to Learn,” Am. Chem. Soc., vol. 49, no. 7, pp. 1359–1368, 2016.

[7] Sivanesan TulasidasRuth MackayPascal CrawChris HudsonVoula Gkatzidouand Wamadeva Balachandran, “Process of Designing Robust, Dependable, Safe and Secure Software for Medical Devices: Point of Care Testing Device as a Case Study,” J. Softw. Eng. Appl., vol. 6, no. 9, pp. 1–13, Aug. 2013.