February 2011
Feature Story

Anne Ford

By their first birthday, most babies show signs of dental development. But the point-of-care connectivity standard POCT1-A celebrates its 10th anniversary this year, and some say it has yet to start growing teeth.

That is, the standard has no enforcing body, and so adoption has been left up to individual vendors, some of whom are not inclined to spend financial resources making their legacy systems compliant with POCT1-A. In addition, the manufacturers that are pursuing POCT1-A compliance are left without guidance as to how to best implement the standard. “There are different ways of interpreting the POCT1-A standard,” says Bryan Allen, Siemens senior research and development manager with responsibility for POC informatics. “It would be wonderful if there were someone you could turn to and say, ‘What’s the right way to do it?’ That would help prevent potential divergence of the standard.” As it is, “today, you’re on your own.”

The Connectivity Industry Consortium developed the POCT1-A standard in 2001. Its aim was to provide a set of interface standards that, once adopted by manufacturers, would allow users to integrate data seamlessly between hospital information systems and POC devices such as handheld glucose meters. “By adopting these standards, manufacturers would offer POCT devices that are essentially plug-and-play—any device could link to any hospital information system through the use of any docking station without the need for a separate communications system. ... Expectations were high,” writes Robert Williams, Roche Diagnostics’ technical product manager for hospital point of care, in his 2010 article “The future of connectivity in POC testing: evolving standards promote seamless integration of patient data” (Point of Care. 2010;9:193–195).

The POCT1-A standard was updated in 2006. Nonetheless, five years later, “there is still a significant gap between how solutions are performing and the outlined POCT1-A goals,” Williams says in the article. “One of the key reasons is that the standard only provides a framework for engineers to build applications to support point-of-care functions. The actual application of the standard is left to individual manufacturers. This has resulted in varying degrees of adoption—which raises the question of whether the standard has real value for the industry.”

That’s not to say that manufacturers have ignored the standard completely. Indeed, several vendors offer POCT1-A-compliant products, among them Siemens’ Clinitek Status Connect System urinalysis analyzer and Nova Biomedical’s StatStrip glucose connectivity meter. Nonetheless, the adoption gap to which Williams refers is real, and several factors are contributing to it.

First, “it’s difficult for some legacy systems to support the standard,” Allen says. “If a system had a very simple results-only output device, then lack of CPU power or memory could be a deterrent to implementing the bidirectional protocol. Other legacy systems that did have good computing power might still have an issue in terms of research and development effort, in that they’re already out there in the field, they already have some sort of protocol, and now to have to impose POCT1-A on top of that ... You can’t just drop the protocol you have, because you have a customer base that’s relying on that. So you end up having to support the old one and the new one.”

Second, the specification ­doesn’t go far enough in defining messages that are commonly needed in devices, Allen says. “For example, if you wanted to send a message to a device to reconfigure its quality control, what message structure should be used?” Then, too, some devices request patient demographics, and there’s nothing in the standard to support that, he says.

“Yet another thing is that the fields aren’t always flexible enough. For example, our urine analyzer produces both semiquantitative and qualitative results. The standard doesn’t define a way to handle semiquantitative results, and the qualitative field it does define has a very limited number of entries. So the standard allows ‘high,’ ‘low,’ ‘normal,’ ‘abnormal,’ etc., but what you want to say for something like protein is ‘trace,’ which is an entry that isn’t defined by the standard. We’ve struggled a lot with little things like that.”

The Clinical and Laboratory Standards Institute’s Consensus Committee on Point-of-Care Testing will meet March 29. One agenda item will be to consider whether and to what extent to update the POCT1-A standard again. There’s one change in particular Allen hopes the committee will elect to make. “A few months ago I proposed to CLSI that they serve as a repository for device vendors’ POCT1-A specifications,” he says. “So when we complete our specifications, we would put them into the CLSI Web site, and then they would be available for other vendors, and hopefully other vendors would do the same. The thought is that when a vendor is faced with the dilemma of how to implement the standard, at least they could go to this repository and see how someone has tackled this issue. That repository would serve as a real-world example of what people have done, and that could help CLSI make decisions on how to change the standard.”

Despite the lack of widespread adoption, CLSI director of standards David E. Sterry, MT(ASCP), says he has recently seen an uptick in interest in POCT1-A. “I seem to be getting inquiries more frequently as to the technical content of the standard,” he says. “Another item that might also indicate there are more vendors making their devices compliant to it is that in the appendix of the document is a list of vendor codes, and we get contacted once, twice, or maybe three times a year with new vendors that want their codes registered.”

While POCT1-A as it stands may lack the robustness necessary to bring about universal seamless POC device integration, it is far from useless, Allen says: “For me, seamless integration is akin to plugging and playing printers and computers. That’s a long way off with POC connectivity in my mind. But I think the standard does advance connectivity. It has got the fundamentals of bidirectional connectivity, so for device and middleware vendors, it does make life easier. The basic communication is there, and then they have to work a little harder, maybe, to extend the standard for some extra feature like device configuration. So it’s not seamless integration, but it’s a good step forward.”