Issue with CodeGroupNum benefit POST

[dothestew]

Hello,

Let me preface this by saying it's very possible I'm using Code Groups in a way other than intended. If I am, I hope the functionality is embraced rather than removed because it can be really useful. I believe the same goal can be accomplished via coverage categories, but it's not nearly as elegant. I've seen other posts about issues sending AgeLimit payloads for CodeGroupNum, and I'm not sure if that was resolved or not, but this seems to be a similar issue.

I'm trying to send a payload that adds a coinsurance percentage for a Code Group I've set up for occlusal guards. The result is below:

Code: Select all

--- FAILED BENEFIT ADDITIONS ---
Payload: {'BenefitType': 'CoInsurance', 'CodeGroupNum': 18, 'Percent': 100, 'TimePeriod': 'CalendarYear', 'CoverageLevel': 'None', 'Quantity': 0, 'QuantityQualifier': 'None', 'PlanNum': 20677}
Error: API Error.
Status Code: 400
Response: "CodeGroup invalid. BenefitType must be Limitation."

While the API imposes the restriction that the BenefitType must be Limitation, the software itself does not. I'm able to add the benefit through the family module without issue. A GET on that benefit entry is listed below:

Code: Select all

Found matching API benefit for Nightguard Coinsurance:
{'BenefitNum': 331852,
 'BenefitType': 'CoInsurance',
 'CodeGroupNum': 18,
 'CodeNum': 0,
 'CovCatNum': 0,
 'CoverageLevel': 'None',
 'MonetaryAmt': -1.0,
 'PatPlanNum': 0,
 'Percent': 100,
 'PlanNum': 20677,
 'Quantity': 0,
 'QuantityQualifier': 'None',
 'SecDateTEdit': '2025-06-16 21:45:58',
 'SecDateTEntry': '2025-06-16 21:45:58',
 'TimePeriod': 'CalendarYear',
 'procCode': ''}

Hopefully it turns out that this restriction is arbritrary and/or unintended and can be adjusted. If I'm making a syntax error and the issue is on my end, that wouldn't surprise me either. Just looking for some information so I can decide how to move forward. Thanks in advance.

This is with versions 25.1.16.0 and 25.1.35.0

[justine]

Hello,

Let me preface this by saying it's very possible I'm using Code Groups in a way other than intended. If I am, I hope the functionality is embraced rather than removed because it can be really useful. I believe the same goal can be accomplished via coverage categories, but it's not nearly as elegant. I've seen other posts about issues sending AgeLimit payloads for CodeGroupNum, and I'm not sure if that was resolved or not, but this seems to be a similar issue.

I'm trying to send a payload that adds a coinsurance percentage for a Code Group I've set up for occlusal guards. The result is below:

Code: Select all

--- FAILED BENEFIT ADDITIONS ---
Payload: {'BenefitType': 'CoInsurance', 'CodeGroupNum': 18, 'Percent': 100, 'TimePeriod': 'CalendarYear', 'CoverageLevel': 'None', 'Quantity': 0, 'QuantityQualifier': 'None', 'PlanNum': 20677}
Error: API Error.
Status Code: 400
Response: "CodeGroup invalid. BenefitType must be Limitation."

While the API imposes the restriction that the BenefitType must be Limitation, the software itself does not. I'm able to add the benefit through the family module without issue. A GET on that benefit entry is listed below:

Code: Select all

Found matching API benefit for Nightguard Coinsurance:
{'BenefitNum': 331852,
 'BenefitType': 'CoInsurance',
 'CodeGroupNum': 18,
 'CodeNum': 0,
 'CovCatNum': 0,
 'CoverageLevel': 'None',
 'MonetaryAmt': -1.0,
 'PatPlanNum': 0,
 'Percent': 100,
 'PlanNum': 20677,
 'Quantity': 0,
 'QuantityQualifier': 'None',
 'SecDateTEdit': '2025-06-16 21:45:58',
 'SecDateTEntry': '2025-06-16 21:45:58',
 'TimePeriod': 'CalendarYear',
 'procCode': ''}

Hopefully it turns out that this restriction is arbritrary and/or unintended and can be adjusted. If I'm making a syntax error and the issue is on my end, that wouldn't surprise me either. Just looking for some information so I can decide how to move forward. Thanks in advance.

This is with versions 25.1.16.0 and 25.1.35.0

Hello dothestew,

Thanks for the thorough write-up. Codegroups and benefits are very complex. It's possible Open Dental has seen enhancements in how benefits work in the UI since the API implementation, and the API validation may now be unnecessarily strict. We'll look into this.

Thanks!