Page tree
Skip to end of metadata
Go to start of metadata

Submitting WG/Project/Implementer Group

CARIN Blue Button (PSS, draft IG)


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?

NA


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


Expected participants

Who do you expect to be present? How many do you expect to attend?

Role 1 - Sandbox API Server: Edifecs

Role 2 - Sandbox API Client app: Edifecs, Apple, bWell


Track Orientation

A webinar will be hosted on date at time to share further participation information about this track.


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 Step 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

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 Step 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


  • No labels