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

Difference between revisions of "201709 Attachments"

From HL7Wiki
Jump to navigation Jump to search
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
+
[http://wiki.hl7.org/index.php?title=Category:201709_FHIR_Connectathon_Track_Proposals Return to September 2017 Proposals]
 
[[Category:201709_FHIR_Connectathon_Track_Proposals|September 2017 Proposals]]
 
[[Category:201709_FHIR_Connectathon_Track_Proposals|September 2017 Proposals]]
 
__NOTOC__
 
__NOTOC__
Line 67: Line 67:
 
* Claim/good-health-claim-1
 
* Claim/good-health-claim-1
 
* http://fhirtest.uhn.ca/baseDstu3/Claim/good-health-claim-1
 
* http://fhirtest.uhn.ca/baseDstu3/Claim/good-health-claim-1
 +
Extension (for attachment type)
 +
* StructureDefinition/221995
 +
* http://fhirtest.uhn.ca/baseDstu3/StructureDefinition/221995
 +
* In CommunicationRequest it goes at the top of the resource, in Communication it is the first child in Communication.payload.
 +
* The cannonical URL is http://hl7.org/fhir/us/attachments/StructureDefinition/attachment-type
 +
* Example
 +
    <extension url="http://hl7.org/fhir/us/attachments/StructureDefinition/attachment-type">
 +
        <valueCodeableConcept>
 +
            <coding>
 +
                <system value="http://loinc.org"></system>
 +
                <code value="34133-1"></code>
 +
                <display value="Summarization of Episode Note"></display>
 +
            </coding>
 +
        </valueCodeableConcept>
 +
    </extension>
  
Here is a link to the main Connectathon 14 page with test servers, other tracks, etc.  
+
Here is a link to the main Connectathon 16 page with test servers, other tracks, etc.  
  
http://wiki.hl7.org/index.php?title=FHIR_Connectathon_14
+
http://wiki.hl7.org/index.php?title=FHIR_Connectathon_16
  
 
===Solicited===
 
===Solicited===
Line 83: Line 98:
  
 
Basic script for provider:
 
Basic script for provider:
* Step 1: Assume payer has sent provider a communication request (example: http://fhirtest.uhn.ca/baseDstu3/CommunicationRequest/140045).
+
* Step 1: Assume payer has sent provider a communication request (example: http://fhirtest.uhn.ca/baseDstu3/CommunicationRequest/example-comm-req).
* Step 2: Provider uses the content of the request to craft a communication resource as the response (example: http://fhirtest.uhn.ca/baseDstu3/Communication/140046)
+
* Step 2: Provider uses the content of the request to craft a communication resource as the response (example: http://fhirtest.uhn.ca/baseDstu3/Communication/example-comm)
 
* Step 3: Provider creates an attachment (PDF, CDA, C-CDA on FHIR)
 
* 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 4: Provider POSTs the Communication resource and attachment to FHIR server.
Line 90: Line 105:
  
 
Basic script for payer:
 
Basic script for payer:
* Step 1: Payer crafts a communication request (example http://fhirtest.uhn.ca/baseDstu3/CommunicationRequest/140045).
+
* Step 1: Payer crafts a communication request (example http://fhirtest.uhn.ca/baseDstu3/CommunicationRequest/example-comm-req).
* Step 2: Provider uses the content of the request to craft a communication resource as the response (example: http://fhirtest.uhn.ca/baseDstu3/Communication/140046)
+
* Step 2: Provider uses the content of the request to craft a communication resource as the response (example: http://fhirtest.uhn.ca/baseDstu3/Communication/example-comm)
 
* Step 3: Provider creates an attachment (PDF, CDA, C-CDA on FHIR)
 
* 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 4: Provider POSTs the Communication resource and attachment to FHIR server.
Line 113: Line 128:
 
:Success Criteria: Payer receives the attachment and is able to view it.  
 
:Success Criteria: Payer receives the attachment and is able to view it.  
 
:Bonus point: Send to an adjudication engine in the Financial track.<!-- Any additional complexity to make the scenario more challenging -->
 
:Bonus point: Send to an adjudication engine in the Financial track.<!-- Any additional complexity to make the scenario more challenging -->
 
===Patient Voice - Solicited Personal Advance Care Plan===
 
:Action: Provider creates a communication request to ask the patient to send his or her current advance care plan information ("advance directives").
 
:Precondition: The patient has created and maintains his or her advance directive information in a system that allows download of the information in a pdf or PACP (CDA). The Patient also has a Direct Secure Messaging address that he or she uses to communicate directly with the provider.
 
:Success Criteria: Provider receives a person's current advance care planning information in a solicited PACP document.
 
 
===Patient Voice - Unsolicited Personal Advance Care Plan===
 
:Action: Patient creates or updates his or her advance care plan information ("advance directives") and proactively shares the information with his or her care provider.
 
:Precondition: The patient has created and maintains his or her advance directive information in a system that allows download of the information in a pdf or PACP (CDA). The Patient also has a Direct Secure Messaging address that he or she uses to communicate directly with the provider.
 
:Success Criteria: Provider receives a person's current advance care planning information in an unsolicited PACP document.
 
  
 
<!-- Provide a description of each task -->
 
<!-- Provide a description of each task -->

Latest revision as of 19:03, 9 September 2017

Return to September 2017 Proposals

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
  • A|D Vault
  • ZeOmega
  • Janie Appleseed (powered by MaxMD)

Roles

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

Payer

Plays the role of a payer who may request and receive attachments. This is loosely analogous to the "FHIR Client - Claims Attachment Requestor" and "FHIR Client - Claims Attachment Processor" roles in the Financial Management track, but with a focus on content instead of process.

Provider

Plays the role of a provider who may receive requests for attachments and send attachments (solicited or unsolicited). This is loosely analogous to the FHIR Client - Claims Attachment Submitter role in the Financial Management track, but with a focus on content instead of process.

Clearinghouse

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.

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

Below are some sample resources we can use during the Connectathon. Most of these will need to be linked to the CommunicationRequest and Communication resources you will create.

Patient

Clearinghouse

Payer

Provider

Claim

Extension (for attachment type)

   <extension url="http://hl7.org/fhir/us/attachments/StructureDefinition/attachment-type">
       <valueCodeableConcept>
           <coding>
               <system value="http://loinc.org"></system>
               
               <display value="Summarization of Episode Note"></display>
           </coding>
       </valueCodeableConcept>
   </extension>

Here is a link to the main Connectathon 16 page with test servers, other tracks, etc.

http://wiki.hl7.org/index.php?title=FHIR_Connectathon_16

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:
http://hl7.org/fhir/2016Sep/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 C-CDA on FHIR attachment):
http://hl7.org/fhir/2016Sep/communication-example-fm-solicited-attachment.xml.html
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 provider:

Basic script for payer:


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/2016Sep/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

Action: Provider creates an attachment and sends it to the payer. Here is an example of a Communication resource for prior authorization (the payload would point to the PDF, C-CDA, or C-CDA on FHIR attachment):
http://hl7.org/fhir/2016Sep/communication-example-fm-attachment.xml.html
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: Send to an adjudication engine in the Financial track.


TODO: Paul, how does the payer respond to the provider with an auth number and other info?

TestScript(s)