Tag Archives: Python

#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 with AuShadha Open Source EMR – UI building with PyYAML – Tutorial – Part 3


Building the Dijit – UI with PyYAML markup and Django Templating

Get the PyYAML file from Git Hub Repo : get it here.

This is the file that generates the Patient Pane which is brought up after searching.

This is the UI it generates:

Patient Pane
This Patient Pane’s UI widgets, layout etc is partly generated from the PyYAML

This pane.yaml file is a Django template that leverages Django’s templating features as well as PyYAML‘s object mark up to generate a rendered JSON. This JSON is then returned on AJAX call to help the UI building. JSON is parsed by the Javascript file here to help build the Dijit UI, Widgets etc…

PyYAML file

Let us examine the PyYAML file markup

Comments and Verbatim Code

At the top, {% verbatim %} Django Template tag allow the developer to put some code / comments

 Declaring Variables

Variables that can be used all over the YAML file can be declared at the top. This is where PyYAML markup scores over Django Template. Django Template restricts variable naming and prevents you from doing Python stuff inside the template.  This is ok for most templates that output HTML where the relevent code can be put inside the views.py. However, for it is also convenient if the option exists on the template. PyYAML allows us to call random python objects, declare variables that can be used through the template, use aliases in YAML file and even instantiate Python objects. Coupled with Django Template, it can be used powerfully.

# VARS

Variables can be declared with the expected type just to be sure. Aliases created can be used like Variables throughout the YAML file. Of Course we can just use {{{<some_var>}} Django template variable to do the substitution as well without creating any alias. 

VARS:
  clinic_id: &CLINIC_ID
     !!int {{clinic_id}}
  patient_id: &PATIENT_ID
     !!int {{patient_id}}
URLS:

This calls the Django reverse method and allows calling with arguments. The results is stored as the PATIENT_PANE_URL alias. 

pane: &PATIENT_PANE_URL 
 !!python/object/apply:django.core.urlresolvers.reverse
 args: [ render_patient_pane_with_id ]
 kwds: { kwargs : { patient_id: *PATIENT_ID } }

Using Django {%url%} template tag, the code below can be rewritten more elegantlyas:

pane: &PATIENT_PANE_URL  # creates the Alias of PATIENT_PANE_URL    
    {% url 'render_patient_pane_with_id' *PATIENT_ID %}

 YAML Header and Describing the Layout of the UI, widgets inside each DOM

YAML Header describes which module the pane belongs to, what are requisite modules to be loaded before this loads and whether this loads on AuShadha start. This is something like a basicinformation about the pane.

# YAML

depends_on: [ search ] #Requires that the Search Module
load_after: search #Requires that Search UI should be loaded before this
load_first: !!bool False #Prevents loading this first explicitly

#Following markup start the description of the Patient UI Pane

id : PATIENT     #ID of the DOM Element

type : bc        # Type of Dijit Layout Widget this is bc = Dijit BorderContainer

title : Patient         #Title Attribute

url : *PATIENT_PANE_URL #The URL attribute which equals href of the widget

closable : !!bool True  #Whether the tab is closable

widgets: []             #Whether there are child widgets (exludes layout widgets)

panes:                  #Describes the child layout Panes / DOM Nodes

  - id: PATIENT_DETAIL_ACTIONS_ICONS #DOM Element Id of the pane
    type: dom                        #Says that this is only a DOM Node not Dijit
    domType: div                     #Specifies the DOM node type
    style:                           #Specifies the CSS styles 
      position: relative
      top: 10
      zIndex: 1000
      float: right
      width: 200px
      height: 1.8em
- id : PATIENT_TOP_CP            #Describes a Dijit Layout Widget DOM Id
 region: top                     #Region attribute of the widget
 type: cp                        #Type of widget cp = dijit ContentPane
 splitter: False                 #Splitter attibute
 url: *PATIENT_INFO_URL          #href attribute
 widgets: []                     #Contained non-layout widgets
 panes: []                       #Contained Dijit panes, DOM nodes
 class: topContentPane selected  #CSS class 
 style:                          #CSS styles
   height: 1.8em

The resulting PyYAML file can be parsed and UI created by the Javascript file. As you can see the method is easy and the markup is certainly more readable than an HTML file with Dijit declarative markup interspersed with Django template markup etc..

It can certainly be argued about the need for a PyYAML use when HTML can be used. However, to change a layout and to see switching layout / per -user customisation it is much easier to move the YAML blocks to and fro the nested levels than to switch HTML blocks with all the declarative markups. Of course we can use Django Template {% include %} to create a basic HTML file that will do the job. It is up to developer preference. I found this much easier on the eye.

The current limitation is regarding inline javascript. This can be solved through custom Dojo Modules using AMD loader. Dojo’s dojoConfig attribute allows runtime loading. The pane’sattribute can allow import of specifically needed JS modules / classes. This is a thought. I have not implemented this fully. However, the proof of concept of this exists at the Pluggable module aushadha_demographics_us tree.yaml file.

More on that on a later post.

Next Tutorial will be based on the core of AuShadha and its bundled apps

Developing Pluggable Modules with AuShadha Open Source EMR – Part 2


Creating a fresh application

For the purpose of this we will create a demographics application with data collection as done is USA.

The end result is available at http://github.com/dreaswar/Au-Pluggables

After activating the virtual environment run

$ python manage.py startapp aushadha_demographics_us --template AuShadha/app_template

This will generate the application scaffold and populate it with basic import stubs. The folder structure will be as described in the PART 1.

1. Creating the model, views and urls.py

The models will be derived based on the US Demographics requirements here:  Demographics

The model class inherits from AuShadhaBaseModel and the model form class will inherit from AuShadhaBaseModelForm class, which gives them some useful methods which they inherit.

Additionally, the AuShadhaModelForm class generates Dijits for display. The Dijits have to be configured in the dijit_widgets_constants.py file which is a python dictionary. This is will give the necessary Dijit declarative directives for generating the form widgets.

Once the models are done, the views and urls.py have nothing AuShadha specific about them. Basically we need views to add, edit, delete, view, json export the objects. The same can be represented in the urls.py

2. Determining the registration of roles

The aushadha.py  file registers the role of a particular class in the application. Roles are purely arbitrarily made up by the developer. However, if he needs to register a class for a particualr role that has already been registered, he will need to use the same name so as to override the preexisting class.

For eg> a PatientRegistration model may do the role of Patient Registration in the application. Hence this can be registered for that role. AuShadhaUI class generates an instance per server run and this registers the classes for a particular role on startup.

Registration can be accomplished inside aushadha.py as

UI.register(<class_name>, <role_name_as_string> )

3. Finalise the UI layout with PyYAML

Earlier in AuShadha developement, Django Template with HTML, CSS, and JS was used to generate the layout. This sometimes requires extensive Dijit declarative HTML markup that was not easy on the eye. Additionally interspersed JS and CSS didnt help.

Hence a method of returning the UI layout as a JSON was devised using PyYAML library. On JSON return, this is parsed and the UI dynamically generated using Javascript. This has dramatically reduced the JS files required.

The required PyYAML file is located in the dijit_widgets directory. The pane.yaml  and  pane.py  creates the necessary JSON

PyYAML directives are almost the same as Dijit declarative HTML markup except for the quotations and angled bracket distractions. I will devout an entire tutorial on this and how the JS file parses this. This is very early in AuShadha development so the markup, directive may change, but the principle is the same.

4. Study need for additional JS files

The add-on modules will have a media directory with sub-directories of js, styles, images  to house modules of JS, CSS and images. Dojo has the new AMD loader that encourages modular design and the dojoConfig variable can be changed at runtime allowing full flexibility to add modules as needed. This is demonstrated by the grids in the application (Contact, Phone and Guardian grid). The relevent module that should be called by the loader is specified in the pane.yaml under the grid directives as gridStrModule.

5. Integerate or install the application

The application itself needs to be added to the INSTALLED_APPS. Integrating the application (or installing ) requires changes in the settings.py to set the paths for templates, scripts, styles and media.  The Root urls.py needs to include the application as well. After the settings are done run syncdb to install the changes.

In case of Stock modules that clash with add-on modules, the stock modules will have to be removed, changes made to settings.py and urls.py to reflect this. This has to be done before syncdb is done.

The fully developed application for US demographics collection is at http://github.com/dreaswar/Au-Pluggables

Part 3 will deal with PyYAML and auto building the Dijit UI Widgets with PyYAML and Dojo

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

Dedicated Website for my Open Source Electronic Medical Records Project – AuShadha


AuShadha Website is live !

AuShadha Electronic Medical Records project written in Python using Django and Dojo Javascript library has now a dedicated website with integrated Wiki, Blog and Discussion Forum at http://www.aushadha.org/

Please visit and let me know the feedback.

Thanks,

Dr.Easwar

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 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/

Plone based Open Source Intranet Solution for Hospitals


As discussed in my previous post I have implemented an Open Source Intranet Solution in my Hospital, Ortho One Orthopaedic Speciality Centre, Coimbatore, India.

This is based on Plone. Customisation have been done to suit and hospital work flow. Necessary add-ons have been added to achieve the desired functionality along with custom scripts. Basic styling has been done to keep it simple and presentable.

Plone is served from an Ubuntu Server 12.04, 4GB Ram and 500 GB HDD. The processor is Core2Duo. This is a staging server. We may be shifting out once we have fitted the gaps and are ready to go live. That said the existing hardware serves well.

Here are a few screenshots:

Intranet Wall

Intranet wall for file dumping, discussions, chats, announcements.. even secret meetings !

Chat on Intranet.. Too lazy to create events, pages ? Chat away…

Staff Leave Calendar

Staff Leave Calendar

Intranet Login Page

The Login page…

Intranet Discussion Board

Discussion Board for the Intranet.

 

What stops Open Source Imlpementation in Hospitals ? – A Poll


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.

Contact Management App with Zope3 (Bluebream)


Am having a repository developing Bluebream (Zope 3) simple contact management application at BitBucket.

Its here: https://bitbucket.org/dreaswar/bbcontact/

Its just starting. I suppose pluggable modules can be created to make it like an ERP

Care to join ?

Django EMR , Dojo (OrthoDocx) – jQuery (OrthoEMR) comparative Interfaces


The entire application interface is basically a tabbed top and bottom container for Patient management.

Patient list grid is basically a list with Datagrid with a jsonRest store. The Django view will return the json. The row click will  fill the bottom tabbed panel with appropriate contact, phone numbers, email, guardian, admission and visit info for that patient.The double click will allow editions / deletion of the patient if the user has the permissions.

Application currently uses Django 1.4, PyYaml, PIL, ReportLab, PISA(html5lib) and Dojo 1.7.2

The icons currently being used are from KDE but that may change.

 

The second sreenshot is the comparative interface in jQuery. There is no bottom pane here. Left sidebar shows the context info on patient selection from the list. The Right sidebar is hidden if the screen resolution is below 1024 and shows itself on zooming out / clicking the icon at the top left.

This interface uses jQuery, jQuery UI and plugins for the table with heavy CSS and jQuery customisation.  The icons used are mostly from the tango project with a few from the silk collection for web. I have made some of my own. Some icons are just place holders and i need to work on them to make my own ones.

Image