Sunday, June 17, 2012

'Open' Health IT Architecture

I have had some major issues with IT Architects over the years and the many prolific and useless dissertations they produce that are usually of little real value or practical use to senior IT managers responsible for day-to-day operations.  That does not mean that I don't appreciate the need for a good, practical IT architectural blueprint or roadmap that will help one make better decisions about the technology to acquire and implement to best meet the operational business needs of the organization for the future. What follows is a high level management introduction to 'Open' Health IT Architecture for those who are new to this whole arena.

IT Architecture

A sound IT Architectural roadmap should produce a detailed blueprint for the future that addresses the following areas: business activities and processes; the flow of information; needed data sets; software tools and applications; hardware platforms; telecommunications infrastructure; and other key information technologies that your organization ought to acquire and implement to successfully carry out its mission.

There are several popular architectural processes that have emerged over time such as the TOGAF Framework, DoD Architectural Framework (DODAF), and the Zachman Framework. My favorite, though, is the Medicaid Information Technology Architecture (MITA) Framework. Also, given the intended audience of this article, it's may be the most relevant to healthcare organizations. The MITA Framework provides guidelines for the creation of a roadmap that ought to contain the following key sections:

  • The Business Architecture (BA) section of your IT Architecture roadmap ought to present a collectively agreed upon vision for the future of your business organization, e.g. clinic, hospital.
  • The Information Architecture (IA) section should identify the major types of information systems needed to support the business functions of the organization.
  • The Technical Architecture (TA) section should describe current and planned technical services, their connectivity, and standards that the organization should use when they plan and specify new IT systems to be acquired and implemented.

When you start the process of developing the IT Architectural roadmap for your organization, one ought to start with a vision of what you are trying to accomplish - a list of specific objectives. For example, primary objectives of the IT Architectural process might include:

  • Align information requirements with the organization's business plans
  • Continually strive to improve overall business and information system effectiveness
  • Lower overall system life-cycle costs, while constantly innovating and enhancing systems
  • Enable interoperability and data sharing between key internal and external systems

The IT Architecture roadmap you produce should address both the "as is" and "to be" business, information, and technical architectures for your organization. How do you go about doing this? Take a snapshot of your existing IT capabilities. Then identify key IT architecture and standards you believe ought to be put into place. Identify gaps between the existing IT architecture and the planned architecture. After you finalize the agreed upon targeted IT architecture, put together a migration plan to acquire and implement the new architecture over time. Remember, as your organization begins to implement the planned architecture and starts the migration process, make sure to regularly review and track progress and make needed changes to the IT architecture when necessary.

Also, remember, the organization's IT Architecture must be reviewed, documented and updated regularly - if it is to become an effective management tool. However, the level of detail can vary greatly. Some organizations' architecture documents approach the size of a small set of encyclopedias which generally don't get read and end up sitting on the shelf. Others are much more compact. I advise being concise and providing specific, practical guidance that can be readily understood and used by your IT managers and staff.

'Open' IT Architecture

'Open architecture' strives to allow for the adding, upgrading and swapping hardware and software components from a wide range of products and solution providers.  Key concepts for ensuring an open architecture are being standards-based and vendor neutral. In a 'closed architecture', the hardware or software vendor usually locks you into a limited set of proprietary  components, primarily limited to their product line. In most circumstances, organizations should seriously consider going with an 'open' architecture approach.

Other characteristics related to an 'open architecture' and environment include:

  • Allowing for no single developer or vendor to have control over your future.
  • Any privately designed architectures and specifications should be made public
  • Allowing improvements to the architecture or technology to be made by key players, without obtaining permission from a vendor.
  • Any open architecture ought to ensure that systems are interoperable and that applications are readily portable.
  • There should be a heavy emphasis placed on collaboration and sharing during the development of the IT architectural roadmap.

Finally, it has been found that an 'open architecture' evolves and matures faster through the input of multiple developers and vendors within an open source software development community.  Open architecture also tends to help generate more competition in the marketplace, thereby promoting technical innovation and helping to lower systems development costs.


The following are selected links to some of the major collaborative organizations, projects, and activities focused in varying degrees on IT Architecture, Standards, and 'Open Health'.


Finally, here's a short list of other articles, reports, and papers on collaborative, 'open source' health IT architecture and standards you might want to read include:


Send us your comments and share any links to other useful IT architecture web sites and organizations we ought to all know about. Especially if it relates to the healthcare environment.

No comments: