Listen Beyond the Words!

Recently, I have been subjected new software with an interface that screams a lack of usability testing.  It is always a shame when workable, convenient software is replaced by something “better” that simply doesn’t serve the end-user.  Having been in the software business, I understand how this comes to pass.  When purchasing software for your business, you need to “Listen Beyond the Words” and “Look Beyond the Demo”.

Early in my career I worried about consultants helping associations choose software.  As time went on, I developed a real respect for good consultants who knew their client’s needs and could explain them well to the vendor. They could probe into the real functionality of the proposed software, ask questions that the client might not ask themselves, and ultimately create a real collaborative team during the implementation.

The different players in the software selection process each have different objectives. The business wants to purchase software that will do a certain job in a way that improves on older software and increases the productivity and efficiency of the staff.  On the other hand, the software salesman’s objective is to make the sale.  I’m not saying that the objective of software salesmen is to mislead – just that everything that measures their success relates to their sales.

The software demo, a key aspect of the selection process, is supposed to be where the committee determines if the software meets the company’s objectives.  For the salesman doing the demo, the objective is to show the strengths of the software and to do it in a way that masks any objections to their software’s design and functionality.  It is up to the committee to extrapolate what is shown versus what is needed.  Those involved in the selection process often assume too much and trust what is implied rather than insist on seeing each entire process.  Sometimes, committee members feel that they just might not understand the technology and don’t want to ask specifically about something they think must be obvious or at least obvious to everyone else.

Though I don’t expect a salesman to call attention to the negatives of the software, I would at least expect them not to actively mislead.  Then again, chances are, the salesman doesn’t really know the prospective client’s business well enough to know where his software doesn’t fit.

The key success factor in the software selection process is to have someone on your side that understands the objectives of the different players and knows what it is that you do and what you want to accomplish.  That consultant’s role is to “listen beyond the words”, to look, and to demand clarity on issues that are important to the client and that are not necessarily shown during the standard demo.  The consultant’s job is to tease out edge conditions and related issues.  “Show me” has to be a standard mantra and pushback the standard procedure when it appears that an issue is being avoided.  If the vendor embraces the consultant’s questions and answers questions openly, you are in good shape.  If the vendor tries to diminish the role of the consultant in the process, then take fair warning.

Sometimes the issue is not whether or not the software will do something you need to do but rather how it does it and who does what.  If the software can do it but it requires a cumbersome process that replaces an existing simple process, there is a problem.  If the process is now to be done by a different person or different position, make sure you are comfortable with that.  The selection committee needs to actually see everything that is important to each process and not just be assured that everything is fine.

In a recent implementation of hospital and medical records software, the administrators were assured that they could reduce the staff because of the new software.  The administrators were delighted.  What was not mentioned was that the vendor was now requiring the surgeons themselves to do data entry.  You can imagine how well that went over once the implementation got underway!

Here are a few of the warning signs:

  • “Well, I don’t have a full set of data in the demo system so I can’t actually show you…”
  • “We don’t have a printer hooked up to the demo system so I’ll send you a copy of the report tomorrow.” (…tomorrow never comes…)
  • “Sure, we can do that.” (…without actually showing you.)
  • “Not a problem.” (…often repeated frequently with no follow-up.)
  • “Trust me; you’ll love it.”

In one of my consulting engagements, the vendor, during the demo of a financial system, said “Of course we have month-end reports.  It never dawned on anyone that their month-end general ledger report wouldn’t show starting and ending balances nor would anyone guess that their system didn’t actually store offsetting debits and credits!  Now, that’s the most egregious example I have seen but still…

Going back to the experience that started this article, the basic idea behind the new software was actually a good one.  The new software did something that the old software did not and it was a very nice feature.  What might not have been noticed by to the customer was that all the good things that the existing software did were not done by the new software at all.  What used to be simple and automatic was now very cumbersome.  The staff facing the public probably weren’t involved in the selection process but are now left with having to smile and say “You’ll like it once you get used to it.”  To me, that’s saying “When you forget how good the old software was, you’ll finally accept the new software!”

