Anticlue

International Institute of Business Analysis

Requirements development and gathering is a desperately needed set of skills in Healthcare today. Everyone seemingly wants the same item, but the variations is just off enough, so one process at one location will not work for another process at another location.

Understanding what is being asked for and what is needed is vital. So if you want to tool up and check your worth, another professional organization has been created.

Check out the International Institute of Business Analysis.

Rails 1.1 Released

A nice milestone in the ruby on rails saga came and went this week. Ruby on Rails 1.1 was released.

Being honest and just getting right down to the whistles. RJS adds great comfort zone functionality to Rails. Basically it allows one to write javascript in Ruby, and taking the concept a bit further we can write Ajax application’s Javacript in ruby.

ActiveRecord has been enhanced with polymorphic associations, nested-with scope, aggregated calculations and a couple other nice to haves.

As for testing, integration test have been added. This insurance that the application works as intended across the continuum of controllers and actions.

For the complete list of new functionality, check out What’s new in Rails 1.1.

Zend competition for PHPEclipse

In the that will be cool category, I came across a zend proposal for a PHP IDE in eclipse. Has a couple more features than PHPEclipse, and a couple less.

Reporting on File Transfers

As organizations grow and more integration is needed. The cobweb of integrated systems becomes a management and security risk as time continues. A product to check out is software assist's FTP/Reporter. FTP/Reporter reports all FPT activity on mainframe and distributed systems. With canned reports, one can look at what is happening to sensitive data to monitors for failed transfers.

I want a new PC

The PC refresh. Everyone wants a new one, and there just is not enought to go around. For this week, I don't think there was a day, I was in any particular department where someone didn't ask me for a new computer.

We are currently going through the process to eliminate the oldest of the PC's. Through budgeting we have received funds to replace the NT4 workstations. Yes, I know, NT4. But this has sparked the bug, and the questions go, can I have a new PC?

Gartner has recommended for the PC's replaced between 2003 to 2005 should have a useful life of 5 years. PC's replaced this year should last for about 4 years, before needing to be refreshed. The Notebook that everyone wants, lasts for only 3 years.

My viewpoint, is that we should offer most fat client apps via Citrix, and move to thin devices. Also have as a part of the evaluation process the criteria that any app should be a web-based.

Analyzing a business problem

In order for there to be a problem, something has to be out of synch somewhere. Here are some key steps to take as a part of analyzing a problem.

First, it is good practice to identify what is occurring incorrectly and how this is an obstacle to obtaining the objective.

Next it is a good idea to obtain the frequency of the problem.

Next one has to determine impact. Impact is the where it occurs, in what processes. Are there contributing technological factors? Most important consider assessing the impact in dollars, resources, opportunity cost, customer service and as an obstacle to the organizational goals.

As a next step identify any other dependent processes that are affected by the problem.

Finally if possible, validate the problem in hard stats covering who, what, where, when, and how must time and cost.

Once analysis is complete, its time to come up with solutions. As a part of the process one need to consider the cost to implement and monitor the solution, also what business processes will be affected. Reveal any value that the solution will add such as increasing revenue, lowering costs, improving turn around times. Identify the costs for any technologies to be acquired, changed or improved for supporting the solution. Also it is a good idea to identify how to measure the solutions effectiveness.

Open Source Software lowers costs of Health IT

The California Health Care Foundation has released Open Source Software: A Primer for Health Care Leaders by Forrester Consulting.

The report is effective and thorough, and it would be good to eventually see a how to move from best of department to best of breed to best of suite to open source, as a follow up to the original report. A couple of considerations and evaluations need to occur as one ramps up to embrace an open source solution.

How much risk is your organization willing to accept? The report shows good solutions for open source as JBOSS, MySQL, and RedHat. However these are specific tools for developers and software development companies to utilize and exploit. The most successful projects for open source have been tools for developers. There has not been much success in running a corporation on an open-source system. The model is different and needs to be evaluated.

Perhaps as a move, starting small would be ideal. Instead of beginning with a Hospital Information System, begin with an item that would have sweeping success and visability without much effort. A couple of ideas that come to mind are a bed board, a standardized web-based way for physicians to re new privileges, an issues management system for projects. The goal is to have a high level of exposure and reliability that doesn’t first effect the bread and butter.

For a small physician’s practices, the avoidance of risk is even greater. Perhaps starting with open-office a well founded solution that provides the office with a word processing, spreadsheet, presentation tool, and drawing tool.

Another consideration is the level of support that is needed for the system. If you need a programmer, is that a salary expense you can deal with? Or is it more important for the practice administrator to be able to call someone to help with issues? For a hospital, hopefully they are skilled with implementations, being skilled supporting developers who need to be familiar with code is a different story. For this would be a major culture shift, hospital organizations have not been supportive of maintaining an in-house developer shop. Just check out the Joel Test

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

How many yes answers are there in your organization? Here is a more dangerous question, are any of these even seen as having value? When asking the IT staff and leadership these questions, how many understand the terminology? How about the execs?

Another consideration is the different state regulations on needed data and billing requirements. Also larger institutions need to have the flexibility to track at a data level different values for performance management. The open source solution needs to be flexible for these additions and considerations as one looks at a hospital information system. Standardization is ideal, but it is rare that the need for customization is eliminated completely, with all packages.

Open-Source may be the solution of the future, but we have a lot of cultural changes as an industry that need to be addressed first and the flexibility of the solution needs to be well proven before the culture change will occur.

Other views:
Tim’s medical connectivity
Shahid’s the healthcare guy

