In another post, I mentioned two ways that I imagined a provider might be able to determine the expected plan payment, patient's co-payment, and any contract write-off adjustment... before submitting a live claim. This comes up frequently with eyeglass scenarios in which the patient may want to choose between several lens configurations with different features and different total co-payments. The patient's total co-payment for the "eyeglass order" may not simply be the sum of the co-pays for each coded lens feature.. it's more often determined by complex logic that considers all of the other attributes of the eyewear order, and possibly the wholesale or retail price of a "base" or "standard" configuration.
One way I have visualized the Optometrist handling this is to retrieve all of the plan's adjudication logic in the form of coded eligibility terms and values. These parameters could be returned in a 271 for a specific plan (after the vision industry defines these terms and creates standard codes, of course). Armed with the plan-specific rules, the provider's system should be able to predict pricing locally for any conceivable combination of eyeglass variables. If the provider system was not that capable, however, an alternative would be to send out 5 or 6 "pricing query" 837s corresponding to each eyeglass configuration the patient was considering... and let the plan apply its rules and return "pricing query response" 835s. This would have to be a "real-time" process and I suppose the Optometrist would have to utilize the Dental 837 for this purpose, because it is enabled with a flag for use as a pricing query. Does anyone foresee problems with either approach to pricing? Can you think of an easier/better way? Thanks, Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
