My dad used to say, there are old pilots and there are bold pilots but there are not many old, bold pilots. For this blog we can substitute pilots for medical device (MD) & in-vitro diagnostic (IVD) programmers. Programming is fun! It provides focused creative activity with tangible results. “Hello World!” on a computer screen or a blinking LED on a circuit board provide instant gratification that you have the basics running and the sky is the limit after that!
Aerobatics – the early days
In my earlier design career, I switched back and forth between electronic design and embedded software design (aka firmware). For me, over time, I learned firmware was more enjoyable – being in the bowels of the instrument and really bringing it all together can be daunting yet, it is somewhat forgiving from a development standpoint. All focus would be on the coding with its tight timing constraints and multi-dimensional aspects such as interrupts and task switching. Make a mistake during development and often you can quickly remedy, recompile and voila little schedule impact. Hardware on the other hand was less forgiving, make a mistake and it is either a “cut-n-jump”, dead bug integrated circuit (IC) tack on, or a printed circuit board re-spin – Ugh – so much for project schedule and budget!
So software/firmware was very agile in the old days as there was little to change but code. Then came medical device software development. This required many of the design artefacts we know of and they subsequently added a bit more inertia to the software development process. Now we needed to plan, spec., verify and if issues arose go back and make a lot of documentation changes plus regression tests and formal V&V redo’s. We need to formally manage configurations, bug anomalies, release processes and OTS/SOUP. Still not so bad relative to “late in the game” MD & IVD hardware changes but not nearly so “agile” as the older days.
Formation Flying – more than a software only focus
I’ve been around long enough to notice that even those software centric process days are behind us. MD and IVD software development is significantly more comprehensive now with commensurate additional process. It has become so comprehensive that the coding effort is about the same percentage of the development from a task standpoint as hardware schematic design is to the other processes involved in product realization. Key to this is that there are now a myriad of standards established and recognized that set the acceptability level “high bar” on MD & IVD software. Think of these standardsas the wisdom of the old pilots being shared with the bold pilots (although old dogs need to learn too). The extensiveness of these standards is often spawned from real world issues and become required. Heed these standards and your efforts can live on, ignore them, or pay “lip-service” to them and you will crash and burn.
The challenge with the standards is that they are rather siloed. These standards set out to address a particular issue and although they try to harmonize and align it can be very daunting to practically apply them. The standards are put out by various organizations (ISO, IEC, AAMI etc.) and they reference and point to each other in an attempt to tie them together for the consumer (i.e., manufacturers). Moreover, different regulatory agencies recognize different versions throughout the world making the global market even more of a challenge (Qserve is well versed here). Since we are focused here on software lets apply a common software state diagram to show how these various standards translate to the manufacturer’s developer activities. | 
Figure 1: Standard Siloes |
Figure 2: Manufacturer’s developer standard application state diagram behavior.
As we develop medical device software, regardless of whether it is embedded in a medical device or IVD (IVD Software), is considered the medical device (SaMD/AI), or perhaps an accessory to a medical device, we must grapple with how the standards ultimately affect our software processes, requirements, architectures, V&V etc. This can be a major challenge to small device manufacturers depending on resources and backgrounds. Even large organization can tend to enhance the silos by assigning subject matter experts(SME’s) to the particular area where their focus is confined to their expertise and whatever they happened to know about the overall domain and the rest of the standards playing field. This can lead to the “whack-a-mole” (Fig. 2) approach to compliance. We tend to focus on various aspects with compartmental thinking at times; Let’s look at usability, let’s look at cybersecurity, let’s look at risks, let’s look at software etc. We can go from state to state addressing the various aspects of the standards sprinkling in solutions and mitigations sometimes creating band-aids after the fact to hopefully satisfy requirements.
Formation Flying – building the support structure
Over the years I have come to embrace and be a strong proponent of system perspectives. From traffic patterns to our law making and yes to MD & IVD design and development I believe a system viewpoint is critical prior to picking solution paths. In all fairness, the base standards call for a planning phase – which really means – step back and map it out! This can be under appreciated by the inexperienced. We don’t have the time! As the old adage goes, “there is never enough time to do it right but always enough time to do it over”!
Okay, I’ve dug a hole with the problem stated above. My motivation here is to 1) provide awareness of the reality (above) and to 2) offer a glimpse of a solution (below). First a word from our sponsor: Qserve deals with this issue on a daily basis with many diverse clients in the global market. Our pragmatic approach can be as little as some advice, to reviewing/auditing, to getting things started to just be doing it. In any capacity, if you have a viable effective medical device or IVD we want to help you provide it to those who can benefit and that means product realization!
| To tackle this silo situation there needs to be an alignment process done by the manufacturer/developer. Because design controls are central, they best serve as the framework to start organizing ourselves. We need to understand our intended use, users and the markets as these fundamental, core top-level requirements feed our planning and ultimately the level of rigor we apply to our application of the standards. | 
Figure 3: AI is software too! |
For this exercise I’m lumping Artificial Intelligence into software. There are some additional considerations (AI Framework ) but remember – AI is software and therefore beholden to software development standards.
As blog space is limited and here intended to help encourage a system perspective, I will just cover some concepts. Starting with a table (Excel works good) of the appropriate major design control buckets, we pull from the standards the requirements ascribed to the various buckets and put them there as placeholders. The goal here is to align the standard’s requirements in a process structure that we can then add to our process/procedures and templates so that we are simultaneously addressing as we move through development. Some standards readily lend themselves to this like 62304 which is a process standard. Others do not like 60601-1 (remember Essential Performance?) but their deliverables align to design control phases. Additionally, as each manufacturer has their own domains, it is an exercise that requires customization/tuning for the domain. If nothing else, start with planning. If your plans (risk management, usability, cybersecurity, s/w dev., etc.) are standards driven and you follow your plans you will be yielding a standards compliant result!
If your goal is the global market, capture geographically recognized standards in the column heading under the standard category. For example, universally recognized can be green, while those that are unique such as FDA Guidance blue. If we go down the phases – (only planning is shown, and I’ve listed no other planning elements here) we can comprehensively cover each aspect of the pertinent standard in the corresponding design phase.
Product Realization Stage 13485 FDA Guidance Design Controls | General SW 62304 FDA Guide SW Val. | Risk 14971 80001-1 | SW Risk TIR 80002-1 AMI TIR34 | SW Cybersecurity EN IEC 62443-2 (11073-40102) 60601-4-5 TIR57 | Usability 62366-1 FDA HF/UE Guidance |
Process 810001-5-1 TIR57 | Network 80001-1 | Product EN IEC 62443-2 60601-4-5 |
Planning | Project Plan SW Dev. Planüü | Risk Management Plan SW Risk Management Plan üü | Process (Manf. Cybersecurity Plan Plan Req. üü | Usability Engineering Plan üü |
Design Input | üüEtc. | üüEtc. | üüEtc. | üüEtc. | üüNetwork (Responsible Org.) Requirements | üü Product Capability Requirements | üüEtc. |
At a high level for software, we can end up with something like the diagram below for those elements listed in the standards. The plans capture the required elements for the product development project while the design control procedures/templates cross check.
Figure 4: Standard Alignment to Design Controls Process
This depiction is for a device with software in it. If it was Software as a Medical Device (SaMD - AI) it wouldn’t be much different only instead of teal where software is part of the consideration it would be greener as software (SaMD) is the system and hence requires the full system perspective. The standards encourage system perspectives when it comes to software, but this can often not be appreciated. By the way: can you see where the coding task is in this development? Obviously, each box above has a lot more granularity but if your plans, processes/procedures, and templates span the field and pick up this granularity of the contributing standards, then your development will too! So, if I leave you with nothing else, look to the sky and let the wisdom of generations remind you that formation flying versus loan aerobatic flying is where we are now in MD & IVD programming if you want to go the distance! MD & IVD software development, a system perspective – time to make the migration?
Figure 5: Software V-Diagram - System Perspective