“Little Data” and the Shortcomings of the Self-Service Model

31 July 2015

AUTHORED BY: DB Technology


How do your employees and partners obtain the information they need to perform their jobs?

Are they PUSHED information in the traditional way, via reports and emails?

Are they asked to PULL information via a self-service tool, i.e. EMR dashboards and query tools?

The PULL method is the primary method deployed by newer EMR’s, but have you embraced this method in spite of the benefits offered by traditional PUSH methods?

I thought it would be advantageous to look at information dissemination from my perspective as an HIT enthusiast for the last 30 years.

In 1986 I was cutting my HIT teeth as an applications analyst and “do-everything” guy at a mid-sized hospital in Philadelphia. Standards were few and those choosing HIT as a career path were fewer. You learned from vendors, reading technical manuals and putting out fires.

My first big project was implementing Shared Medical Systems Spirit platform, which was SMS’ first turn-key mini platform. This led to managing of other tertiary clinical applications and methods of creating information. Each new platform we installed was bundled with standardized reports focused on daily activities, DNFB accounts and payments by patient type. All reports were QA’d by vendor and staff prior to go-live to certify accuracy. These standard out-of-the-box reports were the lifeblood of staff’s workflows, and believe me I would hear it if they weren’t delivered by 6 am.

Reporting exploded as data became richer and tools emerged to create specialized ad-hoc reports. Soon we were creating ER patient flow analysis, profitability by attending physician, nurse staffing by patient acuity and then linking data between disparate platforms.

Life was good, but we were mass murderers of trees. End-users were happy because we took a personal approach to design. We would sit with end-users to analyze their needs against the data collected. When required, we would add new data fields and workflows to collect that information accurately. Finally we would validate output structures, ensure accuracy and schedule reports for the desired time frame. Each day or week or month the report would print. In the 90’s we downloaded reports to our content management platform (quick plug – this was soon to be my company Dbtech). Now all reports were readily accessible, and audit trails let us know exactly who was, or was not, reviewing their reports.

My formative years were spent understanding need, locating data and constructing formats to enable user workflows. These were the “Push” years, because it was our responsibility to ensure the report, spreadsheet or database was created and pushed to users and business partners in a timely way.

Change loomed somewhere in the mid-90’s. During a PeopleSoft implementation I noted that disk-space and CPU resources were significantly more robust than in the past. Data could be kept indefinitely and sophisticated queries could be run real-time. The writing was on the wall, but major HIT vendors would take years to catch up to this model.

Most modern EMR’s are fashioned with few standard reports, and end-users are expected to operate in a self-service model where they pull their own information. In this pull world, users access report writing tools and pull data as needed. In some implementations, the IT department creates general templates for users to enter query parameters. This works fairly well, but does not address those reporting situations where the timing of data generation is critical. The report will look different if run on August 31st at 11:59 PM as opposed to anytime on September 10th.

Another method is to provide the user with a full query interface. Now end-users are playing the role of IT analyst. Maybe this is fair and is a reflection of how IT is part of everyone’s jobs today, but it can be problematic when users select the wrong data, or create a query that is particularly taxing to the EMR or its reporting database. In this world we have a real problem of focusing on the wrong data, or worst yet, not focusing on the data at all.

To the system designers this must have been intended as empowerment, but for many users it is a speed-bump that did not exist before.

For the moment (because I know that once HIT is exposed to big-data this will change) patient accounting and general finance are your biggest data consumers, and from my perspective they seem particularly annoyed with this new Pull mentality. Many of these users access these new systems exclusively to generate their own reports.

For me life is always about balance and I think both the Pull and Push methods have their place. Pull methods are fine in some scenarios, assuming your end-users know how to data mine and construct data exports. But when the situation is time sensitive, I want tools that Push information to responsible parties. This means end-users are immediately notified the information exists, that it is readily accessible, and that they are expected to review it immediately.

I think there is room for multiple methods of information delivery.

Please click on the image below if you want to learn more about Dbtech.

Want to learn more? Fill out the form below and a representative will call you ASAP!