LigoLab RCM: An In-Depth Look at the Software (Video and Transcript)

Thank you for your interest in learning more about LigoLab’s fully integrated LIS and RCM platform. 

During this presentation, we’ll take you through our best-in-class software, and show you first-hand how this powerful encounter-based workflow structure combined with over a million rules and automations, and our extensive, highly transparent and user-friendly features will help you increase clean claim submissions, improve operational efficiency, and increase productivity, revenue, and profit. This helps mitigate compliance risk and avoid future bad debt, differentiating labs to be viewed as true leaders in the increasingly competitive marketplace. 

The industry is continuously evolving now more than ever, and effective risk management is critical for success. And the LigoLab platform gives you the powerful tools to do exactly that. These include powerful automations and rules, unparalleled clean-claim scrubbing and extensive third-party integration, a consolidated single data entity queue-based workflow structure with interwoven billing logic throughout the entire LIS RCM life cycle, extensive audit recording tools providing transparent workflow and compliance management, accounting insight, powerful reporting and distribution engines that ensure operational integrity, intuitive user visual interface and truly patient-centric solutions and unparalleled customization capabilities. All supported by gifted developers and a dedicated client support team. 

The entire billing workflow in the LigoLab RCM platform works with real-time queues. All queues are live so no encounter gets lost in the process. They allow for strategic distribution of work and include intelligent and convenient filters as well as template creation capabilities. With LigoLab’s intelligent RCM module, you gain full transparency and control of billing workflow with upfront patient demographic and insurance eligibility check, insurance discovery, real-time workflow queues and reports, extensive clear audit trail functionality, and automated CPT and ICD coding, all to provide proactive mitigation of denials and rejections. And this leads to increased revenue and profit. 

We and our customers who use the LigoLab LIS & RCM platform, know that it's in a category all of its own. We not only combine your laboratory and billing operations, but we also make your workflow better, faster, and cleaner, all while effectively managing your entire operations compliance risk, enabling exponential profitable growth even during the most volatile and evolving times.  So, let's jump right in and go through the system. 

We start with the billing encounter. As mentioned earlier, the billing encounter is a data entity in LigoLab’s RCM module that consolidates all financial and workflow-related information in a well-organized, intuitive, heavily automated, and user-friendly data structure. This data entity consolidates and provides access to lab orders, test results, reports and specimen data, imaging data and all claim statements, invoices and relevant detailed audit information as well as remittance and accounting summaries. 

The billing encounter consists of several tabs. We start with the main tab here lists all diagnosis and CPT data as well as encounter claims, statements, and invoices. In the diagnosis section, we have diagnosis data, add, remove, and make primary user actions. In the encounter details section, CPT and test panel data and add remove user actions are easily accessible. 

The main tab consists of a CPT sub-tab, as well as a test panel sub-tab. The CPT sub-tab lists the following items, CPT codes, units, DX sequence and note the order of the DX pointers is based on NCD LCD coverage policies modifiers, the rendering facility, the rendering provider, the primary payer and the place of service, and the test panel sub-tabs tests and panel if any. And note that the billing and counter data entities provide two types of financial summaries: basic and advanced. 

Here we see the finance summary tab. This represents a financial summary per CPT code for all claims and lists a current responsible party. And we have the finances summary advanced tab. This shows expanded financial and processing history for all claims and claim data. 

Then we see the claim section here lists all claims, statements, and invoices in a hierarchical structure with corresponding data summary and status. The adjusted column here represents an adjustment activity for all remote responses. The add claim function lists all payers that are listed on the encounter, and it offers operational right-click user actions. And all claims here are also available for individual review and editing. 

The demographics tab includes billing and LIS sub-tabs and is a summary of all patient and payer data. The billing sub-tab here in the top section contains some useful functions including an ordering provider override function, a patient class menu, and an order DX system validation field that lists the current diagnosis listed on the billing encounter level. The bottom section is split into patient data, billing data, and supplemental data sections. 

In the patient data area, we have all patient data plus USPS, and white pages address parsing and validation tools. So, as you can see, our third-party integrations are featured here as well. In the billing insurance data, a payment source menu lists payer options and payer data that are available for review. And a user may add, remove or alter the payer or payer sequence here. And no eligibility check is run from this tab directly. In the supplemental data section, we have various fields such as date of injury, comment box, etc. And this section is customizable, so custom fields may be deleted and or added. 

The sub-tab here in the top section lists various LIS data such as collected date, case priority, and patient info as collected during creation. And the bottom section contains all payer information collected at order creation with the eligibility button here as well. specimen tab. This is where all the specimen information can be accessed. specimen data is organized in a tree format and may be expanded and collapsed. Both primary specimen and derivative specimen with details relevant to the coding workflow are listed here. And right-clicking on the specimen ID and specimen name open a very elaborate user action menu. 

Order data - this tab provides access to LIS data. We have all sessions in a tree format that you may expand, collapse and search data. Plus, you can open the order data entity directly from here. And note the tree format levels down to the session report results and CPT levels. Right-clicking on either level here accommodates many useful user functions. audit tab, the audit tab stores workflow-related encounter data summary as well as automation information. In this tab, users will find workflow and review stages audit information and history such as information about current encounter location. And in the additional fields section, we have external ID and external encounter ID as well as billing pattern data. Additional fields here are customizable, so they too may be deleted or added per client request. 

Report tab. This provides users with a floating capability for workflow and visual convenience. Here we list all reports for the encounter with each having its own tab, and each tab title will show an accession number and the report name. The top of the tab allows for visual flexibility, so you can enlarge and zoom in or out. Scans tab. This tab also provides a floating capability for workflow and visual convenience. Attachments listed here are available for visual flexibility. And here too, you can enlarge and zoom in or out, and they too can be reprinted right out of LigoLab and saved locally, and sent to imaging processing. In addition to billing encounter data, we also have an event tab that lists all billing review-related and claims submission-related events. It also displays scrubbing and validation system messages, and any error notifications that take place after the encounter creation. 

The special actions menu. This allows for the execution of many important user actions, such as insurance and discovery. And we have tags. These enable users to tag as many cases as are required, providing improved organization and clean delegation of work. And then we have workflow actions, which are labels that assign specific tasks and are handled in their respective workflow action queue. And last, we see data panels. Here we provide custom data expansion of the billing encounter data entity workflow queues. 

Now we delve into the workflow queues. The entire billing workflow of the LigoLab RCM module is handled in workflow queues. All queues are live so no encounter gets lost in the cracks. They allow for the strategic distribution of work. And they have intelligent and convenient queue filters, template creation capabilities as well as queue-specific data validations. And there's also a maximum row to display regulation and both tags and notes to promote quality workflow. 

We start with the demographic queue. The demographics queue is the first stage in the workflow where patient and payer demographic verification is performed. In this queue, we have multiple filters that allow for extensive case navigation, such as in the main tab we have maximum row limitation, as well as payer and template filters. In the extra tab, we have tags, result types, and test filters. And in the advanced tab, we have workflow-related filters. In this queue, the system also performs many types of demographics cue-specific validations that reduce user errors, such as missing patient, gender, patient class, or payment source. 

We offer third-party integration to locate and verify patient and payer data. This address lookup is through white pages. The white pages tool will locate all known addresses for the patient and will reference them with age and gender and will provide a phone number that is found and your data gets auto-populated once a selection is made. And we have address format verification through USPS. They are all real-time, and fast and accurate. The USPS tool will validate all components of the address listed including street name, street numbers, etc. And they’ll locate the last four digits of the zip code if the user did not include them. Here as well, data gets auto-populated once a selection is made. 

You can locate insurance coverage through insurance discovery. Insurance discovery is a highly effective real-time interface tool. This tool will locate active insurance coverages for a given patient. By sending a query ‘directly’ to the payer, it will detail the data and auto-populate it within the payer source fields. With this feature, you get a tremendous time saver for your billing staff. It works with all major payers, and due to its direct real-time connection, parsed data can be trusted to be accurate and updated. And it also provides automated sequence designation. And the insurance discovery tool is also an effective coverage verification tool, verifying data such as subscriber ID, payer address, patient name, etc. 

