What Medical Software Companies are Doing Wrong
Identifying and fixing the problem with today’s healthcare and health insurance systems.
Today we are going to discuss what the Epics, Cerners and Athenas of the world are doing right and wrong and what could probably be done better.
Technology Mix
The Problem
Epic
Epic is used in 40% of hospitals in the United States and has a ‘chart’ for over 54% of the patients. While this seems impressive, Epic uses an ancient, 1960s, programming language called MUMPS that has an integrated key/value style ‘database.’ MUMPS is ONLY used for medical records and therefore is not well maintained nor kept up to date with current programming thinking and makes it extremely difficult to find programmers. The key/value pair is wholly unstructured and makes remembering what key the programmer stored the data in a challenge. The designers of MUMPS will tell you that the key/value pair makes data access fast, but the reality is that a more traditional, though newer, relational database management system (RDBMS) is far faster with batch write caching, indexing, table statistics and other magic to help make reading and writing data far faster. Further, the RDBMS maintains a transaction log that in the event of a crash can be played forward against a back up and ‘replay’ all the database changes since that backup.
Cerner et al.
Cerner is written in everything BUT MUMPS. Oracle bought Cerner in 2022 and is slowly rewriting it a piece at a time. This probably because it is written in hundreds of disparate programming languages and consequently is utterly unmaintainable. This is a trap that most software falls into, however, we can’t afford to fail with patient care. The US Department of Veterans Affairs (VA) spent $16,000,000,000 on an Oracle Cerner deployment and stated
“Oracle had inherited that deal as part of its Cerner acquisition – and with it the news that between the Cerner system go-live in October 2020 through June 2021 alone, it had ‘failed to deliver more than 11,000 orders for requested clinical services’ owing to alleged system design errors.”
“US Department of Veterans Affairs (VA) put a $16 billion Oracle Cerner deployment on ice, after an audit found that its failures had caused ‘multiple events of patient harm.’”
This is all after the VA decided to use MUMPS to build their own EMR, VistA, and spent $2,300,000,000 over 2015, 2016 and 2017.
Open Source
Security
Bluntly, you can’t use open-source software for financial and medical systems because it simply isn’t secure. We assume that Oracle’s rewrite is going to be done in Java since Oracle owns Java, but this is still an open-source solution with all the problems that open source has.
No Single Source of Accountability
When something breaks on your open-source solution who are you going to call? There is no support line, no email, no way to get in touch with the individual who caused your problem. I’m not sure what kind of testing the open-source stuff goes through, but I do know that there are as many different testing methods as there are pieces of software.
External Security
The problem is that open-source is community supported and maintained and anyone can sign up to be a part of the community and check in a back door to the code that might be pushed with the next release. This could let a bad actor either push a vulnerability to the code base or pay off a member of the community to do that for them.
Local Security
There aren’t many bad actors in the world, but here are LOTS of actors. There is nothing preventing one of your developers from going rogue, or being paid to insert malicious code into your solution. Just as bad is your developer putting code in the infrastructure that breaks the whole thing, if not now, then eventually.
The Solution
Know the technology you are using. Know it well, intimately even. We use Microsoft for all our development and only use less expensive alternatives for infrastructure things like monitoring and virtualization. Microsoft has a ‘free’ version of its premier software language, C#, that comes packaged with the free product VSCode. Microsoft’s premier RDBMS, SQL Server, also has a free tier, though you are limited to size and number of transactions, it is perfect for development.
Business and Doctors
The Problem
Business can’t be left with the task of writing software. There isn’t enough knowledge, generally, about how software works to leave this mission critical, life-depending kind of thing to the people who don’t write code every day. The business people generally don’t even know enough to hire someone to do it for them. Doctors certainly know what needs to be done, but the mindset is completely wrong for software development. Doctors see individual patients and solve one problem at a time. Developers should try to solve the general problem and then reuse that solution everywhere for similar problems.
Specialties
If we leave the software design to the business people, they will defer to the doctors. The doctors will state that “my specialty is different from anyone else’s.” The outcome of this thinking is that each specialty gets its own hand coded solution. There are more than 135 medical specialties. That means that the developers have to write 135 separate applications that all do the similar, but not the same things. This leads to the Cerner et al., madness and unsustainability.
Code Sets
Big insurance mandates that it only accepts Current Procedural Terminology (CPT) codes for processing and payment. The practice also has to supply the correct diagnosis codes that support the procedure performed or International Classification of Disease Version 10 (ICD10) or they won’t get paid. All other code sets are proprietary across currently offered EMRs. That means that Epic can’t talk to Cerner can’t talk to Athena and so on, because they don’t speak the same language.
Interoperability
Because the various EMR solutions have disparate, proprietary code sets, they can’t communicate. There are a couple of ways that are ‘standardized’ for this communication.
HL7
Health Level version 7 or HL7 is a text-based way to communicate various kinds of medical information. ‘Channels’ detail demographic, appointment, diagnosis, treatment and pretty much everything you want to know about a patient encounter. The HL7 messages can come in files or networking packets. The problem is that in an effort to cover every eventuality, the designers made it so complicated that most information is transferred in ‘notes’ sections. That is, you have to still write custom code for a message from every sender. If you’ve seen one HL7 message, you have seen one HL7 message and you certainly haven’t seen them all
FHIR
The Fast Healthcare Interoperability Resource (FHIR) is from the same Health Level 7 people, but is an Application Programming Interface (API) meaning that it isn’t text based. The sending machine returns a structured packet of information about a particular patient encounter. The problem with that is that now you have to have a developer write code to connect to the remote machine, THEN you have the same morass detailed above. If You’ve seen one’ you’ve seen one, and you still have to write code to translate whatever it is that they send you.
HL7 and FHIR are more examples of the “one patient one solution” thinking instead of solving the general problem and using that one solution for every similar challenge, medicine looks at one problem at a time and configures a new solution for each, making the total operation bulky, complicated and unsustainable.
The Solution
Clearly, we can’t depend on business people and doctors to come up with software that is designed and coded in a sustainable, maintainable way and plays well with others.
There are no Specialties
If you are a Ferrari mechanic, you may not know how to work on a Maserati. You are a specialist, nay, an artist at your craft. We are not talking about art however. We are talking about documentation. If your Ferrari needs a water pump, the service writer at the Ferrari dealership writes “leaks water and overheats.” These are symptoms. The Ferrari mechanic diagnoses that the car needs a water pump, and them performs the water pump procedure. This procedure is different from the procedure the Maserati artist performs, but the documentation is exactly the same. Substitute your healthcare for that process and you find amazing similarities, including that you do not need a specialized EMR for the practice. That also means that we should be able to design and build an EMR that only has one ‘specialty’ and one code set. That would make this EMR 135 times faster to code, sustainable and maintainable.
For example, you don’t have an engine documentation system and a transmission documentation system, and a differential documentation system, so why in the world are medical documentation systems written this way?
Code Sets
What we really need to build this universal EMR is a universal code set. That is where the smart people at CAP and NHS come in. They came up with the Systematic Nomenclature of Medical Terms and Clinical Terms (SNOMED_CT), a nomenclature suitable for documenting the entire patient encounter. This nomenclature includes well over 350,000 concepts. Even better, the National Institutes of Health (NIH) combined SNOMED_CT, RxNorm, the national drug database, and the Value Set Authority Center (VSAC) into the Unified Medical Language System (UMLS) that not only combines these three but translates them into a self-referencing and self-documenting schema where the same programmatic techniques can access any of a large number of medical nomenclatures. The UMLS has over 14 million concepts. That means we can translate back and forth from UMLS to legacy ICD and CPT codes, along with the major EMR vendor’s proprietary code sets.
Interoperability
Since we now have a universal set of codes suitable for doing the job we have to do, we can exchange these codes for all our interoperability needs. Gone are the days of custom code per sender and maintaining all that overhead, custom coded solutions and infrastructure. Everything just works together, seamlessly.
Conclusion
On a personal note, we had to deal with Epic recently. While HL7 and FHIR are both trainwrecks, they work. We asked them for HL7. Epic refused to send data in this standard format. Refusing to send data in this standard format is against the law. Instead, they required us to set up a legacy SFTP server to transfer comma separated value files. This hasn't been the standard for 30 years, since the 90s, and is so far out of date the Microsoft doesn't support it by default, and hasn't for decades. Additionally, every so often they send a file that does not follow the naming convention we agreed on. This morning was one of those times. Our system is fault tolerant, so processing continued but our monitoring solution alerted us to the fact that some files didn't process. This all indicates that Epic is using manual processes with zero quality control and consequently causing downstream chaos. These rocket surgeons must be stopped. This is the entire problem with healthcare. The powers that be get something that kind of works and they cling desperately to it instead of hiring some real experts to fix the whole overly complicated, fragile system. We here Sentia are going to fix it, and the solution is to put these legacy vendors and the dumb insurance companies out of business. There. Is. No. Other. Way. We are coming for you.
In this article we have shown what the old legacy medical software vendors are doing wrong, and how to do it right. We showed how to handle the technology, that there are no specialties, that UMLS should replace the ICD and CPT and all other codes, and therefore how to achieve true interoperability. We have achieved most of this already, and are working diligently to complete the balance. Contact us here or on our site and we will be happy to provide code samples to use the UMLS data.
If you liked what you read, please like and subscribe, click on the notification icon, subscribe to our newsletter, and follow us on all our social media and blog sites.
We have built a comprehensive health information system to keep the patient healthy and on the right track by making healthcare 50% or more less expensive. Implementing this system should be fairly simple and will completely revolutionize the way healthcare is paid for, saving countless lives. We have shown a way to use this system to make the best healthcare system in the world also the most efficacious and the most affordable.
Watch the video version of this article on our YouTube channel: