Capabilities required for an EHR participating in a PAS Exchange.

Capabilities required for an Intermediary participating in a PAS Exchange.

This operation is used to make a search for a Prior Authorization Response by example for a previously-submitted PreAuthorization. This Prior Authorization $inquire operation is a query-by-example that follows the X12 278 Inquiry rules. The only input parameter is the single Bundle resource with a PASClaimInquiry instance (along with other referenced resources) and the only output is a single Bundle with zero-to-many PASClaimInquiryResponses (and other referenced resources) or an OperationOutcome resource.

This operation is used to submit a PreAuthorization Claim Request for adjudication as a Bundle containing the PASClaimRequest and other referenced resources for processing. The only input parameter is the single Bundle resource with a PASClaimRequest instance (along with other referenced resources) and the only output is a single Bundle with a PASClaimResponse (and other referenced resources) or an OperationOutcome resource. This is a variant of the FHIR Core Claim $submit operation.

A logical model describing the information that should be captured by PAS implementers about every PAS invocation to support measures evaluating PAS implementation

PAS constraints on Claim resource that are common to both the request and the inquiry.

PAS constraints on ClaimResponse resource that are common to both the request and the inquiry.

A base profile for organizations in PAS

A patient who is the beneficiary of an insurance plan.

PAS constraints on Claim resource mandating support for elements relevant to the prior authorization request

PAS constraints on Claim resource when submitting an inquiry for existing authorizations.

PAS constraints on Claim resource mandating support for elements relevant to the response of an inquiry for details of previous authorizations.

PAS constraints on Claim resource mandating support for elements relevant to the response of a prior authorization request

PAS constraints on Claim resource when submitting an update to a previous PAS prior authorization request

PAS constraints on CommunicationRequest resource mandating support for elements relevant to the prior authorization response

PAS constraints on Coverage resource mandating support for insurance elements relevant to the prior authorization request

PAS constraints on DeviceRequest resource mandating support for elements relevant to the devices being requested on a prior authorization request

PAS constraints on the Encounter resource mandating support for elements relevant to details of a requested institutional stay on the prior authorization request

PAS constraints on Bundle resource ensuring that a claim inquiry resource is present and that non-supported elements are not.

PAS constraints on Bundle resource ensuring that a claim inquiry response resource is present and that non-supported elements are not.

An organization who provides insurance and is the receiver of a prior authorization request.

A profile on US-Core location to allow for specifying where a practitioner is working at.

PAS constraints on MedicationRequest resource mandating support for elements relevant to the prescriptions being requested on a prior authorization request

PAS constraint on Nutrition Order resource for elements relevant to the ordering of nutrition on a prior authorization request

PAS constraints on Practitioner resource mandating support for elements relevant to the care team involved in a prior authorization request

PAS constraints on PractitionerRole resource mandating support for elements relevant to the care team involved in a prior authorization request

PAS constraints on Bundle resource ensuring that a claim/claim update resource is present and that non-supported elements are not.

The organization who is making a prior authorization request.

PAS constraints on Bundle resource ensuring that a claim response resource is present and that non-supported elements are not.

PAS constraints on ServiceRequest resource mandating support for elements relevant to the generic services being requested on a prior authorization request

A patient who is the subscriber of an insurance plan.

PAS constraints on Task resource that is used to request additional documentation for prior authorizations.

Constraints and extensions on Identifier allowing for a common datatype across all resource profiles.

PAS constraints on the Timing datatype used in the various service requests.

A string assigned by the UMO to the original disallowed review outcome associated with this service item.

A string assigned by the UMO to an authorized review outcome associated with this service item.

A code representing the specific days when a service is being requested

A flag that indicates whether the care team applies to the entire claim or a single item.

The specific date or period within which this item's preauthorization became effective.

The specific date or period within which this item's preauthorization expires.

The specific date or period within which this item's preauthorization was issued.

A code representing the type of certification being requested (UM02)

A code representing the diagnosis that is the subject of the communication

Information to supply various patient conditions.

A code representing a modifier of the content being requested

A code representing the specific delivery of a service being requested

The date that a diagnosis was recorded. (HIxx-4)

An indicator of whether early and periodic screen for diagnosis and treatment of children is involved.

The specific loop, segment, or element that this error information is about.

A code representing what action must occur to resolve this error.

The FHIRPath expression that indicates which FHIR element that this error information is about.

Information needed for home health care requests.

