2023 - 01 CARIN IG For Digital Insurance Card

Short Description

Real-world testing of the CARIN IG for Digital Insurance Card.

Long Description

This project is intended to develop artifacts (FHIR implementation guides, code mappings, reference implementations, etc) to retrieve proof of insurance coverage information via FHIR when requested or shared by a Patient in order to create an electronic rendering of the insurance membership card within a digital application.

The objectives of this track are: 

• Test and gather feedback on the draft Implementation Guide
• Identify gaps or errors

Type

Test an Implementation Guide

Call for participants

Patients, Providers, Insurance companies, App developers

Track Prerequisites

Track Lead(s)

Mark Roberts

Track Lead Email(s)

mark.roberts@leavittpartners.com 

Specification Information

CARIN IG for Digital Insurance Card (PSS, Draft STU1) 

Zulip stream

https://chat.fhir.org/#narrow/stream/285193-CARIN-IG.20for.20Digital.20Insurance.20Card

Track Kick off Call

Primary Testing Scenario #1: If time allows and there is sufficient interest, we may test the other scenarios.

Scenario #1: Overview

SMART Health Links

• Health care providers are increasingly relying on web-based registration and check-in flows for patients
• In most of these flows, the patient is asked (or required) to input their insurance information, by

–Manually entering plan and policy information

–Uploading photos of their card

• A SMART Health Link digital insurance card could make this easier, reduce errors, and facilitate faster eligibility checks

Workflow

• Insurer/ data holder provides a digital insurance card to the individual as a SMART Health Link

–e.g., Insurer prints SHL QR on physical card

–e.g., Insurer emails or messages SHL QR to patient

–e.g., Insurer hosts SHL through their online portal

• Individual stores or captures their SMART Health Link digital insurance card on their device
• Individual shares their SMART Health Link digital insurance card during a web-based registration/ check-in flow for a new patient visit

Implementer Roles

• Data holders: generate a SMART Health Link

–Use https://docs.smarthealthit.org/smart-health-links/spec and the CARIN IG data profile

–Display or send a QR code or link

• PHR/ wallet/ patient apps: capture, display, store, share the SMART Health Link

–Consume a SHL from QR code or link, display and store it in app

–Provide user a way to copy, screenshot, or otherwise surface SHL for web checkin

• Providers/ platforms: ingest and validate the SMART Health Link

–Provide user a way to share their QR code or link in web checkin flow

–Consume and validate SHL from QR code or link, display and confirm details

Data Profile/IG Questions

• Is the complete CARIN IG data profile appropriate for individual-mediated use?

–The IG contains a lot of information, is there a minimized profile that would be still be valuable?

–How much more valuable/ what else can we accomplish in this workflow with the complete profile?

–Is there value to a signed digital version of just the core insurance card details?

–Are there UX trade-offs (e.g. being able to use a SMART Health Card vs Link) to a smaller profile?

• Does anything need to be changed in the IG to support SHLs (or SHCs)?

Testing Scenario #2:

Scenario #2: Overview

Provider Automatically Retrieves Insurance Card Before Appointment

• An existing patient has an upcoming appointment with their Primary Care Provider.
• It has been a while since the patient’s last visit, and even though their insurance information has not changed, the Provider Organization is required to have an up-to-date version of the patient’s insurance card on file.
• During pre-appointment processing the provider organization recognizes that it needs to verify that the patient is still eligible for coverage and that its current scan of the patient’s insurance ID card has expired.
• After verifying eligibility for the upcoming appointment, the Provider’s system automatically requests and receives images for the current insurance ID card from the Payer’s system.
• The patient is not asked to present an insurance ID card during their check-in process.

Workflow

Preconditions

–Patient insurance information already exists within the Provider’s system.

–Provider and Payer organizations have an existing connection that patient information, including Insurance ID Cards, can be exchanged on.

Actors

–Patient (aka Subscriber or Member)

–Provider Organization

–Payer Organization

Flow

1.Provider Organization’s system identifies the Patient as:

–Having an upcoming appointment.

–Not having recently verified their coverage eligibility.

–Not having their up-to-date Insurance ID Card in the system.

2.The Provider Organization verifies eligibility via 270/271.

3.The Provider Organization requests coverage information regarding the patient from the Payer Organization via a FHIR API. The Provider Organization knows which Payer Organization to contact since coverage has been verified via 270/271.

4.The Payer Organization responds with coverage information via a FHIR response. Included in that FHIR response are images of the Patient’s Insurance ID Card.

5.The Provider Organization saves the copies of the Patient’s Insurance ID Card.

Testing Scenario #3:

Scenario #3: Overview

Provider Gets Insurance Card Images When Registering a Patient

• A new patient is being seen for the first time at a Provider organization and is completing the Registration process in person.
• The patient can provide the registrar with their insurance information but is not able to provide the registrar with a copy of the Insurance ID Card that can be scanned into the Provider’s system.
• The registrar enters the patient’s personal and insurance information into the system and performs an eligibility request.
• After the patient’s coverage eligibility has been confirmed the Provider’s system requests a Coverage ID Card from the Payer’s system.

Workflow

Preconditions

–Provider and Payer organizations have an existing connection that patient information, including Insurance ID Cards, can be exchanged on.

Actors

–Patient (aka Subscriber or Member)

–Provider Organization

–Payer Organization

Flow

1.The Patient’s personal and insurance information is entered into the Provider Organization’s system.

2.The Provider Organization verifies eligibility via 270/271.

3.The Provider Organization requests coverage information regarding the patient from the Payer Organization via a FHIR API. The Provider Organization knows which Payer Organization to contact since coverage has been verified via 270/271.

4.The Payer Organization responds with coverage information via a FHIR response. Included in that FHIR response are images of the Patient’s Insurance ID Card.

5.The Provider Organization saves the copies of the Patient’s Insurance ID Card.

Testing Scenario #4:

Scenario #4: Overview

Provide Patient with Coverage and Benefits Information in Patient Portal

• A patient needs to schedule an office visit at their Provider Organization and wants to complete this task via their Provider’s Patient Portal.
• The patient logs into the patient portal and schedules the visit.
• During the process of scheduling the visit they are shown the coverage and a summary of the benefits that it provides.

Workflow

Preconditions

–Patient insurance information already exists within the Provider’s system.

–Provider and Payer organizations have an existing connection that patient information, including Insurance ID Cards, can be exchanged on.

–The Patient’s coverage eligibility has already been verified via 270/271.

Actors

–Patient (aka Subscriber or Member)

–Provider Organization

–Payer Organization

Flow

1.The Patient’s log into the Provider’s Patient Portal.

2.The Patient begins the process of scheduling the visit.

3.The Provider Organization’s system requests a summary of the Patient’s Coverage and Benefit information from the Payer Organization’s system via FHIR.

4.The Payer Organization responds with the Patient’s Coverage and a summary of their Benefit Information via a FHIR response.

5.The Provider Organization formats and displays the summary of the Patient’s Benefits and displays it to them during the scheduling process.