Merge pull request #261514 from mmitrik/revert-256493-mmitrik/bulk-update

Revert "Adds new article for bulk update operation"

Author: v-dirichards

articles/healthcare-apis/.openpublishing.redirection.healthcare-apis.json

@@ -491,6 +491,10 @@
        "redirect_url": "/azure/healthcare-apis/dicom/export-files",
        "redirect_document_id": true     
     },     
+    {  "source_path_from_root": "/articles/healthcare-apis/dicom/update-files.md",
+       "redirect_url": "/azure/healthcare-apis/dicom/overview",
+       "redirect_document_id": false     
+    },
       {
           "source_path_from_root": "/articles/healthcare-apis/fhir/configure-azure-rbac-for-fhir.md",
           "redirect_url": "/azure/healthcare-apis/configure-azure-rbac",

articles/healthcare-apis/dicom/dicom-change-feed-overview.md

@@ -11,7 +11,7 @@ ms.author: mmitrik
 
 # Change feed overview
 
-The change feed provides logs of all the changes that occur in the DICOM® service. The change feed provides ordered, guaranteed, immutable, and read-only logs of these changes. The change feed offers the ability to go through the history of DICOM service and acts upon the creates, updates, and deletes in the service.
+The change feed provides logs of all the changes that occur in the DICOM® service. The change feed provides ordered, guaranteed, immutable, and read-only logs of these changes. The change feed offers the ability to go through the history of DICOM service and acts upon the creates and deletes in the service.
 
 Client applications can read these logs at any time in batches of any size. The change feed enables you to build efficient and scalable solutions that process change events that occur in your DICOM service.
 
@@ -38,7 +38,7 @@ Sequence            | long      | The unique ID per change event
 StudyInstanceUid    | string    | The study instance UID
 SeriesInstanceUid   | string    | The series instance UID
 SopInstanceUid      | string    | The sop instance UID
-Action              | string    | The action that was performed - either `create`, `update`, or `delete`
+Action              | string    | The action that was performed - either `create` or `delete`
 Timestamp           | datetime  | The date and time the action was performed in UTC
 State               | string    | [The current state of the metadata](#states)
 Metadata            | object    | Optionally, the current DICOM metadata if the instance exists
@@ -168,7 +168,7 @@ Content-Type: application/json
     "StudyInstanceUid": "{uid}",
     "SeriesInstanceUid": "{uid}",
     "SopInstanceUid": "{uid}",
-    "Action": "create|update|delete",
+    "Action": "create|delete",
     "Timestamp": "2020-03-05T07:13:16.4834Z",
     "State": "current|replaced|deleted",
     "Metadata": {

articles/healthcare-apis/dicom/dicom-services-conformance-statement-v2.md

@@ -34,9 +34,6 @@ Additionally, the following nonstandard API(s) are supported:
 
 * [Change Feed](dicom-change-feed-overview.md)
 * [Extended Query Tags](dicom-extended-query-tags-overview.md)
-* [Bulk Update](update-files.md)
-* [Bulk Import](import-files.md)
-* [Export](export-dicom-files.md)
 
 The service uses REST API versioning. The version of the REST API must be explicitly specified as part of the base URL, as in the following example:
 
@@ -395,16 +392,6 @@ When specifying a particular frame to return, frame indexing starts at 1.
 
 The `quality` query parameter is also supported. An integer value between `1` and `100` inclusive (1 being worst quality, and 100 being best quality) might be passed as the value for the query parameter. This parameter is used for images rendered as `jpeg`, and is ignored for `png` render requests. If not specified the parameter defaults to `100`.
 
-### Retrieve original version
-Using the [bulk update](update-files.md) operation will allow you to retrieve either the original and latest version of a study, series, or instance.  The latest version of a study, series, or instance is always returned by default.  The original version may be returned by setting the `msdicom-request-original` header to `true`.  An example request is shown below:
-
-```http 
-GET ../studies/{study}/series/{series}/instances/{instance}
-Accept: multipart/related; type="application/dicom"; transfer-syntax=*
-msdicom-request-original: true
-Content-Type: application/dicom
- ```
-
 ### Retrieve response status codes
 
 | Code                         | Description |
@@ -439,7 +426,7 @@ The following `Accept` header(s) are supported for searching:
 * `application/dicom+json`
 
 ### Search changes from v1
-In the v1 API and continued for v2, if an [extended query tag](dicom-extended-query-tags-overview.md) has any errors, because one or more of the existing instances had a tag value that couldn't be indexed, then subsequent search queries containing the extended query tag returns `erroneous-dicom-attributes` as detailed in the [documentation](dicom-extended-query-tags-overview.md#tag-query-status). However, tags (also known as attributes) with validation warnings from STOW-RS are **not** included in this header. If a store request results in validation warnings for [searchable attributes](#searchable-attributes) at the time the [instance was stored](#store-changes-from-v1), those attributes may not be used to search for the stored instance. However, any [searchable attributes](#searchable-attributes) that failed validation will be able to return results if the values are overwritten by instances in the same study/series that are stored after the failed one, or if the values are already stored correctly by a previous instance. If the attribute values aren't overwritten, then they won't produce any search results.
+In the v1 API and continued for v2, if an [extended query tag](dicom-extended-query-tags-overview.md) has any errors, because one or more of the existing instances had a tag value that couldn't be indexed, then subsequent search queries containing the extended query tag returns `erroneous-dicom-attributes` as detailed in the [documentation](dicom-extended-query-tags-overview.md#tag-query-status). However, tags (also known as attributes) with validation warnings from STOW-RS are **not** included in this header. If a store request results in validation warnings for [searchable attributes](#searchable-attributes) at the time the [instance was stored](#store-changes-from-v1), those attributes may not be used to search for the stored instance. However, any [searchable attributes](#searchable-attributes) that failed validation will be able to return results if the values are overwritten by instances in the same study/series that are stored after the failed one, or if the values are already stored correctly by a previous instance. If the attribute values are not overwritten, then they will not produce any search results.
 
 An attribute can be corrected in the following ways:
 - Delete the stored instance and upload a new instance with the corrected data

articles/healthcare-apis/dicom/toc.yml

@@ -70,8 +70,6 @@ items:
           href: dicom-change-feed-overview.md
         - name: Extended query tags
           href: dicom-extended-query-tags-overview.md
-        - name: Bulk update
-          href: update-files.md
     - name: API versioning
       expanded: false
       items: