Medical information system having interactive messaging interface (24-Apr-2007)

CONTINUATION APPLICATION INFORMATION

This application is a continuation of U.S. application Ser. No. 08/906,726, filed Aug. 5, 1997, entitled A MEDICAL INFORMATION SYSTEM INCLUDING A MEDICAL INFORMATION SERVER HAVING AN INTERACTIVE VOICE RESPONSE INTERFACE, which subsequently issued as U.S. Pat. No. 6,192,112 on Feb. 20, 2001 and which itself was a continuation-in-part of U.S. application Ser. No. 08/581,749 filed Dec. 29, 1995 that subsequently issued as U.S. Pat. No. 5,926,526 on Jul. 20, 1999 with the title METHOD AND APPARATUS FOR AUTOMATED PATIENT INFORMATION RETRIEVAL. The disclosures of said cross-referenced applications are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to providing medical information such as laboratory test results to patients.

DESCRIPTION OF RELATED ART

Medical providers and testing facilities are typically deluged with demands on their time and have limited support for delivery and tracking of test results. Primary care and other medical providers often order various tests during their office evaluation of patients. The tests may range from a pregnancy test with a single yes-no type answer that will be reported the next day to batteries of tests with more than fifty result values that may come back at different times over several weeks. The task of reporting these results to patients can be horrendously complex and consuming, but, at the same time, errors or lapses in reporting can be life threatening. The task is often accomplished with great effort and not uncommonly with less than ideal perfection or completeness.

U.S. patent application entitled, “Method and Apparatus for Automated Patient Information Retrieval,” Seymour A. Rapaport, M.D., Jeffrey A. Rapaport et al., filed Dec. 29, 1995 referenced above and incorporated by reference, describes an approach for patient information retrieval that significantly eases this work and can allow essentially complete reporting of test results to the patients in a professional practice. The approach described there increases the medical provider's efficiency and effectiveness in accomplishing the test result reporting task many fold. However, despite the fact that the provider's medical practice and patient care is significantly improved in that it is possible for essentially all tests to be reported, the provider must accomplish some added tasks, and therefore there are some added demands on the provider's time.

SUMMARY

The present disclosure of invention provides methods and/or systems that may streamline the provider's tasks so that the provider is involved time-wise only to the extent that he or she wants to and has to be. This results in essentially complete reporting of patient tests and other appropriate patient messages in the medical practice with little added efforts on the providers' part and improved patient care and safeguards to patients' health.

There are several additions and innovations that enable these goals: The system improves the use of standard patient messages and allows for extensive uploading of results of tests by testing facilities directly into the account owner's patient message database for access by the account owner's patients. This significantly eases the burden of test reporting for the provider, but comes with the cost of making the provider less aware than is desirable to certain test results—e.g., critical results, results that the provider is especially interested in knowing, results that the testing facility feels need direct provider attention, and time-sensitive results. To prevent such occurrences, the system has several types of alerts for the providers and upload-sources (testing facilities).

Upload-sources may upload specific results into an upload-source note field that is in the mailbox for account owners to review. The content in this field is available only to medical personnel and not the patient.

A finder function and patient identifier feature enables the account owner to quickly locate the proper mailbox for a patient on the system for placing a patient message when the test results return.

The system may be configured to include a database with patient record data that automatically uploads much of the information needed for the mailbox on the system when needed; text-to-speech software allows this information to be converted to speech which may be played over a telephone line by a interactive voice response system.

A plurality of reports is composed by the system to aid account owners and upload-sources. These reports automatically record the functioning of the system including account owner placement and retrieval of messages and alerts, patient message retrieval, and a summary of message content.

An array of parameters allows for significant customization of a particular system at the account level, mailbox pool level, and system level. This customization allows features of the system to be available as desired thereby offering a highly customized solution to the many different needs of a variety of users of the system.

The system shares information resources through a variety of interfaces and also supports a public application programming interface (API), which allows access to third party software and solutions.

The system may be configured to serve several members of the same provider group with the same access means, e.g. telephone number, with the inclusion of a mailbox number that is linked to an account.

According to one aspect of the present disclosure, a system for providing medical information to a patient is provided. The system comprises a medical information software engine. A memory location having a voice mailbox is coupled to the engine. The voice mailbox is accessible by the patient, the upload-source, such as a laboratory test facility, and the account owner, such as a medical provider. The voice mailbox includes a first segment for storing a patient message for the patient, a second segment for account owner information supplied by the account owner, and a third segment for storing upload-source information, such as test results. The upload-source is coupled to the medical information software engine and may provide the test results. An interactive voice response system interface is coupled to the medical information engine and the voice mailbox. The interface provides the account owner information in the second segment responsive to an account owner input.

Upload-Source Uploading Patient Messages and Patient Retrieval Alerts into Mailboxes that Have Associated Account Owner Chart Notes

According to an aspect of the present invention, a set of pre-recorded patient messages are stored in the appropriate patient mailboxes in response to account owner input or input from an expert system where the expert system responds to test result data at the upload-source. The expert system rule-base is in agreement with the standards and practices of the upload-source and account owners involved.

According to an aspect of the present invention, messages may include textual data which is translated into speech data using text-to-speech software and stored in a patient voice mailbox.

According to an aspect of the present disclosure, both the account owner and the uploading source may be notified by a patient-retrieval alert if a patient does not access the voice mailbox within specified time period.

According to another aspect of the present disclosure, when data is uploaded into a mailbox, the upload-source may assign responsibility of the mailbox to a particular account owner. The account owner would have the mailbox assigned to his or her account database, and have corresponding information sent to the account owner regarding the patient message and mailbox. The information may include alert information.

According to an aspect of the present disclosure, a patient voice mailbox may have a segment for storing an upload-source note wherein the upload-source may upload specific test results or messages into the upload-source note that the account owner can access but not the patient.

According to an aspect of the present disclosure, the system alerts a particular account owner when an upload-source note is uploaded into an assigned patient voice mailbox but a patient message is not stored in the assigned patient voice mailbox.

According to an aspect of the present disclosure, the upload-source may overwrite data in a mailbox if the patient voice mailbox data has not been accessed by patient or altered by an account owner. If the account owner has accessed the mailbox, and the upload-source alters data in the voice mailbox, the account owner is notified by an upload-source-change alert

According to an aspect of the present disclosure, patients cannot receive certain pre-recorded patient messages without prior review and/or approval by the account owner.

Configurations with PD Access and Configurations Without PD Access

According to an aspect of the present disclosure, each account may have an associated patient database (PD) containing records with fields having: 1) a unique patient identification code, 2) other identifying data, 3) contact data, 4) and other information regarding the patients in the practice of the account owner.

According to an aspect of the present disclosure, when an account is configured to have access to a patient database, appropriate data from fields in this database can be entered into a particular mailbox using a patient finder code (“PFC”) to locate the proper patient identification code (“PIC”). In this configuration the account owner's chart notes are associated with the PIC.

According to an aspect of the present disclosure, the upload-source can assign a mailbox to the account owner's account.

According to an aspect of the present disclosure, all chart notes for a specific patient in a PD provided by the accessing account owner will first be presented in order of date of formation and then chart notes placed by other account owners for this PIC will be presented in order of date of formation. In another aspect, the chart notes provided by other account owners are preceded by the system playing the name of the account owner who provided the chart note.

According to an aspect of the present disclosure, a patient database may contain other fields pertinent to the patient's health such as drug allergies and current medications or have means of accessing such data on an electronically stored patient record elsewhere.

According to an aspect of the present disclosure, for an account with access to a patient database there is available an alert, called the test-number alert, which indicates the number of tests remaining to be retrieved by a patient. The alert is activated according to the following: The account owner enters into the system the number of mailboxes that will be used to report results to the patient over a specified time period subsequent to the office visit wherein the tests were ordered. This number is decremented whenever the patient retrieves a patient message stored in a mailbox within this set time period. If all patient messages in mailboxes that are to inform the patient of results have not been retrieved, the patient is informed of this prior to the end of the patient's access to the system. According to another aspect of the disclosure, if there are remaining unfilled or unretrieved patient messages after the account owner pre-set time, the account owner may be so informed by this alert if it is activated. If by the deadline set for this alert, the patient has additional tests ordered to be reported on the system, the account owner is prompted to reset the test number alert information.

Alerts

According to an aspect of the present invention, for an account with patient database (PD) access, the account owner can assign a completion notification request (CNR) to a mailbox corresponding to a PIC. A completion notification request (CNR) utilizes a series of numeric digits which is communicated to the upload-source and associated with the chart note stored when the test is ordered. The upload-source accordingly can associate the upload message with the CNR string and alert the account owner that a patient message or upload-source note has been uploaded into the patient mailbox. The CNR string has an associated account owner input of a deadline whereby an alert to the account owner is activated by the system (compliance alert) if a patient message or upload-source note is not uploaded by the upload-source within this deadline.

According to an aspect of the present disclosure, for an account without PD access, when the account owner stores a chart note at the time of test ordering, he or she may set a deadline for the system to notify him or her if there is no upload-source note or patient message uploaded to that mailbox within an account owner specified deadline. This alert is referred to as a compliance alert.

According to an aspect of the present disclosure, for an account without PD access, when storing a chart note, the account owner may cause the system to notify him or her when an upload-source note or patient message is uploaded to that mailbox within an account owner specified deadline. This alert is referred to as a completion alert.

According to an aspect of the present disclosure, the upload-source when uploading data into a mailbox can activate an alert for notifying the account owner that an upload-source note or patient message in a particular mailbox has been uploaded. In another aspect of the present invention, the particular upload-source name is communicated to the account owner during playing of alert information. This alert is referred to as an upload alert.

