This is the sort of war we are fighting. We ARE in the office, experiencing user interact with the system every day. It IS working but I feel there is so much more to do.  We have even put up

signs to remind people about our quest for faster and more accurate methods for data capture.

One progress update is that we are going to implement e-faxing in a rollout this weekend. We are going with Innoport due to their https interface and the ability to render faxes from multiple types of documents.   By going with a company that provides an API and not using a ‘print to fax’ button, we can keep data that will give us a better idea of our costs and faxing usage, and allows us the ability to enforce system-wide rules about when a document can be faxed (Does it need editing/revisioning/etc.)?

We have written a companion interface to Innoport in Python. They have examples for C#, Java and a few others but if any of you are looking for an Innoport Python module, let me know and I will try to help you out. We plan on releasing that bit of code when we have time but would consider bumping it up if someone has a specific need.

Ankhos tracks everything from treatment schedules to nursing notes to appointment times and lab results.  That can end up being a lot of data, touching a lot of database tables if the patient has an involved history. So how do we show all of this information at once, while still having a fast, painless user experience?

Here is an example picture of what an somewhat involved calendar might look like (this is actually sort-of tame. I was trying to find one without much identifying data):

Patient calendars in Ankhos can become very complex.

You are able to scroll up and down depending on how long of a history the patient has and how far out treatments are scheduled (or based on preferences).  A straightforward way to increase the performance of this page is through caching.  We went with Memcached. It is insanely simple to use and very fast.   There are lots of tutorials on how to speed up flat-page or low-change page performance on their site (My favorite is their tutorial… in anecdotal format ).

One problem still remained, however. Ankhos allows the user to drag and drop treatments,  create comments directly on the calendar and have new treatment orders appear immediately.  Caching the entire calendar may make it load quickly, but each time an action is performed, the whole thing needs to be ‘recalculated’, as one action could have the potential to affect long swaths of time (e.g. Discontinuing a treatment).  This would dramatically increase response latency when manipulating the calendar (a bad thing).

Consider two different calendar operations: 1.  jotting a margin note that affects one date and 2.  dragging  a 6 month Carboplatin regimen from Tuesdays to Thursdays.

Our goal is to make the difference in response latency be a function of the size of the change, not the size of the calendar, so that these two operations would ‘feel’ like they took  roughly the same amount of time.

To accomplish this goal we have split up our calendar cache.  Instead of caching the entire calendar as one HTML chunk, we store the rendered HTML of each week  separately and render single weeks in the calendar only if they ‘miss’ the cache. Our cache key would be something like  ”ANKHOS:CAL_WEEK:1234:2011-10-02″. If all of the calendar weeks are in cache, displaying the calendar is as fast as string concatenation.

This way when we made a large drag and drop operation or just a single date modification, we can expire the weeks that are affected by these dates and re-render only those weeks.

This scheme has served us very well and has made calendar manipulation a pleasant experience. I hope this idea gives someone  a head start on their partial-caching problem.

NCOH is currently using Centricity and is bracing for the change to Centricity 9.5. Today I was able to get a look at some of the screenshots — They look great.

What looks even better is the solution that Unlimited has created to complement Centricity. Their software puts the
proverbial icing on the cake, making the business side of practice management using Centricity that much easier. It also looks slick and fun to use.

As readers know, this blog is about the origin and development of Ankhos and I can see some serious potential for integration here. Indeed, it seems that Unlimited Systems has this type of integration dead in their sights. Whether it be a hardware vendor, EMR or even other PM software, they are a force for unification and integration that is enthusiastically reaching for the stars.
Soon, I’ll be on my way back to North Carolina to prepare for the arrival of our new developer!   I am very excited, as we will be able to handle user issues and drive progress in Ankhos at the same time!

Hello. This is my first attempt at blogging. So I am a little nervous but here I go!

I am a nurse. My knowledge base is in people, not in macros, pigeon holes or textboxes. Over the years I have learned a lot, self taught, what I like to call a “computer geek wanta be.” I know enough to get by. Let’s just say I know just enough to be dangerous.

Having said that, when the very busy Oncology Practice I work for purchased an EMR I was asked to help as a super user and was eager to get involved. Why not? I love this stuff!

