MDD Essential Requirements

The following material is copied from the original MEDTEQ website, which was developed around 2009. It is noted that the proposed update to the European MDD addresses some of the points raised in this article. 

In Europe, manufacturers working under the Medical Device Directive (MDD) are given a legal "presumption of conformity" with essential requirements if they apply harmonized standards as published in the Official Journal. This feature is most often quoted as simply meaning that standards are voluntary; most people assume that essential requirements have the highest priority and must anyhow be fulfilled, in this context standards are just one way to show compliance.

Most people also assume the "presumption of conformity" only applies if the standard actually addresses the essential requirement; in other words, the presumption is not absolute. If standards don't cover an essential requirement or only provide a partial solution, the manufacturer is still obliged to provide additional solutions to ensure compliance with essential requirements.

While reasonable, this expectation is not actually supported by the directive. If the presumption was not absolute, we would need a mechanism, defined in the directive, to determine when the presumption is or is not effective. The expected mechanism would require each essential requirement to be analyzed and a formal decision made as to whether standards provide a complete solution, and if not, record the additional details necessary to provide that complete solution. The analysis would inevitably involve a characterization of the essential requirement for the individual device.

Consider for example, the application of essential requirement No. 10.1 (measurement functions) for a diagnostic ultrasound. To determine compliance we would need to compile the following information: 

• what measurement function(s) is/are there?
• for each measurement function, what is/are the intended purpose(s)?
• for each measurement function, what is an appropriate accuracy for the intended purpose(s)?
• for each measurement function, what is an appropriate test method for accuracy in design?
• for each measurement function, what is an appropriate test method for accuracy in production?
• for each measurement function, do the results of those test methods confirm the accuracy in design and production are suitable for the intended purpose(s)?

With this kind of detailed analysis, we can determine if standards genuinely provide a complete solution to the essential requirement, and also identify other solutions if the standards are incomplete. Given the huge range of medical devices, we know that standards struggle to provide a complete solution, and even those few that do address an essential requirement often provide only partial technical solutions which need to be supplemented with manufacturer specifications covering both design and production. Thus this analysis stage is expected to be extremely important for medical devices, and we can expect that the directive will specify exactly how to perform this analysis and what records must be maintained.

But when we look in the MDD to find what documentation must be kept (Annexes II ~ VII), we find surprisingly that there is no general requirement to document how essential requirements are fulfilled. Rather, each Annex says it is only if the manufacturer does not apply a harmonized standard that there is an obligation to document the solutions for essential requirements. This result is reinforced by Article 5, which says that member states must presume compliance with essential requirements if harmonized standards are applied. If these standards are inadequate, member states should take action to create standards, but there is no action required for the manufacturer.

Notified bodies have tried to fill this gap by insisting on an "essential requirements checklist". This checklist has now been formalized in the standard ISO/TR 16142. However, the checklist is really just a method of identifying which standards have been applied, and does not provide the analysis given above, nor record any formal decision as to whether a standard provides a complete "presumption of conformity", and if not, record the additional details necessary to provide a complete solution.  

The application of EN ISO 13485 and EN ISO 14971 were perhaps intended help to fill the gap; but there is a couple of legal problems: first is that neither of these standards, nor any management system standard actually meet the definition of a "harmonized standard" under the MDD. In principle, a harmonized standard is one that provides a complete technical solution (objective test criteria and test method), and should apply to the product, not the manufacturer (see Directive 98/34/EC, formerly 83/189/EEC).

More importantly, these standards have a key weak point: it is possible to argue under both ISO 13485 and ISO 14971 that analysis of essential requirements analysis should be performed, but there is no requirement for this analysis to be documented. Both standards limit the records to the results of the analysis, in particular ISO 14971 requires only the results of risk analysis to be recorded, not the technical analysis used to arrive at those results. While there are good reasons for this, it means that manufacturers can formally comply with these standards without ever actually documenting how essential requirements are met.

Independent observers would be somewhat bemused to find that there is no formal mechanism in the directive which forces manufacturers to document responses to important and difficult questions, such as:

• are low cost oscillometric based NIBPs suitable for home use with high blood pressure patients?
• are syringes with their highly variable stop/start action (stiction) suitable for use with infusion pumps when delivering critical drugs? 
• is the accuracy of fetal weight estimation by ultrasound suitable to make clinical decisions for cesarean procedures?
• can high powered hearing aids actually further damage hearing?

For each of the examples above, clinical literature exists showing they are real problems, yet it is rare to find these topics discussed in any detail in a manufacturer's technical file, quality system or risk management documentation, nor any formal conclusion as to whether the related essential requirement is met. The absence of such documentation is entirely in compliance with the law.

The reason for the apparent weakness in the directive can be found in the history behind the MDD. The original "new approach directives", first developed in the early 1980's were built on the assumption that published technical standards alone can reasonably assure compliance with the essential requirements, through the use of objective test methods and criteria (see 85/C 136/01 and 83/189/EEC). This is called the "general reference to standards" and requires that the standards provide " ... a guarantee of quality with regard to the essential requirements". The "general reference to standards" also says it should not be necessary to refer to "manufacturing specifications" in order to determine compliance, in other words, standards alone should provide the complete solution.

With this guarantee in place, an absolute presumption of conformity is reasonable. Manufacturers can be given a choice of either (a) applying the standard(s) and ignoring essential requirements, or (b) ignoring the standard(s) and applying essential requirements. You don't have to do both, i.e. apply standards and essential requirements. In general, essential requirements are intended to guide the standards writers, and only rarely need to be considered by those manufacturers that choose to ignore requirements in standards.  

For directives such as the LVD (low voltage), this worked well, as the standards could reasonably ensure compliance. But for other directives like the MDD, the range of devices and safety issues makes it impossible to develop comprehensive technical standards. As stated in 85/C 136/01:

"... in all areas in which the essential requirements in the public interest are such that a large number of manufacturing specifications have to be included if the public authorities are to keep intact their responsibility for protection of their citizens, the conditions for the "general reference to standards" approach are not fulfilled as this approach would have little sense"

Despite this problem, the EU went ahead and used the new approach framework for the MDD, as published in 1993. As the framework (Articles and Annexes) of CE marking directives was fixed based on Commission Decision EC COM(89) 209, the text related to the presumption of conformity and required documentation was adopted almost word for word. Thus, we can see in Annexes II ~ VII that manufacturers only need to refer to essential requirements if harmonized standards are not applied; in Article 5 the presumption of conformity is unconditional; and if there is doubt about standards assuring compliance then action is required by member states and not by manufacturers. While EC COM(89) 209 has now been updated twice (currently DECISION No 768/2008/EC), these parts of the MDD have not been yet updated to reflect the most recent framework.

So while competent authorities, notified bodies and even manufacturers might reasonably assume that the presumption of conformity is not absolute, the law doesn't support this. Moreover, the current informal approach, based on the essential requirement checklist, ISO/TR 16142, ISO 13485 and ISO 14971 also fails to effectively force manufacturers to look at each essential requirement in detail.

An interesting aside here is that the UK "transposition" of the MDD into national law includes a qualification that national standards provide a presumption of conformity with an essential requirement, "unless there are reasonable grounds for suspecting that it does not comply with that requirement". A slight problem, however, is that the UK is not allowed to do this: European law requires the local transposition to be effectively the same as the MDD, otherwise the whole concept of the common market and CE marking falls down. A secondary problem is that the UK law does not give any implementation details, such as who is authorized to decide, when such decision are required and what records are required. That the UK quietly added this modification to the MDD, despite being obviously illegal, clearly indicates the presumption of conformity is weak when applied to medical devices.   

So, is EU law at fault? Does it need to be amended to force manufacturers to analyze each essential requirement through a process of characterization, scientifically and objectively showing how the requirement is met, irrespective of standards?

Perhaps, but some caution is recommended. We need to keep in mind that CE marking may really just provide "clearance for sale", a function which needs to balance free flow of goods against risks, and which should wherever possible be based on legal certainty and objective technical specifications. Regardless of compliance with the directive, manufacturers are still liable for injury under the Product Liability Directive, which provides back up and incentive at least for serious and detectable issues. Competition also provides incentive in many other areas which are highly visible to the user, such as image quality in a diagnostic ultrasound.

Competition of course also has a darker side: pressure to reduce price and speed up market access. But, the reality is that manufacturers live in a competitive world. Like it or not, competition is a strong force and is a key reason why some of the difficult issues remain undocumented. Most manufacturers when questioned know well about these issues, but feel action is not required while the competition also takes no action. Even if we did force manufacturers to analyse essential requirements systematically, complex situations allow in bias, and the bias would tend towards keeping the status quo - it would take a lot of effort by notified bodies and regulators to detect and counter such bias working directly with each manufacturer.

In other words, forcing the analysis on manufacturers may not make much difference, and just add to compliance costs.

So, the answer here seems to be improving technical standards, forcing all manufacturers on to a "common playing field". In a round about way, Article 5 of the directive is perhaps on the best path: rather than expecting too much from manufacturers, member states should focus on creating standards that provide specific solutions (test methods and criteria) for individual medical devices.

For this to work, a critical point here is that standards committees need to take  Directive 98/34/EC seriously, creating standards that provide a complete, objective technical solutions for the product, rather than more management system standards without any specific technical details.

While we can never hope to address all safety issues in technical standards given the wide range of medical devices, it may be possible for member states to focus their efforts to those areas where product liability and competition are not effective at addressing known issues. In other words, it is not necessary for a standard to try and cover everything, just those areas which manufacturers are known to be weak.    

The main point is, the next time someone wants to discuss whether a standard provides a "presumption of conformity", make sure they have a cup of coffee ready, as the explanation will take a little time.

MDD - Retrospective application of harmonized standards: an investigation

Originally posted in October 2011. Due to the transfer, links to footnotes no longer operate. 

[PDF Version]

While significant discussion continues around the content of EN 60601-1:2006 (IEC 60601-1:2005), it is generally understood that in Europe as of June 1, 2012[1], the previous edition will be withdrawn, leaving only the new edition to provide the legal “presumption of conformity” against essential requirements.

Notified Bodies have indicated that this situation is in effect retrospective: all older designs that are still being sold will have to be re-verified against the new standard. This is based on the interpretation that the “presumption of conformity” only exists at a point in time when each individual device is placed on the market. Thus, in order for manufacturers to maintain compliance, they must continuously update the design taking into account current harmonized standards.

Although standards are voluntary, it is still expected that manufacturers evaluate compliance on a clause by clause basis. This ensures the manufacturer is aware of specific non-conformities, and can then choose to redesign or provide an appropriate justification as to why alternate solutions still meet the essential requirements. Thus the voluntary nature of harmonized standards has little impact on the amount of work associated with updates in standards, and in particular, work associated with retrospective application to existing designs.

Despite the apparent unity in Notified Bodies on this interpretation, the MDD does contain text that calls this interpretation into question. Moreover, the implications of broad retrospective application may not have been fully considered by Notified Bodies.

The preliminary "whereas" section of the Medical Device Directive (MDD) includes the following paragraph:

“Whereas the essential requirements and other requirements set out in the Annexes to this Directive, including any reference to ‘minimizing’ or ‘reducing’ risk must be interpreted and applied in such a way as to take account of technology and practice existing at the time of design and of technical and economical considerations compatible with a high level of protection of health and safety;”

Later, in a paragraph associated with harmonized standards, this is repeated again:

"… essential requirements should be applied with discretion to take account of the technological level existing at the time of design and of technical and economic considerations compatible with a high level of protection of health and safety"

These statements appear to indicate that the presumption of conformity may exist at the time of design, rather than the time of placing on the market. If so, this would remove the retrospective nature of standards, and conflict with the advice of Notified Bodies. While the “high level of protection” part is open to interpretation, it appears that the intention was to say that essential requirements, standards and risk should be considered to apply at the time of design, unless there are some serious concerns. For example, if incidents in the market led to changes in standards or state of the art, such changes could be considered reasonable even for old designs.

Unfortunately, this “time of design” statement lacks further legal support. In the core part of the directive (articles, annexes) the phrase is not repeated. It also appears that the “whereas” section has not been transposed into national law (UK law, for example, does not use the phrase). The forward of EN ISO 14971 does repeat the above statement that "risk" must be assessed “at the time of design”, and this is also clarified in again in Annex D.4 in the same standard. But since these references are hidden away from the normative text, again they are often overlooked. So if the authors of the MDD really did intend the presumption of conformity to apply at the "time of design", there is considerable room for the EU to improve on implementation to provide greater legal certainty.

So, we are left with the task of finding out if retrospective application is feasible. An investigation finds that there are three key areas: the first looks at the unusually large number of standards that apply to medical devices; the second considers the case of “brand new” standards (without any transition period), and the third is the impact of requirements that apply to the manufacturer, as opposed to the device.  

Notified bodies have tended to highlight the retrospective aspect on high profile product standards undergoing transition, such as EN 60601-1:2006. But they have been very weak in enforcing the retrospective rule for all harmonized standards.

This is not a reflection of poor quality work by Notified Bodies, but rather the sheer impracticality of the task. While other directives may have more standards, the MDD is perhaps unique in the large number of standards that can apply to a single "product". Under the Low Voltage Directive, for example, two to three standards would typically apply to an electrical appliance such as a toaster or washing machine, keeping retrospective application in the realm of feasibility. Other high profile directives don't use the phrase “at the time of design” .

In contrast, a typical medical electrical device will have at least 10 harmonized standards, and Appendix 1 of this document lists some 26 harmonized standards that would apply to a typical full featured patient monitor.

Keeping on top of all these standards retrospectively is arguably beyond what can reasonably be expected of manufacturers. Benefits from new standards would be offset by adverse effects such as impeding innovation and increasing costs of medical devices. Another less obvious effect is that it tends to make standards less effective: recognizing the heavy burden, third parties often allow simplifications to make the standards easier to apply retrospectively, but these simplifications set up precedents that can take many years to reverse. 

Not only are there a large number of standards being regularly updated, there are also many “brand new” standards which are harmonized without any transition period. This poses a special case where retrospective application is impossible, since a manufacturer cannot know when a standard will be harmonized. In a sense, the standard becomes instantaneously effective on the day it is first published in the Official Journal.

In literature associated with EN 60601-1:2006 (IEC 60601-1:2005), it has been pointed out that the original standard has been around for many years, thus manufacturers have no excuse for further delays beyond June 2012. But this is again an example where only high profile standards are being considered, not the full range of both harmonized and non-harmonized standards.

The “no excuse” interpretation implies that manufacturers must watch IEC or ISO publications, anticipate and prepare for harmonization. But this is not only unfair since there are many IEC and ISO standards that never get harmonized, it is also logistically impossible. There are many examples where the time from first publication as IEC or ISO to publication in the Official Journal is less than 18 months[2]; no reasonable law could expect implementation in such a short time, particularly in the context of retrospective application. Moreover, the simple logistics of CE marking (such as the declaration of conformity, technical file) would be impossible arrange in a single day when the standard first appears in the Official Journal.

The case of “brand new” standards alone provides simple, unarguable evidence that the presumption of conformity cannot apply at the time of placing on the market, without violating the principles of proportionality and legal certainty[3].

A more complex situation exists with manufacturer requirements, usually in the form of management systems. EN 60601-1:2006 highlights these problems as it has both product and manufacturer requirements in the same standard. Manufacturer requirements are those which require the manufacturer to take some specific action indirect to the product; while these actions are intended to have an influence on the product they are often several layers removed, such as the retention of qualification records of persons involved in the design.   

Historically, the new approach directives were based on product requirements, and it is arguable that areas of the directive have not been fortified to handle manufacturer requirements. Even the definition of a harmonized standard is “a specification contained in a document which lays down the characteristics required of a product …”[4], and thus appears not to have provision for manufacturer requirements.

Since the principles of free movement, essential requirements the presumption of conformity all  apply to the device, it is obvious management systems alone cannot be used to provide a presumption of conformity; rather it is the design specifications, verification records and other product related documents output from the management system which provide the main evidence of conformity.

If a harmonized management system standard is updated, the question then arises about the validity of product related documents which were output from the old system. In other words, whether the older documents still provide a presumption of conformity. Moreover, if a “brand new” management system standard is harmonized (such as EN 62304), the question arises whether manufacturers are required to apply the management system in retrospect for older designs.

This is very different to product requirements. A change in product requirements might be annoying, but generally limited in the amount of resources required for re-testing or redesign for specific technical issues. In contrast, a change in a management system can invalidate large amounts documentation and  trigger a massive amount of rework, far beyond what is reasonable to achieve the objective of health and safety. Manfacturer requirements are clearly written to apply at the time of design: the costs are relatively small if applied at the time of design, whereas as the implementation after the design is complete can be incredibly high.

Consider for example, a manufacturer that has an older programmable system, but did not record whether the persons validating the design were not involved in the design, as required by EN 60601-1:2006, Clause 14.11. A strict, retrospective interpretation would find all the validation tests invalid, and force the manufacturer to repeat them all again at great cost.

Thus, while less straightforward, management systems also provide a fairly strong argument that the presumption of conformity applies at the time of design.

In practice, most Notified Bodies take a flexible view on retrospective application of management systems, using common sense, taking into account the amount of work required, and focusing on high level documents associated with high profile standards.

Also with respect to “brand new” standards, Notified Bodies often apply an informal transition period of 3 years from the time a standard first harmonized, recognizing that immediate application is impractical.

While these relaxations are reasonable, they are not supported by the law. This is not a case where vagueness in the law requires Notified Body interpretation to fill in the details; this is in a sense a simple question of when the presumption of conformity applies. The answer, whatever it is, must be universally applied. It is not possible to apply one interpretation to EN 60601-1 and another to EN 62304. All harmonized standards must be treated equally.

With the current law, the only practical universal interpretation is that the presumption of conformity applies at the time of design, as indicated by the “whereas” section of the MDD.

It is worth to note that no official document endorsed by the EU commission indicates that retrospective application is required. This is unlikely to happen as documents issued by the EU are usually carefully vetted by the lawyers, a process which is likely to raise similar concerns as discussed above. In particular, the situation with “brand new” standards (standards without a transition period) will make the commission wary of formally declaring standards to be retrospective.

Also, it is a well established regulatory requirement (e.g. clinical data, EN ISO 13485, EN ISO 14971) that post market monitoring includes the review of new and revised standards.  Thus, the “time of design” interpretation does not imply manufacturers can completely ignore new standards. But importantly, the flexibility in decisions to apply new standards to older designs is made by the manufacturer, not the Notified Body.   

The “time of design” interpretation is not without problems. Designs may take many years to finalize, so the term “time of design” obviously requires clarification. It could also lead to products falling far behind state the art, or failing to implement critical new requirements quickly. Even using the “time of design” interpretation, “brand new” standards still pose a challenge to manufacturers, since it can be impractical to apply even to current designs. So, more work is required.  

But in the context of EN 60601-1:2006, a “time of design” interpretation would act as a pressure relief valve not only for manufacturers, but for all parties involved who are struggling to apply such a large new standard retrospectively.

Appendix 1: Harmonized standards applicable to a patient monitor

The following is a list of harmonized standards which are currently applicable to a typical full featured patient monitor including accessories. Items shown in brackets are standards which are expected to replace the existing standard or are already in transition.

EN 980

EN 1041

EN 1060-1

EN 1060-3

EN 1060-4 (ISO 81060-2)

EN ISO 9919 (EN 80601-2-61)

EN ISO 10993-1

EN ISO 12470-1

EN ISO 12470-4 (EN 80601-2-56)

EN ISO 13485

EN ISO 14971

EN ISO 17664

EN ISO 21647

EN ISO 20594-1

EN 60601-1

EN 60601-1-2

EN 60601-1-4 (EN 60601-1/Clause 14)

EN 60601-1-6

EN 60601-1-8

EN 60601-2-27

EN 60601-2-30 (EN 80601-2-30)

EN 60601-2-34

EN 60601-2-49

EN 60601-2-51

EN 62366

EN 62304
 

[1] The actual date will depend on particular standards

