Leveraging Health Information Exchange to Improve Population Health Reporting Processes: Lessons in Using a Collaborative-Participatory Design Process

Abstract

Introduction:

Surveillance, or the systematic monitoring of disease within a population, is a cornerstone function of public health. Despite significant investment in information technologies (IT) to improve the public’s health, health care providers continue to rely on manual, spontaneous reporting processes that can result in incomplete and delayed surveillance activities.

Background:

Participatory design principles advocate including real users and stakeholders when designing an information system to ensure high ecological validity of the product, incorporate relevance and context into the design, reduce misconceptions designers can make due to insufficient domain expertise, and ultimately reduce barriers to adoption of the system. This paper focuses on the collaborative and informal participatory design process used to develop enhanced, IT-enabled reporting processes that leverage available electronic health records in a health information exchange to prepopulate notifiable-conditions report forms used by public health authorities.

Methods:

Over nine months, public health stakeholders, technical staff, and informatics researchers were engaged in a multiphase participatory design process that included public health stakeholder focus groups, investigator-engineering team meetings, public health survey and census regarding high-priority data elements, and codesign of exploratory prototypes and final form mock-ups.

Findings:

A number of state-mandated report fields that are not highly used or desirable for disease investigation were eliminated, which allowed engineers to repurpose form space for desired and high-priority data elements and improve the usability of the forms. Our participatory design process ensured that IT development was driven by end user expertise and needs, resulting in significant improvements to the layout and functionality of the reporting forms.

Discussion:

In addition to informing report form development, engaging with public health end users and stakeholders through the participatory design process provided new insights into public health workflow and allowed the team to quickly triage user requests while managing user expectations within the realm of engineering possibilities.

Conclusion:

Engaging public health, engineering staff, and investigators in a shared codesigning process ensured that the new forms will not only meet real-life needs but will also support development of a product that will be adopted and, ultimately, improve communicable and infectious disease reporting by clinicians to public health.

Introduction

Evidence-based decision-making in public health aims to protect the health of a community through program planning and leveraging actionable data. The capacity to conduct this work begins with surveillance: the ongoing, systematic collection, analysis, and interpretation of communicable and infectious disease data that are the cornerstone of public health practice.1 Much of public health surveillance continues to rely on government-driven, mandatory reporting of disease—i.e., notifiable conditions—through passive surveillance methods wherein health care providers and laboratories report specific diseases to public health authorities. However, numerous studies have found that traditional notifiable disease reporting is burdensome for providers and produces reports that are incomplete, are delayed, and that vary in data quality.2–6 Given their significance to public health activities, collecting high-quality, reliable, complete, and timely data merits ongoing attention and quality improvement efforts.7

Work to improve surveillance strategies with respect to notifiable condition reporting has evolved in recent years with the advancement and adoption of information technology (IT) in health care. Increasing attention has focused on leveraging electronic health record (EHR) systems, connections between diverse clinical information systems, and using technologies supporting the transmission and transfer of health information such as electronic laboratory reporting8 and health information exchange (HIE).9 These developments have the potential to shift reporting from the traditionally passive to active notifiable disease surveillance that promises to be more timely, complete, and clinically detailed to meet the surveillance needs of public health.8,10 One proposed pathway towards active surveillance in settings that employ EHR systems is to deploy notifiable condition report forms that are pre-populated with electronic data generated in the clinical care setting.11

However, understanding public health surveillance needs is critical to designing interventions and tools to meet those needs.12–13 Furthermore, IT-system and information-process design must be conducted within the constraints of the available public health infrastructure,14 including where it is feasible to access clinically derived electronic health data.15 Incorporating end users in a collaborative IT design process can ensure that the design includes context of use and that the developed tool or software program not only meets the needs of its users and fits within organizational workflow, but also safeguards against a common IT pitfall of, “If we build it they will come.”16

Participatory design (PD) is an approach that advocates the inclusion of end users and stakeholders in IT design to ensure high ecological validity of the product, incorporate relevance and context into the design, reduce misconceptions designers may have due to insufficient domain expertise, and ultimately reduce barriers to adoption of the system.17–18 This paper describes the informal collaborative PD process we used to develop an innovative IT-enabled solution to improve community reporting processes by deploying notifiable condition report forms that are prepopulated with electronic clinical data available in an EHR system. Our process was informal, collaborative, and inclusive; we sought to involve public health, IT, and research team members throughout the design, development, and implementation processes of the reporting system.

Background

The objective of the “Improving Population Health through Enhanced Targeted Regional Decision Support” research project is to improve the known underreporting and incomplete notifiable condition reporting by clinical providers, which can lead to inaccurate assessments of the disease burden in a community and hinder population health interventions. To meet this objective the project aimed to reenvision a standard, paper-based notifiable-condition reporting form into an electronic reporting form—tailored to identified high-priority communicable and infectious disease case conditions and capable of being prepopulated with patient demographic data and pertinent case management information available through the EHR system utilized by an HIE. Our group hypothesized that an enhanced, prepopulated reporting form tailored to specific notifiable diseases that matches public health work processes and task flow would improve timeliness and completeness of clinician notifiable-condition reporting to public health. Hereafter, this is referred to as the “intervention.”

Ensuring the success of our reenvisioned reporting forms required input from end users. Public health communicable and infectious disease specialists were required to articulate their unique information and surveillance needs. Technologists tasked with designing the information architecture to extract needed data from the EHR and construct the electronic forms to capture these data were also critical. PD operates within a “third space” in which the work domains of technologists (which focus on the artifact or product as an end in itself) and end users (which focus on the human work processes and how the artifact or product is a means to meet user needs) overlap and create a hybrid product-process realm.19 PD advocates, as its most fundamental tenet, that the people affected by a design outcome must be included in the process of design as active cocreators.20 Substantive user involvement in design increases commitment to and adoption of technological innovations, increases end user buy-in, improves final product quality, shortens the number of development cycles and iterations, and improves user satisfaction.17–20

Given these advantages, we utilized PD methods to design our health IT (HIT) innovation. However, while PD is a strategy that is advocated to ensure that developed technologies, software, or tools interface appropriately with their intended users, PD has rarely been applied to large-scale health care systems or settings comprising heterogeneous user groups, such as HIEs.21 Thus, finding appropriate ways to engage and involve end users of varying backgrounds, experiences, expectations, and roles within the design process can be a challenge. For this reason we chose to restrict our design process to the public health end users in collaboration with the technologists leading the engineering development of the enhanced and prepopulated notifiable-condition reporting forms.

Methods

Settings

The clinical setting in which the intervention will be used is the Indiana Health Information Exchange (IHIE), a mature, robust health information infrastructure. IHIE provides a number of information services to Indiana-based health care providers, including DOCS4DOCS, which delivers clinical messages such as laboratory and radiology results to over 20,000 physicians,22 and the Notifiable Condition Detector (NCD),23 which automates the identification of clinical results to be reported to public health under state law. The intervention leverages existing technologies such as the NCD and creates a prepopulated electronic reporting form using data available from the patient-centric EHR part of the Indiana Network for Patient Care (INPC),24 another IHIE service that uses a master person index to link electronic clinical data in the community. The system can then deliver the prepopulated form using the DOCS4DOCS service to the clinician who ordered the test for the given notifiable disease.

Figure 1 depicts the flow of information through the IHIE infrastructure. Note that clinicians send report forms by fax machine to public health agencies. Intended recipients of the intervention are existing providers in clinics with established services from IHIE who will complete the prepopulated and enhanced form for delivery to public health agencies.

Figure 1.

Flow of Information through the IHIE Infrastructure

Intended recipients of the completed notifiable-condition report form are public health agencies in Marion County, Indiana, which receive forms from providers by fax machine. In Marion County, the health department organizes reportable disease surveillance into two distinct working groups: sexually transmitted infections (STIs) and non-STIs. Seven targeted conditions were focused on for the intervention: Acute Hepatitis B, Chronic Hepatitis C, Chlamydia, Gonorrhea, Histoplasmosis, Salmonella, and Syphilis.

Ethics

A Human Subjects application (minimal risk) was submitted for this work as per Institutional Review Board (IRB) protocols at both Indiana University and the University of Washington for any research involving human subjects, including PD or quality improvement activities. The project received approval by the Indiana University Human Subject Division with a concurrent IRB deferral from the University of Washington to Indiana University.

Overview

Over nine months, public health stakeholders, technical staff, and the research team engaged in a multiphase PD process that included focus groups, a survey, and meetings to iteratively design enhanced notifiable-condition reporting forms for the seven targeted conditions that incorporate case information from the EHR system utilized by IHIE. Our design process alternated internal team activities and broader stakeholder engagement to transform existing, paper-based forms into dynamic, prepopulated electronic forms customized for each target notifiable condition over six phases as described below.

Team Composition

The research team was made up of professionals with a broad range of clinical, public health, and informatics experience. The three lead investigators collectively possessed more than 35 years of experience designing, implementing, and evaluating interventions in clinical and public health settings. Two researchers brought over 15 years of qualitative analysis and formative research experience to the team. The team also included two clinical epidemiologists from a local health department, each with over 10 years of experience. In addition, a systems engineer with 10 years of experience in clinical settings designed and implemented the technical components of the intervention. Other team members involved in the PD process included a graduate student research assistant and a project manager with public health training and experience.

Phase 1: Research Team Brainstorming

As stated, the research team included broad representation from clinical, public health, and informatics domains. Our process began with team members generating ideas for the electronic pre-populated forms. Existing forms from the state health department are static, one-size-fits-all paper forms last updated in 1996. We aimed to create dynamic, web-based forms that could be updated frequently and customized based on class (e.g., STI, enteric condition, etc.) or specific disease. Initially, our research team met to discuss the existing data fields represented on the state form (see Fig. 2), and they brainstormed additional fields and information that might be relevant to case investigation.

Figure 2.

Data Fields in State Form

The session was intentionally unstructured, allowing the research team to “think outside the box” and suggest any and all ideas for improving existing communicable disease forms. Two main questions guided the discussion: (1) What potentially relevant clinical information is missing from the existing form; and (2) What information might be of interest to public health stakeholders? Ideas were recorded in meeting notes and summarized for use in later phases.

Phase 2: Preliminary Public Health End User Focus Groups

After brainstorming with the internal group, research team members who were experienced in conducting focus groups met with external groups of public health stakeholders. Given the health department organizational structure (described in Settings), one focus group was conducted at each public health agency site to facilitate separate conversations with the two distinct groups of stakeholders based on their areas of clinical focus—STIs and non-STIs. Participation at each site was based on applicability of job role, and all individuals in relevant roles were invited to participate. Seven invitations were issued in the STI public health agency and eight in the non-STI public health agency; six individuals participated in the STI focus group and eight in the non-STI focus group. Participants at each site included a mixture of case management technicians, case management supervisors, or epidemiologists. During each focus group we provided an overview of our study and reviewed the existing state form and its data elements. Next, we asked participants to brainstorm additional data and information they would like to see on the forms sent from clinical providers that could improve their disease surveillance and investigation process.

Three primary questions guided these focus group discussions: (1) What potentially relevant clinical information is missing from the existing form? (2) What additional information are you interested in gathering from providers? and (3) Which fields on the existing form are not essential to your work? As part of this process, ideas generated by the research team in Phase 1, such as adding liver enzyme lab results to forms, were presented to illustrate potential revisions to the form and to engage participants when conversation waned. Throughout the discussion, the focus group leader summarized suggestions, contributions, and points of agreement and disagreement among the participants.

Group sessions were digitally recorded and detailed meeting notes taken by two research team members. Recordings were used to supplement and clarify meeting notes but were not transcribed for analysis. Given this very focused activity, analysis of the detailed notes was sufficient because the meeting goals were clearly defined and conversation was focused on form modifications. Notes were collated into a single document for analysis by two team members experienced in qualitative data analysis using the content analysis method,25–26 a strategy used to analyze and generate recommendations from moderated discussions such as multidisciplinary panels focused on issuing practice guidelines27 and subject-matter expert discussions.28–29 Meeting note analysis revealed specific recommendations to revise the notifiable-condition report forms for each condition as illustrated in Figure 3, which shows an example of preliminary report form revisions for two of the target conditions: Acute Hepatitis B and Salmonella. While this outcome provided a benchmark for making revisions, the technical capability to implement these changes required review—described in the next section—before reaching a final consensus on the modified form.

Figure 3.

Sample of Notifiable-Condition Report Forms

Phase 3: Technical Feasibility Assessment

