ECG Monitor / Defibrillator (Class III)
Create IEC-62304 life cycle documentation for a legacy product, including the software architecture specification aligned with upper level requirements specifications.
Assign the safety classification for the individual software items based on the device intended use, and consistent with the system safety risk assessment, for IEC-62304 compliance.
The company was addressing several regulatory requirements to commercialize legacy product in Europe and Canada, and in order to do so IEC-60601 Ed. 3 certification was required. Several audit findings related to inadequate design history records, and non-conformance to the IEC-62304 life cycle standard for the device software. For many areas of the software resident on the device there was little or no design documentation at all.
Initial collaboration with cross-functional development leads provided some design history information about the legacy software, and gaps were filled by means of reverse engineering the code as necessary. This was a challenging task as the software system was comprised of many components; including firmware for a DSP, configurations for FPGA and CPLD device, firmware for micro-controllers resident on internal PCBAs connected with the main system processor, and other firmware resident on externally connected accessory devices (e.g. patient connected measurement devices, data communication radios,etc.).
After sufficient design information was collected, a software architecture specification was created, decomposing the software system into logical software items and units that are mapped to system use cases and user needs (system) requirements. In order to address the Class C requirements (interfaces, segregation, integration) of the IEC-62304 standard the software architecture specification presented 6 different viewpoints: physical, logical, dynamic, information, security, and deployment. Each software item was then assigned a safety classification (A, B, or C) based on the system function the software item serves and if there are traces to hazards in the system safety risk assessment, per the guidelines of IEC 62304 and ISO 14971 standards. The software hazard analysis was also updated to align with the system safety risk assessment for system hazards and their associated harm severity levels (patient/user harm). Hazardous situations that can be caused or contributed to by software were carefully identified, and documented to demonstrate traceability to specific software items, specific failure causes, risk control measures and verification records. Per the risk management requirements assessment of post production information was also reviewed to confirm no additional new hazards connected with legacy software is evident and the existing risk controls are effective for continued use.
Based on the software item decomposition identified and safety classifications, detailed design, unit tests, and integration tests were created, executed, reviewed and approved. Finally, complete traceability between requirements, design and verification artifacts was established, risk management files were updated, and placed in project DHF.
At the end the software architecture specification was in place and the development team had a great reference to help with planning feature additions/changes, collaborate on implementation trade-offs, taking a risk-based approach, and determine the unit tests and regression tests that will need to be rerun after a change iteration based on risks, hazardous situations and inter-dependencies between software items.
Contact us for a concrete proposal and quotation for your project.