Common use cases for composable processors

Last updated: Nov 4, 2026

DEVELOPER

IMPLEMENTATION

HEALTH TECH VENDOR

A composable processor is a collection of operations you can build to orchestrate your unique workflow. You can reuse a processor for multiple workflows. . Learn more about orchestration.

Check out how processors can enhance your data processing workflow with these high-level use cases, including one detailed use case with code examples at the end.

Use case 1: Enrich a message with data from another API

Scenario: A message from your connection is missing diagnoses, insurance details, or certain code sets.

Problem: You need the missing data to populate records in your system.

Goal: Add the missing data from an external API to the message before it reaches your system.

How the processor works:

The processor calls an external API to get the missing data.
The processor enriches the messages with these details:
- Add encounter diagnoses from the EHR system to a Scheduling message.
- Add insurance information to VisitQuery results.
- Add standardized terminology codes to a value set.
The processor sends the enriched message to your system.

Use case 2: Send one message as two

Scenario: You receive order cancellations as HL7v2 messages.

Problem: To cancel a single order, your system needs two HL7v2 messages that differ only in ORC.1. Your connection (i.e., the source system) sends only one Order.Cancel message.

Goal: Send two versions of the cancellation, each with the ORC.1 value that your system expects.

How the processor works:

The processor duplicates the Order.Cancel message.
It tags the copy.
Your destination’s config uses the tag to set a different ORC.1 value on each message.

Use case 3: Pull a clinical record after discharge

Scenario: An EHR system send discharge notifications to your system.

Problem: You need the patient’s full clinical record after discharge, but the EHR system only sends a discharge notification.

Goal: Turn the discharge notification into a complete clinical record for your system.

How the processor works:

The processor takes the MRN from the A03 message.
It finds the patient in the EHR system.
It runs a set of FHIR® searches, such as Encounter, Observation, Condition, and Medications.
It reads any referenced Location, Organization, and Practitioner resources to build the clincial record.
It combines everything into one FHIR® bundle and sends it to your system.

Use case 4: Automatically check for new data in HL7v2 feeds

Scenario: You’re receiving an SIU and ADT feed that you filter based on provider ID.

Problem: The provider ID list is manually maintained and filters have to be updated or paused every time a new provider is added to the network.

Goal: Automatically check for new providers and get notified about the new provider(s) without having to pause your filters.

How the processor works:

The processor polls for new providers.
It notifies your system when a new provider is added so you can update your filter and provider list without pausing.

Detailed use case: Split a FHIR® bundle into several messages

Scenario: You receive a FHIR® bundle with several document entries in one message.

Problem: Your system expects individual documents for easy retrieval.

Goal: Split the FHIR® bundle into individual Document Bundle payloads.

Example: Input payload for populating a field

json

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

Process operations: Next, build your processor with these operations:

apply-config: You need to modify the FHIR® bundle by applying a Redox base config. Learn about apply config.
map-collection: You need to map the split document bundles to new payloads with metadata for each. Learn about map collection.
build-json: You need to return each item as a full payload with metadata so it's ready to enqueue at your source. Learn about build json.

Example: Split a FHIR bundle processor

json

1
{
2
  "splitBundle": {
3
    "name": "Split FHIR Bundle into a Bundle transaction of individual document Bundles",
4
    "operationType": {
5
      "key": "apply-config",
6
      "majorVersion": 1
7
    },
8
    "nextOperation": {
9
      "onSuccess": "Operation.mapPayloads",
10
      "onError": "Processor.error"
11
    },
12
    "inputExpression": {
13
      "type": "reference",
14
      "reference": "Payload.initial",
15
      "includeMetadata": false
16
    },
17
    "parameterExpressions": {
18
      "configVersion": {
19
        "type": "constant",
20
        "constant": {
21
          "structure": "json-object",
22
          "kind": "redox-config-version",
23
          "value": {
24
            "key": "7e2329af-1960-4871-a0ae-ed27f034237e"
25
          }
26
        }
27
      }
28
    },
29
    "dataLabels": {
30
      "output": {
31
        "onSuccess": {
32
          "dataModel": {
33
            "value": "FHIR.Event.Document"
34
          },
35
          "eventType": {
36
            "value": "document-created"
37
          }
38
        },
39
        "onError": {
40
          "error": {
41
            "value": "error"
42
          }
43
        }
44
      }
45
    }
46
  },
47
  "mapPayloads": {
48
    "name": "Map the split document Bundles to new payloads with metadata for each",
49
    "operationType": {
50
      "key": "map-collection",
51
      "majorVersion": 1
52
    },
53
    "nextOperation": {
54
      "onSuccess": "Processor.success",
55
      "onError": "Processor.error"
56
    },
57
    "inputExpression": {
58
      "type": "reference",
59
      "reference": "Payload.splitBundle",
60
      "includeMetadata": false
61
    },
62
    "parameterExpressions": {
63
      "selector": {
64
        "type": "constant",
65
        "constant": {
66
          "structure": "string",
67
          "kind": "jsonpath-selector",
68
          "value": "$.entry[*].resource"
69
        }
70
      },
71
      "itemPayloadKey": {
72
        "type": "constant",
73
        "constant": {
74
          "structure": "string",
75
          "value": "documentBundle"
76
        }
77
      },
78
      "initialOperationKey": {
79
        "type": "constant",
80
        "constant": {
81
          "structure": "string",
82
          "value": "buildWithMetadata"
83
        }
84
      },
85
      "includeItemMetadata": {
86
        "type": "constant",
87
        "constant": {
88
          "structure": "boolean",
89
          "value": true
90
        }
91
      },
92
      "operations": {
93
        "type": "constant",
94
        "constant": {
95
          "structure": "json-object",
96
          "value": {
97
            "buildWithMetadata": {
98
              "name": "Simply returns each item as a full Payload (with metadata) so it's ready to enqueue",
99
              "operationType": {
100
                "key": "build-json",
101
                "majorVersion": 1
102
              },
103
              "inputExpression": {
104
                "type": "reference",
105
                "reference": "Payload.documentBundle",
106
                "includeMetadata": false
107
              },
108
              "parameterExpressions": {
109
                "schema": {
110
                  "type": "constant",
111
                  "constant": {
112
                    "structure": "json-object",
113
                    "kind": "config-modifier-schema",
114
                    "value": {}
115
                  }
116
                }
117
              },
118
              "nextOperation": {
119
                "onSuccess": "Processor.success",
120
                "onError": "Processor.error"
121
              },
122
              "dataLabels": {
123
                "output": {
124
                  "onSuccess": {
125
                    "dataModel": {
126
                      "value": "FHIR.Event.Document"
127
                    },
128
                    "eventType": {
129
                      "value": "document-created"
130
                    }
131
                  },
132
                  "onError": {
133
                    "error": {
134
                      "value": "error"
135
                    }
136
                  }
137
                }
138
              }
139
            }
140
          }
141
        }
142
      }
143
    },
144
    "dataLabels": {
145
      "output": {
146
        "onSuccess": {
147
          "dataModel": {
148
            "value": "FHIR.Event.Document"
149
          },
150
          "eventType": {
151
            "value": "document-created"
152
          }
153
        },
154
        "onError": {
155
          "error": {
156
            "value": "error"
157
          }
158
        },
159
        "onStop": {
160
          "error": {
161
            "value": "stop"
162
          }
163
        }
164
      }
165
    }
166
  }
167
}

FHIR® is a registered trademark of Health Level Seven International (HL7) and is used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.