The individual ADT/Lab providers a given patient will be subscribed to can vary based on factors like geographic location and additional contracting requirements. To avoid any confusion moving forward, the response to GET https://api.zusapi.com/zap-data-subscriptions/packages will no longer include asubscriptionProvidersarray for each package.

Instead, packages will include a boolean value for adtFeeds:true/false and labFeeds: true/false. Please contact support if you have any questions on subscription providers for your patients.

Before:

 "attributes": {
                "meta": {
                    "adtFeeds": true,
                    "labFeeds": true,
                    
                    "subscriptionProviders": [
                        "bamboo",
                        "collective",
                        "connectn",
                        "eden",
                        "floridahie",
                        "ghhconnect",
                        "manifestmedex",
                        "quest",
                        "schio"
                    ]
                },
                "name": "ZAP Pro"

After:

 "attributes": {
                "meta": {
                    "adtFeeds": true,
                    "labFeeds": true
                },
                "name": "ZAP Pro"

As part of an initiative to optimize performance of the Zus platform to better support customers leveraging the Zus Aggregated Profile, we are updating our FHIR platform capability statement.

This update includes no changes to features or functionality currently in use by Zus customers. Noted changes in unused behavior are available here.

This new capability statement is effective as of today, and our API documentation and Postman workspace have been updated to reflect the new capability statement. Documentation for the new FHIR APIs is accessible from the left side bar of our API Reference, under "FHIR REST APIs".

Please review our updated capability statement to ensure you have the most current information. If you have any questions or require further clarification, please do not hesitate to reach out to our support team.

We appreciate your continued partnership and trust in our services. Thank you for your attention to this update.

Starting today, the previously titled "Hospitalizations Page" in the Zus Web Application is called "Transitions."

The Transitions page provides a list of patients that have had recent encounters at hospitals or emergency rooms.

Read more about it here.

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.