WO2000003343A1

WO2000003343A1 - Method and system for electronically managing and reimbursing medical care

Info

Publication number: WO2000003343A1
Application number: PCT/US1999/015429
Authority: WO
Inventors: Gregory A. Gratias; Joseph B. Lennon; Bakhitzhan Nurzhanov
Original assignee: Asterion.Com, Inc.
Priority date: 1998-07-10
Filing date: 1999-07-09
Publication date: 2000-01-20
Also published as: AU4976199A

Abstract

A system for guiding medical service providers in making referrals and in providing services that are automatically authorized for specified payments. Upon an initial encounter with a patient, the system guides a user through identifying insurance plan member information, verifying patient number and eligibility, and identifying related past encounter. The system then assists the user in creating a referral that authorizes a performing provider to provide certain medical services which are guaranteed to be reimbursed at a determinable level. The system guides the user in specifying a referring and performing provider, a type of facility, a referral basis and treatment type suggestions, and an urgency level. For each specification, the system indicates choices for which the system can automatically authorize a referral that results. The system also assists review users in manually authorizing referrals that the system cannot automatically authorize. When a person seeks care from a preforming provider for which an authorized referral exists, the system retrieves relevant patient medical history and assists a user in specifying authorized diagnosis and service codes, corresponding to the medical diagnoses made and the medical services provided, such that the provider is guaranteed to receive a determinable payment. If diagnosis or service codes are specified for which the system cannot automatically authorize payment, the system assists review users in manually adjucating and authorizing the payment to be received. When services are authorized for payment, the system automatically makes payment.

Description

METHOD AND SYSTEM FOR ELECTRONICALLY MANAGING AND REIMBURSING MEDICAL CARE

TECHNICAL FIELD

The present invention relates generally to improving medical care, and more particularly to guiding medical service providers through providing services and making referrals that are automatically authorized for payment.

BACKGROUND OF THE INVENTION

In the current environment where costs associated with medical care are closely managed, medical service providers ("providers^'") such as doctors, hospitals, and labs are often limited in the types of medical services ( . e. , procedures and products) which they are authorized to provide. For example, insurance plans will typically provide payment for services only if the necessity for the services is justified and the services are covered by the insurance plan. Similarly, incentives to restrict unwarranted services exist for managed care organizations, such as physician groups with capitated contracts in which a fixed monetary amount is received for each covered patient.

Even if a provider knows that a particular service is authorized for a particular patient, it is often necessary for the provider to submit a claim in the appropriate format and with the correct information to ensure that the provider will receive payment. For example, many insurance plans require the use of diagnosis and service codes in their claims to describe respectively a patient^'s problems and the services provided to address the problems. A common example of diagnosis codes is the International Classification of Diseases. 9th Revision (ICD-9) code set based on U.S. Department of Health and Human Services Publication No. (PHS) 91-1260. Similarly, many insurance plans use a code set of Common Procedure Techniques (CPT) codes to reflect services supplied by doctors. Other types of providers use other common sets of codes (e.g., HCPC codes for hospitals).

The complexity of medical care has led to large numbers of codes in most code sets, including thousands of diagnosis and service codes. These large numbers make the selection of appropriate codes difficult. Merely finding appropriate codes from among the many possibilities can be a significant challenge. Moreover, it is often the case that two or more codes can be used to describe a diagnosis or a service, but an insurance plan may provide payment for only some of the possible codes. Thus, even if a patient's insurance plan would be willing to fully reimburse an appropriate claim for a particular type of service performed, it is difficult for a provider to select the appropriate diagnosis and service codes to ensure that payment will be received.

Moreover, even if diagnosis and service codes are correctly supplied, receiving payment for services can be time-consuming and subject to error. For example, claims have historically been submitted on paper forms. Each time the information on the form must be re-entered into a computer system, such as when the insurance plan determines payment, it is possible for errors to be introduced. In addition, the insurance plan and/or a managed care organization^'s Utilization Management (UM) group must process each claim, check patient eligibility, verify that a performing provider (i.e., the provider performing a service) is authorized to provide the particular service or that a referring provider (i.e., the provider making a referral) is authorized to make the referral, check the maximum benefit for the service provided, and submit payment to the appropriate providers. After submitting a claim, a provider must track the status of the claim while waiting for reimbursement, match payments received to the appropriate services provided, post payments to the appropriate claim, and deal with denials and adjustments. In addition, a UM group may need to audit claims that are paid and identify errors, and the insurance plan must adjust later payments to the provider to reflect errors made. It is not uncommon for this procedure to take several months. The current situation is made even more difficult for providers because they typically do not know whether particular services are covered for a particular patient, and if so, at what level they will be compensated. Thus, when a patient first comes to a provider, the provider must attempt to verify the status of a patient as an eligible member of an insurance plan and to determine the types of services that will be covered for this patient. Covered services will vary for each insurance plan, and can even vary for individual patients within a plan. Due to these various uncertainties, providers can wait for many months before knowing whether and how much they will be paid for services performed.

A similar situation exists for referrals made for extended care or for specialized services. Not only is it difficult for the referring provider to know whether the referral will be covered by the insurance plan, it is also difficult for a referring provider to know exactly what specialty service is needed. For example, a general practitioner may know that a patient has some type of heart irregularity, but may not be qualified or authorized to make the particular diagnosis needed to recommend ICD-9 and CPT codes. A specialist performing provider who receives a referral may be even less familiar with the services typically covered by a particular insurance plan, and thus may face even greater uncertainty about the possibility of payment.

Thus, for both services performed and referrals made, the current situation requires significant effort by providers to receive payment and creates uncertainty and delay in their receipt. While uncertainty can be reduced for services that can be postponed until the}' can be pre-authorized by the insurance plan, that is also a time-consuming process and may still not indicate the precise amount of payment that will be received. The current situation also requires significant effort by insurance plans and UM groups to track referrals and services performed, to preauthorize a variety of referrals and services, to determine whether to authorize payment for claims, and to supply and track payments. The current situation is also frustrating for patients because each time they visit a new provider they must re-specify a variety of patient data before receiving care, and the provider will have to re-enter information about past services provided and any current referral.

SUMMARY OF THE INVENTION

Some embodiments of the present invention provide a method and system for guiding medical service providers in making referrals and in selecting services to be provided that are automatically authorized for specified payments. The system creates and shares electronic patient claim records (PCRs) that are transferred between providers and other authorized users, and that are automatically paid when they are either automatically or manually authorized. When a patient first visits a provider, the system assists the provider to determine patient eligibility and to identify relevant patient medical history and related past treatments. If the patient is to be referred to a performing provider for the provision of medical services, the system assists the user in specifying the referring and performing providers, a referral basis, a type of facility for treatment, a suggested type of treatment, and an urgency of treatment. As each specification is made, the information is stored in the PCR. For each specification, the system provides possible choices for which the system can automatically authorize payment, with the capability to restrict these possible choices based on previous specifications and other relevant information.

If a referral is automatically authorized, the corresponding PCR is immediately forwarded electronically to the selected performing provider without requiring manual review. When a performing provider is to treat a patient, the system assists a user in specifying diagnosis and service codes for which the system can automatically authorize payment. If the treatment is automatically authorized, a payment amount is automatically determined and disclosed to the performing provider, and the determined amount is automatically paid. If a referral, treatment, or payment request cannot be automatically authorized, the system forwards the corresponding PCR to an appropriate person for rapid manual approval of the request. The appropriate person may be any person at a specified review level (e.g., any Utilization Review nurse) or a specific person (e.g., a particular case manager). The system also supports specialized functionality, such as separate support functions for hospital performing providers. For such performing providers, the system tracks information such as admission and discharge dates as well as journal entries made.

In one embodiment, all users of the system are in constant two-way computer communication, such as via a network of computers or via terminals attached to a shared server. In this embodiment, PCRs and other messages can be forwarded to users in a variety of ways, such as via messages sent to and stored on local computers or as information stored on a central server for retrieval by the appropriate clients. In another embodiment, some users are contactable in other ways such as by one-way or two-way pager, cellular phone, voice mail. etc. For example, a physician who can manually approve a type of procedure may carry a pager rather than be tied to a particular computer. The system tracks the status of various users, and forwards information to them in the manner appropriate for that user. Thus, if a destination user has access to a computer connection, a PCR can be forwarded to the user as an object or as email. Alternately, if the user has a communication device such as a pager or a phone, the system can convert the information from the PCR into an appropriate alphanumeric or spoken format so that the user can receive the information on their communication device.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a diagram illustrating an embodiment of the Electronic Managed Care Commerce (EMCC) system of the present invention.

Figures 2-15 are example user interface screens of an EMCC system. Figure 16 is a block diagram illustrating an embodiment of an EMCC system.

Figures 17A and 17B are exemplary flow diagrams of an embodiment of the Gatekeeper routine.

Figure 18 is an exemplary flow diagram of an embodiment of the Designate Referral Information subroutine.

Figure 19 is an exemplary flow diagram of an embodiment of the Select An Instance Of Specified Type Of Information Based On Specified Context Of Past Selections subroutine.

Figures 20A and 20B are exemplary flow diagrams of an embodiment of the Remote Distribution subroutine.

Figure 21 is an exemplary flow diagram of an embodiment of the Authorization routine.

Figure 22 is an exemplary flow diagram of an embodiment of the Performing Provider routine. Figure 23 is an exemplary flow diagram of an embodiment of the Hospital routine.

Figure 24 is an exemplary flow diagram of an embodiment of the Adjudication routine. Figure 25 is an exemplary flow diagram of an embodiment of the Paylist

Routine.

DETAILED DESCRIPTION OF THE INVENTION

An embodiment of the present invention provides a method and system for guiding medical service providers ("providers^") in making referrals and in selecting services to be provided that are automatically authorized for specified payments. In particular, the Electronic Managed Care Commerce (EMCC) system creates and shares electronic patient claim records (PCRs) that are transferred between providers and other users, and that are automatically paid when they are either automatically or manually authorized. Since referrals and services can be automatically authorized for guaranteed payment, uncertainty of providers about reimbursement and under-payments can be reduced and the need of insurance plans and/or UM groups to review many claims can be eliminated. In one embodiment, the EMCC system consists of an EMCC Server computer which stores a variety of information centrally and coordinates activity between a variety of different EMCC client computers or terminals at various locations. When a person first seeks care from a provider {e.g.. their primary care provider), a user at that location uses an EMCC Gatekeeper module to initiate the provision of medical care to the person. The Gatekeeper module acts as an entry point into the EMCC system by guiding the user through specifying various information that will ultimately create a referral to a provider for specified types of treatment. For each specification to be made by the user, the Gatekeeper module uses past user specifications and other available information to provide a context for displaying only relevant information, including indicating available choices for which the resulting referral can be automatically authorized for payment by the EMCC system. The Gatekeeper module begins a referral by creating an electronic patient claim record (PCR) for the patient. The PCR represents the current encounter as well as any subsequent referral and services, storing information related to the encounter such as information specifications made by the user. The Gatekeeper module assists the user in determining patient eligibility and in displaying patient medical history, including indicating any referral history and past encounters related to the present visit. For example, to assist in determining patient eligibility, the Gatekeeper module can retrieve from the EMCC Server a list of insurance plan members who are eligible for medical treatment. This list could include any member of which the EMCC system was aware, or only those members relevant to the current provider (e.g., for a solo practitioner, only those patients for whom she is their primary care provider). After the member information for the patient is selected by the user, the Gatekeeper module can similarly assist in displaying patient medical history by retrieving other PCRs for this patient. The retrieved PCRs could include all PCRs for the patient, or only those PCRs which have previously been designated as being related to the current PCR through the creation of an association between them (e.g., if the current PCR represents the continuing treatment of a previously treated problem).

The Gatekeeper module next assists the user in specifying the referring and performing providers for the referral. While the referring provider will often be the primary care provider for the patient, other providers (e.g., a nurse practitioner or a hospital) may also be authorized to make a referral depending on the insurance plan, the patient, and the past treatment. A variety of providers can similarly be specified as the performing provider. For example, a patient may be referred to a specialist provider, or a primary care provider may specify a self-referral in which the primary care provider is both the referring and performing provider. As mentioned, when the user is to specify information such as the referring or performing providers, the Gatekeeper module will indicate the possible choices that can be automatically authorized by the EMCC system. In one embodiment, the context of past user specifications will be used to determine the list of authorizable choices for the current specification. For example, when a patient first sees their primary care provider for an infection, the only authorized referral and services may be for that provider to prescribe antibiotics. However, if this treatment is not effective, the context of this past treatment selection may allow a later referral to a specialist to be automatically authorizable. Similarly, when the head of a medical department is acting as a referring provider, he may have a wider range of performing providers to which referrals can be automatically authorized than would the average primary care provider.

After specifying referring and performing providers, the Gatekeeper module assists the user in specifying a referral basis that indicates the type of patient problem (e.g.. a suspected heart valve disorder), a type of facility for treatment (e.g., a physician's office), a suggested type of treatment by the performing provider (e.g., evaluate and treat, or only perform lab tests), and an urgency of treatment (e.g., emergency). The Gatekeeper module also can assign an appropriate referral review level (e.g., a Utilization Review nurse) if manual review is needed, and can identify patient-specific risk factors related to the specified referral basis and suggested type of treatment (e.g.. patient^'s smoking may be related to heart problems). After all of the specifications have been made, the Gatekeeper module will notify the EMCC Server to make the electronic PCR available to the appropriate provider or other user. Those skilled in the art will appreciate that while the Gatekeeper module is often used by a primary care provider during an initial consultation with a patient, it can also be used by other providers at other times (e.g.. a specialist performing provider who receives a referral which authorizes one type of service may perform a self-referral to authorize additional types of service).

If the user of the Gatekeeper module selects only choices indicated to be automatically authorizable. then the EMCC system automatically authorizes the referral and the PCR is immediately sent to the selected performing provider. However, if the user instead made one or more selections which could not be automatically authorized, the PCR is sent to one or more users at the specified review level for the PCR (e.g., to one or more Utilization Review nurses) for manual authorization. A user such as a Utilization Review (UR) nurse will use an EMCC Authorization module to receive and review such PCRs. The Authorization module can display the information in the PCR and retrieve additional related information from the EMCC Server (e.g.. patient medical history or performance data for the referring provider). The Authorization module user can then manually authorize the referral, either as-is or as modified by the user. Alternately, the PCR can be transferred to a user at a higher review level for authorization. Upon manual authorization, the PCR is forwarded to the selected performing provider by the EMCC Server. This manual authorization process can be completed in a matter of minutes, with the authorization received while the patient is still at the provider's location.

When the patient seeks medical care at the performing provider, a user at that location uses an EMCC Performing Provider (PP) module to display the electronic PCR for the person. The availability of the PCR indicates that the referral to the performing provider has been authorized, either automatically by a Gatekeeper module or manually by an Authorization module. If the Gatekeeper module is used to make a self-referral where the current provider is both the referring and performing provider, then the user at that location can merely switch from the Gatekeeper module to the PP module and continue the encounter.

The PP module assists a user in viewing information from the PCR for the patient, and can retrieve and display related information from the EMCC Server such as patient medical history or patient demographic information. The PP module then assists the user in specifying one or more diagnosis codes related to medical problems of the patient, and one or more service codes related to services provided to the patient by the performing provider. As each specification is made, the information is stored in the PCR. As with the Gatekeeper module, the PP module indicates choices for the diagnosis and service codes that can be automatically authorized by the EMCC system. In one embodiment, the context of past specifications, including specifications from any referrals leading to treatment, will be used to determine the list of authorizable choices for the current selection. If the user of the PP module selects only choices which the EMCC system can automatically authorize, then the services are automatical!}' authorized. If so. the PP module determines the payment that will be received for the authorized services, and the PCR is sent to a Pavlist module for immediate payment.

The EMCC system can also support specialized modules. For example, while hospitals are one type of performing provider, the EMCC system can have an EMCC Hospital module which is unique from the PP module. When the patient seeks medical care at the hospital, a user at that location uses a Hospital module to display the electronic PCR for the person. In addition to the functions performed by the PP module, the Hospital module can assist the user in performing hospital-specific activities such as admitting and discharging the patient and recording journal entries for the period during which the patient is admitted. If the hospital provides only services which the Hospital module can automatically authorize, then these services are automatically authorized, the payment that will be received is automatically determined, and the PCR is sent to the Paylist module for immediate payment.

If the user of a PP or Hospital module specifies choices which cannot be automatically authorized, then the PCR is sent to one or more users for manual adjudication of whether payment will be supplied. As with Authorization modules, various review levels can be specified for manual adjudication. An adjudication user will use an EMCC Adjudication module to receive and review such PCRs. The Adjudication module can display the information in the PCR and retrieve additional related information from the EMCC Server. A user can then use the Adjudication module to manually authorize a specified amount of payment for specific services. Upon manual authorization of payment, the PCR is forwarded to the Paylist module for immediate payment. As with the Authorization module, manual authorization from the Adjudication module can be received in a matter of minutes. When the Paylist module receives a PCR authorized for a specified payment, the Paylist module can make immediate payment to the appropriate provider (e.g., electronically wiring funds or debiting a provider account maintained by the EMCC system).

In one embodiment, all users of the EMCC system are in constant two- way computer communication, such as via a network or via terminals attached to a shared server. In this embodiment. PCRs and other messages can be forwarded to users in a variety of ways, such as via messages sent to and stored on local computers or as information stored on the EMCC Server for retrieval by the appropriate EMCC module. In another embodiment, some users are contactable in a variety of other ways such as by one-way or two-way pager, cellular phone, voice mail. etc. The system tracks the status of various users, and a Remote Distribution (RD) module can be used by the EMCC system to receive a PCR or other information and to forward the information to such users in the manner appropriate for that user. For example, if a destination user has access to a computer connection, a PCR can be forwarded to the user as an object or as email. In this situation, the appropriate EMCC module for the user will display the PCR information to the user. Alternately, if the user has a communication device such as a pager or a phone, the RD module can convert the information from the PCR into an appropriate alphanumeric or spoken format so that the user can receive the information on their communication device.

Thus, the EMCC system provides a variety of advantages over prior systems. Since the EMCC system guides providers through the process of specifying referrals and treatments that can be automatically authorized, the providers can promptly receive payment without the uncertainties and delays associated with prior systems. Conversely, the automatic approval of referrals and treatments performed by the EMCC system frees insurance plans and/or UM groups from manual review of claims and authorization requests. Since providers are guided through the process of treatments and making referrals, the EMCC system can provide point-of-care protocols and sophisticated disease management. In addition, combining together all information related to a patient, including demographic, medical history and medical treatment information, provides various advantages. The combination of all information together eliminates the need to do many types of audits which are needed to ensure consistency across various disparate data stores. Moreover, since information is electronically transferred, the EMCC system eliminates redundant specification of information which is time-consuming, annoying, and subject to input error. Finally, the EMCC system can provide instantaneous electronic notice to users interested in various types of information, such as all referrals from a particular provider or the providing of a particular type of service by any provider. Those skilled in the art will appreciate that these and analogous EMCC modules can be used by any type of provider, including solo practitioner doctors, groups of doctors working together, managed care organizations, hospitals, clinics, laboratories, pharmacies, alternative medical care providers, rehabilitation centers, etc. In addition, those skilled in the art will appreciate that some embodiments of the EMCC system can be used to pre-authorize referrals and services before the referral is made or the service is performed, while other embodiments may only allow the automatic authorization to be determined after the referral is made or the service is performed. Referring now to Figure 1, an embodiment of the EMCC system 100 is described. The EMCC system includes an EMCC Server 110 which coordinates the activities of various EMCC modules and which facilitates the transfer of electronic PCRs and other information between these modules. When a person first seeks care, they will typically go to their primary care provider. The primary care provider will use a Gatekeeper module 105 to determine eligibility of the patient and to review the medical history of the patient. The Gatekeeper module will then be used to refer the patient to an authorized performing provider who will perform medical services, with the referral indicating the types of services which are authorized to be performed.

If a referral to a hospital for admission is authorized, the Gatekeeper module and/or the EMCC Server will transmit the corresponding electronic PCR to a Hospital module 125. If an authorized referral is not for a hospital admission, the Gatekeeper and/or the EMCC Server will instead transmit the electronic PCR to a Performing Provider (PP) module 120 for the specified performing provider. However, if the user of the Gatekeeper module specified a referral which could not be automatically authorized by the EMCC system, the Gatekeeper module and/or the EMCC Server instead transmit the electronic PCR as a request for authorization to an Authorization module 115 of a user at the appropriate review level. This review user can then promptly authorize, modify, or deny the referral and forward an authorized electronic PCR to the appropriate PP or Hospital module for the performing provider. When the patient seeks care at the specified performing provider, it is not necessary to re-enter patient information or re-verify patient eligibility since the electronic PCR contains this information. Instead, the referral information in the PCR can be used by the PP or Hospital module to guide the performing provider through the process of specifying diagnosis and service codes which are authorized for specified payments. After services are provided or a patient is discharged, the PP or Hospital module and/or the EMCC Server transmit the authorized updated electronic PCR to the Paylist module 135 to initiate payment.

Alternately, if a performing provider chooses diagnosis or service codes which cannot be automatically authorized, the PP or Hospital module and/or EMCC Server transmit the electronic PCR as a request for payment to the Adjudication module 130 for manual authorization, modification, or denial of payment for the services. After the electronic PCR is updated with a manually authorized payment amount, the PCR is then forwarded to the Paylist module. When the Paylist module receives an electronic PCR that is authorized for a specified payment amount, the electronic PCR is automatically processed and payment is immediately forwarded (electronically or otherwise) to the appropriate performing and referring providers.

As an illustrative example, consider the case of a person named Paul Anderson seeking medical care from his primary care provider. Dr. Ted Smith. When Mr. Anderson initiates a visit to Dr. Smith^'s office, a user at the office invokes a Gatekeeper module to record the encounter and guide the initial consultation. The user can access the Gatekeeper module in a variety of ways. For example, the Gatekeeper module could be executed on a local computer at the user's location or on a central EMCC Server. If the Gatekeeper module executes on a local computer, it can retrieve information from an EMCC Server via a network or modem connection or it can retrieve information that is stored locally on the local computer. Alternately, the Gatekeeper module can execute on the EMCC Server, and the user can access the module via a local computer or a thin client such as an EMCC terminal. Either standard connection mechanisms (e.g., a web browser or telnet application) or custom EMCC connection mechanisms can be used. For the purposes of the illustrative example, the details of the Gatekeeper module execution are not significant.

Referring now to Figure 2. an example of a Gatekeeper user interface (UI) screen 200 is displayed. When the user first begins the session with the Gatekeeper module, they are presented with a list of pending PCRs that have been created but not completed. As shown in Figure 2, each of the PCRs has a unique PCR identifier, and the current display shows the name of the insurance plan and the member identifier for the patient, the date that the PCR was created, an urgency level indicating how quickly care must be provided, and a review level indicating the appropriate types of people to review the referral and services represented by the PCR. These PCRs (and other information) can be retrieved by the Gatekeeper module in a variety of ways. For example, the relevant PCRs for this user^'s location could be stored on a local computer, or all PCRs could instead be stored on a central EMCC Server and retrieved by EMCC modules as needed. In the illustrative example, all PCRs are stored on a central EMCC Server. If a PCR already existed for this encounter, the PCR would be displayed as pending and the user could select the PCR. For example, the user might have partially created the PCR and then switched to another task before returning to the Gatekeeper module to complete the PCR.

Since the visit by Mr. Anderson is a beginning of a new encounter and thus has no pending PCR, the user of the Gatekeeper module instead selects the Create New Patient Claim Request button on the screen After selecting this action. UI screen 300 is displayed to the user as shown in Figure 3. As indicated, the user has now entered the Create/Edit Patient Claim Records portion of the UI. with the first of eight actions related to creating a new PCR being to identify the insurance plan member information for the patient. As part of creating a new PCR. the EMCC system automatically assigns a unique identifier for the new PCR and the current date is inserted in the PCR. A list of possible members is presented to the user, and the user scrolls or searches through the list until the entry for Paul Anderson is located. This entry indicates Mr. Anderson's insurance plan, plan member ID. primary care provider, and the provider code for the primary care provider. In the current default mode, the Gatekeeper module displays only that information which is appropriate under the current circumstances. For example, if the only two doctors at this office are Ted Smith and Jan Wu. only insurance plan member information for members which have one of these doctors as their primary care provider will be listed, rather than listing all members of all possible insurance plans. If a member listing for Paul Anderson cannot be located in the default view, the user can select the Show All button to see the member listing for all known insurance plan members. Alternately, the user could manually specify the patient information and attempt to verify eligibility. In addition, the user can at any time select the Cancel button to abort the current transaction and discard the information that has been previously entered, or can save the information that has been currently entered for later use by selecting the Make Pending button. Since the member listing for Mr. Anderson is displayed, the user selects the displayed entry and then selects the View Eligibility/Information button to see additional information. Referring now to UI screen 400 shown in Figure 4, this screen shows patient eligibility and other information for Mr. Anderson. A variety of patient information can be displayed, including information about when the eligibility of the patient as a member of the insurance plan was last automatically verified. When the user is finished reviewing the information on the screen, the user selects the Done button to return to screen 300. and then with the entry for Mr. Anderson selected the user selects the Done button on that screen to continue with the PCR creation. If information displayed on UI screen 400 had required further investigation, additional information could have been retrieved from the EMCC Server using other EMCC system functionality (not shown). After selecting the entry for Mr. Anderson, the Gatekeeper module continues to UI screen 500, shown on Figure 5. Note that the patient name and member ID were added to the PCR after the member entry was selected on UI screen 400. with a PCR-specific suffix added to the base member ID. Screen 500 allows the user to specify a referral history for the current PCR if there have been previous encounters related to the current encounter. Various other PCRs for the current patient are displayed in the referral history screen, with information displayed indicating the problems to which the PCRs relate. The two PCRs shown indicate that Mr. Anderson was treated for circulation problems approximately three months ago, and that three days ago he was treated for heart problems. Since the current encounter is related to continuing heart problems, PCR 000151 from three days ago is related history for the current PCR. Thus, the user selects the 000151 PCR and then selects the Associate button so that the two PCRs are associated as being related. When the user is finished, they select the Done button to continue to the next screen.

After the user has specified the referral history for the current PCR, the Gatekeeper module continues to UI screen 600 shown on Figure 6 to display a list of providers. The providers displayed are those which the EMCC system can automatically authorize to make referrals for this patient based on the insurance plan and the past treatment history from associated PCRs. For example, when a patient first seeks treatment, it is possible that only a doctor may be authorized to refer the patient for additional treatment. However, after previous treatment by a doctor and continuing patient problems, a nurse practitioner may then be authorized to make a referral for later visit. The determination of the providers who can be automatically authorized by the EMCC system can be performed in a variety of ways. For example, different combinations of insurance plans and patients may have unique lists of providers that were previously specified as authorized to make referrals. Alternately, the EMCC system may be able to calculate which providers are authorized in a given situation, considering factors such as insurance plan contract details, past treatments, etc.

