Signs a project has problems

Who’s complaining?

If the IT team is complaining about the business not doing their share of the work, then the goals are not clear enough and are not tied to direct accountability. Why would you expect someone to go out of their way to help when that person has no “ownership” of the project? How many times has IT bulldozed an initiative through the business successfully without full cooperation and understanding from the business side? So, if individual team members of the IT team are annoyed, it’s time to reconsider the approach to implementing the solution; somewhere along the line a piece of the puzzle is missing, and it will be obvious when you look for it.

Dotted line agreements

Your project is large enough to span systems which integrate. There is a risk in planning a project with teams who have competing objectives. Scheduling the rollout of the project can be tricky. The dotted line between your project’s goals and the associated extended teams can be deceiving. Make sure there is enough oversight by a “steering committee” which will back up the project during the critical milestones and implementation.

It’s when issues come up

Designs and specs can fall apart when seemingly insurmountable problems arise. In large projects, issues always rear their ugly heads. This is when the team’s cohesiveness is tested. Will everyone rally to fix the issue in a timely manner? When a project schedule slips, there’s usually an issue. The root of the issue can be traced back to some assumption, scope creep, personnel change, etc. The root needs to be explained, transparent and fully understood. This is the learning moment and shouldn’t wait for a post mortem. Explaining what went wrong after the fact is lame and not as impactful. 

Retention Policy: ECM’s software solution vs. what is required

Scenario: you have hired a consultant who has experience in implementing an ECM software’s records management module. This consultant meets with various groups and gathers requirements with questions that pertain to the vendor’s out-of-box solution. The legal department is focused on complying with current laws and regulations around how long to keep their content. Many weeks have been spent on creating a folder structure that conforms to how the software works, that is, if a file is moved to that folder, a retention policy is applied, and the retention period starts. According to proven waterfall methodology, a pilot is executed and signed off on. During go live, there are issues with importing documents and the legal department can’t find their content.

So, what happened with the frozen situation?

First, just because an ECM suite has a product/module for sale that is named the buzzword you are trying to implement doesn’t mean that it actually helps automate the process or simplify the ongoing work involved. In many cases, the module is an “add-on” originally purchased from another company to fill in the ECM suite offering. This could mean that the solution solves issues of the companies who were involved with the pilot or beta of the product. It definitely is designed to meet many general requirements, but will miss 20% of yours, guaranteed.

Second, if the implementation analyst is a consultant, chances are good that something will get screwed up. A good technical assurance management is required to maintain a more balanced point of view, but most companies don’t have them. They may have review boards, but this is not the same as a person on the project who is directly responsible for successful implementation.

Third, if your company is implementing records management for the first time, or reviewing the retention policies in place, you might want to look at healthcare EMRs for reference. Hospitals have been working under HIPAA regulations for a long time. Their information management systems, AKA EMR systems, are all about taxonomies, access control, and retention. Chances are good that they currently keep all electric records indefinitely. This is not a bad policy because ways of organizing information change over time.

Fourth, as content/info management technology improves, overzealous records management implementations slow down upgrades, and changes in metadata and folder hierarchies become major headaches.

Five, personnel changes create havoc around migrating “ownership” of retained content. Does the system allow you to make user accounts “inactive”? If the owner is deleted, does the retention period get reset?

Six, as far as the pilot is concerned, it is typical for a consultant to run unit tests as a super user and for a power user to UAT the pilot. The actual Users are not mandatory participants which is the big mistake. They need to make the time during the pilot beyond executing test scripts in order to fully vet the implementation. The should expect many issues, if there aren't, there will be after go-live.

The bottom line is that retention policies are overrated. I believe the trend will be to simplify these implementations and make it easy to manage in the future not harder…

An IT Project's Soft Deliverables

As an ECM specialist, you know that every time you are involved with a project, there are requirements gathering activities. It doesn’t matter if the project is small, or that “there’s a ton of documentation”. It may be as simple as writing a document that references previous deliverables to build on them. Because content processing is in constant flux there is more a need to not only keep your documents up-to-date, but to keep the non-deliverables going smoothly as well. What do I mean by “non-deliverables”? Well, I’m glad you asked:

