Anticlue

cfeclipse

Find cfeclipse here and a nice little how to here.

Norm of Reciprocity

The norm of reciprocity is the human tendency to respond to the actions of others with similar actions. If we are treated with contention and distrust, we tend to treat others with contention or distruct. If we are treated by someone with a warm friendly manner, we tend to treat others in a warm friendly manner.

Hostile interactions evolve out of one's tendency to take an exaggerated view of others' perceived hostility or unreasonable behavior. Then the exaggeration causes one to reciprocate with negative behavior. These hostile interactions end up being a self-fulfilling prophecy with each side behaving equally negatively.

Some triggers of this behavior are Naive realism, where people tend to assume that their view of the world reflects the reality of the world. Confirmatory bias is another trigger where we seek to confirm our beliefs or to find flaws. Also accuse bias is another scenario where someone intentionally does one harm, then it is human nature to hold the party responsible for a long time. On the flip side of things, excuser bias is the tendency to focus on factors outside of our control, while turning a blind eye to factors within our control.

Cooperative interactions is triggered by people's perceptions of fairness, the ability to realize that reasonable people will come to different conclusions, (many ways to skin a cat), the ability to accept responsibility for problems, and finally the ability that you don't blame others for the problem exclusively.

Soarian Clinicals Go Live

From Forbes, comes the following snippet.

Siemens Medical Solutions announces that three more healthcare facilities have gone live on clinical modules of Soarian(R), Siemens new generation healthcare information solution:

Fox Chase Cancer Center of Philadelphia, Pa. has gone live on Soarian Clinical Access, the healthcare industry's only seamless integration of the complete electronic patient record with medical technology.

EMR & Time constraints

An interesting tid bit I came across today was a statistic for patient "face time" with physicians. The statistic was that for an hour spent on site about 30 percent of that time is spent with a physician in some practices.

So why am I interested here? Clinicians do hard good work, they don't need to be buried in a dump of procedural documentation and forms. If the "face time" with physician is that low in a practice setting, I'm guessing it is lower in a hospital situation.

When looking at implementing an EMR, remember that clinicians time is valuable and the purpose of the system to allow the user a way to maximize use of their time. Seriously how much would you like to utilize a system that encumbers you?

Fireworks for the forth

Some fireworks in anticipation of the 4th.

Query Result Caching

Query result caching is ideal for querys that don't change often, normally the ideal is to obtain values from a lookup table or when dealing with the next n records.

One can specify caching withing the <CFQUERY> tag via the CACHEDWITHIN and CACHEDAFTER attributes. A side note is that one should use either the cachedwithin or cachedafter not both simultaneously in the same query.

I like using the CACHEDWITHIN attribute and setting the applications query timeout parameter in the application.cfm with a url override if we need to immediately update criteria.

Yesterday Macromedia released a tech note regarding the behavior of cached queries when maximum number is set to 0. Basically setting the value to zero in the administrator causes no upper limit to be set, and all queries with caching indicated are cached. This will eat up all server memory (ram and pagefile). It use to be in CF5 that this value represented the number of queries, I think it now represents the memory size.

So if you use query result caching alot, one probably needs to set the Maximum number of cached queries parameter intelligently. One of the goals is to keep the cached queries in memory (ram) but not on the pagefile. The reason being is that the pagefile will affect response time. Also keep in mind that if the number is set too low then the oldest cached query is just dropped beforehand.

First figure on times of high load. So determine the memory calculation of the record sets (number or rows returned * bytes per row). Add in 1024 just for overhead and wiggle room. Now you have an intelligent number one can play with via the 100 default. Also as new applications are brought online, determine if this parameter needs to be reset or new hardware needs to be purchased. Just another one of those things to add to the proactive monitoring list.

Security & Programming

Let's talk for a minute about security and programming. The problem is sometimes with science "oh can we do this" is soo much cooler than "oh should we being doing this".

So how does one protect oneself from the threat of a possible attack? Well do the simple things first.

First employ a mechanism of database hardening for the backend. In otherwords only install what is absolutely needed.

Next change the default accounts, and change the network address. For example change the MS SQL server TCPIP Port from 1433 to something else. Put a very very secure password in the sa account, and disable the guest account on the windows machine.

The next stage is auditing have a detailed auditing practice, and review the practice. The auditing should cover who was on the box when and what they installed, for an application who changed or even looked at what data elements when.

It is a very good idea to be up to date with all security patches. The next one is coming around July 18th, just a heads up.

Use encryption when necessary. Ideal times are messages and using a public key to encrypt a digital signature.

Use a strong application design, and review it with others, be very wary of dos attacks and load balance the app.

These are just a few tips, I'm sure others have more.

An Element or An Attribute

For newbies with XML there is one basic thing to know. How to label the data in the most effective manner for future growth.

Attributes cannot be further drilled down into subelements. However Elements can be broken down into more detail.

Elements are the easier way to go if you are looking at standardizing the schema. Attribute need slightly more complex coding to be able to handle their existence.

Healthcare reporting and XML

I'm not a believer in incumbering a business process with paper reports. I've seen it bring businesses to their knees. However I was playing with XML Maps in Office 2003, and had another one of those ideas that I'll give up to the community in the hope of improving healthcare in America.

XML and healthcare is starting to take off, there is the CCR, HL7 ver 3, the EHR, alot of benefits looking at the large picture. So I'm going to talk about a small portion, the reports of the billing system and finance.

I'm going to propose that an organization with time, looks at generating an xml document instead of a paper report from the respective cobol system. Why you ask? Let me introduce you to MS Excel 2003 XML Maps.

First let's get a sample report into an xml document. I've made up a readmission report here, that is an extract of the medicare and medicaid readmits within 30 days as inpatients. Here is my sample document.

<?xml version="1.0" encoding="iso-8859-1"?>
<ReadmissionReport version="1.56" date="06.27.2004">
   <readmission>
      <PatientName>Elyse Nielsen</PatientName>
      <PatientID>1234567</PatientID>
      <VisitID>200111222</VisitID>
      <AdmitDate>Sat, 26 Jun 2004 09:28:00 -0500</AdmitDate>
      <Payor>Medicare</Payor>
      <NurseStation>Station</NurseStation>
      <RoomBed>Bed</RoomBed>
      <Service>Physiciatry</Service>
      <PreviousDischargeDate>Sat, 5 Jun 2004 17:21:00 -0500</PreviousDischargeDate>
   </readmission>
   <readmission>
      <PatientName>Test Patient</PatientName>
      <PatientID>9234567</PatientID>
      <VisitID>400111333</VisitID>
      <AdmitDate>Fri, 25 Jun 2004 09:28:00 -0500</AdmitDate>
      <Payor>Medicaid</Payor>
      <NurseStation>Station</NurseStation>
      <RoomBed>Bed</RoomBed>
      <Service>Cardiology</Service>
      <PreviousDischargeDate>Sat, 5 Jun 2004 17:21:00 -0500</PreviousDischargeDate>
   </readmission>
</ReadmissionReport>

In a new excel doc, under the Data Menu Item, there is XML, choice xml source. Click on the XML Map button and select your xml file.

Now just select and drag the elements you want to report on. Once this is set up for each individual, with the desired sorting. Import your xml document.

A nice report that you can manipulate. Imagine if this was the daily unbilled report able to be analyzed in a totally different manner.

So how should one go about doing this, well alot of organizations are looking at document management. But let's go this route, first have the printed reports dumped to a folder on the network somewhere. Have the documents from the nightly report well named.

The one truth from reusability is that most programmed cobol reports have the same format for the header. Normally it hasn't change much since the application was built. There is the TITLE-LINE, COLUMN-HEADINGS, and DETAIL-LINE in the working storage of the cobol program. If you are really lucky these have been saved as copy members. (Slight aside: I do not know COBOL, I swear it, no one can make me state any different 8) These structures will have the text layout needed to pull off the field names and report headings.

01 TITLE-LINE
    05  FILLER                              PIC X(20) VALUE SPACE.
    05  FILLER                              PIC X(18) VALUE "Readmission Report".
    05  FILLER                              PIC X(20) VALUE SPACE.
    05  FILLER                              PIC X(5) VALUE "Page:".
    05  PRINT-PAGE-NUMBER        PIC ZZZZ9.

01 COLUMN-LINE

    05  FILLER                              PIC X(15) VALUE "Patient Name".

    05  FILLER                              PIC X(10) VALUE SPACE.

    05  FILLER                              PIC X(15) VALUE "Mrno".

    05  FILLER                              PIC X(10) VALUE SPACE.

    05  FILLER                              PIC X(15) VALUE "Serial".

    05  FILLER                              PIC X(10) VALUE SPACE.

    05  FILLER                              PIC X(15) VALUE "Admit Date".

    05  FILLER                              PIC X(10) VALUE SPACE.

    05  FILLER                              PIC X(15) VALUE "Payor".

    05  FILLER                              PIC X(10) VALUE SPACE.

    05  FILLER                              PIC X(15) VALUE "Nurse Station".

    05  FILLER                              PIC X(10) VALUE SPACE.

    05  FILLER                              PIC X(15) VALUE "Room Bed".

    05  FILLER                              PIC X(10) VALUE SPACE.

    05  FILLER                              PIC X(15) VALUE "Service".

    05  FILLER                              PIC X(10) VALUE SPACE.

    05  FILLER                              PIC X(15) VALUE "Previous Discharge".

    05  FILLER                              PIC X(10) VALUE SPACE.

What wonderful file data, so here we go have an application that reads the report, determines for this report I need this info from the cobol program, (ascii dumped somewhere), and then coverts the report into an xml file. Wouldn't CF's File Search and <CFXML> tag be great here.

Finally provide training to the "computer experts in the billing department"
on how to import and setup throw in a couple of excel's statistical tweaks. Happy enabled customers with the data in their control not held hostage in an antiquated system.

I'm sure a couple people reading this could improve this idea even farther, so please share.

Possible Threatening Virus

Looks like there is a new virus out there, this time that is quite threatening.

It comprises IIS Servers, appending a js to a webpage that installs a backdoor on the user's computer. The js downloads a .exe that has been shown to include keystroke loggers, proxy server, and other things.

The attack exploits the vulnerability in Microsoft Security Bulletin MS04-011 Security Update for Microsoft Windows (835732)

You can find more info here.

Patient / Physician Email Guidelines

Everybody loves email. Heck look at the gmail account craze. Email is a very convenient way to communicate and enhance the physician patient relationship.
But it does have its risks, and very few physicians are interested in using in email, liability being the overall concern with confidentiality a distant second. (survey here)

As Jacob has pointed out, email isn't the greatest from a provider view. Email can't be relied on for confidentiality, unless the contents of the message are encrypted. Also the reciever needs to be validated, and the sender authenticated. Also consider that the home email account maybe read my multiple members of the family. Another concern is sending email to the employees work account, that may lead to inopportune disclosures to the employer.

A couple of groups have gotten together to start to address the issue, but they may need to update their information.

Journal of American Medical Informatics Association Email Guidelines (1998)
American Medical Association Guidelines (2003)
Healthy Email

Use Case Template

For the change management application, that I am still toying with the idea of building. I figure that if requirements come about they can't be all that damaging. The worse thing that can happen is that when we do get approval to move forward, at least we will have something that everyone can start from. One of the things that needs to be done for requirements is the uses cases, the detailed overview and then the drill down. Below is a template for use cases, that I'm thinking of using. After a quick perusal does anyone see any room for improvement?

Prosecuting spammers

Saw this in the wsj, an ex-AOL software engineer was arrested on charges he stole AOL's entire subscriber list in order to send massive amounts of spam to AOL. His buddy sold the list to spammers.

If convicted of conspiracy, each face up to five years in prison and a $250,000 fine. 8)

The Five Dysfunctions of a Team

A good team is a precious thing, the book, The Five Dysfunctions of a Team: A Leadership Fable, really brings to light how difficult it is to get a good team together and working well. You know when you are apart of a good team and when the team needs work.

The book lists the five dysfunctions of a Team:
1. The first dysfunction is an absense of trust among team members. Essentially, this stems from their unwillingness to be vulnerable within the group. Team members who are not genuinely open with one another about their mistakes and weaknesses make it impossible to build a foundation for trust.
2. This failure to build trust is damaging because it sets the tone for the second dysfunction: fear of conflict. Teams that lack trust are incapable of engaging in unfiltered and passionate debate of ideas. Instead they resort to veiled discussions and guarded comments.
3. A lack of healthy conflict is a problem because it ensures the third dysfunction of a team: lack of commitment. Without having aired their opinions in the course of passionate and open debate, team member rarely, if ever, buy in and commit to decisions, though they may feign agreement during meetings.
4. Because of this lack of real commitment and buy-in, team members develop an avoidance of accountability, the fourth dysfunction. Without committing to a clear plan of action, even the most focused and driven people often hesitate to call their peers on actions and behaviors that seem counterproductive to the good of the team.
5. Failure to hold one another accountable creates an environment where the fifth dysfunction can thrive. Inattention to results occurs when team members put their individual needs (such as ego, career development, or recognition) or even the needs of their divisions above the collective goals of the team.

Truly cohesive teams are obvious
1. They trust one another
2. They engage in unfiltered conflict around ideas
3. They commit to decisions and plans of actions.
4. They hold one another accountable for delivering against those plans.
5. They focus on the achievenment of collective results.

I think the above is exactly out of the book. I borrowed the book from the library, and I thought the above was so important I typed it out to remember for later. I know its a geekish thing to do, but why today am i sharing it with you.

The reason is that at times, I need a place to remember that I'm apart of many many teams. I have different roles and places in several teams. Some I'm suppose to lead, others i need to actively participate in, and others i need to follow the lead of others. But my actions and contributions and light of which I accept the actions and contributions of others needs to avoid the dysfunctions. That's why they are dysfunctions.

IHE IT Infrastructure Technical Framework Sups

The Integrating the Healthcare Enterprise just put out some supplements to the IHE IT technical framework, version 1.0.

The supplements are
1. Audit Trail and Node Authentication
2. Cross-Enterprise Clinical Documents Sharing (XDS)
3. Patient Demographics Query
4. Personnel white pages

You can find all the info and forums here.

The Traffic Triad

Judith Dinowitz has a good article on the session "Programming a Network/Site to Drive Traffic Profitably from the Internet Planet conference.

<--- Snipped from article --->
David Card, Vice President and Research Director at JupiterResearch, spoke of a "triad" -- three tactics that one can use to drive users on your website to the areas that are profitable. These are:

60% of the page design devoted to Programmed Content
30% of the page for Marketing and promotional material
Navigation on only 10% of the page design

When designing a web page, it is the opportunity for the customer to experience all that you company has to offer. It is like painting a picture that informs, guides, and sells all at the same time.

Change Management

I'm toying with the idea of rewriting a change management app we have at work in my non-existant spare time at home. Toying is a good word here because that conflicts with some of my basic principals. I like to work on projects with managements blessing, the resource availability, fully architected, and using the SDLC. I know there is an application out there we can buy, I just haven't researched that yet. Also an IT goverance package was not approved in the business cases this year or next. The problem is I really don't have alot of coding time at work anymore, and I miss it. Also the application is screaming, i mean literally screaming for a new do.

The app captures the change, the impact, the hardware, the vendor, and the approval process. I'm going to be going into these more later. However, if you were going to use a change management application what information would you like captured within it?

What I'm proposing is doing the full development here on the blog, and posting the deliverables as it goes. This is inclusive of requirements gathering, design, construction, testing, and live. But I wanted to gauge if anyone thinks that is a good idea.

When to Comment Code

Use comments to explain what the code does and why the code needs to do that function. Also use comments to describe how the code performs to a newbie. Newbies will be learning from your code.

Now here is the key when it comes to coding, if the code is tricky or difficult to follow. Do not use a comment to fix code. The intent of a comment is so that someone can pick up the code and immediately understand it, not walk through the code line by line with the comments as a bible. Make the code easier to understand, try to keep it simple, and remove the trickiness.

Another item is that one should understand there is an audience that reads the comments. Comments should not convey zealous technological beliefs, the comment is not the forum for that. A discussion with the team is the forum, not the coding comment.

In CF comments should be in the CFML style (<--- comment --- >), so it is not readable in the browser.

When you make a change, comment it, and identify the date and your initials.

If you want to leave a note about a bug to be fixed or functionality to be added, place a TODO: in front of the actual comment, so people now what to search for.

<--- 2004-06-05 (EVN) TODO: Incorporate everyone'se feed back --- >

