Technical Decisions

Author(s): RAND Corporation, HRSA HIV/AIDS Bureau (HAB)

Goals for This Chapter

This chapter is designed to help you:

  • choose a data integration model that is feasible for all partner organizations and maximizes efficiencies
  • select integrated data system functionalities based on identified service coordination deficiencies
  • determine the changes that data system vendors would need to make to integrate two or more data systems, how they would implement new functionalities, and what timelines and costs would be involved.

Data Integration Models

In this chapter, we describe three data integration models. Although this is not the universe of data integration models, these three options cover most of the fundamental technical decisions that need to be made. In the following examples, we describe the integration of data systems across two partner organizations only (recognizing there could be more). Our examples propose data system integration across a housing partner and a medical provider. For that reason, the examples of data elements to be shared (e.g., housing status, viral load) are relevant to housing and medical services. You may be interested in integrating data from different social or human services providers. Although the specific data elements to be shared may differ, these general models will still apply.

Under Model 1, housing and medical providers use and maintain separate data systems.

Data-sharing occurs through a one-way data bridge. In Figure 4.1, the data bridge shares selected housing variables from the housing provider system to the medical provider system only. The data bridge can be activated at a frequency agreed upon by both sides (e.g., daily or weekly updates). Medical providers can see housing information for their clients in their own data system. However, housing providers require access to the medical provider’s system to see medical information, with the result that housing providers might encounter some inefficiencies (accessing shared data through a separate system). Therefore, this model may be selected if one partner experiences administrative barriers to data-sharing or if one of the partners has existing access to both systems.

Figure 4.1. Model 1: One-Way Data Transmission

In Model 2, both systems share client data with each other using a two-way data bridge, or bidirectional transmission (see Figure 4.2). In this scenario, medical providers and housing providers continue to access only their existing data systems to see new shared client data.

Model 2 provides some efficiencies over Model 1, in that neither type of provider needs special access or training to use a different system, although training is needed to access and interpret new data elements and understand service coordination protocols. Model 2 also requires intensive coordination across data vendors of the two systems to ensure clear understanding of what information will be shared, where it will be mapped to in the companion system, and troubleshooting of any possible technical issues.

Figure 4.2. Model 2: Bidrectional Transmission

In Model 2, both systems share client data with each other using a two-way data bridge, or bidirectional transmission. In Figure 4.2, this scenario shows medical providers and housing providers continue to access only their existing data systems to see new shared client data. Model 2 provides some efficiencies over Model 1, in that neither type of provider needs special access or training to use a different system, although training is needed to access and interpret new data elements and understand service coordination protocols. Model 2 also requires intensive coordination across data vendors of the two systems to ensure clear understanding of what information will be shared, where it will be mapped to in the companion system, and troubleshooting of any possible technical issues.

Model 3 has the highest level of efficiency for both housing and medical providers, because they both use one system containing all relevant client data (see Figure 4.3). Updates are accessible to all providers in real time, unlike the other models, in which client data are updated at agreed-upon intervals. Although Model 3 is the most efficient, it is not always feasible.

Programs with existing data systems would need to make significant logistical changes to transfer client data to a new system, including potential disruption of workflow as providers transition to the new system. In addition, the shared single system may not meet the data needs for all clients in an organization, requiring providers to understand and use two different systems (i.e., one for clients shared between a housing and medical provider and one for all other clients).

Figure 4.3. Model 3: Integration Into Single Data System

Model 3 has the highest level of efficiency for both housing and medical providers, because they both use one system containing all relevant client data. Figure 4.3 shows that updates are accessible to all providers in real time, unlike the other models, in which client data are updated at agreed-upon intervals. Although Model 3 is the most efficient, it is not always feasible. Programs with existing data systems would need to make significant logistical changes to transfer client data to a new system, including potential disruption of workflow as providers transition to the new system. In addition, the shared single system may not meet the data needs for all clients in an organization, requiring providers to understand and use two different systems.

Questions to Ask Yourself

  • What data systems do we and our partner organizations currently use?
  • Do all of our partner organizations maintain a client data system, or are one or more organizations working from paper files?
  • Are any partner organizations dissatisfied with their current client data system and thus potentially willing to change to a different system?
  • What challenges might we encounter when switching from one data system or data vendor to another?

Lessons Learned

The following are some critical lessons learned by those at the performance sites selecting data integration models.

  • Even though the most efficient integration model allows all partner organizations to use the same data system, it is not often the most feasible because it would require new funding and/or the wholesale transfer of one or more provider’s existing data into a new system.
  • If you would like to transition to a new data system and vendor (either to streamline to one shared data system or to select a system more amenable to data-sharing), it is important to understand the current contractual agreement with the existing data vendor as you make decisions to transition. Data systems are often a dedicated line item on operational budgets and change may be difficult once budgets are approved.
  • Providers are critical to keeping the integrated data system useful because they need to enter the client data in a timely fashion. An integrated data system is only as useful as the accuracy of the information it contains. To enhance accuracy, it is important to ensure that providers believe the information they are entering is valuable and useful.
  • If the model you are considering requires providers to enter the same data into two different systems or access systems that are not currently part of their workflows, you will need to assess the feasibility of these activities and generate new workflows to accommodate them.

Integrated Data System Functionalities

Although there are many integrated data system functionalities from which to choose, here we focus on those that can support improved service coordination. Having an integrated data system does not, on its own, automate coordination, but it can streamline many manual processes. After integration, providers will still be engaging each other in coordination, ideally in a manner that is more meaningful to the client because of systematized information-sharing and a reduction in paperwork.

