The inherent complexity of medical payments

It goes without saying, but I’ll say it anyway: medical billing is complex. That complexity can confuse and infuriate patients, often when they receive an enormous bill after their insurance company denies a claim. In an effort to avoid this scenario, most patients are interested in determining whether a provider accepts their insurance plan before they commit to taking on financial responsibility for a visit. Many patients have faced historic struggles to determine what insurance their providers accept, at a plan level. Why?

Well, let’s start with the providers. For now, we'll assume a health system with a substantial presence on the west coast, just because that's where I have the most experience.

In most of the areas the system services, providers are employed directly. For example, your primary care physician in Washington is typically a system employee, and while she might get paid a salary or effectively work on commission (via her delivery of RVUs, or “relative value units,” part of a reimbursement formula), she files a W2 with the system as her employer. California, as usual, is weird. In the name of separating profit motives from medical decision making, hospitals and health systems are not allowed to directly employ physicians, although they can directly employ some non-physician providers like PAs. Anyway, we’ll call these providers “non-employed,” for now. 

So, we’ve got employed providers in a few states, and then some non-employed providers in CA. There are also “affiliated” providers, who are not employed by either the system or a foundation that manages non-employed providers in California, and may choose to work for competitors or operate an independent practice. Often, these affiliated providers are in an HMO-like agreement with the system but may otherwise be completely separate from their employed and non-employed compatriots. 

Still awake? All right, let’s talk credentialing. 

If you’re a bright-eyed college graduate with dreams of being the next Dr. House, you’ll apply to medical school, get in, complete your studies, and then apply for your license and become a resident. After a few years of residency, you might decide to enter practice, or delay that for a few years as you go through your fellowship in a specialty. Eventually, a grizzled veteran on the wrong side of 30, you’ll be an attending physician. But if you want to pay down those student loans with reimbursement from commercial insurers, you’re going to need to be credentialed. This is the process where your qualifications are reviewed: did you actually go to medical school? Did you graduate?Is your licensure in line with your specialty and location? Were you actually a resident at Princeton-Plainsboro or is that just a hospital from a TV show? If you pass the test, you are “credentialed,” and can submit claims to payors with a reasonable expectation of reimbursement. Credentialing is usually something that comes with your new job at a system or foundation.

The last piece is contracting, which is typically the purview of a larger entity than a single provider. The system negotiates contracts with payors on behalf of its providers. Contracts include things like reimbursement rates per procedure (CPT) code, network definition (e.g. all these doctors are in the System West Choice network), and covered service locations. These covered service locations are typically identified by a federal tax ID number (TIN), with a TIN representing a geographic area as small as a clinic and as large as a state.

Once a provider is credentialed, she is assigned a TIN. That credential information is sent to the payor and the provider is able to bill for services rendered to payor plan subscribers in that area as long as her credential is active and the contract is live.

Let’s recap:

• provider gets a job with a health system (or a foundation, in California)
• the provider gets credentialed with help from the system or the foundation
• the system establishes a contract with a payor

If you combine those three things, you can state with absolute certainty which plans a provider accepts. If the provider is assigned a TIN of 1234, and the system signs a contract with Aetna that includes that TIN as part of a network, then the provider is now part of that network and can accept all plans assigned to that network. TINs usually represent many providers and locations, so that contract might cover 400 doctors across tens of facilities.

So, I'd call this "complex, but not especially hard." Why can’t health systems just publish this data to the web immediately? Well…

1. Contracts are big. I have reviewed contracts which are over 20 individual documents, each of which contains a variety of stipulations that affect coverage. Systems have entire teams dedicated to parsing these contracts and it still takes them a long time to get them right. they are usually amended at least annually.
2. Credentialing changes frequently. The system has to supply payors with an updated credentialing database monthly.
3. Affiliated providers have their own contracts independent of the systemand aren’t obligated to share them. Depending on the system, affiliated providers may form a substantial plurality of providers at their facilities.

Ultimately, improved contracting, credentialing, and legal procedures can make life easier for patients. Just don't expect to see it until the payors make demands.

How not to hire people

Hiring good people is important. It's so important that it's amazing how bad most companies are at locating and hiring top talent. Today, an example from Northrop Grumman:

 
Nope.


Wrong.

With regards to this specific case, it's stupefying that a company would admit, on social media, that their hiring process is so bad that they can't even tell you what their hiring strategy is, much less how much time you can expect to spend waiting for a call from HR. Stupefying.

Unfortunately, this is not unique. Larger corporations are typically the most egregious offenders, but most companies post a job listing which includes incredibly specific skill requirements and experience metrics.  That makes sense, right? The company has a specific need and they're looking for someone with a very particular skill set to fill that need. But I've got some bad news: that person doesn't exist, and if he does, he's not going to work for you.


Top talent is in high demand. All the time. By the time a company has gotten around to interviewing candidates for a position, debating salary brackets with the finance department, and mailing (?!) an offer letter, the best candidate will already have received and accepted an offer from someone else. An interview should be used to determine three things, in this order of importance:

1. Culture fit
2. Problem-solving mindset
3. Existing skills

Truthfully, existing skills don't really matter. Past experience is a useful, but dull, tool, but if the candidate is not a culture fit with an organization,  nobody will want to work with him and his time at the company will be a failure. I have seen many so-called "ninjas" and "gurus" and "rockstars" endlessly stumble because they can't pour some coffee without bothering someone. Interview for culture fit and willingness to learn and you'll quickly find yourself with a staff that performs much better than a staff composed of experts.

Goodness, be expedient with  offers. In 2012, particularly in engineering and computer science, there is no reason why a candidate shouldn't be made an offer immediately following an interview. Before the candidate even shows up, you should already have reviewed his portfolio, be it a github page or an assembly of Solidworks drawings. Once you've made sure he's a fit, in the interview make him an offer, and if you're serious about hiring top talent, make him an offer at market value.

A litmus test: if you have to ask candidates to review your "application process," you've most definitely strayed from the path.

Your users aren't engineers

Make no mistake: you must always speak with your users. As much as I'd like to celebrate my awesome software once we ship, the users get the final say in just how awesome it is, and users don't like software that doesn't fix their problems.* The only way you fix problems is by understanding them, so yeah, talk to your users.

The problem, though, is that users aren't engineers. The same attention to detail they exhibit with their daily tasks is the same attention to detail that derails most demos and leads to four hour excursions into "well can that be a radio button instead of a picklist because it's only ever a select one and never a select many or select all." Your users don't know how easy or hard it is to change things, and they should never (never!) be forced to sit through a technical discussion with an architect to learn the finer points of configuration versus code.**

Worse yet, these discussions typically result in a very slick, very expensive system that effectively reproduces the Excel spreadsheet you're trying to replace. Yes, absolutely let your users help define their own future workflow. Understand, though, that they will always be predisposed to doing things the way they've always done them, and that usually means something like "copy this data to this spreadsheet, move that cell there, and then run the macro."

What can you do about this?

First, pick a use case. At the start of your meeting, mention that you are going to do a quick walkthrough of the new process before you get into details. Execute the steps in your wireframe/comps/demo as if you were the end-user of the system. Gloss over details like button placement and instead show the benefits of your new process: reduced time, reduced complexity, reduced duplication, and increased automation. If you do a good job, they'll stop trying to replicate Excel and start identifying MVP requirements and changes to your process.

Next, have your user walk through the same steps but ask for feedback along the way. If they start talking about trivialities, direct them back towards what;s important. YOU know what's easy to change and thus undeserving of your user's time. THEY have the business context. Trade valuable information, not errata.

Make sure to ask the right questions. You're iterating, so you need to know whether something is truly part of your MVP requirements or not. Don't ask whether they need something, ask whether it's something they do 100 times a day or once. Ask them if it's truly painful or just an annoyance. Figure out what they're willing to trade for this feature that covers an edge case; I personally love the "buy a feature" exercise*** because it highlights priority to users.

Regardless of the quantity and quality of user feedback, business analysis still needs to be done by business analysts. Use your technical knowledge to apply the business context to your solution and everyone drinks champagne on launch day. Otherwise, invest in scotch.

* This isn't always true. iTunes is a classic example of bad software with adoring users. 

** When should they be subjected to this? You have two choices: 
        1. Never 
        2. The day before they complain to their manager about how annoying/confusing/rude the PM from Tech was.

 *** Give your users a list of features and $100. Tell them they can spend the $100 on whichever features they like, but they only have $100. If you want to make it really interesting, you can price the features (where $100 represents the total development capacity of the team) to give a sense of scale. Maybe the big feature isn't as important as fifteen little ones. With a representative sample, you'll have an indisputable prioritized list of features to hand to your product manager. Out of the mouths of babes...

Uptime matters more than almost anything else

Image courtesy of this guy.

Although the meatspace event ended hours ago, those of us on the west coast are just now watching the Spice Girls drive around on LED-encrusted London taxicabs while singing hits from elementary school. Or rather, West Coasters who don't have DirecTV are watching the Spice Girls. I'm watching the error message above that describes a solution but does not enumerate said solution in a way which precludes the need for additional Googling. The "no need to call us" is particularly cute.

The abrupt failure of high definition television services for the west coast, notably Los Angeles, inspired some strong feelings on Twitter. When the error message appeared, I immediately opened Twitter with a search for "directv." The results were...well, take it away, Nima:

 

You and me both, friend.  Of course, some people felt the need to politicize the issue:

 

I had no idea President Obama had such a tremendous influence on television broadcasts from space. Guess I'm voting Republican. Meanwhile, Crystal made a statement of truth, followed by a statement of questionable veracity: 

 

 Melissa makes yet a bolder statement:

Agreed. I've been waiting ages for the Spice Girls to sing together again. Ghetto University has a simple question:

We'll hold off answering that for a moment while Natasha broadcasts from the Winter Olympics. Vancouver 2010 or Sochi 2014?

Ms. University has, apparently, decided that she is, indeed, being punished, and is not pleased with this:

Nobody puts babby in the corner!

There's two things I'd like to note from this.

1. Before Twitter, how did we all whine?
2. Uptime matters. Five nines is not sufficient. In a world where we're looking to save nanoseconds of latency in financial transactions, dropping rovers onto Mars with rocket-powered skycranes, and driving around in LED-encrusted London cabs, there's no reason why every enterprise application shouldn't have 100% uptime. It's time to step messing around. 

Yet another reason why I'll never be rich

My desk at work is at the far end of the office and mostly obscured by the other cube walls. With goaltending being pretty rough on my knees, I like to sit very low so that I can keep my knees bent when I'm sitting or easily straighten them out by slumping in my chair. This means that people can't see me until they get all the way to my desk. This annoys people.

Were I somebody else, I would default to one of these options:

1.) Deal with it.
2.) Increase the height of my chair and get a box on which to put my feet.

But since I'm not somebody else, I started using this sytem where I placed an index card on the wall behind me to indicate to others whether I'm at my desk, away from my desk, or at home. This was an intuitive, low-tech solution, but failed to address the laziness problem. See, cycling between three index cards requires that I pay attention to what I'm doing and remember to change the cards.

I don't.

So instead of a reliable indicator of my presence, the cards were serving as public reminders of my laziness. They were lying to my coworkers' faces.

The one thing I don't forget to do, courtesy of college roommates, is forget to lock my computer. So I started thinking about having my machine toggle a light on and off when the computer gets locked. Further analysis revealed that this would probably be a lot of work,* so instead I decided to build a light that I could actuate manually.

A little-known fact about my day-to-day interaction with objects is my liking for a good button. Elevators, street crossing signals, keyboards, and anything else with buttons stands to make me much happier with a good, responsive button. Toggle switches are particularly desirable because they've got a solid mechanical feel and a decidedly retro feel.

I go to Radioshack, buy two project boxes, a spool of wire, a package of 68 ohm resistors, a giant LED, a toggle switch, and a roll of solder. We have broken the $20 barrier to build a light. With a broken keyboard donating a usable USB cable, I set to work building the simplest circuit known to man. I can sheepishly admit that replacing a battery with a USB power source in this circuit required the repeated humiliating refactoring of my design as I found myself continually building a circuit whose sole function was to short circuit a USB port.

I swear, I am actually a fully degreed and educated engineer.

So now I have a complicated solution to a simple problem, and all I had to do was spend $20 and a half hour at Radioshack.

*The Googling required to find a piece of software that will turn a light on and off was feeling onerous.

What UX Is

User experience design has spiraled wildly out of control since the release of iOS with the iPhone a couple years ago. Menus have become passé. Navigation is supposed to be touch friendly. Hell, even Microsoft is getting rid of the ubiquitous Start menu, having already eliminated (or at least hidden) the File and Edit menus.

These changes are not improving usability. Changing usability, yes, but not fundamentally improving the usability of an application.

Usability is not a measure of how easy something is to use, although that is often an important factor. Rather, it's a measure of how effectively something helps you complete your work.

Software isn't usable because very often, what we do with software isn't possible in the real world. Unfortunately, we keep trying to create digital representations of physical things in a futile effort to make things easier to understand, more "intuitive*."

Why are we doing this? Why do we keep forcing users into arbitrary folder structures to store files?  Aren't there cases where a single file makes sense in two locations?  Does a user care where a file is stored as long as he can find it? Does it even make sense to require users to save files?

These are the types of questions an effective UX designer will ask.

It's unreasonable to expect that every user will sit down with an application and instantly understand how to complete their work. In some cases, I'd argue it doesn't even make sense to try making an application instantly understandable. There will always be an upper bound on the number of functions an application can perform before it becomes necessary to start stashing things in menus. And that's okay! Users will put up with questionable UX if the software improves their lives. They will not put up with beautiful UX and no functionality.

There are some obvious things to avoid. The California DMV provides a particularly egregious example:

Outside silly problems like this, though, good UX is achieved through an understanding of user goals. Understand your users, understand their goals, and you'll construct an interface that gets out of their way.

*"Intuitive" is a word whose incessant use in IT leaves me confused and angry. The word has no meaning because it results in no action. Ask a user "is this intuitive?" and they'll say yes or no, providing absolutely no help and forcing you to ask the better question, like "what about this tool makes it easier or harder to accomplish this task?" "Intuitive" is not a quality of software. It is a buzzword.

Stop thinking strategically

My first day in post-graduate corporate America required a dramatic and unsettling change in my decision making. No longer was it enough to merely accomplish the goal - I had to think "strategically."

My problem with words like "strategic" is that they're rarely used in a way which corresponds to their English definition. I learned quickly that "strategic" meant "in a way that's unlikely to solve our problem but also unlikely to offend executives." And while there are valid reasons to make decisions classified as strategic or tactical, this insistence on being strategic overlooks the obvious: do the right thing.

Many hyper-dysfunctional IT departments become paralyzed by unexplained business decisions made years before. Having endured years of failure as a consequence of shortsighted management and a generally inept staff, they revert to the risk-averse approach of avoiding short-term fixes. Why bother fixing one defect if there are ten more? Wouldn't it make more sense from a strategic standpoint to just refactor the whole thing and fix them all? Let's form a tiger team! We can hire some consultants to introduce a new stack and let the stack fix everything! We won't even need developers because EVERYTHING WILL BE CONFIGURATION!

Meanwhile, the users are sitting around wondering why some critical piece of software has had an obvious bug hampering their work for months, the engineers are shaking their heads, and the corporate overlords are ten minutes from firing their third CIO in two years.

The right decision is to fix problems. Tolerate hacks that improve the user experience . Of course, yes, I understand, individual fixes may often create a hostile user experience in aggregate, and yes, you need to reinforce the need to pay down technical debt or incur an unmanageable tax. Sure, go for the whole-enchilada refactor when you must. But the correct solution to a pressing, time-constrained problem very rarely includes things like tiger teams.

Just like developers who pair program effectively surrender ownership of their code, effective project managers should surrender the desire to put their personal imprint on the project. Commiserate with your users and prioritize accordingly.