{fastsocialshare}

Computer Software Validation is something we discuss a lot where I work. Since Aligned Elements is a Medical Device Quality Management System relevant software, our customers make sure that their Aligned Elements installations and configurations are validated.

It is a necessary activity, although not always perceived as bringing an awful lot of value. Sometimes the cost of CSV activities actually supersedes the cost of acquiring the software itself. 

I sometimes get the question if I know any best practices when it comes to Computer Software Validation and I have made a few observations from my CSV experiences. 

Let me tell you about the top 3 things that have an impact on the Computer Software Validation effort:

1) How many test cases do you perform?

It is dead simple. More test cases (note: not necessarily "more requirements") is more work. But do YOU have to perform all those test cases? What if the supplier has already verified them? 

You are very much allowed to leverage existing supplier documentation and testing records. A properly conducted Supplier / Vendor assessment can lead you to the conclusion that the suppliers' verification documentation suffices. Remember that the risk we are trying to mitigate with a Computer Software Validation effort is primarily about patient safety. A software like Aligned Elements is not directly involved in patient safety and this fact can be leveraged when assessing and deciding on the validation scope. 

2) How do you record the test results?

The bulk of the CSV work resides in performing and recording the test results. The way you record those results can have a significant impact on the overall effort. In order to record that the actual behavior of a test step corresponds to the expected behavior, is it enough to tick a box (passed/failed)? Or do you need to write a text? Or do you need to make screenshots? As you can imagine, there is a huge difference between the former and the latter.

"But are we not required to take screenshots?".  The short answer is "No, you don't". Not if you do not think it proves anything more than the tester checking a box. FDA requires you to select your own methods and tools for quality assurance. If you have a good case for not making screenshots (which I think you have), you do not have to.

3) Who (and how many) has to sign all these CSV documents?

This might sound a bit odd but more than once I have run into cases where the validation is completed and everything that is missing is a signature from some top management figure. And now we run into a buy-in problem. If this guy has not been involved CSV approach and suddenly disagrees with how it was conducted ("BUT THERE ARE NO SCREENSHOTS?!?"), it can have a significant impact (significant as in "redo the validation").

So the lesson here is to get early buy-in from the people that sign the document. On a general level, reducing the number of signatures will speed up any documentation process. And you might want to contemplate the necessity of having the IQ, OQ, and PQ plans/reports in different documents (more documents to sign) or if you can combine them.

Validating Aligned Elements

When you acquire Aligned Elements, you get free access to our internal verification documents to use in your vendor assessments as well as pre-filled Validation documents to kick-start your validation. Contact us for more information at This email address is being protected from spambots. You need JavaScript enabled to view it.

What's up ahead regarding Computer Software Validation?

FDA announced that their much anticipated "Computer Software Assurance for Manufacturing, Operations, and Quality System Software" draft guidance should be out in 2019 but now it seems like it has been postponed to 2020. The new guidance is supposed to use a more agile approach, including a risk-based and value-creating perspective on CSV activities.

 {fastsocialshare}

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“ (https://github.com/johner-institut/it-security-guideline/) and is a recommended read for everyone concerned with Medical Device cybersecurity. You can also download Excel files with the requirements from the Johner Institute website.

We have made the Product IT Security Requirements available as a 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 explain the rationale and context for some of the requirements.

{fastsocialshare}

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 exist 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 misuses.

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 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 necessarily, 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 judging whether a probability should be six or seven on a 1-10 scale and spend too much time pondering such questions. The range of options is simply too large to be effective!

For the probability axis, I would like to endorse Dr. Johner's approach of having each step representing 2 orders of magnitude. He explains this very well by saying, that apart from such 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 at 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 engineers 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 at This email address is being protected from spambots. You need JavaScript enabled to view it.

 {fastsocialshare}

In the beginning, there was the User Need.

According to FDA, the User Needs are 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.

It 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 the device being 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 arises 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 product's life 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 captures 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 necessarily User Needs. I usually recommend to my clients that they add an additional Design Control type for Stakeholder Needs in order to pick up this input which definitely influences the design, although it is not always 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 proposed 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 than 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.

{fastsocialshare}

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.

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.

{fastsocialshare}

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 lead to enormous costs down the line.

This is exactly what Prof. Dr. Samuel Fricker and his team have 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 the elicitation process
2. involve many people in 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 interacts with the system.

In other words, we let use drive design.

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

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

If the found processes are too large to analyse, Mr. Brisk advises decomposing 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 and essential parts of the Usability Management File.

Some important lessons learned using this method include:

• 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 Endpoint 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.

{fastsocialshare}

That medical device development entails a lot of documentation should not be a surprise to anyone. Hundreds of documents are created, reviewed, released, then modified, reviewed, and released again. The majority of these documents need to be signed, often by two persons or more. Collecting signatures, although it seems like a trivial task, becomes a significant nuisance when the number of documents and releases increases.

One of our customers insisted on having 3 people sign each test case before release. Their 18 000 test cases yielded a combined signature collection effort of 5 man-years (estimated 30 mins to collect a single signature, their estimation).

It is rare to find medical device manufacturers that enjoy writing medical device development documents, but it is even rarer to find those who gladly spend their days collecting signatures for the said documents.

The obvious question is hence: how can we spend less time on document signatures?

For many medical device manufacturers, the equally obvious answer seems to be electronic (or digital) signatures.

So why is it so hard to get a signature?

There are several potential reasons for this. Maybe the Signer is a very busy person and simply has no time for this task. Maybe the Signer is located somewhere else through work, traveling, vacation, or other reasons. Or perhaps the previous Signer did not pass on the document to the next Signer in line. Or maybe a formal signature sequence (order) is forced by the document process in question, where a Signer that actually is available, is prevented to carry out the task since some Signer further up the signing sequence has not fulfilled hers. Or it might be that the document in question cannot be signed before some other related document has been released (i.e. signed).

Thus, there can be formal reasons but also trivial reasons why a signature does not get timely collected.

The most trivial is of course that it is just hard to physically get the document in front of the Signer (or the other way around) for some reason or another. Once you get that far, the literary "stroke of the pen" is usually a quick affair. This is the perceived major efficiency benefit of Electronic Signatures. You do not have to physically get the document in front of the Signer. The document does not need to get passed around. The Signer can pull it up (from an E-Signing System) whenever he wants, from wherever he is. This allows a quasi-parallel execution of signatures. Two people on different sides of the planet can sign the same document at the same time (almost)! Costs associated with printing, sending, scanning, and storing the paper copy are eliminated. E-Signatures also entail increased measures of security, enhanced authenticity, resisting tampering, and also provide accurate signature audit trails.

Before explaining how to introduce an E-Signing System, let me say a few words about Digital and Electronic Signatures.

Digital and Electronic Signatures

Even though the terms are often used interchangeably, there are some notable differences between the two concepts.

According to FDA, Electronic Signatures are "Compilation of data (user name/password, dongles, biometric)", which is unique for a person. This can be used to sign documents and is as legally binding as a “wet signature”. The signature and the association with the signed entity (document) are stored in a database of the Signature System. Furthermore, not all E-Signing Systems leave a visual mark on the signed document that indicates that it has actually been signed.

Digital Signatures, on the other hand, require a Digital Certificate that ensures the identity of the signer. A part of that Digital Certificate gets embedded in the signed document during the signing process. As a result, the validity of the signature can be checked independently of the E-Signing System.

So, someone needs to guarantee the identity of the signer.

For Electronic Signatures, the organisation (the manufacturer) does this by using the validated E-Signing System.

For Digital Signatures, it is the issuer of the Digital Certificate that ensures the identity of the signer. Digitally signed documents often also contain a visible signature.

Obviously, there seem to be several advantages to using Digital Signatures. The validity of the signed document can be inspected independently of the E-Signing System, which is an advantage if the E-Signing System goes down, is corrupted or the system vendor goes bankrupt.

Any drawbacks?

Yes, a few. Obtaining a Digital Certificate from a third-party vendor is expensive and requires an administrative effort. There is the obvious question of where and how to store these certificates as well as associate them with the user. They also have the nuisance to expire after a while and therefore need to get regularly renewed. People also have a tendency to marry and change their names etc. which also leads to renewals. Furthermore, it is not guaranteed that the validity shows up correctly in third-party viewers (like Acrobat PDF Reader), for technical reasons having to do with root certificates.

An organisation can circumvent all this by issuing its own Digital Certificates. This is somewhat of an IT "adventure" but it can be done. Costs can then be lowered somewhat but there is still a significant administrative effort. Moreover, internally generated Digital Certificates can of course not be validated by third-party viewers (like Acrobat PDF Reader).

So, there are pros and cons with both options.

However, they have several similarities, and most important of all, both methods are recognized by the FDA.

Let's do E-SIgning!

Let's say we want to engage in eSigning (Electronic or Digital). What kind of effort can we expect to get this up and running?

Here is a shortlist of some of the steps:

• Assess the E-Signing System for Part 11 / Annex 11 compliance
• Qualify the E-Signing System Vendor as Supplier according to your QMS
• Assign responsible roles and people for the E-Signing System
• Install and configure the E-Signing System
• Make or buy the Digital Certificates (if used)
• Adapt your QMS to recognize E-Signatures and describe how they are intended to work
• Prepare all the Document Templates to be used for eSigning (the system needs to know where in the document the signature shall be placed. Page nr, location on the page, margins, and spaces, etc).
• Validate the E-Signing System
• Create E-Signature User Guidelines and train all users in how to use it
• Notify the FDA (which is compulsory)

There is thus a non-neglectable initial effort to set up the E-Signing System, and also an effort to keep it maintained, both from a process as well as from an IT perspective.

There are also several other things to consider before you decide to go down the Electronic Signature path:

Document Life Cycle

All documents have a life cycle and the signing is only a very small part of this process. You need to consider how the document gets into the E-Signing System, how it interfaces with other systems such as Document Management Systems, workflow engines, or e-Forms of which the document may be a part.

You also need to pay attention to how you plan to archive the electronic documents. This might seem like a trivial question but it is more depth here than you think.

External Users

If external users (as in external to your organisation) are going to use the system, you need to prepare a process where they get access to the E-Signing System, including setting up a corresponding user in the system with the appropriate Digital Certificate if applicable. These external users also need to get trained in how to use the system.

Hybrid Signature Situations

Are you going to end up with documents that are partly signed electronically and partly with traditional "wet signatures"? If so, you need a described process for this as well.

Ownership

Last but not least you need to establish who has the ownership of the E-Signing System. Is it the IT Department that usually acquires and maintains IT systems? Or is it the R&D department that probably is the most frequent user of the system? Or is it the HR department that is concerned with the identity of the people working in the organisation? This needs to be clarified before you start.

Predicted Outcome

As mentioned, an E-Signing System will decrease the effort of placing the document in front of the Signer. It will reduce costs associated with transporting the paper copy of the document. It will also potentially increase the security and authenticity of the documents.

But there are things an E-Signing System cannot do. Regardless of how deep you entrench E-Signatures as a paradigm in your organisation, you will almost inevitably have a residual number of documents that are signed with ink. Thus, no matter how much you push E-Signatures you will end up with a hybrid system, composed of documents signed electronically and documents signed with ink. Be prepared for this.

Then, a Signature System is per se an IT system with all the work it entails. It needs to be validated and maintained, people will repeatedly forget their credentials if they do not use the system frequently and there will be ubiquitous bugs and errors. This all means increased costs that need to be compared and contrasted with the costs by using a manual system.

Finally, an E-Signature System does not make bad processes good just by digitizing them. Overloaded employees will still remain overloaded regardless.

For which situations does E-Signatures make sense?

E-Signatures make sense when signing is a routine operation i.e. when a user makes several signings per week. E-signing for the occasional (or maybe even singular) CEO signature on a Product Requirements Document does not warrant the effort.  

Document types that are well suited for E-Signatures are those that exist in many instances and that have a comparably small amount of actual content (as in "quick to read"). Examples of such document types are time reports, expense reports, purchasing approvals, and test case documents.

Last but not least, maintenance is of course made easier if all Signers are part of the organisation (as opposed to involving multiple external users).

Efficient with and without E-signatures

If you find it cumbersome to collect signatures today, there are several ways you can scrutinize your organisation for efficiency improvements.

Analyse current signing process

Are all these signatures really necessary? Ask yourself why they were added ("It is required by our process" is not a valid answer) and most importantly, what does the particular signature mean? In what way does a particular signature make the document "better"?

Don’t get dependent on busy Signers

The overloaded Project Manager or CTO that never has time for signing is a common bottleneck in many organisations. Appoint deputies to all signing functions (the deputies shall also have deputies). Try to avoid sequentially forced signature sequences. They cost more than they bring. Finally, simply planning the signing occasion like a regular meeting (set up a meeting in the calendar) might yield some good results.

I hope this post has highlighted some of the pros and cons of employing Electronic Signatures. If there is anything I want you to take home it is probably this:

• Signature efficiency stands and falls with the process, not the system
• Analyse and improve the process first!!
• E-signatures can be very beneficial in specific situations
• E-signatures gains (i.e. speed gains) must be weighed against costs

Aligned Elements supports electronic as well as digital signatures of documents with automatic relaying to external Document Management Systems.

If you would like to get a demonstration of e-Signatures in Aligned Elements, just let us know.

{fastsocialshare}

Test managers often have to deal with superhuman juggling of timelines, resource allocations and continuously changing specifications while facing increasing pressure from management as the shipping-date draws closer. Furthermore, the test manager is responsible for making sure that the traceability is completed, that test data integrity remains intact, and that change management procedures are followed correctly, even under situations of extreme stress.

Efficient change management, planning, tracking, and reuse of test executions are therefore much appreciated tools in the V&V Managers toolbox. The Aligned Elements Test Runs aims to address these challenges. The Test Runs manages the planning, allocation, execution, and tracking of test activities. Let's dive into the details.

Planning the Test Run

The Test Run Planning section is the place to define the Test Run context, much as you would write a Verification Plan.

The Test Run Planning information includes:

• What to test i.e. information the Object Under Test and the addressed configurations
• When to perform the tests i.e. the planned start and end date for the Test Run
• Who participates in the test effort i.e. the team of testers and their allocated work
• How to test the device i.e. which test strategy to use by selecting among the existing test types
• Why the test is being done i.e. the purpose or reason for performing this particular set of tests on this Object Under Test

Allocate existing Test Cases from your Test Case library to the Test Run by using simple drag-and-drop. You can use any number of tests of any available types from any number of projects. If needed, add Test Run specific information to the Test Cases and designate the Test Cases to the members of the Test Team.

Once the planning phase is completed, the Test Execution can begin.

The Test Execution phase 

Test Case data is kept separate from the Test Execution result data, permitting a high degree of test case reuse and a clear separation between Test Instructions and Test Results.
Consistency checks are optionally carried out on the Test Case before execution in order to ensure that tests cannot be performed until all foreseen process steps are completed.
During execution, the test input data is optionally kept read-only, preventing testers to modify a reviewed and released Test Case during execution.

All Test Team Members can access the Test Run and simultaneously Execute Tests as well as continuously monitor how the Execution phase progresses.

Real-Time Test Execution data is presented through:

• Individual Test Execution results including any found defects as well as colour-coded feedback on states
• Colour coded test progression statistics, with the possibility to drill down on e.g. individual Testers or Test Types
• Burndown charts, showing how planned Test progress over time corresponds to the actual progression

Defect Tracking

During Test Execution, Defects and Anomalies can be created and traced on-the-fly without having to leave the Test Execution context. The Defects can be tracked in either Aligned Elements internal Issue Management system or already existing integrated Issue Trackers such as Jira, TFS, GitHub, Trac or Countersoft Gemini or any mix of these systems. Created Defects and their corresponding status are displayed in the Test Run.

Test Case Change Management

When developing medical devices, it is of paramount importance to keep your Design Control under tight change control.
The Test Run assist the testers and test managers in several ways to accomplish this goal, including optional actions:

• Preventing inconsistent tests from being executed
• Preventing input data to get modified during test execution
• Allowing Test Managers to lock/freeze Design Input and Tests during execution
• Alert testers when attempting to modify tests for which valid results already exist
• Signalize whether a Test Case has been reviewed and released or not
• Allowing the user to explicitly invalidate existing test results when a test is updated with major changes

Testing Variants of the Object Under Test

If several variants of the Object Under Test exist, it is sometimes desirable to create variant-specific test results for common test cases and subsequently create separate traceabilities for the variants. The Test Run uses a concept called "Configurations" to achieve this behaviour. A Test Case is executed for one or more Configurations to make sure that variant-specific test results are kept separate.

The exact data composition of a Configuration is customizable to fit the needs of each customer.

Complete the Test Run

Once all Test Cases has been completed, the Test Run and all its content is set to read-only. Optionally, a Snapshot of all Test Run relevant items is created as part of the completion procedure. A Test Run report containing all the necessary Test Run information can be inserted into any Word Document using Aligned Elements Word Integration with a single drag and drop action.

The Test Run is a Test Managers best friend, providing the flexibility needed during test planning and full transparency during test execution, making it possible to quickly react as real-time test events unfold.

_{Note: Burn Down Charts is under development at the point of writing and planned to be released in the next service pack.}

{fastsocialshare}

The medical device as a stand-alone product is a waning concept.

The desire to make use of the information collected in a medical device in other health systems, coupled with recent advancements in networks and interconnectivity has resulted in more devices being connected to the Internet. As a consequence, they have become more vulnerable to hackers.

A 2015 KPMG survey found that 81 percent of health care organizations had their data compromised within the previous two years.

FBI reports (FBI Cyber Division PIN (Private Industry Notification) #140408-010) that due to the transition of paper to electronic health records, lax cybersecurity standards and higher financial payout for medical records in the black market, the "cyber actors will likely increase cyber intrusions against health care systems". 

During 2016, several ransom-attacks were launched against health institutions in the United States with wide-ranging consequences. 

FDA has shown heightened interest in cybersecurity issues and released three guidelines during the last two years. Medical Device manufacturers are likely to focus more on cybersecurity risk management activities in the near future and assign additional resources accordingly.

One integral part of the cybersecurity risk management process constitutes the risk assessment.

Performing risk assessments is a core activity in the medical device industry and many of the available techniques are well-known and well-used by industry professionals. Having long and thorough experience of risk management might lead the same professionals to believe that cybersecurity issues can be harnessed by the tools already at hand.

There are, however, key aspects where cybersecurity risks differ from traditional medical device risks.

Risk identification and the building blocks of a cybersecurity risk

The fundamental challenge during risk identification is to ensure that all relevant risks have been identified.

Verifying that this criterion has been fulfilled is often difficult and therefore structural help and practical advice is very welcome.

Due to the wide variety of possible medical device types, ISO 14971, the standard for medical device risk management, understandably has a hard time defining concrete identification techniques that are relevant enough to provide value for every kind of medical device. 

IT risk management, operating in a narrower technical scope, provides a host of techniques, tailored to this domain. Many of these techniques are based around the asset-vulnerability-threat model. 

These components can be described as followed.  

• Assets are the entities a cyber-intruder attempts to access and control. An asset has a value to the patient and therefore also to an intruder. In a safety-related context, we can exemplify assets as device configurations, health data, medical device functions, or battery power.
• Vulnerabilities represent weaknesses in the medical device that, when exploited, can give an intruder access to an asset. Software bugs, application design flaws, and insufficient input validation are examples of software vulnerabilities. But vulnerabilities can also be found in hardware, business processes, organizational structures, and interpersonal communication.
• A threat is defined as an event with the potential to an adverse impact on an asset. The threat is executed by a threat agent (i.e. an intruder) exploiting a vulnerability in order to access an asset.

A combination of these building blocks describes a cybersecurity risk. 

As a starting point, the manufacturer should be able to enumerate assets for the given device. By analyzing how these assets can be targeted, e.g. by performing a “Threat modeling analysis”, using a data flow analysis of the application, identifying "data-at-rest" (data storage) and "data-in-motion" (data transfer) will further help the manufacturer to identify vulnerabilities and threats, particular to the medical device.

Bottom-line: Identifying assets, threats, and vulnerabilities will support the manufacturer when enumerating potential cybersecurity risks. The identified items should be listed in the risk management documentation.

What is the probability of a cyber attack?

The Medical Device industry takes its risk assessment cues from ISO 14971, which defines risk as the combination of the probability of the occurrence of harm and the severity of that harm. 

The computer security industry, on the other hand, has used several kinds of assessment methods to estimate the "riskiness" of cybersecurity risks. None of them rely solely on the probability and severity of an event. Instead, these techniques estimate and/or quantify aspects of the assets, threats, and vulnerabilities that in combination say something about the computer security risk. 

So how can the medical device risk assessment methods concerned with the safety of patients be connected with techniques whose primary concern is information security?

In the AAMI paper "TIR 57 - Principles for medical device security - Risk Management", the authors address this discrepancy and attempt to transpose the cybersecurity line of thinking into the domain of ISO 14971. 

It is easy to see how the "potential adverse effect" can be regarded as analogue to the “Harm” in ISO 14971 and be quantified with a corresponding severity.

The probability factor in ISO 14971 does not have a direct equivalent in the cybersecurity risk domain. A composite factor called "exploitability" combining characteristics of the vulnerability, the threat agent, and the medical device itself is mentioned in the FDA guidelines. This factor intends to indicate the amount of work involved in order to invoke a successful attack.

The AAMI TIR57 group suggests a two-pronged approach to establish something similar, combining two likelihood factors.

The first factor, the “Threat Likelihood”, defines the likelihood of the threat agent having the motivation, skills, and resources to exploit a given vulnerability.

The second factor estimates the likelihood of harm being the effect of an exploited vulnerability.  These two factors in combination make out the probability of the cybersecurity risk.

Note that this approach is similar to the P1 (probability of the hazardous situation occurring) / P2 (probability of the hazardous situation causing harm) frequently used in the medical device community.

Information security theory recognizes that aspects and characteristics of the threat agent, the vulnerability, and the device itself drive these factors.

Bottom-line: caution shall be taken when estimating probability/likelihood/exploitability for cybersecurity risks. The manufacturer's Risk Management SOP shall address this concern accordingly and be adapted if necessary.

The drivers of cybersecurity risks

During classic medical device risk assessments, the identified causes leading to hazardous situations and potentially to harms are in most cases accidental. Although malicious use should be considered, this area often receives considerably less attention than harms caused by accidental events. 

For cybersecurity risks, the opposite is true. Here, a significant factor in the causal chain constitutes the intentional behavior of a threat agent causing harm by exploiting a vulnerability.

Whereas the software flaw might have been created accidentally, exploiting it is an intentional act.

A malicious agent may come in many shapes and forms, such as a criminal organization, a competitor, or disgruntled employees. Each of these has its own motivation, skill set, and reach when it comes to detecting and exploiting vulnerabilities, which affects the likelihood of a vulnerability being exploited as we have seen above.

Therefore, not only needs the focus to be shifted from accidentally caused risks to intentionally caused risks. The manufacturer benefits from analyzing the characteristics of the malicious intruder in order to do a proper risk assessment.

Bottom line: Manufacturers will need to shift perspective from accidentally caused risks to explicit maliciously caused risks during the identification and classification of the risk assessment.

The poisoned SOUP

Just like in the rest of the software industry, medical device companies use third-party libraries to increase productivity when developing medical devices.

These third-party libraries (or frameworks or applications), sometimes referred to as "SOUP" components (Software of Unknown Provenance) are of course also subject to cybersecurity scrutiny.

It is debatable if third-party components, and in particular open source components, are inherently more unsafe than proprietary produced applications (there are several arguments against such claims).

Regardless of this claim, it can be safely assumed that many of these libraries were not developed with a medical device cybersecurity context in mind. The security firm “Contrast Security” reports that 26% of downloaded SOUP:s contained known vulnerabilities and were still applied.

It shall be noted that SOUP:s themselves often rely on and integrate third-party software, which increases the scope of the problem accordingly.

The medical device manufacturer is responsible for any vulnerabilities caused by SOUP:s in his device and must therefore analyses his SOUP:s accordingly.

This shall include a systematic inventory of SOUP:s, actively collecting information on current vulnerabilities in SOUP:s as well as applying timely updates of the SOUP:s when available.

Bottom-line: The manufacturer must have a clear plan for how to handle potential cybersecurity risks in SOUP:s. 

Skills required to assess cybersecurity risks

Cybersecurity vulnerabilities are largely made up of software flaws. Understanding the technical details of how such vulnerabilities come into being, the technical influence they have, and how they can be mitigated requires precise software knowledge. Including software developers in the assessment group is, therefore, a highly recommended measure.

It is a misconception that all software professionals are software security professionals. The majority of today’s information security problems can be traced to flaws in code. Many software developers lack basic training and understanding of cybersecurity. 

As already mentioned, the security scope for an interconnected medical device is much larger than the device itself. The network infrastructure in which connected medical devices operate is often outside the control of the medical device manufacturer but still has a great impact on the overall risk exposure and needs to be included in the risk assessment.

It is likewise a misconception that cybersecurity is a strictly technical field. Cybersecurity vulnerabilities are not exclusively found in hardware and software but also in business processes, organizational structures, human behavior, and the environment in which the device operates. A thorough understanding of where, how, and by whom the medical device will be operated is therefore important input for the risk assessment.

Last but not least, the clinical experts are required for estimating the potential harm of compromised availability, confidentiality, and integrity of the associated data.

All these competencies are required in order to perform a comprehensive cybersecurity risk assessment and it is clear that it stretches beyond being an internal R&D activity.

The risk assessment benefits from involving stakeholders beyond the immediate software development team. If specific cybersecurity expertise is lacking in the organization, the manufacturer should consider employing or train their own experts or outsource these functions to a competent partner.

Bottom-line: the knowledge required to perform a medical device cybersecurity risk assessment is both broader and deeper than what is often immediately available in many medical device companies. 

Conclusion

The medical device industry has extensive experience with risk management and risk assessment techniques.

The cybersecurity dimension of medical device development is an additional aspect where risk assessments can enhance safety.

However, traditional medical device risk assessment techniques need adaptation in order to successfully be applied to cybersecurity risks.

Cybersecurity risks consist of other aspects and other drivers than "classic" medical device risks and are best mitigated by recognizing these differences.

{fastsocialshare}

One audit to rule them all. 

Sounds good, doesn't it?

If you have spent a lot of time in audits lately, then you are certainly not alone. More and more company resources are devoted to a continuous string of auditing activities. The Medical Device Single Audit Program is an initiative by the IMDRF intended to curb the audit avalanche.  

But does the promise hold? Or is it too good to be true?

Read this inside story from a recent MDSAP audit experience.

{fastsocialshare}

You spend too much time and money on documentation.

Agreed?

Good.

So what is your plan?

The regulations of the medical device industry require us to produce a pretty hefty chunk of documentation to show that the device is safe and efficient. If the documentation is not compliant, then it does not matter how safe, secure and performant the device itself it. Therefore, the documentation aspect that receives the largest share of attention is compliance. The most common path to a compliant stack of documents is to throw heaps of man-hours at the problem. Quantity seems to be the weapon of choice in many firms.

As a consequence, a large number of people get involved in the documentation creation and maintenance, especially people residing in the R&D part of the organization as most companies do not have Document Officers or documentation experts in their organization.

However, engineers and scientists are not necessarily the best writers (And they probably have no ambition to be.) Staff who are necessary for other tasks struggle to find the time to write these documents, and so the documents they do produce may be of lower quality than their usual work.

The effect on these people is often a suffocating feeling of inefficiency and frustration of spending an un-proportionally large part of the working day on menial documentation tasks, deciphering SOP:S and unpractical standards to compile documents that no-one reads (apart from the auditor).

Our studies show that up to 30% of the total project effort is spent on documentation required by regulations. There is also an overwhelming consensus in the industry that this is far too much. Money and time are inefficiently spent and morale buckles as the workload increases.

The good news is that these problems can be fixed. The bad news is that you are going to lose time, money, and people until you fix them.

Excelling at documentation efficiency is not intuitive to many R&D-centric organizations. However, considering the situation described above, good documentation practices is an investment. In the medical device industry, it is even a competitive dimension.

Your company can be efficient!!

Some good starting points are:

• Make documentation efficiency a prioritized objective using measurable goals
• Assign a responsible Manager
• Set up a tight collaboration between the people writing templates and SOPs (Quality people) and the people using the templates and SOPs (R&D people)
• Analyze your documentation processes
• Apply the right software tools to automate documentation tasks

You can start right away!

Download our Medical Device Documentation Self-assessment paper and take a few minutes to complete it. We assure you that you will have started the road to more efficient documentation within the next 15 minutes!

{fastsocialshare}

The Swiss Medtech Industry Sector study surveyed more than 340 medical device companies in this year’s SMTI industry study, uncovering the current opinions and views in the Swiss Medtech market.

The study claims that "the ever-increasing quality and documentation requirements" and the difficulty to "preserve innovative capacity" are the primary challenges to remain competitive in the current market.

For those of us working in the industry for some time, this does not come as a surprise.

Knowing the dynamics operating in medical device development, it is obvious how these two challenges inter-relate. How is it possible to sustain a competitive and innovative R&D program when more and more of the development effort is devoted to satisfying regulatory and documentation requirements?

Our own studies show that up to 30% of the total medical device development effort is spent on documentation tasks. As in many other industries, the digitalization of processes offers some prospects of streamlining the medical device documentation burden.

Our users say that significant efficiency improvements can be done by applying the right tools. Download your free copy today or ask us for a free online presentation.

{fastsocialshare}

The imminent update of the EU MDR and IVDR regulations has serious effects on Notify Body access. The result might be an increase in company value of manufacturers for second-rate products.

Read the full article here.

Generating the medical device development documentation making up the products' Design History File stands for up to 30% of the total development effort. Putting in these substantial resources ought to provide top-notch quality and very few errors in documentation.

Still, Documentation not available, or Documentation not adequate are frequently cited deviations in FDA Warning Letters. 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.

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.

This combination of large volume, frequent changes and a high level of document interdependencies make it impossible for any single employee to get a comprehensive view of the current documentation consistency at a particular point in time.

This is where automatic checks by a dedicated computer system really help out. To illustrate this point, let us share some insights from a medical device manufacturer that ported existing Design Control documentation into our Medical Device ALM Aligned Elements and analyzed it using the automatic consistency checks.

Seeing is believing

"We found inconsistencies in the areas of design control structure, missing and inadequate traces as well as formal aspects of the risk management." says the responsible engineer. "We knew about the problem with the risk management and did not have too much confidence about the traces, but the other inconsistencies were new to us".

Applying the sort of systematic, automated analysis and support a tool can offer, not only unveils gaps in the documentation. It also makes deviations from formal documentation requirements explicit. "In the past, we did not work with a tool and then you have more freedom to find solutions, which in themselves are not wrong per se, but at the same time may be a bit outside of the ideal structure." he continues. "As time goes by, these design control documents are modified and deviates further and further away from the ideal structure."

This is a typical way in which inconsistencies undetectably find their way into the documentation. No up-front errors are committed, but over time, the collective aggregation of minor, grey-zone adaptations undermines the overall documentation coherence. In the end, the consistency of the documentation is unknown and the confidence in the work deteriorates.

"We might have underestimated the benefit of adhering to a clear documentation structure. At the moment, we know that we have structural points to fix. When this is done we can focus on the content. I am confident that, in the end, it will be easier to defend the documentation when the formal aspects are not in question.", concludes the customer.

{fastsocialshare}

FDA keeps pushing the topic of the importance of Human Factors and Usability Engineering, trying to maximize the likelihood that new medical devices will be safe and effective for the intended users, uses and use environments. 

The FDA's draft guidance List of Highest Priority Devices for Human Factors Review, issued in February 2016, enumerates a number of device types where human factors data should be included in premarket submissions. This draft guidance is currently under review. The submitted Human Factors Review data should include a report that summarizes the human factors or usability engineering processes they have followed, including any preliminary analyses and evaluations and human factors validation testing, results and conclusions. 

• Ablation generators (associated with ablation systems, e.g., LPB, OAD, OAE, OCM, OCL) OCL)
• Anesthesia machines (e.g., BSZ)
• Artificial pancreas systems (e.g., OZO, OZP, OZQ)
• Auto injectors (when CDRH is lead Center; e.g., KZE, KZH, NSC )
• Automated external defibrillators (e.g., MKJ, NSA )
• Duodenoscopes (on the reprocessing; e.g., FDT) with elevator channels
• Gastroenterology-urology endoscopic ultrasound systems (on the reprocessing; e.g., ODG) with elevator channels Hemodialysis and peritoneal dialysis systems (e.g., FKP, FKT, FKX, KDI, KPF ODX, ONW)
• Implanted infusion pumps (e.g., LKK, MDY)
• Infusion pumps (e.g., FRN, LZH, MEA, MRZ )
• Insulin delivery systems (e.g., LZG, OPP)
• Negative-pressure wound therapy (e.g., OKO, OMP) intended for use in the home
• Robotic catheter manipulation systems (e.g., DXX)
• Robotic surgery devices (e.g., NAY)
• Ventilators (e.g., CBK, NOU, ONZ)
• Ventricular assist devices (e.g., DSQ, PCK)

According to the FDA, these devices were selected because they have clear potential for serious harm resulting from use error.

However, for device types not on the list, the guidance is very clear that submissions should contain human factors data if analysis of risk indicates that users performing tasks incorrectly or failing to perform tasks that could result in serious harm. This is a strong indication on that, regardless of device type, Human Factor engineering, Usability Engineering and the documentation of detected and mitigated risks caused be Use Errors will receive increased by the agency in the future.  

The Aligned Elements IEC 62366 configuration is available for download in our extension library.

For a live demonstration of the Aligned Elements IEC 62366 configuration, please This email address is being protected from spambots. You need JavaScript enabled to view it. to set up an appointment.

{fastsocialshare}

Sometimes when I ask development teams about their Software Unit verification, they fire up Nunit (or MSUnit or some other unit test tool) and say “Look here, we have more than 1800 unit tests with a test coverage way over 70%! Regarding Software Unit tests, we are certainly well covered!”

It is obvious to readers that the guys who wrote IEC 62304 explicitly tried to stay away from established software notions. You don’t see any “components”, “classes”, “modules”, “diagrams”, “dlls” or “objects” in the text (at least not in the English version). The authors did this on purpose in order to stay out of the nitty-gritty details of software development, to not make any technical prescriptions, and avoid a minefield of interpretations of concepts existing for decades. 

That’s why the norm speaks of software development in tech- and methodology-neutral terms. We have “architecture”, “items”, “interfaces” and “versions”. And, unfortunately, “units”.

This is just about the only notion where there seems to be confusion. Maybe not about units per se, but certainly about “Software Units verification”, which in some companies is translated to “Unit Testing”.

What is a “Unit”?

Unit testing was popularized by the practice of Test Driven Design and extreme programming in the late ’90s. JUnit was the first xUnit testing framework getting widely used and the concept was reused for other development stacks. The xUnit testing frameworks have since then evolved and are today widely used for automated testing in many industries, including the medical device industry. Over time, the frameworks have become increasingly versatile and are today used far beyond the original scope of classical unit testing. 

IEC 62304 defines the Software Unit as a Software item “not subdivided into other items”. According to the standard, it is up to the manufacturer to decide the granularity of items and therefore also the criterion for divisibility, making the definition somewhat arbitrary. Members of the medical device community have through lengthy discussions tried to agree on a practical interpretation of what a "Software Unit" is. Suggestions include:

• Class
• File
• Package
• Namespace
• Module

Unfortunately, there seems not to be a commonly accepted definition. This leaves us, the implementers of the standard, with much freedom and little support. 

Regardless of the manufacturers' definition of the “Software Unit”, the standard does require the unit to be “Verified”. Again, the IEC 62304 leaves it up to the manufacturer to define according to which acceptance criteria and through which means the verification shall be conducted.

Note that the verification of a Software Unit does not necessarily have to be a test (depending on the software safety classification). The verification strategy can be a walkthrough, inspection, review, results from static testing tools, or anything else that is valid and appropriate for the Software safety classification of the unit. Furthermore, the verification strategy, methods, and acceptance criteria are permitted to vary from Unit to Unit as long as this is appropriately documented.

Let’s now move the focus from the definition of a “Software Unit” in IEC 62304 to the definition of a “Unit” in classical "Unit Testing". Wikipedia suggests several definitions (which are all variants of the word “small”) but concludes that at the business end of unit testing, we find a piece of code that can be tested in isolation. This is in general a much finer level of granularity than "Software Units" in IEC 62304. Whereas a “Software Unit” in IEC 62304 is an architectural building block, a “Unit” in Unit Testing is simply something that can be tested in isolation with no explicit relation to the software architecture.    

Thus, summary so far:

1. A “Unit” as in Unit Testing is not the same thing as a “Software Unit” in IEC 62304.
2. A Test being executed in a xUnit Testing Framework does not automatically make it: 
   1. a classical Unit Test
   2. a Software Unit Verification.
3. A Software Unit can be verified by other means than tests (depending on the software safety classification).

 “But I really want to use my xUnit Tests for Software Unit Verification! What do I need to do?”

It is of course entirely possible to use unit tests run by an xUnit Testing Framework (or manually if preferred) as a verification method for Software Unit. However, the tests themselves are only a part of the required deliverables. Be careful to:

• Document the test strategies, the test methods, and the procedures used.
• Evaluate the procedures for adequacy and document the results.
• Establish and document acceptance criteria (more rigid for class C than A and B, see IEC 62304)
• Perform the tests and document the result.
• Explicitly evaluate if (and document that) the results fulfill the acceptance criteria.

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}

The Mobile Health Application market is glowing hot at the moment. New players are entering the market from left and right. Traditional blue chip players are moving in and new start-up's are popping up by the day. However, the medical device market is regulated market and finding out to which laws that apply for your mobile health app might be obvious. Start-up companies may not even realize that their apps are subjected by FDA regulations.

For those unsure about the legal status of their mobile health apps, the US Free Trade Comission has provided an excellent interactive online tool.

Take it for a spin right here! 

Learn more about how Aligned Elements can help with achieving regulatory compliance for your app

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

On March 3rd, the 2016 revision of ISO 13485 was finally released. The new revision is essentially an evolution of the 2003 revision and includes a number of changes and clarifications.

For Aligned Elements users, a change in section 4.1.6 might have some important implications. Whereas ISO 13485:2003 did not explicitly require computer systems used in the quality management system to be validated, the 2016 edition certainly does. ISO 13485 is now finally on par with FDA 21 CFR 820 on this matter.

Computer Software Validation is used to ensure that each computer system fulfills its intended purpose. It prevents problems with the software to reach the production environment. CSV is today used in many regulated industries and is today regarded as a good manufacturing practice.
Aligned Elements certainly fall into the category of Computer systems that must be validated according to ISO 13485:2016 and FDA 21 CFR 820. If you do not have CSV process in place, we do have some things that may help you.

Why is Aligned Elements not validated by Aligned AG?

Aligned Elements falls into the GAMP 5 Software category 4 - "Configurable Software". AE is a highly configurable software with the purpose of mapping the customer's QMS, as opposed to forcing the customer to change his processes and templates to match Aligned Elements.
When validating a software of Category 4, it is of course the particular configuration of the software that is validated. Since each Aligned Elements customer is using a different configuration (each customer has its individual QMS), we cannot foresee which configuration our customers will use.
As mentioned, we do supply a number of useful tools to make the validation process faster.

What do I need in order to validate Aligned Elements?

Even though ISO 13485:2016 and FDA 21 CFR 820 require Computer Systems used in the Quality Management System to be validated, they do not explicitly described how to do it. This is up to each organisation to decide.
With no intention to be a complete listing, you need at least the following things:

1. A Standard Operating Procedure (SOP) that describes how Computer Software is validated in your organisation
2. A validation plan, that describes:
   • INTENDED USE of the computer system in question
   • WHAT are you validating, i.e. which name, version, and configuration of the software including manuals and supplier information and target environment
   • WHY are you validating this software to this particular extent (hint: the GMP Software Categories are a good starting place. A risk-based approach is also a viable starting point.)
   • WHO is responsible for the software, for the maintenance of the software and who is responsible for the validation
   • HOW do you intend to validate the software, what the acceptance criteria are, and in particular how do you intend to handle software errors detected during the validation
   • DELIVERABLES i.e. the documentation you intend to provide
