The inspiration for this hack came about at a 'Hack for Good' day, when the mother of a fellow participant asked Benji for help, using her data logging system for mental health patients. Benji soon discovered that this data logging system was an Excel spreadsheet, which had a version control method of where the Excel file was copied with the file name being changed to reflect the date of the modification. Each patient had their own spreadsheet, and the spreadsheets all had the same data structure and fields.
This was the inspiration for this system, because in both our mobile and web application, the user is able to create custom records, with different input mechanisms such as text boxes and drop down menus, which are then stored in a MongoDB database, where a basic implementation of a version control system to keep track of patient progress over time.
What it does
The Web implementation lets the user create forms with custom data types and store this data in a MongoDB database, where a method of version control has been implemented to show where changes have been made to certain records.
The mobile application can generate a form for the user to fill in, from a JSON file, and store it back into the JSON file. It can switch between JSON files (patients) but, it has no version control implementation at the moment.
How we built it
We built the web application in Node JS with the Express framework, where we used MongoDB to generate a database, where the MongoDB database was used to store the details about the patient as well as the modifications made to the file, which meant that any modifications made to a file could be seen.
The mobile applications was built using Java, using the Android SDK, also using the Gson library.
Challenges we ran into
In the mobile, we came across vague documentation in very specific parts of the layout system, designed for static buttons and fields, not for the generation of fields on the fly. This vague documentation involved researching deep into the Android SDK and example code. Trial and error was also very useful, especially a error-improvement approach where I would run approximately correct code, trawl through the errors produced, and then respond to these errors. This is not the best approach as a rule, but it was effective under time pressure and we would have an even less operational product if I planned and researched carefully.
In the web application, the main problem was trying to approach version control in a decent fashion, because the initial plan was to use Git as a bot in order to start a 'commit, pull, rebase and push' system, however we later found that his was impractical, which meant that we switched to MongoDB.
Accomplishments that we're proud of
We are proud of the fact that in the mobile app, the form can dynamically generate input fields, because this was particularly difficult due to the fact that the Android UI system was not designed for a potentially unlimited number of input fields, and it took a large amount of work and coercing to get it operational.
What we learned
We learnt that in the web application, Git is incredibly difficult to implement as a bot without user control, and that MongoDB is easier to implement. I learnt a large deal about the fundamental theory behind Android UI SDK, the precise nature of views and layouts and the id system, something that I had not worked with in great detail before.
What's next for Patient Tracker
Ideally, the Patient Tracker would eventually become fully functional in both the web and mobile application, with the web application showing the full commit history of each commit, meaning that a side by side comparison could be done, while the mobile app would eventually be connected to a database where commit history could be viewed. In short, connecting the Android App to the Web backend will probably be the next step forwards