Patent Abstract:
According to various embodiments, methods and systems are provided for facilitating and managing communications between healthcare service referrers and healthcare service providers. Such communications are transacted via digital networks in connection with a healthcare information system. Referral of various diagnostic and therapeutic specialties is tracked from the initiation by the referrers to the completion of the services by the specialty service providers. Validation of insurance authorization is performed automatically if needed. Reports on the results of a requested specialty service as well as intermediate recommendations are made available to the referrer or other relevant entities upon completion of the service.

Full Description:
CROSS REFERENCE TO RELATED APPLICATIONS  
       [0001]     This application claims the benefit of U.S. Provisional Application No. 60/525,550, entitled “Digital Management of Referral and Provision of Healthcare Services”, filed Nov. 26, 2003, which is incorporated by reference herein. 
     
    
     BACKGROUND  
       [0002]     1. Field of the Invention  
         [0003]     This invention relates in general to healthcare services referral and management, and more particularly to automatically initiating and tracking referrals of specialty healthcare services as well as tracking intermediate and final results of the specialty services.  
         [0004]     2. Background Art  
         [0005]     When certain specialty services (whether a diagnostic test or therapeutic procedure) are needed for patient care, it typically takes a series of phone calls, conversations, and the processing of stacks of written notes or printed forms before a medical order for the services is placed by a healthcare referrer, such as a primary care doctor. This manual process is both error-prone and inefficient. It typically takes anywhere from ten to thirty minutes for a referring provider to prepare a patient&#39;s order. This time is spent collecting patient demographics, insurance information, and medical records and obtaining insurance authorizations. Much of the communication is done by telephone. Studies show that for a referring provider that is scheduling an average of 10 medial or diagnostic procedures per day it takes an average of three hours per day and 850 hours per year. Missed phone calls, voice mails, and misplaced paper are commonplace and they represent significant waste of human resources. Inefficiency in communication among healthcare referrers, healthcare specialty providers, insurance specialists, and any other relevant parties directly translates into inefficiency in the provision of patient care.  
         [0006]     There are software solutions available today that attempt to address this problem. Physician order entry systems are among them. These systems focus on order creation, and are typically confined to clinical systems or organizations from which a referring provider is operating. The primary objective of these systems is to capture a clinical order and validate its contents for medical accuracy and practice redundancies. These systems, however, do not focus on monitoring intermediate and final results of the order completion.  
         [0007]     Other existing software solutions allow for the display of medical images and diagnostic reports over a web interface. These solutions are typically based on the results of the medical or diagnostic procedure. They are not capable of, for example, placing a medical order and tracking the subsequent follow-up orders that are the recommended course of actions given the results of the services subscribed by the initial order. Thus, none of the existing automated solutions are capable of monitoring the entire life of a specialty order, from its inception to the final completion of the service.  
         [0008]     Accordingly, there is a need for a more efficient mechanism for placing a specialty order and monitoring the results of the completion of the order.  
       DISCLOSURE OF THE INVENTION  
       [0009]     The above need is met by a referral order management system that captures an initial specialty order from a referral provider office, tracks the relevant patient information regarding the order from a specialty department office, provides automated alerts to physicians and other healthcare professionals at the referral provider office when new order information is available, provides reports on the results of a requested specialty service and follows up with the subsequent recommendations. Such a system facilitates the communications between the referring provider office and the specialty group or department that will be performing the diagnostic or therapeutic procedure.  
         [0010]     In one embodiment, the referral order management system communicates with a referring provider office that creates a specialty order and a specialty department office that will be performing diagnostic or therapeutic procedures indicated in the order and providing updates on the order to the referral order management system. The referral order management system also communicates with an insurance carrier system that services preauthorization requests initiated by the referral order management system. The referral order management system notifies the referring provider office and a specialty department office of the events that are raised as the result of the actions performed on the specialty order. For example, the referral management system provides a notification when a new order is created, when a status of the order is updated, or when the specialty department office has posted results of the procedure indicated in the order.  
         [0011]     In one embodiment, the referral order management system executes various engines to perform the functionality for receiving an initial specialty order, tracking and capturing the relevant patient information regarding the order and providing automatic notifications about the status of the order. These engines include an order processing engine, an eligibility and preauthorization engine, and a notification engine. The order processing engine receives a specialty order from the referral provider office, preferably validates the received order, schedules a procedure indicated in the order, and automatically stores the order.  
         [0012]     The notification engine listens to events that are triggered as the result of the actions performed on the order. In one implementation, the notification engine notifies the referring provider office and the specialty department office of the events, thereby allowing a referring provider office and a specialty department office to monitor the status of the specialty order in real time.  
         [0013]     The eligibility and pre-authorization engine of the referral order management system receives a notification from the notification engine that the new order is stored, preferably determines whether the procedure indicated in the order requires insurance pre-authorization, and sends a request for pre-authorization to an insurance carrier system. The eligibility and pre-authorization engine then receives the pre-authorization information from the insurance carrier system and persists the information into the system. The eligibility and pre-authorization engine also uses eligibility rules to verify whether the procedure indicated in the specialty order is eligible for reimbursement by the insurance carrier.  
         [0014]     Thus, the referral order management system of the present invention tracks the entire life of a specialty referral, from the initial order of the service to the final completion of the service. Such comprehensive digital referral management enables significant reduction of ad hoc or manual communications among specialty service providers, referrers, and patients in order to set up and complete the required specialty services. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0015]      FIG. 1  is a high-level diagram illustrating an environment utilizing an embodiment of the present invention.  
         [0016]      FIG. 2  is a block diagram of the referral order management system.  
         [0017]      FIG. 3  is a block diagram illustrating a more detailed view of a data store of the referral order management system.  
         [0018]      FIG. 4  is an event diagram of a method for ordering specialty services and tracking intermediate and final results of the specialty services.  
         [0019]      FIG. 5  is a flow diagram of the steps performed by the eligibility and authorization engine within the referral order management system.  
         [0020]      FIG. 6  is a flow diagram of the steps performed by the notification engine within the referral order management system. 
     
    
       [0021]     The figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.  
       DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0022]      FIG. 1  is a high-level block diagram illustrating an environment  100  utilizing an embodiment of the present invention. The illustrated environment  100  includes a referral order management system  190 , a referring provider system  110 , a specialty department system  130 , and an insurance carrier system  170 .  
         [0023]     Referring provider system  110  is a computer system associated with a referring provider&#39;s office (not shown in  FIG. 1 ). In general, system  110  is an electronic device that allows end-users to interface with referral order management system  190 . System  110  can be, for example, a personal computer system, a portable digital assistant (PDA), a cellular phone, or any other system capable of communicating with referral management system  190  and providing a user interface for displaying information. In one embodiment, system  110  executes a web browser (not shown) such as INTERNET EXPLORER from Microsoft Corp. of Redmond, Wash. Although only one referring provider system  110  is shown in  FIG. 1  for purposes of clarity, embodiments of the present invention contemplate any number of referring provider systems interfacing with referral management system  190 . Because in the preferred embodiment the invention is described in the medical context, end-users of system  110  can be physicians, referring provider office administrators, and other medical staff having access to system  110 .  
         [0024]     The referring provider&#39;s office uses system  110  to create a specialty referral order  115   a  to perform a medical procedure, such as a diagnostic test or a therapeutic procedure, on a patient. System  110  communicates the order  115   a  to referral order management system  190 . As used herein, “a specialty order” is a documented direction to perform a medical procedure on a patient. It should be noted that “a specialty order”, “specialty referral order”, and “order” are used herein interchangeably. System  110  includes a user interface that allows a referring physician as well as other members of the referring provider&#39;s office staff to monitor the entire life of the order  115   a , from the initial order to the final completion of the procedure listed in the order.  
         [0025]     Specialty department system  130  is a computer system associated with a specialty service provider office (not shown in  FIG. 1 ). The specialty service provider performs a medical procedure on a patient as indicated in the specialty referral order. System  130  is adapted to communicate to system  190  any updates  116   a  to the status of the order or results of the order. As used herein, “results” are findings ascertained during the performance of the medical procedure. The specialty department office uses system  130  to update the status of an order and add results of the procedure to the order. A specialty service provider office can be an outpatient clinic, a hospital, or any other medical facility that performs diagnostic or therapeutic procedures on patients.  
         [0026]     Referral order management system  190  is adapted to receive a specialty referral order  115   a  from system  110 , process the order, perform eligibility and pre-authorization checks, track and capture relevant patient information regarding the specialty service, provide automated alerts  115   b  and  116   b  to system  110  and  130  respectively when an event occurs. An event can be triggered, for example, when a new order is created, an existing order is updated, results of the order have been submitted, or pre-authorization information is updated on the existing order. Thus, referral order management system  190  tracks and reports to systems  110  and  130  the status of the order at various points of the order processing. Such “real-time” monitoring enables accurate and efficient communications among all entities shown in  FIG. 1  participating in the specialty order creation and execution. Various components of referral order management system  190  will be described in more detail below in reference to  FIG. 2 .  
         [0027]     System  190  operates in several different modes according to the various embodiments depending on the conditions and needs of a given healthcare information setting. In one embodiment, the referral order management system  190  operates as a web-based system executed on a server (not shown in  FIG. 1 ). In another embodiment, the referral order management system  190  is integrated into a third party system or framework (not shown in  FIG. 1 ) or a third party portal, and thereby provides to the third party system the functionalities and advantages of automated tracking and management of information surrounding specialty service referral. In yet another embodiment, system  190  operates as a standalone system.  
         [0028]     Whether standalone, embedded in another system, or integrated in a distributed network such as a web framework, the referral order management system  190  tracks the entire process of referring and completing various specialty therapeutic and diagnostic services and thereby allows for easy access of patient information.  
         [0029]     The insurance carrier system  170  is a third party system adapted to receive insurance authorization requests  117   a  from system  190 , perform insurance pre-authorization, and provide electronic pre-authorizations  117   b  to system  190  for procedures to be to performed on patients. System  170  is associated with an insurance carrier. Although only one system  170  is shown in  FIG. 1 , referral order management system  190  can be in communication with any number of insurance carrier systems  170 .  
         [0030]     In one embodiment, system  190  interfaces with systems  110 ,  130 , and  170  via networks  119   a ,  119   b , and  119   c  respectively. Networks  119   a ,  119   b , and  119   c  allow the electronic exchange of data between system  190  and system  110  and  130 . Networks  119   a ,  119   b , and  119   c  can be the Internet. However, it will also be appreciated that communication networks  119   a ,  119   b , and  119   c  can be any known communication network.  
         [0031]     The data exchanged over networks  119   a ,  119   b , and  119   c  can be represented in various formats, such as the hypertext markup language (HTML), the extensible markup language (XML), or any other representation.  
         [0000]     Referral Order Management System  
         [0032]     Turning now to  FIG. 2 , referral order management system  190  includes various engines to perform the functionality of receiving an initial specialty order, tracking and capturing the relevant patient information regarding the order and providing automatic notifications to referring provider system  110  and specialty department system  130  about the status of the order. These engines include an order processing engine  230 , an eligibility and preauthorization engine  240 , a communication engine  250 , a notification engine  210 , and a data store  220 . In one embodiment, these engines are implemented as modules. As used herein, the term “module” refers to computer program code adapted to provide the functionality attributed to the module. The program code is embodied in a random access memory (RAM), a read-only memory (ROM) or other media.  
         [0033]     Order processing engine  230  preferably receives a specialty order from system  110 , validates the received order, schedules a procedure indicated in the order, and automatically stores the order in data store  220 . An exemplary order includes, for example, an order ID, status of the order, patient ID, medical procedure ID, requested physician name, requested date and time when the procedure needs to be performed, and diagnosis. Other data, of course, may be included in the order.  
         [0034]     Data store  220  maintains data utilized by referral order management system  190  to perform its functionality.  FIG. 3  is a block diagram of data store  220 . Data store  220  maintains patient records  320 , scheduling records  330  for medical procedures, specialty orders  340 , and insurance data  350 . Data store  220  also keeps track of events  310  that occur within the referral order management system  190 . Data store  220  can be implemented, for example, as a relational database management system (RDMBS) and queries to the data store are accomplished via Standard Query Language (SQL).  
         [0035]     Patient records  320  contain fields for storing data associated with a patient. A field can hold data in the form of numeric, textual, binary information, and any other data type adapted for storage in a data store  220 . In one embodiment, a patient record includes patient identification information, such as patient ID, patient name, Social Security Number (SSN), date of birth, gender, patient insurance information and other patient identification information. Other data may be included as desired.  
         [0036]     Scheduling records  330  include fields for storing data associated with scheduling a procedure. A typical record includes the following fields: an identification of a resource to be used to perform the procedure, date and time when the procedure can be scheduled to perform, and an order ID. As used herein, “a resource” is an entity that is utilized to perform the procedure. A resource can be a room, a piece of equipment, or a person utilized to perform the medical procedure.  
         [0037]     Orders  340  are stored in association with patient records. An order includes, for example, an order ID, patient ID, status, procedure ID, diagnosis, Requesting Physician Name, Requested Date and Time, pre-authorization number, “require pre-authorization” flag, and “require advanced beneficiary notice (ABN)” flag. The ABN is a document that is required to be signed by a patient when the insurance carrier will not pay for the medical procedure. A typical ABN states that the patient has been notified that the insurance carrier will not reimburse the procedure, and the patient is responsible for the payment. In one embodiment, when the “require advanced beneficiary notice (ABN)” flag is set to FALSE, it indicates that the procedure indicated in the order will be reimbursed by the insurance carrier. If the flag is set to TRUE, it indicates that the insurance carrier will not reimburse for the procedure (and hence the patient is required to sign an ABN notice to this effect).  
         [0038]     Insurance data  350  includes information related to various insurance carriers and various insurance plans offered by insurance carriers. This information includes, for example, procedure eligibility, pre-authorization requirements, supported electronic format, co-payment information, and other insurance carrier related information. Exemplary electronic formats supported by various insurance carriers are the Accredited Standards Committee (ASC) X12 protocol and the Health Level Seven (HL7) protocol.  
         [0039]     Data store  220  also stores events  310  that are triggered as the result of the actions performed on the specialty order. Exemplary events are creation of a new order, updating of an existing order, receiving results of the existing order or receiving insurance pre-authorization of the existing order. In one embodiment, stored events have the following format: order ID, event code, and time stamp specifying the time when the event occurred. As will be described in greater details below, notification engine  210  shown in  FIG. 2  uses events  310  to provide notifications to referring provider system  110  and specialty department system  130  about the events.  
         [0040]     Referring again to  FIG. 2 , referral order management system  190  further executes notification engine  210 . Engine  210  is adapted to listen to data events and perform an action in response to the data events. As previously described, various actions can trigger an event. For example, when order processing system  230  processes the received order and stores the order in data store  220 , a NEWORDER event is triggered. Similarly, when specialty department system  130  communicates to referral order management system  190  results of the medical procedure or simply the status of the medical procedure, RESULTUPDATE and ORDERUPDATE are triggered. Likewise, when insurance authorization engine  240  communicates pre-authorization information to referral management system  190 , a PREAUTHUPDATE event is triggered. These events are stored in data store  220  in association with the identification of the order that triggered the event and the time stamp. In one implementation, engine  210  notifies referring provider system  110 , specialty department system  130 , and eligibility and pre-authorization engine  240  of the events, thereby enabling a referring provider office and a specialty service department to monitor the status of the specialty order in real time. Notifications can be sent using COM interfaces, web service calls, or via XML or HL7 messages.  
         [0041]     Referral order management system  190  further executes eligibility and preauthorization engine  240 . Engine  240  receives notification from engine  210  that a new order is stored, determines whether the procedure indicated in the order requires insurance pre-authorization, and sends a request for pre-authorization to communication engine  250  if the pre-authorization is required. Engine  240  is further adapted to receive pre-authorization information, such as a preauthorization number, from communication engine  250 , and store the information in data store  220 . Engine  240  is also adapted to use eligibility rules to verify whether the procedure is eligible for reimbursement by the insurance carrier.  FIG. 5  describes in more detail various steps performed by engine  240  to perform pre-authorization and eligibility processing. Although in the preferred embodiment of the present invention, engine  240  is a part of the referral order management system  190 , other embodiments of the present invention may use third party subsystems for performing the functionality of engine  240 . These systems include those provided by IDX Systems Corporation (www.idx.com) in Burlington, Vt. and WebMD (www.webmd.com) in Elmwood Park, N.J., among others.  
         [0042]     Communication engine  250  is adapted to receive a pre-authorization request from engine  240 , query insurance data  350  in data store  220  for an electronic format that is supported by the insurance carrier whose preauthorization is requested, format the data indicated in the request into the appropriate format, and send the request to system  170 . Communication engine  250  is further adapted to receive pre-authorization information from system  170  and forward the information to engine  240 . In one embodiment, the pre-authorization information includes a pre-authorization number. Engine  250  can be implemented as ConnectR application provided by IDX Systems Corporation of Burlington, Vt.  
         [0000]     Methods of Operation  
         [0043]      FIG. 4  is an event diagram illustrating exemplary transactions among referring provider system  110 , referral order management system  190 , insurance carrier system  170 , and specialty department system  130 . In  FIG. 4 , the above entities are listed across the top. Beneath each entity is a vertical line representing the passage of time. The horizontal arrows between the vertical lines represent transactions between the associated entities. It should be noted that not every transaction is shown in  FIG. 4 . In other embodiments of the present invention, the order of the transactions can vary.  
         [0044]     Initially, when a referring provider office (not shown in  FIG. 4 ) creates a new order for a medical procedure for a patient, the office causes system  110  to send a query  410  to data store  220  within system  190  for data associated with the patient using, for example, the patient ID, patient name, or patient SSN. If the order is created for an existing patient (e.g., the patient ID matches the patient ID of the existing record), then system  110  preferably updates the patient&#39;s record in data store  220  with the newly created order. Otherwise, system  110  causes a new patient record to be created in data store  220  and causes the patient record to be populated with the data for the newly created order and other additional information as can be determined.  
         [0045]     Within referral order management system  190 , order processing engine  230  receives  430  the order and processes  440  the order. In one embodiment, processing of the order includes the following steps: validating the order and scheduling the procedure indicated in the order.  
         [0046]     To validate the order, engine  230  preferably determines whether the received order contains enough information to support further processing of the order. In one embodiment, the received order has to include at least one of a patient name, ordered procedure ID, diagnosis, and requesting physician name. Otherwise, engine  230  rejects the order and generates an “incomplete order” event, which is communicated to referring provider system  110  via an event notification. Such a notification may be provided in the form of the electronic message.  
         [0047]     If the order contains enough information to support further processing of the order, engine  230  within system  190  further performs scheduling of the order. As previously described, data store  220  maintains scheduling records  330 . An exemplary scheduling record includes, for example, the following fields: a name of the resource, date and time when the resource is available, and order Id. A resource is an entity that is used to perform the procedure. A resource can be a room, a piece of equipment, or a physician required to perform the ordered procedure. If the resource has already been scheduled, the order ID, for example, is set to “1”. Alternatively, order ID is set to “0”. Thus, scheduling records for resource Cath Lab may look like the one shown in Table 1:  
                                     TABLE 1                           Exemplary Scheduling Records                Name of the                       Resource   Date   Time   Order ID                       Cath Lab 1   Jan. 2, 2005   5:15 p.m.   1               Jan. 2, 2005   5:30 p.m.               Jan. 2, 2005   5:45 p.m.                      
 
         [0048]     In this example, Cath Lab 1 is not available at 5:15 p.m. because the order ID is set to “1”.  
         [0049]     To schedule the procedure, order processing engine  230  queries data store  220  for the resources that can be used to perform the ordered procedure. Engine  230  loops through scheduling records for each resource and uses the following metrics such as the duration of the procedure and the requested date and time to find an available time slot for the ordered procedure. In one embodiment, engine  230  searches for consecutive records for a given resource having a cumulative duration of time equal or greater to the time specified in the order for the duration of the procedure. If engine  230  does not find an available time slot to schedule the procedure (e.g., the order ID is set to “1”), engine  230  searches scheduling records for another resource that can be used to perform the procedure until the available resource is found.  
         [0050]     Those skilled in the art would appreciate that in other embodiments of the present invention an order may require that more than one resource be available for a procedure to be performed. For example, an order for a Cardiac Intra-Vascular Ultrasound (IVUS) procedure may require that the Cath Lab and the ultrasound equipment be available at the same time. To this end, engine  230  searches scheduling records for more than one resource to find an available time slot so as to schedule the procedure.  
         [0051]     Once order processing engine  230  schedules the procedure indicated in the order, engine  230  stores the processed order in data store  220 . Thus, data store  220  now stores the order along with the scheduled date and time, duration of the procedure, and the resource that will be used to perform the procedure.  
         [0052]     As was previously described, certain actions performed on a specialty order by various entities can trigger events. Thus, when a new order is stored in data store  220 , it triggers an event  450 . System  190  notifies  460  referring provider system  110  of the event. Data store  220  keeps track of events that occur within system  190 . As previously described, in one embodiment, an event is stored in the form of an event code, order ID, and a time stamp indicating when the event took place. Thus, when a new order is created at 5:00 p.m. on Nov. 23, 2004 having the order ID “ 12345 ” the following event will be stored in  310 :  
                                 TABLE 2                           Exemplary Events stored in Data Store 220.                Time Stamp   Event Code   Order ID                       Nov. 23, 2004   NEWORDER   12345           5:00 p.m.                      
 
         [0053]     When a patient reports to a specialty department office at the time instructed in the specialty order, the office staff updates the order in the specialty department system  130 . As the patient undergoes the procedure indicated in the order, the specialty department office staff monitors the status of the order and stores the status of the order into the system  130 . For example, when the patient currently undergoes the procedure, the order status is “In-progress”; when the procedure is completed, the order status is “Completed”. In addition, specialty department staff adds results of the procedure to the order. The results are findings that are ascertained after the performance of the medical procedure. The specialty department staff can also include follow-up recommendations. For example, if the ordered procedure is a mammography-screening test, the findings may be abnormal tenderness of the breast tissue. The follow-up recommendation may be a biopsy. The specialty department staff enters the order status, the results, and follow-up recommendations to system  130 . System  130  sends  470  to system  190  a message that preferably includes an order status, an order results, responsible physician, and suggested follow-up recommendations. In one implementation, system  130  updates data store  220  with the new order information.  
         [0054]     When referral order management system  190  receives  470  status order updates or result order updates it triggers  480  an event. When an update to the status of the order is received, a new event is stored in events  310  in association with the order ID with the event code “ORDERUPDATE”. Similarly, when a change was filed on the order result, a new event is stored in events  310  in association with the order ID with an event code “RESULTUPDATE”. As previously described, each event in events  210  has a time stamp specifying the time when the event occurs. In addition, status of the order, results of the order, and follow-up recommendations are persisted to data store  220 .  
         [0055]     Notification engine  210  listens for data events. In one embodiment, engine  210  queries events  310  in data store  220  having a time stamp greater than the time stamp of the last query that was performed by engine  210 .  
         [0056]     In another embodiment, engine  210  subscribes to a message queue mechanism, such as Microsoft Message Queue or IBM MQ Services, to receive new events stored in events  310 .  
         [0057]      FIG. 6  is a flow diagram illustrating the steps performed by notification engine  210  according to one embodiment of the present invention. At step  610 , engine  210  receives a new event. Engine  210  extracts the order ID from the event and queries data store  220  for data associated with the order having the extracted order ID. In response to the query, engine  210  receives the stored order  620 , along with its results and updates, as well as insurance pre-authorization information (as will be described in more detail later). Engine  210  maintains business rules for routing events. As an illustrative example, a rule may indicate that if Event Code=NEWORDER, then route the event to system  110 , system  130 , and engine  240 . If Event Code=ORDERUPDATE, then route the event to system  110 . Engine  210  routes the events responsive to the rules. Thus, if the event code is NEWORDER  630 , engine  210  notifies  640  referring provider system  110 . Engine  210  also notifies  650  specialty department system  130 . The notification includes the updated order. In one implementation, notifications can be sent using COM interfaces, web service calls, or via XML messages. When the referring provider office staff receives the results of the procedure, it enables the staff to initiate a new order request based on the text of the provided result. Engine  210  also notifies  660  eligibility and pre-authorization engine  240  (shown in  FIG. 2 ).  
         [0058]     If the event code is ORDERUPDATE or RESULTUPDATE  670 , engine  210  notifies  640  referring provider system  110 . If the event code is PREATHUPDATE, engine  210  notifies  640  referring provider system  110 .  
         [0059]     Referring again to  FIG. 4 , within referral order management system  190 , eligibility and preauthorization engine  240  performs  485  eligibility verification and preauthorization.  FIG. 5  is a flow diagram illustrating the steps performed by eligibility and pre-authorization engine  240 . Those skilled in the art will recognize that alternative embodiments of engine  240  may perform the illustrated steps in different orders, perform additional steps, or even omit certain steps.  
         [0060]     Engine  240  receives  510  a new event indicating that the new order is stored. Engine  240  also receives data associated with the order. Engine  240  determines  520  if insurance pre-authorization is required for the procedure indicated in the order. In one implementation, engine  240  uses the order ID indicated in the new event notification to determine the patient insurance carrier. Engine  240  determines whether the patient&#39;s insurance carrier requires pre-authorization for the procedure indicated in the order. If the insurance carrier requires pre-authorization for the procedure, engine  240  determines  540  whether the insurance carrier supports an electronic request for pre-authorization. If so, engine  240  communicates  550  the request for preauthorization to communication engine  250  within system  190 . The request includes, for example, patient ID, ordered procedure, diagnosis ID, insurance carrier, and requesting physician name.  
         [0061]     If the insurance carrier does not support an electronic request for pre-authorization, engine  240  does not enter a pre-authorization number and sets the “required preauthorization” flag to TRUE in orders  220 . Engine  240  notifies  530  referring provider system  130  that verbal insurance authorization is required for the procedure indicated in the order.  
         [0062]     If the insurance carrier does not require pre-authorization for a procedure indicated in the order, engine  240  does not enter a pre-authorization number in orders  340  and sets the “required preauthorization” flag to FALSE in orders  220 . As part of the eligibility verification, engine  240  then determines  560  whether the procedure requires advanced beneficiary notice (ABN). In one implementation, engine  240  uses insurance data  350  in data store  220  to determine whether the insurance carrier reimburses for the procedure indicated in the order that needs to be performed in connection with a diagnosis indicated in the order. If the insurance carrier reimburses for the procedure for the diagnosis indicated in the order, then the “required ABN” flag in orders  310  is set  580  to FALSE. In the alternative, the “required ABN” flag is set to TRUE for this order, and engine  240  notifies  570  referral provider system  110  that the patient is required to sign the advance beneficiary notice, which indicates that the procedure will not be reimbursed by the insurance carrier and the patient is responsible for the payment.  
         [0063]     In other implementations, engine  240  uses more complex eligibility rules to determine whether a certain procedure is eligible for reimbursement by insurance carrier. For example, eligibility rules may take into account the patient&#39;s age, gender and previous orders in considering whether or not a procedure will be reimbursed. For example, to be eligible for a mammography-screening test, a woman must be at a certain age before an insurance carrier will pay for one screening test every 2 years. Once a woman reaches 50 years old, insurance carriers typically pay for one screening annually. If a screening procedure has a result that indicates that a follow-up examination is necessary regardless of the age, the carrier will reimburse for additional procedures provided that the diagnosis requires so (e.g., suspicious abnormality found during physical exam). If a carrier elects not to reimburse the procedure, the patient may elect to have the procedure performed, provided the patient signs an ABN notice and pays for the procedure.  
         [0064]     Referring again to  FIG. 4 , within referral order management system  190 , communication engine  250  sends  490  a pre-authorization request to insurance carrier system  170 . The request includes, for example, patient ID, insurance carrier, ordered procedure and diagnosis ID.  
         [0065]     Insurance carrier system  170  receives  490  the preauthorization request and provides the response  492  to communication module  250  within referral order management system  190 , which in turn sends the response to eligibility and pre-authorization engine  240 . The response may include patient ID, ordered procedure, pre-authorization number, and a flag indicating whether the procedure will be reimbursed. Engine  240  associates the received information with the order ID and updates the order in data store  220  with the received information.  
         [0066]     When referral order management system  190  receives  492  a preauthorization response, an event is triggered  494 . The new event having an event code “PREATHUPDATE” in stored in events  310  in association with the order ID with a time stamp specifying the time when the event occurs. Notification engine  240  notifies  496  referring provider system  110  of the new event.  
         [0067]     Thus, the present invention advantageously captures the initial specialty order, tracks the relevant patient information regarding the order, provides automated alerts to physicians and other healthcare, professionals when a new order information is available, communicates the order results, and follows up with the subsequent recommendations and results of the ordered diagnostic tests or therapeutic procedures without paper-based communication with the specialty department office. Thus, some of the benefits of the present invention are in that it significantly reduces paper-based communications between specialty service providers and referrers to initiate a specialty order and complete services prescribed in the order. In addition, the present invention lightens medical staff workload by automating a scheduling procedure.

Technology Classification (CPC): 6