[2] See EN 62366 (Usability Engineering) which has only 13 months from publication as IEC to listing in the Official Journal.

[3] As required by the “Treaty of the European Union” 

[4] See directive 98/34/EC

IEC 62304 Software Development Life Cycle

Search for the term design life cycle in Google Images and you will find a plethora of circular flowing images, creating the impression that a design life cycle is an abstract concept, one that guides the flow rather than provides any detailed structure or definition to the design process.

While an abstract guide may be useful, it has little place in a regulatory or legal context. Regulations aren't about good guidance such as writing clean code; regulations and standards need to provide requirements which at least in principle can be both interpreted consistently and where compliance can be verified.

Fortunately, a close look at IEC 62304 finds that a design life cycle is in fact well defined and verifiable requirement.  A life cycle consists of defined phases, each with specific inputs and outputs (deliverables). These inputs and outputs form the tangible elements which can be checked for plausible implementation. 

For example, a realistic life cycle might start with an "Draft documentation" phase, which has no formal inputs, but outputs documents such as the draft project plan, system specifications, initial risk analysis. The next phase may be "Stage 1 Approval" which reviews and approves those documents (as inputs) and and creates a review report, and formally approved plan, specifications, risk analysis (as outputs). A later stage might be "Final Testing" which uses the test plan, starting code, prototype, with the output being the final code, configuration report, test reports, summary report, completed risk traceability matrix, design change records and so on.  

As such, a design life cycle starts when the first document is approved (typically the plan), and continues to control the activities in the design process. It is closely related to a design plan: a plan includes the life cycle and adds supporting information such as requirements for document control, configuration management, change control, definitions for responsibility and authority, linkage to system specifications and so on. 

Life cycle timing

Given that a regulatory life cycle starts when the first document is approved (and not at the brainstorming meeting or when the designer has a 3am eureka moment), it is an important question to ask: when should this formal life cycle start? 

Experts are likely to say "as soon as possible", or "whenever any significant design activity occurs". These answers, while said with all good intentions are both wrong and often dangerous. 

The correct answer is: whenever the manufacturer likes. There is no legal obligation to keep records of the design process as it happens. A manufacturer can spend 10 years in R&D, legally shred all the records covering the messy development period, and then start a 6 month period creating all the documents required by ISO 13485, IEC 14971, IEC 62304, IEC 62366 and other management standards standards, and be perfectly in compliance with all standards and regulations. 

And in fact, this approach is far more safe than it may appear.

Why do experts assume earlier is better?

One of the reasons why "earlier is better" persists is the common mistake of regarding prototypes as medical devices, which in turn makes us think that regulations naturally apply over the whole development period.

Another reason is the assumption that early design controls and in particular early risk management yields better outcomes.

Both of these are wrong, and the good news is that IEC 62304 appears to have (for the most part) been written by people who have real world experience, and the standard itself does not load designers with any unrealistic expectations. The main problem consists of people who have not read the standard, have no experience in design, and overlay their well intentioned but ultimately misguided interpretations on the standard. 

Prototypes are not medical devices  

Only the device actually placed on the market is a medical device. When the word "medical device" appears in management system standards such as IEC 62304, we tend to naturally extend this to pre-market versions and prototypes. But legally speaking, a manufacturer's responsibility is limited to demonstrating that the marketed device meets the requirements. How they do this is up to them: the history of the product, which is often complicated, messy, includes a mix of new ideas, old ideas, borrowed designs, software bought from a bankrupt company with a great product but no records; all of this is not under the scope of regulations or standards.

You don't need to pretend the process was smooth and controlled: it rarely is. It is only necessary that records exist to support the final marketed device.  

In seminars, this concept is often difficult to get across. Consider the following example for the software history: 

• Version 1.0.1.2 is released to marked, properly verified according to IEC 62304
• Version 1.0.1.3 adds new Feature A, is tested but not released, as requests for new feature B came in the mean time
• Version 1.0.1.4 is released to market with new Features A & B  

A typical exchange in a seminar might go along the following lines: 

