Attachments Submission v1

Summary API Attachments FAQ CHANGE LOG     

Overview

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:

    https://apigw.changehealthcare.com/medicalnetwork/attachments/submission/v1/uploads/

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.

Links to Attachments Submissions FAQ Topics

You'll find the following topics on this page:

Accessing the Attachments Submission APIs

What information needs to go in the API Request header?

What are the endpoints for getting authorization tokens?

How do I access the Production APIs?

Using the Sandbox environment

Do you have a sandbox that I can test before signing a contract?

How do I access the Sandbox environment?

Sandbox predefined fields and values

Using the Attachments Submission API

What does a typical API request look like?

What are the differences between Solicited and Unsolicited Attachments?

What does a successful Attachments response look like?

What response parameters can I expect to see in most error responses?

What types of errors will I typically see?

Understanding API Features

How can I check the status of my attachment submissions?

Trading Partners and Attachment Requirements

Where do the Control Numbers come from?

What are the JSON-to-EDI mappings for the Attachment Submission request?

How can I attach multiple files in one transaction?

How do I use the API to send a Fax to the payer?

How do I handle payer submissions when they don't support 275 transactions and don't accept faxes?

What information needs to go in the API request header?

The Attachments Submission API request header needs an authorization token. You can get the token by making an API call to:

curl -X POST \
  'https://sandbox.apis.changehealthcare.com/apip/auth/v2/token' \
  -H 'Content-Type: application/json' \
  -d '{
  "client_id": "<Your-ClientId>",
  "client_secret": "<Your-ClientSecret>",
  "grant_type": "client_credentials"
}

The authorization token is a requirement for making an API call, which will have the following headers:

Content-Type: application/json
Authorization: Bearer <Your-Access-Token>

What are the endpoints for getting authorization tokens?

  • The Production endpoint URL for authorization tokens is as follows:

    https://apigw.changehealthcare.com/apip/auth/v2/token/

In production, the lifespan of a token is two hours (7200 seconds). For Sandbox use, a token lifespan is one hour.

Find out more about our security protocols in the Security -> Authorization section of this portal.

How do I access the Production APIs?

  • The production endpoint for Attachments Submission is:

    https://apigw.changehealthcare.com/medicalnetwork/attachments/submission/v1/uploads

This API supports both Solicited and Unsolicited attachments. For fax support, see the section titled How do I handle payer submissions when they don't support 275 transactions and don't accept faxes?.

Using the Sandbox Environment

Do you have a sandbox that I can test before signing a contract?

We do! You can use our Sandbox environment even before signing a contract. It requires a separate set of secure credentials which you can obtain from your Change Healthcare representative. After receiving your client_id and client_secret for our Sandbox environment, you can test the API in our interactive documentation, use an application such as Postman, or test APIs using your own development console.

Try our Postman Collection! Run in Postman

How do I access the Sandbox environment?

  • The Sandbox endpoint URL for authorization tokens is as follows:

    https://sandbox.apigw.changehealthcare.com/apip/auth/v2/token/

    Authorization tokens have a lifespan of 3600 seconds (1 hour) in the Sandbox environment.

  • For testing, the Sandbox Attachments Submission API endpoint is as follows:

    https://sandbox.apigw.changehealthcare.com/medicalnetwork/attachments/v1/submission/uploads

Sandbox predefined fields and values

The following fields for Sandbox Attachment Submission requests must have one of the predefined Sandbox values listed below. The following fields must use one of the following predefined values.

Field Values
memberId "0000000000", "0000000001", "0000000002", "1234567890", "0000000004", "0000000005", "0000000006","0000000007", "123456789"
firstName "johnone", "johntwo", "janeone", "janetwo"
lastName "doeone", "doetwo"
middleName "middleone", "middletwo"
gender "m", "u", "f"
dateOfBirth "18800102", "18800101", "18160421", "19800101", "19800102", "20000101", "20000102"
ssn "000000000", "555443333", "1111111111", "000000001", "891234567", "123456789"
groupNumber "0000000000", "1111111111","1234567891","0000000001", "0000000002", "0000000003", "0000000004", "0000000005"
address1 "123 address1", "000 address1"
address2 "apt 123", "apt 000", "123", "000"
city "city1", "city2"
state "wa", "tn"
postalCode "981010000", "372030000"
employerId "00000", "12345","00001","00002","000000000", "123456789","123456"
propertyCasualtyClaimNumber "00000", "12345","00001","00002"
patientControlNumber "00000", "12345","00001","00002"
priorAuthorizationNumber "00000", "12345","00001","00002"
referralNumber "00000", "12345","00001","00002"
repricedClaimNumber "00000", "12345","00001","00002"
investigationalDeviceExemptionNumber "00000", "12345","00001","00002"
claimNumber "00000", "12345","00001","00002"
name "johnone doeone", "johntwo doetwo", "janeone doeone", "janetwo doetwo", "submitter contact info"
phoneNumber "0000000000", "123456789", "0000000001", "0000000002"
faxNumber "0000000000", "123456789", "0000000001", "0000000002"
email "email@email.com", "email@email.net"
stateLicenseNumber "0000000", "0000001", "123456"
contractVersionIdentifier "111111", "222222", "123456"
patientControlNumber "00000", "12345","00001","00002"
priorAuthorizationNumber "00000", "12345","00001","00002"
referralNumber "00000", "12345","00001","00002"
claimControlNumber "00000", "12345","00001","00002"
cliaNumber "12D4567890", "00D0000001"
repricedClaimNumber "00000", "12345","00001","00002"
mammographyCertificationNumber "00000", "12345","00001","00002"
medicalRecordNumber "00000", "12345","00001","00002"
demoProjectIdentifier "00000", "12345","00001","00002"
carePlanOversightNumber "00000", "12345","00001","00002"
policyNumber "00000", "12345","00001","00002"
npi "1760854442", "1942788757"
organizationName "happy doctors group", "happy doctors grouppractice","extra healthy insurance", "regional ppo network"

NOTE: TradingPartnerServiceId 9496 is a test payer and is the only payer allowed for use in Sandbox.

If you don't use Sandbox predefined values, you will get errors like the following:

{
    "traceId": null,
    "tradingPartnerId": null,
    "tradingPartnerServiceId": null,
    "status": null,
    "files": [],
    "errors": [
        {
            "field": "subscriber",
            "description": "Please use predefined users for non-prod environments: firstName was not predefined."
        }
    ]
}

Using the Attachments Submission APIs

What do typical Attachments API requests look like?

The API uses a POST HTTPS call. You provide the input as JSON in the body of the request. The following shows the contents of an Unsolicited attachment submission:

curl -X POST \
  https://<path>
  -H 'Accept: application/json' \
  -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW' \
  -F 'request={
  "controlNumber": "123459999",
  "tradingPartnerServiceId": "9496",
  "submitter": {
    "organizationName": "happy doctors grouppractice",
    "etin": "1942788757"
  },
  "provider": {
    "organizationName": "happy doctors group",
    "npi": "1760854442",
    "address": {
      "address1": "123 address1",
      "city": "city1",
      "state": "wa",
      "postalCode": "981010000"
    },
    "phoneNumber": "123456789",
    "faxNumber": "123456789"
  },
  "subscriber": {
    "memberId": "0000000001",
    "firstName": "johnone",
    "lastName": "doeone"
  },
  "claimInformation": {
    "patientControlNumber": "12345",
    "payerControlNumber": "00001",
    "beginClaimServiceDate": "20050514",
    "endClaimServiceDate": "20050515",
    "serviceLines": [{
      "providerAttachmentControlNumber": "123456789",
      "serviceLineDateInformation" : {
          "submissionDate" : "20050514"
      },
      "attachmentDetails": {
        "name": "rightarm.jpg"
      }
    }]
  }
}' \
  -F files=@~/images/attachments_rightarm.jpg

A submission for a Solicited Attachments transaction appears as follows:

{
  "controlNumber": "123459999",
  "tradingPartnerServiceId": "9496",
  "tradingPartnerName":"Happy Payers of Washington State",
  "payerAddress": {
      "address1": "123 address1",
      "city": "city1",
      "state": "wa",
      "postalCode": "981010000"
    },
  "submitter": {
    "organizationName": "happy doctors grouppractice",
    "etin": "1942788757"
  },
  "provider": {
    "organizationName": "happy doctors group",
    "npi": "1760854442",
    "address": {
      "address1": "123 address1",
      "city": "city1",
      "state": "wa",
      "postalCode": "981010000"
    },
    "phoneNumber": "123456789",
    "faxNumber": "123456789"
  },
  "subscriber": {
    "memberId": "0000000001",
    "firstName": "johnone",
    "lastName": "doeone"
  },
  "claimInformation": {
    "patientControlNumber": "12345",
    "payerControlNumber": "00001",
    "beginClaimServiceDate": "20050514",
    "endClaimServiceDate": "20050614",
    "serviceLines": [{
      "payerClaimControlNumber": "123456789",
      "serviceLineDateInformation" : {
          "submissionDate" : "20050514"
      },
      "attachmentDetails": {
        "name": "rightarm.jpg"
      }
    }]
  }
}

What are the differences between Solicited and Unsolicited Attachments?

The serviceLines JSON object contains the values that define the key difference in Solicited and Unsolicited attachment transactions. For any transaction, In JSON, the key values are:

For Unsolicited Attachments:

  • providerAttachmentControlNumber
  • payerAddress and its elements

You send Unsolicited attachments as part of the process of submitting 275 claim transactons which require attachments as standard documentation for the claim. Worker's Compensation claims are one good example among many. You use the providerAttachmentControlNumberas the control number value to the serviceLines JSON object. An example:

  {
    "serviceLines": [{
      "providerAttachmentControlNumber": "123456789"
  }

Unsolicited transactions may also contain the required payerAddress object, which has the payer's address information. It consists of the following:

  "tradingPartnerName":"Happy Payers of Washington State",
  "payerAddress": {
      "address1": "123 address1",
      "city": "city1",
      "state": "wa",
      "postalCode": "981010000"
    },

Use this address information as part of the request body when you need to mail the physical attachments to the payer. This may be necessary when the payer does not support either electronic attachment transactions or fax.

For Solicited Attachments:

  • payerClaimControlNumber
  • tradingPartnerName
  • payerAddress and its elements

You typically send Solicited attachments in response to a 277R transaction from a payer that is requesting additional documentation for a submitted claim. When you edit the request body, ensure that you have the payerClaimControlNumber as a unique value for each attachment, as the subordinate field to the serviceLines JSON object.

    "serviceLines": [{
      "payerClaimControlNumber": "123456789",
    }

Solicited attachment transactions also contain the required payerAddress object, which has the payer's address information. It consists of the following:

  "tradingPartnerName":"Happy Payers of Washington State",
  "payerAddress": {
      "address1": "123 address1",
      "city": "city1",
      "state": "wa",
      "postalCode": "981010000"
    },

The tradingPartnerName is also required in the JSON request body.

What does a successful Attachments response look like?

For a successful Solicited or Unsolicited transaction, you'll receive the following:

{
    "status": "success",
    "attachmentId": "c8f5fdc7-d71c-5cf8-f68c-2e87eff625bf_12B19_999898"
}

Your workflow for API consumers should retain this notification for every transaction they send. It contains a unique value called the traceId, which is a 128-bit UUID value that's generated and sent by the clearinghouse whenever it receives a new attachment transaction.

The traceId is a reference value should a user need to check the status of an attachment submission.

The acknowledgement appends the tradingPartnerServiceId (12B19 in this example, which is the payer ID), along with the submitterId (999898 in this example).

What response parameters can I expect to see in most error responses?

The vast majority of error messages you'll receive as a result of error events will return the following fields:

  • field (error.field)
  • description (error.description)

The following section offers some examples.

What types of errors will I typically see?

If you accidentally specify the wrong payer or a payer that doesn't support digital attachment capabilities, you'll see the following error:

{
    "status": "errors",
    "errors": [
        {
            "field": "tradingPartnerServiceId",
            "description": "trading partner not established for digital attachments, please provide a payerFaxNumber or payerAddress"
        }
    ]
}

The Attachments Submission API provides useful error information as responses when the request body contains mistakes or when something else in the process goes wrong. Except where noted, all errors described in this section apply to both Unsolicited and Solicited transactions.

When you forget to attach a file to the transaction:

{
    "status": "errors",
    "errors": [
        {
            "field": "files",
            "description": "File:  is size 0, please submit a valid file."
        }
    ]
}

When a Solicited attachments transaction is attempted but some payerAddress information is missing:

{
    "status": "errors",
    "errors": [
        {
            "field": "payerAddress.state",
            "description": "must not be blank"
        },
        {
            "field": "payerAddress.address1",
            "description": "must not be blank"
        },
        {
            "field": "payerAddress.city",
            "description": "must not be blank"
        }
    ]
}

You can receive one or more error instances depending on which fields are missing.

When the entire block of payerAddress information is missing:

{
    "status": "errors",
    "errors": [
        {
            "field": "tradingPartnerServiceId",
            "description": "trading partner not established for digital attachments, please provide a payerFaxNumber or payerAddress"
        }
    ]
}

When you have a typo in the controlNumber, or a missing digit in this value, you'll see the following error:

{
    "status": "errors",
    "errors": [
        {
            "field": "controlNumber",
            "description": "BAD_CONTROL_NUMBER, ControlNumber has to be 9 digits."
        }
    ]
}

If the controlNumber is missing entirely:

{
    "status": "errors",
    "errors": [
        {
            "field": "controlNumber",
            "description": "must not be blank"
        },
        {
            "field": "controlNumber",
            "description": "BAD_CONTROL_NUMBER, ControlNumber has to be 9 digits."
        }
    ]
}

At times, you may receive an error showing a rejection due to missing files in a Solicited transaction. These may appear in X12 EDI format. Such a message takes a form similar to the following:

{
    "status": "errors",
    "attachmentId": null,
    "errors": [
        {
            "field": "Segment: STC",
            "location": "Loop: 2000, Segment Position: 13",
            "description": "Required Segment Missing"
        }
    ],
    "transactionSetAcknowledgement" : "Rejected",
    "implementationTransactionSetSyntaxError" : "One or More Segments in Error"
}

Understanding API Features

How can I check the status of my attachment submissions?

Because our APIs don't support push notifications from the clearinghouse or the payer, API users will need to check on the status of attachment transactions that they've sent on behalf of the provider. To do so, use the Attachment Status API, which is closely tied to Attachment Submissions and offers a flexible RESTful query mechanism.

Trading Partners and Attachments Requirements

The active Trading Partners list, that is supported for electronic Solicited and Unsolicited attachments, consists of the following:

  • 3657: Workers Compensation Institutional
  • 5861: Workers Compensation Professional
  • 83867: QualLynx
  • 84146: CHAMPVA - HAC
  • 12115: VA Fee Basis Programs
  • LACAR: LA Care
  • 14163: WELLCARE HEALTH PLAN
  • PIPREPAY: Payment Integrity

For non-electronic payers, always use the actual Payer ID and Payer Name values. You can look up the complete list of Payer IDs and their names on the Change Healthcare Payer IDs page.

Fax Numbers and the API

Any tradingPartnerServiceId can be used to send a fax to the payer by setting payerFaxNumber on the request.

"payerFaxNumber": "fax number of the payer",

Any tradingPartnerServiceId can be used to send a physical mail to the payer by setting payerAddress on the request.

"payerAddress" : { "address1": "123 address1", "city": "city1", "state" : "wa", "postalCode": "981010000"},

Where do the Control Numbers come from?

The providers and, often, Payers originate the Control Numbers for transactions. Control Numbers must a nine-digit numeric value.

What are the JSON-to-EDI mappings for the Attachment Submission request?

NOTE: You can check the ***Medical Attachment Submission API Mapping*** document in the Attachments tab for the field-by-field listing of the sample payload described in this section.

The following JSON code block shows the direct relationship between JSON fields in an attachment request and the X12 EDI loop associated with each field in the 275 request:

{
  "controlNumber": "controlNumber",
  "tradingPartnerId": "tradingPartnerId",
  "tradingPartnerServiceId": "LOOP 1000A; NM109",
  "tradingPartnerName": "LOOP 1000A NM103",
  "payerFaxNumber": "fax number of the payer",
  "payerAddress": {
        "address1": "",
        "address2": "",
        "city": "",
        "state": "",
        "postalCode": ""
  },
  "submitter": 
    {
      "organizationName": "LOOP 1000B NM103",
      "firstName": "LOOP 1000B NM104",
      "lastName": "LOOP 1000B NM103",
      "etin": "LOOP 1000B NM109; "
    },
  "provider":
    {
      "organizationName": "LOOP 1000C NM103",
      "lastName": "LOOP 1000C NM103",
      "firstName": "LOOP 1000C NM104",
      "middleName": "LOOP 1000C NM105",
      "suffix": "LOOP 1000C NM107",
      "npi": "LOOP 1000C NM109",
      "taxonomyCode": "LOOP 1000C PRV03",
      "providerCommercialNumber": "Loops to 1000C; Maps to REF02; REF01=G2",
        "locationNumber": "Loops to 1000C; Maps to REF02; REF01=LU",
        "stateLicenseNumber": "Loops to 1000C; Maps to REF02; REF01=0B",
        "providerUpinNumber": "Loops to 1000C; Maps to REF02; REF01=1G",
      "address": 
         {
           "address1": "LOOP 1100C",
           "address2": "LOOP 1100C; maps N302",
           "city": "LOOP 1100C; N401",
           "state": "LOOP 1100C; N402",
           "postalCode": "LOOP 1100C; N403"
         },
      "phoneNumber": "Used in fax cover sheet",
      "faxNumber": "Used in fax cover sheet"
    },
  "subscriber": 
    {
      "memberId": "LOOP 1000D NM segment; NM108=MI",
      "firstName" : "LOOP 1000D NM segment; NM104",
      "lastName" : "LOOP 1000D NM segment; NM103"
    },
  "claimInformation":
    {
      "patientControlNumber": "LOOP 1000D REF=EJ segment",
      "billingTypeIdentifier": "LOOP 1000D REF=BLT",
      "medicalRecordIdentifier": "LOOP 1000D REF=EA",
      "claimNumber": "LOOP 1000D REF=D9",
      "beginClaimServiceDate": "LOOP 1000D DTP segment; DTP01=472; DTP02=RD8",
      "endClaimServiceDate": "LOOP 1000D DTP segment; DTP01=472; DTP02=RD8",
      "claimServiceDate": "LOOP 1000D DTP segment; DTP01=472; DTP02=D8",
      "serviceLines":[ //Note: for each serviceLine, we will add LX segment and keep incrementing LX01
      {
        "payerClaimControlNumber": "LOOP 2000A; TRNO1=2; Payer Claim Control Number is the value from the TRN segment loop 2200D of the 277 when in response to a solicited request",
        "providerAttachmentControlNumber" : "LOOP 2000A TRN01=1; For the unsolicited 275, the Attachment Control Number is the value from PWK06 loop 2300 of the 837. This is the main matching criteria and must be unique on a per attachment basis.",
        "claimStatus": [
          {
            "claimStatusCategoryCode": "LOOP 2000A; STC01-1",
            "additionalInformationRequestCode": "LOOP 2000A; STC01-2"
          }],
        "providerControlNumber": "LOOP 2000A; REF01=6R",
        "lineItemControlNumber": "LOOP 2000A; REF01=FJ",
        "procedureOrRevenueDetails": 
          {
            "procedureOrRevenueCode": "LOOP 2000A; REF01; valid values: CPT, F8, FO, PRT,RB, VP, YJ, ZZ",
            "procedureOrRevenueValue": "value of the code provided in REF01; this would be REF02",
            "revenueCode": "LOOP 2000A; REF04-02"
          },
        "procedureCodeModifier": 
          {
            "serviceChangeNumber": "LOOP 2000A; REF01=SK; REF02",
            "objectCode" : "LOOP 2000A; REF04-1=XX4; REF04-2",
            "systemNumber": "LOOP 2000A; REF04-3=06; REF04-4",
            "specialPaymentReferenceNumber": "LOOP 2000A; REF04-5=4N; REF04-6"
          },
        "serviceLineDateInformation": 
          {
            "serviceDate": "LOOP 2100A; DTP01=472; DTP03=value; DTP02=D8",
            "beginServiceDate": "LOOP 2100A; DTP01=472; DTP03=value ; DTP02=RD8",
            "endServiceDate": "LOOP 2100A; DTP01=472; DTP03=value ; DTP02=RD8",
            "submissionDate": "LOOP 2100B; DTP01=472; DTP03=value; DTP02=D8"
          },
        "attachmentDetails": 
          {
              "name": "Should match a file name sent with Form-Data files, Used to complete LOOP 2110B; BIN02 and LOOP 2110B; BIN01"
          }
      }
    ]
  }
}

How can I attach multiple files in one transaction?

Unsolicited and Solicited transactions use different approaches for attaching multiple files. Both transaction types support this feature.

You'll use the serviceLines object to contain two or more sub-objects in the JSON request body each representing an attachment file. Each attached document requires its own record as part of the transaction (you can't just list the filenames under attachmentDetails).

For Unsolicited Attachments transactions, each attachment must have a unique providerAttachmentControlNumber value. Here's an example:

    "serviceLines": [{
      "providerAttachmentControlNumber": "123456789",
      "serviceLineDateInformation" : {
          "submissionDate" : "20050514"
      },
      "attachmentDetails": {
        "name": "rightarm.jpg"
      }
    }
    {
      "providerAttachmentControlNumber": "123456788",
      "serviceLineDateInformation" : {
          "submissionDate" : "20050514"
      },
      "attachmentDetails": {
        "name": "rightscapula.jpg"
      }
    }]

For Solicited Attachments transactions, you use the payerClaimControlNumber in the JSON request body and use the same payerClaimControlNumber value in each document record:

    "serviceLines": [{
      "payerClaimControlNumber": "123412341",
      "serviceLineDateInformation" : {
          "submissionDate" : "20050514"
      },
      "attachmentDetails": {
        "name": "rightarm.jpg"
      }
    }
    {
      "payerClaimControlNumber": "123412341",
      "serviceLineDateInformation" : {
          "submissionDate" : "20050514"
      },
      "attachmentDetails": {
        "name": "rightscapula.jpg"
      }]
  }

How do I use the API to send a Fax to the payer?

The payerFaxNumber field is the payer fax number that you can use to send a digital fax to the payer. If payerfaxNumber is present and the trading partner is not set up for 275 transactions, a fax will be sent due to your request.

How do I handle payer submissions when they don't support 275 transactions and don't accept faxes?

When the trading partner is not set up for 275 transactions, and the payerFaxNumber is not present, it means that they don't support a fax. Mailing the attachment document is the only option. Print the document in the highest quality possible, and mail it to the payer if payerAddress information is present.

Change Log

API Name API Version Date Introduced Available Until
Attachments Submission v1 11/01/19 TBD

Release Notes

v1

  • Initial offering of attachments submission
  • 5/14/2020 Update: Adding statusList endpoint
  • 12/15/2020 Update: Medical Attachments Submission API Mapping document updated to cover `payerAddress` JSON field mappings to EDI
  • 03/08/2021 Update: new API Gateway URL for Attachment Submission API