Anticlue

Keeping on top of things

With technology changing at a rapid pace, sometimes its hard to remain on top of new ideas and technologies.

Lately, I haven't had any coding time at work, so I probably spend about an hour a day at home, surfing and reading on new technology. I have found that I enjoy reading the various ways to accomplish something. (I've also figured out I need to build another room for a library) I also have discovered, that I like to lay the foundation first, before delving into high end concepts. Guess I'm a crawl before you run type.

I do think technologists have to a responsibility to keep up with the latest concepts. However, people have various learning styles. Adults learn best by doing normally, which is what training classes provide. So I wonder, how do others keep abreast of new technologies? Please share.

Why do a Charter?

Why do i have to do a charter, the customer knows what they want. I just wanna program it! Sounds like a childish whine. Here is why.

A charter acts like a requirements document. It clearly defines the scope of work. It also defines the intent and usage of the product. The user community of the product. The charter also goes beyond the what, it covers, the who, where, why, and how. It identifies the risks of the project, the people involved in the project and their expertise, and the communication mechanism for the project. It also establish guidelines of how people will act who are involved in the charter. The charter also makes ideally clear to executive management the impact of a project. All of these are good things.

If there is a major development request (more than 3 weeks of work), it is best to charter. Then in the first week, establish a comprehensive requirements document with the user understanding, this is what they have requested, and what will be done. (This needs to be the same)

ENH's CMS

Evanston Northwestern Healthcare redesigned its Web site to be patient centered. In otherwords the redesign is so that it makes sense and flows well for the patients.

This article details how a Content Management System helped the endeavor. The authorizing structure used is that the department chairs authorize content for the web site. Another nice feature is that it integrates with the electronic medical record system being implemented.

Going through the cycles

Ben Forta recently surveyed developers on his site for where they do development. The results were a bit disconcerting.

14% do development on a production server.
52% use a dedicated development server.
32% use the free Developer Edition.

As web technologies become more prevelant in an organization's business operations, imho there needs to be 4 dedicated systems.

First, a production system with the goal of 99.9% uptime. The cost of bring down a production server, is that the business can't work. So to totally eliminate all risk, no development or testing should be done on a production box when it is in production.

Second, a disaster recovery system should be available. This should be an exact replica of production, in another physical location (preferrably out of the building). There needs to be measures in place to ensure synchronization between the production and disaster recovery.

Third, a quality assurance or testing system should be available. This should be another copy of production but with controlled and released changes. In the ideal world, this test system would undergo daily automated test cases. There would be stress testing, interoperability testing, and integrated testing. The outcomes of this testing would ensure that what ever changes scheduled to be released would not affect the business with undesired results.

Finally, a development system with source control. A source control tool, allows for changes to be tracked, eliminates the possiblity of developers overwriting code changes. A development system on a server also allows for nightly backups in case a local pc crashes.

The movement through the stages, from development to test to production and disaster recovery, ideally would be done by a change control of configuration management process. The goal is to minimize impact to the business operations.

Is this an expensive solution, for you I don't know. What is the total cost of operations when your server is down? What is the cost of losing certain data elements? I guess it comes down to how much risk your organization can withstand.

Governmental Blunders

That's about all I can say on this topic.

The Equal Employment Opportunity Commission approved a rule that would let employers reduce or eliminate company health benefits to retirees eligible for Medicare.

What a wonderful place to be, retirement, never getting another raise ever. The dollar losing value to inflation. Medical bills galore. And now possibly losing any promised benefits from corporations striving to safe some money.

Strategically utilize the web

Businesses need to be able to create a strategic vision for how to expand or improve their basic operation, marketing, and customer service functions. In all three cases, Web-based technologies can help to fundamentally change the way an organization does business. This strategic method is generally referred to as Feeny's E-Opportunities.

There are three main categories of opportunities; e-operations, e-marketing, and e-services.

E-Operations focuses on the business daily operations and supply chain management functions. For health care organizations, daily operations can be enhanced tremendously by the use of web technology. Imagine an automated supply request process, with no pieces of paper to fill out along the way. Or perhaps vacation requests and scheduling being completed via an intranet web page. Another ideal is computerized physician order entry.

E-marketing covers initiatives that expand the delivery mechanism of the main product of the business. Viewed through a health care perspective, disease management and wellness programs provide consumers with a starting place for asking questions.

E-service challenges companies to find new ways to address an identified set of customer needs. Perhaps it is a web-based training application to expand CME or CNE credits. Maybe it is a tool to expand and support conversations between clinicians, referring, consulting, attending, and residents, on a patients care. E-Services expand the traditional service model to a non brick and mortar model.

What Design Pattern to use when

Recently on the Machii mailing list, Sean Corfield shared this link. A very clear and useful guide to understanding design patterns.

Inheriting a Department

Things in life change, people move on, organizational structures change. All of a sudden one day, you are blessed with a new opportunity of supporting the systems for another department.

One of the first steps is to find the data and where the data goes. How to do this? Get a listing of all of the applications of the department, the version, the last major update, the current customer contact. Find out the platform and data base engine of the application. Also determine all of the interfaces, are they manual, batch, or realtime? Is there a standardized data format? Is there a yearly cycle of business that they need to coordinate with? What steps need to be done to interface data from one system to the next?

Finally, layout a high level diagram of all of the systems and the data flow. This picture is invaluable in trying to see the landscape.

Work with your vendors for testing

Vendor relationships make or break healthcare institutions. Its been my experience that Healthcare IT organizations generally don't have enough resources to go all out in testing. It would be great to test every single application for all weak points and to be able to address them. But the simple fact is that a single healthcare institution doesn't have the resources available to test every appliction for every breaking point. (Unless of course, they purchase an it goverance suite with testing software) So what can one do?

Well, I propose a better working relationship with your vendor of choice. If you have a good working relationship, try to find out the types of testing and test cases that the vendor placed the application through before forwarding it onto you. The Ideal is to get those test results, and then add them in with your testing scenarios for interoperability testing. If you don't get some of the same result, figure out why there is a difference in the configuration. One doesn't need to recreate the entire wheel, if your vendor has a proven track record, then have some faith. If your vendor doesn't have a proven track record, consider getting one who does. Poor vendors are an expense that any healthcare organization cannot afford.

Also have your vendor partake in your change management process, perhaps even fill out a change form. Be sure to include in the change form, test cases and outcomes, (ideally both yours and the vendors), the dependencies, the order to move a change live, what the risk points are, and at least two strategies for recovery at each risk point.

Group by IT practice

In large development group organizations, there are various ways to support different functions. In Application support, sometimes groups are split up by departmental functionality. For example, the IT division is split into various departments that manage certain business processes. This group deals with all technology requests regarding patient registration. Departmental functionality does do a great job of giving a department one single point of contact for relaying the status of projects, issues, and other requests. On the other hand from a technology viewpoint it really does a disservice, because the practice creates silos. Each IT department has one or two individual that are either programmers; an implementer; screen designers/builders; interface specialists; and/or dbas. The outcome is that each it department has disparate practices and skillsets.

It may be better to divide application support into the skillsets needed, and have a centralized project management office. For example, have a group of individuals who are experts at mapping out workflow and obtaining business requirements. Create another group of people who are the implementers of the organizations, the project managers, then organize the developers under a central group, as with the interface experts, and with the reporting experts. Split testing and change control functions into specialized individual groups. This practice would eliminate people working in silos and provide better cross training with similar skillsets. The single point of contact could arise out of the project managemetn office or the business analysts group. Also this split would highly increase the repeatable processes, and lessons learned would arise with a greater understanding. This type of organizational design would also leverage any organizations contraints of time, cost, and quality.

Mapping Objects to a Relational Database

Here is a nice overview of mapping object to a relational db.

Buying vs Building

The other day, I ran into a colleague of mine. Somehow in our conversation, we came across the concept of buying versus building. After a little bit of thought, I think the question is larger than buying versus building.

Basically here is the scenario, someone sees or thinks of some technology tool that would make their job easier. Then the question becomes whether you buy a product that does the job or you build a product that does the job.

The decision depends on alot of factors. First, although you may try, you can't possibly buy everything that works for your business solutions. There will always be outliers, things that you can't find a reasonable solution for, or items that just need to be built. My best guess is that one can probably reasonably purchase 85 - 90 % of the needed information technology tools for a healthcare enterprise. There are build needs, just have a clear process in-house to identify when something needs to be built.

Next comes to the monetary investment, the institution wants to make. When asking this question, my favorite answer is "We don't have the money in this type of product, so could we just build one." List the maintenance, first time naviety, testing scenarios needed, time to build, and opportunity cost of building this item versus others, as reasons why lack of money is a very poor reason to build a product. (Unless your organization plans to sell that product to make $$$)

Another aspect is the level of risk that is acceptable to the organization. If you are working in an organization on the bleeding edge of technology, that has a high risk propensity maybe building is for you. Maybe building a fantastic custom product out weighs the fact that when it breaks you have no one to call. On the other hand, if you are working in an organization that is on the edge of technology, and is known to be very risk adverse. Maybe buying something that others have installed elsewhere is the road for you.

Drilling down and examining the benefit of having someone to call about a purchased application is sometimes critical. The purchased application will continue to be enhanced by suggestions from multiple organizations using the app. There will be support maintenance fees, but these maybe a low cost when considering the value of having support available instead of your business being down and unable to function.

Another aspect is you don't need to worry about turnover of internal staff. If you build a custom system, and that builder leaves the organization. You don't need to worry about training other programmers in maintaining the custom application. Even if the company goes bankrupt, it is more than likely another software company will purchase the product and continue to support it. An organization does have to worry about the sunsetting of applications, but that would be the same case with a built tool.

There are many other aspects not covered here on this question, but I'd like to leave with this note. Given the limited resources, time, and other constraints don't build an inhouse solution just because there isn't money to buy something. That custom solution will probably be far more costly in the long run, than investing in a tool.

Estimating Tasks

I love this scenario, someone presents you with a piece of paper or an email. It details some vague task or concept. Like for instance create an interface from the student information system to the finance system. No specs, no fields desired, no format, no transport mechanism and then they ask can you do it by the end of May?

Nevermind the six or seven balls you are juggling :) Estimating the time for tasks is something that is sorely missed. First there needs to be clearly defined requirements for the task at hand. Yes, there will probably be scope changes to some of the requirements, but hopefully not the essence of the requirements. Then a couple of estimates would be good, have two or three people, derive the optimistic, realistic, and pessimistic estimates. Average the estimates, with a higher weight on realistic and pessimistic.

The best practice is to get a central repository of task that have previously been completed with the slip time of the task, the time the task took to completion, the skillset performing the task, and the obstacles encountered. This will assist in generating the realistic estimate.

For the optimistic scenario, base it on a highly skilled individual, for the pessimistic base it on a newbie. One doesn't always get the most skilled individual for a project, and the newbie will probably encounter more obstacles. (Its all a part of learning)

Yes, this process would take more time than the standard 2 days, 2 weeks, 2 months guestimation mechanisms. But accurate reliable estimates of the time to complete work will only create a better project plan, and any tools that would help with this process are worth their weight. A detailed scope of work, makes it very clear upfront whether this project is worth the time, instead of wasting time and then not delivering.

ROI and CMS

There is an interesting article on the content management session at Himss 2004 found here.

The article reviews the benefits of a CMS based upon ROI. Its a very good read for the overall benefits of a CMS.

Don't have secrets

Project Management is an interesting task. One of the main tenets of project management is not to keep secrets. What do I mean? Basically if an issue arises or if there is even an indication of an issue address it. Get the key needed players in the room, analysis the risk, and have plans to overcome the obstacle. If it is an obstacle that can not be hurdled, clearly define the impact. The key is that you don't need to know the answer, you need to know various ways to address the issue at hand with the least impact and risk to the business.

As a friend of mine says, honesty is the best policy.

Traits of poor performers

Viewed a glimpse of the Effective Public Manager today, by Steven Cohen and William Eimicke.

One excert that gave me pause was "Knowing When to Give Up on a Staff Member." It's a listing of characteristics for employees that would probably be better suited in another situation.

< --- Snipped from the book --->
1. Wastes time in meetings with trival or impossible issues.
2. Possesses poor listening skills - never seems to understand the last point made.
3. Refuses to work overtime.
4. Never arrives anywhere on time.
5. Is disliked by the rest of the organization.
6. Is pitied by the rest of the organization.
7. Spends much of the work day on personal business.
8. Agrees with everything you say.
9. Disagrees with everything you say.
10. Is at his or her best when analyszing why an assignment is infeasible, unnecessary, or otherwise not worth doing.
11. Rarely finishes an assignment on time.
12. Rarely finishes an assignment at all.
13. Is unable to explain or defend a product.
14. Undercuts member of his or her own staff.

The elements on the list are interesting. I think it is essential to realize that sometimes people don't fit in the role they are in, but there are roles that they fit in. The trick is matching people to those roles. The other essential characteristic is that sometimes people may have these characteristics due to other external events. The point is that if this is a habit with no other legitimate reason.

Economic Census

This is pretty interesting. Show's the economic census for 2002.

Take a look at the number of establishments, revenue, annual payroll, and paid employees for the different categories. Its surprising in some cases.

The Office of Budget and Management is reviewing the 75% rule

Looks like the Center for Medicare and Medicaid services finally established the criteria for classification as a rehabilitation facility.

The proposed rule states that inpatient rehabilitation facilities (IRFs) would be required to have at least 65 percent of their patient population diagnosed with at least 1 of 12 designated medical conditions in order to qualify, or continue to qualify, for reimbursement as an IRF. This stiffer regulation even with a lower percentage may be cause for concern, as some IRFs may fail to qualify.

A CMS and organizational constraints

A content management system is basically a global communication mechanism. The CMS allows any authorized user to communicate globally on a web page under a create, review, authorize, and then publish workflow. Its supervised email for permanent communication with employees, customers, business partners, and any other visitor to your intranet, extranet, or internet site. So how does this come into play with organizational constraints?

