fbpx
 

08 Jul Data Processing During Medical Device Design

Posted at 12:58h in cyber-security, featured by

At Key Tech, we work on all manner of instruments that collect and analyze raw data for novel therapies, research, and diagnostic decisions.  Over the past ten years, the amount of raw or unprocessed data associated with these instruments has grown tremendously.  While having this additional data is critical for analysis, it presents some challenges that need to be addressed for safe and effective operation.  The main concerns are data volume, storage, integration, security, and processing speed.

Data Volume

Years ago, I remember a discussion amongst the Computer Engineers on a specific project about the diagnostic capture settings and how we could reach almost 3MB per sensor, which, multiplied by the number of sensors, quickly used up all of our onboard storage and completely overwhelmed the communication pipeline.  The solution at the time was to limit what the assay developer could request and prevent using settings that would produce too much raw data.  At the time, this amount of data seemed abnormal and was difficult to process quickly.  Jumping forward to now, in any standard optical or sequencing system, gigabytes of data are generated per run.  This amount of data must be accounted for early during the architecture phase and is difficult to correct later on in the development process. It’s crucial that developers select an embedded computer system that can handle this data and create a firmware architecture that matches hardware constraints

Data Storage

The data storage challenge is closely related to data volume.  For instruments that have smaller datasets, there are options to keep all of the raw data.  This is the optimal case: by keeping the raw data, updates to the detection or therapy algorithms can be regression tested against previously collected data and their efficiency can be compared between software iterations.  Unfortunately, this is not always feasible.

An alternative to storing data on the device itself would be to ship all raw data to the cloud. However, this is not always practical; issues arise with both processing on the instrument and transferring that much data through an unknown network (such as the end user’s lab or hospital).  Exporting data off the instrument can take hours or even days.  One solution would be adding more processing hardware to the instrument, which can add cost to an already complex and expensive system. A better solution would be to use data decimation and/or compression methods to get the data down to a reasonable size.

Another factor to consider is storage costs.  When performing this cost analysis, one must also consider how long the data should be retained.  Most samples are temporary, and they cannot be resampled or analyzed again.  Purging data from these samples prematurely is an irreversible action.  One should also consider where the cloud system will be hosted. Will it be hosted in-house or outsourced to a trusted medical cloud provider?  The costs associated with any of these options can grow very quickly depending on the system data architecture decisions made early on.

Data Integration

When planning for the data in these systems, data integration must be considered as well.  Will data only come from one instrument, or could one set of samples be run on multiple devices in parallel to increase throughput?  How will these data sets be brought back together and processed?  These are the core questions that need to be answered during the system architecture phase.  The cloud again becomes an attractive option, as all data can be pulled from systems that are physically separate.  Another common configuration is an onsite LIS or server that can collate this data.  These on-site systems can facilitate the association between patient and test ID information without the need to global cloud-based systems.  This decision heavily depends on the data size needed for integration.

Data Security

This really could be a topic alone, but clearly, even raw or unprocessed data is private and needs to be protected.  Aside from the regulatory cybersecurity environment constraints, there are regional privacy laws and regulations that need to be considered as well.  To ensure compliance with all regulations, data must be secure at all points in the processing pipeline.  This can be difficult with smaller embedded systems, and special encryption hardware and protocols might be necessary.  A full cybersecurity analysis is required to determine the detailed requirements for the system under design.  Here, the critical data assets and repositories can be recorded, and the attack surfaces and potential vulnerabilities can be identified.  This is also critical to do early on, as it could be difficult to bolt on additional mitigations after a holistic architecture has been developed.

Processing Speed

Processing speed must also be considered when developing a medical system, especially when working with large data sets.  The first requirement to consider is how fast the data must be processed. This timeline varies based on the application.  For therapy devices, this might need to be on the order of seconds, while for research instruments, this could be days. Diagnostic devices usually require results on the order of minutes to hours.  Local processing is needed to meet faster processing speeds.  Specialized parallelization hardware, such as GPUs, can speed up processing further, but they add cost and heat to already sensitive designs.  Careful exploration of this must be done to ensure the correct processing speed while balancing other design decisions.

Conclusion

Ultimately, data management is a complex topic that directly impacts design decisions for both the device itself and the device ecosystem.  Luckily, Key Tech is well-versed in these challenges, and we’d love to help you make informed decisions for your specific system. You can contact us at TalkToUs@keytechinc.com and we’re looking forward to working with you!

 

Jamie Kendall
Latest posts by Jamie Kendall (see all)


Every challenge is different – Tell us about yours.