Medical Connectivity

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

Medical Device Interoperability Workshop

Tim Gee — Sun, 17 Jan 2010 23:59:28 +0000

There is a FDA (CDRH) Workshop on Medical Device Interoperability scheduled for January 25 - 27 at the FDA’s White Oak Campus in Silver Springs, MD. Here’s a link to the meeting’s official web site, which includes a number of downloadable files on the agenda, meeting logistics and background.

There is little question the workflow automation and intelligence offered by interconnecting medical devices can improve patient safety. There’s also little doubt that there is significant market demand for such solutions. For example, if hospitals could purchase PCA pumps and SpO2 monitors that were interoperable, i.e., the monitor could suspend drug delivery at the first indication of respiratory arrest, such a capability would quickly become a standard of care. Interoperability is a huge opportunity.

There is no doubt that there are unintended — and in some respects, unregulated by the FDA — systems of systems made up of medical devices sold and in use by health care providers. At the most basic level, there are medical devices with serial ports that were never intended to provide connectivity (or Medical Device Data Systems as the FDA called them in a draft rule issued almost 2 years ago). At the other extreme, you have systems like closed loop infusion therapy delivery, made up of components that are both regulated and unregulated, and that were originally developed with little or no thought to the demands of interoperability. This is a problem.

The FDA’s been interested in this area for some time. Way back in 2005, the FDA held a workgroup to discuss the system of systems issue regarding networked medical devices (see the blog posts here, here and here). The outgrowth of this meeting was IEC 80001, which is scheduled to be completed this year. In 2007, the FDA published an excellent draft guidance on wireless medical devices (posts here and here) on how to apply the Quality System regulation to wireless medical devices. (I can’t help but wonder why this is still a “draft” guidance.) Also back in 2007, the FDA provided a rather limp statement on interoperability at the 2007 conference on Medical Device Interoperability and High Confidence Software (see the posts in this search). (Offered as the first example of the FDA’s interest in interoperability is their dubious buy-in to the questionable patient safety benefits of new medical device unique device identification requirements was not inspiring — more here.) (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…)

FDA Posts New Draft Guidance on Computer-Assisted Detection Devices

William Hyman — Mon, 09 Nov 2009 17:03:16 +0000

It may be helpful to compare these new guidances with the pending MDDS rule, discussed here, in which the proposed rule defines an MDDS as Class I, the class with the lowest FDA scrutiny. Unlike MDDS, in the current case these CADe devices are not newly defined. However the FDA does acknowledge that the terminology may not widely known or used. A CADe system is not in the same class as an MDDS, and therefore is not an MDDS, because of the degree to which it analyzes medical device data.

The Federal Register posting defines CADe’s as “computerized systems that incorporate pattern recognition and data analyses capabilities (i.e. combine values, measurements or features extracted fro the patient radiological data) intended to identify, mark, highlight, or in any other manner direct attention to portions of the an image, or aspects of radiology data, that may reveal abnormalities during interpretation of patient radiology images or patient radiology device data by the intended user (i.e., a physician or other health care professional)”. As with the MDDS rule, it can be helpful to know what is excluded from the category as well as what is included. Here certain types of systems are defined to not be CADe. These include:

CADx devices (which) are computerized systems intended to provide information beyond identifying, marking, highlighting, or in any other manner directing attention to portions of an image, or aspects of radiology device data, that may reveal abnormalities during interpretation of patient radiology images or patient radiology device data by the clinician. CADx devices include those devices that are intended to provide an assessment of disease or other conditions in terms of the likelihood of the presence or absence of disease, or are intended to specify disease type (i.e., specific diagnosis or differential diagnosis), severity, stage, or intervention recommended. An example of such a device would be a computer algorithm designed both to identify and prompt lung nodules on CT exams and also to provide a probability score to the clinician for each potential lesion as additional information.

Computer-triage devices (which) are computerized systems intended to in any way reduce or eliminate any aspect of clinical care currently provided by a clinician, such as a device for which the output indicates that a subset of patients (i.e., one or more patients in the target population) are normal and therefore do not require interpretation of their radiological data by a clinician. An example of this device is a prescreening computer scheme that identifies patients with normal MRI scans that do not require any review or diagnostic interpretation by a clinician. (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…)

What (if anything) can the recent Sidekick problem teach us?

William Hyman — Tue, 27 Oct 2009 21:32:26 +0000

On October 12 the NY Times headline read “Some Users May Lose Data On a T-Mobile Smartphone”. Those phones use software and support from Microsoft/Danger for their data applications. According to the article a “technical glitch” had resulted in customers losing personal information held on at least in part an associated cloud computer service. Another story here by Eric Savitz, led with the question: “So how sure are you that you want all of your data to live in the cloud?”

The precursor to the Times story had appeared earlier in a number of places including here on October 5^th. At that time the issue was reported as a loss of data service as opposed to a loss of data, although it was noted that a reset could cause loss of the user’s contacts and calendar. On the 11^th it was reported here that the data may be lost for good, but then on the 13^th it was said here that maybe not all of the lost data was permanently lost. Apparently Microsoft/Danger was being run on a single server.

While there is no direct association of this situation with medical information (unless your doctor’s contact information was among the stored data), it should serve as yet another reminder that the connected world, and its operational software and hardware, is not without its own issues. When new medical applications are being discussed there seems too often to be a suspension of reality with respect to system functionality, data reliability, and data availability. Whether it is “just” an EMR/EHR, or it is more direct functionality (e.g. an alarm or communication system), or even a single device, it must be remembered that software anomalies (a nice word meaning it sometimes doesn’t work) are more common than rare, and that reliance on “the network” to perform as imagined can often be a false reliance.

In case there was any doubt of this, software is a fairly common cause of FDA mediated medical device recalls. The FDA’s recall datebase has a Simple Search function. Entering “software” without date limits brings up 500 hits, the systems maximum. Limiting the search to 2009 (through 10/21/09) on the Advanced Search produces 62 hits. The most recent of these involves a “software bug” cryptically reported as “The … flag is configured incorrectly. The flag is not generated according to system requirements.” A “software update” is said to be forthcoming.

As I have noted elsewhere, the software industry really needs to be congratulated for its use of the term “upgrade” to mean fixing something that was never right in the first place. The second most recent recall had an equally cryptic explanation: “There is a potential safety issue with … 3.0.x software where study split operations are not correctly replicated to a secondary ’shadow’ archive”. (more…)

Impact of Modifying FDA Regulated Devices

Tim Gee — Sun, 25 Oct 2009 19:47:46 +0000

Off Label Use

In a previous post, Medical Device System Network Install Issues, I suggested that when health care providers don’t follow medical device manufacturer’s specifications when installing medical device systems they were using the system “off label.” This site’s latest contributing author, William Hyman, provides an alternative perspective:

My interpretation of off-label use has been that it pertains to the actual use of the medical device, not the way it is set-up. Thus it isn’t off-label use until it is actually used, and use here is with respect to the Indications for Use, which do not generally address set-up and configurations as opposed to what the device is for.

Therefore a set-up or installation that is different from the manufacturer’s recommendations/specifications may be a modification rather than an off-label use. Other types of reconfigurations and changes would also be a modification.

Practice of Medicine Doctrine

Off label use is unregulated per the “practice of medicine doctrine,” but comes with some risk management issues. Also please note that this doctrine applies to physicians, not health care provider organizations. According to Hyman:

This is more than a semantic distinction. Off-label use of a medical device, at least by physicians, is legal and unregulated. This of course does not necessarily mean it is safe, smart, or well justified. The defense of an unsafe off-label use (if necessary) would be an after the fact liability matter, not a regulatory matter. However hospitals might be wise to have their own controls on off-label uses and require appropriate justifications.

After some research, I found that there’s very litte published — by the FDA or others — about the issue of post-market regulated device modification, especially by health care providers. Hyman delivers more: (more…)

Canada Posts “Medical Device Data System” Rule

William Hyman — Wed, 14 Oct 2009 16:44:11 +0000

On August 31, 2009 Health Canada, Canada’s medical device regulatory authority, posted classification information for Patient Management Software (pdf). This action is similar to the FDA’s proposed rule for the regulation of Medical Device Data Systems (MDDS), nearing finalization. The Canadian announcement begins with a reminder of its definition of “medical device” which is similar to although not identical to the U.S definition. This definition includes Patient Management Software as a medical device. In addition, Canada defines an “active” device as one that requires an energy source, and “active diagnostic device” as one that is intended to supply information for the purpose of detecting, monitoring or treating a physiological condition, state of health, illness or congenital deformity. Based on these definitions patient management software is declared to be first a medical device, and then an active medical device.

The next question is the appropriate classification of this type of active medical device under the Canadian classification system. The Canadian system has four device classifications which is similar to the European system. The U.S., of course, has three classifications.

