Abstract:
The problem with healthcare today is that clinicians are required to make time sensitive decisions without a complete, comprehensive, objective and easily accessed picture of a patient&#39;s overall condition. Healthcare data lives in multiple, unconnected silos and paper based files. The result to hospitals is lost revenue, administrative inefficiencies and increased labor costs. The tool as described above solves for these challenges by providing real time, accumulated, analyzed and scored data and corresponding and relevant workflows that can be accessed at the point of care through claim payment and finalization.

Description:
[0001]    This application claims the benefit of U.S. Provisional Patent Application Ser. No. 62/058,121 filed Oct. 1, 2014, which is incorporated by reference herein in its entirety. 
         [0002]    The field of invention is a platform that provides institutional healthcare providers a single, integrated solution that connects prospective clinical decision making and post claim denial resolution. This invention integrates disparate sources of discrete and non-discrete clinical, financial and administrative health care data and provides technology and analytics that enable institutional healthcare entities to make accurate, data driven care level decisions, provides workflow to ensure care decisions are made timely, manages hand-offs across care givers necessary for patient throughput and captures rationale behind care level decisions for use in post payment denials resolution. 
     
    
     DESCRIPTION OF RELATED ART 
       [0003]    Healthcare providers lose billions of dollars annually due to unreimbursed or under-reimbursed services. Most lack access to objective clinical and financial data and analytics necessary to proactively ensure reimbursement accuracy and retrospectively resolve payment issues. Providers also lack the ability to accurately document the decisions they make. The result is a loss of revenue and increased administrative expense for healthcare providers. Additionally, functional areas that have an impact on ensuring appropriate revenue are disjointed, existing platforms are administratively burdensome and provide only “point in time” optics. 
         [0004]    Compounding the issue, Government and commercial payers have put tremendous pressure on institutional healthcare providers such as hospitals to make accurate patient care determinations (i.e. should the patient be admitted to the hospital; should they be cared for in an inpatient or observation setting) and to comprehensively document the rationale for those care determinations. This pressure has increased particularly over the last 5 years as government and commercial payers have implemented aggressive pre and post payment audit programs namely RAC and MAC. These programs audit compliancy to care guidelines, payment, administrative and compliance rules. Should a claim be deemed non-compliant for these reasons (and others), the hospital is at risk for non-payment and/or a take-back of payment and a resulting loss of revenue after the services were provided. In many cases, take-backs can date back as far as 3 years and affect hospital revenue and reserves. In order to reclaim payment, hospitals must go through a rigorous, largely manual and time consuming appeals process that can take up to 5 years. 
         [0005]    The result of these audit programs is an increased need for hospitals to ensure patient care level decisions at the point of care—to get it right the first time. In addition, if and when a payment is denied, they require the tools necessary to effectively and efficiently reconstruct the clinical set of events to defend the original care determination. 
         [0006]    Generally, hospitals are challenged in both regards. Prospectively, hospital staff throughout the care continuum must make timely decisions based on clinical, financial and regulatory requirements based on the information available at that time. Today, due to lack of integrated, timely and comprehensive data, these decisions are inconsistent, disjointed and somewhat subjective. Hospitals have attempted to solve for the problem by implementing internal or outsourced concurrent review processes to ensure accuracy and compliance. Unfortunately, due to lack of credentialed staff, widely dispersed data and poor internal system infrastructure, these review processes are generally costly, ineffective and still effectively manual. 
         [0007]    Retrospectively, should a patient care decision be challenged by government or commercial payers and/or their contracted auditors, hospitals are asked to recreate care decisions years after the patient has been discharged. Today, the appeal process is largely manual and heavily dependent on review of disparate sources of information to defend their decisions. These sources include paper medical records, scanned documents, EMRs, case management systems and others. In addition, hospital staff working denied claims are asked to “recreate” clinical determination made years earlier. The connectivity between front-end decision making and back-end denials management does not exist. Nor does the ability to recreate automated clinical determinations. 
         [0008]    In addition, both prospectively and retrospectively, hospitals are challenged by the arbitrary application of clinical guidelines, payment, administrative and compliance rules by government and commercial payers and their contracted auditors. Today, a source of truth that can be used by both parties in determining care accuracy does not exist. 
       SUMMARY 
       [0009]    It has recently been discovered that the challenges as described above can be solved through the deployment of a tool that consolidates discrete and non-discrete administrative, financial and clinical data real-time into a single system, that applies real time analytics that guides clinical decisions, that applies known and customizable denial and audit targets through a dynamic rules engine and provides a workflow infrastructure that connects front end decision making with back-end denials management, documentation, and audit defense. 
         [0010]    The inventive subject matter connects prospective point-of-care and retrospective post-claim revenue cycle/audit processes and automates labor intensive and non-productive processes. The inventive subject matter combines and aggregates discrete and non-discrete clinical, financial and administrative data into a single data warehouse. 
         [0011]    The inventive subject matter includes clinical and risk scoring methodologies to affect patient flow, patient handoffs, payer/provider communication and accurate reimbursement. The inventive subject matter includes real-time, dynamically updated, patient clinical dashboards to track, monitor and memorialize relevant clinical data for future use. The inventive subject matter includes automated scoring and message alerts dispatched via email and text messages and are refreshed as new information is received. 
         [0012]    The inventive subject matter&#39;s rule engine incorporates administrative, financial, compliance and payer specific guidelines and alerts end users at a case level adherence/breach. Through customizable analytics, the inventive subject matter incorporates discrete and non-discrete clinical data in the development and promotion of scoring methodologies and analytics used in the prospective care decision and retrospective denial resolution process. 
         [0013]    The inventive subject matter provides prospective and retrospective workflow that includes predefined timelines, case escalation and communication protocols and required actions to ensure adherence to regulatory and payer specific parameters. The inventive subject matter provides capabilities which allows end users to bundle, package and submit disparate documents necessary in the defense of a denied claim. 
         [0014]    The inventive subject matter includes an integrated and comprehensive executive reporting layer, including population based and case specific analytics information. Reports are access directly through the analytics portal. The inventive subject matter provides a means for healthcare entities (payers and providers) to use a common set of objective data and analytics and access to key structured, unstructured and tagged documents necessary in the evaluation of patient status. The inventive subject matter provides a means for healthcare entities (payers and providers) to communicate regarding the appropriateness of patient status decisions. 
         [0015]    In one example, a computer implemented method for managing and documenting health care decisions includes the steps of providing a non-transitory computer-readable medium database for accumulating and processing information data related to a clinical care determination. The next step is consolidating information data related to a clinical care determination in the database so that it is available to a user, wherein the information data includes administrative, financial and clinical data. The next step is applying a customizable rules engine to the information data to generate a visual guide that links clinical care guidelines and a medical payer denials management processes in order to provide guidance to a real-time clinical care determination. The final step is providing a visual patient dashboard adapted to display the information data, including the visual guide, in accordance with the rules engine. The visual guide may comprise a wellness score that is representative of the overall wellness of a patient prior to the onset of current health issue of the patient. The wellness score may be calculated by assigning a numerical value to each of a plurality of health factors that impact overall wellness on a predefined wellness scale. This wellness score may be visually presented on the patient dashboard as green (good), yellow (fair), or red (poor) depending on a specific patient wellness score. The visual guide may further comprise an acuity score that is representative of the condition of a patient at the onset of the current health issue of the patient. The acuity score is calculated by assigning a second numerical value to each of a plurality of diagnostic data. The acuity score may be visually presented on the patient dashboard as green (low acuity), yellow (medium acuity), or red (high acuity) depending on a specific patient acuity score. The visual guide may comprise a visual care level score which is a numerical indicator that assists a user with deciding a level of service for a patient, wherein the level of service includes an inpatient care level and an observation care level. The care level score may comprise a gauge on the patient dashboard, wherein the higher the numerical indicator, the closer the gauge will visually indicate an inpatient level of care. The care level score may be based on a calculation comprising patient wellness, patient acuity scores, high value medications (RX) and impactful procedures. The visual guide may further comprise a condition specific mappings of clinical values and services rendered (i.e. medications (RX), procedures) related to actual patient care service diagnostic outcomes. The visual guide may further comprise an appeal score that is a likelihood that an unpaid or denied healthcare claim by a healthcare provider to a pair will be resolved in the favor of the healthcare provider. The appeal score may be based on a clinical strength of the claim and a financial strength of the claim as measured by the healthcare provider&#39;s pass success rate of overturning similar unpaid or denied healthcare claims. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]      FIG. 1  is an overview of the flow and function of the tool for managing and documenting healthcare decisions described herein. 
           [0017]      FIG. 2  is a schematic flow chart of the functional operation of the data accumulator described herein. 
           [0018]      FIGS. 3 and 3  Continued are an expanded flow chart of the operation of the tool. 
           [0019]      FIGS. 4 and 4  Continued sheets are an illustration of one example of an analytics portal. 
           [0020]      FIGS. 5 and 5A  and their respective Continued sheets are an illustration of one example of a patient dashboard. 
           [0021]      FIGS. 6 and 6A  and their respective Continued sheets are an example of a user interface illustrating admission criteria trending analysis. 
           [0022]      FIG. 7  is an example of a user interface displaying search functionality of the tool. 
       
    
    
     DETAILED DESCRIPTION 
       [0023]    Referring first to  FIG. 1 , there is an overview of the operation of the management and documentation tool  10  for use with healthcare decisions. The tool  10  begins with the collection of hospital information data  12  related to a clinical care determination that is transferred into the data accumulator  14 . The data accumulator  14  is a non-transitory computer-readable medium database. The data collected in the data accumulator  14  is then consolidated and passed through the normalized data store  16  and thereafter through the rules engine  18  to end up at the analytics portal  20  where a user may visually interact and interface with all of the information in an effort to make healthcare decisions. The tool  10  is effective all along a timeline  22  which means that it is useful in analyzing and making healthcare decisions related to a patient at the front end or initiation  24  of care. Later in the timeline  22 , the tool  10  can be used in the retrospective end  26  so that all of the information associated with a healthcare decision is available and documented. 
         [0024]    The tool described herein is intended for use with any institutional healthcare entities. Typically, these healthcare entities are hospitals and payers. Healthcare providers are not intended to be limited by any narrow definition of a hospital. The institutional healthcare provider may be a clinic or doctor office or emergency center or any other location where healthcare decisions are rendered and payers are called upon to reimburse that healthcare provider for the medical care that was delivered. To the extent that the term “hospital” is used often herein, the term is intended to encompass all institutional healthcare providers. 
         [0025]    As illustrated in  FIG. 2 , the tool includes a data accumulator  14  that intakes, transforms and normalizes data from disparate discrete and non-discrete clinical, financial and administrative data creating a unique and comprehensive view of a patient throughout the care continuum (i.e. from point of care to claim payment). Hospital data  12  may include laboratory, reports, orders, medications (RX), caregiver notes, vital sign readings, claims or other information. This data  12  may be found in common documents  30  like HL7, X12 or other formats  32  as shown. 
         [0026]    The data accumulator consists of the following key components:
       An interface engine  40  for taking data from various sources and performing required mapping services for data normalization   A Master Patient Index (MPI)  36  to cross-reference patient identity; and   A terminology service  34  to manage coding standardization.       
 
         [0030]    Turning now to  FIG. 3 , a staging database  50  holds standardized discrete and non-discrete information data for subsequent applications, such analytics applications, rules applications, work flow applications and reporting applications. The staging database  50  is multi-tenant and security is set at the schema level to provide tenant-level security. 
         [0031]    The staging database  50  includes the following key components:
       Main clinical data model  52  that holds clinical data including vital signs, labs, medications, notes and reports, images, problems, allergies, demographics. Sources of clinical data include HL7, CCD, NCPDP, CDA, JPG/GIF/PNG.   Main financial models  54  that holds provider, patient, insurance, claims and appeals history and inventory. Sources of data include X12 835, 837, CSV/Batch files from hospital specific patient account systems, CSV/Batch files from hospital specific appeals inventory system(s).   Custom tables  56  that hold data specific for the product including scoring outputs, end-users inputs and other system generated data.   APIs for loading data into the staging database, as well as for accessing the data.   Configuration and logging functionality for loading data into the staging database.       
 
         [0037]    Once the data is normalized and stored, cleansed and relevant data is scored and analyzed via rules and automation engine  60 . This rules engine component  60  provides independent recommendations on patient care level actions, validates decisions being made, begins the documentation retention process, and identifies possible problems or issues related to payer reimbursement. Main components of the rules and automation engine  60  include:
       Administrative Rules   Compliance Rules   Payer Guideline Rules   Coding Rules
 
End users are alerted of possible rule violations via a comprehensive “push” notification and messaging system that includes text, email and work queue alerts.
       
 
         [0042]    The services layer  58  of the staging database  50  also includes analytic results  65 . The tool also includes an analytics portal  70 . The analytics portal is integrated with the normalized data store (as described above) and provides a complete access to all clinical data and analytics results  65 . The portal  70  facilitates communication within a hospital and between hospitals and payers to facilitate effective and efficient care determinations and claim resolution. Real-time case level displays are available 24/7 to provide hospital and payer staff with real time access to information, clinical scoring results and information alerts. 
         [0043]    The analytics portal is mobile-enabled, allowing both PC access as well as real-time tablet access. 
         [0044]    Key component of the analytics portal include: 
         [0045]    Rules Driven Due Dates for Required Decisions and Actions
       Reasons for required decisions and actions   Tracking of required decisions and actions   Case escalations   Alerts for non-compliant cases   Easy access to output of analytics (as described below)       
 
         [0051]    Again referring to  FIG. 4 , the portal  70  includes multiple classes of information. There are specific patient and healthcare episode columns  72 . The date of patient care actions are listed in column  74 . There are additional indicator columns  76  that are directed to initial acuity, current acuity and wellness in columns  76 . These categories may be specifically customized and calculated according to a particular caregiver, payer, and industry guidelines. These indicator columns  76  are shown with color-codes indicia are a visual guide to a real-time clinical care determination that indicate or suggest various attributes of a patient and needed patient care. Next, there is the admission criteria trending analysis column  78  where a caregiver can watch the progress of various predetermined criteria of a patient. Relevant clinical values are highlighted and scored. The next column is a patient dashboard  80  which allows the user access to detailed medical information about that patient. Finally, there is the action column  82  which allows the caregiver to choose various predetermined actions with respect to patient care. 
         [0052]    The tool also includes a patient dashboard  90 , a real-time top-level look into a patient&#39;s case including patient demographics  92 , trended vitals  104 , trended test results and active alert notifications  94 . As shown in  FIG. 5 , the patient dashboard  90  also visually provides continuous scoring metric updates for all of scoring methodologies including scores for patient wellness  100 , patient acuity  102 , strength of patient care level  98  and potential denial risk. Additional information accumulated and displayed via the patient dashboard  90  is intensity of service indicators  108  (i.e. tests, EKGs. X-rays, etc.), hospital procedures performed and non-oral drug administration  110 . Information is displayed in aggregate for the entire episode of care and for each separate day of the patient stay. The patient dashboard  90  displays comparative financial information  114  to provide estimated payer reimbursement for various billable events. 
         [0053]    The current healthcare environment lacks comprehensive scoring tools specific to the patient care level determinations and appeal decisions. Applied throughout the tool are various real time and historical scoring methodologies that enable hospital staff to make more accurate care and case resolution determinations. 
         [0054]    The analytics displayed on the patient dashboard  90  ( FIG. 5 ) provide end users with a consolidated view of the patient&#39;s condition, past and present which are critical elements in making appropriate level of care decisions and supporting those decisions during the appeal process. Key analytics illustrated in  FIG. 5  below include: 
         [0055]    Wellness Score  100 —The wellness score  100  is a representation of the overall wellness of the patient prior to the onset of the current condition. It is uniquely calculated using an algorithm that associates a numerical value (positive or negative) to key health factors that impact overall wellness (i.e. chronic conditions, age, mobility, high risk medications). Each factor is assigned a weighted numerical value and totaled to determine where the patient falls on the wellness scale. The score is presented on the patient dashboard  90  and the ACTA as Green (good), Yellow (fair) and Red (poor). 
         [0056]    Acuity Score  102 —The acuity score  102  is a representation of the condition of the patient beginning with the onset of the current health issue. It is calculated using an algorithm that associates a weight to key diagnostic values/levels that indicate overall acuity. The weights are totaled and the score determines where the patient falls on the acuity scale. The Initial Acuity Score is calculated using the instance with the highest weight value for the time period under consideration. The acuity score  102  displays on the patient dashboard  90  and ACTA as in an easily readable/interpretable image with Green (Low acuity), Yellow (Medium Acuity) and Red (High Acuity). 
         [0057]    Care level score  98 —Uniquely provides an end user with direction on deciding the appropriate level of service for a patient. It is calculated using an algorithm that factors patient acuity, trending acuity, patient wellness, clinical indicator score as well as regulatory requirements or services that require specific settings (e.g. inpatient only procedures). This algorithm is customizable by a hospital to conform to rules of that end user and expected payers. The care level score  98  displays as a gauge on the patient dashboard  90 . The higher the score, the closer the gauge will get to an Inpatient care level. The lower the score, the closer the gauge will get to observation care level. The score is dynamic and updates every 4 hours or other variable time period. 
         [0058]    Chronic Condition Predictors—The chronic condition predictor is a representation of the likelihood a patient has a chronic condition (CKD, COPD, etc). It is calculated applying machine learning techniques and incorporates key current diagnostic values as well as previous key diagnostic values referenced at six and twelve month intervals. The algorithms assigns a “confidence” score and assigns a corresponding weight and adjusts the care level score proportionally. 
         [0059]    Condition Specific Analytics  104 —High utilization conditions are mapped and scored to the clinical values (key labs/vitals/medications (RX), diagnostic outcomes) most relevant to condition specific care decisions and promoted to the patient dashboard  90  and ACTA  120  for use in patient care level determinations. The mappings and scores are stored as part of the rules engine  60  as described above. Industry acceptable high and low ranges are factored into the mapping and outcomes that fall outside these normal ranges are scored to facilitate care decisions. 
         [0060]    Acuity Trending  106 —The trending acuity score  106  is calculated using a customizable algorithm that associates a weight to key diagnostic values/levels that indicates acuity over the length of the patient&#39;s hospitalization. The trend  106  is indicated by a line graph that represents the acuity score updated at multiple points during the patient stay. The graph is color coded with Red at the top, Yellow in the middle and Green at the bottom, indicating the level of acuity and corresponding with the acuity score  102  (as described above) scale with Green (Low acuity), Yellow (Medium Acuity) and Red (High Acuity). The graph displays a new acuity score periodically, for example every 4 hours starting with the date/time of the initial acuity score. 
         [0061]    Appeal Score  114 —is a customizable algorithm that scores the likelihood an unpaid or denied claim will be resolved in the hospital&#39;s favor based on the integration of clinical, financial and administrative scores. The score is calculated based on: 
         [0062]    1) The clinical strength of the claim as measured by:
       Acuity Score   Wellness Score   Clinical Indicator Score—derived from the clinical mappings as described above. Scores falling outside of normal are scored and weighted based on the variance between normal and defined ranges and actual values.       
 
         [0066]    2) The financial strength of the claim as measured by the hospital&#39;s past success rate of overturning similar denied cases. Similar denied cases are defined as cases involving the same denial target, type of service (Inpatient, Outpatient), Diagnostic Related Group (DRG), diagnosis (ICDx) and/or Procedure (CPT). A success percentage is assigned based on the number of cases won divided by the overall number of appeals for similar cases. 
         [0067]    Each factor described above is assigned a score and then each score is weighted to determine the overall appeal strength of the claim. The appeal score  114  displays on the patient dashboard  90  and ACTA  120  and as in an easily readable/interpretable image with Green (Low acuity), Yellow (Medium Acuity) and Red (High Acuity). The appeal score  114  is also used in several Executive Summary reports to assist users in making data-driven decisions as to the likelihood that an unpaid or denied claim will be resolved in the hospital&#39;s favor. 
         [0068]    The system provides centralized access to key information eliminating the need to access and login to additional hospital systems or external references. End users have access to key medical records documents, results documents including operative reports, imaging, consult, H&amp;P, cardiac cath, EKG, Doppler, discharge summary as well as orders for key items that indicate a higher intensity of service (isolation, ventilator, 24 hour sitter, etc.) directly from the patient dashboard  90 . Users of the patient dashboard  90  have easy access to view key results documents without having to return to other hospital systems to find/view the document. The user is able to access text documents by clicking on the result-description in the list. In addition, condition specific criteria “calculators” (SIRS, ABCD2, etc) are viewable via the system and auto populated via the database. Users have access to a prepopulated reference library of evidence based and condition specific reference material and can score the material based on its relevancy and edit/manage (add, archive, delete) material in the library. 
         [0069]    The presence of a viewable document is indicated by a using a flag to alert the user to the fact that a result document is available. The type of document (final or preliminary) is indicated. In addition, the user is able to highlight and copy text from the document to allow users to easily copy certain parts of a document and pasting them into nursing notes or physician advisory notes, etc. 
         [0070]    Turning now to  FIG. 6 , the ACTA (Admission Criteria Trending Analysis)  120  incorporates unique algorithmic calculations, outcomes and views from clinical and other data sources in a detailed view of a case and reveals all clinical information incorporated in the scores and includes trended data on all vital signs and test results. It can be accessed via the patient dashboard  90  or independently via the portal  70 . The ACTA  120  provides end users access to the key clinical indicators driving the wellness and acuity score as described above. The ACTA  120  also provides visual graphs  128  of criteria trending analysis. Additional component of the ACTA  120  include free form text notes and document pointers used in the claim resolution process. All information and pertinent findings are preserved and available on demand at any time should a case ever come under review by a payer or audit contractor. 
         [0071]    The tool includes functionality to convert unstructured and non-discrete data into searchable and queriable structured text. An example search and interface  135  is shown in  FIG. 7 . The tool allows for both the pull and push of information critical to the analytics. The solution includes predefined set of “tokens”, unique and pre-defined sets of words, lab results, diagnostic results, etc. that the system can apply to the integrated discrete and non-discrete data set so that the end user can validate the presence or absence of critical medical condition factors. When an unstructured document is added to the database, a search will be run on the document to identify and highlight any occurrences of the list of available tokens. Instances of “tokens” are highlighted in the application to alert the end of their existence and impact to the analytics. The tool identifies the type of document (i.e. history and physical, consult notes, progress notes, etc.) where critical data exists and the absence or presence of a clinical attribute specific to a patient condition, diagnosis or procedure. In addition, the end users have the ability to enter their own search criteria from transcribed or unstructured documents and update analytics and scores. All searches are captured in the data base and used to augment existing rules and analytics. 
         [0072]    The tool also includes an integrated and comprehensive executive reporting layer, including a wide variety of population based analytics information (i.e. DRG and physician). Reports are access directly through the analytics portal and assist end users in 1) driving appeal activities based on key indicators, 2) providing meaningful insight prospectively and retrospectively to better manage the denial/appeal process from receipt of the denial through all levels of the appeal process, 3) providing awareness of current appeal activity and the revenue involved in each level of the appeal process, and 4) driving corrective action. The tool provides information at a summary level as well as supporting drill down via various summary levels to case level details depending on the report purpose and content. 
         [0073]    Attributes/functionality includes:
       Prospective and Retrospective views   Dynamic filter with immediate data refresh   Single click drill down from highest summary level through various levels of detail based on the report.   End user ad hoc report generation   End user ability to create and customize report profile       
 
       USER EXAMPLES 
     Example 1 
     Provider Use, Prospective Application 
       [0079]    Determination of Patient Status 
       Step 1—Assessment 
       [0080]    Patient presents to the Emergency Room with signs of Pneumonia. Via the tool, the end user reviews the patient dashboard to determine the general health of the patient (wellness score) and that initial labs (i.e. WBC, Troponin, Lactic Acid) and vitals (i.e. Heart Rate, Blood Pressure, Temperature) are within normal ranges (acuity score). For example, if the wellness score presented as Good (green) and the acuity score presented as Low (green), the end user could assume the patient was in relatively good condition. 
       Step 2—Level of Care Determination 
       [0081]    Next, the end user would use the care level score (CLS) score to guide them in their evaluation of appropriate patient status. For example, if the CLS was less than 70, the end user could rationally place the patient in an appropriate observation status. Conversely, if the CLS measured greater than 70, the end user could assume the patient should be admitted and would require hospital care. The final determination made by the end users is stored and viewable in the platform and can be referenced for future use. 
       Step 3—Denial Mitigation Documentation 
       [0082]    Next, the end user would review the specific clinical indicators for the patient. For example, for the pneumonia patient, if the patient&#39;s SA02 was greater than 97, the end user would document that the measurement of the SA02 was the driving factor behind the decision. This decision is memorialized via the tool and used in the post-pay appeal resolution effort. 
         [0083]    Provider users in this example include but are not limited to: Emergency Room Physician, Hospitalist, Attending Physician, Case Manager, Utilization Review Manager, and Physician Advisor. 
       Example 2 
     Provider/Payer, Use Retrospective Application 
       [0084]    Denial Response/Appeal Review 
         [0085]    In today&#39;s environment, the review of a denied claim for medical necessity by a provider and the review of the corresponding appeal by a payer is largely a manual process. Key components for both entities in the review process is 1) Severity of Illness (SOI); 2) Intensity of Services (IS) and 3) Does the patient require Hospital Based Care. Currently, the hospital clinician and the payer auditor must review clinical information—likely a printed medical record ranging anywhere from 50 to 500+ pages depending on the complexity of the case to make their determinations. Via the tool, this review process is streamlined as follows: 
       Step 1—Accessing Scoring Outputs 
       [0086]    Via the tool, the clinician (hospital) and auditor (payer) access the patient dashboard to evaluate the key components listed above (SOI, IO and Hospital Based Care requirements). These components are displayed on the dashboard as wellness, acuity and care level score thereby minimizing the clinicians and auditors need to access the printed medical record. The specific scores calculated help the clinicians and auditors determine what their course of action will be. For example, if wellness is Red (poor) and Acuity is Red (high) and the Care level score is &gt;60, a hospital clinician can quickly determine they have a strong argument to appeal the claim in question and conversely, a payer auditor to overturn a denial. 
       Step 2—Accessing Acuity Trend 
       [0087]    Another critical step in the review process for both the provider and the payer is the timing of admission specific to the severity of illness and intensity of service. Via the tool and specifically the admission criteria trending analysis (ACTA) as described above, the hospital clinician and payer auditor are able to review—in graphical representation—the pertinent clinical indicators relative to this case again minimizing the end users need to manually and arguably subjectively plot the condition of the patient via a review of the printed medical record. Via the tool, the hospital clinician and payer auditor are able to use the data displayed on the ACTA to make their determination to appeal a denied claim (provider) or uphold/overturn an appealed claim (payer). 
       Step 3—Accessing Documentation 
       [0088]    Most important in the review process is the capturing of documentation by the physician as to the justification for the medical necessity of services rendered. As described above, the tool requires the hospital end user to document overall and at the Clinical Indicator level, information that would defend their status decisions. Via the tool, both the hospital clinician and payer auditor are able to access these comprehensive comments again in their effort to determine appropriate course of action to defend/overturn/uphold a denial/appeal. The final determination made by the end users is stored and viewable in the platform and can be referenced for future use. 
         [0000]    Provider users include but are not limited to: 
       Clinical Appeals Nurse, Revenue Cycle Director, Clinical Appeals Nurse, Payer Audit Staff 
     Example 3 
     Payer Use, Prospective Application—Authorization for Services 
       [0089]    In today&#39;s environment, the process of obtaining and granting authorization for services is largely a manual, paper intensive, iterative and time consuming process. Typically a list of patients requiring authorization is faxed to the payer on a daily basis along with documentation to support the request. Often, there is discrepancy between what services the Provider requests and what the Payer will approve. In these cases, additional documentation is faxed and the case is escalated to the Provider&#39;s Attending Physician and the Payer&#39;s Utilization Management Physician (peer to peer review). Today, a platform does not exist to minimize the exchange of paper documentation, to manage the communication between the payer and provider and to facilitate decision making based on objective, data driven criteria. The tool provides this platform. 
       Step 1—Request for Authorization 
       [0090]    Via the too, analytics portal and specifically the payer defined work queue, on a predetermined frequency (daily/hourly), a payer&#39;s utilization management staff can access cases a provider has submitted to the payer for consideration. Via the portal, the Payer has the ability to communicate its decision (approve, pend, deny, request additional documentation) facilitating a seamless mechanism for the Payer to communicate its approval. 
       Step 2—Clinical Review 
       [0091]    In the event additional clinical support is required by the Payer to make their determination, the Payer can access the patient dashboard and admission criteria trending analysis (ACTA) in lieu of the exchange of paper described above. Via the tool, a payer&#39;s utilization manager staff can access evaluate the key components such as wellness, acuity and care level score and other score calculated by the tool thereby minimizing the payer&#39;s staff need to access the printed medical record. Via the tool and specifically the analytics portal, the payer&#39;s utilization management staff is quickly able to determine discrepancies between the level of care suggested by the analytics and the level of care requested by the provider. The specific scores calculated help payer utilization manager physicians determine what their course of action will be. 
       Step 3—Additional Days/Service Requested 
       [0092]    When a patient&#39;s condition worsens and Provider case management believes additional hospital days or services will be required prior to discharge, via the tool, the hospital alerts Payer Utilization Management staff of this request. Payer&#39;s utilization management staff are able to access the trending acuity graph as well as other clinical scores displayed via the tool to assess the need for additional inpatient days/services. The result of the assessment as well as comments supporting the response are entered into the portal and displayed on and archived with the claim. All communication between the payer and provider is managed through this process thereby eliminating the paper rich and manual process experienced in today&#39;s environment. The final determination made by the end users is stored and viewable in the platform and can be referenced for future use. 
       Step 4—Data Driven Peer to Peer Review 
       [0093]    In the event a provider requests a peer to peer review or oral reconsideration of the request for additional inpatient days/services, both the provider and payer physician representation via the tool can access all relative scores and clinical indicator simultaneously via the portal and specifically the patient dashboard and admission criteria trending report. The interactive nature of the patient dashboard and admission criteria trending report enables dynamic, real time access to scores and data necessary in facilitating the review by both parties. The result of this peer to peer review is chronicled via the portal and displayed on and archived with the claim. 
         [0094]    Payer users in this example include but are not limited to: CMO, Utilization Physician, and Utilization Manager. 
         [0095]    Other embodiments of the present invention will be apparent to those skilled in the art from consideration of the specification. It is intended that the specification and figures be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.