When Heroku removed their free tier, many people started to ask questions about what they should do next. There were a number of options. Pay Heroku, but do stuff yourself, move somewhere else free, but do it yourself, or pay for someone to host Nightscout for you.
The idea of paying someone else to host Nightscout for you wasn’t new, but what that means for those running the services does raise some questions.
Firstly, in the US, the FDA considers this type of activity to be a class 2 medical device. In Europe, dependent on what’s being offered as part of the service, it may or may not be a medical device and this may then fall under different categories, dependent on what is being offered.
So let’s start with some definitions for the European viewpoint. According to the Johner Institute, interpreting the EU Medical Device Regulations:
” Medical Device ” means an instrument, apparatus, device, software, implant, reagent, material or other item which, according to the manufacturer, is intended for humans and alone or in combination one or more of the following specific intended to fulfill medical purposes:
— diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
— Diagnosing, monitoring, treating, alleviating or compensating for injuries or disabilities,
— examination, replacement or modification of the anatomy or of a physiological or pathological process or condition,
— Obtaining information from the in vitro analysis of samples taken from the human body, including from donated organs, blood and tissue
and whose intended main effect in or on the human body is neither achieved by pharmacological or immunological means nor metabolically, but whose mode of action can be supported by such means.
So if we consider what Nightscout, when built, does, which is software intended to fulfill the monitoring of diabetes, it seems to fall squarely into the definition of a medical device. Even more so if Nightscout is used as the mechanism by which remote treatment can be administered
As has been looked at many times, if you build it yourself from the source, then it’s hard to consider it as something that anyone other than you is responsible for, in it’s “product” form, and you, as an individual bear the risks of using what is defined as an experimental software which should not be used for medical purposes.
This all seems reasonable.
But what happens when someone else builds it and runs it as a service?
That’s quite a paradigm shift, and one that anyone running a “Nightscout as a service”, or “NAAS” model needs to consider.
It can’t be coincidence that CamAPS is willing to partner with multiple monitoring services, as long as they have the appropriate certification.
Nightscout as a service
We’ve already established that Nightscout run by a third party is a medical device run by a third party, but what does that mean in the world of regulation and legal situation?
I’m not a lawyer, so I’m taking the EU Medical Device Regulations and figuring out how they might work in this case.
Firstly, Nightscout (or anything else that’s currently part of the “WeAreNotWaiting” stable) is code that’s released into the open that you individually build. In that case, as per a comment by one European regulator, it’s not a medical device.
As soon as you build it and offer it to others, it becomes a medical device and you, it’s distributor. That causes two issues. The first is that it is not a licensed device under MDR. The second is that you are distributing something that is an unlicensed device. Two breaches of the regulations, and it’s up to the local regulator as to how they deal with this.
Some jurisdictions take a harsher view than others.
And if you allow remote treatment of an AID device? That’s then more of a risk, as you’re dealing not only in display of data but also in delivery of drugs, which levels the owner with an additional risk.
If, for some reason, your platform delivers multiple doses of insulin and that results in hospitalisation, then there’s an additional legislative risk associated with that.
It’s also why the regulators demand that there are clear development and testing processes in place for approved medical devices and that there’s a person who is responsible for it.
So what are you saying?
Anyone considering using a NAAS service needs to consider all of the above.
Someone providing this type of service and not in discussion with their regulator is potentially causing concerns for both them and their users.
Not least of which is that a regulator may find out and shut down the service with zero notice.
It should also remind people why development and testing cycles exist in software platforms, and why they matter to the WeAreNotWaiting world.
At the very least, you need to ask any provider you consider using how they deal with development and testing and whether they’re in dialogue with their regulator.
Strong answers in both these spaces will help to alleviate concerns that a service might just disappear overnight.
Strictly, NighScout is not monitoring a disease, it’s enabling remote access to the data produced by a disease monitoring system — a secondary level service — which brings into doubt on your assumption that it is a disease monitoring system.
Thanks for your thoughts Stuart.
Diasend/Glooko is an MDR registered device that you’d also consider to be “secondary”.
Similarly, the MDR terms don’t seem to consider “Secondary” as a consideration as long as they allow for treatment decisions/adjustments to be made and monitoring of a disease to take place.
Finally, the ability to remotely deliver insulin by using a service fundamentally changes it from being a monitoring device to becoming an active treatment delivery device. In that state, it’s no longer secondary, and indeed has greater legal implications.
The major point of this post isn’t to argue the minutiae though, it’s to highlight the risks associated with some activities that are currently underway within the community and to allow those undertaking them to consider appropriate ways of managing those risks.
Hi Tim,
I appreciate your views. However, I personally don’t think the status of Nightscout is as clear cut as you present.
What you leave out in your analysis is the specific role of Nightscout. Sure, you use Nightscout when monitoring diabetes – but you cannot monitor diabetes with Nightscout alone. You need a continuous glucose monitor to do that. Beyond the CGM, pure Nightscout only transfers and displays the data. Even with commercially supported full CGM solutions, you usually use a mobile phone to transfer the data from the CGM into a cloud service. And the app Is a medical device, but the phone is not, neither is its operating system.
You might think that it is overkill to even consider whether the mobile phone in this scenario should be a medical device. But I’d like to point out that ten years ago the industry had a very different perspective, and back then it was considered practically impossible to develop a medical device that would run on a mobile phone. How do you guarantee that everything always works? The patient may adjust the settings of the phone so that there’s just black text on black background. This will render your app unusable, and a disaster follows. Yes, I did hear those arguments back then.
Anyway, perspectives and interpretations change. What I would lean on is the document MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR (https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_11_guidance_en_0.pdf).
It says, among many other things:
“It is important to clarify that not all software used within healthcare is qualified as a medical device. For example, “Simple search”, which refers to the retrieval of records by matching record metadata against record search criteria or to the retrieval of information does not qualify as medical device software (e.g. library functions).”
“However, software which is intended to process, analyse, create or modify medical information may be qualified as a medical device software if the creation or modification of that information is governed by a medical intended purpose. For example, the software which alters the representation of data for a medical purpose would qualify as a medical device software. (e.g. “searching image for findings that support a clinical hypothesis as to the diagnosis or evolution of therapy” or “software which locally amplifies the contrast of the finding on an image display so that it serves as a decision support or suggests an action to be taken by the user”). However, altering the representation of data for embellishment/cosmetic or compatibility purposes does not readily qualify the software as medical device software.”
In order to be considered a medical device, the software needs to perform an action on data, an action beyond storage, archival, communication, simple search, or lossless compression.
Consider a case where the Nightscout as a Service offering would not provide any of the graphical reports. It would just be the backend that different mobile and smartwatch apps depend on. The graphical views are, in my view, the feature that most clearly puts Nightscout into the medical device category. But without them, I don’t think the Nightscout as a Service would be considered a medical device.
I say this as someone who has actually gone through the trouble of CE marking a Nightscout as a Service offering (nightscout.fi) as a medical device, with good interaction with regulators. And as a representative of a company with a certified quality management system and an ongoing process of updating several of our medical devices, currently in Class I according to the MDD, into Class IIa according to the MDR. I’m still not convinced we should do that for nightscout.fi. The notified body we’re working with even has doubts whether we could certify it if we wanted, based on the MDCG identified above.
All of this is from EU perspective. I’m sure Ben West can chime in from the US one.
Thanks Mikael, I appreciate your contribution to the debate.
I think the places where concerns lie are the generation of analytical content such as AGP and Distribution data, which are very much used for making adjustments to treatment, and as I mentioned, the ability to deliver remote control of AID systems, which would put it squarely in the IIb classification.
I’d welcome your thoughts on this based on your conversations with regulators.
I think the implementation of the forecasting line in Nightscout clearly pushes it into medical device territory. This isn’t back-end reporting, it is “software which is intended to process, analyse, create or modify medical information…” and clearly has “a medical intended purpose” in guiding dosing decisions.