Don't delete blocks of code in production, comment them out with the date and reasoning for removal. In my opinion it is just good practice not to delete production code.

In pages have the following
<---
Author:
Description:
Parameters:
In:
Out:
Usage:
Documentation Location:
Based on:
Date Created:
Template Type:
User Owner:
Summary:

$Log:
Revision 1.2 2004/06/04 EVN
Fixed db SQL transaction

Revision 1.1 2004/06/01 EVN
Initial Version into production
--->

These really help when trying to discover the history of a project and the changes incurred.

ECommerce and CF

Craig Rosenblum has a good article on using CF and ECommerce in the CFDJ journal this month.

The idea of coding standards and project management should resonate with every project not just Ecommerce ones.

Eclipse 3.0

Eclipse is an open-source project originally out of IBM. Version 3.0 should be available for download on June 30th.

The ripple of change

Let's take a minute to consider the ripple of change. A change occurs in one place, a small insignificant change, then the ripple effect occurs. It turns out that a small insignificant drop, has many ripples in a calm pond.

Due to othis ripple of change, highly consider communication as a part of the change management process. Have a group that gets together to consider the changes going into production, and communicates the impact of those changes.

Also no matter how insignificant a change appears, always test it elsewhere first. And always have a backup for when you are implementing the change. It is just good sense and provides an excellent cross training opportunity.

Finally have at least two ways to back out a change. In technology surprises occur, and it is best if you can back them out with minimal downtime effects to the institution.

Prioritization of Projects

One of the key things that needs to be done in a healthcare organization is to centralize the prioritization of projects through the hospital administration.

It just seems to be key. First of all the IT resource pool is not vast and unlimited. Based upon 50,000 + discharges per year, the average number of IT FTE in a hospital is 83. That number significantly drops to 49 IT FTE for organizations with 20,000 - 49,999 discharges per year. (Statistic from the HIMSS Solution Toolkit May 20, 2004)

Of those employees, they don't all work for one centralized IT department. Maybe 70 - 80% do work for the IT department. Then others staff the individual departments IT staff. For example the clinical ancillaries: pharmacy, radiology, surgery, and labs may all have departmental IT staffs consisting of 1 - 4 people. The billing groups, technical and professional, will also have IT staff of 1 -2 people. If you are fortunate enought to have an academic center, they may also have IT staff of 1 - 5 people. Also the clinicians may have an dedicated IT staff of a couple people.

So here is the quintessential problem, departmental initiatives effects are not only limited to a department. The effect is far reaching and touches elsewhere, and then uses IS resources. Also the business becomes confused as to who is IT and who is not, and responsibility is very unclear.

If you bring the initiatives up a notch to the hospital administration, then you have a centralized group. This group sets the organizational goals and then IT initiatives can relate directly to the organizational goal. Departments bring the opportunities before the group, the group discusses the organizational benefits, hopefully agrees on a course of action, and then the expected result. Every so often the group reconvenes to re-establish the priorites or if adjust based upon a new iniative being brought into the fold.

Lessons Learned from Evanston Northwestern

Evanston Northwestern recently implemented an EMR and CPOE. Entire article found here.

Business Improvements:

1. Test result turnaround times have dropped


2. insurance denials related to insufficient information have fallen to 0.5 percent of all claims

Lessons Learned:

1. Have mandatory training for all users of the system to ensure clinician usage


2. Review categories of medical errors and monitor which ones should be eliminated

Planned Healthcare IT Investments

From the HIMSS Solutions Toolkit, May 20, 2004, the major planned investments within the 12 - 24 months, based upon a surveyed 954 hospitals from July 1, 2003 to May 21, 2004.

Obviously these five are interrelated. Computerized Physician Order Entry must be convenient for physicians. The most convenient way for that to occur is through either a hand held or tablet. In order to be able to do that the infrastructure of the hospital has to be updated for wireless networking and that includes network development. Then one has need convenience of doing things from home, the office, and other locations. Enter in the investment in privacy and security (remember HIPAA). Finally it won't do any good to have orders that stay within one system. There comes the interfacing and integration component. The five are apart of the sum to get to an electronic healthcare record.

Paging for errors

I wear a pager for my job. I even wear it on hours that I'm not on call due to the likelihood of someone may need some help. Several others in my department do the same thing. It is sorta the logic that if someone needs something, it is better to be available, because one day you will be calling on them for something.

That's a courtesy and should not be treated as a dependency.

The other essential item is that paging one off hours needs to be due to an event of a critical nature. The reason I'm doing a little venting is in talking to my coworkers in the area. I've heard of someone getting pages off hours for errors that have no effect to the daily business process.

Here are the characteristic of the event:
First, the paging is systematic and generated from a report that is used to work errors. These single error reports went to a printer and then were worked in the morning for the past several years. The errors occur several times throughout the night. Now, the error goes to the entire department's pagers, not just the oncall individual.

I'm sorry but that is just abusive behavior. If the errors that need to be worked in a timely manner, then setup a 24 hour shift. Have coverage onsite for 24 hours and a dedicated individual to the job.

If something changed and there is now an emergent need, communicate the need and then have a plan for 24 hour coverage in the works.

Health Care and Project Management

As of 6/15/2004, there are 844 members in Healthcare Project Management SIG. In addition, as of 2002, there are approximately 5,794 hospitals in the US. So here is an interesting question, since America is moving forward with an electronic healthcare record. How are we going to implement it if so few healthcare institutions are interested in project management? (Assumption being, the members of the Healthcare project management sig is indicative to those interested in PM)

Spam tops 80%

In pursuing my emails this morning, I came across this interesting point.

Spam in the US is around 83% of the total email volume. So with all that spam, does anyone actually click on it? Or do we all just hit delete, block, and junk combinations?

Data Integration

The heart of an organization is its data. The quality of the data will make or break a business. The interfacing of the data will either make the workload extremely easy or cripple the institution. Access to the data is also essential. Holding data hostage from the users is just wrong.

The picture should be enlarged for choosing a new system, and a part of the selection criteria considering the integration of the data as a key component. I would review all of the ADT transactions and make sure merging patient or account information works. Maintainence of the metadata is also key, it should be easily done, and consider integration. For example, wouldn't it be sweet if the credentialing system could generate a record that would update all systems with doctor information.

Sometimes looking at the larger integration picture, may even recommend going with the same vendor for the systems instead of the best of breed approach.

Medicare Part B LIDOS

Starting October 4, 2004, all outpatient and inpatient Part B claims will required a line item date of service for each revenue code.

The reason for this requirement is that the CMS's system can't process a range of service dates for each revenue code on outpatient claims. (Although the HIPAA implementation guide allows this to occur)

Please find the entire transmittal here.

Infrastructure includes the PC

I love the following scenario:

IT Gal: Hi, I'm you're friendly IT person here. I've been commissioned to update your pc today.

Customer: What does that mean?

IT Gal: We just have to install this new software, but there is a small chance you can lose your pc. Have anything important saved there?

Customer: Oh no, I wouldn't be able to continue to do my job without these files saved here. I've been working for the last 6 months on this project all saved in My Documents.

IT Gal: So how do you back them up?

Customer: What does that mean?

When considering the sanctity of data, be sure not to forget the local PC. In large institutions with very liberal rules regarding PCs, try explaining to the customer that maybe it wasn't the best place to store those very sensitive documents was on the PC. Maybe even institute a policy of what is considered recoverable, and what is not. For departments determined on using the local drives, consider usb hard drives. They are a really easy solution to use, an definitely help with restoring information.

Changes

Bringing changes into production need to be controlled. It is essential to continuing the business process. Now, sometimes outside risk factors cause changes of smaller scope to occur with a sense of urgency to divert a larger impact.

However all changes need to have four main factors.
1. Comprehensive testing of the set of changes.
2. A complete sense of the impact of the changes to the business community.
3. A way to return to the original state if problems occur after implementation.
4. A full recovery mechanism of all user data and system configurations before implementation.

Consider the Impact with TCO

We work in a business environment. While conceiving dreams of grand design in the conceptual phase of a project, it maybe a good idea to include the practical total cost of ownership. The total cost of ownership provides a clear way to define the cost of an asset throughout its life at the business. An asset can be anything from a software application (built or bought) to a new business process. A good article to review the calculation of the total cost of ownership can be found here.

Supersize Me

Saw this on the news this morning, and all I can say is oh my.

Supersize Me is a documentary film about one man eating nothing but McDonalds for 1 month. I hope he is actually able to recover.

Inheriting a weak department

Gartner has a good article on how to attack the problem of inheriting a weak department found here.

One of the symptoms of the problem described is a poor project prioritization mechanism. A development portfolio filled with pet projects is actually used in the article.

<--- Snipped from Gartner --->
Immediate Actions

8. Set a limit to the transition period. These changes will be unwelcome to some. You will have to face internal opposition — and may need to make some people redundant. While the threats of reorganization and redundancy hang over your staff, they will be distracted and less effective. Make it clear that you will make the major changes within a fixed period, perhaps three months. Anyone still employed after that can expect to stay with the business.

Requests for Work.

There are multiple types of projects with various sizes. So lets start with one that doesn't need a charter, a detailed requirements process. I'm going to refer to these as requests. So how does one determine a request for work from the IT department vs a small project.

I think it is best to define requests by what they are, not by the workload associated with them.

First requests are for routine updates to keep system tables in synchronization. Have a doctor, need to have IS update all the system tables, that's a data request. Have a new employee, want to get him added to the 15 systems with appropriate security access, request. Want a report, write a request.

Second requests are not implementing new things. Implementing a new technology, system, or interface shouldn't be a request, it should be a project.

However, if you have the basic system in place, and an upgrade comes along. That is a request, unless the upgrade calls for a hardware refresh (project).

Normally the risk for requests is low, and only affecting one department.

How do you get work?

Work comes in all variations, I go to the cafeteria, I leave with three assignments. I go to a meeting, I get meetingwork - a not as fun variation of homework. I have these emergency calls which either come to my phone, my pager, or my support queue. I have regulatory releases and system upgrades that magically show up on my desk in a fedex package. I have requests for small projects, and projects for actually large projects.

Work comes in many variations, and I'm wondering how it is handled at your department. How do you quantify and qualify what you are doing?

One of the items that has been proposed is classifying work in different categories.

First, there are emergencies, the server is suddenly displaying a jrun out of memory error or something where business can not continue.

Next there are emergent issues, there is something incorrect in a data transfer from one place to the fifth place down the queue.

Then we have requests, all system upgrades, regulatory releases, report generation, and small projects under 80 hours.

Next we have the project request, which comes with the complete project management methodology.

This is just a proposal, and little glimpse into something that I'm sure happens elsewhere. How do others handle it?

The 75% rule changes criteria

The rule changed, the percentage of patients to whom hospitals must provide rehab services to be classified as IRF is now 50 %. The CMS will analyze claims and assessment data to determine a more appropriate threshold in the meantime. It was previously alloted at 75%.

The qualifying medical conditions have been slightly expanded from 10 to 13. This is mainly due to a more detailed classification of polyarthritis. There are more changes and it is probably best to look at the May 7th Federal Register.

CFXML_Blog customized

Steven Erat has some customization to CFXML_Blog found here.

Technote Updates

Several good technotes out of Macromedia today.

Maximum JVM heap size greater than 1.8GB will prevent ColdFusion MX from starting so ensure the flag -Xmx variable to set a maximum heap size less than 1.8GB ie -Xm2048

Determining which class files are loaded by ColdFusion MX is done by adding the flag -verbose:class to the jvm arguments. The class file listing is saved to cf_root\runtime\logs\default-out.log.

And finally returning large character data record sets causes server instability and Out of Memory errors. The fix is to only return a portion of the query variables, not the whole thing.

Conceptual Phase

The conceptual phase of the project lifecycle defines a the project, so management can decide to pursue or not. The purpose is to yield the tools, so someone can make an informed decision and envision the project's intent, scope, benefits and costs. There are several tools that can be used to paint the picture for executive management.

One of the first items that needs to be completed is to determine what is required, needed, and or desired. This is done with simplified use case modeling. Discover the actors, their functions, and goals. Detail these use cases in simple paragraphs to capture the essense of the case. (More elaborate use cases are completed as a part of the building phase of the project)

As you are discovering the intented usage of the system, it is a good idea to start a risk list, and how you intend to manage each risk. Its best to identify and start working on risks in the beginning instead of the end.

