Guiding Principles for Data Architecture to Support the Pathways Community HUB Model

Abstract

Introduction:

The Pathways Community HUB Model provides a unique strategy to effectively supplement health care services with social services needed to overcome barriers for those most at risk of poor health outcomes. Pathways are standardized measurement tools used to define and track health and social issues from identification through to a measurable completion point. The HUB use Pathways to coordinate agencies and service providers in the community to eliminate the inefficiencies and duplication that exist among them.

Pathways Community HUB Model and Formalization:

Experience with the Model has brought out the need for better information technology solutions to support implementation of the Pathways themselves through decision-support tools for care coordinators and other users to track activities and outcomes, and to facilitate reporting. Here we provide a basis for discussing recommendations for such a data infrastructure by developing a conceptual model that formalizes the Pathway concept underlying current implementations.

Requirements for Data Architecture to Support the Pathways Community HUB Model:

The main contribution is a set of core recommendations as a framework for developing and implementing a data architecture to support implementation of the Pathways Community HUB Model. The objective is to present a tool for communities interested in adopting the Model to learn from and to adapt in their own development and implementation efforts.

Problems with Quality of Data Extracted from the CHAP Database:

Experience with the Community Health Access Project (CHAP) data base system (the core implementation of the Model) has identified several issues and remedies that have been developed to address these issues. Based on analysis of issues and remedies, we present several key features for a data architecture meeting the just mentioned recommendations.

Implementation of Features:

Presentation of features is followed by a practical guide to their implementation allowing an organization to consider either tailoring off-the-shelf generic systems to meet the requirements or offerings that are specialized for community-based care coordination.

Discussion:

Looking to future extensions, we discuss the utility and prospects for an ontology to include care coordination in the Unified Medical Language System (UMLS) of the National Library of Medicine and other existing medical and nursing taxonomies.

Conclusions and Recommendations:

Pathways structures are an important principle, not only for organizing the care coordination activities, but also for structuring the data stored in electronic form in the conduct of such care. We showed how the proposed architecture encourages design of effective decision support systems for coordinated care and suggested how interested organizations can set about acquiring such systems. Although the presentation focuses on the Pathways Community HUB Model, the principles for data architecture are stated in generic form and are applicable to any health information system for improving care coordination services and population health.

Introduction

The Pathways Community HUB Model was developed by the Community Health Access Project (CHAP) to improve preventative care for high-risk mothers and children in under resourced areas. The HUB Model was developed in 2004 and is fundamentally a delivery system for care coordination services provided in a community setting. The HUB Model was recognized by the Agency for Healthcare Research and Quality (AHRQ) Innovations Exchange, and a collaborative learning network of 16 communities was implemented.1 As detailed in Zeigler et al.,2 the HUB Model creates the infrastructure within a community to organize care coordination services. Pathways are used as a common outcome measurement tool across all care coordination agencies that connect with the HUB.

The Pathways Model provides a unique strategy to effectively supplement health care services with social services needed to overcome barriers for those most at risk of poor health outcomes. Pathways are standardized measurement tools used to define and track an issue identified at the individual level—from identification through to a measurable completion point. Pathways focus on both health and social issues that need to be addressed to increase the likelihood of a positive outcome for the individual. Twenty Core Pathways have been developed for many issues, including obtaining health insurance, finding a medical home, pregnancy, developmental screening, and tracking social service referrals such as housing and employment.3,4,5

Where it has been implemented, the HUB Model coordinates agencies and service providers in the community to eliminate the inefficiencies and duplication that exist among them. At the foundation of the Model are these primary features: (1) Core Pathways, (2) the HUB itself, and (3) payments linked to outcomes. The HUB is a regional point of registry and outcome tracking that networks together community care coordination agencies, providers, and payers. The HUB uses Pathways along with other metrics to monitor progress at the individual, care coordinator, agency, and regional levels. Clients, care coordinators, and agencies providing related services in a region of the country (usually within state boundaries) are registered, tracked, and monitored by the HUB. Pathways are associated with payment by Medicaid managed care plans, government programs, philanthropic foundations, and other payers for specific benchmarks along the Pathway—the highest payment is provided for successful outcomes at completion. In this way, Pathways provide the infrastructure to link payment to outcomes, thereby linking payments to performance.

The Pathways Community HUB Model is unique in that the outcomes are tracked at the level of the individual being served and each step of the Pathway addresses a clearly defined action toward problem resolution. Many steps deal with social and cultural issues, and these steps are just as important as the traditional activities of the health and human service systems. Pathways have been developed for many issues, including homelessness, pregnancy, medical home, immunizations, lead exposure, and behavior issues. Unlike guidelines or protocols, also referred to as clinical or critical pathways,6,7 coordinated care Pathways are analogous to skeletons showing paths and benchmarks rather than detailed handbooks of actions to achieve these benchmarks. One client may be assigned to many different Pathways depending on the problems identified during the initial interview and subsequent home visits. This concept differs markedly from guidelines or protocols for which accountability is not deliberately taken into consideration.

A Pathway is not considered complete until its identified problems have all been successfully resolved. Conversely, at some definitive point, a Pathway that has not been successfully completed must be closed in a documented fashion.

Experience with the Pathways model has brought out the need for better information technology solutions to support implementation of the Pathways themselves through decision-support tools for care coordinators and other users to track activities and outcomes, and to facilitate reporting. In this article we present a set of core recommendations as a framework for developing and implementing a model for data architecture to support implementation of the Pathways Community HUB Model. We then focus on some issues that have been identified in experience with it and some remedies that have been developed to address these issues; we show how these elements map back to the recommendations of the data infrastructure. The objective is to present a tool for communities interested in adopting the Pathways Community HUB Model, to learn from and to adapt in their own model development and implementation efforts.

In the following sections, we begin with a conceptual description of the Pathways Community HUB Model since it is not yet widely known. This provides the context for a discussion of a series of challenges faced through using electronic data for communitywide interventions and some solutions on how such challenges can be prevented or solved in future endeavors. Then we discuss how communities should utilize or treat existing Electronic Health Record (EHR) data for their community-based health interventions, especially using the Pathways Community HUB Model. We conclude with a brief discussion regarding gaps and further considerations for development such as the need for decision support, and we suggest how to expand current medical ontologies to include care coordination that are focused on medical terminology and that do not address care coordination.

Pathways Community HUB Model and Formalization

Although well-defined from an implementation perspective,1 the Pathways Community HUB Model has not received a definition from a data design perspective. To provide a basis for discussing recommendations for data infrastructure, we first provide a conceptual model that refers to the informally described Pathway concept underlying current implementations, such as in Redding et al.1

In this model, community health workers (CHWs) are the client-facing care coordinators and are backed up by supervisors, social workers, and others. As shown in the upper left of Figure 1, the Client Referral Process, Client, CHW Interaction, and Billing of payers are integral to the Pathways conceptual model. These activities have their corresponding data storage and retrieval representations in the CHAP database as indicated in the right half of Figure 1. Although risk assessment is also an essential activity, it was not represented in the original CHAP database but has since been identified as needing such representation. In the referral process, upon enrollment a client is interviewed with a checklist of questions that enable assessing the risk level of the client and that determine the set of Pathways to be initiated. Subsequently, CHWs interact with clients on a one-to-one basis to encourage, monitor, and track clients in order to achieve the assigned subgoals of the Pathways—to improve thereby the prospects of attaining their goals. Such interaction is documented in auxiliary data fields associated with Pathways steps in the database. We refer to all data related to a client as the Pathways Client Record (PCR), and we discuss later the relation of such data to more well-known EHRs. Further, billing can involve multiple entities, especially if behavioral health services are involved. These data can be challenging to integrate retrospectively as needed to associate payments with services provided in a pay-for-performance model. In the conceptual model, Pathways are associated with payment for specific benchmarks along the Pathway, with the highest payment provided for successful outcomes at completion. Accordingly, payers, such as Medicaid managed care plans, are associated with clients and Pathways. They are represented in the billing data, thereby enabling payments to be linked to accomplishments.

Figure 1.

Pathways Conceptual Model and its Implementation

To date, the Pathways Community HUB Model has been implemented in some 16 communities,2 and standards for certifying Community HUB programs have been developed.18 However, requirements for data architecture to support the Model have not been developed. We discuss such requirements in the following section.

Requirements for Data Architecture to Support the Pathways Community HUB Model

