Connected medical devices or (medical IoT – Internet of Things) outnumber people.
This is an article David wrote about 1.5 years ago. It is a good general introduction for the layman to the challenges of developing connected medical devices in clinical trials but it is not a technical treatment and doesn’t get into the really nasty things that can happen. If you are a software engineer with devops experience, you will want to pay attention to the part in the post that talks about validation.
We’ll leave the nasty stuff for another post.
Why bother with medical IoT? Coolness or Compliance?
Increasingly, connected medical devices are used for treating a wide variety of indications, from diabetes and blood pressure to migraine headaches. So the first reason is that its cool and fashionable to connect Apple watches to clinical trials.
The real reason to use medical IoT / connected medical devices in your trial is to collect data from the patient and ensure patient compliance to the clinical trial protocol. Use of medical IoT, wearables, watches and device apps can close the monitoring gap from weeks to seconds and make SDV a thing of the past.
Connected medical devices – system design alternatives
There are 3 general design alternatives for connected medical devices – device at home, device+phone, software as a device.
Device at home to cloud EDC
The simplest configuration is a device that connects to a home WiFi network and transfers data to the EDC.
Device + phone to cloud EDC
Medical IoT (aka connected medical devices) rely on a mobile phone for both connectivity and User interface at the patient end-point and on cloud services for data storage and application-layer logic and processing.
This enables medical IoT to be thin, focus on the medical device functionality without having to deal with UI, connectivity and more complex data processing functions.
In this configuration, we believe that medical IoT will soon become the sensor of choice for collecting data about the patient, the treatment he took (or did not take) and relaying data to the EDC and real-time remote monitoring services like Flaskdata.
Software as a device to cloud EDC
In terms of numbers, the most popular configuration is “software as a device” or mobile medical app.
As of a few years ago, there were already one million health apps from 62 app stores available. The cloud application of mobile devices as medical devices makes a lot of industry sense, as data can be sent, studied and responded to in real-time.
Rest API for ingesting data and offloading data processing
Cloud EDC that interfaces to a mobile medical device using a REST API allows processing to be moved from the device endpoint to cloud servers and enables remote improvements, upgrades, and security patches to be implemented without changing the device.
Why medical IoT is outside your comfort zone
Drug trials are often considered more complex than device trials (more than one CRO told me disparagingly that “drug trials are much more complex than device trials“) but recently we are seeing very complex data models for connected medical trials that are non-standard and involve complex API integration and cybersecurity requirements. This kind of complexity is a different kind of challenge from drug logistics and inventory management which is familiar territory for CROs.
Connected medical devices will also need to consider FDA cybersecurity guidance as well as possible requirements for compliance with HIPAA and GDPR if you collect personal data in the app and interfaces between user and mobile device.
You cannot just develop a smartphone app that integrates with a medical device and deploy.
The integrated system of app + device (or app) (or device) needs to be validated by a professional third party that specializes in medical device software V&V and understands the intended use of the device and the nuances of validation.
After you V&V your connected device then you should do a security threat analysis and privacy compliance risk assessment or face the risk of having your cloud data hacked via the entry point of your medical IoT.
In short – medical IoT in your clinical trial is probably outside the comfort zones of your CRO, your VP Regulatory and your engineers. No one is happy.
Medical IoT – develop, integrate and validate
Best practice devops, CI/CD (continuous integration/continuous deploy) are very relevant for development of connected medical devices but there will be an additional required step for V&V – verification and validation.
Development
When it comes to developing a mobile app to connect with your cloud EDC, there is much more to the process than just designing a user interface that is logically arranged and aesthetically pleasing. It important to consider that the device will no longer be simply a smartphone or tablet anymore – as per the FDA (and similarly the EU) it becomes an actual medical device once the app is approved and installed on the device, whether natively and marketed as a medical device, or by a third party on a mobile that was not marketed for its intended use as a medical device.
Usability
Regardless, during design and development it needs to be kept in mind that before you connect the device to your EDC it will need also need usability testing. After all, this is a medical device that will be put into the hands of doctors and patients and can (and will) have an impact on the patient’s health.
During code development, keep in mind that users may make mistakes, misunderstand your UI, and do the unexpected. So there should be safeguards to ensure that an erroneous use of the device does not easily occur. For a simple example, not placing “yes” and “no” buttons close together. When designing the app the following (amongst others) needs to be accounted for to ensure validation after development is complete. Before integration – go through a checklist and make sure you are ready for validation, otherwise you will pay heavily in rework.
Validation readiness checklist before integration
2. Hardware requirements
3. Warning and error alarms
4. Patient/doctor communication
5. Cloud security measures
6. Software updates
Integration
Integrating your mobile device with your cloud EDC is more than just developing, distributing and installing an app. Integrating a mobile device with EDC requires use of a robust well-defined and secure API between the mobile device and the EDC server and database. The reason why is that, unless your clinical trial is using bespoke mobile medical devices for the EDC system, doctors and patients are going to be using their own smartphones and tablets.
In order to ensure that the API will function properly across different versions of Android and iOS, we require use a secure REST-based API over SSL that authenticate to an identity provider – typically using JWT – JSON web tokens
A crucial requirement and challenge is to maintain a stable version of the API since changes in calling sequences or typing may break the API service on the app client or break it on the EDC listener side.
Validation
The final step before you can implement mobile devices for use in your medical device clinical trials is validation. Validation is rather straightforward if you have been working with an experienced V&V provider, but it is a necessary step to make sure that device will pose as little risk to patient health and that the the data will be secure using the cloud.
Manufacturers must establish and follow quality systems to help ensure that their medical devices consistently meet applicable requirements and specifications and the design controls authorized by the Safe Medical Devices Act. For more information see the FDA guidance on quality systems
Your quality system should address hardware, software validation and cyber-security risk, distribution and sustaining a secure device in the field.
Deploy
So you finished development, you integrated and validated and now you’re ready to deploy to a test environment where your medical IoT can send data from simulated patients to the cloud EDC.
Mazal Tov – you are now jumping head-first, eyes-shut into the cold water of connected medical devices in clinical trials.
My only advice to you at this point. Test often on your test system. Not on your production EDC.
Let me know how the water is.
