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
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
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