Medical Technology is NOT Different
Medical professionals are their own worst enemies
Introduction
There is and always has been a push to do things a little bit differently in medicine. We at Sentia have been doing this for a long time and the story with clients is always the same “What we do is different.” Well, maybe it is and maybe it isn’t. Today we are going to see what is done differently, the incorrect reasons it is done differently and what can be done to correct the situation.
What we do is Different
No, no it isn’t. If I work for United Healthcare, I can’t just go into Cigna and start working. If I work for Christus, I can’t just walk into Baylor, Scott & White and start treating patients. You should be able to, but you can’t. We get a different way of doing things for every doer. How many times have your heard “We aren’t supposed to do it this way, but *I* do it like this” ? Here is an example of what I mean. At Sentia we look at the inputs and the outputs and automate as much as we can in between. We looked at the insurance industry and determined that an insurance claim needs a doctor, a patient, a procedure and a practice. The output of the claim is a check (or transfer of funds) to the practice for the procedure performed.
That is it.
So yes, what you do IS different, but it is still wrong. In the example above, with health insurance, the whole process can be automated. All the things you are doing that make your “workflow” different simply doens’t need to be done. At Sentia , as we stated, we automate things. As the insurance company, we provide the Electronic Medical Records (EMR) to the practice for free, pick up procedures documented and pay for them electronically in real time. That automates the entire process. You can read more about that on this site, but it works and it is built. In fact, you can contact us at sentiahealth.com for a demonstration.
Examples
Let’s take a look at some large and not so large examples of how the medical industry has completely gone off the rails with what they were trying to accomplish by arrogantly thinking that they are different and attempting to reinvent the wheel.
DICOM
DICOM means Digital Imaging and Communication in Medicine. So you medical people are telling me that JPEG or PNG or any of the other standard imaging protocols are inadequate to describe medical data?
As my grandfather would have said, “POPPYCOCK.”
The only difference between DICOM and JPEG is that the patient information is stored in the header of the image. This is an exceedingly bad idea. Not only is it an exceedingly bad idea, it makes the thing unreadable by any other means. .In software design we have a couple of tenets. One is separation of concerns. We do one thing in one place and that is it. Data in the data layer, transport in the transport layer, Display (and data validation) in the user Interface (UI) layer. The other tenet is we keep one kind of information in one and only one place. If the information is updated, we don’t have to update it everywhere, like in the header of a DICOM. What happens when the patient moves, gets a new phone number or job and insurance? No, all the demographic information should be kept in a set of tables in a database.
You don’t need, and should not have DICOM. Luckily, We at Sentia have a way to translate these proprietary images to a standard PNG and we can save them in a document database with their own metadata.
HL7/FHIR
These are protocols for transferring data between systems.
HL7
Health Level 7 (HL7) is a protocol for either network packets or file contents that define medical information. it comes in “channels” that define events and objects like patients, procedures and appointments. The problem is that in trying to define every possible thing that could happen or that needs to be defined, it becomes so complicated that quite literally (we say that a lot) nobody can use it. So since this is a legally mandated protocol, you have to be able to speak it (Epic can’t but more on that in their section) but since it is so complicated every iteration of it is different.
If you have decoded one HL7 message, you have decoded one HL7 message; they are all different. Everyone puts the information they are transferring in a different spot and usually, most of it in a “notes” field. It is utterly useless.
FHIR
FHIR or Fast Healthcare Interoperability Resources, is a healthcare data standard and application programming interface (API) used to represent and exchange electronic health records (EHRs). FHIR s HL7 with all its associated problems, just in an Application Programming Interface (API) format. Understanding APIs is an exercise left for the student.
What to do Instead
There are several formats that are acceptable for transferring information, like XML or preferably JSON. Both of these are self defining so it doesn’t matter what the format is. You might think that since they are self defining, we would have to code for them for each individual combination of sender and receiver, but you don’t. The receiver defines what is acceptable as a parameter so we know what we are getting. We lost the concept of “channels” and instead replace them with a hierarchical, object based data structure that defines relationships in the data. For example, we might have one patient with several diagnoses or procedures. JSON defines this relationship where HL7 and FHIR do not. JSON is the standard platform agnostic data transfer protocol in every other industry that isn’t medicine.
MUMPS
Massachusetts General Hospital Utility Multi-Programming System (MUMPS) is a programming language that was dreamed up at MIT in the mid to late 60s. While there have been any number of updates over the years to keep this programming language even semi viable, they have all failed. There is one application that is coded in MUMPS: Epic. Here is another case of the Medical industry erroneously thinking that they have to have their own way of doing things. MUMPS advocates will tell you that there is an internal database (there isn’t) that makes data retrieval simple and fast. It does not. First, databases have indexes and transaction logs and schemas and various things that make what they do extremely fast, robust, reproducible and able to recover from a fault. Databases have built in back up schemes, data partitioning schemes and an entire query language built specifically for them to make data retrieval fast and easy. MUMPS has none of these things. MUMPS has a key/value pair style data store where the programmer has complete control over what the data structure looks like. Sounds great until you have to fix the code or reuse the code for something else. This is how we end up with a different program for each specialty. You have a team of programmers doing whatever it is that they think needs to be done working on each of 135 specialties and you end up with 135 slightly different, unmaintainable programs one for each specialty.
Epic Systems
Epic’s Electronic Medical record is written in MUMPS. An Epic installation in a major hospital can cost $300,000,000+. there are several reasons for this.
- Ancient programming language used for ONE application
- Modified for each client
- At least 135 separate programs
- amazing amount of training required to run the thing
This is just not the way to run a railroad. In fact, their way of doing things is so complicated that they can’t Interface with other systems. Instead of the legally mandated HL7 or FHIR, they will provide you with a comma separated value (CSV) text file that you then have to write custom code to ingest into your system. The mind boggles at the incompetence.
Oracle/Cerner
Oracle Cerner has exactly the opposite problem. The people who paid to have Cerner written were just as uninformed as Judy Faulkner, the CEO of Epic Systems, but in the opposite direction: It is written in EVERYTHING. Nobody alive today has a handle on the what the whole thing does nor how it works.
The problem here as we previously mentioned is that you don’t have to have specialties. What we need is to look at the inputs and outputs and come up with a way to design a medical application that is suitable for every specialty.
What to do Instead
Part of the problem is that when Epic and Cerner were started there was no universal set of discrete values (think things you can pick out of a list) for an EMR to use to define all the things needed to document a patient encounter. Judy Faulkner, as a young programmer, made the one unpardonable programmatic sin in the early 70s: she jumped right into code. She didn’t design, she didn’t think about the future, she didn’t think about supportability, she trusted MUMPS and its designers and just willy nilly started making “codes’ that represented what she thought she needed. When one doctor saw another doctor typing his notes into a terminal, he wanted that system. Judy programmed a solution for his specialty. Fast forward to 2025, and she is still doing the same thing in the same way and has seemingly never given a thought to that one unpardonable sin in the early 70s
We at Sentia have some advantages that Judy doesn't have. We can look at historical mistakes and do things in a better way. Now in the intervening 50+ years Judy could have done the same thing, but either she doesn’t care or is too ignorant to understand what she did wrong and go correct it. We use a universal code set that is adequate for documenting any patient encounter. It is just that simple. The Universal Medical Language System (UMLS) is a database of SNOMED_CT, VSAC, RxNorm and various crosswalks to lesser code sets so we can translate seamlessly between this universal database and any other proprietary code set. The UMLS is also set up to be searchable with the same query regardless of what you are looking for. You can look for an RxNORM drug, with exactly the same code you would use to lookup SNOMED codes, ICD-10, CPT or even Epic codes and connectors just by changing the search parameter.
Conclusions
If you walked into the Ferrari dealership and they wanted to document your service experience with a separate engine documentation system, transmission documentation system, suspension documentation system, ad nauseum, you would run to the nearest Porsche dealership and trade in that idiotic Ferrari. Why, then, do we put up with all this proprietary idiocy in Medicine?
Doctors are uniquely unqualified to solve technology problems. As the fictional Dr. Charles Emerson Winchester infamously said “I do one thing, I do it very well and I move on.” That works great for a patient, but not for all the patients collectively. Here’s a little programmatic f’rinstance. Let suppose a doctor needs to add 2+2. He fires up his laptop and writes a new function called Add2plus2 and the return value of the function is 4. Three lines of code. Easy. Simple. Effective. Eventually he ends up with Epic and Cerner and 135 different specialties and $300,000,000 installations and a medical industry that is on the verge of collapse under its own ignorant weight. A programmer would solve the general addition problem by writing a function called SUM that takes an array or object of any number of individual numbers and loops through and adds them together. This solves the general addition problem.
We at Sentia are obsessed with solving the general problem. Our scheduling system was predicated around being flexible enough to not only put a patient, a doctor and a room together, but also Whitesnake at Reunion Arena in Dallas in 1987, complete with a stage, tickets, seats, staff and everything you need for that. We are monomaniacal about not having to revisit a completed, deployed application. This is why we can look at the less-than-optimal solutions being tendered in the medical and insurance industries and tell you, dear reader, not only what is wrong with it, but what to do Instead.
The health insurance automation system we described previously is real and complete in prototype form. Just automating health insurance should save half from the cost of health insurance. Couple that with our built in health and wellness system that incentivizes healthy living with insurance discounts for demonstrated good behavior and we can get the US down to the OECD average mortality, saving another 25% from the cost of health care. We judge healthy living with science: clinical measurements and lab results.
If you like what you read, join our newsletter at https://open.substack.com/pub/sentiahealth/p/medical-technology-is-not-different?r=473krc&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
You can also read this article on our site: https://sentiahealth.com/WebLog/Details/1089
Or you can read it on our parent’s site: https://sentiasystems.com/WebLog/Details/7042
Watch the video version of this article on YouTube https://youtu.be/XQYGVVbg4kI
