EMR Core Versus Specialty Functionality

The other day I was thinking about the way EMR software has been designed. A common complaint by specialists is that a certain EMR was designed for General Medicine, but would not work for [insert specialty here]. Then, I asked myself the question “Why hasn’t an EMR vendor built a core with plugins so that other divisions of their company could focus on specialties?”

Yes, if you are a doctor you can probably stop reading right here.

Anyone who’s participated in a website content management system like WordPress (which I use to run this blog) is familiar with the idea of WordPress being the core and then plugins adding extra functionality that might be specific to a user. I wonder why no EMR vendor has decided to develop their software with this same type of flexibility. I believe this process could even work for a private company. It could have one department in charge of the core EMR functionality. Then, other divisions of the company could focus on creating various “plugins” that would expand the core functionality to meet different needs.

This could be the perfect way to be able to adapt the core EMR functions to meet the needs of various specialty clinics out there. This could even be a good way for an EMR company to adapt a product for different state regulations and requirements.

Of course, this model works even better when we’re talking about open source EMR (see also the open source EMR list on the EMR wiki). I’ve seen some different open source EMR, but I don’t personally know of any that are using this model. I’m guessing there has to be and I just don’t know about it. If anyone knows of an open source EMR that is using this model for development, please let me know in the comments. I’d also love to have someone do a guest blog post about this if it is occurring already.

Just some food for thought. Any EMR companies developing this way and I just don’t know about it? I’d love to hear about it as well.

About the author

John Lynn

John Lynn

John Lynn is the Founder of HealthcareScene.com, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference, EXPO.health, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.


  • John… To your question “why hasn’t anyone built a common core” with plug ins for specialties and subspecialties?”

    Could the business component of the EHR/EMR be the core?

    Could the fact that medicine and surgery are process and speciality/subspeciality focused … not patient-focused… so the orientation of the model is toward the customer rather than patients?

    From a code writing perspective it makes sense to build a central core and then build plug ins… what business risk though is there that if you build it that way it could easily be copied? Could easily result in a competitor building the plug in?

    What is the risk to your entire business line if down the road there is an issue with the core… that causes huge problems across all of your specialty and subspecialty applications?

    I agree with you … a modular EHR/EMR would make a whole lot of sense.

    Something I don’t understand … because perhaps I’m not in the business of selling hardware or appropriating money from Americans to gain votes in 2 years when I run for re-election to Congress … but why aren’t EHRs built as a web services product? Like Google.

    DoD operates 6 major server systems to support its global C2 and shipment tracking for all transportation modes … 3 are in the U.S. and 2 are overseas. Most fixed facilities operate hard wire to specific servers … mobile units operate into the same system via web based services. Five of those systems are live all the time or in backup … all are linked … 1 system is always available for analyitics and reports … queries can be run against the live systems … but heavy analysis is run on the one system which is not in a C2 posture. Why isn’t health care’s national system adopting something like this … rather than trying to figure out how to link up a myraid of regional information exchanges with little if any commonality in their platform or capabilities?

  • We can modualize the EMR but then you will have some physicians that will want the EMR but without the benifit. Some companies sell the EMR’s and remove the ePrescribing, Templates, Labs. It is like buying the car and taking out the radio, AC, and Seats and steering wheel. Oh…But leave the engine. Our EMR (FirstEMR) is being developing with this vision as our roadmap. We have currently developed a General Medicine, but as we continue we will have plug-in that will customize our application for specialties.

    I agree with you that essential core EMR/EHR functions are common, but the difficulty is establishing what are common functions and what are specialty-based functions.

    We can modularize the EMR but then you will have some physicians that will want the EMR but without the benefit. Some companies sell the EMR’s and remove the ePrescribing, Templates, Labs. It is like buying the car and taking out the radio, AC, and Seats and steering wheel. Oh…But leave the engine.

  • Don,
    “why aren’t EHRs built as a web services product? Like Google.”
    There are a lot of answers to this question. The short answer is that a lot of companies are trying to do it. However, there’s still a rather large group of people that argue that certain functions that can be done in client server still aren’t possible on the web.

    As far as one unified system hosted by the government, you might want to just look at the challenges of the much smaller British National Health system to see why we don’t want to have one unified EHR done by government. See my recent post to see what I’m talking about: https://www.healthcareittoday.com/2009/03/13/comparison-with-british-national-health-system-emr-implementation/

  • Denis,
    I’m not necessarily suggesting that you sale the product with the various modules. I can see why this could be a major challenge.

    My suggestion is to use this development process to be able to scale the development in order to support more specialties. It also would mean that you could expose your software to outside developers to be able to develop these specialty modules as well. This could be either through an API or even open sourcing the entire application down the road.

    This is the type of development going on all over the web, but I have yet to see it employed by EHR developers.

  • It strikes me that this is a task ideally suited to Drupal and CiviCRM. Drupal is an open source CMS with thousands of developers worldwide. It has an excellent security team that is constantly on the watch for needed updates, and the 6.x release monitors sites for needed updates constantly. The entire system is modular, and so could easily accommodate a series of modules written for specialties. The core modules already support different roles with different permissions (providors, nurses, records, etc.). CiviCRM is a large collection of modules designed for customer (patient) relations that now includes a customizable CiviCase that might serve as the basis for a patient database. I do not see, however, that any Drupal developers are yet working on a distribution of Drupal that could be used as a free and open EHR system. I suspect that is because no developers, myself included, has been retained by a group of physicians to develop such a system. If you know of any, please contact me.

  • Michael,
    The drupal model (or also Joomla or WordPress) is basically the type of model I’m describing. I hadn’t considered the idea of just building a full EMR on top of Drupal. I’d have to think about it a bit more to think if that’s a good idea or not. I’m not sure how much benefit you’d get from using drupal as the core.

    It definitely would take a group of physicians retaining some programmers to make Drupal into an EHR. Could be interesting.

  • I considered Joomla, but I thought that the update system in Drupal was compelling. It would be especially useful in maintaining security updates, and security is a major concern.

  • John, I agree with you! A community development would be ideal, but from my (programmer) perspective an open development with SDK’s and API’s could allow people to exploit the EMR and worse patient files. Which is why, I believe many EMR’s have not yet implemented SDK’s or API’s. I think in a few years we can expect SDK’s and API’s, as developers become more aware of ways to protect patient information while allowing third party connection. I always enjoy reading your posts!

    (Note on Don’s Post) Our application is Client-Server based and setup to use WebServices. WebServices allows our remote clients to connect to the server over the internet.

  • Denis,
    You could always go for more of a Meebo.com like model. Essentially they only opened up their API to a trusted set of developers. That way they have some basis for quality, but still can empower as many third party developers as they see fit.

  • John… Am intimately familiar with NHS’ experience. Off the top of my head the Brits have burned through near close to $20bil with 1/5 the population… and one health care construct since 2004. Not done yet.

    Working against the Brit experience too is that because their health care system is socialized with way cheap and rationed services they will not ‘enjoy’ the ‘full value’ of their EHR like the U.S. will. GULP.

    More I listen to you guys… got to believe that idea of a central common core application with ‘snap on’ modules for specialities and features like ePrescription etc.

    Way I’d price it is that the core is the core… and if client wants it without some standard feature they pay an ala carte price for the whole deal. Not sure how another source pharma package would work side by side. Sounds dumb to me.

    Story: Was AF C-5 pilot. Original C-5 had 2 identical Honeywell Nav Cmptrs. One was PRI one was AUX. Brilliant planners thought they would save money by only requiring the real basic features in the Aux box. Since Honeywell only built one LRU for real… they had to bust into the box, pull cards, deprogram. Result … AUX cost $200k more than the PRI. See that’s what I mean about dumb requirements folks who don’t know changes cost bucks.

  • You clearly have not been involved with VistA.

    Our Vascular Surgery department customized templates, ordering templates, and referral templates for Vascular Surgery easily, within the VistA framework.

    Modularity is designed into VistA already. That is how it developed.

    I am always amazed at people who want to reinvent the wheel.

  • The solution is simple really. Look at how Apple is handling all of their app store applications. They verify that the code is “compliant” to their requirements. There really needs to be a non-profit testing and certification group for this. The consequences are way to high if a few “bugs” crept in.

    And to answer the first question… There is a API (sort of) available in OpenEMR. Its not perfect but its a start.

  • EMR vendors have demonstrated abundantly that they buy niche solutions, rather than build them. They want the market to speak for itself, rather than take on the risk of attempting to create the market. EMR vendors (and other reef predators) seldom wait very long to pounce. A ferocious rate of five healthcare IT transactions every week this year, proves the point.

Click here to post a comment