Month: March 2010

The missing entities

There’s a reason why our medical records systems don’t work and that reason goes back quite a way. As I’ve mentioned before, it goes back to when IT people started implementing the paper records in computers, assuming the paper records contained a complete model of the medical management of the patient, which they didn’t. Automating that crippled model resultet in an automated crippled medical records system. All general medical records systems I’ve ever seen are based on a model somewhat like this:

As you can see, it’s a mess in general, but the problem I’m particularly focusing on is that the main entity, once the patient has been chosen, is the “Encounter”. Everything then dangles of either the encounter or the patient, making it totally impossible to find anything. If you search for information under the patient, you’ll find everything, but if you search under encounters, you’ll typically find nothing. For example, if I want to know if the patient ever said something in particular, or ever showed a particular clinical sign, I first have to know during which encounter that thing happened, if it ever happened. But if I knew that, I wouldn’t need to search for it, would I? Oh, by the way, did you see where they put the symptoms or diseases the patient has? No? Well, neither do I, because they didn’t. It’s not there. The ICD-10 codes don’t fill that function.

This entity relation diagram (ERD) is nuts. Not even a rank beginner would normally analyze a domain this poorly. But somehow it happened and keeps happening.

Let’s see how it should look:

Now we’re getting somewhere. A patient has issues, for which we, in turn, follow clinical guidelines, treat with medicines which in turn are refilled using prescriptions. Referrals are for issues, not for patients as in the first, bad, analysis. With this ERD as a basis, everything else falls into place. There are hundreds of entities missing in these two diagrams, but adding them to the correct, second, diagram is pretty easy and doesn’t break anything. Not so for the first ERD, the one we see in all current systems.

I actually made these two simplified diagrams for the iotaMed wiki. If you want to improve on them, please do that there. That’s what wikis are for.

iPad: the lowest common denominator

After watching Apple vs Predator, a short YouTube video, I had a blinding flash of the somewhat obvious and this is it: no other interface but the iPhone/iPad interface can seamlessly transfer to a virtual surface and gestures. Let’s expand on this.

If you’ve seen “Minority Report”, the movie, you must remember the interface Tom Cruise uses to access files. He pulls on gloves, then works the displays as if he touches a virtual surface in space. There are a number of projects doing gloves like this, such as the AcceleGlove by AnthroTronix.

It’s obvious, to me at least, that you can’t usefully move just any graphical interface to a virtual surface like in “Minority Report”. There are UI elements that work and others that don’t work. Obviously, you can’t use a mouse, there’s nowhere to let it rest, there’s just air. You can’t use a pen. The only thing you can use is your fingers. In other words, it’s a multi-touch interface, albeit virtually and in the middle of the air.

Could you imagine if you developed a useful virtual surface like this and you wanted to use the same user interface on a hard, real surface device. How would that look? Surprise, surprise, it would look exactly like the iPad. Not like Windows for Tablets, not like any other smartphone UI I’ve ever seen, but exactly like the iPhone and iPad UI.

I don’t think this is accidental. I think this is the fundamental reason that the iPhone and iPad have never had, and never will have, a pen or other pointing device. As long as they are entirely useable using only one or more fingers, the UI translates seamlessly to a virtual surface in the air.

There are signs one can do using a glove and a virtual surface that aren’t useable on a real surface with multi-touch. Example: making the “ok” sign using your thumb and index finger could work with a glove, but not with an iPad. On the other hand, it seems such signs are rarely used even in science fiction movies, and I think there’s a fundamental reason why not, simply because they are less suitable for an intuitive command interface. This leads to the rule that one should probably not introduce any visual signs in virtual surfaces that cannot be translated to gestures using a hardware device surface.

For medicine, all this is great news. This means that if you develop a medical records interface, or the interface to any other medical system, on an iPad, it will automatically be just right for a virtual interface, such as those we will need in operating theatres and bedside.

That makes the iPad user interface the lowest common denominator. If you develop for this UI, your medical app is future proof. MS Windows based medical apps, on the other hand, are living on borrowed time.

The interconnection con

Every project and initiative in healthcare IT can be classified into one of two types: interconnection and the rest.

Interconnection projects, as the term indicates, all have in common that they involve improving just the exchange of data and nothing else, by actually interconnecting two or more systems, or by creating some standard that is intended to make interconnection easier. Almost without exeption, these projects are described as “improving healthcare” and almost without exception, no effort is expended on actually describing what this improvement is or means. Practically none of these projects are preceded by a reasonable cost/benefit analysis, or any other analysis of any kind.

Then you have all other projects, those that do not primarily speak of interconnection or standard structures or terms intended to make interconnections easier. Those projects are usually, but not always, meant to solve a defined and real problem, often preceded by cost/benefit analyses, and a decent technical analysis and design.

I’d say more than 90% of all projects we see in healthcare, at least those with public funding, are of the first, “interconnect”, variety. They are, as I said, usually without any decent motivation or ground work except the desire to “interconnect” for its own sake, and usually fail according to objective criteria. But note that they are usually declared successful anyway, and since the requirements were never clear, it’s just as unclear how to deem them successes or failures, so they could just as well call them a success, whatever happens.

The remaining 10% or less may have interconnection as a component, but are founded on some other functional principle, are usually scientifically and technically sound, have a real hard time getting funding, but are often successful and useful. They don’t get much publicity, though.

So, my advice to you is: if you want to contribute something real to healthcare, avoid any project exclusively having to do with “interconnections”. If you’re more interested in committee work without much risk of ever having to prove that you actually accomplished anything useful, jump on any chance you get to do “interconnection” work.

And if you’re in a budget committee and take that responsibility seriously, jump on any “interconnection” proposals and demand a detailed clarification of what exactly will be the benefit of the project, and don’t settle for “more information must be good”. That’s malarkey. If you find any other motivation that actually makes sense, please let me know.

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.

Open development of the medical record

To summarize where the medical record is and where it is going, we could say the following. And if we can’t, please tell me why not.

The frontend of current medical records systems simply don’t work in practice. They’re hard to use and are unsuitable to help in ongoing work. The only thing they do is to retrieve old documentation, and they do even that one task very badly. Even if they did do it perfectly, retrieving old documentation is just one little part of what we need to be effective as clinicians. The support we need more, that is knowledge and planning support, is practically entirely absent.

The backends of current medical records are in just as bad a shape. We have a number of smaller and larger incompatible databases holding information and few workable standards to allow interchange of information. There is a constant and unresolvable conflict between building large, unified database systems and small independent systems. None of these extremes work and neither does a mix of them.

So what we can conclude is that current medical records generally collect the wrong kind of data the wrong way, and both storage and interchange is also wrong. So what is right about what we have? Hardly anything.

Why did this come about? Largely because the medical records have been built as if they were some kind of accounting system, but based on kidneys, white blood cells, and sneezing instead of money. But they shouldn’t be.

The reason for this, in turn, is that most of the effort to create the medical records and all the standards that go into them are done by lay people and non-practicing physicians. Clinicians have stayed out of this effort and haven’t the training or assurance they need to convert clinical workflows and thinking into information technology terms. And they haven’t received any help in getting there, either.

What we need to do is to create a movement of developers and clinicians that together build the next, working, generation of medical records. This movement needs to be open to all, use lightweight processes, and modern architectural principles. It needs to be as free of proprietary elements as possible, while allowing linking to those proprietary systems already on the market.

The following items come to mind when thinking about this as an open project:

  • iPad based UI
  • linking to legacy systems containing current medical records
  • a document system that is neither a large or a small database, but independent of such thinking
  • an issue-oriented architecture that uses legacy data to enrich the issues, so that older journal data is not lost but reused
  • reuse of whatever can be used from other open projects, both within IT in general and medical records
  • a minimal dependence on standards, but when the need arises, it should be on open standards

Note that the last point does not mean one should strive for non-standard interconnects, but that one should strive to eliminate need for standards when the interconnect can be usefully encapsulated in such a way that there is no need for agreements. Big difference. Just saying.

Confidentiality of the right thing

If we use “issues” as the top level item in the EHR, instead of the “encounter”, it comes naturally to attach confidentiality attributes to the issue instead of the department, doctor, or encounter. That’s a huge improvement. Let’s take an example to show why.

As things are in current systems, confidentiality walls or borders are located around certain services. The reasoning goes that if a patient doesn’t want his psychiatric problems to be known, then any records entered by the psychiatrist should be confidential and not accessible by other specialities. This is so screwed up. The psychiatrist is usually the one that handles embarrassing psychiatric problems, but this is not necessarily so. The psychiatrist may actually treat the patient for something entirely un-embarrassing like a headache or irregular menstruation or hives, and does that mean that the patient’s hives now are confidential? Of course not, but that’s not how the systems we have reason.

Let’s take another example. If I, as a GP, treat a patient for syphilis, there’s no confidentiality attached to it. If the same patient was treated for the same disease by a venereologist, then there is confidentiality. This is bloody nonsense, but this is how things generally work. In the system I’m working mostly, that is not a problem, since no confidentiality is implemented at all. (Don’t ask…)

It must be obvious to most that it is the “issue” that should have confidentiality attributes attached. If the patient doesn’t want the news about his syphilis to spread, the issue “syphilis” should be confidential, irrespective of which doctor or speciality that treats the patient. It’s up to the patient to decide if he wants any other particular specialist or department to know about this diagnosis.

The danger with all these confidentiality limits is that a disease that normally isn’t important to the treatment of another disease, may occasionally be extremely important, but remains hidden. If confidentiality is attached to issues, and issues to the patient, then there is the possibility of the system warning the user of hidden pathologies that are important, simply since this system actually knows what an issue is, and that other issues may include warnings about the simultaneous presence of these issues, including pharmacological interactions.

For instance, our syphilitic patient has a problem with suspected neuropathy, but the syphilis is hidden from the neurologist examining the patient. If the clinical guideline for “peripheral neuropathies” includes the differential diagnosis “syphilis”, the system is able to warn the physician that there are hidden issues that are related to the workup he is currently performing and that he should take steps to be allowed to unlock this information.

Having issues

In my last post I described the positioning of the SRR record and I also painted it as a form that can either be predetermined in the form of a clinical guideline record or a free form record to which the doctor can add steps, or a mixture of both. Since we don’t want to keep calling this thing an “SRR”, and we can’t call it a “symptom” or a “pathology” or a “disease” for reasons I’ll soon get to, I think we need to call it an “issue”.

It would have been natural to call it a “problem”, but there’s a problem with calling it a “problem”, namely that 50 years ago or so, Wade described the Problem Oriented Medical Record (POMR) which has a lot of the characteristics of what we here describe, but still differs on some crucial points. And since I don’t want to run in to prejudices connected with POMR and get remarks like “it’s old hat”, “we know about that”, “it never worked”, and more, I prefer to call it something else. And “issue” it is for now. Especially since I can’t think of anyone calling this an “issue” up to now.

Recapping, we have a list of “issues” under the entity “patient”. Each “issue” can be a symptom, a disease, a hypothesis, a plan, or even in some cases a therapeutic regimen. Let’s run through a couple of examples just to illustrate what it is, and what it is not.

“Diabetes type 2” is an issue. It has diagnostic criteria, recommended follow-up lab tests, regular checkups and referrals, recommended therapies, diagnostic codes, and contra-indications such as “careful with some diuretics”.

“Migraine” is an issue, and so is “tension headaches”. Interestingly, “headache” is also an issue with its own recommended diagnostic steps, but it also has a list of differential diagnoses, including both “migraine” and “tension headaches”. A “headache” is not a diagnosis but a symptom, but it needs to be a first class “issue” anyway, since that is the “issue” we’re working with until we can replace it with a more definite diagnosis.

So now we encountered the “replacing” of issues. This can happen in the “headache” case, among many others. The patient presents with headaches, and immediatly gets a “headache” issue assigned, which is prefilled with a differential diagnosis including among other things “migraine” and “tension headaches”. As the physician needs to exclude “migraine” first, the issue “migraine” is attached to the main issue “headaches” and you can work through the recommendations in “migraine”. If “migraine” is confirmed, it actually is lifted a level and replaces the main issue “headache” which is then removed from the list. If, on the other hand, “migraine” is excluded after some examination, the “migraine” subissue is removed and it is marked as “excluded” in the list of differential diagnoses in the “headache” issue. And so forth.

Don’t become nervous when you see all this insertion, moving, and deletion. That is how it looks to the user, but behind the scenes, everything is saved, version controlled, listed, and is being audited like there’s no tomorrow. Except we don’t want to actually see any of that unless we ask for it.

What’s this SRR thing, then?

In my last post, I arrived at the conclusion that the main element in the electronic healthcare record should be a list of problems and each of those problems should be an SRR, that is a document that is updated with  the most recent data pertaining to this problem, not a document that gets replaced and shoved out in a queue as in a TAS. (Back up a few posts to find the definition of these terms.)

Ok, fine, if you accept that, we now have a problem of defining the contents of this SRR, this problem document. It could very well start out as an empty document or a document with a few predefined sections such as “Tests”, “Clinical signs”, “Medications”. Under each of those sections, the doctor could then add in the tests and signs he plans on doing or checking and then later check them off or fill in results. That’s certainly one viable method.

But we’ll soon notice that most problems people show up with are pretty common and have established guidelines we can reuse. For diabetes, for instance, we very well know which tests we want to perform, which values constitute diagnostic values for the disease and which follow-up referrals and exams that need to be done. Even criteria for reporting the problem to different tracking databases are pretty clearcut. So it would only be natural to keep these guidelines in a common database so all doctors using the same system will follow up the same disease the same way. Additionally, if the guideline changes at some point in time, the diagnostic and treatment plans of patients already in the system will signal the change to the physician the next time the patient is seen.

But won’t it be prohibitively expensive to set up all these guidelines? Um, no, it’s already been done. All these guidelines exist at least on paper and in most places in the world as PDF documents. But in some places, such as Sweden, we even have them in an almost immediately useful form. Just check out the site viss.nu and there you have them. These guidelines can be used almost without change in an electronic healthcare record system, if checkboxes and input fields are added and a copy of the guideline is linked to the individual EHR patient file.

In conclusion, we actually do have the SRR we need for the medical records. It’s either an empty document the physician can add his planning to, or it is a predetermined guideline adapted for this system, but taken from one of the many excellent repositories of clinical guidelines that already exist. Which then also finally get to be used in real practice.