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:
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
- 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“ (https://github.com/johner-institut/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.
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:
- bring structure into elicitation process
- 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:
- Setup / Installation
- Start up
- Daily Operation
- Alarms and Alerts
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?
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.