One thing we can all agree on in healthcare is that no one can agree on codes. You may find that your connection sends messages with different codes or values than your organization uses, which muddies things up when ingesting data into your system.
Instead of detangling all of that on your own, you can use translation sets with Redox. Translation sets map different value sets to each other.
Fundamentally, translations are one of many operations that can be applied during log processing, but they fall under the mapping type of operations. Learn about operations.
Translation sets are different from Redox base configs, which include their own base translation. Our base translation provides a consistent experience for all our customers.
For each data model, you can see which fields are included in Redox's base config translation by using the toggle for Show Translation Fields.
A value set is the list of specific values that should be translated during the process of data exchange. A value set could be a standard code set like LOINC, SNOMED, or any other you know so well, or it could be a custom code set that your organization uses.
You must define a value set for each system's code set. So for a data exchange between two systems, there should be at least two value sets defined. Essentially, there should be a value set for each code set you want to translate to or from for each system.
Learn how to create a value set.
A translation set is a list of individual translations between two value sets. After you link a translation set, we run our magic in the background so that you receive messages with the values or codes pertinent to your system.
Create a translation set in the Redox dashboard. Alternatively, create translation sets with the Redox Platform API.
Once you have value sets defined, you can use them to create individual translations, which map a value in the first value set to a value in a second value set. One or more translations make up a translation set.
To explain translation mappings, let's say your connection stores an address value like Wisconsin, but your system stores those as the abbreviated WI. A translation can resolve the Wisconsin instances in a payload to the value you use instead.
You can either build or import translations when creating or editing a translation set in the dashboard. Alternatively, you can add a translation with the Redox Platform API for an existing translation set.
For a translation set to work its magic, you must link it to the relevant stage of log processing. There are up to four stages that you can link a translation set to (i.e., REQUEST and RESPOND or SEND and RECEIVE), depending on whether you own either the source, destination, or both. Learn about log processing stages.
To fully link a translation set, you must select the relevant field path where the translation should happen.
A translation set can be bi-directional if you link it to all processing stages you own, and you map values one-to-one.
Let's say you own the source side and you're mapping address values from WISCONSIN to WI. So you decide to link the translation set twice, once to the REQUEST processing stage and once to RECEIVE. In the first processing stage, Redox translates the value from WISCONSIN to WI. In the last processing stage, Redox translates the value from WI to WISCONSIN. In that scenario, the WISCONSIN value serves as the FROM value in the first linked translation set but as the TO value in the second linked translation set.
If you choose to map multiple values to one value, the translation set can only be linked as uni-directional. This means you can only have FROM-TO links.
For example, you could map both WISCONSIN or WISCO to WI, but WI couldn't be mapped back to either one without creating a new translation set. However, you can select the same TO value multiple times per translation set.
These are simple examples to demonstrate how directionality works. But it's worth mentioning that while you may link a translation set to the processing stages you own, your connection may link separate translation sets to processing stages they own, too. So there's likely more translation happening than to just one field, and there could be different translation happening on both sides of the exchange.
By default, translation sets are case sensitive. However, if your data won't be consistently cased, you can turn off case sensitivity. That way, you can manage translations with just one translation set, instead of having to create a new set for differing cases.
After successfully creating and linking a translation set, the translation automatically takes effect on the related subscription. The translation details are visible in the log details. Learn more about log operation details.