Track overview

Short Description

How would you describe this track to promote participation?  What's your two-sentence elevator pitch?  (Avoid acronyms)

Real-world testing of the CARIN Consumer Directed Payer Data Exchange (CARIN IG For Blue Button®)

Long Description

What's the purpose of hosting this connectathon track?  What do you hope to achieve?

The CARIN Alliance Health Plan Workgroup was organized to develop a FHIR-based API that could be sent to a consumer-facing application and was designed to answer the challenge for health plans to ‘meet or exceed’ the CMS Medicare Blue Button 2.0 capabilities. The CMS Medicare Blue Button 2.0 project provides over 53 million Medicare fee-for-service beneficiaries access to their electronic claims information.

The CARIN Consumer Directed Payer Data Exchange Implementation Guide (CARIN IG For Blue Button®)  was balloted in December for STU and comments are currently being addressed and resolved. Updates to the IG are being made to the continuous build once voted on and approved by the HL7 Financial Management Work Group.

The objectives of this track are: 


Pick one:

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group

What group has responsibility for this track?

Financial Management WG

Proposed Track Lead

Name, email.  Track leads must be registered users on

Amol Vyas - (zulip)

Mark Roberts (co-lead) - (zulip)

Related tracks

Provide links to other tracks that are likely to have overlap of use-cases and/or participants (used to help guide seating arrangements and possibly drive track consolidation)

The target audience for CDPDE API development will include payer organizations who may also be involved in the various DaVinci Tracks at the Connectathon.

FHIR Version

Delete those that do not apply

Specification(s) this track uses

Please provide version-specific (ballot, connectathon or official release) hyperlinks to the FHIR IG or other specifications implementers of this track will follow.  If the relevant version does not exist yet, describe what it *will* be.  (Hyperlink to actual version should be present no later than 1 month prior to connectathon.)

CARIN Consumer Directed Payer Data Exchange (CDPDE) IG (PSS, STU1, CI)

Artifacts of focus

Provide links to the resources, profiles or other key artifacts that will be a focus for the connectathon


Clinical input requested (if any)

Does your track have a need for input from the clinical community?  If so, what are the needs?


Patient input requested (if any)

Does your track have a need for input from the patient/care-giver community?  If so, what are the needs?


Expected participants

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

Zulip stream

Identify the stream on that will be used to coordinate among participants, both prior to and during the connectathon (Mandatory)

Zulip stream

Track Orientation

Provide information about the date & time at which a webinar will be hosted to share further participation information about this track.  (Mandatory)


Track details

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


Describe the different scenarios participating systems can engage in during the connectathon.  Each scenario should provide sufficient description that participants can appropriately construct their software in advance to prepare to interoperate during the connectathon.

Scenario: Sandbox user retrieves EOBs from the Sandbox server using the Client

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

Success Criteria: The client 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 (link) for selecting the EOBs and the client uses search parameters to select and retrieve the EOBs.

Bonus point #3: For a Server supporting _include, the resource instance included in the search response should match the instance from a separate read/vread on that resource's reference.


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


Reference Materials

Reference Implementation Resources