Apply typo fixes from FHIR-44546

input/pages/app-launch.md

@@ -1,12 +1,12 @@
 The SMART App Launch Framework connects third-party applications to Electronic
 Health Record data, allowing apps to launch from inside or outside the user
 interface of an EHR system. The framework supports apps for use by clinicians,
-patients, and others via a PHR or Patient Portal or any FHIR system where a user can launch an app. It provides a reliable, secure authorization protocol for
+patients, and others via a PHR, Patient Portal, or any FHIR system where a user can launch an app. It provides a reliable, secure authorization protocol for
 a variety of app architectures, including apps that run on an end-user's device
 as well as apps that run on a secure server.
 The Launch Framework supports four key use cases:
 
-1. Patients apps that launch standalone
+1. Patient apps that launch standalone
 2. Patient apps that launch from a portal
 3. Provider apps that launch standalone
 4. Provider apps that launch from a portal
@@ -454,7 +454,7 @@ href="scopes-and-launch-context.html">SMART launch
 context parameters</a>.*
 
 
-The app then instructs the browser to navigate the browser to the EHR's **authorization URL** as
+The app then instructs the browser to navigate to the EHR's **authorization URL** as
 determined above. For example to cause the browser to issue a `GET`:
 
 

input/pages/app-state.md

@@ -5,15 +5,15 @@ configuration data to an EHR's FHIR server. Conformance requirements described
 below apply only to software that implements support for this capability.
 Example use cases include:
 
-* App with no backend storage persists user preferences such as default
+* An app with no backend storage persists user preferences such as default
   screens, shortcuts, or color preferences. Such apps can save preferences to
   the EHR and retrieve them on subsequent launches.
 
-* App maintains encrypted external data sets. Such apps can persist access keys
+* An app maintains encrypted external data sets. Such apps can persist access keys
   to the EHR and retrieve them on subsequent launches, allowing in-app
   decryption and display of external data sets.
 
-**Apps SHALL NOT use `smart-app-state` when data being persisted could be
+**Apps SHALL NOT use `smart-app-state` when the data being persisted could be
 managed directly using FHIR domain models.** For example, an app would never
 persist clinical diagnoses or observations using `smart-app-state`. Such usage
 is prohibited because the standard FHIR API provides safer and more
@@ -433,7 +433,7 @@ types like `https://app.example.org|user-preferences` or
 State types, these could be reviewed through an out-of-band process. This
 situation is expected when one developer supplies a patient-facing app and
 another developer supplies a provider-facing "companion app" that needs to
-query state written by the patient-facing app.
+query the state written by the patient-facing app.
 
 Further consideration is required when granting an app the ability to modify
 global app state (i.e., where `Basic.subject` is absent). Such permissions

input/pages/backend-services.md

@@ -164,7 +164,7 @@ syntax](scopes-and-launch-context.html).  For Backend Services, requested scopes
 will be `system/` scopes (for example `system/Observation.rs`, which requests an
 access token capable of reading all Observations that the client has been
 pre-authorized to access). The use of Backend Services with `user/` and
-`patient/` scopes is not prohibited, but would required out-of-band coordination
+`patient/` scopes is not prohibited, but would require out-of-band coordination
 to establish context (e.g., to establish which user or patient applies).
 
 #### Response
@@ -255,7 +255,7 @@ with the actual token value.)
 
 The resource server SHALL validate the access token and ensure that it has not expired and that its scope covers the requested resource. The method used by the EHR to validate the access token is beyond the scope of this specification but generally involves an interaction or coordination between the EHR’s resource server and the authorization server.
 
-On occasion, an Backend Service may receive a FHIR resource that contains a “reference” to a resource hosted on a different resource server.  The Backend Service SHOULD NOT blindly follow such references and send along its access_token, as the token may be subject to potential theft.   The Backend Service SHOULD either ignore the reference, or initiate a new request for access to that resource.
+On occasion, a Backend Service may receive a FHIR resource that contains a “reference” to a resource hosted on a different resource server.  The Backend Service SHOULD NOT blindly follow such references and send along its access_token, as the token may be subject to potential theft.   The Backend Service SHOULD either ignore the reference, or initiate a new request for access to that resource.
 
 #### Example Request and Response
 

input/pages/brands.md

@@ -66,7 +66,7 @@ Commonly, a single Brand is typically associated with a single patient Portal th
 * *One Brand is associated with multiple Portals*
   * e.g., a hospital may offer more than one patient portal for legacy purposes
   * e.g., a tertiary cancer center may offer one patient portal for adults and another for pediatric patients
-  * Becaues Brand information may be published in multiple places, Organizations include the same `identifier` to facilitate matching, merging, and de-duplication. Apps can merge Brands into a single target Brand's card by displaying the target Brand's title and logo. Within the Brand's card, the app displays a distinct "connect" button for each set of Patient Access Details.
+  * Because Brand information may be published in multiple places, Organizations include the same `identifier` to facilitate matching, merging, and de-duplication. Apps can merge Brands into a single target Brand's card by displaying the target Brand's title and logo. Within the Brand's card, the app displays a distinct "connect" button for each set of Patient Access Details.
 * *One Portal is associated with one Endpoint*
   * e.g., an EHR-based portal that provides access to patient data through a single FHIR R4 endpoint 
 * *One Portal is associated with multiple FHIR Endpoints*

input/pages/client-authentication.md

@@ -1,4 +1,4 @@
 Two different types:
 
-1. [Assymetric (public key)](client-confidential-asymmetric.html) 
+1. [Asymetric (public key)](client-confidential-asymmetric.html) 
 2. [Symmetric (shared secret)](client-confidential-symmetric.html) 

input/pages/client-confidential-asymmetric.md

@@ -156,7 +156,7 @@ tools and client libraries, see [https://jwt.io](https://jwt.io).
     <tr>
       <td><code>jku</code></td>
       <td><span class="label label-info">optional</span></td>
-      <td>The TLS-protected URL to the JWK Set containing the public key(s) accessible without authentication or authorization. When present, this SHALL match the JWKS URL value that the client supplied to the FHIR authorization server at client registration time. When absent, the FHIR authorization server SHOULD fall back on the JWK Set URL or the JWK Set supplied at registration time. See section <a href="#signature-verification">Signature Verification</a> for details.</td>
+      <td>The TLS-protected URL to the JWK Set that contains the public key(s) accessible without authentication or authorization. When present, this SHALL match the JWKS URL value that the client supplied to the FHIR authorization server at client registration time. When absent, the FHIR authorization server SHOULD fall back on the JWK Set URL or the JWK Set supplied at registration time. See section <a href="#signature-verification">Signature Verification</a> for details.</td>
     </tr>
   </tbody>
 </table>
@@ -243,7 +243,7 @@ To resolve a key to verify signatures, a FHIR authorization server SHALL follow
   <li>Attempt to verify the JWK using the key identified in step 3.</li>
 </ol>
 
-To retrieve the keys from a JWKS URL in step 1 or step 2, a FHIR authorization server issues a HTTP GET request that URL to obtain a JWKS response. For example, if a client has registered a JWKS URL of https://client.example.com/path/to/jwks.json, the server retrieves the client's JWKS with a GET request for that URL, including a header of `Accept: application/json`.
+To retrieve the keys from a JWKS URL in step 1 or step 2, a FHIR authorization server issues a HTTP GET request for that URL to obtain a JWKS response. For example, if a client has registered a JWKS URL of https://client.example.com/path/to/jwks.json, the server retrieves the client's JWKS with a GET request for that URL, including a header of `Accept: application/json`.
 
 If an error is encountered during the authentication process, the server SHALL
 respond with an `invalid_client` error as defined by

input/pages/client-confidential-symmetric.md

@@ -1,8 +1,8 @@
 ### Profile Audience and Scope
 
 This profile describes SMART's
-[`client-confidential-symmetric`](conformance.html) authentication mechanism.  It is intended for
-for [SMART App Launch](app-launch.html) clients that can maintain a secret but cannot manage asymmetric keypairs. For client that can manage asymmetric keypairs, [Asymmetric Authentication](client-confidential-asymmetric.html) is preferred. This profile is not intended for [SMART Backend Services](backend-services.html) clients.
+[`client-confidential-symmetric`](conformance.html) authentication mechanism.  It is intended
+for [SMART App Launch](app-launch.html) clients that can maintain a secret but cannot manage asymmetric keypairs. For clients that can manage asymmetric keypairs, [Asymmetric Authentication](client-confidential-asymmetric.html) is preferred. This profile is not intended for [SMART Backend Services](backend-services.html) clients.
 
 ### Authentication using a `client_secret`
 

input/pages/example-app-launch-asymmetric-auth.md

@@ -106,7 +106,7 @@ Generate a PKCE code challenge and verifier, then redirect browser to the `autho
       code_challenge_method=S256
 
 
-Receive authorization code when EHR redirects the browser back to (newlines added for clarity):
+Receive authorization code when EHR redirects the browser back to the endpoint (newlines added for clarity):
 
     https://sharp-lake-word.glitch.me/graph.html?
       code=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb250ZXh0Ijp7Im5lZWRfcGF0aWVudF9iYW5uZXIiOnRydWUsInNtYXJ0X3N0eWxlX3VybCI6Imh0dHBzOi8vc21hcnQuYXJnby5ydW4vL3NtYXJ0LXN0eWxlLmpzb24iLCJwYXRpZW50IjoiODdhMzM5ZDAtOGNhZS00MThlLTg5YzctODY1MWU2YWFiM2M2In0sImNsaWVudF9pZCI6ImRlbW9fYXBwX3doYXRldmVyIiwiY29kZV9jaGFsbGVuZ2VfbWV0aG9kIjoiUzI1NiIsImNvZGVfY2hhbGxlbmdlIjoiWVBYZTdCOGdoS3JqOFBzVDRMNmx0dXBnSTEyTlFKNXZibEIwN0Y0ckdhdyIsInNjb3BlIjoibGF1bmNoL3BhdGllbnQgcGF0aWVudC9PYnNlcnZhdGlvbi5ycyBwYXRpZW50L1BhdGllbnQucnMiLCJyZWRpcmVjdF91cmkiOiJodHRwczovL3NoYXJwLWxha2Utd29yZC5nbGl0Y2gubWUvZ3JhcGguaHRtbCIsImlhdCI6MTYzMzUzMjAxNCwiZXhwIjoxNjMzNTMyMzE0fQ.xilM68Bavtr9IpklYG-j96gTxAda9r4Z_boe2zv3A3E&

input/pages/example-app-launch-public.md

@@ -91,7 +91,7 @@ Generate a PKCE code challenge and verifier, then redirect browser to the `autho
       code_challenge_method=S256
 
 
-Receive authorization code when EHR redirects the browser back to (newlines added for clarity):
+Receive authorization code when EHR redirects the browser back to the endpoint (newlines added for clarity):
 
     https://sharp-lake-word.glitch.me/graph.html?
       code=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb250ZXh0Ijp7Im5lZWRfcGF0aWVudF9iYW5uZXIiOnRydWUsInNtYXJ0X3N0eWxlX3VybCI6Imh0dHBzOi8vc21hcnQuYXJnby5ydW4vL3NtYXJ0LXN0eWxlLmpzb24iLCJwYXRpZW50IjoiODdhMzM5ZDAtOGNhZS00MThlLTg5YzctODY1MWU2YWFiM2M2In0sImNsaWVudF9pZCI6ImRlbW9fYXBwX3doYXRldmVyIiwiY29kZV9jaGFsbGVuZ2VfbWV0aG9kIjoiUzI1NiIsImNvZGVfY2hhbGxlbmdlIjoiWVBYZTdCOGdoS3JqOFBzVDRMNmx0dXBnSTEyTlFKNXZibEIwN0Y0ckdhdyIsInNjb3BlIjoibGF1bmNoL3BhdGllbnQgcGF0aWVudC9PYnNlcnZhdGlvbi5ycyBwYXRpZW50L1BhdGllbnQucnMiLCJyZWRpcmVjdF91cmkiOiJodHRwczovL3NoYXJwLWxha2Utd29yZC5nbGl0Y2gubWUvZ3JhcGguaHRtbCIsImlhdCI6MTYzMzUzMjAxNCwiZXhwIjoxNjMzNTMyMzE0fQ.xilM68Bavtr9IpklYG-j96gTxAda9r4Z_boe2zv3A3E&

input/pages/example-app-launch-symmetric-auth.md

@@ -94,7 +94,7 @@ Generate a PKCE code challenge and verifier, then redirect browser to the `autho
       code_challenge_method=S256
 
 
-Receive authorization code when EHR redirects the browser back to (newlines added for clarity):
+Receive authorization code when EHR redirects the browser back to the endpoint (newlines added for clarity):
 
     https://sharp-lake-word.glitch.me/graph.html?
       code=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb250ZXh0Ijp7Im5lZWRfcGF0aWVudF9iYW5uZXIiOnRydWUsInNtYXJ0X3N0eWxlX3VybCI6Imh0dHBzOi8vc21hcnQuYXJnby5ydW4vL3NtYXJ0LXN0eWxlLmpzb24iLCJwYXRpZW50IjoiODdhMzM5ZDAtOGNhZS00MThlLTg5YzctODY1MWU2YWFiM2M2In0sImNsaWVudF9pZCI6ImRlbW9fYXBwX3doYXRldmVyIiwiY29kZV9jaGFsbGVuZ2VfbWV0aG9kIjoiUzI1NiIsImNvZGVfY2hhbGxlbmdlIjoiWVBYZTdCOGdoS3JqOFBzVDRMNmx0dXBnSTEyTlFKNXZibEIwN0Y0ckdhdyIsInNjb3BlIjoibGF1bmNoL3BhdGllbnQgcGF0aWVudC9PYnNlcnZhdGlvbi5ycyBwYXRpZW50L1BhdGllbnQucnMiLCJyZWRpcmVjdF91cmkiOiJodHRwczovL3NoYXJwLWxha2Utd29yZC5nbGl0Y2gubWUvZ3JhcGguaHRtbCIsImlhdCI6MTYzMzUzMjAxNCwiZXhwIjoxNjMzNTMyMzE0fQ.xilM68Bavtr9IpklYG-j96gTxAda9r4Z_boe2zv3A3E&

input/pages/example-brands.md

@@ -8,7 +8,7 @@ Let's begin by considering a national lab with many locations nationwide.
 
 The configuration below establishes a single top-level Brand with a potentially long list of ExampleLabs addresses. In this configuration there's a single Organization associated with a single portal and endpoint. The organization lists several aliases and addresses.
 
-(An alternative choice for ExampleLabs would be to create an Organization for each state as a sub-brand with its own name, logo, and addresses. This is a decision that ExampleLabs can make based on how they want their brand to appear in patieint-facing apps.)
+(An alternative choice for ExampleLabs would be to create an Organization for each state as a sub-brand with its own name, logo, and addresses. This is a decision that ExampleLabs can make based on how they want their brand to appear in patient-facing apps.)
 
 Based on this configuration, a patient app might display the following cards to a user:
 <div class="bg-info" markdown="1">
@@ -40,7 +40,7 @@ Next, let's look at a Regional health system ("ExampleHealth") that has:
 * Has locations in/around 12 cities
 * Provides EHR for independent affiliates (distinctly branded sites like "ExampleHealth Physicians of Madison" or "ExampleHealth Community Hospital")
 
-The configuration below establishes a single Organiztion for ExampleHealth, with a single portal associated with two FHIR endpoints (one R2, one R4). There are also Organizations for the affiliated providers, each indicating a `partOf`  relationship with ExampleHealth.
+The configuration below establishes a single Organization for ExampleHealth, with a single portal associated with two FHIR endpoints (one R2, one R4). There are also Organizations for the affiliated providers, each indicating a `partOf`  relationship with ExampleHealth.
 
 Based on this configuration, a patient app might display the following cards to a user:
 
@@ -86,7 +86,7 @@ Now let's look at a more complex (but still surprisingly common) scenario where
 * EHR1: "Patient Gateway" for adult patients to help them connect with providers, manage appointments and refill prescriptions.
 * EHR2: "Pediatrics", a patient portal where parents can access their child's information.
 
-The configuration below establishes a single Organiztion for ExampleHospital, with a portal for pediatrics and a portal for adult care, each associated with a distinct endpoint.
+The configuration below establishes a single Organization for ExampleHospital, with a portal for pediatrics and a portal for adult care, each associated with a distinct endpoint.
 
 Based on this configuration, a patient app might display the following cards to a user: