First of all, I have to stress that this post does not teach you how to write object orientated code. It’s to really give clinicians an idea of what is object orientated code, and how to think about the clinical situation in relation to this. As I’ve said before I am not a coding fanatic. Although I love coding I do not think that everyone should become a professional developer. However, getting a general feel for how programs are developed and run is always a good idea. On a personal note, considering all the free material and resources that are out there, you have to really question how interested someone is in tech if they haven’t at least tried out a high-level language. Tech is the new cool train that people are jumping on for a get rich quick result. Everyone’s different and a one-dimensional factor like if they’ve dabbled in coding shouldn’t completely define them, however, I advise that you keep your eyes open. There’s a lot of “ideas” guys out there.

So what is object orientated coding? It’s where you create objects, and then write the logic around them. This is different from procedural coding. I’m coding, to be honest, I’ve never really coded in a procedural format. I started with Python and my first piece of software was object orientated, all my teaching has been object-orientated and, and I’ve never felt the need to trying something new yet. Therefore I can list the differences just from reading myself but I’m not qualified to comment on which approach is best. I know that object orientated programming is used a lot in modern apps because you can reuse the code. This seems logical if your app has user profiles or is tracking the journey of patients.

The interesting point to take home is that object-orientated code shifts from complex code to complex design. This is because you have to think about your objects and what relationships they have with other objects. To get a better feel for what objects are let’s look at the following code:

Here we have the object person, we then set from standard characteristics, and then we have some functions which are denoted by def. The words in the brackets are the arguments that the function takes, and the __init__ function is what’s fired when a new object (in this case person) is created. The fine tech details are not important. What you need to know is that objects can be created, and functions can be used and reused to alter the object characteristics. Objects can also inherit other objects. Now, let’s think about this in a sense of solving a clinical problem.

All sorts of procedures happen to patients. These procedures are standardized. However, logging them is an issue, frankly, doctors and nurses are not logging the specifics of certain procedures, all they are saying is stuff like: “central line inserted” in the notes. This is giving the legal department in the hospital a hard time to defend clinicians’ actions. What objects would you develop and how would they relate?

Now, there’s no right or wrong way to do this. Approaches are always up for debate, but here’s a simple solution with some light reasoning why. There’s two objects here, patient and procedures. I would make the patient the parent object. A range of procedure objects can then be created. When a patient A is admitted, instance A of the object is created. When procedure B is done to patient A, an instance of procedure B is created, and it inherits the object, patient A. Why have I chosen this. There are two reasons. Initially, when clinicians or lawyers are looking over the notes of one patient, they want to see all the procedures that happened to the patient. Therefore it makes sense when calling from a database to have a patient object with a list of procedure instances attached to it as opposed to a procedure object with a load of patient instances attached. The second is the change of templates. Procedure templates change from time to time. Let’s say that the central line procedure template changes today. So you open up your laptop and you change the central line template. If the procedure object is the parent object, then patients who had the procedure in the past will have their instance altered, even though they had that procedure under old guidelines. However, if the parent object is the patient, only procedures from today onwards would have to updated templates.

There’s more, but hopefully, you understand that comprehending objects and their relationships are helpful when breaking down the situation and problem. Your clinical insight will not only help produce rapid development, but help produce robust design that will prevent problems when the platform scales.