Common use cases for config modifiers

Scenario: You’re receiving a PatientAdmin data model from your connection.

Problem: Your connection (i.e., source system) isn’t populating the MSH.4 (i.e., FacilityCode) segment. Your system expects the sending facility code in Meta.FacilityCode.

Goal: Populate the FacilityCode with a specific value. In this case, you know the code should always be acme-123.

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

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

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

1
$.Meta.FacilityCode

Schema: Next, build your schema to hardcode the FacilityCode value on each PatientAdmin message from this source feed with this keyword:

• 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

Output payload: This config modifier would result in the hardcoded FacilityCode value in the output payload.

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

Scenario: You receive a Scheduling.New message from your connection (i.e., the source system).

Problem: 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.

Goal: Populate the VisitDateTime from SCH 11.1 (the time the visit starts) instead of SCH.11.4 (the time the visit ends).

Input payload: In this input payload, the desired start time (20240603165602) is located at SCH.11[0].1.1.

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
}

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

1
$.Visit.VisitDateTime

Schema: Next, build your schema to retrieve the value at SCH 11.1 and reformat it with these keywords:

• 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

Output payload: 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
 }

Scenario: Your connection sends a Visit ID in one segment for some types of visits, but in a different segment for other types of visits.

Problem: Sometimes the input payload looks like 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.

Goal: Populate visit ID regardless of the visit type.

Input payload: These input payloads show the different locations visit ID might be.

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
}

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

1
$.Visit.VisitNumber

Schema: Next, build your schema to look for visit ID depending on whether PV1.19.1 is populated or not with these keywords:

• 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

Output payload: 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
}