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