A history to why the idea was conceived.
So what will diabetestools.org offer?
How will diabetestools.org work?
Are there any possible financial benefits?
Licensing of diabetestools.org.
Time estimate – how long will it take to build. 7
diabetestools.org is intended to be a system that helps diabetics to manage their condition. It should supply diabetics with a diary, a reporting tool for long term overview and a way to easily communicate with his/her medical team. The medical team working with the patient should in turn be offered an easy way to communicate with the patient, an easy overview over the patients' condition and a place to keep the patients information. It should also provide the scientific community with the possibility to use a wealth of data that has not previously existed so that new research into diabetes and diabetics life is easy and cost efficient.
My name is Tomas Malmsten. I have had juvenile diabetes since 1991 and have used a number of glucose meters as well as other equipment and different types of insulin. I have also tried to get along with the, in my experience, quite limited diaries that are provided. I have also taken part in a study about minimally invasive technology called MITRE which I mention further down.
I work as a computer programmer and I currently work for an accountancy firm and build their enterprise solutions.
There are currently a number of blood glucose monitoring devices that interface with computers or hand held devices, each different from the next. There are also a number of computerised diary systems that diabetics can use. Each of these systems provides more or less sophisticated reporting tools and user interfaces. None offers a way to conveniently communicate results and queries regarding the current condition to health care professionals. None, as far as I know, are usable on multiple platforms or accessible for handicapped diabetics.
The health care teams working with diabetics all use different systems to keep track of each patients record and none offer an easy diabetic centric overview of a diabetic's data.
There is no way for researchers to access live data directly without initially undertaking a time consuming data gathering process, nor a tool available, which would simplify the task of contacting people and asking them to partake in a study if the correct data is not presently available.
diabetestools.org is intended to service three different user groups:
diabetestools.org is intended to offer diabetics that are using glucose monitoring devices which can interface with computers (including handhelds) one application for all devices. It should also be a powerful and easy to use diary with comprehensive reporting tools and overviews over long term trends. There should be a possibility to configure alarms that will monitor longer trends and can alert the diabetic to slipping control, or encourage improvements towards a goal. It should also incorporate a communication module that allows the diabetic to communicate easily with his/her medical team about his/her results and any other queries.
The medical team should at their end be able to reply on any queries using diabetestools.org as well as feed back test results done at the last visit. It should give the health care professionals a diabetic specific view over data kept with reporting tools that are helpful to them. The alerts described above are also available to the medical team so that a slipping condition can be earlier identified.
diabetestools.org will offer a direct view into all users every day life. Since it is used by both diabetics and their health care team the data is guaranteed to be correct. This section of the application will naturally not have any personally identifiable information but will offer a system interface that allows researchers to gather needed data or alternatively define a group that they need specific information about and then request this information.
When any new research is done this can immediately be fed back into the system and there be made available to all users, health care professionals as well as diabetics. It should also offer the medical industries information about what diabetics need and therefore be able to provide better tailored tools for us. Public (or private) health institutions caring for diabetics should be able to cut costs due to simplified communication and earlier identification of critical trends in treatment.
A diabetic should get comprehensive easy to use diary application that can read data from his/hers blood glucose monitoring device, accept highly configurable data input and categories dealing with activities and provide an easy to read overview or report over long term trends and day to day treatment.
The application should have configurable alarms that will alert the user if his/her treatment is slipping outside set boundaries. Any goals agreed with the medical team will be kept in the application and build configuration for such alarms, both so that the diabetic can be informed when he/she is doing well and not so well.
A communication module will allow the diabetic to communicate with his/her medical team, choosing if he/she prefers to send a message to one specific person or a group. The message can be attached to a set of blood glucose test results, a period in the diary or to activities that have been entered into the application or with all of the above. The communication module will also allow the medical team to enter test values that have been done at the hospital or surgery, such as HbA1c and such lab values.
Completed research and hopefully also other research, will be accessible using the application and given the correct parameters may also be tailored to each user's interest.
Since the application will be written in a platform-independent manner it should be usable on any computer (Apple mac, Linux, Unix and windows) as well as on hand held devices and even Java enabled mobile phones. This will make the application easy to use and accessible for more people. It should also cater for users that have special needs, such as blind, deaf and other handicapped diabetics.
The medical team will use a system that hopefully is incorporated into the computer system they already use and are familiar with.
It should offer each role an interface that is tailored for his/her special needs. It should be easy to retrieve a patient's up to date information, such as diary entries and glucose levels and other test results as well as any communication that have been sent/received. Longer term overviews should be easy to produce as well as an overview over agreed goals and how the patient is doing in respect to them.
It will provide a simple way to communicate with the patient, both with suggestion regarding the ongoing treatment as well as answering questions that the patient may have asked.
It will provide information on all medication and other information regarding the patient, perhaps even internationally, if more then one country signs up to diabetestools.org
There is a real possibility that, if this system gets a global coverage, a diabetic can have an emergency card with a user name and password that any authorised health care professional can use to obtain up to date data about how the diabetic is treating his/her diabetes and any other important medical information.
The benefit to research can be potentially enormous, especially if diabetestools.org has an international uptake in the healthcare industry.
The research application is intended to be a data store that has no personally identifiable information kept within the data but a unique alpha numerical key that identifies one record from the next. The database used by the medical teams will have both the key and the personal records so it can synchronise the data in the research database with the data from diabetics. This guarantees that the data in the research database is correct and useful for research.
Researches will be able to use the data when needed for each research project. If a project requires additional data they can find a target group and then send a request to the target group to contribute the additional data without knowing anything about the individuals more then the data that they need. They can of course also make the request that the relevant people identify themselves if this is needed but such a request needs to be routed via the medical team, in my opinion.
The research application will make simpler statistical studies extremely simple and cheap to do and will therefore allow for more of them to be done by diabetics themselves or by the medical industries in order to develop new products.
I imagine that there are two main financial benefactors of diabetestools.org that will be able to save or make money from the system.
One is the medical/health providers that can that will be able to work more efficiently thanks to the communication module that will allow for reducing or increasing the number of visits more in accordance to immediate need. The system should also enable earlier notification of possibly serious complications using the alarm that will be provided.
The second and biggest benefactor economically is the medical industry and research institutions. To illustrate I will use myself as an example. I recently partook in a study to see how well minimal invasive metering technology worked. Much of the research was done using a specific glucose monitoring device and a paper diary. I assume that the paper diary was later typed into a computer, this would have cost some money since there would have been quite a lot of them to transfer. The glucose monitor that I was given must have been purchased and there would have most likely been some customisation of the software provided with it so that it could be transferred to a statistical system. Besides, I have never liked the glucose monitor so I would rather have used my own. If there would have been an application available that could read the data from any monitoring device the study would not have had to provide me with a free glucose monitoring device. The diary notes would have been made available in digital form from the start since the diabetics diary is automatically uploaded to the research server. So the only material cost would have been to create the reports needed for the study and since they would have been created using a system that is made for report creation this would have been a fairly straight forward process. I am sure that research of this kind would be done more often if the tools and the framework would be there and available so the set-up cost would be minimal.
The commercial medical industry would most likely jump at the possibility to directly communicate to diabetics on a large scale anonymously and get reliable data back that can help with product development.
Security is a key issue in an application of this type. It is after all sensitive personal data that is dealt with. The security issue is divided into the following parts:
diabetestools.org's success lies in part in having an open approach to licensing of the system as well as providing it free of charge to anyone who wants to use it. The reason for this is that if the system is written as open source in an open manner anyone's needs for customisation and feature additions can be done by anyone else. If then the additions are approved by the governing body for the system they will be included and all users that want the extra functionality can easily access it and upgrade their own application. This will provide a rich usable application to the end user without any additional cost to the end user.
I intend to use GNU's General Public License as the license for diabetestools.org. For more information on the license see http://www.gnu.org/licenses/gpl.html .
The costs for diabetestools.org are the development costs, which is the man hours it will take to build the system, the ongoing costs for hosting the system and any integration costs. The initial building cost will be based on how much money the developers will be paid per hour and how many man hours it is estimated to take. The hosting costs can be separated into two. The hardware and possible operating system costs for servers and clients that will run the system at hospitals/health institutions and the Internet server costs for research servers and for synchronisation with individual diabetics. The integration costs are what third party software manufacturers may charge for integrating diabetestools.org into institutions software systems.
It should be mentioned here as well that any research done using diabetestools.org may need to employ professional report writers to create the required reports. Also important is that everything created for diabetestools.org is available to use for free once it's been written. And some things may well be written by enthusiasts that will not charge since they need the part they create themselves.
All time estimates in this section are very rough estimates. It may take less or more time to complete either of the milestones mentioned. I do think however that as a rough estimate and a pointer the the times specified are useful.
The project can be split into three major milestones, the completion of each application tier. The diabetic's client is the only one of the three that will offer value independently of the other two so it seems logical to start with it. This is also the tier that will take the longest to create since everything needs to be written from scratch. Many components used in the diabetic's client will also be used in the other two tiers. I estimate that it will take around 14 man months to complete the diabetic's client.
The second milestone is the general healthcare application. The user interface will be created using web technologies so the time needed will be less then for the diabetic's client. Since a number of components will be ready to use from the previous milestone, this milestone will be faster to build. I expect it will take 10 man months.
The last milestone, the research tier, will be considerably easier to build since there is no actual user interface to build but mainly a matter of careful database configuration. My estimate is around 2 man months.
The diabetic's client and the healthcare client estimates could be split equal as well since parts are shared, but since one can not be completed without the other then they will be combined and the completion time is then two man years.
I should also mention here that the way this project will be managed will make it easy for stakeholder and other interested parties to see exactly how it is progressing. It will also be easy to see if the project is on schedule to reach the next milestone.