Figure 2 illustrates the data architecture for supporting decision-making for care coordinators, CHWs, administrators, and other users implied by the Pathways Community HUB Model, and the data architecture requirements to be presented. Before discussing such requirements, we briefly summarize the main points of the architecture in Figure 2. The distinguishing characteristic of this architecture is that, except for Pathway initialization, user interactions with the system are driven by the Pathways steps currently in play. One or more Pathways are initialized when a client is enrolled—based on an enrollment questionnaire that establishes the particular needs or risks of the client and prescribes appropriate Pathways to address such issues. Subsequently at each Pathway step, the system requests data from the CHW that is specifically required to complete that step. Besides keeping such data immediately available to help with progression to the next step, the web services Portal transmits appropriate patient health information for long-term storage in electronic form in the PCR. Both data stores are then available for analytics by other users such as supervisors, system operators, operation analysts, and researchers. The PCR database for care coordination is located in the Pathways HUB and is directly accessible by CHWs and other HUB personnel via the Pathways Portal. The central role of the Pathways concept and its organization of the PCR database illustrates a general approach to address and improve interoperability between the data and systems being used by diverse users.

Figure 2.

Data infrastructure for Pathways Community HUB: Circled numbers link to Key Requirements

Having summarized the main points of the architecture in Figure 2, we outline the requirements for data architecture to support the Pathways Community HUB Model. These recommendations are grounded in real world experience in attempting to extract, analyze, and apply Pathways data, rather than being derived from existing literature studies, because such literature has yet to develop. Our intent is to stimulate and guide the development and study of Pathways models—and, more broadly, care coordination—with particular attention to their data architecture requirements. The following key features are linked to related elements in Figure 2.

Requirements for Pathways Community HUB Model Data Architecture

1. The Pathways web services Portal should mediate between the database holding Pathway Client Records and users such as care coordinators (CHWs, supervisors), care providers, managers, and quality improvement analysts.

2. Care coordinators should be able to enter timely patient information while other users have access to the information in real time.

3. The Portal should guide data entry according to the rules of the Pathway currently controlling user input. The Portal can do this, knowing the state of the Pathway Model and, therefore, the current step of the Pathway.

4. The Portal should eliminate incomplete and inconsistent data entry of Pathway steps, improving data quality while simultaneously reducing user effort in data entry. Of course, users must still understand the semantics of a Pathway (e.g., what the steps and dates represent) to make meaningful entries.

5. The Portal should deliver the client caseload to the care coordinator with the entire Pathways and checklists for each specific client, allowing the coordinator to interview and record the information gained during the coordinator’s client meetings.

6. The information collected should be used in the Pathways payment process for reporting and invoicing based on Pathway billing codes reflecting completed outcomes (in contrast to payment based on activities, i.e., pay-for-services.)

7. The data system should also be the primary repository for the collection of Pathways and HUB information and should be open to interconnection with EHRs in Health Information Exchanges. The system database should be replicated within a secure environment, and should be available offline over secure channels for analysis, reporting, and invoicing purposes.

We summarize these requirements in Table 1 for later reference.

Table 1.

Summary of requirements for Pathways Community HUB Model Data Architecture

NUMBER	REQUIREMENT
1	The Pathways Portal should mediate between the PCR database holding client data and the users.
2	The Portal should support care coordinators in entering primary patient data enabling other users’ access in real time.
3	The Portal should guide data entry according to Pathway states and rules.
4	The Portal should eliminate incomplete and inconsistent data while simultaneously reducing user effort.
5	If requested, the Portal should deliver the entire Pathway for each client to the care coordinator.
6	The information collected during Pathway operation should support the payment process.
7	The data system should be the primary and secure repository for Pathways and HUB information, and should be open to interconnection with EHRs in Health Information Exchanges.

Problems with Quality of Data Extracted from the CHAP Database

Experience with Pathways Community HUB Data

In research that we previously documented in Zeigler et al.,4 we collected de-identified personal health and behavioral data for clients from the database employed by CHAP using the EHR technology of that time, which was quite limited compared to that current at this writing. As with previous studies of Pathways Community HUB coordinated care,5 we encountered problems with the quality of the data extracted from the CHAP database that are nevertheless still germane to today’s technology. See Appendix 2 for a brief review and summary of the data quality challenges that we encountered. A definition from the literature and the associated challenge is appropriate here: “Data validity refers to the level of completeness (i.e., the amount of missing data for a data element), accuracy (i.e., the extent to which the data reflects the underlying state or process of interest), and granularity (i.e., clinical specificity).” However, ensuring the validity of EHR data has been noted to be a significant challenge.8,9 Such data quality issues can be viewed within a broader context of problems that have arisen with EHRs. Kahn et al.,10 considering data models for comparative effectiveness research, examined the suitability of several data models for determining which data elements will be stored and how they will be stored, including their relationships and constraints. They concluded that successful data modeling requires focusing on objectives, addressing compromises between complexity and usability, and prioritizing requirements, all of which are dependent upon many factors.

As indicated, CHAP agreed to provide access, under suitable data sharing agreements (as required by federal privacy protection regulations, data distribution policies of sponsoring agencies, etc.) to its database of client and Pathway records. The de-identified data that we extracted consisted of personal health and behavioral data (demographic, socioeconomic, etc.) for successfully and unsuccessfully treated clients. The study was a retrospective review of a data set captured in CHAP’s database between 2009 and early 2013. CHWs captured client visit information during home visits on paper forms, and then transcribed data into the EHRs upon return to the office. The data was stored in a relational database, and each client was assigned a unique identification number (ID), serving as a primary key within table rows to associate data elements to specific clients. The data fields capture responses to initial interview questions, as well as notes entered by CHWs after each home visit.

The system did not provide sufficient means to analyze its data. In order to enable such analysis, as well as to create an independent de-identified data set, we developed an approach to export data tables into spreadsheet forms. Furthermore, to explore the data, we developed an array of tools to join client record rows from various data tables and to “slice and dice” the data for the various analyses discussed in this article. Most relevant to the Pathways Community HUB data management is the development of support for data entry that encourages accurate and complete entry of Pathway events by CHWs as they occur in interacting with the client. The formalization and associated proposed implementation of the Pathways Model address these limitations with the intention of providing a design for an improved implementation. The lack of ontologies for care coordination also motivates criteria for the proposed formalization to lay the basis for standards for Pathways semantics and pragmatics that eventually can be incorporated into EHRs (the term “pragmatics” distinguishes the intended use of data as opposed to its meaning (semantics) captured in current ontologies.11,12,13

Key Features of Health Information Technology (HIT) Support for Pathways Community HUB Data Infrastructure

Organizations interested in implementing a data infrastructure for a Pathways Community HUB in order to address the requirements listed in Section 3 can refer to the following set of key features on which to base their implementation. In each case, we discuss the motivation underlying the feature, either by giving a rationale or the experience that led us to recognize the need for this feature. We also enumerate the primary requirements for system operation, given above, that the feature supports.

The Key Features are organized into four categories:

1. Data Definition and Management deals with how to exploit the Pathways structures to organize the data and facilitate its comprehension and analysis.

2. Data Entry User Interface provides guidelines for data entry and standards for input validation.

3. Control of System-User Interactions offers Pathway-based status information and support for different uses of the data.

4. Security of Data Interfaces deals with security completeness, recognizing that this topic can be the subject of much more in-depth discussion.

Data Definition and Management

Key Feature 1: The system database maintains the information gathered by the community care coordinators using the Pathways processes, as well as auxiliary data associated with process steps. Pathway structures are applied to organize the data and identify the level of process completion.

The step-wise nature of Pathways provides the basic structure concept for representation of client data in the data infrastructure for Pathways-based care coordination. We found that a rudimentary representation was employed in the CHAP database that did not fully capture Pathways’ temporal behaviors and presented a challenge to efficiently analyzing the data. The demands of Pathways’ temporal aspect are more fully discussed below. Key Feature 1 supports requirements 1, 2, and 3.

Key Feature 2: Adequate metadata descriptions are provided, and data models depict table relationships and keys that are designed to adequately and uniquely represent the Pathway structures and associated auxiliary data.

The ability to decipher the data fields and understand the meaning of data entries is impeded by the following: lack of metadata describing the data set, absence of an entity relational diagram describing the database structure, nonnormalized data table structure, and inconsistent naming convention of database table primary keys (i.e., client ID versus patient ID). In our work, we found that some of the fields needed for analysis were missing, e.g., we were not able to clearly identify episodes of care such as different instances of pregnancy for the same client. Also, key data elements were missing that our research hoped to find, e.g., there was not sufficient granularity in the representation of social service referrals. This impeded our ability to determine factors that might affect important relationships. Key Feature 2 supports requirements 3 and 4.

Key Feature 3: Unique representations of data values are enforced or standardized cross-mappings are provided if multiple representations are allowed.

Text data entry fields allow multiple data representation of identical concepts and a wide array of noncomparable data values. In our work, we found that such multiple representations created ambiguity in data interpretation while noncomparable data values limited ability to place values into serial order. Appendix 2 discusses in more detail the data quality issues that we dealt with. Key Feature 3 supports requirements 3 and 4.

Data Entry User Interface

Key Feature 4: Guidelines are provided for data collection and entry with incentivized enforcement and computerized support to ease adherence to these guidelines.

Some of the cause of the data management difficulties already enumerated can be attributed to a lack of data collection policy and procedures to guide the data entry process. Such guidelines should be based on, and provide an actionable form of, the key features for health information technology (HIT) support under discussion. It is also important that the guidelines for data collection and entry be enforced by incentives and computerized support to make following them as easy as possible. Key Feature 4 supports requirements 3 and 4.

Key Feature 5: Standardized entries, and input verification and validation, provide data integrity and accuracy. HUB management can add entries to drop down lists augmenting those available to users for data entry.

Clear definitions of fields (supported by metadata descriptions as mentioned above) and constraints on what can be entered (e.g., dates are consistently entered in standard format) are necessary to help the CHW and other users enter data correctly and consistently. Replacement of free text entry by selection lists offering single or multiple choices eases both data entry and subsequent analysis of the data (inclusion of the “other” choice enables users to enter free text as needed). We frequently encountered data fields that were filled with more than one variable per data cell. We concluded that some of the problems we encountered were due to the lack of standardized entries and the absence of verification and validation of these entries. Key Feature 5 supports requirements 3 and 4.

Control of System-User Interactions

Key Feature 6: Status messages are provided to users and supervisors on screen and in reports.

Such messages serve as alerts and reminders of tasks to be completed for each client by the CHW as well as by clients themselves. In our work, we frequently encountered data fields that were not completed when they should have been. For example, appointments were made but there was no entry confirming the appointment was kept, as required by a Pathway. Alerts and reminders can help to assure that such tasks are actually kept and recorded. Key Feature 6 supports requirements 4 and 5.

Key Feature 7: While active, Pathway data can be entered and modified by care coordinators in both structured and note-based forms. Completed Pathways are moved to archival history and are then available in a read-only state with authorized overrides.

Since multiple instances of Pathways are generated both for the same, and for different, clients, it is important to distinguish completed Pathways and to lock them in so as to prevent further accidental modification. However, authorized means must also be provided to override such locks in order to modify data in the archive if it becomes necessary. For example, inconsistencies may be detected during a general review of all the database data whose resolution require careful revision. Key Feature 7 supports requirements 5.

Key Feature 8: Upon completion of a Pathway, state codes are generated based on Pathways rules to differentiate the completed Pathways—for process analysis, business intelligence, reporting, and invoice generation for the appropriate paying entity. Since Pathways may be abandoned before normal completion (see Appendix 1), it is important to include codes for such cases.

In our work we found a lack of report generator and analysis tools for the CHAP data. This led us to develop our own tools to organize and “slice and dice” the data. In this way, our study resulted in a Pathways formalization that serves as a basis for process improvements in care coordination involving computerized support—for more complete and consistent Pathway reporting, improved client adherence to their recommended activities, and improved coordination among the payers and agencies.4 Moreover, abandoned Pathways are suitably coded in this approach to enable subsequent statistical treatment. This focus on Pathway structures enables an approach that can address such issues in a formal, generalizable, manner. Key Feature 8 supports requirements 6 and 7.

Security of Data Interfaces

Key Feature 9: Secure interfaces are provided for claims processing, document transmission, and client referral to the Pathways Community HUB.

Security must be provided to protect client personal data as well as system operational data. Key Feature 9 supports requirement 7.

Implementation of Features

To implement such features, an organization can consider either tailoring off-the-shelf generic systems to meet the requirements or offerings that are specialized for community-based care coordination. To support the growth of the Pathways Community HUB Model, Care Coordination Systems (CCS)14 has developed a PCR database that implements the above features. CCS introduced additional modules— the Pathways HUB Connect system and Pathways Mobile—to provide the Pathways Community HUB Model with numerous additional features aiming for streamlined interfaces and better user experience. Care coordinators access the system through the Pathways Mobile tablet applications, mobile tablets accessing the HUB portal through secure web browsers, and directly via the user-enabled HUB portal used by the HUB administration staff as well as care agencies, their desk-based supervisors, and coordinators. In this way, the HUB administrative staff and the care coordinators are able to accomplish in a timely manner the information tasks outlined in Section 8. A risk module scores the validated Pathways client data to rank clients and to assist care coordinators in prioritizing services for clients (also available for use by researchers). More general HIT systems may have generic features that can be specialized for community-based care coordination. Systems such as Covisint15 and JProg’s CAREWare16 offer a variety of data organization and aggregation functions and also provide support for Health Information Exchange (HIE) initiatives that need to access applications and share information in an agnostic manner with existing national, state, or regional EHR systems.

As mentioned above, the data quality issues raised here can be seen within a broader context of problems that have arisen with EHR systems as they become more widespread and are required for use under federal health care policies. Perhaps the most common situation encountered in data quality is that a data element is either overlooked entirely or is entered inconsistently in multiple locations or in different formats within, or across, EHR systems. This makes it difficult to ascertain the intended relevant data value or even to obtain a close approximation of it (see Appendix 2). In this context, the remedies suggested above can be viewed as providing approaches to particular problems within larger problem sets. For example, experience in the Beacon Communities suggests that data quality can be improved by providing charts showing missing data as feedback to collectors and customizing their workflow to support standard data collection.17

Discussion

Ontology to Include Care Coordination in Unified Medical Language System (UMLS)

The requirements and features for adequate metadata descriptions and standardized terminology (stated above) should ideally be based on ontologies that are universally adopted for coordinated care and health care more generally. However, we have to recognize that current ontologies for health care are focused on medical terminology and do not address care coordination. More broadly, Koppel20 recently called the universe of EHR systems a “Tower of Babel” situation, partly due to the lack of adoption of a single standard for EHRs. A quick review shows that Continuity of Care Record (CCR) is a health record standard intended to provide summary records of a patient’s health information that uses Extensible Markup Language (XML) to provide flexibility that will allow users to formulate, transfer, and view such records in a number of ways. Such means includes transport by Health Level 7 (HL7) messages, the most widely adopted HIT message standard.21 Such summaries are much less granular than patient data obtained from an individual visit or encounter as required by the Pathways Portal. Indeed, a key design feature of the Pathways Portal is the ability to track a client at each step of the Pathway, provide decision support to CHWs, and provide reporting capabilities to all involved staff.

EHR vendors in the United States are now required by Meaningful Use Stage 222 to enable electronic systems to understand each other using the common language Systematized Nomenclature of Medicine–Clinical Terminology (SNOMED-CT) included within the Unified Medical Language System (UMLS) of the National Library of Medicine.12 To comply with this requirement, vendors are utilizing “maps” between existing EHR systems based on the International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)23 and SNOMED-CT. The nursing services orientation of the Clinical Care Classification (CCC),24 which is integrated in the UMLS Metathesaurus and SNOMED-CT, renders it a candidate for consideration in the care coordination context discussed here.

Figure 3 displays a potential approach to developing ontology for the Pathways Community HUB Model that can support the enhanced PCR data infrastructure. To integrate with the UMLS, existing terminologies can serve as inputs for the terms that constitute the Pathway descriptions. In particular, the clinical terminology of SNOMED-CT and the nursing terminology of CCC are considered an input to a potential Pathway ontology. Although the CCC considers coordination of care, the type of care it concerns differs substantially from that under consideration here. Unlike nurses, care coordinators (e.g., CHWs) in the Pathways Community HUB Model coordinate, but do not provide, care directly to the patient. Indeed, in this model, the care recipients are typically referred to as clients, rather than patients. One role of the care coordinators is to facilitate connections to evidence-based care that is provided by clinicians (e.g., prenatal care services). In addition they facilitate connections to services provided by community-based agencies (e.g., transportation, social services). While care coordinators are not direct service providers of either the clinical or community-based services, they are involved in finding those at risk, ensuring that they are treated with evidence-based medical and social interventions, and measuring the health outcomes and costs of these efforts. The Pathways in this model concern the representation of some of the activities in this kind of coordination. Therefore we recommend that the Pathways ontology employ UMLS terminologies rather than attempting to subsume it within the CCC.

Figure 3.

Approach to Developing Pathways Ontology

Figure 3 recognizes the levels of clinician-provided care and community service agencies coordinated by the HUB. This is consistent with the multilevel framework for coordination within and across organizations that identifies key dimensions that can be altered to enable or improve communication and coordination.25 Such dimensions include the organization structure, knowledge and technology employed, and administrative operational processes (e.g., by introducing cross-organization care pathways), and were found to be effective in enhancing information exchange, alignment of goals and roles, and improved quality of relationships in service of better care outcome quality and cost.25 The HUB Pathways are distinct from the pathways developed across the primary-hospital care continuum shown to enhance the components of care coordination of the multilevel framework.26 Existing billing codes are shown in Figure 3 as being correlated with UMLS terminologies by vendor mappings. Likewise, billing codes are being developed for the HUB Model to be consistent with Pathways steps that will allow each such step to be linked to payment based on outcomes rather than activities.

Conclusions and Recommendations

We have presented an approach to ensuring Pathways client data validity and improving the design of associated health information infrastructure for community-based care coordination. Beyond making explicit the aspects in which data quality can fall short, the approach has been shown to inform the design of decision support systems for CHWs and other participants in the Pathways Community HUB. We exploited the existence of Pathways structures to organize the data using formal systems concepts to develop an approach that is both well-defined and applicable to general standards for certification of such organizations. The presentation showed that Pathways structures are an important principle, not only for organizing the care coordination activities but also for structuring the data stored in EHRs in the conduct of such care. We also showed how it encourages design of effective decision support systems for coordinated care and suggested how interested organizations can set about acquiring such systems.

A major goal of data architecture design for data validity is to reduce the errors in PCR data. In our previous analysis of the CHAP database, we developed metrics for measuring the completeness and consistency of data entered by CHWs. As reported in Zeigler et al.,4 by computing these metrics we were able to correlate quality of CHW performance with eventual client pregnancy outcomes. In general, measurement of errors and correlation to types of users and outcomes is an aspect of EHR data that seems to be often overlooked in HIT policy and programs and needs to be better understood. We recommend further research on metrics such as percentage of records with errors, different types of errors and how they are distributed among records, and how such errors affect the outcomes and implementations of HIT data systems.

Although we have suggested how to expand standard UMLS ontologies to include community-based care coordination, we have not provided a detailed plan for such expansion, which remains for future work. We recommend that it be undertaken by the Pathways Community HUB certification committee18 along with the associated formalization of Pathways.4

Although the presentation focuses on the Pathways Community HUB Model, the principles for data architecture are stated in generic form and are applicable to any health information system for improving care coordination services and population health.

Glossary

Community Care Coordination:

Care coordination outside the health care setting addressing both health and social services needs

Core Pathways:

The Pathways that are approved by the National Pathways Community HUB Certification Group, of which there are currently 20

Data Architecture:

A model of the interactions among data systems of an information system, setting forth data processing requirements and standards

Decision Support System:

A computer-based information system that supports business or organizational decision-making activities

Electronic Health Record (EHR):

Broader repository and record of client information than an Electronic Medical Record, which is generally defined as containing only clinical data.

Formalization:

Providing a definite structure for an informal concept; in this paper, through providing a logical, mathematical, or systemic definition that supports computer manipulation

Implementation:

Generally, the process of putting a decision or plan into effect; commonly employed in information technology as the process of developing software to the specifications of data architecture

Legal Traces:

Sequences of steps that are prescribed by a Pathway model (as opposed to illegal sequences that don’t conform to the Pathway specification)

Metadata:

Data that serves to provide context or additional information about other data, in this paper used regarding the data in a database

Ontology:

A formalization of concepts and relationships underlying knowledge about a domain such as medicine; prescribes semantics of terms used in the domain and can be extended to include “pragmatics” (see definition below)

Pathways:

Tools to track identified social or medical issues to a measurable outcome

Pathways Client Record (PCR):

Record of client’s progress through Pathway interventions that have been initiated for the client

Pathways Community HUB Model:

A delivery system for care coordination services provided in a community setting with primary features: (1) Core Pathways, (2) the HUB itself, and (3) payments linked to outcomes

Pathway Structure:

Refers to the manner in which states (steps) and transitions (from one state to another) of a Pathway model relate to each other

Pathway Temporal Behavior:

The succession in time of the Pathway states (steps) including the time it takes to execute each step

Pragmatics:

Refers to the manner in which data is to be used, including context and intent

Semantics:

Refers to the meaning of the data independently of its use (both semantics and pragmatics are needed in a complete ontology)

Social Determinants:

The complex, integrated, and overlapping social structures and economic systems that are responsible for most health inequities. These social structures and economic systems include the social environment, physical environment, health services, and structural and societal factors.

Appendix 1. Illustrating Pathway Temporal Behavior

An illustrative Pathway as implemented in the database is shown in Table A.1, in terms of a specification of step names, I S1, S2, S3, and S4, and paired interpretation of dates to be entered by the CHW. This abstraction represents the core of several Pathways with appointments, such as social service and medical referrals.

Table A.1.

Illustrative Pathway

STEP NAME	INTERPRETATION
S1	Pathway Initiation Date
S2	Pathway Scheduled Appointment Date
S3	Pathway Appointment Kept
S4	Pathway Finished Incomplete

The actual records appearing in the database are traces of activity events intended to consist of step names paired with dates entered by the CHW in accordance with the given meanings. Thus the following represents an event sequence in which a Pathway is initiated, and an appointment is scheduled and kept, with the respective dates shown.

Table A.2.

An Event Sequence

S1	11/01/2012
S2	11/22/2012
S3	11/22/2012

For this Pathway there are only two sequences of steps that are intended by the designer: S1, S2, S3 and S1, S2, S4. However, in practice, other patterns were observed—sometimes missing a step, sometimes with too many steps. The set of legal traces grows dramatically when we recognize that some Pathways allow for multiple replications of subsegments, e.g., repeated doctor’s visits in the Pregnancy Pathway.

Figure A1.

A Temporal Scenario for the Pathway of Table 1

For this Pathway there are only two sequences of steps that are intended by the designer: S1, S2, S3 and S1, S2, S4. However, in practice, other patterns were observed—sometimes missing a step, sometimes with too many steps. The set of legal traces grows dramatically when we recognize that some Pathways allow for multiple replications of subsegments, e.g., repeated doctor’s visits in the Pregnancy Pathway. Figure 2 outlines a scheduling use case in which the client should make an appointment and keep it. The Pathway gives the client 10 days to make the appointment, which the client then makes for two weeks later. An alert is generated if the appointment is not made, and a reminder is sent within two days of the appointment date. This kind of scenario can generate the legal traces intended by the conceptual Pathway specification. In Zeigler et al.4 we developed a formal specification of Pathways using the Discrete Event System Specification (DEVS) modeling framework that represent such schedules in a generic language-independent manner. The details of the DEVS formalization that provide the computational temporal semantics of a Pathway are beyond the scope of this paper and are available in Zeigler et al.4 Also, as indicated and depicted at the bottom of Figure A1, the formalization helped to meaningfully analyze the extracted data despite the often incomplete or inconsistent traces in client records—details of which are also given in Zeigler et al.4

Appendix 2. Auxiliary Data Challenges Encountered

Since the original CHAP database did not come with a usable data model, we followed Chen27 in reconstructing a data model that would help conceptually manage the data. Figure 3 provides a fragment of this scheme that helped to illuminate data quality challenges in the particular context of Pathways-based coordinated care.

Figure A2.

Entity-Relationship Model Fragment of CHAP Data

Our extraction of data for analysis revealed a number of limitations in the implementation prevailing at the time (an updated implementation improved in part due to our work is described below). A significant challenge for the research was that data collection was incomplete; our findings suggest that some data fields were never completed. There was more data field completion for data elements that were associated with service payments. Data entry was not standardized. Most data fields did not have any prescribed data validation filters. The result was a wide array of noncomparable data values. Issues included mixed units of measures (lb., kg, oz.), fraction values, and decimal values (5.5 lbs., 6 ¾ lbs.) As stated in Shachter et al.,17 “The common issue is that data elements are often entered inconsistently in multiple locations or in The common issue is that data elements are often entered inconsistently in multiple locations or in incomplete, inaccurate, or inconsistent data can lead to miscalculated denominators (e.g., patients eligible for a measure) and numerators (e.g., those eligible who received recommended care), and reduce the overall validity of the measure results.” As with other research,17 the issue becomes the ability to determine a close approximation of the relevant data element. Redundant data elements can help to confirm such approximations. For example, in the CHAP data, it would be have been helpful to have another data field that provided clinical data confirmation of the client’s self-reported infant birth weight.

Appendix 3. Additional Temporal Requirements

As indicated above, we found that the rudimentary representation employed in the CHAP database did not fully capture Pathways temporal behaviors. Here we discuss the demands of the temporal aspect of Pathways, referring to a short review of this aspect in Appendix 1. This review suggests the type of support needed for scheduling, cancellation, and reminder- and alert generation to more fully capture Pathway temporal behaviors. The formalization of the Pathways Community HUB Model that we presented in Zeigler et al.4 affords a solid, implementation-neutral basis for enhanced computerized support for care coordination based on the Pathways concept. In this light, we present some additional requirements based on the formalization:

1. The software should handle the time management, event scheduling, state transitions, and input and output of the Pathways Model. Multiple model instances may be active at any time to represent several concurrent Pathways of a single client, as well as multiple such instances of the current set of clients with records resident in the database.

2. The software should also provide tools that provide more in-depth analysis based on temporal and dynamic behaviors such as analytics for client assessment (i.e., adherence or compliance) and for HUB operation (activity-based time-driven accounting,19 reporting quality, outcome evaluation). These functions can be based on the Pathways formalization as discussed in Zeigler et al.4