ECM: Point vs. Enterprise Solution

Scenario

The industry is healthcare (so lower budget by default for IT projects). The project is a document control system which needs to manage the publishing, approvals, security, and readership of policies and procedures.

Issue

The team has seen other point solutions which are exactly what they want. In their world, these solutions are perfect, however in the larger world of trying to make connections between the morass of information within the entire hospital system, the ECM solutions needs to be used, or at least integrated.

Failure in the Past

Program and port folio management was not part of the ECM initial rollout. There was no information architecture from a content management perspective. The informatics and integration architects have no idea what the implications of using the correct metadata for index/search means at the enterprise level. They know what to so with patient account data and paper forms and clinical notes, but when comes to weaving this information together, not so much.

Finding a solution

So put aside the lack of PMO and let's focus on how to blend the desired point solution with ECM. Paper is still used for reviews and approvals of the SOPs. The groups responsible for writing the procedures are not very familiar with metadata, they really scratch the surface with MS Office products. Trying to demo an ECM workflow with versioning, convert to PDF, and electronic signatures did not go over well. The group needed to drive with a permit and an instructor first.

Options

• Use ECM workflow solution, dump files in the existing repository as a pilot and keep revision and approval outside the system.
• Scan existing SOPs into the system and just using the scans as for reader acknowledgement and approval.
• Use Sharepoint as a bridge between MS Office and the existing ECM solution. The problem with this is that Sharepoint could easily take over the whole process.
• Build on the status quo of the paper process, but use MS Office for revisions, Acrobat for signatures, email for workflow and folders for storage and presentation to the readers.
• Pilot the point solution and integrate it with ECM at the reader acknowledgement and presentation stages.

Politics and Operations

Who has the money? Without PMO, the money for projects magically appears. So, the doc control group seems to think they have the money for the point solution. Politically, does IT dictate the ECM solution as it has implemented it with the assumption that there would be ROI only with penetration and scale.

Solution

• Level set the group's understanding of the publishing tools, the revision and approval process, common metadata (ie Dublin Core), records retention, complying with the rules (HIPAA, CAP), etc. 
• Find bridges between the old way and the new way of doing things, like using MS Word for revisions, isolating certain workflow steps like approvals and using a point solution for it, or using Acrobat for electronic signatures. 
• Push for using the ECM solution as the metadata and content layer which will at least assure that the "big data" guys will be able to find the content and try to use it in their big data cubes. 

Designing an Export Tool for Livelink

Designing and Export Tool for Livelink

For those of you who have not created an export tool, here's a high level write up of one. 

Overview

The Export Tool has been developed to handle multiple ways to query and export content with metadata derived from system and category attributes.

Key Features

• Multiple Query Methods
• Export content and metadata
• Recovery from failed exports
• Duplicate detection
• File hash reporting for validation
• Exports generations, shortcuts, all versions, and compound documents

High Level Flow of Export Methods

Input Parameters

Parameter	Sample Value	Purpose
Server = args[0];	"Servername"	OT content server host name
Port = args[1];	"2099"	Port of service
DFT = args[2];		Not used
User =  args[3];	"Admin"	Administrator user name
Pass =  args[4];	"Password"	Administrator password
dbURL= args[5];	"jdbc:oracle:thin:@dbname:1521:repositoryname"	Database connection
dbUser= args[6];	"Username"	Database User
dbPwd= args[7];	"Password"	Database Password
ExportFilePath = args[8];	"c:\\RepExport\\"	File system path to export content files to.
CSVFilePath = args[9];	"c:\\RepExportCSV\\"	File system path to write CSV files to
TrackFilePath = args[10];	"c:\\RepExportTrack\\"	File system path to write tracking file to
QueryString1 = args[11];	"ID to search on"	Query string to pass into export tool
TrackFileValue = args[12];	"C:\\RepExportTrack\\ExportTrackerXXXXXXX.txt"	File path to point to the tracked ids that have already been exported

Sample Export Tool command line:

java LLExportTool "docadm" "2099" "" "Admin" "password" "jdbc:oracle:thin:@databasename:1521:repname" "username" "userpassword" "c:\\RepExport\\" "c:\\RepExportCSV\\" "c:\\RepExportTrack\\" "0000000" "C:\\RepExportTrack\\ExportTrackerXXX.txt"

Export Search Query Types and Methods

Metadata

Example:

QueryString1: "select dataid, parentid, name, versionnum from dtree where name like '%Test%' " ;

Method:

runExportBySQLQuery(session, doc, conn, ExportFilePath, CSVFilePath, QueryString1, QueryString2, LLExportLog);

FolderId

Example:

QueryString1 is a predetermined parent folder id.

Parameters:

String QueryType = "Folder";

boolean DryRun = false;

int WaitTime = 0;

Method:

runExportByFolderId(session, doc, conn, ExportFilePath, CSVFilePath, QueryString1, QueryString2, LLExportLog,

QueryType, DryRun, WaitTime, TrackDataIds, LLExportTracker);

FullText

Parameters:

String QueryStringKeyWords = "test";

int ResultNumber = 100;       

Method:

runSearch(session, doc, conn, ExportFilePath, CSVFilePath, QueryStringKeyWords, QueryString2, ResultNumber, LLExportLog);

CollectionId

Example:

String QueryStringCollection = "select dataid from collections where COLLECTIONSID = 1 "

Method:

runExportByCollection(session, doc, conn, ExportFilePath, CSVFilePath, QueryStringCollection, QueryString2, LLExportLog);

Validation

Approach

Build test case folders, files, shortcuts, generations, etc.

Produce results using Pathbuilder or XML export

Verify Export Tool results with those produced by the validated tool

Quality and Integrity of Information in Healthcare

Quality and Integrity of information is only as good as its solution documentation and resource accountability. The best way to measure info quality is to detail (Zachman style) a failure of the system, figure out accountability and share the understanding of what went wrong and how to fix it. For example, in a healthcare system, when the registration system goes down, presumably it fails over to a hot swap database which is current with account numbering. If the account numbers are not in synch the risk is high for duplicate encounter numbers to be given to patients.

The day of the failure and duplicates goes by, patients are admitted. But, the next day when their bracelets are scanned for medication some patient’s account numbers are rejected because the patient names don’t match. The doctor or nurse looks up a CT Scan by the account number and sees another patient with a different name in the search result. An admin scans a consent form, enters the account number and scans in the form under a different name.

So, what happened here? Why were duplicate account numbers permitted to enter the Electronic Medical Record system in the first place? Well, this is apparently, okay according to the information architecture -- when merging two patients this could be a scenario. What? ECM solutions with systems like Documentum would call this a relation, but would never “merge”, thus erasing the history (and integrity) of information.

After discharge the patient goes home, and the hospital forms are scanned and indexed. When the QA person looks at the actual scanned form, she sees a different patient name. How will this get fixed? The Hospital Information Management department needs to process these patients through coding so the information can get sent to the insurance company and the hospital can get paid for services.

First, what happened? Was the registration faulty failover to blame? It introduced the duplicates and team did not even know it. The EMR team did not know what happened. The integration team did know about it, but didn’t sound the alarms. This issue was exposed by the nurses with medications and admins trying to scan in the front line.

Second, what was done to fix it? Amid quiet desperation, a slow resolution was worked on. No accountability, no consequences. The issue with healthcare information management is that it is patched together by longtime friends who watch each other’s back – this is not isolated to healthcare, obviously. Personal knowledge over sharing is still the preferred mode of operation in most IT shops.

Knowledge Sharing

Documentation, sharing knowledge, is the first hurdle to get over. It is not easy to revamp inventories of applications, what they do and why. Departments like to hold onto the applications that they “own” even if efficiencies and consolidations at the enterprise level makes sense. So one way to force it is the point to an industry regulation and say, “we must do this to comply with the law”, or risk heavy fines. Or, the security and data integrity risks are too great and HIPPA regulations will nail us.

