EHR Redux

Kibbe It’s time to revive the discussion of electronic health record software in light of the new federal regulations that define criteria for meaningful use and also set criteria for the EHR technologies that must be implemented by doctors and hospitals in order for them to become, and be paid for being, “meaningful users of certified EHR technology.”

While most of the public commentary so far has been directed to the NPRM on meaningful use, the real news here relates to the de-construction of EHRs that is described in the interim final rule covering EHR standards and implementation specifications. Of course, the NPRM and IFR are by design tightly linked. But the NPRM on meaningful use is primarily a set of instructions for doctors and hospitals about how to participate in the incentive payment programs established statutorily under ARRA/HITECH. The rule on EHR technology certification criteria, on the other hand, is a playbook intended for vendors and developers who want to qualify their products to meet the expected demand by meaningful users in those programs.

The revolution in the marketplace, if it occurs, will come from the changes to EHR technology blueprinted in the IFR, regardless of when, which, or how many doctors and hospitals become meaningful users. Let me explain.

Every software program has a “core.” The core is both actual and metaphorical, consisting of primary code routines around which others are constructed and subservient, as well as business logic which subsumes the purposes served by the application. The software core for traditional EHRs has been the routines for producing a “super bill” and documenting the evaluation and management steps taken by the provider, the goal being to capture all justifiable charges of the visit or hospital stay according to the rules set by the payers. Not to put too fine a point on it, it’s been all about the money. To the extent that EHRs have offered any return on investment to physicians and hospitals using them they have done so by helping to maximize the amount of charges claimed so reimbursements will be higher. This can border on abuse and even fraud, as physical exams are too easily “documented” by the push of an EHR button, but not actually performed. The engine driving this has been the fee-for-service payment system and all its costly, even bizarre complexity.

What Congress/HHS/ONC have now done is attempt to regulate into existence an entirely new software core for what is hereafter to be known as “EHR technology.” This new core is built around decision support and quality, rather than around charge maximization.

It’s a profound change, one that recalls the tradition of quality improvement and safety enhancement of which this is the latest incarnation. It has deep roots in the writings of Deming, Donabedian, Crosby, Leape, and, more recently Donald Berwick and David Blumenthal. Meaningful use creates a software core that focuses on data capture for individuals and for populations of individuals, along with the deployment of quite specific operations to be performed on and with those data, all of which relate to quality. These operations automate (that is, make more efficient) a number of key processes such as medication prescribing and order entry; they seek to improve quality through computational recall of information that is required for decisions about care; and they enhance safety by popping up alerts and reminders as close to the point of care as possible.

One of the more important of these operations is the reporting out of data organized into functional and clinical quality measures with a numerator and a denominator. Another important operation is the making accessible to patients/consumers of copies of their health summary data in standardized and computable electronic format that can be rendered as human readable documents, too. The latter may not only be a new tool in the box of quality tools, but a disruptive innovation in the sense described by Clayton Christensen in his many books and articles on technological innovation.

Now, merely redefining the core software functionality required of EHR technology used in the HITECH incentive payment programs may not be enough change to be revolutionary, although it’s a very good thing. However, the mandate for a new software core is accompanied by three additional and very specific regulatory directives included in the IFR. Taken together, they create an entirely new blueprint for the health IT industry to follow.

The first of these is the establishment of a new and HHS-controlled certification process, separate and apart from the industry-led Commission on Certification of HIT, or CCHIT. The language in the IFR makes clear that this break was intentional and carefully considered by those at the very top of the administration: “…the Secretary has decided not to adopt previously recognized certification criteria developed in 2006 [that is,by CCHIT] as any of the certification criteria in this interim final rule.” (Emphasis and notation added.) This one of the very few places in the document where the Secretary of HHS is invoked.

What the IFR says is that with respect to EHR technology going forward under HHS auspices CCHIT’s criteria are irrelevant. CCHIT may apply to become one of the certifying entities under the new regime for EHR technology certification being set up by HHS — and its heavy certification criteria may continue to be used by vendors on a voluntary basis — but it is no longer primum inter pares.

This is an important signal to the industry, because critics of CCHIT’s certification process, including myself, have pointed out that its costs and complexity have acted as a discouragement to technological innovation and a barrier to entry into the market by small companies whose software would likely be lower cost, easier to use, and less risky to implement. CCHIT in effect acted as judge and jury for its own industry’s definition of EHR software, inhibiting alternative approaches that would embrace component or modular architectures, web-based delivery also known as “software-as-a-service,” and practical means of achieving interoperable data exchange between applications from different vendors. Now, with HHS Certification replacing both CCHIT’s criteria and methodology, the government will be setting the terms for innovation and competition in this market, not a relatively small number of established vendors whose representatives served on the leadership boards and commissions of CCHIT. It’s a whole new ball game, as they say.

Secondly, the framers of the IFR explicitly encourage EHR technology vendors to develop products and services using a modular or component model, as an alternative approach to the single vendor, integrated EHR product model favored by the legacy vendors They use the analogy of plug-and-play as typified by modern audio and video equipment, writing:

“An innovative and competitive HIT marketplace needs to exist much like the marketplace for consumer electronics, where, for the purpose of setting up a home theater, a television, DVD player, and stereo system can be purchased from three different manufacturers, from a single manufacturer, or as a complete system from one manufacturer. To that end, we believe that it will be common in the near future for Certified EHR Technology to be assembled from several replaceable and swappable EHR Modules. For example, an EHR Module specifically designed to enable electronic health information exchange may be implemented for the purposes of interoperability and participation in a health information organization, regional health information organization, or some other consortium whose purpose is to enable the electronic exchange of health information.”

I think a better choice of analogy would have been to compare modular EHR technology with the way add-ons and plug-ins are available to enhance and extend the display and management of information in web browsers, or the manner in which the Apple iPhone apps store offers consumers downloadable applications that run on the iPhone OS platform. Regardless, the intent of HHS to influence the marketplace in a direction away from the legacy monolithic, single-vendor, one-size-fits-all model, is still very clear.

And, finally, the IFR authors open the door to innovation through clear-cut separation of content data exchange standards from transport and networking standards. They wisely offer the industry choices among similar and emerging content exchange standards, for example including both the CCR standard and the HL7 version of the CCR, as ways in which to use XML to standardize patient summary health data for movement across the network. However, the major breakthrough in the regs has less to do with the standards per se than with the clear directive to make it the norm that any application on the network must be able to consume data from any other application.

The reason this is so important to innovation is that it frees individuals and groups with potentially new and valuable ways of presenting or handling the data from having to worry about pre-existing applications to which their new app or device would have to conform. Developers and software engineers crave this kind of freedom of creative expression, and entrepreneurs understand that new business models for health IT will be available only if developers have the data in easily accessible standardized format for their work.

Taken together, these reforms will have profound changes on the marketplace for EHR technology over the next five years. Already, new entrants are poised to bring innovative products and services to the 85% of physicians who don’t yet use EHR technology in their practices. PracticeFusion, Optum/UnitedHealth, Medicity, RMDNetworks, Relay Health, Covisint, DocSite, AthenaHealth, and McKesson/HP are among the companies who have recently announced a “meaningful use EHR technology” offering that makes use of a “platform” with some degree of exchangeable, modular applications, along the lines of what is described in the IFR. And there will be many others. Costs for these products are generally lower, and in some cases significantly lower, than the comprehensive EHRs with which they will be competing.

The confusion that is a concomitant of very swift technology paradigmatic change, combined with billions of dollars of federal market subsidy, and in the context of new regulatory control and market influencing directives, will be intense for the near term. Doctors and hospitals will not be able to easily discern which product offerings among the many new and older EHR technologies are best suited for them, their practices, and their patients.

But when the dust settles — and it will settle — we may just find that EHR technologies are at the center of a health care system capable of improving quality and helping all parties to make better medical decisions.

David C. Kibbe, MD, MBA, is a Family Physician and Senior Advisor to the American Academy of Family Physicians who consults on healthcare professional and consumer technologies.

28 replies »

  1. We are a bunch of volunteers and starting a new scheme in our community.
    Your site offered us with helpful information to work on. You have done a formidable job and our whole neighborhood
    might be grateful to you.

  2. Nice post. Seem true on most accounts but I also think that today medical practitioners are looking to avail of this federal incentive by trying to comply with the definition of meaningful use but at the same time EHR providers are looking at their own set of profits.
    This misunderstanding is mostly I believe as a result of wrong interpretation of the federal guidelines. The EHR providers need to look at these guidelines from the prospective of the practitioners who deal with different specialties.
    Each specialty EHR has its own set of challenges or requirements which I believe is overlooked by in most EHR vendors in a effort to merely follows federal guidelines. This is resulting in low usability to the practitioners, thus less ROI, finally redundancy of the EHR solution in place.
    I think ROI is very important factor that should be duly considered when look achieve a ‘meaning use’ out of a EHR solution. Though one may get vendors providing ‘meaning use’ at a lower cost, their ROI / savings through the use of their EHR might be pretty low when compared to costlier initial investment. Found a pretty useful ROI tool that is pretty customizable and easy to use. It also accounts for the different specialty EHR’s too.
    Some of the other useful resources on this topic:
    REC’s putting EHR’s to meaningful use
    Certification criteria for EHR
    Also the introduction of REC’s through the HITECH act. is a great way to avail of quality EHR solutions at competitive prices. The stiff competition among not only these REC’s but also among EHR vendors ( to become a preferred vendor of a given REC) will result in lot of positives to medical practioners.
    Looking the funding provided to the REC’s, the staggered grant allocation system also promises to be an unbiased way of allocating funds. It will also help in the concept of REC’s helping out each with their own unique business models. It can be one of the possible answers to the
    ’safe vendor challenge’ as discussed by many critics.

  3. Regarding Mr./Ms. Bisht’s comments: HL7 is an encoding scheme – for creating messages that contain clinical and administrative data in healthcare settings. That is all I noted.
    It is also explicitly considered a “standard”:
    “HL7 (Health Level 7): An ANSI standard for healthcare specific data exchange between computer applications.”
    The “plug and play” reference regarding the HL7 is imprecise in any case. The “plug and play” moniker does not have a precise definition. A similar description is “usable out of the box” when referring to software. The term “standards” is not completely homogeneous nor are software standards always adhered to in implementations of them.
    I really do not understand the point of the comment in other words.
    Regarding the lack of plug-and-playedness or need for “tweaking” of HL7, a vendor of HL7 tools provides a good analysis of this at least as interpreted by that company:
    * Missing Fields: some vendors tend to omit fields in the message instead of leaving them empty. This will change the number of every subsequent field from the start of the message.
    * Same Data in Different Fields The same information may be located in other fields – and even in different segments – in various HL7 implementations.
    * Same Data in Different Formats: The same data may come in different formats. For example, timestamp information should appear as 19991231100000.000, but some vendors divide the date and time into different sub-fields: 19991231^100000.000. This is only one example of the possible mis-formats.
    * Different Versions: The existence of a number of different versions allows data exchange only between applications that support the same version of HL7.
    * Missing Values (including mandatory fields): Although the standard requires only a limited set of values to be present (95 percent of the fields are optional), some vendors omit even those with required values.
    * Invalid Segment Grammar: There is a lack of adherence to the segment grammar that is required by the standard. Some expected segments may be missing, while other unexpected segments may appear.
    Regarding eClinicalWorks, needless to say anyone is entitled to his/her opinion regarding the strengths and weaknesses of any product, software or something else.
    eClinicalWorks as a company and as a product has weaknesses. My mentioning the web interface that I produced for the urgent care facility stems from the relatively poor customer service that that facility has experienced from eClinicalWorks.
    The facility is unwilling as a result to acquire any additions to the application it now has, including the “patient portal” that eClinicalWorks offers.
    Aside from that and from some relatively minor quibbles, the personnel at the facility are very happy with the eClinicalWorks application which they installed several years ago.
    I have my own quibbles – some serious – with eClinicalWorks as a company and the application itself, but not worthwhile to list them. Overall however, I believe the founders of the company have done a remarkably good job in the development of the software application and in the management of the company.
    “but they have a poor reputation for patient safety in the ambulatory care area”
    I have no knowledge of this, although I am aware that Senator Grassley has raised concerns on a range of issues in the healthcare/medical services industry. What degree of substance those concerns have, I do not know. Perhaps a lot. Perhaps very little.
    Nonetheless in regard to Senator Grassley’s credibility on healthcare policy and likely on any details about the healthcare system in the USA, I want to note that he has been one of the more egregious and explicit liars regarding the characteristics of the Canadian and UK healthcare systems, among other topics.

  4. In response to Wendell Murray’s posts, I thought I would make a few corrections. HL7 has nothing to do with vocabularies. This is basic fact and is well known the HL7 user community. From the HL7 site, “ Founded in 1987, Health Level Seven International (HL7) is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services”
    HL7 is a communication protocol or specification. It is NOT a standard. If it were a standard, HL7 based interfaces would be ‘plug and play’. They are decidedly not plug and play. They are non-uniformly implemented and require both vendors to tweak the interface to make it work. Some vendors use ver 2.2, others ver 2.5 or higher. Most vendors implement HL7 differently. The beauty of HL7 is it’s flexibility. The downfall of HL7 is it’s flexibility. To make interfaces work out of the box you need rigid standards, NOT flexible, ‘subject to interpretation’ specifications.
    I also find it interesting that Mr Murray has such evangelical regard for eCW. There are well known issues with many EMR software, especially with regard to data integrity and e-prescribing error. I don’t wish to single out eCW software, but they have a poor reputation for patient safety in the ambulatory care area. 3M, Cerner and a few others have been similarly implicated on the inpatient side. Senator Grassley’s office is conducting a probe of this matter. The message, I think is, the fastest growing companies may be releasing software updates so quickly to meet customer demand without adequate testing and with medical software this can end in wrong medicines or treatments and patient deaths. This is why lowest price or excellent product demonstration should not be relied upon to make a purchase decision.
    Dihrendra Bisht

  5. Dr. Kibbe: Once I solve the issue of integration with the eClinicalWorks databases – key needless to say but delayed because eClinicalWorks does not provide the API for the application (understandable, but debatable policy) – add some additional modules after the integration mechanism is in place and make various needed enhancements, I may well do so for all the reasons that such projects are offered as free and open-source.
    eClinicalWorks, while an excellent application, has by now an enormous userbase, but one that has some legitimate complaints about customer service and about this restriction on add-on services.
    There are no doubt many users and technical advisors to users who would be interested in enhancing any application along these lines. I suspect many improvements would be made quite quickly once the application is made available.
    I should be at that point within a month or so, depending upon how much time I have available to complete the basic enhancements/integration mechanism.
    Also in line for work is an integration of PatientOS (an excellent FOSS EMR/PM written in Java) with the Indivo PHR application developed at Childrens Hospital in Boston.
    Much more could be written on specifics, but enough for now.

  6. Thanks to David Winn, MD, founder of e-MD, one of the EHRs most popular among physicians in small practices, due in large part to its attention to user interface issues, and one of the early proponents of semantic interoperability. Nice to know you’re still in the game, David!
    And to Wendell Murray: I think your data exchange app is pretty cool. There are quite a lot of people developing web services that can act as agents for any EMR or EHR system, to access the database and format the data in CCR standard XML, and to do the reverse on receipt of a CCR XML file. It gives me hope that near universal semantic interoperability (at least with respect to the MU data set which is a small CCR profile) is around the corner, even for those EHR vendors who, as David Winn describes, have for so long stalled and delayed the inevitable.
    Wendell, any interest in developing such a web service agent as FOSS? The only hard part is doing the first time mapping to each EHR’s database. But once that is done, voila!
    Kind regards, DCK

  7. “..will require a universal standardized and codified vocabulary”
    This vocabulary effectively already exists and is communicated via HL7 encoding or XML encoding or a combination of the two.
    One further comment regarding a web-accessible front-end. I personally within a few days last summer designed and programmed a Java-based web-accessible front-end for the eClinicalWorks application that is usable by any outside party – primarily for use by patients going to an urgent care center that uses eClinicalWorks as its EMR/PM system.
    The application collects all relevant patient data input by the patient or his/her proxy, updates a dedicated MySQL database (it has yet to be integrated with the eClinicalWorks’ MySQL databases, but that is another story), then e-mails the patient’s primary care physician automatically with relevant information regarding the urgent care matter.
    It also electronically finds and checks the website of the primary care provider for the urgent care patient to see if the website offers an entrypoint to its EMR system (assuming it has one), then automatically requests relevant clinical data from that EMR system (which has to be set up to accommodate this).
    The primary care EMR system receives the request, uses a feature available in virtually all good-quality EMR systems to collect the relevant data from its database or databases, then formats that data in XML. The data in the XML format is automatically sent back to my application that then uses the received data to update the dedicated database, then another module updates the eClinicalWorks’ databases – or will when that integration is completed. Again another story that.
    I have so far only experimented with the exchange of data with the EMR system used by my own primary care physician, but this exchange of data is relatively simple to implement.
    My physician’s EMR system uses a small amount of coding done in a Microsoft programming product that handles the reception of the electronic request, which is sent using web services, then to process the request, then send the data back to the initiating module within my application. An alternative would have been to use Java code on both sides of the transaction which obviates the need for web services.
    This provides the urgent care physician with all relevant data – in so-called “real-time” – regarding the urgent care patient within the eClinicalWorks application itself. All triggered by entries made by the patient him or herself either before going to, enroute (through a smart phone of some type that can access websites) or at the urgent care center itself.
    More relevant and necessary details, but this at least illustrates how relatively easy it is to set up an automatic electronic exchange of data.

  8. I wholeheartedly agree with Dr. Kibbe. CCHIT’s onerous certification criteria stifled innovation while protecting the interests of large and expensive proprietary vendors. Innovation, IMO will come from more agile, physician centric (ie physician led) vendors.
    Broad adoption will occur once systems are easy to use such that they do not result in a lengthy implementation phase and the loss of revenue associated with concomitant decreased productivity. True interoperability (semantic interoperability) whereby different EMR systems can communicate and actually comprehend the medical information passed between them will require a universal standardized and codified vocabulary. Still, some vendors, in order to protect their installed base, will resist to the bitter end. We see lack of cooperation with these standards at every turn with vendors who, because of price or market share, use stall tactics to delay the implementation of interfaces. Greed and avarice are alive and well, thank you, in the HIT marketplace. Maybe some Google like upstart will come along and shake things up for some of these HIT institutions.

  9. “Clay Christensen’s work on disruptive innovation”
    I have read The Innovator’s Prescription which is generally excellent with several invaluable insights and some outstanding analysis, although not the original book. I think he and his co-authors overdo the “disruptive” idea, but generally the idea is useful, true to reality and insightful.
    Your point is a good one, if any EMR or similar technology, so long as that application provides useful functionality to any user whether on the provision side or elsewhere, is adapted rather than nothing.
    I am still amazed at the level of resistance to adaption of any clinically-oriented computer application on the part of physicians as well as their willingness to accept the assertions of any given salesperson for any given commercial system while failing to negotiate aggressively to reduce all relevant prices and ensure better customer service during and after implementation.
    The marketplace, if the evaluation and buying process is done methodically, favors the buyers by a long shot.
    There are many eager commercial vendors out there with good products who are willing to negotiate, along with many other products such as PracticeFusion, the FOSS products listed or inexpensive, commercial applications such as AmazingCharts to select from.
    Anyway, please keep up the evangelizing. Eventually it will pay off.

  10. Is an Interim Final Rule like a Jumbo Shrimp?
    I’m just a doctor but I think “The EHR Guy” got it right—the systems that are currently available are financial systems. I already have those in place in my office. Why should I spend large amounts of money on something the government deems “meaningful use?” Are they really interested in my office schedule, how easy it is to use and if it fits with something they think is good for me? This is a vendor driven initiative and not for our benefit
    Take this challenge: Forget everything you know about EHRs, EMRs, ASPs, ARRA or IFRs and put on your “I’M A PATIENT “hat. Now go see your personal doctor. What do you want her to have? I would say she only needs the answers to four questions: 1) Are you allergic to anything? 2) Have you had any previous diagnosis made? 3) What medications are you taking? and 4) Who is going to pay for this? This last question is important, but is really not central to patient care. Now, once the first three questions are answered, you want her to put the document she creates and any changes in your problem list and medication list in a place that is easily accessible to the next clinician who you see. This is clinical information management and clinicians do it every day. It is just an inefficient and cumbersome activity when the document and changes are stored on paper.
    Medical practice is, after all, a one on one activity—just the patient and their clinician.

  11. I’d like to address some of the fine points made by Wendell Murray. I have never said that modular or native cloud EHR applications are BETTER than the older client-server and database management-based EHRs. In fact, they’re not better, and in some ways are inferior. This is one of those anti-intuitive facts about disruptive innovations, that they start out life “crummy” compared to the upscale products with which they compete. For a really authoritative read on this, take a look at Clay Christensen’s work on disruptive innovation.
    In brief, what happens is that established companies gather at the top tier of the market, selling their comprehensive products at high cost to their best customers, at the highest profit margin possible. Their products “over serve” the needs of the rest of the market, who can’t afford the high prices and don’t need all the functionality or high performance of the up-tier products.
    The disruptively innovative firms start to compete NOT with the up tier products, but with “non-consumption,” that is, for the business from the rest of the market that is sitting on the sidelines waiting, not buying. The disruptively innovative firms offer products that aren’t as complete or complex as the up-tier companies’ products, but they’re a lot less expensive, and they’re easier to use, and they can be installed or implemented rapidly and by lay persons. The transistor radio, the Apple IIe computers, the early cell phones, Southwest Airlines….these are all examples of “not so good” innovations that eventually stole market share from the up-tier product or service firms, not by competing directly with them (at least not at first), but by offering the non-consuming public something they wanted and could afford and which met their performance characteristics well-enough.
    It is always my mistake not to mention FOSS, which I consider to be an important segment of the emerging market for EHR technology and a leading group of people ready to be innovators. Thank you for reminding me to do so! ; )
    Kind regards, DCK

  12. Dear Reed: Thanks so much for your comments. I can’t answer your question about why basic capabilities of EHR technology for trustworthiness and integrity were left out of the NPRM and the IFR. The guidance you suggest is mandatory could well be something that will be a regulatory add-on later this year, and I’m sure you will continue to be an advocate for that. It remains to be seen how the next NPRM or IFR on the certification process itself might include or at least make reference to the legal requirements you describe. This was supposed to be published in January, but now looks as though it will be pushed out to March. In any case, I think there are still opportunities for you to comment on and address the records management and integrity aspects of the new EHR technology certification process.
    Kind regards, DCK

  13. A good read as always David, very informative, and another example of your continuing excellent service to the community. One concern: perhaps I am misinterpreting, but there seems to be an implicit theme that HHS in general and CMS and ONC in particular, are behaving sagely and in the best interest of the country in these matters. If that isn’t intended, all the better. I’ll speak to the point in either case.
    It is important to also note what is omitted from NPRM and IFR indications for the new “core”. At the top of my list are the following:
    1. Inclusion (or mention) of existing US and international standards for records management systems in general and electronic medical records in particular. This omission necessarily means that all “qualifying systems” will only incidentally or accidentally meet existing RM, EHR, and EHR-S standards. This, in turn, will magnify what others have pointed out, the “accumulating legacy burden”. You are, of course, deeply familiar with this issue in the context of your own extensive work with ASTM, as others like myself are in the context of HL-7 EHR-S Functional Model Standard work. Why do you suppose there is no mention of even future source system standards support as requirements in NPRM and IFR?
    The HITECH Policy and Standards Committees had authoritative input on the necessity of first providing for the capability of a system to support basic records management and health information management requirements, as a precondition for derived meaningful uses. This specific point was documented in an HL7 response to last year’s HITECH Call for Comments on MU, which also included a short list of specific and succinct actionable mitigating recommendations, based in Standards. None appear in the NPRM or IFR.
    Since HHS/CMS/ONC knows that EHR trustworthiness support capabilities cannot be presumed, I look forward to your thoughts on why they advance meaningful uses of derived functions like decision support, but leave unstated the necessity of trustworthy source system information by omitting Standards adherence requirements.
    2. Basic Federal Rules of Evidence, in particular Rule 803(6), stipulate requirements for valid admissible records in Federal Courts (and similar in many State courts). However, even a notable cohort of current Certified EHRs cannot necessarily support these, most commonly the accuracy of record authorship. (Thank you to Hoyt Kesterson and George Paul for correcting me on an prior error on that point). A simple EHR testing vignette my associate Patricia Trites and I published in the Journal of AHIMA all the way back in 2005 still illustrates that readily, as it did when applied to several Certified Ambulatory EMRs at HIMSS 2009.
    The ONC in 2007 acknowledged to its own RTI/AHIMA Task Force on Fraud Prevention that neither HITSP nor CCHIT were directed to include medical-legal validity compliance capabilities, so no surprise neither entity advanced that seemingly fundamental requirement set. The current ONC appears to be maintaining this position.
    There is one oblique mention of this omission in the IFR, on p88 of 136:
    “4. Additional Considerations, Clarifications, and Requests for Public Comments
    a. Relationship to other Federal Laws
    Nothing required by this interim final rule should be construed as affecting existing legal requirements under other Federal laws. While the capabilities provided by Certified EHR Technology may assist in the compliance with certain legal requirements, they do not in any way remove or alter those requirements.”
    At least there’s that one mention of the continuing need for basic due diligence on “meaningful trustworthiness”.
    Perhaps the way HHS/CMS/ONC is proceeding is the best that can be achieved given the political landscape and strategic placement of major EHR vendors. If these limited next steps are to be deemed acceptable, at the least IMO there must be guidance on due diligence on capabilities assuring the integrity of the primary source record otherwise left unaddressed, unguarded, and unprotected. To do otherwise sacrifices for the near term and perhaps even the intermediate term the first necessity, a trustworthy record, in turn thus risking the safety of patients and the confidence of all who are pledged to do no harm.
    Hopefully the months ahead will see these and other basic gaps closed. I eagerly look forward to your thoughts and observations on these points.
    Reed D. Gelzer, MD, MPH, CHCC
    Advocates for Documentation Integrity and Compliance

  14. “The software core for traditional EHRs has been the routines for producing a “super bill” and documenting the evaluation and management steps taken by the provider”
    This sentence depends upon what is meant by “traditional”. Like it or not, computerization’s presence among medical service providers has always been focussed on reimbursement. No physician complained about computerization in the late 1960s when the first so-called “service bureaus” were created to handle administrative tasks for physicians offices, primarily billing.
    As I have noted before regarding Dr. Kibbe’s insistence that installed EMR software is somehow inferior to EMR software accessible through a web browser that is resident on a machine or machines managed by a third-party, any “legacy monolithic, single-vendor, one-size-fits-all model” – I am not even sure which product or products he refers to here – can be made web-accessible. All that is required is to place a web-accessible interface in front of the application. This has been the focus of development in software for well over a decade.
    If the business rules embedded in the so-called “legacy” system or the means of data access make the legacy application inferior to other applications whether due to features or maintainability then that is another issue, but web-accessibility can be provided for any application.
    In addition, the arguments for the desired patterning on the applications available for the iPhone in fact are better satisfied by what I repeatedly assert is the best use of the resources of the Office of National Co-ordinator for IT: the “sponsorship” for literally a pittance of some number of free and open-source EMR applications now available: PatientOS, Tolven, OpenEMR, VistA for starters.
    The vast number of outstanding software developers who gravitate towards FOSS projects would be interested and available to rapidly improve each application and to offer the necessary implementation services that all ultimate users would need. This all at a true miniscule fraction of the cost imposed on the ultimate users by most proprietary systems. The availability of high-quality FOSS product would also drive down the much-too-high-cost of most proprietary systems.
    Interoperability underlies the entire Java platform and the many frameworks built upon Java. Microsoft’s long commitment to the development of web services and to the myriad uses of XML or other SGML-based self-describing software structures has added to the availability of well-developed techniques for easy data interchange and easy remote method invocation from one software product to another. Enhancing interoperability is merely a matter of applying those now-standard techniques – easily applied to any “legacy” system.

  15. Dr. Kibbe:
    Thank you for this post. You have described clearly what many of us (aka “Luddites”) have felt instinctively over the past decade: that current EHRs are designed primarily to facilitate upcoding and phony documentation (aka “lying and stealing”). We have been unable to find any features that would truly lead to better health, either for individuals or populations.
    I could list dozens of articles distributed by the AAFP and groups sponsored by the AAFP that cite higher levels of coding as one of the main, if not the main, reasons that MDs should invest in EHRs (this upcoding is also given as the primary vehicle to finance PCMHs, but that’s a whole different kettle of non-evidence based fish). Is it any wonder that many docs feel that they are being sold a bill of goods by their own professional organizations?
    I hope what you describe indicates a more realistic approach to the potential benefits to be obtained from EHRs. Thanks again for the post.

  16. Gary L: I think you’re asking a serious question, not being facetious. ; )
    What I’m saying is that the federal government is trying to make EHR technology centered on quality improvement and decision support. This is new and different and potentially capable of making some previous EHR software less desirable, although not necessarily obsolete. There is already more choice in the marketplace than a year ago, and pricing associated with modular products will be lower than with the integrated ones. Some EHR technology will be free or very close to free.
    As long as fee-for-service is dominant as a payment method, billing systems and charge capture software will be marketable. But I am definitely suggesting that clinical data capture and management will increasingly be de-coupled from the charge capture and E/M software, and that examination of the abuses and fraud associated with its tight coupling will face increasing examination by payers and CMS.
    A lot of EHR software was sold with the implicit or explicit promise that E/M coding embedded in it would facilitate up-coding and higher revenues for the practice, NOT with the promise that care would be better quality or that better, guideline-level decisions would be supported. If there was ever snake-oil, this is where it was and is still to be found. “Wink, wink, nod, nod, we’ll help you upcode on a systemic basis, and it’s all fair game.”
    What the government now wants, and is putting some money behind, is a model of EHR technology that is centered on data collection and reporting for quality improvement, with explicit accountability for decisions built-in, and I think that’s a major shift, and a good one. I don’t expect EHR consultants who’ve made their living selling the high-cost, quantity-encouraging systems to agree that this is a good thing, because they’ll make less money.
    Regards, and thanks to all for a good discussion. DCK

  17. Thanks for the good read. Can you add some detail on how we are going to design structured data entry for all this game changing data and when we will be relieved of the onerous and counter-productive E/M coding rules?
    Talk about a legacy burden – billions of dollars of EHR software design, purchase and implementation based on bizarre, fundamentally broken billing rules that force physicians to over document to such a degree that the charts are unreadable and an entire industry of ‘documentation police’ will become wealthy in short order.

  18. There should be a clear distinction between the Health Information System (HIS)in the case of hospitals, and the Practice Management System (PMS) in the case of physician offices, with respect to the EHR or EMR.
    Both the HIS and PMS are financially centric applications, and they should be. A sound financial management of any of these organizations is a must.
    The EHRs, or EMRs, (I prefer the latter term) should be patient, health and medical centric.
    There should be a middleman that can tap into these EMRs and extract intelligently information that translates into financial activity and provide it to the HIS or PMS.
    Healthcare organizations that request their clinicians to be charge posters are the most mediocre organizations in existence.
    I never engaged with a health organization that would put in practice the medical aspect of software with a financial core system.
    Sorry, but life is too short to be around snake oil salesmen.
    The EHR Guy

  19. David, Are you proposing that current EMR core structure is about to become obsolete, changing from a sophisticated billing algorithm to one based on outcome measures, and preferred practic patterns??? What do I tell my colleagues who think I know something about EHRs??

  20. Exactly, what we must avoid is that television is not a negative influence on our children as they rely on the attitude and performance of individuals who are on television, there are many cases like the House that by their addiction vicodin has led to people using this medication and this is proven in the U.S., since 40% of the American population is assiduous to this medicine and is caused by the influence that Dr. House at the time, as indicated findrxonline in his article that this medicine is dangerous if not properly due to moderation.
    Hopefully, the media are aware that an important means of educating future generations. I thankful that we can improve the current way of life for our families.

  21. Dear Tom: Thanks for your comment, which better states the paradigm shift than my own writing! May I quote you? ; )
    Interesting point about “accumulating legacy burden.” I’m sure that the legacy products and services will continue to well in this market — at least some of them will. I wonder how much change will occur in their products. After all, it was IBM that really set off the PC marketplace, despite the fact that their mainstream “legacy” products were mainframe and mini computers. However, they were among the few companies that could pull this off. Digital Equipment and Wang lost their way completely. If the legacy companies can adapt to the newer entrants in the market, I think some of those companies could do well.
    Kind regards, dCK

  22. David,
    Well done! I agree with you that the essence and realities of “meaningful use” cuts deep into the core of the legacy EHR platforms. Today’s solutions are cleary structured around individual patient data files (not patient populations ), focused on charge capture optimization (not decision support nor outcomes), coded for data storage/retrieval routines (not performance analysis) and organized to accomplish workflows that mimic yesterday’s paper norms (not innovate the underlying SYSTEM of care delivery).
    As a result, most are ill-equipped to effectively be relied upon as a ‘core’ on which we can innovate new solutions in order to achieve the goals spelled out in the ‘meaningful use’ guidelines. After all, MU represents a foundational shift in how we manage our practices, and does not represent merely a checklist of required features ( a la CCHIT).
    I just the industry doesn’t accummulate too much legacy burden before the next generation solutions can come of age.

  23. The Notice of Proposed Rule Making (NPRM) and Interim Final Rule (IFR) were the documents Dr. Kibbe alludes to that were released by the Office of the National Coordinator for Health IT (ONCHIT (or ONC, for short)) US Department of Health and Human Services (HHS) in late December 2009. They elaborate on changes in law established under the Health Information Technology for Clinical and Economic Health Act (HITECH) section of the American Recovery and Reinvestment Act (ARRA).
    The Continuity of Care Record Standard (CCR) is a standardized format for clinical data exchange and storage that was named as a standard in the new documents. Dr. Kibbe was a lead architect and collaborator on the development of the CCR.
    Hope this is helpful.

  24. TERMS and ACRONYMS used in the blog post “EHR Redux.”
    My apologies about the acronyms used in the article. Here are some brief explanations for readers. I greatly appreciate the feedback:
    EHR = generally used for “electronic health record” software used by doctors and hospitals, often replacing older term EMR, or electronic medical record. Often confusing, as some people use EHR to mean the content or output of a software program, rather than the software application itself.
    HHS = Department of Health and Human Services of the U.S. government. The Secretary of HHS is a cabinet level position, and is currently occupied by Kathleen Sibelius, former governor of the state of Kansas.
    ARRA = American Recovery and Reinvestment Act of 2009.
    NPRM = notice of proposed rulemaking, the normal way that our government agencies make regulations. i
    In this case we’re referencing the NPRM published Dec. 19, 2009, on “meaningful use,” interpreting and putting into effect the EHR incentive programs that were included in the stimulus bill, the American Recovery and Reinvestment Act, or ARRA, passed and signed into law in February, 2009.
    HITECH = that portion of ARRA that specifically covers the EHR incentive program, and other health IT related grants and programs.
    Meaningful Use = under the ARRA/HITECH legislation, physicians and hospitals will be eligible to receive incentive payments for the “meaningful use of certified EHR technology.” Meaningful use is described and its criteria give in the NPRM referenced here.
    IFR = interim final rule, another way that agencies of the federal government publish regulations, but when they are on a fast track and there is urgency, essentially by-passing the NPRM stage.
    CCR = Continuity of Care Record standard, a content messaging standard that uses XML to create a summary of a person’s relevant medical data, in computable and human readable format. Basically, the building block for EHR interoperability. One of two standards using XML for this purpose included in the IFR discussed here.

  25. I thought I was up to date on this topic but I too, am stumped by NPRM…
    Google says:
    NPRM Notice of Proposed Rulemaking
    NPRM Non-Penetrating Roof Mount (satellite antenna)
    NPRM Network Performance Report Message (Hekimian)
    I guess it is the first and I guess it has something to do with government.
    However, as a courtesy to your readers you might want to explain explain CCR, HHS, ONC, ARRA, HITECH in addition to the acronyms mentioned by Legacy Flyer.
    You can probably count on most people to know DVD, XML, IT.

  26. My room mate in Med School said that he knew he would be a full fledged doctor when he could look at any random sequence of letters on a license plate and come up with a medical term using those letters. I appear to be a failure since I cannot do the same with the apparently random letters in this article.
    Nowhere in the text of the article are the following acronyms explained; EHR, NPRM, IFR, HIT, CCHIT. Perhaps because this was published in “Electronic Medical Records” such explanations are not necessary. However, without more explanation of the “alphabet soup” of this article it is hard for me to be a “meaningful user”

  27. Thanks David for the in-depth digest of these main ideas of the IFR in terms of how they advance the principles of a more open, robust, interoperable HIT infrastructure. Regardless of the success of insurance reform legislation, such quantum leaps in the HIT system afford the US an opportunity for an equally important form of healthcare reform – based on quality improvement, opened access by patients to see and use their data, and – as noted in an earlier blog entry – even a chance to improve healthcare access and quality in the developing world.