By Dan DeMaria, CBET
With the advent of the Health Information Technology for Economic and Clinical Health (HITECH) Act enacted as part of the American Recovery and Reinvestment Act of 2009 and Meaningful Use, we have begun a journey. At the end (if there is truly an end) of that journey is a utopia in which all medical information collected over the course of a patient’s lifetime will be readily available to any caregiver. This information will be in a consistent format, it will be completely secure, and it will—at the same time—be instantly available to anyone who needs it.
That is pretty ambitious. It is also very far-reaching, meaning it touches many disciplines within medicine.
I started writing this article a couple of months ago, and have since that time completed a “go live” with what my organization termed “Phase 2.” That may sound like an innocent and simple project, but trust me when I say: It struck fear into the heart of many involved.
At the heart of our “Phase 2” project was a simultaneous move to computerized physician order entry (CPOE) and bedside medical device integration (BMDI, also known as biomedical device integration). CPOE is a process of electronic entry of medical practitioner instructions for the treatment of patients (particularly, hospitalized patients) under his or her care. These orders are communicated over a computer network to the medical staff or to the departments (pharmacy, laboratory, or radiology) responsible for fulfilling the order.
BMDI is the process of integrating medical equipment into the electronic health record in such a way that various settings, alarms, and physiologic patient data are captured and correctly entered into the patient record.
BMDI is much like PACS integration—we match a patient name and/or number with a bit of physiologic information. |
This article will focus on device integration and provide some of the lessons learned, unforeseen difficulties, and hopefully an understanding of the journey.
At the first meeting where we discussed device integration, I reflected on the early days of DICOM. With the advent of DICOM, every medical imaging device could instantly share images with PACS. Modality Work List automatically populated the imaging device with patient demographics, and physicians could instantly read those images on their home 90-mHz Pentium computers connected via a 56k modem.
The world was also filled with unicorns and rainbows. In other words, I was having horrible flashbacks as leadership described the standard communications and design protocols that would allow me to send patient data to the electronic medical record.
I did not laugh, nor did I cry as the milestone dates were unveiled. I did what every biomed (embrace the term, folks) “health care technology management” (HTM) professional should do. I began to think about the scope of the project and divide it into manageable chunks. I won’t claim my way was the right way, but it worked. Hopefully, everyone embarking on this road to device integration can learn from our successes and mistakes.
BMDI
BMDI is much like PACS integration—we match a patient name and/or number with a bit of physiologic information. We gather the physiologic information using traditional methods, and we bundle that information into a neat electronic package. Instead of DICOM, we use a format called Health Level 7, or HL7, to translate data gathered by the machine into the health record. How hard can that be? It is a standard that everyone agrees upon, right? In theory, yes. In reality, it is a bit complicated.
One of the first steps to successful integration is to truly map out the desired results and the full scope of work. Decide which devices will be integrated and to what extent. Once a desired outcome is agreed upon, the hard part begins.
Get an inventory. Every clinical/biomedical engineering (now also known as HTM) department should have an inventory of devices, so you should be able to simply run a report showing how many of each device is in inventory. This will give you a picture of how many of each type of cable, adapter, or other connection method is required, right?
Maybe not. The questions that must be asked are:
- Does each model of equipment support data export?
- Do the devices have the required options or licensing required to support BMDI?
- What software revision is each device using?
- What type of output connecter is used? Is it a DB9 male or female? Is it Ethernet? Is it wireless?
- Is native support available, or will we need an intermediary connectivity device?
- It is a good idea to verify all of the above. Relying on vendors can cause unplanned expense and embarrassment.
Unless the computerized maintenance management system (CMMS) used to track medical devices at your facility is extremely detailed and includes software revisions and installed options, it is preferable that someone performs a physical inventory. Once a detailed picture of available devices and capabilities is developed, it is time to begin asking which devices should be integrated. Does it make sense to integrate the blood pressure device that is a one-of-a-kind unit that will require $2,500 in external hardware plus development time and is used four times per week?
One of the biggest lessons learned is the absolute criticality of working as a team. |
Now that you have a plan and a rough road map in place, it is time to start building a team. The team should include clinicians, HTM, IT, and the electronic medical record (EMR) vendor. Clearly defined roles and responsibilities are important. This is not as easy as it seems because the lines between medical device, IT infrastructure, and the EMR are rapidly blurring. The work accomplished defining responsibilities during design, test, and build will pay big dividends during deployment and “go live” support.
Creating a Test Environment
Once a plan is developed and a team is assembled, developing a test environment is critical. It is highly desirable to create a complete test system that will allow end-to-end testing. In some cases, it may be necessary to use production patient data (eg, live patient monitoring) and bring this data into the test environment. In our case, we have parallel data streams to production and test systems. One issue we encountered was data field mapping when using the “demo” mode of medical devices did not match live or simulated (using a simulator) data. Do not rely on demo mode data to perform mapping, as it may not work.
It is a good idea to perform realistic testing once everything appears to be working. Write test scripts that cover every step of the patient experience from admit, to vital signs collection, to discharge. Include transfers and use every device—ventilators, balloon pumps, IV pumps, and any other device that will be integrated. By using formal test scripts, all scenarios can be properly evaluated.
During this test phase, it should become apparent where failure points will occur and triage methodology can be developed.
What will the support model look like? Will all calls route through the IT help desk? Will all calls route through the HTM department? Defining the process now will help avoid confusion at “go live.”
Cooperative Integration
This truly is integration; clear lines in the sand do not work. Cooperation between clinical/biomedical engineering, IT, and clinical informatics is the new norm. To ease the transition to integrated medical systems:
- Identify the goal.
- Select the team.
- Involve everyone, including clinicians.
- Create detailed test scenarios.
- Test, test, test.
- Determine how to support the system from end to end.
- Put in place a formal change management process.
It sounds fairly simple, but overlooking any of these steps can cause difficulties when it is too late. We should not have an, “Oh, I didn’t think about that,” moment when we are working with live patient data. This is a great opportunity to share HTM best practices while learning IT best practices. Hopefully, during the process of integrating equipment and systems, the process of integrating HTM and IT will begin as well.
Lessons Learned
One of the biggest lessons learned is the absolute criticality of working as a team. HTM, clinicians, and IT each bring a piece of the puzzle to the table. We formed informal working teams of experts that worked through issues together. In this way, not only were problems resolved in a timely manner, but also all team members learned from one another. Post “go-live” this has resulted in quick triage and call routing of issues, as different team members understand end-to-end workflow.
During “go-live” our organization set up a war room that was manned 24/7 by subject matter experts. This allowed ready support for clinicians. We documented all issues and discussed them at shift change. This allowed us to have a continuous flow of information and knowledge transfer.
From an HTM point of view, we learned that it was vital to learn end-to-end data and workflow. This entailed participating in user training. We learned how to chart BMDI, and we learned how to map data fields in the application. We learned to follow the data from the medical device to the server and to the patient record. As the system has been fully implemented and the “war room” disbanded, we find that clinicians call biomed anytime there are BMDI issues. Rarely are the calls related to the medical device, but by understanding the complete data path and workflow we are able to quickly engage the right people to resolve our customer’s problem.
Perhaps the biggest lesson learned during the integration process: There are few clear lines of demarcation with respect to BMDI. The days of “us versus them” truly must end if we are to succeed. 24×7 Service Solutions December 2012
Dan DeMaria, CBET, is the manager, bio-medical engineering and telecommunications, Olathe Medical Center, Olathe, Kan. For more information, contact the editor.
