As we continue, at breakneck speed, to develop interconnected systems for capturing, storing, and retrieving medical information, many people have expressed earnest concerns about how the privacy and security of this information can be maintained. These concerns are very valid.

Our experience with the Health Insurance Portability and Accountability Act, or HIPAA, has demonstrated the plusses and minuses of various strategies for assuring privacy and security. Moving to fully electronic medical and personal health records, which will encompass data from magnetic resonance imaging scans, electrocardiogram (ECG) strips, laboratory histories, vaccinations, home-based medical utilities, and everything in between, can quickly become an exercise in futility as far as privacy and security are concerned.

One of the keys to overcoming this is to adopt standard protocols that cut across many systems of communications and integration, allowing for uniform schemes to protect the information, and de-identify it as required. Elliot B. Sloane, PhD, explored some aspects of this march toward a standardized national infrastructure in the December 2006 “Tech Talk” column in 24×7. A necessary ingredient for building these electronic records is the ability to bind patient identity (ID) to the data.

At first glance, this might seem like a trivial concern. After all, patients are identified when they enter the hospital; they receive wristbands, ID cards, etc. There are Joint Commission requirements to verify patient identity before certain procedures and tests. Modern medical equipment such as computed tomography scanners and automated ECG machines allows for the entry of a patient identification.

These considerations, however, are insufficient to assure consistent binding of the patient’s ID to the patient’s electronic data; and, taken together with no controls, they can actually result in data gaps, duplication, or errors in the electronic record. Complicating the situation is the issue of thousands upon thousands of legacy devices that will become “connected” through various wired and wireless interfaces, but which have varying capacities for binding patient ID to the data stream.

The methodology for binding patient ID needs to be vendor neutral, but it also must not favor one technology over another. Otherwise, the opportunity for universal adoption will be compromised. For example, an approach that uses barcoded wristbands might seem intuitive. In 2006, however, according to one major wristband manufacturer, only 18% of hospitals actually utilized barcode capabilities in wristbands. Radio frequency identification (RFID) is challenging the use of barcodes for identification in some areas, but it is still in the “early adopter” phase of deployment. Since the adoption of a patient ID binding scheme is needed now, it should be based on an approach that will work with barcodes, RFID, key entry, or any other technology that comes along.

While automating the entry of patient ID to patient care devices has the potential for improving throughput, reducing errors, and increasing safety and device effectiveness, the seriousness of an erroneous patient ID getting into the system mandates a conservative approach. Unstructured manual entry of patient ID to patient care devices is inefficient and subject to error. Keying in a patient’s ID needs to be based upon a structured methodology that includes verification. Similarly, the use of technology to semiautomate the process still requires validation by the caregiver. The IHE (Integrating the Healthcare Enterprise) initiative’s patient care devices domain is drafting a profile for the binding of patient ID for testing in January 2008. Examples of the use cases that must be satisfied under this profile include the following:

In the first scenario, a patient is connected to a station (bedside monitor) of a cardiac monitoring system that includes a number of bedside monitors and a system console that is connected to the patient administration system. The patient may or may not be able to confirm positive ID information. Therefore, the caregiver enters known patient information, such as partial or complete patient name (printed on the patient record or told by the patient), patient ID (this may be obtained from a printed barcode, a bedside chart, etc), and/or date of birth, into the system console, which returns and displays to the caregiver a list of matching patients showing the medical record number, full name, age, sex, room/bed, and admit date . In most cases, the list would contain only one name, unless the data input were fragmentary. The caregiver then selects the appropriate record binding the patient ID into the monitor’s data.

In the case of a patient who is connected to a stand-alone infusion device connected to the network, the caregiver would scan the barcode of the patient’s wristband and the device barcode, to bind the patient’s ID to the infusion device, and confirm the binding.

A third case could involve a patient connected to a stand-alone ventilator, connected to the network. Ventilator and patient have RFID tags. The proximity of the tags for a minimum time period implies a binding of patient ID to the device, provided that there is an existing order for a ventilator for the identified patient. A caregiver verifies the binding.

These three use cases are simplified here due to constraints of space, but illustrate the breadth of the application. The complexity of patient ID binding is also subject to two other workflows: logically disconnecting the patient from the device when true physical disconnection occurs; and suspending the patient from the device, to resume later without having to reinitiate the connection. This could occur when a patient who is ambulatory is disconnected from monitoring periodically, or when a patient is first taken from a monitored bed in day surgery to the operating room and later returned to the same bed after the procedure.

In building a true technical framework from this profile, a number of existing standards need to be taken into consideration. These include ISO/IEEE 11073, which governs much of the device data communication, Health Level 7—which applies to the messages used to identify and bind the patient ID, IHE profiles covering queries to patient administration, GS1, and the Health Industry Barcode Council standards—regarding barcode protocols, The Joint Commission, and others.

Among the open issues in the implementation of patient ID binding are: standards in the process of adoption, registration systems for the devices themselves, the level of automation of these processes that are consistent with prudent practice, and, of course, protecting the privacy and security of the now patient-identifiable data.

All of this is being considered by IHE planning and technical committees that include representatives of the user community—clinicians, clinical engineers, health care IT professionals, and the vendor community—equipment manufacturers and barcode and RFID vendors. An initial demonstration of patient ID binding in production-level medical devices and systems is planned for the Interoperability Showcase at the February 2008 HIMSS meeting in Orlando, Fla. This event will mark another major accomplishment for clinical engineering collaboration with information technology. To become a part of this process, please email your intent to .

Raymond Peter Zambuto, CCE, FASHE, FHIMSS, FACCE, president, Technology in Medicine Inc, Holliston, Mass, a Linc Facility Services Company. For more information, contact .