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

April 23 2015

"But it all becomes Class C?!?" - IEC 62304, software architecture and Software safety classification

During a seminar some time ago, I elaborated on the possibility of using  existing risk assessments to deduce the software safety classification (SSC) of the software architecture parts according to IEC 62304 (see the slides here).

My discussion was based on the Matrix Model, initially published by the company "Certified Compliance Solutions". The essence of the deduction goes like this:

  • IEC 62304 does not stipulate an explicit traceability relationship between the SW requirements and the architecture.
  • The Software Safety Classification of each software item/unit is based on the potential harm that (hypothetical errors in) the item/unit might produce.
  • Risk originates not from the software item itself, but from the functional context it is used. If a GUI component displays printer settings, then the risk is low. If the GUI component displays the real-time EEG, then the risk is high.

So how can the risks emanating from the functional context often documented in SW requirements, be transposed to the SCC of the Software Architecture.

The company “Certified Compliance Solutions” ties these concepts together by applying the so-called "Matrix model" on functional workflows and the software architecture. The approach  is best explained with the picture below.

MatrixModel

The idea is to establish/document use-cases for all SW Requirements and perform a risk assessment on these Use Cases to establish the worst possible harm they might cause.

This gives each Use-case a "functional" Safety Classification.

On the X-axis, we enumerate all Software Items/Units in our architecture.

It should now be possible to single out the set of Software Items/Units a particular Use-case needs/uses for its implementation.

The functional safety class for the Use-case can then be transferred to all the Software Items/Units needed for its implementation. Repeat this process for all Use-cases.

The highest occurring Software Safety Classification in each column represents the Software Safety Classification for the Software Item/Unit of that column.

(Be aware: A Use-case usually does not cause the same risk for each step of the workflow. Some steps generates higher risks than others. The Matrix Model does not account for this.) 

"But then all becomes Class C?!?" - exclaims a young man in the audience.

Now, this is a valid observation and a phenomena we see from time to time.

Risk-driven development is one of the underlying reasons for IEC 62304. The manufacturer should focus development efforts on the software parts that pose the highest risks.

The Software Safety Classification-concept is used to detect these software parts. More risk => more effort required to ensure safety.

However, manufacturers sometimes seem overburdened with the ins-and-outs of the regulation and therefore capitulates to the approach of "just smack class C (or class B) on everything and get it over with".

I think there are several reasons for ending up in this situation and these reasons should not be confused with each other. They each have different causes and different remedies.

Defunct Architecture

The first potential reason lies in the selected software architecture.

If, after having applied the Matrix Model, it turns out that all Software Items/unit indeed receive the highest possible software safety class, then this is might indicate a particularly entangled design with insufficient separation of concerns.

The Matrix Model should give an indication of high-risk Use Cases that span across wide parts of the architecture.

The scope of these use cases might be too large. Reconsidering the scope and aiming for a more risk-driven division of the workflows could lead to some important decomposition gains. 

Or maybe the decomposition of the architecture is insufficient. Further decomposition and/or segregation of software items can potentially confine high-risk aspects of the software to dedicated areas.

Bad Processes

A second and completely different reason for "everything turning into class C" lies in the administrative overhead of separating the work needed for each Software Item according to its Software Safety Classification. This point-of-view advocates that it is simply less work to treat every software item uniformly from an administrative perspective, regardless of the actual risk of the software items is lower than nominally designated risk.

This indicates that something is foul in the development process and/or documentation system. IEC 62304 gives the manufacturer a possibility to perform efficient development, allowing redistribution of resources from low risk areas to high risk areas of the software. That opportunity is foregone in this scenario.

A well-adapted development process and supporting tool-set shall make sure that the following things are in place:

  • An easy-to-understand, formalized technique to correctly deduce the Software Safety Classification from Risk assessments.
  • Automatic checks to verify that the software architecture is valid from a Software Safety Classification perspective.
  • Clear designation of necessary and sufficient tasks to comply with IEC 62304 given the SSC for the particular item.

The Matrix Model is right

A third reason for this phenomenon is, of course, that the result is entirely warranted. The Matrix Model might actually correctly show that the entire software DOES carry a risk for death or serious injury to the patient and/or user. If this is the case, the model has served its purpose.

Safety and Quality first

Last but not least, your development process might be more ambitious than what IEC 62304 requires. This is entirely OK. IEC 62304 establishes the most basic requirements to ensure that the software is developed with safety in mind. Raising the bar further by applying even more rigorous development requirements with regards to safety might very well be warranted for companies that puts safety and quality first. 

Learn more about how Aligned Elements can help you support IEC 62304

Request a live demo and let us show you how Aligned Elements can help you to comply to IEC 62304

April 13 2015

Join us at Kista Entré Konferens in Stockholm, Sweden, on May 12th for the morning seminar "Your Medical Device Development - death by documentation?" 

“Writing documents and putting them into binders does not sound like rocket science.”

Nevertheless, many of us have experienced how documentation and traceability according to ISO 13485 and FDA QSR 820 turns into a both complex and cumbersome activity. Surprisingly enough, as long as regulatory demands are met, the documentation process itself is seldom scrutinized for efficiency improvements.

This seminar highlights how great savings can be made in this area. We uncover bad documentation practices, their consequences and potential remedies with the intent to make the medical device documentation process more efficient.

This event is a cooperation with Qadvis. Event details can be found here.

Looking forward to see you there!

