John Halamka published a blog post titled “The Draft FY10 IS Clinical Systems Plan” regarding Beth Israel Deaconess Medical Center last week. CIOs at health systems always have a long list of projects and a finite amount of resources. It was sobering to read that BIDMC won’t have a big bull’s eye on data warehousing, however there was funding for decision support in the plan for the following areas:

• Implement Performance Manager reports and dashboards as needed to support
  organizational needs.
  

  Implement clinical data marts as needed to enable quality measurement, pay
  for performance goals, and other decision support needs.
  

  Enhance the Community Provider Index to better support Health Information
  Exchange via NEHEN gateways.
  

  Implement enhancements to the Patient Activity Profile to support enhanced
  reviews required by JCAHO.
  

  Enhance SOAR (Accounts Receivable workflow) to support denial tracking and
  appeals workflow
  

  Explore the introduction of new Business Intelligence tools as funding
  permits
  

  Support Cactus and NEHEN Express users

Dan Housman
Managing Director, Analytical Applications

Labels: Quality Reporting

Imagine for a moment that the government issued a mandate that required consumers to pay a significant portion (75% or higher) of all healthcare costs out-of-pocket.

This is a serious reality for many tourists who arrive in the United States from foreign countries without insurance, but with a reasonable bank account, and a need for care.

When this occurs, a provider must not only explain the options available, but also the cost of each to the patient. Procedures are then chosen based on a balance between cost and a desire for the highest quality outcome.

Among the challenges providers struggle with is how to explain the cost of a procedure in marketing materials or during a consultation visit. This isn't quite as simple as one might think, e.g. determining the cost of a colonoscopy. The total cost to the patient has a real chance of including the removal of polyps and a need for a secondary colonoscopy. The patient visit also includes underlying services beyond the core procedure; and the cost of these additional activities must be accounted for.

This situation warrants the need for procedure pricing that is averaged for high and low costs based upon potential episodes. Packages need to be established with pricing and options clearly communicated to allow for consumer choice. A handful of health systems are now attempting to cater to this market using simple analytics to support pricing models.

In contrast, the decision-making of an insured patient differs tremendously. They either do not worry about the cost of a procedure or they choose the opposite of the lowest cost. And why not? If a patient is fully covered for a colonoscopy with the option of either a $3,000 or an $8,000 procedure, they will likely choose the more expensive option under the assumption that it is superior care.

At the moment I am scheduling my own dental care for 4 crowns to minimize out-of-pocket expenses. My dental insurance plan has a maximum annual coverage limit, thus I make medical decisions based upon what I must pay. It appears that dental insurance is more efficient than health insurance in this way. It encourages consumer behavior, but generally covers maintenance and prevention activities.

Now imagine that competition on price became a leading healthcare issue, created by consumers forced into out-of-pocket buying decisions. Perhaps a price and quality comparison website would appear in the market. Prospective patients would select from a list of procedures and then nearby providers would list their pricing. Some providers would likely advertise to get to the top of the list, while others would simply rise to the top through competition. Patients might even rate or comment on the outcome of a previous procedure using such a tool.

Medicine at times has taken a track opposite to the one governed by Moore’s law in the semiconductor industry. The evolution of new technologies in medicine serves to increase cost. No one that I am familiar with is working on the assumption that we will reduce the cost of colonoscopies by 50% every 5 years.

How do we encourage patients to act as consumers? Consumers are needed to improve quality and minimize costs.

One place to start is to evaluate quality through patient reported outcomes and let the mix between insurers and providers figure out how it drives the market. Perhaps insurers should reward the healthy with financial incentives.

It appears that capitalism has failed, but I don't know why.

I’ve read a handful of research studies that mentioned inactive patients were uncomfortable with consumer-driven insurance spending because it required effort on the patients’ behalf to reap the benefits. This suggests that such a plan would encourage patients to work toward becoming healthy. Could these plans become more cost-effective for employers over time? Will self-insured employers or HMOs--folks who bear the full cost of the risk do some pioneering in this area?

Dan Housman
Managing Director, Analytical Applications
Recombinant Data Corp.

Labels: Quality Reporting

Many fail to realize that the state of healthcare IT is firmly entrenched in legacy technology. I’ve encountered this trend in recent travels to healthcare organizations that would rather maintain an old technology until it fails than delve into the effort, expense, and potential risk of implementing a new solution to replace it.

One recent encounter involved a group of CIOs evaluating the purchase of an ESB (Enterprise Service Bus – used for HL7 messaging) for research collaboration. The CIOs questioned why the ESB vendor had only a few customers upgraded to the latest platform. The vendor deferred the question back to one of the CIOs who owned the eight-year-old legacy application; why haven’t you switched to the new platform? The CIO stated that the old application still worked and the upgrade provided a greater potential risk than reward. Despite all of the limitations in features, flexibility, and age of the legacy system, the upgrade required too much of an engineering effort. Simply speaking, the response reflected the phrase: if it ain’t broke, don’t fix it!

A second encounter occurred at a small practice involved in a PQRI initiative to code CPTII codes in billing data. Each practice involved in the initiative had to transmit their billing data to a central quality reporting repository for analysis. I was called in to this particular practice for my knowledge of an ancient technology – DOS! The practice managed billing on an EPM (Electronic Practice Management) application using the same back room white box server since 1989. The machine in question utilized a DOS prompt to access billing data. After a bit of tweaking, we extracted the data to a floppy disk and onto a laptop through a USB floppy drive. At a subsequent meeting, the youngest person in the room asked, what is a floppy drive? The user of the machine, who dutifully processed billing for the practice, remarked that should the system ever completely fail, it would be time for them to retire. That would be an unlikely scenario due to the EPM’s built-in 8-track backup system.

While the DOS box from 1989 wins the record for oldest system I’ve encountered, we have seen plenty of SCO servers from the mid-1990s as well as a host of old platforms operating in the corners and back rooms of physician practices. At this point, I wouldn’t be surprised to find an Atari 2600 running a lab order tracking system or an 8086 storing vital signs for over a million patients.

Nothing legacy is shocking anymore.

As we progress toward the powerful future of PHRs, HIEs, NHINs, and EDWs, DOS is just one example of a legacy system that must communicate with modern applications. There are thousands of DOS machines still spinning disk drives that were built before the college graduates of today were born. Many of these machines serve as the primary source of electronic data that we need to share and analyze. There is a last mile. And healthcare applications don’t die without a fight.

Dan Housman
Managing Director, Analytical Applications
Recombinant Data Corp.

Labels: Clinical Research, Quality Reporting

Like all software companies, we spend a fair share of our time trying to resolve bugs. Many people hear the word bug and it sends shivers up their spine. They envision some beast that eats all of their data never to return it again. Bugs are an acquired taste and for us we actually enjoy a good bug once we can track it down and fix it.

With a couple of major releases in July we hit some interesting bugs. By describing them in detail I think the process of debugging can be an opportunity to play Sherlock Holmes and then achieve that satisfying epiphany in an ah-ha moment. I do wish someone would create a museum or book of bug patterns. Maybe someone has. But a layperson's guide including the debugging process would be ideal.

Case 1: The case of the over green heat map

Biologists like to see data in heat maps. It feels natural for them to try to view the complexity of genes and samples with everything lined up in a colorful grid. We built a tool to view a grid of gene expression data. It was looking fine but we decided to modify our normalization routine to improve the accuracy of the results. Normalization is needed for heat maps because taking numbers from zero to N makes it difficult to set a scale for what should be red and what should be green. In a normal distribution using a bell curve, items that are in the extremes are bright colors and the ones in the middle are lighter versions of the same.

A problem was reported to us; our heat map was showing data that was too bright green, meaning the data wasn’t represented accurately. This caused some stir given that we had just improved it. So, we went to work trying to identify the cause. The first hypothesis suggested outliers. We proposed samples that were 3 standard deviations could be throwing off the whole scale of the heat map.

We took numbers greater than + or - 3 and set them to 3. This seemed to help but things were still too green. We then reviewed the data directly and it looked normal. However one thing was odd; the extremely small numbers were bright green. This led us back to the question of scales and outliers and reexamining our groupings of samples.

One engineer eventually cracked the bug. The small numbers were bright because they weren't recognized in the heat map as small. But why did this occur in the new heat map version? The small near-zero numbers were being read in scientific notation, e.g., .0000003 can also be 3 EXP-6. The heat map recognized it as 3. It changed because the new algorithm was more precise and was carrying more information in it through additional significant digits. More significant digits meant conversion into scientific notation more often.

We modified the database procedures to remove the unnecessary digits and verified the data wasn't presented through the code in the heat map using scientific notation.

Case 2: The mysterious failed report migration

Due to schema changes to a data mart, a number of Crystal reports were modified to encode logical updates to reflect the modified schema. Each were built in a development environment and all successfully tested against the development database.

We then needed to move the reports to QA. Upon migration of the database and schemas, the reports failed in the report server. This was quite odd; the reports worked in development when pointing the report server to the QA database, but failed in QA. We meticulously checked the configuration files and couldn't find a difference. However, there was a pattern in report failures, just the ones we had modified.

Upon verifying the files were the same, I came to the following conclusion: something was different in development vs. QA on the servers and something was different between modified vs. not modified reports.

Given that there was a big clue (error message "could not log on to database"), I compared both the report types modified vs. unmodified for the SQL connection properties. Everything was identical except for one thing. The modified report connection type had switched from SQL SERVER OLEDB to the SQL SERVER NATIVE driver. Upon switching it back in each report to OLEDB, the problem was resolved in QA.

Why? Development is a curious environment vs. QA. In QA, we keep the database and application server separate. In development, both are on the same machine. This meant that the SQL SERVER NATIVE driver was installed with SQL SERVER and was the difference in why it worked in development but not in QA. Case closed.

Dan Housman
Managing Director, Analytical Applications
Recombinant Data Corp.

Labels: Development, Quality Reporting