Empower Medical Devices with Embedded Database Software and Manage Risks

Medical device manufacturers have a tremendous opportunity to improve patient health care and boost the productivity of nurses and physicians with innovative products based on the latest microcontrollers and embedded processors. These technologies are a source of great excitement, offering full multipurpose computing capability and significant storage capacity with low power requirements and cost. Data management is an important component of these mission-critical devices, which demand increasingly scalable storage that is safe and reliable. Selecting the best strategy for data management is a fundamental challenge of product development that requires both expertise and capable tools.

As the complexity of medical device products continues to grow, the nature of data storage and communication is changing. Rather than simply forwarding information to a central location, medical devices must now make decisions autonomously using accumulated data about one or more patients. To accomplish this while ensuring patient safety and privacy, it is important to select an appropriate database technology, have access to relevant and responsive technical knowledge, and obtain support in meeting industry-wide regulations. But first, it is important to understand why formal data management is necessary on a medical device and what options are available.

Motivations for an Embedded Relational Database

Medical devices have a wide range of uses, from bedside monitoring in a hospital to personal fitness tracking at home. As manufacturers pursue a higher level of intelligence and care, these devices must collect and share more information than ever before, with no finite limits on how these devices will be combined to interoperate. Several specific requirements indicate that dedicated data management solution is required:

• Patient information is frequently updated and revised;
• Collected data may exceed available memory;
• Safe recovery from an unexpected power failure must proceed automatically;
• Concurrent tasks must read from and write to a common collection of records;
• Records must be filtered, aggregated, and compared for graphs and reports; or
• Data must be continuously distributed to keep systems and devices synchronized.

An embedded database management system integrates directly with the application software or firmware on a medical device to store and access data without administrative overhead. In this way, it is similar to a file system, but with greater capability to efficiently protect, organize, and share data between tasks. (See Figure 1)

A file system can store data in a flat or hierarchical format, such as CSV, XML, or a custom binary format. While these formats can be very effective for appendonly logging and interchange of data, they become difficult to update and search as the data grows beyond a certain threshold. While it is possible to develop a custom binary format and index some parts of the data, keeping the index data consistent with the original file is not trivial, particularly if the file is shared by several tasks.

Rewriting a large file to save a small update can put the entire file at risk of corruption and introduce extra wear on flash storage media. With some file systems, an application can protect a flat file by writing to a different file each time it is saved. However, this approach does not scale well and it is difficult to exhaustively test for edge cases where data loss can occur. (See Figure 2)

These problems can be solved, but they represent a significant distraction from the core functionality of a medical device. An embedded relational database supplies developers with a safe and optimized interface for data management that leverages industrystandard design patterns, including:

• A table-based relational data model suitable for SQL queries;
• Transaction recovery and rollback for consistent, reliable updates;
• Transaction isolation to share data between tasks with minimal blocking;
• Replication and remote access to distribute data and achieve high availability;
• Encrypted storage and communications to secure data.

Regulatory Concerns

Medical device manufacturers build robust, high-value products that must store, analyze, connect, and distribute data. For mission-critical systems, a solid database framework with low total cost of ownership is needed to manage this data. But it is also important to reduce complexity wherever possible, both to support fixed hardware constraints and to simplify risk identification and mitigation. Developed nations across the different continents have regulations specifically designed to minimize risk in medical devices.

In the various industry standards based on those regulations, the term SOUP, which stands for Software of Unknown Provenance, is used to describe third-party software used in medical devices and other safety-critical embedded systems. SOUP can be any type of software, from an embedded database library, to the file system and operating system that is developed with an unknown process. Because the safetyrelated properties of SOUP are not clearly defined, medical device manufacturers must rely on the software vendor to provide assurance of quality.

Specific practices must be exercised when SOUP is used in a medical device, such as working closely with the embedded database vendor to check compliance with software development guidelines, identify potential design artifacts, and validate test coverage. Therefore, establishing a relationship with the vendor is important, as the regulation authorities require software validation and quality control. These validation requirements apply to all software components used in a medical device, including SOUP.

All system software components, even if purchased off-the-shelf, are expected to have documented requirements that fully define their intended use, and information against which testing results and other evidence that are compared, to show that the software is validated for its intended use. (See Figure 3)

Technical Support

Another important factor for database software embedded in a medical device is the relationship between the manufacturer and database vendor to receive on-time, cost-effective technical support both during development and after. Technical support for an embedded database is more involved than other fields of software due to the tight integration with the application and numerous opportunities for optimization. While free software may reduce upfront cost, the total cost of ownership also includes development and maintenance costs associated with meeting the needs of a specific application and hardware platform.

When a medical device software developer needs in-depth familiarity with technical tradeoffs that can affect the performance and reliability of an embedded database, waiting for the community on a mailing list or forum to form a consensus is not an option. Since these communities do not have a business obligation to answer support questions, it is often necessary to hire a consultant or risk developing an inappropriate solution. In addition, any resulting customizations may become incompatible with future releases.

Conclusion

Developers of medical device application must rely on a database vendor that provides comprehensive knowhow and experience in this area, assisting the manufacturer to focus on developing unique, market-driven value while database experts assist with software development to reduce risk and cost.

Various medical device applications require uniquely different needs, such as support at the early stages of conceptual design and prototyping, during development and testing, and even when seeking national and international regulatory approval. An embedded database vendor needs to be a reliable resource.

While cost remains an important part of any software development, the most expensive consideration is the lost opportunities. Experiencing failure for medical devices means recall from the market, losing reputations, and not being able to build a success story. A developer of medical devices needs to evaluate the most important goals for their systems and focus on achieving them with safety, cost and time in mind.

This article was written by Sasan Montaseri, President and Founder, and Ryan Phillips, Senior Lead Engineer, ITTIA, Bellevue, WA. For more information, Click Here .

---