Archive for the ‘EMR’ Category

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.


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.


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!

Ankhos is Paperless; Next step: CCHIT Oncology Certification

April 30, 2013

I am proud to report that we have reached a major implementation milestone in the development of Ankhos: no new paper is going into any chart! All new patient referral material is being scanned and all incoming documents are reviewed and signed electronically… and our users love it.


We have had our nose to the grindstone for 2+ years and it is now time to look up and make sure we are headed in the right direction.


In the light of the recent meaningful use audits, I think it was a good decision to finish these core features before attempting meaningful use certification.   The physicians I work with are quickly realizing that it is much easier, desirable and predictable to squeeze money out of increased productivity than to hope that the government hands us a check (and doesn’t take it back).  While we are still headed towards meaningful use, we are going to take a short detour – to CCHIT Ambulatory Oncology Certification. 


It’s not that large of a detour either. Because we started with the fundamentals of oncology: regimens, propagating dose changes, a timeline-oriented mentality, and a strong drug administration workflow, we are probably 85-90% towards complete test script coverage.  Having the CCHIT seal of approval for both oncology and meaningful use should help this rocket take off even faster.


Are we and EMR vendor? I’m not sure anymore. I’m beginning to think of us as an Oncology Software Vendor.

Faxing in Japan: Anything but a relic

February 16, 2013

My fellow programmers bemoan the dastardly fax machines in our office.  They are slow, there are always problems like “Only half of the page came through”, busy signals, out-of-service numbers… they all add up to describe a system no one would ever choose in this day and age. And we don’t. Many successful EMR systems HAVE closed that paper gap already and are proud of it. We are weeks away from being there, as well.

However, according to an article in the New York Times, a large contingent of the Japanese population prefer faxes to other types of modern communication.

In Japan, with the exception of the savviest Internet start-ups or internationally minded manufacturers, the fax remains an essential tool for doing business. Experts say government offices prefer faxes because they generate paperwork onto which bureaucrats can affix their stamps of approval, called Hanko. Many companies say they still rely on faxes to create a paper trail of orders and shipments not left by ephemeral e-mail. Banks rely on faxes because, they say, customers are worried about the safety of their personal information on the Internet.

If the Times article is representative of the Japanese sentiment, this might make sense.  However, the article does not mention this phenomenon in Health IT so I looked around. I found a BBC article and a Wall Street Journal article that echo the Times article.  The WSJ journal explained

[the] reason is that computers, at the outset, never worked well for the Japanese. The country’s language — a mix of three syllabaries, with thousands of complex “kanji” ideograms — bedeviled early-age word-processing software. Until the early 1990s, Japanese was nearly impossible to type. Even today, particularly for older Japanese people, it’s easier to write a letter by hand than with a standard keyboard. Japan also relies on seals, called “hanko,” that are required for most official documents.

The BBC added that part of the cause was that Japan’s population is an aging one, where older people are more reticent to give up their paper and the subtleties of communication and respect in a handwritten fax.

One more report by John Halamka, a leader in health IT reported that

Japan has a state-of-the-art wireless and wired networks, arguably the best in the world. However, few hospitals and clinicians use this infrastructure to exchange heathcare information, coordinate care, or engage patients/families.

He doesn’t say the word “fax” but I suspect that this is what he is talking about.

Maybe the HIT community will get to bypass the days of HL7 2.x and live happier lives because of it!



Guest post: Richard Orlowski, M.D.

January 15, 2013

The following is a guest post written by the head physician at Carolina Oncology Specialists regarding the government “quality of service” reporting and its effects on EMR software.
The medical office now is encumbered by an overwhelming array of government regulations and hurdles. The government, as payer, is desirous of avoiding fraud and abuse. The government hopes that the EMR will make records more available to them for analysis of cost, appropriateness and ultimately rationing (which is inevitable in a government system–under some other name). Thus, the idea of “cost savings” pertains to the government and not to the practice.

There are aspects of the EMR that are wonderful, such as immediate access to data collected in a central repository in a timely manner without having to search for charts. Collecting and organizing all of the data is not an easy task and is a major challenge for programmers.

