Proximity-based patient check-in computing system

An improved patient check-in system for healthcare appointments is disclosed herein. Prior to a datetime of a healthcare appointment of a patient, an electronic health records application (EHR) receives a first message originating from a patient computing device of the patient. The first message includes a location of the patient and patient information for the patient. Responsive to receiving the first message, the EHR stores the patient information in a cache. The EHR also places a placeholder for the patient in a queue that indicates an order in which healthcare appointments for patients at the healthcare facility are to occur. Subsequently, the EHR receives a second message generated by the patient computing device indicating that the patient has arrived at the healthcare facility for the healthcare appointment. The EHR transfers the patient information from the cache to a data store accessible to the EHR.

BACKGROUND

Electronic health records applications (EHRs) are computer-executable applications that are configured to assist healthcare workers with providing care to patients. EHRs are configured with functionality pertaining to patient intake, patient billing, insurance billing, prescription generation, maintaining a record of patient care over time, etc. EHRs are often used by healthcare workers at the point of care (i.e., at a time when the healthcare worker is providing care to a patient). For example, a healthcare worker may retrieve data from a patient record maintained by an EHR to relatively quickly ascertain problems being experienced by the patient, medications currently being taken by the patient, and so forth.

Some EHRs are configured with patient check-in functionality which enables a patient to be checked-in for a healthcare appointment at a healthcare facility. Conventionally, when the patient arrives at the healthcare facility for the healthcare appointment, he or she will relay his or her patient information that is to be used during the healthcare appointment to a healthcare worker. For instance, the patient information may include a name of the patient, an address of the patient, a sex of the patient, a list of any allergies the patient may have, a list of active (i.e., current) medications that the patient is taking, and/or insurance information of the patient. The EHR will then receive the patient information as input from the healthcare worker and the EHR will store the patient information in a data store along with an indication that the patient has checked-in for the healthcare appointment. Another healthcare worker (e.g., a physician) may then conduct the healthcare appointment with the patient. In an example, after the healthcare appointment is conducted, the EHR may use the patient information to generate an electronic prescription.

Conventional patient check-in systems provided by EHRs have various deficiencies. First, patients often are late to scheduled healthcare appointments and/or reschedule healthcare appointments. This necessitates updating patient data maintained by the EHR. However, data maintained by EHRs is often stored in highly normalized forms. As such, updating the patient data involves updating many different tables storing the patient information, which is undesirable, especially when a healthcare appointment is changed multiple times. Second, conventional patient check-in systems are not configured to automatically reschedule appointments based upon patient distance to a healthcare facility. Third, conventional patient check-in systems do not provide the patient with the ability to visually check the status of other appointments on a computing device operated by the patient.

SUMMARY

Disclosed herein are various technologies pertaining to patient check-in functionality of an electronic health records application (EHR). The EHR is a distributed application that includes both server-side functionality (server EHR) and client-side functionality (client EHR). The EHR facilitates more efficient check-in of patients for healthcare appointments at a healthcare facility. The EHR also facilitates dynamically rescheduling of appointments based in part upon patient proximity to the healthcare facility.

In operation, the server EHR schedules a healthcare appointment for a patient at a healthcare facility for a datetime (e.g., a date and a time on the date). In an embodiment, a medication is to be prescribed to the patient during the healthcare appointment. Prior to the datetime of the healthcare appointment, it is contemplated that the patient begins transit to the healthcare facility. As such, a patient computing device operated by the patient may generate and cause a first message to be received by the server EHR. The first message indicates that the patient has begun transit to the healthcare facility. The first message comprises a location of the patient (as ascertained by a geolocation component of the patient computing device) as well as patient information for the patient. The patient information for the patient may include an identifier for the patient (e.g., a name of the patient, a medical record number (MRN), etc.), an age of the patient, an address of the patient, insurance information of the patient, a list of allergies of the patient, and/or a list of (active) medications of the patient.

In a first embodiment, the patient computing device receives the patient information as manual input from the patient. In the first embodiment, the patient computing device may store the patient information in a data store of the patient computing device for future use.

In a second embodiment, the first message initially fails to include at least some of the patient information. For instance, the first message may include an identifier for the patient, but may fail to include the list of allergies of the patient, the list of active medications of the patient, etc. The patient computing device (by way of a client patient portal application) transmits the first message (including the identifier for the patient) to a server patient portal application. The patient portal application retrieves the patient information for the patient based upon the identifier for the patient and causes the patient information to be included in the first message. The server patient portal application then routes the first message to the server EHR.

Responsive to receiving the first message, the server EHR stores the patient information for the patient in a cache accessible to the server EHR. In an embodiment, the patient information may be stored in denormalized form.

The server EHR also places a placeholder for the patient in a computer-implemented queue for healthcare appointments at the healthcare facility. The queue comprises placeholders for healthcare appointments at the healthcare facility. An ordering of the placeholders in the queue is indicative of an order in which the healthcare appointments are to occur at the healthcare facility. A position of the placeholder in the queue is based upon the datetime for the healthcare appointment and a distance between the location of the patient and a location of the healthcare facility.

As the patient travels to the healthcare facility, the patient computing device may cause the server EHR to receive a current location of the patient computing device (and hence the patient) at certain time intervals. In an example, the server EHR may determine that based upon the datetime for the appointment and the current location of the patient, the patient will fail to arrive on time for the healthcare appointment. The server EHR may be configured to reschedule the healthcare appointment for the patient responsive to the determination. In another example, the server EHR may determine that a second patient having a second healthcare appointment at a second datetime that is to occur immediately prior to the healthcare appointment will fail to arrive at the second datetime. In the event the server EHR determines that that the patient will arrive at the healthcare facility prior to or at the second datetime, the server EHR may be configured to reschedule the healthcare appointment and the second healthcare appointment such that the healthcare appointment occurs at the second datetime instead of the datetime.

When the patient arrives (or is about to arrive) at the healthcare facility, the patient computing device may generate a second message and cause the second message to be received by the server EHR. The second message indicates that the patient has arrived (or is about to arrive) at the healthcare facility.

Responsive to receiving the second message, the server EHR may transfer the patient information for the patient from the cache to a data store accessible to the server EHR such that the patient information is stored in the data store. In an embodiment, the patient information in the data store may be stored in a highly normalized form. The server EHR may also remove the placeholder for the patient from the queue. The healthcare worker may then conduct the healthcare appointment with the patient. In an embodiment, an electronic prescription may be generated from the patient information now retained in the data store. Subsequently, the server EHR may purge the patient information from the cache.

The above-described technologies present various advantages over conventional patient check-in systems. First, through use of a cache that temporarily stores patient information of a patient, the above-described technologies reduce the number of times the data store of the server EHR is accessed, thus saving computing resources, especially when a healthcare appointment is rescheduled multiple times. Second, above-described technologies enable automatic rescheduling of healthcare appointments based in part upon patient proximity to a healthcare facility. Third, the above-described technologies provide a patient with the ability to visually check the status of other appointments on a computing device.

DETAILED DESCRIPTION

With reference toFIG. 1, an exemplary computing system100that facilitates patient check-in for healthcare appointments is illustrated. The computing system100includes a server computing device102. The server computing device102comprises a processor104and memory106, wherein the memory106has a server electronic health records application (server EHR)108loaded therein. In general, the server EHR108(when executed by the processor104) is configured to perform a variety of tasks related to patient healthcare in a healthcare facility (e.g., patient intake, prescription generation, patient record creation and maintenance, etc.).

The server EHR108may include an electronic prescription module110. The electronic prescription module110is configured to generate electronic prescriptions for patients. The electronic prescription module110may also be configured to cause the electronic prescription to be transmitted to an electronic device (e.g., a computing device) of a pharmacy that is to fill the electronic prescription.

The memory106may also include a cache112. As will be described in greater detail below, the cache112is configured to temporarily store patient information for patients. In an embodiment, the cache112may store patient information for patients in a highly denormalized form. Although the cache112is depicted as being stored in the memory106, other possibilities are contemplated. For instance, in an embodiment, the cache112may be stored in other memory (i.e., high-performance memory) or one or more solid state drives (SSDs).

