Anticlue

Top Ten Billing Errors

This is interesting, TrailBlazer has identified the top ten billing errors for texas medicare part b. This will be done quarterly through a data analysis program.

<--- Snipped from Site --->
1. Duplicates
2. Bundled Services
3. Facility Information
4. Beneficiary Eligibility
5. Medical Necessity
6. Provider Number Missing
7. Medicare Secondary Payer (MSP)
8. Non-covered services
9. Unique Provider Identification Number (UPIN)
10. Modifiers

Wouldn't it be sweet to use the same idea on professional and technical claims in a health care enterprise? That way you look at the constraint that gives you the most issues, and identify probably several root causes. Much better than expanding a bunch of resources on 1 account or 2 account problems in my humble opinion.

Fair Labor Standards Act & Computer Employee's Exempt Status

Looking for a little info on the exemption status with the changes under the FairPlay act regarding overtime and exemption? Check out these sites.

Fair Pay FactSheets by Exemption

The Hay group's analysis of the rule.

Heads Up! Grouping the Updater Woes and Wows

I was kinda serious about those of us just going off an madly applying the updater without testing.

For the bleeding edgers, Sean points out the ole truth, read the manually (or at least assign someone to) from this house of fusion mail.

Mark also found an issue with cfinvoke and the ill working duplicate function.

And in the forums we have a couple of strange errors and the admin again.

On the wow side of the house, Ray Camden got confirmation of two resolutions to previous problems.

So I'm going to let those bleeding edgers find most of the woes and wows for me ahead of time.

Leadership Syles

There are several different styles of leadership in the world. Some are good at one time others are good at another.

Directing - Telling others what to do
Facilitating - Coordinating the input of others
Coaching - Instructing others
Supporting - Providing assistance along the way
Autocratic - Making decisions without input
Consultative - Inviting ideas from others
Consensus - Problem solving in a group with decision - making based on group agreement.

Security and Healthcare Applications

System Security Policies are needed for any healthcare related application. These policies will help to standardized security practices throughout an institution.

One of the main items needed for security is to look at things from the point of restricting access. Only allow users access to the data they need to see. Otherwise confidentiality issues may occur. Its an interesting mix balancing the patient's right to privacy and appropriate access levels of the system users.

Also into the application it is best to have an auditing mechanism architected into the main solution. The auditing functionality includes who logged in, what did they do, when did that do it and from where did they access the system. Include in the auditing a way to determine if the application is logged into from home through remote access. Beware of remote access plans that nat everyone's ip to the same thing. If there is a systematic way to examine the audit trails of an application for a breach of confidentiality, its a very good thing.

Another item to consider is how long until the application times out. For instance, no application should be available above 30 minutes between keystrokes or mouse maneuvers. Have a standardized timeout set for the institution, and have that added to all applications.

Its easier to have a single signon, but this needs to rotate passwords frequently every 100 days. Passwords should be complex, not the work password for instance. The authentication may include who you are, what you know, what you have, and maybe even where you are.

It is a good idea to have a basic set of security practices detailed and agreed to with all stakeholders.

Check out SQL Express

Looking for a development db that acts like SQL Server? Check out MS SQL Express, not too bad a solution for development on your local pc.

CFMX 6.1 Updater

A little over a year, and the CF MX 6.1 Updater has been released. Find the info here.

So how many people are testing and how many people are just placing into production?

Are you done yet?

How far are you along with that task? Are you 50% done, 60% done, 77.77777% done? I hate this question, and after a little research I think I've come across an idea I like alot more.

We often have to do progress reporting for a task, and then estimate the percent complete for the task. This is a time consuming exercise riddled with unintentional misconceptions. Well, functional testing is 50% done, but we still have to test the other half of the application. Whose to say that half won't take twice as much time if a major issue is uncovered?

So what's the solution, it is pretty simple. There are three rules, 50/50, 20/80, 0/100, here is how it goes. For the x/100-x rule, when the task starts it is immediately completed by x percentage, only when the task is completely finished and closed out it gains the remaining 100-x percentage.

So for instance, for the task of functional testing, as soon as we start we are 20% complete. We maintain this status until we have completely finished functional testing, and at that time the task becomes 100% complete. A much more systematic method than random estimating.

Software Engineering Links

These are a couple of links for to review key concepts.

The Software Engineering Body of Knowledge.
The Capability Maturity Model

Using what you know

The "not invented here" syndrome hits alot of different places in different ways. In managing projects, one of the very first steps should be to look at other previous projects for something similar. It just saves alot of time and headaches in learning from others.

The creation of and maintainence of a project repository is just very very useful. It also shouldn't be locked away from different groups. If you have a functional organizational structure, different groups should be able to see others projects.

What is in a project repository? Well it should contain the project plan materials items. A good items is to have the charter, risks and issuesl, the schedule with slippage, scope of work, work breakdown structure, the change control plan, how communications where handled, what the risks where, and the budget for the project. Any correspondence regarding the project should also be maintained within the repository. Also the estimates and resources needed for the project. One of the more important items, is the review of lessons learned from the project.

So once you have the repository in place, use it. Its best to start first thing in the initiation phase, look at what has been done and what worked. look at what didn't work and if applicable apply the recommendations to the new project.

RegExLib

Need a regular expression. Check out RegExLib. A good library to find what one is looking for.

Server Impact

In the event of a server downtime, it is a good idea to get a plan together of how to recover. A tip, don’t save it on the server that is going to be down.

Things that I have come across that would be helpful to comprise ahead of time are as follows:

Stakeholders

Who are stakeholders in project management terminology? A stakeholder is someone who is affected by the project or someone who affects the project. So who are these mysterious stakeholders?

There is the project manager, this is the individual responsible for planning, communicating, assigning tasks, gathering identified issues, ensuring there is quality to the project, coordinating training on the project, tracking the benefits of the project, and providing the deliverables are on time. If it is where you make your bread and butter, you are affected by the project.

Another stakeholder is the customer or business associate. This is the group who will actually use the end result of the project. We are all affect by something that is going to change the way we work.

The project sponsor and executive sponsors, who provide the money for the project, are obviously stakeholders. I think we are all affect by our money is going.

The project team are all stakeholders. This is the group of people who are working on the tasks of the project. Interest arises from this is either work to be done, or work in progress. The work that needs to be completed affects those who are doing the work.

Now here is the political trick, let’s say you know someone who is none of the above, and yet still influences the project. Guess what another stakeholder has been identified!

A tip to stakeholder management, and i know it is anal, is to keep a matrix like the one below. It really helps if you need to turnover the project, get new manager, or some other reason you start getting asked why?

Problem Solving Tips

How to go about solving a problem is critical.

First, Gather the facts. Determine what are actual facts and what is suspicion or the gut feeling. Be specific and actual about the facts, don't have alot of emotion. Clearly list all relevant details.

Next, brain storm about the possibilities, consider various solutions. By the way it is best to brainstorm with others or differing skill sets.

Then analyze the possibilites objectively, consider the consequences of each alternative. What is the cause and effect of each action? And probably the most important question, is that if you were not involved, what would you suggest?

Finally weigh the impact. Is this something you can live with? What is your gut saying? What hunches do you have about other reactions.

After you have the best solution, go forward and solve. But at least go through the steps.

Pricing System Software

Out of the microsoft columns on the business of software comes an informative piece on pricing software.

Top Ten Innovators

I was catching up on old emails this morning, and I noticed the amdis top ten innovators. Article found here.

<--- Snipped from Article --->
Reid Coleman, M.D., medical informatics officer at Lifespan, Providence, R.I. Coleman led implementation of computerized physician order entry at Lifespan, a multi-hospital delivery system.

Physician Directory Standards

This is a good step, so I'm sharing it. The National Committee for Quality Assurance has recommendations of what a standardized physician directory should offer customers when looking up a physician.

The recommendation can be found here.

Scope Changes

Scope changes happen all the time, its a part of business. What we do is not an exact science, its difficult to calibrate. There are repeatible processes, but we aren't in the business of making 1000 lightbulbs. We are in the business of delivering technical solution to make the business run.

So when one has a project, and a change occurs, don't stone wall every one about the change.

Just simply quantify it, state the impact on the duration of the project, any new risks or issues that arise, if the cost of the project is increase and the impact of that upon the budget. Also clearly define the business value of this change.

Barriers to CPOE

Health affairs has a couple of hints on overcoming the barrier to a CPOE implementation. The complete article is found here.

<--- Snipped form article and summarized -->
Overcoming resistance.
(1) Strong leadership: Hospital leaders need to be firm believers in the benefits of CPOE and demonstrate a commitment to the implementation. They need to be in a position to deal with the changes that arrive with a CPOE implementation.
(2) Identifying physician champions: Their knowledge of their workflow assist tremendously in selecting a vendor, and they can help facilitate the benefits of the system and communicate the physicians population concerns to the project implementation team.
(3) Addressing workflow concerns: Listening to the customer population is essential here, in addition to having adequate training and assistance available.
(4) Leveraging house staff or hospitalists: The simple fact is physicians-in-training have a higher level of comfort with technology. They can provide valuable feed back on how to improve the product.
Overcoming the high cost of CPOE
(1) Realign the hospital’s priorities to focus on patient safety: Simply reducing medical errors interests everyone.
(2) Measure CPOE’s impact on hospital efficiency: A CPOE implementation may correlate directly to improved hospital efficiency. Some benefits to look for are reduced delays in patient care through improved communication and standardized procedures. So start collecting the baseline data sooner than later, the quality management department can be a huge aide.
(3) Improve system interoperability: Basically standardize in the industry what CPOE systems interoperability means. If systems can work well together and communicate well, plugging a CPOE in place is easier that the other scenario.
(4) Provide third-party payer incentives for implementing CPOE: CPOE costs are borne entirely by hospitals, however incentives from government or private insurance can help to alleviate som of the costs.
Overcoming vendor and product immaturity.
(1) The vendor must be committed to the CPOE market. Read investing R&D dollars in the CPOE market
(2) The vendor must be ready to identify hospital workflow issues and adapt its product accordingly.
(3) The vendor must commit to a long-term trusting relationship with the hospital, because successful CPOE implementation might take years.

The effect of silos

We all know about single points of failures. That's the one critical point where if something goes wrong, everyone is in trouble.

What's bad is when that is a single silo and one person is responsible for the entire system.

First thing that happens is poor communication, somewhere along the lines something becomes disconnected and one part doesn't inform the other part.

Next, there isn't alot a sharing going on. Good ideas and lessons learned are lost when people stop communicating. Individuals end up individually reinventing a wheel, that the group has collectively made if they would only talk to each other.

The poor communication causes a reduced awareness of other initiatives and sometimes the silo begins to resent that not everyone else is understanding the importance of the silo. Or even the workload of the silo.

Silos also breed a lack of standardization and consistency, you can't have standardized practices if you don't communicate them.

In the long run a silos will be of a higher cost, because the same lessons learned are repeatedly in multiple ways by individuals instead of collectively by the group at once, and the brainstorming for a great idea is lost in the midst of single mindedness and purpose.

Commitment to Coworkers

A teammate of mine today sent this to me, I think it is very good, and I'm sharing it here.

Commitment to My Co-Workers

As your co-worker with a shared goal of providing excellent care to our consumers, I commit to the following:

I will accept responsibility for establishing and maintaining healthy interpersonal relationships with you and every member of this staff. I will talk to you promptly if I am having a problem with you. The only time I will discuss it with another person is when I need advice or help in deciding how to communicate with you appropriately.

I will maintain a relationship of functional trust with you and every member of this staff. My relationships with each of you will be equally respectful, regardless of job titles or levels of educational preparation.

I will not engage in the 3 ?B?s?
(bickering, back biting and blaming)
and will ask you not to as well.
I will not complain about another team member:
and ask you not to as well.
If I hear you doing so I will ask you to talk to that person.

I will accept you as you are today, forgiving past problems and ask you to do the same with me.

I will be committed to finding solutions to problems rather than complaining about them or blaming someone for them and ask you to do the same.

I will affirm your contribution to quality consumer care.

I will remember that neither of us is perfect,
And those human errors are opportunities,
not for shame or guilt but for
forgiveness and growth.

Original found here.

The Evil Side of IT Governance

CIO.com has an article on IT Governance gone bad entitled, Stop Measuring Performance and Get Something Done. It lists a couple of stories including one manager who instead of working with the customer department, reported the departments failure to provide requirements for the project within the IT Governance Reports.

IT Governance is basically common sense, and working on the work at hand is also basically common sense. The article is incorrect in stating "Stand up and deliver—because well done is always better than well said" That's not really true, you can be doing a fabulous job maintaining the operation so that everything seem seemless, but if no one in the customer community knows that or your manager, then the work has no value until you are not there to do it.

IT professionals need to be good at communicating the work being completed and doing the actual work. The trick is balancing the two items and still being a valued resource to the institution.

Production Changes on a Friday

I think there needs to be a golden rule in IT, basically to have a day of the week chosen for production changes being released into the environment. Or at the very least, a day when changes should not be released.

A golden rule should be not to place changes into production on a friday or before a long weekend. Also not to place significant changes into production before a key participants vacation.

Key exceptions, implementing a brand new major system, like hospital registration. Do it on a Saturday, and have everyone available to support it onsite.

Last friday, a vendor dropped by to say hi, and examine a couple of issues. My teammate had been working on these operational issues for a while, and the business is still able to function.

So as I'm coming back to my cube, I see my teammate and the vendor heading off to the computer room to implement a new system upgrade. So I take the opportunity to stop the unscheduled upgrade, and enlighten the vendor on our change management policy. Later on I review the same policy with my teammate again.

It is a pretty good policy. Basically all of the application it groups leads get together on Friday morning from 9:00 - 9:30 am. We review the changes going into production to ensure that several factors are covered. Customer acceptance has been completed. The customer community and technology has had the change communitcated. The change was tested with this plan. We can back it out if necessary and here is how. There are people available for support if there are problems. The beauty of group meeting is that everyone hears what is moving into production and when. If you are under the impression that there may be a ripple effect, one can voice the concerns before the ripple effect hits, instead of being paged while on the way to the boat Saturday afternoon.