US20080275724A1 - Cpt pricing from medpar data - Google Patents
Cpt pricing from medpar data Download PDFInfo
- Publication number
- US20080275724A1 US20080275724A1 US11/744,556 US74455607A US2008275724A1 US 20080275724 A1 US20080275724 A1 US 20080275724A1 US 74455607 A US74455607 A US 74455607A US 2008275724 A1 US2008275724 A1 US 2008275724A1
- Authority
- US
- United States
- Prior art keywords
- amounts
- charge amount
- healthcare organization
- charge
- amount
- 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
- 230000008520 organization Effects 0.000 claims abstract description 77
- 238000000034 method Methods 0.000 claims abstract description 56
- 238000004458 analytical method Methods 0.000 abstract description 8
- 230000008569 process Effects 0.000 description 5
- 101100544603 Candida albicans (strain SC5314 / ATCC MYA-2876) PRP13 gene Proteins 0.000 description 4
- 101000577652 Homo sapiens Serine/threonine-protein kinase PRP4 homolog Proteins 0.000 description 4
- 101000577737 Homo sapiens U4/U6 small nuclear ribonucleoprotein Prp4 Proteins 0.000 description 4
- 102100028868 Serine/threonine-protein kinase PRP4 homolog Human genes 0.000 description 4
- 102100040374 U4/U6 small nuclear ribonucleoprotein Prp3 Human genes 0.000 description 4
- NREIOERVEJDBJP-KFDLCVIWSA-N [3)-beta-D-ribosyl-(1->1)-D-ribitol-5-P-(O->]3 Chemical compound O[C@@H]1[C@H](O)[C@@H](CO)O[C@H]1OC[C@H](O)[C@H](O)[C@H](O)COP(O)(=O)O[C@@H]1[C@@H](CO)O[C@@H](OC[C@H](O)[C@H](O)[C@H](O)COP(O)(=O)O[C@@H]2[C@H](O[C@@H](OC[C@H](O)[C@H](O)[C@H](O)COP(O)(O)=O)[C@@H]2O)CO)[C@@H]1O NREIOERVEJDBJP-KFDLCVIWSA-N 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 239000003607 modifier Substances 0.000 description 4
- 101000610640 Homo sapiens U4/U6 small nuclear ribonucleoprotein Prp3 Proteins 0.000 description 3
- 102100031712 Splicing factor 3A subunit 2 Human genes 0.000 description 3
- 101100137548 Arabidopsis thaliana PRF4 gene Proteins 0.000 description 2
- 101100137549 Arabidopsis thaliana PRF5 gene Proteins 0.000 description 2
- 101000707567 Homo sapiens Splicing factor 3B subunit 1 Proteins 0.000 description 2
- 101150066369 PRO3 gene Proteins 0.000 description 2
- 101150054426 PRO4 gene Proteins 0.000 description 2
- 101150101414 PRP1 gene Proteins 0.000 description 2
- 101100368710 Rattus norvegicus Tacstd2 gene Proteins 0.000 description 2
- 101100342406 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) PRS1 gene Proteins 0.000 description 2
- 101100255229 Schizosaccharomyces pombe (strain 972 / ATCC 24843) prp12 gene Proteins 0.000 description 2
- 101100311302 Sordaria macrospora (strain ATCC MYA-333 / DSM 997 / K(L3346) / K-hell) pro11 gene Proteins 0.000 description 2
- 102100031711 Splicing factor 3B subunit 1 Human genes 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000002860 competitive effect Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 101150106994 yme2 gene Proteins 0.000 description 2
- 101100137547 Arabidopsis thaliana PRF3 gene Proteins 0.000 description 1
- 208000017667 Chronic Disease Diseases 0.000 description 1
- 101000707561 Homo sapiens Splicing factor 3A subunit 2 Proteins 0.000 description 1
- 101000707569 Homo sapiens Splicing factor 3A subunit 3 Proteins 0.000 description 1
- 206010028980 Neoplasm Diseases 0.000 description 1
- 102100031710 Splicing factor 3A subunit 3 Human genes 0.000 description 1
- 101100137778 Zea mays PRO5 gene Proteins 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 201000011510 cancer Diseases 0.000 description 1
- 230000000747 cardiac effect Effects 0.000 description 1
- 230000001609 comparable effect Effects 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000007418 data mining Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 206010012601 diabetes mellitus Diseases 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 229910000078 germane Inorganic materials 0.000 description 1
- 208000019622 heart disease Diseases 0.000 description 1
- 238000005065 mining Methods 0.000 description 1
- 230000000474 nursing effect Effects 0.000 description 1
- 229940052586 pro 12 Drugs 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
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
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- 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
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
Definitions
- MedPAR data For a healthcare organization, such as a hospital, competitor pricing information is useful competitive intelligence.
- One source for such pricing information is MedPAR data, which is based on information reported by healthcare organizations to the government, and thusly made available to the public for a fee.
- MedPAR data often has several or many charge amounts associated with a particular procedure for a particular healthcare organization.
- the present invention is directed to methods and systems supporting the application of a set of rules to MedPAR data, yielding data indicative of what a healthcare organization actually charges for a procedure. Further, the disclosure is further directed to methods used to commercialize this information.
- the present invention is directed toward a computer-implemented method of determining an actual amount a target healthcare organization charges for a procedure, the procedure associated with a CPT code, the method comprising: accessing MedPAR data defining a plurality of charge amounts charged by the target healthcare organization for the procedure; applying a set of rules to the MedPAR data; and, based on the application of the set of rules, computing a dollar amount the healthcare organization charged for the CPT code associated with the procedure.
- the disclosure is directed toward a system for identifying an actual amount a target healthcare organization charges for a procedure, the procedure associated with a CPT code, the system comprising: a database component operative to maintain records identifying a plurality of amounts the target healthcare organization has charged for the procedure associated with the CPT code; a processor programmed to: retrieve the records from the database component; apply a set of rules to the records; and, based on the application of the set of rules, compute an actual amount charged by the target healthcare organization for the procedure associated with the CPT code.
- the disclosure is directed toward a method of benchmarking at least a portion of a first healthcare organization's chargemaster against a second healthcare organization, comprising: receiving at least a portion of the first healthcare organization's chargemaster, the chargemaster including an amount charged for a procedure associated with a CPT code; applying a set of rules to MedPAR data, the MedPAR data including data defining a plurality of amounts the second healthcare organization has charged for the procedure associated with the CPT code, the set of rules determining an actual charge amount, among the plurality of amounts; and, providing a report to the first healthcare organization, the report including the amount charged for the procedure associated with the CPT code by the first healthcare organization against the actual charge amount of the second healthcare organization.
- FIG. 1 is a diagram showing an exemplary embodiment of CPT pricing system in accordance with the present invention.
- FIG. 2 is a high-level flowchart illustrating how MedPAR data is brought into and analyzed in accordance with the present invention.
- FIG. 3 is a flowchart graphically illustrating one embodiment of logic that could be used to populate a master database in accordance with the present invention.
- FIG. 4 is a functional diagram illustrating detail behind the hunt for common charge amount routine.
- FIGS. 5A , 5 B, 5 C, 5 D, and 5 E show examples of the application of the logic shown in various steps in FIG. 4 .
- FIG. 6 is a flowchart showing one exemplary manner in which a user may interact with the system described herein.
- a patient's encounter with a healthcare organization is often documented by the healthcare organization using pre-defined codes that represent services provided to the patient.
- One such code base is marketed by the American Medical Association under the trade designation Current Procedure Terminology, or CPT.
- CPT codes describe or define services rendered to a patient.
- the codes may be used for billing purposes, by cross referencing particular codes against a chargemaster.
- a chargemaster is a table that defines prices for particular CPT codes.
- MedPAR data refers to Medicare Provider Analysis and Review dataset, which is maintained by, and available from, the Centers for Medicare and Medicaid Services (http://www.cms.hhs.gov) for a nominal fee.
- MedPAR data is typically purchased by companies that analyze it and make reports or views of the data available, usually for a fee, to healthcare organizations, researchers, etc.
- researchers might use the MedPAR data, or various abstracts of it, to research chronic disease prevalent in the elderly population (cancer, heart disease, diabetes, etc.), or for mortality studies.
- Healthcare organizations may be interested in reports based on the MedPAR data that show information about competitors or peer companies. For example, with the MedPAR data it is possible to get a sense of what services a particular healthcare organization have sold in a particular geographic region. While the only population represented in the data is the Medicare inpatient population, this dataset is generally regarded as sufficiently representative of the entire inpatient population to provide useful information.
- MedPAR data it is also possible to use the MedPAR data to determine actual CPT-based pricing for a healthcare organization.
- “Actual,” in this context, refers to the fact that the price was actually in fact charged by the healthcare organization—it is not, for example, an average of prices charged, which is a fictional value (i.e. the healthcare organization does not, in practice, actually charge the average amount).
- This actual pricing information may be helpful in rationalizing a healthcare organization's own chargemaster. It may also be helpful in analyzing a healthcare organization's chargemaster to make sure CPT codes are in line with market practices (for example, they are not “under” or “over” billing (billing rates less than/greater than the market, respectively).
- FIG. 1 is a diagram that shows an exemplary embodiment of CPT pricing system 9 , which includes pricing optimizer engine 11 , common pricing engine 8 , MedPAR database 15 , and CPT price master database 16 .
- CPT pricing system 9 may analyze a healthcare organization's chargemaster data, or a subset thereof, in light of data derived from MedPAR data. Particularly, CPT pricing system 9 may, in one embodiment, receive a healthcare organization's chargemaster, or a subset of their chargemaster, and then analyze it in light of MedPAR data to show where and how the healthcare organization's chargemaster differs from aspects of a competitor's or peer company. In addition, this analysis can be utilized by a healthcare organization to develop a transparent and defensible pricing structure.
- this information may be useful for a healthcare organization interested in modifying its pricing, but unsure in what service areas it has the ability to make such modifications (i.e. in some service areas, it may have more or less ability to make changes, or risk being out of line with market conditions, for example).
- the information also may be useful for reports benchmarking a healthcare organization's book of business against other facilities selected to be peer comparables. Such benchmarking may additionally show service areas offered by a healthcare organization that fall outside of its desired market position. Such benchmarking may additionally show service areas offered by a healthcare organization that fall outside of its desired market position. For example, if a hospital is charging too high for cardiac-related procedures, a comparison against its peers will allow the hospital to establish a competitive posture. Similarly, the hospital may choose to keep its rates higher than the benchmarks because they may believe that their services are of a more specialized nature either because of volume, technology available at that hospital only, or other factors.
- the CPT pricing system 9 is implemented in a computing device 14 , which may be any computer with a memory, such as a personal computer, a server, multiple servers, or a personal digital assistant.
- computing device 14 is shown further containing user interface 12 and application program interface (API) 8 .
- Computing device 14 is further showing including web server 3 .
- a user such as user 10 , may interact with CPT pricing system 9 via user interface 12 , or via web server 3 (via a web browser-type application running on a client computer).
- Web server 3 which shown in FIG. 1 as part of computing system 14 , may be implemented in a variety of ways.
- web server 3 might be on another computer system, such as stand alone computer system 5 , and access the CPT pricing system via API 2 . Users of the CPT pricing system, then, could interact with web server 3 running on stand alone computer system 5 .
- CPT pricing system 9 in the embodiment shown in FIG. 1 , is comprised of pricing optimizer engine 11 , common pricing engine 8 , and two databases: MedPAR database 15 , and CPT price master database 16 .
- CPT pricing system 9 may be implemented in a variety of ways, and the manner in which a particular limitation discussed herein should not be read as limiting, because as one skilled in the art will appreciate, there are many ways to implement the system described herein.
- Common pricing engine 8 includes logic by which to “mine” MedPAR data, and populate CPT price master database 16 .
- the mining operation functionally invoked by common pricing engine 8 in effect attempts to create chargemaster-like data for each facility represented in MedPAR, by applying a set of rules against the MedPAR data.
- common pricing engine 8 attempts to assign a most probable price to each CPT code a healthcare organization is charging for, using logic further discussed herein.
- optimizer engine 11 facilitates interaction with CPT price master database 16 .
- user 10 may interact with user interface 12 to provide information including the CPT code of interest and the healthcare organization of interest (the target healthcare organization). This information would in turn be provided to optimizer engine, along with data representing the request itself. The information and request could be facilitated by, for example, a function call or similar.
- the optimizer engine 11 then, would make appropriate queries against CPT price master database 16 , arrive at and possibly validate a result, then return it to user interface module 12 , which in turn may present it to user 10 .
- user interface module 12 which in turn may present it to user 10 .
- a similar interaction could be achieved where a user (not shown) interacts with web server 3 using a client computer running a web browser-type application.
- the two databases shown in CPT pricing system 9 may be implemented in a myriad of ways, as discussed further below.
- CPT pricing system 9 receives MedPAR data, in one embodiment the location of which (usually a large flat file, but could be a database) is specified via user interface 12 .
- User interface 12 may be a graphical user interface which facilitates data entry or uploading, and interfaces with common pricing engine 8 and optimizer engine 11 .
- User 10 may be any person interested in accessing the functionality of CPT pricing system 9 . If user 10 is an owner or administrator or manager of CPT pricing system 9 , he may see a different set of user interface screens that particularly facilitate his management function.
- user 10 may access the common pricing engine 8 to load raw MedPAR data into MedPAR database 15 , then invoke functionality within common pricing engine 8 to mine the MedPAR data from MedPAR database 15 and populate CPT price master database 16 .
- user 10 may, for example, be a consultant working for the benefit of a healthcare organization.
- user 10 would typically not be concerned with interacting with CPT pricing system 9 in the same manner as a manager or administrator of the system. Instead, user 10 would access CPT pricing system, and particularly optimizer engine 11 , via user interface 12 or web server 3 .
- User 10 would submit queries to optimizer engine 11 , which in turn would interact with CPT price master database 16 to return information or reports to user 10 .
- User 10 may also be a healthcare organization itself. Access in such a case would be via user interface 12 , or via web server 3 , or, if the healthcare organization has customized programs needing to access data of the type supplied by CPT pricing system 9 , the healthcare organization may access the CPT pricing system via API 2 .
- Network 7 may be any network, public or private, that carries information.
- network 7 connects computing device 14 , and thus CPT pricing system 9 , to stand alone computer system 5 .
- User 10 may interact with stand alone computer system 5 , for example, if user 10 is not in physical proximity to computing device 14 .
- Network 7 also connects to healthcare organization 4 .
- Computing device 14 may read software instructions from a computer-readable medium (such as a hard drive, a CD-ROM, or a computer memory), or may receive instructions from another source logically connected to computer, such as another networked computer.
- CPT pricing system 9 and/or any of the logic and procedures included herein may be embodied in a computer-readable medium, to be executed by a computer processor. Further, CPT pricing system 9 may be distributed to execute on multiple computers, and may be located remote to user 10 and accessible via a web browser or other interface.
- computing device 14 typically includes hardware (not shown in FIG.
- Computing device 14 may include one or more processors, volatile memory (RAM), a device for reading computer-readable media, and input/output devices, such as a display, a keyboard, and a pointing device.
- Computing device 14 may be, for example, a workstation, a laptop, a personal digital assistant (PDA), a server, a mainframe or any other general-purpose or application-specific computing device.
- computing device 14 may also include other software, firmware, or combinations thereof, such as an operating system and other application software.
- Computing device 14 may read executable software instructions from a computer-readable medium (such as a hard drive, or a CD-ROM), or may receive instructions from another source logically connected to computer, such as another networked computer.
- components that comprise CPT pricing system 9 may be disparately located. For example, database components may be located in one geographic region, while processing components are located in another.
- MedPAR database 15 and CPT price master database 16 may be any type of data stores. They need not be separate databases, and are shown as such for illustrative purposes only.
- the databases may be data storage files, or one or more database management systems (DBMS) executing on one or more database servers.
- the database management system may be a relational (RDBMS), hierarchical (HDBMS), multidimensional (MDBMS), object oriented (ODBMS or OODBMS) or object relational (ORDBMS) database management system.
- RDBMS database management systems
- the database management system may be a relational (RDBMS), hierarchical (HDBMS), multidimensional (MDBMS), object oriented (ODBMS or OODBMS) or object relational (ORDBMS) database management system.
- MedPAR database 15 and CPT price master database 16 are in one embodiment a single relational database such as SQL SERVERTM from Microsoft Corporation of Redmond, Wash.
- FIG. 2 is a high-level flowchart illustrating how MedPAR data is brought into and analyzed by CPT pricing system 9 .
- MedPAR data is received and loaded into MedPAR database 15 (LD 1 ).
- This load may have minimal, if any, transformation associated with it—that is, the load is basically to get the raw MedPAR data into a database to allow subsequent manipulation.
- the MedPAR data is analyzed (LD 2 ) using exemplary techniques such as those further described below, specifically with respect to FIG. LD.
- the CPT price master database 16 is populated (LD 3 ).
- FIG. 3 is a flowchart graphically illustrating one embodiment of logic that could be used in common pricing engine 8 to populate CPT price master database 16 .
- CPT price master database 16 is mined and populated in advance of optimizer engine 11 accessing it to fulfill user queries.
- MedPAR data could similarly be accessed and analyzed on the fly, with sufficient computing power.
- the batch-processing approach to analyzing MedPAR data disclosed in FIG. 3 should not be read as limiting, as one in the art will appreciate.
- the data mining process starts (PRO 1 ) by accessing MedPAR data (PRO 2 ).
- the MedPAR data has already been loaded into a database such as MedPAR database 15 .
- the MedPAR data is in raw form, comprised of records. Records contain claim information for a patient's visit to a healthcare organization. Records with CPT codes having certain modifiers that impact pricing are eliminated (PRO 3 ). These records are eliminated because they may impact pricing. While many modifiers are informational (for example, a CPT code may describe a service associated with a broken arm, and the modifiers might further define which arm is broken (left or right)), another set (which is excluded) is not merely informational and instead may indicate other information about the procedure associated with the CPT code that does impact pricing.
- the particular MedPAR modifiers excluded include those that could affect the pricing of the base code charge, or “code 5 ” as it is know to those skilled in the art. These may include, for example, 21, 22, 23, 26, 50, 51, 52, 53, 54, 55, 54, 62, 66, 75, 80, 81, 82, “TC” and “TU.”
- records with negative pricing data are excluded (PRO 4 ). Particularly, records where charges are negative, or where charges less non-covered serves are negative. These data are excluded because they may represent duplicate claims, re-submissions of denied claims, or other out-of-the-ordinary type circumstances may have an undesirable bearing on the common price being sought. Steps illustrated in PRO 3 and PRO 4 are part of an initial culling of data represented in FIG.
- step PRO 5 One skilled in the art will appreciate there may be other records for which it is advantageous to exclude, that could be a part of the initial culling.
- the two culling operations presented as part of culling operation PRO 5 show just one manner, among many, whereby data could be prepared for analysis.
- a query is performed which returns of all healthcare organizations represented in the culled dataset (PRO 16 ).
- a first healthcare organization is selected from the listing (PRO 6 ) and analysis of that healthcare organization's billing practices begins.
- a listing of all CPT codes available for the healthcare organization is populated (PRO 17 ).
- a first CPT code is selected for analysis, and all records associated with the particular healthcare organization are retrieved. These records include at least a CPT code and the amount charged for that CPT code. Other data is often included in these records.
- a routine applies logic to the listing of records having a common CPT code, to try to find a common charge amount (PRO 8 ).
- This routine is further documented in FIG. 4 .
- the hunt routine will either succeed in finding a charge amount for a given CPT code (YES at PRO 9 ), or it will fail (NO at PRO 9 ). If the routine fails to find a common charge amount, a null set or similar indicia is returned and associated with that CPT code (PRO 13 ). If the routine succeeds in finding a common amount for the CPT code, the amount is returned and associated with that CPT code, for the particular healthcare organization, in CPT price master database 16 .
- step PRO 17 a check is made of the listing of CPT codes made in step PRO 17 . If there are more CPT codes in the listing (PRO 11 ), the next code is chosen from the listing (PRO 12 ) and the process of analyzing the particular CPT code for the healthcare organization repeats starting at step PRO 7 .
- the routine checks whether there are further healthcare organizations in the listing of healthcare organizations assembled in step PRO 16 . If there are (YES at PRO 14 ), the next healthcare organization is retrieved (PRO 18 ), and that organization's CPT codes and billing practices thereby analyzed (PRO 6 ). If there are no further healthcare organizations, the routine completes (PRO 15 ).
- the CPT price master database 12 includes, for each healthcare organization, a listing of CPT codes that organization has attempted to bill for, and the a probable amount that represents the probable common charge associated with that CPT code (if such common charge was ascertainable by the hunt routine of PRO 8 ).
- FIG. 4 is a functional diagram that illustrates detail behind the hunt for common charge amount of FIG. PRO, step PRO 8 .
- PRP 1 the charge amount with the highest frequency
- PRP 2 the charge amount at the 75 th percentile of the ranked dataset
- the 75 th percentile is calculated to add significance to the data set.
- a comparison to the charge amount at the 75 th percentile assures that 75% of the charge values for a particular healthcare organization's CPT code have a common charge amount.
- a comparison of the charge amount with highest frequency (determined in PRP 1 ) and the charge amount at 75 th percentile (determined is PRP 2 ) is made.
- FIG. 5A is an exemplary table illustrating a simplified example of how this check in PRP 3 may work.
- the CPT code for which a price is being sought is 11042.
- Count refers to the number of times a particular charge amount is associated with the CPT code in question.
- the charge amount with the highest frequency is $775 (would be computed in step PRP 1 ).
- the charge amount at the 75 th percentile is also $775 (computed in step PRP 2 ).
- the two values are compared in step PRP 3 , and as they are equal, the $775 value is assigned to CPT code 11042.
- the routine checks whether 50 % or more of the dataset is a common charge amount (PRP 4 ). If it is (YES at PRP 4 ), then that common charge amount is returned (PRP 7 ).
- FIG. 5B is an example of the application of this rule to a simplified dataset. As in FIG. 5A , the routine is searching for a charge amount associated with CPT code 11042. In this example dataset, $775 has a frequency percentage (50%) at least equal to or greater than 50%. Thus, there would be a YES at PRP 4 , and the charge amount returned would be $775.
- the weighted average charge price of the CPT code for the particular healthcare organization is calculated (PRP 15 ), and this weighted average returned along with other indicia representing the result is flagged (PRP 9 ).
- the result is flagged because it is an amount is not based on frequencies, and thus may not actually ever have been charged by the particular healthcare organization.
- FIG. 5C , FIG. 5D , and FIG. 5E show examples of the application of the logic of shown in steps PRP 10 through PRP 14 .
- the simplified datasets shown with respect to FIG. 5C , 5 D, and 5 E would have progressed through logic shown preceding PRP 10 (there would have been no computed common charge amount figured for these datasets).
- FIG. 5C shows a dataset having a highest frequency charge amount higher than 25% (YES to step PRP 11 in FIG. 4 ). There is no other charge amount with a frequency equal to 25 (NO to step PRP 12 in FIG. 4 ). Further, there is no other charge amount with a frequency greater than 25% (NO at step PRP 13 in FIG. 4 ). Thus, charge amount $775 is returned (at step PRP 7 in FIG. 4 ).
- the example numbers show there is an amount having a frequency greater than 25% (YES at step PRP 1 1 in FIG. 4 ). And there are in fact two numbers having the same charge amount frequency (the first for $775, the second for $985) (YES at step PRP 12 in FIG. 4 ). Thus, a dataset synonymous with “not available” is found (step PRP 6 in FIG. 4 ).
- FIG. 5E there are two charge amounts with a frequency above 25% of the total (YES at step PRP 11 in FIG. 4 , and NO at step PRP 12 in FIG. 4 ). Since there is more than one charge amount with a frequency greater than 25% (YES at step PRP 13 ), a check is made as to whether the difference in percentage between the frequencies of the two highest frequencies is at least 10%. Since in this case $775's 39% is 12 points greater than $985's 27%, and 12 is greater than 10 there is a YES at step PRP 14 in FIG. 4 , and the $775 charge amount is returned (step PRP 7 in FIG. 4 ).
- FIG. 6 is a flowchart showing an exemplary manner in which user 10 , who in this particular case is a consulting company, may interact with the CPT price master database 16 , via optimizer engine 11 , and in turn via one of the several interfaces into CPT pricing system (in this particular example web server 3 ).
- CPT pricing system in this particular example web server 3 .
- this process presumes CPT price master database 16 has already been populated using logic described above.
- the process and system could be architected to do CPT analysis of the type mentioned above real-time, and thus nullify the necessity of the CPT price master database.
- Geographical Area Within an area (up to 60 mile radius) from the customer.
- Bed Size Facilities of similar bed size.
- Revenue Size Facilities that have a similar revenue.
- Level of services Compare facilities that perform similar services as the customer.
- the customer's chargemaster, or germane portions of it are uploaded to CPT pricing system 9 . Analysis is done, and the consultant receives a benchmark report (WEB 4 ) showing how the customer compares, in various aspects, to one or more peer companies.
Abstract
Description
- For a healthcare organization, such as a hospital, competitor pricing information is useful competitive intelligence. One source for such pricing information is MedPAR data, which is based on information reported by healthcare organizations to the government, and thusly made available to the public for a fee. For various reasons, MedPAR data often has several or many charge amounts associated with a particular procedure for a particular healthcare organization.
- In general, the present invention is directed to methods and systems supporting the application of a set of rules to MedPAR data, yielding data indicative of what a healthcare organization actually charges for a procedure. Further, the disclosure is further directed to methods used to commercialize this information.
- In one embodiment, the present invention is directed toward a computer-implemented method of determining an actual amount a target healthcare organization charges for a procedure, the procedure associated with a CPT code, the method comprising: accessing MedPAR data defining a plurality of charge amounts charged by the target healthcare organization for the procedure; applying a set of rules to the MedPAR data; and, based on the application of the set of rules, computing a dollar amount the healthcare organization charged for the CPT code associated with the procedure.
- In another embodiment, the disclosure is directed toward a system for identifying an actual amount a target healthcare organization charges for a procedure, the procedure associated with a CPT code, the system comprising: a database component operative to maintain records identifying a plurality of amounts the target healthcare organization has charged for the procedure associated with the CPT code; a processor programmed to: retrieve the records from the database component; apply a set of rules to the records; and, based on the application of the set of rules, compute an actual amount charged by the target healthcare organization for the procedure associated with the CPT code.
- In another embodiment, the disclosure is directed toward a method of benchmarking at least a portion of a first healthcare organization's chargemaster against a second healthcare organization, comprising: receiving at least a portion of the first healthcare organization's chargemaster, the chargemaster including an amount charged for a procedure associated with a CPT code; applying a set of rules to MedPAR data, the MedPAR data including data defining a plurality of amounts the second healthcare organization has charged for the procedure associated with the CPT code, the set of rules determining an actual charge amount, among the plurality of amounts; and, providing a report to the first healthcare organization, the report including the amount charged for the procedure associated with the CPT code by the first healthcare organization against the actual charge amount of the second healthcare organization.
- The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.
-
FIG. 1 is a diagram showing an exemplary embodiment of CPT pricing system in accordance with the present invention. -
FIG. 2 is a high-level flowchart illustrating how MedPAR data is brought into and analyzed in accordance with the present invention. -
FIG. 3 is a flowchart graphically illustrating one embodiment of logic that could be used to populate a master database in accordance with the present invention. -
FIG. 4 is a functional diagram illustrating detail behind the hunt for common charge amount routine. -
FIGS. 5A , 5B, 5C, 5D, and 5E show examples of the application of the logic shown in various steps inFIG. 4 . -
FIG. 6 is a flowchart showing one exemplary manner in which a user may interact with the system described herein. - A patient's encounter with a healthcare organization (for example a hospital or skilled nursing facility) is often documented by the healthcare organization using pre-defined codes that represent services provided to the patient. One such code base is marketed by the American Medical Association under the trade designation Current Procedure Terminology, or CPT. CPT codes describe or define services rendered to a patient. Once a patient's encounter with a healthcare organization has been appropriately described by CPT codes, the codes may be used for billing purposes, by cross referencing particular codes against a chargemaster. A chargemaster is a table that defines prices for particular CPT codes. Once the CPT codes have been cross-referenced with prices, hospitals can generate and submit bills to payment organizations, which in turn may have their own chargemaster-type tables which define what the payment organization will in fact pay for procedures associated with particular CPT codes.
- Abstracts of the CPT-coded bills submitted to Medicare for payment are made available to the public via a product offering called MedPAR. MedPAR data refers to Medicare Provider Analysis and Review dataset, which is maintained by, and available from, the Centers for Medicare and Medicaid Services (http://www.cms.hhs.gov) for a nominal fee.
- MedPAR data is typically purchased by companies that analyze it and make reports or views of the data available, usually for a fee, to healthcare organizations, researchers, etc. Researchers might use the MedPAR data, or various abstracts of it, to research chronic disease prevalent in the elderly population (cancer, heart disease, diabetes, etc.), or for mortality studies. Healthcare organizations, on the other hand, may be interested in reports based on the MedPAR data that show information about competitors or peer companies. For example, with the MedPAR data it is possible to get a sense of what services a particular healthcare organization have sold in a particular geographic region. While the only population represented in the data is the Medicare inpatient population, this dataset is generally regarded as sufficiently representative of the entire inpatient population to provide useful information.
- Using embodiments of the invention described herein, it is also possible to use the MedPAR data to determine actual CPT-based pricing for a healthcare organization. “Actual,” in this context, refers to the fact that the price was actually in fact charged by the healthcare organization—it is not, for example, an average of prices charged, which is a fictional value (i.e. the healthcare organization does not, in practice, actually charge the average amount). This actual pricing information may be helpful in rationalizing a healthcare organization's own chargemaster. It may also be helpful in analyzing a healthcare organization's chargemaster to make sure CPT codes are in line with market practices (for example, they are not “under” or “over” billing (billing rates less than/greater than the market, respectively).
-
FIG. 1 is a diagram that shows an exemplary embodiment of CPT pricing system 9, which includespricing optimizer engine 11,common pricing engine 8, MedPARdatabase 15, and CPTprice master database 16. In certain embodiments, CPT pricing system 9 may analyze a healthcare organization's chargemaster data, or a subset thereof, in light of data derived from MedPAR data. Particularly, CPT pricing system 9 may, in one embodiment, receive a healthcare organization's chargemaster, or a subset of their chargemaster, and then analyze it in light of MedPAR data to show where and how the healthcare organization's chargemaster differs from aspects of a competitor's or peer company. In addition, this analysis can be utilized by a healthcare organization to develop a transparent and defensible pricing structure. Further, this information may be useful for a healthcare organization interested in modifying its pricing, but unsure in what service areas it has the ability to make such modifications (i.e. in some service areas, it may have more or less ability to make changes, or risk being out of line with market conditions, for example). The information also may be useful for reports benchmarking a healthcare organization's book of business against other facilities selected to be peer comparables. Such benchmarking may additionally show service areas offered by a healthcare organization that fall outside of its desired market position. Such benchmarking may additionally show service areas offered by a healthcare organization that fall outside of its desired market position. For example, if a hospital is charging too high for cardiac-related procedures, a comparison against its peers will allow the hospital to establish a competitive posture. Similarly, the hospital may choose to keep its rates higher than the benchmarks because they may believe that their services are of a more specialized nature either because of volume, technology available at that hospital only, or other factors. - In one embodiment described herein, the CPT pricing system 9 is implemented in a
computing device 14, which may be any computer with a memory, such as a personal computer, a server, multiple servers, or a personal digital assistant. For exemplary purposes only (and not limitation),computing device 14 is shown further containinguser interface 12 and application program interface (API) 8.Computing device 14 is further showing includingweb server 3. A user, such asuser 10, may interact with CPT pricing system 9 viauser interface 12, or via web server 3 (via a web browser-type application running on a client computer).Web server 3, which shown inFIG. 1 as part ofcomputing system 14, may be implemented in a variety of ways. For example,web server 3 might be on another computer system, such as standalone computer system 5, and access the CPT pricing system via API 2. Users of the CPT pricing system, then, could interact withweb server 3 running on standalone computer system 5. - As mentioned, CPT pricing system 9, in the embodiment shown in
FIG. 1 , is comprised ofpricing optimizer engine 11,common pricing engine 8, and two databases: MedPARdatabase 15, and CPTprice master database 16. CPT pricing system 9 may be implemented in a variety of ways, and the manner in which a particular limitation discussed herein should not be read as limiting, because as one skilled in the art will appreciate, there are many ways to implement the system described herein.Common pricing engine 8 includes logic by which to “mine” MedPAR data, and populate CPTprice master database 16. The mining operation functionally invoked bycommon pricing engine 8 in effect attempts to create chargemaster-like data for each facility represented in MedPAR, by applying a set of rules against the MedPAR data. Or, to put it another way,common pricing engine 8 attempts to assign a most probable price to each CPT code a healthcare organization is charging for, using logic further discussed herein. Once CPTprice master database 12 has been populated bycommon pricing engine 11,optimizer engine 11 facilitates interaction with CPTprice master database 16. As a simplified example, ifuser 10 wanted to see what the price for a given CPT code was for a particular healthcare organization,user 10 may interact withuser interface 12 to provide information including the CPT code of interest and the healthcare organization of interest (the target healthcare organization). This information would in turn be provided to optimizer engine, along with data representing the request itself. The information and request could be facilitated by, for example, a function call or similar. Theoptimizer engine 11, then, would make appropriate queries against CPTprice master database 16, arrive at and possibly validate a result, then return it touser interface module 12, which in turn may present it touser 10. Alternatively, a similar interaction could be achieved where a user (not shown) interacts withweb server 3 using a client computer running a web browser-type application. The two databases shown in CPT pricing system 9 may be implemented in a myriad of ways, as discussed further below. - CPT pricing system 9 receives MedPAR data, in one embodiment the location of which (usually a large flat file, but could be a database) is specified via
user interface 12.User interface 12 may be a graphical user interface which facilitates data entry or uploading, and interfaces withcommon pricing engine 8 andoptimizer engine 11.User 10 may be any person interested in accessing the functionality of CPT pricing system 9. Ifuser 10 is an owner or administrator or manager of CPT pricing system 9, he may see a different set of user interface screens that particularly facilitate his management function. For example,user 10, if he is a manager of CPT pricing system 9, may access thecommon pricing engine 8 to load raw MedPAR data intoMedPAR database 15, then invoke functionality withincommon pricing engine 8 to mine the MedPAR data fromMedPAR database 15 and populate CPTprice master database 16. - Alternatively or additionally,
user 10 may, for example, be a consultant working for the benefit of a healthcare organization. In such a case,user 10 would typically not be concerned with interacting with CPT pricing system 9 in the same manner as a manager or administrator of the system. Instead,user 10 would access CPT pricing system, and particularlyoptimizer engine 11, viauser interface 12 orweb server 3.User 10 would submit queries tooptimizer engine 11, which in turn would interact with CPTprice master database 16 to return information or reports touser 10. -
User 10 may also be a healthcare organization itself. Access in such a case would be viauser interface 12, or viaweb server 3, or, if the healthcare organization has customized programs needing to access data of the type supplied by CPT pricing system 9, the healthcare organization may access the CPT pricing system viaAPI 2. -
Network 7 may be any network, public or private, that carries information. InFIG. 1 ,network 7 connectscomputing device 14, and thus CPT pricing system 9, to standalone computer system 5.User 10 may interact with standalone computer system 5, for example, ifuser 10 is not in physical proximity to computingdevice 14.Network 7 also connects tohealthcare organization 4. -
Computing device 14 may read software instructions from a computer-readable medium (such as a hard drive, a CD-ROM, or a computer memory), or may receive instructions from another source logically connected to computer, such as another networked computer. CPT pricing system 9 and/or any of the logic and procedures included herein may be embodied in a computer-readable medium, to be executed by a computer processor. Further, CPT pricing system 9 may be distributed to execute on multiple computers, and may be located remote touser 10 and accessible via a web browser or other interface. As mentioned earlier,computing device 14 typically includes hardware (not shown inFIG. 1 ) that may include one or more processors, volatile memory (RAM), a device for reading computer-readable media, and input/output devices, such as a display, a keyboard, and a pointing device.Computing device 14 may be, for example, a workstation, a laptop, a personal digital assistant (PDA), a server, a mainframe or any other general-purpose or application-specific computing device. Although not shown,computing device 14 may also include other software, firmware, or combinations thereof, such as an operating system and other application software.Computing device 14 may read executable software instructions from a computer-readable medium (such as a hard drive, or a CD-ROM), or may receive instructions from another source logically connected to computer, such as another networked computer. Further, components that comprise CPT pricing system 9 may be disparately located. For example, database components may be located in one geographic region, while processing components are located in another. -
MedPAR database 15 and CPTprice master database 16 may be any type of data stores. They need not be separate databases, and are shown as such for illustrative purposes only. The databases may be data storage files, or one or more database management systems (DBMS) executing on one or more database servers. The database management system may be a relational (RDBMS), hierarchical (HDBMS), multidimensional (MDBMS), object oriented (ODBMS or OODBMS) or object relational (ORDBMS) database management system.MedPAR database 15 and CPTprice master database 16 are in one embodiment a single relational database such as SQL SERVER™ from Microsoft Corporation of Redmond, Wash. -
FIG. 2 is a high-level flowchart illustrating how MedPAR data is brought into and analyzed by CPT pricing system 9. MedPAR data is received and loaded into MedPAR database 15 (LD1). This load may have minimal, if any, transformation associated with it—that is, the load is basically to get the raw MedPAR data into a database to allow subsequent manipulation. Next, the MedPAR data is analyzed (LD2) using exemplary techniques such as those further described below, specifically with respect to FIG. LD. Finally, the CPTprice master database 16 is populated (LD3). -
FIG. 3 is a flowchart graphically illustrating one embodiment of logic that could be used incommon pricing engine 8 to populate CPTprice master database 16. In this particular embodiment ofcommon pricing engine 8's logic, CPTprice master database 16 is mined and populated in advance ofoptimizer engine 11 accessing it to fulfill user queries. One skilled in the art will appreciate MedPAR data could similarly be accessed and analyzed on the fly, with sufficient computing power. The batch-processing approach to analyzing MedPAR data disclosed inFIG. 3 should not be read as limiting, as one in the art will appreciate. - The data mining process starts (PRO1) by accessing MedPAR data (PRO2). The MedPAR data has already been loaded into a database such as
MedPAR database 15. The MedPAR data is in raw form, comprised of records. Records contain claim information for a patient's visit to a healthcare organization. Records with CPT codes having certain modifiers that impact pricing are eliminated (PRO3). These records are eliminated because they may impact pricing. While many modifiers are informational (for example, a CPT code may describe a service associated with a broken arm, and the modifiers might further define which arm is broken (left or right)), another set (which is excluded) is not merely informational and instead may indicate other information about the procedure associated with the CPT code that does impact pricing. In one embodiment, the particular MedPAR modifiers excluded include those that could affect the pricing of the base code charge, or “code 5” as it is know to those skilled in the art. These may include, for example, 21, 22, 23, 26, 50, 51, 52, 53, 54, 55, 54, 62, 66, 75, 80, 81, 82, “TC” and “TU.” Next, records with negative pricing data are excluded (PRO4). Particularly, records where charges are negative, or where charges less non-covered serves are negative. These data are excluded because they may represent duplicate claims, re-submissions of denied claims, or other out-of-the-ordinary type circumstances may have an undesirable bearing on the common price being sought. Steps illustrated in PRO3 and PRO4 are part of an initial culling of data represented inFIG. 3 as step PRO5. One skilled in the art will appreciate there may be other records for which it is advantageous to exclude, that could be a part of the initial culling. The two culling operations presented as part of culling operation PRO5 show just one manner, among many, whereby data could be prepared for analysis. - Next, a query is performed which returns of all healthcare organizations represented in the culled dataset (PRO16). A first healthcare organization is selected from the listing (PRO6) and analysis of that healthcare organization's billing practices begins. A listing of all CPT codes available for the healthcare organization is populated (PRO17). A first CPT code is selected for analysis, and all records associated with the particular healthcare organization are retrieved. These records include at least a CPT code and the amount charged for that CPT code. Other data is often included in these records.
- Next, a routine applies logic to the listing of records having a common CPT code, to try to find a common charge amount (PRO8). This routine is further documented in
FIG. 4 . The hunt routine will either succeed in finding a charge amount for a given CPT code (YES at PRO9), or it will fail (NO at PRO9). If the routine fails to find a common charge amount, a null set or similar indicia is returned and associated with that CPT code (PRO13). If the routine succeeds in finding a common amount for the CPT code, the amount is returned and associated with that CPT code, for the particular healthcare organization, in CPTprice master database 16. In either event, either a null (or similar) return value, or an actual price value is returned for a CPT code. Next, a check is made of the listing of CPT codes made in step PRO17. If there are more CPT codes in the listing (PRO11), the next code is chosen from the listing (PRO12) and the process of analyzing the particular CPT code for the healthcare organization repeats starting at step PRO7. - If there are no further CPT codes (NO at PRO11), the routine checks whether there are further healthcare organizations in the listing of healthcare organizations assembled in step PRO16. If there are (YES at PRO14), the next healthcare organization is retrieved (PRO18), and that organization's CPT codes and billing practices thereby analyzed (PRO6). If there are no further healthcare organizations, the routine completes (PRO15).
- At this point, the CPT
price master database 12 includes, for each healthcare organization, a listing of CPT codes that organization has attempted to bill for, and the a probable amount that represents the probable common charge associated with that CPT code (if such common charge was ascertainable by the hunt routine of PRO8). -
FIG. 4 is a functional diagram that illustrates detail behind the hunt for common charge amount of FIG. PRO, step PRO8. First, the charge amount with the highest frequency is computed (PRP1). Next, the charge amount at the 75th percentile of the ranked dataset is computed (PRP2). The 75th percentile is calculated to add significance to the data set. A comparison to the charge amount at the 75th percentile assures that 75% of the charge values for a particular healthcare organization's CPT code have a common charge amount. A comparison of the charge amount with highest frequency (determined in PRP1) and the charge amount at 75th percentile (determined is PRP2) is made. If the two charge amounts are equal (YES at PRP3) this charge amount is returned (PRP7).FIG. 5A is an exemplary table illustrating a simplified example of how this check in PRP3 may work. The CPT code for which a price is being sought is 11042. Count refers to the number of times a particular charge amount is associated with the CPT code in question. The charge amount with the highest frequency is $775 (would be computed in step PRP1). The charge amount at the 75th percentile is also $775 (computed in step PRP2). The two values are compared in step PRP3, and as they are equal, the $775 value is assigned toCPT code 11042. - Returning to
FIG. 4 , if the two charge amounts are not equal (NO at PRP3), the routine checks whether 50% or more of the dataset is a common charge amount (PRP4). If it is (YES at PRP4), then that common charge amount is returned (PRP7).FIG. 5B is an example of the application of this rule to a simplified dataset. As inFIG. 5A , the routine is searching for a charge amount associated withCPT code 11042. In this example dataset, $775 has a frequency percentage (50%) at least equal to or greater than 50%. Thus, there would be a YES at PRP4, and the charge amount returned would be $775. - If there is not a common charge having 50% or more of the total number of entries in the dataset (NO at PRP4), a check is made of the total size of the dataset (PRP5). In one embodiment, this check involves checking whether the size of the dataset is >50. If the sample is of insufficient size (NO at PRP5), an appropriate return is made, for example “not available” or the null set (PRP6). If the sample is of sufficient size (YES at PRP5), the frequencies of each charge amount in the dataset is computed (PRP 10), along with the percentages of the total. For example, if a particular charge amount has a frequency of 2 out of a dataset size of 10, the percentage would be 20%. Next, a check is made to determine if the highest percentage amount is greater than 25%. If not, (NO at PRP11), the process proceeds to calculate weighted averages (PRP15), which will be described further later. If there is a frequency with a percentage >25%, the routine then checks if there is another charge amount with the same percentage as the highest one (PRP12). If there is, then “not available” or the null set is returned (PRP6). This is because there exists more than one charge amounts which could presumptively be the actual charge amount, and the routine does not have enough data to prefer one over the other. If there is not another charge amount with a frequency equal to the frequency of the highest charge amount (NO at PRP12), a check is made as to whether there is more than one charge amount with a frequency percentage greater than 25%. If there is no such charge amount with a frequency percentage greater than 25% (NO at PRP13), “not available” or the null set is returned (PRP6). If there is more than one charge amount having a frequency greater than 25% (YES at PRP13), the frequency percentage of the highest frequency charge amount is subtracted from the frequency percentage of the second highest frequency charge amount (PRP14). If this subtraction yields a number greater or equal to 10% (YES at PRP14), the higher charge amount is returned (PRP7). If the number is less than 10 (NO at PRP14), the weighted average charge price of the CPT code for the particular healthcare organization is calculated (PRP15), and this weighted average returned along with other indicia representing the result is flagged (PRP9). The result is flagged because it is an amount is not based on frequencies, and thus may not actually ever have been charged by the particular healthcare organization.
-
FIG. 5C ,FIG. 5D , andFIG. 5E show examples of the application of the logic of shown in steps PRP10 through PRP14. The simplified datasets shown with respect toFIG. 5C , 5D, and 5E would have progressed through logic shown preceding PRP10 (there would have been no computed common charge amount figured for these datasets).FIG. 5C shows a dataset having a highest frequency charge amount higher than 25% (YES to step PRP11 inFIG. 4 ). There is no other charge amount with a frequency equal to 25 (NO to step PRP12 inFIG. 4 ). Further, there is no other charge amount with a frequency greater than 25% (NO at step PRP13 inFIG. 4 ). Thus, charge amount $775 is returned (at step PRP7 inFIG. 4 ). - Turning to
FIG. 5D , the example numbers show there is an amount having a frequency greater than 25% (YES atstep PRP1 1 inFIG. 4 ). And there are in fact two numbers having the same charge amount frequency (the first for $775, the second for $985) (YES at step PRP12 inFIG. 4 ). Thus, a dataset synonymous with “not available” is found (step PRP6 inFIG. 4 ). - Turning to
FIG. 5E , there are two charge amounts with a frequency above 25% of the total (YES at step PRP11 inFIG. 4 , and NO at step PRP12 inFIG. 4 ). Since there is more than one charge amount with a frequency greater than 25% (YES at step PRP13), a check is made as to whether the difference in percentage between the frequencies of the two highest frequencies is at least 10%. Since in this case $775's 39% is 12 points greater than $985's 27%, and 12 is greater than 10 there is a YES at step PRP14 inFIG. 4 , and the $775 charge amount is returned (step PRP7 inFIG. 4 ). -
FIG. 6 is a flowchart showing an exemplary manner in whichuser 10, who in this particular case is a consulting company, may interact with the CPTprice master database 16, viaoptimizer engine 11, and in turn via one of the several interfaces into CPT pricing system (in this particular example web server 3). For the sake of example and not limitation, this process presumes CPTprice master database 16 has already been populated using logic described above. One skilled in the art will recognize that the process and system could be architected to do CPT analysis of the type mentioned above real-time, and thus nullify the necessity of the CPT price master database. This is merely a system design consideration: where speed is paramount it may make sense to architect CPT pricing system 9 with CPTprice master database 16 populated as an extract fromMedPAR database 15. First, consultant logs onto web server 3 (WEB1). This may involve, for example, authentication. Next, a group of peer companies against which a particular healthcare organization (with respect to this FIG. this would be the customer) is to be analyzed is determined (WEB2). In one embodiment, an initial selection of peer companies is computed and suggested touser 10. The population of peer companies is determined based on the following criteria: - Geographical Area: Within an area (up to 60 mile radius) from the customer.
- Bed Size: Facilities of similar bed size.
- Revenue Size: Facilities that have a similar revenue.
- Level of services: Compare facilities that perform similar services as the customer.
- Once the peer companies have been selected, the customer's chargemaster, or germane portions of it (perhaps just a single CPT code), are uploaded to CPT pricing system 9. Analysis is done, and the consultant receives a benchmark report (WEB4) showing how the customer compares, in various aspects, to one or more peer companies.
- Though described with respect to MedPAR data, the same or similar concepts described above could be applied to any data that defines multiple charge amounts charged for a particular procedure.
- The foregoing description of various embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Obvious modifications or variations are possible in light of the above teachings. The embodiment was chosen and described to provide the best illustration of the invention and its practical application to thereby enable one of ordinary skill in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. All such modifications and variations are within the scope of the invention as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly, legally and equitably entitled.
- All features and limitations presented in, or found to be in this application (including the claims), are intended to be open-ended limitations, unless the term ‘consisting of’ is explicitly used.
Claims (16)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/744,556 US8073709B2 (en) | 2007-05-04 | 2007-05-04 | CPT pricing from MedPAR data |
PCT/US2008/058081 WO2008137222A1 (en) | 2007-05-04 | 2008-03-25 | Cpt pricing from medpar data |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/744,556 US8073709B2 (en) | 2007-05-04 | 2007-05-04 | CPT pricing from MedPAR data |
Publications (2)
Publication Number | Publication Date |
---|---|
US20080275724A1 true US20080275724A1 (en) | 2008-11-06 |
US8073709B2 US8073709B2 (en) | 2011-12-06 |
Family
ID=39940219
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/744,556 Active 2029-11-04 US8073709B2 (en) | 2007-05-04 | 2007-05-04 | CPT pricing from MedPAR data |
Country Status (2)
Country | Link |
---|---|
US (1) | US8073709B2 (en) |
WO (1) | WO2008137222A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11600391B1 (en) * | 2019-05-28 | 2023-03-07 | Joanne Rodriques-Craig | Classifying and grouping service descriptors from health provider chargemasters |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10339532B2 (en) * | 2006-08-10 | 2019-07-02 | Medcom Solutions, Inc. | System and method for uniformly pricing items |
US11887170B1 (en) | 2018-07-11 | 2024-01-30 | Medcom Solutions, Inc. | Medical procedure charge restructuring tools and techniques |
US11922471B1 (en) * | 2018-11-28 | 2024-03-05 | Unitedhealth Group Incorporated | Automated data routing and comparison systems and methods for identifying and implementing an optimal pricing model |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4667292A (en) * | 1984-02-16 | 1987-05-19 | Iameter Incorporated | Medical reimbursement computer system |
US4831526A (en) * | 1986-04-22 | 1989-05-16 | The Chubb Corporation | Computerized insurance premium quote request and policy issuance system |
US5235507A (en) * | 1990-01-16 | 1993-08-10 | P. B. Toau And Company, Ltd. | Health insurance management system |
US5446653A (en) * | 1993-05-10 | 1995-08-29 | Aetna Casualty And Surety Company | Rule based document generation system |
US5523942A (en) * | 1994-03-31 | 1996-06-04 | New England Mutual Life Insurance Company | Design grid for inputting insurance and investment product information in a computer system |
US5652842A (en) * | 1994-03-01 | 1997-07-29 | Healthshare Technology, Inc. | Analysis and reporting of performance of service providers |
US6014632A (en) * | 1997-04-15 | 2000-01-11 | Financial Growth Resources, Inc. | Apparatus and method for determining insurance benefit amounts based on groupings of long-term care patients with common characteristics |
US6163770A (en) * | 1998-08-25 | 2000-12-19 | Financial Growth Resources, Inc. | Computer apparatus and method for generating documentation using a computed value for a claims cost affected by at least one concurrent, different insurance policy for the same insured |
US20040243438A1 (en) * | 2001-06-28 | 2004-12-02 | Ilan Mintz | Method and system for cost analysis and benchmarking in the healthcare industry |
US6959429B1 (en) * | 2000-05-16 | 2005-10-25 | Watterson-Prime Software, Inc. | System for developing data collection software applications |
US20060143042A1 (en) * | 2004-12-28 | 2006-06-29 | Cerner Innovation, Inc. | System and method for cost accounting in a healthcare environment |
-
2007
- 2007-05-04 US US11/744,556 patent/US8073709B2/en active Active
-
2008
- 2008-03-25 WO PCT/US2008/058081 patent/WO2008137222A1/en active Application Filing
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4667292A (en) * | 1984-02-16 | 1987-05-19 | Iameter Incorporated | Medical reimbursement computer system |
US4831526A (en) * | 1986-04-22 | 1989-05-16 | The Chubb Corporation | Computerized insurance premium quote request and policy issuance system |
US5235507A (en) * | 1990-01-16 | 1993-08-10 | P. B. Toau And Company, Ltd. | Health insurance management system |
US5446653A (en) * | 1993-05-10 | 1995-08-29 | Aetna Casualty And Surety Company | Rule based document generation system |
US5652842A (en) * | 1994-03-01 | 1997-07-29 | Healthshare Technology, Inc. | Analysis and reporting of performance of service providers |
US5523942A (en) * | 1994-03-31 | 1996-06-04 | New England Mutual Life Insurance Company | Design grid for inputting insurance and investment product information in a computer system |
US6014632A (en) * | 1997-04-15 | 2000-01-11 | Financial Growth Resources, Inc. | Apparatus and method for determining insurance benefit amounts based on groupings of long-term care patients with common characteristics |
US6163770A (en) * | 1998-08-25 | 2000-12-19 | Financial Growth Resources, Inc. | Computer apparatus and method for generating documentation using a computed value for a claims cost affected by at least one concurrent, different insurance policy for the same insured |
US6959429B1 (en) * | 2000-05-16 | 2005-10-25 | Watterson-Prime Software, Inc. | System for developing data collection software applications |
US20040243438A1 (en) * | 2001-06-28 | 2004-12-02 | Ilan Mintz | Method and system for cost analysis and benchmarking in the healthcare industry |
US20060143042A1 (en) * | 2004-12-28 | 2006-06-29 | Cerner Innovation, Inc. | System and method for cost accounting in a healthcare environment |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11600391B1 (en) * | 2019-05-28 | 2023-03-07 | Joanne Rodriques-Craig | Classifying and grouping service descriptors from health provider chargemasters |
Also Published As
Publication number | Publication date |
---|---|
WO2008137222A1 (en) | 2008-11-13 |
US8073709B2 (en) | 2011-12-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11321631B1 (en) | Artificial intelligence, machine learning, and predictive analytics for patent and non-patent documents | |
US10540375B2 (en) | Systems and methods for self-pairing databases | |
US9563662B2 (en) | Detecting and processing cache hits for queries with aggregates | |
US9202170B2 (en) | Systems and methods for contextual recommendations | |
US10163147B2 (en) | Systems and methods of location based merchant recommendations | |
US8838490B2 (en) | Associate memory learning for analyzing financial transactions | |
US20160034578A1 (en) | Querying medical claims data | |
US20200242615A1 (en) | First party fraud detection | |
WO2008134707A2 (en) | Product affinity engine and method | |
Krishnamoorthy | Efficient mining of high utility itemsets with multiple minimum utility thresholds | |
US20080255865A1 (en) | Using Relationships Between Master Data and Transactional Data to Process Business Documents | |
US8782083B1 (en) | Dynamic sourcing | |
US9275125B1 (en) | System for organizing data from a plurality of users to create individual user profiles | |
US20210191953A1 (en) | Universal repository for holding repeatedly accessible information | |
US8073709B2 (en) | CPT pricing from MedPAR data | |
US8799327B2 (en) | System, method and computer program product for deriving commonalities among data entries | |
US11675848B2 (en) | Optimizing response creation and delivery for lending queries | |
US10621206B2 (en) | Method and system for recording responses in a CRM system | |
Dhurandhar et al. | Big data system for analyzing risky procurement entities | |
JP7011552B2 (en) | Ad management system, ad management method, and ad management program | |
US20150278723A1 (en) | Dimensional multi-level scale for data management in transactional systems | |
Chiang et al. | A data quality framework for customer relationship analytics | |
Zhang et al. | Improving Performance of E-Government System from the User Perspective | |
Anderson et al. | Streaming Data in the Age of Big Data | |
Sampaioa et al. | DQ 2 S-A Framework for Data Quality-Aware Information Management |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: 3M INNOVATIVE PROPERTIES COMPANY, MINNESOTA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MORENO, PAUL W.;BARCLAY, STEPHEN K.;KOBYLNIAK, YURI P.;REEL/FRAME:019428/0986 Effective date: 20070608 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
CC | Certificate of correction | ||
FPAY | Fee payment |
Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 12 |
|
AS | Assignment |
Owner name: SOLVENTUM INTELLECTUAL PROPERTIES COMPANY, MINNESOTA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:3M INNOVATIVE PROPERTIES COMPANY;REEL/FRAME:066444/0535 Effective date: 20240201 |