Language Can’t Be Used To Document Patient Care

That leaves out all the current EMRs and AI, so what now?

Introduction

Normally we discuss healthcare and health insurance in this space and today is no different.  Today we are going to discuss why language, any language, is inadequate to properly document a patient’s complaint, the practitioners’ observations, lab tests, diagnoses, treatments and ultimately outcomes.  We will discuss what the current batch of Electronic Medical Records systems (EMRs) do, and why it is wrong.  We will also, in our typical fashion, present a valid solution to the problem presented.  We think it is the only valid solution, and by the end of this article you will agree.

The Situation

There are lots of ‘opportunities’ with medical records today.  We will discuss all of these in The Slightly Longer Answer, but for now, we’ll focus on language.

1. Language is imprecise
2. You can’t relate symptoms to diagnoses or outcomes 
3. Language leads to ‘code sets’ in an attempt to codify things that can’t be described
4. Nobody reads your notes

The Logical Conclusion

If we continue with the Epic and Judy Faulkner’s misguided, language-based documentation nothing will ever get better.  

The Short Answer

Move to a discrete value based documentation system.  Discrete values are the ones that you can pick out of a drop down list box.  They are generally kept in a Relational Database Management System (RDBMS) for easy, fast search and retrieval.  This will allow us to relate (that’s the relational part) complaints to symptoms to observations to lab results to diagnoses to treatments to outcomes.  That simply can’t be done with language or any of the current batch of EMR systems.

The Slightly Longer Answer

Go back 75 years or 750 years of 7500 years and patient care was documented with writing.  You came in and the doc asked “where does it hurt?” and you said “right here” and the doc scribbled that down.  Flash forward to 2025 and the doc has the exact same clay tablet/parchment/papyrus/paper and pen, it is just behind the glass of a monitor.  Sure, you can do a search for a patient’s ‘chart’ but we could do that with filing cabinets and filing cabinets solve that problem far cheaper and more easily.  All the current EMRs took this concept and just ‘electronified’ it.  

The solution as alluded to above is to use discrete values from a database.  We use the Unified Medical Language System (UMLS).  This database has everything you need to document a patient encounter and can be searched in a way that is generic.  You tell it what you want and in what category and it spits it out, quickly.  This database is free of charge and provided by the National Institutes of Health (NIH).  

Benefits of Discrete Values

Gee, that’s great, but “what does it get me,” “how much does it cost,” and “I don’t believe you and don’t want to change.”  I appreciate your comments.

Rationalization of Data Entry

When I was writing the demonstration article for our EMR, I just wanted a generic SOAP (Subjective/Objective/Assessment/Plan) Note about appendicitis to demonstrate entering documentation into the system by selecting these discrete values instead of typing them.  The vast majority of these  template notes started with “Patient presents with screaming and crying” or the equivalent.  Gee that is great, but it has no meaning.  Yes, it hurts or you probably wouldn’t see the doctor.  What we should have seen was this:

Subjective: Patient presents with

Abdominal pain (finding)

          - Initial (qualifier value)

          - Hypogastric region structure (body structure)

          - Moving away (finding)

          - Right lower quadrant (qualifier value)

Loss of appetite (finding)

          - Abdominal pain (finding)

          - Nausea (finding)

Objective:

Finding of auscultation of abdomen (finding)

          - On examination - tenderness/pain (finding)

          - Right lower quadrant (qualifier value)

Palpation of abdomen (procedure)

          - On examination - tenderness/pain (finding)

          - Right lower quadrant (qualifier value)

          - McBurney's sign (finding)

          - Obturator sign (finding)

          - Rovsing's sign (finding)

Assessment:

Acute appendicitis (disorder) - Diagnosis Status: Active

Plan:

Appendectomy (procedure)

There is a lot to unpack here.  First, this was copied and pasted out of Sentia’s EMR.  You can see a demo of this particular record being entered in this demo article.  Second, all these are discrete values picked out of the UMLS.  Third, the categories are at the end of the concepts in parentheses.  Entering this data took less time than typing it or writing it by hand.  

Normalization of Concepts

All of the data we might use to document a patient encounter is kept in one table: MRCONSO. The categories mentioned above make it easy to find and choose the correct data and we only need one piece of code to do it.  This is not how things are normally done, but they work here.  The point is that now, for the first time we can have a universal EMR that doesn't have to be rewritten literally 135 times, once for each specialty.  It is all here.

Relation of Concepts

Since each of these concepts is already in the database, we simply relate them to a record.  These relationships are the main reason we use a database.  Let’s suppose we want to document sports preferences on paper.  We print out the firm and hand it to the filler-outer. The first question is “What is your favorite sport?”  The filler-outer writes in rutabaga.   You begin to see the problem.  Maybe s/he types in “..presents with screaming and crying.”  It is really the same thing.

That isn't the best part though.  The best part is that we have automatically created a relationship between what the patient says, what the practitioner observes, the results of lab tests, the diagnosis, the treatment and the results.  That means I could go type in a bunch of symptoms and get back a list of patients with those same symptoms, along with the diagnosis, the treatment and the outcome.  This alone revolutionizes medicine.

Standardization of ‘Codes’

