We’ve spent the last few weeks coding an early prototype application and testing it with users in Richmond! Here’s what we’ve built so far:
A pre-screening tool allows the user to input the most basic eligibility information and learn whether a patient is likely to qualify for each service. This isn’t a definitive answer, but it helps the patient figure out whether it’s worth filling out the full application.
The full patient profile contains the questions currently found on the paper application forms for the health services we’re working with. We’re hoping that if all this information is filled out, it can replace the paper application for a patient.
Initially, a patient’s information is only available to users at the organization that created the profile. If that organization wants to refer the patient to another service, they can use this feature to make the profile available to users there.
What happens if a community health worker creates a record for a patient at one of the resource centers in the public housing communities, and the patient later shows up at a clinic, but without an explicit referral from the resource center? The clinic could contact the resource center and ask them to share the patient’s information, but that could take a while. This feature would allow a clinic user to look up the patient by name and date of birth, but hides the rest of the patient’s information until the user confirms that they have the patient’s consent. After providing confirmation, the user can immediately access the information.
Was this address updated last week or two years ago? Who can I contact if I have questions about an application filled out elsewhere? What other organizations have screened this patient? This section tracks changes to each patient’s profile, allowing users to check when each piece of information was added and by whom.
Despite all the research we’ve done, anything we build at this stage is based on our assumptions, both explicit and implicit, about what users want and need. Only those users can tell us which are right and which are wrong, and we want to get that feedback early and often so that we can make sure what we build works for them. The main goal of our trip to Richmond at the end of May was user research. This usually means showing our prototype application to potential users and letting them navigate through it without too much direction, asking them about their expectations and thoughts at each step.
We focused on people in three different roles.
Much of the user feedback focuses on UI details. For example, it doesn’t make sense to ask about the spouse’s employment status if the patient isn’t married. Or a dropdown for phone number type (home, cell, work, etc) would be easier than a text field. We want to fix these issues as quickly as possible to eliminate potential pain points. But most important are the big questions: What would you use this for? How does it aid or hinder your goals? What would prevent you from using the software today? What would make you want to start using it immediately?
Here are a few points we heard repeatedly:
Ben is in Richmond this week, running another round of user research and then helping out the Code for RVA Brigade at National Day of Civic Hacking on Saturday. Sam and Emma are in San Francisco, preparing our mid-year presentation and report. After that, we’ll spend a few more weeks coding new features and adjusting existing ones based on user feedback before Sam travels back to Richmond the week of June 22nd for more user research and the Richmond Latino Health Summit. Features at the top of our list include:
As always, you can follow our progress on Github!
