Builder developer users can now try the Zus GraphQL API, which offers efficient queries to retrieve FHIR resources for one patient to integrate with the Zus Aggregated Profile (ZAP). For more information, see: https://docs.zushealth.com/docs/graphql-fhir-query-service
Care Teams can now view patient allergies from their organization and outside provider records in the new Allergies embeddable component. Learn more about the Allergies component and the overall Zus component library.
📆 Appointments and five other FHIR resource types now included in Data Marts.
Data is now continuously streamed to Snowflake data marts. The latest state of FHIR resources should be reflected in Snowflake data marts within one hour of the change in the Zus FHIR Store. Previously, Snowflake data marts were automatically refreshed 4 times a day.
Occasionally, CommonWell and Carequality participants respond to patient history requests with CDA documents respondents that have other binaries (e.g., PDFs, text, images) embedded within them. As of last week, we are extracting these embedded binaries and storing them to ODS.
Patient history API calls will now validate the patient's address, including their postal code, before accepting a refresh request. Postal codes must be formatted as 5 digits (e.g., 02138) or 5+4 digits separated by a hyphen (e.g., 02138-1000).
We are pleased to announce an update to our Patient History service that will improve the performance and stability of our medication history search.
We have released a search parameter that allows API users to find FHIR resources created by their Builder organization, thereby excluding third-party and Zus-created Lens resources 🥳. To use the first-party search parameter and benefit from the improved performance 💨, add firstparty=true to the URL.
Message statuses on the patient history API will no longer include the list of FHIR resources created by the underlying connectors. Payloads for this API were consistently too large to support a responsive synchronous experience.
