> For the complete documentation index, see [llms.txt](https://help.bioinsight.illumina.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.bioinsight.illumina.com/emedgene/emedgene-analyze-manual/settings/organization_settings_-330+/case-settings/case-additional-information.md).

# Case additional information

Clinical and research teams often need to store extra case-level metadata—such as **lab name, lab ID, specimen ID, internal tracking fields, or multilingual labels**—that are not included in the standard Add Case form.

Case additional information is a self-service feature (v100.41.0+): you define additional information fields at the organization level, optionally set a default value for each field, and those fields appear on new cases in **Case Info Sidebar → Additional Information**. Before v100.41.0, organizations typically relied on Illumina Support to configure these fields.

Changes you make in Organization Settings apply only to cases created after the change. Existing cases keep the fields and values they had when they were created; updating or removing a field or default does not change cases that already exist.

For how fields appear on a case, see [Case info](/emedgene/emedgene-analyze-manual/getting_around_the_platform/cases_tab/case_details/case-info.md).

### Accessing case additional information

You can manage these fields from:

**Organization Settings → Case Settings → Case Additional Information**

This card appears **below “Multiple tags.”**

### Case Additional Information

The card includes:

* A searchable table of your organization’s additional information fields and each field’s default value (if set)
* Add, Edit, and Delete actions

If your organization already had additional information fields before v100.41.0, those fields and defaults appear in this table with no action required. New organizations with no configured fields see an empty table until fields are added.

#### Adding a new field

Users with the role can click **Add Field**.

For each field, you can enter:

* **Field name** (required): Must be unique in your organization
* **Default value** (optional):
  * You can leave this empty when you create the field and set or change the default later when you edit the field.

{% hint style="info" %}
**Recommended:** set a default when the same value applies to most new cases (for example, a standard ordering lab ID), so analysts do not re-enter it on every case.
{% endhint %}

**Once saved:**

* The field is added to the table (new fields appear at the bottom of the list)
* A success message is shown and an entry is written to the organization activity log

**On new cases created after the fields exist:**

* The field appears under Case info → Additional
* If a default is set, the case is pre-filled with that value; if not, the field is empty until someone enters a value on the case

New additional information fields are included on cases created after the field is saved (with defaults applied when configured).

You can still supply case-level additional data through case creation API or batch CSV where your workflow supports it; org-defined fields and defaults are managed in this card.

#### Editing a field's default value

You can update the default value for an existing field at any time. You cannot rename a field from the UI; to use a different name, delete the field and add a new one.

* If a default value is changed, the updated value will apply only to **future cases**.
* Existing cases are not modified.

#### Deleting a field

When you delete a field, the **system asks you to confirm deletion**.

After you confirm:

* The field is removed from Organization Settings and does not appear on newly created cases
* Values already saved on existing cases are kept (historical case data is not erased)

Deletion cannot be undone. If you need the field again, add it as a new field.

#### Searching for fields

A search bar is available to help locate fields by name. Search is case-insensitive and returns **partial matches**. Search is especially useful for large organizations with many metadata requirements.

{% hint style="info" %}
**Notes:**

* Field names must be unique within the organization (case-insensitive)
* There is **no limit** on the number of fields you can create.
* Removing a field does **not** erase data stored in historical cases.
* Field names **cannot be changed** after creation—delete and re-add if needed
  {% endhint %}

{% hint style="success" %}
**Tips:**

* Use descriptive field names (e.g., “Specimen Type,” “Collection Site,” “Ordering Lab ID”) to make downstream case review easier.
* Consider setting default values for fields that apply to most cases to reduce manual data entry.
* Use the search bar when managing large lists of metadata fields.
  {% endhint %}

{% hint style="warning" %}
**Warnings:**

* Deleting a field **cannot** be undone—confirm carefully before proceeding.
* Changing default values will not update existing cases.
* Default values apply to **all new cases**, so ensure they represent organization-wide expectations.
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.bioinsight.illumina.com/emedgene/emedgene-analyze-manual/settings/organization_settings_-330+/case-settings/case-additional-information.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.