3. Requirements and/or use cases describing how you intend to use the Computer Software.
4. Tests verifying that the use cases and documenting any deviations found.
5. A Validation Summary or Report stating the result of the validation, preferably with some kind of traceability, and whether the Computer Software should be cleared for use in the production environment

To make this process a bit simpler, we provide our customers with a pre-filled example validation kit of Aligned Elements that can be adapted to the individual needs of each organization.

Can Aligned Elements be used to document the validation of other systems?

Absolutely. Aligned Elements is very well equipped for documenting the validation of other systems (provided AE has been validated, of course). AE supports all steps of the CSV process, from evaluating the validation extent via checklists or using a risk-based approach, documenting requirements, use cases and test cases, executing test cases, analysing the test results, and finally supplying the necessary traceability reports.

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}

The first amendment to the IEC 62304 was released in June 2015 and contains some welcome contributions, including:

• Clarification on the scope of the standard
• Information on how to approach Legacy Software
• Increased number of clauses applicable to Class A

There were also some interesting changes made to Software Safety Classifications in section 4.3.

For those familiar with the original IEC 62304 text, the following section describes to assign a Software Safety Classification:

"The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the possible effects on the patient, operator, or other people resulting from a HAZARD (being a potential source of Harm) to which the SOFTWARE SYSTEM can contribute.

The software safety classes shall initially be assigned based on severity as follows: 

Class A: No injury or damage to health is possible

Class B: Non-SERIOUS INJURY is possible

Class C: Death or SERIOUS INJURY is possible

If the HAZARD (i.e. the potential source of harm) could arise from a failure of the SOFTWARE SYSTEM to behave as specified, the probability of such failure shall be assumed to be 100 percent."

This is essentially saying that severity alone decides the classification of your software system/item/unit. Since there is no consensus on how to determine the probability of software failure, the probability of a failure to occur is assumed to be 100%, effectively eliminating the probability factor from having any kind of influence on the software safety classification. 

Now, software in itself has never killed anyone. When harm occurs due to a software failure, there is always some other executing agent involved, e.g. some piece of hardware or a human actor. Consequentially, for harm to occur, there must exist a causal chain of events, tying the software to the harm via that external agent. A causal chain of events occurs with some probability, sometimes called probability of harm.

Probability of harm did not play any prominent part in the original release of IEC 62304 and focusing by effectually removing the probability of failure from the equation due to the difficulties of establishing it in quantitative terms sometimes lead to more or less absurd results. 

In examples where a failure has severe consequences but is extremely unlikely to result in any kind of harm, the software safety class is C according to IEC 62304:2006 (if no hardware mitigations exist), regardless of how unlikely the risk of harm is.

And here is where the authors of the IEC 62304:2015 Amendment 1 have done a great job reformulating the Software Safety Classification section.

The IEC 62304:2015 Amd 1 section 4.3 point a) now reads:

"a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the RISK of HARM to the patient, operator, or other people resulting from a HAZARDOUS SITUATION to which the SOFTWARE SYSTEM can contribute in a worst-case scenario as indicated in Figure 3.

The SOFTWARE SYSTEM is software safety class A if:
the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM.

The SOFTWARE SYSTEM is software safety class B if:
the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is non-SERIOUS INJURY.

The SOFTWARE SYSTEM is software safety class C if:
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is death or SERIOUS INJURY.”

The pivotal point lies in the use of the terms "RISK of HARM" and "unacceptable risk". RISK, in this case, being a combination of severity AND probability.

Now, the probability of harm, (the probability that someone gets hurt) is different from the probability of failure (the probability that the software malfunctions).

The combination of these two probabilities becomes the probability of occurrence of harm. IEC 62304:2015 Amd 1, explains this further in section B4.3 and also includes a Figure (B.2) from ISO 14971.

This means that it makes sense to incorporate both the probability of failure and the probability of harm in our risk assessments. We will still stay true to IEC 62304:2006 by setting probability of failure to 1 (100%) (and avoid the problematic discussion of the probability of a software failure) and concentrate our efforts on correctly estimate the probability of harm.

The amendment of the standard also claims clinical knowledge might be necessary to correctly estimate that the probability of harm following a hazardous situation, in order to “distinguish between hazardous situations where clinical practice would be likely to prevent HARM, and hazardous situations that would be more likely to cause HARM.” This certainly makes sense since the casual chain of events leading from a hazardous situation to a harm typically takes place in a clinical context. 

There are also further complications. Where it previously was sufficient to map severity to the  “no injury”, “non-serious injury”, and “serious injury” categories, which is fairly straightforward, we now have the additional possibility of bringing in the risk's acceptability into the picture.

Establishing severity and probability is one thing that can be done fairly objectively, but in a rational manner argue why a particular combination of these factors is “unacceptable” or “acceptable” is subjective at best, opening the software safety classification establishing to an amount of arbitrariness. On the other hand, "unacceptable" and "acceptable" risks are terms defined in ISO 14971 and should therefore not be new territory to the average medical device manufacturer.

The software safety classification method in IEC 62304:2015 Amendment 1 has certainly become more intuitive. The price for this change lies in the extra effort of:

1. Establishing the probability of harm following a hazardous situation, with the involvement of clinical expertise if and where applicable.
2. Establish and rationalize what makes a particular risk limit acceptable or unacceptable, if not already defined in the general risk management process. 

To finalize this discussion on Software Safety Classification in IEC 62304:2015 Amd. 1, I would like to point out sections in the standard that have received some welcomed clarifications.

Segregation

The new version of the standard amends that segregation of software items does not necessarily have to be physical. In the 2006 version, the only segregation exemplified was hardware-related, which has lead to the false belief that segregation between items has to be physical. This is not the case. The 2015 Amendment makes it clear that the main concern is to assure that one item does not negatively affect another. Furthermore, the segregation applied shall make sense in the context it is used as well as clearly documented and rationalized.

Software Items implementing risk controls

A software item implementing a software risk control (i.e. not external risk controls which can have a positive effect on the classification) shall be assigned the same software safety classification as the software item containing the risk it is controlling. This idea is applicable not only on System level (as described in the 2006 version) but also Item/Unit level.

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}

"Defect rejected - not reproducible” - we have all experienced the gnawing feeling of closing an unreproducible defect. We suspect that the error is still in there somewhere, but without being able to reproduce it, we are fumbling in the dark. In a Medical Device context, where a considerable risk is potentially lurking in this evasive defect, we end up in a very uncomfortable spot.

To minimize these kinds of risks, it is therefore of utmost importance that defect reports contain the information necessary for timely reproduction. 

"We are all interested in getting defects fixed as soon as possible. However, more often than not, defect reproduction takes more time than the actual fixing. The tester has a major role in providing the information necessary to reproduce a defect. However, he can only excel in this role if the underlying concepts of providing accurate diagnostic information are in place, to begin with.", claims Mr.  Michael Stegmann, Chief Executive Director in the Stegmann Innovation Team. 

Mr. Stegmann, having an extensive background in Medical Device Verification and Validation, singles out five critical software aspects that have a decisive effect on effective defect reporting.

Versioning of the software under test

"If the software I test is not unambiguously identifiable, the chance that the development team will be able to reproduce the defect decreases significantly. "V1.0.0.0" or "found in current trunk" will not help anyone. Sending patched dll:s back and forth is a risky practice that eventually will make your environment completely opaque. Therefore, a clear version schema of the software tested needs to be in place from day one." 

Nightly builds with versioned Installers

"Half-baked deployments from various developers will invariably deteriorate your test environment. In the end, you will simply not know what you are testing. Better to go with a centralized build system that automatically creates versioned Installers. 

In that way, all testers have a common source of versioned, predictable deployments that also correctly cleans out all files and dependencies during an uninstall. Setting up a build server does not have to be complicated or expensive. There exist many examples of free and low-priced options in the market."

 Logs, logs, logs

"Logs are one of the main diagnostic tools for finding and fixing defects. When the software developer wants to reproduce the defect, he will certainly ask for the logs. This, of course, presupposes that there exist logs in the first place.

Characteristics of a good logging concept include:

• Logging shall be easy to apply in the code
• Log messages shall have timestamps
• The Log files shall be humanly readable on any computer
• Message severity categories to enable quick visual identification of abnormal entries
• In multi-threaded applications, the logging shall be tread-safe
• The logs shall be stored in an unambiguous and accessible location 
• The log files shall be of a manageable size for viewing and sending, 500kB is a good approximation
• Log message metadata that enables a Log Viewing Application to efficiently filter large amounts of data"

 An Error Handling Concept

"Error handling includes the anticipation, detection, resolution, and communication of errors. When it comes to effective defect tracking the last word, communication, is the most important. If the developer deals with an error situation, seeming ever so improbable, a clear message of what, why, and where the problem occurred, communicated both in logs and on-screen, will go a long way.

Details on the error context, stack traces, and probable causes shall be communicated in a way that is detectable and collectible for the tester. Only then can the information serve as accurate feedback to the developer."

Automatic Collection of Diagnostic information

"Collecting test evidence often includes the finding and bundling of log files, screenshots, PC Information, event log files, configuration file, crash dumps, etc. This is often a tedious and time consuming activity. Automating this process can greatly speed up the verification process and also make sure that the evidence collected is uniform and according to expectations. 

Integrating such a capability in the software will have the additional benefit of making it easier for users and field service engineers to collect and send diagnostic information back to the company in case a defect has slipped through the verification net."

"These aspects shall be designed and implemented in due time before verification starts. In a medical device development environment where risk management is a central factor, a solid foundation for collecting valid and accurate diagnostic information is a requirement, not an option.”

Request a live demo and let us show you how Aligned Elements can help you with your reporting

{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}