Regulating the Point of Care: The IVD Connectivity Industry Consortium

Originally Published MDDI April 2001 Several major in vitro diagnostics companies have come together to develop a standards proposal for the connectivity of point-of-care devices. Their labor provides a model for other manufacturers seeking to expedite the standards development process.

April 1, 2001

20 Min Read
Regulating the Point of Care: The IVD Connectivity Industry Consortium

Originally Published MDDI April 2001

Several major in vitro diagnostics companies have come together to develop a standards proposal for the connectivity of point-of-care devices. Their labor provides a model for other manufacturers seeking to expedite the standards development process.

Alan Reder

Sometime this spring, a visionary in vitro diagnostic industry group called the Connectivity Industry Consortium (CIC) will happily disband, having achieved its objective: establishing the basic foundation for a set of point-of-care (POC) connectivity standards and passing the results on to an official standards-making body for industrywide adoption. The success of the CIC provides a framework that manufacturers throughout the device and diagnostic industry can follow to actively participate in standards development.

The CIC formed in early 2000 to tackle a major issue that was frustrating both the IVD manufacturing industry and the healthcare providers using its devices. Doctors, hospital accreditation agencies, and federal regulators were pressuring providers to integrate the test-result data generated by POC diagnostic devices into their electronic patient records, but there was no uniform way to do so. Every POC device manufacturer seemed to offer a different way to connect to the providers' information systems—different physical connections, different software, different computers, different protocols.Users were fed up, and their frustrations were finding their way back to the manufacturers. Users had to rewire and retrain every time they bought a new POC device, and they were running out of room for every device maker's proprietary gear. From their standpoint, the solution to the problem was simple: every company's device should be able to plug into any other company's system, regardless of who manufactured either product.In reality, this would require a single set of connectivity standards so that each hospital's laboratory information system (LIS) and POC devices could exchange data the same way. The question was, who could exercise the necessary authority and instill a spirit of compromise across the industry to create such standards? With some strategic pushing from the outside, the industry nominated itself for the job, and the CIC was born.One year later, it appears that the CIC has not only hit its targets, but has also provided a model for other industries, even outside healthcare, to tackle similar issues. Within the IVD industry, the CIC solution hopes to boost the adoption of POC testing and thereby speed the revolution in healthcare delivery that POC devices make possible.THE POINT-OF-CARE REVOLUTIONThanks both to advancing technology and the exorbitant costs of long patient stays in hospitals, noncritical healthcare continues to move out of the hospital setting and into the community. A high level of care once only available in hospitals is now being delivered in outpatient clinics, physicians' offices, and even patients' homes. Many patients have their operations outside the hospital now, checking into same-day surgical centers in the morning and going home to recuperate in the afternoon. A point-of-care cholesterol monitor with an embedded microprocessor reader by Lifestream Technologies Inc.

POC testing devices are a large part of what makes this scenario possible. These handheld units analyze glucose, blood gas, coagulation, and other IVD measurements—which were previously the sole province of benchtop equipment in hospital laboratories—and process the results in minutes. Hospitals have taken to POC devices for their in-house patient care as well; the quick turnaround times help improve care and the bottom line simultaneously.

Doctors benefit from POC devices as well. When tests are performed by a central laboratory, busy physicians generally head off to do other things while waiting for the results. When they finally get the data in hand, they have to review the case before resuming treatment of their patient. Whether the interruption harms care is arguable; it certainly doesn't help, however, and either way, it is an inefficient expenditure of the doctor's time. With POC devices, physicians get a test taken at the patient's bedside and have the results in minutes, while the case is fresh in their minds.

In theory, POC devices promise to improve healthcare and lower costs in one handy package. In practice, however, their use has created a tangled mess of redundant wiring. The crux of the problem lies in efforts to transfer information from the POC devices to the hospital's permanent records. When the devices first hit the scene, healthcare personnel almost universally marked the results on paper records kept at the foot of the pat-ient's bed. But various factors have pressured providers to integrate POC results into the hospital's electronic information system; the resulting lack of communicability is where the problem lies.

One of those factors is the need to understand the chart note in the context of the patient's total history. "[Without connectivity], there is no convenient way to compare that chart note with the more reliable analysis that the laboratory is doing, and there is no convenient way to watch trends," explains Sidney Goldblatt, MD, a CIC board member and CEO of the medical software company Sunquest (Tucson, AZ).

Hospital accreditation requirements and federal regulations are also driving providers to connect their POC devices to the hospital or laboratory information system. The accrediting agencies want a single authority in the institution to assume central responsibility for the quality control (QC) and quality assurance (QA) of testing, regardless of whether the testing is done by a POC device or a central-laboratory device. Most hospitals have designated their central laboratories as the responsible party. The simplest way for the central laboratory to manage the QA and QC data from a variety of POC devices is to plug the devices into the hospital's LIS and upload the information.

The federal Clinical Laboratory Improvement Amendments (CLIA) of 1988 are playing a major role in the push to link POC devices with LISs, as well. CLIA treats POC testing the same as it does central-laboratory in vitro tests, meaning that records documenting the training of operators must be kept and, again, the QC of POC devices. That formidable task is also best managed electronically, by plugging the devices into an LIS. Jim Nichols, chair of the CIC's provider review committee and director of the clinical chemistry division of Baystate Medical Center (Springfield, MA), says that this is easier said than done: "At Johns Hopkins, we have 300 glucose meters and close to 3200 operators that we have to keep records on regarding their training and ongoing competency, as well as the QC on every one of those devices. That can't be done manually."

CIC'S PROPOSED STANDARDS DOCUMENTS

In their work to create a foundation for connectivity standards, the CIC member organizations identified five user requirements: bidirectionality, device connection commonality, commercial software interoperability, security, and QC and regulatory compliance. In order to address each issue fully, the consortium split their proposal into three standards documents. The first deals with the lower layer of the interface between the POC devices and the data manager; the second document covers the bidirectional, or device-messaging, layer of the interface; and the third deals with the electronic data interchange (EDI) interface between the data manager and a laboratory information system (LIS).

The Device Lower Layer. The lower-layer proposal describes a common connectivity infrastructure that POC devices use to connect to data managers on a network. This lower-layer protocol provides standards for cabled (RS-232) and wireless (infrared) connectivity, meeting the critical user requirement for device connection commonality. This proposal also describes the CIC common access point, an industry standards–based access point that hospitals can deploy to allow CIC-compliant devices to connect to networked data managers. The word common in this case refers to the fact that this access point can also be used by existing IEEE 1073 medical information bus (MIB) devices, as well as by all personal digital-assistant devices, cell phones, and laptop computers that have infrared data association (IrDA) ports. Thus, the access point enables connectivity for myriad commercial and consumer devices at the point of care.

The Device-Messaging Layer. The device-messaging or bidirectional-layer proposal describes a standard messaging protocol for bidirectional communication between POC devices and data managers. These messages support the essential processes of patient test reporting, quality control and calibration communication, and quality-assurance data exchange. The protocol also allows uploading of certified operator and patient lists to POC devices. To simplify implementation and allow widespread use, the messaging layer's syntax is based on the cross-industry standard extensible markup language (XML).

The EDI Interface. The third document, covering the EDI interface, provides a standard messaging scheme for data managers to communicate patient test results and order information to enterprise information systems (e.g., clinical data repository (CDR) and electronic medical record (EMR) systems). The EDI interface is built on the industry-standard HL7 messaging scheme, allowing for quick, easy, and widespread implementation.

CHALLENGES TO IMPLEMENTATION

With powerful incentives such as these, providers began asking POC device vendors and manufacturers several years ago to come up with solutions to the connectivity, QA and QC, and data-integration issues. The basic scheme for what was needed was clear. The POC devices would first connect to a computer, the data manager, which would supplement the primitive computing abilities of most POC devices. The data manager would then capture and consolidate patient, operator, test-ordering, test result, and QA and QC information. The data manager would in turn be connected to the LIS so it could pass on the required information—mainly, patient name and ID, and test name and results.

The scheme was straightforward enough, but with no template in place manufacturers responded as competitors generally do: with an array of proprietary solutions, specific to their own product and incompatible with each other. The resulting chaos was predictable. If a hospital had seven POC devices from seven different makers (not an uncommon example), it might have to cram seven data-management computers into its precious lab space, one for each device. And each manufacturer's device might connect to its computer differently than other manufacturers' units. One maker would use one type of cabling, another would use a different type, a third might use a modem instead of cable, and every maker would use its own custom docking station.

Complicating the matter even more was the very attribute that made POC devices so attractive: portability. "If we want to buy an Abbott device," says Nichols, "we not only have to get a whole new computer system, we have to figure out how we're going to connect every site—every nursing station, outpatient clinic, home nursing center, and mobile nursing outfit, as well as home patients—back into the central server."

Besides the physical problems of rewiring for each new device and finding space for all its associated hardware, providers faced the management nightmare of having to train staff on each maker's software. Little wonder, then, that providers began to balk at buying new devices and POC industry sales slowed. From where they sat, manufacturers were unable to grasp the full dimensions of the connectivity problem. So providers began to ask what was going on.

FORMING THE CONSORTIUM

They got their answer in 1998, when the POC testing division of the American Association for Clinical Chemistry (AACC) hired Enterprise Analysis Corporation (EAC) of Stamford, CT, to survey its members. The survey confirmed what everyone already suspected: the lack of a universal way to integrate POC data with the LIS was the major problem facing POC customers and was thus holding back acceptance of POC.

Having identified the dilemma, the AACC volunteered to help solve it. After lengthy, far-ranging discussions, it concluded that the best fix for the problem was a member-funded industry consortium. If major POC device manufacturers, healthcare providers, and suppliers could be enticed to the table, the testing division believed, the consortium could establish standards that would be almost instantly accepted industrywide. A preliminary meeting was scheduled in 1999, and invitations went out to entities representing all sides of the issues: hospitals, POC device makers, standards bodies, regulatory agencies, LIS companies, and members of the AACC POC testing division that had initiated the consortium idea.

Presentations at the meeting made a persuasive case for action. Speakers from healthcare institutions shared their horror stories about connectivity difficulties and argued for standards. On the vendors' side, speakers stressed that addressing providers' needs would expand the overall POC market. Connectivity, in Goldblatt's words, was "the tide that raises all ships."

The meeting also opened vendors' eyes to the fact that standards could make life easier for them as well. Cables, connectors, communications, and data management—these were not POC device companies' core competencies. If the consortium standardized those items, the companies could focus on what they did best—assays, the cost of test strips, POC technology, and so on. That would be a much better way for them to distinguish themselves from their competitors.

At the meeting's end, attendees were surveyed about their interest in forming a consortium. Over 80% volunteered to commit funds and staff (see sidebar, page 68). The CIC became a reality.

THE CIC AGENDA

The CIC officially launched operations in February 2000. The new organization figured out early on what it was capable of doing and what it was not. What it could do was create baseline standards and then generate support for those standards.

Create Baseline Standards. The CIC was charged with writing a set of standards that would fully meet the healthcare providers' need for uniform connectivity and data transfer. But, on the other hand, it wanted the standards to be limited and open enough for individual manufacturers to create competitive advantages on top of the baseline. It also wanted the standards to be flexible enough to adapt to the needs of international vendors and providers.

The point-of-care Dx system from Becton, Dickinson, & Co. reduces errors in the collection of patient specimens.

Create Widespread Buy-In of the Standards. The terms of CIC membership required all member vendor and provider organizations to implement the standards in their products and institutions. With such heavyweight buy-in at the start, the CIC fully expected industrywide acceptance to follow.

What the CIC knew it could not do by itself was maintain and refine the standards indefinitely. That job was better left to chartered standards-development organizations (SDOs), such as the National Committee for Clinical Laboratory Standards (NCCLS). So the CIC membership agreed that when its standards were completed, it would hand off its work, in proposal form, to SDOs for publication and future development.

To guide its efforts, the CIC crafted a vision statement that identified five critical user requirements to be fulfilled by its work: bidirectional communication ability, device connection commonality, commercial software interoperability, security (primarily of confidential patient records), and QC and regulatory compliance. Keeping things as simple as possible, the CIC decided that in most cases it would simply apply existing standards such as the Health Level 7 (HL7) computer protocol to the POC realm. But with some of the user requirements, providers wanted more capability than some devices currently had.

For instance, providers wanted devices to connect bidirectionally with a data manager so they would be able to upload as well as download. That way, the devices could also receive important information—valid operator lists and reagent lots, for example. In addition, a bidirectional POC device could access the full patient record from the LIS so the POC test result could be viewed against the patient's history and recent trends.

In addition, providers and vendors alike wanted commercial software interoperability. To lower cost, providers preferred off-the-shelf commercial software instead of software expressly created for the healthcare field. Manufacturers wanted a low-cost solution as well, because of the nature of the typical POC business model: POC devices are sold at a loss, with the profits made on test supplies. Understandably, then, manufacturers preferred software that added as little cost to the devices as possible.

THE PROPOSAL

One thing the CIC got right in its original concept was its timeline. It is finishing up its work right on schedule. The proposal has been split between three standards documents: one dealing with what the CIC calls the lower layer of the interface, between the POC device and the data manager; one dealing with the bidirectional (or device-messaging) layer aspects of that interface; and one dealing with the connection (called the EDI interface) between the data manager and the LIS. Each document was prepared by the technical team that worked on those aspects of the standards. As of late February 2001, the first of the documents began circulating to the CIC membership, with the other two soon to follow.

Each document is first going out in draft form with a request for comments. It will be returned to its authoring team to integrate the feedback. When all three documents have passed through this process, they will be compiled into a master document and sent to the CIC's provider review committee. If the committee passes the master document, it will go out to the full membership for final voting. The voting process is expected to be concluded by May.

When the CIC proposals are ratified, the CIC's business will have officially concluded and the organization will have achieved its objective. The proposal will be transferred over to three SDOs: NCCLS, HL7, and the Institute of Electrical and Electronics Engineers (IEEE). Each SDO will assume development responsibility for sections relevant to its expertise. NCCLS will have primary responsibility for publishing the standards.

NCCLS publication is anticipated to take place by late summer, or early fall at the latest. Once the standards are under the control of NCCLS, non-CIC members will be able to contribute to revisions. NCCLS provides an open, democratic, international forum, including affiliation with the International Organization for Standardization (ISO).

As part of its work, the CIC also prepared a heritage document for the SDOs. The heritage document covers issues that were beyond the CIC's scope but that may arise in future generations of POC technology. The SDOs will use that document to guide their development and maintenance of the standards. For instance, the CIC believes that in the future POC devices may be wireless. The wireless market hasn't yet matured sufficiently, however, for the consortium to select a standard wireless format, so it has simply alerted the SDOs to the issue.

CIC GUIDING WORK PRINCIPLES

The CIC unanimously voted to adopt the following guiding principles while developing the new standards:

THE CONSORTIUM MODEL

So why didn't the POC industry just contract with SDOs to develop standards in the first place, and save everyone the time and effort invested in the CIC? Two reasons: prearranged buy-in and the need to outpace technology

Prearranged Buy-In. By recruiting all significant parties to membership in the CIC, industrywide acceptance of the standards was virtually guaranteed. As Jim Nichols explains, "A standard can be developed by a standards organization, but unless vendors agree to it, it's just a standard that no one ever uses."

Outpacing Technology. An SDO like NCCLS typically takes five or more years to develop a consensus and publish a standard. "If we were to take that long to develop a standard," says Nichols, "it would have been outdated by three to five years by the time it came to market." So by working together in a very fast time frame—one year—the CIC has come up with something, Nichols says, that has "ready applicability to devices that are about to emerge on the market."

Many consortium members feel the CIC has itself set a new standard in business cooperation. Jump-starting a standards process with an industry consortium and then handing it off to the SDOs proved to be a perfect solution to the challenges presented by fast-moving technologies. "This model is not something unique to POC diagnostics," says CIC cofounder Jeff Perry, chief technical officer and a project scientist for Agilent Technologies. "The idea of an industry consortium with a focused effort to develop baseline standards is a very valid model for other areas in healthcare, or even other industries."

Of course, it is not as if the CIC's work occurred entirely without a hitch. "There had to be some negotiations about implementation, and there were other debates," says Emery Stephans, EAC president and chair of the industrial liaison committee for AACC's POC division. "One company's preferences were often at odds with another company's. But there was an awful lot of goodwill, and apparently all the controversies have been resolved." Stephans, whose vision and early recruitment of members helped get CIC off the ground, could not be more pleased about the result. "I'm also humbled because had it not been for the outstanding quality of the people we were able to find, all of this would not have happened."

Alan Reder is a freelance writer based in Rogue River, OR.

Photo by George B. Diebold/The Stock Market

Copyright ©2001 Medical Device & Diagnostic Industry

Sign up for the QMED & MD+DI Daily newsletter.

You May Also Like