Legacy App Rebuild for Medical Manufacturer
When a slow and steady route to rebuild is safer
What started as augmentation of an existing app lead to a full rebuild for this highly regulated medical device manufacturer. Along the way we acquired the knowledge and earned the trust necessary to work on an app supporting equipment that save lives.
For several years we have partnered with an international medical device company servicing the healthcare industry. Their products address medication management and patient safety, and must adhere to strict regulatory and compliance protocols.
We have worked with them on multiple projects in the areas of development (contributing code to existing applications, both rewriting and writing apps from scratch); manual testing (verification and validation or V&V); and automation testing (UI, unit, smoke testing, and more).
As a company of their size and scope, employing roughly 15,000 people, we are sometimes recommended from one internal team to another, but we have to prove ourselves in each case.
In this case we were asked to help the client expand a device testing app used with medical devices like infusion pumps, syringes, and patient care units (PCUs). The app allowed the client’s field service engineers (FSEs) and end user customers (primarily biomedical engineers at hospitals) to test and access data specific to a particular device. The primary function of the app was to ensure that a device is functioning properly before being used in a patient setting.
The app worked well and as intended on a per-device basis. It continues to be used today as the main tool to test individual medical devices by both the client’s FSEs and their end user customers.
The problem was that FSE’s usually have a team of technicians that work on up to 6,000 devices per deployment. The FSE’s needed a way to aggregate testing data across multiple devices. They needed to track which devices had been tested, which tests had been performed, which tests had yet to be completed, and prepare aggregate results in these areas.
To address this need the client had used Access, the database management system (DBMS) from Microsoft. They augmented the functionality of the per-device app to allow multiple users to document all devices that had been tested, any that had failed and where, and the number of devices ready to be used with patients. The augmenting app was an additional tool designed to help FSE’s monitor and control work done by multiple techs on multiple devices and to have a sense of overall progress on projects.
The problem was that Access was not ideal for maintenance and extensibility in this situation. Because Access is macro-based it required workarounds to provide the FSE’s the reporting they needed. One table would reference another in a disorganized way and there was little understanding of how a modification in one area would affect other areas.
Also, adding features took time and involved a greater chance of errors due to interdepencies and the limitations of the Access database for the intended purpose. Lastly, the client had only one person internally who knew how it was built and this put the client in a position of zero knowledge transfer, backup, or redundancy.
Where we came in
We were asked to add a side tool to the Access-based app to allow for more reporting and look-up functionality. Our technical contact within the client’s internal team was John, a field engineer and senior analyst. He was a seasoned, well respected technical authority with 30 years of experience. He had developed the Access-based version of the app.
We gained the client’s trust by addressing their immediate pain point and respecting their processes and current methods and tools. Our hope was that after addressing their immediate request we would have the opportunity to suggest other approaches to the overall architecture and tools for the multi-device app.
In addition to John, we worked with the implementation supervisor in technical services, and the product implementation manager in professional services. The Integrant team included a project manager, two developers, and two QC engineers.
John was skeptical at first. He knew the Access-based app lacked the functionality, UI, extensibility, and maintainability he wanted. But he did not want an outside entity coming in and potentially undoing the work he had done to date without a clear understanding of what the users needed. He did not want to risk leaving FSE’s without a working tool.
Working very closely with John as well as directly with the Access-based app, we acquired a thorough understanding of the technical functioning and business logic behind the existing tool. We performed the reporting and look-up augmentation in the form of a separate module. In this way John saw our help as a means to grow functionality while also protecting the app the FSEs depended upon.
When John and other stakeholders saw the functionality of the side module and introduced it in the field, the feedback was that this separate module was more user friendly and had better UI than that of the existing app. So instead of asking us to continue to maintain and augment the Access-based app plus the separate module, they asked us to replace and rebuild the app entirely. We would be moving away from Access and creating the app from scratch using our code and UI.
John became not only our internal technical guru but also a champion of the new tool being built. His knowledge of the field and the technology supporting it was invaluable as we defined our approach. We did not have a wire frame, just requirements. We also didn’t have reference points or documents for the Access-based app. We reverse engineered it and rebuilt it into our code and UI.
The project was mainly built using .NET/WPF. For the data access layer we used Entity framework and SQL Server Express. We also used the open source projects mentioned in the below posts:
In the field today
Currently John serves as a senior field service engineer and the expert for the new app, training FSE’s and providing feedback to us regarding new functionality and reports that would be helpful. The new app is maintainable and extensible, and we continue to add code with no problems in the field. The Access-based app supported two reports whereas we now have 10 supported reports. We hear from the FSEs that the user experience and usability (UX) are making their daily work easier and allowing them to focus on the work instead of reporting activities.
In addition to the app rebuild project, the trust we engendered between us and the technical expert on the Access-based app was very rewarding. As the project progressed through various phases we came to a point where John and the Integrant team truly acted as one. To us, that was the best reward.
We look forward to partnering on more projects with this client down the road.