EAD Thesis -Design Principles for Extensibility - 86

8/3/2019 EAD Thesis -Design Principles for Extensibility - 86

1/86

Sheffield Hallam University School of Computing and Management Sciences

Design Principles for Extensibility: Detailed Technical Analysis of Extensibility of an Open Source Medical Record System

Upul Indika Godage

January 2011

A dissertation submitted in partial fulfillment of the requirements of the Sheffield Hallam University for the degree of Master of Science in Enterprise Application Development


2/86

i

Abstract

In enterprise application development a design is implemented to meet the user requirements. When

the user requirements change or when other users want new features the developers have to redesign

build, test and ship a new release. This is the typical software development life cycle. An extensible

system can change that.

Extensibility is the ability of software for future growth. Extensibility does not mean bloated software. It

means the software architecture is designed to incorporate mechanisms for extending the system with

new capabilities without modifying the basic system to satisfy new requirements.

OpenMRS is one such extensible system. It is a community developed open source medical record

system. It has been used to record patient data in the HIV treatment programs in Kenya, Rwanda,

Tanzania, multi drug resistant tuberculosis studies in Peru as well as for pediatric clinics in Indiana and

tuberculosis treatment clinics in Los Angeles, USA.The power of OpenMRS comes from the extensible

data model and the pluggable module architecture.

This research project will investigate and analyze the OpenMRS architecture and find out the keydesign

principles behind the extensible data model and the module architecture of OpenMRS.This research

with the empirical evidence from the extension developer community and analysisof the system and the

source code argues that following these technical and human factor principles the OpenMRS system has

effectively achieved an extensible design. This knowledge will help tounderstand and applyeffective

design principles on how to build extensible software to supportnew requirements without constantly

changing the systems.


3/86


4/86

iii

Extension Mechanism ............................................................................................................................. 20

Styles for Extensibility ............................................................................................................................. 21

Module Limitations ................................................................................................................................. 22

Extensibility in Other Platforms .............................................................................................................. 24

Other Medical Record Systems ............................................................................................................... 25

Design Principles Overview ......................................................................................................................... 27

Open Close Principle ............................................................................................................................... 27

Liskov's Substitution Principle ................................................................................................................. 27

Interface Segregation Principle ............................................................................................................... 27

Dependency Inversion ............................................................................................................................ 28

Derived Principles ................................................................................................................................... 28

Further Analysis of Design Principles .......................................................................................................... 30

Aspect Oriented Design .......................................................................................................................... 30

Single Responsibility Principle ................................................................................................................. 31

Generalization ......................................................................................................................................... 33

Key Value Data Model ............................................................................................................................. 36

Leverage and Reuse Existing Tools ......................................................................................................... 39

User Centered Design and Public Design Process .................................................................................. 42

Internalization from Inception ................................................................................................................ 43

Principle of Using Metaphor ................................................................................................................... 44

Use of Standards ..................................................................................................................................... 46

Security

from

Inception

..........................................................................................................................

47

Conclusion and Future Work ...................................................................................................................... 49

Bibliography ................................................................................................................................................ 52

Appendix A Project Plan ........................................................................................................................... 57

Appendix B Project Proposal .................................................................................................................... 58


5/86

iv

Introduction ........................................................................................................................................ 58

Literature Survey ................................................................................................................................. 60

Research Methodology ....................................................................................................................... 62

Gathering and Analyzing Data ............................................................................................................ 63

Ethics ................................................................................................................................................... 63

Outcomes of the Research .................................................................................................................. 64

Bibliography ........................................................................................................................................ 64

Appendix C OpenMRS System Artifacts ................................................................................................... 70

Module Folder Structure ......................................................................................................................... 70

Sample Module Configuration File ......................................................................................................... 71

Sample Module Application Context Configuration ............................................................................... 72

Appendix D Sample Questionnaire .......................................................................................................... 73

Appendix E Interview Schedule ................................................................................................................ 75

Appendix F Questionnaire and Interview Results .................................................................................... 76


6/86

v

List of Figures

Figure 1 The research wheel ......................................................................................................................... 6

Figure 2 The conceptual model to evaluate extensibility ............................................................................. 9

Figure 3 OpenMRS top level architecture ................................................................................................... 17

Figure 4 Privilege role model ...................................................................................................................... 23

Figure 5 Layered architecture ..................................................................................................................... 32

Figure 6 Person attribute model ................................................................................................................. 34

Figure 7 Presenting patient data in a generic column system .................................................................... 37

Figure 8 Extending the persistence layer and services layer ...................................................................... 40

Figure 9 Modules referencing core domain objects ................................................................................... 41

Figure 10 OpenMRS custom servlet directing requests to module servlets .............................................. 45

Figure 11 Extending as a portal container .................................................................................................. 46


7/86

vi

List of Tables

Table 1 Static table structure to record patient data ................................................................................. 36

Table 2 Generic columns to record patient data ........................................................................................ 36

Table 3 Giving labels in the user interface level ......................................................................................... 37

Table 4 Key value data model ..................................................................................................................... 38


8/86

vii

Acknowledgements

I would like to thank all the people that had helped me through my masters. Special thanks to my

supervisors,ProfessorJawed Siddiqi and ProfessorChristopher Bates. Thank you very much for your

patience and guidance.Also I would like to thank all the lecturers and the staff.

I would like to thank Ben Wolfe, Project Manager of Regenstrief Institute, for welcoming me into

OpenMRS and helping me out in all occasions. Without your help I would have achieved nothing. Thank

you very much.

I thank the OpenMRS community including developers, implementers and users worldwide who have

built a great product helping the humanity fight against deceases and an active and friendly open source

community around it.

Last but not least, I would like to express my gratitude to my parents and all my friends forthesupport

and encouragement.


9/86

viii

Glossary

AMPATH Academic Model for the Prevention and Treatment of HIV/AIDS

AMRS AMPATH Medical Record System

AOP Aspect Oriented Programming

API Application Programming Interface

CDC Center for Disease Control

CJK Chinese Japanese Korean

CSV Comma separated Values

DAO Data Access Object

EMR Electronic Medical Record

ERP Enterprise Resource Planning

HL7 Health Level Seven

IDE Integrated Development Environment

MMRS MOSORIOT Medical Record System

OCC OpenMRS Concept Cooperative

PEPFAR President's Emergency Plan for AIDS Relief

SaaS Software as a Service

UI User Interface

WHO

World

Health

Organization


10/86

1

Introduction

Extensibility in Context

In typical enterprise application development processes the analysts and the users discuss and agree

upon on a set of requirements. Then the developers design a system to fulfill those requirements. Finally

they build, test and release the software to the users. When the user requirements change or when

another client wants a similar solutionwith some custom features the developers have to redesign,

build, test and ship a new release.This is the typical software development life cycle.

Users have different requirements even if they are in the sameindustry. For example clients who are

looking for a travel management system will require connecting to various hotel reservation systems,

train, flight, taxi reservation systems. The clients who are looking for a billing system will need to

connect to different payment gateways and they will have different tax calculation requirements. The

above extensibility requirements are relatively predictable and straight forward. Moving further the

future requirements can be more complex and unpredictable such as capturing and storing additional

data and creating reports with the aggregate data. It is impossible for the developers to guess all the

future needs of the user community or to foresee the environments in which the software will be used

in.

Enterprise software developers try to design and develop software targeted for the majority of clients in

the vertical markets such as accounting, logistics management, inventory control systems etc. When a

client requests a new feature the developers ship a new release building up the portfolio of features of

the product. Typically these software systems incorporate methods for user customizations in a limited

manner. Most of the time users have to adjust their existing processes to streamline with the software.

One approach used by the contemporary information systems designers according to the authors

personal experience and the people interviewed, is incorporating all the features into the system and

providing a feature enabling mechanism at build time or at run time according to the customer. The

advantage of this approach is that when the feature set is limited and is straight forward to implement

this method is the obvious method to design from the developers point of view. From the views of the

interviewees it was came to notice that many systems use this approach because the systems are

developed organically instead of using a systematic approach to design.


11/86

2

It was said that one of the main reasons for this approach was the urgency of delivering the features

instead of taking time to develop the system using good design principles. But most interviewees agree

that although this approach gives quick results in the short term, they will have to undo these quick fixes

when the requirements become more complex and more diverse. When investigating the source of this

particular medical record system it was evident this kind of quick fixes exist. And it was also evident that

later development work are related to removing these quick fixes with permanent solutions that are

extendable and the developers try to generalize these fixes so that they can be usable by a more generic

user base to support future requirements.

The ability to handle unforeseen changes and future needs easily is an important quality of software

especially for software which is developed for vertical markets. Having a single well tested system to

handle many clients requirements reduces the cost and increases the profitability of the software

development business exponentially. That is why extensible software is important.

Extensibility in software means the ability to add new functionality with minimal effort. An extensible

system can support future requirements without changing the base system. Extensibility does not mean

bloated software which incorporates all the known user requirements in a single bundle so that each

user will use a subset of all the features. Extensibility means the software architecture is designed to

include mechanisms for extending the system with new capabilities without making changes to the base

system to satisfy new requirements or work in new environments.

Designing an extensible architecture is a bit of a guessing game. The designersare anticipating the future

usage scenarios and requirements that do not exist today and are designing a system architecture that

can support those changes.

Aim of the Research

The aim of the study is to investigate and formulate the key design principles behind the extensibility of

OpenMRS architecture. To achieve that objective this research will gather the empirical evidence from

the extension developer community and analyzethe system and the source code to argue with

observations that following these technical and human factor principles the OpenMRS has effectively

achieved an extensible design.

This knowledge will help to understand the effective design principles needed to build extensible

enterprise applications to support new requirements without constantly changing the software


12/86

3

systems.One objective in coming up with these design principles was to make them specific and

concrete enough so that they can be applied in real world enterprise application development scenarios

effectively as best practices but generic enough so that they can be applied in any industry not specific

to the medical record systems.

By following these distilledprinciples the author hopes that the software architects can come up with

lean and extensible systems that would withstand the future requirements introducing minimal code rot

or software entropywithout feature bloat or without major system reengineering efforts later in the

lifecycle.

Because the content in the initial project proposal was too broad and extensive, the research project

was narrowed down into identifying the specific technical and human factor design principles for

extensibility

in

the

OpenMRS

architecture.

Extra Project Work

During my study period I have contributed to the OpenMRS project through the Google Summer of Code

program in 2008and as an intern in the OpenMRS Internship Program (OIP) in 2009. Since then I have

been involved in the OpenMRS project as a voluntary contributor.

Road Map

First the dissertation will describe the research process that was followed, how the data were gathered

and the conceptual model used to analyze and extract the key design principles. Thenit will give an

overview of the OpenMRS and the module architecture to a considerable extent as the extensibility

principles reside inthe module architecture and the key value data model. Then it will evaluate and

discuss the identifieddesign principles one by one that are the basis for extensibility in the system in

detail using evidence from the system and the interview findings. The dissertation ends with

summarizing the distilleddesign principles and further work.


13/86

4

Research Methodology

This chapter will discuss the research methodologyselection, how the data were gathered and the

evaluation criteria model that was usedto analyze the data.

Approach

It is said that the research process is like an hourglass. It starts from the general questions. Then the

process narrows down to focus on specific aspects of the research problem. Finally the conclusion

generalizes the results in relation to the real world. This research will discuss about the extensible

software architecture, formulate some keydesign principles used in the OpenMRS architecture and then

describe the evidence acquired from the researchpertaining to these design principles inthe OpenMRS

software architecture.

Before starting the research, the research methods were investigated to find a suitable methodology. A

research methodology defines how the research should be carried out. There are many methods

practiced by the research community including experimental research, quasi experiments, action

research and ethnography (Gill & Johnson, 2002). The chosen method depends on the nature of the

research project.

Qualitative research and quantitative research are two main schools of thought in to the research

process. In the study of mathematics, chemistry or physics experiments are quite easy to comprehend

by defining the independent and dependent variables, operationalizing the fuzzy concepts and coming

up with scientific measurements. Quantitative research concerns about systematic scientific

