Anticlue

Medical Necessity Checking

According to a survey of 123 hospitals, published in HCPro Inc.'s Medical Records Briefing, 57 percent of hospitals stated that they check for medical necessity at registration, followed closely by 52 percent in the ancillary departments at the point-of-service. Only 17 percent reported checking medical necessity at the physician's office where the order or admit diagnosis is written. (Percentages add up to more than 100 percent because some hospitals check medical necessity in more than one location.)

Project Management and HealthCare IT

Recently, I came across this article relating to Hospital IT Practice and Project Management.

Startling factoids below:
<--- Snipped from Article --->
Of the organizations surveyed, nearly 50 percent have 1-4 major IT projects currently under way. At the other end of the scale, about 16 percent or our respondents indicated that they have 17 or more major IT projects currently in progress. This is a relatively high number. For example, in re-engineering projects, most authors recommend no more than 4-5 major projets at once.

When Canadian hospital IT projects failed in the past, what caused the failure? We asked our respondents to rate the relative importance of various factors. The top five factors, said to be inadequate, were:
• Levels of funding;
• Control of scope changes;
• Operational support;
• Time;
• Senior management support.

Let's review these factors, most probably can be laid out easily. One of the first things to do in reviewing a project is before it starts, obtain a rough idea of how much it is going to cost. Consider the implementation costs, and the cost of maintaining that product over 5 years. At this point in time, there should be a clear understanding of whether one is purchasing or building the solution. This is a business case for providing the solution and needs to be presented to senior management. Probably best as a part of the budgetary process.

Next, get a clear understanding of what the product is suppose to do. A long to do listing, or "functional requirements". This should be done prior to any vendor viewings, and define an RFI, then even an RFP.

For the selection process, keep the long term cost of the product in mind, and as a criteria for the solution. (Have a deliberate purposeful plan for how to select, who is involved, and how to evaluate, and a timeline sequence of steps set up) After the product is selected, have the plan of implementation and maintenance needs created.

Therefore before the actual product is contracted, you have proactively addressed the Levels of funding, the operational support, time needed. You have the scope of work, so any scope changes severely affect the project should be documented. One has also needed to obtain senior management support for the project. These basic steps provide a greater opportunity for success.

Why Implementations Fail?

An interesting study out of Peerstone Research hits the high points on why implementation projects fail.

I think the study really speaks for itself.

Netscape Dead

Caught this the other day, and was thankful that this is finally true!

Netscape 4 is officially dead (less than 0.4% usage!)

Why automate testing

I'm a huge believer in automated testing. I know it takes time, money, and resources to set this up, but here is my opinion.

Over time the quality of testing decreases with any software product if there is not an automated testing solution. The reasons for this are many, first people become complacent if everything has worked well in the past. Suddenly not as many resources are dedicated to the testing process. Another symptom of this problem is over time people leave and the needed knowledge transfer is not there. Another factor is that if it took 5 resources to fully test the last release, and a new release with new functionality is being added. What's the likelihood that no new resources will be added to the testing? So what are you going to test, the new functionality or all of the old functionality?

An automated testing tool, with dedicated testing scenarios, only has to have the new functionality and lessons learned from the last testing base added. The invested resources leave a better quality product in the long run.