Method and apparatus for managing physician profile and healthcare appointment services

FIELD OF THE INVENTION

0001The present invention relates to directories that display profiles of healthcare practitioners (e.g. physicians), such as a hospital directory containing profiles of their affiliated physicians, or an insurance provider's directory containing profiles of their participating physicians.

BACKGROUND

0002Hospital directories with physician profiles are typically provided on a hospital website to enable actual or prospective patients to search for a particular healthcare practitioner affiliated with the hospital by name and/or specialty. The hospital directory generally provides certain background information on the practitioner enabling new patients to consider the specific education, areas of expertise, awards and publications, age, languages spoken, and even a personal statement explaining the physician's particular approach to the practice of medicine. After reviewing such physician profile information in the hospital directory and making a selection, the prospective patient is generally invited to contact the physician's office by telephone or visit the physician's practice group website.

0003The problem with hospital directories is that they generally do not provide much of the information that the patient would like to know before selecting a physician, such as accepted insurance plan(s), and booking availability. Physicians are often affiliated with multiple hospitals and as a result, providing all of this variable information in any one hospital directory becomes a difficult if not impossible undertaking for both the physician and the multiple hospitals. Each hospital has its own procedures and rules regarding, for example, displaying insurance acceptance, physician credentials, office hours and patient communications, and these procedures/rules may or may not be compatible with those of the other hospitals with which the physicians are affiliated and/or which may or may not conform with the various practice management procedures and rules followed by the physicians in their own offices. The net effect is that hospital directories provide only limited information, and the process of collecting, reviewing and approving that limited information requires significant human resources. As a result, hospital directories are typically in a state of disrepair and provide a very low rate of return on attracting new patients, hospital resource utilization, and ultimately revenue and profit.

0004Insurance company directories may also contain profiles of their participating physicians and suffer similar problems. Still further, the failure to provide accurate and complete physician profile information can impose even greater costs on the insurance companies. For restricted plans (e.g. an HMO) that require patients (subscribers) to use a doctor within an approved provider list, the insurer is often mandated by state law to provide the subscriber with an appointment within a specified amount of time. Facilitating this process is therefore of paramount importance to the insurer. Still further, a very high percentage of a health insurer's costs are emergency room visits; reducing such visits by its plan members, by enabling a regular office visit instead, represents a huge potential cost savings.

0005The issues described above have been long-standing problems for both hospitals and insurance companies, and for their patients and physicians.

SUMMARY OF THE INVENTION

0006According to various embodiments of the invention, apparatus and methods are provided for significantly enhancing the performance, accuracy, utilization and rate of return from hospital directories with profiles of their affiliated physicians, and/or insurance provider directories with profiles of their participating providers.

0007In one embodiment, apparatus and methods are provided which enable healthcare practitioners (e.g., physicians) to communicate changes to their profile data so as to increase their compliance and decrease the frequency of providing outdated or incomplete information in a hospital or insurance provider directory.

0008In another embodiment, a credentialing process is provided enabling hospitals and insurance providers to credential the profile information that is provided by the practitioner prior to including such information in their respective directories. The process enables each hospital and insurer to define their own rules for verifying some or all of the profile information provided.

0009In another embodiment, a reliable method is provided for matching practitioner to entries in insurance directories, such that a practitioner's profile can be more easily updated with complete and up-to-date insurance information.

0010In another embodiment, an apparatus and method is provided for online booking of healthcare practitioner appointments on multiple websites. This online booking process can occur simultaneously on multiple websites of a hospital, insurance provider, physician practice group, and/or centralized provider (aggregator). When provided with the enhanced directory services previously described, the hospital and insurance provider directories not only provide more complete and up-to-date physician profile information enabling patients to more easily search for and select a desired practitioner, but further allow for the immediate online booking of an appointment with the selected practitioner.

0011According to one embodiment of the invention, an apparatus is provided which includes: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0012">a computer apparatus for managing and storing a central managed database of physician profiles for physicians having affiliations with multiple hospitals and/or participations with multiple insurance providers, the database containing multiple categories of physician profile data (PPD) for each physician;</li><li id="ul0002-0002" num="0013">a portal accessible by computer to physicians over a public network for submitting the PPD to the database; and</li><li id="ul0002-0003" num="0014">a computer implemented selection filter for retrieving from the database different select categories of the PPD for a specified physician based on the physician's hospital affiliations and/or insurance participations.</li></ul></li></ul>

0015In one embodiment, the apparatus further includes: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0016">a set of computer implemented credentialing rules specific to a hospital or insurance provider for application to the PPD prior to inclusion of the PPD in an on-line physician profile directory of the respective hospital or insurance provider.</li></ul></li></ul>

0017In one embodiment, the set includes rules for: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0018">excluding the selected PPD from the directory;</li><li id="ul0006-0002" num="0019">including the selected PPD in the directory;</li><li id="ul0006-0003" num="0020">requiring approval by the respective hospital or insurance provider before including the selected PPD in the directory.</li></ul></li></ul>

0021In one embodiment, the categories include one or more of: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0022">physician name;</li><li id="ul0008-0002" num="0023">phone number;</li><li id="ul0008-0003" num="0024">practice location;</li><li id="ul0008-0004" num="0025">office hours;</li><li id="ul0008-0005" num="0026">title;</li><li id="ul0008-0006" num="0027">department;</li><li id="ul0008-0007" num="0028">professional suffixes;</li><li id="ul0008-0008" num="0029">board membership;</li><li id="ul0008-0009" num="0030">gender;</li><li id="ul0008-0010" num="0031">specialties;</li><li id="ul0008-0011" num="0032">procedures performed;</li><li id="ul0008-0012" num="0033">insurances;</li><li id="ul0008-0013" num="0034">awards; and</li><li id="ul0008-0014" num="0035">publications.</li></ul></li></ul>

0036In one embodiment, the database includes a different unique identifier for each physician.

0037In one embodiment, the categories include practice location and a geographic indicator of the practice location.

0038In one embodiment, the apparatus further includes:

0039a central managed database of available appointments with the physicians.

0040In one embodiment, the apparatus further includes:

0041a portal accessible by computer to patients over a public network for booking one of the available appointments.

0042In one embodiment, the hospital or insurance provider directory includes a link to an aggregator's website providing online booking of appointments with physicians across multiple practice groups.

