From what I have observed over many years, Hospitals have historically approached medical device connectivity projects as a tactical issue to be dealt with. Up until relatively recently, technology alone could be used to solve the connectivity issue (i.e. getting data from point A to point B) with little to no negative impact on clinical workflow. Further, the scope of connectivity projects has been mainly departmentally focused and deployments have been relatively basic. By basic, I refer to projects that have focused on connecting one or two bedside medical devices to a single CIS application or EMR.
Evidence of all of this can be found by looking back at the past 10 or more years and examining typical implementations of biomedical device connectivity to information systems.
• Most implementations up to now have been in very specific care areas such as the ICU and OR.
• Most implementations are relatively small in scope, often in the area of about 20 to 50 beds. Incidentally, for most US hospitals this happens to be about the same number of ICU beds per facility.
• In the ICU, the key devices that are interfaced are typically multi-parameter patient monitors and sometimes ventilators - but vents to a much lesser degree than monitors.
• In the OR, the key devices are typically patient monitors and anesthesia/gas machines.
• Outside of high-acuity care areas, in the general ward there are some limited niche interface solutions for mobile vital signs data capture. Many of these are only semi-automated in terms of truly automating both the data capture and the clinical workflow.
• For virtually all of these implementations, the data collected from the devices is identified though a mapping of the medical device’s location – that is a bed or room location identifier is used to associate the data and alarms.
• The device workflow - that is the steps clinicians are required to perform at the bedside to interact with devices to establish connectivity – has been limited. This is because most of the devices are actually fixed to the location – i.e. the monitors in ICU are mounted to the wall and data is interface via a networked gateway with outbound HL7. Therefore few if any steps are required by clinicians because the devices are permanently tethered to a local PC or terminal server that facilitates the data collection.
But as discussed in some of my previous market trends postings – requirements for connectivity have been changing and in some not so subtle ways. Many hospitals are 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?
Great post on a key hot topic in the industry today.
From my experience, the technology aspect of achieving enterprise data acquisition is much easier than the political aspect of getting departments to be on the same page. Large health systems need to implement Interoperability Committeeâ€™s that address existing asset compatibility and then set purchasing standards for future equipment. This assumes that as an enterprise you have already defined the specific data elements, frequency of collection, etc., of the data you want captured and stored in the EMR.
Each department will always have their specific workflow, however as an enterprise you need to set standards on protocols, formats and connectivity to name a few. One of the problems is, when a vendor comes into an individual department and sells them a product based on a cute little block diagram that shows how easy it is to implement the system into their current environment. Without a process in place that requires these types of purchases to meet a minimal set of standards, you will be stuck with another proprietary system that requires another gateway and $1000 an hour to write an outbound interface to capture one simple data element. Not to mention it will probably be completely unsecured and a threat to every other system on the network.
1. Adopt a minimal set of enterprise standards and then enforce the standards on purchases where data acquisition could be achieved. By minimal I mean, it must natively support HL7 v.x, MIB x73, etc.
2. IT and BioMed departments must be partners to ensure you only impact the workflow of care-givers in a positive manner.
3. All standards should be reviewed by a Workflow Impact Committee to keep ambitions grounded to reality.
4. A culture must be encouraged from the top-down on the importance of collecting this data and following standards.
What I am curious about is how you define a support model when you have a â€œsystem of systemsâ€ achieving this enterprise view. For example, you may have a Capsule Terminal server in the room connecting GE monitors & other POC devices which is then sending data to one server, which then sends EMR data to another server and alarm data to another server (which then sends it to another server that actually communicates with a communication device SIP, etc.). Then you have a Nurse Call system that wants to own device assignment and an alarming middleware that also wants to own it.
The reality is, when you diagram out all the connections to the POC devices, networks (VLANâ€™s), gateways, servers, interfaces and communication devices, you end up with a situation where determining who owns a problem is a nightmare. Then you still have to consider FDA regulations, current and future (MDDS), and the potential impact of IEC 80001.
Craig - great comments. You appear to have taken a few “arrows” along the way. Your remarks about vendors presenting departmental solutions and their “cute little block diagrams” resonates with me. From my background in both alarm management and device connectivity - I have experienced the proliferation of ad-hoc systems such as you describe. The result that hospitals are left with is referred to as “the accidental architecture” - that is the piecemeal collection of systems and technologies that the hospital is left with to both integrate and support. This is obviously nothing that most hospitals planned for - it just happens because of what you describe. It is the inherent behavior of the purchasing process for many systems. I did want to mention that in addition to the complexity relating to the systems, networks, and various technologies - there is the issue of the overlapping work processes. You mention the topic of managing staff assignments - this is a perfect example where all hospitals are doing this in multiple systems and in uncoordinated ways.
Your 4 recommendations are spot on! I could not agree with you more. I might call these “the 4 ways to prevent the accidental architecture”. Hospitals would be well advised to adopt these practices. From what I have experienced in many hospitals (really most), it is purely a lack of communication and coordination across departments that is the hardest issue to resolve. Just getting Biomed and IT to talk and coordinate efforts is a major challenge.
Your last comment about how to deal with the resulting “system of systems” is one of the most important issues. Anyone that has followed Tim Gee knows this is an area that has been discussed quite a bit. The recent MDC Conference in Boston discussed this. Regarding how Capsule can help help hospitals deal with this - the Capsule system will provide visibility and management of the connectivity from the medical device, through the middleware, and all the way to the EMR or the destination system. But you describe an even larger system of systems - and this is really the core of the problem. Can anyone get the arms around this entire issue? Time will tell.