Today we’ll be looking at a Centricity table called AllocationSet. I’m the first to admit that most of what our Billing department does goes straight over my head, so I’m not going to pretend to know what an allocation set is. One thing I do know is that this table contains all the various copay amounts our patients might be expected to pay when they visit our practices and specialties. I also know that the way they’re stored is a reporting nightmare.
Continued from part two.
In this last part we’ll look at the Crystal Report and how we schedule it in Logicity. I’m hoping this project serves as an example of why, with the exception of very simple reports, I generally prefer to do my data processing in stored procedures, and only use Crystal for presentation.
I shudder to think what would be required to make this report happen using only Crystal. How many subreports and shared variables would you need? Instead, we have two somewhat complex but relatively manageable scripts that provide all the data we need to populate a very simple report. It wouldn’t be difficult to read through those two scripts and figure out how they work. If you put all that into the report itself, it would take days or weeks to get your head around what it’s doing.
Continued from part one.
Our objective with this report is two-fold: To list any patient visits with missing service charges, and to show any patient visits where it appears a “new patient” charge was entered for an established patient, or vice-versa. I’ll refer to this second category as “Suspect Charges.”
You might think that this would be an excellent opportunity to use the New/Established Patient column we added to PatientProfile. Unfortunately, it’s not that simple. That’s a computed column that returns the patient’s new/established status at the moment you select it. We need to consider the patient’s status at the time of the visit. If we’re looking at charges that have already been entered, all of these patients should come back as established. The question is, were they established at the time of the visit?
Management asked for a report, to be emailed to the office coordinators twice daily, showing any qualifying visits in the past 24 hours that were missing a service charge. In addition, they also wanted it to show any “new patient” charges that should have been “established patient” and vice-versa. They also wanted a copy sent to the practice managers on a weekly basis, showing any outstanding items from the past 90 days. This would allow the practices to stay on top of their charges and hopefully recoup some of the money they were hemorrhaging due to inattentiveness and human error.
Based on what shows up on this report every day, I wish I was being paid on commission.
I’ve used a number of report schedulers over the years. When I joined my current organization, they were using an application which I shall not name, developed by an Australian (maybe New Zealand?) software company whose name I shall also redact. I’m withholding their names because both their software and their company are god-awful and I don’t want to get sued. The few times I managed to get them to respond to a support email, I got the distinct impression I was dealing with one of two guys who had long ago abandoned their basement startup’s GeoCities website for steadier day jobs, and were rather annoyed at having to continue to monitor the company’s email account. It was clearly time to move on.
One of the biggest problems our Billing department deals with is incorrect service charges. I don’t claim to understand all the ins and outs, but I get the basic idea: There are charges for new patients, and charges for established patients. Put the wrong charge on a visit, it gets kicked back by the insurance, Billing has to deal with it. We needed a way for the staff to more easily identify a patient as new or established.
I hate the OBS table. No, actually I shouldn’t blame the table; I should blame the application that allows so much garbage data to be entered into it. If you’ve worked with the table at all (I prefer to go directly to the table rather than use the RPTOBS view, though the LASTLABS view is pretty useful), you probably know that you’re likely to find all kinds of things in there.
There are ways to save an individual document from a patient’s chart to a file location. But what if you had to export hundreds, or even thousands of documents? How do you export all documents of a given type over a given date range? That gets a little trickier.
You’ve been using computers for quite some time, I’m guessing. You’ve worked in dozens, scores, maybe hundreds of different programs. And in every one of them, when presented with buttons that say OK and Cancel, their behavior is generally consistent. OK commits whatever changes you just made and Cancel discards them. And by “discards them” I mean leaves you in the same exact state as before you went into that dialog or form and started making changes.
That is, unless you’re working in Centricity.