Da Vinci Prior Authorization Support (PAS) FHIR IG
2.2.1 - STU 2.2 United States of America flag

Da Vinci Prior Authorization Support (PAS) FHIR IG, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.2.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-pas/ and changes regularly. See the Directory of published versions

Conformance Expectations

Page standards status: Trial-use

This implementation guide uses specific terminology such as SHALL, SHOULD, MAY to flag statements that have relevance for the evaluation of conformance with the guide. As well, profiles in this implementation guide make use of the mustSupport element. Base expectations for the interpretation of these terms are set in the FHIR core specification and general Da Vinci-wide expectations are defined in HRex. A summary of all such conformance statements found in this implementation guide can be found here.

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 (EHR) 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.).

Payer 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).

Payers SHALL have a distinct endpoint for each different supported version (which are not inter-version compatible) of the PAS specification.§conf-1 Payers may have multiple back-end functions that handle different types of decision support and/or different types of services. If a payer supports endpoint discovery, they SHALL have at most a single endpoint for each combination of version of the specification and coverage (e.g., Medicare, Medicaid, or commercial) they provide coverage under.§conf-2 In FHIR, a coverage instance essentially corresponds with the identification information on an insurance card, irrespective of the types of coverages available under that card. If a payer does not support endpoint discovery, they SHALL expose only one PAS endpoint of each supported version capable of handling all coverages.§conf-3

MustSupport

Profiles in this implementation guide make use of the mustSupport element.

The Must Support rules for the PAS specification are somewhat different than the rules for US Core and HRex because the implementation needs are different. In US Core, there is generally an expectation for clients to modify code and persistence layers to add support for 'mustSupport' elements in profiles. That expectation does not hold for PAS. Along with the following section on Interoperability Expectations, these rules recognize how existing Client, Intermediary, and Payer systems work with the existing X12 Prior Authorization specifications today.

NOTE: The following conformance rules around Must Support are explicitly for PAS actors and operations as opposed to rules around Must Support specified in any of the dependent guides, including US Core, HRex, CRD, and DTR. Specifically around US Core, neither the PA Client System nor the PA Intermediary System actors are considered to be a US Core Responder or US Core Requester actor.

In PAS, an element is marked as Must Support if that means that it could be exchanged between a provider and a payer. There is no expectation that all providers or all payers will support all elements marked as Must Support in the specification. As an example, the Home Health Care Information extension is provided for those providers that are requesting Home Health Care authorizations. If a provider does not support Home Health Care authorizations, there is no expectation that they would support this extension.

For PA Intermediary Systems, the following rules hold:

  • PA Intermediary Systems SHALL be capable of processing all data elements that are marked as Must Support on the Claim Request and Claim Inquiry if they are relevant to the types of authorization requests that they are capable of processing.§conf-4
  • PA Intermediary Systems SHALL NOT generate an error or cause the application to fail due the presence of any data element marked as Must Support that is sent as support for a type of authorization request that they are capable of processing.§conf-5
  • PA Intermediary Systems MAY generate an error if a data element that is marked as Must Support is sent as support for a type of authorization request that they are NOT capable of processing.§conf-6
  • 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 that are relevant to the types of authorization requests that they are capable of processing.§conf-7
  • If data elements that are not marked as Must Support are included in a Claim Request or Claim Inquiry, the receiving PA Intermediary System MAY ignore those elements.§conf-8

For PA client Systems, the following rules hold:

  • PA Client Systems SHALL be able to send any element that is marked as Must Support if data exists and is relevant to any authorization requests that they are capable of making.§conf-9
  • 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.§conf-10
  • PA Client Systems SHALL NOT generate an error or cause the application to fail when receiving any data element that is marked as Must Support.§conf-11
  • PA Client Systems SHOULD NOT send any data elements that are not marked as Must Support.§conf-12
  • PA Client Systems SHALL make any elements that are marked as Must Support and received in a response available to the appropriate users or leverage the data within their authorization workflow as necessary.§conf-13

Interoperability Expectations

For the PAS specification to work successfully at scale, it is essential that PAS clients and servers be able to interoperate with each other without custom expectations or deviations driven by EHR-specific or payer-specific requirements. The following rules are intended to help drive such consistency:

  1. When processing prior auth requests and additional data submissions, PAS services SHALL NOT depend on or set expectations for the inclusion of resource instances not compliant with profiles defined in this guide, CRD, DTR, HRex, or US Core.§conf-14 Similarly, they SHALL NOT depend on or set expectations for the inclusion of any data elements not marked as mandatory (min cardinality >= 1) or mustSupport in those profiles.§conf-15
  2. In the event a need to communicate data structures or elements not covered as required or mustSupport in the specification and there are not rules in X12 for the mapped element that would require the element to be present, the organization identifying the requirement has two choices:
    • gather the additional data using questionnaires via DTR
    • submit change requests proposing adding the relevant profiles and/or mustSupport elements to a future version of the PAS specification. If the proposed change is adopted and published in the PAS continuous integration build or the CI build of one of its dependencies (e.g. US Core), implementations MAY, by mutual agreement, pre-adopt the use of those additional profiles and/or mustSupport data elements and not be considered in violation of #1 above.§conf-16
  3. Where cardinality and other constraints present in profiles allow data elements to be omitted, PAS compliant systems SHALL NOT treat the omission of those elements as a conformance error.§conf-17 PAS responses are free to reject claims due to missing elements, but not treat the omission of non-required elements as an error resulting in a 4xx.
  4. PAS clients and services SHALL use standard PAS data elements (i.e. elements found within PAS-defined or inherited profiles and marked as mandatory or mustSupport) to communicate needed data if such elements are intended to convey such information.§conf-18 (If an organization believes they have a requirement for a data element not marked as mustSupport in the PAS or inherited profiles, they should raise the requirement for discussion on the PAS stream on chat.fhir.org.)
  5. PAS implementing organizations SHALL NOT publish guidance setting expectations for where certain data elements are conveyed within PAS and inherited data structures, but MAY submit change requests to PAS, HRex, or US Core requesting that additional guidance be provided to implementers on data structure usage to increase consistency across implementations.§conf-19