Announcement: Synthetic User Account Improvements

70 views
Skip to first unread message

Developer Group for CMS Blue Button API

unread,
Jul 18, 2023, 10:30:36 AM7/18/23
to Developer Group for CMS Blue Button API

Our first 10,000 synthetic user accounts have been replaced with a new data set, based on feedback from this community. Key features of the new dataset include:


  • Broader demographic representation: The new dataset represents a wider range of Medicare demographics and ages, including people under 65 who qualify for Medicare for reasons other than age. 


  • Rolling claims data updates: A random selection of this new set of synthetic user accounts will have new claims added weekly to simulate how Medicare enrollees have new claims processed over time. The weekly updates vary in claim types added, number of claims added, and number of user accounts affected.

With this change, the first 10,000 synthetic users with Medicare.gov usernames from BBUser00000 to BBUser09999 are the best and most updated data to test with. Our other, older synthetic user accounts from BBUser10000 to BBUser 39999 are not affected by this change and will not receive rolling claims data. 


Working with synthetic user accounts

Each of our 40,000 synthetic user accounts have Medicare.gov login credentials. To log in as a synthetic user, use the following Username/Password combination pattern when authorizing a test user with Blue Button 2.0:

  • Username: BBUserXXXXX (Example: BBUser00005)

  • Password: PWXXXXX! (Example: PW00005!)


Synthetic user accounts work in both the sandbox and production environments. To make it easy to differentiate between synthetic data and real patient production data, synthetic records will always have negative Patient ID and Explanation of Benefit values (example synthetic Patient ID: -10000010254618). Production record Patient IDs will always have positive values.


Claim dates in rolling claims updates

When new data is added for a synthetic user account in the weekly update, the new data includes claims dated 1-2 weeks prior. This delay simulates real claim processing time in production data. Get updated claims using the  _lastUpdated query parameter.
Reply all
Reply to author
Forward
0 new messages