WO2007081998A2 - System and methods for performing distributed transactions - Google Patents

Abstract

A system and methods is described for providing unified and secure centralizing information management to permit interoperability of disparate stakeholders in the healthcare industry access and update information under a common scheme thereby creating a more efficient delivery system for all the stakeholders such as patients, doctors, clinics, hospitals, insurance companies, pharmacies and related healthcare entities.

Description

SYSTEM AND METHODS FOR PERFORMING DISTRIBUTED TRANSACTIONS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 60/758,325, U.S. Provisional Patent Application No. 60/758,395, U.S. Provisional Patent Application No. 60/758,433 and U.S. Provisional Patent Application No. 60/758,283, each of which were filed on January 11 , 2006, and are incorporated by reference herein, in their entirety.

Further, this application is related to U.S. Patent Application No. , entitled "TOOLBAR

USER INTERFACE FOR INFORMATION SYSTEM," U.S. Patent Application No. , entitled "SYSTEM AND METHOD FOR A SECURE PROCESS TO PERFORM

DISTRIBUTED TRANSACTIONS," and U.S. Patent Application No. , entitled

"SYSTEM AND METHODS FOR PERFORMING DISTRIBUTED PAYMENT TRANSACTIONS," each of which are being filed simultaneously herewith, having James D. Peters as a common inventor, and are incorporated by reference herein, in their entirety.

BACKGROUND OF THE INVENTION

1. Field of Invention

[0002] This invention relates generally to extending business interoperability to business entities, and, more particularly, to a system and process for efficiently extending interoperability for communications and data related to transactions to business entities in an overall business sector, such as healthcare. 2. Related Art

[0003] Generally, the issues facing the healthcare industry include the continuing need for efficiency in each of the industry market verticals ("Vertical (s)") such as clinics, hospitals, insurance payers, etc. and (b) the lack of effectiveness for transactions that occur across these vertical segments, affecting the entire healthcare market sector ("Sector", or "Horizontal".) The ability to effectively conduct business electronically, across and between these Verticals in the entire healthcare Sector is referred to as interoperability. Whereas solutions from various companies exist that attempt to make the Verticals more efficient, there is no solution in the marketplace that makes the overall market sector effective. Generally, efficiently means to do things right; effectively means to do the right things.

[0004] Looking into each of the two issues identified above we note:

(a) Regarding the Vertical market segments, many companies have and continue to invest their resources and energies in making the Verticals more efficient through automation. This process is by no means complete, but the various market competitors continue to improve their products to deliver higher process efficiencies in each of these market segments. Examples of such companies are NextGen, GE Healthcare, Greenway Technologies, eClinicalWorks, Allscripts and others who have developed and market software solutions that increase the efficiency of clinics and medical offices. Similarly, corporations such as CERNER, SMS, McKesson and others have developed and market solutions that make hospitals more efficient. Others have done the same for other industry Verticals that contribute to the healthcare process, such as the insurance segment, the banking segment, the pharmacy segment, etc.

[0005] The lack of efficiency in the Vertical segments has been reviewed by the Institute of Medicine in the Untied States. On March 1, 2001, the Institute of Medicine issued a report entitled Crossing the Chasm: A New Health System for the 21st Century that clearly describes the state of the healthcare industry in the United States. Specifically, this report states that the healthcare industry is in dire need of automation in all its operations, including hospitals, clinics and doctors in their practices ("Healthcare Providers"). This lack of automation causes healthcare to be expensive and inefficient, and it impedes the ability of healthcare providers to share electronically patient data, clinical and payment information. Such inefficiencies result not only in lost earnings (for example, it is estimated that in many cases as much as thirty percent (30%) of insurance claims are not paid because they cannot be processed due to improper coding), but also in exposure to potential legal liability that causes related insurance premiums to remain very high.

[0006] Furthermore, a federal statute governing the use of healthcare information, the Health Insurance Portability and Accountability Act of 1996, known as HIPAA, imposes federal requirements that affect healthcare providers and other covered entities. The regulations implementing HIPAA mandate certain changes that all healthcare providers must effect in their operations.

[00071 (b) The present lack of Interoperability can be illustrated by the following quote from independent and credible third-party. The Health and Human Services (HHS) Secretary in 2006 said: "The U.S. health care system needs an interoperable electronic health records and billing system... I've come to conclude there really isn't a health care system. There's a health care sector... There's really nothing that connects it together into an economic system. "

[0008] Regarding the effectiveness of conducting business across the overall Sector, we note that there are numerous "Stakeholders" in the Healthcare Sector, including: Patients; Hospitals (including Urgent Care); Primary Physicians; Specialist Physicians; Pharmacies; Insurance Payers; Laboratories (for various tests, imaging, pulmonary, cardio, etc.); Pharmaceutical Companies; Banks that handle transaction payments including HAS/ FSA accounts; Clearing Houses that negotiate a discounted network of services; Employers who participate in the payment of insurance premiums; Government that regulates and insures; and Associations that act as volume purchasing groups, such as Independent Physician Associations and Unions. Generally, a "Stakeholder" may be an individual, or corporation or other type of business who derives a business or personal benefit of any kind, and/or who contributes or participates in the delivery of healthcare services.

[0009] Whereas many companies are working hard to make each of these Stakeholders efficient (Verticals), there is no other solution in the marketplace that make the Horizontal processes effective (that is to say across the entire Healthcare Sector), at this time, nor is there a common infrastructure over which these stakeholders can conduct business effectively, in an automated way. In fact, it has been estimated that over 90% of some 30 billion healthcare transactions per year in the USA are paper based.

[0010J Moreover, there is a general mistrust among the key stakeholders, which is more or less natural in a market that is fraught with errors, fraud, inefficiency and shrinking margins. For example, in 2006, the head of the U.S. Department of Health and Human Services (HHS) has stated that in his estimate, that up to 25% of all Medicare transactions may be fraudulent.

[0011] This conflict is one of the main reasons why the various Stakeholders in healthcare do not collaborate, and hence the result is a disjointed, semi-automated and expensive healthcare delivery system, as illustrated in Figure IA, where some of the Stakeholders are shown illustratively as pieces of a disjointed puzzle. I.e., there is no common infrastructure among Stakeholders. Furthermore, because collaboration is important but not mandatory for effectiveness, it is difficult for anyone of the major players to play a leading role, due to objections by their competitors. For example, if a first large insurance company would take an initiative to resolve some of the key industry problems, why would a second insurance company collaborate and risk losing market share? The answer is likely they would not. It becomes obvious that the marketplace would favor an independent party, especially one that offers advantages to each of the healthcare stakeholders.

[0012] It should be noted that parts of the effectiveness solution are being addressed by initiatives that are typically sponsored by various States of the Union and referred to as Regional Health Information Organizations ("RHIO"), such RHIOs are generally concerned with and attempt to provide a standard with which to electronically share medical records with care providers, such as hospitals, clinics and physicians. In this RHIO environment, the participating Stakeholders are limited to healthcare providing entities, and the type of information they share is limited to medical records. But, this fails to address the needs of all types of Stakeholders, in all of the various products and services they require, including medical records. Examples of the additional products and services addressed by this invention include but are not limited to: Records and benefits individuals (and their families) derive from their membership in Associations; employment data, including detailed healthcare benefits; records and access to banking products of the individuals for healthcare related accounts, such as Health Savings Accounts and other financial matters, such as records for healthcare tax exemptions; records of medications individuals have been prescribed for and other related issues, such as whether they have purchased their medication, etc. SUMMARY OF THE INVENTION

[0013] The invention satisfies the foregoing needs and avoids the drawbacks and limitations of the prior art by providing a system and methods for the providing interoperability among various stakeholders in the healthcare industry to provide efficient and timely processing of information to delivery effective healthcare.

[0014] An aspect of the invention includes a system for providing interoperability between stakeholders in the healthcare industry including a logically centralized database having information records related to a plurality of different stakeholders, wherein each stakeholder is a member of at least one category of stakeholders include at least a patient member, a medical provider and an insurance company, a plurality of disparate medical records systems each provided by a different vendor and having different internal formats of data and at least one integration component interfaced with each of the plurality of disparate medical records systems to normalize the information in each disparate medical records system and to permit access to the normalized information by the different stakeholders.

[0015] Another aspect of the invention includes a method of providing interoperability for different types of stakeholders in the healthcare industry. The steps include identifying a type of stakeholder, determining a need of the stakeholder, identifying a software component to satisfy the need of the stakeholder based on the type of stakeholder, integrating the identified software component with a medical records system associated with the stakeholder and exchanging data using the integrated software component by converting information in one format into a different format for access by another stakeholder to deliver a healthcare related transaction. [0016] Another aspect of the invention includes a method for providing interoperability in the healthcare industry that includes a system comprising a logically centralized database having information records related to a plurality of different stakeholders, wherein each stakeholder is a member of at least one category of stakeholders include at least a patient member, a medical provider and an insurance company, a plurality of disparate medical records systems each provided by a different vendor and having different internal formats of data, at least one integration component interfaced with each of the plurality of disparate medical records systems to normalize the information in each disparate medical records system and to permit access to the normalized information by the different stakeholders, the method includes the steps of querying the logically centralized database by a first stakeholder, receiving a response from the centralized database that provides information concerning at least a second stakeholder, and completing a healthcare related transaction based on the response.

[0017] Additional features, advantages and embodiments of the invention may be set forth or apparent from consideration of the following detailed description, drawings, and claims.

Moreover, it is to be understood that both the foregoing summary of the invention and the following detailed description are exemplary and intended to provide further explanation without limiting the scope of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are included to provide a further understanding of the invention, are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the detailed description serve to explain the principles of the invention. No attempt is made to show structural details of the invention. In more detail than may be necessary for a fundamental understanding of the invention and the various ways in which it may be practiced. In the drawings:

[0019] Figure 1 is an illustration showing no common infrastructure among stakeholders; [0020] Figure IB is an illustration showing interoperability among stakeholders provided by the invention;

[0021] Figure 2 is a block diagram showing an exemplary architecture and environment of the invention;

[0022] Figures 3A-3F are logical representations of data organization, according to principles of the invention;

[0023] Figures 4A and 4B illustrate the stakeholder processes before and after, respectively, the functional contributions of the invention;

[0024] Figure 5 A is a block diagram illustratively showing aspects of the invention being installed on a client system;

[0025] Figure 5B is an illustration showing a typical existing medical office arrangement, prior to the invention;

[0026] Figure 5C is an illustration showing a typical medical office arrangement, according to principles of the invention;

[0027] Figures 6A-6E are flow diagrams showing steps of providing aspects the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0028] The embodiments of the invention and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments and examples that are described and/or illustrated in the accompanying drawings and detailed in the following description. It should be noted that the features illustrated in the drawings are not necessarily drawn to scale, and features of one embodiment may be employed with other embodiments as the skilled artisan would recognize, even if not explicitly stated herein. Descriptions of well-known components and processing techniques may be omitted so as to not unnecessarily obscure the embodiments of the invention. The examples used herein are intended merely to facilitate an understanding of ways in which the invention may be practiced and to further enable those of skill in the art to practice the embodiments of the invention. Accordingly, the examples and embodiments herein should not be construed as limiting the scope of the invention, which is defined solely by the appended claims and applicable law. Moreover, it is . noted that like reference numerals represent similar parts throughout the several views of the drawings.

[0029] It is understood that the invention is not limited to the particular methodology, protocols, devices, apparatus, materials, applications, etc., described herein, as these may vary. It is also to be understood that the terminology used herein is used for the purpose of describing particular embodiments only, and is not intended to limit the scope of the invention. It must be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural reference unless the context clearly dictates otherwise.

[0030] Unless defined otherwise, all technical and scientific terms used herein have the same meanings as commonly understood by one of ordinary skill in the art to which this invention belongs. Preferred methods, devices, and materials are described, although any methods and materials similar or equivalent to those described herein can be used in the practice or testing of the invention.

[0031] A conceptual view may be taken that the healthcare system may be or could be somewhat analogous to the credit card system. In a credit card system, a consumer receives products and services from a merchant who uses a network (such as VISA) to go to the payer (e.g., the Bank) and receive payment. Similarly, a patient goes to a physician for services, the physician is linked through some clearing house and PPO or HMO network to the payer (the Insurance.) From a technology point of view, both systems are structured somewhat similarly. Even though healthcare is twice as large in annual volume of dollars transacted per year ($2 trillion) it is not even near the level of efficiency that the credit card system enjoys, where payments are performed in near real-time.

[0032] Employers (especially if they are self-insured) are under pressure to reduce expenses, and thus they are open to review products and services that are likely to decrease their expenses at a fraction of the cost. The savings potential to an employer could be as much as 30% reduction in the cost of the healthcare benefits. Thus, employers would likely be motivated to use a system such as EON.

[0033] As explained more below, as an illustrative example, once employees are registered in the EON Exchange (Stakeholders in the healthcare market sector may be served through the invention through a common set of middleware software referred to as the EON Exchange 210a-210d, as illustrated in Figure 2 and described below, where the disjointed healthcare sector obtains interoperability through techniques such as common access, integration, and data warehouse), then they can receive as patients medical care anywhere at any time, so long as there is an Internet access (under patient controlled password) to the patient's medical chart that resides in a secure database that could be managed as an outsourced service, such as in the EON Exchange. In this manner, the patient no longer needs to fill-in the infamous clipboard r at the time of registration, but can be updated beforehand on-line by a patient, and/or accessed by a doctor in real-time during treatment. Once physicians realize the advantages of using the functionality provided by the invention for the employee and how they can (for a small transaction fee) conduct their own business much more efficiently, profitability should rise.

[0034] There are approximately two and a half thousand hospitals (2,500) one hundred twenty five thousand (125,000) clinics and eight hundred fifty thousand (850,000) doctors in the United States. These providers currently attempt to meet their information processing needs by using multiple software programs that usually provide only partial and incomplete solutions. The EON Exchange is designed with an advanced systems architecture that enables an enterprise-wide solution to operate either on a stand alone "client-server" basis or as an internet based ASP service, and in a secure way. The EON Exchange is flexible, expandable for volume, can operate multiple provider sites/facilities as departments of one organization and can be changed or modified in days, versus months for PC based systems and years for Legacy Systems. By design, the EON Exchange is capable of running on any intelligent computer operating system, or as a network-based service. The EON Exchange system can be used together with or separately from the EON Toolbar system.

[00351 A partial list of the advantages provided by the invention is as follows:

• Patient care can be delivered anywhere, anytime, securely to authorized users through various delivery tools, such as the Internet; removable "thumb drive" disks; TV screens; iPods, etc. or even by simply calling a central Help Desk where operators can relay (upon positive authentication of the identity of the caller) certain portions of the person's medical record as needed for urgent care. Prior to the invention, electronic medical record systems are not interoperable. The invention transforms this, so, typically regardless of the systems and technology in use, and thus the advantages mentioned above are obtained.

.• Patients or Members are able to obtain additional information that present day Electronic Medical record Systems do not provide, such as (but not limited to): personal health baseline (screening data) captured earlier or during the enrollment process; real time review of medications purchased; real time comparison of prices of brand name and generic drugs; review of past medical history while at home, either from an Internet connected PC, a PDA, a digital Blue Tooth wireless telephone, the TV screen; and other personal information, as has been previously been authorized; etc.

• Patients or members of an association are uniquely identified through biometric information that is maintained in the EON Exchange, but is captured through the EON Toolbar during the enrollment process of patients or members.

• All Stakeholders receive timely and accurate information on the data they are authorized to obtain.

• Accurate and secure records are maintained of all data that are important to all Stakeholders.

• All Stakeholders can exchange and share authorized information, securely, regardless of the technology and systems they use to store their data.

• Patients or patient members can obtain through the Internet their own healthcare related financial records and attach them to their tax return.

• Patients can access and can authorize providers to access and debit their own personal HSA and FSA health related financial accounts, with appropriate record keeping and tracking.

• Medical providers (hospitals, clinics, physicians, assistants) can obtain near real time insurance verification and predetermination of what the insurance will cover, and how much will be reimbursed by the Insurance carrier and what is the patient' s financial responsibility, while the patient is present and is being discharged.

• AU payments that are due as a result of services rendered by any of the Stakeholders to other Stakeholders can occur in seconds, securely, accurately, on a real time ("7- 24") basis. • Providers that use the EON System can consolidate their back office.

[0036] The invention offers a flexible, scaleable, secure, efficient and comprehensive suite of integrated and patient centric products and services (solutions) that run on any suitable hardware and can use the Internet to address the totality of needs of patients, members, doctor practices, clinics, employers, and other categories of Stakeholders in the healthcare market sector. Logically, the invention unifies all the stakeholders as illustrated in Figure IB.

[00371 Figure 2 is a block diagram showing an exemplary configuration of various components of the invention, generally denoted by reference numeral 200. The invention 200 typically utilizes the Internet 205 as a telecommunications vehicle, or direct telecommunications lines (such as Virtual Private networks) as dictated by the economics of volume.

[0038] Access devices 210a — 21Od which may be various computer servers, lap tops, personal desk top computers, PDAs, etc., having various operating systems, from companies such as Microsoft, Linux, and Apple, for example, permitting users to gain access to the system. To each of such access devices, the EON Toolbar 215a-215b may be down-loaded from the EON Exchange 210 through the Internet 205 as explained in more detail in co-pending U.S. Patent

Application Serial No. , entitled "System and Method for a User Interface for

Performing Distributed Transactions." The toolbar 215 is adaptable so that the displays and content of information are altered based on the identity of the stakeholder using the toolbar 215.

[0039] The system of the invention includes one or more software components 21 Oa- 21Od, referred to generally as the EON Exchange. Although the EON Exchange 210 may be different "nodes," they are part of one logical system. Physically the nodes could be located in facilities many miles distant from one another, and are able to operate independently, in parallel or as a back up to one another. The EON Exchange nodes may be implemented as servers and each typically includes a database 212, such as a SQL database, for example. Peer-to-peer operability may be employed to maintain real-time updates and mirrored imaging of the databases 212, as necessary.

[0040] The toolbar 215 may operate independently from the EON Exchange 210, with one another, and can synchronize their data either at the same instant in time or at various intervals of time, as design parameters, including economics, would dictate. The toolbar is adaptable in operation to conform to the user's identity and functional requirements. For example, a patient using the toolbar would be able to view and access information related only to that patient and prevented from accessing or viewing data not related to the patient (such as a clinic's data). For a clinic's user, the toolbar conforms to the user's identity and presents fields and formats appropriate to the clinic's data while shielding information unrelated to the clinic from the user.

[0041] The logical architecture of the EON Exchange database may be represented by an object having "n" dimensions and may be created and stored in database 212, typically as a relational database. Each of the "n" sides of that object represents a separate domain of data. Some examples of such data domains are: a domain for providers who are independent physicians; a domain for clinics, with multiple physicians in various medical specialties; another domain could be for general hospitals; another for urgent care hospitals; yet another for employers; another for employees; another for associations; another for private insurance plans; another for Medicare plans; another for banking; another for pharmacies, another for tax tables (federal separate from each State, and similar types of data domains associated or found in operation with the healthcare industry.

[0042] Such an "n" dimensional object is difficult to present visually on two- dimensional paper, however, aspects of the multi-dimensional object is shown illustratively in Figure 3 A in the shape of a cube, and generally designated by reference numeral 300.

[0043] As an illustrative example, assume that one side of this cubical object 300, as shown in Figure 3B and designated by the letters a-b-c-d, represents the domain for computational algorithms. Each rectangular square (referred to as "Grid Rectangle") in that side (a-b-c-d) corresponds to a different algorithm. As one of many possible examples, a computational algorithm may be the calculation of the patient responsibility amount of a given claim, based upon the cumulative value of the total claims submitted to date for a given group of networked coverage; another example of an algorithm may be the tracking of max-min readings of test results for a specific medical condition, accompanied by certain actions that vary upon the value of the actual test results, and so on.

[0044] In a similar fashion, assume that on the side represented by the letters a-b-e-g in Figure 3C the domain for clinics are located. Each Grid Rectangle in that side corresponds to a different clinic, for which clinic, a set of unique data would apply. For example, the Universal ID numbers for each of the doctors in one clinic would be different from those of the doctors in another clinic, and so on.

[0045] Yet again, the side represented by the letters b-c-f-e in Figure 3D denotes the domain for private insurance companies. For example one Grid Rectangle might represent the negotiated contract for one clinic with a private insurance carrier and then another Grid Rectangle might represent a different contract that has been negotiated by the same insurance carrier with another clinic, and so on.

[0046] Moreover, in Figure 3E, the area marked by the letters a-d-h-g denotes another side of the illustrative cubic shape, and that side represents all the patients. Each Grid Rectangle in that side would represent different data for each patient, such as their personal demographic data; their family data in another; their individual medical records in yet another, and so on.

[0047] The other side, side e-f-h-g, of the illustrative cubic object in Figure 3F could represent employer data, such that each Grid Rectangle of that side could be the benefit health plans for employees, which may be different from those of their family members in another Grid Rectangle, or workman compensation cases in yet another Grid Rectangle, and so on.

[0048] In this example, a given Grid Rectangle in Figure 3E may relate to a specific issue with regard to a patient, which in turn would link with another Grid Rectangle in Figure 3F that identifies specifics to do with the employer of that patient, then they link to another specific Grid Rectangle that identifies a specific clinic that provided care depicted in Figure 3C, and which care was covered by specific conditions of the insurance carrier as per a specific Grid rectangle in sub-diagram 230 and they in turn may link to another specific Grid Rectangle that identifies the applicable payment algorithm in the sub-diagram 210.

[0049] Thus in this example, all the Stakeholders are linked to specific services and create unique linkages that are then computing the correct value of a given algorithm, which then is processed and recorded in the database of EON Exchange. In this manner, the separation and differentiation provided by the grid concept (and implemented in a database such as, for example, an SQL database, and/or MUMPS (Massachusetts General Hospital Utility Multi-Programming System), provides intrinsic security by preventing certain entities from accessing data or information that they cannot gain access while gaining access to information that they are granted access. For example, a doctor's office could not gain access to a patient's employee related information associated with an employer. [0050] However, the invention also provides features to already existing commercial healthcare products for the purpose of re-engineering of the business workflow processes of healthcare providers. For example, Figure 4A depicts a typical workflow process at a clinic, where some of the business workflows are automated, but others are not. Cloud 410 shows that existing third party Electronic Medical Record systems leave automation "gaps", such as (but not limited to): only over the telephone, manual verification of insurance eligibility; no automated verification of the identity of the patient; no base line of health data available to assist in the diagnosis and protocols for treatment; no predetermination of insurance payments; reduce claim rejection and diagnosing error risks by matching procedure with diagnostic codes, and the like. The invention provides for the integration of such types of additional functionality, which enhance the efficiency of existing systems and streamline the business workflows of the medical practices/clinics.

[0051] Thus Figure 4B shows additional functionality, described below, provided by the invention and denoted as processes 470, 480 and 490, which are added to the clinic and shows how business workflows are improved through the new automation that the invention accommodates. For example, such automation may include software components to translate and bind third party vendors' software to one another so that the once unrelated third party software may share data for performing a transaction. Such integration becomes possible through the invention (even of dissimilar systems - also possible that some older systems may not have to be replaced as they may possible to integrate them with the EON Exchange system.) For example, the automation that identifies insurance eligibility results in the elimination of telephone calls to perform this task; the removal of this manual step normally results in a 10-15 minute gain in the time it takes to process and register a patient. [0052] Another work flow advantage that re-engineers the processes of a medical practice is the ability the invention provides to predetermine the value of the payment from the insurance payer, and thereby also predetermine the amount of the portion of the payment that is the responsibility of the patient, while the patient is in the medical office, thereby eliminating all future payment steps such as billing and mailing, as well as promptly determining the primary versus secondary insurance coverage, thereby settling all insurance payments at patient discharge time. This is accomplished by accessing the EON Exchange databases to ascertain the insurance plan and payment requirements for the patient.

[0053] It should be noted that from a patient, an employer and an insurance Stakeholder point of view, such additional data may be in effect altering the way providers operate, in that the norm at present is for patients to seek medical care to fix a symptom or an illness that has taken place. However, with a baseline of health records (health screening) preventive care can take place based on test results, before the onset of illness.

[0054] Similarly, outcome data (metrics of success to treatment or drug therapy, or a pharmaceutical patient outcome) are also maintained, and such outcomes can affect the overall health of the general public, because of curative measures (preventative, habitual, or otherwise) that can be suggested when data are compiled as impersonal statistics for various medical conditions, by gender, by population centers (geography) by racial profile, by educational or economic stratification, etc.

[0055] Another way to describe aspects of the invention is shown in Figure 5 A. In this example, the invention is used at a clinic that has or is acquiring an Electronic Medical Record (EMR) system from a third party. One or more software component(s) 510 of the invention "inserts into" or "^■surrounds" that third party EMR 522, and in addition, may accommodate any special client requests for customization (depicted by reference numeral 560, and which become integrated with EON Exchange) and assists the clinic with any changes that is needed to be implement, as depicted by reference numeral 520, such as upgrades to their clearing house for claims processing; input of the physicians AMA ID number; defining and assisting the clinic to implement new work flow procedures, or the like. Furthermore, these third party products are supplemented by implementation services (530) that are needed to effect the changes, and may include new definitions for the telecommunications network; other services, such as Project Management (540); long term support services (550), or the like.

[0056) Once the software components) and implementation services are implemented at a specific medical specialty, then other customized solutions (570) can be constructed as part of the implementation services, as necessary, for additional medical specialties.

[0057] The invention provides the additional operating capability of consolidating into one "back office" even dissimilar technology and systems (different programs, different software architectures, different operating systems, etc.) even when the EMR portion of the software products remain separate and dispersed, even when there is a different one per medical office. "Back office" refers to a logically single (physically it may be many) administrative and management function for tasks such as booking of appointments, preparation of coding of claims, submitting such claims to insurance and other private payers, accounting and bookkeeping functions and the like.

[0058] Figure 5B shows the existing scenario prior to the invention offered by others, where they need to maintain or install either completely separate stand alone systems — one for each physical location (that offer the detailed features some of the medical specialties require) or subscribe to an ASP (ASP refers to Application Service Provider, a solution whereby the same software resides in some central location on one logical computing processor and database, thereby forcing all users to share the same level of detailed functionality without the capability to offer economically a solution that differs from medical specialty to medical specialty) model that offers an identical set of software features to all, regardless of whether they need more or specific functionality to accommodate the needs of their specialty. This problem may become significant when the client owns multiple medical specialties in many different geographic locations, and thereby is forced to have redundant staff in each location.

[0059} The system and process of the invention does away with this problem due to its ability to consolidate and normalize disparate information, as well as integrate. Figure 5C shows the effect of consolidation and integration through the invention, whereby many different EMRs, including those from different vendors with disparate internal information formats, are able to be consolidated into a single back office, while keeping different software (different operating systems, different programs, etc. designated generally by reference numeral 625). The advantages of such integration include but are not limited to the ability to: operate as a single business entity; have a unified database for records (lessens errors and reduces costs); deploy a system that requires information is key entered only once (lessens errors, reduces costs); avail of the ability to run a single much simpler to operate and maintain, less expensive web site, etc.

[0060] Consolidation of multiple front office (patient care) EMR systems into one back office system offers improved control and accuracy when aggregating clinical data and higher operating efficiency through the ability to perform all administrative and financial functions in one location, thereby attaining economies of scale.

[0061] A further advantage provided by the invention is the ability to integrate with other third party devices (either existing devices, designated by reference numeral 635a, or as new additional devices, designated as reference numeral 635b) that then interface with the back office through the EON Exchange 655 other third party products are also shown in Figure 5C. Some examples of such devices include: RFid (radio frequency control ID devices); remote voice transcription; heart monitoring; pulmonary testing devices, etc.; and other testing devices, such as tether-less personal monitoring devices (Blue Tooth telephones, PDAs, etc.) all conveying data into the EON Exchange thereby producing more automated and streamlined workflows, as well as accommodating rapid service through remote access to the EON system from which to obtain the patient's medical record remotely, in cases of emergency care. [0062] The invention also manages processes securely so that users can enjoy an additional number of advantages, such as: seamless enterprise- wide functionality across multiple sites or in a campus environment, thereby obtaining reliable performance; ease of operation; optimizing patient care; optimizing business performance, and the like.

[0063] The invention creates "Clean Claims" for insurance reimbursements through our secure processes. A "Clean Claim" is produced when all necessary and required steps are prompted by the EON system and are either completed by the system automatically or alerts the user as to what is required. I.e., completeness and accuracy are checked prior to submission to an insurance company. For example, some insurance plans require the submission of an x-ray that has been signed by the attending physician; else it will not be reimbursed. In present day practice, most providers submit claims electronically, but signed x-rays are submitted by Postal Service. This separation of documents (even when both are submitted, and often they are not) creates a lengthy process of matching one submission with a separate transmission through another trail. At best, the claim gets processed, but it typically takes on average 90 to 120 days. A Clean Process assures that the necessary steps have been taken and the claim is "clean" for processing. If the claim generated is a "Clean Claim," then the system arranges (for its clients that select this option, perhaps for a fee) to have an advance of up to 80% of the value of clean insurance claims paid to the medical provider typically within 24 to 48 hours. Then, the EON system automatically pursues the claim with the insurance payer and whenever they reimburse the practice, optionally, a fee may be deducted prior to providing the remainder to the provider.

[0064] Figures 6A-6E are flow diagrams showing steps of an embodiment of the invention, starting at step 700. Figures 6A-6E, as well as any other flow diagram herein, may equally represent a high-level block diagram of components of the invention implementing the steps thereof. All or a subset of the steps of Figures 6A-6E, and all the other flow diagrams, herein, may be implemented in computer program code in combination with the appropriate hardware. This computer program code may be stored on storage media such as a diskette, hard disk, CD-ROM, DVD-ROM or tape, as well as a memory storage device or collection of memory storage devices such as read-only memory (ROM) or random access memory (RAM). Further, the computer code may also be embodied, at least in part, in a medium such as a carrier wave, which can be extracted and processed by a computer. Additionally, the computer program code and any associated parametric data can be transferred to a workstation over the Internet or some other type of network, perhaps encrypted, using a browser and/or using a carrier wave. The steps of Figure 6A-6E, as well as the other flow and relational flow diagrams herein, may also be implemented in the environment of Figure 2, for example.

[0065]: Continuing with step 710, when a user accesses the EON Exchange 210, typically via EON Toolbar 215, the type of user (e.g., employer, insurance company, hospital, clinic, or the like) and the identity of the user. At step 720, a determination is made as to what needs are being requested. For example, a request may be made to inquire about all the patients in a particular area who are on a particular medication. Or, perhaps, a request is being made to summarize the costs associated with a particular medical code. In general, a request may be made to acquire any data maintained in the system database which is typically maintained in a relational database, or similar type of database. Exemplary types of data that may be maintained and/or queried by the invention is listed in Appendix-4. Of course, any type of data associated with business operations (such as financial, employee and/or cost data) or data associated with records for patients or clients may be queried.

[0066] At step 730, a determination or review is made as to whether necessary data and/or supporting software is already existing as part of the EON Exchange. This is explained more fully in relation to Figures 6C-6E, below. At step 740, a determination is made if a particular application programming interface (API) is available for the particular type of user (e.g., a hospital interface, a pharmacy interface, or an insurance company interface). If the requested/required API is not available then at step 750, a new API is developed or acquired. Processing continues at step 780.

10067] If however, at step 740, there is an API already available, then at step 760 a determination is made whether the requested user needs are adequately addressed by the EON Exchange. If not, then at step 770, new functionality is developed. If, however, the needs are addressed, then at step 780, any new development is integrated with the EON Exchange as part of its operational capabilities.

[0068] At step 810, connectivity with the user is established and tested to verify operational suitability of the new API related functionality. At step 820, an end to end test of functions related to the interoperability is performed. This verifies and validates correctness and completeness of communications and data integrity. At step 830, a determination is made whether all tests have succeeded. If not, corrections are performed related to the failure modes and the process continues at step 810. If, however, all tests pass the tests, then at step 840, the new functionality is promoted to production and accounting for general use. At step 850, a check is made whether there are additional user needs. If there are more needs, then the process continues at step 720. If there are no more needs, then the process terminates at step 860.

[0069] The process for determining user needs at step 720 is further detailed in relation to Figure 6C, beginning at step 9 IQ. The existing EON Exchange database 212 may include database components (or portions of a database) associated with various exemplary stakeholders such as members/patients 920, hospitals, 930, clinics, 940, pharmacy, nursing services and/or employers 950, or any other similar stakeholder. These databases are checked for current functionality.

[0070] The current functionality check is illustratively shown as step 1010 (Fig. 6D), where the relevant database(s) may be checked for current functionality support (typically, but not exclusively, software) such as, for example, demographics 1020a, biometrics 1020b, health screening 1020c, medical records 102Od, employment 102Oe, membership 102Of, banking info 102Og, medications 102Oh, outcomes 102Oi, family records 102Oj, patient care 1020k, account maintenance 10201, and/or other functionality 1020m. At step 1100, a check is made if an algorithm is required to fulfill the user needs. The algorithm may be any specific software module to calculate or transform data, such as for example, computing the average cost per visit for a patient. Or, perhaps, the algorithm may be for calculating the average number of people who have had a heart attack in a age range. If so, then at step 1440, the algorithm is processed and at step 1440, the appropriate database is updated with the results. The process continues with step 740. If no algorithm is necessary at step 1110, then at step 1120, a check is made whether a databases must be updates with new information, if not the process ends at step 1160. If an update is necessary, then the process continues at step 1140, described previously.

ALTERNATIVE DESCRIPTION

[0071] As an alternative, non-limiting description in view of the previous descriptions, EON Exchange may in aspects be a distributed system with intelligence (processing) and repository of records at many physical locations. The underlying assumption was that customers would have a relationship with a "Home" location (referred to as "Clinic", though it may be a Clinic, but also a place of employment, a hospital, etc. and as such, the large majority of transactions would have been done at that (local) Clinic. The convenience of EON Exchange allows customers to make transactions at other (remote) Clinics. EON Exchange is designed to operate with the following attributes:

1. A Reliable Network System

2. Database Synchronization

3. A Central Head Office System (typically performing administrative and accounting services)

4. Multiple Clinic Systems

A Reliable Network System:

[0072] The distributed design infers that the majority of transactions that take place at a Clinic are local transactions on the local network. However, whenever the need for an EON type transaction arises, it is necessary for the network to other Climes to be available. Database Synchronization:

[0073] EON Exchange may employ a daemon or two running on each server and a table (sync_db) that hold the transactions and instructions for database synchronization. Alternatively, peer-to-peer synchronization may be employed. Today, nearly all commercial databases come with database replication so there is no need to elaborate on the synchronization used with EON Exchange. Implementation of EON Exchange today takes advantage of the native data replication provided by the database.

A Central Head Office System:

[0074] Distributed Systems design has many advantages, but a hurdle is the need for centralized administration and reporting. The Head Office concept took care of this, type of problems. Business-wide rules are entered into the EON Exchange at the Head Office, and Database

Synchronization is used to push those rules out to every Clinic sub-system. At the same time, any database activity taking place at the Clinics, are pushed to the Head Office making data readily available for centralized reporting. The Head Office is typically Clinic Number "H000".

Multiple Clinic Systems:

[0075] Database activity taking place at the Climes, are pushed to the Head Office using database synchronization. Clinics receive business-wide rules from the Head Office by the same method. Clinics are typically given Clinic Numbers such as "0001" and "0107".

[0076] At the lowest level, an EON transaction may be a remote SQL DML using industry standard syntax. For example:

SELECT <columnjist,..> FROM <schema.xtable>@<database_link>;

[0077] The SQL DML statements are generated by the application software, depending on which EON Clinic is the target of the SQL. The application components are implemented with databases on each Clinic server set up in the same manner. The data is set up in a schema called "ubanks" and the user is also called "ubanks". Permissions allow remote users fall access to the local database as long as the user name is the same. The application overwrites the actual logged-in user name with the generic "ubanks" to simplify administration. However, alternative implementation of EON uses the actual authorized user to eliminate any security risk.

[00781 Since the user of the data is always the owner of the schema, the application does not have to locate that information to generate the IHCS SQL DML. All it needs to get is the database_link for the Clinic it is trying to reach. That is found in the clnc_db table.

CLNC DB Table:

[0079] The clncjib table is at the center of the EON Exchange design because it holds the Unique Clinic Numbers (primary keys) and the connection information for all Clinics in the system, including the Head Office. It also keeps the next sequence number for all the types of accounts that customers could open. The Head Office always has Clinic number "H000" and other Clinics were given Clinic numbers such as "0001" and "0107," for example. This table is designed to contain two rows at the Clinic level. When each Clinic is set up, its new Clinic information is synchronized to the Head Office.

[0080] The Head Office has the connection information for every Clinic in the system in its clnc_db table. The invention is designed to make a remote read to the Head Office to get the connection information (database_link) for the Clinic with which your Clinic wants to communicate (in the CLNC_DATABASEID column). To get the Head Office database link information in your local table, the following exemplary instructions may be used: SELECT CLNC_DATABASEID FROM CLNC_DB WHERE CLNC_NO = 'HOOO' ; --(returns bOOOO_db)

[0081] To get the target Clinic database_link information from the Head Office, the following exemplary instructions may be used:

SELECT CLNC_LOCAL_SYSID, CLNC_DBASE_SYSID, CLNC JDB_SERVERID, CLNCJDATABASEID FROM CLNC_DB@b0O00_db WHERE CLNC_NO = '0107'; --(returns b0107_db)

[0082] When the target Clinic connection information is retrieved, a SQL DML query may be generated to perform direct remote data manipulation of the data in the target Clinic. SELECT ACCT_STATUS FROM SAV_DB@b0107_db WHERE ACCTJKEY = 12345670107;

[0083] Note that the SQL in the actual program code may be written as though it were being executed on the local machine. It is the External User Interface (XUI) that transforms the query at run time into a remote query.

[0084] Alternatively, the read to the Head Office may be eliminated to get the connection information for a Clinic. It involves having the clnc_db at every Clinic contain rows for every Clinic so that the target Clinic database_link information can be retrieved locally. TABLE 2 shows a detailed exemplary layout of clncjlb.

HOME CLINIC:

[0085] When a patient walks into a Clinic (perhaps Clinic 0001), and asks to be set up as a patient, the application uses a remote SQL search of the Head Office to be sure that the patient was not already set up anywhere in that Clinic. A record may be inserted in the cust_db table (see Table 3) for the new patient and the column CUST_HOME_CLNC and set to the code of that Clinic (0001), making that Clinic the patient's Home Clinic. The patient may proceed to receive healthcare services (Patient Account type #1) in one medical specialty at that same Clinic on that same day. The Home Clinic for that healthcare service would have been that Clinic (0001). The next day, the same patient could go to another Clinic, say Clinic 0107, to receive medical services in the same or a different medical specialty (Patient Account type #2). The registration process uses a remote SQL search of the Head Office to be sure that the patient is not already set up anywhere in that Clinic. It would find that the patient "belongs" to Clinic 0001. The EON process then copies a mini patient record down to Clinic 0107 in a table called xtacjib (see, Table 4). The Patient Account is then opened for the patient, but the Home Clinic of that Checking Account would still be Clinic 0107.

[0086] The xtacjib is used for retrieving patient identification information locally. But it is not sufficient for generating monthly statements because the patient address information still resides at the Head Office and Home Clinic. Generally, the concept of allowing the patient to create accounts at Clinics other than the Home Clinic caused numerous issues in the distributed architecture. ACCOUNT NUMBER and HOME CLINIC:

[0087] When the patient opens a Patient Account at their home Clinic, the account number is generated for that account using the next available seven digit savings account number found in the CLNCJS AV_NO column of the local clnc_db table (which may have been 1234567, for example). To that seven digit number, the system appends the Clinic number of the home Clinic, so the account number for that patient account would have been 12345670001 , fro example. The CLNC_SAV_NO column is then incremented by one. So the general "rule" is that the home Clinic of an account can be easily determined by identifying the last four digits of the account number. But there is another column that is used if a remote read of the Head Office is forced.

[0088] The Home Clinic number is carried explicitly in the ACCT_HOME_CLNC column of the sav_db table. If the extraction of the Clinic number ftom the account number does not return a valid Clinic, a remote read of the sav_db table at the head office is done and it looks in this column. Patient Account are set up in the sav_db table and the account number is the primary key to that table(the ACCTJKEY column).

[0089] When the patient opens a different type of Patient Account at Clinic 0107, the same process transpires with the last four digits of that account number being 0107, and the ACCT_HOME_CLNC column also having 0107, for example. Table 5 shows the exemplary layout of savjdb.

EON PROCESSING:

[0090] Referring to the pseudo code in Table 1 below as an example, when a patient presents an EON Member Card to a receptionist, it typically includes the Account Type and Account Number to which that transaction pertains. The system accepts the account type and account number entered by the registering person. The account type tells the system which table to pull the information from; account type SV meant looking into sav_db and DD meant looking into dda_db. The account type mapping is typically kept in memory.

[0091] The EON system takes the last four digits of the account number and compares it with its own Clinic number which is also kept in memory. If a match is found, a local transaction is started. The comparison may be done by XUI. If the Clinic number extracted from the account number does not match the local Clinic number held in memory, the system then looks into clnc_db to find a match for the extracted Clinic number. The match tells the system which remote database to connect with to perform an EON transaction. A "remote session" is opened in the program code which signaled XUI to generate remote SQL whenever it encountered regular SQL in the program. A "close remote session" command in the program disables the remote SQL facility.

[0092] EON Exchange may be implemented with XUI, but that is not necessary, as there are other known implementation languages for a modern implementation.

TABLE l

Pseudocode: Patient Diagnostics or Patient History transaction

Prompt/Accept Account Type Prompt/Accept Account Number

XUI Uses Account Type to determine which Account table (Diagnostic, Family History, Social History,...) and set up in $CALL-DBID(sav_db)

Extract last 4 digits of account number XUI checks if it's a local account If local account Then

Proceed to DO_TXN_BLOCK Else

Read clnc_db for Clinic number If Clinic_number does not exist in clnc db Then Open remote session to Head Office Select acct_home_clnc

From $CALL-DBID(sav_db) Where acct_key = Accepted Account Number Close remote session to Head Office Open remote session to Home Clinic of Account Else (Clinic_number found in cmc_db)

Open remote session to Home Clinic of Account End If End If

DO_TXN_BLOCK:

The SQL statements in the program looks like local SQL It is the remote session flag that causes XUI to capture the SQL and generate remote queries using the database_link. Sav_db is updated. Sav_tx is inserted. Jnal_tx is inserted In the remote database with flags to indicate the entry Clinic. if a remote session is detected, it is closed. cash_db and others are updated. Jnal_tx at the entry Clinic is inserted

End of transaction

10093] The following APPENDIX-I is an exemplary description of the various database elements that may be maintained as part of the EON Exchange. These elements are searchable and updateable by the Stakeholders, typically through the EON Toolbar, subject to security authorization controls to protect information from unauthorized access. Appendix-I is organized into three columns, "Application," "Functions," and "EON SYTEM Features." The "Application" column refers to the software application that provides the functions as shown in the "Functions" column. The "Functions" column describes the basic function being provided, while the "EON SYSTEM features" column more fully describes the characteristics or capabilities of the "Functions" for the "Application," in more detail.

APPENDIX-I

TION Functions EON SYSTEM Features

I Contac

[0094] Various modifications and variations of the described methods and systems of the invention will be apparent to those skilled in the art without departing from the scope and spirit of the invention. Although the invention has been described in connection with specific preferred embodiments, it should be understood that the invention as claimed should not be unduly limited to such specific embodiments. Indeed, various modifications of the described modes for carrying out the invention which are obvious to those skilled in the art are intended to be within the scope of the following claims.

Claims

What is claimed is:

Claim 1 : A system for providing interoperability between stakeholders in the healthcare industry, comprising: a logically centralized database having information records related to a plurality of different stakeholders, wherein each stakeholder is a member of at least one category of stakeholders include at least a patient member, a medical provider and an insurance company; a plurality of disparate medical records systems each provided by a different vendor and having different internal formats of data; and at least one integration component interfaced with each of the plurality of disparate medical records systems to normalize the information in each disparate medical records system and to permit access to the normalized information by the different stakeholders.

Claim 2: The system of claim 1, wherein the normalized information is maintained in the logically centralized database.

Claim 3: The system of claim 1, wherein the medical provider includes at least one of: a pharmacy, a hospital, a clinic;

Claim 4: The system of claim 1, wherein the plurality of different stakeholders includes a financial institution or an employer.

Claim 4: The system of claim 1, further comprising a network for interconnecting the stakeholders and the logically centralized database. Claim 5: The system of claim 1, further comprising a user interface to permit the different stakeholders access to the logically centralized database, wherein the user interface adapts in format and information content base on the category of stakeholder or identity of the stakeholder.

Claim 6: The system of claim 1, wherein the at least one interface component further provides communication with a back office, wherein the back office supports the plurality of disparate medical record systems.

Claim 7: The system of claim 6, wherein the back office provides at least any one of: aggregated clinical data, administrative functions and financial billing functions.

Claim 8: The system of claim 1, wherein the logically centralized database is substantially located in different geographical locations.

Claim 9: The system of claim 8, wherein the logically database is synchronized in real-time.

Claim 10: A method of providing interoperability for different types of stakeholders in the healthcare industry, the steps comprising: identifying a type of stakeholder; determining a need of the stakeholder; identifying a software component to satisfy the need of the stakeholder based on the type of stakeholder; integrating the identified software component with a medical records system associated with the stakeholder; and exchanging data using the integrated software component by converting information in one format into a different format for access by another stakeholder to deliver a healthcare related transaction.

Claim 11 : The method of claim 10, wherein the different types of stakeholders include at least any two of: a patient, a healthcare service provider, an employer, a pharmacy, a pharmaceutical company, a clearing house, a government that regulates insurers, an association, a union, a laboratory, financial institution and an insurance company.

Claim 12: The method of claim 10, wherein the type of stakeholder includes a specialist healthcare provider.

Claim 13: The method of claim 10, further comprising customizing an existing medical records system for the stakeholder in order to communicate information with other stakeholders.

Claim 14: The method of claim 10, wherein the healthcare related transaction comprises a clean claim for an insurance related transaction.

Claim 15: The method of claim 14, wherein the clean claim is verified for completeness and accuracy prior to submission to an insurance company. Claim 16: A method for providing interoperability in the healthcare industry that includes a system comprising: a logically centralized database having information records related to a plurality of different stakeholders, wherein each stakeholder is a member of at least one category of stakeholders include at least a patient member, a medical provider and an insurance company; a plurality of disparate medical records systems each provided by a different vendor and having different internal formats of data; at least one integration component interfaced with each of the plurality of disparate medical records systems to normalize the information in each disparate medical records system and to permit access to the normalized information by the different stakeholders; the method comprising the steps of: ^• querying the logically centralized database by a first stakeholder; receiving a response from the centralized database that provides information concerning at least a second stakeholder; and completing a healthcare related transaction based on the response.

Claim 17: The method of claim 16, wherein the healthcare related transaction comprises any one of a patient record update, a patient information lookup, a pharmaceutical patient outcome, a financial transaction, an insurance claim and a report based on aggregated data related to a plurality of patients.