WO2002001483A2 - Patient health record access system - Google Patents

Abstract

An integrated system provides patients with secure, real-time access to their Personal Health Record and an Enterprise Health Information System (PHR and EHIS, respectively). Access may be provided by way of the Internet and via a Personal Health Portal (PHP) web page. From the secure PHP web page, patients can view information created and maintained by their health care providers and their affiliated staff. The patients can also request services and information from their health care providers and affiliated staff, directly access EHIS-related services, such as scheduling an appointment, scheduling, paying a bill, enrolling in a class, completing insurance and other forms, and viewing information and Internet services that are relevant to their particular health status.

Description

PATIENT HEALTH RECORD ACCESS SYSTEM

Field of the Invention

The present invention relates generally to health records management, and more particularly, to a system for providing a patient with access to the patient's health record^

Background of the Invention

A variety of Internet-based systems for providing access to a patient's health record and related healthcare information have been proposed. Such Internet-based personal or patient medical records either provide patients access only to information that they enter and maintain themselves, or provide them with delayed and limited access to information contained in a separate healthcare information system from which patient health information must be abstracted and uploaded to a web server in regularly scheduled batch processes. A patient is unsure if the information they are viewing is the most up to date and complete. Apart from the ability to view selected portions of information or patient self-generated information, the proposed systems have not provided an effective forum to allow the patient to communicate with their health care providers. None of the proposed systems feature secured, realtime access to an integrated patient health record.

Many attempts have previously been made to streamline the process of scheduling appointments for patients in the healthcare industry. From a healthcare organization's point of view, the most efficient method is to let patients schedule appointments themselves. However, until the advent of the Internet, this solution was not feasible. Now, the Internet has provided patients with direct access to an organization through the web, thereby opening up the possibility of self-scheduling. Nevertheless, self-scheduling over the Internet presents unique and interesting problems. For example, there are always security issues when dealing with medical information on the

Internet. Also, if the system is not implemented properly, patients could abuse the system. Furthermore, Healthcare providers, such as doctors, nurses, and surgeons often have concerns that they are losing control of their daily schedules if they allow patients to schedule their own appointments.

The existing scheduling solutions are based on messaging or very restricted access. These solutions allow patients to enter some limited information concerning an appointment. Some examples are: (1) which provider the patient wants to see, (2) the day and time the patient wants to be seen, (3) some of the patient's insurance information, and (4) a few other types of information relevant to scheduling.

After requests were submitted in the previous systems, workers at the clinics were then required to review each of the requests and contact every patient individually to inform him or her whether or not the request was granted. While this process is somewhat convenient for the patients, it does not automatically schedule appointments or immediately enter the data into the organization's system. Rather, it relies on human intervention to evaluate the requests and contact the patients when the decision to schedule the appointment has been made.

Thus, there is a need for a patient health record access system that provides real-time communication between the patient and an integrated Patient Health Record (PHR) and an Enterprise Health Information System (EHIS). Such a system would provide patients with the most up-to-date information. Moreover, patients could avail themselves of electronic health- related services in real-time. Furthermore, a real-time, integrated PHR/EHIS system could provide efficiency, workflow flexibility and connectivity between patients and their health care providers and affiliated staff that are not available using previously disclosed systems.

There is also demonstrated a need for healthcare organizations to allow the full scheduling of appointments over the Internet in an automated process that gives patients immediate results and eliminates the need for employees of the facility to review each request for an appointment. None of the previous systems satisfied this need. Brief Description of the Drawings

FIG. 1 is a system block diagram of a patient health record access system in accordance with a preferred embodiment of the invention.

FIG. 2 is a flowchart illustrating operation of the system illustrated in FIG. 1.

FIG. 3 is a flowchart illustrating operation of a content relevancy engine portion of the system illustrated in FIG. 1.

FIG. 4 is a flowchart illustrating operation of the system illustrated in FIG. 1 for viewing of information by the patient. FIG. 5 is a flowchart illustrating operation of the system illustrated in

FIG. 1 for processing messages.

FIG. 6 is a flowchart illustrating operation of the system illustrated in FIG. 1 for accepting and recording information from a patient.

FIG. 7 is a flowchart illustrating operation of the system illustrated in FIG. 1 for scheduling appointments in accordance with a preferred embodiment of the invention.

FIG. 8 is a flowchart illustrating operation of the system illustrated in FIG. 1 for scheduling appointments in accordance with another preferred embodiment of the invention. FIG. 9 is a flowchart illustrating operation of the system illustrated in

FIG. 1 for providing class enrollment.

FIG. 10 is a flowchart illustrating operation of the system illustrated in FIG. 1 for paying bills.

FIG. 11 is a flow chart representation of the path that the system would take when a patient attempted to schedule an appointment directly from the system.

FIG. 12 is a flowchart that illustrates the process by which a user logged in to his Patient Health Portal (PHP) Web Page can schedule an appointment that has been pre-qualified. FIG. 13 is a flowchart illustrating the components and connections from the enterprise healthcare information management system through the Internet and on to the patient via a web page portal. Detailed Description of the Preferred Embodiments

An integrated system provides patients with secure, real-time access to their Personal Health Record and an Enterprise Health Information System (PHR and EHIS, respectively). Access may be provided by way of the Internet and via a Personal Health Portal (PHP) web page. From the secure PHP web page, patients can view information created and maintained by their health care providers and their affiliated staff. The patients can also request services and information from their health care providers and affiliated staff, directly access EHIS-related services, such as scheduling an appointment, paying a bill, enrolling in a class, completing insurance and other forms, and viewing information and Internet services that are relevant to their particular health status.

In a preferred embodiment of the invention a patient health record data server, including a machine-readable media having a data structure containing patient-created data, is coupled by a communication network with a patient interface. The communication network may be the Internet and the patient interface may be a suitable Internet access device including a browser for supporting a personalized web page. A secure interface securely couples, in real-time, the patient health record server to an enterprise health record system for providing access by the patient to patient-related data retained within the enterprise health record system. Thus, the patient, via the patient interface, may access the patient health record server for manipulating the patient- created data and for accessing the patient-related data from the enterprise health record system. According to a preferred embodiment of the invention a system that enables a patient to use a pre-authorized or a user initiated scheduling process that utilizes hierarchically-layered rules. The system further provides dynamic feedback to self-schedule appointments with a user's preferred clinics and providers in a confidential and secure manner. The rules based ticketing system for self-scheduling provides healthcare clinics and providers the ability to manage and control patient appointment utilization. For several reasons, it is very desirable from a healthcare provider's perspective to allow patients to schedule their own appointments. It is also desirable from a patient's perspective to be able to independently schedule their own appointments at their convenience through the Internet. A system according to the preferred embodiments of the invention satisfies the desires of both parties. While described in terms of several preferred embodiments, it will be appreciated that the invention is not limited in scope to the embodiments herein described. Many modifications, alterations and additions may be made without departing from the fair scope of the invention.

Referring to FIG. 1 of the drawings, a patient access system 10 includes a Patient Health Record (PHR) data server 12 and an EHIS data server 14. The PHR data server 12 may be any suitable platform including processing, memory and data storage capability to perform the functions herein described. The PHR data server 12 stores data entered by the patient within a data structure configured within the storage portion 26 of the PHR data server 12. A secure interface or EHIS queue 16 securely couples the PHR server 12 and the EHIS data server 14 for communication of data and information from the PHR data server 12 to the EHIS data server 14. The EHIS Queue 16 provides a real-time secure communication link for information moving from the PHR data server 12 to the EHIS data server 14. This queue is used to transfer information for secure messaging and self-service options. In response to information received from the PHP web page, the PHR data server 12 forwards information to the EHIS queue 16. Information in the EHIS queue 16 is then processed appropriately by the EHIS data server 14.

While the specific configuration of the EHIS data server 14 is not particular to the structure and function of the present invention, preferably, the EHIS data server 14 is a single data repository structured to support both the separation and the sharing of data. As such, the EHIS data server 14 may receive information from existing outpatient and inpatient data management systems via interfaces or from various integrated applications. The EHIS data server 14 may be configured to organize information into a consistent whole to provide a longitudinal patient record. For example, the EHIS data server 14 may be linked to manage all aspects of a patient's hospital health status and care and to support effective management of patient lists, results inquiry management, complete clinical documentation, physician order entry with decision support, nursing workflow and documentation, and discharge planning. The EHIS data server 14 may further be configured to support the inclusion of problem lists, order communications, results reporting, pharmacy management, quick documentation, clinical messaging and communication. Additionally, the EHIS data server 14 may be configured to manage referral information, up-to-date progress notes, lab results, discharge instructions, portions of a patient's record, and emergency summary cards. A suitable data management product that may be adapted as the EHIS data server 14 is the Epicenter^® Enterprise Data Repository and related suite of products available from Epic System Corporation of Madison, Wisconsin.

The PHR data server 12 includes a patient services application layer 22, a communication layer 24, a patient data manager 26 and a content relevancy engine 28, all of which are suitably linked within an architecture for operation under the direction of the PHR data server 12. The patient data manager 26 includes suitable storage capability, such as magnetic, optical, or other storage technology, for storing patient-created data. The patient services application layer 22 and the communication layer 24 include routines for managing access and use of the patient-created data, as well as to provide patient services. The PHR data server 12 is further linked, by way of the content relevancy engine 28 to a source of generic data 30 and a source of news, educational and similar materials 32 via a secure connection 34, such as a Internet protocol secure (IPsec) connection or by a file transfer protocol (ftp) connection.

A communication network 36 couples the PHR data server 12 to a patient interface 38. The communication network 36 may include the Internet 40 or other suitable data network, and the PHR data server 12 is linked to the Internet 40 by a web server 42 in a highly secure dual firewall configuration. In this arrangement, a primary fire wall 44 protects the web server 42 and a secondary fire wall 46 protects the PHR data server 12 and the EHIS data server 14 with a communication link 48 coupling the communication network 36 to the PHR data server 12.

In a preferred embodiment of the invention, a shadow server 50 is provided and maintains a copy of at least the patient-related data retained within the EHIS data server 14. A communication link 52 permits the copying of the patient-related data from the EHIS data server 14 to the shadow server 50, and a view access only communication link 56 couples the shadow server 50 to the communication network 36, and hence to the patient interface 38. This arrangement advantageously allows the EHIS data server 14 to be highly available for EHIS systems operation. Alternatively, the communication network 36 may be directly linked to the EHIS data server 14.

Patients access the system 10 by logging into the web server 42 via the patient interface 38. The patient interface 38 is preferably configured as a web page displayed within a web browser running on a suitable platform, and is further preferably configured as a personalized Personal Health Portal (PHP) web page providing the patient with patient-specific information and links to the features and services offered by the invention. The web server 42 may be any suitable web server platform containing routines for displaying the PHP web page and for managing online communication between a user logged in via an associated PHP web page and the PHR data server 12 and the EHIS data server 14.

A user logging into the system via the PHP web page may or may not be an existing patient of the healthcare enterprise. For existing patient users, the PHR data server 12 may already contain a record for the patient and, as will be described, the user is provided access to the information contained in that record. Some existing patients and new patients may not have a record within the PHR data server 12. These patients will have at least two options for gaining access to the functionality of the system 10. First, the patient may fully register by providing appropriate identifying. The PHR data server 12 creates a patient record for the user. A patient may gain access without fully identifying himself or herself. The patient may enter patient data using a user name and identifying information that is anonymous in nature. Access for this "anonymous user" may be limited to predefined functionality. For example, the anonymous user may be permitted only to view information related to services provide by the healthcare enterprise, may be able to create a record or patient created information within the PHR data server 12, may be able to ask questions of the healthcare enterprise and receive responses, and the like. The anonymous user, however, would not be permitted to make appointments or request specific services of the healthcare enterprise. Additionally, should the anonymous user become a patient of the healthcare enterprise, the PHR data server 12 may use the anonymous user record to create a patient record within the PHR data server 12 without requiring the patient to reenter information.

