Submitting WG/Project/Implementer Group
CARIN Blue Button (PSS, draft IG, Documents and Data for Connectathon)
Justification and Objectives
What’s the purpose of hosting this connectathon track? What do you hope to achieve?
Real world testing of the CARIN Blue Button IG
This track will use what version of FHIR.
R4
Clinical input requested (if any)
Does your track have a need for input from the clinical community? If so, what are the needs?
N/A
Related tracks
(used to help guide seating arrangements and possibly drive track consolidation)
The target audience for Blue Button API development will include payer organizations who may also be involved in the various Da Vinci Tracks at the Connectathon.
Proposed Track Lead
Name, email. Track leads must be registered users on http://chat.fhir.org
Amol Vyas - amol.vyas@cambiahealth.com (zulip)
Expected participants
Who do you expect to be present? How many do you expect to attend?
Participants, please add/update your information in the public tracker:
Participant tracking: bit.ly/carin-bb-tracker
Track Collaboration/Communication/Feedback
CARIN Blue Button IG Zulip stream
System Roles
Describe each type of system that could participate in the track
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
Role 1 - Sandbox API Server
Role 2 - Sandbox API Client app
Scenarios
Describe the different scenarios participating systems can engage in during the conenctathon. Each scenario should provide sufficient description that participants can appropriately construct their software in advance to prepare to interoperate during the connectathon.
Scenario 1 - Sandbox user retrieves EOBs from the Sandbox server using the Client app
Action: Sandbox user receives the access and refresh tokens from the Sandbox server and calls the EOB endpoint
Precondition: Sandbox user is logged into the Client app
Success Criteria: The client app retrieves the user's EOBs and renders them on the UI
Bonus point #1: On expiration of the access token, the app uses the refresh token to get new access and refresh tokens
Bonus point #2: The Server exposes search criteria for filtering the EOBs and the client app uses the search criteria to retrieve the filtered EOBs [lastUpdated, etc]
Bonus point #3: Incorporate direct-support for native mobile apps (PKCE) [RFC8252 - native mobile app support, RFC7636 - PKCE]
Scenario 2 - Populate Server Sandbox that is tested for compliance by a tool (i.e. Aegis Touchstone/MITRE Crucible/ONC Inferno)
Action: Generate compliant CPCDS (Common Payer Consumer Data Set - defined by the CARIN BB IG) extract and transform and load the same into a CARIN BB IG-compliant Sandbox FHIR repository
Precondition: A source for CPCDS flat file extract exists (for example, Claims/EOB System of Record such as Cognizant Facets, etc)
Success Criteria: The Sandbox passes the compliance testing run by the tool
Bonus point #1: Transform and load the CPCDS extract into a third party CARIN BB IG-compliant Sandbox FHIR repository that also passes the tool's compliance testing
TestScript(s)
Indicate any test scripts that will be used to help verify system behavior
Security and Privacy Considerations
Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate