Skip to content

Commit 36200d2

Browse files
authored
Merge pull request #173766 from SteveWohl/healthcare-apis-edits-09-27-2021
Made edits to Healthcare APIs FHIR service and Azure API for FHIR TOCs
2 parents 1bdd517 + f6cc5af commit 36200d2

File tree

8 files changed

+242
-47
lines changed

8 files changed

+242
-47
lines changed

.openpublishing.redirection.healthcare-apis.json

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -177,11 +177,6 @@
177177
"redirect_url": "/azure/healthcare-apis/fhir/register-service-azure-ad-client-app",
178178
"redirect_document_id": true
179179
},
180-
{
181-
"source_path_from_root": "/articles/healthcare-apis/security-controls-policy.md",
182-
"redirect_url": "/azure/healthcare-apis/fhir/security-controls-policy",
183-
"redirect_document_id": true
184-
},
185180
{
186181
"source_path_from_root": "/articles/healthcare-apis/tutorial-web-app-fhir-server.md",
187182
"redirect_url": "/azure/healthcare-apis/fhir/tutorial-web-app-fhir-server",
@@ -334,7 +329,7 @@
334329
},
335330
{
336331
"source_path_from_root": "/articles/healthcare-apis/fhir/partner-ecosystem.md",
337-
"redirect_url": "/azure/healthcare-apis/azure-api-for-fhir/partner-ecosystem",
332+
"redirect_url": "/azure/healthcare-apis/azure-api-for-fhir/fhir-features-supported",
338333
"redirect_document_id": true
339334
},
340335
{
@@ -456,6 +451,11 @@
456451
"source_path_from_root": "/articles/healthcare-apis/azure-api-for-fhir/access-fhir-postman-tutorial.md",
457452
"redirect_url": "/azure/healthcare-apis/use-postman",
458453
"redirect_document_id": true
459-
}
454+
},
455+
{
456+
"source_path_from_root": "/articles/healthcare-apis/fhir/security-controls-policy.md",
457+
"redirect_url": "/azure/healthcare-apis/security-controls-policy",
458+
"redirect_document_id": true
459+
},
460460
]
461461
}
Lines changed: 108 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,108 @@
1+
---
2+
title: FHIR Rest API capabilities for Azure API for FHIR
3+
description: This article describes the RESTful interactions and capabilities for Azure API for FHIR.
4+
author: stevewohl
5+
ms.service: healthcare-apis
6+
ms.subservice: fhir
7+
ms.topic: conceptual
8+
ms.date: 09/28/2021
9+
ms.author: cavoeg
10+
---
11+
12+
# FHIR Rest API capabilities for Azure API for FHIR
13+
14+
In this article, we'll cover some of the nuances of the RESTful interactions of Azure API for FHIR.
15+
16+
17+
## Conditional create/update
18+
19+
Azure API for FHIR supports create, conditional create, update, and conditional update as defined by the FHIR specification. One useful header in these scenarios is the [If-Match](https://www.hl7.org/fhir/http.html#concurrency) header. The `If-Match` header is used and will validate the version being updated before making the update. If the `ETag` doesn’t match the expected `ETag`, it will produce the error message *412 Precondition Failed*.
20+
21+
## Delete
22+
23+
[Delete](https://www.hl7.org/fhir/http.html#delete) defined by the FHIR specification requires that after deleting, subsequent non-version specific reads of a resource returns a 410 HTTP status code, and the resource is no longer found through searching. Additionally, Azure API for FHIR enables you to fully delete (including all history) the resource. To fully delete the resource, you can pass a parameter settings `hardDelete` to true (`DELETE {server}/{resource}/{id}?hardDelete=true`). If you don't pass this parameter or set `hardDelete` to false, the historic versions of the resource will still be available.
24+
25+
> [!NOTE]
26+
> If you want to delete only the history, Azure API for FHIR supports a custom operations, `$purge-history`, which allows you to delete the history off of a resource.
27+
28+
## Conditional delete
29+
30+
In addition to delete, Azure API for FHIR supports conditional delete, which allows you to pass a search criteria to delete a resource. By default, the conditional delete will allow you to delete one item at a time. You can also specify the `_count` parameter to delete up to 100 items at a time. Below are some examples of using conditional delete.
31+
32+
To delete a single item using conditional delete, you must specify search criteria that returns a single item.
33+
34+
DELETE `https://{{hostname}}/Patient?identifier=1032704`
35+
36+
You can do the same search but include hardDelete=true to also delete all history.
37+
38+
DELETE `https://{{hostname}}/Patient?identifier=1032704&hardDelete=true`
39+
40+
If you want to delete multiple resources, you can include `_count=100`, which will delete up to 100 resources that match the search criteria.
41+
42+
DELETE `https://{{hostname}}/Patient?identifier=1032704&_count=100`
43+
44+
## Patch and Conditional Patch
45+
46+
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(s) that you want to update in the resource without having to update the entire record. FHIR defines three types of ways to Patch resources in FHIR: JSON Patch, XML Patch, and FHIR Path Patch. The FHIR service supports JSON Patch and Conditional JSON Patch (which allows you to Patch a resource based on a search criteria instead of an ID). To walk through some examples of using JSON Patch, refer to the sample [REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/PatchRequests.http).
47+
48+
### Testing Patch
49+
50+
Within Patch, there is a test operation that allows you to validate that a condition is true before doing the patch. For example, if you wanted to set a patient deceased, only if they were not already marked as deceased, you could use the example below:
51+
52+
PATCH `http://{FHIR-SERVICE-NAME}/Patient/{PatientID}`
53+
Content-type: `application/json-patch+json`
54+
55+
```
56+
[
57+
{
58+
“op”: “test”,
59+
“path”: “/deceasedBoolean”,
60+
“value”: false
61+
},
62+
{
63+
“op”: “replace”
64+
“path”: “/deceasedBoolean”,
65+
“value”: true
66+
}
67+
]
68+
69+
```
70+
71+
### Patch in Bundles
72+
73+
By default, JSON Patch is not supported in Bundle resources. This is because a Bundle only supports with FHIR resources and JSON Patch is not a FHIR resource. To work around this, we'll treat Binary resources with a content-type of `"application/json-patch+json"`as base64 encoding of JSON string when a Bundle is executed. For information about this workaround, log in to [Zulip](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Transaction.20with.20PATCH.20request).
74+
75+
In the example below, we want to change the gender on the patient to female. We have taken the JSON patch `[{"op":"replace","path":"/gender","value":"female"}]` and encoded it to base64.
76+
77+
POST `https://{FHIR-SERVICE-NAME}/`
78+
content-type: `application/json`
79+
80+
```
81+
{
82+
“resourceType”: “Bundle”
83+
“id”: “bundle-batch”,
84+
“type”: “batch”
85+
“entry”: [
86+
{
87+
“fullUrl”: “Patient/{PatientID}”,
88+
“resource”: {
89+
“resourceType”: “Binary”,
90+
“contentType”: “application/json-patch+json”,
91+
“data”: "W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9nZW5kZXIiLCJ2YWx1ZSI6ImZlbWFsZSJ9XQ=="
92+
},
93+
“request”: {
94+
“method”: “PATCH”,
95+
“url”: “Patient/{PatientID}”
96+
}
97+
}
98+
]
99+
}
100+
101+
```
102+
103+
## Next steps
104+
105+
In this article, you learned about some of the REST capabilities of Azure API for FHIR. Next, you can learn more about the key aspects to searching resources in FHIR.
106+
107+
>[!div class="nextstepaction"]
108+
>[Overview of search in Azure API for FHIR](overview-of-search.md)

articles/healthcare-apis/azure-api-for-fhir/partner-ecosystem.md

Lines changed: 0 additions & 30 deletions
This file was deleted.

articles/healthcare-apis/azure-api-for-fhir/toc.yml

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -84,7 +84,7 @@ items:
8484
- name: Configure settings
8585
expanded: false
8686
items:
87-
- name: Configure another Azure API for FHIR settings
87+
- name: Configure other Azure API for FHIR settings
8888
href: azure-api-for-fhir-additional-settings.md
8989
- name: Configure Azure RBAC
9090
href: configure-azure-rbac.md
@@ -167,6 +167,8 @@ items:
167167
href: iot-data-flow.md
168168
- name: Azure IoT Connector for FHIR (preview) mapping templates
169169
href: iot-mapping-templates.md
170+
- name: FHIR Rest API capabilities
171+
href: fhir-rest-api-capabilities.md
170172
- name: Security
171173
items:
172174
- name: Security controls by Azure Policy
@@ -179,8 +181,6 @@ items:
179181
href: fhir-features-supported.md
180182
- name: GitHub Projects
181183
href: fhir-github-projects.md
182-
- name: Partner ecosystem
183-
href: partner-ecosystem.md
184184
- name: Reference
185185
items:
186186
- name: Azure CLI
Lines changed: 112 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,112 @@
1+
---
2+
title: FHIR Rest API capabilities for Azure Healthcare APIs FHIR service
3+
description: This article describes the RESTful interactions and capabilities for Azure Healthcare APIs FHIR service.
4+
author: stevewohl
5+
ms.service: healthcare-apis
6+
ms.subservice: fhir
7+
ms.topic: conceptual
8+
ms.date: 09/28/2021
9+
ms.author: cavoeg
10+
---
11+
12+
# FHIR Rest API capabilities for Azure Healthcare APIs FHIR service
13+
14+
In this article, we'll cover some of the nuances of the RESTful interactions of Azure Healthcare APIs FHIR service (hereby called the FHIR service).
15+
16+
17+
## Conditional create/update
18+
19+
The FHIR service supports create, conditional create, update, and conditional update as defined by the FHIR specification. One useful header in these scenarios is the [If-Match](https://www.hl7.org/fhir/http.html#concurrency) header. The `If-Match` header is used and will validate the version being updated before making the update. If the `ETag` doesn’t match the expected `ETag`, it will produce the error message *412 Precondition Failed*.
20+
21+
## Delete
22+
23+
[Delete](https://www.hl7.org/fhir/http.html#delete) defined by the FHIR specification requires that after deleting, subsequent non-version specific reads of a resource returns a 410 HTTP status code, and the resource is no longer found through searching. Additionally, the FHIR service enables you to fully delete (including all history) the resource. To fully delete the resource, you can pass a parameter settings `hardDelete` to true (`DELETE {server}/{resource}/{id}?hardDelete=true`). If you don't pass this parameter or set `hardDelete` to false, the historic versions of the resource will still be available.
24+
25+
> [!NOTE]
26+
> If you want to delete only the history, the FHIR service supports a custom operations, `$purge-history`, which allows you to delete the history off of a resource.
27+
28+
## Conditional delete
29+
30+
In addition to delete, the FHIR service supports conditional delete, which allows you to pass a search criteria to delete a resource. By default, the conditional delete allows you to delete one item at a time. You can also specify the `_count` parameter to delete up to 100 items at a time. Below are some examples of using conditional delete.
31+
32+
To delete a single item using conditional delete, you must specify search criteria that returns a single item.
33+
34+
DELETE `https://{{hostname}}/Patient?identifier=1032704`
35+
36+
You can do the same search but include hardDelete=true to also delete all history.
37+
38+
DELETE `https://{{hostname}}/Patient?identifier=1032704&hardDelete=true`
39+
40+
If you want to delete multiple resources, you can include `_count=100`, which will delete up to 100 resources that match the search criteria.
41+
42+
DELETE `https://{{hostname}}/Patient?identifier=1032704&_count=100`
43+
44+
## Patch and Conditional Patch
45+
46+
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(s) that you want to update in the resource without having to update the entire record. FHIR defines three types of ways to Patch resources in FHIR: JSON Patch, XML Patch, and FHIR Path Patch. The FHIR service support JSON Patch and Conditional JSON Patch (which allows you to Patch a resource based on a search criteria instead of an ID). To walk through some examples of using JSON Patch, refer to the sample [REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/PatchRequests.http).
47+
48+
### Testing Patch
49+
50+
Within Patch, there is a test operation that allows you to validate that a condition is true before doing the patch. For example, if you want to set a patient as deceased (only if they're not already marked as deceased) you can use the example below:
51+
52+
PATCH `http://{FHIR-SERVICE-NAME}/Patient/{PatientID}`
53+
Content-type: `application/json-patch+json`
54+
55+
```
56+
[
57+
{
58+
“op”: “test”,
59+
“path”: “/deceasedBoolean”,
60+
“value”: false
61+
},
62+
{
63+
“op”: “replace”
64+
“path”: “/deceasedBoolean”,
65+
“value”: true
66+
}
67+
]
68+
69+
```
70+
71+
### Patch in Bundles
72+
73+
By default, JSON Patch is not supported in Bundle resources. This is because a Bundle only supports with FHIR resources and JSON Patch is not a FHIR resource. To work around this, we'll treat Binary resources with a content-type of `"application/json-patch+json"`as base64 encoding of JSON string when a Bundle is executed. For information about this workaround, log in to [Zulip](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Transaction.20with.20PATCH.20request).
74+
75+
In the example below, we want to change the gender on the patient to female. We've taken the JSON patch `[{"op":"replace","path":"/gender","value":"female"}]` and encoded it to base64.
76+
77+
POST `https://{FHIR-SERVICE-NAME}/`
78+
content-type: `application/json`
79+
80+
```
81+
{
82+
“resourceType”: “Bundle”
83+
“id”: “bundle-batch”,
84+
“type”: “batch”
85+
“entry”: [
86+
{
87+
“fullUrl”: “Patient/{PatientID}”,
88+
“resource”: {
89+
“resourceType”: “Binary”,
90+
“contentType”: “application/json-patch+json”,
91+
“data”: "W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9nZW5kZXIiLCJ2YWx1ZSI6ImZlbWFsZSJ9XQ=="
92+
},
93+
“request”: {
94+
“method”: “PATCH”,
95+
“url”: “Patient/{PatientID}”
96+
}
97+
}
98+
]
99+
}
100+
101+
```
102+
103+
## Next steps
104+
105+
In this article, you learned about some of the REST capabilities of the FHIR service. Next, you can learn more about the key aspects to searching resources in the FHIR service.
106+
107+
>[!div class="nextstepaction"]
108+
>[Overview of FHIR search](overview-of-search.md)
109+
110+
111+
112+

articles/healthcare-apis/fhir/toc.yml

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -85,12 +85,12 @@ items:
8585

8686
- name: Concepts
8787
items:
88-
- name: Security controls by Azure Policy
89-
href: ./security-controls-policy.md
88+
- name: FHIR Rest API capabilities
89+
href: fhir-rest-api-capabilities.md
9090

9191
- name: Resources
9292
items:
93-
- name: FAQ
93+
- name: FAQs
9494
href: fhir-faq.md
9595
- name: Supported features
9696
href: fhir-features-supported.md

articles/healthcare-apis/fhir/security-controls-policy.md renamed to articles/healthcare-apis/security-controls-policy.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -14,16 +14,16 @@ ms.custom: subject-policy-compliancecontrols
1414
> [!IMPORTANT]
1515
> Azure Healthcare APIs is currently in PREVIEW. The [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) include additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
1616
17-
[Regulatory Compliance in Azure Policy](../../governance/policy/concepts/regulatory-compliance.md)
17+
[Regulatory Compliance in Azure Policy](../governance/policy/concepts/regulatory-compliance.md)
1818
provides Microsoft created and managed initiative definitions, known as _built-ins_, for the
1919
**compliance domains** and **security controls** related to different compliance standards. This
2020
page lists the **compliance domains** and **security controls** for the FHIR service in the Azure Healthcare APIs. You can assign the built-ins for a **security control** individually to help make your Azure resources compliant with the specific standard.
2121

22-
[!INCLUDE [azure-policy-compliancecontrols-introwarning](../../../includes/policy/standards/intro-warning.md)]
22+
[!INCLUDE [azure-policy-compliancecontrols-introwarning](../../includes/policy/standards/intro-warning.md)]
2323

24-
[!INCLUDE [azure-policy-compliancecontrols-healthcare](../../../includes/policy/standards/byrp/microsoft.healthcareapis.md)]
24+
[!INCLUDE [azure-policy-compliancecontrols-healthcare](../../includes/policy/standards/byrp/microsoft.healthcareapis.md)]
2525

2626
## Next steps
2727

28-
- Learn more about [Azure Policy Regulatory Compliance](../../governance/policy/concepts/regulatory-compliance.md).
28+
- Learn more about [Azure Policy Regulatory Compliance](../governance/policy/concepts/regulatory-compliance.md).
2929
- See the built-ins on the [Azure Policy GitHub repo](https://github.com/Azure/azure-policy).

articles/healthcare-apis/toc.yml

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -42,6 +42,11 @@ items:
4242
- name: Logging
4343
href: logging.md
4444

45+
- name: Concepts
46+
items:
47+
- name: Security controls by Azure Policy
48+
href: security-controls-policy.md
49+
4550
- name: Resources
4651
expanded: true
4752
items:

0 commit comments

Comments
 (0)