AuntMinnie.com is pleased to present a two-part article on assessing, improving, and updating medical systems.
By: John Cadigan, Jim Everett-Wilson, and Norm DelisleFoliage Software Systems
In some cases the pressure for new features is too strong to allow for the development of a completely new software platform. In other cases, the allocated budget won’t support it -- the common wisdom being that just enhancing the existing software platform will be cheaper. In almost all cases the risk in developing a new software platform can seem too high.
This article describes an approach for incrementally migrating existing legacy software systems to a new software architecture. This approach reduces overall risk, reduces initial investment, and provides a very attractive return on investment. Based on our lessons learned -- both designing systems from scratch and migrating existing systems to improved software architectures -- we describe how to determine whether your existing software can be migrated and how to determine the best migration approach.
Many existing medical systems are good candidates for improvement via incremental migration. With the advent of component-based software technologies over the past decade, software architects have been crafting highly modular software systems that migrate much more easily than the monolithic software applications of the previous generation.
The first step is to determine whether your software can and should be migrated. We will discuss some low-cost, easy-to-learn formal software architecture evaluation methods. With a minimal investment, these can be used to determine how you can save millions of dollars per year in software maintenance costs and, at the same time, gain the ability to quickly develop new products off your software code base to capitalize on new product opportunities.
Why is migration an issue?
With the evolution of widely available Internet technologies, user expectations are rising around the level of integration they expect from their systems. To see how this can affect the development path of a medical software system, let’s examine the case of a typical point-of-care information system (POCIS).
The point-of-care (POC) marketplace is in flux as the scope of hospital information systems reaches deeper and deeper into department networks. At the same time, evolving standards are presenting both technological challenges and opportunities for connectivity among the various elements of a POC network.
All of these factors increase the value of software upgrades, as well as the pressure to create them. Many of the currently deployed systems are first- or second-generation devices. The transition from analog hardware-based solutions is long behind us, but many of the current-generation systems are designed around the premise of an isolated departmental subnet.
Growingly Increasingly, more sophisticated users are looking for complete location transparency when accessing their data. A doctor in a coronary care unit expects to be able to see the test results from an ECG that was taken yesterday in the ER. The HIS system can act as a common repository for information, but as a general-purpose system it cannot duplicate the specific functionality of the POCIS that generated the data.
 |
| Chart 1 |
Furthermore, POCIS integration with laboratory information systems (LIS) and HIS systems has, for the most part, been only on an as-needed basis. In the past, a lack of standards has also limited the availability of ubiquitous end-to-end POC integration. The de facto way of solving this dilemma has been through hard-coded location of proprietary connections and services. With the wide variety of commercial and homegrown healthcare information systems, implementing proxy point-of-care information systems is still very challenging.
With the introduction of the POC device to POCIS communications standards (POCCIC), and advances in POCIS to LIS/HIS standards (HL7 version 3), the bar for information system connectivity is being raised. The industry is far from settling on a single homogenous standard, but the technologies related to XML-based connectivity protocols promise a lot.
Apart from the need to adopt new technologies, emerging connectivity standards also introduce a number of qualities quality-of-service concerns that were either not present or less pressing in earlier systems. The ability to transparently access data across hospital networks, and potentially across the Internet, introduces a number of security issues to a system in which security was often addressed through physical controls.
The situation described above for a POCIS systems applies to all kinds of medical systems. Pressure of for change exists, and often the best path for change is ambiguous. Just about every software developer has seen at least one over-ambitious attempt to develop a completely new software platform that was aborted due to uncontrollable cost and schedule overruns. These experiences are career killers and can be company killers.
Unfortunately, the perceived low-risk path -- to continue enhancing the existing legacy software -- can also lead to uncontrollable cost and schedule overruns. Every software platform has a finite useful lifetime. Eventually a software platform loses whatever good structure it originally had and becomes nearly impossible to maintain. Enhancements and bug fixes are often made without attempting to preserve the integrity of the design. The effort needed to make enhancements or fix defects increases significantly. Every change introduces new defects, and programmer productivity levels plunge.
As a result, the risk of failure is high whether you try to develop new software or attempt to "just" continue enhancing the existing application. What should software developers do? The only practical solution is to figure out a way to incrementally migrate the existing software to an architecture that better meets the evolving requirements.
How is migrating the existing software any different than enhancing the existing software? The basic distinction is that migration involves proactively moving toward a new software architecture. Enhancements, on the other hand, are typically made within the constraints of the existing legacy software architecture.
The return on investment (ROI) implications of migration versus enhancing is dramatic. In a recent analysis, the engineering cost break-even point was less than two years for migration of a system’s software to an improved architecture. Engineering cost savings exceeded a factor of two in less than five years, compared with continuing to enhance the legacy software; and that ROI does not take into account the increased revenues enabled by an improved software platform that supports rapid new product development.
The basic steps for migrating existing software are as follows:
- Evaluate your existing software to determine migration suitability.
- Design the new target software architecture.
- Determine alternative plans for incrementally doing the migration.
- Choose the migration plan based on ROI analysis and short-term business drivers.
What does architectural suitability mean?
It is possible to incrementally migrate virtually any software system to a new architecture. However, in some cases it might lower both the cost and the risk to start over from scratch. And there are some cases where the best strategy will be to stick with your current architecture and simply continue to do enhancements. How do you determine whether your equipment or information system software should be migrated, replaced, or retained? Both the architecture of the existing software and the level of enhancement activity expected drive the answer to this question.
As a simple analogy, let’s consider the architecture for a house. Most houses have all the right functional components -- kitchen, living room, bedrooms, bathrooms, and so on. Some of these houses are a perfect fit for your current and anticipated future needs. Some of these houses you would rule out immediately because, for example, they don’t have enough bedrooms or you don’t like the floor plan.
Software systems have functional components analogous to rooms. In a POCIS these functional components include items such as the following:
- Interfaces to medical devices, both for configuration and control as well as collection of results.
- Local patient information and encounter tracking.
- Equipment monitoring and status (last calibration, levels of consumables, and so on).
- Interfaces to LIS systems for tracking work sent out.
- Interfaces to HIS systems for updating and retrieving patient information.
- User management and permissioning for assigning users access to specific data -- Health Insurance Portability and Accountability Act (HIPAA) compliance.
- Image management and storage.
The software components of an information system are expected to show a high degree of conceptual integrity -- just like the rooms of a house. For example, managing the image file system from within the medical device interface is a lot like putting a shower in the middle of a living room -- it just doesn’t make sense. In the house, bad architectural decisions like these reduce the appeal of the room and the usefulness of the shower. In a complex medical system, a bad architectural decision like this can make the software much more difficult to modify.
Although it sounds absurd to put a shower in the middle of the living room, analogous poor design decisions are common in the software world. In fact it is sometimes much worse -- like putting the shower’s hot water faucet in the kitchen and cold faucet in a bedroom. When building a house, the builder’s convenience is generally considered to be secondary to that of the occupants. When building software, the creators’ convenience often wins out over the maintainers’. Imagine walking into our strange house, finding the shower and not even knowing where to look for the faucets. Analogous situations happen every day for the software maintainer working on poorly architected legacy code.
Unlike the rooms of the house, however, medical systems do not have a standardized set of functional software components. For example, the kinds of devices installed in a POC will vary by the kind of care being given. Similarly, treatment of patient information may vary on the basis of whether it is operating at a referral-based facility or a walk-in (such as an ER).
It would be nice if there were a universal set of functional components for medical software. Unfortunately, this is not technically practical. Different types of systems have needs for different types of functional components. The wide diversity of the kinds of devices and procedures supported gives rise to a wide diversity of appropriate functional software components. Stated more formally, the organizing principles used in the software architecture must be derived from the functionality of the system. This concept was succinctly articulated by the Bauhaus school with the architectural dictate: "Form follows function."
So, evaluating the effectiveness of your existing software architecture is not as easy as taking an inventory of expected functional components. You need a process that accesses your architecture with respect to attributes that are specific to your type of application.
Evaluating an existing architecture
A good way to assess your current software is to use a formal software architecture evaluation process. The Software Architecture Analysis Method (SAAM), found in the book Evaluating Software Architectures by Paul Clements, Rick Kazman, and Mark Klein (Addison Wesley & Benjamin Cummings, Boston, 2002), was developed specifically for this purpose. SAAM focuses on the modifiability of a body of software. Specifically, critical aspects such as extensibility, subsetability, variability, and portability can be assessed. The evaluation process is based on an analysis of scenarios that represent possible future changes to the system. For each scenario, the necessary modifications are mapped onto existing software components and the costs of the changes are estimated.
As an example of the application of the SAAM process, consider the POCIS depicted in figure 1.
 |
| Figure 1: Topology of an example POCIS |
The software for this system was based on a client/server design with a number of medical devices communicating data bi-directionally through a device communication layer. Users could perform tests through the devices and access a series of services through a desktop thick-client interface. The desktop clients accessed information stored in a departmental data server. The individual device drivers stored data in the central repository using it as one mechanism to achieve device decoupling.
An architectural evaluation quickly reveals that the following types of new features are not handled well in the current system:
- As part of an information-access initiative at the hospital a physician now needs to be able to view patient data and test results that are stored in instances of the POCIS installed in other departments. For example, a physician in the coronary care unit needs to be able to transparently access information that was collected when running tests in the ER.
- As part of the same initiative, systems are expected to conform to an enterprise integration model. This model provides enhanced information access so that, for example, a physician can access an MRI image from his home location in San Francisco that was done at a member hospital while his patient was on vacation in San Diego.
- In order to save resources and improve service, the hospital is advocating central storage of all image data in PACS-compliant image servers. The POCIS needs to store all image data on these servers.
- In order to conform to HIPAA security guidelines, a security model is necessary that supports rule-based authorization and delegation.
- In an effort to decrease redundant entry and improve data accuracy, a POCIS is expected to access central order management and scheduling facilities when they are available. Local facilities still need to be supported for use in isolated installations and for walk-in encounters.
 |
| Figure 2: POCIS topology with enhanced connectivity requirements |
As shown in figure 3, the existing user interface and analysis layer make direct accesses to the operational database (including the image file system) without an intervening layer that provides location transparency. The lack of such a layer makes it more difficult to implement a resource locator that could handle cross-department requests or specialized storage by information type. In addition to the lack of location transparency in the data layer, the facilities that the existing system uses to manage encounters and schedules are well compartmentalized from a code-maintenance perspective, but have many implicit assumptions that require them to be implemented locally to the POCIS.
 |
| Figure 3: Example of an existing POCIS architecture |
With the addition of a network-enabled resource manager and service locator, as shown in figure 4, the goals established for this project can be accomplished much more efficiently. Furthermore, the new architecture encapsulates the areas of complexity associated with the new system aspects, isolating them from the existing investment in algorithm development.
 |
| Figure 4: POCIS architecture with a resource access layer |
After re-architecting, it is important to repeat the SAAM architectural validation process to ensure that additional architectural challenges are not uncovered. In this case, the presence of a remote resource provider means that authentication and authorization issues need to be dealt with here, as well as in the user interface.
This may result in a further architectural refactoring to expose the security services of the system at a lower level in the infrastructure. Infrastructure elements such as authentication, auditing, logging, and so on, are not depicted in this diagram, although they are an important part of any architecture, and of course necessary for HIPAA conformance. Adhering to a structured evaluation process dramatically increases the likelihood that all of the relevant quality-of-service issues will be uncovered early in the design and development process.
In addition to the immediate benefits of location transparency, a service and resource access layer also has the additional benefit of isolating the business logic in a middle-tier service layer. This separation of service logic and presentation logic will reap benefits in a future planned upgrade of the user interface.
In the above example, it is important to separate architectural issues from more routine coding issues. For example, even though the creation of new analysis modules might require a large engineering effort, the change needed is not an architectural change. All of the code changes are contained within a specific registered service, and the development of this service does not affect the interactions between the user interface and other components in the system. On the other hand, the need to invoke and collect results from analysis services offered by another department does require a significant architectural change.
Of course, a formal architecture evaluation process, like SAAM, requires that the existing architecture be well understood and documented. For many existing legacy software systems, the first step is understanding and capturing the existing architecture. This step is easiest to perform if the original architects are available. Typically, some archeology is needed to fully capture the existing design -- chances are that is it has evolved since its original implementation.
We also recommend the use of the Architecture Tradeoff Analysis Method (ATAM), a more comprehensive software architecture evaluation method also discussed in Evaluating Software Architectures, for assessing the new target architecture. It should be noted that ATAM could also be used to evaluate your existing architecture.
Our recommendation to use SAAM for this first step is motivated by the fact that SAAM is easier to learn, it takes less time to conduct and therefore costs less. In the context of evaluating an operational system, many of the quality attributes that ATAM explores "on paper" have already been well characterized through actual system usage.
 |
| Chart 2 |
Architecture evaluation approaches
There are some potential advantages to using ATAM to evaluate both the existing and the target architectures. SAAM is less comprehensive, so there is a risk that the evaluation will validate an existing architecture that has some serious shortcomings. ATAM helps ensure that the needs of all stakeholders are well represented across a wider set of quality attributes. Some of the more detailed work required for the ATAM can be performed once for evaluating both the existing and target architectures. For example, the utility trees (see chart 3 below), which precisely characterize the full set of required quality attributes, can be prepared initially for evaluating the existing architecture and then reused for evaluating the target architecture.
 |
| Chart 3 |
So, to refine our process a bit, we recommend that SAAM be used to evaluate the existing architecture. However, the evaluators should informally explore some scenarios outside the normal SAAM focus on modifiability. If problems are apparent, you should shift to the more thorough ATAM evaluation. For most software development organizations, the use of either SAAM or ATAM will be a huge improvement over the informal ad-hoc architecture design review approaches currently in widespread use.
By John Cadigan, Jim Everett-Wilson, and Norm DelisleAuntMinnie.com contributing writers
February 3, 2003
Join us tomorrow for Part II: New target-architecture design
Foliage Software Systems architects, designs, and delivers custom software and integrated systems for the medical industry. Foliage operates development centers at its headquarters in Burlington, MA, and in Campbell, CA. The company can be contacted in Burlington at 781-993-5500, in Campbell at 408-321-8444, or on the Web at www.foliage.com.
Copyright © 2003 Foliage Software Systems
