(Topic Last Updated On: 06/08/2015)
The Prior Authorizations menu item on the Accounting menu launches the Prior Authorizations screen, which is used to enter Prior Authorizations for rendered Billable Services for an individual patient. This screen replaces the Billing Authorizations screen available in previous versions of Methasoft, and is now fully integrated with available Billable Services and/or specific billable Service Types as defined on the Billable Services screen. While some facilities use this screen to simply track Prior Authorizations, the Authorization Numbers are exported at the Service Line level (Loop 2400) to 4010 and 5010 EDI billing export files as required by a Payer, based on the date range of the Prior Authorization record and Start/End Service Line date range for the Claims being exported. Prior Authorizations can be entered at the Billable Service level without selecting a specific billable Service Type - this allows the authorization to cover all types of services associated with the Billable Service. If a specific billable Service Type is selected, then the authorization will only be exported for service lines of the selected billable Service Type, regardless of whether or not other specific Service Types are defined, or grouped for the Billable Service selected. This functionality allows for more granularity and flexibility in order to meet more specific Payer requirements.
Payer / Rate Group
This field is used for selecting the third party Payer issuing the authorization. The available selections in this field are all 'Advanced' Validation Level Payers entered on the Payer/Rate Groups screen. This field was added to this screen in Methasoft Version 6.5.0 or higher for the ongoing implementation of Coordination-of-Benefits (COB) Billing functionality.
Authorization Type
This field is used for selecting the billable service for which the authorization is being entered. The available selections correspond to the available selections in the 'Billable Service' field on the Billable Services screen. If no 'Service Type' is selected in the field below this field, then the authorization data entered will cover all service types for the billable service ('Authorization Type') selected. This functionality is by design to allow for greater flexibility and granularity when entering authorization data, and determines whether or not an authorization number will be stored for generated claims and subsequently exported to billing export files.
Service Type
This field is used for selecting the specific type of service for which the authorization is being entered. The available selections correspond to the available selections in the 'Service Type' field on the Billable Services screen. If a 'Service Type' is selected, then the authorization data entered will cover only the service type selected, regardless of whether or not other service types have been defined for the Authorization Type ('Billable Service') selected in the field above. This functionality is by design to allow for greater flexibility and granularity when entering authorization data, and determines whether or not an authorization number will be stored for generated claims and subsequently exported to billing export files.
Authorization #
This field is used for entering the authorization number provided by the payer for the patient and service(s) covered by the authorization. This is the only user-entered value on this screen which is stored at the time of claim generation and subsequently exported to billing export files. The authorization number entered in this field is exported to the data element REF02 (Reference Identification) in the REF (Prior Authorization) segment of Loop 2400 (Service Line data) on billing export files. The payer determines whether or not submitting this data is mandatory in order for the file to be accepted or the rendered service paid for.
# of Units
This field is used for entering the number of billable units covered by an authorization record. Interpreting the definition of 'unit' within this context often varies amongst different facilities and is ultimately dictated by the payer. The value entered in this field is for informational purposes only. When claims are generated and exported in Methasoft, the value entered in this field has no relationship at all to whether or not an authorization number will be stored for a generated service line and subsequently exported. Instead, Methasoft relies on the authorization start/end dates and date(s) of service to determine whether or not an authorization number will be stored for a generated service line and subsequently exported to a billing export file.
Start Date
This field is used for entering the first date on which the patient is pre-authorized to receive an eligible rendered billable service by a rendering provider (see 'Considerations' - When Billable Services are Rendered Before Receiving Prior Authorization Data/Approval from a Payer). The date entered in this field must match or precede the date of an associated service line in order for the authorization number to be stored for the service line and subsequently exported. The same is true for the End Date defined in the field below - in other words the date range of the authorization must fully encompass the date(s) of service date range in order for the authorization number to be stored for an associated service line and subsequently exported.
End Date
This field is used for entering the final date on which the patient is pre-authorized to receive an eligible rendered billable service by a rendering provider (see 'Considerations' - When Billable Services are Rendered Before Receiving Prior Authorization Data/Approval from a Payer). The date entered in this field must match or exceed the date of an associated service line in order for the authorization number to be stored for the service line and subsequently exported. The same is true for the Start Date defined in the field above - in other words the date range of the authorization must fully encompass the date(s) of service date range in order for the authorization number to be stored for an associated service line and subsequently exported.
Comments
This field is used for informational purposes only. Most commonly, facilities use this field to indicate whether or not an entered authorization record has received approval by a payer, and/or any pertinent additional information related to the authorization.
Payer Name
This column displays the name of the Payer selected in the 'Payer/Rate Group' field for each authorization.
Authorization for
This column displays the type of service (Billable Service) that has been authorized as selected in the 'Authorization Type' field.
Service Type
This column displays the sub-type of the service (Service Type) that has been authorized as selected in the 'Service Type' field.
Authorization #
This column displays the authorization number, assigned by the payer, as entered in the 'Authorization #' field.
Units
This column displays the number of billable units that have been authorized as entered in the '# of Units' field.
Start Date
This column displays the first date covered by the authorization as entered in the 'Start Date' field.
End Date
This column displays the final date covered by the authorization as entered in the 'End Date' field.
Potential Validation Issues
Currently this screen allows users to create Prior Authorization records that are invalid, either based on the patient's current Billing Episode (and thus associated Payer) or on the facility's Billable Service configuration on the Billable Services screen. For example, if an authorization is entered for 'Dosing' - 'Both', and the patient's current Billing Episode is associated with a Payer that does not have a Billable Service configured for 'Dosing' - 'Both', then the patient's 'Authorization #' will not be properly stored for associated Service Lines and subsequently will not be exported to billing export files, which could lead to export file rejection. It is important for all billing personnel at a facility to know what Billable Services are configured, and ensure that Billing Episodes are being properly maintained for each patient.
Entering Invalid 'Authorization Type' - 'Service Type' Combinations
Related to the Consideration listed above, the 'Service Type' dropdown selection field is not filtered based on the 'Authorization Type' selected above it. Thus the user must ensure that a valid 'Authorization Type' - 'Service Type' combination is selected. The easiest way to verify that a combination is valid is to refer to the Billable Services screen, which does filter the 'Service Type' dropdown selection field based on the 'Billable Service' selected (thereby preventing invalid combinations to be configured on the Billable Services screen).
Entering Prior Authorizations in a Timely Manner - Potential Workflow Issues
It is important that Prior Authorizations, including each's 'Authorization #', are entered prior to generating claims on the Claims Generator screen. Otherwise, the 'Authorization #' will not be stored for associated Service Lines, and thus will not be exported to billing export files. Thus it is important for all billing personnel at a facility to establish and understand the billing workflow at their facility, and effectively communicate with other billing staff members to minimize file rejections.
Editing or Deleting Prior Authorizations in a Timely Manner - Potential Workflow Issues
Related to the above 'Consideration', the same principles apply when editing or deleting a Prior Authorization, depending on when Claims are generated, exported and submitted to Payers.
When Billable Services are Rendered Before Receiving Prior Authorization Data/Approval from a Payer
This consideration is related to the two Considerations listed above. We have observed scenarios where the Payer is late in providing a facility with the appropriate Prior Authorization data before the billable service being authorized is rendered to the patient. Though this should not happen, and is fairly unusual, it can and does happen. When this happens, users should consider the workflow/timing-related items above. When this happens the facility is often required to delay generating Claims until the Payer provides the appropriate Prior Authorization data. Any disruption to a facility's typical billing workflow increases the likelihood of errors and subsequent file rejection or denied payments.
Authorization Start and End Date Considerations for Authorization # Export
To re-emphasize what is stated above in the Field Descriptions section, as well as reiterate an above Consideration - the only way an 'Authorization #' will be properly stored for Service Lines and subsequently exported to billing export files is if the Prior Authorization date range fully encompasses the Date(s) of Service date range for an associated Service Line.
The Old Billing Authorizations Screen can be Enabled if Necessary for Basic Authorization Tracking for Additional Charges
Some facilities were accustomed to tracking Prior Authorizations (previously called Billing Authorizations) for an 'Authorization Type' called 'Additional Charges', which is no longer available as a selectable 'Billable Service' on the Billable Services screen, and thus is not available for selection on the new Prior Authorizations screen due to the integration of these screens. If your facility cannot find a new method using the new functionality, and must continue to track 'Additional Charge' billing authorizations using the old screen, the old Billing Authorizations screen can be re-enabled in your system by a Methasoft Customer Support Specialist. The old Billing Authorizations screen is being deprecated, and the Development Team is working on potential solutions for integrating 'Additional Charges' with the new billing functionality.
Dynamic Enable / Disable, Cascading (Filtered) Dropdown Selections, and Required Field Functionality
This screen includes functionality that will automatically enable or disable fields, filter subsequent dropdown combo field selection lists, and/or require fields dynamically depending on the selections made in other related fields. For example, if no value is selected in a Secondary ID Code Type field, then the Secondary ID Code field will be disabled. But once a value is selected in the Secondary ID Code Type field, not only does the Secondary ID Code field become enabled, it also becomes required. An example of Cascading (Filtered) Dropdown functionality is when a value selected in one combo dropdown field determines which dropdown values are available for selection in another dropdown field by filtering out invalid selections. This functionality exists to minimize erroneous data entry, and particularly the generation / export of invalid EDI files such as the 837P, which will be rejected by either a clearinghouse and/or payer. This functionality is in addition to, and when applicable will override, initial required field functionality which operates when a New record is being entered, no data is entered in any field, and the Save button is pressed.
Claims Generator
Claims Generator - Edit Service Lines - Billing Service Line Management
Billing Export
Understanding the 837 Professional (837P) Export File Format
Loop 2400 (Service Line data)
Troubleshooting EDI File and Claim Rejections/Denials
Prior Authorizations
Billable Services
Service Lines by Claim
Service Lines by Service