The decision to implement an AIMS, although offering significant possibilities of improvement on many fronts, is not one to make lightly. The initial cost and maintenance of these systems can consume a significant proportion of a department's annual capital budget. In addition, the implementation process provides not only the excitement of technological advancement but also the frustrations of health care process change. The net result is usually a system that, although not perfect, is superior to the paper record it replaced. After the initial implementation phase, the vast majority of users prefer the AIMS to the paper anesthetic record. AIMS implementations require dedicated personnel from both the vendor and institution. Clinician champions of the system need to come forward or be recruited, and protected time needs to be allotted to the implementation. Once the due diligence has been complete, and the system has been selected and purchased, the real work begins.27
Phases of the Implementation Process
This is the planning stage. Clinicians and users envision in detail how the system will be used. Workflow is mapped out, screens are reviewed and designed, and use cases are discussed so that the system can be configured appropriately. Vendor implementation teams and institutional IT staff typically help in this stage by mocking up screens, providing guidance on the limits and best use of the features and preventing deviation from initial project scope. In this stage, clinicians test different hardware combinations and decide on the best choice for their facility.
This is the configuration stage. Vendor or institution application specialists build out each of the screens. History and physical screens, anesthesia intraoperative templates, nursing assessment modules, and every other screen that needs configuration are built or modified to specification. Specialists upload or input all additional and institution-specific data needed to operate the system. These include locations, users, equipment, supplies, charges, medications, allergies, and many others. In this stage, hardware is purchased and installed, including point-of-care workstations if needed, central servers, and backup equipment. This process can be time consuming and tedious but ultimately makes the system usable for a specific institution.
Once the build is complete, it needs to be thoroughly tested. Typically, systems are initially tested by the vendor implementation team and the institution IT staff, and then detailed screen testing and use case testing is performed by selected end users of the system. The testing should cover as many use cases and workflow scenarios as possible to uncover bugs in the system and prevent surprises when the system is live and running in a real clinical or operational environment. Rigorous testing ensures that every data element on every screen is tested in as many combinations as possible. Load testing is done to ensure that when multiple users are performing the same task, the system does not deteriorate. Performance testing ensures that response times are to specifications. Disaster preparedness plans are tested to ensure that backup systems are functioning properly.
After adequate testing, the all end users of the system must be trained on the system. Training should be concise, focusing on broad concepts of navigating and documenting. Well-designed systems do not take an overwhelming amount of training for users to grasp basic concepts and be able to function within the system. Many specific questions can then be answered during the initial go-live.
Go-live is the culmination of all the hard work put in by the implementation team. The hope is that the effort expended during the previous phases makes for a smooth go-live with satisfied end users. The reality is that issues always arise, minor malfunctions are discovered, and some features do not work as planned. A go-live team that is flexible and responsive to end-users is invaluable to making the initial days successful. For inexperienced institutions, vendor implementation teams can provide valuable expertise during these times.
The go-live is just the start of the journey. During the life of the software product, maintenance will be required; changes will be made to both the content and features of the system. Newer releases will come out that provide exciting new functionality but may break existing features that users depended on. As the institution becomes familiar with, then inextricably linked to the product, clinicians will start to forget the time when the product was not around.28