# Signals settings

Canonical page: https://docs.ovok.com/signals/with-ovok/settings

Two project settings connect your FHIR data with Signals. Both are Boolean [project settings](/settings-and-features), changed by a project admin:

```bash
curl --request PUT \
  --url 'https://api.sandbox.ovok.com/v1/project/settings/SIGNALS_SEND_AUTO' \
  --header "Authorization: Bearer ${OVOK_TOKEN}" \
  --header 'Content-Type: application/json' \
  --data '{"enabled":true}'
```

| Setting | Default when unset | Needs, or `effectiveSettings` is `false` |
| --- | --- | --- |
| `SIGNALS_SEND_AUTO` | On | A Signals tenant of the project's own. |
| `SIGNALS_ANNOTATE_OBSERVATIONS` | Whatever `SIGNALS_SEND_AUTO` is | A Signals tenant of the project's own. |

Read `effectiveSettings` in `GET /v1/project/settings` to see what Ovok applies. A project on the shared Signals tenant shows both as `false`, and turning either on answers `409` `SETTING_NOT_AVAILABLE`.

## Saving a setting sets it up [#saving-a-setting-sets-it-up]

Saving a switch does the wiring in the same request, before the value is stored:

- If the wiring works, the setting is saved and the response is the full settings record.
- If it fails, the request answers `502` `SETTING_WIRING_FAILED`, nothing is saved, and any step already done is undone. Try again later.
- While another change of the same switch is running, the request answers `409`.
- Saving the same value again is safe, and repairs missing wiring. Use it after someone deleted the wiring, or after Signals turned a delivery off.

A project that never saved `SIGNALS_SEND_AUTO` is set up on its first request to Ovok, so the default works without anyone saving it.

## SIGNALS_SEND_AUTO [#signals_send_auto]

Sends each `Observation` created through the FHIR API to Signals.

- **What saving it on sets up:** a FHIR `Subscription` in your project that notifies Ovok of every created Observation. It is tagged `https://api.ovok.com/identifier/system-resource|signals-send-auto`. Saving it off deletes it.
- **Create only.** Updating an Observation sends nothing, so a reading is judged once.
- **Enrols patients.** A patient Signals does not know yet is enrolled by its first forwarded reading. You don't need [`$enable-signals`](/signals/enable-signals-patient) first.
- **Not for ingest.** Readings from [Data Ingestion](/data-ingestion) already go to Signals from the ingest path, and the Subscription skips them.
- **Retries.** If Ovok or Signals is briefly down, the notification is retried for about 34 minutes. Signals ignores a reading it already has, so retries never alert twice.

## SIGNALS_ANNOTATE_OBSERVATIONS [#signals_annotate_observations]

Writes Signals' alerts and episodes into FHIR. See [Alerts in FHIR](/signals/with-ovok/fhir-annotations) for the resources.

- **What saving it on sets up:** a system subscriber in your Signals tenant that sends every alert and episode event to Ovok. Saving it off deletes it.
- **Default:** it follows `SIGNALS_SEND_AUTO` until you save it yourself. Saving `SIGNALS_SEND_AUTO` switches it too, unless it has a saved value of its own.
- **Why it follows send-auto.** It annotates readings that live in FHIR. Creating a Manager or Submitter application doesn't change it.
- **Standalone-only projects: switch both off.** Both are on by default for every project with its own tenant. Annotations cover every alert of the tenant, so for patients you created through the [standalone API](/signals/standalone) they write `DetectedIssue`s that point at a `Patient/<refId>` that does not exist.
- **Only new alerts.** Alerts raised before you turned it on are not written.

## Related [#related]

- [Signals with Ovok](/signals/connected-ovok)
- [Alerts in FHIR](/signals/with-ovok/fhir-annotations)
- [Gotchas](/signals/with-ovok/gotchas)
- [Project settings and features](/settings-and-features)