Josh Padnick’s Blog

There are certain fundamental principles that are supposed to be followed in all kinds of software development — reuse code as much as possible, work lots with the client, etc. There is another fundamental principle that is very often *overlooked* in software development, and particularly in software designed for physician practices — and get ready because it’s a boring word that’s going to make you stop reading; I present to you the stupefying concept of:

I just read this blog entry (read the intro at the top and then scroll down to the bolded comments by Dr. Kelly Clark) and I think it’s a great example of how software that fails to take account of the workflow process goes beyond simply not satisfying the customer and into the rather unpleasant realm of actually inciting anger in the customer. Yikes!

But It’s Challenging To Do This…
About 1.5 years ago, we began laying the foundation for an administrative automation system for physician practices and so one of the first tasks was to whip out our notepads, go down to physician practices and ask “Okay, so when a patient calls and makes an appointment, how does that work?”. Then we tried to document these answers on paper, then model them in a flowchart, then validate them with the practice, then inquire with another practice, update the model, etc.

This turned out to be *extremely* labor-intensive, generating 15-page Visio documents which helped somewhat, but which ultimately were shelved for a different day.

The takeaway from all of this for me is that, as a healthcare IT vendor, we *ought* to do a huge amount of workflow analysis and engineering, but it’s time-consuming, expensive, a pain for the client, and ultimately drives up the cost to the point where a customer might start to have second thoughts about whether the software is worth it in the first place.

So what’s a vendor to do? Our Solution
Well, one tenet of capitalism is that capitalism always rewards efficient use of resources. I mean, in the end, using resources efficiently is exactly what the system is designed to do in the first place. So, the way I see it, the *inefficient* way to address this issue is to painstakingly and intensively analyze the unique workflow processes of numerous practices and then try to engineer a super-model of the workflow and build our software to that spec.

I think the efficient way to do it is to interview a handful of practices, and then engineer our own workflow process, take it back to them, and say “Well, what do you think?” Obviously, any workflow that we propose had better be accepted by the client or else we’ll re-visit that awful angry zone from the link above, but personally I still think this is a more efficient way to do it.

On the downside, the client has to go through the very awkward process of re-doing their existing workflow, which I would imagine is not only logistically challenging, but risks calling into question the usefulness of some people, which creates an environment of “our software vs. your job”, which would be a terrible situation. But if that particular issue can be managed and a workflow process could be engineered that is both very well-designed and doesn’t aggravate the client, then we’ve actually succeeded in creating useful, efficiency-boosting software at a very reasonable price.

We’ll see what happens…