How Software Architecture Enables Faster Release of New Clinical Tests to the Market

The ultimate goal of developing a medical device is to receive FDA approval and to be able to release the device commercially. Once a medical device is released, many benefits can be realized, including improving the health of the public at large, improving the efficiency and/or safety of healthcare workers, and recouping the investment in development of the medical device.

Regarding the investment in releasing a medical device, the typical length of time required to bring a medical device to market from concept to FDA clearance is 3 to 7 years, at an average cost of $31M, (for a device that follows the 510(k) pathway).

With this level of time and cost investment, makers of medical devices need to maximize the time their device will be on the market and gain return on their investment.

For makers of In-vitro diagnostic (IVD) medical devices, the path to initial FDA approval is generally narrowly focused on a single intended use, or single type of clinical test. For example, a medical device maker may focus on testing for Flu-A and Flu-B in their initial FDA submission, but have long-term plans to submit and receive approval for many other follow-on types of tests (RSV, Strep, Pneumonia, etc.).

The IVD device is carefully designed, from a hardware and biological perspective, to support detection of many types of disease conditions over the longterm, with the goal of submitting and receive approval for follow-on tests as rapidly as possible to ensure the long-term market viability of the particular IVD medical device.

This IVD “re-usability” approach is a great strategy and it benefits the public, healthcare workers, and the medical device company, if executed well. However, what can often be neglected in defining an IVD device’s re-usability strategy is architecting and ensuring the software components of the IVD device are capable of being wholly or mostly re-used for additional intended uses.

FREE WHITE PAPER: Click here to download the PDF of 'Reusable Software for Clinical Test Management'

Benefits of Software Re-Use

Software that is part of an IVD medical device must be verified and validated for all releases of the medical device that are submitted to the FDA for approval. Based on RND Group’s historical experience, verification and validation can cost in the range of $500k-$600k and can take 5-7 months calendar time to complete for an initial release to the FDA.

This is a significant cost, and more importantly, a significant length of time, that, if performed for each submission to the FDA, can derail the IVD “re-usability” strategy.

So, how can software architecture reduce the time and cost required for software verification and validation for second and subsequent FDA releases? The first thing to understand is the relationship of risk planning to software verification and validation. Simply put, software that does not change (and can be proven to have not changed) can avoid having to be re-verified and re-validated, based on documented risk analysis.

So, if an IVD manufacturer can externalize the differences between different clinical tests (e.g. intended uses) performed by the IVD, the testing – software verification and software validation, not to mention non-software types of testing like mechanical, electrical, and clinical trials – can be predominately focused on the specifics of the new clinical test.

This risk-based testing that does not require re-testing of all aspects of the IVD and software will reduce the cost and duration of follow-on submissions to the FDA.

Understanding Software Architecture

The terms “software architecture” and “architecting” have been mentioned a couple of times already, but what, exactly, is a software architecture? Similar to how buildings are constructed from an architectural plan or blueprint, well-designed software is built from an architectural plan that defines how the different components and layers of the software interact.

Complex software is built of multiple layers on top of one another, with each layer providing an abstraction, or higher-level concept than the layer below it. For example, the lowest layer deals with the physical hardware that the software is running on and issues machine instructions and manages timing control of the hardware.

This lower layer, in turn, provides an abstract, higher level interface used by the layer above it. The higher layer is likely still hardware-focused, but is dealing with concepts like “start a pump device” or “stop a pump device” and is abstracted from the detailed machine instructions necessary to “start” or “stop”.

This layering continues all the way up to the user interface layer where a human operator has the ability to push or click an on-screen button to start a high-level operation. An example high-level operation is initiating a sample processing run, which involves controlling multiple mechanical and electrical components on the IVD device and performing a workflow of steps defined for the sample run.

Software that manages complex operations such as controlling an IVD device must be architected to have each layer or component managing a subset of the overall operation in isolation, much in the way a building architecture combines different subsystems like electrical, plumbing, flooring, and heating that operate in isolation, but, when combined, provides a single integrated solution – the building.

In addition to defining the software layers and components and their interactions, software architecture defines common types of services that all layers and components need to interact with, such as triggering and responding to error conditions, managing security, validating data inputs, logging diagnostic messages for support purposes, and generating audit messages required by regulations like 21 CFR.

These common services are often called “cross cutting concerns” in the context of software architecture. An example software architecture diagram illustrating these concepts is shown below.

Architecting for Rapid Release of New Clinical Tests

Armed with some knowledge about software architecture, how can architecture be applied to the problem of rapid release of new clinical tests? The first step is to identify all aspects of a clinical test that IVD software must manage, including:

1. Managing loading of specimens (samples)

2. Managing loading of consumables (like reagents) required to perform a clinical test on a specimen

3. Managing controls and calibration to ensure the clinical test is producing accurate results

4. Performing the specific and unique processing steps on the IVD instrument hardware to execute the clinical test on the sample

5. Reading and measuring the clinical test outputs produced by the IVD instrument hardware

6. Interpreting the outputs and calculating qualitative and/or quantitative results

7. Presenting the calculated results to the end user of the IVD

8. Reporting the clinical test details (sample, reagent, controls, results)

The second step is to define an abstraction, or interface, for managing the above actions that are required to perform a clinical test. The interface defined in this step will define the subsystem for clinical test execution within the overall software architecture.

Getting this interface definition “right”, in the sense that it supports future clinical test types without requiring the interface to change is critical. If the defined interface is stable, the rest of the overall IVD software that uses the interface will not have to change. And, if the interface does not change, the greatest degree of software re-use and the least amount of re-verification and re-validation will be achieved.

So as to not oversimplify, the defining of a stable, “future proof” interface is a significant challenge and involves examining as many anticipated (future) clinical test types as possible to accommodate for individual clinical test-specific needs in a way that does not affect the interface for all other clinical tests.

FREE WHITE PAPER: Click here to download the PDF of 'Reusable Software for Clinical Test Management'

Applying the Software Architecture

The software architecture and the concepts described for managing clinical tests in an abstract way is only useful if it solves a real problem and can be applied in an approved IVD medical device.

Thankfully, RND Group has applied the approach described in this document for many of its customers and each of those customers have released more than one clinical test that take advantage of the “clinical test abstraction interface”. These customers have all benefited from the described software architecture in significantly reducing the costs and time required for subsequent clinical tests released to the FDA.

In addition, this clinical test abstraction interface has been incorporated into RND Group’s Application Accelerator software architecture framework and is available for use by any medical device company that wants to leverage the ability to release multiple clinical tests on the same IVD medical device.

The RND Group is partner of Greenlight Guru. To learn more about their services and schedule an initial consultation, please contact sales@rndgroup.com.

This article was originally published by The RND Group and is being republished here with permission.

Looking for an all-in-one QMS solution to advance the success of your in-market devices that can integrate your post-market activities with product development efforts? Click here to take a quick tour of Greenlight Guru's Medical Device QMS software →