Next you will link each of the members and coverages in your system with Noyo’s records. This step will ensure that everyone is enrolled in the right coverages, and that your future demographic and enrollment changes will be processed quickly and accurately.
Unlike other solutions, Noyo uses unique IDs for members, which allows us to submit changes for any member attribute, for any carrier. For instance, other systems might use SSN as an identifier, which prevents any SSN changes. With Noyo, it's possible to request SSN changes for multiple carriers with a single standard request.
Terms to know
idis a member identifier defined by Noyo, and is assigned to each employee and dependent when their record is created in the Noyo system.
custom_individual_idfield 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_idvalues 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.
When your group connection is complete and you’ve mapped plans and account structures, you’ll move on to linking members and dependents. How you’ll link them depends on whether Noyo has pulled members’ data into our system from the carrier.
First you’ll need to check for employee data with the Filter employees endpoint.
If no employees are returned, as is typical with net-new groups or Send connections where carrier data is not available, you will need to create the group’s employees and dependents in our system by sending an initial census via a series of member snapshots, with a
custom_individual_id included for each member. The success responses will contain each person’s Noyo ID, which you should include in future snapshots along with your custom ID.
Otherwise, if employee records are returned, as is typical with existing groups and Sync connections where Noyo can read data from the carrier, you’ll need to establish a link between your own records of those members and ours. There are two options for completing this process, which should result in each member in Noyo updated with your own custom ID:
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
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.
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 DOB and SSN 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:
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.
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 responses with the members in your system. After matching the members on your side, you can save and use the noyo IDs for each member to send future snapshot payloads.
If you choose to do your own matching, you should use your own custom IDs by sending snapshots with both the Noyo ID and a custom ID for each person (with the
enable_member_auto_link flag set to
false) so we can store it. We will select the member with the given Noyo ID and associate your custom ID with them. After that, it’s possible to send requests with either a custom ID or Noyo ID. Note that if you send a snapshot with a Noyo ID that does not exist, you’ll receive an error response.
There are two common strategies for finding and matching Noyo IDs for existing members:
- You can attempt to match one member at a time from your system by calling our Filter employee list endpoint, and using the
date_of_birthfields 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.
- You can paginate through the Group employees 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 each set of matched employees.
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 the company is being inaccurately billed (and the employee’s deductions are wrong, too). Or the enrollment may be correct and the member doesn’t realize they have access to these extra benefits.
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 manually compare it with your own records, or build a tool to compare Noyo’s data with your own automatically and surface any important differences.
Our Employee and Dependent endpoints return member demographic information, and our Individual enrollment endpoint returns coverage information. Each individual enrollment includes an
plan_id that link to the member and plan in Noyo, which you can then relate back to your own coverage records. Noyo 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.
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.
Updated about 2 months ago