Category Archives: EMR

My EMR Development in Django, jQuery and Dojo

#PySangamam presentation on #AuShadha done !


Had a lovely day at @PySangamam where I presented my experiences developing @aushadha_emr #ElectronicMedicalRecords or #EMR . Attaching below are some pictures of the event. https://t.co/hJteYzw822

I was pleasantly surprised on how open the crowd and organisers were to a talk delivered by a developer who’s primarily a doctor. It was organised beautifully and thanks specially Mr. Vijayakumar , Mr Abhishek and his team for all the encouragement.

Looking forward to #pysangamam next year at #Coimbatore , my home town

My Presentation : Creating Pluggable Electronic Medical Records

Git Hub : AuShadha Open Source Electronic Medical Records 

https://www.linkedin.com/feed/update/urn:li:activity:6443989732329394176

AuShadha 2.0 , a re-write of AuShadha Electronic Medical Records


I am happy to inform as promised earlier that AuShadha 2.0, which is a complete rewrite of AuShadha using Python 3.x, PostreSQL, Django 2.x and Dojo1.1x has been started and first major commit pushed.

Please find the repository at https://github.com/dreaswar/AuShadha2.0 

AuShadha 2.0 will use GNU-GPL Version 3.0 License.

PySangamam , the first Python Conference at Tamil Nadu


I’m excited to participate at #PySangamam the first Python Conference in Tamil Nadu at chennai Next month to talk on AuShadha EMR

via #Townscript https://t.co/xipWgkYQDF via @townscript
#Python
#Django
#webdevelopment
@aushadha_emr

AuShadha Electronic Medical Records Development update


AuShadha Electronic Medical Records at https://github.com/dreaswar/AuShadha has been seeing very slow development mostly due to pressures on my personal and professional front.

I could get back to development past few days and I have pushed a commit to master after some gap.

The Prescription App for Outpatient visits is ready.

Next stop is to implement Outpatient Reports.

Do check it out and let me know what you think.

You will need #Django1.7.2, #Python2.7x, #Dojo #Javascript Toolkit 1.13

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. 

Developing Pluggable Modules for AuShadha – Tutorial – PART 1


AuShadha Open Source EMR has been made pluggable – well almost. The au_pluggable branch is meant to make it more pluggable that it was in master branch.

Issues the monolithic AuShadha:

Well, when I started this I myself was new to Django and programming in general. I learnt as I coded and as can be expected, there were code everywhere and it was not very pleasant. So I rewrote the app in many times from ground up before AuShadha came into being. I was at that time building something for myself – to use at my orthopaedic clinic.

When AuShadha was started, it suddenly dawned that there are now people participating; people who have never seen this code, and who probably will be put off on the huge pile of code to digest. Since there is already a lot of code out there, it is difficult for a developer joining a project or someone who does not want the whole AuShadha package to develop , rehash or add packages to it. The entry barrier was very high. I also seemed to be re-creating one of the problems that made me start and EMR project; I had found existing ones tough to customise.

In an ideal world, EMRs should vary. Data collection varies from hospital to hospital, country to country and speciality to speciality and to some extent practioner to practitioner. Except for gross repeatable elements that can be swapped, most of the EMRs have to be different. However, many are not. Its not common in India to see EMRs used by hospitals that do not fit into the Indian way of data gathering and its unique Demographics and other regional specifics. Some EMRs do provide custom form generation to tide over this and some vendors do provide some basic customisation. The solution has to be more robust.

My own experience with getting them to do that for us was poor. This is probably because the code is hardwired and they could not accomodate out request for a feature change easily. From their side it would involve extensive recoding and debugging, man power requirement, that could not be afforded when the system is live at a Hospital.

The user should be provided a decent package out of the box with the option of switching out elements as he / she sees fit, to develop his own variant of AuShadha. This would be the ultimate goal.

Why this tutorial ?

It became quickly clear that I had to do something about it before the project grew. So about 2 months ago I created the au_pluggable branch in an attempt to modularise AuShadha. Thankfully Django encourages pluggable modules. This process was not very difficult; except for the difficulties created by my mangled coding earlier 🙂

The purpose of the write-up is to show developers and other enthusiastic people who want to develop / test out AuShadha how easy it is now to create their own mix- and – match AuShadha brew. There is still a lot of work, but as it stands the process is simple enough for somebody to follow. It is intended to show how easy it is to create modules for AuShadha without knowing the whole codebase that is already out there.

The tutorial would be written in parts. This is the first one.

So, let us start.

As I said, one of the advantages of the current pluggability model it that it allows user to swap in custom implementation of a particular module. All this while retaining the inherent structure of Django. This is important as developers who would get involved with AuShadha should feel that the skill they improve here is usable outside of AuShadha. Therefore the customisations have be done on top of Django with no patching of Django or any hacks.

First, let us familiarise ourselves with AuShadha module directory and file structure. After that we will create a pluggable module for use. For example, if the user wants his own implementation of the Demographics module overriding the stock version he / she will do it as below. The procedure for creating new modules will also be identical to this, which will be examined in subsequent post.

Of course if the reader dosent care and just wants to build a pluggable module for AuShadha using raw Django, then there is not problem. He can just build a regular Django-app and intergrate it as usual and expect it to work; well, after some little configuration. No XML I promise.

Basic AuShadha-app structure

The basic Structure of an AuShadha-pluggable module is typically seen in the patient app ( called aushadha-patient )

patient/
|– admin.py
|– aushadha.py
|– dijit_fields_constants.py
|– dijit_widgets
| |– __init__.py
| |– pane.py
| |– pane.yaml
| |– tree.py
| `– tree.yaml
|– docs
|– fixtures
|– __init__.py
|– LICENSE.txt
|– MANIFEST.in
|– media
| |–patient
| | |– images
| | |– js
| | |– styles
| `– README
|– models.py
|– queries.py
|– README.md
|– setup.py
|– templates
| `– patient_detail
| |– add.html
| |– edit.html
| |– info.html
| |– list.html
| |– summary.html
|– tests.py
|– urls.py
|– utilities.py
|– views.py

Typical AuShadha Application Structure and its contents

Typical AuShadha Application Structure and its contents

models.py, views.py, urls.py, admin.py, media/, templates/ are directly from Django’s own system. Nothing much custom here. Standard Django roles are served by these files.

Custom action is mostly in dijit_widgets/ and its contents, dijit_fields_constants.py, aushadha.py, queries.py, utilities.py

AuShadha uses a system of PyYAML to serialize and generate the UI for each app. Each app can configure the UI layout using Dijit (Dojo) widgets using this markup. Whats’ wrong with HTML ? Well, this is way more readable, we can still use the goodness of Django’s template engine and PyYAML’s python object and function calls including pickling and this reduces the JS files. This way there is less to debug and quick prototyping and customisation of UI is possible. The dijit_widgets folder contains:

Folder Structure and contents inside dijit_widgets folder

Folder Structure and contents inside dijit_widgets folder


pane.py, pane.yaml — > Django view to serve the ‘pane’ for the app. All customisation can be done in the corresponding pane.yaml using django template syntax / PyYaml syntax. It will be serialized as JSON and presented on request. This JSON will autocreate the UI. It is much more easier than using HTML with Django template for UI generation. Of course this traditional approach can be used just to generate Django forms and its validation JS code. This is what is done in the templates/ folder.

tree.py, tree.yaml — > Though not necessary for all apps, apps that do provide a tree structure to the UI can define this and use tree.yaml to generate the structure dynamically. Django template can be used as can PyYAML object notations. The JSON can then be passed to the client on request.

dijit_fields_constants.py — > (WARINING: This is going to be changed soon ) This hold the Python dictionary values for model form fields as Django ModelForm using Dojo/Dijit markup. This was before YAML became widely used in the project. This will be replaced soon with PyYAML markup like the Ui and this file may be moved into the dijit_widgets directory.

aushadha.py –> Every project when server is started creates a shared instance of AuShadhaUI class that lives in . This instance accepts registration of classes for particular roles they will perform in the EMR. Registration for the role and the class is done here. Each module is autoinspected for aushadha.py file on server startup just like admin.py file. The purpose for this is to create a role based central registry that registers classes for roles in EMR. This allow relative role based imports rather than path based module dependant imports allowing free module swappability. No more ImportErrors if that particular module is not present. For eg; if the patient module has been changed by say Author Mr. X and he has named it patient-mr-x and included in installed apps, along with a registration in aushadha.py for “PatientRegistration” role, as long as syncdb has been done, the class is picked up on first load and registered for that role overwriting the stock ‘patient’ app. All modules that need ‘patient_detail’ foreignkey do a relative import of the same in their models.py / views.py. This allows a Zope 3 like Interface like, Role based registrations allowing loose coupling. This is explained by me in my query to Stack Overflow here. Sadly, no answers came. So this solution has been rolled out. http://stackoverflow.com/questions/19100013/using-zope-interface-with-django

LICENSE.txt, MANIFEST.in, README.md, setup.py, docs/ are requirements to make this a python package. This will allow users to easing installation.

Having described the directory structure of AuShadha app and its contents, we will discuss the app creation from scratch in next part of the tutorial

AuShadha Open Source EMR moves to Django 1.5.1


AuShadha Dependency Changes:
========================

This is to infrom that AuShadha dependency list has changed. This has been necessitated to ensure compatibility with Django 1.5.1 and xhtml2pdf.pisa packages along with upgrades to ReportLab, PIL, South.

Anybody wanting to test out code in the “visit_experimental” branch need to setup a Python virtualenv and run the following from the AuShadha code main directory

Read more about it here… http://blog.aushadha.org/?p=24

ICD 10 CM Diagnosis Code parser in Python for AuShadha Electronic Medical Records Project


AuShadha Logo

AuShadha Logo

AuShadha Open Source Electronic Medical Records Project Update:

AuShadha is an electronic medical records project in Python, Django and Dojo.
AuShadha is getting ICD 10 Ready….  Just building an XML parser using elementtree module to parse the ICD 10 codes into a DB.

Know more about AuShadha at: http://facebook.com/AuShadha

Live Demo at : http://tinyurl.com/byaorgq

Dr.Easwar
http://www.dreaswar.com/

Hosted Live Demo for AuShadha Open Source Electronic Medical Records Project


AuShadha Logo

AuShadha Logo

Hosted Live Demo for AuShadha Electronic Medical Records Project

Finally my Open Source Electronic Medical Records using Django, Python, and Dojo has a hosted Live Demo.

This features the ‘master’ branch from Github.
Issues:

  • Initial screen load takes some times with un-styled display.
  • This will be fixed later.
  • Please take it as a prototype and explore and let me know.
  • Physical Examinations and Admissions management has not been integrated, will do it soon

Login as below:

username : demo_user
password : demopassword

URL:  http://powerful-earth-4121.herokuapp.com/AuShadha/alternate_layout/
Please leave your comments here.

Thanks,

Dr. Easwar T.R
http://www.dreaswar.com/

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.

Formatting Dojo Datagrid with values from many fields


How to Format a Dojo Datagrid with values from different fields: This is an post outlining this approach.

Documentum Cookbook

I faced an interesting problem today. I was using a dojo Datagrid and wanted to display a different value in “Author” column if the author value was empty. All the samples I came across on the net were simple formatter examples which dealt with a single column.
Finally I found that the formatter function call has an “undocumented” 2nd argument “rowIndex”. Once I had a handle to this rowIndex, I could retrieve all the fields in the grid row using var rowdata = this.grid.getItem(rowIndex).

var layout = [{
field: “a_content_type”,
name: ‘ ‘,
width: “20px”,
formatter: getIcon
},
{
field: “author”,
name: ‘Author‘,
width: “25%”,
styles: ‘text-decoration:underline;’,
formatter: getAuthor
},……

//You can name the arguments anyway you want.
//You can call this function getAuthor(writer, rowNum), Javascript will pass the values to your arguments when formatter is called.
function getAuthor(author, rowIndex){
if( dojo.string.trim(author) == “”) { //author field was…

View original post 27 more words

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.

AuShadha EMR Project listed at Medfloss website !


AuShadha EMR Project gets listed at Medfloss website

http://www.medfloss.org/node/806

Thanks Medfloss for the help in listing the Project !

http://www.medfloss.org/node/806

AuShadha Project is listed at Medfloss at http://www.medfloss.org/node/806

AuShadha UI is about to get a design make over – A Preview Mockup


AuShadha is undergoing a UI desgin makeover to fit into the present role. I had Open sourced my private EMR, so essentially I am stripping it of personal features and adding in the common use ones that will serve for a multiuser clinic.

Dojo 1.8 migration has already started and is currently in testing.

UI design for the pane controlling an admitted patient is as below. This is a mock up in inkscape and is likely to change.

Once the UI is finalised and Dojo 1.8 is tested locally, I will push it to github repo at http://dreaswar.github.com/AuShadha/

Please watch this space and http://facebook.com/AuShadha for further news on the project

 

AuShadha UI Mockup

AuShadha EMR project UI mock up

AuShadha Open Source Public Health Management EMR System at GitHub has a official logo


Image Image

LICENSE: Image

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License

AuShadha Project home: http://dreaswar.github.com/AuShadha/

What stops Open Source Imlpementation in Hospitals ? – A Poll


My Neurology Charter app in HTML and Javascript – Design Preview


An Neurology Charter app in Javascript and HTML.
As of now this is Standalone but this will be integrated into the EMR.
This is still very-much-beta. Design & Functionality will change considerably before I go final.

Neurological Examination App

Neurological Examination App

My Hospital runs Linux (OR) How we closed the Windows & Opened the Doors


The Great Dream …

This post is my dream .. or has been for about 4 years.

A day that my hospital runs on full Open Source Software.

First a little about me. I am a practicing Paediatric Orthopaedic and Spine Surgeon. I am a Open Source enthusiast. I started using Linux 6 years ago and for past 4 year I am using it almost exclusively at work and home. The only time I use Windows is for the odd gaming. I do Python programming – web & desktop.

When we moved into our new hospital premises, set up 2 years ago, to start on a good note and to save start up cost I set up an Open Source Intranet (Plone) and Open Source PACS for my use at the Hospital. I also started developing my own EMR project that I speak abt in this blog.

I dreamed that the hospital will implement an all Open Source Solution. I advised them likewise.

They seemed to listen. Then FUD (Fear -Uncertainty-Doubt) took over them:

How can we follow the advise of this Non-Professional ?

What happens if we have a trouble in future and then he cant help us ?

Where do you find the Linux certified guys to help you ?

What happens if Linux is sold off to come company and it becomes a paid?

(Yes, they did actually say that ).

So they sell themselves to the “Professionals” . Our Management was no different.

It was advised that our Hospital will need the best server, a professional firewall, latest antivirus, and all windows machines. Individual desktops were advised, even for Reception area ! . This along with the latest MS Office and all the great accompaniments. … It was not cheap – It was not meant to be. The offer looked really good. The guileless management was tempted to say ‘yes’.

Then they thought they’d double check with me, just in case.

The Great Deliberation followed.

One looked at the order, I chopped off half of it. Why do you need a comp with Core2Duo, 320 GB drive, 4GB RAM and Win7Prof  for Reception, Cash ?. All that they ever use to is to login to our Hospital Software.

I suggested all Thin Clients, Open Office, Linux on Server. Firewall with Linux. No antivirus software. Intranet with Open Source and Open Source PACS system. Desktops only for Doctor chambers and Media editing.

After mustering courage and ample dosage of FUD from the Professionals, Management decided on Windows Server & Win Thin Clients. They were whining all the while saying that my idea is ill advised. I suppose he would considering that I trimmed the budget at least 5 -6 lakhs of Rupees.

So it was going to be a huge server we may never use with features and specs that many small IT companies may not have or want or need or use : Sonic wall firewall, MacAfee antivirus, MS Office on all Desktops the list went on and on… There were ThinClients at all stations and Desktop at Doctors rooms and other important admin areas only. IT was Windows everywhere.

The Professionals offered to set up the Server with domains all the security stuff. It was bundled with the purchase.

Things had barely gotten off the ground after a year of struggling to set it up. Then a 2 year jinx started.

The Great Depression followed.

The Thin Clients which needed to work with only our Hospital Software (written in Java) needs Firefox. Most stations needed this software for the daily work. Even though we had purchased the ThinClients after testing with Firefox and our Software, after implementation it was horridly slow. CPU was clocking   100 % the moment we use the software on Firefox.

The ‘Pros’ blamed it on Thin Clients. They told Mangement we told you so. You needed Desktops. Buy it and it will run things smoothly. Blame game between the ‘Pros’ and the software vendor started.

They could not sort it out for over two years. Work at the hospital suffered. We needed to replace the Thin Clients at the high workflow areas with old desktops to that we could serve.

All the while I kept telling them you move to Linux it will be all right, but they needed a ‘Pro’ to tell them that. Of course, they would not. They tried to sell us more. After `considerable study` at their HQ and evaluation of the software, they said it will be all right if the server did all the processing and asked us to shell out more for the Terminal  License for Windows.

I put my foot down and said no. I said I could make it run smoothly under Linux if they wanted, so they had better come up with a better option.

Things dragged on with no news from them even after 1 year. The Management was frustrated. Then Windows cracked and light came through. The Management decided to Open the Doors.

The Great Revival followed.

Enter Mr. Kumaran (http://www.kums.in)

Cent-OS it was then for the main server with customised `really thin` clients. One week of testing with VirtualBox and couple of flashed thin clients and the Managements saw the light of what I was saying all the while. All processing at the server. Hospital Software is fast. Staff are happy. Work gets done. Management is happy. Work get done with no money spent.

Now we have fully converted. Printing is an issue because of the WinPrinters we had purchased. Luckily most of the are aging and needs to be replaced.

The Great Leap Forward …..

Open Source Intranet Platform

  • Intranet has been customised and installed.
  • Used everyday at our Hospital now.
  • It runs Plone with add-ons and custom scripts.
  • Currently we are `fitting the gaps`
  • Scheduled implementation is due next month.
  • Staff seem to like the concept and are getting the hang of it.

Open Source PACS

  • Set up and running at full tilt
  • Currently in testing.
  • Scheduled implementation in a months time.

Our setup now contains

  • A main Cent-OS Server serving the Thin Clients
  • A Desktop with Ubuntu 12.04 PACS Server (Staging)
  • A Desktop Ubuntu 12.04 Intranet Server (Staging)
  • A Desktop Ubuntu 9.04 Server for the Hospital Management Software Maintained by Software Vendor. We need to migrate this as it is aging.

So, what are we leaping to ?

  • Open Source EMR
  • Open Source ERP
  • and more…..