Sunday, March 06, 2011

What to do about the state of the ED EHR's in NSW?

At my post yesterday "On an EMR Forensic Evaluation by Professor Jon Patrick from Down Under: More Thoughts", I've come down pretty hard on internal and external (i.e., human interface) sloppiness in mission critical IT systems.

In my view, the flaws that create randomly-occurring errors, combined with a mission hostile user experience highly and especially inappropriate in the hectic and unpredictable ED environment, turn these systems into slot machines. The jackpot, however, is not wealth. It's injury or death.

I've been asked, "So - what to do about the state of the ED EHR in NSW?"

Here are some simple initial suggestions:

A. For the time being: securing and implementing a paper backup (pen & paper) with scanning and document imaging retrieval system (integrated or standalone) as an 'EHR supplement", in order that really critical info can be steered in that direction.

Clinicians are already avoiding the EHR system and not entering or minimizing data, or using other "workarounds." Therefore, informationally and safety-wise, a document imaging/retrieval system for paper would probably be a net plus.

ED charts are not Tolstoy novel-length, as a matter of fact. There would not be many pages per patient, but even small morsels of key information collected easily and quickly, then retrieved easily, and presented clearly, cleanly and rapidly, as on a sheet or three of physical, then virtual parchment, can have enormous value.

B. Clinicians and responsible executives and officials should start demanding that the ED EHR vendor release its full conceptual and logical data models so that others can, competitively (including the original vendor if they wish), cleanse it and redo a user interface that meets the needs of NSW ED's. The latter should be determined collaboratively with the key stakeholders, and developed using agile, iterative and incremental methodologies, not the usual stale Management Information Systems approach. (I.e., the mercantile, manufacturing and management computing paradigms that are ill-fitting to healthcare informatics as further explained at my post here.)

That way moving data over to the "redone" new system would not be a nightmare. Or perhaps less of a nightmare than an entirely new extant system from another vendor (which would likely have similar flaws anyway and need similar rework).

The closed-system, locked-in-to-one-vendor paradigm that's apparently holding the ED's of an entire state of the fine country of Australia hostage must end. Let the best organization win.

As I also observed in the aforementioned post, the UK, having their own HIT issues (see my Aug. 2010 "Battle of Britain" post at this link), apparently learned something, as evidenced in:

Health Informatics — Application of clinical risk management to the manufacture of health software. UK National Health Service, DSCN14 (2009), formerly ISO/TS 29321:2008(E).


Health informatics — Guidance on the management of clinical risk relating to the deployment and use of health software. UK National Health Service, DSCN18 (2009), formerly ISO/TR 29322:2008(E).

Perhaps those in the U.S. and in VK-land (amateur-radio speak for Australia; I am KU3E here in the U.S.) can also heed these documents and their recommendations.

-- SS

Mar. 8, 2011 addendum:

Prof. Patrick has added a new section to his report, entitled "The Future Pathways for e-Health in NSW." It is available at this link (PDF).

It inoculates against most of the 'Ten Plagues' that bedevil health IT projects (such as the IT-clinical leadership inversion, magical thinking about the technology, and lack of accountability):

More on the Pathways at my post here.

The de facto "National Program for IT in the HHS" here in the United States needs a similar inoculation.



Anonymous said...

There needs to be markedly upgraded communications between the ER and the clinical ward and hospital care team. The interfaces repeatedly fail and medications are omitted.

Cognitive errors are facilitated by ER EHR systems. Additionally, care is slowed.

I cal;led a nurse yesterday and asked for the vital signs on my patient in the ER. She said they were ok. When asked what they were exactly, she sighed because she had to log on...and blithered, "the computers are slow today". That took 93 seconds (she was on the clock). The BP was 160/95 and pulse was 105...not exactly ok.

I get a lot of this crap interpretation and erroneous information from the nurses because they are disuaded from signing on due to the intrinsic slowness of the system.

InformaticsMD said...

Anonymous March 6, 2011 12:11:00 PM EST wrote:

I get a lot of this crap interpretation and erroneous information from the nurses because they are dissuaded from signing on due to the intrinsic slowness of the system.

This is a keen example of how business computing and clinical computing differ. Clinical environments are not calm, solitary back office settings where people have ample time to dick around with computers.

Further, "one second response time, maximum" was the mantra I learned/taught at Yale in the 1990's. Computers were a lot slower then...

-- SS