Understanding Diagnosis Pointers

April 22, 2013

 

Pointers 1500

 

Diagnosis Pointers Explained

 

In the last 17 years, I have been asked a number of times to explain diagnosis pointers.  While diagnosis pointers are simple once you understand them, sometimes they are difficult to explain, especially to those outside the claims world.  The best way I can think of for now is to put together this diagnosis pointer FAQ.  If you have any additions, corrections or would like me to answer other questions, please leave a comment.

 

What are Diagnosis Pointers?

Diagnosis Pointers are used to describe sometimes complex many to many relationships between submitted diagnosis and service line treatment information on health claims and encounters.

 

Where did diagnosis pointers come from?  Why are diagnosis pointers used?

Pointers originated with paper claims.  As you can see from the image, there is not a lot of room left in the service line area for diagnosis codes.  Instead, the user just enters a number that corresponds with the diagnosis code they are “pointing” to.  When EDI started to be used for claims, pointers were a natural fit for two reasons: First, to keep things the same no matter how the data was submitted (electronic or paper) and second to keep EDI “lean”.  Transmitting data used to be expensive and charged by the character.  Using pointers meant that no diagnosis code ever had to be listed and transmitted more than once.

 

Why not just list all the Diagnosis at the line? 

A properly coded claim often has diagnosis that are not pointed to, but still collected during the encounter.  For a service that is somewhat generic like an office visit, the patient may have come in because they had the flu, but ended up getting a full evaluation that showed a previous lower leg amputation and perhaps diabetes management.  While the office visit did not address the leg specifically, capturing the diagnosis is still very important.

 

Are Diagnosis Pointers used in Institutional Claims?

No.  Diagnosis pointers are only used in Professional Claims.

 

Who uses Diagnosis Pointers? 

Claims departments use them to determine if they will pay the claim.  After loading the pricing for that provider and determining eligibility and coverage, claims decides if the treatment is covered.  Among other decisions being made is whether the treatment is covered for the diagnosis.  For something simple like an office visit, almost any reason will do, but for something more specific they must match.  If the diagnosis is broken toe and the treatment is removed kidney, the claim will not be paid.  This is a way to prevent fraud and also a way to avoid paying expensive claims that are really a result of a keying error.

 

How many diagnosis pointers can there be?

On any given service line there are up to 4.  In current EDI (version 5010 of the 837P) the value must be between 1 and 12.

 

What if more than four (4) diagnosis relate to the treatment? 

The coder who is submitting the claim at the provider picks the 4 best and does not point to the others.  The idea is to give enough detail / justification for the service being claimed to actually be paid.  If one pointer will do, then there is very little reason to point to more codes.  In the off chance other diagnosis are relevant to the treatment, they are still available to the examiner at the insurance company who is doing the adjudication – they just are not specifically pointed to.

 

Why should HEDIS, Medicare Revenue efforts or the new Health Insurance Exchange ignore Diagnosis  Pointers?

Pointers are limited to 4 or less per line and average around 1.3 per line.  This means that if HEDIS or Revenue only used the codes that were pointed to, codes that are crucial to HEDIS measures or HCC calculations would be dropped.  A doctor who did a proper, comprehensive E&M for a patient would almost certainly have the information ignored when processing.

 

Besides pointers what other limitations are present on Diagnosis Code Submission?

The total number of submittable codes vary by transmission type.

  • EDI 837 v4010 Professional: 8
  • EDI 837 v5010 Professional: 12
  • Current Paper Claim, Professional: 4
  • EDI 837 v4010 Institutional: 12
  • EDI 837 v5010 Institutional: 25
  • Current Paper Claim, Institutional: 18
  • ICE (no limit)

 

Is there any reason Medicare Revenue has to pay attention to pointers?

Certain systems may require them to be submittable data.  For example, CMS’s EDPS system that replaces the RAPS system for risk adjustment has them as a required field to be able to submit to the system.

Encounter Data or Fishing Expedition?

October 30, 2012

Recently, I mentioned to my wife that I needed new skis for this winter. Her response? “Define Need.” When it comes to collecting Encounter Data for CMS, perhaps I should consider sending my wife to Baltimore to help smooth things out.

If you have not heard of Encounter Data Processing for CMS is you could go here or just go ahead and skip this article entirely.

So while health plans have been busy for more than two years trying to comply with EDPS and prepare to switch over from RAPS (Risk Adjustment Processing System) , some involved with the process have lost sight of why we are doing this in the first place. CMS isn’t out to make things more difficult or to simply to see how high plans will jump. EDPS exists to settle some issues that can’t be addressed without more complete data. The problem is that data collection requirements can easily get out of hand.

Background: A Disagreement

In 2009, Medicare Advantage cost CMS roughly 14% more per patient than Fee For Service (FFS) patients. In 2010, that number dipped to 9% more, but still represented billions of dollars in additional cost to Medicare. The Medicare Advantage Organizations (MAOs) have pointed out that they have sicker patients on average and provide more services than FFS patients receive. CMS claimed that since MAOs are paid a Risk Adjustment Factor (RAF) based on what is wrong with patients instead of on services they provide like in FFS, they are simply better at reporting than doctors who see FFS patients. In fact, there is already an adjustment to RAF for the effect of coding intensity.

Measuring outcomes such as re-admission rates or patient satisfaction show MAO patients are better off than in FFS Medicare. MAO plans also claim that they do a better job of managing complex conditions such as diabetes and that costs money. Since current reporting (RAPS) does not show all the steps taken to provide the care, there is no way to reconcile whether CMS or the MAOs are right – or even who is “more” right.

Reasons and Realignment

To sort out how to fix the model in a fair way, EDPS uses the full data set of an 837 claim file as the source data instead of the 7 fields or so that are found in RAPS. Essentially, if CMS can get a picture of not only what is wrong with the patients today (like in RAPS) but also, what services were provided in the course of care, they can try and reconcile the model. Are the patients truly more sick on average? Are the MAOs actually being good stewards of the funds they are given and providing equal or even more care than a FFS patient gets? To get to the bottom of this, they would need to get the following information:

1. Clear understanding of services rendered – what are all the things that are being provided to the patients in an MAO plan? With this data, a patient with the same exact condition can be compared from MAO to FFS to determine the level of care received.

2. Complete data – every visit, procedure, test etc. must be submitted rather than the subset of risk adjustable data that is found in RAPS. In RAPS, submitting additional instances of the same diagnosis really didn’t do anything to the RAF calculation. To be able to compare utilization across the models, care provided that is unrelated to HCCs and RAF also must be submitted in total.

In order to make valid 837 files for submission to CMS, every encounter must include Member ID info, Provider Identifiers for both Billing and Rendering, and service line information such as DOS, CPT, Modifiers, REV Codes, Specialties, POS and charges. The problem comes in with how to use this data once it is received by CMS.

Not Claims Processing

While I was not a party to any of the discussions behind how to implement EDPS at CMS, I imagine the reasons they went with outbound 837s as the model is that they already receive these today for FFS processing and perhaps that some state Medicaid systems collect 837s for their model today. The thought was probably that they could just take the FFS system that could already process 837s and modify it to take in encounter data for use in EDPS instead. The problem is that claims processing requirements don’t always line up with EDPS. It is easy to look back and say that collecting 835s that every MAO in America can already output and contains a clear record of what took place in the course of care would have been a better way to go, but that won’t help us here.

In FFS processing, certain data may be required in order to pay a claim. If the data is not present, the claim is denied. If a FFS provider wants to get paid, they will get the needed data and resubmit. With MAO plans however, there isn’t any requirement to follow FFS submission rules. If a plan wants to work with a particular doctor or facility their contract will dictate what needs to be submitted. For example, skilled nursing facilities (SNF) must submit 837 claims to CMS for FFS payment. Another SNF may work with MAO plans and submit claims via paper form which may not have all the data elements needed to make a valid SNF claim. If that MAO then tries to submit EDPS data showing the SNF encounters, they will be rejected due to missing data elements. The encounter certainly happened and the MAO paid the claim; there is nothing to “fix” in the system of record (e.g. claims system) to make it submittable to CMS. If data is made up to make it submittable, the head of the plan’s compliance efforts would likely be less than pleased to say the least. If the data is not submitted to CMS, utilization will seem lower than it actually is. Typically I refer to these types of claims as the “encounter grey zone”. These are claims that are correctly processed by the plan according to their business rules, and yet are unsubmittable to CMS.

In the above example, RAF scores would likely not suffer too greatly if at all. The direct impact is not felt because other encounters would likely be present to cover any related HCC diagnosis. Of course this is going to be a revenue department’s first concern at a plan. However, even if small numbers of encounters are unsubmittable at each plan, utilization across all plans will appear lower and therefore there will be an indirect but definite impact to plan payment when utilization is calculated by CMS and applied to the new reimbursement model.

One option, which would take a great deal of time and effort to come to fruition, would be to make sure the same rules that apply to CMS FFS submission are then followed by providers and then the plan’s claim system processing rules. While this is possible, it essentially means that CMS’s rules and system become a defacto way to enforce payment practices on MAO plans. There are a lot of attractive reasons to work with an MAO rather than FFS Medicare, but those reasons start to go away as MAOs have to add layers of rules and bureaucracy.

There is a lot of data in an 837. When you take into account the fact that all encounters must be submitted to CMS, plans are looking at 500-1000 times as much data as submitted under RAPS. While balancing claim lines for amounts claimed, paid, denied – not to mention coordination of benefit payments – is not a part of the stated goals of EDPS, balanced claims are needed to make a processable 837 file. Due to the nature of contracts and variability of services provided within identical CPTs, this data won’t likely proved statistically significant to CMS even if they are able to collect and data mine it.

Reexamine the stated goals of Encounter Data Collection

I am sure there is lots of data that would be nice to have for some data miner at CMS someday. Now that we are all quite far into this thing, there are certain things that would be painful to undo, however there is still an opportunity to take a step back and reexamine why we are doing this in the first place. In many cases, CMS is still running the submitted data through a system designed to pay or deny claims before it reaches their data store. This means a lot of edits and a lot of reasons why an encounter might reject. To their credit, CMS has turned a lot of edits off, but when the starting point was a full claims environment, there is still a long way to go.

If CMS were to reexamine the edits involved in the EDPS process, they would find it is in not only the plan’s best interest to turn off many edits, but their own as well. If an edit doesn’t fit the following criteria, it should be turned off.

  1. Can the member be identified? Doing a good job so far on this one.
  2. Can the provider be identified? After a positive NPI match, there should not be rejections for mismatched addresses, zip codes, names, etc. If it is a valid NPI and CMS still has rejections then the table CMS is using for this process MUST be shared with the plans so they can do look-ups prior to submission. Plans can’t be expected to guess this information. There are a lot of kinds of provider errors out there that need to be relaxed.
  3. Is it a valid 837 v5010? If the standard is not followed and the required fields according to the TR3 are not present, all bets are off. However, this may mean that certain fields should be able to be defaulted in the same way that Ambulance mileage / pick up and drop off defaults have been allowed.  There are lots of segments and elements to the TR3 that are Situational unless your trading partner requires them.  Most of these are just not required to realign the model.

Finally ask the following: Does a rejection indicate doubt the encounter happened, or that CMS doesn’t normally pay it? If an encounter / line doesn’t have a valid DOS, CPT, Unit where required, Modifier where needed, diagnosis code(s) then it may be unclear what happened and when. Barring that, the decision whether to accept the encounter data should be to accept. Whether CMS normally pays without that data in a FFS environment is irrelevant.

What do you think?  I’ll monitor the comments to hear your thoughts.

Paper Claims and Encounter Data

February 16, 2012

Addressing the Confusion Related to CMS’s Encounter Data Mandate

Whether it is the various industry calls, conferences or even CMS’s own meetings, the question about what to do with paper claims keeps coming up. This is a short look at the issue including background, unknowns and an attempt to surmise what is most likely to happen.

Background

Paper to dataCMS has decided to replace the current method of reporting risk adjustment information called RAPS with a new process called the Encounter Data Processing System (EDPS). This process requires plans to submit EDI transactions that contain much more information about members, providers, dates of service, diagnosis, treatments and amounts. The EDPS mandate also requires every encounter to be submitted, even if denied. When compared to the 7 or so fields required under RAPS, EDPS means that plans have to submit somewhere around 500 times as much data as they did before.

Many MAOs are frustrated with various areas of the effort from slipping deadlines to changing requirements, but this article will focus on unique problems associated with paper claims.

EDPS calls for data post adjudication
Perhaps this is the most important thing to remember when trying to figure out any problem relating to the paper claims issue. The data that CMS has asked for is not simply a forwarded copy of whatever the provider submitted to the MAO. Instead, CMS is asking for not only the “claim” data, but also the results of the claim through the adjudication process. One simple way to look at the EDPS requirements is as a combination of the originally submitted claim combined with the explanation of benefits / payments. CMS wants to see what lines were accepted, for how much, as well as what lines were denied. Even in a best case, the claim – paper or electronic – only tells half the story.

Paper claims typically get into the claims system in one of two ways:

  •  Paper Claims are entered directly into the system.
  •  Paper claims are scanned, OCRed and typically converted to EDI.

