Products

Morris Medical Monday: Work Item Type "Software Item"

By morrisd

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 MedPack’s Software Item type Work Item.


Software Item


Description


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.

Workflow Steps


The Software Item Item uses the standard Verification Workflow.

VerificationWorkflow_Overview

Traceability & Impact


A Software Item Work Item must be traceable to a Software System Work Item, to a Architectural Design or to another Software Item Work Item and has an impact on a Integration Test Work Item and to a Hazardous SituationWork Item. It can also has an impact to a SOUP Work Item, to a Software Unit Work Item or to another Software Item Work Item.
For more information on traceability and impacts, see the Traceability wiki page.

Attributes


Work Item Attributes


The following custom fields must be filled out before verification can be requested:

























Attribute Name Type Description
Software Safety Class Enum (A,B,C,Inherit) A Software System have to classified in one of the following Software Safety Classes:
– Software Safety Class A (No injury or damage to health is possible)
– Software Safety Class B (Non-serious injury is possible)
– Software Safety Class C (Death or serious injury is possible)
– Inherit (Software Item inherit software safety class from linked Software System or Software Item)
(as required by IEC 62304:2006->4.3).
Rationale for classification other than ‘inherited’ Text It has to declare a reason, if a Software Item has another software safety class as ‘inherit’.
(as required by IEC 62304:2006->4.3d)
Segregation to other items concerning risk control [C] Text A effectively segregation to other Software Items concerning risk control.
(as required by IEC 62304:2006->5.3.5)

Verification Attributes


The following custom fields must be filled out before verification can be finshed and the work item can be closed:

























Attribute Name Type Description
Reviewer Text Person(s) to perform, performing or have performed a review.
Review summary Text Short summary of the review. Attachments should be used for additional information.
Last review date Date Hidden field automatically set when review has been finshed. Intended to be used for sorting and statistical analysis.

Verification Checklist


The following checklist must be filled out before verification can be finshed and the work item can be closed:





























Checklist entry Description
Incorrect or incomplete specification of functionality has been taken into account Identify potential causes of contribution to a hazardous situation
(as required by IEC 62304:2006->7.1.2a)
Software defects in the identified software item functionality has been taken into account Identify potential causes of contribution to a hazardous situation
(as required by IEC 62304:2006->7.1.2b)
Failure or unexpected results from SOUP has been taken into account Identify potential causes of contribution to a hazardous situation
(as required by IEC 62304:2006->7.1.2c)
Hardware failures or other software defects that could result in unpredictable software operation has been taken into account Identify potential causes of contribution to a hazardous situation
(as required by IEC 62304:2006->7.1.2d)
Reasonably foreseeable misuse has been taken into account Identify potential causes of contribution to a hazardous situation
(as required by IEC 62304:2006->7.1.2e)

Possible Resolutions


The following table shows the possible resolution values when the work item is closed:





















Resolution Name Description
Implemented The software item has been implemented.
Obsolete The software item has become obsolete and is no longer needed.
Discarded The work item entry has been discarded. No further attention is needed.

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



webinar banner: alm software impacts medical device compliance


 

Morris Daniel

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.stage.sw.siemens.com/polarion/morris-medical-monday-work-item-type-software-item/