Why are we still having problems in the area of Healthcare software?

Blog: KWKeirstead's Blog

The point was made in a recent LinkedIn HIMSS discussion group “At what point does an EHR implementation become too large an endeavor?”

My response was this happens at the time you pick a bad EHR “solution”. The usual outcome is a need for extensive customization which extends the timeline and the cost of acquisition.

We don’t hear many stories about how easy/difficult it was for an organization to “customize”, say, MS Excel.

The reason, of course, is that setting up rules at spreadsheet cells is typically referred to as “configuration” as opposed to “customization” and you can configure different spreadsheet “books” to process data in quite different ways.

With EHRs, you can basically look at the software as having four modules (Clinical, Scheduling, Billing, Data Interchange). Not all that different from spreadsheets, (i.e. different “books” that perform different functions), right?

The statement “. . the level of effort is mind boggling” seems indeed to be the case with many EHRs, but not all.

My view is the origin of the mess the healthcare industry is in can be traced back to the way many of the EHRs were designed (requiring customization instead of configuration).

If your EHR ships with a proper scheduler designed for healthcare, a billing engine designed for healthcare, the only things you really need to worry about are Clinical and Data Exchange.

Clinical

In most Clinical modules you quickly get to the practical problem Dr Liebert raises in respect of clinical work, which, if I am reading it right, is a statement that cookie-cutter medicine does not work.

Practical input like this from experts could have allowed EHR software designers to predict that one-size-fits-all would not work (” . . . the system needs you to do it this way”).

Some went to the other extreme where the customer is allowed to start with a blank sheet and map out clinical best practices as process maps, but with the caveat ” . . . make sure you anticipate all possible eventualities”.

This, too, was “not close, no cigar”.

The lights go on when your Clinical piece has its foundation in ACM (Adaptive Case Management) because, here, you start with a blank sheet, and use BPM (Business Process Management) to map your processes to cover most eventualities, without having to stay up nights worrying about all eventualities. The environment takes care of the need to accommodate ad hoc interventions.

BPM provides orchestration, ACM accommodates (via global rule sets) eventualities you did not include in your BPM process maps.

Think of a highway. BPM is the yellow center line (guidelines), ACM provides the guardrails on each side of the road. You can vary from the guidelines but extreme excursions are reined in by the guardrails.

You get to have your cake and eat it.

Don’t try to go out and buy an ACM EHR. ACM is a methodology, not a piece of software.

Data Exchange

The wrong turn with Data Exchange was to reckon that EHRs need to be standardized so that they can exchange data.

One generic standalone Data Exchanger is all you really need and, simply stated, most of all of what it needs to be able to do is to take in data from publishers and make different subsets of this data available to different subscribers.

Publishers clearly want to post using their native data element naming conventions, subscribers want to read using their native data element naming conventions.

In respect of data types, character strings are fine for most data and you can post complex objects such as video files with an indication of their file type so that subscribers know what program is needed to access/open the file.

Data Exchange under the hood is nowhere near as simple as I have describe it here – you need long descriptors for data elements so that potential subscribers can know what it is they are subscribing to. You don’t, as a publisher, want to make your data available on other than a strict need-to-know basis. Different EHRs require different data formats.

You end up writing formatters to get data into the Data Exchanger and parsers to get the data out of the Data Exchanger but, guess what? There are only so many different EHRs so each new formatter/parser gets a little easier.

I think the healthcare business could significantly increase efficiency, increase throughput, decrease errors and improve compliance with internal and external rules and regulations, all of which would improve outcomes (i.e. individual patient outcomes and data collection for long term outcomes across different patient populations).

The only way this is going to happen is for buyers of EHRs to spec out what they want/need and accept nothing less.

Remember what you really need is a solution capable of addressing current as well as unanticipated future needs, not just current needs.

Filed under: Adaptive Case Management, Business Process Improvement, Business Process Management, Case Management, Data Interoperability, FIXING HEALTHCARE Tagged: #CostOfHealthcare