Jon Patrick

A recent article published in EHR Intelligence by Sara Heath caught my eye for a good common sense approach to introducing an EHR/EMR into health organisations.

4 EHR Best Practices for Improving Clinical Workflows

The four principles espoused are:

• Develop a workflow plan
• Utilize the new EHR to improve care coordination
• Streamline clinical documentation improvement
• Know when to start an EHR optimization project

The detailed discussion of these principles is well thought out and presented but as a complete description, even at a high level, they are a necessary part of a successful implementation but not sufficient.

Crucially the final principle is elaborated with the statement “Simply because a practice as adopted and implemented an EHR does not mean the hospital will automatically function more effectively. Understanding how to improve is key” which of itself is true. However, the presentation of a dynamic approach to adapting the EHR requires a technology that enables those changes. The large vendor technologies in place in many organisations today do not provide dynamic adaptation as they are not based on an architectural principle of Immediate Adaptability.

So the 4 best practices should have a 5th element: Choose your technology carefully.

• If your needs are unambiguously defined, then choose a technology that exactly fits your requirements.
• If you have a dynamic workplace where staff are always trying to improve their work processes then the EHR needs to be able to move easily with them – that is only provided with a technology that has Immediate Adaptability.

The original article is at: https://ehrintelligence.com/news/4-ehr-best-practices-for-improving-clinical-workflows

We all have enough to read in this electronic age so why do we need to have yet a another blog to consume our time. I am often asked my opinion about topics of importance in health informatics so this is a place to find them all gathered together. I hope you enjoy them.

The clinical ERP systems have reached the limit of their deployability by their intrinsic nature. Our argument follows.

Enterprise Resource Planning (ERP) systems are built on the idea that:

• The work tasks can be decomposed into deterministic functions to be represented by software code of manageable size components;
• Code can then be written that performs or services that function effectively;
• A very large manufacturing or industrial system can be defined by the optimal combination of those components;
• The welding together of the code components provides an adequate and efficient representation of the total industrial process from start to finish;
• An individual client’s work processes will operate more efficiently IF they are shoehorned into the vendors model of industrial processes.

Some of the pitfalls of this approach are:

• That sometimes clients find the change in their processes so radical that it entirely disrupts their activities and they loose a lot of money;
• This technology is very expensive for the client presumably because the vendors are able to produce case studies that show substantial efficiencies;
• If the technology does not meet basic or critical needs then the client has to devise methods to get around the deficit – your workarounds.

The issues with the technology:

• Over time things happen to the vendor: their code base increases in size due to trying to cover more varieties of activities, and because of staff turnover, and the new staff are not on top of everything that exists in the code base and so they start re-inventing modules;
• A net effect is that older versions and more recent versions of the code do not operate seamlessly which leads to repair jobs between versions of code that are brittle as more recent versions are further developed, work becomes more and more engaged on keeping the repairs up to scratch;
• User managed components of the system start to conflict with vendor managed components creating a greater cost to maintenance and increased risk of system disasters and downtime;
• The vendor doesn’t want to “redevelop” its technology because it has the lost the bright people who got it going in the first place, and because they can’t see any other way to do the job, and they don’t care that the clients are hurting because they have them locked in, and they are well practiced at foiling critics.

Clinical ERP systems, as supplied by the large vendors, then fail to meet the users’ needs on a number of criteria:

• Clinical work is generally non-deterministic so the core model of the vendor is mismatched to the application;
• Some clinical workers can be less easily pushed and shoved into working the vendor’s way because:
  1. They are generally more autonomous;
  2. They have external motivations — patient safety and medical malpractice — controlling their behaviours to various degrees;
  3. They are often contractors and not employees so they are much more careful about the efficiency issues in the way the software works;
  4. They are on average a stronger/smarter resistance force than the industrial worker and see the clear water more readily and so can defend themselves more effectively (you might disagree with this point).

The Clinical ERP technology has reached the limit of its functionality and service value because:

• It worked satisfactorily for the need to better record the clinical work for billing where the task is to translate work units into codes and then ship the pertinent information out to external services and to compile the cash flow statistics;
• Clinical staff require a different technology for the clinical care but found themselves doing double data entry and asked to perform more efficiently;
• Clinical billing software vendors then offered to move the coding from the coders to the clinical staff to remove the coding process but made no account for:
  • The added time costs on people who cost more in the first place;
  • Had no understanding of the non-determinism of the work processes;
• Had to expand their code base extensively to cover all the new requirements;
• Did not have the software engineering skills to manage the expansion of their code base efficiently and coherently, especially as they increased the size of a highly mobile workforce that was not served with sufficient training and not sufficient old hands to keep the code train from veering from left to right and back again.

Why clinical ERP cannot reach any higher level of performance:

• The problem they are trying to service does not match their model of service. They are using a deterministic low-scalability homogeneous model for a non-deterministic very large scale heterogeneous problem;
• The problem is too large and diverse for a catalogue of tasks to be adequately constructed and its integrity maintained and their interactions made error proof by the principle of enumeration of all tasks/services;
• The health industry is not homogeneous and so each new site will demand new and/or different functionalities from the vendor hence their code base will continue to grow exasperating the problems defined above;

A solution to the problem: The architecture of software solutions has to be re-thought and taken in an entirely new direction.

I arrived late because my plane from Sydney was delayed due to fog at Melbourne.

This no doubt led to my confusion for half the day about what was trying to be achieved. I enjoyed the speakers but couldn’t get to the nub of why we were there until later in the day.

My understanding is that we would like to create at least an online community that provided content and entrées to the best people to bring to trial innovative technologies.

People contributed many descriptions about what the online community might engage in and that will come forth from Denis Tebbutt’s report of the meeting. My own response to all these conversations was retreat into my own analysis of where to start the whole process, and that was to construct a mini (micro?) taxonomy of the variables we had to deal with at a macro level. Hence, this is my analysis.

There are two primary variables:

1. The contexts that an innovation best fits, made up of {hospitals, community settings, patients}
2. The type of innovation {instruments, processes}

My notion is that depending on how an innovation matches these variables will effect what information and support the innovator will need.

Secondly, I thought at a macro level what is the current state of play for my own innovation location in these variables. So my work is with medical records and so my variable values are {hospital, processes}.

My next thoughts were about the innovations past and future in this space and the innovations my company has created.

The Past. 1st Age of Innovation for the past 40 years

We have achieved two things:

1. Nearly location independent access to records;
2. Nearly time independent access to records.

We have lost:

1. Freedom of process change and introduced rigidity of practice;
2. Readily available analytics.

The Future. 2nd Age of Innovation

1. Freedom to change clinical information systems at will and hence create a mechanism for continuous process improvement.
2. Analytics to support evidence based change.

Thanks to everyone for what they taught me.