An additional element that provides the assigning jurisdiction of the identifier (i.e. provider state license number or state driver's license) so that it does not need to be mapped from the identifier system.

An additional element that provides a further subdivision within the organization granting the identifier.

A flag indicating whether the piece of information was cancelled.

A code indicating how the piece of information has changed.

The details of what has been authorized for this item if different from what was requested.

The specific provider who has been authorized to provide this item.

The date when this item's preauthorization was issued.

The date/period when this item's preauthorization is valid.

The original date/period that was requested by the submitter for this item.

Uniquely identifies this claim item. (2000F-TRN)

A code specifying the level of service being requested (UM06)

A patient's military status.

A code specifying the level of care provided by a nursing home facility. (SV120, SV210)

A code specifying the status of a nursing home resident at the time of service. (SV209)

A specific line number associated with the attachment request code or TRN.

A code representing the status of the patient when being admitted

Used to provide the last code in a series of codes for the service being requested.

The details of the service being requested.

The limit on the rate per unit of revenue for hospital accomodation. (SV206)

The details of the review action that is necessary for the authorization.

The code describing the result of the review.

A code that identifies the type of service being requested.

A number that links the content being requested with the claim item number.

These codes are used to convey specific accomodation, ancillary service or unique billing calculations or arrangements. They are listed within the UB-04 Data Specifications Manual and maintained by the National Uniform Billing Committee (NUBC).

A list of codes indicating the perspective from which metric data was captured

Types of channels that a communication request can be made

The mode by which a piece of information has changed.

This value set includes LOINC terms that can be sent by a payer as part of an HL7 attachment request for additional information. It has been curated by the HL7 Payer/Provider Information Exchange (PIE) Work Group. More information about using LOINC in HIPAA attachments and the source of this value set can be found at LOINC Attahments.

In addition to using LOINC attachment codes, a payer may request for additional information from the provider to support a prior authorization request using X12's PWK01 Attachment Report Type Code.

Note that the PWK01 codes will not be published in due to X12 IP restrictions.

Types of supporting information for a Prior Authorization Claim.

The code for the task that is request additional information.

This set of codes identifies the category of a patient's condition.

This set of codes identifies a patient's conditions.

The complete set of codes that can be used to convey a patient diagnosis. This includes codes from ICD-10-CM, ICD-9-CM and Diagnosis Related Group codes.

LOINC codes that convey the type of information that is being requested about the diagnosis.

This set of codes is used to identify the type of diagnosis that is being conveyed in the prior authorization.

The complete set of codes that are used to indicate any follow-up actions that are allowed for a reject reason.

This set of codes identifies where services were, or may be, performed. The codes are taken from NUBC Bill Type and from CMS Place of Service codes.

This set of codes identifies enteral formula codes.

This set of codes identifies oral diet codes.

The complete set of codes that are used to indicate the reason why something was rejected.

This set of codes identifies modifiers to the type of service being requested. It is a combination of CPT (HCPCS I) and HCPCS II procedure code modifiers. NOTE: HCPCS Level 1 Codes are the CPT codes so either code system could be used to send the codes. When receiving the codes from an X12 system, the system returned will be HCPCS even if it was initially sent as a CPT code.

This set of codes identifies what service is being requested. For queries, if the query is not searching for a specific service type, the not-applicable data absent reason code can be used. It is a combination of X12 Service Type codes, CPT (HCPCS I) and HCPCS II procedure code modifiers, ICD-9 Procedure codes, ICD-10 Procedure codes, and NDC Drug codes. NOTE: HCPCS Level 1 Codes are the CPT codes so either code system could be used to send the codes. When receiving the codes from an X12 system, the system returned will be HCPCS even if it was initially sent as a CPT code.

Codes used to identify the reason for the health care service review outcome.

Codes temporarily defined as part of the PAS implementation guide. These will eventually migrate into an officially maintained terminology (likely either SNOMED CT or HL7's UTG code systems).

An example of a PAS Task requesting additional information.

An example of a ClaimResponse where the requestor is a Practitioner.

A sample communication request asking for more information about a specific diagnosis.

A sample device request for a wheelchair.

An example of encounter details for a surgical admission request.

An example of a ClaimResponse bundle with errors.

An example of a ClaimResponse with errors.

An example of a Claim bundle requesting prior authorization of a home healthcare service.

An example of a Claim bundle changing elements of a previously sent prior authorization request.

An example of a Claim resource updating a prior authorization.

An example of a Claim resource requesting prior authorization of a home healthcare service.

An example of a Claim bundle updating a previously sent prior authorization request.

An example of a Claim resource updating a prior authorization.

An example of a Claim bundle requesting Medical Services Reservation.

An example of a Claim resource requesting prior authorization of Medical Services Reservation.

A sample medication request to prescribe a specific drug.

A sample nutrition order.

An example of a Claim resource used to search for prior authorizations that match the example.

An example of a ClaimResponse resource that is a response to a claims inquiry.

An example of a Claim bundle inquiring about prior authorizations.

An example of a ClaimResponse bundle returning a response to a claims inquiry.

An example of the parameters going back for a PAS subscription notification

An example of a PAS Subscription Notification

An example of a PAS Subscription submission for a specific provider.

An example of a ClaimResponse where the requestor is a Practitioner and the response is pended.

An example of a Claim bundle requesting prior authorization of a referral.

An example of a Claim resource requesting prior authorization of a referral.

An example of a ClaimResponse bundle approving the authorization of a referral.

An example of a ClaimResponse bundle with a pending authorization of a referral.

An example of a ClaimResponse bundle showing the rejection of a request.

An example of a ClaimResponse that is rejected.

Sample patient who is a beneficiary of an insurance plan.

Sample insurance for a prior authorization.

A sample payor organization.

A sample location.

A sample practitioner who is being referred to.

A sample practitioner role instance.

A sample referral request that is the subject of a prior authorization.

A sample organization that is requesting a prior authorization.

Sample patient who is a subscriber of an insurance plan.

A sample location.

A sample practitioner who is being referred to.

A sample practitioner role instance.

An example of a Claim bundle requesting prior authorization of a surgical service.

An example of a Claim resource requesting prior authorization of a surgical service.

This is the subscription topic used for retrieving results from pended authorization requests.