Replies: 4 comments 10 replies
-
|
Most of our facility contracts use code ranges for determining rates. These can any combination of Revenue codes, ICD10 Procedure codes and ICD10 Diagnosis codes. This is referred to as a Hierarchy in our system For each code type there can be zero to many codes specified. For 1 single contracts Inpatient Hierarchy which has 251 combinations, expanding these code combinations out so each possible combination of Revenue code, Procedure code and Diagnosis code specified is an 8,031,262 row result set. It's common to list a range of Revenue codes 100-219 (room and board) along with a Procedure code or range of Procedure codes. Not all combinations of the 88 Revenue codes in the range would be expected to ever be submitted for a given procedure code. From a pricing perspective what the ranges really mean is if the revenue code is in the range 100-219 and the procedure code is in the range specified then this is the allowed rate. Being able to report 251 rates would be much preferable that reporting 8,031,262 rates, |
Beta Was this translation helpful? Give feedback.
-
|
Horizon blue cross of NJ would be interested in ranging/grouping multiple codes into a code set as well. This is a major roadblock for our development of MRF due to the size of the codes that would be returned when trying to list each and every individual code. Our database is unable to support processing of this volume. An example is we have a code group for diagnosis codes which has 1000+ diagnosis codes that all price with the same allowance amount. Without an array or a reference table that can mimic the groups of codes we have internally, we will end up with billions of records (the example provided isn't the only logical grouping we have, we have many different types of groups spanned across procedure codes, revenue codes, DRG codes, etc) with the same allowance amount across all our pricing arrangements. Kindly review and assist! |
Beta Was this translation helpful? Give feedback.
-
|
I agree, even we have the same situation. Today when the pricing is defined
with a group of codes similar to the example defined above with rev codes
and cpt codes, we are reporting pricing based on the cpt and adding all the
rev code information into the additional information node and that would be
difficult for anyone trying to consume our data, but with the current
schema we don't have any other option. In more complex scenarios there are
more code types and ranges that may be defined to identify the applicable
pricing and we are pulling all this information into additional information
node with our own custom formatting within this node.
So, allowing code ranges and grouping of various code types that share the
same pricing amount and provider grouping would drastically reduce file
sizes, be more effective and easier for the consumers of the MRF too.
…On Fri, 1 Apr 2022, 02:10 Jeffrey Li, ***@***.***> wrote:
Horizon blue cross of NJ would be interested in ranging/grouping multiple
codes into a code set as well. This is a major roadblock for our
development of MRF due to the size of the codes that would be returned when
trying to list each and every individual code. Our database is unable to
support processing of this volume.
An example is we have a code group for diagnosis codes which has 1000+
diagnosis codes that all price with the same allowance amount. Without an
array or a reference table that can mimic the groups of codes we have
internally, we will end up with billions of records (the example provided
isn't the only logical grouping we have, we have many different types of
groups spanned across procedure codes, revenue codes, DRG codes, etc) with
the same allowance amount across all our pricing arrangements.
Kindly review and assist!
@shaselton <https://github.com/shaselton>
—
Reply to this email directly, view it on GitHub
<#405 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIJ2FFMOGH7ZXLQLZ7VELP3VCYEVFANCNFSM5PWHPBXQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: <CMSgov/price-transparency-guide/repo-discussions/405/comments/2481298
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
We have a Lot of DME contracts where the rates for HCPCS are specified by Range e.g. L Codes 110% medicare A Codes 90% of medicare, if medicare rate not published 75% of charges. |
Beta Was this translation helpful? Give feedback.
-
|
Have you received any guidance on this? Almost all of our contracts are built on this type of logic, with (for example) Lab at 100% of Medicare, DME at 110%, etc. I not only don't see guidance on how to create the "% of Medicare", but also on how to handle code ranges. Blowing this out into a code by code basis is unrealistic given the scope. |
Beta Was this translation helpful? Give feedback.
-
|
No guidance received I have several issues open, no responses. the one related to Place of Service got closed by someone who did not understand the issue at all. |
Beta Was this translation helpful? Give feedback.
-
|
I would also like to see ranges for the POS code on professional claims. Our system has not been able to handle the volume of records when producing a record for every CPT code and every POS value. |
Beta Was this translation helpful? Give feedback.
-
|
Are you then having to create a separate record for each of the other service codes outside of 21, 22 and 23? This is what we're trying to avoid. |
Beta Was this translation helpful? Give feedback.
-
|
I think you need to create a set number of arrays of the POS combos available to you. Say (21,22,23) in array 1, and then "all others" in array 2. You would then have 2 sets of data dumped based on each of the 2 arrays. You don't have to have every POS mapped to every CPT. |
Beta Was this translation helpful? Give feedback.
-
|
No. The 21,22,23 rate has 21,22,23 for the service code array. The other rate has 01,02,03,04,05,06,07,08,09,11,12,13,14,15,16,17,18,19,20,24,25,26,31,32,33,34,41,42,49,50,51,52,53,54,55,56,57,60,61,62,65,71,72,81,99 as the service code array. Two rates for the provider for a given procedure code. |
Beta Was this translation helpful? Give feedback.
-
|
The main point though is that the large majority of professional contracts don't differentiate rates by POS, so for the minuscule percentage that do have differentials, the large majority have to have an array of about 50 POS tacked on to every rate in the contract. Which does not make sense, its like having a mandatory field in a structure that describes a Mammal, to specify if it is egg laying to accommodate a platypus. |
Beta Was this translation helpful? Give feedback.
-
|
Not disagreeing at all. In addition to POS codes we have rates that are determined by ranges of 1 or more of Revenue Codes, Procedure Codes (CPT/HCPCS and ICD10) and ICD Diagnosis codes. Generates lots of data. So there are multiple places ranges of codes would help. |
Beta Was this translation helpful? Give feedback.
-
Introducing a "FROM" and "THRU" range for billing_code might help reduce the record count only when applicable. Payers do use code ranges to represent services
Beta Was this translation helpful? Give feedback.
All reactions