---
tags: CDEX
title: Unsolicited Claims Attachment Example
---

# Unsolicited Claims Attachment Example

## Example Use case:

source: [Guidance on Implementation of Standard Electronic Attachments for Healthcare Transactions November 2017](https://confluence.hl7.org/download/attachments/5998218/ACP%20Attachment%20White%20Paper.pdf?version=1&modificationDate=1516719257383&api=v2)

>Notification Unsolicited Event Level
A provider wants to notify the payer of a future elective inpatient admission. Based on previous encounters with a specific payer, a review of the patient’s medical records will be needed before the admission can be preauthorized. In this instance the provider will be sending both a Notification using the ASC X12N 278 (Health Care Services Review — Notification and Acknowledgment) and an ASC X12N 275 (Additional Information to Support a Health Care Services Review). The payer receives the notification for the elective admission and determines that a “Treatment Plan” has already been sent electronically as reported in the PWK. This information will be captured to assist with the ongoing utilization review process. The ASC X12N 278 Health Care Services Review - Notification and Acknowledgment will be returned to indicate that the notification was received and processed.



>The Attachment Control Number (PWK06 =1234567) is assigned by the provider which will also be reported in the X12N 275 submission.
In addition, the PWK segment is reporting that a “Plan of Treatment” (PWK01= ‘08’) was sent electronically (PWK02 = ‘EL’) to assist with the Utilization Review process.

#### Sequence Diagram

@startuml
 
Participant Provider
Participant Payer


    Provider-->Provider: 1. Create Parameter Payload
    Provider->Payer: 2. POST $unsolicited-submit Operation 
    alt Accept
    Payer-->Provider: Http response 202
    else Reject due to invalid payload content or Payer does not support operation
    Payer-->Provider: Http 400 Bad Request +/- OperationOutcome
    else Reject due to invalid or absent authorization
    Payer-->Provider: Http 401 Unauthorized +/- OperationOutcome
    else Reject due to insufficient scopes 
    Payer-->Provider: Http 403 Forbidded +/- OperationOutcome 
 
    end
  
@enduml

### Scenario: Unsolicited Claims Attachment Example

#### Preconditions and Assumptions:

- Based on a set of pre-defined rules set by the Payer, Provider can submit additional information for certain claims as Unsolicited Attachments
- Provider A knows the Payer endpoint for Sending attachments. The `$attachment` operation operation can be used by any HTTP end-point, not just FHIR RESTful servers.
- Unsolicited Claim implies that the *Provider* assigns the claim and line item identifiers (in other words, a "placer identifier") upon claim generation.
- Reassociation of attachments to the Claim, subsequent Claim processing and ajudication, and follow up communication are out of scope and out of band.

The Provider creates a claim and sends supporting CCDA document using the FHIR operation, `$attachment`:

`POST [base]/$attachment`

**Request**

~~~
POST ~/Claim/$unsolicited-claim

{
"resourceType": "Parameters",
"id": "unsolicited-submit-example1",
"parameter": [
{
"name": "AttachmentControlNumber",
"valueString": "1234567"
},
{
"name": "X12Claim",
"resource": {
"resourceType": "DocumentReference"
// X12 claim as binary file or url
}
},
{
"name": "Attachment",
"resource": {
"resourceType": "DocumentReference"
// Plan of Treatment CCDA sent as a binary or url
}
}
]
}
~~~
**Response:**
~~~
HTTP/1.1 202 Accepted
~~~

#### Example 2: The provider sends the Claim as FHIR Claim resource and supporting CCDA document using a FHIR operation

Request:

~~~
POST ~/Claim/$unsolicited-claim

{
"resourceType": "Parameters",
"id": "unsolicited-submit-example1",
"parameter": [
{
"name": "AttachmentControlNumber",
"valueString": "1234567"
},
{
"name": "FHIRClaim",
"resource": {
"resourceType": "Claim"
// claim as Claim Resource
}
},
{
"name": "Attachment",
"resource": {
"resourceType": "DocumentReference"
// Plan of Treatment CCDA sent as a binary or url
}
}
]
}
~~~
Response:
~~~
HTTP/1.1 202 Accepted
~~~

#### Example 2: The provider sends the Claim as FHIR Claim resource and supporting document as CCDA on FHIR Document using a FHIR operation

Request:

~~~
POST ~/Claim/$unsolicited-claim

{
"resourceType": "Parameters",
"id": "unsolicited-submit-example1",
"parameter": [
{
"name": "AttachmentControlNumber",
"valueString": "1234567"
},
{
"name": "FHIRClaim",
"resource": {
"resourceType": "Claim"
// claim as Claim Resource
}
},
{
"name": "Attachment",
"resource": {
"resourceType": "Bundle"
// Plan of Treatment CCDA sent as a FHIR Document
}
}
]
}
~~~
Response:
~~~
HTTP/1.1 202 Accepted
~~~

#### OperationDefinition Definition
Rendered output [ArgonautPatientListProfile](https://healthedata1.github.io/Sushi-Sandbox/OperationDefinition-unsolicited-claim.html)

<iframe src="https://healthedata1.github.io/Sushi-Sandbox/OperationDefinition-unsolicited-claim.html" width="100%" height="500">
</iframe>