Codes and coding are the natural outgrowth of using language.  Practices and hospitals have to hire teams of people to look at ‘charts’ all day and translate the problem and the solution into codes.  These codes are called ICD and CPT and are the idiocy co-opted by the insurance industry bizdiots to force practices to do their work for them.  

This is also the natural outgrowth of using language.

You don’t need and shouldn’t have codes.  Codes cause tribal knowledge.  The coder knows what a 43239 is and will not bother to look it up.  Until the definitions change. Or it gets dropped.

Epic/Cerner/Athena all have proprietary code sets that they and nobody else uses.  The original intention of the UMLS was to have a way to translate between these disparate, not-too-bright code sets so that we could have more portable records.  

But What does it Look Like?

Let’s just show you a video of us entering in the documentation for the abovementioned appendectomy

The SOAP Note

This is where the meat of the application lives and where we will demonstrate the power of the UMLS and the structured data approach without codes and coding, while being easily human readable. We will start with the clinical measurements and lab values filled in, as above, you don’t want to watch us type into a form. Notice as we go that the notes are very lean, and “just the facts.” there is no History of Present Illness as they would be in a classical SOAP Note, because that would have been captured in a previous encounter. There is no discussion of allergies as those would have been captured in another section of the application. Contrary to your training, these things, while germane, only serve to muddy the notes and ensure that the downstream practitioner will NOT read them.

Subjective

Here we see the user entering basically what the patient tells us. Notice how we can modify any concept, usually a finding, by clicking the ellipsis to the left of the modifier value. In this case we even denote that the pain seemingly moved from the hypogastric region to the lower right abdominal quadrant. Then we will add loss of appetite due to abdominal pain and nausea.

Objective

Here we will see what the clinician actually finds and can measure. Notice the extensive use of the modifier section.

Assessment

There isn’t much here, just the conclusion of the practitioner's findings, in this case the patient has appendicitis.

Plan

While this looks simple, there is a lot to unpack here. First, notice that the covered procedure is in green and has a number attached to it. This is the payment from us (or your self-insured employer) with no adjudication, no delays, no denials and no negotiation. This is a take it or leave it number. If you as a practitioner don’t want to take our payment, we will remove you as a recommendation. There are no networks, but we do recommend practitioners with whom we have done business before. Of note, this plan has one policy that belongs to this patient. The plan also only covers this one procedure. While this application has been in production and used at a regional hospital in North Carolina, this part is a prototype, so don’t put too much stock in the dollar value for the procedure performed. We will flesh out the plans as we get more information and as necessary. The lesson here is that this is all data driven and all configurable.

Patient Lists

If completely automating health insurance (more on that later) and eliminating medical coding, pre-authorization, insurance networks, adjudication, delays, denials, rate negotiation, sales/brokers/agents, the cost of a third party EMR, skyscrapers in every major city in the US, and the hundreds of thousands of employees that work at the legacy insurance companies and cutting out half the costs weren’t enough, here we demonstrate the research tool we mentioned earlier.  As you watch this, think of what we could do with a few billion patient encounters.

Here, we are going to combine several things, in this case hypertension as it pertains to diastolic blood pressure and pregnancy to filter out our patients who show symptoms of Gestational Hypertension. Any of these few dozen boxes can be combined and the UMLS data can be stacked up as we did in documenting our test subject’s appendicitis.

Conclusions

We have shown not only why using language to document patient care is wrong, we have given a better path forward.  Below are some other benefits of our approach

Automating Insurance

Since all the concepts are relatable, all we need to automate insurance is to relate the concepts to an insurance plan, add a price and then provide policies based on those plans to patients.  Then as the care is documented we pick up the procedures and pay for them in real time.  This automates the entire insurance industry and eliminates medical coding, pre-authorization, insurance networks, adjudication, delays, denials, rate negotiation, sales/brokers/agents, the cost of a third party EMR, skyscrapers in every major city in the US, and the hundreds of thousands of employees that work at the legacy insurance companies that you, as the insured, pay for.

Automating insurance also slashes about half the cost  

Automating Documentation

A practitioner can mark a record as a template.  The first instance of a new diagnosis is automatically a template, but that one isn’t always the best, so we gave them the ability to choose.  This template can then act as one click documentation for any diagnosis.  The SOAP note above can be duplicated into a new record with on click and documentation is complete.  There is no need to create and maintain new templates either, it is just a click.

We have shown why language is inadequate to document medicine, and a better path forward.  We have shown a way to completely automate the health insurance industry and save half from the cost.  We have shown a way to make documentation easier, faster and in some cases one click, while adding functionality like research to find diagnoses and efficacious treatments.

We already have the best doctors and the best equipment; we just need to implement the above detailed framework to give them all the tools necessary for success.

We have this system in prototype now, fully functioning.

Contact us here or on our site and we will be happy to provide a demonstration of the fully functional prototype.

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 with the ability to incentivize healthy living. This system includes the automation of the health insurance industry completely.  We have designed and are currently building the ERP style PM system.  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.

If you liked what you read contact us here, on our site, SentiaHealth.com, our parent company SentiaSystems.com, or send us an email to info@sentiasystems.com or info@sentiahealth.com