Lab Soft News

Digital Pathology Misconceptions Debunked by Amanda Lowe

Amanda Lowe, president of Digital Pathology Consultants, posted a very illuminating blog note recently in Keith Kaplan's Digital Pathology Blog (see: Digital Pathology Misconceptions Debunked by Digital Pathology Consultants). It's definitely worth a look. Misconception #1 caught my attention and I reproduce it below:

Misconception #1: The FDA has not approved digital pathology; therefore, it must not be safe.

The FDA does not regulate laboratories and it does not issue blanket approvals for specific applications like digital pathology. The reality is that the FDA approves the digital pathology hardware and software produced by a manufacturer for a specific intended use (e.g., primary diagnosis of H&E slides). Digital pathology manufacturers are required to go through a premarket approval (PMA) process to have their systems approved as a Class III medical device; this process takes time and is very costly for manufacturers. These hurdles have made it difficult for manufacturers to apply for FDA approval, but they are working on it. However, several digital pathology manufacturers have received FDA 510(k) clearances for specific manual and semi-quantitative analysis of specific IHC assays including HER2, ER/PR, Ki-67, and p53. 

DARPA's Plan X for Cyberwar; Relevance for Hospital EMRs

In a recent post, I discussed healthcare as a new target for cybercriminals (see: Is Medical Cybercrime the "Next Frontier" for Hackers?). A recent article about cyberwar and DARPA's Plan X (see: Inside DARPA's "Plan X" For Cyberwar) called to my mind a scenario whereby hospital EMRs might be a key target as part of a cyberwar or terrorist plot. Below is an excerpt about Plan X:

On September 27, DARPA will hold a workshop to flesh out the government cyberwar strategy called “Plan X.” The one-day workshop consists of a general access session for government employees and contractors, along with a Secret-clearance and above closed session to draw a roadmap for the future of America's cyberwar forces. While the next great virus won't be proposed at the Plan X workshop, the Defense Department's cyberarmy infrastructure development plans...will....Plan X has received $110 million in funding for the next five years. A publicly available DARPA document says that Plan X will “create revolutionary technologies for understanding, planning, and managing cyberwarfare in real-time, large-scale, and dynamic network environments” and “conduct novel research into the nature of cyberwarfare and support development of fundamental strategies and tactics needed to dominate the cyber battlespace.” In other words, Plan X will give Pentagon cybergeeks top-notch tools and research capabilities for the high-tech worms, malware, monitoring equipment, and network infrastructure hijinx that are an integral part of military capability circa 2012. DARPA, however, explicitly stated that Plan X will not fund research and development for the development of cyberweapons or vulnerability analysis. DARPA IS ESPECIALLY INTERESTED IN THE DEVELOPMENT OF CUSTOM, SECURE OPERATING SYSTEMS AND PLATFORMS FOR USE IN “HOSTILE NETWORK ENVIRONMENTS.

All of the major hospitals in the U.S. have converted, or are in the process of converting, to EMRs. Although all such deployments have backup plans whereby hospital physicians and nurses revert to written records when the system is down, such changeovers are always sub-optimal. These are backup plans that you usually don't want to even try. Many major cyberwar scenario's are bloodless and involve disruption of public utilities such as power grids and water systems. However, I can also envision cyberwarfare in association with terror incidents with mass casualties. Think about the confusion that would ensue if the major hospitals in the cities where such terror attacks took place had their EMRs hacked. The injured could not be triaged and treated efficiently.

I am reporting on these unattractive scenarios, both cybercrime and cyberwarfare, to make the point that EMRs need to operate at a level of security certainly as high as those in critical industries and public utilities. The problem for EMRs is that they also need to provide access to data for patients in the community via patient portals. In my mind, this is a vulnerability that could be exploited. Some hospital systems have already been breached (see: Hospital Management Systems Breached, By @OfficialComrade .c0mrade). Here is part of the message left on a hospital server by a hacker:

Hello, my minions. Let me start off by answering some questions.

Q: Why do you do what you do? A: I’m not in it for treason or pedestrianizing millions around the world, I’m solely in it because Computer Security is the most fitful outlet for me. Nowadays, the Hacking community is motile. There’s hundreds of group who are hostile and make freedom-ring by indulging in illegal matters and leaking information on Websites to industrialize themselves within the scene....

I’ve yet to report [that I have hacked your system) to those who created the dreadful piece of software. I plan on calling them later this afternoon.

Epic Authorizes Its EMR to Run on Open-Source Linux Servers

A recent article discussed Epic's authorization of its EMR to run on Intel x86 servers with open-source Linux (see: Epic Systems authorizes EHR system to run on Intel x86 Linux). What was most interesting about the piece was the speculation and hints within it about Epic's overarching strategy. Below is an excerpt from the article:

Epic Systems Corp., one of several dominant EHR vendors for large hospitals, recently authorized implementations of its EHR system on Intel x86 servers running open-source Linux, virtualized to VMware. Prior to that, Epic ran exclusively on AIX and UNIX servers. The move could signal the software company's attempt to expand its customer base by adding more medium-sized hospitals to its present mix, which includes the largest hospitals, physician groups and academic medical centers. Linux servers are cheaper to purchase -- and maintain, too, since Linux administrators are more plentiful, especially in smaller cities. The announcement came early in May at an Epic Systems Roundtable meeting at its Verona, Wis., campus, after extensive testing by third-party service providers VMware and Dell. Those companies will offer implementation services to hospitals who buy into the system, which they also do for customers of Epic competitors such as Cerner Corp. Dell also provides other services, such as Epic disaster recovery and physician/nurse order-entry helpdesks....[Frank] Nydam [VMware director of healthcare business development] added that cost isn't the only factor driving smaller providers to consider Epic, but interoperability concerns too. If a local hospital's patients typically seek specialty care at a large Epic customer such as Kaiser Permanente or the Cleveland Clinic, it would be more straightforward to exchange patient data when they're on the same system....

 "We're excited about this kind of a move; to do this kind of thing is a little out of Epic's character," said Jamie Coffin, vice president and general manager of Dell Healthcare & Life Sciences. "They see it -- I think -- as a way to reach customers that are much smaller than they've historically reached." Gartner analyst Wes Rishel, who sits on the Office of the National Coordinator for Health IT's Privacy & Security Tiger Team with Epic CEO Judith Faulkner, doesn't necessarily see the move to Linux servers as a significant market play for more customers. After all, Rishel points out, server hardware is just a small slice of an Epic implementation budget that includes support, provider training, software purchase and other costs. Furthermore, he added, hospitals in smaller cities may find it challenging to locate IT specialists versed in running VMware on Linux. He does concede, however, the idea of running Epic on Linux servers has potential to expand the EHR system's reach into more hospitals, especially at a time when competitor Allscripts is enduring internal strife."I don't see it as creating any significant shift in market position or anything like that," Rishel said. Later, he added, "But I can't deny that it's a possibility."

Here's what I personally take to be significant elements of Epic's business strategy inferred from this article and other notes I have posted:

• Start to compete more vigorously in the mid-size hospital sector. A component of this strategy, previously discussed, was to use its large hospital customers as Epic hosting sites for smaller hospital (see: Epic Helps Convert Its Large Hospital Customers into Epic Hosting Sites/Consultants). Running Epic on Linux servers which are less expensive also goes to this same agenda. I have speculated before that its arch rival, Cerner, is also starting to compete in mid-size hospitals (see: Is Cerner Modifying Its EMR Business Model?). It helps that Allscripts is in turmoil.
• Outsource work to other reliable IT companies, when feasible. Of course, the MUMPS/Cache software engine is at the heart of the EPIC EMR, which is a product of privately held InterSystems. For the Beaker LIS, instrument interfaces and rules are managed by Data Innovations software. VMware and Dell now join the list of companies that Epic and its customers have come to depend on. The latter we learn above provides disaster recovery and physician/nurse order-entry helpdesk services.
• Provide a de facto clinical-data-exchange "standard" among Epic client hospitals. I have speculated about this goal in previous notes (see: A Reader Comments on Epic Interoperability and Care Everywhere;  More on Epic's (Non)-Interoperability and the Recent NYT Puff Piece). Frank Nydam of VMware makes this same point regarding Epic in the excerpt above: "If a local hospital's patients typically seek specialty care at a large Epic customer such as Kaiser Permanente or the Cleveland Clinic, it would be more straightforward to exchange patient data when they're on the same system."

National Institute of Standards and Technology (NIST) to Study EMR/EHR Usability

I have posted previous notes on the usability of EMRs, particularly by physicians (see: "Usability Failures" of EMRs Frustate Physician Users; EMR Failures and a Recipe for Their Avoidance in the Future; Why Many Clinicians Dislike Their EMRs). It's a worthwhile area for inquiry and, apparently, the National Institute of Standards and Technology (NIST) will be looking into this matter (see: NIST to test EHR usability). Below is an excerpt from the  article:

The National Institute of Standards and Technology has decided to tackle the problem of poor electronic health record usability, asking EHR vendors to share their products with the agency so it can research how they work, according to an iHealthBeat report. According to NIST's Federal Register notice, the agency plans to conduct research designed to develop a set of guidelines/ standards for usability of EHRs and develop a framework for assessing their "performance oriented" usability. NIST also may examine the EHR systems' relevant instructions, documentation and error messages. It will release its findings in a report. NIST estimates that it will take a year to conduct the research, and vendors can't make modifications to products being researched during that time. The agency does assure vendors that it will keep the EHRs protected, applying the same high security measures in place in its main headquarters in Gaithersburg, Md., even if testing is performed off-site. NIST will not accept personal health information for this project. It will report any usability problems to the vendor. This is not the first time that NIST, which has a keen interest in EHRs, has expressed concern about EHRs' usability. In a 108-page report released last fall, NIST noted that EHR usability was "critical" but that EHRs were harder to use than they should be. The report called for further studies to assess the problem and recommended that a usability protocol be developed for the products.

For me, a key aspect of current EMR usability is the fact that some hospitals are employing EMR scribes to enter clinical data dictated by physicians and nurses into workstations (see: The Emergence of EMR Scribes as a New Category of Hospital Employees). I can't help making the comparison between this situation and that of, say, engineers for whom their computers are key productivity tools. I would hazard a guess that there is no such thing as scribes working for engineering firms to input computer data for these engineers. Why this difference between the hospital and engineering environments? The difference is that many hospital physicians do not view the EMR as a useful productivity tool that helps them care for patients. Although EMR vendors now seem to be stressing system usability (see: EMR vendors stress usability to attract physicians), I am not sure that this factor, in and of itself, will be sufficient to gain the confidence of physician users.

Put me down as being pessimistic about whether a NIST report will have any effect on the design of the EMRs, either now or in the future. I am, in part, influenced by the last two sentences of the above article. The previous 108-page NIST report released last fall called for "further studies" and recommended that a "usability protocol" be developed. Nothing will happen until hospital executives start complaining about the quality of EMRs and demanding that they be changed in some way. Even then, these products are large and complex pieces of software. Anything but cosmetic changes will be difficult to implement.

Digital Pathology Showcase; Industry Discussion Panel at Pathology Informatics 2011

It's not too late to register for Pathology Informatics 2011, a conference encompassing the entire breadth of the field that will take place on October 4-7, 2011, in Pittsburgh. The conference is composed of the following components: three workshops, three parallel tracks punctuated by plenary lectures over the course of three and one-half days, 33 scientific presentations selected on the basis of abstract submissions, 30 e-posters, and displays by 42 exhibitors (conference schedule). A total of 42 faculty members will be participating.

On Wednesday, October 5, from 9:00-9:40 a.m. in Pittsburgh, I will be moderating an industry panel that will discuss how to manage the Digital Pathology Showcase. The Showcase will be a head-to-head demonstration of multiple digital pathology systems to be presented at the 2012 Pathology Informatics conference. The date and venue for the 2012 conference is October 9-12, 2012, at the Chicago Hyatt Regency Hotel. Here is some background information about this whole concept evolved:

Pathology Informatics 2010 was held in Boston on September 19-22. At that time and within the planning group, it was decided to launch a digital pathology project that would allow potential purchasers of this technology to assess the various products available in the U.S. marketplace.

A two-year planning cycle for this project was decided upon. The first step, occurring in mid-2011, was the creation of a draft document detailing how the various vendors of digital pathology hardware and software could be compared before an audience of potential buyers. This document was circulated among both vendors and pathologists for several months. Vendor comments and reactions are contained within the document. This draft document, labeled the Digital Pathology Showcase, will be the focus of an industry panel discussion that will be convened at Pathology Informatics 2011 in Pittsburgh on October 5th 2011.

Following this panel and in the latter portion of 2011, a final Digital Pathology Showcase plan will be agreed upon. It will be the basis for the vendor head-to-head demonstrations that will take place at Pathology Informatics 2012 to be held on 8-12 October at the Chicago Hyatt Regency Hotel. Participation in the Vendor Showcase will be offered to all digital pathology companies on a first-come, first-serve basis.

I now am able to present to the readers of Lab Soft News a draft document describing the Digital Pathology Showcase that will be the basis for the upcoming Pittsburgh panel discussion. Please use the "comments" feature of this blog if you want to react to it. I will be happy to carry your ideas to Pittsburgh as the moderator of this session.

FDA Convenes Advisory Committee to Discuss Whole Slide Imaging

The FDA's Hematology and Pathology Devices Advisory Committee will be convening today and tomorrow to discuss discuss, and make recommendations, about what they describe as "public health issues" related to the use of digital whole slide imaging (WSI) systems that are now being used to replace conventional light microscopy for diagnostic surgical pathology. The meeting will be open to the public. Within the scope of this meeting, digital pathology is defined as the conversion of images that can be observed by conventional light microscopy on histologic glass slides into digital whole slide images via digital scanners. These latter images are then viewed with a computer monitor to render pathologic diagnosis of the lesion of interest. Finally, this process involves digitally archiving and retrieving these images for access at some later time. The committee will not be discussing computer-assisted image analysis or remote real-time microscopy at this time. 

The FDA background briefing for this meeting as a PDF file and downloaded from the FDA web site makes interesting reading for those interested in digital pathology. Below is more detail extracted from this briefing paper about what the FDA hopes to achieve by this meeting. Obviously, the major thrust will be the establishment of a set of principles for evaluating the accuracy and reproducibility of pathologists using this tool including both objective and subjective perspectives.

FDA hopes to gather information about how to evaluate and compare the performance characteristics of both the light microscope‐the reference method‐‐and the digital WSI method.  As background for the panel discussions, there will be presentations to cover the principles of light microscopy and the possible criteria and studies for analyzing the accuracy and reproducibility of the diagnostic performance of pathologists using the light microscope for examination of human tissue specimens, the principles of digital WSI, and the criteria and studies for the evaluation of the diagnostic accuracy and reproducibility of pathologists using digital WI for examination of human tissue specimens.  There will be a discussion of the objective and subjective aspects of reading direct images from a microscope and from a digital screen. 

The Pursuit of a Federated EMR Architecture by Hospital EMR Vendors

I have discussed the federated architecture for hospital EMRs in previous notes. I believe that the current hospital EMR architecture, adopted by virtually all vendors, will be eventually unable to accommodate to the increasingly complex information being generated in radiology, pathology, and the clinical labs. Under a federated architecture, these departments will be allocated their own space in hospital EMRs, allowing the content experts in them to populate it with the information that they generate and that they are the most skilled in formatting. This will avoid the current restrictions being placed on the diagnostic information being replicated to the EMRs.

I have little expectation that EMR vendors such as Cerner would adopt such a federated model for their EMR products because to do so would highlight the deficiencies of the current systems. In addition, I also think their underlying philosophy is that the ancillary systems, and the information that they generate, need to adapt to the constraints and rules of the EMR. Put another way, I think that these companies view the "ancillary" information systems as feeders of the higher level and integrated EMR. I personally view the LIS, the RIS, and the hospital EMR as peer systems.

Interestingly and in contrast, EMR vendors such as GE and Siemens have now unveiled a much different healthcare strategy and philosophy than Cerner. Both companies are now on record as pursuing what I will call a "diagnostic-centric" vision for healthcare delivery. Siemens refers to this approach as a full service diagnostic model and GE refers to it as an early health model. In the long run, neither company will  benefit from developing and selling an EMR that places significant constraints on the major diagnostic information systems, the LIS and the RIS.

I think that it would be in the best interests of both of these companies to begin to develop an EMR based on a federated architecture. After several years in a development phase, such a system could be sold to those hospitals that place a high premium on the reporting of complex diagnostic information to their clinicians. If they truly believe that the "center of gravity" in healthcare delivery is moving toward the major diagnostic departments (i.e., pathology, clinical pathology, and radiology), their EMR philosophy and architecture should be modified to reinforce this business model.
 

Patent Farming in Medical Standards

Dr. Jules Berman launched a continuing series of guest blog notes in Lab Soft News on March 3, 2007, entitled  Intellectual Property Issues Relating to Biomedical Standards. This note is the second in the series and was also co-published in his blog Specified Life.   

In a prior blog, I listed some of the intellectual property (IP) issues involving medical standards. One of the most significant problems that I have encountered in this regard is the incorporation of patented methods within standards. Hidden patents within standards can be used as a weapon against anyone who implements that standard. Bruce Perens, an open source guru, has written extensively about this problem. He uses the term "patent farming" to describe the act of planting the seed, a patented method, into the standard while the standard is being developed. Once the standard is approved and implemented by the user community, the patent farmer reaps his crop by asserting his rights to the hidden patent.

Perens provides several specific examples where patent farming has benefited various standards committee members to the detriment of the users of the standard. You might think that it would be a simple matter to require the participants in the development of a standard to disclose any of their owned patents that might be included in it. In the Rambus case described by Perens, such a disclosure agreement was part of the process but the patent disclosure policy of the standards organization proved unenforceable in court.

Even if an SDO (Standards Development Organization) requires an enforceable disclosure agreement from its members, it also appears that a committee member can sell patents relating to parts of the standard to a patent holding company. By working with a holding company, the original patent holder divests the patent and therefore is relieved of the obligation to disclose the existence of the patent to the SDO. Patent holding companies, sometimes called patent trolls by their detractors, are in the business of purchasing portfolios of patents to assert IP rights in strategically chosen business sectors. Recently, hospital-based technologies, including radiology imaging, have been the legal target of at least one major patent holding company.

In my next note, I will discuss measures that SDOs may take to reduce their vulnerability to patent farmers. I will also discuss some defensive strategies against patent farmers that are often suggested but which may not be that effective.

Intellectual Property Issues Relating to Biomedical Standards (First in a Series)

Dr. Jules Berman, a noted pathologist informatician, has published a number of previous notes in Lab Soft News about diverse topics. He is one of the country's leading authorities about healthcare software standards and intellectual property (IP) issues. This is the first in a series of notes by him as a guest blogger about IP issues as they relate to healthcare standards.

Bruce Friedman and I have informally discussed an emerging problem in health informatics: the insinuation of intellectual property via licenses and patents into healthcare data standards. Both industry and government experts agree that we need to have standard ways of describing, organizing, and exchanging data. In the U.S., there are thousands of standards development organizations (SDOs) busily creating new standards and revising existing standards. In the healthcare industry, it is likely that a small number of standards will emerge as the "winners" in this evolutionary struggle. A great deal of money will be invested in the development of software and other implementing technologies in support of those standards that are recommended or required by the U.S. government.

Unfortunately, the implementation of standards in commercial systems, or even standards that have been recommended or required by the government, may put commercial entities at some legal risk.

• The standard may contain methods that are covered by existing patents
• The standard may itself be "owned" by entities that require a license to use it
• The use of the standard but not the standard itself may be patented

I will be writing a series of blogs over the next few weeks that describe some of the challenging IP issues relating to biomedical standards. The blogs will include practical examples and will suggest some common-sense approaches intended to reduce risk and expense and maximize interoperability and flexibility. Comments about this note and any of the others that will be published in this series are highly encouraged.

:: Update on March 3, 2007 @ 10:35 a.m.

Jules Berman has a personel web site that contains resources and information relevant to his two book publications: Biomedical Perl and Perl Programming for Biology and Medicine. Among the resources available are:

• The Developmental Lineage Classification of Neoplasms, containing over 6,000 types of neoplasms and over 146,000 unique names of neoplasms. This classification is the largest neoplasm nomenclature in existence and is currently available as a public domain document.
• A compilations of all the lists included in Biomedical Informatics (about 240).These lists can be used in PowerPoint demonstrations.
• Links to information (such as Table of Contents) describing both books.
• Links to many of Jules' prior publications.
• Hundreds of "factoid" web pages containing interesting information in the related fields of pathology and biomedical computation.
• The web site currently contains several hundred web pages and is rapidly growing.

Biomedical Informatics: A New Book by Dr. Jules Berman

Dr. Jules Berman, one of the most accomplished pathology informaticians in the country, has just published a book entitled Biomedical Informatics. Here is the link to the publisher's web site and below is an excerpt of the description of the book:

Ideal for healthcare workers, students and biomedical researchers who wish to use informatics technologies in their own clinics and laboratories, Biomedical Informatics describes the fundamental issues and questions in the field, and reviews the different types of biomedical data resources and open source tools needed to fully utilize biomedical data.  You are shown how to navigate through the legal, ethical, and technical hazards of biomedical informatics to become self-sufficient and productive.  You will finish with an understanding of how to acquire, organize, annotate, and share biomedical data, how to render confidential data harmless through de-identification, and how to use a variety of free and open source utilities to solve common computational tasks.  Berman also discusses how the Perl Language is used in biomedical informatics and provides short Perl scripts that can be applied in the biological research and healthcare settings.

To quote Jules description of the book in an email to me, "It clarifies the fundamental principles of the field (rather than just describing past and current efforts in the field) and teaches a set of skills that are needed to work as an independent informatician." This is a volume that any serious student of biomedical informatics should add to his library. I recommend it highly.