Operation and use of the system is described in more detail with reference to FIGS. 2-10. The flowcharts depicted in FIGS. 2-10 are linked and illustrate the operation of the system 10 in accordance with a preferred embodiment of the invention. The alpha designations indicate the interconnections between the various flowcharts depicted in the figures. Turning to FIG. 2 depicted is a method 200 of providing access by a patient to the PHR data server 12 and the EHIS data server 14. The method 200 begins at step 202 where the patient accesses a public web page, such as an Internet service provider (ISP) home page, with a PHP web page option and selects the PHP web page option, step 204. At step 206, the user attempts to log into the PHP web page, which is provided by the web server 42, using a suitable authentication technology. The web server 42 executes the authentication routine at step 208, and a user authorization determination is made at step 210. If the user is not authorized, the user is returned to the public web page. If the user is authorized, the content relevancy engine 28 functions, step 212, as will be described in connection with FIG. 3, and at step 214, the web server 42 generates and displays the user's PHP web page on the patient interface 38. From the PHP web page, the user is provided a selection of links providing access to patient-relevant content, information from the patient's enterprise health record, and services associated with the enterprise health information system. If the user does not click on a link within a timeout period causes the web server 42, at step 216, to log the user out and to return the user to the public page. At step 218 the user clicks a content link. Depending on the type of content selected by the user, step 220, if the item is stored directly in a content database or on the web server 42, at step 224 the content is displayed on the PHP web page. Otherwise, for items stored as URLs, at step 226 the data retrieval and display option associated with the link opens a separate browser page to display the content. In a preferred embodiment of the invention, the user may also select: a view option; a secure messaging option, an edit or add notes option; an online form; schedule a prequahfied appointment option; schedule an appointment option; enroll in a class option; pay a bill option or log out, respectively, links associated with blocks 228-244. Referring now to FIG. 3, the content relevancy engine 28 operates in accordance with a method 300 depicted therein. At step 302, the web server 42 requests patient-related information from the Shadow Server 14 and caches it on the PHR data server 12. This data includes the user's sex, age, zip code, medical problems and diagnoses (using ICD9 codes), procedures (using CPT codes) and medications (using GPI & NDC) as indicated at block 306. At step 304, another routine on the PHR data server 12 uses page layout specifications associated with the user's PHP web page, which may be specified by the system provider or may be user configurable, to determine what types of content to display, and how many items to display of each type. At step 308, for each type of content specified by the page layout, a routine within the content relevancy engine 28 compares the patient-related data to criteria in the content database. The content database is maintained on the PHR data server 12 and stores available content for display on the PHP web page with each record being categorized by display type, relevance factors, and effective dates as indicated at block 310. The content relevancy engine 28 at step 312 then determines if a content item is relevant based upon the cached patient-related information. At step 314, the content relevancy engine 28 then produces a ranked list of relevant content items, based on a number of matches between the content criteria and the patient-related information. Then, at step 316, the web server 42 builds the PHP web page according to the page layout (step 308), using the highest-ranking content items for each type of content.

When the user selects a link associated with a view option, secure messaging option, or self-service option, the PHR data server 12 initiates a routine associated with the link. Link 228 in FIG. 2 initiates a view content routine 400 illustrated in FIG. 4. The system 10 advantageously permits viewing of a wide variety of information types including patient-created information stored within the PHR data server 12 and patient-related information stored within the EHIS data server 14. The patient-created data may be notes and comments relating to the user's health or requests for information. The patient-related information may be portions of the user's medical record and other information created by the health care professionals and staff. In the preferred embodiment illustrated in FIG. 4, the user may select to view a health summary, a medication list, lab results, health reminders, recent visit information, medical history, upcoming appointments, messages, immunization information, allergies information, current health issues, financial and insurance information, and records access by selecting an appropriate link associated with the requested information represented by blocks 402-424, respectively. Upon the user selecting the link, at step 426 the web server 42 receives the data request, and at step 428 initiates a routine to retrieve the requested information, either from the PHR data server 12 or the shadow server 50 (or EHIS data server 14 if so configured). At step 430, the web server 42 updates the PHP web page with the new information. The web server 42 may retrieve the patient-related information from the shadow server 50 in XML format as shown in block 432. Similarly, the web server 42 may retrieve the patient-created information from the PHR data server 12 in XML format, the patient- created information including user-entered notes or messages.

The system 10 provides ability for the user to send and receive secure messages to the user's health care providers and administrators. Selecting the link 230 in FIG. 2 initiates a secure messaging routine 500 illustrated in FIG. 5. The message types include a request for medical advice; a request for prescription renewal; a request for a referral; a customer service request; a request for a prequahfied appointment and a request for an appointment, and the user selects the message type by selecting an appropriate link associated with the message type represented by blocks 502-512, respectively. Responsive to the user selecting one of the links 502-512, at step 514, the web server 42 creates a secure messaging form on the PHP web page for the selected message type. At step 516, the user enters the appropriate data and information into the message form. The user may cancel the message, step 518, and be returned to the previous PHP web page, or the user clicks send, step 522. The web server 42 forwards the information to the PHR server 12, step 524, and the PHR server 12 places the user's message in a queue for transmission to the EHIS data server 14. At step 528, the EHIS data server 14 receives the incoming message from the queue, and translates and routes the message to the appropriate destination, and at step 530, the web server 42 updates the PHP web page to reflect that the user's message has been sent.

Selecting the link associated with block 232 (FIG. 2) allows the user to add notes to the patient-created information, and selecting the link associated with the block 234 allows the user to complete forms. Selecting either link 232 or 234 initiates a process 600 illustrated in FIG. 6. Additionally, the user may add information flags to the patient-created information and/or other information contained with the PHR server 12. The information flag identifies the flagged information and may provide read only access of the information to one or more of the user's health care professionals and staff. Coupled with the information flag, the PHR server 12 is adapted to generate an alert that is communicated to the EHIS data server 14 indicating the receipt of the flag. Appropriate messaging may also be generated and communicated to the one or more of the user's health care professionals and staff. If the user has selected the link associated with block 232, the web server 42 creates an add/edit notes form and displays the form on the PHP web page. At step 604, the user enters or edits the note text in an editing window. If the user selects cancel, step 606, the notes/edits are discarded and the web server 42 returns to the previously displayed PHP web page. If the user clicks to save changes, step 610, the web server 42 forwards the edited text to the PHR data server 12, step 612, and the PHR data server 12 updates the patients notes portion of the patient-created date stored within the PHR data server 12, step 614. The user notes may be unstructured information, such as unstructured text notes, or the notes may be structured information. As an example, to input structured information the user may be presented with a form seeking particular information, such as medications they are currently taking or procedures they have had or will have. The fields within the form may be linked to other data entries in the enterprise health record system, such as reference materials for the entered medication or procedure. Moreover, the information need not be clinical in nature, as described in foregoing examples, but may be administrative in nature, such as benefits information. A similar process occurs if the user has selected the link associated with block

