| Real-world testing of the CARIN Consumer Directed Payer Data Exchange (CARIN IG For Blue Button®) including Oral and Vision Profiles. |
| 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 V1.1.0
- Test and gather feedback on the Draft Implementation Guide V2.0
- Identify gaps or errors
|
| Test and Implementation Guide |
| Financial Management WG |
| Amol Vyas Mark Roberts |
| amol.vyas@cambiahealth.com; mark.roberts@leavittpartners.com |
| Patient Access API (PDex, PDex Formulary and Plan-Net IGs), Da Vinci Health Record Exchange |
| FHIR R4 |
| CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) (PSS, STU1, Draft STU2) |
| Oral EoB Profile: https://build.fhir.org/ig/HL7/carin-bb/StructureDefinition-C4BB-ExplanationOfBenefit-Oral.html |
| Payers and Consumer Application Developers |
| https://chat.fhir.org/#narrow/stream/204607-CARIN-IG.20for.20Blue.20Button.C2.AE/topic/Connectathon.20Ongoing |
| |
| 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 #1: The server returns resources that are compliant with CARIN BB Profiles, including Vision and Oral EoBs
- Success Criteria #2: Server is compliant with SMART App Launch [Stand alone mode] framework
- Success Criteria #3: Registered and run Aegis TestsScript
- 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.
TestScript(s): Aegis Touchstone
|
| Day 1 (5/3): Meeting Recording: https://hl7-org.zoom.us/rec/share/iQV6zpKSRwbOV_4FZS-D2bILtQYkZWieZbdjJ0RMvYiyMkJh9zB1BcvSA3_RoZq_.rMhd-8N7I-AUqc6e
Day 2 (5/4): Meeting Recording: https://hl7-org.zoom.us/rec/share/eEMHYss1G3-3wqzL0iV16JmUzWgzh_veNvt22qDbCPVbois5Qe5qpQIQUtFbr6RZ.PY6KZhEww1W5GFk3 |