According to another aspect of the present disclosure, the upload-source can set a deadline by which the account owner must access the upload-source note or patient message in a particular mailbox which the upload-source has uploaded or the upload-source is automatically notified of the lack of access by the account owner. This alert is referred to as a timed-upload alert.

According to an another aspect of the present disclosure, whenever an upload-source sets an upload alert in a mailbox, the corresponding mailbox will have an owner alert activated at the time of upload.

According to still another aspect of the present disclosure, if the notification deadline in the aforementioned timed-upload alert is less than a parameter value, the upload-source is periodically notified of the status of the access of the mailbox by the account owner and the system can initiate means to contact the account owner or a designated alternate regarding the alert by pager or other means. This alert is referred to as a panic alert.

According to an aspect of the present disclosure, the upload-source is notified by, for example, fax to inform the upload-source of the retrieval or non-retrieval of an upload alert or panic alert.

According to an aspect of the present disclosure, the account owner is prompted by the system to record an alert note number when the account owner sets an alert for the patient. The alert note includes patient contact information, e.g. the patient's phone. The alert note is only available to the account owner when an alert is activated. In an embodiment, the upload-source may set the alert note information when uploading information.

According to an aspect of the present disclosure, when the patient retrieves a patient message with a patient-retrieval alert associated with the patient message, the patient-retrieval alert is automatically removed from the corresponding account's alerted mailbox list.

According to an aspect of the present disclosure, a mailbox can not be removed or deleted from the system if a panic alert has been activated for the mailbox and the account owner has not addressed the panic alert.

According to an aspect of the present disclosure, the deadline until a patient-retrieval alert is activated can be set individually for each patient message by the account owner or upload-source at the time of patient message placement.

According to an aspect of the present disclosure, the various types of alerts on the system are presented to the account owner in a pre-designated order, sorted by alert type.

According to another aspect of the present disclosure, the alerts of a particular type can be further ordered to be presented to the account owner in order of the date of their creation.

According to an aspect of the present disclosure, the system has a built in default capability of assigning an alert precedence if a mailbox has more than one alert.

In an embodiment if a mailbox has more than one alert flag set, then the alert information for the mailbox is presented to the account owner as if the mailbox only had the highest precedence alert. For example, if a mailbox has both a panic alert flag set and a patient-retrieval alert flag set, the mailbox is presented to the account owner as if the mailbox only had a panic alert flag set; or, for example, if a mailbox had both patient-retrieval alert flag set and upload-source-change alert flag set, the alert information is presented as if the mailbox only had an upload-source-change alert flag set.

In an embodiment if a mailbox has more than one alert, the contents of the mailbox are presented to the account owner only once during the account owner's accessing of his or her alerts.

Prevention of Conflicting Demands and Results on System

According to an aspect of the present disclosure, a mailbox may only be accessed by one user at a time.

According to an aspect of the present disclosure, after a patient retrieves a patient message from a particular mailbox, neither the account owner or the upload-source can edit any field in that mailbox.

According to an aspect of the present disclosure, mailboxes in a particular mailbox pool are either in a protected range or not in a protected range. If a particular mailbox is in the protected range then when mailbox information is uploaded and/or changed by uploading file information, the upload file information for that mailbox must contain the appropriate mailbox security code.

In an embodiment, for an account with PD access, the mailbox security code can be a patient security code or other type of patient security code for a particular patient in a PD.

Reporting Functions

According to an aspect of the present disclosure, the system maintains a count of entries in the expired-timed-upload alerts collection: When this count reaches a parameter value or when the number of days since the last such report was sent to the upload facility is above a parameter value, the system sends the upload facility an expired-timed-upload alert report. The expired-timed-upload alert report indicates, but is not limited to, the deadline set for alerting the account owner of the uploaded information and the time of account owner access of such information.

According to an aspect of the present disclosure, the system compiles and sends a report to the upload-source that lists the results of the system's processing of the last upload file received by the system from this source. This report is compiled and sent once the uploaded file is processed. This report lists those mailboxes that failed to upload information and an error code that indicates the reason for the failure. The report for an account with PD access includes the mailbox number assigned by the system to each uploaded result and/or patient message; this mailbox number may be used by the upload-source to subsequently edit the mailbox. The report may also include for each mailbox a patient name, a PIC, pre-recorded patient message code, upload-source note or upload-source code, a name of account owner for the mailbox, and date and time of upload.

In an embodiment, for accounts without PD access, a mailbox number is reported in place of the PIC.

According to an aspect of the present disclosure, patient message titles may summarize pre-recorded patient messages and be presented to account owners when appropriate to inform them of mailbox contents more rapidly. According to another aspect of the present disclosure, the account owner may use standard patient message codes or text to summarize the content of custom recorded patient messages so that these codes and what they represent may appear on reports generated by the system. These codes and messages may be appended.

According to an aspect of the present disclosure, the account owner when accessing alerts can place information regarding his or her disposition of each alert and associated information in a file for subsequent transcription to the patient's records. The account owner may store in an electronic medical record associated with the patient the actions taken secondary to and results of his or her accessing an alert for that patient.

Patient Identifier Functionality

According to one aspect of the present disclosure the system uses a finder function and a patient identifier to locate a particular patient message and/or mailbox.

According to an aspect of the present disclosure, a two digit numeric entry, called a patient identifier, corresponds to a subset of mailboxes containing the mailbox desired and is used by the finder function to retrieve the mailbox for data entry in the mailbox. The patient identifier has several unique characteristics that allow efficient location of the appropriate mailbox.

According to an aspect of the present disclosure, the patient identifier can be used only to access a mailbox in the account of the account owner who assigned the patient identifier to a specific patient mailbox.

According to an aspect of the present disclosure, the patient identifier can be used only by the account owner who is authorized to leave a patient message in the particular mailbox—e.g., the patient identifier is available to the account owner using the system and only after the account owner gains access to the system using the appropriate security code.

According to an aspect of the present disclosure, the patient identifier is selected by the person who stores a patient message in the mailbox.

According to an aspect of the present disclosure, the patient identifier can only access mailboxes that do not contain patient messages.

According to an aspect of the present invention, the patient identifier can only access mailboxes that do not contain patient messages, or that have had patient messages stored less than a specific time period.

According to an aspect of the present disclosure, upon entering the patient identifier, information is presented to the user on the matching mailboxes to allow discrimination between the mailboxes. This allows the user to identify the appropriate mailbox. Typically, a patient identifier consisting of two digits will result in some redundancy—i.e., several mailboxes will have the same patient identifier and, often, the same patient since several tests may have been ordered on one patient.

According to an aspect of the present disclosure, the patient identifier is used on the system in conjunction with storing the patient name and then playing the associated account owner's chart note. This allows for rapid identification and choice of the proper mailbox by the account owner, since the system allows the listening account owner to “skip forward” at any time by pushing an appropriate touch tone telephone key.

According to an aspect of the present disclosure, a particular mailbox is only accessible by a patient identifier until a patient message has been stored in the mailbox. Thus, as patient messages are stored, there is a progressive decrease in the number of choices presented to the account owner when the system is entered to store another patient message. This aids in the speed and efficiency of an account owner's use of the system.

According to an aspect of the present disclosure, the system may retrieve in rank order the closest matches to a particular entered patient identifier.

According to an aspect of the present disclosure, once a set of mailboxes has been identified by entering a particular patient identifier, the system retrieves and presents the particular data in fields of each mailbox sequentially to the account owner in an order that allows the most discriminating fields to be presented first.

According to an aspect of the present disclosure, the patient identifier is a voice signal that the account owner voices into the system. The system records the vocal characteristics of the spoken patient identifier. When the account owner subsequently enters the system to place a patient message, the account owner may voice the patient identifier into the system and the system presents, in rank order, the nearest matches of the vocal characteristic electronic signal so inputted from which the account owner would choose the correct mailbox.

Interactive Voice Response Interface

According to another aspect of the present disclosure, the prompts heard by a particular user in the interactive voice response interface automatically change in response to the number of user entries by the particular user into the system and/or logic block of the system. The number of entries controlling this change is adjustable by the system administrator. A similar function operates for the same purpose if interfaces other than interactive voice response are used.

Per another aspect of the present disclosure, the value representing the number of entries that determines which prompt is played decays (decreases) over time.

Per another aspect of the present disclosure, the threshold that triggers change from one prompt to another changes over time.

According to an aspect of the present disclosure, several account owners who may work as a group may give patients the same telephone number to access the system to retrieve their messages. There are three numbers on a card given to the patient: The first number, is the telephone number, and is used to indicate which mailbox pool is being accessed. The second number, the mailbox number, is used to determine the mailbox number as well as the account that has the particular mailbox. The third number, the security code, is used to provide secure access to the mailbox with the patient message.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a simplified block diagram of a medical information system and its interactions with users in accordance with the present disclosure.

FIG. 2 illustrates a simplified hardware block diagram of a medical information system and associated input and output devices in accordance with the present disclosure.

FIG. 3 illustrates a simplified block diagram of relationships between telephony ports, mailbox pools, accounts, and patient databases in a medical information system in accordance with the present disclosure.

FIG. 4 illustrates a simplified block diagram of an alternative configuration of telephony ports, mailbox pools, accounts, and patient databases in a medical information system in accordance with the present invention.

FIG. 5 illustrates the medical information server and interfaces to other components of the system in accordance with the present invention.

FIG. 6 illustrates a logic flow diagram of a patient attempting to retrieve a patient message in a medical information system in accordance with the present disclosure.

FIG. 7 illustrates a logic flow diagram of a patient entering a mailbox number, if required, and security code(s) in a medical information system in accordance with the present invention.

FIG. 8 illustrates a logic flow diagram of an account owner or system administrator entering a medical information system in accordance with the present disclosure.

FIG. 9 illustrates a logic flow diagram for handling invalid security code entries of an individual entering a medical information system as an account owner or administrator in accordance with the present disclosure.

FIG. 10 illustrates a logic flow diagram of an account owner accessing administrator and alert information in a medical information system in accordance with the present invention.

FIG. 11 illustrates logic flow diagrams of an account owner accessing the main menu in several available configurations of a medical information system in accordance with the present disclosure.

FIG. 12 illustrates a logic flow diagram of an account owner accessing a main menu in a medical information system with patient database access in accordance with the present disclosure.

FIG. 13 illustrates a logic flow diagram of an account owner accessing an alternative main menu in a medical information system with patient database access in accordance with the present disclosure.

FIG. 14 illustrates a logic flow diagram of setting up a mailbox for chart note storage for future retrieval and/or access for patient message storage and setting a compliance or completion alert for mailboxes in a medical information system in accordance with the present disclosure.

FIG. 15 illustrates a logic flow diagram for assessing the status of a mailbox, or accessing a mailbox edit menu in a medical information system in accordance with the present disclosure.

FIG. 16 illustrates a logic flow diagram for locating the proper mailbox for patient message storage in a medical information system in accordance with the present disclosure.

FIG. 17 illustrates a logic flow diagram for entering and retrieving mailbox information as well as accessing a mailbox edit menu, recording a patient name, recording a patient message, and accessing chart notes and upload-source notes related to a mailbox in medical information system in accordance with the present disclosure.

FIG. 18 illustrates a logic flow diagram for recording a patient message, placing a pre-recorded patient message, re-recording a patient name, and appending or replacing a chart note for a mailbox in an medical information system in accordance with the present disclosure.

FIG. 19 illustrates a logic flow diagram for recording a patient message in a medical information system in accordance with the present disclosure.

FIG. 20 illustrates a logic flow diagram for placing a pre-recorded patient message in a mailbox in a medical information system in accordance with the present disclosure.

FIG. 21 illustrates a logic flow diagram for accessing a list of patient mailboxes with corresponding names and their messages entered on a particular date in a medical information system in accordance with the present disclosure.

FIG. 22 illustrates a logic flow diagram for accessing panic and other alert information on an account in a medical information system in accordance with the present disclosure.

FIG. 23 illustrates a logic flow diagram for entering alert information such as setting an alert note and the number of days until a patient-retrieval alert is activated in a medical information system in accordance with the present disclosure.

FIG. 24 illustrates a logic flow diagram for accessing and changing an account's status as well as listening to patient pre-recorded messages in a medical information system in accordance with the present disclosure.

FIG. 25 illustrates a logic flow diagram for changing account options in a medical information system in accordance with the present disclosure.

FIG. 26 illustrates a logic flow diagram for a system administrator menu in a medical information system in accordance with the present disclosure.

FIG. 27 illustrates a logic flow diagram for an administrator to access a mailbox pool to alter pool parameters and to change account settings in a medical information system in accordance with the present disclosure.

FIG. 28 illustrates a logic flow diagram for playing messages for an administrator in a medical information system in accordance with the present disclosure.

FIG. 29 illustrates a logic flow diagram for editing a patient message without playing the message in a medical information system in accordance with the present disclosure.

FIG. 30 illustrates a logic flow diagram for mailbox activation in a medical information system in accordance with the present disclosure.

FIG. 31 illustrates a logic flow diagram for placing suggestions in a medical information system in accordance with the present disclosure.

FIG. 32 illustrates a logic flow diagram for recording pre-recorded patient messages (Part I) in a medical information system in accordance with the present disclosure.

FIG. 33 illustrates a logic flow diagram for shutting down a medical information system in accordance with the present disclosure.

FIG. 34 illustrates a logic flow diagram for changing the administrator fax number in a medical information system in accordance with the present disclosure.

FIG. 35 illustrates a logic flow diagram for recording pre-recorded patient messages and titles to the messages (Part II) in a medical information system in accordance with the present disclosure.

FIG. 36 illustrates a logic flow diagram for storing patient messages in response to an no-message alert in a medical information system in accordance with the present disclosure.

FIG. 37 illustrates a logic flow diagram for recording information with review in a medical information system in accordance with the present disclosure.

FIG. 38 illustrates a logic flow diagram for recording information with no review in a medical information system in accordance with the present disclosure.

FIG. 39 illustrates a logic flow diagram for recording a patient name in a medical information system in accordance with the present disclosure.

FIG. 40 illustrates a logic flow diagram for recording an account owner name in a medical information system in accordance with the present disclosure.

FIG. 41 illustrates a logic flow diagram flow for accessing a list of patients and their messages or message titles entered on a particular day in a medical information system in accordance with the present disclosure.

FIG. 42 illustrates a logic flow diagram for an account owner to access alert information in the account in a medical information system in accordance with the present disclosure.

FIG. 43 illustrates a logic flow diagram for changing the access security code and/or account change code for an account owner in a medical information system in accordance with the present disclosure.

FIG. 44 illustrates a logic flow diagram for completion and compliance alert information entry in a medical information system in accordance with the present disclosure.

FIG. 45 illustrates a logic flow diagram for deleting or saving an alert that has been accessed in a medical information system in accordance with the present disclosure.

FIG. 46 illustrates a logic flow diagram for replacing alert information in a medical information system in accordance with the present disclosure.

FIG. 47 illustrates a logic flow diagram for deleting mailbox contents in a medical information system in accordance with the present disclosure.

FIG. 48 illustrates a logic flow diagram for re-recording a patient name in a medical information system in accordance with the present disclosure.

FIG. 49 illustrates a logic flow diagram for on-line training in a medical information system in accordance with the present disclosure.

FIG. 50 illustrates a logic flow diagram for reading a patient mailbox content in a medical information system in accordance with the present disclosure.

FIG. 51 illustrates a logic flow diagram for replacing a patient message in a medical information system in accordance with the present disclosure.

FIG. 52 illustrates a logic flow diagram of an account owner entering a medical information system for the first time and recording an account owner name and selecting a personal security code and fax number and, if appropriate, a new account change code according to the present disclosure.

FIG. 53 illustrates a logic flow diagram for an account owner to access a list of patient names and messages and upload-source notes uploaded by one or more upload-sources in a medical information system in accordance with the present disclosure.

FIG. 54 illustrates a logic flow diagram for an administrator to access an account's parameters in a medical information system in accordance with the present disclosure.

FIG. 55 illustrates a logic flow diagram for setting the number of mailboxes on an account in a medical information system in accordance with the present disclosure.

FIG. 56 illustrates a logic flow diagram to check whether or not a mailbox number is valid on an account in a medical information system in accordance with the present disclosure.

FIG. 57 illustrates a logic flow diagram in a medical information system with patient database access for locating a patient identification code from a patient finder code entry in accordance with the present disclosure.

FIG. 58 illustrates a logic flow diagram in a medical information system with patient database access for placing a patient message or chart note in accordance with the present disclosure.

FIG. 59 illustrates a logic flow diagram in a medical information system with patient database access for reviewing chart notes or for recording a chart note, a patient message, or the patient name or to place a pre-recorded patient message or set a completion/compliance alert in accordance with the present disclosure.

FIG. 60 illustrates a logic flow diagram in a medical information system with patient database access for recording a chart note or appending or replacing a chart note for a mailbox in accordance with to the present disclosure.

FIG. 61 illustrates a logic flow diagram in a medical information system with patient database access for reading chart notes associated with a specific patient identification code and account in accordance with the present disclosure.

FIG. 62 illustrates a logic flow diagram in a medical information system with patient database access for editing data in a mailbox in accordance with the present disclosure.

FIG. 63 illustrates a logic flow diagram in a medical information system with patient database access for retrieving and presenting a list of mailboxes that have a specific patient identification code and have unretrieved patient messages in accordance with the present disclosure.

FIG. 64 illustrates a logic flow diagram in a medical information system with patient database access for presenting the data in a particular mailbox in accordance with the present disclosure.

FIG. 65 illustrates a logic flow diagram for a system that possesses an array of prompts appropriate for each prompted step from which prompts are chosen to be used which fit the user's level of familiarity with the system in accordance with the present disclosure.

FIG. 66 illustrates a logic flow diagram for message uploading from an upload-source into the medical information system in accordance with the present disclosure.

DETAILED DESCRIPTION

I. System Overview

A system for providing and delivering medical information between (1) account owners such as medical providers, physicians and testing facilities, (2) upload-sources such as laboratories and testing facilities, and (3) patients, using a medical information server is described below. Section II describes typical users of the system. Section III provides definitions which may be used in conjunction with the present disclosure. Section IV describes reports generated by the system. Section V describes the system software and hardware architecture.

In the preferred embodiment an interactive voice response system (IVR) is used as an interface to the system and is described in Section VI. Flow chart diagrams for a system having a IVR interface are also described.

II. Users of the System

(1) Patients: A patient retrieves patient messages from the system by contacting the system through an input device, such as a touch tone telephone, and enters appropriate information such as mailbox number and security code.

(2) Account owners: Account owners are assigned an account on the system and may access the system to store or change messages for patients or make changes to their account parameters. Account owners, for example, could be medical providers such as physicians or their agents. An account owner may also be a medical facility that performs tests, such as a mammogram center or cancer screening centers. Account owners may access the system via IVR menus.

(3) Upload-source: The upload-source transfers patient test results and other information to the system using electronic data transfer.

(4) System administrator: The system administrator may use system screens and menus to configure the system and manage accounts and upload-sources, as well as provide general administration of the system.

III. Definitions

(1) Account—An Account is a collection of data that is used by the system to serve the account owner. An account may include, but is not limited to, the following data: Account configuration data, Mailbox collection, Mailbox loading activity list (lists of mailboxes with patient messages placed by account owner/mailboxes with messages uploaded today), mailbox status reports (account activity report), administrator voice mail messages, and recorded name of the account owner.

