Browsing projects by Tag(s)

Select a tag to browse associated projects and drill deeper into the tag cloud.

Showing page 2 of 3

Helps keeping track of various health related readings for people with diabetes. Provides reports based on the collected data. Web and smart device user interfaces.

0
 
  0 reviews  |  0 users  |  0 current contributors
 
 
Compare

This project is for the HMTK, a tool for people trying to look after their nutrition, their weight, and their blood sugar. It was started because the developer is a diabetic and needed a tool for her DS to help her.

0
 
  0 reviews  |  0 users  |  0 current contributors  |  Analyzed 4 days ago
 
 

Please note any kind of support we seek, if you want support or help with the project opengluco@googlecode.com contact me, thank you!

0
 
  0 reviews  |  0 users  |  0 current contributors  |  Analyzed over 1 year ago
 
 

Library for daily diabetes (TYPE II) checks, such as blood sugar, blood pressure. Including PPC sync and PPC client application.

0
 
  0 reviews  |  0 users  |  0 current contributors  |  Analyzed about 2 years ago
 
 
0
 
  0 reviews  |  0 users  |  914 lines of code  |  0 current contributors  |  Analyzed 3 days ago
 
 
Compare

EBMI is a medical computer simulation framework that integrates three kinds of knowledge: (1) risk estimates derived from patient data, (2) comparative-effectiveness estimates obtained from randomized clinical trials (RCTs), and (3) genetic knowledge from basic research. Using patient data creates ... [More] risk-predictions that are personalized and precise, while avoiding the biases that arise when real-world patients and doctors are assumed to act and prescribe as research participants do. The direct use of RCT results maximizes the validity of assumptions about treatment effects, while allowing immediate modification of these assumptions when unexpected new trial results appear. EBMI was developed at the Kaiser Permanente Center for Health Research with support from the National Library of Medicine, Kaiser Permanente, the Agency for Healthcare Research and Quality, and several pharmaceutical companies, including Takeda Pharmaceuticals-North America and Merck and Co. Kaiser Permanente made EBMI free and open-source in June, 2009, under the GLP2 license. EBMI currently simulates only type 2 diabetes. It predicts how changes in treatments will alter the occurrence of 25 complications of type 2 diabetes, over any specified span of time, for an individual or for a population of individuals. When used in its clinical-prioritization mode, EBMI identifies and simulates all of a patient’s available treatment options and generates a ranked list to assist clinical decision-making, based on quality-adjusted life-expectancy or another user-chosen criterion. EBMI is a highly transparent program that simply calculates the logical consequences of available clinical trial evidence for particular patients. The user, not the model, specifies all treatment effects, hopefully using meta-analyses of randomized clinical trials or other sources of evidence. The model generates risks of events—outpatient diagnoses, hospitalizations, treatments, and death–from analyses of real-world data taken from the same population in which the model will be used. Rates for events are initialized at baseline using data on each patient’s medical history, genetic characteristics, age, sex, duration of diabetes, risk factor levels, and treatments already in use. As it simulates, the model modifies these rates each quarter in response to changes in treatment, aging, and the occurrence of new medical events. The user can make rules governing downstream treatment changes (initiation, intensification, and discontinuation), conditional on blood glucose, blood pressure, or lipid levels; on physician adherence to treatment protocols; on patient adherence to physician recommendations; on treatment failure; and on the occurrence of events, such as an MI, which could trigger beta-blocker therapy. Virtually all assumptions about genetic effects, treatment effects, treatment pathways, treatment protocols, adherence, costs, and quality of life can be set by any non-programmer from user-friendly interfaces. In practice, because of their number, most assumptions are stored in run settings files and uploaded as a set. A default set of assumptions is also provided. Currently, EBMI is written in Visual Basic to run in the Microsoft .NET environment on any Windows-compatible computer. It uses a 90-day (quarterly) fixed simulation cycle, an interval chosen because major cardiovascular events rarely occur more than once every 90 days, and virtually never more than twice, and because persons with chronic illness see their primary care physicians about 4 times a year, which helps in emulating clinical decision-making. 90 days is a shorter cycle than other fixed-time disease models use. By using a shorter cycle, a limitless number of events and treatments can easily be made to interact, because intra-period interactions do not need to be modeled and sequenced. From baseline data, EBMI establishes an initial quarterly rate for each event. Each quarter, EBMI converts each rate to a probability and “rolls the dice” (draws a random number) to see if any new events will occur. If a treatment is changed, or if a new event does occur, EBMI moves the affected event-rates up or down to account for the effects of these changes. When the simulated patient “dies,” this process is repeated for another simulated life until, after hundreds or thousands of simulated lives per patient, stable mean estimates emerge. When EBMI is used to prioritize treatments, this process also repeats across treatment options, until all open treatment options have been simulated and ranked. When EBMI is used to simulate treatments in a population, the process repeats until all persons in the population have been simulated. EBMI incorporates the effects of new treatments and other downstream changes in the form of relative-risk (risk-ratio) multipliers. Any number of risk-ratios can be multiplied together, assuming the risks are independent of each other. The use of multiplicative adjusters makes EBMI extremely flexible and easy to modify. It also allows the relative-risk results of clinical trials and genetic studies to be used directly and transparently, almost “right out of the box.” This simple approach, calculating an absolute rate once and then adjusting it with multipliers over time, has an extremely useful characteristic, namely, that the equations that set the initial rate can be completely independent from the multipliers later used to modify the rate. This allows all sorts of locally available data to “naively” but precisely predict the initial rate, without having to care whether the equation behind the rate provided a “true model” of how predictors cause events. The EBMI approach also gives complete control over risk-function specification, which lets the statistical analyses exactly match the simulator’s architecture. Using local data to calculate risks also grounds the simulator in the data that actually exist in the place it will be used, which ensures that variables signify the same thing in the simulator that they signify to local doctors. Finally, when local data are voluminous, using local data permits a fine individualization of risk, which further increases accuracy and safety, and avoids the biases that are introduced by trying to predict real-world behavior from the behavior of study volunteers and research doctors. Because EBMI was explicitly designed for real-world clinical use, EBMI treatments match actual compounds and available dosages that doctors actually prescribe. For type-2 diabetes, we programmed 43 treatment classes, including behavioral treatments like smoking cessation, as well as drugs. The drug-class, ACE_Inhibitor, for example, includes benazepril hcl, captopril, enalapril maleate, fosinopril sodium, lisinopril, moexipril hcl, quinapril hcl, ramipril, and trandolapril. Each drug-class has a reference drug and specified dosages. The reference drug for ACE_Inhibitor is lisinopril, with 5 dose levels: 5 mg, 10 mg, 20 mg, 40 mg, and 80 mg per day. The potencies of all other drugs in each class are calibrated in terms of the reference drug’s dosages. EBMI has rules to recognize what level of each drug-class patients are taking when they enter the model, based on refill frequency and days-supply. [Less]

0
 
  0 reviews  |  0 users  |  0 current contributors
 
 

Various tools and a GUI front end for OSX to interact with Blood Glucose data from LifeScan's Ultra range. Currently supporting Ultra OneTouch2 devices. Tools should compile on Linux based distributions also. GUI should run on any machine with a AMP stack.

0
 
  0 reviews  |  0 users  |  0 current contributors  |  Analyzed 5 days ago
 
 

overviewThe development and availability of Continuous Glucose Monitoring Systems (CGMS) has substantially improved both the quality of life, and blood-glucose control for many Type 1 Diabetics. The primary goal of this project is to take this understanding a step further. By using CGMS data ... [More] , along with other sources of information, carbohydrates consumed, insulin taken, physical activity, etc., my hope is to produces a mathematical model of the individual diabetic. This model may then be used in conjunction with a data driven algorithm, to predict future blood-glucose concentrations. In turn this prediction may be used to partially automate insulin delivery, or issue early low blood blood-sugar warnings. Some key features I'm working on include: A probabilistic interpretation of model predictions. e.g. for a given confidence level, the model will describe a range of potential outcomes. Be able to pick up on non-trivial trends A mathematical model can't hope to describe such a complex system such as a person with type 1 diabetes. This project will attempt to account for this through a series of statistical and heuristic methods. Clearly the system won't have access to to all bio-information of the person, therefore the system should be able to take a 'best guess' as the form of driving force behind a given trend or event. "real time" analysis of CGMS data Project StatusSince this is primarily a personal research project, and in it's infancy, many of the features I am working on have not been hooked up to the GUI interface, however what is available under the gui interface includes: Read in CGMS/insulin/meal information from Minimed, Dexcom, and Navigator system exports Find parameters for the set of non-linear differential equations currently used Make predictions of blood glucose concentrations up to an hour ahead of present time User control of parameter optimization options Saving programs state to disk Implemented features not available via gui interface include: Filtering of CGMS data via, Fast Fourier processing, 4th order Butterworth filtering, or b-spline smoothing A host of features for researching effects, and quick protyping of new ideas Feature under construction Adding more interfaces to gui Take into account uncertainties of parameters and events Fit for an event that was not recorded (e.g. ate a meal and forgot to take insulin) Recommended correction doses of insulin/carbohydrates I am hoping by the end of 2009 to have this project in a state presentable to others; meaning able to make predictions for given confidence levels, suggest corrections, able to simulate hypothetical situations, and more. In the mean time, you are welcome to contact me if you would like to become involved, or would like future updates, my name is Will Johnson, and my email is banjohik@gmail.com. You are welcome do download the code, compile it, and run in, to compile the code, see the note below. And if you have any proplems feel free to email me. A Note about the CodeThis project is implemented in c++, using using the Boost (v 1.38), ROOT (v5.20/00), and GSL (v 1.12) libraries, and is known to compile under linux and OS X, using the gcc compiler. [Less]

0
 
  0 reviews  |  0 users  |  141,017 lines of code  |  2 current contributors  |  Analyzed 4 days ago
 
 

This project is a web-based recording and management system for diabetics to use in maintaining controlled blood sugars and HbA1c values. Eventual planned functionality includes the ability to: - record blood glucose readings and categorize them by time of day and event - record insulin dosage for ... [More] both basal and bolus, supporting injections and pumps - record carbohydrate intake related to dosage of insulin - record oral and other medications taken which may affect blood glucose readings - upload data from meters, pumps, CGM devices, other software - obtain logs of all data in user customized formats - graph data values in customizable ways - perform a variety of analyses of data using an embedded scripting capability This project is being developed in Python on Google AppEngine with an Ajax (XHTML/CSS/JavaScript) front end. All help offered is welcome. [Less]

0
 
  0 reviews  |  0 users  |  0 current contributors  |  Analyzed 4 days ago
 
 

Proyecto de fin de carrera, es un sistema de gestión de todos los aspectos del control de la diabetes para la plataforma s60, en concreto resolución de 352x416

0
 
  0 reviews  |  0 users  |  0 current contributors
 
 
 
 

Creative Commons License Copyright © 2013 Black Duck Software, Inc. and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a Creative Commons Attribution 3.0 Unported License . Ohloh ® and the Ohloh logo are trademarks of Black Duck Software, Inc. in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.