Medication Domain Model

In conventional EHR systems, medications are usually just a list found under the patient. The problem here is that there is no direct relationship between the medication and the reason it is administered, simply because there is no concept that could function as “reason”. Lucky us, with iotaMed we do have “issues” so that’s what we’ll use.

A “prescription” is an order for a particular drug, for example “Aspirin, twice daily”, while a “refill” is the order to the pharmacy, for example “Aspirin, box of 100”. (Highly simplified.)

Since a “prescription” is for a particular issue, that is a particular symptom or disease, it should be a child of the issue in some way. Since it will typically appear in a clinical guideline under the section “Treatment”, it will appear as a line item.

Encapsulated lifetime

If you look carefully, you’ll see that each “prescription” can relate to more than one “issue worksheet”, which allows it to relate to more than one “issue”, since a different “issue worksheet” belongs to another “issue”. This is necessary since a prescription could serve a purpose for more than one disease. For instance, an ACE inhibitor is beneficial both in heart failure and to prevent diabetic kidney problems. And it is also used to treat hypertension.

Making “prescriptions” dependent on “issues” makes it much easier to stop medications when they’re no longer necessary. What we often see in practice today, with the crippled EHR systems we have, is that medications are continued indefinitely since it is often unclear exactly why it was started in the first place. Most systems allow a comment to be printed on the medication label describing the intent in a language the patient is meant to understand, but this is just a bad workaround. Often it is not filled in and if it is, it is sometimes incomplete. It is, after all, just a text field.

In iotaMed, however, it is abundantly clear exactly why a medication is prescribed and this allows the system to prompt for continuation or interruption of the prescription as the issue itself is activated or deactivated. Using an object term, we can say that the “lifetime of the prescription is encapsulated in the issue lifetime”, as it should be.

Contraindications

Current EHR systems usually issue warnings for interactions between prescribed products. This isn’t as great as it is made out to be. Generally, these systems stink. They throw up meaningless and frankly ridiculous warnings so often that nobody pays attention anymore. I can’t count the number of times our system has warned me that eardrops can cause unwanted pregnancies. I kid you not.

Also, interactions aren’t the main problem we have with medications. The main problem is contraindications, but since EHR systems can’t handle that, we’re supposed to believe that interactions are more important. Don’t fall for it, they’re not.

All medications have a list of contraindications, that is, conditions that if present makes their use dangerous. Some drugs for urinary problems, for instance, may not be given if the patient has glaucoma. A number of products should not be given if the patient has prostate problems, or heart problems, or asthma, or any number of other conditions. But if the EHR system has no idea what diseases and conditions the patient has, it can’t detect contraindications and there you are.

iotaMed, however, is built on the presence of issues, which are exactly those conditions we need. If we try to prescribe a medication for one condition that is contraindicated in the presence of another condition which the same patient has (as an issue), then the system can easily point out the conflict and stop you from doing something really stupid.

Domain analysis vs application design

Before I get into today’s topic, I’ll just have to point you to a review of the Apple iPad by a doctor. Main point: it fits in a regular white coat pocket. Very important.

In Sweden, we do have a problem, though, since doctors in general aren’t allowed old fashioned white coats, but go around dressed in the same pajamas everyone else has. The idea seems to be that doctors should be as indistinguishable from nurses and administrative staff as possible to keep the patients on their toes and make the doctors more amenable to accept lower salaries. So big pockets are out, here. But the iPad could change that (desperate hope). Wait… an idea is being born… an Apple branded white coat with an iPad pocket? An iCoat?

After this interruption, back to the regular programming. Last week I drew a diagram as part of the “domain analysis”, without explaining what that means. Sorry about that, I’ll explain it now. First, “domain analysis” is a process that produces, among other things, a “domain model”. I should actually have used the term “domain model” last week, it’s more correct.

A “domain model” describes the actual parts and interactions of the systems in reality, not in a software application. In my case, it describes the concepts that I as a doctor would use when seeing a patient. When you look at my diagram from last week, you’ll see “clinical guideline”, “issue”, “item”, and so on, which don’t really exist in reality, so it isn’t a pure domain model either. When drawing that diagram I did something impure, but very useful, and that is describing how to model the reality we want to automate using concepts that describe that reality to a software engineer, without necessarily being real terms used by doctors.

