Place Of Service Codes #63
-
|
Is there a means by which one could denote a 'Facility' Place of Service vs. a 'Non-Facility' Place of Service rather than denote every qualified place of service code? For nearly all of our contracts the differentiation only seeks to use place of service to define payment as a facility or non-facility similar to Medicare reimbursement (https://www.cms.gov/Research-Statistics-Data-and-Systems/Monitoring-Programs/Medicare-FFS-Compliance-Programs/Recovery-Audit-Program/Approved-RAC-Topics-Items/0108-Facility-vs-Non-Facility-Reimbursement) listing copies? |
Beta Was this translation helpful? Give feedback.
Replies: 16 comments 50 replies
-
|
We have basically the same question around the service codes. There are quite a few service codes that are standard and our rates do not always change based on the service code (same negotiated rate regardless of the place of service). The way that the schema is laid out and described, if we were to report on EVERY place of service code allowed per procedure - the file could contain the same TIN/NPI/Negotiated Rate combination listed out separately for each of the standard pocedure code options. This doesn't seem very efficient for the file. If we are supposed to list out EVERY permeatation of negotiated rate per procedure code per service code, then is there a possiblity that the we could make the service code attribute an array of strings instead of just 1 string value? This would allow us to list out all of the applicable service codes in one record for the same TIN/NPI/Negotiated Rate object. |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense in terms of efficient to allow the mapping of multiple There could be a situation of including an array of Something like: "negotiated_price": {
"negotiated_type": "negotiated",
"negotiated_rate": 123.45,
"expiration_date": "2022-01-01",
"service_code": ["01", "02"]
}Question: Do your contracted/negotiated rates (that are the same) specify that items/services that are provided to providers aren't limited to single It might make sense to turn the service_code into an array if this is a common scenario. |
Beta Was this translation helpful? Give feedback.
-
|
@shaselton , yes, contracts may often be written where the rate is based on an underlying CMS RBRVS fee schedule, those fee schedules specify different weightings for facility vs. non-facility locations. The contracted definitions implies that selected rate will be based on the 'facility' or 'non-facility' weights based on the Place Of Service Code on the profressional claim. |
Beta Was this translation helpful? Give feedback.
-
|
@shaselton However, as there are so many service codes with CMS and potentially, they could all have the same negotiated rate, there was a discussion about the possibility of adding Service_Code as an array so we didn't have so many duplicated rates. There was also talk of possibly just having this at Facility vs Non-Facility. Is there any update to that? Also - I see that in the requirements for Service_Code, it does state 'professional claim', but it says it's required, so are we not needing to put the service code on the Institutional Provider Contract data? I will post this same note to that discussion as well. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, a decision on Place of Service is needed soon. The testing phase of these files is probably about 3 months away for most of us. @shaselton-usds, @shaselton - I did not think about the npi/tin/price uniqueness that is needed if the Place of Service was made an array in it's current location, very good point. I agree moving the field to a position within the negotiated price object works best for my scenario. However I can make either solution work. The most important thing to me is that the field is made into an array - that will drastically reduce the size of the file for both the consumer and producer - a win\win. Does anyone have an idea on when a decision will be made? |
Beta Was this translation helpful? Give feedback.
-
|
@shaselton Following up with the request to make Place of Service an array. My vote is to include an array of service_codes in the negotiated_price object. For example, CPT® billing code 94002 (Ventilation assist and management) may be performed in eight Places of Service (Inpatient, ER, ASC, birthing center, on campus or Indian health or tribal facilities) but may have the same or different negotiated rates. Defining it in the negotiated-price object as an array allows the flexibility to provide different negotiated rates or if they are the same for multiple places of service, it removes the redundancy required by the current definition. |
Beta Was this translation helpful? Give feedback.
-
|
Agree, this has the potential to reduce file sizes by more than a factor of 20+. There appear to be 49 active Place Of Service codes, no contracts we have specify anything other differences for facility place of service vs. non-facility. The increased complexity certainly seems worth it to me. |
Beta Was this translation helpful? Give feedback.
-
|
@shaselton In situations where a different POS does not affect reimbursement, would CMS consider allowing payers to report 00 “Unassigned” or 99 “Other Place of Service”? Or, would CMS consider making the POS optional? |
Beta Was this translation helpful? Give feedback.
-
|
@BobSyracuse @angelamarie0975 @ryan-thomas-peterson @tdfow @taylorpatriciab @angelamarie0975 Sorry for going dark -- CMS was in the middle of developing guidance that includes a delayed implementation of the files for 6 months while dropping enforcement for the Rx machine-readable file. As such, CMS couldn't respond to any discussions until that guidance was released. That said, CMS plans to pick up active discussions with the community to continue to help clarify implementation requirements and overall technical implementation -- these discussions included. Before going dark, turning the Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@mmorri05 Examples updated here: 102801b @Paul-Sousa @jltang-kp The idea would be that the schema reaches v1.0 that would represent final requirements for the time while still allowing for iteration if necessary -- it would allow for the tracking of what information is being produced. |
Beta Was this translation helpful? Give feedback.
-
|
@shaselton-usds Thanks, that helps to know v1.0 is driving for final requirements is the reg is published as of now. |
Beta Was this translation helpful? Give feedback.
-
|
Can we please have the TIN field become an array? It's currently a string. That will help with reducing file size as well. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
@shaselton-usds , @shaselton , As the topic has continued to expand beyond initial scope and promote active discussion, I'm unflagging this as 'answered' until we either address residual needs on a different topic thread or resolve how to handle service_codes on institutional claims here as well. But this improvement was a major step forward! |
Beta Was this translation helpful? Give feedback.
-
|
Making service_code an array is great. Moving it to the negotiated_price object has a side affect. For a given billing code for a given tax id, for a given list of providers that has one rate for service codes 21,22, and 23 and a different rate for all other service codes, requires 2 negotiated rate details objects for the same tin and providers with the different negotiated_price objects needed for the 2 groups of service codes. Making negotiated_price an array eliminates a negotiated rate details object for every billing code affected. We frequently have providers with one set of rates a service codes 21,22,23 and different rates at all other service codes. I have 1 contract that does this and making the negotiated_price an array reduces the negotiated rates for this one contract (TIN) from 121,544 to 60,772 |
Beta Was this translation helpful? Give feedback.
-
|
Did the 121544 count include 1 record for each 21, 22, 23 with the same allowed amount? We have the same scenario, but based on where I see that the array is put for the in network rate file, I am having a hard time visualizing this being an issue. I added an example below which would be correct the way that I am visualizing this. So I could see how it would be cut in half - because instead of 2 separate negotiated rates objects, that is cut to 1 object with 2 different negotiated price arrays. If this array was moved outside of this object, I don't think it would make sense. I am however having a similar issue but on the OON file and the place that the service_code array is put on the OON file doesn't make as much sense there, but I have to research that more before I open a question about that one. For example: |
Beta Was this translation helpful? Give feedback.
-
|
Well - I now understand what you are referring to - I inadvertently was thinking this WAS an array already because all other objects for both INN and OON are arrays, plus the fact that there CAN be different negotiated rates per different service_codes. So I just assumed it was an array - EVEN THOUGH, I can clearly see it was not in the schema. LOL @shaselton-usds was this object discussed as well when the change was made to the service_code array? The way I understand this working would be as below if it was made into an array (example 1). If we don't make it an array, then you can see where we would end up with more duplication of data (example 2). Is this the wrong assumption that I am making? If made an array example: If left AS IS example: |
Beta Was this translation helpful? Give feedback.
-
|
@angelamarie0975 Makes sense now that dynamic information such as |
Beta Was this translation helpful? Give feedback.
-
|
What you have above is essentially what I am after. This is for the in-network file. The service codes were moved to the negotiated price object from the negotiated rate object. The OON still has the service codes in the allowed amounts object instead of the payment object. Also noticed that the OON file has the providers in the payment object instead of the allowed amounts object where the tin is. That's a difference between in0network file which has the tin and the providers array in the negotiated rates object. |
Beta Was this translation helpful? Give feedback.
-
|
Remember to update the Out Of Network JSON example to reflect the array when this topic is closed. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the heads up -- updated. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Scott. |
Beta Was this translation helpful? Give feedback.
-
|
@mmorri05 semantically, it doesn't matter in what order certain elements appear. Strictly speaking, an object is an unordered set of name/value pairs. Both the |
Beta Was this translation helpful? Give feedback.
-
|
@BobSyracuse @angelamarie0975 @ryan-thomas-peterson @tdfow @taylorpatriciab CMS is looking to introduce a contextual attribute to flag whether a negotiated rate is "facility" or "non-facility" as this discussion has been tracking. I want to get your thoughts on a couple things happening on this branch: 70c3ff9 A) Does the location of I'll most likely keep this branch living throughout next week with feedback coming in and also updating the rest of the examples. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
@BobSyracuse , @angelamarie0975 , @tdfow, @taylorpatriciab I'd be happy with it but think it makes sense to change: So that the billing_class is an enumeration list of professional and institutional. These line up with the ANSI specified 837 billing types on which medical claims are provided. Then require service_code if billing_class is professional. |
Beta Was this translation helpful? Give feedback.
-
|
@ryan-thomas-peterson @BobSyracuse @angelamarie0975 @tdfow @shaselton-usds Agree. However, it may be best at the Negotiated Rates Object level, however, as opposed to within the Negotiated Price. And should the enumeration be 'institutional' or 'professional' instead of 'facility' and 'non-facility' to align with the ANSI 837 billing types? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, would want them to be be institutional or professional. Facility vs. non-facility is overloaded with it's use on the professional side and would lead to confusion. The original suggestion was only trying to solve for service_codes on the professional side since we didn't have an array, but we're moving beyond that to try and cover what to do with the field for institutional claims too. Moving things into that negotiated rates object level makes sense for us too. Great suggestions. |
Beta Was this translation helpful? Give feedback.
-
|
If there is going to be a billing_class type field, I agree with the comments of using 'institutional' or 'professional' rather than 'facility' and 'non-facility' |
Beta Was this translation helpful? Give feedback.
-
|
a) Yes it makes sense that it lands there. Only question I would have is since the service_code is now an array, is there a dependency that all the elements in the array type for a billing_class to be either "facility" or "non-facility"? Overall I can see the “facilty” vs “non-facility” making sense in general. Obviously on the Inpatient and Outpatient side of things it won’t matter as all of those services are occurring in a facility so there is only one rate, but for physicians we have 2 rates for them with 1 being if they perform the service in their own office(“Non-Facility” or at a hospital(“Facility”) – not all codes have a difference in pricing for this distinction but we calculate pricing for both (the reasoning behind a difference in price is basically if the service is deemed to need to pay for some the cost of the building/tools then the non-facility rate will be a little higher to help the docs paying their rent whereas the facility version is where its expected we already paid the hospital for that piece already) |
Beta Was this translation helpful? Give feedback.
-
|
A. Would this billing_class be required? Your updated schema suggestions is implying that when the rate is for a facility, that there isn’t the notion of different rates per service_code. I am finding that when our contracted rates are different, that most of the time, it is because they are performed at a facility and in a lot of cases – like the example below – we pay a different contracted rate when procedure is done in an ambulatory surgical center than when done in a hospital setting. This is an actual example from our file that we have produced - masked NPI/TIN, but this same set of providers have different rates for 99213 procedure code with service_code 11 vs service_codes 19, 21, 22, 23 vs service_code 24. The only non-facility service_code that we have a contract for is the 11, the other service codes are all for facility. If we add the billing class - I am not sure about where to include the billing_class. I think this is where you are proposing it to be added. If so, this can work, but for us, it’s just an extra attribute, because we would still need to include the service_codes. Is there possibly some way that we ONLY need to include the service_codes when we actually have different rates per different codes? I know some companies have said their rates are Facility vs Non-Facility and others, like us, do have different rates for different places of service and then we have a rate that applies regardless of place of service and because service_code is required, we have to include EVERY one of the service_codes in the array because technically, that rate would apply to all service_codes. "negotiated_rates": [ |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate the continued discussions and effort to refine the schema, but could this change be considered for a post v1.0.0 release? While the push to 7/1/22 has given us some breathing room, we do have deliverables with rapidly approaching dates and a change like this will put those in jeopardy. I don't expect CMS to cater to our Plan's needs, but I would expect other Plans to be in a similar position. |
Beta Was this translation helpful? Give feedback.
-
|
If I can throw my 2 cents worth in. We do have "non-facility" contracts that have different rates based on service code. Typically 21,22,and 23 or all other service codes. The current schema in the in-network-rates file handles this well. We have opted for facility pricing to use the type of bill code with the leading digit ignored as the service code as these will identify inpatient vs outpatient rates, which can be and are different. Adding the billing classes Facility or Non-Facility would help to identify what those service codes represent as code 11 for example has different meaning for Professional claims (Office) or for Facility Claims (Hospital Inpatient). As a means of identifying what the service codes represent placing billing_class in the Negotiated Price object makes sense. |
Beta Was this translation helpful? Give feedback.
-
|
@angelamarie0975 -- I agree with your statements |
Beta Was this translation helpful? Give feedback.
-
|
@CKreklo Agree that service_code should not be required on facility. The UB-04 Bill Type three-digit alphanumeric code gives three specific pieces of information: First Digit = Type of facility, Second Digit = Type of care, Third Digit = Sequence of this bill in this episode of care. Referred to as a "frequency" code. Providing them as a service_code would unnecessarily complicate providing accurate rates. |
Beta Was this translation helpful? Give feedback.
-
|
First we do have contracts that have rates for a facility provider that are separated by Inpatient and Outpatient (determined by bill type) with carve outs for DRG (Inpatient only), New Born, and ASC. Not all facility providers use DRG. Not all facility providers that use DRG have contracted rates for all DRGs, Not all facility providers have New Born and ASC carve outs. Some facility providers have Outpatient only. That being said it is possible to enter contract pricing for ER services for example with different rates for Inpatient billing because the patient was admitted vs Outpatient billing because the patient was not admitted. At this point a billing class for Institutional / Professional or Facility / Non-Facility can be made to work with no service codes provided for the Facility rates. If we do indeed have a differing rate for a billing code for Inpatient vs Outpatient it will show up in the in network file as 2 different rates for the same tin and will probably be easier to find after the file is created. One note on the UB-04 Bill Type code - actually a 4 digit code with the leading zero excluded from 837 transactions, Idea was to use the leading 0 as the first digit with the type of facility digit and type of care digits to follow thinking a 3 digit code would distinguish these from the professional place of service codes. |
Beta Was this translation helpful? Give feedback.
-
|
@rgouldkc To confirm, are you're ok with not including service codes for the Institutional / Facility rates? |
Beta Was this translation helpful? Give feedback.
-
|
At this time yes. If we do have an issue at some point with 2 different rates for a tin for a billing code I'll deal with it at that time. The issues of how to report percentage discount off billed charges, indicate situations where for a given provider there are different rates based on state or zip code where services are performed are probably a bigger issue I need to deal with. |
Beta Was this translation helpful? Give feedback.
-
|
As I read the original request, I think the intent is to identify Institutional provider contracts separate from Professional provider contracts, much like the UB-04/837I identifies Institutional claims and CMS-1500/837P identifies Professional claims. From that perspective, wouldn't this indicator be better placed in the Providers Object? |
Beta Was this translation helpful? Give feedback.
-
|
But the different claim types are because of the providers that are billing them. If it is a professional claim, then when the claim is processed, you still have to look at the place_of_service code to figure out which setting the procedure was performed in - same with the institutional, needs to be based on the bill-type which can be converted to a place_of_service. You would still have a professional claim be billed for procedures done in a facility. If you put this indicator in the providers object - this is basically classifying that provider as a facility or non-facility, but based on the original question back from April was whether or not we could just simply classify our rates as either the rate when the setting is facility or non-facility instead of listing out all of the place_of_service codes. Based on the link he provided from CMS - it states the same thing - that it's for the setting - not the provider type, so I am not so sure that makes sense in that object since we are not trying to determine if the provider is a facility or not, we are trying to determine what the rate is based on the place of service setting. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with you @angelamarie0975 that I think the initial request was more for a "pseudo service code" that would take the place of listing out 15 different service codes for "facility" under each procedure. However I think moving service code to an array alleviates this to a great extent, and unless the groupings are well-defined it will cause more confusion than it solves. I also agree with @taylorpatriciab that the more useful approach is to separate Institutional (facility) reimbursement from Professional (non-facility). However I also don't think that moving it to the provider is necessarily accurate. It may be best at the Negotiated Rates Object level, however, as opposed to within the Negotiated Price. |
Beta Was this translation helpful? Give feedback.
-
|
@angelamarie0975 , @CKreklow , @taylorpatriciab , @shaselton Yes, the initial request was a means to solve for service_code not being an array on the professional side. I think the current schema solves for this better than my originally proposed fac/non-fac solution and allows the most flexibility. I still think we have an issue of how the service_code object should be filled (or not) as defined on an institutional contract since CMS service_codes are for professional bills. |
Beta Was this translation helpful? Give feedback.
-
|
@ryan-thomas-peterson Agree that service_code object should not be required for institutional contracts. @CKreklow @angelamarie0975 @shaselton-usds @BobSyracuse |
Beta Was this translation helpful? Give feedback.
-
|
That would work. |
Beta Was this translation helpful? Give feedback.
-
|
@angelamarie0975 If the intent is not to identify institutional provider contracts vs professional provider contracts, but to identify the rate based on the place of service, and based on the conversations above, my suggestion aligns with @Paul-Sousa in that it would be simpler to keep the schema as it is. Consideration could be given to adding a value of 'All' to the Service Code Allowed Values to allow for situations where fee schedules in professional contracts apply to all places of service. @CKreklow I agree... if the schema were to separate institutional contracts from professional contracts, the Negotiated Rate Details Object makes sense. |
Beta Was this translation helpful? Give feedback.
-
|
Per the 5010 837 TR3s Loop 2300 CLM05 - Facility Code Value - identifies where services were, or may be, performed - The first and second positions of the Uniform Bill Type Code for Institutional Services or the Place of Service Codes for Professional or Dental Services. Since electronic transactions are not sent the leading zero found on the paper UB it really means 11 for 011x. The UB04 Data Specifications Manual also has general guidelines on what constitutes an inpatient or outpatient claim based on the Type Of Bill code - 11 or 011x being Hospital Inpatient. |
Beta Was this translation helpful? Give feedback.
-
|
@rgouldkc Yes, this would work for us too as long as the description of service_code changed to reflect the need for 3 digits and that it's meaning conditionally needs to be interpreted based on the length of the string. Currently the schema description for the field states: "The CMS-maintained two-digit code that is placed on a professional claim to indicate the setting in which a service was provided". It could be changed to something like the "The CMS-maintained two digit code that is placed on a professional claim to indicate the setting with a service was provided OR the three digit Facility Value Code (with leading 0) for institutional claims to indicate where the facility service was provided" without the need for a schema change |
Beta Was this translation helpful? Give feedback.
-
|
@ryan-thomas-peterson How will that work exactly for the service_code since the 2nd and 3rd digits of the Facility Value Code do not equate to the service codes? I am looking at the Bill Type Codes - Let's say that we have a specific procedure that is contracted with a different rate in the ER, which of those codes would be used for those rates? We have a hospital contract where when the place of service is in 22, 23, 24 (Outpatient, ER, or ASC) then we pay a percentage of billed. If it is 21 (Inpatient) we pay a different rate based on DRG. So, how would we use the 3 digit code for the ER? Can we still use the service_codes if applicable to our company? By using the service codes, we are still able to distinguish between inpatient and outpatient. But if that 3 digit code is made required for a facility instead of the service_code, then that is not going to work for everyone, like us. And if this is made as optional to use one over the other, how will the end user know which code to use if this new attribute is used for 2 different purposes? |
Beta Was this translation helpful? Give feedback.
-
|
@angelamarie0975,I think with the @rgouldkc combined with the above proposal of having a billing_class at the we could have something like the below. The underlying details would be having a set of physicians that go around to IP and OP settings performing knee surgeries - they bill these on professional claims and get different rates depending on if the setting of the service. One of the physician groups (TIN 11-11111111) is owned by a hospital group and bill under the same TIN as the hospital. We have another surgeon group under tin 33-3333333 that just is contracted to support IP surgeries and bills professionally. That takes care of the professional contracts. The first set of physicians is owned by a hospital - they have their own contracted rates for institutional services. And depending if it's billed on an institutional IP claim or OP claim they get different rates. IP is contracted as a DRG and OP is contracted based on CPT where our billing_class is the only thing that defines the designated rate. Here we use the @rgouldkc suggestion to designate the first 3 digits of the 4 digit Type Of Bill that comes on the institutional claim that routes the claim to the IP or OP contract terms. The allowable 3 digit codes (which maybe are optional) could be harvested from here: https://resdac.org/cms-data/variables/bill-type-code The schema would then look like this "in_network": [{ |
Beta Was this translation helpful? Give feedback.
-
|
@shaselton-usds @BobSyracuse @angelamarie0975 @ryan-thomas-peterson @tdfow Including the first three positions of Type Bill for Institutional claims may be adding complication to the schema without adding value to the data. Would defining billing_class as an enumeration list of professional and institutional, then requiring the CMS Service_Codes only when billing_class is 'professional' work for everyone? |
Beta Was this translation helpful? Give feedback.
-
|
To a degree it does, but it does not address different rates for an Institutional provider that has differing rates for Inpatient, Outpatient and ASC for billing codes that might overlap. |
Beta Was this translation helpful? Give feedback.
-
|
@rgouldkc |
Beta Was this translation helpful? Give feedback.
-
|
@shaselton-usds @taylorpatriciab I agree with @taylorpatriciab regarding the Type of Bill, as I don't see how that would add value to the data for the in-network rate file |
Beta Was this translation helpful? Give feedback.
-
|
The suggestion of moving away from the ambiguous terms of 'facility' and 'non-facility' is fantastic. They have been replaced with 'professional' and 'institutional'. It seems that the "type of bill" has the potential ability to be mapped to a Otherwise, allowing the dependency of More information on this issue can be found here: cms.gov/healthplan-price-transparency/resources/technical-clarification |
Beta Was this translation helpful? Give feedback.
-
|
@shaselton-usds is there a target for when the in-network schema will be updated to address the technical-clarification documentation? "CMS added a contextual attribute called "billing_class" to the in-network schema to flag whether a negotiated rate is based on a professional or institutional claim. " |
Beta Was this translation helpful? Give feedback.
-
|
There is a PR currently open here: #270. Keeping it open through tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
In the in-network fee for service example, shouldn't the billing class be 'professional' and 'institutional' instead of facility and non-facility? Also, the institutional billing class should not have a service_codes as they only apply to billing classes of professional |
Beta Was this translation helpful? Give feedback.
-
|
@taylorpatriciab - we do have institutional contracts that have different pricing rules based on the place of service codes. We convert bill types to the standard place of service codes in our system and we use those in our provider contracts. For some of our provider contracts, the rate determinants are based on the place of service codes - ie...inpatient facility rates may differ from the outpatient facility rates - like per diem for inpatient or percent of billed for outpatient. So for these rates, we would include the place of service array when applicable. |
Beta Was this translation helpful? Give feedback.
-
|
@angelamarie0975 Following claims submission standards, the CMS place of service codes are only defined for professional claims and so CMS required it for the professional rates. However, the CMS schema doesn't prevent you from placing a CMS place of service code on institutional rates. |
Beta Was this translation helpful? Give feedback.
The suggestion of moving away from the ambiguous terms of 'facility' and 'non-facility' is fantastic. They have been replaced with 'professional' and 'institutional'.
It seems that the "type of bill" has the potential ability to be mapped to a
service_codefor institutional negotiations -- if that is in fact where negotiations for items/services happen. In addition, institutional claims with different "type of bill"s appear to have different billing codes, which means that a differentIn-Network Objectto cover the item/service based on the institutional negotiation would need be added to the array to address the different rates.Otherwise, allowing the dependency of
service_codeto "prof…