UChicago Medicine ADAMS Center
Designing a tiered data governance system for a new clinical research platform
Service Design
2024
The
Brief
UChicago Medicine's partnership with MDClone introduced a significant new capability: the ability to pull longitudinal patient data across the health system rapidly, and to generate synthetic datasets suitable for grant applications and quality improvement projects. The tool had the potential to substantially reduce the friction of clinical research, but only if the question of access could be resolved.
The existing process for data access was sequential and manual: a researcher would submit a request, the data team would verify credentials, pull the relevant data, anonymize it as required, and deliver it securely. That process worked, but it was slow, placed significant burden on the data team, and created bottlenecks that discouraged research. The new system needed to preserve that process for the most sensitive data while opening up direct access for lower-risk data types (synthetic data, pre-anonymized datasets) to users who had the appropriate credentials and training.
The design problem was not the software. It was governance: who gets access to what, under what conditions, through what process, with what accountability. Getting that wrong meant either recreating the bottlenecks of the old system or creating HIPAA exposure. Getting it right required a shared understanding across teams - IT, informatics, data management, compliance, privacy, and clinical quality - that did not yet exist.
Co-Creating a Service Blueprint
The service blueprint became the primary tool for building that shared understanding. Rather than designing it in isolation and presenting it for approval, the blueprint was co-created iteratively with stakeholders from across the institution; including the Chief Privacy Officer, the VP for Clinical Quality, the Executive Directors of both Research Informatics and Clinical Data and Analytics, and the MDClone implementation team.
Kimisha Cassidy - Senior Project Manager, HDSI
Pete Calderone - MDClone
Julie Johnson - Executive Director, Center for Research Informatics
Mary Kate Selling - Executive Director, Clinical Data and Analytics
Shwetha Devanagondi - Director, Clinical Data and Analytics
Karen Habercross - Chief Privacy Officer
Thomas Spiegel - Vice President and Health System Chief Quality Officer
Each iteration did two things: it refined the blueprint itself, and it surfaced assumptions that different teams had been carrying independently. What counted as a "clinical user"? What training was sufficient to qualify for direct data access? How long should a back-end access request realistically take, and who was accountable for that timeline? These were not questions that could be answered by design alone — they required negotiation across teams with different priorities and different risk tolerances. The co-creation process made that negotiation visible and productive rather than implicit and contested.
The blueprint also generated requirements for adjacent workstreams: training modules, access request forms, and communication materials for users unfamiliar with the new system.
The Core Blueprint
The core blueprint shows all the user types, permissions paths, and actions that can be taken within a single document. In this way, it highlights the process for different types of users to access different kinds of data, as well as the back-end tasks that need to be undertaken to grant access or to approve data requests.
The blueprint was designed to continue to grow and evolve as new modules and features and user types are added and the process evolves.
Individual Service Blueprints
The overall service blueprint could also be broken down into individual elements for different kinds of users:
Admin Users
ADAMS Center Staff
Pro Users
Frequent Users who have undergone training and have been given permission to directly download or export data
Clinical Users
UChicago Medicine Clinical Staff who have prior permission to view patient data on other platforms (EPIC, Slicer Dicer etc.)
Non-Clinical Users
UChicago Medicine Non-Clinical Staff, who don’t have permission to view patient data but may need access to data for certain projects (Project Managers, Quality Improvement, Designers)
University Users
Collaborators from the University (but outside the Medical Center) frequently collaborate with the medical center on projects and may need access to data.
External Vendors
Vendors from outside the hospital / university system who need access to data for projects
These focused blueprints are intended to communicate the process to those individual users, as well as how long they can expect back-end processes, such as service requests, to take. In this way, the blueprint acts as a communication tool.
