Thinking Clinically in Swift

Programming languages tend to be very much alike.   Some veer off into their own territory (FORTH being my favorite example), but most tend to follow the same general path.   The biggest change in languages over the last 30 years has been the move from imperative to object-oriented approaches. The divide between the two approaches is enough to cause headaches for those of us who felt completely at home with the former.   As odd as it may sound, PHP made this transition simpler for me.   PHP started as a purely imperative language and is now object-oriented. Objects were added to PHP gradually enough that it was possible to slowly adjust and wait for the needed “aha” moments that make OOP less foreign. From the standpoint of clinical software design, OOP has proven to be better in terms of allowing me to convert clinical concepts more directly into code.

For any programming language, there is an “idiomatic” way of coding a concept. That is, there is a way of doing things in C that would seem out of place or not work in Pascal. Swift and Java have their best ways to code a concept. Clinical software design requires converting clinical concepts into programming code. The more ways that a programming language provides for abstractions, the easier it becomes for the designer.

Swift provides the usual constructs for variables and looping, along with typical OOP features.   However, it also offers three things that clearly benefit clinical software designers: tuples, protocols, and extensions.

Tuples
Before explaining why I like Swift’s implementation of tuples, it will be helpful to explain the mathematical origin of tuples.

Sets are fundamental to mathematics. Sets are flexible and may contain anything from integers (Z) to animals typically found in zoo {zebra, lion, tiger, elephant…}.   At times, it is useful to relate members of one set to those of one or more additional sets (or to itself). Functions are one way of relating sets. Consider the function:

f (x) = x2

This function relates member of the set of real numbers to itself.   Assuming we restrict the function’s domain to integers and use this set A = { -7, -3, -1, 0, 4, 5} as the domain, substituting each of the members for x yields a set of ordered pairs.

{(-7, 49), (-3, 9), (-1, 1), (0, 0), (4, 16), (5, 25)}

These ordered pairs result from using the formula f (x) = x2   with set A. Another name for an ordered pair is “binary tuple.” Thus, tuples are a way of relating members of sets.   Functions are a special type of mathematical object called a relation. Relations, as the name implies relate one set to another.   Relations can be defined for multiple sets, giving rise to tuples with more than two values. Accordingly, relations between three sets would yield tuples with three values, four sets, four values, etc.   If we move away from sets limited to numbers, relations become compelling and immediately useful for clinical software.

Assume we have three sets–one containing clinicians, one with patients, and one with practice locations.

Clinicians = {Jones, Smith, Brown, Green, Walker}
Patients = {Warren, Jay, Marshall}
Locations = {Downtown, Sixth Ave, DuPont}

Formulas such as f(x)= x2 or y=3x+4 are used to build the ordered pairs (binary tuples) that comprise the relation. However, when the sets are not numbers, a means is still required to create tuples. In these cases, an algorithms fulfills this requirement.

Consider this scenario: Clinicians Jones and Smith practice Downtown. Green and Brown are located at Sixth Ave and Walker at DuPont. When a patient joins the practice, he/she is given the ability to choose a clinician or practice site.   A simple algorithm (usually applied by the staff person taking the call) assigns the patient.

Start – Ask the patient if they have a preferred clinician

  1. If Yes
    1. Add patient to the clinician’s panel
  2. If No
    1. Ask patient for a preferred location
      1. Review clinician panels at preferred location
      2. Add patient to a clinician with an open slot.

End

One way to represent that a patient has a primary care clinician is a ternary tuple.   Here are example assignments.

Relation Name: Clinician-Patient Assignment = Clinicians X Patients X Locations = (Clinician, Patient, Location)

{(Jones, Warren, Downtown), (Walker, Jay, DuPont)}

Until now, I have been talking about relations only in a mathematical sense, but they are easily used as powerful tools in clinical software. Don’t see it??? Consider this: Every component of a patient chart can be represented as a relation!

Giving a patient a medication can be represented as a relation between a doctor, patient, medication, date, and time—a five element tuple

Relation name: GiveMedication = (Jones, Jay, Lasix 20mg, 4/16/16, 10:10AM).

The same could be done with any patient data — problems, notes, labs, symptoms—anything. As was seen with the Clinician-Patient Assignment relation, these tuples are built using some type of algorithm. A Problem/Diagnosis relation is created when a clinician arrives at a diagnosis or problem (the algorithm is a mental task performed by the clinician) and records the outcome as a relation in the chart.   If the algorithm for the relation is computable, then the software can create the tuple.   For example, if a patient uses an application to schedule an appointment, the software applies the rules using algorithms to assign the patient an appointment slot. The outcome is a tuple (patient, clinician, date, time, location).

That is enough math for now, let’s get back to programming…

Programming languages adopted many mathematical constructs, functions being one of them.   Languages like Pascal made a distinction between Functions and Procedures as programming constructs.   Functions were units of code that returned a value; procedures did not.   If multiple results were required, one might have to call multiple functions to calculate them all or perhaps execute a function then use an array or other data structure to hold all the results.   Swift functions are different—they can return tuples! In practical terms, one could write a Swift function (not the same as a math function) that computes the Clinician-Patient Assignment relation, and then returns the complete tuple back for the rest of the program to use!   For someone who cut his teeth on Pascal and BASIC, this is a BIG deal.

Having deep support for tuples as data structures and the ability to return them from functions makes the chunks of data typical in clinical software easier to manipulate.

Tuples in Swift are flexible.   They can be created without using a function. For example, one can easily create a tuple to hold Chem7 data.

A Chem7 panel (Na+, K+, Cl-, HCO3-, BUN, Crt, Glu) tuple could be created in Swift with this declaration:

var chem7 = (140, 4.1, 100, 24, 16, 1.3, 83)

This is an unnamed tuple.   The better approach, especially if one wants to keep the concept of a Chem7 within the software, would be to use a named tuple.

var chem7: (Na:Double, K:Double, Cl:Double, HCO3:Double, BUN:Double, Crt:Double, Glu:Double)

Using a named tuple allows one to assign values using the name of each element. For example a value could be added for sodium as follows:

chem7.Na = 140

Below is code that creates a named tuple called chem7 and an unnamed tuple called patAG for the patient’s anion gap value with an outcome reading.  Next, the tuple is assigned values for all variables at once.

The anion gap function takes three parameters and returns a tuple with the AG along with the outcome reading (high, normal).

var patAG: (Double, String)
var chem7:(Na:Double, K:Double, Cl:Double, HCO3:Double, BUN:Double, Crt:Double, Glu:Double)

chem7 = (140, 3.9, 100, 23, 16, 1.2, 75)

func anionGap(Na:Double, Cl:Double, HCO3:Double)-> (Double, String)

{

   var AG: Double
   var reading: String = “Normal”

   AG = Na – (Cl + HCO3);

   if (AG) > 16 {

       reading = “high”;

   }

   return (AG, reading)

}

Here is the programming code that calls the anionGap function.

patAG = anionGap(chem7.Na, Cl: chem7.Cl, HCO3: chem7.HCO3)

Having lived through the days when functions could only return a single value and tuples were not available, I am loving Swift!

Creating computable versions of clinical concepts is essential for clinical software development. Swift offers useful data structures, which makes that task easier.   In the next post, I will look at protocols and extensions, powerful constructs that make it much easier to work with complex objects while avoiding the headaches of multiple inheritance.   See you then…

Facebooktwittergoogle_plusredditpinterestlinkedinmail

  1 comment for “Thinking Clinically in Swift

Leave a Reply

Your email address will not be published. Required fields are marked *