The current medical systems are too cumbersome and too high maintenance. Legacy medicare portals make it impossible for the patients or providers to seamlessly access their records. Various backend APIs work in a standalone fashion which makes it difficult to harness the true value of the data collected and its correlations.
What it does
After spending several hours trying to design a simple, agile and efficient UI for a Patient Data Management System, we were very clear about one thing- there are some problems for which the statement- “One solution fits all” holds true, and this was not one of them.
As we explored the data provided by the APIs and the use cases in which they might be of use to different actors, we became aware of the fact that utility for each one of them varies widely. A doctor might use patient’s data in a completely different manner when compared to an anesthetist, or a neurosurgeon compared to a dentist. Coexisting with this variety are use cases common to all and personal preference of some data points over others.
If we provide all users with all data in collated fashion, they might get overwhelmed. On the other hand, if we provide a minimalistic interface, they might find themselves doing the same search and nested-menu navigations repeatedly, and handicapped to not be able to put two data points side by side and compare them.
With the motivation to design an application which resolves all the aforementioned problems and more, we designed Medified - a juxtaposed UI for the patient data management system, which can accommodate all these demands by providing flexibility of use. The design categorizes data points into 4 major fields - “Previous Diagnoses”, “Previous Medications/Allergies”, “Physical Exam and Lab Test Reports.” We noticed that not all the data was available for all the categories every time, and wanted the user to know about the availability of data points for each category(or the lack thereof), without the unnecessary need to go their “nested-menu”. A user can select the kind of widgets that they want to see for each of the categories and can decide what data is important to them. They can also compare relevant data by placing two widgets side by side.
We explore this by one particular use case, where a doctor wants to search for currently available medicines for a compound, by looking at the list of active illnesses a patient is suffering from currently. This has been done by providing an option to the user to display the widgets he uses most frequently tiled on the main page. We have created some more widget designs which can be juxtaposed to be of more use to a particular user. These widgets have been designed by analysis of the data available from the APIs, directly or indirectly. We have assumed required data for these widgets is efficiently available without much delay. We have also presented the diagnoses data for any user in a time series manner for the easy tracking of patient's history.
How we built it
Challenges we ran into
The biggest challenge we faced was lack of domain knowledge in the field of healthcare, as a result of which we had to put in a lot of effort in understanding the technical jargon presented in the API response and mapping relevant data to present on the UI. Another big challenge we faced was understanding how to fetch API response for SDA and integrating that into our application due to some limitations in the API which were not explicitly mentioned in the documentation provided. We also faced challenges on the data inconsistency for different patient records.
Accomplishments that we're proud of
After being unable to get anything to work, inspite of scratching our heads so hard, for the entire first half of the hackathon, we're proud of having built an app that is not only useful owing to its design, but also a huge improvement over the existing UI in terms of grouping data from APIs based on the specific use-cases which are commonly encountered in the daily activities of any entity interacting with the system. We're also proud of having implemented the idea of user-specific UI, which is uncommon in the domain of patient portals. It was the first time any of us were working with real medical data and we're proud of our learning curve in terms of using our computer science knowledge to solve problems of the healthcare domain.
What we learned
We gained important insights into the complexities of medical data, in terms of storage and retrieval and also from the domain knowledge point of view. Figuring out how to best map the huge amounts of patient and hospital data to enhance usability and ease-of-experience as well draw conclusions which may have been previously unknown was the most important learning gained from the project.
What's next for Medified
The project has huge scope in terms of the possibilities that could not be explored over the short period of a weekend, but we have chalked out a plan-of-action to design a full-fledged web-based tool which could be used to capture the entire journey of a patient through the healthcare system seamlessly.
First-off, a feature to generate a prescription for the printable patient and insert that record into the database. Secondly, make the system blazing fast by implementing cache mechanisms - this can be accomplished by running batch jobs on the server during off-peak hours to generate and pre-store info for all widgets the user has selected for frequent use