Lab Soft News

Xerox Follows Lead of Others, Purchases Computer Services Company

In recent notes, I have begun to explore questions pertaining to whether lab software vendors will begin  to provide professional services (i.e., consulting services) to hospital-based clinical labs in addition to software and hardware (see: Professional Services Divisions as Potential New Profit Centers for Pathology Vendors; Who Will Function as System Integrators for Mini-LIS-Networks?). Increasing emphasis on IT services is not unique in the lab world but occurring across the entire business sector. A recent article in the New York Times discussed the purchase by Xerox of a service outsourcing company and the larger implications of this trend (see: Xerox Buys Affiliated, Fueling Shift to Services). Below is an excerpt from it:

Ursula M. Burns, the chief executive of Xerox, declared on Monday that the company’s plan to buy Affiliated Computer Services, an outsourcing services company, for $6.4 billion would be “a game-changer” for Xerox....And technology companies, like Xerox, are often buying services companies to accelerate the transition. Only last week, for example, Dell announced that it would buy Perot Systems for $3.9 billion. Last year, Hewlett-Packard bought another large technology services company, Electronic Data Systems, for $13.9 billion. The shift to services is being fueled by financial and strategic considerations and by the evolution of technology itself. Services businesses tend to be steadier sources of revenue and profit than product businesses, which are more susceptible to peaks and valleys of economic cycles. Services businesses also foster closer relations with corporate customers and often yield higher profit margins....Technology advances are making it easier for suppliers to provide computing as a service, delivered over the Internet from remote data centers in the so-called cloud computing model. Software can move off desktop personal computers to become a Web-based service, like Google’s e-mail, word processing and spreadsheets, and the online customer-relationship management software of Salesforce.com.

I have discussed grater utilization of remote data centers and the cloud computing model in a number of previous notes (see: Finally, A Clear Definition for Cloud Computing; Cloud Computing in Healthcare: Key Questions to Ask; A Different Definition for Cloud Computing Emerges; Amazon's Cloud Computing Now Comes with a Service Level Agreement). I fully understand that many of the technical issues supporting use of "the cloud" as a computing platform have yet to be fully worked out. However, there is no question is my mind that the lion's chare of business computing will eventually move to the cloud. Such services will be priced as a commodity, issues such as backup and disaster recovery largely disappear. and storage space can expand almost infinitely. Among major industries, however, healthcare will certainly be the very last to make such a move. The stated reasons for this will be security, confidentiality, and HIPAA considerations. The real reason is that healthcare IT personnel are deeply conservative and never take the national lead in any IT ventures. They are also reluctant to put their own jobs in jeopardy.

Although healthcare will be a laggard in adopting the cloud computing model, I suspect that lab computing will lead the way over other hospital computing units. The reason for this will be primarily the rapid adoption of digital pathology that I foresee occurring starting about now (see: Major Drivers for the Conversion to Digital Pathology in Teaching Programs). For a large pathology department, the storage requirements for deploying digital pathology services supported by a pathology PACS are enormous. It's only a matter of time before pathology departments, and the digital pathology companies supplying the scanners and software for whole slide imaging (WSL), come to recognize that that most cost-effective means to store digital images files will be in remote data centers under the cloud computing model.

Who Will Function as System Integrators for Mini-LIS-Networks?

In a recent note (see: A Scenario for Lab Computing in the Post-Classic-LIS Era), I predicted that hospital-based mini-LIS-network would, in time, replace the monolithic classic LISs that are common in hospitals today. For the sake of simplicity, let's call these new systems MLNs. They can be defined as classic LISs that are integrated (not interfaced) with additional specialized modules including molecular diagnostics and digital pathology, important functionality that the classic LIS can't adequate provide. The MLNs, in turn, will be integrated with various esoteric reference labs via electronic national lab networks. These networks, with electronic links to reference labs, differ from the one-to-one interfaced connections between hospital and reference labs that are commonplace today. The esoteric labs will offer services and procedures that many of the hospital labs cannot themselves provide such as sophisticated genomic/proteomic tests and immunohistochemistry (IHC) on tissue specimens. A similar situation prevails today but without the multi-lab electronic interconnectivity.

This scenario, if viable, prompts an interesting question. Given that most hospital labs will lack the expertise to integrate their LISs with other modules to create MLNs, who will function as the system integrators for them? Additionally, who will integrate these systems into the national lab networks? Unlike the current hospital EMR industry with a host of consultants/system integrators available to help design, install, and troubleshoot systems, there are only a small number of comparable consultants serving the clinical labs. There is simply not as much money at stake and the LIS vendors themselves generally assume the responsibility for the successful deployment of their own systems. In so doing, they do not assume great risk because most of them can be installed relatively easily. To answer my own question, I can envision four scenarios for the design, development, and integration of the MLNs. They are the following:

• The classic LIS vendors themselves will either buy the companies that have developed the specialized lab modules described above or establish a strategic relationship with them such that the companies, working in concert, can guarantee a successful and integrated system.
• There are lab software companies currently operating such as Atlas Medical with its Total Outreach Management solution and Halfpenny Technologies that provide outreach integration solutions and are accustomed to working with the heterogeneous systems available in the market today.
• A third option will be the current or emerging professional service units of the lab software companies, one of whose missions will be to assist in the development of MLNs (see: Professional Services Divisions as Potential New Profit Centers for Pathology Vendors).
• The current individuals functioning as lab software consultants, perhaps augmented by new entrants into the field, if MLNs prove to be an desirable option for the hospital-based clinical laboratories.

Emergence of a Professional Services Division at Aperio

I attended a workshop entitled Multisite Integration in a Global Environment at the recent Pathology Visions conference in San Diego. The workshop faculty included representatives from the global medical research/pharma corporations Quintiles and Merck. Also on the panel was a representative of the Aperio professional services division that was launched in February, 2008, and responsible for IT integration, configuration, and compliance consulting. I was intrigued by the apparent success of this Aperio business unit thus far and decided to explore the idea a little further. Please keep in mind that I had concluded in a previous note that software development was the core competency of digital pathology companies like Aperio so I consider these companies to be first cousins of the LIS vendors (see: Software as the Core Competency of Digital Pathology Companies).

LIS vendors have attempted to launch professional services divisions over the years but the success of these ventures has been limited. This is not to say that hospitals do not require professional services support from their LIS vendors for their integration and configuration challenges. For example, such support is a necessity when two hospitals merge and decide to convert one of them to the LIS used by the other. The problem with hospitals is that the lab leadership usually assumes that the cost of designing the new system will be included in their system licensing and support fees. I think that we can conclude that these fees are set at levels to cover such professional services consulting. However, they are not always identified as such and the company may not show a professional services unit on their organizational charts.

The development of such a unit unit within a digital pathology company such as Aperio, I think, reflects the two arms of this industry. One consists of pathology departments and pathology reference labs and the other can be identified as pathology/health research, both for-profit and not-for-profit. They correspond to the two tracks of the recent Pathology Visions conference. For-profit companies such as Quintiles and Merck are large multinational enterprises and require an integrated digital pathology architecture as part of their technology adoption plans. The IT demands of such companies are rigorous and they are willing, and accustomed, to budget for various types of consulting services. Their corporate cultures are very different from non-profit hospitals, even those that are large and complex. The Quintiles launch of digital pathology with Aperio is described in a recent press release (see: Quintiles Advances Cancer Treatment Through New Digital Pathology Services).

The most interesting question for me relating to this whole matter is whether Aperio and other digital pathology companies, once they establish professional service divisions to serve their corporate and research clients, can establish a value proposition regarding such services for pathology departments and hospitals. It's worth noting that hospital CEOs and CIOs are accustomed to paying large sums of money to consultants relating to their hospital EMR deployments but generally not for their "ancillary" information system installations.

David Okrongly Appointed CEO of Quanterix Corporation

Quanterix Corporation has announced that David Okrongly, Ph.D. has been appointed Chief Executive Officer and a member of the company's Board of Directors. Dr. Okrongly replaces co-founder and interim CEO, Nicholas Naclerio, Ph.D., who will continue serving as Chairman of the Board. He joins Quanterix from Siemens Healthcare Diagnostics Division, where he most recently served as Senior Vice President in charge of the Molecular Diagnostics business unit. In his 12 years at Siemens, formerly Bayer Healthcare, he led the worldwide introduction of a variety of chemical and immunochemical assays and clinical diagnostic systems. Dr. Okrongly brings more than 20 years of experience in product development and commercialization, which includes previous senior management positions at Xytronyx and Applied Immune Sciences.

Some Bad Financial News from Aspyra

Mr. HIStalk highlights some bad financial news about Aspyra:

Ancillary systems vendor Aspyra...files a horrendous 10-Q: a loss of $1.6 million on revenue of $2.1 million. The company says it will have losses and negative cash flows for the foreseeable future, meaning it needs financing or to sell shares (not likely: 12 million shares are already out and trading at 19 cents, 66% off the year-ago price, valuing the whole shebang at just over $2 million).

Here's a run-down on the company's product line:

Aspyra...is a healthcare information technology and service provider that specializes in Clinical Information Systems (CIS) and Diagnostic Information Systems (DIS) for healthcare providers. Its portfolio of products also includes the Picture Archive Communication Systems (PACS) products. The Company markets a product line that includes a Laboratory Information System (LIS) under the trade name CyberLAB, a general purpose PACS system under the trade name AccessNET, a Radiology Information System (RIS) under the trade name CyberRAD, a RIS/PACS integrated system under the trade name AccessRAD, a specialty PACS system under the trade name AccessMED, an Anatomic Pathology System under the trade name of CyberPATH, a WebGateway portal for physician access to its CIS applications, and other related clinical and diagnostic application modules.

One needs to ask the question whether the company has spread itself too thin with so many products in the medical diagnostic market for a relatively small company.

Do Hospital Executives Use Their IT Vendors as Scapegoats?

Mr. HIStalk, spurred on by a reader's comment about how hospital administers may use their IT vendors as scapegoats, responds with some pearls of wisdom. Copied below verbatim is first the comment followed by his response:

Reader: [B]laming vendors [for hospital inadequacies]: Hospital administrators seem to be using clinical systems as an excuse for poor outcomes instead of their own poor management and operational workflows. I have seen hospitals bleed money because they refuse to fix workflow while demanding to replace a current IT system. The attitude that a system should fix these problems is absurd.

Mr. HIStalk response: Why do people believe they no longer have to think?” Ever since systems were first sold. In my experience:

• Hospitals like the idea of solving a problem by buying something — a piece of equipment, the services of a consultant, or a software application. It seems so much more decisive than the unglamorous chore of fixing poor organizational habits or culture.
• Hospital project management is usually iffy and IT portfolio management and governance even worse. IT should not own or run any IT project except infrastructure, yet you see IT departments claim they are going to lead clinical transformation. Not likely.
• Once the switch is flipped, everybody walks away instead of starting the long-term work of wringing value out of the technology.
• Hospital buy applications to avoid confronting employees for subpar job performance and managers for poor job definition. Hospitals almost never fire salaried employees, so nobody feels much pressure to change.
• Every area within a hospital thinks they are too different to allow conformance (especially pediatrics and surgery). Every hospital with an IDN (especially the flagship one) is convinced that nobody has a better idea.
• All that said, it’s easier to blame your vendor and then dump them than to look in the mirror to see who’s really responsible. I rag on vendors because I know they could do better, but when you paint an ugly picture, it’s ludicrous to blame the paintbrush you willingly chose. Every vendor’s product is wildly successful in at least one site, so that pretty much validates that it works when implemented and used correctly.

There is little that I can say to improve on this set of assertions. I obviously endorse the idea that central hospital IT should mainly provide infrastructure. I also believe that most hospital CEOs and COOs are skilled primarily in managing hospital reimbursement, cutting merger deals with other hospitals, and planning new construction. They will obviously turf all IT projects to their CIOs who often have worked their way up through some hospital IT department. CIOs often tilt primarily to the technical side, which is bad, or to the managerial side, which is also bad. They will often buy one-of-everything and then can't integrate these diverse systems or purchase most of their major IT systems from a dominant vendor and end up with functionality deficits. Throwing federal money at healthcare IT problems will not solve them if managerial talent in a hospital is scarce or the systems themselves are inadequate.

Horizon Anatomic Pathology Offers an Integrated Pathologist Dashboard

I have made occasion references to Diagnostic Information Systems (DIS) that could be developed by the integration of the the currently separate LIS, RIS, and PACS systems. In a recent note, I made specific reference to the fact that few vendors were offering such a system (see: Few Vendors Deliver an Integrated RIS/PACS Solution According to KLAS). It appears that this situation is being partly remedied by one vendor, McKesson, which has sent me the specification sheet for their Horizon Anatomic Pathology product that you can review with this link (Horizon Anatomic Pathology).

The product offers many of the features of what has been called a pathologist dashboard or console including the following: (1) a workflow engine; (2) a case-aggregating application to integrate whole slide images for a patient with the specimen gross description/images; (3) access to special stains and clinical pathology results for the case at-hand; (4) an embedded digital dictation system; (5) encoded diagnosis reporting; and (6) access to PACS images for the patient. Joe Stabile of McKesson informs me that the product now also interfaces to both Aperio’s Spectrum and BioImagene’s Virtuoso whole slide image applications.

In the past, I have commented on the fact that the return-on-investment (ROI) for the total conversion to a digital pathology department may have been somewhat lacking in the past, assuming that such a purchase was driven mainly by economic considerations. I am now convinced that with the growing technical maturity of whole-slide-imaging and the pathologist dashboard, similar to that being offered by McKesson, this story takes a very different turn. The combination of these hardware and software technologies provides a productivity tool and quality improvements not available before for surgical pathologists.

One note of caution that is probably obvious to anyone reading this note. These new technologies, taken as an integrated package, constitute a radical new approach to histopathology. Like all new technologies, they place a training burden on the pathologist that has never been encountered before in the field. However, it's no different than that experienced by all radiologists during the last decade or more as they have adapted to digital radiology. Our specialty has no choice but to embrace this digital approach to histopathology because all of the momentum in the field will be moving in this direction.

Medicolegal Liability and Malfunctioning Healthcare Information Systems

According to a recent blog note by Mr. HIStalk, EMR vendors can't be held responsible for errors that creep into data reported by their systems to hospital physicians. Below is an excerpt from his note with boldface emphasis mine:

Penn researcher Ross Koppel’s new JAMA article concludes that healthcare IT vendors enjoy contractual and legal protections that keep them out of trouble even when their products cause patient harm.  Anyone who has signed a vendor contract from either side of the table knows that vendors disclaim most responsibility, saying it’s the licensed user’s job to notice software or hardware errors and prevent them from harming patients (like when an allergy warning doesn’t display or a dose is calculated incorrectly). HIMSS unleashed a vindictive and wildly pro-vendor barrage against Ross in 2005 for daring to write an article describing patient harm that occurred with a hospital’s IT implementation, but I expect they’ve got bigger, multi-billion dollar fish to fry this time.

Here's a link to an abstract of the 2005 JAMA article. Also, here's a link to a 2005 reference describing the nature of the criticism leveled by HIMSS personnel against Koppel and referred to in Mr. HIStalk's note (see: When Technology Isn’t Always the Answer: A Case Against Computerized Order Entry):

Although Koppel offered suggestions for reducing the medication error risks inadvertently caused by CPOE systems, the University of Pennsylvania report was still met with criticism from proponents of CPOE systems, including the Healthcare Information and Management Systems Society (HIMSS), which asserted that the systems, when properly implemented, are extremely beneficial to the safety of health care. “The study points out some design problems that could cause confusion or error if they were present,” said Jonathan Teich, MD, Ph.D., chair of the HIMSS Patient Safety and Quality of Care Steering Committee. “However, almost all of the flaws that were mentioned in the research have been realized previously; remedies have been found and have appeared in published literature.” Joyce Sensemeir, RN, MS, HIMSS director of professional services, added that while the report can serve as a “cautionary tale” about what could go wrong, it should not be taken as the standard of what occurs with proper CPOE implementation.

I frankly can't see a practical way to hold EMR vendors responsible for errors that might crop up in hospital electronic records. I can therefore understand why these vendors include "hold harmless" clauses in their contracts. First of all, these companies would probably spend most of their time and resources in court litigating both valid and frivolous suits against them without such a contractual exemption. We all understand that healthcare is a litigious environment. Secondly, the performance of any EMR is a combination of the vendor product plus the various tables and settings established by the local hospital software support group. In most cases of erroneous results, it would probably be difficult to establish fault. Putting the onus for the quality of EMR results on hospital personnel seems to me to be placing responsibility on the proper group. I have published previous notes about how HIMSS operates largely as a trade association for healthcare IT companies (see: HIMSS Describes Itself as a "Trade Association" in a Press Release, Possible Adverse Consequences of Increased Federal Investment in HIT).

Brochure Now Available for the 14th Annual APIII Pathology Informatics Conference in Pittsburgh

The brochure is now available on-line for the 14th annual APIII Conference that will be held on September 20-24, 2009, at the Marriott City Center Hotel in downtown Pittsburgh. This is a must-attend event for any lab professional with even a passing interest in pathology informatics. As always, the program is outstanding and provides a cutting-edge overview of this rapidly expanding field.

Do Hospitals Really Want Interoperable E-Health Records?

The New York Times yesterday published an op-ed piece about e-health records that was remarkable for its brevity and accuracy (see: Miles to Go on E-Health Records). Below is an excerpt from it with boldface emphasis mine:

The main impediment [to the wider deployment of EMRs] is money. Many hospitals simply do not have the capital to buy systems that can cost $20 million to $200 million, especially when so many are struggling to remain solvent. Hospitals also worry about high maintenance costs, an uncertain payoff on their investment, a lack of staff with adequate technical expertise and resistance from doctors....The ultimate goal is an “interoperable” system that would allow easy exchange of clinical data between hospitals and doctors. The modernization effort will have limited value if a mélange of different computer systems can’t talk to one another.

Hospital EMRs are extremely expensive and the estimate above for the cost of a single system is certainly in the ballpark for medium to large hospitals. Businesses of comparable size outside of healthcare would never consider, nor be able to pay, such high prices, even for a mission-critical system. An interesting question is why these systems are so expensive, particularly since many of them are rather antiquated. I can't point definitively point to any one factor but I would cite the following: few competing companies, a thin layer of buyers at the high end, the desire for extensive unique customization by each hospital client, and high customer vendor support costs.

However, let's turn to the issue of why EMRs from different hospitals "can't talk to each other." Let's call this system interoperability as noted above in the op-ed piece. Part of this problem is vendor-driven. As hospitals within cities and regions consolidate, they are faced with the daunting process of computer interoperability across the hospitals comprising the newly emerging multi-hospital health system. In such a setting, the dominant purchasing hospital commonly declares its EMR or LIS to be the winner and deploys it within the newly purchased hospital. Such an action always inflames an already simmering conflict within the now "integrated" system, creating winners and losers. However, more revenue is generated for the winning EMR vendor -- another payoff for non-compatibility.

What about interoperability across competing hospitals in a city or region? I have been involved with LISs and EMRs for decades. I have never seen a request for interoperability with information systems in competing hospitals in an RFP. This is quite simply a matter of market competition. Hospitals don't want portability of patient information with their competitors. If hospitals never asks for the expensive and complex interoperabilty of systems, given today's architecture of EMRs and LISs, how many vendors will try to force it down their throats?