Da Vinci Prior Authorization Support (PAS) FHIR IG
1.0.0 - STU 1

This page is part of the Da Vinci Prior Authorization Support (PAS) FHIR IG (v1.0.0: STU 1) based on FHIR R4. The current version which supercedes this version is 1.1.0. For a full list of available versions, see the Directory of published versions

Technical Background

Da Vinci

Da Vinci is an industry sponsored project which is contributing to the development of HL7 standards. It brings together the U.S. payer, providers, and technology suppliers (including EHR vendors) to help payers and providers to positively impact clinical, quality, cost, and care management outcomes using FHIR-related technologies. The project organizes meetings (face-to-face and conference calls) as well as connectathons to find ways to leverage FHIR technologies to support and integrate value-based care (VBC) data exchange across communities. Da Vinci identifies value-based care use cases of interest to its member and the community as a whole.

The process that Da Vinci has adopted includes:

  1. identify business, clinical, technical and testing requirements,
  2. develop and ballot a FHIR based implementation guide (IG),
  3. develop a reference implementation (RI) that is used to demonstrate that the concepts in the IG are possible to implement,
  4. pilot the standard
  5. support the production use of the IG to enable exchange of data to support interoperability for value-based care.

Additional information about Da Vinci, its members, the use cases and the implementation guides being developed can all be found on the HL7 website. Meeting minutes and other materials can be found on the Da Vinci Confluence page.

Da Vinci Burden Reduction

This implementation guide is part of a set of interrelated implementation guides that are focused on reducing clinician and payer burden. The Da Vinci ‘Burden Reduction’ implementation guides are:

  1. Coverage Requirements Discovery (CRD) which provides decision support to providers at the time they’re ordering diagnostics, specifying treatments, making referrals, scheduling appointments, etc.
  2. Documentation Templates and Rules (DTR) which allows providers to download ‘smart’ questionnaires, rules (e.g. CQL), and provides a SMART on FHIR app or EHR app that executes them to gather information relevant to a performed or planned service. Execution of the questionnaires and rules may also be performed by an application that is part of the provider’s EHR.
  3. Prior Authorization Support (PAS) allows provider systems to send (and payer systems to receive) prior authorization requests using FHIR, while still meeting regulatory mandates to have X12 278 used, where required, to transport the prior authorization, potentially simplifying processing for either or both exchange partner.

The general flow of activity across all three IGs can be seen in the following diagram:

Clinical SystemPayerProviderEHREHR repositoryHooks ServiceSMART appPrior AuthconverterRules repositoryPrior AuthprocessorCoverage Requirements Discovery (CRD)For "what if" scenariosEHR is played by SMART appCreate order/referral/etc.Is there anything provider should know?Retrieve patient dataYes, e.g.:No coverage requirements; orSeelinkto opioid guidelines; orThat lab test was already run, results are here:... ; orThere are documents to fill outClickhereto launch SMART appDocumentation, Templates & Rules (DTR)Click 'launch' on SMART App cardLaunch SMART appRetrieve Questionnaire/CQL rulesRetrieve data to populate QuestionnaireResponse/execute CQLUser verifies data & QuestionnaireResponseStore completed QuestionnaireResponse/other infoPrior Authorization Support (PAS)"Request prior auth"FHIR prior auth request(with completed form(s) from DTR process)"X12 (+FHIR) prior auth requestwith completed form(s)"X12 prior auth responseFHIR prior auth responseDisplay prior auth response

The guides overlap in the following ways:

  • CRD can indicate whether prior authorization is or is not required and whether there are or are not ‘special documentation requirements’ related to the planned service. The CDS Hook cards returned by CRD can include a link to a DTR SMART application that will then guide the clinician in capturing the relevant information
  • DTR can be triggered by a CRD hook. It allows captures of information needed to support prior authorization requests and that can be included as part of the request
  • PAS can be used to submit a prior authorization based on a requirement identified by CRD and using information gathered by DTR

All three implementation guides can be used together and intersect in that they perform business functions related to prior authorization. However the first two IGs also offer functionality that’s unrelated to prior authorization. The guides can function independently in a number of ways:

  • CRD can provide information unrelated to prior authorization and ‘special documentation’. For example, providing an estimate of patient cost, suggesting appropriate use criteria, identifying duplicate therapies, etc.
  • CRD can identify a need for prior authorization and/or special documentation but, instead of linking to a DTR solution, might simply point to a website or other documentation with guidance on the appropriate forms to complete
  • DTR might be invoked directly by a clinician who either knows or is informed by means other than CRD about the requirement to gather additional documentation
  • Information gathered by DTR might be used for direct submission of prior authorizations to support X12 278 transactions or using alternative submission means (e.g. fax, mail) if supported/required by the relevant payer
  • PAS can be used for prior authorization submissions where the need to submit a prior authorization was identified without CRD (either known in advance or identified by other means) and/or the supplemental information to be provided was identified and gathered outside of or in addition to DTR.

As such, implementers can choose to roll out these three implementation guides in whatever order or combination best meets their particular business objectives - though obviously coordinating with their communication partners so that there are other systems to interoperate with will also be important.

Systems

The PAS implementation guide defines the responsibilities of the two types of systems involved in a PAS solution:

Client systems are typically Electronic Medical Record (EMR) systems but could theoretically be any system responsible for requesting prior authorizations . (E.g. practice management systems, pharmacy systems (for drugs that are part of a medical benefit), dental systems, etc.)

Server systems (or servers) are typically intermediary systems that act on behalf of payer organizations and are responsible for conversion of prior authorization requests to and from X12 for subsequent relay to payer systems. In some cases, a server system may directly be a payer system (if X12 translation is not required by regulation).

Underlying technologies

This guide is based on the HL7 FHIR standard. Implementers of this specification therefore need to understand some basic information about these specifications.

FHIR

This implementation guide uses terminology, notations and design principles that are specific to FHIR. Before reading this implementation guide, it’s important to be familiar with some of the basic principles of FHIR as well as general guidance on how to read FHIR specifications. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the rest of this implementation guide.

This implementation guide supports the R4 version of the FHIR standard. R4 is just recently published and the goal is to ensure the implementation guide is aligned with the current direction of the FHIR standard.

This implementation guide also builds on the US Core (STU3 - R4 based) Implementation Guide and implementers need to familiarize themselves with the profiles in that IG.

ASC X12N

The intention of this implementation guide is that detailed knowledge of X12N is not required by client/EHR implementers, though knowledge of some value sets and business processes will be needed. Intermediary systems will require an intimate understanding of the X12N specification, particularly the 278 and 275 transactions. The following X12 Standards are referenced in this guide:

  • ASC X12N/005010X217 - Health Care Services Review - Request for Review and Response (278) - provide standardized data requirements and content for all users who request authorizations or certifications or who respond to such requests
  • ASC X12N/005010X215 - Health Care Services Review - Inqury and Response (278) - provide standardized data requirements and content for all users who inquire on authorizations or certifications or who respond to such inquiries
  • ASC X12N/006020X316 - Additional Information to Support a Health Care Services Review (275) - provide standardized data requirements and content to send additional information about a healthcare service review.

NOTE: At the time of publication, only the use of ASC X12N/005010X217 is mandated by HIPAA.