Medical Network Attachments Submission v1

  Open Developer Docs     Request a Quote


For a longer discussion of Attachments in electronic data interchange and their use in our APIs, see this page.

The Attachments Submission API supports the X12 EDI 275 Patient Information transaction. It translates this standard to JSON, so it is more accessible to developers for integration into users’ applications.

Attachments submissions take two forms: Solicited and Unsolicited. As an example of an unsolicited attachment, consider workman's compensation claims. Attachments illustrating the conditions giving rise to the claim are required in all worker's compensation claims, hence they called unsolicited claims. Solicited claims usually are sent by payers to providers requesting documentation for a claim.

An attachment, in the context of healthcare electronic data interchange (EDI), is an electronic rendition of medical documentation, such as an X-ray, lab report, or questionnaire, to support a healthcare administrative transaction.

Change Healthcare supports the following formats for 275 attachments: JPG, BMP, GIF, TIF, TIFF, PDF, DOC, DOCX, TXT, RTF, JPEG, and PNG.

Change Healthcare’s attachment solution includes workers’ compensation attachments and medical attachments. Any receiver who does not support electronic attachments will receive the documentation via fax or mail.

API Onboarding

Most of our APIs are private and require credentials to gain access. Begin by obtaining your client_id and client_secret for our sandbox test environment. (Contact your Change Healthcare representative if you do not have this information.)

Find out more about our security protocols and their implementation.

NOTE: You use a separate Change Healthcare-issued credential pair for your production API work.

You can test the APIs from within our interactive documentation, use an application such as Postman, or use your own development platform. You use a separate Change Healthcare-issued secret pair for your production API work.

Try our Postman Collection! Run in Postman

The goal for onboarding is to ensure API customers can automate their API consumption process. For end use, API consumption shouldn't require 'seeing' the APIs; preferably, a number of tasks can be automated:

  • API bearer token automation, using OAuth2 token retrieval.
  • A data entry console to make claims requests and eligibility requests. It's a characteristic feature of medical facilities where public medical encounters take place.
  • Abstraction of the majority of complex data that's required for a successful request, so you can easily make requests and get replies efficiently without confusion. For example, Control Numbers exist in all of our APIs as a required value that's generated, assigned and sent by the provider or institution to identify each transaction. When the provider's office sends a request, they should never have to worry about defining and entering those values, and they should be handled programmatically.
  • Auditing and tracking for all transactions.

For token automation, you can apply one of the following:

  • Get a unique token for each transaction.
  • Apply the same token across all transactions in the full token lifespan (tokens for production APIs have a two-hour/7200 second lifespan) and automatically refresh the token just before it expires.

NOTE: We suggest automating token generation over the token lifespan, or close to it, instead of tokenizing each individual transaction.

API Endpoints

Endpoints for the Attachment Submissions APIs are as follows.

  • The primary Attachment Submissions endpoint:

This endpoint supports Unsolicited, Solicited and Fax transactions.

Using the API

In our interactive documentation, select the API tab, and select the green POST API object. Scroll down to the Authorization field, enter the word Bearer, and paste your token into the Bearer Token field.

Many of our API collections also provide a GET /healthcheck call to check that the service you're trying to use is up and running.

For Sandbox API testing, you can also edit the request body. We provide a set of predefined values that you can apply to see how the API works with key claim data, and predefined values to simulate Personal Medical Information (PMI) in the Sandbox environment. For successful use of Sandbox APIs, you must use these "fake patient" values for your testing. Check the FAQ tab -> Sandbox predefined fields and values section for details. Avoid using real-world values in our Sandbox API endpoints!

For details on the Attachments request model, see the FAQ tab. Topics document the field names and examples for the API requests, error messages and how to define both Unsolicited and Solicited transactions.