[attendee] "So what level of records do I need to keep for V1.0.1.3?"
[speaker] "Well, if you start at V1.0.1.4 ... "
"Sorry to interrupt, but I am talking about V1.0.1.3"
"Yes, but we need to start at V1.0.1.4 ... "
"SIR I AM TALKING ABOUT V1.0.1.3"
"I DON'T CARE ABOUT V1.0.1.3" [deep breathing, calming down]. "It never went to market. It is not a medical device. You do not need to keep any records for it. Now, we need to look at the records for the real medical device, V1.0.1.4. We might find that tests on V1.0.1.3 were used to to support compliance, or we might find V1.0.1.4 was 100% re-tested, so we can ignore all data from V1.0.1.3."
"Really? I'm still not sure I can just throw out the design test data."
[Inaudible sigh]

To understand the regulatory perspective, always start with the actual marketed device, and work back to the required evidence. Once the evidence is found, you can stop looking.   

The "prototype is a medical device" thinking is not only confusing, it can be dangerous as designers often forget about their obligation to make sure data is representative of the marketed device. In the above example, a court of law would find any testing on V1.0.1.3 for Feature A does not itself form any legal evidence for the marketed version 1.0.1.4. This is one area where IEC 62304 is weakly structured: if a serious incident occurred and the cause found that Feature B interfered with Feature A, there is no record required by the standard which clearly identifies the responsible person that decided not to re-test Feature A again in V1.0.1.4. Amendment 1 improved the text in 6.3.1, but there are no required records pertaining to the decision not to retest. As design changes accumulate, the relationship between the tests on the older versions and the final marketed device gets progressively weaker.  

This may seem a digression from the design life cycle, but understanding the need to be representative of the marketed device is an important factor in deciding when to start the formal, regulatory life cycle. 

Early designs change more than you think

Those outside of the design process might think that design is simply about writing specifications, writing some code and checking that it works as expected, ironing out the occasional bug that occurs along the way. 

In reality, designs are multi-dimensional problems that our brains are simply not smart enough to solve in a logical way. This means that trial and error forms a huge part of design, with as much as 90% of trials ending in failure (hence the phrase trial and error). Some failures are detected quickly, others advance for months or years before realising it is unworkable. Some failures are quickly corrected, others require major surgery. 

This is important to understand for two reasons: first, formal design controls can be more of a hindrance than a help for designs that are still young, unstable and working through this trial and error phase. Having to update specifications, architecture every step of the way can be so onerous as to grind the process to a halt. To survive, designers often opt for a simplified "lite mode" approach to design controls, keeping everything at a surface level, avoiding detail and not particularly accurate with respect to the real design.

The problem is this "lite mode" continues even to the point of market release. Although designers often have good intentions to document more detail later, the "lite" verses "detail" distinction is not formally identified in the plan, so there is no specific point to switch from "lite" to "detail" and no time or resources allocated for the "detail mode". Couple this with schedule overruns in years and the pressure from management to get the product to market typically means designers quietly stick to the "lite mode" all the way to product release.

Regulators often look for the structure of the documents, but fail to check if the detail is accurate and complete for the final marketed device. If they did, for example, take several random samples from the features in the real medical device, and auditors checked that the architecture, specifications and tests covered these features accurately, they are likely to find at least one or more features where the specifications no longer fit, are lacking reasonable detail, the testing is out of date with the actual design or even the feature is missing entirely from the formal records.   

Thus, it is actually safer to allow designers a free hand to develop the product until the design is stable, and then apply detailed, formal controls with an emphasis of working back from the finished design to ensure the details are accurate according to the marketed product. 

The second is good understanding that system specifications are not black box derived - in other words, you can't sit down and write good specifications without knowing how the design will be implemented. In the early stages of design, solutions will not yet be found, hence reasonable specifications cannot be created early in the cycle. This problem is one of the issues addressed by modern techniques such as agile software development, which understand that rather than preceding detailed design, specifications will emerge and evolve from the design.    

Equally, until the design is stable it won't be clear exactly what the risks are and the best way to handle them. Risk is again not black box driven - the final architecture, structure of the system, platforms and software will yield significantly different risks and risk controls. For example, these days wireless patient monitoring applications via smart phone and the cloud are the flavour of the month. Each company will choose different solutions and in particular vary greatly in delinting the software functions handled by each device in the chain (device attached the patient / smartphone / cloud). Decision on the amount of data storage in each unit, where time stamps are recorded, degree of pre-processing, controls and feedback available to the patient can all have a big influence on any risk evaluation and the associated risk controls.  

