Patent Grant
8489415
Aspects of the invention relate generally to healthcare transactions, and more particularly, to the coordination of benefits in healthcare claim transactions.
During the processing of a healthcare transaction by a healthcare provider, such as a pharmacy or hospital, a healthcare claim, such as an insurance claim, is typically made by the healthcare provider in order to receive compensation for provided products and/or services. However, in many situations, a patient may have dual prescription coverage and/or multiple benefit payers. For example, a commercial insurance provider may cover all the cost of a medication except for a co-payment amount. A state provider, such as a Medicaid provider, may then cover the co-payment amount. In dual coverage situations, a healthcare provider must submit claims to each benefit provider separately and inform providers of amounts that have been paid by previous providers. Such individual claim submission may be time consuming for the healthcare provider and may be susceptible to inaccuracies as employees of the healthcare provider submit multiple claim requests.
Therefore, a need exists for systems and methods for the coordination of benefits in healthcare claim transactions.
Some or all of the above needs and/or problems may be addressed by certain embodiments of the invention. Embodiments of the invention may include systems, methods, and apparatus for the coordination of benefits in healthcare claim transactions. In one embodiment, a computer-implemented method for the coordination of benefits in healthcare claim transactions is provided. A healthcare claim request may be received from a healthcare provider computer. The received healthcare claim request may include information associated with a plurality of prescription claims for a single healthcare transaction. The received healthcare claim request may be identified as a bundled healthcare claim request. A primary claim request for the healthcare transaction may be generated and communicated to a first claims processor computer for adjudication. A first adjudicated reply for the primary claim request may be received from the first claims processor computer. Based at least in part on the received first adjudicated reply, a secondary claim request for the healthcare transaction may be generated and communicated to a second claims processor computer for adjudication. A second adjudicated reply for the secondary claim request may be received from the second claims processor computer. Information associated with the first adjudicated reply and the second adjudicated reply may be communicated to the healthcare provider computer.
In accordance with another embodiment of the invention, a system for the coordination of benefits in healthcare claim transactions is provided. The system may include at least one memory and at least one processor. The at least one memory may be operable to store computer-executable instructions. The at least one processor may be configured to access the at least one memory and execute the computer-executable instructions to: receive a healthcare claim request from a healthcare provider computer, the healthcare claim request comprising information associated with a plurality of prescription claims for a single healthcare transaction; identify the received healthcare claim request as a bundled healthcare claim request; generate a primary claim request for the healthcare transaction; communicate the generated primary claim request to a first claims processor computer for adjudication; receive, from the first claims processor computer, a first adjudicated reply for the primary claim request; generate, based at least in part on the received first adjudicated reply, a secondary claim request for the healthcare transaction; communicate the generated secondary claim request to a second claims processor computer for adjudication; receive, from the second claims processor computer, a second adjudicated reply for the secondary claim request; and communicate information associated the first adjudicated reply and the second adjudicated reply to the healthcare provider computer.
Additional systems, methods, apparatus, features, and aspects may be realized though the techniques of various embodiments of the invention. Other embodiments and aspects of the invention are described in detail herein with reference to the description and to the drawings and are considered a part of the claimed invention.
Reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
Embodiments of the invention now will be described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.
Embodiments of the invention can provide systems, methods, apparatus, means, and/or mechanisms for the coordination of benefits in healthcare claim transactions. A healthcare provider computer, such as a pharmacy computer, may submit a bundled healthcare claim request to a service provider computer. The bundled healthcare claim request may contain information associated with multiple claims for a single healthcare transaction. The service provider computer may identify the bundled claim request as a bundled request and process the bundled request by generating multiple claims requests and routing or otherwise communicating each of the generated claim requests to a respective claims processor computer for adjudication. For example, a primary claim request for the healthcare transaction may be generated and communicated to a first claims processor computer for adjudication. A first adjudicated reply for the primary claim request may be received from the first claims processor computer. Based at least in part on the received first adjudicated reply, a secondary claim request for the healthcare transaction may be generated and communicated to a second claims processor computer for adjudication. A second adjudicated reply for the secondary claim request may be received from the second claims processor computer. Any number of claim requests may be generated for the healthcare transaction and communicated to appropriate claims processor computers for adjudication. Once the claim requests have been adjudicated, in certain embodiments, a bundled reply for the original healthcare claim request may be assembled or generated and returned to the healthcare provider computer. The bundled reply may include information associated with each of the adjudicated replies that are received by the service provider computer. In this regard, a healthcare provider may submit a single claim request to the service provider computer, and the service provider computer may coordinate the various benefit providers associated with the claim.
System Overview
An example system 100 system for facilitating the coordination of benefits in healthcare claim transactions will now be described illustratively with respect to
Additionally, in certain embodiments, the service provider computer 106 may include or otherwise be in communication with a coordination of benefits (COB) application 180 or COB module, which may facilitate the generation of multiple claim requests for a bundled healthcare claim request that has been received from a healthcare provider computer 104. For example, the COB application 180 may generate a primary claim request and one or more secondary claim requests for a healthcare transaction, and the COB application 180 may direct the communication of the various claim requests to appropriate claims processor computers 108, 110. The COB application 180 may additionally analyze information included in adjudicated replies that are received from the claims processor computers 108, 110 and utilize that information in the generation of claims requests, such as secondary claim requests. Additionally, as desired, the COB application 180 may generate or assembly a single adjudicated reply for the bundled healthcare claim request and direct the communication of the single adjudicated reply to the healthcare provider computer 104.
Generally, network devices and systems, including one or more of the healthcare provider computer 104, service provider computer 106, and claims processor computers 108, 110 may include or otherwise be associated with suitable hardware and/or software for transmitting and receiving data and/or computer-executable instructions over one or more communications links or networks. These network devices and systems may also include any number of processors for processing data and executing computer-executable instructions, as well as other internal and peripheral components that are well known in the art. Further, these network devices and systems may include or be in communication with any number of suitable memory devices operable to store data and/or computer-executable instructions. By executing computer-executable instructions, each of the network devices may form a special purpose computer or particular machine. As used herein, the term “computer-readable medium” describes any form of suitable memory or memory device.
The healthcare provider computer 104 may be associated with a healthcare provider, for example, a pharmacy, physician's office, hospital, etc. The healthcare provider computer 104 may be any suitable processor-driven device that facilitates the processing of healthcare requests made by patients or consumers and the communication of information associated with healthcare claim transactions or healthcare claim requests to the service provider computer 106. For example, the healthcare provider computer 104 may be a computing device that includes any number of server computers, mainframe computers, networked computers, desktop computers, personal computers, digital assistants, personal digital assistants, digital tablets, Internet appliances, application specific circuits, microcontrollers, minicomputers, and/or any other processor-based device(s). In certain embodiments, the healthcare provider computer 104 may be a suitable point of sale device associated with a healthcare provider. The execution of the computer-implemented instructions by the healthcare provider computer 104 may form a special purpose computer or other particular machine that is operable to facilitate the processing of healthcare requests made by patients and the communication of information associated with healthcare claim requests and/or healthcare claim transactions to a service provider computer 106. Additionally, in certain embodiments of the invention, the operations and/or control of the healthcare provider computer 104 may be distributed amongst several processing components.
In addition to having one or more processors 124, the healthcare provider computer 104 may include one or more memory devices 126, one or more input/output (“I/O”) interface(s) 128, and one or more network interface(s) 130. The memory devices 126 may be any suitable memory devices, for example, caches, read only memory devices, random access memory devices, magnetic storage devices, removable storage devices, etc. The memory devices 126 may store data, executable instructions, and/or various program modules utilized by the healthcare provider computer 104, for example, data files 132, an operating system 134, and/or a client module 138. The data files 132 may include any suitable data that facilitates the receipt and/or processing of healthcare requests by the healthcare provider computer 104 and the generation and/or processing of healthcare claim requests or healthcare claim transactions that are communicated to the service provider computer 106. For example, the data files 132 may include, but are not limited to, healthcare information associated with one or more patients, information associated with the service provider computer 106, information associated with one or more claims processors, information associated with one or more healthcare claim transactions, and/or information associated with the generation of bundled healthcare claim requests. The operating system (OS) 134 may be a suitable software module that controls the general operation of the healthcare provider 104. The OS 134 may also facilitate the execution of other software modules by the one or more processors 124, for example, the client module 138. The OS 134 may be, but is not limited to, Microsoft Windows®, Apple OSX™, Linux, Unix, or a mainframe operating system. The client module 138 may be an Internet browser or other software, including a dedicated program, for interacting with the service provider computer 106. For example, a user such as a pharmacist or other pharmacy employee, may utilize the client module 138 in preparing and providing a prescription claim request to the service processor computer 106 for delivery to one or more appropriate claims processor computers 108, 110 for adjudication or other coverage/benefits determination. The healthcare provider computer 104 may also utilize the client module 138 to retrieve or otherwise receive data, messages, or responses from the service provider computer 106 and/or other components of the system 100.
In operation, the healthcare provider computer 104 may receive information associated with a healthcare request from a patient. As one example, the healthcare provider computer 104 may receive information associated with a healthcare request for a patient at a point of sale, such as in a pharmacy during a prescription fulfillment or purchase transaction. As another example, the healthcare provider computer 104 may electronic receive a healthcare request from a patient computer or other patient device. The healthcare provider computer 104 may generate a healthcare claim request, healthcare claim transaction, or prescription claim request for the patient request and information associated with the healthcare claim request may be communicated to the service provider computer 106. In various embodiments of the invention, the generated healthcare claim request may be a bundled request that identifies one or more benefits providers or payors for the healthcare transaction, such as a primary payor and one or more secondary payors. The healthcare claim request may further include a field, flag, setting, or other identifier that identifies the healthcare claim request as a bundled request. A wide variety of identifiers may be utilized as desired in various embodiments of the invention, for example, an other coverage code (OCC) for the healthcare claim request may be set to a certain value (e.g., nine) to identify the healthcare claim request as a bundled request.
The one or more I/O interfaces 128 may facilitate communication between the healthcare provider computer 104 and one or more input/output devices, for example, one or more user interface devices, such as, a display, keypad, control panel, touch screen display, remote control, microphone, etc. that facilitate user interaction with the healthcare provider computer 104. For example, the one or more I/O interfaces 128 may facilitate entry of information associated with a healthcare transaction or healthcare claim request by an employee of a healthcare provider, such as a pharmacy employee. The one or more network interfaces 130 may facilitate connection of the healthcare provider computer 104 to one or more suitable networks, for example, a local area network, a wide area network, the Internet, a cellular network, a publicly switched telephone network, a dedicated healthcare transactions network, any wired network, any wireless network, a combination of networks, etc. In this regard, the healthcare provider computer 104 may receive and/or communicate information to other network components of the system 100, such as the service provider computer 106.
With continued reference to
The service provider computer 106 may include any number of special purpose computers or other particular machines, application specific circuits, microcontrollers, personal computers, minicomputers, mainframe computers, servers, networked computers, and/or other processor driven devices. In certain embodiments, the operations of the service provider computer 106 may be controlled by computer-executed or computer-implemented instructions that are executed by one or more processors associated with the service provider computer 106 to form a special purpose computer or other particular machine that is operable to facilitate the receipt, routing, and/or processing of healthcare claim requests or healthcare claim transactions. The one or more processors that control the operations of the service provider computer 106 may be incorporated into the service provider computer 106 and/or in communication with the service provider computer 106 via one or more suitable networks. In certain embodiments of the invention, the operations and/or control of the service provider computer 106 may be distributed amongst several processing components.
Similar to the healthcare provider computer 104, the service provider computer 106 may include one or more processors 140, one or more memory devices 142, one or more input/output (“I/O”) interface(s) 144, and one or more network interfaces 146. The one or more memory devices 142 may be any suitable memory devices, for example, caches, read only memory devices, random access memory devices, magnetic storage devices, removable memory devices, etc. The one or more memory devices 142 may store data, executable instructions, and/or various program modules utilized by the service provider 106, for example, data files 148, an operating system (“OS”) 150, the host module 154, and a database management system (“DBMS”) 152 to facilitate management of data files 148 and other data stored in the memory devices 142 and/or one or more databases 182 or data storage devices. The OS 150 may be, but is not limited to, Microsoft Windows®, Apple OSX™, Linux, Unix, or a mainframe operating system.
According to an embodiment of the invention, the data files 148 may store healthcare transaction records associated with communications received from various healthcare provider computers 104 and/or various claims processor computers 108, 110. The data files 148 may also store any number of suitable routing tables that facilitate determining the destination of communications received from a healthcare provider computer 104 or claims processor computer 108, 110 and/or the destination of claims generated by the COB application 180. The host module 154 may receive, process, and respond to requests from the client module 138 of the healthcare provider computer 104, and may further receive, process, and respond to requests of the host modules 172, 192 of the various claims processor computers 108, 110. The service provider computer 106 may include additional program modules for performing other processing methods described herein. Those of ordinary skill in the art will appreciate that the service provider computer 106 may include alternate and/or additional components, hardware or software without departing from example embodiments of the invention.
A coordination of benefits (COB) application 180 or COB module may also be operative with the service provider computer 106. The COB application 180 may include computer-executable instructions for identifying and/or processing a bundled healthcare claim transaction that is received from a healthcare provider computer 104. For example, the COB application 180 may receive a healthcare claim request, a copy of a healthcare claim request, or information included in the healthcare claim request from the service provider computer 106, and the COB application 180 may determine whether the healthcare claim request is a bundled request. A wide variety of techniques may be utilized in this determination, such as reading an flag or identifier included in the healthcare claim request (e.g., an OCC code) or by determining whether information associated with multiple benefit providers or payors is included in the healthcare claim request.
It the COB application 180 identifies a received healthcare claim request or healthcare claim transaction as a bundled request, then the COB application 180 may parse or otherwise break up the bundled request into its components. For example, the bundled request may be parsed into a primary component and one or more secondary components. The COB application 180 may then generate and direct the communication of claim requests for one or more of the components in an attempt to adjudicate the bundled request. For example, the COB application 180 may generate a primary claim request and direct the service provider computer 106 to route or otherwise communicate the primary claim request to a first claims processor computer 108 associated with the primary claim request. A first adjudicated reply for the primary claim request may then be received by the service provider computer 106 from the first claims processor computer 108 and the first adjudicated reply, a copy of the reply, or information included in the reply may be communicated to the COB application 180. The COB application 180 may then generate a secondary claim request based at least in part on the information included in the first adjudicated reply, and the COB application 180 may direct the service provider computer 106 to route or otherwise communicate the secondary claim request to a second claims processor computer 110 associated with the secondary claim request. A second adjudicated reply for the secondary claim request may then be received by the service provider computer 106 from the second claims processor computer 110 and the second adjudicated reply, a copy of the reply, or information included in the reply may be communicated to the COB application 180. As desired, the COB application 180 may generate additional secondary requests in an iterative manner based upon the received adjudicated replies. The COB application 180 may continue to generate and/or route claim requests until all relevant claims included in the bundled request are paid or until no more claims processor computers are available. Once processing by the COB application 180 is complete, the COB application 180 may generate or construct a bundled reply to the bundled healthcare claim request based upon each of the received adjudicated replies, and the COB application 180 may direct the service provider computer 106 to route the bundled reply to the healthcare provider computer 104. As an alternative to generating a bundled reply, each of the received adjudicated replies may be communicated to the service provider computer 104.
In certain embodiments of the invention, the COB application 180 may construct a secondary claim request based upon information included in received adjudicated replies for one or more previous claim requests. In this regard, a requested claim amount or payment amount included in a secondary claim request may be based upon one or more payments that have been made or approved in conjunction with previously adjudicated claim requests for the healthcare transaction. For example, a primary claim request may be generated for a prescription medication and communicated to an appropriate claims processor computer 108 associated with an insurance provider. An adjudicated reply received for the primary claim request may indicate that all of the medication cost will be covered other than a patient co-payment amount, such as fifteen dollars ($15). A secondary claim request for the co-payment amount (e.g., fifteen dollars) may be generated for the prescription medication and communicated to an appropriate claims processor computer 110 associated with a government provider (e.g., a Medicaid provider) to request payment of the co-payment amount. Once an adjudicated reply is received for the secondary claim request, a bundled reply may be generated or built for communication to the healthcare provider computer 104.
As desired in various embodiments, if a claim request is denied by a claims processor computer 108 or if an expected payment amount is not made or authorized, then information included in the claim request may be utilized to generate a second claim request. For example, if a primary claim request is denied, then a secondary claim request may be generated using the primary claim request data or information. The secondary claim request may then be communicated to an appropriate claims processor computer for adjudication. This process may be repeated as desired until the claim is paid or until no other payors are available for the healthcare transaction. In this regard, if a first payor does not authorize payment for a claim, then a claim request may be sent to a second payor, third payor, and so on. For example, if a patient has two insurance providers and a first of the insurance providers denies a claim, then a claim request may be communicated to the second insurance provider in an attempt to have the claim approved. If the claim is ultimately approved, then one or more additional secondary claims may be generated as desired in the event that other claims processor computers are available. An example of operations for generating claim requests based upon the adjudicated replies received for one or more previous requests is provided below with reference to
The data storage devices 182 (e.g., databases) may be accessible by the COB application 180, and the data storage devices 182 be operable to store healthcare claim transaction information, such as information that may be utilized by the COB application 180 to construct one or more claim requests and/or information (e.g., adjudicated replies) that may be utilized to generate or build a bundled reply for a healthcare claim request.
With continued reference to the service provider computer 106, the one or more I/O interfaces 144 may facilitate communication between the service provider computer 106 and one or more input/output devices, for example, one or more user interface devices, such as, a display, keypad, control panel, touch screen display, remote control, microphone, etc. that facilitate user interaction with the service provider computer 106. The one or more network interfaces 146 may facilitate connection of the service provider computer 106 to one or more suitable networks, for example, a local area network, a wide area network, the Internet, a cellular network, a publicly switched telephone network, a dedicated healthcare transactions network, any wired network, any wireless network, a combination of networks, etc. In this regard, the service provider computer 106 may communicate with other components of the system 100.
With continued reference to
Similar to other components of the system 100, the claims processor computer 108 may include one or more processors 158, one or more memory devices 160, one or more input/output (“I/O”) interface(s) 162, and one or more network interfaces 164. The one or more memory devices 160 may be any suitable memory devices, for example, caches, read only memory devices, random access memory devices, magnetic storage devices, removable memory devices, etc. The one or more memory devices 160 may store data, executable instructions, and/or various program modules utilized by the claims processor computer 108, for example, data files 166, an operating system (“OS”) 168, a database management system (“DBMS”) 170, and a host module 172. The data files 166 may include any suitable information that is utilized by the claims processor computer 108 to process healthcare claim transactions, for example, patient profiles, patient insurance information, other information associated with a patient, information associated with a healthcare provider, etc. The operating system (OS) 168 may be a suitable software module that controls the general operation of the claims processor computer 108. The OS 168 may also facilitate the execution of other software modules by the one or more processors 158, for example, the DBMS 170 and/or the host module 172. The OS 150 may be, but is not limited to, Microsoft Windows®, Apple OSX™, Linux, Unix, or a mainframe operating system. The DBMS 170 may be a suitable software module that facilitates access and management of one or more databases that are utilized to store information that is utilized by the claims processor computer 108 in various embodiments of the invention. The host module 172 may initiate, receive, process, and/or respond to requests, such as healthcare claim transactions or claim requests, from the host module 154 of the service provider 106. The claims processor computer 108 may include additional program modules for performing other pre-processing or post-processing methods described herein. Those of ordinary skill in the art will appreciate that the claims processor 108 computer may include alternate and/or additional components, hardware or software without departing from example embodiments of the invention.
The one or more I/O interfaces 162 may facilitate communication between the claims processor computer 108 and one or more input/output devices, for example, one or more user interface devices, such as, a display, keypad, control panel, touch screen display, remote control, microphone, etc. that facilitate user interaction with the claims processor computer 108. The one or more network interfaces 164 may facilitate connection of the claims processor computer 108 to one or more suitable networks, for example, a local area network, a wide area network, the Internet, a cellular network, a publicly switched telephone network, a dedicated healthcare transactions network, any wired network, any wireless network, a combination of networks, etc. In this regard, the claims processor computer 108 may receive healthcare claim transactions and/or other communications from the service provider computer 106, and the claims processor computer 108 may communicate information associated with processing claim transactions to the service provider.
Other claims processor computers, such as the second claims processor computer 110, may generally include similar components to the first claims processor computer 108. For example, the second claims processor computer 110 may include one or more processors 181, one or more memory devices 183, one or more I/O interfaces 184, and/or one or more network interfaces 186. Each of these components may operate in a similar manner as the corresponding components described above for the first claims processor computer 108. Additionally, the one or more memory devices 183 may store data, executable instructions, and/or various program modules utilized by the second claims processor computer 110, for example, data files 190, an operating system (“OS”) 188, a database management system (“DBMS”) 191, and/or a host module 192, and each of these various components may be similar to those described above with reference to the first claims processor computer 108.
Any number of networks may be utilized in association with various embodiments of the invention to facilitate communications between any number of components of the system. The network(s) may also allow for real-time, off-line, and/or batch transactions to be transmitted between or among the healthcare provider computer 104, the service provider computer 106, and the claims processor computers 108, 110. Due to network connectivity, various methodologies as described herein may be practiced in the context of distributed computing environments. A wide variety of network configurations may be utilized as desired in various embodiments of the invention. Instead of or in addition to a network or combination of networks, dedicated communication links may be used to connect the various devices in accordance with an example embodiment of the invention. For example, the service provider computer 106 may form the basis of a network that interconnects the healthcare provider computer 104 and one or more claims processor computers 108, 110.
Those of ordinary skill in the art will appreciate that the system 100 shown in and described with respect to
Operational Overview
The healthcare provider computer 104 may receive and process the request 205 to generate a healthcare claim transaction 210 or a healthcare claim request, such as a prescription claim request, and the healthcare claim transaction 210 may be communicated by the healthcare provider computer 104 to the service provider computer 106. The healthcare claim transaction 210 may be a bundled transaction that includes information associated with a plurality of claims and/or a plurality of payors for the healthcare claim transaction 210. Additionally, the bundled healthcare claim transaction 210 may include at least one identifier that facilitates the identification by the service provider computer 106 of the healthcare claim transaction 210 as a bundled claim transaction. A wide variety of identifiers may be utilized as desired in various embodiments of the invention, for example, a certain value (e.g., a value of nine) in an other coverage code (OCC) field for the healthcare claim transaction.
According to an example embodiment of the invention, the bundled healthcare claim transaction 210 may be in accordance with a version of a National Council for Prescription Drug Programs (NCPDP) Telecommunication Standard, although other standards may be utilized as well. As desired, the healthcare claim transaction 210 may include one or more Banking Identification Numbers (BINs) and/or Processor Control Numbers (PCNs) for identifying one or more appropriate claims processor computers, such as the claims processor computers 108, 110 illustrated in
Payor ID/Routing Information for each identified payor or potential payor BIN Number (i.e. Banking Identification Number) and Processor Control
Patient Information
Secondary Insurance/Coverage Information for Each Secondary Payor
Claim Information
Date of Service.
The service provider computer 106 may receive the bundled healthcare claim transaction 210 from the healthcare provider computer 104, and the service provider computer and/or an associated COB application, such as the COB application 180 shown in
The COB application 180 may facilitate the generation and/or processing of a plurality of claim request for the bundled transaction 210. The COB application 180 may identify a plurality of payors (e.g., pharmacy benefits managers (PBM), insurers, government payors, and/or claims clearinghouses) for the bundled transaction 210, for example, by identifying payor identifiers included in the bundled transaction 210. The COB application 180 may also identify an order for submitting claims to the identified plurality of payors. In certain embodiments, the order for submitting claims may be identified based upon information included in the bundled transaction 210. For example, the bundled transaction 210 may identify a primary payor and one or more ordered secondary payors. In other embodiments, the order for submitting claims may be identified based on one or more prioritization rules that are applied by the COB application 180. A wide variety of prioritization rules may be utilized as desired. For example, a commercial insurance provider may be ordered before a government payor. As another example, the commercial insurance provider may be ordered before a supplemental insurance provider. As yet another example, information associated with previous healthcare claim transactions processed on behalf of the patient may be accessed from one or more suitable data storage devices, such as data storage devices 182 illustrated in
The COB application 180 may generate or build a primary claim request 220 for the bundled transaction 210. The primary claim request 220 may include a portion of the information included in the bundled transaction 210, for example, information associated with the primary payor or primary insurance provider. The primary claim request 220 (or a copy of the primary claim request 220) may be communicated to service provider computer 106 for routing or communication to an appropriate claims processor computer 108 associated with the primary claim request 220. The primary claim request 220 and/or a copy of the primary claim request 220 may then be routed or otherwise communicated by the service provider computer 106 to the appropriate claims processor computer 108 for adjudication. According to an example embodiment, the service provider 106 may utilize at least a portion of the information included in the primary claim request 220, such as a BIN/PCN, to determine the appropriate claims processor computer 108 to route the primary claim request 220 to. The service provider computer 106 may also include a routing table, perhaps stored in memory, for determining which claims processor computer to route the primary claim request 230 to.
The first claims processor computer 108 may receive and adjudicate or otherwise process the primary claim request 220. For example, the first claims processor computer 108 may determine benefits coverage for the primary claim request 220 according to an adjudication process associated with eligibility, pricing, and/or utilization review. The first claims processor computer 108 may transmit a first adjudicated reply 225 for the primary claim request 220 to the service provider computer 106. The service provider computer 106 may receive the first adjudicated reply 225 from the first claims processor computer 108. As desired, the service provider computer 106 may perform any number of post-edits on the adjudicated reply. For example, the service provider computer 106 may identify the first adjudicated reply 225 as an adjudicated reply associated with a bundled transaction, and the service provider computer 106 may communicate the first adjudicated reply 225 or a copy of the first adjudicated reply 225 to the COB application 180. A wide variety of various identifiers and/or identification techniques may be utilized by the service provider computer 106 to identify the first adjudicated reply 225 as an adjudicated reply associated with a bundled transaction, for example, identification of a claim number by the service provider computer 106.
The COB application 180 may receive the first adjudicated reply 225, and the COB application 180 may generate or build a secondary claim request 230 based at least in part on the information included in the first adjudicated reply 225. An amount paid or authorized for the first adjudicated reply 225 may be determined by the COB application 180 and the determined amount may be utilized in the generation of a secondary claim request 230. For example, if the first adjudicated reply 225 indicates that all but a co-payment amount (e.g., a $15 or $20 co-pay) has been paid or authorized, then the secondary claim request 230 may be generated to request a portion or all of the co-payment amount. As another example, if the first adjudicated reply 225 indicates that the primary claim request has been denied, then the secondary claim request 230 may be generated to request a portion or all of the claim amount that was included in the primary claim request 220. In this regard, the COB application 180 may attempt to obtain a highest possible payment for the bundled transaction 210.
The secondary claim request 230 (or a copy of the secondary claim request 230) may be communicated to service provider computer 106 for routing or communication to an appropriate claims processor computer 110 associated with the secondary claim request 230. The secondary claim request 230 and/or a copy of the secondary claim request 230 may then be routed or otherwise communicated by the service provider computer 106 to the appropriate claims processor computer 110 for adjudication. According to an example embodiment, the service provider 106 may utilize at least a portion of the information included in the secondary claim request 230, such as a BIN/PCN, to determine the appropriate claims processor computer 110 to route the secondary claim request 230 to. The service provider computer 106 may also include a routing table, perhaps stored in memory, for determining which claims processor computer to route the secondary claim request 230 to.
The second claims processor computer 110 may receive and adjudicate or otherwise process the secondary claim request 230. For example, the second claims processor computer 110 may determine benefits coverage for the secondary claim request 230 according to an adjudication process associated with eligibility, pricing, and/or utilization review. The second claims processor computer 110 may transmit a second adjudicated reply 235 for the secondary claim request 230 to the service provider computer 106. The service provider computer 106 may receive the second adjudicated reply 235 from the second claims processor computer 110, and the service provider computer 106 may identify the second adjudicated reply 235 as an adjudicated reply associated with a bundled transaction in a similar manner as that utilized for the primary claim request 220. The service provider computer 106 may communicate the second adjudicated reply 235 or a copy of the second adjudicated reply 235 to the COB application 180.
The COB application 180 may receive and process the second adjudicated reply 235. The COB application 180 may determine an amount paid or authorized for the second adjudication reply 235. In this regard, the COB application 180 may determine whether a total amount for the bundled transaction has been paid or authorized. If a total amount has not been paid or authorized for payment, then the COB application 180 may determine whether any additional claims processor computers are available. If an additional claims processor computer is available, then the COB application 180 may generate an additional secondary claim request (e.g., a third claim request) based upon the information included in the second adjudicated reply 235 and the first adjudicated reply 225. The additional secondary claim request may then be routed to a claims processor computer in a similar manner as that utilized to route the other claim requests 220, 230, and an adjudicated reply may be received for the additional secondary claim request. As desired, the COB application 180 may continue to generate or build claim requests until a maximum receivable or maximum available amount for the bundled transaction 210 is paid or authorized or until no more claims processor computers are available.
Once the adjudication of each component or portion of the bundled transaction 210 has been completed, the COB application 180 may generate or build a bundled transaction adjudicated reply 240 for the bundled transaction 210. The bundled reply 240 may be generated utilizing each of the adjudicated replies received from various claims processor computers. The bundled reply 240 or multi-claim reply may include a wide variety of information, for example, information associated with each of the claim requests that have been generated for the bundled transaction, information associated with each of the received adjudicated replies, payment information for the various claim requests, a total amount paid or authorized (if applicable), etc. The bundled reply 240 or a copy of the bundled reply 240 may be communicated to the service provider computer 106, and the service provider computer 106 may route or otherwise communicate the bundled reply 240 to the healthcare provider computer 104 as a response to the bundled healthcare transaction 210. As an alternative to communicating a single bundled reply 240, one or more of the received adjudicated replies may be communicated to the healthcare provider computer 104. These adjudicated replies may be communicated as a single communication or message or as any number of separate communications.
As described herein, healthcare transactions may be examined as they are routed to or through a service provider computer 106. In this regard, a bundled transaction may be identified and processed in real time as the bundled transaction is routed to or through the service provider computer 106.
At block 305, the service provider computer 106 may receive a bundled healthcare claim transaction from a healthcare provider computer, such as the healthcare provider computer 104 illustrated in
At block 310, the received bundled healthcare claim transaction may be identified as a bundled transaction or a bundled request. A wide variety of identifiers and/or identification techniques, such as the recognition of an other coverage code value (e.g., an OCC value of nine) or some other identifier, may be utilized to identify the received transaction as a bundled transaction or a bundled request. Once the received transaction is identified as a bundled request, the received transaction may be communicated to the COB application 180 for processing.
At block 315, The COB application 180 may receive the bundled transaction and parse or otherwise divide the bundled transaction into any number of individual components or parts. As desired, the COB application 180 may also rank or prioritize the components in the order in which they should be processed. The COB application 180 may then iteratively process each of the components of the bundled transaction until a maximum available payment amount is received or authorized for the bundled transaction or until no additional components are available.
At block 320, the next component of the bundled transaction may be selected. A claim request for the selected component may then be generated or built at block 325. The claim request may be generated utilizing information included in the bundled transaction, information included in previously generated claim requests for the transaction, and/or information included in adjudicated replies received for previously generated claim requests. In this regard, a claim request generated for a first component or primary component may be generated or built utilizing information included in the bundled transaction. Secondary claim requests generated for subsequent components may be generated or built utilizing information from the bundled transaction and/or adjudication information received for previous claim requests.
At block 325, the generated claim request may be routed or otherwise communicated to an appropriate claims processor computer, such as one of the claims processor computers 108, 110 illustrated in
The adjudicated reply may be received by the service provider computer 106 at block 335. At block 340, a determination may be made as to whether or not the last component of the bundled transaction has been reached or processed. If it is determined at block 340 that the last component has not been reached, then operations may continue at block 320 and the next component of the bundled transaction may be selected and processed. In this regard, the COB application 180 may generate a plurality of claims in a serial manner based upon the adjudication of previously processed claims. If, however, it is determined at block 340 that the last component has been paid or approved for payment, then operations may continue at block 345.
At block 345, a bundled reply to the bundled transaction may be generated or built based upon received adjudicated replies for each of the claim requests that were generated for respective components of the bundled transaction. The bundled reply may then be routed or otherwise communicated to the healthcare provider computer 104 by the service provider computer at block 350. As an alternative to generating and communicating a bundled reply, each of the received adjudicated replies may be communicated to the healthcare provider computer 104 in any number of suitable communications or messages.
The method 300 may end following block 350.
According to an aspect of the invention, a generated claim request for a bundled transaction may be based upon one or more previously adjudicated claim requests for the bundled transaction.
At block 405, a primary claim request may be generated or built for a bundled healthcare transaction received from a healthcare provider computer, such as the healthcare provider computer 104 illustrated in
At block 415, a determination may be made as to whether the primary claim request has been paid or approved for payment. If it is determined at block 415 that the primary claim request has not been paid, then operations may continue at block 440 which is discussed in greater detail below. If, however, it is determined at block 415 that the primary claim request has been paid, then operations may continue at block 420.
At block 420, a secondary claim request may be generated or built based at least in part on the payment that has been made or authorized for the approved primary claim request. For example, a remaining co-payment amount following payment of the primary claim request may be identified and the co-payment amount may be requested in the generated secondary claim request. As another example, a payment amount for the primary claim request may be subtracted from a total amount of the bundled transaction, and a portion or all of the remainder may be requested in the generated secondary claim request. At block 425, the secondary primary claim request may be routed or otherwise communicated to an appropriate claims processor computer associated with the secondary claim request. The secondary claim request may be adjudicated by the recipient claims processor computer, and an adjudicated reply for the secondary claim request may be received at block 425. Following the receipt of the adjudicated reply for the secondary claim request, a determination may be made as to whether the secondary claim request has been paid. If the secondary claim request has not been paid or if the amount paid for the secondary claim request does not satisfy a total outstanding amount for the bundled transaction, then one or more additional secondary claim requests may be generated.
For example, at block 430, a determination may be made as to whether another claims processor computer is available. If it is determined at block 430 that another claims processor computer is available, then operations may continue at block 420 and another secondary claim request may be generated based upon the adjudication of prior claim requests. If, however, it is determined at block 430 that another claims processor computer is not available, then operations may continue at block 435. At block 435, a bundled or multi-claim reply for the bundled transaction may be generated based upon the adjudication of each of the claim requests. As desired, the bundled reply may then be routed or otherwise communicated to the healthcare provider computer.
At block 440, which may be reached if it is determined at block 415 that the primary claim request has not been paid, a secondary claim request may be generated or built utilizing data for the rejected primary claim request. For example, the secondary claim request may request an entire amount for the bundled transaction or an amount minus a patient co-payment amount. The secondary claim request may be generated for submission to a different claims processor computer, for example, a different insurance provider or other payor. At block 445, the generated secondary claim request may be may be routed or otherwise communicated to an appropriate claims processor computer associated with the secondary claim request. The secondary claim request may be adjudicated by the recipient claims processor computer, and an adjudicated reply for the secondary claim request may be received at block 445.
Following the receipt of the adjudicated reply for the secondary claim request, a determination may be made at block 450 as to whether the secondary claim request has been paid. If it is determined at block 450 that the secondary claim request has been paid, then operations may continue at block 430 as discussed above. If, however, it is determined at block 450, that the secondary claim request has not been paid, then operations may continue at block 455.
At block 455, which may be optional in certain embodiments of the invention, a reject code may be identified for the secondary claim request or a reason for rejection or denial of the secondary claim request may be determined. A wide variety of rejection codes may be identified for the secondary claim request, for example, a code indicated that the provider is not covered, a code indicating that the patient is not covered, or a code indicating that the payment was not collected. Additionally, although the determination of a reject code is described above with reference to a rejected secondary claim request following the rejections of a primary claim request, it will be appreciated that a rejection code may be identified for any rejected claim request. These rejection codes may then be included in a generated bundled reply.
At block 460, a determination may be made as to whether another claims processor computer is available. If it is determined at block 460 that another claims processor computer is available, then operations may continue at block 440 and another secondary claim request may be generated utilizing the primary claim data. If, however, it is determined at block 460 that another claims processor computer is not available, then operations may continue at block 465. At block 465, the bundled transaction may be identified as a denied or unpaid claim transaction. A reply to the bundled transaction indicating that the claim is denied may be generated for communication to the healthcare provider computer 104. The generated reply may be a relatively simple reply identifying the claim as unpaid or, alternatively, may be a bundled or multi-claim reply that includes information associated with the adjudication of each of the generated claim requests.
The method 400 may end following block 435 or 465.
The operations described and shown in the methods 300, 400 of
Accordingly, example embodiments of the invention can provide the technical effects of creating a system, method, and apparatus that coordinates benefits for healthcare claim transactions or healthcare claim request. Additionally, example embodiments of the invention can provide the technical effect of generating a plurality of claim requests for a single healthcare transaction for adjudication and the communication of a single reply to a healthcare provider computer. In this regard, claim errors on the part of healthcare providers may be reduced or prevented.
Various block and/or flow diagrams of systems, methods, apparatuses, and/or computer program products according to example embodiments of the invention are described above. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, respectively, can be implemented by computer-executable program instructions. Likewise, some blocks of the block diagrams and flow diagrams may not necessarily need to be performed in the order presented, or may not necessarily need to be performed at all, according to some embodiments of the invention.
These computer-executable program instructions may be loaded onto a special purpose computer or other particular machine, a processor, or other programmable data processing apparatus to produce a particular machine, such that the instructions that execute on the computer, processor, or other programmable data processing apparatus create means for implementing one or more functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement one or more functions specified in the flow diagram block or blocks. As an example, embodiments of the invention may provide for a computer program product, comprising a computer usable medium having a computer readable program code or program instructions embodied therein, said computer readable program code adapted to be executed to implement one or more functions specified in the flow diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block or blocks.
Accordingly, blocks of the block diagrams and flow diagrams support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, can be implemented by special-purpose, hardware-based computer systems that perform the specified functions, elements or steps, or combinations of special purpose hardware and computer instructions.
Many modifications and other embodiments of the invention set forth herein will be apparent having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4674041 | Lemon et al. | Jun 1987 | A |
| 4723212 | Mindrum et al. | Feb 1988 | A |
| 4910672 | Off et al. | Mar 1990 | A |
| 5007641 | Seidman | Apr 1991 | A |
| 5080364 | Seidman | Jan 1992 | A |
| 5173851 | Off et al. | Dec 1992 | A |
| 5201010 | Deaton et al. | Apr 1993 | A |
| 5235702 | Miller | Aug 1993 | A |
| 5237620 | Deaton et al. | Aug 1993 | A |
| 5301105 | Cummings | Apr 1994 | A |
| 5305196 | Deaton et al. | Apr 1994 | A |
| 5327508 | Deaton et al. | Jul 1994 | A |
| 5359509 | Little et al. | Oct 1994 | A |
| 5388165 | Deaton et al. | Feb 1995 | A |
| 5430644 | Deaton et al. | Jul 1995 | A |
| 5448471 | Deaton et al. | Sep 1995 | A |
| 5544044 | Leatherman | Aug 1996 | A |
| 5550734 | Tarter et al. | Aug 1996 | A |
| 5588649 | Blumberg et al. | Dec 1996 | A |
| 5592560 | Deaton et al. | Jan 1997 | A |
| 5612868 | Off et al. | Mar 1997 | A |
| 5621812 | Deaton et al. | Apr 1997 | A |
| 5628530 | Thornton | May 1997 | A |
| 5638457 | Deaton et al. | Jun 1997 | A |
| 5642485 | Deaton et al. | Jun 1997 | A |
| 5644723 | Deaton et al. | Jul 1997 | A |
| 5644778 | Burks et al. | Jul 1997 | A |
| 5649114 | Deaton et al. | Jul 1997 | A |
| 5659469 | Deaton et al. | Aug 1997 | A |
| 5675662 | Deaton et al. | Oct 1997 | A |
| 5687322 | Deaton et al. | Nov 1997 | A |
| 5704044 | Tarter et al. | Dec 1997 | A |
| 5748907 | Crane | May 1998 | A |
| 5749907 | Mann | May 1998 | A |
| 5832447 | Rieker et al. | Nov 1998 | A |
| 5832457 | O'Brien | Nov 1998 | A |
| 5845255 | Mayaud | Dec 1998 | A |
| 5857175 | Day et al. | Jan 1999 | A |
| 5892827 | Beach et al. | Apr 1999 | A |
| 5892900 | Ginter et al. | Apr 1999 | A |
| 5915007 | Klapka | Jun 1999 | A |
| 5926795 | Williams | Jul 1999 | A |
| 5950169 | Borghesi et al. | Sep 1999 | A |
| 5956736 | Hanson et al. | Sep 1999 | A |
| 5963915 | Kirsch | Oct 1999 | A |
| 5970469 | Scroggie et al. | Oct 1999 | A |
| 5974399 | Giuliani et al. | Oct 1999 | A |
| 5991750 | Watson | Nov 1999 | A |
| 6006242 | Poole et al. | Dec 1999 | A |
| 6012035 | Freeman et al. | Jan 2000 | A |
| 6014634 | Scroggie et al. | Jan 2000 | A |
| 6021392 | Lester et al. | Feb 2000 | A |
| 6026370 | Jermyn | Feb 2000 | A |
| 6041309 | Laor | Mar 2000 | A |
| 6055573 | Gardenswartz et al. | Apr 2000 | A |
| 6067069 | Krause | May 2000 | A |
| 6067524 | Byerly et al. | May 2000 | A |
| 6073104 | Field | Jun 2000 | A |
| 6185541 | Scroggie et al. | Feb 2001 | B1 |
| 6195612 | Pack-Harris | Feb 2001 | B1 |
| 6202923 | Boyer et al. | Mar 2001 | B1 |
| 6205455 | Umen | Mar 2001 | B1 |
| 6208973 | Boyer et al. | Mar 2001 | B1 |
| 6224387 | Jones | May 2001 | B1 |
| 6240394 | Uecker | May 2001 | B1 |
| 6260758 | Blumberg | Jul 2001 | B1 |
| 6278979 | Williams | Aug 2001 | B1 |
| 6282516 | Giuliani | Aug 2001 | B1 |
| 6298330 | Gardenswartz et al. | Oct 2001 | B1 |
| 6304849 | Uecker et al. | Oct 2001 | B1 |
| 6307940 | Yamamoto et al. | Oct 2001 | B1 |
| 6307958 | Deaton et al. | Oct 2001 | B1 |
| 6321210 | O'Brien et al. | Nov 2001 | B1 |
| 6324516 | Shults et al. | Nov 2001 | B1 |
| 6330546 | Gopinathan et al. | Dec 2001 | B1 |
| 6334108 | Deaton et al. | Dec 2001 | B1 |
| 6341265 | Provost et al. | Jan 2002 | B1 |
| 6343271 | Peterson et al. | Jan 2002 | B1 |
| 6351735 | Deaton et al. | Feb 2002 | B1 |
| 6377935 | Deaton et al. | Apr 2002 | B1 |
| 6424949 | Deaton et al. | Jul 2002 | B1 |
| 6427020 | Rhoads | Jul 2002 | B1 |
| 6484146 | Day et al. | Nov 2002 | B2 |
| 6584448 | Laor | Jun 2003 | B1 |
| 6632251 | Rutten et al. | Oct 2003 | B1 |
| 6671692 | Marpe et al. | Dec 2003 | B1 |
| 6671693 | Marpe et al. | Dec 2003 | B1 |
| 6684195 | Deaton et al. | Jan 2004 | B1 |
| 6714918 | Hillmer et al. | Mar 2004 | B2 |
| 6757898 | Ilsen et al. | Jun 2004 | B1 |
| 6769228 | Mahar | Aug 2004 | B1 |
| 6795809 | O'Brien et al. | Sep 2004 | B2 |
| 6879959 | Chapman et al. | Apr 2005 | B1 |
| 6885994 | Scroggie et al. | Apr 2005 | B1 |
| 7013284 | Guyan et al. | Mar 2006 | B2 |
| 7024374 | Day et al. | Apr 2006 | B1 |
| 7058584 | Kosinski et al. | Jun 2006 | B2 |
| 7058591 | Giuliani et al. | Jun 2006 | B2 |
| 7111173 | Scheidt | Sep 2006 | B1 |
| 7155397 | Alexander et al. | Dec 2006 | B2 |
| 7225052 | Foote et al. | May 2007 | B2 |
| 7228285 | Hull et al. | Jun 2007 | B2 |
| 7233913 | Scroggie et al. | Jun 2007 | B2 |
| 7309001 | Banfield et al. | Dec 2007 | B2 |
| 7356460 | Kennedy et al. | Apr 2008 | B1 |
| 7380707 | Fredman | Jun 2008 | B1 |
| 7401027 | Moore et al. | Jul 2008 | B2 |
| 7415426 | Williams et al. | Aug 2008 | B2 |
| 7418400 | Lorenz | Aug 2008 | B1 |
| 7426480 | Granger et al. | Sep 2008 | B2 |
| 7685006 | Rahn et al. | Mar 2010 | B2 |
| 7917378 | Fitzgerald et al. | Mar 2011 | B2 |
| 8321243 | Harris, Sr. et al. | Nov 2012 | B1 |
| 20010001014 | Akins, III et al. | May 2001 | A1 |
| 20010032099 | Joao | Oct 2001 | A1 |
| 20010037216 | Oscar et al. | Nov 2001 | A1 |
| 20010037224 | Eldridge et al. | Nov 2001 | A1 |
| 20010041993 | Campbell | Nov 2001 | A1 |
| 20020002495 | Ullman | Jan 2002 | A1 |
| 20020032583 | Joao | Mar 2002 | A1 |
| 20020035488 | Aquila et al. | Mar 2002 | A1 |
| 20020044043 | Chaco et al. | Apr 2002 | A1 |
| 20020049617 | Lencki et al. | Apr 2002 | A1 |
| 20020055856 | Adams | May 2002 | A1 |
| 20020065687 | Onoue | May 2002 | A1 |
| 20020087554 | Seelinger | Jul 2002 | A1 |
| 20020087583 | Morgan et al. | Jul 2002 | A1 |
| 20020111832 | Judge | Aug 2002 | A1 |
| 20020120473 | Wiggins | Aug 2002 | A1 |
| 20020128883 | Harris | Sep 2002 | A1 |
| 20020133503 | Amar et al. | Sep 2002 | A1 |
| 20020138593 | Novak et al. | Sep 2002 | A1 |
| 20020175370 | Bockelman | Nov 2002 | A1 |
| 20020183979 | Wildman | Dec 2002 | A1 |
| 20020198831 | Patricelli et al. | Dec 2002 | A1 |
| 20030009357 | Pish | Jan 2003 | A1 |
| 20030009367 | Morrison | Jan 2003 | A1 |
| 20030028404 | Herron et al. | Feb 2003 | A1 |
| 20030050799 | Jay et al. | Mar 2003 | A1 |
| 20030074218 | Liff et al. | Apr 2003 | A1 |
| 20030074222 | Rosow et al. | Apr 2003 | A1 |
| 20030083903 | Myers | May 2003 | A1 |
| 20030120588 | Dodd et al. | Jun 2003 | A1 |
| 20030125986 | Collosi | Jul 2003 | A1 |
| 20030149594 | Beazley et al. | Aug 2003 | A1 |
| 20030149625 | Leonardi et al. | Aug 2003 | A1 |
| 20030154163 | Phillips et al. | Aug 2003 | A1 |
| 20030229540 | Algiene | Dec 2003 | A1 |
| 20040006490 | Gingrich et al. | Jan 2004 | A1 |
| 20040019464 | Martucci et al. | Jan 2004 | A1 |
| 20040039599 | Fralic | Feb 2004 | A1 |
| 20040046020 | Andreasson et al. | Mar 2004 | A1 |
| 20040049422 | Mortimer | Mar 2004 | A1 |
| 20040054657 | Takeyama | Mar 2004 | A1 |
| 20040073457 | Kalies | Apr 2004 | A1 |
| 20040078234 | Tallal, Jr. | Apr 2004 | A1 |
| 20040093242 | Cadigan et al. | May 2004 | A1 |
| 20040107117 | Denny | Jun 2004 | A1 |
| 20040111277 | Pearson et al. | Jun 2004 | A1 |
| 20040111291 | Dust et al. | Jun 2004 | A1 |
| 20040117323 | Mindala | Jun 2004 | A1 |
| 20040148198 | Kalies | Jul 2004 | A1 |
| 20040153336 | Virdee et al. | Aug 2004 | A1 |
| 20040172281 | Stanners | Sep 2004 | A1 |
| 20040172313 | Stein et al. | Sep 2004 | A1 |
| 20040188998 | Henthorn | Sep 2004 | A1 |
| 20040249745 | Baaren | Dec 2004 | A1 |
| 20050015280 | Gabel et al. | Jan 2005 | A1 |
| 20050033604 | Hogan | Feb 2005 | A1 |
| 20050033610 | Cunningham | Feb 2005 | A1 |
| 20050060201 | Connely et al. | Mar 2005 | A1 |
| 20050065821 | Kalies | Mar 2005 | A1 |
| 20050086081 | Brock-Fisher | Apr 2005 | A1 |
| 20050090425 | Reardan et al. | Apr 2005 | A1 |
| 20050102169 | Wilson | May 2005 | A1 |
| 20050102170 | Lefever et al. | May 2005 | A1 |
| 20050125292 | Kassab et al. | Jun 2005 | A1 |
| 20050154627 | Zuzek et al. | Jul 2005 | A1 |
| 20050171815 | Vanderveen | Aug 2005 | A1 |
| 20050187793 | Myles | Aug 2005 | A1 |
| 20050197862 | Paterson et al. | Sep 2005 | A1 |
| 20050240473 | Ayers | Oct 2005 | A1 |
| 20050288972 | Marvin et al. | Dec 2005 | A1 |
| 20060015518 | Eletreby et al. | Jan 2006 | A1 |
| 20060020514 | Yered | Jan 2006 | A1 |
| 20060026041 | Ullman et al. | Feb 2006 | A1 |
| 20060085230 | Brill et al. | Apr 2006 | A1 |
| 20060149587 | Hill, Sr. et al. | Jul 2006 | A1 |
| 20060149784 | Tholl et al. | Jul 2006 | A1 |
| 20060184391 | Barre et al. | Aug 2006 | A1 |
| 20060224415 | Hudson et al. | Oct 2006 | A1 |
| 20060229915 | Kosinski et al. | Oct 2006 | A1 |
| 20060247948 | Ellis et al. | Nov 2006 | A1 |
| 20060259363 | Jhetam | Nov 2006 | A1 |
| 20060271398 | Belcastro | Nov 2006 | A1 |
| 20060271405 | Cipolle et al. | Nov 2006 | A1 |
| 20060287886 | Kitazawa | Dec 2006 | A1 |
| 20070005402 | Kennedy et al. | Jan 2007 | A1 |
| 20070050209 | Yered | Mar 2007 | A1 |
| 20070050219 | Sohr et al. | Mar 2007 | A1 |
| 20070088567 | Berkelhamer et al. | Apr 2007 | A1 |
| 20070088576 | de Beus et al. | Apr 2007 | A1 |
| 20070124177 | Engleson et al. | May 2007 | A1 |
| 20070136100 | Daugherty et al. | Jun 2007 | A1 |
| 20070179957 | Gibson et al. | Aug 2007 | A1 |
| 20070233525 | Boyle | Oct 2007 | A1 |
| 20070233526 | Hoffman et al. | Oct 2007 | A1 |
| 20070239493 | Sweetland et al. | Oct 2007 | A1 |
| 20080027759 | Flam et al. | Jan 2008 | A1 |
| Number | Date | Country |
|---|---|---|
| 2482370 | Mar 2006 | CA |
| 1310895 | Nov 2002 | EP |
| WO9106917 | May 1991 | WO |
| 9503569 | Feb 1995 | WO |
| WO9725682 | Jul 1997 | WO |
| WO9850871 | Nov 1998 | WO |
| 0039737 | Jul 2000 | WO |
| 2007025295 | Mar 2007 | WO |
| Entry |
|---|
| Sampson, R.J., Taking Control of Health Care Costs, Best's Review—Life Health Insurance Edition, Nov. 1983, pp. 64-66, vol. 84, Issue 7, USA. |
| Anonymous, ACS to Demonstrate Electronic Health Record Solution Suite at MMIS 2007 Conference; EHR Tools Consolidate Data, Provide Useful Information at the Point of Care for Medicaid Providers, Payers, and Patients, PR Newswire, Aug. 13, 2007, New York, NY, USA. |
| Lamb, J., New Era of Electronic Medicine Management: E-Prescriptions, Britain's Traditionally Cautious National Health Service is Starting Trials for Online Prescription, with the Aim of Cutting Costs. Financial Times, London, Feb. 21, 2001, p. 6, London, United Kingdom. |
| Anonymous, Pharmacy Industry Leaders Launch Firm to Supply Real-Time Data. PR Newswire. Jul. 30, 2001, p. 1, New York, NY, USA. |
| Anonymous, Medic: On-line Goes In-House, Chain Store Age Executive, Jan. 1987, pp. 128-132. vol. 63, Issue 1, USA. |
| Anonymous, TechRx Announces Successful Beta Deployment of T-Rex. PR Newswire. May 13, 2002. |
| “Two automatic identification technology, neither new in the sense if being recent developments . . . ” Patient Safety & Quality Healthcare [Online] Aug. 2005. URL: http://www.awarix.com. |
| “Subnotebooks, Phones, and More. St. Vincent's Gets on Track.” Mobile Health Data [Online], Nov. 19, 2004. URL: http://www.awarix.com. |
| “Coping with Information Overload.” The News Source for Healthcare Information Technology [Online] Nov. 2004. URL: http://www.awarix.com. |
| “St. Vincent's first to use Birmingham startup's information system.” The Birmingham News [Online] Apr. 11, 2005. URL: http://www.awarix.com. |
| “St. Vincent's is Digital Flagship” D. Lockridge; Birmingham Medical News [Online] Sep. 2005. |
| Non-Final Office Action for U.S. Appl. No. 12/705,921 mailed Jan. 17, 2012. |
| Non-Final Office Action for U.S. Appl. No. 12/644,232 mailed Dec. 8, 2011. |
| Non-final Office Action for U.S. Appl. No. 12/696,677 mailed Dec. 20, 2011. |
| Notice of Allowance and Fees Due for U.S. Appl. No. 12/705,921 mailed Aug. 21, 2012. |
| “Medi-Cal POS NCPDP Pharmacy Transaction Specifications Third Party Vendors”; May 2005. |
| Final Office Action for U.S. Appl. No. 12/644,232 mailed Mar. 28, 2012. |
| Final Office Action for U.S. Appl. No. 12/705,921 mailed Apr. 30, 2012. |
| Final Office Action for U.S. Appl. No. 12/696,677 mailed May 2, 2012. |
