Products
Morris Medical Monday: Polarion MedPack and Regulatory Compliance Part 2
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 sol...
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 compliance support.
MedPack Compliance
MedPack helps medical device development projects to be compliant. The MedPack Kernel is an implementation of the IEC 62304 (Software Lifecycle Process for Medical Devices) standard. Last week we already had a look into Chapter 4 and Chapter 5.1.
Today we will have a look on the rest of chapter 5 and what will be covered by Polarion MedPack:
Mapping of IEC 62304 to MedPack
| Chapter of IEC 62304:2006 | Fulfilled by MedPack through: |
| 5.2 Software requirements analysis | |
| 5.2.1 Define and document software requirements from SYSTEM requirements | Work Item: Software Requirement, Traceability to Work Item: System Requirement |
| 5.2.2 Software requirements content | Attribute “Requirement category” of Work Item type: Software Requirement |
| 5.2.3 Include RISK CONTROL measures in software requirements | Work Item: Risk Control Measure, Traceability to Work Item: Software Requirement |
| 5.2.4 Re-EVALUATE MEDICAL DEVICE RISK ANALYSIS | Manual Attention: Overall risk (analysis) management is not done by MedPack |
| 5.2.5 Update SYSTEM requirements | Manual Attention: MedPack does not control the overall process and has therefore no knowledge when system requirements change |
| 5.2.6 Verify software requirements | Workflow of Work Item: Software Requirement |
| 5.3 Software ARCHITECTURAL design | |
| 5.3.1 Transform software requirements into an ARCHITECTURE | Work Item: Architectural Design, Work Items Implementation (Software System, Software Item, Software Unit, SOUP) |
| 5.3.2 Develop an ARCHITECTURE for the interfaces of SOFTWARE ITEMS | Work Item: Architectural Design, Work Items Implementation (Software System, Software Item, Software Unit, SOUP) |
| 5.3.3 Specify functional and performance requirements of SOUP item | SOUP – Attributes |
| 5.3.4 Specify SYSTEM hardware and software required by SOUP item | SOUP – Attributes |
| 5.3.5 Identify segregation necessary for RISK CONTROL | Manual Attention: This can only be done with a textual explanation |
| 5.3.6 Verify software ARCHITECTURE | Architectural Design – Attributes |
| 5.4 Software detailed design | |
| 5.4.1 Refine SOFTWARE ARCHITECTURE into SOFTWARE UNITS | Work Item: Software Unit, links from Work Item: Software Item |
| 5.4.2 Develop detailed design for each SOFTWARE UNIT | Work Item: Detailed Design |
| 5.4.3 Develop detailed design for interfaces | Detailed Design – Attributes |
| 5.4.4 Verify detailed design | Detailed Design – Attributes |
| 5.5 SOFTWARE UNIT implementation and verification | |
| 5.5.1 Implement each SOFTWARE UNIT | Manual Attention: Link-check from Work Item: Software Unit to repository (source code) |
| 5.5.2 Establish SOFTWARE UNIT VERIFICATION PROCESS | Software Development Plan |
| 5.5.3 SOFTWARE UNIT acceptance criteria | Software Unit – Attributes |
| 5.5.4 Additional SOFTWARE UNIT acceptance criteria | Software Unit – Attributes |
| 5.5.5 SOFTWARE UNIT VERIFICATION | Workflow of Work Item: Software Unit |
| 5.6 Software integration and integration testing | |
| 5.6.1 Integrate SOFTWARE UNITS | Integration Test – Attributes |
| 5.6.2 Verify software integration | Integration Test – Verification attributes |
| 5.6.3 Test integrated software | Integration Test – Workflow and Work Item status |
| 5.6.4 Integration testing content | Integration Test – Attribute “Test type/content” |
| 5.6.5 Verify integration test procedures | Wiki page: Software Integration Plan |
| 5.6.6 Conduct regression tests | Integration Test – Workflow and Work Item status. Manual Attention: The overall development process must care for regression tests being properly performed. |
| 5.6.7 Integration test record contents | Integration Test – Attributes |
| 5.6.8 Use software problem resolution PROCESS | Integration Test, link to Anomalies |
| 5.7 SOFTWARE SYSTEM testing | |
| 5.7.1 Establish tests for software requirements | Software System Test – Attributes. Wiki page: Missing Traceability Report |
| 5.7.2 Use software problem resolution PROCESS | Software System Test – link to Anomaly. Wiki page: Missing Traceability Report |
| 5.7.3 Retest after changes | Manual Attention: The overall development process must care for regression tests being properly performed. |
| 5.7.4 Verify SOFTWARE SYSTEM testing | Software System Test – Review Attributes. Wiki page: Missing Traceability Report |
| 5.7.5 SOFTWARE SYSTEM test record contents | Software System Test – Attributes |
| 5.8 Software release | |
| 5.8.1 Ensure software VERIFICATION is complete | Wiki page: Review Report |
| 5.8.2 Document known residual ANOMALIES | Anomalies – Resolution state “known anomaly” |
| 5.8.3 EVALUATE known residual ANOMALIES | Anomalies – Attribute “Rational for not fixing anomaly” |
| 5.8.4 Document released VERSIONS | Subversion / Polarion ALM by design |
| 5.8.5 Document how released software was created | Subversion / Polarion ALM by design |
| 5.8.6 Ensure activities and tasks are complete | Wiki page: Review Report |
| 5.8.7 Archive software | Subversion / Polarion ALM by design |
| 5.8.8 Assure repeatability of software release | Subversion / Polarion ALM by design |
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.