Global ideas for report form improvement and disease-specific suggestions were synthesized into a single working document for Phase 3 in which the feasibility of electronically capturing and prepopulating the identified desired data elements was assessed by the research team and technical staff. First, a determination was made as to whether the requested data were available in EHR systems during routine clinical care activities. If so, the group assessed whether these data are routinely transmitted to the HIE.

As one example, stakeholders strongly desired to have symptoms such as jaundice and dark urine included on the report forms as these symptoms can assist investigators in establishing clinical indications of Hepatitis B and C in addition to, or in lieu of, laboratory test results as established in CDC case definitions.30 However, symptoms are not documented discretely in EHR systems but rather are embedded in free-text notes, if they are documented at all. In addition, these notes are not always sent to the HIE. As a result, it was determined that, while these data are in the EHR, it would not be possible to capture these data electronically and prepopulate them onto the form because they are not computable and are not consistently transmitted to the HIE. However, an alternative would be to design the dynamic forms to autogenerate a checklist of key symptoms as identified in CDC case definitions—allowing providers to easily select specific symptoms for any given case. A spreadsheet was used to collate the technical feasibility of including each desired data element and condition. Figure 4 provides an example of the Technical Feasibility Assessment form for one of the target conditions, Chlamydia.

Figure 4.

Example of Technical Feasibility Assessment for Chlamydia

Phase 4: Public Health End User Survey

The Technical Feasibility Assessment developed in Phase 3 was converted into an electronic survey document for review by all public health stakeholders who participated in the focus groups and their respective work group managers. Stakeholders were asked to individually categorize each of the data elements identified in phase 3 as “feasible” with respect to its relevance for public health investigations. The survey asked stakeholders to assess each element as: (1) required for an investigation and to close a case; (2) desired for an investigation and to close a case; or (3) desired for an investigation but not to close a case. Stakeholders were also asked to confirm the removal of existing data fields that were rarely used by providers or did not contribute to establishment of case definition. Two completed surveys were returned, one from each public health site. The manager of each of the two work group divisions synthesized the individual responses and submitted a single completed survey to the research team. Survey responses were used to support prioritization of data elements and design of the revised forms for Phase 5 as illustrated in Figure 5.

Figure 5.

Prioritization of Data Elements and Design of the Revised Forms

Phase 5: Exploratory and Iterative Form Prototyping

The systems engineer created a series of dynamic forms customized by disease and symptom list with data elements identified by the Phase 4 survey. As discussed above, in Phase 2 we learned that public health stakeholders desired that the forms would capture symptoms as identified in CDC case definitions as well as other clinical elements. However, for each condition, these lists are extensive so the decision was made to restrict the symptom list by condition and to create disease-specific forms. In addition, this ensured that the new forms would roughly equate to the one-page paper document that clinicians were already familiar with completing. The engineering team made mock-ups of disease-specific forms electronically as PDF documents, eliminating data elements that were identified in Phase 4 surveys as adding limited or no value to case investigation. Figure 6 provides an example of a report form mock-up for one of the target conditions, Gonorrhea.

Figure 6.

Report Form Mock-Up for Gonorrhea

Phase 6: Final Public Health End User Prototype Review Focus Groups

A final round of focus groups with public health stakeholders was held to evaluate the form mock-ups. Recruitment methods for Phase 6 were identical to those described for Phase 2, but with lower participation rates (n=3–5 in each group). Each focus group reviewed the prioritized list of data elements and provided feedback on the revised form design. Note taking and analytic methods for Phase 6 were the same as described in Phase 2. Figure 7 provides an example of the Gonorrhea mock-up with final modifications requested by public health end users.

Figure 7.

Report Form Mock-Up for Gonorrhea with Final Modifications from Public Health End Users

Final mock-ups for each disease are being used by the engineering team to develop the prepopulated form as described in the Next Steps section below.

Results

Each phase of the development process built on the previous phase results and produced new ideas, requirements, or prototypes that enabled our team to advance the design, development, and implementation of enhanced notifiable-disease reporting forms for the seven targeted conditions. Figure 8 illustrates our PD process and outcomes from each phase of the process.

Figure 8.

Participatory Design Phases

The first two phases generated several strategies detailing the enhanced form’s function and layout. During Phase 1, an initial list of potential changes was collated. For example, a physician on the team suggested that recent liver enzyme lab results would be of interest for cases involving Hepatitis C and theorized that this additional laboratory test information—in addition to a positive or negative diagnosis of Hepatitis C—could enable both providers and public health to quickly distinguish chronic cases of Hepatitis C from acute cases. After Phase 2, a full list with input from the research team and the focus group participants included demographic, clinical diagnosis, laboratory, and treatment data. Some data elements already existed on the static form, including patient name, address, gender, race, disease name, and physician name. There were also data elements added as a result of the suggestions, including symptoms, corollary tests (e.g., liver enzymes for Hepatitis C), and HIV status.

Lessons Learned from Each Phase of Form Development

Phases 1 and 2 identified existing less useful form fields that are not generally completed by physicians, are not applicable to all diseases, or are not helpful for disease investigation processes. In addition, the need to provide disease-specific forms for particular reportable diseases was identified during Phase 2. This suggestion came about because of each disease’s complexity, specific symptoms, and public health stakeholders’ desire for longer symptom lists on the revised forms.

Phase 3 findings resulted in consolidated lists of data elements and designation of each element as “feasible” or “not feasible” to include in the form, based on whether or not the element was currently collected electronically. The removal of unused or low-priority data elements during this phase resulted in additional white space and more space for adding other elements identified as high priority.

The fourth phase asked users to review and prioritize the consolidated list of technically feasible enhancements. The primary results from this phase were the identification of additional priority elements, identification of low-priority elements, and consensus to remove some elements. Decisions to remove several technically feasible elements viewed as lower priority were reached because of consensus that the form should not be overcrowded.

The last two phases engaged users in providing feedback on a series of form prototypes. These final stages provided affirmation that the development team was targeting appropriate data and information that stakeholders needed for disease investigation processes. Feedback from users helped in changing the order within and the refining of form design specifications, and further informed the strategy for prepopulating the forms using EHRs. As a result of this phase, additional white space was reclaimed and the Indiana state seal was removed from the form. The output from Phase 6 provided a final set of design specifications and technical requirements for our development team (see Fig. 6). Review of the proposed modifications by clinical members of the research team affirmed that providing this additional information in a prepopulated form will streamline the reporting process and reduce the time needed to complete forms. Public health stake-holders also affirmed that receiving this data will streamline their case completion processes and reduce the burden of contacting providers to obtain information missing on report forms.

Major Changes to the Final Form

Specific results from all phases of the process include the following design specifications and modifications to the form:

• High priority fields were included in a convenient location on the form. For example, HIV status was added—as a checkbox—and the number of sexual partners was added.

• Rarely used, low-priority fields were eliminated. For example, labs routinely send details regarding bacterial serotypes (etiologic agent) information, which providers include on forms.

• Disease-specific form elements were included. For example, new data elements relevant to sexually transmitted infections, such as number of sexual partners, were included.

• The Indiana state seal was removed.

Next Steps

Notifiable-condition reporting form templates, one for each of the seven conditions targeted in the study (Acute Hepatitis B, Chronic Hepatitis C, Chlamydia, Gonorrhea, Histoplasmosis, Salmonella, and Syphilis), have been developed for use in a trial. The templates were designed to meet the information needs of public health end users and to match the technical capabilities of the HIE—which will automatically prepopulate the forms with available, prioritized data elements, and distribute the forms through the IHIE infrastructure (as illustrated in Fig. 1) for completion and review by clinicians before they are faxed to the public health agencies. Minor adjustments to the mock-ups, where necessary based on Phase 6 feedback, were made to the forms by the engineering team.

Deployment of the forms began September 2014 in pilot clinics. The evaluation of these improvements on notifiable-condition report data quality and timeliness is described elsewhere.31 In brief, this evaluation utilizes a concurrent design mixed-methods framework in which qualitative methods are embedded within the quantitative methods. Quantitative data collected will include reporting rates, timeliness, burden, and report completeness and accuracy, analyzed using interrupted time-series and other before-and-after comparisons. Qualitative data regarding before-and-after provider perceptions of report completeness, accuracy, timeliness, reporting burden, data quality, benefits, utility, adoption, utilization, and impact on reporting workflow will be collected using semistructured interviews and open-ended survey items. The evaluation seeks to identify: (1) barriers to and facilitators of implementation, adoption, and utilization of the intervention; (2) impacts of the intervention on workflow, provider awareness, and end user satisfaction; and (3) contextual factors that have an impact on the effectiveness of the intervention within heterogeneous clinical settings and the HIE.

