This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201609 Attachments"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
  
[[Category:201609_FHIR_Connectathon_Track_Proposals|May 2016 Proposals]]
+
[[Category:201609_FHIR_Connectathon_Track_Proposals|September 2016 Proposals]]
 
__NOTOC__
 
__NOTOC__
 
=Attachments=
 
=Attachments=

Revision as of 17:10, 17 June 2016


Attachments

Submitting WG/Project/Implementer Group

Attachments Work Group (AWG)

Justification

Electronic attachments are a high priority for processing claims and other payer/provider interactions. Current thinking has attachment submissions occurring via X12 messaging. However, there is substantial interest in experimenting with FHIR-based messaging for exchanging attachments. This track will explore the feasibility of this approach.

Proposed Track Lead

See Connectathon_Track_Lead_Responsibilities

  • Rick Geimer
    • Email: rick dot geimer at lantanagroup dot com
    • Skype: rgeimer
    • Co-leads, Paul Knapp, Durwin Day

Expected participants

  • BCBS
  • HCSC
  • BCBSAL
  • Anthem
  • Optum

Roles

Please include information here regarding how much advance preparation will be required if creating a client and/or server.

Payer

Provider

Scenarios

For all scenarios below, the following types of attachments are allowed:

  • PDF attachment
  • Unstructured C-CDA attachment
  • Structured C-CDA attachment
  • C-CDA on FHIR attachment

Prior Authorization

Action: Provider creates an attachment and sends it to the payer.
Precondition: Prior authorization has occurred, and the provider has an id (i.e. electronic staple) to associate the attachment with the claim.
Success Criteria: Payer receives the attachment and is able to view it.
Bonus point:


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.
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:


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.
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:


TestScript(s)