This wiki has undergone a migration to Confluence found Here
Difference between revisions of "201609 Attachments"
Jump to navigation
Jump to search
| (28 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | [[Category:201609_FHIR_Connectathon_Track_Proposals| | + | [[Category:201609_FHIR_Connectathon_Track_Proposals|September 2016 Proposals]] |
__NOTOC__ | __NOTOC__ | ||
=Attachments= | =Attachments= | ||
| Line 9: | Line 9: | ||
==Justification== | ==Justification== | ||
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. --> | <!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. --> | ||
| + | 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== | ==Proposed Track Lead== | ||
| Line 14: | Line 15: | ||
See [[Connectathon_Track_Lead_Responsibilities]] | See [[Connectathon_Track_Lead_Responsibilities]] | ||
* Rick Geimer | * Rick Geimer | ||
| + | ** Email: rick dot geimer at lantanagroup dot com | ||
| + | ** Skype: rgeimer | ||
** Co-leads, Paul Knapp, Durwin Day | ** Co-leads, Paul Knapp, Durwin Day | ||
| Line 28: | Line 31: | ||
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | <!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | ||
===Payer=== | ===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=== | ===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. | |
==Scenarios== | ==Scenarios== | ||
| Line 41: | Line 44: | ||
* C-CDA on FHIR attachment | * C-CDA on FHIR attachment | ||
| − | + | Also remember to sign up on this spreadsheet | |
| − | + | ||
| − | : | + | https://docs.google.com/spreadsheets/d/1rrz8yqkG5gHhSEzUvZxP-6_CCFr_6F0FUElFRGmObyw/edit#gid=1088922430 |
| − | + | ||
| − | + | Here is a link to the main Connectathon 13 page with test servers, other tracks, etc. | |
| − | + | http://wiki.hl7.org/index.php?title=FHIR_Connectathon_13 | |
===Solicited=== | ===Solicited=== | ||
| − | :Action: | + | :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: |
| − | :Success Criteria: | + | :http://hl7.org/fhir/2016Sep/communicationrequest-example-fm-solicit-attachment.xml.html |
| − | :Bonus point: <!-- Any additional complexity to make the scenario more challenging --> | + | :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.<!-- Any additional complexity to make the scenario more challenging --> | ||
| + | |||
| + | Basic script for provider: | ||
| + | * Step 1: Assume payer has sent provider a communication request (example: http://fhirtest.uhn.ca/baseDstu3/CommunicationRequest/140045). | ||
| + | * 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 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. | ||
| + | |||
| + | Basic script for payer: | ||
| + | * Step 1: Payer crafts a communication request (example http://fhirtest.uhn.ca/baseDstu3/CommunicationRequest/140045). | ||
| + | * 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 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. | ||
<!-- Provide a description of each task --> | <!-- Provide a description of each task --> | ||
===Unsolicited=== | ===Unsolicited=== | ||
| − | :Action: | + | :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 |
| − | :Success Criteria: | + | :Precondition: Prior agreement in place between payer and provider. |
| − | :Bonus point: <!-- Any additional complexity to make the scenario more challenging --> | + | :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.<!-- Any additional complexity to make the scenario more challenging --> | ||
<!-- Provide a description of each task --> | <!-- Provide a description of each task --> | ||
| + | |||
| + | ===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.<!-- Any additional complexity to make the scenario more challenging --> | ||
| + | |||
| + | <!-- Provide a description of each task --> | ||
| + | |||
| + | TODO: Paul, how does the payer respond to the provider with an auth number and other info? | ||
==TestScript(s)== | ==TestScript(s)== | ||
Latest revision as of 13:19, 17 September 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
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.
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
Also remember to sign up on this spreadsheet
Here is a link to the main Connectathon 13 page with test servers, other tracks, etc.
http://wiki.hl7.org/index.php?title=FHIR_Connectathon_13
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:
- Step 1: Assume payer has sent provider a communication request (example: http://fhirtest.uhn.ca/baseDstu3/CommunicationRequest/140045).
- 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 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.
Basic script for payer:
- Step 1: Payer crafts a communication request (example http://fhirtest.uhn.ca/baseDstu3/CommunicationRequest/140045).
- 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 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.
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?
