Readers Write 7/17/08

Samantha Brown on Most Wired

There are some of us who just aren’t filling out these ridiculous surveys anymore. They are nothing more than vanity plates for CIOs. There are a lot of better wired hospitals who are not on the rankings at all.

Spanky on Most Wired

After 10 years, only 556 organizations see any value in responding to the survey.

The PACS Designer’s Open Software Review – OpenMRS
By The PACS Designer

The ROW (rest of world) is starting to get the digital sense when it comes to record management systems for healthcare. Developers have come together to specifically respond to those actively building and managing health systems in the developing world, where AIDS, tuberculosis, and malaria afflict the lives of millions. They are using OpenMRS to achieve a  better outcome for patients. Most of the core developers are from the Regenstrief Institute and Partners in Health.

OpenMRS is an open source medical record system which is focused on developing countries. Open Medical Record System (OpenMRS®) was formed in 2004 as a open source medical record system framework for developing countries. OpenMRS is a multi-institution, nonprofit collaborative led by Regenstrief Institute, Inc. (http://regenstrief.org), a world-renowned leader in medical informatics research, and Partners In Health (http://pih.org), a Boston-based philanthropic organization with a focus on improving the lives of underprivileged people worldwide through health care service and advocacy. It is web-based, written in Java, and is under active development.

There are several layers to the system:

(1) The OpenMRS data model borrows heavily from the Regenstrief model, which has over a 30-year history of proven scalability and is also based on a concept dictionary.

(2) The API (application programming interface) provides a programmatic wrapper around the data model, allowing developers to program against more simplified method calls rather than having to understand the intricacies of the data model.

(3) The Web Application includes web front-ends and modules that extend the core functions — these are the user interfaces and applications themselves built upon the lower levels.

OpenMRS® is a community-developed, open-source, enterprise electronic medical record system framework. Their mission is to foster self-sustaining health information technology implementations in these environments through peer mentorship, proactive collaboration, and a code base that equals or surpasses proprietary equivalents.

As the ROW gains confidence in OpenMRS, you will see more countries joining this effort to digitize their medical records for patients to improve outcomes. OpenMRS has been implemented in several African countries, including South Africa, Kenya, Rwanda, Lesotho, Zimbabwe, Mozambique, Uganda, and Tanzania.

TPD Usefulness Rating:  8.

http://openmrs.org/wiki/OpenMRS

Art Vandelay on Enterprise Architecture

A number of organizations outside of healthcare have been developing "enterprise architectures" (EA) for some time. My first exposure to the concept was when Gartner introduced, "3 Documents for Healthcare IT Planning" in 1998. Outside of healthcare, there have been some success stories, but many more failures. The cases of failure seem to be due to a poor link to business value (ROI). With the growing complexity of our environments, some level of EA is needed. It is more than a passing fad.

In 1998, we looked at EA as basic standards and filling in the cells in the "Zachman Framework." While a great technique, this was fairly academic at the time. There was little guidance on looking at the present while projecting the future. There were also no formal linkages between the cells or a step-by-step process.

Knowing there was still value in this space, we evolved our concept to what we feel is a practical approach to enterprise architecture. To ensure that we keep true to providing business value, we trace the business value expressed in the form of the principles through all our decisions. We’ve defined a process that is iterative. It involves defining the current state and the path to migrate to the future state.

Whatever technique you use, it is important to set the goals and be sure your key stakeholders buy in to your approach. The proper level of input is important. This usually comes in the form of a steering or governance committee. We then start with reviewing our business and technology strategy. Next, we establish our principles for a defined period of time. Examples of our principles include looking an existing vendors for solutions to consolidate our spend to get preferential pricing and support. Another principle is to look to local vendors to help the economics of our area.

We then define standards maps for how we envision the layers in the architecture evolving over time. At its broadest level, think of the different layers involved in hardware, software and application integration. Within each layer, we also define another dimension for support processes, monitoring, change control, problem management, etc. For example, for integration, there is integration of healthcare applications – usually based on HL7. There is also non-healthcare application integration. We’ve chosen to use XML for the data standards layer.

The standards maps are supported by an approved buy list. We attempt to select the items in the buy list based on some no-nonsense requirements. For example, we use Altova’s XML Suite for working with XML. For servers, we’ve picked a major vendor but work with a local reseller to stimulate our local economy.

Most of the work goes into synchronizing the maps of various technology layers. We also establish reusable patterns to provide standardized solution templates across layers. For example, we have patterns for the various 9’s of availability (ex: 99.99%). Other patterns involve how we work with application service providers (ASPs).

With the advent of service-oriented architectures (SOA), the patterns have evolved to include application services. For example, we have defined an application authentication service that works with our single sign-on vendor and directory services. This is referenced by our web applications. Services have brought about the need for a new level of governance and coordinated planning. Fortunately, with the work we’ve done to define some of the EA, we seem to be adequately positioned to work through the challenge.

If you haven’t started to develop an EA, I encourage you to do so. From a purely IS point of view, as our vendors adopt SOA and virtualization and more integration is expected, the level of coordination increases exponentially. It will also start to evolve our support and project delivery models.