December 13 2018


Finally! State-of-the-art Medical Device IT Security Requirements! And they are free! And you can download them!

For those of us who (in vain) have poured over IT Security standards and guidelines of variable quality in order to distillate useful requirements: look no further! A state-of-the-art, useable Medical Device IT Security guideline is finally here!

The Johner Institute has in collaboration with TÜV SÜD, TÜV Nord and Dr. Heidenreich (Siemens) compiled an excellent set of Medical Device Cyber Security Process and Product requirements and made it available to the industry for free.

Roughly 150 IT Security requirements are available in the Guideline covering both process requirements as well as product requirements, including the level of expertise needed to implement them, are available in the following structure:

Process requirements

Requirements for the development process

  • Intended purpose and stakeholder requirements
  • System and software requirements
  • System and software architecture
  • Implementation and development of the software
  • Evaluation of software units
  • System and software tests
  • Product release

Requirements for the post-development phase

  • Production, distribution, installation
  • Market surveillance
  • Incident response plan

Product requirements

  • Preliminary remarks and general requirements
  • System requirements
  • System and software architecture
  • Support materials

This IT Security Guideline is directed to Medical Device Manufacturers as well as Auditors, Reviewers and Hospital Management.

Dr. Johner and his collaborators have in this guideline managed to deliver concrete, best-practice guidelines, something that most other standards and regulations certainly tend to lacks.


The entire guideline is available in the GitHub-Repository „IT Security Guideline“ ( and is a recommended read for everyone concerned with Medical Device cyber security. You can also download Excel files with the requirements from the Johner Institute website.

We have made the Product IT Security Requirements available as downloadable extension for Aligned Elements. It is recommended to use them in conjunction with the material in the mentioned GitHub-repository, which contains valuable additional information and footnotes that explains the rationale and context for some of the requirements.


November 26 2018

Risk Assessments play a central role in Medical Device development. All medical device manufacturers apply risk management (they should because they have to!). All of them claim to be compliant with ISO 14971. And all of them do it differently.

I have worked with a large number of clients and I have seen more Risk Assessment variants than I can count. Some are good, some have, let's say, "potential".  


From this experience, I can deduce a few best practices that will reduce the risk assessment effort considerably.

Here are my top five tips:

Don't brainstorm to identify risks

You are required to identify and assess ALL potential risks. How do you find them ALL? That can be a daunting question for someone new to the medical device industry.

However, the solution is to be structured i.e. to use a structured approach to systematically identify risks. There exists several known methods to do this, including:

  • Task Analysis (analysing the use process)
  • System Analysis (analysing the system through decomposition)
  • Using the ISO 14971 annex questions
  • Using existing risk reports of similar devices

Regardless of the approach selected, brainstorming should not be one of them. There are a number of well-known reasons for this, the most important one being that you will miss important risks.

Next time around, try a structured technique. You will identify more risks. I promise.

Use both top-down and bottom-up Risk Assessments

Some companies rely on EITHER bottom-up OR top-down risk assessment techniques and miss out on the fact that both approaches deliver vital and often DIFFERENT risks.

Top-down risk assessment techniques (such as PHA or Task Analysis) can be done early in the development process without much knowledge about the actual design of the device. It is a great tool for early identifying use errors and probably misuse.

Once the device design is known, the selected design itself must be analysed for risks (such as materials used, geometry, movements and energy emittance etc.) through a bottom-up risk assessment. FMEA's are very popular and well designed for this purpose. Both these techniques complement each other and should be conducted by any serious medical device manufacturer.

Don't keep Design Controls and Risk Management in separate systems

Design drives risk. And Risk drives design. This will become apparent when you need to follow up on the implementation and verification of mitigations as well as the further analysis if mitigations introduce new risks. The glue between the design and the risks is the traceability. The effort of managing this traceability in a paper-based documentation system will be VERY high (those of you who have done it will nod now!).

So is applying software tools the solution? Not necessarilly, since proper traceability monitoring can not be done until the requirement management tool is integrated with the risk management tool (or vice versa). Only by automatically managing the traceability between the Risk Assessment Items and the Design Items, preferably in a single tool, can true trace monitoring be obtained.

Use reasonable probability and severity scales

I am glad to see a clear trend of tightening down the probability and severity scales during the risk evaluations. From previously having used up to 10 steps, the current trend tends towards five to six steps or less. People simply have a very hard time to judge whether a probability should be six or seven on a 1-10 scale and spend too much time pondering such questions. The option range is simply too large to be effective!

For the probability axis, I would like to endorse Dr. Johner approach of having each step representing 2 orders of magnitude. He explains this very well by saying, that apart from such a an approach lets the probability axis span over more than 8 order of magnitudes, "...the factor 100 indicates the precision which we can appreciate... If you ask a group of people, how long it takes (on average) for a hard disk to be defective, the estimates vary between 2 years and 10 years. But everyone realizes that this average is greater than one month and less than 10 years. And between these two values is about a factor of 100."

Make use of existing mitigations

In many cases, the risk assessment is carried out when the design is already known. In such cases: when coming up with mitigations for your identified risks, use the already existing mitigations in your current design!

I bet your current design already contains a whole bunch of design decisions that are risk mitigations without you really considering them as such. The absolute majority of design teams I have encountered are very, very good in designing innovative and safe devices. However, many of the design decisions taken are based on previous experience, industry state-of-the-art, or simply old habits having been refined over time. Since these engineer are often better designers than document writers, they simply do not see their design (often already in place) through the lens of risk management.

Bottom line: your current design already contains of an uncovered treasure of existing mitigations. Try to use your existing design as mitigations when performing your next risk assessment.

Aligned Elements, our medical device ALM, assists you in performing structured risk assessments. Its highly customizable risk assessment configuration can be set up for a large array of risk analysis variants. Should you be interested in a demonstration, contact us on This email address is being protected from spambots. You need JavaScript enabled to view it.

November 05 2018


In the beginning, there was the User Need.

According to FDA, the User Needs is the starting point for building a safe and efficient medical device. However, User Needs can be elusive to an engineering team used to rigid techniques and accustomed to having "full information" when approaching a problem.

bikeIt is rather rare that the developer has the real and deep experience a User has and it can therefore be precarious to leave the User Need elicitation process in the hands of an engineering team. Here are some tips for eliciting better User Needs.

Consider the Intended Use

It has been said 100 times before, but I say it again: start out by considering the Intended Use and Indication for Use.

These two items will tell you:

  • who is the device for (or rather, who do you say the device is for)
  • why (or for what) is the user using this device (or rather, for what you say the device is to be used for)

The whole idea here is to get as close as possible to the user and the situation in which the user applies the device. What medical condition is the device intended to address? Where and under which circumstances is device used? In a hospital or an ambulance? During the night? In the rain? By a child? By a blind person?

Answering these questions will put you in the shoes of the user and will let you describe the user's needs in his or her own words. Imagining being the user in the situation where the need for using the device arise will also give you an idea of the constraints facing the user at the time of application.

Thus, considering the "who" and the "why" is generally a more fruitful starting point than elaborating on the "how" (which is what engineers tend to do).

Who is the user?

In a majority of cases, a medical device is handled by more than one type of User during the products lify cycle. This becomes clear when considering non-core usage tasks such as:

  • transportation
  • installation
  • calibration
  • maintenance
  • service
  • decommissioning

How did the device arrive at the usage location? How and by whom was it deployed? Was it carried in a pocket? Was it transported by air? 

Apparently, it is important to consider all people involved with the handling of the device since these actions may have safety implications. Again, do not second guess the needs of these users but involve them in the process.

User Needs can be vague

Using fuzzy language (such as adverbs) when documenting requirements is a known bad-practice. However, User Needs may be written in a less prescriptive way if it capture important aspects of the User and the Usage. We know that, in the end, the Medical Device will end up being very concrete and void of any fuzziness.

The challenge thus lies in translating the potentially fuzzy language used in User Needs into concrete specifications in the Design Input Requirements and concrete Validation Tests. Make sure that the User Needs are well understood by the team deriving the Design Input Requirements and Validation Tests from the User Needs.

Not all input is User Needs

Costs, brand colors, production constraints are examples of important design input that are not necessarilly User Needs. I usually recommend my clients to add an additional Design Control type for Stakeholder Needs in order to pick up this input which definitely influences the design, although not always being required to be verified or validated.

When setting up the validation activities, you must be explicit about what you intend to validate and explicitly define the criteria applied to make this selection. By separating the input in the two mentioned Design Control Types makes it easy to explain which Design Controls are intended for validation (User Needs) and which are not (Stakeholder Needs).

Write User Needs with Validation in mind

The way User Needs are written will heavily influence the Validation activities. Since Validation is a resource intensive (and therefore expensive) activity, it makes sense to keep a close eye on the prognosed validation work that will be derived by a User Need when writing it.

If some of the validation activities are already known at an early stage, the team can use this knowledge to cleverly formulate the User Needs in a way to maximize the coverage of the known validation activities. By this, I do not mean that important User Needs should be left out but rather that formulating and structuring the combined User Needs can have a positive or negative impact on  the validation effort.

By following these simple guidelines, you should be able to get more bang for the buck next time you elicitate User Needs.

Aligned Elements, the medical device ALM, manages end-to-end traceability of all Design Control items, including User Needs, Design Input Requirements, Validation and Verification Testing. If you are interested in an online demonstration of Aligned Elements, let us know on This email address is being protected from spambots. You need JavaScript enabled to view it.

September 28 2018

Risk Management is a crucial part of Medical Device Development and if you are about to develop a Medical Device, you and your team are likely to find yourselves spending many hours compiling Risk Assessments.

There exist several techniques for performing a proper Risk Assessment but they all follow the same basic steps:

  • Define your risk policy (risk acceptance criteria)
  • Identify the Hazards through a structured analysis
  • Evaluate the Risks by estimating severities and probability
  • Mitigate the Risks that are not acceptable
  • Implement and verify the mitigations for effectiveness

To get you started, we have made two free Risk Assessment Excel templates available for download.

Download Free Risk Assessment Templates

The first demonstrates a Failuremode and Effect Analysis (FMEA) approach, a widespread technique used in many areas and industries. We often see it in bottom-up types of Risk Assessment.

The second one uses a Preliminary Hazard Analysis (PHA) approach which is an excellent top-down approach earlier in the design cycle where many of the design details are not yet known.

Both these techniques are available in Aligned Elements and we have compared and contrasted them in earlier posts.

August 27 2018

Requirements Management is strange. It is a well-researched area which each year yields an impressive number of articles, conferences and known best-practices. Still, this body of knowledge remains remarkably underused by the people who would gain from it most. In many of the organisations I encounter, well-established requirements elicitation techniques are simply not undertaken.

Perhaps this has to do with the deceivingly simple task at hand. "I just need to write down what the device should be able to do. How hard can it be?". Hard enough it seems, if one considers the many reports stating how mismanaged requirements leads to enormous costs down the line.

This is exactly what Prof. Dr. Samuel Fricker and his team has established in their paper "Requirements Engineering: Best Practices" (2015).

He concludes that although each and every one of the 419 participating organisations "...elicited, planned, analysed, specified, checked, and managed requirements...", very few of them apply formal requirement elicitation techniques.

For those who did "...only three techniques correlated with requirements engineering success: scenarios of system use, business cases, and stakeholder workshops."

The common idea with these techniques is to:

  1. bring structure into elicitation process
  2. involve many people into the discussion

Both parts are essential to success. Doing 1) without 2) misses out on critical knowledge in the organisation. Doing 2) without 1) is just wasteful. Personally, I have particularly good results from applying a variant of Use Scenarios called "Task Analysis / Task Risk Management" described by Andy Brisk. In short, this is a basic Task Analysis method, where processes are analysed step by step for requirements and risks.

