The journey from concept to certification of a new medical device is a lengthy one, often spanning several months or even years. A common challenge is ensuring the device’s functionality matches the customer’s original concept, especially when integrating with a hospital network (like an SDC device). To tackle the issue of ensuring the final product meets initial requirements, our team developed a specialized tool. This tool provides product owners with transparent, measurable, and accessible data on how each stage of development aligns with the original specifications of the medical database. Auriga uses this tool in all of our medical software development projects, aiding the client in making well-informed and timely decisions for the product’s ongoing development.
SDC Standard Protocol in Medical Devices
The SDC (Service-oriented Device Connectivity) protocol represents a unified standard for connecting medical devices into one network. Developed by the OR.NET association, which originated from a research initiative sponsored by Germany’s Federal Ministry of Education and Research, this protocol was formally recognized as the ISO/IEEE 11073-20701:2020 standard in 2020, with the International Organization for Standardization (ISO) endorsing and publishing the complete set of foundational SDC standards.
Previously, network-enabled medical devices used proprietary protocols specific to each manufacturer, leading to widespread incompatibility connectivity issues. This limitation was a significant barrier to delivering high-quality, efficient emergency medical services. With the advent of the SDC standard, secure and seamless interaction among medical devices is now possible. It also facilitates data exchange between these devices and HL7-compatible hospital information systems, transcending manufacturer-specific barriers.
Critical Aspects of Developing Software for Medical SDC Devices
Developing software for devices that use the SDC (Service-oriented Device Connectivity) protocol involves distinct challenges and demands a tailored approach. Here are four critical elements to consider in such development projects:
Choosing the Right Framework: Given that SDC is a standardized protocol, it offers readily available components and tools for implementation. Leveraging existing frameworks for different programming languages and testing tools can drastically reduce project development time, provided the framework is appropriately selected.
Establishing a Testing Strategy: Implementing a robust testing strategy that ensures compatibility with other SDC devices in the market is crucial. This averts potential future issues and provides seamless interoperability between devices.
Selecting a Suitable Hardware Platform: To efficiently work with the SDC protocol, the team must consider the hardware and network performance requirements. Integrating SDC devices with legacy equipment may pose challenges due to its reliance on SOAP, XML, and encryption technologies. Conducting thorough load testing is critical to optimizing the system’s performance.
Developing the Medical Device Information Base (MDIB): Developing the device’s descriptive database component accurately and efficiently is vital. This step dramatically simplifies the project’s development, testing, and maintenance phases.
Understanding the Medical Database in the SDC Standard
Every medical device that integrates into a shared hospital information network and communicates with other devices using the SDC protocol is characterized by parameters listed in a medical database, referred to in the standard as the Medical Data Information Base (MDIB). The descriptive portion of this database encompasses various elements like patient vital sign indicators, alarm signal parameters, and their respective threshold values. These elements are subject to considerable variations based on specific customer needs, such as measurement units, patient age groups, and whether the methods for gathering data are invasive or non-invasive. These factors collectively contribute to the complex and detailed requirements of the MDIB’s descriptive section.
As depicted in Figure 1, the structure of a standard medical database includes Virtual Medical Devices (VMD), each integrating metric channels, alarm signals, and the capability to modify these elements.
Metric channels (channel) encompass various vital patient metrics (metrics), such as data on blood pressure, temperature, oxygen levels, and more.
Alarm signals (AlertSystem) consist of condition sets (AlertConditions) activated by specific metrics, such as elevated temperatures, blood pressure spikes, or other indicators surpassing predefined thresholds.
The Service Control Object (SCO) involves operations to adjust metric parameters or alarm signals. An example would be modifying the threshold for blood pressure that triggers an alarm signal.
Tool Operational Method
As we have previously noted, a prevalent challenge in projects related to developing medical devices that adhere to the SDC protocol is verifying if the actual device functions match the predefined parameters established during the design phase. Typically, engineers address this task through manual, step-by-step comparisons. However, Auriga’s developed tool automates this analysis, significantly reducing the verification time from a full day to just a few minutes.
Practical Approach
The developer starts by retrieving an XML file representing the MDIB from the technical specification. This XML file serves as the “expected” CSV file in our developed tool.
Next, an engineer connects to the developed SDC device and extracts data from its medical database, creating the “actual” CSV file.
To facilitate comparison, it is essential to standardize the expected and actual results in a standard format, usually CSV. The tool accomplishes this by converting the XML file into CSV format using XSLT transformation. The parameters exported to the CSV file are defined separately and can be tailored to each customer’s requirements. Generating the CSV file for the SDC device is slightly more time-consuming. It involves reading the medical database from the connected device, which depends on the data format used (e.g., Google Protocol Buffers, JSON, XML, etc.), followed by transformation into CSV format.
Following this process, both files are uploaded into the tool developed by our team. It automatically compares them and generates a report, as depicted in Figure 2. This report itemizes the parameters of the actual device that fall into the following categories:
- Matched the expected ones.
- Added as compared to the planned functionality.
- Removed during the development.
- Modified as compared to the initial technical specification, along with a description of the changes made.
The comparison results serve not only for visualizing disparities but also for further analysis, including utilizing other data comparison tools. Additionally, the tool can accept a supplementary list of parameters to exclude from the comparison. This feature proves valuable when these parameters have not yet been implemented or are not intended for implementation.
Pros and Cons of the Tool
Auriga’s developed tool has demonstrated its effectiveness in a lengthy project spanning over four years. This project focused on developing an SDC device for a prominent medical equipment manufacturer. The project adopted an iterative approach, with multiple stages and involvement from development and testing teams located in various countries. At the end of each stage, there was a comprehensive review and evaluation of the successful integration of the device’s functionalities, leading to the transition to the subsequent phase. Moreover, engineers frequently relied on the tool to personally validate the developed functions, ensuring their readiness for formal testing in the upcoming releases.
Based on our practical experience with this tool, we can confidently affirm that it significantly reduces the time required to compare the “specified” and “implemented” parameters of the developed device compared to traditional methods, achieving this with remarkable efficiency. While manual parameter verification typically consumes approximately several man-hours and is repeated at least twice a month, the automated process takes minutes. It can be performed as frequently as needed. Moreover, this tool diminishes human errors thanks to the extensive automation of the process. Its applicability in the initial stages of development enables prompt adjustments and expedites the product’s time-to-market. The final report generated by the tool serves as a valuable resource for customers during the preparation for medical device certification.
However, the tool developed by Auriga also has its limitations. For instance, an SDC device can output information in various data formats, depending on the specific device implementation. These formats may include JSON, Google Protocol Buffers, and others. Adapting the tool to transform “actual” data from the medical device into a CSV file may be necessary.
Furthermore, not all parameters from the medical database are currently accessible for comparison. This list is configurable and subject to expansion. If you are considering using this tool for your project, please get in touch with our expert to assess its compatibility with your SDC device.
Please refer to our whitepaper for detailed insights and information on ensuring medical device interoperability with hospitals’ legacy systems using the SDC protocol. In it, we discuss challenges in converting proprietary protocols to SDC, provide solutions, and highlight potential bottlenecks. We also suggest steps to enable manufacturer-independent medical device connectivity for secure health information exchange in hospitals.