Discussion

To adequately monitor and respond to issues affecting community health, public health agencies require complete and timely information on notifiable diseases and the populations with those diseases. In this paper, we describe the application of informal PD methods to redesign and deploy enhanced notifiable-condition reporting forms in a large, urban community. Although the forms were developed primarily for use in a study of enhanced disease-reporting processes using HIE, their use could extend well beyond the trial to enhance disease reporting across Indiana and in other contexts. Furthermore, the PD methods described in this paper have applications outside of notifiable disease reporting and the design of informatics systems used in clinical or public health organizations that seek to improve community health outcomes.

Prior to this paper, PD methods have been described and recommended for the design of clinical as well as public health informatics systems.21,32–36 Our contribution to the literature is two-fold. First, unlike other PD studies that focus on describing the system developed and evaluation of that system, this paper is a detailed description of the PD methods utilized, thus illustrating how to apply PD and providing a structure for others to replicate across a range of biomedical informatics interventions. Second, this paper describes the use of PD to redesign processes and information systems across intersecting clinical and public health settings. Other studies report using PD to design or redesign a single system in two different local health departments, whereas the enhanced notifiable-disease reporting forms described here will be utilized across multiple health facilities and systems.

The PD process enabled us to not only learn more about reporting processes but also to learn more about the contextual issues surrounding notifiable-condition reporting from the perspective of public health. Understanding context and work processes supports development of innovative technology solutions that are driven and informed by their end users’ expertise, domain knowledge, and organizational workflow. For example, by involving public health end users in the process of form redesign, we were made aware of important differences between policy needs (e.g., state mandated fields on the forms) and actual workflow needs. This shared understanding facilitated the support needed to adjust the layout of the new form to make it more useful and streamlined for both those completing the form—as determined by research team clinical review, and for those receiving the information—as determined by public health stakeholder review in Phase 6. Whether this streamlining also has impacts on clinical reporting rates or timeliness is a focus of the project evaluation described above.31 Rather than recreating a paper form using IT software, we redesigned the form to respond to the realities and goals of the work being done, and the context of its use by clinicians and policymakers. An additional outcome of utilizing the PD process was the lesson that there were a lot of form fields that were customarily missing or unnecessary for clinician input. Cutting these fields benefitted engineering design processes by creating usable space and reducing the need for costly redesign during testing phases.

By engaging with end users, the project team was able to establish appropriate user expectations, and an ancillary benefit of the PD process was to manage these within the limits of engineering and technical development and feasibility. For example, during Phase 2, public health stakeholders requested that the forms provide a single, drop-down symptom list. However, this request was not possible to implement by the engineering team during the Phase 3 feasibility assessment. The need to provide this information and alternative methods to meet this stakeholder need was presented to end users, thus enabling our team to iteratively explore options in Phase 5 with end users. The collaborative PD process resulted in a compromise that would meet end user information needs within an approach that is technically feasible.

A potential barrier to greater use of PD in the design and development phases of electronic information systems in clinical and public health is that these methods add time and administrative costs to a project. Instead of taking six to eight months to design the prototype and test the enhanced forms, our team could have performed the same work in two to three months if the design were driven by internal team members only. Furthermore, scheduling and facilitating multiple forums in which end users had an opportunity to discuss and engage with our team added time as well as costs to our project manager’s and study team members’ efforts. Even with a focused approach, some project or program officials may not look favorably on what may appear to be a long development time frame and costly overhead.

Our team emphasized PD for high-priority notifiable-condition forms rather than redesigning all reporting forms, and—in this way—concentrated the resources for use toward more commonly reported conditions. While unlikely, it is possible that our emphasis on high-priority notifiable conditions may have biased the redesign process—as less common conditions potentially have unique information needs or constraints that were not captured by our PD methods. Given that design consists of trade-offs, an argument can be made that designers must position limited resources at the greatest area of need with the greatest anticipated benefit. It would require significant effort to redesign forms for less common conditions, and the process could result in less-than-full support of end user information needs.

