---
tags: CDEX
title: Requesting and Sending Attachments
---
# Requesting and Sending Attachments

## Unsolicited Attachments

- 'unsolicited' Claims and Prior Authorization
- X12 275 Analog

### `$submit-attachment` Operation

digraph hierarchy {

                nodesep=1.0 // increases the separation between nodes

                node [color=Red,fontname=Courier,shape=box] //All nodes will this shape and colour
                edge [color=Blue, style=dashed] //All the lines look like this

                "Data Source (HIT)"->{"Data Consumer(Payer) is a 'black box: \n a system which can be viewed\n in terms of its inputs and outputs,\n without any knowledge of its\n internal workings."[style=filled, color=black, fontcolor=white,fontname=Courier,shape=box]}[ label=" Input: Parameters resource\n with an 'attachment' parameter for\n attachments represented natively\n as FHIR resources\nor b64 encoded non-FHIR resources\n wrapped in a Binary\n   or DocumentReference FHIR resource" ]}

[**Formal Views of OperationDefinition for `$sumbit-attachment`**](http://build.fhir.org/ig/HL7/davinci-ecdx/OperationDefinition-submit-attachment.html)


## Solicited Attachments

### non-FHIR Request

'solicited' Claims and Prior Authorization when the attachment request is not a FHIR Request (for example, an X12 277, 278 or Fax). Use the `$submit-attachment` Operation defined above.

Payer(Data Consumer)->HIT(Data Source): non-FHIR Attachment request
Note right of HIT(Data Source): HIT(Data Source)\ngathers information to submit
HIT(Data Source)->Payer(Data Consumer): POST $submit-attachment
Payer(Data Consumer)-->HIT(Data Source): Return HTTP 200 OK +/- OperationOutcome
note left of Payer(Data Consumer): 4) Payer associates data with existing or future\nclaim/prior authorization and processes

### FHIR Request

The 'solicited' Claims and Prior Authorization when the attachment request is a FHIR Request that is compliant with HIPAA Attachment rules for CMS and can replace the X12n 278response, 277 and 275 messages. ( Bob to edit ).

#### Request Attachment Using CDEX Task

The current CDEX design to transact "solicited" attachments using FHIR is mash up:

1. The CDEX Task Profile to Request the Attachments
1. $submit-attachment operation to Return the Attachments

##### Sequence Diagram

note left of Payer(Data Consumer): Prepare Task for attachments request\n(including $submit-attachment endpoint URL)
Payer(Data Consumer)->HIT(Data Source): POST CDEX Task 
Note right of HIT(Data Source): Gathers information to submit\nas $submit-attachment operation payload 
HIT(Data Source)->Payer(Data Consumer): POST $submit-attachment
Payer(Data Consumer)-->HIT(Data Source): Return HTTP 200 OK +/- OperationOutcome
Note right of HIT(Data Source): Updates Task as complete
Note left of Payer(Data Consumer): Associates submitted data\n with existing or future\nclaim/prior authorization and processes

##### Data Elements Needed to Request Attachments

It has been determined that these X12 + other elements are need to request attachments:

No.|X12 277/278 ID|Name
---|---|---
2 | NM108 | Payer ID - should be a business ID -requester.reference
3 | | Payer URL
4 | | Claim/PreAuth ID (Provider or Payer Assigned)
5 | REF02 | Tracking ID (Provider or Payer Assigned)
5| | line item # nos
7 | STC01-02 | LOINCs
8| DPT02 | Due Date
9| DTP03 | Date of Service (encounter info)
10 | X2100D NM | Member ID (patient info)
11 | X2100D NM103-7 | Patient Name (patient info)
12 | CLM01(837) | Patient Account No. *PreAuth Only* (patient info)
13 | X12 | DOB *Optional* (patient info )

##### The CDEX Attachment Request Profile

The CDEX Attachment Request Profile is a specialization of the CDEX Task Profile for requesting attachments. The CDEX Task Profile is used communicate the request for a variety of use cases including requesting attachments, but The CDEX Attachment Request is defined specifically for requesting attachments for Claims and Prior Authorization that is compatible with existing X12n 277 and 278 response transactions. In the following sections, An example CDEX Attachment Request is looked at in detail to document how this profile is used to communicate the required data elements and how they are used in $submit-attachment response back to the payer.

[**Formal Views of The CDEX Attachment Request Profile Content Design 1 (contained Claim)**](http://build.fhir.org/ig/HL7/davinci-ecdx/StructureDefinition-cdex-task-attachment-request.html)

[**Formal Views of The CDEX Attachment Request Profile Content Design 2(reasonCode and Service-date input)**](http://build.fhir.org/ig/HL7/davinci-ecdx/StructureDefinition-cdex-task-attachment-request2.html)

### Example Attachment Request

In the following example, The Provider creates a claim and sends to the Payer. The Payer responds with request for attachments using the The CDEX Attachment Request Profile. This replaces the X12n 277 transactions. In addition to the various identifiers needed to associate the attachments to the claim, the payer supplies details about what information is need to complete the adjudication of the claim:

- LOINC code(s) for the requested attachment
- What line numbers on the claim the requested attachment(s) are for

They payer also indicates:

- whether a Digital Signature is required
- the endpoint where the Provider should submit the attachments to

After receiving the attachment request, the Provider A collects the documentation and returns them using the `$submit-attachment operation` which replaces the X12n 275 transaction.

The flow diagram for this transaction is shown in the figure below:

#### CDex Request Attachment Overview for a Claim

st=>start: Provider files claim for services
documenting what was done and the cost
(this is an X12n 837 message)
op3=>operation: Payer reviews claim and all the documents
e=>end: Payer processes claim
op5=>operation: Payer requests attachments
(e.g.,more information)
from the Provider using the 
CDex Task Attachment Request Profile
(this replaces the X12n 277 message)
op6=>operation: Provider submits requested attachments
from the Provider using the 
CDex $submit-attachments operation
(this replaces the X12n 275 message)
op7=>operation: Payer associates submitted attachments
with the claim and reviews claim
and all the documents
cond1=>condition: Claim and 
documentation
Complete?


st->op3->cond1
cond1(yes)->e
cond1(no)->op5->op6->op7(right)->op3

#### Step 1: POST a CDEX Attachment Request to the Provider Endpoint

~~~
POST [base]/Task
~~~

##### Request Body

<!-- The request body's various elements are annotated to show how each of the data elements is communicated to the Provider. -->

###### Declaring the Profile and Work Queue Hints

The Provider receives the Attachments request. The profile declaration asserts that the resource conforms to the profile and contains all the necessary data elements listed above. Work Queue Hints are and optional element are displayed here to show how they can be used by a Payer in a claims attachment request.

~~~json
1: {
2: "resourceType": "Task",
3: "meta": {
4: "profile": [
5: "http://hl7.org/fhir/us/davinci-cdex/StructureDefinition/cdex-task-attachment-request2"
6: ],
7: "tag": [
8: {
9: "system": "http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp",
10: "code": "claims-processing"
11: }
12: ]
13: },
~~~

###### Verifying Patient Identity

The following data elements are used to verify patient identity for compliance regulations (such as HIPAA). (How the Provider system verify the patient in not covered in this guide.) The Payer communicates them in a `contained` Patient resource using the [**CDex Patient Demographics Profile**](http://build.fhir.org/ig/HL7/davinci-ecdx/StructureDefinition-cdex-patient-demographics.html). This contained Patient is referenced in `Task.for.reference` using the a fixed reference value of "#patient".:

|Data|HRex Patient Demographics Profile.|
|---|---|
|Member ID or Patient Account No.|`Patient.identifier`|
|Patient Name|`Patient.name`|
|Patient DOB (optional)|`Patient.birthDate`|
|Sex |`Patient.gender`|

~~~json
14: "contained": [
15: {
16: "resourceType": "Patient",
17: "id": "patient",
18: "meta": {
19: "profile": [
20: "http://hl7.org/fhir/us/davinci-cdex/StructureDefinition/cdex-patient-demographics"
21: ]
22: },
23: "identifier": [
24: {
25: "use": "usual",
26: "type": {
27: "coding": [
28: {
29: "system": "http://hl7.org/fhir/us/davinci-hrex/CodeSystem/hrex-temp",
30: "code": "UMB",
31: "display": "Member Number"
32: }
33: ],
34: "text": "Member Number"
35: },
36: "system": "http://example.org/cdex/payer/member-ids",
37: "value": "Member123"
38: },
39: {
40: "use": "usual",
41: "type": {
42: "coding": [
43: {
44: "system": "http://hl7.org/fhir/us/carin-bb/CodeSystem/C4BBIdentifierType",
45: "code": "pat",
46: "display": "Patient Account Number"
47: }
48: ],
49: "text": "Patient Account Number"
50: },
51: "system": "http://example.org/cdex/provider/patient-ids",
52: "value": "PA-123"
53: }
54: ],
55: "name": [
56: {
57: "family": "Shaw",
58: "given": [
59: "Amy"
60: ]
61: }
62: ],
63: "gender": "female",
64: "birthDate": "1987-02-20"
65: }
66: ],
~~~

<!-- ##### Supplying the Claim/PreAuthorization Data

The Payer supplies the necessary Claim/PreAuthorization Data so the Provider can locate the claim. The data is communicated in a `contained` Claim resource using the [**CDex Claim Profile**](http://build.fhir.org/ig/HL7/davinci-ecdx/StructureDefinition-cdex-claim.html). This contained Claim is referenced in `Task.reasonReference.reference` using the a fixed reference value of "#claim". In addition to required (min=1) elements inherited from the FHIR Base resource, these elements are required:

|Data|CDex Claim Profile element|
|---|---|
|claim/pre-auth id|`Claim.identifer`|
|claim or preauthorization|`Claim.use`|
|date of service|`Claim.supportingInfo.timing[x]`|
|patient member id or patient account no|`Claim.patient.identifier` (note: this is the same value as `Task.for.identifier`)|
|provider id|`Claim.provider.identifier` (note: this is the same value as `Task.owner.identifier`)| -->

###### Supplying the Tracking ID

The mandatory `Task.identifier` "tracking-id" slice element represents the payers tracking identifier. This is an identifier that ties the attachments back to the claim or pre-auth and is echoed back to the Payer when submitting the attachments. It is often referred to as the “re-association tracking control number”.

~~~json
67: "identifier": [
68: {
69: "type": {
70: "coding": [
71: {
72: "system": "http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp",
73: "code": "tracking-id",
74: "display": "Tracking Id"
75: }
76: ],
77: "text": "Re-Association Tracking Control Number"
78: },
79: "system": "http://example.org/payer",
80: "value": "trackingid123"
81: }
82: ],
~~~

###### Task *Infrastructure* Elements

These required Task *infrastructural* elements:

- Task.status
- Task.intent
- Task.code

convey what the task is about, its status and the intent of the request. The values shown below are typical for the attachment request. Note that the status will change as the Task at is moves through [different states](http://hl7.org/fhir/task.html#statemachine) in the workflow.

~~~json
83: "status": "requested",
84: "intent": "order",
85: "code": {
86: "coding": [
87: {
88: "system": "http://hl7.org/fhir/us/davinci-hrex/CodeSystem/hrex-temp",
89: "code": "data-request"
90: }
91: ],
92: "text": "Data Request"
93: },
~~~

###### Identifying the Payer, Provider and Patient

Business idenfiers are used to identify the Payer, Patient and if present the Provider ID which is an optional element in the profile. Note that the Patient identifier is in both Task profile and the contained Patient profile. These IDs are echoed back to the Payer when submitting the attachments. (note the various Task dates as well)

|Actor|CDex Claim Profile element|
|---|---|
|payer ID|`Task.reasonReference.identifier`|
|provider ID (optional)|`Task.owner.identifier`|
|patient member ID or patient account no|`Task.for.identifier` and/or`Task.for.reference`|

~~~json
94: "for": {
95: "reference": "#patient",
96: "identifier": {
97: "system": "http://example.org/cdex/payer/member-ids",
98: "value": "Member123"
99: }
100: },
101: "authoredOn": "2022-06-17T16:16:06Z",
102: "lastModified": "2022-06-17T16:16:06Z",
103: "requester": {
104: "identifier": {
105: "system": "http://example.org/cdex/payer/payer-ids",
106: "value": "Payer123"
107: }
108: },
109: "owner": {
110: "identifier": {
111: "system": "http://hl7.org/fhir/sid/us-npi",
112: "value": "9941339108"
113: }
114: },
~~~

##### Claim Information

The Task communicates whether the attachments are for a Claim or Prior Authorization and the Claim or Prior Authorization ID is identified by its business Identifier.

|Data|CDex Claim Profile element|
|---|---|
|Claim or Prior Authorization|`Task.reasonCode`|
|Claim or Prior Authorization ID|`Task.reasonReference.identifier`|

~~~json
115: "reasonCode": {
116: "coding": [
117: {
118: "system": "http://hl7.org/fhir/claim-use",
119: "code": "claim",
120: "display": "Claim"
121: }
122: ],
123: "text": "claim"
124: },
125: "reasonReference": {
126: "identifier": {
127: "system": "http://example.org/cdex/payer/claim-ids",
128: "value": "Claim123"
129: }
130: },
~~~

##### Communicating Attachments Due Date

The Due Date for attachment is communicated in the `Task.restriction.period` element. Note that `Task.restriction.period.end` is the due date representing the time by which the attachments should be submitted.

~~~json
131: "restriction": {
132: "period": {
133: "end": "2022-06-21"
134: }
135: },
~~~

##### Communicating What Attachments are Needed

The payer supplies either LOINCs or non-coded data a Task input parameters to indicate what attachments are needed. Line item numbers may also be supplied to match the attachment to a line item in the claim or pre-auth. This information is represented in the `Task.input` "code" or "query" slices. Note that free text requests use the "code" slice and FHIR search based syntax the "query" slice. The code snippet below shows a single request for line item 1 using a LOINC attachment code. The codes and line items are echoed back to the Payer when submitting the attachments.

~~~json
136: "input": [
137: {
138: "type": {
139: "coding": [
140: {
141: "system": "http://hl7.org/fhir/us/davinci-hrex/CodeSystem/hrex-temp",
142: "code": "data-code"
143: }
144: ]
145: },
146: "valueCodeableConcept": {
147: "coding": [
148: {
149: "system": "http://loinc.org",
150: "code": "34117-2",
151: "display": "History and physical note"
152: }
153: ],
154: "text": "History and Physical"
155: },
156: "extension": [
157: {
158: "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-serviceLineNumber",
159: "valuePositiveInt": 1
160: }
161: ]
162: },
~~~

###### Communicating the Signature Requirements

See the [Signature page](#) for more information

~~~json
163: {
164: "type": {
165: "coding": [
166: {
167: "system": "http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp",
168: "code": "signature-flag"
169: }
170: ]
171: },
172: "valueBoolean": true
173: },
~~~

###### Indicating the $submit-attachment Operation Endpoint

When the Payer supplies the url endpoint as a Task input parameter, it triggers the Provider System to use it as the endpoint for the $submit-attachment Operation defined above. If no url endpoint is supplied the attachments are provided either as references or contained Task resource and the requester needs to poll/subscribe to the Task to retrieve when done.

~~~json
174: {
175: "type": {
176: "coding": [
177: {
178: "system": "http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp",
179: "code": "payer-url"
180: }
181: ]
182: },
183: "valueUrl": "http://example.org/cdex/payer/$submit-attachment"
184: },
~~~

###### Date of Service for the Claim

A Task.input element represents the date of service or starting date of the service for the claim or prior authorization.

~~~json
185: {
186: "type": {
187: "coding": [
188: {
189: "system": "http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp",
190: "code": "service-date"
191: }
192: ]
193: },
194: "valueDate": "2022-06-13"
195: }
196: ]
197: }
~~~

#### Step 2 - Submit Solicited Attachments to Payer endpoint

As stated above, the Payer endpoint is communicated to the Payer using the Task.input element. This endpoint is the target for the $submit-attachment operation when the provider sends the requested attachment to the payer. The following table maps the information communicated in the CDex Attachment Request to the corresponding parameter in the body of $submit-attachment operation:

|foo|bar|baz|biz|
|---|---|---|---|
|foo|bar|baz|biz|

These parameters are documented in more detail below.

**Request**

~~~
POST [base]/$submit-attachment
~~~

**Request Body**

##### Use the `$submit-attachment` Operation Defined Above

The attachments along with the metadata needed to associate the attachment to the Claim or Pre-Auth are in the $submit-attachments payload, a Parameters resource.

~~~yaml=
resourceType: Parameters
parameter:
~~~

##### Echoing back the Tracking ID and whether is a claim or preaut
These data elements are taken from `Task.identifier` "tracking-id" slice and contained `Claim.use` elements respectively.

~~~yaml=+
- name: TrackingId
valueString: targetid123
- name: AttachTo
valueCode: claim
~~~

##### Supplying the Payer, Provider, Organization and Patient ids

The Payer and Patient IDs should be the same as communicated in the request. See above for details. For the Provider and Organization IDs the NPI should be used if not supplied in the request.

~~~yaml=+
- name: PayerId
valueIdentifier:
system: 'http://example.org/cdex/payer-ids'
value: payer123
- name: OrganizationId
valueIdentifier:
system: 'http://hl7.org/fhir/sid/us-npi'
value: '1407071236'
- name: ProviderId
valueIdentifier:
system: 'http://hl7.org/fhir/sid/us-npi'
value: '9941339108'
- name: MemberId
valueIdentifier:
system: 'http://example.org/cdex/member-ids'
value: '234567'
~~~

##### Echo back the Service date

The service date taken from the contained `Claim.supportingInfo.timingDate` element in the CDEX Attachment request.

~~~yaml=+
- serviceDate: '2022-06-16'
~~~

##### Supply the Requested Attachments for Each Line Item and Code

the Requested Attachments and the corresponding coded or non-coded requests and/or line item numbers are communicated back as Attachment parameter parts. The actual attachment is communicated as a FHIR resource in the Attachment.content parameter part, often a DocumentReference containing Base64 encoded FHIR and non-FHIR documents. What attachments are returned are determined by the CDEX Attachment requests in `Task.input` "code" or "query" slices. These may be coded in LOINC or non-LOINC, free text, or FHIR RESTful search syntax queries. Codes are represented in the Attachment.code parameter part in the `valueCodeableConcept.Coding` field and free text or FHIR RESTful search syntax queries are represented in `valueCodeableConcept.text` field. Line item numbers associated with a requested item are communicated in the Attachment.LineItem parameter part.

~~~yaml=+
- name: Attachment
part:
- name: LineItem
valueString: '1'
- name: Code
valueCodeableConcept:
- coding:
system: 'http://loinc.org'
code: 34117-2
- name: Content
resource:
- resourceType: DocumentReference
id: cdex-example-doc1
status: current
type:
coding:
- system: 'http://loinc.org'
code: 34117-2
display: History and physical note
text: History and Physical
category:
- coding:
- system: >-
http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category
code: clinical-note
display: Clinical Note
text: Clinical Note 1
date: '2021-12-03T18:30:56-08:00'
content:
- attachment:
contentType: application/pdf
data: '>>>>>>Base64 here<<<<<<'
title: sample1.pdf
~~~

**Full example Task request in JSON:**

{%gist Healthedata1/9bc715de1ebab524a95b4c679e5894fe%}

**Full example Response in JSON ($submit-attachment Parameters Payload):**

{%gist Healthedata1/ff729585f6d369e821d90854813c9b97%}