Regence
Technical documentation for integrating with Regence through Noyo
API | Snapshot |
COBRA | Supported |
Geographies | All |
Group Size | At least 50 subscribed employees. Fewer than 50 employees supported if the group does not have dental coverage. |
Lines | Dental, medical, vision |
Name | Regence |
Network | Send |
New Group Connection Time | 6–8 weeks |
Prod ID | 2cabb3fe-9c6a-4c2d-a07c-5b69b878fdb |
Group connections
Create a group connection request to manage groups through Noyo. In the group_data
object for the create endpoint, use Regence’s group ID (also called the master agreement number) for the carrier_group_id
. The format expected is a numeric string.
Sandbox testing
Use the following special Regence carrier_group_id
s to simulate different group connection statuses. Test group connections with these IDs will asynchronously update with the corresponding status within 10 seconds of submission.
Only the first three characters are evaluated to figure out the target status (e.g. 989 means noyo_review
). Since group connections should be unique by a carrier ID and carrier group ID combination, you may use the final characters to iterate and test this interaction further.
Test ID Pattern | Resulting Status |
---|---|
989*** | noyo_review |
767*** | waiting_on_carrier |
545*** | action_required |
323*** | unable_to_connect |
212*** | move_to_carrier_authorization |
Carrier configurations
Dynamic config is recommended for all new Noyo integrations and makes carrier-specific config values no longer required.
Group, plan, and member configurations are where Noyo shares and receives details that are unique to a carrier. Every other part of Noyo’s payloads are standardized, but the configurations hold the unique fields and classifications that change from connection to connection. As part of preparing to connect to a new carrier, you need to understand the contents of each configuration and be sure your system is able to send the required data for each member.
Get the group configuration from Noyo
The group carrier configuration endpoint returns information about how the group is labeled and categorized within the carrier’s system. You can also see this data in the Command Center on a group’s detail page by clicking one of their carrier connections.
Regence groups will be configured with a master_agreement_number
string, which is the primary group identifier, along with a list of one or more subgroups
(4 digit numeric code) and one or more benefit_classes
(4 digit numeric code) to categorize employees enrolling in coverage.
Get the plan configuration from Noyo
The details in the plan configuration should be used to map each Noyo plan to the corresponding plan in your own system. Importantly, each plan configuration has details about which populations are connected to an individual plan. Groups with multiple populations may link a plan with one or more of them.
Some Regence plans are only available for employees in certain benefit classes. Regence plans will include a plan_configuration
****block with benefit_class_identifiers
and subgroup_identifiers
fields containing lists of string identifiers. The benefit class identifiers and subgroup identifiers will match the benefit classes and subgroups in the group’s carrier configuration respectively, and describe which benefit classes and subgroups are eligible to enroll in the plan.
Send the member configuration to Noyo
Each member snapshot sent to Noyo can contain a configuration section. Depending on each carrier’s requirements, you may need to use this section to include carrier-specific identifiers like classes, subdivisions, or bill groups. These go in the coverage block’s carrier_config
section and ensure that members are enrolled in the correct coverages. Member snapshots missing a carrier_config
section or with incorrect config data will result in a 422 error.
Snapshots with Regence coverage may include an optional benefit_class_identifier
or subgroup_identifier
that matches the corresponding values in the group carrier configuration.
If the caller omits any values included for the plan, Noyo will attempt to resolve the correct identifier cases where only one option is available for the employee.
Carrier-specific requirements
Validations
Noyo will validate the following based on the member carrier configuration:
- The subgroup specified is valid for the group
- The benefit class specified is valid for the group
- The provided benefit class identifiers and subgroup identifiers are valid for the plans specified in the relevant coverages
- Requests to add or modify coverage contain plans that are available to the subgroup and benefit class fields specified
COBRA
To send a COBRA request, follow the COBRA guidelines outlined in our developer docs.
When a member is enrolled in COBRA coverage, Regence requires a COBRA qualifying event reason to be sent in the qualifying_event_reason
**of the cobra_details
**block.
Connection Basics
Getting groups connected
Once you submit a group connection request, Noyo will kick off the process with Regence by emailing DL-FullyInsuredEnrollmentAutomationSupport@regence.com. Regence will then assign an analyst, and share a Trading Partner form that must be completed by you and the group. After the form is complete, Regence and Noyo will begin building the group’s connection. We’ll manage testing with the carrier and return member-level discrepancies for your review. Regence requires all data discrepancies to be corrected before going live.
This process is the same for groups that are net-new to Regence or have existing coverage.
Processing member changes
If you make changes directly with Regence while Noyo is managing the group, you also need to update your system with those changes so they are sent to us for inclusion on the file. Otherwise, the file we send will overwrite the changes.
File delivery and discrepancy reporting
Once a group has been approved for production by the carrier, transactions will be queued and delivered via EDI file to Regence on a weekly cadence.
Regence will return a discrepancy report to your specified contact weekly, 1-2 business days after Noyo delivers the EDI file. Reporting contacts will be established when the connection is set up.
Regence may flag some changes (such as COBRA enrollments) for review and take longer to process them. These changes will be indicated in the “manual” tab of your Regence error report.
Managed changes
The following types of changes are not included on the file and will be managed by Noyo through the carrier’s preferred method. Processing times for these changes may be longer:
- Changes to effective dates
- Changes to terminated members and enrollments
- Changes to prior plan years
- Changes effective +/- 60 days from current date
Regence requests that the group communicate these changes to their membership team directly, in addition to sending on the file. Noyo will send changes we receive as allowed by Regence, but Regence may not process without communication from the group.
Dependent requirements
Paperwork for dependents over age 26 and for Qualified Medical Support Orders must be sent directly to Regence’s membership team.
Open enrollment
Regence has a blackout period before the renewal once OE enrollments are sent. Noyo will handle current-year changes during the blackout window, but processing times for these changes may be longer.
Regence does not allow changes to EDI vendors concurrently with OE. If transitioning an existing group to Noyo, current year files must be in production at least 2 weeks before OE or the transition must follow OE in the new plan year.
Was this page helpful?