You Don’t Need Specialties in Medical Records
Why and how Medical Records companies are holding back medicine, killing patients, and how to fix the whole system
Introduction
We will demonstrate not only why the medical software companies are approaching their products the wrong way, but a better way to think about medical records.
The Problem
All of the currently produced Electronic Medical Records Systems (EMRs) are either written for one or two medical specialties, or are individually written for all 135+. This makes every specialty an island with its own documentation style and nomenclature, or with the large EMR providers, a conglomerate of all 135 that all require individual training courses, called modules, that span up to six weeks each. That means that if a doctor wanted to learn all the ‘modules’ in Epic it would take him or her 4-8 years longer to learn than the entirety of medical school and residency. At least they would get to spend those 15+ years in Vegas at a convention center being paid for by their employer. In addition to the training problem, we have either hundreds of individual applications built in nobody-knows-what, like Cerner, or built in an ancient (60+ year old) language like MUMPS, as Epic is. Thes number of applications is wholly unmaintainable, there is no code reuse, takes decades to write, costs hundreds of millions of dollars per hospital or practice, and frequently just fails. By ‘fails’ I mean completely quits working forcing the practice to rely on paper.
Comparisons
What other industry has 135+ specialties? While there probably aren’t many, there isn’t one that has 135 different pieces of software to handle them. It’s true that you don’t want a cardiothoracic surgeon managing your anesthesia, and your anesthesiologist doing a triple bypass. The way these two things are documented, however, is exactly the same.
Let us consider the common experience of taking your car into the shop. You pull up and the service writer asks you to describe your problem. He or she writes that down and passes it to the technician. Let’s say that your car is overheating. The tech gets the car, sees that the symptom is ‘car is overheating’ and does an examination and decides you need a water pump. He writes ‘remove and replace water pump’ in your case notes. Then he removes and replaces your water pump, tops off or replaces your coolant and off you go. From a documentation perspective, there is no difference between performing that procedure on a Ferrari or a Maserati. You could make an argument that a Volkswagen Beetle is a little different, but you simply wouldn’t document a water pump on one of those. The point is that you don’t see your mechanic shop having a water pump records system, or a differential records system or a coil spring records system.
Differences
Why is it that medicine does things one way and everyone else in the world does it another? We think the difference is mindset. Doctors do one thing, do it very well and move on. Engineers look at the class of a problem, reduce it to its component elements, and then solve the general problem. It is a little like the difference between mathematics and algebra. You can state that 2 + 2 = 4. This is an irrefutable statement. This is how medicine thinks. It works. An engineer might think ‘what if I had a 3 in there, or an apple or a giraffe?’ Then he might state a + b = c, solving all the variations of this general problem.
Commonalities
Here is where the metaphor breaks down. The dealership you take your car to doesn’t have a universal set of diagnoses or procedures. They use whatever they are given or buy. There isn’t a hue and cry to transfer data easily between mechanics or dealerships. There is a need to transfer data between hospitals and practices. Luckily people are far more similar to each other than a Ferrari 360 Modena is to Volkswagen Beetle, and some of those similar people at the National Institutes of Health have come up with a universal medical language system, called oddly enough, the Universal Medical Language System that assigns discreet, structured values and definitions to anything can be measured or done to a human body. Only with this universal diagnostic definition set can we achieve interoperability and easy transfer of medical records between systems.
The Solution
What we need, then, is to break down what we really need to know for each medical specialty, and what is similar between them. Then we come up with a solution ONLY for the things that are different between specialties.
What do we really need to know?
At its base a medical record needs to know a list of complaints, few measurements, some observations, and a plan on how to make the patient healthy. Just like the overheating car above, this should be fairly simple.
Universal Medical Language System (UMLS)
As stated above, the UMLS is a database (or should be, they send you a list and the importing to the DB is left as an exercise for the student) including SNOMED_CT (the Systematic NOmenclature of MEDical (and Clinical) Terms(suite of designated standards for use in U.S. Federal Government systems for the electronic exchange of clinical health information)), RxNorm (normalized names for clinical drugs and links its names to many of the drug vocabularies commonly used in pharmacy management and drug interaction software) and VSAC (Value Set Authority Center(a repository and authoring tool for standard lists of codes and terms from biomedical vocabularies)). These document, as mentioned, everything that can be done to a human, including drugs, and also include over 180 different medical nomenclatures, like Epic and Cerner, allowing the user to easily translate between UMLS and any other source of data or between any two disparate sources. The best part is that the documentation is all written in such a way that it is all self-referencing, meaning that if you figure out how to use one, you’ve figured out them all.
Flexible Measurement Framework
At its core a measurement is a key value pair (KVP). You have the name of the measurement, the magnitude and some units. For example: Key = Length, Value = 62, units = inches. While it is slightly more complicated than that, this description gives a good overview of the design. The Key could be picked from a list as could the units. These two lists, or lookups, should be not only data driven, but preloaded. By that, I mean that the measurement name and the units are both pulled out of the database so we don’t get typing mistakes, but can be edited, easily, with no additional coding required, for new and changing measurements
Automatic Measurements
Also necessary for a universal EMR is the ability to automatically ingest machine read data from a vitals monitor. There are several standard formats for this data transfer, HL7, being the most common.
Sometimes Specialty Specific Information is Necessary
There are things that have to be documented about a patient encounter that aren’t needed for each kind of encounter. We propose to solve this with a survey tool. This is a fully configurable dynamic tool that allows the user to create checklists, unstructured notes, unstructured measurements, like a blood pressure and heart rate when a patient moves from surgery to recovery, and things of that nature. The hospital or practice can configure their own questions and answer types, or we can suggest these to them, and then modify the suggestions as necessary. These things can be made mandatory, that is, must be answered, and hierarchical, such as a ‘Do you like ice cream?’ having a follow up question with a multiselect full of ice cream flavors labeled ‘What kind?’ This allows the practice to modify their own version of the application to do whatever it is that they think is necessary, and requires no additional code, deployment or installation. Even better, we already have this tool and the associated printable and savable reporting structure for it completed and ready to use.
Conclusion
We have proven that current EMRs are badly designed, require months or years of worthless training, sometimes just fail, and are monumentally, amazingly, idiotically expensive. We have further shown that all this work on current EMR software just doesn’t need to be done. It is born out of a ‘one problem one solution’ mindset prevalent in medicine that is just wrong. We have demonstrated a three-pronged approach to building this new system that includes UMLS, a Flexible Measurement Framework that accounts for automatic measurements, and a Survey Tool suitable for handling things that ARE specialty specific. This EMR does everything it needs to that is lightweight, fast, inexpensive and requires no training. We have this system in prototype version right now, and are working on the production version. Contact us for demonstration.
Watch the video version of this article on YouTube: