Once data is in the Exchange, an administrator or data engineer configures who can use it for research or clinical care.
How it works¶
Run an Exchange. If your institution already runs a JupyterHealth Exchange, you can use that. Otherwise, you can run your own. Running your own is a job for an engineer or IT team, who can start with the Exchange’s Getting Started guide. If your institution runs its cloud services on Kubernetes, the Helm chart installs the Exchange there. To talk through running JupyterHealth at your institution, contact the team.
Decide who can see what. In the Exchange, researchers and clinicians belong to organizations, which group users and patients for access control. They can read data for the patients in their organizations, and their role (viewer, member, or manager) controls what they can change. Patient consent decides what data gets into the Exchange. Once data is in, consent doesn’t limit which people in the organization can read it. See Access Control.
Connect other tools. Other software reads data through the Exchange’s APIs, which check the same permissions. The Hub uses the Exchange for login, and an EHR can launch apps that use it (see step 4).
Configure EHR access, if you want EHR launches. For clinicians to open dashboards from their EHR, the admin needs to tell the Exchange to accept logins from that EHR. Each clinician also needs a record in the Exchange that is linked to their EHR account. See Provider EHR Launch (SMART on FHIR).
The Exchange has two APIs, plus an optional AI server:
A REST API for managing organizations, studies, and patients.
A FHIR API for reading and writing health data in the FHIR standard.
An MCP server, deployed separately, so AI tools can query the data. See MCP.
Learn more¶
Exchange clients: how other tools log in to the Exchange.
Next step: Analyze data and build data products.