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.

Amortizing the office workflow: The Big Board

October 16, 2013

In a recent post, Dr. Edmond Billings discusses the inevitable decline of EMR vendors who ‘teach to the test’ of Meaningful Use at the expense of good software design.  Citing the results of multiple physician surveys, he concludes:

Clearly, the usability of EHRs has gotten worse with the implementation of Meaningful Use. Many have been coded to certification requirements, not designed to make achieving Meaningful Use a byproduct of improved workflow automation. Where basic EHR usage is not already established, bolted on functionality forces clinicians to take additional steps that further disrupt workflow.

Achieving the part where Meaningful Use is a “byproduct of improved workflow automation” requires the first step of actually improving the office workflow. Before we do that, we need to think hard about what the office workflow is.

1.  What work is being done?

Physician orders

Insurance Pre-certification

Treatment administration


2.  What is required to get work done?

Orders require lab results, notes and other clinical information.

Pre-certification requires orders and insurance information.

Treatment requires lab results and dosing information.

So…  How can we get more work done more quickly?

It seems like we need to increase the flow of information.

Moving from paper charts is a no-brainer in this regard. Suddenly everyone can access the same information without fighting over a paper chart, but as Dr. Billings and the studies he sites suggest, using an EMR system is not always sufficient to increase information throughput. If the software is poorly designed, or information is not easily accessible, it might just be faster to find the paper chart.

So, how do we increase information flow?

The Big Board

The Big Board

The Big Board:

The concept is not novel, but it is very powerful is done correctly. In Ankhos we have developed a feature where system-wide tasks are posted and filterable by department (Scheduling, Insurance, Physician, etc.)

Insurance – “John Doe needs chemo pre-cert”

Scheduling – “Call Jane Doe for a reschedule”

Scheduling – “The CT scan for Jim Beam is in, please schedule follow-up”

Physician – “Check lab results for Phyllis Doe”

Nurses – “Review treatment for Bill Smith”

Each one of these tasks links directly to the chart, with lab results, scans, past treatments all in one place.  Anyone can add a comment to any task and anyone can claim a task to work on.

So how does this increase productivity? Amortization and parallel processing.

Amortization:  For one person, the big board is daunting, but with an entire office working on little bits of a task at a time, the work becomes much more manageable.   Moments that might be idle can be spent chipping away at these tasks, decreasing the overall office-time spent working.  All first hand accounts from our users have proven this out so far.

Parallel Processing: The office receives nearly 300 lab results, radiology reports and referrals per day. Each must be reviewed and any acute issues must be dealt with immediately.  This is clearly too much for one person to complete and get home in time for dinner (and only certain employees are qualified to act on certain tasks). By showing these tasks on the ‘Big Board’, practicioners can spend spare cycles reviewing these labs and by the end of the day, the big board is blank.

The Big Board has worked far beyond my expectations. I have had users reach out to me to say how much easier and faster it is to get their work done. No more sticky notes. No separate todo-lists for each employee. Everyone chips in and they all go home earlier.

Before we went paperless, physicians would be sitting with a stack of charts at the end of the day, staying until 7:00 sometimes looking at lab results.

With the Big Board, everyone is home in time for dinner.

Now that we have achieved meaningful use in with Ankhos, we can begin achieving Meaningful Use.

Halamka: Rethinking Certification

October 2, 2013

Dr. Halamka of BIDMC has been a supporter of the ONC and their quest for meaningful use. He has been a “no whining, just solutions” voice in the industry, helping the ONC gain at least a little bit of traction to test their Meaningful Use wings.  I applaud him for his patience and stoicism,   but also now welcome his constructive criticisms of the meaningful use guidelines.   He calls for the ONC to make up it’s mind on which standards to use. Hear! hear!


We have recently re-visited our schedule for meeting meaningful use and put in a list of high/medium/low priorities for what tasks we have left. The tasks that are uniformly low on our priority list are functions such as “reporting to immunization health agencies”.  We run a cancer clinic. We MIGHT give out a flu shot or two, but we are not giving assays of immunizations to two year-olds.

Another feature is the displaying of growth charts. Why do we need to clutter our interface so that you can display a pediatric growth chart when our patients are reliably all over 20? The are just two examples of the ‘plumpness’ that still exists in the meaningful use guidelines that is nearly irrelevant to the success of medical specialty software.