234. The web server 42 creates an online form, such as an insurance form or medical history form, and displays the form on the PHP web page, step 616. At step 618, the user enters information into the form in an editing window. If the user selects cancel, step 620, the information and form are discarded and the web server 42 returns to the previously displayed PHP web page, step 608. If the user clicks to save changes, step 622, the web server 42 forwards the edited form to the PHR data server 12, step 624, and the PHR data server 12 forwards the information from the edited form to the EHIS server 50, step 626, where it is processed appropriately. The web server 42 then returns the user to the previous PHP web page, step 608. By selecting the link associated with the block 236 (FIG. 2) the user may schedule a prequahfied appointment in accordance with a process 700 illustrated in FIG. 7. Upon selecting the link, the web server 42 queries the shadow server 50 for a list of available appointments for the current user, step 702. Whether prequahfied appointments are available will depend on the existence of a scheduling ticket illustrated at 704. The scheduling ticket is provided by the shadow server 50 responsive to input received from a care provider and specifies which providers are available, what procedures are required and dates and times that the appointment may be scheduled. If there are appointments available, step 706, the web server 42 updates the PHP web page with a listing of the appointments, step 708. At step 710, the user selects an appointment to schedule and, if necessary, provides additional information necessary to narrow the search for dates, times, etc. The user may also cancel the process at step 712, and web server 42 returns the user to the PHP web page. Otherwise, at step 714, the PHR data server 12 requests available appointments from a scheduling engine portion (not depicted) of the shadow server 50. If there are no appointments that meet the user specified criteria, step 716, the web server 42 updates the PHP web page, and the user is requested to enter revised information. Otherwise, at step 718 the web server 42 displays the list of available appointment times on the PHP web page. At step 720, the user selects an appointment, and the web server 42 forwards the appointment selection to PHR data server 12, which places the request in the EHIS queue 16 for processing by the EHIS data server 14. When the appointment is booked, the updated appointment information flows via the shadow server 54 from the EHIS data server 14 to the web server, which updates the PHP web page with the selected appointment summary information, step 728. The web server 42 also updates the scheduling ticket to reflect that a prequahfied appointment has been scheduled. The user may otherwise cancel the scheduled appointment at step 722 and be returned to the PHP web page.

A second appointment option is initiated by selecting the link associated with block 238 (FIG. 2), which starts a process 800 illustrated in FIG. 8. After the user selects the link 238, the web server 42 queries the shadow server 50 for a list of available providers for the user, step 802. At step 804, the web server 42 updates the PHP web page with a list of the providers. At step 806, the user selects a provider and provides additional information, such as dates and times for the appointment. The user may also cancel, step 808, and the web server 42 returns the user to the PHP web page. Otherwise, at step 810 the PHR data server 12 requests available appointments information from the scheduling engine portion of the shadow server 50. If there are no appointments within the date and time range provided by the user, step 812, the web server 42 updates the PHP web page for the user to provide additional information. Otherwise, the web server 42 updates the PHP web page with a list of the available appointments, step 814. At step 816, the user selects an appointment or cancels the process, step 818. If an appointment is requested, the web server 42 forwards the appointment information to the PHR data server 12, which places the information in the EHIS queue 16 for processing by the EHIS data server 14. When the appointment is booked, the updated appointment information flows via the shadow server 54 from the EHIS data server 14 to the web server, which updates the PHP web page with the selected appointment summary information, step 822. By the user selecting the link associated with block 240 (FIG. 2) a process 900 illustrated in FIG. 9 is started that allows the user to enroll in a class. After the user selects the link 240, the web server 42 queries the shadow server 50 for a list of available classes for the user, step 902. At step 904, the web server 42 updates the PHP web page with a list of the classes. At step 906, the user selects a class or cancels the process, step 908. If the user cancels the process, the web server 42 returns the user to the PHP web page. Otherwise, at step 910 the PHR data server 12 requests available class times from the scheduling engine portion of the shadow server 50. At step 912, the web server 42 displays the list of available class times, and at step 914 the user selects a class time or cancels. If an appointment is requested, the web server 42 forwards the appointment information to the PHR data server 12, which places the information in the EHIS queue 16 for processing by the EHIS data server 14. When the appointment is booked, the updated appointment information flows via the shadow server 54 from the EHIS data server 14 to the web server, which updates the PHP web page with the selected appointment summary information, step 920. If the process is cancelled, the web server 42 returns the user to the PHP web page.

By selecting the link associated with the block 242 (FIG. 2) the user may initiate a process 1000 illustrated in FIG. 10 for paying a bill. The process 1000 begins at step 1002 with the web server 42 making a query of the shadow server 50 for accounts for the user. The web server 42 at step 1004 updates the PHP web page with an accounts listing. The user may select an account at step 1006, or may cancel, step 1008. If the user cancels, the web server 42 returns the user to the PHP web page, step 1010. If the user does select an account, at step 1012 a routine on the PHR data server 12 requests information from an accounts receivable engine portion (not depicted) of the shadow server 50. The account is checked to determine if there is an outstanding balance, step 1014. The user may then return to the PHP web page providing the account listing. The user may elect to pay all or a portion of any balance due or may elect to pay ahead to develop an account credit toward an upcoming procedure. To permit the user to make a payment, the web server 42 displays a pay online option for the account, step 1016. The user may click the pay online option, step 1018, and the web server updates the PHP web page with an online payment form, step 1020. The user completes the online payment form, step 1022, or the user may cancel the process, step 1024 and be returned to the PHP web page. At step 1026, the web server 42 forward the information from the completed payment form to the PHR data server 12, which places the information in the EHIS queue 16 for processing by the EHIS data server 14. When the payment is processed by the EHIS data server, the information flows via the shadow server to the web server 42, which updates the PHP web page 38 with a message indicating that the payment has been submitted, step 1028.

A rules-based scheduling system according to a preferred embodiment of the invention allows a facility to control appointments scheduled through the Internet, with "scheduling tickets" that incorporate a variety of rules and triggers. These rules can be defined as many things. Some examples that may be included are:

(1) The type of patient. The system checks if the patient has any special conditions, such as being diabetic or undergoing cancer therapy, that would allow or disallow a patient to self-schedule. A clinic may not want certain patient types scheduling their own appointments because some patients need special consideration. (2) A patient's Insurance. The system checks to ensure that patients have insurance or other methods to cover their medical expenses.

(3) Referral information. The system checks to ensure that patients do not have any outstanding referrals for that type of visit so that appointments are not duplicated. (4) Previous visits of a certain type. The system checks if patients are due for or require a follow up appointment. For example, a minor operation may warrant a return visit to remove the sutures. (5) Provider preferences. The system takes into account when providers can or want to see certain types of patients. For example, if a provider does not want to schedule physicals in the morning, the system could reject any ticket submission from patients to have physicals scheduled in the morning for this particular provider. (6) Patient preferences. The system takes into account when patients want to be seen by their providers.

(7) Past patient history. The system checks if factors exist that may change whether or not a patient can self-schedule. For instance, a system could deny a patient the right to self-schedule because he has a history of more than 20% no-shows or cancellations.

(8) Copay requirements. The system checks if a copay by the patient is required for the appointment. Accordingly, the system requires that a patient must pay the copay when he or she schedules the appointment.

These rules could further be set up as a layered hierarchy. They could be specified at various levels which include, but are not limited to:

(1) System level or facility level. This is the least specific level. The settings at this level pertain to an entire healthcare facility.

(2) Department level. This level is more specific than the system level. The settings at this level pertain to all providers who work in a specific department of a facility.

(3) Provider level. This level is very specific. The settings at this level pertain to only a specific provider.

(4) Rule level. The specificity of this level could vary, depending on how a facility has set up the system. For example, one facility could set up the rules level settings as overriding settings at the provider level, while another facility could set up settings at the provider level as overriding the settings at the rules level. The settings at this level pertain to only a specific rule.

Rules set at more specific levels could override rules set at less-specific levels. For example, if an entire clinic's system is configured to allow diabetic patients to self-schedule using pre-authorized scheduling tickets, but a diabetic patient attempts to use a scheduling ticket to schedule an appointment in a department that does not allow diabetic patients to self-schedule, the patient would not be able to self-schedule in that department because the department level is more specific than the system level, so it takes precedence. However, diabetic patients in departments that allow diabetic patients to use self-scheduling or in departments with no specific rules for diabetic patients could still schedule an appointment with a ticket.

Different rules could also be set up to override other rules. For example, provider preference rules could be set up to override patient preference rules when a patient is using a scheduling ticket to make an appointment. Also, the past patient history rules could be defined to override all other rules, because if a patient abuses self-scheduling, a facility would most likely not want that patient to be scheduling appointments, regardless of what the other rules dictate. Furthermore, these rules can be dynamic in their ability to change over time.

For example, the system could revoke a patient's ability to self-schedule if the patient abuses the system. Therefore, if a patient self-scheduled three appointments and did not show up for them, the system could automatically change the patient's status from "able to self schedule" to "unable to self schedule." While the invention is further described in terms of several preferred embodiments, it will be appreciated that the invention is not limited in scope to the embodiments herein described. Many modifications, alterations and additions may be made without departing from the fair scope of the invention.

Referring to FIG. 11 of the drawings, a flow chart representation is shown of the path that the system would take when a patient attempted to schedule an appointment directly from the system. Through the system, a patient with access to self-scheduling can, either with a pre-authorized scheduling ticket or through a user initiated scheduling process, request an appointment with his or her clinic or provider. The self schedule request would then have to pass a series of checks, or rules, before it could be fulfilled. First, the system would run 1104 a rules check to see 1106 if the patient is authorized to self-schedule appointments. If the patient has the appropriate authorization, the system would then check 1110 to see if a pre-authorized scheduling ticket existed for the patient. If one existed, the system would offer 1114 the patient time slots that met the ticket requirements. If there were no pre-authorized tickets for the patient, he or she would enter an appointment search criteria manually 1112. Then the system would verify that the patient was allowed to see the search results, whether the search results were obtained using the pre-authorized ticket or using search criteria initiated by the patient. The patient would then select 1 118 an appointment to schedule. The system would perform 1120 one last check to make sure the patient was allowed to schedule the appointment and that the appointment was still available, and then the appointment would be made 1124. If the specific appointment that the patient was trying to book was unavailable, the patient would be prompted 1112 to enter scheduling information manually, and the process would start over.

Again, if the scheduling ticket or the responses from the user initiated scheduling process pass all of the appropriate security checks, the system then can present the patient with a list of solutions that match his or her request. After the patient selects an appointment 1118, the system can perform 1120 a final check to ensure that the patient is authorized to use the ticket to schedule the appointment and that the time slot is still available. If the request passes this security check, then the system can notify 1124 the patient that he or she has successfully scheduled the appointment with his or her clinic or provider. If for any reason, a patient is not allowed to self-schedule, the system could be configured 1108 to immediately give the patient the option to request an appointment, as opposed to actually scheduling one with a scheduling ticket.

As explained above, a patient can self-schedule an appointment with his or her clinic or provider using either a pre-authorized scheduling ticket 11 14 or through a user initiated scheduling process 1112. As shown in Figure 12, a pre-authorized scheduling ticket is an electronic ticket that is given to the patient via their electronic health record managed by their physician. This record is stored on a computer server and is referenced by the Internet based scheduling system to limit the patient's ability to schedule appointments to what is described 1204 by the ticket. An electronic database of scheduling tickets (also referred to as access tickets) would be created. Attributes 1204 of records in this database would include the healthcare provider who authorized the ticket, the services the ticket entitles the patient to schedule (e.g. one follow up visit within the next two months), and the patient identifier for the patient the ticket is for. The ticket also has an attribute that describes its current status (unused, appointment made, appointment completed).

These pre-authorized scheduling tickets would be automatically created during the physician's documentation of a clinical encounter with the patient. Typically a doctor will document when a patient should return, in follow up of a problem (e.g. to check on how well a medication is working to control the patient's blood pressure) or for a follow up procedure (e.g. suture removal). When initially created, the ticket's status is set to "unused."