In an embodiment, an account may have an account message collection which contains pre-recorded patient messages for each account owner.

There are three account types to fit the needs of various account owners. The three account types are:

• • A) Account with patient database (PD) access—this account type uses a patient database.
  • B) Account with patient identifier feature and no patient database (PD) access—this account type uses the patient identifier feature to aid the account owner in placing patient messages and the account does not have access to a patient database.
  • C) Account without patient identifier feature and no patient database (PD) access—this account type does not have the patient identifier feature nor patient database (PD) access.

(2) Account message—patient message pre-recorded by account owner which can be stored in a mailbox.

(3) Account message title—short recorded description of an account message.

(4) Account Number—a number that identifies the account owner's account on the system.

(5) Account Owner—A user that has an account on the system and can access the system to use the account owner menus.

(6) Account security code—a code that allows account access.

(7) Activate alert—set an alert flag in a mailbox to “New” and if the mailbox is not in the account's list of alerted mailboxes, then add alert to the list.

(8) Alerts: Alerts are generated by the medical information server to notify the account owner and/or upload-source of important events. There are several types of alerts. Alerts that are used to inform account owners are referred to as owner alerts.

The following is a list of alert types:

A. Patient-retrieval alert: Either an account owner or an upload-source may request notification in the event that a patient does not retrieve a patient message within a deadline specified when setting the alert. In this situation, the system fulfills the request by activating an alert signal and delivering the alert signal to the account owner and/or upload-source. This alert serves to notify the account owner and upload-source of important results not successfully communicated to the patient so that other means and efforts may be undertaken to notify patient of their test results.

B. Upload-source-change alert: When an upload-source alters data in a mailbox and the account owner has accessed that data prior to the data alteration, the system activates an upload-source-change alert indicating that the data has been altered by an upload-source. The alert is communicated to the account owner.

C. No-message alert: An alert activated by the medical information server when the upload-source uploads information such as test results into an upload-source note in a mailbox without uploading a corresponding patient message in the mailbox. This alert is received by the account owner and serves as notification that the account owner should store an appropriate patient message in the mailbox for the patient.

D. Non-timed-upload alert: This alert notifies the account owner that test information has been uploaded into a mailbox. The alert is set by the upload-source at the time of upload and is activated by the system for the account owner. This alert may serve to notify the account owner that test information he or she was particularly interested in has been placed in the mailbox.

E. Timed-upload alert: This alert is similar to a non-timed-upload alert but adds the following feature: If the account owner does not retrieve the upload alert within a deadline specified when setting the alert, the system will notify the upload-source of this fact as part of either an expired-timed-upload alert (ETUAR) report or a Panic report. If the time period specified is within a pre-defined panic range then the alert is considered to be a panic alert. If an upload alert that is a panic alert and is not received by the account owner within the deadline, the alert will appear on a Panic report. In an embodiment, this report is may be sent by the system by fax. All timed-upload alerts that do not appear on a Panic report will appear on an Expired-timed-upload alert Report (ETUAR).

The timed-upload alert is used to notify the uploading source when an account owner has accessed information that has been uploaded into a patient message mailbox. The upload-source is notified through this alert activation if the account owner does not retrieve or access this information within the deadline specified by the upload-source. The upload-source may be notified of the time of retrieval of the information in a fax report. An account owner alert is set when an upload alert information is placed in a patient mailbox.

If the account owner retrieves this upload alert with Panic Status (i.e., accesses the patient message and/or upload-source note) within a parameter value number of days or hours, a signal, such as a fax, is generated with this retrieval information and sent to the upload-source.

In the preferred embodiment, whether or not the account owner retrieves the mailbox information within the specified deadline, a signal, such as a fax, is generated and sent to the upload-source within a parameter value set time. This signal (fax) indicates receipt or non-receipt of alert.

The panic alert serves to notify the account owner of critical results that need timely review and allows notification of the upload-source if account owner notification has been received or not within an upload-source set time.

In an embodiment, when a mailbox in an account has a panic alert, the system sends a signal, such as an electronic notification signal to a pager, to the account owner who has the mailbox assigned to him or her.

In an embodiment, when a mailbox in an account has a panic alert, and the account owner who has the mailbox assigned to him or her does not retrieve the panic alert by the upload-source set deadline, the system sends a signal, such as an electronic notification signal to a pager, to the account owner.

F. Patient-attempt alert: This is an alert activated by the system when the patient contacts the system to retrieve a patient message but no patient message is available. The patient-attempt alert is delivered to the account owner who has initialized the mailbox in an account without PD access, or placed a chart note for the patient in an account with PD access and informs the account owner that the patient is attempting to access information that has not as yet been stored in the mailbox.

In an embodiment if the mailbox belongs to a mailbox pool without PD access, and the mailbox has not been initialized then a patient-attempt alert is not activated for the mailbox.

G. Completion alert (for accounts without Patient Database access): This is an alert set by the account owner at the time the test is ordered for the patient. This alert is activated by the system and is delivered to the account owner when a patient message or upload-source note is placed in the mailbox by an upload-source. The purpose of this alert is to allow a means for the account owner to know the test result regardless of the outcome. For example, if the patient has been anemic and treated, the account owner might want to know the blood level even if the blood level test had returned to the normal range.

The completion alert is useful because in a situation where results are uploaded to the mailbox in the form of a pre-recorded patient message, the account owner may not be notified if the results are normal. Hence, a means such as this allows for account owner notification if desired regardless of the test results.

H. Compliance alert (for accounts without Patient Database access): This is an alert set by the account owner when the test is ordered. The system will activate this alert if a patient message or upload-source note has not been placed in the mailbox within the deadline specified when setting the alert. A compliance alert may be activated, for example, as a result of the patient not having the test done or if the test specimen is lost, since the test results won't be entered if these events occur. This may also be used to notify the account owner if the test result is not entered into the system by the time that the account owner informed the patient the test result would be available. This alert type is needed since at times an account owner may order a test that is important to be done timely and/or the account owner may feel that the patient may not comply with having an important test done.

In an alternative embodiment, the compliance alert can be set by the upload-source. This may be of use so that if the upload-source does not receive the test specimen within a time frame and wishes to communicate this fact to the account owner.

I. Completion/compliance alerts (for accounts with Patient Database access): For accounts with patient database access, the account owner does not assign mailbox numbers for the patient to obtain test results. The mailboxes are automatically assigned by the system. Accordingly, the account owner needs to assign a numeric sequence of digits that identifies a chart note which reflects the testing circumstances. This allows the system to associate a particular chart note to a particular mailbox via the particular numeric sequence of digits for a completion or compliance alert.

Thus, in an embodiment, the medical information server allows an account owner to place a completion notification request (CNR) for a patient's test result. The account owner provides a CNR identifying signal or number when the chart note is placed. The CNR identifying signal or number is unique to that chart note and the associated test and patient. The account owner at the time of generation of the CNR specifies a time limit in days to determine the CNR deadline. The account owner then transmits the unique CNR identifying signal or number to the upload-source. When the mailbox information is uploaded, the CNR allows identification of the mailbox so that the completion alert is activated for the account owner for the corresponding medical information. If no information is uploaded into the mailbox by the CNR deadline, then a compliance alert is activated for the mailbox.

In an alternative embodiment, the CNR code could be furnished to the account owner by the system in response to an account owner request.

J. Trace alerts (for accounts with Patient Database access): An account owner can choose to activate a trace for a patient at the time that a chart note is recorded. The account owner will specify a deadline in days for the trace which is used to determine the trace deadline. In the length of time prior to the trace alert deadline, whenever a mailbox is uploaded for this patient the account owner will receive a trace alert indicating a mailbox was uploaded. If more than one account has a trace set for a patient, each account will receive a trace alert for each mailbox uploaded. If no mailbox has been uploaded prior to the trace alert deadline, then a trace alert indicating this fact will be activated for the account and the trace alert setting will be removed. Each trace alert will have a status flag that indicates whether or not patient information was uploaded into the mailbox.

These alert communications can be via fax report, electronic mail, ASCII data file, sound file, voice file, voice mail, or other means and can include the patient name and name of the account owner and/or upload-source that set the alert information and/or entered information in the patient mailbox.

In an embodiment, only the account owner and/or upload-source who sets an alert will receive the alert if an alert is activated.

(9) Chart Note—a chart note is a text message and/or voice recording placed by the account owner in a mailbox that typically contains information the account owner will find useful in placing patient messages relating to test results coming back for the patient.

In an embodiment, a chart note is used with a patient identifier in the patient finder function to allow the account owner to identify the proper mailbox in which to place information.

In an alternate embodiment chart notes can be ASCII text that can be translated into speech using text-to-speech software.

(10) Completion Notification Request (CNR)—a request from the account owner to be notified when a mailbox is uploaded. Typically, a two digit CNR code will uniquely identify the CNR within the group of CNRs for a patient and account.

(11) Custom patient message—patient message recorded by account owner specifically for one patient.

(12) Deadline (Alert Deadline)—time period for an action to occur so that the associated alert flag is changed to New.

(13) Delete alert—setting an alert flag to unused and clears any alert deadline information for the alert and if there is no other active alert in the mailbox, then remove the alert from the account's list of alerted mailboxes.

(14) Expired patient message—Patient message that has been unretrieved before an account configuration parameter time period.

(15) Expired timed-upload alert—a timed-upload alert that was not retrieved by the account owner within deadline specified in the alert setting.

(16) Mailbox—a group of data relating to a single patient that may include, but is not limited to, a patient message and other information such as notes from an upload-source and/or account owner, and flags and information relating to various alerts, time message was uploaded, time message was retrieved by patient.

