How Hard Is It?
By Frank Poggio
Frank Poggio is president and CEO of The Kelzon Group.
In the October 28, 2017 issue of HIStalk, Mr. H made this critical observation and raised an important question. He wrote (finishing with tongue in cheek):
For those with short memories or short healthcare IT careers, it’s time to relearn the oft-repeated lesson that big companies dip their toes into and out of the healthcare IT waters all the time with little loyalty to anyone except shareholders. McKesson bailed out this year and now GE is apparently mulling its exit after wrecking a slew of acquisitions over many years. Siemens is long gone. Nothing good ever comes from conglomerates licking their chops at what they naively think is easy money and higher growth than their other verticals (see also: Misys and Sage). How hard could this healthcare thing be?
GE of course isn’t alone, but they may hold the prize for most kicks at the can. This will be their third time since 1970 — three tries and billons later and nothing to show for it. Ironically, GE has had great success in medical devices, so one could assume they know more about the healthcare business than a Revlon, Apple, IBM, NCR, Martin Marietta, Lockheed, Oracle, SAP, Microsoft, et al.
After some 45 years working in the healthcare IT arena, I believe I have the answer to Mr. H’s query. My qualifications in support of my response are:
- Over four decades, I was a hospital CFO and CIO at a major teaching hospital.
- I spent two intermittent decades as an industry consultant working with healthcare providers and system vendors of all sizes.
- In the middle of my career, after my CIO stint, I founded a HIT startup that built both clinical and administrative systems, went public, and was later acquired by one of today’s major vendors.
- Most importantly, I have designed clinical and administrative software systems, led installations, and written more than my share of program code.
To summarize, I have seen it from all four sides; buyer, builder, advisor, and patient.
There are four reasons that make healthcare IT hard, really hard.
Many people new to the healthcare readily compare it to commercial industry. Why can’t hospitals do as banks, or airlines, or Google, or…?
One reason is they are not organized like these entities. What other industry has as its primary customer the same person that sells and then performs the core services? That same person also defines the product and further determines how it is delivered and implemented. That person is the doctor. The PhDs at GE do not make the final decision on how to make a jet engine or how to deliver it. GE is run by a CEO and the buck stops there. Hospitals are run by a troika (or committee) of the board, the administrative CEO, and the chief medical officer.
In 1974, Professor William Dowling, University of Washington, published the book “Prospective Reimbursement for Hospitals,” which did research on hospital operations. His studies showed that the CEO of a typical community hospital directly controls only 25 percent of the resources and operations. The other 75 percent is controlled by the doctors. They decide what tests to run, when to run them, and what happens next. The fastest way for a CEO to lose his job is to directly challenge the medical staff.
What other industry is organized like this? If you are in the business trying to build and sell million-dollar systems, you had better understand this organizational dynamic and accept the fact it will take years to generate an acceptable return on investment.
All businesses are struggling with regulation. I submit that healthcare far exceeds all others.
Case in point: in what other industry does the payer define the structure and content of the bill down to the very last data element? One that comes closest is the defense industry, and many of its idiosyncrasies are incorporated in healthcare regulations. In 1999, Price Waterhouse CPAs completed an analysis of how many pages in the federal register addressed income tax laws. They compared income tax against the number of regulatory pages need to create a payable UB bill for all payers in a given state. The results were 11,000 pages of regulations for taxes and over 50,000 for a hospital bill.
A further complication is the person receiving the care is not the one paying the bill. Sometimes the patient never sees the full bill, and when they do, they are inevitably confused.
Training, Structure, and Definition
Computer systems thrive on definition and structure. The easiest applications to develop are those where the target domain has a history and library of definition and structure. Lack of definition and structure are a programmer’s nightmare. Today there are many tools to help address gray areas, such a fuzzy logic and neural networks, yet learning and applying these tools significantly raises the complexity of the system, thereby increasing development time and costs.
A doctor’s adherence to medical terminology and structure is highly dependent on which medical school they attended. As an example, a study at the Milken Institute SPH at George Washington University found that physicians whose residencies were in higher-spending regions spent 29 percent more on average than their peers who had trained in lower-spending areas of the country. Different protocols for different regions based on training. The federal government spent $30 billion on EMRs and yet we still have wide gaps in medical lexicons, protocols, and the structure and content of EMRs.
In IT, this is classically called a rolling design, again a developer’s nightmare. But the delivery of healthcare and the practice of medicine are rife with this burden. Medicine is in constant change, with new protocols, test procedures, quality measures, etc. presented every week. Old protocols are challenged on a routine basis, e.g., mammography screening, PSA testing, knee replacements, tonsillectomies, and more.
What if you were assigned to develop a production management system for an auto manufacturer and every month the manufacturing engineers told you that process A — which we coded last month — has now changed to process B? The solution in commercial industry is to freeze the design by freezing the process. Can’t do that in medicine — freeze your protocol and tomorrow it could be the basis of a malpractice suit.
Medicine has always been in constant change, and with personalized medicine around the corner, variation and complexity will grow by leaps and bounds. Scientists have been trying to reverse engineer the human body since the first autopsy a thousand years ago. If only when you were born your mother gave you a 5,000-page human spec sheet with schematics and diagrams, a user’s manual, a troubleshooting guide, and a 1-800 number to call when all else fails. They exist for every car, dishwasher, plane, and other device and sure make software development a lot easier.
When I was a CIO at the end of a difficult IT implementation, the dean of our medical school said to me, “There is a reason we called it the practice of medicine. If we practice long and hard enough, someday we’ll get it right.”
Many of these issues exist in other industries and disciplines. I submit that the depth and interaction to which they exist in medicine and healthcare is what makes IT development hard, very, very hard. All those big companies (and many small) that came into the healthcare industry failed because they did not allow for the depth and interaction of these challenges, and hence they did not prepare for them, lost patience and millions, then chose to cut their losses and run.
From the outside looking in, healthcare is twenty percent of the gross national product, which could support a very attractive business opportunity. It’s a beguiling number which has proved to be siren song for many a big and small firm.