What’s Next?: No Oncology Trial Patient Left Behind

Now that we’re well on our way to full implementation, we’ve begun to think about the next steps we’re going to take.

Nearly every day I have the opportunity to listen to drug reps pitch their wares to our MDs, PAs and nurses. I have also had a chance to demo a bit of Ankhos to them. Most are completely wowed. They say “None of our other oncology clients has anything close to what you guys are doing. Your software will be a success.”

And then I ask what I ask nearly everyone at the office: “Great! Now what would you like this software to do for YOU?”

The drug reps will take a step back, collect their thoughts and say “We want  to never miss a potential trial patient again.”

So that’s our next goal. We will compile study criteria and patient data and make sure that we have  cancer staging,  treatment plans, diagnoses and everything else we need and constantly monitor our patients for potential trial fits.

I think Ankhos is poised to do this with excellent precision because it is “Regimen Aware”.  It can answer questions like “Is the first time this patient with stage II breast cancer has been on the regimen FLOX with a Creatinine level of x?”

Just like the past few months… I’m very excited and have so much to learn.

Scheduling:Suggestions instead of graphs

After the first workup, we decided that in order to solve the scheduling problem, we’re going to go with a time suggestion method rather than a more visual method.

I am a nut for interesting charts and graphs, which led us down an un-productive path. I still think some cool/constructive things can be done with graphs and scheduling, but those are for another time.

In order for us to keep it simple, we’re just going to compile existing appointments in a way that we can suggest, given the length of a treatment or exam, what time slots will be applicable, while still allowing the user to overbook (With ample warning, of course).

Screenshot: Scheduling problem

I just posted about the scheduling problem and promised a mock-up screenshot. Here it is:

The sliders on the left will affect the population histograms on the right.

Obviously numbers are off and scale is inaccurate… for now.

Solving the scheduling problem

One of the things I want Ankhos to accomplish is to simplify appointment scheduling. I’ve got some free time during a down-period of our launch so I’m writing this blog post as a brainstorm session for myself.

There are currently four fundamental goals that we are any scheduling system is trying to solve:

1. Be able to tell the patient when to arrive

2. Be able to spread patient load throughout or across workdays

3. Be able to show employees where time-critical workflow elements (busy times) are in their day to help department administrators plan their workday. For example, It would be nice for the chemo nurses to know what drugs they need for the day and how much.

4. Keep patient waiting time to a minimum.

These are probably no-brainers, but stating them explicitly helps the thought process.  In my math and computer science training, we studied complex algorithms and thought of ways to make them either faster, cheaper or less complex (Hint: You can only pick two). I want to try this approach to scheduling, also…

Making a Django POST mutable

For good reasons, the Django Request object’s POST attribute is immutable. No one wants anyone mucking around with important data there. But I had a case where I wanted to re-use some view code and it would involve using a POST object again, but with a few added parameters.

You can copy the POST data into a QueryDict, but I found that if you want to forward the actual request, you have to copy.copy() the request using the python standard copy library. Maybe this is obvious but it might save someone(like me) an hour of searching and trial/error.

def my_view(request)
    req_copy = copy.copy(request)
    req_copy.POST = request.POST.copy()
    req_copy.POST.update({'added_param':'my_value'})
    my_DRY_view(req_copy)

def my_DRY_view(req_copy)
        cool_stuff()

Down to the wire

It’s been really busy lately (thus, the lack of posts), but we’re finally starting 1.0 on Monday!  We’re going to be going side-by-side with the paper charts until we determine that all the bolts are screwed in tightly.

I’ve been working very closely with the staff at Carolina Oncology Specialists.  I’ve spent weeks, nay,  months watching, listening, asking questions.  And it has paid off. Ankhos is almost unrecognizable (even the name) from what we started with nearly 10 months ago. This is a good thing. I owe much to the staff who have helped with this effort, especially Dr. Orlowski and  lead R.N.  Joy Hester. Their enthusiasm and willingness to take my after-dinner calls has been indespensible to the progress of Ankhos.

The staff is armed with their cache of iPads and we’re ready to rock.  This  weekend will certainly be a busy one. There are many usability findings that need fixing in these next few days. They are little things like ‘this button should be bigger’, or ‘This link should be on this page’, but hopefully these are the types of bolts that need tightening.

Here’s looking forward to 1.1 and the innovative solutions we have for patient scheduling!

Starfleet EMR

I couldn’t resist posting this link about what the EMR/EHR market can learn from Star Trek:

http://blog.carecloud.com/2010/06/29/9-things-electronic-health-records-can-learn-from-star-trek/

Ankhos + iPad: The perfect marriage

I just recieved our development iPad from the apple store this afternoon. If there has ever been an incarnation of poetry it is in the synergy of the iPad and Ankhos.  There is really something special in the iPad and I am now a believer.

I was skeptical that Safari would be able to handle what Ankhos was up to, or that the resolution might be to small or… well, that’s all in the past now. I hope iPad forgives me.

This is going to be awesome.

Turnkey Virtualized PostgreSQL database

Since we’ve pretty much committed to using a virtualized server structure, the next thing to consider was the array of virtualized storage options we have.

We have decided to go with the Turnkey PostgreSQL virtual app. I  compared it to a normal install of PostgreSQL and the differences are negligible for an app of our scale.

The turnkey applicance uses a web-based interface to administer the database (only the essential parts of Ubuntu are installed), but the interface is nigh identical to the one that comes with PostgreSQL.

The two virtual machines (Ankhos and PostgreSQL) are up and running, playing merrily together.

so…

The show-stoppers are fixed…

We only have a few more server configs/optimizations to iron out…

We’re nearly ready for version 1.0!

Ankhos launching on iPads, but not Mac

It’s decided. The initial rollout of Ankhos will be on the iPad.  They are cheap, light and easy to use. However, we won’t be using the broken-down OS that comes with them. The current plan (in development) is to use them simply as a thin client to the already existing virtualized Windows environment. This will allow the doc’s machines to not only multi-task, but to use the portion of the  Windows-based EMR we are still using now

Doc’s are constantly moving in and out of exam rooms and nurses are constantly moving between patients administering chemo treatments.  Having the option of carrying their EMR system with them will surely be appreciated. (Ankhos will, of course, still run on a desktop workstation with any operating system.) iPads are…