Flags/Alerts

Data systems can be programmed to “flag” data. Flags that can be used to enhance client service coordination include, for example, if specific client data fields (e.g., housing status) have not been updated over a certain period of time, if a client appears to have fallen out of care, or if a client’s viral load becomes detectable. Including flags and alerts about out-of-date information or upcoming milestone dates (e.g., rent renewals) gives all providers a better understanding of the client’s situation and provides additional opportunities for providers to offer support (e.g., if a housing provider notices an out-of-care flag, she can talk to the client about this and coordinate with her counterpart provider to ensure that the client can schedule an appointment).

Secure Direct Messaging

One way to enhance service coordination is to facilitate communication between providers. Non-secure email cannot be used to share client data across providers. However, an integrated data system can be equipped with secure email or messaging between providers that complies with privacy and security rules, such as HIPAA. For this functionality to work, it is essential for clients to be assigned or affiliated with case managers/providers in the system so that the direct message reaches the correct person in the counterpart agency.

Shared Reports

Client-level shared reports between organizations can help providers identify clients with priority issues and better coordinate service plans and program recertification documentation. Shared reports are also useful at the organizational level, such as summary performance measures across all joint clients to identify broader challenges.

Shared Provider Contact Lists

Often, the names and contact information for all providers serving a client are not available to each individual provider. An integrated data system is an ideal place for providers to enter their information and affiliate it with clients on their caseload so that counterpart providers spend less time tracking down this information.

Link Clients to Providers

If every client is linked to a case manager or other provider in the system, other users will know whom to contact for any issues regarding this client. If or when a new case manager takes over, keeping this information updated in the system would eliminate confusion and lags in communication.

Questions to Ask Yourself

  • What specific areas of coordination do both providers and clients want improved and how can we implement new functionalities to address those areas?
  • In what specific ways will our proposed new functionalities support service coordination?
  • What is the new step-by-step process that our providers will need to follow to maximize the new functionalities’ benefits?
  • What are the barriers to providers using the new functionalities and how do we address them?
  • How can we best message to providers the benefits of using the new functionalities?

Lessons Learned

The following are some critical lessons learned by those at the performance sites selecting integrated data system functionalities.

  • Buy-in from providers is critical to getting them to use the new functionalities. Allowing providers to suggest functionalities and test them out before launching can greatly increase their engagement with the integrated system.
  • Such functionalities as shared reports across partner organizations can be influential for planning but require a higher level of organizational coordination and commitment.
  • Training for use of new functionalities cannot be a one-time activity. Follow-up training is essential to identify where providers have continued gaps in knowledge.

Engaging Data System Vendors

A data system vendor is typically an external company that is paid to set up and maintain data systems. Data system vendors1 must be invested and involved in this venture because they will likely be the ones to translate your ideas into the technical work needed to integrate and enhance the data system. In some cases, your own internal IT department may be able to make the necessary changes to a data system to facilitate integration. However, your partners in data integration may still require the engagement of a data system vendor.

Organizations may find themselves hesitant to launch a project like data integration because, even though they understand the benefits, they do not feel well-versed enough in their data management systems to make all of the technical decisions. If you have a good relationship with your data vendor, they may be able to serve as guides through the process. If you would like additional support, you can hire a consultant who can help translate your integrated data system needs into a plan for the vendors. Vendors may discuss different issues with you as they effect data integration (e.g., a roadmap or plan for the data system integration, software update schedules for the data systems, changes to your existing system that could improve data integration for service coordination, new functions for users in upcoming software versions, how best to coordinate the technical exchange of data from a software point of view).

For the purposes of this toolkit, we define a data system vendor as a third-party organization who services your data system, providing updates and upgrades as they become available. Vendors could provide an array of other services, such as performing routine maintenance, troubleshooting problems with the software, customizing functionality and reports, and providing training to new users, among others.

Questions to Ask Yourself

  • Is our internal IT department well versed enough in our data management system to provide some or total support to data integration? If yes, what support can they provide?
  • Do we have a data system vendor? If so, what kind of support are they currently contracted to provide?
  • What is the payment structure between our organization and the vendor? Do we pay the vendor each time for a data or report request or is maintenance and reporting built into the contract?
  • What is the timeline that the data vendor(s) can agree to for carrying out the work, including training for our users, key milestones for the project as we have defined them, and testing by our users?
  • Are there any major barriers that could derail the timeline, such as major upgrades to the data system software that may be required or be beneficial for supporting the integration between our system and another one?
  • Are there barriers to multiple data system vendors working together to complete the project?
  • How do our contracts with vendors need to change to maintain the integrated data system?
  • What is our communication and accountability plan to keep vendors on track to complete the integration?

Lessons Learned

The following are some critical lessons learned by those the performance sites working with vendors.

  • Even the best-coordinated plans can be delayed by unforeseen issues related to data vendors. It is critical to ask vendor representatives about planned major software upgrades by their companies or any other changes that might cause delays. Once integration projects have started, months long vendor-related delays can cause the process to lose momentum or buy-in.
  • It is critical to understand up front how the contract with the vendor is structured to avoid unforeseen costs later on in the project, particularly maintenance costs for updating and revising systems on a continuous basis. This is one reason to consider engaging a consultant to help guide the technical work if your organization lacks expertise.

If you are working with multiple vendors, it is helpful to have a knowledgeable data manager from one of the provider organizations serving as a project manager. This individual can clearly communicate expectations to all vendors, make sure the vendor-led work is being done correctly and on the agreed-upon timeline, and share progress and any challenges with all participating organizations to reach resolution.