Lessons to be learned:

  • Hire someone to help you who knows how the process works both from the vendor and the client perspectives.
  • Invest in the time to make sure that your consultant knows your business, your objectives, what you are currently doing, and who and how they are doing it. The consultant needs to know the existing software interface to correctly assess a new one.
  • Trust and encourage the consultant to press the vendor for specifics. You may not get everything you want but at least you will know what you are getting into before it’s too late!
  • If the vendor pushes back on the consultant or tries to bypass or marginalize the consultant, raise red flags against that vendor! Ultimately, this needs to be a collaborative team!

Looking Back on Health Care Exchange Implementation

It is now almost two years since I started working with the Hawaii Health Connector, a state exchange implementing the Affordable Care Act. For me, that project ended mid-last-year. I began the project by helping them with the vendor selection process and later became the subject matter expert and business owner for the financial management side of the exchange.

I was impressed with the process in both positive and negative ways.  I watched a full-time staff that was totally dedicated to the success of their mission.  They worked through a complex process where the rules were being dynamically defined throughout the implementation as they tried to accomplish something that simply had never been done before.  I have nothing but the highest respect for the Connector staff I worked with in Hawaii.

On the other hand, I watched an enormous amount of federal money spent across the country to do something I believe in but it wasn’t necessarily spent wisely.  As everyone knows, the roll-out was a disaster across the board.  It was difficult in Hawaii and even more so in other states and even for the Feds.  The software should not have been that difficult to write nor the hardware that difficult to configure, yet at the very last-minute many were surprised that things didn’t work.  I hold the vendors responsible for the failure particularly as they assured everyone of success right up to the go-live date when everything failed.

Having come from the vendor side of software implementations, I was saddened to see incompetence in the vendors and further saddened by how easy it was for vendors to manipulate their clients to ignore the very deadlines and metrics that were necessary for success.  What many of the states needed was someone with vendor experience to help them navigate the process of bringing up a large system.  They needed someone to translate what the vendor was saying into what it actually meant to the project.  It is not for the faint of heart.  Politically, October 1, 2013 was an absolute that couldn’t be moved.  On the other hand, much earlier on, there needed to be people involved who would just-say-no and force the vendors to follow their own contracts and agreements.

As I check back with friends in Hawaii and in other states, I am still surprised that the vendors weren’t held responsible for what they did.  In one case, the financial system provided by Aldera (previously Healthation) for the exchange still cannot generate accurate financial reports or even accurate financial transactions after more than a year in production.  What’s more, they don’t even seem interested in fixing the problems.

I still believe in what the Affordable Care Act was trying to accomplish though I have never seen so many political “leaders” doing everything they can to make it fail rather than taking their responsibility to serve their constituents.  Just think of what it could be if both parties worked together to make the vision a success and fix shortcomings rather than exacerbate them.  We can only hope that politicians in Washington will eventually become at least civil to each other.

This was one of my first experiences with large government projects. I hope that others are better envisioned and implemented.  At this point, my prime interest is to return to helping associations and other non-profits to select and implement software.

Is it really a requirement?

I never cease to be amazed by the antics of vendors trying to make problems simply go away without fixing them. The latest was a request from a vendor to remove an “issue report” because there was no actual written requirement to support it. You be the judge…

The problem was with software sold as a “robust financial accounting system” which turned out being neither robust nor even a real accounting system. When the first monthly close couldn’t tie out and we went to analyze what went wrong, we realized that there was no way in their system to link the debits and credits to the transactions that created them! You could see a list of transactions and even a list of debits and credits but the only way to see how they corresponded was to download everything into Excel and then manually move things around to where they should be and finally analyze what was left as the likely problem area. This was reported to the vendor to make sure that we weren’t missing something along with a request to find a way to show this relationship.

Their response was that “This is just the way the software is designed.” The vendor wanted the problem dropped since we didn’t actually specify in the RFP that the accounting system should be able to show what debits and credits were associated with a given transaction. Who in their right mind would have thought that you needed to specify such a thing when looking at a “robust financial accounting system”?

Later, we even found instances where the debit was in one month and the credit in another month. Then again, we didn’t write a specific requirement for that in the RFP either but at least in this case they agreed to fix it.

Buyer beware. If you are writing an RFP for a state insurance exchange, contact me!

Reinsurance, Risk Corridors, Risk Adjustment

Premium Stabilization Programs

Among the many aspects of the Affordable Care Act that the general public is unaware are elements that are intended to stabilize premiums for the public but also in another sense assure the insurance companies that they won’t lose money.  These are often nicknamed “The Three R’s” – Reinsurance, Risk Adjustment, and Risk Corridors.  As with any government program, the rules are complex.  Though the three programs all target stabilization of premiums, each of them do it in a different way and target different mechanisms that would otherwise encourage carriers to increase rates and avoid high risk enrollees.  At the same time, you can see how they also stabilize profits for the insurance companies.

Some of these programs are temporary just to get everyone through the period where no one knows exactly what will happen including who and how many will enroll.  Will they only be the old or the young; will they be those already ill versus those who are purchasing insurance to protect themselves from future expenses.


ACA requires health insurance companies and self-funded group health plans to fund a transitional reinsurance program from 2014 through 2016.  This temporary program is meant to stabilize premiums by reducing the incentive for insurers to charge higher premiums due to the uncertainty about the health status of enrollees.  To implement this, all health insurance companies and self-insured plans are required to contribute funds to the reinsurance pool.  These reinsurance fees are then disbursed to issuers and self-funded plans that disproportionately attract individuals at risk for high medical costs.  It is rightly assumed that individuals with high risk for high medical costs will naturally be attracted to plans offered through the ACA, particularly those who have not had access to insurance because of pre-existing conditions.

Reinsurance fees are paid back to individual market plans where the claims cost for an enrollee exceeds a certain threshold – called an “attachment point” — up to a set reinsurance cap.  For those with access to CMS documentation, this functionally is outlined in the Financial Management Blueprint Process Models, specifically BP-FM-10, -15, and -17.

Obviously there are two aspects to this, the collecting of the fees and the disbursement of the fees.  HHS is responsible for collecting the fees.  HHS uses enrollment counts to calculate a per capita fee – currently $63 per enrollee for 2014 and then decreasing over the next two years.  Insurance companies are required to provide these counts by November 15, 2014.  The first invoices for these fees are expected by December 15, 2015 for the 2014 benefit year.  The first payments are to be made in January of 2015.

As one can imagine, the Reinsurance program requires contributing entities to register and set up a fairly complex infrastructure to compile and make available information about their enrollees and claims.

Risk Adjustment

Risk Adjustment is a permanent plan.  Where Reinsurance is meant to stabilize premiums by protecting insurance companies from the uncertainty of the health status of enrollees, Risk Adjustment is meant to stabilize premiums by mitigating the effect of risk selection across plans.  It provides a disincentive to insurance companies to only attract healthy clients by sharing the risk across plans and companies.

Risk Adjustment essentially transfers funds from plans with lower-risk enrollees to plans with higher risk enrollees.  Again, all plans pay into the program and money is paid out to carriers of both the individual and SHOP (small business) market based on expected costs determined through actuarial calculations.  The program will not make payments until 2018 to allow adequate time for HHS to optimize the data validation process. For those with access to CMS documentation, this functionally is outlined in the Financial Management Blueprint Process Models BP-FM-11 and -18.

Risk Corridors

Risk Corridors, another temporary program, is meant to stabilize premiums by limiting both gains and losses thus mitigating the uncertainty involved in who will enroll and who will not. Plans are to target a payout of 80% of premiums on enrollee’s medical care.  Issuers with costs less than 3% of the target amount must pay into the risk corridors program while funds are redistributed to plans with costs that exceed 3% of the target amount. For those with access to CMS documentation, this functionally is outlined in the Financial Management Blueprint Process Model BP-FM-12.

Open Enrollment Closes

I was asked yesterday why there was a specific end to enrollment in the Affordable Care Act.  I guess I have been too involved with it to think that this was not well-known but then again…

The ACA has many concepts built into it to “make it work”.  One of these is the specific enrollment period approach that works much the same way as signing up for Medicare (Parts A, B, C, and D). The fear among insurers is that people will wait until they get sick and then sign up for insurance.  To avoid that situation, the Feds have established only certain periods that you are allowed to sign up.  Presumably, you can still wait until you get sick but then you have to wait until the next enrollment period before you sign up for coverage and may lose your shirt before you can get the insurance.  Young invincibles may still want to roll the dice but a single visit to an ER can easily leave someone in debt for years and being generally healthy doesn’t protect you from the driver running a red light.

There are other aspects of the ACA that “encourage” people to sign up.  The penalty for not having insurance is one of them.  A lot has been made of the $95 penalty for not having insurance.  What has not gotten a lot of press is that the $95 is the minimum penalty.  First of all, that is the penalty for just a single adult and not a family and even then it is for someone making less than $19,500 a year.  If you make more than this, you pay a percentage of your income up to $11,000 for 2014 and then this increases in 2015.  Throw in a single trip to the ER for you or your family and you are really in trouble.

Perhaps one caveat is that the IRS is not allowed to collect the money outside of deducting it from tax refund checks.  This could raise some interesting questions in itself!

There are a number of other interesting ways that the ACA is adopting to “make it work” and to protect the insurance companies.  I’ll cover some of these in later posts.

The CMS Vision versus the Vendor’s Imposed Reality

Again, I start with a caveat.  I only know from what I read in terms of CMS vision and speak to the vendor’s imposed reality from a background in software development and systems administration within the corporate world.  Clearly, my views here are my opinions only!

When I first read documents from CMS on what they asked vendors to do and how the technology should be built and how it should work, I was really impressed.  When I first read the CMS requirements, I was excited to see something really done right.  They specified software that followed specific data standards so that reporting could be done across the entire system without all the data conversion issues they have now from all the various state proprietary systems.  They specified an architecture based on SOA (Service Oriented Architecture) so that various components could be linked together in a modular way with standard communication protocols between them.  Components could be swapped out without damaging other components.  CMS specified the use of rules engines so that when business requirements change, they could be implemented through the definition of English-like rules outside of the code itself.  If the state and federal exchanges were written this way, this would provide sophistication and flexibility unknown in most large government programs and probably all state programs.

To this day, I don’t believe that any of the vendors actually followed these requirements in the way described by CMS.  I know of at least three states who are using one major component of the exchange that was written in VB6 – not even Microsoft VB.NET which was first released in 2002.  Programmers reading this will laugh about how long ago this code must have been written.  They will also cringe when thinking about linking this to a SOA architecture and cringe even more when thinking about modifying it for some purpose other than what it was originally written to do.  Those of us trying to use it are finding it almost non-functional!

Then again, CMS wanted the ability to re-use and share code between the states to reduce the overall cost of the project.  That was naïve.  The commercial companies bidding on this project had no intention of doing anything other than some proprietary approach that they could sell over and over again.  There was no intention of sharing anything.  All the companies came out with bids including COTS (Commercial-off-the-Shelf) software that was already “owned” by commercial companies so couldn’t be shared.

Rather than a highly modularized and flexible system standardized in many ways across the different exchanges, what we have is a hodge-podge of different existing systems that have had to be integrated in very complex ways.  There is little real flexibility.  Most of what I have seen is much worse than it could have been had the companies started from scratch and written to the requirements rather than force everyone down the proprietary COTS path.

I have said before that I think this should have been a federal program and not one where each state could have its own exchange.  If CMS and the Feds had hired the staff to design and write the exchange software so that the government could actually own it, I think they would have been more successful.

The CMS vision was great; the reality imposed upon it by the large contractors hired to implement it was very different.

The Health Insurance Exchange as a True Startup

Having worked through a state exchange ramp-up from vendor selection to the eventual invoicing and collection of premiums, it rings true that anyone attempting this needs to look at it like an entrepreneur involved in a technology startup.  States that want to start now will at least be able to benefit from the experiences of those who have come before but looking at the process as that of a startup would still serve them well.

Objectives and requirements need to be defined up front and not as you go along.  Staffing should match the expertise required to manage the project.  All those participating in the project should believe in it and work to make it a success.

The biggest difference between a technology startup and an exchange startup has been money.  I think it had a profound effect on the state exchanges. The Feds were providing the money – lots of it – for a project that hadn’t yet had its requirements defined.  I am convinced that a private individual or a venture capital organization would have dealt with the funding very differently than did the Federal Government that seemed at time to provide a blank check to state exchanges.

Now we are facing even more money pouring into the process and a feeding frenzy as vendors step up, perfectly willing to fix another vendor’s code.  When will the dollars stop?  When will someone develop the technology can will bring reality to the dream.

