Wes Rishel

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.

I enjoyed Carleen Hawn’s Take Two Aspirin And Tweet Me In The Morning: How Twitter, Facebook, And Other Social Media Are Reshaping Health Care. Not the typical “wall of evidence” from Health Affairs, but numerous well-chosen and credible anecdotes. These make a credible case for at least two advantages for e-enabled healthcare

• social network software as prolonged, nearly continuous “group therapy” for patients with chronic-diseases that are mitigated by maintaining good choices in daily life
• scenarios in which patients benefit from more spontaneous or ad hoc connections to on-call physicians chosen by their availability rather than their prior continuity with the patient. (Two examples described are Hello Health.com and the contract between American Well and the Hawaii Medical Service Association for “on-line house calls.”)

The article did not adopt the “ohmigod, this changes everything” attitude of most of what is written about Health 2.0, which is why I found it more tolerable and less, well, stupid.

Still, I wish that Hawn had done a better job of positioning these anecdotes against the complex matrix of healthcare delivery. The lead anecdote was about an executive that chose Hello Health’s fixed fees per visit in lieu of health insurance. Should she have mentioned that he apparently gave up insurance for major health events in the bargain? Does the Hello Health approach discourage health screening?

Although she mentioned standards of care for e-visits, she basically treated the issue as a licensure problem and a need for “an entirely new regulatory structure.” To its credit American Well addresses the issue forthrightly on its Web site and points the surfer to efforts that are attempting to resolve the issue of standards of care for eVisits within a time frame that the company needs if it is to succeed.

On thr plus side, Hawn did pick examples where Health 2.0 was extending the role of caregivers in fairly well-understood healthcare processes. ATMs didn’t fundamentally change banking, although it did cherrypick high-volume, simple transactions and greatly improve the user experience for them. Orbitz and the like allowed consumers access to knowledge that was previously locked up in the travel agent’s computers, and made simple reservations self-service. But try booking an eight-day, five-country trip that way. Business travel agents use self-booking like banks use the ATM, to handle the simple transactions 24 hours a day without waiting to talk to a travel agent. But they continue to offer the other values they have always offered, complex travel arrangements, the creation of special value by special deals with travel suppliers and enforcement of company travel policies.

Some healthcare transactions are high-volume, relatively simple and can be handled by some consumers with normal intelligence and increased access to knowledge and information on line. It is up to the entrepeneurs to identify those and find ways to offer them to appropriate consumers within the context of overall healthcare.

Looking at it this way, it is hard not to get excited about Health 2.0

In Hey, Washington Post, Wake Up! I mentioned several well-reasoned, informed replies to the recent Washington Post note decrying EHRs. I don’t begrudge the Post its need to publish material that grabs attention and runs counter to the thinking of the Administration. I do fault it for ignoring informed responses. I therefore asked the authors to let me publish their letters in my blog so they would at least be on the Internet.

Another thoughful letter directly from the Washington, DC area. Peter Basch, MD, FACP, is an internist in DC is an early adopter of electronic health records and ePrescribing.  He is has a wealth of experience in this area. Peter

• is the Medical Director for Ambulatory Clinical Systems at MedStar Health, an eight hospital not-for-profit health system in the region where he provides clinical leadership for the MedStar ambulatory EHR implementation. 
• served as the chairman of the recently concluded Maryland Task Force on EHRs.  
• is a board member of the eHealth Initiative
• is a member of the American College of Physicians’ Medical Informatics Subcommittee and also represents the ACP at the Physicians’ EHR Coalition, serving as a member of its Executive Committee. 
• received the HIMSS Physician IT Leadership Award for 2007.

Here is his letter to the Post.

As a practicing physician and early adopter of electronic health records (EHRs), I appreciate the cautionary statements made by Drs. Soumerai and Majumdar (“Bad Bet on Medical Records,” Tuesday, March 17th, 2009: A15) regarding the potential for harm from poor health IT implementations.  That is why health IT projects must be carefully planned and implemented; paying close attention to existing and new processes of care, as well as being vigilant for unintended consequences.  That said, Drs. Soumerai and Majumdar incorrectly conclude that now is not the time for the Obama administration to invest in health IT.  Their conclusions are based on a combination of outdated studies, and a misinterpretation of several current ones.

First of all, health IT is a very rapidly evolving field – and conclusions drawn from studies that are more than a few years old are really not germane today.  Specifically, outside of a few select institutions, the typical EHR of the early to mid part of this decade did not have the advanced features (clinical decision support) necessary to improve quality to a significant degree.  It should thus surprise no one that studies conducted during that period of time failed to show significant quality improvement. 

