Patent Application
20060095303
1. Technical Field
The present invention relates to an improved health care system. In particular, the present invention relates to adjudication of claims in a claims processing system. Still more particularly, the present invention relates to a generic mechanism for adjudication of claims in a claims processing system.
2. Description of Related Art
Claims-processing in health care is a highly complex task. Typically, a claim for payment is submitted by a medical provider to one or more payers after a patient visit. Examples of medical providers include physicians and physician groups, hospitals, medical centers, pharmacies, and laboratories. Examples of payers include commercial health and accident insurance companies, workers' compensation organizations, third party administrators, managed care companies, pharmaceutical companies, and government agencies.
Under current claims-processing environment, most medical providers do not submit their claims directly to the payers. Instead, the medical providers submit their claims to a clearing house application, which verifies and validates the claims against a set of rules defined by the payers. The clearing house application also provides an electronic connection to the payers for adjudication and returns the results to the medical providers. Each payer defines its own set of rules for validating claims by adjudicating the claims against a defined set of business rules. The business rules include requirements for accepting the claims, such as, for example, patient's name, date of birth, and social security number, etc. The process of accepting claims, validating claims based on a set of pre-defined rules, and returning results of the claims is known as adjudication.
One example of a clearing house application is Claims Manager, a product available from Ingenix, Inc. Claims Manager accepts claim transactions from medical providers, analyzes the transactions based on a set of rules pre-defined by the payers, and returns results including information about the correctness of data in the submitted claim. If the claim is valid, Claims Manager returns the claim and the transaction results.
However, clearing house applications, such as Claims Manager, requires the medical providers to submit the claims using a proprietary internal message format, for example, the Ingenix message format, developed by Ingenix, Inc. The internal message format creates problems for developers of host systems used by the medical providers, since developers must codify the host systems to translate information submitted by the providers to the internal message format. This creates additional overhead in time and cost for the medical providers.
In addition, most claims-processing applications currently used by host systems are client-based applications, which require installations on the host systems prior to operation. This leads to an abundance of maintenance issues, as updates to these applications have to be manually installed. Therefore, there is an increasing demand for a Web based solution for claims adjudication that does not require manual maintenance and may run on different platforms.
Therefore, it would be advantageous to have an improved method, apparatus, and computer instructions for a generic mechanism for adjudication of claims in a claims processing environment, such that medical providers may submit claims for validation generically without first converting the information into an internal message format.
A method, apparatus, and computer instructions are provided for a generic mechanism for adjudication of claims for a claims processing system. In a preferred embodiment, medical providers may submit claims via a Web service module. In an alternative embodiment, claims may be submitted via a Web portal from a third party practice management system. When the claims are received, the Web service module or the Web portal converts claim information into a generic message format. The generic messages are sent, either directly from the Web service module or via a batch loader, to an interface engine where they are validated using a claim schema.
If the messages are valid, the interface engine converts the generic messages to an internal message format and sends the internal messages along with a set of templates obtained from the payers to a clearing house application for adjudication. When return messages are received from the clearing house application, the interface engine converts the return messages back to generic messages and validates the generic messages with a return message schema. The valid generic messages are returned to the host system and sent to the payer for approval. The invalid messages are returned to the host system for correction.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
The present invention provides a method, apparatus, and computer instructions for a generic mechanism for adjudication of claims in a claims processing system. The present invention provides a generic mechanism, which includes an interface engine that operates between host systems and clearing house applications, such as Claims Manager. In addition, the mechanism of the present invention includes a Web services module that interacts with a smart client for gathering claims information. Furthermore, the mechanism of the present invention includes a Web portal that handles high volume claim submission from multiple medical providers.
The Web portal of the present invention may interact with a practice management system (PMS) to batch load a high volume of claims. PMS are third party applications that medical providers use to manage their practice. PMS includes patients' bibliographical information and medical histories. By providing a Web portal to PMS, medical providers may directly upload a batch of claims using information from PMS without having to manually input individual patient information and histories. All that medical providers have to do is to ensure the information in PMS conforms to the interface engine of the present invention.
When a medical provider inputs claim information, through a Web service module at a host system, the claim information is formatted into messages in a markup language format, such as extensible markup language (XML). However, other generic message format may also be used. After claim information is formatted into XML messages, the Web service module sends the messages to the interface engine of the present invention.
If the claims are submitted via a third party PMS, the Web portal converts the claim information into XML messages and uploads the messages to a batch loader. The batch loader periodically checks to see if messages are uploaded and sends uploaded messages to the interface engine of the present invention.
The interface engine of the present invention facilitates adjudication of claims by using two extensible markup language (XML) schemas: a claim schema and a return message schema. The interface engine of the present invention first validates the XML messages using the claim schema. The claim schema defines a set of elements that represent different segments of a message according to the internal message format.
If the messages are validated, the interface engine of the present invention then converts the XML messages into the internal message format and submits the internal messages to the clearing house application, such as Claims Manager. In turn, the clearing house application uses templates defined by each payer to determine if there are any errors associated with the messages received. Templates include a set of rules defined by each payer for adjudication of claims. In a preferred embodiment, the templates are obtained by the interface engine from the payers. If the messages include any errors, the clearing house application returns those messages with the error to the interface engine of the present invention. Otherwise, the clearing house application simply returns the messages. The returned messages are adjudicated messages.
When the interface engine of the present invention receives the adjudicated messages, the interface engine converts these messages from the internal message format back to a markup language format, such as extensible markup language (XML). After the adjudicated messages are converted, the interface engine of the present invention validates the XML adjudicated messages by using a return message schema. Once the XML adjudicated messages are validated, the XML messages are sent back to the Web service module.
If the claim is adjudicated successfully, meaning that no error is found, the Web service module may format the claim into a Health Level Seven (HL7) extensible markup language (XML) format and send the claim to the payer for approval. HL7 is an American National Standards Institute (ANSI) standard of electronic data transfer for a particular health domain, such as the insurance domain. Level Seven refers to the application level, which addresses the definition of data to be exchanged, the timing of the interchange, and the communication of certain errors to the application.
When the payer approves the claim, the payer sends an approval message back to either the Web portal or the Web service module. Thus, claim processing is complete. On the other hand, if the claim is not adjudicated successfully, meaning that errors need to be corrected, the Web service module notifies the medical provider to correct the errors and resubmit the claim for a second adjudication. The following figures provide an overview of a background and detail descriptions of preferred embodiments of the present invention.
With reference now to the figures,
In the depicted example, server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 are connected to network 102. These clients 108, 110, and 112 may be, for example, personal computers or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112. Clients 108, 110, and 112 are clients to server 104. Network data processing system 100 may include additional servers, clients, and other devices not shown. In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational, and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN).
Referring to
Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI local bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to clients 108-112 in
Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI local buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, data processing system 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.
Those of ordinary skill in the art will appreciate that the hardware depicted in
The data processing system depicted in
With reference now to
An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in
Those of ordinary skill in the art will appreciate that the hardware in
As another example, data processing system 300 may be a stand-alone system configured to be bootable without relying on some type of network communication interfaces. As a further example, data processing system 300 may be a personal digital assistant (PDA) device, which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.
The depicted example in
Turning now to
When a medical provider submits a claim via host system 402, host system 402 converts the claim information into an internal message format understood by clearing house application 404. Host system 402 then connects to clearing house application 404 using a communication protocol, such as TCP/IP, and transmits the claim to clearing house application 404 for adjudication.
Upon receiving the claim, clearing house application 404 either places the claim in queue 406 for later processing or adjudicates the claim using a set of rules defined by payer 414 in a number of templates 412. Templates 412 are stored in rule engine 408. Once the claim is adjudicated, the claim is stored as a record in history database 410 prior to being returned to host system 402.
As shown in
Turning now to
When medical providers submit a claim via host system 502, the present invention provides Web service module 504 that may be implemented in association with host system 502, such that medical providers may enter claim information via a Web browser. Web service module 504 may be implemented using any existing Web services platform, including Microsoft .NET, a product available from Microsoft Corporation.
Upon receiving claim information, instead of directly submitting the claim to clearing house application 518, Web services module 504 parses the claim information and converts the information into generic messages using a markup language format, such as extensible markup language (XML). Web services module 504 then sends the XML messages to interface engine 512, which validates the XML messages with claim schema 526 before converting the XML messages into an internal message format. In this way, host system 502 does not have to have knowledge of internal message format in order to submit claims for adjudication.
Claim schema 526 identifies segments of an internal message according to the internal message format that are required for clearing house application 518 to adjudicate the claim. If the XML messages are validated, meaning that the XML messages are valid messages according to the internal message format, interface engine 512 converts the XML messages to the internal message format and sends the messages to clearing house application 518.
On the other hand, instead of submitting each claim individually, medical providers may submit high volumes of claims via host system 502 using a third party practice management system (PMS) 508. PMS 508 is a system used by medical providers for managing their practices. PMS 508 includes patient bibliographical information and medical histories.
When medical providers submit their claims using PMS 508, the claims are submitted via Web portal 510, which is a Web-based interface that uploads claims from PMS 508 to batch loader 506. Before claims are uploaded from PMS 508 to batch loader 506, Web portal 510 converts the claim information into generic messages using a markup language format, such as extensible markup language (XML).
Batch loader 506 checks periodically for messages that are submitted by PMS 508 via Web portal 510. When batch loader 506 detects a set of submitted messages, batch loader 506 sends the XML messages to interface engine 512. Similarly, interface engine 512 validates the XML messages with claim schema 526 before converting the XML messages to the internal message format and sending the messages to clearing house application 518.
Before internal messages from Web services module 504 or batch loader 506 are sent to clearing house application 518, interface engine 512 obtains a set of rules defined by payer 524 using a set of templates 516. Templates 516 are used by clearing house application 518 to adjudicate claims and detect if there are any errors in the submitted messages. Interface engine 512 then sends the internal messages with the templates 516 obtained from payer 524 to clearing house application 518.
When clearing house application 518 receives the internal messages and templates 516, clearing house application 518 either places the internal messages in queue 520 or adjudicates the claims within the internal messages. Unlike clearing house application 404 in
Once the claims within the internal messages are adjudicated, clearing house application 518 places claim results in history database 522 prior to returning them to interface engine 512 in the internal message format. Interface engine 512 then converts the return messages back to a markup language format, such as extensible markup language, and validates the XML return messages with return message schema 528. Return message schema 528 identifies components of a return message, including error components.
Once the return messages are validated, interface engine 512 places the claim results within the return messages in claims database 514 for future reference. If the claims are adjudicated successfully, interface engine 512 returns the claim results in XML format to host system 502 via a Web service module 504. If claim adjudication is not successful, meaning that there are errors within the claims, interface engine 512 returns the claim results with errors to host system 502 via a Web service module 504. Medical providers may then correct the errors and repeat the adjudication process.
Thus, the generic mechanism of the present invention replaces most of the clearing house function that was provided by clearing house application 404 and rule engine 408 in
Turning now to
Claim message 600 is formatted using ANSI characters and are delimited by various symbols. For example, the ‘!’ symbol is used to delimit segments, and the ‘|’ symbol is used to delimit fields. As shown in
Line segment 608 is a repeated segment. Line segment 608 identifies detail claim information, including the date of service provided by the medical provider, the amount of the service, what treatment was provided, and plan and account information for the patient's health care plan. History segment 610 has a format that is identical to the format of line segment 608. History segment 610 is optional and may be repeated to identify a history of claims that are submitted by the medical provider.
In order for medical providers to send claim messages to the clearing house application, the developers of the host system must first convert claim information received into segmentations and delimiters used in claim message 600. This creates an overhead in development time and labor cost for medical providers, who must adhere to the internal message format.
Turning now to
Turning now to
In addition, return message schema 800 includes line segment 808 and message id segment 810 in
Turning now to
Once the claim submission is received, the Web service module parses claim information from the Web-based interface (step 904) and converts the claim information into a generic message format, such as XML format (step 906). Once the claim information is converted into XML messages, the Web service module then sends XML messages to the interface engine (step 908) for adjudication. Thus, the process terminates thereafter.
Turning now to
Turning now to
However, if no messages are waiting for batch processing, the batch loader returns to step 930 to periodically check to see if new XML messages are uploaded.
Turning now to
The interface engine validates the XML messages received with a claim schema (step 1004) and determines if the messages are valid according to the internal message format as defined in the claim schema (step 1006). If the messages are not valid, the interface engine returns an error to the host system (step 1014) and the process terminates thereafter.
If the messages are valid, the interface engine converts the XML messages to internal message format (step 1008) and sends the internal messages to clearing house application for adjudication (step 1010).
When adjudication is complete, the interface engine receives the claim results from clearing house application (step 1012) and converts the claim results back to XML messages (step 1016). Once the claim results are converted back to XML messages, the interface engine validates the messages by using the return message schema (step 1018).
A determination is then made by the interface engine as to whether the messages are valid (step 1020). If the messages are not valid, an error is returned to the clearing house application to resend correct claim results (step 1024) and the process terminates thereafter. If the messages are valid, the interface engine saves the claim results in a claim database (step 1021) for future reference and returns the claim results back to the host system (step 1022).
The host system then submits the adjudicated claims to payer for approval (step 1026). A determination is made by the payer as to whether the claim is approved (step 1028). If the payer approves the claim, an approval is returned by the payer to the medical provider via the host system (step 1030). Otherwise, a failure to approve is returned by the payer to the medical provider via the host system (step 1032) and the process terminates thereafter.
In summary, the generic mechanism of the present invention has advantages over the prior art, in that development cost is greatly reduced by eliminating the requirement of the internal message format knowledge from the host system. With the generic mechanism of the present invention, medical providers may submit claims for adjudication without having knowledge of the internal message format or the clearing house application. In addition, medical providers may submit claims using a Web-based interface provided by the generic mechanism via a Web service module. Furthermore, a high volume of claims may be submitted for adjudication from a third party practice management system via Web portal without involvement of the host system. Moreover, the templates defined by the payer may directly be obtained by the interface engine without using the clearing house application. Also, claim results are now accessible via the claim database provided by the present invention for medical providers' use for backup, storage, and maintenance.
It is important to note that while the present invention has been described in the context of a fully functioning data processing system. Those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
