Subscribe to RSS feed

Thomson to sell Ascent

By now, most of the clients have heard that Thomson-Reuters is trying to sell its healthcare division.  The News Release 6/6/11 made it sound like they had a buyer and would divest by the end of 2011.  I’m interested in what you have to say about this.  Will you be likely to hope Ascent gets a new owner and sticks around?  Will you expect support to get better? or worse?  Will you change any of your plans for replacing Ascent – hurrying, delaying, or no change?

Contract Management System – Reporting Metrics

Question: 

Hi Jodi.  Can you tell me what a few key reporting metrics are in the area of contract management and underpayments?  We currently have our contracts programmed in the AR system (EPIC) but may end up utilizing a bolt-on system because EPIC reporting is not very developed. There is some discussion here regarding what metrics should be reported. I wondered what other facilities deem the most useful metrics in the area of contract managment.  We are looking at Concuity and the Medassets products to begin with. Appreciate your thoughts.

My Answer – - and I go could on!

Now to answer it briefly. Or try. I could probably write a book on your question alone – - no kidding. I am familiar with both Concuity and MedAssets as well as the rest of the list on my website. Don’t miss JDA, Sure Decisions, PMMC, and Kreg. They are all worthy of discussion and it all depends on your business needs. Links at http://www.bloomroad.com/links.htm

Metrics:  your business drivers will dictate your metrics and reporting needs. Many times a Contract Management system is supplemental to the AR reports, and sometimes it is the backbone because these bolt on systems are, by their nature, in a database that is easy to query. Most of them are either oracle, Sybase, SQL-Server and most vendors provide a data extraction tool or an ODBC driver – - with the last option you are home free to reporting.

The Basics of Contract Management System reporting can be broken into the functional areas that will use the system and its data. I do have some specific metrics that I’ll clean up and send you also.

  • Executive/Finance – Overall summaries and trends of payor activity, denials, recovery.
  • Patient Financial Services – Transactional queries to manage operations.
  • Managed Care/Payor Contracting – Profitability, Yield, and Variance by Payor
  • Revenue Recovery – Variance for Underpayments and Denials

All of these are based on some spin off of the calculated expected reimbursement and the actual reimbursement. Some systems break out the expected into components that can actually be matching to the payment/remittance, others it’s just one figure that then leads to investigation and discovery of those components. At a high level, start with variance reports, both detail by account and grouped by logical payor grouping whether that’s financial class, contract group, or insurance plan code. Sometimes you set this up by all of those. I’ll be posting some more reports on my website for samples. A few are on the Bloom Road  home page.

Managed Care and Executive Needs – - Looking at all payor data you can determine payor mix volumes both % and $. Adding in cost data you can determine profitability. Those summaries form the basis for contract evaluation and renegotiation.  Contract Management Systems can also do modeling/projections of contracts in negotiation, so you can compare the actual to the projected and negotiate from a real position of data strength.

Patient Finance and Revenue Recovery – - Sometimes you want to compare contractual variance and sometimes payment variance.  If possible, show the expected patient responsibility. Already we are talking about several reports.  Group these reports into unbilled (DNFB), unpaid, and paid. I have some samples on my website and more coming all the time as I figure out what’s most useful to those looking for ideas and help.

I know I have not simplified this process but it can start out simple. What are the biggest business issues? How might data help in finding answers to help solve those issues?

Systems we support

I often get asked which systems we support.  The truth is, we support all of them. Because the systems are basically doing the same things, the data is not all that different.  There are nuances, to be sure. We are confident that we can help you no matter what system you use.  Our goal is to make your day better through applying our expertise to your siutation. If you look at the http://www.bloomroad.com home page or the links page you’ll see a list of the systems.  Just ask us about any of them.

Fixing a table link to avoid duplicate records

Recently I had a request to fix a report that was showing an account number twice.  This was in a Crystal Report, though the concept and solution apply to any relational database.  There were two tables on the report, a PATIENT table and a PATIENT-INSURANCE table.  While the PATIENT table had only one account per record, the PATIENT-INSURANCE table had a record for each level of insurance – primary, secondary, third, fourth, etc.  So even though the selection criteria specified only a specific insurance, if the insurance was both primary and secondary we would get two records.  Now you might ask if this happens often and the answer is no. However, the principle of joining and multiple records happens often.

I have seen people try to simply suppress duplicate records, however this still includes duplicate values in any totals on the report.  It is necessary to not select the duplicate records at all.

In order to fix this in Crystal Reports, I had to specify in the visual linking that PATIENT.ACCOUNTID=PATIENT-INSURANCE.ACCOUNTID and in the selection criteria that PATIENT-INSURANCE.LEVEL=1.  If this were a SQL statement, this would occur in the WHERE clause and it would read like this:

WHERE  PATIENT.ACCOUNTID=PATIENT-INSURANCE.ACCOUNTID and PATIENT-INSURANCE.LEVEL=1.

Contract Management Replacement

Business delivery model:

Software as a Service (SAS): The software vendor will do all of your contract coding for you, develop the backbone of your reporting, and leave you to the work of contract negotiation, underpayment recovery, and data analysis.  These are more than just buzz words, though they sound like it sometimes.

Train and Release: That’s how I describe the model where the software vendor trains you on how to set up your insurance contracts for calculation, then they allow you to manage them. You only need to call on the vendor when you have a question or problem. They train you in the setup of tables and reports, and similarly, you only need their assistance when you get stuck.

Calculation Engine

UB and Detail charges: The UB claim is most often sent in 837  format to the payor. Some calculate on UB/837 data, some on detail charges, some on both.  Why would you want to?  Well, the 837 data is the “clean claim” that went to the payor.  Being able to calculate on the clean claim allows you to get closer to how the payor actually adjudicates the claim.  However, there are times when you need to utilize the detailed charges, such as with stoplosses based on a cumulative daily total that the 837 would not have.

Medicare: Nearly all of the software companies I have reviewed will perform the bulk or all of the Medicare contract maintenance for you.

Software Delivery Method

Hosted ASP vs. client-server: Hosted ASP software is accessed via the web; the actual server is in a location remote to the provider. Often several providers are on the same physical computer server in a secure location. Sometimes each provider will have a dedicated server in that location.  Contrast that to the client-server where the physical computer server is located at the provider site, on the provider network, and the software access is via an intranet or local network.  It is a matter of performance and paradigm.  Client-server environments are usually faster, but this is not a given.  A well configured ASP server will return the data to the user’s software screen without much notice to the user.  SQL and Oracle do an amazing job of crunching the volume associated with hospital data.

Reporting Tools

Vendor proprietary or ODBC: Since this is my primary area of expertise, forgive me if I get a little techy here. While Ascent® users are used to having access to any field in the database, not all vendors allow this.  In fact, most don’t.  Many of the databases, in order to allow accurate calculation, have a lot of cryptic and technical descriptions of fields.  So most vendors have some sort of report writer or proprietary tool.  Many will provide a data dictionary and Open Database Compatibility(ODBC) driver for you to use, which will get you close enough to full database access without getting you into trouble.  Do you need SQL? Crystal Reports®? Or do you just need to export the data; if you need more than the reporting provided.  In the vendor-provided report writers, you will see options from predefined query choices to the ability to build your own summary or detail reports.  Some have drill in capabilities. Some allow you to save your reports for others to use.  Since most organizations end up with a few proficient report writing people and a multitude of users, it is important to define the reporting requirements. Then, be specific with the vendor in describing those features and making sure you see the tools you need to accomplish your business needs.

Reviewing Report Writing Features

When reviewing systems for their Report Writing Features the first place to start is by reviewing the proprietary tools packaged with the system, then look at the options for user adhoc or connection capabilities external to the system.

Vendor proprietary or ODBC: Since this is my primary area of expertise, forgive me if I get a little techy here. While Ascent® users are used to having access to any field in the database, not all vendors allow this.  In fact, most don’t.  Many of the databases, in order to allow accurate calculation, have a lot of cryptic and technical descriptions of fields.  So most vendors have some sort of report writer or proprietary tool.  Many will provide a data dictionary and Open Database Compatibility(ODBC) driver for you to use, which will get you close enough to full database access without getting you into trouble.  Do you need SQL? Crystal Reports®? Or do you just need to export the data; if you need more than the reporting provided.  In the vendor-provided report writers, you will see options from predefined query choices to the ability to build your own summary or detail reports.  Some have drill in capabilities. Some allow you to save your reports for others to use.  Since most organizations end up with a few proficient report writing people and a multitude of users, it is important to define the reporting requirements. Then, be specific with the vendor in describing those features and making sure you see the tools you need to accomplish your business needs.

Contract Management System Experience

For 12 years I have worked solely with Contract and Denials Management Systems.  While the hunt continues for software to replace one of them, Ascent®, I have found this journey to unfold in very interesting ways.  I have spent most of my direct time working with Ascent® for the last 12 years.  Meanwhile, the industry has been moving along, developing some great software and tools to manage contracts, business workflow, and reporting.  I have reviewed about 8 software solutions that include the payor reimbursement calculation as their backbone.  Not only are there multiple software vendors, there are multiple options for how a healthcare provider uses them.  Many people I have talked to are interested in the trends and what is available.  Let me explain in more detail

Business delivery model:

Software as a Service (SAS): The software vendor will do all of your contract coding for you, develop the backbone of your reporting, and leave you to the work of contract negotiation, underpayment recovery, and data analysis.  These are more than just buzz words, though they sound like it sometimes.

Train and Release: That’s how I describe the model where the software vendor trains you on how to set up your insurance contracts for calculation, then they allow you to manage them. You only need to call on the vendor when you have a question or problem. They train you in the setup of tables and reports, and similarly, you only need their assistance when you get stuck.

Calculation Engine

UB and Detail charges: The UB claim is most often sent in 837  format to the payor. Some calculate on UB/837 data, some on detail charges, some on both.  Why would you want to?  Well, the 837 data is the “clean claim” that went to the payor.  Being able to calculate on the clean claim allows you to get closer to how the payor actually adjudicates the claim.  However, there are times when you need to utilize the detailed charges, such as with stoplosses based on a cumulative daily total that the 837 would not have.

Medicare: Nearly all of the software companies I have reviewed will perform the bulk or all of the Medicare contract maintenance for you.

Software Delivery Method

Hosted ASP vs. client-server: Hosted ASP software is accessed via the web; the actual server is in a location remote to the provider. Often several providers are on the same physical computer server in a secure location. Sometimes each provider will have a dedicated server in that location.  Contrast that to the client-server where the physical computer server is located at the provider site, on the provider network, and the software access is via an intranet or local network.  It is a matter of performance and paradigm.  Client-server environments are usually faster, but this is not a given.  A well configured ASP server will return the data to the user’s software screen without much notice to the user.  SQL and Oracle do an amazing job of crunching the volume associated with hospital data.

Reporting Tools

Vendor proprietary or ODBC: Since this is my primary area of expertise, forgive me if I get a little techy here. While Ascent® users are used to having access to any field in the database, not all vendors allow this.  In fact, most don’t.  Many of the databases, in order to allow accurate calculation, have a lot of cryptic and technical descriptions of fields.  So most vendors have some sort of report writer or proprietary tool.  Many will provide a data dictionary and Open Database Compatibility(ODBC) driver for you to use, which will get you close enough to full database access without getting you into trouble.  Do you need SQL? Crystal Reports®? Or do you just need to export the data; if you need more than the reporting provided.  In the vendor-provided report writers, you will see options from predefined query choices to the ability to build your own summary or detail reports.  Some have drill in capabilities. Some allow you to save your reports for others to use.  Since most organizations end up with a few proficient report writing people and a multitude of users, it is important to define the reporting requirements. Then, be specific with the vendor in describing those features and making sure you see the tools you need to accomplish your business needs.