Back in February my son lost control of his car and landed in the hospital. Fortunately he has recovered from his injuries. And fortunately we have health insurance. So everything's OK. However I'm still, six months later, trying to untangle the bureaucratic mess that ensued.
There are multiple insurance providers (auto, health) and health-care providers (hospital, clinic) involved in this game. None of them talk to each other directly. They all emit tokens, in the form of images of documents, that the consumer -- me in this case -- has to decode and route.
Recently, for example, I realized that while the bills from the clinic had been routed to the health insurer, the bills from the hospital hadn't. Why not? A token wasn't properly routed. The name of this token is Exhaustion of Benefits. In this scenario, the auto insurer pays for the first round of bills, up to a limit. When that limit is reached the auto insurer sends the insured party an Exhaustion of Benefits letter. It must be routed to all the health-care providers to trigger resubmission of bills to the health insurer.
I brought a copy of the letter to the clinic, and they said they'd forward a copy to the hospital. Apparently that didn't happen. Which was entirely my fault. The clinic isn't the authoritative router in this scenario. It has to be me. So eventually, when I realized what had happened, I sent a copy of the letter directly to the hospital. I think that will resolve the matter.
Meanwhile I pause to imagine an alternative way of doing things that I hope I'll live to see. In this alternate world I'm still the authoritative router. But the tokens aren't just images of documents, they're machine-readable and machine-processable packets of information. And the routing hub isn't a pile of papers on my desk, it's my personal cloud.
When I enter into a business relationship with a provider -- and in this case there are four of them, two insurance providers and two health-care providers -- I authorize them to access my personal cloud. And the authorization is granular. The auto insurer has write access, so it can poke the Exhaustion of Benefits (EOB) token into my cloud data store, but no read access, because it doesn't need that. The hospital and the clinic have read access to just that one document. (Separately they have write access so they can poke bills into my data store.) The hospital and the clinic can also subscribe to notifications, so when the EOB token hits my cloud they know it's there and can access it. Since all access to my cloud is audited, I know when that happens -- or if it doesn't.
Everything related to my son's accident and ongoing recovery is handled in the same way: bills, medical records, appointment calendars. Because my personal cloud receives and relays all this stuff on communication channels that I name and authorize, I'm in a position to do something that would be much harder for the other parties to do. I can organize stuff in a way that makes sense to me. The hospital and the clinic don't know which of the bills they send me relate to the accident. Nor do the auto and health insurers know that about the bills they receive. Nor does the physical therapy appointment desk. And so forth.
One View of the Customer is a laudable business mantra. But a customer often engages with many businesses in the context of what is, from the customer's point of view, one business process. It's a decentralized game with many players, and the only referee is the customer. Only we can create the One View that we need. Today we do it the hard way, using phone calls and faxes and piles of papers on our desks, and we do it poorly. I'm hoping our personal clouds will enable us to do it easily and well.