One thing we can all agree on in healthcare is that no one can agree on codes. For example, your connection may send messages with different codes or values than your organization uses. That might muddy things up in your organization when ingesting data.
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. A translation maps a value in the first value set to a value in the 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 show how directionality works. But it’s possible for you to link a translation set to the processing stages you own, while your connection links separate translation sets to processing stages they own. This means that translation is likely happening to more than 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 you create and link a translation set, the translation automatically applies to messages for the linked subscription. The translation details are visible in the log details. Learn more about log operation details.
During implementation, you can build and test a translation set in a staging environment. Once you have any kinks ironed out, you can then promote the translation set to production. This saves you time and avoids introducing errors by having to rebuild in a different environment. Any time you promote a translation set, the value set is promoted with it. Value sets can’t be promoted on their own. Learn about promoting assets in your Redox organization. Then learn how to promote a translation set.
Every time you edit a translation set, 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 translation set.