Medical Connectivity » Healthcare IT

The 25 Elements of “Meaningful Use”

William Hyman — Tue, 09 Feb 2010 17:30:43 +0000

The Recovery Act that initiated the process of providing incentive payments for the adoption and use of Electronic Health Records (EHR) included the provision that such systems support “meaningful use” if they are to be certified and funded. Of course if you have to have meaningful use, then meaningful use has to be defined, and them measured. After a round or two of proposals and comments, CMS issued an Interim Final Rule on December 30, 2009. (The idea that a Final Rule can be Interim is itself a masterwork of government speak.) The governments discussion of this process is available here. The Interim Final Rule itself (which runs over 30 pages) is entitled “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology; Interim Final Rule” and it is available here. A companion rule posted in the Federal Register (FR) on January 13, 2010, “Medicare and Medicaid Programs; Electronic Health Record Incentive Program; Proposed Rule” is available here. All of this is part of the Health Information Technology project in the Department of Health and Human Services which is lead by Dr. David Blumenthal who is the National Coordinator for Health IT.

These rules defines 25 functions that together constitute meaningful use. Each of these also has a level of performance that is required for ultimate certification (as listed in the January 13th FR). For example, the first use (see below) of “Use Computer Provider Order Entry (CPOE)” has the criteria that it is used for at least 80% of all orders; but only 10% for hospitals. How an EHR is actually used by the provider is an interesting and important distinction from what the system is capable of, i.e. if the system provides for CPOE but if the users don’t use that capability to an adequate degree, then by these definitions meaningful use is not achieved. Thus what the EHR can do is a necessary but sufficient condition to establish its certifiablity.

The 25 elements and an abbreviated statement of the associated measures are:

1. Use Computer Provider Order Entry (CPOE) (80%/10% hospitals)

2. Implement drug/allergy checks (Enabled)

3. Maintain an up-to-date problem list of current and active diagnoses (80%)

4. E-prescribing (Eligible Professional (EP) only) (75%) (more…)

Tim Gee Affiliates with Santa Rosa Consulting for Provider Consulting

Tim Gee — Thu, 31 Dec 2009 05:01:56 +0000

This month marks the end my 5th year as an independent consultant. Over that time, I’ve had the opportunity to complete many great projects for a variety of clients, large and small. A basic objective has always been to provide services to both manufacturers and health care providers. The general knowledge gained — both current trends and the depths of complex issues — from working with providers has always benefited my manufacturer clients, the same holds true for providers based on the perspectives gained working for manufacturers.

While I’ve done projects for some great health care providers (Providence, RWJUH, Spectrum and Partners), most of my business has been on the vendor side. This past fall Marilyn Hailperin of Santa Rosa Consulting contacted me about working for their firm. We have entered into an agreement where all of my consulting for health care providers is done through Santa Rosa, while I continue to pursue consulting business with manufacturers as Medical Connectivity Consulting.

Santa Rosa Consulting was founded this year by Richard Helppie, the founder, Chair and CEO for Superior Consultant. One of the hospital consulting market segments Santa Rosa is targeting is point of care workflow automation and medical device integration. Here’s more from the press release:

As part of the Santa Rosa team, Mr. Gee will provide consulting services related to point-of-care technology strategy development, clinical workflow optimization, technology vendor selection, risk management of converged medical device/enterprise networks, and support for Santa Rosa’s PCDI [Patient Care Device Integration] implementation team.

Santa Rosa Associate Partner and National Practice Director for PCDI, Marilyn Hailperin, says, “We are pleased to have someone of Tim’s caliber on our team. He has long been an advocate and recognized authority on medical device connectivity. Tim brings essential real-world knowledge and expertise to our clients to maximize their investment in point-of-care technology, achieve the benefits of patient care device integration with information systems, and attain “meaningful use” certification with respect to medical device interoperability.”

While Santa Rosa gets to use me in their provider practice, my provider clients also benefit in a number of ways: (more…)

Market Trends Series #3: Shift from Dept to Enterprise Focus

Brian McAlpine — Wed, 04 Nov 2009 00:32:52 +0000

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 are (more…)

Medical Device System Network Install Issues

Tim Gee — Tue, 22 Sep 2009 16:37:19 +0000

Last week there was an interesting discussion on the Biomed Listserv about network installation for patient monitoring systems. Emphasis highlighting key issues and best practices are mine. The discussion started with a question from Scott Skinner:

I’m curious if anyone has been successful using their own vendors to pull cables for monitoring installations. With the monitoring OEM we work with, they simply get a local subcontractor to do the cable pulls.

So this would involve breaking future monitoring packages up into two quotes: one for the actual technology itself (and associated installation and implementation), and then one for just the cable pull work. The latter would get bid out, and the OEM could compete against other vendors.

Of course, the OEM can just take the profit they would have made on the cable pull and add that to the cost of the equipment bid. One would need to find a way to watch that carefully.

Which lead to a critical observation from Craig Muehling:

We have started pulling our own cable for monitoring installations. I have one happening now and I’m not exactly pleased how it’s working out. I won’t mention and names, [vendor name removed] but they make their equipment charges per drop whether you have any drops or not.

I would still like our [networking] vendor to do the networking, ie: install and configure switches and physically plug patch cables into the switches. Seems easy, but the way they [the patient monitoring vendor] charge it’s really not much less than if they did the whole job. I think from now on, we will have to take on the entire networking job.

I have learned a lesson from this last installation and will scrutinize the quotes closer from now on, but with their charging structure
(supposedly) there’s not a lot of options. Either we do the entire job, or they make lots and lots of money for relatively little work.

Here’s how they do it at the Mayo Clinic, from Steve May:

We have our own low voltage and high voltage contractors for all in-house cable pulling, to include data pulls and all project related work, so cable pulling and wiring costs are never part of an installation package, but an infrastructure cost which we earmark as Capital expenditures and plan/budget annually. Bids & labor costs are renewed by Purchasing every 2 years and our preferred contractors are all able to bid on both project services & time & material services. (more…)

It’s All About Workflow

Tim Gee — Thu, 03 Sep 2009 00:58:45 +0000

Okay, it’s not all about workflow, just mostly, as you’ll see.

A while back Ann Farrell was nice enough to bring an interesting paper to my attention. Titled, “Workarounds to Barcode Medication Administration Systems: Their Occurrences, Causes, and Threats to Patient Safety” the paper is a fascinating read for several reasons. The authors studied barcode medication administration systems (BCMA) at 5 hospitals, and identified 15 types of workarounds and 31 types of causes of workarounds. This paper provides the most detailed and comprehensive description of product and implementation shortcomings centered on the point of care that I’ve ever seen. It’s devastating. Really.

So what’s this got to do with medical device connectivity? Two words: workflow and barcodes. Medical device connectivity is the automation of workflow through the integration of medical devices and information system. Likewise, BCMA is the automation of workflow through the use of auto ID (barcode labels and scanners) and information systems. With connectivity, attention centers on the connection; with BCMA, attention centers on the barcoding. Where should the attention be focused? Workflow.

Workflow is the Rodney Dangerfield of point of care systems. Everyone, manufacturers and clinicians both, focus on the tangible stuff, like serial cables and network connectivity or barcodes and readers. The invisible stuff, like water is to fish, is the workflow that occurs at the point of care. There are two key workflow data points that are required for a well designed product. First is capturing the complete workflow process in which the technology solution is to be used.

Framing the workflow should extend beyond the scope of the actual product, so that everything flows well at both the initiation and end of the workflow. Whether you’re a provider looking to define requirements for a vendor selection process, or a manufacturer developing a new product, use cases are an ideal tool for capturing workflow. Use cases are easy for non-engineers (product managers, application specialists, clinical analysts) to understand and use and can be structured to provide engineers with something that can easily be translated into software specifications. (more…)

Converging Medical Device and Enterprise Networks

Tim Gee — Thu, 21 May 2009 04:23:48 +0000

On Thursday, May 21, 2009 WAV Distribution and and client Summit Data Communications are hosting a web seminar on Converging Medical Device and Enterprise Networks, with yours truly.

As automation converges ever closer to the point of care, medical device systems are increasingly coming to the attention of hospital IT departments. Applications like EMRs, alarm notification, and enterprise-wide deployments of medical device systems are all driving the convergence of private medical device networks with the hospital enterprise network.

