Patrick Soon-Shiong of APP Pharmaceuticals donated $1 billion to create Bell Labs of Health Care according to the article “Billionaire Patrick Soon-Shiong On Health Care, Obama” by Kym McNicholas from Forbes. The philanthropic investment is intended to create a public health grid.

“The idea is to actually go across the country and bring scientists, mathematicians, computer scientists, engineers, biologists, clinicians, surgeons, oncologists, pathologists, all together. And really integrate, truly integrate, information from the basic science to the bench to the clinic” said Patrick Soon-Shiong.

At Recombinant, we look forward to this effort taking shape and hope to get involved in the project.

Dan Housman
Managing Director, Analytical Applications
Recombinant Data Corp.

A clinical trials model was referenced in the blog post “OBIEE for Clinical Trial Management System (CTMS)” by Ramana Chittor. It focused on the tracking of trial activity and less about the clinical observation components of the CTMS. This is an interesting high-level trial and business model with mapping in OBIEE.

Dan Housman
Managing Director, Analytical Applications
Recombinant Data Corp.

Labels: Business Intelligence

There is an interesting blog post titled “Industries Hurt Most by Soaring Health Costs” by Rick Newman from U.S. News and World Report. The post suggests that healthcare efficiency is linked to overall economic growth. Industries that traditionally provide their employees with company-sponsored health insurance are the ones experiencing the slowest growth. While I am not familiar with the full extent of the details, it is clear that the cost of healthcare is a burden for every industry.

Dan Housman
Managing Director, Analytical Applications
Recombinant Data Corp.

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

After being trapped in an Atlanta airport for 24 hours I purchased and read Ben Mezrich's new book, The Accidental Billionaires, about the Facebook start-up story.

I have become a fan of Facebook and must commend Zuckerman for having built a great application and network.

There have been medical applications that play off of the social networking theme. PatientsLikeMe allows patients with similar medical conditions to share information with each other about treatments.

Within the CTSA there is a grant opportunity to establish tools for researchers to network with each other. At the moment it appears that the CTSA initiative will either focus on a network already established by Collexis, a private company, or to take the open source route of hardening tools used at UCSF and within Harvard's CTSA in their catalyst site.

We also have seen many physician networks try to establish a social network among their physicians to encourage increased intranetwork referrals.

There will surely be social networking extensions built upon PHRs like Google Health and Microsoft HealthVault.

At Recombinant we are likely to intersect with social networking in all three areas. Each network is dependent on rich reference and clinical data sets that must be powered by data warehouse strategies. For example - knowing a physician's specialties is a secondary use of credentialing data normally found in tools like ECHO or Cactus. Knowing their practice patterns is a matter of analyzing their medical claims. Microsoft is already linking their data management engine, Amalga, with their PHR. We have even discussed using the data warehouse to help physicians socially understand best practice care patterns from their peers.

The holy grail that may never come to be would be an integration of the networks of patients, researchers, and providers. I think Jim Clark had some vision of this when he started Healthscape as his follow-up to Netscape before it became WebMD.

Given the projects we are working on today we can see many exciting opportunities and challenges in the intersection of data warehousing and social networking. It's a hot space that may take ten years to settle before the dominant Facebook-like platforms emerge. After all, Facebook followed the work of SixDegrees (too early), Friendster (too date focused), and MySpace (too ego driven).

There may be some smart kid at Harvard or MIT with a better model for social networking in healthcare and a drive like Zuckerman. Maybe we already know them? But if you are out there.... give us a call when you are ready!

Dan Housman
Managing Director, Analytical Applications
Recombinant Data Corp.

Labels: Data Warehousing, PHR, Social Networking