The server computing device102may additionally comprise a data store114. The data store114may comprise clinical data116for patients, as well as appointment data118for patients. The clinical data116can include electronic health records, prescription records, claims data, patient/disease registries data, health surveys data, and/or clinical trials data. The appointment data118includes datetimes for healthcare appointments of patients that are to occur at a healthcare facility. The appointment data118may also include identifiers for patients, identifiers for healthcare workers that are to conduct the healthcare appointments, etc. The clinical data116may be stored in a normalized form. For instance, some or all of the clinical data116may be stored in third normal form (3NF), elementary key normal form (EKNF), Boyce-Codd normal form (BCNF), fourth normal form (4NF), essential tuple normal form (ETNF), fifth normal form (5NF), domain-key normal form (DKNF), or sixth normal form (6NF). Although the clinical data116and the appointment data118are depicted as being retained in the data store114, it is to be understood that the clinical data116and the appointment data118may be retained in separate data stores. In an embodiment, the appointment data118may be stored as part of the clinical data116. Furthermore, it is to be understood that certain portions of the clinical data116may be retained in separate data stores.

The computing system100may include a client computing device122operated by a healthcare worker140. In an example, the client computing device122may be a tablet computing device. The client computing device122may be in communication with the server computing device102by way of a network120(e.g., the Internet, intranet, etc.). The client computing device122comprises a processor124and memory126, wherein the memory126has a client electronic health records application (client EHR)128loaded therein. In general, the client EHR128(when executed by the processor124) is configured to interface with the server EHR108executing on the server computing device102, thereby providing the healthcare worker140with access to functionality of the server EHR108.

The client computing device122may include a data store130comprising clinical data132about patients. It is understood that there may be overlap between the clinical data132stored in the data store130and the clinical data116stored in the data store114.

The client computing device122may include a display134, whereupon graphical features136may be presented thereon. For instance, a graphical user interface (GUI) may be presented as part of the graphical features136. The client computing device122may additionally include input components138suitable for data input. For instance, the input components138may include a mouse, a keyboard, a touchscreen, a trackpad, a scroll wheel, a microphone, a camera, a video camera, etc.

In an embodiment, the computing system100may include a second server computing device142. The second server computing device142comprises a processor (not shown) and memory (not shown), wherein the memory includes an electronic health records agent application (EHR agent) loaded therein. In general, the EHR agent (when executed by the processor) is configured to retrieve and maintain clinical information for patients from sources inaccessible to the server EHR108. For instance, the EHR agent may retrieve and maintain clinical information for patients from other EHRs, health information exchanges (HIEs), third-party applications, etc. The EHR agent may maintain such information in a data store (not shown) accessible to the EHR agent.

The computing system100may include a third server computing device144. The third server computing device144comprises a processor (not shown) and memory (not shown), wherein the memory has a server patient portal application loaded therein. In general, the server patient portal application (when executed by the processor) is configured to allow a patient to access his or her health data, including prescriptions medications, health records, communications with healthcare providers, insurance information, input self-reported patient health data, schedule healthcare appointments, etc. As such, the server patient portal application may maintain a subset of the clinical data for patients in a data store (not shown) accessible to the server patient portal application. Thus, the server EHR108may be configured to provide the server patient portal application with the clinical data, wherein an administrator (not shown) of the server EHR108can set forth polices as to what data is included in the clinical data of the server patient portal application. In addition, the server patient portal application can maintain data provided directly by patients to the server patient portal application.

The computing system100additionally includes a patient computing device146of a patient148. The patient computing device146may be a mobile computing device, such as a tablet computing device, a smartphone, or a wearable computing device (e.g., a smartwatch). In an embodiment, the patient computing device146may be integrated into a vehicle of the patient148. The patient computing device146is in communication with the server computing device102and/or the third server computing device144by way of the network120(or another network).

Referring now toFIG. 2, the patient computing device146comprises a processor200and memory202. The memory202may include a client patient portal application204. In general, the client patient portal application204(when executed by the processor200) is configured to communicate with the server patient portal application in order to interface with the server patient portal application to allow the patient148to access his or her health data maintained by the server patient portal application.

The patient computing device146may include a data store206that retains patient data208for the patient148. The patient data208may be a subset of the clinical data for the patient. For example, the patient data208may include the patient information for the patient148discussed above (e.g., the identifier for the patient148, the list of allergies of the patient148, etc.).

