WO2008106761A1 - System and method for generating automated reminders - Google Patents

System and method for generating automated reminders Download PDF

Info

Publication number
WO2008106761A1
WO2008106761A1 PCT/CA2007/000373 CA2007000373W WO2008106761A1 WO 2008106761 A1 WO2008106761 A1 WO 2008106761A1 CA 2007000373 W CA2007000373 W CA 2007000373W WO 2008106761 A1 WO2008106761 A1 WO 2008106761A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
notification
data
appointment
package
Prior art date
Application number
PCT/CA2007/000373
Other languages
French (fr)
Inventor
Jeremy Greven
Blair Taylor
Original Assignee
Promptalert Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Promptalert Inc. filed Critical Promptalert Inc.
Priority to PCT/CA2007/000373 priority Critical patent/WO2008106761A1/en
Publication of WO2008106761A1 publication Critical patent/WO2008106761A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/109—Time management, e.g. calendars, reminders, meetings or time accounting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests

Definitions

  • the present invention relates generally to a system and method for processing and updating event related information and specifically to using automated reminders for updating the event related information.
  • EMR Electronic Medical Records
  • TOR_LAW ⁇ 6542311 ⁇ 1 event and task related information i.e. appointments and meetings with clients which need to be maintained, updated and/or confirmed.
  • Problems associated with current state of the art appointment reminder systems include handling of large amounts of data from an appointment database having a plurality of appointments, client, and service provider information.
  • a further problem is inefficiencies and errors in manual updating of appointment reminder status.
  • a further problem is integration difficulties with a variety of appointment reminder systems for effective updating of their appointment records.
  • a further problem concerns monitoring and efficient processing of related appointments.
  • a further problem concerns coordination (i.e. disconnect or misunderstanding) of appointment details between service providers, clients, and the appointment reminder systems.
  • a server for processing event related information of a scheduler application, the event related information including identification data of a client and event data corresponding to the client, the system comprising: a memory for storing a plurality of update codes corresponding to the scheduler application, the update codes defining a format of a notification package in a native language of a database of the scheduler application; a generation module configured for receiving the event related information from a scheduler interface and configured for generating a notification reminder message according to a defined message timing, the notification reminder message including the event data and client contact data associated with the client identification data, the notification reminder message configured for sending according to the client contact data over a
  • TOR_LAW ⁇ 654231 1 ⁇ 1 communications network for receipt by the client; a processing module configured for receiving notification response information in response to the notification reminder message; an interpreter module configured for generating the notification package including the notification response information and an update code selected from the plurality of update codes, the update code corresponding to the notification response information, the notification package configured for sending to the scheduler interface.
  • a method for processing event related information of a scheduler application comprising the steps of: storing a plurality of update codes corresponding to the scheduler application, the update codes defining a format of a notification package in a native language of a database of the scheduler application; receiving the event related information from a scheduler interface; generating a notification reminder message according to a defined message timing, the notification reminder message including the event data and client contact data associated with the client identification data, the notification reminder message configured for sending according to the client contact data over a communications network for receipt by the client; receiving notification response information in response to the notification reminder message; and generating the notification package including the notification response information and an update code selected from the plurality of update codes, the update code corresponding to the notification response information, the notification package configured for sending to the scheduler interface.
  • Figure 1 is a block diagram illustrating an information processing system for processing and updating appointment information
  • Figure 2 is a block diagram of a scheduling device of Figure 1 ;
  • Figure 3 is a block diagram of a bridge proxy server of Figure 1;
  • FIG. 4 is a block diagram illustrating example components of a data package used in the system of Figure 1 ;
  • FIG. 5 is a block diagram illustrating example components of a notification package used in the system of Figure 1 ;
  • Figure 6 is a sequence diagram illustrating an example communication between the bridge and one of the scheduling devices of Figure 1;
  • Figure 7 is a block diagram illustrating the central server 110 of Figure 1 ;
  • Figure 8 is a block diagram illustrating the scheduling device of Figure 1 according to an embodiment.
  • FIG. 1 shown is an information processing system 100 for processing and updating event related information.
  • the system 100 provides upload of event related information (including one or more appointments, as well as corresponding clients and service providers associated therewith) stored on a scheduling device 102 via a data package 404 transmitted across a network 106.
  • the system 100 generates and transmits notifications to the clients for the upcoming events in data package 404 via notification reminders 506 and receives responses, such as confirmations from the client to the particular event in the notifications via notification responses 507.
  • the system 100 translates the responses 507 into a notification package 504 which is in the form for applying the update on the corresponding scheduling device 102 and its associated database. Examples of users of the scheduling devices 102 include doctors, dentists, lawyers and other entities needing sophisticated appointment scheduling services.
  • the system 100 is used for processing and updating event related information.
  • Events refer to various types of occurrence, happenings or activity that may be related to one or more persons. That is, events can refer to any actions scheduled for a certain time and/or date and/or place. Examples of events include appointments, meetings, scheduled tasks, or other activities. For simplicity, the term appointments will be used hereinafter to refer to one type of exemplary event. However, it will be understood that other types of events may be envisaged.
  • the system 100 comprises one or more scheduling devices 102 connected via the bridge 104 through to a network 106 to a notification server 110.
  • the bridge 104 may exist as a standalone unit such as the bridge proxy server 104b or it may be implemented as an application loaded onto a corresponding scheduling device 102.
  • the bridge 104 whether implemented as a standalone unit 104b or installed on the scheduling device 102 as a local bridge 104a will be referred to as the bridge 104 hereinafter.
  • the bridge 104 is configured for intelligent manipulation of the data package 404 in order to help reduce the bandwidth sent across the network 106 by minimizing the size of the data package 404 and to thereby facilitate improvements in the efficiency of the system 100.
  • the bridge 104 further comprises a filter module 230 to implement bridge 104 intelligence to reduce the amount of data included in the data package 404a prior to transmission over the network 106 to the server 110 as data package 404b.
  • the filter module 230 is configured to remove stale appointment related data, repetitive data or unchanged data (as compared to previous transmission(s) of the data package 404a,b) prior to sending the data package 404b across the network 106.
  • the filter module 230 is configured to remove client data or service provider data not linked to appointment data.
  • the bridge 104 comprises a number of configuration settings 232a, which control the operation of the bridge 104 with respect to the central server 110 connected to the bridge 104, and the one or more scheduling devices 102.
  • the configuration settings 232a may define the time intervals for uploading the data package 404 to the server 110.
  • the bridge 104 processes the notification package 504 received in response to the data package 404 and applies the notification results provided by the notification package 504 to the database 210 of the corresponding scheduling device 102 which originated the data package 404.
  • the bridge 104 acts an interface between the scheduler application/ scheduler database 210 and the central server 110, for facilitating intelligent upload and download of the packages 404, 504.
  • the central server 110 is further connected to the network 106 for receiving appointment related data via the data package 404 from the one or more scheduling devices 102 through the bridge 104. As will be described, the central server 110 is configured to process the appointment related data received from the bridge 104 and to generate automated
  • a Gateway 112 i.e. a voice or SMS and/or SMTP Gateway
  • the client devices 108 may include, for example, a telephone device, a pager, a printer, an SMS client device, a personal computer, a personal digital assistant, a laptop or other devices configured to receive voice, text and/or email notification reminders 506 for a response to be fed back via the server 110 and bridge 104 to update the scheduling device's 102 database 210 (see Figure 2) containing the appointment data.
  • the system 100 further comprises a website customization service 116 and an admin user interface 114 connected to the central server 110.
  • the automated notification reminders 506 described herein may be generated using predefined templates 508 stored on the server 110.
  • the templates 508 used to generate the automated notification reminders 506 can be customized using the website customization service 116 (via the website update package 117) and/or the admin user interface 114 which allow customization of the generated notification reminders 506 for the appointment related data as will be transmitted to the client devices 108.
  • the information processing system 100 may include additional servers, scheduling devices, and other devices not shown, including one or more distributed servers 110 and bridge proxy server 104b.
  • each of the scheduling devices 102 includes at least one database or memory storage (i.e. database 210) for storing the data package 404 comprising the appointment data 406, client data 410 and service provider data 408.
  • appointment data 406 may include the time of the appointment, the date of the appointment, the location of the appointment and other details regarding the appointment.
  • the client data 410 may include, for example, names of clients/patients having appointments, the date of birth of the client, client contact information, names of other family members linked to the client, client billing details
  • the service provider data 408 may include, for example, the name of a doctor, dentist, or lawyer or other type of service provider which a client may have an appointment with.
  • the service provider data 408 then includes identification information for the various service providers. It should be noted that one scheduling device 102 may be associated with various service providers, each having their own clients and appointments. In turn each of these appointments is stored in database 210.
  • These scheduling devices 102 provide an interface for a service provider or an administrator to input and update data 410, 406, 408 relating to a client "Cn” and the client's associated appointments “An” for a particular service provider "Sn", details of which are communicated to the client devices 108 as further described below.
  • the data package 404 contained within the scheduling device's database 210 can be further updated to include the results of the notification package 504. For example, where the scheduling devicelO2 stores a list of appointment "An" data 406 for a client "Cn”, then the appointment data 406 may be updated to include information about whether the client "Cn" has confirmed the relevant appointment "An”.
  • the scheduling devices 102 discussed herein, for example, are personal computers or network computers that are implemented as clients to the central server 110.
  • the scheduling device 102 can generally include a network connection interface 200, such as a network interface card or a modem, coupled via connection 218 to a device infrastructure 204.
  • the connection interface 200 is connectable during operation of the scheduling device 102 to the network 106 (e.g. an intranet and/or an extranet such as the Internet), which enables each of the scheduling devices 102 to communicate with each the server 110 as appropriate.
  • the network 106 e.g. an intranet and/or an extranet such as the Internet
  • the network 106 supports the communication of the package data 404 between the bridge 104 and the scheduling devices 102 or between the bridge 104 and the server 110. As discussed earlier, the bridge 104 acts as an interface between the scheduling device 102 and the server 110. Further, the network 106 supports the transmission of the notification package 504 between the server 110 and the bridge 104 as well the communication between each of the scheduling devices 106 and the website customization service 116 as desired.
  • each of the scheduling devices 102 can also have a user interface 202, coupled to the device infrastructure 204 by connection 222, to interact with a user such as the service provider or the scheduling device's 102 administrator (not shown).
  • the user interface 202 can include one or more user input devices such as but not limited to a QWERTY keyboard, a keypad, a track wheel, a stylus, a mouse, a microphone and the user output device such as an LCD screen display and/or a speaker. If the screen is touch sensitive, then the display can also be used as the user input device as controlled by the device infrastructure 204.
  • the user interface 202 for the scheduling device 102 is employed by the user of the scheduling device 102 to input data relating to the service provider data 408, the client data 410, and the appointment data 406.
  • the device infrastructure 204 includes one or more computer processors 208 and can include an associated memory 210 (e.g. a random access memory).
  • the computer processor 208 facilitates performance of the scheduling device 102 configured for the intended task through operation of the network interface 200, the user interface 202 and other application programs/hardware of the scheduling device 102 by executing task related instructions.
  • These task related instructions can be provided by an operating system, and/or software applications located in the memory 210, and/or by operability that is configured into the electronic/digital circuitry of the processor(s) 208 designed to perform the specific task(s).
  • the device infrastructure 204 can include a computer readable storage medium 212 coupled to the processor 208 for providing instructions to the processor 208 and/or to load/update client application programs 224, 104a.
  • the computer readable medium 212 can include hardware and/or software such as, by way of example only, magnetic disks, magnetic tape, optically readable medium such as CD/DVD ROMS, and memory cards.
  • the computer readable medium 212 may take the form of a small disk, floppy diskette, cassette, hard disk drive, solid state memory card, or RAM provided in the memory module 210. It should be noted that the above listed example computer readable mediums 212 can be used either alone or in combination.
  • scheduling devices 102 can include the executable application programs/instructions such as the scheduler instructions 224 (i.e. exemplary software
  • TOR_LAW ⁇ 654231 1 ⁇ 1 scheduling programs allow users to store and access information relating to the users, their scheduled events/tasks, and corresponding contact information). It is further noted that in some cases, these software scheduling programs facilitate sharing of calendar events among users to allow scheduling within a global calendar of events.
  • the scheduling devices 102 can also include bridge application program 104a comprising code or machine readable instructions for implementing predetermined functions/operations including those of an operating system, healthcare provider or service provider information system or other information processing system, for example, in response to command or input provided by a user of the scheduling device 102 or the system 100.
  • the processor 208 as used herein is a configured device and/or set of machine-readable instructions for performing operations as described by example above.
  • the processor 208 may comprise any one or combination of, hardware, firmware, and/or software.
  • the processor 208 acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information with respect to an output device.
  • the processor 208 may use or comprise the capabilities of a controller or microprocessor, for example. Accordingly, any of the functionality provided by the systems and process of FIGS. 1,2,3 may be implemented in hardware, software or a combination of both. Accordingly, the use of a processor 208 as a device and/or as a set of machine readable instructions is hereafter referred to generically as a processor/module for sake of simplicity.
  • the scheduling device 102 provides access to the data 404 (received in database 210) to the bridge 104 as well as receives updates to data 404 in storage/database 210 in the form of a notification package 504 configured for application to the storage/database 210.
  • the storage/ database 210 described herein is the place where data is held in an electromagnetic or optical form for access by a computer processor.
  • storage is frequently used to mean the devices and data connected to the computer through input/output operations such as hard disk and tape systems and other forms of storage not including computer memory and other in- computer storage.
  • TOR LAW ⁇ 6 5 42311 ⁇ 1 storage which holds data in memory (sometimes called random access memory or RAM) and other "built-in" devices such as the processor's Ll cache, and (2) secondary storage, which holds data on hard disks, tapes, and other devices requiring input/output operations.
  • Primary storage is much faster to access than secondary storage because of the proximity of the storage to the
  • secondary storage can hold much more data than primary storage.
  • primary storage includes read-only memory (ROM) and Ll and L2 cache memory.
  • ROM read-only memory
  • Ll L2 cache memory
  • hard disks secondary storage includes a range of device types and technologies, including diskettes, Zip drives, redundant array of independent disks (RAID) systems, and holographic storage.
  • a database is one embodiment of storage 210 as a collection of information that is organized so that it can easily be accessed, managed, and updated.
  • databases can be classified according to types of content: bibliographic, full-text, numeric, and images.
  • databases are sometimes classified according to their organizational approach. The > most prevalent approach is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways.
  • a distributed database is one that can be dispersed or replicated among different points in a network.
  • An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.
  • Computer databases typically contain aggregations of data records or files, such as sales transactions, product catalogs and inventories, and customer profiles.
  • a database manager provides users the capabilities of controlling read/write access, specifying report generation, and analyzing usage.
  • Databases and database managers are prevalent in large mainframe systems, but are also present in smaller distributed workstation and mid-range systems such as the AS/400 and on personal computers.
  • SQL Structured Query Language
  • IBM's DB2, Microsoft's Access and database products from Oracle, Sybase, and Computer Associates.
  • Memory is a further embodiment of storage/database 210 as the electronic holding place for instructions and data that the computer's microprocessor can reach quickly.
  • TOR_LAW ⁇ 0542311 ⁇ 1 computer is in normal operation, its memory usually contains the main parts of the operating system and some or all of the application programs and related data that are being used. Memory is often used as a shorter synonym for random access memory (RAM). This kind of memory is located on one or more microchips that are physically close to the microprocessor in your ! computer.
  • RAM random access memory
  • the data package 404 discussed herein is a combination of service provider data 408, client data 410 and appointment data 406 for a particular client "Cn" and service provider "Sn".
  • said service provider "Sn" i.e. a particular dentist
  • each service provider such as a dentist, physician, health care provider or other defined service provider is defined by certain identification means such as but not limited to, a name of the service provider, an account ID, and a service provider ID.
  • each client associated with the service i provider i.e. a dental patient
  • each appointment "An" corresponds to a scheduled event for a particular client "Cn” by the service provider "Sn”.
  • the appointment data 410 can include such as but not limited to an appointment ID, a date and time for the appointment, the associated client ID, and the associated service provider ID.
  • each of the data packages 404a and 404b can include all or a subset of the data described generally as data package 404 shown in Figure 4. Further examples of fields that may be included in each of the service provider data 408, the appointment data 406 and the client data 410 for each data package 404 are provided below. Additionally, the data package 404a
  • TOR_LAW ⁇ 6 5 42311 ⁇ 1 refers specifically to the data package 404 communicated between one of the scheduling devices 102 and a corresponding bridge 104 while the data package 404b refers specifically to a data package 404 which is communicated between the bridge 104 and the central server 110.
  • the data package 404a sent to the bridge 104 can include all the phone numbers and an email address for a particular client "Cn”
  • the bridge 104 intelligence i.e. via the configuration settings 232
  • the bridge 104 may filter out (via filter 230) additional contact information such that the data package 404b includes only the relevant phone number as the contact information.
  • the data package 404 shown in Figure 4 can be further understood with reference to the following exemplary descriptions of each of the service provider data 408, appointment data 406 and client data 410 and their corresponding fields.
  • the description below provides an example of some of the fields that may included within the each of the data 406, 408, and 410 for a data package 404. It is noted that other additional fields defining each of the data 406, 408, and 410 may be envisaged as will be understood by a person of ordinary skill in the art.
  • the data packages 404a and 404b may be transmitted one segment at a time.
  • the bridge 104 may be configured to send the client data 410 first to the central server 110, followed by the service provider data 408 and the appointment data 406.
  • the client data 410 can include, for example, the following fields:
  • a cross reference id to the client id used in the client package is
  • the first name of the client is the first name of the client.
  • the email address of the client is the email address of the client.
  • the home phone number of the client The home phone number of the client.
  • a cross reference id to the client id used in the client package which represents the responsible family member for the client. This can be null and is usually used when the client is a child and the responsible family member is a parent.
  • the service provider data 408 can include, for example, the following fields:
  • a cross reference id to the service provider id used in the client package is
  • the first name of the service provider is the first name of the service provider.
  • the account id (clinic) of the service provider The account id (clinic) of the service provider.
  • the bridge 104 may send the service provider data 408 again only in order to add information about a new service provider not previously sent or to update information about the previously transmitted service provider "Sn".
  • appointment data 406 sent as part of data package 404 can include, for example, the following fields:
  • a cross reference id to the service provider id used in the client package is
  • the batch number of the appointment This is used to determine if future appointments not sent within the latest batch of appointments should be deleted.
  • TOR_LAW ⁇ 65 42311 ⁇ 1 A flag (i.e. a DoNotCall flag) indicating if reminders should be generated for the appointment.
  • a type id for the appointment This allows for future categorization of appointments. Current values include "normal” and “recall”.
  • the contents of the data package 404 including the fields contained within each of the data 406, 408, and 410 may vary at each stage of the system 100.
  • the transmission and manipulation of the data package 404 will be discussed further with reference to each of the bridge 104 and the server 110.
  • the bridge 104 may be implemented as a standalone unit such as the bridge proxy server 104b or alternatively, the bridge 104 may be implemented as an application program, such as bridge 104a loaded onto the corresponding scheduling device 102.
  • the scheduling devices 102 connected thereto do not include the bridge 104a application program.
  • the bridge 104 is implemented as the bridge application program 104a on a scheduling device 102 having a series of executable instructions 238 installed on the scheduling device 102, then the scheduling device 102 and the local bridge 104a are connected directly to the server 110 via the network 106.
  • executable instructions could be hard-coded (e.g. logic device), soft-coded (e.g. software), or a combination thereof.
  • the bridge 104 comprises a series of executable instructions 238, an upload module 234, a download module 236, the number of configuration settings 232a, and the filter module 230 discussed earlier.
  • the upload module 234 of the bridge 104 has the capability to obtain the data package 404a including the appointment data 406 from the database 210 or other storage of the scheduling device 102.
  • the configuration settings 232a determine the communication protocol used by the upload module 234 and the download module 236 to communicate with the database 210 and the scheduling device 102.
  • the configuration settings 232a define the time intervals at which the communication between the bridge 104 the scheduling device 102 and the server 110 occurs.
  • the upload and download times occur at separate time instances.
  • the configuration settings 232a may define that the upload module 234 uploads the data package 404a at every 30 seconds while the download module 230 downloads data to the scheduling device 102 every 30 minutes.
  • the upload module 234 may be configured to upload the data package 404a substantially simultaneously rather at set time intervals such that it is almost immediately aware of updates to the scheduling devices 102.
  • the download module 230 may be configured to download data to the scheduling device 102 substantially instantaneously.
  • the upload module 234 receives the data package 404a it communicates the data package 404a to the filter module 230 which is configured to filter the data package 404a contents according to the filter settings in order to generate the data package 404b (e.g. which includes client data 410, service provider data 408 and appointment data 406) across the network 106 to the server 110.
  • the server 110 uses the appointment data 406 within the data package 404b for generation of the notification reminders 506 to the client and then once the notification response 507 is received from the client, the server 110 translates the response data into native language for the scheduling device 102.
  • the bridge's download module 236 is then configured to download the notification package 504 from the server 110 (according to the configuration settings 232).
  • the download module 236 further communicates the notification package 504 including the response data back to the associated database 210 of the scheduling device 102, in order to update the stored data of the data package 404a.
  • the notification package 504 is indicative of the appointment confirmation/response information received from the client devices 108 in response to the reminders 506.
  • the operation of the bridge 104 is discussed in detail below.
  • the bridge 104 installs (e.g. on the scheduling device 102) as a Microsoft Windows Installer package (MSI).
  • MSI Microsoft Windows Installer package
  • the installation displays a license agreement page and allows
  • TOR LA W ⁇ 054231 IM the installer to select the directory to be installed. Once installed, the installer runs a script (installservice.cmd) included within the executable instructions 238 to register the service and create the event log source "PromptAlert" in the Windows event viewer. The script also sets the event viewer category to overwrite events as needed.
  • installservice.cmd included within the executable instructions 238 to register the service and create the event log source "PromptAlert" in the Windows event viewer.
  • the script also sets the event viewer category to overwrite events as needed.
  • configuration settings 232a are defined to allow the bridge to operate as needed by the server 110.
  • the configuration settings 232a define the operation of the upload module 234, the download module 236 and the communication between the bridge 104 and the connecting components such as the one or more scheduling devices 102 and the server 110.
  • the configuration settings 232a may include information about the database 210 for the corresponding scheduling device 102.
  • the database 210 stores the relevant service provider data 408, appointment data 406, and client data 410 as communicated from a scheduling application program/ executable instructions 224.
  • the configuration settings 232a may include information about the database 210 type, the connection protocol required for communication to the database 210 (as required for communication from the upload module 234 or the download module 236 to the database 210).
  • the bridge 104 XML file is located in the install directory specified during installation of the bridge 104 and provides default values for the configuration settings 232a.
  • the server 110 also includes a set of customizable configuration settings 232b stored thereon.
  • the configuration settings 232b stored on the central server 110 are account specific such that they can be updated by a user of the website customization service 116 (i.e. a dentist, a service provider or an administrator of one or more scheduling devices 102).
  • the configuration settings 232b may be updated by the scheduling device 102 connected to the website customization service 116 via the network 106.
  • the service provider may use a user interface 202 of the scheduling device 102 to modify the configuration settings 232b via the website customization service 116.
  • the admin user interface 114 may be provided to allow direct modification of the configuration settings 232b on the server 110.
  • the configuration settings 232b once defined for a particular account (i.e. service provider /scheduling device 102/ database 210) and stored on the server 110, may be communicated to the bridge 104 for defining some of the values in the configuration settings 232a not previously defined and for overwriting certain generic default values.
  • the configuration settings 232a, and 232b are referred to generally as configuration settings 232.
  • appointment datetime values are based on the scheduler instructions/application package 224 since each scheduler application package 224 stores appointment date and time differently.
  • the bridge 104 comprises the upload module 234.
  • the upload module 234 is responsible for receiving the data package 404a containing the service provider data 408, the client data 410, and the appointment data 406 from the scheduling device
  • TOR_LAW ⁇ 6S423i m 102 and for transmitting a filtered version of the data package 404a (i.e. in the form of data package 404b) to the server 110.
  • the filtering of data is facilitated by the filter module 230 provided by the bridge 104.
  • the operation of the upload module 234 with respect to the scheduling device 102 and the server 110 is defined by the configuration settings 232 described above.
  • the upload module 234 of the bridge 104 first loads in the local configuration settings 232a defined during installation of the bridge 104.
  • the server 110 has loaded thereon a number of customizable configuration settings 232b which may have been customized through the website customization service 116 (via the updates 117) or through an admin user interface 114.
  • the configuration settings 232b are transmitted to the bridge 104. For example, this may be facilitated via a web service call to the server 110. As described earlier, this allows for configuration changes for the service provider account to be made on the server 110 and to propagate to the bridge 104.
  • the server defined configuration settings 232b are then loaded onto the bridge 104 and override the local configuration settings 232a.
  • the upload module 234 then replaces the token date in the AppointmentSQL with the last transmission date for the bridge 104.
  • the last transmission date is used to store the date of the last successful transmission to the server 110. This information which is stored in the configuration settings 232 allow the upload module 234 to determine which appointment data 406 to upload to the server 110 such that the appointment data 406 uploaded is current.
  • the upload module 234 uses the DatabaseProvider setting stored in the configuration settings 232 to determine if the client is using OLEDB, ODBC, or another database connection. Based on this value, the upload module 234 applies an SQL query against the database 210 via the scheduler 224 to determine a list of appointment data 406, service provider data 408 and client data 410 to receive from the scheduling device 102. Alternatively at step 612, the scheduling device 102 transmits the data package 404a containing client data 410, appointment data 406 and service provider data 408 to the bridge 104.
  • the upload module 234 receives the data package 404a and filters the data package 404a according to the filter module 230 settings in order to generate the data package 404b for subsequent transmission to the server 110 at step 616.
  • the frequency of upload of the data package 404b to the server 110 is determined by the value stored in the ServerUploadlntervallnMinutes.
  • the upload module 234 may upload data package 404b to the server 110 at predefined intervals.
  • the upload module 234 may be configured to transmit data package 404a each time there is new information relating to I appointment data 406/client data 410/ service provider data 408 stored on the database 210.
  • the update may be transmitted substantially simultaneously to the server 110.
  • this may be implemented by configuring the "ServerUploadlntervallnMinutes" to real-time such that the upload to the server 110 occurs almost immediately.
  • the filter module 230 may be configured to provide a series of rules which determine which components of the appointment data 406/ client data 410/ service provider data 408are transmitted as part of data package 404b.
  • the following description provides some examples of filtering rules that may be used within the filtering module 230.
  • the upload 5 module 234 uses the filter module 230 to remove any service providers (as defined in the service provider data 408) or clients (as defined in the client data 410) which are not referenced in the list of appointments provided by the appointment data 406. In this case, if there are service providers "Sn” or clients "Cn” which have no appointments "An” linked to them then there is no reason to upload the particular service provider data 408 or client data 410.
  • the filter module 230 may be configured with filter settings which remove stale appointments which have expired, or unchanged appointments. In this case, if the appointment data 406/client data 410/service provider data 408 remains unchanged since previous transmissions then the appointment data 406/client data 410/service provider data 408 is not transmitted again to the server 110.
  • the filter module 230 detects the value of the flag and removes the particular client data 410 and associated appointment data 406 from the data package 404b prior to transmission to the server ) 110.
  • a count of the number of total rows to upload to the server 110 is determined and the information is uploaded to the server 110 via the upload module 234 across the network 106. This count of number of rows is passed by the bridge 104 as a checksum value for the server 110 to perform
  • the upload module 234 may also transmit an account security token to the server 110 that may be defined in the configuration settings 232 and for substantially immediate verification by the server 110 prior to processing of the data package 404. Additionally, the upload module 234 may be configured to encrypt all communications including data package 404 via SSL prior to
  • the server 110 may be configured to transmit acknowledgement of successful transmission of the data package 404.
  • the upload module 234 is further configured to update the last transmission date and time stored in the configuration settings 232 and the connection to the database 310 may then be closed.
  • the last transmission date stored within the configuration settings 232 may be used by the bridge 104 to determine which appointment related data has not been communicated yet.
  • the bridge 104 further comprises a communication module 235.
  • the communication module 235 is configured to communicate with the server 110 and to provide the filtered data package 404b to the server 110.
  • the upload module 234 is configured to receive the data package 404a from the database 210 via the scheduler 224. As described above, prior to this upload, the upload module 234 detects the communication protocols as defined in the configuration settings 232. Once the upload module 234 receives the data package 404a from the database 210, then the upload module 234 cooperates with the filter module 230 which removes unnecessary data from the data package 404a to generate the data package 404b.
  • this unnecessary data can include for example, stale data, unchanged data, or data not required for generating the notification reminder 506.
  • the data package 404b is then forwarded to the communication module 235 which is configured to communicate with the server 110 and transmit the data package 404b to the server 110 for subsequent generation of the notification reminders 506.
  • the download module 236 of the bridge 104 facilitates downloading of responses (received in the form of the notification package 504) to notification reminders 506 generated at the server 110 and containing information about a particular appointment and corresponding client.
  • the download module 236 processes the notification package 504, it applies the response (i.e. confirmation type, appointment related data) to the database 210 associated with scheduling device 102. Similar to the upload operation, the operation of the download module 236 is defined by the configuration settings 232.
  • the download module 236 is thus configured to receive client responses to automated appointment reminders for the client via the notification package 504 sent from the server 110.
  • the client responses referred to as notification responses 507 can include for example, appointment confirmation and appointment activity information obtained from the client device 108.
  • the download module 236 is further configured to process the results received in the notification package 504 and update the database 210 accordingly. Similar to the upload operation, in the download operation of the download module 236, the local
  • TOR_LAW ⁇ 6542311 ⁇ 1 configuration settings 232a are synchronized with those of the server-defined configuration settings 232b.
  • the download module 236 establishes a connection to the database 210.
  • the "Startlnterval" and “Endlnterval” stored in the 5 configuration settings 232 are examined by the server 110 to determine the list of confirmed appointments to report back to the bridge 104 via the notification package 504.
  • the range will be from the current date/time less the Startlnterval in hours to the current date/time plus the Startlnterval in hours. Thus, only appointments which have been confirmed (and related activity) are reported back to the bridge 104.
  • the confirmed appointments and activity transmitted via the notification package 504 are then downloaded to the bridge 104 for further processing.
  • the notification package 504 received includes, for example, the confirmation SQL and the client appointment id which was confirmed.
  • shown is an example notification package 504 which comprises one or more of appointment data 406 in native i language; client data 410 in native language; service provider data 408 in native language; and notification responses 507 in native language.
  • the download module 236 iterates through all the appointments received in the notification package 504 and applies the confirmation SQL or other forms of notification responses contained therein to update the database 210. Further, the download 1 module 236 is configured to iterates through all the client activity received in the notification package 504 and applies the activity SQL (or other native language) to update the database 210. The result is that the corresponding scheduling device 102 and the scheduling application/executable instructions 224 will then show the appointment as confirmed and display the reminder activity/response to the appointment notification on the user interface 202, if this feature is supported by the client application.
  • a confirmation (i.e. via an acknowledgement message 713) is sent to an acknowledgement processing module 711 of the server 110 at step 634 (i.e. via the communication module 235).
  • the acknowledgement i.e. via an acknowledgement message 713
  • TOR_LAW ⁇ 6 5 4231 1 ⁇ 1 processing module 711 marks the confirmation notification package as applied within the activity table 709 of the server 110. For example, a list of all appointments (this can be in the form of appointment data 406) which were updated is sent back to the server 110 via the communication module 235. This allows the server 110 to update the configuration settings 232 (i.e. flag that the client is confirmed for the Appointment and ReminderAudit tables for the corresponding reminder).
  • the upload module 234 of the bridge 104 is configured to communicate with the download module 236 prior to transmission of appointment related data via the data package 404 to the server 110.
  • the download module 236 may have received a notification package 504 from the server 110 for processing which includes status updates (i.e. confirmation of a particular appointment for a corresponding client and service provider).
  • the download module 236 may further comprise a queue of status of appointment related data for processing.
  • the upload module 234 may also comprise a queue for processing of the appointment related data prior to transmission to the server 110.
  • the upload module 234 may check the queue or other storage means of the download module 236 to verify that the data package 404 has not yet been confirmed (or other reminder activity not yet received) via notification package 504. If the data package 404 contained in the queue of the bridge has been confirmed then the data package 404 is removed from the queue of the upload module 234 prior to transmission to the server 110.
  • the bridge proxy server 104b comprises a network connection interface 300, a user interface 302, coupled to the device infrastructure 304 by connection 318, 322 respectively.
  • the device infrastructure 304 further comprises one or more computer processors 308 and can include an associated memory 310.
  • the device infrastructure 304 can include a computer readable storage medium 312 coupled to the processor 308 .
  • the bridge proxy server 104b comprises executable instructions 238, filter module 230, upload module 234, download module 236, and configuration settings 232a coupled to the device infrastructure via 320. It will be understood by a person of ordinary skill in the art, that components 300, 302, 304, 308, 310, 312, 318, 320 and 322 discussed in reference to Figure 3
  • TOR_LAW ⁇ 654231 IM are similar components and devices as corresponding components 200, 202, 204, 208, 210, 212, 218, 220 and 222 discussed in reference to Figure 2.
  • the bridge 104 is a generic bridge configured to communicate with different types of databases 210 and scheduler applications 224.
  • the configuration settings 232a can predefine the type of database 210 and the scheduler application 224 used (as well as the required communication protocol) such that the bridge's upload module 234 and download module 236 are configured for communication to the scheduling device 102.
  • the types of database connections may include ODBC", "OLEDB”, ProxyTimeout among others as will be understood by a person skilled in the art.
  • FIG 801 shown is a block diagram of the scheduling device 102 further comprising a database manager 801.
  • the scheduler application 224 then passes the notification package 504 containing the response data (in the native language of database 210), to the database manager 801 for subsequent application of the response data in native language to the database 210.
  • the bridge 104 may be configured to communicate directly with the database manager 801 and provide the notification package 504 for subsequent application to the database 210.
  • the website customization service 116 provides the interface for customizing the notification reminders 506 (i.e. via customization of the templates 508) and/or customization of the configuration settings 232 in the form of the website update package 117 adapted to be subsequently applied to the server 110 and/or the bridge 104.
  • the website customization service 116 further provides an interface for a user to schedule new appointments and/or modify existing appointment information including deleting existing appointments (see Figure 7).
  • the website customization module 116 may be configured to provide a copy of the database 210 corresponding to a scheduling device 102 such that a user accessing the website customization service 116, is able to view the current status of one or more appointments for a corresponding service provider 408 associated with the scheduling device 102 and
  • TOR LA W ⁇ 054231 IM accordingly request a new appointment and/or change an existing appointment information.
  • the new appointment and/or changes to existing appointment information are transmitted to the server 110 via the website update package 117.
  • the update package 117 containing the updated appointment information is then received at the processing module 708 which encapsulates the update package 117 in the form of the notification package 504 and transmits the notification package 504 to the bridge 104.
  • the download module 236 of the bridge 104 receives the notification package 504 comprising the requested new appointment/change of appointment information it applies the update to the corresponding database 210. Further, similar to the processing of reminder responses obtained via the notification package 504, the download module 236 is configured to generate a positive/negative confirmation about the application of the new appointment/ modified appointment information received via update 117 to the database 210. For example, referring now to Figures 6 and 7, in the case where the download module 236 determines that the update can't be applied (i.e.
  • the download module 236 generates a negative acknowledgement message 713 and communicates this to the communication module 235.
  • the communication module 235 is configured to communicate the acknowledgement message 713 to the server 1 10.
  • the acknowledgement processing module 711 then receives this acknowledgement message 713 and forwards it to the website customization service 116 for subsequent display to the user.
  • a positive acknowledgement message 713 is reflected on the website customization service 116 via the server 110.
  • a user can update/modify(e.g. delete)/add new appointment related information (i.e. modify a patient's contact information) via the website customization service 116 and the result is then verified to the user via the acknowledgement message 713 transmitted to the website customization service 116.
  • the central server 110 is configured to process the data package 404 containing appointment related data for particular clients and service providers and
  • the central server 110 further comprises a notification generation module 702 for processing the data package 404b and generating the notification reminders 506 in accordance with the processed data package 404b.
  • the central server 110 further comprises customizable/predefined templates 508 for use by the notification generation module 702 in generating the text/voice to be used in the notification reminders 506 for the client's device 108.
  • the voice or SMS or SMTP gateway 112 receives responses to the reminders 506 sent to the clients and forwards the notification responses 507 to the central server 110.
  • the central server 110 further comprises a processing module 708.
  • the processing module 708 may be configured to process update packages 117 (e.g.
  • the processing module 708 is configured to process responses to reminders (e.g. a confirmation of an appointment reminder received via notification responses 507).
  • the processing module 708 processes the notification responses 507 received and generates the notification package 504 that is specific to the scheduling device database 210 using an interpreter module 710 coupled thereto.
  • the notification package is subsequently transmitted to the bridge 104.
  • the notification generation module 702 first verifies the passed security token received from the bridge 104 against the value stored in the notification generation module 702. If the tokens match, then the central server 110 accepts receipt of the data package 404.
  • the notification generation module 702 performs preprocessing of the received data package 404 prior to generating the notification reminders 506. For example, in the case of back-to-back appointments, the notification generation module 702 identifies the client's first appointment in a day as the only appointment requiring communication. All notifications for later appointments in the same day are held (i.e. no new notification reminders 506 are generated) and inherit the confirmation status of the first appointment in the activity table 709. While importing the data package 404b from the bridge 104, the notification generation module 702 flags same-day appointments if they are created/modified within a pre-determined period prior to appointment notifications and they are assumed to be confirmed based on the small period of time between the booking and the actual appointment.
  • the notification generation module 702 receives a data package 404 where the event data 406 applies to more than one persons (e.g. associated with more than one client 410). In this case, the notification generation module 702 flags the data package 404 so that more than one reminder is generated via the notification reminders 506, each generated notification reminder 506 being transmitted to the one or more persons associated with the event 406. For example, considering the scenario where a scheduled event such as a fire drill, or
  • the data package 404 contains the event data 406, and the client data 410 includes identification of the number of clients associated with the event.
  • the notification reminders 506 are generated by the notification generation module 702, each corresponding to the number of clients.
  • the notification generation module 702 flags multiple appointments for the same family and groups them according to their contact phone number. If a number is due to be called multiple times for separate appointments, the notification reminders 506 are concatenated into one 'parent' call. Thus the appointments for concatenated notifications inherit the confirmation status of the 'parent' appointment in the activity table 709.
  • This method is passed the "OffsetHours" as a parameter.
  • the logic loops through all appointments within OffsetHours hours of the current date/time and checks if there is another non-deleted appointment with the same client, account, year, month, day and later in the same day. If a later appointment exists which matches the same criterial, the task kills the reminders for the later appointment and sets the "B2BApptId" values to the current (parent) appointment. The result is that only one reminder will be sent to the client for the back to back appointments they have scheduled during the same day.
  • Same Day Appointment Appointments booked or changed close to the actual date of the appointment are considered to be pre-confirmed by nature. When these types of appointments are transmitted across the bridge 104, they are classified as 'sameday' and no reminders are generated or sent out for this appointment. Each account has a value on the account table called "SameDaylnternalHours" If the appointment is within SameDaylnternalHours hours of the current date/time, the appointment is considered a SameDay appointment and flagged as such on the appointment table. No reminders are generated for "SameDay” appointments as they are presumed to be confirmed based on their proximity to the actual event.
  • Family calling is the method in which it is determined whether to confirm all appointments for all family members in one call or separate calls. Enabled on a per account basis, the Family Calling scheduled task runs through all scheduled voice calls in the next few days. The number to call is examined for each reminder. If more than one reminder is due to be sent to the same phone number for appointments on the same day, the first appointment timewise is considered to be the 'Parent'. All reminders for appointments later in the day are killed. I.e - "I'm calling to remind Patient 1, Patient 2 AND Patient 3 of their.. (Patient 1 is the parent appointment, the reminders for Patient 2 and Patient 3 were killed and their names added to the reminder for Patient 1).
  • TORJ.AW ⁇ 6 5 42311 ⁇ 1 generated. In this case, if a reminder is being generated which should have been sent out a week before the reminder was generated, it will not be generated.
  • the notification generation module 702 further comprises a scheduler 707 and a scheduler table 706 for determining when the notification reminders 506 should be transmitted to the client devices 108 in accordance with the account specific information (i.e. client/service provider/scheduling device 102 specific requirements) stored in the scheduler table 706.
  • the scheduler table 706 may contain predefined or default values therein. However, the scheduler table 706 values may also be customizable via the website customization service 116. For example, a client/service provider may have specific predefined call times associated therewith for contact via email, SMS or voice calling.
  • call times may further be manipulated by the scheduler 707 to account for time zone changes and the scheduler 707 may also overwrite the call times defined in the scheduler table 706 based on the account specific statistics obtained in the activity table 709. That is, if the scheduler 707 determines, based on analyzing the success/failure information stored in the activity table 709 that a particular time slot has had success in reaching one or more clients, then the scheduler 707 may modify the scheduler table 706 to overwrite existing call times for the one or more clients with those times having a higher success rate.
  • templates 508 are used to store a series of predefined and/or customizable text/voice templates which facilitate the generation of notification reminders 506 via the notification generation module 702.
  • the notification generation module 702 receives the data package 404b and determines the time for sending out the notification reminder 506 for that data package 404b according to the scheduler 707 then the notification generation
  • module 702 applies one or more of the templates 508 which are specific to the client/service provider associated with the data package 404b. For example, for e-mail and SMS messages, 15 minutes prior to the notification send time, the client details (name/appointment date time) provided in the data package 404 are merged with the message template 508 text for the account to generate the notification reminders 506.
  • TOR_LAW ⁇ 6 5 42311 ⁇ 1 In order to generate notification reminders 506 using voice reminders, a voice template 508 is used and merged with the appointment related data.
  • the voice template 508 is account specific for the specific client and/or service provider.
  • the notification reminders 506 are then placed within the queue 704 for subsequent transmission to the client devices 108 in accordance with the times determined by the scheduler
  • the module 708 may further be configured to store the client activity and reminder responses in the activity table 709 for later access by the central server 110 and for tracking of status of notification responses 507.
  • the activity table is further divided into other tables such as a reminder table for storing responses to text-based messages (e.g. email, SMS) as well as voice call audit tables for storing responses to voice-based notification reminders 506.
  • the interpreter module 710 coupled thereto is further configured to translate the notification responses 507 stored in the activity table 709 into the native language associated with the database 210 of the scheduling device 102.
  • This translation of the notification response 507 in the native language of the database defines the format of the notification package 504 that is transmitted to the bridge 104.
  • the notification package 504 contains the status of appointment and/or the contact activity details relating to the interaction of the client in response to receiving the notification reminder 506.
  • the interpreter module 710 accesses a client update table 720 which stores generic and/or account specific (e.g. defined by service provider/client information) SQL update statements that are in the native language of the scheduler database 210.
  • the SQL update statements include statements for the various types of client confirmations/detected client activity related to an appointment. That is, the client update table 720 further comprises status update codes 722; and activity update codes 724.
  • the status update codes 722 define the SQL statement for confirmation related activity, such as but not limited to: client confirmation of appointment; and client rejection of appointment information.
  • the activity update codes 724 define the SQL statement for confirmation related activity, such as but not limited to: client confirmation of appointment; and client rejection of appointment information.
  • TOR_LAW ⁇ 6 5 4231 1 ⁇ 1 may define the SQL statements for other types of activity detected from the client, such as but not limited to: number busy, no answer, call hangup, answering machine-dropped call, delivered to answering machine; and call was answered by human but they didn't respond to prompts- reschedule call.
  • the status and activity update codes 722 and 724 may be combined so as to generate a single SQL statement based on the notification response 507.
  • the interpreter module 710 then converts the appointment related information and response contained in the notification response 507 to the appropriate SQL statements (via the update codes within the client update table 720) and forwards them to the processing module 708 for transmission to the bridge 104. This may be done by substituting the notification response 507 values stored in the activity table into the SQL templates defined by the status and/or activity update codes 722, 724 to define the notification package 504. In this manner, the notification package 504 contains SQL statements indicative of the response/activity received from the client in the native language of the database 210 such that once the notification package 504 is passed from the server 110 to the bridge 104 it can directly be applied to the database 210 of the scheduling device 102.
  • the interpreter module 710 examines the notification response 507 stored in the activity table, retrieves the corresponding status and/or activity update codes 722, 724 and provides the combination of the SQL template provided in the form of codes 722, 724 and the ) notification response 507 to the bridge 104.
  • the bridge 104 then substitutes the values provided by the notification response 507 into the corresponding codes 722, 724 and applies the updated SQL statement to the appropriate corresponding scheduling device database 210. Examples of this operation are further discussed below.
  • the account is setup within the system 100 by providing the account with a number, a security token which is used to secure information as well as an identifier indicating the type of client package (e.g. local bridge 104a and/or database 210 on the client's scheduling device 102) that the client is running. This will allows the system 100 (e.g. the server 110) to determine the appropriate SQL template to use to retrieve and update client information.
  • a security token which is used to secure information as well as an identifier indicating the type of client package (e.g. local bridge 104a and/or database 210 on the client's scheduling device 102) that the client is running.
  • This will allows the system 100 (e.g. the server 110) to determine the appropriate SQL template to use to retrieve and update client information.
  • the account is configured for a set of reminders and a call template (e.g. notification reminders 506 generated using template 508).
  • the reminder metadata indicates what reminders should be generated for appointments for the account and at what interval prior to the appointment the reminder should be send.
  • Possible reminder types include but are not limited to are email, SMS (Text Message to Cellular Phone), voice call, fax or Instant Message.
  • the bridge (e.g. bridge 104) is installed on one of the PC's (e.g. scheduling device) in the account's office.
  • the bridge transmits appointment, service provider and client information (e.g. via data package 404 transmitting service provider data 408, appointment data 406, client data 410) to the server 110 to enable the server 110 to send reminders to account clients.
  • the bridge also updates the account package database (e.g. database 210) with confirmation and activity information based on reminder activity within the server 110.
  • An appointment is created for a client.
  • the appointment can be created in the system (e.g. scheduling device 102) through a variety of means including entered by a client at the account office, calling the receptionist at the account office or electronically via an external appointment scheduling facility.
  • the client provides their relevant contact information including e-mail address, cell phone and phone contact information (e.g. client data 410). If any of the information is not available, the client reminder for this type of notification will not be sent and an audit log entry (e.g. activity table 709) in the server 110 will be generated to explain why the reminder was not sent.
  • the bridge (e.g.104) connects to the client package (e.g. scheduling device 102) and extracts a list of all appointments, clients and service providers. The system then determines
  • TOR_LAW ⁇ 6542311 ⁇ 1 what clients and service providers are required to send based on the appointment list and filters (e.g. via filter module 230) the client and service provider list to exclude clients and service providers who do not need to be sent to the server 110.
  • the list of filtered information might include appointments which are no longer active or appointments which do not require confirming.
  • the list of appointments and filtered list of service providers and clients are uploaded to the server 110. Newly created appointments are included in this list.
  • the appointment, client and service provider information is applied to the server 110. In each case, if the appointment, client or service provider does not exist, they are added to the system. If the entity already exists, the information is updated.
  • the schedule for the reminders is based on the account settings (e.g. as defined within the scheduler table 706) as noted in the "Appointment Booking" section above.
  • a sample schedule could be:
  • the appointment would generate 4 reminders (e.g. notification reminders 506) with each reminder being sent out at the specified interval before the ) appointment.
  • reminders e.g. notification reminders 506
  • body of the message is defined in a template (e.g. templates 508).
  • the template is the generic version of the message without any appointment specifics.
  • An example of this generic template is :
  • TOR_LAW ⁇ 65423H ⁇ 1 Minutes before the message is due to be sent out, the generic message body template is merged with the appointment specific information to create the final message text. If a client has not provided accurate contact information (e.g. An email address for email reminders, a cellular phone number for SMS reminders or a valid phone number for voice calls), the reminder will not be sent and a note will be added to the audit logs (e.g. activity table 709) to indicate that the reminder was "killed” and the reason why.
  • accurate contact information e.g. An email address for email reminders, a cellular phone number for SMS reminders or a valid phone number for voice calls
  • the email message (e.g. via notification reminder 506) is sent 7 days before the appointment.
  • the email text contains two hyperlinks at the bottom of the message. The first link allows the client to add this appointment to their local calendar application. The second link allows the client to connect back to the server 110 and acknowledge receipt of the reminder e-mail (e.g. via notification response 507).
  • the body of the message is based on template text as earlier described.
  • the voice call (e.g. via notification reminder 506) is sent out 2 days prior to appointment.
  • the voice calling system is capable of handling all possible outcomes from the voice call - i.e. no answer, busy signal, no response from client, answered by an answering machine etc. Regardless of the outcome, the result is recorded and later applied to the office scheduling package (e.g. database 210).
  • the server 110 determines whether the voice call result was sufficient to consider sending of this reminder completed or if another call needs to be sent out later. For example, if a client confirms the appointment, the voice calling should be considered completed for this reminder. Conversely, if there is no answer or the client requests a callback at a later time, the voice call is rescheduled into the future.
  • the ultimate determination of a calls success and corresponding actions are specific to each account. As illustration of this point, accounts may request that an answering machine be considered the final result while other accounts request that this result type be re- attempted later in hopes of attaining a human recipient.
  • the client can reply to the SMS message to indicate a response such as "I will be there". This response is received by the server 110 and forwarded to the account office (e.g. scheduling device 102).
  • the account office e.g. scheduling device 1012.
  • TOR_LAW ⁇ 6 542311 ⁇ 1 When a reminder is sent the specific information about this reminder (e.g. notification response 507) is written to the ReminderAudit table (e.g. Activity Table 709). This table is used to determine whether appointments have been confirmed and to report on client activity.
  • the ReminderAudit table e.g. Activity Table 709
  • Updates to ReminderAuditTable e.g. Activity Table 709
  • Email Reminders when an email is successfully sent, a row is written to the
  • Voice Calls all voice calls are scheduled based on a timetable per account (e.g.
  • the timetable is made up of a sequence of calling times in which a reminder is called.
  • An example of this timetable could be:
  • a voice call executes a calling script (e.g. using template 508) which calls the client on their voice contact number and solicits a response. All possible outcomes are anticipated and assigned a 'result code' within the call script.
  • TOR_LAW ⁇ 6542311 ⁇ 1 outcome is returned to the server 110 as a result code.
  • Possible result codes include but are not limited to:
  • VoiceCallAudit table (e.g. Activity Table 709) which logs all voice call results. The system next looks up the result code to determine which of the following attributes should be applied to the call. These attributes are specific to each result code and determine how the call should be handled.
  • the voice call is added to the Reminder Audit table. Examples of when a call is not an attempt include processing issues, all circuits busy etc. If another calls needs to be placed, the next time to calls is determined based on the account specific calling schedule. The server 110 maintains a minimum and maximum daily call time per account (e.g. as defined by Scheduler Table 706). If the next call time is past
  • the next voice call time is set to the first available call time for the next day.
  • the server 110 keeps track of number of attempts and maximum voice contacts per account client. If the number of voice contacts for this appointment exceeds the maximum voice contacts per account client, the MaxContactsExceeded flag is set for this reminder in the reminderaudit table (e.g. Activity Table 709) and no further calls will be placed for this reminder.
  • the reminderaudit table e.g. Activity Table 709
  • Updates to the account package database e.g. database 210
  • the ClientUpdateConfig table (e.g. Client Update Table 720) stores information based on the account and the ClientUpdateCode from the ResultCode table.
  • the ClientUpdateConfig table (e.g. Client Update Table 720) contains two pieces of information: should the call be considered a confirmation of the appointment and the SQL template ("ConfirmSQL") (e.g. status update codes 722 and/or activity update codes 724) needed to update the account package (e.g. database 210) with this call activity.
  • the bridge (e.g. 104) sends this call activity to the account package (e.g. database 210) by substituting the call values into the SQL template and applying the SQL to the account package database (e.g. database 210).
  • the bridge 104 then applies the appropriate update SQL statements to the local database.
  • the server 110 provides the generic SQL statement and values for populating the SQL statement (as defined by the reminder notification responses 507 stored in the activity table 709) to the bridge 104.
  • the bridge 104 then combines the SQL statement and values for applying to the corresponding database 210.
  • the interpreter module 710 applies the SQL templates contained within the Client Update Table 720 to the received reminder response (e.g. as stored in the activity table 709) and thereby generates a corresponding SQL statement containing the reminder response as provided to the bridge 104 via the notification package 504.
  • the bridge 104 applies the notification package 504 containing the update SQL statement directly to the database 210.
  • appointment activity and appointment state information are applied to the account package database (e.g. database 210).
  • the confirmation flag stored in the account package (e.g. database 210) is also recorded (e.g. via acknowledgement processing module 711 uploads the confirmation flag and updates the activity table 709) to ensure that the confirmation values between the two systems are kept in sync.
  • the client manually confirms an appointment within the office (e.g. via the scheduling device 102) of the account by calling in directly, the confirmation flag for the appointment will be set in both systems, preventing the appointment from being confirmed twice.
  • activity details are recorded in the account scheduling package (e.g. database 210 of scheduling device 102).
  • the details of how to update an account scheduling package are specific to each account and are stored in a table (e.g. as defined by client update table 720). Every reminder outcome has a link to a corresponding, account specific update string (e.g. status update codes 722 and/or activity update codes 724) which is applied to update the scheduling package.
  • the package update language would be responsible for updating the status of the appointment as well as entering the details of how it was confirmed (e.g. defining details of the communication interaction with the client upon providing the notification reminder to the client) in the appointment communication log (e.g. database 210).
  • the following code could be used to confirm the appointment and provide a status update:
  • values for variables prefixed with $Variable represent the identifier used by the local scheduling database (e.g. database 210) to refer to the appointment identifier we are confirming.
  • the appointment identifier may include '23456' which identifies the particular appointment within the service provider's list of appointments.
  • INSERT INTO COMMLOG PATNUM, COMMDATETIME, COMMTYPE, NOTE, MODE, SENTORRECEIVED, EMAILMESSAGENUM
  • VALUES CSCIientld 1 STR_TO_DATE('$SentDateTime', '%m/%d/%Y %l:%i:%s %p'), '2', 'PromptAlert - Confirmed via Human Response 1 , '3','1 ', 1 O 1 )
  • the SQL is applied to the account database by the bridge 104.
  • the Clientld may be replaced with '9876'; and the SentDateTime may be replaced with '2007-01-01-12:30:00.000'.

Abstract

There is provided a server for processing event related information of a scheduler application, the event related information including identification data of a client and event data corresponding to the client, the system comprising: a memory for storing a plurality of update codes corresponding to the scheduler application, the update codes defining a format of a notification package in a native language of a database of the scheduler application; a generation module configured for receiving the event related information from a scheduler interface and configured for generating a notification reminder message according to a defined message timing, the notification reminder message including the event data and client contact data associated with the client identification data, the notification reminder message configured for sending according to the client contact data over a communications network for receipt by the client; a processing module configured for receiving notification response information in response to the notification reminder message; an interpreter module configured for generating the notification package including the notification response information and an update code selected from the plurality of update codes, the update code corresponding to the notification response information, the notification package configured for sending to the scheduler interface.

Description

SYSTEM AND METHOD FOR GENERATING AUTOMATED REMINDERS
FIELD OF THE INVENTION
[0001] The present invention relates generally to a system and method for processing and updating event related information and specifically to using automated reminders for updating the event related information.
BACKGROUND OF THE INVENTION
[0002] With over 700,000 physicians conducting business in the U.S. alone, the market is ever expanding. The adoption of Electronic Medical Records (EMR) is growing every day as physicians new and old begin to realize the potential cost savings capable by adopting electronic management tools. In conjunction with the cost savings, EMR systems also allow healthcare providers to maintain centralized patient care records which are accessible in real-time from disparate sites. The standardization of information flow between healthcare providers is causing Federal governments to mandate the adoption of EMR systems. Physicians are increasingly starting to understand the benefits of electronic systems, and are looking for additional ways to leverage their investment.
[0003] A challenge faced for health care systems is patients are very busy people and the traditional 9-5 office hours are no longer sufficient to effectively service a 'round-the-clock' population. The healthcare industry is on the verge of a technological revolution. The declining cost of technology and its increasing ability to further healthcare is creating a lucrative niche market for companies with the foresight to assist. Research has shown that 35% to 45% of patients in the U.S. fail to attend scheduled physician appointments. Even using modest figures, the ability to decrease this 'no-show' rate is a niche 99 billion dollar industry in the United States alone. Traditional methods to address the problem are labor intensive, consuming the valuable resources of a physician's busy practice.
[0004] It is further noted that these challenges while discussed in relation to the healthcare industry, are also commonly faced within other industries such as education, financial services, legal services, insurance, and business services where there is a need for databases containing
TOR_LAW\ 6542311\1 event and task related information (i.e. appointments and meetings with clients) which need to be maintained, updated and/or confirmed.
[0005] Problems associated with current state of the art appointment reminder systems include handling of large amounts of data from an appointment database having a plurality of appointments, client, and service provider information. A further problem is inefficiencies and errors in manual updating of appointment reminder status. A further problem is integration difficulties with a variety of appointment reminder systems for effective updating of their appointment records. A further problem concerns monitoring and efficient processing of related appointments. A further problem concerns coordination (i.e. disconnect or misunderstanding) of appointment details between service providers, clients, and the appointment reminder systems.
[0006] One solution to address this challenge is performed by Televox™, however their appointment reminder solution does not provide real-time two-way integration into the appointment database.
SUMMARY OF THE INVENTION
[0007] Accordingly, there is a need for a method and system to process event related information and to update the event information in the scheduling device's database using automatically generated reminders such as to obviate or mitigates at least some of the above-presented disadvantages.
[0008] In accordance with an aspect of the present invention there is provided a server for processing event related information of a scheduler application, the event related information including identification data of a client and event data corresponding to the client, the system comprising: a memory for storing a plurality of update codes corresponding to the scheduler application, the update codes defining a format of a notification package in a native language of a database of the scheduler application; a generation module configured for receiving the event related information from a scheduler interface and configured for generating a notification reminder message according to a defined message timing, the notification reminder message including the event data and client contact data associated with the client identification data, the notification reminder message configured for sending according to the client contact data over a
2
TOR_LAW\ 654231 1\1 communications network for receipt by the client; a processing module configured for receiving notification response information in response to the notification reminder message; an interpreter module configured for generating the notification package including the notification response information and an update code selected from the plurality of update codes, the update code corresponding to the notification response information, the notification package configured for sending to the scheduler interface.
[0009] In accordance with an aspect of the present invention there is provided a method for processing event related information of a scheduler application, the event related information including identification data of a client and event data corresponding to the client, the method comprising the steps of: storing a plurality of update codes corresponding to the scheduler application, the update codes defining a format of a notification package in a native language of a database of the scheduler application; receiving the event related information from a scheduler interface; generating a notification reminder message according to a defined message timing, the notification reminder message including the event data and client contact data associated with the client identification data, the notification reminder message configured for sending according to the client contact data over a communications network for receipt by the client; receiving notification response information in response to the notification reminder message; and generating the notification package including the notification response information and an update code selected from the plurality of update codes, the update code corresponding to the notification response information, the notification package configured for sending to the scheduler interface.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] An embodiment of the invention will now be described by way of example only with reference to the following drawings in which:
Figure 1 is a block diagram illustrating an information processing system for processing and updating appointment information;
Figure 2 is a block diagram of a scheduling device of Figure 1 ; Figure 3 is a block diagram of a bridge proxy server of Figure 1;
TOR_LAW\ 6542311\1 Figure 4 is a block diagram illustrating example components of a data package used in the system of Figure 1 ;
Figure 5 is a block diagram illustrating example components of a notification package used in the system of Figure 1 ;
Figure 6 is a sequence diagram illustrating an example communication between the bridge and one of the scheduling devices of Figure 1;
Figure 7 is a block diagram illustrating the central server 110 of Figure 1 ; and
Figure 8 is a block diagram illustrating the scheduling device of Figure 1 according to an embodiment.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0011] For convenience, like reference numerals in the description refer to like structures in the drawings. Referring to Figure 1 , shown is an information processing system 100 for processing and updating event related information. The system 100 provides upload of event related information (including one or more appointments, as well as corresponding clients and service providers associated therewith) stored on a scheduling device 102 via a data package 404 transmitted across a network 106. The system 100 generates and transmits notifications to the clients for the upcoming events in data package 404 via notification reminders 506 and receives responses, such as confirmations from the client to the particular event in the notifications via notification responses 507. The system 100 translates the responses 507 into a notification package 504 which is in the form for applying the update on the corresponding scheduling device 102 and its associated database. Examples of users of the scheduling devices 102 include doctors, dentists, lawyers and other entities needing sophisticated appointment scheduling services.
[0012] As described, the system 100 is used for processing and updating event related information. Events refer to various types of occurrence, happenings or activity that may be related to one or more persons. That is, events can refer to any actions scheduled for a certain time and/or date and/or place. Examples of events include appointments, meetings, scheduled tasks, or other activities. For simplicity, the term appointments will be used hereinafter to refer to one type of exemplary event. However, it will be understood that other types of events may be envisaged.
4
TOR_LAW\ 654231 IM [0013] As shown in Figure 1, the system 100 comprises one or more scheduling devices 102 connected via the bridge 104 through to a network 106 to a notification server 110. The bridge 104 may exist as a standalone unit such as the bridge proxy server 104b or it may be implemented as an application loaded onto a corresponding scheduling device 102. For convenience, the bridge 104 whether implemented as a standalone unit 104b or installed on the scheduling device 102 as a local bridge 104a will be referred to as the bridge 104 hereinafter. As will be described further below, the bridge 104 is configured for intelligent manipulation of the data package 404 in order to help reduce the bandwidth sent across the network 106 by minimizing the size of the data package 404 and to thereby facilitate improvements in the efficiency of the system 100. For example, the bridge 104 further comprises a filter module 230 to implement bridge 104 intelligence to reduce the amount of data included in the data package 404a prior to transmission over the network 106 to the server 110 as data package 404b. In one case, during the upload process which transmits data from the scheduling device 102 across the network 106 to the server 110, the filter module 230 is configured to remove stale appointment related data, repetitive data or unchanged data (as compared to previous transmission(s) of the data package 404a,b) prior to sending the data package 404b across the network 106. In one case, the filter module 230 is configured to remove client data or service provider data not linked to appointment data. Additionally, the bridge 104 comprises a number of configuration settings 232a, which control the operation of the bridge 104 with respect to the central server 110 connected to the bridge 104, and the one or more scheduling devices 102. For example, the configuration settings 232a may define the time intervals for uploading the data package 404 to the server 110. Additionally, as will be described, the bridge 104 processes the notification package 504 received in response to the data package 404 and applies the notification results provided by the notification package 504 to the database 210 of the corresponding scheduling device 102 which originated the data package 404. As will be described, the bridge 104 acts an interface between the scheduler application/ scheduler database 210 and the central server 110, for facilitating intelligent upload and download of the packages 404, 504.
[0014] Referring again to Figure 1, the central server 110 is further connected to the network 106 for receiving appointment related data via the data package 404 from the one or more scheduling devices 102 through the bridge 104. As will be described, the central server 110 is configured to process the appointment related data received from the bridge 104 and to generate automated
5
TOR_LAW\ 654231 IM notification reminders 506 for the appointments in the data package 404. In turn, a Gateway 112 (i.e. a voice or SMS and/or SMTP Gateway) is coupled to the central server 110 for processing the automated notification reminders 506 and directing the automated notification reminders 506 to a corresponding client's device 108. The client devices 108 may include, for example, a telephone device, a pager, a printer, an SMS client device, a personal computer, a personal digital assistant, a laptop or other devices configured to receive voice, text and/or email notification reminders 506 for a response to be fed back via the server 110 and bridge 104 to update the scheduling device's 102 database 210 (see Figure 2) containing the appointment data.
[0015] Additionally, as shown in Figure 1, the system 100 further comprises a website customization service 116 and an admin user interface 114 connected to the central server 110. The automated notification reminders 506 described herein may be generated using predefined templates 508 stored on the server 110. Alternatively, the templates 508 used to generate the automated notification reminders 506 can be customized using the website customization service 116 (via the website update package 117) and/or the admin user interface 114 which allow customization of the generated notification reminders 506 for the appointment related data as will be transmitted to the client devices 108. It will be understood that the information processing system 100 may include additional servers, scheduling devices, and other devices not shown, including one or more distributed servers 110 and bridge proxy server 104b.
[0016] Each of the main components of the system 100 will now be discussed with reference to Figures 1, 2, 3, 4 and 5, namely the scheduling device 102, the data package 404, the bridge 104, the appointment server 110, and the notification package 504.
Scheduling Devices 102
[0017] Referring to Figures 1 and 2, each of the scheduling devices 102 includes at least one database or memory storage (i.e. database 210) for storing the data package 404 comprising the appointment data 406, client data 410 and service provider data 408. For example, appointment data 406 may include the time of the appointment, the date of the appointment, the location of the appointment and other details regarding the appointment. The client data 410 may include, for example, names of clients/patients having appointments, the date of birth of the client, client contact information, names of other family members linked to the client, client billing details
6
TOR_LAW\ 05423 I M (i.e. for patient record keeping) and other identification information for the client. The service provider data 408 may include, for example, the name of a doctor, dentist, or lawyer or other type of service provider which a client may have an appointment with. The service provider data 408 then includes identification information for the various service providers. It should be noted that one scheduling device 102 may be associated with various service providers, each having their own clients and appointments. In turn each of these appointments is stored in database 210.
[0018] These scheduling devices 102 provide an interface for a service provider or an administrator to input and update data 410, 406, 408 relating to a client "Cn" and the client's associated appointments "An" for a particular service provider "Sn", details of which are communicated to the client devices 108 as further described below. The data package 404 contained within the scheduling device's database 210 can be further updated to include the results of the notification package 504. For example, where the scheduling devicelO2 stores a list of appointment "An" data 406 for a client "Cn", then the appointment data 406 may be updated to include information about whether the client "Cn" has confirmed the relevant appointment "An".
[0019] The scheduling devices 102 discussed herein, for example, are personal computers or network computers that are implemented as clients to the central server 110. Referring to Figure 2 shown is a block diagram of a computer system configured as the scheduling device 102. As shown in this figure, the scheduling device 102 can generally include a network connection interface 200, such as a network interface card or a modem, coupled via connection 218 to a device infrastructure 204. The connection interface 200 is connectable during operation of the scheduling device 102 to the network 106 (e.g. an intranet and/or an extranet such as the Internet), which enables each of the scheduling devices 102 to communicate with each the server 110 as appropriate. The network 106 supports the communication of the package data 404 between the bridge 104 and the scheduling devices 102 or between the bridge 104 and the server 110. As discussed earlier, the bridge 104 acts as an interface between the scheduling device 102 and the server 110. Further, the network 106 supports the transmission of the notification package 504 between the server 110 and the bridge 104 as well the communication between each of the scheduling devices 106 and the website customization service 116 as desired.
TOR__LAW\ 65423 I M [0020] Referring again to Figure 2, each of the scheduling devices 102 can also have a user interface 202, coupled to the device infrastructure 204 by connection 222, to interact with a user such as the service provider or the scheduling device's 102 administrator (not shown). The user interface 202 can include one or more user input devices such as but not limited to a QWERTY keyboard, a keypad, a track wheel, a stylus, a mouse, a microphone and the user output device such as an LCD screen display and/or a speaker. If the screen is touch sensitive, then the display can also be used as the user input device as controlled by the device infrastructure 204. For example, the user interface 202 for the scheduling device 102 is employed by the user of the scheduling device 102 to input data relating to the service provider data 408, the client data 410, and the appointment data 406.
[0021] Referring again to Figure 2, the operation of the scheduling device 102 is facilitated by the device infrastructure 204. The device infrastructure 204 includes one or more computer processors 208 and can include an associated memory 210 (e.g. a random access memory). The computer processor 208 facilitates performance of the scheduling device 102 configured for the intended task through operation of the network interface 200, the user interface 202 and other application programs/hardware of the scheduling device 102 by executing task related instructions. These task related instructions can be provided by an operating system, and/or software applications located in the memory 210, and/or by operability that is configured into the electronic/digital circuitry of the processor(s) 208 designed to perform the specific task(s). Further, it is recognized that the device infrastructure 204 can include a computer readable storage medium 212 coupled to the processor 208 for providing instructions to the processor 208 and/or to load/update client application programs 224, 104a. The computer readable medium 212 can include hardware and/or software such as, by way of example only, magnetic disks, magnetic tape, optically readable medium such as CD/DVD ROMS, and memory cards. In each case, the computer readable medium 212 may take the form of a small disk, floppy diskette, cassette, hard disk drive, solid state memory card, or RAM provided in the memory module 210. It should be noted that the above listed example computer readable mediums 212 can be used either alone or in combination.
[0022] Further, it is recognized that the scheduling devices 102 can include the executable application programs/instructions such as the scheduler instructions 224 (i.e. exemplary software
8
TOR_LAW\ 654231 1 \1 scheduling programs allow users to store and access information relating to the users, their scheduled events/tasks, and corresponding contact information). It is further noted that in some cases, these software scheduling programs facilitate sharing of calendar events among users to allow scheduling within a global calendar of events. As further illustrated in Figure 2, the scheduling devices 102 can also include bridge application program 104a comprising code or machine readable instructions for implementing predetermined functions/operations including those of an operating system, healthcare provider or service provider information system or other information processing system, for example, in response to command or input provided by a user of the scheduling device 102 or the system 100. The processor 208 as used herein is a configured device and/or set of machine-readable instructions for performing operations as described by example above.
[0023] As used herein, the processor 208 may comprise any one or combination of, hardware, firmware, and/or software. The processor 208 acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information with respect to an output device. The processor 208 may use or comprise the capabilities of a controller or microprocessor, for example. Accordingly, any of the functionality provided by the systems and process of FIGS. 1,2,3 may be implemented in hardware, software or a combination of both. Accordingly, the use of a processor 208 as a device and/or as a set of machine readable instructions is hereafter referred to generically as a processor/module for sake of simplicity.
[0024] Accordingly, the scheduling device 102 provides access to the data 404 (received in database 210) to the bridge 104 as well as receives updates to data 404 in storage/database 210 in the form of a notification package 504 configured for application to the storage/database 210.
[0025] It will be understood by a person skilled in the art that the storage/ database 210 described herein is the place where data is held in an electromagnetic or optical form for access by a computer processor. There are two general usages: First, storage is frequently used to mean the devices and data connected to the computer through input/output operations such as hard disk and tape systems and other forms of storage not including computer memory and other in- computer storage. Second, in a more formal usage, storage has been divided into: (1) primary
TOR LAW\ 6542311 \1 storage, which holds data in memory (sometimes called random access memory or RAM) and other "built-in" devices such as the processor's Ll cache, and (2) secondary storage, which holds data on hard disks, tapes, and other devices requiring input/output operations. Primary storage is much faster to access than secondary storage because of the proximity of the storage to the
' processor or because of the nature of the storage devices. On the other hand, secondary storage can hold much more data than primary storage. In addition to RAM, primary storage includes read-only memory (ROM) and Ll and L2 cache memory. In addition to hard disks, secondary storage includes a range of device types and technologies, including diskettes, Zip drives, redundant array of independent disks (RAID) systems, and holographic storage. Devices that
• hold storage are collectively known as storage media.
[0026] A database is one embodiment of storage 210 as a collection of information that is organized so that it can easily be accessed, managed, and updated. In one view, databases can be classified according to types of content: bibliographic, full-text, numeric, and images. In computing, databases are sometimes classified according to their organizational approach. The > most prevalent approach is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.
I [0027] Computer databases typically contain aggregations of data records or files, such as sales transactions, product catalogs and inventories, and customer profiles. Typically, a database manager provides users the capabilities of controlling read/write access, specifying report generation, and analyzing usage. Databases and database managers are prevalent in large mainframe systems, but are also present in smaller distributed workstation and mid-range systems such as the AS/400 and on personal computers. SQL (Structured Query Language) is a standard language for making interactive queries from and updating a database such as IBM's DB2, Microsoft's Access, and database products from Oracle, Sybase, and Computer Associates.
[0028] Memory is a further embodiment of storage/database 210 as the electronic holding place for instructions and data that the computer's microprocessor can reach quickly. When your
10
TOR_LAW\ 0542311\1 computer is in normal operation, its memory usually contains the main parts of the operating system and some or all of the application programs and related data that are being used. Memory is often used as a shorter synonym for random access memory (RAM). This kind of memory is located on one or more microchips that are physically close to the microprocessor in your ! computer.
The Data Package 404
[0029] Referring to Figures 1 and 4, the data package 404 discussed herein is a combination of service provider data 408, client data 410 and appointment data 406 for a particular client "Cn" and service provider "Sn". For example, said service provider "Sn" (i.e. a particular dentist) can
) use a scheduling device's 102 database 210 for storing thereon said dentist's list of clients "Cn" and appointments for each of those clients. Additionally, as shown in Figure 4, each service provider such as a dentist, physician, health care provider or other defined service provider is defined by certain identification means such as but not limited to, a name of the service provider, an account ID, and a service provider ID. In turn, each client associated with the service i provider (i.e. a dental patient) has identifying characteristics such as but not limited to, the client's name, ID, and contact information. Further, each appointment "An" corresponds to a scheduled event for a particular client "Cn" by the service provider "Sn". Thus, the appointment data 410 can include such as but not limited to an appointment ID, a date and time for the appointment, the associated client ID, and the associated service provider ID.
) [0030] It will be understood that the components of the data package 404 shown in Figure 4 are exemplary and other combinations of sub-information relating to and included as a part of each of the service provider data 408, appointment data 406 and client data 410 may be envisaged. As shown in Figure 1 , for simplicity, the data package 404 discussed herein refers generally to either one or both of the data packages 404a, and 404b. Since, as will be described, the data package i 404 contents can be modified at each stage by the scheduling devices 102, the bridge 104 and the server 110 . Thus, each of the data packages 404a and 404b can include all or a subset of the data described generally as data package 404 shown in Figure 4. Further examples of fields that may be included in each of the service provider data 408, the appointment data 406 and the client data 410 for each data package 404 are provided below. Additionally, the data package 404a
11
TOR_LAW\ 6542311\1 refers specifically to the data package 404 communicated between one of the scheduling devices 102 and a corresponding bridge 104 while the data package 404b refers specifically to a data package 404 which is communicated between the bridge 104 and the central server 110. For example, while the data package 404a sent to the bridge 104 can include all the phone numbers and an email address for a particular client "Cn", it may be determined by the bridge 104 intelligence (i.e. via the configuration settings 232) that the preferred mode of communication to the client is by the client's home telephone number and thus the bridge 104 may filter out (via filter 230) additional contact information such that the data package 404b includes only the relevant phone number as the contact information.
[0031] The data package 404 shown in Figure 4 can be further understood with reference to the following exemplary descriptions of each of the service provider data 408, appointment data 406 and client data 410 and their corresponding fields. The description below provides an example of some of the fields that may included within the each of the data 406, 408, and 410 for a data package 404. It is noted that other additional fields defining each of the data 406, 408, and 410 may be envisaged as will be understood by a person of ordinary skill in the art.
[0032] It will further be understood by a person of ordinary skill in the art that the data packages 404a and 404b may be transmitted one segment at a time. For example, the bridge 104 may be configured to send the client data 410 first to the central server 110, followed by the service provider data 408 and the appointment data 406.
[0033] The client data 410 can include, for example, the following fields:
Field Description
A cross reference id to the client id used in the client package.
The client salutation.
The first name of the client.
The last name of the client.
The email address of the client.
The home phone number of the client.
The business phone number of the client
A flag indicating if this client is willing to receive reminder notifications.
A flag indicating if the client has signed a HIPPA agreement.
12
TOR_LAW\ 6542311\1 The account id (clinic) of the client.
A cross reference id to the client id used in the client package which represents the responsible family member for the client. This can be null and is usually used when the client is a child and the responsible family member is a parent.
The user updating this record. For the import, this is the admin user.
[0034] The service provider data 408 can include, for example, the following fields:
Field Description
A cross reference id to the service provider id used in the client package.
The service provider salutation.
The first name of the service provider.
The last name of the service provider.
The account id (clinic) of the service provider.
The useR updating this record. For the import, this is the admin user.
[0035] As will be described with reference to communications between the bridge 104 and the server 110 with respect to bridge intelligence, in one embodiment, once the service provider data 408 for a particular service provider "Sn" has been provided to the server 110, it is not transmitted again. In this case, the bridge 104 may send the service provider data 408 again only in order to add information about a new service provider not previously sent or to update information about the previously transmitted service provider "Sn".
[0036] Further, the appointment data 406 sent as part of data package 404 can include, for example, the following fields:
Field Description
A cross reference id to the appointment id used in the client package. The appointment date and time.
The length of the appointment in minutes.
A cross reference id to the client id used in the client package. The account id (clinic) of the service provider.
A cross reference id to the service provider id used in the client package.
The batch number of the appointment. This is used to determine if future appointments not sent within the latest batch of appointments should be deleted.
13
TOR_LAW\ 6542311\1 A flag (i.e. a DoNotCall flag) indicating if reminders should be generated for the appointment.
A type id for the appointment. This allows for future categorization of appointments. Current values include "normal" and "recall".
The user updating this record. For the import, this is the admin user.
[0037] The contents of the data package 404 including the fields contained within each of the data 406, 408, and 410 may vary at each stage of the system 100. The transmission and manipulation of the data package 404 will be discussed further with reference to each of the bridge 104 and the server 110.
Bridge 104
[0038] As discussed earlier, and illustrated in Figures 1, 2, and 3 the bridge 104 may be implemented as a standalone unit such as the bridge proxy server 104b or alternatively, the bridge 104 may be implemented as an application program, such as bridge 104a loaded onto the corresponding scheduling device 102. As shown in Figure 1, where the bridge 104 is implemented as a bridge proxy server 104a, then the scheduling devices 102 connected thereto do not include the bridge 104a application program. Conversely, where the bridge 104 is implemented as the bridge application program 104a on a scheduling device 102 having a series of executable instructions 238 installed on the scheduling device 102, then the scheduling device 102 and the local bridge 104a are connected directly to the server 110 via the network 106. It is recognized that executable instructions could be hard-coded (e.g. logic device), soft-coded (e.g. software), or a combination thereof.
[0039] As shown in Figures 2 and 3, the bridge 104 comprises a series of executable instructions 238, an upload module 234, a download module 236, the number of configuration settings 232a, and the filter module 230 discussed earlier. The upload module 234 of the bridge 104 has the capability to obtain the data package 404a including the appointment data 406 from the database 210 or other storage of the scheduling device 102. As will be discussed, the configuration settings 232a determine the communication protocol used by the upload module 234 and the download module 236 to communicate with the database 210 and the scheduling device 102.
14
TOR_LAW\ 6542311 \1 Additionally, the configuration settings 232a define the time intervals at which the communication between the bridge 104 the scheduling device 102 and the server 110 occurs.
[0040] According to one embodiment, the upload and download times occur at separate time instances. For example, the configuration settings 232a may define that the upload module 234 uploads the data package 404a at every 30 seconds while the download module 230 downloads data to the scheduling device 102 every 30 minutes. Alternatively, the upload module 234 may be configured to upload the data package 404a substantially simultaneously rather at set time intervals such that it is almost immediately aware of updates to the scheduling devices 102. Similarly, the download module 230 may be configured to download data to the scheduling device 102 substantially instantaneously.
[0041] As further described below, once the upload module 234 receives the data package 404a it communicates the data package 404a to the filter module 230 which is configured to filter the data package 404a contents according to the filter settings in order to generate the data package 404b (e.g. which includes client data 410, service provider data 408 and appointment data 406) across the network 106 to the server 110. The server 110 then uses the appointment data 406 within the data package 404b for generation of the notification reminders 506 to the client and then once the notification response 507 is received from the client, the server 110 translates the response data into native language for the scheduling device 102.
[0042] Further, the bridge's download module 236 is then configured to download the notification package 504 from the server 110 (according to the configuration settings 232). The download module 236 further communicates the notification package 504 including the response data back to the associated database 210 of the scheduling device 102, in order to update the stored data of the data package 404a. The notification package 504 is indicative of the appointment confirmation/response information received from the client devices 108 in response to the reminders 506. The operation of the bridge 104 is discussed in detail below.
Installation
In one embodiment, the bridge 104 installs (e.g. on the scheduling device 102) as a Microsoft Windows Installer package (MSI). The installation displays a license agreement page and allows
15
TOR LA W\ 054231 IM the installer to select the directory to be installed. Once installed, the installer runs a script (installservice.cmd) included within the executable instructions 238 to register the service and create the event log source "PromptAlert" in the Windows event viewer. The script also sets the event viewer category to overwrite events as needed.
Configuration Settings 232a
[0043] Once the bridge 104 is installed, configuration settings 232a are defined to allow the bridge to operate as needed by the server 110. The configuration settings 232a define the operation of the upload module 234, the download module 236 and the communication between the bridge 104 and the connecting components such as the one or more scheduling devices 102 and the server 110. Additionally, the configuration settings 232a may include information about the database 210 for the corresponding scheduling device 102. As mentioned earlier, the database 210, stores the relevant service provider data 408, appointment data 406, and client data 410 as communicated from a scheduling application program/ executable instructions 224. Thus, the configuration settings 232a may include information about the database 210 type, the connection protocol required for communication to the database 210 (as required for communication from the upload module 234 or the download module 236 to the database 210).
[0044] For example, the bridge 104 XML file, is located in the install directory specified during installation of the bridge 104 and provides default values for the configuration settings 232a. As will be described, the server 110 also includes a set of customizable configuration settings 232b stored thereon. The configuration settings 232b stored on the central server 110 are account specific such that they can be updated by a user of the website customization service 116 (i.e. a dentist, a service provider or an administrator of one or more scheduling devices 102). Alternatively, as shown in Figure 1, the configuration settings 232b may be updated by the scheduling device 102 connected to the website customization service 116 via the network 106. In this case, the service provider may use a user interface 202 of the scheduling device 102 to modify the configuration settings 232b via the website customization service 116. Further alternatively, as shown in Figure 1, the admin user interface 114 may be provided to allow direct modification of the configuration settings 232b on the server 110.
16
TOR_LAW\ 6542311\1 [0045] As will be described, the configuration settings 232b once defined for a particular account (i.e. service provider /scheduling device 102/ database 210) and stored on the server 110, may be communicated to the bridge 104 for defining some of the values in the configuration settings 232a not previously defined and for overwriting certain generic default values. For simplicity, the configuration settings 232a, and 232b are referred to generally as configuration settings 232.
[0046] The following table provides examples of configuration settings 232 and what they represent such that may be used by the bridge 104:
Figure imgf000018_0001
17
TOR_LAW\ 6542311\1
Figure imgf000019_0001
[0047] Additionally, the handling of appointment datetime values are based on the scheduler instructions/application package 224 since each scheduler application package 224 stores appointment date and time differently.
Upload Module 234
[0048] Referring again to Figures 2 and 3, the bridge 104 comprises the upload module 234. The upload module 234 is responsible for receiving the data package 404a containing the service provider data 408, the client data 410, and the appointment data 406 from the scheduling device
18
TOR_LAW\ 6S423i m 102 and for transmitting a filtered version of the data package 404a (i.e. in the form of data package 404b) to the server 110. The filtering of data is facilitated by the filter module 230 provided by the bridge 104. Additionally, the operation of the upload module 234 with respect to the scheduling device 102 and the server 110 is defined by the configuration settings 232 described above.
[0049] Referring to Figure 6, shown is the operation of the system 100 as defined by its components. As shown in Figure 6, at step 602 the upload module 234 of the bridge 104 first loads in the local configuration settings 232a defined during installation of the bridge 104. At the same time, the server 110 has loaded thereon a number of customizable configuration settings 232b which may have been customized through the website customization service 116 (via the updates 117) or through an admin user interface 114. At step 606, the configuration settings 232b are transmitted to the bridge 104. For example, this may be facilitated via a web service call to the server 110. As described earlier, this allows for configuration changes for the service provider account to be made on the server 110 and to propagate to the bridge 104. At step 608, the server defined configuration settings 232b are then loaded onto the bridge 104 and override the local configuration settings 232a.
[0050] In one embodiment, the upload module 234 then replaces the token date in the AppointmentSQL with the last transmission date for the bridge 104. The last transmission date is used to store the date of the last successful transmission to the server 110. This information which is stored in the configuration settings 232 allow the upload module 234 to determine which appointment data 406 to upload to the server 110 such that the appointment data 406 uploaded is current.
[0051] For example, the tokens replaced are:
Figure imgf000020_0001
19
TOR LAW\ 6542311\1 [0052] At step 610, the upload module 234 then uses the DatabaseProvider setting stored in the configuration settings 232 to determine if the client is using OLEDB, ODBC, or another database connection. Based on this value, the upload module 234 applies an SQL query against the database 210 via the scheduler 224 to determine a list of appointment data 406, service provider data 408 and client data 410 to receive from the scheduling device 102. Alternatively at step 612, the scheduling device 102 transmits the data package 404a containing client data 410, appointment data 406 and service provider data 408 to the bridge 104. At step 614, the upload module 234 receives the data package 404a and filters the data package 404a according to the filter module 230 settings in order to generate the data package 404b for subsequent transmission to the server 110 at step 616. As defined by the configuration settings 232, the frequency of upload of the data package 404b to the server 110 is determined by the value stored in the ServerUploadlntervallnMinutes. For example, the upload module 234 may upload data package 404b to the server 110 at predefined intervals. Alternatively, the upload module 234 may be configured to transmit data package 404a each time there is new information relating to I appointment data 406/client data 410/ service provider data 408 stored on the database 210. Thus when an update is made on the data package 404 using the scheduling device 102, the update may be transmitted substantially simultaneously to the server 110. For example, this may be implemented by configuring the "ServerUploadlntervallnMinutes" to real-time such that the upload to the server 110 occurs almost immediately.
) [0053] Further, the filter module 230 may be configured to provide a series of rules which determine which components of the appointment data 406/ client data 410/ service provider data 408are transmitted as part of data package 404b. The following description provides some examples of filtering rules that may be used within the filtering module 230.
[0054] In one embodiment, once the bridge 104 has received the data package 404a, the upload 5 module 234 uses the filter module 230 to remove any service providers (as defined in the service provider data 408) or clients (as defined in the client data 410) which are not referenced in the list of appointments provided by the appointment data 406. In this case, if there are service providers "Sn" or clients "Cn" which have no appointments "An" linked to them then there is no reason to upload the particular service provider data 408 or client data 410.
20
TOR_LAW\ 6542311\1 [0055] Additionally, the filter module 230 may be configured with filter settings which remove stale appointments which have expired, or unchanged appointments. In this case, if the appointment data 406/client data 410/service provider data 408 remains unchanged since previous transmissions then the appointment data 406/client data 410/service provider data 408 is not transmitted again to the server 110.
[0056] In another embodiment, if the client data 410 specifies that a client does not want reminders for their appointments (i.e. by setting a DoNotCall flag to indicate this) then the filter module 230 detects the value of the flag and removes the particular client data 410 and associated appointment data 406 from the data package 404b prior to transmission to the server ) 110.
[0057] In one embodiment, once the filtration process is completed via the filter module 234, a count of the number of total rows to upload to the server 110 is determined and the information is uploaded to the server 110 via the upload module 234 across the network 106. This count of number of rows is passed by the bridge 104 as a checksum value for the server 110 to perform
5 error checking and verification of correct transmission. Further, in one embodiment, the upload module 234 may also transmit an account security token to the server 110 that may be defined in the configuration settings 232 and for substantially immediate verification by the server 110 prior to processing of the data package 404. Additionally, the upload module 234 may be configured to encrypt all communications including data package 404 via SSL prior to
I transmission to the server 110. Other forms of secure transmission of the data package 404 may be used as will be understood by a person of ordinary skill in the art.
[0058] Further, the server 110 may be configured to transmit acknowledgement of successful transmission of the data package 404. In this case, if the transmission of the data package 404a is successful, then the upload module 234 is further configured to update the last transmission date and time stored in the configuration settings 232 and the connection to the database 310 may then be closed. As discussed earlier, the last transmission date stored within the configuration settings 232 may be used by the bridge 104 to determine which appointment related data has not been communicated yet.
21
TOR_LAW\ 6542311 \1 [0059] Alternatively, according to one embodiment, the bridge 104 further comprises a communication module 235. In this embodiment, the communication module 235 is configured to communicate with the server 110 and to provide the filtered data package 404b to the server 110. Similar to the operation described earlier, the upload module 234 is configured to receive the data package 404a from the database 210 via the scheduler 224. As described above, prior to this upload, the upload module 234 detects the communication protocols as defined in the configuration settings 232. Once the upload module 234 receives the data package 404a from the database 210, then the upload module 234 cooperates with the filter module 230 which removes unnecessary data from the data package 404a to generate the data package 404b. As described earlier, this unnecessary data can include for example, stale data, unchanged data, or data not required for generating the notification reminder 506. The data package 404b is then forwarded to the communication module 235 which is configured to communicate with the server 110 and transmit the data package 404b to the server 110 for subsequent generation of the notification reminders 506.
Download Module 236
[0060] As described earlier, the download module 236 of the bridge 104 facilitates downloading of responses (received in the form of the notification package 504) to notification reminders 506 generated at the server 110 and containing information about a particular appointment and corresponding client. Once the download module 236 processes the notification package 504, it applies the response (i.e. confirmation type, appointment related data) to the database 210 associated with scheduling device 102. Similar to the upload operation, the operation of the download module 236 is defined by the configuration settings 232.
[0061] The download module 236 is thus configured to receive client responses to automated appointment reminders for the client via the notification package 504 sent from the server 110. The client responses referred to as notification responses 507 can include for example, appointment confirmation and appointment activity information obtained from the client device 108. As will be described, the download module 236 is further configured to process the results received in the notification package 504 and update the database 210 accordingly. Similar to the upload operation, in the download operation of the download module 236, the local
22
TOR_LAW\ 6542311\1 configuration settings 232a are synchronized with those of the server-defined configuration settings 232b. As well, based on the "DatabaseProvider" setting in the configuration settings 232, the download module 236 establishes a connection to the database 210.
[0062] Further, in one embodiment, the "Startlnterval" and "Endlnterval" stored in the 5 configuration settings 232 are examined by the server 110 to determine the list of confirmed appointments to report back to the bridge 104 via the notification package 504. The range will be from the current date/time less the Startlnterval in hours to the current date/time plus the Startlnterval in hours. Thus, only appointments which have been confirmed (and related activity) are reported back to the bridge 104.
) [0063] Referring again to Figure 6, at step 628, the confirmed appointments and activity transmitted via the notification package 504 are then downloaded to the bridge 104 for further processing. The notification package 504 received includes, for example, the confirmation SQL and the client appointment id which was confirmed. Referring to Figure 5, shown is an example notification package 504 which comprises one or more of appointment data 406 in native i language; client data 410 in native language; service provider data 408 in native language; and notification responses 507 in native language.
[0064] At steps 630 and 632, the download module 236 iterates through all the appointments received in the notification package 504 and applies the confirmation SQL or other forms of notification responses contained therein to update the database 210. Further, the download 1 module 236 is configured to iterates through all the client activity received in the notification package 504 and applies the activity SQL (or other native language) to update the database 210. The result is that the corresponding scheduling device 102 and the scheduling application/executable instructions 224 will then show the appointment as confirmed and display the reminder activity/response to the appointment notification on the user interface 202, if this feature is supported by the client application.
[0065] Further, after successful update of the appointment and activity information via the notification package 504 to the database 210, a confirmation (i.e. via an acknowledgement message 713) is sent to an acknowledgement processing module 711 of the server 110 at step 634 (i.e. via the communication module 235). As shown in Figure 7, the acknowledgement
23
TOR_LAW\ 654231 1\1 processing module 711 then marks the confirmation notification package as applied within the activity table 709 of the server 110. For example, a list of all appointments (this can be in the form of appointment data 406) which were updated is sent back to the server 110 via the communication module 235. This allows the server 110 to update the configuration settings 232 (i.e. flag that the client is confirmed for the Appointment and ReminderAudit tables for the corresponding reminder).
[0066] In one embodiment, the upload module 234 of the bridge 104 is configured to communicate with the download module 236 prior to transmission of appointment related data via the data package 404 to the server 110. hi this case, the download module 236 may have received a notification package 504 from the server 110 for processing which includes status updates (i.e. confirmation of a particular appointment for a corresponding client and service provider). The download module 236 may further comprise a queue of status of appointment related data for processing. The upload module 234 may also comprise a queue for processing of the appointment related data prior to transmission to the server 110. Thus the upload module 234 may check the queue or other storage means of the download module 236 to verify that the data package 404 has not yet been confirmed (or other reminder activity not yet received) via notification package 504. If the data package 404 contained in the queue of the bridge has been confirmed then the data package 404 is removed from the queue of the upload module 234 prior to transmission to the server 110.
[0067] Further, in one embodiment as shown in Figure 3, if the bridge is implemented as a bridge proxy server 104b then the bridge proxy server 104b comprises a network connection interface 300, a user interface 302, coupled to the device infrastructure 304 by connection 318, 322 respectively. The device infrastructure 304 further comprises one or more computer processors 308 and can include an associated memory 310. Further, the device infrastructure 304 can include a computer readable storage medium 312 coupled to the processor 308 . Further the bridge proxy server 104b comprises executable instructions 238, filter module 230, upload module 234, download module 236, and configuration settings 232a coupled to the device infrastructure via 320. It will be understood by a person of ordinary skill in the art, that components 300, 302, 304, 308, 310, 312, 318, 320 and 322 discussed in reference to Figure 3
24
TOR_LAW\ 654231 IM are similar components and devices as corresponding components 200, 202, 204, 208, 210, 212, 218, 220 and 222 discussed in reference to Figure 2.
[0068] As described above, the bridge 104 is a generic bridge configured to communicate with different types of databases 210 and scheduler applications 224. The configuration settings 232a can predefine the type of database 210 and the scheduler application 224 used (as well as the required communication protocol) such that the bridge's upload module 234 and download module 236 are configured for communication to the scheduling device 102. As described above, the types of database connections may include ODBC", "OLEDB", ProxyTimeout among others as will be understood by a person skilled in the art. Referring now to Figure 8, shown is a block diagram of the scheduling device 102 further comprising a database manager 801. In this embodiment, once the scheduler application 224 receives the notification package 504 from the bridge 104, the scheduler application 224 then passes the notification package 504 containing the response data (in the native language of database 210), to the database manager 801 for subsequent application of the response data in native language to the database 210. Alternatively, the bridge 104 may be configured to communicate directly with the database manager 801 and provide the notification package 504 for subsequent application to the database 210.
Creation of New Appointments/Updates via the Website Customization Service 116
[0069] As described above, the website customization service 116 provides the interface for customizing the notification reminders 506 (i.e. via customization of the templates 508) and/or customization of the configuration settings 232 in the form of the website update package 117 adapted to be subsequently applied to the server 110 and/or the bridge 104. According to one embodiment, the website customization service 116 further provides an interface for a user to schedule new appointments and/or modify existing appointment information including deleting existing appointments (see Figure 7).
[0070] For example, the website customization module 116 may be configured to provide a copy of the database 210 corresponding to a scheduling device 102 such that a user accessing the website customization service 116, is able to view the current status of one or more appointments for a corresponding service provider 408 associated with the scheduling device 102 and
25
TOR LA W\ 054231 IM accordingly request a new appointment and/or change an existing appointment information. In this case, the new appointment and/or changes to existing appointment information are transmitted to the server 110 via the website update package 117. The update package 117 containing the updated appointment information is then received at the processing module 708 which encapsulates the update package 117 in the form of the notification package 504 and transmits the notification package 504 to the bridge 104.
[0071] Referring now to Figures 2 and 3, similar to the operation described above, once the download module 236 of the bridge 104 receives the notification package 504 comprising the requested new appointment/change of appointment information it applies the update to the corresponding database 210. Further, similar to the processing of reminder responses obtained via the notification package 504, the download module 236 is configured to generate a positive/negative confirmation about the application of the new appointment/ modified appointment information received via update 117 to the database 210. For example, referring now to Figures 6 and 7, in the case where the download module 236 determines that the update can't be applied (i.e. the appointment time is no longer available, or the updated appointment information is not valid), the download module 236 generates a negative acknowledgement message 713 and communicates this to the communication module 235. In turn, the communication module 235 is configured to communicate the acknowledgement message 713 to the server 1 10. The acknowledgement processing module 711 then receives this acknowledgement message 713 and forwards it to the website customization service 116 for subsequent display to the user. Conversely, a positive acknowledgement message 713 is reflected on the website customization service 116 via the server 110. In this manner, a user can update/modify(e.g. delete)/add new appointment related information (i.e. modify a patient's contact information) via the website customization service 116 and the result is then verified to the user via the acknowledgement message 713 transmitted to the website customization service 116.
Central Server 110
[0072] Referring now to Figures 1 and 7, the central server 110 is configured to process the data package 404 containing appointment related data for particular clients and service providers and
26
TOR_LAW\ 654231 IM generate notification reminders 506 regarding said appointments to said clients. As shown in Figure 7, the central server 110 further comprises a notification generation module 702 for processing the data package 404b and generating the notification reminders 506 in accordance with the processed data package 404b. The central server 110 further comprises customizable/predefined templates 508 for use by the notification generation module 702 in generating the text/voice to be used in the notification reminders 506 for the client's device 108. The voice or SMS or SMTP gateway 112 receives responses to the reminders 506 sent to the clients and forwards the notification responses 507 to the central server 110. The central server 110 further comprises a processing module 708. As described above, the processing module 708 may be configured to process update packages 117 (e.g. containing new appointments/modified appointment information). In addition, according to the present embodiment, the processing module 708 is configured to process responses to reminders (e.g. a confirmation of an appointment reminder received via notification responses 507). In this case, the processing module 708 processes the notification responses 507 received and generates the notification package 504 that is specific to the scheduling device database 210 using an interpreter module 710 coupled thereto. The notification package is subsequently transmitted to the bridge 104.
[0073] The operation of the central server 110 will be discussed with reference to each of the components in Figure 7.
Notification Generation Module 702
I [0074] In one embodiment, the notification generation module 702 first verifies the passed security token received from the bridge 104 against the value stored in the notification generation module 702. If the tokens match, then the central server 110 accepts receipt of the data package 404. The table below lists exemplary methods used to receive the data package 404b and perform processing thereon by the notification generation module 702:
i Stored Procedure Purpose
Figure imgf000028_0001
27
TOR_LAW\ 6542311\1
Figure imgf000029_0001
Further details of exemplary steps performed by each of the above procedures is shown below:
Client Import
The stored procedure usp_P A_ImportClient is called. The following exemplary steps are executed:
- check to see if the Client already exist
- check to see if the Client has an existing Responsible Family Member set
- if no Responsible Family Member set, set the client themself as the Responsible Family Member
- add or update the Client setting the Accountld, Salutation, FirsfName, LastName, EmailAddress, HomePhone, Cell
- verify phone/contact information to remove non-valid entries
Client Table Trigger Functionality
- if the DoNotCallFlag is set for the client, kill all corresponding reminders
Service Provider
The stored procedure usp_PA_ImportServiceProvider is called. The following steps are executed:
- check to see if the Service Provider already exist
- add or update the Service Provider setting the Accountld, Salutation, FirstName, LastName, and ServiceProvider
Appointment
The stored procedure usp_PA_ImportAppointment is called. The following steps are executed:
- first finds the client id and service provider id for this appointment
- looks up the reminders for the account
- if one of the Notification type is a voice call for the appointment, look up and set to the preferred voice call time
- if no PreferredVoiceCallTime exists, set the VoiceCallTime to a predetermined time
- check to see if this is a SameDay appointment, set the corresponding flag
- checks to see if the appointment already exist
28
TOR LAW\ 654231 1\1 - if adding the Appointment, sets the ApptDate, LengthlnMinutes, Clientld, Accountld, ServiceProviderld, Notificication
- if updating the Appointment, sets the ApptDate, LengthlnMinutes, Clientld, Accountld, ServiceProviderld, Notification
Appointment Table Trigger Functionality [tr_PA_UpdateApptDotNotCalI]
- if the appointment DoNotCall flag is set, kill all corresponding reminders
[usp_PA_trUpdateAppt]
- if the ApptDate is changed, check to see if this is a SameDay Appointment
- if the appointment is a "SameDay" appointment then flag it as a SameDay Appointment
If the appointment is NOT a "SameDay" appointment then:
- kill all the reminders which have not already been sent for this appointment
- reset the reminder generated flag for the appointment
- reset the IsClientConfirmed flag to set the appointment as not confirmed
- flag the appointment as NOT being a SameDay appointment
Preprocessing
[0075] As shown in the procedures above, the notification generation module 702 performs preprocessing of the received data package 404 prior to generating the notification reminders 506. For example, in the case of back-to-back appointments, the notification generation module 702 identifies the client's first appointment in a day as the only appointment requiring communication. All notifications for later appointments in the same day are held (i.e. no new notification reminders 506 are generated) and inherit the confirmation status of the first appointment in the activity table 709. While importing the data package 404b from the bridge 104, the notification generation module 702 flags same-day appointments if they are created/modified within a pre-determined period prior to appointment notifications and they are assumed to be confirmed based on the small period of time between the booking and the actual appointment.
[0076] In another embodiment, the notification generation module 702 receives a data package 404 where the event data 406 applies to more than one persons (e.g. associated with more than one client 410). In this case, the notification generation module 702 flags the data package 404 so that more than one reminder is generated via the notification reminders 506, each generated notification reminder 506 being transmitted to the one or more persons associated with the event 406. For example, considering the scenario where a scheduled event such as a fire drill, or
29
TOR_LAW\ 65423U\I cancellation of school, or other occurrences which affect a number of clients then the data package 404 contains the event data 406, and the client data 410 includes identification of the number of clients associated with the event. In this case, several notification reminders 506 are generated by the notification generation module 702, each corresponding to the number of clients.
[0077] In another embodiment, the notification generation module 702 flags multiple appointments for the same family and groups them according to their contact phone number. If a number is due to be called multiple times for separate appointments, the notification reminders 506 are concatenated into one 'parent' call. Thus the appointments for concatenated notifications inherit the confirmation status of the 'parent' appointment in the activity table 709.
[0078] Exemplary implementations of the above embodiments are described below.
[0079] Back-to-Back Appointments: This method is passed the "OffsetHours" as a parameter. The logic loops through all appointments within OffsetHours hours of the current date/time and checks if there is another non-deleted appointment with the same client, account, year, month, day and later in the same day. If a later appointment exists which matches the same criterial, the task kills the reminders for the later appointment and sets the "B2BApptId" values to the current (parent) appointment. The result is that only one reminder will be sent to the client for the back to back appointments they have scheduled during the same day.
[0080] Same Day Appointment: Appointments booked or changed close to the actual date of the appointment are considered to be pre-confirmed by nature. When these types of appointments are transmitted across the bridge 104, they are classified as 'sameday' and no reminders are generated or sent out for this appointment. Each account has a value on the account table called "SameDaylnternalHours" If the appointment is within SameDaylnternalHours hours of the current date/time, the appointment is considered a SameDay appointment and flagged as such on the appointment table. No reminders are generated for "SameDay" appointments as they are presumed to be confirmed based on their proximity to the actual event.
30
TOR_LAW\ 65423 U\l [0081] Family Member Reminders: Family calling is the method in which it is determined whether to confirm all appointments for all family members in one call or separate calls. Enabled on a per account basis, the Family Calling scheduled task runs through all scheduled voice calls in the next few days. The number to call is examined for each reminder. If more than one reminder is due to be sent to the same phone number for appointments on the same day, the first appointment timewise is considered to be the 'Parent'. All reminders for appointments later in the day are killed. I.e - "I'm calling to remind Patient 1, Patient 2 AND Patient 3 of their.. (Patient 1 is the parent appointment, the reminders for Patient 2 and Patient 3 were killed and their names added to the reminder for Patient 1).
[0082] The table below lists examples of cases where the notification generation module 702 determines upon processing the data package 404b that no notification reminders 506 should be generated for the data package 404b
Figure imgf000032_0001
[0083] Additionally, in one embodiment, notification reminders are not generated if, the configuration settings 232 provided to the notification generation module 702 provide the following settings for the account associated with the data package 404: a) DoNotGenerateReminders = 1 for the Service Provider; b) DoNotCall = 1 for the Client; c) Isdeleted = 1 for the Appointment (appointment flagged as deleted); d) DoNotGenerateReminders = 1 for the Account; e) IsSameDayAppt = 1 for the appointment (same day appointment); f) DoNotSendReminder = 1 for the appointment; DoNotGeneratePastDue=l for the Appointment. For example, if the DoNotGeneratePastDue flag is set, it will prevent a reminder for an appointment that has occurred in the past from being
31
TORJ.AW\ 6542311\1 generated. In this case, if a reminder is being generated which should have been sent out a week before the reminder was generated, it will not be generated.
Scheduler Table 706
[0084] Referring to Figure 7, the notification generation module 702 further comprises a scheduler 707 and a scheduler table 706 for determining when the notification reminders 506 should be transmitted to the client devices 108 in accordance with the account specific information (i.e. client/service provider/scheduling device 102 specific requirements) stored in the scheduler table 706. The scheduler table 706 may contain predefined or default values therein. However, the scheduler table 706 values may also be customizable via the website customization service 116. For example, a client/service provider may have specific predefined call times associated therewith for contact via email, SMS or voice calling. These call times may further be manipulated by the scheduler 707 to account for time zone changes and the scheduler 707 may also overwrite the call times defined in the scheduler table 706 based on the account specific statistics obtained in the activity table 709. That is, if the scheduler 707 determines, based on analyzing the success/failure information stored in the activity table 709 that a particular time slot has had success in reaching one or more clients, then the scheduler 707 may modify the scheduler table 706 to overwrite existing call times for the one or more clients with those times having a higher success rate.
Notification Text/Voice Generation
I [0085] As described earlier, templates 508 are used to store a series of predefined and/or customizable text/voice templates which facilitate the generation of notification reminders 506 via the notification generation module 702. Once the notification generation module 702 receives the data package 404b and determines the time for sending out the notification reminder 506 for that data package 404b according to the scheduler 707 then the notification generation
> module 702 applies one or more of the templates 508 which are specific to the client/service provider associated with the data package 404b. For example, for e-mail and SMS messages, 15 minutes prior to the notification send time, the client details (name/appointment date time) provided in the data package 404 are merged with the message template 508 text for the account to generate the notification reminders 506.
32
TOR_LAW\ 6542311\1 [0086] In order to generate notification reminders 506 using voice reminders, a voice template 508 is used and merged with the appointment related data. The voice template 508 is account specific for the specific client and/or service provider.
[0087] The notification reminders 506 are then placed within the queue 704 for subsequent transmission to the client devices 108 in accordance with the times determined by the scheduler
707.
Processing Module 708
[0088] Once a particular notification response 507 is received at the processing module 708, the module 708 may further be configured to store the client activity and reminder responses in the activity table 709 for later access by the central server 110 and for tracking of status of notification responses 507. In one example, the activity table is further divided into other tables such as a reminder table for storing responses to text-based messages (e.g. email, SMS) as well as voice call audit tables for storing responses to voice-based notification reminders 506.
[0089] The interpreter module 710 coupled thereto is further configured to translate the notification responses 507 stored in the activity table 709 into the native language associated with the database 210 of the scheduling device 102. This translation of the notification response 507 in the native language of the database defines the format of the notification package 504 that is transmitted to the bridge 104. As will be described, the notification package 504 contains the status of appointment and/or the contact activity details relating to the interaction of the client in response to receiving the notification reminder 506.
[0090] For example, the interpreter module 710 accesses a client update table 720 which stores generic and/or account specific (e.g. defined by service provider/client information) SQL update statements that are in the native language of the scheduler database 210. The SQL update statements include statements for the various types of client confirmations/detected client activity related to an appointment. That is, the client update table 720 further comprises status update codes 722; and activity update codes 724. The status update codes 722 define the SQL statement for confirmation related activity, such as but not limited to: client confirmation of appointment; and client rejection of appointment information. The activity update codes 724
33
TOR_LAW\ 654231 1\1 may define the SQL statements for other types of activity detected from the client, such as but not limited to: number busy, no answer, call hangup, answering machine-dropped call, delivered to answering machine; and call was answered by human but they didn't respond to prompts- reschedule call. As will be appreciated by a person skilled in the art, the status and activity update codes 722 and 724 may be combined so as to generate a single SQL statement based on the notification response 507.
[0091] The interpreter module 710 then converts the appointment related information and response contained in the notification response 507 to the appropriate SQL statements (via the update codes within the client update table 720) and forwards them to the processing module 708 for transmission to the bridge 104. This may be done by substituting the notification response 507 values stored in the activity table into the SQL templates defined by the status and/or activity update codes 722, 724 to define the notification package 504. In this manner, the notification package 504 contains SQL statements indicative of the response/activity received from the client in the native language of the database 210 such that once the notification package 504 is passed from the server 110 to the bridge 104 it can directly be applied to the database 210 of the scheduling device 102.
[0092] Alternatively, the interpreter module 710 examines the notification response 507 stored in the activity table, retrieves the corresponding status and/or activity update codes 722, 724 and provides the combination of the SQL template provided in the form of codes 722, 724 and the ) notification response 507 to the bridge 104. The bridge 104 then substitutes the values provided by the notification response 507 into the corresponding codes 722, 724 and applies the updated SQL statement to the appropriate corresponding scheduling device database 210. Examples of this operation are further discussed below.
EXEMPLARY OPERATION OF SYSTEM 100
> [0093] The following description provides an exemplary operation of the system 100. For example, when a clinic signs up to use the information processing system 100, the following steps occur:
34
TOR_LAW\ 6542311\1 [0094] The account is setup within the system 100 by providing the account with a number, a security token which is used to secure information as well as an identifier indicating the type of client package (e.g. local bridge 104a and/or database 210 on the client's scheduling device 102) that the client is running. This will allows the system 100 (e.g. the server 110) to determine the appropriate SQL template to use to retrieve and update client information.
[0095] The account is configured for a set of reminders and a call template (e.g. notification reminders 506 generated using template 508). The reminder metadata indicates what reminders should be generated for appointments for the account and at what interval prior to the appointment the reminder should be send. Possible reminder types include but are not limited to are email, SMS (Text Message to Cellular Phone), voice call, fax or Instant Message.
[0096] The bridge (e.g. bridge 104) is installed on one of the PC's (e.g. scheduling device) in the account's office. The bridge transmits appointment, service provider and client information (e.g. via data package 404 transmitting service provider data 408, appointment data 406, client data 410) to the server 110 to enable the server 110 to send reminders to account clients. The bridge also updates the account package database (e.g. database 210) with confirmation and activity information based on reminder activity within the server 110.
Workflow
[0097] The workflow for a patient appointment is as follows:
[0098] An appointment is created for a client. The appointment can be created in the system (e.g. scheduling device 102) through a variety of means including entered by a client at the account office, calling the receptionist at the account office or electronically via an external appointment scheduling facility. The client provides their relevant contact information including e-mail address, cell phone and phone contact information (e.g. client data 410). If any of the information is not available, the client reminder for this type of notification will not be sent and an audit log entry (e.g. activity table 709) in the server 110 will be generated to explain why the reminder was not sent.
[0099] The bridge (e.g.104) connects to the client package (e.g. scheduling device 102) and extracts a list of all appointments, clients and service providers. The system then determines
35
TOR_LAW\ 6542311\1 what clients and service providers are required to send based on the appointment list and filters (e.g. via filter module 230) the client and service provider list to exclude clients and service providers who do not need to be sent to the server 110. The list of filtered information might include appointments which are no longer active or appointments which do not require confirming.
[00100] The list of appointments and filtered list of service providers and clients (e.g. via data package 404b) are uploaded to the server 110. Newly created appointments are included in this list. The appointment, client and service provider information is applied to the server 110. In each case, if the appointment, client or service provider does not exist, they are added to the system. If the entity already exists, the information is updated.
Reminder Processing
[00101] There are automated tasks which run at scheduled intervals on the server 110.
These tasks perform many functions including generating and sending the reminders associated with appointments. The schedule for the reminders is based on the account settings (e.g. as defined within the scheduler table 706) as noted in the "Appointment Booking" section above. A sample schedule could be:
Figure imgf000037_0001
[00102] In this case, the appointment would generate 4 reminders (e.g. notification reminders 506) with each reminder being sent out at the specified interval before the ) appointment. For SMS and email messages, the body of the message is defined in a template (e.g. templates 508). The template is the generic version of the message without any appointment specifics. An example of this generic template is :
[00103] "Hi, This is a courtesy reminder of your approaching appointment. You have an appointment with <serviceprovidername> on <date> scheduled for <time>. We are looking > forward to seeing you then. If you are unable to make this appointment, please call the office at <accountbusinessphone>, to reschedule. Thank you! <serviceprovidername>'s office."
36
TOR_LAW\ 65423H\1 [00104] Minutes before the message is due to be sent out, the generic message body template is merged with the appointment specific information to create the final message text. If a client has not provided accurate contact information (e.g. An email address for email reminders, a cellular phone number for SMS reminders or a valid phone number for voice calls), the reminder will not be sent and a note will be added to the audit logs (e.g. activity table 709) to indicate that the reminder was "killed" and the reason why.
[00105] Using the above sample schedule; the email message (e.g. via notification reminder 506) is sent 7 days before the appointment. For email reminders, the email text contains two hyperlinks at the bottom of the message. The first link allows the client to add this appointment to their local calendar application. The second link allows the client to connect back to the server 110 and acknowledge receipt of the reminder e-mail (e.g. via notification response 507). The body of the message is based on template text as earlier described.
[00106] The voice call (e.g. via notification reminder 506) is sent out 2 days prior to appointment. The voice calling system is capable of handling all possible outcomes from the voice call - i.e. no answer, busy signal, no response from client, answered by an answering machine etc. Regardless of the outcome, the result is recorded and later applied to the office scheduling package (e.g. database 210). Based on the outcome of the call, the server 110 determines whether the voice call result was sufficient to consider sending of this reminder completed or if another call needs to be sent out later. For example, if a client confirms the appointment, the voice calling should be considered completed for this reminder. Conversely, if there is no answer or the client requests a callback at a later time, the voice call is rescheduled into the future. The ultimate determination of a calls success and corresponding actions are specific to each account. As illustration of this point, accounts may request that an answering machine be considered the final result while other accounts request that this result type be re- attempted later in hopes of attaining a human recipient.
[00107] For SMS reminders, the client can reply to the SMS message to indicate a response such as "I will be there". This response is received by the server 110 and forwarded to the account office (e.g. scheduling device 102).
37
TOR_LAW\ 6542311\1 [00108] When a reminder is sent the specific information about this reminder (e.g. notification response 507) is written to the ReminderAudit table (e.g. Activity Table 709). This table is used to determine whether appointments have been confirmed and to report on client activity.
Updates to ReminderAuditTable (e.g. Activity Table 709)
[00109] Email Reminders: when an email is successfully sent, a row is written to the
ReminderAudit table (e.g. Activity Table 709). The row indicates the resultcode = "El" and the HasBeenSent code as "1", indicating that the reminder was successfully sent.
[00110] SMS Reminders: when an SMS message is successfully sent, a row is written to the ReminderAudit table. The row indicates the resultcode = "Sl" and the HasBeenSent code as "1", indicating that the reminder was successfully sent.
[00111] Voice Calls: all voice calls are scheduled based on a timetable per account (e.g.
Scheduler Table 706). The timetable is made up of a sequence of calling times in which a reminder is called. An example of this timetable could be:
Figure imgf000039_0001
[00112] Using the above example, calls for this account (e.g. id 2) would go out starting at
9am in their local time zone. If this call was unsuccessful or had no answer, the next call would go out at noon and so on throughout the day until either the maximum number of attempts or maximum number of contacts was exceeded (as will be discussed later).
) [00113] When a voice call is sent, the voice call executes a calling script (e.g. using template 508) which calls the client on their voice contact number and solicits a response. All possible outcomes are anticipated and assigned a 'result code' within the call script. Each
38
TOR_LAW\ 6542311\1 outcome is returned to the server 110 as a result code. Possible result codes include but are not limited to:
Figure imgf000040_0001
[00114] When the call result is returned to server 110, the call result is logged to the
VoiceCallAudit table (e.g. Activity Table 709) which logs all voice call results. The system next looks up the result code to determine which of the following attributes should be applied to the call. These attributes are specific to each result code and determine how the call should be handled.
IsSuccess - Was the call successfully placed?
FlagReminderSent - Does the reminder require another call?
ResendReminder - Should this reminder be re-sent at a later date?
ResendMinutes - If the call should be resent, in how many minutes?
SetClientPrefTime - Was this call confirmed via human? If so record the call details
IsAttempt - should this call be considered an attempt (see below)
IsClientContact - did this call make contact with a human
ClientUpdateCode - the link to the ClientUpdateConf ig table
[00115] If the voice call is considered an attempt (IsAttempt=l), the voice call is added to the Reminder Audit table. Examples of when a call is not an attempt include processing issues, all circuits busy etc. If another calls needs to be placed, the next time to calls is determined based on the account specific calling schedule. The server 110 maintains a minimum and maximum daily call time per account (e.g. as defined by Scheduler Table 706). If the next call time is past
39
TORJLA W\ 654231 IM the latest daily call time for the account, the next voice call time is set to the first available call time for the next day.
[00116] The server 110 keeps track of number of attempts and maximum voice contacts per account client. If the number of voice contacts for this appointment exceeds the maximum voice contacts per account client, the MaxContactsExceeded flag is set for this reminder in the reminderaudit table (e.g. Activity Table 709) and no further calls will be placed for this reminder.
Updates to the account package database (e.g. database 210)
[00117] The ClientUpdateConfig table (e.g. Client Update Table 720) stores information based on the account and the ClientUpdateCode from the ResultCode table. The ClientUpdateConfig table (e.g. Client Update Table 720) contains two pieces of information: should the call be considered a confirmation of the appointment and the SQL template ("ConfirmSQL") (e.g. status update codes 722 and/or activity update codes 724) needed to update the account package (e.g. database 210) with this call activity. The bridge (e.g. 104) sends this call activity to the account package (e.g. database 210) by substituting the call values into the SQL template and applying the SQL to the account package database (e.g. database 210). The bridge 104 then applies the appropriate update SQL statements to the local database. Thus, in this case, the server 110 provides the generic SQL statement and values for populating the SQL statement (as defined by the reminder notification responses 507 stored in the activity table 709) to the bridge 104. The bridge 104 then combines the SQL statement and values for applying to the corresponding database 210.
[00118] Alternatively, once a response to a generated reminder is received (i.e. a status update or an activity received via notification response 507) and stored within the activity table 709, the interpreter module 710 applies the SQL templates contained within the Client Update Table 720 to the received reminder response (e.g. as stored in the activity table 709) and thereby generates a corresponding SQL statement containing the reminder response as provided to the bridge 104 via the notification package 504. In this case, the bridge 104 applies the notification package 504 containing the update SQL statement directly to the database 210.
40
TOR_LAW\ 6542311\1 [00119] In both cases described above, appointment activity and appointment state information (ie. Confirmed, Message left) are applied to the account package database (e.g. database 210).
[00120] Thus, the next time the appointment information is synched into the server 110, the confirmation flag stored in the account package (e.g. database 210) is also recorded (e.g. via acknowledgement processing module 711 uploads the confirmation flag and updates the activity table 709) to ensure that the confirmation values between the two systems are kept in sync. In this way if the client manually confirms an appointment within the office (e.g. via the scheduling device 102) of the account by calling in directly, the confirmation flag for the appointment will be set in both systems, preventing the appointment from being confirmed twice.
Updating Client Activity to the Account Package (e.g. scheduling device 102)
[00121] For each action performed in response to a reminder, activity details are recorded in the account scheduling package (e.g. database 210 of scheduling device 102). The details of how to update an account scheduling package are specific to each account and are stored in a table (e.g. as defined by client update table 720). Every reminder outcome has a link to a corresponding, account specific update string (e.g. status update codes 722 and/or activity update codes 724) which is applied to update the scheduling package. For example, if a voice reminder is confirmed, the package update language would be responsible for updating the status of the appointment as well as entering the details of how it was confirmed (e.g. defining details of the communication interaction with the client upon providing the notification reminder to the client) in the appointment communication log (e.g. database 210). Specifically, as an example, the following code could be used to confirm the appointment and provide a status update:
UPDATE APPOINTMENT SET APPOINTMENT-CONFIRMED=^I 1 WHERE APTNUM='$Appointmentld'
[00122] Thus, values for variables prefixed with $Variable (i.e. $AppointmentId) represent the identifier used by the local scheduling database (e.g. database 210) to refer to the appointment identifier we are confirming. For example, the appointment identifier may include '23456' which identifies the particular appointment within the service provider's list of appointments.
41
TOR_LAW\ 6542311\1 [00123] Followed by the following SQL which defines the activity related to the notification response 507:
INSERT INTO COMMLOG (PATNUM, COMMDATETIME, COMMTYPE, NOTE, MODE, SENTORRECEIVED, EMAILMESSAGENUM) VALUES CSCIientld1, STR_TO_DATE('$SentDateTime', '%m/%d/%Y %l:%i:%s %p'), '2', 'PromptAlert - Confirmed via Human Response1, '3','1 ',1O1)
[00124] Once all $Variables are replaced with the corresponding identifiers for the local scheduling package, the SQL is applied to the account database by the bridge 104. For example, in the case above, the Clientld may be replaced with '9876'; and the SentDateTime may be replaced with '2007-01-01-12:30:00.000'.
[00125] As will be appreciated by a person skilled in the art, by populating the local database (e.g database 210) for each account enables office personnel to query the local scheduling package to determine if daily appointments have been confirmed and to respond to patient inquiries regarding communication to the client by the system 100 on behalf of the office.
[00126] Accordingly, although preferred embodiments of the invention have been described herein, it will be understood by those skilled in the art that variations may be made thereto without departing from the spirit of the invention or the scope of the appended claims.
42
TOR_LA VA 65423 H\l

Claims

What is claimed is:
1. A server for processing event related information of a scheduler application, the event related information including identification data of a client and event data corresponding to the
* client, the system comprising: a memory for storing a plurality of update codes corresponding to the scheduler application, the update codes defining a format of a notification package in a native language of a database of the scheduler application; a generation module configured for receiving the event related information from a
I scheduler interface and configured for generating a notification reminder message according to a defined message timing, the notification reminder message including the event data and client contact data associated with the client identification data, the notification reminder message configured for sending according to the client contact data over a communications network for receipt by the client; i a processing module configured for receiving notification response information in response to the notification reminder message; an interpreter module configured for generating the notification package including the notification response information and an update code selected from the plurality of update codes, the update code corresponding to the notification response information, the notification package
) configured for sending to the scheduler interface.
2. The system of claim 1, wherein the notification package includes the notification response information and the update code in a manner selected from the group comprising: the notification response information is combined with the update code for providing a statement i applicable to the database; and the notification response information is separate from the update code for subsequent combination by the scheduler interface for providing a statement applicable to the database.
3. The system of claim 2, wherein the notification response information includes data ) selected from the group comprising: status of an event for the client; and contact activity details concerning interaction of the client in response to the notification reminder message.
43
TOR._LAW\ 65423U\1
4. The system of claim 3, wherein the processing module updates an activity table of the storage using the received notification response information for monitoring the status of the client event.
5. The system according to claim 2 further comprising a scheduler module for defining the message timing used by the generation module.
6. The system according to claim 5, wherein timing information for use by the scheduler module is provided in a manner selected from the group comprising: predefined for the client in the storage; dynamically received through a notification message customization interface.
7. The system of claim 3, wherein the update code of the plurality of update codes is selected from the group comprising: status update codes including client confirmation of events and client rejection of the events; and activity codes defining details of the communication of the notification reminder message with the client.
8. The system of claim 2, wherein the scheduler application facilitates users to store and access the event related information relevant to the user selected from the group comprising: scheduled events; scheduled events; and scheduled tasks.
9. The system of claim 2 further comprising a customization interface configured for dynamically receiving information directly from the client selected from the group comprising: new event data; modified event data; new client data; and modified client data.
10. The system of claim 5, wherein the scheduler module is further configured for monitoring the activity table for stored activity statistics of the event and for updating the message timing related to resending of the notification reminder message to the client, the activity statistics including contact failure status of the original notification reminder message with the client.
11. A method for processing event related information of a scheduler application, the event
44
TOR LA W\ 6542311\1 related information including identification data of a client and event data corresponding to the client, the method comprising the steps of: storing a plurality of update codes corresponding to the scheduler application, the update codes defining a format of a notification package in a native language of a database of the scheduler application; receiving the event related information from a scheduler interface; generating a notification reminder message according to a defined message timing, the notification reminder message including the event data and client contact data associated with the client identification data, the notification reminder message configured for sending according to the client contact data over a communications network for receipt by the client; receiving notification response information in response to the notification reminder message; and generating the notification package including the notification response information and an update code selected from the plurality of update codes, the update code corresponding to the notification response information, the notification package configured for sending to the scheduler interface.
12. The method of claim 11, wherein the notification package includes the notification response information and the update code in a manner selected from the group comprising: the notification response information is combined with the update code for providing a statement applicable to the database; and the notification response information is separate from the update code for subsequent combination by the scheduler interface for providing a statement applicable to the database.
13. The method of claim 12, wherein the notification response information includes data selected from the group comprising: status of an event for the client; and contact activity details concerning interaction of the client in response to the notification reminder message.
14. The method of claim 13 further comprising the step of updating an activity table of the storage using the received notification response information for monitoring the status of the client event.
45
TOR_LAW\ 6542311\1
15. The method according to claim 12 further comprising the step of defining the message timing used by the generation module.
16. The method according to claim 15, wherein timing information for use by the scheduler module is provided in a manner selected from the group comprising: predefined for the client in the storage; dynamically received through a notification message customization interface.
17. The method of claim 13, wherein the update code of the plurality of update codes is selected from the group comprising: status update codes including client confirmation of events and client rejection of the events; and activity codes defining details of the communication of the notification reminder message with the client.
18. The method of claim 12, wherein the scheduler application facilitates users to store and access the event related information relevant to the user selected from the group comprising: scheduled events; scheduled events; and scheduled tasks.
19. The method of claim 12 further comprising the step of dynamically receiving information directly from the client selected from the group comprising: new event data; modified event data; new client data; and modified client data.
20. The method of claim 15 further comprising the step of monitoring the activity table for stored activity statistics of the event and for updating the message timing related to resending of the notification reminder message to the client, the activity statistics including contact failure status of the original notification reminder message with the client.
21. The method of claim 12 further comprising the step of pre-processing the event related information including a pair of related events so as to consolidate a reminder for the pair of events as the notification reminder message.
22. The method of claim 19 further comprising the step of receiving an acknowledgement
46
TOR_LAW\ 65423 U\1 message from the scheduler interface representing successful application of the notification package to the database.
23. The method of claim 22 further comprising the step of updating an activity table of the storage based on the receipt of the acknowledgement message for cancelling a potential resending of the notification reminder message to the client.
24. The system of claim 22 further comprising the step of sending an indication of acceptance to the customization interface of the information received directly from the client.
47
TOR_LAW\ 65423 UVl
PCT/CA2007/000373 2007-03-08 2007-03-08 System and method for generating automated reminders WO2008106761A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CA2007/000373 WO2008106761A1 (en) 2007-03-08 2007-03-08 System and method for generating automated reminders

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CA2007/000373 WO2008106761A1 (en) 2007-03-08 2007-03-08 System and method for generating automated reminders

Publications (1)

Publication Number Publication Date
WO2008106761A1 true WO2008106761A1 (en) 2008-09-12

Family

ID=39737720

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2007/000373 WO2008106761A1 (en) 2007-03-08 2007-03-08 System and method for generating automated reminders

Country Status (1)

Country Link
WO (1) WO2008106761A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015109372A1 (en) * 2014-01-24 2015-07-30 N'8Kd Decision Pty Ltd Managing scheduled events in network-hosted time management system
US10070277B2 (en) 2013-12-31 2018-09-04 Nokia Technologies Oy Method and apparatus for providing a dynamic polling notification system

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5960406A (en) * 1998-01-22 1999-09-28 Ecal, Corp. Scheduling system for use between users on the web
US6016478A (en) * 1996-08-13 2000-01-18 Starfish Software, Inc. Scheduling system with methods for peer-to-peer scheduling of remote users
US6094681A (en) * 1998-03-31 2000-07-25 Siemens Information And Communication Networks, Inc. Apparatus and method for automated event notification
US20010049617A1 (en) * 2000-02-24 2001-12-06 Berenson Richard W. Web-driven calendar updating system
US20020131565A1 (en) * 2001-02-09 2002-09-19 Scheuring Jerome James Calendaring systems and methods
US20030215067A1 (en) * 2002-05-14 2003-11-20 Ordille Joann J. Method and apparatus for automatic notification and response based on communication flow expressions
US20040158486A1 (en) * 2001-06-11 2004-08-12 Nudd Audrey J. Healthcare solution system
US20050234741A1 (en) * 2004-04-16 2005-10-20 Sumit Rana Electronic appointment scheduling for medical resources
US7139718B2 (en) * 1997-03-24 2006-11-21 Canon Kabushiki Kaisha Notification apparatus and method therefor

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6016478A (en) * 1996-08-13 2000-01-18 Starfish Software, Inc. Scheduling system with methods for peer-to-peer scheduling of remote users
US7139718B2 (en) * 1997-03-24 2006-11-21 Canon Kabushiki Kaisha Notification apparatus and method therefor
US5960406A (en) * 1998-01-22 1999-09-28 Ecal, Corp. Scheduling system for use between users on the web
US6094681A (en) * 1998-03-31 2000-07-25 Siemens Information And Communication Networks, Inc. Apparatus and method for automated event notification
US20010049617A1 (en) * 2000-02-24 2001-12-06 Berenson Richard W. Web-driven calendar updating system
US20020131565A1 (en) * 2001-02-09 2002-09-19 Scheuring Jerome James Calendaring systems and methods
US20040158486A1 (en) * 2001-06-11 2004-08-12 Nudd Audrey J. Healthcare solution system
US20030215067A1 (en) * 2002-05-14 2003-11-20 Ordille Joann J. Method and apparatus for automatic notification and response based on communication flow expressions
US20050234741A1 (en) * 2004-04-16 2005-10-20 Sumit Rana Electronic appointment scheduling for medical resources

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10070277B2 (en) 2013-12-31 2018-09-04 Nokia Technologies Oy Method and apparatus for providing a dynamic polling notification system
WO2015109372A1 (en) * 2014-01-24 2015-07-30 N'8Kd Decision Pty Ltd Managing scheduled events in network-hosted time management system

Similar Documents

Publication Publication Date Title
CA2680282C (en) System and method for processing and updating event related information using automated reminders
US6697810B2 (en) Security system for event monitoring, detection and notification system
US8984535B2 (en) System and method for facilitating the exchange of information among applications
US20030023580A1 (en) Method and system for assimilating data from ancillary preumbra systems onto an enterprise system
US6617969B2 (en) Event notification system
US7739345B2 (en) Alert notification engine
US6985922B1 (en) Method, apparatus and system for processing compliance actions over a wide area network
US6385589B1 (en) System for monitoring and managing the health care of a patient population
US8694465B2 (en) System and method for context sensitive mobile data and software update
US20040078228A1 (en) System for monitoring healthcare patient encounter related information
US20040083119A1 (en) System and method for implementing a vendor contract management system
US20020157017A1 (en) Event monitoring, detection and notification system having security functions
JP2010508731A (en) Method and apparatus for sending notifications about required events to subscribers
US20050195077A1 (en) Communication of long term care information
US20110145018A1 (en) Drug and medical device safety and support information reporting system, processing device and method
US20040002958A1 (en) System and method for providing notification(s)
US20030191667A1 (en) System and user interface supporting use of rules for processing healthcare and other claim data
US20090125332A1 (en) Automated execution of health care protocols in an integrated communications infrastructure
US20100169263A1 (en) Individual health record system and apparatus
US20100076895A1 (en) Apparatus and methods for customer interaction management
JP2004538574A (en) Workflow system capable of document version management and document version management method using the same
US20230069416A1 (en) Intelligent Patient Billing Communication Platform For Health Services
US20030018643A1 (en) VIGIP006 - collaborative resolution and tracking of detected events
CA2664941A1 (en) Method and system for communicating vehicle repair information to a business-to-business rental vehicle reservation management computer system
US8185407B2 (en) Referral request system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07710707

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07710707

Country of ref document: EP

Kind code of ref document: A1