Accountability

Accountability, having consequences, is paramount to achieving the minimum quality standards of information needed to function without careless mistakes. For example, if the backup and restore process were tested and signed off on by directors do you think the duplicates would have happened? Accountability helps morale of the team(s) in IT as it exposes what happened, who did it, why they did it, and should offer up the best ways to fix the issues. If the director or manager was negligent, figure out why and fix it. If the architect did not follow protocol, call it out for everyone to learn from. This is not a playground here, this is people’s lives, more serious than systems like hedge fund transaction services and yet financial and pharmaceutical systems run more smoothly and with higher quality.

Quality

Quality, doing the right thing, is not achievable without knowledge sharing and accountability. Of course, the strategy and goals filtered down through a strong program management structure is vital as well, but I’m focusing just on a few concepts and an outcome that healthcare IT desperately needs to get right, every time.

Integrity

There is a gap between personal integrity of workers in a hospital and information integrity of the patient's medical record. Hospitals have to balance the costs of both types of integrity. However, it's time to respect and do no harm to information as well as a person's health. It's time to innovate how we 

What is Information Management Progress in Healthcare?

Progress starts with learning from previous mistakes by instituting solutions and rules which prevent the same mistakes from repeating themselves. Of course the conditions that lead up the mistakes can change so the solutions and rules must be fundamental enough to deal with them. So, where is information taking us? Where specifically in healthcare?

In Healthcare we have, medical research data, patient data, what the medical field does with the patient, regulations which produce forms for the patient to sign, codes which need to be matched to procedures for billing, analysis which checks the coding accuracy, audits, etc. There are many information systems which interact with each other.

A question to ask a Healthcare IT department is what can be done to eliminate the integration parts of your information processing? That is, why do so many software solutions need to be integrated through a service layer which is basically acting a broker between point A and point B. Why are properties of information being “tweaked” during this process? Is there such thing as information integrity?

Another question to ask is do friendships among IT folks affect professionalism? That is, when a database outage affects data integrity in applications that rely on it, was the DBA held accountable, or was it deemed unavoidable between friends.

Healthcare information will not progress to better integrity when the IT department at a facility is just at work for the day job. To really reform this information and get back its integrity anyone has to feel discomfort, everyone has to change the way they think about their jobs. Will this happen quick enough to give the best care possible to patients who need accuracy and privacy? We’ll see.

The changing of CIOs every few years at the hospital system will help, as new ideas are sorely needed in Healthcare IT. I don't have enough experience in the Healthcare field to know if there have been a series of "progress traps" in the past (I'm sure there has been), but I am ready to help push progress forward a notch in hopes of giving patients what they deserve, especially for the money that is spent on their care.

When a DBA holds all the cards

As we move through the life cycle of content management projects, we deal with project managers, internal and external vendors, technical architects, storage managers, and database administrators (DBAs). Sometimes DBAs are reactionary, sometimes they are forward thinking and actually care about projecting growth of data.

You could spend weeks with the software QA department trying to tune the queries that are slow only to find out that the database is maxed out, or the software is tuned for MS SQL over Oracle, or vice versa.
During major upgrades or migrations, DBAs need to be on top of their game, they need to anticipate a jump in database size, RAM, and CPU utilization. When they get caught not doing their job is when performance slows and users start complaining. This puts you in the middle, having to explain to the users and project sponsors that, “yes, you allowed for this possibility”, but, “no, we are still looking why this happened.”

DBAs can either go into cover your ass mode, or fess up to their oversight and make plans to fix it. The tell tail sign that you are being stonewalled is when you ask a question and you never quite get a straight answer. Sometime you get an answer by way of push back, like, “what queries are you guys running anyways”, or you get long responses that tout their expertise and knowledge, but still don’t answer the questions of performance.
 

So how do we light a fire under the DBA to boast performance that is obviously being affected by over taxed RAM and CPU? We could escalate the issue to managers, which could work, if the management is accountable and works well with one another. We escalate the issue between the users and the DBA, which would put the two parties most affected by the performance in the same run to describe the pain of waiting for results.
 

The bottom line is that we need to include all players in a meeting during the planning phases to make sure everyone knows the ramifications and expectations of the project and to have face to face agreements which are a lot stronger than email acknowledgements.

Documentum vs. OnBase Part 4: Access Control and Privileges

This is an odd one, it could be a comparison where patents play a role in the underlying design because in OnBase there is no explicit mention of “access control”. Let’s try to build a simple use case to illustrate the differences between the two approaches to control who can do what when to a document.

Use Case: Excluding a reader group from viewing documents in their draft state, then allowing the reader group to view documents in their approved state.

DCTM:

1. Create a dm_document object type with attributes
2. Create a permissions list for draft and approved
3. Create a lifecycle for the document type
4.  Add two states for draft and approved
5. Add an action to each state to apply the permission set (or ACL)
6. Apply the lifecycle to the document upon import (manually or automatically)

Or

1. Use ACLs inherited from Folder Security and the folder’s permissions
2. Do steps 1 and 2 and set permissions on folders and use folder security, moving documents from a draft folder to an approved folder

Or

1. Use ACLs inherited from the Owner’s permissions
2. Do steps 1 and 2 and set permission manually on the document after

Or

1. User ACLs inherited from the document type’s permissions
2. Do step 2 and set permission manually on the document after

OnBase:

1. Create two document types: draft and approved
2. Create two User Groups (at a minimum); one with privileges to create, modify, and delete the draft docs, and one with privileges to view the approved document type
3. Assign the ability to change doc types to the author’s group

Use Case: Make a document revisable

DCTM:

1. Create an ACL with Read/Write/Version permissions
2. Apply it to the document

OnBase:

Change to privileges on a group that is linked to the doc type

Thus, in OnBase it is routine to change doc types as keywords are shared across the types, which is taboo in DCTM. However, in DCTM you have three distinct ways to inherit permissions. This is more flexible. The overall difference in permissions is that OnBase is group privileged based and DCTM is primarily object permission based. Groups are a lot more configurable in OnBase which lends itself to easier setup from a User’s perspective. In DCTM, the document object has its own attributes and is linked to ACLs and Lifecycles. In OnBase, the document is more of an equal player in the system.

Documentum vs. OnBase Part 3: Scan/Index workflow

In Parts 1 and 2, we looked at configuration and relations. Now let's look at scanning and indexing using Documentum's tools vs. OnBase's.

Documentum offers a wealth of tools and functionality for scanning, indexing, and validating paper. The huge difference between Documentum and OnBase is that the OnBase user interfaces are integrated into the scan/index modules. You don't have to index in one UI, then switch to another for further processing like you do with Captiva products. EMC bought Captiva but did not fully integrate it.

The concept of a interoperable modules was probably not considered as the most important aspect of the acquisition. However, as these software acquisitions play out over time, you can see the long term negative effects of not integrating the products. I believe the days of buying software to gain market share only are gone. It may be profitable in the short run, but these purchases need to be well integrated in the long run to be viable.

Invoices: Documentum
Let's say you use Input Accel to scan and index invoices for example. You will have to have an approval workflow and an auditing workflow. Which UI is used for the approval workflow, Input Accel or Webtop or xCP, or D2? Which systems tries to match the POs by invoice number, receipts, and total amount, or is this custom? I have seen some of the xCP solutions for this activity and they are complex and expensive and custom to the general ledger integrations.

Invoices: OnBase
Scanning and Indexes are configured and executed through OnBase's Clients. There's no patch work of double checking and exporting, there's just one interface called "Import > Scan/Index", that's it. You set up the scanner, give the workstation rights to scan, configure the document type and scanning queues, and you're good to go. Oh, and the workflow can be configured to execute after you commit the batch. It's all in one and takes about a 5th of the time to configure. It scales as well.

Let's face it, EMC treats Documentum as a repository for dumping content. It cares about amassing storage first, then figuring out what to do with it, eventually...