(17) Mailbox number—a number that uniquely identifies the mailbox within a mailbox pool.

(18) Mailbox pool—a group of mailboxes that account owners, upload sources, and their patients can access.

(19) Mailbox security code—a series of numeric digits that allows patient access to certain contents of a mailbox.

(20) Note—a text or voice recording placed by an account owner or upload-source containing information; this information is not accessible by patients.

(21) Patient Database (PD)—a database of patient records from which patient data can be utilized to reduce the amount of data the account owner must enter to set up a mailbox.

(22) Patient Finder Code (PFC)—a series of numeric digits used to identify a patient record that is not necessarily unique within the PD. The PFC is typically a short-hand version of the PIC that is more convenient for the account owners to input: If PFC use results in several patient matches in the PD, the system presents these to the account owner for the account owner to choose the correct entry.

(23) Patient Identification Code (PIC)—a series of numeric digits used to identify a patient that is unique for each patient in the PD.

(24) Patient message digits—digits that are spoken to patient after the pre-recorded patient message and may give a specific test result—e.g., “Your cholesterol is” “200”. The “200” is the patient message digits and represents the value of cholesterol for this test.

(25) Pre-Recorded patient message codes—Pre-recorded patient messages have a code that can be entered by the account owner to identify their content on reports and lists of patient messages. These codes are also used to specify which pre-recorded patient message is placed in a patient mailbox.

(25) PSC “Patient Security Code”(accounts with PD access only)—a series of numeric digits used to secure access to a patient's test results that is unique within the PD. The PSC may consist of two parts. Part A is a fixed length of digits for all patients in the PD. Part B can be variable length (up to 20 digits) and is typically used if Part A is not unique in the PD, But Part A and Part B together are unique to the PD.

(26) Reported mailbox—a mailbox that has appeared on an account activity report.

(27) Retired mailbox—mailbox that has had a patient message either expired or retrieved.

(28) Set Alert—alert information, such as an alert deadline, is placed in alert fields of the mailbox.

(29) System patient message—a pre-recorded patient message available to all account owners to place in patient mailboxes.

(30) System patient message title—short, recorded description of a system patient message.

(31) System prompt—pre-recorded voice message that either delivers information to the caller or requests caller input.

(32) Upload-source note—an upload-source note is a text message and/or voice recording placed in a mailbox by an upload-source containing information to the appropriate account owner who is assigned the mailbox and not the patient. The upload-source note is accessible only by the account owner and the upload-source that placed the upload-source note.

IV. Reports Generated by the System

In order to allow various users of the system to track pertinent activities including delivery of patient messages the system generates and automatically delivers to the account owners and upload sources several types of reports. These include the following:

1. Account Activity report: A report sent to an account owner that lists all mailboxes assigned to the account in which the patient message has either expired or been retrieved. This report can include the patient name, date that the patient message was placed by the account owner or upload-source, the account owner name, if patient retrieved the message, the date when the patient message was retrieved by the patient, indication if the patient message was not retrieved, if upload-source entered information then upload source identification, a code or synopsis that reflects the content and or type of patient message, and the types of alerts set for a mailbox, if any, together with the time information regarding alert flags and whether or not the account owner received these alert messages.

2. Upload Acceptance report: A report sent to an upload-source that lists the results of processing the last upload data file received by the system from this upload-source. This report includes any mailboxes that failed to accept information that was sent by the upload-source along with an error code that indicates the reason for the failure. This report may include the patient name, patient identifier (if report to account without PD access) or PIC (if the report is to an account with PD access), mailbox number, pre-recorded patient message code, the upload-source note, pertinent alert information, the name of the account owner, and the date and time of the data upload.

3. Upload Activity report: A report sent to an upload-source that lists all mailboxes which information has been uploaded by the upload-source and in which the patient message has either expired or been retrieved. This report can also include pertinent information as in other reports noted above for the Upload Acceptance report and the Account Activity report. This report also can indicate if a message has been accessed by the account owner who is assigned the mailbox and the time of this access.

4. Expired Timed-Upload Alert Report (ETUAR): A report sent to an upload-source that lists all expired-timed-upload alerts that do not have panic status. This report can also include pertinent information as noted above for other reports.

5. Panic report: A report sent to an upload-source that lists a single expired panic alert. In addition, this report can include the name of the account owner and/or the name of an alternative back-up provider for whom the alert was set as well as relevant information regarding content of this mailbox.

In an embodiment, the Panic report may include means and results of contact attempts regarding the account owner, alternate backup provider and the patient involved as well as other pertinent information noted above for other reports.

6. Summary Panic report: A report sent to both the upload-source and account owner that lists all panic alerts for a particular time period, the date and time the message and alert status was entered into a mailbox for each listed panic alert, and the date and time the alerts were retrieved by the account owner and the name of the account owner, an indication if alert(s) were not retrieved and any back-up provider(s) that were contacted and/or attempted to be contacted. This report can also include pertinent information as noted above for other reports.

In alternate embodiments, these reports may be faxed, e-mailed, or sent over a local or wide area network.

V. Medical Information System Software and Hardware Architecture

1. Medical Information System Hardware.

FIG. 1 illustrates a simplified block diagram 105 of a system which interfaces with users of the system in accordance with the present disclosure. The Medical Information Server 100 interfaces with the system administrator 101, the patient 102, the account owner 103, and the upload-source 104. FIG. 2 illustrates a simplified hardware block diagram of the medical information server 100 according to the present invention. In an embodiment server 100 includes processor 205 which in the preferred embodiment is an Intel Pentium™200 megahertz microprocessor. Processor 205 is coupled with disc 211, modem 204, network card 208, I/O card 271, random access memory (RAM) 207, video card and display 209, keyboard 214, telephony circuits 202 and voice resource circuits 206.

In a preferred embodiment, disc 211 will be a four-gigabyte hard disk drive. Disc 211 contains Windows NT 4.0 operating system 250, modem communication software 251, medical information server software 215, medical information server data 216, and hardware drivers 217. Hardware drivers include, Dialogic voice/fax card drivers, video drivers, modem drivers, and other drivers. Medical information server software 215 and medical information server data 216 are detailed further in FIG. 5.
In an alternate embodiment, medical information server programs and data may be stored at a remote location and accessed via network by server 100.

In an embodiment, modem 204 may be a 28.8 k bps modem, which provides remote access to server 100 for service and maintenance from telephony ports 201 which include plain old telephone service lines (“POTS lines”) 201a or through T1/E1 lines 210b.

RAM 207, in an embodiment, includes 64 megabytes of random access memory and contains Windows NT 4.0, along with appropriate device drivers.

In an embodiment, RAM 207 contains system software and includes the following products available from Artisoft Inc, Computer Telephony Products Group located at 5 Cambridge Center, Cambridge, Mass. 02142: (a) Visual Voice Pro Dialogic edition version 3.02 for Microsoft Windows NT 4.0, (b) Visual Voice Text-To-Speech 2.0 for Microsoft Windows NT 4.0, (c) Visual Fax 2.0 for Microsoft Windows NT 4.0, (d) Visual Voice Recognition Support 2.0 for Microsoft Windows NT 4.0.

In an embodiment, the following software products are loaded into Server 100 and are supported under Visual Voice Recognition support 2.0: The AT&T Watson™ SAPI engine, and the PureSpeech RECITE!™ Recognition engine for use on Dialogic Antaries™ Board. These software products are available from Artisoft™ Inc. The Dialogic Antaries™ voice board is available from Dialogic Corporation located at 1515 Route Ten, Parsippany, N.J. 07054.

In an embodiment, Visual Voice™ Text-To-Speech software utilizes the DECtalk™ text-to-speech engine, which is also available from Artisoft Inc.

In an alternative embodiment, Antaries™ board can utilize other speech recognition technology such as Applied Language Technologies' SpeechWorks™. In an embodiment, Applied Language Technologies software SpeechForms™, SpeechQuery™, and SpeechAgent™ are used in conjunction with SpeechWorks™. Applied Language Technology is located at 695 Atlantic Avenue, Third Floor, Boston, Mass. 02111.

In the embodiment, Dialogic Board Device drivers for Microsoft Windows NT 4.0 are loaded into RAM 207 and are available from Dialogic Corporation.

Appropriate run-time software Visual Basic 5.0, as well as communications software is loaded in RAM 207. The voice software interacts with processor 205 and telephony circuits 202 and voice resource card 206 and disk 211, to handle, for example, voice processing, voice recognition, faxing, and text-to-speech processing. Flow control charts as illustrated by FIGS. 6 through 66 are described in detail below and illustrate the operation of IVR interface program 215e (illustrated in FIG. 5) in Server 100.

In an embodiment, T-NetX™, Inc's Speak EZ Voice Print™ speaker verification software for Antares™ is installed in Server 100. T-NetX™, Inc is located at 67 Inverness Drive East, Englewood, Colo. 80112.

Manuals for specific software named above from Applied Language Technologies, Artisoft, Digital Equipment Corporation, PureSpeech, and Dialogic are incorporated by reference.

Patients, or those interested in obtaining medical information, as well as account owners and the system administrator, access server 100 by way of POTS lines 201a, or T1/E1 lines 201b. In an embodiment, an account owner or patient uses a touch-tone telephone to access telephony ports 201. In alternate embodiments, other data communication services, such as wireless services, can be used instead of telephony ports and may be directly coupled to telephony circuits 202.

In an embodiment, information upload from upload-source is via modem 204 or network card 208 or via scanner device such as a bar code scanner 272 through I/O card 271. In alternate embodiments other input devices such as optical information entry and translation, electromagnetic or RF devices may be used.

