Changing data with config modifiers

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.

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.

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.

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 create a config modifier.

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

There are up to four stages that you can link a config modifier to (i.e., REQUEST and RESPOND or SEND and RECEIVE). Learn about log stages. Both you and your connection may link config modifier(s) to these stages, based on the unique data needs for each side of the exchange. Learn how to link a config modifier.

You can link config modifiers to incoming or outgoing data at any of the four processing stages, and so can your connection. Simply choose the relevant selector where processing should happen.

But here are a few things to keep in mind about linking.

Each processing stage has two parts where you can 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.

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 that middle stage, we convert data into a Redox data model or FHIR® resource format. If the selector path 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.

In short, if you're altering something within one of our standard formats, stick with before Redox processing. If you're altering something outside of our standard formats, cover your bases by linking it after Redox processing.

For a more detailed answer:

• If your config modifier alters the shape of data or things outside the Redox standard formats, we recommend linking it to the last possible location in processing. This would be the config modifier location before the RECEIVE stage on either side of the exchange. Pro tip: Find the RECEIVE config modifier location that's roughly a few steps before a deliveries operation for async traffic or before the end of log processing for sync.
• If your config modifier alters values (e.g., timestamp format) or fields within the Redox format, you might want to link it before Redox processing. A change to values or formats of value will be retained during Redox processing since you're not moving fields around.

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.

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.