0043According to another embodiment of the invention, a method of managing physician profiles is provided which includes: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0044">providing a portal to enable physicians affiliated with multiple hospitals and/or participating with multiple insurance providers to submit specified categories of physician profile data (PPD) to a central managed database;</li><li id="ul0010-0002" num="0045">storing and managing the PPD in the central database; and</li><li id="ul0010-0003" num="0046">providing PPD from the central database for inclusion in an online physician profile directory of a hospital or insurance provider.</li></ul></li></ul>

0047In one embodiment, the method further includes: <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0048">applying a set of credentialing rules specific to the hospital or insurance provider for determining compliance with the rules of some or all of the PPD and, if compliance is found, including the PPD in an online directory of the respective hospital or insurance provider.</li></ul></li></ul>

0049In one embodiment, the method further includes:

0050providing a different unique identifier for each physician in the database.

0051In one embodiment, the method further includes:

0052comparing the provided PPD to the hospital's or insurance provider's existing physician profile data and applying a merge process to create a merged profile.

0053In one embodiment, the method further includes:

0054an aggregator managing the central database and allowing shared access to the PPD as a web-based service.

0055In one embodiment, the method further includes:

0056an aggregator managing a central database of available appointments with the physicians and providing on-line booking of available appointments with the physicians.

0057In one embodiment, the method further includes:

0058simultaneously providing the available appointments for online booking on a plurality of websites hosted by two or more of the aggregator, hospital, insurance provider, and/or physician practice group.

0059In one embodiment, the method further includes:

0060providing a link in the hospital or insurance provider directory to the on-line booking process.

0061In one embodiment, the method further includes:

0062providing specified procedures available across multiple specialties to enable booking of physician appointments based on a specified procedure and not limited to a specialty.

0063In one embodiment, the method further includes:

0064wherein the categories include a practice location, and each location is classified by geographic coordinates.

0065In another embodiment, a computer-readable storage medium is provided with instructions to one or a plurality of computers for execution of the methods previously described.

0066In another embodiment of the invention, a method is provided which includes: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0067">a host providing a hospital online directory of physician profile data (PPD) for physicians affiliated with the hospital;</li><li id="ul0014-0002" num="0068">the hospital providing a website having a link to a website of the host for accessing the directory;</li><li id="ul0014-0003" num="0069">wherein the host manages physician profile data for the affiliated physicians of the hospital and provides the profile data in the directory of the hospital; and</li><li id="ul0014-0004" num="0070">wherein the host manages and provides multiple such directories, each for a different hospital.</li></ul></li></ul>

0071In one embodiment the host manages credentialing of the physician profile information prior to inclusion of the PPD in the directory.

0072In one embodiment the host manages a central database of available appointments for physicians affiliated with multiple hospitals.

0073In one embodiment each directory on the host website provides online booking of appointments with the hospital's respective affiliated physicians.

0074According to another embodiment of the invention, a method is provided which includes: <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0075">providing a hospital website having an online directory of physician profile data (PPD) for physicians affiliated with the hospital;</li><li id="ul0016-0002" num="0076">accessing the online directory and reviewing the physician profile data to identify a physician;</li><li id="ul0016-0003" num="0077">the hospital website further providing online booking of appointments with the affiliated physicians from multiple practice groups; and</li><li id="ul0016-0004" num="0078">accessing the online booking process including selecting an available appointment and booking the appointment online.</li></ul></li></ul>

0079In one embodiment of the method, the physicians: <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0000"><ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0080">have affiliations with multiple hospitals;</li><li id="ul0018-0002" num="0081">practice in multiple practice groups; and/or</li><li id="ul0018-0003" num="0082">participate with multiple insurance providers;</li></ul></li><li id="ul0017-0002" num="0083">and the PPD undergoes a credentialing process specific to each affiliated hospital, practice group or insurance provider prior to inclusion in a directory of the respective hospital, group or provider.</li></ul>

0084In one embodiment of the method, the physicians: <ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0000"><ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0085">have affiliations with multiple hospitals;</li><li id="ul0020-0002" num="0086">practice in multiple practice groups; and/or</li><li id="ul0020-0003" num="0087">participate with multiple insurance providers;</li></ul></li><li id="ul0019-0002" num="0088">and the online booking process is available on multiple website of the hospital(s); group(s) and provider(s).</li></ul>

BRIEF DESCRIPTION OF THE FIGURES

0089<figref idref="DRAWINGS">FIG. 1</figref><i>a </i>is a schematic representation of an exemplary communications network for implementing various embodiments of the present invention;

0090<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of an exemplary computer on which the software product(s) of the present invention may be executed;

0091<figref idref="DRAWINGS">FIG. 3</figref> is a exemplary webpage from an aggregator's website enabling a physician to enter his/her profile information according to one embodiment of the invention;

0092<figref idref="DRAWINGS">FIG. 4</figref> is one example of an entry on a display screen enabling a hospital reviewer to perform a credentialing process according to one embodiment of the invention;

0093<figref idref="DRAWINGS">FIG. 5</figref> is one example of a listing in a hospital directory for an affiliated physician according to one embodiment of the invention;

0094<figref idref="DRAWINGS">FIGS. 6</figref><i>a</i>-<b>6</b><i>b </i>is a flow diagram illustrating one example of a method for reviewing and confirming a physician's affiliation with a designated hospital prior to inclusion in the hospital directory according to one embodiment of the invention;

0095<figref idref="DRAWINGS">FIG. 7</figref> is an exemplary screenshot for performing a credentialing process according to one embodiment;

0096<figref idref="DRAWINGS">FIG. 8</figref> is one example of a script (software code) for providing an online booking functionality according to one embodiment of the invention;

0097<figref idref="DRAWINGS">FIG. 9</figref> is an exemplary webpage from a physician's website for online booking according to one embodiment of the invention;

0098<figref idref="DRAWINGS">FIG. 10</figref> is a flow diagram illustrating the operation of one embodiment of a software product for extracting appointment scheduling information from a physician's practice management system according to one embodiment of the invention;

0099<figref idref="DRAWINGS">FIG. 11</figref> is an exemplary data entry webpage enabling a physician's practice group to input appointment scheduling information to an aggregator's central database according to one embodiment;

0100<figref idref="DRAWINGS">FIG. 12</figref> is an exemplary webpage for mapping physician location information according to one embodiment; and

0101<figref idref="DRAWINGS">FIG. 13</figref> is an exemplary screenshot of select data from an aggregator's database enabling identification of physicians that provide a desired service, irrespective of their specialty or sub-specialty, according to one embodiment.

DETAILED DESCRIPTION

0102Apparatus and methods are described herein for improving the content of hospital and insurance directories of healthcare practitioners, and for online booking of healthcare appointments on multiple websites, e.g. via a hospital directory website, a physician's practice group website, an insurer's website and/or a centralized service provider's (aggregator's) website. For these purposes, network based communications are required between one or more of the hospitals, insurers, physician practice groups, patients and aggregator. The block diagrams of one such communication system is illustrated in <figref idref="DRAWINGS">FIG. 1</figref> and is meant to be representative only. Suitable hardware, communication protocols and software languages for implementing the systems and methods of various embodiments of the invention are readily known to those who are skilled in the art and any discussion herein is not meant to limit the scope of the invention.

0103<figref idref="DRAWINGS">FIG. 1</figref> illustrates schematically network communications among various server computers <b>4</b><i>a</i>, <b>4</b><i>b</i>, <b>4</b><i>c</i>, and <b>4</b><i>d </i>and client computers <b>5</b><i>a </i>shown coupled together via a cloud <b>6</b> (e.g., the Internet) to communicate with one another using standard communication protocols, such as TCP/IP. The servers can be any type of server, including but not limited to a Windows, Unix, Linux and/or Apple servers. Each server may have an attached data storage system <b>3</b><i>a</i>, <b>3</b><i>b</i>, <b>3</b><i>c </i>and <b>3</b><i>d </i>for storing software applications and data.

0104In accordance with one embodiment of the invention, the network of <figref idref="DRAWINGS">FIG. 1</figref> allows communications between a centralized service provider (aggregator), multiple hospitals, multiple insurers, multiple healthcare practitioner practice groups, and multiple patients. The aggregator's server provides a network based service to the hospitals, insurers, practitioner groups, and patients, e.g. an aggregator's server <b>4</b><i>a </i>provides a web-based data processing service and interface to each of the patient computers <b>5</b><i>a</i>, practice group servers <b>4</b><i>b</i>, hospital servers <b>4</b><i>c</i>, and insurance provider servers <b>4</b><i>d</i>, and can also communicate electronically via email with each of these computers and servers. The aggregator's server also communicates (e.g. web-based) with each of the practice groups, hospitals and insurers via their respective servers for retrieving data such as available appointment times and other information for each of the practice groups, hospitals and insurers in order to enable online booking and confirmation of appointments on multiple websites. In alternative embodiments, the aggregator's service is provided to one or more hospitals, one or more insurance providers in addition to the hospital(s), or just to insurance provider(s). For ease of description, the first embodiment will discuss hospitals and not insurance providers, it being understood that the services can similarly be provided to insurance companies.

0105<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of one server <b>4</b> which includes a processor <b>8</b>, memory <b>9</b>, data storage <b>10</b>, disk drive <b>11</b>, keyboard/mouse <b>12</b>, computer display <b>13</b> and network interface <b>14</b>. The components are coupled together and communicate via a system bus <b>16</b>. Various software modules of the present invention can be loaded into data storage and during operation are transferred into memory (e.g. RAM) for execution by the processor. A user may manipulate the software and enter commands to the server using the keyboard/mouse. The input/output may be viewed on the display screen. The network interface couples the server to the Internet or whatever type of network is used to connect the server with the other computers and servers of the respective hospitals, practice groups, patients, insurers and aggregator. Further, the server may communicate with a storage array or storage network (e.g. SANS) if there is a need to access large amounts of data. A database of patient records, practice group (practitioner) records, and associated scheduling records may be implemented as a relational database and search engine with, for example, Microsoft's Active Server Page Technology, SQL Server Technology, Database Artisan Software, or database products from Oracle Corp., Redwood Shores, Calif.

0106The software described herein may be implemented as various modules, e.g. a web module, a database module, an email module, and standard application programming interfaces (APIs). The web module may include a set of templates and icons to enable the creation of web pages. It may include other tools to allow one to create browser friendly websites. These tools enable the creation of dynamic hypertext web pages to be accessed by the hospitals, patients, practice groups, insurers and aggregator.

0107The database module may include a relational database and search engine. The records, fields, search queries and other features of the database are described below and suitable alternatives will be apparent to persons who are skilled in the art.

0108The email module allows emails to be sent to/from patients, practice groups, hospitals, insurers and the aggregator via the respective server/computer. The emails can be sent manually by a person operating the server and can be automatically generated by the server. For example, the email module can be configured to automatically query the database module and send email messages to entities identified in the database module.

0109The software may include standard APIs so data and other information can be exchanged with other software systems.

0110Each practice group server may include the group's own practice management software and any other database of information used by the practitioners in that group. As described below, the aggregator may install software on the practice group's server for uploading available appointment times to the aggregator's database and otherwise automating and synchronizing the appointment calendars of the practice group and the aggregator. The relevant appointment booking information may be stored on one or both of the aggregator and practice group servers and data storage systems. Similarly, the aggregator may install software on a hospital's server and/or insurer's server for the same or similar purposes (e.g., exchange of profile information and/or appointment scheduling information).

0111The database maintained by the aggregator includes records of practitioner profile information and booking information for the practice groups and their respective practitioners, the hospitals and their affiliated practitioners, the insurance providers and their participating practitioners, and each patient who establishes an account with the aggregator. These records will be described further below in various embodiments.

0112Various systems and methods for aggregating available appointment times for multiple practitioner groups, including search and display algorithms are described in the following co-pending and commonly owned US patent applications: <ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0000"><ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0113">U.S. Ser. No. 12/210,664 filed 15 Sep. 2008 entitled: CENTRALIZED MARKETPLACE FOR HEALTHCARE APPOINTMENTS ACROSS PRACTICE GROUPS;</li><li id="ul0022-0002" num="0114">U.S. Ser. No. 12/210,690 filed 15 Sep. 2008 entitled: CONSUMER PORTAL FOR HEALTHCARE APPOINTMENTS ACROSS PRACTICE GROUPS;</li><li id="ul0022-0003" num="0115">U.S. Ser. No. 12/210,765 filed 15 Sep. 2008 entitled:</li><li id="ul0022-0004" num="0116">DATA SYNCHRONIZATOIN FOR BOOKING OF HEALTHCARE APPOINTMENTS ACROSS PRACTICE GROUPS; and</li><li id="ul0022-0005" num="0117">U.S. Ser. No. 12/210,716 filed 15 Sep. 2008 entitled:</li><li id="ul0022-0006" num="0118">PATIENT VERIFICATION FOR BOOKING OF HEALTHCARE APPOINTMENTS ACROSS PRACTICE GROUPS. <br /> the entire contents of which are hereby incorporated by reference as if fully set forth herein. </li></ul></li></ul>

Physician Profile Information

0119As used in this application, healthcare practitioners includes one or more of physicians, physician assistants, nurses, chiropractors, mid-wives and other providers of healthcare services. As used herein, physicians is meant to include both physicians and other healthcare providers. Patients includes existing patients (of a given healthcare practitioner) and prospective patients.

0120Physicians and other healthcare providers are frequently affiliated with one or more hospitals. Traditionally, in order to update their profile data, they have been required to separately communicate changes to each hospital with which they are affiliated. In addition, the required profile data may differ for each hospital. This leads to a decrease in practitioner compliance with communicating changes to their affiliated hospitals, and as a consequence means that the hospital directories frequently contain outdated or incomplete information.

0121According to one embodiment of the invention, an apparatus and method are provided to enable a practitioner to enter their profile information once, to a single database, for all of their affiliated hospitals and practice groups. In this embodiment, an aggregator manages and maintains the database, along with related processes for data entry and retrieval, search, and display. The data fields are standardized so that the data can be used across multiple institutions (hospitals and practice groups) while being input with a single data entry. A data entry mask may be provided that dynamically changes based upon the combination of affiliated hospitals for a given practitioner.

0122The practitioner profile information is stored in a central database maintained by the aggregator. For ease of description, this embodiment will refer to a physician as the healthcare practitioner, and multiple affiliated hospitals of the physician as the intended recipients of the physician profile information for their respective hospital directories.

0123Every physician is assigned an individual unique identifier by the aggregator for identification and mapping of data. This identifier can be used for the purposes of enabling the physician to edit his/her own profile information, identify which hospital(s) should receive his/her profile information, and review the status of the credentialing process being performed by the various affiliated hospitals. This identifier is different for each physician in the aggregator's database and facilitates the credentialing process. There is currently no unique identifier for every physician which hospitals, insurance companies and others can use to identify a specific physician. For example, the government assigns an NPI number (National Provider ID) to physicians that accept Medicare and Medicaid patients, but there is no NPI number for doctors who do not accept these government insurance plans. Furthermore, because the NPI system was fairly recently established, there are many physicians who have never updated their profiles to include their NPI number. This has greatly hampered efforts to accurately identify a specific physician across multiple databases.

0124<figref idref="DRAWINGS">FIG. 3</figref> is an example of a web page <b>20</b> from an aggregator's website which serves as a template for enabling a physician to enter his/her profile information. The physician profile may then be stored as one data record in a central database managed by the aggregator. Here, the web page includes a box <b>21</b> identifying the physician by name, a box <b>22</b> for his/her username for accessing the aggregator's website, and an entry box <b>23</b> for the designated physician to enter a professional statement. Below this, are a plurality of boxes identifying the physician's NPI number <b>24</b> and previously entered profile information such as job title <b>25</b>, department <b>26</b>, professional suffixes <b>27</b>, and specialties <b>28</b>. Beside each entry in the respective profile blocks <b>25</b>-<b>28</b>, is one of three different credentialing “status” indicators (identified in the right-hand box <b>29</b>), namely: a check mark for an approved status <b>30</b>, a minus in a circle mark for a rejected status <b>31</b>, and a dot in a circle mark for an awaiting credentialing status <b>32</b>. The physician can thus monitor the status of the credentialing process by the aggregator and the one or more affiliated hospitals (identified in box <b>33</b>), on the aggregator's website. The profile information further includes a photo <b>36</b> of the physician, which is made available to the affiliated hospitals for their directories, and buttons <b>37</b>, <b>38</b> for editing or adding additional photos. An edit button <b>34</b> is provided in the various profile information boxes for editing the contents.

0125The fields presented to a given physician on the aggregator's website changes dynamically depending upon which hospitals the physician is affiliated with. When a doctor enters an additional, previously unknown hospital affiliation on the aggregator's webpage, the additional fields required for this hospital are searched for and obtained in the aggregator's database, and then automatically added to the data entry mask for that physician. Thus, every physician is not required to enter and maintain the entire set of profile information fields available on the aggregator's website and database, but rather the aggregator automatically provides a more limited subset of required profile information for the hospitals affiliated with a given physician. This reduces the time required for the physician to enter the necessary profile information, and thus increases compliance with and the maintenance of up-to-date and complete information.

0126Each hospital needs to maintain control over which information appears on their directory to ensure both accuracy and relevance for their patients. Typically, a hospital will select only a subset of the available physician profile information to be displayed on its directory, and they may choose to verify some or all of the information provided. This makes it difficult for a doctor with multiple hospital affiliations to determine which data needs to be provided to which hospital. As a result, a hospital has historically employed a team of people to request information from the doctor, manually decide which part of the information needs to be verified, and manually update the hospital directory. This process is costly, slow, error prone and frequently incomplete.

0127In accordance with one embodiment of the invention, an aggregator provides a service for doctors to enter profile information once to the aggregator's database; the profile information is then made available to various affiliated hospitals of the practitioner but will not be included in a hospital directory until it complies with a set of rules defined by the respective hospital. In one example, these rules can: <ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0000"><ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0128">generally exclude select categories of information from the hospital directory;</li><li id="ul0024-0002" num="0129">automatically post updated information in select categories to the hospital directory;</li><li id="ul0024-0003" num="0130">require human approval before information in select categories appears in the hospital directory.</li></ul></li></ul>

0131These rules can be implemented on a “field” level, i.e., based on individual fields in each data record, and the fields can be standardized for use across different practice groups and hospitals.

0132The aggregator's database stores a respective item of profile information in an associated field, whether this field is excluded, automatically included, or requires human review by one or more of the affiliated hospitals. In addition, for every item of information provided by a doctor, the aggregator's system stores the status of this item in the database, e.g., automatically excluded, automatically reviewed, pending human review, accepted by a human reviewer, rejected by a human reviewer, and the identity of the human reviewer.

0133The human reviewer at the respective hospital has credentialing software, provided by the aggregator, to perform the credentialing process. <figref idref="DRAWINGS">FIG. 4</figref> shows one example of a data entry display screen <b>40</b> enabling a hospital reviewer to perform the credentialing process. At the top of the display, a set of five filter windows <b>42</b> are provided prompting the reviewer to enter or select from a pull down menu the following items: first name <b>43</b>, last name <b>44</b>, approval status <b>45</b>, document status <b>46</b> and provider package <b>47</b>. The reviewer enters the appropriate information and then clicks the filter button <b>48</b>, initiating a search of the hospital database for the entered information. Below the filters is a specialties window <b>50</b> with five columns across the window, namely, Approval Id <b>51</b>, Professional Id <b>52</b>, Professional Name <b>53</b>, Added Specialty <b>54</b>, and Approve/Reject <b>55</b>. Each of these column headings identifies a field for credentialing each practitioner and specialty in the hospital directory. Each row <b>56</b> in the window represents a practitioner/specialty pair, enabling the reviewer to approve or reject such pair, prior to inclusion in the hospital directory. The above details are just one example of a credentialing process and not meant to be limiting.

0134Each hospital maintains its own directory review process whereby profile information provided by the aggregator to the hospital is subject to the hospital's own review and approval prior to acceptance and entry into the hospital directory. Each hospital may maintain different content in their hospital directory, i.e., different fields of profile information for a respective practitioner. <figref idref="DRAWINGS">FIG. 5</figref> shows one example of a listing from an online hospital directory for an affiliated physician. Below a running head <b>61</b> identifying the hospital, and below a series of links identifying various webpages on the hospital website, there is a display <b>63</b> of text, photos and graphics concerning one individual physician and his affiliated profile information. This hospital directory also includes a window <b>64</b> to enable immediate online booking of an appointment with the associated physician. This online booking feature will be described in a subsequent section.

0135Here the physician's profile includes, on the upper left-hand side of the webpage, the physician's name <b>65</b>, contact information <b>66</b>, link to his practice group website <b>67</b>, specialties <b>68</b>, department <b>69</b> and job title <b>70</b>. Next to these windows on the right-hand side, is another window <b>72</b> with a geographical display (street map) identifying the location of the practitioner's office by a numbered marker (here identified by the number “1”). In the event that the practitioner has multiple office locations, there would be multiple differently numbered location indicators.

0136The hospital directory page further includes, along the left-hand margin going from the middle to the bottom of the page, a plurality of text boxes with descriptive profile information and/or links to other web pages on the same or a different website. For example, one box <b>74</b> includes a list of the insurances accepted by the physician, with links <b>75</b> to the respectively identified insurance plans. Another box <b>76</b> contains the physician's professional statement, and a link <b>77</b> to a more complete statement. Another box <b>78</b> lists the physician's education (schools/degrees). Another box <b>79</b> lists the languages spoken by the physician. Another box <b>80</b> lists the board certifications. A further box <b>81</b> lists the professional memberships of the physician. Another box <b>82</b> lists the states in which the physician is licensed. The lowermost box <b>83</b> on the left-hand side contains a link to the physician's practice group website.

0137The profile data entry and credentialing process previously described may be implemented in various apparatus and methods according to various embodiments of the invention. In one such embodiment, the aggregator may send the physician an email containing a link with a unique identifier which when clicked, brings the doctor to a specially prepared webpage that allows the doctor to edit his/her profile. Each identifier is matched to exactly one physician profile. The doctor registers with a password that allows him/her to log in later without requiring an initial email from the aggregator. The unique identifier may be used by each of the aggregator, physician, physician practice group, and physician affiliated hospitals, for obtaining access to profile information in the aggregator's database for a specific physician.

0138Once a physician has registered with the aggregator and is signed onto the aggregator's website, the physician can access a webpage, e.g., similar to that shown in <figref idref="DRAWINGS">FIG. 3</figref>, to edit his/her profile information, e.g., by clicking on the edit button <b>34</b> in the respective window of the profile information to be edited. In one example, illustrated in the flow chart of <figref idref="DRAWINGS">FIGS. 6</figref><i>a</i>-<b>6</b><i>b</i>, a physician has added an affiliation with an additional hospital in their profile editor on the aggregator's webpage <b>90</b>. The doctor is then invited, via a popup window on the webpage, to join the hospital directory of the newly identified hospital <b>91</b>. The popup window may identify the process by which this occurs, e.g. <ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0000"><ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0139">1. The aggregator sends the physician an email or phone call to confirm his/her identify <b>92</b><i>a</i>; either the physician confirms the email account or phone number <b>92</b><i>b</i>, or the aggregator or hospital attempts to verify <b>92</b><i>c </i>(e.g. by calling the hospital department in which the physician practices);</li><li id="ul0026-0002" num="0140">2. The hospital verifies the affiliation <b>93</b>;</li><li id="ul0026-0003" num="0141">3. The aggregator emails the physician verification of the affiliation <b>94</b>;</li><li id="ul0026-0004" num="0142">4. The hospital credentialer reviews the submitted profile information <b>95</b>; and</li><li id="ul0026-0005" num="0143">5. If the profile information is approved (in Step 4), the original or edited physician profile information will be added to the hospital's directory <b>96</b>.</li></ul></li></ul>

0144By clicking a continue button in the popup window, the physician may elect to begin this credentialing process. A new record will then appear in the hospital's credentialing process, such as that illustrated in <figref idref="DRAWINGS">FIG. 4</figref>. After completing an original profile entry or edit to the profile, the hospital and/or aggregator may prompt the physician to sign up for an online appointment booking process.

0145In another example, a physician may edit his/her profile on the aggregator's website to update or modify a particular profile data entry. In this case, the hospital credentialing reviewer will receive automatic notice (e.g., alert) of the new entry, and again will decide whether to accept or reject the entry.

0146<figref idref="DRAWINGS">FIG. 7</figref> shows one example of a process enabling the hospital to compare new and existing profile information. In the left column of the screen <b>100</b> is the existing profile information <b>102</b> from the hospital's directory and database for the identified physician. In the right column is the new profile information <b>104</b> with each field located in the appropriate row next to the existing profile information. For example, here there are three new procedures <b>105</b> listed for this physician in the Procedures row, and a new professional statement <b>106</b> in the appropriate row. The hospital will apply its own rules for deciding whether to include, approve or reject the new procedures before merging any newly submitted procedures for inclusion on the hospital's website. All non-rejected items on the left profile (existing hospital record) have been copied to the new affiliate profile with their hospital credentialing status intact (i.e., if the hospital had previously approved an item on the existing profile, it will be approved on the new profile). All of the new affiliate data is marked as uncredentialed for the hospital. After all of the data has been copied to the new profile, the new profile is associated with the hospital and the existing profile is marked as deleted.