Telephony circuits 202 include, among other circuits, circuits for interfacing with telephony ports 201. These circuits include voice circuits 202a having a touch tone recognition circuit and voice processing circuit, as well as other circuits. Other circuits include switching circuits 202b, text-to-speech circuits 202c which have appropriate software and firmware, voice recognition circuits 202d which may include appropriate software/firmware, fax circuits 202e, and adapter circuits 202f.

In an embodiment, telephony circuits 202 may be a Dialogic D41ESC board, and Fax circuits may be a Dialogic VFX daughter board.

In an embodiment, Voice Resource Circuits 206 include a Dialogic Antaries board which contains Text-To-Speech software 206a and/or Voice Recognition software 206b. In an embodiment, the connection between Voice Resource circuits 206 and Telephony circuits 202 is via a Signal Computer (“SC”) connector.

In an embodiment, network card 208 is connected to a local area network (LAN) or wide area network (WAN) 220 which provides Server 100 access to other devices, and other devices access to Server 100. Some of these devices are represented by block 203 which contains Internet/Intranet 203a, a Net-PC 203b, and PC 203c.

System software 210 is primarily responsible for operating system 105, and in particular server 100.

FIG. 3 illustrates various embodiments of telephony ports, mailbox pools, users of accounts, and patient databases intercoupled in accordance with the present disclosure. Blocks 330331 and 332 represent telephony port groups. Telephony port group 330 consists of telephony ports 1, 2, and 3 represented by blocks 301, 302, and 303, respectively. Telephony port group 331 consists of telephony ports 4 and 5 represented by blocks 304 and 305 respectively. Telephony port group 332 consists of telephony port 6 represented by block 340. Telephony port groups 330, 331, and 332 have access to mailbox pool A as illustrated in block 306, mailbox pool B as illustrated in block 307 and mailbox pool C as illustrated in block 315, respectively.

In an embodiment, Mailbox Pool A has access to Patient Database F as illustrated in block 311 by account owner P as illustrated in block 308 and account owner Q in block 309 who may likewise access mailbox pool A by way of telephony port group 330.

Mailbox Pool B has access to Patient Database G as illustrated in block 312. Account owner, R as illustrated in block 310, may access Mailbox Pool B.

In an alternate embodiment, mailbox pool C does not have access to a patient database. Account owner S as illustrated in block 314 and account owner T as illustrated in block 321 are able to access mailbox pool C by telephony port group 6.

These embodiments illustrate that more than one account owner can interact with a single patient database and more than one account owner can access and use a single mailbox pool. Further, a single system can service account owners with or without access to a patient database.

In an embodiment, a patient database may be located on a remote server.

FIG. 4 illustrates a simplified block diagram of an alternative embodiment of telephony ports, mailbox pools, account owners, and patient databases in the medical information system 105. Blocks 430 and 431 consist of groups of telephony ports: Block 430 consists of telephony port 1 in block 401, telephony port 2 in block 402, and telephony port 3 in block 403. Block 431 consists of telephony port 4 in block 404 and telephony port 5 in block 405.

Mailbox pool A is represented by block 406 and Mailbox pool B is represented by block 407. Patient database R is represented by block 411 and patient database S is represented by block 412.

Account owner P as illustrated by block 408 interacts with telephony ports in block 430, Mailbox pool A represented by block 406, and patient database R represented by block 411.

Account owner E as illustrated by block 409 interacts with telephony ports in block 430, Mailbox pool A represented by block 406, and patient database S represented by block 412.

Account owner F as illustrated by block 410 interacts with telephony ports in block 431, Mailbox pool B represented by block 407, and patient database R represented by block 411.

Account owner G as illustrated by block 414 interacts with telephony ports in block 431, and mailbox pool B represented by block 407 and does not have access to a patient database.

FIG. 4 illustrates that system 105 may be configured so that more than one account owner can access a particular mailbox pool and that the accounts that access a particular mailbox pool may access different patient databases and that some of the account owners that access a particular mailbox may also have access to a patient database while others do not.

FIG. 5 illustrates a medical information server 100 having GUI screens, electronic chart software, and other interfaces. Server 100 software 215 includes master program 215a, Visual Interface program 215b, engine program 215c, and account owner/upload-source interface programs 215d (with IVR interface programs 215e, and upload-source interface program 215f).

Medical Information System (“MIS”) data 216 includes, for example: (a) Report data, (b) Patient Pre-recorded Message Code collection, (c) Account data collection, (d) administrator voice mail messages, (e) engine/pool/telephony port settings, (f) area codes/prefix data (for area codes and prefixes that medical information server can dial out to), (g) upload-source data, (h) PD data collection, (i) mailbox pool data, (j) voice prompts, (k) default configuration data, and (l) system patient message collection. (m) mailbox uploaded events collections, and (n) mailbox collections. In the embodiment, server 100 interacts with users via touch-tone telephone 598 and Fax 510 through a central office or PBX 597. Server 100 interacts through local or wide area networks 532 and internet/intranets 531. Remote software 516 can allow interaction with electronic chart software 516a or a graphic user interface (“GUI”) 501.

Block 501 illustrates a GUI of an Electronic Chart Software Screen. The screen contains a plurality of informational display screens and control buttons to facilitate information delivery and receipt. Screen segment 502 represents a patient information screen that displays pertinent information regarding a patient. Screen segment 503 represents the patient chart screen, where information on patient's medical chart is displayed. Screen segment 504 represents a patient message screen where information regarding messaging to the patient is displayed utilizing the Medical Information Server 100; uploaded test results may be represented as text here or accessed by sound device. Screen segment 508 represents patient messages suggested by an expert system in response to the test results represented in screen segment 504. An account owner may click on these to load the results into the appropriate mailbox. Buttons represented by blocks 505 and 506 are used to control content of patient chart screen 502 and patient info screen 504.

A user can extract information from the patient screen and use other input to place a patient message into a patient mailbox in server 100 by patient-message-send button represented by block 507. Button 507 allows electronic chart software to extract information from patient message screen as well as user input to place a patient message in medical information server 100 into a patient mailbox. The results of patient message delivery, including alert information are reported in patient information screen 504.

The system software Interface's public application programming interface facilitates the interactions noted above. Through these means a plurality of different interface embodiments are possible for handling test result information. The interfaces may present and receive data through a GUI and accept input from appropriate expert system suggested selections for possible patient messages. The account owner may then click on one such patient message to have the specific chosen message loaded into the patient mailbox.

In an embodiment, panic or other alert types may be communicated on the account owner's GUI screen for notification, acknowledgment, and reaction through the use of information resources available by way of medical information server 100.

2. Medical Information Server Software and Data.

Medical information server software and data includes, but is not limited to, (a) several databases, (b) a master program, that starts and stops the medical information server, (c) an engine or collection of software routines, (d) upload-sources data, (e) graphical user interface screens for the administrator and account owner, and (f) an interactive user interface, which in the preferred embodiment is an interactive voice response (IVR) interface. Interactive response interfaces include interactive voice telephony response interfaces, graphical user interfaces (GUI), video delivery mechanisms, wireless delivery mechanisms, or combinations of these.

Typical Data Groupings:

The engine references data in collections, wherein items can be added, deleted or edited; lists, wherein items can be added or deleted but not edited; and tables, wherein items can be edited but not added or deleted.

The engine interacts with at least the following data collections: (a) patient database (PD) data collection, (b) the patient message code collection, (c) the system patient message collection, (d) the administrator voice mail message collection, (e) the mailbox pool collection, (f) the upload-source data collection (a database consisting of data characterizing the upload-sources), (g) the disallowed prefix data collection, (h) the allowed area code/prefix data collection, (i) the default configurations data for the engine, mailbox pools, accounts, and upload-sources, (j) account collection, (k) engine/port/mailbox pool/accounts/upload-sources configuration data collection.

The patient database collection typically includes patient databases (PD) which contain (a) PD record data, (b) a PD chart note collection, (c) PD trace collection, and (d) a CNR list containing numbers of mailboxes with CNR's.

The Patient Message Code collection contains a group of patient message codes. In an embodiment, each patient message code contains the following data: (a) a series of digits that identifies the message, (b) a flag indicating whether or not the message is available for use, (c) a flag indicating whether or not the message is time sensitive (whether or not a patient-retrieval alert can be set or activated), (d) a flag indicating whether or not the message includes patient message digits, (e) a flag indicating whether or not the message includes a custom recorded segment that is appended to pre-recorded message, (f) a descriptive code that can be written on reports to describe contents of pre-recorded message.

The system patient message collection includes pre-recorded patient messages that are available on the entire system for all account owners.

The administrator voice mail message collection includes messages to the administrator from account owners on the system.

The mailbox pool collection contains a group of mailbox pools. In an embodiment, each mailbox pool contains (a) pool configuration data, (b) a collection of unused mailboxes, and (c) an account collection.

Each account in the account collection contains account configuration data and a collection of mailboxes.

In an embodiment, mailboxes may contain upload-source notes, chart notes, and alert notes (e.g. alert notes typically contain the patient telephone number) which may be voiced or in ASCII format, or ASCII translated to voice via a text-to-speech method.

In an embodiment, each account also contains a list of noted mailboxes with a chart and/or upload-source note loaded and no patient message loaded, a list of messaged mailboxes with patient messages loaded, a list of retired mailboxes, a list of mailbox coded events, a list of mailbox uploaded events, a list of alerted mailboxes, a list of mailboxes wherein the patient message has been reported, an account activity reports collection containing account activity reports for the account, an account message collection and an administrator voice mail message collection.

The upload-source data collection contains a group of upload-sources. In an embodiment, each upload-source contains (a) a retired mailbox list, (b) an upload activity reports collection, (c) a timed-upload alerts collection, (d) an expired-timed-upload alerts collection, (e) an expired-timed-upload alert report list, (f) a list of Panic reports, (g) data relating to the upload activity report format and Panic reports formats, and (h) upload-source configuration data.

The Disallowed Prefix data collection includes data that the medical information server uses in preventing connection via telephone with undesirable locations—e.g., in an interactive voice response interface embodiment, numbers such as 911 cannot be called.

The Allowed Area Code/Prefix collection includes data that limits the system to contacting only certain desirable locations—e.g., in an interactive voice response interface embodiment, the area codes that the system is allowed to call out to, which in the present software has been described as resident in the architecture illustrated in FIG. 5. In an another embodiment this software may be stored on an article of manufacture, such as a magnetic or optical medium.

A. The Engine

The engine is a collection of software routines that manage the storage of, the access to, and the transfer and manipulation of data relating to the following: engine/port/mailbox pool/account/upload-source configuration, patient databases, mailbox pools including mailbox and account data, and upload-source data. The engine handles all automatic processing of this data including checking for expirations and activating alerts and generating reports. The engine interacts with interface software so as to allow use of the system across several different modes of operation and platforms with minimal reconfiguration. Similarly, the engine interacts with database access software to allow the use of a variety of database servers with little or no added reconfiguration.

1. Engine Interaction with Configured Data

The engine is started and stopped via the master control program 215a. The engine on start-up reads the engine configuration data and the other system components configuration data. The engine also reconfigures the system in response to changes in configuration data via administrator screens. The engine provides access to the disallowed prefix collection and Allowed Area Code collections and deletes expired system logs and mailboxes.

2. Engine Interaction with Patient Databases

The engine has the capability to add or delete to their respective collections a PD, trace alert, upload-source note, and chart note. The engine can also allow editing an existing PD, trace alert, upload-source note and chart note.

The engine allows additions to the PD by upload-sources and the administrator. The engine also allows the administrator to make changes and deletions in the PD. The engine also can retrieve data from, add data to, and delete records from the PD database. The engine can verify validity of access by checking the patient identification code (PIC) prior to allowing these actions.

The engine also searches for records using a particular patient finder code (PFC). The IVR interface and the engine allow the user to identify the correct patient if necessary from the group selected by the PFC.

In an embodiment the engine may use text-to-speech software to convert uploaded ASCII strings in patient name fields and upload-source note fields to voice files. The engine can retrieve and delete and write data to and from chart notes, upload-source notes, and alerts.

The engine can retrieve a patient name voice recording from a PD record.

The engine can also retrieve a list of chart notes for (1) a specific PIC, (2) for a specific PIC and specific creation date, (3) for a specific medical account owner and PIC, and (4) for a specific PIC, creation date or range of dates and particular account owner.

The engine can check for and delete any PD chart notes that have exceeded a parameter set maximum stay on the system.

In an account without PD access, the engine can check for and delete any chart notes that have exceeded a parameter set maximum stay on the system.

The engine is able to: (1) allow only the account owner who originally created a chart note to add to, replace or delete the particular chart note; (2) allow any account owner to listen to any chart note for any patient in a PD to which the account has access. Any number of account owners can create a chart note for the same patient on a particular day.

When creating the chart or upload-source note the engine can assign an unique identifying number (CNR) associated with the account owner number and PIC and sets the creation date for this upload-source or chart note to the current date. The engine also converts, if needed, ASCII text to a voice recording file using text-to-speech software.

The engine is able to set and/or activate one trace alert per patient for each account owner. Several account owners may have trace alerts set and/or active for a particular patient. The engine checks trace alert deadlines and activates compliance alerts accordingly and places them in the appropriate mailbox. Likewise, when test results are uploaded, the engine activates the completion alerts in the appropriate mailbox.

3. Engine Interaction with Messages

The engine allows pre-recorded patient messages to be accessed through patient pre-recorded message codes from a patient pre-recorded message code collection. Codes and messages may be added or deleted from this collection. The engine can check if a particular patient pre-recorded message code entry exists and respond appropriately. The patient pre-recorded message collection contains fields for each patient pre-recorded message code specifying if the patient pre-recorded message code is active or not on the system, is time sensitive, and if the pre-recorded message requires patient message digits or has custom recorded segment which is played after the patient pre-recorded message to specify test result values, a time for an appointment, or other patient information.

The engine also enables creation of system patient messages for corresponding message codes and can add, retrieve, or delete these recordings. The engine can associate a system patient message title with each system patient message code that summarizes the message content.

The engine also enables creation of administrator voice mail messages, which are added to an administrator voice mail message collection. The engine allows addition or deletion as well as retrieving such messages and a count of such messages. Data in a voice mail message may include message identification number, account owner number that sent the message, account owner name that sent message, status of message (new or old), and the message voice recording or the memory location of the file that contains the messages.

The engine also maintains a count of new and saved administrator voice mail messages.

4. Engine Interaction with a Mailbox Pool Collection

The engine maintains a mailbox pool data collection and is capable of adding and deleting mailbox pools and retrieving data from a mailbox pool.

In an embodiment, each mailbox pool contains the following configuration data: Pool number, pool name, and whether or not the pool functions with a patient database enabled and, if so, the patient database number.

Each mailbox pool may have a range of mailboxes available that are accessible by upload-sources for data entry without a security code. This is termed the unprotected mailbox range.

In an embodiment, each pool includes at least the following additional parameters:

Expiration Parameters: (a) maximum days a patient message can stay unretrieved in a mailbox, (b) number of days after a mailbox is reported before mailbox is deleted, (c) maximum days a mailbox can have a chart note and no patient message loaded, (d) maximum days an account activity report will be kept, (e) maximum days an upload activity report will be kept, (f) maximum days a mailbox can remain unused.

1. A machine-implemented notifying method which is able to notify responsible parties of notification-worthy events occurring in an automation-assisted medical messaging system, where at least two of the following messaging transactions can take place in the medical messaging system: (0.1) a medical service provider orders one or more medical tests to be performed on a given patient where one or more deadlines may be indicated for the performance of the tests and/or for the reporting of corresponding test results to the medical service provider; (0.2) an upload source automatically uploads test results and/or other for-provider information into a machine-implemented mailbox, where the mailbox corresponds to a given patient, and where the mailbox is structured to allow a medical service provider to access the uploaded test results and/or other for-provider information of the corresponding mailbox; (0.3) the upload source automatically uploads test result changes and/or other informational changes into the machine-implemented mailbox of the given patient; (0.4) an expert system automatically analyzes test results and/or other for-provider information, generates a notification urgency value for the analyzed information, where the generated notification urgency value is indicative of whether a corresponding predefined threshold has been exceeded where the threshold has been established for the analyzed type of test results and/or other for-provider information; (0.5) a medical service provider places a message for retrieval by a given patient where the placed message asks the given patient to contact the medical service provider, and where said requested contacting by the given patient may have a time deadline associated therewith; (0.6) a medical service provider is allowed to review uploaded test results and/or other for-provider information uploaded into the machine-implemented mailbox of a given patient; (0.7) after review of uploaded test results and/or other for-provider information, a medical service provider is allowed to place and/or approve for placement, corresponding, for-patient information in the mailbox for retrieval by the given patient, where one or more deadlines may be indicated for retrieval by the patient of the placed, for-patient information; and (0.8) a patient is allowed to attempt to access a corresponding patient mailbox even if there is no for-patient information placed in that mailbox;

said notifying method comprising: (a) testing the messaging transactions of the medical messaging system and responsively generating corresponding alerts for retrieval by one or more alertable parties, where the generated and retrievable alerts can be deleted after they are retrieved, where the generated and retrievable alerts are designated as belonging to at least one category in a set of predefined alert categories, where the predefined alert categories include at least two of the following alert categories: (a.1) a panic alert category indicative of a failure of an alertable party to timely retrieve a placed alert of a lesser urgency than the panic alert being currently generated, where timely retrieval of the less urgent alert is constituted by retrieval of the less urgent alert before expiration of a deadline established for retrieval of the less urgent alert; (a.2) a patient retrieval alert category indicative of a failure of a patient to timely retrieve a placed, for-patient message before expiration of a deadline established for retrieval of the placed, for-patient message; (a.3) a missing message alert category indicative of a failure of a responsible party to timely place a for-patient message in a corresponding mailbox before expiration of a deadline established for placing the for-patient message; (a.4) a test noncompliance alert category indicative of a failure of a corresponding one or more test results to be uploaded into a given mailbox before expiration of a respective one or more deadlines established for completion of correspondingly ordered tests and for reporting of the corresponding test results; (a.5) a traced test noncompliance alert category indicative of a failure of a corresponding one or more of plural test results to be uploaded into a given mailbox before expiration of a respective one or more deadlines established for completion of a correspondingly ordered set of plural tests, where the plural tests are pre-designated as belonging to a traced set of tests; (a.6) a traced test completion alert category indicative of successful and timely uploading of a corresponding one or more of plural test results into a given mailbox before expiration of a respective one or more deadlines established for completion of a correspondingly ordered set of plural tests, where the plural tests are pre-designated as belonging to a traced set of tests; (a.7) a changed upload alert category indicative of a change of upload information in a given mailbox after a medical service provider has accessed for-provider information that was earlier uploaded into the given mailbox, where change of upload information alters validity of the earlier uploaded information; (a.8) a test completion alert category indicative of a successful uploading of a corresponding one or more test results into a given mailbox; (a.9) an upload alert category indicative of for-provider information having been automatically uploaded into a given mailbox where the upload source is indicating via the upload alert, a desire for the medical service provider to be aware of the automatically uploaded, for-provider information; (a.10) a patient attempt alert category indicative of a patient attempting to retrieve for-patient information from a mailbox that does not contain for-patient information; and (a.11) a timed upload alert category indicative of for-provider information having been automatically uploaded into a given mailbox where the upload source is indicating via the timed upload alert, a desire for the medical service provider to be aware of the automatically uploaded, for-provider information before expiration of an established deadline; (b) collecting generated alerts that have not yet been deleted and determining the respective categories into which the collected alerts belong; and (c) presenting to a medical service provider and/or to another responsible and notifiable party information indicating the category of one or more of the collected alerts.

