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

The road to no paper in healthcare

Of course the end goal of any paper in your organization is full conversion of paper to online forms, however, scanning paper is an intermediate step toward this goal.

According to Seth Godin, this should not be a “finite game” where there are winners and losers, this should be an “infinite game” where we implement a strategy to become more connected and raise all Users’ ability to serve.

Outline of Steps and Considerations

IT Strategy Component

At the highest levels in IT, there should be a healthy understanding of the positive effect of rules for publishing and presenting information. What I mean by this is that the information on paper is priceless and yet the techniques of gathering, collating and aggregating are from twenty years ago. Even with paper, rules need to be created and disseminated on form templates, fixed information boxes, choices instead of free text, etc. These will have to be decided at some point, why not get it started now...

IT stability

There will need to be a fallback Plan for unexpected outages and routine maintenance downtimes for when the system changes and evolves. This will most likely be paper forms or local backups on the network which could get synced up later.                        

Information Integrity

Need to clean up the metadata of the paper and scan types: naming conventions of form types, folders, metadata: look for implicit hierarchy in names

To Barcode or Not

If you don’t have advance capture to train on fixed forms which are controlled within the organization, then you should use barcoding to reduce indexing times and inaccuracies. That said, you might want a bar code available to add to forms when printing for patient information requests or transfers so that the form type can be read from other sources.

Centralize vs. Distributed (hospital content)

Centralize

• Pro: Easier standardization, less configuration, thus easier change management
• Con: Less location specific knowledge

Distributed

• Pro: Easier transition to electronic forms?
• Con:
• Registration
•  First system which Patient information is entered
• Forms and Signatures
• eSignature possibilities
• eForms and HL7 messages

Form Origin: within or outside of company

Docs within control

•  Information quality assurance
• Form standardization (across locations)
• Predictable Format
• Scan/Index standard forms
• General OCR
• Zonal OCR
• Template recognition
• Systems of origin
• Registration
• EMR
• Billing
• Building eForms from standard forms
• Form Differentiation
• identify and categorize the forms by functional groups to have scope and front load the system with abilities to convert to eForms in the future
• Patient Forms
• Signature required
• Patient and Witness signature required
• Other information added and signature required
• Other information added
• Types of information required?
• Clinical Forms
• Medical signature required
• Medical signature required and Patient signature required
• Other information and Medical signature required
• Other information and Medical signature required and Patient signature required
• Other information added
• Other Forms

Doc outside of control

• Unpredictable format
• Collect paper samples by categorization from groups responsible for scanning them
• Determine patterns of categories across all document types and sources
• Ask for style guidelines from outside sources
• Predictable Format
• Standard Form Scanning
• Standard barcodes
• Standard information interoperability

Cost "Profiling" IT

Seth Godin, in "The Icarus Deception", wants us to learn how to see, to make, and to begin from a blank slate. We are all artists, he says, and "You need to know the conventional wisdom inside and out. Not to obey the rules, but to break them".

We tend to "profile" projects and copy what has worked in the past, or see projects based on models. IT operations does not like change, or breaking the model, they want to quantify and execute their projects. For example, this enterprise software will help consolidate all rogue applications having to do with X. The Users of X will have to conform to the standard enterprise software in order to save money.

So, the convention is to save money on an enterprise application through consolidation and scale, but to customize it because the out-of-box functionality is too generic to satisfied the needs of every group. Each customized feature, makes the application harder to change. The application could grow to be too big to upgrade within the downtime window.

The Users and applications are "profiled" and the solution is crammed down the enterprise. Is there a five year technical plan with the five year operations plan? I doubt it. Does cost profiling really suit the Users in the long run? What would happen if business groups could pick and choose their applications like we do from a cell phone menu of apps? The menu would be the enterprise; the app choice would be the business's. We need to really embrace self service at the enterprise level. Self service with simple to configure apps, what a concept...

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.