data-spy="scroll" data-target=".scrollspy"

API Descriptions

Take a deeper dive into PokitDok's API Descriptions to see how our software works to streamline healthcare transactions and power the business of health.

Benefit Enrollment

Benefit enrollment and maintenance files are typically accepted in PokitDok’s simplified JSON schema via an HTTP POST request. Once you POST an enrollment API request and it passes PokitDok validation, an activity is created in our system and it enters a "scheduled" state. We return the activity ID which can then be used with the Activities API to track the status of the activity as it moves through the workflow. Our system will pick up "scheduled" activities and submit to the trading partner via their approved secure file transfer method.

Benefit Enrollment Graphic

Once the enrollment or maintenance request has been accepted by the trading partner, it will pass through their validation system. Responses and validation procedures may vary between trading partners. File requirements may also vary between trading partners. For example some may return error reports, some may only accept and process submissions once a month, etc. Confirmation of files received as well as any reports will be returned to the submitter for review.

PokitDok only transmits 834 files and responses to and from carriers. We do not perform scrubbing or editing of submissions, or manage benefits. File transmission is subject to carrier and group requirements. Since enrollment requirements vary greatly between carriers, please contact us to get started integrating the Benefits Enrollment and Maintenance API into your solution.

What makes PokitDok’s enrollment API different from other benefit administration products?

The enrollment endpoint eases the creation and transmission process of benefit enrollment and maintenance files. PokitDok only transmits 834 files and responses to and from carriers. We do not perform scrubbing or editing of submissions, or manage benefits. In short, the PokitDok API handles the heavy lifting of communicating with trading partners, and you build the interfaces and workflows that suit your business or application.

What carriers are currently supported?

Enrollment connectivity currently varies between carriers. Please contact us to inquire about the carrier you are interested in.

Does PokitDok store group or plan enrollment information?

No, currently PokitDok does not maintain plan information or past enrollment transactions.

How will we be notified when a file has been accepted with a carrier?

Responses will vary between carriers. Error or load reports will be returned to the submitter by a secure transmission method. The status of all transmissions is viewable in our API Dashboard or, programmatically through our Activities API.

Does the PokitDok API support change and full files?

Yes, currently PokitDok supports both full and change files.

What are the steps in the process to begin submitting EDI through PokitDok?

Please contact us to get started integrating benefits enrollment and maintenance into your solution.

Claims Status

Claims Status API requests are submitted in real-time. Once a request passes PokitDok validation, the request is sent to the trading partner. If request is valid, a response is returned in real-time (typically within a few seconds). An activity is created in our system at submission. We return the activity id which can then be used with the Activities API. Response times can vary by trading partner.

Claims Status Graphic

Why am I not seeing deductible or other benefit information?

We return all available eligibility and benefit information provided by the trading partner. If no deductible information is included, there may not be a deductible. In addition, some plans return $0 when there is no deductible.

Why am I getting unable_to_respond_now?

Trading partners may experience unscheduled downtimes. Please try again later or call the trading partner on the back of the member’s card for eligibility and benefit information. Check out our list of reject reasons in our documentation.

Claim Submission

Claims are typically accepted via a batch file transmission. Once you POST a Claims API request and it passes PokitDok validation, an activity is created in our system and it enters a "scheduled" state. We return the activity id which can then be used with the Activities API to track the status of the activity as it moves through the workflow at no charge. Our system will pick up "scheduled" activities and submit to the trading partner via their approved secure file transfer method. After an activity is transmitted to the trading partner, it will enter a "waiting" state for generally 24 hours. There may be additional delays if the trading partner is experiencing technical difficulties. A trading partner's first response lets you know if the request has been accepted (or rejected) by their claims validation system.

Claims Status graphic

Once your claim submission is accepted by the trading partner, it will enter their adjudication system. A tracking id will be assigned after passing the validation stage, which can then be used in claims status requests to track the claim. A claim can be monitored via a Claims Status request once the claim has been accepted in the trading partner’s adjudication system. If you submit a Claims Status API request right after submitting a claim, it will not yet be visible. Claims may sit in a queue for generally a week before entering the adjudication system so a Claims Status API request will not return anything during this time period. Once adjudication is complete, the trading partner will return an electronic remittance advice or ERA (if elected to receive ERAs), otherwise a paper remittance advice is sent with final adjudication information.

What happens when patient-paid amount is equal to the total claim amount?

If you’re submitting claims for cases where a patient pays in full for the service ($0 claims) and want the service(s) contributed toward the patient deductible, and patient has not yet met their deductible, the final claim status result will usually return the claim is finalized and denied since the trading partner didn't pay but the applied_to_deductible value will be set to true.

Are there multiple statuses for a single claim? If so, how do I know which one is the most recent?

This varies by trading partner but it is possible for a trading partner to return several status values per service or claim so we return them as a list. If you do encounter multiple status values, you can sort them by the status_effective_date if you want to present them in order or find the most recent status information.

If you do a claim status request while the insurance company is requesting different types of additional information to support the claim, you might see several statuses returned to indicate the date/status of those information requests.

Is there a way to check multiple claims statuses from different patients with a single API call?

The claim status API request is limited to a single patient but you can request claim status information for that patient/provider combination over a given period of time. You’ll receive a list of claims for that patient matching the service date period that was specified in the request. That's a common use case when the specific claim tracking id is not known but the date of service (or a general time period) is known.

Do you support custom identifiers with your activity callbacks?

You can monitor your API activities by using your activity_id with the Activities API to track the status of the activity (no charge). In addition, you can use the callback_url in your claims requests to be notified when a request has been received from the trading partner or if it fails. You will want to ensure that the callback url you provide uses https. The full activity will be posted back to your callback_url. The result portion of the activity will contain the current claim status information.

Do you support custom identifiers with your activity callbacks?

You can include additional data in your requests that's specific to your system if that helps to associate the activity data back up with a record or records in your system. application_data is the name of that optional section. We store it on the activity for you and echo it back in the responses.

How do receive 835 electronic remittance advice (ERAs)?

You must elect to receive this transaction with the trading partner. Please contact us to get further information or to enroll.

Eligibility

Eligibility API requests are submitted in real-time. Once a request passes PokitDok validation, the request is sent to the trading partner. If request is valid, a response is returned in real-time (typically within a few seconds). An activity is created in our system at submission. We return the activity id which can then be used with the Activities API. Response times can vary by trading partner.

Eligibility Graphic

Why am I getting provider_not_on_file?

Some trading partners require a contracted or networked provider NPI be used in the eligibility request. Check out our list of reject reasons in our documentation.

Why am I not seeing deductible or other benefit information?

We return all available eligibility and benefit information provided by the trading partner. If no deductible information is included, there may not be a deductible. In addition, some plans return $0 when there is no deductible.

Why am I getting unable_to_respond_now?

Trading partners may experience unscheduled downtimes. Please try again later or call the trading partner on the back of the member’s card for eligibility and benefit information. Check out our list of reject reasons in our documentation.

Pharmacy

PokitDok’s Pharmacy APIs allow the ability to dive into a member's prescription benefits with a pharmacy benefit plan number. PokitDok's 270/271 Eligibility API can be used to look up a member's plan number for Medicare Part C and D plans.

Claims Status graphic

The Pharmacy Plans API returns a member's pharmacy plan information such as plan name, premium, deductible, initial coverage limit and copays for each tier (initial coverage phase).

The Pharmacy Formulary API returns specific coverage such as tier level and restrictions including prior authorization, step therapy, and quantity limit, as well as details about a medication's out of pocket cost and average total cost including insurance reimbursement.

The In-Network Pharmacy API returns in-network pharmacies for a plan, or returns the details of a particular pharmacy (such as if it is in-network, if it is a retail pharmacy, etc).

What pharmacy benefit plans am I able to check?

Today, we have access to pharmacy benefit data for Medicare Part C and D members. People over 65 usually have one of these plans.

What about commercial pharmacy benefits?

The X12 270/271 medical eligibility request may return limited pharmacy benefits if available. Please contact us to see how we can help with commercial pharmacy benefits.

How do I find a member’s plan id to check pharmacy benefit information?

To use the Pharmacy Formulary Endpoint with a Medicare member, the plan number is required. This is the contract ID (ex. S1234) + Plan's Plan Benefit Package (PBP) Number PBP number (ex. 001) concatenated together - in that order. There are several ways to get this number. The plan number may be on the member’s insurance card. If not, an NCPDP E1 eligibility check or PokitDok’s Eligibility Endpoint can be used. With the Eligibility Endpoint, Medicare members with Part D coverage will have pharmacy.is_eligible set to true and the pharmacy.plan_number will contain their Medicare Part D plan_number. Note: A Medicare registered NPI is needed in order to check eligibility.

What is a formulary?

A formulary is a list of drugs covered under a plan, with details about the type of coverage. The word "formulary" may be used during a physician visit or when picking up a prescription.

What is a tier?

A tier is a level of coverage. If a patient has a three-tier plan, he or she has three levels of coverage. A five-tier plan has five levels. Tier 1 drugs are generic drugs, and cost less. Drugs that are in higher tiers, usually have a higher cost.

Identity Management

The PokitDok Identity Management (IdM) API allows for querying an EMPI (Enterprise Master Patient Index) and/or MPI (Master Patient Index), typical components of EMR or EHR systems, in order to find record identifiers and details in target systems. These Identity Management endpoints will identify, match, prove, and store each of the associated record identities in multiple target EMPIs. Additionally, the Identity Management API supports historical data loads for configurable duplicate entity detection.

IdM Graphic

Which settings are configurable when using the Identity Management API for duplicate entity detection?

There are three components of the API which can be adjusted to find the best set of matches across your historical data: the match algorithm, the search fields and the match weight. The different match algorithms can be set for exact or approximate string matching. The use of different source and search fields allows for the detection of transposition within an entity's values. Lastly, setting different match weights allows you to control the importance of any individual field level match.

What are the configurable options for fuzzy user search?

The Identity Management API also supports approximate string matching for individual user search. For the individual search fields, you can adjust the matching algorithm to be exact or approximate when retrieving users through the API.

What version of the identity is returned when there are multiple versions in the database?

We store a historical chain of the updates to a given consumer while also maintaining a single best record for the duration of the data record. When using the search API, we return the single best record. The Identity History endpoint returns a list of available snapshots to give you access specific historical records.

Authorizations

Authorization API requests are submitted in real-time. Once a request passes PokitDok validation, the request is sent to the trading partner. If request is valid, an acknowledgement response is returned in real-time (typically within a few seconds). An activity is created in our system at submission. We will return the activity id which can then be used with the Activities API.

AuthorizationsGraphic

Response times and methods can vary by trading partner. PokitDok transmits the requests to the carrier but cannot guarantee which trading partners will return a successful or electronic response. It is not uncommon for a trading partner to respond via phone, email or fax. For additional details please contact us.

How is it determined that a Prior Authorization is required?

Prior authorization is determined on a plan by plan basis per trading partner. Certain trading partners do not require prior authorization for any services while others do. This information is typically available in the providers section of the trading partner websites.

Is an Authorization transaction in real time?

Although some trading partners are set up to receive and return authorization requests and responses in real time, responses may be returned via batch mode at a later date or via phone, fax or email.

Will I always receive a trading partner response for an Authorization transaction?

Trading partners will often respond acknowledging receipt of Authorization electronically. However, final responses to the request may vary based on trading partner capability.

How long will it take to receive a response if my authorization request has been approved or denied?

Response time will vary based on trading partner. If additional information is needed to process the request, the trading partner will reach out via phone, fax or email to obtain this documentation.

Do all trading partners support electronic prior authorizations?

As with all X12 transactions, trading partner capabilities will vary. While some trading partners are able to accept and process 278 transactions electronically, not all will be able to support this functionality at this time. Review our trading partners list to see who we are currently connected with and contact us to inquire about additional trading partner connections.

Why am I getting a message indicating the trading partner is unable_to_respond_now?

Trading partners may experience scheduled or unscheduled downtime. Please try again later or call the number on the back of the member’s card for eligibility and benefit information. You can review the full list of reject reasons in our documentation.

Scheduling

The API for the PokitDok Enterprise Scheduler uses JavaScript Object Notation (JSON) for requests and responses. All API traffic is encrypted over HTTPS and authentication is handled with OAuth2, the open standard for authentication and authorization. This method puts providers and patients in full control of which applications can create and book appointments on their behalf. The API is designed according to Representational State Transfer (REST) principles and unlike on-site hardware installations, it resides in the cloud and does not require physical space to support or maintain.

Scheduling Graphic

Referrals

The Referrals API allows an application to request approval for a referral to another health care provider.

Primary Care Physicians can enable their patients to receive the consult and services of a specialist or specialist entity. This request will be sent to the reviewing entity (e.g. Utilization Management Organization) for approval.

Plans

The Plans API can check a customer's insurance carrier and see what their plan design is. This information is used in determining the benefits, copayments, or coinsurance a patient has.

Providers

Search for providers from one of the largest provider directories. Our directory provides biographical information, education, credentialing, and other quality and business information. Use this API to let customers select providers based on a variety of factors.

Cash Prices

Based on our proprietary database, this API calculates the average cash price providers charge for a specific service, within a certain geographic area. This is a good reference point for customers to use when selecting a provider for services or for selecting a geographic area to obtain those services.

Insurance Prices

Based on our proprietary database, this API calculates the average price for a service that providers are submitting to an insurance carrier within a specified area. This information can be used by customers to get an idea of how much they might save between a cash price and insurance price. It can also be used as a guide to select a geographic location for obtaining healthcare services.

Trading Partners

This is where you will find an always current list of the insurance carriers and health plans that are partnered with us to exchange information. It also provides details on what types of information we can exchange with each of these partners.

Activities

Keep track of your API usage through our Activities API. Data on your APIs help you drive and grow your business intelligently.

Have additional questions about our APIs? Contact Us