From df0a2a7132c0d0d4cc1dd06eedeaf0ca4089b4e0 Mon Sep 17 00:00:00 2001 From: Josh Mandel Date: Fri, 26 Jan 2024 10:00:02 -0600 Subject: [PATCH] Apply typo fixes from FHIR-44546 --- input/pages/app-launch.md | 6 +++--- input/pages/app-state.md | 8 ++++---- input/pages/backend-services.md | 4 ++-- input/pages/brands.md | 2 +- input/pages/client-authentication.md | 2 +- input/pages/client-confidential-asymmetric.md | 4 ++-- input/pages/client-confidential-symmetric.md | 4 ++-- input/pages/example-app-launch-asymmetric-auth.md | 2 +- input/pages/example-app-launch-public.md | 2 +- input/pages/example-app-launch-symmetric-auth.md | 2 +- input/pages/example-brands.md | 6 +++--- input/pages/index.md | 10 +++++----- input/pages/scopes-and-launch-context.md | 4 ++-- input/pages/task-launch.md | 4 ++-- input/pages/token-introspection.md | 2 +- input/pages/worked_example_id_token.md | 2 +- input/resources/CodeSystem-smart-codes.json | 2 +- ...plementationGuide-hl7.fhir.uv.smart-app-launch.json | 2 +- 18 files changed, 34 insertions(+), 34 deletions(-) diff --git a/input/pages/app-launch.md b/input/pages/app-launch.md index bfc8ed40..0e765778 100644 --- a/input/pages/app-launch.md +++ b/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.* -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`: diff --git a/input/pages/app-state.md b/input/pages/app-state.md index 3fb5a4ba..d613500c 100644 --- a/input/pages/app-state.md +++ b/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 diff --git a/input/pages/backend-services.md b/input/pages/backend-services.md index 7324d931..3cbe52dc 100755 --- a/input/pages/backend-services.md +++ b/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 diff --git a/input/pages/brands.md b/input/pages/brands.md index 3b8247e2..ab18f895 100644 --- a/input/pages/brands.md +++ b/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* diff --git a/input/pages/client-authentication.md b/input/pages/client-authentication.md index 6a6bd8e5..52c65864 100644 --- a/input/pages/client-authentication.md +++ b/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) diff --git a/input/pages/client-confidential-asymmetric.md b/input/pages/client-confidential-asymmetric.md index b3c2355a..3dba9f4c 100755 --- a/input/pages/client-confidential-asymmetric.md +++ b/input/pages/client-confidential-asymmetric.md @@ -156,7 +156,7 @@ tools and client libraries, see [https://jwt.io](https://jwt.io). jku optional - 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 Signature Verification for details. + 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 Signature Verification for details. @@ -243,7 +243,7 @@ To resolve a key to verify signatures, a FHIR authorization server SHALL follow
  • Attempt to verify the JWK using the key identified in step 3.
    • -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 diff --git a/input/pages/client-confidential-symmetric.md b/input/pages/client-confidential-symmetric.md index e4780b1a..f3328e06 100755 --- a/input/pages/client-confidential-symmetric.md +++ b/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` diff --git a/input/pages/example-app-launch-asymmetric-auth.md b/input/pages/example-app-launch-asymmetric-auth.md index 9bf20c3f..b3e4ee55 100644 --- a/input/pages/example-app-launch-asymmetric-auth.md +++ b/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& diff --git a/input/pages/example-app-launch-public.md b/input/pages/example-app-launch-public.md index 565fbec7..93513542 100644 --- a/input/pages/example-app-launch-public.md +++ b/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& diff --git a/input/pages/example-app-launch-symmetric-auth.md b/input/pages/example-app-launch-symmetric-auth.md index fa38fcf8..58d4098f 100644 --- a/input/pages/example-app-launch-symmetric-auth.md +++ b/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& diff --git a/input/pages/example-brands.md b/input/pages/example-brands.md index fd2cfa4a..94667fd7 100644 --- a/input/pages/example-brands.md +++ b/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:
    @@ -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: diff --git a/input/pages/index.md b/input/pages/index.md index b56d814e..2614b1d8 100644 --- a/input/pages/index.md +++ b/input/pages/index.md @@ -4,13 +4,13 @@ This implementation guide describes a set of foundational patterns based on [OAu ### [Discovery of Server Capabilities and Configuration](conformance.html) -SMART defines a discovery document available at `.well-known/smart-configuration` relative to a FHIR Server Base URL, allowing clients to learn the authorization endpoint URLs and features a server supports. This information helps client direct authorization requests to the right endpoint, and helps clients construct an authorization request that the server can support. +SMART defines a discovery document, available at `.well-known/smart-configuration` relative to a FHIR Server Base URL, allowing clients to learn the authorization endpoint URLs and features a server supports. This information helps client direct authorization requests to the right endpoint, and helps clients construct an authorization request that the server can support. ### SMART Defines Two Patterns For Client *Authorization* #### [Authorization via **SMART App Launch**](app-launch.html) -Authorizes a user-facing client application ("App") to connect to a FHIR Server. This pattern allows for "launch context" such as *currently selected patient* to be shared with the app, based on a user's session inside an EHR or other health data software, or based on a user's selection at launch time. Authorization allows for delegation of a user's permissions to the app itself. +Authorizes a user-facing client application ("App") to connect to a FHIR Server. This pattern allows for "launch context" such as a *currently selected patient* to be shared with the app, based on a user's session inside an EHR or other health data software, or based on a user's selection at launch time. Authorization allows for delegation of a user's permissions to the app itself. #### [Authorization via **SMART Backend Services**](backend-services.html) @@ -34,9 +34,9 @@ Authenticates a client using a secret that has been pre-shared between the clien ### [Scopes for Limiting Access](scopes-and-launch-context.html) -SMART uses a language of "scopes" to define specific access permissions that can be delegated to a client application. These scopes draw on FHIR API definitions for interactions, resource types, and search parameters to describe a permissions model. For example, an app might be granted scopes like `user/Encounter.rs`, allowing it to read and search for Encounters that are accessible to the user who has authorized the app. Similarly, a backend service might be granted scopes like `system/Encounter.rs`, allowing it to read and search for Encounters within the overall set of data it is configured to access. User-facing apps can also receive "launch context" to indicate details about the current patient or other aspects of a user's EHR session or a user's selections when launching the app. +SMART uses a language of "scopes" to define specific access permissions that can be delegated to a client application. These scopes draw on FHIR API definitions for interactions, resource types, and search parameters to describe a permissions model. For example, an app might be granted scopes like `user/Encounter.rs`, allowing it to read and search for Encounters that are accessible to the user who has authorized the app. Similarly, a backend service might be granted scopes like `system/Encounter.rs`, allowing it to read and search for Encounters within the overall set of data it is configured to access. User-facing apps can also receive "launch context" to indicate details about the current patient, other aspects of a user's EHR session, or a user's selections when launching the app. -*Note that the scope syntax has changed since SMARTv1. Details are in section [Scopes for requesting FHIR resources](scopes-and-launch-context.html#scopes-for-requesting-fhir-resources).* +*Note that the scope syntax has changed since SMARTv1. Further details are in the section [Scopes for requesting FHIR resources](scopes-and-launch-context.html#scopes-for-requesting-fhir-resources).* ### [Token Introspection](token-introspection.html) @@ -44,7 +44,7 @@ SMART defines a Token Introspection API allowing Resource Servers or software co ### [Patient-Access Brands](brands.html) -SMART defines a publication format for API providers to make branding information available to patient-facing apps. This helps apps offer a "connect to my records" UX where providers appear with the names, logos, and desriptions they choose. +SMART defines a publication format for API providers to make branding information available to patient-facing apps. This helps apps offer a "connect to my records" UX where providers appear with the names, logos, and descriptions they choose. ### [Persisting App State](app-state.html) diff --git a/input/pages/scopes-and-launch-context.md b/input/pages/scopes-and-launch-context.md index 29901a32..a26c7616 100644 --- a/input/pages/scopes-and-launch-context.md +++ b/input/pages/scopes-and-launch-context.md @@ -502,7 +502,7 @@ The application could choose to also provide `launch/patient`, contexts the app would like the EHR to gather. The EHR MAY ignore these hints (for example, if the user is in a workflow where these contexts do not exist). -If an application requests a FHIR Resource scope which is restricted to a single patient (e.g., `patient/*.rs`), and the authorization results in the EHR is granting that scope, the EHR SHALL establish a patient in context. The EHR MAY refuse authorization requests including `patient/` that do not also include a valid `launch`, or it MAY infer the `launch/patient` scope. +If an application requests a FHIR Resource scope which is restricted to a single patient (e.g., `patient/*.rs`), and the authorization results in the EHR granting that scope, the EHR SHALL establish a patient in context. The EHR MAY refuse authorization requests including `patient/` that do not also include a valid `launch`, or it MAY infer the `launch/patient` scope. #### Standalone apps @@ -512,7 +512,7 @@ Requested Scope | Meaning ----------------|--------- `launch/patient` | Need patient context at launch time (FHIR Patient resource). See note below. `launch/encounter` | Need encounter context at launch time (FHIR Encounter resource). -(Others) | This list can be extended by any SMART EHR to support additional context. When specifying resource types, convert the type names to *all lowercase* (e.g., `launch/diagnosticreport`). In situations where the same resource type might be used for more than one purpose (e.g., in a medication reconciliation app, one List of at-home medications and another List of in-hospital medicdations), the app can solicit context with a specific role by appending `?role={role}` (see [example below](#fhircontext-example-medication-reconciliation)). +(Others) | This list can be extended by any SMART EHR to support additional context. When specifying resource types, convert the type names to *all lowercase* (e.g., `launch/diagnosticreport`). In situations where the same resource type might be used for more than one purpose (e.g., in a medication reconciliation app, one List of at-home medications and another List of in-hospital medications), the app can solicit context with a specific role by appending `?role={role}` (see [example below](#fhircontext-example-medication-reconciliation)). {:.grid} Note on `launch/patient`: If an application requests a scope which is restricted to a single patient (e.g., `patient/*.rs`), and the authorization results in the EHR granting that scope, the EHR SHALL establish a patient in context. The EHR MAY refuse authorization requests including `patient/` that do not also include a valid `launch/patient` scope, or it MAY infer the `launch/patient` scope. diff --git a/input/pages/task-launch.md b/input/pages/task-launch.md index 832f8bde..16007779 100644 --- a/input/pages/task-launch.md +++ b/input/pages/task-launch.md @@ -9,9 +9,9 @@ Two profiles are defined: A Task with the profile [task-ehr-launch](StructureDefinition-task-ehr-launch.html), requests an EHR launch with optional `appContext`. -The `Task.for` field, if present indicates the Patient resource to be used in the launch context. +The `Task.for` field, if present, indicates the Patient resource to be used in the launch context. -the `Task.encounter` field, if present indicates the Encounter resource to be used in the launch context. +The `Task.encounter` field, if present, indicates the Encounter resource to be used in the launch context. The input field contains: diff --git a/input/pages/token-introspection.md b/input/pages/token-introspection.md index e8278e3e..6aa578e2 100644 --- a/input/pages/token-introspection.md +++ b/input/pages/token-introspection.md @@ -8,7 +8,7 @@ In addition to the `active` field required by RFC7662 (a boolean indicating whet * `client_id`. As included in the original access token response. The client identifier of the client to which the token was issued. -* `exp`. As included in the original access token response. The integer timestamp indicating when the access token expires. +* `exp`. As included in the original access token response. The integer timestamp indicates when the access token expires. ### Conditional fields in the introspection response diff --git a/input/pages/worked_example_id_token.md b/input/pages/worked_example_id_token.md index b7009322..946db397 100644 --- a/input/pages/worked_example_id_token.md +++ b/input/pages/worked_example_id_token.md @@ -101,7 +101,7 @@ print(id_token) ### Validating and using an ID Token (for clients) -A client obtains the ID Token as the result of an authorization operation. To validate the token, the client fetches the servers's public key, and then decodes the token. While decoding the token, the client must verify that the audience ('aud') matches its own client_id +A client obtains the ID Token as the result of an authorization operation. To validate the token, the client fetches the server's public key, and then decodes the token. While decoding the token, the client must verify that the audience ('aud') matches its own client_id diff --git a/input/resources/CodeSystem-smart-codes.json b/input/resources/CodeSystem-smart-codes.json index fab8ac3c..ed02f820 100644 --- a/input/resources/CodeSystem-smart-codes.json +++ b/input/resources/CodeSystem-smart-codes.json @@ -5,7 +5,7 @@ "name": "SmartOnFhirCodes", "id": "smart-codes", "title": "SMART on FHIR terminology.", - "description": "Codes used to in profiles related to SMART on FHIR.", + "description": "Codes used in profiles related to SMART on FHIR.", "url": "http://hl7.org/fhir/smart-app-launch/CodeSystem/smart-codes", "concept": [ { diff --git a/input/resources/ImplementationGuide-hl7.fhir.uv.smart-app-launch.json b/input/resources/ImplementationGuide-hl7.fhir.uv.smart-app-launch.json index e2060cb1..e79cc953 100644 --- a/input/resources/ImplementationGuide-hl7.fhir.uv.smart-app-launch.json +++ b/input/resources/ImplementationGuide-hl7.fhir.uv.smart-app-launch.json @@ -58,7 +58,7 @@ { "id": "PAB", "name": "Patient Access Brand Examples", - "description": "The follow examples demonstrate use of Patient Access Brands. See [example-brands](./example-brands.html) for a guided tour." + "description": "The following examples demonstrate use of Patient Access Brands. See [example-brands](./example-brands.html) for a guided tour." }, { "id": "SMARTAppState",