Patent Grant
10297344
Aspects of the disclosure relate generally to patient medication histories, and more particularly, to systems and methods for aggregating a patient's medication history across multiple covered entities to establish the patient's longitudinal medication history across the multiple covered entities.
An individual's longitudinal medication history can include a chronological history of medications the patient has taken over a period of time. One measure of a patient's longitudinal medication history can include the number and types of over the counter (“OTC”) medications and/or prescription medications a patient has purchased over a time period. In general, an individual goes to a pharmacy to purchase OTC medications and/or prescription medications. However, an individual's identification information, the pharmacy they purchase medications from, and/or the health insurance company they have can change over a period of time. Correspondingly, an individual's medication history can be distributed over many covered entities (e.g., insurance companies and pharmacies) during a given time period. For example, an individual may go to different pharmacies to have their prescriptions filled and/or to purchase OTC medications. In such an example, an individual's medication history is distributed over multiple pharmacies. In another example, the individual may get their medications from store A of Pharmacy Chain in City A and Store B of Pharmacy Chain in City B. In such an example, the pharmacy chain may identify the patient as two distinct individuals because the individual's identification information (e.g., the patient's address) has changed. Accordingly, it can be difficult to accurately establish a patient's longitudinal medication history because, for example, a patient's medication information can be distributed over multiple covered entities and/or distributed with different identification information.
Furthermore, patient privacy regulations can complicate establishing an individual's longitudinal medication history. Patient privacy regulations can include, but are not limited to, rules promulgated by the Department of Health & Human Services (“HHS”) pursuant to the Health Insurance Portability and Accountability Act (“HIPPA”) and the Health Information Technology for Economic and Clinical Health (“HITECH”) Act. Such patient privacy regulations limit what type of and how patient information can be shared among covered entities absent patient consent or contractual relationship between covered entities. For example, patient privacy regulations do not allow patient medication history data to be shared across the same type of covered entity absent an individual's consent (e.g., distinct pharmacy are not permitted to share patient medication history data absent an individual's consent). Furthermore, even when consent is given by an individual, patient privacy regulations do not permit another individual's information data to be accessed even if only to determine the other individual is not the individual who gave consent. Accordingly, it can be difficult to establish the full scope of a patient's medication history over long periods of time in accordance with applicable patient privacy regulations.
Reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
Exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments are shown. The concepts disclosed herein may, however, be embodied in many different forms and should not be construed as limited to the exemplary 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 concepts to those skilled in the art. Like numbers refer to like, but not necessarily the same or identical, elements throughout.
Exemplary embodiments described herein include systems and methods that facilitate the establishment of an individual's longitudinal medication history, in accordance with privacy regulations. In some example embodiments, the systems and methods generate linking indexes to link an individual's medication history data across one or more pharmacies and one or more claims processors (e.g., a Pharmacy Benefits Manager (PBM), claims payor, healthcare insurance company, Medicare, Medicaid, or other government healthcare insurance payor, Medicare Part D provider, claims clearinghouse, etc.). As used herein, a pharmacy refers to all pharmacy stores doing business under a given name, unless explicitly referred to otherwise. For example, a pharmacy refers to the all stores of a pharmacy chain (e.g., CVS and Walgreens pharmacy). The linking indexes can be generated from patient identification data gathered by the system in accordance with patient privacy regulations. In some example embodiments, the systems and methods can generate a linking index for one or more individuals relative to one or more pharmacies and/or one or more claims processor computers associated with one or more claims processors. For example, a linking index can be generated for an individual relative to a single pharmacy, multiple pharmacies, a single claims processor, multiple claims processors, or any combination thereof. In such an example, the linking index can correspond to a unique individual identified from the patients represented by patient identification data from a single pharmacy, multiple pharmacies, a single claims processor, multiple claims processors, or any combination thereof. In certain example embodiments, the systems and methods described herein can desirably generate linking indexes for an individual over single pharmacies and over multiple claims processors. In some example embodiments, an individual can consent to having the individual's longitudinal medication history established over a selected group of pharmacies, claims processors, or pharmacies and claims processors. In such embodiments, the systems and methods described herein can link the individual's medication history over the selected group of pharmacies, claims processors, or pharmacies and claims processors using the linking indexes for the individual.
Patient privacy regulations (e.g., HIPAA and/or HITECH) can restrict what type of, and how, patient information data (e.g., patient identification data and patient medication history data) can be shared between covered entities. Covered entities include, but are not limited to, claims processors (e.g., a Pharmacy Benefits Manager (PBM), claims payor, healthcare insurance company, Medicare, Medicaid, or other government healthcare insurance payor, Medicare Part D provider, claims clearinghouse, etc.) and pharmacies. For example, patient privacy regulations, in general, do not allow different covered entities to share patient medication history data, absent patient consent. As another example, even where an individual's consent exists, privacy regulations only allow those records belonging to that individual to be accessed to establish a longitudinal patient medication history for that individual (i.e., medication history records belonging to another individual may not be accessed, even if only to determine that those records belong do not belong to the same individual who's longitudinal medication history is being established). On the other hand, patient privacy regulations do allow distinct claims processors to share patient identification information data (described in detail below). However, even in such situations, patient identification information data can only be shared between distinct claims processors that are parties to a data rights management agreement(s).
In some example embodiments, a service provider computer can generate an individual's longitudinal medication history based at least in part upon patient information data that is collected by the service provider computer, in accordance with patient privacy regulations and incident to the service provider computer providing services for covered entities. For example, a service provider computer can, according to patient privacy regulations, collect patient identification data including, but not limited to, patient demographic data and/or billing data from a given claims processor computer in response to the claims processor computer's (i.e., a computer located within or providing computing services for a claims processor) request to sign-up one or more individuals for Eligibility Services, including, but not limited to, immunization opportunity identification, cash medication regimen tracking, and/or medication therapy management (“MTM”). In some example embodiments and in accordance with patient privacy regulations, a claims processor computer can sign-up one or more individuals who receive health insurance coverage from the claims processor associated with the claims processor computer. As another example, a service provider computer can collect patient identification data for a given pharmacy computer in response to the pharmacy associated with (i.e., located within or providing primary computing services for) the pharmacy computer's request to sign-up for services related to billing transaction processing and/or Eligibility Services between the pharmacy computer and the claims processor computer.
In certain example embodiments, based at least in part on the collected patient identification data, a service provider computer can generate linking indexes to link an individual patient's medication history data across a pharmacy and/or one or more claims processors. In some example embodiments, the service provider computer can identify individuals associated with one or more covered entities from patient identification information collected by the service provider computer incident to performing services for those one or more covered entities. For example, the service provider computer can identify individuals from a set of patient identification data received from one or more pharmacy computers and/or one or more claims processor computers. For example, the service provider computer can generate a linking index for each identified individual and associate the linking index with a unique identifier (“individual longitudinal identifier,” discussed below). The linking index can include one or more keys corresponding to distinct patients, representing the same individual, in the set of patient identification data. For example, the set of patient identification data can correspond to patient identification data received from a pharmacy computer associated with a pharmacy. In such embodiments, an individual may be represented by two (or more) distinct patient identification data (i.e., the pharmacy can have two (or more) distinct patient records for the same individual) and the service provider computer can create a key for each of the two (or more) distinct representations of the individual in the patient identification records received from the pharmacy computer. As used herein, “patient” refers to a covered entity's representation of an “individual” through patient identification data.
In some example embodiments, a key can include one or more key fields and corresponding key values. The example key fields can be selected from some or all of the patient identification data collected by the service provider computer. Example keys associated with different covered entities can have one or more common key fields. When the service provider computer receives a notification of an individual's consent to establish the individual's longitudinal medication history across covered entities, or any subset thereof, the service provider computer can link the individual's medication histories across different covered entities by searching for common keys among the linking indexes associated with each covered entity. In such an example embodiment, the service provider computer can selectively identify an individual's medication history across one or more pharmacies and one or more claims processors (i.e., the service provider computer does not access any other individual's patient information data) and generate an individual's longitudinal medication history.
System Overview
The example service provider computer 102 may include, but is not limited to, any suitable processor-driven device that is configured for receiving, processing, and fulfilling medication services between healthcare providers (including, but not limited to, hospitals, clinics, physician's offices, and prescribers of medication), the pharmacy computers 104, and/or claims processor computers 106. Medication services can include, but are not limited to, data related to patient demographic information data (e.g., patient date of birth, patient gender, patient zip/postal code, patient marital status, and number of family members), patient billing information (e.g., patient first name, patient last name, spouse first name, spouse last name, patient street address, cardholder ID, national provider identifier (“NPI”)), and/or data related to patient medication history (e.g., medication identifier (i.e., medication name, National Drug Code (NDC) code, Rx number, etc.) and dosage). Any number of pharmacy computers 104, and/or claims processor computers 106 may be in communication with the service provider computer 102 as desired in various example embodiments via, for example, the network 132.
Generally, network devices and systems, including one or more service provider computers 102, pharmacy computers 104, and/or the claims processor computers 106, 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 communication 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 currently known in the art or which may be developed in the future. 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 medium for storing computer-executable instructions.
As shown in
With continued reference to
The service provider computer 102 may include one or more processors 133, one or more memory devices 134, one or more input/output (“I/O”) interfaces 136, and one or more network interfaces 138. The one or more memory devices 134 may be any suitable memory device, for example, caches, read only memory devices, random access memory devices, magnetic storage devices, removable memory devices, etc. The one or more memory devices 134 may store data, executable instructions, and/or various program modules utilized by the service provider computer 102, for example, data files 140 and an operating system (“OS”) 142. The OS 142 may be any operating system known in the art or which may be developed in the future including, but not limited to, Microsoft Windows®, Apple OSX™, Linux, Unix, Apple iOS™, Google Android™, or a mainframe operating system. The OS 142 may be a suitable software module that controls the general operation of the service provider computer 102 and/or that facilitates the execution of other software modules.
The service provider computer 102 may include any number of special-purpose computers or other particular machines, application-specific integrated 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 102 may be controlled by computer-executed or computer-implemented instructions that are executed by one or more processors associated with the service provider computer 102 to form a special-purpose computer or other particular machine that is operable to facilitate the receipt, routing, and/or processing of healthcare requests or healthcare transactions. The one or more processors that control the operations of the service provider computer 102 may be incorporated into the service provider computer 102 and/or may be in communication with the service provider computer 102 via one or more suitable networks. In certain example embodiments, the operations and/or control of the service provider computer 102 may be distributed among several processing components.
According to an example embodiment, the data files 140 may store patient identification data and patient medication history data associated with communications received from various pharmacy computers 104 and/or various claims processor computers 106. The data files 140 may also store any number of suitable routing tables that facilitate determining the destination of communications received from the claims processor computer 106 and/or the pharmacy computer 104. In one or more example embodiments of the disclosure, the service provider computer 102 may include or otherwise be in communication with one or more suitable databases and/or data storage devices 108 including, but not limited to, one or more patient identification data files 116, 120 and patient medication history data files 118, 122.
The service provider computer 102 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 102 may include alternate and/or additional components, hardware, or software without departing from the scope of the disclosure. For example, the service provider computer 102 may include the claims processor module 150 and/or the pharmacy module 152. The claims processor module 150 can include computer-executable instructions for facilitating, among other things, receipt and/or communication of patient identification data and, optionally, patient medication history data from the claims processor computer 106 (e.g., the claims processor management module 124 or another module associated with a back-end system including one or more of the computers of claims processor computer 106). In some example embodiments, patient identification data and, optionally, patient medication history data can be provided to claims processor module 150 from one or more computers associated with any entity transacting through service provider computer 102 including, but not limited to, a Pharmacy Benefits Manager (“PBM”), claims payor, healthcare insurance company, Medicare, Medicaid, or other government healthcare insurance payor, Medicare Part D provider, claims clearinghouse, etc. The pharmacy module 152 can include computer-executable instructions for facilitating, among other things, receipt and/or communication of patient identification data and patient medication history data from the pharmacy computer 104 (e.g., the pharmacy management module 126). In certain exemplary embodiments, the claims processor module 150 may be implemented as computer-implemented instructions of the memory 134 of the service provider computer 102 or otherwise may be located within the service provider computer 102. Alternatively, the claims processor module 150 may also be implemented as computer-implemented instructions of a memory of a separate computing entity or processor-based system, according to another example embodiment of the disclosure.
In one example implementation, the claims processor module 150 can be operative to receive identifiers, patient identification data and, optionally, patient medication history data, from the claims processor management module 124 of the claims processor computer 106. In one example embodiment, the claims processor module 150 can communicate the received identifiers and patient identification data to the database 108 and store the data in patient identification data files 116 or otherwise store the data in the data files 140. If the claims processor module 150 receives patient medication history data from the claims processor management module 124, the claims processor module 150 can communicate the received patient medication history data to database 108 and/or the data files 140 and store the received data in the patient medication history data files 118.
As another example, the pharmacy module 152 can be operative to receive patient identification data and patient medication history data from the pharmacy management module 126. The pharmacy module 150 can communicate the received patient identification data and patient medication history data to the database 108 and store the data in patient identification data files 120 and patient medication history data 122, respectively. Alternatively, the pharmacy module 150 can store the data in the data files 140.
With continued reference to the service provider computer 102, the one or more I/O interfaces 136 may facilitate communication between the service provider computer 102 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 102. The one or more network interfaces 138 may facilitate connection of the service provider computer 102 to one or more suitable networks, for example, the network 132 illustrated in
With continued reference to
Similar to other components of the system 100, each pharmacy computer 104 may include one or more processors 154, one or more memory devices 156, one or more I/O interfaces 158, and one or more network interfaces 160. The one or more memory devices 156 may be any suitable memory devices, for example, caches, read-only memory device, random access memory devices, magnetic storage devices, removable memory devices, etc. The one or more memory devices 156 may store data, executable instructions, and/or various program modules utilized by the pharmacy computer 104, for example, data files 162, an OS 164, and a pharmacy management module 126. The data files 162 may include any suitable information that is utilized by the pharmacy computer 104. The OS 164 may be a suitable software module that controls the general operation of the pharmacy computer 104. The OS 164 may also facilitate the execution of other software modules by the one or more processors 154. The OS 164 may be any operating system known in the art or which may be developed in the future including, but not limited to, Microsoft Windows®, Apple OSX™, Linux, Unix, Apple iOS™, Google Android™, or a mainframe operating system.
The one or more I/O interfaces 158 may facilitate communication between the pharmacy 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 pharmacy computer 104. The one or more network interfaces 160 may facilitate connection of the pharmacy computer 104 to one or more suitable networks, for example, the network 132 illustrated in
The pharmacy management module 126 may be a software application(s), including a dedicated program, for transmitting healthcare transactions, reading and/or updating medical records (e.g., prescription records), facilitating patient billing, etc., as well as interacting with the service provider computer 102. For example, a pharmacist or other pharmacy employee, may utilize the pharmacy management module 126 in filling a prescription, recording and/or updating a patient's medical prescription history, billing a patient and/or claims processor, and preparing and providing a healthcare transaction request for information to the service provider computer 102. Furthermore, the pharmacy computer 104 may utilize the pharmacy management module 126 to retrieve or otherwise receive data, messages, or responses from other components of the system 100.
The claims processor computer 106 may be one or more processor-driven devices, such as, but not limited to, a server computer, a personal computer, a laptop computer, a handheld computer, a tablet computer, a smart phone, and the like. In addition to having one or more processors 168, the claims processor computer 106 may further include one or more memory devices 170, one or more input/output (I/O) interfaces 172, and one or more network interfaces 174. The one or more memory devices 170 may store data files 176 and various program modules, such as an operating system (OS) 178 and a claims processor management module 124. In one example embodiment, the data files 176 can include patient identification data files and associated patient medication history data files. In some such embodiments, the data files 176 can include an identifier that associates the patient identification files and patient medication history data files with a particular individual. The I/O interface 172 may facilitate communication between the processors 168 and various I/O devices, such as a keyboard, mouse, printer, microphone, speaker, monitor, bar code reader/scanner, RFID reader, and the like. The one or more network interfaces 174 may facilitate connection of the claims processor computer 106 to one or more suitable networks, for example, the network 132 illustrated in
Generally, the claims processor computer 106 may facilitate the determination of benefits, coverage, and/or extent of coverage for one or more healthcare transactions, such as prescription claim transactions or other healthcare service or product claim transactions. According to various example embodiments, the claims processor computer 106 may be associated with, without limitation, a PBM, an insurance company, a government payor affiliated entity, another third-party payor, or a claims processor processing healthcare claim transactions and performing adjudication on behalf of one or more third-party payors and/or healthcare providers. In one example embodiment, the claims processor computer 106 may be operated by, or otherwise included with, the service provider computer 102, such as if the service provider operates the claims processor computer 106 and provides adjudication services.
The claims processor computer 106 may include the claims processor management module 124. The claims processor management module 124 may be an Internet browser or other software, such as a dedicated program, for interacting with the service provider computer 102 and/or the pharmacy computer 104.
In one or more example embodiments of the disclosure, the service provider computer 102 may include or otherwise be in communication with one or more suitable databases and/or data storage devices 108. The one or more databases 108 may include one or more data files comprising data including, but not limited to, claims processor data files 110, the pharmacy data files 112, and contract data files 114. Claims processor data files 110 can include, but are not limited to, patient identification data files 116 and patient medication history data files 118. The pharmacy data files 112 can include, but are not limited to, patient identification data files 120 and patient medication history data files 122. In some example embodiments, the database 108 can include separate claims processor data files 110 corresponding to each distinct claims processor associated with claims processor computer 106 and/or separate pharmacy data files 112 corresponding to each distinct pharmacy associated with the pharmacy computer 104. In such embodiments, the database 108 can keep patient information data files and patient medication history data files corresponding to different claims processors and/or different pharmacies separate form one-another (i.e., not commingled).
The one or more patient identification data files 116 and patient medication history data files 118 can contain patient identification information and patient medication history information, respectively, received from the claims processor computer 106. In one example implementation, the claims processor management module 124 can communicate the patient identification data and/or patient medication history data to the service provider computer 102. The service provider computer 102 can facilitate storage of the patient identification data in the patient identification data file 116 and patient medication history data in patient medication history data file 118. The identification data files 120 and patient medication history data files 122 can contain patient identification information and patient medication history information, respectively, received from the pharmacy computer 104. In some example embodiments, a plan sponsor or sponsors (e.g, payer, etc.) when contracting through a PBM may transmit the one or more patient identification data files 116 and patient medication history data files 118 directly to the service provider computer 102 through the network 132. In one example implementation, the pharmacy management module 126 can communicate the patient identification information data and/or patient medication history data to the service provider computer 102. The service provider computer 102 can facilitate storage of the patient identification data in patient identification data file 120 and patient medication history data in patient medication history data file 122.
Patient identification data communicated to the service provider computer 102 from the pharmacy computer 104 and/or the claims processor computer 106 can include, but is not limited to, name (e.g., patient last name, patient first name, etc.), date of birth of patient, age of patient, patient gender (e.g., gender code), patient address (e.g., street address, city, state/province, zip/postal code, etc.), patient contact information (e.g., patient telephone number, email address, etc.), patient identification identifier (such as, but not limited to, patient social security number, a subset of the patient social security number, health insurance claim number (HICN), cardholder ID, etc.), cardholder name (e.g., cardholder first name, cardholder last name), cardholder ID and/or other identifier (e.g., person code), group ID and/or group information, prescriber primary care provider ID or other identifier (e.g., National Provider Identifier (NPI) code), primary care provider name (e.g., last name, first name), prescriber ID or other identifier (e.g., NPI code, Drug Enforcement Administration (DEA) number), prescriber name (e.g., last name, first name), prescriber contact information (e.g., telephone number, email address, fax number), pharmacy or other healthcare provider information (e.g., store name, chain ID), and/or pharmacy or other healthcare provider ID (e.g., NPI code). Patient medication history data communicated to the service provider computer 102 from the pharmacy computer 104 and/or the claims processor computer 106 can include, but is not limited to, drug, service, or product information (e.g., via NDC code or drug/service/product name), prescription/service reference number, date prescription was written, quantity dispensed, days' supply, diagnosis/condition, pricing information for the drug/service/product (e.g., network price, usual & customary price), number of refills authorized, one or more drug utilization (DUR) codes, and date of service.
The one or more contract data files 114 can include contract information between the service provider associated with the service provider computer 102 and the pharmacy associated with the pharmacy computer 104, and between the service provider associated with the service provider computer 102 and the claims processor associated with the claims processor computer 106. The contract information can include information relating to what services the service provider computer 102 is authorized to perform on behalf of the pharmacy computer 104 and/or the claims processor computer 106. Contract information related to the claims processor computer 106 can include, but is not limited to, an indication of whether the service provider computer 102 is authorized to perform an eligibility service on behalf of the claims processor computer 106. Contract information related to the pharmacy computer 104 includes, but is not limited to, whether the service provider computer 102 is authorized to perform billing services on behalf of the pharmacy computer 104. In some example embodiments, contract data files 115 can comprise contract information relating to data rights management that authorize service provider computer 102 to share patient identification data between distinct claims processors. In some such example embodiments, the contract information relating to data rights management can comprise a listing of each claims processor and, for each claims processor, a listing of with which other claims processors service provider computer 102 is authorized to share the claims processor's patient identification data. In some example embodiments, the service provider can require that, as a term of service, all claims processors signing-up for eligibility services authorize service provider computer 102 to share patient identification data between all claims processor computers 106 that are signed-up for eligibility services).
In one or more example embodiments of the disclosure, the service provider computers 102 can also include or otherwise be in communication with the identification module 128 or an individual identification application. The identification module 128 may include computer-executable instructions operable for identifying distinct individuals from patient identification data files, such as patient identification files 116, 120. Over a given time period, an individual's information may change. Changes in an individual's information can include, but are not limited to, changes in health insurance plan, health insurance providers, and health insurance health plan information (e.g., claims processor), residential addresses, and/or name. Correspondingly, an individual's identification data can be different for different covered entities. For example, Store A of Pharmacy in City A may have patient identification data for a customer named “Jane Doe”. Store B of Pharmacy in City B may have patient identification data for a customer named “Jane Doe.” It is not clear, on its face, whether the patient identification data at Store A and Store B belong to the same individual (e.g., “Jane Doe” may have moved from City A to City B or simply decided to use a different pharmacy store for filling separate prescriptions) or if the patient identification data refers to two distinct individuals (e.g., two different people with the same name, “Jane Doe”). Accordingly, in some example embodiments, the identification module 128 can include computer-executable instructions to apply probabilistic matching techniques to patient identification data to determine if the patient identification data is for the same person.
In certain example embodiments, the computer-executable instructions of the identification module 128 are operable to restrict individual identification logic in accordance with patient privacy regulations. For example, as discussed above, patient privacy regulations, in general, do not allow different covered entities to share patient data. As such, in one example embodiment, the identification module 128 can restrict patient identification logic to the patient identification data files 116, 120 of each claims processor associated with each claims processor computer 106 and/or of each pharmacy (or store thereof, or any combination of stores thereof) associated with one or more pharmacy computers 104. In such embodiments, the identification module 128 can identify individuals associated with each claims processor/claims processor computer 106 and/or each pharmacy/pharmacy computer 104. Privacy regulations, however, do allow different claims processors to share patient identification information. Thus, in some example embodiments, the identification module 128 can apply individual identification logic across patient identification data files 116 associated with one or more claims processors/claims processor computers 106. In such embodiments, the identification module 128 can identify individuals across all the claims processor entities or any subset(s) thereof.
The identification module 128 can include computer-executable code for generating a linking index from the patient identification data files 116 and 120. A linking index can include one or more keys that can be used to identify an individual's patient medication history data within different covered entities or any combination thereof, based at least in part on how the identification module 128 applies individual identification logic. In some example embodiments, the identification module 128 can generate a linking index for each individual relative to one or more covered entities. For example, identification module 128 can apply individual identification logic to generate an individual's linking index over one or more stores of a pharmacy/pharmacy computer 106, over one or more pharmacies/pharmacy computer 106, and/or over one or more claims processors/claims processor computer 106. As another example, the identification module 128 can apply individual identification logic to generate a linking index for a single pharmacy/pharmacy computer 104 and can independently apply individual identification logic to generate a linking index for multiple claims processor entities/claims processor computer 106. In such an embodiment, the identification module 128 can generate a linking index for each individual identified from the patient identification data files 116 corresponding to the single pharmacy/pharmacy computer 104 and can generate a linking index for each individual identified from the patient identification data files 116 corresponding to the multiple claims processor/claims processor computers 106. In some example embodiments, as explained in detail below, the keys can link an individual's linking indexes across different covered entities. Returning to the previous example, the one or more keys in an individual's linking index corresponding to the single pharmacy/pharmacy computer 104 can be used to identify that individual's linking index corresponding to the multiple claims processor/claims processor computer 106.
In some example embodiments, identification module 128 can also generate an individual longitudinal identifier for each linking index or group of linking indexes. The individual longitudinal identifier can include an alphabetical, numeric, or alphanumeric string of characters (e.g., “abcdef,” “1a2b3c” or “12345,” respectively). The individual longitudinal identifier can be directly or indirectly linked to an individual's patient medication history corresponding to the one or more covered entities over which the linking index or linking indexes are established. For example, a linking index can be generated over one or more stores of a pharmacy, one or more pharmacies and/or one or more claims processors from patient identification data files provided by, respectively, the one or more stores of a pharmacy/pharmacy computer 104, the one or more pharmacy/pharmacy computer 104 and/or the one or more claims processor/claims processor computer 106. In another example, a linking index can be generated from the patient identification data files 120 corresponding to a single pharmacy. In such an example, the identification module 128 can generate a individual longitudinal identifier for the individual and link the identifier to the patient medication history of the individual in the patient medication history data files 122 corresponding to the single pharmacy. In a further example, a linking index can be generated from the patient identification files 116 corresponding to multiple claims processors. In such an example, the identification module 128 can generate a individual longitudinal identifier for the individual and link the identifier to the patient medication history of the individual in patient medication history data files 118 corresponding to the multiple claims processors.
The identification module 128 can access the database 108 and store the one or more linking indexes therein. For example, the identification module 128 can store linking indexes generated from the patient identification data files 116 with the claims processor data files 110 and indexes generated from the patient identification data files 120 with the pharmacy data files 112. While the example embodiment of
In certain example embodiments, the service provider computer 102 can further include or otherwise be in communication with an aggregation module 130. The aggregation module 130 can include computer-executable instructions operable for establishing an individual's patient medication history across one or more pharmacy entities and/or one or more claims processor entities without accessing patient medication history data corresponding to another individual. For example, the aggregation module 130 can establish an individual's patient medication history based at least in part on the linking indexes.
The aggregation module 130 can access the database 108 to retrieve linking indexes generated by identification module 128. As explained in detail below, the aggregation module 130 can use the keys in the linking indexes to link a single individual's patient medication history data records across one or more pharmacies/pharmacy computers 104 and one or more the claims processors/claims processor computers 106, without accessing patient medication history data for another individual. In one example embodiment, the service provider computer 102 can transmit the individual longitudinal identifiers (or another unique representation thereof) linked with the linking indexes for an individual to the pharmacy computer 104, the claims processor computer 106, or a third-party computer to allow for the respective computers to establish an individual's longitudinal medication history. In some such embodiments, the pharmacy computer 104, the claims processor computer 106 and/or the third-party computer can be in communication with the aggregation module 130 and can be in communication with the database 108. While the example embodiment of
The network 132 may include any telecommunication and/or data network, whether public, private, or a combination thereof, including a local area network, a wide area network, an intranet, the Internet, intermediate handheld data transfer devices, and/or any combination thereof and may be wired and/or wireless, or any combination thereof. The network 132 may also allow for real time, offline, and/or batch transactions to be transmitted between or among the service provider computer 102, the pharmacy computer 104, and the claims processor computer 106. Various methodologies as described herein, may be practiced in the context of distributed computing environments. Although the service provider computer 102 is shown for simplicity as being in communication with the pharmacy computer 104, or the claims processor computer 106 via one intervening network 132, it is to be understood that any other network configurations are possible. For example, intervening network 132 may include a plurality of networks, each with devices such as gateways and routers for providing connectivity between or among the components of the system 100. Instead of or in addition to the network 132, dedicated communication links may be used to connect various devices in accordance with an example embodiment. For example, the service provider computer 102 may form the basis of network 132 that interconnects the pharmacy computer 104 and the claims processor computer 106.
Those of ordinary skill in the art will appreciate that the system 100 shown in and described with respect to
Operational Overview
Certain portions of the exemplary methods discussed below will be described with reference to establishing an individual's patient longitudinal medication history, across a pharmacy and a plurality of the claims processors. However, this is only for purposes of example as the person of ordinary skill in the art would know how to establish an individual's patient longitudinal medication history over any combination of pharmacies and claims processors, based upon the teachings herein.
Referring now to
At step 204, the service provider computer 102 optionally retrieves patient medication history data linked with the claims processor patient identifier from the patient medication history data files 118, if provided to the database 108 by the claims processor computer 106. In some example embodiments, the claims processor computer 106 can communicate patient medication history data linked with the claims processor patient identifier to database 108 for storage in the database 108, or to the service provider computer 102 for storage in the database 108. Upon receiving an eligibility request from the pharmacy computer 104 (and/or from a third party computer), the service provider computer 102 can retrieve patient medication data for the request from database 108 on behalf of claims processor computer 106. For other Eligibility services, service provider computer 102 can provide the service to claims processor computer 106 without receiving patient medication history data.
In one exemplary embodiment, the claims processor management module 124 can access the claims processor patient identifier, claims processor ID, patient identification data, and optional patient medication history data stored in data files 176 or another database and communicate that data to the claims processor module 150, identification module 128 or another portion of the service provider computer 102. For example where the identification module 128 is a part of the service provider computer 102 or otherwise affiliated with the service provider computer 102, the delivery of the claims processor patient identifier, claims processor ID, patient identification data, and optional patient medication history can be an internal delivery or an intra-network delivery. However, where the claims processor module 150 is a processor-based system distinct from the service provider computer 102, the delivery of the claims processor patient identifier, patient identification data, and optional patient medication history data may be an external delivery, for example, via the network 132, according to an example embodiment of the disclosure.
At step 206, the service provider computer 102 stores the claims processor patient identifier, claims processor ID and received patient identification data in, for example, the database 108. If the medication history data is also received, this data can also be stored in the database 108. The service provider computer 102 can store the received claims processor patient identifier, claims processor ID and patient identification data in the patient identification data files 116 and optional patient medication history data in the patient medication history data files 118 in the database 108. In some example embodiments, the service provider computer 102 can link the claims processor patient identifier to the claims processor ID, patient identification data and optional patient medication history data in the database 108. In such embodiments, the service provider computer 102 can locate, update and/or retrieve a claims processor's patient identification data and optional patient medication history data in database 108 using the claims processor patient identifier received from the claims processor computer 106. In some exemplary embodiments, to facilitate later processing of received patient identification data (e.g., by method 300), service provider can keep a record of newly received patient identification data that is stored in patient identification data files 116. In some such embodiments, newly received patient identification data can be stored in a data structure including a flag to indicate that it is newly received. For example, newly received patient identification data can be stored in a database structure (along with previously received patient identification data) where a row (or column) contains a database field for a flag. In some embodiments, the flag can be an integer, such as a “1” to indicate newly received patient identification data and/or a “0” to indication previously received patient identification data or a date and time stamp to indicate the time or receipt or time of transmission. The method then proceeds to the END step.
In certain example embodiments of method 200, prior to starting at step 202, the database 108 may have previously stored the claims processor patient identifiers, linked patient identification data and, linked optional patient medication history data received from the claims processor computer 106. In some such embodiments, service provider computer can access database 108 to determine if any of the stored claims processor patient identifiers match a claims processor patient identifier received at step 202. If not the service provider computer 102 can store the claims processor patient identifier received at step 202 in the database 108, patient identification data received at step 202 in patient identification data files 116 and, if received, patient medication history data received at step 204 in patient medication data files 118. If so, the service provider computer 102 can compare the newly received patient identification data at step 202 with the patient identification data patient identification data files 116 and linked with the claims processor patient identifier. If the newly received patient identification data at step 202 is the same as the patient identification data stored in patient identification data files 116, the service provider computer 102 can store the optional patient medication history data, if received at step 204, in patient medication history data files 118 and link it with the stored claims processor patient identifier. If the newly received patient identification data at step 202 is not the same as patient identification data stored in patient identification data files 116, the service provider computer 102 can store, in the patient identification data files 116, the newly received patient identification data and, if received at step 204, the newly received patient medication history data in the patient medication history data files 118, and link the newly stored data with the corresponding stored claims processor patient identifier.
Continuing to step 304, the identification module 128 or another portion of the service provider computer 102 computes a key for the first patient. A key can include one or more key fields and corresponding key values. The key fields are configurable based on the desires of the designer, can be preselected, and can be chosen from the patient identification data. In one example embodiment, a key can include the following key fields: patient date of birth|patient cardholder ID|patient person code|claims processor ID. The corresponding values can be the value of the key fields in the patient identification data. As is explained in detail below, the keys can be used to establish a patient's longitudinal medication history in accordance with patient privacy regulations.
At step 306, the identification module 128 or another portion of the service provider computer 102 selects patient identification data for a second patient from patient identification data files 116. In some example embodiments, the selection of patient identification data for a second patient is based at least in part on patient privacy regulations and the presence or absence of contractual relationships between different covered entities. For example, in the example embodiment depicted in
Identification module 128 can select patient identification data for the second patient without regards to whether the patient identification data was previously indexed by identification module 128. In certain example embodiments, selection of the patient identification data corresponding to the second patient can be random. At step 308, the identification module 128, for example, applies identification logic to the patient identification data of the first and second patients to determine whether the first and second patients correspond to the same individual. In particular, the identification module 128 can compare the patient identification data corresponding to the first patient and the patient identification data corresponding to the second patient to determine if the patient identification data for both correspond to the same individual. In some example embodiment, the identification logic can apply probabilistic matching techniques to patient identification data to effect the comparison. In such example, embodiments, matching functions can be applied to preselected patient identification data elements (“match fields”) obtained from the patient identification data associated with the first and second patients. A match field can include, but is not limited to, any patient identification data. In certain example embodiments, a match field can include patient first name, patient last name, patient date of birth, patient gender, patient address (or address EUID (normalized address), patient spouse's first name, patient spouse's last name, patient family count (e.g., number of family members covered by the patient's health insurance plan), patient address ID (address identifier used by the claims processor computer 106 to identify the patient's address).
The matching functions can be an exact matching function (i.e., returning first value if all of the input match fields are an exact match and returning a second value if even one of the input match fields are not an exact match) or a similarly matching function (i.e., return a spectrum of values based upon the similarity of the input match fields) and can be independently selected for each match field. The matching functions can be applied to corresponding match fields from the first and second patient to obtain matching values for each of the match fields. For example, if the match fields are represented by D1, D2 and D3 and the matching functions are f1, f2, and f3, the identification module 128 or another portion of the service provider computer 106 can compute match values f1(D1,1,D1,2), f2(D2,1,D2,2) and f3(D3,1,D3,2), where Dn,1 and Dn,2 correspond to the values of match fields Dn, obtained from the patient identification information for patients 1 and 2, respectively. As a further example, D1 and D2 can correspond to “patient first name” and “patient last name”, respectively. In such an example, match values f1 (“patient first name” of patient 1, “patient first name” of patient 2) and f2 (“patient last name” of patient 1, “patient last name” of patient 2) can be computed. The identification module 128 can calculate an overall matching score based upon the computed match values and determine if the overall matching score meets or exceeds a threshold value. In some example embodiments, each match value can be independently weighted in the calculation of the overall matching score. For example, match values f1(D1,1,D1,2), f2(D2,1,D2,2) and f3(D3,1,D3,2) can have corresponding weights w1, w2 and w3 such that the quantities w1f1(D1,1,D1,2), w2f2(D2,1,D2,2) and w3f3(D3,1,D3,2) are used in calculating the overall matching score.
In step 310, an inquiry is conducted to determine if a match exists (e.g., the first and second patients correspond to the same individual). In one example embodiment, this determination can be made by the identification module 128 or another portion of the service provider computer. If the identification module 128 determines the threshold value is exceeded or met or exceeded by the overall matching score, the identification module 128 can determine that the first and second patients correspond to the same individual and the YES branch is followed to step 318. If the identification module 128 determines that the threshold value is not exceeded or not met or exceeded by the overall matching score, the identification module 128 determines the first and second patients correspond to different individuals and the NO branch is followed to step 312. In other example embodiments, the identification module 128 can incorporate a threshold range. For example, identification module 128 can use an upper threshold value and a lower threshold value to define a threshold range of values. In such example embodiments, if the upper threshold value is exceeded or met or exceeded by the overall matching score, the identification module 128 can determine that the first and second patients correspond to the same individual. If the identification module 128 determines that the lower threshold value is not exceeded or not met or exceeded by the overall matching score, the identification module 128 determines the first and second patients correspond to different individuals. If the identification module 128 determines that the overall matching score is between the upper threshold value and lower threshold value, identification module 128 can invoke exception logic. In one example embodiment, exception logic can request a user to manually review the patient identification for the first and second patient and make a manual determination whether the patient identification data for the first and second patient correspond to the same individual.
At step 312, the identification module 128 creates a linking index for the individual represented by the identification data corresponding to the first patient. In certain example embodiments, a linking index can include one or more patient keys and one or more claims processor IDs. In some such example embodiments, the keys can be linked with the claims processor ID corresponding to the patient identification data upon which the key was computed. For example, in some example embodiments, if a key is computed from patient identification data provided by claims processor A to service provider computer 102, the linking index can link the key with the claims processor ID for claims processor A. In some example embodiments, a linking index can directly or indirectly include the claims processor IDs. For example, at step 312 the linking index can include a data structure with the key of the first patient in a row and the claims processor ID in the same row, in a column preceding or following the columns containing the key. In some example embodiments, the key can include the claims processor ID corresponding to the patient identification data upon which the key was computed. In some example embodiments, the linking index can include an individual longitudinal identifier, as described above. The individual longitudinal identifier can be used by aggregation module 130, as described below in the method 700, to identify linking indexes corresponding to an individual. In some example embodiments, identification module 128 or another portion of the service provider computer 102 can communicate the linking index to the database 108 and store the linking index therein. In some such embodiments, the linking index can be stored in the claims processor data files 110. Following creation of the linking index, the method continues to step 314, where an inquiry is conducted to determine if there are any other non-indexed patients in the patient identification data files 116. In one example embodiment, the determination is made by the identification module 128 or another portion of the service provider computer 102. For example, the identification module 128 can determine whether there are any other patients (i.e., patient identification data associated with the claims processor ID) in the patient identification data files 116 that are not indexed. If there are other patients that are not indexed, then the YES branch is followed and the method returns to step 302. If there are no other patients that are not indexed, then the NO branch is followed to the END step.
At step 318, the identification module 128 or another portion of the service provider computer 102 determines if the patient identification data for the second patient is indexed, as described above. In one example embodiment, the identification module 128 or another portion of the service provider computer 102 determines whether the second patient is indexed. If the second patient is not indexed, the NO branch is followed and the method continues to step 322. If the second patient is indexed, the YES branch is followed and the method continues to step 320. At step 320, the identification module 128 adds the key for the first patient to the linking index including the second patient's key (e.g., determines the patient identification data for the first and second patient correspond to the same individual). The method then proceeds to step 314, described above.
At step 322, the identification module 128 or another portion of the service provider computer 102 calculates a key for the second patient. In some example embodiments, the key fields have one or more key fields in common with the first patient's key. For example, the key fields can have one, more than one, or all key fields in common. In step 324, the identification module 128 creates a linking index that includes the first patient's key and the second patient's key. As described above, the linking index can include the claims processor patient identifiers for the first patient's key and the second patient's key. Also as described above, the linking index can also include an individual longitudinal identifier. In one example embodiment, the identification module 128 can store the linking index in the claims processor data files 110. Following creation of the linking index, the method continues to step 314, which is described in detail above.
At step 506, the identification module 128 or another portion of the service provider computer stores the identified patient identification data and patient medication history data and associates them. In some example embodiments, the identification module 128 stores the identified patient identification data in the pharmacy identification data files 120 and the identified patient medication history data in the pharmacy medication history data files 122 of the database 108. In one example, the pharmacy identification data files 120 and the pharmacy medication history data files 122 can be localized (i.e., the pharmacy identification data files and the pharmacy medication history data files from different pharmacies are stored separately for each pharmacy so that the data from different pharmacies is not commingled).
At step 508, the identification module 128 can compute a key from the received patient identification data, as described above in step 304 of
At step 512, the identification module 128 creates a linking index for the first patient (i.e., the identification module 128 has recognized the first patient as a unique individual with respect to the first pharmacy entity/pharmacy computer 104). In some example embodiments, the linking index can include one or more patient keys. For example, at step 312 the linking index can include the key of the first patient. In some such embodiments, a linking index can further include a pharmacy ID (e.g., NPI number, chain identifier, store number, etc.) associated with the pharmacy computer 104 from which the patient identification data was received by the identification module 128 and/or the service provider computer 102. The pharmacy ID can be an identifier, relative to the service provider computer 102, that uniquely identifies a pharmacy and/or a pharmacy store, as described further below. In one example embodiment, the identification module 128 can also generate a unique individual longitudinal identifier that uniquely identifies, relative to the service provider computer 102, the linking index (and the corresponding individual). The linking index can include or otherwise be associated with the individual longitudinal identifier. For example, the identification module 128 or another portion of the service provider computer 102 can use the unique individual longitudinal identifier to identify the linking index corresponding to an individual. The identification module 128 can communicate the linking index to the database 108 and store the linking index therein. For example, the linking index can be stored in with the pharmacy data files 112. The method then proceeds to the END step.
At step 516, the identification module 128 selects patient identification data for a second patient, distinct from the first patient. In some example embodiments, identification module 128 can randomly select patient identification from pharmacy data files 112. In other example embodiments, identification module 128 can sequentially access patient identification data records, skipping the patient identification data for the first patient. At step 518, the identification module 128 applies identification logic, described above with respect to
At step 522, the key calculated for the first patient is added to the linking index that includes the second patient's key. In certain example embodiments, the linking index that includes the second patient's key can include a individual longitudinal identifier as described above in step 312 of the method 300 and further below in method 700. In some such embodiments, the identification module 128 can associate the unique identifier with the patient identification data and/or patient medication history data for the first patient stored in the pharmacy data files 112. The method then proceeds to the END step.
At step 524, an inquiry is conducted to determine if the matching logic has been applied to all other patient identification data. In one example embodiment, the determination is made by the identification module 128 or another portion of the service provider computer 102, which determines if the matching logic has been applied between the patient identification data of the first patient and all other patients in the pharmacy data files 112. In one such exemplary embodiment, identification module 128 or another portion of the service provider computer 102 can sequentially access patient identification data records in patient identification data files 120 at step 516 and, at step 524, can determine if the end of patient identification data records has been reached. If matching logic has not been applied between the patient identification data of the first patient all other patients in the pharmacy data files 112, the YES branch is followed and the method proceeds to step 512. If so, the NO branch is followed and the method returns to step 516 to attempt to apply matching logic to the patient identification data files in the pharmacy data files 112 corresponding to another patient.
At step 704, the aggregation module 130 or another portion of the service provider computer 102 selects a linking index corresponding to the individual. In some example embodiments, the aggregation module 130 can receive, from claims processor computer 106, patient identification data corresponding to an individual along with receiving the individual's indication of consent. In some such exemplary embodiments, aggregation module 130 can compute a key from the patient identification data, for example, as described above at step 304 in the method 300. Aggregation module 130 or another portion of the service provider computer 102 can parse the linking indexes stored in claims processor data file 110 and identify a linking index having a matching key and a claims processor ID associated with one of the claims processors in the selected set of claims processors. One example embodiment of a claims processor linking index is shown in
At step 716, the aggregation module 130 can access the pharmacy data files 112 in the database 108 to find key indexes having keys matching the key computed in step 704 and a pharmacy ID associated with the selected pharmacy and/or pharmacy store. In one example embodiment, the matching can include determining if the selected key is identical to one or more keys identified in the pharmacy data files 112. For example, referring to
In step 718, an inquiry is conducted to determine if a matching key was identified. In one example embodiment, the determination can be made by the aggregation module 130 or another portion of the service provider computer 102. If a matching key was identified, the YES branch is followed to step 720. Otherwise, the NO branch is followed to step 722. At step 720, the aggregation module 130 or another portion of the service provider computer 102 selects the individual longitudinal identifier linked with the pharmacy linking index comprising the matching key. Returning to the previous example, and referring to
At step 724, an inquiry is conducted to determine if there are any additional claims processor IDs in the selected claims processor linking index. In certain example embodiments, the determination is made by the aggregation module 130 or another portion of the service provider computer 102. In one example embodiment, the aggregation module 130 determines if there are additional claims processor IDs by parsing the linking index selected at step 704. If there are claims processor IDs, the YES branch is followed and the method returns to step 708. On the other hand, if there are no additional claims processor IDs in the selected claims processor linking index, then the NO branch is followed to the END step. In certain example embodiments, the service provider computer 102 can send the retrieved data to the pharmacy computer 104, the claims processor computer 106, and/or a third-party computer. In some example embodiments, service provider computer can perform post-processing on the patient medication history data following agglomeration, for example, as describe in method 700. For example, the agglomerated data can be de-duped (e.g., a duplicate medication history data can be removed).
While method 700 describes agglomeration of patient medication history data across a plurality of claims processors and a single pharmacy, a person of ordinary skill in the art will be able to agglomerate patient medication history over any combination of one or more pharmacy stores, one or more pharmacies and/or one or more claims processors, based upon the teachings herein. For example, identification module 128 can create a distinct linking index for each individual over each claims processor/claims processor computer 106, over each pharmacy/pharmacy computer 104, and/or over each pharmacy store/pharmacy computer 104 corresponding to a pharmacy, as exemplified in
In some example embodiments, service provider computer can chronologically arrange the agglomerated patient medication history data (e.g., resulting from method 700) to generate the individual's longitudinal medication history. In some embodiments, generation of the longitudinal medication history can be based at least in part on date of service data included in each patient medication history record, as described above. In some such embodiments, the agglomerated patient medication history can be stored in data files 140 and indexed and/or arranged over a time period from most recent date of service to least recent date of service or from least recent date of service to most recent date of service.
Various block and/or flow diagrams of systems, methods, apparatus, and/or computer program products according to example embodiments of the disclosure are described above. It will be understood that one or more blocks of the block diagrams and steps of the flow diagrams, and combinations of blocks in the block diagrams and combinations of steps in the flow diagrams, respectively, can be implemented by computer-executable program instructions. Likewise, some blocks of the block diagrams and steps of the 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.
These computer-executable program instructions may be loaded onto a special-purpose computer or other particular machine, one or more processors, 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 flow diagram step or steps. 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 step or steps. As an example, various embodiments of the disclosure may provide for a computer program product including 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 step or steps. 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 step or steps.
Accordingly, blocks of the block diagrams and steps of the 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 step of the flow diagrams, and combinations of blocks in the block diagrams and steps of the 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 disclosure 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 |
| 5465286 | Clare et al. | Nov 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, Jr. 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 |
| 6427020 | Rhoads | Jun 2002 | B1 |
| 6424949 | Deaton et al. | 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 |
| 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 |
| 7046789 | Anderson et al. | May 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 |
| 8538777 | Kaye | Sep 2013 | B1 |
| 8731966 | Breitenstein | May 2014 | B2 |
| 8788287 | Padate | Jul 2014 | B2 |
| 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 |
| 20020035484 | McCormick | 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 |
| 20020073099 | Gilbert | Jun 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 |
| 20020175929 | Hunt et al. | 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 |
| 20030158755 | Neuman | 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 |
| 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 |
| 20040188998 | Henthom | 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, III 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 |
| 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, Jr. et al. | Oct 2005 | A1 |
| 20050246205 | Wang | Nov 2005 | A1 |
| 20050256740 | Kohan | Nov 2005 | A1 |
| 20050288972 | Marvin et al. | Dec 2005 | A1 |
| 20060015518 | Eletreby et al. | Jan 2006 | A1 |
| 20060020514 | Yered | Jan 2006 | A1 |
| 20060026041 | Ullman | 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 |
| 20060178915 | Chao | Aug 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 et al. | 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 |
| 20070067186 | Brenner et al. | Mar 2007 | A1 |
| 20070088576 | de Beus et al. | Apr 2007 | A1 |
| 20070124177 | Engleson et al. | May 2007 | A1 |
| 20070136100 | Daugherty et al. | Jun 2007 | A1 |
| 20070162303 | Wiley et al. | Jul 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 |
| 20080147554 | Stevens | Jun 2008 | A1 |
| 20100122202 | Omiya | May 2010 | A1 |
| 20110060757 | Dettinger | Mar 2011 | A1 |
| 20110125528 | Padate | May 2011 | A1 |
| 20130218599 | Highley | Aug 2013 | A1 |
| 20140039929 | Vdovjak | Feb 2014 | A1 |
| 20140100880 | Patterson | Apr 2014 | A1 |
| 20150149208 | Lynch | May 2015 | A1 |
| 20150278482 | Mattera | Oct 2015 | A1 |
| Number | Date | Country |
|---|---|---|
| 2482370 | Mar 2006 | CA |
| 1310895 | Nov 2002 | EP |
| 1991006917 | May 1991 | WO |
| 1995003569 | Feb 1995 | WO |
| 1997025682 | Jul 1997 | WO |
| 1998050871 | Nov 1998 | WO |
| 2000039737 | 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, vol. 84, Issue 7, USA; Abstract only. |
| 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, vol. 63, Issue 1, USA; Abstract only. |
| 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. |
| Hutty, S. Third party issues: Understanding drug benefits for better patient care. Pharmacy Practice, 18(6), CE1-CE16, Retrieved from http://search.proquest.com/docview/232078749?accountid=14753. |
| Nonfinal Office Action for U.S. Appl. No. 12/165,031 dated Nov. 23, 2010. |
| Final Office Action for U.S. Appl. No. 12/165,031, dated Apr. 13, 2011. |
| Non-Final Office Action for U.S. Appl. No. 13/181,082 dated Feb. 20, 2013. |
| Notice of Allowance for U.S. Appl. No. 12/165,031 dated May 15, 2013. |
| Final Office Action for U.S. Appl. No. 13/181,082 dated Jul. 24, 2013. |
| Non-Final Office Action for U.S. Appl. No. 14/010,167 dated Jun. 9, 2014. |
| Letter Restarting Period for Response for U.S. Appl. No. 14/010,167 dated Jul. 10, 2014. |
| Final Office Action for U.S. Appl. No. 14/010,167 dated Feb. 26, 2015. |
| Non-final Office Action for U.S. Appl. No. 14/010,167 dated Sep. 4, 2015. |
