Tag: iotaMed

Lecture

I was invited to give a lecture to the International Masters Programme in Health Informatics at Karolinska Institute, and we recorded a video of the entire lecture, in total around 3.5 hours. The last part is about iotaMed, our open source project for a “new and improved” electronic health care record, which is knowledge support, medical record, and national registries all rolled into one.

The rest of the lecture is about a lot of different things I have opinions about, and as there is no lack of things I feel strongly about, it went almost an hour longer than it should have.

The full lecture consists of 12 chapters (“parts”), each 1-4 video segments (YouTube limits videos to max 15 minutes, and that makes for a lot of dividing of videos). You can find the lecture notes here. Oh, by the way, the site for the iotaMed project is here. The playlist with all 20 videos is on YouTube here.

Solution: modular structure

Forcing a large application into small independent parts that have to communicate with each other using minimal interfaces is always a good thing. Large monolithic applications go “fat and lazy” when there is no requirement to keep them split up. Also, the effort to expand and maintain the applications go through the roof. We know all that since ages, but both our IT purchasers and our vendors act as if it’s raining and it’s all business as usual. Of course, monolithic means all the business goes to one vendor, making him fat and happy, and very little requirement for thinking and effort by the purchasing organizations and the IT support. Now, if IT support considered their actual task, which is not work avoidance but the implementation and support of an effective IT organization enabling the health care staff to do a better job, things would look different.

The thing is, we do absolutely need modularity. The IT applications should mimic and support medicine as it is actually practiced, and not the other way around. Medical practice should not need to adapt itself to poorly conceived IT solutions. (You recognize this tendency by the constant cries for “more training”. It’s all just so much nonsense. My advice: ignore them.)

Different specialities have different needs for note taking and guidelines. On the other hand, needs for handling of pharmaceutical prescriptions differ according to type of department. Internal medicine on a ward or outpatient differs from internal medicine as practices on an intensive care unit. Different needs also arise for appointments according to the ownership of the practice, regardless of speciality. And so on.

These differences aren’t gratuitous; they are necessary and are an inherent part of how medicine works. The attempts to eliminate these differences by large, universal systems, and their large, universal ways of working, don’t work, since they force a suboptimal way of operating on the medical profession.

Now, the defenders of the great unified systems, let’s call them “unicorn followers”, argue that medicine should adapt itself to how IT works, else the IT systems will be too expensive and complex. To the unicorn followers, we should say: yes, the IT systems will be more expensive, but the savings in medical practice will outpace them by orders of magnitude. Don’t suboptimize and try to save just on IT, that is not your job! Your job is to enable medicine to save lives and money through better healthcare, not through junk IT software and equipment.

Oh, and while we’re at it: modular systems are actually cheaper to produce and work much better, but that is something most software engineering texts explain and provide the proofs for. And you out there who purchase, or sell, or build these systems, you have read those texts, haven’t you?

In short, even the unicorn followers, once they’ve picked up a bit of the computer science of the last half century and started to worry about what their real task in the medical context actually is or should be, will undoubtedly see the light and start to specify new systems as modular in every possible aspect. The unicorn, just like the “one medical records system” is a mythical beast and will never be seen in real life. Even if it wasn’t mythical, it would get stuck everywhere with that unwieldy horn and die of hunger. Good riddance.

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.

IotaMed business plan

The main obstacle to getting a better electronic health care record off the ground is the following. Hospitals (or large primary care organizations, for that matter) generally do not buy anything but complete systems with wall-to-wall coverage of functionality, which in turn leads to major upheavals at every system change and generally an almost total loss of all information that was kept in the legacy systems. Even if the legacy information is kept in some form, it is usually so hard to retrieve as to make it, for all practical purpose, gone.

The only way forward is to break this vicious circle. Hospital systems have grown too large to be built as monolithic products by single companies and in practice we see each generation of medical records system becoming much richer in diversity of functionality and much poorer in execution of the individual functions, including poor analysis and implementation, and with ever increasing bug counts and dangerous failures.

(A very fundamental problem is that all these systems implement a medical records model that was never intended for this use. Medical records were developed to serve as a memory aid to a family physician and was never structured to help in managing disease. I wrote a little “history” of medical records to illustrate what I mean by this and what went wrong when this one-physician system was scaled up.)

In order to get out of this situation, it’s absolutely necessary to create a market where smaller, interacting systems can be produced and marketed. A number of efforts are being done, mainly as European projects (e.g. OpenEHR), but as often happens, these projects are large and slow to result in actual products, but they do contain a number of interesting results that we do intend to reuse. The participation of customer organisations show that interest is high in this type of open development. From my informal contacts, it is clear that most hospitals have knowledgeable personnel eager to test and run smaller, open systems that would help them solve otherwise intractable problems, but the monolithic systems they have installed won’t let them do this on their own.

In other words, to enable us to develop smaller systems that are more suitable for their purpose than the huge compromise systems of today, we must develop an open market, a market built on public and open standards, and to a large degree on open software. The standards need to be of the “American variety”, that is selected from actually working implementations and not, as is more common in Europe, designed by committee.

The only realistic way of getting new systems into hospitals is not to replace existing systems, but to complement them. To be able to do that, the new systems must connect to existing systems and provide an added value. The iotaMed system we’re defining does just that.

Our business idea is to create a market for open systems and system additions to existing monolithic installations, show that it is possible and how it is to be done, and then sell into that new market both products and services to implement the iotaMed overlay.

It is clear that we need cooperation from other smaller actors to create and maintain a productive market of modules, and to do that we cannot keep neither the standards nor the products proprietary. If you want to go the proprietary route, you must be as large as the current players and we are not, and do not desire to be, since we would then produce the same inferior products and compete in a market in which we could not win.

The last number of years have shown that it is not necessary to have proprietary products and standards to achieve business success in the software arena. Companies such as Red Hat and MySQL have profited greatly from creating and maintaining an open market for their systems, giving away their products and standards for free (with “enterprise” exceptions), while having a very respectable income from support and consultancy.

We propose basically the same business idea as them, namely build a market of open systems and standards, then sell into that market support and advisory functions, plus a few signature products such as the iPad implementation of the user interface and communication systems.

As to the argument we often get that this change is only for the younger generation and that the older generation will resist it, I have this to say. First, younger doctors aren’t that hot, either, simply because they usually get their habits from their supervisors. It’s amazingly rare to find even 25 year olds daring to type in the medical records; they all dictate in Sweden. On the other hand and as far as I know, all doctors type for themselves in Norway, irrespective of age.

Secondly, all doctors are subject to change, if they want to or not. All doctors now must read the electronic healthcare record, which implies hugely increasing amounts of data to wade through and an uncomfortable way of making sense of it. Adding an organizing overlay such as iotaMed would provide doctors a huge relief from the drawbacks of automation and information overload gone wild, making it easier for them all, young and old alike.

Comparing iotaMed to other dissimilar initiatives such as the Microsoft and Google initiatives, and the Swedish NPÖ, we see they all have at least one problem in common and that is that all these systems are created with the idea that more information is good, but that is not necessarily so. Too much prose without structure is worse than useless and even the most important data drowns in the flood. None of these projects have shown that any priority is given to the actual structuring of information according to planning and modern clinical principles. They’re simply firehoses of information. It seems as if nobody has ever studied the psychological impact on the user of these systems. Why not, is a major mystery to me.

Another problem they do not adress is how to connect evidence based medicine to clinical practice. Coincidentally, these two problems are not only the major obstacles to efficient healthcare, but also the two problems iotaMed sets out to solve.

I’ve tried out my ideas with pen and paper on a few GPs in all age groups. There was no clear difference in how quickly the doctor saw the advantages and the point of it. Rather, the older doctors seemed quicker to pick it up, since they have a more acute feeling of losing contact with scientific advances and they also more acutely feel how much control they are losing over the patient history, which used to be much more tractable a number of years back. Younger doctors don’t yet see the downward slope as clearly.