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.

So Happy Together......

It was just announced that the Provinces of British Columbia and Alberta have come to an agreement to coordinate their medical supply purchases. Sort of a "Coastal Costco" for the provinces. To work around the provincialization of healthcare in Canada, they created a third-party entity to negotiate volume discounts for the two provinces.

When might the other provinces join in? And why not have the Federal government sponsor such a thing? The clear follow through is lower prices for everyone, but there would be another upside; consistency and continuity of the care experience.

If most supplies and physical resources are the same across the nation, then their management practices would be the same as well. A nurse who moves from Nova Scotia to Ontario would have a much shorter learning curve in getting acclimated a new facility. And a patient really would know what to expect--wherever they are. This would by itself reduce the costs of both "onboarding time" for staff and "patient orientation."

Would this be a good lead to follow for technology? Well, a little over two years ago, the BC Ministry of Health certainly thought so. The Ministry directed the regional health authorities to work together to figure out a unified EMR approach. Coastal (Central Vancouver) and VIHA (Vancouver Island) began working on a joint agreement to use PARIS, a software system already being used at Coastal. As part of this discussion, the issue of "bulk buying" was raised. In early analysis of existing contracts and the license extensions, huge potential savings were identified in the simple elimination of buying and customizing a new software installation. How much could be saved if The Nation were to buy the same software everywhere?

A single system has been done successfully. The United States Department of Defense uses one system, AHLTA for all of the millions of people they serve. Was it easy to do? Not at all (DISCLAIMER: I worked on the AHLTA deployment a number of years ago, when it was still called CHSII). Delays came from the bottleneck created by using a single, new vendor and from doing what had never been done before. The first two deployment efforts were cut short by the refusal of the end-users to implement software that was still, really, only in Beta. Often, new things can only be learned by trying and failing. Once the software was sufficiently developed to work, user adoption was generally successful.

Now, patient records are available wherever the patient goes, not wherever the patient carries them. Prescriptions, drug allergies, provider notes--all are available and accurate. Patient misidentification is fast becoming a bad memory as electronic orders track to accurate patient identification. Are there savings? Certainly of lives, time, and yes, money. (I leave the question of whether healthcare should be about money to Bill Maher's blog.) A full audit of the savings cannot be done yet, but it is looking awfully good.

What is already known is the new mobility of both staff and patients. The orientation period is vastly reduced, and the very necessary and long-overdue ability of staff to "parachute in" to a new facility is greatly increased.

Single-system, bulk buying--call it what you will, but perhaps these examples from both sides of the border might lead CIHI and HITSP to work together towards one cross-border standard. It might enable competition in that larger market, leading to lower prices and ease of use.....one never knows, do one?

"Meaningful Use:" Meaningful to Whom?

In the States, ARRA has authorized funds to assist organizations implementing EHRs. ARRA requires "Meaningful use." The healthcare Information technology Standards Panel (HITSP) has just defined seven core types of data exchange; prescriptions, lab results, clinical data summaries, biosurveillance data, immunization registries, public health and quality measurement. [Full article here] Clearly a committee was involved--certainly prescription data, clinical summaries and labs would enable healthcare while reducing potential misidentification issues.

But what do immunization registries do for patients or providers? public health data? And biosurveillance is about accessing multiple data sources to identify trends or potential outbreaks; so that means making the electronic record readable for "phishing," not improving the care of the patient. Is that wrong?

The American Health Information Management Association (AHIMA) commented to The National Committee on Vital and Health Statistics on this (April 2009, AHIMA), and had some very interesting points. Sandra Fuller delivered a very thorough discussion of both the product and the process to arrive at "meaningful use." AHIMA felt that public funding should be used to drive improved care as well as the public interest.

To improve care, they spoke of prescriptions, labs and results and discharge data. These are all considered core elements of care-information communication and patient transfer (provider to technician, provider to pharmacist, provider to provider) and areas of greatest risk of error.

The report looked beyond the patient--to both public-health policy and to patient-care policy. To serve public health interests (and after all, this is being publicly funded), AHIMA recommends investment in development of improved reporting methods and systems with coordination through the HIEs being developed (and funded) with other ARRA resources. But, at the end, AHIMA circled back to the patient;

Be relevant to consumers: Taxpayers are funding these investments as a prerequisite to effective health reform. More broadly, this is an extraordinary opportunity to be transparent and to increase public recognition of the challenge and opportunity of an interconnected health system and the progress that is being made.

All in all, a very interesting and valuable report--check it out

Well, the committee got to it and politics seems to have moved things to the, if you will, "right." Immunization records should certainly be part of the patient record, but is it really a priority element for standardization? Discharge summaries fell out, but biosurveillance got in. Should readability by outside agencies be a "core element" of meaningful use? If an EHR is about communicating patient data (and it is usually thought of as an active process, not a passive one), then is anxiety overwhelming the mission? Or is this use of "surveillance" simply a way to get Homeland Security behind the drive for a national standards for data formatting and encoding? After all, the multiple-vendor system has led to a wide variety of proprietary methods that inhibit data communication and portability. And are we still in the times of driving by fear? Thoughts?