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.

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.

 

Paper to scanner to ECM

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…

Pathways to No Paper

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:

• Paper to scanner to ECM
• Fax to ECM
• Fax to email to ECM
• Email with attachments to ECM
• Fax to directory to ECM capture disk sweep
• Index to QA to ECM
• Barcode to index to QA to ECM
• Capture to QA to ECM
• Modify paper forms to suit needs of capture and barcode
• Modify paper forms to suit needs of web forms
• Web forms to ECM
• ECM forms
• Mobile forms

Spinning Sensation of IT Projects

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?

Techniques to pitch your innovative ideas in IT

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.

Some Myths of Big Data

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. 

When ECM's “How” gets in the way of the “What”

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.

OnBase VBScript to Export a File

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.

·         Database connection

o   Const CONNECTSTRING = "DSN=onbase;UID=hsi;PWD=xxxxxx"

·         Destination of copy

o   DestinationFolder = “\\\”

o   DestinationFile = DestinationFolder & oDoc.Handle & ".TIF"

·         Source of file

o   FileSystemPath = Trim(oRecordSet(0)) & Trim(oRecordSet(1))

o   SourceFile =  "\\

Script Code

Test

Sub Main35()

Const CONNECTSTRING = "DSN=onbase;UID=hsi;PWD=xxxxxxx"

' Root level OnBase Automation object

  Dim oApp

  Set oApp = CreateObject("OnBase.Application")

  Dim oDoc

  Dim cKWs

  Set oDoc = oApp.CurrentDocument

  Set cKWs = oDoc.Keywords

  Dim sSQL

  Dim oRecordSet

  Dim oConn

  Dim i

  Dim FileSystemPath

 'MsgBox "oDoc.Handle:" & oDoc.Handle

  'open connection

  Set oConn = CreateObject("ADODB.Connection")

  oConn.Open CONNECTSTRING

  sSQL = "SELECT b.diskgroupname, a.filepath FROM HSI.itemdatapage a, hsi.diskgroup b WHERE itemnum =  "& oDoc.Handle &"  AND a.diskgroupnum = b.diskgroupnum"

 'MsgBox "sSQL: " & sSQL

  'Get recordset by executin query

  Set oRecordSet = CreateObject("ADODB.Recordset")

  Set oRecordSet = oConn.Execute(sSQL)

  If Not oRecordSet.EOF Then

       'MsgBox "Trim(oRecordSet(0)): " & Trim(oRecordSet(0))

       'MsgBox "Trim(oRecordSet(1)): " & Trim(oRecordSet(1))

      FileSystemPath = Trim(oRecordSet(0)) & "117" & Trim(oRecordSet(1))

  End If

 'MsgBox FileSystemPath

 ' Call oDoc.StoreKeywords()

  oRecordSet.Close

  Set oRecordSet = Nothing 

  oConn.Close

Dim DestinationFolder

DestinationFolder = "\\destination share drive\"

'MsgBox DestinationFolder

Dim DestinationFile

DestinationFile = DestinationFolder & oDoc.Handle & ".TIF"

'MsgBox DestinationFile

Dim SourceFile

SourceFile =  "\\

'MsgBox SourceFile

Set fso = CreateObject("Scripting.FileSystemObject")

    'Check to see if the file already exists in the destination folder

    If fso.FileExists(DestinationFile) Then

      'Check to see if the file is read-only

      If Not fso.GetFile(DestinationFile).Attributes And 1 Then

            'The file exists and is not read-only.  Safe to replace the file.

            fso.CopyFile SourceFile, DestinationFolder, True

      Else

            'The file exists and is read-only.

            'Remove the read-only attribute

            fso.GetFile(DestinationFile).Attributes = fso.GetFile(DestinationFile).Attributes - 1

            'Replace the file

            fso.CopyFile SourceFile, DestinationFolder, True

            'Reapply the read-only attribute

            fso.GetFile(DestinationFile).Attributes = fso.GetFile(DestinationFile).Attributes + 1

      End If

    Else

      'The file does not exist in the destination folder.  Safe to copy file to this folder.

      fso.CopyFile SourceFile, DestinationFolder, True

            'MsgBox "file copied"

    End If

Set objFSO = CreateObject("Scripting.FileSystemObject")

Set objFile = objFSO.GetFile(SourceFile)

Dim SourceCopiedFile

SourceCopiedFile = DestinationFolder & objFSO.GetFileName(objFile)

fso.MoveFile SourceCopiedFile, DestinationFile

     

Set fso = Nothing

Set objFSO = Nothing

  Set oConn = Nothing

  Set cKWs = Nothing

  Set oDoc = Nothing

  Set oApp = Nothing

End Sub 'Main35()

Scanning Forms can be Tricky

When scanning into batches and selecting document types to index, there are many issues that cause misfiling. Below is a list of findings from a typical set of scan queues across different departments and facilities:

·         Forms with Exact Name as Doc Type are more accurately filed.

o   Exception: Admission Orders: Bariatric Surgery Procedures                   

·         It helps to have a standard form across practices and checkbox to distinguish the location

·         Forms with labels are more consistently filed

·         General doc type names get all of the misfit forms

·         Some misfiles are from changes to doc types which leave the old docs in general types and the new ones go to the newer more specific types

·         Inconsistent form headers and footers cause misfiles

·         Machine printed forms are more accurately filed

·         Some Doc Types have less than 10 scans in them

·         Very specific names gather all forms of that name whether they are correct or not, for example: “pH” or “Esophageal”

·         Barcoding for doc types is very accurate, however, the form names need to be consistent and sometimes the barcode doc type is manually re-indexed to a different doc type

·         General Form Names as a Heading (large type) with specific names as sub heads underneath sometimes get misfiled

·         Some Doc Types were created for a specific facility and are misfiled against because they don’t have the same form names as other facilities, ex. HIV Informed Consent

·         Regardless of language, the forms should have the same template layout

·         Forms should be consistently scanned, for example, the same front page, number of pages, layout, etc.

·         Redundant doc types should be consolidated: “Consent for Participation in Pet Visitation Program” and “Consent for Participation in Animal-Assisted Therapy Program”

·         Non-company forms are mixed in with company forms

·         Some redundant doc types are used by different scan queues, for example one facility uses both “Peripherally Inserted Central Catheter (PICC) Consent Form” and “Peripherally Inserted Catheters Consent”, while the other facility uses “Peripherally Inserted Catheters Consent”

·         There are clusters of doc types that are close to the same definition that should be considered for consolidation, for example,

o   HIV Informed Consent

o   HIV Testing Consent Form

o   HIV Testing Informed Consent, Health Care Worker Exposure

·         Doc Types no longer in use should be taken out of the scan queues

·         Some doc types have names that are too limiting: ex: “Sterilization Consent Form Ages 21 or Older”, where some of the forms are for ages 18-21…

·         Some doc types have “or” instead of “and”: ex:  doc type is  “Consent for Surgical or Diagnostic Procedure”, while the form’s name is “Consent for Surgical and Diagnostic Procedure”. The “or” suggests that this could be for either surgical or diagnostic procedures, not both…

·         Groupings of types should start with the same label value

·                         Example: consents should all start with “Consent”, then the second defining label

·         General types should be further detailed

·         Specific department types overlap general types