Referring again to FIG. 12, the flowchart illustrates the process by which a user logged in to his Patient Health Portal (PHP) Web Page can schedule an appointment that has been pre-qualified. When the user clicks the Schedule Appointment option, the Web Server queries 1202 the Scheduling Server to see if there are any pre-qualified appointments available for the current user. If there are, the Web Server updates 1208 the PHP Web Page with the available appointment information. The user can then select 1210 an appointment to schedule, and indicates date, time, and locations (selections may be limited by information in the Scheduling Ticket database). The Web Server then obtains 1214 appointment times available within the selected range and displays 1218 them, whereupon the user can either select a time, change the search, or cancel. When a user completes the appointment scheduling process, the Web Server notifies 1224 the Scheduling Ticket database that the appointment has been scheduled and the ticket for the current user is updated 1226 accordingly. The Scheduling Ticket database will then track whether the appointment has been cancelled or completed, and will update the corresponding pre-qualified appointment record accordingly. As previously mentioned, in addition to direct provider created tickets, patients may schedule an appointment through a user initiated scheduling process 1112. An example of when this may be utilized is when a provider places a patient on a disease management protocol. These protocols might call for a patient to be seen with a certain frequency for specified types of visits. These protocols would automatically grant authority for the patients that conform to the limitations of the protocols. This process could be used independently or in combination with other insurance information available for the patient and represents the limitations that would be imposed on a patient self-scheduling through the web.

To provide additional control for healthcare providers, the system may be designed to apply a more restricted set of rules to patients scheduling appointments through the user initiated scheduling process. For example, a healthcare provider may reserve only a few time slots per week for patients to schedule appointments through this process. They may additionally limit those appointments to very short durations for limited purposes, such as consultations or the administration of simple tests. Another example is that the system could restrict a patient from selecting a provider or a department. Instead, the system would pick an appropriate provider or department from a pre-determined list that is driven by the patient as a parameter. The patient would be provided access to a self scheduling application (e.g. a web site or a computer application for personal use, possibly running on a home computer, personal digital assistant (PDA) or cellular telephone) which would allow them to schedule the appointment.

This self-scheduling computer application would identify and authenticate the patient and read the database of electronic tickets to determine what self-scheduling limits exist for the patient. The self-scheduling application then allows the patient to select appointments that are within the limitation of the ticket.

Once an appointment is made, it is associated with the ticket. The ticket is then marked as "appointment made." When the appointment is kept, the ticket is marked as "appointment completed" and then subsequently destroyed or retained for historical analysis. If the patient or provider cancels the appointment, the ticket's status would revert to the "unused status."

The integration of the self-scheduling component into an overall healthcare management system is shown in Figure 13. A completely integrated system provides patients with secure, real-time access to their Personal Health Record and an

Enterprise Health Information System (PHR and EHIS, respectively). Access may be provided by way of the Internet 316 and via a Personal Health Portal (PHP) web page 1318. From the secure PHP web page 1318, patients can view information created and maintained by their health care providers and their affiliated staff. The patients can also request services and information from their health care providers and affiliated staff, directly access EHIS-related services, such as scheduling an appointment, paying a bill, enrolling in a class, completing insurance and other forms, and viewing information and Internet services that are relevant to their particular health status. In a preferred embodiment of the invention a patient health record data server

1302, including a machine readable media having a data structure containing patient- created data, is coupled by an electronic network with a patient interface. The electronic network may be the Internet 1316 and the patient interface may be a suitable Internet access device including a browser for supporting a personalized web page 1318. A secure interface securely couples, in real-time, the patient health record server 1302 to an enterprise health record system 1304 for providing access by the patient to patient-related data retained within the enterprise health record system 1304. Thus, the patient, via the patient interface, may access the patient health record server 1302 for manipulating the patient-created data and for accessing the patient- related data from the enterprise health record system 1304.

Referring again to Figure 13 of the drawings, the system includes a Patient Health Record (PHR) data server 1302, an EHIS data server 1306, and a self- scheduling server 1308. The PHR data server 1302 may be any suitable platform including processing, memory and data storage capability to perform the functions herein described. The PHR data server 1302 stores data entered by the patient within a data structure configured within the storage portion of the PHR data server 1302. A secure interface or EHIS queue securely couples the PHR server 1302 and the EHIS data server 1306 for communication of data and information from the PHR data server 1302 to the EHIS data server 1306. The EHIS queue provides a real-time secure communication link for information moving from the PHR data server 1302 to the EHIS data server 1306. This queue is used to transfer information for secure messaging and self-service options. In response to information received from the PHP web page 318, the PHR data server 1302 forwards information to the EHIS queue. Information in the EHIS queue is then processed appropriately by the EHIS data server 1306.

While the specific configuration of the EHIS data server 1306 is not particular to the structure and function of the present invention, preferably, the EHIS data server 1306 is a single data repository structured to support both the separation and the sharing of data. As such, the EHIS data server 1306 may receive information from existing outpatient and inpatient data management systems via interfaces or from various integrated applications. The EHIS data server 1306 may be configured to organize information into a consistent whole to provide a longitudinal patient record. For example, the EHIS data server 1306 may be linked to manage all aspects of a patient's hospital health status and care and to support effective management of patient lists, results inquiry management, complete clinical documentation, physician order entry with decision support, nursing workflow and documentation, and discharge planning.

The EHIS data server 1306 may further be configured to support the inclusion of problem lists, order communications, results reporting, pharmacy management, quick documentation, clinical messaging and communication. Additionally, the EHIS data server 1306 may be configured to manage referral information, up-to-date progress notes, lab results, discharge instructions, portions of a patient's record, and emergency summary cards. A suitable data management product that may be adapted as the EHIS data server 1306 is the Epicenter® Enterprise Data Repository and related suite of products available from Epic Systems Corporation of Madison, Wisconsin.

The specific configuration of the scheduling server 308 is also not particular to the structure and function of the present invention. However, the scheduling server may be any suitable platform that includes a processor, memory and data storage capability to perform the functions herein described. These functions may alternatively be performed by the EHIS server 1306. Thus, the scheduling server 1308 may be a separate component from the EHIS server 1306, or it may be one in the same.

An electronic network couples the PHR data server 1302, the EHIS server 1306, and the scheduling server 1308 to a patient interface. While Figure 13 depicts the scheduling server 1308 as a separate component, as mentioned above, an alternative embodiment may include the scheduling server as part of the EHIS server 1306, as represented by the phantom line 1304 in Figure 13. The electronic network may include the Internet 1316 or another suitable data network. The system servers are electronically linked to the Internet by a web server 1312 in a highly secure dual firewall configuration. In this arrangement, a primary fire wall 1314 protects the web server 1312 and a secondary fire wall 1310 protects the PHR data server 1302, EHIS server 1306, and scheduling server 1308. Additionally, the PHR data server 1302, EHIS server 1306, and scheduling server 1308 are also electrically interconnected.

