How to Develop for Compliance… and Safety – InApps 2022

Not surprisingly, mobile health apps have more development and testing requirements than a regular consumer app. And when things go wrong, it doesn’t just mean deleted apps, but costly and lengthy recalls. This means these apps don’t just require testing before release but constantly through the product’s entire lifecycle.

While there may be more hoops to jump through, who wouldn’t want to delve into the mobile health app space when they could have the opportunity to reach a whole new market, and maybe even save some lives? We talked to a few experts in the mobile health space about how to get over those hurdles and make sure your app is compliant from spec to API to release, and everything in between.

Risky Business

First lesson: Know IEC 62304 Before Even Starting to Develop in Mobile Health App Space.

Mobile Jazz works with medical companies developing apps like one that monitors a child’s temperature overnight. Its team lead Joan Martin says one of the most important things to pay attention to is international standard IEC 62304, the regulation of the software lifecycle process for medical devices in both the European Union and the United States. This standard covers software planning, requirements, architectural design, implementation and verification, integration and integration testing, and releases and maintenance.

IEC 62304 includes a basic safety requirement where you run a risk analysis on your software, which will determine a development plan meant to mitigate these risks and provides a guide for many of the testing parameters.

You also need to test for the essential performance requirement of accuracy, measurements, and capabilities. Here, every item needs to be tested for “intended us versus unintended use” always asking the question:  if the app degrades, will it create a risk for the patient?

For the temperature monitoring app, it’s about making sure that the right data is fed into the app. You also need to test for what happens if your application programming interface (API) feeds the wrong data.

According to this presentation by the regulatory consulting firm Method Sense, everything comes down to not only following certain processes but documenting all activities around them.

Now, IEC 62304 doesn’t give you specific guidelines for organizational structure nor documentation, however, as a mobile app developer who is foraying into the medical software space, you need to make sure that your company, in general, follows a standard software development lifecycle procedure with transparent documentation from the start.

Not Just an App

It’s not just about your software and the mobile device it’s paired with. A lot of medical apps have third-party variables, protocols and thus regulations that maybe don’t affect typical consumer apps.

“In some of our health-related apps, we have backends but we also connect via Bluetooth or beacons or specific libraries that we put inside our application that help us measure the movement of the patients, like muscles and exercises,” Martin explained.

He says all of this has to be tested. For example, for Bluetooth-related tests, at a high level, there is usually a list of requests that you do.

Then they also build integration tests, testing the API and the app against all of these external variables.

“In an asynchronous way, we can test the Bluetooth or beacon, put waiting times and responses,” he said, further commenting that, “You think Bluetooth is simple, but it is internally harder to request because each device has its different protocol.”

Method Sense also points out that technically the certifying body will only consider your essential performance and basic safety, but, if you haven’t partitioned these aspects of your code, then they really will inspect the entire software, which will, in turn, have to be compliant, instead of just those sections.

Needless to say, documentation is key here to meet the traceability requirements including not only documenting each major phase but the relationships between phases.

“If we write spaghetti code, then it could not be tested. You have to write the test and document that test. You have to have it in mind before you start developing,” Martin said.

He continued to point out that when you develop the app and its code, you need to develop it related to a use case requirement. All code, including the API, must be mapped to specific use cases and then tests.

While this all sounds like a lot of paperwork, according to what Anil Kumar wrote in the Medical Electronics Design Journal, “Qualified, well-integrated tools ensure that developers can automate the process more easily and efficiently.”

He argues the cost of automating testing the entire stack, as well as automating as much of the documentation as possible, is far cheaper than the cost of recalls.

By maintaining API documentation with an automating language like Swagger, you then can also make sure the apps built on top of your medical API are better prepared for their software process and documentation too, making for a better overall developer experience.

Of course, Martin pointed out that it gets easier the more experience you gain in medical and healthcare apps. Mobile Jazz has even created an IEC 62304 documentation template that allows them to map out code to compliance.

“Whenever we have a new startup in the medical health space, [we ask] ‘Do you have to comply with this?’ If they say no, we ask why not, otherwise we know which documentation they need.”

Testing Can’t Happen in a Bubble

Another thing to remember is that when you have medical software, these become deeply personal and are often worn by the users who — though they probably shouldn’t — take the information in an app as seriously as they would their doctors.

Acknowledging this, Mobile Jazz also has partnerships with different organizations including a hospital in San Francisco in order to gather feedback. Martin says sometimes they will catch bugs, but their involvement is particularly significant for user experience improvements, like “Patients like this more than this. They don’t use this feature.”

He calls this high-level UX testing. “If it doesn’t crash and everything more or less is fine, what matters most is that the users like the app.”

He says that obviously, this doesn’t work when scaling an app to millions of users. For clients like that, they run a battery of tests, particularly running asynchronous tests on the API where the data structure does not change.

He admits this is for a client who invests a lot of money into testing, “but that’s not the usual case for us as we have a lot of startups.”

At Mobile Jazz, they like to stand out for actually not having a testing team. Instead, they try to involve a lot of clients into the integration tests. Martin says that the team collaborates on creating tests and documenting them.

“We work a lot with Google Docs, creating spreadsheets for all use cases we have to write for a specific app, so we have columns for iOS and Androids and Windows, developing the tests,” and then filling in results of those tests.

Feature image via Pixabay.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Bubble.