The patient computing device146may include a display210, whereupon graphical features212may be presented thereon. For instance, a graphical user interface (GUI) may be presented as part of the graphical features212. The patient computing device146may additionally include input components214suitable for data input. For instance, the input components may include a mouse, a keyboard, a touchscreen, a trackpad, a scroll wheel, a microphone, a camera, a video camera, etc.

The patient computing device146may include a geolocation receiver216that is configured to ascertain a current location of the patient computing device146(that is reflective of a current location of the patient148). For example, the geolocation receiver216may be a global positioning system (GPS) receiver that is configured to ascertain a current location (GPS coordinates) of the patient computing device146via communication with space-based radio-navigation satellites.

With reference generally now toFIGS. 1 and 2, operation of the computing system100is now set forth. It is contemplated that the patient148requires a healthcare appointment at a healthcare facility. As such, the server EHR108schedules a healthcare appointment for the patient148at the healthcare facility for a datetime (i.e., a date and a time). In an example, a medication is to be prescribed to the patient148during the healthcare appointment.

Prior to the datetime, the patient148may begin transit to the healthcare facility for the healthcare appointment and the patient computing device146causes a first message to be received by the server EHR108. For instance, the patient computing device146may receive input from the patient148causing the patient computing device146to generate and transmit the first message. In an embodiment, the patient computing device146may be configured to determine that the patient148has begun transit and may be configured to automatically generate and transmit the first message.

The first message indicates that the patient148has begun transit to the healthcare facility for the healthcare appointment. The first message may comprise a (current) location of the patient148(e.g., a set of global positioning system (GPS) coordinates) and patient information for the patient148. In an embodiment, the patient computing device146may ascertain the location of the patient148by way of the geolocation receiver216. In another embodiment, the patient computing device146may receive input from the patient148indicative of the location of the patient148(e.g., an address). The patient computing device146may transmit the location to an Internet-based mapping service which may determine the location of the patient148based on the address. The Internet-based mapping system may then transmit the location of the patient148to the patient computing device146, which may forward the location to the server EHR108. The patient computing device146may also transmit the address to the server EHR108which may communicate with the Internet-based mapping service in order to determine the location of the patient148.

The patient information for the patient148may include an identifier for the patient148(e.g., a name, a medical record number (MRN), etc.), an age of the patient148, an address of the patient148, insurance information of the patient148, a list of allergies of the patient148, and/or a list of (active) medications of the patient148.

In an embodiment, the patient computing device146may receive the patient information as manual input from the patient148. The patient computing device146may store the patient information in the data store206of the patient computing device146for future use. Thus, for future healthcare appointment, the patient computing device146need not receive the patient information as manual input from the patient148.

In another embodiment, the first message includes an identifier for the patient148, but fails to include at least a portion of the patient information for the patient148. As such, the patient computing device146may receive input from the patient148causing the client patient portal application204to transmit the identifier for the patient148to the server patient portal application. Responsive to receiving the identifier for the patient148, the server patient portal application may execute a search over a data store retaining patient information for a plurality of patients. The search is based on the identifier for the patient148. The search produces search results, wherein the search results include the at least a portion of the patient information for the patient148. The server patient portal application then causes the at least a portion of the patient information for the patient148to be included in the first message. The server patient portal application then routes the first message to the server EHR108.

The server EHR108may then receive the first message. Responsive to receiving the first message, the server EHR108may cause the patient information for the patient148to be stored in the cache112. In an embodiment, the patient information for the patient148may be stored in denormalized form so as to facilitate fast read read-times for the patient information. In an embodiment, the server EHR108may utilize stored procedures in order to facilitate storing the patient information in tables stored in the cache112.

It is understood that the clinical data for the patient148retained in the data store114of the server computing device102may not represent the complete patient record for the patient148. For instance, the clinical data for the patient148retained in the data store114may not include all of the active medications of the patient148and/or all of the allergies of the patient148. Thus, in an embodiment, subsequent to receiving the first message, the server EHR108may transmit an identifier for the patient148to the EHR agent executing on the second server computing device142. The EHR agent may then retrieve additional patient information (e.g., active medications of the patient148, allergies of the patient148, etc.) for the patient148. For instance, the EHR agent may execute a search over a data store (not shown) accessible to the EHR agent that comprises clinical data for patients gathered from different sources (e.g., different EHR systems, HIEs, third-party applications, etc.) that are inaccessible to the server EHR108. The search may be based upon the identifier for the patient148. The search produces search results, wherein the search results include the additional patient information for the patient148. The EHR agent may then transmit the additional patient information to the server EHR108which may cause the additional information for the patient148to become part of the patient information for the patient148. The server EHR108may then store the patient information in the cache112as described above. Alternatively, the server patient portal application may perform the aforementioned steps in place of the server EHR108in order to retrieve the additional patient information for the patient148.

Additionally, the server EHR108also places a placeholder for the patient148in a computer-implemented queue for healthcare appointments at the healthcare facility. The queue comprises placeholders for healthcare appointments at the healthcare facility. An ordering of the placeholders in the queue is indicative of an order in which the healthcare appointments are scheduled to occur at the healthcare facility. A position of the placeholder in the queue is based upon the datetime for the healthcare appointment and a distance between the location of the patient148and a location of the healthcare facility.

The server EHR108may be configured to dynamically rearrange the queue for the healthcare appointments if the patient148(or another patient) will fail to arrive at the healthcare facility for the datetime of the healthcare appointment (or another healthcare appointment). In an example, the queue comprises a second placeholder for a second patient that has a second healthcare appointment at the healthcare facility at a second datetime. The second datetime may occur immediately after the datetime and as such the second placeholder is placed immediately after the placeholder within the queue. In the example, the server EHR108receives a current location of the patient148from the patient computing device146at predefined intervals (e.g., every minute). The server EHR108may also receive a current location of the second patient from a second patient computing device operated by the second patient. The server EHR108may determine that the patient148will fail to arrive at the healthcare facility at the datetime based on the current location of the patient148and a current datetime. The determination may also be made based upon traffic data for areas surrounding the current location of the patient148and/or the healthcare facility received from an Internet-based mapping service. The server EHR108may also determine that the second patient will arrive at the healthcare facility prior to or at the datetime based on the current location of the second patient. The determination may also be made upon traffic data for areas surrounding the current location of the patient148received from the Internet-based mapping service. Responsive to determining that the patient148will fail to arrive at the healthcare facility at the datetime for the healthcare appointment, the server EHR108may reposition the placeholder for the patient148in the queue such that the placeholder is placed immediately after the second placeholder in the queue, thereby indicating that the healthcare appointment datetimes have been switched. The server EHR108may also cause a notification to be transmitted to the patient computing device146(e.g., by way of the server patient portal application) indicating that the healthcare appointment for the patient148has been rescheduled to a different datetime due to the determination that the patient148will fail to arrive at the healthcare facility at the datetime.

In another example, the second healthcare appointment for the second patient is scheduled for a second datetime at the healthcare facility that occurs immediately before the datetime of the healthcare appointment. As such, the second placeholder for the second patient in the queue is placed immediately before the placeholder for the first patient in the queue. In the example, the server EHR108may determine that the second patient will fail to arrive at the healthcare facility at the second datetime. The server EHR108may also receive a current location of the patient148. The server EHR108may determine that the patient148will arrive at the healthcare facility prior to or at the second datetime based in part upon the second location (as well as potentially traffic data received from an Internet-based mapping service). Responsive to determining that the second patient will fail to arrive at the healthcare facility, the server EHR108repositions the placeholder for the patient148within the queue such that the placeholder is placed immediately before the second placeholder in the queue.

The server EHR108may also cause a notification to be received by the patient computing device146(e.g., by way of the server patient portal application). The notification may indicate that the second datetime is now available for the healthcare appointment of the patient148due to a cancellation (or reschedule). The notification may include the option to allow the patient148to reschedule the healthcare appointment for the second datetime. If the patient148wishes to take the (earlier) second datetime, the patient computing device146may receive input from the patient indicating that the patient148agrees to the second datetime for the healthcare appointment, and the patient computing device146may transmit data causing the server EHR108to schedule the healthcare appointment for the (now free) second datetime.

In an embodiment, the server EHR108may be configured to transmit data that causes a visual representation of the queue to be presented on the display210of the patient computing device146and/or the display134of the client computing device122(described below).

