Common use cases for config modifiers

Let’s say you’re receiving a PatientAdmin data model. The source system isn’t populating the MSH.4 (i.e., FacilityCode) segment. Your system expects the sending facility code in Meta.FacilityCode, and you know the code should always be acme-123.

In this input payload, you see the facility code is missing.

1
{
2
  ...remaining payload
3
  "Meta": {
4
    ..."FacilityCode" is not present
5
  }
6
}

First, you have to define where you want the config modifier to populate a value.

1
$.Meta.FacilityCode

Next, you have to build your schema to hardcode the FacilityCode value on each PatientAdmin message from this source feed.

• constant: Since you want to output the same value on each message, you need to use the constant keyword. Learn about constant.

1
constant: acme-123

This config modifier would result in this hardcoded value in the output payload:

1
{
2
  ...remaining payload
3
  "Meta": {
4
    ...remaining Meta data
5
    "FacilityCode": "acme-123"
6
  }
7
}

Let’s say you receive a Scheduling.New message from a source. Your system expects VisitDateTime to be populated with the time the visit starts, but in testing, you notice you’re receiving the time the visit ends. Also, the value isn’t in your preferred date-time format.

In this input payload, you see the value you want is VisitDateTime from SCH 11.1 (the time the visit starts) instead of SCH.11.4 (the time the visit ends).

1
{
2
  ...remaining payload
3
  "SCH": {
4
    ...remaining SCH data
5
    "11": [
6
      {
7
        "1": {
8
          "1": "20240603165602"
9
        },
10
        "2": {
11
          "1": ""
12
        },
13
        "3": "",
14
        "4": {
15
          "1": "20240603175602"
16
        }
17
      }
18
    ]
19
  }
20
}

First, you have to define where you want the config modifier to populate a value.

1
$.Visit.VisitDateTime

Next, you have to build your schema to retrieve the value at SCH 11.1 and reformat it:

• use: You need to access the initial HL7v2 payload, which is outside the scope of the selector path. That means you need to include use. Learn about use.
• get: You need to define where to get the value from to populate the selector path.
• plugin: You need the date-time value to be in ISO-8601 format, so you need to use a plugin to reformat. Learn about plugin.
  • name: Use the date-time plugin to format the value.
  • action: To reformat the incoming value into ISO-8601, use parse.
  • parameters.standard: Identifies the current format of the incoming value, which is in HL7 format.

1
use: initialPayload
2
get: SCH.11[0].1.1
3
plugin:
4
   name: date-time
5
   action: parse
6
   parameters:
7
      standard: HL7

This config modifier would result in this change in the output payload:

1
{
2
  ...remaining payload
3
  "Visit": {
4
    ...remaining Visit data
5
    "VisitDateTime": "2024-06-03T16:56:02.000Z"
6
  }
7
 }

Let’s say your connection sends a Visit ID in one segment for some types of visits, but in a different segment for other types of visits.

Sometimes the input payload looks like the example 1, and sometimes it looks like example 2. Redox handles the visit ID correctly for example 1. But in example 2, Redox uses null for the visit ID because it’s not where we expect.

1
{
2
  ...remaining payload
3
  "PV1": {
4
    ...remaining PV1 data
5
    "19": {
6
      "1": "1234"
7
    }
8
  }
9
}

1
{
2
  ...remaining payload
3
  "PV1": {
4
    ...remaining PV1 data
5
    "50": {
6
      "1": "1234"
7
    }
8
  }
9
}

First, you have to define where you want the config modifier to output a value.

1
$.Visit.VisitNumber

Next, you have to build your schema to look for visit ID depending on whether PV1.19.1 is populated or not:

• use: You need to access the initial HL7v2 payload, which is outside the scope of the selector path. That means you need to include use. Learn about use.
• if: The action to take is a conditional decision. That means you need to include if to define the logic for each condition. Learn about if.
  • operator: First, Redox should check that the value exists, so you should enter all. Learn about operator.
  • terms: Next, Redox should check whether PV1.19.1 exists, so that value is our singular term. Learn about terms.
    • get: Define where to get the value from to populate the selector path. Learn about get.
  • then: Define what should happen when the if scenario is true. In this case, use PV1.19.1 if it exists. Learn about then.
    • get: If PV1.19.1. exists, retrieve its value. Learn about get.
  • else: Define what should happen when the if scenario isn’t true. In this case, use PV1.50.1 if PV1.19.1 doesn’t exist. Learn about else.

1
use: initialPayload
2
if:
3
  operator: all
4
  terms:
5
    - get: PV1.19.1
6
  then:
7
    get: PV1.19.1
8
  else:
9
    get: PV1.50.1

This config modifier would result in this output payload, regardless of whether PV1.19.1 is populated or not:

1
{
2
  ...remaining payload
3
  "Visit": {
4
    ...remaining Visit data
5
    "VisitNumber": "1234"
6
  }
7
}