24
Designing a Reportable Event System: A Collaborative Quality Improvement Project October 2005

Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Designing a Reportable Event System: A Collaborative Quality

Improvement Project October 2005

Page 2: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Designing a Reportable Event System: A Collaborative Quality Improvement Project

Taryn Bowe Institute for Health Policy Muskie School of Public Service University of Southern Maine October 2005

Page 3: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

This report was prepared under Cooperative Agreement No. 10A-202007 between Muskie School of Public Service and Maine Department of Health and Human Services.

Sponsored by the Maine Department of Health and Human Services, with the participation of consumer groups, advocates, and other state agencies. The State of Maine does not discriminate on the basis of disability, race, color, creed, gender, age, or national origin in admission to, access to, or operations of its programs, services or activities, or its hiring practices.

This document was developed under Grant No. P-921540/1 from the U.S. Department of Health and Human Services, Centers for Medicare & Medicaid Services. However, the contents herein do not necessarily represent the policy of the U.S. Department of Health and Human Services, and you should not infer endorsement by the federal government.

Page 4: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Table of Contents

Acknowledgements……………………………………………………………………1

Executive Summary………………………………………………………………...…2

Background……………………………………………………………………………..3

Goals and Objectives…………………………………………………………….……3

Project Selection……………………………………………………………………….4

Pre-Design Planning……………………………………………………..……………5

System Design…………………………………………………………………………7

Challenges………………………………………………………………………………9

Lessons Learned……………………………………………………………………..10

Next Steps/Sustainability…………………………………………………………...10

Appendices

A. Current Processes for Critical Event Intake and Triage

B. Planned Processes for Critical Event Intake and Triage

C. BEAS Event Form

Page 5: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Acknowledgements

A number of people have contributed to this project. Members of Maine’s Quality Technical Advisory Group (Quality TAG) met quarterly for three years and helped guide the project in its earliest phases by discussing feedback from agency interviews and defining the criteria for selecting a final collaborative quality improvement project. Representatives from the HCBS Internal Quality Workgroup were instrumental once a final project was selected and provided information on existing state systems and how these resources could be leveraged.

The bulk of the work done on selecting reportable event categories and data fields was completed by BEAS System Workgroup, a group that meets monthly and is made up of BEAS long term care program staff and representatives from BEAS’ three authorized agencies for assessing and coordinating homecare services: Goold Health Services (GHS), Elder Independence of Maine (EIM) and AlphaOne. Members of the System Workgroup spent extensive time defining and debating reportable event categories, brainstorming key system functionalities and eventually pilot testing a draft event form once preliminary data fields were determined. Finally, we would like to give special thanks to Mollie Baldwin and Terry Sandusky who contributed their leadership and expertise throughout this project, and without whom, none of this work would have been possible.

1

Page 6: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Summary In 2001, the Maine Department of Human Services received a three year grant from the U.S. Department of Health and Human Service to improve services for people with disabilities. This grant was part of the Real Choice Systems Change Initiative funded by the Centers for Medicare & Medicaid. The grant funded work in four major areas: Data integration, Quality, Access and Person-centered services.

The specific objectives of this project were to document current quality management and improvement efforts across departments and programs, develop criteria for selecting areas for potential coordination or collaboration, select a collaborative project to improve the quality of care to persons with disabilities and devote the remainder of the grant to designing and implementing this project.

Staff met with stakeholders and state agency representatives to discuss a number of possible quality improvement topics, including a project in the area of serious event management. This later project was eventually adopted with the purpose being to respond to CMS’s increased interest in establishing methods for identifying potential problems and to design a web-based event tracking system that would meet the immediate and long-term needs of the Bureau of Elderly and Adult Services (BEAS) in monitoring at least two of Maine’s four Medicaid waivers.1 Two primary goals in developing this system were to leverage and build upon resources that were already developed by other state agencies and share the final system with all agencies administering HCBS waivers so that multiple agencies could benefit from any new functionality introduced.

At the conclusion of Quality Choices I, the project will have:

• Identified and trained a working group to continue providing consultation and decision-making to this effort;

• Selected and defined seven reportable event categories for the Bureau of Elderly and Adult Services (BEAS);

• Tested and refined a reportable event form and data fields for BEAS; and • Established a collaborative working relationship between BEAS and the

Department of Behavioral and Developmental Services (BDS), along with a commitment to continue work on the development of this system throughout the duration of Quality Choices II.

The next steps in the development of this system include continuing to build off the collaborative relationship between BEAS and BDS, refining data fields and desired system functionalities and getting sign off from leadership on a plan to begin constructing the system. 1 Please note that this report uses the old titles for the Bureau of Elder and Adult Services (BEAS), now the Office of Elder Services (OAS), and the Department of Behavioral and Developmental Services (BDS), now the Office of Adults with Cognitive and Physical Disability Services (OAC-PDS), as these were the titles used throughout the majority of the project.

2

Page 7: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Background In 2001, the Maine Department of Human Services received a three year grant from the U.S. Department of Health and Human Service to improve services for people with disabilities. This grant was part of the Real Choice Systems Change Initiative funded by the Centers for Medicare & Medicaid. Called Quality Choices in Maine, the goals of the grant were to:

• Ensure the quality of Maine’s community-based living options by building community relevant quality management structures that incorporate consumers’ perspectives;

• Facilitate inter-departmental collaboration by developing integrated data capacity; • Focus attention on services and supports identified as weak links in the system;

and • Make services and supports more consumer centered by incorporating greater

choice and control for consumers in the system. The grant funded work in four major areas:

• Data Integration • Quality • Access • Person-Centered Services

This report focuses on the work related to Collaborative Quality Improvement and concentrates specifically on the design of a web-based reportable events system to meet the needs of at least two of Maine’s four Medicaid waivers. The report describes the criteria by which the collaborative project was selected, as well as the various steps undertaken throughout the initial design phase. The report concludes with a discussion of next steps for system development, as well as plans for sustaining the work of the grant.

Goals and Objectives One of the overall goals of the Quality Choices grant was to improve the quality of community-based services and supports for persons with disabilities through improved coordination and collaboration across departments. In Maine, home and community-based services are administered and/or financed by a number of different departments and agencies. At the time the project began, the elderly and adults with disabilities waivers were administered by the Bureau of Elder and Adult Services (BEAS) within the Department of Human Services (DHS), the persons with mental retardation waiver was administered by the Department of Behavioral and Developmental Services (BDS), and the waiver for persons with physical disabilities who wish to direct their care was administered by the Bureau of Rehabilitation Services (BRS) within the Department of Labor (DOL). There were no formal cross-program quality oversight and improvement

3

Page 8: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

efforts, and persons requiring services from more than one agency were more likely to receive fragmented services and encounter gaps in care. As of July 2004, a number of changes were implemented in the administration of the home and community-based services. Most notably, the Department of Human Services and the Department of Behavioral and Developmental Services merged into a single agency called the Department of Health and Human Services (DHHS). In addition, as of August 1, 2004, responsibility for the administration of the HCBS consumer directed waiver for people with disabilities was moved from the Department of Labor to the Bureau of Elder and Adult Services (BEAS) within DHHS.2

The specific objectives of this project were to document current quality management and improvement efforts across departments and programs, develop criteria for selecting areas for potential coordination or collaboration, select a collaborative project to improve the quality of care to persons with disabilities and devote the remainder of the grant to designing and implementing this project.

Staff met with stakeholders and state agency representatives to discuss a number of possible quality improvement topics, including a project in the area of serious event management. This later project was eventually adopted with the purpose being to respond to CMS’s increased interest in establishing methods for identifying potential problems and to design a web-based event tracking system that would meet the immediate and long-term needs of BEAS in monitoring at least two of Maine’s four Medicaid waivers. Two primary goals in developing this system were to leverage and build upon resources that were already developed by other state agencies and share the final system with all agencies administering HCBS waivers so that multiple agencies could benefit from any new functionality introduced.

Project Selection Early on in the grant, project staff conducted a series of interviews with state agency representatives responsible for the quality oversight of home and community based services. The purpose of these interviews was to inventory agencies’ current quality activities and priorities and gain a better understanding of existing opportunities for coordinating quality improvement activities across departments and programs. Agency representatives were asked to speak on existing mechanisms for collaboration, as well as perceived opportunities and challenges to coordinating future quality activities across programs. Responses varied by agency, but suggested that there were additional opportunities for collaboration in the following areas:

• Information sharing of data owned and managed by other departments; • Interdepartmental trainings on topics that commonly cross departments and

populations;

2 Please note that this report uses the old titles for the Bureau of Elder and Adult Services (BEAS), now the Office of Elder Services (OAS), and the Department of Behavioral and Developmental Services (BDS), now the Office of Adults with Cognitive and Physical Disability Services (OAC-PDS), as these were the titles used throughout the majority of the project.

4

Page 9: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

• Collaboration to better serve persons with multiple service needs; • Standardization of some core consumer experience survey questions; and • Programmatic integration, in particular in the areas of collecting and analyzing

event reports, establishing emergency back-up systems for personal care workers in the home and developing a quality group to guide quality oversight and improvement activities across waiver programs.

These recommendations were presented to the Quality Technical Advisory Group (Quality TAG), a group formed to provide advice and guidance on quality-related initiatives funded under the first Quality Choices grant, as well as to the HCBS Internal Quality Workgroup, an interdepartmental workgroup established to provide similar guidance under the second Quality Choices project. In prioritizing Quality Improvement projects, both groups were asked to consider the following questions:

