One element of the National Institutes of Health (NIH) Roadmap program, ⁴ initiated in 2004 by the National Heart, Lung, and Blood Institute (NHLBI), and later moved to the National Center for Research Resources (NCRR), was a Broad Agency Announcement (BAA) contract mechanism entitled “Re-Engineering the Clinical Research Enterprise.” The BAA was charged with the discovery of new tools and methodologies for the conduct of multidisciplinary, multi-institutional clinical research projects, to decrease the cost of such projects and to facilitate the extension of their reach into the community at large. In response, the Center for the Advancement of Clinical Research (CACR) and the Depression Center at the University of Michigan proposed and received funding to create the Michigan Clinical Research Collaboratory (MCRC).

The technical mission of the MCRC was to develop and deploy a system (the Honest Broker, or HB) to facilitate seamless and secure sharing of clinical care and research data within an organizational collaboration between geographically dispersed healthcare providers and research entities. Design objectives were to facilitate sharing of data, maintain a master patient index, deidentify data in conformance with HIPAA limited dataset HIPAA safe harbor, and route the data to preauthorized destination systems for use in clinical care, research, or both.

The functional requirements of our HB project can be succinctly categorized into data sharing, identity management, and research data HIPAA safe haven deidentification or HIPAA limited dataset generation.

The Honest Broker interface components are light-weight client-server systems that manage access to specific clinical data stores and communicate with the HBC securely over the Internet using standard, Web-based protocols (e.g., https) and Web Services (See online supplement: Honest Broker interface components, for more details).

In the feasibility study, the Honest Broker Core and interface components were deployed to facilitate interoperability between three previously unconnected clinical care and research systems, and a clinical research management system, each of which is operated by different departments and different institutions. The interconnected systems include (see for diagram):

The Honest Broker allowed an interventional cardiac catheterization patient's cardiology and depression screening data to be shared, from BMC2 and M-Strides respectively, with one or more ClinfoTracker instances serving family practices where the patient received postdischarge follow-up care. In the primary care setting, patients were screened, consented, and enrolled in the prospective observational study using ClinfoTracker. The consent management process is unique to both ClinfoTracker and the HBC. While many EHR's will have notes stating the patient is enrolled in a specific study, the EHR is not the system that sends the message to the clinical trial management system. After the clinical research coordinator-consented the patient, the information was entered into Clinfotracker. From Clinfotracker, a message is generated to the Honest Broker to enroll the patient into Velos. Upon enrollment, previously sent percutaneous coronary intervention (PCI) data from BMC2 becomes requested by HBC to be sent to Velos. If patients decline enrollment, their clinical data are still passed through HBC to ClinfoTracker for their physicians' use.

The use of SNOMED CT allowed HBC to maintain semantic interoperability between all the systems. The cardiology data collected in Velos for the study was a subset of the data sent to the ClinfoTracker and passed to practices for clinical use. The SNOMED CT codes were passed to the individual systems. However, ClinfoTracker maintained the SNOMED CT codes and Velos did not directly store the codes. The limitations of Velos were due to technical difficulties. The internal vocabularies of the different systems in this network were beyond the control of the research project. HBC maintained XLST transformation to migrate the proper subsets of information from the BMC2 data to both the ClinfoTracker and Velos. The benefit of using SNOMED CT allowed all systems to maintain the same meaning across systems and domains. The primary care doctors and Clinfotracker did not need to learn the data definitions of the BMC2 data collection tool.

A benefit of the HB system is in the event of an adverse event or withdrawal from the study. The project was fortunate that no adverse events were reported or patients withdrew. However, upon an adverse event, the data transmitted to Velos could be turned off for all participants, until time of reconsent of all the research subjects. Disenrollment of the patient from this study would still permit all the follow-up clinical data to continue to be routed but no additional research data would be collected. This provides another level of protection for research subjects to meet the requirements of participating in a clinical trial, and enables the remote collection and management of research data.

The Honest Broker supports multiple security schemes to ensure the safety of patient data, while leveraging pre-existing network-based security infrastructure (See online supplement: Security Infrastructure, for more details).

The HBC was developed using best-practices-based software engineering industry tools, design strategies, and development life cycle methodologies; which resulted in real-time updates about the quality and completeness of the software system (See online supplement: Software engineering methodology, for more details).

The development of the Honest Broker followed a multistaged, iterative process that included the development of a clinical research domain model (see ); the identification of the messages required to support the feasibility study (see ); the writing and refining of the software; and testing of the system (see online supplement: Domain Model, for more details).

The HBC was designed as an n-tier software application, with discrete layers for information presentation and capture, business logic, and data persistence, and retrieval. The presentation layer, the topmost tier, is divided into two subcomponents, a Web application interface for human-computer interaction, and a Web Services interface for computer-computer interaction. The human-computer component of the presentation tier uses a model-view-controller (MVC) architecture, with separate components (controllers) for handling requests and rendering user interfaces from HTML templates (see online supplement: Honest Broker core, for more details). The middle, business tier encapsulates all business logic operations of the Honest Broker, including technical operations, such as data validation, information routing, transaction handling, and auditing, as well as the functional operations required for the project, including subject enrollment, patient identity management, limited PHI de-identification, and patient searching. The persistence tier of the HBC was designed to employ the data access object (DAO) software design pattern (See online supplement: Honest Broker core, for more details).

To address the need for a standardized message format, we evaluated several alternatives, and ended up choosing the Clinical Document Architecture (CDA), ²⁰ a constrained subset of the Health Level 7 Version 3 (HL7v3) standard, for transmission of most messages containing clinical data. We chose to employ a mix of project-specific data structures defined by the development team for messages containing no clinical data. All messages used the XML standard as the syntactical base, and validation was enabled using definitions conforming to the XML Schema standard. Use of XML allowed us to easily translate incoming messages into a common internal XML format, which was then transformable into outbound formats after internal processing, filtering, and combining operations were performed. One benefit of using HL7-CDA was forward planning for future development. While all future systems messages would need to be validated, using HL7-CDA would permit faster interoperability.

The CDA message format is rich, heavily nested, complex, and more than adequate to meet our requirements. Its complexity was reflected in a steep learning curve, especially for developers with little or no prior XML experience. Our internally developed XML document types tended to be much simpler than CDA documents, primarily because we were able to define single-scenario data structures vis-à-vis the CDA mandate to serve a multitude of use cases. Of particular value to us were the CDA facilities for nested qualifiers on observational metadata, necessary to express in computer-readable form such constructs as “myocardial infarction event in the context of interventional cardiac catheterization procedure.”

Selection of standards for data encoding narrowed quickly to SNOMED CT and LOINC. For organizational identifiers, we chose the international Abstract Syntax Notation One (ASN.1) standard. Since our clinical problem domain was cardiology, we were unable to leverage the extensive work funded by the NCI under its caBIG ²¹ initiative. While examination of other terminologies occurred, with SNOMED CT, we found an ontology fully capable of expressing the concepts in the project's problem domain, with a few minor exceptions related to experimental assay results.

Downstream licensing issues were a factor considered in the evaluation. SNOMED CT is freely available for use in noncommercial contexts, owing to an agreement between the College of American Pathologists (CAP) and the National Library of Medicine (NLM). LOINC has similar licensing terms. One project survey instrument, the Patient Health Questionnaire 9 (PHQ-9), ²² is licensed by Pfizer. Use of the PHQ-9 has grown rapidly as a screening and monitoring tool in psychiatric and nonpsychiatric settings. We worked with Pfizer and Regenstrief Institute, curators of the LOINC standard, to incorporate the PHQ-9, thus extending LOINC as part of the project. Our other cardiovascular survey instrument was proprietary, and its owners did not wish to consider its inclusion at this point.

Patients could enter the study through one of two ways: (1) having a diagnosis of CHD made by their primary-care physician, or (2) having an acute-event coronary catheterization procedure at one of the participating BMC2 hospitals. Patients were consented for the study at their primary care office. Ninety-three patients with CHD were screened for depression; 88 enrolled in the study. The BMC2 database has 334 total entries for acute coronary events during the study period from the participating hospitals, of which 61 matched to patients in the primary care practices participating in the study. Most of the matches were historical; only 2 patients had acute coronary events during the study period. Of the 61 matches, there were no false negative or false positive matches; each match was verified by a member of the primary care clinical staff team. Of the 93 patients screened for depression, 23 were managed by the depression disease management program (M-DOCC), with the data forwarded to the primary care system.

A key feature that has thus far been omitted from the requirements for HIE and PHR implementations is the ability to link relevant clinical data for use in research projects. High fidelity clinical data can be collected and reused for clinical research purposes with the appropriate consents and permissions obtained. At present, obtaining multiple IRB approvals and cooperation of healthcare IT staff requires significant effort, but this additional cost for both HIE and PHR systems should be considered a necessity as we seek to advance medicine through clinical and translational research.

Although the success or failure of HIEs, as with commercial Electronic Data Interchanges, ²⁴ is most likely governed by the traditional dimensions of interorganizational power and trust, we found the positive factors related to trust to be particularly relevant for an academic, federated data-sharing development project. Several critical factors of trust that played key roles in the successful development of the U-M Honest Broker were openness to ideas and change, a continually renewed understanding of our shared goals, principled commitment to the adoption of nonproprietary standards, and the dependability and accuracy of shared information. Temporary deviations from these factors of trust often times resulted in slowed or stalled progress. Factors that threatened mutual trust relationships among participants included divergent approaches to ensuring security and privacy of patient data, competing organizational priorities, and unforeseeably unrealistic estimates of the effort required to achieve novel and innovative design goals. These factors must be addressed by top-down participating organization leadership commitment to the achievement of project goals, and by vigilant project management monitoring progress, proactively mediating competing priorities, managing expectations, and negotiating resource allocations to meet revised effort and timing estimates.

Working with data standards such as LOINC and SNOMED CT helped us achieve interoperability between the separately developed information systems. We believe that once the standards are implemented on both ends of a transaction, they greatly increase the likelihood of a successful and secure interchange of data. However, this project brought to light a potentially serious risk of disparities of cost and benefit in the deployment of an interoperable, standards-based biomedical information systems infrastructure merging clinical operations and clinical research informatics systems. Clinical operations applications are often maintained by legacy programming staff, many of whom have limited knowledge of research-related requirements for interoperability. Moreover, the missions and cultural norms of operations and research IT organizations are not often harmoniously aligned. These issues must be addressed globally if the national and international biomedical research enterprises are to make significant progress toward the free exchange of data in a regulatory-compliant health information infrastructure (HII).

Data exchange between institutions is notoriously challenging. This project benefited from the fact that there was no adversarial relationship(s) between participating hospital and community-based practices.

While each discipline involved in our research protocol used a separate lexicon to share data, including SNOMED CT, LOINC, and ICPC, the systematic mapping of domain vocabularies helped ensure mutual understanding. Currently, there is no deterministic solution for semantically correct information exchange between domain-specific vocabularies. Collaboration between communities of generalists and specialists could facilitate the harmonization of domain terminologies.

A unique feature of the HB compared with other projects was the adherence to commercial-grade software engineering and data security management practices. While many successful programs can be developed with limited programming skills, sharing sensitive patient data over the Internet requires a higher standard for software engineering quality and formal data security planning than for sharing in an Intranet. This results in higher up-front costs, but the potential liabilities involved in security breaches are far greater and justify these up-front costs. This requirement must be addressed at the highest levels of the sponsors and the universities conducting biomedical research.

While the HIE and PHR projects are significantly larger in scope, this small pilot project demonstrated that incorporating using clinically structured data in a clinical workflow can be done successfully, as well as extracting the data for clinical research purposes. The primary care clinics did not view the recruitment or confirmation of patients from their clinic as a large burden. A recruitment rate of 70% of eligible patients in a primary care clinic is remarkable compared with typical published rates of 18%. ²⁵ While technology is not sufficient to study a distributed population of community-based patients, it does lower the bar to begin to study these populations in a cost-effective manner. Moreover, the substantial increase in the size of the potential subject pool will make possible research that is currently difficult or impossible to undertake, both from logistical and cost perspectives. In talking with primary care providers, the human confirmation of patients' identities was considered necessary, since ClinfoTracker uses the data to generate clinical reminders and decision support as well as store medication history. Therefore, the matches must be correct at the individual level; even a very high percentage correct at the aggregate level would mean some erroneous matches that would erode trust in the system and willingness to share data. While this could potentially limit the initial scalability of the system, once the links are established they are maintained. As increasing the number of patients in the system would also increase the number of primary care physicians available to confirm matches, the system as architected does scale without increasing burden on providers for match confirmation. It is routine in practice for a new patient to fill out a several page form, or a returning patient is often asked to describe any changes in their medical condition; so the alternative of human confirmation of matches followed by automatic data transfer may not significantly increase overall effort.

The HB approach does suggest solutions to many outstanding issues related to data sharing and clinical and translational research. This method, as currently implemented, will not scale nationally with a single Honest Broker instance, but a single instance could serve a large number of patients within a geographic region. With an increasingly mobile society, development of additional data structures and messages to facilitate sharing data on a national scale will be required for scaling beyond regional use. Moreover, a pressing need for improving the efficiency of the difficult process of obtaining multiple IRB approvals for data sharing projects is apparent. Further study will also be needed to fully understand the feasibility of the human-confirmed match process in various scenarios.