0 Recommendations

The potential of modular design for EMR systems

By Hamish Fraser, MBChB, MRCP, MSc Moderator Emeritus | 28 Apr, 2009 Last edited by Robert Szypko on 04 Aug 2011

One of the real challenges I see in the development of EMR systems around the world is the constant "re-invention of the wheel". Every project that creates a medical information system such as an EMR has to build all the basic tools before they get on to creating the parts
that are different and specific for a particular project. These tools include management of patient IDs and a master patient list, management of logins and role based authentication, systems to audit changes in the data, and tools for data management and reporting.

Developers can handle this in a couple of ways. They can skip these systems and then try to deal with the problems when the system has to scale, or they can invest a lot of time doing this work up front. An additional problem is that these functions require considerable expertise to build effectively.

What is the alternative? At present you can buy a system from a company which may have built all these basis tools, but then you must rely on the company to do all the work, a process which is time consuming and typically expensive. In a few cases an EMR system may be open source such as VistA. Then you can hire programmers and modify the system (though it will take a while to get up to speed with a large system).

There is an alternative approach which is complementary to open source and in some cases offers an alternative. In a recent paper in the New England Journal of Medicine Isaac Kohane and Kenneth Mandl describe the principle of an EMR platform. Taking the analogy of the Iphone or Facebook, this system would allow developer to add functionality to an existing EMR system in a modular fashion without having to change the core code. This would allow flexibility and rapid innovation, and is fundamentally different from having hundreds of companies all competing with different EMRs, as we currently have in the US. A well established platform should allow many different functions to be mixed and matched on top of the basic system. At present the best functions of each of these different EMRs are separated from the best functions of the others. Imagine if you could simply download modules for certain diseases, modules to link to specific lab or pharmacy systems and tools for visualizing data for particular purposes. Some would be open source, others proprietary but in addition you could commission or build your own.

This is the approach we are taking with the OpenMRS EMR system (www.openmrs.org) which is not only open source but provides a modular architecture. There are now 35 modules in the respository on the OpenMRS site some of which are widely shared across sites others just built for local use. There are 96 in total in various stages of completion. We are hoping that other projects with important functionality in their EMR systems will consider building a module in OpenMRS that can be widely shared.

Are there other systems out there like this is use in developing countries? Any thoughts on how might this strategy be used for other systems?

Attached resource:
  • No Small Change for the Health Information Economy (external URL)

    Link leads to: http://nejm.highwire.org/cgi/content/full/360/13/1278

    Summary: In this Perspective piece in the New England Journal of Medicine, the authors describe the principle of an EMR platform that would support interoperable and substitutable modules.

    "The economic stimulus package signed by President Barack Obama on February 17 included a $19 billion investment in health information technology. How can we best take advantage of this unprecedented opportunity to computerize health care and stimulate the health information economy while also stimulating the U.S. economy? A health care system adapting to the effects of an aging population, growing expenditures, and a diminishing primary care workforce needs the support of a flexible information infrastructure that facilitates innovation in wellness, health care, and public health.

    Flexibility is critical, since the system will have to function under new policies and in the service of new health care delivery mechanisms, and it will need to incorporate emerging information technologies on an ongoing basis. As we seek to design a system that will constantly evolve and encourage innovation, we can glean lessons from large-scale information-technology successes in other fields. An essential first lesson is that ideally, system components should be not only interoperable but also substitutable..."

    Read the entire article by clicking the link above.

    Join GHDonline Members discussing this issue here: http://www.ghdonline.org/tech/discussion/the-potential-of-modular-design-for-...

    Source: New England Journal of Medicine - NEJM

    Publication Date: March 26, 2009

    Language: English

    Keywords: EMR modules, EMR platform, Pharmacy Information System, Software



Rogers Hellman Replied at 11:55 AM, 28 Apr 2009


The one problem with that approach in regards to health based systems in particular is patient privacy. I like the idea of making things completely open so that others can add new modules, features and improve the existing system. On the other hand, I've encrypted the patient demographics to enhance security. The two goals seem to be in conflict.


Hamish Fraser, MBChB, MRCP, MSc Moderator Emeritus Replied at 12:05 PM, 28 Apr 2009

Hi Roger, thanks for your post on this. In general there is no conflict with the use of Open Source software and ensuring data confidentiality and security. The code that you use is compiled and so it is an issue of good design rather than keeping the source code secret. Linux has a much better track record than Windows for security and freedom from bugs. That stems partly from the number of good programmers who look at the code and submit patches for problems usually very quickly. Apache the leading web server is also open source as is the VistA EMR system.