Patients access the system by logging into the web server 1312 via the patient interface. The patient interface is preferably configured as a web page displayed within a web browser running on a suitable platform, and is further preferably configured as a personalized Personal Health Portal (PHP) web page 1318 providing the patient with patient-specific information and links to the features and services offered by the invention. The web server 1312 may be any suitable web server platform containing routines for displaying the PHP web page 1318 and for managing online communication between a user logged in via an associated PHP web page 1318, the PHR data server 1302, and the EHIS data server 1306. Rules-based scheduling tickets solve the many problems that the healthcare industry has encountered. First, the scheduling ticket could be sent to the facility via a secure web-access application ensuring that the request will remain confidential. Furthermore, the self-scheduling functionality is equipped with a dynamic feedback system, which prevents patients from abusing their self-scheduling capabilities. For instance, if a patient schedules multiple appointments and does not show up for the appointments, the patient could be banned from scheduling any more appointments over the Internet. Finally, because of the hierarchical rules that a facility could enact, the facilities, departments, and providers are able to determine which patients can use scheduling tickets and which time slots they can schedule in at different levels, so that they do not lose control of their daily schedules.

The invention has been described in terms of several preferred embodiments, including a number of features and functions. Not all features and functions are required for every embodiment of the invention, and in this manner the invention provides a flexible system by which a user may access patient records, send and receive messages, retrieve information, schedule appointments, renew prescriptions, pay bills and the like. The features discussed herein are intended to be illustrative of those features that may be implemented; however, such features should not be considered exhaustive of all possible features that may be implemented in a system configured in accordance with the preferred embodiments of the invention.

Claims

CLAIMSWe claim:

1. A system for providing a patient with access to a patient health record for that patient, the system comprising: a patient health record server including a machine readable media having a data structure, the data structure containing patient-created data; a communication network coupling the patient health record server with a patient interface, the patient interface providing the patient with access to the patient health record server via the communication network; a secure interface adapted to securely couple in real-time the patient health record server to an enterprise health record system for providing access by the patient health record server to patient-related data for the patient retained within the enterprise health record system; wherein, via the patient interface, the patient may access the patient health record server for manipulating the patient-created data and for accessing the patient- related data from the enterprise health record system.

2. The system of claim 1, wherein the communication network comprises the Internet and wherein the patient interface comprises a web browser.

3. The system of claim 2, wherein the patient interface further comprises a personalized patient home page.

4. The system of claim 1, wherein the secure interface is adapted for securely exchanging messages between the patient and the enterprise health record system.

5. The system of claim 4, wherein the messages comprise messages of the type comprising: a request for medical advice; a request for prescription renewal; a request for a referral; a customer service request; a request for a pre-qualified appointment and a request for an appointment.

6. The system of claim 1, further comprising a shadow server coupled to the enterprise health record system, the shadow server including a machine readable media and wherein a copy of the patient-related data is retained on the shadow server, and wherein the communication network securely couples the patient interface to the shadow server for permitting viewing of the patient-related data by the patient.

7. The system of claim 1, wherein the communication network comprises a security server, the security server being adapted to prohibit copying of the patient- created data or the patient related data from the respective patient health record server and the enterprise health record system.

8. The system of claim 1, wherein the communication network comprises a security server, the security server being adapted to prohibit unauthorized access to the patient-created data and the patient-related data via the communication network.

9. The system of claim 1, adapted to receive a scheduling ticket from the enterprise health record system and the communicate the scheduling ticket to the patient, the scheduling ticket enabling the patient to schedule an appointment with a health care provider in accordance an authorization provided by the scheduling ticket.

10. The system of claim 1, the patient health record server coupled to a source of information, the patient health record server including a relevancy engine for selecting patient-specific health-related information and for displaying that information to the patient via the patient interface.

11. The system of claim 1 , the patient health record server adapted to receive payment information from the patient via the patient interface and to communicate the payment information to the enterprise health record system.

12. The system of claim 1, wherein the secure interface is configured to provide view only access to the patient-related information.

13. The system of claim 1, wherein the patient-related information comprises one of the group of patient-related information types comprising: a medication list, a lab result, recent visit information, appointment information, immunization information, allergy information, a problem list, insurance information, account information, referrals information, administrative information, staff information, financial information, insurance information and messages.

14. The system of claim 1, wherein the patient health record server is adapted to receive messages from the patient via the patient interface and to forward the messages to the enterprise health record system.

15. The system of claim 14, wherein the messages comprises one of the group of message types comprising: an appointment request, a medical advice request, a medication renewal request, a customer service message and an address change.

16. The system of claim 14, wherein the patient health record server is adapted to receive a self-service access authorization for a patient from the enterprise health record system and to forward the self-service access authorization to the patient via the patient interface.

17. The system of claim 16, wherein the self-service access authorization comprises one of the group of self-service access authorization types comprising: an option to schedule an appointment, an option to enroll in a health education class and an option to make credit card payments.

18. The system of claim 1 , wherein the patient-created data comprises one of unstructured information and structured information.

19. The system of claim 1, wherein the patient-created data comprises one of the group of data entry types comprising: a medication list, a health reminder list, a medical history summary, an immunizations list, an allergies list and a current health issues list.

20. The system of claim 1 , wherein the patient-created data comprises one of clinical information and administrative information.

21. The system of claim 1 , wherein the patient health record server is adapted to receive an information flag from the patient via the patient interface and to associate the information flag with one of the patient-created information and the patient- related information.

22. The system of claim 21 , wherein the patient health record server is further adapted to send an alert to the enterprise health record system upon receipt of an information flag.

23. A method of linking patients with a patient health record for that patient, the method comprising the steps of: within a patient health record server, providing a data structure containing patient-created data; coupling the patient health record server with a patient interface, the patient interface providing the patient with access to the patient health record server via the communication network; and securely coupling in real-time the patient health record server to an enterprise health record system for providing access by the patient health record server to patient-related data for the patient retained within the enterprise health record system.

24. The method of claim 23, wherein the communication network comprises the Internet and wherein the patient interface comprises a web browser.

25. The method of claim 24, wherein the patient interface further comprises a personalized patient home page.

26. The method of claim 23, further comprising the step of securely exchanging messages between the patient and the enterprise health record system.

27. The method of claim 26, wherein the messages comprise messages of the type comprising: a request for medical advice; a request for prescription renewal; a request for a referral; a customer service request; a request for a pre-qualified appointment and a request for an appointment.

28. The method of claim 23, further comprising the step of providing a shadow server coupled to the enterprise health record system and copying the patient-related data to the shadow server.

29. The method of claim 23, further comprising the step of prohibiting the copying of the patient-created data or the patient related data from the respective patient health record server and the enterprise health record system.

30. The method of claim 23, further comprising the step of prohibiting unauthorized access to the patient-created data and the patient-related data via the communication network.

31. The method of claim 23, further comprising the steps of receiving a scheduling ticket from the enterprise health record system and communicating the scheduling ticket to the patient, wherein the scheduling ticket enables the patient, to schedule an appointment with a health care provider in accordance an authorization provided by the scheduling ticket.

32. The method of claim 23, further comprising the steps of providing patient- specific information to the patient via the patient interface.

33. The method of claim 23, further comprising the steps of receiving payment information from the patient via the patient interface and communicating the payment information to the enterprise health record system.

34. The method of claim 23, further comprising the steps of limiting information access to view only access of the patient-related information.

35. The method of claim 23, wherein the patient-related information comprises one of the group of patient-related information types comprising: a medication list, a lab result, recent visit information, appointment information, immunization information, allergy information, a problem list, insurance information, account information, referrals information, administrative information, staff information, financial information, insurance information, and messages.

36. The method of claim 23, further comprising the steps of receiving messages from the patient via the patient interface and forwarding the messages to the enterprise health record system.

37. The method of claim 36, wherein the messages comprises one of the group of message types comprising: an appointment request, a medical advice request, a medication renewal request, a customer service message and an address change.

38. The method of claim 23 further comprising the steps of receiving a self- service access authorization for a patient from the enterprise health record system.

39. The method of claim 38, wherein the self-service access authorization comprises one of the group of service request types comprising: an option to schedule an appointment, an option to enroll in a health education class and an option to make credit card payments.

40. The method of claim 23, further comprising the steps of receiving patient- created data and linking the patient-created data to a corresponding data entry in the enterprise health record system.

41. The method of claim 40, wherein the corresponding data entry comprises one of the group of data entry types comprising: a medication list, a health reminder, a medical history summary, an immunizations list, an allergies list and a current health issues list.

42. The method of claim 23, further comprising the step of building a patient health record from the patient created data.

43. The method of claim 23, further comprising the steps of receiving an information flag from the patient via the patient interface and associating the information flag with one of the patient-created information and the patient-related information.

44. The method of claim 43, further comprising the step of sending an alert to the enterprise health record system upon receipt of an information flag.

45. A method of self-scheduling appointments between service recipients and service providers via an electronic network, the method comprising the steps of: receiving via the electronic network an appointment scheduling request from a service recipient; determining an authorization of the service recipient to submit the appointment scheduling request; identifying a pre-authorized scheduling ticket for the service recipient, the pre- authorized scheduling ticket including appointment scheduling information; providing to the service recipient an appointment proposal in accordance with the appointment scheduling information; and applying a set of rules to the appointment request to determine if the requested appointment is allowed.

46. The method of claim 45, wherein the set of rules comprises a rule selected from the group of rules including: type of patient, patient insurance, referral, provider preference, past patient history and copay requirements.

47. The method of claim 45, wherein the set of rules comprises a hierarchy of rules.

48. The method of claim 47, wherein the hierarchy comprises a hierarchy selected from the group of hierarchical levels including: system or facility, department, provider and rule.

49. The method of claim 45, wherein the set of rules is predetermined.

50. The method of claim 45, wherein a rule of the set of rules is dynamic.

51. The method of claim 45, wherein the step of determining an authorization of the service recipient includes authorizing a user initiated scheduling process when a scheduling ticket is not located.

52. The method of claim 51 , further comprising the step of applying a more restricted set of rules when an appointment is scheduled through the user initiated scheduling process.

53. The method of claim 45, further comprising the step of verifying the pre- authorization scheduling ticket.

54. The method of claim 53, wherein the step of verifying the pre-authorization scheduling ticket comprises checking at least one of the group of checks including: availability of self-scheduling for the service recipient, validity of the pre-authorized scheduling ticket, and availability of requested appointment slots.

55. The method of claim 45, wherein the step of identifying a pre-authorized scheduling ticket for the service recipient comprises receiving the appointment scheduling information from the service provider.

56. A system to allow self-scheduling of appointments via an electronic network, the electronic network configured to permit secure access thereto by a service recipient, the system comprising: a self-scheduling server coupled to the electronic network for secure communications therewith, the self-scheduling server adapted to receive appointment scheduling requests from the service recipient securely via the electronic network; a self-scheduling server including a processor, the processor being coupled to a rule base, to a scheduling database, and to receive the appointment scheduling request; and wherein the processor is operable upon the appointment scheduling requests to authorize the appointment scheduling request, to send appointment schedule information to the scheduling database for inclusion therein and to send an appointment acknowledgment to the service recipient securely via the electronic network.

57. The system of claim 56, wherein the scheduling database includes pre- authorization scheduling information associated with the service recipient.

58. The system of claim 57, wherein the pre-authorization scheduling information comprises a pre-authorized scheduling ticket.

59. The system of claim 58, wherein the pre-authorization scheduling ticket is automatically generated within the scheduling database.

60. The system of claim 56, wherein the scheduling database includes information associated with the service recipient is manually entered through a user initiated scheduling process.

61. The system of claim 56, wherein the system is part of an enterprise healthcare information management system.

62. The system of claim 56, wherein the rule base contains a set of rules.

63. The system of claim 62, wherein the set of rules comprises the group of rules including: type of patient, patient insurance, referral, provider preference, past patient history and copay requirements.

64. The system of claim 62, wherein the set of rules comprises a hierarchy ofrules.

65. The system of claim 64, wherein the hierarchy ofrules comprises the group of hierarchical levels including: system or facility, department, provider and rule.

66. The system of claim 56, wherein the set ofrules is predetermined.

67. The system of claim 56, wherein a rule of the set ofrules is dynamic.