I worked on developing the chemo regimens and single agent favorite list of drugs. I also developed documentation tools call Questionnaires for nursing documentation. I thought Questionnaires was an odd name for a documentation tool but, after a while it made sense. The Question was “Why does this have to be so hard?”

I could go on and on about how difficult the EMR was to use but I do not want to relive that. We finally scrapped the drug ordering and administration portion of the software. We now only use the scheduling and note portions of the EMR. We looked at other systems and did not see anything we wanted to pursue.

Then along came Ankhos.

Ankhos is so easy to use. I even have some privileges to add and modify drugs and procedures. These are called Orderables.

In the old system this was the hardest part. We are nurses. We are surrounded by patients who need our attention. We need an easy to use adaptable system where doctors can order and nurses can document treatments accurately.

We now have it.

We are in the enviable position of having an on staff software developer, Nick Orlowski, available to build the software to meet our needs. All we have to do is ask.

Working with Nick, I began to understand that the software should work for me, not me working on the software. I started to ask what Ankhos can do for me. These things are coming and I am excited to see how they develop.

We are accurately documenting on our patients. All the documentation requirements are being met. One of the best parts for the nurses is to be able to pull the treatment to an order sheet when the patient goes to an outside facility for their chemo. Ankhos tracks the location of the patient’s treatment and I am then able to verify the treatment is given after notification from the hospital the treatment is complete.

I review all the previous days encounter forms and having the drugs documented in Ankhos has saved me so much time when there is a question about a charge on a form. All I have to do is pull it up. I would have to physically find the chart to verify the treatment before Ankhos. It is wonderful to have it right there.

We have just begun. I am excited to see what is coming.

-Joy

A few weeks ago I wrote a post about a distinct feature of Ankhos called sandboxing. The feedback from our users has been overwhelmingly positive. Many of our users came from outside clinics or hospitals where drug entry was a daily(or weekly) task and each agent had to be ordered at once.   The ability to easily modify a published regimen (or order labs, blood, etc.) is a boon to provider productivity.

The past few weeks have been very busy.  We have reached some serious milestones in our project:

1. Nurses are completely paperless. All infusion time charting and Nursing notes are done in Ankhos.

2. All labs are available in the EMR, imported directly from the clinic lab machines (as well as a Labcorp interface).

3. All Providers are creating their orders in Ankhos.

a. The new Doc is well-trained as Ankhos has actually helped orient him to the practice’s idiosyncrasies.

4. 10 new Toshiba Sattelite (17″/4 g/300 g) were purchased and placed in exam rooms. I will write another post regarding the decisions and setup of our client hardware.  The biggest draw is the great quality of the wide screen. Ankhos is a web app so we don’t need a lot of processing power.

5. My sister was happily married to her long-time boyfriend in a fabulous wedding in downtown Charlotte.

Hopefully I will get back to blogging our development more in the future as things move more towards maintenance mode (HA!)

It takes dedication and focus to come up with a competitive product in this market, and just providing ‘templates’ is not enough to increase productivity, safety and ROI.

Quick edit:

One divergence from the article that Ankhos takes is our lack of automatic drug calculations. There are handy calculators integrated into the system to calculate AUC and BMI, but every dose must be entered by a human in absolute milligrams (or cc, etc.). The computer is not allowed to determine or alter any doses.

One main concern that a healthcare practice faces is impending lawsuits and audits. Electronic systems are  very powerful and very descriptive. There are timestamps and ‘fingerprints’ associated with every action taken in Ankhos. If there was an accusation that someone had not documented an allergy or reaction correctly, or administered the wrong drug, the record of that incident would be easily accessible with an electronic system and the legal accusation would be quickly resolved.

However, electronic systems also present a great opportunity for fraud and tampering. Yes, fingerprints, access controls and timestamps are strewn throughout the system, but the database administrator has final say about everything that is in the database. A diligent fraudster can easily cover up an audit trail that would otherwise prove malpractice.

Because of this possibility, an astute lawyer could raise doubt about the validity of any claims made with reference to the electronic records, and rightly so.  But how do we solve the problem of proving data integrity while at the same time retaining the flexibility of an electronic system?

After some thought and research on best practices, we decided that it was essential to have a third party involved. One whose interests were not co-mingled with those of the practice.  We also wanted to have an irrefutable way to use that third party to validate the state of the database.  We want to be able to say:

