Patent Publication Number: US-2015088535-A1

Title: Multivariate computational system and method for optimal healthcare service pricing

Description:
PRIORITY CLAIMS/RELATED APPLICATIONS  
     This application claims the benefit under 35 USC 119(e) and priority under 35 USC 120 to U.S. Provisional Patent Application Ser. No. 61/881,918, filed Sep. 24, 2013 and titled “A Multivariate Computational System And Method For Optimal Healthcare Service Pricing”, the entirety of which is incorporated herein by reference. 
    
    
     FIELD  
     The disclosure relates generally to a system and method for determining optimal healthcare service pricing. 
     BACKGROUND  
     Price setting in the American healthcare service market is currently an opaque process. Specifically, prices for the same service can vary by tens of thousands of dollars from one hospital to another, based on factors that are entirely unknown to the patient, or in many cases even the practicing physician. 
     Recently, due in part to the Affordable Care Act legislation, there is increasing consumer-driven pressure on healthcare service providers (“providers”) to price their services in a transparent manner, taking into account regional income variability, local demand for the services they provide, and a national ‘baseline’ price, such as that defined by the Center for Medicare Services (CMS). As this pressure increases, and transparency becomes more commonplace, providers who deliver care of a higher quality will find an increased demand for their services, allowing such providers to charge more for their services based on this increased level of quality of care. To date, however, measures of “quality of care” have been hard to come by, and tend to be defined in very limiting terms by the CMS, or in highly general terms by the American Medical Association (AMA). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a healthcare marketplace system that may incorporate a pricing engine; 
         FIG. 2  illustrates more details of a pricing engine that uses an adaptive model; 
         FIG. 3  illustrates a HealthCare Quality Estimation Model of the pricing system; 
         FIG. 4  illustrate an example of a pricing model of the pricing engine; and 
         FIG. 5  illustrates an example of a genetic Programming method for Cost Convergence. 
     
    
    
     DETAILED DESCRIPTION OF ONE OR MORE EMBODIMENTS  
     The disclosure is particularly applicable to a web/cloud based healthcare system in which the healthcare service pricing is provided to members of the healthcare system and it is in this context that the disclosure will be described. It will be appreciated, however, that the system and method has greater utility since the healthcare service pricing model may use a different technique than that described below (and those different techniques are within the scope of the disclosure), the pricing engine may provide pricing information to a third party system, the pricing engine may provide the pricing information using a software as service mode and the system and method described below may be implemented in other manners that are within the scope of the disclosure. 
     The pricing system and method may provide a new model for market clearing dynamics with respect to Health Economic and price equilibrium. For example, the system and method may use a computational process that integrates arbitrary sources of healthcare service price and quality information into a model. The model adapts over time such that the model determines the optimal price for individual or aggregate healthcare service queries based on regional and temporal adjustments, as well as any of a number of service quality metrics. Specifically, since time is the inverse of frequency, the system can easily adapt to a temporal model whereby the number or Frequency (F), as discussed below in more detail, may be a frequency of visits, number of services such as denoted by CPT and or ICD as well as by time stamping the social network comments and reviews. By also incorporating a proprietary, consumer-driven “Request For Quote” (RFQ) methodology, described in co-pending patent application Ser. No. 61/871,195 filed on Aug. 28, 2013 which is incorporated herein by reference, the system and method obtains near real-time feedback from consumers regarding the accuracy of prices established for a given query. 
       FIG. 1  is a healthcare marketplace system  100  that may incorporate a pricing engine system. The healthcare marketplace system  100  may have one or more computing devices  102  that connect over a communication path  106  to a backend system  108 . Each computing device  102 , such as computing devices  102   a,    102   b,  . . . ,  102   n  as shown in  FIG. 1 , may be a processor based device with memory, persistent storage, wired or wireless communication circuits and a display that allows each computing device to connect to and couple over the communication path  106  to a backend system  108 . For example, each computing device may be a smartphone device, such as an Apple Computer product, Android OS based product, etc., a tablet computer, a personal computer, a terminal device, a laptop computer and the like. In one embodiment shown in  FIG. 1 , each computing device  102  may store an application in memory and then execute that application using the processor of the computing device to interface with the backend system. For example, the application may be a typical browser application or may be a mobile application, such as is shown in the example user interfaces in  FIGS. 4-7 . Each computing device may couple to and communicate with the backend system  108  to submit a request for one or more prices for a particular heathcare service and then receive, from the backend system  108 , one or more prices for the particular healthcare service based on the operation of the backend system  108  as described below. 
     The communication path  104  may be a wired or wireless communication path that uses a secure protocol or an unsecure protocol. For example, the communication path  104  may be the Internet, Ethernet, a wireless data network, a cellular digital data network, a WiFi network and the like. 
     The backend system  108  may also have a health marketplace engine  110  and a pricing engine  112  that may be coupled together. Each of these components of the backend system may be implemented using one or more computing resources, such as one or more server computers, one or more cloud computing resources and the like. In one embodiment, the health marketplace engine  110  and the pricing engine  112  may each be implemented in software in which each has a plurality of lines of computer code that are executed by a processor of the one or more computing resources of the backend system. In other embodiments, each of the health marketplace engine  110  and the pricing engine  112  may be implemented in hardware such as a programmed logic device, a programmed processor or microcontroller and the like. The backend system  108  may be coupled to a store  114  that stores the various data and software modules that make up the healthcare system. The store  114  may be implemented as a hardware database system, a software database system or any other storage system. In addition to the client/server type architecture shown in  FIG. 1 , the system may also be implemented on a standalone computer, using a software as a service architecture, implemented within a larger health care provider system and the like. 
     The health marketplace engine  110  may allow practitioners that have joined the healthcare social community to reach potential clients in ways unimaginable even a few years ago. In addition to giving practitioners a social portal with which to communicate and market themselves with consumers, the marketplace gives each healthcare practitioner the ability to offer their services in an environment that is familiar to users of Groupon, Living Social, or other social marketplaces. The pricing engine  112 , in the example shown in  FIG. 1  in which the pricing engine  112  is part of the health marketplace system  110 , allows a user of the health marketplace system to be provide adaptive pricing for healthcare provider services. Furthermore, the pricing model generated by the pricing engine  112  may be adaptive in that the pricing model may be adjusted based on arbitrary sources of healthcare service price and quality information. For example, additional baseline pricing information may include, but not be limited to: health insurance claims data; federal, state and local government healthcare service agencies in addition to Medicare; price information scraped from websites, etc. Possible additional sources of quality information may include, but not be limited to: customer or peer review data; patient outcomes data; federal, state, and local government healthcare service agencies, etc. These types of data sources may include but are not limited to open source data from the American Medical Association Professional Services Directory, Centers for Medicare and Medicade Services such as http://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/Medicare-Provider-Charge-Data/, demographic data such as http://easydbs.com/zipcode-demographics-database, out of pocket costs data such as http://www.fairhealth.org/ and self pay pricing data from the system described in U.S. patent application Ser. No. 14/328,591, filed 7/10/2014, which is incorporated herein by reference. 
       FIG. 2  illustrates more details of a pricing engine  112  that uses an adaptive model and leverages sources of healthcare service price and quality information  114  that may be stored in a store, such as a software or hardware database, that may be collocated with the pricing engine  112  or located remotely from the pricing engine  112 . The pricing engine  112  may further include a pricing model store  112 A and a pricing model adjusting engine  112 B. The pricing model adjusting engine  112 B may, based on at least a currently used pricing model stored in the pricing model store  112 A and sources of healthcare service price and quality information stored in the store  114 , adjust the pricing model. The pricing model store  112 A may be implemented using a data structure in a memory of a computing resource on which the healthcare system is executing, a software or hardware database and the like. The pricing model adjusting engine  112 B may be implemented in hardware or software. In a software implementation, the pricing model adjusting engine  112 B may be a plurality of lines of computer code that may be stored in a computing resource memory and executed by a processor of the computing resource that also implements the healthcare system  108 . In a hardware implementation, the pricing model adjusting engine  112 B may be a programmed hardware device, a microcontroller with microcode, a memory and the like. 
     The pricing engine  112  may provide a system and method for optimal healthcare service price setting. The system incorporates available pricing data from any available sources, and integrates these prices with arbitrary measures of healthcare “quality of service” (QOS). The QOS metrics may be direct measures, such as patient outcome information as reported by the CMS, or indirect (or “proxy”) measures of quality as defined by PokitDok or any other entity. An example of how billing code data, as a proxy measure of quality, may be integrated into optimal price setting is described now. For the pricing model, a set of all healthcare providers may be defined as a sparse matrix, S, represented in coordinate form as [Provider P i , Billing Code C j , Frequency F k ] triples: 
       S=[P i ,C j ,F k ] 
     where: 
     i ∈[1, numProviders] for a number of providers, i;
 
j ∈[1, numCodes] for a number of billing codes, j;
 
k ∈[0,1]
 
     Thus, for each incidence of the sparse matrix, S, there may be a number of providers and a number of billing codes associated with the providers. F k  is the probability that a given provider bills a given CPT for each sevice code and normalized per provider. For example, if a provider, NPI=12345, does two procedures, throat swab and proctology exam, and does 100 throat swabs and 200 proctology exams, that provider would have two entries in the model, which would look like this: [12345, throat_swab_code, 0.333], [12345, procotology_exam_code, 0.667] Further given the above, the system may also calculate the co-currence of the visits and calculate a Probably of visits=Probability(condition I billing_codes) per geo-location which would can also be inferred via the frequency variable F with respect to the CPT services visits. 
     To place the quality-proxy data in the appropriate context for a pricing model, the system and method may define a score for each provider as a multivariate estimator of provider quality: 
       score i =[efficiency i ,reputation i ,legal i ] 
     This allows the pricing system and method to model price as a function of provider quality. Each element of this particular implementation of a score function is described in detail below. Finally, let N represent the set of provider categories as defined in the current (2013) National Provider Identifier (NPI) registry. Then, for all n: 
       p n   ⊂ P; n ∈N
 
     The system and method may employ any suitable classification and regression algorithms to find the maps, x n : The system may use various algorithms including Decision Tree Classifiers, Random Forest Trees, Gradient Boosted Trees, Support Vector Machines or Adapative Neural Networks. The types of regression analysis that may be used may include, but not limited to, Linear Regression, Logistic Regression, Generalized Linear Models. These classifiers and regression models are based on the amount of data or the frequency of data is in this case a data driven process. 
       p n x n =score n    
     These maps define how billing code utilization maps to provider quality, within each of the subsets of NPI-defined provider specialties. 
     Provider Efficiency: 
     In the billing code model described here, efficiency could be defined as the billing accuracy of each individual provider. This measure takes into account the reimbursement/billing ratio, coding error rates, total provider income, and a variety of other meta parameters related to overall provider quality. As described above, if a provider, NPI=12345, does two procedures, throat swab and proctology exam, and does 100 throat swabs and 200 proctology exams, that provider would have two entries in the model, which would look like this: [12345, throat_swab_code, 0.333], [12345, procotology_exam_code, 0.667] 
     Provider Reputation: 
     The PokitDok reputation estimate for providers includes rigorous peer ratings, consumer ratings, board certifications, publications, as well as many other documents that may be indicative of healthcare provider reputation including social media feeds and survey data. For example, given categorical data such as speciality—urology and CPT codes throat swab as 87070, 46600 which are numeric designations are a function of a Current Procedure Terminology (CPT) coding. CPT coding is similar to well-known ICD- 9  and ICD- 10  coding, except that it identifies the services rendered rather than the diagnosis on the claim. The numbers in the example above are merely illustrative with respect to the example of the vector for the graph formatting. 
     Provider Legal: 
     This is modeled as 1—Probability (malpractice), where the probability of malpractice is estimated as an exponential decay from time of last malpractice lawsuit, scaled by total number of malpractice lawsuits filed against a given provider, normalized to the provider&#39;s specialty and region of primary practice. For example, the system may calculate the number of revists given the same estimation model given the above parameters and the data is from the American Medical Association including the rate of malpractice as well as data for suspension of the license and or revocation for a particular provider into the following formula: 
       M(t)=M 0 e −n    
     where M(t)=the frequency of malpractice as at time t, M 0 =initial amount at time t= 0 , r=the decay rate and t=time (number of periods) based on calendar time. Revocation is obviously a binary result where you cannot practice thus immediate null rating. 
       FIG. 3  illustrates a HealthCare Quality Estimation Model  300  of the pricing system. In this model, one or more factors may be used to determine a pricing model for the healthcare service. The one or more factors, grouped together into a vector of numeric values, may include billing efficiency  300  of each provider, a reputation and ranking for each provider  302 , a consumer rating for each provider  304  and materials and resources  306 . Examples of the consumer ratings and materials may be from Social Media as well as Application Programmer Interfaces (APIs) for data and reviews that can be accessed. For example, the system can refer to http://www.yelp.com/biz/doctors-care-charleston-8 for an example of both consumer numeric and sentiment ratings. Further, Yelp provides access to this information via APIs. Sentiment and “likes” can be used as vector inputs into the consumer quality rating as well. These materials could be but are not limited to fascimiles, office notes, or electronic medical record databases. http://advancingyourhealth.org/highlights/2013/03/30//national-doctors-day-2013-emory-healthcare/ and refer to page 124 for examples of these values http://www.elsevieradvantage.com/samplechapters/9781455707201/Sample%20Chapter.pdf which shows the types of information contained in the Electronic Medical Record (EMR), Electronic Health Record (HER) or Practice Management (PM) systems. This allows deep analysis of repeat visits and patients who would not follow physician directives and change the repeat outcomes coefficients. These one or more factors may be fed into a determination of service quality  308  that may be generated by the pricing model adjusting engine, for example. The service quality  308  may then be used to generate the adaptive pricing model  301  that may then be stored in the pricing model store. 
       FIG. 4  illustrate an example of a pricing model of the pricing engine. The pricing model may use request for quote prices  400 , CMS price  402  and external prices on resources and materials  404  to generate a quality of service measure  406  as shown below in the examples. The quality of service measure  406  may then be used to generate one or more pricing models  408 - 412  that may adapt depending on the data. In the method, the pricing model price may be fed back to the RFQ price  400  to form a feedback loop of the method. 
       FIG. 5  illustrates an example of a genetic Programming method for Cost Convergence. Specifically, once the parameters of the vectors are selected, the method may apply various scaling functions. These scaling functions as well as additional variables may be used in production implementations. These non-linear scaling function may be, but are not limited to: Logistic, Gamma, and polynomial. These scaling functions are generated as a function of Quality vs Cost. In order to choose the optimal scaling functions, the system and method may utilize a Genetic Evolutionary Programming methodology to converge on the multivariate scaling functions as shown in  FIG. 5 . We are creating various characteristic functions based on the various equilibrium points between the cost of the service as a function of quality and the requested price from the patient. Due to the multivariate nature of the method and the fact that the genetic programming method converges to a buyer optimality such that each patient maximizes his/her utility subject to their budget constraint based on prior presented information that is contained within our quality metrics. 
     An example of the step by step process flow may be: 
     A. User searches for “Knee Surgery” 
     B. Medicare price for “Lateral Meniscus (Knee) Surgery” in user&#39;s geographic region is known to be $2,500. 
     C. PokitDok “Right Price™” multiplier for “Lateral Meniscus (Knee) Surgery” in user&#39;s geographic region is 3× making PokitDok baseline price $7,500. 
     D. User&#39;s geographic region contains 3 surgeons who can perform the procedure: Doctor A has a reputation score in the 50 th  percentile, an efficiency score in the 50 th  percentile, and a legal score in the 50 th  percentile, resulting in a price exactly equal to the PokitDok baseline of $7,500. 
     E. Doctor B has a reputation score in the 95 th  percentile, an efficiency score in the 95 th  percentile, and a legal score in the 95 th  percentile, resulting in a price of $17,625. 
     F. Doctor C has a reputation score in the 25 th  percentile, an efficiency score in the 25 th  percentile, and a legal score in the 25 th  percentile, resulting in a price of $3,675. 
     Below is a simple example of a direct non genetic programmed linear scaling model for pricing where the physician quality scores are assumed to be represented as percentiles (in [0,1]), with the average score being set at 0.50. Other (i.e. nonlinear) scaling functions as well as additional variables may be used in production implementations. These non-linear scaling function can be but are not limited to: Logistic, Gamma, and polynomial. 
     i) user_geo=PokitDok.get(user_location) 
     ii) user_query=PokitDok.get(user_search_terms) 
     iii) geo_scalar=PokitDok.get_geo_scalar(user_query, user_geo) 
     iv) PokitDok_baseline=average(geo_scalar*[CMS_price, RFQ_price, other_price]) 
     v) PokitDok_Right_Price=PokitDok_baseline *PokitDok.get_Right_Price_scalar(user_query) 
     vi) physician_quality_vector=[reputation_score, efficiency_score, legal_score] 
     vii) num_vars=length(physician_quality_vector) 
     viii) physician_quality_adj=sum((1/num_vars)+(physician_quality_vector−0.5)) 
     ix) PokitDok_Quality_Price=PokitDok_baseline*physician_quality_adj 
     An example of how this simple model would work with a PokitDok_Right_Price of $2,500 for 3 physicians with scores ranging from average (A) to excellent (B) to poor (C): 
     scores_A=[0.50, 0.50, 0.50] 
     PokitDok_Quality_Price_A=2500*(sum ((⅓)+([0,0,0])))= 2500 * 1 =$2,500 
     scores_B=[0.95, 0.95, 0.95] 
     PokitDok_Quality_Price_B=2500*(sum ((⅓)+([0.45,0.45,0.45])))=2500*2.35=$5,875 
     scores_C=[0.33, 0.33, 0.33] 
     PokitDok_Quality_Price_C=2500*(sum ((⅓)+([−0.17, −0.17, −0.17])))=2500*0.49=$1,225 
     As we can see the “Best” Ranking is not the lowest price. Which is the basis for the multivariate rating system. The advantage herewith is the implicit nature of the rating process. 
     While the foregoing has been with reference to a particular embodiment of the invention, it will be appreciated by those skilled in the art that changes in this embodiment may be made without departing from the principles and spirit of the disclosure, the scope of which is defined by the appended claims.