The above title is the topic for my presentation at this year’s Medical Device Connectivity Conference. The event this year will be held at the Hyatt Dulles in Herndon, VA November 21-22. The agenda is just about finalized; you can check it out here.
This post is both a preview and a bit of thinking out loud as I continue to develop the the presentation. Suggestions or criticisms are welcome via comments below.
Whenever connectivity is added to a product or solution, things change. If this is a new product direction for the company (or a new variation of an established product category purchased by a provider organization) the resulting changes are often unexpected – by both buyer and seller. And whether expected or not, not meeting the market requirements that result from these transformations means bad things can happen like:
- Unsatisfied customers and/or user resistance due to unmet requirements,
- Lower than expected adoption rates, and
- Lost sales to competitors who better meet requirements resulting from transformations.
The goal of the presentation is to provide a concise framework to be able to identify and anticipate those changes, even when it’s the first time dealing with connectivity.Read More
As noted before, from time to time I answer questions and exchange ideas with folks from hospitals, companies and with students. It’s a karma thing with me – if I can help out with reasonable effort in situations where there’s no immediate consulting opportunity (although there may in the future), and it’s interesting, then I do what I can.
The following is the most recent exchange from a conversation I’ve been having with a product manager at a HIT software vendor about MDDS. They develop and sell an information system, part of which consumes medical device data. Not every customer already has an MDDS, and those that don’t look to their company to provide one as part of a “complete solution.”
From my research, it seems that having FDA clearance for MDDS seems to assure that the product will work out of the box and it’s tested for safety and effectiveness and seems to be a better choice to have than an MDDS (reliability, safety for patients).Read More
The medical app and regulatory pot is being stirred as products continue to appear, including those with questionable FDA credentials, or lack of credentials.
As discussed in our earlier posts on apps regulation (here and here), an app is a medical device if its meets the congressionally mandated and FDA enforced definition of a medical device as something whose intended use “is for the diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease, or is intended to affect the structure or any function of the body of man”. As stated in the FDA’s Draft Guidance, omitted from this definition, and therefore not medical devices, are apps “that are solely used to log, record, track, evaluate, or make decisions or suggestions related to developing or maintaining general health and wellness.”Read More
I received several items in my email regarding different organizations’ proclamations for 2012. Most of them predict that 2012 will be the year for mHealth to ‘break-out.’ Here are 5 examples:
- HIMSS 2012 is focusing on mHealth with several sessions and will have a kiosk on the vendor floor which features speakers on the mobile aspect of healthcare
- AAMI has published in their IT World column a synopsis of mHealth (requires login credentials)
- Here in Europe, the Mobile World Congress, Barcelona Feb 2012, sponsored by the GSM Association, has a track devoted to mHealth (filter for Mobile Health), a day of demonstrations and a specific plan on embedded mobile medical functionality.
- Additionally, the FDA has come out with draft guidance and has promised final guidance regarding mobile medical apps. The European Commission has entered into an MOU with the HHS to work together on the regulatory aspects of healthcare. I wouldn’t be surprised if they come out with similar regulatory guidance regarding mHealth as that promulgated by the FDA.
From what I have observed over many years, Hospitals have historically approached medical device connectivity projects as a tactical issue to be dealt with. Up until relatively recently, technology alone could be used to solve the connectivity issue (i.e. getting data from point A to point B) with little to no negative impact on clinical workflow. Further, the scope of connectivity projects has been mainly departmentally focused and deployments have been relatively basic. By basic, I refer to projects that have focused on connecting one or two bedside medical devices to a single CIS application or EMR.
Evidence of all of this can be found by looking back at the past 10 or more years and examining typical implementations of biomedical device connectivity to information systems.
• Most implementations up to now have been in very specific care areas such as the ICU and OR.
• Most implementations are relatively small in scope, often in the area of about 20 to 50 beds. Incidentally, for most US hospitals this happens to be about the same number of ICU beds per facility.
• In the ICU, the key devices that are interfaced are typically multi-parameter patient monitors and sometimes ventilators – but vents to a much lesser degree than monitors.
• In the OR, the key devices are typically patient monitors and anesthesia/gas machines.
• Outside of high-acuity care areas, in the general ward there are some limited niche interface solutions for mobile vital signs data capture. Many of these are only semi-automated in terms of truly automating both the data capture and the clinical workflow.
• For virtually all of these implementations, the data collected from the devices is identified though a mapping of the medical device’s location – that is a bed or room location identifier is used to associate the data and alarms.
• The device workflow – that is the steps clinicians are required to perform at the bedside to interact with devices to establish connectivity – has been limited. This is because most of the devices are actually fixed to the location – i.e. the monitors in ICU are mounted to the wall and data is interface via a networked gateway with outbound HL7. Therefore few if any steps are required by clinicians because the devices are permanently tethered to a local PC or terminal server that facilitates the data collection.
But as discussed in some of my previous market trends postings – requirements for connectivity have been changing and in some not so subtle ways. Many hospitals areRead More
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.Read More