Wes Rishel

It is likely not a coincidence that David and I independently posted thoughts on the NHIN last night. The ONC has the HIT Policy Committee looking into it and this is generating interest the HIT blogging circles. His post is The Health Internet vs. the NHIN — A Matter of Control, Cost, and Timing and mine is Health 2.0: Take a Lesson From the Web. Subsequently I responded to his and he replied. These are copied at the end of this post. In it he asks whether I agree with him on some points.

First and foremost I believe that when we talk about the “Health Internet” there are two equally important problems to solve:

1. consumer-controlled accumulating and consumer-directed use of health records, and
2. inter-clinician exchange of health records in the course of caring for or managing the care of a patient.

I don’t believe that what has been written about the Health Internet describes a solution that deals with both cases. On the first point, above, I think David and I are in the same ballpark. The model of a PHR proffered by Dossia, Google and Microsoft has many of the fundamentals that are required: a clearly stated privacy model that can serve as the basis for informed decisions whether or not to use the service, access to consumers that is cheaper than Quicken on-line (i.e., free so far), a proactive consumer role in setting and changing consent for various kinds of information exchange, a way of verifying the consent on both sides (the consumer has to be logged into the web sites of both the PHR and the system that sends or receives data) and a rock-solid patient ID mapping (the mapping is created when the patient is logged in).  I would argue that the use of “cloud storage” and good offices of the vendors to facilitate connecting to the PHRs is a valuable and highly desirable.

I have not been able to understand David’s view on point #2. One could read his stuff to say that the Health Internet is all the industry needs. Given the growing presence of the Internet patient-mediated transfers should also be used to get lab results to the ordering physician, ED notes back to the primary care provider, to find out whether a patient presenting at the ED with chest pain has had a recent angiogram and get the results if so and so on through any number of care transitions that we handle very badly now in the health care industry.

There are problems with patient-mediated transfers of information in the course of giving care. Many patients who are fully deft at doing business on the Internet will forget or slow down the process. Some are simply unable to actively mediate information flows. A few patients will knowingly disrupt the flow of information. For example, they may delete reports that suggest that they don’t need high-end analgesics.  Anorexics, who already get more help on the Internet on maintaining their disease then they do on curing it, will also manipulate the information flow. Although these patients may be a minority, the potential for this manipulation will impact the credibility that physicians place on information received through patient-mediated sources.

Labs and other diagnostic facilities have legal and ethical obligations to ascertain that the information has gone to the ordering physician or one designated to receive copies. Information lost in transitions from hospitals to SNFs are a known source of death, and greatly reduced quality of life. I believe that solving the provider-to-provider problem for routine care delivery scenarios is every bit as important as patient engagement, particularly if one expects or hopes to maintain independent physicians as a viable participant in the US healthcare system.

Where we might agree is that the current conception of HIEs joined together in the NHIN has, at best, a very long lead time to create nonpatient-mediated exchange of healthcare information.  It is not that some HIEs haven’t done well or the current NHIN approach can’t link them to one-another and to multi-regional providers. However, it is not clear that this approach can be built out in a reasonable amount of time even with mid-course corrections on the goals and standards in use.

There is an alternative to HIEs and the NHIN we should consider during this period of reexamination of the approach. It might be called The Health Internet for Providers. I don’t see why we can’t be sending information about patients with the same facility that one sends an email. This approach has several advantages

• The consent model can be essentially the same as the consent model that is used to send faxes today.
• Unlike faxes the package that is equivalent to an email can have a variable amount of structured data. In particular
  • enough data to give the receive an easy shot at matching the patient with their data base
  • data about who sent the info and what is the subject
  • more structured data as appropriate to agreements between the sender and receiver. Presumably various incentive programs can improve the amount of structured data over time but the fundamental exchange mechnaism would not be broken.
• It should be straightforward to include in the approach irrefutability of transmission and receipt.

David McCallie has been talking this idea up with me and others and has come to a bright line to identify when a transaction should flow over the “provider health Internet” and when it should flow over the “consumer health Internet,” (i.e., be patient-mediated). If the transfer is one that would be expected now (by fax, letter, CD or whatever) then it should not need patient-mediation to be accomplished. If such transactions are sent electronically now they are usually “pushed.” Any kind of ad hoc searching of patient information (including looking up a critical patient in the ED) should be patient mediated. Perhaps there should be a “break the glass” capability for when the patient is incapacitated and there is no one else to give consent; that’s a fine point.

So I conclude that maybe David K and I agree on some things. At least with his peanut butter and my chocolate we would have a complete candy bar.

What follows is the dialogue from earlier on Wednesday.

Wes:

The statement that the NHIN was “created so that large systems like the VA and the DOD, Kaiser and Geisinger, can exchange data without having to reach the Internet” is blatantly untrue and contrary to everything that the ONC ever published about the NHIN. The NHIN was in fact built to run on the Internet.

Recently five small HIEs (RHIOs) working under the auspices of the California eHealth Collaborative created the ability to share patient data among them over the Internet in a matter of weeks using the NHIN protocols and the open-source code that was created as part of the last NHIN project. The small HIEs which have substantial support for physicians in small practices co-demonstrated with Kaiser. Far from the NHIN being designed to let the big providers ice out small providers it was designed to enable their interaction. In many ways this was a David v. Goliath use of open source software and the NHIN protocols as this the CAeHC is striving to position itself as an alternative to CalRHIO.

There is plenty of room to simplify the NHIN work so far. But we should not conflate the need for healthcare organizations to interact with the very important need for PHRs.

I address this in my recent blog posting “Health 2.0: Take a Lesson From the Web” (http://blogs.gartner.com/wes_rishel/2009/11/18/health-2-0-take-a-lesson-from-the-web/).

David:

Dear Wes: Thanks for your comments, and I stand corrected. In the future I’ll defer to your excellent blog post for a description of NHIN and CONNECT. I also think that the eHealth Collaborative patient data sharing project you refer to is real and substantial progress, and I’m glad that we agree on the point about simplifying NHIN and the protocols involved, so that health care organizations of all sizes can interact with one another and with PHRs.

However, the example of five RHIOs taking “weeks” to “create the ability” to share data, amongst themselves, is exactly the kind of enterprise and provider/organization control of data that Brian and I along with many others consider to be an insufficient solution, one that well describes the old idea of NHIN, but does not describe the new model Health Internet.

Perhaps we agree on this, too. That would be great.

But I want to emphasize that in my opinion patient-centered health data exchange should not require a RHIO or HIE or a formal NHIN. These constructs may be very useful in some ways in some communities, but they are not the same thing as what David McAllie described above, namely a means of exchange over the Internet by which “(T)he data will be available to them (patients/consumers) regardless of where they live or travel. The data will be exposed to services selected by the consumer via standards-based, simple, Internet-friendly (RESTful) protocols, and not via some overly complex service-oriented architecture that presupposes all of the use-cases.”

Believe it or not, this is about the Nationwide Health Information Network (NHIN) and maybe the Health Internet, whatever that turns out to be. But I’ll get back to that.

As discussed in Healthcare 2.0: Better Tweetment? I am on a mission to find concrete value propositions for Health 2.0. By this I mean not the “Wiffle Bat of hope” statements like “the Web changes everything” but the Louisville Slugger statements such as “modified primary care delivery models for self-pay professionals” or “Twittering from the operating room as a marketing tool.” Do I think that the hits that I identify will be the be the game changers? Of course not. Any day, in any park, the home runs may come from any batter.  But if we swing at every pitch, the odds of getting on base go down.

Let’s look at a home run from the Web. Did the Web revolutionize selling airline tickets? Well, for simple round trips and tours to major destinations it surely did. It is a simpler technology than the old one (calling a travel agent), more accessible and disintermediates some of the special knowledge of that agent. For complex itineraries, not so much. My company continues to use a major travel agency, that offers us its own version of Orbitz and offers real live people for the tricky bits.

What’s more, the Web experience didn’t revolutionize the entire travel industry. A great deal of the company to company and company to agency interchange is still enabled by computer-to-computer linkages among business application programs. Granted, the Internet helped with software compatibility but this was less the magic of new ways of dealing with consumers and more industry taking advantage of technologies originally driven by the consumer market.

Put it another way: woe be upon those who fail to aggressively improve their customer relationship through Web 2.0, but even more woe be on to those that think that they will sell boxcar lots of chemicals, oil drilling derricks or electronic subassemblies solely through consumer-friendly Web sites. More complex computer-to-computer interfaces are needed with a higher level of semantic interoperability than can be achieved by a person who is reading information from a screen and typing. Both accuracy and efficiency argue for getting people out of the loop.

We have the same issue with healthcare. We need to service both consumer engagement issues and the industrial-strength connections among healthcare providers, providers and other care delivery organizations. Better consumer engagement can profoundly impact people’s decisions on health maintenance and healthcare options, but the profound impacts depend on more than a social network and a snazzy Web experience. They depend on a long process of learning what actually changes behavior. To think otherwise is to ignore that the public had all the knowledge it needed to quit smoking thirty years ago.

We also need to connect the “industrial” healthcare organizations to those organizations and the agencies that are working to create transparency in quality and cost. Why, because we can avoid killing people in care transition. Every unnecessary death is precious, but talking only about deaths hides an equally important threat. By doing care transitions poorly and using 3 people to bill for every person who provides care we are denying care to many through the rationing that comes by limiting private and government coverage.

This is where the NHIN comes in. In the past it and health information exchanges (HIEs) have been focused on the “industrial” side, that is inter-HCO communications used in the course of giving care. We’ve had our share of Wiffle Bats in HIEs, but the 57 operational HIEs (according to eHI) and a number of self-sustaining HIEs show that it is possible to improve care transitions and even the gathering of quality data. The customer-facing channel (consumer engagement) was previously seen as the province of CDOs and PHRs. HIEs could be an enabler of interchange with the PHR but they were primarily about improving on the fax for gritty, back-room exchange of data.

The NHIN was seen to round off the edges of the HIE concept. It was to cover people who moved, overlapping catchment areas, and the providers and CDOs that operated where a local HIE was unlikely to occur and major organizations like the Veteran’s Health Administration and Kaiser that could not spare the resources to negotiate business and technology agreements with dozens or up to a hundred individual HIEs.

The NHIN also provided a work-around for the basic bug in U.S. healthcare IT: the lack of a singe person identifier.

Currently the NHIN work is on hold for a reevaluation of its direction and proposals abound for a Health Internet. Since the NHIN was designed to work over the Internet, what is different about the Health Internet? Apparently it is more consumer facing.

Consumer facing is good. It will achieve a measure of smarter use of healthcare and perhaps even smarter lifestyle choices. Reevaluation is good. There are plenty of opportunities to simplify the execution of the mission of the NHIN.

What would be bad would be to conflate the consumer-facing aspects of Web 2.0 and the “industrial” interchanges into a single solution that limited the “industrial interactions” to apply to those consumers that have proactively enabled it. We need to recognize that something akin to the HIPAA consent model is needed for some forms of information interchange.

We need to take the full lesson from the Web. It revolutionized consumer-facing business but is only a part of the solution for large-scale inter-business collaboration. We need to keep this distinction in mind during a reexamination of the NHIN. There is plenty of room to find a way to meet the NHIN mission better. The consumer-facing Web changes a lot in very important ways, but if we don’t recognize the rest of what healthcare needs we will face the possibility of reaching the year 2015 with the fax machine still being the primary interoperability technology among physicians and CDOs.

In A Singular Opportunity for Health Interoperability I summarized a metaphor based on the Web standards HTTP and HTML which was “get HL7 and other SDOs out of the HTTP business.”

Metaphors gain their power from poetic ambiguity. One of the great things about a metaphor is that it can rally so many folks to believe they agree. They each read the metaphor as supporting their favorite point. The follow-on to a metaphoric rally must be a drill-down to tease out where the metaphor singles out an important common cause and where it papers over differences.  Using a RESTful approach to interoperability is another metaphor. Some of the discussants take it quite literally as the single most important point to agree on; others see RESTful as an example of a broad approach to rapid innovation.

Over the last few days I have come to believe the following “big takes” on this discussion. In another simplification I break the discussants into two groups,  “the Internet crowd” and “the healthcare informatics crowd.” I mean no disrespect to either group and understand that many people have a foot in both camps or at least a foot in one and a toe in the other.

There are implicitly three levels of contention. I will arbitrarily assign them to a vertical stack.

Bottom: Connecting (in the broadest sense). So much has been accomplished with well-layered Internet protocols to create quite complex behaviors and progress has progressed so rapidly that “the Internet crowd” can’t understand why “the healthcare IT crowd” wants to stick to technologies for secure transport that are “so five years ago” but preclude participating in rapid evolution. “RESTful operations” are a token of the deeper conflict, not the actual point of contention. Some of the informatics crowd significantly confuses the issue by presenting discussions on security based on standardized roles and other as yet unproven constructs.

Top: Semantics of Data. Understanding data clearly is a never-ending task. As Bertrand Russell said “Everything is vague to a degree you do not realize till you have tried to make it precise.” The Internet crowd has done very well with a model where semantics evolve as rapidly with experience. They have productivity tools that rely on some unstated but “common sense” approaches such as using business names as XML element names. The health IT crowd has been through this learning curve on clinical data and wants to skip over many learning steps that uncover ambiguities on health data. However the health IT crowd (including HL7) has made it more difficult to propagate its knowledge about health data because they have chosen to package it in self-created modeling formalisms and XML that is obscure to the max and doesn’t work well with common XML tools. They further complicate the issue by not knowing how to package their sophisticated understanding in a way that it can be understood by programmers who know the data of their own application but don’t comprehend the abstract approach.

Middle: The Semantics of Exchange Sequences. To a certain extent saying something is “architecturally neutral” means “it isn’t interoperable in any architecture.”Any attempt to truly achieve interoperability involves a state machine that implies certain sequences of transactions needed to get the job done.

The Internet crowd is used to improvising the sequences of actions that are required to accomplish a task but not standardizing them. The health IT crowd has attempted to establish very loose architectures (i.e., no technology or system factoring constraints) that standardize the sequences enough that two products that are expected to be interoperable could interoperate without continually adjusting the code based on what is going on in the broader community. Thus the Healthcare IT has fought its way to largely agreeing on XDS over a five year period (and XDS has evolved in that period) and the Internet crowd sees XDS as not applicable to their use cases and restricting their ability to improvise.

The Internet crowd represents a culture that employs the power of the Internet protocols in an enterprising, high-energy, innovative and incremental approach that has revolutionized some industries. The informatics crowd really does have the ability to shortcut many learning cycles based on experience and understanding. How can we introduce combine the peanut butter with the chocolate? Oops! There goes anothe r metaphor.

Sean Nolan of Microsoft just published a finding from the HIT Standards Committee testimony on implementation last Thursday. See his blog item  Hey — was that just an HIT Standards breakthrough? I summarized and perhaps oversimplified an analogy that had built up during multiple conversations by saying healthcare SDOs should “get out of the HTTP business.” The analogy developed from a conversation on the benefits of the Internet suite of protocols by having cleanly separated layers and, in particular, separating specifications on data (such as HTML) from specifications on the communication protocol (such as HTTP, HTTPS, etc.)

A number of healthcare standards and standards-profiling groups have published not only format standards, but also communications standards. Some do not. One of the reasons that HIPAA transactions were largely a failure is that the regulations included no approved method for communicating X12 transactions. Providers must conform to many dozens of different various specifications for the physical transport of data in order to get their bills paid. Alternatively they can pay a substantial click fee to clearinghouses to cater to the communications-spec whims of the payers.

I did not at all mean to suggest that the ONC in its role guiding the implementation of the ARRA should allow the same thing to happen again.

The HTTP Side

To a certain extent the specifications that are most disputed now relate not directly to HL7 standards but to specifications created by Integrating the Healthcare Enterprise (IHE) and adopted by the Health IT Standards Panel. Those poor fellas at IHE started working on an approach to cross-enterprise data sharing in about 2004 and believed IBM and Microsoft that Web Services would be the way to achieve secure, reliable, technology-neutral inter-enterprise interoperability. At the same time they adopted ebXML as a then-proven approach for store-end-forward messaging.  IHE members dumped a ton of sweat into puzzling through the specs, developing selective profiles of them that might actually interoperate, conducting repeated multi-may inter-vendor testing sessions and honing their specifications. Now that they made this investment they are naturally reluctant to give it up. There are actually live implementations now using these protocols, we learned last week.

Oh how times change! During the five years that have passed new entrants such as Google and Amazon have joined the ranks of market-dominating vendors, serious concerns have developed about the complexity of Web services and everybody’s favorite new approach is RESTful Web services‎. This approach is, indeed, simple and layers well. There is a lot of real-world use of RESTful Web services. Security is very simply provided by using the security associated with HTTPS.  Other requirements important to healthcare, such as non-refutability transmission and receipt, can be handled equally well. Probably many of the big firms already are.

In fact, I would venture that each of Amazon, Google, Microsoft and other dominant players each have one or more specs built around the concept of RESTful Web services each of which is simple, particularly because it was catered to the needs of their specific applications. Like providers sending in HIPAA bills, software developers have to develop interfaces that are generally the same but differ in enough specifics that they either align with one vendor or re-develop their interfaces for each.

Is that the best we can do for healthcare interoperability? Somehow I had hoped for more. I don’t really care about RESTful Web services or the other kind. I do care that N x M interoperability work for medium sizes of N and M. For example, if a vendor or care delivery organization (CDO) is developing a clinical solution that needs to interoperate with some other HCOs, labs, multiple PHRs, public health and quality measurement agencies, I would like to believe that they could do so, without getting into a “my business is bigger than yours ” contest. It is clearly not the case that every CDO needs to talk to every other CDO. More and more they will outsource the communications to their vendors, a trend that is underway. So, would each vendor have to be a clearinghouse? Would a new vendor coming into the market face a daunting challenge because it needs to develop a body of intellectual property to communicate with all the labs, PHRs, payers, health agencies and quality measurement organizations, each of which uses a different approach to RESTful Web Services?

Let’s suppose that all the various supporting specs needed for healthcare interoperation already exist in one or the other of the big vendors’ use of RESTful Web services. Is there really a standard for all that that is standard as, say HTTPS or HTML? If so, great let’s go full time ahead. If there is no standard but a lot of good experience, can we somehow put together a tiger team that looks at what’s in use and agrees on a common approach? Such a team would have to follow much of the advice we heard at the HIT SC testimony last week including:

• focus solely on the most immediate needs for fulfilling meaningful use requirements
• focus on reusing what is widely being done across many industries
• spec a little, implement a little, test a little, spec some more until you reach a stopping point
• create open source specs and code that has been tested for interoperability.

The “HTML Side”

There is also work that needs to be done on the side that is the equivalent of HTML in our metaphor. This side includes the specs that represent the payloads communicated through HTTPS for healthcare interoperability. Perhaps the most critical thing is to revisit the specifications to see whether they intermix information needed for the communications with information needed for business processing of the payload. This is a tricky business, because there is overlap. I don’t really know how much IHE and HITSP have already done to create the correct separation. Perhaps it is already done. But if not, could a “tiger team” on the payload side work closely with the communication side to sort out these issues and provide an urgent interface back to the standards bodies if any changes are needed?

Can We Create the Trust to Get This Done?

Like Sean, I see this as an opportunity to get the U.S. healthcare industry to make a leap forward on interoperability that could meet the challenge of the ARRA meaningful use criteria.

For something to come of this, various parties will have to trust a small team to do the work without the formal governance of an SDO. Developers will have to be prepared to accept solutions that require changes to their software. SDOs will have to accept the challenge to change their standards to catch up with the work of the tiger team.

The biggest problem will be antibodies created by the bile and spittle of numerous commenters in this area. Every time an advocate for a more RESTful approach refers to Electronic Health Record Association and IHE as being a cartel working to restrain trade it becomes that much harder to bring the mainstream EHR vendorsto the table. On the other side, HITSP, IHE and others need to do a better job of understanding the advantages of totally separating the two layers and be willing to give some in order to bring in the Health 2.0 crowd.

If this is going to work, all parties are going to have to accept that we need some change and we have a singular opportunity to accomplish it. They are going to have to accept that the parties they disagree with won’t go away. They must refute even their supporters who continue to play the name-calling game.

In the words of comedian Judy Tenuta, “Hey! It could happen!”

This posting was revised on 1 November based on thoughtful feedback from several people.

I just Googled “‘Health Internet’ Aneesh” and found 723 responses. I wonder what the over/under is for 2000 by the end of the month?

Given that the statements from Chopra and Todd Parks have been fairly general, they are treated like ink blots. Each blogger interprets them to find what he loves or hates and writes a brief essay on that. My particular essay will be that I love it and to list the issues that I hope it solves.

In healthcare we have four basic interoperability challenges.

1. Reduce the friction of personal health information flow between the providers in the course of care transitions and between providers and other stakeholders for aggregate management of care.
2. Reduce and increase the friction of personal information flow among healthcare providers, consumers, and a broad class of stakeholders such as patient advocates, providers of special services. We need to reduce the technical barriers to sharing information with consumers and create a positive incentive to do so. At the same time we need to provide consumers with substantial reason to trust that their intentions to limit information sharing are not betrayed. As they trust their control of this health information the increasingly become a force compelling healthcare providers to provide information. In effect the consumers are both the agents of (good) friction and the lubricant.
3. Enable rapid technology innovation without requiring it. Computers are actually doing a lot of good in healthcare now and the challenge that innovators face must include “changing the tires on the moving car,” a sentiment that has often been expressed as “no rip and replace.” This matters particularly when working on the first challenge.
4. Avoid “innovation dead ends” such as the fax machine. It was not so many years ago that the pre-fax epitome of healthcare interoperability was pieces of paper sent through the U.S. Mail. In that context the fax was a wildly disruptive piece of innovation. It needed no new infrastructure outside of an extra phone line, had fewer security vulnerabilities than the mail, was fully upgradeable from paper (as long as you didn’t use color and accepted blotches and pixelation), and no standards were required that hadn’t already been hashed out by the telecomm industry. It was the very strength of the fax machine that has limited our ability to replace it. The comparable challenge in today’s interoperability world do establish standards that are easy enough to enable rapid grown and don’t freeze progress just one step forward.

Some will ask if there is truly a difference between the first two challenges or whether meeting the second challenge wouldn’t also take care of the first. I hope to address that more in a future blog and to present ideas on how we can meet all four of these challenges.

I am enjoying that all-too-brief time between finishing one big project and starting the next. It’s a time to read some emails I might have skipped and even take a minute to ponder them.

One email recommmendedThe Watch for Flu and More. It is a well-written article for the public describing the benefits and challenges of syndromic surveillance for adverse reactions during H1N1 immunization in the U.S. “Harvard Medical School scientists are linking large insurance databases that cover as many as 50 million people with vaccination registries around the country for real-time [emphasis added] checks of whether people see a doctor in the weeks after a flu shot and why.”

This program challenged by three factors.

• The time-lag associated with respect to detecting rare events in a fast-moving vaccination program. I inserted the snarky “emphasis added” to point out that it is difficult to put “real-time” and “billing data” in the same sentence.

• Subject identification. For populations of 50 million, what are the chances in a large program like this that the patient demographic  information will match between insurance and registry data? The good news is that occasional mismatches are tolerable in a statistical study. The bad news is that the goals of the study are to detect relatively infrequent adverse effects,  so the error level will reduce the sensitivity of detection. Perhaps the most important outcome of this study will be determining whether it is possible to detect adverse events this way. If there is an adverse event and it is not detected soon, perhaps ethicists who speak about the balance between protecting privacy and achieving the benefit of healthcare IT will have a real-world example to show the value of a universal healthcare ID.

• Registry compliance. For many patients getting the flu vaccine is a cash transaction. It is hard to imagine that Safeway and the airport immunization clinics are registering all their clients. Where they are registering there is little incentive to collect identifying information as thoroughly as when a bill must be submitted.

Changing the Odds

It is really important that the Harvard study happen. Perchance it will be a major discovery on adverse event detection and registries. More likely it will sharpen the policy discourse on where population studies have value and what can be done to improve their sensitivity. It is unrealistic to depend on the proliferation of EHRs into doctors’ offices to be complete in, say, 10 years. What is the level of proliferation that makes direct transmission of clinical data including immunizatin status a possibility for adverse event detection? Gartner believes that the combinaiton of incentive funds and Stark safe-harbor programs will create a pretty substantial nudge on proliferations. We could see as many as 20% of physicians using EHRs well enough to qualify for “meaningful use” by 2013. If those physicians are collecting immunization status and other indicators for adverse event reporting then the identity correlation would be reduced. If they have true “real-time” feeds of clinical data to massive adverse-event servers then the time-lags could be substantially reduced.

Being able to go beyond detection to associating problems with lot numbers will remain a challenge since patients will frequently get vaccinated through a different provider than the one that they use when symptoms develop.

Thinking in a ten-year timeframe it is also possible to think about policy changes that would motivate better use of data for various kinds of population studies. Perhaps it is possible to require those that adminster vaccines to register patients and submit the info to registries? It probably wouldn’t be cost-effective to pay them to register patients, given the limited value of adverse event detection for vaccines, on the average.

Absent a universal patient ID perhaps it would prove cost effective to pay PHR operators for providing linked up data sent with patient consent. PHR operators would likely use most of that payment to find ways to motivate patients to provide consent and authorize the necessary linkages with their providers. I’d bet these folks, who have a good handle on consumer behavior, could deliver a substantial number of patients for five bucks a head, and bask in the glory of making a proven contribution to population healthcare.  Such a program might be cost effective because the data could be put to many uses.  Like the Harvard study, a demonstration program on this model would yield important findings, succeeding or failing. It would provide some calibration of how much benefit a consumer must receive to share data. If it’s really $5 per person, or anywhere close, that would certainly inform the debate about the relative value that a consumer must receive to overcome privacy concerns.

Finally, simply requiring all health plans to play for all immunizations would create a data stream correlated on patient ID for analysis.

When it comes to achieving population-based value from clinical data, the hell of it is that we are required to accomplish this without a universal patient id. The good thing is that we are following Winston Churchill’s maxim, “when you are going through hell, keep going.” This Harvard study puts us one step forward.

Joe Heyman wrote a response to Practical Concerns re: Certification Recommendation that raised some important points. A dialogue between us may further illuminate the points.

I don’t know if Joe meant to imply that I am advocating CCHIT as the sole certifier, but let’s be clear up front that I am not. My concern is with the provision of the recommendation that implies that only the vendor gets to choose which certifying agency they use.

On to specifics. Joe writes:

In Practical Concerns re: Certification Recommendation I drew from the experience with CCHIT to identify issues that must be dealt with in certifying EHRs for various programs created under the ARRA. I further suggested that these issues are compounded by the “waterfall” process recommended by the HIT Policy Committee, wherein one organization (ONC) determines certification criteria and other organizations actually implement certification programs.

I immediately received an e-mail response suggesting that the waterfall approach is mandated by the HITECH portion of ARRA. Specifically at Section 13101 it amends The Public Health Service Act to add Sec 3004 giving the process for adoption of endorsed recommendations; adoption of initial set of standards, implementation specifications, and certification criteria.

While only lawyers can interpret legalese, as a layman it seems pretty clear that 13101 dictates a process wherein the HIT Standards Committee ends up enumerating specific requirements for certification. This only slightly changes what I wrote however. ONC must recognize that it has only two choices for certification:

• Be precise and uniform not only on what is certified but also how, or
• Expect that multiple certifiers will be driven by market forces to “race to the bottom,” giving the most benefit of the doubt to vendors they can get away with.

If it chooses the former, it should determine what level of support the HIT Standards Committee needs to work out the details on how. I would urge it to look at the CCHIT experience for at least one working methodology and resource estimate.

Alternatively, I have not actually found language in the HITECH act that requires multiple certifiers. That seems to be a recommendation of the HIT Policy Committee. The ONC should at least consider whether the heavyweight approach used for ISO 9001 and the like is really required.

On 16 July the Certification and Adoption Workgroup (CAWG) of the U.S. HIT Policy Committee provided its recommendation to the full committee.  It calls for a 3-level approach to certification. There will be an opportunity to comment and I hope that readers of this blog will consider the thoughts here and then comment as they see fit. (Please see a subsequent clarification based on early feedback from blog readers at More on The EHR 3-Level Certification Approach.)

The current recommendation is

1. ONC itself determine criteria for certification
2. ONC identify an organization to accredit various certifying organizations
3. As many organizations as feel there is a business in doing so become accredited and begin certification.

A corollary recommendation is that vendors should only need to be certified by one organization.This implies that all Federal programs and regulations that require certification would accept certification from any accredited organization. The main focus right now is the incentive payments but one must presume it applies equally to grant programs that provide assistance in implementing EHRs. Since Federal money contributes to many state programs they would also be bound, it seems. The bottom line is that vendors and CDOs that want to qualify with self-developed EHRs would each be free to pick one accredited certifier. The entities that are relying on certification to determine whether to give funds would not be able to say that “we feel that Sleaze Bag Certifiers, Inc.” is mainly in the business of helping vendors find loopholes and “Upright Certifiers, Inc” is diligently applying the criteria in a way that ensures we know what we are getting. They would have to accept certs from SBCI and UCI indiscriminately.  When the choice of certifiers is made only the vendor, not the organization that relies on the certificate, this creates an inevitable pressure to be the certifying organization that is the least thorough in its process.

At worst this guts the idea of certification. At best it creates a requirement that ONC construct a set of requirements for the accrediting organization that assures it not only pre-qualifies certifying organizations but also monitors their actions and provides a dispute mechanism for those that feel that a given certifier is too lax or too strict.

There have been those lobbying against the Bush-administration approach, which was embodied in CCHIT. Whatever the merits of the argument, it seems unlikely that a government agency can promote the notion of industry self-regulation given what has been learned from the financial services industry in the last year. Therefore, CCHIT has a very steep hill to climb if it to retain its status as the public consensus body for determining requirements.

Even so, there is a lot of valuable experience that can inform the specific adoption of the CAWG recommendations. I have worked at all three levels of the CCHIT workgroup, commissioner, and trustee. In my day job I am continually evaluating vendors and vendor claims, sorting out the information from the noise, at a company that became a billion-dollar company because users trusted our advice on vendors. Therefore I put myself forward as someone who has a good understanding of the process and a balanced view of vendors, neither demonizing nor glorifying them. I hope you will consider the material below in that light as you make your own decisions on commenting.

Questions to Consider

I have organized this into questions to consider and thoughts that might help. As always comments in the form of additional questions and further considerations are very, very welcome.

Why do we need certification at all, since we now have meaningful use criteria? In other words why not let physicians and small hospitals buy whatever product or build and assemble whatever combination of open-source code, commercial products and home-brew that makes sense. Either they qualify for meaningful use or they fail. They can reply on their trade associations and organizations that survey satisfied customers to give them guidance on what to choose.

The short answer is that the law requires certification for several big programs. The equivalent question in this context is should ONC minimize  the certification requirements and rely primarily on meaningful use going forward?This gives the marketplace the most opportunity to respond innovatively to the meaningful use measures, in other words to achieve the “outcome” rather than follow a prescribed approach.

This is a very attractive proposition. But it does mean that a practice or hospital buying a product now (and let’s face it, most of them will buy products rather than build) must correctly judge whether it does or will grow to meet the evolving meaningful use requirements in 2015. Customer surveys, whether commercial or conducted by specialist associations, primarily ask the question “are you satisfied with your product and the vendor that sold it?” They will no doubt have collected and published great data by 2016 on the ability to mean the 2015 meaningful use requirements, but they aren’t that much help to a CDO making a purchase decision in 2011 or 2013. This element of risk will contribute to a trend to defer purchases, even at the cost of giving up some incentive funds.

Is it possible to certify products to give solid buying advice to physicians? After all, CCHIT has failed to set advanced criteria for aiding the cognition of physicians, evaluate the quality and safety of user interfaces, or to evaluate the fiscal stability of vendors.

When CCHIT started there were about 200 EMR products that could be identified by scanning the Web, ads in trade magazines, etc. Currently about 80 of them are certified. To me this indicates that CCHIT has done a good job of finding the middle course between setting criteria that physicians won’t buy or can’t implement and being completely laissez faire. For example, all the so-called EMRs that were primarily systems for storing and retrieving scanned documents have either modernized or failed to be certified. Systems that only accept medication orders as text have similarly had to evolve. Systems that cannot record problems and allergies, and use med allergies in med orders have been eliminated.

No certifying organization can assess all the criteria that go into choosing a product.  For example:

• Financial Viability. There are difficult issues in certifying financial viability, since almost no startup looks viable by any objective measure- or at least most people don’t think that startups should have to be sufficiently capitalized to look viable. CCHIT made a compromise: it allowed firms to provide some basic information about the size of their customer base and made it apparent when this information was not provided. Furthermore, it followed up with vendors that had qualified about every 90 days to see if they were still in business and answering their phone.  Would this be adequate, insufficient or overkill in the future? That would be up to ONC to decide in setting criteria.
•  Quality and Safety. The quality and safety of user interfaces is subjective. Arguably one could establish some objective measures of what makes a “bad” or “unsafe” UI, but this would be incomplete and the converse of these measures would not define a “good” or “safe” UI. The experience building consensus on clinical measures has shown that even when the conceptual ideas can be easily accepted, nailing them down to the point of being objectively measured in real-world systems is a long process. It would be a substantial value if ONC were to start the long-term process now of building consensus on objectively measurable system characteristics that are unsafe. Perhaps it should kick this off with the Institute of Medicine. It seems unlikely that the consensus could be developed and reduced to practice in certification much before the 2013 round of criteria.
• Cognitive Assistance.Advanced clinical support and point-of-care access to medical knowledge is an area where CCHIT has been criticized for being too strict and not strict enough. Vendors are often accused of watering this down because they can’t do it or beefing it up to try to restrict new entrances in the market. Having seen this debate in CCHIT I can say that the vendors tended to work to keep criteria matched with what they thought physicians would be willing to pay for. The pressure to raise criteria came from other stakeholders with righteous concern about safely and quality, hoping to use certification as a way to force physicians to practice better medicine. This is an area where any certification program should be closely tied to meaningful use criteria or other elements of healthcare reform. It is unlikely that the majority of physicians will accept these features unless they see near-term, highly credible pain if they don’t.

Should the accrediting organization evaluate howa certifier determines compliance or only whether it does? This 3-level approach is straight out of the playbook of ISO 9000, the capability and maturity model and the Common Criteria for security. It will be interesting to see what happens there. I am going to guess, however, that it is impractical to determine in advance whether a candidate certifying organization can be effective without reviewing its methods. 

In adopting the 3-level approach there are three strategic approaches. ONC can (1) leave the determination of methodology to each separate certification organizations; (2) strike out to establish a brand new approach to certification to be applied uniformly by all certifications; or (3) adapt the approach used by CCHIT for use by all certification organizations.

As discussed above, the 3-level approach will create market forces driving certification organizations to be the least intrusive on vendors. Arguably this means that the first approach, leaving the certification process to the certifying organizations, is equivalent to reducing the impact of certification to the legal minimum, and relying almost entirely on meaningful use.

The second and third approaches, ignoring the CCHIT approach or adopting it, represent the endpoints of a spectrum of approaches. Intermediate points on the spectrum arise based on how much attention is given to CCHIT experience. I strongly advocate paying close attention to the CCHIT experience with regard to certification because it achieved several important balances:

• Criterion objectivity. Several rounds of certification have led CCHIT to a set of criteria that can be rated by judges with good inter-rater reliability. This is a value that the accrediting organization should consider in evaluating the methodology of organizations.
• Criterion testability. The devil is really in the details in objectively testing functionality. This will be the biggest challenge for the 3-level approach, because it involves a give and take between the determination of criteria, the testing approach and the test scripts. In adopting the three-level approach the ONC should not consider how the HIT Standards Committee, or whoever else determines testing criteria should be able to participate on a quick-response basis as the certifying scripts that support a criterion are developed and executed. CCHIT also used a “beta certification.” Vendors could participate without charge and without their names being released to the pubic. This allowed the final scripts to be tuned up by experience before being put into play.
• Certification costs.CCHIT adopted a budget of only testing as much as can be evaluated in a single day of testing (for ambulatory EHRs). This involves complex trade-offs between the selection of criteria and the methods of certification. It will also be more complicated in the 3-step approach.

Should the ONC reconsider the 3-level approach? I perceive that CCHIT actually achieved a balance between three different groups of stakeholders, those that must build to the requirements and sell that product to CDOs and physicians; the purchasers of products who are primarily focused on the short-term impacts directly oh themselves; and other stakeholders that want to ensure that funding EHRs leads to better and less expensive care. The closer observers were to seeing the process the more they will agree with me. However not everyone shares that view. I would urge those who write comments to consider this issue on their own, keeping in mind that if the outcome of establishing criteria is truly balanced, nobody will like all of it.

I would further argue that CCHIT met unbelievable deadlines, launching itself in a year and going through annual updates to its criteria.

Because of the current general public concern about industry self-regulation I doubt that the current governance of CCHIT will be acceptable. A separate question is whether the full bureaucracy of the 3-level process is needed,given the issues discussed above. I strongly suggest that commenters give consideration to whether a group such as CCHIT with a different approach to governance wouldn’t a better approach. Commenters might want to give some thought to how a governance approach can avoid the problems to the usual government “waterfall” process where requirements are developed by one entity and then become sacrosanct to the entities that need to figure out how to make them work in certification. (My clarification at More on The EHR 3-Level Certification Approach is particularly relevant to this section.)

Negative articles continue to appear implying that incentives in the Stimulus to roll out EHR will lead to a disastrous failure. Here we want to note that there are numerous examples of successful deployment in EHRs and to identify some of the ingredients of those successes.

EHRs today are far from highly-tuned instruments anticipating and meeting the doctors’ requirements. But recent articles seem to imply that the current round of products are a sham foisted off on physicians by a cartel of powerful vendors manipulating government standards. We need to make it clear that EHRs are being successfully deployed in many situations and understand the reasons for success.

In research for some upcoming Gartner publications I have looked at five instances where organizations have assisted in selecting and implementing EHRs mostly in small practices. (These are of course all pre-Stimulus activities.) They include: HealthBridge in Cincinnati, Hoag Memorial Hospital Presbyterian in Newport Beach, California, The Massachusetts eHealth Collaborative, MedAllies in the Hudson Valley of New York State, and the New York City Department of Health and Hygiene.

These successful efforts have at least two common facets: they all started with health information exchange or included HIE in the initial plans and they all controlled, supplemented or replaced the vendor implementation and support with approaches that are more highly directive and more keyed to supporting the practices complete the workflow changes necessary to benefit from the EHR.

As I was conducting these interviews, A. John Blair, III, MD, the CEO of MedAllies, offered to contribute to my blog, giving a brief summary of the successes there. This paragraph is verbatim from John:

After two years of ambulatory EHR implementations in New York’s Hudson Valley, we have found that practices of all sizes can implement today’s full EHRs.  Not all currently certified ambulatory systems are suitable for very small physician practices, but several systems work well in small offices.  The critical factor for success is the initial implementation effort and ongoing support, which includes extended implementation and monitoring of system usage.  Our routine implementation includes continuous monitoring for comprehensive and high eRx usage.  We work actively with Surescripts to monitor all aspects of eRx.  We strive to go live with bi-directional lab interfaces.  Also, we configure  the systems and train on reporting from the beginning.  We ensure that providers are facile with the software before going live so they are documenting at the point of care at day one of go live.  We have a comprehensive chart abstraction program to move fully from paper.  We monitor adherence to CDS after implementation.  We are currently working with 13 practices at over 70 sites to achieve NCQA advanced medical home.  All groups have chosen three chronic diseases and are fully using the EHR registry functions.  Our current install base includes:  Solo practices-24, 2-5-12, 6-25-2, 26-100-3.  We have yet to de-install a system.

No one would claim that the products these implementors are supporting are ideal or that every product will work for every practice. Far from it. In fact, healthcare reform and EHR products will, of necessity, co-evolve. As we look for the evolutionary starting point for health IT + healthcare reform, it is reasonable to ask if we want to start with protozoa or salamanders. In examining the question, the fact that we know how to make that today’s salamanders work for physicians should not be ignored.