April 07 2015

There was standing room only when Mr. Robert Ginsberg, CEO of Qadvis and co-author of IEC 62304, and his team presented best practices and lessons learned at Marriott Courtyard Hotel in Zürich on March 31st.

Ginsbergs session addressed common questions arising medical device manufacturers attempt to implement the harmonized standard IEC 62304 "Medical Device Software".

"Even though many IEC 62304 issues are context dependent, there are a few persistent problems that I come across time and again.", says Mr. Ginsberg.

Not enough focus on Software Quality - manufacturers tend to stare themselves blind on the documentation required for IEC 62304 and subsequently lose focus on the intended goal of the standard, namely to increase software quality."

Lost traceability - we keep detecting gaps in the traceability during the audits we perform, particularly regarding how risk control measures are implemented as software requirements and how they are subsequently verified. Traceability is an immensely complex task to manage as the project evolves and I highly recommend to use software support tools available to handle this activity."

No connection from the field to R&D - I can't stress this enough: post-market surveillance is one of the main focuses of the regulation. It is an incredibly important indicator on how the software is actually performing. Still, it is also one of the most neglected aspects in the software life cycle. Post-market data contains a virtual goldmine of opportunities for increased software quality and should be properly addressed."

Non-value added activities to fulfill IEC 62304 - The standard is not about producing alibi-documentation, it is about increasing software quality. In one "agile" firm I worked with, the detailed design was extracted from the existing code base after the coding was complete, using a software UML extractor. But documenting the detail design in such a matter provides no added value to the software quality what so ever."

Too shallow risk management - Risk management is not an administrative activity to make Notified Bodies happy. It is the driver of improved software safety and quality. Therefore, to be able to improve safety, the depth of the analyses needs to increase. 

Mixup of concepts - the terms 'SW validation' (as defined e.g. by AAMI:TIR 36), 'product validation' and 'product verification' do not denote the same thing and these terms can therefore not be used interchangeably. IEC 62304 is not concerned with any types of validation activities. Do be clear vis-a-vis the auditors, formally define the terms as you intend to use it and apply it consistently within the company and in your documentation.

Too strict interpretation of segregation - There is this note in IEC 62304 that indicates that the only possible segregation of items is to execute them on separate hardware. This is not entirely true. Soft segregation on functional and/or logical level can be entirely appropriate depending on the risk the segregated items expose. The main point is that your segregation must be well-argued, proven to be effective and documented.

Using system level testing as a risk control measure - testing is by most notified bodies no longer accepted as risk control measure. An RCM should result in a new SW requirement which in turn is verified.

No metrics supporting the process - having no metrics showing how well your software performs, might lead to unconstructive arguments with your auditor about the true level of safety your software retains. It is my advice to define and use performance metrics to support your case of having developed a high-quality software and in particular, make use of the available field data."

"This is by no means an exhaustive list but, as I mentioned, I see these issues a lot and I think the effort needed to address them are relatively cost-effective. Should you have any further questions, I'd be happy to address them afterwards.", Mr. Ginsberg concludes.

The Aligned team presentation, with focus on the documentation tasks required by IEC 62304, addressed the issue of conceptually connecting the software architecture and the risk management in the development documentation.

By using a concrete example, Aligned demonstrated how a Preliminary Hazard Analysis as risk assessment could be used in their medical device ALM software "Aligned Elements" to not only fulfill the traceability requirements of IEC 62304 but also successfully connect the software architecture with existing risk assessments.

The seminar was concluded with a host of interesting and constructive discussions among the participants at the subsequent lunch buffet supplied by Marriott.

March 11 2015

Medyria is a Swiss medtech startup that engineers technologies for endovascular catheter navigation and sensing.

Medyria’s core technology is a sensor-based system, called Flowcath, to measure blood flow and a revolutionary technology for processing flow data and tracking catheters called Trackcath. The combination of these two technologies creates a set of tools that will redefine how physicians navigate and track catheters during minimally invasive surgical procedures. The technology in its first application provides contrast-dye-free precise catheter guidance for stent placement.

Medyria

Medyria has won a number of awards for their scientific development work. Medyria is using Aligned Elements for managing their medical device related development documentation management.

Find out more about Medyria here.

February 19 2015

Having questions on how to apply and implement IEC 62304 in your company?

Join us as Robert Ginsberg, one of the co-authors of "IEC 62304 Medical Device Software - Software Life Cycle Processes" reveals the initial intent, best practices and lessons learned of this software standard.

In this half-day seminar we will address the practical challenges of implementing IEC 62304 in medical device software development.

Key Learning Objectives:

  • IEC 62304: best practices and lessons learned
  • IEC 82304: how will it fit in next to other standards
  • IEC 62304 Amendment 1: key changes and their consequences
  • Software risk management, architecture and software safety classification: bringing it together

Take the opportunity to confront a co-author of IEC 62304 with your own thoughts and questions.

A 30% earlybird discount applies to all registrations made before March 1st!

When: Tuesday March 31st, 08:30 - 13:00

Where: Hotel Marriott Courtyard Oerlikon, Zurich (directions)

Price: 250 CHF  (Note! 30% earlybird discount for registrations before March 1st)

Register here!

Hosted by: Qadvis / Aligned AG

Presented by: Robert Ginsberg CEO, Qadvis, co-author of IEC 62304 and Anders Emmerich, CEO, Aligned AG

googleplus facebook