This page is part of the Da Vinci Prior Authorization Support (PAS) FHIR IG (v2.0.1: STU 2) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Technical Background

Page standards status: Informative

Previous Page - Request for Additional Info

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 members 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 partners.
4. Clinical Data Exchange (CDex) supports the launch of DTR to gather documentation through the CDex Task Data Request Profile, which provides the questionnaire Task.input reference to Communicate to the provider a URL of a data request FHIR Questionnaire, and the ‘data-request-questionnaire’ Task.code which indicates the provider system uses DTR to complete the Questionnaire referenced in the questionnaire input parameter.

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

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 system actions can indicate that additional clinical and/or administrative information needs to be captured, allowing the EHR to prompt the appropriate user(s) to launch the DTR process to guide the user(s) in capturing the relevant information.
• The need for DTR is indicated in an extension created by a CRD system action. DTR allows the capture of information needed to support prior authorization requests and that can be included as part of such requests in PAS.
• PAS can be used to submit a prior authorization based on a requirement identified by CRD and include information requested by the payer in the form for a QuestionnaireResponse Bundle. The QuestionnaireResponse Bundle is included in the PAS request bundle and referenced by the PA profile on the claim as .supportingInformation. The entire PAS bundle passed to the payer includes the QuestionnaireResponse Bundle.

All three implementation guides should be used together to 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 several 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.
• DTR might be invoked directly by a clinician to validate documentation regarding an item or service that meets a responsible payer’s requirements.
• Information gathered by DTR will normally be used for submission via PAS to support a prior authorization request. However, the Questionnaire Response and its associated references may be exchanged, using other methods, with a performing provider, payer, or other entity to supply medical necessity documentation.
• PAS can be used for prior authorization submissions even if the requirement is not identified by CRD and the supporting documentation is exchanged via another method.

The greatest benefit to clinical workflow and reduction of manual intervention is achieved by implementing all three IGs at the same time. However, implementers can choose to roll out these three implementation guides in whatever order or combination best meets their business objectives.

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

• FHIR Overview
• Developer’s Introduction (or Clinical Introduction)
• FHIR Data Types
• Using Codes
• References between Resources
• How to Read Resource & Profile Definitions
• Base Resource

This implementation guide supports the R4 version 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.

Must Support

The Profile elements consist of both Mandatory and Must Support elements. Mandatory elements are elements with a minimum cardinality of 1 (min=1). The base FHIR Must Support guidance requires specifications to define the support expected for profile elements labeled Must Support. The HRex IG defines some conformance expectations that all Da Vinci IGs are expected to follow. Along with those expectations, the following rules on MustSupport are also required:

• PA Intermediary Systems SHALL be capable of processing all data elements that are marked as Must Support on the Claim Request and Claim Inquiry. They SHALL not generate an error or cause the application to fail due the presence of any data element marked as Must Support.
• PA Intermediary Systems SHALL be capable of returning resource instances containing any of the data elements that are marked as Must Support on the Claim Response and the Claim Inquiry Response.
• PA Client Systems SHALL be capable of receiving all data elements that are marked as Must Support on the Claim Response and the Claim Inquiry Response. They SHALL not generate an error or cause the application to fail when receiving any data element that is marked as Must Support.
• PA Client Systems SHOULD NOT send any data elements that are not marked as Must Support. If these data elements are included in a Claim Request or Claim Inquiry, the receiving PA Intermediary System MAY ignore those elements.

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

X12 Terminology

All of the X12 Terminology is copyright of the X12 organization. All of the code systems and value sets that are referenced use URLs that are provided by X12. The intent of the X12 organization is to have those URLs resolve for members. It is also possible to find the relevant codes by referencing the X217 and X215 Technical Reports in X12’s Glass viewer. (NOTE: The links to the X12 Technical Reports will only be visible to X12 members.) Further information on the use of X12 terminology in HL7 can be found at the HL7 Terminology Authority X12 page.

The different components of the X12 ValueSet URLs can be interpreted as follows:

1. valueset.x12.org
2. TR3 ID, eg. x217, x215
3. TR3 Version, eg. 005010
4. ‘request’ or ‘response’
5. loop ID, eg. 2010EA
6. segment ID, eg. NM1
7. segment repetition, eg. 1
8. data element position, eg. 06
9. data subelement position, eg. 00
10. data element number, eg. 1338

Thus any URL can be parsed to determine where to find the set of codes in the appropriate X12 Technical Report.

Next Page - HIPAA Regulations