Kia ora! I’m looking for anyone interested in working together on an architecture and then proposal for funding ( or perhaps a spin-off start-up company ) for a way to make vendor-supplied EHR screens customizable by end-users. By “screens” I mean the whole user interface and sequences of screens and menus, etc.
The problem: current EHR screens from distant generic vendor products are often confusing, frustrating, non-local in language, in the wrong order, requiring the wrong things, etc. Clearly one-size-fits-all means one-size misfits everyone, which means there is substantial needless friction, delays, training obstacles, precious seconds or minutes lost, opportunity to lose the clinical mental picture while messing with technology, frustration, and actual burnout among staff we cannot afford to lose, which should be creatively helping not kicking the wall.
Probable cause: The world is not only not flat, it is fractally complex and diverse, and vendors give up trying to please everyone, or in some cases don’t even appear to realize that their mental model of workflow appears quite different from actual or desired local clinical workflow.
Secondary problem: Reported issues, such as “this field is too small for the new codes to fit in” which should take 8 seconds to fix in the Integrated Development Environment and screen-builder the developer uses can be reported endlessly and fruitlessly and never get fixed. Large issues such as “This patient situation doesn’t fit in the choices I"m provided so I’m going to put it all into this wrong field in free text” also never get addressed. Required fields I have no information on mean I put in anything I make up to get past them results in data quality contamination but that’s not my problem = I don’t use that field." result in much work downstream somewhere, out of sight.
Possible causes: Current changes to vendor-supplied systems are dearly expensive and require requests to go up through multiple layers of management, and at each stage the request list is filtered to prioritize top items and remove less-critical items. After four such filtering steps, the original “field is wrong size” request is long gone, despite the fact that 10,000 users hit that daily,because the importance was computed without multiplying it by the number of times that “small problem” occurs. Also, as computer staff know, “there is no such thing as a small change to a validated, warranted system” so any change requires skating on thin ice or doing a complete “regression test” validation which is labor intensive and expensive. Also the staff who wrote that screen are long gone and the position is currently empty.
Net total problem – implementation and evolutionary development is expensive, changes arrive in huge batches ( version 8), changes arrive long after the external world has changed so the system is not agile or adaptive, clinicians burn out, time is lost, money is wasted, patient care suffers. A few-second delay times number of occurrences means hundreds or thousands of clinician hours wasted, momentum lost, mental picture lost, from each such interface issue. EHR’s become more of a problem than a solution. Mistakes get made. Databases are contaminated with bad data.
Obstacles to solution: mindset ( conviction, belief ) that things have to be this way, that if users are allowed to touch anything anarchy and chaos will result, the “seal will be broken” so the “warranty is void”, intellectual property will be muddled, lawyers will become involved. Etc.
Examples in larger scale: Cerner’s current effort in the USA to replace 103 customized versions of Vista at Veterans Administrators Hospitals with a single one-size-fits-all standardized system in order to achieve interoperability because that is believed to be the only way to accomplish that, and resistant staff at the coal-face are considered lazy, trouble-makers, and obstacles to progress.
Smaller scale – mutilingual screens within a facility are not possible for nurses, doctors, and staff using their niche-specific familiar terminology and field order. Screens have too many or not enough fields. Implementation of new systems becomes needlessly complex.
Proposed Solution:
Just as programmers discovered decades ago that smart Integrated Development Environments, not text editors, were the key to “writing code”, and that separating the user interface code ( “css” files on webpages ) from the data-processing code made life 100x easier, it appears to me that we could go a step further and provide an intelligent, helpful Integrated Front-End Development Environment for end-users which would allow them to do things like move fields or change field sizes and prompting text while confirming and guaranteeing that the changes did not break the data-processing sections of the EHR system. Basically, in computing terms, a “wrapper” could be put around the vendor system screens that, in analog electronics terms, did an impedance match between the system and the user, so that the users “saw” one thing they could understand and work with while the computer central system “saw” the same thing the central system developers had imagined. We can have it both ways – standardized data processing and dynamic agile customized user front-ends which do not require any additional effort or time on the vendor’s development staff to handle, write, verify, test, or even understand the reason for.
So long as the IDE maintains the condition that the user interface is 100% plug-compatible with what the developers coded for, this should work, given external socio-technical issues can be worked out. The IDE can be increasingly AI-empowered with rule-based expert systems (not neural nets!) just as software engineers IDE’s are becoming, in that they not only do spell checking and grammar checking, they do concept checking, suggest better ways to implement what the user appears to be attempting to do, provide pull-down menu with acceptable verified options, etc.
What “socio-technical issues” are there between a single user with a bright idea and a modified legacy system incorporating that bright idea? That’s the nub of the issue I think. Can that friction be made close to zero?
A layered hierarchical system of trying the change out, assisting in better defining it via peers, realizing issues and revising the change yet again, when everyone at the niche agrees this is helpful expanding the offering to the next larger set of users, building reputations along the way to include a reputation-based rating system ( “oh Joe recommended this? Let’s check it out!” ) etc. The set of users optionally electing to incorporate the latest suggested change, reversibly, could grow until it hit an organic ecological limit, which could be all users of the vendor’s EHR system.
There are trade-offs between rapid release of small changes and batched release of large versions or vendor-upgrades, and pros and cons for each. The standard in commercial software in business has been steadily falling until now software production pipeline cycles may be two weeks or less, the time for an “agile sprint”. Each cycle change is small, but they accumulate and compound to substantial improvements in the fit of the software to the problems the users are facing today. There is again a trade-off of system stability ( and documentation and training and warranty ) versus system ability and evolution in an increasingly rapidly changing world. The point of such cycles is to solicit and harvest and incorporate what the users see into the product rapidly.
Summary – as EHR’s grow right now they become bureaucratic, brittle, inertial, and incapable of change. This is a misfit to a world which values diversity, and agility. A dynamic process of software development seems possible which is a win-win, providing the stability and control of centrally managed professional systems and the agility and dynamic joy of user-created interfaces.
I"m looking for people interested in exploring this idea further.
Wade