From c1db221874bfe0ff3fa38f3415f16705cfd83b43 Mon Sep 17 00:00:00 2001 From: Carl Partridge Date: Wed, 30 Oct 2024 11:42:07 -0400 Subject: [PATCH 1/9] =?UTF-8?q?BCDA-8251=20Update=20all=20curl=20examples?= =?UTF-8?q?=20for=20/Patient=20and=20/Group=20endpoints=20=E2=80=A6=20(#21?= =?UTF-8?q?3)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit …to use -i ## 🎫 Ticket https://jira.cms.gov/browse/BCDA-8251 ## 🛠 Changes Updated all references and curl examples from curls -v param to curls -i param. ## ℹ️ Context Curls -v param shows all http request info which can be a lot. Curls -i param only shows the important info (headers, response). ## 🧪 Validation Went through the site locally finding all references to -v, -i, /Group, and /Patient. --- _includes/build/bcda_v2.html | 4 ++-- _includes/build/requesting_data_all_three.html | 9 ++++++--- _includes/build/requesting_data_runouts.html | 9 ++++++--- .../requesting_filtered_data_since_Group.html | 3 ++- .../requesting_filtered_data_since_Patient.html | 3 ++- _includes/guide/bcda_v2.html | 4 ++-- _includes/guide/try_the_api.html | 14 ++++++-------- _includes/partial/faq.html | 9 ++++----- 8 files changed, 30 insertions(+), 25 deletions(-) diff --git a/_includes/build/bcda_v2.html b/_includes/build/bcda_v2.html index ef7f8c7..beab519 100644 --- a/_includes/build/bcda_v2.html +++ b/_includes/build/bcda_v2.html @@ -24,14 +24,14 @@

-H "accept: application/fhir+json" \ -H "Prefer: respond-async" \ -H "Authorization: Bearer {access_token}" \ --v +-i 
curl -X GET "https://api.bcda.cms.gov/api/v1/Group/all/\$export" \
 -H "accept: application/fhir+json" \
 -H "Prefer: respond-async" \
 -H "Authorization: Bearer {access_token}" \
--v
+-i diff --git a/_includes/build/requesting_data_all_three.html b/_includes/build/requesting_data_all_three.html index 80edcbf..e7308ca 100644 --- a/_includes/build/requesting_data_all_three.html +++ b/_includes/build/requesting_data_all_three.html @@ -32,19 +32,22 @@

cURL Commands to start a job

curl -X GET "https://api.bcda.cms.gov/api/v2/Group/all/\$export" \
 	-H "accept: application/fhir+json" \
 	-H "Prefer: respond-async" \
-	-H "Authorization: Bearer {access_token}"
+ -H "Authorization: Bearer {access_token}" \ + -i 
  • curl -X GET "https://api.bcda.cms.gov/api/v2/Group/all/\$export?_type=ExplanationOfBenefit,Patient" \
 	-H "accept: application/fhir+json" \
 	-H "Prefer: respond-async" \
-	-H "Authorization: Bearer {access_token}"
    + -H "Authorization: Bearer {access_token}" \ + -i 
  • curl -X GET "https://api.bcda.cms.gov/api/v2/Group/all/\$export?_type=Patient" \
 	-H "accept: application/fhir+json" \
 	-H "Prefer: respond-async" \
-	-H "Authorization: Bearer {access_token}"
    + -H "Authorization: Bearer {access_token}" \ + -i
    • diff --git a/_includes/build/requesting_data_runouts.html b/_includes/build/requesting_data_runouts.html index e4c49f1..0b715de 100644 --- a/_includes/build/requesting_data_runouts.html +++ b/_includes/build/requesting_data_runouts.html @@ -23,19 +23,22 @@

    cURL Commands to start a job

    curl -X GET "https://api.bcda.cms.gov/api/v2/Group/runout/\$export" \
 	-H "accept: application/fhir+json" \
 	-H "Prefer: respond-async" \
-	-H "Authorization: Bearer {access_token}"
    + -H "Authorization: Bearer {access_token}" \ + -i 
  • curl -X GET "https://api.bcda.cms.gov/api/v2/Group/runout/\$export?_type=ExplanationOfBenefit,Patient" \
 	-H "accept: application/fhir+json" \
 	-H "Prefer: respond-async" \
-	-H "Authorization: Bearer {access_token}"
    + -H "Authorization: Bearer {access_token}" \ + -i 
  • curl -X GET "https://api.bcda.cms.gov/api/v2/Group/runout/\$export?_type=Patient" \
 	-H "accept: application/fhir+json" \
 	-H "Prefer: respond-async" \
-	-H "Authorization: Bearer {access_token}"
    + -H "Authorization: Bearer {access_token}" \ + -i
    • diff --git a/_includes/build/requesting_filtered_data_since_Group.html b/_includes/build/requesting_filtered_data_since_Group.html index 162807e..3a4239c 100644 --- a/_includes/build/requesting_filtered_data_since_Group.html +++ b/_includes/build/requesting_filtered_data_since_Group.html @@ -20,7 +20,8 @@

    cURL Command using the _since parameter within the /Group endpoint

    curl -X GET "https://api.bcda.cms.gov/api/v2/Group/all/\$export?_type=Patient&_since=2020-02-13T08:00:00.000-05:00" \
 	-H "Accept: application/fhir+json" \
 	-H "Prefer: respond-async" \
-	-H "Authorization: Bearer {access_token}"
    + -H "Authorization: Bearer {access_token}" \ + -i

    Response Example: Successful Request

    202 Accepted
    diff --git a/_includes/build/requesting_filtered_data_since_Patient.html b/_includes/build/requesting_filtered_data_since_Patient.html index 2c614df..182dca6 100644 --- a/_includes/build/requesting_filtered_data_since_Patient.html +++ b/_includes/build/requesting_filtered_data_since_Patient.html @@ -16,7 +16,8 @@

    cURL Command using the _since parameter within the /Patient endpoint

    curl -X GET "https://api.bcda.cms.gov/api/v2/Patient/\$export?_type=Patient&_since=2020-02-13T08:00:00.000-05:00" \
 	-H "Accept: application/fhir+json" \
 	-H "Prefer: respond-async" \
-	-H "Authorization: Bearer {access_token}"
    + -H "Authorization: Bearer {access_token}" \ + -i

    Response Example: Successful Request

    202 Accepted
    diff --git a/_includes/guide/bcda_v2.html b/_includes/guide/bcda_v2.html index 201e7f0..711e495 100644 --- a/_includes/guide/bcda_v2.html +++ b/_includes/guide/bcda_v2.html @@ -24,14 +24,14 @@

    -H "accept: application/fhir+json" \ -H "Prefer: respond-async" \ -H "Authorization: Bearer {access_token}" \ --v +-i 
    curl -X GET "https://sandbox.bcda.cms.gov/api/v1/Group/all/\$export" \
 -H "accept: application/fhir+json" \
 -H "Prefer: respond-async" \
 -H "Authorization: Bearer {access_token}" \
--v
    +-i diff --git a/_includes/guide/try_the_api.html b/_includes/guide/try_the_api.html index cc865b8..5f393bf 100644 --- a/_includes/guide/try_the_api.html +++ b/_includes/guide/try_the_api.html @@ -105,17 +105,16 @@

    With our new access token, we are able to make more requests to the API. We will now tell the server to deliver our data.

    - In this example, we requested data from the /Patient endpoint with no date filter (no _since parameter) and no specified resource type (no _type parameter). We included the long string of characters from the previous step (our access token) in the authorization header (-H "Authorization: Bearer "). Notice that we needed to include the word "Bearer" followed by a space before the access token. We also added "-v" in order to see the Job ID. + In this example, we requested data from the /Patient endpoint with no date filter (no _since parameter) and no specified resource type (no _type parameter). We included the long string of characters from the previous step (our access token) in the authorization header (-H "Authorization: Bearer "). Notice that we needed to include the word "Bearer" followed by a space before the access token. We also added "-i" in order to see the Job ID.

    Sample cURL Command to Start a Job 

    curl -X GET "https://sandbox.bcda.cms.gov/api/v2/Group/all/\$export" \
--H "accept: application/fhir+json" \
--H "Prefer: respond-async" \
--H "Authorization: Bearer {access_token}" \
--v
-
    + -H "accept: application/fhir+json" \ + -H "Prefer: respond-async" \ + -H "Authorization: Bearer {access_token}" \ + -i

    Response Example after Starting a Job

    @@ -150,8 +149,7 @@ 

    curl -X GET "https://sandbox.bcda.cms.gov/api/v2/jobs/42" \
 -H "accept: application/fhir+json" \
--H "Authorization: Bearer {access_token}"
-
    +-H "Authorization: Bearer {access_token}"

    Response Example after Checking on a Job

    diff --git a/_includes/partial/faq.html b/_includes/partial/faq.html index cd0bf3f..518ee1f 100644 --- a/_includes/partial/faq.html +++ b/_includes/partial/faq.html @@ -59,11 +59,10 @@

    Access to the Claim and ClaimResponse resources is handled within BCDA on a per ACO (Accountable Care Organization) ID level. There are no required changes to credentials for those REACH ACOs who would like access to the V2 endpoint. The BCDA V2 service supports the same functionality as V1 API endpoints in both the sandbox and production API environments. All V2 endpoints should work as described in the existing BCDA documentation. To transition from V1 to your BCDA V2 endpoints, replace ‘v1’ in the API call URLs with ‘v2’, as in the cURL example below: 

    curl -X GET "https://sandbox.bcda.cms.gov/api/v1/Patient/\$export" \
--H "accept: application/fhir+json" \
--H "Prefer: respond-async" \
--H "Authorization: Bearer {access_token}" \
--v
-
    + -H "accept: application/fhir+json" \ + -H "Prefer: respond-async" \ + -H "Authorization: Bearer {access_token}" \ + -i
    13) Are partially adjudicated claims received after a supplier’s orders are completed and the claims are submitted for payment? Or, are they received in a pre-authorization form? For example, if we place an order for an x-ray and then the x-ray supplier first submits a pre-op before they even see the patient, would we be receiving any of those before the event actually happens or is partially adjudicated data only available after the fact?

    In Medicare Fee-for-Service (FFS), in the timeline of a supplier order and partially adjudicated data, there is no pre-authorization information available. In BCDA, we only see partially adjudicated claims for actual claims, not for the pre-authorization type or a pre-determination type. From aed97863a04e65fbfc684af3ad0d40f8dc910148 Mon Sep 17 00:00:00 2001 From: Carl Partridge Date: Fri, 1 Nov 2024 16:08:06 -0400 Subject: [PATCH 2/9] BCDA-8391 standardize dynamic parameters (#214) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## 🎫 Ticket https://jira.cms.gov/browse/BCDA-8391 ## 🛠 Changes Standardize dynamic parameters in various example code blocks ## ℹ️ Context Previously we had a mishmash of hardcoded values and substitution representations (eg in one place we would have `/jobs/42` and others `/jobs/{job_id}`). The goal here was to standardize these. ## 🧪 Validation Went through each page carefully to doublecheck. --- _includes/build/access_token.html | 2 +- _includes/build/attribution_status.html | 4 ++-- _includes/build/bcda_v2.html | 4 ++-- .../build/best_practices_download_speed.html | 6 +++--- _includes/build/cancelling_jobs.html | 2 +- _includes/build/requesting_data_all_three.html | 18 +++++++++--------- _includes/build/requesting_data_runouts.html | 2 +- .../requesting_filtered_data_since_Group.html | 2 +- ...requesting_filtered_data_since_Patient.html | 2 +- _includes/guide/bcda_v2.html | 4 ++-- _includes/guide/try_the_api.html | 16 ++++++++-------- 11 files changed, 31 insertions(+), 31 deletions(-) diff --git a/_includes/build/access_token.html b/_includes/build/access_token.html index 9514a13..c7eca9c 100644 --- a/_includes/build/access_token.html +++ b/_includes/build/access_token.html @@ -44,7 +44,7 @@ 

    curl -d "" -X POST "https://sandbox.bcda.cms.gov/auth/token" \
-	--user 2462c96b-6427-4efb-aed7-118e20c2e997:8e87f0ebc50d10f1bc9734329a9900179b84ccd39e4d0920b905cc359cf6e94a6e760bbe3a0890c7 \
+	--user {client_id}:{client_secret} \
 	-H "accept: application/json"

    Access Token Response Example diff --git a/_includes/build/attribution_status.html b/_includes/build/attribution_status.html index 057741e..7f389b7 100644 --- a/_includes/build/attribution_status.html +++ b/_includes/build/attribution_status.html @@ -15,8 +15,8 @@

    Request Headers

    cURL Command to retrieve the attribution status

    curl -X GET "https://api.bcda.cms.gov/api/v2/attribution_status" \
-    -H "accept: application/json" \
-    -H "Authorization: Bearer {access_token}"
    + -H "accept: application/json" \ + -H "Authorization: Bearer {access_token}"

    Response Example

    {
diff --git a/_includes/build/bcda_v2.html b/_includes/build/bcda_v2.html
index beab519..65493a1 100644
--- a/_includes/build/bcda_v2.html
+++ b/_includes/build/bcda_v2.html
@@ -23,14 +23,14 @@ 
    
                     
    curl -X GET "https://api.bcda.cms.gov/api/v2/Group/all/\$export" \
 -H "accept: application/fhir+json" \
 -H "Prefer: respond-async" \
--H "Authorization: Bearer {access_token}" \
+-H "Authorization: Bearer {access_token}" \
 -i
    
                 
                 
                     
    curl -X GET "https://api.bcda.cms.gov/api/v1/Group/all/\$export" \
 -H "accept: application/fhir+json" \
 -H "Prefer: respond-async" \
--H "Authorization: Bearer {access_token}" \
+-H "Authorization: Bearer {access_token}" \
 -i
    
                   
             
diff --git a/_includes/build/best_practices_download_speed.html b/_includes/build/best_practices_download_speed.html
index 62fd0d0..8b583f2 100644
--- a/_includes/build/best_practices_download_speed.html
+++ b/_includes/build/best_practices_download_speed.html
@@ -10,9 +10,9 @@ 
    
   
    
     Sample cURL Command to Download the Data
   
    
-  
    curl "https://sandbox.bcda.cms.gov/data/42/afd22dfa-c239-4063-8882-eb2712f9f638.ndjson" \
--H "Authorization: Bearer {access_token}" \
--H "Accept-Encoding: gzip"
+  
    curl "{output_url}" \
+	-H "Authorization: Bearer {access_token}" \
+	-H "Accept-Encoding: gzip"
 
    
 
   
    
diff --git a/_includes/build/cancelling_jobs.html b/_includes/build/cancelling_jobs.html
index 42d2cc2..4cce62c 100644
--- a/_includes/build/cancelling_jobs.html
+++ b/_includes/build/cancelling_jobs.html
@@ -5,7 +5,7 @@ 
    Step 1: Obtain an Access Token
    
 
    Step 2: Send a Request to Cancel a Job
    
 
 
    Request to Cancel a Job
    
-      
    DELETE /api/v2/jobs/{jobId}
    
+      
    DELETE /api/v2/jobs/{job_id}
    
 
 
    Request Headers
    
 
    Authorization: Bearer {access_token}
diff --git a/_includes/build/requesting_data_all_three.html b/_includes/build/requesting_data_all_three.html
index e7308ca..ec0e45d 100644
--- a/_includes/build/requesting_data_all_three.html
+++ b/_includes/build/requesting_data_all_three.html
@@ -58,7 +58,7 @@ 
    Response Example: Too Many Requests
    
 	
    429 Too Many Requests
    
 
 
    Response Headers
    
-	
    Content-Location: https://api.bcda.cms.gov/api/v2/jobs/42
    
+	
    Content-Location: https://api.bcda.cms.gov/api/v2/jobs/{job_id}
    
 
 
    Start a Job Explanation
    
 	
    This operation will start a data export job. We have provided three example requests and three example cURL statements to start a job for:
    
@@ -88,14 +88,14 @@ 
    Start a Job Explanation
    
 
    Step 3: Check the job status
    
 
 
    Request to check the job status
    
-	
    GET https://api.bcda.cms.gov/api/v2/jobs/42
    
+	
    GET https://api.bcda.cms.gov/api/v2/jobs/{job_id}
    
 
 
    Request Headers
    
 	
    Authorization: Bearer {access_token}
 Accept: application/fhir+json
    
 
 
    cURL Command to check the job status
    
-	
    curl -X GET "https://api.bcda.cms.gov/api/v2/jobs/42" \
+	
    curl -X GET "https://api.bcda.cms.gov/api/v2/jobs/{job_id}" \
 	-H "accept: application/fhir+json" \
 	-H "Authorization: Bearer {access_token}"
    
 
@@ -107,19 +107,19 @@ 
    Response Example: Completed Job
    
   "output": [
     {
       "type": "ExplanationOfBenefit",
-      "url": "https://api.bcda.cms.gov/data/42/afd22dfa-c239-4063-8882-eb2712f9f638.ndjson"
+      "url": "{output_url}"
     },
     {
       "type": "Coverage",
-      "url": "https://api.bcda.cms.gov/data/42/f76a0b76-48ed-4033-aad9-d3eec37e7e83.ndjson"
+      "url": "{output_url}"
     },
     {
       "type": "Patient",
-      "url": "https://api.bcda.cms.gov/data/42/f92dcf16-63a2-448e-a12a-3bf677f966ed.ndjson"
+      "url": "{output_url}"
     }
   ],
   "error": [],
-  "JobID": 42
+  "JobID": {job_id}
 }
 
    
 
@@ -135,14 +135,14 @@ 
    Check the Job Status Explanation
    
 
    Step 4: Download the data
    
 
 
    Request to download the data
    
-	
    GET https://api.bcda.cms.gov/data/42/afd22dfa-c239-4063-8882-eb2712f9f638.ndjson
    
+	
    GET {output_url}
    
 
 
    Request Headers
    
 	
    Authorization: Bearer {access_token}
 Accept-Encoding: gzip
    
 
 
    cURL Command to download the data
    
-	
    curl -X GET "https://api.bcda.cms.gov/data/42/afd22dfa-c239-4063-8882-eb2712f9f638.ndjson" \
+	
    curl -X GET "{output_url}" \
 	-H "Accept-Encoding: gzip" \
 	-H "Authorization: Bearer {access_token}"
    
 
diff --git a/_includes/build/requesting_data_runouts.html b/_includes/build/requesting_data_runouts.html
index 0b715de..a198829 100644
--- a/_includes/build/requesting_data_runouts.html
+++ b/_includes/build/requesting_data_runouts.html
@@ -46,7 +46,7 @@ 
    Response Example: Successful Request
    
 	
    202 Accepted
    
 
 
    Response Headers
    
-	
    Content-Location: https://api.bcda.cms.gov/api/v2/jobs/42
    
+	
    Content-Location: https://api.bcda.cms.gov/api/v2/jobs/{job_id}
    
 
 
    Start a Job using 'runout' with /Group Explanation
    
 	
    This operation will start a data export job. We have provided three example requests and three example cURL statements to start a job for:
    
diff --git a/_includes/build/requesting_filtered_data_since_Group.html b/_includes/build/requesting_filtered_data_since_Group.html
index 3a4239c..be68fcc 100644
--- a/_includes/build/requesting_filtered_data_since_Group.html
+++ b/_includes/build/requesting_filtered_data_since_Group.html
@@ -30,7 +30,7 @@ 
    Response Example: Too Many Requests
    
 
    429 Too Many Requests
    
 
 
    Response Headers
    
-
    Content-Location: https://api.bcda.cms.gov/api/v2/jobs/42
    
+
    Content-Location: https://api.bcda.cms.gov/api/v2/jobs/{job_id}
    
 
 
 
    Start a Job using _since within the /Group endpoint Explanation
    
diff --git a/_includes/build/requesting_filtered_data_since_Patient.html b/_includes/build/requesting_filtered_data_since_Patient.html
index 182dca6..1686d0d 100644
--- a/_includes/build/requesting_filtered_data_since_Patient.html
+++ b/_includes/build/requesting_filtered_data_since_Patient.html
@@ -26,7 +26,7 @@ 
    Response Example: Too Many Requests
    
 
    429 Too Many Requests
    
 
 
    Response Headers
    
-
    Content-Location: https://api.bcda.cms.gov/api/v2/jobs/42
    
+
    Content-Location: https://api.bcda.cms.gov/api/v2/jobs/{job_id}
    
 
 
 
    Start a Job using _since within the /Patient endpoint Explanation
    
diff --git a/_includes/guide/bcda_v2.html b/_includes/guide/bcda_v2.html
index 711e495..304bd6e 100644
--- a/_includes/guide/bcda_v2.html
+++ b/_includes/guide/bcda_v2.html
@@ -23,14 +23,14 @@ 
    
                 
    curl -X GET "https://sandbox.bcda.cms.gov/api/v2/Group/all/\$export" \
 -H "accept: application/fhir+json" \
 -H "Prefer: respond-async" \
--H "Authorization: Bearer {access_token}" \
+-H "Authorization: Bearer {access_token}" \
 -i
    
             
             
                 
    curl -X GET "https://sandbox.bcda.cms.gov/api/v1/Group/all/\$export" \
 -H "accept: application/fhir+json" \
 -H "Prefer: respond-async" \
--H "Authorization: Bearer {access_token}" \
+-H "Authorization: Bearer {access_token}" \
 -i
    
               
         
diff --git a/_includes/guide/try_the_api.html b/_includes/guide/try_the_api.html
index 5f393bf..30fcf26 100644
--- a/_includes/guide/try_the_api.html
+++ b/_includes/guide/try_the_api.html
@@ -87,7 +87,7 @@ 
    
 	If the request was successful, we will receive a response with the code 200 containing a few headers. The first header ("access token") contains a long string of characters. This is our access token which must be attached to all of our other requests to the API.
 
    
 
    {
-"access_token": "eyJhbGciOiJSUzUxMiIsInR5c...",
+"access_token": "{access_token}",
 "token_type":"bearer"
 }
    
 
@@ -124,7 +124,7 @@ 
    Response Example after Starting a Job
    
 	If the request was successful, we will receive a response with the code 202 containing a few headers. One of the headers (Content-Location) will contain a URL. Notice that the URL ends in a number. This is the Job ID of the job we just started. In the next step, we will use this URL and Job ID to check if the server is done preparing our file(s).
 
    
 
    202 Accepted
-Content-Location: https://sandbox.bcda.cms.gov/api/v2/jobs/42
+Content-Location: https://sandbox.bcda.cms.gov/api/v2/jobs/{job_id}
 
    
 
 
@@ -147,9 +147,9 @@ 
    
 
    
 	Sample cURL Command to Check the Job Status
 
    
-
    curl -X GET "https://sandbox.bcda.cms.gov/api/v2/jobs/42" \
--H "accept: application/fhir+json" \
--H "Authorization: Bearer {access_token}"
    
+
    curl -X GET "https://sandbox.bcda.cms.gov/api/v2/jobs/{job_id}" \
+	-H "accept: application/fhir+json" \
+	-H "Authorization: Bearer {access_token}"
    
 
    
 	Response Example after Checking on a Job
 
    
@@ -201,9 +201,9 @@ 
    
 	
    
 		Sample cURL Command to Download the Data
 	
    
-
    curl "https://sandbox.bcda.cms.gov/data/42/afd22dfa-c239-4063-8882-eb2712f9f638.ndjson" \
--H "Authorization: Bearer {access_token}" \
--H "Accept-Encoding: gzip"
+
    curl "{output_url}" \
+	-H "Authorization: Bearer {access_token}" \
+	-H "Accept-Encoding: gzip"
 
    
 
    
 Response Example after Downloading the Data

From 7cead962eca133d4f22a44ad344bdefbf0cfcaf6 Mon Sep 17 00:00:00 2001
From: Carl Partridge 
Date: Tue, 5 Nov 2024 16:29:05 -0500
Subject: [PATCH 3/9] BCDA-8393 Update a few small things, add links (#215)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

## 🎫 Ticket

https://jira.cms.gov/browse/BCDA-8393

## 🛠 Changes

A few small changes.  Adding some links, removal of a word.

## ℹ️ Context





A few small changes from the most recent friction log.

## 🧪 Validation



Verified changes locally.
---
 _includes/data/claims_data_avail.html    | 2 +-
 _includes/data/how_to_use_bcda_data.html | 6 +++---
 _includes/guide/type_parameter.html      | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/_includes/data/claims_data_avail.html b/_includes/data/claims_data_avail.html
index c0b6cca..4c55b03 100644
--- a/_includes/data/claims_data_avail.html
+++ b/_includes/data/claims_data_avail.html
@@ -1,5 +1,5 @@
 
    
-  
    Since the Beneficiary Claims Data API (BCDA) shares fully adjudicated Medicare claims data (Part A, B, and D), claims data availability relies on how quickly a claim has been submitted, processed, and approved. Per Section 6404 of the Affordable Care Act, the maximum period for submission of all Medicare Fee-for-Service claims has been reduced to no more than 12 months (1 calendar year) after the date services were furnished. CMS typically receives claims 3-4 weeks after care has been provided. Once received by CMS, it is possible for claims to undergo more than one round of processing to make adjustments, edits, and cancellations. Data will only be available via the API once a claim has been approved. For more details on claims submission and approval timeframes, please review this white paper which outlines the lifecycle of a Medicare claim, as well as timeframes for submission and approval (pages 11, 12, and 22 have details on month-over-month statistics). 
+  
    Since the Beneficiary Claims Data API (BCDA) shares fully adjudicated Medicare claims data (Part A, B, and D), claims data availability relies on how quickly a claim has been submitted, processed, and approved. Per Section 6404 of the Affordable Care Act, the maximum period for submission of all Medicare Fee-for-Service claims has been reduced to no more than 12 months (1 calendar year) after the date services were furnished. CMS typically receives claims 3-4 weeks after care has been provided. Once received by CMS, it is possible for claims to undergo more than one round of processing to make adjustments, edits, and cancellations. Data will only be available via the API once a claim has been approved. For more details on claims submission and approval timeframes, please review this white paper which outlines the lifecycle of a Medicare claim, as well as timeframes for submission and approval (pages 11, 12, and 22 have details on month-over-month statistics). 
   
    
   
    Once a claim has been submitted, processed, and approved, BCDA receives the data on a weekly cadence, while Claim and Claim Line Feed (CCLF) files receive them monthly. New data is loaded from the CCW every weekend. In the event of a delay, there will be an announcement in the BCDA Google Group with updates on when the data will be refreshed.
   
    
diff --git a/_includes/data/how_to_use_bcda_data.html b/_includes/data/how_to_use_bcda_data.html
index f78cfe2..9b19d25 100644
--- a/_includes/data/how_to_use_bcda_data.html
+++ b/_includes/data/how_to_use_bcda_data.html
@@ -4,9 +4,9 @@
   
    For adjudicated claims, BCDA serves data according to the bulk FHIR specification using three FHIR resources: ExplanationOfBenefit (EOB), Patient, and Coverage. This means that your claims data will be delivered through three FHIR resource types rather than 12 CCLF files.
   
    
   
      
-    
    • The ExplanationOfBenefit (EOB) resource type provides similar information to what is provided in CCLF files 1-7. The EOB files contain lines within an episode of care, including where and when the service was performed, the diagnosis codes, the provider who performed the service, and the cost of care.
      • 
-    
    • The Patient resource type provides similar information to what is provided in CCLF files 8 and 9. This is where you get your information about who your beneficiaries are, their demographic information, and updates to their patient identifiers.
      • 
-    
    • The Coverage resource type provides information about beneficiaries’ insurance coverage, including information about dual coverage.
      • 
+    
    • The  ExplanationOfBenefit (EOB) resource type provides similar information to what is provided in CCLF files 1-7. The EOB files contain lines within an episode of care, including where and when the service was performed, the diagnosis codes, the provider who performed the service, and the cost of care.
      • 
+    
    • The  Patient resource type provides similar information to what is provided in CCLF files 8 and 9. This is where you get your information about who your beneficiaries are, their demographic information, and updates to their patient identifiers.
      • 
+    
    • The  Coverage resource type provides information about beneficiaries’ insurance coverage, including information about dual coverage.
      • 
   
    
   
    For partially adjudicated claims two FHIR resources are available to REACH ACOs: Claim and ClaimResponse.
   
    
diff --git a/_includes/guide/type_parameter.html b/_includes/guide/type_parameter.html
index 71454e4..a6223fa 100644
--- a/_includes/guide/type_parameter.html
+++ b/_includes/guide/type_parameter.html
@@ -1,5 +1,5 @@
 
    
-	The _type parameter allows you to request different Resource Types from the API. Instead of receiving data from all three Resource Types when no _type parameter is specified, you will be able to use the _type parameter to submit one or more Resource Types. The API will then produce data from the specified Resource Types.
+	The _type parameter allows you to request different Resource Types from the API. Instead of receiving data from all Resource Types when no _type parameter is specified, you will be able to use the _type parameter to submit one or more Resource Types. The API will then produce data from the specified Resource Types.
 
    
 
 
    

From 0954e434069e531ef11daf7850a88c9496b1c12d Mon Sep 17 00:00:00 2001
From: Greg Pfadenhauer 
Date: Thu, 7 Nov 2024 14:18:51 -0500
Subject: [PATCH 4/9] Remove option 1 to request a token using curl (#216)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Address feedback from Karley's review of staging r79

## 🎫 Ticket
https://cmsgov.slack.com/archives/CHG7Q7XNH/p1730998587225749

## 🛠 Changes
Remove option 1 to request a token using curl

## ℹ️ Context
we don't provide a sample command on how to actually encode the
credentials, and it's cleaner to just point everyone to the curl command
with the --user flag



## 🧪 Validation

Validated in staging
image
---
 _includes/build/access_token.html | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/_includes/build/access_token.html b/_includes/build/access_token.html
index c7eca9c..61ec270 100644
--- a/_includes/build/access_token.html
+++ b/_includes/build/access_token.html
@@ -32,15 +32,9 @@ 
    
 
    
 	Access Token cURL Command
 
    
-	
    
-		cURL Option 1: This cURL command requires separate Base64 encoding. 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. 
-	
    
-
    curl -d "" -X POST "https://sandbox.bcda.cms.gov/auth/token" \
-	-H "accept: application/json" \
-	-H "authorization: Basic MjQ2MmM5NmItNjQyNy00ZWZiLWFlZDctMTE4ZTIwYzJlOTk3OjhlODdmMGViYzUwZDEwZjFiYzk3MzQzMjlhOTkwMDE3OWI4NGNjZDM5ZTRkMDkyMGI5MDVjYzM1OWNmNmU5NGE2ZTc2MGJiZTNhMDg5MGM3"
    
 
 
    
-	cURL Option 2: This cURL command encodes your credentials into Base64.
+	This command takes advantage of curl’s built-in ability to Base-64 encode your credentials, request, and receive your token in a single step. The authorization in your request header will be substituted with "--user {client_id}:{client_secret}"
 
    
 
 
    curl -d "" -X POST "https://sandbox.bcda.cms.gov/auth/token" \

From 73d5ec025dbf3fc942e5e0fb08858f6da73e727a Mon Sep 17 00:00:00 2001
From: austincanada <162146803+austincanada@users.noreply.github.com>
Date: Wed, 20 Nov 2024 11:44:04 -0500
Subject: [PATCH 5/9] Austin/bcda 8262 tealium snippet (#218)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

## 🎫 Ticket

https://jira.cms.gov/browse/8262

## 🛠 Changes

Updated Tealium snippet change

## ℹ️ Context

Needed to add an additional Tealium script

## 🧪 Validation

Available within stage.bcda.gov and BlastX team validation.
---
 assets/js/tagging.js | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/assets/js/tagging.js b/assets/js/tagging.js
index 9c45220..7b2a902 100644
--- a/assets/js/tagging.js
+++ b/assets/js/tagging.js
@@ -2,12 +2,18 @@
 ---
 
 (function(a,b,c,d){
-  a='https://tags.tiqcdn.com/utag/cmsgov/cms-general/{{ jekyll.environment }}/utag.js';
+  a='https://tealium-tags.cms.gov/cms-general/{{ jekyll.environment }}/utag.js';
   b=document;c='script';d=b.createElement(c);d.src=a;
   d.type='text/java'+c;d.async=true;
   a=b.getElementsByTagName(c)[0];a.parentNode.insertBefore(d,a);
 })();
 
+(function(a,b,c,d){
+  a='https://tealium-tags.cms.gov/cms-general/{{ jekyll.environment }}/utag.sync.js';
+  b=document;c='script';d=b.createElement(c);d.src=a;
+  a=b.getElementsByTagName(c)[0];a.parentNode.insertBefore(d,a);
+})();
+
 function metricTagging(category, action, label) {
     utag.link({ ga_event_category: category, ga_event_action: action, ga_event_label: label });
 };

From 4d21de388cba7c8fe27f1099f35dc2f1743776f0 Mon Sep 17 00:00:00 2001
From: Greg Pfadenhauer 
Date: Wed, 20 Nov 2024 11:51:14 -0500
Subject: [PATCH 6/9] BCDA-8434 Update credential management guidelines (#217)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

## 🎫 Ticket

https://jira.cms.gov/browse/bcda-8434

## 🛠 Changes

Added the updated credential management instructions to build.html and
included a small announcement in updates.html
## ℹ️ Context
This content was originally drafted to be a new subpage in a redesigned
version of the site, but can be dropped into the current site. It will
be helpful for new model entities joining in 2025 and getting started
with BCDA.



## 🧪 Validation


1. Published to staging site for review by @phamjennifer
2. Validated links from side navigation and from updates.html work as
intended to /build.html#bcda-credentials
image
image
---
 _includes/build/bcda_credentials.html | 44 +++++++++++++++------------
 _updates/2024-11-18.html              | 14 +++++++++
 build.html                            |  4 +--
 3 files changed, 41 insertions(+), 21 deletions(-)
 create mode 100644 _updates/2024-11-18.html

diff --git a/_includes/build/bcda_credentials.html b/_includes/build/bcda_credentials.html
index 272130a..a3550df 100644
--- a/_includes/build/bcda_credentials.html
+++ b/_includes/build/bcda_credentials.html
@@ -1,22 +1,28 @@
-
    
-  In production, BCDA protects its endpoints with OAuth2 access tokens.
-  
    
+
    Production credentials authorize your organization's access to the Beneficiary Claims Data API (BCDA). Eligible model entities can manage BCDA credentials by logging into their model-specific system: 
    
+
      
+  
    • ACOs in the Medicare Shared Savings Program: Credential delegates can manage and create credentials from ACO Management System (ACO-MS). 
      • 
+  
    • REACH ACOs and KCEs or KCF practices in the Kidney Care Choices Model: The following roles can manage and create credentials from 4innovation (4i): 
        
+      
      • Executive Contact 
        • 
+      
      • Entity Primary Contact 
        • 
+      
      • Entity Secondary Contact 
        • 
+      
      • DUA Requestor 
        • 
+      
      • DUA Custodian
        • 
+    
      
+  
      • 
+
    
+
    Your registered contact can contact the ACO-MS and 4i help desk to assign these roles.
    
 
-  
    
-    
    
-      
    Your credentials are protected data.
    
-        
    
-        Please store them safely and securely.	
-      
    
-	
    
-  
    
+
    Create your credentials
    
+
    BCDA credentials are formatted as a client ID and secret, which your organization will use every time it requests an authentication token. Production credentials are sensitive information and must be stored securely. 
    
+
    Create BCDA credentials by visiting the API Credentials page in your model-specific system. Choose the BCDA Credentials tab, then select Create New API Credentials. You'll need to provide a public, static IP address for every system, including vendors, that will access the API (up to 8 IP addresses). It may take up to an hour for the allow list to be updated. 
    
 
-
    
-Model Entities Gain Access to BCDA through ACO-MS or 4i
-
    
+
    Rotate your credentials
    
+
    Your organization's credentials will expire and deactivate after a set period of time. You can rotate BCDA credentials in the API Credentials page to generate a new, active client ID and secret. 
    
+
    You'll need to rotate credentials every 90 days in 4i or every 12 months in ACO-MS. Once you choose the BCDA Credentials tab, select the rotate icon under the Actions column. 
    
 
-
    
- 
    ACOs in the Medicare Shared Savings Program: Create and manage your organization's BCDA credentials from the ACO Management System.
     
-
    REACH ACOs and KCEs or KCFs in the Kidney Care Choices Model: Create and manage your organization's BCDA credentials from the 4i portal.
    
-
    When creating new credentials, be prepared to provide the IP address(es) for each system that will make requests to BCDA. It may take up to an hour for the allow list to be updated after the IP address(es) are added.
    
-
    
+
    Revoke your credentials
    
+
    You may need to revoke (deactivate) your organization's credentials if they are leaked or compromised. You can create new credentials as a replacement afterward. 
    
+
    Revoke BCDA credentials in the API Credentials page. Choose the BCDA Credentials tab, then select the delete (x) icon under the Actions column. 
    
+
+
    If your credentials have been compromised
    
+
    Please revoke or rotate your BCDA credentials immediately. Afterward, notify the BCDA team at bcapi@cms.hhs.gov to review recent activity. 
    
\ No newline at end of file
diff --git a/_updates/2024-11-18.html b/_updates/2024-11-18.html
new file mode 100644
index 0000000..022a4e3
--- /dev/null
+++ b/_updates/2024-11-18.html
@@ -0,0 +1,14 @@
+---
+---
+
    
+  
    
+    Updated guidance on managing BCDA credentials
+  
    
+  
    
+    November 20, 2024
+  
    
+  
    
+    
    The BCDA team has updated our guidance for model entities managing their BCDA credentials in 4i and ACO-MS. Please visit Manage your BCDA Credentials for model specific instructions on how to manage and create BCDA credentials for your organization.
    
+    
    No action is required for BCDA users, but we hope the updated guidance is helpful!
    
+  
    
+
    
\ No newline at end of file
diff --git a/build.html b/build.html
index 30e84c8..07685f4 100644
--- a/build.html
+++ b/build.html
@@ -38,7 +38,7 @@
           
    
           
    
             
    
-              Obtain your BCDA Credentials
+              Manage your BCDA Credentials
             
    
             
    
               {% include build/bcda_credentials.html %}

From 89372eb354944e256596746519066421970230f7 Mon Sep 17 00:00:00 2001
From: Carl Partridge 
Date: Tue, 17 Dec 2024 14:01:07 -0500
Subject: [PATCH 7/9] BCDA-8390-adjust-file-download-copy (#219)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

## 🎫 Ticket

https://jira.cms.gov/browse/BCDA-8390

## 🛠 Changes

Adjusting the file download curl command to specifically download a file
as output instead of return bits from the request as well as adjust the
copy to acknowledge that the file downloaded is a gzip and will need to
be extracted to be used.

## ℹ️ Context





## 🧪 Validation

Site build and review locally.
---
 _includes/build/best_practices_download_speed.html | 5 +++--
 _includes/build/requesting_data_all_three.html     | 5 +++--
 _includes/guide/try_the_api.html                   | 3 ++-
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/_includes/build/best_practices_download_speed.html b/_includes/build/best_practices_download_speed.html
index 8b583f2..cfb00a2 100644
--- a/_includes/build/best_practices_download_speed.html
+++ b/_includes/build/best_practices_download_speed.html
@@ -4,7 +4,7 @@ 
    
   
    
 
   
    
-    Requesting compressed data can help increase your download speed. You can request compressed data files by specifying the `Accept-Encoding: gzip` header in your download requests.
+    Requesting compressed data can help increase your download speed. You can request compressed data files by specifying the `Accept-Encoding: gzip` header in your download requests.  Note that the file downloaded will be a gzip file which you will need to extract into its ndjson format.
   
    
 
   
    
@@ -12,7 +12,8 @@ 
    
   
    
   
    curl "{output_url}" \
 	-H "Authorization: Bearer {access_token}" \
-	-H "Accept-Encoding: gzip"
+	-H "Accept-Encoding: gzip" \
+	--output "your-file-name"
 
    
 
   
    
diff --git a/_includes/build/requesting_data_all_three.html b/_includes/build/requesting_data_all_three.html
index ec0e45d..c353495 100644
--- a/_includes/build/requesting_data_all_three.html
+++ b/_includes/build/requesting_data_all_three.html
@@ -144,7 +144,8 @@ 
    Request Headers
    
 
    cURL Command to download the data
    
 	
    curl -X GET "{output_url}" \
 	-H "Accept-Encoding: gzip" \
-	-H "Authorization: Bearer {access_token}"
    
+	-H "Authorization: Bearer {access_token}" \
+	--output "your-file-name"
    
 
 
    Response Example
    
 	
    
@@ -173,7 +174,7 @@ 
     Files expire after 24 hours.
    
 	
 
 	
    
-		The "Accept-Encoding: gzip" header is optional, but will return a significantly smaller (about 30X smaller) file with a faster download speed. Follow our recommended best practices for speeding up downloads.
+		The "Accept-Encoding: gzip" header is optional, but will return a significantly smaller (about 30X smaller) file with a faster download speed. Follow our recommended best practices for speeding up downloads.  Note that the file downloaded will be a gzip file which you will need to extract into its ndjson format.
 	
    
 	
    
 		The response will be the requested data as FHIR resources in NDJSON format. Each file related to a different resource type will appear separately and labeled as to which resource type it contains. Examples of data from each Resource Type are available in the guide to working with BCDA data.
diff --git a/_includes/guide/try_the_api.html b/_includes/guide/try_the_api.html
index 30fcf26..5ed16c4 100644
--- a/_includes/guide/try_the_api.html
+++ b/_includes/guide/try_the_api.html
@@ -203,7 +203,8 @@ 
    
 	
    
 
    curl "{output_url}" \
 	-H "Authorization: Bearer {access_token}" \
-	-H "Accept-Encoding: gzip"
+	-H "Accept-Encoding: gzip" \
+	--output "your-file-name"
 
    
 
    
 Response Example after Downloading the Data

From 3cbb8286a117c7828126a29d3f901945894627eb Mon Sep 17 00:00:00 2001
From: Carl Partridge 
Date: Tue, 17 Dec 2024 15:30:10 -0500
Subject: [PATCH 8/9] BCDA-8392-add-runout-description (#220)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

## 🎫 Ticket

https://jira.cms.gov/browse/BCDA-8392

## 🛠 Changes

Added runout data description.

## ℹ️ Context





## 🧪 Validation

Site build and review locally.

---------

Co-authored-by: Greg Pfadenhauer 
---
 build.html | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/build.html b/build.html
index 07685f4..d120fd3 100644
--- a/build.html
+++ b/build.html
@@ -247,6 +247,9 @@ 
    
           
    
             Request runouts data with /Group and `runout`
           
    
+          
    
+            Use /Group/runout at the beginning of a new Performance Year (PY) to retrieve runouts data for the the previous PY. Runouts data includes claims data for Medicare enrollees 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.
+          
    
           
    
             {% include build/requesting_data_runouts.html %}
           
    

From a5e91531b717703a6a9fb48369afe4939b4126b5 Mon Sep 17 00:00:00 2001
From: Greg Pfadenhauer 
Date: Wed, 18 Dec 2024 14:56:10 -0500
Subject: [PATCH 9/9] Correct credential expiration in ACO-MS (#221)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Credentials expire after 90 days regardless of which portal they were
created in

## 🎫 Ticket
N/A

## 🛠 Changes
Corrected information on when credentials expire

## ℹ️ Context





## 🧪 Validation


---
 _includes/build/bcda_credentials.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/_includes/build/bcda_credentials.html b/_includes/build/bcda_credentials.html
index a3550df..57d9e0c 100644
--- a/_includes/build/bcda_credentials.html
+++ b/_includes/build/bcda_credentials.html
@@ -18,11 +18,11 @@ 
    Create your credentials
    
 
 
    Rotate your credentials
    
 
    Your organization's credentials will expire and deactivate after a set period of time. You can rotate BCDA credentials in the API Credentials page to generate a new, active client ID and secret. 
    
-
    You'll need to rotate credentials every 90 days in 4i or every 12 months in ACO-MS. Once you choose the BCDA Credentials tab, select the rotate icon under the Actions column. 
    
+
    You'll need to rotate credentials every 90 days in 4i or ACO-MS. Once you choose the BCDA Credentials tab, select the rotate icon under the Actions column. 
    
 
 
    Revoke your credentials
    
 
    You may need to revoke (deactivate) your organization's credentials if they are leaked or compromised. You can create new credentials as a replacement afterward. 
    
 
    Revoke BCDA credentials in the API Credentials page. Choose the BCDA Credentials tab, then select the delete (x) icon under the Actions column. 
    
 
 
    If your credentials have been compromised
    
-
    Please revoke or rotate your BCDA credentials immediately. Afterward, notify the BCDA team at bcapi@cms.hhs.gov to review recent activity. 
    
\ No newline at end of file
+
    Please revoke or rotate your BCDA credentials immediately. Afterward, notify the BCDA team at bcapi@cms.hhs.gov to review recent activity.