markdown and editorial updates

Author: KendalBond007

articles/healthcare-apis/fhir/overview.md

@@ -34,11 +34,11 @@ The healthcare industry is rapidly adopting [FHIR®](https://hl7.org/fhir) as th
 
 ### Securely manage health data in the cloud
 
-The FHIR service in Azure Health Data Services makes FHIR data available to clients through a RESTful API. This API is an implementation of the HL7 FHIR API specification. As a managed PaaS offering in Azure, the FHIR service gives organizations a scalable and secure environment for the storage and exchange of Protected Health Information (PHI) in the native FHIR format.  
+The FHIR service in Azure Health Data Services makes FHIR data available to clients through a RESTful API. This API is an implementation of the HL7 FHIR API specification. As a managed PaaS offering in Azure, the FHIR service gives organizations a scalable and secure environment for the storage and exchange of PHI in the native FHIR format.  
 
 ### Free up resources to innovate
 
-Although you can build and maintain your own FHIR server, with the FHIR service in Azure Health Data Services Microsoft handles setting up server components, ensuring all compliance requirements are met so you can focus on building innovative solutions.
+You can build and maintain your own FHIR server. However, with the FHIR service in Azure Health Data Services, Microsoft handles setting up server components, and ensuring all compliance requirements are met, so you can focus on building innovative solutions.
 
 ### Enable interoperability
 
@@ -54,19 +54,19 @@ Because it belongs to the Azure family of services, the FHIR service protects yo
 
 ## Use cases for the FHIR service
 
-FHIR servers are essential for interoperability of health data. The FHIR service is designed as a managed FHIR server with a RESTful API for connecting to a broad range of client systems and applications. Some of the key use cases for the FHIR service are:
+FHIR servers are essential for interoperability of health data. The FHIR service is designed as a managed FHIR server with a RESTful API for connecting to a broad range of client systems and applications. Some of the key use cases for the FHIR service are as follows.
 
 - **Startup app development:** Customers developing a patient- or provider-centric app (mobile or web) can use the FHIR service as a fully managed backend for health data transactions. The FHIR service enables secure transfer of PHI. With SMART on FHIR, app developers can take advantage of the robust identities management in Microsoft Entra ID for authorization of FHIR RESTful API actions.
 
-- **Healthcare ecosystems:** Although EHRs are the primary source of truth in many clinical settings, it's common for providers to have multiple databases that aren’t connected to each other (often because the data is stored in different formats). By using the FHIR service as a conversion layer between these systems, organizations can standardize data in the FHIR format. Ingesting and persisting in FHIR format enables health data querying and exchange across multiple disparate systems.
+- **Healthcare ecosystems:** Although EHRs are the primary source of truth in many clinical settings, it's common for providers to have multiple databases that aren’t connected to each other (often because the data is stored in different formats). Using the FHIR service as a conversion layer between these systems, organizations can standardize data in the FHIR format. Ingesting and persisting in FHIR format enables health data querying and exchange across multiple disparate systems.
 
-- **Research:** Health researchers use the FHIR standard because it gives the community a shared data model and removes barriers to assembling large datasets for machine learning and analytics. With the data conversion and PHI deidentification capabilities in the FHIR service, researchers can prepare HIPAA-compliant data for secondary use before sending the data to Azure Machine Learning and analytics pipelines. The FHIR service's audit logging and alert mechanisms also play an important role in research workflows.
+- **Research:** Health researchers use the FHIR standard because it gives the community a shared data model and removes barriers to assembling large datasets for machine learning and analytics. With the data conversion and PHI de-identification capabilities in the FHIR service, researchers can prepare HIPAA-compliant data for secondary use before sending the data to Azure Machine Learning and analytics pipelines. The FHIR service's audit logging and alert mechanisms also play an important role in research workflows.
 
 ## FHIR platforms from Microsoft
 
 FHIR capabilities from Microsoft are available in three configurations:
 
-- The **FHIR service** is a managed platform as a service (PaaS) that operates as part of Azure Health Data Services. In addition to the FHIR service, Azure Health Data Services includes managed services for other types of health data, such as the DICOM service for medical imaging data and the MedTech service for medical IoT data. All services (FHIR service, DICOM service, and MedTech service) can be connected and administered within an Azure Health Data Services workspace.
+- The **FHIR service** is a managed PaaS that operates as part of Azure Health Data Services. In addition to the FHIR service, Azure Health Data Services includes managed services for other types of health data, such as the DICOM service for medical imaging data, and the MedTech service for medical IoT data. All services (FHIR service, DICOM service, and MedTech service) can be connected and administered within an Azure Health Data Services workspace.
 
 - **Azure API for FHIR** is a managed FHIR server offered as a PaaS in Azure and is easily deployed in the Azure portal. Azure API for FHIR isn't part of Azure Health Data Services and lacks some of the features of the FHIR service.
 

articles/healthcare-apis/fhir/patient-everything.md

@@ -12,7 +12,7 @@ ms.author: kesheth
 
 # Using Patient-everything in FHIR service
 
-The [Patient-everything](https://www.hl7.org/fhir/patient-operation-everything.html) operation is used to provide a view of all resources related to a patient. This operation can be useful to give patients' access to their entire record or for a provider or other user to perform a bulk data download related to a patient. According to the Fast Healthcare Interoperability Resources (FHIR®) specification, Patient-everything returns all the information related to one or more patients described in the resource or context on which this operation is invoked. In the FHIR service in Azure Health Data Services(hereby called FHIR service), Patient-everything is available to pull data related to a specific patient.
+The [Patient-everything](https://www.hl7.org/fhir/patient-operation-everything.html) operation is used to provide a view of all resources related to a patient. This operation can be useful to give patients' access to their entire record, or for a provider or other user to perform a bulk data download related to a patient. According to the Fast Healthcare Interoperability Resources (FHIR®) specification, Patient-everything returns all the information related to one or more patients described in the resource or context on which this operation is invoked. In the FHIR® service in Azure Health Data Services, Patient-everything is available to pull data related to a specific patient.
 
 ## Use Patient-everything
 To call Patient-everything, use the following command:
@@ -24,27 +24,27 @@ GET {FHIRURL}/Patient/{ID}/$everything
 > [!Note]
 > You must specify an ID for a specific patient. If you need all data for all patients, see [$export](../data-transformation/export-data.md). 
 
-FHIR service validates that it can find the patient matching the provided patient ID. If a result is found, the response will be a bundle of type `searchset` with the following information:
+FHIR service validates that it can find the patient matching the provided patient ID. If a result is found, the response is a bundle of type `searchset` with the following information:
 
 * [Patient resource](https://www.hl7.org/fhir/patient.html).
 * Resources that are directly referenced by the patient resource, except [link](https://www.hl7.org/fhir/patient-definitions.html#Patient.link) references that aren't of [see also](https://www.hl7.org/fhir/codesystem-link-type.html#content) or if the `seealso` link references a `RelatedPerson`.
-* If there are `seealso` link reference(s) to other patient(s), the results will include Patient-everything operation against the `seealso` patient(s) listed.
+* If there are `seealso` link references to other patients, the results include Patient-everything operation against the `seealso` patients listed.
 * Resources in the [Patient Compartment](https://www.hl7.org/fhir/compartmentdefinition-patient.html).
 * [Device resources](https://www.hl7.org/fhir/device.html) that reference the patient resource. 
 
 > [!Note]
-> If the patient has more than 100 devices linked to them, only 100 will be returned. 
+> Up to the first 100 devices linked to a patient will be returned.
 
 
 ## Patient-everything parameters
-FHIR service supports the following query parameters. All of these parameters are optional:
+FHIR service supports the following query parameters. All of these parameters are optional.
 
 |Query parameter        |  Description|
 |-----------------------|------------|
 | \_type | Allows you to specify which types of resources will be included in the response. For example, \_type=Encounter would return only `Encounter` resources associated with the patient. |
 | \_since | Will return only resources that have been modified since the time provided. |
 | start | Specifying the start date will pull in resources where their clinical date is after the specified start date. If no start date is provided, all records before the end date are in scope. |
-| end | Specifying the end date will pull in resources where their clinical date is before the specified end date. If no end date is provided, all records after the start date are in scope. |
+| end | Specifying the end date pulls in resources where their clinical date is before the specified end date. If no end date is provided, all records after the start date are in scope. |
 
 > [!Note]
 > This implementation of Patient-everything does not support the _count parameter.
@@ -53,7 +53,7 @@ FHIR service supports the following query parameters. All of these parameters ar
 
 On a patient resource, there's an element called link, which links a patient to other patients or related persons. These linked patients help give a holistic view of the original patient. The link reference can be used when a patient is replacing another patient or when two patient resources have complementary information. One use case for links is when an ADT 38 or 39 HL7v2 message comes. It describes an update to a patient. This update can be stored as a reference between two patients in the link element.
 
-The FHIR specification has a detailed overview of the different types of [patient links](https://www.hl7.org/fhir/valueset-link-type.html#expansion), but we've include a high-level summary:
+The FHIR specification has a detailed overview of the different types of [patient links](https://www.hl7.org/fhir/valueset-link-type.html#expansion), but here we include a high-level summary:
 
 * [replaces](https://www.hl7.org/fhir/codesystem-link-type.html#link-type-replaces) - The Patient resource replaces a different Patient.
 * [refer](https://www.hl7.org/fhir/codesystem-link-type.html#link-type-refer) - Patient is valid, but it's not considered the main source of information. Points to another patient to retrieve additional information.
@@ -69,16 +69,16 @@ The Patient-everything operation in the FHIR service processes patient links in
 
 Right now, [replaces](https://www.hl7.org/fhir/codesystem-link-type.html#link-type-replaces) and [refer](https://www.hl7.org/fhir/codesystem-link-type.html#link-type-refer) links are ignored by the Patient-everything operation, and the linked patient isn't returned in the bundle. 
 
-As described, [seealso](https://www.hl7.org/fhir/codesystem-link-type.html#link-type-seealso) links reference another patient that's considered equally valid to the original. After the Patient-everything operation is run, if the patient has `seealso` links to other patients, the operation runs Patient-everything on each `seealso` link. This means if a patient links to five other patients with a type `seealso` link, we'll run Patient-everything on each of those five patients.
+As described, [seealso](https://www.hl7.org/fhir/codesystem-link-type.html#link-type-seealso) links reference another patient that's considered equally valid to the original. After the Patient-everything operation is run, if the patient has `seealso` links to other patients, the operation runs Patient-everything on each `seealso` link. This means if a patient links to five other patients with a type `seealso` link, we run Patient-everything on each of those five patients.
 
 > [!Note]
 > This is set up to only follow `seealso` links one layer deep. It doesn't process a `seealso` link's `seealso` links.
 
 [![See also flow diagram.](media/patient-everything/see-also-flow.png)](media/patient-everything/see-also-flow.png#lightbox) 
 
-The final link type is [replaced-by](https://www.hl7.org/fhir/codesystem-link-type.html#link-type-replaced-by). In this case, the original patient resource is no longer being used and the `replaced-by` link points to the patient that should be used. This implementation of `Patient-everything` will include by default an operation outcome at the start of the bundle with a warning that the patient is no longer valid. This will also be the behavior when the `Prefer` header is set to `handling=lenient`.
+The final link type is [replaced-by](https://www.hl7.org/fhir/codesystem-link-type.html#link-type-replaced-by). In this case, the original patient resource is no longer being used and the `replaced-by` link points to the patient that should be used. This implementation of `Patient-everything` by default includes an operation outcome at the start of the bundle with a warning that the patient is no longer valid. This will also be the behavior when the `Prefer` header is set to `handling=lenient`.
 
-In addition, you can set the `Prefer` header to `handling=strict` to throw an error instead. In this case, a return of error code 301 `MovedPermanently` indicates that the current patient is out of date and returns the ID for the correct patient that's included in the link. The `ContentLocation` header of the returned error will point to the correct and up-to-date request.
+In addition, you can set the `Prefer` header to `handling=strict` to throw an error instead. In this case, a return of error code 301 `MovedPermanently` indicates that the current patient is out of date and returns the ID for the correct patient that's included in the link. The `ContentLocation` header of the returned error points to the correct and up-to-date request.
 
 > [!Note]
 > If a `replaced-by` link is present, `Prefer: handling=lenient` and results are returned asynchronously in multiple bundles, only an operation outcome is returned in one bundle.
@@ -87,36 +87,37 @@ In addition, you can set the `Prefer` header to `handling=strict` to throw an er
 
 The Patient-everything operation returns results in phases:
 
-1. Phase 1 returns the `Patient` resource itself in addition to any `generalPractitioner` and `managingOrganization` resources ir references.
+1. Phase 1 returns the `Patient` resource itself in addition to any `generalPractitioner` and `managingOrganization` resources it references.
 1. Phase 2 and 3 both return resources in the patient compartment. If the `start` or `end` query parameters are specified, Phase 2 returns resources from the compartment that can be filtered by their clinical date, and Phase 3 returns resources from the compartment that can't be filtered by their clinical date. If neither of these parameters are specified, Phase 2 is skipped and Phase 3 returns all patient-compartment resources.
-1. Phase 4 will return any devices that reference the patient.
+1. Phase 4 returns any devices that reference the patient.
 
-Each phase will return results in a bundle. If the results span multiple pages, the next link in the bundle will point to the next page of results for that phase. After all results from a phase are returned, the next link in the bundle will point to the call to initiate the next phase.
+Each phase returns results in a bundle. If the results span multiple pages, the next link in the bundle will point to the next page of results for that phase. After all results from a phase are returned, the next link in the bundle will point to the call to initiate the next phase.
 
 If the original patient has any `seealso` links, phases 1 through 4 will be repeated for each of those patients. 
 
 ## Examples of Patient-everything 
 
-Here are some examples of using the Patient-everything operation. In addition to these examples, we have a [sample REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/PatientEverythingLinks.http) that illustrates how the `seealso` and `replaced-by` behavior works.  
+Following are some examples of using the Patient-everything operation. In addition to these examples, we have a [sample REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/PatientEverythingLinks.http) that illustrates how the `seealso` and `replaced-by` behavior works.  
 
-To use Patient-everything to query a patient's "everything" between 2010 and 2020, use the following call: 
+To use Patient-everything to query a patient's "everything" between 2010 and 2020, use the following call.
 
 ```json
 GET {FHIRURL}/Patient/{ID}/$everything?start=2010&end=2020
 ``` 
 
-To use Patient-everything to query a patient's Observation and Encounter, use the following call: 
+To use Patient-everything to query a patient's Observation and Encounter, use the following call.
+
 ```json
 GET {FHIRURL}/Patient/{ID}/$everything?_type=Observation,Encounter 
 ```
 
-To use Patient-everything to query a patient's "everything" since 2021-05-27T05:00:00Z, use the following call: 
+To use Patient-everything to query a patient's "everything" since 2021-05-27T05:00:00Z, use the following call. 
 
 ```json
 GET {FHIRURL}/Patient/{ID}/$everything?_since=2021-05-27T05:00:00Z 
 ```
 
-If a patient is found for each of these calls, you'll get back a 200 response with a `Bundle` of the corresponding resources.
+If a patient is found for each of these calls, you'll get a 200 response with a `Bundle` of the corresponding resources.
 
 ## Next steps
 
@@ -125,4 +126,4 @@ Now that you know how to use the Patient-everything operation, you can learn abo
 >[!div class="nextstepaction"]
 >[Overview of FHIR search](overview-of-search.md)
 
-FHIR® is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7. 
+[!INCLUDE [FHIR trademark statement](../includes/healthcare-apis-fhir-trademark.md)]