Aligned Element have made life easy working with requirement/verification including traceability. We could easily make a structure suitable for us, for all our different products and their specifications.
Amazing to see how adaptable AE is to our development process and risk management process, giving us the ability to work swiftly without any unnecessary constraints!
If you want to check how well your QMS complies with ISO 13485, you can use this Aligned Elements Extension in your Aligned Elements instance.
In an auditing situation, you might be required to demonstrate how you comply to this standard.
The Extension consists of:
Use this checklist to get a properly controlled and document proof of your compliance with ISO 13485.
If you develop software for a medical device then you have hopefully aligned your processes with IEC 62304 - Medical Device Software
In an auditing situation, you might be required to demonstrate how you comply to this standard.
Our IEC 62304 Checklist is integrated in Aligned Elements and lets you perform the assessment inside AE, taking advantage of inconsistency rules, tracing to existing project documents as objective evidence and simple export to word once completed.
The checklist includes 93 prepared audit questions based on the requirements in IEC 62304.
This is a simple and efficient way to demonstrate your company and software's compliance with the standard.
{fastsocialshare}
If you plan to develop and sell a medical device on the European Market, complying with the MDR (European Union Medical Device Regulation (EU MDR 2017/745)) is mandatory.
A cornerstone of this regulation is to write and maintain the required technical documentation, often referred to as the Technical File. Getting your Technical File complete, correct and consistent is an essential step of the conformity assessment procedure.
When completed, you will submit the Technical File to your Notified Body, If the Notified Body is satisfied, your product will receive the CE mark necessary for selling the medical device in the EU market.
This guide provides an in-depth look at the essential elements of the Technical File, helping you ensure compliance, achieve CE marking, and bring safe, effective devices to market.
The Technical File consists of a number of documents. Exactly which documents to include is partly mandatory (e.g. demonstrating conformity to Annex I of MDR) and partly up to the manufacturer. The areas the documents need to address are mandatory and outlined in Annex II of MDR.
In essence, the documentation describes your device, what it is made for (its intended use), how it is designed and manufactured, how you have made sure that it is safe and how you intend to make sure that it is safe in the future, taking into account changes you make but also post-market surveillance data from the market.
The underlying reason for having to compile and submit this documentation is that its content constitutes the proof that the medical device is safe for its intended use and effectively fulfills its purpose for patients and users.
Let’s be honest. Compiling a Technical File a considerable task. However, if it makes you feel better, many companies, like your own, has successfully done this in the past and so will you.
You will notice that some requirements on the Technical File are very concrete (or at least appear to be very concrete) whereas other requirements are less firm and leaves a lot of latitude to the manufacturer. There also tends to be a continuously ongoing debate in the industry on how to best fulfill some of the more nebulous requirements.
Therefore, first make sure that you have a copy of the MDR text including the Annexes readily available. Then, please (!), take some time to read it through (suggested read order?) (I am sorry but you really have to read it).
Note that the MDR requires you to not only compile and submit your technical documentation prior to launching a product. Be aware of thar the technical file must be kept up to date by the manufacturer (you) and is part of the documentation obligations even after the product has been placed on the market.
Furthermore, you have make the documentation accessible to market surveillance authorities upon request once the device is available on the market. You must be able to make the technical documentation available to the competent authorities for at least 10 years after a device has been placed on the market. For implants, this minimum period is extended to 15 years.
Last but not least , if a competent authority checks whether an assessment by a notified body has been carried out properly, this also includes the technical documentation of a medical device i.e. they might want to take a look at your Technical File. In addition, a Member State in which a Notified Body is established may also require that technical documentation is provided.
One person in your organization will be appointed responsible for keeping the Technical File up to date. This Person responsible for regulatory compliance (PRRC) is responsible for ensuring that the technical documentation and the EU declaration of conformity are correct, complete, consistent and kept up to date.
According to the MDR, you (the manufacturer) must set up a surveillance system for monitoring the medical device after it has been placed on the market. The collected post-market data serves as a basis for the ongoing updating of the technical documentation.
Bottomline: a Technical File is not completed upon submission. The Technical File needs to be actively maintained for years to come and you must be prepared to show it upon a valid request. Therefore, your goal should not only be to prepare your Technical File for submission but also take active measures to make sure that it is easy to maintain.
Everything OK so far? Then it is time to decide how to organize the Technical File. This takes us to the sensitive matter the Technical File structure. The Annex II of the EU MDR prescribes a number of Technical File sections. Annex II therefore prescribes both mandatory content parts but also the structure/order in which a Notified Body expect these to appear in your Technical File.
Note that the Annex does not necessarily prescribes concrete documents. Rather, it prescribe information sections. It is up to you to decide how you package these information sections into documents. You should, though, adhere to the structure of Annex II.
You will also notice that the information structure in Annex II does not chronologically align with the development cycle of a medical device. E.g. the Instructions for Use (IFU) is listed very early in the structure but can obviously not be compiled until very late in the development cycle. Thus, the structure of the Technical File does not correspond to the chronological creation time of the information and documents that constitute it.
Many of the documents in the Technical File are resulting from your development process and I suggest that you create these documents in the order that is prescribed by your development process but make sure that they are ordered in the structure mandated by Annex II and Annex III b.
Many notified bodies explicitly require you to use their Technical File structure. This makes their review work easier. These structures are expansions on the mandatory Annex II and Annex III b structure. If you have a Notified Body, ask them if they require a structure and if yes, use that structure.
There is a strict requirement in MDR that technical documentation should be prepared in a “clear, organized, readily searchable, and unambiguous manner”. This can of course mean many different things.
You Quality Management System already has a Document Management SOP. Use this for your technical documentation as well, such as:
Regarding document formats, clearer input is sometimes issued by Notified Bodies themselves. BSI, for example, gives helpful input on what they expect from a concrete documentation format perspective, such as:
(MDR Readiness Review (bsigroup.com))
According to Annex II your Technical File should be structured into the following sections:
This section states overall important key facts about your device. As previously mentioned, it is not clear if this is a single document or several documents. It is up to you to decide.
Although this section concerns various kinds of “printed” information, there is not always a great deal of commonality between the subsections. Also note that the content for this section tends to mature fairly late in the development cycle.
Again, four very different points, although all concretely related to the product itself. This is one of the bulkier sections of the Technical Documentation where you will spend a lot of time.
This information is, as mentioned, often collected in a single document, namely the GSPR checklist. You should start addressing this section early during the development in order to identify which documents you need to produce in order to complete this checklist. Note that the documents that constitute the evidence of compliance can in some cases be available only fairly late during the documentation process. It is not uncommon that this document is worked on continuously right to the moment before submission.
Risk management activities accompanies the development process during the entire product development cycle (as well as after the release of the product).
V&V activities tend to be very rich in output. Our experience shows that V&V related documentation constitute up to 50% of the entire technical documentation volume. It is also one of the documentation sections that are the last to be finalized before submission. Therefore, plan what you can. Note that verification and validation is much more than just the actual testing.
Plan carefully how many instances of your instruments you will need for testing, which instances that can be used in parallel, which additional equipment you need for testing. Make sure that you make early reservations at any accredited labs. Nothing is more annoying than having a product that is ready but all testing labs are suddenly booked out.
It might seem daunting to plan for the collection of post-market data for a device that do not yet exist. Still, it has to be done.
GSPR stands for General Safety and performance requirements. The are listed in Annex I of MDR. A part of your Technical File is to demonstrate how your medical device and your organization satisfies the mandatory GSPR requirements.
The GSPR’s are structured into the following four sections:
The GSPR’s are a fairly heterogenous set of requirements where some are very specific and others are much more high-level. Some of them are related to the product and others are more process related.
I strongly recommend that you make yourself acquainted with the GSPR’s early in the development process. This will make it easier to plan and foresee your way to completion.
The absolute standard way to demonstrate conformity with the GSPR requirements is through a checklist. The checklist ideally has the following columns:
Note that if a requirement applies, you do not need to justify why.
However, if it does not apply, you must clearly state why with a full and proper justification. For example: ‘The device is not an active device since it is not powered. This requirement does not apply.'
Try to avoid insufficient detail. You should make sure that all sections of the Technical File are thoroughly documented with supporting evidence available.
Provide comprehensive evidence. Make sure that complete test reports, certificates, and validation results are available rather than summaries.
Use consistent language, numbering and identification schemas. Check for consistency across all documents, avoiding contradictions or outdated information.
Conduct structured risk assessment in order to achieve exhaustive risk elicitations, considering all potential hazards, including those related to cybersecurity and data protection.
Implement effective risk control measures and verify their effectiveness. This can sometimes be both difficult and daunting but it needs to be done.
Fully document all risk management activities, including rationales for accepting residual risks.
Do not ignore feedback. Feedback is the best way for you to not only monitoring the safety of your product but also an invaluable source of information to make sour product better. Actively collect and analyze feedback from users and implement improvements to make the product better and safer.
Do not delayed your PMS updates. Regularly update PMS and PMCF plans and reports, integrating findings into risk management and clinical evaluation. To do this properly requires plenty of resources so make sure you plan accordingly.
Non-Compliance with Vigilance. Sooner or later it can happen to you. Train for the event of a vigilance case in order to ensure timely reporting if an incident occurs.
Preparing a thorough Technical File in line with the EU MDR is more than just a regulatory box to check—it's a critical step that directly impacts the safety and effectiveness of your medical device. By doing this right, you're not just ensuring compliance; you're building trust with your users and stakeholders.
When you compile and maintain your technical documentation, you’re showing a commitment to the highest standards of quality and patient safety. This isn’t just about meeting a requirement; it’s about positioning yourself for success in the EU medical device market, where quality is everything.
Meeting the EU MDR’s rigorous standards sets you apart from the competition. It shows the market that your company is serious about excellence and compliance. Think of it as an investment—not only in regulatory approval but in the long-term success and reputation of your business.
{fastsocialshare}
When developing according to IEC 62304, you are required to document your Software Architecture. One of the best ways to do just that is to use UM or SYSML. And one of the most widely used tools to document this kind of modelling is Enterprise Architect by Sparx Systems.
Integrating these design artefacts in your Aligned Elements traceability can now be done using the interface Aligned Elements - Enterprise Architect to access all your UML diagrams from within Aligned Elements.
This will enable you to:
A few technical details:
If you are interested in adding the Enterprise Architect Integration to your Aligned Elements project, contact us at
{fastsocialshare}
Many development teams have good tooling in place to organise the daily work. My personal favourite hub for information is a good solid issue tracking system. The simpler the system the better!
With an issue tracking system you can easily track:
An “issue” can be created for several reasons: to capture a work task, track a bug, take down to-do’s, or just set up a reminder. The common denominator is to organize your work in a team environment.
In a modern era, using an issue tracking system is a cornerstone of efficient software development and is today considered state-of-the-art. Most issue tracking systems facilitate searching, sorting, listing, querying, assigning, and tracking issues for optimal teamwork and efficiency. Nowadays, many hardware designers have of course also learned to appreciate these useful tools.
Now, as good as these tools are to manage and organise work when it comes to maintaining a formal Medical Device technical documentation / Design Control documentation, they lack quite a bit of structural guidance.
Watch out for the following misuse-of-issue-tracking-system-smells:
The obvious reason for the points above is that issue tracking systems have been developed for a particular reason, namely organizing and following up on tasks.
I bet you are not using Excel to write legal contracts or letters. Likewise, you are hopefully not using Word for calculating a budget.
Each software has been built for a particular purpose and if your purpose is Design Control Management for Medical Device Technical Documentation, there are other and better tools available.
This does not mean that you have to give up your Issue tracking software. Instead, integrate it in a powerful tool-chain.
We, at Aligned AG, recommend you to keep your existing Issue tracking software and integrate it with Aligned Elements for optimal value creation. In most DevOps tool-chains, the Issue tracking system acts as the spider in the net and is crucial for efficient software team collaboration.
Moreover, issue tracking systems are usually well integrated with other development activities such as:
To structure your documentation, on the other hand, we are convinced that a purpose-built tool like Aligned Elements will help you reach your goal faster and more efficiently. Regulations such as MDR, IVDR, or the QSR require a formal development process. You shall describe the structure dictated by the development process in your Quality Management System, but to convey this structure properly, the team needs to be thoroughly guided.
The expected result after a long project needs to be clearly stated at the beginning of your development journey! (i.e., do NOT use a Wiki!).
Our obvious choice for this is of course Aligned Elements.
For maximal gains, integrate Aligned Elements with your issue management system of choice.
In Aligned Elements, we support live connections to a growing list of the most popular issue tracking systems.
This allows you to create and modify Issues directly from Aligned Elements and trace from any:
directly to issues in the issue tracking system of choice.
The traces will be part of your Aligned Elements traceability monitoring and reporting. Aligned Elements even sets a source Aligned Elements hyper-link in the target issue automatically in order to designate the Aligned Elements tracing to it. The issue data is kept in the issue manager only and Aligned Elements keeps a live link to that data. There is no need for error-prone synchronization between the systems.
Execute test cases in Aligned Elements but create software bug reports in your issue tracking system without having to leave the Aligned Elements context.
Generate agile artefacts like User Stories or Epics in your issue tracking software directly from Aligned Elements with traces being set automatically.
Lever Aligned Elements consistency checks, query capabilities, and powerful word reporting features on the issues in your issue tracking system.
Please contact us at
{fastsocialshare}
Compliant and Efficient Medical Device DevelopmentAn impossible combination?
Join us to gather concrete and practical advice on how to meet trending medical device development challenges in 2017.
We have called on a group of experienced industry experts to share their latest best practices on how to eliminate problems with you.
We look forward to seeing you at this event. If you have any questions or information requests, please don't hesitate to
What does the new EU MDR have in store for you? The 566 pages of the MDR contain a number of important changes for the medical device industry. Meet the challenges in time and in the right order.
Hansjörg Riedwyl, CEO | ISS AG
Test documentation takes up more than 50% of the total Design History File / Technical File. Time which could be better spent. Imagine 100% regression tests in a single day, for every release. Can it be made possible? Learn more in this session.
Tobias Müller, Managing Director | Progile GmbH
Regulatory requirements on clinical evaluation data have risen considerably during recent years. What are the best (and worst) practices in writing and updating state-of-the-art medical device CER:s?
Dr. Bruno Walter, Managing Director | Medical Minds
E-signatures boost document release efficiency according to business experts. Medical device development involves an awful lot of documents. So why should not everyone use e-signatures?
Karl Larsson, Medical Device Documentation Expert | Aligned AG
Presentations are held in german. Slides are written in English.
This event is aimed at medical device development professionals, project managers, QARA professionals, R&D personnel, and other industry professionals engaged in medical device development.
We are looking forward to seeing you at this seminar!
Registration Fee: 125 CHF
30% early bird discount for registration before May 10th
Adress: Hotel Marriott Courtyard, Max-Bill-Platz 19, 8050 Zürich
Aligned AG provides Aligned Elements, a Medical Device ALM system that accelerates and ensures compliant Design Control documentation for medical devices. We assist our clients in developing regulatory compliant products within shorter time-frames, to lower costs and with higher confidence.
{fastsocialshare}
Documenting the design controls for a medical device is a mandatory exercise in our industry. Regulations describe what the documentation must show. Standards describe harmonized ways in which regulations can be fulfilled. Your quality management system should, in the best case, describe which process you need to follow in order to satisfy the standards and regulations, and finally, your company templates are what you use to finally pen it down.
However, regardless of the multitude of support systems, at the end of the day some of us given the task to provide a document, will sit down in front of the computer and think:
But what exactly should I write?
Here is where we can help. The Aligned Elements Extension section contains more than 50 importable plug-and-play content packages that can help you accelerate the documentation process by leaning on collected experiences and best practices. Our extensions exemplify how Aligned Elements can be used to solve ubiquitous medical device documentation problems.
These extensions contain things like:
To make this even better: all extensions on our website are free to our customers.
Today, we added a new package of 120 Infusion Pump requirements exemplifying the Design Input for an Infusion Pump device. Let us help you. If you have questions about our extensions, please
{fastsocialshare}
Not long ago I sat down and had a really good talk with Ilari Henrik Aegerter from House Of Test. Ilari has an extensive background in high-quality testing and is one of the leading opinion makers in the area of context-driven testing. Ilari is also a strong advocate of Exploratory Testing and I challenged him to explain how Exploratory Testing could fit into the world of strict and regulated medical device development.
"One way of thinking about testing is value creation. Value is created by increasing the knowledge about the system.” starts Ilari, “Through testing, you gather information about your system’s desirable and undesirable behavior. Now, some testing methodologies accomplish this more efficiently than others.”
"In traditional, scripted testing, the task is to verify that the system behaves according to a formally specified input, a.k.a "confirmatory checking". I see this approach a lot in the medical device industry, often accompanied by extensive documentation, meticulously describing the input and output.”
“The drawback of this approach is that it only traverses a very narrow path of the system. The generated results is equally meager when it comes to unveiling previously unknown knowledge about the system. It also abstains from tapping into the creativity and system expertise of the tester.
Let me make this clearer with an illustration.”
“This diagram describes a medical device. As you can see, we have three ways of looking at the product:
In the ideal case, a medical device is characterized by a perfect intersection between all three areas.
Now, let's evaluate what happens when this is not the case.
"Specified but not implemented" - This area translates to turn up as failed tests in the medical device documentation, something that becomes accentuated in companies that focus on verifying formal specifications. Not uncommon in the medical device industry.
"Implemented and specified but not covered by User Needs" - Sometimes called "Gold Plating". From a scripted test perspective, this area is going to transform into passed test cases. One might question the value of implementing things that the Users don't need, but there might exist business reasons that explain this area.
"Implementation and User Needs intersect but are not covered by Specifications" - This is the result of an experienced developer who knows what the User Needs even though it is not specified. Unfortunately, this part is not going to be covered by the formal verification so we can only hope that the implementation actually works.
Finally, the most important area is represented by the "unmet User needs". This area is going to come back as bugs and change requests in the post-market phase. Despite having done the things right, we have apparently failed to do the right things. Some of these user needs might have been explicitly left out for cost reasons or with the intention to be implemented later. However, the critical part consists of the "things we didn't think about".
And voila, here is where exploratory testing can make a big difference. By applying a broader testing mindset, not being constrained by the narrow path of formal specifications, wider test coverage is reached and more knowledge is obtained about the system. More knowledge is more value. The best part is that studies have shown that exploratory testing is much more efficient in finding bugs per time unit compared to traditional testing."
At this point, I asked Ilari if these unmet User Needs would not be uncovered during the Design Validation? Wasn't this exactly the objective of validation, to check that we have done the right things?
"Partly", says Ilari, "the notions are related but not the same."
“In recent years, we have seen an increased focus on usability and human factor engineering in medical device development. We have also seen an increased regulatory focus on performing proper validation for each new release. The whole point of these disciplines is to engage the user's perspective since the user probably knows more about the final usage than the manufacturer. Usability and human factor engineering are valuable tools to emphasize, charter, and corroborate user needs in the design process.
Exploratory testing is focusing on similar issues. It leverages the creative and critical thinking of the tester, mimicking the thought process of a user. It challenges the tester as a domain expert and explicitly attempts to uncover tacit and unspecified needs."
I was still skeptical. "But, Ilari, we still need to be compliant with the FDA. We still have to show that the specifications are met and we still need to have documented proof. Exploratory testing makes a big point how traditional, scripted testing is obsessing about repeatability and documentation, indicating that these are not important steps."
"That is not true.", Ilari responds, "I think this is a misconception about exploratory testing, i.e. that it does not test specifications and does not produce documented evidence. Of course, exploratory tests are documented. It's just that it might not use the same level of detail and that it better highlights undesired behavior, instead of only focusing on meticulously writing down everything that works as specified.”
“My opinion is that exploratory testing generates more knowledge about the system. This is particularly valuable during the early development stages. If you have worked in the industry, you know exactly what I am talking about. At this stage, the specs are constantly changing, the device is continuously modified, a lot of factors have not yet stabilized and it is simply not efficient to start writing formalized test scripts at this point. During this phase, exploratory testing is the superior testing method for generating knowledge about the current system state.”
“This idea is partly reflected in the FDA document “Design Considerations for Pivotal Clinical Investigations for Medical Devices - Guidance for Industry, Clinical Investigators, Institutional Review Boards, and Food and Drug Administration Staff”. The document states that exploratory studies in the early, and even pivotal stage of clinical investigations, is advantageous, simply because it generates more knowledge about the system. In this line of thought, exploratory testing does not replace scripted testing, but certainly precedes and complements it.”
I must say that Ilari is building a case here. We leave the discussion at this point, both excited about the prospects and challenges of exploratory testing in a medical device context.
