You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 6, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: codex-process-feasibility/README.md
+50-12Lines changed: 50 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,41 +12,79 @@ As you can see in the figure above, the feasibility query process starts with a
12
12
13
13
### Distribute Query
14
14
15
-
Messages, queries and results are represented by FHIR resources. The following three figures show the entire FHIR resource flow. In difference to the figure above, only one DIZ is represented, but both, the ZARS and the DIZ are divided into its individual components. On the ZARS side the components are the FHIR communication server and the BPE, were the DIZ contains an additional Blaze FHIR server.
15
+
Messages, queries and results are represented by FHIR resources. The following three figures show the entire FHIR resource flow. In contrast to the figure above, only one DIZ is represented, but both, the ZARS and the DIZ are divided into its individual components. On the ZARS side the components are the FHIR communication server and the BPE, were the DIZ contains an additional Blaze FHIR server.
16
16
17
17
18
18
19
19
1. Like in the high-level overview, the process starts with the `request` message. Beside the FHIR [Task][1] resource for the message, two other FHIR resources will be sent to the ZARS FHIR server. The first one is the [Measure][2] resource specifying the population criteria that are defined in the second resource, the [Library][3]. All three resources are put into a transaction [Bundle][4] in order to create all together in one transaction.
20
20
21
-
1. After the ZARS FHIR server receives the resources, it notifies the ZARS BPE via websocket subscription by transmitting the Task resource. The incoming Task resource starts the `request` process that implements the query distribution to all appropriate DIZ'es.
22
-
23
-
### Execute Query
21
+
2. After the ZARS FHIR server receives the resources, it notifies the ZARS BPE via websocket subscription by transmitting the Task resource. The incoming Task resource starts the `request` process that implements the query distribution to all appropriate DIZ'es.
24
22
25
23
3. To each DIZ, an `execute` message is sent via a Task resource.
26
24
27
-
3. After arriving at the DIZ FHIR communication server, the `execute` Task resource is transferred to the DIZ BPE via websocket subscription, starting the `execute` process.
25
+
4. After arriving at the DIZ FHIR communication server, the `execute` Task resource is transferred to the DIZ BPE via websocket subscription, starting the `execute` process.
26
+
27
+
### Execute Query (CQL)
28
+
29
+
This describes the execute process in case `CQL` is specified as an evaluation strategy.
28
30
29
31
30
32
31
33
5. In each DIZ, the `execute` process starts by fetching the Measure and Library resource created at the ZARS FHIR communication server. The resources have to be fetched by the BPE because only Task resources are sent actively between organizations and message payload is only fetched in case a process really needs it. FHIR search is used in order to fetch both resources in one HTTP request by searching for the Measure resource and including the referenced Library resource.
32
34
33
-
5. In the next step, the `execute` process stores the Measure and Library resources to the Blaze FHIR server in order to be able to execute the [$evaluate-measure][5] operation.
35
+
6. In the next step, the `execute` process stores the Measure and Library resources to the Blaze FHIR server in order to be able to execute the [$evaluate-measure][5] operation.
34
36
35
-
5. The resulting [MeasureReport][6] resource is transferred back to the DIZ BPE.
37
+
7. The resulting [MeasureReport][6] resource is transferred back to the DIZ BPE.
36
38
37
-
5. After receiving the MeasureReport, the DIZ BPE stores it on the DIZ FHIR communication server in order to make it available for the ZARS.
38
-
39
-
### Retrieve Results
39
+
8. After receiving the MeasureReport, the DIZ BPE obfuscates the population count within it unless disabled. Subsequently, it stores the MeasureReport on the DIZ FHIR communication server in order to make it available for the ZARS.
40
40
41
41
9. In its last step, the `execute` process sends a `result` message to the ZARS. The `result` message references the MeasureReport, so that it can be retrieved by the ZARS.
42
42
43
+
### Execute Query (Structured Query)
44
+
45
+
This describes the execute process in case `Structured Query` is specified as an evaluation strategy.
46
+
43
47
44
48
49
+
5. In each DIZ, the `execute` process starts by fetching the Measure and Library resource created at the ZARS FHIR communication server. The resources have to be fetched by the BPE because only Task resources are sent actively between organizations and message payload is only fetched in case a process really needs it. FHIR search is used in order to fetch both resources in one HTTP request by searching for the Measure resource and including the referenced Library resource.
50
+
51
+
6. The DIZ BPE extracts the structured query from the Library resource and sends it to the Flare server.
52
+
53
+
7. The DIZ Flare server runs the evaluation by transforming the structured query into one or more requests compatible with the FHIR standard.
54
+
55
+
8. The DIZ Flare server collects all results from the FHIR server.
56
+
57
+
9. The DIZ Flare server sends back a single population count to the BPE.
58
+
59
+
10. Since the DIZ Flare server does not respond with a FHIR resource the BPE creates a MeasureReport resource based on the population count and the resources it downloaded in `5.`. Additionally, it obfuscates the population count unless disabled. The DIZ BPE stores this MeasureReport on the DIZ FHIR communication server in order to make it available for the ZARS.
60
+
61
+
11. In its last step, the `execute` process sends a `result` message to the ZARS. The `result` message references the MeasureReport, so that it can be retrieved by the ZARS.
62
+
63
+
### Retrieve Results
64
+
65
+
66
+
45
67
10. After arrival, the ZARS FHIR communication server will send the `result` Task resource to the ZARS BPE via websocket subscription. The incoming `result` message will use its correlation ID to match the original `request` process to continue.
46
68
47
-
10. As part of this process, the MeasureReport resource is fetched from the DIZ.
69
+
11. As part of this process, the MeasureReport resource is fetched from the DIZ.
70
+
71
+
12. The fetched MeasureReport resource is stored immediately on the ZARS FHIR communication server together with the updated Task resource. The Task resource references the MeasureReport resource in its output parameter, in order to make it available to the initial requester.
72
+
73
+
## Supported Query Types
74
+
75
+
This process supports the following query types within the transferred Library resource:
76
+
77
+
|Type | Description | Mime Type |
78
+
|-----|-------------|-----------|
79
+
| CQL | Standardized query format. See https://cql.hl7.org/ for more information. |`text/cql`|
80
+
| Structured Query | Internal query representation within the CODEX project based on the JSON format. |`application/sq+json`|
81
+
| FHIR Search Query | Standardized FHIR search query. See https://www.hl7.org/fhir/search.html for more information. |`application/x-fhir-query`|
82
+
83
+
**Note**: _Although a FHIR search query can be transferred to the process no result will be calculated!_
84
+
85
+
## Result Obfuscation
48
86
49
-
10.The fetched MeasureReport resource is stored immediately on the ZARS FHIR communication server together with the updated Task resource. The Task resource references the MeasureReport resource in its output parameter, in order to make it available to the initial requester.
87
+
The process ensures obfuscation of a DIZ's real evaluation numbers by rounding them to the nearest ten. Real numbers are solely present in an intermediary step for obfuscation purposes. None of these non obfuscated numbers get persisted unless obfuscation gets explicitly disabled.
0 commit comments