Patient Management Software that is used only for archiving or viewing information or images, and is not involved in the primary acquisition, manipulation or transfer of data is deemed to be a Class I device. This definition is somewhat more restrictive than that for a U.S Class I MDDS. Any Patient Management Software that goes beyond these restrictions is a Canadian Class II device. Furthermore such software is categorized as an active diagnostic device. This includes software involved in data manipulation, graphing, flagging of results or performing calculations. Workstations that interface with such software are then also in Class II. The inclusion of the work station appears to directly address the illusive question of when does a computer become a medical device. As a result of these new distinctions some software that was previously Class I (in Canada) will now be Class II. The manufacturers of such systems sold in Canada have been granted a one year transition period to meet those aspects of Class II regulation that are different from or in addition to those for Class I. This defined transition period is a more explicit statement than the FDA has provided in the draft MDDS rule.

The distinctions between system functions made in Canada are somewhat different from those initially defined by the FDA for MDDS. None-the-less they reflect essentially the same issues and concerns which are that (1) any software that receives and manipulates patient data is a medical device, and (2) that the appropriate classification depends in part on exactly what the software does with the data. Only minimal data handling activities are in the least stringent regulatory classification, while classification and therefore regulatory scrutiny will increase along with the sophistication of what the software does.

Market Trends Series #2: Patient Safety

Brian McAlpine — Thu, 01 Oct 2009 18:30:37 +0000

This is the second post as part of an ongoing series that discusses the market trends that are affecting the evolution of medical device connectivity (MDC) technology. I received some good comments from my previous post – please consider sharing your thoughts, ideas, and experiences.

The second trend I’d like to discuss is the shift towards patient safety as one of the key market drivers for connectivity. It is probably not news to anyone that patient safety has become one of the key drivers for many healthcare IT initiatives. But what is the relationship between patient safety and MDC? Ever since the often referenced IOM report, To Err is Human: Building A Safer Health System, hospitals and vendors alike have increased their focus on driving towards significant reductions in medical errors. The industry as a whole has made great strides, but still lots of work remains.

With device connectivity, my experience has been that for at least the past 15+ years, the key driver has been making the nurse more efficient by eliminating the manual transcription of device data into the patient’s chart. One of the related benefits is a more come complete and legible patient record. However, one could argue that the more legible patient record could be achieved if the vital signs from medical devices were simply typed into the charting application manually (something that many hospitals are actually doing today). So I believe that the nursing efficiency argument holds as the primary driver – but that is starting to be challenged by the focus on patient safety as it relates to connectivity.

(more…)

FCC Seeks Comment (Again) on MBANs

Tim Gee — Thu, 24 Sep 2009 05:48:34 +0000

Some semi recent news on Medical Body Area Networks (MBANs) from GE Research and the FCC. It starts with GE’s September 1, 2009 press release (pdf), where they announced:

…an intiative aimed to develop wireless medical monitoring systems, or body sensor networks (BSN), which would replace the traditional tangle of bedside caables used to capture a patient’s vital signs. GE’s vision for the systems would enable wireless monitoring from anywhere in the hospital — or even remotely at home.

For the past couple years, GE’s been pushing for the allocation of spectrum for MBANs. The press release notes that, “The FCC recently issued a notice of proposed rulemaking (NPRM), acting upon GE Healthcare’s petition to establish a new, vendor-neutral dedicated radio frequency band for low-power, short-range, wireless patient monitoring devices. This petition requested creation of a new Medical Body Area Network Service (MBANS), to support wireless sensors that monitor a patient’s health state, linked together in body sensor networks.”

Here’s David Davenport talking about their wireless sensor initiative:

Apparently, GE’s going after the cable replacement business for traditional multi parameter patient monitors. LifeSync has had a product replacing ECG cables (by far the most predominate type of cables in clinical use) for several years. LifeSync also controls the Besson patent (licensed to them exclusively by Motorola) that applies to wireless sensor based physiological monitoring.The FCC Notice of Proposed Rulemaking referenced is from June 29, 2009. Another “article” written by a law firm apparently engaged by GE was published March 20, 2009 and outlines:

Proposed Frequency Band: ”identified the 2360-2400 MHz band as the preferred frequency band based on engineering studies showing that MBANS devices can successfully coexist with incumbent operators and users.” I would love to see that coexistence data. In a conversation with David Davenport of GE Global Research that, he told me that spectrum just outside 2.4 GHz was desired because it would enable the use of off the shelf 2.4 GHz components, with only minimal modifications. (more…)