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.

The patient-history/messages endpoint allows Builders to search across previously initiated Patient History jobs. We now order these results by most-recently-created first and support start-date and end-date as parameters to narrow results based on when the job was initiated.

In order to ensure compliance with various clinical information networks, Zus builders are required to specify the name, NPI number, and role of a treating provider when making a /refresh/ request to the Patient History API.

New query examples are up! Learn how you can fulfill your analytic needs with Data Marts. For more information, see: https://docs.zushealth.com/docs/data-marts.

We're pleased to release the next generation of our Patient History service that will enable us with greater speed, stability, and scale in bringing you the clinical data that powers your Zus Aggregated Profile (ZAP).

Calls to the Zus Operational Data Store, which includes our FHIR APIs, are now rate limited at 20 requests per second per IP. The FHIR APIs will return HTTP 429 responses to requests exceeding this limit.

We have developed a guide to configuring ZusHooks, which allow Builders to receive inbound HTTPS requests from Zus that contain information about data creation and update activity in the Zus FHIR Store. For more information, see: https://docs.zushealth.com/docs/subscriptions.

We have deprecated our beta FHIR Manager service, which allowed admin users to define and add custom fields to FHIR resources.

Builders can now use a single API endpoint to manage their care team users and associated FHIR Practitioner resources. With the new Practitioner User Upsert API endpoint, Builders can create & update users, create & update Practitioner resources, and link the two together.

Builders querying the ZAP can now access a small set of foundational resources (e.g., Practitioner, Organization, etc.) from other Builders outside of the Designated Record Set if they are referenced by Designated Record Set resources for a shared patient. For example, a care team user viewing a patient’s ZAP can see who ordered a MedicationRequest from another Builder, as represented by a reference to a Practitioner resource in the other Builder. However, the user cannot query directly for the Practitioner resource. The Practitioner resource is only accessible as part of a query for the MedicationRequest resource. Learn more here.