Posts Tagged ‘ankhos’

Please Touch the Demo

June 4, 2014

We have had a few interested clients recently and one thing I have realized is invaluable is that we let them touch our demo.


If you would like a live demo where you can  be in the driver’s seat, send us an email at or request one here.


Some companies seem to think this might hinder their attempts to keep their intellectual property private, but to us, non-touch demos are more of a speed bump.

I have been on many remote-desktop call demos, where a salesperson walks through a pre-written script of the product. I might ask “Can you click on that? I just want to see what it does” or “what happens if you right click there? No, not there, yes, a little higher… There!”

These screen-demos are frustrating and convey a small fraction of what can be illustrated by letting the user create their own orders, drag their own treatment schedules around, modify their own doses (and propagate the changes), maybe even send themselves a real fax!  The user can also get a feel for the responsiveness of the system and experience it as they would after they sign up.

Concerned about using Firefox on Ubuntu? Safari on Mac OS?  Let’s put those concerns to rest with a live demo where you are using Ankhos exactly as you would in your practice!  We can even break out your iPad!

There are benefits of this to us, as well. We get to see what uninitiated users might be confused about; what could be made more clear.  Perhaps the user is keeping in mind all of the things they can do in their current EMR system and can let us know what features could be added to satisfy their needs. It is much easier for a potential customer to wow themselves with a touchable demo than to hear us say how great Ankhos is.

So if you would like a live, clickable demo of Ankhos, please send us an email at and hopefully we can let you experience the ‘Wow’ for yourself.


ePrescribing has arrived

May 22, 2014

We are proud to present our users with our new ePrescribing system!  Partnered with MDToolbox, we were able to do a fast screen integration to easily log our providers and nurse assistants into the ePrescribing  program, and implement a behind-the-scenes SOAP interface to safely retrieve information about sent prescriptions.

Screen integration does not require a full-blown prescription network certification, but does include a basic audit (in this case, by Surescripts).

There are a lot of ePrescribing solutions out there, and a lot are built into larger vendors’ EMR functionality (e.g. Allscripts).  We chose MDToolbox because they support importing of medication list by using RxNorm concept ids, which is the dataset on which we have based our medication list and their cost structure is very flexible.

So far our users have had overwhelmingly positive responses. We are not yet cleared for ePrescribing of controlled substances (EPCS) but that will be implemented in the coming weeks.


Looking forward:

We consider Ankhos to be a mature clinical oncology platform and going forward, we are looking at ways to improve profitability, not just productivity.

Our current mission is to develop features in Ankhos to ensure that our medical coders have the information they need to bill properly and with lower risk of claims rejection. This will include implementing reminders for clinicians about what drugs are indicated for which diagnosis codes, and make sure that we have the correct information on file.

Some documentation requirements are as simple as “requires diagnosis code 123”, others are more complex: “Must have a diagnosis of xyz AND must have failed 2 prior treatments”. It is easy for a computer to tell us if a patient has a certain diagnosis on their problem list, it is harder to make more Human decisions like “… have failed x treatments, one of which is Oxaliplatin.”

Questions like “Did the patient’s disease progress on drug ABC or was it discontinued for another reason?” are not reliably answered by a computer. We will have to be very careful about how we implement this interface to not lose all of the physician and nurse productivity gains we have made so far, and at the same time increase our reimbursement rates with well-documented encounters.

The American healthcare payment system is constructed around this delicate balance of taking care of patients and getting paid. As developers we must be diligent about listening to our users and must take great care to not trade too many clicks for cash, lest we succumb to the dark side of the Mega-Click EMR.

An oncology pharmacist’s dream

September 5, 2013

Recently we have been putting some more polish on some features of Ankhos we have planned for a long time and we have a doozy.


Ankhos has been made to live and breathe oncology. For the uninitiated, much of modern cancer treatment involves many planned doses of chemotherapy over regular periods of time.  Doses are assumed to change  at any time given a patient’s response to the medicine. Medication doses may be altered mid-treatment or completely scrapped and a new treatment plan initiated.


These rapid and irregular changes in dosing can be problematic for a pharmacist trying to keep the right drugs in stock.  Chemotherapy drugs are very expensive and drugs that are not given are taken as a loss if they expire. For this reason, it is imperative that the pharmacist has an accurate picture of upcoming doses. Bulk pricing may also be available if the pharmacist knows well enough in advance of a big drug need.


Because Ankhos’ treatment planning is so comprehensive and agile, we are able to maintain a very accurate picture of what drugs we will need and when. So what is this new ‘doozy’ feature? Let the following screenshot say a few words:


This is a graph of all of the upcoming Oxaliplatin needs for the next two weeks from our test dataset. As you can see, this graph provides a clear picture of when we will need what amount of ‘Oxali’.  In this example, the pharmacist may be able to create two bulk orders, one for early September and one for the end of September, saving lots of money. This chart will also change dynamically, based on any dose reductions or increases, providing a progressively more accurate picture of drug needs in the future.

Future drug planning is not all that we can provide. The date ranges can be changed to include past months to evaluate the general trends of usage of a given drug.

This is the sort of feature that other general practice EMR systems cannot provide. Futher, there is information not shown here for HIPAA reasons. The user can drill-down into these aggregate statistics to see specific treatments per-patient.

The next feature we want to add is to incorporate drug prices and insurance allowables (payment prices from insurance companies) which would turn this into a future estimated profit graph!

We are constantly dealing with government regulations and core features like ePrescribing, but once in a while we are able to create these awesome features that are unique to Ankhos and really wow our users.


Fighting the Internet

July 1, 2013

Last week our main Internet connection went down. The office didn’t even notice because we are hosting Ankhos in the basement and not in “The cloud”.  It happens.

Despite this outage, we have been working on getting an architecture set up for hosting Ankhos from Amazon.  There are lots of things to consider:

Heroku or Amazon or Xyz?: We determined that for our usage, Amazon would be more cost effective, and we would have great compatibility with S3 (The Amazon storage engine) and even Amazon Glacier(The Amazon long-term storage engine). Other suggestions for hosting platforms are welcome!

Amazon RDS or our own replicated Postgres instances? RDS means switching to MySQL which feels gross, but may make our lives a whole lot easier. Our ultimate decision was to go with RDS. There are too many moving parts in the Postgres approach that we would waste time solving a problem that didn’t need to be solved.

Deployment: We still don’t have this one quite ironed out. We would like to have a deployment similar to Heroku where a Git Push updates the code on the servers, then manually cycle the instances behind a load balancer to get the code running. Or even have the ec2 instances detect changes and cycle themselves!


We have already learned so much with this project:  A cursory vocabulary of chemotherapy, Knowledge of the oncology workflow, Unix administration, HL7, Django, ‘Meaningful Use’,… tons of stuff. We have also learned squishier things like Project Management, Resource/Requirements gathering and creating positive client relationships.

Now we get to learn even more with cloud hosting for all of our future customers 🙂


PS: If you know of a good Amazon veteran, send them our way!

Partial patient calendar caching with Memcached

October 5, 2011

In Ankhos, we display a lot of information in different places, the most comprehensive of which is the patient’s calendar. I’ll talk about what we put on the calendar, what it looks like, and one of the tricks we have used to make it very fast.


Down to the wire

July 8, 2010

Shuttle launch

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!

Ankhos + iPad: The perfect marriage

June 14, 2010

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.

Winning the hearts and minds of the people

May 18, 2010

We spent the last few weeks  going through the initial process of using Ankhos in the office, as well as developing a specific rollout schedule.  We have been very sensitive about how receptive the employees are to our new software, as their acceptance can make or break the software.

To this end, I spent most of my time this week working one-on-one with the future users of the software, coaching them through their roles with the software.  Physician’s assistants would be working with the software in different ways than the nurses or lab techs, and I made sure everyone understood their proposed roles.  (I say proposed because software is organic, and these roles and use cases will likely change)

Working one-on-one with the user, asking questions and prompting criticizm is the best way to win the hearts and minds of the users and to make the software their own.  I am excited to abdicate this  “developer’s throne”  and give the power to the users. Ankhos 1.0 is coming soon…

Regimen creation success

February 23, 2010

Today was the first day in three of on-site user tests for Ankhos. I sat with Joy, the lead nurse at COS and went through the creation of a few oncology regimens. Granted, the previous experiences she has had with regimen entry in other EMR products has been a nightmare but, in her words, Ankhos is “Awesome!”

Oncology regimens can be as simple as prescribing one dose of one drug on one day. They can also morph into tentacled behemoths capable of devouring days of productivity and chomping away at the morale of those charged with their creation. Today we concluded that the simple interface Ankhos uses is able to tame these horriffic beasts and make their creation… dare I say… fun.

To make regimen entry simple, we tried to break it down into fundamentals. We took a step back and noticed a few fundamental principles

1. Regimens are cyclical — There should be some notion of periodicity built in to how we specify them.

2. Regimens are cohesive — They are not simply a collection of drugs, but are notions of intent for how to treat a patient.

3. Regimens are subject to real life events — They have to be flexible enough to accommodate a patient missing a treatment, or not having a ride home, or having bad reactions during treatment.

4. Regimens are temporally dependent — Modification of an ordered regimen must be allowed to ‘cascade’ to future doses and schedules.

5. Regimens can be hierarchical — Some are derived from others, and if we can design our interface around that, we can make modification and addition of regimens easier.

By taking these principles into account, we were able to design an interface that is both easy to use and powerful enough to express the most complex regimens.  More testing tomorrow…

If there is enough interest, I would be willing to create a video demonstration of our regimen creation process.

Security: Public primary keys bad?

February 12, 2010

I’d like to talk about a security aspect of web apps in general. I’ll try to keep the industry buzzwords to a minimum for the non-programmers.

Ankhos is a web application, an asynchronous one, at that. Asynchronous web applications use many web addresses to load only parts of themselves at once. This can make things seem faster and more responsive to the user.

In any asynchronous web application, web addresses are flying around left and right.  These addresses aren’t typically seen by the user, but simple tools can tell you what these addresses are.  In order to submit a comment or retrieve patient information, we have to hit the server and that means loading a webpage behind the scenes. Here are some fake examples: