The use of the product in question was given as:

• a networked solution system used to monitor a patient’s vital signs and therapy, control alarms, review Web-based diagnostic images, and access patient records. The number of monitored vital signs can be increased or decreased based on the patient’s needs

Curiously only one customer was identified as having received the product, or at least this particular version of the product. While the manufacturer and product in question is a matter of public record, and available at the link, I chose not to include it here because my objective is not to repeat the recall information, but to suggest the reasons for the recall, an associated labeling issue, and offer some general lessons.

The reason given for the recall had two seemingly separate parts. The first is that “The weight-based drug dosage calculation may indicate incorrect recommended values, including a drug dosage up to ten times the indicated dosage”. This sounds like a software problem yet the fix was not to “upgrade” the software but to suggest a workaround. (I love the term upgrade to when applied to fixing something that doesn’t actually work!)  According to the FDA the firm’s letter stated that “users should enter the patient’s weight by way of the admin/demographics screen to ensure the drug dosage is calculated as intended.” (I did not find the firm’s letter on its website, but it might be one of those hidden page situations since I did find, with a struggle, two other recalls, though using the search term “recall” produced no results). Again speculating, the workaround sounds like a user dependent way to do something that was supposed to happen automatically. At least part of the value of automation is largely diminished, and opportunities for use error increased, when such additional demands are placed on the user.

The second reason given for the recall was that there may be a 5-10 second delay between the electrocardiogram and blood pressure curves (waveforms) at the central station.   This is an interesting technical issue that may be related to software and/or communication protocols. In either case it illustrates that multiple data streams may only be useful if they are properly timed stamped, and then properly aligned at the receiver. Out-of-sync data when subsequently processed either by eye, or automatically, can give erroneous and misleading results that might appear to be correct, i.e. the results could be in the category of erroneous but believable.

For one or both reasons the FDA found that, “This product may cause serious adverse health consequences, including death.” Yet it should be noted that this was a voluntary recall, as most recalls are, despite the fact that people who surely know better reported this as “FDA recalls…”

The FDA announcement goes on to say that the company pointed out that the instructions for use state that: ”For primary monitoring and diagnosis of bedside patients, use the bedside monitor. Use the…Central Station only for remote assessment of a patient’s status.” This sentence seems to be illustrative of the fundamental problem of remote information receivers and integrators that carry a disclaimer that in sum says that you shouldn’t rely on them. But isn’t the ability to rely on it exactly why you bought it? Moreover, promotional materials available on the web do not appear to echo this disclaimer. For example it is stated that ”Applications…enhance patient care management by providing rapid assessment, decision support and clinical reporting.” Does that sound like it isn’t for primary diagnosis? Or does “Data accessible from the…Central Station includes real-time waveforms” sound like those waveforms shouldn’t be used for primary monitoring? For one more example it is said that “arrhythmia events are detected with an unprecedented degree of accuracy.” Accuracy is certainly a good thing, but detecting arrhythmias at the central station when only the beside monitor is to be used for “primary monitoring and diagnosis” appears to be less than highly useful.

Furthermore the statement that the central station is only for remote assessment seems both definitional and contradictory. It is obviously for remote assessment–because it is a central station and thus remote! But then what does “assessment of the patient’s status” mean if not monitoring and diagnosis?

The disclaimer game has been addressed in these pages before. Here it seems to involve a product that is being marketed, sold and bought for exactly the reasons that the manufacturer is saying it shouldn’t be used. I didn’t spot the disclaimer language in any of the promotional materials, but maybe it is there somewhere.

So, we have here an apparent example of software driven miscalculations, network transported data that is not time synchornized, and a reminder not to use the central station for primary assessment. Important examples to remember as we charge ahead with software driven networked solutions.

[The products in the photo with this post above are not associated with the recall discussed, and are for illustrative purposes only.]

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

I’m looking for some feedback. Why would any healthcare organization choose to go with Capsule if they have 90% Philips bedside solutions? Why would they not consider Philips as the nutural choice for device integration? I want to know and your feedback will be greatly appreciated.

As usual, there were numerous insightful responses discussing how the two approaches – connectivity enabled by medical device makers and that provided by vendor agnostic manufacturers – differed. What struck me was that there was no discussion about the workflow that the connectivity was supposed to provide. Since patient monitoring is mentioned, is the desired workflow remote surveillance or alarm notification? Perhaps the need is for clinical documentation from patient monitors to the patient’s chart in an EMR? Another common application is data aggregation in high acuity areas like the OR or ICU. While each of these workflow applications is enabled by an MDDS, they are often provided by different sets of vendors.

Connectivity is workflow automation through the integration of medical devices and information systems. A basic question is exactly what workflow you’re looking to automate with your proposed connectivity? Unfortunately, no one connectivity solution does all workflows equally well.

Workflows like remote surveillance and event review most often come from the medical device manufacturer (exceptions include Cardioupulmonary and LiveData). Alarm notification beyond remote speakers, ceiling lights and message panels are most often available from third parties (Welch Allyn is an exception here). Clinical documentation, or EMR charting of medical device data comes mostly from third parties and medical device manufacturers who have their own gateway products (like GE and Philips patient monitoring gateways).

The discussion comments about the trade offs between medical device maker’s and third party solutions are all valid. Device makers like proprietary end to end solutions because it raises customer’s switching costs and helps lock in their installed base. Because they make the medical device and the connectivity solution, theoretically they can create a better – more feature rich, easier to use – solution than a third party. An example of where this theoretical potential is realized is Welch Allyn’s alarm notification product.

Likewise, third party connectivity solutions are also proprietary. The big difference here is that the third party solutions are device manufacturer agnostic, so you can change your patient monitoring vendor – or add manufacturers who make different kinds of devices other than patient monitors – without having to swap your connectivity solution too. However, should you want a connectivity workflow that’s not available from your third party connectivity solution provider, you must add another vendor who can deliver on the new workflow or go without.

Unfortunately, the market has not evolved to the point where any third party connectivity solution can provide all the different connectivity workflow solutions. Currently, providers who have implemented various connectivity workflows also have multiple third party (and often medical device maker) connectivity solutions. The connectivity market can be segmented between EMR documentation, alarm notification, and remote surveillance/data aggregation applications. While there are third party vendors whose products theoretically could support all three segments of connectivity workflow, I’m not aware of any that do.

Before we launch into the pro’s and con’s, let’s identify the basic functional requirements for connectivity:

1. You must have the ability to get machine readable data out of your medical device. Most all electronic devices have this ability, provided by a serial port. Alternatively, the device can use an Ethernet and/or Wi-Fi (or perhaps some other wireless technology).
2. Next the proprietary data format from the medical device must be parsed and converted into something the target system understands, typically HL7.
3. At some point the medical device data must be associated with patient from whence it came. There are many ways to do this, but the key is to make it as automated and reliable as possible.
4. There must be a target system to communicate with. The common standard used for this communications is HL7. The target system can be a hospital’s HL7 interface engine, or the HL7 interface module of an application like an EMR.
5. The ability to communicate between the medical device (or connectivity server) and target system is necessary when you need to resend data that may be garbled or capture (and in a perfect world respond to) error messages from the target system – like, “don’t send me any more data, I’m busy right now.”

The two design options we’re considering are building the function requirements above into the embedded systems device (a.k.a. the medical device) or to push all but the first function off to a server that provides requirements 2-5 for multiple embedded systems.

One more caveat before we start. We’re not entertaining a connectivity solution based on USB drives, which is often referred to as “sneaker-net.” Connectivity is supposed to entail workflow automation, and forcing users to manually download data from one device, transport it to the target device and then upload the data – not to mention housekeeping like purging data that accumulates on the USB drives – does not provide a very compelling value proposition. In fact, such a solution would likely require as much or more time from users as manually writing down data read off the medical device, and then typing it into the EMR (or some other system). I’m not saying there are no use cases where USB drives don’t offer a meaningful connectivity solution, but they are very few and far between.

Pro Embedded

• Eliminates a component (the server) from the system – less to develop, manufacturer, install, service and support (yeah!)
• The COGS (cost of goods sold) of the overall embedded system, plus connectivity, will likely be lower due to the elimination of a server

Con Embedded

• Industry best practice for health care IT systems integration is to run application code on general purpose computers. This presents additional challenges when doing an implementation on an embedded system, adding additional scope and complexity to project (e.g., in crease in UI on embedded device to support configuration, troubleshooting and use of the connectivity by end users).
• The embedded approach conflicts with market requirement for a single server supporting multiple devices for connectivity because customers want 1 HL7 gateway to manage rather than one for every connected device.
• Developing and maintaining embedded system code is more expensive and time consuming compared to application code on general purpose computers. Given that connectivity code, and especially HL7 interface configurations, will change over time, sustaining engineering efforts will be most costly and time consuming.
• Implementing connectivity in a distributed fashion eliminates a central management and configuration facility, potentially adding to design complexity and development cost, e.g., due to things like log files, dbms, patient context, and HL7 interface configuration.
• Increases sustaining engineering costs as any change to HL7 interfaces requires changing embedded system software (this is not a simple configuration change that can be done by the customer).
• Distributed embedded solution increases installation and support costs (and cost of ownership) as access to, and modification of individual embedded systems is much more difficult and time consuming than supporting application code and scripts on a single server – trouble shooting can be more complex when compared to finding a problem on a single server.
• Due to scope and complexity, the distributed embedded approach will likely go to market missing major features (e.g., forcing users to take manual steps like entering patient ID rather than automating that process), necessitating a follow on project of similar cost and effort.
• Any effort spent creating tools to reduce the costs and complexity of managing connectivity on distributed individual embedded system devices adds to overall development costs.
• Getting Biomed to agree to purchase support for the embedded device (due to the embedded connectivity) will be difficult at best, and often results in a refusal to buy, which will cause the customer to incur time and expense charges for connectivity support (esp. reconfiguring HL7 interfaces) creating the perception that the cost of ownership of the device is unreasonably high.

Pro Server

• The market requirement is for a centralized, server based connectivity solution that is easy to use (has efficient and complete workflow automation), avoids a potential competitive weakness, and is easier to sell as it is what IT buyers are looking for.
• It is much easier to use open source software on a server to lower development costs, time to market and COGS, compared to implementing on an embedded system.
• Reducing scope of the embedded system device reduces embedded development costs and time to market for the embedded device.
• Reducing scope of the embedded system device may result in a reduction in COGS.
• By investing the time otherwise spent integrating connectivity into the embedded system, it is possible to deploy a more feature rich and competitive server-based connectivity solution.
• It is possible to sell support contracts to virtually all customers to cover support costs and minimize perceived cost of ownership (not to mention hassling over service charges every time someone needs to touch a device with embedded connectivity).

Con Server

• Adding a server to the project may be perceived as “scope creep” by management.
• Many embedded system R&D shops lack a core competency in developing application software for general purpose computing platforms. This can be an important issue, but one that is pretty easy to overcome through new hires and/or outsourcing.
• A server may be perceived as adding cost and complexity to the solution (although the opposite is true).
• Management may not want to get into “the software business” – however, any medical device vendor adding connectivity is, by definition, in the software business.
• Most standalone embedded system product development projects are complete before product launch, except for minor sustaining engineering projects for things like parts obsolescence or fixing latent defects; server software development is more of a sustained R&D spend, keeping up with emerging market requirements and changing technology (development tools, operating systems, and hardware).

The pro’s and con’s of a server deployment are pretty balanced. Including a server in your design does take real effort. But the deciding factor between going embedded or with a server in most cases is a desire to avoid the disadvantages of implementing connectivity on the embedded system.

The current industry best practice for connectivity solutions is to aggregate the data from multiple devices on a server. Depending on the data volume and other factors, the server may serve an entire enterprise (multiple hospitals), individual hospitals, or individual care delivery or diagnostic areas. The data aggregation function of the server is important for several reasons.

Manufacturers in this situation (needing an interface to EMRs for clinical documentation) often come to me with a plethora of questions. Before we get started, let’s frame the discussion. In this post you will be introduced to a framework for clinical documentation connectivity. I do not get into details on product design or features. Rather we look at a basic framework and external factors that come to bare on any manufacturer contemplating a connectivity feature for their products. What follows is a sketched in foundation or starting point for manufacturers to use to plan for and implement what is probably the most basic connectivity application.

Let’s run through the basics.

What are the basic components of a clinical documentation solution for a medical device?

Here are the most basic components:

1. Your medical device must have the ability to export data in a digital form. This is relatively easy, as most medical devices are digital and have a serial port. An alternative (and industry best practice) is a network connection right in the medical device.
2. A centralized computer or server that aggregates data from your medical devices. This server may do other things like convert units of measurement, relabel data, store the data in a temporary database, or provide users the means to review and edited acquired data (referred to as “validation”) before it is pushed into the EMR.
3. An HL7 interface that takes your device data, in your proprietary protocol, converts it to HL7 and sends it on to the EMR.

Geez, just three components? Can’t I just outsource this whole EMR integration thing to a third party? Maybe. One can certainly partner with one of several MDDS vendors (like Nuvon or iSirona) who will acquire data from your existing serial port, and then push it to an EMR via an HL7 interface. This approach might well take this whole connectivity thing off your lap, but there are drawbacks:

• The principal business of MDDS vendors is to provide connectivity for multiple types and manufacturers of medical devices, especially legacy devices that don’t have built in network connectivity. These MDDSs are purchased on a departmental or enterprise wide basis. What if you partner with another MDDS vendor, such as Capsule, and the prospect has deployed Cerner’s CareAware house wide? The hospital will not be keen to installing any MDDS other than the one they, you know, already bought. Bottom line: prospects who have bought (or are planning to buy) a competing MDDS and not the one you chose are unlikely to buy your solution.
• Remember that medical device connectivity is not about the connection – it’s all about workflow automation through the integration of medical devices and information systems. Another drawback of MDDSs is that you are dependent on them for the quality and extent of their workflow automation. Now some of these MDDS are pretty good at workflow, but they are not all equally good at all workflows for all device types. Nor are they as good as a well designed connectivity solution that’s fully integrated with the medical device. Bottom line: compared to built in connectivity, a MDDS is a compromise. You are likely to face a competitor with a demonstrably better connectivity solution.
• By handing the connectivity portion of your solution to a third party, they now control a portion of the pricing of your sale. They may or may not be interested in discounting to win a sale that’s important to you. And the incremental cost of your connectivity solution is also controlled by your partner. Bottom line: a hight priced solution.

Wait, wait, wait! HL7 is a standard, so isn’t it just “plug and play”? Unfortunately, the HL7 standard and how interfaces are effected is far from ideal. HL7 is not a plug and play interface because:

• The HL7 standard was built (mostly by vendors) to include many options and exceptions. Consequently, there are many ways to configure one side of an interface that are all legitimate and consistent with the standard.
• Many HIT applications installed in hospitals have been modified by the IT department. It’s not unusual for a mid sized hospital to have 100-200 software developers in the IT department writing code and modifying software purchased from vendors. Consequently, an interface that works with one hospitals EPIC EMR may not work for another customer also running EPIC because of customer modification.
• Like any other software business, EMR vendors regularly come out with new versions or releases. There is no general tendency among hospitals to keep up with vendors and stay on the current release of software. Consequently, when two or more customers have the same EMR vendor and product, they are seldom running the same release. This means that the HL7 interfaces in each hospital may have to be configured differently because the hospitals are running difference versions of the same application.

Please tell me there’s an established industry method for dealing with the medical device connectivity for clinical documentation! Sure, but it’s not pretty. EMR vendors in acute and long term care markets have a common way of dealing with HL7 interfaces. (The ambulatory market does too, but it is quite different and outside the scope of this post.)

• All HL7 interfaces are table driven with associated specification documents describing how they can be configured.
• EMR vendors only want to engage with another vendor to do an interface after there is a sale to a common customer (it’s hard to find an EMR vendor who will work with you on a product development project, although it is possible).
• Providers prefer to have an aggregator for medical device data and a single HL7 interface for clinical documentation, rather than individual medical devices talking to the EMR.
• Once a customer sale is made that includes clinical documentation, the medical device and EMR vendors exchange HL7 interface specification documents, technicians from each company review the other’s specification document and discuss how each side of the interface can be configured to effect a working interface. Each technician configures a test fixture in their lab and tests the interface over the Internet. Once a working configuration is proven out (through verification testing), each technician sends their configuration file to their own field technician (or the customer) for installation at the customer site. A second test on site validates the interface and the customer goes live.
• THIS PROCESS IS REPEATED WITH EVERY SALE.
• Any subsequent failure of the interface – a more common occurrence that you might hope – causes a repeat of the above process.

I get the message that I probably can’t push this off to anyone else. So what do I need to develop, deliver, install and support these clinical documentation interfaces?

Let’s start with product development.

Imagine you have to gather requirements and design a product that is unlike anything your company has ever designed before. Connectivity is like that, except because it uses your medical device as a starting point, and it’s sold to and used by your existing customers, it’s easy to miss this fact. Medical device makers are great at gathering voice of the customer requirements for the actual medical device – what I call “knobology,” the direct operation and use of the medical device. But when you start asking customers how want automated clinical documentation to work, please know that they’re just guessing – because they’ve never done what you’re asking them about. This is fundamentally different from asking a customer about how an evolutionary improvement or new feature on a medical device might work.

The key to getting good requirements for connectivity features is going out to customer sites and directly observing how they do their jobs and documenting this in formal use cases. The scope of this workflow must extend beyond the direct operation and use of your medical device; how far depends on your application.

NIST has some very cool HL7 test fixtures exposed to the Internet that are ideal for testing during product development (obviating the need to work with an EMR vendor). Validation testing must include an HL7 interface to the customer’s EMR.

Now let’s summarize the internal resources you’ll need to sell, install and support HL7 interfaces:

• Sales support will be required to sell the HL7 interface engine. The degree of sales support required varies depending on your product design. A conference call by a technician during an on site sales call by your sales rep may suffice. If your systems are larger and more complex, on-site sales support may be needed to close the sale. Over time this need will decline as reps gain experience.
• A test lab with your HL7 interface running on a server (current released product) that is exposed to the Internet. (You’ll need this to develop the interface anyway.) After the sale, this test lab will be used to configure and verification test HL7 interfaces with whatever HL7 system your interface is integrating with.
• A technician with HL7 configuration experience to work in your lab. This person does not have to be a software engineer and, depending on their work load, can provide customer support services in addition to configuring HL7 interfaces.
• A network engineer is required to install the product. If you’re device is network enabled, this engineer will have to be on site at installation to ensure that your devices and server are properly configured and operating on the customer’s enterprise network. (Networking and network integration are a lot like connectivity, but that’s a topic for a separate blog post.)
• Don’t forget to build into your product the ability to remotely access to the servers installed in customer sites to be able to diagnose problems, apply patches, upgrade software, etc. remotely.
• In addition to the above, customer support will require a solid foundation of general purpose enterprise IT expertise. This can be one just one person, but I would have at least two. You also need resources that can support the application software running on your server, and networking expertise to trouble shoot and fix network integration, performance and reliability issues.
• Tools will be required to trouble shoot and confirm the resolution of installation and ongoing support issues. If your medical device includes wireless networking, you’ll need a spectrum analyzer (you can probably just rent this when you need it in the beginning), a packet sniffer, site survey tool, and probably a few other things. You will, of course, need staff that is competent in the use of these tools.

Resist the urge to train existing installation and support staff to gain the knowledge and experience required to support connectivity and networking; your customers will suffer, and as a consequence, so will you. Hire a core of really knowledgable folks, and then think about training some existing staff to complement your new hires.

You will of course, want to charge a software support fee for the HL7 interface (as well as the rest of the software services running on the server). Pricing for HL7 interfaces is pretty well established (and these prices are trending down, not up):

• The HL7 interface itself sells for between $5k to $10k.
• There is a project management fee associated with the interface technician’s efforts that can range between $10k and $20k.
• Support for this kind of application code ranges between 12-20% of the list purchase price of the application software, per year.

You must sell this support contract to IT, who buys maintenance contracts on everything; Biomed departments tend to resist buying support contracts on medical devices. Even though Biomed is in no position to support your connectivity features, don’t count on convincing them of this and gaining their endorsement of your connectivity service contract.

So, there you have it. A compendium of basic approaches to connectivity for clinical documentation. Remember that this is all high level stuff, and that the devil is in the details. Also, there are exceptions to everything. This should serve well to generally set management’s expectations, and to sketch out an initial project plan. Success in this area is greatly dependent on a solid discovery process that identifies all the important market requirements and results in the most cost effective operations.

With the advent of Meaningful Use, and all that implies, we are all connectologists now. Whether we aspire to be, or not.

[Pictured is the medical device connectivity lab from a hospital in the Northeast - yes, it's a brave new world for them too.]

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.) Last year the FDA was one of several organizers in a series of workshops on wireless medical devices. Oh, and I almost forgot the FDA’s proposed rule on Medical Device Data Systems (MDDS) it was published so long ago (2 years ago next month). You can read more about the draft MDDS rule here, here, here, and here. Finally, the FDA has participated in a number of standards and test and certification efforts, such as the IHE’s Patient Care Device workgroup.

In many ways, the FDA’s regulatory framework is based on the concept of medical devices as stand alone black boxes controlled by manufacturers and used by health care providers. With stand alone medical devices, a regulatory framework that only applies to manufacturers is fine. But when medical devices become components in wider systems that are designed and implemented by sometimes unregulated third parties and maintained by customers, things can break down. As a result, the efficacy of this long standing regulatory framework is called into question. The blog post Medical Device Networks Trouble Industry, offers another example of the potential gaps resulting from limiting regulatory requirements to manufacturers. Medical device networking was also the subject of my presentation proposal for the workshop.

So what’s the purpose or desired outcome of this workshop? From the workshop web page:

The purpose of the workshop is to facilitate discussion among FDA, industry, academia, professional societies, clinical investigators and other interested parties on issues related to safe and effective interoperable medical devices.

This is an uninspiring, or more accurately, overly broad objective. In fact, anyone who attends is likely to have more substantive objectives they’d like to see realized. For example:

• A desire to be educated, either industry’s interests in the regulatory requirements for medical device interoperability, or regulators interests in the kinds of interoperable solutions offered or under consideration by manufacturers
• A goal of convincing the FDA to adopt a new and less onerous regulatory framework within which to realize interoperability
• The objective to gain specific regulatory guidance from the FDA on how to apply current regulations to specific products incorporating interoperability
• As always, there will be some health care providers in attendance who simply want to know how they can go about buying or creating the interoperable solutions they’ve been waiting for so long

After chairing last September’s inaugural Medical Device Connectivity Conference in Boston, I’m just glad to be an attendee.

UPDATE: A revised agenda (dated January 20, 2010), including descriptions of all the presentations, has been released. You can download it here.

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 now starting to look beyond departmental connectivity solutions (i.e. the tactical approach) and are now evaluating their enterprise needs. Looking at an entire healthcare enterprise requires a more comprehensive evaluation of the healthcare organizations’ goals and requirements – and this requires more strategic thinking and planning in a number of areas. Hospitals that attempt to extend their departmental connectivity strategies and technology platforms in ad-hoc fashion, will hit the wall at some point. And in the end, I believe those hospitals will likely spend a lot more time and resources (not to mention money) unwinding what they have in place in order to achieve the level of results that most hospitals are looking for.

In the past, patients on general medical-surgical floors did not have biomedical devices. But over the past five to ten years, the acuity level of general ward patients in many hospitals has increased significantly. Now these patients often have one or more IV pumps and patients are always at least periodically monitored via spot check monitoring every 2-4 hours. And there is a shift towards continuous monitoring in the general ward, mainly to provide caregivers an early warning of rapid decline in state. Rapid response teams are being formed in many hospitals as a means for dealing with early intervention to prevent patient crashes. In all of these cases, the connectivity requirements are distinctly different as compare to a high-acuity (i.e. ICU) environment.

I am beginning to see more and more hospitals recognize this situation, and as a result they are starting to assess connectivity requirements across their entire healthcare enterprise. In addition to increasing acuity levels across all care areas, hospitals are also thinking about some of the challenges around their EMR. Many institutions have one main EMR vendor but many of them have to also deal with the fact that they have several “point EMR solutions” in specialty areas. For example, many times a hospital will have a different vendor in the OR for the anesthesia charting application, and another in the ED for emergency department management. This adds both complexity and confusion for the hospital trying to evaluate their medical device connectivity options, mainly because their departmental applications often come with their own niche solution for solving device connectivity in the specialty care environment.

There are three main use models or categories of medical devices and this has an impact on the connectivity solution and workflow.

•    Category #1 includes the fixed devices – such as anesthesia machines in the OR, or a patient monitor mounted to the wall in a patient’s ICU room. These devices are not going anywhere so managing connectivity tends to be a little easier (sometimes via networks gateways).

•    Category #2 includes devices that can move from patient to patient periodically, but once moved, they remain with the new patient until the patient is transferred or discharged. These would be devices like patient-worn telemetry, IV pumps, and ventilators.

•    Category #3 is transient devices that come and go and move from patient to patient on a frequent basis. Unlike category 1 and 2, these devices could contain data for more than one patient. Examples of these include POC blood testing devices and vital signs spot check monitors used on general medical-surgical floors.

Hospitals are also starting to recognize that there are workflow and patient safety implications — i.e. data from a medical device going to the wrong patient’s record, or alarms from a device not getting to the appropriate caregiver.  Perhaps the largest area for potential gains in both workflow and patient safety can be realized by implementing common methods (the workflow steps) for managing the clinician interaction with medical devices, regardless of device type, make/model, category (as described above), or care environment. The process of managing patient ID and association to medical devices is one key area where standardization needs to be thought about and planned for.

For all of these reasons, hospitals have started to realize that implementing connectivity from separate vendors in different care areas (depending on which vendor application is installed in that particular care area), is a recipe for lots of problems. And this practice will only make it harder and ultimately much more expensive to create any standardization when the hospital is ready.

Here is an analogy that may resonate with some of you. Think of how many remote controls you have on your coffee table at home and how problematic it is to train someone unfamiliar with your equipment and setup – just to watch a basic cable-TV program. Perhaps you have addressed this problem and made life easier by investing in a good universal remote? If you did, then you would have realized that the end result is easier training, less steps (think workflow), and less mistakes. And I am only talking about something as simple (or should be anyway) as your home audio-video equipment. Now think about how non-standard all of the bedside equipment is and how the clinical staff can function without making mistakes.

I would be interested in knowing what hospitals are doing to look at connectivity more strategically and how they are going about assessing their situation and requirements. Let me know what you think?

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.

Up to now, bedside patient monitors have been the priority medical device driver for connectivity. Multi-parameter patient monitors produce approximately three quarters of the total number of device parameters that need to be charted on a periodic basis. Other devices that make up the remaining one quarter of the data set includes ventilators, anesthesia machines (of course in the OR environment), standalone pulse oximeters, IV pumps, standalone cardiac output devices, and even beds (weight, angle of inclination, rail positions, etc.)  However with the increased drive for patient safety in recent years, we are starting to see hospitals discuss requirements for smart IV pumps to be interfaced as a priority over other devices.

One of the reasons for this shift is likely due to the high number of visible errors involved with high profile infused drugs such as Heparin.  Simply put, hospitals are focusing more on those devices that are directly related to patient safety and errors and IV pumps are often in the mix. Hospitals have been migrating to smart IV pump technology. One key market indicator is the rapid growth of smart pumps being purchased – now over 60% of US hospitals have made the switch to smart pumps.  For details – refer to this link.

Even though smart pumps are proliferating, challenges remain when it comes to the integration of smart pump data to the EMR and smart pump alarms to alarm management and notification systems. In reality, there are very few instances of IV pump connectivity to EMR or alarm systems. Not only is there the issue related to patient ID and association (for detailed discussion see this link). There are also the issues related to the unique nature of the data produced by an IV pump. But it is a bit ironic that just as patient safety is driving the adoption of smart pumps, the need to ensure safety is one of the factors holding back the end to end integration to the EMR. Vendors have been very cautious on all sides when determining how to integrate pump data. The stakes are high if the integration does not work 100% – patient safety is at risk.

What really needs to be charted into the EMR from an IV pump is the total volume infused (TVI), the infusion rate, and the drug dose. The problem is that EMR vendors have been working on how to accept automated data from pumps – but some EMR’s are not there yet.

One complexity is related to the fact that the EMR cannot just import the data values directly from the pump devices. The EMR needs to perform a calculation of volume infused taking into account what has already been infused over the last charting intervals. Also, don’t forget that most patients are infused by more than pump device at a time, especially in the ICU.

Another important challenge is related to bi-directional communication with an IV pump. Data must be able to flow seamlessly from the IV pump to the EMR for documentation purposes. But to really reduce administration errors and impact patient safety at the bedside, automating the programming of the pump is required. The order for the infused medication or fluid needs to be transmitted to the right pump at the bedside – and this requires a capability to communicate bi-directionally with the pump device. The workflow challenge for the nurse at the bedside is ensuring you have the right patient, the right pump, and that the order matches the patient before it gets to the pump.

I believe that the focus on patient safety will continue to drive vendors towards providing connectivity solutions that solve these types of complex problems.  IV pump connectivity and integration are the next big frontier in MDC. What do you think? Whether you are a care provider or a vendor – agree or disagree. Do you think I missed anything?

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.

The other key factor for good product design is managing workflow variability. After you’ve done a few workflow exercises you’ll see that most of any workflow is remarkably similar across users. But there’s always some portion(s) of the workflow that are highly variable. These areas of variation must be identified. Then the challenge is to define the degree of variability for each of the variations you’re willing to support in your product.

For every percentage of variability your product does not support, you can expect a certain percentage in lost sales or dissatisfied customers who make the mistake of buying a product that doesn’t match their workflow. Thoroughly understanding  workflow variability enables you to make an informed decisions about how much of your addressable market you want to trade off against the added R&D cost to support the target market’s full variability. Once you’ve captured the variability in your target workflow, you can make informed trade off decisions — and if you decide to support all or part of that variability you’ve likely captured what you need for requirements.

So let’s go back the Koppel paper on BCMA. First, the methodology used to gather the data for their study was similar to what a would be required to capture workflow. They used a combination of structured observations where they directly observed clinicians going about their work over a variety of representative time frames (in representative units, over each shift, at shift change, etc.). This is typically the first phase in gathering use cases. Next, the authors held unstructured and semi-structured interviews with groups of participants. This is a good method to nailing workflow variability, building on a solid understanding of the basic workflow gathered by direct observation. Finally, a couple of the authors participated in staff meetings about BCMA use.

I am sometimes amazed at the amount of “voice of the customer” data a manufacturer can collect, without actually understanding and documenting the actual workflow. Providers too tend to miss the workflow opportunity — on site clinical trials of new systems are a common vendor selection tool, but it is very rare when a provider actually documents their workflow and uses that to provide detailed requirements to prospective vendors.

These missed workflow opportunities, with vendors early in product development and providers at vendor selection, are why reading this paper just makes me cringe. The authors divided BCMA-related workarounds into 3 groups:

• Omission of process steps;
• Steps performed out of sequence; and
• Unauthorized BCMA process steps.

Probable causes of BCMA workarounds fell into 4 categories:

• Technology related;
• Task related;
• Organizational; and
• Patient related.

Reading the actual descriptions of workarounds and their probable causes points to the following shortcomings:

• Just plain old poor user interface design — shame on both the vendor and the providers who bought systems with these problems.
• Poorly automated workflow — either the vendor didn’t understand the workflow, or made a decision to “just have the user do it this way” in spite of the recognized workflow, and again shame on providers who didn’t recognize these shortcomings due to a lack of understanding their own workflows.
• Poor planning or implementation — buying computers on wheels (COWs) that don’t fit through doorways or actually reach the bedside (30′ cords for barcode readers are not the answer) are the responsibility of the vendor to ensure the customer buys the right thing, and ultimately the responsibility of the buyer to, you know, buy the right thing.

Now we come to one of my pet peeves, barcoding. I don’t really understand why the terms “auto ID” and “barcode” are used together. The set up for this requires the production and application of a barcode to a drug, device, patient, etc. And the user must manually pick up the reader and scan the barcode. This works great in the grocery store, but not in hospitals. If it wasn’t for the fact that (when they can be read) barcodes eliminate the potential for typographical errors, barcodes would represent more work than simply using a keyboard. Barcode’s saving grace is that barcode labels are pretty cheap, and in the best utilization of the technology are printed by the manufacturer as part of the product packaging. Again, think of the grocery store.

Barcodes are so simple conceptually, that many discount the planning and engineering required to design and implement a system that works reliably. Many of the workarounds noted in the Koppel paper result from the inability to read the barcode. Getting barcodes that can be reliably read on patient’s wristbands is not a trivial task. You must assemble the right combination of barcode printers, ink, wrist band material, and barcode symbology and orientation (you can’t read a linear barcode that wraps 2 inches around the patient’s wrist — you’ll never get it flat enough to scan). Another big problem with BCMA is that many of the barcodes on the meds administered to patients have to be produced and applied by the hospital.

Earlier this week I was interviewed for a magazine article singing the praises of barcodes in general, and meds administration in general. I asked the writer what market adoption rates for BCMA they’d uncovered. Over the past two years adoption grew from 23% to 25%. Certainly we’ve know about the need since the publication of the IOM’s publication of To Err is Human in 1999. The adoption of BCMA is not low and slow because hospitals don’t care. Koppel’s paper does a lot to shine a light on some of the reasons adoption has lagged. I’ll be surprised if I get quoted in the barcode story.

Here’s an overview of the agenda:

• Define and frame medical device connectivity for this event
• Industry standards
• Regulatory issues
  • FDA’s proposed MDDS rule
  • IEC 80001
• “Systems of systems” patient safety issues
• A review of the real costs of connectivity

Day two is divided into three tracks:

• Infrastructure, especially converging medical device and enterprise networks
• Connectivity solutions, a review of the most common connectivity applications (it’s not just about EMR integration)
• Clinical and workflow impacts of connectivity

Friday afternoon, there are two great post-conference workshops. One workshop delves into Distributed Antenna Systems (DAS), describing best practices for the selection and implementation of DAS. The second workshop is for providers and manufacturers getting ready for IEC 80001. You are getting ready, aren’t you? This workshop details the standard’s requirements with special focus on the risk management process that’s at the heart of IEC 80001.

The conference well be September 10 and 11 (Thursday and Friday) in Boston, at the Joseph B Martin Conference Center at Harvard Medical School. This is a pretty snazzy venue, as you can see by the photo.

This conference includes an innovation that’s just starting to appear in conferences like this. On the second day, there is an additional track where attendees can meet with conference sponsors. This is your opportunity to get an indepth demonstration or have a meaty discussion with one or more of the sponsors.

Sponsors for the event are many of the leading manufacturers in connectivity or patient care device integration (PCDI) market:

• Capsule
• Cardiopulmonary
• Cerner
• Hill-Rom
• Cisco
• Nuvon
• Philips

Just today, I heard that Fluke Networks has joined as a sponsor.

Acquiring Medical Device Data is Key to Clinical Decision Making

Medical device connectivity in the ICU is essential to supporting a complete clinical decision support framework. While electronic medical records in and of themselves offer enormous workflow benefits, the documentation and charting systems are only as good as the data they convey.

Due diligence by care providers can be augmented by automated and validated data collection, achieved through a seamless form of medical device connectivity and interoperability that is supported both inside and outside the enterprise, and follows the patient from the home to the hospital. Yet, as we know, human beings are complex systems of systems.

Decision making in the healthcare enterprise is often made on the basis of multiple parameters and in the context of the patient presentation, setting, and specific conditions relating to the reason for hospitalization and procedures. The data used in clinical decision- making originates from many sources: devices in and around the patient, laboratory and blood tests, films, and ancillary information available both prior to and during the encounter. How often should data be collected? The assessment of clinical needs change depending on the acuity of the patient and conditions present at the point of care.

Updates per care unit drive the quantity of data captured within the bedside documentation, either through flow sheets or paper records. But, the team supporting the patient ultimately must define what is acceptable and required. To support clinical decision making it will also be necessary to include other data from the electronic health record. These include fluid intake and patient output, demographic data, laboratory blood draw assessments, films, etc. Clinical decision-making must be made with data measurements obtained from devices at the bedside and from the ancillary data taken from the electronic medical record.

An Acute Care Scenario

We can learn something of what is required to manage patients effectively by following them through several key departments within the hospital enterprise—a “day in the life” of a patient. In laying out the details of such a scenario, I will draw upon my own experiences at the point of care.

Perhaps there is no better place to consider than the intensive care unit (ICU). The ICU environment cares for the sickest of acutely ill patients. Many patients within ICU environments, and particularly surgical intensive care units (SICU), are technologically dependent on the life-sustaining devices that surround them. Some of these patients are indeed dependent for their very survival on such technologies as infusion pumps, mechanical ventilators, and intra-arterial balloon pumps.

Consider a patient who enters the hospital for a coronary arterial bypass graft, and the workflow and environment surrounding a typical encounter. To this end, I will refer to a former patient, Mr. A. It was determined by Mr. A.’s cardiologist that he had 90% occlusion, or blockage, of three of the coronary arteries supplying his heart muscles with nutrients. As a result, Mr. A was recommended for immediate coronary bypass surgery the following morning.

During the admission process, he is assigned an electronic medical record number along with account and related personal and payer identifying information so as to enable charting and tracking his progress throughout the hospital. As Mr. A. is prepared for surgery, he is moved to a pre-operative waiting area. He receives drugs to reduce the workload on his heart and to prepare him for the anesthesia. He receives sedation and is wheeled to the operating room where his anesthesia and surgical teams prepare him for the procedure. The anesthesiologist manages the patient’s airway, sedation, and monitors vital signs.

In the case of patients receiving coronary bypass grafting in which the heart is stopped, the patient is also placed on a bypass machine that oxygenates the blood and returns it to the body. Vital signs are documented, either automatically or through a paper record, and all drug infusions are recorded by dose, time, rate, and titration. Mechanical ventilators breathe for the patient and replace the exhaled CO2 with oxygen. Upon completion of surgery, the patient is wheeled to surgical intensive care, whereupon mechanical ventilation is continued, vital signs are monitored, and drug infusions are administered.

These devices all create measurements that are used to govern, maintain, and document the status and trajectory of the patient as Mr. A. recovers. Gradually, as the effects of the anesthesia wear off and as heart function becomes more stable and strong, the patient begins to breathe spontaneously. Gradually at first, but increasing over time, measurements documenting the trajectory of spontaneous breathing are captured and used to evaluate patient state and recovery. Laboratory blood gas tests are used to affirm proper physiological, renal, neurological, cardiovascular, and pulmonary function over time. All measurements are recorded within Mr. A.’s medical record.

Physicians write orders guided in part by the patient’s recovering state. These measurements, if recorded automatically from the medical devices, can serve to greatly increase the charting process at the bedside. However, as importantly, they can also serve to guide in clinical decision making by providing the Intensivist, and other attending clinicians, with key information on the state and systemic health of the patient in regard to this immediate procedure.

Data taken from bedside devices can also assist in determining whether the patient is at added risk due to co-morbidities or ailments that can be acquired while in the hospital, such as ventilator- or community-acquired pneumonia or sepsis. The ability to assist the bedside clinician is enhanced greatly through the added benefit of complete, dense, and thoroughly documented information. Charting (or “flow sheeting,” to which it is sometimes referred) involves the documenting of all information relevant to the care of the patient, including vital signs, fluid intake and output, laboratory values, ventilator and respiratory information, and other non-numeric data that provide insight into the care and progress of the patient.

Yet, despite the inordinate amount of data collected at the bedside, these are but a shadow of the patient—an approximation of the state of the individual and this state changes with time. For example, tools and methods that can assist or guide in the weaning of the patient from mechanical ventilation; determine whether the patient is at risk for myocardial infarction or provide insight as to whether the patient is likely to experience other complications, can greatly enhance patient care management and clinical workflow within the intensive care unit, and can result in more homogeneous and stable outcomes for patients. Let’s consider the process of weaning patients from post-operative mechanical ventilation as an example.

Weaning the Patient from Post-Operative Mechanical Ventilation

To assist in visualizing this scenario, refer to the diagram of Figure 1, which illustrates the intra-operative (OR) and post-operative (SICU) processes. Data are collected through a number of sources. As shown, an anesthesia machine is employed to assist in the electronic charting and capture of patient vital signs into the electronic medical or electronic health record. Once surgery is completed, the patient is moved to ICU in which further monitoring and management of the patient continue. Shown are a Swan-Ganz catheter and a mechanical ventilator. These two modalities are used to collect key information required for weaning our patient post-operatively: cardiac output, temperature, cardiovascular function, and respiratory state.

Figure 1: Diagram illustrating high-level intra- and post-operative timeline and key medical devices employed in support of the patient.

The process of weaning a patient from post-operative mechanical ventilation is an important one that consumes a fair amount of time and resources within the SICU environment. Patients are typically weaned according to specific protocols that involve monitoring their spontaneous lung performance and cardiovascular systems to determine whether, during this weaning process, they are receiving sufficient support. While the process is well defined, individual patients can behave differently depending on many factors including physiology, anesthesia dosing, general health of the pulmonary and cardiovascular systems, co-morbidities, etc.

Patients being weaned from mechanical ventilation post-operatively must meet specific physiological criteria prior to being weaned and must be managed closely during the weaning process to ensure that physiological parameters and other data are always maintained within safe and approved thresholds. Examples of such thresholds include chest bleeding less than 100 CCs per hour, warming to normothermia (normal core body temperature), normal blood gas oxygenations in excess of 95%, normal ranges on cardiac output and perfusion ratios, and normal blood gas results.

Data collected both during the post operative weaning process from bedside devices can be compared with data from similar patients so as to provide for an a priori assessment of whether the patient state is evolving normally during the process. Because a patient’s lung function has been compromised due to the strong paralytic drugs administered during surgery, patients tend to arrive dependent on the mechanical ventilator for breathing.

Most (if not all) mechanical ventilators used in the intensive care unit support the capability to communicate data through standard RS-232 ports. The type and quantity of data relate to the settings, mandatory support levels, and patient (or spontaneous) levels. As patients begin to recuperate, their spontaneous support levels evolve from zero to some final value related to full spontaneous support. This is illustrated notionally in Figure 2, which shows patient spontaneous minute volume (that is, the volume of air breathed in a minute’s time) as a function of time after arrival from surgery. The time at which a patient begins to breathe is related to many factors, as stated above. The ability to metabolize the anesthesia is one of these. A patient will begin to breathe slowly and will gain his or her strength over time, as illustrated in this figure. The time at which the patient begins to breathe on his or her own is loosely tied to several factors, including their body mass and core body temperature. Of course, the assumption is that the patient is not being maintained in a sedated state post-operatively. This can be the case and for a variety of reasons. However, we will assume the most typical of cases, in which a patient is being weaned gradually over time.

Figure 2: Notional representation of patient respiratory recovery as depicted by post-operative minute volume evolution over time.

Prior to weaning, a patient should achieve normal body temperature to ensure all bodily functions can operate at their optimal levels. The following graph, Figure 3, illustrates a normal re-warming profile of coronary bypass patients recovering from the effects of anesthesia [1]. The horizontal axis represents time from arrival in SICU from surgery. Thus, from the perspective of our patient, Mr. A., we should begin the weaning process as the patient approaches normal body temperature, around 37C.

Figure 3: Average time to achieve normal body temperature.

As the effects of the anesthesia wear off and the patient’s respiratory performance returns, the evidence of this improvement and strengthening is visible from the data collected through the ventilator. These data, when charted, provide a visible trend that reflects the patient’s pulmonary and cardiovascular performance. These data can be used to help guide the weaning process as well as confirm and feed back to the clinician the patient’s response to stimulus and treatment during the unconscious state.

The time to achieve spontaneous breathing at a rate of 1 liter per minute was determined in a study of bypass patients in SICU by the author, and is represented according to the plot of Figure 4. In this assessment, the author hypothesized that the time to re-awaken, defined as spontaneous breathing in excess of 1 liter per minute for a period of 10 seconds or longer, was related to the amount of analgesia / anesthesia administered during surgery. The typical anesthetics administered to patients include propothol and fentanyl. The author further hypothesized a linkage between the fentanyl dosing and the re-awakening time. The following plot illustrates a best-fit plot to the original data (r² = 0.61).

Figure 4: Time to achieve breathing level of 1 liter per minute post-operatively linked to analgesia and anesthetic dosing intra-operatively.

Thus, armed with information related to breathing (available from the mechanical ventilator), core body temperature (available through Swan-Ganz or similar core catheter), and intake & output information from surgery, the clinician can begin to develop an understanding for the expected relationships these may play in terms of guiding patient post-operative weaning. This information is available from previously charted information, from direct medical device connection, and from the surgical flow sheet.

Ultimately, the data collected through the mechanical ventilator are augmented by this information to assist the care provider in guiding patient weaning, in ordering procedures and changes to support that are consistent with the patient’s ability to respond, and help reduce the risk to the patient. The plot of Figure 5 illustrates the mandatory (set) value of respiratory rate and the spontaneous (patient) value of the same parameter during the post- operative weaning process of a coronary bypass graft (CABG) patient [2]. The spontaneous component of this plot is similar to the plot of Figure 2 in shape. As can be seen, the mandatory value of respiratory rate setting is reduced in steps over time. The spontaneous component shows growth to a final value near extubation time. Measurement and collection of these data were through a standard RS-232 serial adapter into a laptop computer.

Figure 5: Mandatory and spontaneous respiratory rate plots for patient in question.

We can illustrate with several diagrams where these data can be collected and compared for decision making purposes. Figure 6 illustrates the fentanyl dosing in comparison with the model developed from a larger sampling of patients to provide a rough guide as to viability to wean in terms of expected time after arrival from surgery.

Figure 6: Flow diagram illustrating comparison of patient-specific fentanyl dosing with larger model to indicate relative time to excrete effects of intra-operative drugs.

Figure 7: Comparison of patient temperature to illustrate approximate time required to achieve normothermia.

Figure 8: Patient spontaneous respiratory rate in comparison with mandatory settings to provide gauge on viability to wean.

Figure 7 and Figure 8 illustrate the time required to achieve normothermia and the patient respiratory rate performance over time, both collected from bedside monitor and mechanical ventilator, respectively. If we look at the time to reach normothermia and the time required to dissipate the effects of fentanyl in relation to this plot, we have the graph of Figure 9.

Figure 9: Spontaneous and mandatory respiratory rate with indicators as to when normothermia is achieved and drug effects have dissipated.

As we can see from Figure 9, viability to begin trials for respiratory weaning appears to be achieved after approximately 250 minutes. Of course, other data are also used to assist in making this decision and to determine viability, and expert or related systems cannot be used as a substitute for a bedside clinician. Yet, the possibility to assist and guide the clinician in determining whether it is advisable to proceed can indeed serve a positive end in guiding overall therapy.

Summary

As the patient re-awakens and approaches viability for extubation, it becomes even more important to acquire and analyze measurements from medical devices as these are used to determine whether the patient can be discontinued from mechanical ventilation. The re-awakening time model is a simple but useful tool to guide clinical decision making in the acute setting for a very specific class of patient. Thus, it facilitates the patient care management process in enabling the clinical staff to predict with some reliability when patients require attention during the normal course of care.

Medical device interoperability and integration with external systems becomes essential to clinical decision making ability. There are a number of commercial technologies that support basic interoperability and communication, and I have worked with a number of them. The end in itself is never the ability to merely communicate with a medical device, but, rather, to use the data as a means to assist in making clinical decisions.

Efforts to date in the electronic health record and health information technology areas have focused on documentation, clinical workflow, order entry, notes, and charting. These are all necessary enablers to assist the care provider as a “colleague.” However, clinical decisions are made on the basis of all data presented to the clinician, and involve both real-time and ad-hoc data presented in the form of reports, waveforms, trends, and even hunches based on prior experience. This is the key– all data, communicated intelligently, filtered and analyzed appropriately, presented clearly– so as to assist in diagnoses, interventions, therapies, and long-term trending of patient state and care.

[1] Source: J. Zaleski, based on study conducted by author in surgical intensive care unit of major teaching hospital. [2] Source: J. Zaleski