Scheduling is not a workflow one normally associates with medical device connectivity. In some applications, scheduling is handled by software separate from the connectivity solution. Sometimes, scheduling is not done at all. In other applications, as we shall see, scheduling is so much a part of the broader workflow, that it’s hard to recognize as a scheduling task. Two illustrative aspects of scheduling will be discussed, scheduling for diagnostic modalities and scheduling for routine patient care tasks. Because it’s less understood (and frankly more interesting) we will look at scheduling for routine patient care tasks first.
Patient Care Task Scheduling
Patient care tasks encompass routine activities carried out by caregivers and/or aids. Examples of these routine tasks include vital signs collection, medication administration, bed turns (to avoid hospital acquired pressure ulcers, or HAPU), and respiratory circuit flushing (to avoid ventilator acquired pneumonia, VAP). These tasks must be completed at a predetermined frequency on a reliable basis or adverse events – including patient death – can result.Read More
Connectivity enabled medical devices send patient data right out of the medical device to a network, be it a body area network, cellular broadband network, home or enterprise network. The network then conveys this medical device data to databases and applications that store, display and manipulate the data. When a medical device is directly attached to a patient, there is no question as to which patient the device data belongs. As soon as the data leaves the actual medical device via the serial port or a network connection, the association of that data with a particular patient is no longer obvious.
Much of the data used in establishing and maintaining patient association or patient context comes from, or is stored in, the patient management database. Patient management workflow is an important enabling component in the overall connectivity solution and key to patient context management.
It is critical to reliably know that the data from a medical device belongs to a particular patient. If the data is not associated with any patient it’s worthless; should the data be associated with the wrong patient it could be deadly. When patient data from patient A is misidentified as belonging to patient B, patient A can miss out on a life saving clinical intervention that is mistakenly applied to patient B. In this example, patient A may die due to a lack of care, and patient B may be injured or die as a consequence of receiving some clinical intervention that is not needed and could be contraindicated. Consequently, safe and reliable patient association or patient context management is a foundational capability for virtually any medical device connectivity or interoperability solution.Read More
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