Month: November 2014

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.