1. AEMS is a browser based application. Events can be created and managed through Internet Explorer (v5.5 or higher), assuming the user has been assigned the appropriate permissions.
2. The Configuration Utility (used by 1 or 2 key staff) is a Windows application accessed through the network.
3. All content collected throughout the incident management process is stored in a central SQL Server database.
4. Each record changed in AEMS causes a snapshot of the previous value to be saved. Privileged managers can access the “revisions” listing to view the history. The snapshot includes when and who made the change.
5. The availability of the AEMS application is determined by the uptime of the IIS Web service in your organization. A well configured Intranet environment should be available for use at all times –less the time required re-boot the operating system following the application of Microsoft patch updates.
6. As part of the installation, CCD will configure SQL Server to create a Database backup each night. Industry standard backup procedures can then be used to transfer the files to secure devices such as tape or CD. The ASP Web pages and configuration utility should only need to be backed up prior to applying patches and upgrades. The latest version of these files can always be retrieved from CCD. All backups can be performed without system downtime
7. The interface options built into AEMS allows real-time connection to 3rd-party data sources. Optional modules (included in the proposed costs) allow for the connection to external Employee, Patient and Formulary databases.
8. AEMS supports the placement of a custom browser link that can be used to access a common Intranet site. CCD clients use this link for accessing additional training, corporate directories and policies.
Initial Data Capture Information
1. Anonymous reporting is enabled for each licensed facility. If Anonymous reporting is permitted, the main start screen provides Users with the opportunity to report an incident without logging on. Alternately, they may elect to logon in order to enter the Event details.
2. Only logged-on Users can choose to Save and Finish the reporting process at a later time.
3. Supervisors and Managers that wish to view or follow up on an incident must logon in order to validate their permissions.
4. AEMS issues a unique, sequential number for every incident created. The system can also be configured to prompt the user for a separate reference number if required.
5. The unique Report ID number is displayed to the Report Creator as a reference for future follow-up.
6. The Date Created is automatically recorded when the incident is entered. All other dates/times are optionally enabled by the Administrator. If enabled they appear as selection fields on Page 1 during the entry process. The following dates can be collected:
• Date/time of occurrence
• Date/time Event was discovered
• Date/time Event was reported, and
• Date entered into AEMS (auto-entered when created)
7. AEMS supports answer collection using a host of field types including:
• Date & Time fields (via calendar)
• Drop-down pick lists
• Check-one pick lists
• Check-many pick lists
• Boolean check boxes
• Text entry boxes (any size)
8. Text entry fields can be set to accept a set number of characters. Fields that collect more than 40 characters automatically display a count of characters remaining.
9. Each question displayed on the form can be configured to accept the most appropriate field type and can be changed at any time without loosing past responses.
11. The Participant collection area on the form allows for the input of an unlimited number of participants. (patients, employees, others)
12. Administrators can choose which participant types to collect and whether the User has access to the Patient and Employee databases when entering the participant.
13. AEMS includes customizable rollover hints and help pages that can be displayed for each question field appearing on the forms. Administrators can modify the standard help pages in order to apply local terminology or additional information.
14. AEMS supports an unlimited number of Event type Groups (per category) to help Users “drill-down” into the proper type of Event. Users select the Primary Category for the incident which then displays only those incident types that are relevant. These incident types may also be contained in additional groups to narrow the choices.
15. AEMS can be configured to prompt the user as to whether the incident was a “Near-miss” or actually occurred. The workflow process can then be altered based on this choice.
16. All questions displayed on page 2 of the reporting process are relevant to the:
Facility where it occurred,
Type of incident,
Actual or Near-miss status, and
Actual / Potential severity
Confidential status of incident
17. AEMS uses a smart “Time-entry” field that allows the user to enter the minimal number of digits needed to identify the time. Both 12 & 24 hour modes can be configured. The Info Centre Web page (used by managers to view a summary of activity) allows selection of date ranges in 3 ways.
18. Some fields are auto-populated when the user select information from another source, such as choosing a medication or finding a patient.
19. An incident can be flagged as Confidential by any User. Also specific incident types can be pre-set to be confidential.
20. Logged-on Users can choose to finish the Event later by setting the checkbox on the Finish page. Incomplete incidents are accessed through the menu under “My Events > Not Completed”. This functionality is determined by the User’s permissions and is not available to anonymous Users.
21. Mandatory fields can be set through out AEMS. (including all custom fields). Mandatory Fields not answered cause a message to appear and are then coloured green to help the User locate them. Mandatory fields must be answered.
22. To flag a field as optional, administrators may elect to set the background field colour or include labels.
23. All common file types can be attached (uploaded) to incidents or downloaded for viewing. Attachments are assignable based on the criteria specified in item 2.7. (i.e. depending of the incident type, severity, etc.)
24. Permissions required to run various components of AEMS are assignable to 1 or more Roles. These roles are flexible enough to handle all levels of systems access. Permission can be assigned to the entire module or down to a single action, within a single task, of the module –including creating new incidents. Users are then assigned 1 or more of these pre-defined roles.
25. Record level access (or the ability to view/edit/administer individual Events) is separately assigned to each user through the User Rights function. Events can be assigned to users based on the category (or type), facility, department, severity or confidentiality status of the Event. All fields necessary for the user to review the current phase are displayed, assuming permission has been given.
26. AEMS allows users to find Events based on a long list of search criteria. The Find function allows Keyword searches on all fields –including “Any”, “All” and “Exact Phrase” options.A recent addition to AEMS allows Searching through Events for answers that match specific values.
Supplemental Data Capture
1. The manager responsible for the incident while in its current phase has the opportunity to notify others. This functionality may also be enabled during the Initial Entry phase.
• Notification Only
• Information Only
• Comments Only
• Second Opinion
• Manager Review
• Responsibility of Event
3. One of 4 Audit level may be set in the application profile. The Audit tables are protected against edits. Audit entries contain the Username, UserID, Date/Time stamp, Menu Action and Record changed.
2. AEMS was designed to automatically determine who should be notified based on the Event type, severity, etc.
4. The notification cycle is user-definable allowing exceedances messages to be sent out daily.
Review/follow up, supplementary data capture and closure – Management
1. Permissions assigned to Users determine the level of access they have when working with Events.
2. Assuming the proper permissions (through Roles and Rights) have been given to each manager, they will be able to view, edit, involve others, assign risk type/causes, close the Event and perform approximately 50 additional tasks.
3. The workflow process can be set up to include any number of phases such as Pharmacy Review, OHS Review, Fatality Review, etc. When an Event enters each phase, different notifications are sent out and different staff becomes involved. Each Phase can also be setup to contain secondary, user-definable data screens for collecting such information as contribution factors, corrective actions, etc.
4. Each User (created from a staff position) is assigned permissions to View, Edit or Admin Events within one or more departments. This information is set once during the initial configuration when setting up Users.
5. Supervisors have access to Events based on the permissions that they have been given.
6. All content entered prior to the current phase is always available for viewing in order for the responsible manager to get a full understanding of the Event.
7. Keyword searching is available from the main menu. The Find function also allows Keyword searches on all fields –including “Any”, “All” and “Exact Phrase” options. Users can choose which fields should be searched including answers provided to custom questions.
Follow-up Review/Event Management
1. The Info Centre page provides users with a real-time, graphical view of Events within their department.
2. Tasks available from the main menu allow managers to quickly list:
• all open Events in their department,
• all Events that they received a notification and
• all Events that they participated in.
3. The Phase Progression List displayed as part of the Event’s information, indicates whether the Event has been closed. The date and User responsible for moving the Event into the next phase is also displayed.
Queries and Reporting
1. All information is stored in a centralized SQL Server database. Report developers, with the appropriate database permissions, can use 3rd-party reporting tools to create custom reports
2. An add-on Report Maintenance module can be purchased to create Projects (pre-formed database views) that are then referenced by report developers.
3. The module also allows custom reports to be added to the AEMS website where they can be run by supervisors/management staff.
4. CCD is always available to create custom reports for our clients. Our rates are very reasonable and where custom reports can be shared with other clients, prices are even lower.
7. An add-on Data Export module can be purchased that facilitates easy exporting of incident details, including the translation of field values. Export formats include fixed width, comma-separated (CSV), MS Excel, MS Word and XML.
8. The Custom Report module provides in-house developers with the ability to create custom database views that bring together desired fields. These virtual tables can then be used for purposes outside of AEMS.