Archive for the ‘eHealth’ Category

An Opinionated Approach to OpenMRS Customization

This is my opinionated guide to OpenMRS (http://openmrs.org) customization for multiple sites, may work for a single site if developer resources are available. This guide is based on 3 years working with the UgandaEMR distribution (https://wiki.openmrs.org/display/docs/UgandaEMR+Distribution) for the Ministry of Health of Uganda, currently in 650 sites across the country (December 2017).

Background to OpenMRS 

OpenMRS is a electronic medical records solution, which runs on Java 8, Apache Tomcat 7 and MySQL 5.x (we are using 5.5 and 5.6). The solution is based on openmrs-core (the platform) and modules which extend the platform providing key functionality such as look and feel, REST API, data collection tools, dashboards, patient management workflows.

OpenMRS releases the Reference Application (RefApp) a collection of modules that showcases how the EMR can be setup for clinical workflows, and which is usually the starting point for implementations. The RefApp is released twice a year, April and October, with enhancements that are prioritized by the community and developed leveraging available resources.

I may be somwhat biased due to my role as Reference Application Lead from January 2017.

UgandaEMR

This is one of the nationally approved EMR solutions, which is being actively developed from August 2015, currently supporting HIV Treatment and Care including HIV Exposed Infants (babies born to HIV positive mothers), Safe Male Circumcision, Tuberculosis treatment, Maternal and Child Health (antenatal, maternity and post-natal care), Outpatient services among others.

Guiding Principles

This approach follows the list of principles below:

  1. Any distribution should only customize workflows, look and feel and provide metadata to the underlying EMR – any custom functionality belongs in the underlying core platform and modules. This rule means that the underlying code grows and evolves with time to meet needs of different implementations, may not be adhered to 100% but even 80% is sufficient
  2. “If you need to change the core, then you are probably doing something wrong” ~Daniel Kayiwa OpenMRS Core Contributor, which is probably true. There are multiple ways to skin a cat so skin it the “openmrs” way
  3. Use the OpenMRS SDK – this tool is what an SDK should be, allows you to create, run and test multiple variations and approaches using the openmrs-distro.properties file that allows the distribution to define and build its own war file and docker containers for shipping
  4. Leverage the new openweb apps (OWAs) approach to provide user interfaces with the REST APIs
  5. For concepts always refer to the CIEL dictionary (http://openconceptlab.org/) as your primary reference
  6. Contribute changes back to the platform and modules you are using rather than build your own – stand on the shoulders of giants, but feed them too so that they can grow stronger and carry others. This is a core opensource ethos
  7. Keep your distribution code public – share with others never know where the knowledge will come from. My personal technology experience has been that at some point in time, you will have to come out and find you missed alot of the magic
  8. Ask quesitons on design, approaches, best practices and collaborate with the community to grow your knowledge and others – Don’t build a wall fence around your house, raise your neighbors so that you do not need a wall fence

How to setup a Customization

  1. Setup OpenMRS SDK in your developer environment – by now you have figured that I love this tool
  2. Use the SDK to create a reference application module usually named openmrs-module-mydistribution using

    mvn openmrs-sdk:create-project -Dtype=referenceapplication-module

  3. Create a new OpenMRS SDK server following the steps at https://wiki.openmrs.org/display/docs/OpenMRS+SDK#OpenMRSSDK-Settingupservers
  4. Copy openmrs-distro.properties file from the server to api/src/resources for your module
  5. Add a build plugin in the omod/pom.xml folder such as below extracted from UgandaEMR
  6. <build>

    <finalName>${project.parent.artifactId}-${project.parent.version}</finalName>
    <plugins>
    <plugin>
    <groupId>org.openmrs.maven.plugins</groupId>
    <artifactId>maven-openmrs-plugin</artifactId>
    </plugin>
    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    </plugin>
    <plugin>
    <groupId>org.openmrs.maven.plugins</groupId>
    <artifactId>openmrs-sdk-maven-plugin</artifactId>
    <version>3.13.1</version>
    <executions>
    <execution>
    <id>build-distro</id>
    <phase>install</phase>
    <goals>
    <goal>build-distro</goal>
    </goals>
    <configuration>
    <dir>${project.build.directory}/docker</dir>
    <bundled>true</bundled>
    <distro>${project.build.directory}/classes/openmrs-distro.properties</distro>
    <batchAnswers>
    <param>n</param>
    </batchAnswers>
    </configuration>
    </execution>
    </executions>
    </plugin>
    </plugins>
    </build>
  7. Set your custom module to be watched by the server, so each time the server is started the latest version of the module is built and deployed also makes live reload of controllers and styling possible
  8. mvn openmrs-sdk:watch

  9. Add a .travis.yml file to provide integration to Travis CI a sample below
  10. language: java
    jdk:
    - oraclejdk8
  11. Traditional OpenMRS development approaches now follow 😉

More examples from UgandaEMR can be found at http://bit.ly/ugandaemr-technicalguide

In closing, these are my thoughts on how such customizations should be done, while they may need a developer available, they are bound to start the test of time.

Do share your thoughts and learnings from this and let me know how to improve, I may not be able to change though

Advertisements

UgandaEMR Bootcamp – Strengthening the Foundation for a National EMR

This article was originally published on the METS website at http://mets.or.ug/ugandaemr-bootcamp-2017/ with photos courtesy of Nancy Karunganwa (https://twitter.com/Kanandra26)

The week of November 20 – 24, 2017, was an exciting one for the EMR team at METS where we held the first UgandaEMR developer bootcamp, aimed at developing local capability to extend and build upon UgandaEMR. The end-goal was to have 4 new HMIS forms developed to be added to UgandaEMR by the participants, while building their understanding of the platform, how it works, and the software delivery process used by the METS team.

The blog post below is abridged in Twitter thread at https://twitter.com/ssmusoke/status/933970233261424641

Background

METS is the Monitoring and Evaluation Technical Support program a 5-year Centers for Disease Control (CDC) funded cooperative agreement, started in April 2015, led by Makerere University School of Public Health (MakSPH) as prime with University of California San Francisco (UCSF) as a sub-grantee. The aim of the program is to support Uganda Ministry of Health (MoH) with Strategic Information across multiple areas, one of which being the ability to leverage electronic medical records (EMRs) as the foundation for patient centered care starting with public health facilities.

From August 2015 to February 2016, the METS team embarked on updating an OpenMRS distribution, WHO Express, which was over 6 years old installed in about 350 public health facilities, to the latest released OpenMRS version as well as the the latest HMIS tools in ART care. In March 2016, the METS team started upgrades and training on how to use the new version of the EMR in Kabarole, a district in Western Uganda, with 20 sites. In May 2016, the first National Training of Trainers was held in Mbrarara with over 150 trainees, followed by an official rebranding of the OpenMRS distribution by MoH, to UgandaEMR.

Fast forward to September 2017, when METS released UgandaEMR 2.0.0 an upgrade from the 1.x series released in 2016, using the latest long term release OpenMRS platform (2.0.5) and Java 8, which is seen as the future foundation for the next 5 – 10 years.

The key challenge faced by the METS UgandaEMR team is that new features were not being added as fast as the implementing partners, MoH program areas and end-user facilities needed. This led to the concept of a bootcamp to seed the local tech scene with capacity to develop upon and extend UgandaEMR providing a key component of sustainability for the platform, through speeding up development of health tools needed by stakeholders.

The bootcamp with 20 participants, was split into 5 days, following the principles of agile software delivery, with focus on having usable forms by the end of the camp.

Day 1 – Problem definition and requirements gathering

To kick off the bootcamp was outlining of the expectations by the participants – most of which focused on learning about UgandaEMR, building on top of it and learning more about the software delivery process used to build the EMR.

The 4 HMIS tools to be developed in the week were introduced by a doctor from the METS team, building up an understanding of the purpose of the paper tools and how they are used within the context of a public health facility.

A parallel activity between the breaks of the tools discussion was setup of the development environment tools on participant laptops, which included MySQL/5.5, Java 8, git, maven, OpenMRS SDK, Intellij Community Edition & Visual Studio code that were to be used on preceeding days.

At the end of each day, the facilitators and participants had a “retrospective” looking at how the day went and what can be improved going forward.

UI Wireframe Showcase

Day 2 – Wireframing

The key challenge with digitizing paper records is how the paper tools are transformed to digital forms. The day kicked off with an overview and guidelines for UgandaEMR form design process at https://metsprogram.gitbooks.io/ugandaemr-technical-guide/content/form-management.html

The teams were handed pencils and paper, and with support from facilitators developed UI wireframes. After 3 hours of back-and-forth the teams were requested to show case their designs to provide feedback for each individual team but to also share learnings across all the teams.

Day 3 – Concept Management

OpenMRS Architecture Presentation

OpenMRS Architecture

This was the first day that the facilitators and participants delved into OpenMRS architecture and design, leveraging parts of a presentation “Health IT and OpenMRS: An Introduction

The idea was to introduce concepts and how the medical data is coded using concepts. Once the introduction was complete, the teams re-assembled to identifying the concepts needed for their forms following searching the locations below:

  • UgandaEMR concept dictionary
  • CIEL – a local instannce using the latest released concept dictionary
  • Identifying new custom concepts to be created

The discussion and modeling of the required concepts led to interesting discussions on differing approaches to handling repeated data capture dependent on the context of usage of the concepts. In certain cases we agreed to disagree about the models which would be tackled in subsequent iterations.

Day 4 – Coding HTML Forms

This was the long awaited activity, to see the forms come to life. Based on prior experiences, all laptops had setup and configured development environments.

The process copied from OpenMRS development guide was as follows:

  • Each team picked a single machine to work on
  • The team created a branch which was the HMIS number for the form being worked on by the team
  • An OpenMRS SDK  server named ugandaemr was created
  • The server was configured to watch the developement folder such that any changes to the forms would be automatically viewed following steps at http://bit.ly/2hWyAun

Once the initial form metadata was entered, with a quick primer on using HTML form entry tags, the teams worked leaving gaps where concepts were not yet defined.

The presentations were electrifying as the work for the whole week could be visualised. The approach to the team was the non-developer was to do the actual coding of the form, with the support of the team so as to slow down the “coding speed” to ensure all team members were active.

At the end of the day a working version of each team’s form was committed to GitHub and a pull request issued for progress monitoring.

Day 5 – Presentation Day

This is usually the most stressful day, however to make it fun the teams took the opportunity to self-organize in order of presentation, with a . number of constraints, teams decided the order to present, with opportunities being given to team members who had not lead any presentations during the week.

Dr Eddie Mukooyo, Ms Evelyn Akello with the best performing team at the bootcamp

This was to give all the team members an opportunity and to force the teams to prepare for the presentations.

A winning team was selected based on their presentation style, understanding of the HTML form being delivered and progress within the constraints.

Key Learnings

  1. The bootcamp was for 20 participants of whom 6 were female with a range of background from students of software engineering and Masters, software developers, M& E and public health practitioners
  2. The 5 days were not sufficient to complete working on the forms so the teams will work on their own with a planned follow-on activity to finalize for inclusion in UgandaEMR
  3. The positive feedback from the participants was with regard to the practical, collaborative and hands-on nature of the bootcamp, the learning experience of having to work within their teams which were randomly selected, balance brought to the teams from both the technical and non-technical members.

The event as seen by a little eye

Interactive discussions

Smiles and laughter to lighten up the day

Random selection of teams using sticky notes

Dr Eddie Mukooyo making closing remarks at the bootcamp on opportunity and expectations from the cohort of participants

Part of the METS UgandaEMR team with CDC Program Manager just after the first round of final day presentations

Group Photo – The first UgandaEMR Bootcamp participants and facilitators

National Digital eHealth Systems Maturity Model

My thoughts on this topic were fully crystallized at a WHO workshop to disseminate the Consolidated Guidelines on Person-Centered HIV Patient Monitoring and Case Surveillance, from June 18 to June 23, 2017, where one of the discussions centered on the state of national eHealth data collection and management systems.

My thoughts on this model, were firmed up by the discussion and sharing following the three-age system adopted by history, anthropology and archeology in organizing human events. The stages are:

  1. Stone Age – communities of 25 to 100 people surviving on hunting and gathering. Some communities evolved into having temporary settlements at opportune locations for economic activities
  2. Agricultural Age – permanent settlements varying in size from villages to walled cities. Increased scale of domestication of animals, planting of fields and use of tools for agriculture.
  3. Industrial Age – Replacement of hand tools by power driven-tools, communities coming together in governance, planning and resource mobilization. Learning and culture starting to blossom, and new knowledge being created

Now to map those models into national digital eHealth initiatives

  1. Stone age
    • Paper based tools for patient monitoring and reporting
    • Limited use of electronic medical records (EMR) coverage below 20% of sites
    • Where EMRs are available used as dumb data dumps to simplify mandatory reporting needs
    • Adhoc usage of data for facility care and program monitoring
    • Single disease support in EMR
  2. Agricultural age
    • Increased rollout and usage of EMR tools at patient service sites over 60% coverage
    • Disparate integration efforts and capabilities between different systems
    • Routine mandatory reporting well established
    • Routine data usage for patient care and treatment program monitoring
    • Initial efforts at system inter-operability over and above point-to-point system integration
    • Adhoc dashboards and data analysis outputs developed
    • Unique identification processes at initial state of establishment
  3. Industrial Age
    • At least 85% of sites have an EMR installed and routinely used
    • EMR systems cover at least 60% of clinical data available
    • Routine patient treatment and monitoring data generated, analyzed and summarized
    • Connections between systems done following documented best practices and protocols leading to development of health information exchanges
    • Dashboards and data analysis tools routinely used to display summaries at different levels
    • Well established, documented and routinely used unique identification
    • Data de-identification done regularly to provide data sets for analysis

Looking forward to hearing your thoughts … Where does your nation lie

OpenMRS Implementor Series 101 – Building a distribution package

I am not sure where this will end, however it is my way of giving back to the OpenMRS community that has provided an excellent learning platform and great support to me over the last 6 months, I have been using the software tools.

My intention is to share what I know, as a way of organising my thoughts and sharing ideas as I figure out where to add this to the OpenMRS community documentation, where it surely belongs. The flow of each of these posts will usually be to answer a very specific question that I have asked in the past, and where I think I have figured out an approach that seems to work.

UPDATE December 31, 2015: The new home for this blog post is  on the OpenMRS Wiki at https://wiki.openmrs.org/pages/viewpage.action?pageId=93358939 all further updates will be placed there

Problem Statement: How can I get an OpenMRS distribution that has all the modules that I need?

New to OpenMRS – What is Possible?

If you are new to OpenMRS and would like to see what is possible, then download the OpenMRS X.X Standalone Edition from http://openmrs.org/download/ which contains a pre-configured reference application with sample data that is ready to run in a single command.  This is note meant for production use as the embedded components are not robust enough for the growth in data collected.

Enterprise Installation like Reference Application

If the reference application provides all the modules that you need, the next step is to set-up n enterprise ready installation using a dedicated application server & database in which the Platform x.xx WAR (for Enterprise) can be installed. The modules for the reference application above can be downloaded as a zip file from the standalone edition above.

Full Control of Enterprise Installation

The last option is the most complex, and is for those implementors who want to install the enterprise edition but have control over what modules are installed or even what versions. In this case the OpenMRS distro platform is your best choice (https://github.com/openmrs/openmrs-distro-platform) which allows the building of a custom WAR file that includes the modules that you need.

The modules are defined in the pom.xml file and are accessed from the OpenMRS Maven Nexus repository (http://mavenrepo.openmrs.org/nexus/index.html#view-repositories;modules~browsestorage).

An addition to this project is for modules (pending review) but currently available at https://github.com/ssmusoke/openmrs-distro-platform is the ability to include custom modules (*.omod files) by dropping them in a folder called modules.

Please do share your comments on this style and let me know where it would fit best in the OpenMRS community documentation

 

OpenMRS Module Development Learnings – 102

My team mates and I are completing a number of OpenMRS workshops focused on improving our module development capability. This blog post captures the unwritten lessons that we have picked up as a way of giving back our lessons to help others in the community (and will be moved to the OpenMRS Wiki once the lessons have been internalized and consolidated, as that is its natural home).
The approach is based on the following OpenMRS community articles:
  1. Creating Modules – https://wiki.openmrs.org/display/docs/Creating+Modules
  2. Creating your First Module – https://wiki.openmrs.org/display/docs/Creating+Your+First+Module
As you develop the module it is important to keep testing and verifying whatever you do especially when the module involves user interface components, extending the OpenMRS UI. The process we ended up using was as follows:
  1. Setup a module using the module creation command line utility
  2. Downloaded Spring Loaded from its maven repository http://mvnrepository.com/artifact/org.springframework/springloaded
  3. Downloaded and setup OpenMRS standalone from http://openmrs.org/download/ picking a version greater than 1.11.x which supports debugging options
  4. Once the standalone version is installed, open the openmrs-standalone-runtime.properties and add the following variables to the vm_arguments: (should all be one line – separated here for clarity)
    • -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000
    • -Dmodule.development.directory={absolute path to root folder of the module}
    • -javaagent:{absolute path to spring loaded jar}
    • -noverify -Dspringloaded=inclusions=org.openmrs.module.modulepackage..* (note the two trailing dots before the *)
  5. Setup newly the module into an IDE (tested with IntelliJ & Eclipse)
  6. Installed a FileSync utility, RemoteSynchronizer for IntelliJ & FileSync (http://andrei.gmxhome.de/filesync/) for Eclipse
  7. Setup sync for the omod webapp folder into the standalone webapp folder located at WEB-INF/view/module/{modulename}
Our development workflow is smoothened out since any changes to Java classes & JSPs are automatically applied & reflected in the standalone app.
Additional Tips and Tricks
  1. Tomcat – Change the following init params in web.xml:
    • modificationTestInterval from 4 to 0, so that JSPs are automatically recompiled
    • development is true (this is the default)
  2. Intellij – the Java classes are not automatically recompiled on saving changes so there is need to run mvn package -DskipTests
  3. Follow the OpenMRS conventions as much as possible by cloning openmrs-core to see how the design of the interfaces, service layers is done. This will help get access to lots of the magic that happens behind the scenes.
  4. Java 8 will give you trouble, stick to 1. 7 as we did not try 1.6 anywhere.

Future of Software Development Industry In Uganda – 2015 Edition

These are my thoughts on the future of the software development industry in Uganda, after the official announcement of ThoughtWorks closure of the Kampala office (http://info.thoughtworks.com/Kampala-office.html).

I would like to approach this first of all by analyzing the contribution of ThoughtWorks to the Ugandan technology space, then what I see the future as.

ThoughtWorks contribution in two aspects – showing that its possible to run a pure-play software development business operation out of Kampala using Ugandan based talent, and the second providing an injection of new DNA into the local technology community. The exposure to international level processes, practices and projects have helped grow the experience of the local software development talent.

Local communities have been started & supported, included but not limited to Agile Uganda, Geek Night, Girl Geek Dinners (yay! Women in Tech), Rails Girls and Ruby Fridays. The OpenMRS community run a number of events to help grow its reach, while the Technology Radar discussions provided a continuous look into the present and future of computing. The contributions leave the local technology space different from three years ago.

What does the future look like? A tough question, and my answer is biased by over 15 years experience writing software in Uganda, my overbearing optimism, and my newly rekindled foray back into software development.

The future is bright, but can only be harnessed if the business and technology communities work hand in hand to grow the local technology capability. In this, a concerted effort to build a local technology practice with buyers pushing for a local component on all contracts leveraging open source. A good example is the Ministry of Health selection of OpenMRS (http://openmrs.org) as the EMR of choice for electronic medical records throughout the country with aggregate reporting done in DHIS2. There are lots of opportunities in leveraging technology in the agriculture and education sectors which remain new frontiers to be conquered.

I would further call upon the government entities and parastatals KCCA, URA, UMEME, NWSC to leverage OpenData approaches to provide the infrastructure for young innovators to build and monetize customer centric products and services.

Like Ghandi said, be the change you want to be in the world in this case “Coding in Uganda, for Ugandans, by Ugandans”.

Gakyali Mabaga (it is just the beginning)

%d bloggers like this: