Merge pull request #310453 from evachen96/evachjan14releasenotes

Update release notes and metahistory documentation

Author: JillGrant615

articles/healthcare-apis/fhir/fhir-versioning-policy-and-history-management.md

@@ -71,13 +71,13 @@ Changing the versioning policy, either at a system level or resource level, won'
 > The query parameter _summary=count and _count=0 can be added to _history endpoint to get a count of all versioned resources. This count includes soft deleted resources.
 
 ## Metadata-only updates and versioning
-If the versioning policy is set to either `versioned` or `version-update`, metadata-only updates (changes to FHIR resources that only affect the metadata) increment the resource version, create a new version, and save the old version as a historical record. If you are making metadata-only changes using PUT updates, you can use the query parameter _meta-history for PUT updates to configure whether or not the old version is saved as a historical record.
+If the versioning policy is set to either `versioned` or `version-update`, metadata-only updates (changes to FHIR resources that only affect the metadata) increment the resource version, create a new version, and save the old version as a historical record. If you are making metadata-only changes using PUT or PATCH updates, you can use the query parameter _meta-history for PUT and PATCH updates to configure whether or not the old version is saved as a historical record.
 - `_meta-history=true` is set by default. By default, the resource version is incremented, a new version is created, and the old version is saved as a historical record. The lastUpdated timestamp is updated to reflect the change.
 - `_meta-history=false` The `_meta-history` parameter can be configured to `false`. This means that the resource version is incremented, a new version is created, but the old version is not saved as a historical record. The lastUpdated timestamp is also still updated to reflect the change. This configuration can be used to help reduce data storage when making metadata-only updates.  
 
 
-### Example with `_meta-history=false` 
-To demonstrate the use of the `_meta-history` parameter, follow this example:
+### Example of `_meta-history=false` with PUT
+To demonstrate the use of the `_meta-history` parameter with PUT, follow this example:
 1. Create a resource:  
 `PUT <fhir server>/Patient/test-patient`
 ```
@@ -127,10 +127,85 @@ To demonstrate the use of the `_meta-history` parameter, follow this example:
     ]
 }
 ```
-5. This will increment resource version and create a new version 3, but the old version 2 will not be saved as a historical record. To see this, run: `GET <fhir server>/Patient/test-patient/_history`. Two versions should be returned, versions 1 and 3. Please note that `_meta-history=false` query parameter only affects metadata-only changes made using PUT. Using the query parameter to make metadata updates along with other non-metadata field value changes will increment the resource version and save the old version as a historical record.
+5. This will increment resource version and create a new version 3, but the old version 2 will not be saved as a historical record. To see this, run: `GET <fhir server>/Patient/test-patient/_history`. Two versions should be returned, versions 1 and 3. Please note that `_meta-history=false` query parameter only affects metadata-only changes made using PUT or PATCH. Using the query parameter to make metadata updates along with other non-metadata field value changes will increment the resource version and save the old version as a historical record.
 
 
+### Example of `_meta-history=false` with PATCH
+To demonstrate the use of the `_meta-history` parameter with PATCH, follow this example:
 
+1. Create a resource:  
+`PUT <fhir server>/Patient/test-patient`
+```
+{
+    "id": "test-patient",
+    "resourceType": "Patient",
+    "name": [
+        {
+            "family": "Doe",
+            "given": [ "John" ]
+        }
+    ]
+}
+```
+2. Create a new version of the resource with `PUT <fhir server>/Patient/test-patient`. This will have version 2.
+```
+{
+    "id": "test-patient",
+    "resourceType": "Patient",
+    "meta": {
+        "tag": [
+            {
+                "system": "test",
+                "code": "test"
+            }
+        ]
+    },
+    "name": [
+        {
+            "family": "Doe",
+            "given": [ "Jane" ]
+        }
+    ]
+}
+```
+3. Run: `GET <fhir server>/Patient/test-patient/_history`. Two versions should be returned, versions 1 and 2.
+4. Use PATCH to make a metadata-only update with `_meta-history=false` query parameter. The example uses PATCH to update only the Patient.meta.tag.system value. More information about PATCH [here](rest-api-capabilities.md#patch-and-conditional-patch).
+
+Using PATCH with FHIRPath patch:  
+`PATCH <fhir server>/Patient/test-patient?_meta-history=false`  
+`Content-type: application/fhir+json`
+
+
+``` 
+
+{
+  "resourceType": "Parameters",
+  "parameter": [
+    {
+      "name": "operation",
+      "part": [
+        { "name": "type",  "valueCode": "replace" },
+        { "name": "path",  "valueString": "Patient.meta.tag[0].system" },
+        { "name": "value", "valueUri": "test2" }
+      ]
+    }
+  ]
+}
+```
+
+Using PATCH with JSON Patch:
+`PATCH <fhir server>/Patient/test-patient?_meta-history=false`  
+`Content-type: application/json-patch+json`  
+```
+[
+  {
+    "op": "replace",
+    "path": "/meta/tag/0/system",
+    "value": "test2"
+  }
+]
+```
+5. This will increment resource version and create a new version 3, but the old version 2 will not be saved as a historical record. To see this, run: `GET <fhir server>/Patient/test-patient/_history`. Two versions should be returned, versions 1 and 3. Please note that `_meta-history=false` query parameter only affects metadata-only changes made using PUT or PATCH. Using the query parameter to make metadata updates along with other non-metadata field value changes will increment the resource version and save the old version as a historical record.
 
 ## Next steps
 

articles/healthcare-apis/fhir/rest-api-capabilities.md

@@ -91,6 +91,8 @@ For more information on history and version management visit [FHIR versioning po
 Patch is a valuable RESTful operation when you need to update only a portion of the FHIR resource. Using patch allows you to specify the element that you want to update in the resource without having to update the entire record. FHIR defines three ways to patch resources: JSON Patch, XML Patch, and FHIRPath Patch. The FHIR service supports JSON Patch and FHIRPath Patch, along with Conditional JSON Patch and Conditional FHIRPath Patch (which allows you to patch a resource based on a search criteria instead of a resource ID).
 For examples, refer to the [FHIRPath Patch REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/FhirPatchRequests.http) and the [JSON Patch REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/JsonPatchRequests.http). For more information, see [HL7 documentation for patch operations with FHIR](https://www.hl7.org/fhir/http.html#patch).
 
+
+
 > [!NOTE]
 > When using `PATCH` against STU3, and if you are requesting a History bundle, the patched resource's `Bundle.entry.request.method` is mapped to `PUT`. This is because STU3 doesn't contain a definition for the `PATCH` verb in the [HTTPVerb value set](http://hl7.org/fhir/STU3/valueset-http-verb.html).
 
@@ -179,6 +181,13 @@ Content-Type: `application/json`
 }
 ```
 
+#### Patch with `_meta-history` parameter
+The FHIR service supports the `_meta-history` query parameter with both `PUT` and `PATCH` operations. This parameter allows you to control whether metadata-only changes to a resource create a new historical version of the resource or not. By default, any change to a resource, including metadata-only changes, creates a new version and saves the previous version as a historical record. When you set the `_meta-history` parameter to `false`, metadata-only changes do not create a new version, and the previous version is not saved as a historical record. This feature is useful for scenarios where frequent metadata updates are made, and you want to avoid cluttering the resource history with numerous versions that only differ in metadata. For more information and examples, see [FHIR versioning policy and history management](fhir-versioning-policy-and-history-management.md#metadata-only-updates-and-versioning).
+
+`PATCH <fhir server>/Patient/test-patient?_meta-history=false`  
+
+
+
 ## Troubleshooting 
 
 **Can I delete multiple patient observations or all patient resources in a single API call?**

articles/healthcare-apis/release-notes-2025.md

@@ -45,7 +45,7 @@ Release notes describe features, enhancements, and bug fixes released in 2025 fo
 SMART on FHIR v2.0.0 sample is available now on the Azure Health Data and AI Samples open source repo. For more information, visit [`SMART on FHIR`](./fhir/smart-on-fhir.md).
 
 
-**Metadata-only updates and versioning configuration**: Introduced new query parameter "_meta-history" for PUT updates when versioning policy is set to either "versioned" or "version-update" to configure whether or not the old version is saved as a historical record. "_meta-history = true" is the default. By default, the resource version is incremented, a new version is created, and the old version is saved as a historical record. "_meta-history=false" can be configured so that the resource version is incremented, a new version is created, but the old version is not saved as a historical record. For more information, visit [metadata-only updates and versioning](./fhir/fhir-versioning-policy-and-history-management.md#metadata-only-updates-and-versioning).
+**Metadata-only updates and versioning configuration with PUT**: Introduced new query parameter "_meta-history" for PUT updates when versioning policy is set to either "versioned" or "version-update" to configure whether or not the old version is saved as a historical record. "_meta-history = true" is the default. By default, the resource version is incremented, a new version is created, and the old version is saved as a historical record. "_meta-history=false" can be configured so that the resource version is incremented, a new version is created, but the old version is not saved as a historical record. For more information, visit [metadata-only updates and versioning](./fhir/fhir-versioning-policy-and-history-management.md#metadata-only-updates-and-versioning).
 
 **Composite search parameter collation fix**:  Corrected inconsistent collation handling for Token-String composite search parameters.
 

articles/healthcare-apis/release-notes-2026.md

@@ -20,6 +20,10 @@ Release notes describe features, enhancements, and bug fixes released in 2026 fo
 ## January 2026
 ### FHIR service
 
+**Hard delete now supported inside transaction bundles**:  Hard deletes are now allowed inside transaction bundles. Previously, neither hard deletes nor conditional deletes were supported. Conditional deletes are still not allowed.
+
+**Metadata-only updates and versioning configuration with PATCH**: Introduced new query parameter "_meta-history" for PATCH updates when versioning policy is set to either "versioned" or "version-update" to configure whether or not the old version is saved as a historical record. "_meta-history = true" is the default. By default, the resource version is incremented, a new version is created, and the old version is saved as a historical record. "_meta-history=false" can be configured so that the resource version is incremented, a new version is created, but the old version is not saved as a historical record. For more information, visit [metadata-only updates and versioning](./fhir/fhir-versioning-policy-and-history-management.md#metadata-only-updates-and-versioning).
+
 **Updates to responses for update and deletion of FHIR spec-defined search parameters**: There are a few updates to the behaviors and responses for update and deletion of FHIR spec-defined search parameters:
   - Deletion of out-of-box FHIR spec-defined search parameters previously returned a "204 No Content" and the parameter was not deleted. The response is updated to correctly return "405 Method Not Allowed."
   - Update of out-of-box FHIR spec-defined search parameters previously returned "201 Created", which can cause unintended behavior. The response is updated to return "405 Method Not Allowed." If you wish to update an out-of-box FHIR spec-defined search parameter, please create a new custom search parameter with a different URL.