0147One important piece of profile information, especially for facilitating online booking of appointments, is the physician's insurance acceptance information. Unless this information is up-to-date and complete, a prospective patient cannot in most cases decide whether to select a particular physician i.e., a patient is unlikely to select a physician unless he knows the physician accepts his insurance plan. Thus, maintaining up-to-date insurance information in hospital directories is very beneficial if the hospital wishes to generate new patients for its affiliated physicians via its hospital directory.

0148In accordance with one embodiment of the invention, a process is provided for maintaining accurate and complete insurance information. Historically, there has been no common identifiers for doctors in both hospital and insurance directories, i.e., which would enable a hospital to quickly determine whether a physician affiliated with the hospital accepts a given insurance plan. For example, if a hospital has a doctor whose name is “James Smith” and there is a doctor named “James Smith” in the Aetna insurance directory, the hospital cannot be sure if this is the same James Smith and add this insurance information to the physician profile on the hospital directory. Still further, doctors do not always accept the same insurance plan at all of their locations. As a result, hospitals either do not show insurance information or they need to employ teams of people to call the doctors' offices and obtain the insurance information from the doctors' receptionists.

0149Not showing insurance information significantly reduces the effectiveness of a hospital directory, in terms of acquiring new patients for the hospital's affiliated physicians. Calling doctors' offices is very resource intensive and error prone, as the office staff is frequently not informed about recent changes and/or about insurance plans that have a low market share.

0150In accordance with one embodiment of the invention, it has been determined that a geographic location indicator can effectively enable one to determine whether or not a specific doctor matches an entry in an insurance company's online physician directory. While there may be hundreds of James Smith in New York City, it is highly unlikely there is more than one at a given location. Still further, matching doctors to insurance by name and location also solves the problem of accurately stating insurance acceptance for doctors that accept different insurance plans at different locations.

0151However, determining whether two locations are in fact the same is a problem in and of itself. Addresses are often spelled differently (street, st.), and often information such as suite number is omitted in some cases and is present in other cases. Thus, simple string matching of listed street addresses is not adequate to determine if two addresses are the same.

0152By way of example, the following three addresses may appear in different databases by a physician for a given name:

0153112-03 Queens Boulevard;

015411203 Queens Boulevard;

015511203 Queens Boulevard, Ste. 206.

0156If one were to try to match any of the three addresses above by string matching, it would appear that they are three distinct locations.

0157To solve this problem in accordance with one embodiment of the invention, a physician office location is classified by geographic coordinates, e.g. a geocode, to create a geographic location indicator which can be used to enable more accurate matching of a doctor to an insurance company's online directory entry, regardless of how common the doctor's name is. With a now reliable way to match doctors to entries in insurance directories, this process can be automated, and the aggregator and/or hospital can search insurance directories periodically for their doctors to find entries that match a specific doctor. This can be done by a computer, rather than requiring a fully staffed call center, saving many hours of work. The doctors' profiles can then be automatically updated with additional insurances, and/or the doctors can be notified that they should update their profiles to include these additional insurances. The net result is physician profiles with more accurate and up-to-date insurance information.

0158A geocode (Geospatial Entity Object Code) is a combination of geospatial attributes that provides an exact location of a point on the surface of the earth. Mandatory attributes included in a geocode are latitude and longitude. Other voluntary attributes are the date, local time, global time, coordinate reference system, and sensor accuracy. The aggregator can geocode the address information provided by a physician (e.g. map a street address to geographic coordinates), and also geocode the address information provided by an insurance directory, and then compare the two geocodes to determine if they match. This process can be automated by computer search, geocoding, and comparison algorithms, to produce a substantially more accurate and less error prone result than a manual comparison. Methods for geocoding are well known to a person skilled in the art and commercially available. For example, see http://code.google.com/apis/maps/documentation/services.html#Geocoding.

Online Booking Across Multiple Websites

0159Doctors are reluctant to be “locked into” an online appointment booking service that is only available on one hospital website. Typically they want to provide online booking on their own group practice website. However, they also do not want to miss out on patients that might find them on an affiliated hospital directory.

0160There are many natural impediments to online booking of healthcare appointments across multiple websites. As with the profile information previously described, there are many variables involved in the booking of appointments which are either not understood or not consistent between different practice groups and different affiliated hospitals. Also, doctors typically have limited technical experience and expertise with implementing new software systems so any solution must be easy to implement.

0161In accordance with one embodiment of the present invention, apparatus and methods are provided for implementing online booking of healthcare appointments across multiple websites. An aggregator hosts an online booking functionality as a service that allows healthcare appointments to be available simultaneously on two or more of a hospital directory website, a doctor's practice group website, an insurance provider's website and an aggregator's website. Patients can book an online appointment on any of these sites and availability is updated immediately.

0162An online booking service is described in the previously identified co-pending and commonly owned patent applications, which are incorporated herein by reference in their entirety. As described therein, an aggregator maintains a central database and website for online booking of physician appointments across multiple practice groups. This online booking functionality can be extended to include one or more hospital websites, physician practice group websites and insurance provider websites by providing software (e.g. a Java script) embedded on the hospital and/or physician practice group and/or insurance provider websites. An example of a suitable script <b>110</b> for a physician practice group by the name “Premier Dental Associates of Lower Manhattan” is shown in <figref idref="DRAWINGS">FIG. 8</figref>.

0163JavaScript is commonly used to write functions that are embedded in or included from HTML pages and interact with the Document Object Model (DOM) of the page. The JavaScript code can run locally in a user's browser (rather than on a remote server) and thus respond to user's input actions quickly, making an application feel more responsive. In this example, the aggregator's database contains available appointment information for a plurality of practice groups, and depending upon the specific hospital or practice group website accessed by a patient, the aggregator searches for and retrieves the relevant appointment information for that practice group or affiliated doctors of the hospital. As used throughout this application, patient includes a prospective patient. In one implementation, JavaScript embedded in the practice group's website loads yet another JavaScript from the aggregator's server, which in turn fetches the appointment data from the aggregator's database and displays it on the practice group's website. This 2-layered approach makes it easier to update the underlying JavaScript and available scheduling data centrally.

