Blog

Aligned Elements is a Medical Device application lifecycle management (ALM) solution enabling fast development and regulatory compliance through improved Design History File management.

January 17 2021
Details
Category: Tips & Tricks

Since Covid-19 delayed the introduction of EU-MDR and EU-IVDR until 2021, many companies have been granted an unexpected reprieve from adhering to the changes to the Medical Device Directive (MDD). This extra time should enable many firms to more adequately prepare and rollout these changes in a more orderly fashion.

MDR may also finally compel device manufacturers to eschew their paper or MS Office based processes due to the necessary documentation needed to adhere.

The actual changes in regulations are not as drastic as first appearances may lead one to think, but they are more encompassing. At 174 pages for MDR and 157 for IVDR, the new regulatory documents are physically 3 times longer than the 60-page predecessor, MDD or the very thin 37 pages for IVDD, and have many more annexes than the former regulations.

That said, is it really such a huge difference for many companies?

Yes, yes, a thousand times yes!

For many companies the answer is simply “yes”. Many more medical devices will fall under the new regulations and necessary documentation required by MDR. For many midsized and smaller companies, this can be problematic. Larger device manufacturers have the infrastructure already in place to handle the additional QA/RA efforts needed. For those who were able to avoid regulatory control, MDR/IVDR will be a huge change and challenge.

Bigger and broader

The definition of “medical device” will now include many previously non-medical and cosmetic device. Devices used for sterilizing, disinfecting, and cleaning of devices – including epilation lasers and contact lenses, for example – will now be labeled as medical devices.

If that isn’t enough, many medical devices will move to a higher risk class and there will be a new classification for reusable surgical devices. IVD’s in particular will have a large increase in oversight and there will now be 4 risk classes and those will cover around 90% of those devices.

Previously only 10% were covered by risk classifications whereas with IVDR, the definition of an IVD has been expanded to include software and companion diagnostics.

Going forward, even laboratory devices, cleaning & sterilizing devices and instruments are covered by Class A, with Classes C &D handling life-threatening devices, with D being the highest risk classification. Class B will now be the “default group” covering lower risk devices such as cholesterol, pregnancy, fertility and other urine-based testing.

Safety, safety and more safety

There is also a much larger focus on “safety” – the word appears 290 times in MDR while it was only mentioned 40 times it the former MDD. To prove safety and performance claims, device manufacturers will have to create and maintain more in-depth clinical data than previously expected.

There will be a centralized EU portal that device manufacturers will be required to use when reporting their incidents, injuries and deaths. This will provide a bit more transparency in regards to safety related information for patients as they will now have access to this data for a longer time frame.

Not only initial risk is covered but also continuous, life span of the device risk has to be measured. In addition to increased focus on risk, the clinical effectiveness of the device must be documented.

Wider QMS coverage

What all of this means is that almost every medical device company will require a quality management system (QMS). And not just a QMS that complies to ISO 13485:2016, but one that includes post market surveillance for each device. The goal of this is to assist manufacturers in better understanding their device throughout its entire life cycle. What is also very import is that no products will be “grandfathered” which means you cannot simply reuse your CE info to get this done.

All devices – even those currently on the market – must conform the new IDVR standards. As a result, most companies’ Technical File (now called your Technical Documentation) will increase in size. As per EU regulators, your clinical evaluation (CE) Technical Documentation will include all technical information demonstrating how performance and safety are verified and validated by your risk assessment, manufacturing, PMS, design controls, etc.

Device manufacturers must also describe how to handle and document changes to the Technical Documentation in a formal procedure. There is no longer a distinction between a Technical File and a Design Dossier.

In the EU MDR Annex 1 replaces “Essential Requirements” with the now named “General Safety and Performance Requirements.” On the surface the requirements are quite similar, but they now also include requirements for active implantable devices, and bring forth the use of a benefit-risk-ratio.

Bigger documentation demands better tools

All of this additional information and documentation will create an all-encompassing technical library of your device. This means many companies should strongly consider abandoning the “paper / MS Office” and e-mail based processes in favor of software tools “built for purpose”.

Such artifact-based systems are better able to support the transparency, traceability and control needed to meet the new requirements of MDR/IVDR. Having the ability to link the additional safety analysis that is required to requirements, specifications, mitigations, verifications and validations in a very transparent and efficient manner will benefit both the device manufacturer and auditors.

Being able to find inconsistencies prior to an audit should always be your goal as this will save you time and money. If the change to the regulations due to MDR/IVDR is going to be smooth sailing for your company, you will need to be as confident as possible in your Technical Documentation.

By adopting an artifact based system that adheres to your process, the learning curve and other barriers to entry are lowered or completely eliminated. With software tools you can decrease costs, speed up development, lower testing time, decrease risks and have complete faith in the Technical Documentation you are producing.

Utilize the need to adopt MDR/IVDR as an opportunity to effect changes that modernize your processes.

This will enable you to start to work smarter instead of harder.

 

December 21 2020
Details
Category: Tips & Tricks

So you have realized that an Application Lifecycle Management software probably would make your medical device development more efficient?

Maybe you have experienced that your team:

  • spends a lot of time documenting Design Controls?
  • has difficulty to maintain the traceability for your product?
  • lacks confidence in your current technical file?

There are many good ALM tools out there so it should not to be too hard to pick one, right?

However, acquiring an ALM tool is a significant investment and you want to make sure that you pick one that addresses the particular challenges facing your team.

So where do you start?

Writing a Request for Proposal

A common starting point is to establish your organizations needs in a “Request for Proposal” document a.k.a. RFP. The RFP will be sent to a number of vendors and will help you 

This approach has several benefits. First of all, to explicitly spell out what the tool shall do for you will force you to concretize your needs. You shall also include other stakeholders to make sure you are informed about and address their concerns as well. This exercise will also reveal conflicting and ambiguous requirements which are always better to address sooner rather than later.

We recommend this RFP practice since it provides structure to the evaluation process. However, the RFP phase can sometimes lead to an “Analysis Paralysis” situation where an unproportionate effort is spent on establishing the “complete” RFP. Sometimes this is caused by incorporating too many stakeholders in the process, conflicting visions or needs or simply as a fear of failure when making a significant investment. Worst case, the RFP process can drag on for months, swell uncontrollably in size and, in the end, cost much more than the tool itself.     

We recommend you prioritizing the core needs that initially triggered the evaluation. Keep the RPF short and concise!

For a medical device ALM, this RFP should at least include requirements for:

  • Requirement Management
  • Establishing Traceability
  • Risk Analysis capabilities
  • Management of Verification & Validation activities
  • Proper versioning of Documentation and Artifacts
  • Establish reports that satisfies standards like ISO 13485 and ISO 14971
  • An automatic Audit Trail of all changes
  • Enable you to fulfil your Quality Management System

(We consider these the minimum features required for compliant medical device development).

Since we operate within the medical device scope, 21 CFR Part 11 Electronic Records (most of the artifacts in an ALM!) and Electronic Signatures (depending on how you implement the sign-off in your organisation) shall be addressed by the ALM. This will generate a number of requirements here summarized as:

  • 21 CFR Part 11 Ready (note that a tool in itself can never be 21 CFR Part 11 compliant. Final compliance always depends on processes within the organization)

As always, remember to make sure the requirements are testable.

Testability equals CSV

In our line of business, a Computer Software Validation, CSV, (more on that here) will eventually be used to validate the ALM. The RFP can provide a valuable input to this activity and you should be able to derive your CSV User Requirements from your RFP.

Even though low CSV efforts may not be a formal requirement in itself, the CSV activity will definitely be a cost driver that should have an impact on your purchasing decision. In some cases, the CSV cost can surpass the cost of the tool itself.

The CSV effort is typically driven by:

  • The complexity of your QMS (e.g., number of Design Item types, number of different relationships between design items as well as number of SOPs to test in the validation).
  • The complexity of your CSV process (the rigorousness and granularity required)
  • Approach to tailor the tool itself a.k.a. customizable or configurable.

Finding out the vendors tailoring approach must definitely be part of the RFP. Do not forget to consider required integrations between the ALM and external tools. Integrations are notorious for requiring additional programming efforts.

If the tool has to be scripted / programmed to tailor it to your organization, the system falls into the CSV category “customizable“ for which the validation efforts for a system is expected to be higher (including deeper testing, managing risks, code reviews etc).   

A configurable ALM is therefore preferable since:

  • The initial tailoring cost are lower
  • The initial and subsequent CSV costs are lower
  • Customization may impact the compatibility with future ALM releases and forward compatibility
  • Administrating the tailoring over time will require specialized personnel

Require the ALM to fit with your Quality Management System

Your QMS, development processes and templates have been carefully developed to specifically address your company’s unique situation. Compromising your QMS may have significant effects on compliance and efficiency.

Some ALM  tools are pre-configured and you are required to make substantial changes to your QMS in order to fully utilize its potential. Unless you are considering to rewrite your QMS for other reasons, we would discourage you from doing too big changes to an existing QMS since it may affect existing certifications and jeopardize compliance.

Another option to bridge the difference between the QMS and the ALM to set up processes and documentation that translates/map between the tool and your QMS. However, operations that require manual mapping as described are notoriously error prone and subjects your technical files to an increased risk of errors and inconsistencies.

Instead, the ALM should ideally adapt to your QMS, reflect your processes, use your templates and present your terms and notions in the GUI. This will lead to a higher level of acceptance, lower the learning curve, speed up the tool adoption process and reduce the risk of errors. For these reasons, we at Aligned always strive to make the tool follow the QMS.

The impact on your QMS should ideally not be more that an additional work instruction/SOP, stating that an ALM is used to fulfil certain activities defined by QMS. This work instruction/SOP will be a valuable input to your CSV activities.

To get you started, we have put together an example RFP spreadsheet. Download it here: Medical Device ALM Request for Proposal Template.xls

One Tool to Rule Them All or a Landscape of Tools?

What is the required scope of your ALM? This is a very common question often discussed in terms of cost. Intuitively, one IT tool must be cheaper to maintain than multiple tools, right?

A large tool spanning many areas of activity may have the benefit of providing integration, but from experience, dedicated tools usually are really good at what they do and definitely have their eligibility as well. Within a large organisation there will be tool boundaries. This fact may even simplify the introduction of an ALM tool and lower any business risk if you aim at building a working tool landscape rather than replacing at once.

The consideration of integrating with other tools can also be part of the RFP. We recommend however to keep the priorities right between core functionality and ‘nice to have’s’. The need to integrate different tools may be fulfilled over time.

Go through your RFP again and check if tools already existing in your organisation may already fulfil your requirements and adjust any priorities accordingly.

Next Step, gather Hands-on Experience!

Your RFP is not going to get you answer all your questions. Now it is time to experience the tool first hand. This is a crucial step in your evaluation. Most vendors will affirm every one of your requirements but you will quickly realize that the “how” is more important than the “what”.

Ask if you can access and evaluate the tool yourself. The vendor’s response will give you some important indications. Do they trust the ALM to be self-explanatory or will they require you to take a training?

At this point, there are a few points on what to expect from the vendor:

  • You shouldn’t need to buy any infrastructure to install and run the evaluation version.
  • The evaluation should not require a significant time investment on your part
  • Any training and/or customization cost for the evaluation shall be minimal

Try to account for the subjective impression from the hands-on experience in your evaluation. They will be an important factor to embracing the tool within your organisation.   

Estimating the total cost

To prepare for the last step, it is time to request quotes from your vendors. Make sure these quotes include all cost-driving factors through-out the ALM’s lifecycle to accurately facilitate comparison between vendors.

An accurate life-time cost estimation shall include:

  • Cost of Licenses
  • Cost of Service and Support (find out what is included)
  • Cost of configuration/customizing (how long until the system can be used?)
  • Cost of training
  • Cost of CSV activities
  • Cost of import/transfer of legacy data into the ALM
  • Cost of IT Infrastructure (include cloud costs, software licenses for OS, databases etc.)

Lifetime costs will inevitably arise from maintaining the tool:

  • Is the tool so complex to administrate that we need to build an internal team (or optionally buy this service from the vendor or 3rd party service provider) covering this new expertise?
  • Or you can rely on the vendor (ideally this is already part of the support agreement) for maintenance

Wrapping up the evaluation

Having the input from the RFP and the hands-on experience, you can now hopefully make a well-informed decision based on the capabilities of the ALM. You have gathered knowledge about how to make the tool will fit in your organisation and IT landscape.

At this stage, as a note of caution: a given tool will not solve all your problems. Tools do speeds up processes, provide structure and checks but in essence they rely on improving something that already works.

To summarize the points:

  1. Formulate an RFP, focused on medical device development
  2. Plan ahead for CSV
  3. Check for fit with your QMS
  4. Gain hands-on experience
  5. Establish total lifetime cost

Best of luck with your evaluation!

 

December 11 2020
Details
Category: Product News

 

Have you ever struggled to describe Hazardous Situations so it was clear to all stakeholders what you intended to say?

Did you spend a lot of time to come up with concisely written Sequence of Events and then the first person to review your document claims to not understand what you intended to convey?

When describing your harms, have you ever wished that someone had put together a list of all possible harms, so you could just pick the one, which is applicable for this particular situation?

And then after your product release, did a Risk occur that you did not foresee?

Common Terminology by curtesy of the IMDRF

If you have ever experienced one or more of the above, there might be some help out there. The International Medical Device Regulators Forum (http://www.imdrf.org) has created a document called IMDRF terminologies for categorized Adverse Event Reporting (AER): terms, terminology structure and codes.

Although that is quite a mouthful, this document can make your life a lot easier. It provides an extensive list of possible medical device problems, possible harms and related causes. Each term is assigned a code, which have to used when creating a Manufacturer Incident Report as required by the MDR (https://ec.europa.eu/docsroom/documents/41681).

These codes can also be used when reporting Adverse Events to the FDA by means of a Medical Device Report (https://www.fda.gov/medical-devices/mandatory-reporting-requirements-manufacturers-importers-and-device-user-facilities/mdr-adverse-event-codes).

Is the terminology only applicable for post-market events?

Although the terms compiled by the IMDRF have a strong focus on Post Market incidents, they are also useful in your pre-market design risk assessments. When performing your ISO 14971 compliant Risk Analysis during the development phase, a lot of time is (and should be) spent on the risk identification process to make sure all potential risks have been assessed and addressed.

In practice, this requires writing down and assess the hazardous situations, what causes and subsequent harms that could possibly arise by using your product. However, these are essentially the same as in a post market scenario. Using the lists provided by IMDRF can speed up this process significantly.

So how does this make things easier for me?

The IMDRF lists act as an acceleration vehicle for your Risk Analysis. By using and analysing these established terms, you will save a significant amount of time when documenting all possible hazardous situations, causes and harms. At the same time the likelihood of overlooking a particular hazardous situation, cause or harm is greatly reduced.

Furthermore, ambiguities are reduced by using and referring to an established set of risk terminologies. Thus, you reduce the risk that other stakeholders, not just your colleagues, but also the auditors, will not misunderstand your carefully constructed Risk Analysis.

Using the IMDRF terminology in Aligned Elements

The lists are applicable to Aligned Elements projects using Risk Assessments using the Preliminary Hazard Analysis method. 

It is possible to import the IMDRF items directly into Aligned Elements by using four import packages which you can download here.

The extension consists of lists containing a Design Control type called “IMDRF Item”, which have the attributes “Code” and “Definition”.

When importing them, you will need to map the types to types that exist in your configuration.

Note that the lists contains a large number of items which may not all be applicable to your particular device.

A pre-assessment step of the list content is therefore recommended before applying them into production projects.

The following mappings should be done.

  • “Annex A, Medical Device Problems” (469 items) should be mapped to a type which represents “Potential Hazards” in your configuration.
  • “Annex D, Investigation Conclusions” (35 items) should be mapped to a type which represents “Causes” in your configuration.
  • “Annex E, Health Effects - Clinical Signs and Symptoms or Conditions” (797 items) should be mapped to a type which represents “Harms” in your configuration.
  • “Annex F, Health Effects - Health Impacts” (64 items) should be mapped to a type which represents “Harms” in your configuration.


Please do not hesitate to ask for assistance at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

 

November 27 2020
Details
Category: Tips & Tricks

Some of our most popular blog posts have involved discussions with Christian Kaestner, co-author of IEC 62304 and IEC 82304. He has brought us great insights on the underlying ideas of the people writing these standards and the standards' implications and interpretation throughout the industry.

You can tap into Mr. Kaestner's knowledge in his online course on medical device software and IEC 62304 in collaboration with Medical Device HQ

The full course is found here and a free short version is YouTube.

Once again, we have been fortunate enough to get a few minutes with Mr. Kaestner, who in this post elaborates on the current state of IEC 62304, 14 years after its initial release.

Q: With your extensive experience of both writing the standard and seeing how it has been used by the industry, how do today’s modern software companies approach and implement IEC 62304? Has IEC 62304 successfully stood the test of time? 

A: Well, both yes and no. Yes, because after almost 15 years the standard is now well known and established in the field. No, because the software environment has changed a lot since its first release in 2006. For example, the way we today use apps, cloud-based solutions, and AI, not to mention security aspects and the shift towards using Agile methods for software development! 

Q: Can we expect this to be covered by the upcoming edition 2? 

A: No, not really. I would say the main goal for edition 2 is to align better with IEC 82304-1, which is a product standard for health software (including medical device software). The scope of IEC 62304 edition 2 will be broadened from medical device software to health software.

This expansion has provided some challenges such as ISO 14971 for risk management is currently a normative reference, which means you must comply with also ISO 14971 to comply with IEC 62304. This cannot be required for general health software developers while risk management still is a vital part of a medical device software development process!          

Q: Many medical device software developers want to work Agile but find it difficult when reading IEC 62304, do you have any suggestions? 

A: It is no secret that the standard is written very sequentially and implies a classical V-model approach, but you are free to work in any way you want! If you struggle with implementing the standard, I suggest you consider the standard as a list of requirements that you have to fulfil but you can disregard the order in which they are written.

For example, there is a requirement to “Verify software requirements” but if you find it appropriate, you can do this as part of your software release. I will not say that it is formally incorrect, but I would argue it is a risky approach since late discoveries during the verification might generate a lot of re-work.

Likewise, if you use Scrum, it might be appropriate to include the activity “Verify software requirements” in for example sprint planning and verify the requirements contained in a sprint. You could even consider verifying software requirements on a story-based level!  

 

 

Figure 1: Incremental approach to verification of software requirements  

 

Q: The IEC 62304 Software Safety Classification seems to be the most contested part of the standard.  Is the industry using the Software Safety Classification the way it was intended according to you? Are there any aspects of it that you feel should receive more attention? 

A: Interesting questions indeed… There have been many discussions the past years whether Software Safety Classification is needed or not. Some argue that Class C software development is the current state-of-the-art, and anything less than that is simply not acceptable these days. Still, Software Safety Classification will survive and remain in edition 2 (with some editorial changes).

Personally, I like the risk-based approach for two reasons; firstly, it increases the likelihood for low-risk software devices to enter the market which otherwise would have been too expensive and not make it to the market. Secondly, it increases the awareness of what parts in your software that can be dangerous.  

Q: Can you elaborate a bit more about your second point about awareness? 

A: Early awareness of what can become harmful is a super valuable input to the architectural design because with this information at hand, you can separate risky and non-risk functionality into different items. If this is done correctly, you can assign the appropriate classification to items and concentrate your safety efforts where it makes the most sense! And this is the essence of IEC 62304: focus your efforts on the risky parts! 

Figure 2: Items in a software system can be classified differently 

 

A final point on Software Safety Classification: note that the concept is based on injury, not harm as in ISO 14971. Harm is a much broader concept than injury and includes damage to property and environment which strictly speaking does not need to be considered when determining a Software Safety Classification.  

Q: The IEC 62304 Problem Resolution chapter has received some heat regarding the (at least perceived) overly cumbersome approach. Do you think there is any substance to these claims? Are there any best practices for how to best tackle the Problem Resolution requirements of the standard?  

A: Yes, the Problem Resolution is a bit strange to follow in the standard. Throughout the standard, there are requirements to use a “problem resolution process”.

However, in most cases, it does not make sense to use such a process as it is defined by clause 9 “Software problem resolution process”. For example, if a bug is discovered during system test and the software is still not on the market, it does not make sense to “advice relevant parties”! 

My approach to this is to use a scalable process and use different approaches depending on whether the problem relates to released functionality or not. Where a problem relates to a released functionality, regardless of found internally (“Internal feedback”) or externally (“Feedback”), then all parts of clause 9 apply.

For all other problems, I use selected parts of clause 9 and work with a generic software problem resolution process. 

 Figure 3: An approach to manage a software problem resolution process 

 

About Christian Kaestner 

Christian has recently released an online course about medical device software and IEC 62304 in collaboration with Medical Device HQ. The full course can be found here, and if you are interested in a free short version, you can find it here on YouTube. 

Christian Kaestner is a freelance software medical device consultant who often works in close collaboration with QAdvis AB in Sweden. He is a member of the project team authoring IEC 62304 and was also part of the project team developing IEC 82304-1. 

November 12 2020
Details
Category: Product News

Risk Identification is an early and essential part of the risk management process and ISO 14971 requires us to make a complete risk assessment, to identify ALL hazards. 

But, how do we know if all of the hazards have been identified? How can we prove this?

You could brainstorm or have a white board session gathering ideas that pop up, but the only way to truly achieve confidence in your risk identification process is by using a structured approach. 

There are several techniques available depending on the assessed source, including:

  • Assessing established potential hazards from internal records or published standards
  • Analysis of the manufacturer's experience with similar medical devices
  • Conducting a User Task Analysis on the user’s interaction with the device to uncover use errors
  • Assessing Field data and published incidents from similar devices in use
  • Assessing critical components for safe an effective use

Because of the difficulty involved with thoroughly identifying all of the hazards, ISO 14971 provides a number of aides – such as Annex C (2012) (becoming the ISO 24791 Annex A in the 2019 edition) – which provide a list of questions to assist in establishing device characteristics that may impact safety. Although not exhaustive, these question can serve as starting point and become of one of several potential approaches from which the complete risk identification can be assembled. 

Aligned Elements users can kick start their risk identification process by downloading and importing our ISO 14971:2012 Annex C Extension, assessing them and start generating risks and mitigation. 

The ISO 14971:2012 Annex C Extension contains:

  • RVT file for an ISO 14971 Annex C Question and a corresponding DOCX Reporting style template
  • 37 importable questions built on Annex C in ISO 14971 to assess and integrate in your Risk Assessment

This Extension facilitates the assessment of the questions, the creation of both an automated assessment report of the Annex C questions as well as a starting point for generating new risks and mitigation. 

It gives medical device manufacturers a predefined starting point when setting up their technical file with the intention of accelerating the documentation effort.

The user is of course welcome to expand this question list with questions that are particular for his/her device and the conditions under which it needs to operate.  

The ISO 14971:2012 package can be combined with other risk identification packages from Aligned or in-house developed approaches by the manufacturer.

The ISO 14971:2012 Annex C package is free to Aligned Elements users.

For more information on how you can include our ISO 14971 questions in your risk assessment, contact the This email address is being protected from spambots. You need JavaScript enabled to view it. today. 

googleplus facebook