“Yes, Mr. Lawyer, this was the exact state of our database (and application code) at this date and time”

Our process is two-fold:

1. During each daily backup, we hash the backup file using the Unix md5 hash command.  We keep local copies of both the hash and database file. This is a common practice across many download sites. At a later date, the file can be hashed again and compared to the hash on file. If the hash strings match, then the file has not been altered or replaced.

2. The first step is great, but if the database admin has complete control of her data, then she has complete control of the hashes, as well (and any backup trail).

To solve this problem, we email this hash value to a number of public email accounts to which office administrators have access.  The hash value is a short string of ‘random’ characters derived from the database file and cannot be used to reconstruct a backup file (thus, no patient data is transmitted on the unsecure email format). Doing this allows the hash value to have a timestamp assigned by a third, independent and uninterested party.

This way, when a lawyer asks us how we know that database admin we hired didnt cut out any incriminating data, we can point to the timestamp given by the email provider and show that by the power of our email provider and all the SMTP servers involved in this transaction, THIS was the state of our database at this time.

Hopefully this will satisfy auditors and save the clinic time and money trying to prove the state of their documentation.

I described how things are going very well and that we are slowly but surely adding new functionality and refining existing features. I told him that the biggest issue  we have is getting data from the previous EMR.

He suggested that, maybe, the real way to promote competition in the EMR field was not to mandate that all doctors/hospitals have EMR software, but to mandate that if a practice requests it, an entire data dump must be provided in an electronically-parseable format by the EMR vendor.

This would light a fire under the butts of many of the old EMR vendors whose strategy has revolved around vendor lock-in and would allow for practices and hospitals to incur less risk when deciding on an EMR vendor.

Doctors and hospital admins are not stupid; they are not categorically computer-averse.  A mandate is not magically going to make medical software worth a doctor’s time. Forcing immature/unwanted software into the medical field is a recipe for disaster.

If it is impossible to shop around and take your data with you, all the choices in the world are not going to help.  We need EMR liquidity.

Whether we’re using a regimen straight from the textbook or creating our own, we have the option to place it in the ‘sandbox’.  Anything can be placed in the sandbox, from entire regimens to x-rays to comp panel orders…. Anything that occurs with some periodicity in conjunction with patient treatment.

Ankhos provides a 'sandboxing' technique for easy regimen creation/modification.

Once in the sandbox, these agents and orders can be modified on a  day/cycle basis in order to match the needs of the patient. Clicking on the right and left arrows will increase/decrease the cycle length, and the days of a treatment can either be typed in or inserted on days 1,8,15,… by clicking the weekly checkboxes.

The sandbox outlines a patient’s entire treatment schedule in one fell swoop.  We won’t need to do any physician data entry for weeks… or until a change is needed.

The sandbox pictured above outlines 4 weeks of (made-up) treatment. Once the treatment is in the sandbox, You can cycle these four weeks as many times as you want. Three cycles of CHOP-R? Easy. Weekly CBCs for 6 months? Easy.

The sandbox has received many accolades and nearly every user who has experienced it describes it as ‘very powerful’ or ‘incredibly easy’.

One limitation of the sandbox is that it is not practical to schedule a follow-up  one year from now or mammogram in 6 months, but we solve that problem by ordering the simpler tasks like a normal EMR might… one at a time.

A final note: As far as patient safety is concerned, each treatment must be electronically signed by an MD before it can be administered so any dose reduction that is required does not fall through the cracks.

So the iPad is back on.  We now have a two-factor setup in the office now for the physicians. The first is a kiosk-type style with a widescreen monitor in the main hub.   The other is the iPad; users are encouraged to use what comes naturally to them and so far, this is the setup that has evolved.

And, of course, Ankhos is a web (browser)-based app, so any computer with an internet browser on the internal network can access the application.  This allows great flexibility for our our users to evolve how and where they interact with the program.

This sort of thing is another reason I love my users. They are persistent in discovering what will work best for them and provide feedback that allows me to accommodate it.  It only took a few tweaks to get the iPad working like they wanted, then they were off and running.

Next up? Android and Windows tablets…. Let’s get ready to rumble.