Designing an immunization module

All of last year, I spent working on an EHR redesign project. Unfortunately, the project ended before I had an opportunity to tackle all of the things we wanted to do. One of the things that I wanted to get a stab at and wasn't able to was immunization support. Immunizations are relatively complex to handle in an EHR. Especially if you want to do a little more than just record the immunizations given. If you want to support the doctor's decision process, you have to put some effort into it.

Each year, the CDC publishes guidelines for immunizations. These guidelines propose an immunization schedule, it describes when to administer the various kinds of vaccines, and it also offers options for catch-up vaccinations and how to deal with various exceptions and edge cases.

As you can probably guess, these guidelines are rather complex and they basically read like a computer algorithm.

Here's an example for Hepatitis B

Hepatitis B (HepB) vaccine. (Minimum age: birth)

Routine vaccination: At birth

  • Administer monovalent HepB vaccine to all newborns before hospital discharge.
  • For infants born to hepatitis B surface antigen (HBsAg)–positive mothers, administer HepB vaccine and 0.5 mL of hepatitis B immune globulin (HBIG) within 12 hours of birth. These infants should be tested for HBsAg and antibody to HBsAg (anti-HBs) 1 to 2 months after completion of the HepB series, at age 9 through 18 months (preferably at the next well-child visit).
  • If mother’s HBsAg status is unknown, within 12 hours of birth administer HepB vaccine to all infants regardless of birth weight. For infants weighing <2,000 grams, administer HBIG in addition to HepB within 12 hours of birth. Determine mother’s HBsAg status as soon as possible and, if she is HBsAg-positive, also administer HBIG for infants weighing ≥2,000 grams (no later than age 1 week).

Doses following the birth dose

  • The second dose should be administered at age 1 or 2 months. Monovalent HepB vaccine should be used for doses administered before age 6 weeks.
  • Infants who did not receive a birth dose should receive 3 doses of a HepB-containing vaccine on a schedule of 0, 1 to 2 months, and 6 months starting as soon as feasible. See Figure 2.
  • The minimum interval between dose 1 and dose 2 is 4 weeks and between dose 2 and 3 is 8 weeks. The final (third or fourth) dose in the HepB vaccine series should be administered no earlier than age 24 weeks, and at least 16 weeks after the first dose.
  • Administration of a total of 4 doses of HepB vaccine is recommended when a combination vaccine containing HepB is administered after the birth dose.

Catch-up vaccination:

  • Unvaccinated persons should complete a 3-dose series.
  • A 2-dose series (doses separated by at least 4 months) of adult formulation Recombivax HB is licensed for use in children aged 11 through 15 years.
  • For other catch-up issues, see Figure 2.

Over the years, the CDC has learned to organize this information in a way that doctors can understand well. They publish this information in two PDF documents that break down these guidelines in a nice vaccination schedule which looks like this: 0-18yrs-schedule example

They also publish a web version that is meant to be embedded into hospitals web sites and other content. This re-interpretation to the web degrades the quality of the information offered a little bit (breaks the schedule down, clumsier table layout) but it is still pretty good.

Now, bring that inside the EHR #

Immunization support in EHRs vary greatly from vendor to vendor. On the one end, some systems simply record received immunization as line-items in a table. Others implement complex rules-based systems that attempt to reproduce the various CDC recommendations (including exceptions and catch-up schedules) to give the practitioner precise due dates for the patient's immunization.

In theory, bringing this information inside an EHR situation should help simplify things, not make it more complicated. After all, you know more details about the patient (gender, age, past immunization history) and you know more about the practice (which vaccines the clinic has in stock or typically gives), and you actually know which specific vaccine was administered to the patient in the past. Given this fact, the EHR should be able to properly map-out the patient's immunization schedule and tell the doctor exactly when the vaccines need to be administered.

In practice, I feel that trying to out-think the doctor and pick-out very precise due-dates for immunizations if the wrong way to go about this problem. Here's why I think that:

Trust #

If the EHR has the required code to properly represent and codify all those CDC rules (that is a big if), it potentially can represent proper target dates for the patient's immunization. But that is only half the equation. The doctor has to trust that the guidelines represented in the software are accurate, that they are implemented correctly, and that they can trust the result to make clinical decision.

The issue with trust is that it is fragile. You're not allowed to make a mistake. The minute you do, you will erode the doctor's trust in your EHR's ability to help with the clinical decision. To complicate matters more, you are helping a highly trained expert user make clinical decisions. This is their field of expertise. You are however putting your software in a potential position of conflict. It is very possible that you have more up-to-date information than them. For example, the CDC guidelines might have been updated or the software might have detected an edge case that the doctor is not aware of. Technically, this is a good thing, you always want to have the most accurate information. But to your expert, you have to earn the right to challenge their expertise.

Transparency #

So you're damned if you're right, and damned if you're wrong. How do you mitigate this? As with all the complex processes, one of the best ways to help your user trust the process is to show them how the sausage is made. This sounds counter-intuitive but, if your immunization system triggers a special rule, make sure that this is clear to the user. Better yet, show the user the state that triggers the "standard" rule to fail and give them the control over which special case gets applied.

Most users, especially expert users, want to be in control. Giving your user the best information about the patient's immunization and asking them to make the final call about the course of vaccination to give will support their decision making process without taking control away from them. This will help them be more accepting with situations when you have more accurate (or up-to-date) information than they do about guidelines. It will also help when they know something about the patient that the system doesn't know or doesn't have the necessary code to handle.

Familiarity #

The CDC has been publishing those guidelines for a long time and the doctor is likely to be familiar with the method that the CDC is using to represent the guidelines. Here are some characteristics of the CDC guidelines information design:

  • Schedule is represented as a timeline based on the patient's age.
  • Target dates for the doses are represented as time windows not specific due dates
  • The colour scheme for target dose windows, catch-up schedules and special cases is well established
  • Vaccines are grouped by disease, then by course of treatment
  • Language/terminology is very specific

I'm not saying that it is impossible to improve on the CDC's information design but, since it is the source that is used by most of the doctors, the basic structure of the design should only be changed with great care if at all. Your new design might be better but it will not feel so familiar to your user.

That being said, in an EHR setting, you have more information to show the user than basic guidelines from the CDC:

  • You have a history of past vaccinations
  • You know the age of the patient
  • You know which specific series the patient is on at the moment
  • You know if the patient is on the regular or the catch-up schedule

The design work at this point is to find an efficient way to represent this extra information by adding to the CDC's design language without breaking it or conflicting with it. Keeping the CDC guidelines visually and conceptually consistent will help the user distinguish between what is the guideline and what is the patient's data.

Flexibility #

Guidelines are just that. Once you put them in practice, doctors will make judgement calls every day that might not directly comply with the guidelines. A trustworthy system would accept these variations well and find a way to represent them within the right context. A system that is overly smart and starts going crazy the minute you step outside the lines will erode the doctor's trust.

If the doctor decides to draw outside the lines, let them do it, it is ok to flag the various entries as being non-compliant with the guidelines but don't make the doctor feel like they are making a mistake. Resist the urge to trigger a symphony of alarms. Find a way to represent those non-compliant entries within the framework of the guidelines. If you can, try to add helpful information about how the guidelines propose to solve those edge cases. For example, you can attempt to represent the catchup schedule's data on the main guidelines. Or at the very least, find a way to point the user to the right, up-to-date documentation regarding this exception.

Build on the shoulders of giants #

Immunizations is a situation where there are clear best-practices published by an authority on the subject. Make sure that your design efforts don't go against the authority and expertise of that authority. Find places where you can help the doctor make a decision by adding details to this baseline information.

I didn't get to solve that problem in the context of my project. But I did spend a lot of time thinking about it since the project has ended. If I have a bit more time, I might actually take a stab at a concept of two for bringing this solution to life.