After groups are connected, you’ll want to send snapshots for everyone in the group so Noyo can flag any member-level discrepancies. This also allows you to link the members in your system to any that already exist at the carrier, ensuring that everyone is enrolled in the right coverages and your future demographic and enrollment changes will be processed accurately.
The Noyo id is a member identifier defined by Noyo, and is assigned to each employee and dependent when their record is created in the Noyo system. The custom_individual_id field in the Noyo system is available to store a unique identifier defined by you. Members do not have a custom ID until you assign one. All custom_individual_id values should be unique within each group and fixed so that they will not change over time. Social security numbers should not be used as custom identifiers.

​
Linking overview

When your group connection is complete, you’ll need to link members and dependents. We always recommend sending an initial “census” for newly connected groups by triggering a member snapshot for each employee. If no employees existed with the carrier already, as is typical with net-new groups or Send connections where carrier data is not available, this census will create the group’s employees and dependents in our system. You should include a custom_individual_id for each member; the success responses for your snapshots will contain each person’s Noyo ID, which you should store. Otherwise, if employee records are already in Noyo, as is typical with groups who are moving to Noyo mid-year, you’ll use the custom_individual_id to establish a link between your own records of those members and ours (see below). If you’d like, you can check for employee data before sending the census snapshots by using the Get Group Employee List endpoint.

​
Option 1: Use our automatic member linking feature

This option is recommended
Noyo can attempt to link members in your snapshot payload to members in our system automatically based on demographic details when you use the automatic member linking feature. You can enable it by sending member snapshots with the enable_member_auto_link flag set to true and the custom_individual_id set to your own unique identifier. When a snapshot is sent to Noyo tied to an existing group, we search for that member in the group using a combination of Name, DOB, and SSN. If there is a match, Noyo saves your custom identifier on that member the first time we see it, and any future snapshots with that custom ID will automatically be associated with the linked member. We also recommend saving our associated Noyo ID to use elsewhere in our API. Because it’s likely that your records and the carrier’s records won’t have the exact same data, Noyo’s search algorithm is flexible and does not require strict matching of all demographic information in order to assign a custom ID and create a link. For example, if you have a member’s name as “Jimmy” but it is “James” in our records, we will still match the member as long as the /* glossary */DOB/* glossary */ and /* glossary */SSN/* glossary */ are the same. Sometimes the linking algorithm won’t find a match, most often because the member in the snapshot doesn’t yet exist in Noyo’s records. When there’s not a match, we will create a new member record that’s associated with the custom ID in your submission. Whenever a new member is created, the API response will also include a block highlighting that new member: 
"created_members": [
	{
		"id": "64aef550-ced5-4477-9cdc-26a1f97b5394",
		"custom_individual_id": "123456789",
		"type": "employee"
	}
]
If you didn’t expect the request to create any new members, you can use the response to investigate if the new member should have been created. To resolve a duplicate member, reach out to the Noyo team. Updating a custom ID If you need to update someone’s custom_individual_id, you can send a snapshot for that person that includes both their Noyo id and the new custom_individual_id. We will update the record in our system to associate the person with the new custom_individual_id.

​
Option 2: Use our GET endpoints and Noyo IDs

If you would rather do the work to match and link members in your own system, you can use Noyo’s GET endpoints to retrieve member data and use that demographic information to match Noyo’s records with the members in your system. After matching the members on your side, you can send a snapshot with the Noyo ID and your custom ID, and Noyo will save that association for future use. There are two common strategies for finding and matching Noyo IDs for existing members:
  1. You can attempt to match one member at a time from your system by calling our Get Employee List endpoint, and using the name and date_of_birth fields to filter members. The name field should receive a whitespace-separated combination of a first name, middle name, last name, and suffix, depending on what you have. For example, ?name=Peggy%20C%20Johnson. If multiple employees are returned, you can then compare other data points to select the right employee from a small set of matches.
  2. You can paginate through the Get Group Employee List API endpoint to retrieve a complete census of the group, then write your own algorithm to match the members in your own system.
In either case, we suggest you complete the matching process at the employee level first, then compare and link any dependents under their matched employees.

​
Reconciling linked members

After completing member linking, the next step is to compare your own data to each member’s coverage status at the carrier. This ensures that there are no discrepancies between your systems that could result in rejected changes or customer escalations down the line. Here are some examples of how unreconciled data can affect your customers:
  • If your system has an active coverage that Noyo can’t find at the carrier, it could mean that a member’s enrollment was never processed by the carrier. That member may not be covered when they go to the doctor.
  • If the carrier has an active coverage that’s not in your system, it could mean that a member is accidentally enrolled in coverage they didn’t choose and there could be deduction or billing issues for the member. It’s also possible the enrollment at the carrier is correct, but the member doesn’t realize they have acdcess to these additional benefits.

​
Reconciling Sync groups

After a group connection is complete for a group with a Sync connection, you can choose to do reconciliation on your own by using our GET endpoints to fetch member data and compare it with your own records. Our Get Group Employee List and Get Dependent List endpoints return member demographic information, and our Get Individual Enrollments by Employee endpoint returns coverage information. Each individual enrollment includes an individual_id, individual_type, line_of_coverage, and plan_id that link to the member and plan in Noyo. The API also returns an effective start and effective end date when the coverage is active, and other important details like volume amounts and COBRA status. If you identify any data mismatches, including missing employees or incorrect demographic or coverage data at the carrier, sending a member snapshot with all of their dependent and enrollment information will push those updates or corrections to the carrier, since the group is already live on the connection.

​
Reconciling Send groups

After a group connection is complete for a group with a Send connection, and you have sent initial census snapshots for all members of the group, Noyo will work with the carrier to test and configure the connection. You may receive an error report from the carrier that highlights any data issues to be corrected before the connection can be established. You may need to correct data in your system or request updates from members, then send those updates to Noyo via additional member snapshots to allow Noyo to continue the testing cycle.