Monday, February 22, 2016

The Power of Visualizing Checklists

“…the volume and complexity of what we know has exceeded our individual ability to deliver its benefits correctly, safely, or reliably.”  Atul Gawande, The Checklist Manifesto: How to Get Things Right

We all make lists of activities for today and in the future. As we write them down and/or type them up, we form categories if the list is long. We rearrange and rename the categories. When everything looks good, we can relax, right? Not really; I’ll explain why.

After a month of working on a checklist for a large parallel upgrade project, I decided use Microsoft Visio to represent the checklist’s categories visually as a diagram. Each box in the diagram would correspond to set of tasks. As I was thinking about these boxes, a certain order became clear; an order of what was being done and which team was responsible.

The major sections of an upgrade are Preparation, Pre-Upgrade, Upgrade, Post-Upgrade, and Support. These sections are natural top level boxes. Underneath each of these top level boxes are their corresponding task categories.

As I created and placed the boxes under the sections, I renamed some of the categories and consolidated others. The visual representation allowed me to “see” that some were the same, and some tasks were missing. I could reorder the task categories. I could also see that we needed more support tasks after the upgrade.

I know I could have used MS Project to do this, but it’s not as flexible. Project also presupposes activities that may not add any value to this type of visualization. If you look at the end visual result above, hopefully you’ll see what I mean; by breaking out categories as boxes, it’s easier to see gaps and similarities than if you just had a long list.

Thursday, February 11, 2016

ECM Organization Structure Evolution

A few years ago, Greg Clark posted on AIIM’s Community blog called, “Creating an ECM Organization Structure…” He divided ECM structures into small, medium, and large organizations. At the end of the two part blog, he talks about the need to have a “Change Management” role in the mix for all company sizes. Although he provided structures were are static in terms of growth, most cases small companies grow and evolve.

Understanding how ECM structures go from small to medium and medium to large, as well as the deformed nature of most ECM structures is the goal here. Let’s work through change management at the management level, not just the application level of a typical healthcare IT organization.

“You may ask yourself, well, how did I get here?” – Talking Heads

In general, healthcare ECM is either in the EMR or the Finance IT camp. As Mr. Clark outlines, a large ECM should stand on its own, outside of IT along with EMR. This depends on which IT group and business area developed the ECM solution first. Both finance and health information management (HIM) departments are inundated with paper.


In the past, paper coming in from 3rd party invoices and employee expenses was enormous. The ROI on implementing a scan/store solution was an easy sell for Accounts Payable. This is why many ECM solutions were first introduced into the finance IT area.


Health information went from purely paper to EMR relatively quickly. This meant that some areas were left alone because of the need to implement “80%” of the solution. Part of every EMR solution is dealing with scanning and storing paper forms, especially ones that need to be signed, or ones that are brought in from other healthcare providers. ECM can easily be introduced with in the EMR solution. If your hospital has EPIC as its EMR, chances are good that Hyland OnBase is there as well.

Who wins Finance or HIM?

Many issues from project priorities to information governance are usually after thoughts when it comes to thinking about change management of ECM organization. Moving the ECM group from either Finance or HIM into its own program can be a  battle. How do you split up the project intake process when there’s no governance or program management specifically for ECM?

What happened to ECM governance?

When ECM was initially rolled out there was most likely some type of group or consultant that wrote out the goals, strategy and deployment plans. The documents and diagrams have dust on them. The regular meetings went from weekly to yearly. The intake process is on fire. And so on… Chris Riley in his article, “Taking charge: Structuring and managing an ECM governance committee”, explains the need for sustaining a governance committee:
“A strong ECM governance committee reduces the burden on IT and establishes a more robust and broadly supported governance framework than IT could build on its own. Not only that, committee members who are properly involved in creating governance processes will stand by a system and be the first defense against ECM naysayers.

How the Program Management going?

With ECM governance intact, Program Management can exist beyond the project management software and “project managers” pushing milestones. At the program level, according to Mr. Clark, we are talking about the following responsibilities:
·         Drive the creation and execution of the ECM strategy
·         Liaison to the steering committee
·         Manage vendor relationships
·         Hire and manage the ECM team
·         Contribute to or lead the development of an appropriate information architecture
·         Identify, track and act  upon key metrics for the ECM program

Ok, so here’s where the split between Finance and HIM could have the potential to merge. It would take a program level management structure to efficiently handle ECM projects. Otherwise, the project priorities are dependent on the old school influences which only worked in smaller organization.

Here’s what Mr. Clark says:
“The most important aspect of this particular structure is that the ECM group is not part of the IT department, Legal group or even an administrative or business services group. This organization has chosen to align ECM with overall business operations in a group called Technical Operations and Competence. This division is responsible for helping the organization achieve operational excellence across their core business, and includes such functions as Engineering Standards, Maintenance and Reliability, Environment, Health and Safety (EHS), Training and Development, and, finally, the ECM function.

Pulling a mature ECM program out of IT may seem impossible, however the reasons for doing so should outweigh the reasons for status quo. A liberated ECM program strategy is free to pursue the higher level goals of the organization with being held back by IT. 

Thursday, February 4, 2016

99% Accuracy is Good, Really?

Ok, I know, it’s obvious that, when there is one mistake in a hundred, quality is pretty good. But 1% failures add up when there are 10,000 records: that’s 100 failures. Even small or medium systems can process a million transactions a day. I guess it’s a matter of how important the accuracy of the data matters to the business. You’d be surprised though how many failures are dealt with manually without fixing the root causes of the failures. Let’s consider what types of failures this 1% might impact:

Pharma: good clinical trial practice

Clinical trial documentation keeps track of test results by patient demographics. If there are any data quality issues, the effects ripple throughout the trial results. The safety and efficacy of the trials can easily be influenced by any data quality issues, let alone 1%. Audits for CFR part11 compliance will be disastrous otherwise.

Healthcare: patient safety

If registration systems are not 100% accurate, you could have a patient safety issue. For example, an allergic reaction to a specific medication is not information that should be 99% accurate. I have experienced this first hand and I can tell you it is not fun. Try requesting information on your visit to a hospital and see if it is all there. Even .001% failure is not acceptable.

Finance: entities of entities

At a hedge fund, following the account numbers between entities and fund of funds, accuracy has to be 100%. Documentation metadata has to be validated against source data at every possible opportunity. SOX fines would add up otherwise.
If anyone at your company considers 99% information accuracy a viable goal, ask them if they would care if they got 1% less pay in the paycheck.