In any data exchange, a request must undergo processing. An operation is an individual step during log processing. There are different operation types, but they all have the same goal of shaping data appropriately so you can successfully send and receive data.
Typically, multiple operations are applied to a request. Also, not every log goes through the same set of operations. The operations applied to a log depend on the subscription's settings.
We manage most operations for you. We still show them to you in log inspector so you can pin down where or why data changed unexpectedly for troubleshooting purposes.
However, you know your data needs the best, so you have the ability to create and manage some of these operations yourself. Learn how to set up operations. We note who can manage operations under each operation type below.
Log inspector offers an up-close view of the operations applied to a request. Learn how to run log inspector.
In the operation details, log inspector shows payload snapshots, or quick views of payloads at the input and output points of the operation. Most importantly, log inspector shows whether the operation did nothing, succeeded, or failed.
Redox captures operations for all logs, not just the ones that you run log inspector on. However, extended payload snapshot data isn't captured for logs outside of log inspector. Those extra details only result from running the log inspector.
These operations define how to convert and format data appropriately, as well as perform field mapping.
Managed by: Redox
For each data exchange, Redox normalizes data for a consistent experience—it's the Redox promise!
A Redox base config operation includes converting a payload from a given system's format to the appropriate Redox data model or FHIR® resource. These conversions happen on both sides of the exchange so that you or your connection gets data in the format you expect.
Managed by: You or your connection
A config modifier is a set of custom instructions you create for processing incoming or outgoing data. This operation is typically applied on top of a Redox base config, but it may be applied independently in some cases. Depending on the config modifier flavor, it can either write new data to or delete existing data from a payload. Learn about config modifiers.
Managed by: You or your connection
Translation sets allow you translate one system's preferred value set to another system's value set. Furthermore, a translation set defines how those values should map to each other. Learn about translation sets.
A translation operation occurs when a translation set you've created applies to a log payload. Keep in mind that translations contain explicit logic to change a value that's always the same; they aren't conditional and don't alter the shape of data like config modifiers.
Translations can happen on either side of the data exchange, as well as for outgoing or incoming values.
These operations polish up incoming or outgoing requests so there aren't any snags during delivery.
Managed by: Redox
One system's fundamental data is another's extraneous data. Some payloads need pruning or sprucing to fit our Redox data model or FHIR® resource format during transit.
A cleanser operation both removes unknown fields from payloads and creates empty placeholders for missing fields. It also sets null for empty or missing fields in many cases. Sometimes errors are returned if validation fails significantly during a cleanser operation.
Managed by: Redox
The JSON converter operation generates a JSON representation of data from a given inbound data format or to a different outbound format. The operation details will show whether it's applied as from JSON or to JSON.
For example, we convert HL7 data in pipe-delimited format to JSON like this:
Conversely, running from JSON mode converts HL7 data that's structured as JSON into HL7-formatted data, like this:
Managed by: Redox
Redox likes to be preemptive about catching troublesome formats or contents.
So, the pre-parser operation runs a Redox-written code snippet to clean up or adjust a payload before the JSON converter operation. These code snippets are “early fixers” that adjust payloads to increase chances of successful processing.
Managed by: Redox
In the olden days, we used to address envelopes to let the postal office know where a letter should go. The postal office would stamp envelopes to let the receiver know when they processed the letter.
Likewise, the tagger operation adds metadata about processing, like source and destination IDs, timestamps, and setting data model and event type names if they're missing. This doesn't include any changes to values in payload fields.
The goal of this operation is to ensure metadata consistency.
Now that we've defined what to do and polished it up, we're ready to route and send using these types of operations.
Managed by: Redox
Binary Large Object (BLOB) files are things like PDFs or images that don't fit neatly into the data model or FHIR® resource structure. Typically, you can upload BLOB files to our BLOB file API, then include a reference link directly in a payload to send a file. Learn about sending a file.
A BLOB resolver operation takes references to BLOB files in a payload and looks for a matching file in the BLOB API. The outcome of this operation lets you know whether Redox successfully located a matching file. However, it doesn't include the actual file contents.
Managed by: Redox
We all want our packages to get the correct destination. In technical terms, Redox relies on a bit of directing between sources and destinations to make sure data gets to the correct place.
A conductor operation finds the destination(s) that the log should go to by looking at the subscription's details. A subscription defines which source talks to which destination using a given data model or FHIR® resource. You may have a subscription for the same data model going to multiple destinations. In that case, Redox sends a copy of the same log to each destination.
The details of a conductor operation show what the subscription matched to the log. It also captures “slug routed” FHIR® logs that use part of the URL to identify where the log should go.
Managed by: Redox
A delivery operation is like your Amazon driver; they deliver the package to the right place at the right time. Similarly, delivering to the target destination is the end goal of a SEND request.
Delivery is the core operation of the RECEIVE stage, even though other operations run during RECEIVE as well. Technically speaking, delivery is the actual transport of the request to the destination. This is just like your Amazon delivery driver setting your package on your porch: their delivery happens at the same time you receive the package.
Delivery results in a response from the destination, whether a generic success message or an error.
The delivery operation captures both what Redox sent and the response we got back. So this operation exists to capture those two payloads: the input payload snapshot shows what we sent to the destination, and the output payload snapshot contains the response we received back.
Some FHIR® queries would return too many results; so FHIR® relies on pagination. Learn about FHIR® pagination.
A FHIR® pagination resolver takes a FHIR® server's pagination link and resolves it to a Redox-centric link instead. You can use these links to review pages of search results.
Managed by: You or your connection
Filters are rules that you define to allow or block a subset of data payloads that you receive asynchronously from one of your connections. Learn about filters.
A filter operation occurs when a filter you've created runs on a log. This type of operation only happens in the REQUEST stage of log processing.
Managed by: Redox
Like your custom filters, Redox may also define filter rules for a log. They function mostly the same, but are managed by Redox.
A Redox filter operation occurs when a filter Redox manages runs on a log. This type of operation can happen on either the source or destination side of the exchange, whether for outgoing or incoming requests.
A Redox filter can stop a log from processing further or can modify the log content itself. Just note that the contents of a Redox filter won't be visible in the Redox dashboard.