Hard Check

Bridge’s React SDK is in beta! Expect breaking changes, bugs, and missing features. Please talk to us before integrating.

Refer to the Hard Eligibility page for a detailed explanation of what’s happening during this process.

Running a successful eligibility request for a new patient is the most complex integration touch point. Often, the goal is to minimize friction for the patient, while increasing the likelyhood of resolving their policy. Payers are notoriously unreliable, and even those that don’t require Member ID’s, sometimes force us to.

Bridge has a series of API’s that manages the lifecycle of the “hard eligibility check”, and the React SDK packages those up into a clean, single flow. The SDK implements Bridge’s best-practice recommendations around failures, retries, and conversion optimization. The interface for the SDK will remain stable as we release updates that improve these in a way that requires no additional work from you.

There is an example of a full hard eligibility check, implemented with MUI, inside the GitHub repository.

Below is a step-by-step guide on implementing the basic hard eligibility check. For more advanced use cases (such as multiple provider type support, and conditional patient responsibility), see the Advanced section.

1

Create a Session

Obtain the createHardEligibilityFunction through the useBridgeSdk hook. On first load, create a session, and pass that through into a HardEligibilityProvider, to child components below.

1export const SessionContainer = ({children}) => {
2 const { createHardEligibilitySession } = useBridgeSdk()
3 const session = useMemo(() => {
4 createHardEligibilitySession({ serviceTypeIds: ["svt_xxx"] })
5 }, [createHardEligibilitySession])
6
7 return (
8 <HardEligibilityProvider session={session}>
9 {children}
10 </HardEligibilityProvider>
11 )
12}
2

Form Input

It’s possible that all of the Eligibility Input Fields may be required. With the useEligibilityInputField hook, implement each field type. Drive your “Submit” button with the useHardEligibilitySubmit hook.

1export const HardEligibilityForm = () => {
2 const firstName = useEligibilityInputField("firstName")
3 const lastName = useEligibilityInputField("lastName")
4 const dateOfBirth = useEligibilityInputField("dateOfBirth")
5 const state = useEligibilityInputField("state")
6
7 const { isDisabled, submit } = useHardEligibilitySubmit()
8
9 return (
10 <div>
11
12 <input
13 placeholder="First Name"
14 type="text"
15 value={firstName.value}
16 onChange={e => firstName.setValue(e.target.value)}
17 disabled={firstName.isDisabled}
18 />
19
20 <input
21 placeholder="Last Name"
22 type="text"
23 value={lastName.value}
24 onChange={e => lastName.setValue(e.target.value)}
25 disabled={lastName.isDisabled}
26 />
27
28 <input
29 type="date"
30 value={dayjs(dateOfBirth.value).format("YYYY-MM-DD")}
31 onChange={e => dateOfBirth.setValue(dayjs(e.target.value).toDate())}
32 disabled={dateOfBirth.isDisabled}
33 />
34
35 {/** Refer to payer autocomplete docs for guide on how to implement */}
36 <PayerAutocompleteInputField/>
37
38 {memberId.isVisible && (
39 <input
40 placeholder={memberId.isRequired ? "Member ID (Required)" : "Member ID (Optional)"}
41 type="text"
42 value={memberId.value}
43 onChange={e => memberId.setValue(e.target.value)}
44 disabled={memberId.isDisabled}
45 />
46 )}
47
48 <button disabled={isDisabled} onClick=(() => submit())>
49 Submit
50 </button>
51
52 </div>
53 )
54}
3

Handling the result

With the useHardEligibilityState hook, monitor the progress and outcome of the request.

1function useHardEligibilityState(): HardEligibilitySessionState
2
3interface HardEligibilitySessionState {
4 /**
5 * The current status of the session, begins PENDING
6 */
7 status: HardEligibilitySessionStatus
8 /**
9 * The arguments used to submit the latest request
10 */
11 args?: HardEligibilitySubmissionArgs
12 /**
13 * If appropriate, hints to the next action that should be taken
14 */
15 nextAction?: HardEligibilitySessionAction
16 /**
17 * If applicable, details the error that should be displayed to the user
18 */
19 error?: HardEligibilityError
20 /**
21 * The most recent Policy, if applicable
22 */
23 policy?: Policy
24 /**
25 * If the ServiceEligibility resolved to eligible/ineligible, this contains the final set of ServiceEligibility
26 * The key of the object is each ServiceType ID
27 */
28 serviceEligibility?: Record<ServiceTypeId, ServiceEligibility>
29 /**
30 * If eligible, the final patient responsibility determination
31 */
32 patientResponsibility?: HardEligibilityPatientResponsibility
33 /**
34 * If the status is ELIGIBLE, this contains the final set of EligibleProviders
35 */
36 providers?: Provider[]
37 /**
38 * If the patient is INELIGIBLE, this contains the reason
39 */
40 ineligibilityReason?: IneligibilityReason
41}

Submission Status

The possible status values, their meaning and any action to take, are detailed below.

StatusDescription/Action
PENDINGInitial form input, nothing has been submitted
SERVER_ERRORUnknown server error, may be retried
TIMEOUTPayer took too long to respond with the Policy, may be retried
WAITING_FOR_POLICYFirst step of the flow, resolving the Policy, is in progress
POLICY_ERRORPolicy was unable to be resolved, there’s an error reason included
WAITING_FOR_SERVICE_ELIGIBILITYPolicy was resolved, second step is in progress
INELIGIBLEEither the patient’s Policy does not cover this service, or there are no providers eligible
ELIGIBLEThe patient’s Policy covers this, and there are Provider’s available
4

Error Handling

When the session is in any error state, expect the error object to be defined. This is mostly information, Bridge will handle allowing a retry, and updating the state of the Member ID input field.

1interface HardEligibilityError {
2 // Error code, if customizing the messages
3 code: HardEligibilityErrorCode
4 // User-friendly message to display
5 message: string
6 // Whether this is retryable with the same input
7 retryable: boolean
8 // Whether to require the Member ID, even if the Payer does not require it
9 forceMemberId?: boolean
10}

It’s expected that you display the contents of message: string to the patient. This is an explanation of what went wrong, or, a specific message returned by the Payer.

5

Handling the Results

Bridge will handle re-enabling the form, surfacing errors and changing required inputs, based on the response from the Payer. When a terminal state is reached (INELIGIBLE or ELIGIBLE), redirect them to the next step.

6

Patient Responsibility Estimates

If eligible, the patient responsibility estimate is exposed at patientResponsibility.estimate. See the conditional patient responsibility page for more on that.

7

Eligible Providers

If the status value is ELIGIBLE, there will be at least one provider available in the providers array. Use this collection to filter down the result of your scheduling UX to only eligible providers.

8

Eligibility Denial

In the case where the patient is INELIGIBLE, the state will include an ineligibilityReason value.

1interface IneligibilityReason {
2 // Code for referencing this reason
3 code: IneligibilityReasonCode
4 // User friendly message to display
5 message: string
6}

It’s expected that the message will be displayed to the patient, it contains the explanation. The code can be used for monitoring, additional breakdowns will be added over time.


We highly recommend that you refer back to the demo project in GitHub, to see how this functions in practice.