Ongoing Development of the Critical Care Information System: The Collaborative Approach to Automating Information Mnagement in an Intensive Care Unit Marilyn Hravnak R.N., MSN, CCRN Instructor, Critical Care Specialty* School of Nursing, University of Pittsburgh Associate Project Leader, Critical Care Information System University of Pittsburgh Medical Center Keith L Stein M.D., FCCP, FCCM Associate Professor, Anesthesiology/CCM and Surgery School of Medicine, University of Pittsburgh Medical Director, Cardiothoracic Surgical Intensive Care Unit Project Leader, Critical Care Information System University of Pittsburgh Medical Center Bruce Dale, B.S. System Administrator, Critical Care Information System University of Pittsburgh Medical Center James C. Hazy, M.B.A. Director, Clinical Information Systems Information Services Division University of Pittsburgh Medical Center INTRODUCTlON It is necessary for configuration and functionality of any point-of-care information system in the Intensive Care Unit to meet the needs of a multitude of individuals and hospital based departments. Nurses require a tool that will expedite the flow of work, clinical decision-making, and implementation of the nursing process. Internal documentation requirements must be met, as well as those set forth by external regulatory agencies. Physicians also require a standard composition of information obtained which facilitates clinical decision making and workflow. Members of the Medical Records and Utilization Review Departments wish information to be presented in a manner which streamlines auditing and coding, and the Fiscal Department desires methods which assist or automate billing and revenue capture. Current system functionality, interface to other departmental computer systems, and decision support needs must also be taken into account when determining system configuration and format. The computer expertise and support of
ARSTRACT Point-of-care (bedside) clinical information systems can fulfill a variety offunctions. Included in these functions are: becoming receptacles for patient data and allowing data to be manipulated into formats that facilitate clinical decision making; functioning as sources for billing and auditing processes; interfacing to other hospital systems and bringing distant data to the bedside; and being a repositoryfor information used in the development of hierarchical and/or relational databases. The initial and ongoing development of these systems in a dynamic clinical environment requires the construction of processes and work pathways to ensure that the needs and requirements of myriad personnel, departments and agencies within the health center milieu are addressed. * supported by U.S. Department of Health and Human Services, Division of Nursing, Critical Care Nurse Training Grant 1 D23 NU00976-01
0195-4210/92/$5.00 01993 AMIA, Inc.
3
then function as a resource and coordination point for further product enhancement and development in the future.
the Information Services Division is necessary for system installation, management and growth. The development of a point-of-care information system in the ICU that will meet the needs of the direct caregivers, facilitate fiscal and auditing activities, and interface to other components of the Hospital Information System requires a collaborative
POSTIM1PLEMENTATION Once the system has been implemented, it is important that staff within individual departments are queried on a continuing basis to ensure that needs are being met, and problems are minimized. It has been our experience that hospital personnel, particularly nurses, are remarkably adaptable and will develop "workarounds" or acquiescence to system deficiencies because notification systems may be cumbersome and take time away from direct patient care activities. It is therefore important that identified staff members (or personnel with a specific interest in the implementation process) observe practice and become involved in the development of enhancements to the computer system based on observation as well as verbalized need. We had not prepared mechanisms for ongoing development of the point-of-care Critical Care Information System installed in our facility prior to implementation. The following relates the problems we encountered after implementation, and the mechanisms developed for problem resolution. PROBLEMS Soon after system implementation it became apparent that further customization of the application was necessary. Deficiencies in prior knowledge, inability to gain "live" experience on the system, the use of only small groups to draw upon for comment, and an environment with constantly changing technology and practice all contributed to the need for further changes and enhancements to the initial application. Users began to come forth with a large number of "problems", and no process was in place to assess the problems and identify solutions. The situations we encountered were as follows. Problem identification was random. Situations were identified almost daily that were being touted as "problems", but we were not adept at differentiating problems from complaints or non-problems, or determining the severity of the problem. The approach to an isolated problem verbalized by an occasional user of the system should be different from the approach to those problems identified by several individuals who are daily users, or those having great clinical significance. Deficient mechanisms for identifying problems also resulted in deficient mechanisms for
multidisciplinary approach. PREIMPLEMENTATION Prior to customization of the generic product provided by the vendor, it is important that individuals from the departments subject to either direct or indirect impact learn something about the system. In most cases, the users have not previously worked with point-of-care information systems or even computers. If the users are not well informed regarding the function and potential of their new system, there is a compulsion to format the computer system to display and perform in a manner identical to that of the antecedent paper system. Such an approach does not allow the full advantage of the computer system to be realized, and impedes the improvement in workflow and practice which are among the desirable effects of computerization. Initial customization work should be done only to the degree necessary for basic system function within the particular unit or hospital environment. Further customization work is better left until the users gain experience, familiarity and facility with the system. Preliminary customization is usually based only on input from a small number of relatively inexperienced users. Later, the input from a wider variety of then computer savvy users can be employed to tailor both the system and their clinical practice to their needs and developing objectives. However, involvement by a representative number of personnel from all departments affected by the system or its output early in the development phase fosters the evolution of a sound foundation upon which further customization and enhancement can readily occur. It is also important to have training in system utilization conducted by representatives of each involved department. These representatives can better speak to the needs of their own personnel, and give rationale for decisions which have been made affecting their own area. In addition these trainers, who usually have an interest in, and facility with, the system can evolve into an ongoing information resource for the staff members and develop into "superusers". They may
4
appearance of the proposed change within the application, and its likelihood of solving the problem. Once programming was concluded, we had no process for evaluating the function and effectiveness of the enhancement prior to clinical usage. We did not have a process for evaluating if other parts of the dynamic clinical application were being adversely affected by the change. Even when technical function was appropriate, we had no mechanism for systematically soliciting user opinion as to whether or not the enhancement had indeed solved the problem. Lastly, we lacked a mechanism for keeping the clinical staff informed that problems were being addressed, the manner in which they were being addressed, and when to anticipate the changes and resolutions. Lack of an identified process to identify problems and achieve resolution resulted in frustration of the part of both clinicians and system administration staff.
dealing with them. In some cases the problem resulted from inadequate or forgotten training, and required education as the resolution. In other cases, the problem resulted from policy or protocol applicable to the paper system but no longer applicable to the computerized system, and resolution required revision or generation of policies. In yet other cases, correction of the problem would require a change or addition to the configuration, but we had no organized process for gathering information and soliciting appropriate input for the proposed change. Lack of a consistent process for communication between the clinical staff and the system administrator (an individual responsible for ensuring appropriate function of the hardware and software of the system, but without previous clinical expertise) presented an additional problem. Clinicians from many different levels and disciplines were approaching the system administrator (SA) with problems, but the SA had no way to independently ascertain the immediacy or importance of the problem, quality of the proposed solutions, or authority of those making Personnel wandered in at the requests. inconvenient times, breaking the flow of work for the system administrator. Without clinician input, it was difficult for the system administrator to prioritize the changes and enhancements to be made based upon clinical need. It was also difficult for clinician and system administrator alike to determine which changes and enhancements were being developed or programmed, and the status of each job within the development process. We have found it difficult to take an idea generated by a clinician and translate it to a functional equivalent within the information system. Requirements must be specified in a manner and language understandable to programmers who are without clinical experience. For example, if a new parameter were to be added to the system, the programmer would require information concerning title and abbreviation, units of measurement, placement and content of menus and popups, format of the data cell with number of alphanumerics and decimal places, range warning for checks and errors, and preprint, carry forward and scrolling capabilities. We did not have a process in place for clinicians to document their requests in the above format. An additional problem proved to be lack of a systematic evaluation and review of requested changes. Prior to programming, we had no mechanism for gaining a consensus regarding the
THE SOLUTION As a first step, a working group composed of clinicians was developed. Although comprised of nursing staff at this point, the group addresses the clinical needs of all categories of the health care team. Three members of nursing administration, three senior staff nurses and three junior staff nurses are the constituents of the group. Based upon their own observations of system usage in the clinical arena, they identify problems and deficiencies. In addition to reacting to ideas for improvement generated internally, group members also serve as conduits for recommendations and impressions from other clinicians and nonclinicians. The organization and function of the working group is recognized by other personnel and departments, and the flow of questions, concerns, problems, recommendations, and ideas for enhancement are channeled to group members. Group members then bring this information before the entire group. To date, projects acted upon by this group have been stimulated by requests or ideas put forth by physicians, laboratory personnel, the Pain Management Team, and Quality Improvement, as well as nursing staff. Group meetings are held weekly. At each meeting, the group evaluates problems or ideas that have appeared in the previous week. The group evaluates the magnitude of the problem, and possible solutions. In some cases, the solution is communication or reeducation. A communication
5
bulletin board resides within the clinical unit, and notices, memos and meeting minutes from the workgroup are posted. In some cases reeducation requires direct communication, and an established "communication tree" is activated. Each group member is responsible for communicating or training approximately ten staff members on an informal basis. In cases of major changes or software releases, formal training sessions are scheduled outside of the unit environment. If it is felt that the problem requires a change or enhancement to the current application, the work pathway depicted in Table 1 is activated. A sponsor for the project is designated, and the project is assigned a number for tracking purposes. Outside of the meeting time, the sponsor develops an idea for the change or enhancement on paper, and solicits the input of clinicians from involved disciplines. Projects may focus upon nursing issues and documentation, but at times do not. In one example, group members worked with the unit based physician team for development of a Physician's Summary Sheet intended for use during routine morning rounds. In another example, the group worked with nephrologists who desired a summary sheet focusing on information they required for writing hemodialysis orders. Recommendations made by laboratory personnel have resulted in changes or enhancements to the laboratory report sheets. Currently, work is being conducted to implement documentation by the To assure that Respiratory Care group. documentation requirements are being met, group members refer to procedure and policy manuals, standards of care, and quality improvement indicators. Information and insight may be solicited from the Medical Records or Utilization Review Department. The opinions of the Risk Management Department, as well as the hospital's legal counsel have been sought. The sponsor may gather this information independently, or develop ad hoc meetings of personnel from appropriate disciplines for clarification and collection of information. Once sufficient information and opinion has been gathered and incorporated, the sponsor refines the idea and presents this more finalized version during a workgroup meeting. The group may give approval, or recommend further changes. Once finalized, the sponsor then transfers the idea from the working draft into terminology and format suitable for translation by the system administrator into programming. The project is forwarded to the system administrator, and placed
1.
Table 1: Work Pathway Problem or idea identified, brought forward at workgroup meeting.
2.
Project is assigned a sponsor.
3.
Sponsor formulates proposed change or enhancement, solicits input from multidisciplinary team.
4.
Sponsor presents solution to workgroup for approval, workgroup prioritizes in the queue.
5.
Sponsor completes documentation necessary for system administrator; project is assigned a number.
6.
Projects comes forward in the queue, sponsor meets with system administrator for project and documentation review.
7.
Project programmed and placed within the "test" group. System administrator checks technical function within the test group.
8.
Sponsor assesses project within the "test" group.
9.
Sponsor presents project to workgroup for approval. A date for clinical installation determined based on time necessary for appropriate education.
10.
Staff education for the project application is conducted.
11.
Project installed in the clinical group, technical function within the dynamic clinical group is assessed.
12.
Opinions from multidisciplinary team solicited to determine if the project meets the need or solves the problem.
13.
Appropriate paperwork concluded, project is closed.
in a prioritized queue. When the project comes forward in the queue to be worked upon, the sponsor meets with the system administrator to review the project and accompanying paperwork. Programming then ensues. After completion of
6
pain relief and subsequent titration of therapy. A nurse assumed sponsorship of the project. She gained input from physicians, staff nurses, the Pain Management Protocol, unit documentation standards and JCAHO standards. The Analgesia Assessment parameter added as an optional item on the Vital Signs Flowsheet is illustrated in Figure 1.
programming, the system administrator conducts a technical check on the application within the "test group", and the sponsor conducts a content check. The project within the "test group" is then presented by the sponsor to the work group at the weekly meeting. A consensus is required to move the work into the "clinical group". Prior to installation in the clinical setting, the workgroup determines the communication mechanism necessary to educate the staff on the new application, and the date of installation. Minor changes may be communicated through a notice on the bulletin board, more involved changes may require a memo for clarification, and the most complicated changes may require personal communication through activation of the communication tree. The enhancements or changes are installed into the clinical application during a weekly prescheduled downtime, enabling the staff to become accustomed to a standard date on which changes may be anticipated. Once installed, functionality of the change is reassessed within the dynamic clinical group by the project sponsor or designee. A last, but very important step, is solicitation of input from the users to determine if the change meets the clinical need, and corrects the problem for which it was intended. Two mechanisms are used to communicate the above progress of events to the multidisciplinary team that governs the CCIS project. A calendar is kept in the system administration work area on which dates are posted for reboots and software installations, as well as meeting times for the various workgroups. Other dates, such as arrival and installation of new software, additional personnel, vacation or conference dates, and milestones are listed. On a second board, each project is tracked. This board is divided according to the steps in the process (see Table 1.) and as each step is completed, the project is moved along on the board. In this manner, all personnel are aware of the status of each project, from genesis of the idea through final testing and outcome.
ANALGESIA
'Eoid Bol I
Mode
Pain Scale ASSESSMENT Sedation Scale l~~~~~~~0
1. 2. 3. 4. 5.
6.
7.
8. 9.
£0.
IV Therapy
Epidural Bolus Epidural Continuous PCA PCA Continuous PO Therapy IM Therapy
SQ Therapy Intrathecal Nerve Block
0. 1. 2. 3. 4.
L5.
10 IC
11
-
none
>
10 9 0. 0 - No Pain 1. 2. 3. 4. Moderate Pain 5. 6. 7. 8. 9. 10. 10I Worst Imaginable Pain
I 0 - none (alert) I - mild (occ drowsy; easy to rouse) 2 - mod (freq drowsy; easy to arouse) 3 - severe (somnolent; difficult to arouse) S - sleep (normal sleep; easy to arouse) U - unable to assess (ie:
p2arelyzed/.anes)
Figure 1. Example of a project implemented via the work pathway. An Analgesia Assessment parameter with corresponding pop-ups.
CONCLUSION Because a point-of-care clinical information system resides in a dynamic environment, it is necessary for the system and applications within the system to remain dynamic as well. A collaborative multidisciplinary approach is necessary to ensure that system changes and enhancements meet the expectations of all involved health care team members and departments, and that the needs of the patient as well as the needs of the organization are met.
ACKNOWLEDGEMENTS The authors acknowledge the effort and ongoing work done by the Clinical Workgroup, as well as the continuing faith and support of the staff of the Cardiothoracic Intensive Care Unit, University of Pittsburgh Medical Center. Special thanks to: Jane Guttendorf R.N., Clinical Nurse Manager; Darcy Waechter R.N. and Rick Call R.N., Clinical Coordinators; Shari Ferranti R.N., Elaine Fraga R.N., Margaret Lucas R.N., Kim Porco R.N., Karen Rosco R.N., Donna Saffer R.N., Janet Toth R.N.
Exmple of the Solution. Physicians on the Pain Management Service direct intermittent epidural narcotic administration via protocols. Nursing utilization and documentation of pain and sedation scales was inconsistent. Scaling required reference to a legend that was frequently not accessible at the bedside. Physicians communicated their desire for better documentation to facilitate trending of
7
ARSTRACT Point-of-care (bedside) clinical information systems can fulfill a variety offunctions. Included in these functions are: becoming receptacles for patient data and allowing data to be manipulated into formats that facilitate clinical decision making; functioning as sources for billing and auditing processes; interfacing to other hospital systems and bringing distant data to the bedside; and being a repositoryfor information used in the development of hierarchical and/or relational databases. The initial and ongoing development of these systems in a dynamic clinical environment requires the construction of processes and work pathways to ensure that the needs and requirements of myriad personnel, departments and agencies within the health center milieu are addressed. * supported by U.S. Department of Health and Human Services, Division of Nursing, Critical Care Nurse Training Grant 1 D23 NU00976-01
0195-4210/92/$5.00 01993 AMIA, Inc.
3
then function as a resource and coordination point for further product enhancement and development in the future.
the Information Services Division is necessary for system installation, management and growth. The development of a point-of-care information system in the ICU that will meet the needs of the direct caregivers, facilitate fiscal and auditing activities, and interface to other components of the Hospital Information System requires a collaborative
POSTIM1PLEMENTATION Once the system has been implemented, it is important that staff within individual departments are queried on a continuing basis to ensure that needs are being met, and problems are minimized. It has been our experience that hospital personnel, particularly nurses, are remarkably adaptable and will develop "workarounds" or acquiescence to system deficiencies because notification systems may be cumbersome and take time away from direct patient care activities. It is therefore important that identified staff members (or personnel with a specific interest in the implementation process) observe practice and become involved in the development of enhancements to the computer system based on observation as well as verbalized need. We had not prepared mechanisms for ongoing development of the point-of-care Critical Care Information System installed in our facility prior to implementation. The following relates the problems we encountered after implementation, and the mechanisms developed for problem resolution. PROBLEMS Soon after system implementation it became apparent that further customization of the application was necessary. Deficiencies in prior knowledge, inability to gain "live" experience on the system, the use of only small groups to draw upon for comment, and an environment with constantly changing technology and practice all contributed to the need for further changes and enhancements to the initial application. Users began to come forth with a large number of "problems", and no process was in place to assess the problems and identify solutions. The situations we encountered were as follows. Problem identification was random. Situations were identified almost daily that were being touted as "problems", but we were not adept at differentiating problems from complaints or non-problems, or determining the severity of the problem. The approach to an isolated problem verbalized by an occasional user of the system should be different from the approach to those problems identified by several individuals who are daily users, or those having great clinical significance. Deficient mechanisms for identifying problems also resulted in deficient mechanisms for
multidisciplinary approach. PREIMPLEMENTATION Prior to customization of the generic product provided by the vendor, it is important that individuals from the departments subject to either direct or indirect impact learn something about the system. In most cases, the users have not previously worked with point-of-care information systems or even computers. If the users are not well informed regarding the function and potential of their new system, there is a compulsion to format the computer system to display and perform in a manner identical to that of the antecedent paper system. Such an approach does not allow the full advantage of the computer system to be realized, and impedes the improvement in workflow and practice which are among the desirable effects of computerization. Initial customization work should be done only to the degree necessary for basic system function within the particular unit or hospital environment. Further customization work is better left until the users gain experience, familiarity and facility with the system. Preliminary customization is usually based only on input from a small number of relatively inexperienced users. Later, the input from a wider variety of then computer savvy users can be employed to tailor both the system and their clinical practice to their needs and developing objectives. However, involvement by a representative number of personnel from all departments affected by the system or its output early in the development phase fosters the evolution of a sound foundation upon which further customization and enhancement can readily occur. It is also important to have training in system utilization conducted by representatives of each involved department. These representatives can better speak to the needs of their own personnel, and give rationale for decisions which have been made affecting their own area. In addition these trainers, who usually have an interest in, and facility with, the system can evolve into an ongoing information resource for the staff members and develop into "superusers". They may
4
appearance of the proposed change within the application, and its likelihood of solving the problem. Once programming was concluded, we had no process for evaluating the function and effectiveness of the enhancement prior to clinical usage. We did not have a process for evaluating if other parts of the dynamic clinical application were being adversely affected by the change. Even when technical function was appropriate, we had no mechanism for systematically soliciting user opinion as to whether or not the enhancement had indeed solved the problem. Lastly, we lacked a mechanism for keeping the clinical staff informed that problems were being addressed, the manner in which they were being addressed, and when to anticipate the changes and resolutions. Lack of an identified process to identify problems and achieve resolution resulted in frustration of the part of both clinicians and system administration staff.
dealing with them. In some cases the problem resulted from inadequate or forgotten training, and required education as the resolution. In other cases, the problem resulted from policy or protocol applicable to the paper system but no longer applicable to the computerized system, and resolution required revision or generation of policies. In yet other cases, correction of the problem would require a change or addition to the configuration, but we had no organized process for gathering information and soliciting appropriate input for the proposed change. Lack of a consistent process for communication between the clinical staff and the system administrator (an individual responsible for ensuring appropriate function of the hardware and software of the system, but without previous clinical expertise) presented an additional problem. Clinicians from many different levels and disciplines were approaching the system administrator (SA) with problems, but the SA had no way to independently ascertain the immediacy or importance of the problem, quality of the proposed solutions, or authority of those making Personnel wandered in at the requests. inconvenient times, breaking the flow of work for the system administrator. Without clinician input, it was difficult for the system administrator to prioritize the changes and enhancements to be made based upon clinical need. It was also difficult for clinician and system administrator alike to determine which changes and enhancements were being developed or programmed, and the status of each job within the development process. We have found it difficult to take an idea generated by a clinician and translate it to a functional equivalent within the information system. Requirements must be specified in a manner and language understandable to programmers who are without clinical experience. For example, if a new parameter were to be added to the system, the programmer would require information concerning title and abbreviation, units of measurement, placement and content of menus and popups, format of the data cell with number of alphanumerics and decimal places, range warning for checks and errors, and preprint, carry forward and scrolling capabilities. We did not have a process in place for clinicians to document their requests in the above format. An additional problem proved to be lack of a systematic evaluation and review of requested changes. Prior to programming, we had no mechanism for gaining a consensus regarding the
THE SOLUTION As a first step, a working group composed of clinicians was developed. Although comprised of nursing staff at this point, the group addresses the clinical needs of all categories of the health care team. Three members of nursing administration, three senior staff nurses and three junior staff nurses are the constituents of the group. Based upon their own observations of system usage in the clinical arena, they identify problems and deficiencies. In addition to reacting to ideas for improvement generated internally, group members also serve as conduits for recommendations and impressions from other clinicians and nonclinicians. The organization and function of the working group is recognized by other personnel and departments, and the flow of questions, concerns, problems, recommendations, and ideas for enhancement are channeled to group members. Group members then bring this information before the entire group. To date, projects acted upon by this group have been stimulated by requests or ideas put forth by physicians, laboratory personnel, the Pain Management Team, and Quality Improvement, as well as nursing staff. Group meetings are held weekly. At each meeting, the group evaluates problems or ideas that have appeared in the previous week. The group evaluates the magnitude of the problem, and possible solutions. In some cases, the solution is communication or reeducation. A communication
5
bulletin board resides within the clinical unit, and notices, memos and meeting minutes from the workgroup are posted. In some cases reeducation requires direct communication, and an established "communication tree" is activated. Each group member is responsible for communicating or training approximately ten staff members on an informal basis. In cases of major changes or software releases, formal training sessions are scheduled outside of the unit environment. If it is felt that the problem requires a change or enhancement to the current application, the work pathway depicted in Table 1 is activated. A sponsor for the project is designated, and the project is assigned a number for tracking purposes. Outside of the meeting time, the sponsor develops an idea for the change or enhancement on paper, and solicits the input of clinicians from involved disciplines. Projects may focus upon nursing issues and documentation, but at times do not. In one example, group members worked with the unit based physician team for development of a Physician's Summary Sheet intended for use during routine morning rounds. In another example, the group worked with nephrologists who desired a summary sheet focusing on information they required for writing hemodialysis orders. Recommendations made by laboratory personnel have resulted in changes or enhancements to the laboratory report sheets. Currently, work is being conducted to implement documentation by the To assure that Respiratory Care group. documentation requirements are being met, group members refer to procedure and policy manuals, standards of care, and quality improvement indicators. Information and insight may be solicited from the Medical Records or Utilization Review Department. The opinions of the Risk Management Department, as well as the hospital's legal counsel have been sought. The sponsor may gather this information independently, or develop ad hoc meetings of personnel from appropriate disciplines for clarification and collection of information. Once sufficient information and opinion has been gathered and incorporated, the sponsor refines the idea and presents this more finalized version during a workgroup meeting. The group may give approval, or recommend further changes. Once finalized, the sponsor then transfers the idea from the working draft into terminology and format suitable for translation by the system administrator into programming. The project is forwarded to the system administrator, and placed
1.
Table 1: Work Pathway Problem or idea identified, brought forward at workgroup meeting.
2.
Project is assigned a sponsor.
3.
Sponsor formulates proposed change or enhancement, solicits input from multidisciplinary team.
4.
Sponsor presents solution to workgroup for approval, workgroup prioritizes in the queue.
5.
Sponsor completes documentation necessary for system administrator; project is assigned a number.
6.
Projects comes forward in the queue, sponsor meets with system administrator for project and documentation review.
7.
Project programmed and placed within the "test" group. System administrator checks technical function within the test group.
8.
Sponsor assesses project within the "test" group.
9.
Sponsor presents project to workgroup for approval. A date for clinical installation determined based on time necessary for appropriate education.
10.
Staff education for the project application is conducted.
11.
Project installed in the clinical group, technical function within the dynamic clinical group is assessed.
12.
Opinions from multidisciplinary team solicited to determine if the project meets the need or solves the problem.
13.
Appropriate paperwork concluded, project is closed.
in a prioritized queue. When the project comes forward in the queue to be worked upon, the sponsor meets with the system administrator to review the project and accompanying paperwork. Programming then ensues. After completion of
6
pain relief and subsequent titration of therapy. A nurse assumed sponsorship of the project. She gained input from physicians, staff nurses, the Pain Management Protocol, unit documentation standards and JCAHO standards. The Analgesia Assessment parameter added as an optional item on the Vital Signs Flowsheet is illustrated in Figure 1.
programming, the system administrator conducts a technical check on the application within the "test group", and the sponsor conducts a content check. The project within the "test group" is then presented by the sponsor to the work group at the weekly meeting. A consensus is required to move the work into the "clinical group". Prior to installation in the clinical setting, the workgroup determines the communication mechanism necessary to educate the staff on the new application, and the date of installation. Minor changes may be communicated through a notice on the bulletin board, more involved changes may require a memo for clarification, and the most complicated changes may require personal communication through activation of the communication tree. The enhancements or changes are installed into the clinical application during a weekly prescheduled downtime, enabling the staff to become accustomed to a standard date on which changes may be anticipated. Once installed, functionality of the change is reassessed within the dynamic clinical group by the project sponsor or designee. A last, but very important step, is solicitation of input from the users to determine if the change meets the clinical need, and corrects the problem for which it was intended. Two mechanisms are used to communicate the above progress of events to the multidisciplinary team that governs the CCIS project. A calendar is kept in the system administration work area on which dates are posted for reboots and software installations, as well as meeting times for the various workgroups. Other dates, such as arrival and installation of new software, additional personnel, vacation or conference dates, and milestones are listed. On a second board, each project is tracked. This board is divided according to the steps in the process (see Table 1.) and as each step is completed, the project is moved along on the board. In this manner, all personnel are aware of the status of each project, from genesis of the idea through final testing and outcome.
ANALGESIA
'Eoid Bol I
Mode
Pain Scale ASSESSMENT Sedation Scale l~~~~~~~0
1. 2. 3. 4. 5.
6.
7.
8. 9.
£0.
IV Therapy
Epidural Bolus Epidural Continuous PCA PCA Continuous PO Therapy IM Therapy
SQ Therapy Intrathecal Nerve Block
0. 1. 2. 3. 4.
L5.
10 IC
11
-
none
>
10 9 0. 0 - No Pain 1. 2. 3. 4. Moderate Pain 5. 6. 7. 8. 9. 10. 10I Worst Imaginable Pain
I 0 - none (alert) I - mild (occ drowsy; easy to rouse) 2 - mod (freq drowsy; easy to arouse) 3 - severe (somnolent; difficult to arouse) S - sleep (normal sleep; easy to arouse) U - unable to assess (ie:
p2arelyzed/.anes)
Figure 1. Example of a project implemented via the work pathway. An Analgesia Assessment parameter with corresponding pop-ups.
CONCLUSION Because a point-of-care clinical information system resides in a dynamic environment, it is necessary for the system and applications within the system to remain dynamic as well. A collaborative multidisciplinary approach is necessary to ensure that system changes and enhancements meet the expectations of all involved health care team members and departments, and that the needs of the patient as well as the needs of the organization are met.
ACKNOWLEDGEMENTS The authors acknowledge the effort and ongoing work done by the Clinical Workgroup, as well as the continuing faith and support of the staff of the Cardiothoracic Intensive Care Unit, University of Pittsburgh Medical Center. Special thanks to: Jane Guttendorf R.N., Clinical Nurse Manager; Darcy Waechter R.N. and Rick Call R.N., Clinical Coordinators; Shari Ferranti R.N., Elaine Fraga R.N., Margaret Lucas R.N., Kim Porco R.N., Karen Rosco R.N., Donna Saffer R.N., Janet Toth R.N.
Exmple of the Solution. Physicians on the Pain Management Service direct intermittent epidural narcotic administration via protocols. Nursing utilization and documentation of pain and sedation scales was inconsistent. Scaling required reference to a legend that was frequently not accessible at the bedside. Physicians communicated their desire for better documentation to facilitate trending of
7