investigation of quantitative properties and their relationships. Quantitative approach could focus on

the use of large scale survey, using methods such as questionnaires or structured interviews as in the

marketing field.

On the other hand qualitative research focuses on experiences, attitudes, observations, behaviors,

motivations, aspirations, value systems, concerns, culture or lifestyle. Qualitativeresearch approach is

less concrete than pure numerical data. It does not rely on statistics and numbers. It would yield

descriptive results through interviews and observations.

Qualitative implies that the data are in the form of words as opposed to numbers. There is more

emphasis on description and discovery and less emphasis on hypothesis testing and verification, as the


14/86

5

qualitative researcher seeks a psychologically rich, in depth understanding of the individual(Rudestam &

Newton, 2001).

Further Rudestam & Newton, 2001 states that qualitative research methods share three fundamental

assumptions.

1. A holistic view the whole is different than the sum of its parts.

2. Inductive approach it begins with specific observations and moves towards the development of

general patterns that emerge from the cases under study.

3. Naturalistic inquiry it is intended to understand phenomena in their naturally occurring states.

In this chosen topic the aim was to find out the key principles behind the extensibility of software

architecture in OpenMRS. Looking at the above three points it is much more suitable to approach the

subjectas a qualitative research as the outcome is focused on analyzing the system and extracting the

key design decisions behind the extensibility of the software system.

Another approach to view the research methodology is whether the approach is inductive as mentioned

above or whether the approach is deductive (Rudestam & Newton, 2001). Inductive research is based on

inductive thought or reasoning which transforms specific observations into a general theory. The

researcher observes patterns and conducts surveys or experiments to verify the validity of the concepts

and thus reach a conclusion. Deductive research is based on deductive thought which transforms into

specific hypothesis suitable for testing. The researcher may have a particular hunch, a phenomenon and

try to collect data to prove it is right or wrong. In deductive research firstthe theory is put forth in the

form of a hypothesis and then selects a method by which to test it. If the data supports the hypothesis

the theory is correct. This project is approached in an inductive style gathering data and coming up with

the themes related to extensibility. The themes are formed and molded during the research itself into

design principles.In this case deductive research is not suitable because it is not possible to know the

design principles from the outset but they emerge as a result of the research itself.

The research can be visualized as a research wheel(Rudestam & Newton, 2001). That means the

research process is a recursive cyclic process and is not linear. The following diagram illustrates the

research wheel.


15/86

6

Figure 1Theresearch wheel

In this case the research question is what are the technical and human factor design principles that can

been seen in the OpenMRS architecture for the basis of extensibility.The research cycle goes through

two paths. That is data collection followed by data analysis and the observations followed by

proposition. This research was carried out in an iterative manner in two ways. That is analyzing the

system architecture, the source code and the available documentationand asking the question how did

they design the architecture extensible to support these requirements, andsecondly by open discussions

with the developers who were available to refine these answers into design principles further. As the

time progresses the themes formulated by the research are generated, modified and sometimes

discarded until a set of core principles were derived.

I have been working and contributing to the OpenMRS project during this period while studying and

analyzing the system. The majority of the time was spent on analyzing and evaluating the source code

and analyzing how the OpenMRS developers have designed the base system with the extensibility in

mind. The main objective of the investigation was to find out and itemize the most salient design

principles behind the extensibility of the system.

According to Rudestam& Newton, 2001 there are two kinds of skills necessary for the research process.

That is,

Proposition

Data analysis

Conceptual framework

Data collection

Research question

Empirical observation


16/86

7

Knowledge by description learning in a passive mode such as reading a book.

Knowledge by acquaintance learning by doing such as driving a car.

While doing this research in addition to reading and analyzing the OpenMRS source, I have worked in

developing extensions for OpenMRS as well as adding new features and enhancements to the core

OpenMRS system.

One important fact was that the tasks that were performed were not constricted purely for educational

or academic purpose such as developing extensions as prototypes but wereapplicable in true use cases

applied in practical situations in real scenarios.So this gave the research a practical perspective into the

workings of the architecture. The development contribution I made during the project is being used

around the world in implementation sites in African and South American countries in fighting epidemics

and

deceases.

So the research was carried out by iteratively evaluating the OpenMRS architecture, analyzing the

source code, gathering data from the existing extensions and analyzing them against the conceptual

model presented later, and carrying out interviews and open ended questionnaires with the selected

developers. The following sections will describe the tasks in more detail.

Interviews and Questionnaires

OpenMRS community are scattered all around the world. Mainly there are three kinds of members in

the community. These are the developers, the implementers and the users. The developers develop and

test the software. The implementers are the people who install and administer OpenMRS software at a

site usually at a hospital or a clinic. The users are the people who use the system day to day in their

jobs. The same person can play all three roles. Typically many developers play the role of the

implementer. Also the developers can be roughly divided in to the following categories. Core developers

are responsible for developing and maintaining the base system. Module developers own specific

modules which are extensions or plugins. Also there is a community of contributors who provide

patches

and

support

to

the

user

community

voluntarily.

I had open discussions with some of the core developers on where to look for in the source code to get

some pointers in the design for extensibility. To investigate further I selected around thirty people

encompassing the developers, the implementers and the users of the OpenMRS community. About 2/3

of the sample were the developers from which 1/3 were core developers. Two users who were closely


17/86

8

involved in the day to day discussion were also selected for completion. They were all asked an open

ended questionnaire listed in the appendix. The questions were a starting point to acquire their

experiences extending OpenMRS core system and what strong points they saw in OpenMRS when

customizing and extending the system with modules, what were the weaknesses and shortcomings they

found. The responses were lower than I initially expected. The responses were analyzed and aggregated.

The respondents were followed up for further discussions to understand the extensibility points in the

OpenMRS and get clarifications.

The appendixesQuestionnaire, Interview Schedule and Interview Results listthe samples and a

compilation of the extensibility features and limitations according to the surveyed participants. Note

that the results are used in explaining the design principles in the Further Analysis ofDesign Principles

chapter.

Analyzing the Source Code

OpenMRS is an open source software project licensed under the OpenMRS public license which is

derived from the Mozilla public license. So the complete source code is available on public servers

accessible to everyone (OpenMRS Source Code, 2010).

The source code is well maintained and easy to comprehend. The source code repository contains the

base source code and a separate directory structure for modules or extensions. There are nearly 200

modules

available

with

the

source

code

at

the

moment

covering

features

from

adding

dynamic

database

backup tasks, advanced report generation tools to adding a graphical HTML form designer to the base

system and adding user specific features. The module repository contains the modules releases

(OpenMRS Module Repository, 2010).

Also there is a wiki with OpenMRS documentation on different subjects. They were helpful to

understand how the OpenMRS worked. But there were no design documents describing the initial plans

and discussions. The system has mostly evolved over time organically. The product documentation is not

comprehensive and does not get updated often (OpenMRS Documentation, 2010).

Gathering Data from the Public Module Repository

Module repository is the central distribution point of OpenMRS extensions that have been written by

various developers over the years. When gathering data about how the developers have extended

OpenMRS, this was the main data gathering point for the research. By analyzing the modules and the


18/86

9

source code it was possible to evaluate how the OpenMRS system has been extended for different

purposes by different people.

On the other hand the module repository hosts only the modules that are released under the open

source

license.

The

owner

has

to

agree

to

the

license

before

uploading

a

module.

So

there

is

the

possibility that some party could have written a module to fulfill their own needs that has not been

released to the public. But according to the OpenMRS developers there has not been any recorded

instance of such a privately held module development or use because most of the projects which are

using OpenMRS are run by publicly funded programs and volunteers. In fact most of the interviewees

were the authors of these modules.

Conceptual Model for Evaluation

While analyzing the modules a framework model was needed to understand what the purpose of the

extension and how it interacts with the core architecture to act as a seamless single unit.The following

diagram illustrates the evaluation model that was used to analyze the extensibility points in the

OpenMRS system.

Figure 2Theconceptual model to evaluate extensibility

Business Logic /

Services

User Interface

Publish Events /

Output External Events / Input

Data Model


19/86

10

This conceptual model describes the key areas where developers focus on when extending the base

system. The OpenMRS core system can be thought of as the infrastructure and the skeleton. The

extensions plugs into this model to provide or enhance the services. This model analyses the points

where the extension developers focus on when designing their extensions. Every extension is a

composite of the elements in this model. Each extension can be disassembled into constituent

components in these elements for comprehension. Then it is easier to understand how the extensions

interact with the base system, how they acquire services and how they provide new features.

For example when integrating the OpenMRS system with an external system to directly insert patient

data to the system skipping the web interface, the developers will be working on the external events or

input area. The extension will add new behavior and logic to the external events or input segment of the

system. When the developers want to amend the patient table with their own custom tables they will

be focusing on the data model area. In that case the new functionality will be mixed with the existing

data model segment.

Most of the extensions cover one or more blocks in the model. For example Access Log Module

(OpenMRS Access Logging Module, 2009) covers the user interface, the services and the data model

areas. Access log module audits the patient record modifications. So it will add new user interface

elements to view and manage the access logs, the services to access and save the logs and the data

model to persist the access logs.

Approaching the system in this way is similar to the functional model or data flow diagrams (Yourdon,

2006) in the structured systems analysis and design methodology that was popular before the object

oriented technologies became popular.The reason for having a reference model such as this is that

when analyzing an extension it is possible to see the fundamental elements of the extension without

getting lost in the complex functionality provided by the extensions to support different user

requirements.

The following sections will describe each part in the diagram in further detail.

User Interface

Users will need to add user interface elements or modify the existing elements according to their needs.

For example users may need to change the home page after a user logs into the system to show a

customized home page according to the roles assigned to the user instead of the default homepage as in

the role based homepage module (OpenMRS Role based Homepage Module, 2008). At the moment all


20/86

11

the extension points where developers can plug in their customizations are associated with the user

interface elements. But the extension points can be defined for other layers.

Business Logic / Services

Users

will

need

to

add

new

services

that

are

not

supported

in

the

base

system

or

modify

or

amend

how

an existing service behaves. For example ID generation module adds unique ID generation services to

the base system (OpenMRS ID Generation Module, 2008). So the extension developers can create new

services in the services layer and run them in the container as same as the core services. Mainly new

services are defined using the module Spring bean configuration while existing services and business

logic are modified using the aspect orient programming mechanism described later.

Data Model

Users will need to add or amend the existing data model with new data structures. For example Sync

module keeps the data in two separate OpenMRS instances in synchronization(OpenMRS Sync Module,

2010). The extension developers can create new tables and data sources in the data layer and host them

in the container as same as the existing core data objects. Typically custom Hibernate mappings are

used to extend the data model as described later.

External Events / Input

Users will need to accept and react to events or messages or import data from external systems. For

example JAX WS Web services module exposes the OpenMRS API through the SOAP services (OpenMRS

SOAP Web Services Module, 2009). In this case the JAX WS module fits into the input element in the

conceptual model exposing the service elements in particular, API in a different medium than the

default Web user interface.

Publish Events / Output

Users will need to publish messages or events according to the internal events or communicate with and

export data to external systems. BIRT Report Module exports data for external report applications

consumption (OpenMRS BIRT Report Module, 2010). In this case BIRT report module fits into the output

element in the conceptual model.

So this conceptual model helps to understand the extensions in the context of extensibility. When

investigating the extensions to see how the core architecture has helped the developers to extend the

system this model give a reference model. In a monolithic system all these elements are handled by


21/86

12

theapplication by itself. In an extensible system the new extensions fit into these elements in the model

to extend the base architecture.

Limitations of the Research

This research was carried out mainly in the context of a particular open source medical record system.

Although the resultant design principles derived from the research are valid for any enterprise

application not limited to medical record systems, their applicability and priority could vary according to

the field and the nature of the system.Also this research was conducted by one person. Therefore the

investigation and the research findings may be affected by the views and preconceptions of the author.


22/86

13

Literature Review and Initial Analysis

Extensibility

Extensibility is the ability of software for future growth. It is the ability of a system to extend with new

requirements and functionality with minimal or no modificationsin the core architecture.Software must

stay soft, malleable. The discipline of extensibility is the tool which best helps us achieve this(Kelly,

2002). According to Kelly, 2002 extensibility works because it forces an approach to problems based on

the following ideas.

1. An upfront design which allows for addition.

2. Additions to be made in small, incremental steps.

3. Work elements to be separated into comprehensible units.

So designing modular systems,which consist of core architecture and incrementally developed small

units, is a major approach to architecting extensible systems instead of conventional monolithic

systems.

Monolithic Systems vs. Modular Systems

This section will compare the conventional monolithic systems against the modular systems such as

OpenMRS. Wolfinger, 2008 describes the issues with the conventional solutions which cram in all the

features users ask for a monolithic application.

In this one size fits all approach the users need only a subset of features but they have to navigate and

use complex and feature rich systems. Eventhough the application tries to cater for every user it is

impossible for an enterprise application of any size to meet all user requirements in a single standard

product. There is always some variations that cannot handle by a standard product. Enterprise users are

conservative about deploying new patches and releases. But when having a single monolithic application

every user has to face the same deployement process. It is difficult to perform a selective patch

deployment for the specific users. A monolithic application is harder to customzie or adapt to specific

users. Also it is difficult integrate the system with third party applications easily (Wolfinger, 2008).

But there are advantages in monolithic applications compared to modular systems. The developer has

total control of the application and the behavour. Also monolithic systems eliminate integration issues.

A large part of issueswhich the developers face according to the authors experience are due to

integration of different modules and third party components working together.


23/86

14

Wofinger, 2008 points out some of the issues with modular architectures. How can we support end

users at run time to adapt an application to changing working scenarios? How can we automate the

integration of plug ins? How can we provide guidance for software architects on designing customizable

and extensible plug in applications? And how can we make contract specification more effective and

easier to maintain? How can extensible applications take precautions against being taken down by a

flawed or malicious extension? How can extensible applications constrain the permissions of plug ins?

These are important issues faced by the developers when designing an extensible system. It is hoped

that this research will answer the question, how can we provide guidance for software architects on

designing customizable and extensible plug in applications.

Plug in systems are inherently very complex. Different plug in architectures have tackled the problem to

different extent. Some architectures need to restart the whole system to effect any plug ins while

others can hot deploy the plug ins instantantly. One of the most difficult problems faced by the

extensible system designers is the inability to change the system after it has been released to the wider

community or preserving backward compatibility. So it can be seen that the modular systems solve

many problems as well as introduces new challenges.

Medical Record Systems

There are different types of medical information systems ranging from clinical point of care (POC)

systems to public health information systems for disease surveillance and strategic decision making

(Weber Jahnke & Price, 2007). Electronic medical record system or EMR is a computerized information

system which stores, retrieves and manipulates medical records of patients in a hospital or such an

organization that delivers health care.

Several literature sources discuss the attempts in successful implementation of medical record systems

in different parts of the world using different technologies(Lober, Wagner, & Quiles, 2010)(Hannan,

Rotich, & Odero, 2000)(Rotich, Hannan, & Smith, 2003). Basically it is possible to group EMR system into

two categories. That is commercial EMR systems used in hospitals especially in the developed countries,

and the open source EMR systems developed by communities to improve the healthcare in developing

countries. According to the above sources the common challenges for the community developed EMR

systems are scarcity of resources, low level hardware availability, frequent power outages and

inadequate Internet access and support.


24/86

15

Overview of OpenMRS

OpenMRS is a community developed open source medical record system. The project is led by the

Regenstrief Institute and the Partners in Health organizations and funded by the World Health

Organization (WHO), the Center for Disease Control (CDC), The Rockefeller Foundation, and the

President's Emergency Plan for AIDS Relief (PEPFAR). The development community is scattered all

around the world led by the developers in Indianapolis and Boston.

Mamlin, et al., 2006 describes the beginnings of the project prior to the current OpenMRS was

conceived. Indiana University School and Moi University School of Medicine collaborated to create the

Medical Record System (MMRS) which was developed using Microsoft Access and which was deployed

in Kenya. The system was used in AMPATH (Academic Model for the Prevention and Treatment of

HIV/AIDS) project. The system was not adequate to support many locations and to handle hundred

thousand patients. After evaluating existing solutions they came up with AMRS. AMRS has an extensible

data model. Instead of a flat table structure where each patient data point is recorded by a column,

AMRS model uses the stacked data structure or entity attribute value approach where a single row of

data is represented by a stack of rows for each patient. This is discussed later.

The design goals of AMRS were collaboration of the community to build upon a common infrastructure,

scalability to support many locations and hundred thousand patients, flexibility to support not only HIV

care but general clinical scenarios, rapid form design for data entry, clinically useful gathering of data,

use of standards the medical field such as HL7, LOINC, ICD 10, SNOMED and CPT, support high quality

research using the captured data, web based with support for intermittent connections in developing

countries and low cost solution using free and open source tools (Mamlin, et al., 2006). AMRS system

was developed using Python, Plone and MySQL.

Wolfe, et al., 2006 describes how the AMRS team partnered with the Partners in Health to form the

current OpenMRS project in 2004 which replaced the above AMPATH project. Partners in Health were

involved in developing a system to support multi drug resistant tuberculosis studies in Peru. The goal of

the collaboration was to create an application programming interface (API) encapsulating the data

model and to develop a web based application. The API is separate from the web interface such that the

API can be accessed through other mediums such as mobile appliances. This means that the data

gathering and dissemination is not constrained into isolated silos. The user interface could be Windows

applications, Java applications, Web applications, programs running in personal digital assistants, voice


25/86

16

recognition interfaces through phones or scanned paper forms consumed by optical character

recognition.

Although a generic system will not support all the features out of the box it should be extensible so that

developers

can

extend

the

system

to

support

the

requirements

(Fraser,

Biondich,

Moodley,

Choi,

Mamlin, &Szolovits, 2005). The data model plays a major part in extensibility. OpenMRS uses a concept

dictionary where the data points are first defined in the system. The patient data are captured using

these coded data. Using coded data instead of free text gives more versatility and search and

manipulation capabilities. Also the data can be compared between systems accurately. The extensible

