December 12 2014

It is not hard to guess that Mobile Medical Applications (MMA:s) are going to be a hot topic for 2015. Just in time for Christmas, the market is flooded with wearables and connected devices for health related applications. It is also predicted that we will see a rapid growth in this area, bringing in a whole new group of companies (mobile app makers) into the medical device world.

wearable

From a documentation point of view, there might be some confusion on what really counts as a MMA. FDA has put together a great set of information, explaining their take on the subject with some reasonable helpful tips on how they will make their judgement. I recommend that you take a look. 

Learn more about how Aligned Elements can help you to manage your medical device documentation.

Or contact us for a live demo.

October 20 2014

I was recently asked by a Business Developer at the Sahlgrenska Science Park Start-up incubator in Gothenburg, Sweden, about any useful medical device development documentation tips.

The concrete question was: "What is the absolute minimum a med-tech start-up must know about development documentation during the early phases in order to not suffer from mistakes later on?"

The development documentation essentially describes how you have developed the medical device.

This includes, but is not restricted to:

  • How you planned the development work
  • The requirements of the device
  • The specifications of the device
  • The Verification and Validation of the device
  • How you made sure that the device does not pose risk to patient safety

At product launch, all these things needs to be in place, with all documents properly written, reviewed, signed off and archived.

It is obvious to everyone involved that documentation means work.  A lot of work.  (We assess that up to 30% of the total development effort is spent on documentation). It is equally obvious that conducting this documentation work ties down resources that (due to mutual exclusion) is not spent on something else.

The practical effect of this is that once you start with the formal development (and documentation) process, everything else seems to slow down. And hence, there is often a question about "When does the formal development actually start?"

Now, while the regulations does not do any distinction between "formal" and "informal" development (there is only "formal" development), these start-ups are in such an early phase that they do not even know if there is going to be a product at all, or what the product should be.

What do companies in this situation have to know about development documentation?

Here is my advice:

  1. Once you start with formal documentation, you shall follow "Good Documentation Practices" (called "GDP"). Google it! It is essentially a set of rules describing how to practically write documents. GDP originates from the pharmaceutical industry but it is also widely applied in the med tech field. GDP is utterly concrete in its advice and includes statements similar to:
  • "If it is not documented, it does not exist"
  • Use page numbering "x of y pages" in all documents
  • Sign documents with Full name, signature and date in indelible ink (no pencils)
  • Use "YYYY-MM-DD" as date format
  • Make documents uniquely identifiable and so on.

Many of these rules are common sense and the sooner you start to use them, the better. Therefore, there is nothing preventing you from starting to use GDP right away and the extra work incurred is relatively low.

  1. Taking a medical device from prototype to market-launch is notoriously burdensome, especially due to the regulatory aspects. This phase, which by some is regarded as the “formal development phase”, requires a good deal of preparatory groundwork. It is very important to understand this. Before you start with “formal development”, your development framework needs to be in place.

A good place to start is to get familiar with some of the most basic medical device development concepts, and to have a good grip on these before the “formal development” starts. Even though these concepts have a limited influence on how you write documents during the early phases, knowing them well before formal development starts will make the transition from prototype to product a whole lot smoother.

I have listed some of the most important concepts below.

Quality Management System (QMS)

The QMS is a set of business processes that are meant to "assure product safety and efficacy".  Essentially, it formally describes how your company performs these business processes (such as purchasing, manufacturing, development, service, HR etc.)  in order to make sure that the patient safety is not at risk.

 This is what you need to know:

  1. You have to have a QMS if you want to develop and/or manufacture medical devices.
  2. It takes some time to set up a QMS, so get working on this in due time before the “formal development” starts.
  3. The processes described are not restricted to development, it encompasses aspects such as purchasing, service, support, HR, manufacturing etc.
  4. You don't have to write the QMS yourself. Several Regulatory Consultancies provide Out-of-the-box QMS-kits that can be adapted to your specific needs.
  5. The standards covering this aspect are called “ISO 13485” in the EU and "21 QSR 820" in the USA. When people say that they have "received their ISO 13485 certificate", it means that they have set up the QMS according to ISO 13485 and somebody has checked it.
  6. If you do not have regulatory expertise in your company, I strongly advice that you get outside support to set this up.

Target Markets

Each geographical market has its own set of regulations. Even though the global community is working on harmonizing standards and norms, there are still local particularities.

Broadly speaking, regulations in USA and China are considered more "difficult" to comply with whereas EU and Canada is considered less "difficult".

Selecting target markets does therefore have a large impact on the development documentation required later on.

Intended Use

The "Intended Use" stipulates the use your product is intended for. This probably sounds straight-forward. However, I cannot emphasize enough the enormous impact the intended use has on the documentation burden lying ahead. Note that the intended use is not “what the device is designed for” or “what you can do with the device”. It is what you say your device is to be used for,

The classic example is the scalpel.  If you stipulate the intended use to be “cutting tissue” in the general sense, then it is a Class I device according to the FDA. But if you label the exact same scalpel to be used for ophthalmology or eye surgery, then it is suddenly a Class III device.

Furthermore, according to the FDA, if your device is equivalent to a device already existing on the (US) market, then less work is needed to bring it to the market. The “equivalence” is largely decided based on the intended use.

Therefore, the way you word the intended use has a large impact on the regulatory pathway and thus the accumulated effort of bringing your device to the market. It is important that you consciously and carefully formalize the intended use and that you also develop the device according to the intended use.

Product Classification

The "Intended Use" plus "target market" will render into a product classification for each target market.  FDA and EU regulations use different classification schemes. Generally speaking, the classification describes which and how much data you need to provide in order to get regulatory clearance. This can vary a lot between classifications.

Generally the following applies: the higher risk the product poses to the user (patient, nurse or other), the higher the classification. The higher the classification, the more work (including documentation) is required to prove that the product is safe.

If your device is in an area where you need to prove its effectiveness and reliability on living beings, you need to go through proper Clinical trials (see http://en.wikipedia.org/wiki/Clinical_trial ). Clinical trials are notoriously expensive. Therefore, it is crucial that you have a formal process in place, otherwise the data will not be valid and you have to start all over.

Risk Management

Since patient safety is such a central concept in medical device development, the sooner you get familiar with Risk Management the better. There is simply no way around it. In order to launch you product, you have to have documented proof of that you device is safe to patients and users. The normative standard to look for is ISO 14971 which describes how risks are identified and controlled. There are plenty of seminars and webinars available on risk management introduction and it is well spent time to visit one or more early on.

Conclusion

Medical device development documentation constitutes a large part of total development effort. By learning how to apply Good Documentation Practices during the early phases to all your documents, you will feel more at ease with the necessary work methods when the “formal development” starts.

Switching from “non-formal” to “formal” development is not done in an instance. Setting up the development framework will take some time and you should plan accordingly. I have tried to introduce some of the most important medical device concepts in this text.

If you plan to stay in the Medical Device development field for some foreseeable time, regardless of role or occupation, these are concept that you have to get familiar with. They will permeate your work. Even though they might not seem relevant to start-up teams, it is necessary to know these things in order to make the notoriously difficult transition from prototype to market-ready as smooth as possible.

If you have questions or want to know more about these things, please This email address is being protected from spambots. You need JavaScript enabled to view it. and we will do our best to help you.

Learn more about how Aligned Elements can help with achieving regulatory compliance

Request a live demo and let us show you how Aligned Elements can manage your documentation

October 04 2014

Preliminary Hazard Analysis is a risk assessment technique performed in the early the design phases. It is a powerful method to document and assess device risks without having the full implementation completed and to highlight problematic risk areas early on.

hazard

We have previously discussed how the PHA compares with the FMEA method in Aligned Elements and how they complement each other. The templates needed are available here.

Learn more about Aligned Elements and Riskmanagement

Request a live demo and let us show you how Aligned Elements helps you with your Preliminary Hazard Analysis

September 04 2014

I say "IEC 62304 Software Safety Classification", you say "A, B, C".

If you have worked with IEC 62304, you have (probably) also faced the challenge of assigning Software Safety Classifications to the Software Items. It has to do with associating a risk level to your software items in order to assess how careful you need to be when you document, develop and test them.

Now, if you work with medical device development, it has probably dawned to you that you are already doing risk management. Lots of risk management. All sorts of risk management. Is it possible to use the existing risk assessments when doing our IEC 62304 work? Yes, I think so.

When a software designer/architect constructs the software architecture needed for IEC 62304, there are lots of approaches to choose from. The norm is explicitly ambiguous on this point. In short, it is up to you to pick an approach. It is however not uncommon for the software designer to use established modelling techniques such as UML, Object-oriented design, multi-layered design, SAAS etc. which in most cases results in number of boxes (the software items) with names like:

  • User Interface
  • Logging
  • User Management
  • Reporting
  • Data Access Layer
  • Persistence
  • Serial Communication etc.

So are we supposed to perform a risk assessment of these boxes now?

What strikes you immediately is the insight that these boxes in themselves do not "have" risk. Why? Because we have not defined the context in which they are used. Software risk emanates from how we use the software i.e. in which functional aspect we use the software items.

The guys of Certified Compliance Solution have solved this in a really neat way using what they call "The Matrix Model for Software Safety Classification". It is well summarized in the picture below.

MatrixModel

 

The CCE people have correctly identified that functional flows cut accross the software architecture.

In their model, Software Items are listed on the horizontal axis and User stories (or Epics, Use Cases, Work Flows, Specification or whatever you want to call them) are listed on the vertical axis. Now, risk assessments for User Stories is something we do every day so that part should be pretty straight-forward. Once that is completed, we can deduct a classification for each User Story based on this risk assessment (more about that later).

The Software Designer can now point out the Software Items that implements our User Story in the software. After we have done this for all User Stories, the software Safety Classification for a Software Item is simply the highest risk of its aggregated use, which is summarized in the bottom line "Overall SW Item Safety Class".

Isn't it beautiful?

Let me show you how this is implemented in Aligned Elements.

First, I introduce the Document Object type "Use Case" which will represent the user stories. Then I set up Document Object types for Software System, Software Item, Software Unit and SOUP which all have a Software Safety Class attribute being A, B or C, with the default value C.

I can then proceed to document the Use Cases and structure the Software Architecture separately.

Now, time for risk assessment. I will use the integrated Preliminary Hazard Analysis (PHA) to assess my Use Cases. When working out the risks using the PHA method, I am requested to define the possible Cause(s) for each risk. The Cause has a severity attribute and I will use this severity to calculate the Software Safety classification. If the Cause is emanating from the software, I further tag the Cause originator as "Software".

62304RA

I go back to the Software Item definition and map the values A, B and C to a Severity range in the Cause i.e. a Severity from 1-3 maps to Class A, Severity 3-5 maps to Class B etc.

To tie it all together, I trace the Use Cases to the PHA risks and (here comes the trick) Software Items to the software originated Causes.

 

62304UseCaseTrace

 

I run an Inconsistency analysis on the Software Items and get a report on how well the Software Item Safety classifications match the risk assessment, including suggestions on what the Software Safety Classification ought to be based on the associated risks.

 

62304SWItemInconsistency

 

Simple, transparent and consistent.

So we have a range benefits from this approach:

  • We perform risk assessment where it makes sense i.e. to Use Cases.
  • When we map use cases to software items via the risks, automatic checks that ensure that the maximum severity of the risks match to the software item safety class.
  • We have reused the use case risk assessment in our IEC 62304 implementation.
  • We have used traces to establish the relationships between use case, risk and software items and automatically get the required traceability for free.

Once again we have showed the benefit of integrating all Design Control Items in a single system.

The sum is truly greater than its parts.

  

July 17 2014

Traces are the glue.

Traces are the links that tie the development documentations together. They provide basis for verifying completeness and consistency.

Traceability, the discipline of setting and managing traces, is a core activity in the medical device development process. Norms and directives such as ISO 13485, ISO 14971, IEC 62304, IEC 62366 and FDA CFR 21 QSR 820 explicitly prescribe it.

Traces in a medical device project

In essence, establishing traces between artefacts is a deceptively straigh-forward task. You just declare the trace and that's it. So why is traceability perceived as such as annoying piece of work?

The main reason is change.

As mentioned above, a trace establishes a relation between dependent artefacts (e.g. a requirement and a specification). When change occurs to one party in this relationship (the requirement), the state of the traced artefact (the specification) may become invalid.

Word documents and Excel sheets are notoriously inept at handling this kind of problem, since the artefacts are not aware of eachother.

Traces in an Excel sheet are just dead text.

On the other hand, this is why traceability software tools such as Aligned Elements are so popular. Traceability softwares tools not only allow traces to be declared, but are also able to track changes made to the traced artefacts.

A change in an artefact automatically highlights the affected traces and signalizes that they might have become invalid due to the change. In Aligned Elements, we call such a possibly invalidated relationship a "suspect trace".

The user now has possibility to inspect the implicated artefacts and update them if needed. Or simply confirm that the the change did not have any impact on traced artefacts. In Aligned Elements, an impact analysis entry is made in the audit trail as the user complets this action, in order to ensure accountability throughout the development process.

However, these gains are quickly lost if different artefact types (e.g. tests and risks) are kept in seperate systems. Managing traces across system boundraies is often only possible by resorting to manual measures. Such as Excel. And then we are back to where we started.

Keeping all traced artefacts in a single system further helps disentageling a range of more mundane problems, such as finding out:

  • If some artefacts have not been traced
  • If some artefacts trace to artefacts of the wrong type
  • If some traces simply don't make sense

Trace consistency

In Aligned Elements, we have implemented traceability support following a few simple guidelines:

  • Usability. It shall be easy to set or remove a trace, regardless of the working context. Therefore we have five different mechanisms for setting traces.
  • Accountability. All trace-related operations shall be recorded chronologically in the audit trail.
  • Transparency. Missing, illegal and suspect traces must be immediatly and automatically highlighted.
  • Completeness. End-to-end traceability must be facilitated without having to cross system boundaries.
  • Reportability. Trace reports shall be customizable and configurable to match the quality requirements and look-and-feel criteria of each customer.

Again, traces are the glue.

Managed correctly with the right ALM support, they are (besides being regulatory necessities) a real asset to your design history file management. The traces help you ensure that completeness and consistency has been achieved throughout your development documentation. We are doing our best to make sure this becomes a smooth journey.

googleplus facebook