SHRINE: enabling nationally scalable multi-site disease studies

Abstract

Results of medical research studies are often contradictory or cannot be reproduced. One reason is that there may not be enough patient subjects available for observation for a long enough time period. Another reason is that patient populations may vary considerably with respect to geographic and demographic boundaries thus limiting how broadly the results apply. Even when similar patient populations are pooled together from multiple locations, differences in medical treatment and record systems can limit which outcome measures can be commonly analyzed. In total, these differences in medical research settings can lead to differing conclusions or can even prevent some studies from starting. We thus sought to create a patient research system that could aggregate as many patient observations as possible from a large number of hospitals in a uniform way. We call this system the 'Shared Health Research Information Network', with the following properties: (1) reuse electronic health data from everyday clinical care for research purposes, (2) respect patient privacy and hospital autonomy, (3) aggregate patient populations across many hospitals to achieve statistically significant sample sizes that can be validated independently of a single research setting, (4) harmonize the observation facts recorded at each institution such that queries can be made across many hospitals in parallel, (5) scale to regional and national collaborations. The purpose of this report is to provide open source software for multi-site clinical studies and to report on early uses of this application. At this time SHRINE implementations have been used for multi-site studies of autism co-morbidity, juvenile idiopathic arthritis, peripartum cardiomyopathy, colorectal cancer, diabetes, and others. The wide range of study objectives and growing adoption suggest that SHRINE may be applicable beyond the research uses and participating hospitals named in this report.

Figure 1. Investigator's perspective of the SHRINE Webclient.

Group 1 defines searches for patients with Acute Lymphoid Leukemia (ALL). Group 2 refines the search result to only those patients having one of the medications listed. The medications shown are all chemotherapeutic agents administered during intensive phase. Group 3 further refines the result to require a lab test administered during diagnosis. Lab test values can be set directly or flagged as ‘abnormally high/low’. In the Query Status window, patient counts are displayed with a Gaussian blur to provide additional privacy safeguards of small patient populations. Results are shown for each hospital and the aggregated patient set size.

Figure 2. Federate Query Sequence.

The investigator logs in and composes a query in steps 1–2. SHRINE securely queries multiple hospital peers and returns aggregated results in steps 3–6. The process of securing and translating queries across multiple hospitals is invisible to the investigator user. Lastly, the investigator reviews the results and logs out in steps 7–8.

Figure 3. Query Expansion in the Core Ontology.

Selected Example: ‘Cardiovascular medications’ is selected and the child contents are shown. At runtime, the query is expanded to include every concept in the cardiovascular medication group, recursively.

Figure 4. Hospital Data Mapping Scenario.

First, existing clinical data are extracted into a locally controlled database for research. Second, each local code is mapped to one or more standard concept codes, and vice versa. Third, related medical concepts are grouped using standard hierarchies curated by medical experts. The bipartite graphs produced by this process enable bidirectional translation between concept systems. Fourth, adapt the incoming query to use the local concept codes.

Figure 5. Constructing Bipartite graphs to map concept systems.

Left : Medications are mapped between Children's Hospital Boston (blue) and the RxNorm standard (green) if they share a drug ingredient. The hospital concept code for Acetaminophen is mapped to the RxNorm concept code for Acetaminophen. Codeine also has one mapping. ‘Acetaminophen with Codeine’ has a mapping to RxNorm for each of its ingredients. Patients recorded with the local concept ‘Acetaminophen with Codeine’ will match standard queries using any of the mapped RxNorm drug ingredients. Right : Lab Test concepts are mapped between Children's Hospital Boston (blue) and the LOINC standard (green). Bicarbonate and Blood Urea Nitrogen are each mapped once. Other lab tests require a one-to-many mapping, for example, there are at least four different metabolic tests for sodium (Na+) levels recorded in the Children's Hospital Boston clinical systems.

Figure 6. Percentage of Diagnosis and Medication concepts mapped for SHRINE queries at participating Harvard affiliated teaching hospitals.

Left: Percentage of ICD9-CM diagnoses concepts mapped to at least one diagnosis concept at the hospital. Right: Percentage of RxNorm medication concepts mapped to at least one patient medication concept at the hospital.

Figure 7. Peer Group configurations.

Top: P2P networks are shown for the deployed West and East coast SHRINE networks with 3 and 4 peers respectively. P2P networks have n*(n-1)/2 edges. In the example p2p network with 6 peers, 6*5/2 = 15 edges are drawn. A 60 node P2P network would have 60*59/2 = 1,770 edges. Bottom: Hub Spoke networks are drawn starting with 6 peers. As peers are added, they can attach with a single link to an existing hub. As new hubs are formed regionally, they can be easily attached to the overall network.

Figure 8. Quadratic growth in the number of edges in a communication network.

Each edge incurs administrative overhead to maintain a list of peer locations and trust relationships. Fully meshed peer-to-peer (P2P) topologies have N*(N-1)/2 edges shown in red. Edge growth of hub-spoke topologies are shown with an average hub size of 3 (size of the first deployments of east and west coast networks). A simple hub-spoke topology requires one additional link per hub, shown in green. A fault tolerant topology requires two additional links per hub, shown in purple. With 60 peers, the number of p2p edges is administratively infeasible with 1,770 firewall rules and trust relationships.