Healthcare · Moraph software

Referral & Prior Auth Gateway

Eligibility checked and prior authorizations submitted before the patient arrives

Book a demonstrationRequest a technical briefingFactsheet

Overview

What you are buying

The Referral & Prior Auth Gateway sits between your EHR and payers. It checks coverage for each referral or order, works out whether the payer needs prior authorization, assembles and submits the request electronically where the payer accepts it, and tracks every request to a decision. Nothing waits unnoticed in a fax tray, a payer portal or someone's inbox.

The problem it solves

Prior authorization is still largely manual. Staff check coverage in one place, look up payer rules in another, gather notes from the EHR, submit through a mix of portals, phone and fax, then chase status by hand. When a step is missed, the patient's appointment moves or the claim is denied after the service.

  • Coverage problems are often found on the day of service, when there is no time to fix them.
  • Each payer has its own rules and submission channel, and they change often.
  • Requests for more information arrive by fax or portal message and are easy to miss.
  • Authorizations expire or are tied to a different provider or site, which surfaces only when the claim is denied.

Who uses it

  • Referral coordinators and prior authorization specialists
  • Patient-access and scheduling teams
  • Revenue-cycle and denial-management leaders
  • Clinic and department managers
  • Clinicians and their staff, who supply documentation when asked

Requirements it supports

HIPAA transaction standards (X12 270/271 and 278)CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)HIPAA Privacy and Security RulesHL7 FHIR and the HL7 Da Vinci implementation guides (CRD, DTR, PAS)State prior authorization laws, as configured for your payers

The product supports these requirements; meeting them remains your organization’s responsibility.

See how it works

A short walkthrough

Illustrative screens with fictional sample data. They show the workflow, not any client’s data or configuration, and the layout of the product itself differs. A live demonstration uses the product with sample data.

  1. Step 1

    The worklist

    Coordinators see every referral with its coverage and authorization status, soonest appointment first.

    PatientServicePayerEligibilityAuthorizationAppointment
    Patient 4471MRI lumbar spineExample Health PlanActiveNeededIn 3 days
    Patient 2208Cardiology consultExample Medicare AdvantageActiveSubmittedIn 5 days
    Patient 9015Physical therapyExample CommercialActiveApprovedIn 6 days
    Patient 3362Sleep studyExample Health PlanInactiveOn holdIn 9 days
    Patient 5120Outpatient surgeryExample CommercialActiveNot requiredIn 12 days
    Coordinators see every referral with its coverage and authorization status, soonest appointment first.

  2. Step 2

    The coverage check

    The eligibility response is stored with the referral and summarized, so a coverage problem is found before scheduling.

    Patient 3362 · Coverage check

    Payer
    Example Health Plan
    Response
    Coverage not active on the service date
    Checked
    Electronically (X12 270/271)
    Member ID
    Fictional ID

    Next

    • Patient access to confirm current coverage with the patient
    • Recheck automatically when coverage details are updated
    The eligibility response is stored with the referral and summarized, so a coverage problem is found before scheduling.

  3. Step 3

    Does it need authorization?

    The payer rules library shows whether the payer requires authorization for this service, and which rule applies.

    Example Health Plan · Advanced imaging

    Service
    MRI lumbar spine
    Place of service
    Outpatient hospital
    Authorization
    Required
    Preferred route
    Electronic (X12 278)
    Rule last reviewed
    Fictional date

    Payer asks for

    • Order with diagnosis codes
    • Clinic note describing symptoms and examination
    • History of conservative treatment
    The payer rules library shows whether the payer requires authorization for this service, and which rule applies.

  4. Step 4

    Building the request

    The Gateway shows what the payer requires and what has been gathered from the record.

    Patient 4471 · MRI lumbar spine

    Payer
    Example Health Plan
    Authorization required
    Yes, per payer rules
    Route
    Electronic (X12 278)
    Ordering clinician
    Fictional clinician

    Documentation

    • Order and diagnosis codes: attached
    • Recent clinic note: attached
    • Conservative treatment history: needs clinician confirmation
    The Gateway shows what the payer requires and what has been gathered from the record.

  5. Step 5

    To a decision

    Every step is recorded until the payer decides, and the result goes back to the referral.

    Request history

    1. Request submitted electronicallySpecialist
    2. Payer requested additional informationPayer
    3. Clinical note added and resubmittedSpecialist
    4. Approved, valid for 60 daysPayer
    5. Referral updated, ready to scheduleGateway
    Every step is recorded until the payer decides, and the result goes back to the referral.

  6. Step 6

    What needs attention

    Expiring authorizations, unanswered payer questions and denials, gathered for the team lead.

    PatientServiceIssueWaiting onAppointment
    Patient 7734Physical therapyAuthorization expires before final visitSpecialistIn 4 days
    Patient 2208Cardiology consultPayer asked for recent resultsClinicianIn 5 days
    Patient 6051CT abdomenDenied: documentation incompletePeer-to-peer reviewRescheduled
    Patient 8812Infusion therapyNo response from payerStatus checkIn 7 days
    Expiring authorizations, unanswered payer questions and denials, gathered for the team lead.

Workflows

The principal workflows

  1. Intake

    Referrals and orders arrive from your EHR into one worklist, by department and urgency.

    • New referrals and orders are received from the EHR through an interface, with patient, coverage, ordering clinician and service codes.
    • Duplicate orders for the same patient and service are flagged rather than worked twice.
    • Each item is placed in a department queue and sorted by urgency and appointment date.
    • Coordinators can also enter a referral by hand when one arrives outside the EHR, such as from an outside practice.
    • Ownership is assigned so every item has one person responsible for it.

  2. Eligibility and benefits

    Coverage is checked electronically and the response stored with the referral, so problems surface before scheduling.

    • An X12 270 eligibility inquiry is sent through your clearinghouse for each new item.
    • The 271 response is stored with the referral and summarized: active coverage, plan, and benefit details relevant to the service.
    • Inactive coverage, coordination-of-benefits questions or missing member details are flagged for patient access to resolve.
    • Coverage is rechecked before the appointment if the referral has been open for a while.
    • Results stay with the record as evidence of what was known and when.

  3. Authorization

    Payer rules decide whether authorization is needed. Where it is, the request is assembled from the order and clinical documentation and submitted electronically where the payer supports it.

    • The payer rules library is checked for the payer, plan, service and place of service to decide whether authorization is required.
    • Where a payer offers a coverage requirements API (Da Vinci CRD), the requirement can be confirmed with the payer directly.
    • The documentation the payer asks for is gathered from the EHR: order, diagnosis, recent notes and results.
    • Gaps, such as a missing note on prior treatment, are routed to the ordering clinician's team.
    • The request is submitted as an X12 278 through the clearinghouse, through a payer's prior authorization API where available, or prepared for a specialist to submit on the payer's portal.

  4. Follow-up

    Pending, approved, denied and expiring authorizations are tracked, with requests for more information routed back to the right person and outcomes written back to the referral.

    • Status responses are recorded as they arrive, and items with no response are surfaced for a status check.
    • Requests for more information are routed to the person who can supply it, with the payer's question attached.
    • Approvals are recorded with the authorization number, approved units, dates and any site or provider restriction.
    • Denials are routed with the payer's stated reason for peer-to-peer review or appeal.
    • The outcome is written back to the EHR referral so scheduling and billing see the same information.

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Referral coordinator

Referral coordinator, scheduling coordinator, patient-access representative

Keeps referrals and orders moving from intake to a scheduled appointment, with coverage confirmed first.

Sees

  • The intake worklist for their departments or locations
  • Eligibility and benefit responses for referrals they work
  • Authorization status for each referral, without the full clinical packet
  • Notes and hand-offs from specialists and leads

Does

  • Claims and works referrals from the intake queue
  • Runs or reruns eligibility checks and records the outcome
  • Flags coverage problems to the patient-access lead
  • Hands referrals that need authorization to a specialist
  • Marks referrals ready to schedule once authorization is in place

Cannot

  • Submit authorization requests to payers
  • Change payer rules, queues or interface settings
  • Open clinical documents beyond those needed for the referral
Approvals
None required for their own work; coverage exceptions go to the patient-access lead.
Notified about
When a referral is assigned to them, when coverage comes back inactive, and when an authorization they are waiting on is decided.

Prior authorization specialist

Prior authorization specialist, utilization review coordinator, authorization representative

Builds complete authorization requests, submits them and follows each one to a decision.

Sees

  • Authorization requests assigned to them or their team
  • The documentation packet assembled from the EHR for each request
  • Payer rules and documentation requirements for the service
  • Payer responses, requests for information and decision history

Does

  • Assembles and checks the documentation packet
  • Sends documentation requests to clinicians
  • Submits requests electronically, or prepares them for the payer's own portal and records the submission
  • Answers payer requests for additional information
  • Records approvals, denials, authorization numbers and validity dates
  • Routes denials for peer-to-peer review or appeal

Cannot

  • Edit payer rules or interface settings
  • Change user access or queue assignments
  • Alter clinical documentation from the EHR
Approvals
Submission does not need a second approval by default; your organization can require lead review for chosen services or payers.
Notified about
When documentation they asked for arrives, when a payer pends or decides a request, and before an authorization they recorded is due to expire.

Clinician or clinical staff

Ordering clinician, nurse, medical assistant, clinical documentation staff

Supplies the clinical information a payer needs, without having to work in the Gateway day to day.

Sees

  • Documentation requests addressed to them
  • The order and the specific question being asked
  • The outcome of requests they contributed to

Does

  • Answers documentation requests with notes, confirmation or attachments
  • Confirms clinical details such as treatment history when asked
  • Takes part in peer-to-peer reviews arranged from a denial

Cannot

  • See worklists, other patients' requests or reports
  • Submit requests to payers
  • Change any configuration
Approvals
None; clinical judgment stays in the EHR and with the clinician.
Notified about
When a documentation request is sent to them, and when a peer-to-peer review they are needed for is arranged.

Patient-access lead

Patient-access supervisor, referral manager, authorization team lead

Runs the team's queues so work is balanced and nothing stalls.

Sees

  • All worklists for their departments or locations
  • Workload by person and queue
  • Requests that are overdue, pended or close to an appointment date
  • Coverage problems escalated by coordinators

Does

  • Assigns and reassigns work between coordinators and specialists
  • Resolves coverage exceptions and decides next steps with the patient or department
  • Reviews requests your organization has marked for lead review
  • Sets queue priorities within the rules an administrator configures

Cannot

  • Change payer rules or interface settings
  • Grant or remove user access
Approvals
Approves requests that your organization has set to need lead review, and coverage exceptions raised by coordinators.
Notified about
When items in their queues become overdue, when a request needs their review, and when a coordinator escalates a coverage problem.

Revenue-cycle analyst

Revenue-cycle analyst, denials analyst, patient financial services analyst

Finds patterns in denials, expirations and payer behaviour so the process can be improved.

Sees

  • Reports by payer, service, department and outcome
  • Denial reasons and follow-up history
  • Authorizations nearing expiry across the organization

Does

  • Runs and exports reports
  • Reviews denial trends and recommends rule or process changes
  • Records follow-up actions on denials passed to the revenue cycle

Cannot

  • Submit or change authorization requests
  • Open full clinical documentation packets
  • Change configuration
Approvals
None; recommended rule changes are made by an administrator.
Notified about
On a schedule you choose, with report summaries; not for individual requests.

Administrator

Application administrator, revenue-cycle systems analyst, IT analyst

Keeps the Gateway configured: payer rules, users, queues and interfaces.

Sees

  • All configuration, users, roles and queues
  • Interface status and message errors
  • The audit trail of configuration and permission changes

Does

  • Maintains the payer rules library and records when each rule was last reviewed
  • Adds users, assigns roles and sets department and location scope
  • Creates and adjusts queues and routing
  • Monitors interfaces with the EHR, clearinghouse and payer APIs

Cannot

  • Submit authorization requests or record payer decisions in their administrator role
  • Delete audit records
Approvals
Permission changes for administrator-level access can be set to need a second administrator's approval.
Notified about
When an interface fails or messages are rejected, and when a payer rule is due for review.

Compliance or privacy officer

HIPAA privacy officer, compliance analyst, internal auditor

Checks that access to patient information is appropriate and that the process can be evidenced.

Sees

  • The audit trail of who viewed and changed each request
  • User access lists and role assignments
  • Reports, without working access to queues

Does

  • Reviews access to records and investigates questions about it
  • Exports audit evidence for internal review
  • Takes part in periodic access reviews

Cannot

  • Change requests, configuration or user access
  • Submit anything to payers
Approvals
None; findings go to the administrator and patient-access lead to act on.
Notified about
Only when they subscribe to access-review reminders.

Permissions at a glance

ActionCoordinatorSpecialistClinicianLeadAnalystAdminCompliance
Work the intake worklistOwn work onlyView onlyNo accessFullNo accessNo accessNo access
Run eligibility checksFullFullNo accessFullNo accessNo accessNo access
View documentation packetsNo accessOwn work onlyOwn work onlyView onlyNo accessNo accessView only
Request documentation from cliniciansNo accessFullNo accessFullNo accessNo accessNo access
Answer documentation requestsNo accessNo accessOwn work onlyNo accessNo accessNo accessNo access
Submit authorization requestsNo accessOwn work onlyNo accessApprovesNo accessNo accessNo access
Record payer decisionsNo accessOwn work onlyNo accessFullNo accessNo accessNo access
Assign and reassign workNo accessNo accessNo accessFullNo accessNo accessNo access
Run and export reportsNo accessView onlyNo accessFullFullView onlyView only
Maintain payer rulesNo accessView onlyNo accessView onlyView onlyFullNo access
Manage users and rolesNo accessNo accessNo accessNo accessNo accessFullView only
View the audit trailNo accessNo accessNo accessView onlyNo accessView onlyFull
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Roles follow segregation of duties and the HIPAA minimum-necessary standard: each person sees the patient information their task needs, and clinical packets are limited to the people building or answering a request.
  • Access is scoped by department and location as well as role, so a coordinator in one clinic does not see another clinic's worklist unless your organization chooses to share it.
  • Your administrators review user access periodically, and every permission change is recorded in the audit trail with who made it and when.
  • Referring offices outside your organization do not get accounts by default; where you want them to send referrals or see status, they can be given a limited external role covering only their own referrals.

Features

What it does

One worklist

Every referral and authorization in one place, sorted by urgency and appointment date.

Payer rules library

Which services need authorization from which payer and plan, maintained in one place with the date each rule was last reviewed.

Electronic eligibility

X12 270/271 coverage checks through your clearinghouse, stored with the referral.

Electronic submission

X12 278 through your clearinghouse, and payer prior authorization APIs where payers provide them.

Documentation packets

The order, notes and results the payer asks for, gathered from the EHR into one request.

Clinician requests

When documentation is missing, a specific request goes to the ordering clinician's team, not a general message.

Status tracking

Decisions, pends and expiry dates tracked, with reminders before an authorization lapses.

Authorization details

Authorization number, approved units, valid dates and site or provider restrictions recorded and checked against the appointment.

Denial follow-up

Denials routed with the payer's reason for peer-to-peer review or appeal, with the history kept together.

Portal hand-off

For payers without an electronic route, the request is prepared in full so a specialist can submit it on the payer's portal and record the result.

Write-back to the EHR

Status and outcomes written back to the referral, so scheduling and billing work from the same facts.

Audit trail

Every check, submission, response and change recorded with who did it and when.

Integrations

How it connects to your systems

Connects toHowWhat flows
EHR orders and referralsOrders and referrals received through HL7 v2 or FHIR interfaces.In: patient, coverage, order, diagnosis and clinician details.
EHR documentationClinical notes and results retrieved for the request packet through FHIR or document interfaces.In: notes, results and documents named in the payer's requirements.
EHR write-backStatus, authorization numbers and outcomes written back to the referral.Out: authorization status, number, dates and units.
ClearinghouseEligibility and authorization transactions through the clearinghouse you already use.Out and in: X12 270/271 and 278 transactions.
Payer APIsFHIR-based coverage requirements and prior authorization APIs following the HL7 Da Vinci guides, where payers offer them.Out and in: coverage requirements, request bundles and decisions.
SchedulingAppointment dates read from your scheduling system so work is sorted by when the patient is due.In: appointment date, location and provider.
Single sign-onStaff sign in through your identity provider (SAML or OpenID Connect).In: identity and group membership for roles.
Work APIWorklist and outcome data available to your reporting and analytics tools through the Moraph Work API.Out: referral, request and decision records.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Business associate agreement

Moraph signs a business associate agreement covering the protected health information the Gateway processes.

Encryption and key control

Client data is encrypted, with keys Moraph staff cannot access without explicit, time-bound authorization, as described in our Trust Center.

Role-based access

Staff see the queues and records their role needs, and administrators control who has which role.

Minimum necessary

Request packets include the documents the payer's requirements call for, not the whole chart.

Audit logging

Every view, change, submission and export is logged with the user and time, and available for your compliance reviews.

Independent assurance

The Gateway runs within Moraph's SOC 2 Type II and ISO/IEC 27001 programs; reports are available under confidentiality terms through the Trust Center.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

12 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Worklist operations

Open referrals and authorizations

For referral coordinators, prior authorization specialists and patient-access leads

Every open referral and authorization request with its current status, the queue it sits in and how long it has been open.

Break down by
Queue, Payer, Service or procedure, Department or location, Age of the item
Delivered as
Live dashboard, with export to CSV or Excel
Used for
Balancing work across the team each day and spotting items that have stalled.

Upcoming appointments without a decision

For referral coordinators and patient-access leads

Scheduled appointments and procedures that still have no eligibility result or authorization decision.

Break down by
Appointment date, Payer, Department or location, Authorization status
Delivered as
Live dashboard and a scheduled email digest
Used for
Acting before the patient arrives, so visits are not cancelled or performed without authorization.

Requests for more information

For prior authorization specialists, clinicians and patient-access leads

Outstanding payer requests for additional information, and who each one is waiting on: the payer, a clinician or the specialist.

Break down by
Waiting on, Payer, Ordering clinician, Age of the request
Delivered as
Live dashboard, with export
Used for
Chasing the right person and preventing requests from lapsing while they wait.

Team workload and throughput

For patient-access leads and department managers

Items started, completed and still open for each person and queue over a period you choose.

Break down by
Person, Queue, Payer, Week or month
Delivered as
Dashboard and scheduled export
Used for
Planning staffing and spotting where work is piling up.

Payer performance

Decisions by payer

For revenue-cycle analysts and patient-access leads

Approvals, denials, pends and withdrawals for each payer, with the time from submission to decision as recorded in the Gateway.

Break down by
Payer and plan, Service or procedure, Submission route, Month
Delivered as
Dashboard, with export to CSV or Excel
Used for
Showing which payers and services cause the most delay, for operational and contracting conversations.

Denials and their stated reasons

For revenue-cycle analysts, denial-management staff and managed-care contracting

Every denial with the payer's stated reason, the service, and whether it went to peer-to-peer review or appeal and what happened.

Break down by
Payer, Denial reason, Service or procedure, Ordering department, Appeal outcome
Delivered as
Dashboard and scheduled export
Used for
Finding avoidable denials, fixing documentation gaps and preparing payer meetings.

Submission route by payer

For patient-access leads and revenue-cycle analysts

How requests reach each payer: electronic transaction, payer API or the payer's own portal.

Break down by
Payer, Route, Service or procedure, Month
Delivered as
Dashboard, with export
Used for
Showing where manual portal work remains and which payers to raise electronic submission with.

Revenue cycle

Expiring authorizations and units used

For prior authorization specialists and revenue-cycle analysts

Approved authorizations nearing their end date, and those where most of the approved visits or units have been used.

Break down by
Expiry date, Payer, Service, Department or location
Delivered as
Live dashboard and reminders to the item's owner
Used for
Requesting extensions or new authorizations before care continues without one.

Services performed without a valid authorization

For revenue-cycle analysts and patient-access leads

Completed services, as written back from the EHR, where the authorization was missing, denied or expired on the date of service.

Break down by
Payer, Service, Department or location, Reason
Delivered as
Scheduled report, with export
Used for
Catching likely denials early and correcting the process that let them through.

Eligibility problems found before the visit

For referral coordinators and patient-access leads

Referrals where the eligibility check returned inactive coverage, a different payer or a benefit limit, and what was done about it.

Break down by
Problem type, Payer, Department or location, Resolution
Delivered as
Dashboard, with export
Used for
Resolving coverage before the appointment and spotting recurring registration errors.

Compliance and audit

Request history and audit trail

For compliance staff, internal audit and administrators

For any referral or authorization, every action, document sent, payer response and status change, with who did it and when.

Break down by
Patient record, Person, Action type, Date range
Delivered as
On-screen history, with export for an audit or complaint
Used for
Answering payer, patient or auditor questions about exactly what was sent and when.

Payer rule review status

For administrators and patient-access leads

Each payer rule in the library with the date it was last reviewed and who reviewed it.

Break down by
Payer, Service, Last reviewed, Reviewer
Delivered as
Dashboard, with export
Used for
Keeping rules current as payer policies change, and showing that they are maintained.

Exports, access and evidence

  • Every report can be exported to CSV or Excel, and most can be scheduled to arrive by email for the people entitled to see them.
  • Authorized users can build their own views by choosing filters, columns and groupings, and save them for their team.
  • Report data is also available through the Moraph Work API, so your data warehouse or business-intelligence tools can combine it with EHR and billing data.
  • Reports respect each user's role and locations, and show only the patient information a report needs, in line with the HIPAA minimum necessary standard.
  • Reports can be rerun as of a past date to reproduce what was shown at the time, and every report run and export is recorded in the audit trail.

Deployment

Where and how it runs

Moraph cloud

Hosted by Moraph in the United States region, under a business associate agreement.

Dedicated environment

Single-tenant hosting where your policies require it, scoped in the proposal.

Phased rollout

Can start with one department, service line or set of payers and expand under the same configuration.

With a managed service

Optionally paired with a Moraph managed service for interface monitoring and platform administration.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Payer and service inventory

Together we list the payers, plans and services that matter most to you, which sets the order in which rules are configured.

Payer rules setup

Authorization rules configured for your payers and services from published payer policies and your team's knowledge, and reviewed with your specialists.

EHR interfaces

Inbound orders, documentation retrieval and write-back built and tested with your EHR and integration teams.

Clearinghouse connection

Eligibility and 278 transactions enabled through your clearinghouse, including any enrollment the clearinghouse requires for each payer.

Queues and roles

Departments, queues, assignments and roles set up to match how your teams are organized.

Training and go-live

Coordinators, specialists and administrators trained on your configuration, and go-live planned by department or service line.

Limitations

What it does not do

Worth knowing before you evaluate it.

  • Where a payer accepts requests only through its own portal, the Gateway prepares the request and a specialist submits it there.
  • Medical-necessity documentation comes from your clinicians. The Gateway gathers it; it does not write it.
  • Approval decisions are the payer's. The Gateway makes requests complete and visible, but cannot guarantee an outcome.
  • Payer rules are configured with you during implementation and need to be kept current as payer policies change.
  • Payer prior authorization APIs are only used where a payer offers one and the connection has been set up; availability varies by payer.
  • Electronic eligibility and 278 transactions depend on your clearinghouse supporting them for each payer.
  • It does not submit claims or post payments. It works alongside your billing system.
  • Appeals are tracked and supported with the request history, but appeal letters are written by your staff.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

  1. Bring a list of your highest-volume services and payers, and ask to see how the rules for them would be configured.
  2. Ask how a request for a payer with no electronic route is handled from start to finish.
  3. Ask to see a request for more information arrive and be routed to the right clinician.
  4. Check which of your clearinghouse's eligibility and 278 connections are available for your payers.
  5. Ask your EHR team which order, document and write-back interfaces are available, and review them with our engineers.
  6. Review the reports you would use for denials and expiring authorizations, and whether they match how you manage the work today.

Questions

Frequently asked questions

Does it replace our clearinghouse?

No. Eligibility and authorization transactions go through the clearinghouse you already use. The Gateway decides what to send, assembles it and tracks the response.

Which EHRs does it work with?

It connects through standard HL7 v2 and FHIR interfaces rather than a single vendor's proprietary connection. The interfaces available in your EHR are confirmed in discovery.

What happens with payers that only accept portal submissions?

The Gateway prepares the complete request and tells the specialist where to submit it. The specialist records the submission and the outcome, so the item is tracked the same way as electronic requests.

Does it use the payer prior authorization APIs required under CMS-0057-F?

It is designed to use FHIR-based prior authorization APIs that follow the HL7 Da Vinci guides where a payer offers one. Which payers have usable APIs, and when, varies; we review that with you during implementation.

Who keeps the payer rules up to date?

Rules are configured with your team during implementation. After go-live, your administrators maintain them as payer policies change, and each rule shows when it was last reviewed.

Can clinicians use it without learning a new system?

Clinicians and their staff receive specific requests for missing documentation and can respond without working the full queue. How those requests reach them is agreed during design.

Next steps

Evaluate Referral & Prior Auth Gateway

Book a demonstration

See the product working with sample data, focused on your workflows.

Request a demonstration

Request a technical briefing

Architecture, integrations, security and hosting, with our engineers and your technical team.

Request a briefing

Factsheet

This page on two sides, to share with colleagues or add to your evaluation file.

Open the factsheet

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Referral & Prior Auth Gateway guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Referral & Prior Auth Gateway support guide.

Related products