When the patient148arrives at the healthcare facility, the patient computing device146may cause a second message to be received by the server EHR108. The second message indicates that the patient148has arrived at (or is about to arrive at) the healthcare facility for the healthcare appointment. The second message may include the identifier for the patient. In an embodiment, the patient computing device146may determine a current location of the patient148by way of the geolocation receiver216. The patient computing device146may also determine a location of the healthcare facility. When the current location of the patient148is within a certain threshold distance of the location of the healthcare facility, the patient computing device146can cause the second message to be generated. In another embodiment, when the patient148arrives at the healthcare facility, the patient computing device146may receive input from the patient148causing the patient computing device146to generate the second message.

In an embodiment, the client patient portal application204executing on the patient computing device146may transmit the second message to the server patient portal application. The server patient portal application may then transmit the second message to the server EHR108. In another embodiment, the patient computing device146may directly transmit the second message to the server EHR108.

Responsive to receiving the second message, the server EHR108may transfer the patient information for the patient148from the cache112to the data store114. The server EHR108may cause the patient information for the patient148from the cache112to be stored as part of the clinical data for the patient148. In an embodiment, the patient information may be stored in a normalized form (e.g., 3NF, 4NF, etc.) in the data store114. The server EHR108may also transmit the patient information for the patient148to the client EHR128, whereupon the client EHR128may present the patient information for the patient148on the display134. In an embodiment, the electronic prescription module110may then utilize the patient information for the patient148in the data store114to generate an electronic prescription for the patient148. Subsequently, the server EHR108may purge the patient information from the cache112. The server EHR108may also remove the placeholder for the patient148from the queue after the healthcare appointment for the patient148has concluded.

Although the above-described processes have been primarily described as being performed by the server EHR108, other possibilities are contemplated. For instance, some or all of the above-described processes may be performed by a standalone application executing on a different server computing device than the server computing device102.

Turning now toFIG. 3, an exemplary GUI300that can be presented on a display of a computing device is depicted. In an example, the GUI300may be presented on the display210of the patient computing device146as part of the graphical features212. In another example, the GUI300may be presented on the display134of the client computing device122as part of the graphical features136. The GUI300comprises a visual indicator for a healthcare facility302at which healthcare appointments are to occur, as well as visual indicators of patients304-312that are to attend their respective healthcare appointments. The visual indicators of the patients304-312may be arranged such that patients that are closer to the healthcare facility are depicted as closer to the visual indicator for the healthcare facility302and patients that are farther away from the healthcare facility are depicted as farther away from the visual indicator for the healthcare facility302. For instance, in the GUI300, the visual indicator310is closer to the visual indication of the healthcare facility302than the visual indicator312is from the visual indication of the healthcare facility302.

The GUI300additionally includes ordering markings314-322. Each ordering marking in the ordering markings314-322is indicative of an order in which the healthcare appointments are scheduled to occur. Thus, the GUI300may serve as a visual representation of a queue for healthcare appointments at the healthcare facility. In the example shown in the GUI300, a first patient is represented by the visual indicator308and a second patient is indicated by the visual indicator310. The first patient is to attend a first healthcare appointment at the healthcare facility and the second patient is to attend a second healthcare appointment at the healthcare facility. The first healthcare appointment is scheduled to occur prior to the second healthcare appointment. However, the GUI300indicates that the first patient is 8 miles away from the healthcare facility and the second patient is 2 miles away from the healthcare facility. In an example, the EHR may determine that the first patient will fail to arrive at the healthcare facility for the first datetime. Therefore, as described above, the EHR may utilize the above-described processes to reschedule the first healthcare appointment. For instance, the EHR may swap datetimes for the first healthcare appointment and the second healthcare appointment.

With reference now toFIG. 4, a depiction400of tables402-408that may be stored in the cache112is illustrated. The tables402-408may include a table for insurers402of patients, a table for allergies404of patients, a table for medications406of patients, and a table for demographic information408of patients. As described above, when the patient148arrives at the healthcare facility, the server EHR108(or the electronic prescription module110of the server EHR108) may cause data in the tables402-408to be transferred from the cache112to the data store114. While the tables402-408are depicted as four separate tables, in an embodiment, it is to be understood that information retained in the tables402-408may be retained in a single table.

