System for providing consumer access to healthcare related information

[0001] This is a non-provisional application of provisional application serial No. 60/371,027 by D. Fitzgerald et al. filed Apr. 9, 2002 and of provisional application serial No. 60/374,568 by D. Fitzgerald et al. filed Apr. 22, 2002.

FIELD OF THE INVENTION

[0002] This invention concerns a system and user interface for use in supporting patient access to healthcare encounter related information and enabling a patient to initiate scheduling of an encounter and to update patient related healthcare encounter information.

BACKGROUND OF THE INVENTION

[0003] An important function performed by healthcare providers (such as hospitals, clinics or physicians) is the sending of claims to healthcare payer institutions to obtain reimbursement for provision of services to a patient. These claims may be in electronic or paper format. Paper claims typically go through a data entry process that converts them to an electronic format. The entered electronic claims are usually sorted, indexed and archived. Each claim is processed in a payer institution adjudication system. The payer adjudication system interprets the claim data and determines whether or not the claim is to be paid in full, partially paid or denied. This adjudication process may be fully automated, partially automated, or manual. The results of claim adjudication may include the issuance of a check and an explanation of benefits (EOB) to the insured and healthcare provider, or a request to send additional information.

[0004] The Healthcare claim adjudication and associated billing and payment process is encumbered with problems. Patients often do not understand the proffered reason for claim denial or rejection and are frustrated by the limited methods available for tracking and monitoring progress of a claim submitted to a healthcare payer organization. Known systems approach the problem from a healthcare payer or provider perspective. A provider tracks the status of each individual claim and follows-up with the payer. A payer would monitor the activities of the provider to check claim calculations are correct under current payer rules. Patients are provided limited methods of determining claim status or of determining status of other administrative and clinical healthcare procedures such as eligibility verification, pre-certification requests or referrals to specialists, for example. Compounding the problem associated with this task, is the fact that a single medical incident can generate multiple claims for each clinician involved (physician, surgeon, anesthesiologist, physical therapist, pathologist, radiologist) and a patient may be faced with the burden of contacting multiple different entities of a multi-faceted health system to determine the status of a matter. Further, the most common method of making such a contact currently in use is telephone access to a typically labyrinthine customer services department. A patient currently may have no viable way of knowing whether a claim has been submitted, rejected or paid. Also a submitted claim may have been denied for missing information that the patient could have readily provided if aware of the deficiency. Also, an access system should be secure and prevent unauthorized access to confidential medical data. A system according to invention principles addresses these requirements and associated problems.

SUMMARY OF INVENTION

[0005] A system uses aggregated healthcare encounter service, billing, and claim data to enable an authorized patient to access healthcare encounter related information concerning pre-certifications, referrals, eligibility verification, healthcare services availability, co-payments, deductibles, claims and payment status in providing a consolidated view of activity across multiple claims via the Internet, for example. A system supports patient access to healthcare encounter related information including information concerning an event involving interaction of a patient with a healthcare enterprise. The system includes an interface processor for receiving patient identification information and a request for encounter related information. The system also includes a database linking a patient identifier with, a record identifying at least one patient encounter and data identifying at least one healthcare provider organization associated with the at least one patient encounter and a record containing encounter information related to the at least one patient encounter. A data processor accesses the database to provide encounter related information for a patient and processes the encounter related information to be suitable for output communication for presentation to the patient in response to the patient identification information and the request.

BRIEF DESCRIPTION OF THE DRAWING

[0006]FIG. 1 shows an overall encounter data processing system enabling an authorized patient to access healthcare encounter related information, according to invention principles.

[0007]FIG. 2 shows a system configuration enabling an authorized patient to access healthcare encounter related information, according to invention principles.

[0008]FIG. 3 shows a flowchart of a process employed in providing an authorized patient with access to healthcare encounter related information by the system of FIGS. 1 and 2, according to invention principles.

[0009]FIG. 4 shows a user interface display image illustrating, a patient claim billing record for multiple patient encounters with a healthcare provider concerning treatment of an injury, according to invention principles.

[0010]FIG. 5 shows exemplary claim data processing rules associated with clinical events occurring to a patient, according to invention principles.

[0011]FIG. 6 shows a flowchart of a process supporting a patient in scheduling a visit to a healthcare provider to receive a proposed procedure and involving checking whether the proposed procedure meets medical necessity requirements of a payer, according to invention principles.

[0012]FIG. 7 shows a flowchart of a further process supporting a patient in scheduling a visit to a healthcare provider to receive a proposed procedure and involving determining whether a proposed procedure is covered by a patient healthcare plan, according to invention principles.

[0013]FIG. 8 shows patient accessed collated encounter related information, according to invention principles.

[0014] FIGS. <b>9</b>-<b>15</b> show healthcare encounter related information records accessible by an authorized patient, according to invention principles.

DETAILED DESCRIPTION OF INVENTION

