Why does EDI have to be so hard? (Or, "Healthcare EDI is a freak show!"*)

Okay, let me be the first to ask:

Why are EDI transactions always so difficult???

• Why is it that we always have to put quotes around the words "healthcare EDI standards"?


• Why is it that we have to conform with absolute precision to a each of a variety of specs for outgoing transactions (270, 837, etc.), but payers can send us whatever crap they want (particularly in 835 remittance files), and we have to adjust our systems to interpret them?


• Why is it that we can't send test claim files to payers to ensure that we're meeting their wacky specs? Why do we have to wait until one of our customer actually sends a claim to the payer before we can know with any certainty that our claim generation system works?


• Why can't Medicare and Medicaid intermediaries be forced to comply with HIPAA transaction standards?


• Why can't state payers (primarily Medicare, Medicaid, and the Blues) conform to their own standards?

If it sounds like I'm a bit miffed...well, I am. Partially because it takes so much of our time to keep up with shifting requirements, but mostly because I'm convinced that it's on purpose!

I just finished watching a DVD that was produced by Healthcare IT Transition Group, whose stated mission is (in part) "to reduce the cost and improve the quality of healthcare through the development and implementation of robust IT standards." A worthy cause, by any standards...unless you're a healthcare insurance vendor. The video is called "Defeating the Denial Engine", and it describes new tools that enterprising vendors have created and are selling to payers to help them reject more claims and, consequently, pay out less money.

Here's the idea: This new class of software allows a payer to dial up the percentage of claims that are denied, using a huge array of rules that can, to varying degrees, be reasonably justified as valid rejection reasons. If the payer sets the dial too high, resulting in a flood of complaints from providers, then they can dial it down a bit until the protests become manageable.

That's a complicated way of saying, "Insurance companies will make it as difficult as possible for a caregiver to get paid...without dramatically reducing the number of providers that are willing to contract with them."
For those of us whose mission it is to help our customers get paid by insurance companies, it means that we need to redouble our efforts to understand exactly what it takes to successfully submit a claim to every payer in the nation, and abstract as much of that away from our customers as possible.

I foresee a world where all a biller has to do is ensure that patient encounters are coded correctly (according to the common best practices of the specialty for which he is billing), and the billing software (presumably AdvancedMD for smart billers) will address all of the carrier-specific idiosyncrasies automatically, behind the scenes.

AdvancedMD certainly goes a long way towards that utopian vision--perhaps further than any of our competitors, if you believe what our customers say--but we still have a long way to go. We are actually doing some pretty exciting work right now to take us even further down the road, which I'll write about as we get closer to release.

*The association of the word "freak show" with healthcare EDI was originally made by Steve Lewis, our own EDI guru, also known as "Morpheus".

In Support of UI-First Software Development

It has been several years since I became convinced that the only reasonable approach to development is "top-down/bottom-up", or "top-down design, bottom-up development." More to the point, I assumed that the rest of the world was on the same page.

As it turns out, there is still considerable debate on the subject. Even within our Engineering team at AdvancedMD, we occasionally see examples of database-driven UI design, instead of UI-driven database design.

As I've studied the issue, I've discovered that the terms "top-down" and "bottom-up" mean different things to different people. In fact, my definitions are probably completely wrong, if this wikipedia article is accurate. For the purposes of this article, though, here's what they mean to me:

Top-down: This could also be termed "front-to-back", I suppose. It means that the UI design is fleshed out, prototyped (in the ideal case), and reviewed by stakeholders before any work begins on the middle and database tiers.

Very closely related to top-down design is the notion of UI-First Software Development, as described ably (although certainly not as a totally original thought) by Jeff Atwood. As Jeff states, "...the user interface is the application."

A variation of top-down development is top-down/bottom-up development. In this approach, the feature or application is designed from the front to the back, but then the actual development (schema and code that are ready to check in to the build) is done from the database forward.

Bottom-up: In the bottom-up approach, the UI may be described, or even roughly illustrated in a screen shot, but design begins at the database, based on the developer's understanding of what the purpose of the feature is. Or perhaps the middle tier class architecture and database design are built roughly simultaneously.

