June 19, 2024: Decommissioning select tables in legacy data mart schema

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:


June 17, 2024: Intelligent Refresh for Expected Refills

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.

June 10, 2024: Starting Thursday June 13, Zus App users must log in daily

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.


June 7, 2024: Document Retrieval Optimization Implemented

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.


May 22, 2024: Persistent Filters in the ZAP are Now Available!

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.


May 16, 2024: Preview FHIR REST APIs now contain correct full links for pagination

Today, users of the preview FHIR RESTful APIs available at 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.

May 13, 2024: Refreshing documents throughout a patient's hospital stay

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.

May 13, 2024: Updates to FHIRplace experience

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:


May 8, 2024: Updated Design for Source Documents

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.


May 2, 2024: Device data extracted from CDAs now available

FHIR Device resources extracted from CDAs are now available to customers through data marts, in FHIRplace, and via the Zus APIs. These resources typically contain information on device types (implant, instrument, etc), how the device is associated with a specific patient, and the device’s operational status (active, inactive, etc). For example, a Device resource may describe that patient John Doe (with an ID: 12345) has an active cardiac pacemaker, with a SNOMED CT code of 14106009.