Nit: remove trailing whitespace from all lines

Author: kpshek

docs/specification/1.0.md

@@ -5,7 +5,7 @@
 
 ## Overview
 
-The CDS Hooks specification describes the RESTful APIs and interactions between EHRs and CDS Services. All data exchanged through the RESTful APIs MUST BE sent and received as JSON structures, and MUST be transmitted over channels secured using Transport Layer Security (TLS). 
+The CDS Hooks specification describes the RESTful APIs and interactions between EHRs and CDS Services. All data exchanged through the RESTful APIs MUST BE sent and received as JSON structures, and MUST be transmitted over channels secured using Transport Layer Security (TLS).
 
 ### Conformance Language
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC2119](https://tools.ietf.org/html/rfc2119).
@@ -28,7 +28,7 @@ Developers of CDS Services SHALL provide a stable endpoint for allowing EHRs to
 A CDS Service provider SHALL expose its Discovery endpoint at"
 
 ```shell
-{baseURL}/cds-services  
+{baseURL}/cds-services
 ```
 ### HTTP Request
 
@@ -168,7 +168,7 @@ Two optional enhancements are provided.  First, FHIR resources may be obtained b
 
 The second enhancement enables the CDS Service to retrieve FHIR resources for itself, but to do so more efficiently than if it were required to request and obtain its own authorization.  If the EHR decides to have the CDS Service fetch its own FHIR resources, the EHR obtains and passes directly to the CDS Service a bearer token issued for the CDS Service's use in executing FHIR API calls against the EHR FHIR server to obtain the required resources.  Some EHRs may choose to pass prefetched data, along with a bearer token for the CDS Service to use if additional resources are required.  Each EHR may decide which approach, or combination, is preferred, based on performance considerations and assessment of attendant security and safety risks. For more detail, see the [FHIR Resource Access](#fhir-resource-access) section below.
 
-Similarly, each EHR will decide what FHIR resources to authorize and to prefetch, based on the CDS Service description's "prefetch" request and on the provider's assessment of the "minimum necessary."  The EHR provider and the CDS Service provider will negotiate the set of FHIR resources to be provided, and how these data will be provided, as part of their service agreement. 
+Similarly, each EHR will decide what FHIR resources to authorize and to prefetch, based on the CDS Service description's "prefetch" request and on the provider's assessment of the "minimum necessary."  The EHR provider and the CDS Service provider will negotiate the set of FHIR resources to be provided, and how these data will be provided, as part of their service agreement.
 
 ### Prefetch Template
 
@@ -211,7 +211,7 @@ An EHR MAY choose to honor some or all of the desired prefetch templates, and is
 
 Regardless of how the EHR satisfies the prefetch templates (if at all), the prefetched data given to the CDS Service MUST BE equivalent to the data the CDS Service would receive if it were making its own call to the EHR FHIR server using the parameterized prefetch template.
 
-The resulting response, which MUST BE rendered in a single page — no "next page" links allowed — is passed along to the CDS Service using the `prefetch` parameter (see below for a complete example). 
+The resulting response, which MUST BE rendered in a single page — no "next page" links allowed — is passed along to the CDS Service using the `prefetch` parameter (see below for a complete example).
 
 The CDS Service MUST NOT receive any prefetch template key that the EHR chooses not to satisfy; in which case the prefetch template key SHOULD NOT be sent. Similarly, if the EHR encounters an error while prefetching any data, the prefetch template key SHOULD NOT be sent to the CDS Service. If the EHR has no data to populate a template prefetch key, the prefetch template key MUST have a value of __null__. It is the CDS Service's responsibility to check prefetched data against its template to determine what requests were satisfied (if any) and to manually retrieve any additional necessary data. If the CDS Service is unable to obtain required data because it cannot access the FHIR server and the request did not contain the necessary prefetch keys, the service SHALL respond with an HTTP 412 Precondition Failed status code.
 
@@ -285,7 +285,7 @@ To reduce the implementation burden on EHRs that support CDS Services, CDS Hooks
 * the `_count` parameter to limit the number of results returned
 * the `_sort` parameter to allow for _most recent_ and _first_ queries
 
-### FHIR Resource Access 
+### FHIR Resource Access
 
 The CDS Service is able to use the EHR's FHIR server to obtain any FHIR resources it requires beyond those provided by the EHR as prefetched data. This is similar to the approach used by SMART on FHIR wherein the SMART app requests and ultimately obtains an access token from the EHR's Authorization server using the SMART launch workflow, as described in [SMART App Authorization Guide](http://docs.smarthealthit.org/authorization/).
 
@@ -298,7 +298,7 @@ With CDS Hooks, if the EHR wants to provide the CDS Service direct access to FHI
 
 #### Passing the Access Token to the CDS Service
 
-The access token is specified in the CDS Service request via the OPTIONAL `fhirAuthorization` request parameter. This parameter is an object that contains both the access token as well as other related information.  If the EHR chooses not to pass along an access token, the `fhirAuthorization` parameter is omitted.  
+The access token is specified in the CDS Service request via the OPTIONAL `fhirAuthorization` request parameter. This parameter is an object that contains both the access token as well as other related information.  If the EHR chooses not to pass along an access token, the `fhirAuthorization` parameter is omitted.
 
 Field | Optionality | Type | Description
 ----- | ----- | ----- | -----------
@@ -328,7 +328,7 @@ Below is an example `fhirAuthorization` parameter:
 
 ## CDS Service Response
 
-### Card Array 
+### Card Array
 
 Field | Optionality | Type | Description
 ----- | ----- | ----- | --------
@@ -344,7 +344,7 @@ If your CDS Service has no decision support for the user, your service should re
 }
 ```
 
-### Card Attributes 
+### Card Attributes
 
 Each **Card** is described by the following attributes.
 
@@ -457,32 +457,32 @@ Field | Optionality | Type | Description
 
 ## Security and Safety
 
-Security and safety risks associated with the CDS Hooks API include:  
+Security and safety risks associated with the CDS Hooks API include:
 
 1.	The risk that confidential information and privileged authorizations transmitted between an EHR and a CDS Service could be surreptitiously intercepted by an attacker;
 2.	The risk that an attacker masquerading as a legitimate CDS Service could receive confidential information or privileged authorizations from an EHR, or could provide to an EHR decision support recommendations that could be harmful to a patient;
-3.	The risk that an attacker masquerading as a legitimate service-subscribing EHR (i.e., man-in-the-middle) could intercept and possibly alter data exchanged between the two parties.  
-4.	The risk that a CDS Service could embed dangerous suggestions or links to dangerous apps in Cards returned to an EHR.  
+3.	The risk that an attacker masquerading as a legitimate service-subscribing EHR (i.e., man-in-the-middle) could intercept and possibly alter data exchanged between the two parties.
+4.	The risk that a CDS Service could embed dangerous suggestions or links to dangerous apps in Cards returned to an EHR.
 5.	The risk that a CDS Hooks browser-based deployment could be victimized by a Cross-Origin Resource Sharing (CORS) attack.
-6.	The risk that a CDS Service could return a decision based on outdated patient data, resulting in a safety risk to the patient.  
+6.	The risk that a CDS Service could return a decision based on outdated patient data, resulting in a safety risk to the patient.
 
-CDS Hooks defines a security model that addresses these risks by assuring that the identities of both the CDS Service and the EHR are authenticated to each other; by protecting confidential information and privileged authorizations shared between an EHR and a CDS Service; by recommending means of assuring data freshness; and by incorporating business mechanisms through which trust is established and maintained between an EHR and a CDS Service. 
+CDS Hooks defines a security model that addresses these risks by assuring that the identities of both the CDS Service and the EHR are authenticated to each other; by protecting confidential information and privileged authorizations shared between an EHR and a CDS Service; by recommending means of assuring data freshness; and by incorporating business mechanisms through which trust is established and maintained between an EHR and a CDS Service.
 
 ### Trusting CDS Services
 
-Prior to enabling EHRs to request decision support from any CDS Service, the EHR vendor and/or provider organization is expected to perform due diligence on the CDS Service provider.  Each EHR vendor/provider is individually responsible for determining the suitability, safety and integrity of the CDS Services it uses, based on the organization's own risk-management strategy.  Each EHR vendor/provider SHOULD maintain a "white list" (and/or "black list") of the CDS Services it has vetted, and the Card links that have been deemed safe to display from within the EHR context. Each provider organization is expected to work with its EHR vendor to choose what CDS Services to allow and to negotiate the conditions under which the CDS Services may be called.  
+Prior to enabling EHRs to request decision support from any CDS Service, the EHR vendor and/or provider organization is expected to perform due diligence on the CDS Service provider.  Each EHR vendor/provider is individually responsible for determining the suitability, safety and integrity of the CDS Services it uses, based on the organization's own risk-management strategy.  Each EHR vendor/provider SHOULD maintain a "white list" (and/or "black list") of the CDS Services it has vetted, and the Card links that have been deemed safe to display from within the EHR context. Each provider organization is expected to work with its EHR vendor to choose what CDS Services to allow and to negotiate the conditions under which the CDS Services may be called.
 
-Once a CDS Service provider is selected, the EHR vendor/provider negotiates the terms under which service will be provided.  This negotiation includes agreement on patient data elements that will be prefetched and provided to the CDS Service, data elements that will be made available through an access token passed by the EHR, and steps the CDS Service must take to protect patient data and access tokens.  To enable the EHR authorization server to authorize CDS Service access to FHIR resources, the CDS Service is registered as a client to the EHR authorization server.  These business arrangements are documented in the service agreement.  
+Once a CDS Service provider is selected, the EHR vendor/provider negotiates the terms under which service will be provided.  This negotiation includes agreement on patient data elements that will be prefetched and provided to the CDS Service, data elements that will be made available through an access token passed by the EHR, and steps the CDS Service must take to protect patient data and access tokens.  To enable the EHR authorization server to authorize CDS Service access to FHIR resources, the CDS Service is registered as a client to the EHR authorization server.  These business arrangements are documented in the service agreement.
 
 Every interaction between an EHR and a CDS Service is initiated by the EHR sending a service request to a CDS Service endpoint protected using the [Transport Layer Security protocol](https://tools.ietf.org/html/rfc5246).   Through the TLS protocol the identity of the CDS Service is authenticated, and an encrypted transmission channel is established between the EHR and the CDS Service. Both the Discovery endpoint and individual CDS Service endpoints are TLS secured.
 
 The EHR’s authorization server is responsible for enforcing restrictions on the CDS Services that may be called and the scope of the FHIR resources that may be prefetched or retrieved from the FHIR server.  Therefore, all CDS Services to be called from within an EHR system MUST BE pre-registered with the authorization server of that EHR.  Pre-registration MUST include registering a CDS client identifier, and agreeing upon the scope of FHIR access that is minimally necessary to provide the clinical decision support required.
 
 ### Trusting EHRs
 
-The service agreement negotiated between the EHR vendor/provider and the CDS Service provider will include obligations the EHR vendor/provider commits to the CDS Service provider. Some agreements may include the use of mutual TLS, in which both ends of the channel are authenticated.  
+The service agreement negotiated between the EHR vendor/provider and the CDS Service provider will include obligations the EHR vendor/provider commits to the CDS Service provider. Some agreements may include the use of mutual TLS, in which both ends of the channel are authenticated.
 
-However, mutual TLS is impractical for many organizations, and because the EHR initiates the TLS channel set-up, only the CDS Service endpoint will be authenticated.  To enable the CDS Service to authenticate the identity of the EHR, CDS Hooks uses digitally signed [JSON web tokens (JWT)](https://jwt.io/).  
+However, mutual TLS is impractical for many organizations, and because the EHR initiates the TLS channel set-up, only the CDS Service endpoint will be authenticated.  To enable the CDS Service to authenticate the identity of the EHR, CDS Hooks uses digitally signed [JSON web tokens (JWT)](https://jwt.io/).
 
 Each time an EHR transmits a request to a CDS Service, the request MUST include an `Authorization` header presenting the JWT as a “Bearer” token:
 ```
@@ -549,7 +549,7 @@ Authorization: Bearer eyJhbGciOiJFUzM4NCIsInR5cCI6IkpXVCIsImtpZCI6ImV4YW1wbGUta2
 
 [Cross-origin resource sharing (CORS)](https://www.w3.org/TR/cors/) is a W3C standard mechanism that uses additional HTTP headers to enable a web browser to gain permission to access resources from an Internet domain different from that from which the browser is currently accessing.  CORS is a client-side security mechanism with well-documented security risks.
 
-CDS Services and browser-based EHRs will require CORS support. A secure implementation guide for CORS is outside of the scope of this CDS Hooks specification. Organizations planning to implement CDS Hooks with CORS support are referred to the Cross-Origin Resource Sharing section of the [OWASP HTML5 Security Cheat Sheet]( https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet).  
+CDS Services and browser-based EHRs will require CORS support. A secure implementation guide for CORS is outside of the scope of this CDS Hooks specification. Organizations planning to implement CDS Hooks with CORS support are referred to the Cross-Origin Resource Sharing section of the [OWASP HTML5 Security Cheat Sheet]( https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet).
 
 ## Extensions