Electronic medical record implementation for a healthcare system caring for homeless people

Abstract

Objective

Electronic medical record (EMR) implementation at centers caring for homeless people is constrained by limited resources and the increased disease burden of the patient population. Few informatics articles address this issue. This report describes Boston Health Care for the Homeless Program’s migration to new EMR software without loss of unique care elements and processes.

Materials and methods

Workflows for clinical and operational functions were analyzed and modeled, focusing particularly on resource constraints and comorbidities. Workflows were optimized, standardized, and validated before go-live by user groups who provided design input. Software tools were configured to support optimized workflows. Customization was minimal. Training used the optimized configuration in a live training environment allowing users to learn and use the software before go-live.

Results

Implementation was rapidly accomplished over 6 months. Productivity was reduced at most minimally over the initial 3 months. During the first full year, quality indicator levels were maintained. Keys to success were completing before go-live workflow analysis, workflow mapping, building of documentation templates, creation of screen shot guides, role-based phased training, and standardization of processes. Change management strategies were valuable. The early availability of a configured training environment was essential. With this methodology, the software tools were chosen and workflows optimized that addressed the challenges unique to caring for homeless people.

Conclusions

Successful implementation of an EMR to care for homeless people was achieved through detailed workflow analysis, optimizing and standardizing workflows, configuring software, and initiating training all well before go-live. This approach was particularly suitable for a homeless population.

INTRODUCTION

Implementation of electronic medical records (EMRs) is a transformative and often disruptive process affecting all aspects of a healthcare organization. The implementation process impacts leadership, operations, finance, clinical, and information technology (IT) staff and systems.^1–4 A number of reports outline the approaches and impact of medical IT on Health Care organizations, healthcare delivery, and outcomes.^5–15 The impact is behavioral as well as technical, often requiring change management strategies to achieve successful outcomes.^16–20 For underserved and safety net populations such as community health centers, the implementation process faces additional hurdles of limited resources, and access despite established benefits.^21–26 Homeless populations pose even more unique challenges and barriers to healthcare delivery.^27–29 Few reports in the informatics literature detail the challenges and approaches to IT implementation in centers serving homeless people. Those published detail the approaches rather than successful projects.^30,31 The only identified software developed solely for a homeless population was created in the 1990’s by the Laboratory of Computer Science at the Massachusetts General Hospital and implemented in 1996 for Boston Health Care for the Homeless Program (BHCHP).^32,33

BHCHP, currently a Federally Qualified Community Health Center, was founded in 1985 through collaboration of the City of Boston and State of Massachusetts to provide patient-centered prevention, treatment, and continuity of care exclusively to the Boston homeless population. The program, its principles, its essential services along with a detailed analysis of the issue of homelessness was described in 2010 at which time BHCHP was deemed the largest and most comprehensive freestanding healthcare for the homeless program.³⁴ BHCHP has described the demographics of this population, outcomes of care, and a strategy for providing structured healthcare delivery.^35–37 Encounter data from 2010 document a comorbid disease burden that markedly exceeds that of the general Medicaid population.³⁸ BHCHP conducts clinics at more than 45 locations in greater Boston providing comprehensive integrated medical, dental, behavioral health, and addiction services. More than 10 000 patients receive care per year. The great majority of patient encounters are walk-ins rather than scheduled visits. BHCHP’s relationships include the major teaching hospitals and medical schools of the Boston area, a wide range of shelter and non-profit partners, city, state, and federal agencies and an extended number of educational agencies and institutions. Services include a total of 124 medical respite beds in two 24-h care facilities that provide acute, sub-acute, rehabilitative, recuperative, and palliative care for those who do not need costly hospital care and are at great risk on the streets and in the shelters.^39,40 Based on 2017 data, 84% of patients have insurance coverage: 69% Medicaid, 15% Medicare, and 10% dual coverage. Of the 16% uninsured, enrollment assistance in MassHealth, the state Medicaid program, was provided unless individuals were ineligible for Medicaid for reasons such as citizenship, residency, or income.

In 2015, BHCHP decided to migrate their EMR to Epic. The implementation was managed through an intermediary vendor, OCHIN (formerly Oregon Community Health Information Network), a collaborative offering shared use of Epic by multiple healthcare safety net organizations under agreement with the software vendor.^41–43 The advantage of this migration was to enhance EMR function and allow interoperative communication with area EMR Epic installations at Boston Medical Center, Massachusetts General Hospital, Brigham and Women’s Hospital, and members of the Boston HealthNet, an association of local community health centers. The concern in undertaking this project was that the new software would prevent BHCHP from maintaining the goals and services described as its foundation.³⁴ The objective of this report is to describe the implementation strategies and methodology utilized and validate the effectiveness of the processes chosen.

METHODS

Key elements of the project were the governance structure, workflow analysis, workflow mapping, development of documentation tools, training strategies, customization of selected EMR functions, and support of respite care. A physician informatics consultant, experienced in Epic implementation from clinical and operational perspectives, was a member of the team. Department areas central to care of a homeless population required in depth focus because of unique psychosocial and disease management patient care needs. These included HIV, addiction, hepatitis C, transgender medicine, sexually transmitted disease, behavioral health, and case management.

The decentralized care delivery model of BHCHP required further consideration in order that practice management and clinical services be available at each site and that primary care be integrated with specialty care. Staff members performing both clinical and practice management functions needed cross training and complex security access designations. The OCHIN Epic team’s familiarity with Epic implementation in community health centers was considerably beneficial. OCHIN’s technical staff was able to perform a limited transfer of legacy demographic and clinical data to the new system. Critical to the project throughout was the availability at the onset of the project of an online live training environment implemented at another community health center of the Boston HealthNet which mirrored the Epic build and configuration to be used for BHCHP.

Network connections of multiple sites with varying resources was a challenge. Four strategies were used. The larger sites were connected over dedicated fixed connections either by direct local area network (LAN) to LAN connections or tunneled through a virtual private network (VPN). A VPN over a cellular network was used at some smaller sites where wired connectivity was not practicable. The VPN connections allowed for local printing via a central print server. Portable cellular hotspots allowed outreach staff registered computer connections but not printing. Last, any Internet-connected computer could access the OCHIN offsite portal through a Citrix client again without printing function.

The planning process engaged the health center staff early and frequently before go-live. The physician informatics consultant shadowed users at all levels in the performance of their department roles. Representative examples of documentation were collected and data element requirements identified related to patient population characteristics, health maintenance, disease management, quality indicators, and regulatory requirements. Department and specialty workflows were mapped using role-based cross-functional flowcharts which allowed visual sequencing of actions and their relationships. Documentation templates were designed to meet the needs identified in the workflows. Orders were configured to suit unique department and specialty needs and resources. The online live training environment was used to test, demonstrate, and validate these tools with users and departments. Staff engagement and feedback were used to gain ownership consensus and agreement on workflow standardization. Before go-live, again using the available training environment, screen shot guides were developed specific to workflows and documentation tools. These guides were integrated into training which then could reflect homeless care workflow rather than generic software function most commonly featured.

Software customization focused on 2 areas. The first consisted of enhanced data element documentation specific to homeless people and the second unique operational needs of respite care. Go-live was preceded by rehearsals using BHCHP scenarios and workflows which validated software configuration and allowed troubleshooting. Collection and analysis of outcomes data from legacy EMR software and Epic before and after go-live were performed using Azara Healthcare Data Reporting and Visualization System software which provides reporting and analytics targeted for the community health market place.

RESULTS

Governance and operations

The BHCHP governance group included administration, IT, clinical staff, and management staff. Key roles were Chief Executive Officer, Chief Financial Officer, Chief Operating Officer, Chief Information Officer, project manager, Chief Medical Officer, Medical Directors of primary and respite care, and Director of Clinical Operations/Director of Nursing. In parallel, the OCHIN project team headed by the OCHIN project manager and included operational and technical staff. OCHIN and BHCHP staff met locally or on line weekly. Table 1 lists the users by role or department. Of note, behavioral health and case management staff represented 13% of the clinical staff reflecting the high level of psychosocial support provided.

Table 1.

BHCHP users

Role	Number	(%)
Providers (MD, DO, NP, and PA)	184	21
Nursing staff	333	37
Behavioral health	45	5
Case management	74	8
Other clinicala	76	9
Practice management	152	17
Information technology	27	3
Total	891

BHCHP: Boston Health Care for the Homeless Program; NP: nurse practitioner; PA: physician assistant; MD: Doctor of Medicine, DO: Doctor of Osteopathy.

^aPharmacy, technicians, and dental.

The BHCHP governance group focused on the core areas of function and support: administration, IT, practice management (registration, scheduling, clerical staff), clinical care, billing, pharmacy, and medical records. Staff in return met as departments to discuss implementation at intervals throughout the process. For clinical staff, meetings specific to primary care and specialty care occurred as well, allowing care teams to discuss planning and impact. Duration of implementation from kick off to go-live was 6 months, an unusually aggressive time frame achieved through the chosen processes.

Workflows

For the clinical areas, workflow documentation, optimization, and standardization were essential. Workflow mapping was used to capture existing role-based functions. These workflows were then optimized for improved efficiency and efficacy to reflect how they would be used in the new software and how the tools in the new software might be used in response. The new workflows were adopted by care teams and departments by consensus. This approach both validated the change and achieved buy-in and a sense of ownership. Figure 1 displays a representative optimized role-based cross-functional workflow map of care common to BHCHP but unusual in more traditional healthcare systems. Shown is a provider working alone performing both clinical and practice management roles mandated by working at a decentralized outreach clinic site.

Figure 1.

Role-based workflow map, provider working alone. POCT: point of care testing; Dx: diagnosis; LOS: level of service; Rx: prescription; AVS: after visit summary.

Documentation templates

New documentation tools specific to homeless care were based on review of prior legacy EMR documentation templates, shadowing of providers, and departmental meeting review where tools were tested using clinical scenarios. New documentation tools included configured check lists, data links, imbedded questionnaires, flowsheets, and additional links critical to homeless care areas such as HIV, addiction, hepatitis C, transgender health, sexual transmitted disease, and behavioral health. Necessary for this work to succeed was the availability of the mentioned live training environment configured to the workflows that staff would be using. Figure 2 shows a representative template for integrated behavioral health documentation. This template was validated and collectively adopted by psychiatry, clinical psychology, and behavioral health therapists reflecting team based care delivery.

Figure 2.

Behavioral health-integrated core documentation.

Preference lists

As part of workflow analysis and standardization, preference lists for orders, and documentation tools were developed for department and specialty areas. Orders for most common elements were grouped intuitively and shared electronically to create order sets. Order types configured included medications, labs, imaging, referrals, supplies, and procedures. Grouping, considering user workflow, was based on disease condition, symptom, specialty, organ system, indication, or procedure in addition to order type. These preference lists were created and shared before go-live and available for training and rehearsals.

Training

Training posed a challenge due to the numerous decentralized care sites and crossover clinical and practice management functions of many staff. Training was a continuum using varying strategies throughout the implementation process. The first step was to enroll all users in an online environment supported by OCHIN which included video and documents organized by area of work and level of use. Critical to the next phase was the availability of the configured live training environment. For clinical staff, this environment allowed end users to visualize and simulate their workflow and documentation processes and create consensus on their standardized use. Trainers from OCHIN and Boston Medical Center provided classroom training in 2 phases during the 2 months prior to go-live. Super users, key representatives designated by their departments, received 3 days of training in all aspects of the program. End users received 8 h of training over the 3 weeks prior to go-live in their respective practice management and clinical areas. Super users attended these sessions allowing them to gain further facility with software while assisting the instructors. Due to the decentralized care provided by BHCHP at many sites, many clinical staff received additional practice management training which included crossover functions of registering and scheduling patients as well as providing care. Interwoven with these activities, training staff created numerous screenshot guides that provided stepwise visualization of optimized common and unique workflows. Links to these screen shot guides were posted on the BHCHP intranet home page. Over the days prior to go-live, multiple sites conducted dress rehearsals using the finished software build. At go-live, OCHIN, Boston Medical Center, and BHCHP staff provided “at elbow” support which was phased out over 3 weeks’ time. BHCHP training staff provided additional spot classroom sessions based on need.

Legacy data

Selected data was transferred from the legacy system to Epic. Included were 3 prior years of demographics, provider notes, histories, vital signs, immunizations, tobacco use, PHQ-9 scores, and cancer screening (mammography, colonoscopy, Pap smear, and stool occult blood). Problem list migration was limited by prior use of text entry which could not be mapped to ICD-10 code. Lab data from 3 previous years was uploaded from the vendor to whom most clinic orders had been sent. At go-live, medication lists from the electronic prescription vendor, common to both legacy software and Epic, appeared within each patient record for reconciliation. As well, on go-live, reconciliation prompts for medications and allergies appeared based on communication with other Epic sites provided by Epic software interoperability function.

