Regimen Transforms

One of the aspects of Oncology that differentiates it from some other medical disciplines is the notion of a Regimen.

Most medical disciplines have recurring appointments that need to be tracked. One or two exceptions might be Emergency medicine and accute care clinics.  However, an oncology schedule is more complex and needs to be more flexible than simply scheduling future visits. Oncology schedules are actually made up of many sub-schedules, each of which determines when a particular drug is given or lab values are taken.  I think we have come up with an elegant solution for how to modify and create these schedules.

For example, one regimen might be specified as:

Drug 1: days 1,2,14,15
Drug 2: days 1,14,21
where the patient will come in for vitals/labs on days: 1,7,14,21

and this cycle is repeated x times given situations y and z. Most of the time these are published regimens and if they were guaranteed to be static, our job would be much easier.

But they are not.

All patients are different and not all regimens fit all patients. One of the main limitations of COS’s previous software is that modifying these regimens was all but impossible. And lord help you if you wanted to change the dose on one day because the patient isnt feeling well.

So how to create a schedule framework that allows many sub-schedules where each day can be ‘transformed’ (moved, dose changed, anti-nausea medicine added, etc.)? I use the notion of a schedule ‘transform’.  Much like how vector can be transformed and rotated with special matrices, I have implemented special data structures to act as a ‘lens’ for the real schedule.
The original regimen is never actually modified.

Just define a transform that says ‘move +1 days to day 3’ or ‘change dose +5mg on day 6-8’. This also allows for easy propogation of changes like: ‘change dose -5mg for all days 9 and greater’.

I’m sure people have done this sort of thing (it might even be the standard) but a lot of my research brought me to frameworks where future dates are stored in the database and changes were made to the actual dates. I think the solution we have implemented is much more elegant.

The tradeoff we will have to watch out for, though, is an increase in processing speed. But if schedules are only changing every two weeks, I think we can easily de-normalize them for fast rendering.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: