Diabetes API Live
115 views
Skip to first unread message
Simon Carter
Feb 14, 2013, 10:57:12 PM2/14/13
to mede...@googlegroups.com
Hi everyone,
I'd like to let you know about a new diabetes service that has a cloud API already up and running. We are adding an export facility now as we support an open ecosystem.
It's ManageBGL.com, and it imports from about 100 different device types through 7 major formats. We're happy to support more - just send us samples!
We're not just another logging tool! We predict what happens between blood tests, and predict what happens in the future. Note - it's not statistical, so it doesn't expect your behaviour to be the same from day to day or week to week. It's a fully fledged diabetes simulator.
Once you get your ratios right, it's highly accurate at these predictions.
It also includes a coach, to help you refine your ratios when this is a discrepancy between the prediction and the actual BGLs.
It also has live sharing between School and Home.
Both my school-age daughter (8yo) and I have T1D, me for 24 years, her for 6 years.
My technical background is in data warehousing, data extraction and conversion, based on my DataMystic.com business.
Off now to take my daughter to her endos appointment!
Regards,
Simon Carter, DataMystic.com in Melbourne,
Australia
Know any
Insulin-Dependent Diabetics? Send them to ManageBGL.com
Benjamin West
Feb 15, 2013, 12:44:50 PM2/15/13
to Simon Carter, mede...@googlegroups.com
Howdy Simon,
I took a look at managebl.com, but got pretty confused. You mentioned something about an API, but I couldn't find anything.
I tried the UI; have you considered open-sourcing large parts of the application? It would considerably benefit from community patches on the UX... things like deleting user input in the date selectors, helping to create valid date ranges etc... These problems were enough to frustrate me. There are several existing open source apps that try to serve similar needs, we will likely choose one and start patching it. Some of them are documented on the wiki, but I've missed several.
-bewest
P.S. My day job is developing exactly this kind of thing at meraki.com, which is closer to the kind of total UX I'm after.
--
You received this message because you are subscribed to the Google Groups "medevice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to medevice+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Simon Carter
Feb 15, 2013, 3:15:59 PM2/15/13
to mede...@googlegroups.com
The API is at http://www.managebgl.com/api/index.html
We have a long list of changes to the UI, it's a matter of time and money. Is it possible to open source the UI and not the core code?
BTW, Meraki.com looks very slick. But some of the web browsers I have seen in schools and hospitals are on IE6!
Cheers,
Simon
Nathan West
Feb 15, 2013, 6:51:07 PM2/15/13
to Simon Carter, mede...@googlegroups.com
Hi Simon,
You can open source whatever code you want. If the UI is sufficiently
separated from the logic it shouldn't be difficult. That said I'm not
sure why you would just open source the UI; what's the point? Would
you expect people to improve your UI for free? What would someone get
out of doing such a thing?
I encourage you to open source at least a library to your data format.
That is something I would be likely to contribute code for. A lot of
the discussion on this list has revolved around creating a standard
data storage format for diabetes. Your website claims "Our API is THE
standard way to record and manage diabetes information in the cloud -
in a uniform, universal, non-vendor specific format." What makes your
API the standard for record keeping?
I'm working on bringing wireless connectivity to existing meters so
you can access raw data from anywhere; see my video from yesterday for
a demo. I'm in the market for a back end such as yours. From looking
around at your page it looks like you need an interface to BGM. Your
webpage says your service works with multiple diabetic devices in the
cloud. From the looks of things it doesn't support any devices-- it
requires manual data entry which I am capable of automating. That
means what we are working on is very complimentary.
The problem for me is that I have no clue how you're handling the data
or even what you mean by cloud (actually I don't know what anyone
means when they say cloud). I would like to encourage you to
participate in some of the data structure discussion going on in this
list and maybe even open source a library to interface with that data
structure to put it out in CSV, JSON, etc...
You can see all of my code on my github repos:
http://github.com/n-west You can take it and make your own auditing
devices (I hope someone does); but if you distribute said device you
must comply with the GPLv3 license which means you give me the source
code when I ask for it.
I might be coming off as slightly unreasonable here but one of the
original drives for my work on this is to get this data out of
proprietary systems so it's actually useful and gives people freedom
to take their data anywhere they choose.
My day job is a EE graduate student/research assistant in software
defined radios and signal processing in embedded linux. The general
practice in this area is that all of the signal processing code and
libraries I work with are open source and the applications are
generally proprietary (but there's still a large number of OS apps at
cgran.org). The big players in my field like Ettus Research (owned by
National Instruments), Intel, TI, Mentor Graphics contribute large
amounts of open source code in libraries and device drivers because no
one would use their products otherwise. It would also be insane for
each person to implement their own FFTs and filters for instance,
which is about as fundamental as a standard data structure for
diabetes history. No one makes any progress in such a world.
That said, I would love to have a back end such as what you have, I
just can't work with something that's completely proprietary; it would
be regression for me. Obviously you don't have to change anything for
me, but I hope you consider opening up at least a library to whatever
storage/data structure you're using. Make your product standard by
being the first to publish such code that everyone else will use. I
realize it may be a difficult decision with all of the time, effort,
and money you've likely put in to it but its a win-win for everyone
involved.
-Nathan
You can open source whatever code you want. If the UI is sufficiently
separated from the logic it shouldn't be difficult. That said I'm not
sure why you would just open source the UI; what's the point? Would
you expect people to improve your UI for free? What would someone get
out of doing such a thing?
I encourage you to open source at least a library to your data format.
That is something I would be likely to contribute code for. A lot of
the discussion on this list has revolved around creating a standard
data storage format for diabetes. Your website claims "Our API is THE
standard way to record and manage diabetes information in the cloud -
in a uniform, universal, non-vendor specific format." What makes your
API the standard for record keeping?
I'm working on bringing wireless connectivity to existing meters so
you can access raw data from anywhere; see my video from yesterday for
a demo. I'm in the market for a back end such as yours. From looking
around at your page it looks like you need an interface to BGM. Your
webpage says your service works with multiple diabetic devices in the
cloud. From the looks of things it doesn't support any devices-- it
requires manual data entry which I am capable of automating. That
means what we are working on is very complimentary.
The problem for me is that I have no clue how you're handling the data
or even what you mean by cloud (actually I don't know what anyone
means when they say cloud). I would like to encourage you to
participate in some of the data structure discussion going on in this
list and maybe even open source a library to interface with that data
structure to put it out in CSV, JSON, etc...
You can see all of my code on my github repos:
http://github.com/n-west You can take it and make your own auditing
devices (I hope someone does); but if you distribute said device you
must comply with the GPLv3 license which means you give me the source
code when I ask for it.
I might be coming off as slightly unreasonable here but one of the
original drives for my work on this is to get this data out of
proprietary systems so it's actually useful and gives people freedom
to take their data anywhere they choose.
My day job is a EE graduate student/research assistant in software
defined radios and signal processing in embedded linux. The general
practice in this area is that all of the signal processing code and
libraries I work with are open source and the applications are
generally proprietary (but there's still a large number of OS apps at
cgran.org). The big players in my field like Ettus Research (owned by
National Instruments), Intel, TI, Mentor Graphics contribute large
amounts of open source code in libraries and device drivers because no
one would use their products otherwise. It would also be insane for
each person to implement their own FFTs and filters for instance,
which is about as fundamental as a standard data structure for
diabetes history. No one makes any progress in such a world.
That said, I would love to have a back end such as what you have, I
just can't work with something that's completely proprietary; it would
be regression for me. Obviously you don't have to change anything for
me, but I hope you consider opening up at least a library to whatever
storage/data structure you're using. Make your product standard by
being the first to publish such code that everyone else will use. I
realize it may be a difficult decision with all of the time, effort,
and money you've likely put in to it but its a win-win for everyone
involved.
-Nathan
Jana Beck
Feb 15, 2013, 9:49:02 PM2/15/13
to nate...@gmail.com, Simon Carter, mede...@googlegroups.com
I agree with Nathan--I'm not really interested in potentially contributing to anything that isn't completely open source or at least an open API to the data. I believe there's a real need for tools and data standards that are open and not vendor-specific (although ideally a good open standard might coax the device makers into trashing their proprietary formats in favor of the standard).
Jana
Anthony Di Franco
Feb 16, 2013, 5:05:04 PM2/16/13
to Simon Carter, mede...@googlegroups.com
Can you say more about your diabetes simulator?
My background is in control theory and machine learning, and I have been interested in closed-loop blood glucose control for years, so don't spare any detail you don't mind sharing.
Anthony
--
Simon Carter
Feb 17, 2013, 6:19:12 PM2/17/13
to Jana Beck, nate...@gmail.com, mede...@googlegroups.com
Hi Jana,
I certainly understand your point. Our API (http://www.managebgl.com/api/api-REST.html) is open and we are vendor-neutral.
As a T1D of 24 years, I abhor the vendor lock-in that diabetics are subject to. Having all the data in one system means that far more meaningful insights can be obtained, and self-management and coaching are easy to provide.
Last week we started testing changes to our API to support an export function, and so complete the loop. Should be ready by the end of the week.
Regards,
Simon Carter, DataMystic.com in Melbourne, Australia
+61.3.9913.0595 (GMT+10 hours) Skype:datamystic
Know any Insulin-Dependent Diabetics? Send them to ManageBGL.com
Simon Carter
Feb 17, 2013, 6:37:50 PM2/17/13
to nate...@gmail.com, mede...@googlegroups.com
Hi Nathan,
Great to meet you and other like-minded people here.
I can see a number of advantages to open sourcing the UI - translations,
customizations/tweaking for the multitude of devices/browsers out there and
getting the best possible UI e.g. for date ranges, inline editing and all
the CSS we take for granted from huge players like google. UI development
can also be costly and time consuming. It makes sense to separate the visual
framework from the backend.
But...motivating people to take up this challenge is tricky. Perhaps this
could be in exchange for ongoing free use, as is commonplace in the software
arena, just as we do for DataMystic. Or, listing contributors on the website
with links to their own website, as is done for thmese for phpBB and
vBulletin forums software.
Our API (http://www.managebgl.com/api/api-REST.html ) is open, documented
and vendor-neutral. Please try it! XML is the default, but JSON, AMF, PLIST
and YAML are also supported. An export facility should be available by the
end of this week. Let me know if you have any questions about the model.
Here is an online sample showing how easy it is:
http://www.managebgl.com/api/sample.html
We do import data (Abbott's Copilot, CareLink, Dex, Glucofacts, Freestyle,
Omnipod, Ontrack) but not directly from the devices as yet. This is
something that we plan to add, but it is a big exercise with the sheer
number of devices. When we designed ManageBGL, it was in the complete
absence of any kind of useful connectivity from BG meters, pumps and CGMs.
So, we designed the system for fast data entry (same data as a pump uses,
but with the better UI of a phone), and real-time prediction and decision
making, and built an API so that automated logging could be done when it was
available. If you can help to deliver this automation then I would love to
work with you!
I'm happy to fund a small project to enhance insulaudit to directly upload
to ManageBGL. Please contact me if so - you will need to spec out what is
required from insulaudit's end.
ManageBGL can provide the other pieces of the puzzle such as visualization,
prediction, intelligent interpolation, coaching and warnings as well as live
sharing.
By 'cloud', I mean scalable computer infrastructure (where the computing can
cope with increased load, with load balancers and on-demand instances) that
is both highly reliable (fault-tolerant and load-balanced), data is
backed-up (with redundant copies) and secure. ManageBGL is already deployed
in such an environment.
Regards,
Simon Carter, DataMystic.com in Melbourne, Australia
Great to meet you and other like-minded people here.
I can see a number of advantages to open sourcing the UI - translations,
customizations/tweaking for the multitude of devices/browsers out there and
getting the best possible UI e.g. for date ranges, inline editing and all
the CSS we take for granted from huge players like google. UI development
can also be costly and time consuming. It makes sense to separate the visual
framework from the backend.
But...motivating people to take up this challenge is tricky. Perhaps this
could be in exchange for ongoing free use, as is commonplace in the software
arena, just as we do for DataMystic. Or, listing contributors on the website
with links to their own website, as is done for thmese for phpBB and
vBulletin forums software.
Our API (http://www.managebgl.com/api/api-REST.html ) is open, documented
and vendor-neutral. Please try it! XML is the default, but JSON, AMF, PLIST
and YAML are also supported. An export facility should be available by the
end of this week. Let me know if you have any questions about the model.
Here is an online sample showing how easy it is:
http://www.managebgl.com/api/sample.html
We do import data (Abbott's Copilot, CareLink, Dex, Glucofacts, Freestyle,
Omnipod, Ontrack) but not directly from the devices as yet. This is
something that we plan to add, but it is a big exercise with the sheer
number of devices. When we designed ManageBGL, it was in the complete
absence of any kind of useful connectivity from BG meters, pumps and CGMs.
So, we designed the system for fast data entry (same data as a pump uses,
but with the better UI of a phone), and real-time prediction and decision
making, and built an API so that automated logging could be done when it was
available. If you can help to deliver this automation then I would love to
work with you!
I'm happy to fund a small project to enhance insulaudit to directly upload
to ManageBGL. Please contact me if so - you will need to spec out what is
required from insulaudit's end.
ManageBGL can provide the other pieces of the puzzle such as visualization,
prediction, intelligent interpolation, coaching and warnings as well as live
sharing.
By 'cloud', I mean scalable computer infrastructure (where the computing can
cope with increased load, with load balancers and on-demand instances) that
is both highly reliable (fault-tolerant and load-balanced), data is
backed-up (with redundant copies) and secure. ManageBGL is already deployed
in such an environment.
Regards,
Simon Carter, DataMystic.com in Melbourne, Australia
+61.3.9913.0595 (GMT+10 hours) Skype:datamystic
Know any Insulin-Dependent Diabetics? Send them to ManageBGL.com
-----Original Message-----
From: Nathan West [mailto:nate....@gmail.com]
Sent: Saturday, 16 February 2013 10:51 AM
To: Simon Carter
Cc: mede...@googlegroups.com
Subject: Re: Diabetes API Live
From: Nathan West [mailto:nate....@gmail.com]
Sent: Saturday, 16 February 2013 10:51 AM
To: Simon Carter
Cc: mede...@googlegroups.com
Subject: Re: Diabetes API Live
Simon Carter
May 20, 2013, 12:15:38 AM5/20/13
to Benjamin West, mede...@googlegroups.com
Hi Benjamin,
Just letting you know that we've added protein and fat modelling as part of the wizard. Please first go to www.ManageBGL.com/settings-physiology.html to setup the percentages.
I'm also not sure if you've seen the live coaching?
Regards,
Simon Carter, DataMystic.com in Melbourne, Australia
+61.3.9913.0595 (GMT+10 hours) Skype:datamystic
TextPipe: PCMAG - "The ultimate text conversion and manipulation tool"
Know any Insulin-Dependent Diabetics? Send them to ManageBGL.com
DetachPipe.com - Manage Outlook Attachments and send huge files
Download the latest Windows, Mac and iPhone software - DownloadPipe.com
Reply all
Reply to author
Forward
0 new messages