Track Doctor & Patient Presence for Efficient Online Consultations

How Does the Demo Work?

The application uses the PubNub Core JavaScript SDK, and the full source code of the demo is available on Github.

Ignoring the connective tissue of the app, the key portions that relate to PubNub Presence are as follows:

When you set yourself as available or busy, the setState API is used:

When the application first loads, it will also use the hereNow API to determine which users are already connected to the channel.

If you would like to understand PubNub's Presence feature in more detail, our docs are a great place to start. To avoid straying off-topic, the rest of this blog will look at how you can use PubNub Presence to enhance online healthcare consultations.

Demo Data Security

The demo is designed to show the high-level principles of PubNub Presence, and is not designed to show security best practices. Especially with patient healthcare data, you would likely implement much of the business logic on your server, and ensure users only have visibility to the data they need using access control.

Virtual Patient Consultations

Let’s consider two architectures for virtual consultations:

The first is an appointment-based system where prospective patients will set up scheduled appointments with doctors ahead of time, and meet with the doctor for a set period of time.

The second allows for on-demand, or instant, consultations, where patients needing treatment can join a virtual queue, get assessed and prioritized, and then move on to specialist treatment with a doctor who is assigned based on their skillset and availability.

Appointment-Based Remote Consultations

The most common type of virtual appointment is scheduled in advance and involves the patient and doctor joining a virtual ‘meeting room’ at the specified time.

When scheduling the appointment, the patient will have pre-registered with the healthcare provider and provided some details about their condition before selecting an appointment time. This is not included in the above diagram.

Step 1: At the pre-appointed time, the patient will join a lobby specific to that doctor. So, if there are two doctors, there will be two lobbies, lobby.doctor1 and lobby.doctor2. A join event is generated when the patient arrives, allowing the doctor to see how many patients are waiting at any time.

The doctor can maintain their presence state either manually or automatically, allowing patients to see whether their doctor is currently ‘busy’, ‘unavailable’, or that the consultation will start soon.

Data security is paramount, and channels should be restricted using PubNub’s Access Manager, to ensure data is only available to those who need it. For example, the lobby.doctor1 should not be visible to any doctor other than doctor1. How to achieve this will be shown later in this blog.

PubNub allows you to send secure messages between the doctor and patient, so even before the consultation begins, messages could be exchanged on the lobby.<doctor>.<patientId> channel, which is specific and private for each patient. You might even have a workflow, triggered by a patient joining a lobby, where some heuristic process determines that the doctor is running late and can send automated messages to the patient keeping them updated on expected wait times.

Step 2: When the doctor starts the consultation, the patient leaves the lobby.<doctor> channel and joins the consultation.<doctor>.<patient> channel. Leaving lobby.<doctor> will generate a leave event and automatically update all interested parties that the queue length has reduced; the doctor will also set their presence state to indicate they are in a consultation which will notify anyone who has registered for updates.

The consultation channel, consultation.<doctor>.<patient>, is unique and private to that doctor & patient; data exchanged over this channel can be backed up or retained as needed.

On-Demand (Instant) Remote Consultations

Although not as common as scheduled appointments, some healthcare organizations offer on-demand virtual consultations, where a patient can log in and wait to see an available doctor or specialist.

The following diagram captures the workflow of a patient requesting an on-demand consultation. It presupposes that the patient has registered with the provider and provided details about their symptoms. Data that needs to be persistent, such as medical information and a record of the consultation itself, is not shown on this diagram, which focuses on the transitory data associated with the patients’ and doctors’ presence.

Since there is no single workflow for on-demand virtual healthcare, I have shown a representative case study

Step 1: A patent enters the workflow after requesting a virtual consultation. The patient is first placed into an initial triage queue, lobby.triage, where they provide additional information about their symptoms. This triage might be automated, or handled by a human, but the outcome will be a categorization of the patient along with some assessment of the urgency of their case.

Joining lobby.triage will generate a join event, giving you real-time visibility into how many people are currently being triaged, and eventually determining the time between a patient entering triage and that same patient entering a consultation.

Step 2: After triage, the patient is assigned to a specialist queue, which generates a leave event for the lobby.triage channel and a join event for the lobby.<specialist> channel. At this point, interested parties can see how many patients are waiting to be seen by a doctor, and how much demand there is for each specialist in real-time. Patients can be updated on how many people are in front of them in their queue, and doctors can use this information to prioritize who they will speak with next, for example, patients in the ‘urgent’ queue will take priority over those in the ‘general’ queue.

After triage, the queue categorizations will vary from healthcare provider to healthcare provider, and can even vary based on which doctors are available and their skillsets. I have chosen to categorize pediatric, general, and urgent in the above diagram as this is most typical, but you could also break general down further into cardiology, orthopedics, etc., for example.

Step 3: The patient will join the consultation with the doctor, generating a leave event for the channel they were waiting in and allowing the system to calculate the time between triage and seeing a doctor. The doctors also generate a join event as they start the consultation, giving a real-time overview of how many doctors are in active consultations and how many are waiting to see patients.

Keeping Patient Data Secure

It is critically important to keep all healthcare patient data secure, not just for legal and regulatory compliance but also to protect the privacy of patients and healthcare professionals. Electronic Health Records (EHR) can be highly sensitive and personal, including medical histories, diagnoses, treatments, and more.

PubNub enables you to easily build HIPAA compliant real-time solutions, but what does HIPAA compliance mean? HIPAA stands for the Health Insurance Portability and Accountability Act, which aims to protect patients’ protected health information (PHI). If any of the 18 protected identifiers appear in a message, that message is considered to contain PHI and can only be exchanged with end-to-end encryption, using a solution that supports access controls and auditing.

What about outside of the USA? At PubNub, we often discuss HIPAA Compliance because it resonates strongly with our customer base and is understood by customers worldwide. Globally, PubNub is compliant with a number of industry regulations such as ISO 27001, SOC2, and GDPR, so you can have confidence developing a healthcare solution with PubNub regardless of your worldwide footprint.

Access Control Example

Recall previously, when speaking about Appointment-Based Remote Consultations, I said the following:

Data security is paramount, and channels should be restricted using PubNub’s Access Manager, to ensure data is only available to those who need it. For example, the lobby.doctor1 should not be visible to any doctor other than doctor1.

You would implement this as follows:

Prerequisite: Access Manager is enabled on your PubNub keyset

Step 1: When the doctor application initializes, the doctor logs in and authenticates themself using your existing auth flow. As part of authentication, your application should also make a grant request to PubNub. This is steps 1 and 2 in the oft-reused diagram taken from our documentation on auth flow

The grant request on your server would look something like this in Node (though we do support other languages). See the grantToken documentation for more detail on what each field means:

Step 2: The token returned in the previous call should be returned to the client, who should, in turn, call setToken on their client SDK. This is covered by steps 3, 4, and 5 in the above diagram. Again, although the links and examples are given in JavaScript, PubNub has SDKs to support all popular client languages.

Step 3: Whenever the existing rule’s TTL expires, or new access rules are needed, repeat steps 1 and 2. For example, if a new patient joins the waiting room, you might want to set a new rule to allow the doctor to chat with this new patient

Tracking Patient Metrics

This blog has focused heavily on taking action in real time to improve the patient experience and keep all parties updated as patients move through the system.

I will not go into detail about the following use cases, but if you are tracking user presence anyway, be aware that it would be trivial to implement some additional features:

Admin Dashboards:

An administrator user who has access to all channel presence events could be given an overview of the current solution state, including how many patients are waiting for each doctor, how each doctor is performing, and historical trends. This could allow the administrator to make resourcing decisions (if a doctor suddenly becomes unavailable) or perhaps move patients between doctors if queues get too long, improving patient care and the overall patient experience.

Analytics:

PubNub Events & Actions (E&A) allows you to send the real-time data generated by your system to third parties for storage or analytics. For example, you can send data to Amazon SQS, Amazon Kinesis, Amazon S3, or Apache Kafka.

E&A can ingest Presence events, meaning you can easily set up a rule to export all join, leave, and state-change events for later analysis or storage in a third-party system. This provides historical analytics and trend data without having to write any code.

Get Started

If you haven’t already, check out our digital health landing page, which discusses implementing a healthcare solution with PubNub more generally and highlights some customer testimonials.

If you would like to take the first step towards adding to those customer testimonials or just learn more, you can get in touch with us or start development with a free account.

Finally... although patient health remains the primary focus for medical practices as they transition from face-to-face, in-person care to telehealth consultations, no primary care provider can ignore the impact of social media and online reputation for their organization. Especially where medical services are subject to competition or services are provided to a younger demographic, you must also consider online patient engagement, including search engine ranking, SEO, and your presence on social media platforms. Optimizing your appointment scheduling will lead to an improved patient relationship and better patient reviews and provide you with a positive and strong online presence.