My ACA Prejudices

First of all, I want to make it clear that my observations are not an analysis of Hawaii whose project I was at times directly involved in but represents my observations across a number of states along with what view I had into the Federal System.  These are simply my opinions from what I observed, based on many years of large system implementations.

To establish my prejudices up front… I really want the Affordable Care Act to work.  Though my whole family has been involved in the medical profession and most don’t want to see anything change, my feeling is that the system is “broken” and needs to change.  I particularly dislike the fact that it openly discriminates against the poor.  Why should a hospital accept a much lower payment from my insurance company for a procedure then charge much more from someone who can’t afford insurance and must pay if they want to maintain their credit scores?  Why do we penalize the poor if they need medical care?

Then I watch the local ER providing primary care to those same people without insurance and without formal medical care and think about how expensive an approach that is versus a more organized approach.  I see insurance costs go up. I watch special interest groups to make sure that there is no way to control those costs and plenty of ways to push people out of insurance if they are actually sick.

Do I agree with everything in the act?  Well, no, but at least Obama had the guts to try something rather than just let the problem continue to grow.

What don’t I like about the act?  It should have been a federal program and not something that each state would independently develop.  Why should taxpayers repetitively spend federal dollars to create independent systems when it all has to interact with the Federal system anyway?  If states need to control their own Medicaid programs, a central federal system could go out to these systems for eligibility information just as is done in many of the state exchanges now. There should have been a public option; the only way to really keep insurance companies honest.  Insurance companies should not have played such a large role in writing the act in the first place.  The government should have been able to negotiate prices for medical care.  Pushing out the insurance mandate to satisfy political expediencies should not continue to happen.

Then again, at least the ACA is a start and I will do whatever I can to help make it successful.

When Marketing Outstrips the Product

I have recently been working with an accounting product that makes me want to cry.  It is old and kludgy.  It would make an accountant want to tear his hair out.  It is only marginally useful and requires more workarounds through other accounting systems than supported functionality.

Then I learned that the company that created it changed their name and created a wonderful new website.  I was really impressed with the website.  If the product were only half as good as the marketing for it, I would be happy.

Lesson learned:

Even if the accounting functionality of a project is minimal, make no assumptions that what you think should be standard functionality that everyone provides will be supported by any given piece of software.

Beware of anything a vendor tells you.  Trust but verify.  Just because a website is beautiful and uses the latest technology, don’t assume that the software being sold is equally as good!

Having come from a software product design and implementation background, it makes me sad when I see this sort of thing.

Stage Fright Research Interviews

For those interested in another side of my life and activities, take a look at the following links that deal with the stage fright research I did more than 20 years ago, research that keeps coming back!

An Interview with Thomas A. Brantigan: Beta Blockers and Musicians – A Thirty-Year Retrospective                     

Written by   

One of the benefits of a career in music is working with inspiring colleagues. These individuals promote artistic growth, offer pedagogical insights, and present different perspectives on professional issues. Thomas A. Brantigan is currently Director of Traditional Music at Central Presbyterian Church in Towson, MD and provides many excellent performances to his community annually. Working with Brantigan for many years in concert settings has been a pleasure. After learning that he in fact published “The effect of beta blockade on stage fright: A controlled study,” the first study in America supporting the effectiveness beta blockers in alleviating symptoms associated…

The Ethics and Legality of Beta Blockers for Performance Anxiety: What Every Educator Should Know     

Written by 

Educators are required to make many pedagogical decisions, and fortunately, most are quite simple and do not necessitate major ethical considerations. Some decisions might come easily—for instance whether to copy music for a page turn or view a video on YouTube. However, others are not straightforward. In particular those that pertain to beta blockers raise many legal, ethical, and medical issues. Many educators have not taken the time to consider seriously or research the implications of using beta blockers for performance anxiety and, even more crucially, of recommending these drugs to their students.

Are students who study with teachers who do not include beta blockers as a possible solution to severe performance anxiety at a disadvantage? Do teachers who recommend beta blockers to students make a poor ethical decision: one that could even pose severe legal consequences? There is no doubt that educators are faced with an increasingly litigious society, and having the knowledge regarding specific legal issues has become extremely important…