0164<figref idref="DRAWINGS">FIG. 9</figref> illustrates one example of a doctor's website utilizing an embedded script. A home page <b>112</b> on the physician's practice group website includes a variety of descriptive information concerning the practice group. A window <b>114</b> appears on the page showing available appointment times for a plurality of physicians in the group. In this example, the physicians are listed along the left-hand margin each with a photo and a link to their profile information. To the right of each physician is an array of links with individual available appointments by date and time for that physician. Once the patient has elected a specific appointment date and time, by clicking on the link for that appointment, the patient is then connected to a webpage from the aggregator's website to complete booking of the online appointment.

0165As previously described, providing online booking functionality from a hospital's physician profile directory would be very desirable for hospitals (e.g., for attracting patients). However, knowing a doctor's availability is a challenge. Even if the doctor is employed by the hospital, only a minority of hospitals utilize centralized scheduling processes. For doctor's who run their own practices with their own practice management systems, this task is even more difficult. Attempts by hospital systems to incentivize doctors to migrate to the hospital scheduling system have typically failed, because it requires the physician to change their ongoing scheduling process, it locks in the doctor to a particular hospital, and the scheduling software is frequently part of a larger and more extensive practice management system (which would need to be modified).

0166Even access to a practice group's scheduling system is generally not sufficient to automate scheduling, as most schedules only provide “positive” information, i.e., what times the physician is booked. Much of the scheduling context, i.e., what time the doctor is in the office, which procedures can be done at which times, and which resources may be required (e.g., a special instrument) for each procedure, are generally known to the office manager and not captured in a scheduling system.

0167In accordance with one embodiment of the invention, software tools are provided to enable physicians to maintain their current work flow and software processes, while information is extracted from their existing scheduling/practice management system to an aggregator's centralized server. As illustrated in the method of <figref idref="DRAWINGS">FIG. 10</figref>, the aggregator provides software to: <ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0000"><ul id="ul0028" list-style="none"><li id="ul0028-0001" num="0168">collect (read) existing scheduled appointments from a group's practice management system and store the collected data on the aggregator's server <b>120</b>;</li><li id="ul0028-0002" num="0169">process the collected data on the aggregator's server to filter out the previously scheduled appointment times and create a “negative” view of the time(s) the doctor(s) are available <b>122</b>;</li><li id="ul0028-0003" num="0170">interact with the group's office staff through a two-way communication software (e.g., “alerter”) that intelligently asks the office staff questions not reflected in the scheduling software regarding times available for booking online <b>124</b>, e.g., public holidays, doctor vacations; for example, the system may ask “Is the doctor working on President's Day?” a few days before the actual holiday;</li><li id="ul0028-0004" num="0171">store the available appointment times on the aggregator's server <b>126</b>.</li></ul></li></ul>

0172Software for collecting, processing and storing such appointment data on the aggregator's server is described in the previously identified applications.

0173In one example, a physician practice group has its practice management system (software and data) residing in a data store in the doctor's office. A windows service (provided by the aggregator) is installed on the doctor's server that polls the doctor's practice management database to detect changes in the physician(s) schedule. In another example, the doctor's office is using a web hosted management system; in this case, the aggregator provides software that sends web requests to the hosted site, and parses the HTML that is returned to read the doctor's availability. In another example, when the physician's database server is not available, and the system is not hosted as a website, an aggregator provides software that navigates through the group's practice measurement system and captures screenshots of the doctor's schedule. The aggregator's software is able to determine availability by evaluating the color and position of the pixels in the screenshot.

0174The aggregator may also provide a web interface for the practice group to input variables that may not be available on the group's practice management system. These may include a physician's working hours, vacation times, appointment-specific times, location-specific times, and unavailable times in the schedule that the practice management system does not specify. The aggregator's software then creates a “negative” view of the available appointments by filtering out the times the doctor is not available.

0175In the following example, the practice group can input variable information to the aggregator's website, which then restricts the available appointment times that the integration software (provided on the practice group server) will upload to the aggregator's server. <figref idref="DRAWINGS">FIG. 11</figref> shows a screenshot <b>140</b> on the aggregator's website for inputting such variables. At the top of the webpage, the physician and particular practice group <b>141</b> logged into the site is identified. Two windows <b>142</b>, <b>143</b> enable a user to input a practice group and location. Below this, tabs <b>144</b> to alternative webpages can be selected for accessing each of Working Hours, Configuration, Availability Grid, and Logs. The Working Hour's page is displayed in a window <b>146</b> having a grid (array) of boxes <b>148</b> for inputting beginning and ending times in the morning and afternoon hours for each of the seven (7) days of the week. Links <b>150</b> are provided to select “more options” if the array provided is not sufficient. Along the left-hand margin, one particular physician in the list <b>152</b> has been designated, for which the working hours will be input. A further link <b>154</b> is provided to prompt the user to set up holiday and vacation times. Once the appropriate information has been entered, the user clicks the save button <b>156</b> to enter the information to the aggregator's database. Additional webpages may be provided for entering holiday and vacation times, location information, and procedure types.

0176In one embodiment, the aggregator's web interface provides an easy way to map a specific item in the local practice management system to the associated item in the aggregator's database. For example, <figref idref="DRAWINGS">FIG. 12</figref> shows a screenshot <b>160</b> under the Configuration tab, for mapping location information. On the left-hand side is a list <b>162</b> of the different practice group locations as identified in the group's practice management system. These have been linked (by row) to the corresponding aggregator's location identifier in the list <b>164</b> on the right-hand side. In some cases, there is no corresponding location in the aggregator's location field, so it is marked “not mapped.”

0177In another embodiment, if the doctor's scheduling software has the ability to make certain times available for specific procedures, the aggregator's web interface will allow the doctor to map the procedure type to the aggregator's doctor's procedure type. When a patient specifies a reason for a visit on the aggregator website, the aggregator website will then only display times that the doctor is available for that specific procedure.

0178Because there are many different practice management systems in use today, there are many different ways that each system implements various functions. Because the aggregator's system performs the mapping to accommodate different group software systems, each group can continue to use its respective practice management system while also providing the necessary information to synchronize the appointment availability information for booking across multiple practice groups and multiple websites.

0179As a further example, there is currently no standard layman's nomenclature for medical procedures, and thus searching for doctors who provide a particular procedure requires a significant amount of knowledge and investigative work on the part of the patient. Typical hospital directories are limited to listing doctors by specialty. However, not every doctor within a specialty will perform a given procedure (e.g., not all primary care doctors give flu shots), and the same procedure may be done by doctors in more than one specialty (e.g., flu shots may be given by primary care physicians, ob-gyns, pediatricians, and sometimes others). In order to give a patient an overview of his/her options, the patient would need to have an overview of all doctors who can perform a desired procedure, not limited by speciality. No accepted commercial system is currently available for patient use for this purpose.

0180In accordance with another embodiment of the invention, an aggregator provides a list of standardized procedures which are mapped across specialties. In the above example, if the patient searches for a flu shot after selecting ob-gyn as a specialty, primary care doctors performing this procedure will also be listed. During the profile creation, each physician indicates which procedures he/she performs.

0181<figref idref="DRAWINGS">FIG. 13</figref> shows one example of a screenshot <b>170</b> from the aggregator's database interface for implementing such mapping. The first column <b>172</b> is the specialty and sub-specialty, the second column <b>174</b> is the procedure, and the last column <b>176</b> lists all the (sub)specialties that can potentially offer the procedure listed in the second column. Thus, for any given specialty/procedure pair in the first two columns (i.e., for each row of the database shown in <figref idref="DRAWINGS">FIG. 13</figref>), when one or the other is selected by the patient the last column indicates all of the specialties and sub-specialties that should be searched to determine which physicians can perform the desired procedure, despite the patient failing to request the specialty. This organization of the database and search process on the aggregator's database enables an identification of doctors who provide the desired service, irrespective of their specialty or sub-specialty.

Insurance Providers

0182The previously described embodiments were directed to hospital directories containing profiles of physicians with multiple hospital affiliations. These embodiments are equally applicable to insurance provider directories containing profiles of physicians with multiple insurance participations. Such alternative embodiments will not be repeated herein, but rather the prior embodiments should be understood to include an insurance directory instead of a hospital directory, or both an insurance directory and hospital directory. Thus, the aggregator's central database, online booking functionality and credentialing software, can be run concurrently for one or more of multiple hospitals, multiple insurance providers, or both.

0183As previously described, insurance companies have a great incentive to facilitate patient access to a physician within the insurer's network of approved physicians, e.g., to comply with statutes that may require the insurer to provide an appointment within a specified time and/or to reduce the high cost of emergency room visits by instead providing an appointment with a physician in the physician's office. The categories of physician profile information provided on an insurance directory may typically include, in addition to those previously identified, the doctor's gender, the hospital affiliation(s), name, and office location(s). The previously described credentialing process is also of great benefit to insurers as strict credentialing requirements are often imposed by state law on insurance providers.

0184Thus, it should be understood that all of the previous embodiments are equally applicable to insurance provider directories and booking of appointments on the insurers' websites.

System, Method and Computer Program

0185As will be appreciated by one skilled in the art, the present invention may be embodied as an apparatus or method, including a computer system or computer program product. Accordingly, unless specified to the contrary, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code stored in the medium.

0186Any combination of one or more computer-usable or computer-readable medium(s) may be utilized, unless specified to the contrary herein. The computer-usable or computer-readable medium may be, for example but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor storage mediums. More specific examples (a non-exhaustive list) include: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CDROM), an optical storage device.

0187Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++, C#, JavaScript/Ajax and similar programming languages. JavaScript, which relies on a runtime environment in a web browser, is commonly used for website development (e.g., writing functions that are embedded in or included from HTML pages). JavaScript can be used as a scripting language for implementing an Ajax-embedded webpage. Unless otherwise specified, the program code may execute entirely on a user's computer, partly on the user's (e.g., server or client) computer, as a stand-alone software package, partly on a user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

0188A website is a collection of web pages posted on one or more web servers, accessible via the Internet. A webpage is a document, typically written in [X]HTML, that is generally accessible via HTTP, a protocol that transfers information from a web server to a display in the user's web browser. The collection of publically accessible websites are referred to as the “World Wide Web”.

0189Websites are written in, or dynamically converted to, HTML (hyper text mark-up language) and are accessed using a software interface known as the user agent. Web pages can be viewed or otherwise accessed from a range of computer-based and Internet-enabled devices of various types, including desktop computers, laptop computers, PDA's and cell phones. A website is posted on a computer system known as a web server, and it includes software that retrieves and delivers the pages in response to requests from the website users.

0190A dynamic website presents variable information that is tailored to particular users. It may accept the user's input and respond to a user's request. For example, the user can enter text into a data entry field or form or select highlighted (linked) options, which prompts the website to fulfill the request and return a unique result. The aggregator's website, accessible in various forms to patients, hospitals, insurers and practice groups, includes such dynamic functionality.

0191A link or hyperlink, is a reference or navigation component in a document to another section of the same document or to another document on a different domain. A web browser usually displays a link in some distinguishing way, e.g. in a different color, font or style. When the user activates the link (e.g. by clicking on it with the mouse) the browser will display the target of the link.

0192As used herein, database and central database are not meant to be limiting, and may reside in one or more locations and/or data repositories. The aggregator's database is referred to as a central database to distinguish it from the separate multiple databases of the unaffiliated practice groups from which the aggregator combines (aggregates) the available appointment times to be offered on the aggregator's website.

0193The aggregator can, by collecting and storing this available appointment data from a plurality of unaffiliated practice groups, provide a much larger database of available appointment times/specialties/procedures and can allow patients to book appointments directly with the aggregator, without requiring the patients to contact the practice group in any manner (by phone, email or practice group website).

0194The present invention is described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

0195These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

0196The flowchart and block diagrams illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

0197By way of example only, various described embodiments may be implemented on processor based servers, such as any x86_—64 processor based server, for example running a Windows Operating System, e.g. Windows Server 2003, Windows XP/Vista, including Microsoft's NET Framework (e.g. Net 2.0). The database programming may be implemented in the SQL programming language (e.g. MS SQL 2005 and TSQL).

0198Modifications can be made to the previously described embodiments of the present invention and without departing from the scope of the invention, the embodiments being illustrative and not restrictive.