Recommendations vs. Requirements

I read an email from an IT director a few weeks ago that was explaining how we should proceed with a particularly troublesome issue. The email explained that the User's of the system can "recommend" changes to the website, and that IT will "review" them. It's old school to say "recommend", like really old school, before the concept of documenting requirements to solve a business problem old school.

How does this happen? How can IT management still think that they have the innate ability to understand the intricacies of what business User's want without documenting requirements? It can't and that's the point.

With most information technology, the people who know how the software is designed to solve issues are the first ones to evangelize the usefulness of it. They are usually very familiar with the business processes and at the time know a lot about what the Users need. However, over time these same folks will inevitably lose that edge. That is when they need to start asking their User's what they need. The problem is that pride and prejudice enter into the behaviors and thoughts of the original designers of the system. They are the architects. They feel entitled to dictate what should and should not be included in future designs.

Thus, please be sure there is ample documentation of requirements and functional specifications which solve the issues, and that these docs are updated or superseded. The worse thing that can happen to a system in the long run is to rely on one architect for all design questions and answers because the one person is surrounded by many who have unique perspectives and could potential have more innovated ideas on how to solve problems.

Healthcare ECM is a safety net

Let's face it, the implementation of ECM systems in healthcare is done as a cheap safety net. What I mean by this is that a Director or VP looked at their EMR for example and realized 20% of the results and clinical notes were still in paper form. The price of a scanning solution offered from the EMR software company was prohibitive. In comes a less expensive player, like Hyland OnBase, and fill the gap, creates the safety net.

Smart software companies like Hyland know that their base product is the low bidder, however they have modules that add up in price as more functionality is required. The key is to have the best niche product along with the ECM software. In Hyland's case it's their scanning solution.

ECM as the safety net is not a bad position to be in. Being a "blank slate" so to speak starting out, this allows motivated individuals to build point solutions internally, which, assuming that the company has a good methodology in terms of solution development, can help solve many issues. The expensive alternatives may never even get considered if the financial benefits are not good enough given the cost.

ECM development is flexible, it is up to the IT group to solution architect to the level of competing point solutions. We know that projects of today will be usurp as off the shelf products of tomorrow. This is a one of the ways the ECM pushes innovation in the industry. A trend in a solution across an industry is bound to result in a software product that kills the ECM solution of a 5 years ago.

Fax to directory to ECM capture disk sweep

If you have a multi functional device, you might have the capability of saving incoming faxes to an attached PC or storage device. The fax can usually be saved as a PDF or TIF. The folder where you save the fax image is based on your ECM's scanning configuration. This configuration is scheduled to "sweep" the folder location periodically to import the images. The processing of these images is preset, meaning that the images might have barcodes to be read for indexes, or be routed to a workflow. This type of processing is common in companies that have MFDs that are dispersed. It can save on licensing fees and scales.

Back to pathways.

Email with attachments to ECM

Some vendors will want to create invoices or patient information in electronic form, such as PDF. They will want a email address to send it to as an attachment. There are many aspects to consider when automating the processing of email with attachments:

• Setting up the email account (who has access, gets notifications, what listener to set up)
• Rules for routing the email based on subject content, from address, body of the email
• Whether or not to store the email body
• Determining the attachment's contents: one page per attachment, all together? Different PO's in one batch?
• Whether to split up the attachment
• Classification of the attachment: who is it from?
• OCR of email body and attachment(s)
• Advanced capture on the attachment to automatically index the page based on PO# for example

For each of the above aspects there are many finer details, but it is clear that this type of interchange of information is not ideal. For one, it would be better to setup a formatted xml file which describes all of the attachments, their PO# or Account#, the basic metadata of each file such as invoice number, total amount, vendor name, or for healthcare MRN, Patient Name, date of birth, etc. There's room for improvement and eventually this type of communication will be much accurate. 

OnBase Unity Script to Export an Image

Link to other Onbase Scripts

Writing a script in VB or C# for OnBase is not hard once you take API course or you get you hands on the SDK for OnBase. I had neither the first time I wrote a VBScript to export a file from OnBase. I read through some samples and fumbled my way through only to realize that the script I wrote could only export the first page of an image which multiple pages appended to it. So here's a basic Unity script written in C# which will export the whole file from a workflow action to a local drive. Enjoy!

namespace SaveToFile
{
    using System;
    using System.Text;
    using Hyland.Unity;
    using Hyland.Unity.Workflow;
    
    
    ///

    /// Save a file to disk
    ///

    public class SaveToFile : Hyland.Unity.IWorkflowScript
    {
        
        #region IWorkflowScript
        ///

        /// Implementation of .
        ///
        ///
        ///
        ///
        public void OnWorkflowScriptExecute(Hyland.Unity.Application app, Hyland.Unity.WorkflowEventArgs args)
        {
            // Add Code Here
try{
string dirPath = @"c:\Temp\" + args.Document.ID + ".";

//create doc
Document wfdoc = args.Document;


//Redition
Rendition wfrend = wfdoc.DefaultRenditionOfLatestRevision;

//PageData
//using for the disposal
//PDF for the format

using (PageData wfPageData = app.Core.Retrieval.PDF.GetDocument(wfrend))
{
//Utility to write data page stream
Utility.WriteStreamToFile(wfPageData.Stream, dirPath + wfPageData.Extension);
}
}
catch(UnityAPIException Uex)
{
app.Diagnostics.Write(Uex.Message);
}
catch(Exception ex)
{
app.Diagnostics.Write(ex.Message);
}

        }
        #endregion
    }
}

Fax to Email to ECM

Fax cloud services make it easy to convert fax transmitions into email and attachments. These attachments can TIF or PDF and the email can include a cover sheet. This service eliminates the need to use a traditional fax machine altogether.

The trick is integration with your ECM. Hyland's OnBase subscription service allows you to poll an Outlook inbox form incoming emails. Once an email comes in, the service imports the email's body and attachment. It will import both as seperate doc types and then if necessary place the files in a scan queue. This automates the manual email and importing steps in the invoice process for example.

Aspects to consider

Gather requirements around how to route incoming faxes. For example, typically a department like accounts payable will have on inbox which caters to multiple types of requests. In order to route and organize the incoming invoices vs. complaints vs. receipts vs. backup documentation, rules need to be put in place. These rules should start at the inbox level. This means breakout the major types of the incoming emails, for example, invoices and backup docs. Then look at common values in the email's subject, to and from, and body text. Each of these will help tag incoming content with pertinent metadata.
 

Fax to ECM

Many companies still rely heavily on faxing paper for accounts payable, legal transactions, and signed documents for finances and medical records. These docs consume a lot of paper just to end up being scanned into a document management system. The metadata associated with the documents gets lost every time it is faxed and has to be recreated on the other end manually. This manual process is time consuming and costs a lot of money in the long run.

Document Templates

Laying out a document's design to conform to the way fax machines and scanners read and recognize characters on the page is crucial to get to the next steps in the pathway to fully electronic transactions. The template must be consistent and have distinct features that set it apart from other documents. If there is a logo or header be sure to place it within the margins of the page far enough to that the shifts in the scanner do not sometimes cut it off. This unique identifier will come in handy at the advanced capture stage of scan capture. If the document is an invoice, design it to print out the line items on one line, or within a fixed box per line. This again will help with recognition. If the document is a form with boxes, make the boxes large enough so as not to cut off any data that is printed into them, such as, a date or vendor name. Scanners do not read words with lines between them very well.

Fax Configuration

Make sure the resolution of the scanner's printing is as good as possible. If there are blotches or spots that characters will not be read as well as expected.