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®)
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:
- Test and gather feedback on the Implementation Guide
- Identify gaps or errors
- Test an Implementation Guide
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 http://chat.fhir.org
Amol Vyas - email@example.com (zulip)
Mark Roberts (co-lead) - firstname.lastname@example.org (zulip)
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.
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?
Who do you expect to be present? How many do you expect to attend?
Identify the stream on http://chat.fhir.org that will be used to coordinate among participants, both prior to and during the connectathon (Mandatory)
Provide information about the date & time at which a webinar will be hosted to share further participation information about this track. (Mandatory)
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 Implementation Resources
- Hosted Reference implementations:
- Reference Implementation Code (with Docker containers)