The Role of MISC in ECM

I used to loathe working on categorization projects because I knew eventually someone would say, “I don’t know, put it in a miscellaneous folder”. This meant that the overall design of the categories was flawed or that we didn’t have enough time and energy to work out every minute detail, only to have it change in a few months anyways.

Flexible categorization makes sense, but the tools are still designed to tag content with fixed values. Big Data solutions might eventually help with this if you have millions of dollars to spend on them. For small to medium sized systems, we are stuck with good old fashioned indexing and search. However, this might prove to be a better long-term solution to content mining. I still believe the better the metadata, the better search results.

The Misc folder suits a number of different purposes:

In general, this folder can be used to analyze new trends in metadata values, that is, some patterns of values will become apparent as more content goes there. Over time, the patterns will become folders/categories and there metadata values will become part of the indexing process. Likewise, categories that are almost empty will be merged with others because their index values are too restrictive.

In taxonomy, a miscellaneous folder is a black box, something that gets all that is outside the scope of the people working on it at the time. Emphasis on “at the time” here because as ways of organizing information changes, so goes the taxonomy.

In workflow, miscellaneous really means a place/bucket where all the routing mistakes are sent, or more likely where any new unanticipated content types go. This works well as it is obvious as the content builds up which queue they should be routed too. The alternative would be to ignore the outliers which would leave them for discovery projects in the future.

Drivers and Followers and ECM

Futurama (New York World's Fair)

In The Option of Urbanism, Chris Leinberger, describes how there are “drivers” and “followers” in the product types of real estate. For example, a driver would be residential home development and a follower would be a mall constructed close to where the new homes are built.

The same is true for enterprise content management. For example, a driver in healthcare applications would be an EMR, and the follower would be all the other applications, except registration and billing. EMRs were late to the game, but are now front and center. ECM systems, like Hyland’s Onbase, fill in the gaps as a follower in the long line of other applications.

Gaps occur over time as applications are moved in and out of favor, CIO’s change things up to reduce costs, requirements change, and priorities are mandated. Gaps are filled with invoice scanning solutions for paper processing. When regulations change, ECM has the flexibility to meet the requirements until the larger “driver” systems and adjust.

Hospital merger and acquisitions are “drivers” which spur multiple content and information migrations. The “followers” help clean up the information messes caused by disparate systems. Content types and metadata have to be mapped and reclassified. Who does this? ECM applications and professionals are well versed in these types of situations.

Understanding ECM’s flexibility and its major role as an IT “follower” is essential when making strategic decisions on where to deploy it. It innovates when “drivers” need it to. It fills in the gaps quickly to provide the needed bridge for unforeseen obstacles of business change. It’s easy to get excited about innovation “drivers” and much harder to involve the “follower” applications in this excitement. 

I'm Not Just An ECM Flounder!

Hi, I’m not just an ECM flounder at the bottom of your information ocean. I’m affected by any changes in how or what information is dumped into the sea. Let’s look at some of the ways that my environment gets polluted.

According to CIO’s Howard Baldwin, here are some IT complexity issues that should be looked at in order to decrease pollution levels. Baldwin calls it “complexity”, I call it pollution. As a bottom feeder, I need a lot of coordination and cooperation from above so I can live and prosper. I’m only as fit as the polluters will allow me to be. If I’m not in shape, I can’t innovate. Sorry about that last rhyme, unintended…

Documented Knowledge

How many application integrations are undocumented? Or, documented years ago and not revised? Every undocumented process turns into an oil leak into the ocean, and I have to deal with it during upgrades and new development. I know I have to make sure everyone is aware of changes I make to the ECM system, but same goes for all you applications at the surface.

Consolidate to a Cloud

As an ocean dweller, I would have no problem if all information was filtered in the cloud. This would necessitate more accurate requirements, functional specs, and testing documentation. The rain would be less polluted. The oxygen levels would be excellent. The bottom would be less murky. The ongoing maintenance of the infrastructure and integration points would drop considerably.

Complexity ebbs and flows

Like ocean tides, information inputs and outputs ebb and flow. Complexity can accumulate quickly with director churn, as they need to prove themselves and usually build new applications beside existing ones. Talk to anyone dealing with SharePoint beside an existing ECM solution and you’ll get an ear full.

Hyland Onbase’s Patient Window = Silo Buster?

As a physician, when it comes time to view images within their hospital’s EMR, the experience can be frustrating. Hyland OnBase has a solution for aggregating these disparate imaging viewers (DICOM and non-DICOM content) into one application: Patient Window.

This solution is described with words like “Unify”, “Connecting information silos”, “seamless integration with EMR”. As a certified engineer working with OnBase working on Healthcare solutions, I applaud this effort to truly help physicians find their information efficiently. The demo looks great, but what about the implementation?

So, how can this silo buster get traction within the fortified walls of an EMR’s embedded imaging viewer? Behind these applications are dedicated teams who have spent years implementing these point solutions within the EMR. Chances are good that these teams are managed within the EMR’s umbrella. This means the ECM's team manager will have to have discussions with the EMR's team manager to negotiate how to "unify" these applications.

Showing the image for the patient’s case is the culmination of purchasing the machine, licensing and configuring the software, testing it, configuring the manufacturer’s viewer to be embedded in the EMR’s software. The team that did all of this work, had many meetings with the informatics team to review the physician’s requirements and industry standards, with the EMR team to review how it should be setup with the EMR’s solutions, with IT’s infrastructure and security team to validate the integrity of the solution, with the interface team to make sure that patient information integrated correctly, and so on.

The silo is not just the information, it’s the whole process. Process reengineering is a key part of implementing this type of aggregation. I’m not saying it can’t be done. What I’m saying is that, unless there is already an EMR process overhaul taking place, there is a mountain to climb here.

Zombie ECM

ECM: not alive and not dead, walking towards sounds and smells. On autopilot to get to the next big event. What do you have with information management that does not have adequate quality? You have zombie ECM systems marching toward something.

We like to think this something is for the greater good. A place where healthcare can find their data and get paid, where financial institutions can store their signatures, where pharma can follow the regulations. Without more information quality checks and balances, this greater good looks more like zombie land where we only do what the standards and regulations say, nothing more. We trudge along and wait for the next upgrade, for the next event, the next big thing.

Does everyone feel that they are doing the best quality work on implementing their systems? What would be a better way of designing ECM? How can you improve on how your process works, how solutions get implemented? Why doesn't Gartner have an info quality quadrant their ECM leaders?

“One Patient, One Record”

This healthcare IT tagline has been around for a while. Software vendors and healthcare provider IT groups, touting this slogan, are definitely aware that it over simplifies a patient’s information trail. There are many unknowns that could splinter that “one record” goal. For example, what if a patient goes to a different hospital? What if the patient’s insurance changes, what if any number of issues could happen to the many systems used to keep track of a patient’s registration, appointments, orders, results, ED visits, discharges, etc.

Patient is a person not a chip

Patients being human can inadvertently cause havoc on their own information. It could be as easy as changing your baby’s name or moving to a different healthcare provider. The information that follows the patient me get split into two separate buckets, orphaned by glitches in the systems. Regional information exchanges can help, but typically do not house all of a patient’s record, only the current, actionable data. What happens when patients move and then return to the same hospital years later? I can tell you that merging patient information can be very tricky.

Release of Information—can you be specific?

When a patient requests all of their health record data, do you really think all of it is collected? If so, how is this verified? Are there any regulations that state this type of request has to be complied with fully? Essentially, the patient has to fill out a form and select which information he/she wants, with an “other” line for her to fill out. This could leave many documents behind because the patient has no idea how many types of documents are in a healthcare ECM system: hundreds, if not thousands.

Every Visit to the Doctor’s Office

Every visit to a provider generates thousands of records. There is the registration which gathers insurance information, signatures for consent, appointments. There’s the nurse who enters current information about allergies, weight, body temperature, blood pressure, etc. He may or may not have paper forms as well for the doctor. The doctor opens another form on the computer, shows test results maybe, enters in clinical notes, writes a script, enters in a diagnosis code, and so on. Many of these entries are split up and branch to other systems for further processing.

From One Record to Many

A patient’s healthcare record will never be “one” record, it will always be a tree of information, or many trees of information, connected by one or many medical record numbers. A regional exchange will hopefully help to cull a patient’s information trees together. Maybe a national register would help as well, but this is way in the future. Sharing health information transparently would lower healthcare costs, however it would lower profits, so there will be lots of feet dragging before “One” record is achieved…

Hallway Chat Projects

With all of our productivity tools we use to communicate and make decisions on projects, hallway conversions can still drive the everyday decisions and information sharing. The problem is that there’s no way to forward a decision or share information beyond the folks that have the conversation.

Sometimes the conversation is summarized, but usually it turns into action and surprises other team members. It’s the surprise that is a sign that the vehicles of communication of a large company are still not being used. The small company mentality is still there.

Small businesses that grow to large ones slowly have this issue more than ones that grow quickly. The slow growth makes it possible for the relationships and behaviors to stay the way they were without too much change. Fast growth usually brings in MBAs who have learned the structure and designs of past organizations that have “worked”. The case study of fast growth breaks up the old patterns of hallway communications.

So, applying this to IT projects and large project communication, you can experience the symptoms of this hallway phenomenon as the tasks progress beyond the planning stage. When the doers are engaged in the discussions, the scope of the project is usually torn apart. The hallway decisions are fast and furious. The project starts with members shaking their heads. The more experienced team members follow along, but secretly see the gaps. If they speak up, the project manager, who by this time has had a hallway agreement on the deadline, overrides their concerns and pledges to consider them.

The final result of hallway projects is that the project manager moves onto to a new position. The implementation of the project is done, but the fixes and stabilization are painful and disruptive.