a few terms are defined here to aid in the understanding of the descriptions and drawings that follow . the term “ healthcare provider ” or simply “ provider ” represents the entity that provides medical care to a patient in return for some fee , which may be billed to an insurance company , the patient , the patient &# 39 ; s guarantor , or some combination . the provider may be a hospital ( also known as a facility ), a clinic , or a doctor &# 39 ; s office . the term “ healthcare provider visit ” or just “ visit ” means a unique patient visit to a healthcare provider . during the actual visit , a set of services are provided to the patient for fees . these fees are determined by many different factors including , the free market , the provider , the location of the provider , the doctor , the patient diagnoses , the line of business of the care ( e . g . inpatient , outpatient , emergency , etc . ), the length of hospital stay , whether care was provided , and most importantly , the insurance that the patient is using for the visit since there are pre - negotiated rates and discounts between the provider and the insurance company . the data capture of a new visit for analysis purposes may start in advance of the first date of service for the visit as many providers use a combination of scheduling and pre - registration processes . typically , the data elements captured include , but is not limited to the patient demographic information , date of the appointment , provider information , insurance information if the patient is insured , diagnostic information , and medical procedure information . the term “ alert ” is the data representation of an issue in the data that needs to be brought to the attention of a user or an automated process in order to correct the issue . individual alerts are configurable and are detected in the analytical processing of the data by either business or knowledge rules . business rules are configured process steps that operate on the data while knowledge rules are simple boolean expressions . the actual definition of an individual alert is based upon defined business processes within the healthcare provider organization . as used herein , the terms “ comprises ”, “ comprising ”, “ includes ”, “ including ”, “ has ”, “ having ”, or any other variation thereof , are intended to cover a non - exclusive inclusion . for example , a method comprising a list of elements contains those elements but is not necessarily limited to those elements and may contain other elements not listed . further , unless expressly stated to the contrary , “ or ” refers to an inclusive or and not to an exclusive or . for example , a condition a or b equals true if a is true ( or present ) and b is false ( or not present ), a is false ( or not present ) and b is true ( or present ), and both a and b are true ( or present ). attention is now directed to statistical financial systems and methods to value patient visits to healthcare provider organizations for follow up prioritization . these systems and methods may be used to first create a data model based on existing historical claims and visit data from a healthcare provider . further , these systems and methods can be used to compare real - time visit data , either from an active patient or a scheduled visit in the future to the previously built model in order to create a value that can be assigned to both the visit and any resulting issues that are detected within the data after a series of rules evaluations . furthermore , said value can be used a part of a prioritization scheme to have a user work on the most important issues for the provider from a financial perspective . this is because the items that have a greater financial impact will tend to be the items with heavier weights and this greater priority . before discussing the embodiments of the invention defined by the appended claims , exemplary hardware architecture for using said embodiments is described . fig1 illustrates an exemplary architecture where statistical financial system (“ sfs ”) on computer 120 , can be used to manage both statistical and structured healthcare data residing in database tables contained in database storage and managed by database server 140 . sfs 120 can be bi - directionally attached to database server 140 , which is attached to database storage 14 . database storage 14 may be direct or networked attached to database server 140 . sfs 120 and database sever 140 may be part of a computer network . note that fig1 is a simplification of a hardware configuration . within sfs 120 , a plurality of computers ( not shown ) may be interconnected to each other via a computer network . the computer on which sfs 120 may execute can include a plurality of central processing units ( cpu ) 122 , memory 124 , and input / output ( i / o ) 126 . i / o 126 may include internal data buses , network cards , a keyboard , monitor , pointing devices , and storage and peripheral cards among others . the computer can be attached to a plurality of storage devices 12 either directly or via a network attached drive array , such as a storage area network ( san ). the application client 160 , is utilized by a user to interface with the application containing sfs 120 . as diagrammed , the application client 160 connects to the sfs 120 through an interconnected network 11 . this interconnected computer network 11 may be a local network or the public internet and may run the tcp / ip protocol or other protocols . in an alternate embodiment , the application client 160 may reside on the same local network as sfs 120 , or even within the same computer . there may be a plurality of application clients 160 connected to the sfs 120 server over a network . the computer on which application client 160 may execute can include a plurality of central processing units ( cpu ) 162 , memory 164 , and input / output ( i / o ) 166 . i / o 166 may include internal data buses , network cards , a keyboard , monitor , pointing devices , and storage and peripheral cards among others . the computer may be attached to a plurality of storage devices 16 either directly or via a network attached drive array , such as a storage area network ( san ). portions of the systems and methods described herein may be implemented in suitable software code that may reside within memory 124 , memory 162 , cpu 122 , cpu 162 , or storage devices 12 , 14 , or 16 . in addition , the instructions in an embodiment of said systems and methods may be contained on a data storage device with a different machine readable storage medium such as a hard disk drive . alternatively , the instructions may be stored as software code elements on a disk array , magnetic tape , diskette , cd rom , dvd , optical storage device , or other appropriate machine readable medium or storage device . in an illustrative embodiment of the systems and methods described herein , the machine - executable instructions may be lines of interpreted or compiled java or other language code . in another illustrative embodiment of said systems and methods , the machine - executable instructions may be rules or simple expressions . other architectures may be used . for examples , the functions of any of the systems and methods may be performed by different computers than are shown in fig1 . additionally , a computer program or its software components with such code instructions may be embodied in more than one machine readable medium in more than one computer . in the hardware configuration above , the various software components may reside on a single computer or on any combination of separate computers . in alternate embodiments , some or all of the software components may reside on the same computer . turning to fig2 , the logical layers of a typical statistical financial system for healthcare providers are represented . the lowest layer labeled 210 encompasses the basic persistence layer of the system . the database schemas 212 contain the fundamental data model upon which the application is based and defines tables , relationships between tables , primary and foreign keys , indexes , and data types . the healthcare data is structured and stored in as structured application data 214 . the structured application data 214 includes all data necessary for the system to operate and for the methods to be performed . this data 214 includes relational and non - relational table data , xml and other marked up documents , text , object , expressions , rules , and process state data . the system operates on input data from healthcare providers and other sources , represented as provider / clearinghouse source data 216 . this data may include ansi asc x12 data ( 837 , 835 , 270 , 271 , 276 , 277 , 278 , etc ), health level 7 ( hl7 data ), delimited text , xml or other machine readable formats . once a sample of historical data is processed and analyzed for statistical patterns , it is stored as statistical data 217 for use in other parts of processing . the system will utilize the statistical data store 217 to create stored attribute patterns 218 to compare incoming visit data against in order to calculate value data . the persistence layer contained within layer 210 and within a preferred embodiment of the invention outlined in the attached claims contains machine readable and executable instructions in the form of complex business rules and simple expressions . the business rules 222 are executed within the analytical and rules engine 230 . these business rules 232 provide a flexible and configurable way to augment the machine instructions from a compiled language such as java , which also execute in the analytical and rules engine 230 . the knowledge rules 234 are more basic logical expressions that a skilled user can add to make additional decisions that take into account variables within their unique environment . the analytical and rules engine 230 contains the majority of the machine executable instructions that process the data inputs ( defined in fig3 ) and implements the methods to provide a statistical valuation of a visit , issue , or alert . in an embodiment of this system , an application services and user interface layer 240 provides a means for a user to interact with a remote client 250 to operate an application that incorporates healthcare visits and alerts and the valuations thereof . the remote client 250 , which may be on the same server or a different computer or computers attached over a network is an application such as a web browser that connects to the application services and user interface layer 240 to provide user - facing graphical interfaces to a person . moving on to fig3 , the source data comprised of 303 , 304 , and 306 can come from multiple external systems including the healthcare provider billing system 301 , the healthcare provider registration system 306 , or a claims clearinghouse company 302 . the data defined under 303 and 304 are typically ansi asc x12 837 and 835 files but may be print spool ub04 / cms1500 format other proprietary and custom text formats . the billing data ( 837 , ub / cms , or custom ) contains informational elements such as the dates of service , insurance carrier , the insurance plan code , the facility where services were provided , total and line item charges , procedure codes ( cpt4 / hcpcs ), diagnosis related group ( drg ), diagnostic information , and physician information , amongst others . the remittance data ( 835 or custom ) has matching information from the bill and includes the claim level and line item level payment , adjustment , reason code , and remark code information . in addition to billing and remittance data , there may be visit data associated with the patient registration . typically , this is transmitted ( but is not limited to ) in a health level 7 ( hl7 ) format and contains patient information , the service location , and insurance information , in addition to other information . the aforementioned external data is loaded and processed by the historical claims and remittance module 310 . a block of historical data , for example the data from the previous year , is parsed and split up into relational tables . the historical data is then fed into the statistical analysis module 320 , which creates the attribute patterns 330 . the statistical modeling starts with the identification of the independent variables used in the analysis . based on the already mentioned data inputs , an exemplary set of independent variables are comprised of the insurance carrier , plan code , facility , service code , procedure code , primary diagnosis code , physician , and service location . the independent variables are used to predict the dependent variables , which are the allowed amount , contractual rate , coinsurance rate , total charges , and total payments . in the statistical analysis 320 using a large ( historical ) data set , the independent variables are selected based on their predictive power . since the outcomes of a full historical set are known , the greater predictive power is where the difference between the predicted value and the real value have the best sharpe ratio , the minimum , standard deviation , and the an average approaching zero . the independent variables are discrete variables and using bivariate analysis , the statistical analysis 320 creates statistical markers for the dependent variable , which are comprised of the n ( sample size ), q1 ( value that is at the 25 th percentile of the matching attribute patterns ), median , q3 ( value that is at the 75 th percentile of the matching attribute patterns ), min ( minimum value of the matching attribute patterns ), max ( maximum value of the matching attribute patterns ), sum ( sum of the all of the values of the matching attribute patterns ), and sum2 ( sum of the squares of the values of the matching attribute patterns ). the variables n , sum , and sum2 allow for many statistical calculations such as variance , standard deviation , and skew . all possible combinations of independent variables are calculated to obtain the marker for each of the dependent variables . the independent variables are also weighted based on their contribution to the prediction . the attribute pattern generation 320 saves a data representation of the known set of independent variables ( attribute patterns ) in order to obtain a fast query when needed later in the process . the result set of the fast query is analyzed to find the match that has the most significant statistical quality based on the target valuation desired . this attribute pattern set for fast query is stored in the statistical database 342 . once the system has been tuned with historical data , the real time valuation process can begin . the historical tuning can be repeated over time . the valuation process starts as a new visit comes in from the healthcare registration system 306 and is processed by the real time registration processor 340 , which takes the inbound visit data format , parses it , and hands it off to the real time evaluation of the visit and exception handling 350 . this module stores a data representation of the visit and all of its attributes in the data store 342 . using a configurable set of rules and expressions , the visit is analyzed for any errors or issues . if errors or issues are detected an alert is raised and associated with the visit . alerts are stored 351 in the data store 342 . after the visit attributes are determined , and any alerts are raised , the real time pattern matcher 360 creates the valuation of the visit and the alerts . each visit has a known set of independent variables . using this set , the fast query of an attribute pattern defined by 330 and stored in 332 is queried . the query forms a result set of aggregation values and this result set is ordered by the quality of the sample size , standard deviation , average value and the weighted value of each independent variable . once the ordering is complete , the results are evaluated for the markers whereas the best predictive values are chosen and the target predictive value for each dependent variable . there are several valuation scenarios that may occur ; 1 . value of the entire visit — the predictive dependent variable for a valuation of a visit is the total payments . among the independent variables selected , the insurance carrier , plan code , and procedure code are required . the attribute pattern with greatest sample size and least standard deviation is chosen . 2 . value of the alert — the value is obtained for the entire visit . the value is then apportioned between the various open alerts based on the number of alerts , type of alert , and the configured weight of the alert . in addition to the examples above , there are several variations that can occur ; the value of an underpayment and the insured patient responsibility can be determined based on the dependent variable allowed amount . the value of the uninsured patient payment can be determined based on the dependent variable total charges . finally , turning to fig4 , the basic process flow is depicted . a process 410 monitors for inputs 401 , 402 , and 403 , which contains the historical visit , billing , and remittance data . if data exists 415 , then the process 420 loads the historical data , parses it , and breaks it up into individual data elements . if there is no data , the process 410 continues to monitor for changes . after process 420 loads the data , process step 425 does the statistical analysis described previously during the description of fig3 . as previously describes , the best independent variables are selected . these variables are comprised of insurance carrier , plan code , facility , service code , procedure code , primary diagnosis code , physician , and service location . these independent variables are used to predict the dependent variables allowed amount , contractual rate , coinsurance rate , total charges , and total payments . based on the desired outcome , the best variables are aggregated into an attribute pattern that can be matched later when new registrations are received . the attribute patterns are saved to the statistical data store 430 in either a high performance berkeley file structure or a relational database table . the process 435 monitors for real time inputs from 407 . these inputs are received as patient events occur . these events comprise scheduling , pre - registration , registration , update , check - in , and discharge . if there is data 440 , the process step 445 reads the data , breaks it apart , and analyzes it against a set of rules and expressions . the data representation of the visit processing is stored in data store 470 as relational information . if there is no data , the process step at 435 continues to monitor for new data . the rules and expressions in 445 may detect issues and errors in the data and the decision point 450 evaluates if there are alerts that need to be raised . if there are alerts , the process step 455 creates the necessary alerts associated with the visit object and stores these alerts in the data store 470 . control is then passes to the value alerts step 460 . in this step , the attribute pattern with greatest sample size and least standard deviation is chosen . as previously described in the description of fig3 , the value of the alerts are derived from the overall value obtained for the visit , which is then apportioned between the various open alerts based on the number of alerts , type of alert , and the configured weight of the alert . the results are stored in data store 470 . finally , the overall valuation of the visit is assigned . this is based on the attribute pattern with greatest sample size and least standard deviation and the result is stored in the data store 470 . the outer process loop will return control to the input monitor 435 to start the process anew . in decision 450 , if there are no alerts , then just the value of the visit is created in step 465 and stored in data store 470 .