It can receive and return client data in either X12-278 or JSON over HTTPS. We’ll return the data in the same format the client used to send the transaction.
Our system is connected to EDI/direct payers and a wide range of web portal payers. The API is also responsible for payer-specific requests and request transformation.
We’re connected to all major UM vendors for radiology services in addition to most of the major medical connections.
We’ll return a variety of 278 certification action codes that represent the payer’s authorization status, which users can then interpret to understand the status. These codes represent common statuses, such as approved, partially approved, pending and denied, plus other error messages.
A: Our team can create an account for you to test the API in our sandbox. We have a few pre-written responses, that are not from payers, so you can see how the responses appear.
A: You’ll need to send the data according to our API contract and handle the responding data. Our implementation team will need to work with your client to map their payer IDs to our system's payer ID.
A: No, the Inquiry API checks synchronously upon a request. It’s in the 2025 roadmap to automatically check the status daily until the authorization date of service, or until the authorization has reached its terminal status (approved, denied).
A: The standard Institutional Claims API uses a separate set of rules and logic for scrubbing an institutional claim, and is automatically applicable across a range of institutional specialties. The Integrated Rules Institutional API provides greater specialization through the selection of Knowledge Packs to support your provider's medical specialties. It can be considered complementary to the standard Institutional Claims API.