(I'm using the term "UI" loosely for this discussion. In fact, the UI could be an API interface, or XML contract, if the feature has no visible UI.)

The strongest argument for bottom-up design: It's where most developers (particularly those who started out their careers in database development) feel most comfortable. Think about it: What would you rather do, work with end users and business analysts to design a usable UI that meets complex business requirements, or build a properly normalized relational database schema? Most developers would find the latter far more enjoyable.

Also, if you're lucky, you have application designers on your team who are responsible for the aesthetics of your software. It's much easier to leave that aspect of software development to someone else...after you've build a solid framework to support the facade.

So, why would a developer choose to migrate from a bottom-up approach to top-down?

Simply stated: Far less rework is required if the UI is fully understood and reviewed by stakeholders before development begins in earnest.

It's a fact of life that it is nearly impossible for stakeholders to fully understand the implications of UI design decisions without being able to see the UI. And it's very difficult for them to anticipate show-stopping flaws in the UI design without seeing a prototype within the context of the application as a whole.

Here's a typical sequence of events for a simple project using a bottom-up approach (with creative input from my 10 year-old son):

So, how is a top-down approach different? Phases 1 and 2 are essentially the same. No matter how you tackle a project, the stakeholder is going to express her idea in ambiguous terms, but the developer is going think that he understands, when in fact they are speaking different languages.

The key is in phases 3 and 4. Instead of spending days or weeks building a product that he doesn't understand, the developer creates a screenshot that illustrates his understanding of the stakeholder's idea. When the stakeholder sees the screenshot, she immediately realizes that, while she envisioned two concentric circles, the developer understood two adjacent circles of the same size.

Then the developer creates a prototype of the square with two concentric circles. The result is exactly what the stakeholder originally envisioned, but the prototype allows her to see the square and circles actually working together. She realizes that the inner circle really needs to be a triangle. The developer refactors the feature accordingly, and the stakeholder certifies that the design meets the business needs of the customer.

Finally, the developer builds the feature, in roughly the same amount of time that he would have spent in the bottom-up approach. In all likelihood, some tweaking will be required, but no major rework will need to be done.

Clearly, there are environments where a bottom-up approach will give you better, faster results. Perhaps that's the case when the data is the application. But that's certainly not the case at AdvancedMD, where usability and efficient workflow are key to our success. I would imagine that most other HIT software vendors are in the same boat.

As I've written this post, it has occurred to me that one of my other favorite development patterns, "the walking skeleton", is extremely well-suited for top-down development. Or, perhaps top-down development is well-suited for walking skeletons.

They also share a potential hazard: As soon as you show a customer or other stakeholder a "working" prototype, they may see the feature or product as "nearly done" and become impatient when the final product takes 5 or 10 or 100 times as long to build as the prototype.

In any case, I'll be writing about that combination later.

Secrets of Our Success - Secret #1: The Power of Really Caring

AdvancedMD has been astoundingly successful in a highly-competitive, ridiculously complex market. Having been with the company since the beginning, I may be able to provide unique insight into the secrets of that success--insight that only a few others may have.

With the objective of sharing that insight, I will be posting a "feature", if you will, called "Secrets of Our Success" from time to time, as ideas manifest themselves. This is the first installment.
---
During the 6 or so years that I led the Engineering efforts at AdvancedMD, I developed a great respect and, I have to admit, affection for the people that reported to me. As my role has changed, I've often paused to reflect on what makes them so special, both as teams and as individuals.

First of all, you have to understand that our Engineering staff are highly skilled professionals with unique and varied backgrounds and experience. Maybe that's enough, but what I think is more important is that they truly care about the quality of what they do.

It's certainly true that everyone makes mistakes at times. We focus on the wrong tasks, or we misunderstand instructions from the "business side of the business", or whatever. Mistakes are made at AdvancedMD just like everywhere else.

But the fact that our developers, QA techs, technical writers, business analysts, and project managers care about what they do reduces both the number of mistakes that are made and their impact.

What is really important in terms of the overall success of AdvancedMD is how much everyone across all departments sincerely cares about the services and software that we deliver to customers.

One of the side effects of this caring--a side effect that is simultaneously painful and beneficial--is occasional conflict. Maybe it's obvious, but I'll say it anyway: Any time two people approach the same problem from different points of view, there will be some butting of heads. If both parties really care about the problem, the butting of heads can be uncomfortable.

So it shouldn't be a surprise that at AdvancedMD, a company of over 150 employees who nearly all care deeply about what they do, and who have over 150 different points of view, occasionally we butt heads over differences of opinion, some trivial and others vitally important.

What makes this conflict constructive, though, is that we care enough to butt heads and enough to discuss and resolve our differences frankly and openly, with a willingness to give ground when needed.

Most of us have worked in environments where the majority of the employees didn't really care about their work. We've heard phrases like, "she's working for the paycheck" and "he's always on the 5 o'clock train". Fairly or not, many government agencies are notorious for not really caring about what they do, or the people that they are supposed to serve. (I could tell you some stories about the DMV in Tucson, Arizona...)

No one likes to work in that kind of environment...except, perhaps, people who don't care and don't want to care.

In contrast, AdvancedMD employees, for the most part, genuinely enjoy working at AdvancedMD, even if--or, perhaps because--they occasionally butt heads with other employees who also care.

I could name a dozen occasions over the past month when I have walked away from a conversation or meeting with another AdvancedMD employee where I could have been deeply offended by what they had to say. But, in the end, I couldn't be offended, because I recognized that our disagreement, or their (usually constructive) criticism, stemmed from the fact that we both care. And I'd rather be miffed by someone who cares than pandered to by someone who doesn't.

I've theorized that perhaps AdvancedMD employees care because, besides being conscientious professionals, they recognize how important healthcare IT is to our customers and their patients. Our software and services have a direct impact on peoples' health and well-being.

Whatever the reason, the fact that we care is, I believe, one of the reasons for our success. I highly recommend it. If you're an entrepreneur or executive trying to build a successful business, hire people who care. If you're looking for a job, find a company where the management and employees care. If you work with people who don't care, figure out why and try to change the culture.