CA2476918A1 - Method and system to track customer purchases - Google Patents
Method and system to track customer purchases Download PDFInfo
- Publication number
- CA2476918A1 CA2476918A1 CA002476918A CA2476918A CA2476918A1 CA 2476918 A1 CA2476918 A1 CA 2476918A1 CA 002476918 A CA002476918 A CA 002476918A CA 2476918 A CA2476918 A CA 2476918A CA 2476918 A1 CA2476918 A1 CA 2476918A1
- Authority
- CA
- Canada
- Prior art keywords
- pharmaceutical
- patient
- information
- benefit manager
- outlet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
- G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
Abstract
A system and method for identifying transactions relating to a single custom er in a data set received from a plurality of outlets (402), such that one patient's (404) pharmaceutical prescription data may be linked (406) to represent the entire pharmaceutical purchases of said patient is disclosed (414).
Description
METHOD AND SYSTEM TO TRACK CUSTOMER PURCHASES
CROSS-REFERENCE TO RELATED APPLICATION
This application is related to U.S. Provisional Patent Application 601358,866, filed on February 21, 2002, from which priority is claimed.
FIELD OF THE INVENTION
The present invention is directed to techniques for identifying transactions relating to a single individual customer in a data set of compiled prescription data, relating to pharmaceutical prescription (sales) transactions, from a plurality of data sources.
BACKGROUND INFORMATION
The pharmaceutical industry is one of the largest income generating industries in the world. As revenue in this industry has steadily increased, it has become increasingly important to track the prescribing habits of individual physicians.
Currently, pharmaceutical outlets ("outlets") record and store data pertaining to each pharmaceutical purchase by patients at such outlets. Outlets are more commonly known as drugstores or pharmacies. When a patient purchases pharmaceuticals from an outlet, the outlet collects data such as the patient's name, the pharmaceutical item dispensed ("Rx #"), the transaction date, the physician who prescribed the prescription ("Dr. #"), and other miscellaneous information.
As this transaction information is recorded in the outlet's database, the outlet typically assigns each patient an identification code ("outlet identifier").
An outlet identifier is used such that a patient's name can remain anonymous when such information is transmitted outside of the outlet. Since each outlet may be a drugstore, pharmacy, or chain thereof, outlet identifiers are not the same across multiple outlets. Further, where an outlet is a chain of drugstores, an outlet identifier may not even be the same across different stores of that same chain.
For example, if one outlet is pharmacy "ABC", a regular consumer/patient John Doe may have an outlet identifier "OOA" at pharmacy ABC. If John Doe then gets a pharmaceutical filled from drugstore XYZ, fohn Doe will general get a different outlet identifier, "001" for example, at pharmacy XYZ. Thus, even though John Doe is only one individual patient, if prescription data from both pharmacies are received by a central source, John Doe's records appear as that of two different patients because of the unlike identifiers across different outlets. Thus, based upon the currently available data it is very difficult to map and/or track the pharmaceutical prescriptions written for John Doe or by Joe Doe's physician because John Doe's records appear as two (2) different patients across multiple outlets.
Pharmaceutical benefit managers ("PBM") are another group in the pharmaceutical industry that collect data. In particular, PBMs collect data that pertain to pharmaceutical sales that get resolved through insurance plans. For example, if a patient John Doe has a particular health insurance, "MNO" health insurance, and John Doe wishes to use his benefits under MNO to pay for all or part of his pharmaceutical purchase, data will then pass from the dispensing outlet to one or more PBMs of such transaction, as the transaction is cleared with the insurance company.
PBM data is similar to the outlet prescription data described above. PBM data typically includes an outlet identifier, Rx #, the transaction date, Dr. #, other miscellaneous information, and a patient identifier given by the pharmaceutical benefit manager. Although the pharmaceutical benefit manager can identify patients across a plurality of outlets, because patients are identified by a health insurance plan and an unique identifier for that health insurance (not outlet identifiers as described above), a PBM cannot track cash transactions, or transactions related to insurance plans not serviced by that PBM. Thus, the PBM also cannot provide an accurate depiction of a physician's dispensing habits.
What is needed is an efficient and effective way to track a patient's pharmaceutical prescriptions (sales) across a period of time and across outlets where all prescription information related to a unique patient can be linked regardless of the data source for the information.
_2_ SUMMARY OF THE INVENTION
An object of the present invention is to provide a technique for identifying tra~.lsactions pertaining to an individual in a data set of compiled patient pharmaceutical prescription data from a plurality of outlets, so that one patient's pharmaceutical prescription data may be linked across time to represent the entire pharmaceutical purchases of the patient so as to track the prescribing doctor's prescribing habits.
In order to aclueve this objective, as well as others which will become apparent in the disclosure below, the present invention provides techniques for receiving patient pharmaceutical prescription data ("prescription data") from a plurality of outlets and from one or more PBMs, and linking prescription data records ("record") pertaining to an individual across data sources to provide a clear view of a patient's pharmaceutical purchases and physician prescribing patterns.
In a preferred embodiment, prescription data is received from a plurality of data sources. Such prescription data contains patient identifiers marked by its originating data source in accordance with that data source's own identification scheme.
All records are stored in a general storage area. In addition, each unique patient identifier is also stored in a data relation table. Further, each unique patient identifier in the table is assigned an internal identifier.
Next, as will be further described below, all records in the storage area are checked by a triangulation engine which, by keying in on the Rx #, outlet number, transaction date, and Dr. #, compares records in the storage area with reference data received from one or more PBMs for similarities. In particular, if the above attributes of a prescription sales record in the storage axea match a record of reference data from a PBM, the table is updated such that the patient identifier, for the matched record, is associated with a matched PBM identifier to reflect a bridge between the patient identifier of the record and the associated PBM identifier.
In a preferred embodiment, the table is then checked to ensure that each unique PBM identifier is cross-referenced to only one internal identifier in the table, and updates the table accordingly. Thus, by querying on the internal identifier, a patient's pharmaceutical history can be tracked by keying in on only one identifier, regardless of the origins of such data.
Advantageously, the data in the storage area is then made available for tracking prescriptions relating to a unique individual across the value chain.
This linking methodology allows for better prescription analysis by providing the ability to link prescription data longitudinally across data sources.
BRIEF DESCRIPTION OF THE DRAWINGS
For a complete understanding of the present invention and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings in which like reference numbers indicate like features, components and method steps, and wherein:
FIG. 1 is a functional diagram of an exemplary system of the present invention;
FIG. 2 is an illustrative diagram of exemplary fields in each record of information transmitted from the outlets to the system of the present invention;
FIG. 3 is an illustrative diagram of exemplary fields transmitted from the pharmacy benefit managers to the system of the present system;
FIG. 4 is a flow diagram showing the basic process flow for identifying transactions related to a single customer in data set received from multiple outlets in accordance with the present invention;
FIG. 5 is a chart illustrating an example of the cross-referencing of records performed by the present invention;
FIG. 6(a) is a representative illustration of a table of the present invention before bridging is performed by the triangulation engine; and FIG. 6(b) is a representative illustration of a table of the present invention after bridging is performed by the triangulation engine.
DESCRIPTION OF A PRESENTLY PREFERRED EMBODIMENT
Refernng to FIG. 1, in a preferred embodiment the present system 100 includes a plurality of outlets 102, 104 which are coupled to an identification assignor ("ID
assignor") 106. The ID assignor 106 is in turn coupled to a resultant database 108. The present system 100 also includes one or more PBMs 112, 114. PBMs 112, 114 are coupled to triangulation engine 110. Triangulation engine 110 is coupled to the database 108 such to exchange and receive data therewith.
The triangular engine 110 and ID assignor 106 may be personal computers, networked computers or computer servers, or mainframe devices. Similarly, database 108 may be a relational database, where links and relations can be formed between uncommon fields across multiple records, such as Oracle(TM) or Sybase(TM), residing on a hard drive or magneto-optical device on a personal computer, networked computer or computer server, or mainframe device. ID assignor 106, triangulation engine 110, and database 108 may communicate and exchange data on a plurality of computer networks known in the art, including operating under protocols such as the Transmission Control Protocol/Internet Protocol ("TCP/IP").
Referring next to FIG. 2, using outlet 102 as a representative example of outlets, outlet 102 transmits prescription data records to ID assignor 106 pertaining to pharmaceutical prescriptions (sales) to patients from outlet 102. The records may contain a variety of fields, preferably, the outlet number, outlet patient ID, Rx #, the transaction date, and Dr. # (which is the prescribing physician as described above). Preferably all outlets sending records to ID assignor 106 have records in similar formats.
Referring to FIG. 3, FIG. 3 shows exemplary fields transmitted by one or more PBMs to the triangular engine 110. Each record a PBM transmits to the triangulation engine preferably includes the PBM patient ID number, Rx #, outlet number, transaction date, and Dr. #.
Referring to FIG. 4, in an exemplary embodiment, in operation ID assignor 106 receives records from outlets 102, 104 iri step 4b2. Since different outlets, or chains of outlets, use different patient identifier schemes, once ID assignor 106 receives records from outlets 102, 104, ID assignor 106 places each unique outlet patient ID in a table residing in database 108, and assigns each outlet patient ID in the table with an internal ID in step 404.
In this way all outlet patient IDs held have a common patient identification scheme once received by the present system. ID assignor 106 may comprise a network computer server, personal computer, or mainframe, for example, for receiving the records from the outlets 102, 104.
After ID assignor 106 assigns an internal ID to each unique outlet patient ID
in the table in database 108, ID assignor 106 then updates a records storage area of database 108 with the new records received in step 402, in step 406.
Next, triangulation engine 110 receives PBM data from one or more PBMs 112, 114 in step 408. Once received, the triangulation engine 110 takes the PBM data received, and queries the records storage area of database 108 record-by-record trying to cross-reference the fields in the PBM data with records in the records storage area of database 108 to determine prescription transactions which are the same, in step 410. Based upon such determination, the triangulation engine 110 then updates the table in database 108 to reflect where an outlet patient ID maps to a PBM ID, in step 412. Lastly, the triangulation engine maps each unique PBM ID to only one internal ID to be used in subsequent queries, in step 414. Similar to ID assignor 106, the triangulation engine 110 may comprise a network computer server, personal computer, or mainframe, for example, for receiving the PBM data.
Refernng to FIG. 5 as an illustrative example, triangular engine 110 may receive PBM data 502, 504. The records storage area of database 108 may contain the three (3) records illustrated in data set 506 received from outlet records passed through ID assignor 106. The three transactions are in actuality from one patient, where such patient filled "H2WXY" at outlet 102 using his health insurance plan, filled "H6WAB" at outlet 104 using his health insurance plan, and filled "HBXWZ" at outlet 102 paying for the prescription in cash.
Taking these records for purposes of this illustrative example, prior to being passed to the records storage area of database 108, the ID assignor 106 populated the table in database 106 with the outlet patient IDs in 506, and assigned internal IDs for each, as illustrated in FIG. 6(a). As analyzed by the triangulation engine 110, the first transaction with outlet patient ID 7102 is linked to PBM data 502 with a PBM ID of "1023,"
because, as is clear, all other fields match. Similarly, the second transaction with outlet patient ID 522 is linked to PBM data 504 also with PBM ID "1023". Since the third transaction is also for outlet patient ID 7102, it is also linked to PBM ID "1023".
These values are updated and stored in the table in database 108, and upon updating the table with the PBM IDs, the triangulation engine 110 ensures that each unique PBM ID has only one corresponding internal ID. This is illustrated in FIG.
6(b), which is the table, in this example, after linking. In this way, by querying on the internal ID, all of one patient prescription transacitons will be revealed.
The above system and method may be implemented by many computer languages commonly known in the art and may operate on many computer platforms which include both volatile and non-volatile memory storage devices. In a preferred embodiment, the system and method of the present invention is implemented, in whole or in part, on a mainframe, or UNIX based system using Oracle, SQL, and SAS. Software code encapsulating the functionality of the present inventive technique may be implemented on such computer systems, preferably written in Oracle PL*SQL, C, C++, or any other commonly known programming language.
Although the invention has been described herein by reference to an exemplary embodiment thereof, it will be understood that such embodiment is susceptible of modification and variation without departing from the inventive concepts disclosed. For example, the prescription data records received from the outlets could be used as the reference data and the information received from the PBMs could be the data which resides in database 108 for augmentation by the triangulation engine 110. Further, other types of _7_ data and other data formats than that represented in FIGs. 2 and 3 may be utilized in the present system and method. All such modifications~and variations, therefore, are intended to be encompassed within the spirit and scope of the appended claims.
_g_
CROSS-REFERENCE TO RELATED APPLICATION
This application is related to U.S. Provisional Patent Application 601358,866, filed on February 21, 2002, from which priority is claimed.
FIELD OF THE INVENTION
The present invention is directed to techniques for identifying transactions relating to a single individual customer in a data set of compiled prescription data, relating to pharmaceutical prescription (sales) transactions, from a plurality of data sources.
BACKGROUND INFORMATION
The pharmaceutical industry is one of the largest income generating industries in the world. As revenue in this industry has steadily increased, it has become increasingly important to track the prescribing habits of individual physicians.
Currently, pharmaceutical outlets ("outlets") record and store data pertaining to each pharmaceutical purchase by patients at such outlets. Outlets are more commonly known as drugstores or pharmacies. When a patient purchases pharmaceuticals from an outlet, the outlet collects data such as the patient's name, the pharmaceutical item dispensed ("Rx #"), the transaction date, the physician who prescribed the prescription ("Dr. #"), and other miscellaneous information.
As this transaction information is recorded in the outlet's database, the outlet typically assigns each patient an identification code ("outlet identifier").
An outlet identifier is used such that a patient's name can remain anonymous when such information is transmitted outside of the outlet. Since each outlet may be a drugstore, pharmacy, or chain thereof, outlet identifiers are not the same across multiple outlets. Further, where an outlet is a chain of drugstores, an outlet identifier may not even be the same across different stores of that same chain.
For example, if one outlet is pharmacy "ABC", a regular consumer/patient John Doe may have an outlet identifier "OOA" at pharmacy ABC. If John Doe then gets a pharmaceutical filled from drugstore XYZ, fohn Doe will general get a different outlet identifier, "001" for example, at pharmacy XYZ. Thus, even though John Doe is only one individual patient, if prescription data from both pharmacies are received by a central source, John Doe's records appear as that of two different patients because of the unlike identifiers across different outlets. Thus, based upon the currently available data it is very difficult to map and/or track the pharmaceutical prescriptions written for John Doe or by Joe Doe's physician because John Doe's records appear as two (2) different patients across multiple outlets.
Pharmaceutical benefit managers ("PBM") are another group in the pharmaceutical industry that collect data. In particular, PBMs collect data that pertain to pharmaceutical sales that get resolved through insurance plans. For example, if a patient John Doe has a particular health insurance, "MNO" health insurance, and John Doe wishes to use his benefits under MNO to pay for all or part of his pharmaceutical purchase, data will then pass from the dispensing outlet to one or more PBMs of such transaction, as the transaction is cleared with the insurance company.
PBM data is similar to the outlet prescription data described above. PBM data typically includes an outlet identifier, Rx #, the transaction date, Dr. #, other miscellaneous information, and a patient identifier given by the pharmaceutical benefit manager. Although the pharmaceutical benefit manager can identify patients across a plurality of outlets, because patients are identified by a health insurance plan and an unique identifier for that health insurance (not outlet identifiers as described above), a PBM cannot track cash transactions, or transactions related to insurance plans not serviced by that PBM. Thus, the PBM also cannot provide an accurate depiction of a physician's dispensing habits.
What is needed is an efficient and effective way to track a patient's pharmaceutical prescriptions (sales) across a period of time and across outlets where all prescription information related to a unique patient can be linked regardless of the data source for the information.
_2_ SUMMARY OF THE INVENTION
An object of the present invention is to provide a technique for identifying tra~.lsactions pertaining to an individual in a data set of compiled patient pharmaceutical prescription data from a plurality of outlets, so that one patient's pharmaceutical prescription data may be linked across time to represent the entire pharmaceutical purchases of the patient so as to track the prescribing doctor's prescribing habits.
In order to aclueve this objective, as well as others which will become apparent in the disclosure below, the present invention provides techniques for receiving patient pharmaceutical prescription data ("prescription data") from a plurality of outlets and from one or more PBMs, and linking prescription data records ("record") pertaining to an individual across data sources to provide a clear view of a patient's pharmaceutical purchases and physician prescribing patterns.
In a preferred embodiment, prescription data is received from a plurality of data sources. Such prescription data contains patient identifiers marked by its originating data source in accordance with that data source's own identification scheme.
All records are stored in a general storage area. In addition, each unique patient identifier is also stored in a data relation table. Further, each unique patient identifier in the table is assigned an internal identifier.
Next, as will be further described below, all records in the storage area are checked by a triangulation engine which, by keying in on the Rx #, outlet number, transaction date, and Dr. #, compares records in the storage area with reference data received from one or more PBMs for similarities. In particular, if the above attributes of a prescription sales record in the storage axea match a record of reference data from a PBM, the table is updated such that the patient identifier, for the matched record, is associated with a matched PBM identifier to reflect a bridge between the patient identifier of the record and the associated PBM identifier.
In a preferred embodiment, the table is then checked to ensure that each unique PBM identifier is cross-referenced to only one internal identifier in the table, and updates the table accordingly. Thus, by querying on the internal identifier, a patient's pharmaceutical history can be tracked by keying in on only one identifier, regardless of the origins of such data.
Advantageously, the data in the storage area is then made available for tracking prescriptions relating to a unique individual across the value chain.
This linking methodology allows for better prescription analysis by providing the ability to link prescription data longitudinally across data sources.
BRIEF DESCRIPTION OF THE DRAWINGS
For a complete understanding of the present invention and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings in which like reference numbers indicate like features, components and method steps, and wherein:
FIG. 1 is a functional diagram of an exemplary system of the present invention;
FIG. 2 is an illustrative diagram of exemplary fields in each record of information transmitted from the outlets to the system of the present invention;
FIG. 3 is an illustrative diagram of exemplary fields transmitted from the pharmacy benefit managers to the system of the present system;
FIG. 4 is a flow diagram showing the basic process flow for identifying transactions related to a single customer in data set received from multiple outlets in accordance with the present invention;
FIG. 5 is a chart illustrating an example of the cross-referencing of records performed by the present invention;
FIG. 6(a) is a representative illustration of a table of the present invention before bridging is performed by the triangulation engine; and FIG. 6(b) is a representative illustration of a table of the present invention after bridging is performed by the triangulation engine.
DESCRIPTION OF A PRESENTLY PREFERRED EMBODIMENT
Refernng to FIG. 1, in a preferred embodiment the present system 100 includes a plurality of outlets 102, 104 which are coupled to an identification assignor ("ID
assignor") 106. The ID assignor 106 is in turn coupled to a resultant database 108. The present system 100 also includes one or more PBMs 112, 114. PBMs 112, 114 are coupled to triangulation engine 110. Triangulation engine 110 is coupled to the database 108 such to exchange and receive data therewith.
The triangular engine 110 and ID assignor 106 may be personal computers, networked computers or computer servers, or mainframe devices. Similarly, database 108 may be a relational database, where links and relations can be formed between uncommon fields across multiple records, such as Oracle(TM) or Sybase(TM), residing on a hard drive or magneto-optical device on a personal computer, networked computer or computer server, or mainframe device. ID assignor 106, triangulation engine 110, and database 108 may communicate and exchange data on a plurality of computer networks known in the art, including operating under protocols such as the Transmission Control Protocol/Internet Protocol ("TCP/IP").
Referring next to FIG. 2, using outlet 102 as a representative example of outlets, outlet 102 transmits prescription data records to ID assignor 106 pertaining to pharmaceutical prescriptions (sales) to patients from outlet 102. The records may contain a variety of fields, preferably, the outlet number, outlet patient ID, Rx #, the transaction date, and Dr. # (which is the prescribing physician as described above). Preferably all outlets sending records to ID assignor 106 have records in similar formats.
Referring to FIG. 3, FIG. 3 shows exemplary fields transmitted by one or more PBMs to the triangular engine 110. Each record a PBM transmits to the triangulation engine preferably includes the PBM patient ID number, Rx #, outlet number, transaction date, and Dr. #.
Referring to FIG. 4, in an exemplary embodiment, in operation ID assignor 106 receives records from outlets 102, 104 iri step 4b2. Since different outlets, or chains of outlets, use different patient identifier schemes, once ID assignor 106 receives records from outlets 102, 104, ID assignor 106 places each unique outlet patient ID in a table residing in database 108, and assigns each outlet patient ID in the table with an internal ID in step 404.
In this way all outlet patient IDs held have a common patient identification scheme once received by the present system. ID assignor 106 may comprise a network computer server, personal computer, or mainframe, for example, for receiving the records from the outlets 102, 104.
After ID assignor 106 assigns an internal ID to each unique outlet patient ID
in the table in database 108, ID assignor 106 then updates a records storage area of database 108 with the new records received in step 402, in step 406.
Next, triangulation engine 110 receives PBM data from one or more PBMs 112, 114 in step 408. Once received, the triangulation engine 110 takes the PBM data received, and queries the records storage area of database 108 record-by-record trying to cross-reference the fields in the PBM data with records in the records storage area of database 108 to determine prescription transactions which are the same, in step 410. Based upon such determination, the triangulation engine 110 then updates the table in database 108 to reflect where an outlet patient ID maps to a PBM ID, in step 412. Lastly, the triangulation engine maps each unique PBM ID to only one internal ID to be used in subsequent queries, in step 414. Similar to ID assignor 106, the triangulation engine 110 may comprise a network computer server, personal computer, or mainframe, for example, for receiving the PBM data.
Refernng to FIG. 5 as an illustrative example, triangular engine 110 may receive PBM data 502, 504. The records storage area of database 108 may contain the three (3) records illustrated in data set 506 received from outlet records passed through ID assignor 106. The three transactions are in actuality from one patient, where such patient filled "H2WXY" at outlet 102 using his health insurance plan, filled "H6WAB" at outlet 104 using his health insurance plan, and filled "HBXWZ" at outlet 102 paying for the prescription in cash.
Taking these records for purposes of this illustrative example, prior to being passed to the records storage area of database 108, the ID assignor 106 populated the table in database 106 with the outlet patient IDs in 506, and assigned internal IDs for each, as illustrated in FIG. 6(a). As analyzed by the triangulation engine 110, the first transaction with outlet patient ID 7102 is linked to PBM data 502 with a PBM ID of "1023,"
because, as is clear, all other fields match. Similarly, the second transaction with outlet patient ID 522 is linked to PBM data 504 also with PBM ID "1023". Since the third transaction is also for outlet patient ID 7102, it is also linked to PBM ID "1023".
These values are updated and stored in the table in database 108, and upon updating the table with the PBM IDs, the triangulation engine 110 ensures that each unique PBM ID has only one corresponding internal ID. This is illustrated in FIG.
6(b), which is the table, in this example, after linking. In this way, by querying on the internal ID, all of one patient prescription transacitons will be revealed.
The above system and method may be implemented by many computer languages commonly known in the art and may operate on many computer platforms which include both volatile and non-volatile memory storage devices. In a preferred embodiment, the system and method of the present invention is implemented, in whole or in part, on a mainframe, or UNIX based system using Oracle, SQL, and SAS. Software code encapsulating the functionality of the present inventive technique may be implemented on such computer systems, preferably written in Oracle PL*SQL, C, C++, or any other commonly known programming language.
Although the invention has been described herein by reference to an exemplary embodiment thereof, it will be understood that such embodiment is susceptible of modification and variation without departing from the inventive concepts disclosed. For example, the prescription data records received from the outlets could be used as the reference data and the information received from the PBMs could be the data which resides in database 108 for augmentation by the triangulation engine 110. Further, other types of _7_ data and other data formats than that represented in FIGs. 2 and 3 may be utilized in the present system and method. All such modifications~and variations, therefore, are intended to be encompassed within the spirit and scope of the appended claims.
_g_
Claims (11)
1. A system for identifying transactions related to a single customer in a data set received from multiple pharmaceutical outlets, comprising:
one or more inputs for receiving patient pharmaceutical prescription information from a plurality of pharmaceutical outlets, said patient pharmaceutical prescription information including information identifying one or more patients and a unique outlet patient identifier for each of said pharmaceutical prescription patients, and for receiving pharmaceutical benefit manager information from one or more pharmaceutical benefit managers, said pharmaceutical benefit manager information including information identifying one or more patients and a unique pharmaceutical benefit manager identifier for each of said pharmaceutical benefit manager patients;
an identification assignor, coupled to said one or more inputs and receiving said patient pharmaceutical prescription information therefrom, for providing an internal patient identifier for each of said outlet patient identifiers in said patient pharmaceutical prescription information;
a triangulation engine, coupled to said one or more inputs for receiving said pharmaceutical benefit manager information and said patient pharmaceutical prescription information therefrom, for comparing said pharmaceutical benefit manager information to said patient pharmaceutical prescription information; and a storage device, coupled to said identification assignor and receiving said patient pharmaceutical prescription information, said outlet patient identifiers and associated internal patient identifiers therefrom, and coupled to a triangulation engine for receiving pharmaceutical benefit manager identifiers therefrom, and maintaining a table for linking said outlet patient identifiers, said internal identifiers and said pharmaceutical benefit manager identifiers.
one or more inputs for receiving patient pharmaceutical prescription information from a plurality of pharmaceutical outlets, said patient pharmaceutical prescription information including information identifying one or more patients and a unique outlet patient identifier for each of said pharmaceutical prescription patients, and for receiving pharmaceutical benefit manager information from one or more pharmaceutical benefit managers, said pharmaceutical benefit manager information including information identifying one or more patients and a unique pharmaceutical benefit manager identifier for each of said pharmaceutical benefit manager patients;
an identification assignor, coupled to said one or more inputs and receiving said patient pharmaceutical prescription information therefrom, for providing an internal patient identifier for each of said outlet patient identifiers in said patient pharmaceutical prescription information;
a triangulation engine, coupled to said one or more inputs for receiving said pharmaceutical benefit manager information and said patient pharmaceutical prescription information therefrom, for comparing said pharmaceutical benefit manager information to said patient pharmaceutical prescription information; and a storage device, coupled to said identification assignor and receiving said patient pharmaceutical prescription information, said outlet patient identifiers and associated internal patient identifiers therefrom, and coupled to a triangulation engine for receiving pharmaceutical benefit manager identifiers therefrom, and maintaining a table for linking said outlet patient identifiers, said internal identifiers and said pharmaceutical benefit manager identifiers.
2. The system of claim 1, further comprising a second storage device, coupled to said triangulation engine, for storing said table.
3. The system of claim 1, where said storage device comprises a hard disk drive.
4. The system of claim 1, where said storage device comprises a magneto-optical disc.
5. The system of claim 1, where said storage device comprises a relational database.
6. The system of claim 1, where said one or more inputs comprise a network computer server.
7. The system of claim 1, where said one or more inputs comprise a personal computer.
8. The system of claim 1, where said one or more inputs comprise a mainframe computer.
9. A method for identifying transactions related to a single customer in a data set received from multiple pharmaceutical outlets, comprising the steps of:
receiving patient pharmaceutical prescription information from a plurality of pharmaceutical outlets, said patient pharmaceutical prescription information including information identifying one or more patients and a unique outlet patient identifier for each of said pharmaceutical prescription patients;
receiving pharmaceutical benefit manager information from one or more pharmaceutical benefit managers, said pharmaceutical benefit manager information including information identifying one or more patients and a unique pharmaceutical benefit manager identifier for each of said pharmaceutical benefit manager patients;
assigning an internal patient identifier for each of said outlet patient identifiers in said received patient pharmaceutical prescription information;
storing said internal patient identifier and associated outlet patient identifier in a table;
storing said pharmaceutical prescription information in a storage area;
comparing said patient pharmaceutical prescription information with said pharmaceutical benefit manager information to determine matches in transactions, to define links between said outlet patient identifiers and said pharmaceutical benefit manager identifiers;
updating said table to reflect links between said outlet patient identifiers and said pharmaceutical benefit manager identifiers; and modifying said table such that each unique pharmaceutical benefit manager identifier is linked to only one internal identifier.
receiving patient pharmaceutical prescription information from a plurality of pharmaceutical outlets, said patient pharmaceutical prescription information including information identifying one or more patients and a unique outlet patient identifier for each of said pharmaceutical prescription patients;
receiving pharmaceutical benefit manager information from one or more pharmaceutical benefit managers, said pharmaceutical benefit manager information including information identifying one or more patients and a unique pharmaceutical benefit manager identifier for each of said pharmaceutical benefit manager patients;
assigning an internal patient identifier for each of said outlet patient identifiers in said received patient pharmaceutical prescription information;
storing said internal patient identifier and associated outlet patient identifier in a table;
storing said pharmaceutical prescription information in a storage area;
comparing said patient pharmaceutical prescription information with said pharmaceutical benefit manager information to determine matches in transactions, to define links between said outlet patient identifiers and said pharmaceutical benefit manager identifiers;
updating said table to reflect links between said outlet patient identifiers and said pharmaceutical benefit manager identifiers; and modifying said table such that each unique pharmaceutical benefit manager identifier is linked to only one internal identifier.
10. The method of claim 9, wherein said step of receiving patient pharmaceutical prescription information from a plurality of pharmaceutical outlets comprises receiving said patient pharmaceutical prescription information over a computer network.
11. The method of claim 9, where said step of receiving pharmaceutical benefit manager information from one or more pharmaceutical benefit managers comprises receiving said pharmaceutical benefit manager information over a computer network.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US35886602P | 2002-02-21 | 2002-02-21 | |
| US60/358,866 | 2002-02-21 | ||
| PCT/US2003/005231 WO2003073346A1 (en) | 2002-02-21 | 2003-02-21 | Method and system to track customer purchases |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2476918A1 true CA2476918A1 (en) | 2003-09-04 |
| CA2476918C CA2476918C (en) | 2015-06-30 |
Family
ID=27766007
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2476918A Expired - Lifetime CA2476918C (en) | 2002-02-21 | 2003-02-21 | Method and system to track customer purchases |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US8095385B2 (en) |
| AU (1) | AU2003213178A1 (en) |
| CA (1) | CA2476918C (en) |
| WO (1) | WO2003073346A1 (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10078824B2 (en) * | 2010-11-30 | 2018-09-18 | Ncr Corporation | Platform and method for integrating services in a terminal or kiosk |
| US10366462B1 (en) * | 2012-03-26 | 2019-07-30 | Express Scripts Strategic Development, Inc. | Drug interaction review methods and systems |
| US8725532B1 (en) | 2012-06-29 | 2014-05-13 | Mckesson Financial Holdings | Systems and methods for monitoring controlled substance distribution |
| US10430555B1 (en) | 2014-03-13 | 2019-10-01 | Mckesson Corporation | Systems and methods for determining and communicating information to a pharmacy indicating patient eligibility for an intervention service |
| US10642957B1 (en) | 2014-10-21 | 2020-05-05 | Mckesson Corporation | Systems and methods for determining, collecting, and configuring patient intervention screening information from a pharmacy |
| US10650380B1 (en) | 2017-03-31 | 2020-05-12 | Mckesson Corporation | System and method for evaluating requests |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5519607A (en) * | 1991-03-12 | 1996-05-21 | Research Enterprises, Inc. | Automated health benefit processing system |
| US5737539A (en) * | 1994-10-28 | 1998-04-07 | Advanced Health Med-E-Systems Corp. | Prescription creation system |
| US5845255A (en) * | 1994-10-28 | 1998-12-01 | Advanced Health Med-E-Systems Corporation | Prescription management system |
| US5666492A (en) * | 1995-01-17 | 1997-09-09 | Glaxo Wellcome Inc. | Flexible computer based pharmaceutical care cognitive services management system and method |
| US5758095A (en) * | 1995-02-24 | 1998-05-26 | Albaum; David | Interactive medication ordering system |
| US5911132A (en) * | 1995-04-26 | 1999-06-08 | Lucent Technologies Inc. | Method using central epidemiological database |
| US6397224B1 (en) * | 1999-12-10 | 2002-05-28 | Gordon W. Romney | Anonymously linking a plurality of data records |
| US6947900B2 (en) * | 2000-01-06 | 2005-09-20 | Drugstore.Com | Method and apparatus for automatic product listing |
| US7657479B2 (en) * | 2000-03-02 | 2010-02-02 | PriceDoc, Inc. | Method and system for provision and acquisition of medical services and products |
| US7630908B1 (en) * | 2000-05-01 | 2009-12-08 | John Amrien | Wireless electronic prescription scanning and management system |
| GB2376108A (en) * | 2000-09-04 | 2002-12-04 | Enigma Health Uk Ltd | Improvements relating to information management systems |
| US7346521B2 (en) | 2001-03-05 | 2008-03-18 | Ims Health Incorporated | System and methods for generating physician profiles concerning prescription therapy practices |
| GB0129767D0 (en) * | 2001-12-12 | 2002-01-30 | Euro Celtique Sa | Medical after sales support |
-
2003
- 2003-02-21 AU AU2003213178A patent/AU2003213178A1/en not_active Abandoned
- 2003-02-21 CA CA2476918A patent/CA2476918C/en not_active Expired - Lifetime
- 2003-02-21 WO PCT/US2003/005231 patent/WO2003073346A1/en not_active Application Discontinuation
- 2003-02-21 US US10/505,646 patent/US8095385B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20060074717A1 (en) | 2006-04-06 |
| CA2476918C (en) | 2015-06-30 |
| US8095385B2 (en) | 2012-01-10 |
| WO2003073346A1 (en) | 2003-09-04 |
| AU2003213178A1 (en) | 2003-09-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2608992C (en) | System to provide specific messages to patients | |
| CA2575310C (en) | A method for linking de-identified patients using encrypted and unencrypted demographic and healthcare information from multiple data sources | |
| US8577691B2 (en) | Pharmacy system data interface system and method | |
| US7996260B1 (en) | Promotional carrier for promoting pharmaceutical prescription products | |
| US20120158604A1 (en) | Systems and methods for managing regulatory information | |
| WO2001098994A1 (en) | Method and apparatus for requesting and retrieving medical information | |
| WO2005116894A2 (en) | Pharmacy benefits calculator | |
| US20040148196A1 (en) | Method for assimilating and using pharmacy data | |
| US20080103855A1 (en) | System And Method For Detecting Anomalies In Market Data | |
| US7069226B1 (en) | Prescription data processing system for determining new therapy starts | |
| CA2476918C (en) | Method and system to track customer purchases | |
| US20080185425A1 (en) | System of performing a retrospective drug profile review of de-identified patients | |
| US20040162740A1 (en) | Digitized prescription system | |
| CN114420240A (en) | Prescription management system based on artificial intelligence, big data and block chain | |
| US20060218013A1 (en) | Electronic directory of health care information | |
| US20120191471A1 (en) | Method, system, and software for analysis of a billing process | |
| US20170372021A9 (en) | System and method for generating simulated prescription-drug claims | |
| CN110739035A (en) | patient medical record management system of medical institution | |
| Baser et al. | Use of Open Claims vs Closed Claims in Health Outcomes Research | |
| US20240013245A1 (en) | System and method for providing drug and medical pricing information | |
| Kallukaran et al. | Data mining at IMS health: How we turned a mountain of data into a few information-rich molehills | |
| Bell et al. | Evaluating the technical adequacy of electronic prescribing standards: results of an expert panel process | |
| CN114240396A (en) | Prescription medicine sale multi-part cooperation management system and method thereof | |
| CN116703280A (en) | Drug order generation method, device, computer equipment and readable storage medium | |
| CN116189920A (en) | Medicine integrated management system and management method based on medicine association store |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20230221 |