Issue 8, May 9, 2019
Happy Reading 🙂
How do I improve M3-Patient Experience response rates?
1) Consistently collecting patient email addresses: Pushing the patient an emailed invitation is the number one action that will generate and sustain adequate and better response rates. Practices that collect the patient’s email address as part of the practice’s normal registration process, similar to collecting the patient’s phone number, physical address and other contact information; have on-going, good response rates.
2) Adding a “Please Take Our Survey” link to the practice’s website: If your organization will allow, adding a link on the practice’s website that reads, “Please Take Our Survey” can increase survey responses. Touch base with your practice’s internal resources (web-master and/or ITS team), to see if they can assist with adding the survey URL link to your practice’s website. The unique URL for your practice’s M3 survey may be obtained by logging into M3-Patient Experience and clicking “Manage Survey”. This page also provides for the generation of a QR Code for your practice’s M3 survey.
3) Hand outs: Some M3 clients choose to handout post-card size “invitations”, asking patients to take the survey, which serves as a reminder when the patient returns home. The invitation may have the practice’s website address with a “Please Take Our Survey” link on the website or the QR Code for your practice’s survey for the patient to scan and take the survey on their mobile device.
4) Placing a PC or Kiosk in the practice waiting area or using Tablets or iPads — the good and the bad: Some M3 clients have positioned PC’s and/or Kiosks in the practice’s waiting areas along with signage advertising the survey, and some have utilized iPads or other hand-held PC tablet devices. While utilization of in-clinic devices makes for a nice PR touch — especially with some professional signage posted around the PC or kiosks — please know that it has been our experience that the incremental increase in survey responses most likely will be minimal. In addition, using tablets or iPads will require someone to be responsible for monitoring and maintaining the device to ensure the devices are not abused and/or pilfered. Please check with your organization to see if in-clinic devices are allowed.
How can I promote M3-Patient Experience within the practice?
Click the link below to download the M3 promo materials zip file. In the zip file you will find a set of promo materials containing pdf files that are “print ready”, as well as promo materials saved as Microsoft word documents, which may be edited as needed; allowing for the addition of logos, changing text, etc.
A check-list that describes certain techniques used by other practices to help increase patient participation is also included, which may be very useful.
Download M3 Promo Materials (zip archive file.)
What can I do about undeliverable patient emails?
It’s not unusual to get 15% to 20% of the emails retuned as undeliverable, usually because the patient has a new email address, and/or a new internet service provider.
Whenever an email is not delivered, an “undeliverable” or “failure notice” will automatically come back to the “From:” sender’s in-box, providing an opportunity to flag the patient’s file to allow for a corrected email to be obtained during the patient’s next visit. Many patients will change their email address over time, which may cause the email to be “rejected” or “undeliverable”. If flagging the patients; record is not practical, asking your registration personnel to confirm that the patient’s email address is up-to-date as patients routinely check-in and/or register, much like updating other patient contact information, will minimize the “undeliverable” bounce backs.
“Failure Notices” or “Undeliverable Emails” are automatic emails that bounce back whenever the patient’s email address is not deliverable, usually because the patient has a new email address and their “old” email address is no longer active. Typically included in the body of the “failure notice” text, there’s a reason for the rejection, such as “invalid mailbox” or “addressee unknown.”
Many of the “Failure Notices” or “Undeliverable Emails” will include a “Numeric Code”. Understanding these codes will assist you in determining corrective action in obtaining valid email addresses. Some of the more common codes are presented below:
5.X.X Permanent Failure: A permanent failure is one which is not likely to be resolved by resending the message in the current form. Some change to the message or the destination must be made for successful delivery. For example, if the patient’s email address is no longer active, resending another invitation to the same, inactive address will not be successful, or if the patient’s email address was mistyped, the typo should be corrected before resending the email.
550 5.7.1 Access denied: That is a well-defined (although not directly useful) response code. The ‘550’ is part of the basic standard for SMTP and is defined in RFC2821 as: 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons). The additional code “5.7.1” is part of an extension of the response code system that provides more precise detail.
X.7.X Security or Policy Status: The security or policy status codes report failures involving policies such as per-recipient or per-host filtering and cryptographic operations. Security and policy status issues are assumed to be under the control of either or both the sender and recipient.
X.7.1 Delivery not authorized, message refused: The sender is not authorized to send to the destination. This can be the result of per-host or per-recipient filtering. In short: the receiving server that refuses to accept a message with this response is telling you that it is doing so because of an unspecified policy, which “could” be just about anything imaginable. Policy is subject to the desires of individual mail system operators.
4.4.7. This code typically indicates an issue on the receiving server. Verify the validity of the recipient address, and verify that the receiving server is configured to receive messages correctly. The message in the queue has expired. The sending server tried to relay or deliver the message, but the action was not completed before the message expiration time occurred. This NDR may also indicate that a message header limit has been reached on a remote server or that some other protocol timeout occurred during communication with the remote server.
We hope you are finding Thinking Thursdays TIPs useful. If so, drop me an email and let me know your thoughts. If you don’t automatically receive Thinking Thursdays TIPs in your inbox, subscribe here.