Embedded Files
What We're Building
The Shift Sandbox is a reference implementation. It's for implementers who want to learn, adapt, and apply our methods to their own systems. It validates key workflows around:
Security Labeling: Tagging sensitive data at creation or ingestion
Consent Enforcement: Automating what gets shared based on patient preferences
Redaction: Ensuring unauthorized users do not see restricted data
Revocation: Reflecting updates to consent in real-time
Partial Record Sharing: Sharing what’s necessary, protecting what’s not
This environment is modular and extensible—with reusable components designed to support Shift use cases across a variety of settings.
How it Works
Tag the Data
Granular security labels applied at the source
Define Consent
Patients specify what to share, and with whom
Enforce Automatically
Data Sharing Can Be Filtered in Real Time
Open Source and Standards Based
Built on HL7 FHIR and IHE PCF
Why the Sandbox Matters
Too often, consent, privacy, and sensitive data segmentation are treated as afterthoughts—seen as too complex or burdensome to implement. At Shift, we believe these features are foundational, not optional.
The Shift Sandbox exists to demonstrate that granular data control, standards-based consent workflows, and patient-centered interoperability are not only possible—they're implementable today.
This environment serves as a persistent, open-source, and modular testing ground for organizations, vendors, and developers to explore how real-world Shift use cases can be implemented using modern standards like HL7 FHIR DS4P, and IHE Privacy Consent on FHIR (PCF).
Demonstration Scenarios
This architecture reflects real-world interoperability and privacy standards, allowing implementers to visualize how granular consent and segmentation would work across systems, not just in theory—but in production. Our sandbox currently is expanding to include demonstrations such as:
EHR → HIE
Labeling sensitive data using a Security Labeling Service (SLS)
Enforcing partial sharing through sandbox-based HIE logic
EHR → EHR
Sharing labeled resources across systems
Demonstrating consent-based access controls in the recipient system
Consent Workflows
Enforcement of patient preferences using a Consent Management Engine
Real-time consent decisioning
Revocation and its downstream effects
Sandbox Architecture
At the core of the sandbox is a FHIR-native architecture that integrates:
FHIR Consent Store(s) and API
Security Labeling Service (SLS)
Consent Decision and Enforcement Services
Authorization and Policy Engine
FHIR-based EHR and HIE connectors
Patient and clinician-facing Consent Management UI
Security Labeling Service
This diagram illustrates how the Security Labeling Service (SLS) fits into the Shift Sandbox architecture to enable automated, standards-based tagging of sensitive health data at the point of ingestion or exchange.
How It Works – Simplified Flow:
A transaction bundle (containing health data) enters the system via the Batch Orchestrator.
The SLS applies sensitivity labels based on predefined rules.
The labeled data is processed into a new data bundle.
The orchestrator routes this bundle to the appropriate destination. such as a FHIR server, another EHR, or sandbox HIE.
Labeling queue and triggers support batch updates or downstream changes when data is modified or new rules are applied.
Subscriptions can notify the system when updates are needed based on data source activity.
This architecture allows the Shift Sandbox to simulate real-world conditions where data must be labeled, filtered, and shared based on consent and sensitivity. It demonstrates how sensitive information can be automatically identified and protected: a critical foundation for trustworthy, patient-directed health information exchange.
Key Components:
Labeling Rules: A stored set of policies that define what qualifies as "sensitive" based on clinical codes, context, or jurisdictional logic. These are maintained in coordination with Shift's Terminology Workstream and HL7 efforts.
SLS (Security Labeling Service): This service reads the labeling rules and applies structured sensitivity tags (e.g., reproductive health, substance use) to FHIR resources. It is the heart of the sensitivity tagging engine.
Batch Orchestrator: Coordinates and manages the flow of data bundles through the system. It receives transaction bundles, invokes the SLS as needed, and queues content for downstream processing.
Labeling Queue: A holding mechanism for data awaiting processing, triggered either by subscriptions, scheduled jobs, or specific system events (“other triggers”).
FHIR Data Source: This represents the external system or database where clinical data originates or resides—such as an EHR or HIE. It can subscribe to receive data bundles or trigger the labeling queue based on updates.
Development Team
Dr. Mohammad Jafari
Technical Director
Fred Hong
Engineer
Danni Zhang
Engineer
All components of the Shift Sandbox are open source and available on GitHub:
Shift sees the Sandbox as a shared public good, and we invite collaborators, vendors, and researchers to help us refine and extend it.
If you’re working on privacy, consent, segmentation, or equity in interoperability—this sandbox is for you. Reach out to contact@shiftinterop.org to connect.
Think we're missing something? Let us know! Email us at contact@shiftinterop.org
Report abuse