There are many ways to solve problems in the management of information. Every solution has an infinite blend of possibilities. I want to help you untangled some of the issues that will eventually rise from the morass that we call ECM, CMS, DMS, EDRM, Portal, Social Web or the next acronym.
The first step to
automating the processing of paper is throwing it in a scanner and indexing it.
Most companies that deal with paper invoices either have this technology or
want it. Scanning and manually indexing the image file produces a document and
metadata that is usually stored in some type of content management system. As
more departments hear about the scanning in AP, they will want to acquire
scanners and start processing that way.
The folks involved
with preparing paper and scanning grow comfortable with this paradigm. Depending
on the industry and type of document, the scanner and IT sides are more than
likely looking for ways to expand the scanning aspect of the solution vs.
requiring that vendors and form designers think about the many identification, character
recognition, and indexing issues to stream efficiency.
Instead of forcing
outside vendors and print shops to deal with issues of accuracy and formatting,
many scanners and managers are happy to keep certain personnel busy, thus
justifying their jobs and their departments.
What suffers with this
status quo mentality is the ECM solution. The ECM software can be very good,
however, it is only as good as the information coming in. This is the initial
configuration of documents and minimal descriptions associated with them. The
real power of ECM is force to lie dormant as learning and budgets grow to
realize better, more accurate solutions.
So, how to light a
fire under the very department that was created to solve the paper issues? As
you get comfortable with scanning, the issues of accuracy and automatically capturing
more information start to reveal themselves. More on this in the next blog…
There are infinite approaches to trying to eliminate paper. I have been involved with many of them and look forward to trying whatever technologies come in the future. Right now and probably forever, it's an integration game between old and new technologies. The following are some of the pathways to ECM. In future blog entries, I will tackle these in detail:
It seems like IT departments go round in circles revisiting
the same issues of projects over and over again. As you go around again and
recognize the same issues, will you have enough energy to tighten the circle so
that next time and issues are less? The spinning of project issue repetition is
a symptom of lack of a comprehensive understanding of information and
technology interaction. This spinning does not happen overnight, it builds up
slowly as more projects are retrofitted into system as a whole.
More integration headaches equal less vision of information
architecture. Why is this? Because someone said we need to consolidate system X
with system Y without thinking through the issues of having corrupt
information. Information’s worth is how well it is connected, but what happens
when connections change leaving orphaned content and obsolete metadata? Nothing
happens until someone says, “Let’s safe money by consolidating” or integrating
or adding functionality, etc.
How does IT stop the spinning of issues?
At the core of any spiral, you don’t spin, but you see
everything that is. With this perspective you can understand the forces at
work, for example, a department that is feeding the spin by adding content that
is not described accurately and extensively enough-rotation is increased. At
the core, you can see this by analyzing reports which show trends. Also,
anytime you think through how to export a cross section of your content and
information you will expose the issues which cause your dizziness. The export
exercise can be a low cost way to analyze how well the information architecture
is designed. For example, does the information make sense on its own, are
standard descriptive terms used to describe the content, are there accurate
dates of execution of the information, could it be accurately imported into another
system?
You have an approach to an issue with the design or flaw in
a system. You brought up the idea with your project manager who dismissed it
immediately without considering the whole possible solution. You know your idea
has merit. You know your idea could work, but how do you convince your peers
and managers, how do you persuade them?
Persuasion is a skill that, when coupled with perseverance,
will help implement your idea. Of course, your idea has to be good and well
thought out. Many people have better persuasion skills than ideas and that’s
part of the problem with IT these days: many project managers have other
agendas that diminish the technical integrity of the solution. Solution flaws
come back to haunt you if you let them slide because of the pressures of
timelines in the present. Have some guts and make your case now or suffer the
consequences!
Plant the seed, add water
Bring up your idea and be aware of the reaction. If the
reaction is dismissive, don’t try to convince at that point. Let the idea work
its way into the doubting minds. In the meantime, build your argument. Let’s
say a few other ideas are brought up and tried, but ultimately fail. Your idea
may be brought up by the person who dismissed it a few days ago. If this
happens, try not to feel discouraged as ideas are cumulative and no one person
deserves full credit.
Try/Buy
If the idea you have involves software, see if it is
available on a trial basis. If so, install the software and configure it. Build
a proof of concept. The best way to convince your management that your idea is
a good one is to show it in action.
Gather consensus
Your ability to persuade individual members of the team
could be crucial to getting your point across. The more team members that are
convinced, the better chance of actually getting your innovative idea
recognized.
Let other ideas fizzle out, be patient
If you are patient the inferior ideas will eventually be
proven faulty. Reintroduce your idea and witness how it is accepted. There are
many reasons that folks reject ideas at first. It would take all your energy to
figure them out. Your job is to know that your idea is the best and to
persevere.
After Lawrence Hart recommended "The Myths of Innovation" by Scott Berkun, I was curious to find out what Mr. Berkun's ideas were on innovation. The book starts out with the concept of the years of hard work it takes for our innovative breakthroughs to occur; that the moment of genius is a surprise after many long hours and infinite combinations of possibilities.
As we consider "Big Data" and its promises of indexing and searching "innovation", I wonder how of this is marketing and how much is making a "significant positive change"? Big Data in healthcare has a long way to go before it can truly state that it works. What the Big Data push is doing is forcing the architects of the first generation of EMR designs to rethink how their data is designed, OCR for scanned results and forms, metadata of content, designs of the forms online and on paper, merging of transfer patient encounters, and the use of acronyms, keywords in forms. This is just a short list of hurdles that will need to be dealt with before Big Data can be fully useful.
Bad Data in EMRs
Indexing inconsistent and spotty information makes it easier to search, but the results would still need a lot of clean up. In other words, EMRs will need to be fully combed through and corrected to produce accurately results. One issue with EMRs is that the underlying organizational structures are hard to change because of the audits and regulations that control these changes. Also, when hospitals merge, older record numbers get merged in with newer one; at the master database level the numbers are unique, however at the patient record level all sorts of interesting things can happen where duplicates number occur and short term fixes are put in place...
Some EMRs allow for free text to be entered as metadata which describes the electronic or scanned in form; great, but have you ever tried to pull any type of consistent meaning out of these free text fields? What were they thinking??
Optical Character Recognition (yep, ICR and OMR too)
For hospitals that are not fully electronic, most of them, the issue of scanning and OCR'ing their forms and results is an ongoing struggle in that the forms and inconsistently filled out, doctors and nurse hand write their notes, and the design of the forms paper oriented. The technology behind ICR for hand writing is not good enough for recognition unless the hand written letters have boxes around them.
So, as Big Data permeates healthcare systems, at what point will it really help to bring about "significant positive change"? There are many years of hard work to get this point. If you drink the koolaid, index agents can intelligently sift through all of the noise and help find and report on the information that is required for upper management dashboards, however, I believe there will be many cycles of "reforecasting" Big Data effectiveness before it is ready for primetime.
It's one of those golden rules of IT
projects to collect the business requirements with an open
perspective, unshackled by technical or operational concerns. But,
what happens when this rule is broken? What are are some of the
symptoms of putting the how ahead of the what? Here are a few
categories (out of many):
Over funded with small scope
Capital projects are structured in such
as way as to be viable for certain period of time. These projects can
have moneys which are over allocated. This creates a “bucket” to
use on other, related projects, which can benefit from the “shared”
software application or servers. There's a time limit, so the
deadline of spending approaches, management will get creative and
spend money on more innovative projects.
Project over scoped with not enough
resources
This where the time-line of initiatives
and ROI objectives get delayed and pushed back to the point where the
original project sponsors loose faith in IT's ability to deliver.
Sometimes years will go by with nothing happening, meanwhile the
business is forced to find alternatives. Shadow or cloud projects are
developed on the side, within the view of IT, but without
consequences. That is until a system goes down and someone begs IT
for help. Then IT takes it over and begins the journey back to
standardization and optimization, and lest we forget, shared
services.
Assumptions are not coordinated with
other systems: other systems solve their own issues
The larger the IT project, the more
integrated it is going to be. Without a concerted effort at
understanding the full breadth of requirements and assumptions at the
beginning of the project, the project will falter each time an
integration step is needed. Why? Because the time and effort was not
taken to include the key players of integration during the planning
and funding phases of the project. The assumptions were glossed over
by the deadlines to get a budget in place.
Updated script: VBScript and API to export all image pages Link to other Onbase scripts. I spent too much time looking for a script example for
exporting from OnBase the other day, so I wrote one that works within OnBase.
It can be run as a script hook. The key to figuring this out was to find the
table with the “file path” values in it. After rummaging around for a while I
found the “itemdatapage” table which has part of the path in it. The other part
(the diskgroup) has to be included in the path, plus the share drive value.
The following are the parameters that need to be set in
order for the script to run correctly.
sSQL = "SELECT b.diskgroupname, a.filepath FROM HSI.itemdatapage a,
hsi.diskgroup b WHERE itemnum ="& oDoc.Handle &"AND a.diskgroupnum = b.diskgroupnum"