Another consideration for greater use of PD is team composition. As previously described, our team consisted of interdisciplinary professionals with a broad range of clinical and public health informatics experience. Our engineer had several years of experience designing and deploying IT interventions into complex clinical workflows. The investigators all had experience working in public health settings, and one is a family physician with over a decade of clinical practice involving notifiable disease reporting to health agencies. Our project manager had formal training in public health, enabling deeper understanding of project concepts than her peers without such training. Three team members had experience with “people and organizational issues in informatics” (POI) methods and techniques like PD. This combination of team members’ backgrounds and expertise is unique and may be challenging for other projects that seek to use PD methods. However, many current training programs in informatics emphasize the role of informaticians as liaisons between clinical and IT professionals.44 We believe future research utilizing PD methods could effectively be conducted by a smaller team as long as the team collectively possessed clinical, public health, technical, and informatics expertise.

While PD methods add time and effort to the initial design and development stages, one of the potential benefits of PD is that it can support the process of building consensus to move a project forward, thus mitigating total cost and time overruns by addressing suboptimal design upfront rather than later in the project life cycle, which has been shown to be much more expensive than correcting a low-fidelity prototype prior to its implementation.37–38 Particularly for projects requiring collaboration among multiple and complex organizations, the benefits of employing PD methods can outweigh the expense of time and effort given higher quality requirements that can improve system usability, reduce workflow barriers, and ensure system adoption.39 This has been demonstrated by the Public Health Informatics Institute project to inform the development of an improved and more efficient laboratory information management system40 and the application of PD methods by the Department of Veterans Affairs to improve their electronic drug-allergy, drug-drug interaction, and drug-disease alert system.41 Upfront investment of time and energy can help avoid costly redesign or system abandonment following deployment.

Acceptability and design of information systems in complex contexts is an ongoing, organic, and “live” process. Although engaging clinical stakeholders would be expected for an intervention that targets information exchange between clinical and public health settings, our PD process did not directly include the community providers who will complete the prepopulated forms. While pure PD research would engage all users of a system, the reality of all organizations (including interconnected health enterprises), precludes full engagement at all times during all phases of a project. We believe any limitation this might present was addressed by members of our project team who served as a collective proxy for community providers: a clinical informatics researcher with more than a decade of practice in a family medicine clinic; a health informatics researcher with more than a decade of experience designing and integrating HIT solutions into primary care settings; and a systems engineer with experience developing and implementing HIE-based technologies into a range of clinical settings. The positive responses to the proposed workflow and prepopulated form designs by intervention site clinical and administrative staff indicate that the team input and knowledge regarding context of use and existing work processes were accounted for in the design process.

Limitations

The context in which our methods were conducted may limit their generalizability to other HIE settings, and this is therefore important to describe. The Indiana HIE has a long-standing and highly engaged collaborative relationship with its public health stakeholders. However, current estimates suggest that just over one-third of public health departments are engaged in community-based HIE initiatives.42–43 Although this proportion may increase in coming years due to the implementation of the “meaningful use” program in which hospitals and physician practices begin electronically reporting data to public health,44–45 our ability to engage clinical and public health professionals to change health system information flows may not be generalizable to all jurisdictions.

Another process limitation concerns our project structure. Our research team functioned as a broker between clinical and public health end users and their organizations’ IT departments, so there is potential to miscommunicate end user feedback. Also, our team was not responsible for the development or maintenance of IT systems used in settings outside of the systems provided by IHIE. Thus, it is possible that these systems may need to be redesigned or enhanced to fully support clinical and public health end users in surveillance and monitoring of notifiable disease burden within the community.

Conclusion

Collaborative, participatory processes enhance the design, development, and deployment of HIT-enabled population health interventions. By working closely with end users, engineers and researchers alike were more aware of and sensitive to frontline public health workers’ information needs and information work-flows. Furthermore, by providing a venue for gathering input and engaging in discussion regarding the redesigned forms, our informal PD process facilitated end users becoming co-owners of the redesigned forms and may enhance buy-in from our community stakeholders. PD methods are logical and approachable, enabling their use in a wide range of clinical and public health settings. Our work in this project has laid the foundation for future investigations using PD approaches to design, develop, and implement HIE-enabled interventions to improve population health in our community.