# Extensions for data models
Redox data models contain the most common, industry-standard data fields, but they don’t cover every possible use case. When your workflow requires specific data that isn’t in the standard—for example, an appointment’s confirmation status—we offer **extensions** to add those fields.
When supported, a data model might have multiple extensions. Also, an extension container can have one or more extensions within it.
> **Key takeaways**
>
> - **Extensions** add custom data fields to standard Redox data models.
> - They're used when a workflow requires data that isn't part of the general industry standard (e.g., an appointment confirmation status).
> - Redox provides a library of existing extensions, including extensions for **diversity data** (e.g., gender identity, sexual orientation).
> - Custom extensions can be requested but are subject to review and may have additional fees.
## Supporting new extensions
We review whether the data is critical and can be supported before adding an extension. Not all connections may support extensions.
> **Extension availability**
>
> Any of our existing extensions are available to you. [Check out our extension library](https://docs.redoxengine.com/permalink/extensions).
>
> Or, you can ask for new extensions customized to your workflow. A request for a new extension must undergo a review process, though, so we can’t guarantee it’ll be approved. Custom extensions are subject to additional fees.
## Representing diversity with Redox
Most healthcare standards don’t account for representations of gender identity, sexual orientation, ethnicity, or disability.
At Redox, we value belonging. It’s important to us to support this diversity data when it’s available from your connection. We offer extensions on every data model to support diversity-related information. If your connection can send or receive diversity data, you can do so with Redox without needing to upgrade to a higher platform tier.
## What an extension looks like
An extension applies to a specified data model, event type, and field. The `Extensions` container holds extension objects. The **key** of the object (e.g., `additional-phones`) identifies the extension, and the **value** contains the extension’s data. An optional `url` field can also be included for reference.
### Example
We offer an **Additional Phone Numbers** extension for these data models.
| **Data model** | **Event types** | **Available fields for extension** |
| --- | --- | --- |
| `PatientAdmin` | All | `Patient.Demographics.PhoneNumber` `Patient.Guarantor.PhoneNumber` `Patient.Contacts[].PhoneNumber` |
| `Scheduling` | All | `Patient.Demographics.PhoneNumber` `Visit.Location` |
When used for any available fields, the **Additional Phone Numbers** extension contains values for extra home, office, or mobile phone numbers for the patient or location.
The top-level key has the name of the extension. The value for that top-level key can include the extension URL.
**Example: Additional phone numbers extension**
```json
{
"Meta": {
"DataModel": "Scheduling",
"EventType": "New" // Any event type (*) is allowed
},
"Visit": {
"Location": { // Visit.Location is one availalbe field
"Extensions": { // Extensions container
"additional-phones": { // The actual additional-phones extension
// The url is optional--use the actual key name to find the extension.
"url": "https://api.redoxengine.com/extensions/additional-phones",
// The actual value (in this case additionalPhones) is required.
"additionalPhones": {
"home": [
"+16088675309",
"+16088675308"
],
"office": [
"+16088675309"
],
"mobile": [
"+16088675307",
"+16088675306"
]
}
}
}
}
// Other Location fields
}
// Other Visit fields
}
// Other top-level fields
}
```