The Integrated Community Mental Health Information System (ICMHIS)

Health and the Information Highway Division, Health Canada
September, 2003

Table of Contents

• Project: ICMHIS
• Achievements
  • Goals Reached
  • Additional Successes
  • Unreached Goals
  • Documents or Products Generated
• Main Impact
  • Immediate impacts on service
  • Human Resources Impact
  • Privacy and Protection of Information
  • Policy & Research Implications
• The Future
  • Needs Based Service Delivery Initiative
  • Downtown Health Coalition
  • Partnership with the University of Victoria
  • Clinical Context Descriptors Schema
• Communications

List of Appendices:

• Appendix I - Clinically Complex Use Case/ Training Scenario
• Appendix II - ICMHIS Clinical Data Elements
  • Appendix IIa - Triage-Oriented Assessment of Acuity and Risk: Item Listing
  • Appendix IIb - Triage-Oriented Assessment of Acutiy and Risk: Sample Item
  • Appendix IIc - Ad Hoc Observations
  • Appendix IId - BC Ministry of Health Minimum Reporting Requirements

Project: ICMHIS (Revised Description)

The Integrated Community Mental Health Information System (ICMHIS) is a web-enabled health care information system that will allow the collection and sharing of clinical and non-clinical information across a continuum encompassing hospital and community-based services.

Goals

• To develop a standards-based information tracking system that is efficiently and effectively customizable to support the service delivery processes in a variety of community-based healthcare and human services organizations
• To develop an information system for outcome monitoring and communication between primary/ acute care organizations, government and community
• To travel as 'far' into the community as the most disenfranchised (and often most complexly impaired) members of the target population for mental health and addictions services; to provide integrated information systems coverage into those sectors of community-based service delivery typically untouched by enterprise health information systems

Deliverables

• Web-enabled application accessible and useable for small, medium and large scale organizations
• Data repository
• Structured and ad hoc documentation methodologies
• Vocabularies to assess and describe the target population for mental health/ addictions services (clinical conditions; acuity/ risk characteristics; social environments and the capacity of service providers to mitigate risk and enhance functioning)
• Clinical Context Descriptors Schema (CCDS), a methodology to organize and contextualize clinically-relevant information within an EHR. The CCDS will identify linkages between encounters for purposes of outcome measurement, specify the parameters for contextually-relevant minimum data sets, provide a framework for decision support, and supply a structure to support consent-based limited sharing of information
• A set of organizational templates for information collected across the full continuum of mental health and addictions services
• Shelter, clinic and counselling services business functions

Functionality

• Web-integrated Client Management Database System
• Ability to add new organizations quickly
• Ability to rapidly modify or enhance functionality to meet the needs of different organizations
• Secure access on a need-to-know basis

Application Scenario

Vanessa is a 25 year old woman, recently arrived in a small city where there is a high concentration of individuals with mental health/addictions problems residing in the downtown core. She has an established diagnosis of schizophrenia and is HIV positive. Her condition is complicated by intravenous use of several drugs and associated involvement in the sex trade to pay for drugs. When she is evicted from her apartment she registers at the Women's Shelter using what is clearly a pseudonym. Shelter staff enter a physical description on her ICMHIS client card. This later enables the Public Health [street] nurse to locate her and resume her daily HIV medications. For reasons of public health and safety, the public health nurse shares critical information with shelter staff about Vanessa's psychiatric diagnosis and her medical condition. The public health nurse also informs staff that Vanessa is very careless with her used syringes, and reports that on several occasions has become quite assaultive when she is off her antipsychotic medications. Information about her medical and psychiatric condition is entered into the ICMHIS system, and a medical alert is posted.

Vanessa becomes increasingly agitated and paranoid, to the point that the Mobile Crisis Response Team must be called. Staff employ ICMHIS to complete the structured portion of the Minimum Data Set: Mental Health Triage (MDS: MHT) tool, which summarizes their evaluation of Vanessa's acuity/risk characteristics, as well as the level of supervision and control necessary to mitigate the risks. This assessment, along with other health, behaviour and physical observations contained in the system, is incorporated into the ICMHIS Client Clinical Case History, which is sent by the ICMHIS system to the Mobile Crisis Response Team as an email attachment.

The Mobile Crisis Response Team, with police backup, meet at the shelter to interview Vanessa. Based on what they see of her behaviour, the police are initially unwilling to transport Vanessa on an involuntary basis to the local Emergency Department. However, based on the information registered into the ICMHIS system, including the MDS: MHT structured assessment of acuity/risk, the Mobile Crisis Response Team is able to advocate successfully for transport to hospital on an involuntary basis. In the Hospital Emergency Department, Vanessa composes herself, and her overt behaviour does not suggest an imminent risk to self or others. However, when provided with the picture painted by a copy of the ICMHIS Client Clinical Case History from the Shelter, the Emergency Physician admits her for further assessment and treatment.

While she is in hospital, the Public Health nurse is informed that a person with whom Vanessa was living before her recent eviction has active tuberculosis. The Public Health nurse contacts the Shelter, where the ICMHIS system is used to identify other individuals who shared a room with her during her stay in the Shelter. The Public Health is also able to locate Vanessa in hospital based on data registered in the ICMHIS system at the time that the Mobile Crisis Response Team was called in.

Vanessa tests negative for tuberculosis. She remains in hospital for 13 days and is discharged with a case manager.

Magnitude

Initial deployment at five sites in the Victoria area

Partners

• Vancouver Island Health Authority (VIHA)
• Victoria Cool Aid Society
• LogicLynx Technologies Inc.

Contact

Dr. Ken Moselle, Manager, Standards and Monitoring,
Mental Health & Addictions, VIHA, (250) 812-3925,
Kenneth.Moselle@caphealth.org

Don McTavish, Manager Shelters
Victoria Cool Aid Society (250) 383-1951,
dmctavish@coolaid.org

Chris Holt, CEO LogicLynx Technologies Inc., (250) 389-0994,
chris@logiclynx.com

Bill Marsh, Project Manager for Victoria Cool Aid Society,
(250) 888-9475, wcmarsh@shaw.ca

The work discussed in this document was supported by a grant from the Canadian Health Infostructure Partnership Program (Health Canada).

Achievements

Goals Reached

Introduction - Mental Health & Addictions Services in the Downtown Core

Target Population -The CHIPP-sponsored Integrated Community Mental Health Information System project (ICMHIS) had as its overall objective the development and implementation of a software product in support of regional and community mental health and addictions services. The project focused specifically on community-based service provision within the array of downtown core providers that collectively care for a difficult-to-treat group of disenfranchised individual affected by a combination of problems, including major psychiatric illness, addictions, major health problems including various communicable diseases, and the manifold consequences of poverty (see Appendix I).

Healthcare Informatics Challenges - Downtown core providers address the needs of a high-acuity population, collectively delivering a range of services that is similar in scope to a hospital-based setting. These services include emergency response, acute care, physician and medical specialist coverage, nursing care, social work, food, shelter, ongoing monitoring of care, and clinical documentation. However, when the structures and processes of service delivery within an acute care setting are contrasted to their counterparts in the 'shadow hospital' that operates within the downtown core environment, the analogy with hospital-based acute care quickly breaks down, and the applicability of acute-care derived informatics strategies is called into question:

• Within the downtown core, care is provided by a peer network of service providers working under multiple governance structures, only some of which are a part of the public body (compared to care directed by a most responsible physician within a hospital setting, which is relatively homogeneous with respect to information sharing). This poses a special set of informatics challenges with respect to privacy and data sharing; given the health and safety risks associated with segments of the target population, there are difficult ethical issues around not sharing information across provider organizations; efforts to enhance quality of care through use of information systems are certain to fail unless difficult privacy issues are addressed effectively;
• Service is accessed sporadically by clients and there is little structure to support ongoing monitoring and completion of an episode of care by a single provider; the 'health record' (to the extent that it exists at all) may become fragmented within the network of care providers, and important pieces of health information may rest in the hands of social service organizations (rather than traditional healthcare providers); informatics support for coordination and continuity of care becomes a complicated matter; outcome evaluation becomes quite difficult when a baseline is obtained within one setting and an outcome is assessed in another;
• In some service settings within the downtown core, most notably the emergency shelters, documentation is incident-driven, with little in the way of structured and standardized assessment protocols; though each incident-based observation may carry a high information value (compared to the routine charting done in an acute care setting) the clinical record becomes, in effect, a series of ad hoc observations that require a potentially complex set of operations to amalgamate them into a coherent picture of the client's condition and clinical 'trajectory'. The informatics challenge is one of supporting the ad hoc registration of information in such a way that the record can be parsed, enabling the pertinent clinical data to be assembled into a structured picture.

The challenge for the CHIPP-funded phase of the ICMHIS project was to build an information system, supplied with the appropriate privacy/ security mechanisms, clinical vocabularies and parsing/reporting tools, that would address the many complications arising from efforts to provide for the needs of a high-acuity population of individuals within the downtown core service sector.

What elements in the originally approved work plan were achieved?

The original work plan called for a system meeting the following requirements:

• Web-enabled application - a solution was required that could be placed in the hands of service providers with little up-front investment in hardware/ network infrastructure.
• Generic design, rapidly customizable - broad-based deployment of the ICMHIS within the community sector extending outside the bounds of the Health Authority required the development of a system that could support rapid and cost-effective adaptation to the business requirements of a heterogeneous array of health and social service organizations.
• Privacy/security framework - a host of complications arise when networked information systems technology crosses over the boundary of the Health Authority into the non-profit/contract service sector. The work plan called for a solution to information sharing challenges within a heterogeneous array of services, supplied under multiple governance structures, with care delivered by providers possessing differing background qualifications, experience and training.
• Minimum data set - clinical data collection within established programs in the Health Authority is relatively well-structured according to standards and protocols for medically-based services. By contrast, in many community service sites (e. g., emergency shelters), much of the important clinical data collection is carried out in a more ad hoc manner, driven by incidents or high profile health and safety concerns. An information system supporting the delivery of care within the downtown core service sector required the construction of a minimum data set combining structured and ad hoc methods of data collection.
• Reporting - downtown core service providers, particularly non-profit/ contract providers, typically develop methods (often cumbersome) for reporting utilization data to funders. However, organizations (e.g., shelters) providing service to some of the most difficult and complex clients, may lack any capacity to report hard data about the clinical/ behavioural/ risk characteristics of the target populations for service.
  
  
  • One of the base requirements for the ICMHIS system was to supply a method that would capture the knowledge providers hold about their clients (through the use of a clinical minimum data set) and roll that knowledge upward into an accountability/ performance monitoring framework.
  • The performance monitoring framework needed to be able to cross-reference utilization data by information about the functional characteristics of the clients receiving services, in order to evaluate utilization against measures of need.
  • From the perspective of the Vancouver Island Health Authority, the objective ultimately is to link data about service provision in the community to broader-based efforts to create a risk-adjusted/ outcome-based accountability framework for the system of Mental Health & Addictions Services.

The following is the consensus evaluation of the project as offered by a broad range of project stakeholders:

• Web-enabled application - the development team was successful in constructing a web-enabled health information system meeting the business requirements of community-based agencies serving the identified target population. By the completion of the CHIPP-funded phase of the initiative, the system was being used with success by the staff of two emergency shelters in the Victoria downtown core. While there were initial implementation challenges, none were considered to be significant. Staff in the shelters were generally of the opinion that the system will enable improved client services and improved management reporting and planning.
• Generic design, rapidly customizable - The system was constructed as a generic framework into which specific business requirements were added, proving the effectiveness of the data architecture and systems design vis a vis adaptation of the system to the varied needs of different service organizations. The architecture and state of the art technology employed to develop the ICMHIS solution appears to have been validated. The solution was developed using a standard enterprise design framework, and is judged to be scalable, sustainable and quickly and inexpensively modifiable to meet the requirements in an array of different settings. Two benchmarking activities were carried out to assess the customizability of the software:
  
  
  • The BC Ministry of Health Minimum Reporting Requirements were entered into the system (see Appendix IId). Code sets were cut and pasted into the system using an electronic version of the Minimum Reporting Requirements. This portion of the task was completed by a non-programmer, involving a total of 4 hours time. An additional 2 hours of time was required to connect this new assessment into the database and build the user interface.
  • To further evaluate the customizability of the system, the triage oriented acuity/risk assessment (see Appendix IIa, IIb) was entered into the system. This task required close to two days work (including 5 hours of a non-programmer's time), a reflection of the greater complexity of the user interface. Additional time was required to build a format within Crystal Reports to output the results.
• Privacy/ security framework - one of the major project successes was the development of the "Ethical Distribution of Security Access" (EDSA) framework. The EDSA implements privacy protocols within a three-tiered framework. Privacy legislation is effectively coded at the highest level, with organization-based parameters entered into the middle tier. At its lowest level, the EDSA addresses limitations in the more usual role-based or organization-based protocols by enabling the control of information sharing to be extended down to the level of the individual data elements shared between pairs of individuals for specified periods of time. The EDSA framework has been reconciled against the CSA's 10 Principles of Privacy in the ICMHIS Privacy Impact Assessment. See www. logiclynx. com for more information on the EDSA.
• Clinical Minimum Data Set - a mental health and addictions minimum data set was constructed. It consists of two major components.
  
  
  • 16-item triage-oriented tool (Minimum Data Set: Mental Health Triage, i.e., MDS: MHT, Moselle, 2002) designed to measure of the acuity/risk characteristics of a mental health & addictions target population (see Appendix IIa, IIb). This tool was constructed as a means for registering the reasoning behind critical care decisions made by service providers in the context of urgent/emergent response.
  • Observations - a small array of data elements used to capture specific pieces of information about client behaviour, as well as reported medical/psychiatric conditions (see Appendix IIc).

This set of tools proved to be effective as a means for capturing both structured and ad hoc observations, a capacity which was judged to be critical to the usability and effectiveness of the ICMHIS system in community-based settings that do not employ standardized procedures for registering clinically-relevant information about all clients.

• Reporting - Crystal Reports was successfully integrated into the ICMHIS system as a means for generating reports from information entered into the system through both structured and ad hoc information registration methodologies.
• The project has achieved the broad objectives set out in the Project Proposal submitted to Health Canada in July, 2000, though scope of deployment within the CHIPP-funded part of the ICMHIS initiative was more narrow than originally planned. However, there are no technological limitations preventing broader-based deployment, and Phase 2 planning within the VIHA Mental Health & Addictions Service will support expanded use of the system within the community sector.

What were the contributing key factors?

Though the development team was hard-pressed to deliver production versions of the system within the CHIPP-funded time-frame, the project was judged overall to be a success from a technological standpoint and from the standpoint of meeting the business requirements of the users. Factors contributing to the success of this effort include the following:

• Business requirements analysis - the method was first and foremost client-centered, then provider-centered, and only then technology-centered, involving a consideration of the following issues:
  
  
  • Clinical/behavioural profiles of service recipients - who receives the services (psychiatric features; substance use; medical complications; behavioural features; acuity/risk characteristics; social-economic factors; environmental issues)?
  • Clinical/support requirements of service recipients - what are the support/care requirements arising out of the clients clinical/behavioural presentation?
  • Provider service objectives - what objectives do service provider organizations attempt to achieve on-site for their client populations (typically, a subset of the clients' total spectrum of needs); what objectives do service providers attempt to achieve through referrals/ partnerships with other provider organizations?
  • Information systems support requirements - what are pressing issues for providers and clients within the service environments; what are the requirements for an information system that would support the business process and service objectives within the organization; what is the business logic that needs to be captured in the system's operation and interface design?
  • System architecture - what type of systems architecture will support most effectively and efficiently the business requirements for the full range of organizations that will be using the technology?
  Top of Page
• Combination of conservative and progressive design features
  
  
  • Encourage full uptake of the new system - in order to enhance uptake of the ICMHIS system, a conservative approach was taken towards existing business processes within the organization. The system was architected for flexibility in order to enable it to be contoured to the way in which providers were already delivering care.
  • Improve care - in order to enhance the standard of care, an effort was made to develop a clinical minimum data set that would effectively abstract and register the knowledge of service providers in a way that supported better decision-making and better service access throughout the network of care providers.
• Extensive involvement of front-line service providers - construction of the clinical minimum data set was achieved through dialogue with front-line providers to clarify the basis of critical care decisions they make and identify the clinical data elements that they require in the course of providing care.
  
  
  • Development of the 16-item triage-oriented acuity/risk assessment tool involved extensive review of text-based clinical documentation generated by the VIHA Mobile Crisis Response Team, in close collaboration with clinicians working on that team. The strategy was to identify the broad parameters within which clinicians organized their clinical decision-making, and then create a set of scales, each with break points corresponding to the qualitative distinctions clinicians make in assessing client acuity/risk (see Appendix IIb for a sample item with operationalizations of breakpoints).
  • An important part of this effort was to register the care provider's evaluation of those factors that mitigate against the exercise of restrictive care options despite the presence of significant risk - this is an essential component of care provision within a network of providers seeking to support community tenure for a clinically high-risk population.
• Technical features of data architecture, systems design, and programming -
  
  
  • The conceptual data model for the ICMHIS is based on the CDC's Public Health Conceptual Data Model (PHCDM --http://www.cdc.gov/od/hissb/docs/phcdm.htm). This data model provides a generic framework for recording activities related to the provision of services across the continuum of care. This conceptual model provides the basis for a design oriented to public health systems and allowed ICMHIS to achieve a high degree of compatibility with other large scale PHCDM oriented systems internationally. By utilizing this well understood data model the development team was able to focus on creating a flexible and robust data and systems architecture that would support service delivery within a public health care paradigm.
  • The database design decouples the user interface and business process from the database, hence the small number of tables (11) and a high degree of scalability/portability/reuseabilty.
  • Use of XML and XML-Schema as a means of identifying a data model, data structures and data sets to enable an architecture built around a very small number of tables, providing flexibility and the ability of end users to participate in data management activities (e.g., user modification of assessment process).
  • Limiting the number of tables provided the basis for a framework architecture allowing very rapid development of additional modules and components without requiring any modification of the core components of the system.
  • Capacity for rapid development of additional system components was demonstrated through the rapid modification of a number of items identified during the course of training and after roll-out. Data elements that were missing or inappropriate were modified and put into place with no requirement to re-compile or re-engineer system components.
  • The use of standards, including XML and HL7 V3.0, gives the system the ability to communicate more easily with primary care systems.
  • A combination of programming techniques was employed. The approach used a combination of extreme and waterfall/ reiterative programming depending on the elements being developed. The development team's software systems architect took a modular component-oriented approach to building the system, and therefore gained systems validation of objects on a develop/ test/ implement basis. This approach was judged to be appropriate given the extensive use of cutting-edge technologies.
  • A traditional IEEE approach was used for project documentation.
  • HAIL Health Registry interface - use of this functionality was not part of the business requirements, but the development team successfully tested the HAIL Health Registry interface on test data prior to the end of the project.
• Key roles
  
  
  • Project manager - though the development team was quite small, a large number of elements needed to come together to complete the development and implementation of the system. As the ICMHIS project progressed, it became increasingly clear that a very formal project management structure was necessary for project success.
  • 'Arms-length' risk manager - steps taken to address issues identified by the risk manager turned out to be critical to the successful completion of the project
  • 'Translators' - one coming from the service delivery side, with good capacity to learn about the technology, and one from the technology side with good capacity to understand both the mechanics and the rationale for the business processes, both meeting somewhere in the 'middle'.
  • Data architect/ system designer with a good knowledge of the business process- the requirement that a high degree of flexibility be preserved within an enterprise level system placed a high premium on the capacity of the data architect to abstract the generic features of the business process and design a system that did not impose a systems architecture on the business rules and user interface.
  • Technology development manager - the technological development approach was highly methodical and highly structured.
  • Project documentation - a person with a good understanding of the project and a solid background in software documentation.
  • Support roles
    
    
    • A person with an excellent understanding of the business reporting requirements of Health Canada;
    • A general purpose support person capable of mastering a broad range of tasks, ranging from business requirements analysis to privacy impact analysis to training/onsite support during implementation to project evaluation.

What were the obstacles or challenges and how were they addressed?

• Time was a scarce commodity - 18 months to design, build, implement and evaluate the health-related impacts of the system was insufficient, particularly in light of some of the innovations that were required to develop the system. The scope for deployment of the system was scaled back, some non-essential business functionality was taken out of scope, and the system was not in operation long enough at the time of evaluation to assess impacts in any truly compelling fashion.
• Roles, responsibilities and accountabilities of stakeholders were not adequately clear at the outset of the project, and this resulted in project delays; by mid-project the roles and responsibilities were clarified. In addition, a technically very proficient business analyst was hired, an individual with a solid grasp of the design of the system and good capacity to work with users until they had exactly specified the business process.
• The delay in formally completing user requirements on schedule was a major project concern. Although the design of the system called for a generic engine into which the requirements could be 'dropped' towards the end of the development process, in practice the late delivery of business requirements resulted in the compression of some tasks, and with minimal time allocated to some required tasks.
• Existing solutions to some of the types of problems addressed in the ICMHIS project proved to be unworkable or incomplete, placing an additional burden on the development team. In particular, the HL7 standard did not supply many of the clinical vocabularies required to support the delivery of care in the community, and other clinical minimum data sets did not supply solutions that would be logistically feasible to implement in many downtown core settings.

Additional Successes

What elements were achieved beyond the originally approved work plan?

Additional successes included enhanced understanding of business requirements; identification of parameters within which solutions could be crafted; and in some cases the full implementation of solutions:

• Privacy/ security challenges - One of the most challenging issues was concerned with data sharing across an heterogeneous collection of environments (with a variety of different providers collecting an heterogeneous set of data elements).
  
  
  • The issues became complex in relationship to different service units operating under the governance of a single non-profit society. From a business process standpoint, the issues revolve around specifying protocols for sharing information. Role-based protocols were implemented in the shelters, but it became apparent that with some of the clients receiving service in the shelters, consent-based sharing would need to take place on a limited basis (limited as far as the information that is shared, and limited as to who specifically would be allowed to see information).
  • From a technical standpoint - the issues revolve around the capacity to implement privacy policies at a sufficiently low level of granularity to support limited information sharing on a person-to-person basis.
  • From a logistical standpoint - the issues revolve around design for a scheme that makes it feasible to implement privacy policies at a more granular level than the usual role-based privacy policies.
  • From the standpoint of clinical vocabularies and a 'language' to describe clients and the services they receive - the identified requirement was for a syntax that would amalgamate smaller units of clinical data into larger clinically meaningful groupings that are homogeneous with respect to purpose and, by extension, homogeneous with respect to sharing.
• Privacy/ security solutions -
  
  
  • Strategy -some (but not all) existing privacy practices among downtown core providers were organized around principles that were somewhat more stringent than existing privacy legislation would require appear to require. The overall strategy was to respect existing practices where they were perhaps overly stringent, as sensitivity around privacy on the part of providers was judged to be probably the greatest risk to effective deployment of the system across a broader base of community sites.
  • The result was business rules around information sharing that appear to be more complex and differentiated than those governing sharing within the confines of the Health Authority.
  • Arising out of these business rules were technical challenges that had to be surmounted in order to implement the rules.
  • Business rules governing the sharing of information - some of the rules were well understood at the time of project initiation and were implemented into the system design. Others were not understood fully until users could see the system in operation and identify the points at which its function did not mirror existing practices.
    
    
    • One set of issues revolved around the basic client search functions at the point of registering clients into the system, given that not all services would be validating clients against a central client registry (which effectively anonymizes the registration of basic demographic information).
    • Issues also came up around the need to protect some but not all demographic information from providers operating under the same umbrella governance framework in a community organization providing a heterogeneous collection of services.
  • Technical capacity to implement privacy protocols - the EDSA privacy framework was capable of implementing the business rules governing information exchange that had been identified clearly by mid-project. It is the consensus of the development team that the EDSA framework is sufficiently granular that it can implement the additional business rules that had been identified by the conclusion of the project.
• Feasibility of implementing field-level privacy policies - the Clinical Context Descriptors Schema - while the EDSA technology is capable of implementing field-level privacy policies at the level of person-to-person exchange of information, it is not feasible to regulate data sharing at that level. A requirement was identified for some type of schema to organize data elements into collections for purposes of limited information sharing. The parameters that enable these collections of data elements are reflected in the specifications for the ICMHIS Clinical Context Descriptors Schema, or CCDS. The CCDS is a metadata structure with the following properties:
  
  
  • The CCDS is a generic description of a unit of clinical activity that is homogeneous with respect to purpose;
  • Each CCDS-defined unit of activity specifies a minimum data set necessary to support the actions/ decisions that take place within the context;
  • Because each unit within the CCDS is defined in relationship to a specified purpose, the data elements within a given CCDS unit may be regarded as homogeneous with respect to data sharing, and hence to privacy;
  • The CCDS is conceived by the ICMHIS team as a strategy for handling the logistics around data sharing at a level that is more granular than is typically the case in acute care, but less granular than the EDSA privacy/ security framework is capable of delivering.
  • The CCDS schema was not fully specified by the completion of the CHIPP-funded portion of the ICMHIS project. Its functionality was not specifically required to complete the CHIPP-funded portion of the ICMHIS project, though it would have provided a more structured solution to a data sharing problem that was solved in a somewhat more ad hoc and probably temporary fashion;
  • It was clear, however, that if information sharing is to take place when ICMHIS has been deployed in a more heterogeneous set of environments, limited data sharing will need to be more fully enabled, and it will become necessary to further specify the CCDS schema and implement it within the ICMHIS user interface;
  • As presently conceived, the CCDS does not appear to require any modification of base architecture of the system.
• Clinical vocabularies - the CCDS is a generic schema that must be supplied with clinical vocabularies to give it concrete definition within a given area of health care. A provisional specification of required vocabularies has been made. Supplying values to the vocabularies remains as a major uncompleted task.
• Overall, the ICMHIS project was successful in shedding important light on some of the privacy issues that will prove to be decisive with respect to deployment of electronic health information technology into the full extension of the continuum of care for mental health & addictions clients. The EDSA technology has been deployed successfully and is believed to be sufficiently granular to support virtually any privacy policy. The CCDS schema with accompanying vocabularies requires further development work to become an effective means for using underlying EDSA technology to enable limited data sharing.

What were the contributing key factors?

• Understanding the challenges of information sharing in community-based settings arose quite naturally out of the process of doing requirements analysis across several different service delivery sites.
• Requirements for the EDSA framework had been identified by the outset of the project, and success of efforts to craft the EDSA technology is attributable to the fact that those requirements were built into the framework of the system. The EDSA was built to deal with privacy as required in the scope, but was architected to deliver wider and deeper privacy in anticipation of expanded system adoption and possible privacy changes in the original scope.
• Specification of design parameters for the Clinical Context Descriptors Schema was enabled through a series of steps involving analysis of the clinical activities across the continuum of mental health & addictions services and abstracting a general form that could be used to describe any of those activities.

Unreached Goals

• Interface with the BC Ministry of Health Central Client Registry access - there were no business rules for the CHIPP-funded phase of the ICMHIS project that involved validation of demographics against the Central Client Registry. Consequently, there is no business functionality within the current version of ICMHIS that taps into the interface. However, testing of the interface into the Central Client Registry was successfully completed by the end of the CHIPP-funded phase of the project.

Documents or Products Generated

Document /Product Name	Available in Paper and/or Electronic Form	Licence Fee Required for use (Yes/No)	Previously Provided to Health Canada (Yes/No)	Appendix Name /Number
User Guide(s) and/or Training Manual(s): Training Plan and Materials Software User Manual	Yes Yes	No No	No No
Software Application(s): Scope Document Concept of Operations System & Business Requirements Case Tool Selection System Physical Implementation Messaging Protocols & Standards Software Evaluation Plan ICMHIS Software (including EDSA)	Yes Yes Yes Yes Yes Yes Yes Yes Yes	No No No No No No No No No	No No No No No No No No No
ICMHIS Final Evaluation Report	Yes	No	No
Standards, includes: Minimum Data Set: Mental Health Triage (MDS: MHT) 16 Item Acuity /Severity Scale Structured Observations	Yes	No	No	IIa, IIb, IIc
Clinical Training Protocols Implementation Plan Use Case Scenario -Vanessa	Yes Yes	No No	No No	I
Confidentiality and Privacy documents: ICMHIS Privacy Impact Assessment	Yes	No	Draft
Sustainability Plan Needs-Based Service Delivery Initiative - Business Plans; Charter	Yes	No	No

Main Impact

Immedicate Impacts on Service

The ICMHIS project adopted an aggressive development cycle to get a production version of the system up and running by the conclusion of the CHIPP-funded part of the initiative. One important consequence of the limited deployment within the available timeframe was inadequate opportunity to assess broad-based impacts of the ICMHIS. However, there were clearly identified impacts on the practices of individual providers within the timeframe of the ICMHIS project evaluation:

• More systematic observation, evaluation and documentation of acuity/ risk characteristics of clients - the ICMHIS clinical minimum datasets provide a structure and focus for clinical documentation, regardless of whether information is being registered in an ad hoc or structured fashion.
• More appropriate registration of information - the system enforces a relatively low level of inference by requiring the user to specify an information source for data that calls for some form of validation.
• Better discrimination - by separating out information concerned specifically with risk from information concerned with mental status, the system helps to clarify the distinction between behaviour which is benign, albeit unusual, from behaviour that carries a significant risk. This is important from a privacy standpoint, as behaviour related to risk has a clear need-to-know basis for registration into an information system.
• Decision support - by separating out unusual behaviour from dangerous behaviour, the system enables providers to be appropriately thoughtful and cautious about initiating intrusive interventions (e.g., calling police).
  
  
  • More effective communication - the clinical tools built into the ICMHIS system are intended to facilitate communication with VIHA core service providers (e.g., staff in the emergency rooms) by supplying community-based providers with the same clinical vocabularies that are slated for deployment among VIHA service providers working at various points in the Mental Health & Addictions continuum of care.
  • More appropriate data management practices - there is considerable variation in the manner in which information is maintained and safeguarded in community sites. In its current implementation, the ICMHIS system stores data in a single protected site. The system also ensures that data is backed up and preserved for an appropriate length of time. This encourages providers to be appropriately cautious about entering client data in the first place, and it confronts them with the requirement that they have a clear purpose for registering information, in order to justify in their own thinking the registration of information in some long-lasting form.

Human Resources Impact

• What new skills have staff/health care providers developed? - the ICMHIS system places tools in the hands of community-based providers that enable them to capture clinically-relevant information without employing descriptive and diagnostic terminologies whose use is restricted to specific disciplines or licenses/ certifications. On-site training is currently being provided to staff involved in the ICMHIS initiative to supply them with more of the background information that undergirds the clinical vocabularies built into the ICMHIS system.
• Have new positions been developed? - plans for Phase 2 expansion of the ICMHIS system involve the creation of new positions concerned with training and data management. A new Mental Health & Addictions management position has been created within the Vancouver Island Health Authority to direct Phase 2 expansion of the ICMHIS system and construct an accountability/ performance monitoring framework that will depend in important ways on the data supplied by the ICMHIS system.
• New capacity within the Mental Health & Addictions Program - service providers who are better able to analyze their business requirements in ways that 'speak' to software developers are more likely to have those requirements met in various information systems initiatives. They are also better able to identify ways in which information systems can contribute to the enhancement of service delivery, evaluation and management.
• Has the new technology created new demands on service providers? - in its current implementation, the ICMHIS system does not appear to have created an increased demand on providers. The potential for the system to turn providers into 'data collectors' is offset within the ICMHIS system by the clinical tools it supplies for ad hoc registration of information. This enables providers to enter information when a specific need arises in the course of delivering service, without imposing the requirement that they gather and input information using tools that are not contoured to their business process. At the same time, the system provides tools that enhance their capacity to provide structured information at those times when they need to supply additional information to other service providers (e.g., mobile crisis response team workers). The intention of the system is not to increase demand on providers in a quantitative sense, but the system is intended to promote distinct qualitative shifts in the manner in which providers think about clients, record information about clients, and intervene around issues of health and safety.
• Has job satisfaction changed? - within the community-based settings, several staff members have become champions of the ICMHIS system in their environments, and have developed new skills enabling them to participate as important members of the ICMHIS development team. The ICMHIS system has clearly enhanced capacity within the community service sites to participate constructively in the development of solutions for information collection/ exchange. This is regarded as critical to the further development and deployment of ICMHIS across a broader range of sites in the community.
• Was there resistance to change? - there was little resistance to change, in view of concerns about the legacy system replaced by ICMHIS. However, there were pockets of resistance to information systems technologies that predated ICMHIS and were reflected in a small number of users with very limited knowledge about computers; this had an impact on the amount of training that needed to be provided for some users.
• Resistance is sometimes a good thing - some of the users who were not very enthusiastic about any form of information technology provided useful recommendations on how to streamline the ICMHIS system.

Privacy and Protestion of Information

• Have there been changes in the behaviour of health professionals/ staff with respect to the protection of personal health information? - at the point of user requirements analysis and during training and implementation, emphasis was placed on the requirement that information be gathered for a clearly identifiable purpose that the person entering the information could presumably identify. Some staff noted that this would require them to reflect carefully before registering information, particularly information about behaviour that might have some clear relationship to health or safety in the absence of immediate risk or danger. Some staff noted that they would need to be more cautious about what kind of information they collected, knowing that the information would be preserved for years to come.
  
  
  • The initial concern on the part of some providers in the community was that members of the development team working within the Health Authority might pressure community providers to make information sharable in ways that they felt were inappropriate.
  • By the conclusion of the project, some community providers were beginning to realize that the Health Authority brings a well defined and binding set of parameters to the issue of information collection, and some were of the opinion that they would in fact need to be more cautious about entering and sharing information in light of input from the Health Authority.
  • There remained non-specific concerns about privacy related to the fact that the data would be entered and accessed within a networked environment.
• Have changes been made to policies and procedures within the Health Authority? - the Vancouver Island Health Authority was in the process of implementing new privacy policies during the course of the ICMHIS project. They were not driven by the ICMHIS project but were very compatible with the approaches being implemented in the ICMHIS system.
• Was a Privacy Impact Assessment completed? - a comprehensive PIA was completed, and the activity was productive in a number of regards:
  
  
  • Clarifying the need-to-know basis for registering client information
  • Clarifying the nature and type of information that could legitimately be collected via indirect means
  • Highlighting an array of issues related to data ownership and information sharing
  • Identifying specific requirements for the system related to the management of data sharing
  • Identifying a set of parameters that collectively provides a framework for defining business rules related to information sharing
  • The Clinical Context Descriptors Schema (CCDS) is intended as a means for structuring the collection of information around a explicitly articulated need. It is also intended as a means for utilizing the functionality provided by the EDSA privacy framework to create a capacity for limited sharing of health information within an electronic environment. The Privacy Officer within VIHA has expressed interest in this schema, and the Privacy Office is regarded as an important stakeholder in further development of the CCDS functionality.
• Were there changes in policies and procedures as a result of the Privacy Impact Assessment? - in its initial implementation, the ICMHIS system has been deployed in two downtown core emergency shelters. These programs provide contract services for the Health Authority but have virtually no contact with the VIHA Health Records Department or the VIHA Privacy Coordinator. As a result, various information management practices have evolved that would not satisfy some basic requirements for records management within the Health Authority (e.g., record retention). Carrying out the PIA, and implementing the system brought into high profile some of the practices that required modification. Implementing the ICMHIS system provided an opportunity to highlight required changes in data entry/management practices, anticipating some of the changes that would have been required anyway as a consequence of the new VIHA Privacy Policy, which covers contract service providers as well as core service providers. The overall direction of the change was one of more limited collection of clinical information around a clearly identified need-to-know basis.
• Did the ICMHIS project participate in the CHIPP Privacy and Security Survey conducted in August 2002? - the ICMHIS Project Team did not participate in the CHIPP Privacy and Security Survey.
• Did the ICMHIS project receive any patient views/ concerns/ compliments on the handling and use of their personal information? - the ICMHIS project did not consult with clients on the manner in which personal information was being handled. However, the staff within the shelters regard themselves as strong patient advocates (as exemplified, for example, in their requirement that the system support anonymous patient registrations, despite the complications this has created for other services operating under the common governance of the Cool Aid Society). In the end, the VIHA Mental Health & Addictions lead for the ICMHIS took a more conservative stance than the staff in the shelters, specifically around the issue of conditions under which clinical information could be registered into the system.
• Did any of the ICMHIS privacy/confidentiality rules/guidelines help or hinder health care providers (all staff) to provide patient service? - three issues arose within the context of the ICMHIS project:
  
  
  • Collecting information on a clearly identified need-to-know basis - while this principle already governs existing practices within the shelters, the position taken from the Health Authority side was that information should only be collected in relationship to concerns over client health/safety or that of other shelter residents or staff. This position was taken, in part, in relationship to the scope of information sharing within the initial deployment of the system (sharing with the Community Health Clinic - concerned with major health concerns, and with the Emergency Mental Health Service - concerned with risk associated with impaired mental status).
  • The business process within the shelters extends well beyond the provision of food/shelter and the management of immediate health and safety risks. Shelter providers are de facto case managers for roughly 50% of the clients who use the services. As the ICMHIS system is configured to support a broader network of service partnerships, not all of which are immediately concerned with health and safety, the conditions under which information will be collected and shared by the shelters will change. The Clinical Context Descriptors Schema is conceived as the basis for structuring the expanded collection and sharing of information within the ICMHIS system.
  • Data retention policies - providers within the shelters have evolved data retention policies that are not in keeping with those within the health authority. In light of the contractual relationship between the shelters and VIHA, shelter staff would be accountable to the new VIHA Privacy Policy, which extends into the contract service sector. Implementation of the ICMHIS system, with associated data retention policies, required staff within the shelters to re-evaluate data collection procedures in relationship to the ICMHIS system, which enforces more 'industry-standard' retention policies.
• On a more general level, implementation of the ICMHIS system served to bring to the fore a prevalent belief that paper records are somehow less amenable to improper sharing, and so less information should be registered in electronic form. While there are certainly substantial risks and new complications associated with electronic health records, the dialogue arising in the implementation of the ICMHIS system served to highlight for users the fact that principles of privacy ultimately apply to the information, not the medium in which the information is registered.
• What tools were used for obtaining and managing patient consent? - within the shelters, paper and pencil consent continued to be employed.
• Were there instances where patients refused consent? - the situation did not arise in the course of the initial implementation of the ICMHIS system.
• Will regular Privacy Impact Assessments be conduct? - the Privacy Impact Assessment that was completed for the CHIPP-funded portion of the ICMHIS initiative is regarded as a foundation for subsequent PIA's or addendums to the existing one.
  
  
  • As the system is deployed in more settings, and as new occasions arise for information sharing, Information Sharing Agreements will need to be secure and/or the PIA will need to be modified.
  • The overall strategy is to implement the system in separate silos and only 'lower the draw-bridge' after a run-in period in a new site. In that manner, issues of privacy and information sharing can be considered more concretely in relationship to the situations that arise in the course of using the system. While planning and foresight can set parameters for information sharing, the experience in building and implementing the ICMHIS system illustrated the need to treat privacy, at least in part, as an empirical question, to be illuminated by examination of the data, i.e., the information that is actually being registered and considered for sharing.
  • As each new node is added to the network, the PIA will need to be revisited.
  • The Clinical Context Descriptors Schema is intended as a means for simplifying the process of updating the PIA by grouping data into larger units and enabling issues of privacy to be considered in relationship to a smaller number of units that are homogeneous with respect to information sharing.
• Have ICMHIS project staff participated in discussions with representatives of provincial health infostructure networks on privacy and protection of personal health information? - yes, the ICMHIS lead from VIHA Mental Health & Addictions has attended various sessions at conferences that were conducted by individuals doing major work for the Ministry of Health on privacy.
• Has the ICMHIS project influenced privacy policy and process development in its jurisdiction? - yes, the ICMHIS project has addressed issues around privacy within the community-based non-profit/ contract service sector that is of interest to parties involved in community-based service delivery outside of Mental Health & Addictions. The Clinical Context Descriptors Schema (CCDS) defines a strategy and method for limited data sharing that addresses issues of privacy and consent that extend well beyond the scope of ICMHIS. This schema has come to the attention of the VIHA Privacy Officer, and further development of that schema will be undertaken with direct involvement of the Privacy Office.

Policy & Research Implications

Major Finding #1: Accountability/ Performance Monitoring Framework for Community-Based Mental Health & Addictions - Data Models, Data Standards

The ICMHIS system was successfully deployed within a portion of the service continuum that is not typically covered by enterprise solutions for core services within Health Authorities. Development and deployment within this sector brought to light several issues related to structures governing the collection and organization of clinical data. These issues are critically important to the extension of outcome assessment/ population health status assessment methodologies into the sector of care lying outside the boundaries of services supplied directly by many health authorities.

Further efforts to extend the ICMHIS deployment in the community may carry important policy implications, and the weight attached to the data within an accountability framework should be based on additional research:

Policy Implications -
There are policy implications associated with the use of ICMHIS data to construct an accountability/ performance monitoring framework. These policy issues centre around data standards, selection of an underlying conceptual health data model for purposes of system design, and construction and utilization of new indicators and client descriptors that capitalize on the data supplied by the ICMHIS for purposes of accountability.

• Data standards - Clinical vocabularies supplied by HL7 do not provide adequate coverage within the domain of community mental health and addictions service delivery. The ICMHIS project found itself in the position of constructing descriptive vocabularies in order to supply providers with required clinical tools. If these vocabularies are to be used for purposes of accountability and performance monitoring within the health authority, they require two forms of validation:
  
  
  • empirical evaluation to demonstrate concurrent and predictive validity
  • peer review via appropriately constituted standards bodies/processes to establish consensual validity; the peer reference group must be actively involved in the area of healthcare informatics within the community service sector
• Conceptual health data model for purposes of system design - the ICMHIS system describes the target population within a biopsychosocioeconomic data model, and the system is concerned with status of populations as well as individuals. As such, the ICMHIS system registers clinical signs and symptoms, but also looks at the social-environmental determinants of health, and is intended to supply information about the health status and treatment outcome status of populations. With these considerations in mind, the CDC Public Health Conceptual Data Model (PHCDM) was used in constructing the system.
  Reasons for this choice include
  
  
  • scope and flexibility of the model
  • the model appears to be an emerging standard
  • the model looks at the care recipient from an appropriately multi-dimensional standpoint
  The Canadian Conceptual Health Data Model was one of the inputs for the PHCDM, and it is the view of the data architect for the ICMHIS system that the CDC model encompasses the Canadian Conceptual Health Data model. Consequently, the ICMHIS team does not see an issue with respect to 'competing' data models.
• Accountability/performance monitoring - within many mental health systems, the distribution of health care dollars across hospital and community service sectors appears to be rationalized on the basis of an assumption that those who are most in need and most able to benefit from services are either located within hospital-based psychiatric inpatient units or are connected to core case management/ housing services provided by the health care system (typically accessed initially via an initial stay within an acute care setting). Other more controversial assumptions are sometimes voiced, e.g., clients residing within downtown core areas, particularly those involved with substance abuse, are less responsive to treatment and therefore healthcare expenditure within this sector cannot be justified. Any or all of these claims may be true, and existing patterns of resource allocation may be fully justifiable, but the status quo is not based on comparable data acquired from the hospital and community sectors. The ICMHIS system is intended, among other things, as a source of data that can address questions concerned with equitable distribution of healthcare dollars in relationship to need. Two classes of questions carrying policy implications may be addressed with the data:
  
  
  • Patterns of service utilization - to what extent do clients receiving a major portion of service within downtown core areas overlap with clients accessing hospital-based acute care services; do clients cross over from one system of care into the other; is movement in one 'direction' more or less likely than another; is sector-of-entry related to outcome?
  • Client characteristics - how do clients receiving the major portion of their care within the downtown core service sector compare to hospital-based acute care recipients vis a vis 'state' characteristics (baseline functional status) and 'trait' characteristics (acuity/ risk profile)? In this document the term 'shadow hospital' has been used to describe the downtown core service sector. Is this term misapplied or is it an apt description?
• A common clinical vocabulary is required to perform this comparison, and a technology is necessary to collect the information. However, even if the data are collected, the comparisons are performed and the results validated against repeated data samplings, there will still remain the need for an organizational commitment to allow the data to function as a driver for program redesign and quality assurance/quality improvement activities. For this to take place, the validation research must be done to establish the proper weighting that should be applied to the data.
• Existing accountability/ performance monitoring frameworks appear to be based as much on what data can be collected (e.g., case mix groupings based on diagnoses abstracted from inpatient stays) as what data should be collected (e.g., case mix groupings based on ecologically valid functional assessment of clients). Advances in healthcare informatics enable the direct measurement of quantities that are currently indexed by proxies of questionable power and validity (e.g., length of stay employed as a proxy for severity of illness; service utilization data used as a proxy for outcome).
  
  
  • Health Authorities may develop accountability frameworks for internal use that capitalize on local informatics capacity. These local efforts will supply information that can inform provincial or federal efforts to construct frameworks for health care accountability.
  • The issues involved in constructing an outcome based accountability framework for Mental Health & Addictions Services are complex, and solutions will emerge through a paradigm of evolution, not top-down construction. This evolutionary process carries implications for systems architecture and design - enterprise level systems that are truly flexible will provide support. Systems that are more rigidly architected may implement solutions, but they are not designed for the iterative processes that will inevitably be involved in the construction of outcome based accountability frameworks that can be demonstrated to be valid, useful, and practical within the contexts in which care is provided.

Applied Research Implications

• Ad hoc vs. structured methods for collecting health information - structured methods for collecting information (e.g., use of tools such as the RAI assessments) may be effectively deployed in settings where structured collection of health information is a central part of the business process (e.g., delivery of care within an inpatient unit). However, in many important service delivery sites within downtown core areas (e.g., emergency shelters), providers of an array of services do not engage in routine collection of health information, and the business process will not support routine collection of information using relatively time-consuming methods.
• The use of ad hoc methods to register information poses two major research tasks:
  
  
  • Development of clinical vocabularies to support ad hoc registration of information (see Major Finding #2, below). The vocabularies included within the ICMHIS system must be regarded strictly as first attempts to map out the territory covered by the system and begin to supply some useful content.
  • Development of reporting methodologies to derive structured indicators from information registered in an ad hoc manner: in settings where ad hoc methods are the predominant method for collecting information, documentation is generally incident-driven. The method mirrors the charting by exception paradigm in hospital settings. However, in hospital settings, that charting methodology complements more structured assessments. Where ad hoc assessment methods are not accompanied by structured data collection, it becomes difficult to formulate a baseline assessment and assess progress towards outcomes. The challenge is to develop a reporting methodology that creates a structured picture of client functioning out of ad hoc data that is comparable to what might be derived from more structured methods of assessment. This poses research challenges for a system such as ICMHIS that supplies ad hoc documentation methodologies to providers:
    
    
    • Technical challenges are involved in developing suitably generic methods for parsing the database and creating intermediary data arrays that can be used with generic reporting tools to explore different ways of describing and classifying persons on the basis of ad hoc observational data
    • Substantive challenges are involved in specifying the clinical criteria used to define indicators based on ad hoc information
    • Empirical challenges are involved in establishing the concurrent and predictive validity of indicators generated from ad hoc information

Recommended Next Steps:

• Extend the deployment of ICMHIS as a way of further testing the utility and completeness of what may be an overly-compact ad hoc reporting methodology;
• Partnership with the Health Information Sciences Program and the Addictions Research Group at the University of Victoria to extend and validate the vocabularies in HL7 in order to cover the delivery of mental health & addictions services in the community
• Further development of a generic method for parsing the ICMHIS database to produce values on a standardized array of indicators using ad hoc information

Major Finding #2 - Minimum Data Set (MDS) for Community Mental Health & Addictions Services

The separation of addictions and mental health service systems, often extending up to ministerial level, is not reflected in the real comorbidities of clients contending with addictions and/ or mental health problems, nor is it reflected in the client populations presenting in various downtown core service sites. A minimum data set that supplies care providers with the means to describe key characteristics of clients within community settings must reflect all of the pertinent characteristics that determine client's care requirements.

In the case of ICMHIS, the clinical minimum data set describes clients within a multidimensional space that looks at 'intrinsic' characteristics of the clients, consequences of behaviour, along with social-environmental and historical factors. The tools appears to be sufficient as a means for describing client acuity/risk characteristics (psychiatric/behavioural; medical) and current requirements for care/supervision/control. However, the minimum data set has not been subject to empirical validation.

Applied Research Implications - A major piece of research is required to address the following questions:

• Does the minimum data set possess adequate predictive and concurrent validity?
• Are there critical care decisions made within specific environments that are not adequately predicted by items in the MDS (i.e., is it missing key elements)?
• Can the minimum data set be reduced in size (does it possess elements that do not contribute to its capacity to inform decision making or predict various outcomes, and therefore can be dropped)?
• Does an empirical typological analysis of the minimum data set yield clinically intelligible groups of clients that are homogeneous with respect to care requirements?
• Discriminant validity -Designing an MDS that can predict the use of restrictive care options when significant risks are present (e.g., calling police when a psychotic resident attacks other individuals) is not a difficult matter. However, clinicians and care providers do not always opt for the more restrictive care options, and indeed are obligated to seek the least restrictive care options possible. The challenge is to design an MDS that contain the elements necessary to predict the use of less restrictive care options despite the presence of risk (e.g., not calling the police despite evidence of marked impairment of mental status). A tool that does a poor job of capturing the reasoning of care providers when they exercise less restrictive care options is not likely to be accepted.
• User satisfaction studies employing robust methodologies are required to assess the utility and user friendliness of minimum data sets and the structured and ad hoc methodologies that are used to register and report the information.

Recommended Next Steps

• Within the Vancouver Island Health Authority, an initiative is under way to develop and implement a Mental Health & Addictions Screener. This tool is built around a core set of data elements encompassing the Ministry of Health Minimum Reporting Requirements, which have been coded into the ICMHIS, 'wrapped' in many of the data elements constituting the ICMHIS clinical minimum data set.
• As ICMHIS is deployed more broadly in the community, and as the Screener is deployed across Mental Health & Addictions Services in the Health Authority, a large quantity of data will quickly amass, consisting of clinical descriptions and ratings based on the MDS, and information about various care decisions that are made in the settings where the MDS data have been collected.
• The validation studies described, above, are included within the scope of the Screener initiative in VIHA.

Major Finding #3 - Alerts

Alerts are an important function in systems supporting care for high acuity/ risk clients. Protocols for setting alerts are reasonably straightforward when risks are judged to be serious, imminent and enduring within the environments where care is delivered. Issues in setting alerts become more complex when the severity, imminence and durability criteria are not met. In high-risk environments, the issue is complicated by reluctance on the part of staff to set alerts on too many clients, the concern being that alerts will cease to carry any message value if they become the norm rather than the outlier.

These are categorical concerns about alerts. However, in the ICMHIS system, there are also specific concerns about setting alerts that are related to the fact that there is no procedure for downgrading alerts or setting them as inactive.

• This state of affairs is not reflection of the technology, so much as lack of clarity on the business rules governing the management of alerts.
• Solutions such as taking alerts down after a specified period of time are not appropriate to the situation for the downtown core providers - many clients are transient, and they may be away for extended periods of time. An absence of alert-related activity for a client does not mean that their risk status has necessarily diminished.

Applied Research Implications - Within the ICMHIS system, alert flags can only be set within the context of a clinical or behavioural observation, so system functionality provides support for the judgments behind alerts. Two aspects of functionality remain as unfinished work:

• Investigative Procedures - an alert is fundamentally a statement of possibility, not necessary a statement of fact. An alert should trigger an investigation to enable correct interpretation of the current status (imminence, durability, severity) of the risk. The ICMHIS system current provides three pieces of functionality that are first steps forwards such an investigation:
  
  
  • Means to identify the Observation (i.e., the context) in which the alert was set - this provides information about the alert, albeit on a fairly granular level that may attach a value to severity and imminence but does not necessarily address the issue of durability.
  • Means to capture information about client acuity/risk characteristics - the 16-item acuity/risk assessment, included as a core element of the Minimum Data Set: Mental Health Triage tools in the system, is designed very specifically to assess acuity and risk in an ecologically valid, multidimensional manner. But it is intended to assess risk characteristics of clients in an immediate context, extending over the next 24-72 hours (i.e., the time-frame for urgent/emergent response). It does not specifically address concerns about long-term risk.
  • Means to provide a summary view of the client - the Client Clinical Case Summary Report. This helps to 'track' the clinical/ behavioural trajectory of the client, but the report in its current configuration is not organized specifically around alerts.

Recommended Next Steps

There are two major sets of issues that will determine the next steps:

• Business rules governing the behaviour of Alerts in the system
  
  
  • Any health service organization attempting to implement electronic health records will inevitably encounter the issue of alerts and the complexities around managing them. A focused piece of research bringing together information from various programs/health authorities should enable the issues and options to be laid out clearly for purposes of evaluation by information systems developers.
  • Privacy concerns - in a networked environment that has the capacity to bring together information from multiple service units operating under multiple governances across the public and non-profit/ contract sectors, issues around sharing Alert information - as well as not sharing such information - come immediately to the fore.
    
    
    • Business rules need to be established around alerts showing on client records when the alert has been set by a different service unit within an organization, or by a different organization.
    • The issue can be addressed reasonably directly in the abstract by considering various pieces of privacy legislation and various codes governing management of health information.
    • However, within a given region or system, the issues around alerts need to be considered in relationship to local practices and sensitivities around information sharing, which introduce additional parameters into the decision matrix around the sharing of Alert information.
  • Systems design and technology to implement the business rules around Alerts
    
    
    • The Clinical Context Descriptors Schema (CCDS) is intended to provide a means for structuring the collection of information around a specific clinical purpose or intent. Within the next build of ICMHIS, the plan is to include requirements for managing and documenting Alerts into the design of the CCDS schema.
    • In the next build of the ICMHIS, the Client Clinical Case Summary will need to be altered to provide enhanced support for the interpretation and management of Alerts.
    • One of the relatively simpler challenges related to Alerts for the ICMHIS will be to modify the user interface to include more information about the status of Alerts.

Major Finding #4 - Accountability/ Performance Monitoring

There are at least three gold standards for an accountability/ performance monitoring framework:

• Risk-adjusted outcome measurement
• Utilization measures evaluated against case-mix groupings that reflect client functional status
• Truly representative sampling of the health status of the target population for services.

Existing frameworks appear to have been constructed with an emphasis on delivery of hospital-based services for a medical population. Approaches to performance monitoring that trace their roots back to acute care and the hospital ADT systems used to manage patient registrations and bed occupancy are affected by shortcomings that limit their usefulness for mental health & addictions clients (see Appendix IIIb for a depiction of the "as-is" case, Appendix IIIa for a representation of an accountability framework based on present and planned ICMHIS functionality). These limitations appear in two areas:

• Utilization measures, measures of resource intensity - measures that are appropriate for acute care environment (e.g., length of stay, alternative level of care days, etc.) may be appropriate for acute care environments. However, questions were raised in the user requirements phase of the ICMHIS project around the suitability of such metrics for an accountability/performance monitoring framework for community-based mental health & addictions services.
  
  
  • Issues centre around what should be counted and how to apply resource intensity weightings to activities.
  • Service recipients in the community access multiple services from multiple providers, generally at times of high need. Data on service access across programs would need to be amalgamated together to paint a meaningful picture of service utilization for a given target population. There are logistical issues around how to ensure that comparable units of activity are being amalgamated.
• Client descriptors, case mix groupings - The performance monitoring framework for community-based addictions and mental health services uses diagnosis, or case-mix groupings based on diagnosis, as a way of describing the recipients of service.
  
  
  • This approach may be adequate for monitoring services at a high level, it does not yield data that is robust enough to support program redesign and drive quality assurance/quality improvement activities.
  • The method does not provide a basis for direct assessment of outcomes in terms of change in clinical status from a baseline.

What is required is a method for describing clients in functional terms, and a case-mix grouping scheme based on functional descriptions. This will supply a performance monitoring framework with the data necessary to conduct outcome-based program evaluation and adapt service structures and processes to assessed client needs.

Applied Research Implications

• Utilization measures - the Clinical Context Descriptors Schema defines qualitatively meaningful units of clinical activity in a way that is designed to 'unitize' the ongoing stream of community-based service and apply resource intensity weightings to the units. The objective is to create a basis for measuring service utilization that is meaningful within the context of community-based care for mental health & addictions clients.
• Client descriptors, case mix groupings:
  
  
  • Structured service delivery settings - in settings where there are well-established structures for client assessment, and where staff have extended contact with clients, tools such as the RAI assessment instruments may be utilized to provide the client descriptions in a performance monitoring framework. The RAI tools, in particular, provide a mature and tested approach to functional assessment of clients and case mix grouping based on functional assessment data.
  • Community-based service delivery settings - where data collection is incident driven, where client contact is sporadic, and where clients do not have a stable relationship with a provider, structured assessment tools such as the RAI are not workable. Within the framework of the ICMHIS system, what is required is an extension of the clinical methodologies to provide more complete coverage of the clinical issues that need to be reflected in a functional client assessment.
  • The big challenge will be to bring together indicators derived from structured methodologies such as the RAI tools with indicators derived from ad hoc methodologies.

Recommended Next Steps

• Client descriptors, case mix groupings - augment the clinical methodologies incorporated in the ICMHIS system, using the RAI assessment tools as a reference point. The target is a method for assessing clients in the community that will provide data comparable to what is supplied by the RAI assessment tools. The use of the RAI tools as a standard becomes particularly important in Health Authorities that are adopting those tools within more structured systems of care.
• Utilization measures -
  
  
  • Review and revise the CCDS framework in relationship to the task of generating meaningful measures of service utilization.
  • Pilot implementation of CCDS functionality within the ICMHIS system.
• Validation - case mix groupings based on functional assessments of clients should be relatively homogeneous with respect to level of service utilization. Therefore, case mix groupings based on functional assessments will receive criterion validation to the extent that they account for a significant portion of the variance in service utilization, as measured by a CCDS-based utilization scheme (depicted by paired arrows in Appendix IIIa). If a case mix grouping schema based on functional assessment accounts for a significantly larger portion of the variance in utilization than a case mix grouping based on diagnosis, this will further support the argument for functional assessment as the foundation for measures of client characteristics in an accountability performance monitoring framework.

Major Finding #5 - Foundation for Research on Downtown Core Populations

When some of the most severely impaired and complexly concurrently disordered individuals 'fall through the cracks' (or actively distance themselves from mainstream services, as is often the case) they find themselves embedded within a system of care in which emergency shelters figure centrally as a source of primary support and access/ linkage to a range of other services. The ICMHIS system is currently deployed in two of the major adult shelters in Victoria, with plans to deploy in the addictions outreach service immediately upon completion of the CHIPP-funded phase of the project. Information collected on clients within the shelters and a set of closely allied health and social services within the downtown core holds out the potential as an important data source on a difficult to treat population.

Policy Implications - public policy decisions in the area of health and social services have an impact that is felt within the downtown core sector. The ICMHIS system will provide an ongoing stream of data, and it holds out the potential both as a source of information to guide public policy decisions and as an ongoing source of information about the impacts of policy.

Applied Research Implications:
A host of research questions may be addressed using data derived from the ICMHIS system:

• Epidemiological research - direct population health measures are difficult to obtain for a concurrently disordered population that may not access services where they would be counted.
  
  
  • Strategic expansion of the ICMHIS system within select sites in the downtown core may effectively address sampling problems and yield better estimates of numbers;
  • Risk-indexed population health counts - The clinical methodologies built into the tool are intended, among other things, to enable the generation of risk-indexed counts as part of an effort to profile the target population for mental health & addictions services.
• Health service systems outcome research
  
  
  • Risk-adjusted population outcome measurement - the ICMHIS system provides a basis for assessing systems outcomes using risk-adjusted measures
  • Sampling - the ICMHIS system is envisioned as a basis for extending health systems outcome evaluation methodologies into a sector that is not well-measured, particularly by systems that derive their data principally from acute care services
  • Longitudinal data - if the ICMHIS becomes a stable part of service delivery within the downtown core, it will supply longitudinal data that can address a variety of important questions. For example, by deploying the ICMHIS system in downtown core services to youth and adolescents, as well as adults, it becomes possible to track high risk populations of adolescents and evaluate the impact of programs and services for that population after they have crossed over into the adult service sector.

Recommendations for Next Steps

• Enhancements to the ICMHIS system - clinical methodologies, reporting methodologies, implementation of the Clinical Context Descriptors Schema
• Expanded deployment of the ICMHIS to healthcare providers in the downtown core (e.g., Community Health Centre)
• Partnership with University of Victoria researchers

The Future

Support for maintaining and developing the ICMHIS system arises out of three major initiatives within the Vancouver Island Health Authority Mental Health & Addictions Service.

Needs Based Service Delivery Initiative

The Needs-Based Service Delivery Initiative (NBSD) within the VIHA Mental Health and Addictions Program centres around the development and implementation of a set of clinical assessment tools across the continuum of services, extending across the Health Authority and crossing over into the non-profit/ contract service sector (residential care; downtown core service providers). This initiative provides the framework for:

• Expanded deployment of the ICMHIS system, including development and implementation of the Clinical Context Descriptors Schema
• Further development of the clinical methodologies built into the ICMHIS system and deployment of those tools across the continuum of care within Mental Health & Addictions. This enhanced tool set will provide an integrated deployment framework for the BC Ministry of Health Minimum Reporting Requirements for Mental Health, and the Addictions Information Management System reporting requirement for addictions services.
• Deployment of structured RAI assessment tools within a range of services delivered by the Health Authority.

The NBSD initiative represents the means whereby the Mental Health & Addictions program will uphold its part in a larger initiative involving the coordinated implementation of RAI assessment tools across the Mental Health & Addictions, Seniors, and Community Health Services within VIHA. As such, the NBSD has received a high level of support within VIHA, and the above-mentioned enhancements are covered within the budget for the NBSD initiative.

Downtown Health Coalition

Downtown Health Coalition - the VIHA Mental Health & Addictions Services has entered into a partnership with a collection of partners to form a more effective network of care for downtown core residents. Services/ providers slated for inclusion within this coalition include:

• Emergency Shelters
• Community Health Clinic
• Street Nurses [public health nurses]
• Downtown Housing Outreach Workers
• Medical Detox
• Sobering Assessment Centre
• Links to VIHA Case Management Services

The ICMHIS system is the principle contender for a system to translate a consensus among leaders in health care, city government and police into an operational network of service partnerships 'on the ground'.

The strategy would involve the use of the ICMHIS network as a means for linking together service providers, and the clinical tools contained within ICMHIS as an important part of the clinical vocabulary used to communicate information. Perhaps the most important contribution ICMHIS can make to this effort is its privacy/security framework (EDSA), which can support the privacy protocols that will need to be implemented to address the many client and provider sensitivities around the exchange of information within the Downtown Health Coalition. ICMHIS also provides a common clinical vocabulary, as well as a standardized method for assessing acuity/risk characteristics of a crisis-prone population. As such, it is envisioned as an important piece of infrastructure to support coordination and continuity of care.

At the same time, it should be noted that no amount of information systems privacy infrastructure can take the place for acceptable practice around consent and information sharing. It is recognized that alterations in some aspects of business process will be required to create the basis for effective information sharing - and for effective coordination of care.

Partnership With the University of Vicotira

Centre for Addictions Research of British Columbia at the University of Victoria - The VIHA Mental Health & Addictions Services has entered into a dialogue with the Centre for Addictions Research at the University of Victoria to explore the possibilities of a major research collaboration. The ICMHIS system holds out promise as an ongoing source of data for a sustainable program of research.

Health Information Science Program - The ICMHIS project has given rise to several innovations, including the EDSA privacy framework, the creation of clinical vocabularies to support the provision of care within the community, and an initial specification for the Clinical Context Descriptors Schema. Each of these features of the project represents a potential point of research partnership with the Health Information Science Program at the University of Victoria. With a version of the system in production, incorporating all of the major pieces of functionality inherent in the design, the ICMHIS project is now in a position to enter into a dialogue with the Health Information Science program around further development of the system.

Clinical Context Descriptors Schema

The Clinical Context Descriptors Schema is regarded by the ICMHIS development team as an integrated strategy addressing an array of challenges encountered in the project, including:

• A method for structuring the collection of information in settings where information collection is event-driven rather than program-structure driven;
• A method for ensuring privacy standards at the point of data collection;
• A method for addressing logistical challenges around limited data sharing within a consent-based privacy framework;
• A method for aggregating and organizing clinical information into larger, clinically meaningful units, to support the construction of an electronic health summary;
• A method for identifying relationships between baseline data collected in one setting and outcome data collected in another, i.e., a strategy for addressing issues in outcome measurement when care is accessed across a range of services;
• A method for specifying and weighting units of activity for within the context of an accountability/ performance monitoring framework.

In a sense, the CCDS encapsulates the learning that has taken place over the course of the ICMHIS project, and it represents a strategy for an evolutionary advance in the functionality provided by the ICMHIS system, without requiring any alteration in the base architecture. It is viewed by the development team as a means for addressing some of the deeper problems that are encountered in efforts to implement information systems into the community service sector for mental health and addictions clients. As such, it is seen as a potentially important contributor to efforts currently under way to develop the pan-Canadian electronic health record. Potential funding sources will be explored to support the development and implementation of this schema in a way that coordinates with those efforts.

Communications

The ICMHIS system was constructed with cutting edge technology that was sufficiently unfamiliar to other developers that concerns were expressed by some over the viability of the approach. Though a series of technology reviews by an outside consultant affirmed the soundness of the design strategy, it was felt that a circumspect approach to communications about the technology was in order, until the system was put into production in a working environment. Pressure to complete the system, including documentation and evaluation effectively precluded any major piece of communication about the project.

There have been some limited communications about the strategy and design of the clinical minimum data set incorporated into the ICMHIS design. A presentation in the Case Mix 2001 Conference in Toronto laid out some of the thinking behind the development of the minimum data set that was eventually implemented in the ICMHIS system (Moselle, K. & McNeil, M. Design Parameters for the Development of Community Extensions of RAI-Mental Health: Capital Health Region (British Columbia) Perspective, Toronto, October 2001). Note, however, that the thinking in that document does not reflect some of the critical issues that came up in the design of the minimum data set for the ICMHIS system, most notably the incorporation of ad hoc and structured methods for registering information, and the development of a reporting methodology that could handle both types of information.

There have been other presentations within the VIHA Mental Health & Addictions Program, and the BC Ministry for Children & Family Development has seen several demonstrations of the system. With a working version of the system, and a final technical review by an outside consultant confirming the success of the design and build of the system, the ICMHIS initiative is now in a position to share its success with a wider audience.

Appendix I - Clinically Complex Use Case/Training Scenario

Integrated Community Mental Health Information Systems (ICMHIS)
User Training Plan

Clinically Complex Use Case/Training Scenario:
Concurrent Disorder (Mental Health, Medical,
Behavioural & Drug Use Concerns):
The Case of 'Vanessa'
Version 1.0

Contact: Kenneth A. Moselle, Ph. D., R. Psych.
Victoria Mental Health
2328 Trent St. Victoria, BC V8Y 2K1
tel: (250) 812-3925 * e-mail: kmoselle@caphealth.org

The following case is fictional. It depicts the case of a downtown core resident facing a host of challenges related to mental health, drug use, behavioural risk, and the downtown core environment. In providing service for this person in the Shelter, heavy use is made of the functionality of the ICMHIS system, both as a tool for supporting the management of beds within a shelter environment, and as a tool for supporting the assessment, documentation and management of clinically very complex high-risk issues.

Key features: major mental health issues; drug use; major personal and public health issues; the downtown core environment; assessment and management of risk; emergency response; multiple service providers( mental health, public health, downtown core services, police, hospital ER, inpatient care, nursing, allied health professionals).

The Case of Vanessa/' Jane'

Day 1
A woman comes to the Shelter requesting a bed. She gives a name 'Jane Smith' and provides a DOB of January 1, 1976. She is almost 6' tall, very thin, red hair, and has prominent piercings but no tattoos. Staff suspect that "Jane" is not her real name, though the birthdate or at least the birth year may be accurate. She has not stayed in the Shelter before. Staff note that she seems tense and edgy. She is quite energized, and has the kind of intrusive presence that could create conflict. She also seems to be quite internally preoccupied. The staff suspect that her stay in the Shelter could become complicated, but are also concerned that she could create real problems for herself out on the street. They perceive her as vulnerable and place her on the waiting list with the highest priority.
[data entry]

Jane returns by 8:30 and confirms her intention to stay a full 7 days in the shelter. She stays the night, gets very little sleep, and goes out the next morning.
[data entry]

Day 2
Jane returns by lunch time, eating almost nothing. She hangs around the Shelter that afternoon, and on several occasions is seen by staff talking to herself. At times she seems very internally preoccupied; when she is focused outwardly, she becomes more edgy, at times aggressive, shouting at other residents on several occasions. She does not seem to have any particular focus for her outbursts - they could arise with any resident. This is a concern for staff as they believe she is likely to provoke assaultive behaviour from others.
[data entry]

Late afternoon -A new staff person comes on duty who immediately picks up on Jane's unusual behaviour. She engages with Jane, who acknowledges that she has a history of IV amphetamine use, sometimes heroin, admits that she was using amphetamine "a few days ago" and admits that she was evicted from her apartment because of her behaviour and that of her roommates and friends. She also remarks that this is not the first time that has happened. She denies any use of amphetamine in the past two days but does say that she is still feeling kind of confused. The staff person notes that, in fact, Jane is still very confused, and there are numerous times when the staff person cannot really understand what Jane is saying. The staff person also notes that there are times in the middle of the conversation when she seems to be distracted, as if someone had just spoken to her, even though there is nobody else around. In these moments, she becomes quite internally preoccupied, mumbles several statements that cannot be understood, and then focused back on the staff person. The staff person is also aware that Jane is very thin, her complexion is grey, and she appears malnourished.
[data entry]

That evening Jane confirms her bed for the night. She spends another fitful night.

Day 3
Jane goes out the next morning and returns to the shelter at lunchtime. She does not have anything to eat, seems to be quite energized, again is very edgy, and is behaving in a sexually provocative manner. Other times that afternoon she again becomes embroiled in angry verbal exchanges with other residents. She seems to be going from one high-risk interaction to the next.
[data entry]

Day 4
The next morning Jane goes out. She returns at 3: 30 to register herself for the night. Staff note that her speech is quite pressured, she seems to be jumping around from one thought to another in a manner that is quite difficult to track. Her mood seems to be unusually elevated, though it can change rapidly. Again, she lapses abruptly into states of intense internal preoccupation, mumbling to herself and seems almost to be having a conversation with someone who is not physically present. Staff are of the impression that she cannot be maintained in the Shelter for much longer, and doubt that the collective resources in the community will be able to help her stabilize and remain out of hospital. Recognizing that it may become important to facilitate and emergency response leading to hospitalization, they make an effort to ensure that they record relevant observations about her behaviour.
[data entry]

In the midst of all of this, the Street Nurse contacts the shelter. She reports that she is looking for a woman named Vanessa. A search in the system reveals nobody by that name. However, the Street Nurse knows that Vanessa has been evicted and suspects that Vanessa may be in the shelter. She provides the Shelter staff with a physical description: quite tall, quite slim, prominent piercings, red hair. Staff in the Shelter find a match with a physical description for Jane. Without going into details, the Street Nurse informs Shelter staff that it is quite important that she see the person in the Shelter who has registered under the name of 'Jane' and speak to the staff about her.
[data entry]

The Street Nurse comes over to the Shelter. She provides the following pieces of information: 1) Vanessa, aka 'Jane', is a recent arrival in Victoria from Vancouver, where she has a history of numerous hospitalizations for schizophrenia dating back to age 17; the Street Nurse reports that there was one instance of a full police emergency response team extraction from an apartment when Jane had threatened to shoot anyone who came through the door; in fact she did not have a gun; 2) Jane is intermittently involved in the IV use of amphetamine (heavily involved when she is using), and at times uses heroin or cocaine; 3) Jane is HIV+. The main reason why the Street Nurse was looking for Jane is that the Street Nurses have been providing her with her HIV meds on a daily basis; without Street Nurse involvement she will not take her meds, and the health consequences of not doing so are grave; 4) great care must be exercised as Jane is careless with her syringes, and there was one instance in which she became embroiled in conflict with a roommate and threatened her with a dirty needle; 5) Jane refuses anti-psychotic medications and is not currently in the care of any physician or psychiatrist. The Street Nurse is the only care provider regularly involved with her.
[data entry]

The Shelter staff locate Jane and ask her if she will speak with the Street Nurse. Jane consents, but becomes very angry at the when the Nurse offers her HIV meds. Jane launches into a brief, angry tirade, quickly reaching the point where the Street Nurse must back off from the interaction. Jane does not get her medications.

Jane spends that night in the Shelter.

Day 5
Jane goes out in the morning and comes back around lunch time. She eats a very small amount, and is conspicuously less energetic than in previous days. Though less energized than before, staff note that she is very intensely preoccupied with something going on inside, and when she speaks her language is confusing and her ideas are somewhat bizarre, with a distinctly paranoid flavour. She cannot stay out of trouble with the other residents. However, the staff are very reluctant to send her out of the shelter because they do not expect she will manage for very long on the street before provoking some sort of serious conflict. That is, they see her as a major risk to herself and to others.
[data entry]

Jane confirms her bed for the night. A bit later, staff notice a jacket that has been left behind in the dining room. They recognize it as Jane's, and notice that there is something in one of the pockets. They remove it to the back room, put on gloves, examine its pockets and pull out a dozen used syringes, most of which are uncapped. They are concerned that they may be forced to ban her from the Shelter, but Jane saves them from having to make a decision: staff hear a screaming argument taking place in front of the nursing desk. Jane is 'in the face' of quite a large man, accusing him of stealing her jacket, and it appears that she may attack him. One staff member talks her down while another calls police and the Emergency Mental Health Service.
[data entry]

The Shelter staff person meets with police and EMHS and provides a verbal report on Jane's behaviour in the shelter over the course of the past several days. Jane, however, has changed her behaviour with the arrival of the police. She is not saying much, and attributes her outbursts to the behaviour of other residents. She admits to recent use of amphetamine but denies that she is using currently and says that she plans to see a doctor in the Community Health Centre. The Shelter staff person completes those portions of the MDS: MHT for which she has information. She prints off a Client Health Detail Report for EMHS, which includes the results of the MDS: MHT assessment, along with a listing of various activities and observations contained in the Shelter-accessible portion of the ICMHIS system.
[data entry]

EMHS does not provide a copy of this report to the police. However, they provide the police with the following summary impressions, based on all of the information they have been provided: 1) Jane has an established diagnosis of a major psychiatric illness, and associated with that is a history of dangerous behaviour, including the full police emergency response team extraction in Vancouver; 2) Jane is HIV+ and appropriate cautions must be exercised in dealing with her; 3) Jane has been displaying a consistent pattern of behaviour since her arrival at the shelter suggesting that her mental status is quite severely impaired, she poses a high risk to herself (via provoked assault) and others, and there is every reason to believe that her status will not improve, nor will any of the major risks be reduced, until she receives psychiatric care in a very tightly monitored environment. The fact that she is relatively composed presently does not negate five day's worth of observation of her behaviour. Based on the EMHS recommendations, police invoke Sec. 28 of the BC Mental Health AC and transport Jane to hospital

As part of their assessment of Jane, the EMHS clinician does her ratings of Jane on the MDS: MHT tool. These are substantially in agreement with the ratings completed in the Shelter.

Jane arrives in the Emergency Room. There has been a recent 4-car motor vehicle accident and the ER is backed up. Jane waits for several hours to see an Emergency Room Physician. During that period of time, she composes herself. When she sees the Emergency Room Physician, she acknowledges that she had become involved in conflicts with several residents at Street Link but attributes that to the behaviour of the other residents. She acknowledges that she had been using amphetamine intravenously for several days before coming into Shelter and explains that this is the reason for some of the "unusual" behaviour observed by the staff in the Shelter. She denies any intention of harming herself or anyone else, denies any feelings of fearfulness or persecution, and says that she will be happy to follow up the next day and see a physician at the downtown Health Clinic.

The psychiatric beds are full in the hospital and going ahead with an admission will be very difficult for the staff in the Emergency Department, where Jane will have to remain until a bed becomes available. However, Jane is not able to 'silence' whatever internal distractions seem to capture her attention so frequently. Several times in the conversation with the Emergency Room Physician she halts the conversation quite abruptly, and begins muttering in response to what the Emergency Room Physician believes are auditory hallucinations. The EMHS clinician has supplied the Physician with a copy of the Shelter Client Detail Summary, which lays out very clearly a continuous series of behaviour observations, all pointing to an active psychotic illness associated with a high degree of risk to self (passive, in the sense that she is a strong candidate for provoked assault in the environment in which she lives) and also a significant danger to others. The results of MDS: MHT paint a clear picture of a person who poses a high risk, is unlikely to access any required treatment/ support voluntarily, and makes it more or less impossible for community service providers to support her and reduce the risk she poses to herself and others. Based on his observations in the ER the collateral information provided by the Shelter Client Detail Summary, and the EMHS assessment, the ERP admits Jane to hospital.

Day 6
The day after she is admitted, the Street Nurse comes by the Shelter looking for Jane. She has two reasons why she needs to see Jane. The first is to provide her with her HIV meds. The second is to arrange testing for TB, the reason being that Jane's roommate for several weeks prior to her last eviction has been diagnosed with TB.

The Shelter staff report that Jane is no longer in the shelter. They note that the last entry in the ICMHIS system for Jane is a Client Health Detail Report printed off for EMHS the previous day. The Street Nurse contacts EMHS and explains why she needs to locate Jane. EMHS reports that she is currently an inpatient in the local psychiatric facility. The Street Nurse contacts the unit where she is staying and arranges for the necessary testing.

Day 7
The test results come back positive for TB. The Street Nurse contacts the Shelter and reports the results of the tests. She asks for a listing of all of the people with whom Jane might have had any substantial contact while she was in the Shelter. The staff person first looks up Jane's record to determine when she was in the shelter. He then runs a Bed Registration Range Report to find out who might have had any substantial amount of contact with Jane in the course of her stay in the shelter. Two of the likely candidates are still in the Shelter. The third is no longer in the Shelter. However, this client's record lists the name of a case manager. This case manager is contact and provides the Street Nurse with this person's current location.
[data entry]

After17 days in hospital, Jane is discharged and assigned a Case Manager in the Schizophrenia Service. An apartment is found for her where she takes up residence. After two weeks she begins using amphetamine again, and within a few weeks is evicted. She does not contact her case manager but does show up at the Shelter. She gets her name put on the waiting list. Sometime during that afternoon she is talking with one of the Shelter staff, and she mentions that she has a case manager. When asked, she provides the name of the case manager to the Shelter staff person.

Based on her behaviour, staff in the Shelter are concerned that Jane has gone off her meds and may be using amphetamine again. With Jane's permission then contact the case manager and let him know that Jane is in the Shelter. They also contact the street nurse to let her know Jane's location.
[data entry]

Appendix II - ICMHIS Clinical Data Elements

Appendix IIa ICMHIS - Clinical Data Elements

Structured Triage-Oriented Assessment of Acuity/Risk: Item Listing

Danger to Others

Described in terms of: RISK (probability of aggressive/ assaultive behaviour); SELF-CONTROL (client's capacity to control psychological forces that impel him/ her to behave in an aggressive/ assaultive manner); STABILITY (likelihood that currently assessed risk level vis a vis Danger to Others will remain at the same level or lower; low stability = significant probability of increased risk).

Active Danger to Self

Described in terms of: RISK (probability of intentional self-injury or suicide); SELF-CONTROL (client's capacity to control psychological forces that impel him/ her towards self-injury or suicide); STABILITY (likelihood that currently assessed risk level vis a vis Danger to Self will remain at the same level or lower; low stability = significant probability of increased risk to self).

Passive Danger to Self/ Others (Grave Disability) Resulting From Impaired Capacity to Manage Food/ Shelter/ Clothing

Described in terms of: RISK TO SELF/ OTHERS (extent to which capacity to manage basic food/ shelter/ clothing requirements creates personal and/ or public health risks); STABILITY (likelihood that capacity to manage food/ shelter/ clothing will deteriorate, or likelihood that health status will deteriorate as a result of self-neglect); SUPPORT REQUIREMENTS (level of external monitoring, structure, intervention required to reduce to a manageable level the risks associated with impaired capacity to manage basic food/ shelter/ clothing requirements).

Mental Status Impairment

Described in terms of: DISABILITY, RISK (extent to which impaired mental status creates active danger to self/others or passive danger as a consequence of impaired capacity to manage basic needs - food, shelter, clothing); SELF-MANAGEMENT (client's capacity to exercise control and limit any potential risks to self or others arising from impaired mental status); STABILITY (likelihood that mental status will NOT deteriorate to the point that risk to self or others increases; low stability = significant probability of increased risk to self or others).

Substance Use - Impact on Mental Status/ Behaviour/ Capacity to Manage Food/ Shelter/ Clothing

Described in terms of: RISK (probability of adverse outcome associated with current levels of substance misuse and/ or with behaviours involved in acquiring substances); SELF-MANAGEMENT (capacity to control substance misuse to the point that risks are controlled); TIME-COURSE (time interval within which adverse impacts of substance misuse are likely to manifest).

Insight, Judgment

Described in terms of: Extent to which impaired mental status (disordered/ delusional thinking, hallucinations and/ or marked disturbance of mood) creates risk, or impairs functioning or produces non-compliance with support/ treatment; extent to which insight, judgment enable person to reduce those risks.

Medication Compliance

Described in terms of: LEVEL OF RESISTANCE (how actively a persons resists taking medications necessary to maintain client at baseline); STRUCTURE REQUIRED (level of external structure necessary to ensure compliance -ranging from complete to none); CONTROL REQUIREMENTS (level of external control necessary to ensure compliance -ranging from intrusive physical control to none).

Willing and Able to Participate in Treatment Voluntarily (at time of Incident or Encounter)

Described in terms of: LEVEL OF RESISTANCE (how actively, aggressively does person resist necessary treatment); CAPACITY FOR SELF-CONTROL (how capable is the person of controlling his/ her behaviour and accommodating to the behavioural expectations within treatment setting for the duration of the encounter); STABILITY (how likely is it that actively or aggressively non-compliant behaviour will persist without intervention; how long is client likely to maintain adaptive response to behavioural expectations within treatment setting for the duration of the encounter).

Top of Page

Level of Supervision, Control Required

Described in terms of need for: CONTROL, STRUCTURE REQUIREMENTS (level of direct intervention required to ensure safety and adequate compliance with treatment); REASSESSMENT OF STATUS (how frequently client's status needs to be re-evaluated); SUPERVISION/ SEPARATION REQUIREMENTS: (Supervision: level of monitoring required to minimize risk and ensure adequate compliance with care; SEPARATION: need for containment and physical separation from other people or from usual environment). Hazardous Local Social Environment Described in terms of: SOCIAL RISKS (physical assault, theft, invasion of residence); NECESSARY SURVIVAL SKILLS (level of judgment and behavioural control necessary to avoid provoking a dangerous situation).

'Housability', Supportability in the Community - Impact of Social Behaviour

Described in terms of: IMPACT OF BEHAVIOUR ON SUPPORTS, CAREGIVERS (Extent to which the person's social behaviour makes it difficult or impossible for some combination of caregiver support and housing/ residential placement to reduce risks the client poses to self/ others and assist the client in maintaining stable placement in community); IMPACT OF BEHAVIOUR ON 'HOUSABILITY' (Extent to which the person's social behaviour makes it difficult for client to remain housed) Capacity, Effectiveness of Community-Based Supports Described in terms of: LEVEL OF SUPPORT (capacity of supports to manage, reduce risks); MONITORING (likelihood that external supports will become aware of any significant deterioration in mental status/ behavioural control in time to take action to reduce risks).

History as Qualifier/ Modifier of Apparent Risk

Described in terms of: Extent to which the client's history adds/detracts from assessed level of risk suggested by immediate presentation of client.

Collateral as Qualifier/Modifier of Apparent Risk

Described in terms of: extent to which information from collaterals adds/ detracts from assessed level of risk suggested by immediate presentation of client/ patient.

Response to Treatment - Historical

Described in terms of: EFFECTIVENESS (how effective is treatment in reducing the UNDERLYING CAUSES of risk/ functional impairment); DURABILITY OF GAINS (how long are any treatment gains preserved WITHOUT DAILY INTERVENTION); STRUCTURE REQUIRED TO PRESERVE GAINS (level of structure, care required to preserve gains). The issue here is how effectively does treatment address the CAUSES of risk/ disturbed functioning/ impairment, NOT the capacity of treatment settings to reduce risk directly by providing structure and control of behaviour.

Reliability of Client Self-Report

Described in terms of: APPARENT INTENTION TO MASK CONCERNS (extent to which client's apparent intention is to minimize risks or downplay the extent of his/ her disturbed/ disordered thinking or behaviour); SKILL IN MASKING CONCERNS: (client's capacity to present him/ herself in a manner that would result in an underestimation of risk or functional impairment). The issue for this item is MINIMIZATION of functional impairment/ risk, not exaggeration.

For further information, contact: Kenneth A. Moselle, Ph. D., R. Psych.
Vancouver Island Health Authority
tel: (250) 812-3925 * e-mail: kmoselle@caphealth.org

Appendix IIb ICMHIS - Clinical Data Elements

Structured Triage-Oriented Assessment of Acuity/ Risk: Sample Item with Operationalizations of Scale Points

Danger to others

Described in terms of: RISK (probability of aggressive/ assaultive behaviour); SELF-CONTROL (client's capacity to control psychological forces that impel him/ her to behave in an aggressive/ assaultive manner); STABILITY (likelihood that currently assessed risk level vis a vis Danger to Others will remain at the same level or lower; low stability = significant probability of increased risk).

Appendix IIc Icmhis - Clinical Data Elements

Ad Hoc Observations

• Income Observation - employment status, disability status
• Reported Medical Condition - including information about information source, treatment status, treating physician, recent hospitalizations, text box for additional information
• Physical Observation - for example:
  
  
  • Appears Undernourished
  • Signs of Infection
• Medications - including name of medication, dosage, frequency, prescribing physician, date acquired/ released (for medications held for safekeeping)
• Street Drug Use Observation - including information about type of drug, method of use, frequency of use, intensity of use, source of information, text box for additional information
• Reported Psychiatric Condition - including information about information source, treatment status, treating physician, recent emergency room visits, recent psychiatric hospitalizations, text box for additional information
• Behaviour Observation - for example:
  
  
  • Verbally Aggressive/Threatening Behaviour (with qualifiers: Targeted toward person(s)/Targeted, with sexual content/Untargeted);
  • Risk to Self (with qualifiers: Self harm, e.g., Cutting self/Drug taking behaviour/Likely to provoke physical violence/ Likely to provoke sexual assault/Very poor social judgment
  • Bizarre or Unusual Behaviour (with qualifiers: bizarre or confusing thinking, language paranoid thinking/ bizarre postures or movements/ responding to things or people that aren't there/ responding to voices that aren't there)
• Client Incident Report - including information about the problem behaviour (e.g., staff assault; using drugs in the shelter), involved parties, injuries, recommendations, and attachments (documents, photographs)
• Client Ban from Shelter - including the reason for the ban, the duration, and conditions that must be met for the ban to be lifted.
• Relations - persons, organizations involved in providing service to client

Appendix IId Icmhis - Clinical Data Elements

BC Ministry of Health Minimum Reporting Requirements

(see Ministry of Health, British Columbia, Mental Health Ambulatory Minimum Reporting Requirements: Data Requirements and Rationale, November 29, 2002 for further information)

• PHN
• Birth Date
• Gender
• Postal Code
• City
• Date Of First Contact
• MH Service Provider (Organization) -Location Code
• Employment Status
• Current Vocational Status
• Marital Status
• Residential Arrangement At Admission
• Referral Source
• (Referring Party Type)
• Referral Date
• Education Level
• Legal Status
• Household Composition
• Care Episode Agency
• MH Recipient Diagnosis (DSM-IV-TR) Axis 1 (Principal.)
• MH Recipient Diagnosis (DSM-IV-TR) Axis 1 (Secondary)
• MH Recipient Diagnosis (DSM-IV-TR) Axis 2
• MH Recipient Diagnosis (DSM-IV-TR) Axis 4
• MH Recipient Diagnosis (DSM-IV-TR) Axis 5 GAF Score At Admission
• Care Episode Service Event
• Date Of Service Event
• MH Recipient Diagnosis (DSM-IV-TR) Axis 5 GAF Score At Discharge
• Residential Arrangement At Discharge
• Referral Target
• Discontinuation Reason Type
• Date Of Discontinuation
• Aboriginal Origin