Allows a Prescriber to Request or Cancel Prior Authorization for Medications

Printer Friendly, PDF & Email
Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Implementation Specification
Final
Feedback requested
Feedback Requested
No
$
No
Implementation Specification
Final
Production
Rating 2
No
$
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The prescriber system must receive timely Formulary & Benefit file updates from payers/intermediaries, giving group-level formulary and coverage information (including PA flags) for use when ordering medications.
  • The following ASC X12 patient eligibility transactions enhance the PA Request transactions by supplying the prescriber system with the patient’s pharmacy benefit information, and need to be implemented for interoperability purposes:
    • Eligibility Request (ASC X12 270)
    • Eligibility Response (ASC X12 271)  
  • The following SCRIPT 2017071 PA transactions need to be implemented for interoperability purposes:
    • PAInitiationRequest and PAInitiationResponse
    • PARequest and PAResponse
    • PAAppealRequest and PAAppealResponse
    • PACancelRequest and PACancelResponse
    • Both the prescriber and the payer/processor/pharmacy benefits manager (PBM) must have their systems configured for these transactions in order to facilitate successful exchange, including the ability to send or receive status or error messages.
    • See NCPDP projects in the Interoperability Proving Ground.
    • Secure Communication – create a secure channel for client-to- server and server-to-server communication.
    • Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.
    • Authentication Enforcer – centralized authentication processes.
    • Authorization Enforcer – specifies access control policies.
    • Credential Tokenizer – encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos).
    • Assertion Builder – define processing logic for identity, authorization and attribute statements.
    • User Role – identifies the role asserted by the individual initiating the transaction.
    • Purpose of Use - Identifies the purpose for the transaction.

    Comment

    NCPDP - Comment on Version 10.6

      • The adoption level should be modified to a 2.
      • Under Limitations, Dependencies, and Preconditions for Consideration add the following:
        • The following transactions need to be implemented for interoperability purposes:
          • PAInitiationRequest and PAInitiationResponse
          • PARequest and PAResponse
          • PAAppealRequest and PAAppealResponse
          • PACancelRequest and PACancelResponse
        • Both the prescriber and the payer/processor/pharmacy benefits manager (PBM) must have their systems configured for the transaction in order to facilitate successful exchange.
      • Under Applicable Security Patterns for Consideration add the following:
        • Secure Communication – create a secure channel for client-to- serve and server-to-server communication.
        • Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.
        • Authentication Enforcer – centralized authentication processes.
        • Authorization Enforcer – specifies access control policies.
        • Credential Tokenizer – encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos).
        • Assertion Builder – define processing logic for identity, authorization and attribute statements.
        • User Role – identifies the role asserted by the individual initiating the transaction.
        • Purpose of Use - Identifies the purpose for the transaction.