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.
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.
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.
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.