Typically, the primary care provider for a patient will be the referring provider. In this situation, however, Dr. Smith is unavailable and Dr. Hilter is seeing his patients. Thus, Dr. Sally Hilter is selected as the referring provider. If the user wished to view additional information about a displayed provider, this could be accomplished by using the View Additional Information button with the entry for that provider selected. Although UI screen 600 initially displays only those providers who can be automatically authorized to make a referral, it is also possible for the user of the Gatekeeper module to choose another provider. If the user selects the Show All button to see all possible providers and then chooses someone other than one of the three automatically authorizable choices, the referral process will continue but there is no guarantee that the resulting referral will later be authorized and compensated. After selecting the entry for Dr. Hilter. the user selects the Done button to continue to the next screen.

After the referring provider is selected, the Gatekeeper module continues to UI screen 700 shown in Figure 7. UI screen 700 displays the list of providers who can be automatically authorized to receive the referral from Dr. Hilter to treat Mr. Anderson by performing one or more medical services. If the user would like to return to UI screen 600, the user can select the Previous Screen button shown. If so, the Gatekeeper module would return to UI screen 600 with the entry for Dr. Hilter selected since she is currently specified as the referring provider. As with the list of referring providers on screen 600, the current list of performing providers are determined based on the previous selections made, such as insurance plan, member, referral history and referring provider. Since the past medical treatment indicated by the associated PCR was related to heart problems, many of the performing providers who can be automatically authorized for the current referral may be cardiologists. Note also that a self-referral is allowed at the current time. Thus, if the initial consultation by Dr. Hilter had indicated that additional treatment of a general nature by herself was a preferred course of action, a self-referral could be used to automatically authorize an extended course of treatment. In this situation, however, Mr. Anderson's continuing heart problems are best treated by a cardiologist, so the user of the Gatekeeper module selects Dr. Roberto Mendez as the performing provider and continues to the next screen.

The Gatekeeper module continues to UI screen 800 shown on Figure 8. This screen allows the user to identify one or more referral bases for referring the patient to the performing provider. As with previous screens, the referral bases listed can be automatically authorized based on the combination of previous selections made, including the performing provider. These referral bases describe patient problems at a high level, such as a problem with a major bodily system. While Dr. Hilter does not have the necessary cardiological expertise to make precise diagnoses, she suspects that Mr. Anderson may be having problems related to arrhythmia and/or a heart valve disorder. Thus, the user of the Gatekeeper module selects referral bases entries related to those problems and then selects the Done button to continue.

The Gatekeeper module then continues to UI screen 900 shown on Figure 9, where a list of types of facilities for the referral treatment are shown. These listed facilities can be automatically authorized based on the combination of previous selections made, and the user selects a physician^'s office as the appropriate facility type.

The user then continues to the next screen by selecting the Done button.

After selecting the type of facility, the Gatekeeper module continues to UI screen 1000 shown on Figure 10. This screen allows the user to specify one or more suggestions for types of referral treatments to be performed by the performing provider. As with the referral bases, the referral treatment type suggestions are often at a high level rather than a highly particularized service. In this case, Dr. Hilter believes that lab tests and diagnostic X-rays may be the best course of continued treatment. As before, the treatment type suggestions shown can be automatically authorized based on the previous selections made. After selecting the referral treatment type suggestions, the user selects the Done button to continue to the next screen.

The Gatekeeper module then continues to UI screen 1100 shown in Figure 11. UI screen 1100 allows the user to specify an urgency for the current referral. Since Mr. Anderson's continuing heart problems need immediate attention, but do not constitute an emergency, the user selects Urgent as the urgency for the referral. Note that the Gatekeeper module can automatically add information to the PCR. In the current example, the Gatekeeper module has determined based on the selections made that a UR review level should be assigned to this PCR, and automatically added this information. If manual review of the PCR is required, this review level will determine which users can manually authorize the referral. Even if the PCR can be automatically authorized, some users may desire notification that the referral was made. The review level can indicate any user in a specified group (e.g., UR nurses), or particular users (e.g., a case manager or department head). After making the selection, the user has completed the creation of the PCR. Those skilled in the art will appreciate that other types of information could also be specified for the referral.

The Gatekeeper module then continues to UI screen 1200 shown in Figure 12. This screen provides a summary of the information in the current PCR. After reviewing the displayed information, the user must select an action to be taken with the PCR. As previously indicated, the user can return the PCR to the current list of pending PCRs by selecting the Make Pending button. Alternately, the user can decline to make the referral and can select the Delete button to remove the PCR. If the user wishes to continue the referral, however, the user will select one of the two Submit buttons.

If the user wishes to create additional PCRs for this patient, the user will select the Submit And Create Additional Patient Claim Record For Current Patient button. For example, while Mr. Anderson^'s primary motivation for visiting Dr. Hilter may be his continuing heart problems, Mr. Anderson may also have an unrelated medical condition such as a cut on his leg. If so, the EMCC system can create a new PCR containing the appropriate patient information, and then return the user to UI screen 500 with the new PCR. This removes the need to re-specify patient information and re-verify patient eligibility. If the user instead wishes to submit this referral and return to UI screen 200. the user will select the Submit button. When the user selects either Submit button, the PCR will be forwarded to the appropriate recipients. If the user has specified a referral that can be automatically authorized, the EMCC system authorizes the referral and transmits the PCR to the performing provider Dr. Mendez. However, if the referral could not be automatically authorized, the PCR is instead transmitted to one or more users at the appropriate review level for manual authorization or denial of the requested referral.

Since the referral is automatically authorized, the PCR is transmitted to Dr. Mendez. When the patient arrives at Dr. Mendez' s office, a user at that office uses a Performing Provider (PP) module to process the referral. The user will first view a UI screen, similar to UI screen 200. to display the pending PCRs for Dr. Mendez. When the user selects the PCR for Mr. Anderson that was electronicallv transmitted to the PP module, the PP module then continues to UI screen 1300 shown in Figure 13. This screen displays ICD-9 diagnosis codes for Mr. Anderson that can be automatically authorized by the EMCC system based on the referral. If the user selects one or more of the displayed diagnosis codes and Dr. Mendez then performs a corresponding service that can also be automatically authorized, Dr. Mendez will be guaranteed to receive payment for the service. After examining Mr. Anderson, Dr. Mendez diagnoses that Mr. Anderson suffers from pulmonary heart disease and may have a congenital heart anomaly. The user of the PP module selects diagnosis codes related to these diagnoses, and selects the Done button to continue. The PP module continues to UI screen 1400. shown on Figure 14, to display CPT service codes for services that Dr. Mendez can perform, with the displayed codes being only those which can be automatically authorized based on the referral and the selected diagnosis codes. After the user selects an entry for an extended office visit, the user selects the Done button to continue to the next screen. The PP module then continues to UI screen 1500. shown in Figure 15.

This screen allows the PP module user to review the updated PCR for Mr. Anderson. If the diagnosis and provision of services is complete at this time, the user can select the Submit button to submit the PCR for payment. Alternately, the user can select the Make Pending button if further treatment will occur or if the user wishes to review the selected diagnosis and service codes at a later time.

If the PCR can be automatically authorized for payment, the EMCC system authorizes the services and the PCR is forwarded to a Paylist module for immediate payment. Alternately, if the user has selected diagnosis or service codes which cannot be automatically authorized, the PCR is forwarded to one or more users for manual adjudication of whether the services will be compensated, and if so. at what amount. Since Mr. Anderson^'s claim could be automatically authorized, even before the PCR is submitted the PP module can determine and display the amount of payment that will be received by Dr. Mendez.

In this manner, the Gatekeeper and PP modules can guide providers through the process of referring and treating patients in such a way that the treatments and referrals can be automatically authorized and are immediately reimbursable at a specified payment amount. The EMCC system thus greatly reduces the need for manual review of patient treatment and referral claims.

Figure 16 shows an exemplar}' embodiment of an EMCC system consisting of an EMCC Server 1600 communicating with a variety of EMCC clients 1650, 1660, and 1670 via a communication means such as a network 1655. In the exemplary embodiment, all EMCC modules execute on the EMCC Server, with the EMCC clients receiving information to be displayed to the user and returning user input information. Those skilled in the art will appreciate that multiple copies of a module may be executing at the same time on the EMCC Server, or that multiple clients may share a single executing copy of a module. Those skilled in the art will also appreciate that the EMCC clients could be mere display terminals connected to a server computer, or instead could be computers that execute EMCC modules and store EMCC information locally. Each EMCC client has an EMCC interface that allows the client to invoke one or more EMCC modules on the EMCC Server. The EMCC modules include a Gatekeeper module 1631, a PP module 1632, a Hospital module 1633, an Authorization module 1634, an Adjudication module 1635. a Remote Distribution module 1636. and a Paylist module 1637. The modules perform the functions described in reference to Figure 1, with the Remote Distribution module facilitating the transfer of information between the other modules. The EMCC Server also includes a CPU 1610, a memory 1630. and input/output devices 1620 including a network connection 1622, a computer-readable media drive 1623 and a display 1624.

The EMCC modules are loaded into memory and execute on the CPU. While executing, the modules retrieve and process a variety of information. In the exemplary embodiment, a storage device 1640 serves as a central repository for storing a variety of medical information. Medical information 1680 includes information which will typically be retrieved from sources outside the EMCC system (e.g., insurance plan computers), either before or during execution of the EMCC modules. Medical information 1680 includes reference information 1681 (e.g., ICD-9 diagnosis codes and CPT service codes), information about providers 1682 (e.g.. specialties, affiliations and previous disciplinary measures) and facilities 1685, and information about insurance plans such as contractually covered benefits and terms 1683 and members 1684. The storage device also stores medical information created by or entered into the EMCC system, such as PCRs 1641 and patient medical histories 1642.

In addition to medical information, storage device 1640 stores EMCC- specific system information 1690 which is used by the EMCC system to create PCRs and to automatically authorize referrals and services. The EMCC-specific system information includes information created to allow the EMCC modules to categorize patients and users (i.e., patient risk factors 1692 and review levels 1693). to distribute information to users (i.e., user distribution information 1694). and to identify referrals and services which can be automatically authorized (i.e., referral bases 1695. referral treatment suggestion types 1696, referral urgency levels 1697. and EMCC mapping information 1699). In the exemplary embodiment, the referral bases are general reasons for a referral described in a medical provider's vernacular, such as problems related to one of the major bodily systems. Since a provider at an initial consultation will often not have the time or expertise to make a precise diagnosis, the referral bases provide a general description that may encompass many varied diagnosis codes. Similarly, the referral treatment suggestion types are general directions to a performing provider, at a level appropriate for a referring provider that has not made a specific diagnosis. Typically, multiple service codes can be authorized for a single choice for a referring provider, a performing provider, a referral basis, a referral treatment suggestion type, and a referral urgency level. The EMCC mapping information allows the EMCC system to determine choices for a type of information (e.g., a performing provider) such that a resulting referral using the choice can be automatically authorized for payment based on previously specified information [e.g., insurance plan member information, past related treatments, or the referring provider). Those skilled in the art will appreciate that the EMCC mapping information can be provided in a variety of formats, including having a list of pre-specified choices for each type of information and for each combination of choices for previous selections.

The user distribution information can be used by the Remote Distribution module to forward information to the correct users with the correct format. For example, the user distribution information may keep tracks of all UR nurses so that manual authorization of a PCR by a UR nurse is limited to the appropriate individuals. Alternately, the user distribution information may track that a particular user is to receive PCR information and other messages via a specified pager number.

In the exemplar}- embodiment, the EMCC modules executing on the EMCC Server receive input information from EMCC clients, retrieve information from the various information stores on the storage device, store information that is input by users in the PCRs, and use remote distribution information to contact specific users or to notify other EMCC modules that information is available. The workings of the various EMCC modules will be described in greater detail in relation to Figures 17 through 25. Those skilled in the art will appreciate that the EMCC Server and the EMCC clients are merely illustrative and are not intended to limit the scope of the present invention. Other embodiments may contain additional components or may lack some illustrated components, and the present invention may accordingly be practiced with other computer system configurations. Figures 17A and 17B are flow diagrams of an embodiment of the

Gatekeeper routine 1700. The Gatekeeper routine enables a provider to make a medical referral for a patient that is automatically authorized. The Gatekeeper routine is executed upon a provider^'s initial encounter with a patient (e.g., at a primary care provider^'s office), and can also be executed at a later point during an encounter in order to create additional referrals. The routine selects a new or existing PCR, and then if necessary it identifies insurance plan member information for the patient, verifies patient eligibility, and associates the PCR with other related PCRs. The routine then specifies referral information including a referring and performing provider, a referral basis, a type of facility for the referral, a referral treatment type suggestion, and an urgency of treatment, and determines a review level and patient risk factors for the referral.

The routine begins at step 1705 by retrieving from the EMCC Server all pending PCRs that are queued for this Gatekeeper routine. In the exemplary embodiment, all PCRs are stored at the EMCC Server. Thus, each Gatekeeper routine could have a separate queue holding pending PCRs for that routine, or all PCRs could be stored together and could contain information identifying the routine with which the PCR is currently associated. After retrieving the PCRs. the routine displays the records to the user of the routine, and receives in step 1710 a user selection to either create a new PCR or to edit an existing PCR. The routine continues to step 1715 to determine if the selection was to create a new PCR. If not. the routine continues to step 1740 to retrieve the existing PCR that was indicated.

If the selection was to create a new PCR, the routine continues to step 1720 to receive a user indication of the insurance plan for which the patient is a member. In the exemplary embodiment, the routine retrieves insurance plan member information from the EMCC Server and displays possible members to the user. The list of members may be limited to only those members for whom the provider is their primary care provider, or may include all possible members. If an entry for the patient is displayed, the user of the routine can select the displayed member entry in step 1720. Alternately, the user can attempt to locate insurance plan information for the patient by expanding the list of displayed members (e.g., to all possible members), or by manual overriding the EMCC system and specifying insurance plan information.

After an insurance plan member selection is made in step 1720, the routine continues to step 1725 to verify eligibility of the patient. In the exemplary embodiment, only eligible patients are displayed in the initial list of member information displayed to the user. Thus, it may not be necessary to verify patient eligibility if a selection was made from the initial list, although the user of the Gatekeeper routine may still wish to determine information such as when eligibility of the patient was last verified by the insurance plan. After verifying patient eligibility, the routine checks in step 1730 whether the patient was verified to be eligible. If the patient is not eligible, and thus authorization for any treatments or referrals cannot be obtained, the routine returns to step 1705.

If the patient is determined to be eligible in step 1730. however, the routine continues to step 1735 where a new blank PCR is created to hold information for the current encounter. The routine can automatically add information to the PCR such as a unique PCR identifier and the current date. In the exemplary embodiment, the PCR is given a status which is initially set to "Authorized" and which can be modified by the various EMCC modules. In addition, in the exemplar." embodiment once the PCR is created it will always be associated with one of the EMCC modules. When the PCR is not currently in use by its associated module, it will be considered to be in a queue for that module whether the PCR is actually stored on the EMCC Server or on a local computer and whether the PCRs associated with a particular module are actually stored apart from the PCRs from other modules.

After step 1740 or step 1735. the routine continues to step 1745 to optionally associate the current PCR with other previously created PCRs. Two or more PCRs can be associated when they are related based on the patient's reasons for seeking treatment and the treatment received. For example, if a patient is having continuing heart problems then the PCRs for past encounters related to treating these heart problems would be associated with a current PCR for the same problem. In the exemplary embodiment, a patient can automatically specify that a series of successively created PCRs be associated together, or a list of previously created PCRs can be displayed and the user can select one or more displayed PCRs to associate with the current PCR. The routine then specifies information for the referral by executing subroutine 1750. This referral information will include a referring provider, a performing provider, a referral basis, a type of facility, a referral treatment type suggestion, and an urgency of treatment. Each specification will include presenting the user with choices for which the resulting referral can be automatically authorized based on the previous specifications.

As with the list of members, the user can choose to manually override the EMCC system and specify a referral information choice that cannot be automatically authorized. If so. the current status of the PCR will be set to be "Unauthorized.^" In the exemplar}' embodiment, after a PCR selection is manually overridden the EMCC system no longer tries to limit choices for later selections to those which can be automatically authorized. Instead, all possible choices are listed for these later selections, and authorization for the resulting referral will need to be manually specified after the referral creation is complete.

After the referral information is supplied, the routine continues to step 1760 to determine if the user wishes to submit the claim and thus send the PCR to the next appropriate EMCC module. If the user does not wish to submit the PCR. the routine continues to step 1762 where the status of the PCR is reset to ensure that it is not "Unauthorized." As mentioned above, the PCR status may have become "Unauthorized^" based on selections made when executing subroutine 1750 and step 1720. Since the PCR is not going to be submitted, it will become a pending PCR that will be retrieved the next time step 1705 is executed. When the PCR is later selected as a pending PCR. the user will have the option of modifying the selections so that the

PCR can be automatically authorized. If the manually overriden selections are not appropriately modified, the status of the PCR will return to "Unauthorized" at that time.

After resetting the PCR status in step 1762, the routine continues to step

1764 to invoke the Remote Distribution subroutine and thus place the PCR in the appropriate pending module queue or transmitting it to the appropriate users. Those skilled in the art will appreciate that the Remote Distribution subroutine could send the PCR between routines in a variety of ways. For example, if all PCRs are stored together on the EMCC Server, it may only be necessary to change the PCR association so that another routine becomes currently associated with that PCR. Alternately, a PCR could be electronically transmitted to another routine as a message or an object, or a message could be transmitted to the other routine to indicate that the PCR is stored at a specified location.

If the user instead determines in step 1760 to submit the PCR. the routine continues to step 1765 to determine if the PCR status is "Unauthorized." If so, the routine continues to step 1770 to invoke the Remote Distribution subroutine to send the PCR to an Authorization module for manual authorization. If the PCR status is not "Unauthorized.^" however, the PCR can be automatically authorized and so the routine instead continues to step 1775 to invoke the Remote Distribution subroutine to send the PCR to the PP module for the indicated performing provider. After step 1770 or 1775, the routine continues to step 1780 to invoke the Remote Distribution subroutine to optionally send the PCR to any users interested in the PCR. For example, a case manager may wish to review all referrals made by a particular provider, even if the referrals are automatically authorized, or may instead wish to review all referrals for a certain type of referral basis regardless of the referring provider. After step 1780 or 1764, the routine continues to step 1786 to determine if additional PCRs for this patient should be created. If not, the routine returns to step 1705, and if so the routine continues to step 1788 where a new blank PCR is created for the patient with the referring provider and patient information specified. After step 1788, the routine returns to step 1750 to designate the appropriate referral information. Those skilled in the art will appreciate that the same functions can be accomplished with a variety of modifications to the routine, such as including multiple referrals within a single PCR or associating a PCR with PCRs for other members.

