To improve and streamline our services, Zus will retire non-relational data mart schemas on October 15, 2024. This change will transition all customers to the new, more usable and performant relational schema.

Changes to different schemas

A Zus data mart customer today can have up to three different schemas available to them:

• [CUSTOMER_NAME]: The Zus legacy schema, available to select customers - will be retired on October 15, 2024
• [CUSTOMER_NAME]_STAGING: The Zus preview relational schema, available to select customers - will be retired on October 15, 2024
• [CUSTOMER_NAME]_RELATIONAL: The Zus relational schema, generally available to all customers - will continue to be supported through future versioning

For more information on the features on the relational schema and how to access it, please refer to our changelog post introducing the relational schema.

What this means for customers

To ensure a smooth transition, we recommend the following steps during the transition period:

1. Familiarize yourself with the relational schema: Review the updated documentation to understand the enhancements and changes.
2. Test the relational schema: Use your development or testing environments to ensure you have access to the relational schema.
3. Update your systems: Modify any scripts, integrations, or workflows that rely on the legacy schemas to be compatible with the relational schema.

If you encounter any issues or have questions during the transition, our support team is available to assist you. Please reach out to us at [email protected].

Future of versioning of data marts

Zus will update the relational schema to keep up with customer needs and data quality best practices, but will ensure that changes to an existing version of the schema are non-breaking.

If breaking changes are needed, they will be introduced in a new schema version. Each version will be supported for a minimum of 9 months, and customers will be given at least 60 days to transition to a new version once it is made generally available. Zus reserves the right to introduce a breaking change without notice if it impacts an unused feature of the data mart.

Stay tuned for updates and detailed release notes with each new version. We are committed to providing the best experience and ensuring seamless transitions.

❓

What is a breaking change?

A breaking change in a data mart schema disrupts existing functionality or requires users to alter how they interact with the data mart. These changes can impact data querying, processing, or interpretation, necessitating adjustments to reports, dashboards, or applications relying on the schema.

Examples of breaking changes include:

• Schema modifications:
  • Changing the name of an existing column or table
  • Removing an existing table or column
• Data type changes: Altering the data type of an existing column (e.g., from integer to string)
• Constraint changes:
  • Modifying or removing primary keys
  • Modifying or removing foreign key relationships
  • Adding or removing unique constraints

Note: Adding a column or table or reordering existing columns within a table does not constitute a breaking change.

On September 1, 2024, we will be transitioning customers that signed order forms for a subscription package before December 15, 2023, from the legacy Pro package onto our latest ZAP Pro Intelligent Refresh package. There is no action required from customers.

The legacy Pro package contains a recurring refresh for all enrolled patients. Based on feedback from network respondents about the unsustainability of this volume, we are shifting legacy customers to our latest package, which relies exclusively on Intelligent Refresh.

Both the legacy and current ZAP Pro packages use the same Intelligent Refresh logic, described here. We will retain this logic and are committed to building on it over time to give you the freshest patient data at the moment when it is most actionable.

Please reach out to Zus Support if you have any questions or concerns.

To better align with our standard naming convention for third party data sources, resources generated from Bamboo Health ADTs created after July 1st, 2024 list a data source of bamboo-health. Resources created prior to 7/1 will continue to list the previous bamboohealth source value.

Zus Data Mart customers may wish to update any queries filtering where data_source = 'bamboohealth'to where data_source IN ('bamboohealth', 'bamboo-health)in order to include a complete history of Bamboo encounters.

Starting August 5, 2024, data mart users must log into their Zus-provisioned Snowflake reader account using the "Sign in using Zus Health" button. This change aims to enhance your user experience with improved access management and security, providing streamlined login across all Zus services, including the Zus standalone UI application, Zus APIs, and FHIRPlace.

What You Need to Do:

1. Visit the Snowflake login page as you normally would, available at https://zus-{company_name}.snowflakecomputing.com.
2. Click on the "Sign in using Zus Health" button.
3. Follow the on-screen prompts to complete the login process.

Frequently Asked Questions

What if I use my own identity provider like Azure Active Directory or Google SSO?

Follow the on-screen prompts and you'll be redirected to your identity provider for authentication.

What if I don't have a Zus username and password?

If you have a Zus-provisioned Snowflake reader account but no Zus account, you will receive an email on August 5th to set up your Zus username and password.

What if Zus directly shares the data mart to my organization's own Snowflake account?

This change only affects Zus-provisioned Snowflake reader accounts. Your login to your organization's Snowflake account remains unchanged.

For any issues or questions, contact our customer support team at [email protected].

We are thrilled to announce our latest Lens for Encounter data. This new Encounter Lens ensures that all encounters are cleaned, deduplicated, and normalized.

Key Benefits

• Improved Encounter Data Quality: Automatically cleans and normalizes encounter data, ensuring accuracy and consistency.
• Enhanced Efficiency: Reduces the time and effort required to manage and process encounter data.
• Seamless Integration: Works seamlessly within the ZAP and via API*, enhancing your data management workflows without requiring manual intervention.

Description

The Encounter Lens operates in the background, applying Zus technology and knowledge to clean, deduplicate, and normalize encounter data including the type of encounter, date, time, diagnoses, and more. This ensures that all encounter data you work with is accurate, consistent, and ready for use.

Important Note on Data Reduction

With the introduction of the Encounter Lens, you may notice a significant reduction in the number of rows of data. This is a result of our deduplication and normalization processes, which consolidate duplicate and redundant data entries. This reduction improves data quality and usability, ensuring you work with the most relevant information.

The Lens produces an 85% reduction in encounter volume per patient for clinical users wanting to make sense of what happened, and helps them find information important to care delivery faster.

The Encounter Lens deduplications takes this:

And transforms it into this:

Setup/Configuration

The Encounter Lens is automatically available in the Encounters component of the ZAP. We expect the Encounter Lens data to be available in Zus data marts by the end of the month, and will publish a separate release note when they are available.

Note

Some Hospital Encounters come to Zus incorrectly coded as Ambulatory encounters. You may notice an encounter that spans several days labeled as “Ambulatory” for this reason. We are working to implement a data enrichment that will correctly categorize these encounters as inpatient, and plan to make this improvement available in the coming weeks.

*Lens data will be available via API, but not yet in data marts.

Users of the Zus Web Application are now able to open CDA documents in a new tab in addition to viewing the document within the ZAP.

Viewing multiple documents is much easier - click on the "open in a new tab" button and the document will open, allowing users to return to the profile to open additional documents or browse the ZAP.

Users can also use a keyboard command button in combination with a click to open documents in a new tab effortlessly. Simply hold down the Ctrl key (or Cmd key on Mac) while clicking on the document link to open it in a new browser tab.

In addition, the URL of the document tab is sharable with other colleagues at your organization with a Zus account. Users not already logged into Zus will be prompted to log in to view documents via URL.

Enrolling a patient in a ZAP Data Subscription requires specifying the practitioner with a treatment relationship to the patient. The Data Subscriptions API will now accept a reference to an existing FHIR Practitioner resource in place of the NPI, name, and role fields when creating or updating an enrollment.

POST https://zap-data-subscriptions.dev.zusapi.com/zap-data-subscriptions/enrollment-statuses

{
    "data": {
        "type": "patient-data-subscriptions/enrollment-status",
        "attributes": {
            "status": "active",
            "practitioner": {
                //Specify either practitioner resource-id OR an npi, name, and role
                "resourceId": "{{Practitioner ID}}"
                //"npi": "",
                //"name": "",
                //"role": ""
            }
        },
        "relationships": {
            "patient": {
                "data": {
                    "id": "{{Patient ID}}",
                    "type": "fhir/Patient"
                }
            },
            "package": {
                "data": {
                    "id": "{{Package ID}}",
                    "type": "zap-data-subscriptions/package"
                }
            }
        }
    }
}

For more information on how to enroll your patients in a ZAP Data Subscription, visit our API Documentation.

After careful consideration, the following tables in the legacy data mart schema will be decommissioned due to their limited usage and value to analytics use cases:

• DeviceUseStatement
• DocumentReference_Author
• LocationTag
• PatientTag
• Child tables for contained resources: DiagnosticReportContained, EncounterContained, ImmunizationContained, MedicationDispenseContained, and MedicationRequestContained

On July 8, 2024, the above tables will be removed.

They are no longer actively maintained with the latest data, updates, bug fixes, or support for issues. Please ensure that you have migrated your integration before this date to avoid disruptions to your service.

Why is Zus decommissioning these tables?

We are decommissioning these tables to make way for significant improvements and enhancements with the relational schema and to reduce the number of supported tables in the data mart schema that have limited analytics value. Specifically, contained resources do not have an independent existence apart from the resource that contains them. They cannot be identified independently, nor can they have their own independent transaction scope. Contained resources are used for a small minority of FHIR resources in Zus:

• Less than .1% of DiagnosticReport resources, and used to represent Observation and Practitioner
• Less than .1% of Encounter resources, and used to represent Condition, Location, and Practitioner
• Less than .1% of Immunization resources, and sed to represent Observation and Organization
• Less than 1% of MedicationRequest resources, and used to represent Condition, Medication, Practitioner, and Organization
• Less than 4% of MedicationDispense resources, and used to represent Medication, Location, and Organization

How can I migrate to the relational schema if I'm depending on these tables?

If you would like to access the same data, you can transition to the relational schema

DeviceUseStatement

DocumentReference_Author

LocationTag and PatientTag

The full FHIR resource is available in the RESOURCE_JSON column.

DiagnosticReportContained, EncounterContained, ImmunizationContained, MedicationDispenseContained, and MedicationRequestContained

The full FHIR resource is available in the RESOURCE_JSON column.

Contact Us

If you have any questions or encounter any issues during the migration process, please do not hesitate to reach out to our support team at [email protected]. We are here to assist you and ensure a seamless transition.

We appreciate your continued support and cooperation as we work to provide you with the best possible service. Thank you for being a valued part of our data mart user community.

We're excited to introduce a new Intelligent Refresh trigger to improve latency for prescription activity in Zus and enable better tracking of medication adherence. The “Expected Refill” trigger calculates an expected refill date for each medication fill processed in Zus (as whenPickedUp* + days supply) and will automatically schedule a follow up refresh to check for pickup ~5 days after the expected date. As a part of this change, we will be adjusting the 28 day backstop (if no other refresh activity) to 36 days to better align with standard 30 day refill cycles.

*Not all fills include pickup date information, in which case whenPrepared is used as a fallback

With this addition, this brings brings the list of medication history refresh triggers up to:

• Initial enrollment
• Before the appointments you share with Zus
• After any 3rd party appointments we pull in from other providers on Carequality and Commonwell.
• After an ADT discharge
• 5 days after the expected refill date (as WhenPickedUp + daysSupply) for a given medication
• Any time more than 36 days have elapsed between refreshes

Zus will be updating the login session management settings for the Zus Web Application. Beginning June 13, all users will be required to log in daily regardless of activity (in other words, after 24 hours you will be asked to re-enter your login credentials). We are making this change to align with industry security standards.

Note: This does not impact the embedded EHR ZAP experience, where the inactivity timeout is dependent on the EHR.