It’s almost like Artificial Intelligence (AI).
Since over 50 years, functional AI has been “just around” the corner. It is still there. Check out the hype.
Weed, in late 1960s, described how computerization had already taken medicine too far in the wrong direction and sketched how to fix it in two articles in NEJM. It took him 40 years to get it right. Many others said, “Oh, that’s easy!” and then more or less failed. You are just a few steps away from a functional EMR that saves time, improves patient care, and reduces your overall workload.
One thing is certain: if we keep doing the same things as we are now, we will get the same results. As the PS14bn that was flushed down the drain of NPfIT. D’Oh.
There are no easy solutions.
Here are some thoughts. There are many more. The following 18 points (a), are actually too long. (b) is just the beginning. It may be difficult to understand bits the first time you read them. They are also largely heretical.
- Your design should be based on scientific clinical models and not pre-conceived computer science-based ones. Ontological models, which underpin most software design, are the most dangerously wrong models. This comment will elicit outrage from medical CS fraternity who cannot imagine a model that isn’t primarily ontological. I will be tied to a wall and beat with poorly made whips labeled “HL7v3”. The bottom line is that you can’t force a multi-dimensional vector space to become a hierarchical structure, even with multiple inheritance. Code bloat will result. You will see a decrease in the system’s fidelity, which can then get worse.
- Keep the code basic. Make it simple. Reduce it further. This task requires a lot of effort. Modern EHR suites contain millions of lines (or the equivalent) of code. This failure has predictable consequences.
- Insecurity. Complex code is difficult to secure, especially if it’s not your primary design.
- Inability to maintain code. No matter how complex the code is, it will be difficult to maintain and expand your code.
- Re-coding existing algorithms within the code is a way to extend the code. As the code base grows, this problem will only get worse.
- Inefficiency.
- Unreliability. To a very close approximation, more code means less reliable.
- Documentation can be a nightmare.
- No matter if you are using SQL or NoSQL, it is important to understand proper normalization. Modern EHRs are poorly normalized.
- When to denormalize. It is a black art. Modern EHRs are incorrectly denormalized.
- Do not view “Big Data” in isolation as a way to save yourself. Contrary to what IBM says. This truth will be up to the collective noses of nearly everyone. It harks back, however, to #1 above. The data always precedes the model. Your past experiences and the explicit and implicit models stored in your brain will influence the sensory data you receive when you enter a room. If you are not there to paint the room, the attractive person behind your desk will likely get more attention than the peeling paint. This is true for all data collection, big or small. What was the purpose of collecting these data? What was the process? How were they calibrated Are you able to trust them? Do you trust them? So on. What important data is missing or poorly measured? Big Data is often part of the problem. Don’t trust those who don’t see the problem.
- Make sure you have the right shared data dictionary. It’s not about avoiding unnecessary terms, but about making sure you include the necessary. (Consider, however, the bizarre and absurdity of SNOMED CT). Define terms clearly. Make sure that the clinicians are able to understand the terms. Also, ensure that you are not acting like a complete idiot in the eyes the clinician. Acceptance of change is possible with backwards compatibility. Clinical medicine is not difficult.
- The underlying terms can be mapped to terms that clinicians could use. This second tier is important and often overlooked. Be open to the differences of clinicians and don’t try too hard to apply the same rules to everyone. Be open to incorporating new ideas and variations. This is a difficult balance to achieve.
- It’s important to design systems that make it easy to do the right things and difficult to do them wrong. This is the most difficult part of creating an EMR. Understanding the clinical system is key.
- Make the user interface easy, as an extension to the previous point. Make it even simpler. Eliminate unnecessary clutter.
- You should invest a lot of money and effort to get the “human factors” component of the clinical interface working. This is not possible at the moment.
- Empower clinicians. EMRs today are extremely disempowering. Design interfaces that allow appropriately trained clinicians to modify the interface as needed. This is very difficult. This requires co-operation and leadership from the clinicians.
- Make sure you understand the analytics. Bayesian statistics are easy to grasp. They are consistent, unlike frequentist statistics. Learn to understand Receiver Operating Characteristic curves. You will learn a lot about statistical control, including control charts and the often overlooked run chart. Read Deming. Analysing of means is a cool way to visually visualise meaningful comparisons. Read Spiegelhalter on funnel plots. Regression lines, traffic lights and league tables are more dangerous than useful.
- Incorporate causality and reasons. Allow clinicians–encourage clinicians–to explain why a drug was given. What was the diagnosis? The reason a treatment was chosen. This cannot be reliably imputed post-hoc.
- Accommodate error. This is essential everywhere. This should be trivial to:
- Review past errors;
- Document and correct any errors that may occur.
- You can disagree, but in a structured manner so that both sides are represented. This is a difficult task.
- Accommodate uncertainty. Every diagnosis is uncertain, even if it’s “clinically definite”. As with Bayesian statistics, any diagnosis should include a likelihood estimate, even if it is vague.
- Concentrate on the important data. You’ll end up with garbage if you try to collect everything. Exhausted clinicians will just tick boxes. Be sure that the data you collect are clinically relevant.
- Do not delegate responsibility to the patient. It is easy to create a patient portal which pretends to empower, but in reality, it is confusing and dumps more information on patients than they are able to handle. Or requires understanding of something that isn’t there. Or too many options. Worse, they may upload uncalibrated garbage to their Fitbit or other device. This will make the clinician drown in useless crap. Recognize that too much measurement can be either harmful or unnecessary. This is a hard lesson to learn.
- Do not try to fix things. Instead, ask yourself “How can you help?”
Summarizing, believe that less is more. This is 180 degrees from the current course. It’s almost comical that we are on the wrong path.
Recognize that you will fail a lot of times, even if you do everything right. You can’t control many of the factors that lead to failure. You will be cut off by a litigious environment. It’s almost certain that you will be persuaded by those in authority to make mistakes or design bad things. These pressures will include mandatory data collection; arbitrary targets that obstruct your ability to measure quality; and clinicians and managers who are not familiar with basic measurement, ergonomics, and data interpretation.
We wish you all the best!