As discussed in a previous post, there have been numerous false starts and failures in the implementation of secure text messaging platforms in the healthcare environment.  The landscape is littered with expensive solutions that have seen low utilization, projects being shelved and as a result patient health information continuing to be shared via unsecured methods.

The primary reason for this situation is poor adoption by physicians and subsequently inconsistent use throughout the system. Poor adoption leads to overall poor utilization and a lot of wasted time, money and energy.

But physicians and care providers aren’t to blame. The blame falls on the technology itself. Few of the existing secure messaging products were designed to work with physician workflows and account for physicians need to control accessibility.  Most physicians do not want others to have ‘open access’ to them, nor do they want to ‘sign in’ when they are available or remember to ‘sign out’ when they are not available.

While other technology vendors have provided public RFP templates for secure messaging, those templates focus primarily on the core functionality and the technical requirements of an individual product. They do little to highlight those functional features that will actually encourage broad physician adoption. So, while these templates are helpful, they do not necessarily help you achieve your goal of high user adoption.

With the goal of high user adoption in mind, here are seven key functionality questions you should include as part of your RFP for secure text messaging:

  1. Does the technology automatically route certain types of messages to the physicians designated resource? This might be a resident, PA, fellow, or other clinical staff member. Physicians need control over their access and most solutions don’t offer a way to integrate these physician preferences into their applications.
  2. How do physicians control their availability when they are not on call? Asking physicians to check in and check out every time they want to be unavailable is not a viable solution, and quite frankly, physicians won’t do it.  Look for a solution with one time availability set up that accounts for call and clinical duties.
  3. What happens when a message comes to a physician’s phone when they are in the middle of a procedure?  This is one of the biggest complaints about secure messaging applications.  The application should have an ability for scrub nurses or other providers in the OR to proxy into the physician’s account without having to access the phone. This allows timely response without the OR staff having to access doctor’s personal cell phone and pass words.
  4. Does the platform allow for the user to identify and contact the patient’s current care team (including currently attending hospitalists and nursing staff) through one click access? Having to sift through the frequently long and comprehensive ‘care team’ listing in the EMR does little to facilitate fast, seamless interaction to those who are taking care of the patient at the moment.
  5. Does the application integrate with call centers and other communication systems? Doctors don’t want to carry multiple devices. If secure texting is utilized as the primary method of contacting doctors (which increases adoption), the application needs to be integrated into the call center and function within the parameters of the call centers existing workflows
  6. Does the application architecture and pricing allow for broad distribution to outpatient-based physicians, including regional referring doctors without running afoul of anti-kickback laws and incurring additional costs? Many current technologies offer ‘per head’ licensing, which a) limits the distribution of the product, limiting the overall adoption (see point above). Also, the technical architecture needs to ensure the application can be provided to these referring physicians without fear of giving something of value to these doctors.
  7. Does the application integrate with nurse duty phones? Maximizing nurse/patient interactions is critical. If nurses have to use a desktop-based application, this reduces the available time for patient/nurse contact. Similar to the point above, if the system is to be charged for every downloaded application, adding the hospital-based nurses to the installation can be extremely expensive.  Evaluators should look for a product that not only encourages broad distribution, but facilitates that through enterprise-based pricing and integrates with nurse duty phones to maximize patient contact.