|Numéro de publication||US8095385 B2|
|Type de publication||Octroi|
|Numéro de demande||US 10/505,646|
|Date de publication||10 janv. 2012|
|Date de dépôt||21 févr. 2003|
|Date de priorité||21 févr. 2002|
|État de paiement des frais||Payé|
|Autre référence de publication||CA2476918A1, CA2476918C, US20060074717, WO2003073346A1|
|Numéro de publication||10505646, 505646, PCT/2003/5231, PCT/US/2003/005231, PCT/US/2003/05231, PCT/US/3/005231, PCT/US/3/05231, PCT/US2003/005231, PCT/US2003/05231, PCT/US2003005231, PCT/US200305231, PCT/US3/005231, PCT/US3/05231, PCT/US3005231, PCT/US305231, US 8095385 B2, US 8095385B2, US-B2-8095385, US8095385 B2, US8095385B2|
|Inventeurs||Jay Feldman, Michael Wieczkowski|
|Cessionnaire d'origine||Ims Software Services Ltd.|
|Exporter la citation||BiBTeX, EndNote, RefMan|
|Citations de brevets (13), Classifications (16), Événements juridiques (4)|
|Liens externes: USPTO, Cession USPTO, Espacenet|
This application is related to U.S. Provisional Patent Application 60/358,866, filed on Feb. 21, 2002, from which priority is claimed.
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.
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 “00A” at pharmacy ABC. If John Doe then gets a pharmaceutical filled from drugstore XYZ, John 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.
An object of the present invention is to provide a technique for identifying transactions 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 achieve 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 area 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.
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:
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
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.
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
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
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 data and other data formats than that represented in
|Brevet cité||Date de dépôt||Date de publication||Déposant||Titre|
|US5519607||6 juil. 1993||21 mai 1996||Research Enterprises, Inc.||Automated health benefit processing system|
|US5666492||17 janv. 1995||9 sept. 1997||Glaxo Wellcome Inc.||Flexible computer based pharmaceutical care cognitive services management system and method|
|US5737539||28 oct. 1994||7 avr. 1998||Advanced Health Med-E-Systems Corp.||Prescription creation system|
|US5758095||24 févr. 1995||26 mai 1998||Albaum; David||Interactive medication ordering system|
|US5911132 *||14 oct. 1997||8 juin 1999||Lucent Technologies Inc.||Method using central epidemiological database|
|US6397224 *||10 déc. 1999||28 mai 2002||Gordon W. Romney||Anonymously linking a plurality of data records|
|US7630908 *||8 déc. 2009||John Amrien||Wireless electronic prescription scanning and management system|
|US20020065758 *||29 nov. 2000||30 mai 2002||Henley Julian L.||Method and system for provision and acquisition of medical services and products|
|US20020091576 *||6 janv. 2000||11 juil. 2002||Joseph Giordano||Method and apparatus for automatic product listing|
|US20020165736||29 août 2001||7 nov. 2002||Jill Tolle||System and methods for generating physician profiles concerning prescription therapy practices|
|US20040019502 *||27 févr. 2003||29 janv. 2004||Enigma Health Uk Limited||Information management systems|
|US20050060197 *||16 août 2004||17 mars 2005||Christian Mayaud||Computerized prescription system for gathering and presenting information relating to pharmaceuticals|
|US20050119941 *||27 nov. 2002||2 juin 2005||Euro-Celtique S.A.||Medical after sales support|
|Classification aux États-Unis||705/3, 705/2|
|Classification internationale||G06F19/00, G06Q30/00|
|Classification coopérative||G06Q30/02, G06F19/322, G06Q40/08, G06Q50/24, G06Q30/0601, G06Q50/22|
|Classification européenne||G06Q30/02, G06F19/32C, G06Q50/22, G06Q50/24, G06Q40/08, G06Q30/0601|
|8 sept. 2005||AS||Assignment|
Owner name: IMS SOFTWARE SERVICES LTD., PENNSYLVANIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FELDMAN, JAY;WIECZKOWSKI, MICHAEL;SIGNING DATES FROM 20050901 TO 20050902;REEL/FRAME:016957/0122
|2 mars 2010||AS||Assignment|
Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, NE
Free format text: SECURITY AGREEMENT;ASSIGNORS:IMS HEALTH INCORPORATED, A DE CORP.;IMS HEALTH LICENSING ASSOCIATES, L.L.C., A DE LLC;IMS SOFTWARE SERVICES LTD., A DE CORP.;REEL/FRAME:024006/0581
Effective date: 20100226
|24 juil. 2015||FPAY||Fee payment|
Year of fee payment: 4
|24 juil. 2015||SULP||Surcharge for late payment|