{"id":1104,"date":"2014-05-05T11:00:45","date_gmt":"2014-05-05T18:00:45","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Polarion-Blog\/Morris-Medical-Monday-Polarion-MedPack-and-Regulatory-Compliance\/ba-p\/380857"},"modified":"2026-03-26T05:34:39","modified_gmt":"2026-03-26T09:34:39","slug":"morris-medical-monday-polarion-medpack-and-regulatory-compliance-part-2","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/morris-medical-monday-polarion-medpack-and-regulatory-compliance-part-2\/","title":{"rendered":"Morris Medical Monday: Polarion MedPack and Regulatory Compliance Part 2"},"content":{"rendered":"

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<\/A> and Polarion extensions<\/A>.<\/p>\n

Today we will continue on the subject of Polarion’s MedPack extension<\/A>, and have a look into MedPack’s compliance support.
\n

MedPack Compliance<\/H2>
\nMedPack helps medical device development projects to be compliant. The MedPack Kernel is an implementation of the IEC 62304<\/STRONG> (Software Lifecycle Process for Medical Devices) standard. Last week<\/A> we already had a look into Chapter 4 and Chapter 5.1.<\/p>\n

Today we will have a look on the rest of chapter 5 and what will be covered by Polarion MedPack:
\nMapping of IEC 62304 to MedPack<\/B>
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Chapter of IEC 62304:2006<\/STRONG><\/TD>
\n		Fulfilled by MedPack through:<\/STRONG><\/TD>
\n<\/TR>
\n<\/THEAD>
\n
5.2 Software requirements analysis<\/TD>
\n<\/TR>
\n
5.2.1 Define and document software requirements from SYSTEM requirements<\/TD>
\n		Work Item: Software Requirement, Traceability to Work Item: System Requirement<\/TD>
\n<\/TR>
\n
5.2.2 Software requirements content<\/TD>
\n		Attribute “Requirement category” of Work Item type: Software Requirement<\/TD>
\n<\/TR>
\n
5.2.3 Include RISK CONTROL measures in software requirements<\/TD>
\n		Work Item: Risk Control Measure, Traceability to Work Item: Software Requirement<\/TD>
\n<\/TR>
\n
5.2.4 Re-EVALUATE MEDICAL DEVICE RISK ANALYSIS<\/TD>
\n		Manual Attention: Overall risk (analysis) management is not done by MedPack<\/TD>
\n<\/TR>
\n
5.2.5 Update SYSTEM requirements<\/TD>
\n		Manual Attention: MedPack does not control the overall process and has therefore no knowledge when system requirements change<\/TD>
\n<\/TR>
\n
5.2.6 Verify software requirements<\/TD>
\n		Workflow of Work Item: Software Requirement<\/TD>
\n<\/TR>
\n
5.3 Software ARCHITECTURAL design<\/TD>
\n<\/TR>
\n
5.3.1 Transform software requirements into an ARCHITECTURE<\/TD>
\n		Work Item: Architectural Design, Work Items Implementation (Software System, Software Item, Software Unit, SOUP)<\/TD>
\n<\/TR>
\n
5.3.2 Develop an ARCHITECTURE for the interfaces of SOFTWARE ITEMS<\/TD>
\n		Work Item: Architectural Design, Work Items Implementation (Software System, Software Item, Software Unit, SOUP)<\/TD>
\n<\/TR>
\n
5.3.3 Specify functional and performance requirements of SOUP item<\/TD>
\n		SOUP – Attributes<\/TD>
\n<\/TR>
\n
5.3.4 Specify SYSTEM hardware and software required by SOUP item<\/TD>
\n		SOUP – Attributes<\/TD>
\n<\/TR>
\n
5.3.5 Identify segregation necessary for RISK CONTROL<\/TD>
\n		Manual Attention: This can only be done with a textual explanation<\/TD>
\n<\/TR>
\n
5.3.6 Verify software ARCHITECTURE<\/TD>
\n		Architectural Design – Attributes<\/TD>
\n<\/TR>
\n
5.4 Software detailed design<\/TD>
\n<\/TR>
\n
5.4.1 Refine SOFTWARE ARCHITECTURE into SOFTWARE UNITS<\/TD>
\n		Work Item: Software Unit, links from Work Item: Software Item<\/TD>
\n<\/TR>
\n
5.4.2 Develop detailed design for each SOFTWARE UNIT<\/TD>
\n		Work Item: Detailed Design<\/TD>
\n<\/TR>
\n
5.4.3 Develop detailed design for interfaces<\/TD>
\n		Detailed Design – Attributes<\/TD>
\n<\/TR>
\n
5.4.4 Verify detailed design<\/TD>
\n		Detailed Design – Attributes<\/TD>
\n<\/TR>
\n
5.5 SOFTWARE UNIT implementation and verification<\/TD>
\n<\/TR>
\n
5.5.1 Implement each SOFTWARE UNIT<\/TD>
\n		Manual Attention: Link-check from Work Item: Software Unit to repository (source code)<\/TD>
\n<\/TR>
\n
5.5.2 Establish SOFTWARE UNIT VERIFICATION PROCESS<\/TD>
\n		Software Development Plan<\/TD>
\n<\/TR>
\n
5.5.3 SOFTWARE UNIT acceptance criteria<\/TD>
\n		Software Unit – Attributes<\/TD>
\n<\/TR>
\n
5.5.4 Additional SOFTWARE UNIT acceptance criteria<\/TD>
\n		Software Unit – Attributes<\/TD>
\n<\/TR>
\n
5.5.5 SOFTWARE UNIT VERIFICATION<\/TD>
\n		Workflow of Work Item: Software Unit<\/TD>
\n<\/TR>
\n
5.6 Software integration and integration testing<\/TD>
\n<\/TR>
\n
5.6.1 Integrate SOFTWARE UNITS<\/TD>
\n		Integration Test – Attributes<\/TD>
\n<\/TR>
\n
5.6.2 Verify software integration<\/TD>
\n		Integration Test – Verification attributes<\/TD>
\n<\/TR>
\n
5.6.3 Test integrated software<\/TD>
\n		Integration Test – Workflow and Work Item status<\/TD>
\n<\/TR>
\n
5.6.4 Integration testing content<\/TD>
\n		Integration Test – Attribute “Test type\/content”<\/TD>
\n<\/TR>
\n
5.6.5 Verify integration test procedures<\/TD>
\n		Wiki page: Software Integration Plan<\/TD>
\n<\/TR>
\n
5.6.6 Conduct regression tests<\/TD>
\n		Integration Test – Workflow and Work Item status. Manual Attention: The overall development process must care for regression tests being properly performed.<\/TD>
\n<\/TR>
\n
5.6.7 Integration test record contents<\/TD>
\n		Integration Test – Attributes<\/TD>
\n<\/TR>
\n
5.6.8 Use software problem resolution PROCESS<\/TD>
\n		Integration Test, link to Anomalies<\/TD>
\n<\/TR>
\n
5.7 SOFTWARE SYSTEM testing<\/TD>
\n<\/TR>
\n
5.7.1 Establish tests for software requirements<\/TD>
\n		Software System Test – Attributes. Wiki page: Missing Traceability Report<\/TD>
\n<\/TR>
\n
5.7.2 Use software problem resolution PROCESS<\/TD>
\n		Software System Test – link to Anomaly. Wiki page: Missing Traceability Report<\/TD>
\n<\/TR>
\n
5.7.3 Retest after changes<\/TD>
\n		Manual Attention: The overall development process must care for regression tests being properly performed.<\/TD>
\n<\/TR>
\n
5.7.4 Verify SOFTWARE SYSTEM testing<\/TD>
\n		Software System Test – Review Attributes. Wiki page: Missing Traceability Report<\/TD>
\n<\/TR>
\n
5.7.5 SOFTWARE SYSTEM test record contents<\/TD>
\n		Software System Test – Attributes<\/TD>
\n<\/TR>
\n
5.8 Software release<\/TD>
\n<\/TR>
\n
5.8.1 Ensure software VERIFICATION is complete<\/TD>
\n		Wiki page: Review Report<\/TD>
\n<\/TR>
\n
5.8.2 Document known residual ANOMALIES<\/TD>
\n		Anomalies – Resolution state “known anomaly”<\/TD>
\n<\/TR>
\n
5.8.3 EVALUATE known residual ANOMALIES<\/TD>
\n		Anomalies – Attribute “Rational for not fixing anomaly”<\/TD>
\n<\/TR>
\n
5.8.4 Document released VERSIONS<\/TD>
\n		Subversion \/ Polarion ALM by design<\/TD>
\n<\/TR>
\n
5.8.5 Document how released software was created<\/TD>
\n		Subversion \/ Polarion ALM by design<\/TD>
\n<\/TR>
\n
5.8.6 Ensure activities and tasks are complete<\/TD>
\n		Wiki page: Review Report<\/TD>
\n<\/TR>
\n
5.8.7 Archive software<\/TD>
\n		Subversion \/ Polarion ALM by design<\/TD>
\n<\/TR>
\n
5.8.8 Assure repeatability of software release<\/TD>
\n		Subversion \/ Polarion ALM by design<\/TD>
\n<\/TR>
\n<\/TBODY>
\n<\/TABLE>
\nFor more information about Polarion’s MedPack visit our Extension Portal using following link:
\nhttp:\/\/extensions.polarion.com\/extensions\/31-polarion-alm-medpack-iec-62304<\/A><\/p>\n

I hope you liked this article and you will visit our blog again when there is another Morris Medical Monday <\/B>article.<\/p>\n


\n

\"Medical<\/A><\/P><\/p>\n","protected":false},"excerpt":{"rendered":"

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…<\/p>\n","protected":false},"author":63333,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[],"industry":[],"product":[],"coauthors":[],"class_list":["post-1104","post","type-post","status-publish","format-standard","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1104","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/users\/63333"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/comments?post=1104"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1104\/revisions"}],"predecessor-version":[{"id":1105,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/posts\/1104\/revisions\/1105"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/media?parent=1104"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/categories?post=1104"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/tags?post=1104"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/industry?post=1104"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/product?post=1104"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/polarion\/wp-json\/wp\/v2\/coauthors?post=1104"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}