15. An Example Phase to Develop a
Clinical Data Repository (CDR)

15.1 Project Context: A Project Plan for a Phase

A phase constitutes a subproject within the overall project. Phases can completely or partially overlap in time. Phases can be done concurrently, or they can have dependencies upon each other, with a particular phase requiring the completion of a prior phase before it can be started.

This chapter presents an example phase in the automated patient medical record project. In this phase, HMO clinical systems will be interfaced with the automated patient medical record system. The current healthcare industry standard for interfacing these clinical systems is HL7 network protocol.

Information from the clinical systems needed by the automated patient medical record system would be stored on a database. In the healthcare industry, such a database that stores information from clinical systems is referred to as a clinical data repository (CDR).

For our automated patient medical record system, the CDR is a major portion of the information making up the patient medical record (e.g., encounters, orders and results). The CDR would later be expanded to include other patient medical record information (e.g., progress notes and other such documentation, orders made through the automated patient medical record system rather than the clinical systems, the complete on-line medical record including CPR and source document repositories).

Like for the total project, a phase is a project consisting of project steps. Project steps that can occur in a phase, and more specifically, in the CDR phase, are the following:

· Business Analysis Step: Determine business requirements for the CDR, required changes to the organization when the CDR is completed.

· Business Reengineering Step: Determine how employees will function differently due to the CDR. Determine how information from the CDR (medications, clinical laboratory orders and test results, appointments and outpatient registrations, inpatient stays) will be displayed through the automated patient medical record system, and how printed reports from the CDR will look.

· System Analysis Step: Determine technical requirements for the CDR database, for the interfaces with the other clinical systems to gather data for the CDR, and for code to support display and reporting of CDR information.

· Development Step: Based upon the System Analysis step, create the CDR database, interfaces between the clinical systems and automated patient medical record system, and the screens, dialogs and reports. (Note: This step only occurs within a phase, as phases are where actual products are created.)

· Implementation Step: Implement the CDR in the organization. (This step also only occurs within a phase.)

The CDR will eventually be expanded to include the full capabilities of the automated patient medical record system. Thus, the Business Analysis, Business Reengineering and System Analysis steps for producing the CDR must be consistent with the equivalent steps for the overall project. In other words, the CDR must be able to evolve into the full automated patient medical record system.

15.2 A Phase to Create a Clinical Data Repository

The CDR is a collection of clinical information—encounters, orders and results—from various clinical systems. This clinical information might include the following and more:

· Hospital stays from ADT (i.e., information on inpatient encounters)

· Appointments from the appointment system (information that could be used for outpatient encounters)

· Members registering for an outpatient visit (i.e., information on inpatient encounters).

· Laboratory orders and results from the clinical laboratory system

· Medications requested, medications picked up, and drug allergies from the outpatient pharmacy system

· Medications ordered and taken from the inpatient pharmacy system

· X-ray orders from the radiology system.

In section 13.2, as shown in figure 13.1, it was stated that building a software system is like designing and producing a watch: The externals are usually designed by a group who look at the system from an external or black box view, unconcerned with how the internals work. On the other hand, the internals are built by a group that needs to match up the internal subsystems with the external functions they need to support, thus requiring a white box view of the system. Figure 15.1 illustrates this black box / white box view as related to development of the CDR.

In the Business Analysis step of the CDR phase, a set of business requirements for the CDR would be developed. These business requirements would describe the business rationale for creating clinical system interfaces and the CDR. These phase business requirements must be consistent with the overall system business requirements for the total automated patient medical record system.

The phase System Analysis step would identify the CDR databases and system interfaces sending the information from the clinical systems to the automated patient medical record system. The phase Business Reengineering step would identify how the CDR information would be displayed within the automated patient medical record system.

The interfacing clinical systems would identify encounters and information that would provide a large part of the automated patient medical record: clinical lab orders, tests, and results; outpatient and inpatient medications; x-ray and interpretation of results; etc. The organization of some of these parts of the automated patient medical record—clinical lab tests and results, for example—could probably be determined by looking at screens and dialogs or reports within the originating clinical systems. And the organization of the CDR database within the automated patient medical record system could be partly determined by the organization of similar information in the clinical system databases.

The various clinical systems might have individual databases such as are shown in figure 15.2. In the hospital (ADT) system, admissions, discharges and transfers could be organized by the medical center facility where they occur. In the appointment system, appointments could be identified for each patient. In the outpatient pharmacy system, medications at a pharmacy could be in the order patients and physicians request the medications. In the inpatient pharmacy system, inpatient medications could be identified by hospital unit where patients are located. In the clinical laboratory system, clinical laboratory orders might be ordered by time received, with results being connected to orders, with possible amended results being attached as addendums.

From the overall Business Reengineering step and System Analysis step as described in previous chapters, it is clear that the automated patient medical record system will require a different organization for this clinical information—see the database in figure 13.16. Organizing this information by patient and encounter as if figure 13.16, we get the database shown in figure 15.3 combining encounters with orders and results.

The Business Reengineering step for the CDR phase would identify how the CDR database information would be displayed in the automated patient medical record system: the screens, dialogs and reports.

In the development of systems, screens and dialogs that logically function together are referred to as functions. For example, the screens and dialogs displaying clinical laboratory test orders and results could be one set of functions. A specification is written for each function, a functional specification. A functional specification should be written so that requirements for a function can be tested after development to verify that that the resulting function in the developed system works correctly. Functional specifications would be the products of the phase Business Reengineering and Development steps.

The CDR database, clinical system interfaces, and the code to support the functions would be defined in detail in the phase System Analysis step, resulting in written specifications for this code, these interfaces and the CDR database. These written specifications are referred to as internal design specifications. These internal design specifications would be products of the phase System Analysis and Development steps.

Interfaces between the clinical systems and the future automated patient medical record system would be recorded in an interface plan. The interface plan would be determined within the Reengineering, System Analysis and Development steps.

The functional specifications and internal design specifications would be used in the phase Development step to create the physical CDR system. In the phase Implementation step, the system would be installed in one or more healthcare organization locations for actual use. A phase Project Plan would create a project plan for tasks in the Development and Implementation steps.

Organizational business policies that apply to the CDR need to be incorporated. How these business policies are incorporated within the CDR code and databases needs to be recorded with the business policies so non-technical personnel can manage these policies. Example business policies for the CDR phase might include the following:

1. Security policies: Implement security consistent with organizational security policies, such as described in section 13.9.1. This might include physician or caregiver only access to the CDR patient information, smart card logon, automatic logoff in non-secure areas where patients are examined.

2. Access to psychiatry and genetic information: Restrict the display of patient psychiatry and genetic information to appropriate subsets of physicians or caregivers.

3. Assignment of primary care physicians for HMO members: Within CDR displays, the primary care physician assigned to a patient would be displayed.

4. Quality of information: All data will be verified for correctness and adherence to business rules for it.

At the end of a phase or at any other time in the project, there could be an Evaluation step that could be prescheduled in the project plan. Such an Evaluation step is referred to in this book as a “gate”, a point where a project is to be re-evaluated for costs, feasibility and adherence to the goals of the organization. See section 14.2.1.

15.3 A Business Analysis Step for a Phase

The Business Analysis step of a phase differs somewhat from that of the overall project. There are two differences:

1. During the Business Analysis step of a phase, obstacles are evaluated—For the overall project, this evaluation of obstacles is done in the Evaluation step.

2. During the Business Analysis step of a phase, there is a determination of whether or not the overall design of the system should be revisited.

Compare figures 15.4 and 2.3.

Evaluation of obstacles could be very costly, so during the overall project analysis this evaluation is deferred until after the evaluation of objectives (benefits), because the project might simply be rejected due to not providing enough benefits to the organization. On the other hand, a phase of the project is not started until there is a significant commitment by the organization of doing the project; thus, in such a case, there is no question that the evaluation of obstacles should be done in its entirety.

Some examples of reasons for revisiting the overall design during a phase are the following:

· The phase was defined by a research project and little was known about the phase at the start of the project; thus the phase was not included in the initial overall design--see example research phases in chapter 17

· It is learned in the phase that the phase requires information that is not available.

· The new phase takes over the functionality previously in another part of the system, and thus that other part of the automated patient medical record system must be changed

· The phase does something better than other parts of the project (e.g., has a better user interface) and the overall system should be changed to conform to the ideas of the new phase.

The extent of this revisiting of the overall design is dependent upon how much was known about the phase at the beginning of the project. For a complex phase where little was previously known about the phase at the beginning of the project (e.g., a phase done after research), this new overall design process may be as involved as the initial one.

For the CDR phase, for example, the Business Analysis step might discover that the clinical laboratory system or pharmacy system is incapable of identifying the encounter in which the clinical lab test or medication was ordered. In such a case, the clinical laboratory and pharmacy systems might have to be changed to include encounter information before the CDR phase begins. One way to insuring match-up of orders with encounters is to have all orders be done through the automated patient medical record system, requiring the caregiver doing the ordering to match up the order with the encounter before the order is sent over to a clinical system to be filled.

15.4 The Project Plan for the Phase, Breaking the Project into Tasks

The project plan for a phase will be a standard project plan consisting of a network of interrelated tasks, rather than a network of phases as was the case for the overall project. Chapter 14 discusses project management, both for phases and the larger project. Many good books exist on project management [1] and on project planning for software development [2,3].

In order to do the initial overall project plan, the project plan for each phase must be done to some extent, so the project plan step for a phase can use and refine this earlier phase project plan, in particular refining tasks for the Development and Implementation steps of the phase.

15.5 The Development Step

The Development step may only occur in a phase, not as part of overall design of the project. This is so because the overall design is done to pre-plan or re-plan the project, whereas a phase creates the products of a project. See figures 2.3.

A Development step only occurs if there is a new automated system or a change to an automated system in the phase. There are both in our example phase. There is likely to be many changes to existing clinical systems to interface them with the CDR, and there would be a new automated system, part of the automated patient medical record system, to collect the clinical information and store it on the CDR. (There also could be a new clinical system to replace an old one so it could interface with the CDR, but this would probably be done as a separate project outside the automated patient medical record project.)

The Development step takes two different forms dependent upon whether the automated system is developed in-house or procured from a vendor. In our example phase, implementing HL7 interfaces for clinical systems to send information to a CDR, some of these systems could be organizationally developed, while others are likely to be vendor systems.

15.5.1 The Development Step for an Organizationally Developed System

The Development step for an organizationally developed system (or subsystem), involves developing program specifications for the functions and programs making up the system, programming the automated system from these specifications, and testing the resulting automated system. On the other hand, changes to existing systems would involve changes to existing program specifications. Figure 15.5 identifies the parts of the Development step that are applicable for organizationally developed systems.

The phase to create the CDR would probably may involve organizationally developed systems in the following ways: (1) creation of a new subsystem to record information gathered from clinical systems to the CDR, and (2) changes to existing clinical systems to develop HL7 interfaces (e.g., collecting hospital admissions in ADT, clinical lab results in the clinical laboratory system) to send the information over to the new subsystem, besides (3) possible new organizationally developed systems or vendor systems to replace existing clinical systems which have HL7 interfaces.

The Development step for an organizationally developed system is described in more detail in section 15.7.

15.5.2 The Development Step for a Vendor System

The Development step could alternatively involve newly installed or changed vendor systems. Such vendor systems have been termed “commercial off-the-shelf (or COTS)” software [4]. Using COTS may produce significant savings in time and money over the initial creation and installation of a system within the organization. There are also many potential problems with using COTS systems, however, including the following [4,5,6,7,8,9]:

· no control of upgrades that may cause significant changes from the originally planned system, including unwanted ones

· other customers could disagree with any requested changes and thus the changes may never be implemented

· dependence on the vendor to make changes; as a result, changes could be implemented more slowly than required by the organization

· COTS are like black boxes and thus it is hard for system analysts to verify that the COTS perform safely, securely and reliably--a seeming “must” for an automated patient medical record

· for a COTS system, building a system to meet business requirements may not be possible; in fact, the reverse may be required, the business requirements might be dictated by the COTS system

· unless you are able to do performance testing, you will have to rely upon the vendor’s statements that their system can handle the transaction and database volumes needed by your organization

· the vendor company could go out of business.

Reference [10] describes strategies for the selection and installation of COTS (vendor) systems in detail, with an emphasis on systems that are used for an entire enterprise, such is the case with our automated patient medical record system.

Now, let’s consider the development step for a vendor system. Figure 15.6 identifies those parts of the development step applicable to vendor systems.

15.5.2.1 Procuring a Vendor System

The organization may decide to buy a new vendor system for a phase, e.g., a vendor clinical system that has an HL7 interface for a clinical laboratory for a region of the HMO. The clinical laboratory may not yet be automated or it might not be possible to convert the existing clinical system to include an HL7 interface, and thus the current system would need to be replaced.

The process of procuring an appropriate vendor system often involves the following: The organization sends out a request for proposal (RFP) to various vendors who produce clinical systems for the clinical laboratory, identifying necessary business and system requirements. Interested vendors would respond with a proposal describing how their system would satisfy the requirements, including how the vendor system would customized. System analysts, business analysts and users would test out the vendor systems, evaluate vendor proposals determining how closely they meet system and business requirements, and compare vendor system costs. A vendor would then be selected.

A contract for the vendor system is created, identifying agreed upon customization specifications. The vendor system with customizations is developed. Testers would produce a test plan for the customized vendor system according to system requirements, vendor documents and customizations. The vendor program would be tested, if there were any errors, the customizations would be changed and/or specifications would be updated. Retesting would occur until there were no errors detected in the developed system or specifications. Users would compare the tested system and user documentation supplied by the vendor against the previously agreed upon user interface requirements produced in the Business Reengineering step.

15.5.2.2 Changing a Vendor System

Changes to an existing vendor system, such as a clinical laboratory clinical system, would, on the other hand, involve negotiations between the vendor and the organization. A contract involving the new customizations would be developed, with business and systems analysts verifying that the system met systems and business requirements, including business policies. Thereafter, a test plan would be created and the system tested and revised until there were no errors in the system or specifications. If applicable, users would verify that the user interface is as expected.

15.5.2.3 Replacing a Vendor System

Where possible, vendor systems that follow existing industry standards both for systems and healthcare should be used (e.g., a clinical laboratory system that follows HL7 interface standards and clinical laboratory device standards as identified in the Appendix). This enables a vendor system to be more easily replaced by another vendor system or by an internally developed system that follows those same or similar standards.

Replacement of a vendor system is also facilitated by having a vendor contract that is flexible, which allows for change if there are unanticipated changes that require the system to be replaced. For example, periodic licenses offer more flexibility than very long term ones.

These ideas to facilitate the replacement of a vendor system with another vendor system or an organizationally developed system again fall under the concept of “component adaptability”.

15.5.3 Planning for Availability, Capacity and Performance

Important in developing an automated system or purchasing a vendor system is that the system be able to handle the current and future capacity of users, transactions and network traffic. Performance testers should provide advice to developers on how to develop systems that meet such capacity requirements, in particular on selection of the correct hardware, networks and system software. Performance testers should test vendor systems to see if they meet capacity and performance requirements before they are purchased.

Either for an organizationally developed system or for a proposed vendor system, performance testers could set up a “testbed” computer system for the new automated system, stressing the system with the expected future number of transactions and network traffic, mimicking the future system, to determine if the system will adequately function in the future.

Systems such as the automated patient medical record system must be available on a virtual 24 hour times 7 days a week basis. This requires thorough testing prior to release of the system to insure that there are no bugs in the system that cause the system to go down, as well as planning ahead for the future so the system does not reach capacity in terms of required disk storage, CPU and other requirements.

For (hopefully rare) situations where the system does become unavailable, it is important that there be a back-up mechanism to later input the information that was not input when the system was down and to later receive input from other systems that could not be received because a system or systems were down. Data input during this back-up process should also be sent to all interfacing systems that would have received it if the system was up, with the results of the input being identical to what it would have been if the system was up.

15.5.3.1 Service Level Agreements

In order to insure that the availability and performance of the system is adequate, a Service Level Agreement (SLA) could be written. This is a contract between the end users of the system and the group running a system and/or the vendor providing the system that makes an agreement upon a predefined level of service [10], in particular availability and performance levels. For example, the system must be up 99.5% of the time on a 7 x 24 basis, the system will support ‘x’ simultaneous users during its peak hour of a week, with 95% of users receiving a response time of 2 seconds or less during the peak hour. Application time-outs will occur less than once in 50,000 sessions. If the agreed upon service is not reached, or periodically falls below a certain level, the group running the system or the vendor would be penalized, e.g., monetarily.

Source Level Agreements are often made between a company’s information technology group running the system and the end users within the company using the system. Usually monetary penalties are not actually incurred in such a case.

If a vendor is contracted to not only provide but also run a system, then the SLA could occur between the company and that vendor. In such. a case monetary penalties usually incur upon performance or response times differences with the SLA contract.

An SLA could also potentially occur between a vendor who provides an application system and the company, who both has end users using the system and who also runs the system. Such a situation could be very complicated as the company provides some services (running the system) that could influence performance, while the vendor provides the product that also has an influence on system performance. An SLA may then have to differentiate the services that the company is responsible for and the services that the vendor is responsible for. For a vendor, additional agreements could exist to turn over vendor code to the organization if the vendor should fold.

A Service Level Agreement, in any case, is sort of like an insurance policy for performance problems, but does not make the performance problem go away. Like an insurance policy, it is best that it never be used. If performance does degrade a system significantly, even if all lost revenues could be recovered through the Service Level Agreement, the prestige of the organization could be effected, employees could be demoralized, and lawsuits could ensue. It could take a very long time to correct the performance problems.

15.5.3.2 Service Management Systems

System software, called “service management systems”, can measure system performance and record when it goes below a certain level (e.g., response time is too long). Such systems could be used to evaluate compliance with Service Level Agreements.

15.5.4 Planning for Data Conversion

During the development phase, a data conversion plan could be created to convert existing information on databases to the format of data required by new databases, such as the CDR. The data conversion plan would be executed during the next phase, implementation.

15.6 The Implementation Step

Like for the Development step, an Implementation step only occurs during a phase, not as part of overall design of the project. The Implementation step implements infrastructure for the project, an automated system, a change in an automated system or other change in the organization. An Implementation step does not need to involve an automated system.

See figure 2.10. Implementation could include installing the infrastructure for a system, such as computers, wiring and networks for an automated system; this should occur very early in this phase. Information in existing systems could be converted according to the conversion plan developed in the Development step to the format required by new databases. A tested development system could be installed. In coordination with the installation of the automated system, the users could be trained in the new systems and workflows, then the system would be used within the work environment using the changed workflows.

Our example phase might involve installing new wiring, computers, terminals and networks, replacing and changing clinical systems, which include HL7 interfaces, and installing the program and computer system(s) to interface with the clinical systems, including the program which puts the information on the CDR. If new clinical systems are required, because existing ones are inadequate, training of users of the new systems would also be required.

If a new clinical system replaces an old one, then conversion of existing data from the format of the old system to the format of the new system may be required with transfer of the data from the old to new system. Thereafter, and users would eventually have to stop using an old system and start using the new system.

15.6.1 Approaches to Phasing Out an Old System

Reference [11] identifies a number of different approaches for phasing out an old system and phasing in a new one:

· direct cut over: turning off the old system the day the new system goes into operation--a very risky approach

· parallel operation: running both the old and new system concurrently and comparing results to verify both systems function alike

· phase in: running the new system in a portion of the enterprise first, adjusting the way it works if necessary, and incrementally replicating it in other parts of the enterprise

· limited parallel operation: running the new system with real data to test and verify functionality, but the new system does not completely parallel the old system

· retroactive parallel operation: using the old system for running the business and entering the same data in the new system whenever th e day-to-day operations permit.

15.7 In-House Development of an Automated System in More Detail

This section describes the Develo8pment step for an automated system developed inside the healthcare organization.

15.7.1 The Development Step in the Software Development Life-Cycle

The software development life-cycle, an example of which is shown on the right in figure 15.7 [12], is often used to describe the software development process. The corresponding project steps described in this book are shown to the left of the software development steps.

The conception of the automated system occurs as the first part of the software development life-cycle. Correspondingly, in the Business Analysis step of the project, the mission for the project is determined.

Requirements are the next step in the software development life-cycle. In the project steps, business requirements are determined during the Business Analysis step and user interface requirements are determined in the Business Reengineering step.

The next step in the software development life-cycle is the design step. In the project steps, the design of the user interfaces may be part of the Business Reengineering step, with the initial design of the programs within the automated system being done in the System Analysis step.

The next steps in the software development life-cycle are the implementation and test steps, programs are created, interfaced and tested. These steps together are equivalent to the Development step of a project, which is based upon the system design in the System Analysis step and user interfaces from the Business Reengineering step.

The final steps in the software development life-cycle are operation and maintenance. The project steps include an implementation step to do user training and reengineering of the organization prior to operation and maintenance, which would exist as part of the software life-cycle, but are not usually broken out as a separate step in the software life-cycle.

Maintenance is the process of changing a system after it has been delivered and is in use.

Although the diagram is figure 15.7 may not be true to the time scale of each step, some references note that testing can take up 50% of the development effort [13], while maintenance could take 50-80% of the total costs of an automated system, including all the costs from conception to retirement. This emphasizes the importance of automated system testing and maintenance, which will be discussed further in the following sections.

15.7.2 The Development Step in More Detail

As is implied by figure 15.7, the Development step includes coding of the automated system and testing of the automated system. Figure 15.8 expands on these coding and associated activities and upon the testing activities, which together make up the Development step.

Coding

Coding an automated patient medical record includes writing specifications upon which the code is based. The functions making up the automated system, which would be identified and described in the System Analysis step (see section 13.14.1 and figure 13.51), are described in detail during the Development step through program documentation. This program documentation includes functional specifications, each describing a subsystem or function making up the automated system, and internal design specifications, each describing a program making up the subsystems and functions.

Databases and interfaces identified in previous project steps that are used within a function are referenced within the functional specification. Those that are used within a program are referenced within the internal design specification.

The programs are then coded based upon the functional specifications and the internal design specifications. As the automated system is developed through the coding of the functions and programs, the resulting system is used to simulate production use of the system, with user review of the system.

Testing [12]

Testing involves validation at the end of development to run the resulting code to show that it functions as identified by the functional specifications and internal design specifications, and verification that involves “human comparison” of the requirements for the system with the resulting functions and programs.

Validation involves first validation of individual functions and programs (unit testing), validation of these functions and programs working together into subsystems and in the entire automated system (integration testing), and validation of interfaces between the automated system and other automated systems (interface testing).

During development, the automated system should be tested by users during a simulation of production use of the system (usability testing). Acceptance testing is the process of comparing the end product of development with the current needs of its users; acceptance testing often involves operating the system in production for a pre-specified period.

During the creation of the program specifications, these specifications should be verified as matching the requirements. Whenever there is a mismatch, then the inconsistencies should be corrected by changing the program specifications or code to match the requirements, or sometimes, by reviewing and possibly changing the requirements for the system.

System testing is the process at the end of development to validate that all the requirements have been satisfied by the automated system. Requirements include requirements of all sorts identified so far: business requirements, user interface requirements, security requirements, performance requirements, volume requirements, reliability requirements, etc.

For example, one form of system testing is testing the system for bottlenecks that could cause the system to take a long time to respond to users when many users are using the system (performance testing). Because of the expense of performance testing, it is not often done until problems in response time are found; however, this book identifies how cost-effective performance testing can be done prior to production. See sections 10.12 and 11.7.

Whenever inconsistencies or errors are found through validation or verification, the code or documentation should be corrected, with subsequent retesting, which should include testing of all the parts of the automated system.

Functional specifications and internal design specifications should be maintained along with the program into the “operation and maintenance” step in order to make later changes to the automated system easier. The requirements for the automated system should also be preserved; this is best done by including the business and user requirements associated with a function within the functional specification. When there is a change made in a function during maintenance, the functional specifications and internal design specifications would be changed along with the program, with testing insuring that the changed program matched up with changed specifications and requirements.

After maintenance changes are made, tests done during development or previous maintenance could be re-done to insure that parts of the system that should not be changed continue to function as before. This retesting after a maintenance change using previous tests is called regressive testing or regression testing.

15.7.3 Building for Maintainability of the Automated System in the Development Step

As stated in section 15.7.1, maintenance could involve 50-80% of the total costs of an automated system, including all the costs from conception to retirement. Maintenance is the process of changing a system after it has been delivered and is in use. Maintainability is a measure of how easy or hard it is to change the system without introducing new errors in the system or inconsistencies in the requirements.

Part of the maintainability of a system is dependent upon things that are done in the coding part of the Development step. Figure 15.9 describes some things that could be done during coding to make the system more maintainable or less maintainable.

15.7.3.1 Documentation

Maintenance changes, like the original software design itself, are based upon either correcting errors or upon changes to requirements.

Requirements should be clearly recorded for the system in documentation and when there is a change to a requirement, the associated documentation should be updated to incorporate the changed requirement. The maintenance change can then be based upon this documentation.

Without any documentation on the system, no one in the automated system’s maintenance group really knows how the automated system, functions or programs are supposed to work.. Without documentation, knowledge of the system is dependent upon key employees; if these key employees go away, then the system becomes unmaintainable. Additionally, unknowledgeable members of the maintenance group have no checks on changes they will make, introducing unintended features which have little or no relationship to the original requirements of the system.

On the other extreme is having a complete set of documentation as is shown in figure 2.11, with each item in each document being traceable to the sections in each other document. Although this would describe the system and its requirements in complete detail, doing this would be cost prohibitive. The best approach is something in between these two extremes.

This book suggests that, for the maintenance phase, keeping functional specifications for the subsystems and functions in the system and internal design specifications for each of the programs, with the functional specifications including the requirements related to the functions.

15.7.3.2 Requirements-Based Code Versus Solutions-Based Code

In order to match code back to requirements, it is useful to relate variables and data back to requirements-based concepts rather than solutions-based concepts.

Requirements represent “what” was done, and sometimes also “why” it was done. Solutions represent “how” something was done. There are most often many solutions for a requirement.

For example, a requirement might be “if appointment is considered critical and patient does not show up for the appointment, put the patient on a list to call the patient”. Code in the form, “if appointment-critical and patient-not-seen then …” relates to requirements-based concepts. Code in the form “if (appointment-priority = 3) and (appointment-status = 4, 5, 9, 21, 23 or 64) then …” in replacement doesn’t.

The latter code suffers from a number of problems that make it difficult to later relate the code back to the requirements: (1) “appointment-priority” and “appointment-status” are solutions-based concepts rather than a requirements-based concepts. (2) “appointment-priority” and “appointment-status” address concepts at a lower, finer level than that of the requirements concepts “appointment-critical” and “appointment-no-show”. (3) “appointment-priority” and “appointment-status” use solution-based values (3, 4, 5, 9, …) instead of more descriptive ones (e.g., critical-appointment, appointment-canceled, patient-no-show, etc.).

15.7.3.3 Modularity and Information Hiding

“Modularization” and “information hiding” are two ways of simplifying programs. “Modularization” is breaking up code into smaller blocks of code. “Information hiding” is hiding data or code from a programmer that the programmer does not need to know about.

The most useful way to modularize a program is to create routines, functional common code which can be used many times within a single program or by many different programs. Routines are described by “what” they do and the information provided to the routine, the inputs, and the information returned from the routine, the outputs.

Consider the following: A very large subsystem of the automated patient medical record system is written as one large program and all the data within the program is in global storage (i.e., the data in storage can all be read or updated at any point in the program). Further, “goto” statements appear liberally throughout the program, with the “goto” jumping to any point in the program.

This is a very difficult program for a maintenance programmer to maintain for a number of reasons: Firstly, the programmer has to comprehend, and take into account, the entire large program and all of its data to make changes. Secondly, the programmer has to consider that data can be corrupted at any point during the program. Thirdly, the program does not take into account there being any common code used repeatedly within the program, which there often is in many programs.

Some ways to make the program simpler are the following:

a. Modularity: break code into smaller and, ideally, re-useable modules (less complex) versus a single continuous program (more complex)

b. Getting Rid of “GOTOs” by Use of Structured Code: use structured code constructs (less complex) versus non-structured constructs such as goto (more complex, possibly producing “spaghetti code”). Figure 15.10 identifies structured coding constructs [14]. (Note: Many computer languages only support structured coding constructs.)

c. Information Hiding Via Restricting Scope: hide information from the programmer that he does not need to know about by restricting the scope of a variable to a particular program or routine (less complex) versus making the information global (usually more complex)

d. Information Hiding Via Object-oriented Techniques: hide information and routines from the programmer that he does not need to use via object-oriented techniques of making data elements and methods private instead of making all of it public.

Modularization, including use of object-oriented methods, is itself a form of “information hiding”, as the modules can be considered to be “black boxes” as the programmer using them needs to know “what” the module does and what are its inputs and outputs, but does not need to know “how” the module does what it does. As long as the “what” and inputs and outputs remain the same, the “how” can change without the program using the module needing to be changed.

Use of structured code to eliminate “GOTOs” facilitates the break up of programs into modules.

15.7.3.4 Simple, Understandable Code

Because a program is likely to later be maintained, a program, besides being functional, should be a form of communication, providing the future maintenance programmer with sufficient information on the program to easily maintain it. Thus, all means should be used to make the program understandable.

Examples of ways to make a program simpler or more understandable are the following:

· When the programmer has a choice between a “clever” way of doing things in code versus a “simple” or “commonly used” way of doing things, he should always choose the latter.

· Ideally, a simple, straight-forward style of programming should be agreed upon at the start of Development and used in the entire project.

· When a maintenance programmer makes changes to a program, he or she should follow the same style used in the program.

· Conventions that are commonly used in the industry should be enforced. For example, for Microsoft Windows programs in C and C++, the convention is to differentiate different types of variables by a prefix to the variable depending upon type of variable, called the “Hungarian Naming Convention” [15]. This may simplify the code.

· As stated earlier, code should be requirements-based, rather than only solutions-based. See section 15.7.3.2.

15.7.3.5 Standards

For a large-scale complex project in a healthcare organization involving automated systems, there are at least two sets of standards that are important:

1. General computer-related standards

2. Healthcare standards.

For maintenance reasons, it is important to have standards because

· There is a greater number of maintenance programmers and programmer analysts who are available to be hired, and thus inability to maintain the system due to unavailability of appropriate personnel is less likely.

· The automated systems can be more easily interfaced with outside automated systems in the future, in particular with the universal patient record.

· Industry-wide standards are produced by a large number of experts meeting together, thus producing a standard with wide applicability.

· Code upon which an industry- wide standard is based is most often maintained outside the company using the standard, thus, saving on maintenance costs for the company using the standard.

· Industry-wide standards are likely to be very well defined, thus reducing the chance for errors.

Healthcare standards are described in the appendix.

There are many computer-related standards, including those for

· programming languages (There are standards for many languages, but the most commonly used standard languages are C++, COBOL, and Java)

· database management systems (IBM’s DB2 and Oracle are more used than other systems)

· database query language (SQL is the standard)

· network communications (TCP/IP; IEEE and ANSI have compatible standards [16])

· distributed code (CORBA, RMI, and DCOM are the standards)

· operating systems (UNIX, LINUX, IBM MVS, and the current versions of the Microsoft Windows operating systems)

· Internet scripting language (HTML and XML in the future).

15.7.3.6 Consistency and Intuitiveness

There are two levels of consistency and intuitiveness that are important in the Development step: consistency and intuitiveness in the code, and consistency and intuitiveness in the user interface.

Consistency in code—for example, using the same set of modules throughout, such as modules for user input editing—allows one programmer to copy and reuse the code of others. Consistency and intuitiveness in the code makes it easier for one programmer to understand the code written by other programmers.

Consistency and intuitiveness in the user interface allows the user, in this case the caregiver, to concentrate on his job, caring for the patient. For example, doing the exact same thing differently on three different screens—say selecting an encounter—forces the caregiver to stop and think about what the screen does. Selecting the encounter the same way on all screens—the most intuitive approach that is consistent with other parts of the system and meets standards—enables the caregiver to give greater concentration to caring for the patient.

References

[1] Joan Knutson and Ira Bitz, Project Management: How to Plan and Manage Successful Projects, AMACOM (a division of the American Management Association), 1991.

[2] Neal Whitten, Managing Software Development Projects, John Wiley & Sons, Inc., 1995.

[3] Tom Gilb, Principles of Software Engineering Management, Addison-Wesley Publishing Company, 1988.

[4] Jeffrey M. Voas, “The Challenges of Using COTS Software in Component-Based Development”, Computer, June 1998, Vol. 31, Number 6, pp. 44-45.

[5] Nancy Talbert, John McDermid, “The Cost of COTS”, Computer, June 1998, Vol. 31, Number 6, pp. 46-52.

[6] Jeffry M. Voas, “Certifying Off-the-Shelf Software Components”, Computer, June 1998, Vol. 31, Number 6, pp. 53-59.

[7] Ulf Lindquist and Erland Jonsson, “A Map of Security Risks Associated with Using COTS”, Computer, June 1998, Vol. 31, Number 6, pp. 60-66.

[8] Qun Zhong and Nigel Edwards, “Security Control for COTS Components”, Computer, June 1998, Vol. 31, Number 6, pp. 67-73.

[9] Barry Boehm and Chris Abts, “COTS Integration: Plug and Pray?”, Computer, January 1999, Vol. 32, No. 1, pp. 135-138.

[10] Gilbert Held, “Understanding SLAs”, Network Magazine, June 1998, Vol. 13, Number 7, pp. 82-86.

[11] Sergio Lozinsky, Enterprise-Wide Software Solutions: Integration Strategies and Practices, Addison-Wesley, 1998.

[12] Edward Kit, Software Testing in the Real World: Improving the Process, Addison-Wesley, 1995.

[13] Ian Sommerville, Software Engineering, Addison-Wesley Publishers, Ltd., 1996, p. 539.

[14] F. Terry Baker, “Structured Programming in a Production Programming Environment”, Software Design Techniques, Second Edition, IEEE Computer Society, 1977.

[15] Steve McConnell, Code Complete, Microsoft Press, 1993, p. 202-206.

[16] Michael A. Pastore, Networking Essentials: Rapid Review Study Guide, Duke Communications International, 1998.

NEXT
TABLE OF CONTENTS

Comments? mailto:Michael.McGuire@abac.com