Recently in Certification Category

Just as it is often true that some generals prepare to fight the last war, so too it is also the case that certification is getting ready to validate last generation's client-server technology. The famous example is the construction after World War I of the Maginot Line by France, a series of trench like fortifications in anticipation of trench warfare. Equally famous is (German) General Heinz Guderian's World War II blitzkrieg that went around (and over) the wall using tanks and aircraft, rendering the Maginot line obsolete. Innovations in cloud computing, the provisioning of web based EHRs (EMRs) and database appliances are the equivalent of an emerging technology blitzkrieg in HIT. While we should not represent different players in the market as enemies, large and established HIT vendors (see separately published research here for an overview) are likely to confront a looming innovator's dilemma.[1] In the 1980s IBM would not look at any sales under $1 million dollars and was nearly driven out of business by upstarts building systems with a copy of SQL Server and a copy of PowerBuilder priced one tenth the cost. The dominant HIS and PPMS vendors are positioning themselves to be the next candidates for the unwelcome category of "too big to fail," though this time in HIT, not banking. The recommendation? Stop them before they hurt themselves. Stop them by deleting the word 'certified'. 

The prospective buyers of EHR technology are physician practices (eligible professionals (EP)) and hospitals. They are best protected from the unprofessional practices of a small - very small - minority of system sales people through their own professional procurement practices, diligently reviewing written proposals, specifications, and contracts. It is unlikely to be the basis of a legal claim against a software vendor installed at a given site that failed to satisfy meaningful use criteria for provider that the software system or modules were certified. The provider receives the reimbursement (if any is forthcoming) and is responsible for attaining and demonstrating a use of the system that delivers healthcare services in a more effective way according to the criteria of meaningful use. From such a perspective, certification may be of value to the vendor but it furnishes a false sense of security to the prospective buyers (such as hospitals and eligible physicians).

On the one hand, some of the meaningful use criteria, including those that capture basic clinical transactions, are best delivered by an underlying system consisting of a standard relational database, a frontend query and reporting tool, and a data model that represents the patient demographics, diagnoses and procedures, and related clinical nomenclature. The user interface at which the meaningful use of the technology, including the capturing of data electronically, reporting of data electronically, and the manipulation of quality measures is the contract at which the meaningful use is delivered. Multimillion dollar HIS systems are candidates for "over kill" from a transactional perspective in addressing such use yet at the same time lack the necessary infrastructure to support quality metrics through aggregation and inquiry via a data warehouse function. 

On the other hand, some of the meaningful use criteria - in particular the requirement to report about 100 quality measures - are poorly accommodated by the vast majority of HIS system on the market today. I do not know of a single exception where the HIS system provides for the aggregation and analysis of metrics in a way similar to what business intelligence (now 'clinical intelligence') does in business verticals such as retail, finance, telecommunications. Once again, the user interface at which the quality measures are surfaced is (in effect) the contract, but it will prove impractical to generate such a result. If these systems propose to perform the aggregations of a year's worth of data based on transactional detail, the predictable result will be a long, slow process. Reinventing the wheel is hard work, but that is the path on which existing HIS and PPMS (EHR) systems have embarked. I hasten to add that the quality metrics are critical path and required. However, the path to the efficient and effective production of them does not lie through certification.

Those providers that are currently reporting quality metrics from a data warehouse that gets its data from the transactional EHR are concerned that they are out of compliance. It is widely reported that Intermountain Healthcare is one such enterprise.[2] Are they now supposed to certify their data warehouse? Where is the value-added in that?

A long list of clinical quality measure requires reporting a percentage of a total aggregate of a given diagnostic condition; for example, percentage of patients aged 50 years and older who received an influenza immunization during the flu season (PQR1 110 / NQF 0041). These are what other business operations such as retail or finance call "business intelligence" questions. In the context of healthcare, we might call them "clinical intelligence" - or just plain quality measures - but the function is similar - to make possible the tracking of improvements in the delivery of care. To manage enhancements by measuring outcomes in aggregate. The periodic calculation of some 94 percentages requires scanning the entire database and performing an analysis, review, and aggregation of a totality of the diagnostic data. Even though most records will not satisfy a given diagnosis - whether coronary artery disease of diabetes mellitus - they will have to be examined. The lessons of some two decades of computing in finance, telecommunications, retail, manufacturing, and fast food are clear, but not always  obvious to those medical professional who have spent their time in healthcare IT. When you attempt to perform business intelligence (BI) against the operational, transactional system, then something has got to give. Either the performance of the transactional system is brought to its knees or the BI process has to wait. In fact, system design for high performance transactions processing are poorly adapted to generate the results required to perform business intelligence. The difference is between update intensive operations and query intensive ones, between updating and scanning. That is why the data warehouse was invented - in order to collect and aggregate the data required for reporting in optimal format, allowing the transactional system to do its job supporting clinical process whereas clinical intelligence is used to guide process improvements.

The counter-argument that certification of the functionality around clinical data warehousing ought to be rolled up into the certification process is the reduction to absurdity of the process itself. There will always be some such functionality - if not data warehousing, then cloud computing, database appliances, artificial intelligence in clinical decision support, and so on. The list is limited only by our imagination and that of our fellow innovators. The Meaningful Use Proposal has got it basically right (though one can (and should) argue about details). The reporting of quality measures, based on aggregated clinical detail is a proven method in other disciplines of driving improvements in outcomes by surfacing, managing, and reducing variability from the quality norm. ('If you can't measure it, you can't manage it') However, this value is provided by implementing systems that directly address the superset of meaningful use criteria captured in the proposal, not by driving the process up stream into one particular system architecture that happens to have emerged in the early 1990s and gotten some significant traction.

To see the full Comment submitted to www.regulations.gov on the rule-making for reimburseable EHR investments go here: http://www.b-eye-network.com/files/EHR Certification _Lou Agosta's Feedback to Centers for Medicare and Medicaid Services, HHS.pdf

Healthcare providers are in the business of fighting disease, not installing and maintaining software. Still, software is now a part of every business process; and it is on the horizon to become a part of the every process of diagnosing, managing, and treating diseases that occurs in a modern first world setting. The healthcare provider (whether eligible physician (EP) or hospital) has to demonstrate meaningful use. That burden cannot be shifted onto a certifying organization. Nor would such certifying entity be willing to warrant that its certified EHR system is used in a meaningful way by the provider merely based on its test scripts. Whose job is it to demonstrate that meaningful use is occurring? It is the provider's job. 

The proverbial buck stops with the EP and hospital. The ONC Certification document cautions: 'Eligible professionals and eligible hospitals that elect to adopt and implement certified EHR Modules should take care to ensure that the certified EHR Modules they select are interoperable and can properly perform in their expected operational environment.' All the usual disclaimers apply - the certified product is not warranted for any particular purpose and your mileage may vary. In other words, the adoption of a 'certified' EHR (EMR) does not create a safe harbor for a provider who purchases, installs, and uses one. Nor is the recommendation of this post that such a safe harbor be implemented, based on the requirement for provider accountability and the needs to improve quality and efficiency. The provider is still responsible for outcomes, demonstrating quality metrics, and showing that the provider makes meaningful use of whatever technology is acquired. Presumably the 'certification' is supposed to provide the provider with guidance (in the market) and 'a leg up' on getting over the bar to reimbursement and quality improvement. However, the result is to privilege a certain class of large, existing, dominant players in the market and to complicate the EHR technology acquisition process.

In general, the criteria of meaningful use represent a contract - an agreement - to which the underlying system (whether certified or not) has to conform in terms of producing usable, interoperable output. The provider will work backwards from the interface to assure that the underlying functionality conforms to its attestation - the provider's sworn testimony ('attestation') to the reimbursement office - that the system functions as required. By applying the principles of object-oriented system design and implementation to the challenge represented by meaningful use, the diligent and conscientious provider eliminate the extra step of certification.

The situation is analogous to that encountered in the so-called ERP revolution (enterprise resource planning) in computing. In the run up to the Y2K (year 2000) event in the year 2000, companies such as SAP, Oracle, JD Edwards, PeopleSoft, and many other ERP systems insisted their architectures were robust and flexible enough to support both transaction processing and BI from the same system architecture and data stores. Fast forward a few years, and by the year 2004 those of these companies that still survived were announcing and delivering revised architectures to support business intelligence. We are on track to repeat an entirely analogous repetition of architectural trial and error. Companies such as Cerner, Epic, Eclipsys, McKesson, GE Centricity, MedSphere, Meditech, and so on predictably claim that their transactional engines based in Mumps and Cache (those are data stores) can handle the job. But the job is complex and is inherently at odds with itself. It is a tad like building a car that gets both good gas mileage and one that has a lot of horsepower. In the software world, the solution is to feed the transactional data into a data warehouse or other business intelligence subsystem and use the warehouse to optimize the transactional one. (The automotive problem has still not been solved, nor will it be in this post.)

However, what about the innocent one to five physician practices that deliver much of the healthcare in the country? Who is going to prevent these practices, smart but totally naĂ¯ve from an information technology perspective, from buying a 'pig in a poke'?

First, the need for an assistance program to support such practices with the IT process is well taken. The Regional Extension Centers, where such practices can go to get a leg up on the process, are a step in the right direction - when they actually come into existence. There is also merit is something like a 'good house keeping seal of approval' that interoperability standards are actually implemented by the software in question. The availability of 'Geek Squad Class' professional services at an entry level price point using graduates of community college-based HIT programs also belongs on the list - see more details here. However, none of these mandates certification of the EHR software, the latter adding an unprecedented layer of overhead to an already complex process.

If a small physician practice is savvy enough to know its requirements and buy out of the box or configure a custom solution, it makes no sense to require such a practice to limit its choices to those approved by a certification authority, on penalty of being excluded from the reimbursement process. For those that are the opposite of savvy - and require additional support - the certification process will be as misleading as it is incomplete. The practices are still required to demonstrate meaningful use whether or not the software is certified to provide certain functionality that allegedly lines up with these criteria of meaningful use.

The certification process is anti-competitive in that it advantages existing HIS and PPMS systems architectures, configurations and whatever standards are thereby implemented. This is not bad in itself; however, it does not promote whatever innovations are occurring in a given market - for example, such as those that are occurring in cloud computing and database appliances. Of course, this implies the dynamics of 'technology lock in' as applied to HIT. 'Technology lock in' refers to the situation in which there is a cost associated with switching from one technology to another. There is a common approach to market innovation in software to discount deeply the software at the start of the sales and implementation cycle and recoup some of the discounts through subsequent prices increases that are proportional to switching costs plus the quality cost advantage.[1] This is a fair approach and results in total revenue to the developer and seller of the software that covers the development costs plus a profit roughly proportional to its marketing success based on the perceived and delivered value. One of the consequences - entirely independent of any certification process - is a standards war - where 'war' means 'competition' between alternative technology standards. Let's be clear on this one point. Technology lock in is a fact of life in technology and is not unfair when it is the result of the market voting with its dollars to prefer one standard or architecture over another. What is questionable and arguably unfair is to implement technology lock in by means of a certification process.

If the US Congress and the Office of the National Coordinator of Healthcare Information Technolgy (ONC HIT) want to benefit large established software vendors in the existing EHR technology market - see separately published research here for an overview -  then proceed with the rule-making in its current form. The result will be that the big will get bigger. The powerful, more powerful. Depending on one's perspective, this is not necessarily bad: a certain amount of consolidation and centralization offers economies of scale in the acquisition and installation of hospital information systems (HIS) at large  hospital systems and research institutions. What it does not offer is an opportunity to build out the HIT infrastructure at the community hospital level by innovating in affordable, usable, interoperable systems that address the requirement of the struggling constituencies at the community level. Of course, these two scenarios are not mutually exclusive. Just to pick one example, 'big' is required if you are HCA (formerly Hospital Corporation of America). My point is merely the latter arguably requires less of a financial subsidy in priming the pump (and at least at the level of an intuitive sense of fairness is less deserving of one) than the areas of the economy that lack HIS infrastructure altogether.

The situation in the case of so-called Ambulatory systems is different in that there are literally tens of thousands of small physician practices that will not even look up from their stethoscopes to consider a certified EHR technology with the bar being so far above what they can reasonably contemplate proposing, purchasing, and implementing. Once again the large practices such as Mayo, Intermountain, Geisinger, will require big systems that scale to accommodate hundreds of practitioners. Even if they prefer to report quality metrics from existing data warehousing architecture rather than rip-and-replace in favor of a new EHR with redundant functionality, they have resources to manage the alternatives. On the other hand, maybe not - Intermountain is reportedly complaining that its meaningful use process hits a dead end since its own data warehousing is not 'certified' and it most efficiently and effectively reports its reimbursable quality metrics from it - see story here.

Information technology (IT) is a key enabler in the transformation of the delivery of high quality, affordable, accessible healthcare in the USA. This post contains a single recommendation: delete the word 'certified' from 'certified electronic healthcare record'  (EHR) as a requirement for reimbursement under the HITECH portion of the American Recovery and Reinvestment Act (ARRA). In short, implement EHR technology pure-and-simple instead of 'certified EHR' technology. Although easy to state, this is a radical proposal. Thus, a discussion is useful of the pros and cons of a certification approach to transforming the HIT infrastructure using EHR. This acts as a lightening rod to constellate diverse issues and challenges in the market. The advantages have been called out in a previous post here. This post begins a conversation about the disadvantages of certification.

The certification process introduces a substantial distortion into a robust and dynamic market for such EHR software systems at multiple levels. Certification is an anti-competitive and administrative ('bureaucratic') barrier to market entry by innovative cloud computing applications, database appliance providers, and those high end hospitals and physician practices that command sufficient IT resources to implement their own in-house solutions using standard off-the-shelf components. In addition to satisfying the criteria of meaningful use and properly reporting quality metrics, all these three types of organization must now go to a certification authority (whether CCHIT.org or its successor organization(s)) and navigate the process of certifying a particular implementation and understanding of how the vendor EHR technology maps to meaningful use. I hasten to add that a given interpretation of the certification criteria (for example, at CCHIT.org) may be quite legitimate and proper without being the only possible one, the optimal one in a given context, or one on which a healthcare provider decides to 'bet the farm". In short, choosing a solution that is not certified result in the provider being excluded from the reimbursement process and the market whose outer boundary is defined by the reimbursement process.

It is important to note that 'certification' does not just advantage the selected large, existing HIS and PPMS systems at the expense of would-be innovators at the low end of the market. At the risk of sounding cynical, it is one thing to throw over the side smaller players who have no constituency - whether in the market or amongst regulatory administrators. However, certification also disadvantages such software, hardware, and system sellers as HP, IBM, Oracle, Microsoft, SAS, SAP as well as a host of large but lesser known players in the enterprise and corporate markets such as Informatica, Pervasive, ParAccel, Teradata. Certification disadvantages these companies and even more importantly the buyers that they might benefit whether they realize it or not. Perhaps IBM, HP, and so on are earning plenty of revenue and the sales staff does not believe they are disadvantaged. These sleeping giants are largely still just issuing press releases and marketing brochures - admittedly while continuing to perform consulting services - while pondering real investments in HIT software and technology. Well and good - but the real losers are the hospitals and physician practices, paying for reduced competition by means of what going forward I propose to call a 'certification markup' in price.

Eliminating the word 'certified' from the criteria for reimbursement will drive down prices of EHR systems, and, in addition, has the potential approximately to double the size of this growth by 2015, though not directly through the actual reimbursement process itself. How then? By allowing increased software competition not just from new, small innovative players, but by encouraging the entry of large, established IT players, the looming market shake up in EHR technology will be accelerated and deepened. For further background on the existing market see my research 'The Heatlhcare Information Technology Market is Poised for Growth' (here). 

Prospective buyers still need the products offered in a full, robust market and the cost saving that is (would-be) created by full participation. Many of the criteria of meaningful are precisely what the basic technology does best by means of a standard relational database, a frontend query and reporting tool, and a data model that represents the intersection of such basic dimensions as patient data, provider data, diagnosis code, cost, and so on. It strains credibility that well established software products such as IBM, Oracle, Microsoft or well-known brands from Cognos, Business Objects, and Hyperion require 'certification'. Of course, under the proposed rule-making, the healthcare providers that buy such products are still properly required to demonstrate meaningful use according to the proposed criteria and that may require a significant effort (or not); but having these products 'certified' adds no value from functional perspective, and the certification steps falls out of the process of acquiring software and demonstrating its meaningful use. The buck starts and stops with the healthcare provider's demonstration of meaningful use of the software to deliver quality care. The certification step falls out of the process as an idle wheel. Case closed.

One clarification is useful. Unless otherwise noted, this post takes issue with the point of view that 'certification' is a required ('mandatory') one for reimbursement. An alternative point of view that allows 'certification' as a voluntary process is called out.  Such an approach would capture some of the benefits of standardization and testing without the disadvantages of stifling innovation, distorting the market, and privileging one part of the market at the expense of another. Although such a compromise is feasible, it is anyone's guess what will emerge from the rule-making until the pro and con positions have been clearly articulated.

The rule-making that will determine which hospitals and physician practices are eligible for reimbursement for buying an 'electronic healthcare record (EHR)' is out for public comment (until March 15, 2010). The rules state that the provider must demonstrate 'meaningful use' of a 'certified EHR'. The 'meaningful use' portion has already been parsed to death about a hundred different ways, and is not further discussed in this post. This post is about whether or not the 'certified' is voluntary. The enabling legislation that I will quote clearly states it is 'voluntary'. Yet the proposed rule-making [CMS-033-P (CMS-2009-0117-002)] that implements the reimbursement process reads like the reimbursement requires purchase of a 'certified EHR'. If the EHR is not 'certified', then there is no reimbursement - so 'certified' would be mandatory. This is an inconsistency of numbing grossness.

     The underlying legislative act clearly states the Office of the National Coordinator of HIT and  National Institute for Standards and Testing (NIST) should set up a voluntary program to coordinate, define, and test standards and candidate standards. The key term is 'voluntary'. For example:

 [HITECH Act: Sec. 13101 - ONCHIT

The Public Health Service Act (42 U.S.C. 201 et seq.) is amended by adding at the end the following:

''TITLE XXX--HEALTH INFORMATION TECHNOLOGY AND QUALITY

''SEC. 3000. DEFINITIONS. . . . .]

'(5) CERTIFICATION.--

''(A) IN GENERAL.--The National Coordinator, in consultation with the Director of the National Institute of Standards and Technology, shall keep or recognize a program or programs for the voluntary certification of health information technology as being in compliance with applicable certification criteria adopted under this subtitle. Such program shall include, as appropriate, testing of the technology in accordance with section 13201(b) of the Health Information Technology for Economic and Clinical Health Act.' [emphasis added]

[. . . . ]

'HITECH ACT Sec. 13201. National Institute for Standards and Technology Testing.

(b) Voluntary Testing Program.--In coordination with the HIT Standards Committee established under section 3003 of the Public Health Service Act, as added by section 13101, with respect to the development of standards and implementation specifications under such section, the Director of the National Institute of Standards and Technology shall support the establishment of a conformance testing infrastructure, including the development of technical test beds. The development of this conformance testing infrastructure may include a program to accredit independent, non-Federal laboratories to perform testing.' [emphasis added]

           If I read this correctly, there is nothing in the HITECH portion of the ARRA [American Recovery and Reinvestment Act (sometimes also known as 'the Bailout')] that requires, mandates, or forces the use of 'certified' EHR in order to qualify for reimbursement.The plain meaning of the word 'voluntary' is available to mere visual inspection. Yet the the rule-making document (not quoted in this post, but see here) goes on-and-on referencing reimbursement is allowed for 'certified EHRs'. That would be a requirement - mandatory - would it not? Am I a tad confused by the alphabet soup, or is this process off the rails? I suspect the latter - and, at the risk of bragging, but if not now, when? - you heard it hear for the first time anywhere. Thus, I am going to say it: Any rule-making that changes 'voluntary' to 'mandatory', 'required', or 'necessary' is at variance with the underlying enabling legislation. Given the complex and dynamic nature of the process, the introduction of such a requirement is the moral equivalent of a typographical error and usefully should be corrected - typographically. We can discuss more conspiratorial, if not sinister, interpretations in a future post - that's where the real fun begins - but for the present, I wish to be cautious. If any reader can explain this discrepancy, please post a comment and get in communication with me. The matter is complex. Anyone can make a mistake - including a typo - perhaps I have overlooked something. Meanwhile, you can see how this implies a powerful and free market empowering position vis a vis 'certified EHR'. Where did this 'certified' come from? Stand by for update on that position.