Elle/bcda 6472: Static Site copy updates (#159)

* Getting Started Page updates

* Getting Started Page Updates

* Understanding the Data page updates

* code table navigation updates and link styles

* Wording updates to Getting Started Page

* Correct typos on Getting started page

* token format fix

_includes/build/access_token.html

@@ -1,19 +1,19 @@
 <p>
-	Currently, access tokens expire after twenty minutes. To illustrate this cycle, we’ll use the published open sandbox credentials for Extra-Small ACOs.
+	Currently, access tokens expire after twenty minutes. To illustrate this cycle, we’ll use the published open sandbox credentials for Extra-Small Model Entities.
 </p>
 
-<pre><code><b>Example Client ID (Extra-Small ACOs):</b>
-0c527d2e-2e8a-4808-b11d-0fa06baf8254
+<pre><code><b>Example Client ID (Extra-Small Model Entities):</b>
+3841c594-a8c0-41e5-98cc-38bb45360d3c
 
-<b>Example Client Secret (Extra-Small ACOs):</b>
-36e0ea2217e6d6180f3ab1108d02ca100d684ebdccc04817ce842300996e568c3d77fc61d84006a3
+<b>Example Client Secret (Extra-Small Model Entities):</b>
+d89810016460e6924a1c62583e5f51d1cbf911366c6bc6f040ff9f620a944efbf2b7264afe071609
 </code></pre>
 
 <div class="ds-c-alert ds-c-alert--hide-icon">
     <div class="ds-c-alert__body">
       <h3 class="ds-c-alert__heading">These credentials do not work in production.</h3>
       <p class="ds-c-alert__text">
-	The sample credentials above will not work in the production environment. For production data, follow along using the credentials your ACO was issued.
+	The sample credentials above will <b>not</b> work in the production environment. For production data, follow along using the credentials your model entity was issued.
 	</div>
   </div>
 
@@ -33,19 +33,19 @@ <h4>
 	Access Token cURL Command
 </h4>
 	<p>
-		cURL Option 1: This cURL command requires separate base-64 encryption. We have concatenated the base64 encoding of the ‘Client ID : Secret’ as the argument to the -H flag.
+		cURL Option 1: This cURL command requires separate base-64 encryption. We have concatenated the base64 encoding of the ‘Client ID : Secret’ as the argument to the -H flag. Please note that the URL in the Production environment will be different. 
 	</p>
-<pre><code>curl -d '' -X POST 'https://api.bcda.cms.gov/auth/token' \
-	-H "accept: application/json" \
+<pre><code>curl -d '' -X POST 'https://sandbox.bcda.cms.gov/ ' \ 
+	-H "accept: application/json" \ 
 	-H "authorization: Basic Mzg0MWM1OTQtYThjMC00MWU1Tk4Y2MtMzhiYjQ1MzYwZDNjOmY5NzgwZDMyMzU4OGYxY2RmYzNlNjNlOTVhOGNiZGNkZDQ3NjAyZmY0OGE1MzdiNTFkYzVkNzgzNGJmNDY2NDE2YTcxNmJkNDUwOGU5MDRh"</code></pre>
 
 <p>
-	cURL Option 2: This cURL command innately encrypts your credentials with base-64 encryption
+	cURL Option 2: This cURL command encrypts your credentials with base-64 encryption
 </p>
-<pre><code>curl -d '' -X POST 'https://api.bcda.cms.gov/auth/token' \
+
+<pre><code>curl -d '' -X POST 'https://sandbox.bcda.cms.gov/auth/token' \
 	--user 2462c96b-6427-4efb-aed7-118e20c2e997:8e87f0ebc50d10f1bc9734329a9900179b84ccd39e4d0920b905cc359cf6e94a6e760bbe3a0890c7 \
 	-H "accept: application/json"</code></pre>
-
 <h4>
 	Access Token Response Example
 </h4>
@@ -67,7 +67,7 @@ <h4>
 <h4>
 	Access Token Explanation
 </h4>
-<p>In cURL Option 1, you must base-64 encode the clientId and secret. Once that is performed, the encoded credentials can be passed to cURL as a header with the form: authorization: Basic [base64-encoded clientId:secret]</p>
+<p>In cURL Option 1, you must base-64 encode the Client ID and Secret. Once that is performed, the encoded credentials can be passed to cURL as a header with the form: authorization: Basic [base64-encoded clientId:secret]</p>
 <p>In cURL Option 2, the user can take advantage of cURL’s built-in ability to base-64 encode the clientId and secret, and request and receive their token in a single step.
 If your operation succeeds, you will receive a 202 response with your access token as a header. You will receive a 401 Unauthorized response if your credentials are invalid or if your token has expired. No additional information is returned with a 401 response. When you receive a 401 response for a token you were just using successfully, you should request a new access token as outlined above.</p>
 

_includes/build/authorization.html

@@ -1,3 +1,6 @@
 <p>
-	To complete any other operations with the API, you will need to be authorized. All SSP ACOs are currently eligible for authorization through the ACO-MS system.
+	To complete any other operations with the API, you will need to be authorized.
+</p>
+<p>
+	All model entities – Accountable Care Organizations (ACO), Direct Contracting Entities (DCE), Kidney Care Entities (KCE), and Kidney Care First (KCF) Entities – are eligible for authorization through their model-specific system.
 </p>

_includes/build/bcda_credentials.html

@@ -1,19 +1,20 @@
 <p>
-	In production, the Beneficiary Claims Data API protects its endpoints with OAuth2 access tokens.
-</p>
+  In production, BCDA protects its endpoints with OAuth2 access tokens.
+  </p>
 
   <div class="ds-c-alert ds-c-alert--hide-icon">
     <div class="ds-c-alert__body">
       <h3 class="ds-c-alert__heading">Your credentials are protected data.</h3>
-      <p class="ds-c-alert__text">
-	Please treat your credentials like protected data: store them safely and securely.
+        <p class="ds-c-alert__text">
+        Please store them safely and securely.	
+      </p>
 	</div>
   </div>
 
 <h3>
-	SSP-ACOs Gain Access to BCDA through ACO-MS
+Model Entities Gain Access to BCDA through ACO-MS or 4i
 </h3>
 
 <p>
-	Representatives of Shared Savings Program ACOs are now able to generate BCDA credentials in their <a href="https://acoms.cms.gov/" target="_blank" rel="noopener" class="in-text__link">ACO-MS portal</a> accounts. To view instructions on how to generate API credentials, log into your ACO-MS account and navigate to the ACO-MS Knowledge Library.
+	Representatives of Shared Savings Program (SSP) ACOs can generate BCDA credentials by logging into their <a href="https://acoms.cms.gov/" target="_blank" rel="noopener" class="in-text__link">ACO-MS portal</a> accounts and navigating to the ACO-MS Knowledge Library. Representatives of REACH ACOs and DCEs, KCEs, and KCF Entities can do the same by logging into their 4i account and navigate to the 4i Knowledge Library.
 </p>

_includes/build/bcda_user_guide.html

@@ -1,3 +1,3 @@
 <p>
-For each request and operation, we provide example requests and example cURL commands. We will highlight any common errors or unique attributes of our API. Lastly, we will provide an example response from the API.
+For each request and operation, we provide example requests and example cURL commands. We will highlight any common errors or unique attributes of our API. Lastly, we provide an example response from the API.
 </p>

_includes/build/bcda_v2.html

@@ -5,22 +5,30 @@
     For more information on BCDA V2, please visit the <a href="https://github.com/CMSgov/beneficiary-fhir-data/wiki/Migrating-to-V2-FAQ" target="_blank" class="in-text__link">CMS V2 API FAQ Documentation</a>. 
 </p>
 <h2>
-	How will BCDA V2 change how I interact with the BCDA API?
+	How will BCDA V2 change the way I interact with the BCDA API?
 </h2>
 <p>
-    BCDA V2 supports the same functionality as V1 API endpoints in both the Sandbox and Production API environments. All V2 API endpoints should work as described in existing BCDA documentation. If you wish to transition your implementation to utilize BCDA V2 endpoints instead of V1, users simply need to replace ‘v1’ in API call URLs with ‘v2’. Here is an example:
+    BCDA V2 supports the same functionality as V1 API endpoints in both the Sandbox and Production API environments. If you wish to transition your implementation to utilize BCDA V2 endpoints instead of V1, replace ‘v1’ in API call URLs with ‘v2’. Here is an example:
 </p>
-<h3>
-    Sample cURL Command in BCDA V1:
-</h3>
-<pre><code>curl -X GET 'https://api.bcda.cms.gov/api/v1/Patient/$export' \
--H "accept: application/fhir+json" \
--H "Prefer: respond-async" \
--H "Authorization: Bearer {access_token}"</code></pre>
-<h3>
-    Sample cURL Command in BCDA V2:
-</h3>
-<pre><code>curl -X GET 'https://api.bcda.cms.gov/api/v2/Patient/$export' \
--H "accept: application/fhir+json" \
--H "Prefer: respond-async" \
--H "Authorization: Bearer {access_token}"</code></pre>
+<p>
+    <div style="overflow-x:auto;">
+        <table>
+            <tr>
+                <th>Sample cURL Command in BCDA V1:</th>
+                <th>Sample cURL Command in BCDA V2:</th>
+            </tr>
+            <tr>
+                <td>
+                    <code>curl -X GET 'https://api.bcda.cms.gov/api/v1/Patient/$export' \ 
+                        -H "accept: application/fhir+json" \ -H "Prefer: respond-async" \ 
+                        -H "Authorization: Bearer {access_token}"</code>
+                </td>
+                <td>
+                    <code>curl -X GET 'https://api.bcda.cms.gov/api/v2/Patient/$export' \ 
+                        -H "accept: application/fhir+json" \ -H "Prefer: respond-async" \ 
+                        -H "Authorization: Bearer {access_token}"</code>
+                </td>    
+            </tr>
+        </table>
+    </div>
+</p>

_includes/build/request_metadata.html

@@ -107,5 +107,5 @@ <h3>
 	Metadata Explanation
 </h3>
 <p>
-	This operation will return data about the API in an NDJSON format. You may view the version of the API that is currently active, the version of FHIR currently supported, and other useful information.
+  This operation will return data about the API in an NDJSON format. You may view the release version and the FHIR version of the BCDA API that is currently active and other useful information.
 </p>

_includes/build/requesting_data.html

@@ -1,5 +1,5 @@
 <p>
-	To obtain all the available data (up to 7 years) for all of your beneficiaries, you can make a request to either the /Patient or /Group endpoint. You may want to do this as a first call, as a way to check for BCDA files against CCLF, or to create a database.
+	To obtain all the available data (as far back as 2014) for all of your beneficiaries, you can make a request to either the /Patient or /Group endpoint. You may want to do this as a first call, as a way to check for BCDA files against CCLF files, or to create a database.
 </p>
 <p>
 	BCDA data will be updated weekly, so you will be able to make requests and expect to retrieve new data on a weekly basis.

_includes/build/requesting_filtered_data.html

@@ -6,7 +6,7 @@
 	To reduce file size, use the _since parameter with either the /Patient or /Group endpoints, but be wary that you understand the difference regarding newly added beneficiaries. You may want to do this as a repeating call or as a way to check for new data.
 </p>
 <p>
-	To obtain claims runout data, use the <a href="#requesting-data-runouts" class="in-text__link">'runout' parameter with the /Group endpoint</a>, which returns data for beneficiaries who were attributed to your ACO the previous year but not the current year. These claims will have a service date no later than December 31 of the previous year.
+	To obtain claims runout data, use the <a href="#requesting-data-runouts" class="in-text__link">'runout' parameter with the /Group endpoint</a>, which returns data for beneficiaries who were attributed to your model entity the previous year but not the current year. These claims will have a service date no later than December 31 of the previous year.
 </p>
 
 <div class="ds-c-alert ds-c-alert--hide-icon">
@@ -16,7 +16,7 @@ <h2 class="ds-c-alert__heading">
     	</h2>
     	    <p class="ds-c-alert__text">
     	      <p>
-    	      	Before using _since for the first time, we recommend that you run an unfiltered request (without using _since) to all resource types on the /Patient or /Group endpoints in order to retrieve all historical data for your ACO's associated beneficiaries. You only need to do this once.
+    	      	Before using _since for the first time, we recommend that you run an unfiltered request (without using _since) to all resource types on the /Patient or /Group endpoints in order to retrieve all historical data for your model entity's associated beneficiaries. You only need to do this once.
     	      </p>
     	      <p>
     	      On subsequent calls you can begin retrieving incremental claims data for your beneficiaries using _since. We suggest using the transactionTime from your last bulk data request as the _since date.
@@ -67,7 +67,7 @@ <h2>When using _since, format dates and times by the FHIR standard</h2>
 
 <div class="ds-c-alert ds-c-alert--hide-icon">
     <div class="ds-c-alert__body">
-      <h3 class="ds-c-alert__heading">Be wary of requesting data from before 02-12-2020</h3>
+      <h3 class="ds-c-alert__heading">Difference between requesting data from before or after 02-12-2020</h3>
       <p class="ds-c-alert__text">
 		Due to limitations in the Beneficiary FHIR Data (BFD) Server, data from before 02-12-2020 is marked with the arbitrary <a href="https://www.hl7.org/fhir/search.html#lastUpdated" target="_blank" class="in-text__link">lastUpdated</a> date of 01-01-2020. If you input dates between 01-01-2020 and 02-11-2020 in the _since parameter, you will receive all historical data for your beneficiaries. Data loads from 02-12-2020 onwards have been marked with accurate dates.
 	</div>

_includes/build/requesting_filtered_data_since_Group.html

@@ -34,7 +34,7 @@ <h4>Response Headers</h4>
 
 <h4>Start a Job using _since within the /Group endpoint Explanation</h4>
 	<p>
-		This operation will start a job for filtered data for existing beneficiaries since 8PM EST on February 13th, 2020 and all 7 years of historical data for beneficiaries assigned to your organization in the last month. In the example, we request the Patient resource type. The steps and format would work similarly for other resource types.
+		This operation will start a job for filtered data for existing beneficiaries since 8PM EST on February 13th, 2020 and going as far back as 2014 for historical data for beneficiaries assigned to your organization in the last month. In the example, we request the Patient resource type. The steps and format would work similarly for other resource types.
 	</p>
 	<p>
 		You must provide the groupID of "all" as well as a _since date in the FHIR format. An access token as well as Accept and Prefer headers are required. The dollar sign ($) before the word 	"export" in the URL indicates that the endpoint is	 an action rather than a resource. The format is defined by the FHIR Bulk Data Export spec.
@@ -47,7 +47,7 @@ <h4>Start a Job using _since within the /Group endpoint Explanation</h4>
     	<div class="ds-c-alert__body">
     	  <h3 class="ds-c-alert__heading"> Attribution data is only updated once per month.</h3>
     	    <p class="ds-c-alert__text">
-    	     While most claims data is updated on a weekly cadence (and we encourage you to retrieve your ACO's claims data weekly), ACO attribution is only updated one time per month, so you will only be able to retrieve historical claims data for newly attributed beneficiaries once per month. Additional calls will only yield duplicative data for these newly attributed beneficiaries.
+    	     While most claims data is updated on a weekly cadence (and we encourage you to retrieve your model entity's claims data weekly), attribution is only updated one time per month, so you will only be able to retrieve historical claims data for newly attributed beneficiaries once per month. Additional calls will only yield duplicative data for these newly attributed beneficiaries.
     	  	</p>
     	</div>
 	</div>