Medical Devices PLM Software

Many companies spend a significant amount of time not only completing documentation during the design process, but also on storing it, retrieving it, getting the right approval, going through the gate approval process, and getting the correct update to the project status. In addition, this is not only a time consuming activity when storing and creating the documentation, but also when you need to retrieve documentation.

Companies spend a significant amount of time searching for the correct documents to retrieve. Because most solutions on the market are not tailored towards the specifics of the medical device industry. The process is only partially covered, resulting in manual updates of the documentation having to be made, manual check in, and conversion of the documents, resulting in a higher risk of error, increase in effort required, and a lack of visibility.

In this video, I will show you how you can manage documentation on a project that is off track to achieve an accurate, up to date project status. Faster documentation retrieval, improved visibility and decreased risk of errors. The system will point to the exact deliverables that are off track, which means that you are able to retrieve the right documentation the first time.

When you make changes and revisions to the documentation, the system automatically keeps track of changes and logs it. This ensures that everyone is working on the latest revision. The system is also able to automatically convert documentation to other file formats such as PDF. Lastly, when a new deliverable is marked as ready, the person responsible for signing off the change is automatically alerted when everybody has done their work to ensure the deliverable is finished the phase is automatically completed and everybody can move on to the next stage. When Mike arrives at work, the first thing he does is that he logs into Minerva PLM. Once he’s in the system, what Mike wants to do is that he wants to check the status of his projects. So he goes to projects and he sees that the ventilator project PB 560 is off track.

He opens the project to find out why this project is off track, and loads the deliverable matrix. In that matrix he can clearly see the status of all. He can see he has two deliverables that are off track. You can also see that one has a closing rule by owner and one has by a deliverable release. The closing rule for the country list and language requirements is Mike’s own deliverable, so he can close that by pushing the close button.

This will go in, tell the system that Mike is done, and it will set the status of this deliverable to closed automatically. The other deliverable that is not complete is the customer requirements document for the buzzer board. This is a word document that is supposed to be closed by an ECO. What Mike does is he goes into word through the office connector.

He searches the Aras database for this specific file. He finds it and now he can open it to edit. Word automatically loads the file from Aras and Mike can go in and complete this document. He adds that this document should also be valid for the ventilated PB 560 model, and he also goes in and updates the table of contents since the revision history is no longer needed in this document, as it’s now controlled by the PLM system. He saves this document back into Aras. This updates the file inside of Aras and automatically generates a PDF file that can be used as a viewable inside. Once the document is saved, it’s notified in word. He can go back, open the document object, click on the sidebar to load the viewable file to review that his changes have been implemented in the file. He scrolls down, and you can see that the table of contents has been updated, the revision history is no longer there, and he can also see that his update that this document should also cover the PB 560 ventilator series has also been implemented.

Going back to the main form of the document, Mike can go to the changes tab to see the status of the release process for this document. He finds a relationship to the document change order for to release it sees that that is assigned to him, and Mike can now sign off on the release process, releasing the document, which will in return then also close the last deliverable line that was off track in his project. The document is now released. Mike can go back to his project, refresh his delivery matrix, and he can now see that the last off track, deliverable is now closed. If he goes back and searches for his projects again, he can now see that everything is okay.

All projects are on track and he can go on with his day.

Capturing the design History file and Device master record are examples of two document structures that are required by the regulatory bodies. They are associated to a device or product, and we need to be able to capture changes to them. This can in many cases be a manual tedious task to complete. So having a system that where you easy can create as many regulatory structures that you want to manage and have them managed in the same way so that they are automatically created, automatically tracked automatically baselined should be a requirement for any solution in the medical device industry. Several of our customers find that there are other documentation structures, like the technical file, that will also need to be managed in the same way as a DHF and DMR. Having an easy way to create new document data structures like the DHF and DMR that have the same requirements for change management and traceability is a critical factor in order to be able to support not only your immediate needs, but also your possible needs in the future.

In a company the team are working on the design of a new respiratory ventilator. As you can imagine, developing such equipment is a very complex project and having full traceability of what was done by who, what was changed with what is crucial, not only for getting ventilators to the market faster, but also for getting the required approvals from the regulatory bodies. In this company project changes are not a nightmare anymore. Mike and his team is working very hard to complete the ventilator project, but during the concept phase, they realize that they will not be able to complete the patent filing within the concept phase, and they wish to move that to the next phase, which is engineering prototype.

In order to do such a change in Minerva PLM there is a need to do a change order called design change. This is done in order to maintain the audit trail and the traceability of changes that have been made. These changes can be automatically created from the change section of the project by clicking the Design Change button. This will automatically create the change order, which Mike now automatically can go in and vote to the next step.

Getting it to this start work will create a new revision. As we see the revision changes from D to E, and it’s now in work, meaning that Mike can go in and edit this project. So he does this. He identifies the patent filing deliverable right clicks, cuts that deliverable goes down to engineering prototype and paste the deliverable in this phase. By clicking save, now this deliverable is moved from concept and into engineering prototype. As we can see here, it is now located in the engineering prototype phase of the project. Project is still in the status of in-work meaning that this change to the project has not yet been accepted. In order to get that accepted, Mike needs to push this design change into a review step where the steering group can assess the proposed changes and make a decision whether or not they should be allowed.

So Mike goes in and he sends this for review. He can write a comment. Due to time, we would like to move the patent filing to next phase. When he clicks complete notifications are sent out to the entire steering group that there now is a change request from Mike to move this deliverable. They can now assess this change and come with their input, whether or not they want to approve this change.

In the meanwhile, all Mike can do is wait. After a while, Mike gets notified that the steering group has approved his changes, and when he goes to his project now, he can see that the revision E is now released. When he moves into his project, he can now see that the patent filing is no longer part of concept phase, but has been moved to the engineering prototype phase.

So this buys the team a little bit more time to complete the concept phase and do everything properly in there. For traceability reasons, all versions and baselines are always kept in the system. So if anybody wants to see well, we can see now that this is revision E, what was the status of revision D of this project and how did the deliverable matrix and all the deliverables look at that point in time?

Mike can go and open the version section of this project where all versions and baselines of the project is being kept. He can go back to the revision D and open that. When we open the revision D of the project. We can clearly see that the patent filing here was part of the concept phase, while now it is part of the engineering prototype.

In this baselining, Minerva PLM will not only keep the history of what was in which phase, but we also keep track of which version of each deliverable which actually is valid at any point in time. And if you open any file, any deliverable, any part from a previous version, you will always be sent to that specific version of the deliverable that was valid at that point in time, providing a very strong audit trail and true baselining of your projects.

Capturing the design history file and device master record are just two examples of documentation structures that are required by regulatory bodies. They are associated to a device or a product, and we must be able to capture changes to them to avoid this being a manual, tedious work. A solution will of course need to handle this and keep track of every change and every baseline.

But several of our customers find that there will be other documentation structures, for example, a technical file that also have to be managed like the DHF and DMR, depending on which territory you are operating in. In a company the team are working on the design of a new respiratory ventilator. As you can imagine, developing such equipment is a very complex project and having full traceability of what was done by who, what was changed with what is crucial, not only for getting ventilators to the market faster, but also for getting the required approvals from the regulatory bodies. In this company project changes are not a nightmare anymore. Let’s see how Minerva PLM actually supports them. Today I am going into my project and start working on the patent filing for my ventilator project.

What I do is that I go to the project and I open it to go and find the deliverable matrix and identify where is my patent filing. When I open the project, I can see that many of my documents deliverables have not yet been created, and I can also see which product they are actually being, which product is being created by this development project.

And of course, these deliverables should then also be part of the DHF and all the DMR for this product. So if I open the product, I can see I have two tabs. I can open the Design History file tab, and in there I will see the automatically generated DHF for this ventilator. As I can see, I can see the project status of each of them.

And if I look at the patent filing, I can see that that is pending. It’s supposed to be done by September 4th, and it has not yet been created. If I now go back to my project, I can search for my patent filing. It will then search through my grid and I can see that interface concept is where I have it.

I see I have the line for the deliverable, but it has not yet been created. By clicking instantiate, the system will go in, fetch the template for the patent filing, and automatically create the document for me. As you can see now, this document has been created automatically from the template for the patent filing. If I look at the DHF in the project context, I can now see that the patent filing has been created.

The M3 and the DHF have the document related to it. If I go back to the part, I can see that on the DHF tab for the part. I also have the patent filing created. So automatically the DHF is updated based upon what I do inside of my project. This makes it much easier for me to make sure that everything is aligned and correct.