As it interfaces with the primary source, the payer, and interesting to know for some encounters, we can facilitate a rule-regulated demographics queue bypass. For some cases, we can implement a cool-off feature, which will hold encounters in a limbo state if they are pending information or report release. 

And finally, we can arrange for automated eligibility checks and cases in this queue will be already verified automatically. Insurance eligibility. This too is real-time and is performed through a clearinghouse that has a real-time interface with an insurance payer community. 

The eligibility response format is designed to display in an accessible and strategic format showing all relevant and important insurance coverage data, including coverage disqualifiers, limitations, deductibles, or coinsurance. The rule engine in most cases will label the ER as eligible or ineligible and update the status accordingly on the encounter level. Users are even able to see the status without having to open the eligibility response. In some cases, it will indicate that it needs review, which requires the user to manually review eligibility data that the payer sends back. The status can also be overwritten manually. 

The rule engine parses a Medicare secondary reason required for claim submissions from the ER. The eligibility response may provide to the user secondary and or tertiary payer info, if any, and provide payer sequence verification, which prevents payer sequence conflict denials. The eligibility response also provides a vehicle for verifying vital claim data, including patient name, subscriber ID, current address, etc., and users may expand or collapse as well as search. 

Coding queue. The coding cue has extensive convenient and powerful tools. Among primary operational functions here, we have a manual selection of diagnosis, CPT test panels, and manual claim creation, as well as automatic coding and automatic claim generation. And at the core of the complex functionalities in LigoLab is change line item modification, which is performed through the elaborate coding automation that we offer.

Here we see the automatic assignment of modifiers diagnosis sequence, diagnosis pointers, units, as well as both rendering facility and rendering provider data. Our coding automation also performed unit aggregation, TC/PC splitting, and diagnosis sequence assignment. And in addition, here we accommodate panel test and hybrid client billing formats. And we have clean claim scrubbing based on CPT, MUE, and NCD/LCD regulations. The system can also perform payer-specific scrubbing based on individual insurance requirements. And of course, there are also extensive coding cues, specific data validations that pick up any missing field criteria, such as gender or diagnosis to prevent users from completing coding review, which greatly reduces user error. Here we see in this example a scrubbing event and an invalid DX notification represented by the highlighting of the panels. 

In this example, we have TC/PC splitting. And here a coding queue-specific validation that indicates an auto-billing issue is shown. 

Billing review queue. The billing review queue is the conditional queue in LigoLab where conflict resolution between LIS and RCM modules is handled. Whenever some kind of billing-related change takes place on the LIS side, the system detects it, and it places the corresponding encounter in the billing review queue for user verification. Examples of issues are CPT added/removed on the LIS side, test added, order sync issue, cannot auto-bill, and no bill generated. 

The filter ‘encounter flags’ is the operating filter here. The relevant issue is recorded in an encounter event with a timestamp and corresponding detail. Some issues in the queue are easily resolved with a simple right-click, for example, extract CPT’s. And more examples of billing events are insurance pre-authorization and billing event issues. And no bill generated. So as you can see, the billing review queue is a very useful tool that allows for the monitoring and management of LIS to RCM dynamics. 

Payments queue. The payments queue stores posted payments that were received electronically or were entered manually for user review and finalization. In this queue, we have filters that allow users to view data by user date created, issue date, or payment mode. Users here are able to review and edit an individual payment. Users are also able to consolidate payments into manifests, which are equivalent to batches in LigoLab.

And lastly, as you can see, you can preview and print any manifest collections cue. Our collections queue has a very compact and simplified workflow. And certain claims that are qualified for collection are updated automatically with status late and populate automatically into the collections queue. Inside this queue, users may filter line items with a status filter to organize the workflow and approve or reject cases individually or in batches. special rules may be configured to automatically adjust collection accounts based on the outstanding balance amount, associated client date of services, or any number of specified criteria. Approved cases will advance to the collections log, which may be made accessible to a respective collection agency via interface setup. An alternative workflow to this that is also available in LigoLab is exporting and printing a customized excel report of course collections cases and providing it to your collections partner. Here a right-click user action inside the queue allows for many options, including an assignment payment plan. And for the collections workflow, one or multiple collection agencies may be accommodated. 

Important to note, the LigoLab application is able to accommodate two types of workflows, one that ends when an account is placed in collection and passed along to the collections agency, and the other when the entire cycle from ‘status-update’ to ‘account resolution’ is entirely covered in the LigoLab platform. Refunds to patient claims automatically populate in the refund queue if there is a negative balance. A single operating filter refund status here has a few options, confirmation needed, refund completed, refund rejected, or refund requested, which when used allow for clarity and easy dissemination of work. 

The workflow consists of a few stages. First, the refund has to be confirmed. Here you view claims under a confirmation needed status. This is a manual process of review, after which the user designates either request refund, or, if this is not a true refund, balance the claim, the adjustment, and get the balance to zero and the claim will vacate the queue. 

Second, if a refund is confirmed, an accounting professional is able to issue a refund through an applicable payment format, and utilize a template for a credit letter, which is a customized document with a reason for the refund. The status for the patient claim will then change accordingly to refund requested and this case will be found under refund requested. 

And lastly, for refund request cases, we allow for issuing refunds via an issue refund manager operating window. After a refund is issued, it is recorded on the patient claim level accordingly with refund complete status and the claim balance is set to zero. Rejection queue. Rejection events populate automatically in LigoLab and claims that are rejected are routed here accordingly per their status. Rejected claims with rejection events from both clearinghouses and insurance payers are presented here. Rejections are handled in this queue and when users complete rejection review, the claims are resubmitted to the clearinghouse automatically. 

Inside the queue filter, rejection type, and rejection code, each with a case count, one is able to organize and manage all rejection cases. We are also able to design and implement any client-requested method of rejection profiling. Rejection events are available on the encounter level in the remit activity tab of the insurance claim. And as you see, rejection events archive or rejection in detail with a timestamp source, entire internal rejection code message, and rejection type. Remittance queue. The remittance queue in LigoLab is where denials are managed and resolved. Claims are routed here automatically according to the remit codes listed and their respective remit strategies. Claims that do not require manual review do not populate here and are archived in the system. 

This queue is broken down into sub-queues, most of which are titled after respective remit codes and some are titled after the issue they represent. Additional sub-queues might also be created and named after an individual that is in charge of monitoring them. And any of the cases can be easily relocated from one sub-queue to another. 

The remittance queue has intelligent filters that include payer filter, client filter, etc. Plus time-saving template creation options. Here a count for each sub-queue is shown in the remit filter. So, users can identify work volume for each sub-queue and we have the ‘sort-by’ option for populated results and then the reprocess function. This is utilized when you alter a permanent remit resolution strategy and is retroactively applied to all applicable claims in the remittance queue. 

And note for remittance handling we have added a strategy that alters the remit strategy for the relevant remit codes permanently. And as you can see, we also have a create one-time strategy option that alters the strategy for that specific case. Established remit strategies for remit codes are assigned automatically and are easily differentiated and are clearly visible on the claim level. Labels like adjustment, patient responsibility, and also need review are utilized in LigoLab. Many user actions that are relevant to denial handling are available on the encounter level from within the remit queue such as assign the remaining queue. And lastly, as you can see, claims that are currently residing in the remote queue are highlighted in red in the encounter. And that will show no matter from which locations the claim is opened. 

Remittance strategies. The most important aspect of denial handling in LigoLab is what we call a remittance strategy engine. It allows users to establish a remittance handling course of action for each remit code based on detected insurance payer processing patterns and trends. This involves what sub-queue within the remittance queue the case will be allocated to, what strategy label such as ‘needs review’, ‘adjustments’, etc., will be assigned?  And finally, what rules if any, will be involved in handling that specific scenario. An unlimited number of remit strategies each with its own label can be created for a single remittance code, and each may be as basic or as complex as the user requires. 

For example, you may choose a specific payer remark code, CPT code, or payment rate to outline a scenario and it will be handled accordingly in the background with our automation mechanisms. An example of a written strategy you see here is one that was configured for remit code co-45. It covers two scenarios, one with co-45 on the remittance response, and the other co-45 with zero payment as a single condition. Supplemental queues in LigoLab include three supplemental queues. The first is the demographics request queue. This queue accommodates a resolution of demographic issues, such as patient or payer issues that are discovered mid-workflow and manually requested for demographics review. Then we have the payment queue incomplete. This queue is intended for payments that are entered but are pending clarification or in need of additional data. Cases here will be preserved for later review. And last we have the EOB review queue. This queue is meant for insurance claims that received conflicting or erroneous remittance responses that the system cannot reconcile and manual review of these cases is then performed. 

Our reporting module supports both statistical and linear reports with extensive customization capabilities, and any and all reports that are produced by the system can be exported as an excel sheet or a PDF document. 

We start with dynamic reports, which are customizable high complexity reports. Here we see the whole workflow action report with multiple columns such as status, created, time created user, etc. Any report of any structure can be designed for specific client needs. Reports may be expanded or collapsed or filtered by dynamic format filters. And reports may be printed, previewed, and saved as excel files or PDFs. 

Then we have dashboards. dashboards in LigoLab allow for users to easily view all types of data such as billing, workflow, productivity, accounting, and revenue. Widgets in LigoLab take group data and represent it in any desired format. And the dashboards are then loaded in real-time. We have many dashboard widgets, including daily coding, daily remittance, auto-billed today, total count, and payer aging just to name a few. And any other dashboards can be configured upon request. Examples of dashboards include billing queue throughput, client delinquent 60 days, patient delinquent 60 days, and queue count. 

Finally, we see the financial stats section. This section provides executives with three major types of reports: A/R reports, KPIs, and the posting activity report. And each may be organized in any format with the utilization of multiple filters located here. Users may view data in flat or tree format and can expand and collapse as well as drill down. 

Here we see all AR posting activity for a time interval of the last 60 days. These powerful reports are structured to produce pivot table-like functionality, providing in-depth analysis of your business operations, productivity, and financial efficiency. The AR report provides detailed accounting insight in a time-based format. This enables users to clearly see all receivables within any given timeframe. Multiple filters and sorting options are also available. The KPI report is a very helpful financial tool LigoLab provides. It enables users to review a multitude of KPI indicator-based commonly used report structures. And here we have a variety of filters that support different presentation models and combinations of data. 

The posting activity reports allow users to view a reliable representation of immutable posting data within a specific point in time or date range. The comprehensive summary by filter includes CPT ordering clients, date of service, posted month, etc., and enables users to model representations of data that are highly transparent, and tailored to accommodate very specific and data-intense reports. Additionally, a strategic manipulation and grouping of other filters in this section produce distinct types of reports that serve user’s needs. Finally, any combination of filters can be saved as distinct templates to be used at any time. 

Distribution engine. Our distribution engine supports all LIS distribution channels and includes the following features. Patient statements or client invoices are created automatically on the fly. Flexible distribution allows for remote and local printing of patient statements and client invoices. Distribution is facilitated through fax, email, mail, and client and patient portal capabilities. And integration with a third-party mailing company to mail out patient statements is also possible with LigoLab and client daily notifications in addition to monthly client invoices, you can be set up for automated recurring notifications if desired. As you can see, both client invoices and patient statements can be highly customized operations modules. 

In LigoLab we have three posting utilities. Post payment, which is intended for client patient and collection payments, post EOB meant for insurance and EOB posting exclusively, and the reconcile payment function which is used for financial reconciliation procedures. And Important to note, for our posting purposes, we have a direct interface connection with a payment gateway. The reconcile payment function in LigoLab is intended for reconciling any and all payments against a client's banking activity and is conducted in the reconcile payment window. This assures the linking of the system payments with the bank deposits. 

One option is to upload a file received from the bank and conduct the reconciliation process automatically. Another option is to individually reconcile payments with bank deposits already reported in the system. Users may search payments by payment amount, deposit date, or payer name, etc. And the system performs a search for unreconciled or reconciled payments with the single or multi-criteria you provide. The system will locate individual payments or manifests that fit selected search criteria. 

Search section. The search section in the LigoLab RCM module allows for locating any of the systems data entities with sets of strategically placed filters. Right-clicking on any located record offers the option to review or edit in the sections display. We have multiple search sections. These include finances. Here users are able to view global financial data and filter extensively with or without posting details. Insurance claims. Searching insurance claims plus the aging option and the aging tab allows your user to monitor claims that did not receive a response patient statements. Here users are able to view native and legacy patient statements of any status, including those currently in collections. 

Client invoices. Users are able to view client invoices by status, client account, or created and build date. Adjustments. Users are able to view adjustments of any kind, regardless of the associated data entity, and create a search template payment. Users may search and edit any payment and use the filter selection of the reconcile tab to show reconciliation-related criteria. And lastly, bank deposits. This is a vehicle to search for bank deposit items with an option to import directly from the bank database. 

Our special payment projections feature is also accessible in this third section. The payment projections feature will show payments that are anticipated to come in from insurance payers up to seven days from the current date. An example of that would be specifying the current date as a “from issue date” and not specifying the to date. By sorting your results by issue date and noting the electronic method of payment delivery, you will see what will be deposited electronically from specific payers on any given day. By reviewing the total amount of deposits in the lower right corner of the section display, you will know the total of what will be deposited for the time interval collectively. Notably, the data a user is able to view the next day or the day after may include even more payment items. So daily check is very effective here. And because all our financial cues are updated every few seconds, this information is accessible and is renewed constantly. 

Statistics. The stats section provides users with the ability to run extensive statistics on primary and secondary data entities in the LigoLab application. 

Encounters. This section addresses a primary data entity in LigoLab, the billing encounter. Users here are able to run statistics that are workflow-related with extensive queue input-output visibility, and are user-centric but may also involve the responsible payer or automation aspect of the encounter processing. This section essentially allows the user to closely monitor any and all aspects of workflow efficiency within the LigoLab application. 

Finances. This component of the statistics section is an extremely versatile tool that may be utilized for extensive financial analysis. And we will address this section later and further detail. 

Insurance claims. The insurance claims section here is focused mostly on the insurance billing workflow and remittance processing. Filters such as status, in remit queue, or is resubmitted allow users to monitor various stages of claim submission and post remittance dynamics. 

Patient statements. The patient statements section provides users with the capability to monitor patient billing-related workflow and payment status with filters such as build date, date of service, status, payment exists, etc. 

Client invoices. The client invoices section of financial status gives users the ability to view client invoice statistics by created date, status, etc. The summary by filter expands users’ options to design the format of the statistic structure they may prefer. This ensures full transparency of laboratory client billing adjustments. The adjustments sections of stats address user-initiated, as well as insurance-applied adjustments recorded in the system. Importantly, this particular tool analyzes the entire adjustment culture for your business and allows company executives to gauge the integrity of manually discounting and write-offs and related logistics. Additionally, with the insurance payer filter, billing professionals are able to determine and monitor the adjustment trends of specific payers to model respective billing practices accordingly. 

Payments. The payments section here is very accommodating and comprehensive with the summary by filter allowing for many format manipulations and extensive filter options also allow for increased flexibility and details in viewing payments statistics. 

Financial activity report. Finally, the financial activity report in this section is a uniquely powerful tool that provides a fully inclusive financial summary for the current year's month-long time interval. Here we see indicators such as bad debt, refunds, etc. And we see references regarding the same month of the previous year. This PDF configured report template can be altered to the client's needs and may be viewed and printed on the fly with the utilization of the preview function. 

Pricing policies. We have many diverse pricing policies. Users are able to assign pricing policies to individual insurance payers, clients, or patients. They may be assigned manually or configured to follow a rule and they can be assigned per CPT test or panel. An example of an insurance pricing policy is Medicare physician. 

The pricing policies in LigoLab are very flexible and are set up by terms that cover a specific time interval with effective dates specified, and you may have as many terms as you need. With our import function, clinical and physician fee schedules may be used as a base for a pricing policy that can be automatically uploaded. The setup works with a hierarchy child-parent policy relationship, where discounts can be accommodated for any scenarios using a multiplier feature. And the other category is the client pricing policy. Client accounts may have their own manually configured pricing policies or go off of existing parent policies. And all pricing policies globally or per test may be altered at any time as well as applied retroactively. And client pricing policies may be applied on a single client level, group level, or client account level. And the third category is patient policy, such as in this example, default patient. 

Client billing. Client billing in LigoLab is set up in terms of a hierarchy as well, client billing to a group or to a specific client. We are able to produce a highly customized client invoice. Any design is achievable, and any template may be implemented. 

The client invoices in LigoLab have features like client billing history listed in the invoice document. Data may be grouped by location or physician or LIS data components. Each invoice has a summary page at the end. And the combination of data that the client invoice includes may be expanded or reduced. Client billing in LigoLab also involves elaborate notification schedules with a notification format template setup. Multiple distribution channels such as email, fax, EDI, etc., with flexible options of rule-regulated distribution, secure invoice distribution via email with the subject line, email content options, and secure password setup. And any portion of a client billing can be automated, which will significantly speed up your revenue recovery. 

Billing policies and CPT bundling.  The LigoLab RCM platform fully supports the bundling of sets of CPT codes, assigning an appropriate alternative consolidating CPT code automatically as soon as the applicable set of CPT codes is designated in the order record. And because the bundling is facilitated by a flexible group of rules, it is possible to add supplemental conditions such as specific payer-provider or any relevant variable. 

Here we have a default bundling policy and a payer-specific policy catered to United Healthcare insurance. So, as you can see, we can create many payers’ specific policies on the fly. In this example, for a renal function panel, the mechanics of bundling are clearly outlined. And the consolidating CPT code here is 0076. 

Rule Engine. The LigoLab platform has a highly effective rule engine in place that addresses many functions. One of the branches of our rule engine involves auto coding. Our auto coding rules increase coder efficiency by automatically populating CPT codes and assigning diagnosis priorities. They facilitate 100 percent automation of less complex lab cases and eliminate the need for human intervention. They ensure extensive client billing automation, which can be up to 100 percent. They expand insurance auto-billing with the utilization of the billing patterns feature. And they allow for TC/PC splitting rules to be run automatically, which is a tremendous time-saver for coders. 

Here you see another example of TC/PC splitting. And here we see a client-requested billing rule. The main condition in regards to the contract with this client indicates that if Kaiser is the primary insurance payer, they are to be billed. If not, then a TC/PC split is to be initiated automatically with clients and insurance. As with remittance strategies, any scenario more or less elaborate can be accommodated through an associated rule. 

Another component of our rule engine is our claim scrubbing mechanism. Claim scrubbing rules in LigoLab handle a multitude of issues upfront to mitigate future rejections. When insurance claims or built, default systems checks are run, but also any custom rules that the client needs can be implemented. 

Here we see an example of a claim scrubbing rule that involves billing insurance codes. Here this rule established that if any insurance claim besides Medicare lists codes, the system will prevent the claim from being billed out to the payer. 

And finally, we have billing patterns. Billing patterns work in conjunction with auto coding rules to automatically build out a case with zero human involvement. Our billing patterns are currently being heavily used for COVID cases. Billing patterns check the following criteria when certain tests were ordered, and with a certain result status, such as abnormal and normal, when certain CPT codes were performed on the results, when certain DX codes were used on the results, or any were used, depending on the scenario. So as a result of outline auto coding rules, the CPT codes matching the exact criteria will be generated. This rule indicates that a COVID case gets automatically billed for six specific insurance payers listed here. Auto-coding assigns a CR modifier and a matching rendering facility provider. Additionally, COVID policy grants that the use 0003 CPT code is covered according to a specific coverage policy. If any condition mentioned, for example, use 0003 is not covered, or see our modifier wasn't assigned, then the cases get sent to the coding queue for manual review. 

