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.

We have updated the way in which we process patient documents. Previously, when gathering documents for a patient, we would download all of their documents (regardless of the document's age or if we had downloaded it before). We have now implemented an optimized approach (for documents associated with the CareQuality network) where we only download all of a patient's documents once. After that, any further petitions for a patient's documents will limit retrieved documents to only those created in the past year (with specific exceptions for documents with dates prior to 1970). You may see these changes result in fewer duplicates in both the Zus App and overall. If you observe anything trending in an unexpected direction during your normal analysis do not hesitate to get in contact with us.

🥳 A new data mart schema in a familiar relational format is now available!

Before, data mart users had to extract JSON from key data elements to answer their analytical questions. Now, a data mart user can easily query the data directly without needing to deal with complex JSON structures. This makes the data more accessible and easier to use.

📣 No more LATERAL FLATTEN or UNNEST functions!

Features

The new data mart schema features include:

• Foundational resource types (Medication, Location, Practitioner, Organization) from third-party data sources
• The addition of new FHIR resources types: DeviceUseStatement, RelatedPerson
• The separation of Zus-summarized data (Lenses) into their own tables. Check out the lens_rxnorm_medication_statement, lens_snomed_condition, and lens_transition_of_care tables
• The full JSON of the FHIR resource for zero lossiness. See the resource_json column in the base resource tables.
• The top-leveling of codes. For example, in the Observation table, there are code_loinc and code_snomed columns
• The consistency of naming conventions for foreign keys
• The removal of columns that were always NULL
• Shortening of the univeral_patient_identifer column name to upid

Documentation

We have also improved our documentation to include entity relationship diagrams and a data dictionary.

Accessing the new schema

If you have a Zus-provisioned Snowflake reader account, you can now access the new relational schema in the {customer_name}_export_zus database and the {customer_name}_relational schema within your existing Snowflake reader account.

For those with a direct data mart share from Zus to your own Snowflake account, you will need to consume the share. Please refer to the following Snowflake documentation for instructions: Creating a Database from a Share.

Data Refresh

The new relational schema refreshes every 24 hours except for the following resource types — Condition, Device, DocumentReference, Encounter, Location, Organization, Patient, and Practitioner — which are refreshed every 3 hours.

Starting today any filters or sorting a user applies to the ZAP will be automatically retained. Users no longer have to reset filters after logging out or switching between patients.

We're continuing to update this feature and welcome your feedback!

Filters will persist in the Zus Application, embedded ZAP in EHRs, and in the Hospitalizations Page.

Today, users of the preview FHIR RESTful APIs available at https://fqs.zusapi.com/rest can now supply a header "X-New-Pagination" to receive the full URL schema in next and previous links, which conforms to FHIR's RESTful API's standards. This will allow users to update their integrations to take into account the correct URL in links.

The preview FHIR RESTful APIs will be defaulting to this link format on May 31, 2024 or earlier if all API consumers have transitioned appropriately. After May 31, 2024, users will no longer need to supply the "X-New-Pagination" header, and the header will be ignored in requests.

For example, when retrieving all FHIR Encounters associated with a patient assigned UPID abc123, a user can execute the following query:

GET https://fqs.zusapi.com/rest/Encounter?upid=abc123

If the search returns more than 10 resources, the response will return a Bundle containing only the first 10 and a link which will return the next 10, etc. Without the "X-New-Pagination" header, the link URLs will not contain https://

  "link":[  
        {  
            "relation": "self",  
            "url": "fqs.zusapi.com/rest/Encounter?upid=abc123"  
        },  
        {  
            "relation": "next",  
            "url": "fqs.zusapi.com/rest/Encounter?_after=eyJrZXki...&upid=abc123"
        }
    ]

With the header "X-New-Pagination:true", the link URLs will contain the full URL schema, including https://

  "link":[  
        {  
            "relation": "self",  
            "url": "https://fqs.zusapi.com/rest/Encounter?upid=abc123"  
        },  
        {  
            "relation": "next",  
            "url": "https://fqs.zusapi.com/rest/Encounter_after=eyJrZXki...&upid=abc123"
        }
    ]

We've updated our Intelligent Refresh behavior to help provide more-timely updates on hospitalized patients throughout their admission. In addition to refreshing EHR Documents and Medication Fills within 72 hours of an ADT discharge event, Zus will now refresh available documents within 2 hours of receiving any ADT message, including Admits and Transfers.

This update is now enabled for all patients in a ZAP Pro subscription package, and does not require any action on your part to enable.

We'll be updating the FHIRplace application on June 14, 2024, to begin utilizing our FQS API for greatly improved performance when browsing FHIR resources for your patients. You may notice a few changes in the interface to browse by patient UPID or resource ID, which are outlined below:

• Like the Zus App, FHIRplace will have a patient-centric navigation experience. In order to view clinical resources such as encounters, conditions, and observations, you must choose and filter on a specific patient
• We will support a more limited set of parameters for filtering Patient and other resource types
• Minor change to the navigation experience to jump to a known resource id
• The "Show Everything" tab on the Patient resource page will be deprecated
• There will be minor changes to the write and pagination experience

Documentation on the new FHIRplace experience is available here. You can preview the experience here.

Beginning today, source documents (Continuity of Care Documents or CCDs) have an updated design. This new design makes documents easier to use; including a table of contents, collapsible sections, and easier-to-read notes.

Learn more about Zus Documents in the Clinical Guide.