This page is part of the Da Vinci Prior Authorization Support (PAS) FHIR IG (v2.1.0: 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

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) documents launching DTR to gather additional information ("attachments"). The portion of CDex that is relevant to Burden Reduction is the use of the PAS Task profile. The PAS Task Profile uses the launching of DTR to communicate to the provider a URL of a data request FHIR Questionnaire. The Task.code indicates to the provider system to use DTR to complete the Questionnaire, and the URL of the Questionnaire "package" is communicated in Task.input.

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 required and whether there are '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 of 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 four implementation guides should be used together to perform business functions related to prior authorization. CMS Interoperability and Prior Authorization Final Rule CMS-0057-F recommends (and CMS may in the future require) that payers implement the functionality defined in the CRD, DTR, and PAS guides within their APIs. However, all IGs other than PAS also offer functionality that is 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 documentation of medical necessity.
• 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.
• HRex can be used to solicit information unrelated to prior authorization.

The greatest benefit to clinical workflow and reduction of manual intervention is achieved by implementing all four IGs at the same time. However, implementers can choose to roll out these implementation guides in whatever order or combination best meets their business objectives. (Note that regulations may set expectations for when certain implementation guides must be used.)

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 and additional IG reading guidance
• Base Resource

This implementation guide supports the R4 version of the FHIR standard.

This implementation guide also builds on the US Core Implementation Guide and implementers need to familiarize themselves with the profiles in that IG.

Implementers should also familiarize themselves with the FHIR resources used within the guide:

Resource	Relevance
Bundle	Used when delivering collections of resources in a PAS operation
CapabilityStatement	Used to define conformance expectations for this guide
Claim	The main resource that contains the information about what is being requested to be authorized
ClaimResponse	The main resource that contains the information about what was authorized, if any
CodeSystem	Used to define custom codes specific to this guide
CommunicationRequest	Used to convey information that the payer needs to make an authorization decision
Coverage	Used to identify the member and the relevant insurance coverage to a payer
DeviceRequest	One of the resources that indicates what authorization is needed
Encounter	One of the resources that indicates what authorization is needed and also provides context for other resources
Location	Supporting information for encounters and request resources
MedicationRequest	One of the resources that indicates what authorization is needed
NutritionOrder	One of the resources that indicates what authorization is needed
OperationDefinition	Used to define the two main operations used in this IG
Organization	Used when identifying providers in Encounters, Tasks, and all requests
Parameters	Used to provide the information for the operations
Patient	Demographic information relevant to all requests
Practitioner	Used when identifying providers in Encounters, Tasks, and all requests
PractitionerRole	Used when identifying providers in Encounters, Tasks, and all requests
ServiceRequest	One of the resources that indicates what authorization is needed
StructureDefinition	Used when profiling resources and defining extensions
Subscription	Used when subscribing for authorization decisions for an organization
Task	Used to define something that is needed to be done by the provider to submit information
ValueSet	Used to define collections of codes used by PAS profiles

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