US20140278515A1 - Data synchronization for booking of healthcare appointments across practice groups - Google Patents

Abstract

Systems and methods for aggregating available healthcare appointment times across multiple unaffiliated practitioner groups, including search and display algorithms. A centralized marketplace is provided for real time booking of healthcare appointments which does not require the patient to have a preexisting relationship with the practitioner. The aggregated booking system enhances the number of available near term and conveniently located appointment options while the search and display algorithms reduce the complexity of the patient and practitioner information required to maintain accurate and synchronized database booking records.

Description

FIELD OF THE INVENTION
• The present invention relates to systems and methods for aggregating available appointment times across multiple practitioner groups, including search and display algorithms.
BACKGROUND
• The booking of healthcare appointments has long been handled via telephone and within a specific group of affiliated healthcare practitioners. The reasons for this are many, including the need to match a great variety of patient needs with the available physician resources, the desire of physicians to maintain control over their working hours and practice, which are essentially dictated by their appointment schedules, the affiliations among insurance companies, plans, fee schedules and accepted procedures, and the patient's desire and comfort level with selecting their own physician.
• As a result, prior attempts to automate this process have generally been unsuccessful. The human receptionist in the doctor's office continues to be central focal point for booking an appointment from the viewpoint of both the physician and the patients. The receptionist has the required knowledge base to satisfy both the needs and comfort levels of the physicians in the practice group and their patients. However, telephone based booking of healthcare appointments is time consuming and very often inconvenient for the patient. For example, call in times are limited to the receptionist's working hours and the volume of calls being handled by the receptionist. Still further, the above scenario assumes the patient has a preexisting relationship with a physician, and that physician has a convenient or acceptable appointment time for the necessary procedure. Finding a new physician is even more time consuming for the patient, involving researching potential local practice groups, physician backgrounds, and calls to see whether the physician is accepting new patients. Thus, while there is much room for improvement, there has been very little success in implementing an alternative process for booking healthcare appointments.
SUMMARY OF THE INVENTION
• Systems and methods are provided for aggregating available healthcare appointment times across multiple unaffiliated practitioner groups, including search and display algorithms. A centralized marketplace is provided for real time booking of healthcare appointments which does not require the patient to have a preexisting relationship with the practitioner. The aggregated booking system enhances the number of available near term and conveniently located appointment options while the search and display algorithms reduce the complexity of the patient and practitioner information required to maintain accurate and synchronized database booking records.
• In accordance with one embodiment of the invention, a method is provided comprising:
• • an aggregator of healthcare appointments maintains a central database of available healthcare appointments for a plurality of healthcare practice groups, and the aggregator provides a website for online booking of available healthcare appointments from the practice groups;
  • each practice group has its own database of its own available healthcare appointments; and
  • appointments are offered to patients from both databases concurrently by the aggregator and the various practice groups;
  • the practice groups and aggregator communicate via a computer network and program code which automatically pulls available appointment times from the practice group databases for the aggregator database; and
  • the aggregator sends the practice groups notices to check for and confirm availability of appointments.
• According to one embodiment, the method includes:
• • determining based on the central database whether a practice group has less than a predetermined number of available appointments, and if true, sending the practice group a notice.
• According to one embodiment, the method includes:
• • determining based on the central database whether a practice group will have no available appointments after a defined time period, and if true, sending the practice group a notice.
• According to one embodiment, the method includes:
• • determining from the central database whether a practice group has no available appointment times, and if true, sending the practice group a notice.
• According to one embodiment, the method includes:
• • determining from the central database whether a practice group has less than a predetermined number of available appointment times, and if true, sending the practice group a message that other practice groups are receiving appointments.
• According to one embodiment, the method includes:
• • prior to a holiday, sending the practice groups a request to verify available appointments in the central database which fall on the holiday.
• According to one embodiment, the method includes:
• • the aggregator communicating in predefined intervals with the practice groups to obtain changed appointment data from the practice group databases.
• According to one embodiment, the method includes:
• • providing an application on a practice group server remote from an aggregator server, for communicating changes of appointment data between the central database and the practice group database.
• In accordance with another embodiment of the invention, a method is provided comprising:
• • an aggregator of healthcare appointments maintains a central database of available healthcare appointments for a plurality of healthcare practice groups, and the aggregator provides a website for online booking of available healthcare appointments from the practice groups;
  • each practice group has its own database of its own available healthcare appointments;
  • appointments are offered to patients from both databases concurrently by the aggregator and the various practice groups; and
  • the practice groups send the aggregator available appointment times for an associated practitioner in time blocks, wherein a time block includes multiple contiguous available appointment times.
• According to one embodiment, the method includes:
• • each practice group specifying a minimum procedure time for a practitioner; the aggregator determining a plurality of available starting time slots from the time block based upon the specified procedure time.
• According to one embodiment, the method includes:
• • the aggregator offering via its website the starting time slots for an associated practitioner.
• According to one embodiment, the method includes:
• • the aggregator stores available appointment times as the time blocks and determines the time slots after receiving an online request for an appointment via the website.
• According to one embodiment, the method includes:
• • the practice group specifying one or more allowed procedure types to be booked in an available appointment time.
• In accordance with another embodiment of the invention, a method is provided comprising:
• • an aggregator of healthcare appointments maintains a central database of available healthcare appointments for a plurality of healthcare practice groups, and the aggregator provides a website for online booking of available healthcare appointments from the practice groups;
  • each practice group has its own database of its own available healthcare appointments;
  • appointments are offered to patients from both databases concurrently by the aggregator and the various practice groups; and
  • when a patient books an online appointment from the aggregator's website, the aggregator notifies the practice group to confirm the booked appointment within a defined time period.
• According to one embodiment, the method includes:
• • the aggregator imposes a penalty on the practice group if it fails to confirm the appointment within the defined time period.
• According to one embodiment, the method includes:
• • the practice group and aggregator communicate via a computer network and program code which automatically pulls available appointment time from the practice group database.
• According to one embodiment, the method includes:
• • the program code automatically alerts the practice group of a booked appointment which requires confirmation.
• According to one embodiment, the method includes:
• • the program code automatically blocks requests to book appointments which are less than a threshold time defined to provide the practice group sufficient time to confirm the booked appointment.
• In accordance with another embodiment of the invention, a method is provided comprising:
• • an aggregator of healthcare appointments maintains a central database of available healthcare appointments for a plurality of healthcare practice groups, and the aggregator provides a website for online booking of available healthcare appointments from the practice groups;
  • each practice group has its own database of its own available healthcare appointments;
  • appointments are offered to patients from both databases concurrently by the aggregator and the various practice groups; and
  • the aggregator's website offers defined practitioner specialties and defined procedure types from which a patient selects to book an appointment; and
  • the practice group specifies a procedure time for an associated practitioner and procedure type.
• According to one embodiment, the method includes:
• • the aggregator determines and offers on its website available starting time slots for an associated practitioner and procedure based on a minimum procedure time of the practitioner.
• According to one embodiment, the method includes:
• • the aggregator's website offers defined insurance carriers and plans from which a patient selects to book an appointment; and
  • the practice group specifies insurance carriers and plans for each of its practitioners.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1A shows an exemplary marketplace (community) enabling online booking of healthcare appointments across practitioner groups according to one embodiment of the invention;
• FIG. 1B is a block diagram of an exemplary computer on which the software product(s) of the present invention may be executed;
• FIGS. 2A and 2B are a flow diagram illustrating the operation and sequence of one embodiment of a software product of the present invention, for creating a practitioner group (client) account;
• FIG. 3 is an exemplary webpage enabling a practice group (client) to create an account;
• FIG. 4 is an exemplary webpage enabling a client to enter individual practitioner profile information;
• FIG. 5 is an exemplary webpage enabling a client to enter available appointment times for a respective practitioner;
• FIG. 6 is an exemplary webpage showing a client the appointment availability for respective practitioners in a calendar format;
• FIG. 7 is an exemplary webpage enabling a client to identify resources for a particular procedure;
• FIG. 8 is an exemplary webpage allowing a client to enter (only once) the same insurance information for each practitioner in the practice group;
• FIG. 9 is an exemplary webpage enabling a client to enter different insurance information for different practitioners in the practice group;
• FIGS. 10A and 10B are a flow diagram illustrating the operation and sequence of one embodiment of a software product of the present invention, for client notification of a booked appointment;
• FIG. 11 is a exemplary pop-up window which appears on a client's computer screen showing unconfirmed appointments that need to be confirmed by the client;
• FIG. 12 is an exemplary webpage showing a client, in calendar format, the status of various appointments;
• FIG. 13 is an exemplary webpage showing a client the notification details of various appointments;
• FIG. 14 is an exemplary webpage showing a client the appointment details of a confirmed appointment;
• FIG. 15 is an exemplary webpage showing an appointment confirmation;
• FIGS. 16A and 16B are a CSR display screen showing a customer service representative the details of appointment bookings for each of a plurality of clients;
• FIG. 17 is an exemplary email message notifying a patient that the practitioner needs to reschedule the appointment;
• FIG. 18 is a flow diagram illustrating the operation and sequence of another embodiment of a software product of the present invention, for synchronizing the appointment records of the aggregator and the clients;
• FIGS.19A1 and19A2 are a flow diagram illustrating the operation and sequence of one embodiment of a software product of the present invention, for generating a list of available appointment time slots;
• FIG. 19B is an exemplary group of database records;
• FIGS.20A1 and20A2 area flow diagram illustrating the operation and sequence of another embodiment of a software product of the present invention, for processing appointment changes;
• FIG. 20B is a flow diagram illustrating the operation and sequence of one embodiment of a software product of the present invention, for removing booked appointment time from the appointment records of the aggregator;
• FIG. 21 is a flow chart illustrating the operation and sequence of another embodiment of a software product of the present invention, for reminding the client to add new available appointment times to the aggregator's calendar;
• FIG. 22 is a flow diagram illustrating the operation and sequence of an embodiment of a software product of the present invention, enabling a patient to search for and book an appointment;
• FIG. 23A is an exemplary webpage enabling a patient to enter a search criteria;
• FIG. 23B is an exemplary webpage for displaying the search results to the patient;
• FIG. 24 is an exemplary webpage of a practitioner profile for review by a patient;
• FIGS. 25A and 25B are a flow diagram illustrating the operation and sequence of an embodiment of a software product of the present invention, providing greater detail on a process for booking an appointment;
• FIG. 26 is an exemplary webpage enabling a patient to confirm the details of a requested appointment;
• FIG. 27 is an exemplary webpage enabling a patient to open an account;
• FIG. 28A is an exemplary webpage enabling a patient to confirm and book an appointment;
• FIG. 28B is an exemplary email sent to a patient after booking an appointment (prior to confirmation);
• FIG. 29 is an exemplary email set to a patient that the appointment has been confirmed by the practitioner (client);
• FIG. 30 is an exemplary email sent to a client requesting confirmation of a newly booked appointment;
• FIGS. 31A and 31B area flow diagram illustrating the operation and sequence of an embodiment of a software product of the present invention, for conducting a patient search of the aggregator database;
• FIG. 32 is a flow diagram illustrating the operation and sequence of an embodiment of a software product of the present invention, for creating a patient account;
• FIG. 33 is an exemplary webpage enabling a patient to create an account;
• FIG. 34 is an exemplary webpage requesting a phone number from the patient to validate an appointment;
• FIG. 35 is an exemplary webpage enabling a patient to enter a verification code;
• FIG. 36 is an exemplary webpage notifying a patient the account has been created;
• FIG. 37 is a flow diagram illustrating the operation and sequence of an embodiment of a software product of the present invention, for location verification;
• FIGS. 38A and 38B are a flow diagram illustrating the operation and sequence of an embodiment of a software product of the present invention, for post appointment processing and gathering of patient feedback;
• FIG. 39 is an exemplary email sent to a patient with a request to provide feedback; and
• FIG. 40 is an exemplary webpage enabling a client to enter patient feedback.
DETAILED DESCRIPTION
• In accordance with various embodiments of the present invention, a consumer portal for booking healthcare appointments across practitioner groups is provided. The consumer, a prospective patient, may or may not be an existing patient of the practice group with whom the appointment will be booked via the portal. The booking procedure is essentially immediate, enabling a patient to view a listing of available appointment times across various practitioner groups and then make an informed selection that satisfies the needs of this specific patient. The patient is provided with a wide range of available appointment times, much broader than would be available from any one practice group. Further, the patient is provided with options for selecting among the available appointment slots, based on a variety of factors including location, near availability of the appointment, insurance plans accepted, background of the practitioner (e.g. doctor or dentist), patient feedback, and others. Perhaps the ultimate convenience, the patient can book the appointment essentially immediately online through a web browser.
• The various embodiments of the invention described herein also satisfy the needs and desires of the various practice groups. The practice group can offload much of the man-power required for booking appointments to another entity, but still maintain control of its own appointment schedule. Procedures are employed to ensure that the appointments being booked are viable appointments and will not likely result in a cancellation or no-show. The practitioners can more readily fill near term available slots in their appointment schedules which become available due to patient cancellations and re-bookings and/or due to changes in the practitioners' own schedules. There are essentially no changes required to be made in the doctor's or dentist's existing practice, rather the new booking procedure can be essentially transparent to, while being an enhancement of, their current practice procedures.
• Various embodiment of the invention will now be described in the following subsections, and with reference to the drawings. First, a general overview of the new systems and methods is provided.
• A booking platform is provided enabling various unaffiliated healthcare practitioner groups to provide, via a centralized aggregator, available healthcare appointments to prospective patients on the aggregator's website. The aggregator maintains a centralized database of available appointment times across the various practitioner groups, as well as information relevant to the practitioner and associated appointment times. The aggregator communicates with each of the practice groups and with a prospective patient while maintaining the database of available healthcare appointments and associated information for scheduling of appointments.
• In accordance with one aspect of the invention, a consumer portal for healthcare appointments across practitioner groups is provided. The portal (website) combines cross practitioner booking functionality, patient reviews, patient reminders, patient insurance filtering, practitioner location information, and other practitioner profile information such as specialty, education and training background, languages spoken, etc.
• In accordance with another aspect of the invention, a centralized database of available appointment information is maintained by the aggregator. The number and accuracy of the appointment times are enhanced by a variety of procedures. In one embodiment, a piece of software (client application) is installed on the practitioner's computer/server, which software automatically extracts from the practitioner's electronic practice management system (PMS), the available appointment times; this is done on a regular basis (e.g. intervals between 1-5 minutes) to insure that the aggregator has the most up to date availability. In addition, the client software may “ping” the aggregator's server periodically (e.g. every 15 minutes) to make sure that the aggregator knows if and when the client server is down (unavailable).
• In another embodiment, synchronization between the aggregator and practice group is done via the aggregator's website. The practice group goes online (to the aggregator's website) and enters the available appointment times.
• Because the aggregator has a centralized database of available appointment times, the aggregator can provide (via its website) essentially instantaneous booking of appointments by prospective patients. A patient logs onto the aggregator website and after opening an account with the aggregator, is allowed to book an appointment. The aggregator then notifies the practice group, e.g. via an email, letting them know that an appointment has been booked and providing a link within the email by which the practice group can elect to confirm the appointment. Alternatively, if the aggregator has installed an application on the client's (practice group's) computer, the client can be notified via a popup on their screen with a link to confirm the appointment. The popup may keep coming up until the appointment is confirmed.
• If the practice group does not click on the link in their email or confirm the appointment by responding to the popup alerter, within a specified time, the aggregator may place a call to the practice office to confirm the appointment.
• Various procedures are employed to insure the accuracy of the available appointment times. To give practice groups enough time to confirm appointments, when appointments are booked after business hours, patients may be prevented from booking early morning hour appointments on the next business day.
• In accordance with another aspect of the invention, if a patient does not show up for an appointment, the aggregator may notify the patient that they are now blocked from booking future appointments, or if they again are a no-show in the future, they will be blocked from booking future appointments.
• In accordance with another aspect of the invention, a practice group can enter their available time on the aggregator's system on the basis of a normal daily or weekly schedule, and then click a “recurring” button to have these times repeat for future days/weeks so they do not have to reenter those times. However, this can create a problem if one of those days in the future happens to be a holiday. To account for this, the aggregator sends the practice group automatic reminders before every public holiday asking them to confirm, if they are, in fact, open for business on this holiday. The aggregator may continue to send out this email every day before the holiday until the practitioner clicks on it letting the aggregator know whether or not they will be working on this holiday. This enables the aggregator to offer a recurring calendar function yet avoid problems with unintended bookings on holidays.
• In another aspect, the aggregator sends reminder emails to practice groups if they are running out of available appointment times, notifying them that they should add additional appointment times. The aggregator may also inform the practice group how many appointments doctors have received in their area, since they last had available times in the system, as an incentive to add further available appointment times.
• In accordance with another aspect of the invention, practitioners are allowed to designate the amount of time the individual practitioner needs for a given procedure. The aggregator fixes the available procedure types, but the practitioner can designate for each type of procedure whether it performs the procedure and what is the minimum time required to perform the procedure. Still further, the practitioner can indicate whether additional resources are required by the procedure, such as a hygienist or physician assistant or a particular piece of equipment. This enables the practice group to keep track of all resources—both human and non-human (e.g. equipment, rooms) needed for a scheduled appointment.
• In a further aspect of the invention, before a patient can book an appointment, the aggregator requires the patient to submit his phone number. This phone number can serve multiple purposes. In one embodiment the aggregator can use the phone number to make sure that there is a unique phone number associated with each patient account, wherein a patient must have an account with the aggregator before he/she can book an appointment. Taking steps to ensure that one actual person has only one account can prevent abuse of the system, for example, where a person may try to disrupt the system by booking multiple appointments. Also, by linking appointments to unique patient accounts, the aggregator can track and limit the number of appointments booked by one patient. Further the aggregator can send the patient a code, e.g. via a text message or a phone call, and require the patient to enter that code on the aggregator's website before the patient is authorized to book an appointment. This also prevents appointment spam, while insuring that the aggregator, and the practitioner, have a correct phone number for the patient.
• In accordance with another aspect of the invention, the aggregator employs a location verification procedure, again to deter appointment spam (bogus appointments). The geographic location of the patient is determined from the patient's IP address and compared to the geographic location of the selected appointment/practitioner. Far distances are flagged as this may indicate a fake appointment. The aggregator can then telephone the patient to verify the credibility of the appointment.
• In accordance with another aspect of the invention, the aggregator implements various methods to detect abuse of the service by patients. Examples are patients who book appointments and do not show up or book appointments and repeatedly cancel at the last minute. Once the aggregator has detected abuse, the aggregator can block the patient from using the aggregator's service. For example, if a patient does not show up for one or more appointments, the aggregator can lock (permanently or temporarily) the patient out of the aggregator's service. Alternatively, if a patient cancels too many appointments in a short time frame, the aggregator can also lock them out of the service.
• In accordance with another aspect of the invention, the aggregator collects and provides on its website patient feedback regarding the practitioners with whom appointments were booked. This patient feedback is limited to patients that have actually booked appointments through the aggregator and attended the appointment. For example, after the aggregator confirms that a patient attended a booked appointment, the patient is sent an email by the aggregator asking them to rate the practitioner. The responses to such email are collected by the aggregator and may be provided as patient feedback to future perspective patients. For example, the feedback may be displayed on the webpage which displays the search results. The feedback solicited may be standardized (by category of input and options for response) by the aggregator, to facilitate comparison. The aggregator may also compile or temporarily escrow the reviews (e.g. until an appropriate number are received) to provide a more reliable assessment of each practitioner, and also to prevent one possibly non-representative review from unfairly skewing traffic (the number of a subsequent bookings) to or away from a practitioner.
• In accordance with another aspect of the invention, the aggregator's website allows patients to filter practitioners based on insurance plans, i.e. the aggregator's website informs the prospective patient whether the practitioner is considered “in network”, “out of network”, or “out of network but the practitioner files the paperwork”. The aggregator provides the practitioner groups with a master (predetermined) list of insurance companies and plans from which the practitioner can designate which plans they participate in, again, in network, out of network, and out of network but practitioner files the paperwork.
• In accordance with another aspect of the invention, the aggregator displays the available appointment times in a particular format. In one embodiment, the display includes for example seven (7) days horizontally displayed along the top, various time slots listed below each day with each time slot being an active link for selecting the time slot, and a button available to select other dates such as the next week and/or the previous week. In another embodiment, the display includes a vertical listing of the practitioner groups meeting the search criteria, with the available appointment times horizontally displayed across the page, adjacent the applicable practitioner. Again, a multi-day (e.g. weekly), layout may be provided for the available time slots.
• In accordance with another aspect of the invention, the aggregator sends patients one or more reminders before every appointment. The aggregator may send a reminder immediately when the appointment is booked, and then follow it up with a reminder a week before the appointment, one day before the appointment, and one hour before the appointment.
• These and other features of various embodiments of the invention are further described below.
Introduction
• In accordance with one embodiment of the invention,FIG. 1A illustrates schematically acentralized marketplace10 for healthcare services across multiple practice groups A, B, C, D, . . . in which a centralized service provider (aggregator)12 provides available appointment times from the plurality ofdifferent practice groups14 to the plurality ofprospective patients16, and wherein the prospective patients are not required to have a pre-existing relationship with any one of the practice groups. The aggregator provides a network based service to the patients and practitioner groups, e.g., the aggregator'sserver13 provides aweb interface13 to each of thepatient computers17, and can also communicate electronically viaemail14 to each of thepatient computers17. The aggregator'sserver13 also communicates (e.g., online and web-based) with each of thepractice groups14 via thepractice group servers15 for retrieving available appointment times from each of the practice groups in order to book and confirm appointments with theprospective patients16. Suitable hardware, communication protocols and software languages for implementing the systems and methods of the various embodiments of the invention described below are readily known to those skilled in the art and any discussion herein is not meant to limit the scope of the invention.
• Thenetwork10 includes anaggregator server13 which executes the various software processes of the present invention, and communicates with a plurality ofpatient computers17 located at remote locations from theserver13. Theserver13 andpatient computers17 are coupled together via the Internet and communicate with one another using standard communication protocols, such as TCP/IP. Theserver13 can be any type of server, including, but not limited to Windows Server 2003, Unix, Linux and Apple OS type servers.
• Referring toFIG. 1B, a block diagram is shown of aserver13 used to execute the software processes of the present invention.Server13 includes aprocessor20,memory22,data storage24,disk drive25,computer display26, keyboard/mouse30, and anetwork interface32. The components are coupled together and communicate via asystem bus34. The software product of the present invention is loaded intodata storage24 and during operation is transferred into (e.g. RAM)memory22 and is executed by theprocessor20. Information regarding the software product is presented ondisplay26. A user may manipulate the software product and enter commands into theserver13 using the keyboard/mouse30. Thenetwork interface32 couples theserver13 to theInternet18, or whatever type of network is used to connect theserver13 with thepatient computers17 and thepractice group servers15. Further, the server may communicate with a storage array or storage network (e.g. SANS) if there is a need to access large amounts of data. A database of patient records, practice group (practitioner) records, and associated scheduling records, may be implemented as a relational database and search engine with, for example, Microsoft's Active Server Page technology, SQL server technology, Database Artisan Software, or database products from Oracle Corp., Redwood Shores, Calif.
• The software product may be implemented as various modules, e.g. a web module, a database module, an email module, and standard application program interfaces (APIs). The web module may include a set of templates and icons to enable the creation of web-pages. It may include other tools that allow a user to create browser-friendly, interactive websites. These tools enable the creation of dynamic hypertext web-pages to be accessed by the patients and practice groups.
• The database module may include a relational database and search engine. The records, fields, search queries and other features of the database are described below and suitable alternatives would be apparent to a person skilled in the art.
• The email module enables emails to be sent to patients and the practice groups fromserver13. The emails can be sent manually by a person operating theserver13 or they can be automatically generated by theserver13. For example, the email module can be configured to automatically query the database module and send email messages to entities identified in the database module.
• The software product includes standard APIs so data and other information can be exchanged with other software systems.
• Each of thepractice groups14 has apractice group server15 for communicating with the aggregator'sserver13. Each practice server may include the groups own patient management software (PMS) and any other database of information used by the practitioners in that group. As described below, the aggregator may install software on the practice group servers for uploading available appointment times to the aggregator's database and otherwise automating and synchronizing the appointment calendars of the practice groups and the aggregator. The aggregator and practice group servers are coupled via the Internet. The relevant appointment booking information may be stored on one or both of the aggregator and practice group servers.
• The database maintained by the aggregator includes records of booking information for each of the practice groups and their respective practitioners, as well as each patient who establishes an account with the aggregator. These records will be described further below in the various embodiments.
Practitioner Side Operation
• FIGS. 2A and 2B are a flow diagram illustrating the operation and sequence of one embodiment of the software product of the present invention for creating a practitioner group (client) account. According to theprocess30, initially the portal website of the aggregator is accessed (Box31) and a client selects the client access page for creating an account. The client inputs an email address, selects a password, and identifies one of the aggregator-defined medical specialties (Box32) for entry in the respective data entry fields61-64 of the corresponding “create an account”webpage60 as shown inFIG. 3. The pull downmenu65 of the “main specialty” window, includes aggregator defined categories from which the client is required to select, in order to standardize the search process for prospective patients. The exemplary specialties include dentist, primary care doctor, dermatologist, ophthalmologist, orthopedic surgeon, and ear-nose-throat specialist. The client hits the submitbutton66 to enter the selected data. The aggregator then confirms (in Decision Diamonds33 and34) that the client's email address is unique and that the input passwords match; if they do, the client is presented with a user agreement (Box35) which the client is required to execute to create an account with the aggregator (Box35). If the email address or passwords are defective, the client is returned to prior webpage (Box32) with a notice to correct the respective entries.
• Once the account has been opened, the client is led through a series of requests (Decision Diamonds36-47 in serial order), to provide information that will be used in the patient search of practitioners. As illustrated in thecorresponding webpage70 ofFIG. 4, the client is prompted to provideclient profile information71, such asname72,professional statement73A,education73B,hospital affiliations73C, languages spoken73D,board certifications73E,professional memberships73F, and awards andpublications73G. The client is also prompted to provide (not shown) practice times, and at least one practice location in the reference table of account information. The client is informed if items are outstanding (Box42) and returned to Decision Diamond36 to provide the outstanding items (as noted in window74). Additional information requested includes: aspecialty76; insurances accepted77; a photo77 (Diamond37); notification email address for receiving emails from the aggregator (Diamond38); and appointment availability to be added to the aggregator's calendar (Diamond39). The step of adding appointment times is discussed further below with reference toFIGS. 5-6. If the client is a practice group with multiple practitioners (e.g. doctors), the client is asked whether additional practitioners will be registered (Diamond40) and if so, the process returns to create another account for the additional practitioner (Box41) and the client is requested to fill in the same profile information for the additional practitioner (return to Diamond36).
• FIGS. 5-6 illustrate two webpages (from the aggregator's website) for entry of available appointment time. In thefirst webpage80, for the practitioner identified in thepractitioner data field81, the client selects a date (shown in the date field82), and enters a start time (shown in the start time field83) and an end time (shown in the end time field84) of a continuous time period during which appointments may be made with this practitioner, for a particular practitioner location (identified in the location field85). If desired, the client also selects this available time period for future dates, by using the pull downmenu86 of periodic future times (here illustrated in number(s) of weeks). Having selected Friday, Jul. 25, 2008 from 9:00 a.m. to 12:00 p.m. as an available continuous time period, and by clicking on the submit (add available time)button87, the added time will now appear in thescheduling calendar window91 of thewebpage90 ofFIG. 6, highlighted as ablock92 for the respective date/time during the week of Jul. 20, 2008, i.e. denoting theavailable time block92 in green according to thecolor key93 for “online bookable” time. Because this practice group has multiple professionals (identified in the “Professionals” window94), thetime block92 also includes at the top95 an identification of the associated practitioner having the available time period. This process can then be repeated for additional dates and time periods, and additional practitioners.
• Returning toFIGS. 2A and 2B, the client is prompted to add an additional geographical location (Diamond43), if the practice group has such additional locations; the client is then directed to another webpage (not shown) to enter the relevant location information (Box44). The client is then prompted to add/identify resources (Decision Diamond45 and Box46), in addition to the previously identified practitioners. One example of this process is illustrated with thewebpage100 ofFIG. 7, wherein the practitioner, designated as a dentist (in window101), has added as a resource (in window103) a hygienist to perform or assist in performing the selected procedure, here a “regular cleaning” having an allocated time of 30 minutes (in the data field104). The client is required to select from the aggregator defined list (of standardized procedures in window102) one of the defined procedures, but the client can define an individualized practitioner time (in minutes) for the procedure. As a result, during the search process, patients will be able to select from among the same aggregator defined group of procedures, but the available appointment times for a designated procedure may vary by individual practitioner (designated time infield104 for the procedure). The client then hits the submitbutton106 to enter the identified resource information. Other resources may include equipment or office space required for the procedure, to enable the practitioner to link a particular piece of equipment or office with a designated procedure, in order to insure that when patient books an appointment both the human resources and non-human (e.g. equipment and office space) resources are available at the selected appointment time.
• Returning toFIGS. 2A and 2B, the client is now asked to provide insurance information (Diamond47). If all of the practitioners in a specific practitioner group accept the same insurance, the client is sent to awebpage110, illustrated inFIG. 8, which allows the client to enter once the same information for each practitioner in the group. Awindow111 identifies a list of standard insurance carriers, from which the client is required to select (by checking the associated box) the one or more applicable carriers, and asecond window112 lists standard insurance plans, from which to select the applicable plans. In the embodiment shown, three selection circles allow the client to identify each plan as: in network, out of network but client handles paperwork, or out of network. The client then hits the submitbutton113 to enter the relevant insurance information for the group. In contrast, if individual practitioners in the group have different insurance carriers/plans, then the client is sent to (Box50) thewebpage120 illustrated inFIG. 9 with a more advanced display of options for identifying the relevant insurance carriers and plans for each practitioner. Awindow121 displays a grid includinginsurance carrier selections122 as a first column,insurance plan selections123 in the second column, athird column124 for indicating whether the practitioner will or will not provide paperwork for the insurance carrier/plan and in the remainingcolumns125, an identification of each of the practitioners in the client group. Additional information and selection options for insurance may also be provided, such as a list ofinsurance carriers126.
• Returning toFIGS. 2A and 2B, after the client submits the appropriate insurance information, the aggregator reviews the entered client information to determine if any items are left to be completed (Box51); if there are uncompleted items, these are displayed on the client account page (FIG. 4) for editing, and once completed, the account is activated (Box53). If no items are outstanding (Box54), the account is activated (Box53).
• FIGS. 10A and 10B are a flow diagram illustrating of the operation and sequence of one embodiment of the software product of the present invention for client notification of appointments. According to theprocess130, when a patient books an appointment with the aggregator (Box131), the client can be notified by one or more communication mechanisms until the appointment status is confirmed (Decision Diamond136). Depending upon the notification options selected by the client, the client may be sent an email (Box132), with appointment details similar to that shown inFIG. 30.
• Another notification option is to notify the client via an alerter (Box133). An alerter is an application which is installed on the client's computer which hides itself in the task bar notification area until a new appointment is booked with the client. When this occurs, the application presents itself (e.g. as a popup window) on the client's computer screen, alerting the client of this new appointment and the need to confirm it. The alerter software checks the aggregator's web server for updates (new appointments booked) regularly. For example, every 5 minutes the alerter may request an alerter HTML page with new appointments from the aggregator's web server. If the page contains unconfirmed appointments, a popup window appears on the client's computer screen. This may be instead of or in addition to the email notification previously described.
• FIG. 11 illustrates such apopup window160 which appears on the client's computer screen when unconfirmed appointments have been made, and that need to be confirmed by the client. The window includestext information162 concerning the patient, practitioner and procedure. In this example, the text includesvarious identification information163 regarding the patient, i.e., name, date of birth, insurance carrier, insurance plan, phone number and address, and further includesinformation164 regarding the practitioner and practice group location for the booked appointment. The text also identifies the appointment date and startingtime165, theprocedure167, andduration time166 for the associated procedure. The email includes a plurality of highlightedlinks161 by which the client can confirm or alter the appointment status, namely: confirm appointment; reschedule appointment; cancel appointment. The aggregator is thus notified, by the client's response via the selected link, whether the appointment status is confirmed (Diamond136).
• In a further alternative, client notification is via an appointment which appears in the client's scheduling calendar (Box134), an example of which is illustrated inFIG. 12.FIG. 12 is a webpage display170 (on the aggregator's website) similar to that shown inFIG. 6, but now includes, in addition to multiple available appointment times171 (in color key green), a plurality of booked appointments which require acknowledgement172 (in color key orange). Again, each of these time blocks appear in a grid of time (vertically displayed) and day of the week (horizontally displayed), for one week. The client is prompted to select among a series of links (not shown, but similar tolinks161 inFIG. 11) to confirm the appointment or reschedule or cancel the appointment. If the appointment is confirmed, the time block in thecalendar170 is changed from orange to blue, indicating that the appointment has been confirmed by the client.
• In a further alternative (Box135), client notification details of an appointment can be viewed in the client'sview appointment webpage180 as illustrated inFIG. 13. Here, awindow181 displays the booked appointments for each of the practitioners in the group, in date order, including the time, procedure, practitioner, and status. The status can be changed by clicking on the link (button)182 for the associated record entry. If an appointment has not yet been confirmed (e.g. the third record183), the status is highlighted in thelast column184 as pending confirmation. Once confirmed, the status is indicated as confirmed (see record number two) and no longer highlighted.
• Returning toFIGS. 10A and 10B, the aggregator will monitor the status of unconfirmed appointments and notify the client appropriately (Decision Diamond136). For example, the client may be notified via the alerter (popup window) every 5 minutes (Box137). Once the client has confirmed the appointment electronically (Decision Diamond138), then the aggregator updates its database and website pages (Box139) and notifies the patient (Boxes140-141).FIG. 14 illustrates a web-page190 on the aggregator's site, available to the client, for displaying the appointment details of an appointment which has been confirmed electronically. It includes thepatient information191,practitioner information192, and the appointment date/time/duration/procedure193.FIG. 15 illustrates anappointment confirmation webpage200 which notifies the patient that the appointment has been confirmed201 and which includes the details of the appointment inwindow202, including the date, time, location, procedure, patient, practitioner and procedure information. Alink203 is provided for the patient to change the appointment, if necessary.
• Returning toFIGS. 10A and 10B, the process updates the aggregator's database to include the confirmed appointment information and a CSR tool displays the updated booking information (Box139). In the CSR display (management console for customer service representatives)210 shown inFIGS. 16A and 16B, the confirmed bookings for each of a plurality of clients are displayed in agrid211, with the clients listed vertically (in alphabetical order) down the page, for convenient viewing by (an employee of) the aggregator. Each client entry includes, underneath an identification of the practice group name andtelephone number212, a series ofdata field headings213 displayed horizontally across the page. These include: client ID, appointment time initiated, closing appointment time, practitioner name, additional practitioner resources (if any), followed by patient information. The patient information includes the user's first and last name, email address, telephone number(s), status of the patient ID, status of the patient's telephone number, reason for the visit, patient's IP address from which the appointment was booked, geographic location of the IP address including country and region (e.g. state). As described hereinafter, the aggregator may use the patient location information to perform an integrity check on booked appointments to detect bogus appointments.
• Returning toFIGS. 10A and 10B, the aggregator sends the patient an email confirming the appointment (Box140); the patient may also receive a welcome call from the client or aggregator (Box141). Details of the confirming email will be described in the following sections.
• If the appointment has not yet been confirmed by the client after some predetermined amount of time, the aggregator will contact the client to determine the status (Box147). If the client needs to reschedule or cancel the appointment (Decision Diamond148) then the aggregator will send the patient a consolation gift, here an Amazon voucher, and the client will be billed for this voucher (Box149). This will discourage clients from canceling or rescheduling appointments which have been booked by the aggregator. Otherwise, the appointment is confirmed and the patient receives a welcome call from the client (Box141).
• FIG. 17 shows an example of anemail message220 sent to a patient, indicating that the practitioner needs to reschedule the appointment, inviting the patient to reschedule a new appointment, and sending (by separate email) an Amazon gift certificate to the patient to compensate for the inconvenience of having to reschedule.
• The aggregator also tracks the patient experience, in order to ensure that patients are satisfied with the appointments being booked with the aggregator. The aggregator determines, e.g., via the client, whether the patient attended the appointment (Decision Diamond142). If yes, the patient will be allowed to rebook additional appointments via the aggregator (Box143), as the patient has established a record of showing up for booked appointments. If not, the client identifies the patient as a no-show (Box144), for example using thelink194 on the client appointment detailspage190 ofFIG. 14. If it is determined that this patient has a history of no-shows, for example more than two no-shows (Decision Diamond145), then the aggregator will deactivate the patient's account (Box146); the patient's phone number may also be blacklisted to prevent the patient from opening another account in the future. If not, the patient is allowed to book additional appointments with the aggregator (Box143).
• FIG. 18 is a flow diagram illustrating the operation and sequence of another embodiment of the software product of the present invention, for synchronizing the appointment records of the aggregator and the clients. As previously described, a synchronizer application may be installed on the client's computer15 (Box231). The synchronizer automatically pulls time (Box232) from the client's practice management software PMS (Box235). This time is sent to the aggregator'sserver13, enabling the aggregator to process and update the available appointment times displayed for this practitioner account on the aggregator's website (Box236). Thus, if new appointments are added to the client's PMS, these times are removed from the list of available times in the aggregator's calendar. If appointments in the client's PMS are canceled, these times are made available again in the aggregator's calendar. In order for the aggregator to know it is receiving appointment updates from the client, the synchronizer will periodically ping (e.g., every 15 minutes) theaggregator server13 and if communication ceases (Box233), the aggregator will investigate the communication failure with the client (Box234) to resolve the same.
• According to another aspect of the invention, FIGS.19A1 and19A2 are a flow diagram illustrating the operation and sequence of one embodiment of the software product of the present invention, namely a process for time slot splicing of the available appointment times. Thisprocess240 is used to determine the available appointment times that can be offered to patients from each client. Open time slots are stored in the aggregator database as larger time blocks and the process splits the time blocks into individual appointment starting time slots, each of the length designated by the client as the shortest procedure time for the associated practitioner. This provides the patient with greater flexibility in selecting appointment start times, without leaving the practitioner with unusable (too small) segments of available time. It allows the aggregator to offer the patient a greater number of possible appointment times, for each individual practitioner.
• Referring to FIGS.19A1 and19A2, theprocess240 obtains a list of open time blocks from the aggregator database12 (Box241). Each time block is processed (in the loop shown below Diamond242), until all blocks have been processed and the process returns a list of available start times (Box243). The process gets the next open time block for a given practitioner (Box244) and determines whether the practitioner (for this time block) performs the requested procedure, or if no procedure was specified by the patient (Diamond245). If the patient has designated the procedure (Decision Diamond246), then the method uses the procedure duration previously identified for this practitioner (Box247). If the patient has not identified the procedure (Diamond246), then the process uses a default procedure time (Box248). The method then confirms that a minimum threshold time is met (Box249), i.e., there is enough time to allow the practitioner to confirm the booking. If it is determined that the time block (being processed) meets the confirmation threshold, it is then determined whether, if the patient has selected an appointment date/time, the time block includes time within the requested date/time and whether the time block is big enough to contain at least one designated procedure (Diamond250). If yes, the method determines whether the practitioner has specified (allows) this procedure in the relevant time period (e.g., all resources are available for this procedure at the time and/or the doctor has not limited the times at which he will perform certain procedures) (Diamond251). If yes, and it is determined that the time block is bigger than the procedure duration (Diamond252), the process then determines whether the time block begins after the minimum threshold time and that there is no previously booked appointment overlapping at this time (Diamond253). If these conditions are met, the appointment is added to the list starting at the beginning of this time block (Box254). Then the beginning of the time block is advanced by the shortest procedure time specified by the practitioner for any procedure the practitioner performs (Box255). This maximizes the number of available start times that can be offered to the patient, while not leaving the practitioner with an unusable (too short) gap between appointments. Otherwise (if the conditions of Box253) are not met, the process proceeds directly to advance the time block by the shortest procedure duration that this practitioner performs (Box255). As indicated, this process will increase the available appointment start times offered to the patient. Also, the time blocks stored in the aggregator's database need not be spliced into smaller time slots (for a given procedure) until a specific procedure is requested. This reduces the size and complexity of the aggregator data records.
• FIG. 19B illustrates one embodiment of a group ofdatabase records235 in the aggregator database. Each record (row) includes data fields for, in addition to an initial record id (key)237:

• 	practice id (specialty)	236a
  	client id (practitioner)	236b
  	client location id	236c
  	procedure id	236d
  	start time	236e
  	end time	236f
  	status	236g
  	booking id	236h
  	duration	236i

• Open time blocks have a status of null and a booking id of null. The last 4 records identify booked appointments.
• As previously described, a synchronizer application installed on the client's computer will retrieve all changed (new and canceled) appointment data from the client's appointment booking system and send it to the aggregator's software in order to update the aggregator's client calendar of available time slots. As illustrated in the flow chart of FIGS.20A1 and20A2, theprocess256 obtains the changed appointments from the client synchronizer (Box258). Then, looping through each changed appointment (Diamond259A) and each practitioner (doctor) in the practice group (Diamond260), the time block records in the aggregator database are locked (Box261). The method then deletes all existing time blocks for this practitioner (Box262), and for all open times (Diamond263A), creates new time block records (Box263B). From these new records, the client designated vacation times are removed from the existing time blocks (Diamond264A andBox264B). For new appointments made by the client (not through the aggregator) (Diamond265A), these appointment times are removed from the existing time blocks (Box265B). For all existing appointments for the client made through the aggregator (Diamond266A), these times are removed from the existing time blocks (Box266B). Then, the changes are committed to the database (Box267). The time block records may then be unlocked. Once all practitioners (e.g. doctors and practitioner locations) have been handled (Diamond259B), and the last sync record updated for this doctor and location, the process is completed (Box259C)
• As further illustrated inFIG. 20B, a procedure269 is provided for handling the removal of booked appointment time (from the available time blocks). The process obtains the time blocks to be handled (e.g. appointments booked by the aggregator and by the clients manually (by telephone)) and determines whether all such time blocks have been handled (Diamond268A). If true, the process ends (Box268B). If not the process gets the next time block to be handled (Box268C). It is determined (Diamond268D) whether the time block is a subset (within) the booked appointment time period (Diamond268E), and if so, the entire time block is removed (Box2681). Otherwise, it is determined whether the booked appointment time period (Diamond268F) is within the time block, i.e. in the middle of it (Diamond268F), and if yes, the appointment time is split into two time blocks one before and one after the appointment time which are added separately to a list of existing time blocks to also be checked (Box268J). Otherwise, if the booked appointment overlaps the beginning of the time block (Diamond268G), the head of the time block is cropped (Box268k). Otherwise, if the booked appointment overlaps the tail of the time block (Diamond268H), the tail of the time block is cropped (Box2861). The process loops through (returns toDiamond268A) until all time blocks are handled.
• FIG. 21 is a flow chart illustrating the operation and sequence of another embodiment of the software product of the present invention, for reminding the client to add new available appointment times to the aggregator's calendar. This is another mechanism for keeping the aggregator and client calendars in sync and enhancing the available appointment times offered to patients.
• This process runs on theaggregator server13, querying the aggregator database to determine which clients need to add appointment times. Depending on the results, a variety of email reminders can be sent to the clients.
• In thisprocess270, a program runs nightly on theaggregator server13 and queries the database (Box271). It first determines whether a client will run out of available appointment time in the next 7 days (Diamond272). If yes, an email is sent by the aggregator to the client every day to remind the client that they will run out of time (Box273). In response, the client can click on a link to add more time (Diamond274). If desired, the client enters additional available appointment times (Box275). It is next determined whether the client has already run out of time, but had available time in the calendar up to 14 days ago (Diamond276). If yes, an email is sent to the client every other day to remind the client they have run out of time (Box277). The client can click on a link in the email if it wants to add time (Diamond278), and then add available appointment time (Box279). The process determines whether the client has already run out of time but had time in 30 or more days ago (Diamond280). If yes, the client is sent an email every 30 days to let the client know its competitors have been receiving appointments via the aggregator (Box281). A client can click on a link in the email if it wants to add time (Diamond282), and then add available appointment time (Box283). If the answers to the three determinations (Diamonds272,276 and280) are negative, then the client is considered to have available appointment time (Box284).
Patient Side Operation
• The following methods and systems illustrate embodiments of the invention in which a prospective patient is enabled to search for and select an available appointment. Also described are methods and systems for the patient to create an account with the aggregator, to enable the booking of an appointment, and processes for location verification (to identify and eliminate possible bogus appointments) and the collection and processing of patient feedback to provide credible evidence of the utility of the search and selection process.
• FIG. 22 is a flow diagram illustrating the operation and sequence of an embodiment of the software product of the present invention, enabling a patient to search for and book an appointment. According to theprocess300, the patient accesses the aggregator's website and enters the search criteria, namely the desired practitioner specialty and location, but also preferably one or more of the insurance details, procedure, and desired appointment date (Box301).FIG. 23A illustrates awebpage290 on the aggregator's website for entering the search criteria. Awindow291 includesdata entry field292 for entering the desired specialty of the practitioner (shown as a pull down menu) from a set of aggregator defined specialties. Anotherwindow293 is a data field for entering the patient's desired geographic location for the appointment, here a zip code. Anotherdata field294A (with a pull down menu) has designated choices which allows the patient to select an insurance carrier, and anotherdata field294B has designated choices which allows the patient to select an insurance plan. Afurther data field295 allows the patient to enter the desired appointment date, and afurther window296 has a pull down menu for the patient to select among aggregator defined procedures. The patient then clicks asearch button297 to begin the search.
• The search is conducted on the data in the aggregator's database of available appointment times. The search results are presented to the patient, enabling the patient to browse the results for a doctor and times that appeal to the individual patient (Box302).FIG. 23B illustrates an aggregator'swebpage310 for displaying the search results311 below the inputtedsearch criteria312. A grid is provided of identified practitioners having available appointment times meeting the search criteria. In this embodiment, theavailable times313 for each practitioner are provided horizontally across the page for one week. For each practitioner the results include: a location designator (map marker number315A) which correlates to the map marker shown in thegraphic display314 of the geographic region encompassing the practitioners having available times in the requested location; aphoto315B of the practitioner; atext identification315C of the physician's name and street address;patient feedback315D for this practitioner; alink316 to request more information on the practitioner; anidentification315E of the insurance plan requested by the patient and whether this practitioner would be considered within the network of the patient'sinsurance plan315F; and agrid315G of the next 7 days sequentially presented across the page, with available appointment starttime slots313 listed under each of the relevant days (aligned with the respective practitioner). The time slots arelinks313 which a patient can select by simply clicking on the link. In addition, the patient is provided with alink317 to browse additional appointment times available in the future, such as the next week.
• Returning toFIG. 22, the patient selects a desired practitioner and is then presented with a webpage on the aggregator's site which enables the patient to browse the selected practitioner's profile (Box303). An example of such a profile is shown in thewebpage320 ofFIG. 24. The profile of the selected practitioner includes the background information previously provided by the client/practitioner group, as well as the results of the search and patient feedback on this practitioner which has been processed and presented by the aggregator. Theupper portion321 of the webpage shows the practitioner photo, name and geographic location, name of the practice group, prior patient ratings, specialty and insurance accepted, and again agraphic display322 of practitioner's location with the map marker. Below this, the webpage further includes a professional statement by thepractitioner323A, a description of the practitioner's education323B and languages spoken323C. It then includes asummary325 of the search criteria (e.g. procedure326) and results available (appointment times324), enabling the patient to click on an available appointment time324 (in the same manner asFIG. 23B). The presentation of the patient reviews329 will be described in a later section.
• Returning toFIG. 22, if a patient wishes to browse the profiles of other practitioners having available appointment times meeting the search criteria, the patient returns to the prior webpage ofFIG. 23A (Box302). The patient can thus select an available appointment time from either of the webpages shown inFIGS. 23B and 24 to book an appointment (Box304).
• FIGS. 25A and 25B are a flow diagram illustrating the operation and sequence of an embodiment of the software product of the present invention, providing greater detail on the process of booking an appointment. According to the process340, the patient accesses the aggregator's website (Box341), enters the search criteria on the aggregator's webpage, such as that shown inFIG. 23A, and clicks on the search button (Box342). The aggregator software conducts a search of the aggregator database and returns the results in a webpage, such as that shown inFIG. 23B. The patient selects an appropriate doctor (Box343) and an appropriate appointment time (Box345). In processing the search request, the process determines whether the practice group has enough time to confirm an appointment and if not, filters out such available appointment time (Box344). After selecting the appointment time, the patient is presented with the webpage, such as thewebpage360 shown inFIG. 26, asking the patient to confirm the selected details of the appointment, including thepractitioner361, date andtime362,practitioner location363,specialty364, reason for visit (procedure)365, and method ofpayment367, (e.g. via a selected insurance plan). The patient is then asked to click on abutton367 to confirm this appointment (Box347).
• In order to confirm the appointment, the patient is next presented with awebpage370 for logging into the patient account (Box348), as shown inFIG. 27. A sign inwindow371 is presented including adata field372 requesting entry of the patient's email address, anddata field373 asking whether the patient is a new user (in which case the user will need to create an account and password) or a returning user (in which case the patient enters his patient password in field374). If the patient has forgotten his password, alink375 is provided for sending the patient his password. After entering the above account information, the patient clicks the sign inbutton376.
• After confirming the patient's login information, the aggregator presents the patient with a webpage for confirming and booking the appointment (Box349). For example, the patient may be presented with a webpage380 as shown inFIG. 28A, with a window381 containing the details382 of the appointment and a button383 to click to book the appointment. The patient may provide additional details about the patient's condition in the window384 provided.
• Returning toFIGS. 25A and 25B, upon receiving the patient's confirmation, the aggregator generates and sends anemail385 to the patient (Box350) notifying the patient regarding the details of the appointment, as shown inFIG. 28B. The aggregator also sends anemail notice400 to the practitioner group (Box351), such as that shown inFIG. 30, asking the practitioner to confirm the appointment. When the client confirms the appointment (Box354), the patient is then sent a confirming email (Box355), such as theemail390 shown inFIG. 29. The aggregator may also send the patient one or more reminders, such as one week prior, one day prior, and one hour prior to the appointment (Box356). The aggregator's CSR tool is automatically updated with the confirmed appointment information (Box357). This process is illustrated inFIGS. 16A and 16B.
• As previously described, the client may be notified of a newly booked appointment, and of the client's need to confirm the booked appointment, in various ways. In one embodiment the client is notified on its computer via an alerter popup window with a message asking the client to confirm the newly booked appointment, as described previously with respect toFIG. 14. In another embodiment, the client is sent anemail400, such as shown inFIG. 30, asking the client to confirm within a defined time period the newly booked appointment. The email notification to the client includes the details of the bookedappointment401 and may include alink402 for a response (or the client may reply by email). In both cases, following receipt of confirmation from the client, the aggregator updates the aggregator's database and the CSR tool for viewing confirmed appointments (as shown inFIGS. 16A and 16B).
• FIGS. 31A and 31B are a flow diagram illustrating the operation and sequence of an embodiment of the software product of the present invention, for conducting a patient search of the aggregator database. The search algorithm queries the aggregator's database for client locations that match the patient's search criteria and then groups and sorts these locations and their associated practitioners and available appointment times to present the most useful results to the patient. The client locations are queried so that clients with multiple locations will appear more than once if they have several locations which match the search criteria. A search score is calculated and recorded at the end of the process which allows the aggregator to analyze the search process to ensure that patients are being presented with the best results.
• The search criteria is entered by the patient on the aggregator's home page or search page and this data is sent to the aggregator as query parameters. If any criteria has not been specified by the patient, the process will provide a default value. Once the search process has determined the most appropriate clients and has sorted them, it will display them in the search page, transmitted to the patient's web browser in HTML format.
• Referring toFIGS. 31A and 31B, according to theprocess420 the patient enters the search criteria on the home or search page of the aggregator and clicks on the search or refine search button (Box421). The process initially gathers the user's entered criteria and sets up the default values for any criteria not specified by the patient (Box422). If the user has not entered the location in the criteria, the process will randomly select a zip code within the relevant area to insure that various areas are represented in a default location search (Box424). The process then retrieves the latitude and longitude of the patient location based on the patient's IP address (Box425), and creates a search object and populates it with the search criteria (Box426). The search object then performs a search by querying the database for all client locations that offer the selected practitioner specialty in the region defined by the search location (Box427). It is imperative that if the search does not return any clients, the process searches for appointments in the following week (returns to Box427). If it does not find any clients it will repeat this step again up to a maximum of four times. If it does not find any clients after repeating this search four times, it will redirect the patient to the aggregator's webpage informing the patient that the aggregator's service is not yet available in the patient's designated area and prompting patients to register their interest in using the aggregator's service (when available) in their area (Box429).
• If the search returns at least one client location with available times meeting the search criteria (Box428), the process will determine the distance from each client location to the patient location (Box430) and organize them into groups based on this distance and the insurance status (in network, out of network) (Box431). The process then randomly sorts the clients in each group so that different clients appear toward the top of the list within their groups (Box432). This ensures that clients are fairly represented in the aggregator's search. The groups are then merged into a master list which is sorted by insurance status and then distance (Box433).
• Finally, the process calculates a search score which allows the aggregator to verify the usefulness of the search results. The HTML formatted data is then returned to the patient and rendered in the patient's browser (Box435).
• As previously described, the available appointment times are filtered to insure that appointments can only be booked for times that allow the client sufficient time to confirm the appointment. For example, if an appointment is booked after 5:00 p.m. on a week day, the appointment cannot be booked before 11:00 a.m. on the following week day.
• FIG. 32 is a flow diagram illustrating the operation and sequence of an embodiment of the software product of the present invention, for creating a patient account. In order for a patient account to be created with the aggregator, the patient must fulfill certain criteria, e.g., the following criteria:
• • age above 13 years;
  • email address has not been used for a previous account;
  • telephone number has not been used for a previous account.
• Further, to check the potential patient authenticity, a code is sent by the aggregator to the patient via a call or SMS message to the patient's phone. This code must then be entered by the patient on the aggregator's website to complete the account creation process. This prevents people from creating random email addresses and making fake appointments. It also insures that the aggregator has the correct phone number for the patient, which number can also be provided to the client.
• Referring to theprocess440 ofFIG. 32, to create an account the patient clicks (Box441) on a create-an-account button on the aggregator's webpage. The patient is then presented with awebpage460 such as that shown inFIG. 33, with awindow461 asking the patient to input hisname462, location (zip code)463,email address465, date ofbirth464, and choosing and confirming a password466 (Box442). The process checks to confirm the email address entered is unique (Box443). If not, an error message is sent and the patient is sent back to theprior webpage462 with an error message (Box442). The process then determines whether the passwords entered in the two fields, chose a password and confirm the password, match (Box444). If they do not, the patient is sent an error message and returned to the webpage ofFIG. 33 (Box442). If they match, the process checks if the patient's date of birth is above 13 years (Diamond445). If not, the patient is returned with an error message to the webpage ofFIG. 33 (Box442). If the age requirement is met, the process initiates a registration validation process (Box446). The patient is sent to awebpage470 as shown inFIG. 34 requesting a phone number to validate the appointment, at which number the patient can now be reached, and a request whether to contact the patient via a live (or automated) call or text message (e.g., SMS text message for cell phones) (Box446). The process then verifies whether the telephone number provided for immediate contact is unique in the aggregator database of patient accounts (Diamond447). If not, an error message is returned to the patient to fix the items in the webpage ofFIG. 34 (Box446). If the telephone number is unique, the process generates a code (Box448). The code is transmitted to the patient and the process awaits receipt of the code (entered by the patient on the aggregator's webpage) to determine whether it matches (Diamond449).FIG. 35 illustrates an aggregator'swebpage480 wherein the patient is prompted to enter thecode481 and then hit submit482 in order to validate the registration. If the inputted code is correct, the process allows the account to be created (Box450). The patient is presented awebpage490 notifying them that the account is created and inviting the patient vialink491 to view his appointments (FIG. 36).
• FIG. 37 is a flow diagram illustrating the operation and sequence of an embodiment of the software product of the present invention, for verifying the patient location. This process helps detect and guard against bogus appointments.
• With reference to theprocess500 ofFIG. 37, once an appointment is booked (Box501) the process provides a display for an administrator of the aggregator, showing the IP address of the computer from which the patient booked the appointment, and its geographic location (Box502). An example of such a display is shown inFIG. 16. If it is determined that the patient IP address is sufficiently remote from the search location criteria entered by the patient (Diamond503), then the aggregator will call the patient by phone to determine whether this is a credible (valid) booking (Box504). If the aggregator is satisfied that the appointment is valid, the appointment status will be confirmed in the aggregator database (Box505). If the geographic location of the patient's IP address is sufficiently close to the search location criteria, then the appointment status can be confirmed without further validation. Also, when appointments are booked, the patient IP address can be used to calculate and then record the patient's country and region which are then logged with the request in the database.
• FIGS. 38A and 38B are a flow diagram illustrating the operation and sequence of an embodiment of the software product of the present invention, providing more detail on a post appointment process which includes the gathering of patient feedback. To insure that all feedback is based on an actual patient visit, the aggregator insures that all patients that leave feedback have actually seen the respective client by confirming their appointment history. Only patients who have seen a client can leave feedback.
• Referring to theprocess510 ofFIGS. 38A and 38B, once an appointment is booked (Box511), it is determined whether the patient went to the appointment (Diamond518), and whether the appointment was completed (Box521); if so, then the aggregator automatically sends the patient an email soliciting patient review (Box522).FIG. 39 is an example of such anemail530 sent to the patient, providing alink531 for the patient to access a webpage wherein the patient can provide comments and responses to standardized ratings. Patients can then complete a review of the doctor by entering responses to the designated rating criteria and providing additional text comments before submitting the review (Box523).FIG. 40 is an illustration of an aggregator'swebpage540 inviting patient feedback. It includes three specific rating categories, each including a number of alternative ratings, here ageneral recommendation541, a rating on the practitioner'sbedside manner542, and rating on the amount of waiting time in the office before the patient was seen543. The patient is provided with awindow544 for entering any additional text comments. The patient is given theoption545 to include or exclude his name on the review. The patient then hits the submitreview button546 and the feedback is provided to the aggregator.
• Returning toFIGS. 38A and 38B, the disclosed process also includes a process for determining whether the patient canceled the appointment, or was a no-show. If the patient canceled the appointment electronically from within their (aggregrator) account (Box512), the aggregator informs the client via email (Box513) and the aggregator updates the CSR tool and informs its CSR (customer service representative) via an email (Boxes514 and515). If it is determined that the patient has canceled previous appointments (Diamond516), then the patient may be locked out of making future appointments; the patient will have to explain to the aggregator the basis for the cancellations before the account can be reinstated (Box517). If the patient has not previously canceled, then the patient is allowed to book another appointment (Box520). If the patient no-shows twice, then the patient account is locked (Box519).
• If it was the client who canceled or rescheduled the appointment (Box524), then the aggregator offers the patient another practitioner (Box525) or the client offers the patient another appointment time (Box526). The aggregator sends the patient a gift voucher to compensate for the inconvenience (Box527).
System, Method and Computer Program Product
• As will be appreciated by one skilled in the art, the present invention may be embodied as a system, method or computer program product. Accordingly, unless specified to the contrary, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.
• Any combination of one or more computer-usable or computer-readable medium(s) may be utilized, unless specified to the contrary herein. The computer-usable or computer-readable medium may be, for example but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor. More specific examples (a non-exhaustive list) include: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CDROM), an optical storage device.
• Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++, C#, JavaScript/Ajax and similar programming languages. JavaScript, which relies on a runtime environment in a web browser, is commonly used for website development (e.g., writing functions that are embedded in or included from HTML pages). JavaScript can be used as a scripting language for implementing an Ajax—embedded webpage. Unless otherwise specified, the program code may execute entirely on a user's computer, partly on the user's (e.g., patient or client) computer, as a stand-alone software package, partly on a user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
• A website is a collection of web pages posted on one or more web servers, accessible via the Internet. A webpage is a document, typically written in [X]HTML, that is generally accessible via HTTP, a protocol that transfers information from a web server to a display in the user's web browser. The collection of publically accessible websites are referred to as the “World Wide Web”.
• Websites are written in, or dynamically converted to, HTML (hyper text mark-up language) and are accessed using a software interface known as the user agent. Web pages can be viewed or otherwise accessed from a range of computer-based and Internet-enabled devices of various types, including desktop computers, laptop computers, PDA's and cell phones. A website is posted on a computer system known as a web server, and it includes software that retrieves and delivers the pages in response to requests from the website users.
• A dynamic website presents variable information that is tailored to particular users. It may accept the user's input and respond to a user's request. For example, the user can enter text into a data entry field or form or select highlighted (linked) options, which prompts the website to fulfill the request and return a unique result. The aggregator's website, accessible in various forms to both patients and practice groups, includes such dynamic functionality.
• A link or hyperlink, is a reference or navigation component in a document to another section of the same document or to another document on a different domain. A web browser usually displays a link in some distinguishing way, e.g. in a different color, font or style. When the user activates the link (e.g. by clicking on it with the mouse) the browser will display the target of the link.
• As used herein, database and central database are not meant to be limiting, and may reside in one or more locations and/or data repositories. The aggregator's database is referred to as a central database to distinguish it from the separate multiple databases of the unaffiliated practice groups from which the aggregator combines (aggregates) the available appointment times to be offered on the aggregator's website.
• The aggregator can, by collecting and storing this available appointment data from a plurality of unaffiliated practice groups, provide a much larger database of available appointment times/specialties/procedures and can allow patients to book appointments directly with the aggregator, without requiring the patients to contact the practice group in any manner (by phone, email or practice group website).
• The present invention is described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
• These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
• The flowchart and block diagrams illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
• By way of example only, various described embodiments may be implemented on process based servers, such as anyx86_—64 processor based server, for example running a Windows Operating System, e.g. Windows Server 2003, Windows XP/Vista, including Microsoft's NET Framework (e.g. Net 2.0). The database programming may be implemented in the SQL programming language (e.g. MS SQL 2005 and TSQL).
• Modifications can be made to the previously described embodiments of the present invention and without departing from the scope of the invention, the embodiments being illustrative and not restrictive.

Claims (21)

1. A method comprising:

an aggregator of healthcare appointments maintains a central database of available healthcare appointments for a plurality of healthcare practice groups, and the aggregator provides a website for online booking of available healthcare appointments from the practice groups;

each practice group has its own database of its own available healthcare appointments; and

appointments are offered to patients from both databases concurrently by the aggregator and the various practice groups;

the practice groups and aggregator communicate via a computer network and program code which automatically pulls available appointment times from the practice group databases for the aggregator database; and

the aggregator sends the practice groups notices to check for and confirm availability of appointments.

2. The method ofclaim 1, including:

determining based on the central database whether a practice group has less than a predetermined number of available appointments, and if true, sending the practice group a notice.

3. The method ofclaim 1, including:

determining based on the central database whether a practice group will have no available appointments after a defined time period, and if true, sending the practice group a notice.

4. The method ofclaim 1, comprising:

determining from the central database whether a practice group has no available appointment times, and if true, sending the practice group a notice.

5. The method ofclaim 1, comprising:

determining from the central database whether a practice group has less than a predetermined number of available appointment times, and if true, sending the practice group a message that other practice groups are receiving appointments.

6. The method ofclaim 1, comprising:

prior to a holiday, sending the practice groups a request to verify available appointments in the central database which fall on the holiday.

7. The method ofclaim 1, comprising:

the aggregator communicating in predefined intervals with the practice groups to obtain changed appointment data from the practice group databases.

8. The method ofclaim 7, comprising:

providing an application on a practice group server remote from an aggregator server, for communicating changes of appointment data between the central database and the practice group database.

9. A method comprising:

an aggregator of healthcare appointments maintains a central database of available healthcare appointments for a plurality of healthcare practice groups, and the aggregator provides a website for online booking of available healthcare appointments from the practice groups;

each practice group has its own database of its own available healthcare appointments;

appointments are offered to patients from both databases concurrently by the aggregator and the various practice groups; and

the practice groups send the aggregator available appointment times for an associated practitioner in time blocks, wherein a time block includes multiple contiguous available appointment times.

10. The method ofclaim 9, comprising:

each practice group specifying a minimum procedure time for a practitioner;

the aggregator determining a plurality of available starting time slots from the time block based upon the specified procedure time.

11. The method ofclaim 10, comprising:

the aggregator offering via its website the starting time slots for an associated practitioner.

12. The method ofclaim 10, comprising:

the aggregator stores available appointment times as the time blocks and determines the time slots after receiving an online request for an appointment via the website.

13. The method ofclaim 9, comprising:

the practice group specifying one or more allowed procedure types to be booked in an available appointment time.

