Skip to main content
images/stedi.svg Morf runs insurance eligibility checks through our partnership with Stedi, in two modes:
  • Asynchronous — the Check Eligibility workflow action runs the check inside a Morf workflow. See the walkthrough below and the Parameters reference.
  • Synchronous — a Morf form calls the eligibility endpoint directly, so patients see their eligibility status immediately. See the form setup guide and the endpoint API reference.

​
Asynchronous Eligibility Checks (Workflow Action)

Morf can run asynchronous insurance eligibility checks through our partnership with Stedi. Using the Stedi Check Eligibility action in your Morf workflow automates the patient’s eligibility check, saving admin staff time from manual checks. Run an asynchronous eligibility check when:
  • Insurance information is entered in your intake form
  • An insurance policy is created in your EHR
  • Any time insurance information is captured
Use eligibility check results to:
  • Update the patient chart in your EHR
  • Alert your team of ineligible patients via Slack
  • Send an SMS or email to your patient with the eligibility check results
Have something else in mind? Reach out to Morf support to learn more about how Morf’s Stedi eligibility checks can fit into your workflows.

​
Prerequisites

Before you begin, confirm you have:
  1. A Morf organization.
  2. A Feathery form collecting insurance info connected to your Morf organization. Follow the Feathery Setup Instructions to get started. The form must collect:
    • insurance_plan_name
    • member_id
    • first_name
    • last_name
    • date_of_birth
    • insurance_relationship
  3. Your organization’s insurance information:
    • Organization Name
    • Organization or Provider NPI
    • Service Type Codes
  4. Custom profile properties in Morf to store eligibility check results:
    • stedi_payer_id
    • copay
    • coinsurance
    • deductible

​
Instructions

1. Create a workflow in Morf
In the Workflows tab, click + New Workflow. Select a trigger to kick off the workflow. For this example, select the Feathery Form Step Submission trigger.
2. Configure Update Profile Properties node
Primary and secondary insurance properties are standard properties in Morf.
Save the Feathery form insurance information filled out by the patient to the Morf primary_insurance profile properties in the Update Profile Properties node.
3. Configure Stedi Payer ID mapping
In the Update Profile Properties node, add stedi_payer_id to the Map Properties section. For the value, open a CEL expression and input the following, swapping in your org’s accepted insurance plans and corresponding payer IDs from the Stedi Payer Network:
4. Add and configure the Stedi Check Eligibility action
Add the Stedi Check Eligibility action to the workflow. Rename the object name to stedi_eligibility_result for use in downstream logic. Map the primary_insurance Morf properties to the corresponding parameters in the Map Properties section of the action. Be sure to swap in your org-specific values for organization name, NPI, and service type codes.
5. Add branching logic based on eligibility results
Add filters after the Stedi Check Eligibility action to route executions based on the eligibility result. Stedi branching logic In the filters, input the following CEL expressions to route executions based on the result of the Check Eligibility action for the eligible and not eligible insurances. Is Eligible:
Is Not Eligible:
6. (Optional) Save eligibility results to Morf profile
Using an Update Profile Properties action, save the results of the eligibility check to the custom profile properties copay, coinsurance, and deductible. These values are sourced from in_network_eligibility_summary, created by Morf from the returned Stedi response. Save Stedi results to Morf profile
7. (Optional) Slack message for ineligible results
To alert a team member about ineligible patients, configure a Send Incoming Webhook Message action on the ineligible branch.

​
Testing

Morf’s Stedi Check Eligibility action accepts mock patient data to test the endpoint using Morf’s test API key. In the Check Eligibility node configuration, set the Use Test API Key parameter to true. This allows mock patient eligibility data to be used to test the workflow. To test full functionality, trigger the workflow using mock patient data from Stedi’s mock eligibility examples.

​
Synchronous Eligibility Checks (Morf Forms)

Morf can run synchronous insurance eligibility checks through our partnership with Stedi. Using the Stedi Eligibility Endpoint in your Morf form instantly returns a user’s insurance eligibility, saving admin staff time from manual checks. Run a synchronous eligibility check when:
  • Insurance information is entered in your intake form
Use eligibility check results to:
  • Dynamically route patients through your intake form
  • Update the patient chart in your EHR
  • Send an SMS or email to your patient with the eligibility check results
Have something else in mind? Reach out to Morf support to learn more about how Morf’s Stedi eligibility checks can fit into your practice.

​
Prerequisites

Before you begin, confirm you have:
  1. A Morf token (contact Morf to get this).
  2. A Morf organization.
  3. Completed the baseline Feathery Setup Instructions.
  4. Your organization’s insurance information:
    • Organization Name
    • Organization or Provider NPI
    • Accepted Insurance Plans
    • Service Type Codes
  5. Feathery fields that collect patient information before the eligibility check runs. Confirm the field IDs match exactly:
    • first_name
    • last_name
    • date_of_birth
    • insurance_plan_name
    • member_id
    • insurance_relationship
    • policy_holder_first_name
    • policy_holder_last_name
    • policy_holder_dob

​
Instructions

1. Create hidden fields
In the form, go to Settings > Data Tracking > Edit Hidden Fields and add:
  • morf_token
  • stedi_payer_id
  • is_active_and_covered
To surface returned insurance plan information from the eligibility check result, also add:
  • insurance_type
  • plan_name
  • individual_deductible_remaining_dollars
  • co_insurance_percentage
  • copay_dollars
  • individual_deductible_dollars
2. Create step: Insurance Information
  1. Create a new step named Insurance Information.
  2. Add the required form fields:
    • first_name
    • last_name
    • date_of_birth
    • insurance_plan_name
    • member_id
    • insurance_relationship (e.g. self, parent, spouse)
  3. Look up the Stedi Payer ID for each accepted insurance plan on the Stedi Payer Network. Example: Aetna’s Payer ID is 60054.
  4. Configure insurance_plan_name as a dropdown:
    • Display label: the insurance plan name (e.g. Aetna)
    • Option value: the Stedi Payer ID (e.g. 60054)
If the policy holder is the person completing the form, you do not need to collect their first name, last name, or date of birth again.
3. Create step: Eligibility Check in Progress
  1. Create a new step named Eligibility Check in Progress.
  2. Add a loading image to the step — this will serve as the trigger element for the logic rule when viewed.
4. Create step: Eligibility Confirmed
  1. Create a new step named Eligibility Confirmed. Users land here when their insurance is eligible for your services.
  2. Optionally surface returned insurance information by referencing hidden fields in curly brackets — e.g. {{insurance_type}}, {{copay_dollars}}.
5. Create step: Eligibility Failed
Create a new step named Eligibility Failed. Users land here if their insurance is not eligible for your services.
6. Edit logic rule: Set Environment Variables
Add morf_token to your existing Set Environment Variables logic rule, with staging and production token values.
7. Create logic rule: Initialize Verification Check
  1. Go to Logic > Create New Logic Rule.
  2. Name the rule Initialize Verification Check.
  3. Configure the trigger:
    • Event trigger: Form Element is Viewed
    • Element trigger: the loader element on the Eligibility Check in Progress step
  4. Go to Advanced Logic > Edit Code and add the following. Replace organizationName, npi, and service_codes with your organization’s values.
8. Add endpoint API connector
Add an API connector for the Morf x Stedi Eligibility endpoint:
  • URL: https://api.morf.healthcare/v1/stedi/check_eligibility
  • Method: POST
  • Headers:
    • Content-Type: application/json
    • Authorization: Bearer {{morf_token}}
9. (Optional) Adding dependents to the eligibility check
Update the Initialize Verification Check rule with an updated request that includes dependent information.

​
Testing

Stedi offers mock eligibility requests for testing. See the Stedi mock requests documentation for available test cases. Open the test version of your form and fill in information matching one of the mock eligibility results. Use the test npi, organizationName, and serviceTypeCodes shown below:

​
Eligibility Check Endpoint API Reference

Morf’s eligibility endpoint is a wrapper around the Stedi API, with dates broken out into objects. Fields are required unless noted as optional. Use this endpoint when enabling synchronous eligiblity checks in your Morf form. See also: Stedi’s eligibility check documentation.

​
Request

  • A subscriber is the patient that’s insured.
  • For a dependent, include a dependent object structured the same as subscriber.
  • We recommend including member_id, date_of_birth, first_name, and last_name — payers are required to return a response if the member is in their database.
Endpoint: POST https://api.morf.healthcare/v1/stedi/check_eligibility Headers:
  • Authorization: $API_KEY
  • Content-Type: application/json

​
Response

A successful response returns a 200 status code with the fields below at the top level. Use is_active_and_covered and other fields for downstream logic.

​
Parameters

​
Parameters

​
Result Object Field Details

You can use the result of the action’s data as inputs to downstream workflow actions. Each fetch action requires an object name, which nests the action’s result data inside the downstream data context in the workflow. See Passing Data Between Actions for how to set it and reference the result from downstream nodes. Here we demonstrate how to refer to this data using the prefix $result_object_key.
​
Fetch Action Response Object