Medical Device Software Development has evolved significantly since medical devices have gone online. Gone are the days of being able to test a piece of software on hardware in isolation. Software changes are needed quickly and business needs shift rapidly. Here are five areas to look out for to determine if your medical device software will support your business needs or if it needs help.
1. Insufficient Comprehensive Automated Testing – Especially Unit Tests
Testing is key to achieving confidence in released software. Automation is key to agility.
Automated testing should include system, integration and unit tests. Unit testing should be emphasized because it is the only way to comprehensively cover the nooks and crannies of the code where bugs tend to hide.
Code that is not initially developed with good unit test coverage will not be inherently designed for testability. This is especially true with respect to decoupling. Unit testing early helps code be designed properly for testability. An absence of unit testing and a lack of designing for testability represents significant technical debt, which can be expensive and time-consuming to fix. By designing for testability from the beginning, we can deliver agility and continuous confidence in the code.
In the late 1990’s, website developers recognized the need for speed and agility. New features could be deployed to the world in a moment’s notice if this could be done reliably. As a result, the need for automated testing became apparent. Until recent years, it was presumed by most that medical devices should be developed with a waterfall approach. One of the early pioneers of incorporating Agile software methodologies into medical device software development was Kelly Weyrauch, co-author of TIR45. Kelly provides an exceptional overview of this in the SOAR™ (Software Online Agile Regulatory) Training.
2. Lack of Separation of Concerns and too much coupling in the code base
This happens when code is written and monolithic objects are created that are not properly decomposed. Coupling is well known in the industry and is what occurs when software has not been decomposed cleanly. The best visual here would be that too much coupling in the code base is the equivalent to gum in your hair. Once there is lack of separation, everything is just stuck together. At this point, code becomes hard instead of loose and therefore, ossified. When you are doing agile software development, you want your code to be malleable to change. By doing so, your code is able to respond to unexpected requirements easily and without a lot of effort. When you have hard, ossified, coupled code, you are not able to respond to surprises and adapt. Essentially, agile software engineering is about trying to write your code in an adaptable way so it is soft and malleable and not hard and ossified. Sometimes, we inherit legacy code that was not developed using agile engineering techniques. There are processes to fix legacy code and clean it up and detangled it. You can do that as you introduce automated tests as well. At BeanStock Ventures, we have undertaken projects like this and we are comfortable doing so. However, fixing technical debt can take a lot of effort, so avoiding it in the first place is the less expensive approach.
3. Lack of emulation – external dependencies
Medical device typically has external dependencies on hardware and firmware but often lacks emulation. At BeanStock Ventures, when we develop software, we emulate our external dependencies such as hardware, databases, and network services. Emulation allows us to operate in a pure lightweight software space so we are able to move quickly. One of the most typical scenarios we encounter in our consulting is where the software development teams are blocked from having access to the physical device or instrument. The can happen for a variety of reasons throughout a program and necessitates that the software development needs to be done onsite in order to have access to the physical device. By having emulation, that dependence and delays in the schedule can be avoided.
Agility and agile software development is about being able to react and be adaptive when disruptions or surprises occur. One disruption is losing access to an instrument because another team needs it. A lack of emulation during the surprise and disruptive COVID-19 era would have slowed down innovation significantly as employees had to work remotely. Further, without emulation, the process is slowed and surprise impediments could arise. For example, most organizations have finite instruments and if other teams need to use the available instruments, it causes disruptions in access to the instruments and therefore slows down software development. By doing agile software development and automated testing, you are able to confidently work in a pure software space by leveraging emulation. As a result, the software development team is able to keep performing and the dependence on the physical hardware is removed. Additionally, emulation also allows you to run your code faster. For example, if you are working on an instrument itself and there’s a mechanical action, that mechanical action could slow down the process. In comparison, if you are working in a pure software space with emulation, you are able to run as fast as the computer can keep up instead of waiting on the physical world.
4. Not Hiring the Needed Skill Sets
Traditionally, software engineers with hardware experience were utilized for medical devices. These engineers do not consistently have Computer Science backgrounds or Agile development experience. The hardware skills are valuable, but usually trade off against software focused skills, which can cause them to be a little light on software engineering best practices. In the past, when medical devices were not integrated with the cloud and were stand-alone devices, the most relevant extra skill was for software engineers to have some hardware expertise. In the integrated world, there is an increasing need for agile software development because an integrated device is exposed to more change. The malleability that BeanStock Ventures infuses in the software we develop makes it highly amenable to an integrated world. The integrated world that we now live in consistently introduces surprise requirements. The organization may establish a relationship with a cloud vendor or other services. These strategic changes that are made at the business level need to be supported by the ability to adapt in the software code. The software code needs to be adaptable to changing business requirements in an integrated world. Some organizations may not need this level of software expertise continuously and that’s where BeanStock Ventures can be of assistance. The BeanStock Ventures team is extremely well versed in current best practices and compliance.
5. Tactical Focus Sometimes Causes Lack of Alignment
Often many project teams have to deal with the minutia of a lot of different processes in the organization. The organizational noise can create distractions that cause teams to lose focus on the corporate goals and objectives that the stakeholders are expecting. Working with consultants such as BeanStock Ventures can ensure that you have the modern, up-to-date expertise of software development and regulatory to ensure that total cost of development is minimized and certainty in the product delivery is maximized. The reason for much of BeanStock Ventures software engineering best practices is to reduce the total cost of development. Ultimately, our experience with the first four points and knowing what to watch out for in other areas creates well-written software that is Agile and delivered in a timely way to ensure the best time to market and the ability to adapt the software post-launch.
