One Company's Experience: Blazing the Trail With the First FDA-Cleared Medical Imaging App

The company provides practical imaging solutions for computer workstations, as well as mobile and cloud-based platforms, in the fields of radiation oncology, radiology, nuclear medicine, neuroimaging, and cardiac imaging. Our vendor-neutral solutions for multi-modality image review and fusion for radiology and nuclear medicine are sold globally to imaging centers, hospitals, specialty clinics, research organizations, and pharmaceutical companies.

MIM offers integrated packages for cardiac and neurological imaging with automated quantitative analysis, as well as a comprehensive suite for radiation therapy, which includes deformable contouring and fusion, data management, and practical adaptive therapy tools. Professionals can collaborate securely and reliably by sharing images from anywhere, at any time, with MIMcloud and Mobile MIM, a new remote diagnostic imaging app for the iPhone, iPod touch, or iPad.

We have been writing workstation software for medical imaging since 2003. We had no roadmap for mobile devices. However, many of us were already using the early iPhones and could envision that one day medical imaging would become portable. The release of the first software development kit for app developers in 2008 was the catalyst, and even though we had not developed on that platform before, we decided to try it out and see.

Fortunately, we have some fantastic developers, and in March of 2008 they were able to build a functional prototype in just one week. With a functioning and viable product in hand, our plans began to change. We added the necessary “bells and whistles” to make it into a fully usable app.

Apple got wind of the app, and asked us if we could present onstage with them at their Worldwide Developers Conference (WWDC) in June 2008. This conference announced the arrival of the app store, and several developers presented what they were able to create for the app store launch. Most of the apps were games, or for social networking, and there were two medically related apps. Our app was available free at the launch of the app store.

We knew from our existing customer base of radiologists and radiation oncologists that it's easy to be caught without access to a workstation. This app takes a complex desktop application, and places it directly into the hands of physicians and patients.

Many radiologists already use these devices. Our goal was to give them ready access to a diagnostic tool when medical necessity required it. For example, specialists are often consulted on difficult cases. With this app, specialists could give their opinion on medical images, even if they are on vacation. In addition, the app is very interactive with an intuitive interface; real-time, multi-modality fusion and blending; zoom and pan; and encrypted data transfer to an iPad or an iPhone.

We knew that the app was a medical device, and we knew that we had to go to the U.S. Food and Drug Administration (FDA) for regulatory clearance. Our app was a testing ground for the FDA team. We went through the painful experience of being the trailblazers, but since then quite a few apps have come through in other categories.

In August 2008, we submitted our first 510(k) to the FDA. On the iPhone, images are viewed under different circumstances than are typical for radiologists, such as radiology reading room lighting. This difference raises new issues of safety and effectiveness. Manufacturers have to submit a new 510(k) whenever there are changes in intended use, and it is necessary to address the issues of safety and effectiveness.

Within only a few weeks of submitting, the FDA told us that our app could not be on the app store even though it was both free and labeled as “not intended for diagnostic use,” because it served as marketing for a device that was not cleared for marketing. We immediately removed it.

So, we became the first, and possibly the only medical imaging app to ever be taken down from the app store—companies that manage to keep their products under the radar do not invite the scrutiny of the FDA. The initial 510(k) submission was denied on the basis that it was not substantially equivalent (NSE) because of insufficient data.

We ran additional clinical studies to bolster the application. This data took months to gather and prepare, and we submitted our second 510(k) on June 24, 2009, almost a year after the first submission. This time we received no feedback from the FDA. It was also denied, 221 days later, because they determined it was a new kind of device, not substantially equivalent to any predicate devices, and therefore a class III medical device requiring premarket approval.

In the end, the FDA changed their mind on it being a class III device and we submitted a third 510(k) in December 2010. We would have preferred the entire process take 90 days, as that is the FDA's intended goal. In the end, it took two and a half years and three rounds with the FDA to have the 510(k) application cleared.

The biggest technical issues arising from portability were display quality of the hardware and environmental lighting concerns. We didn't manufacture the iPhone hardware, and therefore had the challenge of demonstrating safe and effective use for “off-the-shelf” hardware.

Fortunately, Apple has a very controlled manufacturing system, which makes the display quality very consistent. The development environment was also stable, as much of the software written in 2008 is still running in today's version. Apple's ecosystem worked out well for the two and a half year regulatory process.

The environmental factors include variations in light and location. You want consistency in reading, but you can use a phone anywhere. This stands in the way of consistent viewing and quality image display. The FDA regulates industry, not doctors. We cannot promote something that gives different readings in different lighting, as that would be unsafe.

We developed a tool that when you open the app, brings up a black screen with a low-contrast grey square. If the ambient light is too bright, as in the sunlight, you can't see the grey square, and therefore, you know the environment is unsuitable for reading images.

If you see the square, you touch it and can continue with the reading. The FDA liked that. We also put in a step that lets you calibrate the grey-scale color so that you can correct for the natural characteristics of the screen and make the displayed images consistent. We even included a user guide in the app and added a touch of fun so that people will be more likely to read it.

We have a lot of customers sampling the app. It's hard to measure the numbers of customers actually using it. Currently, people who use it diagnostically tend to use it only sporadically, but for all kinds of imaging, including computed tomography (CT), single-photon emission computed tomography (SPECT), magnetic resonance imaging (MRI), X-rays, and ultrasound. The app is free, and the sample images are free. There is only a minor charge to use our MIMcloud service on a per-study basis. So we hope the app steadily grows in popularity over time.

The FDA has a guidance document on medical apps. Read it carefully! We were unprepared in our first round because we treated our submission as purely a software device. We learned that the FDA also considered the hardware, even though we did not manufacture it.

The way an app uses the hardware is very important. For example, in apps that measure blood pressure, the display quality is not a problem as it only shows numbers and not images. If you make an app for diagnosis, the display becomes important, especially because displays will vary on different devices. We built our own calibration using the software to address that variability.

Consider human factors when you are developing your app. For example, in many cases it is enough to include a warning label with the app, according to the intended use. In other cases, you will have to design the software to help ensure its safe use. The FDA is going to ask questions about the hardware, particularly on testing and risk assessment.

In addition, the chances are small that there is a predicate—a similar device—that exists for your device or software. You may have to point to a non-mobile device. We used workstation software as our predicate, and had to demonstrate that the technological differences didn't raise new concerns.

Bear in mind that whatever you state as the device's intended use, you will have to demonstrate in your 510(k). If you get too specific and state, for example, that the device or app should only be used in emergencies, you will likely have to demonstrate via clinical data how it performs in emergency situations. It is a good idea to be as accurate as possible when it comes to intended use, but avoid unnecessary details.

Clinical data may be needed. We are an existing company with many software products and many customers. A brand new developer might find the process harder. You would have to find doctors interested in and willing to follow testing protocols using your app. Team up with doctors who believe in what you are doing. The more people involved in the testing, the more reliable the results will be.

The process for getting cleared is becoming smoother. One of the problems is that some manufacturers are labeling their apps as “Not For Diagnostic Use” to bypass the process, rather than going to the FDA. We should have all been there working with the FDA and helping them learn more about this kind of device.

Hospital information technology staff and doctors have brought medical devices and apps into their ecosystem that have not been cleared, and this should not happen. Our goal is to have an app that is safe, useful, and good for patient care. Eventually, all physicians will carry a mobile device, and they want apps that are safe, usable, and have FDA clearance.

We have continued to improve our imaging software. The advantages for mobile medical apps will only increase as technology, speed, and interoperability improve. Doctors will be able to discuss diagnoses with patients while showing them their scans; patients will be able to store their data on the cloud; and rescanning, lost scans, and time-consuming patient data retrieval can be eliminated.