Steve Maylish and Ross Dehmoobed, Fusion Biotec03.03.22
COVID has changed the way people view diagnostic testing. For most, testing consists of going to the doctor, getting an order for a blood test, making an appointment with the lab, going to the lab, then returning to the doctor to discuss the results. This is still true today for the most part. What has changed is the urgency and expectations for those test results.
In the early days of COVID testing, lab results were either too slow (making self-quarantine a moot point) or never returned. Now the FDA aims to move rapid point-of-care (POC) testing from the lab or clinic to the home. However, quick, accurate results that mirror lab results are complicated—add to that results being communicated to the patient, healthcare provider, insurance plan, and perhaps the government. This must be done in a way that protects patient privacy, provides the needed information to healthcare workers and government agencies, bills insurance plans, and perhaps provides a digital record or COVID passport.
Communications and internet connectivity resolve some turnaround issues but cybersecurity and conforming to the Health Insurance Portability and Accountability Act (HIPAA) also must be addressed with any infectious disease POC diagnostic test.
Figure 1: POC software reporting structure.
The software operating the system can get complicated quickly (Figure 1). First the device starts with internal firmware, which runs the reader/tester. If the test is simple, an RFID or barcode might be scanned into the smartphone or a picture taken of the result. If the test is more complicated, the reader may communicate directly to a smartphone via Bluetooth. Finally, the complication of cybersecurity and privacy add to system complexity.
Technical and regulatory requirements dominate the creation of a new POC device. A typical POC diagnostics platform consists of low-level firmware that controls the mechanics, electronics, and measurement systems. If the firmware provides real-time control, consider a real-time operating system (RTOS). A minimalistic approach may suffice when the hardware needs no multithreading. Regardless of the approach, the firmware is a crucial design element and careful attention must be paid to a risk assessment of the firmware and its components.
Once the firmware and hardware platform is selected, the question becomes: “How is the data extracted, in what form, and where is it sent?” Make a careful analysis of what data is useful to stream out of a device, how much data is appropriate, and how that data is extracted. Algorithm analysis should be done in the instrument or remotely of where the data is sent and what communication protocols should be employed.
When transferring data from the device, a few factors should be considered: operating environment, frequency of data delivery, bandwidth required, and workflow. Device expectations vary between a home patient, healthcare provider, or laboratory technician. For the first scenario, imagine a nasal swab or saliva placed in an instrument or cartridge and the result being available to the patient shortly afterward. This could be communicated to a smartphone and pushed to the internet for reporting. This would be a CLIA-waived instrument, meaning simple and having a low risk for erroneous results (as the FDA has determined). A POC device in a hospital may be limited to WiFi or Ethernet connectivity due to interference issues. It may need administration by a trained, healthcare professional and fit into their workflow and hospital procedures.
Frequency of data delivery and bandwidth must be considered—especially if data transfer rates, battery life, or large amounts of information are being processed. This is more of a consideration when using a cellular data connection. The smartphone acts as a gateway connecting the device to the cloud or final destination. In this application, Bluetooth would be more appropriate. If the end device is low-power or battery operated, consider Bluetooth Low Energy (BLE). Be sure to understand the BLE’s limitations in terms of data transfer speed, the potential for interference, and security risk.
If power isn’t a major concern, another option may be classic Bluetooth, which provides higher transfer rates and more persistent connections. If a smartphone is the intermediary, be aware that not all smartphones support extended Bluetooth features without additional certifications. This requirement may create challenges if the user employs their own device.
It is critically important to understand regulatory compliance for the device. As an example, most POC diagnostic instruments are Class II medical devices. Regulatory rules may differ if an instrument reports quantitative versus qualitative results. A device may be qualified as a Medical Device Data System (MDDS) or Clinical Decision Support (CDS) system, each requiring its own regulations. Some of these differences may significantly impact development. It’s important to understand and document the regulatory path early. Regulations also differ from country to country and the commercialization plan will affect regulatory strategy.
ISO 27001 defines the device’s cybersecurity infrastructure, maintenance, and risk management. Cybersecurity management and protecting patient data and health information is integral. Even if the device doesn’t store patient data, cybersecurity considerations must be taken to protect the device’s data, intellectual property, and/or financial data.
Start with a thorough risk planning assessment focusing on data privacy and security. The primary focus should be on collected or stored data elements, which fall under the definition of “protected” per HIPAA. When designing the system, ensure cybersecurity requirements are a core part of the process. Ensure the design team uses the appropriate level of encryption for data storage and transmission. This should tie back to risk assessment and risks identified as high, medium, or low. A general rule of thumb is the higher the risk, the higher the level of encryption needed. Finally, develop a post-market surveillance program to identify future system vulnerabilities and how to address them.
Once patient data is collected or reported, data protection becomes a responsibility and a priority. It’s important to conduct a thorough risk analysis and ask: “What happens if the data is altered or compromised? Would this pose any risk to the patient or end-user?” A risk mitigation strategy should come out of a risk analysis.
Equally important is the hardware. Before software coding begins, make sure the hardware can support encryption or other desired security measures. As with hardware choices, software choices will have an impact on any connected products. It’s common to use free open-source software (FOSS) as building blocks for software development. For compliance and security purposes, treat those software libraries and frameworks as either commercial off-the-shelf (COTS) software or software of unknown provenance (SOUP). Either way, proper mitigations are needed to reduce risk. Choosing the right software stack is also important for cybersecurity. Unsupported libraries may have vulnerabilities that are never addressed. In an ideal scenario, use platforms or frameworks developed with cybersecurity in mind.
One of the most important decisions is obtaining an all-in-one solution. A consulting company can help with firmware or the application software but the entire system must work well together and pass FDA scrutiny. The best option is that a team provides a one-stop shop for firmware, software, and connectivity expertise. This consolidates responsibility for the software project and eliminates finger pointing.
One option is to “home build” the connectivity infrastructure by developing it in-house or outsource the job. Either way, the solution must be FDA compliant with the right design control processes. An in-house solution precisely meets the company’s requirements but could increase staffing cost internally or externally to develop, provide updates, fix issues, and maintain reliable connectivity.
The other option is buy or lease an existing platform as a foundation and customize it. This option is the quickest. Buying the solution can be expensive but allows for better platform control than leasing. Leasing the solution or paying a monthly subscription could be more cost-effective in the short term than buying. However, it usually means less access to source code, as well as less control and customization. This also means being reliant on the third-party platform.
No device is completely safe from attacks if it communicates with another device or network. Sending data from a device requires careful requirement and architecture consideration. Developing a regulatory pathway, understanding agency requirements, and defining product requirements can avoid a number of pitfalls. Selecting the right solution will provide the appropriate device connectivity and security.
Steve Maylish has been part of the medical device community for more than 35 years. He is currently chief commercial officer for Fusion Biotec, an Irvine, Calif.-based contract engineering firm that brings together art, science, and engineering to create medical devices. Early in his career, Maylish held positions at Fortune 100 corporations such as Johnson & Johnson, Shiley, Sorin Group, Baxter Healthcare, and Edwards Lifesciences.
Ross Dehmoobed has been creating cutting-edge embedded software for safety-critical systems for over 17 years. His special expertise is developing hard real-time control systems. He is versatile enough to move up and down the software stack easily, from bare-metal firmware to iOS, Android Apps, IoT devices, and cloud connectivity. He has extensive engineering and product development experience in highly regulated industries such as healthcare and automotive.
In the early days of COVID testing, lab results were either too slow (making self-quarantine a moot point) or never returned. Now the FDA aims to move rapid point-of-care (POC) testing from the lab or clinic to the home. However, quick, accurate results that mirror lab results are complicated—add to that results being communicated to the patient, healthcare provider, insurance plan, and perhaps the government. This must be done in a way that protects patient privacy, provides the needed information to healthcare workers and government agencies, bills insurance plans, and perhaps provides a digital record or COVID passport.
Communications and internet connectivity resolve some turnaround issues but cybersecurity and conforming to the Health Insurance Portability and Accountability Act (HIPAA) also must be addressed with any infectious disease POC diagnostic test.
Figure 1: POC software reporting structure.
Technical and regulatory requirements dominate the creation of a new POC device. A typical POC diagnostics platform consists of low-level firmware that controls the mechanics, electronics, and measurement systems. If the firmware provides real-time control, consider a real-time operating system (RTOS). A minimalistic approach may suffice when the hardware needs no multithreading. Regardless of the approach, the firmware is a crucial design element and careful attention must be paid to a risk assessment of the firmware and its components.
Once the firmware and hardware platform is selected, the question becomes: “How is the data extracted, in what form, and where is it sent?” Make a careful analysis of what data is useful to stream out of a device, how much data is appropriate, and how that data is extracted. Algorithm analysis should be done in the instrument or remotely of where the data is sent and what communication protocols should be employed.
When transferring data from the device, a few factors should be considered: operating environment, frequency of data delivery, bandwidth required, and workflow. Device expectations vary between a home patient, healthcare provider, or laboratory technician. For the first scenario, imagine a nasal swab or saliva placed in an instrument or cartridge and the result being available to the patient shortly afterward. This could be communicated to a smartphone and pushed to the internet for reporting. This would be a CLIA-waived instrument, meaning simple and having a low risk for erroneous results (as the FDA has determined). A POC device in a hospital may be limited to WiFi or Ethernet connectivity due to interference issues. It may need administration by a trained, healthcare professional and fit into their workflow and hospital procedures.
Frequency of data delivery and bandwidth must be considered—especially if data transfer rates, battery life, or large amounts of information are being processed. This is more of a consideration when using a cellular data connection. The smartphone acts as a gateway connecting the device to the cloud or final destination. In this application, Bluetooth would be more appropriate. If the end device is low-power or battery operated, consider Bluetooth Low Energy (BLE). Be sure to understand the BLE’s limitations in terms of data transfer speed, the potential for interference, and security risk.
If power isn’t a major concern, another option may be classic Bluetooth, which provides higher transfer rates and more persistent connections. If a smartphone is the intermediary, be aware that not all smartphones support extended Bluetooth features without additional certifications. This requirement may create challenges if the user employs their own device.
It is critically important to understand regulatory compliance for the device. As an example, most POC diagnostic instruments are Class II medical devices. Regulatory rules may differ if an instrument reports quantitative versus qualitative results. A device may be qualified as a Medical Device Data System (MDDS) or Clinical Decision Support (CDS) system, each requiring its own regulations. Some of these differences may significantly impact development. It’s important to understand and document the regulatory path early. Regulations also differ from country to country and the commercialization plan will affect regulatory strategy.
ISO 27001 defines the device’s cybersecurity infrastructure, maintenance, and risk management. Cybersecurity management and protecting patient data and health information is integral. Even if the device doesn’t store patient data, cybersecurity considerations must be taken to protect the device’s data, intellectual property, and/or financial data.
Start with a thorough risk planning assessment focusing on data privacy and security. The primary focus should be on collected or stored data elements, which fall under the definition of “protected” per HIPAA. When designing the system, ensure cybersecurity requirements are a core part of the process. Ensure the design team uses the appropriate level of encryption for data storage and transmission. This should tie back to risk assessment and risks identified as high, medium, or low. A general rule of thumb is the higher the risk, the higher the level of encryption needed. Finally, develop a post-market surveillance program to identify future system vulnerabilities and how to address them.
Once patient data is collected or reported, data protection becomes a responsibility and a priority. It’s important to conduct a thorough risk analysis and ask: “What happens if the data is altered or compromised? Would this pose any risk to the patient or end-user?” A risk mitigation strategy should come out of a risk analysis.
Equally important is the hardware. Before software coding begins, make sure the hardware can support encryption or other desired security measures. As with hardware choices, software choices will have an impact on any connected products. It’s common to use free open-source software (FOSS) as building blocks for software development. For compliance and security purposes, treat those software libraries and frameworks as either commercial off-the-shelf (COTS) software or software of unknown provenance (SOUP). Either way, proper mitigations are needed to reduce risk. Choosing the right software stack is also important for cybersecurity. Unsupported libraries may have vulnerabilities that are never addressed. In an ideal scenario, use platforms or frameworks developed with cybersecurity in mind.
One of the most important decisions is obtaining an all-in-one solution. A consulting company can help with firmware or the application software but the entire system must work well together and pass FDA scrutiny. The best option is that a team provides a one-stop shop for firmware, software, and connectivity expertise. This consolidates responsibility for the software project and eliminates finger pointing.
One option is to “home build” the connectivity infrastructure by developing it in-house or outsource the job. Either way, the solution must be FDA compliant with the right design control processes. An in-house solution precisely meets the company’s requirements but could increase staffing cost internally or externally to develop, provide updates, fix issues, and maintain reliable connectivity.
The other option is buy or lease an existing platform as a foundation and customize it. This option is the quickest. Buying the solution can be expensive but allows for better platform control than leasing. Leasing the solution or paying a monthly subscription could be more cost-effective in the short term than buying. However, it usually means less access to source code, as well as less control and customization. This also means being reliant on the third-party platform.
No device is completely safe from attacks if it communicates with another device or network. Sending data from a device requires careful requirement and architecture consideration. Developing a regulatory pathway, understanding agency requirements, and defining product requirements can avoid a number of pitfalls. Selecting the right solution will provide the appropriate device connectivity and security.
Steve Maylish has been part of the medical device community for more than 35 years. He is currently chief commercial officer for Fusion Biotec, an Irvine, Calif.-based contract engineering firm that brings together art, science, and engineering to create medical devices. Early in his career, Maylish held positions at Fortune 100 corporations such as Johnson & Johnson, Shiley, Sorin Group, Baxter Healthcare, and Edwards Lifesciences.
Ross Dehmoobed has been creating cutting-edge embedded software for safety-critical systems for over 17 years. His special expertise is developing hard real-time control systems. He is versatile enough to move up and down the software stack easily, from bare-metal firmware to iOS, Android Apps, IoT devices, and cloud connectivity. He has extensive engineering and product development experience in highly regulated industries such as healthcare and automotive.
