Do any of your downstream receivers need the ARV segment? I don’t know of any tooling or functionality to make mass changes to multiple formats.
You could use route detail chaining – create a new “pre-proc/translator/post-proc” structure definition and configure that to be executed first, followed by your existing “pre-proc/translator/post-proc” structure. The new one would have a custom format, based on your existing format, with the addition of the ARV segment. If no downstream receiving system needs that information, then you would not need to create COPY statements for any field in the ARV segment.
We adopted a technique of grabbing certain fields, found in custom segments (ex: ZIN) and putting the field content into OBX segments and passing the OBX segments to downstream systems. Let me back up and say that we have a single input format and translator for all ADT message types, except merges and swaps, and this handles “custom” segments and fields. The output of this translator is sent to multiple sites, and in each site, these messages are then put through translators that are matched to the receiving ancillary system. Those “ancillary” translators then will pick out any OBX data needed and COPY it to the segment which the ancillary expects it.
This reduces translator maintenance. Also, if we change EMRs in the future, we only have to change the one translator in the primary (EMR) site.
This or a similar technique could limit your changes for the ARV segment to just one translator.
Peter Heggie
PeterHeggie@crouse.org
.
