Tag: open source solutions

AuShadha2.0

For all those who were following AuShadha Open Source EMR project hosted at GitHub there’s news. 

I had paused developing for sometime due to pressure of time. 

The development has restarted for past few months (no commits ) and am planning to branch of development into AuShadha2.0 with changes to the core, Dojo 1.12 JavaScript library, Django1.10 support and Python3.x support. 

This is a version written with lessons of what were not ideal practices in previous version. 

Watch this space. Will post more by the end of this month. 

Advertisements

AuShadha Open Source Electronic Medical Records Project : Version 1 at the Horizon

AuShadha Open Source Electronic Medical Records project is coming along nicely.

This has been done in Python, Django and Dojo.

The project introduction is here

This is an update to AuShadha on the walk up to Version 1

I am rather busy lately which is why there has not been a post on this; its been quiet for a while, a little longer than I would have liked. The project though, has been far from quiet. Several Improvements both in UI and the back-end has been done and is continuing in a walk up to Version 1 vision put down in the Github Wiki Roadmap.

The gallery below is some samples of the improvements that have come along. These would not have been possible without the help of Dr. Richard Kim, whose constant advice , criticisms helped shape this and continues to do so. Developers involved with the project has been credited and integrated into the UI.

Predominantly the focus is on a balance between minimalism and functionality. It is known that minimalism is beautiful, but in a non-linear system like EMR the issue is that there may not be a workflow to speak off. People often need to random things at various times and expect the UI to keep things within reach. Initially I was not convinced about this, and my focus was more on workflow. Richard convinced me about this and now I see the light. However, my attraction towards minimalism has not been totally abandoned and try to achieve a balance.

As we see version 1 at the horizon, it will be nice to have your feedback. Do leave your comments and criticisms here.

Head over to Github , grab the code and let me know.

War of the Python EMRs Starts this week at my Hospital – GNUmed v/s GNUHealth

My Hospital has requested me to install Electronic Medical Records (EMR).

We are planning, as always, an Open Source Based EMR Solution.

I have desisted from offering my Open Source Electronic Medical Records -AuShadha as one of the options as its still in heavy development.Therefore I have advised two Open Source Implementations that I have short listed after scouring all the available choices that are listed in Wikipedia and Medfloss.

While some of the implementations are not in active development, others are not specifically meant for private clinics like ours. They are for developing nations to keep track of communicable diseases and other specific diseases and treatments. While it is possible to adopt and modify them , there are two Open Source EMR implementations that are reasonably good straight out of the box.

1) GNUmed

2) GNU Health

Why did I choose them ?

I have to implement and maintain them. I know Python. They are in Python.

Implementation should be easier and so will the maintenance.

Tweaking them to closely fit our hospital’s work flow and adding specific forms for data collection and research work should also be possible.

I personally tend to favour GNU Health, because of installation woes on GNUmed’s previous versions and what I thought was a complicated UI layout but recent communications with Mr. Stephen Hilbert and Mr. Karsten Hilbert, developers of GNUmed and an India doctor who uses GNUmed have forced me to take a second longer look.

This week then I will be installing both on our servers and opening it for use by doctors at our hospital for a month. The user friendliness and ‘tweakability’ will be assessed and then we will decide a month later on which to choose.
Keeping fingers crossed. Will give Installation reports, issues, user experience here once it is through.

Guide to Successful Open Source Software Implementation in Hospitals – Some Difficulties That Needs to be Crossed..

      Its the age of Great Leap Forward..

People are happy, work goes on.. life is kind of strange with no BSOD but people are still carrying on.

One thing they are unhappy about.. They have to work. Gone or the days when their trusted OS used to giveway under then leaving them staring at a BSOD so that they could make a quick call to the IT in charge and go out for a coffee.

Excuses for work delay have come down.

So how did we get ourselves in this mess ?

We had to struggle.

What follows is a first hand account and a general guide for all Doctors who wish to implement Open Source Solutions / Software or Linux based systems at their workplace but are afraid to take the plunge.

For the technically minded Mr. Kumaran (http://kums.in) is preparing a more technically heavy note full of implementation details. Please watch that space.

 

Essential Reading

1) How we moved to Open Source at our hospital

2) Intranet &PACS

3) My Open Source EMR

4) EMR Implementation

Planning ::
==========

– Sit down and think what we want our computers to do for us and define a budget.

– This will dictate what software & hardware you need to get that
job done.

– Make the right Hardware and Software Investments. It is very easy to
get convinced by the vendor to invest more in features you may never
use / need.

– You need to choose you FOSS projects carefully.

http://www.ohloh.net/

http://www.sourceforge.net

gives you indices that help you decide the popularity of the software.

– Look Before you Buy: Always check the Linux Compatibility of the
hardware you are going to purchase after you have installed Linux.
While many will work out of the box, some will work after tweaking,
some may not work.

– Get the right persons for the job. There will be an element of luck
here. If you are, then you will find somebody passionate abt this. Consult them.FOSS enthusiasts and ready to help.

– Do your Homework: I worked for 5 years trying out one solution after another before settling on the ones I wanted. Since I know the work flow of my hospital, I naturally know what suits it the best.

– Keep it cheap. It can be done. Cost is important, even if you are willing to pay
more. Bargain hard. Buy only what you want. Dont by what you are
sold.

– Interoperability within and without your office. This is important.
When going down the not-so-beaten-before track. Detractors are many.
Complaints will be raised. It will be irritating. Don’t expect users
to share your idealistic vision. Every complaint needs to be
listened to and most of them can be safely ignored. Some of them
will give an idea of the gap that needs to be bridged.

– After-installation-service – accessibility, response time, ?365X24X7.
This needs support. If you have an in house reponse team that knows
FOSS solutions, then thats good, otherwise you may need to buy
support. My Open Source friends tell me that Red Hat support is good
and is value for the money paid. Decide on support. Lord Murphy is
always watching. Depending on the level of in house support there may be some investment here.

– Staff training had to be spot on so that there is no excuses
to put up your hand and say `open office is too tough`. This is the
most important. Implementation will fail otherwise. Management will
be inundated by complaints of `non-working’ computers. In our
Hospital. Mr. Kumaran cleverly themed Cent-OS to look list Win7.
Most users tech-savviness ends are very `iconic`, so thats all that
will require.

What did we do ::
=================

– Even when we had the WinSystems I stood firm and never let the management invest in MS office. It was unnecessary. Complaints were many ranging from inability to open external files to difficult UI.

Some of the complaints, especially UI related were somewhat relevent, but I decided not to pay heed. These have settled down.

– Avoiding repeated investments to tide over a initial improper investment: The Pros kept telling us to invest in Teminal Server License but we stood firm. I kept telling the management that that takes away the advantage of cost and that I could run it better without any further investment by installing Linux. There needs to be a strong FOSS enthusiast in whom the management has trust. Otherwise the Corporate win.

– Kept to a budget: When we cut off all the frills like antivirus, firewall, terminal license we cut off all the recurring expenses.

Know what you want and buy only that. They will try to sell you more; thats their job. Let them do theirs, and you do yours.

– Choose your FOSS projects you wnt to implement: Now that you have got the courage to implement, use only well maintained and mature FOSS projects. We have Cent OS , Ubuntu, Zope & Plone, mysql, postgresql, dcm4che,JBoss – all mature and well maintained. For EMR you can use Open EMR, Open MRS, GnuMed, GNU-Health. There are several DICOM viewers you can use depending on the data you want : Oviyam, Mayam, Osirix(Mac), Aeskulap, GingkoCADx, inVesalius and many more. ImageJ is useful with its Java plugins for image analysis.

-Use the LTS version of the OS if possible. Install it on the staging system first. Train all the staff, get them to use it everyday and stress the system. This will give you an idea as to what kind of server you need now and when you expand in future.

– Training. It is important to train the staff. This is paramount. Our Admin Officer (AO) who also looks after IT complaints goes around doing all the minor trouble shooting and doubts. Once the staff realise work has to be done with this, they keep quiet and try to learn. We do Plone/Zope training many times a week. The software vendor and our AO do the Hospital Software training. The basic use of a Linux thin client interface has been taught. The theming is very handy for bridging the gap.

– Firewall. Set up a linux firewall and set up basic access rights to prevent unauthorised access to internet. Setup a secure Wireless. This will help access to Intranet, PACS, EMR over mobile and touch devices and also allow remote access.

Accept the Sore Areas:

===============

Medical Presentations: Right now its only MS office. Even Mac guys have trouble presenting many times; atleast in India. This will need users to use their personal MS office products to prepare their presentations. Sadly Libreoffice Presenter leaves much to be desired. It can do the basic .ppt export, but cannot be relied upon

Printer Support: This will need you to look before you buy. If you have expensive existing systems please evaluate. We could not use two network printers (Sharp)after switching over. They are both aged, so replacement is an alternative.

External DICOM applications: Many patients come with CDs with bundled DICOM viewer software. This may not work in Linux ; even under wine. Depending on the type of practice this may be a problem. In our current practice most patients come with printed films so it is ok. Some of the DICOM viewers open / the CDs can be opened with Aeskulap, but GE PACS cd usually dont.

.docx files: People send you MS Office files of all kinds. You cannot expect them to save it in a legacy format. Ubiquity of MS Office and Win make them expect a reply when the files are received. MS office 2007 – 2010 files are an issue. Simple ones open. Extensive use of animation, graphics causes improper rendering. Usually Office communications are bland letters which open without an issue. For academic presentation use, we suggest you rely on a personal copy of MS Office in you laptop.

Hopefully these basic guidelines will help people to switch. This is first hand account. That should be encouragement enough.

We have made it happen at our Hospital. It is comfortable. Transition has been very smooth with most users not even knowing the OS has changed. They only feel the computer is faster.

Please feel free to leave comments in case of any implementation queries.
As I said before watch http://kums.in for technical updates.