data model will be discussed in the chapter Further Analysis of Extensibility Principles.

The above papers cover the history of the project, how it came into existence, the aims of the project

and

some

high

level

requirements.

According

to

the

core

developers

interviewed

the

existing

data

model has evolved from the lessons learned from around 30 years of practical experience in various

projects including the AMPATH project.

OpenMRS Architecture

The following section will give a brief description about the OpenMRS medical record system.This

research will not go into elaborate detail on medical record systems as the major aim of this project is to

come up with important design principles towards extensibility.

The project uses open source tools and technologies such as Java, Spring framework, Spring MVC,

Hibernate, MySQL, jQuery and DWR and tools such as Eclipse, BIRT, Ant, Subversion, Bamboo and JIRA.

OpenMRS has an extensible data model and pluggable module architecture. The following diagram

illustrates the top level architecture.


26/86

17

Figure 3 OpenMRS top level architecture

Broadly the system consists of three layers as shown above. That is data, services and web. The data

layer consists of the database access services. The business logic resides in the services layer. And the

web layer consists of the default web application. It should be noted that the system can be used

without the web layer. In that case the developer can interact with the services directly using the API of

the services. The modules connect to all three layers to extend the system.

OpenMRS uses modules to extend the functionality of the system so developers can write new

extensions and plug them in to the core system seamlessly. The modules can support new additions in

the persistence level or in the service level or add or modify the web based user interface or connect a

different user interface system to the core system altogether. For example the developer can create

new database tables or append or reference existing tables, or in the user interface they can create new

user interface elements or replace existing elements using the extension points. These will be discussed

in detail with examples in the chapter Further Analysis of Design Principles.

The OpenMRS modules use various tools such as JasperReports, Xtream and integrate with products like

Pentaho suite of tools such as Kettle.The Eclipse IDE has been extended with OpenMRS specific plug ins

to help the developers build modules easily. One notable exception is that the project uses Microsoft

InfoPath proprietary software for form entry task. According to the interviews it was used because at

the

time

when

the

system

was

developed

there

was

no

alterative

solution

to

satisfy

the

requirements

with less effort and time. An XForms based form entry module was developed later. An alternative web

based HTML form entry module has been developed and is under active development now. While older

implementation sites use the InfoPath forms, new implementations are using the new HTML based form

entry module.These module functionalities can be categorized into the input element in the conceptual

model described earlier. They provide an alternative input method for patient record data.

M o d

u l e s Web

ServicesData


27/86

18

OpenMRS has been deployed in many countries such as Kenya, Rwanda, Tanzania, South Africa,

Lesotho, Zimbabwe, Mozambique, Uganda, Pakistan and USA (OpenMRS Implementations, 2010). The

system runs in regions with limited network availability and low resources. Other than being used as a

general patient record system in hospitals, it is used in the HIV treatment in Kenya, Rwanda, Tanzania,

multi drug resistant tuberculosis studies in Peru as well as for pediatric clinics in Indiana and

tuberculosis treatment clinics in Los Angeles, USA.

Each of these different implementation sites has different requirements and expectations from the base

system. OpenMRS cannot satisfy all these requirements out of the box. So the designers have built the

system with extensibility in mind. The data model is extensible to support these varied requirements.

Implementers can design the data model to suit their requirements and at the same time make sure

that the information that is stored can be transferable between different implementations.

So when applying OpenMRS system to record patient data in the HIV treatment programs, tuberculosis

studies, pediatric clinics OpenMRS developers do not release a new OpenMRS version every time.

Instead OpenMRS base system is a stable system with its own release cycle. Implementers who are

deploying the EMR system in sites apply the extensible data model and use modules to build a custom

EMR system out of the base system. The developers can create a module and include new features or

customizations without waiting for the core developers adding the functionality. Recently the reporting

functions have been ported into a separate module so that reporting developers can ship the module

independently from the base system. Also the logic service which is a process where data as well as

derived data can be retrieved about patients in a high level manner which is used for decision support

rules has been moved into a separate module so that the development can go in parallel.

OpenMRS is based on the principle that information should be stored in a manner which is easy to

analyze and aggregate. That is it encourages the use of coded data instead of textual free flowing

information. At its core it has a concept dictionary which is a repository of metadata of

relevantsymptoms, diagnosis, drugs, tests, visits and other recordable questions and answers. Initially

the OpenMRS system is empty of any metadata. The implementor fills the concept dictionary according

to the usage.For example the implementor can enter the concept Blood Type and the relevant answers

A, B, AB, O concepts as the answers. Then on the users can use these concepts to create forms as well as

fill the forms with the patient data.This will be further discussed in the description of the key value data

model section.


28/86

19

Software takes on many of the attributes of the organisation and process that creates it (Kelly,

2002).Conway's law says organizations which design systems are constrained to produce systems which

are copies of the communication structures of these organizations. OpenMRS community consists of

developers, users and volunteers scattered around the world working for different organizations. Hence

the architecture shows the attributes of openness, loose coupling and high user involvement.

Module Architecture

The importance of learning the mechanics of the module architecture is that this is a key feature that

provides extensibility in the medical record system. Today many of the software systems incorporate an

extension mechanism to different degrees. For example Eclipse has the plugin architecture. JBoss

application server is based on a micro kernel architecture where different components plug into that

base. Even Adobe Photoshop application has an extension mechanism so that developers can add new

features to the existing toolset. By understanding the module architecture it would help comprehending

the design principles behind these features in practical terms later.

The goal of the OpenMRS module architecture is to allow other developers to enhance and extend the

OpenMRS system to satisfy their specific requirements without making changes to the core code of the

OpenMRS. The module system has been available since OpenMRS version 1.1.

OpenMRS defines a specific structure for a module similar to the Java WAR file which bundles a Java

Web

application.

See

the

appendix

module

folder

structure.

The

metadata

are

provided

by

the

file

called

config.xml. A sample config.xml file is provided in the appendix sample module configuration file. When

starting up a module OpenMRS reads this file and registers the provided extensions with system. Some

of the details provided in the configuration file are listed below.

The module name

The module version

Supported OpenMRS version

Dependencies

on

other

modules

The activator class which defines the initialization and cleanup code

Extension points this module provides

In Addition there is a module application context file. This is a normal Spring beans configuration file

which defines the services provided by the module. See a sample file in the appendix sample module


29/86

20

application context configuration file. The core architecture loads these module specific services on

module startup.

For the persistence layer OpenMRS loads up the custom Hibernate mappings provided in the module

folder structure. The data migration is handled by LiquiBase data migration library (LiquiBase, 2010).

Until version 1.4 OpenMRS had a custom data migration mechanism (OpenMRS Sqldiff, 2008). It was

found to be very limiting when running complex tasks other than simple SQL create table, insert

statements.

Extension Mechanism

This section will discuss how an extension mechanism is designed in software applications and compare

it with how the OpenMRS architecture designed it.

Anyextensionmechanism consists of three major parts.

Defining the extension point hooks in the base system

A plug in registry where the extension points provided by the plug in module get registered with

the base system hooks.

A triggering mechanism that calls the extension code when an extension point isactivated.

There are several methods to implement this mechanism. The following sections describetwowaysthat

can be used.

Implementing Interface Contracts

Programming languages provide the concept called interface. Interface is a contract. Core code defines

interfaces or abstract classes at extension points. The module code implements the relevant interfaces

or subclass. On module start up the code that implements the relevant interfaces get registeredin a

system wide registry. This way when a user action triggers the extension point the relevant methods in

the module are called through the interfaces. The context data will be passed to the calling method.

Using interfaces is the simplest method. The weakness is that this is not flexible. The base system and

the plug ins should follow the interfaces strictly. They cannot be modified easily.

Publishing Events

The base system defines a preconfigured set of static events. The events could be defined as constants

or enums in the programming language. For every extensible point the base system sends out a static

event. The event contains the details about the context in which it was triggered. The modules subscribe


30/86

21

to receive the relevant events. Model view presenter (MVP) design pattern popularized by the Google

Web Toolkit (GWT) recommends this mechanism in implementing the user interfaces (Ramsdale, 2010).

One of the main advantages in this approach is that the event sources and event consumers are

completely decoupled.

OpenMRS Implementation

OpenMRS uses an interface contract based mechanism. All extension classes derived from the parent

Extension class. For example to add a new menu item to the administration section the module

developer subclasses the AdministrationSectionExt class and defines the links as a key value map. In the

base system administration page the extension point is defined using in the JSP as a tag library action,

. When displaying the administration

section the base system enumerates the registered module extensions and let them generate the

presentation elements which seamlessly plugs into the core system.

Styles for Extensibility

When considering extensibility in software architecture it is important understand the styles of

extensibility in general. Allen, 2001 describes three styles of extensible systems. They are black box,

glass box and white box systems.

Black box systems

Black box systems are those which the outside programmer has neither the ability to view or modify the

underlying code. Most of the commerical software fall into this category. For example Internet Explorer

supports adding extensions written by third party developers. The Internet Explorer provides a public

API describing the available interfaces but they do not provide the underlying code. This method of

extensibility is the most restrictive of all.

Glass boxsystems

Glass box systems mean the developer has the ability to see the underlying code of the base system but

cannot make changes or enhance it. This way developers have an insight of how their extensions

integrate with the base system. Most open source projects fall into this cateogry when looking from the

perspective of the users.


31/86

22

White boxsystems

In white box systems the developershave the ability to see the underlying code and they can make

changes to the core code as required. Open source projects fall into this cateogry when the users

request and provide changes to the core code.

Analysis

OpenMRS model is a white box system.This is cleary supported by being an open source system. When a

deficiency is pointed out in the base system by the module developers OpenMRS core developers are

quick to amend the source to fix it or to give an alternative workaround. This way the base system

evolves to support new extensions instead of adding new features to the base system. For example new

extension points get defined in the user interface when the module developers request them. According

to the core developers most of the time the required amendments to the core architecture are provided

by the module developers themselves as source code patches which consequently added to the current

development cycle.

So OpenMRS architecture is unique and advantageous in this sense being an open source project. In

commercial closed source systems the extension developers do not have access to the source of the

core system.

Module Limitations

The following sections describe some limitations of the OpenMRS module architecture in brief. When

incorporating extensibility principles the designer has to keep in mind these issues. These were

extracted in the data gathering phase. In the interviews it was evident that the designers did not

consider these issues throughly when developing the extension mechanism initially. According to the

discussions some of the issues faced by the developer community when writing extensions are related

to these limitations. So it is important to discuss these issues in here to understand the limitations of the

current architecture.

Trustworthy Computing

Confidentiality and privacy are important attributesin software systems and particularly in the medical

record systems where regulations like HIPAA are enforced (Annas, 2003). OpenMRS architecture

inherently trusts the module developers. An OpenMRS module can do anything the core OpenMRS code

base can do. It can retrieve patient data. It can delete all the patient data. It can send patient data to an

external destination.


32/86

23

OpenMRS provides a granular level security model for the authorization of the system functions. A user

has one or more roles. A role consists of one or more privileges. Using this role privilege model

OpenMRS implementers can define a role which can view patients but cannot edit the patient data or a

role which can login and manage schedule tasks only.

Figure 4 Privilege role model

Module developers use this privilege model to secure the module functionality. For example privileges

can be defined which can view the modules new pages. But the base system cannot control what

modules can do or cannot do.

So there are two perspectives concerning the security of the system. That is user level and extension

level. In the OpenMRS architecture the extension mechanism uses the existing user level authentication

and authorization features provided. But OpenMRS module architecture does not provide an extension

level security model. That means the core system cannot control what an extension can do or cannot

do.

From the interviews it was found out that this requirement was not major issue in real world scenarios.

On the other hand the developers express that incorporating an extension level security mechanism

could change the core system considerably. So one of the emerging design principles of this research is

design for security from the inception. This will be discussed further in the relevant design principle

discussion.

Preserving Backward Compatibility

One of the limitations when doing radical enhancement to the module architecture is the need for

preserving backward compatibility. When changing the base code the developers have to take

precautions not to break the old modules. This means the OpenMRS developers have to preserve

inelegant parts of old code when refactoring the base system.

