No, you didn’t miss anything, there is no Government EHR. But should there be one? And if so, what should it look like?
The argument in favor of a Government EHR goes something like this: If we have 19 Billion dollars to spend on EHR adoption, why not spend a small fraction of that money and buy or build an EHR and make it freely available to all physicians and hospitals? Not a bad idea. I would add that, if we must, we could spend the rest of those billions on training and supporting physicians in their efforts to computerize their records. So how would a Government go about accomplishing such monumental task?
The first option would be a “fixer upper”. Buy something like Epic, which has both an inpatient and an outpatient EHR, hire a team of software developers and hordes of usability and medical informatics experts and set them down to work on the existing product. A slightly less expensive option, which is frequently mentioned, is to use VistA instead of Epic. After all the Government already spent boatloads of money on VistA and many of its users seem satisfied with the product even in its current state. Epic has many satisfied customers as well. Either way, it shouldn’t take more than a couple of years to have a fairly usable product, migrated to new technologies, scaled down for small hospitals and practices and scaled down even more for patients.
The second option is similar to the process by which the Pentagon acquires new fighter jets. HHS would publish a set of requirements and various vendors would create a prototype and bid for the contract. For an EHR, one would expect the likes of Microsoft, IBM, Apple or Google to lead the pack. For this scenario the Government would be free to specify requirements to facilitate all the data collection the Government may need, and probably base the entire project on a Federal Cloud with Internet access either through a downloadable smart client (e.g. TweetDeck) or plain browser (e.g. twitter.com), or both, as circumstances dictate. We should have something to look at in three years or so and could begin rolling it out in earnest in four.
Either option will overcome most impediments to achieving an EHR for every American. A Federal Cloud containing all medical records will obviate the need of reporting to CMS or any other government agency. A true multi-tenant Federal Cloud will be able to uniquely identify each patient, with a very high level of confidence, and automatically create a National Patient Identifier without all the legislative and bureaucratic hassle. Since all data is managed by one entity, assembling a longitudinal, complete record for each one of us, either persistent or on-demand, will become almost trivial. One database schema, one terminology and a unified user interface would practically guarantee abundant and high quality data points for clinical research. Privacy and security policies, all residing in one place, could be driven by the patient, or consumer, through their own longitudinal, comprehensive view of the medical record. There will be no need for intermediaries and push/pull addressing systems with all the associated complexity. Every doctor, clinician, hospital, insurer, researcher and consumer will be accessing the same data, through the same software, within the scope of various privacy and security policies. And it will all be free.
For all those pulling “1984” out and looking to see if medical records are mentioned there, relax, this utopian EHR is not on the Government agenda at this time. There are as many obstacles to building the Federal Cloud EHR as there are to providing a “Public Option” for health insurance and neither one is politically feasible at this time. There is a large and rather influential Health Information Technology industry which will be summarily killed off by a Government EHR initiative. The need for instant gratification and the greater need for political campaigning material preclude anything with a longer than four years time horizon. Americans have a historical aversion to centralized control and would much rather have multiple smaller corporations control smaller chunks of activities and information, regardless of the administrative costs and pitfalls of such approach.
And then, of course, there is the freedom of choice issue. What if I don’t like the Government EHR? What if I want to build my own, or buy one that suits me better? And what comes next, a Government Automobile? And the right to privacy of both consumers and providers is not far behind. Why should the Government have access to every minute detail of my business? What would lawyers do if the Government would require that all their dossiers be uploaded to a Federal Cloud? What do the Constitution and Bill of Rights have to say about such practice? Certainly this is not what our founding fathers had in mind.
Of all the billions of dollars available for EHR adoption, the Government is timidly allocating $60 million to EHR research activities in areas such as security, usability, clinical terminology and some peculiar concept of making EHRs more like iPhones. I have very little hope of anything tangible materializing from any of these research programs anytime soon. In the meantime, tax payers, physicians and various providers of health care services, are spending billions of dollars on “fixing”, deploying and interconnecting fragmented software systems perfectly matching our equally fragmented insurance and health care delivery system. With enough duct tape, strings and wires, we should be able to pull something together. We’ll fix the rest later….
Margalit Gur-Arie blogs frequently at her website, On Healthcare Technology. She was COO at GenesysMD (Purkinje), an HIT company focusing on web based EHR/PMS and billing services for physicians. Prior to GenesysMD, Margalit was Director of Product Management at Essence/Purkinje and HIT Consultant for SSM Healthcare, a large non-profit hospital organization.
What you want in your last comment is simply what needs to happen. I see little reason why it shouldn’t or couldn’t happen. The fact is, current vendor solutions can continue using and developing their innovative, proprietary E.H.R. products – but there would always be a basic standard set of transfer, database, and identifier protocols to which all vendors must develop patches / translations for, say, CMS-accredited HIE transactions. If you want to use alternative HIEs, fine; if you want to participate in silos, fine. You just have to make a core set of data compatible with the CMS standard if you want an NHIN address / credentials, participate in the VA’s HIE processes, or (if you’re a silo HIE) transfer files to and from any public HIE. VistA seems to make the most sense for the reasons I and others describe above. How can we work toward this solution?
“why hasn’t this product that is freely available via a FOIA request been more widely adopted?”
Because it is not “free”.
I still have to pay for the servers to install it on, the third party software licenses it requires, the development of custom interfaces to all those “standardized” pharmacies, labs, hospitals, imaging centers, etc., the “IT guy(s)” and the “developer guy” for any maintenance/enhancements I want/need, the clearinghouse, the clinical content/codes and so forth.
By the time I add it all up I spent as much money as I would have spent if I bought a commercial product, plus 5 times as much of my precious time, and I end up with a “one off” poorly tested version of an aging product which is in the process of being rewritten by the VA.
I want the ability to sign up on line, by virtue of having an NPI, and start using an EHR right off the bat. And as I start using it, all the data from my colleagues is immediately available to me for all my patients, on demand. No worries about whether I say “tomahto” and you say “tomaeto”… One schema, one terminology, one standard. Not necessarily one physical database. No bills in the mail either.
I believe the Dept. of Veterans Affairs did just that, or something similar, with the VistA program. Here is a link to other adopters (Federal Agencies) that utilize VistA. Here is a link to non-federal adopters.Perhaps the real question to be asked is “why hasn’t this product that is freely available via a FOIA request been more widely adopted?”
Thanks for the clarification! AHIMA provides a neat article talking about just that, the harmonization of standards and terminology. Specifically they mention the collaboration betweenHL7 and the CDISC (Clinical Data Interchange Consortium) to provide a set of harmonized, useful standards. Also of interest is the Joint Initiative Council’s Joint Initiative on SDO Global Health Informatics Standardization. I don’t see why what you invision could not be accomplished through the private sector. Indeed, my preference would be to see the private sector consortia develop the standards for the data elements and terminology. The eBusiness standards (ASC X12, xCBL, cXML, ebXML, etc…) are good examples of the private sector initiatives that have yielded wide spread use in industry. Nearly every piece of “middle ware” supports some or all of these standards. Some of the more powerful ERP, CRM, and SRM software applications available to businesses provide integrated support for these standards. Otherwise, the support is available through additional modules in some instances.
Gary, this may be true now, but it doesn’t have to be that way.
Electronic Medical Records have a lot to offer to consumers. They can offer access to perform simple transactions like making appointments, requesting medication refills, paying bills, printing out school physicals and immunizations lists, all without the need to wait on the phone or drive to the doctor. They can also offer the convenience of having the patient and any care giver look at the records and keep an eye on what is going on, or share with another provider for a second opinion.
From a care coordination and evidence based medicine perspective, EHR can reduce the need for duplicate testing and unneeded procedures. Finally, if all goes well, and it eventually has to, EHR and clinical data exchange could improve care by better informing both health care providers and recipients. If all goes fantastically well, we may see some efficiency gains, which may ultimately drive unit costs down (not holding my breath for this one).
We have a long way to go for all this to happen…
Electronic Health Records Software does nothing for the consumer except to require Hospitals to pay hefty prices to pass on to the Consumer. Free Markets are only innovative when it has large sums of profits to soak their customers with inflated,overrated and extravagant products that have more bugs than Microsoft.
Electronic Records also include extravagant maintenance Contracts that latches onto their Host like a Die Hard Parasitic Growth.Loaded with long-term experimentation at the expense of the Facility. Which in turns becomes a Consumer Expense. Electronic Health Records are no more progressive than government software. The only difference is the vastness of wealth consumed for inferior Products!
Thanks for the post about EHR and its implementation in healthcare industry.
ciphertext is off on some fantasy planet – other than Earth that is, presumably with Nate.
The reference to the possible, likely in fact, RFP for an EHR for the Department of Homeland Security provides a good starting point for a prototype for a federal-government website with a variety of FOSS EHR product, so I think it is something worth pursuing. More appropriate that responding with a FOSS proposal to an RFP for a State HIE in any case.
ciphertext, I just thought it worthwhile to ask the questions. I am not claiming to have the answers.
As to the Government competing or selling EHR, I don’t think it should. If they ever commission one from a private company, or actually endeavor to build one “in house”, the EHR should be provided free to providers as a SaaS offering. I don’t see a need for penalties either. Incentives work much better.
This does not preclude a private company from building a better mouse trap. The only caveat would be that the “private” EHR would have to be able to exchange data with the “public” one in order to provide any utility to its users. In fact, it would just be a front for the “Federal Database” (that is another thorny question).
Administrative costs in this context are all the millions of dollars spent on standards harmonizations and on reinventing the terminology, interoperability and communications wheels across multiple government agencies and private vendors.
The pitfalls are evident in the fact that our EHRs are still largely disconnected and suffering from incompatibilities that will make it very hard to construct one coherent and complete record per person.
I don’t believe that would be a viable option in a capitalist economy. Monopolies, whether public or private, are seldom tolerated. There is no incentive to improve upon a product when there is no market feedback. Monopolies are deaf to that feedback because they ARE the market for all intents and purposes. While regulations can impair or clarify the market’s performance (depending on the goals of the regulation and how they are crafted), monopolies will destroy a market.Their are two routes, in reality, that the government could follow in this scenario. This would be regardless of whether the government purchased a software product or developed their own.The government releases a product into the market thereby competing against other producers for a piece of the market share.The government releases a software product to a particular industry and mandates its use within that industry with penalties assessed for non-compliance.Neither of these scenarios bode well for the market or the tax payer in general.
In the procurement process you describe, the government is contracting with the private sector to provide them (government) products and services that would be consumed by the government. Essentially this process already occurred with VistA. The difference between what you are suggesting and the scenario you describe is for whom the product and services are procured. I don’t believe Google, Apple, Microsoft, or IBM would be leading the charge to develop a product that the government could then sell in the market place. If those companies so chose, they would (and indeed might be considering the prospect) develop their own versions of eHR software to compete in the marketplace. This scenario, presupposes that the government would compel by regulation and threat of penalty the use of a particular product. In the example you provided you listed government at “consumer” of the market. However, your posting implies government as a “provider” to the market.
I agree, but on the whole, history has shown that the overall economy of a nation devoid of central planning or operating with fewer, socialist, market concepts is much stronger than one which is centrally planned or incorporates entitlements which encumber the participants of the market. I’m not sure how you would compare the “administrative costs” of a centrally planned economy to the “administrative costs” of a free market economy. How do you define “administrative costs”? I don’t know what you mean by “pitfalls” either. Are you speaking of the overall economy or maybe of a particular market or segment within the economy?
The Indian Health Service has already taken VistA and scaled it to fit small and medium sized care facilities – apparently successfully. There is just no political will in this country to support an open programming solution to health IT in the private sector. As long as health is more business than public good, poor public well-being will be an economic anchor on the US. A sad failure of our system.
Great post Margalit.
Here is my concern with a pure Open Source paradigm for something of this magnitude: There will be many organization that will engage in customization to the point where the branches may become incompatible with each other and with the original trunk.
If the schema is centrally managed, we will gravitate towards Dr. Walker’s suggestion rather quickly. Perhaps this is a good thing, but I am not sure. What do you guys think?
On a different note, here may be a good place to start experimenting with Open Source – The Homeland Security folks are looking for an EHR for illegal aliens….
Any FOSS team care to apply? 🙂
We need less a complete standardized EMR / EHR than a standardized transfer protocol, NPI, MPI authentication programs, and standardized data sets / parameters. Why not an NHIN health Internet using VistA transfer schemes / fields and any EHR vendor of choice for the ‘browser’? This simplistic approach solves problems of interoperability as well as unbundles the EHR from the EMR and practice mgt system, and prevents the perverse use of HIT as a means for power entities to control subordinate entities.
I think a lot of people assume that most of the work on free open source software is done by volunteers. The real situation is that a lot of people are paid to work on FOSS. For example many large companies such as HP and IBM have literally thousands of programmers who are paid to work on free open source software.
If the government paid programmers to develop/enhance FOSS, it would speed development and be a much better use of funds. It wouldn’t take a lot of money (out of the billions) to improve FOSS.
“make sure we are not depending only on freely donated time from the Open Source community.”
Not necessary and maybe not even advisable. The FOSS development paradigm, as I note above, is a very well established one.
If for some reason the normal development process does not materialize satisfactorily, then more financial resources could be devoted to development. A number of committers who are compensated if need be.
The paradigm has proved itself many, many times over however. The results are arguably superior to comparable commercial product. The weakness in the paradigm tends to be documentation of all kinds, so that is an area where governmental resources could be profitably applied.
Both products listed above are comparable to any commercial product by the way.
True that the open-source characteristic is not crucial, but it makes sense to offer it. Access to an existing API is necessary.
Thanks, Wendell and Mark.
I think FOSS is a great idea, but I would still like to see HHS or ONC take charge of the project and make sure we are not depending only on freely donated time from the Open Source community.
I have seen the available FOSS products and I believe there is much work to be done before they are ready to be rolled out on such large scale.
Not sure that Open Source should be an absolute requirement. I would be happy with any good product, an open API and a Federal commitment to patient safety, usability and clinician involvement in all stages of development.
Great post, Margalit!
This is something that seems like a “no brainer” but was surely blocked by all of the corporations that believe in the “free market” but want to avoid competition.
I’ve often wondered why more physicians don’t adopt free open source software and invest their costly “customization” fees in the software where their colleagues can benefit. I have worked in developing countries for many years on health information systems and see the same thing. Contractors working for international aid agencies reinvent the wheel and create an unsustainable (and often dysfunctional) software system that collapses as soon as the grant is finished.
There are many good free open source EMR software packages suitable for use in the US available (mentioned in previous posts). You won’t have an expensive salesman talk you into buying one like you will with the proprietary systems but you can find competent people who will help you implement the system as well as a community of users who are usually happy to help with questions. You can adopt these free open source systems (and pocket the difference in the cost from the government payments). It’s just a shame that the government doesn’t do more to promote these systems. It would be a much better investment of the money.
The last things he health insurance and drug companies want is an integrated EMR and billing system. This would reveal medical and clinical outcomes and put the drug and insurance companies which exist mainly on government subsidies (part D, medicare advantage). If name brand drugs and private health insurance companies are more expensive than generic drugs or government insurance companies such as medicare, then the need for either redundant name brand drugs or private insurance companies will be questioned. Therefore, the drug and insurance lobbyists pay off our congresspeople to insure that no government money is spent on single emr integration. In addition to revealing clinical outcomes, a single emr and billing system under single payer health insurance company would allow real time tracking of billing fraud. Alas, with Bacus having receive over $4,000,000 in payments from the health insurance lobby, there’s no way we’ll ever see integrated EHR.
Keep up the great postings, Margalit! But you already know that I am fan.
“A slightly less expensive option, which is frequently mentioned, is to use VistA instead of Epic.”
HHS, CMS or ONC could easily “sponsor” a website where various FOSS products could be made available for download and improvement. Or one of the departments could work with The Apache Foundation, or another similar entity, to sponsor development.
PatientOS (Java/PostgresSQL-based) and openEMR (PHP/MySQL-based) are two FOSS candidates I normally recommend for a start.
The only cost on the part of the federal government aside from negligible hosting costs would be almost equally negligible cost of having comprehensive training/implementation manuals produced for any of the FOSS. Software development would follow the normal open-source development paradigm with a number of committers and any number of improvers of the software.
As is the usual case with similar FOSS projects, those with expertise in the FOSS would provide implementation and maintenance of the systems for a fee to any user with a need for that expertise.
Well-trod ground and a highly effective, extremely low-cost paradigm.
I believe the developer of PatientOS, Greg Caulton, has expertise in Cerner system development. He developed PatientOS as a significant improvement on the design and fucntionality of the Cerner hospital systems which he found to be unnecessarily difficult to maintain and install.
PatientOS is implementable in physicians practices as well without overkill, whereas there are few implementations of VistA in such settings. The only effective implementation I am aware of is at a multi-office community healthcare facility in the Phoenix area, Clinica Adelante, but there may be others by now.