On the other hand, the actual computing system implementing a solution for this domain need not at all declare classes and objects that correspond to what I put in the diagram, so it’s not a software design diagram either. It may, for instance, be much more convenient to design “issue worksheet” as a group of classes, none of which directly corresponds to that “issue worksheet”.

In other words, my “domain model” is a bastard construct, neither a real “domain model” or a real “application design model”, but it is darn useful. It can be explained to domain workers (in our case, doctors) and they are able to see what I’m driving at, and it can be explained to software developers, so they can form a picture of what the actual workflow is that we need to support. This model allows understanding and discussion of the problem domain. It’s a bastard, but a good bastard.

If you subscribe to “domain-driven design”, you won’t like it, though, since you have to implement domain concepts as software design concepts, else it’s not “domain-driven design”. In this case, you’d be forced to implement classes for “issue”, “issue worksheet”, “privacy”, etc. In my opinion, that’s a naive and unnecessary constraint on software design that doesn’t give enough advantage in return to warrant the suboptimal design that results. So sue me.

3.3.1 with a twist

The by now famous paragraph 3.3.1 in the iPhone Developer Program License Agreement for iPhone OS 4.0 says that “Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited”. Which, of course, ruins the day for Adobe and Flash CS5. The idea was to have Flash scripts run on the iPhone on just such a compatibility layer.

The theories as to the reason why are, generally speaking: f*ck Adobe, preserve performance on the iPhone and iPad, and/or make multiprocessing efficient on these devices. With regard to that last, the theory goes that the OS figures out how the app works and hooks into the app and the app framework, but if there’s a compatibility layer in between, that becomes very difficult and inefficient. Actually, purely technically, without any fanboyisms, it does make sense to me.

In that case, and reading the 3.3.1 literally, nothing stops me, or Adobe, from implementing a translation from our own specific languages using a precompiler, as long as you end up compiling actual Objective-C code using XCode into the app. That’s what I would do, and I find it a better solution, anyway.

But the anti-Adobe conspiration theorists may claim Apple doesn’t want you to do this, either. I don’t know if they do, but let’s assume.

Now it gets interesting. There is no way that Apple can detect from the runtime code, or even the source code, that the code has been produced by a precompiler, if that precompiler does a decent job. If they want to stop that from happening, they’ll have to monitor the user’s machine for precompilers and editing tools, like World of Warcraft is monitoring for bots. What a fascinating circus that would be.

iotaMed domain analysis

As is simply too painfully obvious, current EHR systems aren’t fit for purpose. There is a serious defect in the domain analysis, so that fundamental concepts such as “disease” and “clinical guideline” are simply missing from the EHR domain analysis.

Let’s discuss the parts in this highly simplified diagram. The objects in green are unique to iotaMed and are missing in current EHR systems.

Patient

The patient object is the root of the tree. We’re assumed to already have created or chosen the patient here.

Issue

A patient has zero, or any number of “issues”. An “issue” is a disease, for instance “diabetes” or a symptom such as “headache” or “vertigo”.

Privacy

Access control is contained in the “privacy” object and the privacy object is connected to the issue. This is a major departure from how access control is normally done in EHR systems. Regular EHR systems tie the access control to the department or doctor that handles the patient, departing from the assumption that the information that the patient desires to protect is tied to the department or doctor that created or recorded the information. This is often the case, but not always, and when it is, it is by coincidence and not an essential attribute. For example: most of what a psychiatrist says belongs in the psychiatric domain so at first blush it seems only reasonable to limit access to records originating with the psychiatrist. But if the psychiatrist now treats the patient for a cold, which he can, then the cold becomes protected information, which is clearly absurd.

Another example is if a psychiatrist treats two different diseases, such as parkinsonism and depression, and the patient wishes for the depression to be protected but not parkinsonism. In that case, it becomes very difficult for the psychiatrist to keep the access control masks correct. We’re clearly using the wrong concepts and entities here.

Obviously, the privacy in real life is attached to the “issue”. If a patient wants to keep his depression a secret, it doesn’t matter which doctor is involved, it’s the depression itself that should be privacy protected. Hence the iotaMed design where the privacy record attaches to the issue.

Clinical Guideline

A “Clinical Guideline” is a template maintained by the medical authorities, which describes in outline form how a particular disease or symptom should be worked up and managed. It also contains differential diagnoses, treatments, new scientific discoveries, links to external documentation, reporting sheets, etc. Whenever an “Issue Worksheet” is created, one “Clinical Guideline” is attached and its contents copied into the “Issue Worksheet”. The relationship between the “Clinical Guideline” and the “Issue Worksheet” is maintained so that changes in the “Clinical Guideline” can be propagated to the already instantiated “Issue Worksheets” in use. An example would be if a new drug of choice has been selected for a particular disease, then the iotaMed system can alert the physician at next encounter that he should consider if that change should be done for the individual patient or not. This link-back allows effective distribution of new evidence-based knowledge into clinical practice without undue delay.

An issue that is not easily identifiable with a known condition, or if no clinical guideline exists that is suitable, the issue worksheet is connected to a dummy clinical guideline that does not contain any items.

Issue Worksheet

The “Issue Worksheet” is an interactive instance of the clinical guideline template. On this sheet, observations can be added or removed. Entire items can be added or deleted, such that any clinical guideline that is preloaded can be rearranged for the particular patient.

If the user creates an issue with an empty (dummy) clinical guideline, the issue worksheet starts out empty, so the user needs to add items to it before proceeding. This way, the user forms his ad hoc issue worksheet, which can later be replaced with a “real” issue worksheet based on a real clinical guideline as the narrowing down of the diagnosis proceeds.

Item

An issue worksheet contains a number of items. Each item is a clinical data point such as history, an allergy, a lab result, a blood pressure. The issue is a variable, not the value itself, which is an “observation”.

Observation

An observation is one data point in the clinical work. It is, for example, a blood pressure, a lab value, a description of the palpation of the abdomen, a description of the auscultation of heart sounds, or the patient subjective history for the encounter. For each item in an issue worksheet, there can be zero or any observations per encounter. In other words, for each encounter you can have none, one, or several blood pressures taken. Each observation allows free text comments as well.

Encounter

An encounter has a date and time of examination or conclusion. Each observation may belong to an encounter, but doesn’t have to. A lab result, for instance, is not encounter related. An observation never belongs to more than one encounter. Also, each encounter is related to one doctor, the responsible physician. In some cases, such as in training situations or operations, there may be multiple doctors.

You’ll find this page in the iota wiki as well: see here.

A Physician’s Bill of Rights

Jeff Atwood wrote “The Programmer’s Bill of Rights” a couple of years back, and it’s entirely applicable to physicians using electronic health care records, so I paraphrased it here for our domain. Here goes.

It’s unbelievable to me that a hospital or a healthcare organisation would pay a doctor more than $100,000 in salary, yet cripple him or her with terrible computing hardware and software. This makes no business or medical sense whatsoever. And yet I see it all the time. It’s shocking how many physicians aren’t provided with the essential things they need to succeed and to treat patients.

I propose we adopt a Physician’s Bill of Rights To Computing, protecting the rights of doctors by preventing their organisations from denying them the fundamentals they need to do their job.

  1. Every physician shall have two monitors
    With the low prices of LCDs and the ubiquity of dual-output video cards, you’d be crazy to limit your doctors to a single screen. The productivity benefits, and the improvement in digesting information, are obvious by now.
  2. Every physician shall have a fast PC
    Doctors are required to run a lot of software to get their jobs done: electronic medical records, pharmacy web interfaces, clinical guidelines, lab software, electronic dictation UI, and not least, Lotus Notes. Running all this software requires a fast PC with lots of memory. The faster a doctor’s PC is, the faster he can cycle through the EHR, prescription, messaging, and clinical guidelines. Time spent staring at a frozen desktop is wasted time.
  3. Every doctor shall have a comfortable chair
    Let’s face it. We make our lvings largely by sitting on our butts for 8 hours a day or more. Why not spend it in a comfortable, well-designed chair, instead of the broken down surplus junk most of us try to avoid falling out of. Sure, you hire doctors primarily for their giant brains and knowledge, but don’t forget their other assets.
  4. Every doctor shall have a fast network connection
    Good doctors use the network all the time. Whenever your doctor has to wait for servers and network responses, he’s losing concentration and time.
  5. Every doctor shall have software suitable to his work
    This is the most important of all these points and the most obvious. Without the right software, your doctors can’t do a good job and you’re wasting money, time, and the patient’s health this way.

These points aren’t extravagant demands. They’re fundamental to the quality of work life for a physician. If the organisation you work for isn’t getting this right, making it right is neither expensive nor difficult. Demand your rights as a physician! And remember: you can either change your organisation, or change your job.

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.