Merge pull request #235280 from mmitrik/mmitrik/v2-api-changes

Adds DICOM Conformance Statement V2

Author: Court72

articles/healthcare-apis/dicom/api-versioning-dicom-service.md

@@ -14,28 +14,34 @@ ms.author: mmitrik
 
 This reference guide provides you with an overview of the API version policies for the DICOM service. 
 
-All versions of the DICOM APIs will always conform to the DICOMweb™ Standard specifications, but versions may expose different APIs based on the [DICOM Conformance Statement](dicom-services-conformance-statement.md).
-
 ## Specifying version of REST API in requests
 
 The version of the REST API must be explicitly specified in the request URL as in the following example:
 
 `<service_url>/v<version>/studies`
 
 > [!NOTE]
-> Routes without a version are no longer supported.
+> Routes without a version are not supported.
 
 ## Supported versions
 
 Currently the supported versions are:
 
 * v1.0-prerelease
 * v1
+* v2
 
 The OpenAPI Doc for the supported versions can be found at the following url:
 
 `<service_url>/v<version>/api.yaml`
 
+## DICOM Conformance Statement
+All versions of the DICOM APIs will always conform to the DICOMweb™ Standard specifications, but different versions may expose different APIs.  See the specific version of the conformance statement for details:
+
+* [DICOM Conformance Statement v1](dicom-services-conformance-statement.md)
+* [DICOM Conformance Statement v2](dicom-services-conformance-statement-v2.md)
+
+
 ## Prerelease versions
 
 An API version with the label "prerelease" indicates that the version isn't ready for production, and it should only be used in testing environments. These endpoints may experience breaking changes without notice.
@@ -46,18 +52,18 @@ We currently only increment the major version whenever there's a breaking change
 
 Below are some examples of breaking changes (Major version is incremented):
 
-1. Renaming or removing endpoints.
-2. Removing parameters or adding mandatory parameters.
-3. Changing status code.
-4. Deleting a property in a response, or altering a response type at all, but it's okay to add properties to the response.
-5. Changing the type of a property.
-6. Behavior when an API changes such as changes in business logic used to do foo, but it now does bar.
+* Renaming or removing endpoints.
+* Removing parameters or adding mandatory parameters.
+* Changing status code.
+* Deleting a property in a response, or altering a response type at all, but it's okay to add properties to the response.
+* Changing the type of a property.
+* Behavior when an API changes such as changes in business logic used to do foo, but it now does bar.
 
 Non-breaking changes (Version isn't incremented):
 
-1. Addition of properties that are nullable or have a default value.
-2. Addition of properties to a response model.
-3. Changing the order of properties.
+* Addition of properties that are nullable or have a default value.
+* Addition of properties to a response model.
+* Changing the order of properties.
 
 ## Header in response