Changing data with config modifiers

Last updated: Oct 2, 2025

DEVELOPER

IMPLEMENTATION

PRODUCT OWNER

When exchanging data between systems, you don’t always get data exactly the way you want it. A config modifier solves this by allowing you to create conditional rules that automatically change a data payload. Whether you need to add a missing value, move a field to a different location, or delete sensitive information, config modifiers provide the flexibility to reshape data to meet your unique needs.

Config operations

Several operations run during log processing, but config operations are the fundamental part of data exchange. Learn about operations.

First, we create base configs, which contain instructions for converting data to and from the appropriate format, based on a subscription’s settings.

You can create config modifiers, which are custom instructions for processing incoming or outgoing data. Usually, the input payload is output immediately after Redox applies a base config.

Config modifiers might be independent, but they’re typically applied on top of a Redox base config.

Confidential data in config modifiers

The contents of a config modifier might contain confidential data, like personal health information (PHI). Because of that, the contents are only visible to the organization that manages the config modifier.

If your organization doesn’t own the config modifier, you’ll see its name, flavor, and status without the contents in the operation details of log inspector.

Config modifier parts

There are three significant parts to build when you’re setting up a config modifier:

flavor
selector
schema

Flavors

A config modifier can either write new data to or delete existing data from a payload. Usually, the output of applying a Redox base config serves as the input payload for a config modifier.

Each config modifier has a specific flavor, or type. Currently, we support two flavors:

The Delete flavor allows you to remove specific parts of a payload.
The Put flavor allows you to write data—either replacing existing data or creating new data—to specific parts of a payload.

Selectors

Config modifiers specify a selector or JSON path that points to the part(s) of a payload that you want to create, replace, or delete. Learn how to choose or write selectors.

Schemas

For Put flavors, there’s also a schema with instructions for how to build or replace data at the specified selector. The schema is built with Redox keywords. .

One config modifier can create, replace, or delete values or fields at one selector or path at a time. However, the path value might be an array with multiple values. You must create a config modifier for every selector you want to alter in a payload. Learn how to set up a config modifier.

Using the same or different selector paths

If two config modifiers specify the same selector path, you can’t link them to the same combination of subscription, event type(s), and processing stage.

If you link multiple config modifiers (operating on different selector paths) to the same subscription, event type(s), and processing stage, the output from the first becomes the input for the second, and so on.

Linking to processing stages

For a config modifier to work its magic, you must link it to:

a subscription
all or a set of event types within that subscription
the relevant stage of log processing

You can link config modifiers to incoming or outgoing data to most log stages (learn about log stages), and so can your connection. Review the tips below for linking.

Source-managed versus destination-managed

Processing stages have two different parts for link config modifiers: one that’s source-managed and one that’s destination-managed. You can only link config modifiers to the part of the stage that your organization manages.

For example, if your organization manages the source, you can’t link a config modifier to a destination-managed part of a processing stage.

Available stages

Available log stages are determined by the type of data exchange (i.e., async or sync) and whether your organization owns either the source, destination, or both. If you own both the source and destination, you can link to all of the listed stages.

If you own the source, you can link to these source-managed processing stages:

Async traffic	Sync traffic
SEND RECEIVE	REQUEST RECEIVE (1st half of exchange) RESPOND RECEIVE (2nd half of exchange)

Available stages for async, source-owned links

Available stages for sync, source-owned links

If you own the destination, you can link to these destination-managed stages:

Async traffic	Sync traffic
SEND RECEIVE	REQUEST RECEIVE (first half of exchange) RESPOND

Available stages for async, destination-owned links

Available stages for sync, destination-owned links

Linking to available stages

If linking a config modifier in the Redox dashboard, only the available log processing stages appear. Your view might look different from your connection’s.

If linking a config modifier via API, you’ll get a validation error if you try to link to a stage that isn’t available to you.

Before or after Redox processing

The Redox Process stage(s) happen in the middle, both going to and back from a destination. This is when we convert data into a Redox data model or Redox FHIR® resource format.

You can’t link config modifiers to Redox Process stages. That means you have to decide whether to link before or after Redox processing. The location to link depends on your selector:

Link before processing if the selector exists in our standard data models or FHIR® resources (i.e., your config modifier alters values, like timestamp format, or fields within the Redox format). Changes to values or formats of values are retained during Redox processing since you’re not moving fields around.
Available stages for linking before Redox processing
For async traffic:
source-managed SEND
destination-managed SEND
For sync traffic:
source-managed REQUEST / RESPOND
destination-managed REQUEST / RESPOND
Link after processing if the selector doesn’t exist in our standard data models or FHIR® resources (i.e., your config modifier alters the shape of data or selectors outside of Redox formats). This is a safety precaution so that changes made by your config modifier don’t get unintentionally erased or ignored during Redox processing. Other changes that don’t fit in our standard formats might also be ignored.
Available stages for linking after Redox processing
For async traffic:
source-managed RECEIVE
destination-managed RECEIVE
For sync traffic:
source-managed RECEIVE / RESPOND
destination-managed RECEIVE (1st half of exchange)
If you need to link at the end of a sync exchange, i.e., destination-managed RECEIVE (2nd half of exchange), talk to a Redoxer about your use case.
Expected data formats
A caveat to linking a config modifier after Redox processing is that you must use the format that the destination receives data in. If you’re not familiar with non-Redox formats, you might have to do more work to figure out the destination format and how to change it.
However, if you link a config modifier before Redox processing, you can use selectors already in a standard Redox data model or FHIR® resource. In other words, we do the homework so you don’t have to.

Changes based on conditions

Config modifiers are schemas with keywords that define how to alter data based on certain criteria. Think of them like IF / THEN statements. If the conditions of the schema aren’t met, the config modifier isn’t applied to a log. If a config modifier is applied, there may be changes either to the shape of data, individual values, or both.

Config modifier v. translation set

Both config modifiers and translation sets can alter specific values in a payload.

When should you use a config modifier versus a translation set?

A translation set maps a list of values from one code set to another. It’s useful if you have lots of values you want to change based on different code sets used by different systems. This is a static mapping that looks for a particular value and translates it to a corresponding value. Learn about translation sets.
A config modifier contains flexible instructions based on conditions. For example, you could map a specific value to another only if another specified field is present. Essentially, a config modifier allows you to define conditional or fallback behavior. Also, you can only define instructions for values at one field path at a time. If you wanted to change lots of values in different locations, you’d have to create a config modifier for each one.

Multiple input payloads

A config modifier can have two input payloads:

JSON version of the original request or response
Output from a previous operation in log processing

This means you can define a config modifier that reads a value from the original payload even if that value is removed during a previous operation. The config modifier can recreate it in the processed payload at the linked processing stage.

Input and output payloads

Promoting config modifiers

During implementation, you can build and test a config modifier in a staging environment. Once you’re confident it works, you can promote it to production.

Promoting an asset saves you time and avoids introducing errors by having to rebuild it in a different environment. Learn more about asset promotion, then promote a config modifier.

Restoring config modifiers

Every time you edit a config modifier, you create a new version of the asset. If you run into errors or unexpected outcomes after editing, you can restore to a different version to help troubleshoot and find where any errors were introduced. Learn how to restore a config modifier.

Common use cases for config modifiers

Config modifiers can help with many use cases. You’ll usually find opportunities to use config modifiers during implementation testing if you or your connection don’t receive data you expect. Review common use cases and examples.

FHIR® is a registered trademark of Health Level Seven International (HL7) and is used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.