In a few short weeks, TCBI will be holding their 5th annual Medical Device Connectivity Conference in Herndon, VA (the Washington DC metro area), November 21-22. It seems like the first conference was only a year or two ago.
Medical device connectivity, or the more fashionable (and some might say, more descriptive) term interoperability, has both changed significantly and remained the same over these past 5 years. Lots has changed on the regulatory and HIT governance front. The FDA has issued guidance on mobile medical apps, wireless medical devices, and cyber security – just this year. The FDASIA report on regulating HIT was presented to the ONC, FDA and FCC.Read More
A key feature of all connectivity solutions is a database that includes all of the patients associated with the system’s medical devices. This is called a “patient census” or ADT (admission, transfer and discharge), much like the way a hospital’s ADT system manages patient demographics for the hospital information system or EMR. Also referred to as patient management data, these data often include: patient name and ID number (permanent medical record number, episode of care number, or both), current assigned location of the patient, and the device associated with the patient. Depending on the application, these data can also include more operational or clinical things like assigned caregivers, admitting and/or attending physician, admitting diagnosis and service unit. It is also possible that this operational or clinical data may be stored in a different file, separate from patient management.
Some workflows or systems queue up patient information prior to arrival or application of the medical device, while others capture or generate patient demographics when the medical device is first applied to the patient. In any event, the connectivity solution must capture patient demographics that are sufficient to ensure correct patient identification and possibly additional information that relates to the use of the medical device (e.g., body surface area – or the data to calculate it, weight, etc.) Common methods to capture patient demographics are an ADT interface and a method of manual data entry. In some cases, it may be practical to capture patient demographics at the same time the medical device is associated with a patient.
This workflow is being tackled first in this series of blog posts because it is a foundation used by most connectivity workflows. Patient management workflow should be one of the last set of requirements completed because it must support all the workflows to be included in the product. What follows, in no particular order, are a number of issues and considerations that fall under the patient management category.Read More
One of the biggest challenges for medical device makers developing connectivity solutions is to look beyond the connection itself and design an overall solution that provides good workflow. Medical device connectivity is workflow automation through the integration of medical devices and information systems. It is the scope and quality of the workflow automation in a connectivity solution that impacts users, and not just how the connections are technically implemented.
Besides meeting a growing list of market requirements, connectivity aims to deliver certain features and benefits. Typical examples include:
- Reduced user error by automating previously manual tasks – this can improve patient safety and outcomes
- Automating certain tasks make the resulting data available as it’s generated, rather than when users can get around to manually documenting it (if they don’t forget)
- Automated oversight, where the connectivity solution monitors and reports on the episode of care associated with the medical device can also improve patient safety and outcomes as well as improve staff productivity
- Making it efficient and simple to review retrospective and current medical device data to better make a diagnosis or gauge the efficacy of a therapeutic intervention
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
Creating and launching innovative ground-breaking new technologies and solutions is a heady experience, especially in health care where innovations can literally save lives. Pioneering new technology is hard and very expensive work. There is always a rush to get the product finished enough to be able to launch and start generating some revenue. Features considered not essential are pushed farther out on the product roadmap and these products are launched based on the innovations that have been implemented.
A couple of products come to mind as examples: FlowSense Medical’s digital urine flow meter (recently acquired by Baxter) and PixCell Medical’s cell based point of care diagnostics. In both of these cases, a non essential capability that’s been pushed off is connectivity. Feature trade-off decisions is an everyday activity in medical device product development. However, every trade-off has consequences. Let’s look at those consequences, and more importantly, how to mitigate them.Read More
Wireless sensors are intended to operate via short range wireless communications. That’s why they’re called “body area” networks. Due to power consumption constraints, wireless sensor radios typically don’t operate as 802.11 a/b/g/n radios used in enterprise networks. The reference designs from the manufacturers of radios intended for wireless sensors often indicate a range of a few meters and show wireless sensors communicating with a gateway device that aggregates sensor data and then communicates with the enterprise network where the sensor software applications reside.
When asked if they’d prefer their wireless sensors with a patient worn gateway (typically about the size of a deck of cards or smaller) or just the wireless sensors by themselves, most users – patients and caregivers – overwhelmingly chose the sensors-only option. They just got rid of those nasty sensor cables, why would they want some extra box they have to keep track of?
Asking requirements gathering questions on feature trade-offs that aren’t supported by the technology is often times a frustrating experience. It is, however, important to identify all market requirements, even the ones you may not be able to meet with current technology. Let’s look at how we might solve this conundrum.Read More
On September 4, 2013, the FDASIA mandated workgroup presented their recommendations to the Health IT Policy Committee in Washington, D.C. Some reporting on the meeting cast the draft report as downplaying potential FDA regulation of healthcare IT applications (HIT), while others emphasized the uncertainty (subscription required) of the process and ultimate outcome. Such news stories are, by necessity, short and can’t cover all the issues but this one from iHealthBeat provides a good summary.
The final report (links to all draft documents) was submitted September 4, 2013 and was basically unchanged from the preliminary report.
The question to be answered by the workgroup was how to regulate HIT. I think we’re past the question of whether or not HIT should be regulated: there have been reports of patient deaths starting in 2005 (here and here), and that’s with almost zero reporting requirements on the part of providers or vendors, and the proliferation of HIT vendor non-disclosure and hold harmless agreements to supress reporting (see reports here and here).
The report, also called the “Section 618 report” for the section of FDASIA that mandates the workgroup and their report, is extremely concise and to the point – perhaps too concise for those outside the world of regulated medical devices. Of the three entities, FDA, ONC and FCC that are the focus of the report, by far the most focus was on the FDA. ONC and FCC received minor recommendations. This blog post focuses on the FDA issues and recommendations. You will have to read the workgroup’s recommendations yourself to pick up the specifics regarding ONC and FCC.Read More
A bit more than two years after releasing their draft guidance, FDA has released the final guidance (pdf) on mobile medical apps (FDA press release). FDA also put up a new page on their web site with information on mobile medical apps.
In this final guidance, FDA has chosen to use two factors to distinguish between mobile medical apps that are low risk that they do not intend to regulate, and higher risk apps that will be regulated. FDA will regulate those mobile medical apps intended:
- to be used as an accessory to a regulated medical device; or
- to transform a mobile platform into a regulated medical device.
As always with FDA, the question of whether a mobile app is regulated or not, will be decided on the intended use or claims made by the manufacturer as described in promotional materials, user manuals and similar content and communications.
FDA references two pages of examples of mobile medical apps. The first list includes Class II medical devices that have received premarket clearance (aka, a 510k). Anyone can submit a 510k for clearance for any kind of device – whether FDA really thinks its a medical device or not. Consequently, this list is not an absolute guide to what FDA considers a mobile medical app that they want to regulate. Unfortunately, the page does not include any links to product information or information on the 510k summary for each product. A search on the “K number” in the FDA’s 510k database, e.g., K020866 for Abbott’s Freestyle Tracker Diabetes Management System, will return a 510k summary for the product, including intended use, classification and product code.Read More
On August 6, 2013, FDA published modifications to the list of medical device related standards they recognize. News was made of the fact that additions to the recognized standards addressed areas such as cybersecurity and interoperability. While there were many revisions and some additions of a variety of standards, this blog post will focus on the news making standards related to medical device connectivity.
The published modifications are divided between two separate recognition lists, number 31 (pdf) and 32 (pdf). Here is the Federal Register version (PDF). Recognition list number 31 includes one standard under the Software/Informatics category: Laboratory Automation: Data Content for Specimen Identification; Approved Standard (NCCLS AUTO-7A). The 20+ standards listed in recognition list number 32 are all new additions under Software/Informatics and focus on the following topics:
- IT governance in hospitals for networked medical devices,
- Medical device connectivity and interoperability, and
These are all great standards (although they are of varying relevance and usefulness). So where is the confusion, you might ask?Read More
On August 14, 2013, AAMI reports that the FDA has, “issued a new guidance document on integrating RF technology into medical devices.” You can read the FDA blog post on this guidance here. The draft version of this guidance on RF wireless medical devices was published more than 6 years ago in 2007 (blog post here). At the time, I thought the draft guidance was not earth shattering but a solid example of the application of the Quality System regulation to wireless medical devices.
In order to effectively use this guidance, or the earlier draft guidance, one must have a working understanding of wireless technologies and the FDA’s Quality System regulations. Only then is there sufficient context to be able to properly apply the guidance to the design, manufacture, installation and support of wireless medical devices. Like many initial connectivity efforts, dealing with these wireless issues can be a case of not knowing what you don’t know.Read More