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

201809 Coverage Requirements Discovery

From HL7Wiki
Revision as of 15:56, 26 June 2018 by Andrewg (talk | contribs) (→‎Roles)
Jump to navigation Jump to search


Track Name

Coverage Requirements Discovery (CRD)

Submitting WG/Project/Implementer Group

The Da Vinci Project

Justification

The goal of the CRD Implementation Guide is to allow healthcare payers to be able to query payers to determine:

  • Specific documentation requirements
  • Rules for determining need for specific treatments/services
  • Requirement for Prior Authorization (PA) or other approvals
  • Specific guidance

This track will be testing the ability of a participants to issue a FHIR Operation to discover coverage requirements. It is expected that there will be a reference implementation of the FHIR Operation in a FHIR server to mimic the response with coverage requirement documentation. The track will test the CRD IG that is being balloted in September. This test will help demonstrate:

  • Profiles of FHIR resources along with the operation allow the necessary information for discovery of coverage discovery
  • Profiles of FHIR resources allow the communication of the location of coverage requirement documentation back to providers.

Proposed Track Lead

Andy Gregorowicz - The MITRE Corporation - andrewg@mitre.org

See Connectathon_Track_Lead_Responsibilities

Expected participants

Cerner, Epic, Allscripts, CMS (via The MITRE Corporation), United, Humana, Anthem

Roles

Healthcare Provider

In this role, a provider wishes to discover the documentation requirements for home oxygen therapy. It is expected that the provider will be able to:

  • Invoke the CRD FHIR Operation
    • Populate the Operation in parameters with the necessary demographic, payer and requested service information
  • Handle the response of the CRD FHIR Operation
    • Display to the provider the links to the documentation requirements and allow the provider to follow the links

It is expected, but not necessary, that the Provider end will be implemented as a SMART on FHIR app. The app would pull demographic and payer information from the local EHR and then provide a user interface to allow the provider to select the desired service. The SMART on FHIR app would then invoke the CRD FHIR Operation and display the response.

Healthcare Payer

In this role, the payer examines the request for documentation and responds appropriately. This could be viewed as the server part of the transaction. It is expected that participants in this role will:

  • Provide a FHIR server that implements the CRD FHIR Operation as specified in the CRD IG
  • Provide sample documentation responses for incoming queries

Scenarios

Scenario Step 1 Name

Action:
Precondition:
Success Criteria:
Bonus point:


TestScript(s)

Security and Privacy Considerations