Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

BlueButton2 - please refer to CARIN Blue Button Track


Scenario 1


Clinical Data Exchange (CDex):

...

HCSC, ANTHEM INC., BCBSAL, BCBSTN, NGS, Palmetto GBA

WPS Health Solutions, Availity, Cambia, HSPC

...

Serves as an intermediary/aggregator between multiple parties (usually payers and providers), and thus needs to play both submitter and processor roles. The clearinghouse will need to change the sender/receiver information in the Communication and CommunicationRequest resources appropriately (i.e. when forwarding a request from a Payer to a Provider, the sender should be changed from the Payer to the Organization resource for the clearinghouse.

Basic Scenarios

Solicited

Action: Payor sends an attachment request to the provider. Onus is on the payer to create the staple between the request and the attachment. Provider must return the payer's electronic staple (i.e. ID) with the attachment.Here is an example of a request for an attachment from a payer:

a. http://hl7.org/fhir/communicationrequest-example-fm-solicit-attachment.xml.html

Here is an example of a solicited attachment from a provider (the payload would point to the PDF, C-CDA, or

Precondition: None

Success Criteria: Provider receives the request, responds with the attachment, payer receives the attachment and is able to view it in their system.Bonus point: Send to an adjudication engine in the Financial track.

Basic script for payer:

  • Step 1: Payer crafts a communication request (example "a" above).
  • Step 2: Provider uses the content of the request to craft a communication resource as the response (example "b" above)
  • Step 3: Provider creates an attachment (PDF, CDA, C-CDA on FHIR

...

  • )

...

b. http://hl7.org/fhir/communication-example-fm-solicited-attachment.xml.html

Precondition: None

...

  • Step 4: Provider POSTs the Communication resource and attachment to FHIR server.
  • Step 5: Payer GETs the Communication resource and attachment and manually verifies the content matches the request.

Basic script for payerprovider:

  • Step 1: Payer crafts Assume payer has sent provider a communication request ( example: "a" above).
  • Step 2: Provider uses the content of the request to craft a communication resource as the response ( example: "b" above)
  • Step 3: Provider creates an attachment (PDF, CDA, C-CDA on FHIR)
  • Step 4: Provider POSTs the Communication resource and attachment to FHIR server.
  • Step 5: Payer GETs the Communication resource and attachment and manually verifies the content matches the request.

Basic script for provider:

  • Step 1: Assume payer has sent provider a communication request example: "a"
  • Step 2: Provider uses the content of the request to craft a communication resource as the response example: "b"
  • Step 3: Provider creates an attachment (PDF, CDA, C-CDA on FHIR)
  • Step 4: Provider POSTs the Communication resource and attachment to FHIR server.
  • Step 5: Payer GETs the Communication resource and attachment and manually verifies the content.

Unsolicited

Action: Provider sends an attachment to the payer in support of a claim without a request. Onus on the provider to create the electronic staple (i.e. matching IDs) between the claim and the attachment. Here is an example of a Communication resource for an unsolicited attachment from a provider (the payload would point to the PDF, C-CDA, or C-CDA on FHIR attachment):

http://hl7.org/fhir/communication-example-fm-attachment.xml.html

Precondition: Prior agreement in place between payer and provider.Success Criteria: Payer receives the attachment and is able to view it in their system.Bonus point: Send to an adjudication engine in the Financial track.

Prior Authorization Support

TestScript(s)

Indicate any test scripts that will be used to help verify system behavior

Security and Privacy Considerations

...

Unsolicited

Action: Provider sends an attachment to the payer in support of a claim without a request. Onus on the provider to create the electronic staple (i.e. matching IDs) between the claim and the attachment