Physical Therapy Billing Software

• The flowsheet itself would consist of a list of interventions and exercises along with the corresponding CPT codes. It would enable you to copy forward exercises, interventions, and charges from previous visits.
• On the flowsheet, activities performed on the previous visit would be automatically checked off. Therapists could select/unselect exercises, increase/decrease sets/reps, or otherwise update exercises and interventions as well as the daily SOAP note.
• The other component of the daily note is the SOAP note. The daily SOAP would enable you to roll forward the previous SOAP note.

• All the provider would need to do is to select the intervention, note the time taken if it is a time based code, and other modalities if used (like hot pack/cold pack, for example).
• When the flowsheet is saved, the system would automatically generate charges. While listing charges, the system would automatically itemize the correct number of units for time-based codes, along with modifiers like GP, KX, or 59 modifiers.
• System warnings would help direct attention to items that need a fixing. Some codes may not be supported by the patient’s payer class. These could be documented but no charges would be generated.

It is possible that some CPT codes being offered would not be billed on the insurance claim form. Examples would be selling over the counter goods and massage packages, these charges would go directly to the patient responsibility.

In the fee schedules, setting gross charge amounts and contracted charge amounts for a payer class would feed into reports like expected amounts for the payer class vs. gross amounts. When Medicare patients go over their therapy cap limit, the system would automatically apply KX modifiers. Contracted amounts would also be used in EOB and ERA postings that itemize charge amounts, contracted amounts, and what the payer paid. That would help verify if you are getting paid what you are supposed to be paid.

• The charge review report would highlight things that could cause rejections like charges that are missing an appointment, authorizations, or diagnosis pointers, Medicare patients over the Medicare cap, and eval appointments missing eval codes.
• Issues like missing diagnosis pointers could be fixed at the backend. Billers could also send charges back to the provider to have them correct data for the encounter. Anything over a typical 3-4 units per visit would be highlighted. The idea is to make sure that charges are as clean as possible before creating claims.
• The create claims process would bill all unbilled charges based on filters that are set (by account type, by provider, by patients, charges for signed off documentation etc.) to create a batch of claims.

• Processing claims through a scrubbing rule would validate them and would turn up red or green flags. Greens and reds could be split into separate batches with the green claims being sent out, keeping cash flow healthy.
• Issues in an individual claims batch like missing diagnosis pointers or missing authorization numbers could be analyzed.
• While previewing how the claim looks like on a HIPAA form, you could make necessary changes that would change the flag from red to green. Eventually, turning the entire batch green.

• Tasks could be added for billers or collection agents to follow up on claims if not paid in a certain amount of time. This would add work tickets for each individual claim in the batch to follow up on outstanding amounts at a set frequency.
• Expected collection timeframes would appear in a specialized dashboard for billers to coordinate follow up on outstanding claims. Claims status information would be automatically pulled in from the clearing house, extracting all information needed by the biller to follow up in just one click.
• Notes could be added each time a follow up action is performed like a phone call. This would provide a structured way to close out on outstanding claims while documenting the efforts and process.

• Most insurance carriers would provide automated ERA postings. These would be directly pulled into the system.
• When posting or allocating the money, all transactions and adjustments could be read along with explanations. Essentially, the system would read the ERA file and provide a visualization of how it is transferring the money.
• It would be possible to override amounts in the ERA like an insurance write-off along with notes on why the override was done before going ahead and posting selected payments and transfers. Updates could also be made after the fact in the future.
• Patient payments would be automatically adjusted against an available patient balance pool that was collected upfront.

• You could design how statements would look and control what types of patient statements or invoices are being created like statements for patients with unpaid patient responsibilities, for example.
• Creating a batch of patient statements would follow a process similar to the claims process. Delivery methods could be set for each batch of patient statements like electronic (patient portal) or paper (print on paper).
• Patients who have signed up for the patient portal would receive a text message and email notification informing them they have a balance available online. They can login to the portal and make payments.
• Statements could be printed just for patients who have not signed up for the portal. The integration with the external print service would provide “one click” print capabilities.