Consolidating medical device networks onto the enterprise network eliminates “islands of information” and supports broad deployment of systems like smart infusion pumps and point of care diagnostic testing devices. Moving medical devices from private networks to enterprise networks, however, can prove challenging.

This webinar explores the special requirements medical device systems place on an enterprise networks and provides best practices for creating safe and effective converged networks. Topics covered include: regulatory issues, networking specifications, vendor selection, implementation and management for converged networks.

You can register for the webinar here. I’ll post links to the recorded webinar and a downloadable version after the event.

UPDATE: You can find the webinar listed at Wav Wireless Outfitter’s site, here, and view a stream of the recorded webinar here. You can also download a copy of just the presentation here (4.4Mb pdf).

Medical Device Networks Trouble Industry

Tim Gee — Fri, 19 Dec 2008 01:33:31 +0000

Over the past few years, medical device networking has become increasingly problematic. There is a growing perception of declining service levels and network reliability. (I’ve not seen or heard about any quantitative data to back this up - let me know if you’ve got any - but these are substantive issues.) As medical devices, by way of connectivity and workflow automation, have been pulled into the sphere of the IT department risks to patient safety have increased.

These growing problems are a key factor in the creation of IEC 8001 - which will have a major impact on how hospital’s deploy and manage networked medical devices. The current situation provides a lot of the impetus behind a meeting this week at Villanova on wireless technology in health care. So what’s the big deal?

Private Medical Device Networks

In the good old days, all medical device systems operated on private networks that were designed, installed and supported by the medical device vendor. Vendors decided exactly how the would handle IP addressing (static or DHCP) and every other configuration option. This minimized vendor’s product development costs, shortened time to market, and made service and support easy (because the network was their sandbox). When they got the inevitable calls from customers that, “your system just brought down our network,” vendors could quickly and easily determine if that was the case - and just as importantly, quickly prove to hospital network administrators why their answer was correct.

Providers benefited from this approach in a number of ways. First, vendor system support was quick, efficient and reasonably priced. This approach also relieved hospitals of the need to assume responsibility for supporting life critical applications themselves.

Of course nothing’s perfect, and relying on private networks created a few problems of its own. As more medical devices evolved to become components in medical device systems connected by networks, these private networks proliferated. The IT department of a thousand bed hospital system on the east coast did a survey a couple years ago of their networked medical device systems, and “discovered” over 200 private networks. And unlike enterprise networks that must be kept up to date to ensure cross vendor interoperability and coexistence, private medical device networks are like time capsules. With the exception of occasional failures of a switch or router, medical device networks remain unchanged from the day they’re installed; the hospital mentioned earlier found numerous ThickNet and ThinNet Ethernet networks in their survey of medical device systems.

Over time, medical device vendors have given some ground by moving from physically separate private networks, to creating logically separate private networks through the use of network switches and routers. (more…)

Updated Standards Aim to Encrypt Wired Networks

Tim Gee — Tue, 14 Oct 2008 00:06:36 +0000

Securing Ethernet networks has not received the interest that wireless LANs have gotten, for a variety of reasons.

Physical layer security is viewed by most IT professionals as a low-priority problem because cables are run behind walls or in ceilings, beyond the accessibility of most people. Wiring closets and data centers often are locked, and anyway, there are easier ways to subvert a network than by recabling it.

With all those open RJ47 Ethernet jacks everywhere, it would seem to me that someone interested in data would just plug in, rather than recabling anything. The aforementioned security is done with encryption, and the standards are 802.1AE and 802.1X-REV. The first standard ensures the integrity and privacy of data between peers at Layer 2 (switches and NICs). The second standard, 802.1X-REV is currently being revised to automate the authentication and key management requirements for 802.1AE. If you’re a networking rocket scientist, you can read more about the potential implications for these revised standards here.

With their concerns about security and HIPAA, will health care enterprises move to encrypt the physical layer? Such an option will be increasingly possible, according to this Information Week story from last week (emphasis mine):

You’ll be answering that question in the next few years as two new network security protocols come to a switch near you. Together, these two protocols–IEEE 802.1AE-2006, Media Access Control Security, known as MACsec; and an update to 802.1X called 802.1X-REV–will help secure Layer 2 traffic on the wire. 802.1AE is a completed standard and will be appearing soon in hardware. 802.1X-REV could be ratified as early as the first quarter of next year. (more…)

First Connectivity Cover Story in Leading HIT Mag

Tim Gee — Wed, 24 Sep 2008 23:20:11 +0000

Connectologists rejoyced this month (September, 2008) when Healthcare Informatics magazine published Biomed Joins the Party - Savvy CIOs are considering biomedical devices in their overall strategic plans (link). To my knowledge, this is the very first cover story in a major health care IT magazine about medical device connectivity. As an aside, diagnostic imaging pubs have been writing about connectivity in their market for many years.

Contributing editor, Mark Hagland, casts the drama that is connectivity as “two worlds colliding,” - the worlds of IT and biomedical engineering. He builds his story around the integration of medical devices to support EMR charting. In fact, medical device connectivity started almost 20 years ago with the integration of Apple IIs and IBM PCs (not to mention a few funky HP mini computers) in diagnostic areas like the cath lab and in the ICU. Probably the biggest wave of connectivity to date has been PACS (picture archiving and communications systems) and the adoption of DICOM. Now the health care industry is zeroing in on connectivity at the point of care with patient monitors, smart infusion pumps, point of care testing, and yes, EMR integration (by far the most expensive point of care application).

Using Trinity Health as his template, Hagland describes an ideal approach to medical device connectivity: the involvement of IT, clinicians, and biomedical engineering. The 40 odd hospitals in Trinity’s system have over 110,000 medical devices. Trinity has used this approach to more effectively manage these colliding worlds:

The biomed integration initiative actually began several years ago in an effort to cut costs, Fierens [the hospital exec over Biomed] reports. But as Project Genesis [their EMR project] has moved ahead, and as the technology in the biomed equipment area has advanced, the broader goals of improved care quality and workflow have come more fully into focus, he says. The biggest challenge, says Fierens, is that “you’ve got to balance the economics with the infrastructure and support, along with the service element, along with the clinical outcome you’re trying to support.”

The route to medical device connectivity for hospitals is neither clear or straightforward. (more…)

Scalabilility Challenges Wireless LANs

Tim Gee — Fri, 19 Sep 2008 22:22:50 +0000

When thinking about wireless networks in hospitals, most people think about coverage, and coverage is certainly an important requirement. A network performance metric that is less obvious but perhaps even more important is capacity. Capacity refers to the number of clients associated with an access point (AP) and the total bandwidth that’s available in a given location.

All of this was once again brought into focus for me during a conversation with Phil Belanger, founder and chief marketing officer for consulting firm Novarum. Phil has been in the wireless LAN market a long time, starting with Zilog and Corvus and served as co-chair for the IEEE work group that defined part of the initial 802.11 wireless LAN standard. He ended up at Cisco when they acquired Aironet.

As more medical devices incorporate connectivity, the number of potential WiFi clients around a patient increases. For example, let’s imagine a patient with 5 B Braun infusion pumps, each with its own WiFi radio. Add to this a Dash patient monitor and a ventilator; the Dash has embedded WiFi and the vent has a third party wireless module. Besides these 7 wireless clients, each caregiver has a wireless VoIP phone and most physicians also have WiFi devices (PDAs or smart phones).

Now imagine that there are similar patients in just 3 near by rooms. What happens when a code is called in one of those rooms and 3 caregivers, and a bit later a couple physicians respond. Let’s see, that’s 7 wireless devices times three patients, for 21 active associations with the network. Of the 5 people responding to the code, say 2 of them are having wireless VoIP conversations (say with specialist, or looking for a STAT diagnostic test result) and 1 is charting the code on a COW. That’s 24 associations.

What happens if an acute care patient being transferred goes by, adding 3 more associations and another wireless VoIP call? Or another code is called in the same vicinity? Do calls get dropped and the means to receive urgent information is lost? Are associations with the network lost by medical devices? Which ones? Could it be a device connected to a lone patient in a private room? Might life critical alarms be missed? (more…)