This blog contains the video, shortcut links to different segments of the video and a detailed summary of the conversation from our September 29th Agile eQMS demo.
In the development of Software as a Medical Device (SaMD), there’s often a tension between moving at the speed of Agile and adhering to a Quality Management System that is document-based, which can be tedious to maintain.
An electronic Quality Management System (or eQMS), like the one recently deployed internally by Orthogonal, keeps up with the pace of Agile SaMD development by plugging directly into the tools that development teams already use for their work. This data-driven, automated approach to eQMS can give your organization a huge competitive advantage, enabling the production of a continuous stream of successful devices that improve the health and quality of peoples’ lives faster.
Orthogonal hosted a webinar featuring a live demonstration of our Agile eQMS on September 29th, 2022, as part of our Move Faster and Break Nothing Webinar Series. This webinar set out to answer two questions: What does a modern eQMS look like, and what does it mean to have an eQMS that is an accelerator to your development process rather than a drag?
Sound enlightening? These attendees sure thought so, and shared the following feedback with us after the event:
Orthogonal continues to host events and conversations aimed at improving patient outcomes and driving business results. Keep up with the schedule of events throughout the rest of the year by signing up for our mailing list.
The following is a summary of the webinar’s discussion, edited for conciseness and clarity.
Fast Agile software development vs slow medical device hardware regulations
Bernhard: Software as a Medical Device (SaMD) and connected device systems are both software and medical devices, which move at different speeds. Software is fast. Software is quick to change and easy to distribute. Sensors, connectivity, mobile and cloud are becoming more pervasive, more powerful and evolving faster. Feedback on data and outcomes is fast and cheap to acquire. And unlike traditional medical devices, software lives in environments that we don’t fully control, like the cloud or the devices your SaMD will run on.
SaMD developers have adapted to these challenges and opportunities using Agile methods. Agile is specifically designed for change and uncertainty, using iterative development cycles that let you make adjustments along the way. Agile methods leverage automation to make builds, testing, distribution and rollbacks faster, and result in more robust, resilient, useful and adaptable software delivered faster and cheaper.
Medical devices, on the other hand, are slow. When we develop a medical device, we’re dealing with patient risk, medical efficacy and regulatory standards like quality management and design controls. These standards were written based on hardware manufacturing, which is not fast to change or distribute. They were created well before software was important to medical devices, before Agile methods were developed and before the Internet became central to everything we do. As a result, they were written assuming that waterfall development methods would be used. That legacy has resulted in processes still being used to this day that move slowly and change slowly.
As a consequence, when you bring software and medical devices together in the creation of SaMD, you end up with an impedance mismatch. Even if the development is Agile, if the processes for regulatory compliance, design controls, risk management, etc., are not Agile, then you don’t get the benefits of Agile. Instead, you end up with the worst of both worlds: less adaptation to change with more extra work, for little to no gain in safety, compliance or outcomes. This leaves developers and quality and regulatory folks feeling frustrated and overwhelmed.
But it doesn’t have to be this way. Regulations and standards don’t prohibit Agile methods; they just don’t make how to implement them obvious. That’s why we turn to AAMI TIR 45, IEC 62304 and the various cybersecurity guidelines and standards that were designed for a modern computing world. There are even new guidance documents in the works, like the upcoming AAMI TIR on cloud computing, that makes Agile more accessible for regulatory work.
Ultimately, the key to harmonizing the two halves of SaMD is not to make Agile development less agile, but to make non-development activities more Agile. One of the key building blocks to making all of this work seamlessly is the tooling for an electronic Quality Management System (eQMS) and Application Lifecycle Management/Product Lifecycle Management (ALM/PLM), which we’ll be focusing on today.
The origins of Orthogonal’s eQMS
Bernhard: Orthogonal previously had a standard document-centric QMS for managing requirements, specifications, risk management, verification, traceability, SOPs, etc. At the same time, our developers, project managers and QA folks were working in Jira, Confluence and GitHub. There was a lack of synergy between those software development programs and the document-based QMS. People weren’t looking at or working on the same things in the same environment. As a result, we had wasted effort, longer timelines and documentation for documentation’s sake.
We wanted to get the whole team working in one system, where modular design and Agile practices could be extended to design control activities. This system would have minimal developer disruption, so our developers could use the tools they’re familiar with to integrate iterative work on requirements architecture, design, risk management, verification and validation and traceability. We also wanted documentation to be an automated output of the work being done, rather than extra work on top of development. We believed this would increase quality and reduce costs and duration of the design controls part of the overall process.
Melissa: We treated the creation of our eQMS like any project we work on. We defined the requirements for what the system needed to do for us, the functionality it needed to have, and the value we were looking to get out of it. As part of a competitive analysis, we looked at the eQMS options out there on the marketplace that were separate from Jira and Confluence. We also researched what integrations were available for Jira and Confluence.
In our evaluation process, we discovered a couple big things about QMS tooling. If your software teams are working in Jira, you have the option to build something onto Jira and Confluence’s systems, or you can integrate another system via Jira’s API. Issues can arise when data is managed in two systems. It tends to lead to doing everything in Jira, and then, at the end of the development phase, transferring a large amount of data into the second program to begin the document-generation phase. We wanted to avoid this very scenario.
We found a series of add-ons for Jira and Confluence, primarily from SoftComply and Comala Document Management, that allowed us to do what we set out to do – develop and document efficiently in one program. The add-ons facilitate the Agile process by keeping our software teams working where they are and incorporating documentation seamlessly into their work. They take advantage of the integration and information that our teams capture in Jira to generate documentation automatically. We worked directly and in very close collaboration with add-on provider SoftComply to speed the configuration of relevant apps, saving us at least 3 months of figuring out everything ourselves.
Click through the timestamps to hear about each individual topic.
Jira Demo: 14:28
Access the websites for the add-ons/apps used in Jira with the following links:
Confluence Demo: 28:48
Access the websites for the add-ons/apps used in Confluence with the following links:
Bernhard Kappe, Orthogonal CEO and Founder
Bernhard is a software development leader, technologist, and pioneer who provides clients with an unequaled advantage by helping them develop Software as a Medical Device (SaMD), Digital Therapeutics (DTx), and connected medical devices, while leveraging important trends and techniques at the leading edge of the adoption bell curve (e.g., agile software development, lean user experience, software product management, DevOps, lean startup, and open-source software). Bernhard has exclusively focused on the medical device and health-tech industry for almost a decade, working with clients to create innovative diagnostics, monitoring, and therapeutics solutions, while shortening product development life cycles, improving delivery predictability, and creating products that are financially and clinically successful.
Melissa Gill, Principal Product Owner
Melissa has 10 years of experience in Agile Project/Product Management and four years of experience in QA. She has worked in enterprise, security, pharma and SaMD industries on web, mobile and cross-platform projects. Melissa brings her experience implementing Jira/Confluence and Agile processes at numerous organizations to Orthogonal, where she also implements eQMS tooling and process improvements.
Randy Horton, Chief Solutions Officer
Randy has spent the majority of his career working with healthcare and life sciences organizations to tackle the Quadruple Aim: 1) optimizing health system performance by improving the individual experience of care, 2) advancing the health of populations, 3) reducing the per capita cost of care, and 4) enhancing the work-life of those who deliver care. Randy brings strong experience, expertise, and creative business thinking to his leadership role – along with nearly three decades of experience with Internet-enabled digital transformation and a passion for being a connector of people and ideas. He helps organizations break through to their “what’s next” by building new capabilities and launching innovative, digitally enabled – and highly successful – products and services.