jayanth devasundaram Replied at 1:05 PM, 28 Apr 2009

Hi Hamish,

I completely agree with you that systems should be modularized and pluggable with a core functioning piece for maximum flexibility in functionality and deployment. However, I believe that this core piece still hasn't been defined well enough using ontological principles and, so, the EMR systems seem to be blundering along..


Rogers Hellman Replied at 1:23 PM, 28 Apr 2009

Thanks Jay.

While not the phrasing I would have chosen, I agree that there are issues with openMRS. However, none with the concept.


Om G Replied at 1:57 PM, 28 Apr 2009

Somewhere in the modular design, having automated update framework for the
inevitable core changes is a must.

This is another rationale that leads me to more centralized approaches.

Deploying a front end to the desktop that interacts with a central system
makes sense too.


what do you think about focusing on data interoperability and reporting
repository rather than the actual system being used to collect and manage
individual cases?

Seems like a lot of solutions are going to come and go but the numbers
will remain.

If anyone can collect information in a spreadsheet application and upload
it someplace, then the heavyweight and vulnerable parts can be server
based, or relevant parts sent out to a lightweight desktop client.

jayanth devasundaram Replied at 1:59 PM, 28 Apr 2009

Hi Rogers,

Your ponts are well taken. My statement was not targeted at any specific EMR systems out there. Having looked at so many of them over the years, It appears that there hasn't been any attempt at universalizing the system such that independent developers could plug in their functionalities, adding to the whole. While this is an EMR IT dream, this has been achieved by several prominent software systems such as Adobe and ESRI, to name two, with the facility for independent programmers to create plug-ins that work with the core system.

The responsibility for the standardization of the core piece probably comes from HHS or from a private company with deep pockets such as IBM or Microsoft. Till such an universal core standard is created, the situation described by the original poster will continue to exist with push backs from the medical community because of a demonstrably sloppy system.


Rogers Hellman Replied at 2:13 PM, 28 Apr 2009

I think that makes a great deal of sense, with standards defined to protect the security of the data while in electronic transport. I would also add some standards to define the integrity level of the data.

That way, we get the benefits of a cohesive dataset and yet the innovations from multiple collection systems.


Om G Replied at 2:32 PM, 28 Apr 2009

Hi Rogers,

right, and I think each of those points can be accomplished rather
easily using web forms for the file upload. It can be over SSH without
any additional complexity to the end user and once 'ingested' fields can
be mapped against more common terms and the data parsed for integrity.

We still come back to implementation.. the who and where.

I only know of one system that has all these features implemented, but
I'm not sure of their interoperability with other systems, or how a more
high level repository would be coordinated.

I'd sure like to see something like Source Forge, where end users
(clinics under the official auspices of an agency) would get a secure
token or authenticator once verified as an entity, to upload their
presumably more reliable data.

Rogers Hellman Replied at 2:48 PM, 28 Apr 2009

Om, Hamish & Jay:

Good discussion. It would be nice to formalize with a bit more complete analysis on our part. Or at least speaking for myself, most of what I've contributed to the discussion has been on the fly and off the cuff. I do think defining a data standards format would be an excellent start.

There are lots of web tools for data-exchange that could be employed with little or no impact on emerging technologies.. xml to name one


Om G Replied at 4:05 PM, 28 Apr 2009

Well as with any 'wouldn't it be nice if' conversation, a lot can be gained from better understanding the lay of the land.

My guess is that well thought reporting standards exist in a variety of flavors, which is why I'd like to see something more geared to ease of access that could convert to a few of the most popular standards.

That said, xml is a great mechanism along with OWL, FOAF and other 'knowledge sharing' semantic technologies.

"Pollution is a symbol of design failure."
-William McDonough

jayanth devasundaram Replied at 5:07 PM, 28 Apr 2009


Well said. Using OWL, FOAF, FMA and XML etc is step in the right direction; however, a common ontology and data model needs to exist before interoperability can be considered. Right now, "interoperability" only exists in the data transport realm- not in the data rendering and use realm.


Hamish Fraser, MBChB, MRCP, MSc Moderator Emeritus Replied at 6:07 PM, 28 Apr 2009

Good to see a discussion developing here, it is surprising how little progress has been made on this issue in the US.

However I would raise concerns with the idea that the local data collection is a minor issue that can be left to a simple web form or even an Excel spreadsheet - would that it were so easy! The local interaction with an EMR system is a big part of the challenge, especially in resource poor environments. A particular focus of our work is making clinical data accessible to local staff to support improvements in quality of care and management of the clinic. Data management and improving data quality is the biggest daily challenge. There are lots of reporting systems that do not work well because they place too little emphasis on the data collection part. So having a good data model and ontology is an important factor for a modular design but is perhaps an example of "the best being the enemy of the good".

Om G Replied at 6:16 PM, 28 Apr 2009


True, but there are bound to be convergences in the 'use' realm making the output requirements far fewer than the inputs (speaking from the system's perspective).

I think modularity can be elevated to another level. Rather than everything going into a single universal system with modules, I think it would be helpful to have a series of layers.

The data layer would need to be it's own entity with easy input (uploading) from the widest variety of sources and output in the most useful/universal formats.

Where I saw semantic technologies coming in handy was in the query (data rendering and output) realm.

Tagging enables the data to float around until discovered by relevance linking or direct search. It can even reside at the originator's location as long as the rest of us can discover what it is and get to it.
So, I guess I'm suggesting that ontology would be the 'standard' but doesn't need to get too granular because semantics can relate to one another.

A rough analogy for an end user would be how DNS works to connect you to more technical detail (ip address) through a friendly interface (regular text url).

The discussion started with 'a' system and it occurred to me that forcing a standard isn't always best or adhered to, but as long as everyone is responsible for their version and what a format 'means' then translators can be built pretty easily.

Om G Replied at 6:50 PM, 28 Apr 2009

Well, data collection would take a wide variety of formats and amounts to question, answer text input pairs. Providing standard forms for people to fill out is a separate issue for me.

In this case, even using a clinic management tool is a more sophisticated text entry device with perhaps some analytics built in.

Secure uploads would just be to get a chunk of data from you to a central repository where others could use it.

Standards already exist for associating a name to a disease and location, but I don't know of any reason it can't be dealt with in a way that associates resolution with authorization. Lower level of trust gets you name of disease and a region (county or shire) instead of street address.

I keep coming back to web based collection of a variety of input formats. Useful information and downloads could be there also including templates for better data collection and software.

Om G Replied at 3:51 AM, 30 Apr 2009

here is an interesting beginning that enables entities to be mapped across
different schema


Om G Replied at 3:58 AM, 30 Apr 2009

Apologies for the second post. I intended to include this description:

SKOS — Simple Knowledge Organisation System — provides a model for
expressing the basic structure and content of
concept schemes such as thesauri, classification schemes, subject heading
lists, taxonomies, folksonomies, and other types of controlled vocabulary.
an application of the Resource Description Framework (RDF) SKOS allows
concepts to be documented, linked and merged
with other data, while still being composed, integrated and published on
World Wide Web.

This document is an implementors guide for those who would like to
represent their concept scheme using SKOS.

In basic SKOS, conceptual resources (concepts) can be identified using
URIs, labelled with strings in one or more natural languages, documented
with various types of notes, semantically related to each other in
informal hierarchies and association networks, and aggregated into
distinct concept schemes.

In advanced SKOS, conceptual resources can be mapped to conceptual
resources in other schemes and grouped into labelled or ordered
collections. Concept labels can also be related to each other. Finally,
the SKOS vocabulary itself can be extended to suit the needs of particular
communities of practice.

This document is a companion to the SKOS Reference, which gives the
normative reference on SKOS.

Alvin Marcelo, MD Replied at 10:10 AM, 1 May 2009

Dear all,

I've been following the threads closely for the past few days. The
discussions are all interesting.

I am looking for people who have managed EHR projects (design, develop,
install and maintain -- which includes persuasion, coercion, and all other
techniques to make the technology stick) who are also on this list. I'd like
to specifically know:

- what software was used
- what license it employs (if any)
- how long it has been running
- how many distinct people are using it

If I may start from our experience in the Philippines:

Software: Community Health Information Tracking System (www.chits.ph) LAMP
License: GPLv2
6 years
400 pax (average of 20 users per facility; 20 facilities)

Software: Integrated Surgical Information System (ISIS) LAMP
License: uses open source tools but no FOSS license yet
5 years
100 pax (in one facility)

We are also studying OpenMRS for possible installation in a rural hospital
in the Philippines. A few MIT students are helping us get to a confidence
level to do such a deployment.

I'd like to exchange ideas with these proj managers on the strategies for
implementation which you found had worked well and which ones you found had
not worked as much.



Rogers Hellman Replied at 10:42 AM, 1 May 2009


I guess I fit. You can contact me directly using the email address:


This Community is Archived.

This community is no longer active as of December 2018. Thanks to those who posted here and made this information available to others visiting the site.