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
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
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
10.996636
77.007926
Like this:
Like Loading...