The data must be presented for thorough review and sign off. Also, the EMR is well suited to aid in scheduling events and tracking progress of plans of management and  documenting in detail what is happening in the office. To increase efficiency the EMR must help with these processes without imposing extra work for the medical staff that is under fire throughout the day dealing with living, breathing patients with innumerable real-time problems.

The EMR will not give the practitioner experience, knowledge, intuition, critical thinking, improved mental focus, proper diagnoses, proper treatment, and insight into human aspects of patient interaction or compassion.

The government, in their concern for containing costs, has devised a method of oversight that centers on coding and documentation for such coding. Actual clinical skills do not enter into this analysis. The government asks that MD charges be justified by an incredibly convoluted and complex system of  “bullet points” that testify that a certain level of data collection has occurred.

Computers are particularly adept at data collection so what is seen now is perversion of the patient encounter such that attention is diverted from thinking to data entry. Doctor notes generated under such requirements are voluminous. The notes lack focus such that it is impossible  sometimes to figure out what problem solving occurred during the visit. Despite this, it is certain that data collection has occurred and bullet points have been checked to justify charges. The computer spits out 6 pages of meaningless bullet points. The process is a major distraction. Nowhere in this construct is there the ability to determine if the practitioner acted appropriately and with insight. Nowhere is there a way to measure what was  NOT thought about. The whole process is demeaning and cumbersome and unproductive. It’s no wonder that EMRs are not saving offices money.

Now, in continued effort to reduce expenditures, there is a push by the government to measure what the regulators call “quality”. Excuse my skepticism, but this appears to be another sketchy scheme conceived by the same people who created the above monstrosity with bullet points. They will measure what they are able to measure and call it “quality”. It will amount to more garbage in–garbage out. The practitioners will learn the rules and the EMRs will adapt to spit out more verbiage to satisfy the rules. The measures will miss the mark in detecting and rewarding truly skilled physicians. The computer programs will adapt. Practice management will become more difficult. Efficiency will suffer. EMR’ will fail to result in cost savings in the doctor’s office because they are being used in the government’s game of cat and mouse rather than as a finely tuned tool to assist in evaluation and management. This is a reflection of the difference of perspective of someone in the trenches vs. someone in a government office shuffling papers and trying to control the massive, amorphous, and constantly changing world of medical care.

Integrated faxing with Faxage

June 4, 2012

It is an unfortunate truth that for the next 3 to 5 years (maybe 10) faxes will still be required to run a medical office. In late February we rolled out  Ankhos version 2.0 which included the ability to fax any document in the system from a user’s workstation (or iPad). It has been an incredible success with great return on investment in both time and money.

Since the end of February are that we have sent 9986 total faxes, of which ~8500 were medical notes(~1-5 pages) and ~800 were outpatient hospital orders(~1-2 pages).  There are other generic faxes that go out, including one-off lab orders and medical records requests.

 The old way involved using an EMR that required a fax modem which required a service contract and constantly broke down. Upon that modem’s final demise, we tried a mix of paper faxing and a series of electronic fax solutions but finally settled on Faxage.  They provide an HTTPS API (extremely important for HIPAA reasons. Fax over email is not acceptable). The price is also excellent. With our volume, we require a hefty plan but they are reasonable with their pricing and realize that $.10 per page is ridiculous and insulting.

Another great thing about an HTTPS API is that if you decide to switch to another carrier at some point, it is much simpler to change out the interface module for one that matches another API (We had to do this from one fax provider who had some… surprising billing items). Also, We can tailor the fax interface with Ankhos so that the user does not have to perform clunky interface tasks such as ‘save as fax’ and we can manage our own queue, address book and monitoring platform as we see fit.

Keeping in mind that pages sent is not equal to number of minutes, I can provide some numbers on approximate money saved from human salary (not to mention paper/shredding services).We have saved $2,000 over this three month period in employee-hour-dollars by using integrated faxing. (This figure is a rough estimate and includes the cost of Faxage) . Faster faxing means nurses can get back on the floor more quickly.  Add to that the $800 per month we were spending on our previous electronic faxing service and the savings are crystal clear.  We still have work to do with incoming faxes which are an order of magnitude more numerous.

User feedback has also been extremely positive. Phrases like “I love it!” or “It makes me want to send faxes!” are uttered often, even 3 months later.  Our users love Ankhos faxing and we love Faxage faxing.