Tidepool will be mandated to follow the risk management requirements to mitigate any known or sensibly foreseeable risk, including the use of constructive safety measures (as opposed to alarms and instruction warnings). The hazards associated with DIY are probably too high to be accepted by regulator. The manufacturer’s liability may also be quite significant, especially in the US.
Of course, Tidepool will do whatever they need to do to get FDA approval. If they succeed, which I hope they will, the approval will allow them to distribute the approved Tidepool Loop app. At the same time, DIY Loop will remain an option for individuals who are interested in putting their own system at their own risk. Will be interesting to see how different Tidepool Loop will be compared to DIY Loop. My guess is that the differences will not necessarily be very large because, based on personal experience and anecdotal evidence, DIY Loop is already a well designed, effective and safe system.
I fear the differences may be quite large. I’m guessing the Tidepool version will have all kinds of impediments and misfeatures to satisfy the regulators, such as extra layers of warnings and confirmations, and restrictions that prevent setting targets as low as I want and automated corrections as large as I want. I have no inside knowledge about this, it’s just my pessimistic expectation of how far the FDA is presently willing to go.
And with the diy version we have the possibility of early access to experimental features that make it run even better, such as the more aggressive correction mechanism that dm61 is working on at https://github.com/dm61/Loop/tree/integral-retrospective-correction
Hi everyone. I’m Tidepool’s Community Manager. As you can imagine, this is a very exciting time for us. I wanted to address a few of the concerns/questions I’ve seen pop up in this thread. While there’s a lot that’s still TBD about the Tidepool Loop project, I can comment on our intent…for whatever that’s worth to you.
First, if any of you are curious about the conversations we’ve had with the FDA regarding Tidepool Loop, you can read the meeting minutes from our pre-submission meetings here - tidepool dot org slash documents (New users can’t post links). We talked with them about the Tidepool Loop application, as well as the upcoming observational study that will (hopefully) demonstrate the safety and efficacy of DIY Loop.
To release Tidepool Loop as quickly as possible, we do not intend to deviate too far from the DIY Loop code base. Changes that we make from the version of DIY Loop that is reported in the observational study mean more time, work, and validation beyond what will already be done. Changing the logo or interface is one thing, changing the core algorithm is another.
Obviously compatible devices will differ between the two projects, but beyond that, we expect the core Loop experience to be comparable. Work that we do on Tidepool Loop, where applicable, will find its way back into the DIY Loop code base - one of the joys of being an open source project.
With the resources and process we are putting behind Tidepool Loop, our expectation is the DIY Loop community will similarly benefit from our work - especially now that Pete and Katie are on the Tidepool team.
Of course, any developmental branches of DIY Loop you are running and comfortable with will always be yours to continue to tweak. DIY Loop is not going anywhere. The Tidepool fork is what we will be responsible for.
I’ll keep an eye on this thread in case there are more Tidepool Loop questions. Have a nice day!
Are you able to say more about this? Are you able to say whether the command interface to the pump will be protected in a way that enables Tidepool Loop to use it but diy LOOP can’t?
Certain parts of the Omnipod DASH integration, including the low level command interface, will most likely remain closed source and unavailable for use with DIY Loop. With all of Tidepool’s hardware partners, we encourage them to view security and open source as being non-mutually exclusive, but we must respect our partners’ requests for confidentiality regarding software that they provide us. All code that Tidepool writes for integration with hardware partners will be open source.
What do you mean by “low level command interface” ?
When you say certain parts of the integration will remain closed source then that could be strongly interpreted to mean that a non-Tidepool developer could simply write equivalent code themselves to provide the corresponding function.
Security and open-source are clearly not mutually exclusive. Any company which thinks they are providing security due to keeping their source code under wraps is confusing security with obscurity. There is nothing inherently wrong with obscurity and is an extremely effective layer but should never be confused with security or used as a replacement for security. (Assuming security is an intention.)
I have what would appear to be a similar question as @bkh does. I am not trying to be a PITA but the answer provided seems to dance around without providing a direct response.
So, to rephrase the question from @bkh from perhaps a different angle.
- Will there be security (completely unrelated to any discussions of obscurity or confidentiality or open source) implemented that will prevent the command interface of the pump from being used by non-FDA approved software.
By “low level command interface” I mean that pump manufacturers will generally provide us with an SDK. Whether or not that SDK is released either in open source or binary form, or released publicly in any form at all is up to the pump manufacturer. There will also likely be security provisions within that SDK that are required to actually communicate with the pump. What those might be would certainly fall under an NDA, so even if we knew what they were, we wouldn’t be able to discuss them. So the short answer is yes, we do expect there to be security beyond the SDK being closed source.
If one of our pump partners were to make the interface to the pump open and public, we would be very happy about that, and it would be an integration that could be available in both DIY and Tidepool Loop. We do encourage our hardware partners to consider this, and offer to help them in doing so.
(Also, no need to apologize for direct questions. We’re figuring out some of this as we go, so some of our TBD answers now will hopefully be more concrete as we get to a point where we know what Tidepool Loop will, and will not, look like. Questions from the community keep us honest, and demonstrate enthusiasm and engagement. That makes me happy and shows us we’re on the right path.)
Thanks for the info.
From my point of view, before I even get into what I do or don’t want, I like to understand the situation outside of any advocacy or desires.
@christopherasnider, I will be happy to make it possible for you to post docs. Why don’t you PM me and we can discuss what you need?
Unable to send a PM, you may need to start the dialog so I can reply.
Tidepool Loop will require a prescription. The mechanism and process for this is still TBD.
Android support is part of the plan, but the initial launch will just be iOS. Considering the foundation of the current Loop codebase, this makes the most sense to get to market soonest.
I can’t do much to alleviate your skepticism of Howard’s credibility. I know he’s legit, but he’s also my boss so my bias would likely cloud your perception of my response, too.
But his statement about reading every line of code was true before we took on the Tidepool Loop project. His daughter has been on Loop for nearly three years, and in his own words “there’s no way I would trust this system with my daughter without fully understanding everything it can and can’t do.” If you have specific questions about his credentials, I’d be happy to receive them in an PM and provide responses to your inquiries.
Part of the Tidepool process is to engage early and often with the FDA so they aren’t surprised by anything we do (as evidenced by the other meeting minutes published on /documents). As we have more meetings with the FDA about Tidepool Loop, we will publish meeting minutes as they are approved.
As more device makers (and devices) come on board, we will keep everyone informed.
You have a point. But, in the context of the pre-approval meeting, I do not think that statement makes absolutely any difference one way or another. If I were at the meeting, I imagine I’d probably have hard time not making some even more enthusiastic comments along similar lines.
Credits to Tidepool for insisting on transparency and posting the meeting transcripts. @christopherasnider thanks for taking the time to chime in here, much appreciated. Wish you best luck and success in your efforts.
@chistopherasnider, I am thrilled to see Tidepool enter the fray. This project, I think, is one that many were hoping to see happen. I hope that Tidepool is successful, and keeps as close as possible to the original opensource principles of OpenAPS and of Loop.
@christopherasnider, on behalf of the community here, I just want to thank you for posting, and hope that you will find a communication pathway to our very educated and proactive forum members helpful for your project.
As I am sure you know, the next generation of pumps with more user control is a very exciting item, and I appreciate the work you and the Tidepool team are doing.