Skip to main content

Submit the de-link payer product

Removes a product (product ID and name) from a payer's participant code in the registry.

POST/product/delink

Business purpose

When a payer withdraws a product from the market or replaces it, the registry entry created by /product/link should be removed so that it is no longer resolvable and cannot be referenced by new member links. The OpenAPI document describes this Retrieving API call as the API to de-link products by the payers or insurance companies. Keeping the catalogue accurate protects providers from matching on retired products when they resolve coverage for InsurancePlan and preauthorisation.

When to use

Use it when a product is withdrawn. Remove the member links to it first.

Preconditions

  • You have a valid access token in the bearer_auth header.
  • Member links to the product are already removed.
  • You send productid, productname and participantcode.

Postconditions

The product no longer belongs to the payer in the registry. Providers that cached it keep seeing it until they force a refresh.

Common mistakes

  • Sending only productid. All three fields are required.
  • Removing a product while members are still linked to it.
  • Expecting providers to see the change at once.

Best practices

  • Enumerate and de-link affected member policies before removing the product.
  • Use the exact productid and productname that were registered with /product/link.
  • Verify afterwards with /product/getowner that the product no longer resolves to your participant code.
  • Log the request and the returned participant_code for audit.
  • Refresh the Bearer token proactively and retry once on 401.

Related scenario

An insurer retires its old Individual Health Silver product at the end of a policy year, having migrated every member to a successor product. Its system first runs /participant/delink/abha/policy for each member still linked to the old product, then calls /product/delink with the product ID, product name and the insurer's participant code. A confirmation call to /product/getowner shows the product no longer resolves. The insurer notifies its network hospitals, whose desks force a refresh of cached policies so that the next coverage-eligibility check and preauthorisation reference the successor product.

Specification

Chapter Participants and policies of the NHCX integration specification.

Authorizations

bearer_authapiKeyRequired

Every NHCX call carries the access token from the session call in a header named bearer_auth, as the word Bearer, a space and the token. NHCX reads bearer_auth, not Authorization.

Example Bearer <access token>

Headers

AcceptstringRequired

Always application/json on the participant service.

Body

productidstring
productnamestring
participantcodestring

Responses

200

On success the endpoint returns HTTP 200 with ParticipantCreateResponse containing the optional participant_code.

participant_codestring