Skip to content

Commit 867c634

Browse files
committed
Update API version
1 parent a51d421 commit 867c634

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

articles/healthcare-apis/dicom/dicom-storage-indexing.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -37,14 +37,14 @@ With the Storage Queue in place, events must be published from the Storage Accou
3737
>- `Microsoft.Storage.BlobCreated`
3838
>- `Microsoft.Storage.BlobDeleted`
3939
>- The file system must be the same one configured for the DICOM service
40-
>- The file path must be within `AHDS/<workspace-name>/dicom/<dicom-service-name>[/<partition-name>]`
40+
>- The file path must be within `AHDS/{workspace-name}/dicom/{dicom-service-name}[/{partition-name}]`
4141
>- The file must be a DICOM file as defined in Part 10 of the DICOM standard
4242
>- The operation can't be performed the DICOM service itself
4343
4444
The event subscription can be configured to filter out irrelevant data to avoid unnecessary processing and billing. Make sure to configure filter such that:
45-
- The *subject* must begin with `/blobServices/default/containers/<file-system-name>/blobs/AHDS/<workspace-name>/dicom/<dicom-service-name>/`
45+
- The *subject* must begin with `/blobServices/default/containers/{file-system-name}/blobs/AHDS/{workspace-name}/dicom/{dicom-service-name}/`
4646
- Optionally, the *subject* ends with `.dcm`
47-
- Under *advanced filters*, the key `data.clientRequestId` doesn't begin with `tag:<workspace-name>-<dicom-service-name>.dicom.azurehealthcareapis.com,`
47+
- Under *advanced filters*, the key `data.clientRequestId` doesn't begin with `tag:{workspace-name}-{dicom-service-name}.dicom.azurehealthcareapis.com,`
4848

4949
### Enable Storage Indexing
5050

@@ -283,12 +283,12 @@ The following example ARM template may be deployed using the [Azure CLI](../../a
283283
{
284284
"type": "Microsoft.HealthcareApis/workspaces",
285285
"name": "[parameters('workspaceName')]",
286-
"apiVersion": "2024-03-31",
286+
"apiVersion": "2025-04-01-preview",
287287
"location": "[resourceGroup().location]"
288288
},
289289
{
290290
"type": "Microsoft.HealthcareApis/workspaces/dicomservices",
291-
"apiVersion": "2024-03-31",
291+
"apiVersion": "2025-04-01-preview",
292292
"name": "[concat(parameters('workspaceName'), '/', parameters('dicomServiceName'))]",
293293
"location": "[resourceGroup().location]",
294294
"dependsOn": [
@@ -321,7 +321,7 @@ The following example ARM template may be deployed using the [Azure CLI](../../a
321321

322322
:::image type="content" source="media/storage-indexing/diagnostic-logs.png" alt-text="A screenshot of the Azure portal showing a Kusto Query Language (KQL) query for the AHDSDicomAuditLogs table. The example query is filtering for all logs where OperationName is the string index-storage. A table of the query results is underneath." lightbox="media/storage-indexing/diagnostic-logs.png":::
323323

324-
If there's an error when processing an event, the problematic event is enqueued in a "poison queue" called `<queue-name>-poison` in the same storage account. Details about every processed event can be found in the `AHDSDicomAuditLogs` and `AHDSDicomDiagnosticLogs` tables by filtering for all logs where `OperationName = 'index-storage'`. The audit logs only record when the operation started and completed whereas the diagnostic table provides details about each operation including any errors, if any. Operations may be correlated across the tables using `CorrelationId`.
324+
If there's an error when processing an event, the problematic event is enqueued in a "poison queue" called `{queue-name}-poison` in the same storage account. Details about every processed event can be found in the `AHDSDicomAuditLogs` and `AHDSDicomDiagnosticLogs` tables by filtering for all logs where `OperationName = 'index-storage'`. The audit logs only record when the operation started and completed whereas the diagnostic table provides details about each operation including any errors, if any. Operations may be correlated across the tables using `CorrelationId`.
325325

326326
Failures are divided into two types: `User` and `Server`. User errors include any problem connecting to the storage account or with the DICOM file itself, while server errors include any unexpected error that prevents processing. Unlike server errors, the DICOM service doesn't retry user errors.
327327

0 commit comments

Comments
 (0)