Patient Record System
Fighting Childhood Cataract in Africa
In Africa, it's estimated that 60% of children die within a year of going blind. Over half of the childhood blindness in Africa is caused by congenital cataracts, which can be corrected if caught early. These children need to be operated as early as possible to ensure that the development of the visual part of the brain has enough and correct visual input. The follow-up examinations are also important, as children's eyes will need new pair of glasses or treatments for optimal correction at different growth stages.
Partnering with Emory Global Vision Initiative, the goal is to design and develop a system to facilitate the cycle of "early referral", "treatment", "follow up" and then "rehabilitation" to fight the childhood blindness problem in Africa.
I started by understanding how medical staffs from Kilimanjaro Christian Medical Centre (KCMC) in Northern Tanzania accomplish their work practice. Rather than directly asking them about their expectations to the system, I wanted to identify the challenges encountered during their daily tasks and learning their feedback to the existing tools they currently use.
I then came up a workflow diagram to summarize and illustrate the scenarios that users may encounter in the field. And then I walked through the diagram with the Emory and field teams to make sure the diagram captured their works and needs. Finally, based on the data and feedback, I started to look for the feasible technologies to support users' need.
In the meetings with Emory team and field team in Africa, we narrowed down the scope to bring up a system that makes sure:
Medical teams from Emory told us they have plenty of Google Nexus 7 tablets as donations; therefore, it would be good to have some features built running on Android devices.
At first, I ever considered designing the reminder experience similar to the "Google Calendar": an Android application that pops up a notification on Android device's notification bar for the upcoming scheduled events. However, the field team pointed out that the penetration of Android devices is still low in most African countries. In additional, the mobile network coverage is another challenging factor.
Therefore, I decided to design and implement the system with two primary portions, the Data Collection and SMS Service.
Data Collection:
SMS Service:
I took the existing paper-based medical form from Kilimanjaro Christian Medical Centre (KCMC) as the reference, and decided to separate the lengthy medical form into several distinct forms. I grouped similar fields based on similarity and the stages of the medical treatments:
By doing so, it brings two advantages:
I implemented the system on top of Open Data Kit (ODK), which is a free and open-source software as the base of the project for better sustainability. The ODK system consists of two main components:
1. ODK Collect is an Android application that allows users to download and fill out pre-defined data forms (like our medical forms) on android devices, and submit the collected data to the server-end application ODK Aggregate.
ODK Collect supports the following features:
See screen captured video of collecting patient's data: DEMO VIDEO: INTRA-OPERATIVE FORM - DAY 1
2. ODK Aggregate is the server-end application that manages the forms being uploaded, and the submitted data from the ODK Collect (the android-end application). I deployed ODK Aggregate on Amazon Web Services (AWS) Elastic Compute Cloud (EC2) with Tomcat6 and MySQL database. ODK Aggregate supports the following features:
For our electronic medical forms, I utilized XLSForm to edit and design the form with Microsoft Excel and convert into XForm for compatible with ODK.
For patient referral, the SMS Service allows the community workers to send patient's name and contact phone for referring patients with regular mobile phone. The medical team in hospital can review the referral list on the web UI and check the visiting status to see whether or not the patient has visited hospital.
For follow-up appointment, the medical team can schedule a future appointment for the patient by submitting the 6. Follow-up Appointment Form on ODK Collect. And then the SMS reminders will be generated and sent to patient's contact phone about their upcoming appointment. The medical team in hospital can also tracks the history of visiting status regarding the missed/visited appointments on the web UI.
I leveraged an existing open-source software called RapidSMS and design the UI and logic on top of it. RapidSMS is built with Python and Django for dynamic data collection, logistics coordination and communication by using basic SMS mobile phone technology.
I designed the overall system architecture and deploying RapidSMS and ODK Aggregate at the same Amazon Web Service EC2 server. By doing so, RapidSMS can automatically generate SMS reminders by pulling out patient's data that previously been sent through ODK on the Android tablet from the same MySQL database.
I started UI design with the low-fidelity wireframe using Balsamiq Mockups. On the navigation bar, two buttons are served for switching between "Appointments" list and "SMS Referrals" list. On the left hand side, I envisioned having drop down menus for selecting the data filters to query the list shown on the right hand side. On the top of the list, a button is served for exporting the filtered list as a spreadsheet (CSV) file.
Since the medical team will be inputing the medical data with Android tablet, the web UI of the SMS Service should be responsive design to work great on the Android tablet.
After all parties agreed on the lo-fi mockups, I started to work on implementing the system accordingly. The SMS Service is now running on the same Amazon AWS (EC2) with ODK Aggregate. By doing so, the SMS and ODK service can runn collaboratively with shared database for updating the "visiting status" of "Appointment List" and "SMS Referral List".
For mobile view, with Twitter bootstrap, it is easy to change the layout according to the screen resolution. Here I list several screenshots of how the UI looks like on a Android Nexus 7 tablet.
Since conducting the usability evaluations in remote settings could miss lots of feedback and context information, I decided to apply the surrogate users models (proxy user) and recruited participants from Emory Global Vision Initiative for usability evaluation.
The system consists two primary portions, the Data Collection portion for collecting medical data, and the SMS Service portion for patient referrals and sending reminders to patients for their follow-up visits.
For the usability evaluation, I followed the workflow diagram and created multiple benchmark tasks for different stages of the treatments and asked the participant to go through the task with a fictitious patient named, "George Burdell".
Seven Likert scale - (1: Least agree, 7: Totally Agree)
I calculated the average score and the standard variation for the answers of these five questions as shown in the bar chart to identify where can be further improved.
Please see detail evaluation analysis in the project report:
PROJECT REPORT
Open-end questions - (If yes, please specify.)
I conducted semi-structure interviews to gather feedback. The questions were mostly open and qualitative in nature.
Please see detail evaluation analysis in the project report:
PROJECT REPORT
Our system currently depends on ODK Aggregate to access patients' medical records. To review patients' medical record, the physician must go through below steps:
From the discussions with the medical teams, the on-going works include designing a refined UI portal that dedicates to access patient's medical record. The ideal experience will allow the physician to view medical record about an individual patient at once without switching among different medical forms.
