Lab Soft News

Citrix Has Become a Barrier to Improvements in Healthcare Software

In my opinion, many EMR and LIS systems have become outdated in terms of their architecture (see: Possible Adverse Consequences of Increased Federal Investment in HIT). I have attributed this in the past to the fact that hospital and lab executives keep purchasing them so there is no rush by the vendors to convert them to a more modern design. A recent note by Mr. HIStalk on the use of Citrix in the healthcare industry provides another view of this problem. Here is his note:

...[S]omeone lists the five companies Dell should take over, all of them in healthcare IT. They are Allscripts, Quality Systems (NextGen), CSC, Cognizant, and Citrix Systems. Citrix isn’t technically a healthcare IT vendor, but [healthcare is] probably [the company's] biggest vertical since the industry is dominated by 1970s time capsule applications that won’t run efficiently and securely without it....Actually I use Citrix a fair amount at work and it’s pretty cool – poorly architected fat client apps run a heck of a lot better over wireless or VPN when you’re only painting screens and not slinging massive data packets back and forth.

His observation is very interesting and hits the mark. I am reminded of a LIS vendor many years ago which was reluctant to admit that the use of Citrix was absolutely essential in order for its product to function adequately. The company did not want current clients to understand its fat-client problem nor potential clients to add the cost of the Citrix software to the total cost of ownership (TCO). This need for Citrix as companion software for many LISs and EMRs also places an additional work burden on the lab and hospital IT support staff. As noted above by Mr HIStalk, the success of Citrix in the vertical healthcare market is a function of the inadequate design of the EMRs and LISs that we continue to buy and operate. Citrix is cool but there is a big price to be paid in order to see it work on a daily basis.

New Lecture Posted on Integrated Diagnostics

I delivered a lecture/discussion yesterday about integrated diagnostics to a mixed audience of pathologists and radiologists at the University of California San Francisco (UCSF). This is a topic that I have covered in previous notes. Part of the discussion also touched on the development of integrated diagnostic centers and the relationship of the virtopsy/catopsy to these new concepts. The potential patient referral patterns into these integrated diagnostic centers was touched upon, a topic ripe for discussion that I plan to address in subsequent notes.

Variations of "Integration" Relating to Lab Computing and Clinical/Anatomic Pathology

I have just returned from Toronto where I delivered a lecture at the Executive Edge conference which focuses on Canadian lab management. All of the conference presentations were outstanding and are available on-line. I will return to some of them in upcoming notes for a more detailed analysis. My own presentation addressed various type of integration as the term applies to lab computing and to Clinical and Anatomic pathology. In this lecture, I tease out the following for detailed analysis:

• Integration of Clinical Pathology with Anatomic Pathology; integration of upstream diagnostics with downstream therapeutics.
• Workflow integration of digital pathology with the LIS; introduction of the pathologist dashboard/console.
• Integration of Pathology, Lab Medicine, and Radiology to form the new medical specialty of Diagnostic Medicine; evolution of Integrated Diagnostic Centers.
• Development of lab networks (hospital LISs + esoteric reference lab LISs); pursuit of integrated clinical lab databases for patient care.
• Downstream integration of the expanding LISs with hospital EMRs; consideration of the technical and political challenges involved.
• Dis-integration of pathology, driven by reimbursement issues and upstream diagnostic integration by clinical office-based specialty groups.

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.

A Scenario for Lab Computing in the Post-Classic-LIS Era

I think that we may now be working our way through what might be called the post-classic-LIS era. The classic LISs were designed to meet most of the computing needs of the major hospital-based clinical labs such as chemistry, hematology, microbiology, and blood bank. These multipurpose systems dominated the market for about three decades. The first crack in the facade of their functionality and invincibility was the emergence in the market of so-called middleware. These niche applications were supported and promoted by the IVD vendors and smaller software companies, installed as "black boxes" between analyzers and the LISs, and provided additional functionality not always available in the LISs. A second blow was struck when many of the LISs available in the market were unable to adequately support molecular diagnostics. In response, a small group of the LIS vendors finally developed molecular diagnostics modules. The third blow consisted of the digital pathology systems that have been been supplied largely by a new set of vendors, manufacturing both the requisite scanners and software. The fourth blow, now in its very earliest developmental stage, has been integrated diagnostics which may ultimately result in the emergence of blended diagnostic information system (DIS).

A similar pattern is occurring in the hospital EMR market. Successful vendors such as Epic Systems have been unable to provide EMRs that adequately accommodate to the increasingly complex data and images generated in the major diagnostic departments such as pathology, clinical labs, radiology, cardiology, and gastroenterology. The inadequacy of these nominally "global EMRs" has not raised any alarms because the purchasers of EMRs, hospital CEOs and CIOs, rarely if ever use them on a daily basis for their own work. To explain away this EMR functionality problem. the advocates for these systems declare that they have not been designed to store and report all of this burgeoning diagnostic information and, most particularly, diagnostic images.

In contrast, the daily users of the "ancillary" diagnostic systems continue to insist that they function at a very high level in order to accomplish their daily work. In my opinion, the classic LISs, in a manner similar to the hospital EMRs, will gradually evolve into front-end viewers for the complex molecular test results and images that will be managed by back-end modules and linked under a federated architectural model (see: The Value of a Federated Architecture in Pathology). HL7 will be inadequate as an standard for these modules due to the length of time and cost required to develop interfaces. The solution to this need for an on-the-fly interoperability solution will be LITS-Interop which is web-based, flexible, and inexpensive. Increasingly complex versions of this software were demonstrated at the Lab InfoTech Summit last March in Las Vegas and the just completed APIII conference in Pittsburgh.

I believe that lab computing of the future will resemble something like the following: the classic LISs will remain in-situ, primarily as viewers for the specialized back-end federated modules with LITS-Interop serving as the interoperability solution. These hospital lab mini-networks will be linked into larger regional or national lab networks with scattered reference lab nodes and with participation of panels of pathology and lab medicine consultants. The manner in which the hospital EMRs evolve will become largely irrelevant to lab professionals. The federated hospital lab mini-network will continue to pass to the hospital EMRs those top-level diagnoses that the EMRs can digest. If the hospital clinicians need to view detailed lab information or surgical pathology images, they will link to the web-based federated lab network described above. A similar situation obtains today if the clinicians want to view radiology images -- they sign on to the specialized radiology PACS, usually managed by the radiology department.

Professional Services Divisions as Potential New Profit Centers for Pathology Vendors

In a recent note, I commented on the professional services division of Aperio as a relatively novel component of digital pathology companies (see: Emergence of a Professional Services Division at Aperio). Ole Eichhorn, the CTO of Aperio, emailed me the following comment to this note, which I quote with his permission:

One key point about having a professional services team is that [this approach requires] a relatively open system to build on....The professional services team is a sort of “third party for hire” that [Aperio's] customers can use to create interfaces, customize the product, and otherwise work with them to craft a tailored solution.  Our team builds onto existing interfaces and plug-in APIs at each point, they never modify our baseline code. Another point which won’t surprise you: most radiology PACS vendors have professional services teams and they’re an important part of their businesses.  I remember meeting with [a PACS vendor that told me that] 25% of their revenue came from professional services.

Lot's of interesting food for thought in this short passage. First of all and in order to develop a professional services unit, the product being offered by a vendor such a digital pathology system needs to have an open architecture. Put another way, you can't make money and serve customers modifying an unmodifiable product. He also make mention above of plug-in APIs, which can be defined in the following way in the Wikepedia: an application programming interface (API) is a set of routines, data structures, object classes and/or protocols provided by libraries and/or operating system services in order to support the building of application.

The second concept raised by Ole is that a professional services division works with a customer to develop new applications without altering the "baseline code." The product keeps improving using customer input but without modification of the core hardware/software, which must be sold to other customers. Compare this with the Epic EMR with most modifications generated by the centralized corporate R&D rather than by customers (see: Some Additional Insights into the Epic Corporate Culture). Improvement cycles for such products tend to be slower and they also tend to drift toward "vanilla" over time, making them easier to maintain.

Lastly, he makes mention of a PACS vendor with 25% of revenue derived from professional services. It seems to me that with this type of contribution to the bottom line, a professional services unit starts getting some "respect" within the company. Put another way, the links between it and the company marketing & sales unit become weaker. The professional services consulting division becomes empowered to turn to products and solutions outside the company if and when necessary to increase consulting sales. This, in turn, leads to a virtual circle or cycle, a feedback mechanism whereby the customer sees the consulting services offered by the company as more tied to quality improvements for them and generates even more business. The company products, I am sure, will always remain as the central focus on the solutions proposed by the professional services unit but with alterations at the margins, based on the special needs of the customer.

Major Drivers for the Conversion to Digital Pathology in Teaching Programs

I have just returned from the Pathology Visions conference in San Diego, which is now being converted from an Aperio user group conference to a vendor-neutral conference under the control of the Digital Pathology Association (DPA). This was one of the best managed and content-rich conferences that I have attended lately and I intend to post a number of notes about the ideas that the conference presentations have sparked in my mind. For today's note I want to concentrate on what I now consider to be the major driver for the adoption of digital pathology in the country's most prestigious pathology teaching programs.

Included in the Visions conference were lectures by Drs. Victor Reuter, Memorial Sloan-Kettering Cancer Center, John Pfeifer,Washington University School of Medicine, and Walter Henricks, Cleveland Clinic, about the merits of digital pathology in routine surgical pathology operations. Their PowerPoint lectures will be posted on the conference site in about a week and I will link to them as soon as they are available. I must confess that up to the time of this conference, I was unsure about the speed of the digital pathology adoption curve. I have been stewing about issues such as capital system costs, ergonomics, and "cultural resistance" to change in the departments. Given the obvious enthusiasm of these speakers, I have now changed my thinking about this topic.

If there is one thing that is important to the directors of pathology training programs, it is the quality of the trainees who apply for positions in their departments. Residency applicants, in turn, choose programs that will prepare them for their future careers by being staffed by well-known faculty and serving patient populations with challenging diseases. Part of this picture involves the opportunity to train using modern technology, which was hardly a consideration in surgical pathology until the introduction of digital pathology. Think of medical students applying for residency positions in radiology -- they seek training in the most current imaging technologies to give them an edge when they join radiology groups post-residency.

As soon as the surgical pathology program directors begin to obtain feedback from residency and fellow applicants that they will only apply to programs offering experience in digital pathology, most academic programs will quickly purchase and deploy the necessary equipment and learn how to use it in routine operations. I am told this is happening now. Meanwhile, the pathology departments in the 300-500 bed non-teaching hospitals will be forced to follow suit because their potential pathology hires will only seek positions in pathology groups providing such technology.

As soon as a teaching department convert to digital with the deployment of, say, pathologist dashboards/consoles and whole slide imaging (see: Horizon Anatomic Pathology Offers an Integrated Pathologist Dashboard), the pathologists using this equipment will soon refuse to work with a mixture of digital images and glass slides. I predict that they will prefer to use one or the other and not a mixture of technologies.

Based on these ideas, I think that most of the academic pathology surgical pathology programs will have converted primarily to digital pathology in about three years and most of the 500-bed non-teaching hospital programs in the following three years or so. While this process is taking place, the digital pathology vendors will be improving the user-interface of digital pathology processes such that its speed and efficiency will approach that of the current manual process.

Aggregating LIS Databases from Multiple Hospital Client Sites by a Vendor

Neal Patterson, CEO and one of the founders of Cerner, has always been ahead of most his competitors in terms of strategic vision. For example, he has always had a keen understanding of the feasibility and power of aggregating the databases of Cerner LIS clients. Needless to say, some of them have been reluctant to use their LIS databases for any use other than serving their local patient needs. However, I think that this is a short-sighted view if patient records are appropriately anonymized, although much of the decision will be based on the value for the hospital and lab of the merged lab data. Continuing in this same vein, Mr. HIStalk reports on a Cerner database aggregation initiative in pursuit of epidemiologic data for the H1N1 virus:

[Here is a] letter from HHS Secretary Kathleen Sebelius to Cerner CEO Neal Patterson, taking him up on his offer to create an H1N1 surveillance network made up of Cerner clients. Attached to the letter was Cerner’s pitch to its customers, asking them to sign an agreement allowing Cerner to distribute HIPAA-compliant aggregated data from their facilities. It sounds kind of cool. Benefit to Cerner? Well, Cerner got face time with Sebelius, did her sort of a favor, and may get unspecified IT vendor benefit someday. Add that to having a former Cerner director as President Carter’s … err, President Obama’s healthcare reform czar and you’ve got friends in high places who are spraying great gouts of taxpayer dollars directly at healthcare IT. Still, I’d say Cerner’s intentions were more noble and focused primarily toward their clients and their patients, so I tend to believe their claims of sincerity.

There are various benefits that can be derived from aggregating the LIS databases of the clients of an LIS vendor, public health and otherwise. H1N1 virus information is only one such example. On the one hand, I can understand the reluctance of hospital and lab executive signing a data-sharing agreement such as that offered by Cerner. However, there are also a number of inducements that can be presented to hospital and lab executives for cooperating in such a venture. Although disease surveillance is certainly one of them, it seems to me that a more appealing one for lab managers would be lab productivity and performance benchmarks. Any LIS database would contain, in exquisite detail, parameters about all aspects of the lab being studied. The only challenge would be deciding what data to crunch and how to display it in an understandable fashion. The LIS vendor could obviously charge for such reports given their value and the amount of effort that would be involved in generating them, at least at the outset.

Affordable Human Genome Sequencing to Spawn New Facet of Clinical Lab Industry

I am sure that most of the readers of this blog have already heard this news before but the cost of human genome sequencing continues to decrease. This was the focus of a recent article in the New York Times (see: Cost of Decoding a Genome Is Lowered). The consequences of this trend for clinical lab professionals will be significant. One of them will be that a whole new information management segment of the clinical lab industry will be spawned. Here is an excerpt from the article about this topic:

[Stanford University professor Stephen] Quake calculates that the most recently sequenced human genome cost $250,000 to decode, and that his machine brings the cost to less than a fifth of that....He said the much-discussed goal of the $1,000 genome could be attained in two or three years. That is the cost, experts have long predicted, at which genome sequencing could start to become a routine part of medical practice. The impediment to the medical use of genomes, however, is fast becoming not the technology but the ability to understand and interpret what the technology reveals. The quest to uncover the genetic roots of complex diseases like cancer, diabetes or Alzheimer’s, a primary goal of the Human Genome Project, recently stalled. Most of those diseases turn out to be caused not by a few common variants, as many biologists expected, but by an unmanageable number of rare variants, offering for the most part no clear target for drugs or diagnosis. That genetic complexity has thrown into disarray many plans for personalized medicine, because for complex diseases and traits there is no obvious way to predict the status of a whole person from his DNA sequence. There is much better knowledge about the genetic basis of many simple diseases — those caused by a single genetic variant — but most of those diseases are rare and account for a small fraction of the overall burden of disease.

I would like to use this note to launch a new discussion about how affordable human genome sequencing will affect lab professionals in the future. However and as noted in the article, we simply do not yet have an adequate understanding of the genetic basis for complex diseases and traits. Simply put, we will have access to genomic data from a wide swath of patients/consumers before we have the capacity to interpret most of this information in a broad and meaningful way. Inexpensive genomic testing will be a boon for bench investigators but perhaps frustrating for clinicians, patients, and consumers. In the interim, we will need some sort of secure "clinical" repository for the growing body of genomic data that can be continuously queried as new medical knowledge about the predisposition to disease, pre-disease, and overt disease is acquired (see: Predisposition to Disease and Pre-Disease on the Health Continuum; Wellness, Preventive Medicine, and the Classic Disease Model; Genomic Testing, Pre-Symptomatic Disease, and Health Insurance).

I believe that some patients/consumers may opt to have their local hospital-based clinical labs serve as a repository for their personal and family genomic information. These genomic storage requirements will inevitably create a series of of technical, clinical, and political challenges. One of them certainly will be the need for LISs capable of storing such information in an organized way. A second major challenge will be the need to periodically scan the data and inform the patients, and their physicians, about any new research with clinical relevance for them. The only thing that I am sure about at this time is that these activities will be a new line of business for the clinical laboratories and one that will create a closer relationship between the labs and patients/consumers. It's not too early to begin a discussion about the implications of this new facet of the clinical lab industry.