" email Archives - LuxSci

Posts Tagged ‘email’

How to Tell If Someone Read Your Email: Read Receipts and Web Bugs

Tuesday, January 30th, 2024

We’ve all been in this scenario: you send an important email to your boss or a client, and then you wait, stressed out and anxious to know if they received it and their response. Typically, you can request a read receipt when sending the message to confirm the email was received. Another method, HTML web bug tracking, can also be used to see if an email message was read. However, spammers often use this method to identify active email addresses. Both methods are unreliable ways to tell if the recipient read an email.

The only way to have complete confidence that a message was read is by using a secure web portal solution like LuxSci’s SecureLine Escrow. It also allows for message retraction, which can be helpful when handling sensitive information.

This article explains how read receipts and web bugs work and how you to tell if someone read your email.

email read receipt

What Are Read Receipts?

Read receipts are requests attached to an email message by the sender. Most email programs, like Outlook, Thunderbird, and LuxSci WebMail, allow read receipts to be added to email messages and allow senders to choose if receipts are sent “never,” “on-demand,” or “always.”

Sending: Read receipts are implemented by adding a special “Header” to the headers area of the outbound email message. For example, if somebody@luxsci.net sent an email message and wanted a Read Receipt, the following “Disposition-Notification-To” header would be added:

Disposition-Notification-To: somebody@luxsci.net

Receipt: When the recipient opens the message, the recipient’s email program may see this header and send a special “Delivery Notification” email back to somebody@luxsci.net. When somebody@luxsci.net gets this notification, they know the message has been read.

Read Receipts are Not Reliable

Read receipts are not a reliable way to know if a message has been read. Why?

  • No Support: The recipient’s email program might not support responding to read receipt requests. In this case, receipts would never be sent.
  • Refusal: Even if the email program supports read receipts, the programs generally allow recipients to choose whether to respond. Recipients could choose to respond “never,” “always,” or “decide each time.” The default usually prompts the recipient and allows them to decide yes or no for each receipt.

So, if you use a read receipt to confirm delivery, you will only get a receipt if the recipient wants you to. Sending read receipt requests is unreliable for confirming the read status of a message in general, especially if the recipient denies that the message was even received!

What are Web Bugs?

So, we’ve established that read receipts aren’t 100% reliable because users can choose not to respond to them. Web bugs try to get around this problem by not letting the recipient know you are checking to see if they read the message. To explain how web bugs work, first, we must take a step back to explain how images are transmitted within email.

When an HTML-formatted email message is opened, any referenced external objects, such as images, are downloaded from the internet and displayed. For example, if someone sends you an email message with a link to display a picture that is not attached to the message but hosted elsewhere, your email program will download that image and display it.

Web bugs are contained within image files. To send a web bug, the sender includes some unique tracking code in the link to a picture in the email. When the email is received, the picture is downloaded, and the web server where it was stored records that download, complete with the date, time, tracking code, and the computer’s IP address. By looking at those web server log files, the sender can confirm if you have downloaded the image and, thus, if you have read the message.

Typically, the tracking code is attached to some small, innocuous image. These small tracking images are collectively known as web bugs because they are invisible to the recipient and are meant to secretly transmit data back to the sender, like a phone bug in a spy movie.

Why Web Bugs Are Not Reliable

Unfortunately, spammers often use web bugs to detect active email addresses. As a result, many email providers have taken steps to reduce their impact. That means that web bugs are also not a reliable way to know if a message has been read. Why?

  • No HTML: No images or other objects will be downloaded if the recipient opens the message in an email program with HTML support turned off. For example, LuxSci WebMail shows recipients a plain text preview of their messages. There is no way to track opening the plain text preview of a message using a web bug.
  • Images Off: If the recipient has turned the display of external images off in their email program, the web bugs will never be downloaded. This is an optional feature in some programs like Thunderbird and LuxSci WebMail.
  • Web Bug Extraction: Some email filters will auto-detect images that look like web bugs (i.e., images that look like tracking codes) and automatically remove them by replacing them with transparent images. The web bugs would not be downloaded in this case, but other images would appear as expected. LuxSci’s Premium Email Filtering can do this.

Spammers don’t care that this is not 100% reliable. It is “good enough” to identify many valid recipients and thus allows them to narrow down their lists and send these people more spam.

How to Tell if Someone Read Your Email

So, as we’ve learned, read receipts and web bugs do not always work and cannot be relied on to indicate if a message was read. What options do we have left?

The only way to tell if your email message was read is if you can control the recipient’s ability to access the message. A common way to do this is to:

  • Save the message on a website over which you have control.
  • Send the recipient a notice that a message is waiting for them on that website and provide them with the means to access it.
  • Record when the recipient successfully connects and uses their access credentials to open the message.

By controlling the message location, you can know if and when the message was retrieved. You also know how many times it was accessed and from what IP address(es), and you could remove access to it (i.e., retract it) at any time.

Other email systems may also provide reliable ways of read access tracking. In every case, it depends on if:

  • The system is configured to support it, and
  • Having complete control over the system that the recipient uses to access the message.

If you cannot control your recipient’s email system, consider using a secure web portal system with tracking included, such as LuxSci’s SecureLine Escrow.

Tags: email, escrow, message retraction, privacy, read receipt, secure web portal, secureline, web bug
Posted in LuxSci Library: Security and Privacy, LuxSci Library: The Technical Side of Email
No comments »

How Can I Prove an Email was Sent to Me?

Tuesday, January 16th, 2024

Almost everyone has been in this situation: someone claims to have sent you an email message, but you look in your inbox and don’t see it. As far as you know, you never got it. How can you prove an email was sent?

searching for an email

How to Prove That an Email was Sent

So, where do you start? As the purported recipient of an email message, the easiest way to prove that a message was sent to you is to have a copy of that message. It could be:

  1. In your inbox or another email folder
  2. A copy in your permanent email archives

 Sometimes, missing emails are caused by simple user errors. The obvious place to start the search is in your inbox and email folders. It’s also a good idea to check your email filtering and archival services. It’s possible that your email filtering system accidentally flagged the message as spam or sent it to quarantine. If it’s not there, check your email archival system. That should capture a copy of all sent and received messages. 

Hopefully, that will solve the issue. If it doesn’t, it’s worth stepping back to understand where the email could have gone and where you should turn next to solve the problem.

What happened to the email?

In reality, there are only a few things that could have happened:

  1. The recipient never sent the message.
  2. The recipient did send the message, but it did not reach you.
  3. The message did make it to you, but it was accidentally or inadvertently deleted (or overlooked).

Let’s begin with what you can check and investigate. Start your search soon. The more time that elapses, the less evidence you may have, as logs and backups get deleted over time.

Did the recipient actually send the message?

First, you should know that the sender could have put tracking on the message so that they were informed if you opened or read it (even if you are unaware of the tracking). In such cases, the sender can disprove false claims of “I didn’t get it!” If you are concerned about an email being ignored, use read recipients or tracking pixels to confirm email delivery.  

If you never saw the message, do what we discussed above and start searching your email folders for it. It could have been accidentally moved to the wrong folder or sent to the Trash folder. If you have a folder that keeps copies of all inbound emails (like LuxSci’s “BACKUP” folder), check there too. Check your spam folder and spam-filtering system. Your spam-filtering system may also have logs that you can search for evidence of this message passing through it. Finally, check any custom email filters you may have set up with your email service provider or in your email programs. If you have filters that auto-delete or auto-reject some messages, see if that may have happened to the message in question.

The searches above are straightforward; you can do many of them yourself. Often, they will yield evidence of the missing message or explain why you might not have received it.

Maybe the email was sent but didn’t make it to you?

Email messages leave a trail as they travel from the sender to the recipient. This trail is visible in the “Received” email headers of the message (if you have it) and in the server logs at the sender’s email provider and your email provider. If you know some aspects of the message in question (i.e., the subject, sender, recipient, and date/time sent), you can ask your email service provider to search their logs to see if there is any evidence of such a message arriving in their systems. This will tell you if such a message reached your email provider. However, email providers can typically only search the most recent one to two weeks of logs. So, if the message in question was from a while ago, your email service provider may be unable to help you (or may charge you a lot of money to manually extract and search archived log files if they have them). 

If your email provider has no record of the message or cannot search their logs, you (or the sender) can ask the same question of the sender’s email provider. If they can provide records of such an email being sent through their system, that will prove the email was sent.

The log file analysis provided by the email providers could also explain why you didn’t get the message. Your email address might have been spelled wrong, there could have been a server glitch or issue, etc. However, if the message was sent long ago, the chance of learning anything useful from the email provider is small. Also, if you use a commodity email provider such as AOL, Yahoo, Outlook, Gmail, etc., you may find it impossible to contact a technical support person and have them perform an accurate and helpful log search. Premium providers, like LuxSci, are more likely to support your requests. 

The last thing you can do is have the sender review their sent email folders for a copy of that message. If they have it, that can indicate that they sent it and can reveal why you didn’t get it (i.e., wrong email address, content that would have triggered your filters, etc.). However, be wary. It is easy to forge a message in a sent email folder, so it should not be considered definitive proof that the message was sent. And, even so, just because the message was sent, it does not prove it ever made it to your email provider or inbox.

The recipient never actually sent the email message

If the sending event was recent, then the data from your email service provider can prove that the message did not reach you, but that doesn’t prove that it was not sent. The sender may claim that they do not have a record of sent messages and that their email provider will not do log searching, and that may also be true. At this point, you are stuck without a resolution. 

While email is a reliable delivery system, there are many ways for messages not to make it to the intended recipient. Whether it was not sent or was sent and never arrived, the result is the same- no message for you. As a result, it’s best not to send legal notices or other important documents only by email. Using read receipts and other technologies when sending important messages can help increase confidence that an email was sent and received. Still, there is no foolproof way to guarantee email delivery.

How Do I Prove the Email Sender’s Identity?

A separate but related question is, how can I be sure the sender is who they say they are? Social engineering is rising, and cybercriminals can use technology to impersonate individuals and companies. If you are questioning whether the sender actually sent the message to your inbox (or if it is from a spammer or cybercriminal), it is necessary to perform a forensic analysis of the email headers (particularly the Received lines, DKIM signatures, etc.) and possibly get the sender’s email provider involved to corroborate the evidence. To learn more about how to conduct this analysis, please read: How Spammers and Hackers Can Send Forged Email.

Tags: dkim, email, email security, fraud, lost, missing, sent, tracking
Posted in LuxSci Library: The Technical Side of Email
No comments »

Preventing Email Forgery Part Two: DKIM

Tuesday, December 19th, 2023

In our next post in this series, we look at another way to prevent forged email: DKIM. By using encryption techniques and digital signatures, the sender’s servers can transparently “sign “a message so that you can verify the source and ensure the message has not been modified. DKIM works together with SPF to stop fraud and improve email security.

email alert warning

DKIM – Domain Keys Identified Mail: A Simple Explanation

DKIM stands for “Domain Keys Identified Mail.” Actually, the acronym can be further expanded to “Domain-wide validation Mail Identity through use of cryptographic Keys.” To understand DKIM, we need to pause and look at what we mean by “cryptographic keys” and how they can be used.

Cryptographic Keys

In security, there is a concept called symmetric encryption. Users pick a password and use a cipher to convert a regular (plaintext) message into an encrypted (ciphertext) message. Someone else who knows the password and cipher can reverse the process to get the regular message back in plaintext. 

Another prevalent but more complex concept is asymmetric encryption. Using this method, one can create a key pair or a combination of two keys. A message encrypted using Key One can only be decrypted with Key Two and vice versa. We typically call Key One our “private key” because we keep that safe and secret. Key Two is our “public key” and can be accessed by anyone.

What are the benefits of asymmetric encryption?

  1. Signatures: Anything encrypted using Key One can be decrypted by anyone. If they can decrypt it, that proves that you sent it. Only you have the private key, and thus, only you could have encrypted it in the first place.
  2. Encryption: Anyone can use your public key to encrypt a message that you can only open (using your private key).

How DKIM Works

DKIM uses asymmetric encryption for signing email messages. This validates the sender’s identity and ensures the message contents are not altered in transit. Below is a simple overview of how it works.

Message Sending:

  1. Make a Key Pair: The owners of the sender’s servers create a cryptographic key pair.
  2. Publish the Public Key: They publish the public key in the DNS records for their domain.
  3. Sign Messages: Using the private key, the sender’s servers look at selected message headers (including the sender’s name and address, the subject, and the message ID) and the message body, and they use a cryptographic “hash” function to make a unique fingerprint of this information. Any change to that data would change the fingerprint. This fingerprint hash is also encrypted using the private key. Then, it is added to the message as a new header called “DKIM-Signature.”

Message Receipt:

When you receive a message signed using DKIM, you know the purported sender, their IP address, and the additional DKIM-Signature. However, you cannot trust that the signature header is real or has not been tampered with. Fortunately, you do not have to trust it unquestioningly; DKIM allows you to verify it. Here is what happens on the recipient’s side:

  1. Receipt: The recipient’s inbound email server receives the message.
  2. Get the Signature: The encrypted DKIM fingerprint is detected and extracted from the message headers.
  3. Get the Key: The recipient’s server looks in the sender’s DNS settings to get the public DKIM encryption key.
  4. Decryption: The fingerprint is decrypted using the public key.
  5. Fingerprint Check: The recipient then uses the message body and the same headers as the sender to make another fingerprint. If the fingerprints match, the message has not been altered since it was sent.

As a result, you can verify the sender’s identity because:

  1. We know that the message has not been modified since it was sent. The sender’s name and address (among other things) are the same as when it was sent.
  2. We know the message was sent by a server authorized to send emails for the sender’s domain, as that server used the DKIM private key.

So, through encryption, we have a way to verify that the message was sent by a server authorized to send email from their domain, and thus, we have a solid reason to believe the sender’s identity. Furthermore, this validation does not rely on server IP addresses alone and thus does not share the weaknesses of SPF.

Setting up Domain Keys Identified Mail

It is up to the domain owner to configure their DNS settings for DKIM to be checked by the recipients. You must have access to the domain and the ability to update your DNS records to implement DKIM. 

DKIM is set up by adding unique entries to the published DNS settings for the domain. You can use a tool like this DKIM Generator to create your DKIM cryptographic keys and tell you what you should enter into DNS. Your email provider may have their own tools to assist with this process. The private key must be installed on their mail servers, and DKIM must be enabled. We recommend asking your email provider for assistance.

We will not spend time on the details of the configuration or setup here. Instead, we will look at the actual utility of DKIM, where it fails, and how attackers can get around it.

The Benefits of DKIM

Once DKIM has been set up and is used by your sending mail servers, it does a fantastic job with anti-fraud. It is more robust than SPF. It also helps ensure that messages have not been modified since they were sent. We can be sure who sent the message and what they said, while SPF does not provide any assurance that messages were unaltered.

DKIM is highly recommended for every domain owner and every email filtering system. However, as we shall see next, it’s not time to throw a party celebrating the end of fraudulent emails.

The Limitations of DKIM

While Domain Keys Identified Mail is significantly stronger than SPF on its own, it continues to have limitations in the battle against email fraud.

Identifying Email Sending Servers

To properly use DKIM, all servers that send emails for your domain must have it set up and have keys for your domain. This can be challenging to implement if you use vendors or have partners send emails on your behalf. If DKIM cannot be used, emails should be sent using a different domain or a subdomain so that the primary domain can be fully DKIM-enabled and its DNS can tell everyone that DKIM signatures must be present on all messages. You want to be strict with DKIM usage in a way that is hard to do with SPF.

If you cannot be strict, then DKIM allows you to be soft, which indicates that signatures may or may not be present. In such cases (like with SPF), the absence of a DKIM signature does not make a message invalid. However, if your DKIM setup is soft, it makes forgery simple. 

Inter-Domain Forgery

DKIM checks only the domain name and the server. If there are two different people in the same organization, Fred and Jane, either can send email legitimately from their @domain.com address using the servers they are authorized to use for domain.com email.

However, if Fred@domain.com uses his account to send a message forged from Jane@domain.com, the DKIM will check out as okay, even if DKIM is strict.

DKIM does not protect against inter-domain forgery at all. Note: using separate DKIM selectors and keys for each unique sender would resolve this problem (and the next one), but this is rarely done. 

Same Email Provider: Possible Shared Servers Forgery

If Fred@badguy.com and Jane@goodguy.com were using the same email service provider and servers, Jane’s goodguy.com domain would be set up with DKIM. The email provider’s servers are also set up to sign messages from @goodguy.com with appropriate DKIM signatures. What happens when Fred@badguy.com logs in to his account and sends a message pretending to be from Jane?

 The answer depends on the email provider:

  1. The provider could prevent Fred from sending emails purporting to be from anyone except himself. This would solve the problem immediately, but it is very restrictive, so many providers do not do this.
  2. The provider could associate DKIM keys to specific users or accounts (this is what LuxSci does). Fred’s messages would never be signed by valid the “goodguy.com” DKIM keys, no matter what. This also solves the problem.

However, if the provider’s servers are not restrictive in one of these (or a similar way), Fred’s forged email messages will be DKIM-signed with the goodguy.com signature and appear DKIM-valid.

Legitimate Message Modification

DKIM is very sensitive to message modification. DKIM signature checks will return invalid if even one character has been changed. This is generally good, but email filtering systems may break DKIM. They often read and “re-write” messages in transit where the actual message content is unchanged, but specific (MIME) metadata is replaced with new data. This breaks DKIM, and it can happen more frequently than expected.

Good spam filters check DKIM before modifying messages. Still, if you have multiple filtering systems scanning messages, the DKIM checks of later filters may be broken by the actions of earlier filters. 

DKIM does not protect against Spam

This is not a limitation of DKIM, but it’s worth noting anyway. All DKIM does is help you identify if a message is forged or altered. Most spammers are savvy. They use legitimate domain names and create valid DKIM records to look legitimate.

In truth, this does not make them look less spammy; it just says that the messages are not forged. Of course, if the spammer tries to get by your filters by forging the sender address to pretend that they are you or someone you know, then DKIM can help.

How Attackers Subvert DKIM

So, in the war of escalation where an attacker tries to get a forged email message into your inbox, what tricks do they use to get around sender identity validation by DKIM?

The protections afforded by DKIM are more significant than those provided by SPF. From an attacker’s perspective, it all comes down to what sender’s email address (and domain) they are forging. Can they pick an address to construct an email that will evade DKIM?

  1. If DKIM is not set up, it’s easy to forge the email. 
  2. If DKIM is set up as weak, the attacker can send a forged message with a missing DKIM signature, which will look legitimate.
  3. Suppose the attacker can send a message from one of the servers authorized by the DKIM for the domain. If that server does not care who initiated the message but will sign any messages going through it with the proper DKIM keys, then the message will look legitimate. If the attacker signs up with the same email provider used by the forged domain and that provider’s servers do not restrict DKIM key usage, they can send an email from the same servers and have their messages properly signed. This makes the attacker’s email look valid even if the forged domain’s DKIM records are strict.

 An attacker’s options are much more limited with DKIM. They can only send fraudulent messages from domains with no or weak DKIM support, send through non-restrictive shared email servers, steal the private key used by the sender’s DKIM, or compromise the email account of someone using the same email domain as the address that is to be faked.

The situation is better, but not perfect. Many organizations leave their DKIM configuration weak. They would rather take a chance on forged emails than have legitimate messages be missed due to accidental message modification or because they were sent from a server without DKIM.

We will see in our next post how one can use DMARC to combine the best features of DKIM and SPF to enhance forged email detection further and where the gaps that attackers use remain.

Read next: Preventing Email Forgery Part 3: DMARC

Tags: dkim, DMARC, dns, Domain Keys Identified Mail, email, email forgery, email security, forgery, fraud, spam, spf
Posted in LuxSci Library: The Technical Side of Email
No comments »

Send Secure Emails: Alternatives to Web Portals

Tuesday, December 5th, 2023

Digital technologies have entirely shifted how individuals want to interact with their healthcare providers. As consumers have become used to emailing or texting with their hairstylists, mechanics, and other providers to schedule appointments, they want to have the same level of interaction with their healthcare providers.

However, many healthcare organizations find it challenging to deliver the same experience because of their compliance requirements under HIPAA. They must balance usability and access with security and patient privacy. To send secure emails, they often resort to secure web portals. 

Problems with Secure Web Portals

One of the most common ways that healthcare organizations communicate securely with patients is by using the secure web portal method of email encryption. In this scenario, messages are sent to a secure web server, and a notification is sent to the recipient, who then logs into the portal to retrieve the message.

While highly secure, this method is not popular with recipients because of the friction it creates.

To maintain a high level of security, users must log in to a separate account to retrieve the message. This extra step creates a barrier, especially for individuals who are not tech-savvy. In addition to creating a new account, they must remember a different username and password to access their secure messages. If the recipient doesn’t have this information readily available, they will likely delete the message and move on with their day. Many users will never bother logging in because of the inconvenience. This creates issues for organizations that want to use email for standard business communications and patient engagement efforts. 

While this method may be appropriate for sending highly sensitive information like medical records, financial documents, and other valuable information, many emails that must meet compliance requirements only infer sensitive information and do not require such a high level of security. Flu shot reminder emails are not as sensitive or potentially devastating as sending the wrong medical file to someone. Healthcare organizations need to use secure email solutions that are flexible enough to send only the most sensitive emails to the portal and less sensitive emails using other methods.

How to Meet Compliance Requirements for Sending Secure Email

So, what other options do you have for sending secure emails? The answer will depend on what specific requirements you need to meet. Healthcare organizations that must abide by HIPAA regulations will find a lot of flexibility regarding the technologies they can use to protect ePHI in transit.

In addition to a secure web portal, three other types of encryption are suitable for email sending: TLS, PGP, and S/MIME. PGP and S/MIME are more secure than a web portal. They also require advanced technological skills and coordination with the end-user to implement, which makes them impractical for most business email sending.

That leaves us with TLS, which is suitable to meet most compliance standards (including HIPAA) and delivers an email experience much like that of a “regular” email.

Send Secure Emails with TLS Encryption

TLS encryption is an excellent option for secure email sending that provides a seamless experience for the recipient. Emails sent securely with TLS appear like regular, unencrypted emails in the recipient’s inbox.

TLS encrypts the message contents as they travel between mail servers to prevent interception and eavesdropping. Once the message reaches the inbox, it is unencrypted and can be read by anyone with access to the email account. For this reason, it is less secure than a portal but secure enough to meet compliance requirements like HIPAA.

If you’re wondering why this is, HIPAA only requires covered entities and business associates to protect PHI when it is stored on their systems or as it is transmitted elsewhere. After the message reaches the recipient, it is up to the recipient to decide what they want to do to secure the information. HIPAA does not apply to individuals. Each person is entitled to share and store their health information however they see fit.

Conclusion

Balancing security and usability is a significant challenge for healthcare organizations. If the message is too secure, it may be difficult for the recipient to open and engage with it. If it’s not secure enough, it is too easy for cybercriminals and other bad actors to intercept private information as it is sent across the internet. 

Choosing an email provider like LuxSci, which offers flexible email encryption options, allows users to choose the right level of encryption for each message to maximize engagement and improve health outcomes. Contact our team today to learn more about how we can support your efforts.

Tags: digital transformation, email, email encryption, email security, patient engagement, patient experience, secure web portal, tls, tls encryption
Posted in Email
Comments Off on Send Secure Emails: Alternatives to Web Portals

What is the Difference Between Asynchronous and Synchronous Communications?

Tuesday, June 7th, 2022

Synchronous and asynchronous are terms used to describe when and how individuals communicate. The critical difference between asynchronous and synchronous communication is that synchronous communications are scheduled, real-time interactions. Asynchronous communications happen independently and don’t need scheduling.

This article explores the differences between each and how they can be utilized in a healthcare context.

asynchronous and synchronous communications

Synchronous Communications

Synchronous communications happen in real-time between two or more people. Examples of synchronous communications include in-person meetings, videoconferencing, phone calls, or other types of interactions where an immediate response is expected.

In a health care context, this face-to-face time is precious and can be hard to schedule. Unless seeking acute care at an emergency department or urgent care facility, it is not easy to have same-day synchronous communications with a care provider. Telehealth live video appointments are also considered synchronous.

Asynchronous Communications

Alternatively, asynchronous communications are interactions without real-time conversation. The replies to asynchronous messages are delayed and happen on the participants’ schedules. Email, texting, patient portal messaging, video libraries, or other online wikis are considered asynchronous communications.

Asynchronous communications are becoming more popular among patients and healthcare providers. The advent of patient portals with secure messaging capabilities allows for non-urgent communications to be sent securely and answered on time.

Which is better for healthcare communications?

It depends on the context. Synchronous communications are always better for urgent scenarios. If a sick child exhibits flu-like symptoms, it makes sense to use synchronous communication channels to contact their pediatrician.

However, asynchronous communications are an excellent option for most administrative healthcare interactions. Questions about billing, appointment scheduling, referrals, prescription refills, etc., are not urgent and most often do not require a face-to-face interaction.

Some non-urgent medical questions can also be addressed through asynchronous communications. For example, if a patient has a rash or insect bite, they can upload an image of the rash to a patient portal where a clinician can diagnose and recommend a treatment remotely. Of course, the question may not be answered immediately, but it could be a good option for diagnosing and treating minor skin conditions and irritations.

Improving the Patient and Clinician Experience

In fact, cutting down the number of synchronous communications can help improve both the clinician and patient experience. On the clinician’s side, constant interruptions by phone calls or live video chats can be detrimental to productivity and increase stress. By encouraging asynchronous communications for non-critical issues, clinicians can block off time to respond to messages. They can also take time to deliver thorough responses instead of rushing or being unprepared for conversations.

From the patient’s perspective, asynchronous communication can often offer a better experience. Almost everyone has called their doctor’s office and been put on hold for extended periods. It is frustrating, can take a lot of time out of a workday, and often doesn’t deliver an adequate response. Instead, patients can send a message and be confident that it will be addressed by the right staff member promptly. Asynchronous communications also tend to be more transparent. Patients can reference messages later because they are logged in chat portals or email chains.

Conclusion

Organizations should look at ways to incorporate more asynchronous communications into their workflows. Relieving the administrative burden on staff and freeing up phone lines helps improve employee satisfaction and allows them to focus on what matters- providing a high quality of patient care.

Tags: clinician experience, email, healthcare communications, patient experience, patient portal, telehealth, texting, videoconferencing
Posted in Email Marketing, Telehealth
Comments Off on What is the Difference Between Asynchronous and Synchronous Communications?

« Older Entries