Are you brave enough to use State of the Art?

A term we encounter regularly in safety related industries is state of the art. Top level documents in different industries e.g. ISO 26262 in automotive or the Medical Device Regulation (MDR) often sprinkle the term throughout with the expectation that organisations shall follow state of the art. Which is interesting as neither of these documents define what state of the art actually means.

The term has been around for over 100 years, first used in by an engineering graduate working on gas turbines. The term also has deep roots in the legal profession in patent law and tort (negligence and product) liability.

It was refreshing at the end of 2019 to see the committee working on ISO 14971 – the medical device risk management standard – had added the definition to the standard (origin ISO/IEC Guide 63:2019):

State of the art – developed stage of technical capability at a given time as regards products, processes and services, based on the relevant consolidated findings of science, technology and experience.

Note 1 to entry: The state of the art embodies what is currently and generally accepted as good practice in technology and medicine. The state of the art does not necessarily imply the most technologically advanced solution. The state of the art described here is sometimes referred to as the “generally acknowledged state of the art”.

ISO 26262 part 2 talks about the achievement of the objectives of the standard, judged based on requirements, the state of the art regarding technical solutions and applicable engineering domain knowledge at the time of development.

In the medical device camp, the MDR talks about (amongst other examples) risk control measures conforming to safety principles taking account of the generally acknowledged state of the art.

To which group do you belong?

People generally belong to one of two groups when it comes to the topics relating to implementing state of the art. The smaller group are those that embrace the chance to define technical solutions that fall under this banner and will justify in detail their reasoning and why it fulfils the goal.

The second larger group tend to shy away from these activities and prefer to follow to the letter of the law, the defined clauses of international standards.

This leads to a problem generally in encouraging teams to achieve a ‘good practice’ technical solution if it is unclear what state of the art is and how they should achieve it. Much also comes back to what is normative and what is informative in international standards. Many standards do encourage the reader, as listed above, to find that state of the art solution, but if you are in the group that prefers to follow the normative clauses of a standard you may find it difficult to take that next step.

Perhaps a solution might be to list more examples in standards. The forthcoming second edition of IEC 62304 Health software – software life cycle processes, has been updated so that the general requirements section outlines meeting state of the art, but as to date IEC 62304 has had one update in 14 years, it, as with many other standards, may soon fall behind the curve in this area. Guidance or reference documents in a given industry may be a more preferable route.

A challenging topic that you can see will occupy us all for the foreseeable future.

By Alastair Walker, Consultant