Sunday, February 24, 2013

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

Saturday, February 9, 2013

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...

Sunday, January 27, 2013

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. 

Wednesday, January 23, 2013

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

Saturday, January 12, 2013

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 

Sunday, December 9, 2012

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.

Saturday, November 24, 2012

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.