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 Nexus™. Translation sets map different value sets to each other.
Fundamentally, translations are one of many operations that can be applied during log processing. Learn about operations.
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 contains two value sets: one for incoming values and one for outgoing values between systems. Furthermore, a translation set defines how those values should map to each other.
For each data exchange, Redox applies a base config, which includes base translation. Redox's base translation provides a consistent experience for all our customers.
However, you can use your own custom translation sets, which you create and maintain in the Redox dashboard. We take the translation set you define and run our magic in the background so that you receive messages with the values or codes pertinent to your system.
The project manager or an engineer from your team could create a translation set during an implementation project with a new connection, but a translation set could be created at any time.
The purpose of a translation set is to map a value from one value set to a value from another value set.
For example, maybe your connection stores an address value like Wisconsin, but your system stores those as the abbreviated WI. A translation set can resolve the Wisconsin instances in a payload to the value you use instead.
You can build mappings directly in the dashboard or import mappings from a CSV file.
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.
Learn how to create and link a translation set.
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.
![One-to-one translation set linked twice for bidirectional mapping](https://images.ctfassets.net/cl3wt5ehhnlv/wo6gCRJtN1xpMuOkjlMpk/aed18f6038103886f88935d2ae569ccc/bidirectional2.png?w=700&h=389)
If you choose to map multiple values to one value, the translation set can only be linked as uni-directional.
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.
![One-to-multiple translation set linked once for unidirectional mapping](https://images.ctfassets.net/cl3wt5ehhnlv/6LMpQk8byDfUftSHbetCjJ/c7652187ef2d990fbd4752d5405bb083/unidirectional2.png?w=700&h=399)
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.
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.