Electronic Paediatric Admission Record (ePAR)

Moses Ndiritu Mphil, John Senga BSC, Naomi Muinga BSC, Mike English MD

What is ePAR?

To be updated and added

Where is it running?

1.     Thika Level 5 Hospital

2.     Embu Provincial General Hospital

What is the way forward?

Link this to the notes discussed in Dec 2009

Developing a Modular ePAR

Currently, the ePAR is made a single module with different controllers executing functionality that would be best handled as modules. Although easily maintainable and expandable, it is not easy for developers to work on distinct modules of the ePAR, which can then be ported, directly to the ePAR application and capable of being developed separately by developers responsible for different modules.

Proposed modular ePAR

The ePAR currently running has implemented most of the functionality below in controller scripts but it is desirable to separate this into modules that can be developed separately. The proposed modular structure will include the following modules:

1.     Registration module

2.     Clinical module

3.     Reports module

4.     Laboratory module

5.     Ward module

6.     Prescription module

7.     Decision support module

8.     Research module

9.     Outpatient module

10.  Printing module

11.  Pharmacy module

12.  Vital registration module

13.  Follow up module – for usual outpatient paediatric clinics

14.  Immunization module

15.  Data exchange module – via web services etc to meet needs of various stakeholders eg HMIS etc

16.  Communication module – to support M-health, emailing etc

17.  Note taking module – to allow daily review of patients and inclusion of notes in the system

18.  Discharge module

19.  System Administration module to administer users, electronic resources and rights

Distributed Development of ePAR

These modules cannot be developed by just one person in the long run and will require that different workers in different places and areas of interest be responsible for developing specific modules, which can then be ported into a single ePAR application that can be regularly released to the public.

ePAR Data Model

A simple data module with the most important tables should be agreed upon with a standard naming of fields and the table relationships. It should be such that data logic is not enforced at the level of the database but through model components of the Model Viewer Controller application. The current database structure will be reverse engineered to yield the model structure. This will not restrict the innovativeness of other developers wishing to extend ePAR but will ensure uniformity.

ePAR Architecture

As at the moment, ePAR shall be a distributed web-based application accessible on a regular web browser with support for cookies and JavaScript enabled and a portable document format (pdf) plug-in for viewing and printing of standard reports/forms where needed. The general structure of the ePAR will be underpinned by 3 components:

a)     A web server – Apache

b)    A database server – MySQL

c)     A Model View Controller (MVC) using a web scripting language – the PHP Zend Framework MVC

The choice of each of these applications is based on being open source and free, has friendly licensing requirements, currently run mission critical networked applications and have large and ever increasing community of users. In adopting a web-based architecture, it means that ePAR can be easily coupled up with other disparate networked components, such as electronic resource programmes for managing finances and human resources.

Deploying ePAR

We have worked out a cost effective way of securely deploying ePAR on a local area network (LAN) with a common server and user terminals in the wards, laboratory and other places in the hospital where ePAR requires to be running. Since it runs on a web browser, it means that any user connected to the LAN and with sufficient rights can access ePAR. In general, ePAR can be cost effectively deployed using the following software resources:

1.     A local area network of computers – cheap cat3e cables provide excellent connectivity with bridges across sites

2.     A Linux server – Ubuntu linux server

3.     A Linux desktop – Ubuntu linux gnome desktops

Our experience has shown us that these platforms, on top of being open source and free, are stable, generally virus free and can be used to harness controlled use in places like wards where computers require to be designated for particular use. The operating systems are also open source, free and have a large and expanding base of users.

Technical Document on developing a modular ePAR

Requirements & Skills

1.     A developer machine installed with MySQL, Apache and PHP preferably running a unix-type OS

2.     Basic understanding and ability to deploy an application on the ZF MVC

3.     Get and install Zend Framework MVC

4.     Install Zend Tool needed to create the preferred ZF modular application directory structure (however still not very uptodate)

5.     Ability to use command prompt

 

How to Create a Modular ZF Application

Creating a modular ZF Application can be a daunting task for a first timer, even for a user land developer who easily makes the straightforward non-modular ZF applications that do not use a bootstrap file (ie running only the default ZF module with several controllers).

To understand how to make a modular application has taken me a few days of thorough searches on Google and a lot of playing with code hours on the end.

Directory Structure of a ZF Application

Much of my insight on how to create a modular ZF application came from the tutorial by Jeroen Keppens at http://blog.keppens.biz/2009/06/create-modular-application-with-zend.html using ZF 1.8. It is still a very good starting resource but the directory structure (a variant of the conventional modular) may not work with ZF 1.9 and later. The Zend Tool is good for generating the structure of the directory but will generate what I call the variant-conventional modular structure below.

Conventional non-modular ZF directory structure

 

This is the conventional structure of developing a singleton application. An application in the present form cannot be ported into a larger modular application without some reasonable modifications to make it modular. Its use would have to be as an independent application connected to other applications within the same server through one or other possible means. Collaborative development and code reuse would require more time and effort with this structure.

Variant conventional modular structure generated by Zend Tool

Note that the default module is under the application directory and all the other modules will come under the modules directory. This is the structure generated by the Zend Tool and is not 100% modular since the default module exists outside the modules directory. The default module would not be easily portable to other applications unless it remains the default module for the other applications.

Then conventional modular structure below renders distinct applications capable of running independently and as part of a larger application with minimal to no code alteration. I will describe how to set up this kind of a structure for the modular ePAR application.

Conventional Modular Structure

 

Create a project using Zend_Tool

Make a directory within the web server or other folder holding the web applications eg ~/Sites on the Mac OS

Navigate to the new folder and create a ZF application project

Moses-Ndiritus-MacBook-Pro-15:~ mndiritu$ mkdir ~/Desktop/epar

Moses-Ndiritus-MacBook-Pro-15:~ mndiritu$ cd ~/Desktop/epar/

Moses-Ndiritus-MacBook-Pro-15:epar mndiritu$ zf create project .

Creating project at /Users/mndiritu/Desktop/epar

 

Add a default module to the project

Moses-Ndiritus-MacBook-Pro-15:epar mndiritu$ zf create module default

Creating the following module and artifacts:

/Users/mndiritu/Desktop/epar/application/modules/default/controllers

/Users/mndiritu/Desktop/epar/application/modules/default/models

/Users/mndiritu/Desktop/epar/application/modules/default/views

/Users/mndiritu/Desktop/epar/application/modules/default/views/scripts

/Users/mndiritu/Desktop/epar/application/modules/default/views/helpers

/Users/mndiritu/Desktop/epar/application/modules/default/views/filters

Updating project profile '/Users/mndiritu/Desktop/epar/.zfproject.xml'

 

Add an index controller to the default module

Moses-Ndiritus-MacBook-Pro-15:epar mndiritu$ zf create controller index index-action-included=1 default

Creating a controller at /Users/mndiritu/Desktop/epar/application/modules/default/controllers/IndexController.php

Creating an index action method in controller Index

Creating a view script for the index action method at /Users/mndiritu/Desktop/epar/application/modules/default/views/scripts/index/index.phtml

Creating a controller test file at /Users/mndiritu/Desktop/epar/tests/application/controllers/IndexControllerTest.php

Updating project profile '/Users/mndiritu/Desktop/epar/.zfproject.xml'

 

Add test action to an existing index controller of the default module

Moses-Ndiritus-MacBook-Pro-15:epar mndiritu$ zf create action test Index view-included=1 default

Creating an action named test inside controller at /Users/mndiritu/Desktop/epar/application/modules/default/controllers/IndexController.php

Updating project profile '/Users/mndiritu/Desktop/epar/.zfproject.xml'

Creating a view script for the test action method at /Users/mndiritu/Desktop/epar/application/modules/default/views/scripts/index/test.phtml

Updating project profile '/Users/mndiritu/Desktop/epar/.zfproject.xml'

 

 

Tweak the project folder structures

The structure created by the Zend Tool is the variant-conventional structure described above. It needs to be changed to the conventional modular structure by moving the models, controllers and views folders from the application folder to the default folder within the modules folder created. Remember to move the BootStrap.php file along with these folders to the application/modules/default folder. This (and the next step below) can be achieved using a bash script to automate the processes and produce the desired conventional modular ZF application structure. I have created such a script, which you can download and modify to fit your needs (www.viskenya.com/downloads/ePAR.sh).

 

Add Zend and Custom libraries

Copy the Zend library to the library folder of the project. At this time, other custom libraries can be added. The epar will use a folder Epar to hold all custom libraries/scripts that are needed to support the ePAR application. These will be named and accessed according to the ZF nomenclature system to avoid future redundancies as the ZF MVC develops.

Modify the application/configs/application.ini file

Much of the reasoning came from the report on a bug on this link: http://framework.zend.com/issues/browse/ZF-8377. I have copied the relevant parts in verbatim herebelow.

  1. Put all modules, including the default module, under a "modules" directory:

application/

         modules/

                 default/        

                 blog/        

                 news/

  1. Tell Zend_Application where to find the default module's bootstrap, and what it's named:

bootstrap.path = APPLICATION_PATH /modules/default/Bootstrap.php"

bootstrap.class = "Default_Bootstrap"

resources.frontcontroller.controllerDirectory = APPLICATION_PATH /modules/default/controllers"

resources.frontcontroller.moduleDirectory = APPLICATION_PATH "/modules"

resources.modules[] =

 

  1. Have Default_Bootstrap extend Zend_Application_Module_Bootstrap
    This strategy utilizes modules appropriately. Because the module bootstrap is now in a directory named after the module, the module namespace will be set properly (to "Default_"), which will allow the various resources to load under that namespace.
  2. Add the following to the application bootstrap if the Default_Bootstrap extends Zend_Application_Bootstrap_Bootstrap and not Zend_Application_Module_Bootstrap as above in 3

protected function _initAutoloader ()     {         $autoloader = new Zend_Application_Module_Autoloader(array(             'namespace' => 'Default_',             'basePath' => APPLICATION_PATH.'/modules/default'         ));         return $autoloader;     }

 


  1. Create a bootstrap file for each of the modules extending the Zend_Application_Module_BootStrap to allow autoloading of resources

<?php

 class Modulename_BootStrap extends Zend_Application_Module_BootStrap

{

 

 }

See link http://akrabat.com/zend-framework/bootstrapping-modules-in-zf-1-8/

  1.  

 

Test the application on a browser

http://localhost/epar/public

Add a LoginForm to the default module

Moses-Ndiritus-MacBook-Pro-15:epar mndiritu$ zf create form LoginForm default

Creating a form at /Users/mndiritu/Desktop/epar/application/modules/default/forms/LoginForm.php

Updating project profile '/Users/mndiritu/Desktop/epar/.zfproject.xml'