And more importantly, even where such features existed, they were almost certainly not fully used, causing some to incorrectly interpret that EHRs are not capable of enabling quality improvement.  The fault here is not with the health IT, but rather with how doctors are paid for their work.  Currently, physicians are paid for doing and not thinking, and volume of services rather than quality.  It is not surprising then that studies of EHRs used in these volume-driven settings of care tend to show a lack of significant public good; and studies conducted in settings where physicians are compensated for health information management and quality outcomes (such as community health centers) show just the opposite.  The key then to seeing consistent improvement in care is not to treat health IT as an end to itself, but rather as a supporting component to care delivery innovation.

Aside from enabling better quality, there are other tangible benefits to EHRs and health IT.  In our practices, for example, all prescriptions and renewals are always checked for drug-drug and drug-allergy interactions, and where possible, are sent electronically to drug stores.   Handouts are easily created for patients; containing instructions, lab orders, and a legible and easily understandable medication list.  Most of our patients feel that their care is better and safer, because of the EHR.

And while good EHRs are already on a trajectory to get better, the stimulus bill will hasten this improvement, as it targets the majority of its dollars not on health IT adoption, but on how health IT is used to make care better.  This is both the right time and the right way to help transition our health care into the 21st century.  This is not a bet on EHRs; this is money wisely invested in our future.  

The recent Wall Street Journal and Washington Post pieces critical of stimulating adoption of EHRs are a grand example of the slide to the Trough of Disillusionment in the Gartner Hype Cycle. After being overly high on a new concept the press goes negative, focusing on the early failures rather than early successes.

We know of at least four experience- and evidence-laden response letters to the Washington Post that have languished unpublished. These responses point out the selective nature of citations by Groopman and Hartzband.  We expect better from the Post than to ignore these credible letters. With permission of some of the authors I am publishing their responses as guest pieces in my blog.

William Hersh, M.D. is Professor and Chair of the Department of Medical Informatics & Clinical Epidemiology in the School of Medicine at Oregon Health & Science University (OHSU) in Portland, Oregon, USA. Bill is a leader in informatics and informatics education. He created the first offering of the AMIA 10×10 program, which aims to educate 10,000 health care professionals and others in medical informatics by the year 2010. I thank him for his permission to include his letter here.

Dear Editor,

While Drs. Soumerai and Majumdar are reasonable to question whether President Obama’s investment in health information technology (IT) will meet its goals, they could at least present a more complete view of the research and the science behind health IT and its use for computerized physician order entry (CPOE) with decision support.

It is true that the studies they cite by Han et al. (Pediatrics) and Koppel et al. (JAMA) showed poor outcomes and new forms of error introduction respectively. However, when we look at the whole body of research surrounding these studies, different conclusions emerge.

The Han et al. study looked at overall mortality before and after the introduction of CPOE in the Pediatric Intensive Care Unit of Children’s Hospital of Pittsburgh. Aside from the known limitations of before and after study (i.e., you cannot control for confounding variables, such as the decision to centralize the pharmacy that was made concomitantly at this hospital), analysis by other researchers in the similar pediatric intensive care settings of other hospitals did not find increased mortality after introduction of CPOE (DelBeccaro, Jacobs). Furthermore, postmortem analyses raised significant concerns that the implementation at Children’s Hospital of Pittsburgh ignored several known best practices associated with CPOE implementation (Phibbs, Sittig).

Likewise, the study by Koppel et al. from University of Pennsylvania was very important in identifying new potential errors that could be introduced through CPOE. However, as pointed out by another well-known CPOE researcher (Bates), the Koppel et al. study did not quantify these errors, nor compare their frequency to errors resulting in adverse outcomes for patients. Bates (NEJM) and others have shown in several studies that CPOE does reduce adverse events, even if the systems used are “home grown” and not as generalizable to the rest of the world as we might like.

Finally, the writers completely ignored a new study published recently in Archives of Internal Medicine that assessed 41 Texas hospitals and found use of various aspects of health IT, including CPOE, was associated with better patient outcomes and decreased mortality (Amarasingham).

To me, the major conclusion of all these studies is that we need to pay careful attention to the dangers posed by current medical practice as well as IT-based efforts to improve it. [Emphasis added by Rishel.] Part of the latter involves applying best practices and avoiding known errors in its implementation. To this end, we need more professionals trained in the field of biomedical informatics, where expertise in health care and information technology is combined to use health IT optimally to improve the quality and safety of health care (Hersh). Fortunately, the economic stimulus package includes resources devoted to educating more of these individuals. This will increase the availability of such professionals to fill the jobs that will be created by the incentive funding portion of the stimulus package aimed to increase proper use of health IT in physician practices and hospitals.

While this humble blog is not even a David to the Post’s Goliath, and while I am certainly preaching to the choir, this is more than a fruitless gesture. It gets the responses into cyberspace where they may be discovered by search engines.

For more information on the Gartner hype cycle see the Fenn and Raskino book.