The Big Picture
Medical device interoperability and standardization is a hot topic, and with the efforts surrounding adoption of the 11073 standard, IHE and patient care device frameworks, and the drive towards implementing electronic medical records, the field has become essential to the future of the healthcare industry. Yet, as we look to realign medical devices and their communication mechanisms away from proprietary intercommunication and towards standards-based communication, we should think “outside the box” to other fields, technologies and technical disciplines for inspiration and guidance on best practices. Perhaps an obvious one that comes to mind is the USB 2.0 standard. The simple idea being proffered is the ability to plug a medical device into a computing platform and have it recognized and joined automatically to the operating system. While we are a long way from this vision as a universal standard, there is ample evidence to demonstrate its feasibility in the existing Windows and MAC OS architectures today.
Key to the seamless and universal use and acceptance of USB devices is the bundling of device drivers delivered as part of base operating systems. When a new device is developed, it could be adopted for incorporation within the base Windows and Mac operating system environments. However, even before that adoption, manufacturers of these drivers could consider bundling them as part of hardware delivery. The drivers could be installed at run time or prior to usage and, from there, no other special attention would be required: attaching a medical device to an accompanying computing platform would automatically result in that device “joining” with the base operating system. The challenge, of course, is how best to develop drivers that support consistent and common access to data. While the common Patient Care Device (PCD) framework fosters such an idea, it has yet to be realized as a universal standard.
One theme embodied by the IHE medical device connectivity demonstrations featured at HIMSS 09 (pdf) in Chicago was that of following a patient from admission through a critical care room, in which patient information was gathered at the bedside from and to the various medical devices present there, including infusion, bed, monitor, and mechanical ventilation. The ability to collect and integrate these data into a bedside electronic health record was accomplished in concert among the several medical device manufacturers through access to the communication frameworks peculiar to the many vendors participating in the demonstration. The bundling of device drivers and publishing of a common syntax required to communicate with the various devices could provide a starting point for enabling universal biomedical device communication.
It’s about the patient
One possible approach to embrace is the concept of open source development to support creation of such driver bundles. Of course, device manufacturers will have to go along with this approach. But, I believe it is key to recognize that providing access to information seamlessly ultimately enhances business cases.
To maintain restrictions on access under burdensome license agreements may, in the short term, seem to protect the intellectual property base. Yet, this misses a much larger opportunity: it is not about access to the data, it is about what those data do and how they can be used to support and guide the treatment of the patient clinically. This is the proverbial low-hanging fruit.
The access to the data through hardware ports is a distraction that we must get past, collectively, as an industry. Restricting or limiting access to data impacts the healthcare organization but also constrains the ability of a medical device hardware manufacturer to expand into the larger environment that is the healthcare enterprise. The “commoditization” of the medical device interface is precisely the wrong model we should be promoting–it’s about the patient and the data brought to bear to make clinical decisions that will be of ultimate benefit.
To this end, one possible “model” would be to create an open-source framework analogous to existing open software development frameworks that could be managed or licensed in a manner comparable to GPL. Now, the challenges are clearly there: how do you control, test, qualify, certify, regulate, and secure such software? All valid and important questions. Yet, let’s not dismiss the approach out of hand.
Existing regulatory mechanisms for certifying software exist and can be extended to ensure that appropriate quality controls are applied to such software and device drivers. Controlled development, deployment, and evaluation of software related to medical devices is certainly more challenging because of the very nature and use of those software applications. The development of the drivers themselves and their “care and feeding” can be guided in accord with quality control mechanisms already in place and maintained by individual manufacturers. But, the use of those drivers, their access, and the ability to suggest customization could be in the purview of the open source community. This would not only assist in development, but would also cause the acceleration of key features leading to better, more functional interface products.
Having worked in the medical device, healthcare, and other commercial industries these past 24 years I do not come to these suggestions naively. I, too, have developed and brought medical devices to market and have experienced my fair share of the complexities involved, including issues surrounding quality and regulatory certification. The model that allows any device to be identified by simply plugging it into a base operating system makes logical sense and is a growing trend. Furthermore, by employing simple and common query and response syntax (perhaps rudimentary english commands), device information could be retrieved without relying on proprietary commands. This vision, I believe, is key to this evolving field and is necessary to support the larger ideas of personalized medicine and patient-centric healthcare that must come about in order to improve the overall quality of patient care.