InnerWireless Inks Deal with Hospira
Smart pump vendor Hospira is the first infusion pump vendor to validate their medical device on InnerWireless' “Wireless Utility.”
MedNet® safety software can communicate over a hospital's wireless
network with modules in Hospira infusion devices, such as Plum A+®
(general infusion), Plum A+®3 (triple-channel), and LifeCare
PCA® (patient-controlled analgesia) medication management systems.
The InnerWireless Medical-grade Wireless Utility is a full-coverage
infrastructure that helps guarantee wireless coverage throughout the hospital,
linking key clinical data.
The press release also notes that 84% of hospitals in the U.S. have adopted wireless LANS (according to the latest HIMSS Leadership Survey).
Having to verify wireless medical devices for a specific kind of WLAN infrastructure represents a big barrier to adoption for deice companies. Rather than reprioritizing roadmaps, perhaps a better strategy is to avoid the revalidation altogether. I have some thoughts on that – anyone with an opinion or an interest in exchanging ideas is welcome to give me a call.
The Blogposium
Jack Mason, the master blogger at HealthNex, has organized a group of bloggers to embark on a Blogposium. The goal is to turn our individual blogs into a “collaboration
confederation” that will work together to add dozens of new entries to
the Clinical Informatics Wiki (Clinifowiki), an extension of the Clinical Informatics
Review. This experiment in “collaborative, paticipatory blogging” is our contribution to the industry and will hopefully add important content to the Clinfowiki. Here's a list of participants and their topics:
- Christina's Considerations on RegionalHealth Information Organizations
- Conmergence on Telehealth
- Drugwonks on FDA Critical Path Initiative
- eHealth on Integration of Personal Health Records and Electronic Medical Records
- EMR and HIPAA on ElectronicMedical Records and Biometric Integration
- Envisioning 2.0 on The E-Patient-Provider Relationship
- HealthNex Three topics: Patient Experiential Data, Genetic Privacy Issues and Biobanking
- HITsmit on e-MAR Systems
- HIT Transition on RHIO Startup Funding and Finance
- Informaticopia on International Perspectives on Clinical Informatics
- Medical Connectivity on Integrating Medical Devices into EMRs
News about the Blogposium has been picked up by eWeek and Business Innovation Insider.
So, here's the first draft of my contribution, Integrating Medical Devices into EMRs. Everyone's encouraged to provide comments, edits, suggestions, and criticism – either via email, comments to this post, or at the post on Clinfowiki.
Quantitative data from medical devices makes up a significant portion of a patient's electronic medical record.
The typical patient's electronic record will include trended vital signs data, notations for certain medical device alarms, and documentation concerning therapy provided. The types of data acquired from medical devices include discreet numeric data, waveform data, and events like alarms or when therapy was started and stopped. Some device data needs to be manually qualified, such as breath sounds or the patient's position when reading blood pressure.
Problems with the manual recording of medical device data are well understood. These problems include illegibility and incorrect data entry through transposition of data or entering correct data into the wrong field. Manual recording of data frequently results in delays in data availability; caregivers are frequently interrupted while capturing vital signs, resulting in delays in getting data entered into the chart.
Users adopting an EMR without medical device data integration often complain about “double entry” of data. This attitude is not the result of a workflow change (the only difference is typing data into a computer vs. writing it into a paper chart), but rather a change in the user's expectations. Users of an information system expect things to be automated and when basics like data acquisition remain manual tasks they become frustrated, impacting adoption.
Medical Device Categories
Devices feeding the EMR can be divided by location, one group of devices is found at the point of care, the other lies beyond the point of care in diagnostic and therapy departments. Devices found beyond the point of care are usually integrated through departmental information systems (PACS, cath reporting systems), or traditional physician or technologist reporting systems. Point of care devices can be divided into 4 categories; continuous-data devices, spot data devices, portable therapeutic devices, and portable diagnostic devices.
Continuous-data devices include patient monitors (including telemetry transmitters), “smart” infusion pumps and ventilators. These devices generate continuous data like waveforms, and generate life-critical alarms that must be rapidly communicated and displayed. These types of devices monitor patient parameters and provide surveillance through the display of real-time waveforms and/or alarms.
Spot data devices are used to take readings of physiological parameters on an as needed basis. The most common example is the spot vital signs monitor. These devices are moved from patient to patient to record vital signs at a frequency ordered by the attending physician. In the past some vital signs monitors were connected for extended periods to patients to take readings on a regular basis, e.g., every 5, 10 or 15 minutes.
An example of a portable therapeutic device would be a dialysis machine. These types of devices are rarely integrated; the technician must manually document their episode of care.
The final medical device category is the portable diagnostic device. This category represents quite a range of devices. Traditional portable diagnostic devices include ECG carts and portable diagnostic imaging modalities. Lab test are moving to the point of care with a variety of devices, some wirelessly enabled, and some deployed as “mini-labs” that are located on nursing units. Connectivity for this category of device is challenging, and rapidly evolving. Fortunately for those deploying EMRs, portable diagnostic devices will be integrated into separate diagnostic information systems that will feed diagnostic reports into the EMR.
Patient Context
Patient safety requires that data from medical devices be reliably associated with the correct patient. How patient context is established and maintained varies with the type of connectivity used, and impacts workflow and the reliability of data that flows into the EMR.
Medical devices that rely on RS-232 serial ports for connectivity are “dumb” – they know they are hooked up to a patient because they're generating data, but they have no knowledge of the patient's identity. Serial port connectivity relies on hardwired connections to a specific serial port and software on a back-end server to know which patient goes with which port. Patient context is typically established by a user at a central station who knows that patient X is in room Y. This type of connectivity is hard to deploy in a wireless environment because there is no fixed association between a port and a patient room or other physical location.
Medical devices with network connectivity are “smart” because they know the identity of the patient they are connected to. Establishing patient context at the point of care can be done by entering the patient's name or ID into the medical device, or selecting the patient from a list that is displayed on the medical device. This method is ideal for wireless connectivity because it is independent of physical location. Devices with network connectivity have the ability to display the patient's name, providing a visible check for proper identification and patient context.
There are a few devices that provide serial connectivity patient context through a hardwired network connection. These devices mimic a serial port by using a fixed IP address or MAC address to identify the device at a central station where patient context is managed. Current practice in hospital network management precludes the use of this scheme except on private networks.
The Nokia 3220 – The Ideal Remote Monitoring Computing Device?
It's fun to imagine new technologies for health care, especially gadgets like computing devices. Imagine a cell phone that can read and write RFID tags, capture data from medical devices, and run applications on the handset that interact with backend servers. You could do some very interesting things with a phone like this – patient identification, asset tracking and data acquisition for starters. With the RFID tag writing feature, you could create tags in the field for meds, DME (durable medical equipment like wheel chairs), or devices like oxygen therapy systems – all without a separete tag writer. You could also store or update transaction data in tags that are already deployed, creating data persistence between visits.
Interesting things could be done with a phone like this with patients. For example, you could write and deploy applications to track drug usage (including reminders when necessary). Patients would be issued blank RFID tags that they would write and
apply to meds for new prescriptions and refills. Their phone can remind
them when to take meds, and they can scan the RFID tag when they take
the medication. An application could even remind them when to get
refills. The could acquire physiological data from scales and other monitoring devices, and track/modify patient behavior for, say, diet and exercise. Remote patient monitoring devices don't need an expensive and power draining radio (as you'll see), nor does the home require a gateway and a physical connection to a phone line or broadband connection.
Well you've probably guessed the phone that does all these things is pictured at right. The Nokia 3220 is one of two Nokia GSM/GPRS phones that include an “NFC shell” that is used for reading and writing RFID tags (the other phone is the 5140). The RFID frequency used is 13.56 MHz, has a reading range of 2-5 cm, and conforms to ISO 14443A and EMCA 340 standards.
NFC stands for Near Field Communications and was initially developed by the same Sony/Philips partnership that brought us the audio compact disc. The technology was developed for smart cards, cell phones and other consumer electronics to automate transactions like credit card purchases, unlocking doors, or ordering online entertainment. The data link only works within a range of 8 inches or less. Data transfer is rather slow at 212 kilobits per second – this limits transfers to small amounts of data, so NFC is not likely to replace Bluetooth or Wi-Fi. An NFC chip costs around 20 cents, a Bluetooth radio compares at $4 to $5 per radio. Like passive RFID tags (actually exactly like passive tags) NFC is unpowered – the reader/writer excites the NFC chip with the reader's own RF energy. There's now an NFC Forum, whose members are the usual suspects (MasterCard, Nokia, Microsoft, Matsushita, Samsung, Sony, etc.) You can always tell when a new technology might make it when market studies start to come out – you can get one on NFC technology and market applications here.
Nokia also provides an infrastructure on which to build and deploy applications. For writing apps to run on the handset, they've got a Local Interactions Java SDK. On the server side, they provide connections to an SMS gateway, provide tag, location and event data, authentication and authorization, client provisioning, and administration. They also provide an external Web Services interface. When you visit the Nokia site, just ignore all the references to Field Force and Field Service, and imagine it says health care.
When I heard about this, my first question was deployment and carrier involvement. Current plans are to sell the phones through special health care resellers, and not through carriers. Resellers would buy SIMS from whichever GSM/GPRS carrier provided the best coverage in their area, put them in the phone and have them activated. One nice thing about this arrangement is that the phones won't be “locked” – i.e., coded so they will only operate on one particular carrier's network, and not any others.
Pretty cool, eh? The phone and related infrastructure is becoming available in the U.S. on a pilot project basis, so if you're interested, let me know.
UPDATE: A reader left a comment observing that this is not “new” news – and they're right. The NFC technology was introduced by Nokia at the end of 2004 (press release). This post is more about the application of Nokia's technology bundle in health care, and how it might be used.
Perhaps the biggest challenge for OEMs like Nokia and other members of the NFC Forum is getting third parties to build solutions using NFC technology. Making a phone with NFC built in is the easy part. It is a good sign that the “NFC shell” link above is currently the second most popular out-going link on this web site.
From an adoption stand point, this is still new technology. Sure it's already been on the gadget websites, but it has yet to be released in the U.S. My quick Google search didn't turn up any, you know, actual solutions you could buy using NFC – and certainly none in health care. Time will tell whether this not-so-new technology will be put to good use; let's hope so.
Smart Pump Technology – An Overview
I noticed a strange referrer in my servier logs today that lead me to this paper (pdf here) published in the AAMI Biomedical Instrumentation & Technology journal. In this paper, Ron Snodgrass presents an overview of smart pumps, with a focus on drug errors reduction systems (DERS).
The general purpose pumps of today have served the healthcare industry well because they offer clinicians broad range programming flexibility for dose rate and volume parameters that can treat the entire hospital population from infants to adults. For example, the infusion rate on most infusion pumps can be programmed to deliver as little as one drop per hour to as much as 1 liter per hour. At the same time, the volume to be infused settings can also be programmed to deliver in the wide range of 0.1 ml to 9,999 ml. Unfortunately, this combination of broad range programming and the flexibility of serving patients in all age groups exposes the potential for user programming errors and also opens the door to lethal doses or adverse drug events.
Ron goes on to lay out the drug errors reduction system value proposition.
Since today’s pumps rely heavily on human intelligence for programming without limits or restrictions, medication delivery errors are going to happen. To combat this problem, infusion pumps must be designed with the capability to place dose limitations on IV medications and provide clinicians the opportunity to double check their delivery settings before administering to their patients. Let me introduce you to the next generation of infusion pumps that offers these unique safety features known as “smart pumps.”
Smart pump is a term that was adopted by the Institute for Safe Medical Practices (ISMP) because these new infusion pumps are designed to significantly reduce medication errors (ME) and also because they provide pertinent data to support continuous quality improvement initiatives for increasing patient safety. Smart pumps incorporate software programs known as a dose error reduction system (DERS). Keep in mind, each manufacturer of smart pumps has its own unique name for their specific DERS program. Most DERS on the market today provide the following primary medication management safety features:
What caught my eye was the fact that this site was listed in a “For More Information” sidebar as a source for the latest on “Smart IV Pumps and Safety.” Thank you, Ron, for including this site.
Update on Spacelabs New Wireless Patient Monitors
One of the product managers at Spacelabs was kind enough to call me up the other day and fill me in on their new wireless patient monitors. I've written in the past about their new SL 2400 wireless monitor, and since then, Spacelabs has released the new SL 2600.
First let's talk about the radio. Spacelabs is using an off the shelf radio as I speculated before – they're using the Symbol CF (Compact Flash) 802.11b radio that's designed for embedded systems applications. This embedded radio card has a 5 year life cycle, rather than the 6 to 18 month life cycle that commercial radio cards have. This sounds like the same radio that GE is using in their new Dash.
Next let's look at encryption. Yes, all that stuff I said in my previous post about WEP was true; WEP is wimpy encryption. But, Spacelabs' implementation of security (the reason for encryption ) on their new monitors are good. First, Spacelabs applies their own application layer encryption to everything that comes out of the monitor and over the network. And like most monitoring vendors, they don't send waveform data with patient identifiers. Once patient context is established, waveform data is associated to the patient using internal codes. Finally, Spacelabs has validated their monitors with BlueSocket network security appliances for the truly paranoid among us.
When it comes to connectivity, Spacelabs has an advantage. Back when Carl Lombardi ran the company, he split it in two and created a medical device division and clinical information systems division, in the same company. I guess Carl was a visionary Connectologist. Now, Spacelabs finds itself a medical device vendor once more, but their history, along with some pretty intense training, has given Spacelabs an understanding of wireless connectivity that is arguably better than everyone else. Evidence of this knowledge can be seen in their approach to network integration – i.e., getting their medical devices to work on a hospital's network. Spacelabs has a detailed site survey they use, but beyond that every network is unique. They don't require a private subnet or a VPN, although VPNs are a common network design tool used to deliver performance for critical applications like medical devices or VoIP. Most medical device vendors do everything they can to keep their networks separate in order to reduce (to zero, hopefully) common variables found in general purpose computing environments.
The new SL 2600 sounds like a more feature-rich version of the 2400.
The UltraviewSL2600 is well-suited to a broad range of
environments, including perioperative, emergency and neonatal care
applications. The monitor's compact size and larger display, coupled
with advanced monitoring features, provide a flexible solution that
enables hospitals to augment their existing installation of Spacelabs
monitoring, as the new monitor has full network compatibility with all
existing Spacelabs UltraviewSL Ultraview® and PCMSTM centrals and bedside monitors.
Additionally, a wireless networking option supports central
surveillance during patient transport, when patients are often under
greater stress and risk, enhancing patient safety and improving
emergency response time. Together with Spacelabs' new Clinical Event
Interface to pagers and other handheld devices, these capabilities
serve to accelerate the flow of critical, time-sensitive patient
information to caregivers, regardless of patient or caregiver location.
UPDATE: I forgot to mention that Spacelabs has service menues on their wireless monitors that RF and network performance data that's sufficient to do a manual site survey. I also got this additional bolus of information:
When a “live” hardwired network connection is established, no wireless signal
strength indicator is displayed. (The radio turns itself off). However, unplug
the network cable and the wireless radio turns on automatically, and the signal
strength indicator is displayed.
This is
a useful feature that allows clinicians to determine what mode of networking (HW
or WLAN) the monitor is working off of. As well, the monitor allows for
separate IP network addressing for both hardwired and wireless networking
modes.
The signal strength indicator mentioned is the classic “chicken foot” with a multi bar signal strength meter that also indicates whether the radio is associated with an access point through color coding,
