Nat'l Health IT Week from DC

I'm here at the National Health IT Collaborative for the Underserved in Washington today. The meetings are lasting all day, and I am a member of the Policy workgroup. Members of the workgroup come from a variety of places; provider networks in Californiaand Michigan, Morehouse, The Office of Minority Health and Capitol Hill. Much of this morning's discussion was about ARRA funds and how the remote, rural and underserved community providers would access those funds.

Those at the table from the Hill were pretty energetic about the ARRA funding allocations to regional health networks. They feel that the RFPs have been written to such a tight profile as to be "self selecting." It is already known which big players in health management will qualify. There are now discussions in California to enable access to these funds through "subcontracting" to local networks. There is a requirement that for a Regional network to qualify, it must have a minimum of 100,000 people. By aggregating these "local"'s numbers, the big players can then have the qualifying numbers, and the local clinics can access funding.

There was also a strong sentiment about bringing the smaller, rural/remote providers together to examine their HIT wants and needs. By documenting this aggregate market, vendors can be educated to develop and deliver more integrated and interoperable technologies---This is very reminiscent of last week's article on the Canadian market. MORE ON THAT LATER.....

The Seven Myths of Healthcare Technology6. Health IT is just a product

And as a product, it is subject to the same market drivers and business strategies as any other commodity.

This was the point of a rather difficult conversation I had the other day with a very smart, very senior business-management consultant at a major firm. I had asked his thoughts on cross-border IT and the difference in implementation costs between the States and Canada. I brought up the idea of the cultural differences and the market limitations these impose on vendors. I posited that there might be value to both customers and vendors alike in having some sort of "cultural/market versioning support." He did not think so. Smart software developers, according to my friend, only deliver one version of their products for the largest single market or buyer. These "large-target" versions are sold across the board and the additional customization and implementation costs are passed down to the smaller buyers and the smaller markets. The Canadian market is much smaller than the US.

And while the number of people in Canada is one-tenth that in the US, the market for HIT is even smaller. After all, my friend noted, because of National Health, there are only a few buyers--the Provincial and regional health authorities; So, maybe 6 in all of BC? One in Alberta? Who would build a special version for only a few dozen customers when there is the US market with hundreds of facilities?

Now, this friend of mine is very smart, and he has been very generous with his insight and time. But on this I am not sure I can agree. Yes, in business, as in the US, healthcare is a commodity. The Cato Institute just said so in US News and World Reports. In Canada, however, this is not the case. Healthcare here is a community responsibility (and the best thing the government has ever done, according to some surveys. As a community, the Canadian HIT market population (providers) is about 8% the size of that in the US--about the size of California, and no developer is writing off the Gold Rush State. Healthcare providers are also different from consumers of other softwares. They are not shopping for something to give them an "edge" over their competitors. Healthcare providers, including the technologists, are always aware that their work is about someone's life--someone in their community. This very non-business value structure makes them companions, not competitors. As companions, they can work together to pressure US vendors to fulfill requirements of the Canadian market (as is already done for bilingual functionality).

As to there being so few buyers, shouldn't that be a good thing? HIT software is usually licensed by the number of users, not the number of contracts. So shouldn't managing a few large sales be better than making and managing a lot of small ones? Imagine selling to all of California with only 50 sales, instead 1050.

Maybe US software companies just have trouble understanding the Canadian customer. Perhaps Canadians have trouble communicating their values to American vendors successfully. The culture gap is certainly wider than people might think, and it appears in the most unexpected places.

What are your thoughts? Is Canada big enough to get more "ready-to-use" software? Are developers only successful if they follow a Keynesian model? Is healthcare just a commodity? And is HIT just a product like any other?

I grew up in one country and have lived and worked in both the US and Canada. But this is a real puzzle to me--and to many people I speak with every day. So let me know your thoughts. Maybe my friend is right.....

The Seven Myths of Healthcare Technology5. One Size Fits All

August is over, and so is, sadly, vacation. So, we came back to the office this week, to a pile of mail (I see that Canadian Tire had some nice sales in August) and a week of "start-up" appointments. One was a discussion with a partner company in Toronto. They are in marketing and were contacted by a potential client about an EMR/management system for small-office providers. As an SME, I was brought in to provide support. It sounded like a well-thought-out product serving a clear need. However, as we talked, I recognized a flaw in the initial assumptions;

Myth #5 "Solutions Are Shippable."

The potential client, a software vendor, was thinking of establishing a client base in Ontario and then expanding through Canada and the US--a reasonable and not uncommon business-development route for most products. Vendors and buyers of look on both sides of the border for new clients and better deals, respectively. This works with auto parts, fruit juice and so many other things--especially after NAFTA. And one would assume it would work with HIT as well--and be wrong.

Healthcare IT is only a device to enable a service process. It does not actually deliver healthcare. It just helps keep track of the healthcare being delivered. And that process is not the same everywhere. In Canada, the first goal of record keeping is accuracy of health data and surety of care. In the US, the first task is bookkeeping--determining payment liability and authority. In the US, there are HIPPA regulations carefully restricting access to patient information. These regulations are much more stringent and litigious than those in Canada, where a "circle of care" is more readily extended to include those brought into a patient's care process. These things change the nature of how electronic-record software should be not only managed and used, but actually structured.

In the US, software has be made to accommodate the tangled web of insurers and pre-authorizations required. Before care other than emergency stabilization can begin, financial responsibility and authorization have to be obtained from any one of a myriad of people and documented. Following that, HIPPA practices (coupled with litigation-risk management practices) require careful and full documentation of patient information and consent. Security functions (ID/password systems and access logging and monitoring) are required to assure HIPPA adherence by providers and facility staff. Then each service, each supply and each provider interaction has to be documented in a way that can later be billed successfully to whichever insurance company, HMO, employer fund or government plan may apply. This is often a complicated mix of incremental payments from a number. There often is still a significant balance to be charged the patient (or their family) which may require financing (and the related software functionality). Healthcare software must handle all of these requirements as core elements. This directs a large part of initial development to service coding, annotation of coding, coding-decision support and back-office interfaces and resources (billing office dataset displays and telecommunications with insurance company databases, for example). And these are core requirements for providers in the US.

In Canada, financial issues are far less complicated; a patient is either Canadian or not (or, in rare cases, not up to date on their Provincial premiums). This immediately clears authorization and billing for the majority of primary care services (more than 90% of all healthcare). For "non-urgent" care; optical and dental, elective services or "extras" like private rooms; billing is to one of the fewer-than-in-the-US insurance companies or to the patient. But the billing process is not a primary function in the electronic record. The "Circle of Care" allows easier involvement of providers and requires less documentation of patient information and consent. While patient privacy and security are highly valued in the Canadian practice, the limitations on provider liability in Canada reduce the urgency for liability-risk mitigation through documentation and security processes. Similarly, coding of diagnoses, treatments and prescriptions are important in the Canadian system, but for different reasons. While the US providers are working to ensure that they get paid, the Canadian providers are more concerned with helping organizations like CIHI in the development of trending data and national care standards (as examples).

Clerks in the US ask "Who's paying?" In Canada, they ask, "What's wrong?"

Software is a device to enable a process. While the goal may be the same everywhere, the process is not. And the software cannot.