{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