14. A method comprising:

an aggregator of healthcare appointments maintains a central database of available healthcare appointments for a plurality of healthcare practice groups, and the aggregator provides a website for online booking of available healthcare appointments from the practice groups;

each practice group has its own database of its own available healthcare appointments;

appointments are offered to patients from both databases concurrently by the aggregator and the various practice groups; and

when a patient books an online appointment from the aggregator's website, the aggregator notifies the practice group to confirm the booked appointment within a defined time period.

15. The method ofclaim 14, wherein:

the aggregator imposes a penalty on the practice group if it fails to confirm the appointment within the defined time period.

16. The method ofclaim 14, wherein:

the practice group and aggregator communicate via a computer network and program code which automatically pulls available appointment time from the practice group database.

17. The method ofclaim 16, wherein:

the program code automatically alerts the practice group of a booked appointment which requires confirmation.

18. The method ofclaim 17, wherein:

the program code automatically blocks requests to book appointments which are less than a threshold time defined to provide the practice group sufficient time to confirm the booked appointment.

19. A method comprising:

an aggregator of healthcare appointments maintains a central database of available healthcare appointments for a plurality of healthcare practice groups, and the aggregator provides a website for online booking of available healthcare appointments from the practice groups;

each practice group has its own database of its own available healthcare appointments;

appointments are offered to patients from both databases concurrently by the aggregator and the various practice groups; and

the aggregator's website offers defined practitioner specialties and defined procedure types from which a patient selects to book an appointment; and

the practice group specifies a procedure time for an associated practitioner and procedure type.

20. The method ofclaim 19, wherein:

the aggregator determines and offers on its website available starting time slots for an associated practitioner and procedure based on a minimum procedure time of the practitioner.

21. The method ofclaim 19, wherein:

the aggregator's website offers defined insurance carriers and plans from which a patient selects to book an appointment; and

the practice group specifies insurance carriers and plans for each of its practitioners.

Images