{fastsocialshare}

Christian Kaestner at Qadvis, is an expert company offering quality and regulatory services for Medtech companies, and co-author of the upcoming standard "IEC 82304-1: Health Software - General Requirements for product safety." We were fortunate to get a few minutes of his time to answer five quick questions about the standard and its implications.

What is IEC 82304 all about?

"The purpose of the standard is to establish product requirements for standalone software, i.e. software products not running on dedicated hardware. IEC 82304-1 could be seen as an equivalent to IEC 60601-1 with the difference that the latter includes dedicated hardware for the software to run on. (And of course have a lot of hardware requirements!)"

But isn't this already covered by IEC 62304?

"No, IEC 62304 is a process standard and as such “only” define expectations on activities and their corresponding outputs. The key scope of IEC62304 is the lower part of the traditional V-model while IEC 82304-1 takes the complete product lifecycle into account. This means that IEC 82304-1 establish product requirements which aren’t addressed by IEC 62304, examples:

• Product requirements, like intended use and accompanying documents.
• Product validation
• Decommissioning of software (and its data!)

IEC 62304 is of course referenced by IEC 82304-1 for the development of the actual software."

Which companies are affected by IEC 82304? How can I find out if my company is affected?

"The scope of the standard is health software which is a broader term than medical device software. So, I would suggest any company working with medical device software (standalone) or software in the surrounding of medical device products to have a look at the standard. As a rule of thumb; you could say if your company develops software that might have an impact on the health/wellbeing of a human, I would say you are affected.

Below some examples which I believe should be included in the scope of health software:

• Prescription management systems - If the data is mixed up in any way it may result in wrong doses or even wrong medication to a patient.
• App keeping track of your medication (as one example) - If you use the app to avoid forgetting your medication or by mistake take it twice. This would of course not be good follow the instructions and the instructions are wrong.
• Software tracking “safe periods” to avoid pregnancy - Assuming the software counts wrong and gives green light when it shouldn’t… I can imagine the surprise in a month or so isn’t very popular!"

What is your advice to companies that need to implement IEC 82304?

"To be fair; all standards are voluntary so there is no requirement or need to comply with IEC 82304-1. But as for all other standards, it is a good praxis and gives your company a quality mark otherwise hard to claim.

My advice to companies with regards to IEC 82304-1 is to take advantage of it; it will support you in what is required to make standalone software to a product."

When will the standard be released and where can I get a copy?

"So far, the standard isn’t published, it is currently out for review (DIS, draft international standard). Depending on the result of the voting, an FDIS may be ready in Q2 2016. Usually, the difference between an FDIS and the final version should be marginal. The final version can probably be expected in late Q3 2016. (But, it all depends on the results from the voting process.)

Should you be interested already today, you can purchase a copy of the draft standard at www.iso.org."

If you want to know more about how to prepare for IEC 82304-1, contact Christian Kaestner at This email address is being protected from spambots. You need JavaScript enabled to view it..

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

• Effizienz durch Wiederverwendung
• Konsistenz durch Vermeidung von Redundanz
• Organisatorische Herausforderungen

{fastsocialshare}

Last week I attended the Inartis Network seminar "E-connected Healthcare - 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. Jone's 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 fulfill 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

{fastsocialshare}

"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 in which 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" to functional workflows and the software architecture. The approach is best explained in the picture below.

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 generate higher risks than others. The Matrix Model does not account for this.) 

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

Now, this is a valid observation and a phenomenon 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 the 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

The 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 put 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

{fastsocialshare}

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.

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 whether 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!

{fastsocialshare}

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 checklist 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 accompany 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 checklist 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. 

{fastsocialshare}

"If it is not documented, then it has not been done", according to the FDA saying. "Documentation not available", or "Documentation not adequate" are the most frequently cited deviations in FDA Warning Letters. The effects of inconsistent documentation can be devastating, implying postponed market launches, product withdrawals, and fines.

The reason for this flood of FDA 483 warning letters, addressing seemingly obvious and simple errors, is not that the medical device manufacturers are ignorant or incompetent.