The “paper” EDI is injected into the same EDI stream or a parallel EDI stream to be processed in much the same way as any other inbound electronic claim. Either way, the claims are paid using the same system and rules after the data is entered. This means that to comply with CMS’s Encounter Data Mandate, the data for the outbound file should be pulled from a common pool (usually the plan’s claims system), regardless of submission type. When paper claims are done being processed (paid or denied) they are hard to distinguish from claims that were entered electronically. As such we need to ask ourselves what is so different about a paper claim? To do this we should look at three things:

  1. Identify what data cannot be put on a paper claim form
  2. Examine what data can be put on a form but generally is NOT by the submitter
  3. Find out if any information is present on the paper claim, but not entered into the system for any reason.

After looking at these three areas, we can see what situations a valid 5010 which will comply with the CMS requirements can NOT be created from a claim that originally came in on paper. For area one, it usually turns out that the paper claim has the ability to contain all the information needed. Most of the cases where there are deltas reflect the fact that the paper claims can make a valid but DATA POOR transaction when submitted. For example, there are only 4 spaces available for diagnosis codes. This is an example of a limitation of the paper form when conducting business with a MAO plan, but certainly there is no requirement that there has to be MORE than 4 codes when submitting 5010. While all the data needed by CMS is not available on the form to make a valid transaction, most of that can be added such as the submitter and receiver information. One good example of data that really doesn’t have a place on a professional claim is a Coordination of Benefits (COB) claim.
As it turns out, areas 2 and 3 are where the real problems come up. To make a valid submission, plans need to submit NPI numbers for billing and rendering providers. If providers are not accustomed to providing things like NPI over the years, they may not give it to the plan. In this case, the data CAN be put on the form, but the MAO has never complained about it not being there and so it is skipped. In very much the same way, even when data is put on the form, it might not be entered. On the UB-04, there is actually a place to note an ambulance pick up and drop off location for institutional claims. This field is rarely if ever filled out on an ambulance claim, but even if it were, there may be no place to put that data in the claim system. If the plan doesn’t require it of the ambulance company to get payment and the data is not tracked, it simply won’t be keyed in.
Enforcement of missing data on a paper claim is much tougher than with electronic claims. With an EDI claim, rules can be put in to reject the claim at the EDI gateway. Paper claims are already in the door and rejecting it for something like a missing NPI is most likely more work than simply looking it up. NPI can many times be populated with internal provider tables already integrated into the claims process. If claims tables still don’t have the data, integrating an NPI look up from the NPPES database would certainly help.
Most of the required data for EDPS would be required by the claim system to begin with – paper or EDI. For example, EDPS requires treatment codes where RAPS did not. This has no impact though since every claim system on the planet requires treatment codes anyway at this point. The areas that are required under EDPS that are often not available on the paper claim (for any of the three reasons listed) happen to be areas that are not required or provided in the EDI file. This means that the problems from paper claims may not be unique to paper claims. Instead they are issues with the EDPS requirements as a whole.

Could CMS Offer Eased Requirements for Paper Claims if They Wanted To?
While anything is possible, it is highly unlikely. First off, CMS vastly underestimates the amount of paper being submitted to plans today. Medicare FFS sees very little if any paper and so they can’t seem to imagine why would it be any different at a commercial plan. As such, the fix to them is less important than all the other areas that are making noise in Encounter Data Processing. Second, if we assumed that CMS was interested in doing something about paper claims, the issue is that there isn’t really a reliable way for CMS to know the claim was originally paper in the first place. This is due to:

  • CMS EDPS / EDI 837 v5010 does not have a paper claims indicator
  • Even if there were an indicator, most plans claims systems would not be able to populate it reliably

If these two issues were ever worked out though, the resulting requirements should be a very reasonable bar to hit. Paper claims contain all the fields to report risk, show utilization and price the claims – the stated goals of collecting encounter data in the first place. If paper claim data requirements are ever defined by CMS, treating them as defacto standards for other data types would likely yield a comprehensive, reasonable set of requirements for EDPS as a whole instead of the reach that many requirements are.

What should plans do?
In almost every case, claims that were submitted on paper to the MAO can be turned into a valid, submittable EDPS transaction for CMS. At worst, these transactions may be “data poor” due to less ability to submit diagnosis codes, however that would be true of both RAPS and EDPS. The claims that are truly unsubmittable to CMS due to a missing data element such as COB data or Ambulance Pick Up address are very likely also problems for the native EDI claims as well.
Perhaps instead of trying to work out every possible scenario where a paper claim would present a problem, plans should push back at CMS on the requirements that don’t directly relate to the purpose of EDPS.

Dan Hartensveld: The Infographic

September 2, 2011

Tried out a neat little thing from Vizualize.me to make your experience / professional background easy to read.

You can take a look at it here:  www.visualize.me/dhartensveld

The Office of the Future

September 20, 2010

Scientific American has an interview with Xerox’s Palo Alto Research Center (PARC) research fellow David Biegelsen who has been at the lab since the beginning.  It is a really interesting look back 40 years at “The Office of The Future”.  If you are unfamiliar with PARC (as I was) from the article:

Xerox established its Palo Alto Research Center (better known as Xerox PARC) in June 1970 as a West Coast extension of its research and development laboratories. PARC researchers proved wildly successful in pioneering many contemporary business technologies—the PC (the first was called the “Alto”), graphical user interface (GUI), Ethernet local area computer network (LAN) and laser printing, to name just a few. Xerox, however, was considerably less successful (and less interested) in commercializing much of PARC’s technology itself, leaving the door open for Apple, IBM, Microsoft and others to capitalize on PARC’s innovations.

This is a good reminder for me that being right is not enough.  These folks were ahead of the curve by a long shot and, they were on target about how and what technologies would develop and become useful.  (Image for a moment having email a regular part of your day in 1970).  The thing is that a lot of areas had to catch up before they could capitalize on it.

About 10 years ago, I remember speaking to a vertical market analyst who told me that most of the time, companies when pursuing vertical markets over-estimate short term results and under-estimate long term results.  That rings true here as well.  Having a clear vision of what the future holds may mean that you have to keep pressing for a very long time before you will really see the fruits of your labor pay off.  Just because you are not seeing the results over night, it doesn’t mean your vision is wrong.

Paper Medical Records Are Here to Stay

September 13, 2010

Seems Permanent . . .

About 14 years ago, I got involved with automating medical claims. For those not familiar with the process, as it turns out doctors still lick stamps and send paper medical bills (or claims) to health insurance companies for payment. Sure they can submit electronic bills as EDI, but many don’t. There are a couple big reasons (and a million small ones) that lots of paper claims are still out there:

– Loose Standards (837 the EDI format is implemented in lots of different ways)

- Addressing / Delivery (imagine a doctor needing a separate phone line for every payer – while it is not quite this bad, it certainly isn’t like dropping an envelope in a mailbox (or sending an email for that matter) and knowing it will get to an address despite the fact that you have never talked to them)

So while the above could be overcome, it is easier in lots of cases to just keep doing what you are doing. When it comes down to it, there is a utility to paper that is hard to beat in the short term. This is a common theme to PaperInbox, but in this case I want to discuss how it applies to Medical Records.

Whether it is industry news or even mainstream news covering the new healthcare bill, people talk a lot about the EMR or Electronic Medical Records. EMRs are slated to give us all kinds of great efficiencies from better care due from access to patient history at point of care to huge administrative savings that come from eliminating clerical work. These are pretty great things and somewhat inevitable in the long term. In the short term, I think something quite different will take place. Read the rest of this entry »

2 Areas Not To Outsource

November 19, 2009

Part 1 Here

In my last post, I submitted that today’s outsourcing is not all that different from basic economic specialization.  We can see that due to advances in technology – particularly communications – the pool of places, talent and resources to draw from is now essentially global and nearing limitless.  Often times my customers ask me questions and I have to point out that the question they have asked is not a matter of “can” something be done, but instead “should” it.  That is where these options with outsourcing have left us.

So what areas should a successful corporation focus on?  Obviously those that offer the biggest return in cost savings.  Now those who have done business with me over the years know me to be perhaps obsessive when it comes to focusing on hard dollar ROI and having very little tolerance for the soft dollar pay-backs that are often used to justify technology sales.  That being said, one has to consider all the COSTS including harder to estimate impacts on other areas of the organization.   Read the rest of this entry »

What To Outsource

November 17, 2009

PART 1: Background

For years now, companies in corporate America have been turning to outsourcing to help improve margins and make their organizations more competitive.  The thing is that the successful stories – the ones that truly deliver on the promise – are the ones we hear the least about.  Conversely, the biggest disasters are told many times becoming modern versions of the warnings to mariners of sea monsters or the edge of the earth over time.

Why hide it?