Collecting the right data for the right reasons

As being a part of IT, a large part of our job is to provide systems for data collection. The end purpose of data is for it to be transformed into information that answers business questions, monitors processes, or provides an error listing of the data that needs to be tweaked.

So when implementing a system, there needs to be an assumption that the fields needed for entry will also needed for reporting purposes. For the analysis a couple of questions are needed.

1. Why are we collecting the data? Pretty self explanatory but it does shed light on to the need for the data.
2. How will the data be extrapolated? This is determine the frequency or reporting and the manner, it is granular and detail level, or will it be aggregated and summarized. What various groupings will be needed?
3. Where will the data be collected and where will the data be reported? This determines the point of entry and the point of reporting. These can be two completely different systems, so an integration plan may be needed.
4. What data will be collected? Digging into this question is really necessary because as the data brings information, the analysis of that information will result in the request for more data. Look at assumptions and cover both the foreseen conclusion and the opposite direction.
5. Is there a timeliness to constraint to when the data will be collected? Does this effect the sample or population.
6. Is training needed for those collecting the data? If one is seeking to obtain a new data set, training is probably needed by those who will be responsible for gathering and entering the data.

What would solve the technology chasm in healthcare?

Ah what a question, this morning, I read the following blogsphere entries, and I think it really brings to light the intangible reason for the gap between where we want to be, and where we really are in healthcare IT.

High tech in health care IT? Not exactly. by Roy Johnson
Guest article from Nurse Janus – From the Hospital to the Vendor world

A wide gap arises. That vaporware application may be the best thing since sliced bread, but is it worth the organizational risk?

From my experience working in healthcare, the need for IT to be a strategic partner with business can not be understated. The repercussions and fallouts are throughout, and they do not change with just a change in IT leadership or vendor solutions.

Our problem as an industry is not to be government mandated to be brought into the new technology arrangements. Our problem as an industry will not be solved by leaping from one frying pan as vendor provided apps to another skillet of the open-source bandwagon. Our problem is that we have to intelligently use our limited resources to have the most effectiveness where it is needed the most. That is a hard road to travel, especially since we are coming out of the financial period where resources were stretched as long as possible. So several items need to be revamped and updated, as we proceed down the road less traveled.

A fact is that a hospital, SNF, or practice office does not have unlimited amounts of resources, ie the term non-profit. However on the other side of the coin, the vendors financial structure is completely different, and they need to justify their finances to the board or stockholders. The other fact is that renewing and changing vendors or IT leadership is only two thirds of the tripod. The tripod is the business partner, IT leadership, and the vendor. With this mix the final fact is that all need each other to be complete, and they can not stand on their own without the other. Until that realization occurs the ship will never be able to sail the course, because we as a whole will not be able to execute a project.

Project Management Success

Ah the soft skills, the items that assist with project managment success but are rarely mentioned. Yesterday, I was presented with this listing, and I thought it was definitely worth sharing.

Twelve Rules for Project Management Success

1. Gain consensus on project outcomes
2. Build the best team that you can
3. Develop a comprehensive, viable plan and keep it up-to-date
4. Determine how much stuff you really need to get things done
5. Have a realistic schedule
6. Do not try to do more than can be done
7. Remember that people count
8. Gain formal and ongoing support of management and stakeholders.
9. Be willing to change
10. Keep people informed of your activities
11. Be willing to try new things
12. Be a leaders as well as a manager

BI Solutions Buy, Build, or Ignore

An interesting lunch question arose the other day, at which point does one decide that writing a report and delivering via a web tool is just not practical and a larger tool is purchased, ie. Business Objects. To take the question a bit further at what point is the tool no longer applicable, and we go to a vendor provided BI solution.

I think there is a point of epiphany that occurs between each phase, and it really depends on what is important.
For example, is the business community starved for information? Is the IS staff all using languages of choice to create reports? Is there any standardization at all in the reports? What is a new report request delivery time? How are reports delivered? How important is the historical information? Why is it that important? Answers to these questions, can illustrate the need to move to a larger tool.

Next however, once the tool is in place, how to get the data to a informative solution. Sometime a vendor tool has simplified the data intergration aspect. Imagine in healthcare having the clinical, patient management, patient billing, practice billing, ERP, HR and others all in one centralized place. The other benefit is the multitude of canned reports that are delivered as a part of the implementation. The vendor also has the benefit of being an expert, so they can help with planning, implementation, and maintenance. It is nice to have a place to go to ask a question, especially when staffing is a concern. If you do not have the developers in house, its definitely a good route to take. Also if you know you will not have the budget.

Another thought for a vendor solution is to go with something that you know integrates with your other business apps. Have this as a question in the evaluation process.

For the vendor solution, how close is the data load to real time reporting? Is there power in adhoc reporting and being able to drill down and examine the information to identify trends?

After analyzing and reviewing questions like the ones above, the path may be clear to the solution that works for you.

It is the revenge of the Spaghetti Code

Tim Bray has started a discussion on the advantages and disadvantages of PHP. One of the arguments surrounding the code is that it is spaghetti code. I am sorry, but I would beg to state that most of the code in the world today is Spaghetti Code. Concepts and initiatives have arisen surrounding moving from procedural code to object-oriented code for well over the last decade. It has been few to rare occasions, which I have heard of a business completely re-engineering every line of procedural code into a brand new object-oriented system. It is a poor argument to exclude a language based on the ability to create spaghetti code. Almost every language has the capacity to be mangled by a poorly skilled programmer as it has the capacity to be dazzling by a great programmer.