The core system developers interviewed say that they did not find considerable design changes that

could break the backward compatibility so far. Also an important fact pointed out at the interviews was

that because almost all the module source code is available in the repository it was easy to change or

upgrade modules to support a newer OpenMRS version if the need arises. In the systems where

User Role Privilege


33/86

24

extension source is not centrally held or is private, breaking the backward compatibility could disrupt

many users.

So it is imperative that an extensible architecture has to be designed right from the beginning.

Otherwise

it

is

much

more

difficult

to

change

the

design

when

it

is

released

to

the

public.

It

is

hoped

that the emerging principles of this project will help the designers come up with an extensible

architecture right from the first time.

Introspective Features

OpenMRS architecture lacks introspection features. Each module lives in an isolated container. They are

not aware of the surrounding eco system created by the other modules other than the explicitly

specified dependencies in the module configuration. So this limits inter module extensibility.

The module developers who were interviewed did not find this a limitation so far. One reason this is not

relevant in this case is that the project and the modules are open source and developed cooperatively

by the developer community. If this was a closed source system this would have become an issue.

Incomplete Module Initialization and Cleanup

A module uses a class derived from the Activator class for the initialization and cleanup. This is defined

in the module configuration. Each module loads up in a separate Java class loader. So each module is

isolated from other modules. At the time when the activator gets called the Spring configuration is not

fully loaded and the services are not active. This has caused many issues for the module developers

recently. Further development in this area is necessary for improving the extensibility of the system.

As stated some of the above limitations can be overcome if the emerging principles are followed. It

should be noted that other medical record systems which were reviewed does not provide a broad

extensible architecture as in this particular system. Although they have a componentized architecture

made from different ready made applications they are not extendable as in OpenMRS.

Extensibility in Other Platforms

This section will discuss briefly other extensible systems in context. Today many applications provide

plug in mechanisms or scripting frameworks so that the users can customize and extend the

functionality of the base system. A sample of extensible systems is listed below.

Microsoft Excel macro functions allow the user to write custom calculations.


34/86

25

Microsoft Office applications provide scripting facilities.

The users can program games such as Doom and change the normal behavior.

Firefox plug in system allows adding new user interface elements.

Adobe Photoshop plugins add new filters and image manipulation tools.

It is apparent that when designing the OpenMRS module architecture the developers had used the

extension points design similar to the Eclipse plug in architecture. Eclipse platform is a multi language

integrated development environment with an extensible plug in system. In addition to the software

development environment Eclipse provides a general purpose rich client platform for developing

desktop software. Clayberg & Rubel, 2006 explains the Eclipse plug in architecture in detail.

In the interviews with the OpenMRS developers it was revealed that they have looked into using the

OSGi platform for the OpenMRS plug in system. Even at the moment it is an item in the agenda for

future development work in OpenMRS. OSGi is an open module system for Java programming language

that provides a dynamic component model and a service platform for Java components. Tavares &

Valente, 2008 gives introduction to the services provided by OSGi. At the inception of OpenMRS

development, OSGi was not hugely popular, the developers were not knowledgeable enough about the

subject and the production use of OSGi has been limited. So they decided to implement the plug in

system from the ground up. There are defeciencies compared to OSGi in the OpenMRS module

architecture. For example in OpenMRS, different versions of the same module cannot be loaded.

Other Medical Record Systems

Some of the popular and well established medical record systems are EMR Solutions (EMR Experts,

2010), PRAXIS (PRAXIS, 2010) and Charting PLUS (MediNotes, 2010). These are all commercial software

systems. These systems are similar to ERP systems used inorganizations. The systems consist of many

integrated components which an organization can purchase according to their requirements. The

components are designed in a general purposemanner with numerouse configurable options.There are

different types of modules suitable for opthalmologists to labrotory work. Also there are serveral open

source medical record systems in use today includingOpenEMR (OpenEMR, 2010) and VistA (VistA,

2010).

From the broad investigation it was foundthat OpenMRS differs from the rest of the EMR systems and

open source projects in particular in that it provides a generic lean system not specific to any field which

can be extended or customized using the data model and extensions according to the usage. OpenMRS


35/86

26

can be perceived as a clean slate where different tables and notes can be drawn by the users to design

their own formula. OpenMRS enables the implementers to design a customized medical records system

using its common framework and modules. It is based on a conceptual table structure independent of

metadata in any specific medical field orany particular data collecting forms, so that it can be

customized for different purposes.If the existing features are not enough the developers can add the

missing features by writing modules. The research will not discuss other medical record systems in detail

because the objective is on coming up with the key concepts behind the extensible architecture.


36/86

27

Design Principles Overview

As the starting point in identifying the design principles existing literature were investigated to build on

a foundation. The investigation revealed that the design principles specific for designing extensible

architecture were lacking in literature. It is hoped that the outcome of this research will fill this gap.

In the literature analysis,Martin, 2000 provided a rich set of principles to formulate the basis of this

research. Although these design principles are not specific for extensibility most of them are relevant for

designing extensible systems. The following are brief descriptions of some important concepts from

Martin,2000 and other referenced sources.It should be noted that these principles pave the foundation

for the design principles emerged from this project.

Open Close Principle

Meyer, 1988 says a module should be open for extension but closed for modification. When writing

classes, packages or modules it should be possible to extend the code without changing the original

code. Polymorphism in object oriented design faciliates this principle. Changing the original code would

introduce new bugs and issues with backward compatibility. But it is possible to argue that the extended

code could change the semantics of the code which would break the system behaviour.OpenMRS

implementations are extended through the extension points , aspect oriented programming

mechanisms, without modifiying the base system as desribed later.

Liskov's Substitution Principle

Liskov, 1987 says derived types must be completely substitutable for their base types. This principle is an

extension from the open close principle. In object oriented design, Liskovs substitution principle can be

applied by using class hierarchies and interfaces. The base type works as a contract for other derived

classes to follow.This is the basis of how module extension points work. The base system provides

interfaces and the extension points implement the interfaces.

Interface Segregation Principle

Many client specific interfaces are better t

Documents

EAD Thesis -Design Principles for Extensibility - 86