Diabetes Application (1 Viewer)

I am a Type II diabetes and am looking for a public domain diabetes Access database application. Does anyone have one or know of one I can download?

Hi Doc. I don't know of any but what information would you be storing in this database? I suppose we could help you build one.

maybe see if there is anything here that can provide some development guidance if you don't find an off the shelf solution - specifically the medical section & maybe item 49.

As theDBGuy said, we'd be happy to help you build it. Here is a spreadsheet template you can use as an example.

https://templates.office.com/en-us/blood-sugar-tracker-tm03986892

Although the already built Excel solution is instant gratification, the Access solution will be better since you can have an infinite record of readings and just pick a time period to calculate. You can even create a chart if that's what you want. To use the spreadsheet, you are going to have to either keep making new ones or delete old data to control the size of the chart.

I decided to make the database since I can also use it to track my blood pressure. I started with Blood Sugar. Charts will come later.

Thanks for the feedback. What I would be looking for in the application would be:


1. Have the ability to add, edit, delete a master record with patient profile information.
2. Have the ability to key in before & after blood sugar numbers along with medications and comments taken for breakfast, lunch and dinner. Maybe leave some optional fields for supplemental checks during the day or night.
3, Have the ability to print pre-designed reports that could be printed out to bring to your doctor.
4. Use the data entered calculate an A1C (3 month average).
5. Wish List: store food list along with the carbohydrates, fiber, sugars, and serving size.
6. Wish List: create a table that would store a list of all available diabetic medications.
Since quite a few of us diabetics have eye problems the forms, queries and reports would need to use larger fonts.


The application would be a work in progress making changes as necessary from feedback from the users.


Some of the tables I envision would be:
A main table to store personnel information i.e. name, address, phone number, doctors name, primary contact in case of emergency.



A medications table to store a list of all current diabetic medications that could be selected via a pull down list.


A transaction table. This table will store records being added. This table would store all data from data entered via an Addition form. This form would be used to enter transaction data i.e. daily blood sugar numbers with date and time taken, any medications given before or after meals, any free form comments found pertinent to the entry,



A journal table used to store any changes to the transaction table. this table will be used to do historical reporting.

A "wish list" table would be a table to store food information. i.e. food type, serving size, carbohydrates, fiber, fat, sugars.


Any assistance would be highly appreciated. As I mentioned once developed it would be placed in the public domain so any diabetic can download it for free. Via comments from the users any enhancements or bugs can be addressed.

If It would help I could create a skeleton application to give us a starting point. It would not be functional but what I would envision the forms, tables and reports would look like.



Thanks again,


Doc

Here is the current version of the app. I will add some reports and exports you can send to your doctor. Feel free to take it from there.

There are lots of complicated spreadsheets to log food and medication. Some of them will give you ideas for how you want your app to function. I included some images that I found that might give you some ideas.

If you want me to build the complete app for you, we can discuss rates.

Thanks for the feedback and the sample database. I am enclosing a PDF of what I have done so far.


The tables involved are:


Main: This holds patient / doctor information. i.e. name, phone#, doctor's name ...


Medication: This one holds different diabetic medication types. i.e. Novolog, Lantus ...


Transactions: Stores all current transaction data.


History: Contains any changes made to the transaction table. Anytime the transaction database changes this table will contain a before and after image of fields changed so rollback is possible. This is also used for reporting / searching.


I hope that this kind of helps to better define the process. I do like how you added tracking the BP and oxygen consternation. I added the meal type captures since my doctor wants to track it 3 times a day.


Any help with the design of the tables, necessary coding and reporting would be greatly appreciated expecially in the tracking of transaction changes, adds, deletes.


Doc

You've taken the spreadsheet approach with your table design and this will make analysis more complicated than it needs to be. I started a properly normalized table for you. It also allows multiple people in a household to use the same database.

You might consider doing some reading on database normalization before going much further. You have four repeating groups in your record. i.e. the "same" data occurs multiple times in each record.

If you want to designate, breakfast, lunch, dinner, snack in the table I created, just add one new field similar to the combo field which is used to indicate the reading is before or after a meal.

Take some time now to try to create an analysis of your blood sugar over the course of a day. then try to create that same analysis over the course of a month. Using a normalized schema, the same query does both jobs, you just give it a date range as an argument (NEVER hard-code stuff like this). Using your schema, you need separate queries. If you wanted to analyze only morning readings, that same query could be used if it takes an optional argument for meal time, Given the optional argument, the query only works with "breakfast" or whatever. So far, I've suggested three different ways to slice and dice and with the use of arguments, I can do it all with a single query. You will need to create separate queries for each analysis.

I also just noticed that you are capturing breakfast, dinner, and after dinner. If you later decide you also want to do lunch, then you're going to be rewriting ALL of your queries, modifying your table and modifying your form. With a schema such as I made, you just add a new type code to the dropdown and voila! NO CHANGE WHATSOEVER to any form, report, or query - PERIOD.

Can you recommend a good book on database normalization?

You don't need a whole book. It only takes a few pages to get the point across. Such a book might exist, but to be honest, in my mind it would only be enough material for one chapter in a much larger book.

Do a search on the web for "Database Normalization" and then just limit your reading to academic sites (.EDU) and stay away (initially) from vendor sites (.COM) - because academic sites probably have better general articles whereas vendor sites will tout their "special features" that don't apply everywhere. You have to include "Database" in your general web search because "normalization" occurs in other non-database contexts.

If you search this site (3rd from right in the thin menu ribbon near the top of the page), you can use "Normalization" by itself because this IS a database-related site. But a lot of the threads will be about how someone ISN'T normalizing correctly, and you should save that kind of research for later when you understand the topic better.

This site has a lot of articles about normalization but the variety of .EDU sites can help you find perspective. I would keep on reading from the academic sites until it all becomes kind of familiar. Once you reach the point that you have learned nothing new from reading another couple of articles, you probably have learned everything you need to know regarding the basics.

I would like to thank everyone helping me to understand what constitutes a good design of databases.


A little about myself; I spent 30 years programming mainframes, mini mainframes. I spent 10 years in banking, 10 years in retail and 10 years in transportation.



My job was to create the software that processed the data behind the scenes. I did the datamining from the data already captured or entered. My experience with MS Access was more or less self taught over a years time.


So if I seem to be dumb as a box of rocks at times I am still trying to learn at an entry level.


Now if you have questions in RPGLE or COBOL I might be able to help.

I can answer the COBOL questions

The design of a database in Access is no different from the design of a database using any other RDBMS. The databases I designed in DB2 and accessed via COBOL and CICS use exactly the same rules as the ones I design for Access use. Even as far back as the 70's, the ISAM files were very similar to individual tables and the IMS DB databases, although completely different from a relational database were still separated into 1-m relationships.