It is simply hard to keep the DHF documentation consistent. 

The documentation requirements are many and detailed, the development projects often span over a long time-period, involves a large number of alternating team members, all contributing to the large set of deliverables that make up the Design History File/Technical File. The deliverables are highly interdependent and a small change can cause unexpected ripple-effects over large parts of the documentation.   A considerable amount of the total project effort is thus placed in the handling and management of the DHF.

Not long ago, I was contacted by a customer. He had recently taken over a project with the objective to take the product to market. After a brief introduction, he found the project to be in a miserable state. The project had switched project manager four times during the last four years, the team members were all new, knowledge about the documentation process was lacking.

 In short, the situation was very opaque. 

The project manager wanted help with assessing the current state of the development documentation and within 10 minutes, we could extract the following information from Aligned Elements:  

• About 20 Requirements lacked traces to Specifications. They were all software-related and entered by the same person during a short time-span about two years ago.
• All Specifications had adequate Test Cases assigned.
• About 10 Test Cases had never been executed. None of these were functional Test Cases and they had all been entered after the last milestone.
• About 10 Test Cases had the current state "Failed". Most of them had to do with reliability, maintenance, spare-parts, and life-time tests.
• About 15 Risks were insufficiently mitigated.
• About 10 Mitigations were not verified or implemented.
• All Word documents were up to date.

The project manager finally felt that he had some grip on the situation. He now had concrete errors to fix and also the names of the people to contact to get detailed information about each individual inconsistency. 

Aligned Elements addresses the issue of incompleteness with a range of integrated and automatic consistency and control functions. Aligned Elements is able to:

• In real-time, highlight any gaps and inconsistencies on any content set in the project.
• Provide reports that present a clear overview of the current consistency state of the project.
• Guide the user through a predefined process path to make sure errors are not created in the first place.

By the application of configurable validation rules, real-time checks can be executed on the documentation continuously. Faults and gaps are uncovered well in time before the auditor arrives or before the documentation is submitted to the notified body. 

Knowing the state of the development documentation is invaluable for a medical device manufacturer. The list of open errors, representing the project’s “Documentation Quality Debt”, is an excellent estimator for how much work remains until the documentation is ready for release.

Reducing project risk by making the current documentation state transparent is an excellent way to increase the chances of a successful product launch. 

Schedule a live demo and let us show you how Aligned Elements keeps your DHF complete and consistent

{fastsocialshare}

Our friend Dr. Samuel Fricker, assistant professor at Blekinge Institute of Technology, is co-authoring the publication "Requirements Engineering for Digital Health".

According to the information, this book:

• Includes practical step-by-step guidelines, examples, and lessons learned
• Addresses domains of central importance for the aging society
• Bridges cutting-edge research and relevant business and engineering practices

Samuel provided valuable help when we compiled our report on "Requirements Engineering for Medical Devices".

{fastsocialshare}

{fastsocialshare}

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 rapid growth in this area, bringing in a whole new group of companies (mobile app makers) into the medical device world.

From a documentation point of view, there might be some confusion on what really counts as an 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 judgment. 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.

{fastsocialshare}

{fastsocialshare}

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 need 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 do not make 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 Medtech 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 the 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.

2. 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's 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 advise 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 the USA and China are considered more "difficult" to comply with whereas the EU and Canada are 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 concepts apply; the higher the 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 your product, you have to have documented proof that your device is safe for 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 the 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 concepts 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

{fastsocialshare}

{fastsocialshare}

Preliminary Hazard Analysis is a risk assessment technique performed in the early 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.

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

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 on 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 modeling techniques such as UML, Object-oriented design, multi-layered design, SAAS, etc. which in most cases results in a 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.

The CCE people have correctly identified that functional flows cut across 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 are 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 implement 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".

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.

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.

Simple, transparent, and consistent.

So we have a range of 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 will ensure that the maximum severity of the risks matches with 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 shown the benefit of integrating all Design Control Items in a single system.

The sum is truly greater than its parts.

{fastsocialshare}

Traces are the glue.

Traces are the links that tie the development documentations together. They provide the 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.

In essence, establishing traces between artefacts is a deceptively straightforward task. You just declare the trace and that's it. So why is traceability perceived as such as an 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 each other.

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 software 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 the possibility to inspect the implicated artefacts and update them if needed. Or simply confirm that 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 completes 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 separate systems. Managing traces across system boundaries 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 to disentangle 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

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 immediately 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 have been achieved throughout your development documentation. We are doing our best to make sure this becomes a smooth journey.

{fastsocialshare}

Not long ago, I sat down with three test managers I have recently worked with. They all have extensive backgrounds in managing test teams and supervise the writing and execution of test cases in large Medical Device projects. Since we have made the observation that about 50% of the total DHF is consisting of tests, I had long been pondering how the test activities could be done more efficiently.

We talked about how to find the right "review and release" effort (goldilocks principle, "not too much, not too little"), the optimal test case size, the optimal number of fields in a test case, and how to deal with the ever reoccurring problem of volatile specifications. I got some interesting input on all topics and I was very satisfied with how the conversation went on.

After a while, one of them said, "Mr. Larsson, it is all well and good that you want to optimize the test case writing and execution. I understand your intentions. But, you know, testing is more than just writing and executing. In my opinion, only 30% of the total test effort consists of the writing and execution activities you talk about. 70% is about setting the table. If I were you, I would take a look at that 70%."

I must confess that I did not really understand what he was talking about. In my world, testing is writing and executing test cases. And what did he mean by "setting the table"?

After some prying, we got closer to the heart of the matter: setting the table implies activities such as:

• Setting up infrastructure (computers, user accounts, instruments, etc.)
• Training testers – get to know the instrument, the “lingo”, the templates, and the processes
• Setting up / calibrating the instruments to test
• Learning simulation tools, log parsers, etc.
• Generating test data
• Reviewing specs
• Dry runs and exploratory testing
• Collecting test data

These are all auxiliary test activities that lay the foundation on which efficient test case writing and execution are subsequently performed. They might not look particularly impressive at first, but experience has shown that performing these activities carefully, consciously, and consistently pays off immensely. The reverse is also true; failing to give these activities their proper attention will have a severe impact on testing efficiency.

Finally, another test manager said, "Writing and executing a test case is the end of a long journey. It is the result of a long array of preparatory activities. It is how you get to this point that decides how efficiently your writing and execution will be".

{fastsocialshare}

We have been following an interesting discussion on Linked In "How far is possible"  (this link can only be viewed if you are a group member: Medical Devices: QA / RA discussion 'How far is possible?') as a result of the 14971:2012 Annex ZA deviation #3.

In this discussion, Mr. Singh linked to an informative presentation http://goo.gl/QJiUZj on the subject.

Most companies that participated in the discussion have updated their processes to avoid the term ALARP, usually also no longer identifying any 'Acceptable' ranges of risks. The driver seems rather be to comply with what notified bodies expect to see. All still acknowledge that there will always be the notion of an economical parameter when deciding on risk measures. The arguments backing why the risk measures weren't taken even further were recommended to be an analysis of Risk vs Benefit and claiming that the risk measures are 'State of the Art'

 {fastsocialshare}

Since the release of Aligned Elements V2.1 SP 1, it is possible to integrate Work Item lists from your existing Team Foundation Server in Aligned Elements.

With the appropriate configuration, coupling your Aligned Elements user with your TFS user, your Work Items dynamically appear in a separate Item view. 

In Aligned Elements, the Work items behave and are treated very much like regular Document Objects, meaning that you can open and edit them in a Document Object form, set traces to them, set up inconsistency rules for real-time checks, etc.

When saving changes made to a Work Item in Aligned Elements, the attribute changes are routed to the TFS server, effectively separating the two repositories according to their respective responsibilities. 

Using the "Go to Original" link in the Document Object Form automatically opens a browser and navigates to the Work Item on your TFS server.

Using the Aligned Element TFS integration permits you to benefit from your existing Team Foundation System infrastructure in the Design History File management, working smoother, faster, and with fewer interruptions.

{fastsocialshare}