Figure 18 is a flow diagram of an embodiment of the Designate Referral Information subroutine 1750. The subroutine receives a PCR which has insurance plan member information specified and optionally other PCRs associated, and allows the user to specify a referring provider, a performing provider, a referral basis, a type of facility, a referral treatment type suggestion, and an urgency of treatment level. The subroutine also determines patient risk factors and a manual review level for the PCR. The subroutine begins in step 1805 where a PCR is received. The subroutine then continues to step 1815 to compile a history of past treatments related to the current referral based on the current PCR and its associated PCRs.

After retrieving and processing this previously specified information, the subroutine then specifies the referral information. The subroutine continues to step 1825 where the referring provider who will make the referral is selected by invoking the Select An Instance Of Specified Type Of Information Based On Specified Context Of Past Selections subroutine 1900. Subroutine 1900 will be invoked with the specified type of information to be selected being a referring provider and with the specified context of past selections being the selections previously made for this PCR (i.e., the insurance plan member information and any past related treatments from associated PCRs). Execution of subroutine 1900 will present the user with a list of choices, with any of the choices such that the EMCC system can automatically authorize the choice as the referring provider for the referral. These authorizable choices will vary based on the context of past selections. As with the insurance plan member information, the user can choose to manually override the list of authorizable choices and specify a choice which is not automatically authorizable. If so. the status of the PCR will be set to "Unauthorized.^"

After selecting a refeπing provider in step 1825, the subroutine continues to step 1835 where the performing provider who will receive the referral is selected by invoking subroutine 1900. Subroutine 1900 will be invoked similarly in step 1835 to that of step 1825, with the specified type of information to be selected being a performing provider and with the specified context of past selections again being the selections previously made for this PCR (i.e., the insurance plan member information, any past related treatments from associated PCRs, and the referring provider). Execution of subroutine 1900 will allow the user to specify a performing provider by selecting an automatically authorizable choice based on past selections, or by manually overriding the system and specifying an alternate choice. The subroutine then continues to step 1840 to similarly select a referral basis which indicates why the referral was made. This is accomplished by invoking subroutine 1900, with the specified context of past selections including the same factors as before with the addition of the selected performing provider. After step 1840, the subroutine continues to step 1845 to similarly select a type of facility for the referral based on past selections including the performing provider, and to step 1850 to similarly select a referral treatment type suggestion based on past selections including the type of facility. While the illustrated routine allows only a single performing provider, referral basis, type of facility and referral treatment type suggestion for each PCR, those skilled in the art will appreciate that multiple choices for one or more of these types of information could be selected, with choices for subsequent types of referral information made either for each of the earlier choices or for the combination of earlier choices.

The subroutine then continues to step 1855 to allow the user to select an urgency of treatment level for the referral represented by the PCR. The urgency level can be used in a variety of ways, such as to prioritize PCRs in a list of pending PCRs or to prioritize transmission of a PCR or a related message. The subroutine then continues to step 1860 where patient risk factors associated with the current selections are determined and added to the PCR. In the exemplary embodiment, the user selects patient risk factors from a list appropriate for the referral basis and referral treatment type suggestion. Alternately, the EMCC system could automatically determine this information, such as by comparing the appropriate list to patient risk factors in a previously specified patient medical history. In step 1865, a manual review level is next determined for the PCR. This review level will determine which users are allowed to manually authorize a PCR with an "Unauthorized" status. In some embodiments, the review level can also be used to specify one or more users which are interested in receiving information about the current PCR, regardless of whether the corresponding referral is automatically authorized. The subroutine continues to step 1870 to add the urgency level, the determined risk factors and the manual review level to the PCR. In step 1875 the subroutine returns. Those skilled in the art will appreciate that some steps could be conducted in a different order, and that the steps could be performed in a variety of ways. For example, some embodiments may not determine a review level unless an unauthorized selection is made. Alternately, other embodiments may automatically determine an urgency level based on factors such as the specified referral basis, performing provider, type of facility, and referred treatment type suggestions.

Figure 19 is a flow diagram of an embodiment of the Select An Instance Of Specified Type Of Information Based On Specified Context Of Past Selection subroutine 1900. This subroutine is invoked multiple times, with each invocation including a type of information to be selected (e.g., a referring provider) and a context of past selections (e.g.. the insurance plan member selection and past related treatment from associated PCRs). The subroutine first determines appropriate choices for the specified type of information based on the specified context such that the EMCC system can automatically authorize a resulting referral which includes one of the choices. The subroutine then displays the choices to the user, allows the user to select a choice or manually specify an alternate choice, and adds the specified choice to the PCR.

The subroutine begins in step 1905 where a PCR and a history of related past treatment is received, along with a specified type of information to be selected and a specified context of past selections. Alternately, the subroutine could examine the PCR to retrieve the previously specified information and to determine the next type of information which needs to be selected. The subroutine then continues to step 1915 to identify choices for the specified type of information which can be automatically authorized based on the previous selections for the PCR. As described previously, the identification of these choices can be performed in a variety of ways, such as by pre- specifying authorized choices for a type of information based on various combinations of choices for types of previously specified information.

The subroutine then continues to step 1920 to determine if there is already a choice that was previously specified in the PCR for the current type of information, and if so, whether the choice remains satisfactory to the user. Such a choice may exist if a user makes a selection, continues to the next user selection, and then decides to return and review the previous selection. Alternately, during a previous execution of the Gatekeeper routine, the user may have made a selection for this type of referral information for this PCR. but chose not to submit the PCR. In that case, the PCR would join the list of pending PCRs for that routine, and when the PCR is later selected in step 1710 the routine may be re-executed with the PCR. Therefore, when subroutine 1900 is invoked with a PCR, the PCR may already have a selected choice for the specified type of referral information. Moreover, it is also possible that the status of whether the choice can be automatically authorized by the EMCC system has changed since the choice was first made. Since the subroutine is re-executed, however, the current status of the choice can be reflected. Thus, if a previous choice already exists, the choice and the current automatic authorization status of the choice is displayed to the user in step 1920. allowing the user to retain the choice or to select a different choice. If this previous choice cannot be automatically authorized at the current time and it is retained by the user, the status of the PCR will become ^'Unauthorized.^"

If it is determined in step 1920 that the PCR has a selected choice for the specified type of referral information that is satisfactory to the user, the subroutine continues to step 1940. If the PCR does not have a selected choice or if such a choice is not satisfactory, the subroutine allows the user to specify a new choice. If there are a large number of choices which can be automatically authorized, however, it can be useful for the subroutine to identify the most likely choices for the current selection. These likely choices can assist the user in selecting a choice, such as by using a likely choice as a default or by listing likely choices that can be automatically authorized before other choices that can be automatically authorized. Identifying likely choices can be performed in a variety of ways (e.g.. using a patient's primary care provider as a default for the referring provider selection). In the exemplary embodiment, the subroutine continues to step 1925 to determine the choices for the specified type of information in any associated PCRs so that these choices can be treated as likely choices. For example, if an associated PCR referred the patient to a particular performing provider, that same performing provider may be selected for the related current referral. After determining the choices that are selected in associated PCRs. the subroutine then continues to step 1930 to display the list of choices that can be automatically authorized, with the choices from associated PCRs listed first. In the illustrated embodiment, choices which can be automatically authorized are displayed differently than those which require a manual override of the EMCC system, such as by displaying the manual override choices as grayed out or in a different font. In addition, when a selection is made by the user, the selected choice is displayed differently than other choices, such as by highlighting or reverse-highlighting the choice. Thus, once the user selects a displayed choice, or if a choice was previously selected, the selected choice is identified in the display. Alternately, if the user wishes to specify a choice which cannot be automatically authorized, the user can type the choice or ask the system to display all choices instead of only those which can be automatically authorized.

Once a choice is selected, the user can indicate acceptance of the selection in step 1935. such as by selecting a Done button or pressing the Enter key. After step 1935. or if it was determined in step 1920 that a satisfactory selected value was available, the subroutine continues to step 1940 to determine if the selection made is authorized (i.e., is among those choices identified in step 1915). If not. the subroutine continues to step 1950 where the PCR status is set to 'Unauthorized.^' After step 1950. or if it determined in step 1940 that the selection was authorized, the subroutine continues to step 1960 to add the selected choice to the current PCR. The subroutine returns in step 1965. Those skilled in the art will appreciate that there are a variety f ways for displaying a group of choices in which some of the choices can be auto atical „. authorized and in which others cannot. Rather than displaying only the choices which can be automatically authorized, all choices could be initially displayed with the authorizable choices indicated. Alternately, a default could be selected for one or more types of information (e.g., the primary care provider at the location where the routine is being executed could be the default referring provider).

Figures 20A and 20B are flow diagrams of an embodiment of the Remote Distribution subroutine 2000. The subroutine receives a PCR and an indication of a destination to receive PCR information, and distributes the PCR or its information to the appropriate destination. The subroutine begins in step 2005 where it receives an indication of the PCR and of the destination for information distribution. The subroutine continues to step 2010 to create a message which includes the PCR information. This message can be created in a variety of forms, such as a textual listing of all PCR information or merely an indication of the unique PCR identifier that allows the recipient to access the indicated PCR. The subroutine then continues to step 2015 to check the indicated destination. If it is determined in step 2020 that the destination is the current Gatekeeper routine, the subroutine in step 2025 merely places the PCR in the queue for the Gatekeeper module of the referring provider. If it is instead determined in step 2030 that the destination is an Authorization module, the subroutine determines in step 2035 the appropriate users to review the PCR based on the PCR's review level, and in step 2040 sends a message to the Authorization modules for those users as well as placing the PCR in the queue for those modules. The subroutine may need to both send a message and to place the PCR in a queue because in the exemplary embodiment, some review users (e.g., a UR nurse) may have a networked computer executing an Authorization module to retrieve pending PCRs from the EMCC Server while other users (e.g., a doctor) may need to be contacted in other manners such as via a pager, cellular phone, or voicemail message. The subroutine will thus transmit the PCR information to the review users in the manner appropriate for the user to receive the information.

If it is instead determined in step 2045 that the destination is users who are interested in the PCR, the subroutine continues to step 2050 to determine the interested users. For example, determined users may have been specified when the Remote Distribution subroutine was invoked, or may be listed in the PCR. Alternately, users interested in certain types of information and PCRs may have previously logged this interest with the EMCC Server. After the interested users are determined, the subroutine continues to step 2055 to send the created message to the determined users. If the subroutine instead determines in step 2060 that the destination is the performing provider in the PCR and that the performing provider is a hospital, the subroutine continues to step 2070 to place the PCR in a queue for the Hospital module for the hospital performing provider. If the subroutine instead determines in step 2075 that the destination is a non-hospital performing provider, the subroutine continues to step 2077 to place the PCR in a queue for the PP module of the non-hospital performing provider.

If the subroutine instead determines in step 2080 that the destination is an Adjudication module, the subroutine continues to step 2082 to determine the appropriate users to review the payment request for the PCR. As with authorization users and interested users, the appropriate users for adjudication can be determined in a variety of ways. After determining the appropriate users, the subroutine continues to step 2084 to send the message to the users and to place the PCR in the queue for the determined users^" modules. If the subroutine instead determines in step 2086 that the destination is a Paylist module, the subroutine continues to step 2088 to place the PCR in the queue for the Paylist module. If the subroutine instead determines that the destination indicates those interested in the denial of authorization for a referral, the subroutine continues to step 2092 to send a message to the Gatekeeper module for the referring provider and to the PP module for the performing provider specified in the PCR, as well as to any other users interested in PCR authorization denials. If the destination does not match any of the previously specified destinations, or after steps 2025. 2040, 2055. 2070. 2077. 2084. 2088. or 2092. the subroutine returns in step 2094. Figure 21 is a flow diagram of an embodiment of the Authorization routine 2100. The Authorization routine allows a user to review PCR referrals which cannot be automatically authorized and to determine whether to authorize them. The routine either receives a PCR-related message or retrieves PCRs with pending authorization requests, displays the information from a PCR. and allows the user to determine whether to authorize, modify or deny the referral represented by the PCR. The routine begins at step 2105 where it is determined whether the Authorization routine has access to a network connection to an EMCC server. If not (e.g., a pager), the routine continues to step 2110 where it waits for a message ^;," iicating that a PCR is to be reviewed. After a message is received, the routine continue , to step 2115 to display PCR-related information stored in the message. After the user has reviewed the information, the user supplies a command that is received in step 2120. Those skilled in the art will appreciate that the Authorization routine can be executed on a variety of types of hardware including pagers, cellular phones, personal digital assistants, etc.. and that information will be sent to and displayed on these different types of hardware in the manner appropriate for that hardware. If the hardware did not allow a user response to the displayed information (e.g.. a one-way pager in which the user responds via a separate telephone), the routine could merely display the received information and skip the steps of receiving and responding to a user command.

If it was instead determined in step 2105 that a network connection existed to the EMCC Server, the routine continues to step 21 5 to retrieve all PCRs from the EMCC Server in the queue for this Authorization module. The routine then continues to step 2130 to receive a selection by the user of a displayed PCR. In response, the routine in step 2135 displays the information stored in the selected PCR, and continues to step 2140 to receive a command from the user. If it is determined in step 2145 that the user specified additional information to be displayed (e.g., information on past treatment history or on a provider), the routine continues to step 2150 to retrieve and display the requested information from the EMCC Server and then returns to step 2140. In the exemplary embodiment, hardware without a network connection to the EMCC Server is allowed to reply to a received PCR, but not to request additional information. Thus, if it is determined in step 2145 that the user command in step 2140 was not to get additional information, the routine continues to step 2155 to determine if the user command was to modify the requested referral. If so. the routine continues to step 2160 to receive information from the user indicating how to modify the PCR (e.g., change the referral treatment type suggestion) and then modifies the PCR as indicated. After step 2160. or if it is instead determined in step 2165 that the user command was to authorize the PCR, the routine continues to step 2170 to reset the PCR status so that it is not "Unauthorized." The routine then continues to step 2175 to invoke the Remote Distribution subroutine to send the PCR to the PP module for the performing provider. If it was not determined in step 2165 that the user command was to authorize the PCR, the routine instead continues to step 2180 to determine if the user command was to deny the authorization. If so. the routine continues to step 2185 to invoke the Remote Distribution subroutine to notify the referring and performing providers as well as any other users who are interested in the denial. If the user command was not to deny the authorization request, the routine continues to step 2190 to invoke the Remote Distribution subroutine to return the PCR to an Authorization module. For example, the user of this Authorization module may wish to defer a decision on this PCR until later, or to defer a decision to a different user at the same or a higher review level. After step 2175. 2185. or 2190. the routine returns to step 2105.

Figure 22 is a flow diagram of an embodiment of a Performing Provider (PP) routine 2200. The routine receives PCRs reflecting authorized referrals from either Gatekeeper or Authorization modules, guides a user through specifying diagnoses and services which can be automatically authorized, determines the payment to be received for automatically authorized services, forwards PCRs with automatically authorized services to a Paylist module for payment of the determined payments, and forwards other PCRs to an Adjudication module for manual determination of an authorized payment.

The routine begins at step 2205 where all PCRs in the queue for the current PP module are retrieved from the EMCC server. The routine then continues to step 2210 to receive a selection of a displayed PCR from the user. The routine continues to step 2215 to retrieve additional patient medical history for the patient, such as associated PCRs. The routine then continues to step 2225 to invoke subroutine 1900 to assist the user in selecting for the patient an ICD-9 diagnosis code corresponding to a diagnosis made by the provider. Diagnosis codes are indicated for which the routine can automatically authorize payment based on the context of previously specified information (i.e.. the insurance plan, the patient, related past treatment, the referring and performing providers, the referral basis, the type of facility, the referral treatment type suggestion, and the urgency).

After selecting a diagnosis code, the routine continues to step 2230 to similarly invoke subroutine 1900 to assist the user in selecting for the patient a CPT service code corresponding to products or services supplied by the performing provider. Service codes are indicated for which the routine can automatically authorize payment based on the context of previously specified information, including the selected ICD-9 diagnosis code. The routine continues to step 2235 to add the selected ICD-9 code and CPT codes to the PCR. The routine then continues to step 2240 to determine if there are additional ICD-9 and CPT codes to be added to the PCR. If so, the routine returns to step 2225. and if not the routine continues to step 2245 to determine if the user wishes to submit the current PCR to either the Paylist or Adjudication modules.

If it is determined in 2245 that the user does not wish to submit the PCR, the routine continues to step 2250 to reset the PCR status so that is not "Unauthorized." The routine then continues to step 2255 to invoke the Remote Distribution subroutine to return the PCR to the queue of pending PCRs for the current PP routine. If it is instead determined in step 2245 that the user does wish to submit the PCR, the routine continues to step 2260 to determine if the PCR status is "Unauthorized." If so, the routine continues to step 2275 to invoke the Remote Distribution subroutine to send the PCR to an Adjudication module. If it is instead determined in step 2260 that the PCR status is not "Unauthorized.^" the routine continues to step 2265 to determine the payment that will be received for the services indicated by the specified CPT codes. The routine then in step 2270 sends the PCR to the Paylist module for immediate payment of the determined amount. After steps 2255. 2270, or 2275. the routine returns to step 2205.

Those skilled in the art will appreciate that a variety of types or combinations of codes can be used by the PP routine. While the exemplary embodiment uses only two levels of specification and uses pre-defined sets of ICD-9 and CPT codes, other embodiments could have additional levels of other codes, could use other types of codes (e.g., HCPC codes), could combine codes from multiple different code sets at one level, and could allow customization in which usei -defined codes replace or supplement pre-defined codes.

Figure 23 is a flow diagram of an embodiment of the Hospital routine 2300. The Hospital routine receives PCRs indicating authorized referrals with the hospital as the performing provider, assists a user in adding information about the hospital encounter to the PCR. and submits the PCR for payment to either the Paylist or the Adjudication module. The routine begins at step 2305 where all PCRs in the queue for the cuπent Hospital routine are retrieved from the EMCC Server. The routine then continues to step 2310 to receive a user selection of a displayed PCR. After a PCR is selected, the routine continues to step 2320 to determine if the user has specified to discharge the patient. If not, the routine continues to step 2325 to retrieve the patient's medical history, including associated PCRs, so that it can be displayed. The routine then continues to step 2330 to determine if the user has specified to admit the patient. If so. the routine continues to step 2335 to add the admission date to the PCR. After step 2335. or if it is determined in step 2330 that the user did not specify to admit the patient, the routine continues to step 2340 to add a journal entry related to the patient encounter. These entries may include service codes related to services provided. The routine then continues to step 2345 to determine whether the services corresponding to the journal entry are automatically authorized for payment. Those skilled in the art will appreciate that this determination can be performed in a variety of ways, such as checking whether a specified service code can be automatically authorized based on the context of previously specified information or by requiring the user to flag exceptional journal entries when entered that are outside the normal scope of care. If it is determined in step 2345 that the services corresponding to the journal entry are not automatically authorized for payment, the routine continues to step 2350 to set the PCR status to "Unauthorized.^"' After step 2350, or if the routine determined in step 2345 that the services were authorized, the routine continues to step 2355 to determine if there are more journal entries to add to the PCR at this time. If so, the routine returns to step 2340, and if not, the routine continues to step 2360 to determine if the patient should be discharged at this time. If the patient is not to be discharged, the routine continues to step 2365 to invoke the Remote Distribution subroutine to return the PCR to the queue for the current Hospital module.

If it is instead determined in step 2320 or step 2360 that the patient is to be discharged, the routine continues to step 2370 to add the discharge date to the PCR. The routine then continues to step 2375 to determine if the PCR status is "Unauthorized." If so, the routine continues to step 2385 to invoke the Remote Distribution subroutine to send the PCR to the Adjudication module for manual determination of an authorized payment. If instead it is determined in step 2375 that the PCR status is not "Unauthorized," the routine continues to step 2380 to determine the payment that will be received for the products used and services provided. The routine then continues to step 2390 to invoke the Remote Distribution subroutine to send the PCR to the Paylist module for immediate payment of the determined amount. After steps 2365, 2385, or 2390, the routine returns to step 2305. Figure 24 is a flow diagram of an embodiment of the Adjudication routine 2400. The Adjudication routine receives PCRs related to requests for payment for diagnoses and services which could not be automatically authorized, and assists the user to determine the payment for the services performed by displaying relevant information. The routine begins at step 2405 where all PCRs in the queue for the Adjudication routine are retrieved from the EMCC Server. The routine continues to step 2410 to receive a selection by the user of a displayed PCR. The routine then continues to step 2415 to display information stored in the selected PCR that is related to the request for payment, and then in step 2420 receives a user command. In step 2425 it is determined if the user command is to retrieve additional information, and if so. the routine continues to step 2430 to retrieve and display the requested information from the EMCC Server and then returns to step 2420.

If it is instead determined in step 2425 that the user command is not to retrieve additional information, the routine continues to step 2435 to determine the medical necessity for the services indicated by the service codes in the PCR. Those skilled in the art will appreciate that this can be determined in a variety of ways, such as by receiving textual comments from the user or by automatically analyzing services provided and supporting comments justifying the services. After step 2435, the routine continues to step 2440 to select some or all of the service codes in the PCR to be authorized for payment. The routine then continues to step 2445 to determine a payment for the authorized service codes in the PCR. In step 2450. the routine determines whether the PCR should be submitted to the Paylist module. If so. the routine continues to step 2460 to invoke the Remote Distribution subroutine to send the PCR to the Paylist module. If the routine instead determines in step 2450 not to submit the PCR, the routine continues to step 2455 to invoke the Remote Distribution subroutine to return the PCR to an Adjudication routine. After step 2455 or 2460. the routine returns to step 2405.

Figure 25 is a flow diagram of an embodiment of the Paylist routine 2500. The routine receives PCRs reflecting referrals and services performed that are authorized to be paid a determined amount, and then pays the determined amount. The routine begins at step 2505 where it retrieves all PCRs from the EMCC server in the queue for the Paylist routine. The routine continues to step 2510 to select a retrieved PCR, and then continues to step 2515 to pay the determined amount. The routine then returns to step 2505 and continues to reimburse PCRs. Those skilled in the art will appreciate that this reimbursement can be performed in a variet}' of ways, such as by crediting bank accounts, electronic wire transfers, etc.

