Cloud Computing and Other Buzz Words

The technology that drives health care today is changing in response to increase concerns about security and reliability, and external regulations like the security regulations in HIPAA.  In addition, the HiTech portion of the stimulus law this year has provided incentives for health care providers to adopt technology that allows for health data exchange and for quality reporting (which is a data driven process for providing outcome reporting for certain quality measures as defined by the Secretary of Health and Human Services).  There are a fair number of technology vendors that provide electronic health records (EHR) systems today, and also a fair number of vendors that have developed business intelligence or more sophisticated data reporting tools.  Health data exchange is a newer field; google and Microsoft have begun developing systems that allow users to establish a personal health record database, and some states have started planning for larger scale data repositories, but this concept is still at its beginning stages.

A buzz word today in technology is “cloud computing,” which is a fancy way of describing internet systems that businesses can rent from service providers to perform business tasks.  The idea is not new, even if the buzz word is; in days of yore, we called these “application service providers” or ASP’s for short.  I suppose that the IT marketing folks got sick of being compared with a nasty snake and thought clouds were better (or maybe more humorous if they had ever read Aristophanes).  Of course, the perjorative “vaporware” which roughly translates to a software vendor that markets a product it does not yet have to actually sell to people, also rings of clouds and things in the sky.  And the old “pie in the sky” as a way of saying “that’s a nice idea but has no hope of being useful down here where mere mortals live” could also relate to clouds.

That aside, there may be something to cloud computing for us mere mortals.  One of the important aspects of technology is how complex it actually is under the covers, and the degree and scope of support actually required to get the technology to work properly.  Larger businesses that have high concentrations of technology engineers and analysts are better equipped than the average business to deal with technology issues.  In this respect, cloud computing offers a business a way to “leverage” (another business term thrown casually around) the expertise of a fair number of technology experts without having to hire all of them on full time.  One of the dilemmas for business consumers, however, is the amount that one needs to be able to trust the technology partner they rent from.  This is the same problem that ASP’s originally faced years ago.  What happens to the data in the cloud when the cloud computing vendor either stops providing the service you are using, or just goes out of business?  How do the businesses work together on transitioning from one cloud to another, or from the cloud back in-house?  What if the business wants to host its own cloud onsite or at its existing hosting facility?  How are changes to the hosted application controlled and tested?  How often are backups performed, how often are they tested?  How “highly available” is the highly available system hosted?  How are disasters mitigated and what is the service provider’s disaster recovery/business continuity plan?  How are service provider staff hired and what clearance procedures are employed to ensure that staff aren’t felons that regularly steal identities?  The list of issues is a long one.

The other dilemma for businesses that want to use cloud computing services is that many of these services have a standard form contract that may not be negotiable, or essential parts of it may not be negotiable.  For example, most cloud computing vendors have hired smart attorneys who have drafted a contract that puts all the liability on the customer if something goes wrong, or otherwise limited liability so severely that the business customer will need to buy a considerable amount of business insurance to offset the risks that exist with the cloud, should it ever fail, rain, or just leak into the basement.

On the other hand, businesses that have their own IT departments have the same set of risks.  The difference, I think, is that many businesses do not have liability contracts with their otherwise at-will IT staff.  So, if things go horribly wrong (e.g., think “negligence”), the most that might happen to the IT person responsible is immediate termination (except in cases of intentional property theft or destruction, both of which may lead to criminal but not automatic civil liability for the IT person involved).  How much time does a business have to invest to develop and implement effective system policies, the actual systems themselves, and the staff to maintain those systems?

The advent of more widely adopted EHR systems in the U.S. will likely heat up the debate over whether to use cloud computing services or virtualized desktops that are hosted centrally by a hosting company in order to roll out the functionality of these systems to a broader base of providers (currently estimated at 1 in 5 presently using some EHR).  Companies that can cost less than the Medicare benefit to providers while helping providers comply with the security regulations will likely have the most success in the next few years.  Stay tuned!

EHR & HiTech – More Money for More Health Records

The American Recovery and Reinvestment Act (ARRA) of 2009 has a number of provisions to encourage the expansion and further implementation of electronic health records for the purpose of increasing efficiency in the health care system while hopefully lowering costs.  The  Office of the National Coordinator for Health Information Technology (see website) has established a two-part strategic plan for expanding the installation of health records systems throughout the U.S.

Section 4101 of ARRA descibes the incentive payment process through the Medicare program for eligible professionals that are a “meaningful EHR user,” as that term is defined in subsection (o)(2) of the amended section 1848 of the Social Security Act (cited as 42 U.S.C. 1395w-4).  The tortured definition provided within the statute has three basic requirements: (a) the certified EHR is being used in a “meaningful” manner to the satisfaction of the Secretary, (b) the EHR is connected to some “electronic exchange of health information to improve the quality of health care”, and (c) data is submitted to the Secretary on clinical quality measures on a regular basis.  The data to be submitted to the Secretary is to be governed by contract between Medicare and the provider, and such proposed measures must go through the public notice and comment period in the Federal Register – similar to other proposed regulations under federal law. 

The incentives payable to eligible providers are spread out over five years, with a maximum amount of 18,000 (if starting in 2011 or 2012), otherwise 15,000 that first year.  That is, unless the first year of adoption of the EHR by the provider is after 2014, which in that case the provider is not eligible for any incentive at all through this section.  So, a provider that adopted a certified EHR in 2011, demonstrated that: (a)  he was using it in a meaningful manner, (b) connected to a data exchange, and (c) produced data to the Secretary as required, would be eligible for payments in total of $44,000 over a five year period starting in 2011 (18,000 in 2011, 12,000 in 2012, 8,000 in 2013, 4,000 in 2014, and 2,000 in 2015).

If instead the provider did all the above, but did not start until 2013, the first payment in 2013 would instead be 15,000, for a total of $41,000 over the five years 2013-2017.  Sadly, if the provider did all of the above for the first time in 2015, they would get bupkis.

Health IT & Open Source

The truth is that I may just be getting annoyed about this debate.  A recent blog posting on Wired (click here for the article) frames the debate over health technology in terms of open source versus legacy or proprietary code, the latter being the enemy to innovation, improved health outcomes, and usability.

First off, an open source program is merely governed by some version of the GPL, which means that other developers can reverse engineer, make derivate works, or otherwise include your open source code in their subsequent open source code.  Developers that freely work together to write something cool are developers writing code.  They aren’t necessarily health experts, physicians, efficiency gurus; in fact, they may not even have health insurance if they live in the U.S. (1 in 6 of us are uninsured).  The fact that code is open source does have a big impact on how U.S. copyright law protects the work, but it doesn’t mean that somehow an open source developer is more in tune with health IT requirements, how to best integrate the system into a physician’s practice, or even necessarily what the actual requirements are for a physician to see a patient and document the visit to avoid liability for fraud or malpractice.  That’s because for developers, requirements come from outside of the development community, from users.

And guess what – proprietary developers of software listen to their user community to understand their requirements.  It’s part of the job of developers, regardless of whether the code is open source or proprietary.  And, for everyone participating in the global economy, the people that pay for your product generally drive the features and functionality in it.  If you can’t deliver, then your user base will go find someone else who can deliver.

Now, for larger health organizations, health records systems are a multi-year investment.  This inherently locks that health organization into a longer term, and more conservative, relationship with their health IT vendor, which tends to reduce the amount of change introduced into a health records system over time – especially for the larger vendors that have a lot of big clients.  The little developer out there writing code at 3am is certainly going to respond to market changes far more quickly than a really big corporation with a health IT platform.  But you know what?  Try getting the little guy to support your 500 desktop installations of his software 24×7.  Do you really think he can afford to staff a help desk support function around the clock for your business?  What happens when he has two customers with emergencies?  Or he wants to get some sleep?  And what about change control?  Even big vendors stumble in testing their code to make sure it works and is secure before releasing it (think Microsoft).  Solo, open source developers, even working in informal teams, are going to miss at least as often as a larger vendor, and introducing a lot more changes just increases the frequency that an untested change becomes an “unpublished feature” aka “blue screen of death.”  Trust me on this one: the health care user base is not going to be very tolerant of that.

Repeatedly, I hear the refrain that this stimulus money is going to go to systems that can be put to a “meaningful use,” and that is going to exclude rogue open source Health IT developers from being funded, squelching innovation in the market place.  I imagine that complying with the security regulations under HIPAA probably hinder innovation, too, but they increase the reliability of the system vendors that remain in the market place and reduce the risk to the data of patients that might be in their computer systems.  Setting minimum standards for health records systems may favor incumbent systems, but honestly – is that so wrong?  Isn’t the trade off here that when someone buys a system that is certified, they can have the satisfaction of knowing that someone else without a vested interest in the product, thought it had certain features or a proven record of delivering certain outcomes?  Perhaps the certifiers aren’t neutral because they come from the industry of EHRs, but if I recall correctly, the people that run the internet have committees with representatives from the internet industry, yet I rarely hear that the standards for the POP3 protocol unfairly burden new or open source developers.

That someone set standards for EHRs like a government agency is a lot like the government setting the requirements for you to receive a driver’s license.  Everyone who drives needs to understand what the red, octogonal sign with the capital letters S T OP means.  On the other hand, you may never parallel park again, but you better learn how to do it if you want your license to drive in Maryland.   Standards are always a mixed bag of useful and not-so-useful rules, but I don’t think there are too many people out there arguing that the government should not set minimum standards for drivers.  A certification requirement for EHRs to establish minimum standards is no different.  Ask the JCAHO people about it.  Ask the HIPAA police.  Ask the IT people you know.  If you are going to develop an EHR, you better secure it, make sure the entries in the database are non-repudiatable, and have a disaster recovery approach.  Don’t know what these things are?  Do your homework before you write a computer system.

Now, another refrain has been that look at how all of these proprietary systems have failed the world of health provisioning.  For example, look at how more kids died at the Children’s Hospital ER in Pittsburg after the hospital implemented an EHR (I can feel a class action lawsuit in federal court).  Who implements EHR’s in ER’s?  So the doctor is standing there and a patient is having a heart attack.  What should the doctor’s first act be?  To register the patient into the EHR and record his vitals?  I would think the doctor should be getting out the paddles and worrying about the patient’s heart beat, but then, I am an attorney and systems guy, not a physician.  Look – dumb decisions to implement a computer system should not lead to subsequent critics blaming the computer system for not meeting the requirements of the installation.  EHR is not appropriate every place patients are seen or for every workflow in a health care provider’s facility.  No knock on the open source people, but I don’t want my ER physician clicking on their software when I am dying in the ER, either.  I don’t want my doctor clicking anything at all – I want her to be saving me.  That’s why I have been delivered to the ER.

Now, VistA is getting a lot of mileage these days as an open source, publicly funded, and successful example of EHR in action.  And it is free.  But in fairness, VistA is not a new piece of software recently written by three college kids in a garage somewhere in between World of Warcraft online gaming sessions.  This program has been in development for years.  And “free” is relative.

For example, if you want support, you need to pay for it.  If you want to run it in a production environment, you will need to buy equipment and probably get expert help.  If you want to implement it, you will need to form a committee, develop a project plan, implement the project intelligently with input from your users, and be prepared to make a lot of changes to fit this system (or any system) into your health facility’s workflows.  And if you find yourself writing anything approaching software, that will cost you something, too, as most health care providers do not have a team of developers available to them to modify any computer system.  So, “free” in this context is relative, and genuinely understates the scope and effort required to get any piece of software to work in your facility.  “Less” may be a more appropriate adjective.  But then, that’s only true if you can avoid costly modifications to the software, and so far, there is no single EHR system that works in every setting, so expect to make modifications.

That’s my rant.  Happy EHR-ing!

The Battle Over Health IT Has Begun

The battle lines on how to spend the money for technology to improve health care are beginning to be drawn.  As a former director of an IT department at a health center which implemented a proprietary health record system in 2003, I can offer a useful perspective on some of the issues.  Phillip Longman’s post on health records technology discusses the issue of using a closed versus an open source health records system, which is part of the larger debate on open source and its impact on application development online.

I’m generally a fan of the open source community.  The shareware people were developing useful applications and offering them to the public ever since I started using a PC as a kid back in the 80’s.  There is a lot to be said for application development that is done in a larger community  where sharing is ok.  For example, my blog is a WordPress blog, which is an open source blogging software which provides a platform not just for writers like me, but also for developers to create cool plugins for WordPress blogs that do all sorts of nice things like integrate with Google Analytics, backup your blog, or modify your blog’s theme, just to name a few that I happen to use regularly (thanks all of you that are linked to).

In 2003, we looked at a number of health records systems, ultimately allowing our user community at the time to choose between the two finalists, both of which were proprietary systems.  One of my observations at the time was that there was a wide array of information systems that were available to health care providers, some of which were written by fellow practitioners, and others that were written by professional developers.  I would be willing to bet that today there are even more health IT systems out in the market place.  We ended up going with a product called Logician, which at the time was owned by MedicaLogic (now a subsidiary of the folks at GEMS IT, a division of General Electric).

Logician (now called Centricity EMR) is a closed source system that runs in Windows, but allows for end users to develop clinical content (the electronic equivalent to the paper forms that providers use to document care delivery) and to share that clinical content with other EMR users through a GE-hosted web site for existing clients of the system.  In addition, Logician has a substantial following to support a national user group, CHUG, and has been around long enough for a small cottage industry of developers to create software to integrate with Logician (such as the folks at Kryptiq, Biscom, and Clinical Content Consultants who subsequently sold their content to GEMS IT for support).

After six years of supporting this system, I can assure you that this technology has its issues.  That’s true, of course, of all most information systems, and I would not suggest that the open source community eclectic collection of developers is necessarily any less buggy or any easier to support.  And, in fact, I don’t have any opinion at all as to whether health records would be better off in an open source or proprietary health record system.  Health professionals are very capable of independently evaluating the variety of information systems and choosing a system that will help them do their jobs.  One of the big reasons that these projects tend to fail is a lack of planning and investment in the implementation of the system before the thing gets installed.  This process, which, when done right, engages the user community in the project to guide it to a successful go live, is probably more important and actually takes more effort than the information system itself.

Mr. Longman criticizes the development model of “software engineers using locked, proprietary code” because this model lacks sufficient input from the medical users that ultimately must use the system in their practices.  I suppose there must be some health records systems out there that were developed without health provider input, but I seriously doubt they are used by all that many practices.  I do agree with Mr. Longman that there are plenty of instances where practices tried to implement a health records system and ended up going back to paper.  We met several of these failed projects in our evaluation process.  But I would not conflate proprietary systems with the failure to implement; proprietary systems that actually include health providers in their development process can be successfully implemented.  Open source can work, too.  As Mr. Longman points out, the VA Hospital system has been using an open source system now called VistA which works for the VA hospital system’s closed delivery system (patients at the VA generally get all of their care at a VA institution and rarely go outside for health care).

My point is that the labels “open source” and “proprietary” alone are not enough to predict the success or failure of a health records system project.  Even a relatively inexpensive, proprietary, and functionally-focused system that is well implemented can improve the health of the patients served by it.  There is a very real danger that the Obama administration’s push for health IT will be a boondoggle given the scope and breadth of the vision of health IT in our country.  But the health industry itself is an enormous place with a wide variety of professionals, and the health IT market place reflects this in the varied information systems (both open source and proprietary) available today.  I would not expect there to be any one computer system that will work for every health care provider, regardless of who actually writes the code.

Obama & Health Care IT

President Obama’s plan (published here) (the “Plan”) describes a multi-part approach to expanding the amount of health insurance available to those without insurance while attempting to reduce the costs of providing health care to Americans.  A portion of this plan involves the expansion of health information technology to help reduce the costs of administering health care.  On page 9 of the Plan, paper medical records are identified as a health care expense which can be reduced through records computerization.  The Plan cites a study by the RAND group (published here) (“RAND”) that indicates that the processing of paper claims costs twice as much as processing electronic claims.

Estimated Savings and Quality Improvements by Adoption of Health IT

The RAND group suggests that fully implemented health IT would save the nation approximately $42 billion annually, and would cost the nation’s health care system approximately $7.6 billion to implement.  RAND at 3.  According to their review of the literature on health IT adoption, approximately 20% of providers in 2005 had adopted an information system (which may have several meanings from patient reminder systems to clinical decision support).  RAND at 20-21.  Full implementation of health IT would require a substantial number of providers to convert to regular use in order for the total savings identified by RAND to be realized.  RAND estimated that in 2005 there were approximately 442,000 providers in the U.S.; this suggests that about 353,000 providers would need to convert from paper to electronic systems before the full savings to the health system would be realized.  RAND at 20.

Areas of savings in the outpatient setting noted include: transcription, chart pulls, laboratory tests, drug utilization, and radiology.  RAND at 21.  Areas of savings in the inpatient setting noted include: reduction of unproductive nursing time, laboratory testing, drug utilization, chart pulls and paper chart maintenance, and reduction of length of stay in the hospital.  RAND at 36.  Savings on the inpatient side account for approximately 2/3rds of the total savings, and the largest area of annual savings is tied to the reduction in the length of stay of patients as a result of the adoption of health IT.  Id. This overall cost savings is based on adoption of health records by virtually all health care providers in a 15 year period; the total savings to the health system during that time would total about $627 billion.  Id.

The Plan also discusses increasing the quality of health care delivered to all patients through the implementation of disease management programs (which are driven by health data of individual patients to monitor progress and outcomes), and the “realignment” of provider reimbursement with quality outcomes.  Plan at 7.  Realignment typically occurs when health insurance plans pay not for the total visits billed by a provider, but based on some kind of quality measure that tracks how well patients are doing in managing their health condition.  This is also driven by the availability of reliable health outcomes data (for example, the hemoglobin a1c test results of patients with diabetes over time, and the percentage that report a result under the “normal” or expected value).

The Trouble with Adoption of Health IT

Adopting health IT systems, however, is no small feat.  Systems have been available to the health care infrastructure for a substantial period of time (Centricity, a health information system now owned by General Electric, was originally developed by Medicalogic in the mid-80’s and became popular in the 1990s).  See Article.  In 2000, Medicalogic had penetrated the practices of about 12,000 physicians in the U.S., or around 3% of the total market, and was described then as the market leader in electronic medical records (which perhaps a total of 10% of the market had adopted a system by that time).  Using RAND’s analysis, five years passed and 20% of physicians had adopted some form of health IT.

If market penetration is to double every five years, by 2010, 40% of physicians should be using a health IT system, and by 2015, 80% should have adopted such a system.  (Admittedly, this assertion is weak because there is not sufficient data in this article to support this assertion.  In addition, adoption rates tend to follow a parabolic rather than a linear pattern, so that larger numbers of adopters join the crowd as time progresses.  But, dear reader, please feel free to comment with specifics to help improve the quality of this article!)

The New England Journal of Medicine, with a likely more restrictive definition of health IT, found that less than 13% had adopted such a system as of 2008, based on their sample of 2,758 physicians.  Article here.  An article in the Journal of Evaluation of Clinical practice reported that about 18% of the practices it surveyed (847 in total) had an electronic health record in use in 2008.  Article here.  (“JECP”)  As RAND had pointed out in its own literature search conducted in 2005, the definitions of health IT vary widely across the empirical surveys conducted, so an accurate estimate of market penetration is hard to come by.  However, it does appear that the number of practices that have adopted general health IT is not significantly higher than in 2005.

An interesting article suggested that some of the problem with health IT adoption may be regional – that some regions of the country tend to have a slower adoption rate of technology in general, which would tend to slow down the adoption of health IT in those areas.  Article here.  The JECP survey also indicated that specialty practices and smaller practices tend to be slower to adopt health IT as compared to their primary care provider counterparts.  Access to adequate capital to fund health IT purchases is an obvious reason for not implementing such systems.  Id. I would also posit that the adoption of health IT does not generally distinguish health care providers in the market of health care delivery (physicians don’t advertise that they have a health record system).  It would be interesting if patients could receive information on average health outcomes by physician when researching who they want to use for medical services (only possible if health IT is widely adopted and there is general consent to the publication of such data, which today is putting the cart before the horse).

There is, therefore, a market failure in that, if we accept that health IT reduces medical costs or improves outcomes over time, the market has not made a concerted effort to adopt this technology.  The Plan puts forward capital to help implement records and has an incentives component that rewards improved health outcomes.  Time will tell if these investments and market changes will actually reduce health care costs in the U.S.

Maryland Health IT

The governor is poised to sign a Maryland bill into law this week on health information systems.  Click here to see the Baltimore Sun article.  The bill was known as HB706 on Electronic Health Records – Regulation and Reimbursement, was adopted by the House and State Senate by April 10, 2009.  The Act empowers the Maryland Health Care Commission to establish a health information exchange in the State, and to develop regulations that incentivize providers that use an electronic health record.  The incentives are required to have monetary value, and may include such things as increased reimbursement for specific services, lump sum payments, gain-sharing arrangements, and rewards for quality.  Click here for the full text of the enrolled House Bill. By 2015, the bill also anticipates that health care providers will be using an electronic health record that is nationally certified and capable of sharing information with the State’s health information exchange.

I think this is an interesting development for health care providers.  Most estimates that I have seen show that a majority of health care providers do not use computerized records for keeping track of patient care.  The records systems are relatively expensive (at least in the short term for software licensing, equipment, and the like), most providers are not techno-geeks, there are serious technical security issues that have to be managed (such as those promulgated under the HIPAA security regulations), and in the short term providers are not likely to become more productive or see a substantial increase in revenue from the investment.  This bill, once signed into law, will start to pile on incentives for providers to move to an EHR, particularly if a provider can begin to demonstrate improvements in the quality of care delivered to patients.

The bill also presumes that there is value in a standard health information exchange, which I imagine would act as a clearinghouse for authorized users to access or analyze health information on Maryland residents.  Beyond the obvious privacy concerns (employers firing or not hiring employees with expensive health conditions), having such sensitive information in one place will require a substantial investment in protecting that data from unauthorized access or theft.  I think it is interesting that the State is not just letting the free market address the need for these kinds of information exchanges – Google and Microsoft have both put products in the marketplace for individual consumers to manage health information.  Arguably, such a large scale effort to place all Maryland patient information into a single repository may exceed the resources of private investors or companies expecting to profit from the repository’s development.  The open question is what value such a repository will actually have to individual patients whose data is “on deposit.”  Stay tuned!