Healthcare Financial Services IG Edition 1 - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Prior-Authorization

Overview

This use case enables healthcare providers (HCPs) to obtain approval from the Health Insurance Company (HIC) before delivering healthcare services to beneficiaries. The Prior Authorization (PA) process ensures that the requested services or treatments meet payer criteria for coverage and reimbursement. Providers submit an authorization request to nphies, which validates and routes the request to the respective insurer or Third-Party Administrator (TPA). The insurer then adjudicates the request and responds with errors, approval, denial, or a request for additional information. If approved, then the insurer provides a reference to include on Claims for the approved services.

Workflow

1. Provider sends a Prior Authorization Request Message to the nphies system.
2. nphies validates the request and, if valid, proceeds to Step 3. Otherwise, it generates an error response.
3. nphies forwards the request to the designated insurer or TPA.
4. The insurer or TPA adjudicates the request and returns a Prior Authorization Response Message. and proceeds to Step 6.
5. nphies validates the response and, if valid, proceeds to Step 6; otherwise, an Error Notice Message* is generated.
6. nphies returns the Prior Authorization Response Message with approval, denial, or additional information requests, or errors, to the provider.

Prior Authorizations may be processed as real-time transactions or non-real-time transactions, depending on the insurer’s adjudication capabilities:

• Real-Time Transactions: When automatic adjudication is possible, the insurer immediately processes the authorization request and returns an approval, denial, or request for additional documentation within the same session.
• Non-Real-Time Transactions: If manual review is required, the insurer validates the request, returning errors (outcome=’error’) if invalid, or places the request in the insurer’s queue and responds with an Authorization Response Message indicating that the request is queued (outcome=.’queued’). The insurer may respond later with partial adjudication results (outcome=’partial’) but will only respond with the final response (outcome=’complete’) once the adjudication is completed.
• If nphies is unable to deliver the request to the insurer, or TPA, then nphies will pend the request for later delivery to the insurer, or TPA, and generate a response to the provider indicating that the request was received without errors, as far as nphies could detect, and that nphies will deliver the authorization request to the insurer once the exchange issue is resolved.
• In the event that nphies is not able to successfully deliver the Authorization Request Message to the HIC within less than one minute, or nphies generates a ‘pended’ message or an error message as documented above, then nphies will generate a response message, with a bundle.meta.tag to identifiy that the message has been issued by nphies, see Meta Tag: nphies-generated.
• Given that authorization exchange and processing is a time-limited activity providers should take appropriate alternate steps to ensure that they obtain a definitive authorization response within the required time frame to ensure timely patient care. This may require such methods as consulting an insurer or TPA portal or phoning a support help desk.
• Delayed responses, those not issued directly in the same session as the request, are stored on nphies and, if not containing errors detected by nphies, are stored (pended) for the provider. The provider can retrieve the valid response via Polling.

Message Structures

Prior Authorization Request Message

The key resources for the message are provided below and all require nphies-profiled resources as provided in the Artifacts. Note: the MessageHeader resource must be the first .entry in the bundle and any other resources may follow in any order.

Nphies Bundle (.type = message )
  Nphies MessageHeader (.eventCoding = priorauth-request)
  One of the following Authorization profiles:
     Nphies Authorization Institutional
     Nphies Authorization Oral
     Nphies Authorization Pharmacy
     Nphies Authorization Professional
     Nphies Authorization Vision
  Nphies Coverage
  Nphies Patient
  Nphies Organization (Provider)
  Nphies Organization (Insurer)
  Nphies Practitioner
  One of the following Encounter profiles based on the Authorization profile selected above: 
     Nphies Encounter Auth AMB (Ambulatory)
     Nphies Encounter Auth EMER (Emergency)
     Nphies Encounter Auth HH (Home Healthcare)
     Nphies Encounter Auth IMP (In-Patient)
     Nphies Encounter Auth SS (Day Case)
     Nphies Encounter Auth VR (Telemedicine)
  [any additional resources]

Prior Authorization Response Message

The key resources for the message are provided below and all require nphies-profiled resources as provided in the Artifacts. Note: the MessageHeader resource must be the first .entry in the bundle and any other resources may follow in any order.

Nphies Bundle (.type = message )
  Nphies MessageHeader (.eventCoding = priorauth-response)
  Nphies Authorization Response
  Nphies Coverage
  Nphies Patient
  Nphies Organization (Provider)
  Nphies Organization (Insurer)
  [Nphies CommunicationRequest]
  [any additional resources]

Guidance

There are five types of prior authorization handled within the nphies system:

1. Institutional Authorization – Used for hospital-based services such as inpatient admissions and surgical procedures.
2. Professional Authorization – Required for outpatient physician services, consultations, and diagnostic procedures.
3. Pharmacy Authorization – Necessary for prescription medications that require approval before dispensing.
4. Dental Authorization – Required for major dental procedures, such as orthodontics or surgeries.
5. Vision Authorization – Used for optical services, including corrective lenses and eye surgeries.

Each type of authorization follows a similar request-response pattern but may have specific extensions or required data elements.

Authorizations are managed by an insurer as a dynamic file of planned, and sometimes performed, products and services. The sections below detail how providers manipulate the effective contents of each dynamic authorization file.

• Providing Eligibility: Providers SHALL provide information about the Eligibility Check if one was performed prior to the authorization or claim. This information is provided through the Eligibility Response extension if the check was performed online via the Eligibility use case or if eligibility checking was done manually, for example on a portal or over the phone, via the Eligibility Offline Reference extension and the Eligibility Offline Date extension.

• SupportingInfo – Days Supply: Required for outpatient medications using the ‘days-supply’ category code (see the days-supply slice on supportingInfo). Not required for inpatient items.

Initial Authorization Request

The first authorization request for an intended suite of goods and services to treat a patient results, assuming at least one of the line items is accepted, in the creation of the dynamic authorization file and the return of an authorization reference in the ClaimResponse.preAuthRef element of the authorization response.

Changing the List of Services

The provider may change the list of requested services by submitting a new authorization request containing the previously supplied .preAuthRef in the authorization request. The new authgorization request must contain ALL of the goods and services to be performed including both those which has been previously approved and those which have been completed. For completed line items which the insurer had prevously approved the provider SHALL provide the .servicedDate, which may be today or in the past, and insurers SHALL return a response indiicating the item is approved - insurers SHALL NOT reject or otherwise alter the approval previously given for the line item. Providers and insurers SHALL also preserve the .item.sequence values across requests and responses to ease alignment and understanding.

Examples: The examples below assume the original authorization request included four service lines (sequence=1,2,3,4), all of which were approved,

1. Item Deletion: the provider wishes to remove item #3 then the provider submits a new authorization with the .preAuthRef and items 1, 2 and 4.
2. Item Addition: the provider wishes to add an item then the provider submits a new authorization with the .preAuthRef and items 1, 2, 3, 4 and 5 - the new item.
3. Item Changes: the provider wishes to modify the quantity or other elements of line #3:
   • if none of the line #3 services have been provided then remove item #3 and add a new item #5; or
   • if some of the item #3 services have been provided then adjust the item #3 quantity and provide the .servicedDate and add a new item #5 to reflect the remainer of the requested quantity; and, then the provider submits a new authorization with the .preAuthRef and items 1, 2, 3, 4 and 5.

Cancelling the Authorization

A provider may need to cancel an authorization if, for example: the treatment plan changes; the patient no longer wishes to proceed with the authorized services; or, the provider or practitioner is no longer available to provide the services on a timely basis. The provider SHALL issue a cancel-request with the identifier to the previously approved authorization in the Task.focus element. Providers SHALL NOT cancel authorizations where the ClaimResponse.preAuthPeriod has expired as this authorization is effectively cancelled.

Full Message Examples

Key Extensions

Error Handling

If nphies or the Insurer, or TPA on behalf of an insurer, detect errors in the request message such that the request cannot be processed then the response message will contain an OperationOutcome resource rather than a business-level response message.

Similarly, if the nphies system times-out on passing the request message to the Insurer/TPA or times-out on receiving a valid response from the Insurer/TPA or receives an invalid response from the Insurer/TPA then the nphies system will return a message with an OperationOutcome to indicate the nature of the error. If the response message is issued by nphies rather than the Insurer/TPA then a Bundle.meta.tag will be included to document that.

Like all other response messages the provider receives from nphies, if there are other messages queued at nphies which have not been delivered to the provider then this will be reflected in the presence of a MessageHeader.meta.tag. These queued messages may be retrieved by the provider at their convenience, see Polling for guidance on Polling, Pended Message retrieval.