Medical Device Daily Washington Editor

The promises of healthcare savings from electronic health records – EHRs, in the parlance of healthcare – sometimes seem as commonplace as dashed hopes of lottery-based retirement, but that does not seem to blunt the interest of think tanks such as the Rand Corporation (Santa Monica, California). Rand recently published a report on the impact of a unique identification number for each patient on the cost of healthcare and according to Rand's calculations, the use of such a number coupled with the appropriate healthcare information technology (HIT) infrastructure could mean savings of as much as $77 billion a year.

According to the statement Rand published along with the study, creating a unique patient ID number for everyone in the U.S. "would facilitate a reduction in medical errors, simplify the use of electronic medical records, increase overall efficiency and help protect patient privacy."

The effort would not be cheap, the Rand statement asserts. Such a system "could cost as much as $11 billion," but the projected returns are formidable. The Rand statement also points out that "federal legislation passed more than a decade ago supported the creation of a unique patient identifier system, but privacy and security concerns have stalled efforts to put the proposal into use."

Richard Hillestad, PhD, the study's lead author and a senior researcher at Rand, states that the alternative "is to rely on a system that produces too many errors and puts patients' privacy at risk."

Most systems make use of statistical matching to draw up records, according to Rand. In this scenario, the software searches for data such as name, birth date and so on to retrieve a patient's record, with part or all of the patient's Social Security number often part of the search data. The Rand statement claims that statistical matching "returns incomplete medical records about 8% of the time and exposes patients to privacy risks because a large amount of personal information is exposed to computer systems during a search." A unique patient ID number would eliminate such searches.

Given the population of the U.S., such a system using only numeric characters would have to employ at least nine digits. Whether patients would carry that information on a plastic card akin to a debit or credit card is a detail that has yet to be worked out.

The study group at Rand also made the case that privacy concerns might be better dealt with via "the creation and enforcement of laws that severely punish those who misuse information retrieved with a health ID number." Hillestad said that the research done at Rand "suggests that it's easier to safeguard patient privacy with a records system that makes use of a unique health ID rather than a system that uses statistical matching."

Pam Matthews, senior director of healthcare information systems at the Healthcare Information Management Systems Society (HIMSS; Chicago), told Medical Device Daily that the Rand study helps the EHR cause, but that details still matter. "Especially with a large system, one of the challenges is appropriate patient identification, and there is a lot of work that has been done in terms of options and practices that generate quality results."

As for which entity might be charged with assigning the numbers, Matthews said, "that was originally discussed" as something that would be handled by the Office of the National Coordinator for Health Information Technology (ONCHIT), but "what would be crucial is that whoever sets the standard" would do so in a fashion that reasonably tracks existing standards, which would help interoperability.

All the same, the small physician office may be the rate-setting mechanism in all this. "One of the challenges is the adoption of EHRs in the physician office," Matthews said, observing that "there are still many paper systems out there, especially for the small physician practice, and the challenge is to provide incentives" to boost adoption of HIT among these practices.

Appian snares FDA software contract

FDA's information technology (IT) base is not exactly regarded as world class, so the announcement that software company Appian (Vienna, Virginia), which specializes in business process management, had signed a contract with FDA to install business process management (BPM) software at the agency may strike anyone dealing with the agency as a plus.

Appian's Oct. 27 statement indicated that FDA chose the company's Enterprise BPM application "for the development of process-centric applications" in a purchase valued at almost $800,000. The term of the program is set for three years.

Fred Ackerman, VP of sales for Appian's federal division told MDD that he could not predict how quickly a majority of FDA's staff would be on the new system, but that it would eventually affect most of the agency's staff.

Ackerman said the software is a web-based program that is written to address "a myriad of processes," like an office productivity program. It could be used to help the agency vet advisory committee members for conflicts of interest and to determine security privileges for FDA staff. The software does not reside on the end user's PC at boot-up, but is a server-based system that downloads data and only the essential program files to the end user's terminal.

New software comes with a new software learning curve, but Ackerman said the graphic user interface (GUI) will look similar to the existing software, thanks to the flexibility offered by having written the software in Java, a favorite of web site developers. The GUI will not look identical to the legacy system, however. "Chances are we don't do that right out of the box," Ackerman said, but a fairly close match can be had with some programmer time. He noted, however, that custom GUI mapping can get expensive.

FDA will run the new software in parallel with the legacy system, Ackerman said, noting, "about half their systems are on the way to being retired." As for compatibility, Ackerman said the program runs on Unix-based operating systems such as Linux, but compatibility with the successor to the Vista operating system published by Microsoft (Redmond, Washington) would depend largely on Java's compatibility.

Ackerman said the change of software will not force FDA to update its hardware base any more quickly than it otherwise would. "We don't require 'big boxes' to run the software," he said, adding that the program runs well on 32-bit machines as well as the coming wave of computers based on 64-bit processors. "Our software has an in-memory data store, which requires significant addressable memory," he said, but he also stated that 32-bit architecture allows a computer plenty of memory to handle the program.