Outcomes data

Selected process and outcomes data were collected and compared with pre go-live measures. Figure 3 shows control charts for 6 key quality metrics before and extending through the initial period of implementation. Each of the metrics remained within the control limits without significant deterioration occurring as a result of the EMR change.

Figure 3.

Quality assessment control charts before and after go-live. ^aGo-Live 9/2016; OUD: opioid use disorder; UCL: upper control limit; LCL: lower control limit; 3σ: three standard deviations.

Productivity was minimally affected. A reduction from pre-implementation levels, predicted by the vendor to reach as high as a 50% initially with some limitation thereafter for up to 6 months, did not occur. Figure 4 graphs monthly encounters for the year before and after go-live showing, based on the trendline, at most minimal reduction over the first 3 months and no significant change otherwise. Encounter volume was 107,576 the year before and 109,863 the year after go-live likely representing growth of service.

Figure 4.

Productivity expressed as monthly encounters before and after go-live with trend line.

Customization specific to a homeless population

For ambulatory care, some documentation elements needed to be added and others made more accessible. A tab for homeless status was created to allow choice of 1 of 10 options in anticipation of both clinical and research needs. A best practice alert prompting a tuberculosis skin test every 6 months, essential for a homeless population, was created. A number of screening flowsheets were added as tabbed forms for efficient documentation. These included depression, alcohol use, opioid use, post-traumatic stress, anxiety, and falling. A form was added for collecting HIV data for the Ryan White Program. A tab was added for sexual orientation and gender identity documentation offering 6 designations for which standard registration fields do not provide.

Respite care posed a series of issues related to its hybrid ambulatory and long term stay structure³⁹ and the use of ambulatory care software for this care model. Go-live for this area was delayed 3 months after the primary go-live due to the intrinsic complexity of workflow and functions. Respite care continued to use the legacy system while advanced configuration and testing occurred. Workflow modification included creating admission and discharge processes and entering of 3 nursing and 1 provider note within a single clinical encounter for each day of stay. Scheduling and billing processes were aligned to capture and manage these multiple daily events. Daily medication administration, difficult to track in ambulatory software, was managed through a more suitable separate unintegrated software program which allowed individual dose documentation similar to inpatient care. Preparation for go-live followed the same steps outlined for the initial go-live. Users were shadowed for workflow configuration and analysis. Workflows were mapped in detail by role and function. Documentation tools specific to the respite workflows were developed and screen shot guides were created to visually capture the workflow steps. Respite staff met weekly to test, validate and standardize by consensus the developed processes using the BHCHP’s actual finished build. Prior to respite go-live, staff practiced workflow, and documentation for multiple clinical and operational scenarios ensuring both software function and user performance.

DISCUSSION

This report describes the successful implementation of an EMR for a healthcare program that exclusively treats homeless individuals and families. Specific to this population are decentralized care, unscheduled encounters, combinations of complex illness, the need for extensive integrated behavioral health services, the need for integrated case management and the goal of practicing preventive longitudinal primary care despite these population constraints. At BHCHP by 2010 data, 79% of patients had a behavioral health diagnosis, 23% hepatitis C, and 48% coexisting mental illness and substance abuse. The overall disease burden was 3.8 times the general Medicaid population.³⁸ The complexity of care is an extraordinary challenge to healthcare delivery and IT management. As described earlier, we identified a gap in the literature addressing EMR implementation at community health centers that was even greater at centers dedicated to a homeless population.

At the core of this project was the modification of implementation processes that addressed unique elements of homeless population care that differed from that of a more traditional healthcare system. The modified approach combined mapping of role-based workflows, identifying the tools within the EMR that would serve that workflow, designing documentation unique to the BHCHP patients, developing training tools that reflected anticipated workflow and standardization of EMR use across the Health Care center all before rather than after go-live.

Leadership of BHCHP was committed to the project and earmarked resources and staff. Communication among the vendor, IT staff, senior management, and clinical staff was established at the outset. Project managers from the BHCHP and the vendor integrated their efforts. Provider leadership and acceptance was present throughout the project. BHCHP benefitted further from staff who are committed to the unique organization and the patients they serve.

This report and others have emphasized the importance of workflow. The implementation literature has uniformly emphasized identifying workflows though methods are often vague or unspecified. Detail and specificity vary regarding how and when in the implementation process its evaluation would occur.^44–55 The National Learning Consortium has described specific tools to include workflow process mapping^56–59 utilized extensively in this project. With the BHCHP implementation, workflow analysis started at the onset of the project, was role and function based, and identified the current state elements that would need change. The visual representations of role-based cross-functional maps helped greatly the discussions and development of consensus.

Numerous publications have described in varying detail approaches to documentation of care.^{45,48,60–67} Some articles have reported EMR documentation controversies reflecting the spectrum of users, specialties, and healthcare settings. Of particular note is the range of views, benefits, and limitations regarding structured data entry compared with narrative expression.^68,69 The approach here described addressed and resolved most such controversies. Workflows and documentation tools based on legacy templates and notes were standardized and accepted before go-live.

Training was a continuum from the earliest stages to go-live and beyond. As with workflow and documentation development, training was enhanced by having available a training environment specific to needs of a homeless population. The availability allowed the creation of BHCHP specific screen shot guides to support workflow acceptance and training. Data migration was planned and lab interfaces could be tested. User issues were mitigated by the pre go-live workflow optimization actions described. Electronic migration of legacy data was partial though fully understood pre-go-live.

User resistance is often a critical barrier to all phases of a new EMR implementation and addressed in multiple articles on change management in healthcare IT previously annotated. The issues of change management were addressed throughout the implementation approach. Users understood their workflows, utilized standardized tools and were able to practice within the system they would be using. The culture and the mission of BHCHP were reinforced with staff seeing in the implementation a new interoperable EMR which would enhance care for the patients for whom they had a unique connection and dedication. They enthusiastically embraced the project, its purpose and processes. An initial sense of loss for the legacy system changed to enthusiasm and anticipation for the new system.

The overall approach of this implementation represents a departure from what is often described, used, and recommended. Traditionally, the basic functions of the software are presented and taught with the expectation that operational and clinical workflow would adjust to the new tool. The underlying idea has been to optimize use of the software after go-live once users are familiar with the elements.^4,7,15,52 With such an approach, an adverse impact on the workflow could go unrecognized and the implementation process fail.^4–6 Supporting this view is a multi-center study of EMRs from 2 vendors identifying wide variability in task completion time, clicks, and user error rates all attributed to poor implementation optimization.⁷⁰

A better approach is to start from the optimized workflow and identify the tools within the EMR that serve that workflow rather than to expect that the workflow will change to suit the software. Such an approach requires considerable analysis of the current state and an expectation that many overlooked inefficiencies will become blatant. Starting from the workflow allows standardization of care and resolution of the variability that often occurs later when users create work-around solutions for unanticipated software function gaps. When the workflow comes first, when the users are engaged in its analysis, the ownership and engagement will follow. Change management is addressed as a product of the implementation process. Such an approach is suited particularly to care for a homeless population with complex morbidly. The approach might be considered as well for any healthcare system EMR implementation. Perhaps much of the often voiced anger and frustration surrounding EMR transformation would diminish as a result.⁷¹

This case study has some limitations. It describes an EMR implementation at a large free standing program for treating homeless people in Boston, a city that has committed resources to this medical need. The program has benefited from a staff dedicated to the mission of the health center and willing to accept and pursue change. Other cities and programs might not have such a foundation. As well, Massachusetts has effectively universal healthcare which provides access and financial resources unlikely to be available elsewhere.⁷² Although beyond the scope of this report, these aspects should be considered alongside informatics solutions for underserved populations. Data reflect 1 year’s follow-up assessment. Longer time frames may provide additional insights.

CONCLUSION

EMR implementation at a healthcare center caring for a homeless population imposes unique challenges based on limited resources available and the nature of the population served. A successful approach outlined in this report involves extensive workflow analysis, workflow mapping, build of documentation templates, creation of visual screen shot guides, continuous phased training, and standardization of processes all performed well in advance of go-live. This approach was further aided by early availability at the onset of a live configured training environment and use of consensus building change management strategies. This methodology allowed implementation to occur over an aggressive 6 months’ time frame and productivity and quality improvement to be maintained.