Since no one really referrs to the same term in the same manner, another item to have is a glossary. This will help to define terms. I'm not familiar with other industries, but in healthcare there are several ways to refer to the same thing. For example the unique number for a patients visit can be either serial number, patient case number, encounter number, account number, and so on.

After establishing the use cases at a high level, it is time to create the vision document. This document has many components to capture the intent of the new system. One part details the problem that is at hand in terms of the root cause. Normally for technology business cases, the problem is a business processing problem for which a technology solution can help or eliminate. Another part of the document details the stake holders. This defines who will be affected by the proposed project and how they will be affected. The document also includes a portion which covers the functional requirements of the system.

If you think the vision statement just isn't clear enough, sometimes a prototype can help to illustrate the solution. This isn't a defined deliverable, but if you believe it will help to illustrate the point. It may be worth the time to invest.

Another deliverable is the implementation plan or software development plan. At this point, it is high level, but it does capture the needed resources, and time for tasks within the project. Its a work breakdown structure with people assigned to the tasks.

After there is a clear understanding of the vision of the system is going to be, the next document that emerges is the executive summary. This document provides a high level overview of the key findings and recommendations. It is also summarizes the current situation and the future if enhancements go as planned.

Finally the business case takes all of these components, and analyzes them in conjuncture with the total cost of ownership, including both one-time and recurring operational costs. The business case includes the executive summary overview, the risk list, functional requirements, the resource costs, and the vision of the new system. It is probably ideal to have this in a format that can be used for multiple projects so they can be compared to one another.

The business case should be the comprehensive document that allows executive management to decide the feasibility of the project.

B2B Electronic Procurement Apps could save $$$

HFMA estimates that hospital spend 35% to 40% of their operating budget on medical supplies. One also needs to remember that this percentage includes the labor and logistics costs, since a majority of health care organizations have no supply chain management application, and ordering is a labor intensive endeavor that normally lacks standard repeatible procedures. A supply chain management application or even an e-procurement application could have significant cost savings, in one example, with its purchase of materials management and financial applications software, Allina Hospitals & Clinics increased contract purchases from 50 to 75 percent and saved between $4 to $4.5 million in supply costs.

Commerce eXtensible Markup Language

cXML is a standard for passing data between B2B e-commerce applications. A user guide for the standard can be found here.

Project Lifecycle

There are a lot of proclaimed fixes to the high failure rate of project in technology. The rate of failure for a software project is exceptionately high, sometimes quoted at 35%. Before looking at a solution to project failures, I think one really needs to understand the intricacies of the project life cycle.

Projects are comprised of four phases: the conceptual phase, the development phase, the implementation phase, and the termination phase.

The conceptual phase defines the scope, timing, and cost of a project. The business case, requirements, and resource need are completed within this phase.

The building phase comprises the designing, construction, and testing phases of the software, entails defining how the system will be used and training the users on the system, and constructs the live planning. The majority of the implementation costs are consumed here.

The implementation phase is the rolling out of the system into production. Items to be considered are the live event, ensuring there are enough resources, and how to address daily live issue management.

The termination phase of the project lifecycle is concerned with the turning of the system over to the supporting organization. Another essential item in this phase is a review of the project to learn from successes, and mistakes.

Triple Constraints

The triple constraints in project management refer to the scope, time, and cost constraint of any project.

The scope constraint details the project requirements against the existing need of the project versus the expectations.

The time constraint addresses the timing and length of the project.

The cost constraint defines the total cost of the project both operating and implementation costs.

CPOE and monitors for medication errors

One of the initiatives of the leapfrog group is that orders are at least 75% via the computer. Several healthcare institutions are looking at implementing computerized physician order entry systems to increase patient safety.

One of the monitors utilized to track the success of an implementation is medication errors. It is a good monitor, because it utilizes a computerized systems front end editing power. Instead of having to look at the written order, physicians must type the order into the system. Here dosing size errors or other mediation alerts can be caught.

One of the industry leaders in cpoe is Maine Medical Center. This article details the success rate of the program using medication errors as a monitor. An important side note, was the convenience of utilizing the CPOE system was a big factor in the success.

Software Maintenance

When one is building software, one really needs to consider future enhancements and maintenance. The truth of the matt