This again points to the need to delay formal specifications and risk evaluation until after the design is stable.  

None of this prohibits the manufacturer (designers) from keeping informal documentation: draft plans, specification and risk evaluation, test results which are undoubtedly useful and may even be necessary to keep some control of the design. Nevertheless, it remains a benefit to distinguish this draft stage, which may be deliberately light on detail, not always up to date, and may lack approvals from the formal regulatory stage, which is required to be accurate, approved and complete for the final medical device. 

The best time to start

Deciding the best time to start formal controls is in reality an efficiency decision, and will depend on the individual product. 

For simple designs, it can often be best to leave the formal controls until the design is thought to be 100% stable. This usually means informal testing and debugging against draft specifications until all issues are cleared, followed by the formal life cycle: approval of the specifications, risk management; actual testing; summary report. If during the formal testing issues are still found, the manufacturer can opt to apply configuration management and regression testing after fixing the issues; or re-start the process again from scratch.

For bigger systems, it can be more efficient to break the system into blocks. The blocks can then be treated the same as above (no formal controls until stable); with formal controls applied when the blocks are stable and ready to be integrated.  

The main aspect to consider is the probability that specifications, risk management and test data will be representative of the final medical device. This probability improves as the design becomes more stable. On the other side, there are costs associated with repeating tests with every design change. Having design controls in place allows you to use data on earlier configurations as long as it is representative, which can save considerable time and cost especially for larger systems. An efficient point occurs when the costs of formal design controls balance against the savings from being able to use test data on earlier configurations.   

What if risk evaluation is left too late?

The worry that risk evaluation left late is a valid concern, but the emphasis on early design is a misdirection, at least in the context of standards and regulations. Irrespective of the final solution, the risk must be deemed acceptable by the manufacturer. If the solution is not acceptable, it is not acceptable. Legally, the timing of the decision cannot influence the decision on acceptability. If it does it suggests a deeper problem with the risk management process, such as a lack of control for conflicts of interest. If an unreasonable solution is deemed acceptable just because of the high cost associated with late stage implementation ... then something smells bad in the process that supports that decisions. It is more important to address the inadequacies of the analysis than blame the timing of the analysis. 

Again, none of the above suggests the manufacturer should not be thinking about risks, risk controls and drafting documents prior to the formal design life cycle. But above all this sits the simple approach that the documentation on the final, marketed medical device should be complete and appropriate. The history is irrelevant - the main point is that the marketed medical device should be safe.  

What about agile software development? 

There has been significant discussion about whether agile and similar practices meet the requirements of IEC 62304 and FDA software guides. AAMI TIR45:2012 has been written to address this space, and the FDA has been supportive of the practices given the superior results over waterfall based methods. 

However, much of the guidance continues to use the "prototype is a medical device" philosophy, hence requiring that agile practices, while lighter and focusing on iterations, still need to be documented at every iteration.

Instead, this article suggests agile practices should be considered part of the informal phase of design, where regulatory documentation is not retained. The iterative, collaborative design process eventually outputs a stable design and draft specifications/risk management. Those outputs then forms an input to the formal regulatory stage in which the focus switches to ensuring the documentation is complete and reasonable for the final marketed, medical device.

For example, a surgical laser may have had a internal software controlled start up self test of the overpower protection systems added at the 7th iteration, which while implemented was largely forgotten by the 10th iteration as the focus turned to user interface and high level performance of the system. Left to agile practice alone, the start up test could be easily overlooked in final stage verification tests. This overlooking of internal functions is a frequent issue found in independent testing of safety systems, not only missing specifications and verification, but actual logic errors and software bugs in the final implementation.

The view of this article is that regardless of the history, approach, development model used, the manufacturer needs to be confident that the such a start up self test has been verified for the configuration released to market. Reasonable confidence can only be derived by ignoring the development history and working back from the final, stable device.