# Patients who can't be identified > Protected identity, personal numbers the register can't find, orders without a personal number and children whose guardian pays: when Rivr requires an identified payer, what happens when it can't, and what your system should show. Rivr looks the payer up in a population register using the personal number on the order. That doesn't always work, and the person on the order isn't always the patient: the patient has a protected identity, a Norwegian H-number or a Danish number, no personal number at all, or is a child whose guardian pays. That decides whether the order is created, how the patient can pay and what you get back when you read the order. This guide goes through each case, so the journal doesn't show the wrong person or promise an invoice that never comes. - Market: Sweden (`se`). Norway differs in currency, payment methods and what happens when nobody pays: https://developers.rivr.io/guides/unidentified-patients.md?market=no - Language: English (`en`). Svenska: https://developers.rivr.io/guides/unidentified-patients.md?lang=sv - 7 min read · 8 steps - Page in the portal: https://developers.rivr.io/guides/unidentified-patients Every example targets the sandbox (`https://api.test.rivr.io`) and needs test credentials. A platform client's tokens come from `https://auth.test.rivr.io`, an organisation key's from `https://auth.test.rivr.tech`. ## 1. The personal number on the order is the payer's *Journal system → Rivr* An order carries a single person, the one who pays. `personalNumber`, `phone` and `email` all belong to the payer, and the text message with the payment link goes to the phone number on the order. There is no field for the patient beside the payer, and none for a guardian or a relationship. When the patient pays, payer and patient are the same person. When the patient is a child and the guardian pays, you send the guardian's personal number, phone and email. **Why:** What Rivr returns about the person on the order comes from the payer. When one guardian pays for several children, all the children's orders show the guardian's name. **What your system does:** Keep the patient in your own id and tie the order to it with your order id or your `reference`. Never use the name from Rivr to decide which patient the order is for. > **Rule.** The personal number, phone and email on the order must belong to the same person: the one who pays. ## 2. When Rivr requires an identified payer *Rivr* Identified means that Rivr can read the personal number as Swedish, Danish or Norwegian, and that either the person is already identified at Rivr or the register answers without an error. An outage at the register counts as the person not being identified. Whether the order requires it is decided by the setting "Accepterar oidentifierade köpare" (accepts unidentified buyers). It can be set for a clinic, for a platform and for all of Rivr, and it can't be changed in the order. Rivr requires an identified payer when the setting says no. When checkout has a credit check for the order's amount it is always required, even when the setting says yes. **Why:** The invoice and the credit check need Rivr to know who pays. Checkout depends on the order's amount, so the same clinic can accept a payer without identification for one amount and require identification for another. **What your system does:** Build for both yes and no. That one clinic accepts a payer without identification doesn't mean the next clinic does, or that the same clinic does for every amount. ## 3. How Rivr refuses the order *Rivr → Journal system* When the order requires an identified payer and Rivr can't identify them, Rivr answers `422` with `personal_number_not_identifiable`, and the order is not created. That goes for an order without `personalNumber` too. The error catalog also has `personal_number_required` (`422`) for the same thing, but it doesn't come when an order is created today: treat the two the same, so your system doesn't depend on which one comes. When the setting isn't set at all, the same thing can come as `400` with `request_rejected` instead. Its `message` says in Swedish that the person can't be identified. Read the order before you send the request again, as the code's page says. At a sandbox clinic the test number rule is checked before anything else, so there `personal_number_not_test_identity` comes before these codes. **Why:** The personal number can be right and still not be identifiable in the register: the register refuses some people with a protected identity, Rivr never looks a Norwegian H-number up in the register in production, and Rivr has no Danish register. The same number then gets the same answer next time, unless Rivr has identified the person another way, through the clinic's journal system. That then holds for the person's later orders too. **What your system does:** Show the staff that the clinic requires an identified payer and that Rivr couldn't identify this one. When the number is mistyped or isn't the payer's, fix it and send the order again with the same order id. > **Note.** `message` in `request_rejected` can contain the register's own answer, for example that the person has a protected identity. Handle the text as personal data and show it only to those who need it. ## 4. When the order is created without an identified payer *Rivr → Patient* When the setting says yes and checkout has no credit check for the amount, the order is created even though Rivr couldn't identify the payer. Without `personalNumber` Rivr doesn't look anyone up in the register, and each such order gets a customer of its own. A personal number Rivr can't read is accepted too, with no error saying the number was wrong. A payer who isn't identified gets no invoice: neither Rivr's invoice nor Avarda's is offered as a payment method, and checkout's steps for the invoice and the invoice reminder are removed for the order. So if the patient doesn't pay, the order doesn't become an invoice. Payment methods where the patient pays directly, such as card and Swish, remain when the clinic has them. The same goes for a payer with a protected identity when the register refuses the lookup. When the register instead answers with the person and a confidentiality marking, they are identified and can get an invoice. **Why:** An invoice requires that Rivr has identified the person. That holds for both Rivr's invoice and Avarda's. **What your system does:** Don't promise the patient an invoice when the payer isn't identified. Send the personal number when you have it, also when the clinic accepts payers without identification: without a number that can be identified there is no invoice. ## 5. Protected identity when you read the order *Rivr → Journal system* A full order read in `/api/public` masks a customer with a protected identity instead of hiding them: the personal number becomes its first six digits and `-****`, that is the birth date (`ÅÅMMDD-****` for a Swedish number, `DDMMÅÅ-****` for a Norwegian or Danish one), and name, phone and email become the first character followed by one asterisk for each character removed. The address is emptied. So the length of the name shows, and the birth date remains. Subscriptions are masked the same way. > **Note.** What is echoed in webhooks and which permissions reach patient data are in the guide Patient data in your calls and webhooks. ## 6. The protection doesn't follow everywhere *Rivr → Journal system* Each order carries its own copy of the person. Rivr also updates the person on an order only while it is unpaid. A paid order can therefore still show the name after the person has been given a protected identity. **What your system does:** Once you have seen that a person has a protected identity, carry it over to all of that person's orders in your own system. Don't count on Rivr repeating it on every order. ## 7. Which personal numbers Rivr can identify *Journal system → Rivr* Rivr reads the number as Swedish first, then as Danish and last as Norwegian. - **Sweden:** 10 or 12 digits, with or without `-` or `+`. Rivr checks the date and the check digit. Coordination numbers (samordningsnummer) are accepted as a format. Reserve numbers with letters are not supported and are not read as Swedish. - **Norway:** 11 digits, where Rivr checks both check digits. Only birth numbers (fødselsnummer) and D-numbers are in the National Population Register (Folkeregisteret). Rivr never looks H-numbers and synthetic test numbers up in the National Population Register in production: the register counts them as not identifiable. A sandbox clinic accepts the synthetic test numbers as test identities but refuses H-numbers with `personal_number_not_test_identity`, so there you don't see what production does with an H-number. - **Denmark:** Rivr has no Danish register to look a CPR number up in, so the register can never identify it. - **Another format:** can't be identified. Where the clinic requires an identified payer the answer is `422` with `personal_number_not_identifiable`. Where the clinic accepts payers without identification the order is accepted, with no error saying the number was wrong. **Why:** Norwegian health care gives H-numbers to real patients, so a Norwegian clinic can have patients the register can never identify in production. > **Warning.** A Swedish number with a wrong check digit can be read as a Danish one, and the register can never identify a Danish number. Check the check digit in your system before you send the order. ## 8. Try it in the sandbox *Journal system → Rivr* A sandbox clinic accepts only test identities and checks that before anything else, so a number that isn't one gets `personal_number_not_test_identity` before Rivr asks any register. Which numbers count is in the guide Test in the sandbox. An order without `personalNumber` passes that rule, and what happens next is decided by the clinic's setting. The portal has no test number that gives a protected identity or a person the register can't find. Skatteverket's list of test personal numbers has no coordination numbers, so a coordination number can't be tried at a sandbox clinic. **In the portal:** [The guide Test in the sandbox](https://developers.rivr.io/guides/testing) ## Common pitfalls - Taking the name from Rivr as the patient's. It is the payer's, and a guardian who pays for several children is on all the children's orders. - Trusting the protection to follow to a paid order. It doesn't, so carry it over yourselves. - Sending a mistyped personal number to a clinic that accepts payers without identification. No error says the number was wrong, and the payer gets no invoice. - Building logic on which error code comes when the payer can't be identified. Rivr answers `personal_number_not_identifiable` today; treat `personal_number_required` the same if it comes. - Expecting to see in the sandbox what a Norwegian H-number gets in production. A sandbox clinic refuses H-numbers with `personal_number_not_test_identity`, and in production the register can never identify them. ## Next guide - [Patient data in your calls and webhooks](https://developers.rivr.io/guides/patient-data.md): Where patient data lives in a Rivr integration, what comes back and what doesn't — and the one rule that saves you the most trouble. - [Errors and retries](https://developers.rivr.io/guides/errors-retries.md): One way to handle errors against /api/public: read the code, decide whether to send the call again, wait the right time and send the same Idempotency-Key again. - [Test in the sandbox](https://developers.rivr.io/guides/testing.md): What you can try in the sandbox today, how to do it, which test values exist and what does not work yet.