This past weekend my wife lost the crown on her tooth, and by Monday afternoon I had a better understanding of software design. How? Monday morning she called our dentist. We have new insurance, so she’s never been to this dentist, but we had to pick a dentist when we signed up (so I found the one closest to the house.)
The conversation with the receptionist went something like this:
Receptionist: How can I help you?
Wife: I think I lost one of my crowns this weekend. I haven’t been to your office yet, but I really need to see a dentist.
Receptionist: Ok, do you have insurance?
Receptionist: Who is it with?
Receptionist: Is it a dental HMO?
Wife: I don’t know.
Receptionist: You don’t know?
Wife: No, would it be on the card? I can give you the number.
Receptionist: Well, give me your name.
<Wife tells her name, date of birth etc>
Receptionist: Oh, you’re already in the system. We can see you at 2 today.
As my wife told me this, she told me that the receptionist couldn’t believe she wouldn’t know whether she had a dental HMO or something else. During this conversation, I immediately went to software (it’s this illness I have, I always think about coding.) In particular I went to the number of applications I’ve written where I’ve asked the user information that they no doubt didn’t care about.
Asking for Too Much Data
For example, on one quoting application, we asked them which of the 5 different types of conductor bar they wanted to use. This was information WE as a company cared about, but a lot of our customers might not have cared about. Instead, we could have asked information that the user cared about and still got our information.
What was my wife after? Dental care ASAP. But the receptionist was too caught up on what she needed, and most likely the receptionist was filling out some form written by one us that has about 30 different fields a few radio buttons, maybe a couple of dropdowns.
So the dentist office has challenged me as a developer. There is data my application cares about (e.g. user’s DOB) and there is data my customer cares about (e.g. the cost of some widget.) The game becomes, what’s the fewest number of questions I can ask to satisfy both my application and my customer?
In the case of the dentist above, I think I could satisfy both the receptionist and the customer with 2 simple questions.
- What insurance provider do you have?
- What is the insurance number?
After that, the receptionists software could see it is a Cigna policy, go out to their database, with our policy number. Look up our policy and return the data to the receptionist. Not just if it’s an HMO or PPO or (or any other O) but customer information as well. For example, some of the information that Cigna knows and the dentist office wants is:
- My home address
- My wife’s date of birth
- Policy expiration date
- Whether our deductible is met yet or not
So instead of the receptionist asking all of this information, she could pull it from Cigna, and when my wife goes in, all the receptionist would have to ask is “Are you still living at this address?”
What Really Matters?
What’s the goal of the receptionist’s questions? She wants to ensure that she has the right patient information so the office can collect the funds that are due in a timely manner. That’s pretty important. If they get it wrong it will be a costly error. But it’s precisely that it is important data that should inspire us as developers to help simplify the process. What is more likely to introduce an error? Dealing with 100 different people providing information? Or dealing with 20 different insurance companies’ databases?
Does Anyone Get it Right?
The best example, to me, of an application that gets it right is Mint.com. When I signed up, it asked for some information, for example my bank’s login information. As soon as I provided that, it started pulling in my information. I can go to Mint right now and see not only what my expenses have been, but what group they are, because Mint knows that when I use my debit card at Qdoba that it’s “Eating Out” or “Fast Food.”