spk-logo-white-text-short
0%
1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

Leveraging PTC Integrity as a Medical Device Solution

Written by SPK Blog Post
Published on August 5, 2015

When you first purchase PTC Integrity Lifecycle Manager, what you are getting is pretty much a blank canvas. To assist you in getting your operation off the ground, PTC also provides a number of different pre-built solutions. These solutions have been designed to target different industry verticals. For example, PTC has built a solution targeting the automotive industry, the application lifecycle management solution (ALM) was designed for manufacturers of high tech electronics. There is also an agile solution, for those who would prefer a more agile development methodology.

In this article, I am going to talk about using PTC Integrity as a medical device solution. This solution was designed with the structures and processes required to meet the challenges of developing new products in the highly regulated medical device industry.

The primary purpose of any PTC Integrity Lifecycle Manager solution is to take ideas and to make them into effective products quickly and with as little churn as possible. All the while, ensuring that everything you wanted to be part of the product has been identified, developed, and tested to the best it can be. The Medical Device solution that can be installed in PTC Integrity Lifecycle Manager consists of four main sections—a section to manage your requirements, a section to manage risk, a section to manage your testing efforts, and a section to manage change. I will discuss each of these in the paragraphs below:

1. Managing Requirements

Requirements are managed through 3 containers that are referred to as document domains. Each fulfills a specific role in the development process and are linked together via trace relationships.

First, there is the Input Document. This document contains all of the raw ideas that are used to determine what the new product will be and how it will function. Second, there is the Requirement Specification. This document contains the ideas that have been decomposed from Input Document into specific technical requirements. Each piece of input can be traced via the “Decomposes To” trace relationship into one or more requirements and the requirements can be decomposed from multiple pieces of input. The last container is the Design Specification. This document contains the specific design response that satisfies the decomposed requirements using the “Satisfies” trace relationship.

SPK Managing Requirements

In the end, as a result of this ability to trace between the various containers, you get a tightly designed product.

2. Managing Risk

Anytime you are developing a product where safety is a concern, at some time or another within the development process you are going to have to manage any risks inherent in the product. The Medical Device Solution installed on top of PTC Integrity Lifecycle Manager provides functionality to manage risk within your product development.

This risk-management functionality is implemented in the form of three additional document containers called the Hazard document, the Risk Document as well as the Risk Control Measure document respectively. Hazards are identified in the Hazard document, as you may have guessed. Risks are what causes the hazards, and by identifying what the hazards are, you can also identify the risks that cause those hazards to exist. Lastly, once you know what those risks are, you can identify ways to help remove or minimize those risks, ways that may influence the overall design of your product.

 SPK Managing Risk

3. Test Management

The next main piece that makes up the Medical Device solution is Test Management. This is the cornerstone of any good product development process. In a previous article, I talked about Test Management; how you author tests, how you plan your testing and how you execute your testing and record your results. Here, I won’t go into that again. Instead I’ll talk about how Test Management relates to the other containers that make up the Medical Device solution.

The first thing to remember about testing is that pretty much everything at one time or another needs to be validated or verified on the road to product development. Every test that you write to validate or verify your product is stored within a Test Protocol document. For example, you may want to ensure that the product you’ve developed functions as laid out in your input document at a high level. You may have further test cases to ensure that each specific requirement in your Requirement Specification has been adequately covered off.  You will also want to ensure that any Risk Control Measure you’ve put in place has also been met appropriately as well.

4. Change Management

Last but not least, is the ability to manage change or Change Management. Change can be introduced several ways in the system—it can be introduced through shifts in the Inputs or Requirements, or resulting from defects found during testing.

 SPK Change Management

Defects detected during testing can be potentially used to spawn Change Requests, which in turn can spawn a Change Order. If the Change Order is authorized, it can be used to make changes to the overall design of your product. Changes of don’t have to be started with a Defect, they can also be spawned from various documents throughout the system as well.

For example, if for some reason, you needed to make a change to a Requirement you could use a Change Request to request authorization to make the change. Change Orders would then be created to authorize the change to the related design as well as the related tests.

Conclusion

These four main parts that make up the Medical Device solution in PTC Integrity Lifecycle Manager work together to assist in taking your product idea from the idea stage to an effective product in several ways. First, helping you take your ideas and translate them into technical requirements from which you can use to build your design. Secondly, by identifying and managing risks inherent in your design. Thirdly, by providing an effective mechanism through which you can perform your testing activities. Finally, by providing an effective method of managing the changes that will periodically be introduced in your product development cycle. That’s all four pieces managed from one place, all woven together to help ensure nothing gets lost nor forgotten.

Next Steps:

Latest White Papers

The Hybrid-Remote Playbook

The Hybrid-Remote Playbook

Post-pandemic, many companies have shifted to a hybrid or fully remote work environment. Despite many companies having fully remote workers, many still rely on synchronous communication. Loom offers a way for employees to work on their own time, without as many...

Related Resources

OKR and Agile: Harmonizing Strategic Goals with Agile Methodologies

OKR and Agile: Harmonizing Strategic Goals with Agile Methodologies

Objectives and Key Results (OKRs) and Agile methodologies like Scrum, Kanban, and SAFe are powerful frameworks designed to boost productivity and keep teams aligned. OKRs drive strategic goal-setting and measurable outcomes, while Agile approaches like Scrum focus on...

How Model-Based Definition (MBD) Cuts ECOs by 41% and Scrap by 47%

How Model-Based Definition (MBD) Cuts ECOs by 41% and Scrap by 47%

Organizations are increasingly turning to Model-Based Definition (MBD) to revolutionize their engineering and manufacturing processes. By embedding rich, digital annotations directly into 3D models, MBD provides a single source of truth for product definitions. This...