Patient billing/ patient payment processing. Patient statements in LigoLab are highly customizable and may be delivered through multiple channels, including email and text. Notifications also may be established for payment reminders via multiple channels such as SMS, email, mail, etc. Users may manually alter the patient billing workflow by prompting the next transition date, forcing the next billing stage, or holding statement distribution. And LigoLab has a bi-directional interface with a mailing company that performs hard copy statement printing and processing of undeliverable addresses. 

Patient portal. Importantly a patient statement features a unique pin number that is utilized along with the patient's last name to locate an invoice on the online patient portal. Manual payment processing such as when a patient calls in is conducted in a very secure manner with card or bank data not saved in LigoLab, but rather captured outside of our platform. And the payment that is made via the patient portal is posted within seconds in the LigoLab application. 

The patient billing policies in LigoLab are very flexible. Flexible rules may be created to facilitate discounts or fees for statement applications. These discounts and fees can also be removed or reapplied based on any given scenario.

ABN feature. The ABN waiver of liability or advanced beneficiary notice is a unique component of medical billing as it applies to Medicare and at LigoLab we have a special rule specifically designed to address this workflow component. This rule fires right at the order entry before any of the billing-related workflow stages commence. When a collection of patient information occurs, and the patient insurance is designated as Medicare, and the CPT and diagnosis data meet the rule-specified criteria, an ABN form generation takes place. This ensures an option to facilitate ABN-specific procedures. 

As you can see here, the patient insurance is filled in as Medicare and the diagnosis is not specified. So as soon as the user proceeds to save the order, and ABN form is populated, with an option to preview and print, so to be scanned in after the patient signs it, and saved as an attachment for the related order. This ensures that the patient consents that they are legally liable for laboratory charges and will reimburse accordingly. With this feature, the laboratory is guaranteed to properly collect for their services.

Adjustment templates. The adjustment templates function is a unique tool in LigoLab that is designed to assist users in the organization and management of the adjustment-related billing workflow. in selecting an adjustment template, users are able to specify an adjustment type, as well as include a prefilled or custom memo. Additionally, users are able to specify a percentage for the amount of adjustment and it will be calculated automatically. And finally, the rebill option, if employed, will automatically rebuild associated charges. 

The adjustment templates feature may be utilized in insurance billing, as well as patient and client billing. Notes, tags, and attachments may be added for a created adjustment item. The strategic adjustment template application allows for organized management of billing, reinforced remittance processing, and efficient archiving of applied manual adjustments. An example of an adjustment template you see here is titled low balance. This adjustment template is used for low-balance patient statements. It has a default memo and stipulates that 100 percent of the balance is to be adjusted audit trail. 

The audit trail function is a special and very helpful feature in LigoLab. For each data entity in LigoLab, such as a billing encounter, insurance claim, patient statement, etc., users are able to view an audit trail, which is a full archive of manual and automatic events that took place. The audit trail covers entity modification, entity automation, entity creation, changing status, workflow activities, and reviews, and is intended for mostly workflow analysis and case investigation. The audit trail not only tracks who touched an entity but also clearly shows what was recorded, at what time, and by whom. All while showing the previous and updated values of each change. So, it's a complete forensic tool that locks in every touchpoint for a future look back at any time. This function is available on the right click of individual line items from inside of the queue, as well as from within the relevant data entity via the special actions menu. 

We also have an audit records feature accessible in the administration menu on the top pane of the application. It's equipped with four filters: entity, user, action, and date. This function allows the user to locate any entity in question for review, or to correct as needed. This function is mostly used for scenarios where a user needs to revisit an entity recently worked on for clarification of some kind, or for correction. 

As you have seen, the LigoLab RCM platform is a powerful software product that provides full transparency and control of your billing workflow. Our fully integrated real-time queue facilitated workflow design with powerful interwoven billing logic and clean claims scrubbing automation gives laboratories the tools they need to increase productivity, mitigate risk and improve compliance. And this enables you to increase both revenue and profit and efficiently scale your business. 

We hope you've enjoyed this presentation and it has provided you with a granular look into the power behind the LigoLab platform. We thank you for your time, and we look forward to discussing how we may assist you in further streamlining your business and achieving your growth initiatives.