2. The machine-implemented notifying method of claim 1 wherein the at least two alert categories include said test completion alert category (a.8).

3. The machine-implemented notifying method of claim 1 wherein the at least two alert categories include said test noncompliance alert category (a.4).

4. The machine-implemented notifying method of claim 1 wherein the at least two alert categories include said changed upload alert category (a.7).

5. The machine-implemented notifying method of claim 1 wherein the at least two alert categories include said patient attempt alert category (a.10).

6. The machine-implemented notifying method of claim 1 wherein the at least two alert categories include said timed upload alert category (a.11) and where the upload source has determined that the uploaded information deserves the issuance of a panic alert if the timed upload alert is not responded to before expiration of the established deadline.

7. The machine-implemented notifying method of claim 1 wherein said predefined alert categories are ordered according to a predefined priority scheme and the step of presenting includes (c.1) presenting information about alerts in a higher priority one of said at least two alert categories to the medical service provider and/or other responsible and notifiable party before presenting information about alerts in a lower priority one of said at least two alert categories.

8. The machine-implemented notifying method of claim 7 wherein the at least two alert categories include said panic alert category (a.1) and the panic alert category is ordered as the highest priority one of said predefined alert categories.

9. The machine-implemented notifying method of claim 1 wherein said predefined alert categories are ordered according to a predefined priority scheme and the step of presenting includes (c.1) presenting information about how many collected alerts are present in a given one or more of said at least two alert categories to the medical service provider and/or other responsible and notifiable party before presenting more detailed information about the alerts of the one or more alert categories.

10. The machine-implemented notifying method of claim 9 wherein said information about how many collected alerts are present in a given one or more of said at least two alert categories is machine-vocalized to the medical service provider and/or other responsible and notifiable party.

11. The machine-implemented notifying method of claim 1 wherein the predefined alert categories, to which respective ones of the generated and retrievable alerts are designated, include: (a.12) at least four of said categories (a.1) through (a.11).

12. The machine-implemented notifying method of claim 1 wherein the predefined alert categories, to which respective ones of the generated and retrievable alerts are designated, include: (a.12) at least eight of said categories (a.1) through (a.11).

13. An automated notification system for notifying responsible parties of notification-worthy events occurring in an automation-assisted medical messaging system, where at least two of the following messaging transactions can take place in the medical messaging system: (0.1) a medical service provider orders one or more medical tests to be performed on a given patient where one or more deadlines may be indicated for the performance of the tests and/or for the reporting of corresponding test results to the medical service provider; (0.2) an upload source automatically uploads test results and/or other for-provider information into a machine-implemented mailbox, where the mailbox corresponds to a given patient, and where the mailbox is structured to allow a medical service provider to access the uploaded test results and/or other for-provider information of the corresponding mailbox; (0.3) the upload source automatically uploads test result changes and/or other informational changes into the machine-implemented mailbox of the given patient; (0.4) an expert system automatically analyzes test results and/or other for-provider information, generates a notification urgency value for the analyzed information, where the generated notification urgency value is indicative of whether a corresponding predefined threshold has been exceeded where the threshold has been established for the analyzed type of test results and/or other for-provider information; (0.5) a medical service provider places a message for retrieval by a given patient where the placed message asks the given patient to contact the medical service provider, and where said requested contacting by the given patient may have a time deadline associated therewith; (0.6) a medical service provider is allowed to review uploaded test results and/or other for-provider information uploaded into the machine-implemented mailbox of a given patient; (0.7) after review of uploaded test results and/or other for-provider information, a medical service provider is allowed to place and/or approve for placement, corresponding, for-patient information in the mailbox for retrieval by the given patient, where one or more deadlines may be indicated for retrieval by the patient of the placed, for-patient information; and (0.8) a patient is allowed to attempt to access a corresponding patient mailbox even if there is no for-patient information placed in that mailbox;

said automated notification system comprises: (a) one or more alert event detectors which monitor the messaging transactions of the medical messaging system and responsively generate corresponding alerts for retrieval by one or more alertable parties, where the generated and retrievable alerts can be deleted after they are retrieved, where the generated and retrievable alerts are machine designated as belonging to at least one category in a set of predefined alert categories, where the predefined alert categories include at least two of the following alert categories: (a.1) a panic alert category indicative of a failure of an alertable party to timely retrieve a placed alert of a lesser urgency than the panic alert being currently generated, where timely retrieval of the less urgent alert is constituted by retrieval of the less urgent alert before expiration of a deadline established for retrieval of the less urgent alert; (a.2) a patient retrieval alert category indicative of a failure of a patient to timely retrieve a placed, for-patient message before expiration of a deadline established for retrieval of the placed, for-patient message; (a.3) a missing message alert category indicative of a failure of a responsible party to timely place a for-patient message in a corresponding mailbox before expiration of a deadline established for placing the for-patient message; (a.4) a test noncompliance alert category indicative of a failure of a corresponding one or more test results to be uploaded into a given mailbox before expiration of a respective one or more deadlines established for completion of correspondingly ordered tests and for reporting of the corresponding test results; (a.5) a traced test noncompliance alert category indicative of a failure of a corresponding one or more of plural test results to be uploaded into a given mailbox before expiration of a respective one or more deadlines established for completion of a correspondingly ordered set of plural tests, where the plural tests are pre-designated as belonging to a traced set of tests; (a.6) a traced test completion alert category indicative of successful and timely uploading of a corresponding one or more of plural test results into a given mailbox before expiration of a respective one or more deadlines established for completion of a correspondingly ordered set of plural tests, where the plural tests are pre-designated as belonging to a traced set of tests; (a.7) a changed upload alert category indicative of a change of upload information in a given mailbox after a medical service provider has accessed for-provider information that was earlier uploaded into the given mailbox, where change of upload information alters validity of the earlier uploaded information; (a.8) a test completion alert category indicative of a successful uploading of a corresponding one or more test results into a given mailbox; (a.9) an upload alert category indicative of for-provider information having been automatically uploaded into a given mailbox where the upload source is indicating via the upload alert, a desire for the medical service provider to be aware of the automatically uploaded, for-provider information; (a.10) a patient attempt alert category indicative of a patient attempting to retrieve for-patient information from a mailbox that does not contain for-patient information; and (a.11) a timed upload alert category indicative of for-provider information having been automatically uploaded into a given mailbox where the upload source is indicating via the timed upload alert, a desire for the medical service provider to be aware of the automatically uploaded, for-provider information before expiration of an established deadline; (b) an alerts collector which collects generated alerts that have not yet been deleted and identifies the respective categories into which the collected alerts belong; and (c) an alerts presenter which can present to a medical service provider and/or to another responsible and notifiable party information indicating the category of one or more of the collected alerts.

14. The automated notification system of claim 13 wherein said predefined alert categories are ordered according to a predefined priority scheme and the alerts presenter includes: (c.1) a presentation prioritizer which causes presentation of information about alerts in a higher priority one of said at least two alert categories to surpass presentation of information about alerts in a lower priority one of said at least two alert categories.

15. The automated notification system of claim 14 wherein said surpassing of presentation includes at least one of serially presenting the higher priority information before the lower priority information, or listing the higher priority information before the lower priority information.

16. The automated notification system of claim 14 wherein said presentation of information includes indicating how many collected alerts are present in a given one or more of said at least two alert categories.

17. The automated notification system of claim 14 wherein said presentation of information about the alerts includes a machine-vocalized presentation.

18. The automated notification system of claim 13 wherein the predefined alert categories, to which respective ones of the generated and retrievable alerts are designated, include at least eight of said categories (a.1) through (a.11).

19. A machine-implemented alert forwarding method which is able to alert responsible parties of alert-worthy events occurring in an automation-assisted medical messaging system, wherein operations within the medical messaging system are characterized by: (0.1) a medical service provider orders one or more medical tests to be performed on a given one or more patients; (0.2) corresponding test results are generated; (0.3) a machine-implemented upload source automatically uploads the generated test results and/or corresponding other for-provider information into one or more machine-implemented mailboxes, where each mailbox is structured to allow a medical service provider to access the uploaded test results and/or other for-provider information; (0.4) an expert system automatically analyzes the test results and/or other for-provider information and generates an alert flag for the analyzed information if the analyzed information is outside of predefined bounds; (0.5) the generated alert flags are logically associated with the uploaded test results and/or other for-provider information uploaded into the machine-implemented mailbox; (0.6) the generated alert flags are assigned deadlines by which review is to occur of their corresponding uploaded test results and/or other uploaded for-provider information; (0.7) a medical service provider is allowed to review uploaded test results and/or other for-provider information uploaded into the machine-implemented mailbox; (0.8) one or more, supplementally notifiable persons are designated; (0.9) the medical service provider and/or the one or more, supplementally notifiable persons can be presented with respective alert indicators corresponding to said, generated alert flags, if any; (0.10) inhibiting deletion of the associated alert flag, if any, of uploaded test results and/or other uploaded for-provider information until the corresponding uploaded information is reviewed;

said alert forwarding method comprising: (a) automatically finding undeleted alert flags and determining if review by a responsible medical service provider has taken place for the associated uploaded test results and/or other uploaded for-provider information; and (b) if the assigned deadline of the corresponding and not-yet-deleted alert flag has passed and if it is automatically determined that a responsible medical service provider has not yet reviewed the logically-associated, uploaded test results and/or other uploaded for-provider information, then automatically forwarding a corresponding notification alert signal to at least one of said supplementally notifiable persons where the notification alert signal identifies the uploaded information that has not yet been reviewed.