Here’s the standard list of hard deliverables:

• Charter
• High level Goals
• Budget
• Resources
• Milestones
• High level deadlines based on upper management goals
• Interviews
• Demos of software OOTB capabilities
• Brainstorming sessions
• Goals refined by business group’s focus, rolling up the high level goals
• Requirements
• Traceability matrix
• Functional Specs
• Logical Architecture
• Use Cases
• Test Cases
• Schedule
• Meeting minutes
• Pros and Cons
• Cutover Plan
• Communications
• Training materials
• Etc.

·       

I here’s a list of soft deliverables:

•        Trust and Presents
•        Quality and Inclusiveness
•        Dependable and Honest
•        Generosity

Let’s look at each of the above “soft” deliverables and how important they are and discuss why projects can be disasters without them.

Trust

I know this goes without saying, but trust is earned, it is not a given. Meeting face to face and getting to know the stake holder(s) and the team is essential. This is a mutual trust. If I say I’m going to do something, I do it, if they say they will do it, they should do it as well. Many times a stake holder will not have time to attend all the meetings. In this case, you have to make sure the stakeholder is delegating tasks to someone else. You also need to make sure that meeting notes are written and that issues and next steps are clear to everyone, with follow up emails stating the near term timelines to get things done. Managing expectations goes hand in hand with trust.

Quality and Inclusiveness

As you interview stake holders as to what their goals are and what they expect the project objects should be, you need to make you ask about whom to include in meetings, who is actually doing the work which will be automated. Pay attention to detail and use the tools such as Visio to visually show and review the processes. There is no such thing as a workflow which is completely done, every time I review a use case or flow on my own or with members of the team I find new exceptions and new ways to looking at the process. The quality of your attention and understanding is crucial. Including as many reviewers and encouraging feedback is also key to the success of the project.

Dependable and Honest

I am not going to preach about the differences between a full time analyst and a contractor, but I will say this, that a contractor is not going to be around for the long run (usually). This means they will say and do things that get the work done at hand. What about the future of the project? That’s someone else’s dime. The stakeholders need to be dependable as well. A project is doomed if the governance of the execution of the project is in flux. A project manager cannot hold to a schedule if the resources are double allocated.

Generosity

We all work hard. Going out of your way to make things happen “the right way” will always benefit the project. We shouldn’t just write documentation because we have to. We should write it because it will help during testing, it will help during the next upgrade, it will help you remember the approaches taken for your next project. Writing to a standard template may work for a contractor, but if you go the extra mile and write for quality and give your best, it will show in the project’s success.

The flow of IT in Healthcare

This diagram shows the information flow for a patient in the healthcare information realm. As you can see, the flow goes as fast as it can toward billing insurance. It does not necessarily care about the patient and the quality of the information. As long as there is an account number, it’s full steam ahead!

As a patient, you feel this. What’s the first thing you do when you go to the doctor’s? You don’t get triaged, you get asked for billing information and oh, by the way, what are you here for? Shouldn’t it be the other way around, like when you bring your car in for service? Have it checked out, then if there is an issue, talk about how much it’s going to cost, then agree or disagree to the service.

Information Technology is a patch applied to a system wrought with politics and policies which have been analyzed over and over again by the best consultants money can buy. It’s a wonder that IT has been this successful in pushing its automation techniques into the heart of healthcare. The disputes between nurses and doctors continue, IT is in the mix now. As Healthcare systems own insurance company, so do insurance companies own hospitals and physicians. Everyone is in line to make money to survive and grow.

Expanding healthcare is fine, but the issue is that the patient has to be vigilant more than ever to ask for all visit related and referred information. They will be tangled in the vines if they are not the keeper of their electronic records.

OnBase VB Script and Thick Client API to export all image pages

Link to other onbase scripts.

Below is an OnBase VB Script and Thick Client API to export all of an image's pages:

Sub Main35()

Dim objApplication, objCurrentDocument
Dim MZ_API, MZ_FIRST
MZ_FIRST = 0
Set objApplication = CreateObject("OnBase.Application")
Set objCurrDoc = objApplication.CurrentDocument
Dim filePath, memHandle, MZ_LOCALPATH, MZ_MULT_TIF4
memHandle = 0

Dim exportDirectory
exportDirectory = "\\share location\"

Dim mzApiSessionHandle, mzAPI
mzApiSessionHandle = ScriptAPI.Session
Set mzAPI = ScriptAPI.Object
Dim returnCode : returnCode = 0

'MsgBox "objCurrDoc.Handle is-" & objCurrDoc.Handle

returnCode = mzAPI.mzInitQueryByDocumentID(mzApiSessionHandle, objCurrDoc.Handle)
'MsgBox "1 returnCode is-" & returnCode


Dim mzApiQueryHandle
mzApiQueryHandle = returnCode
returnCode = mzAPI.mzExecuteQuery(mzApiQueryHandle, 0)
'MsgBox "2 returnCode is-" & returnCode

Dim returnDocumentHandle, outDocumentName, outDocumentType, outDocumentDate, outFileFormat, outRevision, outComment, msg

returnCode = mzAPI.mzGetDocumentInfo(mzApiQueryHandle, MZ_FIRST, outDocumentName, outDocumentType, outDocumentDate)
returnDocumentHandle = returnCode

Dim fileExtension, returnedFilePath
fileExtension = "TIF"

returnCode = mzAPI.mzGetDocumentPage(mzApiQueryHandle, returnDocumentHandle, -1, "Image File Format", 0, 1, 8, returnedFilePath, memHandle)
'MsgBox "returnCode: " & returnCode & vbcrlf & "returnedFilePath: " & returnedFilePath
returnCode = mzAPI.mzEndQuery(mzApiQueryHandle)
Set mzAPI = Nothing

Set fso = CreateObject("Scripting.FileSystemObject")
fso.MoveFile returnedFilePath, exportDirectory & objCurrDoc.Handle & ".TIF"
Set fso = Nothing

End Sub

Healthcare IT: Medical Record or Getting Paid?

So what takes information priority at a hospital, integrity of the medical record, or accuracy of a patient encounter for billing insurance? One keeps the customer coming back, the other keeps the money flowing. It's interesting that many information quality issues are push backs from insurance: the coding is incorrect, the patient's name is wrong, there is no signature, the medical record number is one digit off.

A false assumption is made that hospitals of the future are all online and fully automated. This assumption pervades the big data quants. Big data indexing is not as easy as plugging into an EMR and indexing everything in a cloud. First of all, even with a link from the search hits to the original EMR source, all of the data is not present, it may reside in an ECM system used for scanning and workflow. It may still be 20% on paper. OCR fails at 99% accuracy, Big Data fails at 99.99% accuracy. It has to be flawless to work, that's the issue.

Back to the quality issue: the information motivation is split between data integrity within tables and integration, and with applications, many of which serve the requirements of ICD-9 not the patient's continuity of care. The way access services creates a medical record number and metadata is fine. The problem is that with multiple visits new records are added, some are incorrect. If the procedure is correct and that account number is correct, send it to revenue, let's get paid. Hospitals have deadlines for submitting bills. This forces them to be constantly one step behind the curve for automating their processes and cleaning up their data. They don't have the time.

ECM pushes quality up the stack

ECM, being a sea bottom dweller, has many opportunities to detect and fix issues with information architecture. This depends on the breadth of implementation and integration of the system, however, in most cases, applications which rely on metadata accuracy for processing and presentation will route out issue.

Many times an implementation will bump into a information quality issue by chance, for example, in a healthcare setting, billing information is used as the basis of coding patient tests. The source of this information comes from a registration system and if the hospital is large enough, it comes from multiple registration systems. The patient account number needs to be correct for insurance billing. For auditing purposes, the downstream/bottom dweller ECM system needs to be accurate. If it is not, then the exception is sent back up the stack for fixing. This fix more often than not exposes glitches/bugs in the way the integration engine functions. Sometimes it exposes issues from years ago, but a patient's chart information could have many years of visits and discharges associated with it, as well as non hospital related tests add to it. The bottom line is that an ECM system may only be used for scanning and indexing images, but it most likely is driving quality up to the surface of the more mission critical applications.