FIGS. 5 and 6illustrate exemplary methodologies relating to patient-check-in for a healthcare appointment. While the methodologies are shown and described as being a series of acts that are performed in a sequence, it is to be understood and appreciated that the methodologies are not limited by the order of the sequence. For example, some acts can occur in a different order than what is described herein. In addition, an act can occur concurrently with another act. Further, in some instances, not all acts may be required to implement a methodology described herein.

Referring now toFIG. 5, a methodology500executed by an EHR that facilitates patient check-in for a healthcare appointment is illustrated. The methodology500begins at502, and at504the EHR schedules a healthcare appointment for a patient at a healthcare facility for a datetime. At506, prior to the datetime, the EHR receives a first message originating from a patient computing device of the patient. The first message comprises a location of the patient and patient information for the patient that is to be used during the healthcare appointment. At508, responsive to receiving the first message, the EHR stores the patient information in a cache accessible to the EHR. At510, the EHR places a placeholder for the patient in a computer-implemented queue comprising placeholders for healthcare appointments at the healthcare facility. An ordering of the placeholders in the queue is indicative of an order in which the healthcare appointments are to occur at the healthcare facility and a position of the placeholder in the queue is based upon the datetime for the healthcare appointment and a distance between the location of the patient and a location of the healthcare facility.

At512, responsive to receiving a second message indicating that the patient has arrived at the healthcare facility, the EHR transfers the patient information from the cache into a data store accessible to the EHR such that the patient information is stored in the data store. At514, the EHR removes the placeholder for the patient from the queue. At516, the EHR purges the cache of the patient information. The methodology500concludes at518.

Turning now toFIG. 6, a methodology600executed by a patient computing device that facilitates patient check-in for a healthcare appointment is illustrated. The methodology600begins at602, and at604the patient computing device generates a first message. The first message comprises a location of the patient and patient information for the patient that is to be used during a healthcare appointment of the patient. At606, the patient computing device causes the first message to be received by an EHR. The EHR stores the patient information in a cache. The EHR also places a placeholder for the patient in a computer-implemented queue comprising placeholders for healthcare appointments at the healthcare facility. An ordering of the placeholders in the queue is indicative of an order in which the healthcare appointments are to occur at the healthcare facility and a position of the placeholder in the queue is based upon the datetime for the healthcare appointment and a distance between the location of the patient and a location of the healthcare facility. At608, responsive to determining that the patient has arrived at the healthcare facility, the patient computing device generates a second message indicating that the patient has arrived at the healthcare facility for the healthcare appointment. Alternatively, the patient computing device may generate the second message at a certain time or in response to determining that the patient has traveled a certain threshold distance to the healthcare facility. At610, the patient computing device causes the second message to be received by the EHR. The EHR then transfers the patient information for the patient from the cache to a data store accessible to the EHR. The EHR then removes the placeholder for the patient from the queue and purges the cache of the patient information. The methodology600concludes at612.

Referring now toFIG. 7, a high-level illustration of an exemplary computing device700that can be used in accordance with the systems and methodologies disclosed herein is illustrated. For instance, the computing device700may be used in a system that dynamically rearranges a computer-implemented queue for healthcare appointments for patients based in part on patient proximity to a healthcare facility in which the healthcare appointments are to occur. By way of another example, the computing device700can be used in a system that displays a visual representation of the computer-implemented queue on a display. The computing device700includes at least one processor702that executes instructions that are stored in a memory704. The instructions may be, for instance, instructions for implementing functionality described as being carried out by one or more components discussed above or instructions for implementing one or more of the methods described above. The processor702may access the memory704by way of a system bus706. In addition to storing executable instructions, the memory704may also store clinical data, appointment data, computer-implemented queues, etc.

The computing device700additionally includes a data store708that is accessible by the processor702by way of the system bus706. The data store708may include executable instructions, clinical data, appointment data, computer-implemented queues, etc. The computing device700also includes an input interface710that allows external devices to communicate with the computing device700. For instance, the input interface710may be used to receive instructions from an external computer device, from a user, etc. The computing device700also includes an output interface712that interfaces the computing device700with one or more external devices. For example, the computing device700may display text, images, etc. by way of the output interface712.

Additionally, while illustrated as a single system, it is to be understood that the computing device700may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by the computing device700.