Medical Connectivity » Standards & Regulatory

Riegel v. Medtronic

Tim Gee — Wed, 05 Mar 2008 02:25:51 +0000

On February 20, 2008 the Supreme Court ruled on Riegel v. Medtronic. The patient Charles Riegel and his wife brought the suit after Riegel was injured by a Medtronic balloon catheter during an angioplasty procedure in 1996. The ruling is a clear loss for the tort bar wishing to bring suit for negligent or inadequately labeled PMA devices. More background from the SCOTUS BLOG:

The Riegels’ claims alleged that the catheter had been negligently designed, labeled, and manufactured, that Medtronic was strictly liable for Riegel’s injuries, and that the company had breached express and implied warranties.

Medtronic moved for summary judgment, arguing (inter alia) that the Riegels’ claims were preempted because the Food and Drug Administration (FDA) had approved the catheter pursuant to its premarket approval (PMA) process. The PMA process is codified in the 1976 Medical Device Amendments (MDA), 21 U.S.C. § 360c et seq., to the Federal Food, Drug, and Cosmetic Act (FDCA), 21 U.S.C. § 301 et seq., which substantially broadened the FDA’s authority to regulate medical devices. The specific provision at issue, 21 U.S.C. § 360k(a), provides, with respect to medical devices, that no state may establish any “requirement” that is “different from” or “in addition to” any federal requirement, or “which relates to safety or effectiveness of the device” included in a requirement applicable under the MDA[.]

(more…)

FDA Issues New MDDS Rule

Tim Gee — Sat, 01 Mar 2008 22:14:45 +0000

On February 8, 2008 the FDA published a proposed new rule for public comment (pdf version). The new rule provides some definitions of connectivity software and proposes to reclassify some types of connectivity software. The rationale for the proposed rule is as follows:

Since 1989, the use of computer-based products and software-based products as medical devices has grown exponentially. In addition, device interconnectivity and complexity have grown in ways that could not have been predicted in 1989. This growth and expansion have created new considerations for elements of risk that did not previously exist.

Up to this point the FDA has relied on their “Draft Software Policy” published in 1989 (link - pdf). This software policy recognized that software could (and did) meet the definition of a medical device and extended the FDA’s purview from conventional devices to software. This was not a bureaucratic land grab, but a recognition that the legal definition of a medical device could and had been met by software.

What is an MDDS? From the proposed rule (emphasis mine): (more…)

IHE PCD Connectathon - Is Your Vendor There?

Tim Gee — Tue, 29 Jan 2008 18:51:34 +0000

The IHE North America kicked off their Connectathon yesterday. This is the second year (?) that the Patient Care Device domain (PCD) has had something to show in the Interoperability Showcase at HIMSS.

I chatted with Todd Cooper via Skype and received the following update:

As background, there are approximately 390 engineers from 70 companies and 2 university groups connecting 136 different systems. On the PCD side, we have the following groups participating:

B.Braun

CapsuleTech

Draeger

Epic

GE Healthcare

LiveData

Philips

SpaceLabs

Welch Allyn

The profiles being tested are primarily focused on device data gateway reporting to enterprise applications (this fall the PnP profile will start active testing), and includes the basic PCD-01 message from last year (an HL7 v2.5 message with ISO/IEEE 11073 semantics - a consistent message format containing consistent device-related semantics). Also there is a profile for how these “gateway” systems handle patient demographics data and bind patient ID’s to the data streams, as well as use an HL7 Publish/Subscribe mechanism for configuring which information should be reported.

As for process, each vendor has a set of stand-alone, one-on-one and one-on-many tests. Once they think they have things working and are ready for verification, they call over one of the Monitors (independent observers) who observe each step of the test, and if all works, approve the verification or if they don’t work … have the companies go back and figure out what’s wrong, etc. For example, earlier this afternoon two companies thought they were ready. OK - “change that parameter” … “Hmmm…didn’t ever change on the other side … Call me when you’re ready!”

Reps from IHE and the PCD are discussing how devices will be integrated into the upcoming HIMSS ‘08 IHE Showcase. Including medical devices for the first time last year clearly brought out the need to move from the cold I.T. world to include the clinical environments that they are supposed to be supporting … hmmmm…go figure! Last year PCD was in the Showcase, but mostly a separated area. This year, they will be integrated to the overall story line.

Most of the vendors participating in this year’s PCD Connectathon have products in markets where verified IHE support is a key part of the vendor selection process. All of the current participants recognize that it is only a matter of time until such requirements will be applied to patient monitors, infusion pumps, ventilators and other types of medical devices.

Vendors who wait much longer to get involved in the PCD will end up implementing connectivity solutions defined by other vendors, and will have a growing body of work to “catch up” to vendors who jump in early.

Providers are encouraged to participate as well — unless you’re okay with everything designed to convenience vendors rather than users. So far, Kaiser and Partners have been the only provider organizations to participate.

Pictured at top is a view of GE’s workstation at the Connectathon, courtesy of Todd Cooper.

Is Microsoft HealthVault Safe?

Tim Gee — Thu, 25 Oct 2007 20:41:43 +0000

Many have criticized HealthVault regarding privacy and security concerns, or perceived limitations of HV as a personal health record (PHR). I suspect that HV is challenged more by the market's perception of Microsoft's long running security issues than with any actual shortcomings of that type in HV. And since HV is not a PHR, but rather a “platform,” criticisms about any lack of PHR features is not relevant.

One topic I've not seen addressed is the safety and effectiveness of the data within HV - and I don't mean “safety” as in the data is secure from unauthorized access or misuse. I mean “safety” as in the utilization of data stored in HV by other applications won't result in an unsatisfactory patient outcome, you know, like death or injury.

Certainly at first blush HV does not fall under the FDA's purview, but things could end up that way. (More on this later.) A key tool mandated by the FDA's Quality System regulation (QSR) to ensure quality and safety is the risk analysis. Any kind of connectivity needs to be thought of with risk analysis in mind - what can go wrong and how can those risks be mitigated?

If HV is more than just an interface engine, pushing data from one application to another, the risks are narrow. Sample risks include: data corruption during transfer into or out of HV, and data corruption during conversion of the data from one standard format into another. Mitigating these risks is straight forward; common data communications techniques to ensure data quality, and design and testing of the HV platform itself to verify data conversions are done accurately and reliably.

What if HV is more than a translator, but a repository of patient data? Most applications have a database that is written, updated and controlled by that application. It is the application that ensures that the data in the database is correct and valid. It is the application that provides the workflow to safely and reliably validate, edit and update data.

How is data quality ensured when various applications can read and write that resides on HV? Let's say data is edited or a calculated value is generated and then rewritten to HV. Does it overwrite the existing data? If there are multiple sets of the same data, how do you know which set is the best and most accurate data? Do you assume that the most current values are correct? What if they're not? What if that “better” data is not rewritten to HV but remains in the clinical information system in which it was generated - and another application comes along and uses the “wrong” data?

HV does track the properties, history and sharing of patient data. It also logs the time received and the source of the data. (You can see more detail in this page from the HV Developer Center.) Is this sufficient? Perhaps. What seems to be missing is the logic that controls the workflow between various applications, both what they do to the data and how they use it. Also needed is a formal verification process to ensure that any logic concerning HV data is implemented properly between applications, which is not mentioned on the HV Going Live! page.

The first red flag for the FDA regarding HV is the Connection Center (CC). Here data is acquired from medical devices, and if that data is to be used in rendering a diagnosis or guiding therapy (clearly the case with hypertension, diabetes and other chronic diseases) then CC meets the legal definition of a medical device. Presently, the FDA does not actively regulate products like CC, although there are examples of standalone connectivity products and features similar to CC that are built into broader based products that have received the FDA's premarket approvals. The regulatory risk for Microsoft is that the FDA could change its position and recall the product until it receives premarket approval. This change could result from political pressure (Congress or advocacy groups), adverse publicity from reports of patient injuries or deaths, or if Microsoft markets HV (or HV CC) in a way that gets the FDA's attention.

Regardless of the FDA's potential interest, the real issue is provider confidence. If Microsoft cannot demonstrate its ability to ensure the safe and effective use of data on the HV platform, then HV will never see much adoption. Such uncertainties could also dissuade vendors from incorporating HV if they feel that providers won't adopt.

There are many important contributions that HV can make to health care, and Microsoft is off to a good start. As a beta product there are still a few gaps to fill.

See previous Microsoft HealthVault posts here and here. Pictured right is the futuristic HealthVault logo.

FDA Raises Bar on Medical Device Software Testing

Tim Gee — Thu, 25 Oct 2007 01:09:23 +0000

Blog Medical Devices Today did a post last week on the FDA’s adoption of a relatively new software testing technology in the CDRH’s software forensics lab.

In the past year or so, the forensics lab, housed within the Office of Science and Engineering Laboratories, has used high-power instruments and techniques to analyze “source code” in roughly a half dozen medical devices whose software was thought to be responsible for causing serious adverse events.

The analysis, which employ tools routinely used in the automotive and aeronautical industries, exposed several software design errors linked to the adverse events and at least one latent error that had the potential to cause an injury, according to Al Taylor, the Director of OSEL’s Division of Electrical and Software Engineering.

The story hints strongly about the FDA’s keen interest in seeing medical device vendors adopt this technology as part of their verification test in product development. Why is this a big deal? In 1996 10% of medical devices recalls were caused by software-related issues. In June of 2006, software errors in medical devices made up 21% of recalls.

The problem with testing software is that even very basic applications can have so many variables and permutations of outcomes that they become virtually impossible to test with conventional means. This is one of the main reasons that the FDA has focused their regulations on ensuring that vendors follow accepted design processes that maximize resulting quality, rather than focusing on verification and validation testing. The Quality System regulation is the manifestation of this approach.

But about a decade ago, another potential approach emerged. In 1996, a European space rocket, the Ariane 5, exploded just after launch because of a computer bug. Scientists made quick use of a sophisticated programming tool called “static analysis” to figure out what went wrong.

That experience validated the strategy as a useful tool for automating the search for hard-to-find coding vulnerabilities in complex software. It has since been embraced by the aeronautical and automotive sectors to help minimize errors and accidents. Now FDA is trying to bring medical device manufacturers into the fold.

A number of recent recalls (St Jude Medical Merlin PCS/Identity pacemakers, Baxter Colleague infusion pump, Difibtech’s AED) were all software related. Right now the CDRH software forensics lab is used to test vendor’s proposed fixes for recalled devices. In addition to verifying the vendor’s fix the static analysis also uncovers previously undiscovered software bugs.

According to the Deputy Director of the Division of Electrical and Software Engineering, Brian Fitzgerald, “No manufacturer wants to be in a position where FDA [is] finding bugs in his code,” he said. “And so we treat these very, very privately.” Indeed.

The story goes on to emphasize the value static analysis would have on premarket analysis. The story suggests that if medical device vendors don’t get with the program and adopt static analysis and/or other more rigorous software testing methodologies, the FDA might have to start doing premarket static analysis themselves - would very probably adversely affect premarket approval time frames.

This past summer I attended the workshop, Improving Patient Safety Through Medical Device Interoperability and High Confidence Software, in Boston. Much of this conference dealt with the challenges and solutions available to better test medical device software. Static analysis was discussed in a number of sessions. The bottom line from the conference is that the medical device industry has not kept up with other high reliability industries, especially aviation. (You can read posts from the conference here, here, here, here and here.)

I fully expect static analysis and other similar techniques to play an increasing role in medical device product development - mainly because it seems the FDA has similar expectations. Certainly the big vendors will adopt these techniques to:

Differentiate their products (claims of improved safety),
Avoid the considerable costs of preventable product recalls, and
Better influence time-to-market schedules by removing the need for the FDA to do their own static analysis prior to premarket approval.

These advanced testing methods will also be promoted and offered by contract engineering firms. Firms like HighRely, that work in both aerospace and medical devices, can offer static analysis and other high confidence software testing methods. This will enable smaller medical device firms to benefit from these testing methods without investing in the overhead to do it in house.

Pictured right is a graphic report from a static analysis of software from the Centre for Software Engineering in Dublin, Ireland.

Sensor Productization Challenges and Potential Solutions

Tim Gee — Thu, 27 Sep 2007 03:10:06 +0000

Simon Aliwell, Director of the Sensors and Instrumentation Knowledge Transfer Network, National Physical Laboratory, in the UK, has a piece in the latest issue of MDT magazine. His outfit is a network of excellence supported by the UK Technology Strategy Board to develop innovation in sensing. Check out their web site here.

In his story Aliwell suggests that regulatory hurdles represent the greatest market barrier for developers of new sensor technology.

Technologies for use in the medical arena must undergo a thorough and
well defined testing and approval process before they can be adopted.
This is the case even when technologies have proven their effectiveness
in other fields and applications. Although this is to patients'
benefit, it does delay the return on investment for companies and makes
the path to commercial success longer. This, in combination with the
significant upfront investment required to develop, manufacture and
trial new devices, may mean failure for many small companies as they
wait months or even years for returns.

Certainly starting a new medical device company represents a major investment. And certain sensor technologies, like the Oncoprobe chemotherapy sensor that Aliwell mentions must be tested for each clinical application (i.e., or type of cancer in the case of Oncoprobe) - a heavy regulatory burden. A bigger burden I think is creating the “whole product solution” for senors.

In a perfect world, the value of a novel sensor technology is recognized and eagerly licensed and incorporated into medical device vendor's products. In the imperfect world of health care, almost all sensor vendors must create and sell their own product to create the market demand that drives existing vendors to incorporate new sensor technology. There are few Fields of Dreams (build it and they will come…) in health care.

This line between OEM supplier and medical device vendor is a thin one, and must be approached carefully. One one side, your sensor-based product must be compelling enough to win end-user sales and fuel market demand. On the other you need a rapid time to market at a cost you can underwrite. So what might a “whole product solution” include?

In addition to productizing your novel sensor technology, a company has to package it so it can be used in its intended clinical setting. The relative maturity of other medical devices at the point of care - patient monitors, infusion pumps - create expectations among clinicians for certain capabilities. These expectations include:

Some degree of wireless operation - an increasing number of devices are battery powered and wireless connectivity is de riguer for portable medical devices, battery powered or otherwise.
EMR integration - any hospital with paperless charting will insist on the ability to electronically move sensor data into the patient's electronic record.
Monitoring - sensors provide a monitoring function - alone, in conjunction with other sensors, or as feedback to therapy. Monitoring requires surveillance (data display), alarms, and retrospective event review.
Point of care workflow - all these capabilities must be implemented in a system design that supports the care delivery process - where caregivers circulate between the bedside, central station and elsewhere. The system must enhance caregiver productivity and patient safety, rather than the opposite.

These expectations define the system that supports the practical use of your sensor in a real world customer environment. Along with these system features, there is a whole range of business requirements to properly sell, manufacture, install, service and support the whole product solution.

Conventional product development strategies for these system features entail developing most all of the features from scratch, a very time consuming and expensive approach. While we are still a ways from being able to license these features from a medical systems OEM vendor, there are innovative new development strategies that can greatly minimize time to market and R&D costs.

Rome wasn't built in a day, and a new medical device system will not be full featured at first release. In fact, you'll need some system capabilities to support sensor development, like data acquisition and analysis. Part in parcel with your development strategy is the product roadmap. The roadmap lays out the progression of system features over time, and must align with your sensor product development plan and your market entry strategy.

Most novel sensor technology requires that clinicians adopt a new use model different from that used with conventional sensors. Getting anyone in health care to change the way they do things is a challenge, and this has an impact on market entry strategies. Because market entry strategies drives both system requirements and product roadmap, the whole process is rather iterative, with each variable impacting the others until a balance is achieved.

So there you have it, an overview of productization issues for novel sensor in health care.

Pictured right is some Nexense sensor silicon.

Premier Claims Safety Improvements with Medical Device Unique IDs

Tim Gee — Wed, 26 Sep 2007 00:56:02 +0000

Premier Safety Institute sent out the September issue of their (usually) excellent Safety Share newsletter today. Here was the lead item (emphasis in original):

A major move to improve the safety of medical devices - On September 21, Congress approved a law requiring the Food and Drug Administration (FDA) to put into place a unique medical device identification system.

Pshaw! The newsletter went on to report that Premier surveyed 1,000 hospitals in an effort to claim a safety benefit from implementing such a system. Let’s look at this survey (you can download your very own copy here.)

(Identification industry proponents refer to these unique identifiers for medical devices using the acronym “UID.”)

The first red flag is Table 1, listing the job types of survey respondents. It seems that biomedical or clinical engineers didn’t respond to the survey. As the one department in hospitals responsible for patient safety and medical devices, this group should be identified. Instead we’re left to guess if “clinical support” or “Facility/environment” somehow includes biomeds.

Table 2 includes the survey questions. Of note here is question 2, “Do you have a system or database, beyond the individual patient record, to track or record medical devices that are implanted in a patient?” Only 46% of respondents said yes. Question 3 asks how patient care equipment (i.e., medical devices like infusion pumps or patient monitors) is labeled: 65% handwritten or text, 28% bar code, and 2% RFID.

The fact that most hospitals don’t log implanted devices, beyond the patient chart, is embarrassing. How do these hospitals get accredited? Because biomeds tend to be so obsessive about documenting patient care devices, question 3 is worded differently. The end result is the same, regardless how the device is identified, biomeds do a good job of documenting and tracking devices - recalled or otherwise.

Question 4 asks how recalled devices are located: 42% manually review patient records (implants?), 58% and 40% review manual and electronic logs respectively (patient care devices?).

To this point, we have interesting data on sloppy recording of implanted devices. There is no data that shows problems with identifying or locating patient care devices. Nor is there anything in the survey that indicates that a UID would improve patient safety - implanted devices that are not logged are a problem whether they have the current “unique identifier” known as a serial number, or a UID.

Question 6 shifts gears asking, “to what degree do you believe that having a unique device identifier system would enhance patient safety by improving your current process for recording device information and tracking recalls?” This question conflates the numbering scheme with an improved process when in fact they are separate issues.

According to what Premier has to offer, the safety claim of a UID is bogus. Patient safety improvements are all dependent on improved hospital operations, and not on the numbering scheme used to identify medical devices.

Perhaps some supply chain expert can tell us why a UID would perhaps lower health care costs. While less compelling and sexy than improving patient safety, lowering costs is at least believable.

Pictured right is a typical asset tag. Tags like this, combined with medical devices’ current unique identifiers, can support all the patient safety improvements attributed to UID.

Devices for Diabetics Improve

Tim Gee — Mon, 24 Sep 2007 23:33:54 +0000

Business Week has an interesting story about recent advances in glucose meters and insulin delivery systems for diabetics. Many of the devices in the story aim to improve usability in various ways to improve patient compliance and outcomes. Proper control of blood glucose levels has a tremendous impact on a diabetic's health, quality of life and susceptibility to complications.

The market for glucose management has not escaped medical device vendors or entrepreneurs:

The audience for diabetes-management tools is large–and growing. The Centers for Disease Control & Prevention estimates that there are 20.8 million American diabetics, about 7% of
the U.S. population. According to the International Diabetes
Federation's latest statistics, nearly 194 million adults around the
world are diabetic; by 2025, according to estimates, this figure will
reach 333 million. Palo Alto (Calif.) research and consulting firm Frost & Sullivan estimates that the U.S. market for traditional diabetes monitoring
(blood testing equipment and strips that diabetics use to measure their
glucose levels) tallied $3.53 billion last year, up 12% from 2005.

“In the last several years, we've seen low double-digit growth,”
says Mona Patel, director of Frost & Sullivan's medical research
department. “Yes, there will be a saturation factor, but the number of
diabetics keeps increasing–even among children.” So, Patel says, the
market for pediatric devices will grow, too.

The market is slowly growing, but the real opportunity is the poor design of conventional products made for diabetics. They are hard to use, make funny noises, inconvenient, have a medical device look that makes patients look and feel “sick”, have poor battery life, and can be big and clunky.

Blogger Amy Tendrich posted an open letter to Steve Jobs on her blog Diabetes Mine, challenging Apple to bring the same design excellence they bring to consumer electronics to devices for diabetics. The Business Week story describes a design created in response to Tendrich's plea, and touches on a number of other products. (Surprisingly, no mention of DexCom's continuous glucose monitoring system.)

The (glacial) transformation taking place in diabetic devices highlights a structural problem in the medical device industry. Due to barriers to market entry, established vendors feel little pressure to create the equivalent of an iPod for diabetics. Some vendors like Medtronic have created innovative systems like the MiniMed insulin pump with real time glucose monitoring. But in order not to cannibalize sales from their conventional products line, they price the new solution at a significant premium. (Medtronic has taken a similar approach to their relatively new wireless ICDs, charging a $6,000 premium for the wireless models over products that still use induction wands that must be placed over the pacemaker. I know cardiologists that refuse to implant the wireless models because they feel it is unfair to burden the patient/payor for such a high premium.)

Payors only reimburse for technology that has a clear return on investment. They won't reimburse for a fancy (read “expensive”) MiniMed pump for a patient whose condition does not require continuous monitoring and administration of insulin. Sure payors will pay more for a product with better outcomes (i.e., lower costs to the payor resulting from a healthier patient). But proving those improved outcomes - and lower costs of care - is an expensive and time consuming proposition.

It appears that Medtronic - and vendors who pursue a similar strategy - are stuck with a small subsection of the diabetic market, unless they're willing to reduce the price of the MiniMed where patients are willing to pay the difference over what their payor will reimburse for a conventional glucose management system.

The poor comparison between conventional glucose management products and consumer electronics has not been lost on medical device entrepreneurs. Vendors like Medicom, DexCom, Health Pia, and Insulet (pictured right) are bringing better designs and technology to market. These new players will need more of a consumer electronics product strategy, rather than Medtronic's strategy for the MiniMed, if they are to succeed.

More here in a iHealthBeat story about a recent FDA continuous glucose monitoring approval for children that highlights cost and potential savings in reduced health care costs.

Some short-term studies have found that users can improve the control
of their blood sugar through the devices, although other studies have
found minimal impact. Irl Hirsch of the University of Washington said
the discrepancy can be attributed to a lack of effort from diabetics,
not the sensor technology.

The glucose sensors can cost up to
$1,000, with at least $350 in monthly fees for supplies. Although some
insurers pay for them, many refuse to reimburse patients for the
devices until there is more proof that they improve health, the AP/Star reports.

UPDATE: Reader Bernard Farrell has an excellent point in the comments:

Your story illustrates one of the big issues with insurance companies at
present. They don't adequately cover treatments for chronic diseases, and then
later they pay for the outcomes of poor management. There is an argument that
better designed devices will lead to better medical outcomes AND lower support
costs for the device makers. As far as I'm concerned good device design is a
win-win-win situation for patients, device makers, AND insurance companies.
Unfortunately it feels mostly like I'm shouting into the wind about this.

There are two problems I think. The first is demonstrating the hard dollar savings from well designed devices. This naturally falls on the device vendor, and is neither a quick or inexpensive task. The other problem is the tendency of device vendors to want to get a significant premium for their better designed product. A major price increase requires justification before payors will reimburse for a new “class” of device. If a vendor introduced a better designed device (with some additional features) at a slight premium, patients might be willing to pay the difference themselves - think the iPod.

Perhaps what's needed is more of a consumer electronics mindset applied to these kinds of products, rather than the conventional medical device paradigm.

Patent Awarded for Wireless, Batteryless, Implantable Sensors

Tim Gee — Sat, 07 Jul 2007 17:52:12 +0000

MEMS vendor Integrated Sensing Systems, Inc. (ISSYS) announced, “that the U.S Patent Office has granted a patent entitled “Wireless
MEMS Capacitive Sensor for Physiologic Parameter Measurement” (US Patent No. 6,926,670) which covers the design, manufacturing, and anchoring of miniature, wireless, batteryless, implantable sensors.” (press release - pdf) The summary from the patent:

The invention comprises a telemetric sensing system for
noninvasively monitoring pressure and/or pressure gradients in a
cardiac conduit. The system includes one or more implantable sensor
unit(s) and a companion reader unit. The sensor unit, which is
preferably batteryless and wireless is chronically located within the
conduit, or around in a close proximity. For valveless conduits, a
sensor unit is placed at either end of the conduit, or around it. For
valved conduits, one or more sensor units are located both proximal and
distal to the valve, allowing the pressure gradient across the valve to
be monitored. One sensor unit can indicate occlusion; however, two
sensor units will allow the occlusion to be located (e.g.
proximal/middle/distal along the conduit). As well, with two sensor
units, flow rates may be deduced or estimated. Furthermore, trend
analysis of the pressures and/or flow rate within the conduit can allow
a time-to-failure estimate.

New Scientist has a nice description of the clinical application:

The implant, the size of a grain of rice, is one of a new breed of
medical devices that requires no batteries. A radio transmitter and
receiver held near the body provides the power and interrogates the
implant.

The
device is designed for people with congestive heart failure, where
fluid builds up in organs and limbs because the heart fails to pump
enough blood around the body. There are now more than half a million
new cases each year in the US alone.

The
condition is usually treated with drugs, and to ensure they are working
doctors sometimes have to measure the pressure inside the left atrium
of the heart.

At
the moment, this can only be done by temporarily inserting a catheter
into the heart, via an artery in the arm or leg. In some patients this
unpleasant and costly operation has to be done three times a year.

But
with the new implant a similar operation would only have to be done
once, to place the sensor inside the left atrium, says Nader Najafi,
head of Integrated Sensing Systems (ISSYS) in Ypsilanti, Michigan, the
company developing the implant.

Next thing you know, they'll be generating continuous waveforms from implants like this. Pictured right is the implantable wireless pressure sensor.

AAMI 2007 - Day Two, Afternoon

Tim Gee — Sun, 17 Jun 2007 19:51:35 +0000

The IHE PCD crew presented Meeting the Challenges of Integrating the Healthcare Enterprise. Didi Davis from HIMSS, kicked things off describing the IHE organization, what the IHE does, and how they do it. The IHE takes established standards and through collaboration with interested providers and vendors results in a series of “integration profiles” that specify how to configure multi vendor interoperable systems. Each integration area of focus, or domain, has a framework of standards designated to support the workflows and resulting integration profiles for a specific domain. Examples of domains include cardiology, eye care, IT infrastructure, patient care devices (PCDs), radiology, and more.

The process starts with use cases that describe workflows. These worflows are subsequently implemented across multi vendor systems using the standards framework for that specific domain. The resulting integration profiles are tested at an annual “conectathon” every January in Chicago, and demonstrated at Inteoperability Showcases held at RSNA and HIMSS, and then published for use by vendors, systems integrators and providers.

Another key message was the need for providers (buyers) to include requirements for interoperability and standards in the products that they buy.

Next up was Steve Grimes, VP of Enterprise Resource Planning at Technology in Medicine, talking about the convergence of medical devices and IT. He described the trends driving medical device integration with IT. Steve also outlined many of the benefits of this integration:

Access to, comparison and analysis of rich set of clinical data from variety of sources that can be used to provide preemptive care
Automatic charting of data to the electronic medical record (EMR)
Closed loop systems … i.e., outputs from diagnostic devices (e.g., heart rate monitors & pulse oximeters) affect inputs on therapeutic devices (e.g., infusion pumps)
Patient alarm management
Asset tracking (i.e., RFID)
Remote device management
- Monitoring data flow integrity & continuity
- Error code monitoring & remote diagnostics
- Software upgrades

After a review of specific devices being integrated, the resulting integrated medical systems were described. As the systems become more sophisticated, in their effort to improve patient safety and productivity, these systems can become more complex and expensive. As we get more dependent on these types of systems, when they fail it has a significant impact on patient care. This evolution has brought together IT and Biomedical engineering, frequently resulting in a clash of cultures.

Providers must assume a systems engineering role when adopting “home grown” system or multi vendor solutions. While single vendor solutions may be preferred, an increasing number of these systems cross product categories for which there is no single vendor solution. Historically, these systems have been adopted under the radar as a isolated systems. The complexity of these systems, and their impact on patient care, necessitate an strategic enterprise approach to ensure security, safety (like eliminating single points of failure), and manage infrastructure and costs.

The convergence of IT and medical devices are inevitable, and requires coordination between IT and biomedical departments. Clinical engineers can contribute to bridging these two very different departments, and provide a strategic systems vision that spans traditional IT and biomed domains.

Chis Riha, exec director of clinical systems engineering at Carilion Clinic Health Systems. He described the IT realm, with a review of different health care information systems.

Ray Zambuto, President Technology in Medicine, spoke in the IHE Patient Care Device (PCD) Domain. He ran down the history, starting with an IHE provider survey that indicated medical device integration was the second most popular area (50%) for future IHE efforts. Here’s the PCD’s charter:

The Patient Care Devices Domain is concerned with Use Cases in which at least one actor is a regulated patient care device. The PCD coordinates with other IHE clinical specialty based domains such as medical imaging.

Ray then laid out the workflows the PCD has tacked over the first three years. Another survey was done in 2006, asking for device priorities. The top 5 devices were vital signs reporting devices (EMR integration - 72%), continuous patient monitors (67%), ventilators (49%), anesthesia systems (44%), and infusion pumps (43%). Vendor priorities lagged considerably behind user’s interests - the biggest lag with vendors was vents at 21%. Ray described the profiles proposed for 2007:

Patient identification - estab patient context and binding ID to data stream
Device - enterprise query
Point of Care (PoC) real time plug and play integration
Home telehealth (remote monitoring)

Throughout Ray emphasized the need for providers to participate in the IHE PCD efforts. As someone who’s participated in the past, I can say that vendors are considerably over represented, and provider requirements, perspective, and priorities are sorely needed. “Decisions are made by those who show up!”

Questions: how does the groups work take place? There are two basic groups, the planning committee and a technical committee. Occasional face to face meetings (3 or 4 for each committee) are held for major planning and review efforts, with the rest of the work done via bi-weekly teleconferences and email. You can read technical work done to date by the PCD here. When a vendor says they’re involved in IHE, be sure to ask them for their conformance statement - these are not a certification, but documents their successful participation in a connectathon.

One byproduct of the IHE effort is increased transparency regarding what connectivity and interoperability a vendor’s products have - in a concise and detailed document. On the flip side, participating vendors are increasingly using their IHE participation as bragging rights and competitive advantage over vendors who do not participate.