And it is clear why such requirements are there. Our politicians want to show us how to make software by pointing to the horizon and shooting some money out of a cannon.  All of the software vendors start running in the same direction without asking “why?”, or saying “can you check the map again’?”  Instead, they fall in and throw enough money at a problem until all the tests pass. Success.


I can’t put it better than Dr. Halamka about how to foster a better healthcare software ecosystem:

Certifying organizations would not be prescriptive about user interfaces, workflow, or exhaustively test every variation of every option.   Instead, they would certify that an EHR can securely send a precisely formatted clinical summary and securely receive a compliant but less than perfect clinical summary.


How simple, succinct, successful.

Comments on ObamaCare

October 1, 2013


Good, level-headed post about the ACA.


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.


Don’t forget clinical staff when shadowing Healthcare Professionals

August 23, 2013

In a recent post on EMR and EHR, John Lynn points out an up-and-coming EMR (Elation EMR) company is out there shadowing doctors. We’ve said before that physician contact is the silver bullet to success, but it’s important not to forget the clinical staff: Physician Assistants, Nurses, Nurse Practitioners and even front office staff.   Not only should the MD experience be comprehensive and expedient, but the MD should not be slowed down by limitations imposed on support staff.

In our regional cancer treatment clinic, the whole clinic must run smoothly and in sync. Information is not only trickling down from the MD, but that MD is also basing his decisions on information from other staff:

  • Is that expensive chemo pre-certified by their insurance?
  • Did the nurses notice that there was excessive nausea that should delay a treatment?
  • Have the admin staff filed the correct HIPAA agreement so the MD can talk to the patient’s son on the phone?
  • Lab staff – Has the in-house lab had time to get the BCR/ABL results back?

In order for all of these departments to function smoothly, the entire EMR system must be fast for everyone. When we have a new feature in development, it is part of our design process to put the feature on a test server, then go and sit next to the user and duplicate her work. That’s right, you bring a laptop into the exam room and duplicate the work the MD is doing (or lab tech or nurse, what-have-you). If you can’t do the work faster and better than she can, you sit back in your chair and keep developing until you can.  This is an exotic luxury that we have, as we are developing our software in-house… as in, our dev boxes are in the building.

A prime example of this philosophy was when we put our document scanning process in place. We had worked for months (between crisis-features like ICD-10) on the scanning interface, on the specifics of how to split pages, put pages together, rotate, etc.  I personally spent about a month going back and forth to medical records, spending an afternoon just scanning – eating my own dogfood.

By the time I was done, scanning documents was almost a little… fun.  And once we put scanning into production, the users really loved it.

Having my butt in the seat showed to the users that I am invested in the product and am taking considerable effort to make their lives easier, not harder. This disarms the user against reflexive negative emotions and opens the door to constructive criticism and user buy-in.

Being ‘in-building’ provides its advantages of being able to shadow anyone at any time, but it also provides the advantage of immediate feedback. Something broken? We hear about it immediately, perhaps before it affects most users.  We get to see the emotions that our software brings, both positive and negative. And as developers, it feels really good when we turn those negatives into positives.

The big-dog companies are going to stay afloat with their large sales staff, but companies like Elation EMR and Ankhos will rise up with our willingness to get down in the trenches and develop from the inside out.


Nurses are key to a great EMR Success

July 18, 2013

Most of the EMR sales effort is clearly oriented towards the doctors and administrators of a practice. They are the ones who control the money, the gatekeepers.

If the salesperson can get past the MD, or administration, they declare “Success!” and move on to the next practice or hospital.  The effects of the EMR system (for good or bad) remain with the clinic.

In an outpatient oncology clinic, a good portion of revenue comes from the actual treatment of patients; from nursing and drug delivery. This is also an area where many mistakes are possible and a vast assortment of safety precautions must be made.

In order to perform these documentation and safety requirements, the EMR has to work and just stay out of the way. Nurses cannot be bothered to wrestle with an EMR that was not built for their specialty or was just poorly designed (A lot of EMR systems are designed for the front office and MD encounter than for a treatment floor.

Sometimes a lack of productivity is a training issue. Sometimes it is not. The EMR that Carolina Oncology had was nigh-unusable in the treatment area.  Chemotherapy order sets could not be altered easily. It was difficult to document start and stop times for infusions.  Any contraindications made were imperceptible unless the employee was specifically looking for them. After a while, the nurses at Carolina Oncology threatened to quit.

They went back to paper charting.


Apparently this story is becoming more common, or at least more visible. Nurses at Sutter hospital system took several issues with their EMR implementation.

• A patient who had to be transferred to the intensive care unit due to delays in care caused by the computer.

• A nurse who was not able to obtain needed blood for an emergent medical emergency.
• Insulin orders set erroneously by the software.
• Missed orders for lab tests for newborn babies and an inability for RNs to spend time teaching new mothers how to properly breast feed babies before patient discharge.
• Lab tests not done in a timely manner.
• Frequent short staffing caused by time RNs have to spend with the computers.
• Orders incorrectly entered by physicians requiring the RNs to track down the physician before tests can be done or medication ordered.
• Discrepancies between the Epic computers and the computers that dispense medications causing errors with medication labels and delays in administering medications.
• Patient information, including vital signs, missing in the computer software.
• An inability to accurately chart specific patient needs or conditions because of pre-determined responses by the computer software.
• Multiple problems with RN fatigue because of time required by the computers and an inability to take rest breaks as a result.
• Inadequate RN training and orientation.

Some of these are problems with Reality, like slow lab tests or incorrect orders, but others indicate real shortcomings with the software, such as accuracy and usability.  I hope this hospital system can iron out these issues.


In facilities with inpatient or outpatient care, nurses are the troops on the ground. They interact with anxious and frustrated patients. When things go wrong or patients get annoyed, they are the ones who hear about it. You have to supply them with the correct tools or they can’t do their jobs.


When we start marketing Ankhos in a broader playing field, I will make 100% sure that I have clinical staff buy-in before a sale. Otherwise you are just selling brochures to doctors, not offering a tool to make a more efficient, cohesive and communicative office.

Win the nurses and the rest will follow.


Open Medication Datasets

July 11, 2013

In our quest for CCHIT Oncology Certification, we will also be required to be CCHIT Ambulatory EHR certified. This Ambulatory certification has a good amount of overlap with the Meaningful Use requirements, including most of the medication/allergy/drug interaction requirements. I have spent many hours going through medication datasets trying to find the right combination that will give us what we need. This post serves as both a recap of my research for documentation but will hopefully provide a good starting point for others looking for open datasets for medications and allergies.


General medication list requirements include:

1.Keeping  a dataset of prescribable  medications. This list must include at a minimum drug name, generic name, dose, strength and route. This list should be comprehensive and concise enough to provide the prescriber with a terse, yet complete list of medication options.

2. A mechanism for documenting current and past medications and keeping that list up to date.

3. A way for providers to add new prescriptions and send them to the pharmacy as (non-faxed) eRx.

4. A way to provide information on any drug interactions.

5. The ability to create CCD/CDA documents for continuation of care.

6. The ability to accept continuation of care documents from other facilities.

7. Not cost a fortune.


Given the above requirements, two fundamental notions must be captured in the medications dataset: The drug list and a list indicating drug interactions.


Many of the proprietary medication datasets (FDB, Medi-span, etc.) are not open and I am sure they are not cheap.  There are no prices on their website which makes me weary of their pricing strategy. I don’t have time or energy to negotiate pricing and worry about whether I got a good deal.


There are open alternatives, the main one being RxNorm.  This dataset is very comprehensive and is freely available. however, it is more of a translation device between other datasets than a terse, canonical list of medicines.  RxNorm is constructed by collating medicines from many sources, FDA, VA, Gold Standard, SNOMED-CT, even the proprietary medications are linked.  Because of the vast breadth of this RxNorm, it is not immediately suitable for fast data entry.


This is why Kin-Wah Fung of the Lister Hill National Center for Biomedical Communications, NLM has led the effort to create RxTerms. RxTerms is a curated list of drugs derived from information in RxNorm and is designed for efficient provider data entry. The medication names are distinct, concise and include the required information for prescribing. And each medication or concept in RxTerms links to corresponding concepts in RxNorm. Here is a great demo of their work.

However, RxTerm was not designed to directly provide drug interaction data.


For medication interaction data, we will be using the NDF-RT dataset, created and maintained by the U.S. Department of Veterans Affairs, Veterans Health Administration (VHA). This dataset is linkable to both RxNorm and RxTerm and is also freely available.

The queries will be a bit cumbersome but all of the needed data is there. You can try the demo of this interaction mapping at the RxMix site.


With these two datasets, RxTerms and NDF-RT, we will be able to provide concise lists of medications to our providers, check drug interactions and transmit and receive continuation of care documents to and from external providers or HIEs.


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!