The Honest Broker is a suite of software components, including a core system and a set of interfaces that are each associated with an individual clinical or research software system. These components communicate via the Web in a star, or hub and spoke, network pattern that is implemented as a Services Oriented Architecture (SOA). The hub of the network, the Honest Broker Core (HBC), is responsible for routing messages and clinical data between the other systems of the network. In addition, the HBC provides services for identifying patients; manages patient identifiers; provides a mechanism for partial, rules-based deidentification of protected health information; can convert messages between independent, structured formats, simplifying the integration of external systems; and ensures that all data are dealt with securely by enforcing system authentication, authorization, and message encryption.
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):
- • ClinfoTracker17: A clinical prompt and reminder system developed by the U-M Department of Family Medicine, recently commercialized as Cielo Clinic (Cielo MedSolutions, Inc, Ann Arbor, MI), that is deployed at multiple primary care sites within the State of Michigan.
- • Blue Cross Blue Shield of Michigan Cardiovascular Consortium (BMC2)18: A system for capturing and storing deidentified interventional cardiac catheterization outcomes data developed at the U-M Cardiovascular Center as part of the Michigan Cardiovascular Outcomes Research and Reporting Program (M-CORRP).
- • M-Strides: A depression screening and monitoring system that was developed by the U-M Depression Center and Department of Psychiatry. This computer system supports a collaboration called Michigan Depression Outreach and Collaborative Care (M-DOCC), where clinical care providers help patients complete their screenings via phone calls.
- • Velos eResearch19: A commercial clinical research management system (Velos, Inc, Fremont, CA) operated by the Michigan Institute for Clinical and Health Research (MICHR), successor organization to CACR.
Figure 1 A Unified Modeling Language (UML) deployment diagram depicting the major hardware (blue boxes) and software (yellow boxes) components of the U-M Honest Broker system. The lines between the servers show the communications protocols used by the connected (more ...)
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).
Figure 2 A UML (Unified Modeling Language) object diagram depicting the main domain objects of the Honest Broker as well as the structure of the messages, as requests, that the Honest Broker Core is capable of processing. This diagram shows each object's attributes (more ...)
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).
One feature requiring additional discussion is the transaction support. This feature of the HBC was built following a model of events and subevents, where a transaction fault, e.g., a failure to route information to one of several destinations, causes the system to notify a system administrator via e-mail and to signal the event initiator to retrigger the event at a later time, usually 24 hours later. Once an event is retriggered, only incomplete subevents are executed, which alleviates the need for systems outside of the HBC from having to individually implement transaction support or monitor for duplicate information being sent. All events processed by the HBC, both successful and failed ones, are logged for auditing purposes, with each log entry including an identifier for the event initiator, the event status, and the time of the event.