[0015] The inventors have advantageously recognized that it is desirable to provide a system capable of providing efficient patient access to information concerning pre-certifications, referrals, eligibility verification, healthcare services availability, co-payments, deductibles, claims and payment status. It is further desirable that such patient information access is available during convenient hours (ideally 24 hours a day every day) and from convenient locations. FIG. 1 shows an overall encounter data processing system enabling an authorized patient (or a consumer) to access healthcare encounter related information. An encounter as used herein comprises a patient encounter with a healthcare enterprise involving patient and healthcare enterprise interaction that has a financial or transaction consequence and may include for example a patient visit, phone call, inpatient stay or outpatient treatment, an interview, an examination, a procedure, a treatment related occurrence, an admission to a healthcare enterprise, a test or an order for medication etc. In the FIG. 1 system, aggregated healthcare encounter service, billing, and claim data in repository <b>68</b> is used to enable an authorized patient to access healthcare encounter related information concerning pre-certifications, referrals, eligibility verification, healthcare services availability, co-payments, deductibles, claims and payment status. The system securely provides a patient via the Internet, for example, with the information in a variety of formats including as a consolidated view of activity across multiple patient claims. A patient is thereby able to track data concerning an episode of care, plus has the opportunity to correct data that might result in erroneous billing. A patient is also able to access payer organization health plan insurance reimbursement and treatment eligibility rules including cumulative limits, family and personal deductible amounts, limits on the number of visits permitted in a predetermined period and reimbursement limits per particular medical condition (e.g., for a year or over a patient lifetime). A patient is similarly able to determine approved pharmacies or other service providers, obtain authorization for a second opinion, determine referral requirements and find approved medications as well as non-covered services. Further, the system of FIG. 1 enables an authorized user to access another individual's records (typically a family member or user that is fiscally responsible for that individual) and enables a patient to assign authority to another individual or entity to access his confidential information. Access is strictly controlled based on policy data supplied by the payer to prevent unauthorized access to confidential patient information. The FIG. 1 system also supports electronic dialog between a healthcare provider and a payer organization that allows a patient or fiscally responsible party to interact directly with payer organizations and healthcare providers to communicate concerns about information viewed or to request that incorrect information be corrected.

[0016] The FIG. 1 aggregated healthcare encounter service, billing, and claim data repository <b>68</b> comprises a relational database linking a record of an encounter resulting in a claim with patient health plan reimbursement and eligibility rules as well as remittance records for a patient medical episode or illness. The database uses known techniques to logically link multiple encounters related to care including pre-admission testing, inpatient stay, outpatient follow-up, bills and payments across multiple providers and locations. Thereby repository <b>68</b> enables a user, such as a patient via consumer portal <b>24</b>, to access information concerning a particular claim, encounter, patient coverage rule or remittance record. Similarly a user is able to view a history of claim updates and coverage rule changes that may impact claim submission and reimbursement. Repository <b>68</b> also enables a user to view elapsed time between events (discussed later) and to view activity of multiple individuals or of one or more individuals within a user defined time period.

[0017] A rule as used herein comprises a procedure for determining that healthcare claim elements comply with predetermined requirements including, health plan reimbursement conditions, health plan format requirements, a reimbursement formula, reimbursement constraints and a reimbursement computation procedure. A rule also may comprise a prescribed guide, a precept, or a model for how to present, conduct or regulate an action by using a form and data or the relations between form and data. Further, an exception as used herein encompasses the identification of an issue and mechanism to process that issue and claim elements as used herein may comprise a portion of a claim, a complete claim, individual records of a claim and record data associated with an individual patient encounter with a healthcare service provider. Further, a claim is an instrument used by insurance companies to recognize services and related changes but it does not create an absolute expectation of payment. In contrast, a bill (typically directed to a guarantor or other fiscally responsible party) is an expectation of payment.

[0018] The FIG. 1 system automates the pre-registration, eligibility, registration authorization, claim generation, trial adjudication, claim submission, payment remittance, and post-remittance processes of a health care claim data processing cycle to provide seamless, accurate and prompt claim processing. The system automates coordination of employer and payer activities and ensures that pre-visit enrollee data is accurate. Thereby, if a patient uses a consumer portal (<b>24</b>) to schedule a visit or if a healthcare facility collects insurance information from a patient, medical necessity, referral and eligibility verification processing is automatically initiated. A claim is evaluated for accuracy and edited by a rule execution function <b>46</b> and adjudication unit <b>48</b>, using the applicable rules in rules repository <b>74</b>, both before the claim is completed (i.e. as individual claim elements for individual healthcare encounters post to the claim, for example) and again before the completed claim is submitted for payment. A variety of portals <b>20</b>-<b>28</b> in the FIG. 1 system are controlled and administered by interface <b>10</b> to provide claim data access to patients, payers, providers, employers and government agencies. The system facilitates healthcare provider compliance with governmental and payer rules through use of automated, rules-based editing and review systems.

[0019] The FIG. 1 system comprises functions implemented in software applications and executable procedures for processing claim data. These functions may also be implemented in hardware or a combination of both hardware and software resident in one or more computer systems and servers and involving one or more communication networks for internal and external communication. The system processes claim data related to provision of healthcare to a patient by collating data related to a claim for a particular patient for submission to a payer. The collated claim data is submitted for pre-processing using rules to validate the collated claim data is in condition for processing to initiate generation of payment. Upon successful validation the validated claim data is submitted to a payer. The claim data is collated by data acquisition unit <b>32</b> via interface <b>10</b> for storage in data repository <b>68</b>. Repository <b>68</b> contains aggregated healthcare encounter service, billing, and claim data including financial and clinical data related to healthcare encounters that are currently ongoing. Data acquisition unit <b>32</b> is able to receive both solicited and unsolicited data from multiple different sources and to request data from these sources via interface <b>10</b>. The different sources include external users (participants) subscribing to and using the FIG. 1 system and may include for example, healthcare providers, healthcare payer institutions (e.g. insurance companies, Health Maintenance Organizations—HMOs etc.), consumers, employers, and government agencies.

[0020] Data keeper unit <b>64</b> acts as a gateway and data management system governing data storage and retrieval for healthcare data repository <b>68</b> and processing requests to use repository <b>68</b> to store, modify, and retrieve data. Historian unit <b>70</b> tracks data changes in repository <b>68</b> by recording time, date and nature of changes made as well as the source and identity of the author of the changes to maintain a data update audit trial. Historian unit <b>70</b> is also used in archiving and maintaining older data value versions and is specifically used in archiving data records associated with patient encounters following completion of financial transactions (i.e. encounters for which no related financial transactions are outstanding) and processing for these encounters. Records of such encounters are maintained by data keeper unit <b>64</b> in repository <b>68</b>. Archiving unit <b>70</b> stores archived data in archive (data warehouse) database <b>72</b>.

[0021] The collated claim data is submitted for pre-processing by trial adjudicator <b>48</b> using rules to validate the collated claim data is in condition for processing to initiate generation of payment. Trial adjudicator <b>48</b> initiates execution of a sub-set of rules executed by rule execution unit <b>46</b>. Unit <b>46</b> detects the occurrence of an event triggering application of associated rules and executes the rules associated with that event. An event may include receipt of data to add to the repository <b>68</b>, a request to execute a specified list of rules, an eligibility request, an eligibility response, a generated authorization, a claim creation, a claim submission, a remittance or request for additional information or an event triggered by the activities of a function within the FIG. 1 system. A rule executed by unit <b>46</b> may itself generate a triggering event and initiate execution of other rules. An individual rule may contain a test resulting in assignment of a result status of “True” or “False” upon execution of a rule. An individual rule may also contain lists of actions to be performed upon a true result and alternate actions to perform upon a false result, for example. The list of actions may include, creation of worklists of tasks for automatic or manual performance, creation of logs and audit reports and accounting reports, creation of error reports, generation of claims, posting of remittances, modification of data, and other actions. Data Morpher unit <b>44</b> comprises a sub-category of actions that rules invoke to modify data in repository <b>68</b> in response to command. Unit <b>46</b> also processes and executes rules stored in the Relationship Rules Repository <b>18</b> that contains rules required and used by the Protector <b>12</b>, Translator <b>14</b>, and Transporter <b>16</b> during communication involving interface <b>10</b>.

[0022] The rules executed by trial adjudication unit <b>48</b> determine expected adjudication results when a specified set of claim data is submitted to a specified payer. Unit <b>48</b> uses rules derived from repository <b>74</b> (or from rule accessor <b>52</b>) via rule keeper interface <b>66</b> to predict the result of submitting a specified set of claim data to a specified payer. For this purpose the rules used by unit <b>48</b> replicate the rules used by the selected specific payer. Unit <b>48</b> identifies conditions that would lead to denial of payment and enables such conditions to be fixed (automatically or with manual intervention) before a claim is submitted to a designated payer. This procedure advantageously facilitates the creation of error-free claims using rules derived from repository <b>74</b> or using remotely accessed rules. Rules including regulatory guidelines and directives are continuously acquired for storage in repository <b>74</b> and are continuously updated and maintained in this repository via rules keeper unit <b>66</b>. System connectivity rules are also retained in repository <b>74</b> and also in relationship rules repository <b>18</b> (in support of communication via interface <b>10</b>). Such connectivity rules support e-commerce communication (e.g., use FITP @ 2400 k baud to a certain node name) or determine a communication mode (e.g., prompt a user to e-mail to ask questions or probe a response. Other rules detect inconsistency between data fields such as data fields retaining a telephone number, zip code, address or other geographical identifier of the collated claim data.

[0023] Rules archiving unit <b>76</b> in conjunction with unit <b>66</b>, dates and time stamps rules to be archived and stores obsolete, expired or older version rules in archive (rules warehouse) database <b>78</b>. Repository <b>74</b> also contains rules developed by the system and by authorized participants that add automated processes to the system. Pattern creator unit <b>38</b> creates specialized rules that define surveillance research processes and rule maker unit <b>56</b> is used to create general purpose rules. Unit <b>48</b> uses rules in repository <b>74</b> derived from external rule sources (such as rules <b>62</b> owned by a payer institution <b>60</b>) by rule accessor <b>52</b> via interface <b>10</b> and data network <b>58</b>. Network <b>58</b> may comprise a conventional network such a LAN (local area network), WAN (wide area network) or the Internet or alternatively may comprise a network service such as a clearinghouse or other service used by a healthcare payer or a healthcare provider to facilitate data and rule (e.g., payer rules <b>62</b>) acquisition for claim adjudication. Payer rules <b>62</b> are rules promulgated by a payer <b>60</b> that are not accessible through the automated process managed by Rule acquisition unit <b>54</b>. Rather rules <b>62</b> are manually determined through manual acquisition processes and are parsed and analyzed by Rule acquisition unit <b>54</b> by using a user interface provided by rule maker unit <b>56</b>. The Rule Maker <b>56</b> user interface supports manual creation, review and update of rules including those acquired via unit <b>54</b>. Unit <b>56</b> also prompts a user with lists of available tests and actions and guides the user through the process of constructing and editing rules prior to storing the edited rules in Rules Repository <b>74</b>.

[0024] Rule acquisition unit <b>54</b> accumulates rule data based on adjudication outcomes of prior claim submissions to payer institutions and through documentation and other information provided by payers that do not provide access to their proprietary programmed rule sets to external users. Unit <b>54</b> also receives new rules following user manual data entry and processing via a user interface provided by rule maker <b>56</b> based on information acquired from payers by rules gatherer service <b>80</b>. Rule Checker unit <b>50</b> monitors rules in repository <b>74</b> and identifies and indicates to a user those rules that are incomplete or contain incorrect syntax. Unit <b>50</b> also reports combinations of rules that are mutually inconsistent. Further, in response to identification of a predetermined exception condition during claim data processing by rule execution unit <b>46</b> and trial adjudication unit <b>48</b>, exception tracker function <b>42</b> employs a sub-set of rules managing the processing and reporting of an identified exception condition. Trial adjudicator <b>48</b> uses rule accessor <b>52</b> to submit claim data for trial adjudication by remotely located rules.

[0025]FIG. 2 shows a system arrangement enabling an authorized patient to access healthcare encounter related information and to actively monitor claim submission, billing and remittance processes via consumer portals <b>24</b>. Accurate and timely access to healthcare encounter related information is enabled by use of aggregated healthcare encounter service, billing, and claim data in repository <b>68</b> in combination with constantly updated rules, regulatory guidelines and directives in repository <b>74</b> (FIG. 1). In operation, a patient, via a consumer portal <b>24</b>, accesses application <b>203</b> executing on consumer portal server <b>200</b> providing a secured Internet compatible Web based user interface. Application <b>203</b> encompasses functions of FIG. 1 including those of rule execution unit <b>46</b>. A patient employs the user interface provided by application <b>203</b> to access encounter related information in repository <b>68</b>. Application <b>203</b> employs a security system including network firewalls and encryption and decryption algorithms to control access to the data. Application <b>203</b> also maintains a HIPAA (Health Insurance Portability &amp; Accountability Act of Aug. 21 1996) compliant audit trail identifying any access to secure information. In response to an information request via portal <b>24</b>, application <b>203</b> interprets the request and accesses the information using the logical record linkage capability of the structured relational database <b>68</b> to derive the desired encounter information. In another embodiment the logical linkage and mapping information may be resident in server <b>200</b> and be used by application <b>203</b> to access the information in repository <b>68</b>. The database <b>68</b> logical linking structure links multiple encounters related to care including pre-admission testing, inpatient stay, outpatient follow-up, bills and payments across multiple providers and locations.

[0026] The linked information in repository <b>68</b> also associates encounter data and transaction data to enable a patient to monitor a progression of events including: admission, claim generation, remittance, and a request for additional information. In order to reduce information storage cost and potential storage redundancy, logical links to external databases such as to payer <b>60</b> and provider <b>61</b> databases are used. Repository <b>68</b> also accumulates non-redundant data from financial applications of multiple healthcare providers including those of hospital, clinic, and physician systems for presentation to a user via portal <b>24</b> (for this purpose the communication links are established as described in connection with FIG. 1). However, although the data may reside in multiple locations, it is logically connected and presented to the patient in a single view by application <b>203</b> operating in conjunction with repository <b>68</b>. In another embodiment at the cost of additional storage, the required data is maintained in a central repository. Updates to repository <b>68</b> occur through a variety of input processes including ANSI (American National Standards Institute) X-12 compatible transactions mandated by HIPAA. For example, updates occur in response to X-12 compatible <b>270</b> (eligibility request), <b>271</b> (eligibility response), <b>278</b> (authorization), <b>837</b> (claim), and <b>835</b> (remit) transactions. Also online updates occur continuously in response to a transaction record being sent from one participant to another, for example. These updates ensure current information is available to the patient or responsible party.

[0027] A patient is advantageously able to use application <b>203</b> to determine the total cost of an episode of illness as well as to access claims and remittance records and other billing data for an episode of illness. Further, a patient or fiscally responsible party (via portal <b>23</b>) is able to configure a view of data including composite or separate views of family member data and is also able to select a time frame for which encounter related activity is desired. A patient is further able to view a list of payers and providers participating in the consumer portal access system to facilitate choice of healthcare vendors or providers supporting easy access to information. A patient uses consumer portal <b>24</b> and application <b>203</b> to schedule a visit to a healthcare facility to receive a particular service. Application <b>203</b>, in response, identifies whether the healthcare facility concerned collects insurance information from a patient and automatically initiates medical necessity, referral and eligibility verification processing. In addition, application <b>203</b> automatically pushes claim update information to a patient or responsible party via e-mail, if desired, to automatically notify the patient of any changes to a claim and related data.

[0028]FIG. 3 shows a flowchart of a process employed in providing an authorized patient with access to healthcare encounter related information by the system of FIGS. 1 and 2. In step <b>303</b>, after the start at step <b>300</b>, application <b>203</b> (FIG. 2) receives patient identification information and a request for encounter related information. Encounter related information includes claim related data, transaction related data, patient hospital admission identification data, payment related data, data representing a request for information, data identifying a medical procedure authorization, clinical data associated with an encounter or data associated with reimbursement denial or acceptance, for example. In step <b>307</b>, application <b>203</b> acquires encounter related information for a patient by accessing multiple databases including repository <b>68</b> (FIG. 2). Such multiple databases include hospital, clinic, physician or payer databases, for example. Repository <b>68</b> links a patient identifier with, records identifying patient encounters and data identifying at least one healthcare provider organization associated with the patient encounters and also with a record containing information related to the patient encounters. Repository <b>68</b> (or application <b>203</b> in another embodiment) maintains a map of available remote databases and associated communication data enabling bidirectional communication with available remote databases. Application <b>203</b> in step <b>309</b> collates the acquired encounter related information to provide supplemental healthcare information concerning a claim, an encounter, an insurance health plan eligibility rule, a record of a payment, a claim history, encounter related information over a user determined time period or encounter related information between user selected events. Application <b>203</b> also process the acquired information to provide collated encounter related information linking a patient identifier with, at least one record identifying multiple encounters, data identifying multiple healthcare provider organizations, data identifying multiple healthcare provider organization associated locations involved in delivering healthcare to a patient, at least one record containing encounter information related to multiple patient encounters, a total cost of multiple encounters associated with treatment of a patient medical condition and treatment eligibility information under a payer health plan applicable to a patient.

[0029] In step <b>311</b>, application <b>203</b> processes the collated encounter related information to be suitable for presentation to a patient and initiates generation of a display image showing the processed information as a single encompassing record, a single display image, a scrollable display image, or a composite multi-window display image in response to the patient identification information and request. Application <b>203</b> further initiates generation of a printable report including the processed encounter related information in response to the patient request. In step <b>315</b>, application <b>203</b> receives a patient command to schedule a visit to a healthcare provider organization. In response to the command, application <b>203</b> in step <b>317</b> automatically initiates medical necessity verification to determine whether the scheduled visit is covered by a patient healthcare insurance plan. Application <b>203</b> also automatically initiates a request for referral by a patient physician to support the scheduled visit and healthcare insurance plan eligibility verification to verify the scheduled visit is covered by the patient healthcare insurance plan. In addition, application <b>203</b> in step <b>319</b> updates repository <b>68</b> to record the scheduling of the visit and automatically communicates encounter related information to the patient in response to identification of an update to a medical record of the patient in repository <b>68</b> indicating scheduling of the visit. Application <b>203</b> maintains a HIPAA compliant audit trail for use in identifying accesses made by the patient to the medical record information in step <b>321</b>. The process of FIG. 3 ends at step <b>323</b>.

[0030]FIG. 4 shows a user interface display image illustrating a claim billing record accessible by a particular patient (the patient is identified by item <b>420</b>) via portal <b>24</b>. The billing record includes collated claim data for multiple patient encounters <b>402</b>, <b>404</b> and <b>406</b> with a healthcare provider concerning treatment of an injury. Further, FIG. 5 shows exemplary claim data processing rules associated with clinical events occurring to a patient. A patient is able to monitor claim activity resulting from application of these rules via portal <b>24</b>. Rules <b>501</b>-<b>513</b> in FIG. 5 are employed by unit <b>46</b> (FIG. 1) in application <b>203</b> of FIG. 2 to automatically validate and correct claim data for provision of services to a patient in response to triggering events. Claim data is processed by calculating expected reimbursement for services rendered to a patient one service at a time. In response to a record of a charge for a service being incorporated in a patient billing record, an expected reimbursement is computed for those active healthcare insurance policies that are applicable in order of their priority. Unit <b>46</b> executes rules <b>501</b>-<b>513</b> and other rules to validate compliance of claim data with payer requirements. Unit <b>46</b> does this for both individual service charges as they accumulate in a patient billing record and for an overall claim covering multiple services and associated charges.

[0031]FIG. 6 shows a flowchart of a process supporting a patient in scheduling a visit to a healthcare provider to receive a proposed procedure and involving checking whether the proposed procedure meets medical necessity requirements of a payer. The process is executed by application <b>203</b> which encompasses the unit <b>46</b> and other processing functions of FIG. 1. A receipt of a patient request to schedule a visit to receive a procedure advantageously automatically triggers medical necessity determination by application <b>203</b>. In FIG. 6, after the start at step <b>550</b> and receipt of a patient request to schedule a visit to receive a procedure in step <b>551</b>, application <b>203</b> initiates communication of a request to a patient's physician to grant a referral to a specialist to support the visit in step <b>553</b>. Application <b>203</b> also executes rules in step <b>555</b> in response to the patient request to schedule a visit to verify the scheduled procedure meets medical necessity requirements of a particular payer organization. Application <b>203</b> initiates communicating to the patient (and his physician) that either, medical necessity for the associated procedure has been verified in step <b>557</b> or that medical necessity verification failed in step <b>559</b>. Upon a failure in step <b>559</b>, application <b>203</b> in step <b>560</b> initiates generation of a prompt item to the patient allowing the patient to schedule a discussion with the patient's physician concerning the visit (and associated procedure) and potential alternatives. The process of FIG. 6 ends at step <b>565</b>.

[0032]FIG. 7 shows a flowchart of a further process supporting a patient in scheduling a visit to a healthcare provider to receive a proposed procedure and involving determining whether a proposed procedure is covered by a patient healthcare plan. Specifically, application <b>203</b> advantageously automatically verifies that a patient is eligible for reimbursement for a visit or procedure under a patient medical insurance plan in response to a patient request to schedule a visit. In FIG. 7, after the start at step <b>600</b> and receipt of a patient request to schedule a visit to receive a procedure in step <b>603</b>, application <b>203</b> executes rules in step <b>607</b> to verify that the scheduled visit or procedure is reimbursable under the patient medical insurance plan. Application <b>203</b> initiates communicating to the patient (and the patient's physician) that either, insurance coverage of the visit or procedure has been verified in step <b>609</b>, or that the visit or procedure is not covered in step <b>611</b>. If the patient is ineligible for reimbursement for the service based on contract terms, application <b>203</b> in step <b>615</b> initiates generation of a prompt item to the patient allowing the patient to schedule a discussion with the patient's physician concerning the procedure insurance coverage and potential alternative treatments that are reimbursable under the patient's health plan. Application <b>203</b> uses previously collected patient insurance information identifying a payer together with stored payer address information, to send eligibility requests to the identified payer. An individual healthcare provider determines rules concerning how long to wait for an eligibility response before initiating further actions (such as making a worklist entry, sending an e-mail, etc.) to expedite a response. Upon a non-coverage determination in step <b>611</b>, a physician in step <b>615</b> may determine that a non-covered procedure is the preferred course of treatment. The process of FIG. 7 ends at step <b>620</b>.

[0033]FIG. 8 shows collated encounter related information accessed by a patient via portal <b>24</b>. A patient is able to configure a request for information to obtain information concerning the services and procedures and associated costs <b>635</b> for one or more episodes of illness. The example of FIG. 8 shows the procedures including procedures <b>640</b>, <b>643</b>, <b>645</b>, <b>647</b>, <b>649</b> administered in treating a patient for a medical condition by a single hospital (HDX Memorial item <b>630</b>). However, a patient is also able to configure his request for information via pop-menus, for example, to obtain information for one or more episodes of care provided by multiple hospitals or other healthcare providers.

[0034] Aggregated healthcare encounter service, billing, and claim data that is provided to a patient via portal <b>24</b> is derived from data repository <b>68</b> and other remotely located databases as required. FIGS. <b>9</b>-<b>15</b> show healthcare encounter related information accessible by an authorized patient and incorporated in central data repository <b>68</b>. Specifically, FIG. 9 shows a partial patient record data structure, FIG. 10 shows a medical record data structure and FIG. 1I shows a partial payer record data structure. A charge record data structure and occurrence code data structure are presented in FIGS. 12 and 13 respectively and FIGS. 14 and 15 indicate a span code and a medical condition code data structure respectively. A span code is another occurrence code for a clinical or other event that takes place over a period of time. These record structures are exemplary only and repository <b>68</b> typically contains other types of records associated with claim data such as, for example, records concerning ambulance services, rehabilitation services, treatments and other services and activities. The record structures of FIGS. <b>9</b>-<b>15</b> are individually accessible in repository <b>68</b> using a claim packet identifier (<b>800</b>, <b>900</b>, <b>920</b>, <b>940</b>, <b>960</b>, <b>980</b>, <b>830</b>), section identifier (<b>802</b>, <b>902</b>, <b>922</b>, <b>942</b>, <b>962</b>, <b>982</b>, <b>832</b>) and sequence number (<b>804</b>, <b>904</b>, <b>924</b>, <b>944</b>, <b>964</b>, <b>984</b>, <b>834</b>).

[0035] Data in an individual record data structure is field length delimited. In the patient record structure of FIG. 9, for example, a patient last name (<b>806</b>) occupies a fixed length of <b>20</b> characters, followed by a patient first name (<b>808</b>) occupying twelve characters and middle initial (<b>810</b>) occupying one character. The record structures of FIGS. <b>10</b>-<b>15</b> contain data related to other particular claim data aspects in similar predetermined fixed length fields. The medical record of FIG. 10, for example, contains an admission diagnosis code (<b>906</b>), as well as a primary diagnosis code (<b>908</b>) and other diagnosis codes (<b>910</b>). The payer record of FIG. 11 contains a source of payment code (<b>926</b>), as well as payer identifier (<b>928</b>) and payer sub-identifier (<b>930</b>). The charge record of FIG. 12 contains a service charge code (<b>946</b>), as well as a service charge revision code (<b>948</b>) and service date (<b>950</b>). The occurrence code record of FIG. 13 contains an occurrence identification code (<b>966</b>) and occurrence date (<b>968</b>). The span code record of FIG. 14 contains a span identification code (<b>986</b>), as well as a span determination start date (<b>988</b>) and end date (<b>990</b>) for use in identifying a period when the condition defined by the Span Code took place. For example, if a patient has had a similar illness, a span code <b>986</b> for that event is coded, and dates <b>988</b> and <b>990</b> are entered indicating the beginning and the end of the similar illness. In a second example, a span code <b>986</b> is used to define eligibility for a particular benefit, such as follow up treatment for 90 days and dates <b>988</b> and <b>990</b> identify a beginning and ending of the benefit period. The condition code record of FIG. 15 contains a medical condition identification code (<b>836</b>). The items referred to in connection with FIGS. <b>9</b>-<b>15</b> are described for exemplary purposes. However, other record items are shown in the record structures of FIGS. <b>9</b>-<b>12</b>. These other items are representative of the breadth of data that may be included in the various records in the repository <b>68</b> structure, for example. In an alternative embodiment, other non-fixed length data record structure or another data record structure may be employed for repository <b>68</b>.

[0036] Returning to FIG. 1, the healthcare encounter related data in repository <b>68</b> is collated by data acquisition unit <b>32</b> via interface <b>10</b> from multiple different sources as previously described and stored in repository <b>68</b> via data management system <b>64</b>. A data emitter unit <b>34</b> provides healthcare encounter related data to an external entity (e.g., portals and participants <b>20</b>-<b>30</b>) by extracting required claim data from repository <b>68</b> and communicating it via interface <b>10</b>. Data reacher unit <b>36</b> is used by functions of the FIG. 1 system to provide read-only access to healthcare encounter related data stored by a remote entity and to make decisions based on this data. Further, healthcare encounter related data repository <b>68</b> is searchable by a patient and other users <b>30</b> via external portals <b>20</b>-<b>28</b> using data search criteria created using search pattern design function <b>38</b>. Thereby a patient may initiate a search of repository <b>68</b> and collation of healthcare encounter related data for response to a patient request.

[0037] Search design function <b>38</b> employs a specialized category of rules stored in rules repository <b>74</b>. An authorized user is able to use surveillance portal <b>28</b> via interface <b>10</b> to use the specialized category of search rules to support a search of rules and healthcare encounter related data information. Searchable information sources include rules repository <b>74</b>, relationship rules repository <b>18</b> as well as healthcare encounter related data repository <b>68</b>. For this purpose, search pattern evaluator function <b>40</b>, employs a sub-set of rules executed by rule execution unit <b>46</b> to process a definition of a pattern search created by pattern design function <b>38</b>. Specifically, pattern evaluator function <b>40</b> identifies patterns in the data searched according to action steps included in the search definition and reports results to the search initiator via interface <b>10</b>. A pattern search may also be initiated in response to occurrence of an event. An event may include, for example, a command (in response to a request by a participant), or upon detection of a change in particular data (receipt of a specific diagnosis, for example) or an internally generated event such as in response to expiration of a particular time period.

[0038] Interface <b>10</b> provides access by various interested participants <b>30</b> in the claim data processing operation via portals <b>20</b>-<b>28</b> for searching, viewing or initiating actions. Thereby a participant (such as a healthcare provider, payer institution representative, patient, employer or government agency) is able to access healthcare encounter related data, payer rules and initiate various actions such as a data correction action, for example. Specifically healthcare providers and healthcare payer representatives are able to access the system via portals <b>20</b> and <b>22</b> that provide the functions these entities respectively require. A healthcare provider, for example, is able to input financial data and associated clinical data into repository <b>68</b> and to initiate and manage claim trial adjudication and other rule-driven processes via portal <b>20</b>. Similarly, a provider is able to automatically modify its own data based on automated rules or through manual amendment and update. A provider is further able to initiate submission of validated error-free claims for payment and to initiate claim status inquiries. In addition, a provider via portal <b>20</b> is able to acquire remittance advice (i.e., information about payments made) and to automatically post acquired advice to corresponding correct accounts as well as to generate and submit secondary and tertiary claims and obtain worklists (of tasks to be performed) and reports in support of management of its business.

[0039] A payer institution is able to use portal <b>22</b> to store and maintain adjudication rules in repository <b>74</b> and to receive claim data for trial or actual (determinative) adjudication as well as to respond to claim status inquiries. A payer is further able to communicate a request for information or remittance advice and obtain worklists and reports and manage its business and revenue cycle. A patient, covered dependent or healthcare plan subscriber with appropriate authorization is able to use consumer portal <b>24</b> to view his own claim data records and claim status and research rules governing payment as previously described. A patient is also able to correct errors in his own demographic data or medical record and to schedule appointments via the system. A patient is also able to obtain account balance, recent transaction records, future deposit information and request payment from a medical expense reimbursement account for items paid out of pocket.

[0040] An employer, or another plan administrator, is able to use portal <b>26</b> to manage healthcare encounter cycle business and to negotiate healthcare contracts on behalf of a group of persons (employees) and to monitor activity related to those employees. For this purpose, an employer is able to obtain, for example, a worklist or a report identifying incidence of various diagnoses, utilization of various providers, a breakdown of charges (e.g. those paid by members, contractually reduced, or denied). Thereby an employer is able to determine if plan members would benefit from an alternative health plan selection. Surveillance portal <b>28</b> enables authorized participants <b>30</b> (e.g. a regulator or researcher) to create and implement research projects to analyze stored claim data by searching for patterns or trends in the claim data of repository <b>68</b> in conjunction with rules repository <b>74</b>. Specifically, surveillance portal <b>28</b> in conjunction with search pattern design and implementation units <b>38</b> and <b>40</b> respectively, supports searches to, (1) generate periodic statistical reports, (2) detect claim fraud and abuse, and (3) detect outbreaks of epidemics, caused either by natural disease or by human (terrorist) activity and other searches, for example. Search results may include worklists or reports and search criteria may be stored as rules in rules repository <b>74</b>.

[0041] Interface <b>10</b> provides access by participants <b>30</b> to claim data and rule repositories <b>68</b> and <b>74</b> via portals <b>20</b>-<b>28</b> using a security function <b>12</b>, translator function <b>14</b> and transport function <b>16</b>. Security function <b>12</b> determines whether a participant is authorized to communicate with another particular participant and whether a participant is authorized to access particular data and assigns participant privileges and entitlements and maintains security and access rules. Unit <b>12</b> rejects and tracks unauthorized requests that violate security and other (e.g., HIPAA) policies. Translator function <b>14</b> converts data between the different data formats used by internal and external participants in the FIG. 1 system. For this purpose, translator <b>14</b> converts data from a first data format into an internally defined intermediate data format and from the intermediate format into a desired output data format. Transport function <b>16</b> supports communication of data and messages between internal functions of the FIG. 1 system and between internal functions and external participants. For this purpose function <b>16</b> uses relationship rules repository <b>18</b> to identify required connection protocols and methods as well as source and destination addresses. Function <b>16</b> also uses rules repository <b>18</b> in encoding data in the appropriate message format and protocol and in initiating necessary hand shaking and other routines required to implement bidirectional communication.

[0042] Relationship rules repository <b>18</b> contains information identifying the application programmer interfaces (APIs) used by participant and system software applications and the required procedure for requesting information from particular sources and providing information to particular participants. The participant API identification and related communication information is provided by individual participants for storage in repository <b>18</b>. The participants retain control over and maintain their respective communication support information. Interface <b>10</b> uses the stored predetermined API and communication information in supporting conversion of data from a first data format into an internally defined intermediate data format and from the intermediate format into a desired output data format. As a consequence, participants are able to update their own systems and to communicate with other participants regardless of the rule standards in use or whether the repositories are migrated to new platforms or radically altered in other ways. Also data format standards involved may be changed by an individual participant without impeding operation by other participants. For this purpose interface <b>10</b> uses relationship repository <b>18</b> to process the validated claim data to provide the data format, protocol, handshaking routine and submission procedure predetermined (and retained and identified in repository <b>18</b>) by the payer.

[0043] The systems, processes and user interface display formats presented in FIGS. <b>1</b>-<b>15</b> are not exclusive. Other systems, processes and user interface forms may be derived in accordance with the principles of the invention to accomplish the same objectives. The inventive principles are applicable to providing secure consumer access to information of interest in other industries and are particularly applicable to the insurance, government and healthcare industries.