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
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.
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://
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.
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.
Improvements have been made to the organization of conditions in the Conditions Component to help clinical users more easily make sense of a patient’s condition history. These changes will begin rolling out today!
Indicating High-Risk Conditions
A previously released update now indicates conditions that qualify for Hierarchical Condition Categories with a blue HCC badge. HCCs can be used to identify patients with serious acute or chronic conditions as part of a risk-adjustment model. Specific HCC and ICD codes can be found by opening the condition’s details side panel.
⚠️ The HCC indicator is currently displayed based off of the CMS risk-adjustment model. Please reach out if your organization would like to switch to the HHS model, or disable the HCC indicator.
Grouping Conditions by Category
Patient problem lists are messy. In addition to ongoing work to reduce the number of duplicate conditions, we’ve also grouped conditions by Clinical Classifications (CCSR) category by default. Now, clinical users can more easily understand a patient’s overall problem areas, as well as compare diagnoses within a category. Conditions will remain grouped by category even when filters are applied.
Ongoing Improvements
Over the coming weeks, additional improvements will be made to dates related to conditions.
Enhancements to the Last Diagnosed date will more accurately indicate the last time a condition was recorded by a physician in the patient’s chart. This date will be reflected on the Overview card, as well as in a dedicated column in the Conditions Component.
The Onset Date field will be updated to include the earliest known physician recorded date if no Onset Date is specified.