From the foregoing it will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.

Claims

1. A method in a computer system for controlling authorization for a medical referral of a patient from a referring provider to a performing provider, the performing provider to provide medical services authorized by the medical referral to the patient, the method comprising: displaying a list of choices each representing a patient : in response to selection of a patient by indicating the representative displayed choice, displaying a list of referring provider choices each representing a medical service provider authorized to make a medical referral of the selected patient: in response to selection of a referring provider by indicating the representative displayed choice, displaying a list of performing provider choices each representing a medical service provider authorized to provide medical services to the selected patient; in response to selection of a performing provider by indicating the representative displayed choice, displaying a list of referral basis choices each representing a reason for the selected referring provider to make a medical referral of the selected patient to the selected performing provider; in response to selection of a referral basis by indicating the representative displayed choice, displaying a list of treatment suggestion choices each representing at least one medical service that the selected referring provider can suggest be provided to the selected patient by the selected performing provider; in response to selection of a treatment suggestion by indicating the representative displayed choice, determining whether an authorization of a referral can be obtained without human intervention, the refe╧Çal being of the selected patient to the selected performing provider by the selected referring provider for the reason represented by the selected referral basis, the authorization allowing the selected performing provider to provide at least one of the medical services represented by the selected treatment suggestion; and when it is determined that the authorization of the referral is obtained, notifying the selected performing provider so that at least one of the medical services represented by the selected treatment suggestion can be immediately provided to the selected patient by the selected performing provider.

2. The method of claim 1 including: after the notifying of the selected performing provider. displaying a list of diagnosis code choices each representing a medical diagnosis that the selected performing provider can make for the selected patient; in response to selection of a diagnosis code by indicating the representative displayed choice, displaying a list of service code choices each representing a medical service that can be provided to the selected patient by the selected performing provider to address the medical diagnosis of the selected diagnosis code: and in response to selection of a service code by indicating the representative displayed choice, determining whether an authorization can be obtained without human intervention for the medical service represented by the selected service code.

3. The method of claim 2 wherein the medical service represented by the selected service code is determined to be authorized when the medical service is also represented by the selected treatment suggestion, and including: when the medical service is determined to be authorized, providing payment to the selected performing provider without human intervention by, determining a payment amount for the medical service; and providing the determined payment amount to the selected performing provider.

4. The method of claim 2 wherein when the authorization of the medical service represented by the selected service code cannot be obtained without human intervention, payment is provided to the selected performing provider by notifying a manual review user of the referral.

5. The method of claim 2 including: automatically authorizing payment to the selected performing provider for providing to the selected patient the medical service of the selected service code if the medical service represented by the selected service code is one of the medical services represented by the selected treatment suggestion.

6. The method of claim 5 wherein the automatic authorization of the payment includes: automatically determining a payment amount for the medical service represented by the selected service code: and automatically providing the determined payment amount to the selected performing provider.

7. The method of claim 2 wherein the choices displayed in each list depend on the selected choices from previous displayed lists.

8. The method of claim 2 including: after selection of a service code representing a medical service and in response to selection of any of a patient, a performing provider, a reason, a diagnosis code or a service code that is not a displayed choice, determining payment for providing the medical service by notifying a manual review user of the medical service.

9. The method of claim 1 wherein each displayed choice is an authorizable choice for that type of information such that an authorization can be obtained without human intervention for a referral including only authorizable choices, and wherein the authorizable choices for a type of information for the referral depend on previous selections for other types of information for the referral.

10. The method of claim 1 wherein each of the displayed patient choices has insurance coverage for medical services, wherein each of the displayed referring provider choices is authorized by the insurance coverage for the selected patient to make a medical referral of the selected patient, and wherein each of the displayed performing provider choices is authorized by the insurance coverage to provide medical services to the selected patient.

11. A computer system for facilitating management of patient services, the system comprising: a first component having a referral sub-component and an authorization subcomponent, the referral sub-component for verifying patient eligibility, for guiding selection of a performing provider and of a reason code for referral of a patient to the selected performing provider, and for automatic authorization when a combination of the selected performing provider and the selected reason code are pre-authorized. the authorization subcomponent for soliciting authorization from an authorization manager when the combination of the selected performing provider and selected reason code are not pre-authorized; and a second component having a performing sub-component and an approval subcomponent, the performing sub-component for providing to a performing provider an identification of a patient and a reason code for an authorized referral, for guiding selection of a diagnosis code reflecting a diagnosis for a referred patient, for guiding selection of a service code reflecting a service to be provided to a referred patient, and for automatic approval when a combination of the provided reason code, the selected diagnosis code, and the selected service code are pre-approved, the approval sub-component for soliciting approval from an approval manager when the combination of the provided reason code, the selected diagnosis code, and the selected service code is not pre-approved.

12. The computer system of claim 11 wherein the second component includes a payment sub-component for controlling payment to the performing provider upon approval of the combination of the provided reason code, the selected diagnosis code, and the selected service code.

13. The computer system of claim 11 wherein the referral sub-component of the first component is additionally for guiding selection of suggested medical services, and wherein the performing sub-component of the second component is additionally for providing to a performing provider an identification of suggested medical services for an authorized referral.