July 29 2015
Innerhalb der Medizintechnik wird die Risikoanalyse, sei es in Form einer FMEA oder als vorläufige Gefahrenanalyse (PHA),  zu einem immer wichtigeren Teil der Dokumentation.  Sie spielt eine Rolle bei der Umsetzung von EN ISO 13485, IEC 62304, Richtlinie 93/42 EWG über Medizinprodukte und Richtlinie 98/97 EG über In-vitro-Diagnostika, sowie auch der Umsetzung anderer Normen und Direktiven.
 
Um schneller und effizienter entwickeln zu können,  setzen immer mehr Hersteller auf eine modulbasierte Entwicklung. Um beiden Zielen gerecht zu werden, bietet es sich an, auch das gesamte Risikomanagement modular zu gestalten. 
 
Das Zusammenspiel der Themen:
  • Effizienz durch Wiederverwendung
  • Konsistenz durch Vermeidung von Redundanz
  • Organisatorische Herausforderungen
ist aber durchaus komplex. 
 
Modulare Riskoanalyse
 
Die Herausforderungen und ein möglicher Lösungsansatz werden in einem Gratis Paper hier skizziert.
 
 
 
June 29 2015

Last week I attended the Inartis Network seminar "E-connected Heathcare - Innovation Made in Switzerland in Digital Health and Telemedicine" that covered the latest developments in the eHealth market. The eleven speakers provided some very interesting input on their take on the problems and solutions in this domain. The common denominators were:

  • Health-related wearables connected to the "cloud" are here to stay. The sensors will become even more advanced in the next years.
  • Digitalization of Patient records is still progressing really slow even though everyone understands the potential benefits.
  • Where patient data and wearables meet there is still an integrity issue
  • There are numerous "new" players entering this health-related field coming from other industries (logistics-, telecom-, energy-companies)

The seminar was utterly silent on the regulatory aspect of all these developments. There was only one point where this came up: as Mark-Eric Jones, the CEO of Leman Micro Devices was presenting the company's smartphone blood pressure solution, he got the question if this "did not make the smartphone a medical device"?

We can all imagine where this could lead. If the smartphone becomes a medical device then it needs to be developed and documented accordingly. Who would do this work? I cannot imagine that Apple and Samsung are particularly keen on the idea. 

Mr. Jones ingenious answer was to declare the smartphone as a medical device accessory "..like a battery. If your device needs a battery, you don't need a special medical device documented battery. You can take any battery as long as they fulfil the specifications you set up as a medical device manufacturer. It's the same with the smartphone. We define the required specifications and you can then use any smartphone that suits these specs."

Mr. Jones claimed that Lemans had worked closely with the regulatory authorities on this issue and had received acceptance of this approach provided that "additional software safety measures are put in place."

A very interesting approach. It remains to see if this is a viable approach for other manufacturers.

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

 

 

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

February 03 2015

To accelerate your development documentation process, Aligned Elements supplies a number of free downloadable extensions.

These include:

  • regulatory wizards, generating requirements, risks and other Design Control Items based on how you apply a given regulation
  • example content, such as requirements, potential hazards, risks and other Design Control Items
  • regulatory checklists for verifying your content towards medical device norms and regulations
  • import tools, template packs, unit testing integrators, xml transformations and much more.

The extensions can be used in your existing projects to speed up the documentation work, to serve as inspiration or to be used as enhanced control mechanisms.

 accelerate:Courtesy of Malene Thyssen/Wikimedia

Is your device qualified for eIFU (EU No 207/2012)?

For those considering using electronic instructions for use (eIFU) according to EU 207/2012, take a closer look at the "Electronic Instructions For Use Checklist (EU 207/2012)" that helps you finding out weather your device and its intended use makes is it qualified for the regulation.

The QA-based checklist provides objective evidence, once completed, that you have made a careful and detailed analysis of your device according to EU 207/2012.

The advantages of eIFUs are many and compelling, including:

  • Reduced costs for printing and distribution
  • Possibility to include rich media content
  • Faster distribution of critical updates
  • Reduced burden on the environment

Use this checklist to confirm that the regulation applies to your device.

If the checklist establishes that EU 207/2012 applies to your device, proceed and download the 38 predefined eIFU Requirements extracted from the EU 207/2012 and import them into your project.

Accelerating the development documentation work could not be easier!

January 30 2015

As an example of Aligned Elements project consistency control, the Aligned Elements Pre-Submission checklist demonstrates how various aspects of the project content can be analyzed in order to avoid failed audits and unwelcome FDA 483 warning letters.

Both EN/ISO 13485 and EN/ISO 14971 are concerned with the completeness and consistency of the project content and this checklists serves as an instrument to make that effort easier and faster.  

The checklist guides the user through a number of analysis action steps and optionally records the results in a checklist report, which serves as objective evidence of the analysis. Detailed instructions and screenshots accompanies the steps to facilitate the execution.

The checklist has been designed to check a project that uses the Aligned Elements default templates.

The checklist verifies test points such as:

  • Have all the Requirements traces to Specifications?
  • Have all Specifications been tested?
  • Are all Tests passed?
  • Have all Risks been mitigated?
  • Have all Mitigations been either tested or traced to a Specification?
  • Have all Document Objects been placed in Word files?
  • Do any Word files contain outdated Document Objects?

The check list further performs optional checks, if you have selected to use features such as:

  • The integrated Issue Management System
  • The integrated Design reviews
  • The integrated Risk Summary
  • The integrated DHF Index

 The Checklist, which is implemented as a Regulatory Wizard, is available for Aligned Elements users on the Extensions page in the Wizard section. 

googleplus facebook