Well as it turns out, large companies in America have lots of competition looking to tighten the belt just as much as they are.  When a company outsources successfully a particular part of the operation, the only people they would want to tell about it might be shareholders or potential shareholders.  Then again, if it is successful enough, the better numbers should speak for themselves better than any details of their process ever could.  As such they would be only giving their competition a roadmap to re-level the playing field.  In addition, outsourcing can have negative connotations with some customers regardless of the positive overall effect on the product or service they are purchasing.  Better to keep the best stuff under a hat overall in most cases.

As it turns out, there are huge amounts of information available on successful cases of outsourcing things as varied as IT Services, Call Center work, Tech Support, Data Entry, Manufacturing or any number of others.  The problem is that this information is usually generated courtesy of the company providing the outsourcing services.  Predictably they are going to give “case studies” that proffer stories that might as well include cutlery jumping over celestial bodies (ibid Neal Stephenson).

So how is the busy COO or President to know what is best to pursue and what things should be avoided?  My approach to almost all problems in life is to reduce them to their primary and build back up from there.  I’ll try to be brief since most readers understand the background, but the point needs to be made.  Outsourcing is a modern way of expressing a very old concept: economic specialization.  Without economic specialization, the modern world could not exist.  If each of us had to grow our own food, build our own shelter, weave our own clothes, provide our own healthcare, etc. we would have little time left to concentrate on designing efficient engines, packing more transistors on a wafer of silicone or making a beautiful sculpture.  Today’s modern communication and transportation have simply allowed us to take advantage of varied conditions in further away places.  The answer to WHY outsource lies in the very same roots as any economic specialization.

NEXT POST: The 2 Areas Not to Outsource

Weighing Tech Benefits

November 9, 2009
Heavy Features

Bigger might just mean more expensive

There are reasons I enjoy my work in a technology related field.  One of the most fun is the whole idea of better, faster, cheaper that I get to see new examples of every day.  If you think back a bit, in 1980 if you bought a VCR it was about $500 (in 1980 dollars), the size of a refrigerator, had no remote, no auto-tracking, no stereo audio output and broke if you rewound tapes too much.  Just before they stopped selling VCRs a couple years ago, you could go into a Walmart and buy one with a remote, produced a clear picture automatically, stereo output, was only maybe 4 times larger than the tapes themselves and cost $39 in 2006 dollars!  It was better in every imaginable way and way cheaper to boot.

Read the rest of this entry »

A Timely Technology Solution

November 3, 2008
Now picture 7.3 million of these

Now picture 7.3 million of these

Saturday’s Wall Street Journal had an interesting headline: Massive Effort To Save Mortgages.  The article went into how JP Morgan was planning on targeting 400,000 loans for modification of terms on top of what they were already doing.  It also mentioned some other banks such as Bank of America’s efforts to modify the terms of existing loans in lieu of foreclosure.  The article points out that “…7.3 million American Homeowners are expected to default on their mortgages between 2008 and 2010.”

As you might expect, when banks transact business with other banks, things can be done in a largely electronic environment generating minimal amounts of paper.  Since individual homeowners don’t have systems that hook directly into lenders the process of modifying the terms (mod) of a loan is done almost exclusively on paper.  Things like pay stubs, tax returns, letters of hardship are used to determine what can be done for each loan.  This means that even simple mods may carry 20-40 pages of faxes, mail, etc. inbound to the lender.  Multiply that by say 7 million and you have yourself a mess of paper.

So many times I see companies in Corporate America spending money on technology for the sake of technology instead of a solid Return on Investment like cutting costs.  In this case however, I came across a service that is specifically targeted to handle all the paperwork related to the workout options for these loans.  I put a copy of the PDF for the service on my website if anyone is interested in an overview (full disclosure: I have worked on various projects with this company for over ten years and am not a totally disinterested party).  It is exciting to see how technology can be used to effectively address something that is urgent, timely and expensive without being overcomplicated.

The service is particularly appealing to lenders because they really don’t have large capital expenditure budgets floating around right now.  Instead of a long drawn out implementation and large amounts of money down, they “pay by the drink” if you will.  It gives lenders who are under pressure to mod loans an option other than throwing more bodies at the problem and hope they can keep ahead of the tide.  Essentially it is a way for them to focus on the decision making aspect of the process rather than the menial, clerical and repetitive tasks.

This is technology and efficiency at its best and it is great when it happens.  Do you have any positive / timely technology examples?  Put it in the comments and I will do my best to address it.


Follow

Get every new post delivered to your Inbox.