• Does the project address an area that (a) impacts the quality of home and community based services and (b) is in furtherance of the objectives laid out in Maine’s Road Map for Change?

• Is there sufficient commitment and leadership within at least two departments to work on the project?

• Are there ample resources to support the project in a meaningful and sustained way?

The idea of designing and developing a web-based event management system for BEAS home and community-based waivers was first proposed at a HCBS Internal Quality Workgroup meeting and later accepted by the Quality TAG. Both advisory bodies directed the project to make use of existing systems, in particular the event management system used by the Department of Behavioral and Developmental Services (BDS) in monitoring its MR waiver, and to make the final product available to other agencies administering HCBS waivers.

Pre-Design Planning In order to lay the groundwork for designing and implementing a web-based event system, project staff conducted the following information gathering activities:

• Surveyed other states’ systems, policies and reporting forms; • Mapped current processes for critical event intake and triage; and • Identified key players and potential BEAS event system users.

This work began in April of 2004 and continued throughout that Spring.

Survey Other States Event Systems, Polices and Reporting Forms A number of program specific event systems were already in use by other states at the time this project was initiated. Several web-based systems, including Indiana’s and New Mexico’s, were viewed on-line, and System Manuals and Functional Requirements were collected from Indiana, Oregon and Minnesota. Systems were examined in terms of the

5

Page 10: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

functionalities they offered and whether or not these features were appealing and/or necessary for BEAS. Reportable event policies and forms were also compiled. A summary table of reportable event categories from California, New Mexico, Oregon, Pennsylvania, South Carolina and Wisconsin served as the starting point for selecting and prioritizing BEAS events.3 Although few states had developed event reporting policies for the elderly, a number of policies developed for MR/DD populations were available and were able to serve as the foundation for further discussion. Map Current Processes for Critical Event Intake and Triage Another step in the pre-design phase of the project was to diagram the current flow of event information within and outside of BEAS. This was done to get a clearer picture of all the processes and parties potentially involved in the intake, response and investigation of a BEAS event. While BEAS staff and contractors did not have a history of formally collecting reportable event data, they were familiar with responding to cases of this type and expressed that their actions were already guided by a number of assumptions and routine practices. A series of questions helped to guide this discussion:

• Who receives the event report? • What is done with this information? • What action-steps are taken as a result of this information? • Where is the information triaged to? (e.g. adult protective, law enforcement,

Medicaid fraud)? • Who is responsible for the investigation of allegations (e.g. state staff, private

contractors, providers? • When is a case closed? • When might one remain open?

Answers to the above questions were documented. The resulting diagram is included in Appendix A.

Identify Key Players and System Users Finally, project staff met with the BEAS’ program manager to discuss who should inform event system design. It was assumed that the HCBS Internal Quality Workgroup would continue to serve in an advisory role to the project; however, an additional body was needed to do the bulk of the work, including drafting event categories and definitions and determining key system features and processes for reporting. The BEAS’ Systems Workgroup seemed like a natural fit. The System Workgroup meets monthly and is made up of BEAS long term care program staff, as well as representatives from BEAS’ three authorized agencies for assessing and coordinating homecare services: Goold

3 Produced by the Community Living Exchange under a contract with the Centers for Medicare and Medicaid Services (CMS) and available on the QA/QI Systems Change Grant Website.

6

Page 11: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Health Services (GHS), Elder Independence of Maine (EIM) and AlphaOne. The workgroup includes many of the event system’s anticipated users and a number of people who typically field and respond to high-level calls.

System Design Having gathered information on existing event systems and convened the major players and decisions makers, the next tasks were to:

• Select event categories; • Prepare a ‘wish list’ of system features and functionalities; • Select the system model that best fit project goals and specifications; • Create a mock-up of event system data entry screens with data fields and

definitions; and lastly, • Pilot test the event categories and event system data fields.

Select Event Categories In June 2004, members of the BEAS’ Systems Workgroup were presented with a list of event categories collected by BDS, the Division of Licensure and Certification and other Departments outside the state. Event categories ranged from death and medication errors to property damage and emergency services involvement. The workgroup was asked to review and prioritize all possible event categories, paying particular attention to the categories that were regarded as preventable and involved direct harm or risk of harm to elderly and disabled individuals receiving home-based care. After the Systems Workgroup reviewed and prioritized all of the possible event categories, the list was reduced significantly to include the following seven categories:

• Death; • Abuse/Neglect/Exploitation; • Serious Injury to Consumer; • Serious Injury to Worker; • Damage to Consumer’s Property/Theft; • Medication Management; and • Emergency Services Involvement.

These categories were defined with concrete examples and reporting timeframes and were tested during a two month period in which members of the Systems Workgroup kept tally of the number of calls they received on each of these topics and identified categories where further definition was needed.

7

Page 12: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Prepare a ‘Wish List’ of System Features and Functionalities

At the same time the event categories were being selected and defined, the Systems Workgroup was brainstorming a ‘wish list’ of system features and functionalities that were desired in the new event system. Items on this list ranged from controlled security with various levels of access to automatic e-mail triggers to communicate relevant event information to contractors, providers and Adult Protective Services. A number of simpler features were also discussed. For example, the Workgroup agreed that a web-based system with common event reporting categories and standardized documentation of referrals, remediation and resolution would be a significant improvement over the various informal recording methods currently used by BEAS and its contractors.

Other critical design questions discussed at this time, included:

• What agencies will report into the system? • What existing systems can the new system replace? • What existing systems should the new system link to? • What systems could it build upon? • What has been EIM’s experience with their complaint database?

- Who reports and enters data into EIM’s current complaint database? - What important functions of this system must be maintained by a new

system? • What types of event reports will contractors want to access?

Answers to the above questions were documented and diagrammed to create a clearer picture of the system envisioned. This visual is included in Appendix B.

Select the System Model that Best Fits Project Goals and Specifications Once the event categories were selected and the desired functionalities were understood, the project team was in a better position to determine which, if any, of the existing systems best fit the project goals and specifications. Additional discussions with the Department of Behavioral and Developmental Services (BDS) and demonstrations of their Enterprise Information System (EIS) Reportable Event System confirmed the original notion that EIS could be leveraged to create a similar reportable event system for BEAS. A project lead within BDS was identified and, soon after the official decision to pursue this route, this person began meeting regularly with BEAS and project staff to provide design expertise and answer questions as needed.

Create a mock-up of event system screens with data fields and definitions. A parallel design effort, initiated once the preliminary event categories were selected, was to identify additional data fields needed in the system. The Systems Workgroup considered the following questions:

8

Page 13: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

• What additional client, provider and reporter information is needed to generate

reports of interest? (e.g. client demographics, provider name, event reporter role, etc.)

• What additional event information should be tracked? (e.g. event time/date, specific information pertaining to the event type, etc.)

• What follow-up actions should be tracked? • What client information is necessary to link the system with other important

databases? The data fields already used as part of the EIS Reportable Event System provided a basis for discussion, and fields were added or eliminated as needed. A draft of all the BEAS event data fields was completed in March 2005, and these fields were pilot tested during the Spring of 2005.

Pilot Test the Event Categories and Event Systems Data Fields Representatives from BEAS, GHS, EIM and AlphaOne pilot tested the draft BEAS Event Form from April 7 to May 19, 2005. During that period, individuals were instructed to complete a form for every event. The purpose of this pilot was to orient folks to the form, as well as to test the data fields and overall completion process so that (1) needed changes could be identified prior to system development and (2) feedback could be used to help develop business rules and form instructions. Individuals participating in the pilot represented most levels of system users and participated in a debriefing session after the pilot in which feedback was solicited and recorded. Several changes to the BEAS Event Form and data fields were made in response to pilot feedback. The pilot form was seen as too time-consuming and burdensome, and several data fields requiring narratives were eliminated or shortened. Also, descriptions of action steps were replaced by action step codes, and the category of Emergency Services Involvement was eliminated. Finally, a category was added for ‘Other Event Types.’ The BEAS Event Form that emerged was a shortened version of the previous draft that focused on tracking and quantifying reportable events and follow-up activities conducted by BEAS staff and contractors. A copy of this form is presented in Appendix C.

Challenges The task of designing a reportable event system for BEAS presented several challenges.

• At the time of design, there were few models of reportable events systems designed specifically for aged and disabled populations. Project staff reviewed policies and data systems designed for MR/DD waivers programs and discussed ways in which these systems could be modified to address the unique risks and circumstances of elderly and disabled individuals receiving home-based services.

9

Page 14: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

• BEAS staff and contractors were aware of the need for an event monitoring system; however, they were concerned about adding new documentation requirements to their already heavy workload. The requirement to enter data into another information system was also a concern given the existing assessment system and case management systems already in place. Finding a balance between including essential data elements and minimizing the burden of event reporting was a particular challenge throughout the project.

• Although collaborating with BDS on system design was ultimately a very positive

and constructive experience, it presented some challenges as well. The sharing of event data for common BEAS/BDS clients is an issue that has yet to be resolved. Likewise, security issues pertaining to various levels of access (BEAS staff vs. contractors) will also need to be grappled with more extensively in the future.

• The actual development of the system was slowed somewhat by competing

priorities within the state. In particular, the roll-out of Maine’s new Claims Management System (MECMS) beginning in January 2005 required the full attention of IT staff who would have otherwise contributed time to this project.

Lessons Learned Lessons learned throughout the project include the following:

• Utilizing an existing workgroup for project design and decision-making helps to ensure that the project is able to move forward at a steady pace and not get hung up in scheduling conflicts.

• In order to help insure compliance, it is important to keep the event form as

efficient and user-friendly as possible, while continuing to capture the most critical information.

• Leveraging an existing reportable event system enables one department to benefit

from another’s expertise and experience. The BDS lead who worked with the project contributed three-years of experience designing and developing a reportable event system and educated the project on many of the lessons already learned during this previous effort.

• A positive upshot of the project is that BDS is currently looking to adopt several

of the event categories and data fields proposed by BEAS so that the two systems can be more comparable.

Next Steps/Sustainability At the conclusion of Quality Choices I, the project will have:

10

Page 15: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

• Identified and trained a working group to continue providing consultation and decision-making to this effort;

• Selected and defined seven reportable event categories for BEAS; • Tested and refined a reportable event form and data fields for BEAS; and • Established a collaborative working relationship between BEAS and the

Department of Behavioral and Developmental Services (BDS), along with a commitment to continue work on the development of this system throughout the duration of Quality Choices II.

The obvious next steps in the development of this system are to continue working with BDS to refine data fields and desired system functionalities and get sign off from leadership on a plan to begin constructing the system. In the second phase of the project, project staff will collaborate with BDS and BEAS to develop a common event system front page, as well as common event categories, data fields, reporting templates and training materials. Links with BEAS’ existing assessment system will also be explored. BDS has resources and staff to help continue this effort, and project staff from the second Quality Choices grant will continue to provide staff support as needed and will assist in the development of common reporting forms and instruction manuals. In addition to these resources, several other structures are in place to ensure the continuation of this work. The Systems Workgroup will continue to meet on a monthly basis and will be available to provide consultation as the system is developed. The HCBS Internal Quality Workgroup, created as part of the Quality Choices II grant, will continue to meet to share information, build relationships and provide oversight to this activity and others. Also, the merger of the Department of Human Services and the Department of Behavioral and Developmental Services (BDS) should create additional opportunities to coordinate quality management and may eventually help eliminate some of the data sharing challenges that have existed historically between BEAS and BDS.

11

Page 16: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Appendix A

Page 17: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Diagram 1 -

EVENTS - Serious Injury to Consumer- Serious Injury to PCA- Theft/Damage to Consumer's Property- Medication Errors - Crisis w/Emerg. Involvement- Abuse/Neglect/Exploitation

COMPLAINTS/APPEALS- Consumer Complaints- Provider Complaints - Timesheet Fraud - Agency Complaints w/reimbursement

INFORMATION REQUESTS[Consumer Specific]

BEAS From contractors, provider agnecies, and providers

EIM From provider agnecies and providers

Goold From provider agnecies and providers

AlphaOne From provider agnecies and providers Others

BEAS From consumer, family, doctor, licensing, advocate, provider, in-home visits, APS EIM From consumer, family, doctor, advocate, provider

Goold From consumer, family, doctor, advocate, provider

AlphaOne From consumer, family, doctor, advocate, provider Others

BEAS From consumer, family, doctor, licensing, advocate, provider, in-home visits, BFI, BDS, APS, PCG, Others.

Referral

OtherActions

Auto. Notify Desk Review

Desk Review

Referral

Auto. Notify

OtherActions

NotifyHearing

UnitAppeals Route

Follow-up

Closed

Follow-up w/dates Closed

Hearing Unit Notified

HearingDates/Final

DecisionTracking

APS, Medicaid Fraud,Licensure, SURs

Action Steps w/Datesand Findings

Caseworker,Physician, Family,

Guardian, EIM,Goold, AlphaOne,

BDS

Caseworker,Physician, Family,

Guardian, EIM,Goold, AlphaOne,

BDS

LTC Ombudsmen, PrivacyOfficer, Medicaid Fraud

Action Steps w/Datesand Findings

ReferralResponse/Tracking

ReferralResponse/Tracking

Open

Closed

Closed

Open

Closed

Closed

BEASFull report generationcapacity- 'Aging' Complaints- Event Totals- Events by Provider- Complaints by Category- Etc.

ContractorsLimited reportgeneration capacity

BMS, BDSRead only

BEAS Complaint/Event Tracking Processes

Data Entry Referral/Action Steps Tracking Reports/Output

Page 18: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Appendix B

Page 19: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

EVENTS- Death- Abuse/Neglect/Exploitation- Serious Injury to Consumer- Serious Injury to Worker- Damage to Consumer's- Property/Theft- Medication Management- Emergency Services Involvement

ISSUES- Consumer-Related Issues/Queries- Issues/Queries about Provider Process- Issues and Feedback about BEAS and Contractors

BEAS

EIM

Goold

AlphaOne

Others

Referral

OtherActions

Notify/Auto-Notify

Desk Review

Advocacy , APS,BDS, BEAS, BFI, BMS,

DOL, Homemaker Agency,Hospital Quality Board,Internal Team Leader,

Internal Management, LawEnforcement, ApplicableLicensing, MaineCare

Fraud, Other

Provider Sanctions,Provider Audit, Staff

Terminated, StaffTermination Reported, Staff

Search, Other

Consumer, Providers,Family,

Guardian,Physician,EIM, GHS, Alpha, Other

ReferralResponse/Tracking

Open

Closed

Closed

BEASFull report generationcapacity

ContractorsLimited reportgeneration capacity-Events/issues specific provider-Events/issues provider type- All events/issues by category

BMS, BDSRead only

BEAS Events/Issues Tracking System

Data Entry Referral/Action Steps Tracking Reports/Output

Open

Closed

Closed

Page 20: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Appendix C

Page 21: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

__ __ / __ __ / __ __

__ __ / __ __ / __ __

__ __ / __ __ / __ __

__ __ / __ __ / __ __

__ __ / __ __ / __ __

__ __ / __ __ / __ __

__ __ / __ __ / __ __

FILER TYPE: ■ ■ BEAS■ ■ Alpha

■ ■ EIM■ ■ GHS

FILER NAME ____________________________________________________________________

Phone _____________________________ Email ____________________________________DATE REC’D _ _ / _ _ / _ _ Time: _______ ■ ■ a.m. ■ ■ p.m.

REPORTER Name ____________________________________________________ Phone ____________________ email ______________________________

REPORTER ID: ■ ■ Consumer■ ■ Family Member■ ■ Advocate

■ ■ Worker■ ■ Legislators, Commissioners, etc.■ ■ Governor’s Office

■ ■ BEAS■ ■ Alpha■ ■ GHS

■ ■ BMS ■ ■ BFI■ ■ EIM■ ■ Other (specify) _______________________________

■ ■ Call ■ ■ Letter ■ ■ email ■ ■ In-Home Visit ■ ■ Fax ■ ■ Other (specify) ____________________

LOCATION: ■■ Personal Residence■■ Residential Care■ ■ Adult Day Care■ ■ Hospital

■ ■ In Community (e.g.:grocery store, community ctr., not in home) specify _____________________________

■ ■ Other (specify)__________________________________

FORMAT OF REPORT:

Was Worker(s) involved as an alleged perpetrator or witness? ■ ■ YES ■ ■ NONAME(S)_________________________________________________________________________________________________________________________Worker Type: ■ ■ PCA ■ ■ CNA ■ ■ RN

■ ■ Other (specify) ____________________________________

Role: ■ ■ Alleged Participant in Event ■ ■ Witness■ ■ Other (specify) ____________________________________

PERSONS INVOLVED IN EVENT

Was another person(s) involvedas an alleged perpetrator or witness? ■ ■ YES ■ ■ NONAME(S)_______________________________________________________

______________________________________________________________

Role: ■ ■ Alleged Participant in Event■ ■ Witness■ ■ Other (specify) _________________________

Client First Name Client Last Name MaineCare # SS#

_ _ _ _ / _ _ / _ _ _ _

PERSONAL INFORMATION

1

EVENT FORMBureau of Elder and Adult Services

PRELIMINARY EVENT INFORMATION (Please check or fill in all information below as appropriate.)

1.) ■■ Death

2.) ■■ Abuse/Neglect/Exploitation

3.) ■■ Serious Injury to Consumer

4.) ■■ Serious Injury to Worker

5.) ■■ Damage to Consumer’s Property/Theft

6.) ■■ Medication Management

7.) ■■ Other High Risk Isuses

DATE NARRATIVEEVENT (Please check all that apply)

■ ■ EW/ADW HCB ■ ■ PDW HCB ■ ■ PDN ■ ■ HH■ ■ Independent Contractor ■ ■ PDN■ ■ Agency ■ ■ HH■ ■ FPSO ■ ■ N/A

PROGRAM TYPE:(Please check all that apply)

Page 22: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

3. SERIOUS INJURY TO CONSUMER:

Injury requiring treatment beyond first aid includes: lacerations requiring sutures or staples, fractures, dislocations, loss of limb, seriousburns, skin wounds, and other. Must be reported to system within 24 hours of notification.

CUSTOM FIELDS:

3.a.) Serious Injury Type:

3.b.) Cause of Injury:

3.c.) Hospitalization:

■■ Fall ■■ Accident ■■ Medical Condition ■■ Seizure ■■ Treatment Error

■■ Poor care (e.g., skin wounds) ■■ Undetermined ■■ Other (specify) _______________________

■■ YES: ■ ■ Inpatient ■■ Outpatient ■■ ER

■■ NO

PLEASE FILL IN THE “ACTION STEPS” FOUND ON PAGE 4

■■ Laceration requiring sutures or staples ■■ Fracture ■■ Dislocation ■■ Loss of limb■■ Serious burn ■■ Skin wound due to poor care ■■ Other (specify)____________________________

1. DEATH If the death is accidental or of a suspicious nature or if law enforcement or a coroner is involved, it must be reported to the systemwithin 24 hours upon notification.

CUSTOM FIELDS:

a.) Death Type: ■ ■ Completed Suicide■ ■ Unexplained Death

■ ■ Homicide■ ■ Accidental Death

■ ■ Other (specify) ______________________________________________________________________________________________

PLEASE FILL IN THE “ACTION STEPS” FOUND ON PAGE 4

Client Name (First, Last) EVENT TYPESS# _ _ _ _ / _ _ / _ _ _ _

EVENT CUSTOM FIELDSBureau of Elder and Adult Services

2

(1 of 2)

■ ABUSE includes actions which result in bodily harm, pain or mental distress. Examples of abuse are:• pushing, hitting, shaking, pulling hair;• tying to a bed or chair or locking in a room;• forcing into sexual activity;

■ NEGLECT is a failure to provide care and services when an adult is unable to care for him or herself. Neglect may be at the hands of someone else or it may be self neglect. Neglect includes failure to provide:

• adequate shelter, clothes or food; personal care; medical attention or necessary medication; and• necessities such as glasses, dentures, hearing aides, walkers.

■ EXPLOITATION is the illegal or improper use of an adult’s money or property for another person’s profit or advantage. Examples of exploitation include:

• forcing an adult to change a will or sign over control of assets; forcing an adult to sell or give away property or possessions; and• keeping the adult’s pension or social security check

2. ABUSE/NEGLECT/EXPLOITATION: Mandatory Reporting Category.

Must be reported to system and APS within 24 hours of notification

• giving the wrong medicine or too much medicine on purpose;• denying visit with friends or family; and• name calling, harass mentor verbal threats.

■ ■ Physical Abuse ■ ■ Emotional Abuse ■ ■ Safety Issues/At Risk ■ ■ Inability to Give Informed Consent

CUSTOM FIELDS: :

2.a.) Source of Abuse/ Neglect/Exploitation:

2.b.) Type of Abuse/ Neglect/Exploitation:

■ ■ Self Neglect ■ ■ Caregiver Neglect ■ ■ Exploitation ■ ■ Sexual Abuse

REPORT TO APS and PLEASE FILL IN THE “ACTION STEPS” FOUND ON PAGE 4

■ ■ Self ■ ■ Family Member ■ ■ PCA ■ ■ Other (specify)_____________________________________

2.c.) Hospitalization: ■■ YES: ■ ■ Inpatient ■■ Outpatient ■■ ER

■■ NO

Page 23: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

5. DAMAGE TO CONSUMER’S PROPERTY/THEFT:

Deliberate misplacement or wrongful temporary or permanent use of a consumer’s belongings or money without the consumer’s consent.Also, includes missing medications. Must be reported within 24 hours of notification.

■ ■ Theft ■ ■ Damage ■ ■ Medication5.a.) Type of Loss:

5.b.) Suspected Perpetrator:

■ ■ Worker ■ ■ Family Member ■ ■ Other (specify) ________________________________________

CUSTOM FIELDS:

PLEASE FILL IN THE “ACTION STEPS” FOUND ON PAGE 4

7. OTHER HIGH RISK ISSUES:

PLEASE FILL IN THE “ACTION STEPS” FOUND ON PAGE 4

6. MEDICATION MANAGEMENT:

Problems with: medication dosage, scheduling, timing, compliance, set-up, administration or monitoring. Applies only when medication isadministered by a paid provider. Must be reported to system within 24 hours of notification.

■ ■ Omission ■ ■ Wrong Dose ■ ■ Wrong Medication■ ■ Wrong Method of Adminsitration ■ ■ Wrong Route ■ ■ Wrong Time (>1 hr. variance)■ ■ Medication Refused ■ ■ Non-Compliance ■ ■ Other (specify) ____________________

6.a.) Medication Related Event Type:

6.b.) Reason for Event:

6.c.) Administered/ Set-up by:

6.d.) Name of drug:

6.e.) Hospitalization:

■ ■ Administration Error ■ ■ Supply Exhausted ■ ■ Forgot ■ ■ Refusal■ ■ Prescription Unfilled ■ ■ Incorrect Chart Entry ■ ■ Non-Compliance ■ ■ Other (specify) _______________

■ ■ Consumer ■ ■ Provider ■ ■ Provider set-up only ■ ■ Provider admin. only■ ■ Family Member ■ ■ Worker ■ ■ Other (specify) ____________________________

■ ■ YES: ■ ■ Inpatient ■ ■ Outpatient ■ ■ ER■ ■ NO

CUSTOM FIELDS:

PLEASE FILL IN THE “ACTION STEPS” FOUND ON PAGE 4

EVENT CUSTOM FIELDS Client Name (First, Last) EVENT TYPE

SS# _ _ _ _ / _ _ / _ _ _ _

4. SERIOUS INJURY TO WORKER:

Injury requiring treatment beyond first aid includes: lacerations requiring sutures or staples, fractures, dislocations, loss of limb, seriousburns and other. Must be reported to system within 24 hours of notification.

■ ■ Laceration requiring sutures or staples ■ ■ Fracture ■ ■ Dislocation ■ ■ Loss of limb■ ■ Serious burn ■ ■ Skin wound due to poor care ■ ■ Other (specify) ____________________

4.a.) Serious Injury Type:

4.b.) Cause of Injury:

4.c.) Hospitalization:

■ ■ Fall ■ ■ Accident ■ ■ Direct physical contact with consumer or member of household■ ■ Lifting ■ ■ Needle-sticks ■ ■ Unknown ■ ■ Other (specify) ________________________

■ ■ YES: ■ ■ Inpatient ■ ■ Outpatient ■ ■ ER■ ■ NO

PLEASE FILL IN THE “ACTION STEPS” FOUND ON PAGE 4

CUSTOM FIELDS:

3

(2 of 2)

7.a.) Risk Issue Type(s):

7.b.) Why is this issue of particular risk to this person?

CUSTOM FIELDS:

■ ■ Criminal Justice Involvement ■ ■ Consumer Fraud ■ ■ Provider Fraud in a Self-Directed Mode■ ■ Lost/Missing Person ■ ■ Loss of Home ■ ■ Sucide Ideation or Attempt■ ■ Substance Abuse ■ ■ Other (specify) ___________________________________________

Serious issues that do not yet rise to the level of an event, but have the potential to do so in the future.

_______________________________________________________________________________________________________________________________________

Page 24: Designing a Reportable Event System: A Collaborative Quality …muskie.usm.maine.edu/Publications/ihp/Designing... · 2005-10-28 · monitoring at least two of Maine’s four Medicaid

Client Name (First, Last) EVENT TYPESS# _ _ _ _ / _ _ / _ _ _ _

■ ■ No Action■ ■ Change in Policy■ ■ Educational Training■ ■ Disciplinary Action

Do you think this incident requires:

EVENT SYSTEM FOLLOW UP:

■ ■ Process Improvement■ ■ Refer to BEAS/Maine Elder Death Analysis Review Team (MEDART)■ ■ Root Cause Analysis/Case Review■ ■ Don’t Know Yet

MR = MANDATORY REFERRAL TO APSA1 = Additional Follow-up with ConsumerA2 = Additional Follow-up with Provider(s)A3 = Additional Follow-up with Contractor(s)C1 = Consumer Representative Contacted (Family Member/Guardian)D1 = Doctor ContactedP1 = Provider AuditP2 = Provider SanctionsR1 = Referred to AAG

R2 = Referred to Advocacy or Legal ServicesR2a = Legal Services for the Elderly (LSE)R2b = Long Term Care

Ombudsmen Program (LTCOP)R2c = Other Advocate

R3 = Referred to Applicable LicensingR4 = Referred to APSR5 = Referred to BEASR6 = Referred to BDS

R6a = Mental HealthR6b = Mental Retardation

R7 = Referred to BFI

R8 = Referred to BMSR9 = Referred to Crisis InterventionR10 = Referred to DOLR11 = Referred to Emergency Services

R11a = Ambulance/Rescue/ParamedicsR11b = Animal ControlR11c = Fire DepartmentR11d = PoliceR11e = Warden’s ServiceR11f = Other Emergency

Service InvolvedR12 = Referred to Homemaker AgencyR13 = Referred to Hospital Quality Board

R14 = Referred to InternalTeam Leader

R15 = Referred toInternal Management

R16 = Referred to MaineCare FraudR17 = Referred to MDTS1 = Staff TerminatedS2 = Staff Termination Reported to

Appropriate Board or RegistryS3 = Staffing SearchO = Other (Specify)

CODES FOR ACTION STEPS:

Bureau of Elder and Adult ServicesEVENTS NARRATIVE/ACTION STEPS: Data Fields

4 (7/05)

ACTION STEPS EVENTS ACTIVITY NARRATIVE Please Use Codes from Person(s) Contacted Listing Name/Phone above

NarrativeDate Initials