This article is initially available on our podcast. Click here to listen.
We keep running into a problem that’s making our lives difficult. I just thought I would share it because I’ve got to believe that everybody runs into this type of thing, whether it’s an internal project. It’s, “Do people understand what their requirements are?” The short answer is, “No.”
I think there are two parts to this. One is, “Do people understand their requirements?” and the second is, “Can they communicate those requirements?”
Create one set of requirements for specific processes
The issue we’re running into is really about the communication of requirements. When somebody needs something done in software, in analysis, whatever it might be, somehow that has to be communicated to be put into code in software and some types of analysis.
We frequently get a series of requirements from clients. We go through and talk about it, but at some point, there’s a handoff that says, “Okay, give us a set of rules, for example, payment posting rules or some denials management analysis rules.” There is a typically large Word document, or Excel file or something like that says, “Here’s what we do under these conditions. If the payer does X, we do Y” or “Hey, even though we got the CPT codes or something like that, we should not bill that. We should crosswalk it to something else for this particular payer.”
Save time by optimizing workflows
Those are a series of business rules. Translating those into code where we’re making sure that it’s done either automatically or that we are checking to see that it was done correctly when somebody does it manually requires writing in the software or some type of analytic form or, even if you do it in Excel, some logic that says “if this, then this.” That’s generally known as conditional logic: “if-then-else” kind of stuff.
We’re running into a problem because we sit down with clients, and we go through requirements, talk about these rules, and ask and understand. It’s incredibly time-consuming. At some point, there’s that handoff dimension, in which you say, “Okay, now, you guys, we still need the giant list. Go give us the giant list for these or the list for these requirements.” We get it, and we look through it. It’s not in any way something that we can put into code. We cannot automate it because the rules are open to interpretation.
Reduce error by eliminating redundant activities
That means that if we misconstrue it, it’s going to go wonky. There are several levels of this sort of complexity, which is, “Does the person who is communicating to us understand the rule correctly? Did they write it? Did they understand it correctly in the first place? Did they write it down correctly? Are they able to communicate it in a way that is unique in the sense that it can’t be interpreted in many different ways?” Often, the answer is, “No.”
For example, we ran into this recently where we were given an extensive list of business rules. We tried to implement those rules, and we kept running into the problem where we said, “Okay, do they mean this, or this, or this, or this?” And often, a single rule could be interpreted 3, 4, 5, 6 different ways.
Ensure every stakeholder understands how the process works
We went back and said, “Hey, this isn’t clear. Can you guys write this more clearly?” Fast forward a week or two later. We get something back. We still can’t understand it. We’d go back and sit down and even do a bit of tutorial on, “Hey, here’s how you write conditional logic. Try using “if and then” or “if-else” and these kinds of statements. Try using parentheses to sort of lock things off in parentheticals, so that’s not confusing in terms of where you meant the “and.” If you mean to say this, or this and this, is it this or this in combination plus that? Or is it this or that and that?”
Even when I say that it sounds confusing, I mean, you’re hearing me and going like, “Well, I don’t know what he’s talking about anymore. I’m completely lost.” If it isn’t super clear, then everyone’s going to attempt to understand it differently. We’d go through it, and we’d spend some time explaining to their managers, “Here’s how you write conditional logic.” Okay, great. They understand now. They go away. Fast forward ten days later, we get something back. It’s still wholly unintelligible—another fail.
Design repeatable and scalable processes
At some point, we’re escalating it up to the President or the CEO of the billing company, saying, “Hey, this isn’t working.” Then, we said, “Okay, now what? What do we do?” because we’ve tried educating them, and it’s not working. We’ve tried explaining it to them, and it’s not working. We keep getting logic that we cannot write into code.
Yes, we might be able to sit down on each one of these and say, “Do you mean this or this? Okay, and this?” and try to go through the dozens or hundreds of rules, and spend the time to figure out each one of them individually, so we now have it written out and then we can put that into code. That’s so time-consuming. It isn’t repeatable and scalable.
We’ve been trying to figure out, “What do we do? How do we get through that?” That’s where we’ll leave today. We’ll come back, but there’s a problem that we’re facing.
If the department, if a provider group, or whatever it is, cannot communicate what a rule is or it’s open to interpretation, then that means if you have got an entire team of people doing charge entry or whatever it might be. For instance, even if you’ve written down the rules, six different people will do it 5, 10, or 12 different ways. The same person might do it differently this month from last month when they read that same rule. This will create all kinds of problems, regardless of whether or not you’re performing analysis or running applications to review these issues. This is a real problem from an operational standpoint, not just an analysis standpoint.