Morris Medical Monday: Polarion MedPack Work Item Types

Welcome back to Morris Medical Monday: a weekly series for medical device development companies (and companies who are related to such companies), providing some useful information about Polarion solutions and Polarion extensions.

Today we will continue on the subject of Polarion’s MedPack extension, and have a look into a general overview of MedPack’s Work Item Types.

The international standard IEC 62304 (“Medical device software – Software life cycle processes”) requires specific information to be documented and linked. These items are represented as the following work items in MedPack:

Anomaly

An anomaly according to clause 5.6.8 of the IEC 62304:2006. An issue of this type contains a description of an anomaly that has been discovered during integration or system test. It must be linked to a test and a resulting problem report.

Architectural Design

The description of the architectural design according to clause 5.3 of the IEC 62304:2006. The architectural design must clarify the relationship between the software system and the software items. Any issue of this type must be linked to a software requirement and the software system and software item entries it describes. An architectural design must only be provided in case of a class B or class C project.

Change Request

A change request resulting from either a risk control measure or a problem report, according to clause 9.2 of the IEC 62304:2006. Any issue of this type must be linked to the risk control measure or the problem report it springs from and to the software requirement following the request.

Detailed Design

A detailed design description according to clause 5.4 of the IEC 62304:2006. The detailed design must clarify the relationship between the software items and the software units. Any issue of this type must be linked to the architectural design it states more precisely and the software item and software unit entries it describes. A detailed design must only be provided in case of a class C project.

Feedback

User or market feedback according to clause 6.2.1.2 of IEC 62304:2006. A feedback entry might have a link to a problem report generated from it.

Hazardous Situation

Description of a hazardous situation according to chapter 7.1 of IEC 62304:2006. Any hazardous situation must have a link to the software item the hazardous situation springs from.

Integration Test

An integration test description according to clause 5.6.3 of the IEC 62304:2006. Any issue of this type either describes the test completely or links to test procedure descriptions or code to perform the test. It must be linked to the software item(s) and software unit(s) covered by the test. Integration tests must only be performed in case of a class B or class C project.

Problem Report

A problem report describing an anomaly found during an integration or system test according to clause 9.1 of IEC 62304:2006. Any issue of this type must be linked to the source anomaly and the resulting change request, if there is any.

Risk Control Measure

Description of a risk control measure according to chapter 7.2 of IEC 62304:2006. A risk control measure have a traceability link to the hazardous situation it mimic as well as a link from the software requirement that springs from it.

Software Item

A description of a software item according to clause 3.25 of IEC 62304:2006. Any issue of this type must be linked to the parent software system(s) and the child software unit(s). In the case that this item is a SOUP, a link to the SOUP issue must be provided as well. See the note in clause 3.25 for further information about software decomposition.

Software Requirement

A software requirement according to clause 5.2.1 of IEC 62304:2006. Any issue of this type must be linked to its source, which is either a system requirement or a change request and to the architectural design that implements the requirement.

Software System

A description of a software system according to clauses 3.27 and 3.25 of IEC 62304:2006. Any issue of this type must be linked to its child software item(s). See the note in clause 3.25 for further information about software decomposition.

Software System Test

A system test description according to clause 5.7.1 of the IEC 62304:2006. Any issue of this type either describes the test completely or links to test procedure descriptions or code to perform the test. It must be linked to the software system(s) and software item(s) covered by the test as well as the software requirement(s) that is tested. System tests must only be performed in case of a class B or class C project.

Software Unit

A description of a software unit according to clauses 3.28 and 3.25 of IEC 62304:2006. Any issue of this type must be linked to its parent software item(s). See the note in clause 3.25 for further information about software decomposition.

SOUP

A description of a software component of unknown provenance (SOUP) used in the project, according to clause 3.29 of IEC 62304:2006. Any issue of this type must be linked to the software item that is implemented by the component.

System Requirement

A system requirement according to clause 5.1 of IEC 62304:2006. Any issue of this type must be linked to its child software requirement, if it the system requirement is fulfilled by software.

Tool

A Description of a tool used for creating the medical software (compilers, builders, linkers, analysis software) and their configuration. Needed to fulfill the requirements of clause 5.1.4 and 5.1.10 of IEC 62304 for class B or C projects.

 

For more information about Polarion’s MedPack visit our Extension Portal using following link:
http://extensions.polarion.com/extensions/31-polarion-alm-medpack-iec-62304I hope you liked this article and you will visit our Blog again when there is another Morris Medical Monday article.

---