US20140249975A1 - Interactive electronic bill payment system - Google Patents
Interactive electronic bill payment system Download PDFInfo
- Publication number
- US20140249975A1 US20140249975A1 US14/049,733 US201314049733A US2014249975A1 US 20140249975 A1 US20140249975 A1 US 20140249975A1 US 201314049733 A US201314049733 A US 201314049733A US 2014249975 A1 US2014249975 A1 US 2014249975A1
- Authority
- US
- United States
- Prior art keywords
- bill
- plan
- provider
- payment
- adjudication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 230000002452 interceptive effect Effects 0.000 title 1
- 238000012545 processing Methods 0.000 claims abstract description 39
- 230000004044 response Effects 0.000 claims abstract description 8
- 238000003780 insertion Methods 0.000 claims abstract description 6
- 230000037431 insertion Effects 0.000 claims abstract description 6
- 238000012544 monitoring process Methods 0.000 claims abstract description 6
- 238000000034 method Methods 0.000 claims description 82
- 230000008569 process Effects 0.000 description 55
- 230000006870 function Effects 0.000 description 53
- 238000007726 management method Methods 0.000 description 40
- 239000011800 void material Substances 0.000 description 18
- 238000012552 review Methods 0.000 description 11
- 230000008859 change Effects 0.000 description 7
- 238000012790 confirmation Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 230000008676 import Effects 0.000 description 4
- 230000000737 periodic effect Effects 0.000 description 4
- 239000000725 suspension Substances 0.000 description 4
- 238000010200 validation analysis Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 239000003607 modifier Substances 0.000 description 3
- 239000000047 product Substances 0.000 description 3
- 238000010926 purge Methods 0.000 description 3
- 230000004913 activation Effects 0.000 description 2
- 238000007792 addition Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- ATJFFYVFTNAWJD-UHFFFAOYSA-N Tin Chemical compound [Sn] ATJFFYVFTNAWJD-UHFFFAOYSA-N 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 238000013502 data validation Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 230000007420 reactivation Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 230000001755 vocal effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
Definitions
- the present invention relates to electronic bill submission and processing, and in particular to insurance claims corresponding to providers of insurance services.
- an electronic bill processing system for coordinating the submission and processing of an electronic bill corresponding to a provider of insurance services, the system comprising;
- a method for coordinating the submission and processing of a bill according to predictive payment data of a plan comprises the steps of:
- a system for coordinating the submission and processing of a bill according to predictive payment data of a plan comprising:
- FIG. 1 is an electronic bill processing and management system
- FIG. 2 is a component model of the system of FIG. 1 ;
- FIG. 3 is a component model for a provider bill submission interface for the system of FIG. 1 ;
- FIG. 4 is an example screen of the submission interface of FIG. 3 ;
- FIGS. 5A , B is a further example screen of the interface of FIG. 3 ;
- FIG. 6 shows a Labour Management Re-entry workflow of the system of FIG. 1 ;
- FIG. 7 is a referrals workflow for the re-entry workflow of FIG. 6 ;
- FIG. 8 shows a selection algorithm for the workflow of FIG. 7 ;
- FIG. 9 is a manage plans workflow for the re-entry workflow of FIG. 6 ;
- FIG. 10 shows a first graphical user interface for the workflow of FIG. 7 ;
- FIG. 11 shows a second graphical user interface for the workflow of FIG. 7 ;
- FIG. 12 shows a third graphical user interface for the workflow of FIG. 7 ;
- FIG. 13 shows a fourth graphical user interface for the workflow of FIG. 7 ;
- FIG. 14 shows a fifth graphical user interface for the workflow of FIG. 7 ;
- FIG. 15 shows a workflow for creating a plan for the workflow of FIG. 6 ;
- FIG. 16 shows a first graphical user interface for the workflow of FIG. 9 ;
- FIGS. 17A , B shows a second graphical user interface for the workflow of FIG. 9 ;
- FIG. 18 shows a third graphical user interface for the workflow of FIG. 9 ;
- FIG. 19 shows a fourth graphical user interface for the workflow of FIG. 9 ;
- FIG. 20 shows a fifth graphical user interface for the workflow of FIG. 9 ;
- FIG. 21 shows a plan versus actuals report workflow for the system of FIG. 1 ;
- FIGS. 22 , 23 , and 24 show a plan versus actuals report according to the workflow of FIG. 21 ;
- FIG. 25 shows the components of a predictive payment request for the system of FIG. 1 ;
- FIG. 26 shows an interface for a predictive payment
- FIG. 27 is a bill generation workflow of the system of FIG. 6 .
- an insurance bill electronic processing and management system 10 has user interfaces 12 , 14 for communicating over a network 16 , such as the Internet, information 18 related to insurance bill submission and processing corresponding to insurance claims.
- the user interface 14 in the form of a web browser, facilitates electronic submission of the bill information 18 from service providers 20 to an integrated database 26 .
- the integrated database 26 stores the bill information 18 for record keeping.
- the providers 20 provide insurance related services to workers 22 making the insurance claims. Management of the insurance services, provided by the providers 20 , is overseen by a labour management agency 24 .
- the agency 24 uses the user interface 12 to manage the type and content of the bill information 18 contained within the database 26 , as well as coordinating overall processing and access of the bill information 18 . It is recognized that the workers 22 could also submit electronic bills through the interface 14 with limited functionality.
- the system 10 supplements the bill information 18 with general data parameters 28 obtained from an insurance claim database 30 , a provider identification database 32 , and an employers/workers database 34 .
- the data parameters 28 are typically not specific to any one bill represented in the bill information 18 , and include worker addresses, provider names and services, and insurance claim particulars.
- a workflow engine 36 (see FIG. 2 ) manages the transfer of the bill information 18 and the data parameters 28 between an adjudication engine 38 and a payment engine 40 .
- the adjudication engine 38 processes any bills, related to the insurance claims, resident in the integrated database 26 to determine what portion of the bills, if any, should be paid out.
- the adjudication engine 38 therefore receives bills from the providers 20 , adjudicates the provider bills according to business rules (including utilization rules), generates adjudication results for valid “complete” bills, and generates exception records for invalid “exception” bills.
- the payment engine 40 then directs payment of the adjudicated complete bills to a financial institution 42 for subsequent payment to the providers 20 and/or workers 22 .
- the bill information 18 includes details related to bill status, such as pending or approved, related claim data, and bill payment particulars.
- the providers 20 have real-time access through the interface 14 to selected bill information 18 contained within the integrated database 26 , corresponding to pre and post processing of the insurance claims and the related bills.
- the management agency 24 determines the degree of access by the providers 20 to the bill information 18 through the provider procedures 44 (see FIG. 2 ), which defines the functionality of the provider interface 14 .
- Real-time accessibility of the bill information 18 resident on the integrated database 26 facilitates self-management, by the providers 20 , of the bill processing history once the bills are submitted through the interface 14 to the integrated database 26 . Therefore, the integrated database 26 acts as a repository of bill information 18 and payment information related thereto.
- the management agency 24 uses a support system 1 for monitoring and setting up the electronic processing and management system 10 .
- the support system 1 includes a processor 2 coupled to the interface 12 .
- the processor 2 is coupled to a display 3 for displaying the interface 12 and to user input devices 4 , such as a keyboard, mouse, or other suitable devices. If the display 3 is touch sensitive, then the display 3 itself can be employed as the user input device 4 .
- a computer readable storage medium 5 is coupled to the processor 2 for providing instructions to the processor 2 to instruct and/or configure the various components of the system 10 , including the processes related to operation of the workflow engine 36 and interfaces 12 , 14 . These instructions can be used to help set-up and define the protocols and other procedures related to the operation of the system 10 .
- the computer readable medium 5 can include magnetic disks, magnetic tape, optically readable medium such as CD ROM's, and semi conductor memory such as PCMCIA cards.
- the medium 5 may take the form of a portable item such as a small disk, floppy diskette, cassette, or it may take the form of a relatively large or immobile item such as hard disk drive, solid state memory card, or RAM provided in the support system 1 . It should be noted that the above listed example mediums 5 can be used either alone or in combination.
- the functionality of the provider interface 14 is controlled by the provider procedures 44 , which are predefined by the management procedures 46 according to the desired degree of accessibility to the bill information 18 resident on the integrated database 26 .
- the procedures 44 permit the providers 20 through the interface 14 to select bills, update bills, delete bills, and determine bill status once submitted to the integrated database 26 .
- Sub-databases of the integrated database 26 directly accessible by the providers 20 in real-time, are a bill adjudication queue database 48 and a bill status database 50 .
- the queue database 48 lists bill information 18 including all bills (and corresponding bill details) awaiting adjudication, which preferably are both read and write accessible by the providers 20 .
- the status database 50 lists bill information 18 including a pending status (bills undergoing adjudication), a result status (bill adjudication results), and/or a payment status (bill payment decision), which are preferably only read accessible by the providers 20 .
- a pending status (bills undergoing adjudication), a result status (bill adjudication results), and/or a payment status (bill payment decision), which are preferably only read accessible by the providers 20 .
- Real-time inquiry of these bill statuses and queue are accessible (defined by the provider procedures 44 ) by the providers 20 through the interface 14 , with detailed breakdowns of the adjudication and payment decisions determined by the adjudication engine 38 and the payment engine 40 .
- the management user interface 12 allows the management agency 24 to make decisions on the operation of the system 10 , as well as select, delete, update, and inquire on selected bills submitted by the providers 20 and/or workers 22 .
- the interface 12 has a set of sub-interfaces of a predictive payment interface 54 , labour market re-entry (LMR) interface 56 , a consultation payment interface 58 , and an inquiry interface 60 , which are controlled by the management procedures 46 as defined by the management agency 24 .
- the management agency 24 can also use the interfaces 54 , 56 , 58 , 60 to update the provider procedures 44 and management procedures 46 .
- the management agency 24 can use the predictive interface 54 and the LMR interface 56 to define and create individual adjudication rules (utilization rules UR), related to specific codes (for example LMR codes), for insertion into the business rule set of the adjudication engine 38 .
- the management procedures 46 provide both read and write interaction of the interfaces 54 , 56 , 58 , 60 with the integrated database 26 .
- Interaction between the interfaces 54 , 56 , 58 , 60 is indicated by arrows 66 , which allows for the sharing of billing data and review functionality between the interfaces 54 , 56 , 58 , 60 , including prepopulation of data fields.
- the interfaces 54 , 56 , 58 , 60 have access to the adjudication queue database 48 and the status database 50 as described above, with further capabilities such as editing the operation of the bill queue and amending the bill statuses.
- the interfaces 54 , 56 , 58 , 60 also have access to sub-databases of a bill scheduling database 62 and an adjudication rules database 64 .
- the scheduling database 62 contains data pertaining to bills removed from the queue database 48 by the workflow engine 36 for future processing, and/or data pertaining to predictive bills that are periodically inserted into the queue database 48 by the workflow engine 36 for processing by the adjudication engine 38 and payment engine 40 .
- the adjudication rule database 64 contains adjudication rules created by the interfaces 54 and 56 in response to periodic bill parameters for predictive and labour market re-entry (LMR) insurance claims as controlled by the workflow engine 36 . It is recognized that data for bills related to LMR insurance claims could also be stored in the scheduling database 62 .
- LMR predictive and labour market re-entry
- the degree of access for the read and write interaction of the database 48 , 50 , 62 , 64 contents could also be limited to various access levels for individuals of the management agency 24 , depending upon the individuals' priority.
- the access to the integrated database 26 from the interfaces 12 , 14 can be determined by role based features for individual providers 20 and employees of the management agency 24 , as well as state based features used as lock out features to permit sequential rather than parallel editing of the bill information 18 and data parameters 28 .
- the workflow engine 36 monitors the data content of the sub-databases 48 , 50 , 62 , 64 according to the management procedures 46 , as well as amendment of the rule set of the adjudication engine 38 by the contents of the rules database 64 .
- the data content of the databases 48 , 50 , 62 , 64 consists of the bill information 18 and the data parameters 28 , which are supplied by the management agency 24 , the providers 20 , and the workers 22 .
- Adjudication and payment details, generated by the adjudication engine 38 and payment engine 40 respectively, are also coordinated by the workflow engine 36 into and out of the integrated database 26 , as required. It is recognized that access of the interfaces 12 , 14 to the contents of the integrated database 26 is preferably in real-time.
- access to the integrated database 26 by the workflow engine 36 is preferably in periodic or batch mode to facilitate processing efficiencies, such as providing lump sum payments to particular providers 20 related to a plurality of adjudicated bills.
- real-time access of the workflow engine 36 to the integrated database 26 could also be done if desired.
- the workflow engine 36 coordinates, through a defined gather/insert process 66 by the management procedures 46 , the gathering of all adjudication rules from the rule database 64 for insertion into the adjudication engine 38 .
- the workflow engine 36 also coordinates a scheduling process 68 for creating bills from the scheduling database 62 contents, which are scheduled for insertion into the queue database 48 and the processed by the adjudication engine 38 and/or payment engine 40 at specified periodic intervals.
- the process 68 queries a scheduled bill table of the database 62 to confirm which bills should be processed on a periodic cycle, such as a daily cycle, and build any confirmed bills using minimum bill data requirements for the bill queue of the queue database 48 .
- the process 68 extracts scheduling data from the database 62 , and then decides whether to hold the bills pertaining to the scheduling data for future action or to populate the bill queue of the queue database 48 with the extracted scheduling data.
- This population of the queue table permits adjudication of the associated bills in sequence through a query process 70 as described below.
- the workflow engine 36 coordinates the query process 70 , which queries all bills in the database 48 ready for adjudication, both direct and predictive based.
- the process 70 will create an 837 flat file containing all bills obtained from the database 48 , and then transfer the 837 file to the adjudication engine 36 for processing.
- the adjudication engine 36 creates an adjudication results file, such as an acknowledgement 997 flat file, which is then reviewed by an update process 72 to determine the degree of success/failure of each bill adjudication.
- the update process 72 also transfers the success/failure details of the 997 file to the status database 50 , for subsequent review through the interfaces 12 , 14 .
- the update process 72 would also insert payment details from the payment engine 40 , related to the success/failure details of the 997 file.
- the workflow engine 36 also coordinates a purge process 74 to purge bills from the queue database 48 and the scheduling database 62 if needed.
- the process 74 will purge all successfully processed bills from the queue database 48 and all bill schedules from the schedule database 62 that have passed their end date.
- the bill tables of the queue database 48 and the scheduling database 62 along with the query process 70 and the schedule process 68 provides an extraction and processing loop for bills of a predictive nature as entered into the integrated database 26 through the predictive interface and/or the LMR interface 56 .
- the service provider interface 14 has four sub-interfaces, namely an initiate LMR bill interface 76 , an initiate bill interface 78 , a bill submission search interface 80 , and a void bill interface 82 .
- the interfaces 76 , 78 , 80 , 82 allow the providers 20 (see FIG. 2 ) to directly manage electronically their bill submission and results relating to insurance claims of the workers 22 .
- the interface 76 allows the providers 20 to submit bills for payment processing using an electronic version of an LMR provider invoice, such as an electronic version that conforms to an EDI claim import (ASCX12N 837) format.
- the interface 78 allows the providers 20 to submit bills for payment processing using the electronic version of a provider payment request, such as for example the electronic version conforming to the claim import (ASCX12N 837) format.
- the interface 80 allows the providers 20 to execute enquiries on their bill submissions and draft bills resident on the integrated database 26 . These enquiries can include bill detail, bill history, as well as the status of bill payment submissions. Preferably for processing efficiency, real time confirmation of submissions and payment status information may not be supported, and payment detail may only be available as per a check run schedule implemented by the payment engine 40 .
- the interface 82 allows the providers 20 to manage their bill submissions through void bill actions.
- the interface 82 will support same day avoidance submissions only. Capability could also be included in the system 10 to cancel previously submitted bills once they have been removed from the bill queue in the queue database 48 for adjudication by the adjudication engine 38 . Accordingly, the interfaces 76 , 78 , 80 , 82 allow the providers 20 to capture bill detail, save draft bills, export bill detail to the adjudication engine 38 , void bill submissions, and query bill detail and payment status.
- the interface 78 has functionality defined by the provider procedures 44 .
- the interface 78 has a bill details function 84 of the procedure 44 , which allows the providers 20 to initiate payment requests that are subject to invalid data, create payment requests and save submissions, create payment requests and exit submissions, create and submit payment requests subject to an incompletion, and successfully create and submit payment requests.
- the bills are submitted in response to the providers 20 performing or otherwise providing service, treatment, or products to the workers 22 .
- the workers 22 claims are established with the management agency 24 prior to submitting the bills, and the worker/claim entitlement information has been previously loaded into the adjudication engine 38 and the integrated database 26 .
- the result of the details function 84 is either a payment request saved as a draft for future submission or a payment request that is submitted for processing through the interface 14 to the integrated database 26 . Further, the providers 20 can use a combination of claim/worker data to submit the bill requests. It is recognized that the details function 84 , and other functions as described below, could be represented as software modules for use by the support system 1 .
- a first operation of the function 84 is to indicate that a combination of claims/worker data 89 , 91 in the payment request inputted by the provider 20 is invalid.
- the function 84 provides a submit bill menu 86 to the provider 20 , whereby the provider 20 enters a claim number in conjunction with worker/patient 22 profile data 91 (see FIG. 5 ), such as date of accident, surname, given name, and date of birth, when completed for submission to initiate the payment request.
- Other claim data 88 includes service codes, modifiers, ICD-9 codes, date of service, place of service, units, and dollar amounts. In this instance, the profile or claim data 88 is determined to be invalid by the provider procedures 44 and the provider 20 is notified the claim/patient information is invalid.
- the error could be the result of the combination of data 88 , 89 , 91 being invalid (e.g. wrong claim/worker combination), the claim number (record) not existing in the integrated database 26 (i.e. the claim has not yet been approved/fed into the appropriate components of the system 10 ), and/or a typographical error on the part of the provider 20 when keying in the requisite validation information included in the data 88 , 89 , 91 .
- the invalidation process of the provider procedures 44 provides a validation mechanism in order for the provider 20 to proceed with the payment request submission.
- the provider 20 is given choices to continue with the request session on the interface 14 .
- Another operation of the function 84 is to create the payment request and then save the submission in draft for future editing/submission.
- the provider 20 navigates on the interface 14 to the bill submission component of the menu 86 and selects the submit payment request submenu option.
- the provider 20 then enters the data 88 , 89 , 91 and submits to initiate the payment request.
- the provider 20 confirms patient 22 /provider 20 profile information 87 , 91 and defines the bill line item information 88 , such as date of service, service code and charge.
- the provider 20 then saves the payment request without submitting the bill to the integrated database 26 . For example, a warning message could be displayed on the interface 78 advising the provider 20 that the payment request is being saved without submitting the bill to the integrated database 26 .
- the provider 20 can then retrieve and submit the bill related to the saved payment request at a later date, or can delete the draft bill via the void bill interface 82 as further explained below.
- the providers 20 have the ability to input a provider specific invoice as a payment request to the integrated database 26 .
- the data 88 can contain multiple bill line items on a per claim basis, which indicates the specific dates of service for each line and applicable modifiers (for equipment) of the requests. The provider is given further choices to proceed with the request session on the interface 14 .
- a further operation of the bill detail function 84 is for the provider 20 to create and exit without saving or submitting the payment request. Accordingly, the provider 20 navigates on the interface 14 to the bill submission component of the menu 86 and selects the submit payment request submenu option. The provider then enters a claim number in conjunction with patient profile data 91 and submits to initiate the payment requests. The provider 20 also confirms the patient 22 /provider 20 profile information 87 , 91 and defines the bill line item information 88 , however, then proceeds to exit the request without saving or submitting the bill. Accordingly, the function 84 displays a warning message advising the provider 20 that the request is being exited without saving or submitted. The provider is given further choices to proceed with the request session on the interface 14 .
- a further operation of the function 84 is to initiate interaction with the provider 20 when creating the payment request, where some of the required data 87 , 88 , 89 , 91 is incomplete. Accordingly, the provider 20 selects the submit payment request from the menu 86 provided by the interface 14 , enters the claim number in conjunction with the patient profile data 91 and submits to initiate the payment request. The provider also confirms the patient 22 /provider 20 profile information 87 , 91 and defines the bill line item information 88 . The provider 20 then proceeds to submit the payment request, however, a warning prompt appears informing the provider 20 that the required information is incomplete and that the payment request will not be dispatched for the current claim. The provider is given further choices to proceed with the request session on the interface 14 .
- Another operation of the function 84 is for a provider 20 to create and submit a complete payment request.
- the provider 20 Once the provider 20 has entered the claim number in conjunction with the patient profile data 91 , and confirmed the patient 22 /provider 20 profile information 87 , 91 and bill line item information 88 , the provider procedures 44 check that all of the required information is correct and then provides the provider 20 with a confirmation prompt informing that the bill will be dispatched to the integrated database 26 for payment processing. Accordingly, the provider 20 can select OK and the bill will be submitted for processing, can select CANCEL and then edit or otherwise discard the payment request, or if the payment request has been submitted the provider 20 can retrieve from the integrated database 26 the particular payment request and void the related bill. It is also recognized that a popup search box for the selection of primary service provides (POS), representing a list of providers 20 enrolled for use of the system 10 , is accessible by the function 84 for completing the payment request.
- POS primary service provides
- Labour Market Re-entry (LMR) bill interface 76 of the general provider interface 14 enables LMR providers 20 to submit LMR invoices to the management agency 24 for payment via electronic submission provided by the system 10 .
- the LMR bills are for service, treatment, or products provided/performed by the provider 20 according to an approved LMR plan as accommodated for in the integrated database 26 and the adjudication engine 38 .
- the approved LMR plan includes a budget amount relating to the types of service, treatment, and/or product provided or performed by the provider 20 . Each of the types is referred to as a line of service.
- UR utilization rules
- the rules database 64 have been loaded by the work flow engine 36 into the adjudication engine 38 prior to submission of the LMR invoice.
- the provider procedures 44 contain an LMR bill detail function 92 for coordinating the creation and submission of LMR invoices (payment requests). It is noted that the LMR providers 20 can identify the combination of claim/patient profile information 89 , 91 to proceed with a payment request submission through the validation mechanism, as described above in relation to the function 84 . Further, the LMR providers 20 can submit multiple lines of service as bill line items 88 on a per claim basis and can identify an SSP for each of the lines of service. Further, the LMR providers 20 also indicate specific dates of service for each line of service included in the data 88 as well as indicating applicable modifiers (for equipment) in the LMR invoices.
- the function 92 also allows the LMR provider 20 to identify the secondary service provider (SSP) for which the bill line items 88 apply. Preferably, only one SSP is identified per bill and all line items 88 are associated accordingly. Further, the function 92 also operates with a search popup page 94 , which is supplied to the provider 20 through the interface 76 . The popup page 94 : the provider 20 to search and select appropriate SSPs. In addition, further popup pages of an expense code 96 and an ICD-9 98 can be provided by the function 92 to the interface 76 to allow the provider 20 to clarify and confirm portions of the data 88 corresponding to expenses and ICD-9 information.
- SSP secondary service provider
- the function 92 also allows the provider to select OK for submitting the LMR invoice for processing, selecting CANCEL and/or EDIT discard features for the LMR invoice, and if the invoice has been previously submitted the provider 20 can retrieve and void the invoice. Further, more than one SSP can be selected through the popup page 94 to be included in the LMR invoice.
- the sub-interface 82 of the general provider interface 14 enables the providers 20 , both payment requests and LMR invoices, to cancel bill submissions and/or draft bills. It should be noted, for batch mode operation of work flow engine 36 the voiding of bills may only be available for same day cancellations, or any other period specified for the batch mode. It is assumed that prior to accessing the VOID bill page interface 82 , the provider 20 has already submitted the bill payment request, saved as a draft the bill payment request, and/or has decided to proceed with a same day (or other period) review/cancellation process.
- the provider procedures 44 allow the provider 20 to navigate to the VOID bill submission interface 82 , whereby the provider 20 selects the draft or submitted bill to be cancelled via a check box (for example, “Void bill ?”) and the submit a VOID request (for example by a “Void selected” button). See scenarios below discussed users guide and example screens for the interfaces 14 , 76 , 78 , 80 , 82 . It should be noted that multiple bills can be voided simultaneously through the VOID interface 82 .
- a confirmation message is displayed on the interface 82 to the provider 20 thereby informing the provider 20 that the selected bills will be cancelled.
- the provider 20 is given the option to select OK for the bills to be cancelled or to select cancel so that the VOID selections will be cleared and therefore not voided from the integrated database 26 , through operation of the process 74 implemented by the work engine 36 .
- the bill submission search interface 80 of the general provider interface 14 enables the providers 20 , for both payment requests and LMR invoices, to investigate the adjudication and payment status of bills submitted to the integrated database 26 .
- the bill submission search interface 80 has a bill submission search results function 100 as part of the provider procedures 44 .
- the function 100 allows the provider 20 to retrieve bills/payment details from the databases 48 , 50 of the integrated database 26 by a variety of search parameters, such as claim-invalid, claim number-valid, date range-invalid, data range-valid, status-invalid, status-valid, claim number and date range, and status and claim number. It is further recognized that other combinations of search parameters, including or excepting those above, can also be used for treating the bill/payment details from the integrated database 26 . It is noted that SDT inquiry functionality and design can be leveraged for the provider 20 inquiry implemented by the interface 80 .
- the 16 search function 100 co-ordinates the display of either a bill details page 102 or a payment details page 104 on the search interface 80 .
- Operation of the function 100 is initiated when the provider 20 navigates to the bill payment inquiry component of the menu 86 of the general interface 14 (see FIG. 4 ).
- the provider 20 enters a claim number to filter the claims by and then submits. However, in one case the claim number entered may be invalid, and therefore an error message is displayed on the interface 80 by the search function 100 informing the provider 20 that no bill exists for that claim.
- the provider 20 can then select different claim numbers or parameters and then re-submit. Accordingly, the provider 20 can investigate adjudication results and payment details for submitted bills.
- An alternative to the above operation is when the provider 20 enters the claim number to filter the claims by, which contains a valid claim number, and therefore a list of bills is provided by the function 100 for the appropriate claim number for display on the interface 80 .
- the interface 80 can display the inquiry results as the bill detail page 102 , the payment detail page 104 , or a combination of both. Further, upon the inquiry for a valid claim number, the provider 20 can narrow the search by the finding/modifying additional criteria. As well, the provider 20 can select a particular bill (such as a link pertaining to a particular bill ID) to be viewed in greater detail. Accordingly, the function 100 interacts with the bill detail function 84 or the LMR bill detail function 92 to retrieve the requested bill detail. Alternatively, the provider 20 can select a paid amount (such as a link for a particular payment) to be viewed in detail. The function 100 can then interact with the bill detail function 84 or the LMR bill detail function 92 to retrieve required details for display on the bill detail page 102 or the payment detail page 104 on the interface 80 .
- a particular bill such as a link pertaining to a particular bill ID
- the function 100 interacts with the bill detail function 84 or the LMR bill detail function 92 to retrieve the requested bill detail.
- a further operation of the search function 100 allows the provider 20 to retrieve bills/payment detail information by date range.
- the provider 20 enters a start/end date range or uses a calendar control to select a date to refine the search results by, and submits through the interface 80 .
- the search function 100 then checks the date range against the bill details stored in the databases 48 , 50 , and for example can return with an invalid date range entered by displaying an error message on the interface 80 informing the provider 20 that no bills exist in the integrated database 26 for the date range selected.
- the provider 20 can then select a different date range or parameter and re-submit on the interface 80 through the search function 100 .
- An alternative to the above is when the date range entered by the provider 20 is considered valid by the search function 100 .
- a list of bills previously submitted by the provider 20 for the date range parameters selected is displayed on the interface 80 .
- the provider 20 can narrow the search by defining/modifying additional criteria and can select either a particular bill and/or a particular paid amount to be viewed in greater detail. It should be recognized that multiple bill/payment details can be accessed through the general interface 14 simultaneously, as long as they correspond to the selected search criteria submitted through the interface 80 to the search function 100 .
- a further operation of the search function 100 is retrieving bill/payment detail information by status.
- the provider 20 selects the status range to filter submitted/draft bills by and then submits this to the search function 100 .
- the search function 100 then proceeds to review the contents of the databases 48 , 50 . If the status selected is invalid, then an error message is displayed on the interface 80 informing the provider 20 that no bills exist for the status selected.
- the provider 20 can then select a different status or other parameter and re-submit the new search criteria to the search function 100 .
- An alternative to the above is when the status criteria are considered valid by the search function 100 . In this case, the status selected produces a list of bills matching the selected status, subsequently displayed on the search interface 80 .
- the provider 20 can then narrow the search by defining/modifying addition search criteria and/or can select particular bills and/or paid amounts to be viewed in greater detail.
- a further operation of the search function 100 is to retrieve bill/payment detail information from the databases 48 , 50 by claim number and date range. Accordingly, the provider 20 enters a start/end date range to refine the search results and then enters a claim number to filter the claims by and then submits the search request to the search function 100 .
- the search function 100 searches through the databases 48 , 50 , and if valid, provides a list of bills previously submitted by the provider 20 for a given claim during the date range parameters specified for display on the interface 80 . As noted above, the provider 20 can narrow the search further by defining/modifying additional criteria.
- Another operation is that the provider 20 can retrieve bills/payment detail information by specifying status and date range. Accordingly, the provider 20 enters into the interface 80 a start/end date.
- the search function 100 retrieves the matching bills, if valid, from the databases 48 , 50 with a selected status during the date range parameters for display on the interface 80 .
- the provider 20 can then narrow the search by defining/modifying additional criteria as noted above.
- a further operation of the search function 100 is to retrieve bill/payment detail information by status and claim number.
- the provider 20 enters a claim number to filter claims by and submits and selects a status range to filter submitted/draft bills by and submits.
- the claim number/status criteria is searched by the search function 100 in the databases 48 , 50 to provide a list of bills usually submitted by the provider for a given claim during the given status for display on the interface 80 .
- the provider 20 can narrow the search by defining/modifying additional criteria.
- a further operation of the search function 100 is to retrieve a saved payment request, modify the bill detail, and the submit to the integrated database 26 for payment processing through the work flow engine 36 .
- This operation can be done by the provider 20 when bills have been created and saved for future processing. Accordingly, the provider 20 navigates to the bill/payment enquiry component of the menu 86 and then proceeds to enter a combination of search parameters to retrieve a list of bills (both active and pending).
- the parameters can include claim number, bill status, data range, and provider information.
- the provider 20 can then select from the list displayed on the interface 80 a particular bill with a status of pending. The details of the pending bill are displayed on the interface 80 and the provider 20 can make any necessary changes/additions of the draft bill.
- the provider 20 is then given the opportunity to submit the payment request, if the bill request is now complete, and then a confirmation prompt can appear on the interface 80 informing the provider 20 that the bill will be dispatched to the management agency 24 for payment processing.
- the provider 20 can select OK and the bill will be submitted to the integrated database 26 for processing, can select CANCEL and thereby edits/discard the bill, or if the bill has been submitted previously the provider 20 can retrieve and void the bill using the void interface 82 .
- the scenarios 1, 2, 3, and 4 demonstrate the ability to provide multiple bill line items per claim for display on the appropriate interface 14 , 76 , 78 , 80 , 82 , and the interaction of popup boxes for service code searches, date of service selections, LMR expense codes, and provider searches.
- the enquiry and void scenarios allow the retrieval and subsequent selection of multiple bills per page, as displayed on the appropriate interface 80 , 82 , to facilitate easy of selection by the provider 20 .
- an application user guide is provided for the LMR submission interface 76 , the bill submission search interface 80 and void interface 82 , appropriate either to LMR and/or bill payment requests. It should be noted, that the user guide explains further functionality of the system 10 such as printing a screen with bill information 18 contained thereon, and system 10 login for providers 20 part of a provider database having access to the system 10 . It should be noted that registry opportunities for an unregistered provider 20 is also presented on the general provider interface 14 . It should be noted that the user guide should be considered as one example of system 10 application to a specific management agency 24 . Accordingly, some of the required criteria for entry into the data fields as displayed on the interfaces 14 , 76 , 80 may be other than those shown.
- the web specification gives examples of the controls listed in the tab sequence of the menu 86 and sub menus thereto, as well as the actions or events required on the various pages displayed on the interfaces 14 , 76 , 78 , 80 , 82 to initiate the corresponding listed responses. Further, the web specification also includes example data elements and data validation parameters.
- the LMR workflow 199 is shown between the worker 22 , the management agency 24 , and primary (PSP) and secondary (SSP) service providers.
- the worker 22 submits a plan request 200 to the management agency 24 .
- the management agency uses an adjudicator 24 a to compose a plan referral 202 , which is sent to a selected provider PSP.
- the PSP accepts the referral 202 and submits a completed or proposed plan 204 back to the management agency 24 .
- the completed or proposed plan 204 includes a listing of expenses with corresponding SSPs, dollar amounts, start dates, and end dates.
- the adjudicator 24 a in conjunction with a health care professional 24 b reviews the plan and submits the approved plan 206 back to the PSP.
- the PSP can then sub-contract out portions 208 of the plan 206 to a number of SSPs. It is noted that there may be situations in which the plan 204 requires amendment and the referral 202 may be declined, as further described below. Further, once the approved plan 206 is confirmed, a rule set 210 is sent by the management agency 24 into the rules database 64 (see FIG. 2 ), which eventually is inserted into the adjudication rule set of the adjudication engine 38 . The rule set 210 is used to identify whether bills are payable under the approved plan 206 by testing the bills against the rules.
- the rules include that the SSP on the bill is the same as the SSP on the line of service, that the date of service of the bill in within the range for the corresponding entry in the plan, and that the amount of the bill is less than the amount remaining in the plan budget for the corresponding line of service.
- the PSP and SSP have access through the interface 14 (see FIG. 2 ) to the integrated database 26 , for subsequent inquiry of the approved plan 206 as it is processed through the system 10 .
- the approved plan 206 enables the management agency 24 to pre-approve a group of bills associated with the particular LMR plan 206 .
- the LMR workflow 199 is designed to assist the workers 22 who have injuries that prevent a return to work with the accident employer.
- the management agency 24 partners with the providers PSP, SSP to deliver skills acquisition and training programs.
- the management agency participates in the workflow 199 by initiating referrals 202 , approving plans 206 , monitoring programs, and helping to pay bills associated with the approved plans 206 through payors (not shown) who provide payment as specified by the payment engine 40 (see FIG. 2 ).
- the referrals 202 mark the starting point for the LMR workflow 199 , as the worker 22 receives LMR services preferably through the referral 202 from the management agency 24 to the provider PSP.
- the provider PSP submits the proposed plan 204 to the adjudicator 24 a who then indicates approval or requests changes. Once the plan is approved, the approved plan 206 provides the details needed to adjudicate LMR bills.
- bills can be submitted by the providers PSP, SSP to the IDB 26 (see FIG. 1 ) and paid according to the details in the plan 206 , as further described below.
- the providers PSP, SSP incur costs in performing the LMR plan 206 for the worker 22 .
- the providers PSP, SSP can then submit their bills through the interface 14 to the IDB 26 for their own expenses and for expenses incurred on behalf of the worker 22 .
- the LMR bills are adjudicated by the adjudication engine 38 (see FIG. 2 ) and payment is determined by the payment engine 40 according to the rules established 210 previously upon plan approval. LMR bills that fall within entries in the plan and match plan requirements are approved by the adjudication engine 38 for payment.
- the rules 210 verify that the bills fall within the date requirements and budget requirements of the plan. Other bills are sent to a person for a manual check of the bill's eligibility for payment.
- a send referrals process 212 starts 214 where the adjudicator 24 a creates 216 the LMR referral 202 (see FIG. 6 ).
- the adjudicator 24 a submits 218 the referral 202 for review by the nurse case manager 24 b , who completes 220 the review and returns 222 the referral 202 to the adjudicator 24 a .
- the adjudicator 24 a receives 224 the referral 202 and sends 226 the referral 202 to the provider PSP, who can retrieve 228 the referral from the interface 14 (see FIG. 1 ) of the system 10 .
- the provider PSP accepts 230 the referral 202 , then the referral 202 is assigned 232 to a consultant of the provider PSP to generate 234 the proposed plan 204 . Further, the adjudicator 24 a is notified 236 that the referral 202 has been accepted and the referral process 212 ends 238 . Otherwise, the provider PSP declines 242 the referral and an alternate provider PSP is selected 244 . This selection 244 continues until acceptance 236 is confirmed.
- the referral process 212 can automatically select the provider PSP from the provider database 32 (see FIG. 1 ).
- a selection algorithm 246 accesses 248 the database 32 through a plurality of selection criteria 250 .
- the selection criteria 250 can include postal code matching 252 of the provider PSP and the worker 22 (geographic specific), provider expertise 254 , provider selection frequency 256 for distributing a number of referrals among a group of eligible providers PSP, or any other combination of the above. It is recognized that other selection criteria can be used, if desired.
- the adjudicator 24 a or other system administrator can override 260 the selection. It is also possible that the adjudicator 24 a manually selects the provider PSP for the referral 202 .
- an example referral 202 is shown, including worker 22 details, employment profile, physical precautions, referral details, as well as provider details that can be determined by the algorithm 246 (see FIG. 8 ). 10
- a manage plans process 262 starts from the previous step 234 of the referral process 212 .
- the provider PSP creates 264 the proposed plan 204 (see FIG. 6 ) and submits it through the interface 14 (see FIG. 1 ) to the management agency 24 .
- the agency 24 receives 266 the proposed plan 204 .
- the agency 24 determines 268 a value for the proposed plan 204 and then sends payment 270 to the provider PSP for the plan set-up and what level of assessment has already been completed with the worker 22 . Further, the agency 24 also reviews 272 the proposed plan 204 for suitability.
- the adjudication rules 210 are determined and sent to the rules database 64 for subsequent use in adjudicating LMR plan bills associated with the approved plan 206 .
- the provider PSP is notified 276 of the approval. Otherwise, the plan 204 is declined and amended 274 , and the provider PSP is notified 278 that changes are required before final approval.
- the provider PSP modifies the plan 204 and resubmits 280 it for approval. This change process can continue until the plan 204 is finally approved 274 .
- Further activities by the provider PSP and management agency 24 for the process 262 include the provider PSP viewing the status of the submitted plan 204 , 206 , the provider PSP submitting plan 206 amendments as necessary after approval, the provider PSP viewing the balance remaining on approved plans 206 , and the agency 24 changing the status of the plans 204 , 206 (i.e. cancel, suspend, reactivate).
- the rules 210 are also updated to reflect the changes.
- all versions of the plans 204 , 206 can be stored in the IBD 26 (see FIG. 2 ) for referral by the agency 24 to help in subsequent analysis of the plans 204 , 206 .
- the process 212 creates and sends the referral 202 to a selected provider PSP, who then either accepts or declines. Notification of the acceptance/decline status is given to the agency 24 . Further, it should be recognized that once the initial referral 202 is created, all subsequent status information of the referral 202 is stored in the IDB 26 (see FIG. 2 ) for review by interested parties of the system 10 through the interfaces 12 , 14 . Following acceptance of the referral 202 , the provider PSP prepare and submit the proposed plan 204 , which can consist of information pre-populated from the referral 202 , an indication of the level of assessment completed with the worker, as well as details outlining the proposed program of care.
- the referring adjudicator 24 a receives notification of the plan 204 and initial payment is given to the provider PSP base on the indication of the level of assessment completed. Therefore, it should be noted that the rules 210 are used by the adjudication engine 38 (see FIG. 2 ) to process the remaining level of assessment of the approved LMR plan 206 on a predictive basis.
- the adjudicator 24 a indicates initial adjudication results on the proposed plan 204 , and have the option of either approving the plan 204 or requesting changes.
- the approved plan 206 triggers through the workflow engine 36 (see FIG. 2 ) the creation and submission of the payment rules 210 into the adjudication engine 38 . These results are also accessible through the interfaces 12 , 14 for interested parties.
- the providers PSP can also request amendment of the approved plan 206 , however, preferably the initial level of assessment remains static. If amended, the adjudicator 24 a is notified of the amendments and the amended plan 206 must be reapproved. It should be noted that the status and details of the amended plan 206 are stored in the IDB 26 (see FIG.
- the rules 210 are triggered for change and reinserted into the adjudication engine 38 . Accordingly, the revised rules 210 replace the previous rule set 210 .
- the adjudicators 24 a can change the status of the plan 206 at any time, such as to suspension or cancellation. This change in status is recorded in the IDB 26 , as well as revised in the rules 210 to deactivate the payment associated with the plan 206 . Conversely, the adjudicators 24 a can also reactivate the plan 206 , if suspended or cancelled, which will also trigger the revision of the rules 210 to reactivate the payment rules associated with the plan 206 .
- the interfaces 12 , 14 can be used by interested parties (i.e. agency 24 members and providers PSP) to inquire about the status and other details concerning referrals 202 and plans 204 , 206 , as well as the actual dollar amounts approved/paid against the plan 206 .
- interested parties i.e. agency 24 members and providers PSP
- members of the agency 24 can override any provider PSP selection, change the PSP, view a series of referrals 204 against associated valid claim numbers, and view plans 204 , 206 and amendments for any valid claim number. Further, members of the agency 24 can also update LMR parameters of the system 10 , including the referral algorithm 246 operation, the selection criteria 250 , as well as expense codes and dollar limits used by the plans 204 , 206 .
- FIG. 15 an example creation or editing of the plan 204 , 206 is shown.
- An example plan 204 , 206 is shown in FIGS. 16 to 20 .
- the creation of the plan 204 , 206 includes:
- Section 1 Plan Header Tab (see FIG. 16 )
- Section 2 Payment Details Tab (see FIG. 17 )
- Section 3 Assessment Tab (see FIG. 19 )
- Section 4 CEW Tab (see FIG. 19 ) provides a summary of the various cost categories and Section 5: View Payments Tab (see FIG. 20 ) provides summary of approved amounts once the plan 204 has been submitted and then reviewed by the adjudicator 24 a (see FIG. 6 ).
- plan budget versus actuals In order to display the actual dollar amounts approved and/or paid against the plan 206 , the facility to create a report called plan budget versus actuals is provided within the reporting and monitoring module (see FIG. 1 ).
- the name “actuals” refers to the actual dollar amounts paid.
- the plan versus actuals report uses details of the plan described above and stored in the integrated database. The report also uses information on the amounts paid which are also stored in the integrated database.
- a report may be requested by a primary source provider (PSP) or by the labour management agency (LMA) 24 .
- PSP primary source provider
- LMA labour management agency
- the PSP or the LMA requests the plan versus actual report.
- the request includes a claim number as an indication of the plan of interest.
- the plan budget versus actual report provides a view of the entire plan including budgeted amounts compared to paid amounts.
- the system determines the latest approved plan at step 324 . Although the plan is the “latest approved plan”, the status of the plan may be “closed” or “expired” rather than “approved”.
- the system finds all paid bills for the claim indicated in the request at step 326 .
- the claim number and service code on each bill will determine which section the bill will be counted against.
- the system then aligns all the paid bills with the latest approved plan associated with the claim indicated in the request at step 328 .
- the aligning process uses the bill service code to align bills with plan lines according to their service codes.
- the bill date of service (DOS) can be outside of the date range defined for the plan line service.
- the bill secondary service provider (SSP) can be different from the SSP defined for the plan line service.
- This system then displays the report at step 330 .
- a sample report is shown at FIGS. 22 , 23 , and 24 .
- the report is displayed in two sections, namely, a header and a body.
- the header section includes the following information:
- Service Duration the earliest start date of a service in the plan to the latest end date of a service in the plan.
- Service duration can be outside the plan effective dates.
- the assessment section includes the services of transferable skill analysis, evaluation, and vocational evaluation.
- the report displays the service code and name of assessment services that have been paid automatically.
- the report also displays the code and name of the primary service provider associated with the auto-payment.
- the report shows the actual amount paid to the primary service provider. If no amount has been paid, then the message “no assessment” is displayed.
- the plan budget with actuals section of the report displays all services in the latest approved plan with the actual amounts paid for each service grouped by secondary service provider (SSP).
- the report includes the service code and name according to the latest approved plan.
- the status of the service can be “current”, “future”, “past” or “unallocated”.
- the status is “current” if the date is between the start date and end date of the plan line service.
- the “actuals” amount is the total of bills where the DOS is between the service start date and end date, the bill service is the same as the line service, and the bill SSP is the same as the line service SSP.
- the status is “future” if the date is before the start date of the plan line service.
- the “actuals” amount is the total of all bills where the bill DOS is between the service start date and end date, the bill service is the same as the line service, and the bill SSP is the same as the line service SSP.
- the status is “past” if the date is after the end date of the plan line service.
- the “actuals” amount is the total of all bills where the bill DOS is between the service start date and end date, the bill service is the same as the line service, and the bill SSP is the same as the line service SSP.
- the status is “unallocated” if the bill service is the same as the line service, and the bill SSP is not the same as the service SSP or the bill DOS is outside of the range defined by the start date and end date of the plan line service or both.
- the system calculates the balance remaining in the plan as the difference between the plan amount and the actual amount.
- the report includes a service total line which includes the total budget for that service and the actual amount paid for that service and the balance available for that service.
- the other payment section of the report displays all payments made for services that are not in the latest approved plan. This section of the report displays the service code and name for payments made for a service outside of the latest approved plan, the code and name of the service provider associated with the payment, and the actual not paid. If there is no such payments then a message is shown saying “no other payments were issued.”
- the total section of the report shows the actual amount paid for assessments, the plan amount, actual amount and balance for the plan budget with actual section, the total of other payments issued, and an overall total of all actual amounts paid for the claim.
- the predictive payment process 119 (see FIG. 6 ) is part of the system 10 .
- the recurring payment requests associated with the LMR plans 206 are used in the administration of worker 22 claims in order to support the bill adjudication 38 process.
- There are four major functions used in the system 10 and associated process 199 including creation of a predictive payment, the modification of a predictive payment, searching for existing predictive payments, and a bill generation process. These functions are coordinated through the interfaces 12 , 14 (see FIG. 1 ).
- the create predictive payment process involves the set up of one or many predictive payment requests by the rules 210 for the purposes of the predictive payment plan for the worker 22 claim.
- the modify predictive payment process involves the application of the administrative practices of a payor to the existing predictive plan structure they have defined for a worker 22 claim. These modifications may include the following changes: modify service code; modify frequency; modify payment amount; modify start and end dates; modify units (where applicable); and modify payee. These items are included in the LMR DB 64 (see FIG. 2 ) as the series of payment rules 210 , which are imported into the adjudication engine 38 once the plan is confirmed.
- the search process involves retrieving and displaying information about the predictive payment plan 206 for the worker 22 claim based upon user specified criteria through the interfaces 12 , 14 , which can be used to obtain up to date information on the status and activity of the plan 206 as stored in the IIDB 26 (see FIG. 2 ).
- the bill generation process involves the triggering of bill creation based on parameters defined during the predictive payment plan 206 maintenance (create and modify) processes. The bill generation process will apply logic through the workflow engine 36 and the adjudication and payment engines 38 , 40 so that recurring payment requests will occur, which are associated with the details of the approved plan 206 and corresponding rules 210 .
- the predictive payment plan 206 (or PPP) is a collection of one or more payment requests with corresponding payment parameters such as amount, frequency, start and end dates, which are then organized in a structure for the purposes of plan definition. From the plan definition the bill generation process will then be triggered to generate bills for specific payees as per the specified frequencies and start and end dates for the payment requests that are specified in the plan 206 .
- the PPP is comprehensive meaning that it will include all of the predictive payment requests that a worker 22 claim needs in order to be able to build plans 206 .
- the predictive payment plan 206 contains at least one predictive payment request and at least one payee.
- a Predictive Payment detail 300 includes the plan that interacts through a payee 302 with the predictive payment request 304 (embodied in the rules 210 , see FIG. 6 ).
- the payment request 304 identifies a service code 306 , frequency 308 , units 310 , amount 312 , and payment request start 314 and end 316 dates.
- the agency 24 will determine that the worker 22 claim is entitled to a Personal Care Allowance and will then set up a predictive payment request 304 by the rules 210 , which will allow a recurring payment to be sent to the specified payee 302 .
- the agency 24 can indicate during the creation process which Personal Care Allowance code the worker 22 will receive reimbursement for, the frequency for which the worker will receive reimbursement, the number of units, the amount of the reimbursement, and the start date and end date for the reimbursement period.
- the payee 302 identifies who will receive reimbursement for the predictive payment request or requests 304 .
- the agency 24 may indicate at the plan level the payee 302 if all the payment requests— 304 go to the same payee 302 or if there are multiple payees 302 per each payment request then the agency 24 can indicate the payee 302 for each individual payment request 304 .
- the payee may be the worker 22 , an equipment/service supplier (such as an SSP), the provider PSP, or any other third party.
- the bill generation process 400 applies logic through the workflow engine 36 at a predetermined time/schedule on a daily basis, for example, to retrieve predictive payment details (corresponding to the payment requests 304 of the plans 206 ) from the Bill Scheduling database 62 .
- the predictive bill data of the database 62 is reformatted by the workflow engine 40 and then inserted into the bill adjudication queue 48 , for eventual LMR bill 402 creation and submission into the adjudication engine 38 for adjudication.
- the adjudication of these LMR bills 402 provides the payment engine 40 with payment details, which are used to issue payment by the system 10 to the providers PSP in response to the predictive elements of the corresponding plan 206 .
- the process 400 uses the parameters of the payment request(s) 304 within the plan 206 to determine what data to insert into the payment bill entity.
- the process 400 also applies logic in order to determine the required number of bills to be generated based on the payee combinations for the predictive payment plan 206 , for example coordination of benefits (COB) that are part of the plan 206 as well as direct payment to the worker 2 and SSPs if desired.
- COB coordination of benefits
- the bill generation process 400 can use standard fields and values, such as the 837 EDI import process.
- the bill generation process 400 is run on a predefined frequency in order to pick up from the database 62 and send bill payment requests 304 that run on user defined anniversary dates, as well as being able to run on specific set dates.
- the trigger for the bill generation will be the parameters 306 , 308 , 310 , 312 , 314 , 316 in the predictive payment plan (see FIG. 25 ).
- the automatic generation of the LMR bills 402 involves the coordinated effort between the workflow engine 40 and the contents of the IDB 26 , as well as the procedures 70 , 72 , 74 , 68 as discussed above (see FIG. 2 ).
- the system 10 determines the start and end date of the suspension period and determines if during this time the corresponding bill 402 was not generated. For example, an activation date can be provided by the user to determine date range for bill generation for the suspended period. Preferably, if no activation period is supplied, the bill generation process 400 will assume that the reactivation period will be the full suspension 28 period.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Economics (AREA)
- Theoretical Computer Science (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
A system for coordinating the submission and processing of a bill according to predictive payment data of a plan. The system comprises a provider interface and an integrated database for receiving a predictive payment plan submitted from the provider interface. The system also has a predictive payment request of the plan storable in the database, the request including a plurality of predictive payment parameters. An adjudication engine is coupled to the integrated database, and an insertion function is used for inserting the predictive payment parameters, when stored in the database, into an adjudication rule set of the adjudication engine. The adjudication rule set is used for eventual adjudication of the predictive payment data, wherein adjudication of the predictive payment data results in the generation of the bill. The system also has a workflow engine coupled to the integrated database for coordinating the processing of the electronic bill and for updating the bill information in response to the bill processing. A management system is coupled to the integrated database for monitoring the contents of the integrated database accessible by the provider interface, wherein the provider can coordinate real-time retrieval of submission and status details for bill information contained in the integrated database.
Description
- This application is a continuation of U.S. patent application Ser. No. 11/797,316 filed May 2, 2007, which is a continuation of U.S. patent application Ser. No. 10/960,984 filed Oct. 12, 2004, which is a continuation of U.S. patent application Ser. No. 10/656, 265 filed Sep. 8, 2003, which is a continuation in part of U.S. patent application Ser. No. 10/277,205 filed Oct. 22, 2002, which claims the benefit of U.S. Provisional Patent Application No. 60/408,884 filed Sep. 9, 2002, all of which are herein incorporated by reference.
- The present invention relates to electronic bill submission and processing, and in particular to insurance claims corresponding to providers of insurance services.
- According to the present invention there is provided an electronic bill processing system for coordinating the submission and processing of an electronic bill corresponding to a provider of insurance services, the system comprising;
-
- a) a provider interface;
- b) an integrated database coupled to the provider interface for storing bill information pertaining to the electronic bill;
- c) a workflow engine coupled to the integrated database for coordinating the processing of the electronic bill and for updating the bill information in response to the bill processing; and
- d) a management system coupled to the integrated database for monitoring the contents of the integrated database accessible by the provider interface; wherein the provider can coordinate real-time retrieval of submission and status details for bill information contained in the integrated database.
- According to a further aspect of the present invention there is provided a method for coordinating the submission and processing of a bill according to predictive payment data of a plan. The method comprises the steps of:
-
- a) storing the predictive payment data corresponding to the plan in a database coupled to an adjudication engine;
- b) inserting a predictive payment parameter into a rule set of the adjudication engine for eventual adjudication of the predictive payment data at a predefined interval, the predictive payment parameter corresponding to a content of the plan;
- c) triggering a creation of the electronic bill at the predefined interval according to the predictive payment parameter;
- d) retrieving the predictive payment data from the database and providing the predictive payment data to the adjudication engine;
- e) updating the predictive payment parameter for recognizing the submission of the payment data to the adjudication engine; and
- f) generating the bill as defined by the predictive payment data of the plan once adjudicated.
- According to a still further aspect of the present invention there is provided a system for coordinating the submission and processing of a bill according to predictive payment data of a plan. The system comprises:
-
- a) a provider interface;
- b) an integrated database for receiving a predictive payment plan submitted from the provider interface;
- c) a predictive payment request of the plan storable in the database, the request including a plurality of predictive payment parameters;
- d) an adjudication engine coupled to the integrated database; and
- e) an insertion function for inserting the predictive payment parameters, when stored in the database, into an adjudication rule set of the adjudication engine, the adjudication rule set for eventual adjudication of the predictive payment data; wherein adjudication of the predictive payment data results in the generation of the bill.
- These and other features of the preferred embodiments of the invention will become more apparent in the following detailed description in which reference is made to the appended drawings wherein:
-
FIG. 1 is an electronic bill processing and management system; -
FIG. 2 is a component model of the system ofFIG. 1 ; -
FIG. 3 is a component model for a provider bill submission interface for the system ofFIG. 1 ; -
FIG. 4 is an example screen of the submission interface ofFIG. 3 ; -
FIGS. 5A , B is a further example screen of the interface ofFIG. 3 ; -
FIG. 6 shows a Labour Management Re-entry workflow of the system ofFIG. 1 ; -
FIG. 7 is a referrals workflow for the re-entry workflow ofFIG. 6 ; -
FIG. 8 shows a selection algorithm for the workflow ofFIG. 7 ; -
FIG. 9 is a manage plans workflow for the re-entry workflow ofFIG. 6 ; -
FIG. 10 shows a first graphical user interface for the workflow ofFIG. 7 ; -
FIG. 11 shows a second graphical user interface for the workflow ofFIG. 7 ; -
FIG. 12 shows a third graphical user interface for the workflow ofFIG. 7 ; -
FIG. 13 shows a fourth graphical user interface for the workflow ofFIG. 7 ; -
FIG. 14 shows a fifth graphical user interface for the workflow ofFIG. 7 ; -
FIG. 15 shows a workflow for creating a plan for the workflow ofFIG. 6 ; -
FIG. 16 shows a first graphical user interface for the workflow ofFIG. 9 ; -
FIGS. 17A , B shows a second graphical user interface for the workflow ofFIG. 9 ; -
FIG. 18 shows a third graphical user interface for the workflow ofFIG. 9 ; -
FIG. 19 shows a fourth graphical user interface for the workflow ofFIG. 9 ; -
FIG. 20 shows a fifth graphical user interface for the workflow ofFIG. 9 ; -
FIG. 21 shows a plan versus actuals report workflow for the system ofFIG. 1 ; -
FIGS. 22 , 23, and 24 show a plan versus actuals report according to the workflow ofFIG. 21 ; -
FIG. 25 shows the components of a predictive payment request for the system ofFIG. 1 ; -
FIG. 26 shows an interface for a predictive payment; and -
FIG. 27 is a bill generation workflow of the system ofFIG. 6 . - Referring to
FIG. 1 , an insurance bill electronic processing andmanagement system 10 hasuser interfaces network 16, such as the Internet,information 18 related to insurance bill submission and processing corresponding to insurance claims. Theuser interface 14, in the form of a web browser, facilitates electronic submission of thebill information 18 fromservice providers 20 to anintegrated database 26. Theintegrated database 26 stores thebill information 18 for record keeping. Theproviders 20 provide insurance related services toworkers 22 making the insurance claims. Management of the insurance services, provided by theproviders 20, is overseen by alabour management agency 24. Theagency 24 uses theuser interface 12 to manage the type and content of thebill information 18 contained within thedatabase 26, as well as coordinating overall processing and access of thebill information 18. It is recognized that theworkers 22 could also submit electronic bills through theinterface 14 with limited functionality. - The
system 10 supplements thebill information 18 withgeneral data parameters 28 obtained from aninsurance claim database 30, aprovider identification database 32, and an employers/workers database 34. Thedata parameters 28 are typically not specific to any one bill represented in thebill information 18, and include worker addresses, provider names and services, and insurance claim particulars. A workflow engine 36 (seeFIG. 2 ) manages the transfer of thebill information 18 and thedata parameters 28 between anadjudication engine 38 and apayment engine 40. Theadjudication engine 38 processes any bills, related to the insurance claims, resident in theintegrated database 26 to determine what portion of the bills, if any, should be paid out. Theadjudication engine 38 therefore receives bills from theproviders 20, adjudicates the provider bills according to business rules (including utilization rules), generates adjudication results for valid “complete” bills, and generates exception records for invalid “exception” bills. Thepayment engine 40 then directs payment of the adjudicated complete bills to afinancial institution 42 for subsequent payment to theproviders 20 and/orworkers 22. - Accordingly, the
bill information 18 includes details related to bill status, such as pending or approved, related claim data, and bill payment particulars. Theproviders 20 have real-time access through theinterface 14 to selectedbill information 18 contained within the integrateddatabase 26, corresponding to pre and post processing of the insurance claims and the related bills. Themanagement agency 24 determines the degree of access by theproviders 20 to thebill information 18 through the provider procedures 44 (seeFIG. 2 ), which defines the functionality of theprovider interface 14. Real-time accessibility of thebill information 18 resident on theintegrated database 26 facilitates self-management, by theproviders 20, of the bill processing history once the bills are submitted through theinterface 14 to theintegrated database 26. Therefore, theintegrated database 26 acts as a repository ofbill information 18 and payment information related thereto. - Referring to
FIG. 1 , themanagement agency 24 uses asupport system 1 for monitoring and setting up the electronic processing andmanagement system 10. Thesupport system 1 includes aprocessor 2 coupled to theinterface 12. Theprocessor 2 is coupled to adisplay 3 for displaying theinterface 12 and touser input devices 4, such as a keyboard, mouse, or other suitable devices. If thedisplay 3 is touch sensitive, then thedisplay 3 itself can be employed as theuser input device 4. A computerreadable storage medium 5 is coupled to theprocessor 2 for providing instructions to theprocessor 2 to instruct and/or configure the various components of thesystem 10, including the processes related to operation of theworkflow engine 36 andinterfaces system 10. The computerreadable medium 5 can include magnetic disks, magnetic tape, optically readable medium such as CD ROM's, and semi conductor memory such as PCMCIA cards. In each case, themedium 5 may take the form of a portable item such as a small disk, floppy diskette, cassette, or it may take the form of a relatively large or immobile item such as hard disk drive, solid state memory card, or RAM provided in thesupport system 1. It should be noted that the above listedexample mediums 5 can be used either alone or in combination. - Referring to
FIG. 2 , the functionality of theprovider interface 14 is controlled by theprovider procedures 44, which are predefined by themanagement procedures 46 according to the desired degree of accessibility to thebill information 18 resident on theintegrated database 26. Theprocedures 44 permit theproviders 20 through theinterface 14 to select bills, update bills, delete bills, and determine bill status once submitted to theintegrated database 26. Sub-databases of theintegrated database 26, directly accessible by theproviders 20 in real-time, are a billadjudication queue database 48 and a bill status database 50. Thequeue database 48lists bill information 18 including all bills (and corresponding bill details) awaiting adjudication, which preferably are both read and write accessible by theproviders 20. The status database 50lists bill information 18 including a pending status (bills undergoing adjudication), a result status (bill adjudication results), and/or a payment status (bill payment decision), which are preferably only read accessible by theproviders 20. Real-time inquiry of these bill statuses and queue are accessible (defined by the provider procedures 44) by theproviders 20 through theinterface 14, with detailed breakdowns of the adjudication and payment decisions determined by theadjudication engine 38 and thepayment engine 40. - Further referring to
FIG. 2 , themanagement user interface 12 allows themanagement agency 24 to make decisions on the operation of thesystem 10, as well as select, delete, update, and inquire on selected bills submitted by theproviders 20 and/orworkers 22. Theinterface 12 has a set of sub-interfaces of apredictive payment interface 54, labour market re-entry (LMR)interface 56, aconsultation payment interface 58, and aninquiry interface 60, which are controlled by themanagement procedures 46 as defined by themanagement agency 24. Themanagement agency 24 can also use theinterfaces provider procedures 44 andmanagement procedures 46. Themanagement agency 24 can use thepredictive interface 54 and theLMR interface 56 to define and create individual adjudication rules (utilization rules UR), related to specific codes (for example LMR codes), for insertion into the business rule set of theadjudication engine 38. - Referring again to
FIG. 2 , themanagement procedures 46 provide both read and write interaction of theinterfaces integrated database 26. Interaction between theinterfaces arrows 66, which allows for the sharing of billing data and review functionality between theinterfaces interfaces adjudication queue database 48 and the status database 50 as described above, with further capabilities such as editing the operation of the bill queue and amending the bill statuses. Theinterfaces bill scheduling database 62 and anadjudication rules database 64. Thescheduling database 62 contains data pertaining to bills removed from thequeue database 48 by theworkflow engine 36 for future processing, and/or data pertaining to predictive bills that are periodically inserted into thequeue database 48 by theworkflow engine 36 for processing by theadjudication engine 38 andpayment engine 40. Theadjudication rule database 64 contains adjudication rules created by theinterfaces workflow engine 36. It is recognized that data for bills related to LMR insurance claims could also be stored in thescheduling database 62. The degree of access for the read and write interaction of thedatabase management agency 24, depending upon the individuals' priority. The access to theintegrated database 26 from theinterfaces individual providers 20 and employees of themanagement agency 24, as well as state based features used as lock out features to permit sequential rather than parallel editing of thebill information 18 anddata parameters 28. - Referring again to
FIG. 2 , theworkflow engine 36 monitors the data content of the sub-databases 48, 50, 62, 64 according to themanagement procedures 46, as well as amendment of the rule set of theadjudication engine 38 by the contents of therules database 64. The data content of thedatabases bill information 18 and thedata parameters 28, which are supplied by themanagement agency 24, theproviders 20, and theworkers 22. Adjudication and payment details, generated by theadjudication engine 38 andpayment engine 40 respectively, are also coordinated by theworkflow engine 36 into and out of theintegrated database 26, as required. It is recognized that access of theinterfaces integrated database 26 is preferably in real-time. Further, access to theintegrated database 26 by theworkflow engine 36 is preferably in periodic or batch mode to facilitate processing efficiencies, such as providing lump sum payments toparticular providers 20 related to a plurality of adjudicated bills. However, real-time access of theworkflow engine 36 to theintegrated database 26, for adjudication and payment results, could also be done if desired. - Referring to
FIG. 2 , theworkflow engine 36 coordinates, through a defined gather/insert process 66 by themanagement procedures 46, the gathering of all adjudication rules from therule database 64 for insertion into theadjudication engine 38. Theworkflow engine 36 also coordinates ascheduling process 68 for creating bills from thescheduling database 62 contents, which are scheduled for insertion into thequeue database 48 and the processed by theadjudication engine 38 and/orpayment engine 40 at specified periodic intervals. Theprocess 68 queries a scheduled bill table of thedatabase 62 to confirm which bills should be processed on a periodic cycle, such as a daily cycle, and build any confirmed bills using minimum bill data requirements for the bill queue of thequeue database 48. Accordingly, theprocess 68 extracts scheduling data from thedatabase 62, and then decides whether to hold the bills pertaining to the scheduling data for future action or to populate the bill queue of thequeue database 48 with the extracted scheduling data. This population of the queue table permits adjudication of the associated bills in sequence through aquery process 70 as described below. - The
workflow engine 36 coordinates thequery process 70, which queries all bills in thedatabase 48 ready for adjudication, both direct and predictive based. For example, theprocess 70 will create an 837 flat file containing all bills obtained from thedatabase 48, and then transfer the 837 file to theadjudication engine 36 for processing. Theadjudication engine 36 creates an adjudication results file, such as anacknowledgement 997 flat file, which is then reviewed by anupdate process 72 to determine the degree of success/failure of each bill adjudication. Theupdate process 72 also transfers the success/failure details of the 997 file to the status database 50, for subsequent review through theinterfaces update process 72 would also insert payment details from thepayment engine 40, related to the success/failure details of the 997 file. Theworkflow engine 36 also coordinates apurge process 74 to purge bills from thequeue database 48 and thescheduling database 62 if needed. For example, theprocess 74 will purge all successfully processed bills from thequeue database 48 and all bill schedules from theschedule database 62 that have passed their end date. It should be noted that the bill tables of thequeue database 48 and thescheduling database 62, along with thequery process 70 and theschedule process 68 provides an extraction and processing loop for bills of a predictive nature as entered into theintegrated database 26 through the predictive interface and/or theLMR interface 56. - Referring to
FIG. 3 , theservice provider interface 14 has four sub-interfaces, namely an initiateLMR bill interface 76, an initiatebill interface 78, a billsubmission search interface 80, and avoid bill interface 82. Theinterfaces FIG. 2 ) to directly manage electronically their bill submission and results relating to insurance claims of theworkers 22. Theinterface 76 allows theproviders 20 to submit bills for payment processing using an electronic version of an LMR provider invoice, such as an electronic version that conforms to an EDI claim import (ASCX12N 837) format. Theinterface 78 allows theproviders 20 to submit bills for payment processing using the electronic version of a provider payment request, such as for example the electronic version conforming to the claim import (ASCX12N 837) format. Theinterface 80 allows theproviders 20 to execute enquiries on their bill submissions and draft bills resident on theintegrated database 26. These enquiries can include bill detail, bill history, as well as the status of bill payment submissions. Preferably for processing efficiency, real time confirmation of submissions and payment status information may not be supported, and payment detail may only be available as per a check run schedule implemented by thepayment engine 40. Theinterface 82 allows theproviders 20 to manage their bill submissions through void bill actions. For example, in the case of batch mode operation of theadjudication engine 38 and/or thepayment engine 40, theinterface 82 will support same day avoidance submissions only. Capability could also be included in thesystem 10 to cancel previously submitted bills once they have been removed from the bill queue in thequeue database 48 for adjudication by theadjudication engine 38. Accordingly, theinterfaces providers 20 to capture bill detail, save draft bills, export bill detail to theadjudication engine 38, void bill submissions, and query bill detail and payment status. - Referring to
FIG. 3 , theinterface 78 has functionality defined by theprovider procedures 44. In particular, theinterface 78 has a bill details function 84 of theprocedure 44, which allows theproviders 20 to initiate payment requests that are subject to invalid data, create payment requests and save submissions, create payment requests and exit submissions, create and submit payment requests subject to an incompletion, and successfully create and submit payment requests. It is understood that the bills are submitted in response to theproviders 20 performing or otherwise providing service, treatment, or products to theworkers 22. It is understood that theworkers 22 claims are established with themanagement agency 24 prior to submitting the bills, and the worker/claim entitlement information has been previously loaded into theadjudication engine 38 and theintegrated database 26. The result of the details function 84 is either a payment request saved as a draft for future submission or a payment request that is submitted for processing through theinterface 14 to theintegrated database 26. Further, theproviders 20 can use a combination of claim/worker data to submit the bill requests. It is recognized that the details function 84, and other functions as described below, could be represented as software modules for use by thesupport system 1. - A first operation of the
function 84 is to indicate that a combination of claims/worker data provider 20 is invalid. Referring toFIGS. 4 and 5 , thefunction 84 provides a submitbill menu 86 to theprovider 20, whereby theprovider 20 enters a claim number in conjunction with worker/patient 22 profile data 91 (seeFIG. 5 ), such as date of accident, surname, given name, and date of birth, when completed for submission to initiate the payment request.Other claim data 88 includes service codes, modifiers, ICD-9 codes, date of service, place of service, units, and dollar amounts. In this instance, the profile or claimdata 88 is determined to be invalid by theprovider procedures 44 and theprovider 20 is notified the claim/patient information is invalid. Accordingly, the error could be the result of the combination ofdata provider 20 when keying in the requisite validation information included in thedata provider procedures 44 provides a validation mechanism in order for theprovider 20 to proceed with the payment request submission. Theprovider 20 is given choices to continue with the request session on theinterface 14. - Another operation of the
function 84 is to create the payment request and then save the submission in draft for future editing/submission. Initially, theprovider 20 navigates on theinterface 14 to the bill submission component of themenu 86 and selects the submit payment request submenu option. Theprovider 20 then enters thedata provider 20 then confirms patient 22/provider 20profile information line item information 88, such as date of service, service code and charge. Theprovider 20 then saves the payment request without submitting the bill to theintegrated database 26. For example, a warning message could be displayed on theinterface 78 advising theprovider 20 that the payment request is being saved without submitting the bill to theintegrated database 26. Accordingly, theprovider 20 can then retrieve and submit the bill related to the saved payment request at a later date, or can delete the draft bill via thevoid bill interface 82 as further explained below. It should be noted, referring toFIG. 5 , that theproviders 20 have the ability to input a provider specific invoice as a payment request to theintegrated database 26. Thedata 88 can contain multiple bill line items on a per claim basis, which indicates the specific dates of service for each line and applicable modifiers (for equipment) of the requests. The provider is given further choices to proceed with the request session on theinterface 14. - A further operation of the
bill detail function 84 is for theprovider 20 to create and exit without saving or submitting the payment request. Accordingly, theprovider 20 navigates on theinterface 14 to the bill submission component of themenu 86 and selects the submit payment request submenu option. The provider then enters a claim number in conjunction withpatient profile data 91 and submits to initiate the payment requests. Theprovider 20 also confirms the patient 22/provider 20profile information line item information 88, however, then proceeds to exit the request without saving or submitting the bill. Accordingly, thefunction 84 displays a warning message advising theprovider 20 that the request is being exited without saving or submitted. The provider is given further choices to proceed with the request session on theinterface 14. - A further operation of the
function 84 is to initiate interaction with theprovider 20 when creating the payment request, where some of the requireddata provider 20 selects the submit payment request from themenu 86 provided by theinterface 14, enters the claim number in conjunction with thepatient profile data 91 and submits to initiate the payment request. The provider also confirms the patient 22/provider 20profile information line item information 88. Theprovider 20 then proceeds to submit the payment request, however, a warning prompt appears informing theprovider 20 that the required information is incomplete and that the payment request will not be dispatched for the current claim. The provider is given further choices to proceed with the request session on theinterface 14. - Another operation of the
function 84 is for aprovider 20 to create and submit a complete payment request. Once theprovider 20 has entered the claim number in conjunction with thepatient profile data 91, and confirmed the patient 22/provider 20profile information line item information 88, theprovider procedures 44 check that all of the required information is correct and then provides theprovider 20 with a confirmation prompt informing that the bill will be dispatched to theintegrated database 26 for payment processing. Accordingly, theprovider 20 can select OK and the bill will be submitted for processing, can select CANCEL and then edit or otherwise discard the payment request, or if the payment request has been submitted theprovider 20 can retrieve from the integrateddatabase 26 the particular payment request and void the related bill. It is also recognized that a popup search box for the selection of primary service provides (POS), representing a list ofproviders 20 enrolled for use of thesystem 10, is accessible by thefunction 84 for completing the payment request. - Referring to
FIG. 3 , Labour Market Re-entry (LMR)bill interface 76 of thegeneral provider interface 14 enablesLMR providers 20 to submit LMR invoices to themanagement agency 24 for payment via electronic submission provided by thesystem 10. The LMR bills are for service, treatment, or products provided/performed by theprovider 20 according to an approved LMR plan as accommodated for in theintegrated database 26 and theadjudication engine 38. The approved LMR plan includes a budget amount relating to the types of service, treatment, and/or product provided or performed by theprovider 20. Each of the types is referred to as a line of service. It is recognized that the utilization rules (UR) of therules database 64 have been loaded by thework flow engine 36 into theadjudication engine 38 prior to submission of the LMR invoice. Theprovider procedures 44 contain an LMRbill detail function 92 for coordinating the creation and submission of LMR invoices (payment requests). It is noted that theLMR providers 20 can identify the combination of claim/patient profile information function 84. Further, theLMR providers 20 can submit multiple lines of service asbill line items 88 on a per claim basis and can identify an SSP for each of the lines of service. Further, theLMR providers 20 also indicate specific dates of service for each line of service included in thedata 88 as well as indicating applicable modifiers (for equipment) in the LMR invoices. In addition to that described above for thefunction 84, thefunction 92 also allows theLMR provider 20 to identify the secondary service provider (SSP) for which thebill line items 88 apply. Preferably, only one SSP is identified per bill and allline items 88 are associated accordingly. Further, thefunction 92 also operates with asearch popup page 94, which is supplied to theprovider 20 through theinterface 76. The popup page 94: theprovider 20 to search and select appropriate SSPs. In addition, further popup pages of anexpense code 96 and an ICD-9 98 can be provided by thefunction 92 to theinterface 76 to allow theprovider 20 to clarify and confirm portions of thedata 88 corresponding to expenses and ICD-9 information. Accordingly, similar to thefunction 84, thefunction 92 also allows the provider to select OK for submitting the LMR invoice for processing, selecting CANCEL and/or EDIT discard features for the LMR invoice, and if the invoice has been previously submitted theprovider 20 can retrieve and void the invoice. Further, more than one SSP can be selected through thepopup page 94 to be included in the LMR invoice. - Referring to
FIG. 3 , thesub-interface 82 of thegeneral provider interface 14 enables theproviders 20, both payment requests and LMR invoices, to cancel bill submissions and/or draft bills. It should be noted, for batch mode operation ofwork flow engine 36 the voiding of bills may only be available for same day cancellations, or any other period specified for the batch mode. It is assumed that prior to accessing the VOIDbill page interface 82, theprovider 20 has already submitted the bill payment request, saved as a draft the bill payment request, and/or has decided to proceed with a same day (or other period) review/cancellation process. Accordingly, theprovider procedures 44 allow theprovider 20 to navigate to the VOIDbill submission interface 82, whereby theprovider 20 selects the draft or submitted bill to be cancelled via a check box (for example, “Void bill ?”) and the submit a VOID request (for example by a “Void selected” button). See scenarios below discussed users guide and example screens for theinterfaces VOID interface 82. Once the VOID request has been received by theintegrated database 26, a confirmation message is displayed on theinterface 82 to theprovider 20 thereby informing theprovider 20 that the selected bills will be cancelled. Theprovider 20 is given the option to select OK for the bills to be cancelled or to select cancel so that the VOID selections will be cleared and therefore not voided from the integrateddatabase 26, through operation of theprocess 74 implemented by thework engine 36. - Referring to
FIG. 3 , the billsubmission search interface 80 of thegeneral provider interface 14 enables theproviders 20, for both payment requests and LMR invoices, to investigate the adjudication and payment status of bills submitted to theintegrated database 26. For batch mode operation of thework flow engine 36, real-time confirmation of submissions and payment status information may not be supported. Moreover, payment detail may only be available as per a check run schedule as implemented by thepayment engine 40. Theinterface 80 has a bill submission search results function 100 as part of theprovider procedures 44. Thefunction 100 allows theprovider 20 to retrieve bills/payment details from thedatabases 48, 50 of theintegrated database 26 by a variety of search parameters, such as claim-invalid, claim number-valid, date range-invalid, data range-valid, status-invalid, status-valid, claim number and date range, and status and claim number. It is further recognized that other combinations of search parameters, including or excepting those above, can also be used for treating the bill/payment details from the integrateddatabase 26. It is noted that SDT inquiry functionality and design can be leveraged for theprovider 20 inquiry implemented by theinterface 80. The 16search function 100 co-ordinates the display of either a bill detailspage 102 or a payment detailspage 104 on thesearch interface 80. - Operation of the
function 100 is initiated when theprovider 20 navigates to the bill payment inquiry component of themenu 86 of the general interface 14 (seeFIG. 4 ). Theprovider 20 enters a claim number to filter the claims by and then submits. However, in one case the claim number entered may be invalid, and therefore an error message is displayed on theinterface 80 by thesearch function 100 informing theprovider 20 that no bill exists for that claim. Theprovider 20 can then select different claim numbers or parameters and then re-submit. Accordingly, theprovider 20 can investigate adjudication results and payment details for submitted bills. An alternative to the above operation is when theprovider 20 enters the claim number to filter the claims by, which contains a valid claim number, and therefore a list of bills is provided by thefunction 100 for the appropriate claim number for display on theinterface 80. Theinterface 80 can display the inquiry results as thebill detail page 102, thepayment detail page 104, or a combination of both. Further, upon the inquiry for a valid claim number, theprovider 20 can narrow the search by the finding/modifying additional criteria. As well, theprovider 20 can select a particular bill (such as a link pertaining to a particular bill ID) to be viewed in greater detail. Accordingly, thefunction 100 interacts with thebill detail function 84 or the LMRbill detail function 92 to retrieve the requested bill detail. Alternatively, theprovider 20 can select a paid amount (such as a link for a particular payment) to be viewed in detail. Thefunction 100 can then interact with thebill detail function 84 or the LMRbill detail function 92 to retrieve required details for display on thebill detail page 102 or thepayment detail page 104 on theinterface 80. - A further operation of the
search function 100 allows theprovider 20 to retrieve bills/payment detail information by date range. Theprovider 20 enters a start/end date range or uses a calendar control to select a date to refine the search results by, and submits through theinterface 80. Thesearch function 100 then checks the date range against the bill details stored in thedatabases 48, 50, and for example can return with an invalid date range entered by displaying an error message on theinterface 80 informing theprovider 20 that no bills exist in theintegrated database 26 for the date range selected. Theprovider 20 can then select a different date range or parameter and re-submit on theinterface 80 through thesearch function 100. An alternative to the above is when the date range entered by theprovider 20 is considered valid by thesearch function 100. In this case, a list of bills previously submitted by theprovider 20 for the date range parameters selected is displayed on theinterface 80. Accordingly, theprovider 20 can narrow the search by defining/modifying additional criteria and can select either a particular bill and/or a particular paid amount to be viewed in greater detail. It should be recognized that multiple bill/payment details can be accessed through thegeneral interface 14 simultaneously, as long as they correspond to the selected search criteria submitted through theinterface 80 to thesearch function 100. - A further operation of the
search function 100 is retrieving bill/payment detail information by status. Theprovider 20 selects the status range to filter submitted/draft bills by and then submits this to thesearch function 100. Thesearch function 100 then proceeds to review the contents of thedatabases 48, 50. If the status selected is invalid, then an error message is displayed on theinterface 80 informing theprovider 20 that no bills exist for the status selected. Theprovider 20 can then select a different status or other parameter and re-submit the new search criteria to thesearch function 100. An alternative to the above is when the status criteria are considered valid by thesearch function 100. In this case, the status selected produces a list of bills matching the selected status, subsequently displayed on thesearch interface 80. As note above, theprovider 20 can then narrow the search by defining/modifying addition search criteria and/or can select particular bills and/or paid amounts to be viewed in greater detail. - A further operation of the
search function 100 is to retrieve bill/payment detail information from thedatabases 48, 50 by claim number and date range. Accordingly, theprovider 20 enters a start/end date range to refine the search results and then enters a claim number to filter the claims by and then submits the search request to thesearch function 100. Thesearch function 100 then searches through thedatabases 48, 50, and if valid, provides a list of bills previously submitted by theprovider 20 for a given claim during the date range parameters specified for display on theinterface 80. As noted above, theprovider 20 can narrow the search further by defining/modifying additional criteria. Another operation is that theprovider 20 can retrieve bills/payment detail information by specifying status and date range. Accordingly, theprovider 20 enters into the interface 80 a start/end date. range to refine the search results, then selects a status range to filter submitted/draft bills by, and then submits the search request to thesearch function 100. Thesearch function 100 retrieves the matching bills, if valid, from thedatabases 48, 50 with a selected status during the date range parameters for display on theinterface 80. Theprovider 20 can then narrow the search by defining/modifying additional criteria as noted above. A further operation of thesearch function 100 is to retrieve bill/payment detail information by status and claim number. Theprovider 20 enters a claim number to filter claims by and submits and selects a status range to filter submitted/draft bills by and submits. For a valid combination the claim number/status criteria is searched by thesearch function 100 in thedatabases 48, 50 to provide a list of bills usually submitted by the provider for a given claim during the given status for display on theinterface 80. As noted above, theprovider 20 can narrow the search by defining/modifying additional criteria. - A further operation of the
search function 100 is to retrieve a saved payment request, modify the bill detail, and the submit to theintegrated database 26 for payment processing through thework flow engine 36. This operation can be done by theprovider 20 when bills have been created and saved for future processing. Accordingly, theprovider 20 navigates to the bill/payment enquiry component of themenu 86 and then proceeds to enter a combination of search parameters to retrieve a list of bills (both active and pending). The parameters can include claim number, bill status, data range, and provider information. Theprovider 20 can then select from the list displayed on the interface 80 a particular bill with a status of pending. The details of the pending bill are displayed on theinterface 80 and theprovider 20 can make any necessary changes/additions of the draft bill. Theprovider 20 is then given the opportunity to submit the payment request, if the bill request is now complete, and then a confirmation prompt can appear on theinterface 80 informing theprovider 20 that the bill will be dispatched to themanagement agency 24 for payment processing. Theprovider 20 can select OK and the bill will be submitted to theintegrated database 26 for processing, can select CANCEL and thereby edits/discard the bill, or if the bill has been submitted previously theprovider 20 can retrieve and void the bill using thevoid interface 82. - The following
outlines example interface scenarios appropriate interface appropriate interface provider 20. - Further, an application user guide is provided for the
LMR submission interface 76, the billsubmission search interface 80 andvoid interface 82, appropriate either to LMR and/or bill payment requests. It should be noted, that the user guide explains further functionality of thesystem 10 such as printing a screen withbill information 18 contained thereon, andsystem 10 login forproviders 20 part of a provider database having access to thesystem 10. It should be noted that registry opportunities for anunregistered provider 20 is also presented on thegeneral provider interface 14. It should be noted that the user guide should be considered as one example ofsystem 10 application to aspecific management agency 24. Accordingly, some of the required criteria for entry into the data fields as displayed on theinterfaces - Also provided in this disclosure is an example implementation of the
system 10 for provider bill submission UI web specification and error/warning messages. The web specification gives examples of the controls listed in the tab sequence of themenu 86 and sub menus thereto, as well as the actions or events required on the various pages displayed on theinterfaces - Referring to
FIG. 6 , theLMR workflow 199 is shown between theworker 22, themanagement agency 24, and primary (PSP) and secondary (SSP) service providers. Initially, theworker 22 submits aplan request 200 to themanagement agency 24. The management agency then uses anadjudicator 24 a to compose aplan referral 202, which is sent to a selected provider PSP. The PSP accepts thereferral 202 and submits a completed or proposedplan 204 back to themanagement agency 24. The completed or proposedplan 204 includes a listing of expenses with corresponding SSPs, dollar amounts, start dates, and end dates. Theadjudicator 24 a in conjunction with a health care professional 24 b reviews the plan and submits the approvedplan 206 back to the PSP. The PSP can then sub-contract outportions 208 of theplan 206 to a number of SSPs. It is noted that there may be situations in which theplan 204 requires amendment and thereferral 202 may be declined, as further described below. Further, once the approvedplan 206 is confirmed, arule set 210 is sent by themanagement agency 24 into the rules database 64 (seeFIG. 2 ), which eventually is inserted into the adjudication rule set of theadjudication engine 38. The rule set 210 is used to identify whether bills are payable under the approvedplan 206 by testing the bills against the rules. The rules include that the SSP on the bill is the same as the SSP on the line of service, that the date of service of the bill in within the range for the corresponding entry in the plan, and that the amount of the bill is less than the amount remaining in the plan budget for the corresponding line of service. - The PSP and SSP have access through the interface 14 (see
FIG. 2 ) to theintegrated database 26, for subsequent inquiry of the approvedplan 206 as it is processed through thesystem 10. It should be noted that the approvedplan 206 enables themanagement agency 24 to pre-approve a group of bills associated with theparticular LMR plan 206. It should also be noted that it is preferable that only the intended provider PSP have access to thereferral 202 through theinterface 14. - Referring again to
FIG. 6 , theLMR workflow 199 is designed to assist theworkers 22 who have injuries that prevent a return to work with the accident employer. Themanagement agency 24 partners with the providers PSP, SSP to deliver skills acquisition and training programs. The management agency participates in theworkflow 199 by initiatingreferrals 202, approvingplans 206, monitoring programs, and helping to pay bills associated with the approved plans 206 through payors (not shown) who provide payment as specified by the payment engine 40 (seeFIG. 2 ). Accordingly, thereferrals 202 mark the starting point for theLMR workflow 199, as theworker 22 receives LMR services preferably through thereferral 202 from themanagement agency 24 to the provider PSP. The provider PSP submits the proposedplan 204 to theadjudicator 24 a who then indicates approval or requests changes. Once the plan is approved, the approvedplan 206 provides the details needed to adjudicate LMR bills. - Once the
plan 204 has been approved, bills can be submitted by the providers PSP, SSP to the IDB 26 (seeFIG. 1 ) and paid according to the details in theplan 206, as further described below. The providers PSP, SSP incur costs in performing theLMR plan 206 for theworker 22. The providers PSP, SSP can then submit their bills through theinterface 14 to theIDB 26 for their own expenses and for expenses incurred on behalf of theworker 22. The LMR bills are adjudicated by the adjudication engine 38 (seeFIG. 2 ) and payment is determined by thepayment engine 40 according to the rules established 210 previously upon plan approval. LMR bills that fall within entries in the plan and match plan requirements are approved by theadjudication engine 38 for payment. Therules 210 verify that the bills fall within the date requirements and budget requirements of the plan. Other bills are sent to a person for a manual check of the bill's eligibility for payment. - Referring to
FIG. 7 , asend referrals process 212 starts 214 where theadjudicator 24 a creates 216 the LMR referral 202 (seeFIG. 6 ). Theadjudicator 24 a submits 218 thereferral 202 for review by thenurse case manager 24 b, who completes 220 the review and returns 222 thereferral 202 to theadjudicator 24 a. Theadjudicator 24 a receives 224 thereferral 202 and sends 226 thereferral 202 to the provider PSP, who can retrieve 228 the referral from the interface 14 (seeFIG. 1 ) of thesystem 10. If the provider PSP accepts 230 thereferral 202, then thereferral 202 is assigned 232 to a consultant of the provider PSP to generate 234 the proposedplan 204. Further, theadjudicator 24 a is notified 236 that thereferral 202 has been accepted and thereferral process 212 ends 238. Otherwise, the provider PSP declines 242 the referral and an alternate provider PSP is selected 244. Thisselection 244 continues untilacceptance 236 is confirmed. - It should be noted that the
referral process 212 can automatically select the provider PSP from the provider database 32 (seeFIG. 1 ). Referring toFIG. 8 , aselection algorithm 246 accesses 248 thedatabase 32 through a plurality ofselection criteria 250. Theselection criteria 250 can include postal code matching 252 of the provider PSP and the worker 22 (geographic specific),provider expertise 254,provider selection frequency 256 for distributing a number of referrals among a group of eligible providers PSP, or any other combination of the above. It is recognized that other selection criteria can be used, if desired. Once the provider PSP is selected 258, theadjudicator 24 a or other system administrator can override 260 the selection. It is also possible that theadjudicator 24 a manually selects the provider PSP for thereferral 202. - Referring to
FIGS. 10-14 , anexample referral 202 is shown, includingworker 22 details, employment profile, physical precautions, referral details, as well as provider details that can be determined by the algorithm 246 (seeFIG. 8 ). 10 - Referring to
FIG. 9 , a manage plans process 262 starts from theprevious step 234 of thereferral process 212. The provider PSP creates 264 the proposed plan 204 (seeFIG. 6 ) and submits it through the interface 14 (seeFIG. 1 ) to themanagement agency 24. Theagency 24 then receives 266 the proposedplan 204. Theagency 24 determines 268 a value for the proposedplan 204 and then sendspayment 270 to the provider PSP for the plan set-up and what level of assessment has already been completed with theworker 22. Further, theagency 24 also reviews 272 the proposedplan 204 for suitability. If theplan 204 is approved 274, then the adjudication rules 210 are determined and sent to therules database 64 for subsequent use in adjudicating LMR plan bills associated with the approvedplan 206. The provider PSP is notified 276 of the approval. Otherwise, theplan 204 is declined and amended 274, and the provider PSP is notified 278 that changes are required before final approval. The provider PSP then modifies theplan 204 and resubmits 280 it for approval. This change process can continue until theplan 204 is finally approved 274. - Further activities by the provider PSP and
management agency 24 for theprocess 262 include the provider PSP viewing the status of the submittedplan PSP submitting plan 206 amendments as necessary after approval, the provider PSP viewing the balance remaining on approvedplans 206, and theagency 24 changing the status of theplans 204, 206 (i.e. cancel, suspend, reactivate). In the case of changes or amendments of the approved plan, therules 210 are also updated to reflect the changes. Further, during the amendment process of theplans plans FIG. 2 ) for referral by theagency 24 to help in subsequent analysis of theplans - Therefore, as described above, the
process 212 creates and sends thereferral 202 to a selected provider PSP, who then either accepts or declines. Notification of the acceptance/decline status is given to theagency 24. Further, it should be recognized that once theinitial referral 202 is created, all subsequent status information of thereferral 202 is stored in the IDB 26 (seeFIG. 2 ) for review by interested parties of thesystem 10 through theinterfaces referral 202, the provider PSP prepare and submit the proposedplan 204, which can consist of information pre-populated from thereferral 202, an indication of the level of assessment completed with the worker, as well as details outlining the proposed program of care. After theplan 204 is submitted, the referringadjudicator 24 a receives notification of theplan 204 and initial payment is given to the provider PSP base on the indication of the level of assessment completed. Therefore, it should be noted that therules 210 are used by the adjudication engine 38 (seeFIG. 2 ) to process the remaining level of assessment of the approvedLMR plan 206 on a predictive basis. - The
adjudicator 24 a indicates initial adjudication results on the proposedplan 204, and have the option of either approving theplan 204 or requesting changes. The approvedplan 206 triggers through the workflow engine 36 (seeFIG. 2 ) the creation and submission of the payment rules 210 into theadjudication engine 38. These results are also accessible through theinterfaces plan 206, however, preferably the initial level of assessment remains static. If amended, theadjudicator 24 a is notified of the amendments and the amendedplan 206 must be reapproved. It should be noted that the status and details of the amendedplan 206 are stored in the IDB 26 (seeFIG. 1 ) for access through theinterfaces rules 210 are triggered for change and reinserted into theadjudication engine 38. Accordingly, the revisedrules 210 replace the previous rule set 210. Further, theadjudicators 24 a can change the status of theplan 206 at any time, such as to suspension or cancellation. This change in status is recorded in theIDB 26, as well as revised in therules 210 to deactivate the payment associated with theplan 206. Conversely, theadjudicators 24 a can also reactivate theplan 206, if suspended or cancelled, which will also trigger the revision of therules 210 to reactivate the payment rules associated with theplan 206. It should be noted that this change in status is also recoded in theIDB 26. Accordingly, theinterfaces agency 24 members and providers PSP) to inquire about the status and otherdetails concerning referrals 202 and plans 204, 206, as well as the actual dollar amounts approved/paid against theplan 206. - It is also recognized that members of the
agency 24 can override any provider PSP selection, change the PSP, view a series ofreferrals 204 against associated valid claim numbers, and view plans 204, 206 and amendments for any valid claim number. Further, members of theagency 24 can also update LMR parameters of thesystem 10, including thereferral algorithm 246 operation, theselection criteria 250, as well as expense codes and dollar limits used by theplans - Referring to
FIG. 15 , an example creation or editing of theplan example plan FIGS. 16 to 20 . In general, the creation of theplan - 1. User (of the
provider 20 seeFIG. 2 ) logs into thesystem 10 through theinterface 14, - 2. User selects the view or edit plan option,
- 3.
System 10 displays the following fields: Claim Number, Worker First Name, Worker Last Name on theinterface 14, - 4. User enters worker's name and or claim #,
- 5. User issues a Search command,
- 6.
System 10 searches for matching criteria and validates that the claim number is a 28 valid claim number, - 7.
System 10 determines that the claim number is valid and displays the results to the user on theinterface 14, - 8.
System 10 displays the following fields to the user for the specific claim number: - Section 1: Plan Header Tab (see
FIG. 16 ) -
- Claim number
- Claim status
- Worker name (first and last)
- Worker DOA
- Desk ID
- Plan ID
- Plan Version
- Plan Status
- Date Plan Created
- Plan Start Date
- Plan End date
- Plan Review Date
- Plan Suspension Period
- date Plan Last Modified
- Plan Modified By
- Section 2: Payment Details Tab (see
FIG. 17 ) -
- Status
- Service Code
- Freq
- Unit
- Amount
- Payment Start Date
- Payment End Date
- Payee Name
- Section 3: Assessment Tab (see
FIG. 19 ) -
- PCA Total Amount
- CA Total Amount
- Rationale Notes for assessment detail
- Section 4: CEW Tab (see
FIG. 19 ) provides a summary of the various cost categories and Section 5: View Payments Tab (seeFIG. 20 ) provides summary of approved amounts once theplan 204 has been submitted and then reviewed by theadjudicator 24 a (seeFIG. 6 ). - In order to display the actual dollar amounts approved and/or paid against the
plan 206, the facility to create a report called plan budget versus actuals is provided within the reporting and monitoring module (seeFIG. 1 ). The name “actuals” refers to the actual dollar amounts paid. The plan versus actuals report uses details of the plan described above and stored in the integrated database. The report also uses information on the amounts paid which are also stored in the integrated database. - Referring to
FIG. 21 , a workflow for creating a plan versus actuals report is shown generally by the numeral 320. A report may be requested by a primary source provider (PSP) or by the labour management agency (LMA) 24. Atstep 322, the PSP or the LMA requests the plan versus actual report. The request includes a claim number as an indication of the plan of interest. The plan budget versus actual report provides a view of the entire plan including budgeted amounts compared to paid amounts. To create the report, the system determines the latest approved plan at step 324. Although the plan is the “latest approved plan”, the status of the plan may be “closed” or “expired” rather than “approved”. The system then finds all paid bills for the claim indicated in the request atstep 326. The claim number and service code on each bill will determine which section the bill will be counted against. - The system then aligns all the paid bills with the latest approved plan associated with the claim indicated in the request at
step 328. The aligning process uses the bill service code to align bills with plan lines according to their service codes. The bill date of service (DOS) can be outside of the date range defined for the plan line service. The bill secondary service provider (SSP) can be different from the SSP defined for the plan line service. - This system then displays the report at step 330. A sample report is shown at
FIGS. 22 , 23, and 24. The report is displayed in two sections, namely, a header and a body. The header section includes the following information: - “As of”: date the information that is displayed was updated
- “Worker name”: Last and First name of worker associated with the case
- “Claim Number”: claim number associated with the case
- “Plan Id”: LMR Plan Id generated by the system
- “Version”: Version of the LMR Plan
- “Plan States”: status of the LMR plan information displayed
- “Effective Dates”:
-
- From is the date when the plan was last approved
- To relates to plan Status:
- Approved=open
- Closed=date when the plan was closed
- Expired=date the plan expired
- “Service Duration”: the earliest start date of a service in the plan to the latest end date of a service in the plan. Note: Service duration can be outside the plan effective dates. “Case Manager Name and Phone”: Last and first name of Case Manager and phone “Adjudicator Name and Phone”: Last and First name of Adjudicator and phone “Primary Provider and Location”: Name of Primary service Provider and location (city) “Transferred From”, “Location” and “Transfer Date”: when plan is transferred, the previous owner name, location (city) and date when plan is transferred. Transfer can be External (from another provider) or internal (from a different location or different Case Manager). If the case was not transferred, “n/a” will be displayed in these fields.
- Within the body of the report are four sections, namely assessment, plan budget with actuals, other payments issued, and totals. The assessment section includes the services of transferable skill analysis, evaluation, and vocational evaluation. The report displays the service code and name of assessment services that have been paid automatically. The report also displays the code and name of the primary service provider associated with the auto-payment. Finally, the report shows the actual amount paid to the primary service provider. If no amount has been paid, then the message “no assessment” is displayed.
- The plan budget with actuals section of the report displays all services in the latest approved plan with the actual amounts paid for each service grouped by secondary service provider (SSP). The report includes the service code and name according to the latest approved plan. The provider code, name and address according to the latest approved plan, the effective dates of the service according to the latest approved plan, the status of the service, the plan amount and the actual amount paid to the secondary service provider. The status of the service can be “current”, “future”, “past” or “unallocated”. The status is “current” if the date is between the start date and end date of the plan line service. In this case, the “actuals” amount is the total of bills where the DOS is between the service start date and end date, the bill service is the same as the line service, and the bill SSP is the same as the line service SSP.
- The status is “future” if the date is before the start date of the plan line service. In this case, the “actuals” amount is the total of all bills where the bill DOS is between the service start date and end date, the bill service is the same as the line service, and the bill SSP is the same as the line service SSP.
- The status is “past” if the date is after the end date of the plan line service. In this case, the “actuals” amount is the total of all bills where the bill DOS is between the service start date and end date, the bill service is the same as the line service, and the bill SSP is the same as the line service SSP.
- The status is “unallocated” if the bill service is the same as the line service, and the bill SSP is not the same as the service SSP or the bill DOS is outside of the range defined by the start date and end date of the plan line service or both.
- Finally, the system calculates the balance remaining in the plan as the difference between the plan amount and the actual amount. For each separate service, the report includes a service total line which includes the total budget for that service and the actual amount paid for that service and the balance available for that service.
- The other payment section of the report displays all payments made for services that are not in the latest approved plan. This section of the report displays the service code and name for payments made for a service outside of the latest approved plan, the code and name of the service provider associated with the payment, and the actual not paid. If there is no such payments then a message is shown saying “no other payments were issued.”
- The total section of the report shows the actual amount paid for assessments, the plan amount, actual amount and balance for the plan budget with actual section, the total of other payments issued, and an overall total of all actual amounts paid for the claim.
- As discussed above, the predictive payment process 119 (see
FIG. 6 ) is part of thesystem 10. The recurring payment requests associated with the LMR plans 206 are used in the administration ofworker 22 claims in order to support thebill adjudication 38 process. There are four major functions used in thesystem 10 and associatedprocess 199, including creation of a predictive payment, the modification of a predictive payment, searching for existing predictive payments, and a bill generation process. These functions are coordinated through theinterfaces 12, 14 (seeFIG. 1 ). - Referring to
FIG. 26 , the following steps are performed to create a predictive payment: - 1. The
Plan 206 Start Date is auto-populated based on the earliest payment start date on the that will be entered on the Plan Detail tab; - 2. The Plan End Date can be automatically populated by the system to 5 years, for example, from the Plan Start Date. This date can be modified by the user to a date other than the preset date, if desired;
- 3. The system will auto-populate the Plan Review Date to 12 months, for example, prior to the Plan End Date;
- 4. Next the user moves to the Payment Detail tab of the page (see
FIG. 26 ) and begins building theplan 206; - 5. User selects the appropriate service code. User may select the service code from the predefined pick list which will highlight their selection to flag to the user what they have chosen or they may click the Other Service Code icon which will open the scope of the service code search to all service codes. The user can search for the service code based on keyword and or by service code number;
- 6.
System 10 displays the selected service code in the Service Code field. The service code description will be displayed below the service code field. System will determine if selected service code belongs to a pre-defined group or “bundle” and will automatically pre-populates the next detail line items with all the service codes within that “bundle”; - 7. User moves to the Frequency field and indicates the appropriate frequency from the predefined pick list (if required, this is a mandatory field but is sometimes populated by system logic);
- 8.
System 10 highlights and displays the user's frequency selection in the pick list; - 9. User moves to the Unit field and enters the numeric number of units to help determine the dollar value of the payment. For example, the unit value entered is equivalent to the total number of hours allowed for that service per month;
- 10. User moves to the Amount field and enters the dollar amount of the payment (if required, this is a mandatory field but is sometimes populated by system logic) and is displayed to the user.
- 11. User moves to the Payment Start Date and enters the date that the first bill should be generated to begin the recurring payment cycle. A calendar icon can be available to the user in order to facilitate the user in the date selection process;
- 12. User moves to the Payment End Date and if needed alter the default date of Dec. 31, 9999 that the last bill should be generated to end the recurring payment cycle. A calendar icon can be available to the user in order to facilitate the user in the date selection process;
- 13. The payee field can be pre-populated with the worker's 22 name, however, the user may change payee as required (i.e. to the worker's trustee.) by moving to the Payee field. User can click on the Payee icon so that they may search for the appropriate payee. The user will be able to search for the payee based on their name (first and or last) and or Provider TIN# which will have already been set up for the payee whether they be a worker, supplier, provider or third party;
- 14.
System 10 will display the full address of the Payee to the user, the user will click on the payee ID and the system will populate the payee field in the Payment request Section with the full name of the payee; - 15. It is assumed that the payee will be the same for all of the payment requests. Once Payee field has been changed, the
system 10 will make active a checkbox entitled All Payee, which will be checked. The user can uncheck this checkbox which means that for every payment detail they now enter for theplan 206, a payee will have to be selected and all payee name fields on the page will be deleted; - 16. User may repeat steps 10-21 for every
different payment request 304 they wish to set up for thispredictive payment plan 206; - 17.
System 10 will also allow the user to “de-select” a payment detail automatically created based on service groupings (Step 13); - 18. User moves to the Rationale Tab of the page and if needed in the Rationale Notes field enter any additional information. The system will pre-populate the PCA Total Amount and CA Total Amount fields. The CA Total Amount is equal to the total amount of clothing allowance paid per year to the worker (
system 10 adds all clothing allowance service codes to be paid for the year). This amount does not include arrears amount. The PCA Total Amount is equal to the total amount of Personal Care Allowance paid per month (system 10 adds up all PCA service codes to be paid for the month into one amount). This amount does not include arrears amount; - 19. User issues the Save command. System saves the information to the database and the predictive plan is successfully saved with a status of “Pending” allowing the user to save a partially completed plan. To activate the
plan 206, user will go to the Modify Plan option and completed all required information; - 20. User issues the Submit command on the Rationale tab;
- 21.
System 10 can run validation checks for completeness on mandatory fields and format of data entered into all fields that require population by a user and ensuring that no duplicate payment requests have been created; - 22.
System 10 saves the information to the database 26 (seeFIG. 2 ) and thepredictive plan 206 is successfully saved as “Active”. - The create predictive payment process involves the set up of one or many predictive payment requests by the
rules 210 for the purposes of the predictive payment plan for theworker 22 claim. The modify predictive payment process involves the application of the administrative practices of a payor to the existing predictive plan structure they have defined for aworker 22 claim. These modifications may include the following changes: modify service code; modify frequency; modify payment amount; modify start and end dates; modify units (where applicable); and modify payee. These items are included in the LMR DB 64 (seeFIG. 2 ) as the series ofpayment rules 210, which are imported into theadjudication engine 38 once the plan is confirmed. The search process involves retrieving and displaying information about thepredictive payment plan 206 for theworker 22 claim based upon user specified criteria through theinterfaces plan 206 as stored in the IIDB 26 (seeFIG. 2 ). The bill generation process involves the triggering of bill creation based on parameters defined during thepredictive payment plan 206 maintenance (create and modify) processes. The bill generation process will apply logic through theworkflow engine 36 and the adjudication andpayment engines plan 206 andcorresponding rules 210. - There are three main concepts that make up the functionality of the Predictive Payment process 119 as implemented on the
system 10; namely referral, maintenance of predictive payment plans 206, and generation of bills from predictive payment plans 206. The predictive payment plan 206 (or PPP) is a collection of one or more payment requests with corresponding payment parameters such as amount, frequency, start and end dates, which are then organized in a structure for the purposes of plan definition. From the plan definition the bill generation process will then be triggered to generate bills for specific payees as per the specified frequencies and start and end dates for the payment requests that are specified in theplan 206. The PPP is comprehensive meaning that it will include all of the predictive payment requests that aworker 22 claim needs in order to be able to buildplans 206. Thepredictive payment plan 206 contains at least one predictive payment request and at least one payee. - Referring to
FIG. 25 , aPredictive Payment detail 300 includes the plan that interacts through apayee 302 with the predictive payment request 304 (embodied in therules 210, seeFIG. 6 ). Thepayment request 304 identifies aservice code 306,frequency 308,units 310,amount 312, andpayment request start 314 and end 316 dates. For example, theagency 24 will determine that theworker 22 claim is entitled to a Personal Care Allowance and will then set up apredictive payment request 304 by therules 210, which will allow a recurring payment to be sent to the specifiedpayee 302. Theagency 24 can indicate during the creation process which Personal Care Allowance code theworker 22 will receive reimbursement for, the frequency for which the worker will receive reimbursement, the number of units, the amount of the reimbursement, and the start date and end date for the reimbursement period. Thepayee 302 identifies who will receive reimbursement for the predictive payment request or requests 304. Theagency 24 may indicate at the plan level thepayee 302 if all the payment requests—304 go to thesame payee 302 or if there aremultiple payees 302 per each payment request then theagency 24 can indicate thepayee 302 for eachindividual payment request 304. The payee may be theworker 22, an equipment/service supplier (such as an SSP), the provider PSP, or any other third party. - Referring to
FIGS. 2 and 27 , once the LMR UR rulesDB 64 information has been inserted into theadjudication engine 38, in response to the approved plan 206 (seeFIG. 6 ), generation ofbills 402 from the predictive payment requests 304 (seeFIG. 25 ) can begin. Thebill generation process 400 applies logic through theworkflow engine 36 at a predetermined time/schedule on a daily basis, for example, to retrieve predictive payment details (corresponding to the payment requests 304 of the plans 206) from theBill Scheduling database 62. The predictive bill data of thedatabase 62 is reformatted by theworkflow engine 40 and then inserted into thebill adjudication queue 48, foreventual LMR bill 402 creation and submission into theadjudication engine 38 for adjudication. The adjudication of theseLMR bills 402 provides thepayment engine 40 with payment details, which are used to issue payment by thesystem 10 to the providers PSP in response to the predictive elements of thecorresponding plan 206. Theprocess 400 uses the parameters of the payment request(s) 304 within theplan 206 to determine what data to insert into the payment bill entity. Theprocess 400 also applies logic in order to determine the required number of bills to be generated based on the payee combinations for thepredictive payment plan 206, for example coordination of benefits (COB) that are part of theplan 206 as well as direct payment to theworker 2 and SSPs if desired. Thebill generation process 400 can use standard fields and values, such as the 837 EDI import process. - Referring to
FIG. 27 , thebill generation process 400 is run on a predefined frequency in order to pick up from thedatabase 62 and send bill payment requests 304 that run on user defined anniversary dates, as well as being able to run on specific set dates. The trigger for the bill generation will be theparameters FIG. 25 ). Accordingly, the automatic generation of the LMR bills 402 involves the coordinated effort between theworkflow engine 40 and the contents of theIDB 26, as well as theprocedures FIG. 2 ). - Referring again to
FIG. 27 , the process 400: - 1. uses the
system 10 through theworkflow engine 40 to trigger 404 the bill generation to start on a daily basis or other predefined period; - 2. the
system 10checks 406 the Predictive Payment schema indatabase 62 of the IDB; - 3. the system checks 408 each predictive payment plan stored in
system 10 for an Active status; - 4. for each plan that is active the
system 10 also checks 408 to see that allpayment requests 304 12 are Active; - 5. if any
payment requests 304 are not active 410 thebill generation process 400 does not use them for bill generation and proceeds to the next 411 bill; - 6. for each active plan with
active payment requests 304 thesystem 10checks 412 to see what date is contained in a Next Bill Generation Date column of the scheduling data in thedatabase 62; - 7. if the date contained in the Next Bill Generation Date column is equal/
matches 414 to the current date then thesystem 10 flags that for this plan andpayment requests 304 thesystem 10 must generate thebill 402; - 8. once the
system 10 flags that thebill 402 is required for this plan andpayment requests 304 it moves 416 the date in the Next Bill Generation Date column to a Last Bill Generation Date column, hence updating 416 the bill generation frequency; - 9. next the
system 10 looks at a Frequency parameter for thatpayment request 304 and calculates what date thenext bill 402 needs to be generated on and inserts that date value into the Next Bill Generation Date column; - 10. the system checks 418 for
other bills 402 and steps 6-9 are repeated by thesystem 10 until it has collected all of the payment requests 304 that require each of thebills 402 to be generated forspecific plans 206; - 11. next the
system 10 evaluates if one ormore bills 402 are required to be generated that day/period for that plan by confirming 420 the payment details in steps 12-15; - 12. the
system 10 checks an All Payee flag for eachpotential bill 402; - 13. if the All Payee flag is set then the
system 10 will skip to step 16; - 14. if the All Payee flag is not set then the
system 10 looks at a payee id parameter, which denotes the identity for different payees; - 15. for each different payee id per
payment request 304 for that plan thesystem 10 can create adifferent bill 402; - 16. once the
system 10 has determined howmany bills 402 are required for one plan, it begins populating 422 the bill export table 48 in theIDB 26 with the parameters stored in the predictive payment schema of thebill scheduling database 62; - 17. once the
system 10 has completed inserting all thebill 402 data into the bill export table 48 in the IDB, the bill generation process is completed and thequery bills procedure 70 is used by theworkflow engine 40 to import theLMR bills 402 into theadjudication engine 38 foradjudication 424 andeventual bill 402 generation. - It should be noted that information on the processing/payment history of the
bills 402 is stored in the IDB for subsequent access through theinterfaces predictive payment plan 206 or one of theservice codes 306 within the predictive payment plan has moved from suspend to reactivate status, thesystem 10 determines the start and end date of the suspension period and determines if during this time thecorresponding bill 402 was not generated. For example, an activation date can be provided by the user to determine date range for bill generation for the suspended period. Preferably, if no activation period is supplied, thebill generation process 400 will assume that the reactivation period will be thefull suspension 28 period. - Although the invention has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art without departing from the spirit and scope of the invention as outlined in the claims appended hereto.
Claims (5)
1. An electronic bill processing system for coordinating the submission and processing of an electronic bill corresponding to a provider of insurance services, the system comprising:
a) a provider interface;
b) an integrated database coupled to the provider interface for storing bill information pertaining to the electronic bill;
c) a workflow engine coupled to the integrated database for coordinating the processing of the electronic bill and for updating the bill information in response to the bill processing; and
d) a management system coupled to the integrated database for monitoring the contents of the integrated database accessible by the provider interface;
wherein the provider can coordinate real-time retrieval of submission and status details for bill information contained in the integrated database.
2. The system according to claim 1 further comprising a search function for accessing the integrated database through the provider interface, the search function having a number of search options for retrieving the bill information.
3. A method for coordinating the submission and processing of a bill according to predictive payment data of a plan, the method comprising the steps of:
a) storing the predictive payment data corresponding to the plan in a database coupled to an adjudication engine;
b) inserting a predictive payment parameter into a rule set of the adjudication engine for eventual adjudication of the predictive payment data at a predefined interval, the predictive payment parameter corresponding to a content of the plan;
c) triggering a creation of the electronic bill at the predefined interval according to the predictive payment parameter;
d) retrieving the predictive payment data from the database and providing the predictive payment data to the adjudication engine; and
e) updating the predictive payment parameter for recognizing the submission of the payment data to the adjudication engine; and
f) generating the bill as defined by the predictive payment data of the plan once adjudicated.
4. The method according to claim 3 , wherein a plurality of service codes is included with the predictive payment parameter.
5. A system for coordinating the submission and processing of a bill according to predictive payment data of a plan, the system comprising:
a) A PROVIDER INTERFACE;
b) an integrated database for receiving a predictive payment plan submitted from the provider interface;
c) a predictive payment request of the plan storable in the database, the request including a plurality of predictive payment parameters;
d) an adjudication engine coupled to the integrated database; and
e) an insertion function for inserting the predictive payment parameters, when stored in the database, into an adjudication rule set of the adjudication engine, the adjudication rule set for eventual adjudication of the predictive payment data;
wherein adjudication of the predictive payment data results in the generation of the bill.
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA 2401956 CA2401956A1 (en) | 2002-09-06 | 2002-09-06 | Interactive electronic bill payment system |
US40888402P | 2002-09-09 | 2002-09-09 | |
CA002409078A CA2409078A1 (en) | 2002-09-06 | 2002-10-21 | Interactive electronic bill payment system |
US10/277,205 US8108274B2 (en) | 2002-09-06 | 2002-10-22 | Interactive electronic bill payment system |
US65626503A | 2003-09-08 | 2003-09-08 | |
US10/960,984 US20050187872A1 (en) | 2002-09-06 | 2004-10-12 | Interactive electronic bill payment system |
US11/797,316 US8645168B2 (en) | 2002-09-06 | 2007-05-02 | Interactive electronic bill payment system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/797,316 Continuation US8645168B2 (en) | 2002-09-06 | 2007-05-02 | Interactive electronic bill payment system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140249975A1 true US20140249975A1 (en) | 2014-09-04 |
Family
ID=34865424
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/960,984 Abandoned US20050187872A1 (en) | 2002-09-06 | 2004-10-12 | Interactive electronic bill payment system |
US11/797,316 Expired - Lifetime US8645168B2 (en) | 2002-09-06 | 2007-05-02 | Interactive electronic bill payment system |
US14/049,733 Abandoned US20140249975A1 (en) | 2002-09-06 | 2013-10-09 | Interactive electronic bill payment system |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/960,984 Abandoned US20050187872A1 (en) | 2002-09-06 | 2004-10-12 | Interactive electronic bill payment system |
US11/797,316 Expired - Lifetime US8645168B2 (en) | 2002-09-06 | 2007-05-02 | Interactive electronic bill payment system |
Country Status (1)
Country | Link |
---|---|
US (3) | US20050187872A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200387943A1 (en) * | 2019-06-07 | 2020-12-10 | Mitel Networks Corporation | Job-specific contact center generation |
Families Citing this family (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6993507B2 (en) * | 2000-12-14 | 2006-01-31 | Pacific Payment Systems, Inc. | Bar coded bill payment system and method |
US8108274B2 (en) * | 2002-09-06 | 2012-01-31 | Emergis Inc. | Interactive electronic bill payment system |
US20050187872A1 (en) * | 2002-09-06 | 2005-08-25 | Mike Schmidt | Interactive electronic bill payment system |
US8095462B2 (en) * | 2003-05-30 | 2012-01-10 | Regions Asset Company | Dynamic enrollment control system, method and computer program product |
US7590971B2 (en) * | 2003-08-01 | 2009-09-15 | Idx Investment Corporation | Enterprise task manager |
US20050187841A1 (en) * | 2004-02-24 | 2005-08-25 | First Data Corporation | System for maintaining account and product data |
US7475051B1 (en) * | 2004-09-22 | 2009-01-06 | International Business Machines Corporation | System and method for the cascading definition and enforcement of EDI rules |
US9405800B1 (en) * | 2004-12-13 | 2016-08-02 | Iqor Holdings Inc. | Apparatuses, methods and systems for a universal payment integrator |
US8386440B2 (en) * | 2005-05-10 | 2013-02-26 | Microsoft Corporation | Database corruption recovery systems and methods |
US7840526B1 (en) | 2005-12-29 | 2010-11-23 | United Services Automobile Association (Usaa) | Workflow administration tools and user interfaces |
US7792872B1 (en) | 2005-12-29 | 2010-09-07 | United Services Automobile Association | Workflow administration tools and user interfaces |
US7822706B1 (en) | 2005-12-29 | 2010-10-26 | United Services Automobile Association (Usaa) | Workflow administration tools and user interfaces |
US7792871B1 (en) | 2005-12-29 | 2010-09-07 | United Services Automobile Association | Workflow administration tools and user interfaces |
US20070192132A1 (en) | 2006-02-10 | 2007-08-16 | Debra Thesman | System and method of prioritizing and administering healthcare to patients having multiple integral diagnoses |
US9009064B2 (en) * | 2006-03-31 | 2015-04-14 | Ebay Inc. | Contingent fee advertisement publishing service provider for interactive TV media system and method |
US20070282628A1 (en) * | 2006-05-18 | 2007-12-06 | Elizabet Satterfield | Method and Apparatus for Managing Rejections and Denials of Payments for Medical Services |
US7680737B2 (en) * | 2006-07-06 | 2010-03-16 | Moneygram International, Inc. | Systems and methods for processing payments with payment review features |
US8271326B1 (en) * | 2006-09-07 | 2012-09-18 | Newtek Business Services, Inc. | Referral processing and tracking system |
US7885832B2 (en) * | 2006-10-02 | 2011-02-08 | Golden Rule Insurance Company | Insurance policy and method for providing an insurance policy having dormancy features |
US9679318B1 (en) * | 2007-05-24 | 2017-06-13 | Amdocs Software Systems Limited | System, method, and computer program product for updating billing parameters utilizing a bill replica |
US8818835B2 (en) * | 2007-08-17 | 2014-08-26 | Dma Ink | Method and system for integrating calendar, budget and cash flow of a project |
US20090108080A1 (en) * | 2007-10-31 | 2009-04-30 | Payscan America, Inc. | Bar coded monetary transaction system and method |
US8370230B2 (en) * | 2007-11-21 | 2013-02-05 | Early Warning Services, Llc | System and method for expedited release of held items |
US20090204530A1 (en) * | 2008-01-31 | 2009-08-13 | Payscan America, Inc. | Bar coded monetary transaction system and method |
US10453043B2 (en) * | 2008-06-25 | 2019-10-22 | Thomson Reuters Global Resources Unlimited Company | System and method for online bill payment |
US10169784B1 (en) | 2009-03-23 | 2019-01-01 | United Services Automobile Association (Usaa) | Systems and methods for loan origination and servicing based on a recurring deposit of funds |
US9710832B1 (en) * | 2009-06-08 | 2017-07-18 | Jpmorgan Chase Bank, N.A. | System and method for card-funded bill payment concierge service |
US20110161215A1 (en) * | 2009-12-28 | 2011-06-30 | Christina Reed | Method and System for Tracking Billing Information |
US8984034B2 (en) * | 2010-09-28 | 2015-03-17 | Schneider Electric USA, Inc. | Calculation engine and calculation providers |
US20120185400A1 (en) * | 2011-01-13 | 2012-07-19 | Bank Of America Corporation | Processing refund requests |
US20120329015A1 (en) | 2011-06-24 | 2012-12-27 | Debra Thesman | Hierarchical condition categories program |
GB2504339A (en) * | 2012-07-26 | 2014-01-29 | Royal Bank Scotland Plc | Transaction system and method |
US10424032B2 (en) | 2012-12-12 | 2019-09-24 | Quality Standards, Llc | Methods for administering preventative healthcare to a patient population |
US10504075B2 (en) * | 2014-03-10 | 2019-12-10 | Aliaswire, Inc. | Methods, systems, and devices to dynamically customize electronic bill presentment and payment workflows |
US9639830B2 (en) * | 2014-03-10 | 2017-05-02 | Aliaswire, Inc. | Methods, systems, and devices to dynamically customize electronic bill presentment and payment workflows |
US10679163B2 (en) * | 2015-06-30 | 2020-06-09 | Invidasys, Inc. | Workflow management |
CN106980968A (en) * | 2017-04-07 | 2017-07-25 | 沈成龙 | A kind of online ticket payment method and system connected based on bank batch |
WO2019157199A2 (en) * | 2018-02-07 | 2019-08-15 | Sunbelt Medical Management, Llc | Medical claim database relationship processing |
US11463255B2 (en) | 2021-01-04 | 2022-10-04 | Bank Of America Corporation | Document verification system |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020120535A1 (en) * | 2001-02-27 | 2002-08-29 | Spencer Yu | Website system and method for providing on-line data-exchange and a collaborative service of return and repair process |
US20030191711A1 (en) * | 2001-11-01 | 2003-10-09 | Jamison Eric W. | System and method for obtaining customer bill information and facilitating bill payment at biller websites |
US20040064386A1 (en) * | 2002-10-01 | 2004-04-01 | Jane Goguen | Real time claim processing system and method |
US20070203760A1 (en) * | 2002-09-06 | 2007-08-30 | Mike Schmidt | Interactive electronic bill payment system |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000079451A1 (en) * | 1999-06-17 | 2000-12-28 | Mobius Management Systems, Inc. | Electronic statement, bill presentment and payment system and method |
US20020002495A1 (en) * | 2000-05-19 | 2002-01-03 | Npax, Inc. | Integrated pharmaceutical accounts management system and method |
-
2004
- 2004-10-12 US US10/960,984 patent/US20050187872A1/en not_active Abandoned
-
2007
- 2007-05-02 US US11/797,316 patent/US8645168B2/en not_active Expired - Lifetime
-
2013
- 2013-10-09 US US14/049,733 patent/US20140249975A1/en not_active Abandoned
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020120535A1 (en) * | 2001-02-27 | 2002-08-29 | Spencer Yu | Website system and method for providing on-line data-exchange and a collaborative service of return and repair process |
US20030191711A1 (en) * | 2001-11-01 | 2003-10-09 | Jamison Eric W. | System and method for obtaining customer bill information and facilitating bill payment at biller websites |
US20070203760A1 (en) * | 2002-09-06 | 2007-08-30 | Mike Schmidt | Interactive electronic bill payment system |
US20040064386A1 (en) * | 2002-10-01 | 2004-04-01 | Jane Goguen | Real time claim processing system and method |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200387943A1 (en) * | 2019-06-07 | 2020-12-10 | Mitel Networks Corporation | Job-specific contact center generation |
US11574348B2 (en) * | 2019-06-07 | 2023-02-07 | Mitel Networks Corporation | Job-specific contact center generation |
Also Published As
Publication number | Publication date |
---|---|
US20070203760A1 (en) | 2007-08-30 |
US20050187872A1 (en) | 2005-08-25 |
US8645168B2 (en) | 2014-02-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8645168B2 (en) | Interactive electronic bill payment system | |
US8108274B2 (en) | Interactive electronic bill payment system | |
CA2409078A1 (en) | Interactive electronic bill payment system | |
US7835921B1 (en) | Patient credit balance account analysis, overpayment reporting and recovery tools | |
US7917378B2 (en) | System for processing healthcare claim data | |
US7698153B2 (en) | Automated system and method for health care administration | |
US20040039601A1 (en) | Virtual file cabinet including health information method and apparatus | |
US20030191667A1 (en) | System and user interface supporting use of rules for processing healthcare and other claim data | |
US20040172310A1 (en) | Electronic insurance application fulfillment system and method | |
US20100257080A1 (en) | System and Method For Managing Account Receivables | |
EP1465129A1 (en) | Bill payment and payee information management system and method | |
US20040243441A1 (en) | Personal and healthcare data financial management system | |
US20020013716A1 (en) | Network based integrated system of care | |
WO2010042513A2 (en) | Billing, docketing and document management | |
US20070083397A1 (en) | System and method for establishing electronic funds transfer-based medical payment plans at point of service | |
US7761410B2 (en) | System and method for reviewing and implementing requested updates to a primary database | |
WO2011123517A1 (en) | Remote portal for billing, docketing and document management | |
US8065162B1 (en) | Provider data management and claims editing and settlement system | |
CA2440485C (en) | Interactive electronic bill payment system | |
US20200090292A1 (en) | Claim and progression management | |
US20040006495A1 (en) | Letter communication method, an apparatus, and a computer program product for a healthcare provider to effectively expedite reimbursement process from a patient | |
US11449954B2 (en) | Integrated HIPAA-compliant computer security system for verifying and billing long term services, including data collection, proof of service delivery, and electronic visit verification | |
US11954742B2 (en) | Data-driven integrated HIPAA-compliant computer security system for verifying and billing long term services, including data collection from multiple sources | |
US20230186415A1 (en) | Client intake information capture system and methods | |
JP2005523504A (en) | A system that allows consumers to access healthcare-related information |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: EMERGIS INC., CANADA Free format text: CHANGE OF NAME;ASSIGNOR:BCE EMERGIS INC.;REEL/FRAME:032157/0114 Effective date: 20041201 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |