Changing data with config modifiers

Last updated: Jan 16, 2025
DEVELOPER
IMPLEMENTATION
PRODUCT OWNER

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

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

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

Config modifiers may be independent in some cases, but they're typically applied on top of a Redox base config.

Common use cases for config modifiers

Config modifiers can help with many use cases. You'll usually discover opportunities for config modifiers during implementation testing as you or your connection receive data you don't expect or vice versa. Review some common ones below.

Config modifier 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 path pattern that points to the part(s) of a payload that you want to create, replace, or delete. For Put flavors, there's also a schema with instructions for how to build or replace data at the specified selector path. Learn how to build a config modifier schema.

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.

Linking to processing stages

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

  1. a subscription
  2. all or a set of event types within that subscription
  3. 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 the source, you can link to these available stages:

  • For async messages
    • source-managed SEND
    • source-managed RECEIVE
  • For sync messages
    • source-managed REQUEST
    • source-managed RECEIVE (first half of exchange)
    • source-managed RESPOND
    • source-managed RECEIVE (second half of exchange)

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

  • For async messages
    • destination-managed SEND
    • destination-managed RECEIVE
  • For sync messages
    • destination-managed REQUEST
    • destination-managed RECEIVE (first half of exchange)
    • destination-managed RESPOND

If you own both the source and destination, you can link to all of the above stages.

If linking in the Redox dashboard, only the available log stages will appear. This means that your view might look a little different from your connection's.

If linking via API, you'll get a validation error if you try to link to a stage that's not available to you.

Before or after Redox processing

The Redox processing stage(s) happen in the middle, both going to and back from a destination. You can't link config modifiers to these stages.

During the middle stage(s), we convert data into a Redox data model or FHIR® resource format. If the selector you want to target isn't in one of our standard data models or resources, it might unintentionally get erased or ignored before arriving at the destination. Other changes that don't fit in these standard formats might also be ignored.

If you're altering something within one of our standard formats, link before Redox processing. For example, if your config modifier alters values (e.g., timestamp format) or fields within the Redox format. Changing values or formats of values will be retained during Redox processing since you're not moving fields around.

  • For async: source-managed SEND or destination-managed SEND
  • For sync: source-managed REQUEST / RESPOND or destination-managed REQUEST / RESPOND

If you're altering something outside of our standard formats, cover your bases by linking after Redox processing. For example, If your config modifier alters the shape of data or selectors outside Redox formats.

  • For async: source-managed RECEIVE or destination-managed RECEIVE
  • For sync: source-managed RECEIVE / RESPOND or destination-managed RECEIVE (first half of exchange)
    • If you need to link at the end of a sync exchange, i.e., destination-managed RECEIVE (second half of exchange), talk to a Redoxer about your use case.

Changes based on conditions

Config modifiers are schemas with keywords that define how to alter data based on certain criteria. Think of it 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.

This is different from translation operations, since those define how to map values between static code sets. Values within a code set don't change, but a translation operation changes which value you get from your connection, in case you use different code sets for the same thing. Config modifiers, however, may specify to make a change to a value based on certain criteria, like whether a value is present, then perform a certain action.

Multiple input payloads

A config modifier may have two input payloads:

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

This means that 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 create it again in the processed payload at the linked processing stage.

Input and output payloads
Input and output payloads