Streamlining enhanced Eligibility Endpoints with over 50 years combined knowledge parsing and coding Medical Benefit Data to provide front-end patient insurance eligibility and benefit verification processes which will improve the patient collections and reduce back office denials.
pVerify offers many different API services including Eligibility, Same or Similar and Claim Status. To learn more about each endpoint, see below. Click on each endpoint to see it in more detail on the pVerify API Documentation site.
pVerify’s enhanced Endpoints allows you to get the data you want without wading through complex objects, with over 50 years of combined experience.
Experts in the field
High level of knowledge and support delivers optimal results for your API needs for Rest API, Soap API, 271 Response, and MORE!
HIPAA Complaint & Scalable
Reinforced Cloud-Based Environment with Highly scalable Disaster-resistant Infrastructure Showcasing Business Rules & Human-enabled AI
Supported for Eligibility. Finally, an API driven interface to get eligibility data from non-EDI Payers like California IPAs and Vision Payers.
Description: This is the mainstay of our eligibility endpoints and is designed to be used for 90% of use cases. This is the endpoint with the most information returned. This can be used for submission for non EDI payers as well as EDI payers. For Non EDI payers you would call GetEligibilityResponse to return the eligibility data.
Request: This object contains payer, provider, and subscriber/dependent information.
Response: We return demographics, Health Benefit Plan Coverage, Service types from payer, and from these we create new custom fields – a section for copay/coinsurance/OOP/deductible, active status, and payer change object.
Description: This is used for non EDI payers to return the same object format as Eligibility Inquiry but only with key information that the customer wants, for example copay, active status, and deductible.
Request: The Eligibility ID needs to be in the call.
Response: The Response for GetEligibilityResponse is the same as for EligibilityInquiry but will be limited to what customer wants from the non EDI payer.
Description: Eligibility summary allows you to populate data based on the Practice Type. While most of the objects are similar to other eligibility calls, there is a new object which is specific to practice type. EligibilitySummary is not supported for back office payers.
Request: This object contains payer and subscriber/dependent information.
Response: We return information related to Copay, Coinsurance and deductible.
Description: GetEligibilitySummary returns the response from the EligibilitySummary POST call using a unique request id provided in the EligibilitySummary response. EligibilitySummary is not supported for back office payers.
Request: RequestId returned in EligibilitySummary response must be in URL.
Response: The Response for GetEligibilitySummary is the same as for EligibilitySummary.
EDI and Non EDI endpoints
Description: GetEligiblity is a new series of endpoints that are RESTful so you can get the key you want. For example calling https://api.pverify.com/API/GetEligibility/Status/5444 after a POST using EligiblitySummary or EligiblityInquiry will get you only the status “Active”.
Request: Parameters include the key and value for your eligibility request.
Response: This endpoint will retrieve a list of supported keys by single value API.Key in this list.
Description: This is a series of calls to return one piece of information from our parsed results, for example Specialist Copay. EligibilityInquiry or EasyEligibility must be used first.
Request: Parameter is Eligibility Request ID.
Response: Object is a single piece of data for example “$20.00” for copay.
Description: This endpoint will retrieve a list of pending transactions. It is intended to show which back office eligibility transactions are not complete yet.
Request: Contains the authorization credentials as well as the date of service in mm-dd-yyyy format.
Response: Returns and eligibility transactions which are not yet complete. Objects contain patient name, dob, provider name and NPI along with internal information such as the transaction id.
Eligibility Non EDI endpoints
Description: The EasyEligibility endpoint is designed to facilitate easy access to Eligibility Information in just one step, Token call not needed, Request and Response are simplified.
Request: Request object includes patient name, DOB, Payercode, providerlast name, memberID, and DOS among others.
Response: We return eligibility status, error messages as discrete fields then the unparsed full textual report.
Description: CancelTransaction is intended for use with back office transactions, to cancel a transaction that is not able to be completed in time for the patient’s visit.
Request: Request object need only contain the id for the transaction you wish to cancel.
Response: Returns confirmation that the transaction has been canceled.
Same or Similar
Description: Quickly gives you access to Same/Similar checks across all 4 medicare jurisdictions, including L codes.
Request: Object contains memberId, patient name, DOB, hcpcsCodes as well as information such as date of service.
Response: Object contains requesstId in addition to status and an apiResponseMessage.
Description: This call is used to get the Same or Similar transaction result later using a unique request ID.
Request: The request headers contain payer information that is standard for same or similar
Response: Response returns a series of claims containing the Same or Similar request information.
Description: Call will get an estimated price from CMS (Medicare) non-facility price index.
Request: In order for you to use this, we must add the estimator service (which is free) to your account. Additionally, for the Zip code, use 0 for national pricing, and you can send an array of CPT codes per the Postman example.
Response: The response object returns the amount the patient owes, the copay along with other information such as the the Coinsurance amount.
Description: ClaimStatusInquiry call takes in subscriber or dependent demographic information, along with the authorization token, and returns the claim status among other information.
Request: Request includes payer, provider, claim and subscriber information (additionally, dependent information may be included if necessary).
Response: The response contains information on the claim status of the requested subscriber and/or dependent.
Description: This GET method is used to obtain the transaction result later using a unique request ID. Note: the data is deleted after 90 days.
Request: A URL parameter containing a unique claim status transaction id.
Response: A successful GetClaimStatusResponse call will have the same format as the ClaimStatusInquiry response.
Skilled Nursing Facility
Description: The pVerify API for SNF is like Same or Similar in that it will not deliver a result instantly, instead the user is expected to call the GET method 1 minute later.
Request: SNFInquiry requires the standard pVerify credentials and a series of body fields specified in the documentation page.
Response: The response object the expected time to get the SNF response and the request ID used in GetSNFResponse.
Description: This GET call is intended to retrieve the SNF response initiated by the SNFInquiry POST call. By adding the requestId received in the POST call, users can retrieve the SNFInquiry Response.
Request: GetSNFResponse requires the requestId from SNFInquiry to be placed in the URL parameter for the call.
Response: The response object returns the details of the SNFInquiry.
Request: Request demographic information in addition to the standard pVerify credentials.
Response: The response contains a unique request ID to be used when calling GetMBIResponse.
Description: This GET method is used to obtain the MBI result later using a unique request ID. Note: the data is deleted after 90 days.
Request: A URL parameter containing a unique MBI transaction id.
Response: A successful MBIResponse call will have the transaction result later using the unique request ID provided in MBIInquiry.
In addition to our RESTfull interfaces, pVerify offers a direct EDI 270/271 interface for those who already have existing EDI connections.
Interested in learning more? Send us a message by clicking the link below.