Any organization has three main constraints - time, cost, and quality. So in viewing a CMS as an enterprise communication tool. Isn't it a better use of time, to have one person write an page, instead of a create send to the web person, update a stage area, send back to the originator, change something repeat process, then publish. Notice no authorization structure, no one reviewed to say this is legally compliant, or this is the market angle we want to take, or this is the type of information we want to get to our employees. A CMS adds the ability to have that process defined, and saves everybody's time.

The next constraint is cost. How does a CMS address cost? Mainly in savings in document management. Having a tool that posts documents, and archives previous versions, and doesn't force the print to paper and distribution process is a monumental savings. Especially when reviewing at a corporate level. Another factor in cost, is the opportunity cost. The opportunity of a missed marketing factor due web resources being bogged down in requests to departments not even considering the factor due to too much time to go through the request for work. But how much time does it take for someone to write a brochure in an email, thinking about the webpage created with the same level of effort. A powerful concept.

The final constraint is quality. The CMS review cycle addresses the concept of quality, as does the authorization structure. Imagine if every web page on your site had to be reviewed within a matter of time, and then stated whether it was still valid, and that was the responsibility of the authorizor or creator of the page. Timeliness and valid relevant information in the communication that's quality. It gives everyone the impression that you are concerned with the face your institution presents, and how you communicate.

Communication is essential to the world today. Everything is based upon communication, a CMS just expands your communication scope from a list of individuals to anyone with access to where you publish. By communicating properly, it saves time, creates a cost savings, and improves the quality of your organizational image address a part of the three main organizational constraints. Of course, it in no way alleviates those constraints, just lessens the impact of some of them.

Online Consultations

An interesting survey by JupiterResearch located here.

Turns out that 92% of consumers are unwilling to pay more that $10.00 for an online consultation with a doctor. More intriguing is that out of the sample population, only 3 percent of Internet users engaged in online consultations even though 65 percent had indicated a desire in 2002.

Enterprise Patterns

Anyone interested in design patterns should read Martin Fowler's Patterns of Enterprise Application Architecture. The book provides a wonderful view of generic concepts from layering to mapping to a relational database to web presentation. It also details several enterprise design patterns. An online catalog of enterise design patterns is located here.

Searching Features

With all of the jargon that surrounds healthcare, the search feature on a web needs to be oriented towards the non-practioners.

Search tools like Verity can help exploit the searching capability by leading the customer to the most suitable place due to their search phrase.

The value in this is immense, it eases navigation by searching for the customer base, and provides a more usable experience. One probably knows this from searching for something oneself. An empty search phrase is a very frustrating thing.

Open Source Software

Open Source sometimes has a unnecessary stigma attached to it. There is a large difference between Open Source software and unsupported software. Sometimes organizations need to leverage open source as a part of their repetoire, when they have enough support, and individuals with time to master it.

For example, linux is an excellent open-source product, and you can purchase support of the os from various vendors. (IE redhat)

It also depends upon the adoption period, if you are a bleeding edge, you will have a higher risk exposure, than if you are at least cutting edge or waiting for the technology to stabilize.

For a thought provoking article on open-source and its advantages, Forrester Research has compiled the open-source strategy.

Vendor Questions

When choosing a vendor, it's a good idea to ask some basic questions. These give one a broad idea of the vendor's reliablity at hand.

# of years in the business?
# of employees? # of employees dedicated to supporting, maintaining, and enhancing reviewed product?
Annual sales?
Market share of current products market?
Percent of revenue dedicated to research and development?
# of active clients using the product?
# of active clients in similar business to what you are in?

List of organizations currently using product

Object Composition

A fundamental principal in using design patterns is Object Composition. Object Composition is the combining of the parts to obtain the whole. The objects are composed based upon how their interfaces relate at run-time for the lifetime of the whole. Composition refers to the "has-a" relationship between objects.

Hl7 Version 2.3 Document Specification

The link to the HL7 Version 2.3 Document Specification can be found here.

Document Management Aspect

Most of the time, when people start refering to content management. We are speaking of the words and pictures on a web page. We utilize alot of soft untangible terms like improved customer support, the content owners owning and updating the content in a more timely fashion, and content resuse. The picture is vague and unclear to those who have to purchase and invest in the idea.

Inorder to arrive at a good business case, you need tangibles - hard dollar return in investment. Inclusive in a content management system are document management applications. Here is an article on how Florida Hospital is on target to save 1.6 million over the next 5 years using a content management and delivery system. That's a good deal of paper savings.

The added intangible benefit, improved patient safety due to the immediate delivery of physician reports via the web. (More timely and immediate)