Opposing the natural inclination of engineers to decompose a system into parts for analysis, this method focus on how you use the device, i.e. the system is decomposed into the scenarios where the user interact with the system.

In other words, we let use drive design.

Mr. Brisk lists a number of process examples which coincides well those applied to a generic medical device, such as:

  • Unpacking
  • Setup / Installation
  • Calibration
  • Start up
  • Daily Operation
  • Shutdown
  • Maintenance
  • Service
  • Alarms and Alerts
  • Decommission

If the found processes are too large to analyse, Mr. Brisk advices to decompose them further into manageable sizes.

Once the processes are identified, Mr. Brisk prioritizes the processes according to risk, in terms of:

  • Are there significant damaging consequences if the task is performed incorrectly? (High Severity of potential Harms)
  • Is there a reasonable likelihood that tasks will be performed incorrectly? (High Probability of Use Errors)

The idea of this risk-based prioritization is to focus on high-risk processes and analyse them early and thoroughly.

The processes are now analysed step-by-step, preferably by a group of people. They imagine and discuss the steps an imaginary user goes through to perform a task. How is the system accessed? How does the user communicate his intentions to the system and vice versa? What potential errors might the users make?

Task Analysis

Coloured post-it notes can be used to describe the steps on a wall. A tip is to use different colours for process steps and identified potential use errors. This approach manages to create both a common vocabulary of describing the system and its use, as well as creating a common understanding of how the device is meant to be used. It also tends to highlight areas where people had a different understanding of how the system should be used (by simply measuring the loudness of the discussion).

The Task Analysis described above is an easy and straight-forward way of eliciting requirements AND uncover high-level risks in a usage context. What makes it particularly suitable for Medical Device manufacturers is that it combines risk- and requirement elicitation in a single, common activity. Much too often, these two tasks are performed by separate groups in separate contexts.

A further bonus is that it intrinsically produces both Use Scenarios and Use Errors, which are substantial an essential parts of the Usability Management File.

Some important lessons learnt using this method includes:

  • Try to use a similar step granularity in all processes
  • Before starting, try to agree on what shall be considered "known" about the system
  • Define a clear Goal as well as Start and End point for each process in order to declare the scope
  • Be generous with risks, rather too many than too few
  • Do not forget to write down the elicitated Scenarios and Risks before you leave the room

Aligned Elements supports the documentation of Use Scenarios and their associated Use Errors as described above in our IEC 62366 Configuration. The Use Errors are applied in the overall High-Level Risk Assessment to drive further design decisions.

googleplus facebook