Archive for the ‘EMR’ Category

Ankhos launching on iPads, but not Mac

June 10, 2010

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…

(more…)

EMR virtualization… possibly

June 7, 2010

Throughout this whole project we’ve been operating under the assumption that we would have a typical (maybe not) intranet web setup: a dedicated application server, a database server and scale from there.

But recently, we’ve begun to examine the possibility of virtualizing the entire operation. COS are currently using VMWare (HIT Link) for some of their applications and it would make a lot of sense to simply load up another vitual app on their servers. Maybe some hardware would need updating, but that’s easy with virtualization.

I still have a lot to research and learn about the specifics of the different virtualization platforms, but it seems like a no-brainer.  Virtualization could also allow us to easily disseminate Ankhos at a later date with the use of virtual ‘apps’. There are many EMR systems currently available as virtualized apps, but none addresses the specific needs of the oncology internist… yet.

What have your experiences been with EMR virtualization?  I know there are many commercial initiatives (Dell, McKesson) starting up and this is probably very fertile ground for the future of EMR rollouts.

Legacy Health IT: Case of the MUMPS

June 3, 2010

I recently recalled an article at The Daily WTF I read a while back on legacy health IT software, specifically regarding the language MUMPS, or “M”. It was developed by Mass. General Hospital and was pretty innovative in its time.

But that was 1960. Programming language have diversified and evolved (I like Python). But looking at a sample of code (Wikipedia) from this language makes it easy to understand why these large health IT companies find it hard to have an agile approach to software changes:

Here is some example code from Wikipedia:


%DTC
%DTC ; SF/XAK – DATE/TIME OPERATIONS ;1/16/92 11:36 AM
;;19.0;VA FileMan;;Jul 14, 1992
D I ‘X1!’X2 S X=”" Q
S X=X1 D H S X1=%H,X=X2,X2=%Y+1 D H S X=X1-%H,%Y=%Y+1&X2
K %H,X1,X2 Q
;
C S X=X1 Q:’X D H S %H=%H+X2 D YMD S:$P(X1,”.”,2) X=X_”.”_$P(X1,”.”,2) K X1,X2 Q
S S %=%#60/100+(%#3600\60)/100+(%\3600)/100 Q
;
H I X<1410000 S %H=0,%Y=-1 Q S %Y=$E(X,1,3),%M=$E(X,4,5),%D=$E(X,6,7) S %T=$E(X_0,9,10)*60+$E(X_”000″,11,12)*60+$E(X_”00000″,13,14) TOH S %H=%M>2&’(%Y#4)+$P(“^31^59^90^120^151^181^212^243^273^304^334″,”^”,%M)+%D
S %=’%M!’%D,%Y=%Y-141,%H=%H+(%Y*365)+(%Y\4)-(%Y>59)+%,%Y=$S(%:-1,1:%H+4#7)
K %M,%D,% Q

Compared to some example Python code:


my_list = ['john', 'pat', 'gary', 'michael']
for i, name in enumerate(my_list):
     print "iteration %i is %s" % (i, name)

I’m being a tad unfair here, as the above MUMPS code does not simply print a list of names (I think), but what should be clear is the degree to which some of this legacy health IT code is completely un-manageable. It might be worth asking your large EMR vendor which types of platforms they are using and what they think of their ability to add features and fix bugs in a timely manner.

Chemo administration screenshot

May 19, 2010

This is a promised screenshot of our current iteration of the page our nurses will be using to administer chemo.  There is a LOT going on in this picture, but some of the important procedural bookkeeping that is required of the nurses is streamlined on this page.  IV notes, allergies, even plain old warnings about a patient are present here.  Also present are things like dual-signature chemo dose verification and minute-by-minute tracking of what has happened to this patient.

Keep in mind, this is a beta, and there are some debugging/feedback features here for the time being.

The orders these nurses are carrying out come from the specialized physician order interface (not pictured here).

I would love to get more into the rest of the application, but that is premature at this juncture.

Atomizing healthcare IT

May 19, 2010

There has been a lively discussion on one of the posts of EMR and HIPAA about why Medical IT adoption is so slow relative to, say, the financial sector (or the library system for heaven sakes!)

Some blame doctors, some blame lack of real government stimulus and some blame un-enthusiastic IT companies but I think the real problem is the perspective that the industry has had on this subject.

It is true that there will always be a ‘workflow’ framework and a software design process centered around leveraging existing software for new workflows, but that doesn’t mean all strategies of ‘molding software to the workflow’ will work.

At some point the differences are so fundamental that in order to create effective software more than just conforming is required.

Heathcare workflows will have to be atomized in order for software to be beneficial. You wouldn’t expect a mom and pop local bank to be productive/cost-effective with stock-trading software from Goldman Sachs just because they are both in the financial sector!

I think it’s going to take some fresh thinking and willingness to start over to bring productivity and cost-effectiveness to healthcare IT.

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…

EMR ‘patenting’

May 15, 2010

There is a recent newsflash that an EMR company was granted a patent for ‘storing patient data electronically’.

As if there weren’t enough problems with the patent and trademark systems, companies like this are granted superfluous patents that will only hurt innovation.  I hope the industry recognizes this patent for what it is about: a completely obvious and commonly used practice.

Let’s just hope this is a defensive patent and that they don’t plan on suing hospitals for something they’ve been doing before this doctor had his medical license.

Seeing the forest without the trees

May 13, 2010

A while back, I posted a video of how regimen creation is done in Ankhos. In my recent visits, we have decided to almost completely gut that portion of the  UI.

We were using tree widgets, the kind you find when you navigate  file systems on some operating systems. Instead, we are going with the automatically-populated textbox that displays not only drug and procedure names but regimen names, as well.

I think some of the reason we went with the tree paradigm in the beginning was my own ignorance of how chemo regimens are prescribed. The PAs and MDs know what they are looking for when they search for a regimen. They are not ‘exploring’ all of the breast cancer regimens searching for the right one.

I, on the other hand, did not. I assumed that because I had to explore to find a relevant regimen, that the user would too. I think this is an important lesson and a very productive UI improvement that will save them time.

Another lesson here is that I was only able to learn this by performing usability inverviews on-site with the future users of the system. Scrutinizing every click and mouse movement they made, how long they hovered over certain things and trying to ascertain what aspects of the UI seemed to confuse them. Not scientific by any means, but productive.

I find it hard to imagine a large software/EMR company being able to have the close interaction and trust that one can engender with a small engineering team

We are near the end of our annealing user sessions and the home stretch is ahead for completion of phase 1 of Ankhos.  I am very excited as are all of the users at COS. They even have their fancy new long-battery-life Acer laptops!

Querying the future

March 30, 2010

One of the coolest and most impressive aspects of keeping electronic records is the ability to compile massive amounts of information very quickly. But, many offices still use paper and pencil to plan their patient scheduling and pharmacy ordering.

“How much Flouroracil will we need tomorrow?”

“Do we have enough time/space to fit another patient in at 3:00?”

“Do the amounts of controlled substances in our pharmacy match up with the amount prescribed last week? Do we have enough for the upcoming week?”

“How many nurses will we need on Friday? Can Jane take the day off?”

These questions would take hours to answer if compiled by hand, but with an electronic record/scheduling system, they could be answered in seconds…. IF they are implemented correctly.

The flagship feature in Ankhos is the ability to schedule an arbitrary number of chemo cycles months in advance, letting nurses, administrators and pharmacists know exactly what treatments are coming up in the future. If we have answers to the questions above in elecrtonic format, we can make you and the staff of your oncology office much happier, safer and more prepared.

Open source HL7 parser

March 19, 2010

I’ve spent the last few days creating the data ingest engine for our application so we can automatically retrieve data from our in-house lab machines. In doing so, I decided to start my own HL7 parser. I did this because I wanted access to fields by field name and not just by list index.  I also wanted to learn the HL7 spec a bit more.

And learn I did! I learned that there all all sorts of flavors of HL7, each home-grown from lab or EMR vendors to suit their own needs.  We have also decided to make this an open-source aspect of our project. I wanted to wait a while to do this, but this video about the pitfalls of trying to make code ‘perfect’ before releasing it helped push this open source move.

The code can be found here:

http://code.google.com/p/ankhos-python-hl7-parser/

This code is far from complete and we will be adding features as we find a need for them. This system currently is sufficient to ingest blood work data from our LabCorp machines.


Follow

Get every new post delivered to your Inbox.