A statistical visualization of a patient's test results (sample data) that is included in generated reports.
The web app's main view. Users can manage and create patients, and configure test and test group presets.
The web app's view for managing test groups. A test can be added to any number of test groups simply by adding it from the dropdown menu.
The app's menu for editing and viewing patient information. This tab displays a user's demographic info
This tab allows the user to add test results to a patient's history for storage in the database and use in the generated report.
We chose this project after learning about the incredibly menial process that doctors and medical researchers go through on a daily basis writing reports, manually entering data, and generally repeating tasks that could be automated if only there were someone to do it. This project aims to streamline medical professionals' workflows and save them up to several hours a day through automation and data insight.
What it does
Our product in its current incarnation implements several key features that provide both immediate value and long-term foundations for more complex functionality. Currently, DrDocx has the following capabilities:
- A fully functional user interface built using Material Design principles and with flexibility chiefly in mind; the interface is compatible with desktop and mobile devices alike.
- A backend SQLite database that serves requests from the user interface and various export scripts such as the Word document generation.
- Support for creating medical test presets which can be categorized into test groups (i.e. suites of tests usually administered together) to make test result input quick and easy.
- A Word document report generator that automatically populates predefined fields in a template document and adds data tables plus beautiful statistical visualizations (see gallery) to the end of the document to provide a summary of a patient's test workup.
How we built it
- The main web app was built using an ASP.NET Core MVC app, backed by a SQLite database and EntityFrameworkCore facilitating the interactions between the database and the app.
- Integration with Word documents and templates was built with the Open XML SDK.
- The statistical visualizations (normal curve and bar graphs) were built using Matplotlib and numpy in Python and deployed to an EC2 instance for use as a chart generation API.
- The frontend views were built using HTML templates with CSS from Material Design components.
Challenges we ran into
- The .NET Core ecosystem, while growing, is relatively immature and forced us to make certain design compromises including the use of external scripts to facilitate certain functionality (e.g. we used Python's Matplotlib to create our visualizations after being unable to find a free .NET Core alternative).
- The OpenXML SDK (the SDK used for programmatically interfacing with Word documents) proved to be quite esoteric to use and we found it difficult to create more complex structures through it such as our data tables.
- We had a lot of trouble setting up the AWS instance that ultimately powered part of our statistical toolchain thanks to issues with authentication, dependencies, and general unfamiliarity.
- The merge conflicts. Oh god, the merge conflicts.
Accomplishments that we're proud of
- Above all, we're really happy that we managed to make something we know can be useful to people doing important work. A lot of the work we do as students tends to be detached from any real-world impact, so it's an amazing opportunity to be able to do something that will save others precious time and money.
- We're really proud of managing to work with possibly the worst API in the history of large companies: the Open XML SDK.
- The UI is really professional and resilient against bad input or strange display errors. It's not easy to create a UI that doesn't behave strangely in such a short timeframe, but we're proud that ours is pretty consistent and doesn't lean on hardcoded parameters to appear functional.
What we learned
- We learned that ASP.NET Core is not the best framework to build a web backend.
- We learned to write better asynchronous code that saves time and doesn't break things at inopportune times (we hope).
- We learned a lot about using EC2 instances and containerizing Python apps to run in the cloud.
What's next for DrDocx
Our plan is to get this in the hands of our target audience as soon as possible so we can start getting feedback on where to take this project. Much of the initial functionality was based on input from our contact at UCSF and we plan to start our beta-testing there as soon as possible. We plan to implement predictive insights into the product so that researchers can easily gauge what tests are more predictive of certain diagnoses to save them and their patients yet more time. We'd love to deploy this in the cloud rather than a desktop app so it's easier for more professionals to use, but we'd have to ensure HIPAA compliance first. There's a lot of places to go with this project, and we hope we can make it into something great.
Before that, though, we have to rewrite a lot of the code that we left in place because it technically worked despite being poorly designed. Long-term use by customers who need an extremely reliable product is a hugely different challenge than creating a demo-ready app in 36 hours, and we hope to build on the good and throw out the bad as we go forward on this project.