Problem: closed interfaces

Current electronic health-care systems are built as monoliths. They are constructed and sold as all-in-one solutions, largely because of the failure of care provider organizations to successfully manage collections of smaller, more specialized systems. This failure is caused by two factors:

  • The failure of the smaller vendors to cooperate and produce simple methods of supporting each other’s need for interconnection
  • The failure of IT departments at health-care institutions to actively seek out and support such best-of-breed solutions

Since the specifications are designed by the IT departments, and the negotiations with the vendors are also done by the IT department, the ultimate choice of system will be something that is primarily intended to keep the IT department budget within bounds. If that involves having less functionality for the ultimate users, that is not something the IT department is aware of. It also has no incentive to find out.

What appears to us as a problem of closed interfaces is then rooted in a deeper problem, namely that closed interfaces is exactly what the current IT departments wish for. First and foremost, they do not wish to have any open feature that enables the medical departments to ask for, and possibly get, the smaller best-of-breed systems they need for clinical care, since it would often involve committing more resources for IT configuration and support.

Ultimately, this is a problem of priorities. Currently, savings of IT department resources are clearly prioritized above the needs for better IT support on the floor. I find it very hard to believe that the savings achieved in the IT departments of our health-care institutions, if any, is anywhere near the cost to health-care in the form of delayed diagnoses, increased pain and suffering, and increased insurance costs. As long as the authorities let IT departments scrimp on medical IT support by specifying solutions that inhibits any attempts at improving health-care IT beyond what the all-in-one vendor deigns to produce, we will not be able to improve health-care by better IT use. This is basically a political problem.

Problem: confidentiality

Electronic health-care records must implement and respect confidentiality settings, such that certain care givers will not be able to view information that the patient may not want them to. There are many aspects to this problem, such as if the doctor should be able to break these confidentiality barriers in emergency situations, if the existence of hidden data should be indicated, and so on, but the only problem we will discuss in this section is to what entity the confidentiality is applied.

Currently, in Sweden at least, confidentiality is applied to entities such as care provider, document, referral, record notations, warnings, and prescriptions. Exactly which elements you can apply confidentiality attributes to, varies according to EHR system vendor.

The reason confidentiality has to be applied to all these peripheral data types is because the element you actually need to apply confidentiality to, the disease as such, does not exist in these systems. This explains both why there are so many complicated rules and elements and why it will always result in error.

Applying confidentiality causes different problems in each of these cases. A very short list of problems and dangers follows:

  • If applied to care provider, any non-confidential actions performed by that care provider will be hidden behind the confidentiality shroud as well. Also, any action taken by any other, non-included care provider for the confidential disease, will not be hidden and will divulge the existence of the condition. Something as simple as a general practitioner renewing a prescription for a drug used in schizophrenia, for example, will divulge the existence of the condition, regardless of the wishes of the patient.
  • If applied to prescriptions, the doctor will be unable to check for interactions and contraindications, resulting in outright danger to the patient. If the patient develops liver disease or renal failure or any other condition that would make a prescribed but confidential medication dangerous, the doctor will not know about that. The current EHR systems are also unable to warn for contraindications in these situations, since they have no concept of diseases or contraindications.
  • If applied to warnings, such as chronic infections, it puts medical staff at risk by not alerting them to the necessity of taking extra precautions while working with the patient
  • If applied to investigations, referrals, lab results, etc, then the same kind of dangers occur. Since the EHR is unaware of diseases as concepts, it is also totally unable to draw any conclusions on its own and issue warnings for possible medical errors due to the hiding of information.

The only medically responsible conclusion you can draw is that it is dangerous to apply any confidentiality of any kind to current medical health-care records. There is no way these systems can hide information in a way that makes the risk of serious error low enough to be acceptable. Sadly, the law mandates these confidentiality mechanisms, clearly prioritizing the patient’s right to confidentiality above medical safety. Personally, I don’t know if this is right or wrong, but the lawmaker is placed in the unenviable position of having to make such a choice by the unnecessarily poor design of current EHR systems.

Problem: too much text

This post is part of a series detailing the problems of current electronic healthcare records. To orient yourself, you can start at the index page on “presentation” on the iota wiki. You will find this and other pages on that wiki as well. The wiki pages will be continuously updated.

Current electronic health-care record systems contain huge amounts of textual data without any useful structure. The mass of text in itself becomes a big problem when there is no structure, standing in the way of the reader. Since there is no useful structure, the entire text must be read and internalized at every encounter where the patient is new to the doctor or if he hasn’t seen the patient recently, which in primary care is most encounters. If the amount of text could be reduced to the absolute essentials, then the reader might have a chance of getting through it, but we passed that point a while ago in most systems. That was a point of no return, as far as current EHR systems are concerned.

A number of initiatives coming from the outside of direct patient care result in an additional increase of the amount of non-essential or duplicated text. For example, a number of quality register initiatives and the “lifestyle” questionnaires add large amounts of text to the EHR, further obscuring the useful text we’re looking for.

Once a certain point is reached where the amount of text becomes too large to read before each encounter, several things happen, all of them bad:

  • The reader gives up on the EHR text and asks the patient instead. Since he needs to allow time for the patient to answer, he actually reads considerably less of the EHR than he did before. Most doctors I asked admitted to often reading just the one or two most recent entries before simply asking the patient for a short history.
  • Once the doctor does understand the essentials of the patient’s history, he usually summarizes the history and adds it to his own journal entry, so as not to lose it. This isn’t as useful as it may seem since it will scroll away beyond the “reading horizon” of two entries pretty soon. Once it has scrolled away beyond the “reading horizon” it isn’t useful anymore and only contributes to the enormous mass of unstructured text, reinforcing the vicious circle.
  • Not knowing what’s in a medical record is very stressful and tends to make doctors more defensive in writing new notes. These notes tend to be more elaborate than they need to be, once more further contributing to the mass of text.

In other words, as the EHR looks today, it is of critical importance to maintain the absolute minimum of text in the records and to avoid duplication and unrelated information as much as humanly possible. A disturbing number of government initiatives, however, result in exactly the opposite effect, interconnecting EHR systems over large geographic areas while at the same time sprinkling the EHR text mass with redundancies and irrelevancies to a degree that is outright dangerous.

Problem: no searcheability

This post is part of a series detailing the problems of current electronic healthcare records. To orient yourself, you can start at the index page on “presentation” on the iota wiki. You will find this and other pages on that wiki as well. The wiki pages will be continuously updated.

Since current electronic health care record systems have no knowledge of diseases as entities, we can’t drill down into the structure to locate necessary detail about the diagnosis or treatment of that disease. The information about diseases is spread out in the huge block of text that forms the EHR for a patient, so the only way to locate information in that is by searching on particular words or terms one could hope is related to the treatments one is looking for. Interestingly, not one of the EHR systems the author has seen has implemented even the most rudimentary search abilities such as “Find”. It’s hard to believe that these multimillion dollar systems don’t even have the features the lowly “Notepad” app has had since the inception of Windows in the 80’s, but that is the case. This leaves us with nothing else than eyeballing all the text manually, from start to finish. A clearly absurd state of affairs.

Search, even if implemented right, helps only in some edge cases. If you look for a reason why a certain medication was given or not given, it can help. If you look for treatments for a known disease, it can also help, but if you look for issues in the patient’s history that you don’t know about yet (the most important and most frequent search we do in an EHR in primary care), you’re out of luck even with a search function since you don’t know what you are searching for. A search can fill the function of an index, but not of a table of contents.

A summary of contents could be in the form of a “tag cloud”, but no EHR the author is aware of has even attempted to implement any such feature. Implementing a “tag cloud” of terms used in a medical record, if done right and with taste, could make the search problem somewhat more tractable by making it easier to navigate the old unstructured information from current EHR systems. It would not by any means replace “issues” as a structure, but would be helpful when linking legacy information to “issues” in a modern iotaMed based EHR.

In specialist care, the balance is somewhat different. Since searching for unrelated diseases is less frequent, a search on words or terms is relatively more important (one more often knows what one is looking for) and both a “Find” function and a “tag cloud” are even more sorely missed than in primary care. Even though both of these functions would be very useful, their usefulness arises from the fact that the lack of “issues” makes the EHR information such a mess to begin with. In the presence of “issues”, there would rarely be a reason to do a free search at all over an EHR, since information would be found in the place where it belongs.

This is not a reason to cast aside “Find” and “tag clouds” even for specialist care, since the legacy data in current EHR systems will be with us for a very long time still, before it all can be linked up with “issues” and brought into an “issue”-based structure. And even then, in that far future, “Find” and “tag clouds” will be essential tools, albeit not anymore the only tools to aid in the comprehension of the medical record.

Problem: no current status

The entries in our electronic health care records as they are currently built, only give us a chronological list of measurements and changes of the patient’s condition and investigations and treatments applied to him. A number of these steps naturally result in a change in the status of the patient, such as becoming less ill (if cured), having one leg less (after an amputation), having cardiac insufficiency (after a myocardial infarction) and so on. It would be only natural to always have a current picture of how the patient is and apply those changes to him, but that is not the case. There is no such current picture available in the medical record. To know how many legs the patient has, we have to assume he started out with two, then try to find any note in the EHR that indicates he lost one or more legs, to finally arrive at the current count. If we miss a record, we reach the wrong conclusion. You would be excused if you found it much more rational to check the actual patient and count his legs, in this situation.

When we paint our red house green, it is a green house from that point forward. However, if we reasoned according to medical records, it would still be a red house, albeit painted green on a certain date by a certain person who works in a certain department. If all I need to know is that the house is in fact green, that is a very circuitous description of a green house, but that is how we work. Actually, this example may seem contrived, but it’s over simplified. In real medical life, we would probably find records of the house being painted both blue, black, and all shades of pink, but unless we caught all these records and got them in the right order, it would be very difficult to be certain of the current color of that red house.

It’s painfully obvious that we absolutely must have a record of the current state of the patient in the EHR, but so far, I’ve not seen a single EHR system that even attempts to implement that. A curious state of affairs, indeed.

Problem: no archiving

Patients naturally progress through life by accumulating some diseases and becoming cured from other diseases. The accumulated diseases are what we call “chronic diseases”. Typical examples are diabetes, rheumatoid arthritis, vascular disease, hypertension, etc. Other, temporary, diseases are for example: bone fracture, most infections, myocardial infarctions (except for the underlying vascular disease), and an increasing number of cancers.

When you look at a patient’s medical records, you do want to be alerted to his chronic diseases, since most of them are relevant in the context of diagnosing new problems or treatment of a new or old problem. You also want to be able to see a list of resolved temporary diseases or afflictions, in particular when you’re diagnosing something new and don’t know what you’re looking for. But most of the time, the resolved diseases or afflictions from times gone by only clog up the records and stand in the way when you try to form an accurate picture of the patient’s history.

As an example, you may find a patient with a history of urinary infections, maybe once a year, where the annotations due to urinary infections can form half or more of the total volume of text in the medical record. None of that is interesting when the patient presents with chest pains (for example), but it severely diminishes our ability to find the annotations that are relevant to the chest pains in between all that urinary bladder gunk.

It would be wrong to erase the information about urinary infections, of course, since the chest pain may possibly have something to do with it (unlikely), and it’s important to maintain a count of how frequent these infections are, since if they recur often and during a long period, they may indicate a more severe problem that may need more thorough investigation, but these infections definitely do not warrant occupying prime screen real estate when I’m clearly looking for something else. I should be able to see just a one-liner mention of “urinary tract infection” for each such infection, and be able to read all about it only if I explicitly asked the system to show me.

This sounds like it ought to be a piece of cake to do, but in reality it’s close to impossible, since the system doesn’t have a clue that the annotations for all these urinary infections all belong together, simply because, you guessed it, the EHR has no concept of “disease”.

You can also find this page on the iotaMed wiki, here.

Problem: no contraindications

Electronic health care record systems are widely and frequently claimed to reduce injury and death due to prescription errors, since they are able to detect and warn for interactions between products. This claim is largely nonsense, because of the following:

  • Interactions between products are not the only dangerous effects we have from bad prescriptions
  • Interactions aren’t even among the most important dangers
  • Most doctors know of most important interactions and do not generally need these warnings
  • Most warnings we do get from these systems are hilarious or tragic, or plain boring, depending on your mood. They are rarely useful.

Most of these warning systems actually contribute to the danger instead of reducing it, simply because of their existence. It’s too easy for trusting young (or old) doctors to rely on the system to warn for interactions, creating a habit of optimistic prescribing. These users don’t realize how bad these systems generally are, so they adopt dangerous behavior and simply try out prescriptions just to see if they get warnings. If not, they prescribe.

The real problem, however, is contraindications. The presence of certain diseases makes it dangerous to administer certain therapies. A number of classes of medications should not be used if the patient is pregnant or has an enlarged prostate, certain cardiac arrythmias, or glaucoma of the eye, just to name a few examples. Some of these contraindications are deadly and most are hard to remember and easy to miss. But nobody talks about them, since our EHR systems, due to the lack of the concept of “disease” in some form, are totally unable to check for contraindications. Instead, the vendors praise the abilities of their interaction warnings, which in actual fact are near to nothing.

You can find this page on the iotaMed wiki. You can discuss it on Vard IT Forum, where you can find my blog posts published a day or more ahead of time.