Change data with config modifiers

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.

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.

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

1. flavor
2. selector
3. schema

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 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.

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. 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.

To run a config modifier, you must link it to the correct:

1. subscription
2. event type(s) within that subscription
3. log stage, or processing location

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

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 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.

• Post-processing, outbound
  • source-request (source-managed)
  • source-request (destination-managed)
  • destination-request (source-managed)
  • destination-request (destination-managed)

• Post-processing, outbound (1st half of exchange)
  • source-request (source-managed)
  • source-request (destination-managed)
  • destination-request (source-managed)
  • destination-request (destination-managed)

• Pre-processing, inbound (2nd half of exchange)
  • destination-response (destination-managed)
  • destination-response (source-managed)

• Post-processing, inbound (2nd half of exchange)
  • source-response (source-managed)

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.

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.

A config modifier can have two input payloads:

1. JSON version of the original request or response
2. 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.

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.

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.

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.