SLOS – Life scenarios – Part I

The first post in this blog starts a series of articles about data structures from a story about a drop-down, a.k.a list, a.k.a item selector, a.k.a pick-list.

Our story will be about an ordinary list. Its’ simplicity is mirrored by the fact that values are well known, rarely change and managed by administrator. Users, normally, can’t make adjustments to the list themselves but they can address the system administrator. For example, if we present the drop list of Mendeleev’s periodic table, administrated by Dmitri Ivanovich, this would be an ordinary list, because if you think that there is an unneeded element, you will have to convince Mendeleev himself to delete it.

For our narration, it doesn’t matter how the list is visualised; as a select or group of radios/checkboxes or something else. For now we are talking about meaning not visualisation.

Let’s imagine that we created a system that has been used for a few years in the health system, serving patients in emergency ward. The system has a drop-down list “Diagnosis” which contains the values; “concussion”, “food poisoning”, “electric trauma”. For years, since the launch of our system, many patients have been treated, let’s say 10,000. The system has an administrative interface that allows new diagnoses to be added, existing ones to be changed and, of course, existing diagnoses can be deleted but only if no patient has been diagnosed with it yet. Otherwise all patients’ records with this diagnosis have to be found and changed to another diagnosis (we hope a correct one). These situations have never come up.

Everything was perfect, but until …

Real life situation 1
A special clinic was built next door and our medical director said: “They will take everyone with food poisoning, please make sure that diagnosis isn’t in the system so we don’t accidentally admit their patient.”

Real life situation 2
Because a new brain surgery section opened we have 3 different wards now where patients are admitted according to the severity of their injuries, so now the concussion diagnosis must be divided into simple, medium and complex.

“Ok” we said and thought.

It’s obvious that we cannot delete the “food poisoning” value because there are already many patients that have that diagnosis. Logically we thought about adding the active flag (is_active) into the table, which keeps the lists’ value. This solves “Real life situation 1″ by making “food poisoning” diagnose as inactive.

Figure 1

Creation of this flag also resolves the problem from “Real life situation 2″ – we will create three new detailed diagnosis’s – “simple concussion”, “medium concusssion”, “complex concussion” and deactivate unneeded old – “concussion”. With all our determination to find and question each patient, or their doctor, about the severity of brain injury, we understand that this task is impossible. As we stuck changing the diagnosis from old to new properly for many patients, we decided that deactivating the old diagnosis (and visualising it in a specific way) is applicable to this situation too. This will allow to admit new patients using a new list of diagnosis while still keeping old records perfectly linked to now obsolete old diagnosis.

Figure 2

The only thing left was to decide how interpret the meaning of this flag in various system interfaces.

The rules described below resolved all the problems. More problems could only be caused by a new real life situation, which has to be resolved but hasn’t been materialised yet.

So, we added the ability to activate and deactivate values. We decided to show inactive values with a different color. The active/inactive flag hasn’t got a history, so we don’t know when the value changed its’ status. A real need to know this hasn’t come up for years. In a different application or in a different domain this could be not true.

Figure 3

The interface that adds an admission excludes inactive values when showing the diagnoses. This way it will be impossible to create a new record with the diagnosis “food poisoning” or “concussion”.

Figure 4

The implementation of an editing interface for an admission record is interesting because it will contain inactive value if this is a current value for a record plus all active ones. So you can either keep existing inactive value or change it to an active one. If current value for a diagnosis is active – list will contain only active records (same as when we add a new record). By the other words changing an active diagnosis is only possible to another active one in this case.

Figure 5

Search and various reports interfaces contain “Diagnosis” list as one of the criteria. The drop-down list contains active and inactive values marked with different colors. The search or report results also colors inactive values differently, so the user understands that these are old, unusable diagnoses.

Figure 6

Searching engines will think that this page is about medicine. So let them! The main thing is that everyone understands how our drop-down a.k.a list, a.k.a item selector, a.k.a pick-list works.

Oh yeah, I nearly forgot to tell you how all of this is related to SLOS. We quickly got tired of saying; “Are we going to change this old list to the new one with active attribute?” We gave it a name – SLOS – which means Simple List On Steroids (not going to be a registered trademark).

Meanwhile life hasn’t stood still and that’s why in our next post everything would be good until… , as a result we ended up with SLOSW.


Print this post | Home

Comments are closed.