Building a comprehensive clinical information system from components

From Clinfowiki
Jump to: navigation, search

Spurred by the decision to support ambulatory as well as acute care, Intermountan Health Care decided to preserve its investment in multiple vendor and custom technologies and tie the various pieces together using a component-based, open architecture approach to building clinical information systems. In this paper, they discuss their chosen architecture and compare it to other approaches. Their clinical data repository contains the records for 1.48 million patients, and the system (in 2002) had 369 GB of storage capacity. They process nearly 2 million transactions per day via the interface engine and 2,416 individual clinical users log on to the system at least once a month. The environment includes a Master Patient Index, a Clinical Data Repository Database, a Health term Data Dictionary and a Clinical Desktop.

Use of Components in Building Clinical Systems

They outline three options for developing clinical systems:

  • Build all of the applications from scratch. Although this has been a successful model for most currently existing systems, it would effectively mean duplicating the development effort a vendor can spread costs across many customers.
  • Purchase all applications from a single vendor to insure ease of implementation and seamless integration. It is often less expensive to buy and interface an existing system than to rebuild something that already exists from scratch. On the other hand, no single vendor can satisfy all the desired functionality, and the future of the system is tied to the viability of the vendor over a projected 20-25 year system lifetime.
  • Build the system from components and use a common longitudinal repository. For institutions with knowledgeable people and the resources to invest in this approach, they believe it will ultimately be more flexible and cost effective than the alternatives. They expect the advantages to increase as the costs of interfaces are reduced by improved standards for vocabulary and messaging.

In 2002 there were a total of 820 instances of interfaces to 51 different applications including clinical systems (clinical laboratory, PACS, blood bank, anatomic pathology, surgery scheduling, transcription, etc,) financial systems and external partners. Not surprisingly, they found that building the interfaces between the components was a high percentage of project time and cost. They found costs of the interfaces amounted to 20% of the total application software costs and about four percent of the total information systems budget.

One important design goal was to make it possible to change any component or application without the need to change any other component. This requires separating presentation, business/clinical logic and data layers. Monolithic systems are aware of the database structure so any changes in the database structure or the presentation layer usually mean that all the application programs using the same data need to be changed. In their architecture only the services that store and retrieve the data would need to change, and both versions of the database could simultaneously exist during a transition. The ability to gradually change or add one component at a time to the system allows them to adapt to change incrementally. They use standards and common terminologies where possible to help with interoperability and reduce the cost of interfaces: including LOINC, CPT-4, ICD9 and HL7.

Comment

The authors present a sensible view of the world from a technical viewpoint for a large organization that cannot meet its information needs using a single vendor. The level of technical sophistication needed for such a degree of customization may be difficult for many other health care organizations to achieve.

Only a couple years later (2005) Intermountain announced they were replacing much of their system: combining their clinical decision support with the Centricity EHR in a large co-development project with General Electric. Whether they have the ability to reuse much of their prior work, and whether they are are able to transition smoothly to the new software will be a measure of success for the project described here.

“GE Partners With Health-Care Provider To Develop Next-Generation Clinical Software Intermountain Health Care, a pioneer in the use of computerized health records, will help develop a release of GE's Centricity clinical system.” Marianne Kolbasuk McGee. Information Week Jul 6, 2005 http://www.informationweek.com/story/showArticle.jhtml;jsessionid=LRQ3EQIJGCNUQQSNDBECKH0CJUMEKJVN?articleID=165700208