Zus
What is Zus?
Zus is our vendor for Health Information Exchange (HIE) data. Zus is not an HIE itself but aggregates, normalizes, and enriches HIE data from several sources.
Types of Patient Data
Zus includes the following types of patient data:
- Medical: EHR data from thousands of provider sites nationwide, accessed via interoperability network partners such as CommonWell and Carequality.
- Pharmacy: Prescription and medication fill data from pharmacies nationwide, accessed via our e-prescribing network partner Surescripts.
- ADT: Alerts about admissions, discharges, and transfers from healthcare facilities nationwide, accessed via our ADT network partners PointClickCare and Bamboo Health.
- Labs: Comprehensive historical lab results from clinical laboratories nationwide, accessed via our lab partner Quest Diagnostics.
In Q2 2025, the EHR networks will also include TEFCA.
Zus routes additional ADT feeds from local California HIEs for Pair Team, including Manifest-Medex and SCHIO.
For more detailed information, please refer to the Zus Aggregated Profile documentation.
CCDA, ADT, and FHIR
The atomic unit of Zus data is a Fast Healthcare Interoperability Resource (FHIR). One of the primary functions of Zus is to translate Consolidated-Clinical Document Architecture (CCDA) documents, Admission Discharge Transfer (ADT) feeds, and other data types into FHIR via the Zus FHIR Store. From there, we can either access the data via API call or through the Snowflake data share.
The translation of CCDA documents into FHIR, and FHIR into a relational database was one of the primary reasons we chose Zus as our vendor.
Some important notes on CCDAs and ADTs
Of critical importance to using Zus for analytics is the difference between CCDAs and ADTs.
| Description | CCDA | ADT |
|---|---|---|
| Encounter types | Any | Inpatient or ED only |
| History | All time for Commonwell and Carequality; 1 year prior to subscription for Collective-Medical | After subscription |
| Source | Commonwell, Carequality, and Collective-Medical | Commonwell, Carequality, Collective-Medical, Manifest-Medex, and SCHIO |
The reason this matters is that we effectively have inflated inpatient and ED data post-enrollment for all patients, since encounters post-enrollment can also include ADT feeds, which come from a larger set of sources. This can cause issues for things like pre/post analyses where we want equally represented data in each time period.
How do we use Zus?
We have 2 primary use cases for Zus data.
- Transitions of Care: this workflow is entirely reliant on ADT feeds. When a patient subscribed to Zus has an inpatient or emergency department discharge, ARC accesses data from the Transition of Care Lens API from Zus to create a transition of care intervention in the patient's care plan. More detail can be found here.
- Analyses of Clinical Data: as our primary source of clinical data for our patients, Zus is used many places, including Care Gaps and Publication Analyses.
Zus suscriptions
Once per day we send a list of all actively enrolled ECM and CHW patients and their demographic information to Zus. The required information for a subscription is listed here. Patients can also be manually subscribed to Zus using the ZAP portal.
This repository hosts the scripts responsible for Zus subscription.
At some point we will need to unsubscribe patients who have enrolled from Pair Team, but we are not currently doing this.
Reciprocity
A key requirement of obtaining data from Zus is reciprocity, which just means that we are sharing data back to the networks. Currently we share both clinical and non-clinical encounters with Zus via Elation and Arc respectively. Because Zus and Elation have a native integration we do not need to own the process for clinical encounters. For non-clinical encounters, we send data to Zus once per day. More detail on this process can be found here, and the accompanying code here.
Zus has asked that we update our reporting on this but did not give a due date.