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.