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

July 18 2014

On July 19th, 2014, we release Aligned Elements V2.2 (2.2.7.9739) which includes the new Aligned Elements Web Client.

The Aligned Elements Web Client enables browser-based access to any Aligned Elements project from any remote location.

Login

 TraceExplorerConsistencyCoverageWebChart

It is the efficient way to involve and benefit from external project stakeholders such as customers, suppliers, distributed marketing teams, external testers and other remote team members in the Design History File collaboration process.

The web client permits the user to perform core activities such as creating, updating and tracing Document Objects, managing chapter hierarchies, inspecting the project content, running queries, performing free text searches etc.

The new interface is optimized for easy access to core Aligned Elements functions  and combines high performance with a modern interface to enhance the user experience.

For the Windows Client V2.2, we have added a number of new features, most notably:

  • Bookmarking favorite Document Objects
  • Inclusion of the Revision History in Document Object XML exports
  • Optionally including old revision data of Document Objects in Excel reports
  • Copy users to other projects in order to minimize User management effort

We hope that you will enjoy these improvements.

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.

June 20 2014

Zühlke Engineering AG in Zürich (http://www.zuehlke.com), has been
evaluating Aligned Elements during the spring and we recently had the
opportunity to speak with Mr. Claudio Schödler, project manager at Zühlke,
about the results.

"Having finished the evalation of Aligned Elements after 3 months of
careful study, we can conclude that it is a highly suitable application for
medical device development projects." Mr. Claudio Schrödler summarises.

"The tight integration of the risk management functions is a particularly
strong advantage when working in this industry.", Mr.Schödler continues.
"In comparison with other similar applications, we have noted that Aligned
Elements excels in terms of ease of use and reporting. Most teams will be
up and running in a very short time.”

"As you work with the application, it becomes apparent that the Aligned
team has focused on easing the documentation burden, and succeeds in doing so very well.”

June 12 2014

Not long ago, I sat down with three test managers I have recently worked with. They all have extensive background 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 those 70%."

Only 30% of the test effort is about writing test cases

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 executing is subsequently performed. They might not look particularly impressive at first, but experience has shown that performing these activities carefully, consciensly and consistently pays of 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".

May 05 2014

From the very first day, we decided to integrate risk management into Aligned Elements. It is obvious to anyone within the industry that risk management and requirement-specification-verification-validation management are intimately connected. Still, many companies insist on keeping these two artefact collections separate in isolated systems. We think the management of all Design Control Items, including risk information, can be made more efficient with less errors if they are kept within one system.

Failuremode and Effect Analysis in Aligned Elements

In Aligned Elements, we initially implemented FMEA as risk analysis method. The FMEA is a very versatile risk assessment technique. It is widely adopted in the medical device industry and fairly straight forward to understand.

The implementation of FMEA:s in Aligned Elements goes as follows: a Failuremode entity holds a collection of Hazard entities. Each Hazard contains a cause with its probability, an effect with its severity, and an additional optional visibility parameter. A risk priority number is calculated based on the probability, severity and visibility values. The Hazard can then be addressed with one or more Mitigations which, each in turn, reduce the RPN to a new value. 

All this entered risk information in subjected to Aligned Elements general features, including:

  • Individual IDs assigned to each entity
  • Strict version management of all changes made
  • Changes are registered chronologically in the project audit trail
  • Search and filter options can be applied using the Query Manager
  • Risk reviews can be performed using the integrated Design Review Module
  • The  risk information can be included in the Aligned Elements DHF Index

Based on our experiences of time consuming risk analysis work, we included a number of usability features to make the day-to-day work easier and to save time and resources: 

  • Automatic calculation of RPN
  • Automatic checks of RPN against thresholds
  • Intelligent reuse of mitigations
  • Highlighting of unmitigated risks
  • Highlighting mitigations that have not been implemented
  • Automatic Risk Summary generation
  • Control checks that applicable parts of the DHF has been subjected to risk analysis
  • Highlights which requirements/specifications/tests that are affected by the risk analysis
  • Incorporation of risk entities into the overall trace landscape

One of the many reasons the FMEA is such a widely adopted technique derives from its versatility and flexibility. This permits the medical device manufacturer to apply the best possible fit between his risk analysis approach and his existing products, processes and organization.

Aligned Elements provides a number of customization possibilities to ensure that a wide range of FMEA variants can be applied, including:

  • Customizable naming of the parameters and entities
  • Customizable Probability, Severity and Visibility ranges
  • Customizable thresholds for unacceptable risk, ALARP and acceptable risk
  • Customizable formulas for RPN calculation
  • Customizable look and feel of the risk report
  • Expanded Risk reports to include traceability to mitigation implementation according to client QMS
  • Multiple FMEA types in the same project

Enter Preliminary Hazard Analysis 

Not all our customers favored the FMEA as risk analysis method. We therefore contacted ProSystem AG,  an well renowned expert company in the area of medical device risk management and active member in several norm groups (such as IEC 62304, IEC 60601-1) and jointly developed a Preliminary Hazard Analysis (PHA) method in Aligned Elements as an effective complement to the existing FMEA method.

According to theory, the PHA is a top-down approach, using a list of known hazards as input for the risk analysis. The PHA method can be applied in the early stages of the development process and does not presuppose detailed knowledge about the system to be analyzed. 

The Aligned Elements Preliminary Hazard Analysis uses a terminology aligned with ISO 14971 to describe Potential Hazards, Harms, Measure entities etc.. 

As opposed to the FMEA, our PHA implementation uses a stricter separation of Causes and Harms from the Risk Analysis aggregator (the Risk Analysis entity corresponds to the Failuremode entity as a collection of Causes and Harms under a particular subject), where Causes and Harms are captured as separate entities. This allows a more efficient reuse when causes and harms are reoccurring throughout the risk analysis, saving time when creating and managing the risks. Keeping the Causes in separate entities further permits them to be used as the link between IEC 62304 Software Items and the risk analysis in accordance with the IEC 62304.  

In the PHA, we have expanded the Cause entity to include a “Cause source”-parameter to enable a more precise analysis of risk causing factors. Correspondingly, the Harm entity  has an additional “Has Effect On”-parameter for a more granular designation of the affected agent.

Furthermore, in accordance with best practices from ISO 14971 and other risk norms, the Measure entity contains an additional parameter to explicitly designate risk control approach such as "Design for inherent safety", "Adding Protective measure", "Providing Information of Safety" etc. This risk control approach can further be connected to the risk reduction parameter controlling the new RPN to ensure that a given risk control approach always results in a consistent risk reduction.

With the Preliminary Hazard Analysis, we have created a capable complement to the existing FMEA risk analysis implementation. We have enlisted the help of renowned industry experts and used input from our client base to build an implementation more aligned with ISO 14971 and industry best practices. The decoupling of the PHA entities in separate Document Object types permits a more efficient information reuse than the FMEA implementation. Additional parameters enables the user for more in-depth analysis of risk drivers.  This has been achieved without compromising the benefits of strict version control, integrated consistency checks and flexibility that Aligned Elements offers.

If you are interested in a demonstration of the Aligned Elements Preliminary Hazard Analysis, please contact us

Learn more about riskmanagement in Aligned Elements.

Let us show you how riskmanagement works in Aligned Elements during a live demo. 

googleplus facebook